CN115016809A - 中心、更新管理方法、以及非暂时性存储介质 - Google Patents

Abstract

本发明涉及中心、更新管理方法、以及非暂时性存储介质。该中心构成为与OTA管理器进行通信，该OTA管理器构成为对被搭载于车辆的电子控制单元的软件更新进行控制，该中心包括：通信部，构成为从上述OTA管理器接收对上述电子控制单元的软件更新处理的进展状况进行表示的通知；和控制部，构成为基于上述通信部接收的上述通知来管理对上述车辆中的上述软件更新处理的处理状态进行表示的更新状态，并且，在上述通信部紧接着第1通知接收到与紧接着上述第1通知预定接收的第2通知不同的第3通知的情况下，基于上述第3通知来设定上述更新状态。

Description

中心、更新管理方法、以及非暂时性存储介质

技术领域

本公开涉及中心、更新管理方法以及非暂时性存储介质。

背景技术

在车辆搭载有用于控制车辆的动作的多个电子控制单元。电子控制单元具备处理器、如RAM那样的暂时性存储部、以及如闪速ROM那样的非易失性的存储部亦即非易失性存储器，通过处理器执行存储于非易失性存储器的软件来实现电子控制单元的控制功能。各电子控制单元所存储的软件能够改写，通过更新为更新的版本的软件，能够改善各电子控制单元的功能、追加新的车辆控制功能。

作为更新电子控制单元的软件的技术，公知有如下所述的OTA(Over The Air：空中下载)技术：将和车载网络连接的车载通信设备与因特网等通信网络通过无线连接，担负车辆的软件的更新处理的装置经由无线通信从具有服务器功能的中心下载软件，通过将下载的软件安装于电子控制单元来进行电子控制单元的软件更新、追加。例如，参照日本特开2004－326689。

在使用了该OTA技术的软件的更新处理中，在规定的时机(开始、完成等)从担负软件的更新处理的装置亦即OTA管理器向中心通知对软件更新处理的进展状况进行表示的信息，以便中心能够管理在车辆正实施的处理的状态。

在因某些原因而中心无法接收从OTA管理器发送的对软件更新处理的进展状况进行表示的通知的情况下，存在尽管软件的更新处理在车辆中正常推进、但在中心进行误认为软件的更新处理产生异常的判断的情况。若进行了这样的判断，则关于软件的更新处理会在车辆所管理的更新状态与中心所管理的更新状态之间产生偏差，存在对下次的软件的更新处理造成影响的可能性。

发明内容

本公开提供在无法正常地接收从OTA管理器发送的对软件更新处理的进展状况进行表示的通知的情况下能够抑制进行误认为软件更新处理产生异常的判断的中心、更新管理方法、非暂时性存储介质。

本发明的第一方式所涉及的中心构成为与OTA管理器进行通信，该OTA管理器构成为对被搭载于车辆的电子控制单元的软件更新进行控制。上述中心包括：通信部，构成为从上述OTA管理器接收表示上述电子控制单元的软件更新处理的进展状况的通知；和控制部，构成为基于上述通信部接收的上述通知来管理对上述车辆中的上述软件更新处理的处理状态进行表示的更新状态，在上述通信部紧接着第1通知接收到与紧接着上述第1通知预定接收的第2通知不同的第3通知的情况下，基于上述第3通知来设定上述更新状态。

本发明的第二方式所涉及的更新管理方法由中心的计算机执行，该中心具备处理器和存储器并构成为与OTA管理器进行通信，该OTA管理器构成为对被搭载于车辆的电子控制单元的软件更新进行控制。更新管理方法包括：从上述OTA管理器接收对上述电子控制单元的软件更新处理的进展状况进行表示的通知；和基于上述通知来管理对上述车辆中的上述软件更新处理的处理状态进行表示的更新状态。管理上述更新状态包括在紧接着第1通知接收到与紧接着上述第1通知预定接收的第2通知不同的第3通知的情况下，基于上述第3通知来设定上述更新状态。

本发明的第三方式所涉及的非暂时性存储介质存储有更新管理程序，该更新管理程序能够由中心的计算机执行，使上述计算机执行以下的功能，该中心具备处理器和存储器并构成为与OTA管理器进行通信，该OTA管理器对被搭载于车辆的电子控制单元的软件更新进行控制。上述功能包括：从上述OTA管理器接收对上述电子控制单元的软件更新处理的进展状况进行表示的通知；和基于上述通知来管理对上述车辆中的上述软件更新处理的处理状态进行表示的更新状态。管理上述更新状态包括在紧接着第1通知接收到与紧接着上述第1通知预定接收的第2通知不同的第3通知的情况下，基于上述第3通知来设定上述更新状态。

根据本公开的中心、更新管理方法、非暂时性存储介质等，在无法正常接收从OTA管理器发送的表示软件更新处理的进展状况的通知的情况下，能够抑制做出误认为软件更新处理产生了异常的判断。

附图说明

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

图1是表示包括一个实施方式所涉及的中心的网络系统的整体结构的框图。

图2是表示中心的简要结构的框图。

图3是中心的功能框图。

图4是表示OTA管理器的简要结构的框图。

图5是OTA管理器的功能框图。

图6A是在中心执行的更新状态管理处理的流程图。

图6B是在中心执行的更新状态管理处理的流程图。

图7是表示中心向OEM报告的与OTA相关的结果的一个例子的图。

具体实施方式

本公开的中心在软件的更新处理中，在能够以正确的顺序从OTA管理器接收对软件更新处理的进展状况进行表示的通知的期间，以规定的顺序逐个地推进更新状态，在无法以正确的顺序从OTA管理器接收表示软件更新处理的进展状况的通知时，设定基于最近从OTA管理器接收到的通知的更新状态。由此，能够抑制做出误认为软件更新处理产生异常的判断。以下，参照附图，对本公开的一个实施方式详细地进行说明。

＜实施方式＞

[结构]

图1是表示包括本公开的一个实施方式所涉及的中心的网络系统的整体结构的框图。图1所示的网络系统是用于对被搭载于车辆的多个电子控制单元40a～40d的软件进行更新的系统，具备位于车辆外的中心10和在车辆内构建的车载网络20。

(1)中心

中心10能够经由网络70与车载网络20所具备的后述的OTA管理器30通信，能够进行电子控制单元的更新数据的发送、表示软件更新处理的进展状况的通知的接收等通信，来管理与OTA管理器30连接的多个电子控制单元40a～40d的软件更新。该中心10具有作为所谓的服务器的功能。

图2是表示图1中的中心10的简要结构的框图。如图2所示，中心10具备CPU(Central Processing Unit)11、RAM(Random Access Memory)12、存储装置13以及通信装置14。存储装置13是具备硬盘驱动器(HDD)、固态驱动器(SSD)等可读写的存储介质的装置，存储用于执行软件的更新管理的程序、软件的更新管理所使用的信息、各电子控制单元的更新数据等。在中心10中，CPU11通过使用RAM12作为工作区域执行从存储装置13读出的程序，来执行与软件更新相关的规定的处理。CPU11的数量不局限于1个。通信装置14是用于经由网络70与OTA管理器30进行通信的装置。

图3是图2所示的中心10的功能框图。图3所示的中心10具备存储部16、通信部17以及控制部18。存储部16通过图2所示的存储装置13来实现。通信部17以及控制部18通过图2所示的CPU11使用RAM12执行存储于存储装置13的程序来实现。

存储部16存储与被搭载于车辆的1个以上电子控制单元的软件更新处理相关的信息。作为与软件更新处理相关的信息，存储部16按识别车辆的每个车辆识别信息(车辆的ID)来存储将表示能够在电子控制单元利用的软件的信息关联得到的更新管理信息、和电子控制单元的软件的更新数据。作为表示能够在电子控制单元利用的软件的信息，例如可定义多个电子控制单元的各软件的最新的版本信息的组合。另外，作为与软件更新处理相关的信息，存储部16存储对在车辆实施的软件的更新处理状态进行表示的更新状态。

通信部17能够从OTA管理器30接收软件的更新确认请求。更新确认请求例如是当在车辆中电源或者点火装置(IGN)被接通时从OTA管理器30向中心10发送的信息，是用于基于后述的车辆构成信息来向中心10请求确认是否存在电子控制单元的更新数据的信息。另外，通信部17能够接收来自OTA管理器30的发布数据包的发送请求(下载请求)。若接收到发布数据包的下载请求，则通信部17将包括在后述的控制部18生成的电子控制单元的软件的更新数据的发布数据包发送至OTA管理器30。

若通信部17从OTA管理器30接收到更新确认请求，则控制部18基于存储于存储部16的更新管理信息来针对被搭载于由更新确认请求所包括的车辆的ID确定的车辆的电子控制单元判定是否存在软件的更新数据。在判定为存在电子控制单元的软件的更新数据的情况下，若从OTA管理器30接收到发布数据包的下载请求，控制部18生成包括存储于存储部16的相应的更新数据的发布数据包。

(2)车载网络

车载网络20具备OTA管理器30、多个电子控制单元40a～40d以及通信模块50。OTA管理器30与通信模块50经由总线60a连接。OTA管理器30与电子控制单元40a及40b经由总线60b连接。OTA管理器30与电子控制单元40c及40d经由总线60c连接。

OTA管理器30能够经由总线60a以及通信模块50并通过网络70与中心10实现无线通信。另外，OTA管理器30能够经由总线60b～60c与电子控制单元40a～40d实现有线通信。该OTA管理器30管理OTA状态，是具有控制软件更新次序来实施成为更新对象的电子控制单元(以下称为“目标电子控制单元”)的软件更新的功能的装置，基于从中心10取得的更新数据来控制电子控制单元40a～40d中的目标电子控制单元的软件更新。也存在将OTA管理器30称为中央网关(CGW)的情况。

图4是表示图1中的OTA管理器30的简要结构的框图。如图4所示，OTA管理器30具备CPU31、RAM32、ROM(Read-Only Memory)33、存储装置34以及通信装置36。CPU31、RAM32、ROM33以及存储装置34构成微型计算机35。在OTA管理器30中，CPU31通过使用RAM32作为工作区域执行从ROM33读出的程序来执行与软件更新相关的规定的处理。通信装置36是用于经由图1所示的总线60a～60c与通信模块50以及电子控制单元40a～40d进行通信的装置。

图5是图4所示的OTA管理器30的功能框图。图5所示的OTA管理器30具备存储部37、通信部38、控制部39。存储部37通过图4所示的存储装置34来实现。通信部38以及控制部39通过图4所示的CPU31使用RAM32执行存储于ROM33的程序来实现。

存储部37存储与分别搭载于多个电子控制单元40a～40d的非易失性存储器的种类相关的信息(种类信息)等。该种类信息可以基于构成车载网络20的多个电子控制单元40a～40d的规格来预先创建，并在车辆的制造时储存于存储部37，也可以在软件的更新处理时，由后述的通信部38通过车载网络20内的通信来从目标电子控制单元取得。

通信部38例如以车辆的电源或者点火装置(IGN)被接通为契机来将软件的更新确认请求发送至中心10。另外，通信部38从中心10接收表示更新数据的有无的通知作为对于更新确认请求的响应。在存在电子控制单元的软件的更新数据的情况下，通信部38将发布数据包的下载请求发送至中心10，接收从中心10发送的发布数据包。另外，通信部38可以在软件的更新处理时通过通信来从目标电子控制单元取得非易失性存储器的种类信息。

控制部39基于对于通信部38接收到的更新确认请求的响应来判定有无电子控制单元的软件的更新数据。另外，在有软件的更新数据的情况下，控制部39进行通信部38从中心10接收到的发布数据包的真实性的校验、通过下载而储存于存储部37的1个以上更新数据向目标电子控制单元的转送。并且，控制部39使更新数据安装于目标电子控制单元，并在安装完成后进行指示以便使安装好的更新版的软件有效。

多个电子控制单元40a～40d是用于控制车辆的各部的动作的装置(ECU：Electronic Control Unit)。在图1中，例示了4个电子控制单元40a～40d，但电子控制单元的数量不特别限定。例如，用于在电子控制单元40a～40d的软件的更新处理时进行存在更新数据的显示、用于向车辆的用户或管理者请求对于软件更新的同意的同意请求画面的显示、以及软件更新的结果的显示等各种显示的显示装置(HMI)可以与OTA管理器30连接。作为显示装置，能够使用汽车导航系统等。另外，将电子控制单元与OTA管理器30连接的总线的数量也不特别限定。例如，上述的显示装置可以利用总线60a～60c以外的总线与OTA管理器30连接。

通信模块50是具有对中心10与车辆的通信进行控制的功能的单元，是用于将车载网络20与中心10连接的通信设备。通信模块50经由网络70与中心10无线连接，OTA管理器30经由通信模块50进行车辆的认证、更新数据的下载等。此外，通信模块50可以构成为包含于OTA管理器30。

[软件更新处理的概要]

OTA管理器30例如以车辆的电源或者点火装置被接通为契机来将软件的更新确认请求发送至中心10。更新确认请求包括用于识别车辆的车辆的ID、和车载网络20连接的电子控制单元40a～40d的硬件以及软件的版本等与电子控制单元的状态(系统构成)相关的信息亦即车辆构成信息。车辆构成信息能够通过从与车载网络20连接的电子控制单元40a～40d取得电子控制单元的识别编号(ECU＿ID)和电子控制单元的软件版本的识别编号(ECU＿Software＿ID)来创建。车辆的ID以及电子控制单元40a～40d的软件的版本为了通过与中心10按每个车辆ID保持的最新的软件的版本的比较来判定是否存在电子控制单元的软件的更新数据而使用。另外，OTA管理器30从中心10接收表示更新数据的有无的通知作为对于更新确认请求的响应。在有电子控制单元的软件的更新数据的情况下，OTA管理器30将发布数据包的下载请求发送至中心10，接收从中心10发送的发布数据包。发布数据包可以除了更新数据之外，还包括用于校验更新数据的真实性的校验用数据、更新数据的数量、安装顺序、软件更新时所使用的各种控制信息等。

OTA管理器30基于对于接收到的更新确认请求的来自中心10的响应来对是否存在电子控制单元的软件的更新数据进行判定。另外，OTA管理器30对从中心10接收并储存于存储装置13的发布数据包的真实性进行校验。另外，OTA管理器30将通过发布数据包下载了的1个以上更新数据转送至目标电子控制单元，使更新数据安装于目标电子控制单元。在安装完成后，OTA管理器30对于目标电子控制单元进行指示，以使安装了的更新版的软件有效。

在同意请求处理中，OTA管理器30使输出装置输出对于软件更新需要同意这一内容的通知、催促同意软件更新这一内容的输入的通知。作为输出装置，能够利用基于显示进行通知的显示装置、基于声音进行通知的声音输出装置等。例如，在同意请求处理中使用显示装置作为输出装置的情况下，OTA管理器30能够使显示装置显示用于要求同意软件更新的同意请求画面，在用户或者管理者同意的情况下使显示装置显示催促按下同意按钮等特定的输入操作的通知。另外，在同意请求处理中，OTA管理器30能够使显示装置显示通知为存在电子控制单元的软件的更新数据的语句、图标等，使显示装置显示软件更新处理的执行中的限制事项等。若从用户或者管理者受理到同意这一内容的输入，则OTA管理器30执行上述的安装以及激活的控制处理，更新目标电子控制单元的软件。

软件的更新处理由如下阶段构成：OTA管理器30从中心10下载更新数据的阶段(下载阶段)；OTA管理器30将下载的更新数据转送至目标电子控制单元并在目标电子控制单元的储存区域安装更新数据的阶段(安装阶段)；以及目标电子控制单元使安装好的更新版的软件有效化的阶段(激活阶段)。

下载是OTA管理器30接收从中心10通过发布数据包发送的用于更新电子控制单元的软件的更新数据并存储于存储装置34的处理。在下载阶段中，不仅包括下载的执行，还包括下载的可否执行判断、更新数据的校验等与下载相关的一系列处理的控制。

从中心10发送至OTA管理器30的更新数据可以包括电子控制单元的更新软件、压缩更新软件而得到的压缩数据、将更新软件或者压缩数据分割而得到的分割数据中的任一个。另外，更新数据可以包括目标电子控制单元的ECU＿ID(或者序列号)和更新前的电子控制单元的ECU＿Software＿ID。更新数据被作为上述的发布数据包下载，发布数据包中包括单个或者多个电子控制单元的更新数据。

安装是OTA管理器30基于从中心10下载的更新数据来向目标电子控制单元写入更新软件(更新版的程序)的处理。在安装阶段中，不仅包括安装的执行，还包括安装的可否执行判断、更新数据的转送以及更新软件的校验等与安装相关的一系列处理的控制。

在更新数据包括更新软件本身的情况下，在安装阶段中，OTA管理器30将更新数据(更新软件)转送至目标电子控制单元。另外，在更新数据包括更新软件的压缩数据、或者差分数据、或分割数据的情况下，可以由OTA管理器30向目标电子控制单元转送更新数据，且目标电子控制单元根据更新数据生成更新软件，也可以在OTA管理器30根据更新数据生成更新软件之后，将更新软件转送至目标电子控制单元。这里，更新软件的生成能够通过压缩数据的解压、差分数据或者分割数据的组合来进行。

更新软件的安装能够由目标电子控制单元基于来自OTA管理器30的安装请求来进行。或者，可以由接收到更新数据的目标电子控制单元自主地进行安装而不接受来自OTA管理器30的明确的指示。

激活是目标电子控制单元将安装了的更新软件有效化(激活)的处理。在激活阶段中，不仅包括激活的执行，还包括激活的可否执行判断、执行结果的校验等与激活相关的一系列控制。

更新软件的激活能够由目标电子控制单元基于来自OTA管理器30的激活请求来进行。或者，可以由接收到更新数据的目标电子控制单元在安装完成后自主地进行激活，而不接受来自OTA管理器30的明确的指示。

此外，软件的更新处理能够对于多个电子控制单元分别连续或并行地进行。

另外，本说明书中的“软件的更新处理”不仅包括连续地进行下载、安装以及激活的全部的处理，还包括仅进行下载、安装以及激活中的一部分的处理。

[处理]

接下来，进而参照图6A以及图6B，对在本实施方式的网络系统中执行的处理进行说明。图6A以及图6B是对由中心10执行的更新状态管理处理的步骤进行说明的流程图。图6A的处理与图6B的处理通过连接符X、Y、以及Z连接。

该图6A以及图6B所示的更新状态管理处理在存在对电子控制单元的软件进行更新的活动的情况下开始。

(步骤S601)

中心10对是否从OTA管理器30接收到通知进行判断。作为当活动存在时中心10从OTA管理器30接收的通知，能够例示(a)基于用户的指示的活动、下载、安装、激活的各同意结果；(b)下载、安装、激活的各执行前确认；(c)下载、安装、激活的各开始报告；(d)下载、安装、激活的各进展报告；(e)下载、安装、激活的各完成报告；以及(f)软件的更新完成报告等。这些通知并不被限定，可以省略这些通知的一部分，也可以追加其他通知。在该步骤S601中被判断的通知的接收是指最初的通知亦即活动的同意结果的接收、或者基于某个通知而设定了更新状态之后的新的通知的接收。在中心10从OTA管理器30接收到通知的情况下(步骤S601，是)，处理进入至步骤S602，在中心10未从OTA管理器30接收到通知的情况下(步骤S601，否)，处理进入至步骤S606。

(步骤S602)

中心10对从OTA管理器30接收到的通知是否是“软件的更新完成报告”进行判断。若接收到软件的更新完成报告，则中心10能够判断为软件的更新处理在车辆侧正常完成。在从OTA管理器30接收到的通知是软件的更新完成报告的情况下(步骤S602，是)，处理进入至步骤S609，在从OTA管理器30接收到的通知不是软件的更新完成报告的情况下(步骤S602，否)，处理进入至步骤S603。

(步骤S603)

中心10对本次从OTA管理器30接收到的通知亦即本次通知(第2通知或者第3通知)是否是紧接着上次从OTA管理器30接收到的通知亦即上次通知(第1通知)预定接收的通知进行判断。本次通知是否是紧接着上次通知预定接收的通知能够按照在软件的更新处理中预先决定的处理次序来判断。作为一个例子，紧接着“下载完成报告”的通知预定接收的通知成为“安装同意结果”的通知这一判断。在来自OTA管理器30的本次通知是紧接着上次通知预定接收的通知的情况下(在本次通知为第2通知的情况下)(步骤S603，是)，处理进入至步骤S604，在来自OTA管理器30的本次通知不是紧接着上次通知预定接收的通知的情况下(在本次通知为第3通知的情况下)(步骤S603，否)，处理进入至步骤S605。

(步骤S604)

中心10将自身管理的更新状态设定为使处理前进了1个的更新状态。更新状态的发展顺序能够预先决定。作为一个例子，在当前的更新状态为“安装开始准备”的情况下，只要能够准确地接收作为接下来要接收的预定的“安装开始报告”的通知，则更新状态被设定为该“安装开始准备”的向前1个的处理亦即“安装中”。若设定好更新状态，则处理进入至步骤S601。

(步骤S605)

中心10将自身管理的更新状态设定为基于从OTA管理器30接收到的本次通知的更新状态。即，视为中心10将上次通知～本次通知的通知全部接收到，将更新状态设定(变更)为基于本次通知的内容。作为一个例子，在当前的更新状态为“安装开始准备”的情况下，若果接收到不是接下来要接收的预定的“安装完成报告”的通知，则基于该本次通知将更新状态设定为“安装完成”。若设定好更新状态，则处理进入至步骤S601。

(步骤S606)

中心10对是否从OTA管理器30取得了车辆构成信息进行判断。以车辆的电源或者点火装置被接通为契机，通过从OTA管理器30发送的软件的更新确认请求来取得车辆构成信息。在从OTA管理器30取得了车辆构成信息的情况下(步骤S606，是)，处理进入至步骤S607，在未从OTA管理器30取得车辆构成信息的情况下(步骤S606，否)，处理进入至步骤S601。

(步骤S607)

中心10基于从OTA管理器30取得的车辆构成信息来对是否能够判断为从OTA管理器30未接收到“软件的更新完成报告”的通知的软件的更新处理正常地完成了进行判断。该判断通过在软件的更新处理正常完成的情况下目标电子控制单元所表示的软件版本是否与车辆构成信息所示的目标电子控制单元的软件版本一致来进行。在能够判断为软件的更新处理正常地完成了的情况下(步骤S607，是)，处理进入至步骤S609，在无法判断为软件的更新处理正常地完成了的情况下(步骤S607，否)，处理进入至步骤S608。

(步骤S608)

中心10将自身管理的更新状态设定成表示为软件的更新处理未完成的“更新处理未完成”。若设定好更新状态，则更新状态管理处理结束。

(步骤S609)

中心10将自身管理的更新状态设定成表示为软件的更新处理完成的“更新处理完成”。若设定好更新状态，则更新状态管理处理结束。

中心10也可以基于在上述步骤S608以及步骤S609中设定的“更新处理完成”以及“更新处理未完成”的更新状态来将与OTA相关的结果报告给整车制造商亦即OEM(OriginalEquipment Manufacturer)等。

图7表示中心10报告给OEM的与OTA相关的结果(显示画面)的一个例子。在图7的例子中，上图表示在市场流通的成为更新对象的全部车辆(更新对象总车辆)中的、允许OTA更新的(OTA有效)车辆与未允许OTA更新的(OTA无效)车辆的比率。下图针对允许OTA更新的车辆(OTA有效车辆)表示了软件的更新处理的实施比例。更新状态为“更新处理完成”的车辆包括在“更新完毕”内，更新状态为“更新处理未完成”的车辆包括在“未更新”内。

＜作用/效果＞

如以上那样，本公开的一个实施方式所涉及的中心10在软件的更新处理中，在能够以正确的顺序从OTA管理器30接收更新状态的通知的期间，按照规定的顺序逐个地推进更新状态，在无以正确的顺序从OTA管理器30接收更新状态的通知时，设定为基于最近从OTA管理器30接收到的通知(本次通知)的更新状态。由此，能够抑制中心10进行误认为软件的更新处理产生了异常的判断。

另外，本实施方式所涉及的中心10在软件的更新处理中，当无法接收最后的通知亦即软件的更新完成报告时，在下次被从车辆发送车辆构成信息的时机，基于该车辆构成信息对软件的更新处理是否正常完成了进行判断。由此，能够抑制中心10进行误认为软件的更新处理产生了异常的判断。

以上，对本公开技术的一个实施方式进行了说明，但本公开不仅能够理解为中心，还能够理解为具备处理器和存储器的中心所执行的更新管理方法、更新管理程序、或存储有更新管理程序的计算机可读取的非暂时性存储介质等。

本公开技术能够在用于对电子控制单元的软件进行更新的网络系统中利用。

Claims (9)

1.一种中心，构成为与OTA管理器进行通信，该OTA管理器构成为对被搭载于车辆的电子控制单元的软件更新进行控制，

所述中心的特征在于，包括：

通信部，构成为从所述OTA管理器接收对所述电子控制单元的软件更新处理的进展状况进行表示的通知；和

控制部，构成为基于所述通信部接收的所述通知来管理对所述车辆中的所述软件更新处理的处理状态进行表示的更新状态，

在所述通信部紧接着第1通知接收到与紧接着所述第1通知预定接收的第2通知不同的第3通知的情况下，基于所述第3通知来设定所述更新状态。

2.根据权利要求1所述的中心，其特征在于，

所述通信部接收的所述通知至少包括：在所述软件更新中被更新的软件的下载完成报告、所述软件的安装完成报告、所述软件的激活完成报告、以及所述软件的更新完成报告。

3.根据权利要求2所述的中心，其特征在于，

所述控制部构成为在所述通信部接收到所述软件的更新完成报告作为所述通知的情况下，设定表示为所述车辆的软件更新处理完成了的所述更新状态。

4.根据权利要求1或2所述的中心，其特征在于，

所述通信部构成为在无法接收所述第2通知以及所述第3通知中的任一个通知的情况下，从所述OTA管理器接收表示所述电子控制单元的状态的信息，

所述控制部构成为基于所述信息来对所述软件更新处理是否正常完成了进行判断。

5.根据权利要求4所述的中心，其特征在于，

所述通信部无法接收所述第2通知以及所述第3通知中的任一个通知的情况下的所述第2通知至少包括在所述软件更新中被更新的软件的下载同意结果、所述软件的安装同意结果、以及所述软件的激活同意结果。

6.根据权利要求1所述的中心，其特征在于，

在所述通信部紧接着所述第1通知接收到所述第3通知的情况下，视为接收到所述第1通知～所述第3通知的全部通知。

7.根据权利要求1所述的中心，其特征在于，

在所述通信部紧接着所述第1通知接收到所述第2通知的情况下，所述控制部将所述更新状态设定为使所述软件更新处理前进了1个的所述更新状态。

8.一种更新管理方法，由中心的计算机执行，该中心具备处理器和存储器并构成为与OTA管理器进行通信，该OTA管理器构成为对被搭载于车辆的电子控制单元的软件更新进行控制，

所述更新管理方法的特征在于，包括：

从所述OTA管理器接收对所述电子控制单元的软件更新处理的进展状况进行表示的通知；和

基于所述通知来管理对所述车辆中的所述软件更新处理的处理状态进行表示的更新状态，

其中，

管理所述更新状态包括在紧接着第1通知接收到与紧接着所述第1通知预定接收的第2通知不同的第3通知的情况下，基于所述第3通知来设定所述更新状态。

9.一种非暂时性存储介质，存储有更新管理程序，该更新管理程序能够由中心的计算机执行而使所述计算机执行以下的功能，该中心具备处理器和存储器并构成为与OTA管理器进行通信，该OTA管理器构成为对被搭载于车辆的电子控制单元的软件更新进行控制，

所述非暂时性存储介质的特征在于，

所述功能包括：

从所述OTA管理器接收对所述电子控制单元的软件更新处理的进展状况进行表示的通知；和

基于所述通知来管理对所述车辆中的所述软件更新处理的处理状态进行表示的更新状态，

其中，

管理所述更新状态包括在紧接着第1通知接收到与紧接着所述第1通知预定接收的第2通知不同的第3通知的情况下，基于所述第3通知来设定所述更新状态。

Images