信息更新装置、信息更新方法与流程

本发明涉及信息更新装置和信息更新方法。

背景技术：

近年来，由于驾驶辅助功能、自动驾驶技术的发展，搭载于汽车用的电子控制装置(ecu：electriccontrolunit)中的软件的规模正在扩大。另外伴随着软件的规模扩大，不只是因软件的问题造成的召回的次数增加，每一次需要应对的台数的也增加了。因此，对远程地更新搭载在于ecu中的软件的技术的需求提高了。在远程地更新软件的情况下，要求更新处理的自动化。

在专利文献1中，公开了一种软件更新装置，其与服务器和多个控制装置连接而进行数据的收发，其特征在于，该软件更新装置具备：第一通信部，其针对上述多个控制装置的每个控制装置，从上述服务器接收包含更新数据、用于识别为了将上述更新数据应用于控制装置的适用方法的识别信息的更新控制信息；第二通信部，其向上述多个控制装置的每个控制装置发送所应用的上述更新数据；更新控制部，其经由上述第二通信部控制上述多个控制装置，以便根据上述识别信息应用上述更新数据。

现有技术文献

专利文献

专利文献1：日本特开2016-170740号公报

技术实现要素：

发明要解决的问题

在专利文献1记载的发明中，更新处理的灵活性不充分。

解决问题的方案

本发明的第一方式的信息更新装置是将存储在车辆用控制装置中的第一信息更新为第二信息的信息更新装置，该信息更新装置具备：下载控制部，其接收包含上述第一信息与上述第二信息的差分或作为上述第二信息的更新本体、步骤信息以及启动条件的更新包，上述步骤信息包含使用上述更新本体将上述第一信息更新为上述第二信息的步骤上述启动条件是开始将上述第一信息更新为上述第二信息的条件；事件管理部，其取得搭载有上述车辆用控制装置和信息更新装置的车辆的状态，在上述车辆的状态符合上述启动条件时，使更新执行部执行基于上述步骤信息的上述更新。

本发明的第二实施例的信息更新方法是由计算机将存储在车辆用控制装置中的第一信息更新为第二信息的信息更新方法，该信息更新方法包括：接收包含上述第一信息与上述第二信息的差分或作为上述第二信息的更新本体、步骤信息以及启动条件，上述步骤信息包含使用上述更新本体将上述第一信息更新为上述第二信息的步骤，上述启动条件是开始将上述第一信息更新为上述第二信息的条件；取得搭载有上述车辆用控制装置和上述计算机的车辆的状态，在上述车辆的状态符合上述启动条件时，执行基于上述步骤信息的上述更新。

发明效果

根据本发明，能够进行灵活的更新处理。

附图说明

图1是表示第一实施方式的软件更新系统s的结构的图。

图2是表示网关10的硬件结构的框图。

图3是表示网关程序100的结构的框图。

图4是表示更新控制部10001的结构的框图。

图5是表示更新状态d1的一个例子的图。

图6是表示第一实施方式的更新包5的结构的图。

图7是脚本启动控制信息502的结构例子。

图8是表示网关程序100的各结构要素的动作的时序图。

图9是更新包5的具体例子。

图10是全控制信息502z的具体例子。

图11是对象ecu一览504的具体例子。

图12是脚本对应表505的具体例子。

图13是表示在动作例子中车辆1具备的装置的动作概要的时序图。

图14是表示自动驾驶ecu更新脚本5111的具体例子的图。

图15是表示自动驾驶ecu更新脚本5111的执行所伴随的网关程序100的动作的时序图。

图16是表示确认用脚本5113的具体例子的图。

图17是表示确认用脚本5113的执行所伴随的网关程序100的动作的时序图。

图18是表示第二实施方式的更新控制部10001a的结构的框图。

图19是表示脚本启动控制信息502a的结构的图。

图20是表示脚本启动处理的时序图。

图21是第二实施方式的更新包5的具体例子。

图22是第二实施方式的全控制信息502z的具体例子。

图23是表示第二实施方式的软件更新处理的流程的时序图。

图24是第二实施方式的确认用脚本5113a的具体例子。

图25是表示确认用脚本5113a的执行所伴随的网关程序100的动作的时序图。

图26是表示第二实施方式的诊断通信服务调用处理的流程的时序图。

具体实施方式

第一实施方式

以下，参照图1～图17，说明第一实施方式的软件更新系统。此外，在本实施方式中，说明软件的更新，但更新对象并不限于软件，也能够应用于参数、数据等。此外，在本实施方式中，也将更新后的软件称为“新程序”，也将更新前的软件称为“旧程序”。

(系统结构)

图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和自动驾驶ecu15的控制程序的例子。

车内网络由控制局域网(controlareanetwork：can)(注册商标)、本地互联网(localinterconnectnetwork：lin)、flexray、以太网(ethernet)(注册商标)等构成。在本实施方式中，车内网络10b由can构成，车内网络10a由以太网构成。另外，在图1中虽然没有图示，但各种ecu等车辆内的各结构要素通过电力线与蓄电池连接，接受供电。但是，此处所示的车内网络的结构是一个例子，网络的种类、数量并不限于此。

网关10在各种ecu之间进行通信数据的中继，并且作为软件更新装置，进行搭载于本设备和经由车内网络连接的ecu中的软件的更新。即，在本实施方式中，详细说明该网关10的动作。网关10在每次启动时，即在每次车辆1的点火器接通时，向服务器2请求软件更新所需要的更新包5。在有应该更新的信息的情况下，服务器2向网关10发送更新包5。将在后面说明更新包5的结构。

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

服务器2具备未图示的cpu、rom、以及ram，向网关10发送软件更新所需要的更新包5。网关10根据更新包5所包含的数据，更新各ecu的软件。

(网关的结构)

图2是表示网关10的硬件结构的框图。网关10具备微机101、from(闪存rom)102、can用的通信i/f104、以及以太网用的通信i/f105。微机101具备cpu1011、sram1012、from1013、can通信控制器1014、以及以太网通信控制器1015。微机101的cpu1011执行存储在from1013中的程序，控制网关10内的其他结构要素，并且与通过车内网络连接的其他设备进行数据收发指示等，使网关10发挥作用。

from1012是非易失性存储器，存储接收到的更新包5。通信i/f104是can通信用的接口，根据微机101的指示，经由车内网络10b，在与连接到车内网络10b的ecu之间，进行数据的收发。通信i/f105是因特网通信用的接口，根据微机101的指示，经由车内网络10a，在与连接到车内网络10a的设备之间，进行数据的收发。

图3是表示在网关10上进行动作的网关程序100的结构的框图。实现网关10的功能的网关程序100被存储在微机101的from1013中，通过cpu1011执行。在图3中，将功能概括表现为程序块，既可以将各程序块分割为多个，也可以合并几个程序块。另外，控制程序既可以通过一个软件实现，也可以通过2个以上的软件的组合实现。

网关程序100具备更新控制部10001、更新数据管理部10002、更新状态管理部10003、车辆状态管理部10006、以及通信控制部10007。

更新控制部10001经由通信控制部10007与连接到车内网络10a的设备进行通信，取得更新包5、发送车辆的状态、软件更新处理的状况。更新控制部10001取得的更新包5被存储在from102中。将在后面说明更新包5的结构。更新控制部10001经由通信控制部10007与连接到车内网络10b的ecu进行通信，控制该ecu，更新搭载于该ecu中的软件。虽然将在后面详细说明，但是根据经由更新数据管理部10002取得的更新包5和经由车辆状态管理部10006取得的车辆系统状态，实施软件的更新。

更新数据管理部10002从from102取得更新包5，提供到更新控制部10001。更新状态管理部10003从更新控制部10001取得更新状态，作为更新状态d1存储到from1013中。另外，将存储的更新状态d1提供到更新控制部10001。车辆状态管理部10006经由通信控制部10007与连接到车内网络10a和10b的设备进行通信，取得车辆系统的状态，将车辆状态提供到更新控制部10001。车辆状态例如是指点火器的接通、关断、行驶的开始等。

通信控制部10007依照更新控制部10001等的指示，控制can通信控制器1014和以太网通信控制器1015，与连接到车内网络10a和10b的设备进行通信。在与连接到车内网络10a的设备进行通信时，通信控制部10007解析、生成tcp/ip、udp/ip等的数据包。另外，在与连接到车内网络10a的设备进行通信时，通信控制部10007解析、生成can帧。

图4是表示作为通过网关10执行程序而实现的功能之一的更新控制部10001的结构的框图。更新控制部10001具备事件管理部100011、控制部100012、脚本执行部100013、服务提供部100014、以及下载控制部100015。但是，在本实施方式中，脚本是指针对网关10的动作指令，在脚本中包含条件式、控制句、以及指令的执行命令。在本实施方式中，脚本是指shell脚本、通过perl、python等解释器解释的文本文件。

事件管理部100011检测车辆1的状态变化、下载完成等事件，向控制部100012传达事件的发生。控制部100012依照从事件管理部100011传达的事件的发生，进行向脚本执行部100013的脚本的执行指示、向下载控制部100015的下载开始指示。脚本执行部100013解析并执行从控制部100012指示的脚本。另外，脚本执行部100013如果从控制部100012接受了中断指令，则中断脚本的执行。

服务提供部100014向脚本执行部100013提供车辆状态取得、更新状态的记录、读出、诊断通信功能等服务。在诊断通信服务中，以uds(universaldiagnosticservice：通用诊断服务)等诊断通信协议为基准，生成/解析指令。另外，经由通信控制部10007，进行所生成的指令的发送和响应的接收。下载控制部100015经由通信控制部10007与连接到车内网络10a的通信模块11进行通信，从服务器2取得更新包5。

这样，事件管理部100011检测车辆状态、更新状态的变化作为事件，进行脚本启动的判定，由此能够在任意的定时开始执行必要的处理。另外，经由服务提供部100014取得、记录在更新控制部10001以外管理的更新状态，由此能够适当地对难以从脚本直接访问的非易失性存储器等进行写入、读出。

(更新状态d1)

图5是表示由网关10的更新状态管理部10003管理的更新状态d1的一个例子的图。在图5中，示出了将更新状态d1作为表格进行管理并记录每个ecu的更新状态的情况下的例子。更新状态d1具有ecuidd101、更新开始状态d102、完成程序块d103的字段。ecuidd101是存储用于识别ecu的信息的字段。更新开始状态d102是存储表示该ecu的更新处理是否已经开始的识别信息的字段，例如存储“未开始”、“已经开始”、或“更新完”。完成程序块d103是存储处理已成功的程序块的识别信息、例如程序块编号的字段。

用附图标记d11表示的第一个记录是表示自动驾驶ecu15的更新状态的记录。在该记录的ecuidd101的字段中存储有“自动驾驶ecu”，在更新开始状态d102的字段中存储有表示正在更新处理的“已经开始”，在完成程序块d103的字段中存储有表示最后处理完成了的程序块是程序块n的“blockn”。

附图标记d12所表示的第二个记录是表示引擎控制ecu13的更新状态的记录。在该记录的ecuidd101的字段中存储有“引擎控制ecu”，在更新开始状态d102的字段中存储有表示没有开始更新处理的“未开始”。在此，没有开始引擎控制ecu13的更新，因此在完成程序块d103的字段中没有设定值。

在此，说明了2个记录，在以下的情况下制作这些记录。即，在网关10接收到的更新包5中记载为更新对象的ecu的情况下，进行制作。另外，如后述那样，逐次地记录该更新状态d1。通过这样逐次地记录更新状态d1，能够在更新中断后正常地恢复而启动时不完成更新而进行中断、识别更新中断了的位置并开始适当的处理。

(更新包5)

图6是表示网关10从服务器2取得的更新包5的结构的图。更新包5由1个或多个更新用脚本501、1个或多个脚本启动控制信息502、1个或多个ecu更新数据503、对象ecu一览504、脚本对应表505构成。将更新包5包含的全部更新用脚本501汇总，称为全脚本501z。将更新包5包含的全部脚本启动控制信息502汇总，称为全控制信息502z。将更新包5包含的全部ecu更新数据503汇总，称为全更新数据503z。

在更新包5中存在一个以上的更新用脚本501。在更新用脚本501中记述了软件的更新所需要的步骤。更新包5包含的更新用脚本501的数目与更新对象的ecu的数目同等或以上。以能够通过脚本执行部100013执行的形式描述更新用脚本501。记述为脚本的处理、即更新所需要的步骤例如是向更新对象的ecu发送的控制指令的种类及其顺序、车辆状态的确认、向用户取得允许、对每个ecu的复原处理、以及更新后的软件的激活处理等。

在更新包5中存在一个以上的脚本启动控制信息502。脚本启动控制信息502与更新用脚本501相同数目而包含在更新包5中，与各个更新用脚本501对应。在脚本启动控制信息502中，记述了更新用脚本501的控制、即启动和中断所需要的信息。将在后面详细说明脚本启动控制信息502。

在更新包5中存在一个以上的ecu更新数据503。在ecu更新数据503中存储有软件的更新所需要的数据。具体地说，ecu更新数据503是表示写入目标的地址信息等的元数据、软件自身、压缩后的软件、或新旧软件的差分数据。ecu更新数据503也就是更新本体，为了辅助使用作为更新本体的ecu更新数据503进行的软件更新，而存在更新包5包含的其他信息。更新包5包含的ecu更新数据503的数目与更新对象的ecu的数目相同。

在更新包5中存在一个对象ecu一览504。在对象ecu一览504中存储表示成为更新包5的更新对象的ecu的一览的信息。在更新包5中存在一个脚本对应表505。在脚本对应表505中存储表示更新用脚本501、ecu更新数据503、成为更新对象的ecu之间的对应关系的信息。

这样，在更新包5中包含脚本启动控制信息502，由此能够进行控制使得在必要的定时启动必要的处理。

图7是脚本启动控制信息502的结构例子。脚本启动控制信息502由对象脚本5021、启动条件5022、以及中断条件5023构成。启动条件5022由启动事件50221、顺序50222、以及更新状态50223构成。中断条件5023由中断事件50231构成。但是，启动条件5022和中断条件5023也可以包含其他结构要素。

对象脚本5021表示成为该脚本启动控制信息502的启动对象的更新用脚本501。启动事件50221表示成为启动由对象脚本5021指定的更新用脚本501的契机的事件。此处所述的事件是指点火器的接通、关断、车辆1的行驶开始等车辆状态的变化、下载的完成等。中断事件50231表示成为中断由对象脚本5021指定的更新用脚本501的执行的契机的事件。顺序50222表示针对一个事件启动多个脚本的情况下的启动顺序。更新状态50223表示用于在发生该事件时判断是否能够启动脚本的更新状态。

这样，在脚本启动控制信息502中包含与车辆状态和更新状态的变化对应的启动事件50221，由此能够定义得在必要的定时启动必要的处理。另外，在脚本启动控制信息502中包含中断事件50231，由此能够定义为与车辆状态等的变化对应地，在必要的定时中断所执行的脚本。另外，在脚本启动控制信息502中在启动条件5022中包含顺序50222，由此在希望根据一个事件启动多个脚本的情况下，能够进行适当的控制。另外，在启动条件5022中包含更新状态50223，由此能够与更新的进度对应地启动适当的脚本。

(时序图)

图8是表示软件的更新中的网关程序100的各结构要素的动作的时序图。在后面另外说明表示更新用脚本501的动作的时序图。

事件管理部100011为了监视车辆1的状态，分别从车辆状态管理部10006和更新状态管理部10003取得车辆状态、更新状态(s101、s102)。事件管理部100011在状态取得的结果是检测出状态变化的情况下(s103的是)，经由更新数据管理部10002读出更新包5包含的脚本启动控制信息502(s104)。状态变化例如是指点火器从关断变为接通、点火器从接通变为关断、更新包5的下载完成等。

接着，事件管理部100011在读出的脚本启动控制信息502中，检索是否有应该与检测出的事件对应地启动的脚本(s105)。在有应该启动的更新用脚本501的情况下(s105的是)，事件管理部100011确认启动条件5022的顺序50222和更新状态50223。然后，事件管理部100011经由控制部100012向脚本执行部100013进行启动请求，使得按照指定的顺序，执行符合更新状态的更新用脚本501(s106)。脚本执行部100013执行指定的更新用脚本501(s107)，经由控制部100012向事件管理部100011返回响应(s108)。

事件管理部100011根据执行结果和取得的脚本启动控制信息，确认是否存在下一个应该启动的更新用脚本501(s109)，在有启动的脚本的情况下，启动下一个更新用脚本501(s109的是)。另外，在没有下一个启动对象的情况下(s109的否)，结束处理。事件管理部100011在脚本执行部100013执行更新用脚本501时，也监视车辆状态和更新状态，检测启动控制信息所包含的中断事件的发生(s110)。如果检测出中断事件50231的发生，则经由控制部100012向脚本执行部100013输出中断指令(s111)。

这样，通过事件管理部100011检测车辆状态、更新状态的变化事件，启动更新用脚本501，由此能够在任意的定时开始执行必要的处理。另外，事件管理部100011检测车辆状态、更新状态的变化事件，进行中断更新用脚本501的执行的判定，由此能够在任意的定时中断必要的处理。另外，在更新用脚本501以及从服务器2取得的脚本启动控制信息502中，还包含启动事件50221、中断事件50231，由此能够针对每个更新内容，变更成为开始更新的契机的事件。

另外，启动条件5022包含顺序50222，根据它启动更新用脚本501，由此能够将一个事件作为契机，按照适当的顺序启动多个更新用脚本501。在此，示出了持续地读出状态的例子，但也可以预先由事件管理部100011将通知对象的状态变化登记到车辆状态管理部10006和更新状态管理部10003。在该情况下，车辆状态管理部10006和更新状态管理部10003根据登记的信息，向事件管理部100011通知事件的发生。

(动作例子)

以下，使用图9～图17，说明更新自动驾驶ecu15和引擎控制ecu13的情况下的动作例子。在此，自动驾驶ecu15由2片rom构成，在车辆1正在行驶的状态下也能够进行写入。另一方面，引擎控制ecu13在引擎控制中、即在车辆1的行驶中无法进行写入，只能够在点火器关断后进行写入。

如果网关10接收到更新包5，则自动驾驶ecu15根据网关10的动作指令，立即进行新的软件的写入，如果从网关10接收到激活命令，则将新的软件设为有效。即使网关10接收到更新包5，引擎控制ecu13也不马上执行更新。如果车辆1的点火器关断，则网关10使引擎控制ecu13开始软件的更新。

(动作例子：更新包5)

图9是动作例子的更新包5的具体例子。更新包5如上述那样由1个或多个更新用脚本501、1个或多个脚本启动控制信息502、1个或多个ecu更新数据503、对象ecu一览504、脚本对应表505构成。在图9所示的例子中，自动驾驶ecu更新脚本5111、引擎控制ecu更新脚本5112、确认用脚本5113、以及新程序激活用脚本5114分别是更新用脚本501。另外，自动驾驶ecu更新脚本启动控制信息5121、引擎控制ecu更新脚本启动控制信息5122、确认用脚本启动控制信息5123、以及新程序激活用脚本启动控制信息5124分别是脚本启动控制信息502。另外，自动驾驶ecu更新数据5131和引擎控制ecu更新数据5132分别是ecu更新数据503。

自动驾驶ecu更新脚本5111是描述了用于使用自动驾驶ecu更新数据5131向自动驾驶ecu15写入新程序的步骤的脚本。具体地说，描述了以下的步骤：使用诊断通信从网关10向自动驾驶ecu15转送新程序，向自动驾驶ecu15写入新程序。引擎控制ecu更新脚本5112是记述了用于使用引擎控制ecu更新数据5132向引擎控制ecu13写入新程序的步骤的脚本。具体地说，记述了以下的步骤：使用诊断通信从网关10向引擎控制ecu13转送新程序，向引擎控制ecu13写入新程序。

确认用脚本5113是描述了用于确认向引擎控制ecu13的写入、是否是能够执行新程序的激活的状态的步骤的脚本。具体地说，记述了以下的步骤：确认车辆1是否正在停车、即车速是否为零、以及用户是否允许新程序的激活。新程序激活用脚本5114是记述了在向自动驾驶ecu15和引擎控制ecu13写入新程序后在下次启动时使新程序动作所需要的步骤的脚本。具体地说，记述了以下的步骤：向自动驾驶ecu15和引擎控制ecu13发出新程序激活命令。

自动驾驶ecu更新数据5131是自动驾驶ecu15的软件的更新所需要的数据，由记述了写入目标地址等的元数据、写入到自动驾驶ecu15的程序、根据新程序生成的差分数据构成。引擎控制ecu更新数据5132是引擎控制ecu13的软件的更新所需要的数据，由记述了写入目标地址等的元数据、写入到引擎控制ecu13的程序、根据新程序生成的差分数据构成。

构成脚本启动控制信息502的自动驾驶ecu更新脚本启动控制信息5121、引擎控制ecu更新脚本启动控制信息5122、确认用脚本启动控制信息5123、以及新程序激活用脚本启动控制信息5124分别记述了自动驾驶ecu更新脚本5111、引擎控制ecu更新脚本5112、确认用脚本5113、以及新程序激活用脚本5114的启动和中断所需要的信息。参照附图详细说明。

(动作例子：脚本启动控制信息502)

图10是表示更新对象是自动驾驶ecu15和引擎控制ecu13的情况下的全控制信息502z、即更新包5包含的全部脚本启动控制信息502的一个例子的图。在此，为了确保直观性，将全控制信息502z表现为一个表格。即，在图10中记载了多个记录，它们从上起按顺序地对应于自动驾驶ecu更新脚本启动控制信息5121、引擎控制ecu更新脚本启动控制信息5122、确认用脚本启动控制信息5123、以及新程序激活用脚本启动控制信息5124。

图10所示的各个脚本启动控制信息502的结构与图7所示的结构相同。即，各个脚本启动控制信息502由对象脚本5021、启动条件5022、以及中断条件5023构成。启动条件5022由启动事件50221、顺序50222、以及更新状态50223构成。并且，中断条件5023由中断事件50231构成。但是，只在自动驾驶ecu更新脚本启动控制信息5121中设定了2个条件，因此在图10中，跨2行地进行了记载。

图10的最初的记录、即存储在自动驾驶ecu更新脚本启动控制信息5121中的第一个信息如下。在对象脚本5021的字段中存储有“自动驾驶ecu更新用脚本”。在启动事件50221的字段中存储有“dl完成”，表示更新包的下载完成。在顺序50222的字段中存储有“1”，表示在产生该事件时第一个启动。在更新状态50223的字段中存储有“-”，表示无论更新状态如何都进行启动。在中断事件50231的字段中存储有“ign-关断”，表示点火信号为关的定时。

图10的第二个记录、即存储在自动驾驶ecu更新脚本启动控制信息5121中的第二个信息如下。在对象脚本5021的字段中存储有“自动驾驶ecu更新用脚本”。在启动事件50221的字段中存储有“ign-接通”表示点火器成为接通的定时。在顺序50222的字段中存储有“1”，表示在产生该事件时第一个启动。在更新状态50223的字段中存储有“自动驾驶ecu更新未完”，表示自动驾驶ecu更新用脚本向自动驾驶ecu16的数据转送未完成。在中断事件50231的字段中存储有“ign-关断”。

图10的第三个记录、即存储在引擎控制ecu更新脚本启动控制信息5122中的信息如下。在对象脚本5021的字段中存储有“引擎控制ecu更新用脚本”。在启动事件50221的字段中存储有“ign-关断”。在顺序50222的字段中存储有“2”，表示在产生该事件时第二个启动。在更新状态50223的字段中存储有“-”，表示无论更新状态如何都启动。在中断事件50231的字段中存储有“ign-接通”。

图10的第四个记录、即存储在确认用脚本启动控制信息5123中的信息如下。在对象脚本5021的字段中存储有“确认用脚本”。在启动事件50221的字段中存储有“ign-关断”。在顺序50222的字段中存储有“1”，表示在产生该事件时第一个启动。在更新状态50223的字段中存储有“自动驾驶ecu更新完成”，表示只在自动驾驶ecu的更新完成的情况下启动该脚本。此处所述的更新是指自动驾驶ecu更新脚本向自动驾驶ecu15的新程序的写入完成了的状态。在中断事件50231的字段中存储有“ign-接通”。

图10的第五个记录、即存储在新程序激活用脚本启动控制信息5124中的信息如下。在对象脚本5021的字段中存储有“新程序激活用脚本”。在启动事件50221的字段中存储有“ign-关断”，表示点火信号成为关断的定时。在顺序50222的字段中存储有“3”，表示在产生该事件时第三个启动。在更新状态50223的字段中存储有“-”，表示无论更新状态如何都启动。在中断事件50231的字段中存储有“ign-接通”。

(动作例子：对象ecu一览504)

图11是动作例子的对象ecu一览504的具体例子。在图11所示的例子中，本动作例子将自动驾驶ecu15和引擎控制ecu13作为更新对象，因此列举了将自动驾驶ecu15和引擎控制ecu13作为更新对象ecu。

(动作例子：脚本对应表505)

图12是动作例子的脚本对应表505的具体例子。在图12所示的例子中，表示自动驾驶ecu更新脚本5111和自动驾驶ecu更新数据5131和自动驾驶ecu15相对应、以及引擎ecu更新脚本5112和引擎控制ecu更新数据5132和引擎控制ecu13相对应的情况。

(动作例子：时序图)

图13是表示更新自动驾驶ecu15和引擎控制ecu13的情况下的车辆1具备的装置的动作概要的时序图。即，在前面所示的图8中，示出了网关10所包含的网关程序100的各结构要素的动作，但在此后说明的图13中，从比图8更宏观的视角进行说明。另外，图13所示的动作对应于图10所示的全控制信息502z。

如果点火器成为接通(s301)，则网关10经由通信模块11向服务器2进行更新包5的取得请求(s302)。接着，取得根据请求从服务器2发送的更新包5，并保存到网关10的from102中(s303)，并且将更新状态d1设为下载完成。

如果检测出更新包5的下载完成，则事件管理部100011经由更新数据管理部10002读出更新包内的脚本启动控制信息502，将启动事件50221成为“dl完成”的自动驾驶ecu更新脚本5111启动。通过经由控制部100012向脚本执行部100013进行指示，而执行该启动。脚本执行部100013执行自动驾驶ecu更新脚本5111，进行自动驾驶ecu15的更新(s304)。将在后面详细说明s304。自动驾驶ecu15的更新完成，将更新状态d1的自动驾驶ecu15的更新状态d102改写为“完成”。

接着，事件管理部100011如果检测出点火器成为关断(s305)，则读出脚本启动控制信息502。然后，事件管理部100011掌握存在启动事件50221是“ign-关断”的3个脚本的情况，关注于其中的顺序50222是“1”的确认用脚本启动控制信息5123。在该确认用脚本启动控制信息5123中，更新状态d1是“自动驾驶ecu更新完”，因此经由更新状态管理部10003确认自动驾驶ecu15的更新状态d1是“完成”。在此，自动驾驶ecu15的更新状态d1是“完成”，因此事件管理部100011经由控制部100012向脚本执行部100013指示确认用脚本5113的启动。脚本执行部100013执行确认用脚本，进行更新状态d1和用户允许的确认(s306)。将在后面详细说明s306。

如果确认用脚本5113的执行完成，则事件管理部100011经由控制部100012向脚本执行部100013指示启动事件是“ign-关断”、顺序是“2”的引擎ecu更新脚本5112的启动。脚本执行部100013执行该脚本，进行引擎控制ecu13的更新。

如果引擎控制ecu更新脚本5112的执行完成，则事件管理部100011将启动事件是“ign-关断”、顺序是“3”的新程序激活用脚本5114启动。通过经由控制部100012向脚本执行部100013指示，由此进行该启动。脚本执行部100013执行该脚本，进行自动驾驶ecu15和引擎控制ecu13的新程序的激活(s308)。

(动作例子：脚本与动作的对应关系)

参照图14～图17说明脚本的具体例子与动作的对应关系。图14是表示自动驾驶ecu更新脚本5111的具体例子的图。图15是表示自动驾驶ecu更新脚本5111的执行所伴随的网关程序100的动作的时序图。即，图15表示图13的s304的详细内容。图16是表示确认用脚本5113的具体例子的图。图17是表示确认用脚本5113的执行所伴随的网关程序100的动作的时序图。即，图17表示图13的s306的详细内容。此外，图14和图16的左端所记载的数字的序号是脚本的行编号，为了进行说明而记载。

参照图14说明自动驾驶ecu更新脚本5111的记载。在图14的第一行中记载了请求版本信息，在第二行中记载了在版本不是“1.00”的情况下前进到第23行以下的错误处理。此外，在第五行、第十二行等中记载了例外处理的结束，但省略说明。在第四行中记载了发送将会话(session)变更为“行驶中写入模式”的会话变更请求，在第七行中记载了发送将更新状态d1变更为“startota”的请求。在第九行中记载了对变量设定初始值“1”。

在第十～第十五行中记载了将全部的程序块作为对象按顺序向自动驾驶ecu15发送新程序。在第十七行中记载了发送将会话变更为“通常模式”的会话变更请求，在第十九行中记载了发送将更新状态d1变更为“completetransfer”的请求。在第二十一行中记载了向指示了自动驾驶ecu更新脚本5111的执行的控制部100012返回表示正常结束的返回值，在第二十三行以下中记载了向脚本的调用方返回因错误而导致的结束。

参照图15说明脚本执行部100013执行自动驾驶ecu更新脚本5111的情况下的网关程序100的动作。在此，虽然示出了更新自动驾驶ecu15的例子，但本动作基本上对其他ecu也相同。另外，此处的更新是向自动驾驶ecu15的数据转送和写入，不包含新程序的激活。

网关10的控制部100012向脚本执行部100013请求自动驾驶ecu更新脚本5111的启动(s30401)。脚本执行部100013依照自动驾驶ecu更新脚本5111所记述的步骤，实施以下的处理。

脚本执行部100013调用服务提供部100014的诊断通信服务，经由通信控制部10007向自动驾驶ecu15发送版本取得请求(s30402)。根据该请求，服务提供部100014(s30403)和通信控制部10007(s30404)进行动作。s30402是由脚本执行部100013解释并执行图14的第一行的记载。自动驾驶ecu15根据请求，向网关10发送版本信息(s30405)。网关10的服务提供部100014经由通信控制部10007取得版本(s30406)，向脚本执行部100013进行响应(s30407)。

接着，脚本执行部100013解释图14的第二行的记载，将接收到的版本信息与脚本所记载的版本信息进行比较(s30408)，在不一致的情况下结束处理(s30408的否)。此外，也可以代替将成为比较对象的版本信息写入到脚本内，而在更新数据5内保持为元数据。在版本信息与设想一致的情况下(s30408的是)，脚本执行部100013解释并执行图14的第十四行的记载。即，脚本执行部100013调用服务提供部100014的诊断通信服务(s30409)，经由通信控制部10007(s30410)，向自动驾驶ecu15发送会话变更请求(s30411)。

该会话变更请求包含用于进行软件改写的行驶中写入模式的识别信息。在能够接受请求的情况下，在使内部状态转移为会话变更请求所指定的模式后，自动驾驶ecu15向网关10发送接受响应(s30412)。网关10的服务提供部100014经由通信控制部10007取得响应(s30413)，向脚本执行部100013进行响应(s30414)。如果响应是接受响应，则脚本执行部100013解释图14的第七行的记载，记录更新处理已经开始，因此调用服务提供部100014的更新状态保存服务(s30415)。服务提供部100014向更新状态管理部10003请求更新状态的保存(s30416)，向脚本执行部100013响应保存结果(s30417)。

接着，脚本执行部100013解释图14的第十行～第十五行的记载，如以下这样进行伴随着循环控制的程序块转送处理s30460。即，在图15中用虚线围住的程序块转送处理s30460相当于图14中的循环内的处理，具体地说相当于从第十一行到第十四行的处理。程序块转送处理s30460的详细内容如下。

为了发送自动驾驶ecu更新数据5131包含的新程序或压缩后的新程序或差分数据的一个程序块，脚本执行部100013调用服务提供部100014的诊断通信服务(s30421)。服务提供部100014如果接受了数据转送的诊断通信服务执行请求，则首先经由通信控制部10007向自动驾驶ecu15发送转送开始请求(s304222、s30423)。自动驾驶ecu15在能够接受请求的情况下，向网关10发送接受响应(s30424)。

如果经由通信控制部10007取得了响应(s30425)，则服务提供部100014经由通信控制部10007向自动驾驶ecu15转送新程序或压缩后的新程序或差分数据的1个程序块的一部分(s30426、s30427)。如果接收到数据，则自动驾驶ecu15向网关10发送接收响应(s30428)。服务提供部100014经由通信控制部10007接收响应(s30429)。直到通过上一个转送开始请求所请求的数据大小量的发送结束为止，服务提供部100014重复进行数据转送处理(s30460)。如果数据转送完成，则服务提供部100014经由通信控制部10007(s30430)，向自动驾驶ecu15发送转送完成通知(s30431)。

自动驾驶ecu向网关10发送接受响应(s30432)。服务提供部100014经由通信控制部10007接收响应(s30433)，向脚本执行部100013响应转送结果(s30434)。如果响应成功，则脚本执行部100013解释图14的第十四行的记载，并为了对该程序块转送完成进行记录，而调用服务提供部100014的更新状态保存服务(s30435)。服务提供部100014向脚本执行部100013请求保存更新状态(完成程序块)(s30436)，向脚本执行部100013响应保存结果(s30437)。以上是程序块转送处理s30460的详细内容。直到转送更新数据所包含的全部程序块为止，脚本执行部100013重复进行程序块转送处理s30460。

如果全部程序块的转送完成，则脚本执行部100013解释图14的第十七行的记载，调用服务提供部100014的诊断通信服务(s30438)，经由通信控制部10007(s30439)，向自动驾驶ecu15发送会话变更请求(s30440)。该会话变更请求包含通常模式的识别信息。自动驾驶ecu15在能够接受请求的情况下，在使内部状态转移为会话变更请求所指定的模式后，向网关10发送接受响应(s30441)。网关10的服务提供部100014经由通信控制部10007取得响应(s30442)，向脚本执行部100013进行响应(s30443)。

如果响应是接受响应，则脚本执行部100013解释图14的第十九行的记载，为了对已经更新完成进行记录，调用服务提供部100014的更新状态保存服务(s30444)。服务提供部100014向脚本执行部100013请求更新状态的保存(s30445)，向脚本执行部100013响应保存结果(s30446)。以上是图14所示的确认用脚本5113的执行所伴随的网关程序100的动作的说明。

这样，通过在服务提供部100014中管理数据转送循环而削减脚本所描述的内容，谋求削减存储器、减轻不可处理的内容。此外，在此示出了在脚本中描述程序块转送的循环的例子，但也可以在服务提供部100014中实施程序块转送的循环。另外，在此示出了提供诊断通信服务作为同步处理的例子，但也可以作为非同步处理。

参照图16说明确认用脚本5113的记载。在图16的第一行中记载了取得车辆1的速度的信息，在第二行中记载了在车速不是零的情况下前进到第九行以下的错误处理。在第四行中记载了利用hmi12从用户取得更新的同意。在第五行中记载了在由于hmi12的故障等而无法正常地执行第四行的处理的情况(error)、用户拒绝了更新的情况(ng)下，前进到第九行以下的错误处理。在第七行中记载了向指示了确认用脚本5113的执行的控制部100012返回表示正常结束的返回值，在第十行中记载了向控制部100012返回表示异常结束的返回值。

参照图17说明脚本执行部100013执行确认用脚本5113的情况下的网关程序100的动作。与脚本执行部100013对脚本的执行非同步地，车辆状态管理部10006接收在车辆内的网络中传输的信息，更新自身管理的车辆状态。在本例子中，通信控制部10007接收从车辆管理ecu19发送的表示车辆状态的数据(s30602)，车辆状态管理部10006取得该数据(s30603)，更新自身管理的车辆状态(s30604)。在此，表示了根据在车载网络中传输的信息进行的状态更新的例子，但对于点火状态等，也通过电信号的监视等进行状态的更新。

控制部100012根据事件管理部100011的指示，向脚本执行部100013请求确认用脚本5113的启动(s30601)。脚本执行部100013首先解释确认用脚本5113的第一行的记载，调用服务提供部100014的车辆状态取得服务(s30605)。服务提供部100014从车辆状态管理部10006取得车速(s30606)，将其传递到脚本执行部100013(s30607)。脚本执行部100013解释确认用脚本5113的第二行的记载，在车速不是零的情况下(s306071的ng)，结束处理，在车速是零的情况下(s306071的ok)，继续处理，前进到下一个处理。

脚本执行部100013接着解释确认用脚本5113的第四行的记载，为了经由hmi12向用户查询，而调用服务提供部的诊断通信服务。该查询将得到开始执行更新而可以不能马上使用车辆1或者将新程序设为有效的允许。服务提供部100014生成向hmi12发送的用于取得允许的指令(s30609)，并经由通信控制部10007向hmi12发送该指令(s30610、s30611)。hmi12根据接收到的指令显示允许取得画面，取得基于用户操作的允许结果(s30612)，向网关10发送响应(s30613)。

服务提供部100014经由通信控制部10007取得响应(s30614)，解析内容(s30615)，将解析的结果传递到脚本执行部100013(s30616)。脚本执行部100013根据接收到的解析的结果，向控制部100012返回状态确认和用户允许确认结果(s30617)。以上是图17所示的自动驾驶ecu更新脚本5111的执行所伴随的网关程序100的动作的说明。

对于诊断通信服务，示出了直到来自成为对象的ecu的响应为止为同步处理的结构，但也可以为非同步。在第二实施方式中说明非同步的情况下的例子。在作为同步处理而提供服务的情况下，事件管理部100011利用等待响应的期间确认车辆状态，在车辆状态变化了的情况下，向服务提供部100014传达该变化。

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

(1)作为信息更新装置的网关10更新存储在ecu中的软件。具备：下载控制部100015，其接收更新包5，该更新包5包含新旧软件的差分数据或作为新软件的ecu更新数据503、更新用脚本501、以及脚本启动控制信息502，上述更新用脚本501包含使用ecu更新数据503更新软件的步骤的更新用脚本501、上述脚本启动控制信息502包含开始软件的更新的条件即启动条件5022的脚本启动控制信息502；脚本执行部100013，其根据更新用脚本501，执行软件的更新；事件管理部100011，其取得搭载有网关10和ecu的车辆1的状态，在车辆1的状态符合启动条件5022时，使脚本执行部100013执行基于更新用脚本501的软件的更新。

网关10通过执行更新包5所包含的更新用脚本501来更新ecu的软件，因此即使事前不确定更新步骤，也能够按照更新用脚本501灵活地进行软件的更新。另外，更新的开始时期、即执行更新用脚本501的定时作为脚本启动控制信息502的启动条件5022包含在更新包5中，因此能够在适当的定时开始更新。

(2)在更新包5中包含多组的ecu更新数据503、更新用脚本501、以及脚本启动控制信息502。在更新包5中包含表示多个更新用脚本501与多个脚本启动控制信息502的对应关系的脚本对应表505。因此，网关10只通过接收一个更新包5，就能够更新多个ecu的软件。

(3)启动条件5022是成为开始执行的契机的现象即启动事件50221和顺序50222的组合。事件管理部100011在多个启动条件5022所包含的启动事件50221相同的情况下，根据顺序50222决定使脚本执行部100013执行的更新用脚本501的顺序。因此，能够将某事件作为契机，按照希望的顺序更新多个ecu的软件。

(4)脚本执行部100013在规定的情况下中断更新。

(5)在更新包5中包含中断软件的更新的条件即中断条件5023。当车辆1的状态与中断条件5023一致时，事件管理部100011向脚本执行部100013输出更新中断指令。脚本执行部100013在从事件管理部100011接受了更新中断指令的情况下，中断更新。因此，网关10能够配合车辆1的状态而中断更新处理。

(6)在启动事件50221中包含车辆1的点火器的接通或点火器的关断。由于也存在在车辆1的行驶中难以更新软件的ecu，因此检测点火器的关断而执行更新用脚本501是有用的。另外，也设想以下的结构，即将软件的更新分割为多个步骤，与点火器的接通一起开始其一部分步骤、特别是最终的步骤，如果更新完成，则开始车辆1的行驶，因此检测点火器的接通而执行更新用脚本501是有用的。另外，由于需要再开始中断了的处理，因此检测点火器的接通而执行更新用脚本501是有用的。

(7)在启动事件50221中包含更新包5的接收完成。为了即时更新软件，检测更新包5的接收完成而执行更新用脚本501是有用的。

(变形例子1)

在ecu更新数据503中也可以包含确定成为更新对象的ecu的信息。在该情况下，在更新包5中，既可以不包含对象ecu一览504，也可以进而在脚本对应表505中不包含表示成为更新对象的ecu的信息。

(变形例子2)

网关10也可以更新内置于网关10中的软件。另外，网关10接收更新包5并更新的对象并不限于软件，也可以是数据参数。进而，网关10也可以根据一个更新包5，更新软件、数据、参数。

(变形例子3)

在脚本启动控制信息502中也可以不包含中断条件5023。在更新包5中所包含的ecu更新数据503只有一个的情况下，在更新包5中也可以不包含对象ecu一览504和脚本对应表505。这是因为对应关系是清楚的。

(变形例子4)

在更新包5中，也可以存储更新用程序而代替更新用脚本501。在该情况下，脚本执行部100013也可以不具有解释器的功能，通过执行更新包5所包含的作为可执行文件的更新用程序，来更新软件。

(变形例子5)

图3和图4所示的网关程序100的结构是一个例子，只要具有所说明的功能，则也可以是不同的结构。例如，既可以是更新控制部10001和通信控制部10007构成为一体，也可以是控制部100012具有脚本执行部100013和服务提供部100014的功能的一部分。

第二实施方式

以下，参照图18～图26说明第二实施方式的软件更新系统。在以下的说明中，对与第一实施方式相同的结构要素附加相同的附图标记，主要说明不同点。特别对于不说明的点，与第一实施方式相同。在本实施方式中，与第一实施方式的不同点主要是更新控制部具备多个脚本执行部。

(更新控制部的结构)

图18是更新控制部10001a的结构图。第二实施方式的网关10具备更新控制部10001a，而代替第一实施方式的更新控制部10001。更新控制部10001a具备事件管理部100011、控制部100012、第一脚本执行部1000131、第二脚本执行部1000132、下载控制部100015、以及服务提供部100016。事件管理部100011、控制部100012、以及下载控制部100015与第一实施例相同，因此省略说明。第一脚本执行部1000131和第二脚本执行部1000132分别相当于第一实施方式的脚本执行部100013。

更新控制部10001a具备第一脚本执行部1000131和第二脚本执行部1000132，因此能够并行地执行2个脚本。但是，此处所述的“并行执行”是指通过分时地交替使用共享的硬件资源、即cpu1011，而不等待某脚本的执行完成就能够开始其他脚本的执行。此外，也可以是网关10具备多个cpu，在各个cpu中执行不同的脚本。服务提供部100016具备安全过滤器100017。在服务提供部100016中包含安全过滤功能，由此能够保证从脚本执行的诊断通信服务的安全。

(安全过滤器100017)

在本实施方式中，在服务器2发送的更新包5中，包含与各个ecu更新数据503和对象ecu一览504对应的验证信息。验证信息例如是数字署名、消息认证码(以下称为mac)。以下，说明在验证信息是数字署名的情况和mac的情况下服务器2和网关10预先应该具备的秘钥信息、以及网关10的安全过滤器100017的动作。但是，在以下的说明中，为了避免冗余的记载，只说明与ecu更新数据503有关的验证，而省略对对象ecu一览504的记载。

在验证信息是数字署名的情况下，服务器2预先具备私钥，网关10预先具备与该私钥对应的公钥。服务器2使用私钥对ecu更新数据503进行署名，将该署名作为验证信息，与ecu更新数据503一起发送到网关10。安全过滤器100017使用公钥验证作为署名的验证信息，由此确认进行了署名的人、即发送者是服务器2。

在验证信息是mac的情况下，服务器2和网关10分别预先具备公共私钥。服务器2使用公共私钥，生成ecu更新数据503的mac，将该mac作为验证信息，与ecu更新数据503一起发送到网关10。安全过滤器100017使用公共私钥，生成接收到的ecu更新数据503的mac，确认生成的mac与接收到的验证信息一致，由此确认生成mac的人、即发送者是服务器2。

图19是表示脚本启动控制信息502a的结构的图。在本实施方式中，在更新包5中包含脚本启动控制信息502a，而代替脚本启动控制信息502。即，本实施方式中的更新包5由更新用脚本501、脚本启动控制信息502a、ecu更新数据503、对象ecu一览504、脚本对应表505构成。

如图19所示，脚本启动控制信息502a从第一实施方式的脚本启动控制信息502中删除了中断条件。另外，脚本启动控制信息502a在启动条件5022中包含分配50224。分配50224表示启动由对象脚本5021指定的脚本的脚本执行部。这样，通过在启动条件中包含分配，在希望根据一个事件并行地启动多个脚本的情况下，能够使得通过适当的脚本执行部执行对象脚本。

图20是表示本实施例的脚本启动处理的时序图。事件管理部100011预先取得全控制信息502z，根据全控制信息502z，将需要进行发生的通知的事件登记到更新状态管理部10003和车辆状态管理部10006(s201、s202)。更新状态管理部10003和车辆状态管理部10006检测车辆1的状态变化(s203)，向事件管理部100011通知所登记的事件、例如下载的完成通知(s204)。事件管理部100011判断成为第一脚本执行部1000131的启动对象的脚本的有无(s205)。在有成为第一脚本执行部1000131的启动对象的脚本的情况下，经由控制部100012，使第一脚本执行部1000131执行该脚本(s206、s207)。

同样，事件管理部100011判断有无成为第二脚本执行部1000132的启动对象的脚本(s208)。在有成为第二脚本执行部1000132的启动对象的脚本的情况下，经由控制部100012，使第二脚本执行部1000132执行该脚本(s209、s210)。如果脚本的执行完成，则第一脚本执行部1000131和第二脚本执行部1000132向事件管理部100011响应其结果(s211、s213)。事件管理部100011如果接受了该响应，则判断在第一脚本执行部1000131和第二脚本执行部1000132中下一个应该执行的脚本的有无(s212、s214)，根据需要使其执行脚本。

图21是更新对象是自动驾驶ecu15和adasecu16的情况下的更新包5的具体例子。但是，在图21中，省略了验证信息的记载。与第一实施方式的图9的不同点在于由于更新对象的ecu不同造成的以下的点。代替引擎ecu更新脚本5112而具备adasecu更新脚本5115，代替引擎控制ecu更新脚本5112而具备adasecu更新脚本启动控制信息5125，代替引擎控制ecu更新数据5132而具备adasecu更新数据5135。

与更新对象的变更匹配地，相对于第一实施方式，对确认用脚本5113a、新程序激活用脚本5114、对象ecu一览504、以及脚本对应表505改写了内容。

adasecu更新脚本5115是描述了用于使用adasecu更新数据5135向adasecu16写入新程序的步骤的脚本。具体地说，描述了从网关10使用诊断通信向adasecu16转送差分数据的步骤。adasecu更新数据5135是adasecu16的更新所需要的数据，由描述了写入目标地址等的元数据、写入到adasecu16的程序、根据新程序生成的差分数据构成。

图22是表示更新对象是自动驾驶ecu15和adasecu16的情况下的全控制信息502z的一个例子的图。如参照图19所说明的那样，脚本启动控制信息502a不具有中断条件，而代替地具有分配50224。如图22所示，向第一脚本执行部1000131分配自动驾驶ecu更新脚本5111、确认用脚本5113a、以及新程序激活用脚本5114，向第二脚本执行部1000132只分配adasecu更新脚本5115。另外，根据adasecu更新脚本启动控制信息5125的记载，可知adasecu更新脚本5115下载完成、或通过点火器的接通而执行。但是，在点火器接通的情况下，附加有与更新状态50223有关的条件。另外，确认用脚本启动控制信息5123的启动条件5023中的更新状态50223是自动驾驶ecu15的更新完成、并且adasecu16的更新完成。

图23是表示更新自动驾驶ecu15和adasecu16的情况下的软件更新处理的流程的时序图。到更新包5的下载完成为止的处理与图13的处理相同。

事件管理部100011如果检测出下载完成了，则经由更新数据管理部10002读出更新包5内的脚本启动控制信息502a。然后，事件管理部100011识别为启动事件50221是“dl完成”的2个脚本，顺序50222都是“1”，分配50224在两者中是不同的。因此，事件管理部100011向第一脚本执行部1000131指示自动驾驶ecu更新脚本5111的启动，向第二脚本执行部1000132指示adasecu更新脚本5115的启动。通过2个执行部并行地进行这些更新处理(s304、s305)。

接着，事件管理部100011如果检测出点火器成为关断(s310)，则经由更新数据管理部10002读出更新包5内的脚本启动控制信息502a。然后，由于启动事件50221是“ign-关断”且顺序50222是“1”的确认用脚本启动控制信息5123的更新状态50223是“自动驾驶ecu更新完成”并且“adasecu更新完成”，因此事件管理部100011经由更新状态管理部10003确认自动驾驶ecu15和adasecu16的更新状态是“完成”。在此，两者的更新状态是“完成”，因此经由控制部100012向第一脚本执行部1000131指示确认用脚本5113a的启动。第一脚本执行部1000131执行确认用脚本5113a，进行车辆状态和用户允许的确认(s311)。

如果确认用脚本5113a的执行完成，则事件管理部100011经由控制部100012向第一脚本执行部1000131指示启动事件50221为“ign-关断”、顺序为“2”的新程序激活用脚本5114的启动。第一脚本执行部1000131执行该脚本，进行自动驾驶ecu15和adasecu16的新程序的激活(s312)。

图24是表示本实施方式的确认用脚本5113a的具体例子的图。此外，在本实施方式中，服务提供部100014将诊断通信服务作为非同步处理而提供。因此，如以下说明的那样，即使是相同的指令句，其行为也与第一实施方式不同。

在图24的第一行中记载了取得车辆1的速度的信息，在第二行中记载了在车速不是零的情况下前进到第六行以下的错误处理。在第四行中记载了利用hmi12从用户取得更新的同意。但是，在本实施方式中，是非同步处理，因此在第四行的处理中只向用户进行查询、例如向画面显示查询的会话框，不包含得到用户的响应的处理。在第五行中，记载了在无法正常地向用户查询的情况下、例如在hmi12不动作的情况下，前进到第十六行以下的错误处理。

图24的第七～十四行示出了永久循环处理。在第八行中记载了取得点火器的状态，在第九行中记载了在点火器接通的情况下向控制部100012返回表示正常结束的返回值。在第十一行中记载了取得在第四行中向用户查询的回答。但是，在用户还没有选择回答的情况下，取得表示未回答的值、例如“null”作为回答。在第十二行中记载了在第十一行中取得的回答是更新的允许即“ok”的情况下，向控制部100012返回表示正常结束的返回值，在是表示更新的拒绝的“ng”的情况下，前进到第十六行以下的错误处理。

即，图24的第七～十四行的记载表示在点火器为接通、或得到了更新的同意的情况下正常结束，在更新被拒绝的情况下前进到错误处理。换言之，如果点火器关断而用户也没有回答查询，则永久地进行循环处理。另外，还记载了根据用户的选择中断更新处理。

图25是表示确认用脚本5113a的执行所伴随的网关程序100的动作的时序图。但是，对与第一实施方式的图17相同的处理附加相同的步骤编号，并省略说明。如上述那样，服务提供部100014将诊断通信服务作为非同步处理而提供。到向hmi12发送允许取得的指令为止的处理、即图17中的从上开始的四分之三左右的处理与上述图17的处理相同。即，s30608对应于图24的第一行的记载。

服务提供部100014生成向hmi12发送的用于取得允许的指令(s30609)，经由通信控制部10007向hmi12发送该指令(s30610、s30611)。hmi12根据接收到的指令显示允许取得画面，等待用户操作的允许操作。另一方面，通信控制部10007向服务提供部100014响应发送处理的结果、即是否正常使用hmi12进行了允许取得画面的显示(s30618)。作为诊断通信服务的调用结果，服务提供部100014向第一脚本执行部1000131响应发送结果(s30619)。第一脚本执行部1000131解释图24的第二行的记载，并不判断用户是否允许，而只判断是否正常进行了处理，如果没有异常，即如果响应不是“ng”，则前进到下一个处理。

接着，第一脚本执行部1000131解释图24的第八行的记载，为了再次确认点火器是否不是接通，而调用车辆状态取得服务(s30620)。服务提供部100014从车辆状态管理部10006取得点火器的状态(s30621)，向第一脚本执行部1000131响应结果(s30622)。第一脚本执行部1000131解释图24的第九行的记载，如果点火器是接通，则结束处理，向控制部100012响应结果(s30623的接通)。在第一脚本执行部1000131确认点火器的状态的期间，用户操作hmi12(s30624)，将其结果发送到网关(s30625)。服务提供部100014经由通信控制部10007取得诊断通信数据包(s30626)，解析它并保存结果(s30627)。

如果点火器状态是关断(s30623的关断)，则第一脚本执行部1000131解释图24的第十一行的记载，调用诊断通信结果取得服务(s30628)，取得在s30608中调用的诊断通信服务的结果(s30629)。判定读出的结果是否是响应结果(s30630)，如果响应未到达，则重复进行车辆状态取得服务调用s30620以后的处理(s30630的结果未到达)。如果已经接收到响应(s30630的结果已到达)，则第一脚本执行部1000131根据响应结果，向控制部100012返回状态确认和用户允许确认结果(s30631)。

这样，通过将诊断通信服务设为非同步而在脚本内进行状态确认，能够与车辆等的状态变化、用户的指示匹配地中断正在执行的脚本。

图26是表示第二实施方式的诊断通信服务调用处理的流程的时序图。服务提供部100016如果通过第一脚本执行部1000131调用了诊断通信服务(s401)，则判断该请求是否是向ecu的数据写入请求(s402)。例如如果是uds(unifieddiagnosisservices：统一诊断服务)，则此处所述的数据写入请求相当于requestdownload、writedatabyidentifire等请求。在是写入请求的情况下(s402的是)，读出通过安全过滤器100017确认了发送者是服务器2的对象ecu一览504(s403)。此外，如果安全过滤器100017的验证失败，判断为对象ecu一览504的发送者不是服务器2、或所请求的ecu不包含在对象ecu一览504中，则s403的读出失败，不进行更新。

接着，判定在读出的对象ecu一览504中是否包含被指示了写入请求的ecu(s404)，在不包含的情况下(s404的否)，不执行该诊断通信服务并返回应答(s407)。在已经验证的对象ecu一览504中包含对象ecu的情况下(s404的是)，生成诊断通信数据包(s405)，向通信控制部10007请求该数据包的发送(s406)。这样，通过在执行诊断通信服务之前进行对象ecu的确认，能够防止非法的写入请求的发送，执行安全的脚本。

根据上述第二实施方式，除了在第一实施方式中说明的作用效果以外，还得到以下的作用效果。

(8)在更新用脚本501中包含中断更新的处理。脚本执行部100013根据更新用脚本501，中断更新。因此，网关10能够进行还包含软件的更新中断的灵活的软件更新处理。

(9)脚本执行部100013由第一脚本执行部1000131和第二脚本执行部1000132构成。第一脚本执行部1000131和第二脚本执行部1000132读出各自不同的更新用脚本501，更新各自不同的ecu的软件。因此，网关10能够进行包含多个ecu的同时更新的灵活的软件更新处理。

(10)更新包5包含ecu更新数据503的验证所使用的验证信息。网关10具备使用验证信息来验证所接收到的ecu更新数据503的安全过滤器100017。因此，网关10能够确认所接收到的ecu更新数据503的安全性。

(第二实施方式的变形例子1)

网关10也可以不具备安全过滤器100017。在该情况下，在更新包5中也可以不包含验证信息。

(第二实施方式的变形例子2)

网关10也可以具备3个以上的脚本执行部，同时更新3个以上的ecu的软件。

(第二实施方式的变形例子3)

服务器2也可以代替包含验证信息，而使用公共私钥或私钥对更新数据503进行加密并发送。在该情况下，网关10使用公共私钥或私钥对接收到的更新数据503进行解密，而更新ecu的软件。

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

另外，也可以例如通过用集成电路进行设计等，而用硬件实现上述各结构、功能、处理部、处理单元等的一部分或全部。另外，也可以通过由处理器解释、执行实现各个功能的软件，而用软件实现上述各结构、功能等。另外，虽然示出了被认为在说明上必要的控制线、信息线，并不一定限于在产品上表示出全部的控制线、信息线。实际上也可以考虑将几乎全部的结构相互连接起来。

以上说明了各种实施方式和变形例子，但本发明并不限于这些内容。在本发明的技术思想的范围内能够考虑的其他实施例也包含在本发明的范围内。

作为引用文，在此组合以下的优先权基础申请的公开内容。

日本专利申请2017-198622(2017年10月12日申请)。

附图标记说明

1：车辆；5：更新包；10：网关；100：网关程序；501：更新用脚本；501z：全脚本；502：脚本启动控制信息；502z：全控制信息；503：更新数据；503z：全更新数据；504：对象一览；505：脚本对应表；100011：事件管理部；100012：控制部；100013：脚本执行部；100014：服务提供部；100015：下载控制部；100016：服务提供部；100017：安全过滤器。