CN117321569A - 车辆用电子控制装置、更新程序以及数据结构 - Google Patents

Abstract

本发明的车辆用电子控制装置(13)具备：下载器(35)，对下载处理执行部指示执行下载处理，其中，上述下载处理执行部执行从外部下载更新数据的下载处理；第二执行指示部(36～38)，对执行安装处理和激活处理的更新对象节点，指示执行安装处理以及执行激活处理，其中，在上述安装处理中安装更新数据并生成更新后的软件，在上述激活处理中使更新后的软件有效；以及执行请求部(34b)，以更新方法为单位对第一执行指示部或者第二执行指示部发送执行请求，并以更新方法为单位请求下载处理、安装处理以及激活处理中的任意一个处理的执行。

Description

车辆用电子控制装置、更新程序以及数据结构

相关申请的交叉引用

本申请基于在2021年5月21日申请的日本申请号2021－086157号，在此引用其记载内容。

技术领域

本公开涉及车辆用电子控制装置、更新程序以及数据结构。

背景技术

近年来，随着驾驶辅助功能、自动驾驶功能等车辆控制的多样化，搭载于车辆的电子控制装置(以下，称为ECU(Electronic Control Unit：电子控制单元))等的节点的包含车辆控制、诊断等的程序、数据的软件的规模增大。另外，随着基于功能改善等的版本升级，更新(重新编程)节点的动作所需的软件的机会也在增加。另一方面，随着通信网络的发展等，联网汽车的技术也在普及。根据这样的情况，提出了如下技术：在车辆侧设置作为网关ECU发挥作用的车辆用电子控制装置，在车辆用电子控制装置中，将从中心装置下载的更新数据分发给更新对象节点，并通过OTA(Over The Air：空中下载)来更新更新对象节点的软件(例如参照专利文献1)。

专利文献1：日本特开2020－27627号公报

可以成为更新对象的节点多种多样，有软件的更新方法不同的情况。例如，如在更新用于驾驶辅助、自动驾驶的ADAS(Advanced Driving Assistant System：高级驾驶辅助系统)系统的节点的软件时，使用高速文件通信来转送数据，在更新用于车辆行驶的驱动系统的节点的软件时，使用诊断通信来转送数据那样，更新方法不同。因此，有在一个活动信息中以不同的更新方法更新多个更新对象节点的软件的情况。在这样的情况下，如果不适当地管理更新顺序而同时执行多个更新方法，则存在以不希望的组合来更新软件的担忧。

发明内容

本公开的目的在于在以不同的更新方法更新多个更新对象节点的软件的情况下，适当地更新软件。

根据本公开的一个方式，第一执行指示部对执行下载处理的下载处理执行部指示执行下载处理，其中，上述下载处理是从外部下载更新数据的处理。第二执行指示部对执行安装处理和激活处理的更新对象节点指示执行安装处理以及执行激活处理，其中，在上述安装处理中安装更新数据并生成更新后的软件，在上述激活处理中使更新后的软件有效。执行请求部以更新方法为单位对第一执行指示部或者第二执行指示部发送执行请求，并以更新方法为单位请求下载处理、安装处理以及激活处理中的任意一个处理的执行。

通过以更新方法为单位请求下载处理、安装处理以及激活处理中的任意一个处理的执行，以更新方法为单位使下载处理、安装处理以及激活处理中的任意一个执行。在以不同的更新方法更新多个更新对象节点的软件的情况下，能够避免同时执行多个更新方法的情况、以不适当的顺序执行多个更新方法的情况。由此，能够避免以不希望的组合更新软件的情况，能够适当地更新软件。

附图说明

通过参照附图进行下述的详细描述，本公开的上述目的以及其他目的、特征、优点变得更加明确。

图1是表示一个实施方式的整体结构的图。

图2是表示CGW的电气结构的图。

图3是表示ECU的电气结构的图。

图4是CGW的功能框图。

图5是表示规格数据中的执行请求的发送对象的图。

图6是表示规格数据中的执行请求的发送顺序的图。

图7是表示处理的流程的图(其1)。

图8是表示处理的流程的图(其2)。

图9是流程图(其1)。

图10是流程图(其2)。

图11是流程图(其3)。

图12是流程图(其4)。

图13是流程图(其5)。

图14是流程图(其6)。

图15是流程图(其7)。

具体实施方式

以下，参照附图对一个实施方式进行说明。

车辆用电子控制系统是能够通过OTA(Over The Air)来更新搭载于电子控制装置(以下，称为ECU(Electronic Control Unit))的车辆控制、诊断等的软件的系统。软件包含用于实现车辆控制、诊断等功能的程序、数据，也能够表示为应用程序。在本实施方式中，对更新车辆控制、诊断等的软件的情况进行说明，但例如在更新地图应用、在该地图应用中使用的地图数据等的情况下也能够应用。

如图1所示，车辆用电子控制系统1具有通信网络2侧的中心装置3、车辆侧的车辆侧系统4以及显示终端5。通信网络2例如包含基于4G线路等的移动体通信网络、因特网、WiFi(Wireless Fidelity)(注册商标)等而构成。

作为HMI(Human Machine Interface：人机界面)的显示终端5是具有受理来自用户的操作输入的功能、显示各种画面的功能的终端，例如是用户可携带的智能手机、平板电脑等移动终端6、配置于车室内的车载显示器7。移动终端6只要在移动体通信网络的通信范围内，就能够经由通信网络2与中心装置3进行数据通信。车载显示器7与车辆侧系统4连接，可以是兼具导航功能的结构。另外，车载显示器7也可以是具有ECU的功能的车载显示器ECU，也可以具有控制向中心显示器、仪表显示器等的显示的功能。

用户如果在车室外且在移动体通信网络的通信范围内，则能够一边通过移动终端6确认与软件的更新有关的各种画面一边进行操作输入，来进行与软件的更新有关的手续。用户在车室内，能够一边通过车载显示器7确认与软件的更新有关的各种画面一边进行操作输入，来进行与软件的更新有关的手续。即，用户能够在车室外和车室内分开使用移动终端6和车载显示器7，来执行与软件的更新有关的手续。

中心装置3在车辆用电子控制系统1中统一通信网络2侧的软件的更新功能，作为提供OTA服务的OTA中心发挥作用。中心装置3具有文件服务器8、网络服务器9以及管理服务器10，各服务器8～10构成为能够相互进行数据通信。即，中心装置3按每个功能包含不同的多个服务器而构成。

文件服务器8是管理从中心装置3向车辆侧系统4分发的软件的文件的服务器。文件服务器8管理作为从中心装置3分发给车辆侧系统4的软件的提供企业的供应商等提供的更新数据、从OEM(Original Equipment Manufacturer：原始设备制造商)提供的规格数据、从车辆侧系统4获取的车辆状态等。

文件服务器8能够经由通信网络2在与车辆侧系统4之间进行数据通信，将活动信息发送至车辆侧系统4，并将规格数据发送至车辆侧系统4。另外，文件服务器8若从车辆侧系统4接收到数据包数据的下载请求，则将打包更新数据所得到的数据包数据发送至车辆侧系统4。数据包数据包含被压缩的zip形式的文件。此外，文件服务器8也可以通过将打包规格数据和更新数据所得到的数据包数据发送至车辆侧系统4，将规格数据和更新数据同时发送至车辆侧系统4。

网络服务器9是管理网络信息的服务器。网络服务器9根据来自移动终端6等所具有的网络浏览器的请求来发送自己管理的网络数据。管理服务器10是管理在软件的更新的服务注册的用户的个人信息、每台车辆的软件的更新例示等的服务器。

车辆侧系统4具有车辆用主装置11。车辆用主装置11在车辆用电子控制系统1中统一车辆侧的软件的更新功能，作为OTA主机发挥作用。车辆用主装置11具有DCM(DataCommunication Module：数据通信模块)12和CGW(Central Gate Way：中央交易网关)13。

DCM12与中心装置3之间经由通信网络2进行数据通信，相当于下载处理执行部。CGW13作为网关ECU发挥作用，相当于车辆用电子控制装置。DCM12和CGW13以能够经由第一总线14进行数据通信的方式连接。在图1中，例示出DCM12和车载显示器7与同一第一总线14连接的结构，但也可以是DCM12和车载显示器7与不同的总线连接的结构。另外，也可以是CGW13具有DCM12的功能的一部分或者整体的结构，也可以是DCM12具有CGW13的功能的一部分或者整体的结构。即，在车辆用主装置11中，DCM12和CGW13的功能划分也可以以任意的方式构成。车辆用主装置11可以由DCM12以及CGW13这两个ECU构成，也可以由具有DCM12的功能和CGW13的功能的一个统合ECU构成。

CGW13除了与第一总线14连接以外，还连接有第二总线15、第三总线16、第四总线17以及第五总线18，作为车内侧的总线，经由总线15～17连接各种ECU19，并且经由总线18连接有电源管理ECU20。ECU19相当于节点。

第二总线15例如是多媒体系统的总线，连接有进行多媒体系统的控制的ECU19。第三总线16例如是用于驾驶辅助、自动驾驶的ADAS系统的总线，连接有进行ADAS系统的控制的ECU19。第四总线17例如是用于车辆行驶的驱动系统的总线，连接有进行驱动系统的控制的ECU19。总线15～17也可以是多媒体系统的总线、ADAS系统的总线、驱动系统的总线以外的系统的总线。另外，总线的根数、ECU19的个数并不限于例示出的结构。另外，总线无需按系统来划分，例如也可以根据车辆的前方和后方等成为控制对象的ECU19的位置来划分，也可以根据系统和ECU19的设定位置来划分。电源管理ECU20是管理对DCM12、CGW13、各种ECU19等供给的电源的ECU。

在CGW13连接有第六总线21作为车外侧的总线。第六总线21连接有DLC(Data LinkCoupler：数据链路耦合器)连接器22，该DLC连接器22可拆卸地连接作为服务工具发挥作用的工具23。车内侧的总线14～18以及车外侧的总线21例如由CAN(Controller AreaNetwork(控制器局域网)，注册商标)总线构成，CGW13根据CAN的数据通信标准、诊断通信标准(UDS(Unified Diagnosis Services：统一诊断服务)：ISO14229)在与DCM12、各种ECU19以及工具23之间进行数据通信。此外，DCM12和CGW13可以通过以太网连接，DLC连接器22和CGW13也可以通过以太网连接。

CGW13以能够下载数据包数据的条件成立为条件，将数据包数据的下载请求经由DCM12发送至中心装置3。所谓的能够下载数据包数据的条件是得到下载的同意、CGW13能够经由DCM12与中心装置3进行数据通信、DCM12的存储器的空闲容量为规定容量以上、车载蓄电池的剩余容量为规定容量以上等。CGW13若从中心装置3经由DCM12下载数据包数据，则从该下载的数据包数据获取更新数据。

CGW13以能够指示写入更新数据的安装的条件成立为条件，对软件的更新对象ECU19指示该获取到的更新数据的安装。所谓的能够指示安装的条件是得到安装的同意、车辆状态是能够安装的状态、更新对象ECU19是能够安装的状态、更新数据是正常的数据、车载蓄电池的剩余容量为规定容量以上等。更新对象ECU19若从CGW13指示更新数据的安装，则执行更新数据的安装。

若在更新对象ECU19中更新数据的安装完成，则CGW13以能够指示使安装完成后的软件有效的激活的条件成立为条件，对更新对象ECU19指示激活。所谓的能够指示激活的条件是得到激活的同意、车辆状态是能够激活的状态、更新对象ECU19是能够激活的状态、车载蓄电池的剩余容量为规定容量以上等。更新对象ECU19若被从CGW13指示激活，则执行激活。

如图2所示，CGW13具有微型计算机(以下，称为微机)24、存储器25、数据转送电路26、电源电路27以及电源检测电路28作为电气功能模块。微机24执行储存于非过渡性实体存储介质的各种控制程序进行各种处理，来控制CGW13的动作。在本实施方式中，例示出在CGW13搭载有一个微机24的结构，但搭载于CGW13的微机的个数、规格、组合根据CGW13所要求的处理能力来决定。即，若是CGW13要求相对较高的处理能力的情况，则采用相对较高的规格的微机，或为了实现分散处理、并列处理而采用多个微机。

存储器25例如是eMMC(embedded Multi Media Card：嵌入式多媒体卡)、NorFlash。数据转送电路26控制与总线14～18、21之间的依据CAN的数据通信标准、以太网的通信标准、诊断通信标准等的数据通信。电源电路27输入蓄电池电源、辅助电源、点火电源。电源检测电路28检测电源电路27输入的蓄电池电源的电压值、辅助电源的电压值、点火电源的电压值，并将这些已经检测出的电压值与规定的电压阈值进行比较，并将其比较结果输出至微机24。微机24根据从电源检测电路28输入的比较结果，判定从外部对CGW13供给的蓄电池电源、辅助电源、点火电源是正常还是异常。

如图3所示，ECU19具有微机29、数据转送电路30、电源电路31以及电源检测电路32作为电气功能模块。微机29具有CPU29a、ROM29b、RAM29c以及闪存29d。闪存29d中包含不能从ECU19的外部读出信息的安全区域。微机29执行储存于非过渡性实体存储介质的各种控制程序进行各种处理，来控制ECU19的动作。

数据转送电路30控制与总线15～17之间的依据CAN的数据通信标准、以太网的通信标准等的数据通信。电源电路31输入蓄电池电源、辅助电源、点火电源。电源检测电路32检测电源电路31输入的蓄电池电源的电压值、辅助电源的电压值、点火电源的电压值，将这些检测出的电压值与规定的电压阈值进行比较，并将其比较结果输出至微机29。微机29根据从电源检测电路32输入的比较结果，判定从外部对ECU19供给的蓄电池电源、辅助电源、点火电源是正常还是异常。此外，ECU19自身连接的例如传感器、致动器等的负载不同，基本上是同等的结构。

在上述的结构中，由于可能成为更新对象的ECU19是多种多样的，因此在多媒体系统的ECU19、ADAS系统的ECU19、驱动系统的ECU19中，有软件的更新方法不同的情况。例如，如在更新ADAS(Advanced Driving Assistant System)系统的ECU19的软件时，利用高速文件通信来进行数据转送，在更新驱动系统的ECU19的软件时，利用诊断通信来进行数据转送那样，更新方法不同。对于像这样软件的更新方法不同的多个ECU19混合存在的结构，CGW13采用以下的结构。更新方法不同除了如上述那样进行数据转送的通信方式不同以外，也指即使进行数据转送的通信方式相同，ECU19的系统也不同的情况。所谓的更新方法是更新ECU19的软件时的方式、顺序，所谓的方式、顺序，更具体而言，例如表示存储、流式传输等进行数据转送的通信方式、更新所需的处理的手续的种类。此外，根据一个更新方法成为更新对象的ECU19并不局限于一个，也有汇总更新的多个ECU19的情况。

如图4所示，CGW13在控制部33中具有整体管理部34、下载器35、第一更新主机36、第二更新主机37、第三更新主机38以及规格数据存储部39。下载器35相当于第一执行指示部。第一更新主机36、第二更新主机37以及第三更新主机38相当于第二执行指示部。整体管理部34具有规格数据获取部34a、执行请求部34b、状态判定部34c、同意结果接收部34d、同意结果发送部34e、处理完成通知接收部34f以及处理完成通知发送部34g。各部34～38、34a～34g相当于由更新程序执行的功能。即，控制部33通过执行更新程序来进行各部34～38、34a～34g的功能。此外，在图4中，例如第一更新主机36与多媒体系统的ECU19连接，但更新主机与ECU19的关系也可以是这样的对应关系以外的关系。如果第一更新主机36与ADAS系统的ECU19连接，则第一更新主机36也可以管理ADAS系统的ECU19的更新处理。另外，第一更新主机36也可以管理驱动系统的ECU19的更新处理。

下载器35以接收到来自整体管理部34的下载执行请求为契机对DCM12指示执行下载处理。第一更新主机36管理多媒体系统的ECU19的更新处理，以接收到来自整体管理部34的安装执行请求为契机对多媒体系统的ECU19指示执行安装处理，以接收到激活执行请求为契机，对多媒体系统的ECU19指示执行激活处理。第二更新主机37管理ADAS系统的ECU19的更新处理，以接收到来自整体管理部34的安装执行请求为契机，对ADAS系统的ECU19指示执行安装处理，以接收到激活执行请求为契机对ADAS系统的ECU19指示执行激活处理。第三更新主机38管理驱动系统的ECU19的更新处理，以接收到来自整体管理部34的安装执行请求为契机，对驱动系统的ECU19指示执行安装处理，以接收到激活执行请求为契机，对驱动系统的ECU19指示执行激活处理。换言之，更新主机36～38管理作为管理对象的ECU19的更新处理，以接收到来自整体管理部34的安装执行请求为契机，指示执行安装处理，以接收到激活执行请求为契机，指示执行激活处理。作为一个例子，在CGW13中，使整体管理部34、下载器35、更新主机36～38分别成为在功能上独立的模块。通过采用这样的结构，能够简化软件结构，并且适当地确保系统的品质保证。并且，能够在使各自独立的状态下进行软件开发，开发效率提高。

规格数据获取部34a从数据包数据获取规格数据，并将该已经获取到的规格数据存储至规格数据存储部39。规格数据包含与软件的更新有关的各种信息，作为一个信息，包含图5所示的与执行请求的发送对象相关的信息、图6所示的与执行请求的发送顺序相关的信息。与执行请求的发送对象相关的信息包含更新主机、更新主机的节点ID、作为执行请求的发送对象的处理的项目。在图5中，例示出安装执行请求的发送对象是第一更新主机36、第二更新主机37、第三更新主机38，激活执行请求的发送对象是第一更新主机36、第二更新主机37、第三更新主机38。与执行请求的发送顺序相关的信息包含以更新主机36～38为对象的安装处理以及激活处理的优先级。在图6中，例示出按第一更新主机36、第二更新主机37、第三更新主机38的顺序发送安装执行请求，将激活执行请求同时发送至第一更新主机36、第二更新主机37、第三更新主机38。即，规格数据是包含能够确定以更新方法为单位请求下载处理、安装处理、激活处理的执行时的执行请求的发送对象以及发送顺序的信息的数据结构。此外，只要是指定表示是下载、安装、激活中的哪一个的执行请求的种类以及执行请求的发送对象和发送顺序的形式，数据结构也可以是其他形式。

执行请求部34b通过将下载执行请求发送至下载器35，从而从下载器35对DCM12指示执行下载处理，在DCM12中使下载处理执行。执行请求部34b通过将安装执行请求发送至更新主机36～38，从而从更新主机36～38对更新对象ECU19指示执行安装处理，在更新对象ECU19中使安装处理执行。执行请求部34b通过将激活执行请求发送至更新主机36～38，从而从更新主机36～38对更新对象ECU19指示执行激活处理，在更新对象ECU19中使激活处理执行。

状态判定部34c判定是否是能够执行下载处理的状态、是否是能够执行安装处理的状态、是否是能够执行激活处理的状态。状态判定部34c通过判定能够下载上述的数据包数据的条件，来判定是否是能够执行下载处理的状态。状态判定部34c通过判定能够指示上述安装的条件，来判定是否是能够执行安装处理的状态。状态判定部34c通过判定能够指示上述激活的条件，来判定是否是能够执行激活处理的状态。

同意结果接收部34d接收来自下载处理、安装处理、激活处理的用户的同意结果。同意结果发送部34e若通过同意结果接收部34d接收到来自下载处理、安装处理、激活处理的用户的同意结果，则将该已经接收到的同意结果发送至中心装置3。

处理完成通知接收部34f从下载器35接收表示下载处理完成的下载处理完成通知。处理完成通知接收部34f从更新主机36～38接收表示安装处理完成的安装处理完成通知、表示激活处理完成的激活处理完成通知。若通过处理完成通知接收部34f接收到下载处理完成通知，则处理完成通知发送部34g将该已经接收到的下载处理完成通知发送至中心装置3。若通过处理完成通知接收部34f接收到安装处理完成通知、激活处理完成通知，则处理完成通知发送部34g将该已经接收到的安装处理完成通知、激活处理完成通知发送至中心装置3。

接下来，参照图7～图15对上述结构的作用进行说明。在这里，如图5至图6所示，以根据规格数据设定了执行请求的发送对象以及发送顺序为前提进行说明。

在CGW13的控制部33中，整体管理部34若判定为从中心装置3经由DCM12接收到活动信息(t1)、或者从更新主机36～38中的任意一个接收到事件通知(S1：是，t2)，则等待来自中心装置3的规格数据的接收(S2)。整体管理部34若判定为从中心装置3经由DCM12接收到规格数据(S2：是，t3)，则将该已经接收到的规格数据存储至规格数据存储部39，并参照该规格数据来决定执行请求的发送对象以及发送顺序(S3)。整体管理部34例如决定如上所述按第一更新主机36、第二更新主机37、第三更新主机38的顺序发送安装执行请求、将激活执行请求同时发送至第一更新主机36、第二更新主机37、第三更新主机38。

整体管理部34将下载同意画面显示请求发送至HMI(S4，t4)，等待来自HMI的同意结果的接收(S5)。HMI若从整体管理部34接收到下载同意画面显示请求，则显示下载的同意画面，若用户进行同意许可的操作，则将表示同意许可的同意结果发送至整体管理部34(t5)。

整体管理部34若判定为从HMI接收到表示同意许可的同意结果(S5：是)，则将表示同意许可的同意结果经由DCM12发送至中心装置3(S6、t6)。整体管理部34判定是否是能够执行下载处理的状态(S7)，若判定为是能够执行下载处理的状态(S7：是)，则将下载执行请求发送至下载器35(S8、t7，相当于执行请求步骤)，等待针对来自下载器35的下载执行请求的ACK的接收(S9)。下载器35若从整体管理部34接收到下载执行请求，则将ACK返回给整体管理部34。

整体管理部34若判定为从下载器35接收到ACK(S9：是)，则从下载器35对DCM12指示执行下载处理(S10)。若从下载器35对DCM12指示执行下载处理，则整体管理部34等待来自下载器35的下载处理完成通知的接收(S11)，并且监视指示执行下载处理后的经过时间(S12)。

下载器35通过从整体管理部34接收到下载执行请求，而将数据包数据的下载请求经由DCM12发送至中心装置3(t8)。中心装置3若从CGW13接收到数据包数据的下载请求，则将数据包数据分发至DCM12(t9)。DCM12开始从中心装置3的数据包数据的下载处理，若完成下载处理，则将下载处理完成通知发送至下载器35。下载器35若从DCM12接收到下载处理完成通知，则将下载处理完成通知发送至整体管理部34(t10)。

整体管理部34若在指示执行下载处理后经过一定时间之前，判定为从下载器35接收到下载处理完成通知(S11：是)，则将下载处理完成通知经由DCM12发送至中心装置3(S13、t11)。

另一方面，整体管理部34若在从下载器35接收到下载处理完成通知之前，判定为指示执行下载处理后经过了一定时间(S12：是)，则判定重试次数是否达到预先设定的上限次数(S14)。整体管理部34若判定为重试次数未达到上限次数(S14：否)，则将下载执行请求重发至下载器35(S15)，并将重试次数自加一(S16)，并返回到步骤S11、S12。整体管理部34若判定为重试次数达到上限次数(S14：是)，则将表示下载处理错误的错误通知经由DCM12发送至中心装置3(S17)。

若完成基于DCM12的下载处理，则整体管理部34将安装同意画面显示请求发送至HMI(S18、t12)，并等待来自HMI的同意结果的接收(S19)。HMI若从整体管理部34接收到安装同意画面显示请求，则显示安装的同意画面，若用户进行同意许可的操作，则将表示同意许可的同意结果发送至整体管理部34(t13)。

整体管理部34若判定为从HMI接收到表示同意许可的同意结果(S19：是)，则将表示同意许可的同意结果经由DCM12发送至中心装置3(S20、t14)。整体管理部34判定是否是能够执行安装处理的状态(S21)，若判定为是能够执行安装处理的状态(S21：是)，则将作为软件的更新对象的更新主机36～38中安装处理的优先级为最上位的更新主机36作为对象，并将安装执行请求发送至更新主机36(S22、t15，相当于执行请求步骤)，等待来自更新主机36的针对安装执行请求的ACK的接收(S23)。更新主机36若从整体管理部34接收安装执行请求，则将ACK返回到整体管理部34。

整体管理部34若判定为从更新主机36接收到ACK(S23：是)，则从更新主机36对更新对象ECU19指示执行安装处理(S24)。若从更新主机36对更新对象ECU19指示执行安装处理，则整体管理部34等待来自更新主机36的安装处理完成通知的接收(S25)，并且监视指示执行安装处理后的经过时间(S26)。

由更新主机36管理的更新对象ECU19若被从更新主机36指示执行安装处理，则开始安装处理，若完成安装处理，则将安装处理完成通知发送至更新主机36。更新主机36若从更新对象ECU19接收到安装处理完成通知，则将安装处理完成通知发送至整体管理部34(t16)。在该情况下，若由更新主机36管理的更新对象ECU19为多个，则更新主机36若从所有的更新对象ECU19接收到安装处理完成通知，则将安装处理完成通知发送至整体管理部34。

整体管理部34若在对更新主机36指示执行安装处理后经过一定时间之前，判定为从更新主机36接收到安装处理完成通知(S25：是)，则将安装处理完成通知经由DCM12发送至中心装置3(S27、t17)。

另一方面，整体管理部34若在从更新主机36接收到安装处理完成通知之前，判定为对更新主机36指示执行安装处理后经过了一定时间(S26：是)，则判定重试次数是否达到预先设定的上限次数(S28)。若判定为重试次数未达到上限次数(S28：否)，则整体管理部34将安装执行请求重发至更新主机36(S29)，并将重试次数自加一(S30)，并返回到步骤S25、S26。若判定为重试次数达到上限次数(S28：是)，则整体管理部34将表示安装处理错误的错误通知经由DCM12发送至中心装置3(S31)。

整体管理部34判定在本次的活动信息中是否对作为安装执行请求的发送对象的所有更新主机36～38发送完毕安装执行请求(S32)。若判定为未对作为发送对象的所有更新主机36～38发送完毕安装执行请求，存在未发送安装执行请求的更新主机36～38(S32：否)，则整体管理部34将作为软件的更新对象的更新主机36～38中优先级为下一位的更新主机37作为对象，返回到步骤S22，反复步骤S22以后。

如图6所示，在按第一更新主机36、第二更新主机37、第三更新主机38的顺序设定了安装处理的优先级的情况下，整体管理部34通过按第一更新主机36、第二更新主机37、第三更新主机38的顺序发送安装执行请求，来依次对多媒体系统的更新对象ECU19指示执行安装处理、对ADAS系统的更新对象ECU19指示执行安装处理、对驱动系统的更新对象ECU19指示执行安装处理(t15～t23)。

另一方面，若判定为对作为发送对象的所有更新主机36～38发送完毕安装执行请求，不存在未发送安装执行请求的更新主机36～38(S32：是)，且完成基于更新主机36～38的安装处理，则整体管理部34将激活同意画面显示请求发送至HMI(S33、t24)，并等待来自HMI的同意结果的接收(S34)。HMI若从整体管理部34接收到激活同意画面显示请求，则显示激活的同意画面，若用户进行同意许可的操作，则将表示同意许可的同意结果发送至整体管理部34(t25)。

整体管理部34若从HMI接收到表示同意许可的同意结果(S34：是)，则将表示同意许可的同意结果经由DCM12发送至中心装置3(S35、t26)。整体管理部34若判定为是能够执行激活处理的状态(S36：是)，则将激活执行请求同时发送至更新主机36～38(S37、t27，相当于执行请求步骤)，并等待来自更新主机36～38的针对激活执行请求的ACK的接收(S38)。更新主机36～38若从整体管理部34接收到激活执行请求，则将ACK返回到整体管理部34。

若判定为整体管理部34从更新主机36～38接收到ACK(S38：是)，则从更新主机36～38对更新对象ECU19同时指示执行激活处理(S39)。若从更新主机36～38对更新对象ECU19同时指示执行激活处理，则整体管理部34等待来自更新主机36～38的激活处理完成通知的接收(S40)，并且监视同时指示执行激活处理后的经过时间(S41)。

由更新主机36～38管理的更新对象ECU19若被从更新主机36～38指示执行激活处理，则开始激活处理，若完成激活处理，则将激活处理完成通知发送至更新主机36～38。更新主机36～38若从更新对象ECU19接收激活处理完成通知，则将激活处理完成通知发送至整体管理部34(t28)。在该情况下，若由更新主机36～38分别管理的更新对象ECU19为多个，则更新主机36～38若从各自管理的所有更新对象ECU19接收到激活处理完成通知，则将激活处理完成通知发送至整体管理部34。

整体管理部34若在指示执行激活处理后经过一定时间之前，判定为从更新主机36～38接收到激活处理完成通知(S40：是)，则将激活处理完成通知经由DCM12发送至中心装置3(S42、t29)。

另一方面，整体管理部34若在从更新主机36～38接收到激活处理完成通知之前，判定为在指示执行激活处理后经过了一定时间(S41：是)，则判定重试次数是否达到预先设定的上限次数(S43)。若判定为重试次数未达到上限次数(S43：否)，则整体管理部34将激活执行请求重发至更新主机36～38(S44)，并将重试次数自加一(S45)，并返回到步骤S40、S41。若判定为重试次数达到上限次数(S43：是)，则整体管理部34将表示激活错误的错误通知经由DCM12发送至中心装置3(S46)。

然而，例如在将安装执行请求发送至任意一个更新主机后，当在由该更新主机管理的更新对象ECU19中完成安装处理之前，可能有产生法规等优先度较高的处理请求的情况。在这样的情况下，整体管理部34进行图15所示的处理。

整体管理部34若将执行请求发送至任意一个更新主机(S51)，则判定是否接收到针对该执行中处理的执行请求的处理完成通知(S52)，并且判定是否产生了优先度较高的处理请求(S53)。若在接收到针对该执行中处理的执行请求的处理完成通知之前，判定为产生了优先度高的处理请求(S53：是)，则整体管理部34将执行中处理的中断请求发送至更新主机，中断执行中处理(S54)，并将优先度高的后续处理的执行请求发送至更新主机(S55)。

若将优先度高的后续处理的执行请求发送至更新主机，则整体管理部34判定是否接收到针对该优先度高的后续处理的执行请求的处理完成通知(S56)。若判定为接收到针对该优先度高的后续处理的执行请求的处理完成通知(S56：是)，则整体管理部34将已经中断的处理的重新开始请求发送至更新主机，并重新开始已经中断的处理(S57)，并返回到步骤S52、S53。此外，在将激活执行请求发送至任意一个更新主机后，当在由该更新主机管理的更新对象ECU19中完成激活处理之前，同样有产生法规等优先度高的处理请求的情况。

如以上说明的那样，根据实施方式，能够得到以下所示的作用效果。

在CGW13中，通过以更新方法为单位请求下载处理、安装处理以及激活处理的执行，使下载处理、安装处理以及激活处理以更新方法为单位来执行。在以不同的更新方法来更新多个更新对象ECU19的软件时，能够避免同时执行多个更新方法的情况、以不适当的顺序执行多个更新方法的情况。由此，能够避免以不希望的组合更新软件的情况，能够适当地更新软件，并能够担保安全安心的软件更新。

在CGW13中，由于以更新方法为单位来设置更新主机36～38，因此通过将软件更新的控制集中在更新主机36～38，能够简化软件结构，并且适当地确保系统的品质保证。

在CGW13中，由于利用规格数据来设定执行请求的发送对象以及发送顺序，因此能够利用规格数据容易地切换软件更新的内容，无需分别独立地准备应用于各种系统的CGW13，能够实现产品编号的削减。

在CGW13中，由于以判定为是能够执行下载处理、安装处理以及激活处理的状态为条件，并发送该是能够执行的状态的处理的执行请求，因此能够担保下载处理、安装处理以及激活处理的执行。

在CGW13中，由于若接收到来自下载处理、安装处理、激活处理的用户的同意结果，则将该接收到的同意结果发送至中心装置3，因此能够由中心装置3管理来自下载处理、安装处理、激活处理的用户的同意结果。

在CGW13中，由于若接收下载处理完成通知、安装处理完成通知、激活处理完成通知，则将该已经接收到的处理完成通知发送至中心装置3，因此能够由中心装置3管理下载处理、安装处理、激活处理的完成。

在CGW13中，由于若来自整体管理部34的执行请求的重发条件成立，则重发执行请求，因此在尽管整体管理部34发送了执行请求但由于一些理由未执行处理的情况下，能够适当地应对。

在CGW13中，由于在后续处理的优先度比执行中处理的优先度高的情况下，中断执行中处理，并发送后续处理的执行请求，在完成后续处理后请求该已经中断的处理的重新开始，因此在产生了法规等优先度较高的处理请求的情况下，能够适当地应对。

本公开以实施例为依据进行了描述，但应理解为并不限定于该实施例、结构。本公开也包含各种变形例、等同范围内的变形。此外，各种组合、方式、进一步仅包含它们中的一个要素、一个以上、或者一个以下的其他组合、方式也纳入到本公开的范畴、思想范围内。

例示出了通过设置三个更新主机36～38，来管理三种系统的ECU19的更新处理的结构，但也可以是通过设置两个以下、四个以上的更新主机，来管理两种以下、四种以上的系统的ECU19的更新处理的结构。即，也可以是通过设置一个更新主机，来管理一种系统的ECU19的更新处理的结构。

例示出了将激活执行请求同时发送至第一更新主机36、第二更新主机37、第三更新主机38的结构，但也可以是将激活执行请求在不同的时机发送至第一更新主机36、第二更新主机37、第三更新主机38的结构。

例示出了在整体管理部34中，若判定为接收到规格数据，则参照该规格数据来决定执行请求的发送对象以及发送顺序的结构，但也可以仅决定执行请求的最初的发送对象，每当接收处理完成通知，就决定执行请求的下一个发送对象。

例示出了DCM12下载来自中心装置3的数据包数据来获取更新数据的结构，但也可以是通过更新对象ECU19具有下载器35的功能，而更新对象ECU19直接下载来自中心装置3的数据包数据来获取更新数据的结构。

在各个处理中不需要下载同意、安装同意以及激活同意。例如，也可以通过一次同意来实施安装同意和激活同意。

本公开所记载的控制部及其模式可以由专用计算机来实现，该专用计算机通过构成被编程为执行由计算机程序具体化而成的一个或多个功能的处理器以及存储器来提供。或者，本公开所记载的控制部及其模式也可以由专用计算机来实现，该专用计算机通过由一个以上的专用硬件逻辑电路构成处理器来提供。或者，本公开所记载的控制部及其模式也可以由一个以上的专用计算机来实现，该一个以上的专用计算机通过被编程为执行一个或多个功能的处理器和存储器以及由一个以上的硬件逻辑电路构成的处理器的组合构成。另外，计算机程序也可以作为由计算机执行的指令，存储于计算机可读取的非过渡有形记录介质中。

Claims (11)

1.一种车辆用电子控制装置，具备：

第一执行指示部(35)，对执行下载处理的下载处理执行部指示执行上述下载处理，其中，上述下载处理是从外部下载更新数据的处理；

第二执行指示部(36～38)，对执行安装处理和激活处理的更新对象节点指示执行上述安装处理以及执行上述激活处理，其中，上述安装处理是安装更新数据并生成更新后的软件的处理，上述激活处理是使更新后的软件有效的处理；以及

执行请求部(34b)，以更新方法为单位对上述第一执行指示部或者上述第二执行指示部发送执行请求，以更新方法为单位请求上述下载处理、上述安装处理以及上述激活处理中的任意一个处理的执行。

2.根据权利要求1所述的车辆用电子控制装置，其中，

具备规格数据获取部(34a)，上述规格数据获取部(34a)从外部获取规格数据，

上述执行请求部基于上述规格数据来决定上述执行请求的发送对象以及发送顺序。

3.根据权利要求2所述的车辆用电子控制装置，其中，

上述执行请求部将上述下载处理、上述安装处理以及上述激活处理作为对象，在请求上述下载处理的执行之前，决定上述执行请求的发送对象以及发送顺序。

4.根据权利要求2所述的车辆用电子控制装置，其中，

上述执行请求部将上述下载处理、上述安装处理以及上述激活处理作为对象，每当完成任意一个处理，就决定上述执行请求的下一个发送对象。

5.根据权利要求1～4中任一项所述的车辆用电子控制装置，其中，

具备状态判定部(34c)，上述状态判定部(34c)判定状态，

上述执行请求部以由上述状态判定部判定为是能够执行上述下载处理、上述安装处理以及上述激活处理的状态为条件，请求执行是能够执行的状态的处理。

6.根据权利要求1～5中任一项所述的车辆用电子控制装置，其中，

同意结果接收部(34d)，接收来自上述下载处理、上述安装处理、上述激活处理中的任意一个处理所涉及的用户的同意结果；以及

同意结果发送部(34e)，若通过上述同意结果接收部接收到任意的同意结果，则将接收到的同意结果发送至外部。

7.根据权利要求1～6中任一项所述的车辆用电子控制装置，其中，

上述第一执行指示部若确定上述下载处理完成，则发送下载处理完成通知，

上述第二执行指示部若确定上述安装处理完成，则发送安装处理完成通知，若确定上述激活处理完成，则发送激活处理完成通知，

上述车辆用电子控制装置具备：

处理完成通知接收部(34f)，接收上述下载处理完成通知、上述安装处理完成通知、上述激活处理完成通知中的任意一个；以及

处理完成通知发送部(34e)，若通过上述处理完成通知接收部接收任意一个处理完成通知，则将该接收到的处理完成通知发送至外部。

8.根据权利要求1～7中任一项所述的车辆用电子控制装置，其中，

上述执行请求部在以更新方法为单位对上述第一执行指示部或者上述第二执行指示部发送执行请求后，若未执行上述下载处理、上述安装处理以及上述激活处理中的任意一个处理而执行请求的重发条件成立，则重发执行请求。

9.根据权利要求1～8中任一项所述的车辆用电子控制装置，其中，

在后续处理的优先度比执行中处理的优先度高的情况下，上述执行请求部中断上述执行中处理，并发送上述后续处理的执行请求，在完成上述后续处理后请求已经中断的处理的重新开始。

10.一种更新程序，

车辆用电子控制装置(13)具备：

第一执行指示部(35)，对执行下载处理的下载处理执行部指示执行上述下载处理，其中，上述下载处理是从外部下载更新数据的处理；

第二执行指示部(36～38)，对执行安装处理和激活处理的更新对象节点指示执行上述安装处理以及执行上述激活处理，其中，上述安装处理是安装更新数据并生成更新后的软件的处理，上述激活处理是使更新后的软件有效的处理，

上述更新程序使车辆用电子控制装置(13)的控制部(33)执行以下的执行请求步骤：即、

以更新方法为单位对上述第一执行指示部或者上述第二执行指示部发送执行请求，以更新方法为单位请求上述下载处理、上述安装处理以及上述激活处理中的任意一个处理的执行。

11.一种数据结构，是从外部分发给车辆用电子控制装置，且包含在上述车辆用电子控制装置更新更新对象节点的软件时所需的信息的规格数据的数据结构，

上述数据结构包含能够确定以更新方法为单位请求下载处理、安装处理、激活处理中的任意一个处理的执行时的执行请求的发送对象以及发送顺序的信息，其中，在上述下载处理中从外部下载更新数据，在上述安装处理中将更新数据安装于更新对象节点并生成更新后的软件，在上述激活处理中使更新后的软件有效。