CN110795138B - 软件发布系统、软件发布服务器和软件发布方法 - Google Patents

Abstract

本发明能够防止人为失误导致的错误的软件发布。软件发布系统(1)包括：软件发布服务器(远程信息处理中心(10))，其通过活动来管理对于车辆(20)的车载设备(ECU)进行的功能的更新，远程发布基于活动的软件；终端(终端(30)、导航终端(230))，其进行输入输出；软件更新装置(210)，其装载于车辆(20)，下载发布的软件，并将其安装于对象的车载设备。在该软件发布系统(1)中，在委托活动的创建时，将委托活动的对象车载设备的最近的多次活动的软件的更新量的统计信息和委托活动的软件的更新量进行比较，在满足规定条件的情况下，不创建委托活动而通知规定的警告。

Description

软件发布系统、软件发布服务器和软件发布方法

技术领域

本发明涉及软件发布系统、软件发布服务器、和软件发布方法，适用于对于装载于汽车等的车辆的设备实现远程的软件更新的软件发布服务器、软件发布系统、和软件发布方法。

背景技术

近年来，由于驾驶辅助功能和自动驾驶技术的进展，装载于汽车的车载设备(电子控制装置(ECU：Electric Control Unit))的软件的规模增大。对于该ECU软件，设计开发阶段中的测试版本升级、软件出问题导致的召回应对和量产前后的统一版本升级等、需要更新的场景增加。为了有效地应对这种软件的更新机会的增加，通过将现有手机、电视中使用的基于无线的远程软件更新技术应用于汽车，来远程更新汽车的ECU软件的软件发布技术、向所谓OTA(Over The Air)的期待变高。

在此，例如专利文献1中公开有一种在装载于车辆的控制装置的程序更新中，防止用户操作车辆设备的程序提供系统。专利文献1所公开的程序提供系统中，通过在车辆的用户充分离开车辆的情况下指示程序的更新，而不能在程序的更新中进行车辆设备的操作，能够有效地完成程序(软件)的更新。

现有技术文献

专利文献

专利文献1：日本特许第5829839号公报

发明内容

发明要解决的课题

但是，根据上述的专利文献1中公开的程序提供系统，虽然获得能够可靠地更新所发布的软件的效果，但不能防止这之前因人为失误(人为错误)而错误地选择要发布的软件。

在对于汽车的ECU的OTA中，发布软件的ECU的种类处于增加倾向，另外，各ECU中发布的软件的文件名和版本名称大多类似。因此，在决定要发布的软件时，可能发生人为失误导致的软件的错误选择。特别是在汽车的设计开发工序中，使用多个版本的软件反复进行测试，所以更容易发生软件版本的确认失误和误读等，在发布了错误的软件的情况下，有可能因返工而失去重要的测试时间。因此，对于这种课题要求有效的软件发布技术。

本发明是考虑了以上的问题点而研发的，提出一种在对于车载设备的软件更新中，能够防止人为失误导致的错误的软件发布的软件发布系统、软件发布服务器、和软件发布方法。

用于解决课题的方法

为了解决所述的课题，本发明中提供一种控制对于车辆的车载设备的功能的更新的如下所述的软件发布系统。该软件发布系统包括：软件发布服务器，其通过活动来管理上述功能的更新，将基于该活动的软件远程发布到该活动的对象车辆；终端，其接收操作者的操作来进行对于上述软件发布服务器的输入输出；和软件更新装置，其装载于上述车辆，下载从上述软件发布服务器发布的上述软件，并将其安装于对象的车载设备，上述软件发布服务器具有：存储部，其存储包含上述软件的各种信息；活动管理部，其从上述终端接收上述活动所需的信息，将由上述接收到的信息构成的活动信息登记于上述存储部，由此创建该活动；和软件发布部，其按照登记于上述活动管理部的上述活动信息，将基于上述活动的上述软件远程发布到该活动的对象车辆，在通过上述终端的操作委托了上述活动的创建时，上述活动管理部将作为上述委托的活动的对象的上述车辆的车载设备的最近的多次活动的上述软件的更新量的统计信息和上述委托的活动的上述软件的更新量进行比较，在满足规定条件的情况下，不创建上述委托的活动而准备规定的警告并将其发送到上述终端，上述终端将从上述活动管理部接收到的上述规定的警告显示于规定的显示画面。

另外，为了解决所述的课题，本发明中，提供一种软件发布服务器，其通过活动来管理对车辆的车载设备进行的功能的更新，将基于该活动的软件远程发布到该活动的对象车辆。该软件发布服务器的特征在于，包括：存储部，其存储包含上述软件的各种信息；活动管理部，其从终端接收上述活动所需的信息，将由上述接收到的信息构成的活动信息登记于上述存储部，由此创建该活动；和软件发布部，其按照登记于上述活动管理部的上述活动信息，将基于上述活动的上述软件远程发布到该活动的对象车辆，从上述终端接收到创建上述活动的委托时，上述活动管理部将作为上述委托的活动的对象的上述车辆的车载设备的最近的多次活动的上述软件的更新量的统计信息和上述委托的活动的上述软件的更新量进行比较，在满足规定条件的情况下，不创建上述委托的活动而准备规定的警告并将其发送到上述终端。

另外，为了解决所述的课题，本发明中，提供由控制对车辆的车载设备进行的功能的更新的软件发布系统进行的以下那样的软件发布方法。在此，上述软件发布系统具有：软件发布服务器，其通过活动来管理上述功能的更新，将基于该活动的软件远程发布到该活动的对象车辆；终端，其接收操作者的操作来进行对于上述软件发布服务器的输入输出；和软件更新装置，其装载于上述车辆，下载从上述软件发布服务器发布的上述软件，并将其安装于对象的车载设备。另外，上述软件发布服务器具有：存储部，其存储包含上述软件的各种信息；活动管理部，其从上述终端接收上述活动所需的信息，将由上述接收到的信息构成的活动信息登记于上述存储部，由此创建该活动；和软件发布部，其按照登记于上述活动管理部的上述活动信息，将基于上述活动的上述软件远程发布到该活动的对象车辆。本软件发布方法的特征在于，在具有上述结构的软件发布系统中，在通过上述终端的操作委托了上述活动的创建时，包括如下步骤：比较步骤，上述活动管理部将作为上述委托的活动的对象的上述车辆的车载设备的最近的多次活动的上述软件的更新量的统计信息和上述委托的活动的上述软件的更新量进行比较；活动不创建步骤，在上述比较步骤中满足规定条件的情况下，上述活动管理部不创建上述委托的活动而准备规定的警告并将其发送到上述终端；和警告显示步骤，接受上述活动不创建步骤，上述终端将从上述活动管理部接收到的上述规定的警告显示于规定的显示画面。

发明的效果

根据本发明，在对于车载设备的软件更新中，能够防止人为失误导致的错误的软件发布。本发明特别是在开发工序的测试中发挥有效的效果。

附图说明

图1是表示本发明的一个实施方式的软件发布系统的结构例的图。

图2是表示车辆信息的具体例的图。

图3是表示车辆结构信息的具体例的图。

图4是表示活动信息的具体例的图。

图5是表示更新用软件信息的具体例的图。

图6是表示更新用软件的登记处理的处理顺序的一例的序列图。

图7是表示活动的创建处理的处理顺序的一例的序列图。

图8是表示失误可能性判定处理的处理顺序的一例的流程图。

图9是说明活动创建画面的一例的图。

图10是表示基于活动的更新用软件的发布处理的处理顺序的一例的序列图(之一)。

图11是表示基于活动的更新用软件的发布处理的处理顺序的一例的序列图(之二)。

图12是表示测试计划信息的具体例的图。

图13是表示测试计划的创建处理的处理顺序的一例的序列图。

图14是表示基于测试计划的更新用软件的发布处理的处理顺序的一例的序列图(之一)。

图15是表示基于测试计划的更新用软件的发布处理的处理顺序的一例的序列图(之二)。

图16是说明测试计划确认画面的一例的图。

附图标记说明

1 软件发布系统

10 远程信息处理中心(telematics center)

20 车辆

30 终端

40 网络

110 中央运算处理装置

111 车辆管理部

112 活动管理部

113 更新用软件发布部

114 测试计划管理部

120 存储装置

121 车辆DB

122 车辆结构DB

123 活动DB(campaign DB)

124 软件DB

125 测试计划DB

130 通信部

210 软件更新装置

211 中央运算处理装置

212 活动确认部

213 更新用软件请求部

214 ECU软件更新部

215 存储装置

216 定位装置

220 通信部

230 导航终端

231 中央运算处理装置

232 更新信息显示部

233 存储装置

234 输入输出装置

241 引擎ECU

242 自动驾驶ECU

310 中央运算处理装置

311 活动信息输入输出部

320 存储装置

330 输入输出装置

340 通信部

1000 活动创建画面

1100 测试计划确认画面

1210 车辆信息

1220 车辆结构信息

1230 活动信息

1240 更新用软件信息(软件信息)

1250 测试计划信息

具体实施方式

以下，参照附图详细叙述本发明的实施方式。

本说明中“活动(campaign)”是指，用于对于为了更新装载于车辆的车载设备(ECU)的相同功能而要发布的更新用软件，关联地管理作为发布目标的一个以上的车辆的信息的信息单位。

活动的用途多种多样，但存在用于以多个车辆为对象的更新用软件的整体性的发布的情况和用于以测试(验证)用途中限定的特定车辆(测试车辆)为对象的更新用软件的限定性的发布的情况。作为更新用软件的整体性的发布，有时对于量产工序或流通后的多个车辆，以功能提高、召回应对等为目的来发布更新用的更新用软件。例如，通过发布用于消除召回原因的更新用软件，并安装于对象的ECU，来进行功能的更新。另外，作为更新用软件的限定性的发布，有时对于设计开发阶段的特定车辆(测试车辆)，以功能确认、性能测定等为目的来发布测试用的更新用软件。例如，通过将测试用的更新用软件发布于测试车辆，并安装于对象的ECU，来进行在测试场地等进行的行驶测试用的软件设定。

在活动的软件发布中，通过指定了更新用软件的活动信息的登记来创建活动，基于所登记的活动信息向作为对象的车辆20发布更新用软件，并将其安装到ECU。在此，在活动的创建中，操作者(工程师或管理者等)需要指定更新用软件，有可能因版本信息的判断错误或操作失误的人为失误而选择错误的软件。因此，本实施方式的软件发布系统1的特征之一在于，通过进行后述的“失误可能性判定处理”，防止因上述那样的软件的选择而创建活动。

(1)第1实施方式

(1-1)软件发布系统1的结构

图1是表示本发明的一个实施方式的软件发布系统的结构例的图。图1所示的软件发布系统1是向车辆20发布软件的系统包括：作为软件发布服务器的远程信息处理中心10；装载有软件更新装置210和导航终端230的车辆20；和对远程信息处理中心10进行输入输出的终端30。

如图1所示，远程信息处理中心10经由通信部130连接于网络40，车辆20的软件更新装置210经由车辆20的通信部220连接于网络40，终端30经由通信部340连接于网络40。其结果，远程信息处理中心10、车辆20(软件更新装置210)、和终端30经由网络40连接成相互可通信。网络40能够通过例如移动电话网、因特网、无线LAN(Local Area Network)等近距离无线通信或它们的组合构成。

此外，图1中，仅表示一台车辆20，但本实施方式的结构不限定于此，各自装载有软件更新装置210和导航终端230的多台车辆20也能够是经由网络40与远程信息处理中心10和终端30连接成可通信的结构。另外，远程信息处理中心10和终端30也可以通过相同设备实现。

(1-1-1)远程信息处理中心10

远程信息处理中心10是软件发布服务器(例如云型服务器)，经由网络40从终端30接收软件发布指示，并对车辆20发布软件。远程信息处理中心10包括中央运算处理装置110、存储装置120和通信部130。

中央运算处理装置110由例如CPU(Central Processing Unit)和RAM(RandomAccess Memory)等构成，通过执行规定的程序，实现远程信息处理中心10的各功能。中央运算处理装置110作为这些功能以外的结构，包括车辆管理部111、活动管理部112、更新用软件发布部113、和测试计划管理部114。此外，测试计划管理部114是用于第2实施方式的结构，在第1实施方式中未必是必要的结构。

车辆管理部111管理保存于存储装置120的车辆DB121和车辆结构DB122的各信息，且根据需要进行各信息的登记、变更和删除。

活动管理部112管理保存于存储装置120的活动DB123的活动信息，在软件发布系统1的处理中进行各活动信息的登记、变更和删除。

更新用软件发布部113根据来自车辆20(更新用软件请求部213)的请求，将对车辆20来说适当的更新用软件从存储装置120的软件DB124取出，并经由通信部130和网络40向车辆20发布。

测试计划管理部114管理保存于存储装置120的测试计划DB125的测试计划信息，在软件发布系统1的处理中进行各测试计划信息的登记、变更和删除。测试计划信息在第2实施方式中详细叙述。

存储装置120由例如HDD(Hard Disk Drive)、SSD(Solid State Drive)、闪存、或ROM(Read Only Memory)等构成。存储装置120中，除了中央运算处理装置110执行的程序之外，还保存该程序的执行所需要的数据组等。

如图1所示，作为保存于存储装置120的数据组，存储装置120包括：车辆DB121、车辆结构DB122、活动DB123、软件DB124、和测试计划DB125等。此外，测试计划DB125是用于第2实施方式的结构，在第1实施方式中未必是必要的结构。

车辆DB121存储由对于一个以上的车辆20各自(各车辆20)可成为车型、使用状况、和软件发布时的制约条件的信息等构成的“车辆信息”。车辆信息的具体例在后述的图2中表示。

车辆结构DB122存储由对于各车辆20用于管理装载的ECU的种类、和安装的软件的版本的信息等构成的“车辆结构信息”。车辆结构信息的具体例在后述的图3中表示。

活动DB123存储由对车辆20进行的活动所需的信息构成的“活动信息”。活动信息由用于管理活动中成为软件的更新对象的ECU的种类、更新用软件的发布时的制约条件、和成为更新对象的车辆台数的信息等构成，其具体例在后述的图4中表示。

软件DB124存储通过活动向车辆20发布的更新用软件和其管理信息(更新用软件信息)。此外，本说明中为了简化，有时将“更新用软件信息”称为“软件信息”。

测试计划DB125存储由对测试用的特定车辆20(测试车辆)进行的测试计划所需的信息构成的“测试计划信息”。

通信部130由依据网络40中使用的通信标准的网卡等构成，经由网络40在与车辆20和终端30之间基于各种协议收发数据。网卡依据有线LAN等的有线通信或无线LAN等的无线通信，或其双方所需要的通信标准。

(1-1-2)车辆20

车辆20包括：软件更新装置210、通信部220、导航终端230、各种ECU(引擎ECU241，自动驾驶ECU242，…)。车辆20的各设备通过CAN(Controller Area Network)、Ethernet(注册商标)等车内网络连接。

软件更新装置210包括中央运算处理装置211、存储装置215和定位装置216。

中央运算处理装置211由例如CPU和RAM等构成，通过执行规定的程序，实现软件更新装置210的各功能。中央运算处理装置211作为这些功能以外的结构，包括活动确认部212、更新用软件请求部213、和ECU软件更新部214。

活动确认部212以车辆20的引擎起动为触发，对远程信息处理中心10进行查询，确认本车辆的ECU中是否没有实施软件更新的活动。

更新用软件请求部213在活动确认部212进行的确认的结果为具有以本车辆的ECU为对象的活动的情况下，对远程信息处理中心10请求该活动的更新用软件，并下载。

ECU软件更新部214使用更新用软件请求部213下载的更新用软件，并对更新对象的ECU进行更新。

存储装置215由例如HDD、SSD、闪存、或ROM等构成。存储装置215中，除了中央运算处理装置211执行的程序之外，保存该程序的执行所需要的数据组等。

定位装置216由例如GPS(Global Positioning System)传感器等构成，取得特定车辆20的当前位置的位置信息(纬度信息和经度信息)。

通信部220利用依据网络40中使用的通信标准的网卡等构成，经由网络40在与远程信息处理中心10和终端30之间基于各种协议收发数据。网卡依据例如无线LAN等的无线通信。

导航终端230利用具有在车辆20行驶时向当前位置或目的地进行路径导向的导航功能的一般的车辆导航装置或平板终端等构成。导航终端230包括中央运算处理装置231、存储装置233和输入输出装置234。

中央运算处理装置231由例如CPU和RAM等构成，通过执行规定的动作程序，实现导航终端230的导航功能。中央运算处理装置231作为其功能结构包括更新信息显示部232。更新信息显示部232将基于导航功能的显示画面或基于从远程信息处理中心10发送的更新用软件的信息的显示画面等显示于输入输出装置234。

存储装置233由例如HDD、SSD、闪存、或ROM等构成。存储装置233中，除了中央运算处理装置231执行的程序之外，还保存执行该程序所需要的数据组等。

输入输出装置234通过组合触摸面板、键盘、或鼠标等而构成，作为对于导航终端230和软件更新装置210的输入部和输出部(显示部)发挥作用。

此外，本实施方式的车辆20中，软件更新装置210和导航终端230也可以由相同设备实现。另外，导航终端230不限定于装载于车辆20的结构，例如，也可以代替导航终端230，而使用发挥与导航终端230同样功能的智能手机或平板等的便携终端。在该情况下，认为通过将通信部220配置于可与便携终端通信的附近，软件更新装置210使用例如OBD(On BoardDiagnostics)等的连接器，而软件更新装置210与便携终端进行通信。

引擎ECU241是管理车辆20的引擎动作的ECU。自动驾驶ECU242是管理车辆20的自动驾驶的动作控制的ECU。如图1所示，这些ECU连接于总线型CAN网络，软件更新装置210具有这些总线型网络的总线功能。

此外，图1中，作为软件发布系统1中成为更新用软件的发布对象的车辆20的车载设备的一例，表示引擎ECU241和自动驾驶ECU242，但装载于车辆20的各种ECU不限于此。例如，也可以装载悬架控制用的ECU、或电子镜控制用的ECU等、具有辅助车辆20的控制和安全的功能的ECU。此外，这些ECU中分别内置有用于使本身动作的软件。该软件分别保存于各ECU具有的存储装置(未图示)，并由各ECU具有的中央运算处理装置(未图示)执行。本实施方式的软件发布服务器(远程信息处理中心10)发布以这些ECU为更新对象的更新用软件。

(1-1-3)终端30

终端30是通用的计算机、或平板或智能手机等的便携终端等，包括：中央运算处理装置310、存储装置320、输入输出装置330和通信部340。

中央运算处理装置310由例如CPU和RAM等构成，通过执行规定的动作程序，实现终端30的功能。中央运算处理装置310作为其功能结构，包括活动信息输入输出部311。

活动信息输入输出部311根据用户的输入输出装置330的操作，向远程信息处理中心10发送相当于活动信息的信息等。另外，活动信息输入输出部311将从远程信息处理中心10接收的信息显示于输入输出装置330。

存储装置320由例如HDD、SSD、闪存、或ROM等构成。存储装置320中，除了中央运算处理装置211执行的程序之外，保存该程序的执行所需要的数据组等。

输入输出装置330通过组合触摸面板、键盘、或鼠标等而构成，作为对于终端30和远程信息处理中心10的输入部和输出部(显示部)发挥作用。

通信部340由依据网络40中使用的通信标准的网卡等构成，经由网络40在与远程信息处理中心10之间基于各种协议收发数据。网卡依据例如无线LAN等的无线通信。

此外，如上所述，终端30也可以由与远程信息处理中心10相同的设备实现，例如在远程信息处理中心10包含终端30的功能而构成的情况下，只要远程信息处理中心10包括相当于终端30的输入输出装置330的输入输出装置，且中央运算处理装置110包括活动信息输入输出部311即可。

(1-2)各种数据的结构

以下，对于图1所示的远程信息处理中心10的存储装置120中保存于DB的各种数据的结构，举出具体例进行说明。但是，保存于测试计划DB125的测试计划信息1250在第2实施方式中说明。此外，本具体例中，以表形式表示数据结构，但本实施方式的各种数据的结构不限定于此。

图2是表示车辆信息的具体例的图。车辆信息是关于各车辆20的车辆主体的元信息，保存于车辆DB121。图2所示的车辆信息1210是包括VIN1211、车型ID1212、位置1213、和更新日期时刻1214而构成的表形式的数据。

VIN1211是能够唯一地确定车辆20的识别符(VIN：Vehicle IdentificationNumber)。车型ID1212是能够唯一地确定由VIN1211确定的车辆20(该记录中的对象车辆20)的车型的识别符。位置1213是对象车辆20最后成为引擎OFF时的位置信息，以纬度、经度的顺序记载。而且，更新日期时刻1214是表示车辆信息1210的该记录被更新的日期时刻的信息。

图3是表示车辆结构信息的具体例的图。车辆结构信息是关于各车辆20具有的ECU的信息，保存于车辆结构DB122。图3所示的车辆结构信息1220是包括VIN1221、ECU-ID1222、串行ID1223、软件版本1224、和更新日期时刻1225而构成的表形式的数据。

VIN1221是与车辆信息1210的VIN1211共通的数据，是能够唯一地确定对象车辆20的识别符。

ECU-ID1222是能够唯一地确定装载于对象车辆20的ECU的种类的识别符。另外，串行ID1223是能够唯一地确定装载于对象车辆20的ECU的识别符。例如，如比较图3的数据行的第一行和第三行可知那样，即使ECU的种类(ECU-ID1222)相同，各自的ECU的串行ID(Serial ID，序列号)1223也不同。

另外，软件版本1224是能够唯一地确定安装于由该记录确定的ECU(装载于对象车辆20的特定的ECU)的软件的识别符。而且，更新日期时刻1225是表示更新了车辆结构信息1220的该记录的日期时刻的信息。

图4是表示活动信息的具体例的图。如上所述，活动信息由活动所需的信息构成，保存于活动DB123。图4所示的活动信息1230是包括活动ID1231、VIN1232、ECU-ID1233、软件ID1234、状态1235、和更新日期时刻1236而构成的表形式的数据。

活动ID1231是能够唯一地确定活动信息的识别符。

VIN1232是与车辆信息1210的VIN1211和车辆结构信息1220的VIN1221共通的数据，是该记录的活动时用于确定要发布软件的车辆20的信息。

ECU-ID1233是与车辆结构信息1220的ECU-ID1222共通的数据，是表示该记录的活动中设为软件的更新对象的ECU的种类(ECU-ID)的信息。

软件ID1234是用于识别该记录的活动中要发布的更新用软件的识别符。软件ID1234对应于图5中示例的更新用软件信息1240的软件ID1241。

状态1235是对于该记录的活动表示由VIN1232特定车辆20的处理状况(进展状况)的信息，更新日期时刻1236是表示该记录被更新的日期时刻的信息。

具体而言，例如，如图4的数据行的第一行那样，状态1235为“更新完成”的情况是指，对象的车辆20(VIN“9GJH”)的对象ECU(ECU-ID“Engine_MY15”)中更新用软件(软件ID“APA_ver13”)的安装完成。此时，在更新日期时刻1236中记录确认到“更新完成”的日期时刻(也可以是安装完成的日期时刻)。

另外例如，如图4的数据行的第2行那样，状态1235为“下载完成”的情况是指，对象的车辆20(VIN“7RTM”)的对象ECU(ECU-ID“Steer_16JP”)中更新用软件(软件ID“B73H_v5”)的下载完成，但安装未完成。此时，在更新日期时刻1236中记录确认到“下载完成”的日期时刻(也可以是下载完成的日期时刻)。

另外，例如，如图4的数据行的第3行那样，状态1235为“安装中”的情况是指，对象的车辆20(VIN“6ABC”)的对象ECU(ECU-ID“Engine_MY14EU”)中更新用软件(软件ID“CC8Y_v2”)的下载完成且为安装的中途。此时，在更新日期时刻1236中记录确认到安装开始的日期时刻(也可以是安装开始的日期时刻)。

图5是表示更新用软件信息的具体例的图。更新用软件信息(软件信息)是要向车辆20发布的更新用软件的管理信息，与该软件一起保存于软件DB124。图5所示的更新用软件信息(软件信息)1240是包括软件ID1241、文件名1242、更新类型1243、前版本1244、后版本1245、文件大小1246、和更新日期时刻1247而构成的表形式的数据。

软件ID1241是能够唯一地确定更新用软件的识别符，是与图4中示例的活动信息1230的软件ID1234共通的数据。

文件名1242是通过该记录管理的更新用软件的文件名。另外，更新类型1243是该更新用软件的更新种类。例如，更新类型1243为“差量”的情况是指，该更新用软件是来自前版本的差量文件。更新类型1243为“完整”的情况是指，该更新用软件不是差量文件，是完全文件(完整文件)。

前版本1244是该记录中管理的更新用软件的前一个版本名称，后版本1245是后一个版本名称。前版本1244或后版本1245为“null”的情况是指，不存在前一个版本或后一个版本。文件大小1246是该记录中管理的更新用软件的文件大小，图5中例如以千字节(kB)的单位记载。而且，更新日期时刻1247是表示更新更新用软件信息1240的该记录的日期时刻的信息。

以上，举出具体例说明图1所示的远程信息处理中心10的存储装置120中保存于DB的各种数据的结构。这些具体例在以后的说明中也适用。

(1-3)活动的处理

接着，对与本实施方式的软件发布系统1进行的活动的创建和执行相关的处理进行说明。

(1-3-1)更新用软件的登记

图6是表示更新用软件的登记处理的处理顺序的一例的序列图。图6所示的处理是用于将通过活动发布的更新用软件向软件DB124登记(存储)的处理。

首先，由工程师或管理者等操作终端30的输入输出装置330，进行请求更新用软件的登记的操作。此时，输入登记对象的更新用软件和关于该软件的管理信息(相当于软件信息1240的信息)。输入的信息也可以存储于例如存储装置320。

而且，步骤S101中，终端30的活动信息输入输出部311将上述操作中指定的更新用软件的登记委托于远程信息处理中心10。此时，也发送该更新用软件和管理信息。

在接收了步骤S101的委托的远程信息处理中心10，活动管理部112(或车辆管理部111)将接收的管理信息作为更新用软件的软件信息1240保存于软件DB124(步骤S111)。此时，接收到的更新用软件也保存于软件DB124。此外，步骤S111中由于一些原因判定为不是接收更新用软件的登记的状况的情况下，不进行更新用软件和软件信息的登记，并将该情况设为登记结果。然后，在步骤S112中，活动管理部112(或车辆管理部111)将步骤S111中执行的更新用软件信息1240的登记结果发送至终端30。

当接收步骤S112中发送的登记结果时，终端30的活动信息输入输出部311将其登记结果显示于输入输出装置330(步骤S102)。由此，工程师或管理者等能够确认更新用软件的登记结果。

(1-3-2)活动的创建

图7是表示活动的创建处理的处理顺序的一例的序列图。图7所示的处理是用于通过登记活动信息来创建新的活动(以后，也称为新活动)的处理。

此外，图7中，将委托活动的创建的终端设为车辆20的导航终端230，但本实施方式的软件发布系统1中，也能够以也能够从终端30委托创建活动的方式构成。在该情况下，只要代替图7所示的更新信息显示部232，终端30的活动信息输入输出部311进行同样的处理即可。作为具体预想的情况，例如，作为从车辆20委托活动的创建的情况的具体例，举出以下情况，在设计开发阶段的测试中，以特定车辆20(测试车辆)为对象，工程师等在测试现场直接创建活动。另外，作为从终端30委托活动的创建的情况的具体例，举出以下情况，以多个车辆20为对象创建进行更新用程序的整体性的发布的活动。

根据图7，首先，在步骤S201中，更新信息显示部232根据工程师进行的导航终端230的输入输出装置234的操作，对软件信息1240、活动信息1230、和过去的更新历史(软件的更新历史和活动的发布历史等)，查询远程信息处理中心10。

在接收到步骤S201的查询的远程信息处理中心10，车辆管理部111和活动管理部112与查询相应地检索信息并提取(步骤S211)。具体而言，例如，车辆管理部111检索、提取关于要查询的车辆20的信息，或活动管理部112从软件DB124或活动DB123检索、提取软件信息1240或活动信息1230等。然后，在步骤S212中，车辆管理部111和活动管理部112将步骤S211中提取出的检索结果发送至导航终端230。

当接收到步骤S212中发送来的检索结果时，更新信息显示部232将该检索结果显示于输入输出装置234(步骤S202)。通过确认该显示，能够掌握过去的活动等历史。

接着，工程师对于显示于更新信息显示部232的规定的画面(活动创建画面)，输入(指定)创建新活动所需的规定信息。活动创建画面也可以是在图9中表示具体例，但在步骤S202中沿用显示于更新信息显示部232的画面的活动创建画面。然后，接收上述的输入操作，更新信息显示部232向远程信息处理中心10委托新活动的创建(步骤S203)。

远程信息处理中心10当接收步骤S203的新活动的创建委托时(步骤S213)，活动管理部112对于新活动中要发布的更新用软件执行判定软件的选择失误的可能性的“失误可能性判定处理”(步骤S214)。

详情参照图8后述，在失误可能性判定处理中，在判定为存在弄错软件选择的可能性的情况下，不创建新活动而准备警告消息。另一方面，在判定为没有弄错软件选择的可能性的情况下，创建(创建、登记活动信息1230)新活动。而且，步骤S215中，活动管理部112将基于步骤S214的失误可能性判定处理的判定结果的新活动的创建结果发送至导航终端230(步骤S215)。

当接收到步骤S215中发送来的创建结果时，更新信息显示部232将该创建结果显示于输入输出装置234(活动创建画面)(步骤S204)。详细而言，在失误可能性判定处理中判定为存在弄错软件选择的可能性的情况下(经由步骤S227)，显示指出软件的选择失误的可能性的警告消息，再次确认是否真的要创建新活动。另一方面，在失误可能性判定处理中判定为没有弄错软件选择的可能性的情况下(经由步骤S228)，显示表示在步骤S203中委托的新活动的创建完成了的意思。当新活动的创建完成时，在远程信息处理中心10中，该活动的更新用软件的发布准备就绪。

图8是表示失误可能性判定处理的处理顺序的一例的流程图。如图7的步骤S214中叙述那样，失误可能性判定处理由活动管理部112执行。

根据图8，首先，活动管理部112从存储于活动DB123的活动信息1230检索具有与来自更新信息显示部232的创建委托(图7的步骤S203)中指定的VIN和ECU-ID相同的值的记录，并提取符合的记录(步骤S221)。即，步骤S221中提取的记录是对于新活动中成为更新用软件的发布对象的车辆的ECU，以该ECU为对象进行执行的过去的活动信息1230。

接着，活动管理部112将步骤S221中提取出的记录基于更新日期时刻1236降序排序，并提取由最近N次(N为2以上的任意整数)的记录构成的活动历史(步骤S222)。

接着，活动管理部112计算步骤S222中提取出的活动历史所包含的各活动中的软件的更新量(步骤S223)。详细而言，从软件DB124提取与活动信息1230的软件ID1234对应的软件信息1240，并参照该文件大小1246(差量大小)，由此能够计算软件的更新量。然后，活动管理部112基于步骤S223中计算出的最近N次的活动历史中的软件的更新量，计算其平均值A(步骤S234)。

接着，活动管理部112计算将最后的活动(最新的活动历史)中发布的软件更新成本次指定的新活动中发布预定的更新用软件时的软件的更新量D(步骤S225)。

然后，活动管理部112使用步骤S224中计算出的平均值A和步骤S225中计算出的更新量D，判定“2A＜D”的关系是否成立(步骤S226)。在步骤S226中为“2A＜D”的情况下(步骤S226的YES)，进入步骤S227，在为“2A≥D”的情况下(步骤S226的NO)，进入步骤S228。此外，步骤S226中的“2A＜D”的判定条件是与现有的(最近N次的活动中的)软件的平均的更新量比较时，用于判定创建预定的新活动中指定的软件的更新量是否为显著不同的更新量(是否大幅偏离)的指标的一例，也可以使用基于其意旨的其它指标。

在步骤S227中，新活动中指定的软件的更新量与现有的软件的更新量大幅不同，所以活动管理部112判定为具有弄错软件选择的可能性，不创建关于委托的新活动的活动信息1230而准备指出软件的选择失误的可能性的规定的警告消息。

另一方面，在步骤S228中，创建预定的活动中指定的软件的更新量与现有的软件的更新量相比没有特别突出的差异，所以活动管理部112判定为没有弄错软件选择的可能性，创建关于委托的新活动的活动信息1230并登记于活动DB123。

根据步骤S227或S228的处理，失误可能性判定处理结束，之后，如上述那样进行图7的步骤S215以后的处理。

此外，在图8所示的失误可能性判定处理中，在软件的更新量的计算中，利用该软件的更新用文件的文件大小，但其为一例，也能够利用文件大小以外的信息计算软件的更新量。作为利用文件大小以外的信息的软件的更新量的计算方法，例如，可举出：基于更新用文件中的源代码的行数的差量计算的方法、基于更新用文件以二进制形式提供时的(或，将更新用文件看着二进制文件时)的差量比特计算的方法、或基于将更新用文件写入ECU时更新的ROM的块数来计算的方法等。另外，也可以组合这些多个信息计算软件的更新量。

总之，本实施方式的失误可能性判定处理只要是比较过去N次的软件更新量的统计信息和本次的软件更新量，在满足规定条件的情况下，判定为具有失误引起的软件的选择失误的可能性的处理即可，只要在该情况下保留或拒绝本次的软件的登记(活动的创建)，并准备警告消息即可。另外，用于上述判定的“规定条件”也是只要是判断为在过去N次的软件更新量的统计信息与本次的软件更新量之间具有较大的偏离的条件或阈值，就不限定于特定的条件式等。

图9是说明活动创建画面的一例的图。如图9所示，活动创建画面1000显示于输入输出装置234。

图9所示例的活动创建画面1000中，在上部的显示区域1001中，新活动(活动ID“T45M012”)的详细的信息以树形式可视化。显示于显示区域1001的活动ID、ECU-ID、和软件ID与活动信息1230的构成信息对应。另外，显示于显示区域1001的“文件名”以下的信息与对应于上述软件ID(软件ID“APA_ver13”)的软件信息1240的构成信息对应。

另外，活动创建画面1000中，在显示区域1001的下方配置有操作者(工程师或管理者等)可选择的按钮1002。按钮1002如显示为“创建活动”那样，在委托利用显示于显示区域1001的信息创建活动时选择。

在活动创建画面1000中，在显示区域1001中输入新活动(本次的活动)所需的信息，当通过按钮1002的选择委托该活动的创建时，经由上述的失误可能性判定处理(图7的步骤S214)，该创建结果显示于下部的显示区域1003。

显示区域1003是对于创建委托的新活动(本次的活动)中指定的软件，视觉显示过去的活动中的与软件更新的比较结果的区域。图9中，作为判定为失误可能性判定处理中具有弄错软件选择的可能性时的一个显示例，在显示区域1003中显示过去的活动中的软件的变更量(更新量)、和本次的新活动中指定的软件的变更量的图像。

在此，如图8的步骤S706的NO～步骤S227中进行的说明那样，在判定为本次的活动中指定的软件的更新量(图中的“本次”)与现有的软件的更新量(图中的“上一次”或“上上次”等)大幅不同的情况下，在显示区域1003中显示指出软件的选择失误的可能性的规定的警告消息。图9中作为具体例，表示有“＜注意＞本次软件更新与此前相比变更量变多。真的要创建活动？”的警告消息。

然后，活动创建画面1000中，在显示区域1003的下方配置有操作者(工程师或管理者等)可选择的按钮1004、1005。按钮1004、1005是用于在显示区域1003中显示了警告消息的情况下由操作者决定对策而操作。

更具体而言，在对于指出软件的选择失误的可能性的显示区域1003的警告消息，操作者判断为不是选择失误(要在活动中发布所指定的更新用软件)的情况下，通过选择显示“是”的按钮1004，最终决定以当前的输入内容中创建活动。该情况的处理未显示于图7中，但例如从更新信息显示部232对于远程信息处理中心10重新指示活动的创建，远程信息处理中心10的活动管理部112创建该活动的活动信息1230并保存于活动DB123。这样，即使在指定了想要的更新用软件的情况下，在更新量比过去的历史大幅偏离时显示警告消息并要求选择按钮1004，由此能够再次确认不是操作失误。

另外，在对于指出软件的选择失误的可能性的显示区域1003的警告消息，操作者判断为是选择失误(不是要在活动中发布的更新用软件)的情况下，通过选择显示为“否”的按钮1004，最终决定不以当前的输入内容创建活动。该情况的处理未显示于图7中，但例如通过操作者在在显示区域1001中重新输入适当的更新用软件之后选择按钮1002，从更新信息显示部232对于远程信息处理中心10进行修正后的新活动的创建委托(也可以考虑返回图7的步骤S203)。

以上，如参照图7～图9进行的说明，在本实施方式的软件发布系统1中，只要在对于新活动的创建委托，判定为没有更新用软件的选择失误的可能性的情况下，创建、登记活动信息1230，并创建该活动。另一方面，在判定为具有更新用软件的选择失误的可能性的情况下，通过在活动创建画面1000中显示警告消息(显示区域1003)，能够确认、探讨指定的软件是否有错误。通过这样，能够防止因人为的选择失误而在活动中发布错误的更新用软件。

(1-3-3)更新用软件的发布

图10和图11是表示基于活动的更新用软件的发布处理的处理顺序的一例的序列图(之一，之二)。图10中表示车辆20从远程信息处理中心10下载更新用软件的处理，图11中表示图10所示的下载后，车辆20将更新用软件安装于对象ECU，并将该结果通知给远程信息处理中心10的处理。

首先，参照图10说明基于创建完成的活动的更新用软件的下载处理。图10所示的处理由装载于车辆20的软件更新装置210的活动确认部212和更新用软件请求部213、以及装载于远程信息处理中心10的中央运算处理装置110的活动管理部112和更新用软件发布部113执行。

根据图10，首先，车辆20的活动确认部212使用从引擎ECU241得到的信息检测引擎起动(ON状态)(步骤S301)。当步骤S301中检测到引擎起动时，活动确认部212向远程信息处理中心10查询关于该车辆20的VIN(车辆信息1210的VIN1211)有无活动(步骤S302)。

在接收到步骤S302的查询的远程信息处理中心10，活动管理部112检索保存于活动DB123的活动信息1230，并确认是否存在VIN1232与发送方的车辆20的VIN一致的记录，由此检索有无活动(步骤S311)。然后，活动管理部112将步骤S311的确认结果(检索结果)发送至车辆20(步骤S312)。详细而言，在步骤S311中存在与发送方的车辆20的VIN一致的记录的情况下，该记录的活动信息1230作为检索结果发送，在步骤S311中不存在一致的记录的情况下，发送表示没有活动的意思的检索结果。

在接收到来自远程信息处理中心10的检索结果的车辆20中(步骤S303)，活动确认部212根据检索结果确认有无活动(步骤S304)。具体而言例如，确认在检索结果中是否包含活动信息1230。在检索结果中不包含活动信息1230的情况下，判断为没有活动(步骤S304的NO)，由于此时也不存在要下载的更新用软件，所以结束处理。另一方面，在检索结果中包含活动信息1230的情况下，判断为有活动(步骤S304的YES)，更新用软件请求部213向远程信息处理中心10请求提供由该活动信息1230的软件ID1234确定的更新用软件(步骤S305)。此外，以下的说明中，将从检索结果看到的活动称为“执行活动”。

远程信息处理中心10当接收步骤S305的请求时(步骤S313)，更新用软件发布部113基于指定的软件ID1234，从软件DB124提取请求的更新用软件(即，执行活动的更新用软件)，并发送至车辆20(步骤S314)。

步骤S314中发送的更新用软件由车辆20接收并开始下载(步骤S306)，下载数据存储于存储装置215(步骤S307)。然后，当更新用软件的下载完成时，活动确认部212将下载完成通知给远程信息处理中心10(步骤S308)。

远程信息处理中心10当接收(收到)步骤S308的下载完成通知时，活动管理部112对于执行活动的活动信息1230将状态1235更新为“下载完成”，并覆盖写于活动DB123(步骤S315)。然后，活动管理部112将步骤S314中发送的更新用软件的安装的开始命令发送至车辆20(步骤S316)。

然后，当接收(收到)步骤S316的安装开始命令时(步骤S309)，车辆20的活动确认部212直到引擎成为停止状态(OFF状态)为止，转移到待机更新用软件的安装开始的待机状态。活动确认部212能够使用从引擎ECU241得到的信息来检测引擎停止。引擎停止之后的处理在图11中表示。

接着，参照图11说明基于活动的更新用软件的安装处理。图11所示的处理由装载于车辆20的软件更新装置210的活动确认部212和ECU软件更新部214、和装载于远程信息处理中心10的中央运算处理装置110的活动管理部112执行。

根据图11，首先，车辆20的活动确认部212使用从引擎ECU241得到的信息检测引擎停止(OFF状态)(步骤S401)。在步骤S401中检测引擎停止时，活动确认部212确认是否存在执行中的活动(执行活动)(步骤S402)。具体而言只要例如活动确认部212虽然收到安装开始命令(图10的步骤S309)，但在安装之前确认有无未完成的更新用软件即可。

在通过步骤S402的确认不存在执行活动的情况下(步骤S402的NO)，由于也不存在要安装的更新用软件，所以结束处理。另一方面，在通过步骤S402的确认存在执行活动的情况下(步骤S402的YES)，活动确认部212将执行活动的更新用软件(经由图10的处理，下载完成)开始安装到对象ECU通知给远程信息处理中心10(步骤S403)。此外，成为更新用软件的安装目标的对象ECU能够由执行活动的活动信息1230的ECU-ID1233确定。

远程信息处理中心10接收到步骤S403的安装开始通知，活动管理部112对于执行活动的活动信息1230将状态1235更新为“安装中”，并覆盖写于活动DB123(步骤S411)。

另外，在发送了安装开始通知的车辆20中，ECU软件更新部214执行对象ECU的软件安装，并覆盖写该ECU的存储装置(步骤S404)。然后，ECU软件更新部214从对象ECU接收安装结果(更新的成否信息)，并将接收的更新的成否信息通知给远程信息处理中心10(步骤S405)。

然后，远程信息处理中心10接收到步骤S405的通知，活动管理部112对于执行活动的活动信息1230将状态1235更新为“更新完成”，且覆盖写于活动DB123(步骤S412)。

如上所述，通过图10和图11所示的处理正常进行，本实施方式的软件发布系统1中，活动的更新用软件的发布(下载和安装)完成，由此，活动的执行完成。

(2)第2实施方式

如上所述，活动的用途之一中具有以测试的测试车辆为对象的更新用软件的限定性的发布。该测试中，主要是若是设计开发阶段的试用阶段的测试，则较少通过1次的软件的更新完成测试，大多伴随多次的软件更新执行一连串的测试。具体而言例如，在测试场地中，一边依次更新对于测试车辆的相同的ECU不同的版本的软件，一边进行测试行驶，验证该行驶性能的变化。

当将这种一连串的测试视作一个测试计划时，一个测试计划中不同的更新用软件的发布执行多次，所以创建多个活动，需要与测试计划进行相应地依次执行活动。另外，有时也测试的执行顺序(测试序号)和测试的开始位置等也被决定，所以用于管理测试计划的信息中需要比第1实施方式中说明的活动信息更详细的信息。

鉴于以上的背景，第2实施方式中，不仅要能够与第1实施方式同样，对于整个活动防止操作失误导致的错误的更新用软件的登记，而且要能够使用活动信息派生出的测试计划信息来管理上述测试计划。

此外，第2实施方式与第1实施方式同样，使用图1中示例的软件发布系统1进行说明。另外，只要没有特别的记载，保存于各DB的信息的结构和活动的处理等均与第1实施方式相同。而且，有时对与第1实施方式相同的部分省略该说明。

(2-1)测试计划信息的结构

图12是表示测试计划信息的具体例的图。测试计划信息由设计开发阶段等的测试计划中特有的详细的信息构成，并保存于测试计划DB125中。测试计划信息能够视为活动信息的派生，但第1实施方式中具有比图4中示例的活动信息1230更详细的项目。

图12中示例的测试计划信息1250是包括测试计划ID1251、测试序号1252、状态1253、测试开始日期时刻1254、测试结束日期时刻1255、测试车辆VIN1256、ECU-ID1257、软件ID1258、测试开始位置1259、和更新日期时刻1260而构成的表形式的数据。

测试计划ID1251是能够唯一地确定测试计划的识别符，派生出活动ID。此外，本例中，为了能够与活动信息1230的活动ID1231区别，测试计划ID1251中包含“Trial”的字符串。例如，图12的数据行的第一行中，作为测试计划ID1251记载有“T45M012Trial”，但该ID是指与以活动ID“T45M012”表示的活动(参照图4的数据行的第一行)对应的测试计划的ID。

测试序号1252是表示测试计划(相同的测试计划ID)中包含各个测试的执行顺序的信息。

状态1253是表示该记录所示的测试的处理状况(进展状况)的信息，例如以“完成”或“未发布”记载。

测试开始日期时刻1254是表示该记录所示的测试的执行开始日期时刻的信息，测试结束日期时刻1255是表示该执行结束日期时刻的信息。也可以在测试开始日期时刻1254和测试结束日期时刻1255记载预定的信息。另外，也可以最初记载预定的信息，且执行测试时以实际的执行日期时刻进行更新。

测试车辆VIN1256是用于确定该记录所示的测试中成为更新用软件的发布对象的车辆20的信息，是与目前为止说明的各种信息的VIN共通的数据。此外，本例中，为了简单，限定1台测试车辆(根据图12，测试车辆VIN“9GJH”)进行说明，但实际上也可以记载多台测试车辆。

ECU-ID1257是用于确定该记录所示的测试中设为软件的更新对象的ECU的种类的信息，是与目前为止说明的各种信息的ECU-ID共通的数据。

软件ID1258是用于确定该记录所示的测试中发布的更新用软件的信息，是与图5的软件信息1240的软件ID1241共通的数据。软件ID1258中记载能够将更新用软件识别至版本单位的识别符。

测试开始位置1259是表示该记录所示的测试中开始测试时的对象车辆的位置的信息，例如，记载测试场地的维修区(pit)的坐标等。测试开始位置1259还具有允许要在该测试中发布的更新用软件安装到ECU的位置的意思。

然后，更新日期时刻1260是表示测试计划信息1250的该记录被(最后)更新了的日期时刻的信息。

(2-2)测试计划的处理

接着，对与本实施方式的软件发布系统1进行的测试计划的创建和执行相关的处理进行说明。

此外，测试计划中发布的更新用软件通过适用第1实施方式中参照图6说明的更新用软件的登记处理，而登记于软件DB124。具体而言，只要测试计划管理部114执行图6中的活动管理部112的处理即可。

(2-2-1)测试计划的创建

图13是表示测试计划的创建处理的处理顺序的一例的序列图。图13所示的处理是通过登记测试计划信息而创建新的测试计划的处理。

此外，图13中，以委托测试计划的创建的终端为终端30，但本实施方式中，也可以置换成车辆20的导航终端230。在该情况下，只要代替图13所示的活动信息输入输出部311，而导航终端230的更新信息显示部232进行同样的处理即可。

根据图13，首先，由制定测试计划的工程师等操作终端30的输入输出装置330，向要登记的测试计划输入必要的详细信息(相当于测试计划信息1250的信息)。具体例省略，也可以在输入输出装置330中显示第1实施方式中说明的活动创建画面(参照图9)那样的规定的测试计划创建画面。

然后，在步骤S501中，接收上述的输入操作，终端30的活动信息输入输出部311向远程信息处理中心10委托新的测试计划的创建。此时，上述输入操作中输入的测试计划的详细信息发送至远程信息处理中心10。

在接收到步骤S501的委托的远程信息处理中心10，活动管理部112(或车辆管理部111)将接收到的测试计划的详细信息作为测试计划信息1250保存于测试计划DB125，由此登记委托的测试计划信息(步骤S511)。然后，在步骤S512中，活动管理部112(或车辆管理部111)将步骤S511中执行了的测试计划信息1250的登记结果(即，测试计划的创建结果)发送至终端30。

其中，在上述的步骤S511中，优选在确认了委托登记的测试计划信息中没有缺陷之后，登记测试计划信息1250。具体而言例如，确认指定的测试车辆VIN、ECU-ID、与软件ID对应的信息是否保存于存储装置120的DB。然后，在确认的结果为没有保存该信息的情况下，在步骤S511中进行测试计划信息1250的登记，在步骤S512中发送没有创建测试计划的意思的创建结果。

另外，活动管理部112也能够在委托测试计划信息的登记时，与第1实施方式的活动信息的登记委托时同样，进行失误可能性判定处理(参照图7和图8)，判定由本次的测试计划信息指定的更新用软件的更新量是否从过去的测试计划中的更新用软件的更新量大幅偏离。补充说一下，可以将图8的“活动”替代称为“测试计划”。此时，在通过失误可能性判定判定为本次的测试计划中指定的更新用软件的更新量与过去历史相比大幅偏离的情况下(相当于图8的步骤S226的YES)，不登记(创建测试计划)测试计划信息而准备警告消息，在步骤S512中作为创建结果发送。通过这样进行失误可能性判定处理，在测试计划的创建中也能够期待软件的选择失误的防止效果。

然后，当接收到步骤S512中发送的测试计划的创建结果时，终端30的活动信息输入输出部311将该创建结果显示于输入输出装置330(步骤S502)。由此，工程师等操作者能够确认委托的测试计划的创建结果。

(2-2-2)更新用软件的发布

图14和图15是表示基于测试计划的更新用软件的发布处理的处理顺序的一例的序列图(之一、之二)。图14中表示，测试中使用的车辆20(测试车辆)从远程信息处理中心10下载更新用软件的处理，图15中表示图14所示的下载之后，车辆20(测试车辆)将更新用软件安装于对象ECU，并将其结果通知给远程信息处理中心10的处理。另外，图16是说明测试计划确认画面的一例的图。

首先，参照图14说明创建完成的测试计划进行的更新用软件的下载处理。图14所示的处理由装载于车辆20的软件更新装置210的活动确认部212和更新用软件请求部213、以及装载于远程信息处理中心10的中央运算处理装置110的更新用软件发布部113和测试计划管理部114执行。

根据图14，首先，车辆20的活动确认部212使用从引擎ECU241得到的信息检测引擎起动(步骤S601)。在步骤S601中检测到引擎起动时，活动确认部212确认从远程信息处理中心10接收测试计划是否完成(步骤S602)。

在步骤S602中未接收测试计划的情况下(步骤S602的YES)，活动确认部212向远程信息处理中心10查询以本车辆20为对象的测试计划的有无(步骤S603)。另一方面，在步骤S602中完成接收测试计划的情况下(步骤S602的NO)，省略步骤S603和S604的处理，进入步骤S605。

在接收到步骤S603的查询的远程信息处理中心10，测试计划管理部114检索保存于测试计划DB125的测试计划信息1250，并确认是否存在测试车辆VIN1256与发送方的车辆20的VIN一致的记录，由此，检索测试计划的有无(步骤S611)。然后，测试计划管理部114将步骤S611的确认结果(检索结果)发送到车辆20(步骤S612)。详细而言，在步骤S611中存在与发送方的车辆20的VIN一致的记录的情况下，该记录的测试计划信息1250作为检索结果发送，在步骤S611中不不存在一致的记录的情况下，发送表示没有测试计划的意思的检索结果。

在接收到来自远程信息处理中心10的检索结果的车辆20中(步骤S604)，活动确认部212根据检索结果确认下一测试序号的有无(步骤S605)。具体而言，参照接收完成的测试计划信息1250(包含步骤S604中接收的信息)的测试序号1252和状态1253，在存在成为状态“未发布”的测试序号的情况下，判断为具有下一测试序号(步骤S605的YES)，进入步骤S606。其中，在下一测试序号的判断中，记载于测试开始日期时刻1254的日期时刻是否接近等也可以设为判断要素。另一方面，在不存在成为状态“未发布”的测试序号、或者接收完成的测试计划信息1250本身不存在的情况下，判断为没有下一测试序号(步骤S605的NO)，此时不进行测试计划的更新用软件的发布，所以结束处理。

在步骤S606中，更新用软件请求部213向远程信息处理中心10请求提供从与下一测试序号对应的测试计划信息1250的记录中的软件ID1258确定的更新用软件(步骤S606)。此外，以下的说明中，将上述接收完成的测试计划称为“执行测试计划”。

远程信息处理中心10当接收到步骤S606的请求时(步骤S613)，更新用软件发布部113基于指定的软件ID1258，从软件DB124提取请求的更新用软件(即，执行测试计划的更新用软件)，并发送至车辆20(步骤S614)。

在步骤S614中发送的更新用软件由车辆20接收并开始下载(步骤S607)，下载数据存储于存储装置215(步骤S608)。然后，当更新用软件的下载完成时，活动确认部212将下载完成通知给远程信息处理中心10(步骤S609)。

远程信息处理中心10当接收(收到)步骤S609的下载完成通知时，测试计划管理部114对于执行测试计划的测试计划信息1250将状态1253更新为“下载完成”，并覆盖写于测试计划DB125(步骤S615)。然后，测试计划管理部114将步骤S614中发送的更新用软件的安装的开始命令发送至车辆20(步骤S616)。

然后，当接收(收到)步骤S616的安装开始命令时(步骤S610)，车辆20的活动确认部212直到引擎成为停止状态(OFF状态)为止，转移到待机更新用软件的安装开始的待机状态。活动确认部212能够使用从引擎ECU241得到的信息来检测引擎停止。引擎停止之后的处理在图15中表示。

此外，上述的说明中，更新用软件的发布(下载)在各测试序号之前分别进行，但作为处理的其它例，也可以以测试计划单位执行更新用软件的发布(下载)。

在该情况下，图14的处理在步骤S605中不如上述那样判断下一测试序号的有无，而判断步骤S604中是否接收到测试计划信息1250。然后，仅在从远程信息处理中心10接收到测试计划信息1250的情况下，进入步骤S606，向远程信息处理中心10请求通过测试计划提供发布预定的更新用软件(根据由具有相同的测试计划ID1251的记录中指定的软件ID1258确定的所有的更新用软件)。

这样，如果以测试计划单位将多个更新用软件一并下载，则在之后的各软件的安装定时，能够快速地开始安装，能够期待缩短测试的准备时间的效果。例如，通过在测试行驶中进行下载，能够抑制产生等待下载完成的时间，能够在测试车辆的停止时(引擎停止时)快速地开始下一软件的安装。

接着，参照图15说明基于测试计划的更新用软件的安装处理。图15所示的处理由装载于车辆20的软件更新装置210的活动确认部212和ECU软件更新部214、和装载于远程信息处理中心10的中央运算处理装置110的测试计划管理部114执行。

根据图15，首先，车辆20的活动确认部212使用从引擎ECU241得到的信息检测引擎停止(步骤S701)。

在步骤S701中检测到引擎停止时，活动确认部212确认下一测试序号是否存在(步骤S702)。具体而言例如，参照当前的测试计划的测试计划信息1250，确认测试序号1252中是否存在下次。如果不存在下一测试序号(步骤S702的NO)，则也没有应安装的更新用软件，所以结束处理。

另一方面，在步骤S702中存在下一测试序号的情况下(步骤S702的YES)，活动确认部212将关于下次测试的信息显示于输入输出装置234(步骤S703)。

在此，对输入输出装置234的显示画面进行说明。步骤S703中，从对于操作者(例如司机)的信息显示等的目的来看，在输入输出装置234中显示图16中示例那样的画面“测试计划确认画面”。

根据图16，测试计划确认画面1100显示于输入输出装置234，从上依次具有显示区域1101、1102、1103、1104，在显示区域1104的下部还具有按钮1105、1106。

显示区域1101～1103为了显示关于测试计划中的下次测试的信息等而设置，主要显示测试计划信息1250中记载的信息。

具体而言，显示区域1101的显示内容能够从测试车辆VIN1256和ECU-ID1257取得。另外，显示区域1103的显示内容与测试计划ID1251、测试序号1252、测试开始日期时刻1254和测试结束日期时刻1255(测试期间)、软件ID1258等对应。此外，显示区域1103的软件ID中关联显示的“更新类型”和“后版本”通过基于软件ID“APA_ver13_2”并参照软件信息1240(软件DB124)而能够取得。

显示区域1102中表示在测试场地开始下次测试的位置(测试开始位置)和测试车辆的当前位置(车辆位置)。测试开始位置能够从测试计划信息1250的测试开始位置1259取得。车辆位置能够从存储于车辆DB121的车辆信息1210的位置1213取得。如图16的显示区域1102，通过不是显示数值数据而是将信息可视化显示，司机等操作者能够简单地掌握当前的状况。

显示区域1104中显示对于更新用软件的安装，向操作者(例如司机)请求允许的消息。作为对该消息的回答，司机通过选择按钮1105的“是”或按钮1106的“否”，赋予对于更新用软件的安装的允许/不许可。此外，显示区域1104中可显示的消息不限定于图16的例子。除此之外，例如，在下次测试中发布预定的更新用软件的下载未完成的情况下，也可以显示“请等待至下载完成”那样的消息等。

返回图15的说明。步骤S703中显示测试计划确认画面之后，活动确认部212判断是否得到司机的允许(步骤S704)。具体而言，在选择了测试计划确认画面1100的按钮1105的情况下，判断为得到对于下次测试用的更新用软件的安装开始的允许(步骤S704的YES)，此时，进入步骤S705。另一方面，在选择了测试计划确认画面1100的按钮1106的情况下，判断为未得到司机的允许(步骤S704的NO)，并结束处理。

接着，在步骤S706中，活动确认部212确认本车辆20(测试车辆)的当前位置是否距测试开始位置为距离X以内。在此的“距离X”规定了从由测试计划信息1250的测试开始位置1259严密指定的开始位置起的规定的允许范围，预先设定适当的距离。在步骤S706中本车辆20的当前位置从测试开始位置离开超过距离X的情况下(步骤S706的NO)，由于不处于可开始安装更新用软件的位置，所以结束处理。另一方面，在步骤S706中为距离X以内的情况下(步骤S706的YES)，进入步骤S707。

然后，步骤S707中，活动确认部212向远程信息处理中心10通知更新用软件向对象ECU的安装开始。接收步骤S707的安装开始通知，在远程信息处理中心10，测试计划管理部114对于执行测试计划的测试计划信息1250将状态1253更新为“安装中”，并覆盖写于测试计划DB125(步骤S711)。

另外，发送了安装开始通知的车辆20中，ECU软件更新部214执行对象ECU的软件安装，并覆盖写该ECU的存储装置(步骤S708)。然后，ECU软件更新部214从对象ECU接收安装结果(更新的成否信息)，并将接收的更新的成否信息通知给远程信息处理中心10(步骤S709)。

然后，接收步骤S709的通知，在远程信息处理中心10，测试计划管理部114对于执行测试计划的测试计划信息1250将状态1253更新为“完成”，并覆盖写于测试计划DB125(步骤S712)。

如上所述，图14和图15所示的处理正常进行，由此，本实施方式的软件发布系统1中，测试计划进行更新用软件的发布(下载和安装)完成，由此，执行测试计划中的下次测试的准备就绪。

如以上进行的说明，第2实施方式的软件发布系统1中，对于需要多次的更新用软件的发布那样的测试计划，使用比通常的活动更详细的信息(测试计划信息)，能够管理对车载设备的更新用软件的发布。

另外，执行上述那样的测试计划的测试场地等中，存在测试时间的制约、和不具有对于软件的专业知识的测试人员(司机等)必须根据测试计划的进行将更新用软件安装于测试车辆的困难。对于这种课题，第2实施方式的软件发布系统1实现以下那样的效果。

首先，第2实施方式中，在开始测试前创建测试计划，能够将在测试计划内更新的软件统一指定并登记(参照图13)。关于该测试计划的创建的操作，能够在测试场地中进行之前由具有专业知识的工程师等进行，所以能够期待防止测试人员的操作错误的效果。另外，创建测试计划时，也能够与第1实施方式的活动的创建同样进行失误可能性判定处理，所以在该情况下，也能够期待防止工程师等的软件的选择失误。

接着，第2实施方式中，创建测试计划之后，在实际上实施测试的测试场地等，通过简单的操作能够实现多个更新用软件的发布(下载和安装)(参照图14、图15)。

例如，如图14所示，对于测试计划的更新用软件的下载，能够以测试车辆(车辆20)的引擎的起动为契机，自动地检索测试计划(步骤S602～S604，步骤S611～S612)，或在具有下一测试序号的情况下，自动地执行更新用软件的下载(步骤S606～S609，步骤S613～S615)。通过进行这种处理，对测试人员(例如司机)不要求专业的判断，在进行测试行驶的期间，能够下载下一测试用的更新用软件，能够抑制人为失误的产生。

另外，例如，如图15所示，对于测试计划中的更新用软件的安装，以测试车辆(车辆20)的引擎的停止为契机，在测试计划确认画面(参照图16)中显示关于下次测试的信息，在可安装的条件就绪的情况下，测试人员(例如司机)确认该画面，如果选择意思是“是”的按钮1105，则立即开始下一更新用软件的安装。即，在测试场地中，即使不是具有专业知识的工程师，也能够通过根据测试计划的进行一边观察显示的测试计划确认画面一边进行简单的操作(仅选择“是”或“否”)，来进行下一测试用的软件的更新，能够抑制人为失误的产生。

如上所述，在第2实施方式中，能够抑制人为失误的产生，且在测试场地等中通过简单的操作实现多个更新用软件的发布，所以能够期待防止操作失误等引起的再次设定的发生，并且缩短面向下一测试的准备所需时间的效果。

另外，在第2实施方式中，对于测试计划以外的活动进行与第1实施方式同样的处理，所以与第1实施方式同样，只要在对于新活动的创建委托，判定为没有更新用软件的选择失误的可能性的情况下创建、登记活动信息1230，并创建该活动。另外，在判定为具有更新用软件的选择失误的可能性的情况下，在活动创建画面1000中显示警告消息(显示区域1003)，由此，能够确认、探讨指定的软件是否有错误。这样，第2实施方式的软件发布系统1能够防止由于人为的选择失误在活动中发布错误的更新用软件。

(3)其它

此外，通过第1和第2实施方式表示的本发明不是仅可适用于设计开发工序的销售前的阶段，也可适用于车辆销售后的OTA(Field Over The Air)。具体而言例如，在车辆的用户以功能追加和车辆的调整为目的选择、购买软件那样的情况下，能够预想通过活动来发布更新用软件情况，通过对这种活动应用本发明，在创建活动时，实现抑制与操作者本来的意图不同的选择引起的软件的选择失误的效果。

另外，本发明不限定于上述的实施方式，包含各种变形例。例如，上述的实施方式是为了容易理解地说明本发明而详细地说明的方式，未必限定于包括说明的全部结构。另外，各实施方式的结构的一部分能够进行其它结构的追加、删除、置换。具体而言例如，也可以作为软件发布服务器的远程信息处理中心10包括具有显示功能的输入输出装置，进行与终端30的输入输出装置330和车辆20(导航终端230)的输入输出装置234同样的显示(活动创建画面和测试计划确认画面)等。

另外，上述的各结构、功能、处理部、处理部等也可以将它们的一部分或全部通过例如利用集成电路进行设计等并利用硬件实现。另外，上述的各结构、功能等也可以通过处理器对实现各自功能的程序进行解释并执行来用软件实现。实现各功能的程序、表、文件等的信息能够设置于存储器、和硬盘、SSD(Solid State Drive)等的记录装置、或IC卡、SD卡、DVD等的记录介质。另外，控制线和信息线表示认为说明上必要的线，产品上未必显示所有的控制线和信息线。实施中也可以考虑几乎所有的结构相互连接。

Claims (14)

1.一种控制对车辆的车载设备进行的功能的更新的软件发布系统，其特征在于，包括：

软件发布服务器，其通过活动来管理所述功能的更新，将基于该活动的软件远程发布到该活动的对象车辆；

终端，其接收操作者的操作来进行对于所述软件发布服务器的输入输出；和

软件更新装置，其装载于所述车辆，下载从所述软件发布服务器发布的所述软件，并将其安装于对象的车载设备，

所述软件发布服务器具有：

存储部，其存储包含所述软件的各种信息；

活动管理部，其从所述终端接收所述活动所需的信息，将由所述接收到的信息构成的活动信息登记于所述存储部，由此创建该活动；和

软件发布部，其按照登记于所述活动管理部的所述活动信息，将基于所述活动的所述软件远程发布到该活动的对象车辆，

在通过所述终端的操作委托了所述活动的创建时，

所述活动管理部将作为所述委托的活动的对象的所述车辆的车载设备的最近的多次活动的所述软件的更新量的统计信息和所述委托的活动的所述软件的更新量进行比较，在满足规定条件的情况下，不创建所述委托的活动而准备规定的警告并将其发送到所述终端，

所述终端将从所述活动管理部接收到的所述规定的警告显示于规定的显示画面，

所述软件的更新量基于更新前后的软件的文件大小或源代码的行数的差量或视作二进制文件时的差量比特的量或写入ECU时更新的ROM的块数来计算。

2.如权利要求1所述的软件发布系统，其特征在于：

所述终端在显示所述规定的警告的所述规定的显示画面中，将用于再次决定是否要创建所述委托的活动的输入部一起显示，

在通过所述输入部作出了要创建所述委托的活动的决定的情况下，所述活动管理部创建该活动。

3.如权利要求1所述的软件发布系统，其特征在于：

所述活动管理部委托了所述活动的创建时使用的所述规定条件，是用于判定与最近的多次活动的所述软件的更新量的所述统计信息相比，所述委托的活动的所述软件的更新量大幅偏离的条件。

4.如权利要求1所述的软件发布系统，其特征在于：

对于阶段性地执行多个所述活动的测试计划，

所述软件发布服务器还具有测试计划管理部，其从所述终端接收所述测试计划所需的信息，将由所述接收到的信息构成的测试计划信息登记于所述存储部，由此创建该测试计划，

所述软件发布部按照登记于所述测试计划管理部的所述测试计划信息，将基于所述测试计划中包含的多个活动的所述软件远程发布到该测试计划的对象车辆，

基于所述测试计划被发布了所述软件的所述对象车辆，在执行该测试计划中包含的各个活动前，经由所述终端向操作者请求允许执行基于该活动的所述软件的安装，在得到允许的情况下由所述软件更新装置进行该软件的安装。

5.如权利要求4所述的软件发布系统，其特征在于：

所述测试计划信息中，不仅包含构成所述活动信息的信息，还至少包含表示所述测试计划中的测试的序号和开始位置的信息。

6.如权利要求4所述的软件发布系统，其特征在于：

向操作者请求允许执行所述软件的安装的所述终端，配置于要被发布所述软件的所述对象车辆。

7.如权利要求4所述的软件发布系统，其特征在于：

所述软件发布部在所述测试计划的开始前，将基于该测试计划中包含的多个活动的所述软件一并远程发布到该测试计划的对象车辆。

8.一种软件发布服务器，其通过活动来管理对车辆的车载设备进行的功能的更新，将基于该活动的软件远程发布到该活动的对象车辆，所述软件发布服务器的特征在于，包括：

存储部，其存储包含所述软件的各种信息；

活动管理部，其从终端接收所述活动所需的信息，将由所述接收到的信息构成的活动信息登记于所述存储部，由此创建该活动；和

软件发布部，其按照登记于所述活动管理部的所述活动信息，将基于所述活动的所述软件远程发布到该活动的对象车辆，

从所述终端接收到创建所述活动的委托时，

所述活动管理部将作为所述委托的活动的对象的所述车辆的车载设备的最近的多次活动的所述软件的更新量的统计信息和所述委托的活动的所述软件的更新量进行比较，在满足规定条件的情况下，不创建所述委托的活动而准备规定的警告并将其发送到所述终端，

所述软件的更新量基于更新前后的软件的文件大小或源代码的行数的差量或视作二进制文件时的差量比特的量或写入ECU时更新的ROM的块数来计算。

9.如权利要求8所述的软件发布服务器，其特征在于：

所述活动管理部，在尽管从所述终端接收到要创建所述活动的委托但不创建所述委托的活动而将所述规定的警告发送到所述终端之后，

在从所述终端重新接收到表示要创建所述委托的活动的意思的指示的情况下，创建该活动。

10.如权利要求8所述的软件发布服务器，其特征在于：

所述活动管理部委托了所述活动的创建时使用的所述规定条件，是用于判定与最近的多次活动的所述软件的更新量的所述统计信息相比，所述委托的活动的所述软件的更新量大幅偏离的条件。

11.如权利要求8所述的软件发布服务器，其特征在于：

所述软件的更新量基于更新前后的软件的文件大小或源代码的行数的差量或视作二进制文件时的差量比特的量或写入ECU时更新的ROM的块数来计算。

12.一种软件发布方法，由控制对车辆的车载设备进行的功能的更新的软件发布系统进行，其特征在于：

所述软件发布系统具有：

软件发布服务器，其通过活动来管理所述功能的更新，将基于该活动的软件远程发布到该活动的对象车辆；

终端，其接收操作者的操作来进行对于所述软件发布服务器的输入输出；和

软件更新装置，其装载于所述车辆，下载从所述软件发布服务器发布的所述软件，并将其安装于对象的车载设备，

所述软件发布服务器具有：

存储部，其存储包含所述软件的各种信息；

活动管理部，其从所述终端接收所述活动所需的信息，将由所述接收到的信息构成的活动信息登记于所述存储部，由此创建该活动；和

软件发布部，其按照登记于所述活动管理部的所述活动信息，将基于所述活动的所述软件远程发布到该活动的对象车辆，

在通过所述终端的操作委托了所述活动的创建时，包括如下步骤：

比较步骤，所述活动管理部将作为所述委托的活动的对象的所述车辆的车载设备的最近的多次活动的所述软件的更新量的统计信息和所述委托的活动的所述软件的更新量进行比较；

活动不创建步骤，在所述比较步骤中满足规定条件的情况下，所述活动管理部不创建所述委托的活动而准备规定的警告并将其发送到所述终端；和

警告显示步骤，接受所述活动不创建步骤，所述终端将从所述活动管理部接收到的所述规定的警告显示于规定的显示画面，

所述软件的更新量基于更新前后的软件的文件大小或源代码的行数的差量或视作二进制文件时的差量比特的量或写入ECU时更新的ROM的块数来计算。

13.如权利要求12所述的软件发布方法，其特征在于：

在所述警告显示步骤中，所述终端在显示所述规定的警告的所述规定的显示画面中，将用于再次决定是否要创建所述委托的活动的输入部一起显示，

在所述警告显示步骤之后，还包括在通过所述输入部作出了要创建所述委托的活动的决定的情况下，所述活动管理部创建该活动的活动创建步骤。

14.如权利要求12所述的软件发布方法，其特征在于：

对于阶段性地执行多个所述活动的测试计划，

所述软件发布服务器还具有测试计划管理部，其从所述终端接收所述测试计划所需的信息，将由所述接收到的信息构成的测试计划信息登记于所述存储部，由此创建该测试计划，

所述软件发布部按照登记于所述测试计划管理部的所述测试计划信息，将基于所述测试计划中包含的多个活动的所述软件远程发布到该测试计划的对象车辆，

基于所述测试计划被发布了所述软件的所述对象车辆，在执行该测试计划中包含的各个活动前，经由所述终端向操作者请求允许执行基于该活动的所述软件的安装，在得到允许的情况下由所述软件更新装置进行该软件的安装。