中心、管理方法以及非暂时性存储介质与流程

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


背景技术：

2.在车辆搭载有用于控制车辆的动作的多个ecu(电子控制单元)。ecu具备处理器、ram那样的暂时性的存储部、以及闪速rom那样的非易失性的存储部，通过处理器执行存储于非易失性的存储部的软件来实现ecu的控制功能。各ecu所存储的软件能够重写，通过更新为更新的版本的软件，能够改善各ecu的功能、追加新的车辆控制功能。
3.作为更新ecu的软件的技术，公知有一种通过将与车载网络连接的车载通信设备和因特网等通信网络无线连接、经由无线通信从ota中心(存在简称为“中心”的情况)下载软件并安装所下载的软件来进行ecu的程序更新、追加的ota(over the air：空中下载)技术(例如参照日本特开2004－326689)。
4.在将进行软件更新的事件亦即活动登记至服务器之后，以车辆向ota中心请求了确认更新数据的有无为契机来进行基于ota的软件的更新。在存在活动的情况下，车辆通过依次进行更新数据的下载、更新数据的安装以及更新版的软件的激活来对更新对象的ecu亦即目标ecu的软件进行更新。
5.在车辆的ecu被更换(部件更换)了的情况下，有时安装于更换后的ecu的软件的版本与安装于更换前的ecu的软件的版本不同。有时搭载于车辆的多个ecu的软件间的版本的组合中存在车辆有可能不恰当地动作的组合(不匹配的版本组合)，在ecu被更换而成为不匹配的版本组合的情况下需要进行应对。


技术实现要素：

6.本公开提供能够在ecu的更换前后使安装于ecu的软件的版本相同的中心、管理方法以及非暂时性存储介质。
7.本公开的第1方式所涉及的中心构成为经由网络与空中下载(ota：over-the-air)管理器进行通信，该ota管理器构成为控制被搭载于车辆的多个电子控制单元的软件更新。上述中心包括：通信部，构成为从上述ota管理器接收表示被安装于上述多个电子控制单元的软件的版本的识别信息；存储部，存储在适当与否判定中使用的适当与否判定信息，该适当与否判定对被安装于上述多个电子控制单元的软件的版本是否是应该安装的软件的版本亦即安装管理版本进行判定；判定部，构成为基于上述识别信息以及上述适当与否判定信息来进行上述适当与否判定；以及控制部，构成为通过与上述ota管理器进行通信来对由上述判定部判定为软件的版本不是上述安装管理版本的至少一个电子控制单元进行复原控制，该复原控制用于将软件的版本返回至上述安装管理版本。
8.本公开的第2方式所涉及的管理方法由具备处理器、存储器以及构成为经由网络与空中下载(ota：over-the-air)管理器进行通信的通信装置的计算机执行，该ota管理器构成为控制被搭载于车辆的多个电子控制单元的软件更新。上述管理方法包括：从上述ota
管理器接收表示被安装于上述多个电子控制单元的软件的版本的识别信息；存储在适当与否判定中使用的适当与否判定信息，该适当与否判定对被安装于上述多个电子控制单元的软件的版本是否是应该安装的软件的版本亦即安装管理版本进行判定；基于上述识别信息以及上述适当与否判定信息来进行上述适当与否判定；以及通过与上述ota管理器进行通信来对通过上述适当与否判定而判定为软件的版本不是上述安装管理版本的至少一个电子控制单元进行复原控制，该复原控制用于将软件的版本返回至上述安装管理版本。
9.本公开的第3方式所涉及的非暂时性存储介质存储有能够由具备处理器、存储器以及能够经由网络与空中下载(ota：over-the-air)管理器进行通信的通信装置的计算机执行且使上述计算机执行以下的功能的管理程序，该ota管理器控制被搭载于车辆的多个电子控制单元的软件更新。上述功能包括：从上述ota管理器接收表示被安装于上述多个电子控制单元的软件的版本的识别信息；存储在适当与否判定中使用的适当与否判定信息，该适当与否判定对被安装于上述多个电子控制单元的软件的版本是否是应该安装的软件的版本亦即安装管理版本进行判定；基于上述识别信息以及上述适当与否判定信息来进行上述适当与否判定；以及通过与上述ota管理器进行通信来对通过上述适当与否判定而判定为软件的版本不是上述安装管理版本的至少一个电子控制单元进行复原控制，该复原控制用于将软件的版本返回至上述安装管理版本。
10.根据本公开，能够提供可在ecu的更换前后使被安装于ecu的软件的版本相同的中心、管理方法以及非暂时性存储介质等。
附图说明
11.以下，参照附图对本发明的示例性实施例的特征、优点、技术及工业重要性进行说明，在附图中相同的附图标记表示相同的构成要素，其中：
12.图1是表示第1实施方式所涉及的网络系统的整体结构的一个例子的框图。
13.图2是表示图1所示的ota中心的简要结构的一个例子的框图。
14.图3是表示图1所示的ota管理器的简要结构的一个例子的框图。
15.图4是表示图1所示的ecu的简要结构的例子的框图。
16.图5是表示图1所示的ota中心的一个例子的功能框图。
17.图6是表示图1所示的ota管理器的一个例子的功能框图。
18.图7是表示第1实施方式所涉及的ota管理器执行的控制处理的一个例子的流程图。
19.图8是用于对预先存储于图5所示的ota中心的匹配构成信息的一个例子进行说明的图。
20.图9是用于对存储于图5所示的ota中心的历史记录信息的一个例子进行说明的图。
21.图10是用于对存储于图5所示的ota中心的历史记录信息的一个例子进行说明的图。
22.图11是表示图7所示的恢复(rollback)处理的一个例子的流程图。
23.图12是表示第2实施方式所涉及的ota管理器执行的控制处理的一个例子的流程图。
具体实施方式
24.(第1实施方式)
25.图1是表示第1实施方式所涉及的网络系统的整体结构的一个例子的框图。图2是表示图1所示的ota中心的简要结构的一个例子的框图。图3是表示图1所示的ota管理器(master)的简要结构的一个例子的框图。图4是表示图1所示的ecu的简要结构的例子的框图。
26.图1所示的网络系统是用于对被搭载于车辆的多个ecu(electronic control unit：电子控制单元)13a～13d的软件进行更新的系统，具备ota中心(例如服务器；存在简称为“中心”的情况)1和被搭载于车辆的车载网络2。
27.ota中心1能够经由因特网等通信网络5与搭载于车辆的ota管理器11通过无线等进行通信，对搭载于车辆的ecu13a～13d的软件更新进行管理。
28.如图2所示，ota中心1具备cpu21、ram22、存储装置23以及通信装置24。存储装置23具备硬盘、ssd等可读写的存储介质，存储用于执行软件的更新管理的程序、更新管理所使用的信息以及ecu的更新数据。cpu21通过使用ram22作为作业区域而执行从存储装置23读出的程序，来执行控制处理。通信装置24经由通信网络5与ota管理器11进行通信。
29.如图1所示，车载网络2具备ota管理器11、通信模块12、多个ecu13a～13d以及hmi(human machine interface；例如能够实现输入操作的汽车导航系统的显示装置)14。ota管理器11经由总线15a与通信模块12连接，经由总线15b与ecu13a以及13b连接，经由总线15c与ecu13c以及13d连接，经由总线15d与hmi14连接。ota管理器11能够经由通信模块12与ota中心1实现无线通信。ota管理器11基于从ota中心1取得的更新数据来控制ecu13a～13d中的软件为更新对象的ecu(存在称为“目标ecu”的情况)的软件更新。通信模块12是将车载网络2与ota中心1连接的通信设备。ecu13a～13d控制车辆的各部的动作。在ecu13a～13d的软件的更新处理时，为了进行存在更新数据的显示、用于向用户、管理者请求对于软件更新的同意的同意请求画面的显示、更新结果的显示等各种显示而使用hmi14。此外，在图1中例示了4个ecu13a～13d，但ecu的数量并不限定。
30.如图4所示，ecu13(13a～13d)具备cpu41、ram42、非易失性存储器43以及通信装置45。cpu41通过使用ram42作为作业区域而执行从非易失性存储器43(数据储存区域44(44a、44b、44c))读出的软件(程序)、另外使用通信装置45而根据需要经由总线与其他设备通信，来实现ecu13的功能。
31.这里，ecu13存在具有用于储存软件的1个数据储存区域(库)44a的类型的单库(single-bank)存储器ecu(图4左侧的框图)和具有用于储存软件的2个数据储存区域(库)44b以及44c的类型的双库(double-bank)存储器ecu(图4右侧的框图)这两个种类。有时在ecu13的数据储存区域44除了储存用于实现ecu的功能的软件之外，还储存版本信息或参数数据、启动用的启动程序、软件更新用的程序等。在单库存储器ecu中，通过在数据储存区域44a安装更新数据并激活(有效化)，来对ecu的软件产生影响。另一方面，在双库存储器ecu中，将2个数据储存区域(44b、44c)中的任一方作为读出对象的储存区域(运用面)，执行被储存于读出对象的储存区域的软件。在不是读出对象的另一方的储存区域(非运用面)，能够在读出对象的储存区域(运用面)的程序的执行过程中在后台写入更新数据。通过在软件更新处理中的激活时切换由cpu41执行的程序的读出对象的储存区域，能够将更新版的软
件激活(有效化)。在单库存储器ecu以及双库存储器ecu中，软件的激活完成而ecu能够利用该软件动作的状态可称为该软件被安装于ecu的状态。
32.其中，在本公开中，双库存储器ecu还包括：具备将非易失性存储器所具有的1个面的数据储存区域虚拟地划分为2个面、能够在执行一个面的程序的过程中向另一个面写入程序的被称为“单面挂起存储器(one-bank suspended memory)”的结构的存储器的ecu；和除了具有1个面的数据储存区域的非易失性存储器之外还具备具有1个面的数据储存区域的扩展非易失性存储器并能够将这2个非易失性存储器作为运用面以及非运用面使用的ecu。
33.如图3所示，ota管理器11具备微型计算机35和通信装置36，该微型计算机35具备cpu31、ram32、rom33以及存储装置34。cpu31通过使用ram32作为作业区域而执行从rom33读出的程序来执行控制处理。通信装置36经由图1所示的总线15a～15d与通信模块12、ecu13a～13d、hmi14进行通信。
34.这里，软件的更新处理由从ota中心1下载更新数据的阶段、将下载好的更新数据转送至作为更新对象的目标ecu并在目标ecu的存储区域安装更新数据的阶段、以及将在目标ecu中安装了的更新版的软件有效化的激活的阶段构成。
35.下载是接收从ota中心1发送的用于更新ecu的软件的更新数据并存储于存储装置34的处理。下载的阶段不仅包括更新数据的接收，还包括下载的可否执行判定、更新数据的校验等与下载相关的一系列处理的控制。安装是基于下载好的更新数据来向作为更新对象的目标ecu的非易失性存储器写入更新版的程序(更新软件)的处理。安装的阶段不仅包括安装的执行，还包括安装的可否执行判定、更新数据的转送以及更新版的程序的校验等与安装相关的一系列处理的控制。激活是将安装好的更新版的程序激活(有效化)的处理。激活的阶段不仅包括激活的执行，还包括激活的可否执行判定、执行结果的校验等与激活相关的一系列处理的控制。
36.从ota中心1发送至ota管理器11的更新数据可以包括ecu的更新软件、将更新软件压缩而得的压缩数据、将更新软件或者压缩数据分割而得的分割数据中的任一个。另外，更新数据可以包括对作为更新对象的目标ecu进行识别的识别符(ecuid)和对更新前的软件进行识别的识别符(ecu软件id)。更新数据被作为发布数据包(distribution package)下载，但发布数据包包括单个或者多个ecu的更新数据。
37.在更新数据包括更新软件本身的情况下，在安装的阶段中，ota管理器11将更新数据(即，更新软件)转送至目标ecu。另外，在更新数据包括更新软件的压缩数据、差分数据或分割数据的情况下，ota管理器11可以向目标ecu转送更新数据，由目标ecu根据更新数据生成更新软件，也可以在ota管理器11根据更新数据生成更新软件之后，将更新软件转送至目标ecu。这里，更新软件的生成能够通过压缩数据的解压、差分数据或者分割数据的组装来进行。
38.更新软件的安装能够由目标ecu基于来自ota管理器11的安装请求来进行。或者，接收到更新数据的目标ecu可以自主地进行安装而不接受来自ota管理器11的明确的指示。
39.更新软件的激活能够由目标ecu基于来自ota管理器11的激活请求来进行。或者，接收到更新数据的目标ecu可以自主地进行激活而不接受来自ota管理器11的明确的指示。
40.图5是表示图1所示的ota中心1的功能框图的一个例子。如图5所示，ota中心1具备
存储部26、通信部27、判定部28以及控制部29。通信部27、判定部28以及控制部29通过图2所示的cpu21使用ram22执行存储于存储装置23的程序来实现。存储部26由图2所示的存储装置23实现。
41.图6是图1所示的ota管理器11的功能框图的一个例子。如图6所示，ota管理器11具备存储部37、通信部38以及控制部39。通信部38以及控制部39通过图3所示的cpu31使用ram32执行存储于rom33的程序来实现。存储部37由图3所示的存储装置34实现。
42.图7是表示本实施方式所涉及的ota中心1执行的控制处理的一个例子的流程图。以下，按照图7所示的流程图对本实施方式所涉及的控制处理进行说明。
43.通过通信部27接收从ota管理器11发送出的车辆构成信息而开始图7所示的处理。
44.这里，若规定的条件成立(典型的是检测到车辆的点火装置被接通)，则搭载于车辆的ota管理器11从车辆的全部的ecu分别取得能够识别ecu的种类的ecuid和能够识别软件(存在称为“sw”的情况)的种类以及版本的ecu软件id。而且，ota管理器11创建包括所取得的ecuid及ecu软件id与能够识别车辆的vin(vehicle identification number；车辆识别码)的车辆构成信息，并发送至ota中心1。通过该处理，由于例如每当点火装置被接通时，便由ota管理器11创建车辆构成信息并发送至ota中心1，所以ota中心1能够针对各车辆的ecu掌握硬件结构以及软件结构。
45.在图7的步骤s1中，控制部29从由通信部27接收到的车辆构成信息取得vin以及ecu软件id(识别信息)。然后，处理移至步骤s2。
46.在步骤s2中，针对被搭载于在步骤s1中取得的vin所表示的车辆的ecu，判定部28判定软件的版本是否不适当地变化。以下，具体进行说明。
47.在存储部26中，针对各车辆存储有表示由ota中心1作为安装于ecu的软件而管理的软件的版本(以下存在称为“安装管理版本”的情况)的安装管理版本信息(适当与否判定信息)。换言之，安装管理版本信息是表示应该安装于ecu的软件的版本(安装管理版本)的信息。安装管理版本信息将使用图9而具体在后面叙述，例如在vin为1001的车辆(搭载有ecu1～4的车辆)中，是表示为在ecu1安装有ecu1用的版本为2.2的软件、在ecu2安装有ecu2用的版本为2.4的软件、在ecu3安装有ecu3用的版本为2.2的软件、在ecu4安装有ecu4用的版本为2.5的软件的信息。另外，安装管理版本信息被适当地更新。例如，在ota管理器11基于从ota中心1发送的软件的更新数据来进行更新控制而ecu的软件(版本升级)被更新、并从ota管理器11向ota中心1进行了更新完成的通知的情况下，利用更新后的软件的版本来更新安装管理版本信息。
48.在步骤s2中，针对被搭载于在步骤s1中取得的vin所表示的车辆的ecu，判定部28分别对在步骤s1中取得的ecu软件id(识别信息)所表示的软件的版本与存储于存储部26的安装管理版本信息所表示的安装管理版本进行比较。而且，在ecu软件id所表示的软件的版本与安装管理版本信息所表示的安装管理版本不一致的情况下，判定部28判定为软件的版本不适当地变化。这里，在搭载于车辆的ecu被更换了(部件更换)的情况下，如上述那样ecu软件id所表示的软件的版本与安装管理版本信息所表示的安装管理版本不一致的情况较多，该情况下，判定部28判定为软件的版本不适当地变化。然后，处理移至步骤s3。
49.在步骤s3中，当在步骤s2中判定为软件的版本不适当地变化(存在软件的版本的不适当变化)的情况下，控制部29使处理进入至步骤4，在并非如此的情况下结束图7的处
理。
50.在步骤s4中，针对被搭载于在步骤s1中取得的vin所表示的车辆的多个ecu，判定部28判定软件的版本间的匹配性(版本的组合的适当性)。以下，具体进行说明。
51.图8是用于说明对被安装在搭载于车辆的多个ecu的软件所匹配的(适当的)全部的版本组合进行了定义的匹配构成信息的图。如图8所示，例如在vin为1001的车辆(搭载有ecu1～4的车辆)所涉及的匹配构成信息中定义有被安装于ecu1～4的软件所匹配的(适当的)全部的版本组合。换言之，匹配构成信息中不存在的软件的版本组合是不匹配的版本组合，可称为不适当的版本组合。在是不匹配的版本组合的情况下，存在ecu不适当地动作的可能性，存在车辆不适当地动作的可能性。
52.在步骤s4中，针对被搭载于在步骤s1中取得的vin所表示的车辆的多个ecu，判定部28对在步骤s1中取得的ecu软件id所表示的软件的版本的组合是否与预先存储于存储部26的匹配构成信息所表示的软件的版本组合中的任一个一致进行判定。而且，在判定为与任一个一致的情况下，判定部28判定为存在软件的版本间的匹配性，在判定为与任一个均不一致的情况下，判定部28判定为不存在软件的版本间的匹配性(即，判定为不匹配)。然后，处理移至步骤s5。
53.在步骤s5中，控制部29将在步骤s1中取得的ecu软件id所表示的软件的版本的历史记录写入至存储于存储部26的软件版本历史记录信息(以下，存在简称为“历史记录信息”的情况)。以下，具体进行说明。
54.图9是用于对软件版本历史记录信息进行说明的图。如图9所示，例如在vin为1001的车辆(搭载有ecu1～4的车辆)所涉及的历史记录信息中写入有被安装于ecu1～4的软件的版本历史记录。
55.在步骤s5中，控制部29例如写入在步骤s1中取得的ecu软件id所表示的软件的版本(ecu1的sw版本2.2、ecu2的sw版本2.5、ecu3的sw版本1.5、以及ecu4的sw版本2.5)作为图9所示的历史记录信息的历史记录no.12。
56.另外，在步骤s5中，当在步骤s4中判定为不存在软件的版本间的匹配性的情况下，控制部29对历史记录信息所表示的历史记录附加表示为不存在匹配性(不匹配)的信息(例如基于标志的信息)。在图9的例子中，由于历史记录no.12的软件的版本组合不存在于图8的匹配构成信息而不匹配，所以在历史记录no.12的“匹配判定”的列中附加有表示为不匹配的信息(
×
标记)。另外，在骤s5中，当在步骤s4中判定为存在软件的版本间的匹配性的情况下，控制部29在历史记录信息所表示的历史记录附加表示为存在匹配性的信息。在图9的例子中，由于历史记录no.1～11的软件的版本组合存在于图8的匹配构成信息而匹配，所以在历史记录no.1～11的“匹配判定”的列附加有表示为匹配的信息(〇标记)。
57.相对于图9的历史记录信息，图10表示了历史记录no.12的ecu3的软件版本为“2.3”的情况。在图10的情况下，由于历史记录no.12的软件的版本组合与图8所示的匹配构成信息的no.36所表示的软件的版本组合一致，所以是匹配的版本组合。因此，在图10的例子中，在历史记录no.12的“匹配判定”的列中附加有表示为是匹配的版本组合(适当的版本组合)的信息(〇标记)。
58.其中，在本实施方式中，控制部29在历史记录信息中附加(使之包括)对作为安装于ecu的软件而管理的软件的版本(安装管理版本)进行表示的安装管理版本信息，另外，适
当地更新安装管理版本信息。在图9以及图10的例子中，通过在历史记录no.11的软件的版本组合(各ecu的软件的版本)中附加表示为是安装管理版本的信息(〇标记)，来将安装管理版本信息附加于历史记录信息。这样一来，在步骤s2的sw版本不适当变化判定的处理中使用的安装管理版本信息被存储于存储部26。
59.在步骤s6中，当在步骤s4中判定为不存在软件的版本间的匹配性(即，不匹配)的情况下，控制部29使处理进入至步骤s7，当在步骤s4中判定为存在匹配性的情况下，结束图7的处理。其中，当在步骤s4判定为存在匹配性而结束图7的处理的情况下，控制部29将判定为存在匹配性的软件的版本组合设定为安装管理版本来更新安装管理版本信息。在图10的例子中，更新为附加于历史记录no.11的软件的版本组合的表示为是安装管理版本的信息(〇标记)被删除、而该信息(〇标记)被附加于历史记录no.12的软件的版本组合的状态。
60.在步骤s7中，控制部29使用历史记录信息来确定最近的软件的版本匹配构成。在图9的例子中，控制部29能够将历史记录no.11的软件的版本组合确定为最近的软件的版本匹配构成。然后，处理移至步骤s8。
61.在步骤s8中，控制部29确定成为返回软件的版本的恢复处理(复原处理)的执行对象的软件，以便安装于ecu的软件的版本组合返回至在步骤s7中确定出的最近的软件的版本匹配构成。在图9的例子中，控制部29将ecu2以及ecu3的软件确定为成为恢复处理(复原处理)的执行对象的软件。然后，处理移至步骤s9。
62.在步骤s9中，控制部29进行将安装于ecu的软件的版本返回至以前的版本的恢复处理。
63.图11是表示步骤s9的恢复处理的一个例子的流程图。在图11的步骤s11中，控制部29对于在步骤s8中确定出的恢复处理的执行对象的软件中的1个决定用于使版本恢复的数据(恢复数据)以及恢复指示，以便返回至在步骤s7中确定出的最近的软件的版本匹配构成。然后，处理移至步骤s12。
64.在步骤s12中，控制部29判定是否对在步骤s8中确定出的全部的恢复对象的软件进行了步骤s11的决定。在步骤s12中的判定为“是”的情况下，处理移至步骤s13，在该判定为“否”的情况下，处理返回至步骤s11。由此，在步骤s8中确定出的全部的恢复对象的软件的版本被恢复(复原)。
65.在步骤s13中，控制部29将在步骤s11中决定出的恢复数据以及恢复指示通过通信部27发送至ota管理器11。然后，图11的恢复处理结束，图7的处理也结束。
66.其中，若图7的步骤s9的恢复处理结束而恢复对象的软件的版本的恢复完成，则ota管理器11将恢复完成通知发送至ota中心1。ota中心1(控制部29)若接收到恢复完成通知，则将在步骤s7中确定出的最近的软件的版本匹配构成(即，恢复后的软件的版本组合)作为最新的历史记录写入至历史记录信息。此时，ota中心1(控制部29)在写入的最新的历史记录中附加表示为存在版本的匹配性的信息。另外，ota中心1(控制部29)以写入的最新的历史记录所表示的软件的版本组合成为安装管理版本的方式更新安装管理版本信息。在图9的例子中，与历史记录no.11相同的内容的信息被作为最新的历史记录no.13写入至历史记录信息，历史记录no.11的“安装管理版本”的列的〇标记被删除。
67.(第2实施方式)
68.图12是表示第2实施方式所涉及的ota中心1执行的控制处理的一个例子的流程
图。图12的流程图是对于第1实施方式所涉及的图7的流程图将步骤s7以及s8的处理置换为步骤s71的处理的图。在第2实施方式中，当软件的版本不匹配的情况下(在步骤s6中为“是”的情况下)，不像第1实施方式那样进行确定最近的软件的版本匹配构成并返回至该版本结构的处理，而进行返回至安装管理版本信息所表示的安装管理版本(作为安装于ecu的软件而由ota中心1管理的软件的版本)的处理。其中，以下主要对与第1实施方式的处理不同的部分进行说明。
69.当在图12的步骤s6中判定为“是”的情况下，在步骤s71中，控制部29针对被搭载于在步骤s1中取得的vin所表示的车辆的ecu决定为恢复到不适当变化前的软件的版本。具体而言，针对被搭载于在步骤s1中取得的vin所表示的车辆的ecu，控制部29参照存储于存储部26的安装管理版本信息所表示的安装管理版本来决定为将软件的版本恢复(复原)为安装管理版本。在图9的例子中，控制部29决定为恢复成作为安装管理版本的历史记录no.11的软件的版本组合。然后，处置移至步骤s9，恢复对象的软件的版本被恢复(复原)，恢复为作为安装管理版本的历史记录no.11的软件的版本组合。
70.如以上使用图7以及图12等说明那样，在因ecu的更换(部件更换)而导致ecu的软件的版本不适当地切换的情况下，第1以及第2实施方式所涉及的ota中心1能够将不适当地切换了的ecu的软件复原为安装管理版本。由此，能够在ecu更换(部件更换)的前后保证软件的版本相同，能够在ecu更换后返回至适当的软件的版本。
71.这里，在部件更换后的ecu是使用图4的右侧框图说明的双库存储器ecu的情况下，不清楚在不是软件的读出对象的数据储存区域(非运用面)储存有什么样的软件(软件的版本)(另外，也存在在非运用面未储存软件的情况)。因此，即便在部件更换后的ecu是双库存储器ecu的情况下，也同样需要如上所述那样通过ota中心1的控制来复原成安装管理版本。
72.另外，如以上使用图7以及图12等说明那样，第1以及第2实施方式所涉及的ota中心1能够从ota管理器11取得ecu软件id来创建ecu的软件的版本历史记录信息并进行管理，使用该历史记录信息将不适当地切换了的ecu的软件版本复原为安装管理版本。由此，能够使用历史记录信息来复原软件版本，另外，能够复原为处于历史记录的软件版本(基本上是用户同意了的软件版本)。
73.另外，如以上使用图7等说明那样，在ecu的软件版本不恰当地切换了的情况下，当判定为被安装在搭载于车辆的多个ecu的软件的版本不匹配(不为适当的组合)的情况下，第1实施方式所涉及的ota中心1能够使用历史记录信息复原为最近的软件版本的匹配构成。由此，由于能够可靠地复原为软件版本的匹配构成，另外，能够复原为匹配构成中的最新的结构，所以是合理的。另一方面，对于第1实施方式所涉及的ota中心1而言，在ecu的软件的版本不恰当地切换了的情况下，当判定为被安装在搭载于车辆的多个ecu的软件的版本匹配(为适当的组合)的情况下，由于不产生因软件的版本不匹配引起的问题，所以不进行复原软件版本的处理。由此，能够减少处理负荷。此外，可以是在这样判定为被安装于多个ecu的软件的版本匹配(为适当的组合)的情况下也使用历史记录信息来复原为最近的软件版本的匹配构成的控制结构。通过这样进行控制，能够复原为处于历史记录的软件版本(用户同意了的软件版本)。
74.另外，如以上使用图12说明那样，在ecu的软件的版本不恰当地切换了的情况下，第2实施方式所涉及的ota中心1能够将ecu的软件的版本直接复原为安装管理版本信息所
表示的安装管理版本。由此，能够通过简洁的处理将软件版本复原为匹配构成。
75.此外，在上述的第2实施方式中(参照图12)，也可以是不执行进行软件版本的匹配性判定的处理(步骤s4以及s6)的控制结构。即，可以是在检测到软件版本不恰当变化的情况下(参照图9以及图10的粗框部分)不考虑软件版本的匹配性的有无就将软件版本复原为安装管理版本的处理。这里，由于安装管理版本通常具有软件版本的匹配性，所以通过成为这样的简洁的处理，能够减少处理负荷。
76.另外，在上述的第1实施方式以及第2实施方式中，举出了表示安装管理版本的安装管理版本信息包含(附加)在历史记录信息而被存储的例子(参照图9以及图10)。然而，安装管理版本信息也可以独立于历史记录信息来存储。
77.另外，上述的实施方式中例示的ota中心1的功能也能够实现为具备处理器(cpu)、存储器以及通信装置的计算机所执行的管理方法、或使该计算机执行的管理程序、存储有管理程序的计算机可读取的非暂时性存储介质。同样，作为上述的实施方式而例示出的ota管理器11的功能也能够实现为具备处理器(cpu)、存储器以及通信装置的车载的计算机所执行的控制方法、或使该车载的计算机执行的控制程序、存储有控制程序的计算机可读取的非暂时性存储介质。
78.本公开技术能够在用于更新ecu(电子控制单元)的程序的网络系统中利用。