CN117992083A - 移动终端以及软件更新系统 - Google Patents

Abstract

本发明涉及移动终端以及软件更新系统。移动终端包括：构成同步处理部，构成为取得包括被搭载于车辆的电子控制单元(ECU)的信息的车辆构成信息，并向服务器发送；第1取得部，构成为取得被从上述服务器分发的软件；以及通信部，构成为将由上述第1取得部取得的上述软件发送至上述车辆。

Description

移动终端以及软件更新系统

技术领域

本公开涉及移动终端以及软件更新系统。

背景技术

日本特开2017－149323公开了一种通过OTA(Over The Air：空中下载)来更新被搭载于车辆的ECU(Electronic Control Unit)的软件的技术。

车辆能够通过与外部的服务器(例如OTA中心)进行无线通信来下载车载ECU的新的软件(数据)。而且，在车辆中，通过目标ECU(软件更新对象的ECU)依次执行安装、激活而能够更新软件。

然而，未必全部的车辆都能够与OTA中心进行无线通信。由于对于无法与OTA中心进行无线通信的车辆，不能从OTA中心分发软件，所以无法进行软件的更新。希望对于不具有与OTA中心直接进行无线通信的功能(以下，亦称为“OTA访问功能”)的车辆，也能够通过OTA技术来更新软件。

发明内容

本公开提供针对不具有OTA访问功能的车辆也能够实现基于OTA技术的软件的更新的移动终端以及软件更新系统。

(1)本公开的第1方式所涉及的移动终端包括：构成同步处理部，构成为取得包括被搭载于车辆的电子控制单元(ECU)的信息的车辆构成信息，并向服务器发送；第1取得部，构成为取得被从上述服务器分发的软件；以及通信部，构成为将由上述第1取得部取得的上述软件发送至上述车辆。

根据该结构，移动终端能够与车辆以及服务器通信。移动终端的构成同步处理部取得包括被搭载于车辆的ECU的信息的车辆构成信息，并向服务器发送。由此，服务器能够将被应用于该车辆的新的(更新用的)软件分发给移动终端。移动终端的第1取得部取得被从服务器分发的软件。而且，移动终端经由通信部将由第1取得部取得的软件发送至车辆。这样，车辆能够经由移动终端得到新的软件，能够实现基于OTA技术的软件的更新。

(2)在上述方式中，移动终端可以还包括：活动通知处理部，构成为基于被从上述服务器分发的同意请求信号来向用户请求同意上述ECU的软件的更新处理；安装处理部，构成为指示上述ECU执行发送至上述车辆的上述软件的安装；以及激活处理部，构成为指示上述ECU执行所安装的上述软件的激活。

根据该结构，移动终端的活动通知处理部基于被从服务器分发的同意请求信号来向用户请求同意ECU的软件的更新处理。由此，在用户同意了软件的更新的情况下，能够进行软件的更新。移动终端的安装处理部指示ECU执行发送至车辆的软件的安装，激活处理部指示ECU执行所安装的软件的激活。由于通过移动终端的指示来执行被从服务器分发的软件(新的软件)的安装以及激活，所以可以不设置软件的更新专用的设备等。

(3)在上述方式中，移动终端可以还包括构成为取得上述ECU的负载的第2取得部，其中，上述安装处理部可以构成为当由上述第2取得部取得的上述负载为规定值以上时，指示上述ECU中断上述安装的执行。

根据该结构，在ECU的负载为规定值以上而负载高时，移动终端指示中断安装的执行。由此，由于在软件更新对象的ECU(目标ECU)为高负载、若执行安装则产生故障的情况下中断安装，所以能够进行可靠的安装。

(4)本公开的第2方式所涉及的软件更新系统构成为对ECU的软件进行更新，包括：服务器，构成为分发上述软件；车辆，搭载有上述ECU；以及移动终端，构成为与上述服务器以及上述车辆通信，其中，上述移动终端构成为执行如下处理：从上述车辆取得包括上述ECU的信息的车辆构成信息；将所取得的上述车辆构成信息向上述服务器发送；取得被从上述服务器分发的更新用软件；以及将所取得的上述更新用软件发送至上述车辆，上述服务器构成为执行如下处理：若从上述移动终端接收到上述车辆构成信息，则判断有无被应用至上述ECU的上述更新用软件，当存在被应用于上述ECU的上述更新用软件的情况下，将上述更新用软件分发给上述移动终端。

根据该结构，移动终端构成为能够与服务器以及车辆通信。移动终端从车辆取得包括ECU的信息的车辆构成信息，并将车辆构成信息向服务器发送。服务器若从移动终端接收到车辆构成信息，则判断有无被应用于ECU的更新用软件，当存在被应用于ECU的更新用软件的情况下，将更新用软件分发给移动终端。移动终端若取得了被从服务器分发的更新用软件，则将更新用软件发送至车辆。这样，车辆能够经由移动终端得到新的软件(更新用软件)，能够实现基于OTA技术的软件的更新。

(5)在上述方式中，上述服务器可以构成为还执行如下处理：若从上述移动终端接收到上述车辆构成信息，则判断有无被应用于上述ECU的上述更新用软件，当存在被应用于上述ECU的上述更新用软件的情况下，将同意请求信号发送至上述移动终端，若从上述移动终端接收到发送请求，则将上述更新用软件分发给上述移动终端，上述移动终端可以构成为还执行如下处理：若从上述服务器接收到上述同意请求信号，则向用户请求同意上述ECU的软件的更新处理；在由用户做出了上述更新处理的同意时，将上述发送请求发送至上述服务器；指示上述ECU执行发送至上述车辆的上述更新用软件的安装；以及指示上述ECU执行所安装的上述更新用软件的激活。

根据该结构，服务器若从移动终端接收到车辆构成信息，则判断有无被应用于ECU的更新用软件，当存在被应用于ECU的更新用软件的情况下，将同意请求信号发送至移动终端。移动终端若从服务器接收到同意请求信号，则向用户请求同意ECU的软件的更新处理，若由用户做出了更新处理的同意，则将发送请求发送至上述服务器。服务器若从移动终端接收到发送请求，则将更新用软件分发给移动终端。移动终端指示ECU执行发送至车辆的更新用软件的安装，并指示ECU执行所安装的更新用软件的激活。由此，由于根据移动终端的指示来执行从服务器分发的更新用软件(新的软件)的安装以及激活，所以可以不设置软件的更新专用的设备等。

(6)在上述方式中，上述移动终端可以构成为取得上述ECU的负载，在所取得的上述负载为规定值以上时，指示上述ECU中断上述安装的执行。

根据该结构，在ECU的负载为规定值以上而负载高时，移动终端指示中断安装的执行。由于在目标ECU为高负载、若执行安装则产生故障的情况下中断安装，所以能够可靠地进行安装。

(7)在上述方式中，上述车辆构成为在上述更新用软件的激活完成时，将更新完成通知发送至上述移动终端，上述移动终端可以构成为当在从将上述更新用软件发送至上述车辆起至接收到上述更新完成通知为止的期间，上述车辆与上述移动终端的通信中断的情况下，在上述车辆与上述移动终端的上述通信恢复时，请求上述车辆发送被安装于上述ECU的软件的版本信息。

根据该结构，在更新用软件的激活完成时，车辆将更新完成通知发送至移动终端。在从将更新用软件发送至车辆起至接收到更新完成通知为止的期间，当车辆与移动终端的通信中断的情况下，在车辆与移动终端的通信恢复时，移动终端请求车辆发送被安装于ECU的软件的版本信息。在从将更新用软件发送至车辆起至接收到更新完成通知为止的期间，若车辆与移动终端的通信中断，则存在软件的更新处理(安装或激活)未正常完成的可能性、更新处理中断的可能性。由于在车辆与移动终端的通信恢复时，移动终端请求车辆发送被安装于ECU的软件的版本信息，所以能够基于从车辆发送的软件的版本信息来判断是否正常地进行了软件的更新处理。

根据本公开，针对不具有OTA访问功能的车辆也能够实现基于OTA技术的软件的更新。

附图说明

以下，参照附图对本发明的示例性实施例的特征、优点、技术及工业重要性进行说明，在附图中相同的附图标记表示相同的构成要素，其中：

图1是表示本实施方式所涉及的软件更新系统的构成的图。

图2是用于在本实施方式中对车辆100中的软件更新方法的概要进行说明的图。

图3是表示在用户终端中构成的功能模块的一个例子的图。

图4是简要地表示在车辆200中执行的软件的更新处理的时序的一部分的图。

图5是表示在用户终端的触摸面板显示器显示的显示画面的一个例子的图。

图6是表示在用户终端的触摸面板显示器显示的显示画面的一个例子的图。

图7是表示由用户终端执行的安装中断处理的流程图。

图8是表示由用户终端执行的通信中断时处理的流程图。

图9是表示在HMI的触摸面板显示器显示的显示画面的一个例子的图。

具体实施方式

参照附图对本公开的实施方式详细地进行说明。在图中，对相同或者相当的部分标注相同的附图标记而不重复其说明。

图1是表示本实施方式所涉及的软件更新系统的构成的图。参照图1，该软件更新系统包括车辆100、车辆200、用户终端300以及OTA中心500。其中，“OTA”是“Over The Air”的简称。

车辆100、200的每一个例如是电动汽车(BEV：Battery Electric Vehicle)。车辆100具有OTA访问功能(与OTA中心500直接进行无线通信的功能)，但车辆200不具有OTA访问功能。车辆100能够与OTA中心500直接进行无线通信，但车辆200若不经由其他通信装置(即，不是车辆200自身所具备的通信装置的通信装置)则无法与OTA中心500通信。

OTA中心500是提供基于OTA技术的车辆软件更新服务的服务器。OTA中心500构成为能够从该中心经由通信划分来实施远程的车载ECU软件更新。OTA中心500分发车载ECU的软件。“ECU”是指电子控制装置(Electronic Control Unit)。

OTA中心500具备处理器510、存储器520以及通信模块530。处理器510例如包括CPU(Central Processing Unit)。存储器520例如包括闪存那样的非易失性存储器。通信模块530通过有线与通信网络NW连接，经由通信网络NW与多个车辆(包括车辆100)的每一个通信。通信网络NW例如是由因特网和无线基站构建的广域网络。通信网络NW也可以包括移动电话网。

车辆100具备OTA管理器110和多个ECU(包括ECU121、122)。OTA管理器110内置有计算机，作为车载诊断装置发挥功能。各车辆所具备的ECU的数量任意。各车载ECU内置有具备至少1个处理器和至少1个存储器的计算机。各车载ECU也可以以主微机以及副微机那样的形态具备多个微机(微型计算机)。

在车辆100中，OTA管理器110与各ECU经由通信总线连接，构成为相互能够进行有线通信。其中，各车辆中的控制装置间的通信方式不特别限定，例如可以是CAN(ControllerArea Network)或者Ethernet(注册商标)。

OTA管理器110具备处理器111、存储器112以及通信模块113。处理器111例如包括CPU。存储器112例如包括闪存那样的非易失性存储器。通信模块113包括用于与OTA中心500直接进行无线通信的通信I/F(接口)。例如，通过通信模块113指定OTA中心500的地址来访问通信网络NW，由此建立车辆100(通信模块113)与OTA中心500之间的无线通信。通信模块113也可以包括进行无线通信的TCU(Telematics Control Unit)以及/或者DCM(DataCommunication Module)。

车辆100的OTA管理器110构成为能够与OTA中心500进行无线通信。车辆100在停车中和行驶中的任一状态下均能够与OTA中心500通信。OTA管理器110管理车辆内信息，接受活动，管理软件更新时序。

车辆100是构成为可自动驾驶的自动驾驶车辆。车辆100构成为能够执行有人行驶和无人行驶双方。车辆100构成为能够无人自主行驶，但也能够通过用户的手动驾驶来进行行驶(有人行驶)。另外，车辆100还能够在有人行驶中执行自动驾驶(例如自动巡航控制)。自动驾驶的等级可以是完全自动驾驶(等级5)，也可以是带有条件的自动驾驶(例如等级4)。

车辆100具备驾驶装置130和ADS(Autonomous Driving System)140。在车辆100中，ECU121构成为控制驾驶装置130。

驾驶装置130包括加速器装置、制动器装置以及转向操纵装置。加速器装置例如包括使车辆的驱动轮旋转的电动发电机(以下，称为“MG”)、驱动MG的PCU(Power ControlUnit)、以及将用于驱动MG的电力供给至PCU的蓄电池。

ADS140包括识别车辆的外部环境的识别用传感器(例如照相机、毫米波雷达、激光雷达中的至少1个)，基于由识别用传感器依次取得的信息来执行自动驾驶所涉及的处理。ADS140与ECU121协作来生成与车辆的外部环境相应的行驶计划(表示将来的车辆的举动的信息)。而且，ADS140请求ECU121控制驾驶装置130所包括的各种促动器，以使车辆100根据行驶计划来行驶。

车辆100具备启动开关150和HMI(Human Machine Interface)170。

启动开关150是用于供用户使车辆系统(车辆100的控制系统)启动的开关，例如被设置于车厢内。一般，启动开关被称为“电源开关”或者“点火装置开关”等。通过用户操作启动开关150，由此车辆系统(包括被搭载于车辆的各ECU)的接通(工作)/断开(停止)被切换。通过启动开关150被接通操作，由此停止状态的车辆系统启动，车辆系统成为工作状态(以下，亦称为“IG接通”)。另外，当车辆系统正在工作时，若启动开关150被断开操作，则车辆系统成为停止状态(以下，亦称为“IG断开”)。

启动开关150的接通操作是用于将车辆的状态从IG断开切换为IG接通的操作。若用户接通操作了启动开关150，则启动请求被输入至各车载ECU。即，各车载ECU受理来自用户的启动请求。另一方面，启动开关150的断开操作是用于将车辆的状态从IG接通切换为IG断开的操作。若用户断开操作了启动开关150，则关断请求被输入至各车载ECU。即，各车载ECU受理来自用户的关断请求。不过，在行驶中的车辆中，启动开关150的断开操作被禁止。

HMI170包括输入装置以及显示装置。HMI170可以包括作为输入装置以及显示装置发挥功能的触摸面板显示器。HMI170也可以包括汽车导航系统的输入装置以及显示装置。

图2是用于在本实施方式中对车辆100中的软件更新方法的概要进行说明的图。参照图1和图2，按照构成同步、活动通知、应用同意、下载、安装、激活、软件更新完成通知那样的顺序进行软件更新(更详细而言是利用了OTA的车辆软件的更新)所涉及的处理。以下说明的处理由OTA中心500和接受来自OTA中心500的软件分发的各车辆执行。接受来自OTA中心500的分发的车辆的数量可以为50台左右，也可以为100台以上小于1000台，还可以为1000台以上。

每经过预先设定的时间，IG接通状态的车辆便反复执行构成同步。另外，IG接通状态的车辆在从OTA中心500接受到构成同步的请求的情况下也执行构成同步。车辆涉及的构成同步处理包括将车辆识别码(VIN：Vehicle Identification Number)、车辆构成信息发送至OTA中心500。车辆构成信息例如包括车辆所包括的每个ECU的硬件信息(表示硬件的产品编号、ECU的识别符等的信息)以及软件信息(表示软件的产品编号、版本等的信息)。

OTA中心500若从车辆(OTA管理器110)接收到上述车辆构成信息，则对在当前时刻产生的活动(软件的更新)进行确认。而且，若存在能够应用于车辆的活动，则OTA中心500发送向车辆的用户请求同意该活动所涉及的新的软件(更新用软件)的下载的同意请求信号。同意请求信号包括与该活动相关的信息(活动信息)。活动信息例如可以包括活动属性信息(表示软件更新的目的、以及有可能受更新影响的车辆的功能等的信息)、活动对象车辆的列表、与活动对象ECU相关的信息(例如更新前后的软件信息(例如版本信息))、与更新前后的对用户的通知相关的信息中的至少1个。其中，被通知的活动可能是新产生的活动，也可能是以前未应用过的活动。以下，将上述同意请求信号的发送亦称为“活动通知”。

车辆(OTA管理器110)若接受到活动通知(同意请求信号)，则向用户请求是否同意该活动的应用的输入。例如，车辆(OTA管理器110)使车载HMI(HMI170)显示“发现了新的软件。是否应用于该车？”那样的消息，来向用户请求表示“同意”与“拒绝”中的任一方的输入。而且，若进行了表示“同意”的输入，则车辆执行以下说明的下载所涉及的处理。另一方面，若进行了表示“拒绝”的输入，则车辆不执行下载所涉及的处理。该情况下，OTA中心500不进入至下载阶段而使软件更新所涉及的处理结束。

在该实施方式中，OTA中心500和车辆的OTA管理器110按照以下说明的步骤执行下载所涉及的处理。

车辆的OTA管理器110向OTA中心500请求包括新的软件(更新用软件)的分发数据包。然后，OTA管理器110从OTA中心500执行该分发数据包的下载(接收以及保存)。分发数据包可以除了包括新的软件(例如成为活动的对象的每个ECU的更新数据集)之外，还包括数据包属性信息(表示更新划分、分发数据包中的更新数据数量、各ECU的安装顺序等的信息)、以及更新数据属性信息(目标ECU的识别符、用于验证更新数据的合法性的验证用数据、软件的版本信息等)。目标ECU是成为软件更新对象的ECU。例如，目标ECU为ECU121，被更新的软件可以是自动驾驶控制程序。

通过上述的下载所涉及的处理，在OTA管理器110所具备的存储装置(例如存储器112)保存上述分发数据包。在下载完成后，OTA管理器110验证所下载的分发数据包的可靠性。然后，若验证的结果为“正常”，则OTA管理器110将软件更新状态(下载完成)通知给OTA中心500。进行该通知意味着下载成功。

若下载成功，则车辆执行安装。OTA管理器110向至少1个目标ECU(例如ECU121)请求该目标ECU的状态以及DTC(Diagnostic Trouble Code)的输出。OTA管理器110基于目标ECU的状态以及DTC来按每个目标ECU判断可否执行安装。然后，OTA管理器110向可执行安装的目标ECU转送新的软件(更新数据)。接收到更新数据的目标ECU执行该更新数据的安装(向非易失性存储器的写入)。

若从OTA管理器110向目标ECU的上述更新数据的转送完成，则目标ECU将转送完成通知发送至OTA管理器110。而且，接受到转送完成通知的OTA管理器110向目标ECU请求完全性验证。接受到该请求的目标ECU使用完全性验证数据(验证用数据)来进行验证，并将其验证结果向OTA管理器110发送。OTA管理器110保存每个目标ECU的验证结果(安装的完成/失败/中止)。若全部的目标ECU的完全性验证完成且全部的验证结果为“正常”，则OTA管理器110将软件更新状态(安装完成)通知给OTA中心500。进行该通知意味着安装成功。

若紧接着下载安装也成功，则车辆成为待激活状态。然后，若对车辆的启动开关150进行了断开操作，则OTA管理器110使HMI170显示规定的消息，来向用户请求表示“同意”与“拒绝”中的任一方的输入。而且，若进行了表示“同意”的输入，则OTA管理器110执行激活(所安装的软件的有效化)。在OTA管理器110的激活失败的情况下，OTA管理器110向OTA中心500请求软件的回滚。OTA中心500若从车辆接受到回滚的请求，则向该车辆分发回滚用的软件。由此，OTA管理器110能够使用该回滚用的软件来将激活失败的软件恢复(回滚)至原版本。另外，若用户进行了表示“拒绝”的输入，则OTA管理器110不执行激活而中止软件更新所涉及的处理，车辆系统被关断。

若OTA管理器110的激活成功，则OTA管理器110使HMI170显示软件更新的结果。然后，OTA管理器110将软件更新状态(软件更新完成)通知给OTA中心500。进行该通知意味着OTA软件更新成功。若进行了该通知，则车辆的控制系统被关断，成为IG断开。然后，若对车辆的启动开关150进行了接通操作，则车辆系统成为IG接通。由此，更新程序(新的版本的软件)在目标ECU启动。其中，被更新的软件并不局限于上述的自动驾驶控制程序那样的驾驶辅助系统的控制程序而是任意的。

这样，车辆100通过与OTA中心500通信，且使用统管软件的更新的OTA管理器110，能够进行基于OTA技术的软件的更新。然而，车辆200不具备OTA管理器110(不具有OTA访问功能)，无法利用OTA技术来进行软件的更新。在本实施方式中，通过对车辆200的用户所持有的移动终端附加OTA管理器110的功能，由此即便是不具备OTA管理器110的车辆200，也能够实现使用了OTA技术的软件的更新。

参照图1，车辆200的ECU210具备处理器211以及存储器212。处理器211例如包括CPU。存储器212例如包括闪存那样的非易失性存储器。ECU210例如可以是GW(Gateway)－ECU。车辆200具备通信装置290。ECU210通过通信装置290来与车辆外部的装置进行通信。通信装置290包括用于与用户终端300直接进行无线通信的通信I/F(接口)。通信装置290与用户终端300可以进行无线LAN、NFC或者Bluetooth(注册商标)那样的近距离通信。通信装置290可以与存在于车内或者车辆周边的范围内的用户终端300直接通信。在车辆200的停车中，车内或者车外的用户终端300与ECU210可以经由通信装置290相互进行信息的交换。另外，在车辆200的行驶中，车内的用户终端300与ECU210可以经由通信装置290相互进行信息的交换。

车辆200的构成与车辆100大致等同。在车辆200中，ECU彼此经由通信总线连接，例如构成为能够实现CAN通信。另外，ECU221相当于ECU121，ECU222相当于ECU122，驾驶装置230相当于驾驶装置130，ADS240相当于ADS140，启动开关250相当于启动开关150，HMI270相当于HMI170。

用户终端300构成为能够被用户携带。用户终端300是能够被车辆200的用户(车辆管理者)携带并操作的移动终端。在该实施方式中，作为用户终端300，采用具备触摸面板显示器(显示部)的智能手机。智能手机内置有计算机，具有扬声器功能。但并不局限于此，作为用户终端300，能够采用车辆200的用户可携带的任意的终端。例如，还能够采用笔记本电脑、平板终端、便携式游戏机、可穿戴设备(智能手表、智能眼镜、智能手套等)等作为用户终端300。

用户终端300具备处理器310、存储器320以及通信模块330。处理器310例如包括CPU。存储器320例如包括闪存那样的非易失性存储器。通信模块330包括用于与OTA中心500直接进行无线通信的通信I/F(接口)。另外，通信模块330还包括用于与车辆200直接进行无线通信的通信I/F。由此，车辆200与OTA中心500能够经由用户终端300实现数据的收授。通过用户终端300指定OTA中心500的地址来访问通信网络NW，能够实现车辆200与OTA中心500的经由用户终端300的数据的收授。

在用户终端300安装有用于利用OTA中心500所提供的服务的应用软件(以下，称为“移动应用”)。通过移动应用，用户终端300的识别信息(终端ID)被与车辆200的识别信息(车辆ID)建立关联登记于OTA中心500。用户终端300能够通过移动应用来与OTA中心500进行信息的交换。另外，用户终端300通过移动应用来起到与OTA管理器110同样的功能。

图3是表示在用户终端300中构成的功能模块的一个例子的图。这些功能模块是由处理器、存储器以及通信模块等构成的功能。另外，图4是简要地表示在本实施方式的车辆200执行的软件的更新处理的时序的一部分的图。在OTA中心500、用户终端300、车辆200(ECU210、221、222)中处理该时序。通过在各设备中由1个以上的处理器读入存储于1个以上的存储器的程序并执行来实现该处理。

在图3中，通信部31与OTA中心500(通信模块530)以及车辆200(通信装置290)进行通信。通信部31可以是通信模块330。构成同步处理部32取得包括车辆200的ECU210、221、222的信息的车辆构成信息，并向OTA中心500发送。

在图4中，若车辆200成为IG接通状态，则在步骤(以下，将步骤省略为“S”)31中，每当经过预先设定的时间、或在从构成同步处理部32接受到构成同步的请求的情况下，如上述那样，车辆200将包括车辆识别码(VIN)、ECU210、221、222的硬件信息、软件信息的车辆构成信息向用户终端300发送。构成同步处理部32若从车辆200取得了车辆构成信息，则将所取得的车辆构成信息向OTA中心500发送(S21)。

OTA中心500若接收到车辆构成信息，则更新管理信息(S11)。若管理信息的更新结束，则OTA中心500判定被应用于车辆200(ECU210、221、222)的更新用软件的有无(可应用的活动的有无)(S12)。若存在被应用于车辆200的活动(更新用软件)，则OTA中心500向用户终端300发送包括同意请求信号的活动信息(S13)。

用户终端300若从OTA中心500接收到活动信息(同意请求信号)，则在活动通知处理部33(参照图3)中使显示部34显示操作部(操作按钮)(S22)。图5是表示在用户终端300的触摸面板显示器340显示的显示画面的一个例子的图。其中，触摸面板显示器340相当于显示部34的一个例子。如图5所示，在触摸面板显示器340显示车辆软件的更新处理的消息和用于同意软件的更新处理的操作部。在图5中，“是”按钮341是用于同意下载的操作部(操作按钮)。

再次参照图4，若在触摸面板显示器340显示的“是”按钮341被用户操作，则软件的下载(软件的更新处理)被用户同意，用户终端300(活动通知处理部33)向OTA中心500发送分发数据包发送请求(S23)。若在触摸面板显示器340显示的“否”按钮342被用户操作，则不执行软件的下载(软件的更新处理)，本时序结束。此外，在触摸面板显示器340也可以显示用户终端300的蓄电池的蓄电量343。蓄电量343表示蓄电池的当前的蓄电量，例如可以显示用户终端300的蓄电池的SOC(State of Charge)。

OTA中心500若从用户终端300接收到分发数据包发送请求，则将分发数据包(更新用软件)向用户终端300发送(S14)。用户终端300若接收到从OTA中心500发送(分发)的分发数据包，则由第1取得部35(参照图3)取得。第1取得部35将分发数据包保存于存储器320，进行下载(S24)。若分发数据包的下载完成，则在进行了分发数据包的可靠性的验证等之后，用户终端300的安装处理部36(参照图3)向车辆200发送分发数据包(更新用软件(更新数据))，并且指示更新数据的安装的执行(S25)。在车辆200中，接收到更新数据的目标ECU执行该更新用软件的安装(向非易失性存储器的写入)(S32)。

在车辆200中，若更新用软件的安装完成，则目标ECU将完成通知向用户终端300发送(S33)。在安装完成后，若启动开关250被操作而成为IG断开状态，则车辆200将IG断开通知向用户终端300发送(S34)。

用户终端300若接收到IG断开通知，则在触摸面板显示器340(显示部34)显示操作部(操作按钮)(S26)。图6是表示在用户终端300的触摸面板显示器340显示的显示画面的一个例子的图。如图6所示，在触摸面板显示器340显示车辆软件的更新处理的消息和用于同意软件的有效化(激活)的操作部。在图6中，“是”按钮351是用于同意有效化的操作部(操作按钮)。

再次参照图4，若在触摸面板显示器340显示的“是”按钮351被用户操作，则软件的激活(软件的有效化处理)被用户同意，用户终端300的激活处理部37(参照图3)向车辆200发送激活指示(S27)。若在触摸面板显示器340显示的“否”按钮352被用户操作，则软件的更新处理中断，本时序结束。

车辆200(目标ECU)若从用户终端300接收到激活指示，则执行所安装的更新用软件的激活(有效化)(S35)。若激活成功，则车辆200(目标ECU)向用户终端300发送更新完成通知(S36)。

图7是表示通过用户终端300执行的安装中断处理的流程图。在执行了图4的时序的S25(分发数据包发送、安装指示)时开始该流程图。首先，在S41中，第2取得部(参照图3)取得目标ECU(安装更新用软件的ECU)的负载。目标ECU的负载例如可以是目标ECU的CPU使用率(CPU负载率)。经由通信装置290从各目标ECU向用户终端300发送CPU使用率。

在接着的S42中，判定目标ECU的负载(CPU使用率)是否为规定值α以上。规定值α是若在目标ECU的处理负载超过了该值的状态下执行安装、则会在目标ECU作为对象的设备的控制中产生不良状况的值，可以被预先设定。在目标ECU的负载小于规定值α的情况下(负载＜α)时，为否定判定而进入至S43。在负载为规定值α以上时(负载≥α)，为肯定判定而进入至S44。

在S43中，安装处理部36向车辆200发送分发数据包并且指示车辆200执行安装，并进入至S45。其中，在分发数据包的发送被中断的情况下，重启分发数据包的发送，并进入至S45。

在S44中，安装处理部36中断分发数据包的发送，指示车辆200(目标ECU)中断安装，并进入至S45。

在S45中，在目标ECU中判定安装是否完成了。在从车辆200(目标ECU)未接收到完成通知(S33)的情况下，为否定判定而返回至S41。在接收到完成通知(S33)时，为肯定判定而结束本次的例程。

其中，目标ECU的负载也可以不是CPU使用率，只要是与CPU使用率(CPU负载率)相关的参数即可。例如，在目标ECU是控制MG(电动发电机)的ECU的情况下，可以将MG的旋转速度作为ECU的负载。另外，在车辆200具备内燃机、目标ECU为发动机ECU的情况下，可以将发动机旋转速度作为ECU的负载。由于MG或内燃机的旋转速度越高，则ECU(CPU)的运算负载越高，所以在MG的旋转速度为规定值以上时，在发动机旋转速度为规定值以上时，可以在S42中做出肯定判定。该情况下，优选考虑用户终端300与车辆200之间的通信速度(考虑通信延迟)来设定规定值。

图8是表示由用户终端300执行的通信中断时处理的流程图。在执行了图4的时序的S25(分发数据包发送、安装指示)时开始该流程图。首先，在S51中，用户终端300的通信中断检测部39(参照图3)判定车辆200(通信装置290)与用户终端300(通信部31)的通信是否中断了。例如，在车辆200与用户终端300通过Bluetooth(注册商标)进行通信的情况下，当接收信号强度(RSSI：Received Signal Strength Indicator)为规定值以下时、当误码率(BER：Bit Error Rate)为规定值以上时等，可以判定为通信中断。在未产生通信中断的情况下，在S51中做出否定判定而进入至S52。在产生了通信中断的情况下，在S51中做出肯定判定而进入至S53，在将标志F设定为1之后进入至S56。

在S52中，判定标志F是否为1。在标志F为1的情况下，做出肯定判定而进入至S54，在将标志F设定为0之后进入至S55。在标志F为0的情况下，在S52中做出否定判定而进入至S56。

在S55中，版本信息请求部40(参照图3)请求车辆200发送被安装于目标ECU的软件的版本信息(将版本信息发送请求向目标ECU发送)，并进入至S56。其中，S55被处理是在产生了通信中断(标志F设定为1)之后通信已恢复(在S51中为否定判定)时。在S56中，判定用户终端300是否接收到更新完成通知。在未接收到更新完成通知(S36)时，在S56中做出否定判定，返回至S51。在接收到更新完成通知(S36)时，在S56中做出肯定判定，结束本次的例程。

根据该实施方式，用户终端300能够与车辆200以及OTA中心500通信。用户终端300的构成同步处理部32取得包括被搭载于车辆200的ECU的信息的车辆构成信息，向OTA中心500发送。由此，OTA中心500能够将被应用于车辆200的新的(更新用的)软件分发给用户终端300。用户终端300的第1取得部35取得被从OTA中心500分发的软件。然后，用户终端300经由通信部31将由第1取得部35取得的软件发送至车辆200。这样，车辆200能够经由用户终端300得到新的软件，能够实现基于OTA技术的软件的更新。

根据该实施方式，用户终端300的活动通知处理部33基于被从OTA中心500分发的同意请求信号(S13)来向用户请求同意ECU的软件的更新处理。由此，在用户同意了软件的更新的情况下，能够进行软件的更新。用户终端300的安装处理部36指示ECU执行发送至车辆200的软件的安装，激活处理部37指示ECU执行所安装的软件的激活。由于通过用户终端300的指示来执行被从OTA中心500分发的软件(新的软件)的安装以及激活，所以可以不设置软件的更新专用的OTA管理器110。

根据该实施方式，用户终端300的第2取得部38取得目标ECU的处理负载。而且，在目标ECU的负载为规定值以上而负载高时，用户终端300指示中断安装的执行。由此，由于在目标ECU为高负载而若执行安装则产生故障的情况下中断安装，所以能够进行可靠的安装。

根据该实施方式，OTA中心500若从用户终端300接收到车辆构成信息，则判断被应用于ECU的更新用软件的有无(S12)，在存在被应用于ECU的更新用软件的情况下，将同意请求信号发送至用户终端300(S13)。用户终端300若从OTA中心500接收到同意请求信号，则向用户请求同意ECU的软件的更新处理(S22)，若由用户做出了更新处理的同意，则将发送请求发送至上述OTA中心500(S23)。OTA中心500若从用户终端300接收到发送请求，则将更新用软件分发给用户终端300(S14)。用户终端300指示目标ECU执行发送至车辆200的更新用软件的安装(S25)，并指示目标ECU执行所安装的更新用软件的激活(S27)。由此，由于通过用户终端300的指示来执行从服务器分发的更新用软件(新的软件)的安装以及激活，所以可以不设置软件的更新专用的OTA管理器110。

根据该实施方式，在更新用软件的激活完成时，车辆200将更新完成通知发送至用户终端300(S36)。在从将更新用软件发送至车辆200起至接收到更新完成通知为止的期间，当车辆200与用户终端300的通信中断的情况下(在S51中为肯定判定)，在车辆200与用户终端300的通信的恢复时(在S52中为肯定判定)用户终端300请求车辆200发送被安装于目标ECU的软件的版本信息(S55)。在从将更新用软件发送至车辆200起至接收到更新完成通知为止的期间，若车辆200与用户终端300的通信中断，则存在软件的更新处理(安装或激活)未正常完成的可能性、更新处理中断的可能性。由于在车辆200与用户终端300的通信恢复时，用户终端300请求车辆200发送被安装于目标ECU的软件的版本信息，所以能够基于从车辆200发送出的软件的版本信息来判断是否正常地进行了软件的更新处理。

在上述实施方式中，在S22(图4)中，在用户终端300的触摸面板显示器340显示了车辆软件的更新处理的消息和用于同意软件的更新处理的操作部(参照图5)。然而，也可以在车辆200的HMI270显示同样的显示。图9是表示在HMI270的触摸面板显示器610显示的显示画面的一个例子的图。如图9所示，在触摸面板显示器610显示车辆软件的更新处理的消息和用于同意软件的更新处理的操作部。在图9中，“是”按钮611是用于同意下载的操作部(操作按钮)。若“是”按钮611被用户操作，则软件的下载(软件的更新处理)被用户同意，用户终端300向OTA中心500发送分发数据包发送请求。若在触摸面板显示器610显示的“否”按钮622被用户操作，则不执行软件的下载(软件的更新处理)，图4的时序结束。其中，在S26(图4)中，在用户终端300的触摸面板显示器340显示的用于进行软件的有效化(激活)的同意的操作部也同样可以显示于车辆200的HMI270。

此外，在上述说明中，在触摸面板显示器340显示各种信息，但显示器并不限定于具有触摸面板功能的结构，也可以是与显示器独立地设置有操作部的装置(PC等)。

车辆构成为可自动驾驶不是必须的。车辆也可以是BEV以外的xEV(电动车)。车辆可以是具备内燃机(例如汽油发动机、生物燃料发动机或者氢能发动机)的PHEV(插电混合动力车)或者HEV(混合动力车)，也可以是仅具备内燃机的车辆。车辆并不局限于4个轮的乘用车，也可以是巴士或者卡车，也可以是3个轮的xEV。车辆也可以具备飞行功能。车辆可以是被MaaS(Mobility as a Service)利用的车辆。车辆也可以是根据用户的使用目的而定制的多目的车辆。车辆也可以是移动店铺车辆、无人驾驶出租车、无人运输车(AGV)或者农业机械。车辆也可以是无人或者1人乘坐的小型BEV(例如最后一英里用的BEV、电动轮椅或者电动滑板车)。

应该认为本次公开的实施方式在全部的点上都是例示而非限制性的。本发明的范围不是上述的实施方式的说明而由本申请请求保护的范围示出，意在包括与本申请请求保护的范围等效的含义以及范围内的全部的变更。

Claims (7)

1.一种移动终端，其特征在于，包括：

构成同步处理部，构成为取得包括被搭载于车辆的电子控制单元亦即ECU的信息的车辆构成信息，并向服务器发送；

第1取得部，构成为取得被从所述服务器分发的软件；以及

通信部，构成为将由所述第1取得部取得的所述软件发送至所述车辆。

2.根据权利要求1所述的移动终端，其特征在于，还包括：

活动通知处理部，构成为基于被从所述服务器分发的同意请求信号来向用户请求同意所述ECU的软件的更新处理；

安装处理部，构成为指示所述ECU执行发送至所述车辆的所述软件的安装；以及

激活处理部，构成为指示所述ECU执行所安装的所述软件的激活。

3.根据权利要求2所述的移动终端，其特征在于，

还包括构成为取得所述ECU的负载的第2取得部，其中，

所述安装处理部构成为当由所述第2取得部取得的所述负载为规定值以上时，指示所述ECU中断所述安装的执行。

4.一种软件更新系统，构成为对ECU的软件进行更新，其特征在于，包括：

服务器，构成为分发所述软件；

车辆，搭载有所述ECU；以及

移动终端，构成为与所述服务器以及所述车辆通信，其中，

所述移动终端构成为执行如下处理：

从所述车辆取得包括所述ECU的信息的车辆构成信息；

将所取得的所述车辆构成信息向所述服务器发送；

取得被从所述服务器分发的更新用软件；以及

将所取得的所述更新用软件发送至所述车辆，

所述服务器构成为执行如下处理：

若从所述移动终端接收到所述车辆构成信息，则判断有无被应用于所述ECU的所述更新用软件，当存在被应用于所述ECU的所述更新用软件的情况下，将所述更新用软件分发给所述移动终端。

5.根据权利要求4所述的软件更新系统，其特征在于，

所述服务器构成为执行如下处理：

若从所述移动终端接收到所述车辆构成信息，则判断有无被应用于所述ECU的所述更新用软件，当存在被应用于所述ECU的所述更新用软件的情况下，将同意请求信号发送至所述移动终端，若从所述移动终端接收到发送请求，则将所述更新用软件分发给所述移动终端，

所述移动终端构成为还执行如下处理：

若从所述服务器接收到所述同意请求信号，则向用户请求同意所述ECU的软件的更新处理；

在由用户做出了所述更新处理的同意时，将所述发送请求发送至所述服务器；

指示所述ECU执行发送至所述车辆的所述更新用软件的安装；以及

指示所述ECU执行所安装的所述更新用软件的激活。

6.根据权利要求5所述的软件更新系统，其特征在于，

所述移动终端构成为取得所述ECU的负载，在所取得的所述负载为规定值以上时，指示所述ECU中断所述安装的执行。

7.根据权利要求5或6所述的软件更新系统，其特征在于，

所述车辆构成为在所述更新用软件的激活完成时，将更新完成通知发送至所述移动终端，

所述移动终端构成为当在从将所述更新用软件发送至所述车辆起至接收到所述更新完成通知为止的期间，所述车辆与所述移动终端的通信中断的情况下，在所述车辆与所述移动终端的所述通信恢复时，请求所述车辆发送被安装于所述ECU的软件的版本信息。