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

1.本发明涉及软件更新装置、软件更新系统和软件更新方法，适用于用从发布服务器发布的更新程序进行软件单元(ecu)的软件更新的软件更新装置、软件更新系统和软件更新方法。
背景技术：
：：2.近年来，机动车的e(electric)/e(electronic)架构从分散型变化为集中型，正在向硬件与软件独立地开发的方向前进。例如，在软件的开发中，正在推进使用autosar(automotiveopensystemarchitecture：汽车开放系统架构)adaptiveplatform(高效能系统平台)的机动车的软件更新技术的标准化(具体而言，例如控制软件更新的主功能的定义等)。另外，构成机动车的软件单元(ecu：electroniccontrolunit：电子控制单元)的架构不仅有autosar，因此设想转移至各种平台(pf)混合存在的车辆系统。3.例如专利文献1中，公开了一种软件更新系统，其在由多个平台构成的车辆系统中，与1个以上其他软件更新装置和服务器经由网络连接的软件更新装置在判断为满足更新时机(契机)中记载的全部条件时执行软件的更新。4.现有技术文献5.专利文献6.专利文献1：日本特开2018-106461号公报技术实现要素：7.发明要解决的技术问题8.但是，专利文献1中公开的软件更新系统，由于在各平台中各软件更新装置独立地更新软件，最后用更新触发进行软件更新装置之间的协调，因此存在难以用1个软件单元支持多个平台的技术问题。另外，每当平台、更新方法增加时，都需要追加控制软件更新的控制部，预想协调变得复杂，因此在可扩展性(scalablity)方面存在技术问题。9.本发明是考虑以上方面而完成的，提出一种能够灵活地更新由多个平台构成的车辆系统的软件的软件更新装置、软件更新系统和软件更新方法。10.用于解决技术问题的技术方案11.为了解决上述技术问题，本发明提供一种软件更新装置，其与包括在第一平台构成的第一软件单元、和在不同于所述第一平台的第二平台构成的第二软件单元的多个软件单元连接，所述软件更新装置包括：进行所述第一软件单元的软件更新的第一更新控制部；和进行所述第二软件单元的软件更新的第二更新控制部，所述第一更新控制部具有发送面向所述第一平台的控制命令的第一序列控制部，所述第二更新控制部具有模拟更新执行部，其将所述第二软件单元模拟为所述第一平台上的软件单元，基于对在所述第一平台上模拟了的所述第二软件单元的所述控制命令的接收，控制所述第二软件单元的软件更新。12.为了解决上述技术问题，本发明提供一种软件更新系统，其中，发布更新程序的发布服务器与车辆系统用网络连接，所述车辆系统包括：多个软件单元，其包括在第一平台构成的第一软件单元、和在不同于所述第一平台的第二平台构成的第二软件单元；和软件更新装置，其与所述第一软件单元及所述第二软件单元连接，所述软件更新装置具有：进行所述第一软件单元的软件更新的第一更新控制部；和进行所述第二软件单元的软件更新的第二更新控制部，所述第一更新控制部具有发送面向所述第一平台的控制命令的第一序列控制部，所述第二更新控制部具有模拟更新执行部，其将所述第二软件单元模拟为所述第一平台上的软件单元，基于对在所述第一平台上模拟了的所述第二软件单元的所述控制命令的接收，控制所述第二软件单元的软件更新。13.为了解决上述技术问题，本发明提供一种软件更新装置执行的软件更新方法，所述软件更新装置与包括在第一平台构成的第一软件单元、和在不同于所述第一平台的第二平台构成的第二软件单元的多个软件单元连接，所述软件更新装置具有：发送面向所述第一平台的控制命令，进行所述第一软件单元的软件更新的第一更新控制部；和将所述第二软件单元模拟为所述第一平台上的软件单元，进行所述第二软件单元的软件更新的第二更新控制部，所述软件更新方法包括：第一步骤，所述第一更新控制部发送对在所述第一平台上模拟了的所述第二软件单元的所述控制命令；和第二步骤，接收了所述控制命令的所述第二更新控制部，将该控制命令转换为面向所述第二平台的控制命令，利用转换后的控制命令控制所述第二软件单元的软件更新。14.发明的效果15.根据本发明，能够灵活地更新由多个平台构成的车辆系统的软件。附图说明16.图1是表示本发明的第一实施方式的使用了软件更新装置(网关)10的软件更新系统1的整体结构例的框图。17.图2是表示网关10的硬件结构例的框图。18.图3是表示ecu_a13和ecu_b16的硬件结构例的框图。19.图4是表示ecu_c17的硬件结构例的框图。20.图5是表示ecu_d18的硬件结构例的框图。21.图6是表示网关10的功能结构例的框图。22.图7是表示底盘综合ecu16的内部结构例的框图。23.图8是模拟ecu对应管理表的一例。24.图9是接口转换表的一例。25.图10是表示软件包的结构例的图(之一)。26.图11是表示软件包的结构例的图(之二)。27.图12是表示发布包的结构例的图。28.图13是表示车辆2中的系统启动(起动)时动作的次序例(流程例)的序列图。29.图14是表示控制命令转换处理的次序例的流程图。30.图15是表示关于从结构信息的收集到车辆包的接收的次序例的序列图。31.图16是表示更新ecu的软件包的安装和激活的次序例的序列图(之一)。32.图17是表示更新ecu的软件包的安装和激活的次序例的序列图(之二)。33.图18是表示结束处理中的次序例的序列图。34.图19是表示车辆状态管理部130进行的车辆状态的判断处理的处理次序例的流程图。35.图20是表示发布包生成处理的处理次序例的流程图。36.图21是表示本发明的第二实施方式的软件更新装置(网关)10a的功能结构例的框图。37.图22是表示第二实施方式中的车辆2的系统启动时动作的次序例的序列图。38.图23是表示第二实施方式中的关于从收集结构信息到接收车辆包的次序例的序列图。39.图24是表示第二实施方式中的更新ecu的软件包的安装次序例的序列图。40.图25是表示第二实施方式中的更新ecu的软件包的激活次序例的序列图。具体实施方式41.以下，参照附图详细说明本发明的实施方式。42.(1)第一实施方式43.(1-1)结构44.图1是表示使用了本发明的第一实施方式的软件更新装置(网关)10的软件更新系统1的整体结构例的框图。45.如图1所示，软件更新系统1构成为车辆2与发布服务器3经由无线网络5可通信地连接。另外，软件更新系统1也可以包括诊断装置6，该诊断装置6具有对车辆2进行故障诊断、软件更新的工具的作用。46.发布服务器3是基于在oem由本公司开发的、或从供应商收集的软件包，生成、管理和发布对车辆2发布的包(发布包)的系统，例如是ota(ontheair：空中升级或远程升级)服务器。发布服务器3构成为包括：基于上述收集到的软件包生成发布包的发布包生成部31、管理上述软件包和由发布包生成部31生成的发布包的发布包管理部32、和经由网络5向车辆2发布上述软件包和上述发布包的发布(即，信息发布)部33。其中，关于由发布服务器3生成、管理和发布的发布包，在后述的图12中示出其数据结构例。47.另外，图1中，作为对发布服务器3供给软件包的供给源的例子，示出了供应商具有的软件管理系统4(分别是4a、4b、4x)。例如，软件管理系统4a是供应商a具有的系统，构成为包括生成软件包的软件包生成部41、和管理由软件包生成部41生成的软件包的软件包管理部42。另外，关于由软件管理系统4生成和管理的软件包，在后述的图10和图11中示出其结构例。另外，以下说明中，以从发布服务器3对车辆2分别发布(下载)软件包和发布包的方式为例，但本实施方式不限定于此，例如也可以是将软件包和发布包汇总(合并)为1个档案来发布的方式等。48.接着，对车辆2的结构进行说明。图1所示的软件更新系统1是在车辆2内多种平台(pf)在1台车辆2中共存的结构，本实施方式的软件更新装置10作为网关进行该多种平台的ecu之间的通信数据的中继(中转)等。49.本实施方式中，作为车辆2中共存的多种平台的一例，将autosarap(autosaradaptiveplatform)称为第一平台(第一pf)，将autosarcp(autosarclassicplatform(经典平台))称为第二平台(第二pf)，将其他平台(例如agl(automotivegradelinux(注册商标))称为第三平台(第三pf)进行说明。50.如图1所示，车辆2构成为包括软件更新装置(网关)10、通信模块12、驾驶辅助综合ecu13、相机ecu14、传感器ecu15、底盘综合ecu16、发动机控制ecu17、变速机控制ecu18、气囊ecu19、hvacecu20、车体管理ecu21、和ivi22，它们用车内网络11连接。上述各ecu中，图1中在网关10的右侧示出的各ecu相当于网关10的下属ecu。另外，综合ecu是综合规定的多种功能而工作的ecu。51.车内网络11采用已知的通信标准、例如can(controlareanetwork(控制局域网)(注册商标))、can-fd(canwithflexibledatarate)、lin(localinterconnectnetwork)、flexray、ethernet(注册商标)中的任一种。本例中，令车内网络a为can等，车内网络b为ethernet，但对于车内网络a、b也可以采用同一通信标准。另外，在图1中，各种ecu等车辆2内的各构成要素用电力线与蓄电池连接，接受电力供给，但是在图1中省略了图示。52.网关10具有进行下属ecu之间的通信数据的中继、下属ecu的软件更新、和下属ecu中搭载的软件的匹配性确认的功能。网关10构成在autosarcp(第二pf)等的遗留平台(legacyplatform，旧平台)上。另外，关于网关10的内部结构，用图2和图6详细叙述。53.通信模块12是具有对网关10、下属ecu、及ivi22与发布服务器3的通信进行中继的功能的软件模块。54.驾驶辅助综合ecu13、相机ecu14、和传感器ecu15是与车辆2的驾驶辅助关联地工作的ecu，与驾驶辅助域网络(例如ethernet)连接。其中，驾驶辅助综合ecu13是对车辆2的驾驶辅助功能(adas：advanceddriver-assistancesystems)进行综合控制(总控制)的ecu。以下说明中，为了简略，有时将驾驶辅助综合ecu称为“ecu_a”。相机ecu14是控制搭载在车辆2上的相机的ecu，传感器ecu是控制搭载在车辆2上的传感器的ecu。55.底盘综合控制ecu16是对车辆2中的底盘系统功能(制动、转向等)进行综合控制(总控制)的ecu，与底盘域网络(例如ethernet)连接。以下说明中，为了简略，有时将底盘综合控制ecu称为“ecu_b”。56.发动机控制ecu17和变速机控制ecu18是控制车辆2的驱动系统的动作的ecu，与传动域网络(例如can-fd)连接。其中，发动机控制ecu17是控制发动机的ecu，变速机控制ecu18是控制变速机的ecu。以下说明中，为了简略，有时将发动机控制ecu称为“ecu_c”。57.气囊ecu19、hvacecu20、和车体管理ecu21是管理车辆2的各种设备、状态的ecu，与车体域网络(例如can/lin)连接。其中，气囊ecu19是控制气囊的ecu，hvacecu20是控制空调系统(hvac：heating,ventilation,andairconditioning)的ecu，车体管理ecu21是管理车体的状态的ecu。以下说明中，为了简略，有时将气囊ecu称为“ecu_d”。58.ivi22是对车辆2的乘员即用户提示信息、接受用户的输入的ivi(in-vehicleinfotainment：车载信息娱乐系统)的ecu，与信息系统网络(例如ethernet)连接。以下说明中，为了简略，有时将ivi称为“ecu_e”。59.如上所述，车辆2中搭载了各种各样的ecu，构成这些ecu的平台的类型也是各种各样的。具体而言，例如驾驶辅助综合ecu(ecu_a)13和底盘控制ecu(ecu_b)16在第一pf上构成，发动机控制ecu(ecu_c)17和气囊ecu(ecu_d)19在第二pf上构成，ivi(ecu_e)22在第三pf上构成。另外，关于是否能够在车辆2行驶中改写软件，这些ecu规格也不同。例如，ecu_a13、ecu_b16、ecu_c17、和ecu_e22能够在行驶中改写，而ecu_d18不能在行驶中改写。60.图2是表示网关10的硬件结构例的框图。如图2所示，网关(软件更新装置)10包括交换机50、soc51、微控制器52、非易失性存储器53、和rom(readonlymemory：只读存储器)54。交换机50例如是ethernet交换机。soc51是搭载了高负荷的处理等的soc(systemonachip：系统级芯片)，内部具有cpu(centralprocessingunit：中央处理器)55。微控制器52是搭载了关于安全的功能等的微控制器，内部具有cpu56、ram(randomaccessmemory：随机存取存储器)57、rom58、和通信控制部59。61.图3是表示ecu_a13和ecu_b16的硬件结构例的框图。如图3所示，ecu_a13和ecu_b16包括soc61、微控制器62、非易失性存储器63、和ram64。soc61具有cpu65，微控制器62具有cpu66、ram67、rom68、和通信控制部69。ecu_a13和ecu_b16与图2所示的网关10同样地包括各自具有处理器(cpu)的soc和微控制器，由此作为综合ecu能够搭载多个功能。例如，驾驶辅助综合ecu(ecu_a)13的情况下，在soc61搭载识别功能，在微控制器62搭载控制功能。另外，ecu_a13和ecu_b16，由于rom68是双存储体(bank)(第一存储体70、第二存储体71)，因此是在车辆2行驶中也能够改写rom68中保存的软件的结构。62.图4是表示ecu_c17的硬件结构例的框图。如图4所示，ecu_c17包括1个微控制器81。微控制器81与图3所示的微控制器62同样地在内部具有cpu82、ram83、rom84、和通信控制部85。微控制器81的rom84与图3的rom68同样是双存储体(第一存储体86、第二存储体87)，因此是在车辆2行驶中也能够改写rom84中保存的软件的结构。63.图5是表示ecu_d18的硬件结构例的框图。如图5所示，ecu_d18与图4所示的ecu_17同样地包括1个微控制器91，微控制器91在内部具有cpu92、ram93、rom94、和通信控制部95。但是，作为与图4所示的ecu_17的不同之处，微控制器91的rom94是单存储体(bank)的，因此是在车辆2行驶中不能改写rom94中保存的软件的结构。64.图6是表示网关10的功能结构例的框图。如图6所示，网关(软件更新装置)10构成为包括服务器连接部110、hmi控制部120、车辆状态管理部130、第一更新控制部140、第二更新控制部150、和通信部160。65.服务器连接部110负责进行经由通信模块12从车辆2向发布服务器3的连接。具体而言，例如，服务器连接部110在其与发布服务器3之间进行车辆2中搭载的软件和硬件的结构信息(构成信息)的上传、活动(campaign)信息和发布包的下载。66.hmi控制部120经由通信来控制车辆2内的hmi功能(例如ivi、仪表)，进行软件更新所需的显示(例如更新内容和结果的显示)和从用户取得操作结果(例如允许、取消)。67.车辆状态管理部130从其他ecu等取得并管理车辆2的各种状态(例如点火装置的点火状态、行驶中/泊车中等行驶状态等)。68.第一更新控制部140实施以第一pf为前提的ecu的软件更新控制。第一更新控制部140由第一序列控制部141、依存关系管理部142、和设备信息管理部143构成。69.第一序列控制部141控制第一pf中的软件更新的序列(sequence，顺序)。第一序列控制部141不仅控制能够直接控制的第一pf上的ecu，还将第一pf以外的平台上的ecu模拟(近似)地作为第一pf上的ecu进行处理，由此对车辆2的系统内存在的ecu整体地进行控制。依存关系管理部142使用第一pf规定的格式的依存关系信息，检查软件之间的依存关系。设备信息管理部143收集车辆2内的软件信息，管理车辆2的结构信息。70.第二更新控制部150实施第一pf以外的平台(第二pf、第三pf)中的ecu的软件更新控制。第二更新控制部150由模拟更新执行部151、依存关系管理部152、转换信息管理部153、和第二序列控制部154构成，转换信息管理部153具有模拟ecu管理部155和接口管理部156。71.模拟更新执行部151对于第一pf以外的ecu，通过模拟在第一pf的动作来执行软件更新。依存关系管理部152对于第一pf以外的ecu管理各ecu的依存关系。72.转换信息管理部153管理第一pf与第一pf以外的平台之间的信息的对应关系。转换信息管理部153具有的模拟ecu管理部155对由第一pf管理的ecu、软件的识别信息、与由第一pf以外的平台管理的ecu、软件的识别信息的对应关系进行管理，例如，保存记载了上述对应关系的模拟ecu对应管理表(参照图8)。另外，转换信息管理部153具有的接口管理部156，对第一pf中的命令、api(applicationprogramminginterface：应用编程接口)、与第一pf以外的平台中的命令、api的对应关系进行管理，例如保存记载了上述对应关系的接口转换表(参照图9)。其中，模拟ecu对应管理表、接口转换表可以预先生成并被保存，但除此以外例如也可以与车辆系统中的ecu的连接等相应地自动生成内容。73.第二序列控制部154控制第二pf中的软件更新的序列。另外，第二更新控制部150对于第一pf以外的平台、按每个平台包括控制该平台中的软件更新的序列的序列控制部，将它们总称为第n序列控制部。即，图4所示的第二序列控制部154是第n序列控制部的一例，以后对于第n序列控制部也赋予附图标记154进行说明。74.通信部160控制与网关10外部的通信。通信部160由服务管理部161、通信i/f162、第一通信部163、第二通信部164、和第三通信部165构成。75.服务管理部161管理第一pf中的服务。通信i/f162是第一pf中的应用间通信的接口，例如是第一pf的ara::com等。第一通信部163是第一pf中的ecu间通信的接口处理部。第一通信部163例如是处理some/ip(scalableservice-orientedmiddlewareoverip)和dds(datadistributionserviceforreal-timesystems)等第一pf中作为标准的通信协议的模块。第二通信部164是第二pf中的ecu间通信的接口处理部。第二通信部164例如是处理iso14229-1(uds)等第二pf中作为标准的通信协议的模块。第三通信部165是第一pf和第二pf以外的平台中的ecu间通信的接口处理部。第三通信部165例如是处理机动车制造商独自的通信协议的模块。第一通信部163、第二通信部164、和第三通信部165是任一平台中的ecu间通信的接口处理部，也将它们称为第n通信部。76.图7是表示底盘综合ecu16的内部结构例的框图。底盘综合ecu16是将底盘系统(制动、转向等)的ecu的功能集中在1个ecu中的ecu，构成为包括funca170、funcb180、和虚拟机管理器(hypervisor)190。其中，funca170和funcb180分别相当于底盘综合ecu16作为综合ecu具有的多个功能。77.funca170例如控制制动、转向等对安全的要求高的功能。funca具有第一app171、第二pf_mw172和rtos173。第一app171是制动控制用的软件模块。第二pf_mw172是提供第二pf(autosarcp)的功能的中间软件(middleware)组。rtos173是实时os(operatingsystem：操作系统)。78.funcb180例如控制诊断通信功能、联网功能等与行驶安全并不直接相关的功能。funcb180具有第三app181、第四app182、第一pf_mw183、和posix_os184。第三app181是搭载在funcb180的应用之一，例如是关于诊断功能的应用软件。第四app182是搭载在funcb180的与第三app181不同的应用之一，例如是关于联网功能的应用软件。第一pf_mw183是提供第一pf(autosarap)的功能的中间软件组，作为负责该功能中的各功能的软件模块的一例，具有第一pf_sw185、186。具体而言，例如第一pf_sw185是提供更新管理部的功能的软件模块，第一pf_sw186是提供网络管理部的功能的软件模块。posix_os184是posix(portableoperatingsysteminterfaceforunix(unix：注册商标))的os。79.另外，图7中，作为本实施方式的软件更新装置10中包括的综合ecu的内部结构例，示出了底盘综合ecu16的内部结构例，但其他ecu的内部结构也能够参照图7推定。例如，驾驶辅助综合ecu(ecu_a)13因为是综合ecu，所以认为与底盘综合ecu16同样地是包括2个func的结构即可。另外，在发动机控制ecu17、气囊ecu19等这样的单功能ecu的情况下，认为是包括1个func的结构即可。80.(1-2)数据81.以下，对于由本实施方式的软件更新系统1中保存或发布的一部分数据，示出其数据结构例。但是，实际的数据并不限定于以下例子，例如用表形式记载的数据也可以通过规范化(标准化)等而用不同的表结构保存数据。另外，例如也可以用表以外的形式保存数据。82.图8是模拟ecu对应管理表的一例。模拟ecu对应管理表是记载了由第一pf管理的ecu、软件的识别信息、与由第一pf以外的平台管理的ecu、软件的识别信息的对应关系的表数据，由转换信息管理部153的模拟ecu管理部155保存。在图8的情况下，模拟ecu对应管理表210以作为对象的ecu、软件为单位而具有记录，各记录由第一pf上识别id211、ecu识别信息212、和pf识别信息213构成。83.在模拟ecu对应管理表210中，第一pf上识别id211是为了在第一pf上模拟地识别对象而赋予的识别符(id)。ecu识别信息212是在第一pf以外的平台(实际管理的平台上)中识别的对象的识别信息，例如记载ecu的名称。模拟ecu管理部155通过使用第一pf上识别id211和ecu识别信息212，能够在第一pf与其他平台之间转换对象的识别信息。pf识别信息213是用于识别实际管理对象的平台的信息。例如，根据图8可知，在第一pf上模拟地用识别id“2”对待的ecu实际上是由“第二pf”管理的“发动机控制ecu”。这样，模拟ecu管理部155通过参照模拟ecu对应管理表210，能够根据平台使用在第一pf与其他平台之间转换了的ecu、软件的id。84.图9是接口转换表的一例。接口转换表是记载了第一pf的命令、api、与第一pf以外的平台的命令、api的对应关系的表数据，由转换信息管理部153的接口管理部156保存。在图9的情况下，接口转换表220由第一pf控制命令221、pf类别222、和转换后接口223构成。85.在接口转换表220中，第一pf控制命令221是第一pf上的控制命令的名称。具体而言，例如相当于“sw信息取得请求”、“数据传输开始请求”等控制命令。pf类别222是用于识别符合第一pf以外的哪个平台的信息，具体而言，例如记载“第二pf”和“第三pf”等。转换后接口223是在由pf类别222指定的平台中、识别与第一pf控制命令221的控制命令对应的接口的信息。通过转换后接口223的设定，能够指定在执行上述控制命令时对通信部160的哪个通信部以怎样的命令进行委托。86.例如，在图9的接口转换表220中，在第一pf上的控制命令(第一pf控制命令221)是“sw信息取得请求”的情况下，与第三pf对应的转换后接口223为“第三通信部getecuversion”。在此情况下，意思是，在第三pf中，对第三通信部165委托执行从ecu读取版本信息的api(getecuversion)。另外，例如在第一pf控制命令221是“数据传输开始请求”的情况下，与第二pf对应的转换后接口223是“无(ok回应)”。这是因为，与第一pf的数据传输开始请求对应的api在第二pf中不存在，在此情况下，设定为第二pf固定地返回ok回应。87.另外，本实施方式中，在第二pf中，因为存在行驶中能够改写的ecu和不能改写的ecu，所以还能够在转换后接口223中，按ecu的每个类别记载转换后的命令。例如，在第一pf控制命令221是“包处理请求”的情况下，作为与第二pf对应的转换后接口223，在为行驶中能够改写的ecu的情况下设定为委托进行“数据传输请求”，而在为行驶中不能改写的ecu的情况下设定为“无(ok回应)”。通过这样按ecu的每个类别记载转换后的命令，能够控制在什么时间(timing)对ecu发送模拟更新执行部151暂时蓄积了的更新数据。88.另外，在软件更新装置10中，构成为用模拟ecu对应管理表210、接口转换表220管理的信息(至少，第一pf上识别id211和第一pf控制命令221)被发送至第一更新控制部140，由此，第一更新控制部140(尤其是第一序列控制部141)在要进行对第一pf以外的平台上的ecu的控制时，能够生成对在第一pf上模拟了的模拟ecu的控制命令。89.图10和图11是表示软件包的结构例的图(之一、之二)。软件包是包括ecu的更新程序等的包，例如由供应商具有的软件管理系统4生成。软件包经由发布服务器3对车辆2发布，通过在对象ecu的更新执行部按规定的更新次序执行软件包，能够在对象ecu中进行程序的更新。图10中示出了面向第一pf的软件包230，图11中示出了面向第二pf的软件包240和软件包240中包括的更新对象软件信息243的详细结构。90.图10所示的软件包230构成为具有：将面向第一pf的更新程序233、程序执行条件234和数据235归档(archive)了的更新程序数据231、更新程序数据231的数字签名232、和作为关于更新中使用的软件包的信息的更新对象软件信息(vehiclepackagemanifest：车辆包清单)261。更新程序233是用于改写第一pf的规定的ecu的数据，具体而言是第一pf的更新后的程序、差数据等。程序执行条件234是表示更新程序233的执行条件的信息。数据235是更新程序233使用的参数等数据。对于更新对象软件信息261，之后在图12的说明中叙述。91.图11的(a)所示的软件包240构成为具有：面向第二pf的更新程序241、更新程序241的数字签名242、和关于更新中使用的软件包的更新对象软件信息243。更新程序241是用于改写第二pf的规定ecu的数据，具体而言是第二pf的更新后的程序、差数据等。另外，软件包的数据结构不一定需要如图10、图11所示那样依存于更新对象的ecu的平台，例如第二pf用的软件包也可以具有与图10的软件包230同样的数据结构。92.如图11的(b)所示，更新对象软件信息243包括版本2431、大小2432、存储器地址2433和通信地址2434。此处，版本2431对于更新对象软件(更新数据)示出更新后的软件版本，大小2432表示更新数据的大小。另外，存储器地址2433表示保存更新数据的存储器地址，通信地址2434表示用于与处理更新数据的更新执行部通信的通信地址。93.图12是表示发布包的结构例的图。发布包是在网关10中由第一pf定义了的第一更新控制部140为了控制使用了软件包的ecu更新而利用的包，由发布服务器3生成并对网关10发布(参照之后用图20说明的发布包生成处理)。94.图12所示的发布包250构成为具有：与用于更新的控制的数据整体相当的车辆整体更新控制信息251、作为关于更新中使用的软件包的信息的更新对象软件信息261、和数字签名271。95.车辆整体更新控制信息251包括更新次序252、依存关系信息253、第一更新控制部识别信息254、和用户通知255。此处，更新次序252是记载了更新条件、次序的数据，更具体而言，包括各处理(安装、软件包处理、激活)的执行条件256、和关于更新对象软件包的各处理(安装、软件包处理、激活)的执行次序257。依存关系信息253表示更新对象软件包的与其他软件的依存关系。第一更新控制部识别信息254表示处理本控制信息的控制部的识别信息。用户通知255表示关于该更新的对用户的通知内容。96.更新对象软件信息261包括版本262、大小(size)263、更新数据类别264、处理类别265、依存关系266、包id267、通信地址268、更新执行部识别信息269、和包配置目的地270。此处，版本262对于更新对象软件(更新数据)示出更新后的软件版本。大小263表示更新数据的大小。更新数据类别264表示完整更新数据、差数据等这样的更新数据的类别。处理类别265表示新安装、更新、或删除这样的更新处理的类别。依存关系266表示软件包中包括的软件的与其他软件的依存关系。包id267表示软件包的识别符。通信地址268表示用于与处理软件包的更新执行部通信的通信地址。更新执行部识别信息269表示处理软件包的更新执行部的识别信息。包配置目的地270表示用于取得软件包的配置目的地(例如服务器的url等)。97.(1-3)处理98.以下，对于上述本实施方式的软件更新系统1执行的各种动作或处理，进行详细的说明。99.(1-3-1)启动时动作100.图13是表示车辆2中的系统启动时动作的次序例的序列图。车辆2中的系统例如以车辆2的电源on(接通)等为契机而启动，此时，网关(软件更新装置)10开始图13所示的启动时动作。101.根据图13，首先，第一更新控制部140的第一序列控制部141对于通信部160的服务管理部161发送请求检索车辆2的系统内存在的服务的更新对象检索请求(步骤s101)。102.接收了步骤s101的更新对象检索请求的服务管理部161经由第一通信部163对系统内发出探索请求，接受其探索结果的通知(步骤s102～s105)。更具体而言，根据从第一通信部163接受到的探索请求，各ecu的软件发出表示自身的服务的存在的服务通知。作为该步骤s102～s105的探索请求的一例，图13中，示出了从第一pf上的ecu_a13发出服务通知的状况。在此情况下，ecu_a13对于自身具有的软件更新功能(更新管理部)服务，对第一通信部163回应服务通知(步骤s104)，第一通信部163将接收到的服务通知传送至服务管理部161(步骤s105)。103.接着，服务管理部161基于步骤s105中接收到的服务通知，将该服务通知表示的服务(本例中是ecu_a13的软件更新服务)登记在自身保存的管理信息中(ecu_a对象登记)。104.另外，车辆2的系统启动时对服务管理部161的管理信息进行的服务登记，不限定于如上所述那样基于因对更新对象检索请求的回应而发出的服务通知进行，有时也在其他次序(流程)进行服务的登记。以下说明其一例。105.例如，在网关10中，在车辆2的系统启动时，各平台上的ecu内的软件能够自发地发出服务通知。作为这样的动作的一例，图13中，示出了从第一pf上的ecu_b16发出关于ecu_b16具有的软件更新功能服务的服务通知的情形(步骤s106～s107)。在此情况下，来自ecu_b16的服务通知经由第一通信部163被发送至服务管理部161，服务管理部161基于接收到的服务通知，将该服务通知表示的服务(ecu_b16的软件更新服务)登记在自身保存的管理信息中(ecu_b对象登记)。106.另外，例如，网关10中，在车辆2的系统启动时，系统内的服务能够对服务管理部161请求登记自身的服务。作为这样的动作的一例，图13中，示出了第二更新控制部150的模拟更新执行部151对于自身管理的平台(第一pf以外的平台)上的ecu之一即第二pf上的ecu_c17，请求登记ecu_c17具有的软件更新服务的情形(步骤s108)。在此情况下，接受了来自模拟更新执行部151的登记请求的服务管理部161将被请求登记的ecu_c17的软件更新服务登记在管理信息中(ecu_c对象登记)。107.另外，网关10中，也能够由上述模拟更新执行部151在车辆2的系统启动时对服务管理部161请求登记服务，图13中示出了这样的各种动作例。具体而言，在步骤s109中，车辆状态管理部130对服务管理部161请求进行管理车辆2的各种状态的车辆状态管理服务的登记。在此情况下，服务管理部161将被请求登记的车辆状态管理服务登记在管理信息中(车辆状态管理登记)。另外，在步骤s110中，hmi控制部120对服务管理部161请求进行控制hmi功能的hmi控制服务的登记。在此情况下，服务管理部161将被请求登记的hmi控制服务登记在管理信息中(hmi控制登记)。另外，在步骤s111中，服务器连接部110对服务管理部161请求进行与发布服务器3连接的服务器连接服务的登记。在此情况下，服务管理部161将被请求登记的服务器连接服务登记在管理信息中(服务器连接登记)。108.如上所述，通过进行图13所示的启动时动作，能够在网关10中，在车辆2的系统启动时将系统内存在的服务登记在服务管理部161的管理信息中。109.(1-3-2)控制命令转换处理110.图14是表示控制命令转换处理的次序例的流程图。图14的流程图表示在第一更新控制部140(尤其是第一序列控制部141)接收了对第一pf以外的平台上的ecu发出的控制命令的情况下、在第二更新控制部150中转换控制命令的控制命令转换处理的次序例。111.在对图14的处理流程进行说明之前，首先说明本实施方式的软件更新装置(网关)10中对控制命令的处理的概要。112.如参照图6所述，在本实施方式的软件更新装置(网关)10中，第一更新控制部140(第一序列控制部141)不仅控制能够直接控制的第一pf上的ecu，还通过将第一pf以外的平台模拟地作为第一pf上的ecu进行处理，来对各平台上的ecu整体进行控制。在这样的结构的网关10中，关于对第一pf上的ecu的控制命令，第一序列控制部141能够经由第一通信部163对对象ecu直接指示执行该命令。另一方面，关于对第一pf以外的平台上的ecu的控制命令，因为被记载为对第一pf上的模拟的ecu(模拟ecu)的控制命令，所以不能直接执行命令。于是，第一序列控制部141对第二更新控制部150发送对模拟ecu的控制命令。然后，在第二更新控制部150中，模拟更新执行部151将接收到的控制命令转换为对实际的平台上的ecu的控制命令。通过进行这样的转换处理，在第二更新控制部150中，对应的平台的第n序列控制部154能够经由对应的第n通信部(第二通信部164、第三通信部165)对对象ecu指示执行转换后的控制命令。具体而言，例如是对第二pf上的ecu的控制命令的情况下，第二序列控制部154能够经由第二通信部164指示执行该控制命令。113.在以上概要的基础上，对于图14的处理流程进行说明。首先，第二更新控制部150的模拟更新执行部151从第一通信部163接收从第一序列控制部141发送的对模拟ecu的控制命令(步骤s201)。该控制命令构成为至少包括第一pf上的控制命令的名称(例如图9的第一pf控制命令221)、和第一pf上的模拟ecu的识别信息即第一pf上识别id(例如图8的第一pf上识别id211)。114.接着，模拟更新执行部151参照转换信息管理部153的模拟ecu管理部155中保存的模拟ecu对应管理表(图8)，取得与在步骤s201接收到的控制命令中包括的第一pf上识别id211对应的ecu识别信息212和pf识别信息213(步骤s202)。115.接着，模拟更新执行部151参照转换信息管理部153的接口管理部156中保存的接口转换表(图9)，基于在步骤s201接收到的控制命令中包括的第一pf控制命令221、和与在步骤s202取得的pf识别信息213相符合的pf类别222，取得对应的转换后接口223(步骤s203)。116.与在步骤s202取得的pf识别信息213(也可以是pf类别222)表示的平台对应的第n序列控制部154，基于在步骤s203取得的接口信息，经由第n通信部(例如第二通信部164)对对象ecu发送控制命令(步骤s204)。步骤s204中的发送对象ecu，是在步骤s202取得的ecu识别信息212表示的ecu。117.如上所述，通过进行图14所示的控制命令转换处理，网关10对于对在第一pf上模拟地处理的ecu的控制命令，也能够转换为对实际的平台上的ecu的控制命令并执行控制命令，因此能够整体地控制对车辆2的系统内的各平台上的ecu(或ecu的软件)的控制命令。118.(1-3-3)结构信息的收集～车辆包的接收119.图15是表示关于从结构信息的收集到车辆包的接收的次序例的序列图。更详细而言，在图15中示出了：第一序列控制部141收集系统内的软件信息、服务器连接部110将其作为结构信息发送至发布服务器3并进行同步、第一序列控制部141基于从发布服务器3提供的活动信息决定要下载的车辆包(发布包、软件包)的一览(名单)、并接收各车辆包的处理的次序例。120.根据图15，首先，第一序列控制部141对服务管理部161请求取得对象列表(list)，从服务器管理部161取得对象列表(步骤s301～s302)。在步骤s301～s302中作为取得对象的对象列表，具体而言是成为结构(构成)同步、软件更新的对象候选的软件更新服务的一览。121.接着，第一序列控制部141使用在步骤s302取得的一览中的服务，取得各软件的信息。在图15中，作为其一例，示出了从ecu_a13和ecu_b17取得软件信息(sw信息)的次序，但实际上，对所登记的全部服务读取并取得软件信息。122.首先，说明从ecu_a13进行的sw信息的取得。第一序列控制部141对ecu_a13发出的sw信息的取得请求，使用第一pf用的接口而实施，具体而言，第一序列控制部141对第一pf中的应用间通信的接口即通信i/f162发送ecu_a13的sw信息的取得请求(步骤s303)。123.此处，因为ecu_a13是第一pf上的ecu，所以通信i/f162对第一通信部163发送该取得请求(步骤s304)。然后，接收了该取得请求的第一通信部163按照由第一pf定义的ecu间接口，对ecu_a13请求sw信息，ecu_a13根据请求对第一通信部163回应sw信息(步骤s305～s306)。第一通信部163按照第一pf中定义的ecu间接口将在步骤s306接收到的sw信息转换为第一pf的应用接口并回信给通信i/f162，从通信i/f162对第一序列控制部141发送sw信息(步骤s307～s308)。124.通过以上步骤s303～s308的处理，第一序列控制部141能够取得ecu_a13的sw信息。125.接着，说明从ecu_c17取得sw信息的情况。第一序列控制部141对ecu_c17发出的sw信息的取得请求，与对ecu_a13发出的sw信息的取得请求同样地使用第一pf用的接口而实施。具体而言，第一序列控制部141对通信i/f162发送ecu_c17的sw信息的取得请求(步骤s309)。在步骤s309发送的sw信息的取得请求并非直接记载“对第二pf上的ecu_c17的sw信息的取得请求”，而是记载“对第一pf上的ecu_c17的模拟ecu的sw信息的取得请求”。因此，在上述sw信息的取得请求中，用第一pf上识别id(参照图8)指定取得对象ecu，用第一pf控制命令(参照图9)指定请求内容。126.在步骤s309接收了sw信息的取得请求的通信i/f162，由于取得对象ecu由第一pf上识别id指定(由于作为实际的取得对象的ecu_c17是第二pf上的ecu)，因此不直接对第二pf用的第二通信部164发送sw信息的取得请求，而是对第二更新控制部150的模拟更新执行部151发送sw信息的取得请求(步骤s310)。127.接收了sw信息的取得请求的模拟更新执行部151，调用转换信息管理部153，取得与由上述取得请求指定的第一pf上识别id对应的ecu识别信息和pf识别信息(取得ecu识别信息、取得pf信息)。详细说明为，模拟更新执行部151以由取得请求指定的第一pf上识别id为键(key)，参照模拟ecu管理部155保存的模拟ecu对应管理表210，由此，作为表示作为sw信息的实际取得对象的ecu及其平台(第二pf)的信息，取得对应的ecu识别信息212和pf识别信息213。进而，模拟更新执行部151调用(调出)转换信息管理部153，取得与由上述取得请求指定的第一pf控制命令对应的转换后接口(取得转换后i/f)。详细说明为，模拟更新执行部151将由上述取得请求指定的第一pf控制命令、和通过之前的pf信息取得而取得的pf种类信息作为键(key)，参照接口管理部156保存的接口转换表220，由此取得对应的转换后接口223，作为对第二pf上的ecu_c17请求sw信息所需的接口信息。128.接着，模拟更新执行部151使用通过上述ecu识别信息取得、pf信息取得、和转换后i/f取得而取得的信息，经由第二序列控制部154对第二通信部164请求ecu_c17的sw信息取得(步骤s311、s3112)。然后，接收了取得请求的第二通信部164使用第二pf的标准i/f，对ecu_c17请求sw信息，ecu_c17根据请求对第二通信部164回应sw信息(步骤s312～s313)。第二通信部164例如用uds等通信协议，经由第二序列控制部154对模拟更新执行部151回应在步骤s313接收了的sw信息(步骤s3132、s314)。129.之后，模拟更新执行部151将在步骤s314接收到的ecu_c17的sw信息转换为第一pf上的接口并发送至通信i/f162(步骤s315)，通信i/f162对第一序列控制部141返回接收的sw信息作为对步骤s309的sw信息的取得请求的回应(步骤s316)。130.通过以上步骤s309～s316的处理，第一序列控制部141还能够从在第一pf上模拟了的其他平台的ecu_c17取得sw信息。131.这样，在从登记在系统内的全部服务取得软件信息后，第一序列控制部141将收集到的各软件信息发送至服务器连接部110(步骤s317)，服务器连接部110将接收到的这些软件信息作为结构信息对发布服务器3通知(步骤s318)。132.接着，发布服务器3基于在步骤s318接收到的结构信息，确认是否存在能够更新的软件，在存在能够更新(从车辆2看是下载)的软件的情况下，对服务器连接部110回应用于进行该更新的活动信息(步骤s319)。133.接着，服务器连接部110对第一序列控制部141请求从接收到的活动信息中读取要下载的车辆包(更新包)的一览(步骤s320)。对于第一序列控制部141读取要下载的更新包的一览的详细方法，省略说明，例如第一序列控制部141例如可以通过hmi控制部120使hmi显示活动的一览，由用户选择想要下载的车辆包(更新包)。第一序列控制部141对服务器连接部110回应要下载的更新包的一览(步骤s321)。服务器连接部110基于被回应了的更新包的一览，对发布服务器3请求提供更新包(步骤s322)。134.接着，发布服务器3对服务器连接部110发送在步骤s322请求了的更新包(步骤s323)。另外，在步骤s322请求了多个更新包的情况下，在步骤s323中一并或依次发送各更新包，图15中为了简便而举例示出了发送1个更新包(第一包)的情况。135.从发布服务器3接收了更新包的服务器连接部110，对第一序列控制部141请求开始传输更新包(第一包)，当得到许可时，对第一序列控制部141传输第一包(步骤s324～s325)。服务器连接部110在第一包的传输结束时，对第一序列控制部141通知第一包的传输完成(步骤s326)。136.接受到第一包的传输完成的通知时，第一序列控制部141验证接收到的第一包(验证第一包)。作为验证的具体内容，例如能够列举：验证包中包括的数字签名、确认是正规的更新包等。137.通过以上步骤s317～s326的处理，第一序列控制部141能够取得关于系统内的可更新的软件的信息(活动信息)，从发布服务器3下载从活动中选择的任意的车辆包(更新包)。138.(1-3-4)安装和激活139.图16和图17是表示更新ecu的软件包的安装和激活时的次序例的序列图(之一、之二)。作为图16和图17所示的处理的前提，设想在通过图15所示的处理由第一序列控制部141从发布服务器3下载了的更新包中包括用于更新ecu_a13、ecu_c17、ecu_d19的信息。在图16和图17中，示出在从发布服务器3下载用于更新各ecu的软件包(sp1～sp3)、对各ecu进行安装(传输数据)、从驾驶员得到了执行激活的允许的情况下，使更新了的ecu的功能激活(有效)的处理的次序例。另外，对ecu传输数据的时机也可以是在得到执行激活的允许之后，详情后述。140.首先，根据图16，第一序列控制部141对车辆状态管理部130进行车辆状态取得请求，由此，车辆状态管理部130读取关于车辆2的状态的信息(车辆状态)并将其发送至第一序列控制部141(步骤s401～s402)。车辆状态管理部130严密而言经由服务接口读取车辆状态，但图16中省略其记载。141.接着，从车辆状态管理部130对第一序列控制部141通知车辆2的状态，第一序列控制部141基于取得了的车辆状态，判断是否可以开始安装处理(未图示)。第一序列控制部141在判断为可以开始安装处理的情况下，开始以下说明的ecu更新用的软件包(sp)的下载。142.下载ecu更新用的软件包的处理次序，根据对象ecu是否是第一pf上的ecu而不同。即，在图16中，ecu_a13用的ecu包(sp1)的下载、与ecu_c17用的ecu包(sp2)或ecu_d19用的ecu包(sp2)的下载的处理次序不同。143.在下载ecu_a13用的ecu包(sp1)的处理中，首先，第一序列控制部141对服务器连接部110请求取得sp1(步骤s403)。接受到该请求的服务器连接部110通过对发布服务器3请求取得sp1，从发布服务器3接收sp1(步骤s404～s405)。144.接着，服务器连接部110通知sp1的数据传输开始。具体而言，从服务器连接部110对第一序列控制部141通知sp1的传输开始，第一序列控制部141经由通信i/f162和第一通信部163对第一pf上的ecu_a13的更新管理部通知传输开始(步骤s406～s409)。对该传输开始的通知的回应，从ecu_a13经由第一通信部163、通信i/f162、第一序列控制部141被发送至服务器连接部110(步骤s410～s413)。145.接着，服务器连接部110将sp1的数据传输至ecu_a13。具体而言，从服务器连接部110对第一序列控制部141发送sp1，第一序列控制部141经由通信i/f162和第一通信部163对第一pf上的ecu_a13的更新管理部传输sp1(步骤s414～s417)。对该数据传输的回应，从ecu_a13经由第一通信部163、通信i/f162、第一序列控制部141被发送至服务器连接部110(步骤s418～s421)。146.在sp1的数据传输结束时，服务器连接部110通知sp1的数据传输结束。该通知与数据传输开始的通知的情况同样地经由第一序列控制部141、通信i/f162、第一通信部163被传输至ecu_a13的更新管理部(步骤s422～s425)，其回应被发送给服务器连接部110(步骤s426～s429)。147.如上所述，第一pf上的ecu_a13用的ecu包(sp1)的下载，能够在第一pf上执行全部处理，ecu_a13的更新管理部能够安装接收到的sp1。148.另一方面，在第一pf以外的平台上的ecu用的ecu包的下载中，下载的软件包不被立即传输至对象ecu，而是直到满足规定条件为止(直到发出利用图17说明的包处理请求或激活请求为止)，暂时保存在网关10内(模拟更新执行部151)。作为这样的处理次序的一例，以下说明下载ecu_c17用的ecu包(sp2)的处理次序(处理流程)。149.在下载ecu_c17用的ecu包(sp2)的处理中，首先，第一序列控制部141对服务器连接部110请求取得sp2(步骤s431)。接受到该请求的服务器连接部110通过对发布服务器3请求取得sp1，从发布服务器3接收sp1(步骤s432～s433)。150.接着，服务器连接部110通知sp2的数据传输开始。具体而言，从服务器连接部110对第一序列控制部141通知sp2的传输开始，第一序列控制部141经由通信i/f162对在第一pf上识别为ecu_c17的模拟的更新管理部(模拟更新管理部)的模拟更新执行部151通知传输开始(步骤s434～s436)。在步骤s436中接收了sp2的传输开始的通知的模拟更新执行部151，进行与图15的步骤s310中接收了ecu_c17的sw信息的取得请求时同样的处理，取得关于sp2的数据传输的ecu识别信息、pf信息、和转换后i/f。之后，对传输开始的通知的回应，从模拟更新执行部151经由通信i/f162、第一序列控制部141被发送至服务器连接部110(步骤s437～s439)。151.接着，服务器连接部110作为数据传输的处理，将sp2发送至第一序列控制部141，第一序列控制部141经由通信i/f162对作为ecu_c17的第一pf上的模拟更新管理部的模拟更新执行部151传输sp2(步骤s440～s442)。此时，模拟更新执行部151自身保存在步骤s442接收到的sp2，经由通信i/f162、第一序列控制部141对服务器连接部110发送对数据传输的回应(步骤s443～s445)。152.当sp2的数据传输结束时，服务器连接部110对第一序列控制部141通知sp2的数据传输结束，第一序列控制部141经由通信i/f162对作为ecu_c17的第一pf上的模拟更新管理部的模拟更新执行部151传输该通知(步骤s446～s448)。对该通知的回应经由通信i/f162、第一序列控制部141被发送至服务器连接部110(步骤s449～s451)。如步骤s442所述，由于模拟更新执行部151自身保存数据传输时接收到的sp2，所以在sp2的数据传输结束时，sp2的数据整体被保存在模拟更新执行部151中。153.另外，在图16中简略示出了，在步骤s451之后下载第二pf上的ecu_d19用的ecu包(sp3)的处理，但该一系列处理与下载ecu_c17用的ecu包(sp2)的处理(步骤s431～s451)同样，所以省略说明。154.如上所述，以第一pf以外的平台上的ecu(模拟ecu)为对象的软件包，在下载后暂时保存在模拟更新执行部151中。此时，各软件包并没有被数据传输并安装至对象ecu。作为对这些软件包的之后的处理，在本实施方式中，能够在各种时机对对象ecu进行数据传输并安装。数据传输的时机能够在图9的接口转换表220中设定。作为具体例，在图17中，对于ecu_c17用的ecu包，能够以第一序列控制部141发出包处理请求为契机而执行，对于ecu_d19用的ecu包，能够以确认激活后发出的激活请求为契机而执行。155.对图17所示的处理进行说明。首先，图17所示的步骤s501～s520的处理是ecu_c17用的ecu包的下载后的处理。156.根据图17，首先，第一序列控制部141向ecu_c17进行第一pf的包处理请求。具体而言，第一序列控制部141对通信i/f162发送面向ecu_c17的包处理请求(步骤s501)，因为该请求是面向ecu_c17的，所以通信if162对模拟更新执行部151传输该请求(步骤s502)。157.接着，接收到第一pf的包处理请求的模拟更新执行部151，参照接口转换表，将接收到的请求转换为第二pf的请求(api转换)。此处，令ecu_c17为能够在行驶中改写的ecu，在使用图9的接口转换表220的情况下，与“包处理请求”的第一pf控制命令221对应的第二pf的转换后接口223，是“[行驶中能够改写ecu的情况]数据传输请求”。因此，接收到包处理请求的模拟更新执行部151，通过进行api转换，对第二序列控制部154进行对ecu_c17的“数据传输请求”(步骤s503)。在步骤s503中，模拟更新执行部151例如从自身保存的软件包(sp2)中提取更新数据，附加在数据传输请求地发送至第二序列控制部154。[0158]第二序列控制部154对模拟更新执行部151返回对步骤s503的数据传输请求的回应后(步骤s504)，经由第二通信部164对ecu_c17请求开始sp2的数据传输(步骤s505～s506)。[0159]第二序列控制部154在数据传输的开始请求得到回应时(步骤s507～s508)，经由第二通信部164对ecu_c17的更新管理部传输sp2的数据(步骤s509～s510)。另外，在数据传输时，ecu_c17对数据传输的回应，经由第二通信部164被发送至第二序列控制部154(步骤s511～s512)。[0160]当sp2的数据传输结束时，第二序列控制部154通知sp2的数据传输结束。该通知与数据传输开始的通知的情况同样地经第二通信部164被传输至ecu_c17的更新管理部(步骤s513～s514)，其回应被发送至第二序列控制部154(步骤s515～s516)。[0161]接着，在步骤s516接收了数据传输结束的回应的第二序列控制部154，对模拟更新执行部151回答步骤s503的数据传输请求的结果(步骤s517)。模拟更新执行部151经由通信i/f162对第一序列控制部141回答步骤s501～s502的包处理请求的结果(步骤s518～s519)。[0162]通过以上步骤s501～s519的处理，从发布服务器3下载并保存在模拟更新执行部151中的ecu_c17用的ecu包(sp2)，能够被传输至对象ecu_c17并安装。之后，第一序列控制部141为了掌握确认安装了的更新包的激活的时机，对车辆状态管理部130发送车辆装置的通知请求以使其在成为能够激活的状态后进行通知(步骤s520)。[0163]接着，说明图17的步骤s521以后的处理。步骤s521以后的处理是关于更新包的激活的处理。具体而言，步骤s521～s523是关于激活的确认的处理，步骤s524～s542是关于ecu_d19用的更新程序(ecu包，sp3)的数据传输和激活的处理，步骤s543～s548是关于ecu_a13用的更新程序(ecu包，sp1)的激活的处理，步骤s549～s557是关于ecu_c17用的更新程序(ecu包，sp2)的激活的处理。[0164]作为激活的确认的契机，例如在点火装置成为了off(断开)时，车辆状态管理部130对第一序列控制部141通知车辆状态成为了能够激活的状态的情况(步骤s521)。接受了该通知的第一序列控制部141对hmi控制部120请求显示对驾驶员确认可否执行激活的确认画面(步骤s522)。在确认画面中，从驾驶员得到执行激活的允许时，hmi控制部120对第一序列控制部141返回激活确认的结果(步骤s523)。确认画面的显示方式并不特别限定，例如可以是显示等待激活的软件包的一览而能够由驾驶员选择允许对象，也可以构成为能够由驾驶员一并允许激活。另外，取决于更新软件的类别，也可以存在不需要驾驶员对激活的允许的情形。[0165]下面，假设通过步骤s521～s523的处理，对于sp1～sp3的全部软件包都得到了激活的允许，继续进行说明。[0166]对于ecu_d19用的更新程序，第一序列控制部141因为得到了激活的允许，所以经由通信i/f162对模拟更新执行部151请求激活ecu_d19的更新程序(步骤s524～s525)。因为来自第一序列控制部141的激活请求是作为第一pf的请求进行的，所以接收了该请求的模拟更新执行部151与在步骤s502接收到第一pf的包处理请求时同样地进行api转换，将接收到的激活请求转换为第二pf的请求。具体而言，在图9的接口转换表220中与“激活请求”的第一pf控制命令221对应的第二pf的转换后接口223成为“第二通信部[行驶中不可改写ecu的情况]数据传输请求”。[0167]此处，如利用图5所说明的那样，ecu_d19是行驶中不可改写的ecu，因此模拟更新执行部151对第二序列控制部154发送数据传输请求，第二序列控制部154经由第二通信部164对ecu_d19进行下载了的软件包(sp3)的数据传输请求(步骤s526～s527)。[0168]另外，从模拟更新执行部151接收了数据传输请求之后的、从第二序列控制部154对ecu_d19进行的数据传输的一系列的处理次序，与通过之前关于对ecu_c17的数据传输说明了的步骤s505～s517的处理改变了传输目的地的ecu的情况相同，因此省略详细处理(步骤s528～s540)。[0169]在步骤s540中从第二序列控制部154对模拟更新执行部151回答数据传输请求的结果时，模拟更新执行部151经由通信i/f162对第一序列控制部141回答步骤s524～s525的激活请求的结果(步骤s541～s542)。[0170]通过以上步骤s524～s542的处理，能够从模拟更新执行部151对ecu_d19传输ecu_d19用的更新程序(ecu包，sp3)，并在安装之后激活。[0171]接着，关于ecu_a13用的更新程序，第一序列控制部141因为得到了激活的允许，所以经由通信i/f162和第一通信部163对ecu_a13进行激活请求。因为ecu_a13是第一pf上的ecu，所以不需要如上述ecu_d19那样经由模拟更新执行部151进行处理，在执行激活之后从ecu_a13对第一序列控制部141发送回应，ecu_a13用的更新程序的激活完成(步骤s543～s548)。[0172]接着，关于ecu_c17用的更新程序，第一序列控制部141因为得到了激活的允许，所以经由通信i/f162对模拟更新执行部151请求激活ecu_c17的更新程序(步骤s549～s550)。接收了该请求的模拟更新执行部151进行api转换，将接收到的激活请求转换为第二pf的请求。其中，ecu_c17是行驶中可改写的ecu，对象更新程序已经通过步骤s503～s517的处理被传输至ecu_c17并已安装，因此不需要传输数据，只要对ecu_c17传输激活请求即可。这一点也可以根据在图9的接口转换表220中、与“激活请求”的第一pf控制命令221对应的第二pf的转换后接口223是“第二通信部[行驶中可改写ecu的情况下]激活请求”确认。[0173]从而，模拟更新执行部151对第二序列控制部154发送激活请求，第二序列控制部154经由第二通信部164对ecu_c17传输激活请求(步骤s551～s554)。在ecu_c17更新程序(sp2)有效之后，从ecu_c17经由第二通信部164对第二序列控制部154发送结果(步骤s555～s556)，进而，第二序列控制部154对模拟更新执行部151回答步骤s551～s552的激活请求的结果(步骤s557)。另外，进一步在之后，模拟更新执行部151经由通信i/f162对第一序列控制部141回答步骤s549～s550的激活请求的结果，但是在图17中省略了记载。[0174]通过以上步骤s549～s557等的处理，对于ecu_c17用的更新程序(ecu包，sp2)，也能够在ecu_c17中使其有效(激活)。[0175](1-3-5)结束处理[0176]图18是表示结束处理的次序例的序列图。图18中，示出了使在第一pf上处理的各ecu结束时的次序例。该结束处理的流程根据对象是第一pf的ecu、还是在第一pf上模拟了的模拟ecu而不同。[0177]在第一pf上的ecu_a13的结束处理中，第一序列控制部141经由通信i/f162和第一通信部163对第一pf上的ecu_a13请求ecu_a13的结束处理(步骤s601～s603)。在结束处理完成时从ecu_a13对第一序列控制部141发送回应(步骤s604～s606)。[0178]另一方面，在第一pf上模拟了的ecu_c17的结束处理中，第一序列控制部141经由通信i/f162对第一pf上的ecu_c17的模拟更新管理部即模拟更新执行部151请求结束处理(步骤s607～s608)。接收了结束处理请求的模拟更新执行部151基于接收到的请求取得ecu识别信息、pf信息、和转换后i/f(参照图15)，在使在第一pf上模拟了的ecu_c17的模拟更新管理部结束后，经由通信i/f162对第一序列控制部141发送对结束处理请求的回应(步骤s609～s610)。[0179]另外，在第一pf上模拟了的ecu_d19的结束处理也与上述的ecu_c17的结束处理相同(步骤s611～s614)。[0180]如上所述，通过进行步骤s601～s614的处理，第一序列控制部141能够执行在第一pf上控制的系统内的ecu的结束处理。[0181](1-3-6)基于执行条件的车辆状态的判断处理[0182]图19是表示车辆状态管理部130进行的车辆状态的判断处理的处理次序例的流程图。图19所示的处理是用于第一更新控制部140(尤其是第一序列控制部141)基于发布包250中包括的车辆整体更新控制信息251中的执行条件256、掌握能够执行软件更新的各过程(process)的时机的处理，相当于图17的步骤s520～s521的详细处理。[0183]根据图19，首先，第一更新控制部140的第一序列控制部141将发布包250中包括的车辆整体更新控制信息251中的执行条件251(具体而言，例如是点火装置off)设定至车辆状态通知请求的参数，发送至车辆状态管理部130(步骤s5201)。[0184]接着，车辆状态管理部130接收车辆状态通知请求(步骤s5202)时，确认当前的车辆状态是否与接收到的车辆状态通知请求中包括的执行条件相符合(步骤s5203)。在符合执行条件的情况下(步骤s5203的“是”)，车辆状态管理部130对第一更新控制部140(第一序列控制部141)通知车辆状态符合执行条件的情况(步骤s521)。[0185]另一方面，在步骤s5203中当前的车辆状态不符合执行条件的情况下(步骤s5203的“否”)，车辆状态管理部130监视状态直到车辆状态符合接收到的车辆状态通知请求的执行条件(步骤s5204)，确认符合时，对第一更新控制部140(第一序列控制部141)通知车辆状态符合执行条件的情况(步骤s521)。[0186]通过执行上述步骤s5201～s521的处理，软件更新装置10能够基于执行条件256确认车辆的状态后执行更新过程，因此能够安全地实施软件更新。另外，通过将执行条件包括在发布包250中发送，能够与更新内容相应地灵活地设定安全条件。[0187](1-3-7)发布包生成处理[0188]图20是表示发布包生成处理的处理次序例的流程图。图20所示的发布包生成处理是发布服务器3的发布包生成部31生成发布包250的处理。[0189]根据图20，首先，发布包生成部31从软件管理系统4的软件包管理部42读取软件包(步骤s1001)。[0190]接着，发布包生成部31判断在步骤s1001读取到的软件包是面向第一pf的包、还是面向第二pf的包(步骤s1002)。在判断为面向第一pf的软件包的情况下(步骤s1002的第一pf)，发布包生成部31从软件包230(参照图10)中提取更新对象软件信息261(步骤s1003)。另一方面，在判断为面向第二pf的软件包的情况下(步骤s1002的第二pf)，发布包生成部31根据软件包240(参照图11(a))的更新对象软件信息243，生成面向软件包240的更新对象软件信息261(步骤s1004)。[0191]发布包生成部31反复进行步骤s1001～s1004的处理，对于读取出的全部软件包提取或生成更新对象软件信息261时，接着生成车辆整体更新控制信息251(步骤s1005)。[0192]最后，发布包生成部31根据在步骤s1003～s1005中生成的车辆整体更新控制信息251和更新对象软件信息261，生成数字签名271(步骤s1006)。[0193]如上所述，通过执行步骤s1001～s1006的处理，发布包生成部31在从软件包管理部42读取出的软件包是第二pf用的包的情况下，通过生成与第一pf用的包相应的更新对象软件信息261，能够生成在第一pf也能够处理的发布包250。[0194]以上，如参照各附图详细说明的那样，根据本实施方式的软件更新装置10，即使在车辆系统由多个平台构成的情况下，也能够在第一平台上管理和控制各平台上的软件单元(ecu)、ecu内的软件。详细而言，在第二更新控制部150中，保存与第一平台之间的识别信息的对应关系(模拟ecu对应管理表)、接口的对应关系(接口转换表)，模拟更新执行部151进行平台间的转换，将第一平台以外的平台上的ecu作为第一平台上的模拟的ecu，由此，第一平台的控制部(第一更新控制部140)能够在第一平台上统一地控制对各ecu的控制命令、软件处理。[0195]另外，本实施方式的软件更新装置10，对于从车辆2外部的发布服务器3提供的软件包，能够不依存于对象ecu所处的平台地、用第一平台的控制部(第一更新控制部140)接收，进而能够在第一平台上指示对对象ecu的安装、激活等请求。另外，还能够在第一平台上统一地指示对各ecu的软件的更新等处理。即，本实施方式的软件更新装置10能够灵活地更新由多个平台构成的车辆系统的软件。[0196]另外，本实施方式的软件更新装置10如上所述，能够使用表示平台间的对应关系的管理信息，在1个平台上处理多个平台上的ecu，因此即使在车辆系统中的平台的结构发送了变化、或进行了ecu的追加等的情况下，也能够仅改变上述管理信息而不进行大幅度的设计改变等地应对，因此能够通过可扩展的机制进行扩展支持。[0197](2)第二实施方式[0198]在第一实施方式中示出了：对于第一pf的更新控制功能，通过由第二pf的控制功能模拟第一pf，能够实现多个pf的软件更新。而在第二实施方式中示出：第二pf的更新功能能够控制第一pf的更新控制功能而实现多个pf的软件更新。另外，在第二实施方式的说明中，对于与第一实施方式同样的结构和处理，省略说明。[0199](2-1)网关的软件结构[0200]图21是表示本发明的第二实施方式的软件更新装置(网关)10a的功能结构例的框图。在第二实施方式中，代替第一实施方式中的网关10，使用网关10a。另外，在图21中，对于附加了与图6相同的编号的构成要素，省略其说明。[0201]如图21所示，网关(软件更新装置)10a构成为包括第三更新控制部340、第四更新控制部350、和通信部160。[0202]第三更新控制部340实施以第二pf为基础的ecu的软件更新控制。第三更新控制部340由第三序列控制部341、第三设备信息管理部343、服务器连接部110、hmi控制部120、车辆状态管理部130、和第n序列控制部344构成。第n序列控制部344与图6中举例示出了第二序列控制部的第n序列控制部154同样地按每个平台控制该平台的软件更新的序列。即，本实施方式的第n序列控制部344中，包括控制第一pf的更新序列的控制部。[0203]第三序列控制部341控制软件更新的序列整体。第三序列控制部341经由第n序列控制部344整体地控制车辆2的系统内存在的第二pf的ecu和第一pf的软件更新。第三序列控制部341在更新第一pf的软件时，按照由第一pf定义的接口规格对第四更新控制部350进行控制指示，控制软件更新。第三设备信息管理部343与图6所示的设备信息管理部143同样地收集车辆2内的软件信息，管理车辆2的结构信息(构成信息)。[0204]第四更新控制部350根据第三更新控制部340的指示，实施第一pf的软件更新控制。第四更新控制部350由第四序列控制部351、依存关系管理部142、和设备信息管理部143构成。第四序列控制部351控制第一pf中的软件更新的序列。[0205]通过如上所述地构成网关10a，在第二实施方式中，如果对第二pf的更新控制功能追加第一pf用的第n序列控制部344，则能够进行第一pf的软件更新。[0206](2-2)处理[0207]以下，对于由第二实施方式的软件更新系统中执行的各种动作或处理，以与第一实施方式不同的部分为中心，详细进行说明。[0208](2-2-1)启动时动作[0209]图22是表示第二实施方式中的车辆2中的系统启动时动作的次序例的序列图。车辆2中的系统例如以车辆2的电源on(接通)等为契机而启动，此时网关(软件更新装置)10a开始图22所示的启动时动作。[0210]根据图22，首先，第四更新控制部350的第四序列控制部351对通信部160的服务管理部161发送请求检索车辆2的系统内存在的服务的更新对象检索请求(步骤s1101)。[0211]接收了步骤s1101的更新对象检索请求的服务管理部161，经由第一通信部163在系统内发出探索请求，并接受其探索结果的通知(步骤s1102～s1105)。更具体而言，根据从第一通信部163接受到的探索请求，各ecu的软件发出表示自身的服务存在的服务通知。关于图22的步骤s1102～s1107的探索请求、服务的登记的动作，与图13的步骤s102～s107相同，因此省略说明。[0212]接着，第四序列控制部351将自身作为服务登记在服务管理部161中(步骤s1109，第四序列控制登记)。[0213]另外，与上述处理并行地，第三序列控制部341对第n序列控制部344进行第一pf更新准备请求(步骤s1110)。接收到上述请求时，第n序列控制部344对服务管理部161发出第四序列控制部探索请求而取得访问信息(步骤s1111)，基于该信息对第四序列控制部351请求确认车辆状态(步骤s1112)和确认用户if(步骤s1113)。通过发出这些请求，第n序列控制部344在需要确认车辆状态的情况下对第四序列控制部351通知车辆状态请求通知的发行目的地，在需要确认用户的情况下对第四序列控制部351通知用户确认请求通知的发行目的地。由此，第四序列控制部351能够对适当的通知目的地发出车辆状态请求通知和用户确认请求通知。[0214]如上所述，通过进行图22所示的启动时动作，在网关10a中，能够在车辆2的系统启动时将系统内存在的服务登记在服务管理部161的管理信息中，第n序列控制部344能够取得并访问第四序列控制部351的访问信息，第四序列控制部351能够掌握车辆状态请求通知和用户确认请求通知的发行目的地。另外，第一pf更新准备也可以不是在启动时实施，而是在需要更新时实施。[0215](2-2-2)结构信息的收集～车辆包的接收[0216]图23是表示第二实施方式中的关于从结构信息的收集到车辆包的接收的次序例的序列图。更详细而言，在图23中示出了：第三序列控制部341收集系统内的软件信息、服务器连接部110将其作为结构信息发送至发布服务器3并进行同步、第三序列控制部341基于从发布服务器3提供的活动信息决定要下载的车辆包(发布包、软件包)的一览、接收各车辆包的处理的次序例。[0217]根据图23，首先，第三序列控制部341对第n序列控制部344请求取得sw信息(步骤s1201)。第n序列控制部344接受上述请求时经由第二通信部164取得ecu_c17的sw信息(步骤s3112～s3132)。接着，第n序列控制部344对第四序列控制部351请求取得第二pf的sw信息(步骤s1205)。接受上述请求时，第四序列控制部351取得ecu_a13的sw信息(步骤s303～s308)。在图23中，省略ecu_b16的sw信息取得的图示。当第一pf的ecu的sw信息的收集完成时，第四序列控制部351对第n序列控制部344发送收集到的sw信息(步骤s1212)。[0218]当经由第n序列控制部344进行的车辆2的sw信息的收集完成(步骤s1213)时，第三序列控制部341对服务器连接部110请求对服务器通知sw信息(步骤s1214)，服务器连接部110将接收到的这些软件信息作为结构信息通知给发布服务器3(步骤s318)。[0219]接着，发布服务器3基于步骤s318中接收到的结构信息，确认是否存在能够更新的软件，在存在能够更新(从车辆2看时是下载)的软件的情况下，对服务器连接部110回应用于进行该更新的活动信息(步骤s319)。[0220]接着，服务器连接部110对第三序列控制部341通知服务器的回应结果的活动信息(步骤s1215)。对于第三序列控制部341读取要下载的更新包的一览的详细方法，省略说明，例如第三序列控制部341可以通过例如hmi控制部120使hmi显示活动的一览，由用户选择想要下载的车辆包(更新包)。第三序列控制部341对服务器连接部110通知第一包取得请求(步骤s1216)。[0221]接着，服务器连接部110对发布服务器3请求提供第一包(步骤s1206)。从发布服务器3接收了更新包(步骤s1207)的服务器连接部110暂时保存上述接收到的包，对第三序列控制部341通知取得完成的消息(步骤s1217)。[0222]然后，第三序列控制部341经由第n序列控制部344对第四序列控制部351请求开始传输更新包(第一包)(步骤s1218)，第n序列控制部344对第四序列控制部351传输第一包(步骤s324～s325)。第n序列控制部344在第一包的传输结束时，对第三序列控制部341通知第一包的传输完成(步骤s1219)。[0223]通过以上步骤s1201～s1219的处理，第三序列控制部341能够取得关于系统内的能够更新的软件的信息(活动信息)，从发布服务器3下载从活动中选择的任意的车辆包(更新包)。[0224](2-2-3)安装[0225]图24是表示第二实施方式中的更新ecu的软件包的安装次序例的序列图。作为图24所示的处理的前提，设想：通过图23所示的处理由第四序列控制部351从发布服务器3取得的活动信息中包括用于更新第二pf的软件的信息，下载了的更新包中包括用于更新第一pf的软件的信息。在图24中，示出从发布服务器3下载用于更新各ecu的软件包(sp1～sp3)、对各ecu进行安装(传输数据)的处理的次序例。另外，与第一实施方式同样，对ecu传输数据的时机也能够是在得到执行激活的允许之后，这里省略详细说明。另外，用于确认可否安装的车辆状态的确认也在本图中省略。[0226]在图24中，第三序列控制部341基于车辆状态管理部130取得的车辆状态判断是否可以开始安装处理(未图示)之后，在判断为可以开始安装处理的情况下，开始以下说明的ecu更新用的软件包(sp)的下载。[0227]另外，下载ecu更新用的软件包的处理次序，根据对象ecu是否为第一pf上的ecu而不同。即，在图24中，在下载ecu_a13用的ecu包(sp1)的情况、和下载ecu_c17用的ecu包(sp2)或ecu_d19用的ecu包(sp2)的情况下，处理次序(处理流程)不同。[0228]在下载ecu_a13用的ecu包(sp1)的处理中，首先，第三序列控制部341对服务器连接部110请求取得sp1(步骤s1301)。接受了该请求的服务器连接部110通过对发布服务器3请求取得sp1，而从发布服务器3接收sp1(步骤s404～s405)。[0229]接着，服务器连接部110回应sp1的数据传输开始(步骤s13011)。接收到数据传输开始的回应时，第三序列控制部341经由第n序列控制部344对第四序列控制部351请求开始传输数据(步骤s1302)。具体而言，从第n序列控制部344对第四序列控制部351通知sp1的传输开始，第四序列控制部351经由通信i/f162和第一通信部163对第一pf上的ecu_a13的更新管理部通知传输开始(步骤s406～s409)。对该传输开始的通知的回应，从ecu_a13经由第一通信部163、通信i/f162、第一序列控制部141被发送至服务器连接部110(步骤s410～s413)。[0230]接着，第n序列控制部344将sp1的数据传输至ecu_a13。具体而言，从第n序列控制部344对第四序列控制部351发送sp1，第四序列控制部351经由通信i/f162和第一通信部163对第一pf上的ecu_a13的更新管理部传输sp1(步骤s414～s417)。对该数据传输的回应，从ecu_a13经由第一通信部163、通信i/f162、第四序列控制部351被发送至服务器连接部110(步骤s418～s421)。[0231]在sp1的数据传输结束时，第n序列控制部344通知sp1的数据传输结束。该通知与数据传输开始的通知的情况同样地经由第四序列控制部351、通信i/f162、第一通信部163被传输至ecu_a13的更新管理部(步骤s422～s425)，其回应被发送至服务器连接部110(步骤s426～s429)。[0232]如上所述，网关10a能够经由第三序列控制部341和第n序列控制部344将来自发布服务器3的软件包(在此情况下是sp1)直接发送至ecu_a，ecu_a13的更新管理部能够安装接收到的sp1。[0233]另一方面，在第二pf的ecu用的ecu包的下载中，所下载的软件包不是立即被传输至对象ecu，而是暂时保存在网关10a内(第三序列控制部341)。作为这样的处理次序的一例，以下说明下载ecu_c17用的ecu包(sp2)的处理流程。[0234]在下载ecu_c17用的ecu包(sp2)的处理中，首先，第三序列控制部341对服务器连接部110请求取得sp2(步骤s1304)。接受了该请求的服务器连接部110通过对发布服务器3请求取得sp1，而从发布服务器3接收sp1(步骤s432～s433)，sp2的保存完成时对第三序列控制部341通知该消息(步骤s1305)。[0235]接着，第三序列控制部341通知sp2的数据传输开始。具体而言，从第三序列控制部341对第n序列控制部344通知sp2的传输开始，第n序列控制部344经由第二通信部164对ecu_c17通知传输开始(步骤s505～s508)。接着，第n序列控制部344作为数据传输的处理，将sp2发送至ecu_c17(步骤s509～s512)。当sp2的数据传输结束时，第n序列控制部344对ecu_c17通知sp2的数据传输结束(步骤s513～s516)。[0236]如上所述，网关10a能够通过第二pf的第三序列控制部341控制来自发布服务器3的软件包的下载和安装。[0237](2-2-4)激活[0238]图25是表示第二实施方式中的更新ecu的软件包的激活次序例的序列图。[0239]根据图25，首先，第四序列控制部351为了掌握确认所安装了的更新包的激活的时机(timing，时间)，经由第n序列控制部344和第三序列控制部341对车辆状态管理部130发送车辆状态的通知请求以使得在成为了能够激活的状态时进行通知(步骤s1401～s1403)。[0240]作为确认激活的契机，例如在点火装置成为了off(ig-off)时，车辆状态管理部130经由第三序列控制部341和第n序列控制部344对第四序列控制部351通知车辆状态成为了能够激活的状态的情况(步骤s1404～1406)。[0241]接受了该通知的第四序列控制部351经由第n序列控制部344和第三序列控制部341对hmi控制部120请求显示向驾驶员确认可否执行激活的确认画面(步骤s1407～s1410)。在确认画面中，从驾驶员得到执行激活的允许时，hmi控制部120对第三序列控制部341通知确认结果(步骤s1411)。第三序列控制部341接收到结果时，对第n序列控制部344请求执行激活(步骤s1413)。确认画面的显示方式并不特别限定，例如可以显示等待激活的软件包的一览而能够由驾驶员选择允许对象，也可以是能够由驾驶员一并允许激活。另外，取决于更新软件的种类，也可以不需要驾驶员进行激活的允许。[0242]接收到激活请求时，第n序列控制部344首先对第四序列控制部351请求用户确认结果通知和开始激活，第四序列控制部351经由通信if162对ecu_a13请求激活(步骤s543～s548)。接着，第n序列控制部344经由第二通信部164对ecu_c17请求激活(步骤s552～s557)。[0243]在各ecu中更新对象ecu的激活完成时，第n序列控制部344对第三序列控制部341通知其结果(步骤s1414)。[0244]之后，第三序列控制部341对第n序列控制部344请求结束处理(步骤s1415)，第n序列控制部344经由通信if162对ecu_a13请求结束处理(步骤s602～s605)。更新对象ecu的结束处理完成时，第n序列控制部344对第三序列控制部341通知其结果(步骤s1416)，激活处理结束。[0245]如上所述，网关10a能够用第二pf的第三序列控制部341控制已安装在更新对象的ecu中的软件包的激活。[0246]如以上所说明的那样，根据第二实施方式的软件更新装置10a，第二pf的更新功能能够控制第一pf的更新控制功能而实现多个pf的软件更新。从而，即使在车辆系统由多种平台构成的情况下，也能够在第二平台上管理和控制各平台上的软件单元(ecu)、ecu内的软件。即，第二实施方式的软件更新装置10a，与第一实施方式的软件更新装置10同样地能够灵活地更新由多个平台构成的车辆系统的软件。[0247]另外，本发明不限定于上述实施方式，包括各种变形例。例如，上述实施方式是为了易于理解地说明本发明而详细说明的，并不限定于必须包括说明了的全部结构。另外，对于实施方式的结构的一部分，能够追加、删除、置换其他结构。[0248]另外，关于上述各结构、功能、处理部、处理单元等，例如可以通过在集成电路中设计等而用硬件实现其一部分或全部。另外，上述各结构、功能等，也可以通过处理器解释、执行实现各功能的程序而用软件实现。实现各功能的程序、表、文件等信息，能够保存在存储器、硬盘、ssd(solidstatedrive)等记录装置、或者ic卡、sd卡、dvd等记录介质中。[0249]另外，在各个附图中，控制线、信息线示出了认为说明上必要的，并不一定示出了产品上全部的控制线、信息线。实际上也可以认为几乎全部结构都相互连接。[0250]附图标记的说明[0251]1软件更新系统[0252]2车辆[0253]3发布服务器[0254]4(4a，4b，4x)软件管理系统[0255]5网络[0256]6诊断装置[0257]10，10a网关(软件更新装置)[0258]11车内网络[0259]12通信模块[0260]13驾驶辅助综合ecu(ecu_a)[0261]14相机ecu[0262]15传感器ecu[0263]16底盘综合ecu(ecu_b)[0264]17发动机控制ecu(ecu_c)[0265]18变速机控制ecu[0266]19气囊ecu(ecu_d)[0267]20hvacecu[0268]21车体管理ecu[0269]22ivi(ecu_e)[0270]31发布包生成部[0271]32发布包管理部[0272]33发布部[0273]41软件包生成部[0274]42软件包管理部[0275]50交换机[0276]51，61soc[0277]52，62，81，91微控制器[0278]53，63非易失性存储器[0279]54，58，68，84，94rom[0280]55，56，65，66，82，92cpu[0281]57，64，67，83，93ram[0282]59，69，85，95通信控制部[0283]70，86第一存储体[0284]71，87第二存储体[0285]110服务器连接部[0286]120hmi控制部[0287]130车辆状态管理部[0288]140第一更新控制部[0289]141第一序列控制部[0290]142依存关系管理部[0291]143设备信息管理部[0292]150第二更新控制部[0293]151模拟更新执行部[0294]152依存关系管理部[0295]153转换信息管理部[0296]154第n序列控制部(第二序列控制部)[0297]155模拟ecu管理部[0298]156接口管理部[0299]160通信部[0300]161服务管理部[0301]162通信i/f[0302]163第一通信部[0303]164第二通信部[0304]165第三通信部[0305]170funca[0306]171第一app[0307]172第二pf_mw[0308]173rtos[0309]180funcb[0310]181第三app[0311]182第四app[0312]183第一pf_mw[0313]184posix_os184[0314]185，186第一pf_sw[0315]190虚拟机管理器[0316]210模拟ecu对应管理表[0317]220接口转换表[0318]230，240软件包[0319]250发布包[0320]340第三更新控制部[0321]341第三序列控制部[0322]343第三设备信息管理部[0323]344第n序列控制部[0324]350第四更新控制部[0325]351第四序列控制部。当前第1页12当前第1页12
技术特征：
1.一种软件更新装置，其与包括在第一平台上构成的第一软件单元、和在不同于所述第一平台的第二平台上构成的第二软件单元的多个软件单元连接，所述软件更新装置的特征在于，包括：进行所述第一软件单元的软件更新的第一更新控制部；和进行所述第二软件单元的软件更新的第二更新控制部，所述第一更新控制部具有发送面向所述第一平台的控制命令的第一序列控制部，所述第二更新控制部具有模拟更新执行部，其将所述第二软件单元模拟为所述第一平台上的软件单元，基于对在所述第一平台上模拟了的所述第二软件单元的所述控制命令的接收，控制所述第二软件单元的软件更新。2.如权利要求1所述的软件更新装置，其特征在于：所述第二更新控制部还具有：管理在所述控制命令的转换时参照的转换信息的转换信息管理部，所述模拟更新执行部在从所述第一序列控制部接收到对在所述第一平台上模拟了的所述第二软件单元的面向所述第一平台的控制命令时，基于所述转换信息，将该控制命令转换为面向所述第二平台的控制命令，将转换后的控制命令发送给所述第二软件单元。3.如权利要求2所述的软件更新装置，其特征在于：所述转换信息管理部保存第一转换信息作为所述转换信息之一，所述第一转换信息对于在所述第二平台上构成的各个所述第二软件单元，表示在所述第一平台上进行模拟时的识别信息与所述第二平台上的识别信息的对应关系。4.如权利要求2所述的软件更新装置，其特征在于：所述转换信息管理部保存第二转换信息作为所述转换信息之一，所述第二转换信息表示面向所述第一平台的控制命令与面向所述第二平台的控制命令的对应关系。5.如权利要求4所述的软件更新装置，其特征在于：在所述第二转换信息中，关于软件可否改写设定了在所述第二平台中所述第二软件单元所依存的依存条件，所述模拟更新执行部，在通过来自所述第一序列控制部的面向所述第一平台的控制命令请求了进行所述第二软件单元的软件更新时，参照所述第二转换信息，在满足所述依存条件的情况下更新软件，在不满足所述依存条件的情况下不更新软件。6.如权利要求2所述的软件更新装置，其特征在于：在从经由网络连接的发布服务器发布了所述第二软件单元的更新程序的情况下，所述第一序列控制部对在所述第一平台上模拟了的所述第二软件单元发送请求所述更新程序的数据传输的控制命令，接收了该控制命令的所述模拟更新执行部基于所述转换信息，在直到规定条件成立为止的期间，不将所述更新程序传输至所述第二软件单元而将其暂时保存。7.如权利要求6所述的软件更新装置，其特征在于：在对于从所述发布服务器发布了的所述第二软件单元的所述更新程序得到了激活的允许的情况下，所述第一序列控制部对在所述第一平台上模拟了的所述第二软件单元发送请求使所述更新程序有效的控制命令，
接收了该控制命令的所述模拟更新执行部，在向所述第二软件单元进行的所述更新程序的传输结束后，对所述第二软件单元发送指示使所述更新程序有效的控制命令。8.一种软件更新系统，其中，发布更新程序的发布服务器与车辆系统由网络连接，所述软件更新系统的特征在于：所述车辆系统包括：多个软件单元，其包括在第一平台上构成的第一软件单元、和在不同于所述第一平台的第二平台上构成的第二软件单元；和软件更新装置，其与所述第一软件单元及所述第二软件单元连接，所述软件更新装置具有：进行所述第一软件单元的软件更新的第一更新控制部；和进行所述第二软件单元的软件更新的第二更新控制部，所述第一更新控制部具有发送面向所述第一平台的控制命令的第一序列控制部，所述第二更新控制部具有模拟更新执行部，其将所述第二软件单元模拟为所述第一平台上的软件单元，基于对在所述第一平台上模拟了的所述第二软件单元的所述控制命令的接收，控制所述第二软件单元的软件更新。9.一种软件更新装置执行的软件更新方法，所述软件更新装置与包括在第一平台上构成的第一软件单元、和在不同于所述第一平台的第二平台上构成的第二软件单元的多个软件单元连接，所述软件更新方法的特征在于：所述软件更新装置具有：发送面向所述第一平台的控制命令，进行所述第一软件单元的软件更新的第一更新控制部；和将所述第二软件单元模拟为所述第一平台上的软件单元，进行所述第二软件单元的软件更新的第二更新控制部，所述软件更新方法包括：第一步骤，所述第一更新控制部发送对在所述第一平台上模拟了的所述第二软件单元的所述控制命令；和第二步骤，接收了所述控制命令的所述第二更新控制部，将该控制命令转换为面向所述第二平台的控制命令，并利用转换后的控制命令控制所述第二软件单元的软件更新。

技术总结
软件更新装置(网关)(10)包括：进行第一软件单元(例如ECU_A13、ECU_B16)的软件更新的第一更新控制部(140)、和进行第二软件单元(例如ECU_C17、ECU_D19)的软件更新的第二更新控制部(150)。第一更新控制部(140)具有发送面向第一平台的控制命令的第一序列控制部(141)，第二更新控制部(150)具有模拟更新执行部(151)，其将第二软件单元模拟为第一平台上的软件单元，基于对在第一平台上模拟了的第二软件单元的控制命令的接收，控制第二软件单元的软件更新。新。新。


技术研发人员：寺冈秀敏 矢野正
受保护的技术使用者：日立安斯泰莫株式会社
技术研发日：2021.08.23
技术公布日：2023/9/20