软件更新装置、软件更新方法、软件更新系统与流程

本发明涉及软件更新装置、软件更新方法及软件更新系统。

背景技术：

近年来，由于驾驶辅助功能及自动驾驶技术的发展，搭载于汽车用的电子控制装置(ecu：electriccontrolunit，电子控制单元)的软件的规模正在增大。此外，随之，不仅是软件不良所导致的召回的次数，每一次召回需要应对的台数也在增加。因此，对于远程地更新在ecu中搭载的软件的技术的需求正在提高。在远隔地更新软件时，与以往在经销商等处由维护人员进行更新作业的情况不同，需要尽可能使处理自动化。因此，即使在发生例如电源断开等异常而更新处理中断的情况下也能够不以维护人员等的操作为前提而使得回到正常的状态变得重要。

例如，在专利文献1中，公开了以下技术：准备两个保存执行软件的区域，在发生了软件的更新异常的情况下，通过选择正常的软件并执行、在更新异常时也不对系统带来影响。

现有技术文献

专利文献

专利文献1：日本特许第4548601号

技术实现要素：

发明要解决的课题

专利文献1所记载的发明不能应用于存储资源缺乏的装置，难以应对于将软件更新的装置的多样性。

用来解决课题的手段

本发明的第1技术方案的软件更新装置与控制装置连接，具备：更新控制部，进行使上述控制装置的软件从更新前状态转变为更新完成状态的更新处理；恢复控制信息管理部，取得恢复控制信息；以及恢复控制部，在因上述更新处理的异常而上述软件没有转变为上述更新完成状态的情况下，基于上述恢复控制信息执行使上述软件转变为上述更新完成状态的恢复处理。

本发明的第2技术方案的软件更新方法由与控制装置连接的软件更新装置执行，具有以下步骤：进行使上述控制装置的软件从更新前状态转变为更新完成状态的更新处理；取得恢复控制信息；以及在因上述更新处理的异常而上述软件没有转变为上述更新完成状态的情况下，基于上述恢复控制信息执行使上述软件转变为上述更新完成状态的恢复处理。

本发明的第3技术方案的软件更新系统具备：上述软件更新装置；以及服务器，向上述软件更新装置发送上述恢复控制信息。

发明效果

根据本发明，能够执行与多样的装置对应的恢复处理。

附图说明

图1是表示软件更新系统的结构的图。

图2(a)是表示网关的硬件结构的框图，图2(b)是表示在网关上动作的网关程序的结构的框图。

图3是表示更新状态d1的一例的图。

图4(a)是表示发动机控制ecu的硬件结构的框图，图4(b)是表示在发动机控制ecu上动作的控制程序的结构的框图。

图5(a)是表示容量少的from的结构例的图，图5(b)是表示容量多的from的结构例的图。

图6(a)是表示第1实施方式的更新包的结构的图，图6(b)是表示第1实施方式的ecu恢复控制信息的结构的图。

图7是表示将发动机控制ecu的软件更新的更新处理整体的顺序图。

图8是表示在图7的步骤s4中在网关与发动机控制ecu之间执行的软件更新处理的流程的顺序图。

图9(a)是表示存储器少的ecu中的复原处理s407的处理的概念图，图9(b)是表示存储器多的ecu中的复原处理s407的处理的概念图。

图10(a)是表示存储器少的ecu的起动顺序图，图10(b)是表示存储器多的ecu的起动顺序图。

图11是表示网关10在起动时进行的恢复控制处理的流程图。

图12是表示恢复处理s707的一例的流程图。

图13(a)及图13(b)是表示与自动驾驶ecu对应的更新包的一例的图，图13(c)是表示画面显示例的图。

图14是表示自动驾驶ecu的恢复处理的一例的顺序图。

图15(a)及图15(b)是表示与adasecu对应的更新包的一例的图，图15(c)是表示画面显示例的图。

图16是表示adasecu的恢复处理的一例的顺序图。

图17(a)及图17(b)是表示与发动机控制ecu对应的更新包的一例的图，图17(c)是表示画面显示例的图。

图18是表示发动机控制ecu的恢复处理的一例的顺序图。

图19(a)及图19(b)是表示与制动器控制ecu对应的更新包的一例的图，图19(c)是表示画面显示例的图。

图20是表示制动器控制ecu的恢复处理的一例的顺序图。

图21(a)及图21(b)是表示与hvacecu对应的更新包的一例的图，图21(c)是表示画面显示例的图。

图22是表示hvacecu的恢复处理的一例的顺序图。

图23(a)及图23(b)是表示与气囊ecu对应的更新包的一例的图，图23(c)是表示画面显示例的图。

图24是表示气囊ecu的恢复处理的一例的顺序图。

图25是表示变形例6的更新包的一例的图。

图26是表示在第2实施方式的发动机控制ecu上动作的控制程序的结构的框图。

图27是表示网关从发动机控制ecu取得恢复控制信息的处理的顺序图。

图28(a)是表示第3实施方式的更新包的结构的图，图28(b)是表示第3实施方式的ecu恢复控制信息的结构的图。

图29(a)是表示与自动驾驶ecu对应的恢复控制信息的一例的图，图29(b)是表示画面显示例的图，图29(c)是表示更新状态d1的一例的图。

图30(a)是表示根据中断原因而不同的恢复控制处理的一例的顺序图，图30(b)是表示from故障时的恢复控制处理的一例的顺序图。

具体实施方式

―第1实施方式―

以下，参照图1～图24，说明有关第1实施方式的软件更新系统。另外，在本实施方式中对软件的更新进行说明，但并不限定于软件，可以应用于参数或数据等。

<更新和恢复的定义>

如以下这样定义本实施方式的软件的“更新”和“恢复”。即，本实施方式的软件的“更新”是指使软件从更新前状态转变为更新完成状态。此外，本实施方式的软件的“恢复”是指在因更新处理的异常而软件没有转变为更新完成状态的情况下使其转变为更新完成状态。

其中，软件既可以由单一的程序构成，也可以由多个程序构成。进而，也可以是，软件不仅包括程序，还包括在程序的执行中需要的各种参数、文本信息、声音信息、图像信息等。

<结构>

(系统结构)

图1是表示有关第1实施方式的软件更新系统s的结构的图。软件更新系统s具备车辆1及服务器2。车辆1和服务器2经由连接访问网络或据点的互联网3及通信服务提供商所提供的访问网络4而连接。

车辆1具备网关10、通信模块11、humanmachineinterface(hmi，人机界面)12、发动机控制ecu13、制动器控制ecu14、自动驾驶ecu15、先进驾驶辅助系统(adas)ecu16、气囊ecu17、heatingventilationairconditioning(hvac，暖通空调)ecu18及车辆管理ecu19等的车辆1为了实现行驶等功能而需要的ecu群、和连接这些ecu群的车内网络10a、10b。

在本实施方式中，说明将发动机控制ecu13的控制程序从现行的版本2更新为作为新版本的版本3的例子。另外，该控制程序的现行的版本2紧前的旧版本是1。

车内网络由controlareanetwork(can，控制器局域网络)(注册商标)、localinterconnectnetwork(lin，局部互联网)、flexray、ethernet(注册商标)等构成。在本实施方式中，车内网络10b由can构成，车内网络10a由ethernet构成。此外，虽然在图1中没有图示，但各种ecu等的车辆内的各构成要素通过电线连接于蓄电池，接受电力供给。

网关10进行各种ecu间通信数据的中继，并且作为软件更新装置，进行经由本设备及车内网络连接的ecu中搭载的软件的更新。

通信模块11对网关10或hmi12、各种ecu与服务器2的通信进行中继。hmi12是用来受理向作为车辆1的乘员的用户的信息提示及来自用户的输入的装置，由进行画面显示的显示装置及各种开关等输入装置、或将它们组合的触摸面板等构成。发动机控制ecu13进行发动机的控制。制动器控制ecu14进行制动器的控制。自动驾驶ecu15在自动驾驶时进行环境的识别及车辆的起动指示等。adasecu16进行自动制动等的驾驶辅助控制。气囊ecu17进行气囊的控制。hvacecu18进行车内的空调控制。车辆管理ecu19进行车辆状态的管理。

服务器2具备未图示的cpu、rom及ram，将软件更新所需要的更新包5发送给网关10。更新包5的结构在后面叙述。网关10基于更新包5中包含的数据将各ecu的软件更新。

(网关的结构)

图2(a)是表示网关10的硬件结构的框图。网关10具备微型计算机101、from(flashrom)102、can用的通信i/f104、及ethernet用的通信i/f105。

微型计算机101具备cpu1011、sram1012、from1013、can通信控制器1014及ethernet通信控制器1015。微型计算机101的cpu1011执行保存在from1013中的程序，对网关10内的其他构成要素进行控制，并且进行与通过车内网络连接的其他设备的数据收发指示等而使网关10发挥功能。

from102是非易失性存储器，保存接收到的更新包5。

通信i/f104是can通信用的接口，基于微型计算机101的指示，经由车内网络10b在与连接在车内网络10b上的ecu之间进行数据的收发。

通信i/f105是ethernet通信用的接口，基于微型计算机101的指示，经由车内网络10a在与连接在车内网络10a上的设备之间进行数据的收发。

图2(b)是表示在网关10上动作的网关程序100的结构的框图。

实现网关10的功能的网关程序100被保存在微型计算机101的from1013中，由cpu1011执行。在图2(b)中，将功能性的集合表现为块，既可以将各块分割为多个，也可以将几个块合并。此外，控制程序既可以由1个软件实现，也可以由2个以上的软件的组合实现。

网关程序100包括更新控制部10001、更新数据管理部10002、更新状态管理部10003、恢复控制部10004、恢复控制信息管理部10005、车辆状态管理部10006及通信控制部10007。

更新控制部10001经由通信控制部10007而与连接在车内网络10a上的设备进行通信，进行更新包5的取得、车辆的状态及软件更新处理的状况的发送。更新控制部10001取得的更新包5被保存到from102中。详细情况后述，但更新包5由更新控制信息501和恢复控制信息502构成。此外，更新控制部10001经由通信控制部10007而与连接在车内网络10b上的设备进行通信，对ecu进行控制，更新ecu中搭载的软件。这里，软件的更新基于经由更新数据管理部10002取得的更新控制信息501和经由车辆状态管理部10006取得的车辆系统状态来实施。

更新数据管理部10002从from102取得更新控制信息501，向更新控制部10001提供。

更新状态管理部10003从更新控制部10001取得更新状态，作为更新状态d1保存到from1013中。此外，将所保存的更新状态d1向恢复控制部10004提供。

恢复控制部10004经由通信控制部10007而与连接在车内网络10b上的设备进行通信，对ecu进行控制而实施软件的恢复处理。这里，ecu的恢复处理基于经由更新状态管理部10003取得的更新状态d1、经由恢复控制信息管理部10005取得的恢复控制信息502和经由车辆状态管理部10006取得的车辆系统状态来实施。

恢复控制信息管理部10005从from102取得恢复控制信息502，向恢复控制部10004提供。

车辆状态管理部10006经由通信控制部10007而与连接在车内网络10a及10b上的设备进行通信，取得车辆系统的状态，将车辆状态向更新控制部10001及恢复控制部10004提供。车辆状态例如是指点火的开启或关闭、行驶的开始等。

通信控制部10007按照更新控制部10001等的指示，对can通信控制器1014及ethernet通信控制器1015进行控制，与连接在车内网络10a及10b上的设备进行通信。在与连接在车内网络10a上的设备进行通信时，通信控制部10007解析·生成tcp/ip或udp/ip等通信包。此外，在与连接在车内网络10a上的设备进行通信时，通信控制部10007解析·生成can帧。此外，通信控制部10007进行依据universaldiagnosticservice(uds，统一诊断服务)等诊断通信协议的命令的生成·解析。

图3是表示网关10的更新状态管理部10003管理的更新状态d1的一例的图。在图3中，表示了将更新状态d1作为表格进行管理、记录每个ecu的更新状态的情况下的例子。

更新状态d1具备ecuidd101、更新开始状态d102、处理中块d103、完成命令d104、成功块d105的字段。

ecuidd101是保存用来识别ecu的信息的字段。更新开始状态d102是保存表示该ecu的更新处理是否已开始的识别信息的字段，例如保存“未开始”“已开始”或“更新完”。处理中块d103是在该ecu的更新处理中保存处理中的块的识别信息的字段，保存块号码等。完成命令d104是在该ecu的更新处理中保存最后成功的命令的识别信息的字段，保存“数据传送开始请求”等命令识别信息。成功块d105是保存处理成功的块的识别信息的字段，保存块号码等。

记录d11是表示自动驾驶ecu15的更新状态的记录，在ecuidd101的字段中保存有“自动驾驶ecu”，在更新开始状态d102的字段中保存有表示是更新处理中的“已开始”，在处理中块d103的字段中保存有表示块n－1是处理中的“blockn－1”，在完成命令d104的字段中保存有表示数据传送开始请求已接受的“数据传送开始请求”，在成功块d105的字段中保存有表示最后处理完成的块是块n的“blockn”。

记录d12是表示发动机控制ecu13的更新状态的记录，在ecuidd101的字段中保存有“发动机控制ecu”，在更新开始状态d102的字段中保存有表示没有开始更新处理的“未开始”。这里，由于发动机控制ecu的更新没有开始，所以在记录d12的其他字段中没有被设定值。

这里说明了记录d11和记录d12这2个记录，在以下情况下制作这些记录。即，在网关10接收到的更新包5中被记载为更新对象的ecu的情况下制作。此外，该更新状态d1如后述那样被依次记录。这样，通过将更新状态d1依次记录，能够在更新中断后回到正常而起动了时识别出更新没有完成而中断的情况、更新被中断的部位而开始适当的恢复处理。

(ecu的结构)

图4(a)是表示发动机控制ecu13的硬件结构例的框图。但是，在本实施方式中作为被更新软件的对象的ecu都至少具备在图4(a)中表示的硬件结构。发动机控制ecu13具备微型计算机131及can用的通信i/f133。

微型计算机131具备cpu1311、sram1312、from1313、通信控制器1314及i/o控制器1315。微型计算机131执行保存在from1313中的控制程序，对发动机控制ecu13内的其他构成要素、经由i/o连接的传感器/致动器132进行控制，并且进行与通过车内网络连接的其他设备的数据收发指示等，从而实施发动机控制。传感器/致动器132根据微型计算机131的指示，取得发动机控制所需要的数据并执行发动机的控制。

图4(b)是表示在发动机控制ecu13上动作的控制程序130的结构的框图。但是，在本实施方式中，作为被更新软件的对象的ecu都至少具备与图4(b)所示的控制程序130同样的结构。

实现ecu13的功能的控制程序130被保存在微型计算机131的from1313中，由cpu1311执行。在图4(b)中，将功能性的集合表现为块，既可以将各块分割为多个，也可以将几个块合并。此外，控制程序既可以由1个软件实现，也可以由2个以上的软件的组合实现。

控制程序130具备更新控制部13001、差分/压缩复原部13002、更新状态管理部13003、from控制部13004、通信控制部13005及控制处理部13006。

更新控制部13001经由通信控制部10005接收来自网关10的动作指令及在软件的更新中使用的数据，对差分/压缩复原部13002及from控制部13004进行控制而对软件的更新进行控制。差分/压缩复原部13002按照更新控制部13001的指示，根据接收到的差分数据及压缩数据将最新版的软件、即版本3的软件复原。

更新状态管理部13003从更新控制部13001取得更新状态，作为更新状态d21保存到from1313中。此外，将所保存的更新状态d21向更新控制部13001提供。from控制部13004按照更新控制部13001的指示，将最新版的软件向from1313写入。通信控制部13005按照更新控制部13001等的指示，对通信控制器1314进行控制，与连接在车内网络10a上的设备进行通信。在通信时，将can帧进行解析·构成。此外，通信控制部13005进行依据uds等诊断通信协议的命令的生成·解析。控制处理部13006对i/o控制器1315进行控制，对传感器/致动器132进行控制而实施发动机控制。

图5是表示ecu的from的结构例的结构图。基于from1313的容量的多少，说明两种结构。其中，以下将from1313的容量多也称作“存储器多”，将from1313的容量少也称作“存储器少”。from1313的容量的多少即ecu的存储器多还是少，基于from1313的实用量、保存到from1313中的程序的尺寸、保存到from1313中的程序的性质、保存到from1313中的数据量的趋势等来判断。通常，执行复杂的处理的ecu被分类为本实施方式中的存储器多的ecu，仅执行简单的处理的ecu被分类为本实施方式中的存储器少的ecu。例如，发动机控制ecu13、制动器控制ecu14、hvacecu18、气囊ecu17等多数情况下被分类为存储器少的ecu，自动驾驶ecu15、adasecu16等多数情况下被分类为存储器多的ecu。

图5(a)是容量少的情况下的from1313的结构例。

from1313由程序区1313ap0及数据区1313ad0构成。

程序区1313ap0由多个块block0～blockn构成，保存有引导装载程序p1和控制程序p2。该控制程序p2的版本是现行的版本2(在图中记作“ver.2”)。在数据区1313ad0中保存参数d2。参数d2包括更新状态d21及控制参数d22。更新状态d21是表示软件更新的进展等状态的信息，在后面详细叙述。控制参数d22是为了ecu本来的发动机控制及制动器控制而使用的参数群。

图5(b)是容量多的情况下的from1313的结构例。

from1313由程序区及数据区1313bd0构成。程序区由2个区域、即bank0和bank1构成，以下将各自称作程序区1313bp0、程序区1313bp1。

程序区1313bp0及程序区1313bp1分别由多个块block0～blockn构成。在程序区1313bp0中保存引导装载程序p3和控制程序p4。该控制程序p4的版本是现行的版本2。此外，在程序区1313bp1中保存控制程序p5。该控制程序p5的版本是旧版的版本1。

在数据区1313bd0中保存参数d3。参数d3包括更新状态d21、控制参数d22及起动信息d33。

在起动信息d33中，设定执行在2个程序区的哪个中记录的控制程序，例如设定“程序区1313bp0”或“程序区1313bp1”。更新状态d21及控制参数d22如上所述。

图6(a)是网关10从服务器2取得的更新包5的结构例。更新包5由更新控制信息501和恢复控制信息502构成。

更新控制信息501由1个共同更新控制信息5011、1个以上的ecu更新控制信息5012和1个以上的ecu更新数据5013构成。ecu更新控制信息5012及ecu更新数据5013按每个作为更新对象的ecu而存在，共同更新控制信息5011与作为更新对象的ecu的台数无关而仅存在1个。

共同更新控制信息5011中包含用于车辆系统整体的状态确认的次序、阈值等信息。例如共同更新控制信息5011中，包含作为更新开始所需要的状态确认的电池剩余量的确认或可开始的剩余量阈值、hvac的有无的确认、车辆行驶状态的确认所需要的ecuid或canid、确认命令的信息。

ecu更新控制信息5012按每个更新对象ecu而构成，ecu更新控制信息5012中包括各个ecu的检查项目或更新控制次序的信息。

ecu更新数据5013是用于按每个更新对象ecu而构成的ecu的软件更新的数据，例如是软件本身、被压缩的软件或新旧软件的差分数据。

恢复控制信息502由1个以上的ecu恢复控制信息5021构成，有包括1个以上的ecu恢复数据5022的情况。ecu恢复控制信息5021按每个作为更新对象的ecu而存在，关于ecu恢复数据5022，基于ecu恢复控制信息5021的内容来决定是否存在。即，ecu恢复数据5022最多存在与ecu恢复控制信息5021相同数量，最小是零。

ecu恢复数据5022是在ecu的恢复中需要追加数据的情况下被赋予的数据，具备软件本身、被压缩的软件或以block(块)单位从软件的xor生成的备份数据等。

图6(b)是表示ecu恢复控制信息5021的结构的图。ecu恢复控制信息5021由识别ecu的ecuid50211、表示开始恢复的定时的开始定时50212、表示在hmi12的显示装置中进行画面显示的内容的显示内容50213、作为恢复的方式的恢复方式50214、以及用来取得追加的恢复数据的恢复数据uri50215构成。

ecuid50211是用来识别ecu的信息。恢复开始定时50212表示开始由网关10进行的恢复处理的定时。恢复开始定时50212例如被设定表示系统刚从异常恢复后的“立即”、表示开始行驶而电源供给稳定后的“行驶开始”、表示接着发动机从动作状态转变为停止状态时的“ign－off”等。

显示内容50213保存显示消息信息及显示内容的概要，该显示消息信息保存有当系统从异常恢复了时等向用户提示的消息。显示内容的概要例如是指“提醒注意”、“警告”及“紧急”。基于显示内容50213显示的具体的例子后述。

恢复方式50214表示对于该ecu以怎样的次序进行恢复，设定“差分继续恢复(resume)”、“压缩恢复”、“服务器协同”、“块恢复”等。“差分继续恢复”是从异常中断的部位起重新开始差分更新的恢复处理的方式。“压缩恢复”是将被压缩的软件作为ecu恢复数据5022一同打包在恢复控制信息502中并用它将软件整体替换的进行所谓完全更新的恢复处理的方式。“服务器协同”是从服务器2重新下载被压缩的软件而进行所谓完全更新的恢复处理的方式。“块恢复”是将把软件分割为多个块并计算各块的xor而得到的块xor数据作为ecu恢复数据5022而一同打包、并根据块xor数据和没有缺损的块将软件的缺损部分进行恢复的恢复处理的方式。

在恢复数据uri50215中，在恢复方式50214是“服务器协同”的情况下，设定网关10取得恢复数据的uri。在恢复方式50214是“服务器协同”以外的情况下，恢复数据uri50215中设定意味着没有被设定信息的“null”。另外，保存有该uri表示的资源的场所既可以是服务器2也可以是服务器2以外。

图7是表示将发动机控制ecu13的软件进行更新的更新处理整体的流程的顺序图。这里，假设仅发动机控制ecu13是更新对象、其他ecu不是更新对象来进行说明。

如果制作了发动机控制ecu13的新的软件，则服务器2的操作者进行用来将该软件分发给发动机控制ecu13的准备，制作更新包5并向服务器2登记(s1)。另外，更新包5的制作既可以由操作者进行，也可以由服务器2基于制作出的新的软件和设定文件来进行。

在分发准备完成后，在发动机起动时等，网关10经由通信模块11从服务器2下载更新包5，并保持到网关10的from102中(s2)。然后，在发动机状态从起动中转变为停止状态时等，在实施作为更新对象的发动机控制ecu13的版本的检查、更新对象的ecu的状态取得、以及得到向使用hmi12的用户的允许的前处理s3后，进行发动机控制ecu13的软件更新处理s4。最后，实施确认更新对象ecu13的改写状态的后处理s5，更新处理完成。作为更新处理的前处理s3、软件更新处理s4、后处理s5的开始定时除了发动机停止时以外，也可以考虑下载处理s2刚完成后或规定的时刻等。以下，详细地说明标号s4表示的软件更新处理。

图8是表示在图7的步骤s4中在网关10与发动机控制ecu13之间执行的软件更新处理的流程的顺序图。这里，表示将发动机控制ecu13更新的例子，但本动作基本上在其他ecu中也是同样的。在图8中，用虚线的箭头表示根据状况而需要的处理。

在以下的说明中，假设网关10中的数据的收发经由通信控制部10007进行，假设发动机控制ecu13中的数据的收发经由通信控制部13005进行。

首先，网关10的更新控制部10001向发动机控制ecu13发送会话(session)变更请求(s401)。该会话变更请求包含用来进行软件改写的特殊模式的识别信息。发动机控制ecu13的更新控制部13001如果接收到在步骤s402中从网关10发送的会话变更请求，则在使内部状态转变为由会话变更请求指定的模式后，向网关10发送接受应答(s402)。

网关10的更新控制部10001如果接收到在步骤s402中从发动机控制ecu13发送的接受应答，则经由更新状态管理部10003向更新状态d1记录开始了更新应用处理的情况(s402r)。接着，网关10的更新控制部10001经由更新数据管理部10002读出ecu更新控制信息5012，开始记述在ecu更新控制信息5012中的每个处理块的处理。即，更新控制部10001确定记述在ecu更新控制信息5012中的最初的处理块，将该块作为“处理中块”，经由更新状态管理部10003向更新状态d1记录(s403r)。

并且，更新控制部10001向发动机控制ecu13发送该块的数据传送开始请求(s403)。该数据传送开始请求例如包括数据格式、预计发送的数据尺寸、表示所发送的数据的写入目的地的写入目的地地址等信息。发动机控制ecu13的通信控制部13005如果接收到在步骤s403中从网关10发送的数据传送开始请求，则向网关10发送接受应答(s404)。该接受应答中，包含发动机控制ecu13能够一次接收的数据尺寸等信息。网关10的更新控制部10001如果接收到该接受应答，则经由更新状态管理部10003向更新状态d1记录“数据传送开始请求”作为成功的命令(s404r)。

接着，网关10的更新控制部10001从更新数据5013读出与当前处理中的块相应的更新数据，分割为发动机控制ecu13能够一次接收的数据尺寸，向发动机控制ecu13发送(s405)。这里，将发送数据再分割为can帧而发送。发动机控制ecu13的更新控制部13001如果接收到在步骤s405中从网关10发送的数据，则向差分/压缩复原部13002指示而开始复原处理s407。该复原处理s407在后面详细叙述。这里，在复原处理花费时间的情况下，向网关10发送待机应答(s406)。如果复原处理s407完成，则发动机控制ecu13的更新控制部13001向网关10发送接收应答s408。网关10和发动机控制ecu13反复进行从步骤s405到s408的处理(传送处理s430)，直到与分割的当前处理中的块相应的更新数据的传送全部完成。

如果传送处理s430完成，则网关10的更新控制部10001经由更新状态管理部10003向更新状态d1记录“数据传送”作为成功的命令(s408r)，并将传送完成通知向发动机控制ecu13发送(s409)。发动机控制ecu13的更新控制部13001如果接收到在步骤s409中从网关10发送的传送完成通知，则在步骤s411中向from控制部13004进行数据写入指示。根据该指示，from控制部13004将由差分/压缩复原部13002复原并暂时保存在sram1312或from1313中的新软件或其一部分向from1313写入。这里，在向from1313的数据写入花费时间的情况下，向网关10发送待机应答(s410)。如果向from1313的写入成功，则更新控制部13001经由更新状态管理部13003将作为完成的块而写入的块向更新状态d21记录(s411r)，并向网关10发送接受应答(s412)。

网关10的更新控制部10001如果接收到在步骤s412中从发动机控制ecu13发送的接受应答，则经由更新状态管理部10003向更新状态d1记录该块的改写处理完成的情况(s412r)。网关10和发动机控制ecu13反复进行从步骤s403r到s412r的处理(块复原·写入处理s420)，直到将与处理对象的全部块相应的传送及写入处理全部完成。如果处理对象的全部块的复原·写入处理s420完成，则网关10的更新控制部10001经由更新状态管理部10003向更新状态d1记录改写处理完成的情况(s415r)。

接着，网关10的更新控制部10001向发动机控制ecu13发送会话变更请求(s413)。该会话变更请求包含用来回到通常模式的通常模式的识别信息。发动机控制ecu13的更新控制部13001如果接收到在步骤s413中从网关10发送的会话变更请求，则在使内部状态转变为由会话变更请求指定的通常模式后，向网关10发送接受应答(s414)。

这样，通过将更新状态依次记录，在更新中断后，在恢复为正常而起动了时能够识别出更新没有完成而中断、以及更新在进展到哪里的状态下中断，并开始适当的恢复处理。

图9是表示ecu中的复原处理s407的处理的概念图。

图9(a)是表示存储器少的ecu中的复原处理s407的处理的概念图。差分/压缩复原部13002如果从更新控制部13001接收到复原指示，则读出从网关10接收并保存在sram1312中的更新数据5013a的一部分。在压缩更新的情况下，由于更新数据被压缩，所以将其展开，作为版本3的控制程序p22向复原区域d5输出。在差分更新的情况下，由于更新数据是差分数据，所以差分/压缩复原部13002首先读出为了复原而需要的现行的版本2的控制程序p21的一部分或全部。并且，差分/压缩复原部13002将它们组合而复原版本3的控制程序p22，向复原区域d5输出。

另外，在本实施方式中，关于复原区域d5，在from1313的数据区1313ad0内确保，但例如也可以在程序区的空闲区域(1313ap0的blockn)或sram1312中确保。在作为复原区域d5而使用from1313的数据区1313ad0或程序区的空闲区域(1313ap0的blockn)的情况下，即使在flash的消除·写入中更新中断，也能够从中途重新开始。但是，根据微型计算机131的规格，有向数据区1313a的访问花费时间、更新时间变长的情况。此外，根据微型计算机131的规格，有软件的空闲区的可改写的次数较少的情况。此外，在使用sram1312作为复原区域的情况下，在flash写入处理s411时中断的情况下不能进行基于差分继续恢复的恢复处理。复原后的版本3的控制程序p22在图8的flash写入处理s411中由更新控制部13001经由from控制部13004覆盖到from1313的相应区域。在图9(a)中，更新控制部13001及from控制部13004没有图示。

如以上这样，通过将接收到的数据依次复原，即使没有储存为了对版本3的控制程序p22进行重构而需要的全部的差分数据，也能够进行差分更新。

但是，在差分数据足够小而能够保存到存储器的剩余区域中的情况下，并不一定需要按照本次序依次复原，而可以在接收到全部数据后开始复原处理。但是，不管哪种情况下都需要将执行中的控制程序覆盖，所以在更新中断的情况下，控制程序不再正常地动作。

图9(b)是表示存储器多的ecu中的复原处理s407的处理的概念图。差分/压缩复原部13002如果从更新控制部13001接收到复原指示，则读出从网关10接收并保存在sram1312中的更新数据的一部分5013b。在压缩更新的情况下，由于更新数据是被压缩的软件，所以将其展开，作为版本3的控制程序p52而向复原区域d100输出。在本实施方式中，在sram1312中确保复原区域d100。在差分更新的情况下，由于更新数据是差分数据，所以差分/压缩复原部13002读出为了复原而需要的现行的控制程序p4的一部分或全部，将它们组合而将版本3的控制程序p52复原，并向复原区域d100输出。复原后的新软件p52在图8的flash写入处理s411中由更新控制部13001经由from控制部13004覆盖到from1313的相应区域。这里，版本3的控制程序p52将bank1的版本1的控制程序p51覆盖。此外，这里没有图示更新控制部13001、from控制部13004。

如以上这样，在进行具备两个保存控制程序的存储器的ecu的更新的情况下，将控制程序的保存区域进行重复化，将控制程序复原·保存到与保存有当前正在执行的控制程序的区域不同的区域中，由此即使在更新中断的情况下，也能够不使执行中的控制程序损坏而继续正常动作。

图10是ecu的起动次序例。

图10(a)是存储器少的ecu的起动顺序图。

在存储器少的ecu中，首先将引导装载程序p1起动(s601)。引导装载程序p1对保存在程序区中的控制程序p2进行验证(s602)。如果验证的结果判断为控制程序p2没有问题(s603：是)，则将控制程序p2起动(s604)。此外，如果验证的结果判断为在控制程序p2中有问题，则不执行控制程序p2，设为紧急模式而等待来自网关10的控制指示(s605)。此时，作为紧急模式特有的设定，也可以将作为由iso15765－2规定的传送参数的blocksize设定为0，实施can帧的突发(burst)传送。由此，能够实现通信的高效率化。另外，判断为控制程序p2中有问题的情况例如是指不存在软件的情况或验证结果为异常的情况。

图10(b)是存储器多的ecu的起动顺序图。

在存储器多的ecu中，首先将引导装载程序p3起动(s651)。引导装载程序p3读出数据区1313bd0的参数d3内的起动信息d33(s652)，执行记录在起动信息d33中的控制程序(s653)。例如在起动信息d33是“程序区1313bp0”的情况下，执行程序区1313bp0上的版本2的控制程序p4。

图11是表示网关10在起动时进行的恢复控制处理的流程图。

如果网关10起动，则网关10的恢复控制部10004经由更新状态管理部10003取得记录在更新状态d1中的更新开始状态d102(s701)。恢复控制部10004在判断为不存在更新已开始的ecu、即不存在中断的更新的情况下(s702：否)，进行通常的网关10的起动处理(s713)。

在判断为存在更新已开始的ecu、即存在中断的更新的情况下(s702：是)，恢复控制部10004向服务器2通知存在中断的更新之意(s703)。并且，恢复控制部10004经由恢复控制信息管理部10005从与该ecuid对应的ecu恢复控制信息5021取得开始定时50212(s704)。

在判断为开始定时50212是“立即”的情况下(s705：是)，按照恢复控制信息5021的显示内容50213，向hmi12输出“紧急”的画面显示的指令(s706)，开始恢复处理(s707)。但是，在此情况下，为了尽早地开始恢复处理，向hmi12的指令既可以是开始恢复处理后，也可以同时执行2个处理。恢复处理s707的详细情况后述。

在开始定时50212是“立即”以外的情况下，取得恢复控制信息5021的显示内容50213(s708)，在判断为显示内容是“提醒注意”的情况下，向hmi12进行“提醒注意”的画面显示请求(s710)。

另一方面，在判断为显示内容是“警告”的情况下，向hmi12进行“警告”的画面显示请求(s711)。在画面显示请求发送后，等待行驶开始或ign－off等的更新开始触发(s712)。然后，一旦检测到更新开始的触发事件发生，就开始恢复处理(s707)。如果恢复处理s707完成，则进行通常起动处理(s713)。

图12是表示第1实施方式的恢复处理s707的一例的流程图。

网关10的恢复控制部10004经由恢复控制信息管理部10005从与该ecuid对应的恢复控制信息5021取得恢复方式50214(s70701)，向步骤s70702前进。

在判断为恢复方式50214是“差分继续恢复”的情况下(s70702：是)，恢复控制部10004经由更新状态管理部10003取得记录在更新状态d1中的处理中块(s70703)，在与ecu之间从该块起重新开始差分更新处理(s70704)。

在判断为恢复方式50214不是“差分继续恢复”的情况下(s70702：否)，恢复控制部10004判断恢复方式50214是否是“服务器协同”。在判断为恢复方式50214是“服务器协同”的情况下(s70705：是)，恢复控制部10004经由恢复控制信息管理部10005从与该ecuid对应的恢复控制信息5021取得恢复数据uri50215(s70706)，从该uri取得压缩数据作为恢复数据(s70707)。

在判断为恢复方式50214不是“服务器协同”的情况下(s70705：否)，恢复控制部10004判断恢复方式50214是否是“压缩恢复”。在判断为恢复方式50214是“压缩恢复”的情况下(s70709：是)，恢复控制部10004经由恢复控制信息管理部10005从与该ecuid对应的ecu恢复数据5022取得压缩数据(s70710)。

恢复控制部10004在步骤s70707或s70710中取得压缩数据后，使用所取得的压缩数据，在与ecu之间实施恢复处理(s70708)。

在判断为恢复方式50214不是“压缩恢复”的情况下(s70709：否)，恢复控制部10004经由恢复控制信息管理部10005从与该ecuid对应的ecu恢复数据5022取得块xor数据(s70711)，在与ecu之间实施基于块恢复的恢复处理(s70712)。

这样，通过基于从服务器2与更新控制信息501一起作为更新包5而发送的恢复控制信息502来执行更新异常发生时的恢复控制处理，即使在由资源或特性不同的多个ecu构成的系统中发生了更新异常的情况下，也能够根据对车辆系统的影响而在适当的定时开始恢复，向用户准确地传达更新中断对系统的影响，以与更新对象ecu的特性相应的恢复次序执行恢复处理而正常地更新软件。

(动作例)

以下，使用图13～图24，说明自动驾驶ecu15、adasecu16、发动机控制ecu13、制动器控制ecu14、hvacecu18、气囊ecu17的恢复处理的动作例。

(动作例―自动驾驶ecu)

使用图13及图14，说明与自动驾驶ecu15对应的更新包5a的结构、向hmi12的显示例及动作次序。

图13(a)是表示更新对象仅为自动驾驶ecu15的情况下的更新包5a的结构的图，图13(b)是表示在该更新包5a中包含的自动驾驶ecu恢复控制信息5021a的结构的图，图13(c)是表示基于自动驾驶ecu恢复控制信息5021a的hmi12的显示例的图。

更新对象仅为自动驾驶ecu15的情况下的更新包5a如图13(a)所示，由包括共同更新控制信息5011、自动驾驶ecu更新控制信息5012a、自动驾驶ecu更新数据5013a的更新控制信息501a、以及包括自动驾驶ecu恢复控制信息5021a的恢复控制信息502a构成。

自动驾驶ecu恢复控制信息5021a如图13(b)所示，在ecuid50211a中被设定“自动驾驶ecu”，在开始定时50212a中被设定“行驶开始”，在显示内容50213a中被设定“提醒注意”及未图示的显示消息信息，在恢复方式50214a中被设定“差分继续恢复”，在恢复数据uri50215a中被设定意味着没有被设定信息的“null”。

恢复控制部10004基于显示内容50213a，使hmi12的显示装置输出图13(c)所示的画面显示g10a。该画面显示g10a向用户告知软件的更新被中断、作为由恢复处理造成的车辆1的功能限制状态还不能使用更新后的功能之意，并且是表示关于被中断的更新，自动被应用的提醒注意。

图14是表示自动驾驶ecu15的恢复处理的1例的顺序图。例如，如果自动驾驶ecu15的更新处理因向网关10的电源供给断开等而被中断、并电源供给重新开始，则如以下这样执行恢复处理。另外，自动驾驶ecu15被分类为存储器多的ecu，如图5(b)所示那样能够保存2个控制程序。

如果网关10起动，则开始图11所示的处理。即，首先，在步骤s901a中确认中断中的更新的有无(图11的s701、s702，图14的s901a)。

此外，与网关10的处理并行地，在自动驾驶ecu15中进行图10(b)所示的起动处理。这里，由于更新中断，起动信息d33还没有改写，记录在程序区1313bp0中的控制程序的起动已被指定，所以自动驾驶ecu15将现行的版本2的控制程序p4起动。

网关10如果根据更新状态d21的更新开始状态d102判定为自动驾驶ecu15的更新中断(s901a)，则在步骤s903a中进行以下的处理。即网关10从与自动驾驶ecu15相应的自动驾驶ecu恢复控制信息5021a读出开始定时50212a，判定为开始自动驾驶ecu15的恢复处理的定时是行驶开始后。

接着，网关10在步骤s904a中从自动驾驶ecu恢复控制信息5021a读出显示内容50213a，向hmi12发出显示基于显示内容50213a的提醒注意画面的请求。hmi12基于该请求，将在图13(c)的g10a中例示的提醒注意画面显示在显示装置上(s905a)。网关10如果在步骤s906a中检测到作为开始恢复处理的触发的行驶开始，则读出自动驾驶ecu恢复控制信息5021a的恢复方式50214a，判定为恢复处理的方式是“差分继续恢复”(s907a)。如上所述，基于“差分继续恢复”的恢复是指在差分更新中断的情况下，通过从中断的块起重新开始差分更新，使得能够在短时间中完成更新的方式。网关10为了决定开始继续恢复的点，读出更新状态d21的处理中块d103(s908a)。网关10在决定开始继续恢复的块之后，在步骤909a中，从该块起实施图8的软件更新处理s4，完成自动驾驶ecu15的更新。

在如自动驾驶ecu15那样具备丰富的存储器、并且控制程序能够重复化的情况下，能够将更新后的控制程序复原或保存到与保存有当前正在执行的控制程序的区域不同的区域中，所以有以下的优点。即，在更新中断的情况下也不会使执行中的控制程序损坏，通过在重新起动时将执行中的控制程序起动，能够维持正常的动作。因此，通过如上述那样构成恢复控制信息502a并使用它，网关10在自动驾驶ecu15的更新被中断的情况下也可以不用立即使更新完成，只要在接下来的行驶时重新开始更新就可以。

网关10通过使hmi12显示提醒注意画面来向用户传达更新中断之意、以及中断的更新的重新开始在行驶中被自动进行之意。此外，由于在更新状态d1中记录有更新状态，所以能够从中断点起开始恢复的执行、即重新开始更新，迅速地完成更新。

另外，在上述的例子中，表示了当自动驾驶ecu15的更新中断时显示提醒注意画面的例子。但是，例如在自动驾驶ecu15的更新在行驶等中完全在后台被实施、在用户没有意识到的期间完成的情况下，也可以进行控制以使得不显示提醒注意画面。在此情况下，在图13的显示内容50213a中，设定“无画面显示”，而不是“提醒注意”。

(动作例―adasecu)

使用图15及图16，说明与adasecu16对应的更新包5b的结构、向hmi12的显示例及动作次序。

图15(a)是表示更新对象仅为adasecu16的情况下的更新包5b的结构的图，图15(b)是表示在该更新包5b中包含的adasecu恢复控制信息5021b的结构的图，图15(c)是表示基于adasecu恢复控制信息5021b的hmi12的显示例的图。

更新对象仅为adasecu16的情况下的更新包5b如图15(a)所示，由包括共同更新控制信息5011、adasecu更新控制信息5012b、adasecu更新数据5013b的更新控制信息501b、以及包括adasecu恢复控制信息5021b的恢复控制信息502b构成。

adasecu恢复控制信息5021b如图15(b)所示，在ecuid50211b中被设定“adasecu”，在开始定时50212b中被设定“ign－off”，在显示内容50213b中被设定“提醒注意”及未图示的显示消息信息，在恢复方式50214b中被设定“差分继续恢复”，在恢复数据uri50215b中被设定意味着没有被设定信息的“null”。

恢复控制部10004基于显示内容50213b，使hmi12的显示装置输出图15(c)所示的画面显示g10b。该画面显示g10b向用户告知软件的更新被中断、作为由恢复处理造成的车辆1的功能限制状态还不能使用更新后的功能之意，并且是表示关于被中断的更新，在接下来ign－off即点火关闭的定时被应用的提醒注意。

图16是表示adasecu16的恢复处理的1例的顺序图。例如，如果adasecu16的更新处理因向网关10的电源供给断开等而被中断、并重新开始电源供给，则如以下这样执行恢复处理。另外，adasecu16被分类为存储器多的ecu，如图5(b)所示能够保存2个控制程序。

如果网关10起动，则开始图11所示的处理。即，首先在步骤s901b中确认中断中的更新的有无(图11的s701、s702，图16的s901b)。

此外，与网关10的处理并行地在adasecu16中进行图10(b)所示的起动处理。这里，由于更新中断，起动信息d33还没有改写，记录在程序区1313bp0中的控制程序的起动已被指定，所以adasecu16将现行的版本2的控制程序p4起动。

网关10如果根据更新状态d21的更新开始状态d102判定为adasecu16的更新中断(s901b)，则在步骤s903b中进行以下的处理。即网关10从与adasecu16相应的adasecu恢复控制信息5021b读出开始定时50212b，判定为开始adasecu16的恢复处理的定时是ign－off。

接着，网关10在步骤s904b中从adasecu恢复控制信息5021b读出显示内容50213b，向hmi12发出显示基于显示内容50213b的提醒注意画面的请求。hmi12基于该请求，将在图15(c)的g10b中例示的提醒注意画面显示在显示装置上(s905b)。网关10如果在步骤s906b中被从车辆1输入作为开始恢复处理的触发的点火off信号，则检测到该情况(s907b)，读出adasecu恢复控制信息5021b的恢复方式50214b，判定为恢复处理的方式是“差分继续恢复”(s908b)。如上所述，基于“差分继续恢复”的恢复是指在差分更新中断的情况下，通过从中断的块起重新开始差分更新，使得能够在短时间中完成更新的方式。网关10为了决定开始继续恢复的点，读出更新状态d21的处理中块d103(s909a)。网关10在决定了开始继续恢复的块之后，在步骤910b中，从该块起实施图8的软件更新处理s4，完成adasecu16的更新。

由于adasecu16也与自动驾驶ecu15同样具备丰富的存储器，所以有与自动驾驶ecu15同样的优点。

网关10通过使hmi12显示提醒注意画面来向用户传达更新中断之意、以及中断的更新的重新开始通过点火关闭进行之意。此外，由于在更新状态d1中记录有更新状态，所以能够从中断点起开始恢复的执行、即重新开始更新，迅速地完成更新。

(动作例―发动机控制ecu)

使用图17及图18，说明与发动机控制ecu13对应的更新包5c的结构、向hmi12的显示例及动作次序。

图17(a)是表示更新对象仅为发动机控制ecu13的情况下的更新包5c的结构的图，图17(b)是表示该更新包5c中包含的发动机控制ecu恢复控制信息5021c的结构的图，图17(c)是表示基于发动机控制ecu恢复控制信息5021c的hmi12的显示例的图。

更新对象仅为发动机控制ecu13的情况下的更新包5c如图17(a)所示，由包括共同更新控制信息5011、发动机控制ecu更新控制信息5012c、发动机控制ecu更新数据5013c的更新控制信息501c、以及包括发动机控制ecu恢复控制信息5021c的恢复控制信息502c构成。

发动机控制ecu恢复控制信息5021c如图17(b)所示，在ecuid50211c中被设定“发动机控制ecu”，在开始定时50212c中被设定“立即”，在显示内容50213c中被设定“紧急”及未图示的显示消息信息，在恢复方式50214c中被设定“差分继续恢复”，在恢复数据uri50215c中被设定意味着没有被设定信息的“null”。

恢复控制部10004基于显示内容50213c，使hmi12的显示装置输出图17(c)所示的画面显示g10c。该画面显示g10c向用户告知软件的更新被中断、作为由恢复处理造成的车辆1的功能限制状态而车辆1不能使用之意，并且关于被中断的更新表示是立即恢复中。

图18是表示发动机控制ecu13的恢复处理的1例的顺序图。例如，如果发动机控制ecu13的更新处理因向网关10的电源供给断开等而被中断并重新开始电源供给，则如以下这样执行恢复处理。另外，发动机控制ecu13被分类为存储器少的ecu，如图5(a)所示仅能够保存1个控制程序。

如果网关10起动，则开始图11所示的处理。即，首先在步骤s901c中确认中断中的更新的有无(图11的s701、s702，图18的s901c)。

此外，与网关10的处理并行地，在发动机控制ecu13中进行图10(a)所示的起动处理。这里，由于是更新中断、现行的版本2的控制程序的一部分被版本3的控制程序的一部分覆盖的状态，所以控制程序p2的验证中发生问题，以紧急模式被起动(s902c)。

网关10如果根据更新状态d21的更新开始状态d102判定为发动机控制ecu13的更新中断(s901c)，则在步骤s903c中进行以下的处理。即，网关10从与发动机控制ecu13相应的发动机控制ecu恢复控制信息5021c中读出开始定时50212c，判定为开始发动机控制ecu13的恢复处理的定时是立即。

接着，网关10在步骤s904c中从发动机控制ecu恢复控制信息5021c中读出显示内容50213c，向hmi12发出显示基于显示内容50213c的紧急画面的请求。hmi12基于该请求，将在图17(c)的g10c中例示的紧急画面显示在显示装置上(s905c)。网关10由于开始恢复处理的定时是立即的，所以如果在步骤s904c中向hmi12发出紧急画面的显示请求，则立即读出发动机控制ecu恢复控制信息5021c的恢复方式50214c，判定为恢复处理的方式是“差分继续恢复”(s906c)。网关10在步骤s907c中为了决定开始继续恢复的点，读出更新状态d21的处理中块d103。网关10在决定了开始继续恢复的块之后，在步骤908c中，从该块起实施图8的软件更新处理s4，完成发动机控制ecu13的更新。

在发动机控制ecu13那样的存储器少的ecu的情况下，由于需要一边覆盖单一的控制程序一边进行更新，所以在更新中断的情况下，控制程序不能正常动作。因此，在发动机控制ecu13的更新中断的情况下，不能进行发动机控制，变得不能行驶。通过如上述那样构成恢复控制信息502c并使用它，网关10在发动机控制ecu13的更新中断时，判断为需要立即进行中断的更新的重新开始。此外，网关10通过使hmi12显示紧急画面而向用户传达车辆不能使用之意和更新的重新开始已立即开始之意。此外，由于在更新状态d1中记录有更新状态，所以从中断点起开始恢复的执行、即重新开始更新，能够迅速地完成更新。

(动作例―制动器控制ecu)

使用图19及图20，说明与制动器控制ecu14对应的更新包5d的结构、向hmi12的显示例及动作次序。

图19(a)是表示更新对象仅为制动器控制ecu14的情况下的更新包5d的结构的图，图19(b)是表示在该更新包5d中包含的制动器控制ecu恢复控制信息5021d的结构的图，图19(c)是表示基于制动器控制ecu恢复控制信息5021d的hmi12的显示例的图。

更新对象仅为制动器控制ecu14的情况下的更新包5d如图19(a)所示，由包括共同更新控制信息5011、制动器控制ecu更新控制信息5012d、及制动器控制ecu更新数据5013d的更新控制信息501d、以及包括制动器控制ecu恢复控制信息5021d及制动器控制ecu恢复数据5022d的恢复控制信息502d构成。

制动器控制ecu恢复控制信息5021d如图19(b)所示，在ecuid50211d中被设定“制动器控制ecu”，在开始定时50212d中被设定“立即”，在显示内容50213d中被设定“紧急”及未图示的显示消息信息，在恢复方式50214d中被设定“压缩恢复”，恢复数据uri50215d中被设定意味着没有被设定信息的“null”。

恢复控制部10004基于显示内容50213d，使hmi12的显示装置输出图19(c)所示的画面显示g10d。该画面显示g10d向用户告知软件的更新被中断、作为由恢复处理造成的车辆1的功能限制状态而车辆1不能使用之意，并且关于被中断的更新，表示是立即恢复中。

图20是表示制动器控制ecu14的恢复处理的1例的顺序图。例如，如果制动器控制ecu14的更新处理因向网关10的电源供给断开等而被中断并重新开始电源供给，则如以下这样执行恢复处理。另外，制动器控制ecu14被分类为存储器少的ecu，如图5(a)所示仅能够保存1个控制程序。

如果网关10起动，则开始图11所示的处理。即，首先在步骤s901d中确认中断中的更新的有无(图11的s701，s702，图20的s901d)。

此外，与网关10的处理并行地，在制动器控制ecu14中进行图10(a)所示的起动处理。这里，由于是更新中断、现行的版本2的控制程序的一部分被版本3的控制程序的一部分覆盖的状态，所以控制程序p2的验证中发生问题，以紧急模式被起动(s902d)。

网关10如果根据更新状态d21的更新开始状态d102判定为制动器控制ecu14的更新中断(s901d)，则在步骤s903d中进行以下的处理。即，网关10从与制动器控制ecu14相应的制动器控制ecu恢复控制信息5021d读出开始定时50212d，判定为开始制动器控制ecu14的恢复处理的定时是立即。

接着，网关10在步骤s904d中从制动器控制ecu恢复控制信息5021d读出显示内容50213d，向hmi12发出显示基于显示内容50213d的紧急画面的请求。hmi12基于该请求，将在图19(c)的g10d中例示的紧急画面显示在显示装置上(s905c)。由于开始恢复处理的定时是立即，所以如果在步骤s904d中向hmi12发出紧急画面的显示请求，则网关10立即读出制动器控制ecu恢复控制信息5021d的恢复方式50214d，判定为恢复处理的方式是“压缩恢复”(s906d)。如上所述，基于“压缩恢复”方式的恢复是指通过使用软件的压缩数据来进行软件的全区域的写入或损坏的区域的写入即修复而可靠地进行恢复的方式。网关10在步骤s907d中读出一起打包在更新包5d中的作为版本3的控制程序的压缩数据的制动器控制ecu恢复数据5022d。并且，网关10使用所读出的制动器控制ecu恢复数据5022d实施图8的软件更新处理s4，完成制动器控制ecu14的更新。

制动器控制ecu14也与发动机控制ecu13同样是存储器少，所以通过如上述那样构成恢复控制信息502c并使用它，网关10在制动器控制ecu14的更新中断时，判断为需要立即进行中断的更新的重新开始。此外，网关10通过使hmi12显示紧急画面，向用户传达车辆不能使用之意和立即开始了中断的更新的重新开始之意。进而，通过作为制动器控制ecu恢复数据5022d而一起打包将版本3的控制程序压缩的数据来进行控制程序的修复，能够避免差分继续恢复的以下的问题。即，在差分继续恢复中，有由于作为复原区域使用数据区1313a而处理时间变长的问题、导致使用改写次数有可能少的程序区的问题，但在压缩恢复方式中能够避免这些问题。此外，在后述的块恢复中，在ecu的软件修复中再次中断的情况下，不能进行其后的复原，但在基于压缩数据的修复的情况下，再次中断的情况也能够应对。

(动作例―hvacecu)

使用图21及图22，说明与hvacecu18对应的更新包5e的结构、向hmi12的显示例及动作次序。

图21(a)是表示更新对象仅为hvacecu18的情况下的更新包5e的结构的图，图21(b)是表示在该更新包5e中包含的hvacecu恢复控制信息5021e的结构的图，图21(c)是表示基于hvacecu恢复控制信息5021e的hmi12的显示例的图。

更新对象仅为hvacecu18的情况下的更新包5e如图21(a)所示，由包括共同更新控制信息5011、hvacecu更新控制信息5012e、hvacecu更新数据5013e的更新控制信息501e、以及包括hvacecu恢复控制信息5021e的恢复控制信息502e构成。

hvacecu恢复控制信息5021e如图21(b)所示，在ecuid50211e中被设定“hvacecu”，在开始定时50212e中被设定“ign－off”，在显示内容50213e中被设定“警告”及未图示的显示消息信息，在恢复方式50214e中被设定“服务器协同”，在恢复数据uri50215e中被设定作为保存有恢复数据的uri的“htttps：//example.jp/data”。

恢复控制部10004基于显示内容50213e，使hmi12的显示装置输出图21(c)所示的画面显示g10e。该画面显示g10e向用户告知软件的更新被中断、作为由恢复处理造成的车辆1的功能限制状态而hvac功能不能使用之意，并且是表示为了恢复而需要与服务器2的通信的警告。

图22是表示hvacecu18的恢复处理的1例的顺序图。例如，如果hvacecu18的更新处理因向网关10的电源供给断开等而被中断并重新开始电源供给，则如以下这样执行恢复处理。另外，hvacecu18被分类为存储器少的ecu，如图5(a)所示仅能够保存1个控制程序。

如果网关10起动，则开始图11所示的处理。即，首先在步骤s901e中确认中断中的更新的有无(图11的s701、s702，图22的s901e)。

此外，与网关10的处理并行地，在hvacecu18中，进行图10(a)所示的起动处理。这里，由于是更新中断、现行的版本2的控制程序的一部分被版本3的控制程序的一部分覆盖的状态，所以控制程序p2的验证中发生问题，以紧急模式被起动(s902e)。

网关10如果根据更新状态d21的更新开始状态d102判定为hvacecu18的更新(s901e)，则在步骤s903e中进行以下的处理。即，网关10从与hvacecu18相应的hvacecu恢复控制信息5021e中读出开始定时50212e，判断为开始hvacecu18的恢复处理的定时是点火off。

接着，网关10在步骤s904e中从hvacecu恢复控制信息5021e读出显示内容50213e，向hmi12发出显示基于显示内容50213e的警告画面的请求。hmi12基于该请求，显示在图21(c)的g10e中例示的警告画面(s905e)。

网关10如果接收到点火off信号(步骤s906e)，则检测到该情况(s907e)。接着，读出hvacecu恢复控制信息5021e的恢复方式50214e，判定为恢复处理的方式是“服务器协同”(s908e)。如上所述，基于“服务器协同”方式的恢复是指在恢复时从服务器2取得为了使中断的更新完成或回滚(rollback)而需要的数据的方式。如果通信模块11检测到与服务器2的通信被有效化，则网关10从通信模块11接收该通知(s909e)。接着，网关10经由通信模块11对服务器2的恢复数据uri50215d发送恢复数据取得请求(步骤910e)，接收恢复数据(s911e)。进而，网关10使用接收到的恢复数据实施更新处理(s912e)，完成hvacecu18的更新。

由于hvacecu18也与发动机控制ecu13及制动器控制ecu14同样存储器少，需要一边将单一的控制程序覆盖一边进行更新，所以在更新中断的情况下，控制程序不能正常动作。因此，在hvacecu18的更新中断的情况下，虽然不能进行hvac控制，但对车辆1的行驶的影响较小。通过如上述那样构成恢复控制信息502e并使用它，网关10在hvacecu18的更新中断时，也可以不用立刻控制hvacecu18而使更新完成，而在通过服务器协同从服务器2下载需要的数据后，在下次的点火off时重新开始更新。此外，网关10通过使hmi12显示警告画面，向用户传达由于更新中断所以hvac功能不能使用之意、为了更新的重新开始而需要移动到可通信的环境之意、还有中断的更新的重新开始可以在点火off时开始之意。

此外，网关10可以从在恢复数据uri50215中记载的uri取得用于恢复处理的数据。进而，通过构成为仅在频度小的异常发生时从服务器取得所需的恢复数据并对ecu的软件进行修复，不再需要在网关10及ecu中准备用来保存恢复数据及备份数据的追加存储器，能够以低成本构建系统。

(动作例―气囊ecu)

使用图23及图24，说明与气囊ecu17对应的更新包5f的结构、向hmi12的显示例及动作次序。

图23(a)是表示更新对象仅为气囊ecu17的情况下的更新包5f的结构的图，图23(b)是表示在该更新包5f中包含的气囊ecu恢复控制信息5021f的结构的图，图23(c)是表示基于气囊ecu恢复控制信息5021f的hmi12的显示例的图。

更新对象仅为气囊ecu17的情况下的更新包5f如图23(a)所示，由包括共同更新控制信息5011、气囊ecu更新控制信息5012f、气囊ecu更新数据5013f的更新控制信息501f、以及包括气囊ecu恢复控制信息5021f及气囊ecu恢复数据5022f的恢复控制信息502f构成。

气囊ecu恢复控制信息5021f如图23(b)所示，在ecuid50211f中被设定“气囊ecu”，在开始定时50212f中被设定“ign－off”，在显示内容50213f中被设定“警告”及未图示的显示消息信息，在恢复方式50214f中被设定“块恢复”，在恢复数据uri50215f中被设定意味着没有被设定信息的“null”。

恢复控制部10004基于显示内容50213f，使hmi12的显示装置输出图23(c)所示的画面显示g10f。该画面显示g10f向用户告知软件的更新被中断、作为由恢复处理造成的车辆1的功能限制状态而气囊不能使用之意，并且表示将中断的更新重新开始的定时是下次的点火off的定时。

图24是表示气囊ecu17的恢复处理的1例的顺序图。例如，如果气囊ecu17的更新处理因向网关10的电源供给断开等而被中断并重新开始电源供给，则如以下这样执行恢复处理。另外，气囊ecu17被分类为存储器少的ecu，如图5(a)所示仅能够保存1个控制程序。

如果网关10起动，则开始图11所示的处理。即，首先在步骤s901f中确认中断中的更新的有无(图11的s701、s702，图24的s901f)。

此外，与网关10的处理并行地，在气囊ecu17中进行图10(a)所示的起动处理。这里，由于是更新中断、现行的版本2的控制程序的一部分被版本3的控制程序的一部分覆盖的状态，所以控制程序p2的验证中发生问题，以紧急模式被起动(s902f)。

网关10如果根据更新状态d21的更新开始状态d102判定为气囊ecu17的更新中断(s901f)，则在步骤s903f中进行以下的处理。即，网关10从与气囊ecu17相应的气囊ecu恢复控制信息5021f读出开始定时50212f，判定为开始气囊ecu17的恢复处理的定时是点火off。

接着，网关10在步骤s904f中从气囊ecu恢复控制信息5021f中读出显示内容50213f，向hmi12发出显示基于显示内容50213f的警告画面的请求。hmi12基于该请求，显示在图23(c)的g10f中例示的警告画面(s905f)。网关10如果接收到作为开始恢复处理的触发的点火off信号(s906f)，则检测到该情况(s907f)。接着，网关10读出气囊ecu恢复控制信息5021f的恢复方式50214f，判定为恢复处理的方式是“块恢复”(s908f)，读出一同打包在更新包5f中的气囊ecu恢复数据5022f(s909f)。

网关10在步骤s910f中为了决定开始继续恢复的点，读出更新状态d21的处理中块d103。网关10在决定了开始继续恢复的块之后，在步骤911f中，从该块的下一个块起实施图8的软件更新处理s4，将中断的块以外的气囊ecu17的更新完成。网关10在步骤s912f中，将在步骤s909f中取得的恢复数据向气囊ecu17发送。气囊ecu17在步骤s913f中根据接收到的恢复数据和中断的块以外的更新后软件的块，将中断的块(损坏块)复原。

在如气囊ecu17那样的存储器少的ecu的情况下，由于需要一边将单一的控制程序覆盖一边进行更新，所以在更新中断的情况下，控制程序不能正常动作。因此，在气囊ecu17的更新中断的情况下，虽然不能进行气囊控制，但对于车辆1的行驶的影响小。通过如上述那样构成恢复控制信息502f并使用它，网关10在气囊ecu17的更新中断时，也可以不用立刻控制ecu而使更新完成，而是知道只要在下次点火off时重新开始更新就可以。此外，对于用户，通过使hmi12显示警告画面，向用户传达更新中断之意、因此气囊功能不能使用之意、中断的更新的重新开始可以在点火off时开始之意。

根据上述的第1实施方式，能得到以下的作用效果。

(1)软件更新装置例如网关10具备：更新控制部10001，与控制装置例如ecu连接，进行使ecu的软件例如控制程序从更新前状态转变为更新完成状态的更新处理；恢复控制信息管理部10005，取得恢复控制信息502；以及恢复控制部10004，在因更新处理的异常而控制程序没有转变为更新完成状态的情况下，基于恢复控制信息502执行使控制程序转变为更新完成状态的恢复处理。

网关10由于基于恢复控制信息502执行ecu的恢复处理，所以能够基于恢复控制信息502的记载来执行各种各样的恢复处理，能够执行与多种多样的装置、例如多种多样的ecu对应的恢复处理。换言之，通过基于恢复控制信息502执行在更新中发生了异常时的恢复控制处理，即使在由资源或特性不同的多个ecu构成的系统中更新发生了异常的情况下，也能够进行适当的恢复处理。

(2)恢复控制信息502包含开始恢复处理的定时的信息即开始定时50212。因此，网关10关于基于恢复控制信息502执行恢复的定时，能够实现立即实施、下次点火off时等多种多样的应对。恢复控制信息502中的开始定时50212的设定，例如根据车辆中的该ecu的作用来决定。

(3)在网关10被搭载于车辆、控制装置是对车辆的发动机及制动器中的至少一方进行控制的装置的情况下，恢复控制信息包含表示开始恢复处理的定时是立即的信息。因此，网关10对于在车辆的行驶中不可或缺的发动机控制ecu13及制动器控制ecu14能够立即开始恢复处理。

(4)恢复控制信息502包含表示恢复处理的方式的信息。因此，网关10能够基于恢复控制信息502，按每个ecu区分使用差分继续恢复、压缩恢复、服务器协同、块恢复等的恢复处理的方式。

(5)恢复处理的方式基于ecu的结构、例如存储器容量的多少来决定。由于根据ecu的种类，在处理中需要的资源的量某种程度上是被确定的，所以ecu的结构还与ecu的种类有关联。即，恢复处理的方式也可以说是基于ecu的种类决定的。因此，能够根据ecu的结构或ecu的种类来实施适当的恢复处理。

(6)恢复控制信息502包含与恢复处理的方式对应的恢复数据。因此，网关10能够使用恢复控制信息502中包含的恢复数据执行恢复处理。

(7)恢复控制信息502包含用于画面显示的信息即显示内容50213，软件更新装置具备显示控制部即恢复控制部10004，该显示控制部基于用于画面显示的信息，向hmi12输出用来显示如图13(c)、图15(c)、图17(c)、图19(c)、图21(c)、图23(c)所示的画面作为向车辆1的乘员即用户告知由恢复处理造成的车辆1的功能限制状态的画面的信号。

因此，网关10能够向用户告知在恢复处理的执行中车辆1的功能怎样受到限制，通过向用户传达状况，能够使用户的方便性提高。

(变形例1)

在上述的实施方式中，网关10承担将搭载在各个ecu中的控制程序更新的所谓软件更新装置的作用。但是，也可以将上述网关程序100具有的功能搭载在通信模块11或hmi12中。进而，也可以是连接在车内网络10a或10b上的未图示的其他装置具备网关程序100具有的功能。

(变形例2)

在上述的第1实施方式中，设为网关10如果对恢复数据uri50215进行访问则能够得到被压缩的软件。但是，由恢复数据uri50215识别的资源也可以是用来从更新后的软件向现行的软件回滚的差分数据、软件的块的xor数据、还有损坏的块的数据。并且，网关10执行适合于接收到的数据的处理。

(变形例3)

在恢复控制信息502中包含的恢复数据uri50215中，在恢复方式50214是“服务器协同”以外的情况下，设定了意味着没有被设定信息的“null”。但是，在恢复数据包含于ecu恢复控制信息502中的情况下，也可以在恢复数据uri50215中设定表示该情况的“local”。

(变形例4)

在第1实施方式中，恢复被定义为：在因更新处理的异常而软件没有转变为更新完成状态的情况下，使得转变为更新完成状态。但是，也可以将恢复设为：在因更新处理的异常而软件没有转变为更新完成状态的情况下，使得转变为更新前状态。换言之，也可以将所谓的回滚作为恢复。在此情况下，在ecu恢复数据5022中包含为了执行回滚而需要的信息、例如更新前的软件的块间的xor数据，恢复控制部10004使用ecu恢复数据5022执行回滚。

(变形例5)

网关10也可以在执行恢复处理时比通常更多地使用网络带宽。例如网关10通常将每1秒的数据发送次数或每1秒发送的数据量设定为相对于网络的负荷拥有充分的富余。并且，网关10在执行恢复处理时容许比通常多的数据发送次数或比通常多的数据量。由此，能够迅速地执行恢复处理。

此外，网关10也可以代替比通常更多地使用网络带宽，或者在比通常更多地使用网络带宽的同时，将与恢复处理相关联的数据帧的优先级设定为比通常高。

进而，网关10也可以不是对全部的恢复处理比通常更多地使用网络带宽，而是仅在特定的条件下比通常更多地使用网络带宽。特定的条件例如是指ecu恢复控制信息5021的显示内容50213是“紧急”、或在恢复方式50214中明示了使带宽增加。

(变形例6)

ecu更新控制信息5012中包含的更新控制次序与ecu恢复控制信息5021的恢复方式50214的组合也可以是特定的组合。例如也可以是更新控制次序为差分更新、恢复方式50214为压缩恢复的组合。

图25是表示在变形例6中更新对象仅为制动器控制ecu14的情况下的更新包5d的结构的图。制动器控制ecu更新控制信息5012d如图25(b)所示，例如由识别ecu的ecuid50121d、表示开始更新的定时的开始定时50122d、表示更新控制次序的更新方式50124d构成。由于更新方式50124d是差分更新，所以制动器控制ecu更新数据5013d是最新软件与现行软件的差分数据。由于恢复方式50214d是压缩恢复，所以制动器控制ecu恢复数据5022d是被压缩的最新软件。

在此情况下，通常在短时间中处理完成的更新方式执行差分更新，在更新中发生了异常的情况下，通过进行软件的全区域的写入，能够可靠地进行恢复。因此，能够兼顾处理的迅速性和安全性的确保。

另外，也可以是，更新控制次序为差分更新，恢复方式50214为服务器协同，基于恢复数据uri取得的数据是被压缩的最新版的软件。

此外，在将“恢复”的定义设为在因更新处理的异常而软件没有转变为更新完成状态的情况下使得转变为更新完成状态或更新前状态的情况下，图25所示的例子也可以如下所述。即，也可以是，制动器控制ecu更新数据5013d是最新软件与现行软件的差分数据，制动器控制ecu恢复数据5022d是被压缩的现行的软件。

―第2实施方式―

参照图26～图27，说明软件更新系统s的第2实施方式。在以下的说明中，对于与第1实施方式相同的构成部件赋予相同的标号，并主要说明不同点。关于没有特别说明的点，与第1实施方式相同。在本实施方式中，主要在被更新软件的ecu中保存有恢复控制信息这一点上与第1实施方式不同。

(结构)

第2实施方式的网关10的硬件结构及网关程序100的结构与第1实施方式是同样的。但是，网关程序100的动作如后述那样一部分不同。

第2实施方式的ecu的硬件结构与第1实施方式是同样的。说明ecu的控制程序的结构。

图26是表示在第2实施方式的发动机控制ecu13上动作的控制程序130的结构的框图。但是，在本实施方式中作为被更新软件的对象的ecu都至少具备与图26所示的控制程序130同样的结构。

第2实施方式的控制程序130除了第1实施方式的结构以外还具备恢复控制信息13007的存储区域。该恢复控制信息13007中包含与第1实施方式的恢复控制信息502同样的信息。但是，恢复控制信息13007仅保存关于保存恢复控制信息13007的ecu即发动机控制ecu13的信息。换言之，恢复控制信息13007中包含1个ecu恢复控制信息，最多包含1个ecu恢复数据。恢复控制信息13007既可以在发动机控制ecu13的工厂出厂时预先设定，也可以在出厂后设定。恢复控制信息13007以外的构成要素与图4(b)的结构是同样的。

(恢复控制信息的取得动作)

图27是表示网关10从发动机控制ecu13取得恢复控制信息13007的处理的顺序图。网关10在将发动机控制ecu13的控制软件更新之前，例如在更新的紧前，如以下这样从发动机控制ecu13取得恢复控制信息13007。

网关10的更新控制部10001向发动机控制ecu13发送恢复控制信息取得请求(s801)。发动机控制ecu13的更新控制部13001如果接收到恢复控制信息取得请求，则读出恢复控制信息13007，将其向网关10发送(s802)。接收到该信息的网关10使用接收到的恢复控制信息13007，与第1实施方式同样地执行恢复处理。

另外，这里以发动机控制ecu13为例进行了说明，但其他的ecu也能够以同样的结构及次序实施。

根据上述的第2实施方式，能得到以下的作用效果。

(1)ecu具备作为在该ecu的恢复处理中使用的信息的恢复控制信息13007的存储区域，根据来自网关10的请求而提供恢复控制信息13007。

因此，网关10能够将与各个ecu的恢复处理有关的信息不是从经由互联网3连接的服务器2取得，而是从在物理上较近地存在的ecu取得而进行恢复处理。此外，在因ecu的追加·更换等而发生了实际的车辆的结构与由服务器2管理的车辆的结构的不一致的情况下，不能从服务器取得适当的恢复控制信息，但在服务器2与实际的车辆系统的结构中发生了差异的情况下也能够适当地进行恢复控制。

―第3实施方式―

参照图28～图30，说明软件更新系统s的第3实施方式。在以下的说明中，对于与第1实施方式相同的构成部件赋予相同的标号，并主要说明不同点。关于没有特别说明的点，与第1实施方式相同。在本实施方式中，主要在将恢复控制信息按每个中断原因保存这一点上与第1实施方式不同。此外，本实施方式的“恢复”还包括在因更新处理的异常而软件没有转变为更新完成状态、并且因致命性的异常而不能转变为更新完成状态的情况下，向用户通知该情况的动作。用户根据该通知，能够确认在车辆中发生了致命性的异常的情况，采取向经销商联络等必要的手段。

(结构)

第3实施方式的网关10的硬件结构及网关程序100的结构与第1实施方式是同样的。但是，网关程序100的动作如后述那样一部分不同。

第3实施方式的ecu的硬件结构与第1实施方式是同样的。

图28(a)是第3实施方式的更新包5的结构例。如图28(a)所示，第3实施方式的更新包5的结构与第1实施方式是同样的，在ecu恢复控制信息中使用标号5023这一点、以及如以下说明那样ecu恢复控制信息5023的结构与第1实施方式不同。

图28(b)是表示第3实施方式的ecu恢复控制信息5023的结构的图。ecu恢复控制信息5023除了第1实施方式的ecu恢复控制信息5021的结构以外，还具备1个恢复控制信息数50231及1个以上的中断原因50232。并且，在ecu恢复控制信息5023中，包含与各个中断原因50232对应的开始定时50212、显示内容50213、恢复方式50214及恢复数据uri50215。恢复控制信息数50231表示在ecu恢复控制信息5023中包含几个中断原因50232。中断原因50232表示更新中断的原因。以下，将ecu恢复控制信息5023中包含的中断原因50232、开始定时50212、显示内容50213、恢复方式50214及恢复数据uri50215的组合称作分原因恢复控制信息50230。

(动作例)

使用图29及图30，关于自动驾驶ecu15，表示按每个中断原因进行不同的恢复控制的情况下的恢复控制信息5023a的结构例，向hmi12的显示例、更新状态d1a的结构例及动作次序。

第3实施方式的恢复控制信息5023a如图29(a)所示，由ecuid50211a、恢复控制信息数50231a及分原因恢复控制信息50230a构成。在ecuid50211a中被设定“自动驾驶ecu”，在恢复控制信息数50231中被设定“2”，在第1中断原因50232a中被设定“电源断开·通信断开”，在开始定时50212a中被设定“行驶开始”，在显示内容50213a中被设定“提醒注意”及未图示的显示消息信息，在恢复方式50214a中被设定“差分继续恢复”，在恢复数据uri50215a中被设定意味着没有被设定信息的“null”。在第2中断原因50232a2中被设定“立即”，在开始定时50212a2中被设定“立即”，在显示内容50213a2中被设定“紧急”及作为未图示的显示消息信息而促使向经销商的指引的信息，在恢复方式50214a2中被设定意味着没有被设定信息的“null”，在恢复数据uri50215a2中被设定意味着没有被设定信息的“null”。

恢复控制部10004基于显示内容50213a2，使hmi12的显示装置输出图29(b)所示的画面显示g10a2。该画面显示g10a2是表示软件的更新因致命的错误而被中断、为了恢复需要向经销商联络的显示。

第3实施方式的更新状态d1a如图29(c)所示，除了第1实施方式的更新状态d1的信息以外还具备中断原因d106。中断原因d106是保存更新中断的原因的字段，例如保存“电源断开”“通信断开”“from故障”等。

记录d11a在第3实施方式中是表示自动驾驶ecu15的更新状态的记录，在中断原因d106的字段中保存有“from故障”。通过这样记录中断原因d106，能够识别更新中断的原因而开始适当的恢复处理。

图30是表示第3实施方式的自动驾驶ecu15的恢复处理的1例的顺序图。例如，在自动驾驶ecu15的更新处理因向网关10的电源供给断开等而被中断后重新开始电源供给后、或如果在因自动驾驶ecu15的from的故障而中断后点火再次被开启，则如以下这样执行恢复处理。

如果网关10起动，则首先在步骤s901a中确认中断中的更新的有无(图11的s701、s702，图30的s901a)。

此外，与网关10的处理并行地，在自动驾驶ecu15中进行图10(b)所示的起动处理。这里，由于更新中断、起动信息d33还没有被改写、记录在程序区1313bp0中的控制程序的起动已被指定，所以自动驾驶ecu15将现行的版本2的控制程序p4起动。

网关10如果根据更新状态d21的更新开始状态d102判定为自动驾驶ecu15的更新中断(s901a)，则在步骤s910a2中进行以下的处理。即，网关10从更新状态d1a中读出与自动驾驶ecu15相应的中断原因d106，判定中断原因。在中断原因是“电源断开·通信断开”的情况下(s910a2：“通信断开·电源断开”)，接着，在步骤s911a2中，从自动驾驶ecu恢复控制信息5023a读出中断原因是“电源断开·通信断开”的恢复控制信息，进行基于恢复控制信息的恢复处理。基于中断原因是“电源断开·通信断开”的恢复控制信息的恢复处理与图14的从步骤s903a到步骤s909a的处理相同。在中断原因是“from故障”的情况下(s910a2：“from故障”)，接着，在步骤s912a2中从自动驾驶ecu恢复控制信息5023a读出中断原因是“from故障”的恢复控制信息，进行基于恢复控制信息的恢复处理。

基于中断原因是“from故障”的恢复控制信息的恢复处理以图30(b)所示的次序进行。即，网关10从与自动驾驶ecu15相应的自动驾驶ecu恢复控制信息5023中读出中断原因是“from故障”的情况下的开始定时50212a2，判定为开始自动驾驶ecu15的恢复处理的定时是立即。接着，网关10在步骤s903a2中从自动驾驶ecu恢复控制信息5023读出中断原因是“from故障”的情况下的显示内容50213a2，向hmi12发出显示基于显示内容50213a2的紧急画面的请求(s911a2)。hmi12基于该请求，将在图29(b)的g10a2中例示的紧急画面显示在显示装置上(s912a2)。

根据上述的第3实施方式，能得到以下的作用效果。

(1)恢复控制信息5023具备每个异常原因的恢复控制信息，网关10根据异常原因来选择所应用的恢复处理。

根据中断原因，可应用的恢复处理有可能不同，如在更新中断的原因是from的故障的情况下等，需要硬件的更换等，难以以系统单独进行恢复等。通过如上述那样构成恢复控制信息5023并使用它，网关10例如在ecu中发生了致命性的异常的情况和不是那样的情况下能够执行不同的恢复处理，向用户传达适当的信息。

另外，本发明并不限定于上述的实施例，而包括各种各样的变形例。例如，上述的实施例是为了容易理解地说明本发明而详细地说明的，并不一定限定于具备所说明的全部结构。此外，可以将某个实施例的结构的一部分替换为其他实施例的结构，此外，也可以对某个实施例的结构添加其他实施例的结构。此外，也可以对各实施例的结构的一部分进行其他结构的追加、删除、替换，或将各处理的处理的顺序替换。例如，在本实施方式中，假设软件更新装置是网关10，但也可以是通信模块11或hmi12为软件更新装置。

此外，上述的各结构、功能、处理部、处理机构等，也可以通过将它们的一部分或全部用例如用集成电路设计等而由硬件实现。此外，上述的各结构、功能等也可以通过由处理器对实现各个功能的软件进行解释并执行而由软件实现。

此外，关于控制线及信息线，表示了认为在说明上需要的部分，并不一定在产品上表示了全部的控制线及信息线。实际上也可以认为几乎全部的结构被相互连接。

在上述中说明了各种实施方式及变形例，但本发明并不限定于这些内容。在本发明的技术思想的范围内想到的其他形态也包含在本发明的范围内。

这里将下面的优先权基础申请的公开内容作为引用文来引用。

日本专利申请2016年第202767号(2016年10月14日提出申请)

标号说明

s…软件更新系统

1…车辆

2…服务器

10…网关

13…发动机控制ecu

14…制动器控制ecu

10001…更新控制部

10004…恢复控制部

10005…恢复控制信息管理部

502…ecu恢复控制信息

5021…ecu恢复控制信息

5022…ecu恢复数据

50212…恢复开始定时

50212…开始定时

50213…显示内容

50214…恢复方式