中心装置、规格数据的生成方法以及规格数据生成用程序

摘要

本发明公开中心装置、规格数据的生成方法以及规格数据生成用程序，在中心装置(3)的ECU重编程数据DB(204)存储有搭载于车辆的多个ECU(19)中成为更新应用程序的对象的ECU(19)的更新程序的数据。在结构信息DB(208)存储有对多个ECU(19)各自的“ECU ID”以及存储于ECU(19)的应用程序的“ECU SW ID”等车辆相关信息和车辆的种类。在ECU元数据DB(205)存储有改写对象ECU(19)的属性以及与更新数据相关的更新数据相关信息。规格数据生成部(201)基于结构信息DB(208)以及ECU元数据DB(205)所存储的信息将与写入到对象ECU(19)的更新数据一起发送到车辆的规格数据生成为包含对象ECU(19)的种类、属性、更新数据相关信息、以及表示与数据更新相关的改写环境的信息。

说明书

相关申请的交叉引用

本申请主张于2018年8月10日申请的日本申请号2018－151414号、以及于2019年7月12日申请的日本申请号2019－129947号的优先权，并在此引用其全部内容。

技术领域

本公开涉及管理写入到搭载于车辆的多个电子控制装置的数据的中心装置、生成为了选择性地对多个电子控制装置更新数据所使用的规格数据的方法以及程序。

背景技术

近年来，随着驾驶支援功能、自动驾驶功能等车辆控制的多样化，安装于车辆的电子控制装置(以下，称为ECU(Electronic Control Unit：电子控制单元))的车辆控制、诊断等的应用程序的规模增大。另外，随着基于功能改善等的版本升级，改写(重编程)ECU的应用程序的机会也增加。另一方面，随着通信网络的发展等，车联网的技术也普及。由于这样的情况，例如在专利文献1公开了通过OTA(Over The Air：空中下载技术)从中心向车载装置分发ECU的更新程序，并在车辆侧改写更新程序的技术。

专利文献1：日本专利第4221261号公报

如上述那样，虽然在车辆侧改写通过OTA分发的更新程序的方式考虑到各种形式，但在市场中参与的是车辆的一般用户。因此，为了使车辆侧的装置能够进行灵活的控制，期望中心分发需要的信息。

发明内容

本公开是鉴于上述情况而完成的，其目的在于提供能够生成记载有为了在车辆侧改写更新程序所需要的信息的规格数据的中心装置、规格数据的生成方法以及规格数据生成用程序。

根据本公开的中心装置，在更新数据存储部存储有搭载于车辆的多个电子控制装置中成为更新数据的对象的对象装置的更新数据。在车辆信息存储部存储有与对多个电子控制装置各自的装置识别以及存储于该装置的数据的识别相关的车辆相关信息、和车辆的种类。在装置相关信息存储部存储有对象装置的属性以及与更新数据相关的更新数据相关信息。

而且，规格数据生成部基于车辆信息存储部以及装置相关信息存储部所存储的信息，将与写入对象装置的更新数据一起发送到车辆的规格数据生成为包含对象装置的装置种类、对象装置的属性、对象装置的更新数据相关信息、以及表示与对象装置的数据更新相关的改写环境的信息。由此，车辆侧的装置能够通过接收更新数据以及规格数据，基于该规格数据适当地选择对象装置写入更新数据。

附图说明

一边参照附图一边通过下述的详细的记述，本发明的上述目的和其他的目的、特征、优点变得更明确。该附图为如下。

图1是表示在第一实施方式中车辆信息通信系统的整体结构的图。

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

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

图4是表示电源线的连接形式的图。

图5是表示将重编数据和分发规格数据打包的形式的图。

图6是表示将分发包拆包的形式的图。

图7是将中心装置中的主要涉及服务器的各功能的部分框图化而表示的图。

图8是表示中心装置中的处理的流程的示意图。

图9是表示登记在结构信息DB中的车辆的结构信息的一例的图。

图10是表示登记在ECU重配置数据DB中的程序、数据的一例的图。

图11是表示登记在ECU元数据DB中的规格数据的一例的图。

图12是表示登记在单车信息DB中的车辆的结构信息的一例的图。

图13是表示登记在包DB中的分发包数据的一例的图。

图14是表示登记在活动DB中的活动数据的一例的图。

图15是表示生成登记在ECU重配置数据DB中的程序、数据的处理的流程图。

图16是表示生成登记在ECU元数据DB中的规格数据的一例的处理的流程图。

图17是表示规格数据的一例的图。

图18是表示总线负荷表的一例的图。

图19是表示生成登记在包DB中的分发包的处理的流程图。

图20是示意性表示包文件的内容的图。

图21是表示在第二实施方式中，在中心装置与车辆侧系统之间执行的处理步骤的时序图。

图22是表示中心装置进行的处理的流程图。

图23是示意性表示在图22所示的流程图的步骤D6、D7中进行的处理内容的图。

图23A是表示从车辆侧系统向中心装置发送散列值的情况下的处理的流程图。

图24是表示在第三实施方式中，在中心装置与车辆侧系统之间执行的处理步骤的时序图。

图25是表示中心装置进行的处理的流程图。

图26是表示中心装置通过SMS而向EV车和输送车分别进行通知的状态的时序图。

图27是表示在第四实施方式中，在中心装置与车辆侧系统之间执行的处理步骤的时序图。

图28是示意性表示在第五实施方式中，在供应商、中心装置、车辆侧系统间进行的处理的图。

图29是表示在供应商、中心装置、车辆侧系统间进行的处理步骤的时序图(其一)。

图30是表示在供应商、中心装置、车辆侧系统间进行的处理步骤的时序图(其二)。

图31是表示在供应商、中心装置、车辆侧系统间进行的处理步骤的时序图(其三)。

图32是第一实施方式的变形(其一)，是表示使多个包与一个活动对应的情况下的包DB的数据格式的图。

图33是表示使多个包与一个活动对应的情况下的活动DB的数据格式的图。

图34是按照每个组生成规格数据的情况下的相当于图16的图

图35是按照每个组生成分发包的情况下的相当于图19的图

图36是第一实施方式的变形(其二)，是表示包生成工具的处理内容的图。

图37是表示第六实施方式的整体结构的图。

图38是表示CGW的电结构的图。

图39是表示DCM的电结构的图。

图40是表示ECU的电结构的图。

图41是表示电源线的连接形式的图。

图42是表示将重编数据和分发规格数据打包的形式的图。

图43是表示DCM用的改写规格数据的图。

图44是表示CGW用的改写规格数据的图。

图45是表示分发规格数据的图。

图46是表示将分发包拆包的形式的图。

图47是表示嵌入型的1面独立存储器的通常动作时的形式的图。

图48是表示嵌入型的1面独立存储器的改写动作时的形式的图。

图49是表示下载型的1面独立存储器的通常动作时的形式的图。

图50是表示下载型的1面独立存储器的改写动作时的形式的图。

图51是表示嵌入型的1面挂起挂起存储器的通常动作时的形式的图。

图52是表示嵌入型的1面挂起挂起存储器的改写动作时的形式的图。

图53是表示下载型的1面挂起挂起存储器的通常动作时的形式的图。

图54是表示下载型的1面挂起挂起存储器的改写动作时的形式的图。

图55是表示嵌入型的2面存储器的通常动作时的形式的图。

图56是表示嵌入型的2面存储器的改写动作时的形式的图。

图57是表示下载型的2面存储器的通常动作时的形式的图。

图58是表示下载型的2面存储器的改写动作时的形式的图。

图59是表示改写应用程序的形式的图。

图60是表示改写应用程序的形式的图。

图61是表示改写应用程序的形式的图。

图62是表示通过电源控制来改写应用程序的形式的时序图。

图63是表示通过电源控制来改写应用程序的形式的时序图。

图64是表示通过电源自保持来改写应用程序的形式的时序图。

图65是表示通过电源自保持来改写应用程序的形式的时序图。

图66是表示阶段的图。

图67是表示通常时的画面的图。

图68是表示活动通知产生时的画面的图。

图69是表示活动通知时的画面的图。

图70是表示下载同意时的画面的图。

图71是表示下载同意时的画面的图。

图72是表示下载执行中的画面的图。

图73是表示下载执行中的画面的图。

图74是表示下载完成时的画面的图。

图75是表示安装同意时的画面的图。

图76是表示安装同意时的画面的图。

图77是表示安装执行中的画面的图。

图78是表示安装执行中的画面的图。

图79是表示激活同意时的画面的图。

图80是表示IG接通时的画面的图。

图81是表示确认操作时的画面的图。

图82是表示确认操作时的画面的图。

图83是中心装置的功能框图。

图84是DCM的功能框图。

图85是CGW的功能框图。

图86是CGW的功能框图。

图87是ECU的功能框图。

图88是车载显示器的功能框图。

图89是分发包的发送判定部的功能框图。

图90是表示分发包的发送判定处理的流程图。

图91是分发包的下载判定部的功能框图。

图92是表示分发包的下载判定处理的流程图。

图93是写入数据的传输判定部的功能框图。

图94是表示写入数据的传输判定处理的流程图。

图95是写入数据的获取判定部的功能框图。

图96是表示写入数据的获取判定处理的流程图。

图97是安装的指示判定部的功能框图。

图98是表示安装的指示判定处理的流程图。

图99是表示指示安装的形式的图。

图100是表示指示安装的形式的图。

图101是表示生成随机数值的形式的图。

图102是安全访问密钥的管理部的功能框图。

图103是表示安全访问密钥的生成处理的流程图。

图104是表示生成安全访问密钥的形式的图。

图105是表示安全访问密钥的消除处理的流程图。

图106是表示与写入数据的验证相关联的处理的流程的图。

图107是写入数据的验证部的功能框图。

图108是表示写入数据的验证处理的流程图。

图109是表示对与写入数据的验证相关联的处理进行了分散的形式的图。

图110是表示对与写入数据的验证相关联的处理进行了分散的形式的图。

图111是表示对与写入数据的验证相关联的处理进行了分散的形式的图。

图112是表示对与写入数据的验证相关联的处理进行了分散的形式的图。

图113是表示写入数据的验证和应用程序的改写的流程的图。

图114是表示写入数据的验证和应用程序的改写的流程的图。

图115是数据储存面信息的发送控制部的功能框图。

图116是表示数据储存面信息的发送控制处理的流程图。

图117是表示通知2面改写信息的形式的时序图。

图118是非改写对象的电源管理部的功能框图。

图119是表示非改写对象的电源管理处理的流程图。

图120是表示启动状态、停止状态、休眠状态的转变的图。

图121是表示启动状态、停止状态、休眠状态的转变的图。

图122是表示电源线的连接形式的图。

图123是表示电池余量的监视处理的流程图。

图124是文件的传输控制部的功能框图。

图125是表示文件的传输控制处理的流程图。

图126是表示收发文件的形式的图。

图127是表示收发文件的形式的图。

图128是表示分割文件和写入文件的图。

图129是表示CGW向DCM发送传输请求的形式的图。

图130是表示CGW向DCM发送传输请求的形式的图。

图131是表示CGW向改写对象ECU分发写入数据的形式的图。

图132是表示CGW向改写对象ECU分发写入数据的形式的图。

图133是表示CGW向改写对象ECU分发写入数据的形式的图。

图134是表示ECU的连接形式的图。

图135是写入数据的分发控制部的功能框图。

图136是表示总线负荷表的图。

图137是表示改写对象ECU所属表的图。

图138是表示写入数据的分发控制处理的流程图。

图139是表示分发写入数据的形式的图。

图140是表示分发写入数据的形式的图。

图141是表示对车辆在行驶中的写入数据进行分发的形式的图。

图142是表示分发驻车中的写入数据的形式的图。

图143是表示写入数据的分发量的图。

图144是表示写入数据的分发量的图。

图145是激活请求的指示部的功能框图。

图146是表示激活请求的指示处理的流程图。

图147是表示指示激活请求的形式的图。

图148是激活的执行控制部的功能框图。

图149是表示改写处理的流程图。

图150是表示激活的执行控制处理的流程图。

图151是改写对象的分组部的功能框图。

图152是表示改写对象的组管理处理的流程图。

图153是表示改写对象的组管理处理的流程图。

图154是表示对改写对象进行分组的形式的图。

图155是回滚的执行控制部的功能框图。

图156是表示回滚方法的确定处理的流程图。

图157是表示取消请求的判定处理的流程图。

图158是表示取消请求的判定处理的流程图。

图159是表示取消请求的判定处理的流程图。

图160是表示取消请求的判定处理的流程图。

图161是表示取消请求的判定处理的流程图。

图162是表示执行回滚的形式的图。

图163是表示执行回滚的形式的图。

图164是表示执行回滚的形式的图。

图165是表示执行回滚的形式的图。

图166是表示执行回滚的形式的图。

图167是改写进展状况的显示控制部的功能框图。

图168是表示改写进展状况的显示控制处理的流程图。

图169是表示改写进展状况的显示控制处理的流程图。

图170是表示改写进展状况的画面的图。

图171是表示改写进展状况的画面的图。

图172是表示改写进展状况的画面的图。

图173是表示改写进展状况的画面的图。

图174是表示改写进展状况的画面的图。

图175是表示进展图表显示的转变的图。

图176是表示进展图表显示的转变的图。

图177是表示进展图表显示的转变的图。

图178是表示进展图表显示的转变的图。

图179是表示改写进展状况的画面的图。

图180是差分数据的整合性判定部的功能框图。

图181是表示差分数据的整合性判定处理的流程图。

图182是表示判定差分数据的整合性的形式的图。

图183是表示判定差分数据的整合性的形式的图。

图184是改写的执行控制部的功能框图。

图185是表示通常动作处理的流程图。

图186是表示改写动作处理的流程图。

图187是表示信息通知处理的流程图。

图188是表示改写程序的验证处理的流程图。

图189是表示发送识别信息和写入数据的形式的图。

图190是表示发送识别信息和写入数据的形式的图。

图191是表示安装指示处理的流程图。

图192是会话的确立部的功能框图。

图193是表示程序的结构的图。

图194是表示状态转变的图。

图195是表示状态转变的图。

图196是表示状态转变的图。

图197是表示会话的调停的图。

图198是表示会话的调停的图。

图199是表示第一状态的状态转变管理处理的流程图。

图200是表示第一状态的状态转变管理处理的流程图。

图201是表示第一状态的状态转变管理处理的流程图。

图202是表示第二状态的状态转变管理处理的流程图。

图203是表示第二状态的状态转变管理处理的流程图。

图204是表示程序的结构的图。

图205是表示状态转变的图。

图206是重试点的确定部的功能框图。

图207是表示闪存的结构的图。

图208是表示处理标志的设定处理的流程图。

图209是表示处理标志的判定处理的流程图。

图210是表示处理标志的判定处理的流程图。

图211是进展状态的同步控制部的功能框图。

图212是进展状态的同步控制部的功能框图。

图213是表示发送接收进展状态信号的形式的图。

图214是表示进展状态的同步控制处理的流程图。

图215是表示进展状态的同步控制处理的流程图。

图216是表示进展状态的显示处理的流程图。

图217是显示控制信息的发送控制部的功能框图。

图218是表示显示控制信息的发送控制处理的流程图。

图219是显示控制信息的接收控制部的功能框图。

图220是表示显示控制信息的接收控制处理的流程图。

图221是表示分发规格数据中包含的信息的图。

图222是进展显示的画面显示控制部的功能框图。

图223是表示改写规格数据的图。

图224是表示菜单选择时的画面的图。

图225是表示用户选择时的画面的图。

图226是表示用户登记时的画面的图。

图227是表示进展显示的画面显示控制处理的流程图。

图228是表示进展显示的画面显示控制处理的流程图。

图229是表示消息帧的图。

图230是表示激活同意时的画面的图。

图231是表示项目的显示有无的设定的图。

图232是表示项目的显示有无的设定的图。

图233是表示激活同意时的画面的图。

图234是表示数据通信的形式的图。

图235是表示活动通知时的消息帧的图。

图236是表示下载同意时的消息帧的图。

图237是表示安装同意时的消息帧的图。

图238是表示激活同意时的消息帧的图。

图239是表示画面的转变的图。

图240是表示活动通知产生时的画面的图。

图241是表示下载同意时的画面的图。

图242是表示下载同意时的画面的图。

图243是表示下载执行中的画面的图。

图244是表示下载完成时的画面的图。

图245是表示安装同意时的画面的图。

图246是表示激活同意时的画面的图。

图247是程序更新的报告控制部的功能框图。

图248是表示程序更新的报告控制处理的流程图。

图249是表示指示器的报告形式的图。

图250是表示改写对象为2面存储器的情况下的报告形式的转变的图。

图251是表示改写对象为1面挂起挂起存储器的情况下的报告形式的转变的图。

图252是表示改写对象为1面独立存储器的情况下的报告形式的转变的图。

图253是表示连接形式的图。

图254是CGW中的电源自保持的执行控制部的功能模块。

图255是ECU中的电源自保持的执行控制部的功能模块。

图256是表示CGW中的电源自保持的执行控制处理的流程图。

图257是表示ECU中的电源自保持的执行控制处理的流程图。

图258是表示需要电源自保持的期间的图。

图259是表示改写应用程序的形式的整体时序图。

图260是表示改写应用程序的形式的整体时序图。

图261是表示改写应用程序的形式的整体时序图。

图262是表示改写应用程序的形式的整体时序图。

图263是表示改写应用程序的形式的整体时序图。

图264是表示改写应用程序的形式的整体时序图。

图265是表示改写应用程序的形式的整体时序图。

图266是表示改写应用程序的形式的整体时序图。

图267是表示改写应用程序的形式的整体时序图。

图268是表示改写应用程序的形式的整体时序图。

图269是表示改写应用程序的形式的整体时序图。

具体实施方式

(第一实施方式)

以下，参照图1至图20对本发明的第一实施方式进行说明。车辆用程序改写系统是能够通过OTA来改写搭载于车辆的ECU的车辆控制、诊断等应用程序的系统。如图1所示，车辆用程序改写系统1具有通信网络2侧的中心装置3、车辆侧的车辆侧系统4、以及显示终端5。通信网络2例如包含基于4G线路等的移动体通信网络、因特网、WiFi(WirelessFidelity：无线保真)(注册商标)等而构成。

显示终端5是具有受理来自用户的操作输入的功能、显示各种画面的功能的终端，例如是用户能够携带的智能手机或平板电脑等便携终端6、配置在车室内的兼作导航功能的显示器、仪表显示器等车载显示器7。便携终端6只要在移动体通信网络的通信圈内，则能够与通信网络2连接。车载显示器7与车辆侧系统4连接。

如果用户在车室外且在移动体通信网络的通信圈内，则能够一边利用便携终端6确认与应用程序的改写相关联的各种画面一边进行操作输入，能够进行与应用程序的改写相关联的手续。用户能够在车室内一边利用车载显示器7确认与应用程序的改写相关联的各种画面一边进行操作输入，能够进行与应用程序的改写相关联的手续。即，用户能够在车室外和车室内分开使用便携终端6和车载显示器7，进行与应用程序的改写相关联的手续。

中心装置3在车辆用程序改写系统1中总括通信网络2侧的OTA的功能，作为OTA中心发挥功能。中心装置3具有文件服务器8、网络服务器9和管理服务器10，各服务器8～10构成为能够相互进行数据通信。

文件服务器8具备从中心装置3向车辆侧系统4发送的应用程序的管理功能，是对从应用程序的提供企业即供应商等提供的ECU程序及其附带的信息、从OEM(OriginalEquipment Manufacturer：原始设备制造商)提供的分发规格数据、从车辆侧系统4获取的车辆状态等进行管理的服务器。文件服务器8能够经由通信网络2在与车辆侧系统4之间进行数据通信，若产生分发包的下载请求，则向车辆侧系统4发送将重编数据和分发规格数据打包后的分发包。网络服务器9是管理网络信息的服务器，对便携终端6提供与应用程序的改写相关联的各种画面。管理服务器10对登记在应用程序的改写的服务中的用户的个人信息等进行管理，并对每个车辆的应用程序的改写历史等进行管理。

车辆侧系统4具有主装置11。主装置11具有DCM12和CGW13，DCM12与CGW13经由第一总线14而连接成能够进行数据通信。DCM12是在与中心装置3之间经由通信网络2进行数据通信的车载通信机，若从文件服务器8下载分发包，则从该分发包中提取写入数据并向CGW13传输。

CGW13是具有数据中继功能的车辆用网关装置，若从DCM12获取写入数据，则向改写应用程序的改写对象ECU分发该写入数据。主装置11在车辆用程序改写系统1中总括车辆侧的OTA的功能，作为OTA主机发挥功能。另外，在图1中，例示DCM12和车载显示器7与同一第一总线14连接的结构，但也可以是DCM12和车载显示器7与不同的总线连接的结构。

除了第一总线14之外，第二总线15、第三总线16、第四总线17、第五总线18也作为车内侧的总线而与CGW13连接，经由总线15～17连接有各种ECU19，并且经由总线18连接有电源管理ECU20。

第二总线15例如是车身系统网络的总线。与第二总线15连接的ECU19例如是控制车门的锁定/解锁的车门ECU、控制仪表显示的仪表ECU、控制空调的驱动的空调ECU、控制车窗的开闭的车窗ECU等进行车身系统的控制的ECU。第三总线16例如是行驶系统网络的总线。与第三总线16连接的ECU19例如是控制发动机的驱动的发动机ECU、控制制动器的驱动的制动器ECU、控制自动变速器的驱动的ECT(ETC(Electronic Toll Collection System：电子收费系统、注册商标))ECU、控制动力转向的驱动的动力转向ECU等进行行驶系统的控制的ECU。

第四总线17例如是多媒体系统网络的总线。与第四总线17连接的ECU19例如是用于控制导航系统的导航ECU、控制电子式收费系统、即ECT系统的ETCECU等进行多媒体系统的控制的ECU。总线15～17也可以是车身系统网络的总线、行驶系统网络的总线、多媒体系统网络的总线以外的系统的总线。另外，总线的根数、ECU19的个数不限于例示的结构。

电源管理ECU20是具有进行DCM12、CGW13、各种ECU19等的电源管理的功能的ECU。

第六总线21作为车外侧的总线与CGW13连接。可装卸地连接有工具23的DLC(DataLink Coupler：数据链接转换器)连接器22与第六总线21连接。车内侧的总线14～18和车外侧的总线21例如由CAN(Controller Area Network：控制器区域网络、注册商标)总线构成，CGW13根据CAN的数据通信标准、诊断通信标准(UDS：ISO14229)而在与DCM12、各种ECU19、工具23之间进行数据通信。另外，DCM12与CGW13也可以通过以太网连接，DLC连接器22与CGW13也可以通过以太网连接。

改写对象ECU19若从CGW13接收写入数据，则将该写入数据写入闪存而改写应用程序。在上述的结构中，CGW13作为如下的重编主机发挥功能，若从改写对象ECU19接收写入数据的获取请求，则向改写对象ECU19分发写入数据。改写对象ECU19作为如下的重编从机发挥功能，若从CGW13接收写入数据，则将该写入数据写入闪存而改写应用程序。

作为改写应用程序的形式，存在利用有线改写的形式和利用无线改写的形式。在利用有线改写应用程序的形式中，工具23与DLC连接器22连接，工具23将写入数据传输到CGW13。CGW13将从工具23传输来的写入数据中继或者分发到改写对象ECU19。在利用无线改写应用程序的形式中，像上述那样，DCM12若从文件服务器8下载分发包，则从该分发包中提取写入数据，并将该写入数据传输到CGW13。

如图2所示，作为电功能模块，CGW13具有微型计算机(以下，称为微机)24、数据传输电路25、电源电路26和电源检测电路27。微机24具有：CPU(Central Processing Unit：中央处理单元)24a、ROM(Read Only Memory：只读存储器)24b、RAM(Random Access Memory：随机存取存储器)24c、以及闪存24d。微机24执行在非迁移实体存储介质中储存的各种控制程序而进行各种处理，控制CGW13的动作。

数据传输电路25控制与总线14～18、21之间的依据CAN的数据通信标准、诊断通信标准的数据通信。电源电路26输入电池电源(以下，称为+B电源)、辅助电源(以下，称为ACC电源)和点火电源(以下，称为IG电源)。电源检测电路27检测由电源电路26输入的+B电源的电压值、ACC电源的电压值、IG电源的电压值，将这些检测出的电压值与规定的电压阈值进行比较，将该比较结果输出到微机24。微机24根据从电源检测电路27输入的比较结果，判定从外部供给到CGW13的+B电源、ACC电源、IG电源是正常还是异常。

如图3所示，作为电功能模块，ECU19具有微机28、数据传输电路29、电源电路30、以及电源检测电路31。微机28具有CPU28a、ROM28b、RAM28c、以及闪存28d。微机28执行在非迁移实体存储介质中储存的各种控制程序而进行各种处理，控制ECU19的动作。

数据传输电路29控制与总线15～17之间的依据CAN的数据通信标准的数据通信。电源电路30输入+B电源、ACC电源、IG电源。电源检测电路31检测由电源电路30输入的+B电源的电压值、ACC电源的电压值、IG电源的电压值，将这些检测出的电压值与规定的电压阈值进行比较，并将该比较结果输出到微机28。微机28根据从电源检测电路27输入的比较结果，判定从外部供给到ECU19的+B电源、ACC电源、IG电源是正常还是异常。另外，ECU19所连接的例如传感器、致动器等负荷不同，基本上是同等结构。另外，DCM12、车载显示器7和电源管理ECU的基本结构也与图3所示的ECU19相同。

如图4所示，电源管理ECU20、CGW13、ECU19与+B电源线32、ACC电源线33、IG电源线34连接。+B电源线32与车辆电池35的正极连接。ACC电源线33经由ACC开关36而与车辆电池35的正极连接。若用户进行ACC操作，则ACC开关36从断开切换到接通，车辆电池35的输出电压被施加给ACC电源线33。所谓ACC操作，例如如果是将钥匙插入到插入口的类型的车辆，则是将钥匙插入到插入口而从“OFF”位置转动到“ACC”位置的操作，如果是按下开始按钮的类型的车辆，则是将开始按钮按下一次的操作。

IG电源线34经由IG开关37与车辆电池35的正极连接。若用户进行IG操作，则IG开关37从断开切换到接通，车辆电池35的输出电压被施加给IG电源线34。所谓IG操作，例如如果是将钥匙插入到插入口的类型的车辆，则是将钥匙插入到插入口而从“OFF”位置转动到“ON”位置的操作，如果是按下开始按钮的类型的车辆，则是将开始按钮按下二次的操作。车辆电池35的负极接地。

在ACC开关36和IG开关37双方断开时，仅向车辆侧系统4供给+B电源。将仅向车辆侧系统4供给+B电源的状态称为+B电源状态。在ACC开关36接通、IG开关37断开时，向车辆侧系统4供给ACC电源和+B电源。将向车辆侧系统4供给ACC电源和+B电源的状态称为ACC电源状态。在ACC开关36和IG开关37双方接通时，向车辆侧系统4供给+B电源、ACC电源和IG电源。将向车辆侧系统4供给+B电源、ACC电源和IG电源的状态称为IG电源状态。

ECU19的启动条件根据电源状态而不同，区分为在+B电源状态下启动的+B系统ECU、在ACC电源状态下启动的ACC系统ECU、在IG电源状态下启动的IG系统ECU。例如在车辆被盗取等的用途中驱动的ECU19是+B系统ECU。例如在音响等非行驶系统的用途中驱动的ECU19是ACC系统ECU。例如在发动机控制等行驶系统的用途中进行驱动的ECU19是IG系统ECU。

CGW13通过对处于休眠状态的ECU19发送启动请求，而使该启动请求的发送目的地的ECU19从休眠状态转移至启动状态。另外，CGW13通过对处于启动状态的ECU19发送休眠请求，而使该休眠请求的发送目的地的ECU19从启动状态转移至休眠状态。CGW13例如通过使发送给总线15～17的发送信号的波形不同，而从多个ECU中选择启动请求、休眠请求的发送目的地的ECU19。

电源控制电路38与ACC开关36和IG开关37并联连接。CGW13将电源控制请求发送给电源管理ECU20，使电源管理ECU20控制电源控制电路38。即，CGW13将电源启动请求作为电源控制请求而发送给电源管理ECU20，使ACC电源线33、IG电源线34与车辆电池35的正极在电源控制电路38的内部连接。在该状态下，即使ACC开关36、IG开关37断开也将ACC电源、IG电源供给到车辆侧系统4。CGW13将电源停止请求作为电源控制请求而发送给电源管理ECU20，使ACC电源线33、IG电源线34与车辆电池35的正极在电源控制电路38的内部隔断。

DCM12、CGW13、ECU19具有电源自保持功能。即，DCM12、CGW13、ECU19若在处于启动状态时车辆电源从ACC电源或者IG电源切换到+B电源，则不是在该切换之后立即从启动状态转移至休眠状态或者停止状态，而是即使在该切换之后也在规定时间内持续启动状态而自保持驱动电源。DCM12、CGW13、ECU19在车辆电源从ACC电源或者IG电源切换到+B电源之后经过了规定时间(例如几秒)后从启动状态转移至休眠状态或者停止状态。

接下来，参照图5至图6对从中心装置3向主装置11分发的分发包进行说明。在车辆用程序改写系统1中，根据从应用程序的提供企业即供应商提供的写入数据、主要从OEM提供的改写规格数据，生成重编数据。作为从供应商提供的写入数据，存在与旧应用程序和新应用程序的差分相当的差分数据、与新应用程序的整体相当的整体数据。差分数据、整体数据也可以通过公知的数据压缩技术而进行压缩。在图5中，例示了从供应商A～C提供差分数据来作为写入数据，根据从供应商A提供的ECU(ID1)的加密完毕的差分数据和认证符，从供应商B提供的ECU(ID2)的加密完毕的差分数据和认证符、从供应商C提供的ECU(ID3)的加密完毕的差分数据和认证符、从OEM提供的改写规格数据来生成重编数据的情况。针对每个写入数据赋予认证符。

另外，在图5中，表示从旧应用程序更新为新应用程序时的差分数据，但也可以构成为将用于从新应用程序回写为旧应用程序的回滚用差分数据一并包含于重编数据中。例如，在改写对象ECU19为1面存储器的情况下，在重编数据中包含回滚用差分数据。

从OEM提供的改写规格数据作为与应用程序的改写相关联的信息，包含能够确定改写对象ECU19的信息、能够确定改写对象ECU19为多个时的改写顺序的信息、能够确定后述的回滚方法的信息等，是定义DCM12、CGW13、改写对象ECU19中的与改写相关联的动作数据。改写规格数据被区分为DCM12使用的DCM用的改写规格数据、CGW13使用的CGW用的改写规格数据。在DCM用的改写规格数据中记载了与改写对象ECU19对应的文件的读出所需要的信息。如上述那样，在CGW用改写规格数据中记载了为了控制改写对象ECU19的改写所需要的信息。

DCM12若获取到DCM用的改写规格数据，则对该DCM用的改写规格数据进行解析，根据该解析结果而控制向CGW13的写入数据的传输等与改写相关联的动作。CGW13若获取到CGW用的改写规格数据，则对该CGW用的改写规格数据进行解析，根据该解析结果而控制来自DCM12的写入数据的获取、朝向改写对象ECU19的写入数据的分发等与改写相关联的动作。

在文件服务器8中登记上述的重编数据，并且登记从OEM提供的分发规格数据。从OEM提供的分发规格数据是定义与显示终端5中的各种画面的显示相关联的动作的数据。

文件服务器8若登记了重编数据和分发规格数据，则对重编数据进行加密化，生成将用于认证包的包认证符、加密完毕的重编数据、分发规格数据打包于一个文件的分发包。文件服务器8若从外部接收到分发包的下载请求，则将该分发包向DCM12发送。另外，在图5中，例示了文件服务器8生成储存了重编数据和分发规格数据的分发包，并将重编数据和分发规格数据同时向DCM12发送的情况，但也可以将重编数据和分发规格数据分别向DCM12发送。即，文件服务器8也可以先将分发规格数据向DCM12发送，之后将重编数据向DCM12发送。另外，文件服务器8也可以使重编数据和分发规格数据为作为一个文件的分发包，将分发包和包认证符向DCM12发送。

DCM12若从文件服务器8下载分发包，则验证储存于该分发包的包认证符和加密完毕的重编数据，若验证结果为正，则将加密完毕的重编数据解码。DCM12若将加密完毕的重编数据解码，则将该解码的重编数据解包，生成每个ECU的加密完毕的差分数据和认证符、DCM用的改写规格数据、CGW用的改写规格数据。在图6中，例示了生成ECU(ID1)的加密完毕的差分数据和认证符、ECU(ID2)的加密完毕的差分数据和认证符、ECU(ID3)的加密完毕的差分数据和认证符、改写规格数据的情况。

图7将中心装置3中的主要涉及服务器8～10的各功能的部分框图化而表示。另外，图8表示中心装置3关于ECU的程序更新进行的处理的概要。另外，以下有时将“数据库”表述为“DB”。如图7所示，中心装置3具备包管理部3A、结构信息管理部3B、单车信息管理部3C和活动管理部3D。包管理部3A具有规格数据生成部201、包生成部202和包分发部203、ECU重配置数据DB204、ECU元数据DB205和包DB206。结构信息管理部3B具有结构信息登记部207和结构信息DB208。

供应商使用管理服务器10的用户界面(UI)功能即输入部218和显示部219，而登记ECU个别的数据。作为ECU个别的数据，有新程序、差分数据等程序文件、程序文件的验证数据、大小、加密化方式等程序文件关联信息、以及ECU19的存储器构造等与ECU属性信息相关的数据等。程序文件存储于ECU重配置数据DB204。ECU属性信息存储于ECU元数据DB205。程序文件关联信息也可以存储于ECU重配置数据DB204，也可以存储于ECU元数据DB205。ECU重配置数据DB204是更新数据存储部的一例。另外，ECU元数据DB205是装置关联信息存储部的一例。

OEM经由结构信息登记部207，按照每个车辆型号，将正规的结构信息登记于结构信息DB208。正规的结构信息是指由公共的机关认可的车辆的结构信息。结构信息是与搭载于车辆的ECU19的硬件和软件相关的识别信息，是车辆关联信息的一例。在结构信息中还包含由多个ECU19构成的系统结构的识别信息、由多个系统构成的车辆结构的识别信息。另外，作为结构信息，也可以登记与程序的更新相关的车辆的制约信息。例如，也可以登记改写规格数据中记载的ECU的组信息、总线负荷表、与电池负荷相关的信息等。ECU元数据DB205是装置关联信息存储部的一例。另外，结构信息DB208是车辆信息存储部的一例。

规格数据生成部201参照各DB，生成改写规格数据。包生成部202生成包含改写规格数据和重编数据的分发包，并登记于包DB206。包生成部202也可以生成包含分发规格数据的分发包。包分发部203向车辆侧系统4分发所登记的分发包。分发包相当于文件。

单车信息管理部3C具有单车信息登记部209、结构信息确认部210、更新有无确认部211和SMS发送控制部212、以及单车信息DB213。单车信息登记部209将由各个车辆上传的单车信息登记于单车信息DB213。作为初始值，单车信息登记部209也可以将车辆生产或者销售时刻的单车信息登记于单车信息DB213。结构信息确认部210在进行所上传的单车信息的登记时，将单车信息与登记于结构信息DB208的同一型号车辆的结构信息进行对照。更新有无确认部211对于单车信息确认基于新程序的更新的有无、即活动的有无。在单车信息被更新的情况下，SMS发送控制部212通过SMS(Short Message Service：短消息服务)向对应的车辆发送与更新相关的消息。

活动管理部3D具备活动生成部214、活动分发部215、指示通知部216和活动DB217。OEM通过活动生成部214生成与程序更新相关的信息即活动信息，而登记于活动DB217。另外，这里的活动信息相当于上述的“分发规格数据”，主要是与在车辆侧系统4中显示的更新内容相关的信息。活动分发部215向车辆分发活动信息。指示通知部216向车辆通知与程序更新相关联地所需要的指示。在车辆侧系统4中，例如用户基于从中心装置3发送的活动信息，而判断是否进行更新程序的下载，如果需要则进行下载。

另外，各管理部3A～3D的除了各数据库之外的部分是通过计算机的硬件和软件来实现的功能。

车辆通信部222是用于在中心装置3与车辆侧系统4之间通过无线相互进行数据通信的功能模块。

以下，更详细地说明上述的处理，首先，对登记于各数据库的数据的内容进行说明。如图9所示，在结构信息DB208中，作为一例，登记以下的数据。“车辆型号”表示车型。“Vehicle SW ID”是针对车辆整体的软件ID，相当于车辆软件ID。对各车辆仅赋予一个“Vehicle SW ID”，伴随着任意一个以上的ECU的应用程序的版本被更新，而“Vehicle SWID”被更新。若将搭载于各车辆的多个ECU19的组设为“系统”，则“Sys ID”是该系统的ID。

例如，在图1中，车身系统ECU19的组为车身系统，行驶系统ECU19的组为行驶系统。伴随着构成系统的任意一个以上的ECU的应用程序的版本被更新，而“Sys ID”被更新。“ECUID”是表示各ECU的种类的装置识别用的ID。“ECU SW ID”是针对各ECU的软件ID，相当于ECU软件ID。这里，为了方便，在“ECU ID”上附加了软件的版本而表示。伴随着该ECU的应用程序的版本被更新，而“ECU SW ID”被更新。另外，即使同一“ECU ID”是同一程序版本，在硬件结构不同的情况下，也使用不同的“ECU SW ID”。即，“ECU SW ID”也是表示ECU的产品号的信息。

在图9中，表示与“车辆型号”＝“aaa”的车辆相关的结构信息。例示了搭载于车辆的ECU19中的、自动驾驶ECU(ADS)、发动机ECU(ENG)、制动器ECU(BRK)以及电动动力转向ECU(EPS)。

例如，相对于“Vehicle SW ID”＝“0001”的“ECU SW ID”为“ads_001”、“eng_010”、“brk_001”、“eps_010”、“Vehicle SW ID”＝“0002”的“ECU SW ID”为“ads_002”、“eng_010”、“brk_005”、“eps_011”，更新了3个软件版本。与之相伴，“Sys ID”＝“SA01”被更新为“SA02”，“Sys ID”＝“SA02”被更新为“SA03”。这样，在结构信息DB208中，在车辆的生产或者销售时刻登记初始值，然后伴随着任意一个以上的ECU的应用程序的版本被更新，而被更新。即，结构信息DB208表示关于各车辆型号，在市场上正规存在的结构信息。

如图10所示，在ECU重配置数据DB204中，作为一例，登记以下的程序、数据。在图10中，作为搭载于某车辆型号的ECU19中的、应用程序被更新的ECU19，例示自动驾驶ECU(ADS)、制动器ECU(BRK)和电动动力转向ECU(EPS)。对于这些更新对象ECU19的最新的“ECUSW ID”，登记ECU的旧程序和新程序文件、新程序的完整性验证数据、新程序与旧程序的差分数据即更新数据文件、更新数据的完整性验证数据、同样作为差分数据的回滚数据文件、回滚数据的完整性验证数据等。完整性验证数据是对数据值应用散列函数而得的散列值。另外，在将更新数据替换为差分数据而设为新程序的整体数据时，更新数据的完整性验证数据与新程序的同数据相等。

另外，在图10中，表示关于最新的“ECU SW ID”的数据构造，但也可以构成为，在保存关于旧的“ECU SW ID”的数据的情况下，对于旧程序文件，参照一个旧的“ECU SW ID”的新程序文件。另外，各完整性验证数据也可以采用登记由供应商运算出的值的形式，也可以采用由中心装置3运算并登记的形式。

如图11所示，在ECU元数据DB205中，作为一例，登记以下所示的ECU个别的规格数据。关于最新的“ECU SW ID”，采用更新数据文件的大小、回滚数据文件的大小，在ECU19所具备的闪存28d为2面以上的结构的情况下，采用表示是A面、B面、C面等哪个面用的程序的面信息、传输大小、程序文件的读出用地址等。它们是更新数据关联信息的一例。

另外，在ECU元数据DB205中还登记表示ECU19的属性的属性信息。属性信息是指表示与ECU相关的硬件属性和软件属性的信息。“传输大小”是从CGW13将改写数据分割并传输到ECU19时的传输大小，“密钥”是CGW13安全地访问ECU19时使用的密钥。这些是软件属性信息的一例。另外，关于“车辆型号”和“ECU ID”，还包含ECU19所具备的闪存28d的存储器结构、连接有ECU19的总线种类、与ECU19连接的电源的种类等。这些是硬件属性信息的一例。

这里，存储器结构“1面”是在1面具有闪存面的1面独立方式存储器，“2面”是在2面具有闪存面的2面存储器，“挂起”是在伪2面具有闪存面的1面挂起方式存储器。硬件属性信息和软件属性信息是在车辆侧系统4中用于各个ECU19的改写控制的信息。硬件属性信息也可以预先由CGW13存储，在本实施例中，为了减轻车辆侧系统4中的管理负荷，由中心装置3进行管理。另外，软件属性信息是直接指定各个ECU19的改写动作的数据。为了能够实现车辆侧系统4中的灵活的控制，由中心装置3进行管理。

如图12所示，在单车信息DB213中，作为一例，登记以下所示的每个单车的数据。主要登记每个单车的结构信息、针对程序更新的单车的状态信息。具体而言，关于各车辆的ID即“VIN”，为结构信息即“Vehicle SW ID”、“Sys ID”、“ECU ID”、“ECU SW ID”等。关于这些结构信息的散列值即“Digest”值也由中心装置3进行运算、存储。在存储器结构为2面的情况下，“运用面”是ECU19当前运用的程序被写入的面，将所上传的值与结构信息一同登记。

“访问日志”是车辆将单车信息上传于中心装置3的年月日和时刻。“重配置状态”表示车辆中的重编的状态，例如存在“活动发行完毕”、“激活完成”、“下载完成”等。即，根据该进展状态，可知车辆中的重编进行到哪个阶段，在哪个阶段停滞。另外，在从车辆侧系统4对中心装置3上传结构信息等时，对该信息等赋予各车辆的“VIN”。

如图13所示，在包DB206中登记分发包的ID、分发包文件和分发包的完整性验证用的数据。

如图14所示，在活动DB217中登记以下的数据。为活动信息的ID、分发包ID、作为活动内容表示具体的更新内容的文本语句等消息信息、成为活动的对象的车辆的ID即“VIN”的列表、更新前后的“Vehicle SW ID”、更新前后的“ECU SW ID”的列表等。“对象VIN”列表能够对单车信息DB213和活动DB217进行对照并登记。另外，这些活动信息也可以一并登记于包DB206。

接下来，对本实施方式的作用进行说明。在图15中，对包管理部3A中的向ECU重配置数据DB204的登记处理进行说明。如图15所示，显示部219和输入部218将管理服务器10的重配置数据登记用的画面启动，从供应商的作业者受理ECU19的新旧程序文件的输入(A1)。例如，也可以使用将使结构信息以CSV形式等标记的文件登记为文件的UI等。接着，包管理部3A生成新程序的完整性验证数据(A2)，作为更新用的差分数据，生成以旧程序为基础更新为新程序时的差分数据文件和更新用差分数据的完整性验证数据(A3、A4)。

接下来，作为回滚用的差分数据，生成以新程序为基础更新为旧程序时的差分数据文件和该数据的完整性验证数据(A5、A6)。将这些程序文件和验证数据登记于ECU重配置数据DB204，并且基于一个旧的“ECU SW ID”而生成新的“ECU SW ID”，并进行登记(A7)。这里，在不是分发差分数据而是分发整体数据的情况下，能够省略与差分数据相关的步骤。

完整性验证数据例如是应用散列函数而生成的散列值。例如，在作为散列函数使用SHA-256(Secure Hash Algorithm 256-bit：安全散列算法256位)的情况下，将数据值按照每64字节划分为消息块。而且，若对于初始散列值应用最初的消息块的数据值，得到32字节长度的散列值，则依次重复如下，对该散列值应用下一消息块的数据值，同样得到32字节长度的散列值。

在图16中，对规格数据生成部201中的改写规格数据的生成处理进行说明。这里，对针对“车辆型号”＝“aaa”的车辆的改写规格数据的生成处理进行说明，但其他的车辆也同样。

中心装置3将规格数据生成部201的规格数据生成程序启动，经由显示部219和输入部218而受理来自OEM的作业者的输入。首先，规格数据生成部201决定成为更新对象的ECU19。如图16所示，规格数据生成部201访问ECU重配置数据DB204，而向显示部219输出能够选择所登记的“ECU SW ID”中的、成为更新对象的数据的显示画面。规格数据生成部201以确定的ECU顺序保存由OEM的作业者经由输入部218选择的一个以上的“ECU SW ID”(B1)。这里，ECU顺序表示车辆侧系统4中的ECU19的改写顺序。规格数据生成部201将由OEM的作业者指定的顺序作为确定的ECU顺序。

另外，规格数据生成部201也可以访问结构信息DB208，不接受来自OEM的作业者的输入，而决定成为更新对象的ECU1。规格数据生成部201参照相对于最新的“Vehicle SWID”的“ECU SW ID”、相对于一个旧的“Vehicle SW ID”的“ECU SW ID”，提取存在更新的ECU19。例如，在图9中，“ADS”“BRK”“EPS”为更新对象ECU19。规格数据生成部201将登记于结构信息DB208的顺序作为确定的ECU顺序。

而且，规格数据生成部201针对具有成为更新对象的多个“ECU SW ID”的ECU生成组信息(B2)。这里，参照结构信息DB208，使用“Sys ID”，例如将组1汇总为“Sys ID”为“SA01_02”的“ECU ID”，将组2汇总为“Sys ID”为“SA02_02”的“ECU ID”。例如，在图9中，将组1设为“ADS”，将组2设为第一个为“BRK”、第二个为“EPS”。这样，规格数据生成部201决定成为更新对象的ECU、ECU所属的组、组内的ECU顺序。

接下来，规格数据生成部201访问ECU元数据DB205，作为与成为更新对象的ECU19相关的规格数据，获取更新数据关联信息、硬件属性信息和软件属性信息(B3)。例如如图17所示，更新数据关联信息是“更新程序版本”、“更新程序获取地址”、“更新程序大小”、“回滚程序版本”、“回滚程序获取地址”、“回滚程序大小”、“写入数据种类”、“写入面”。硬件属性信息是“连接总线”、“连接电源”、“存储器种类”。软件属性信息是“改写面信息”、“安全访问密钥信息”、“改写方法”、“传输大小”。“改写方法”是表示在IG从接通切换到断开时，是使电源自保持电路为有效来进行改写(电源自保持)、还是根据IG接通和IG断开来进行改写(电源控制)的数据。作为“安全访问密钥信息”，也可以包含密钥以外的信息。

以下，对各信息进行说明。

·“写入数据种类”是表示程序是差分数据还是整体数据的种类。也可以分别记载针对更新程序的写入数据种类和针对回滚程序的写入数据种类。

·“写入面”是表示用于针对2面存储器的ECU19，写入到哪个面的程序的信息。

·“连接总线”是识别连接有ECU19的总线的信息。

·“连接电源”是表示连接有ECU19的电源状态的信息，记载了表示电池电源(+B电源)、辅助电源(ACC电源)和点火电源(IG电源)中的任一个的值。

·“存储器种类”是识别ECU19的存储器结构的信息，记载了表示2面存储器、1面挂起方式存储器(模拟2面存储器)、以及1面存储器等的值。

·“改写面信息”是表示ECU19的哪个面为启动面(运用面)、哪个面为改写面(非运用面)的信息。

·“安全访问密钥信息”是用于使用密钥来进行对ECU19的访问认证的信息，包含密钥导出密钥、密钥模式以及解码运算模式的信息。

·“传输大小”是将程序分割并传输到ECU19时的数据大小。

例如如图17所示，将“ECU ID”作为密钥，这些信息以上述的确定的ECU顺序的形式进行保存。规格数据生成部201若对于全部的ECU获取信息(B4；“是”)，则对于成为更新对象的车辆，指定“改写环境信息”(B5)。“改写环境信息”是指将ECU的组或者车辆整体作为对象的、用于车辆侧系统4中的改写控制的信息，并且是直接指定改写动作的数据。例如，作为以车辆整体为对象的改写环境信息，是表示车辆侧系统4中的程序更新是在车辆的行驶中(IG开关的接通中)进行还是在驻车中(IG开关的断开中)进行的“车辆状态”、表示在车辆侧系统4中能够执行程序更新的电池余量的制约的“电池负荷(电池的余量)”、表示在车辆侧系统4中能够传输写入数据的总线负荷的制约的总线负荷表信息等。

另外，作为以组为对象的改写环境信息，为属于该组的ECU19和组内的ECU顺序等。在车辆侧系统4中，控制为程序更新以组为单位进行同步，以指定的ECU顺序执行对ECU19的写入。规格数据生成部201将改写环境信息登记用的画面启动，从OEM的作业者受理输入。或者，也可以是将被输入了改写环境信息的电子表格(Excel)(注册商标)输入的形式。或者，也可以是提取登记于结构信息DB208的制约信息的形式。此外，规格数据生成部201使用上述的步骤B2的生成结果，来作为以组为对象的改写环境信息。

总线负荷表是表示电源状态与总线的传送允许量的对应关系的表。如图18所示，传送允许量是相对于最大传送允许量能够传送的车辆控制数据与写入数据的传送量的合计。在该例示中，对于第一总线，传送允许量相对于最大传送允许量为“80％”，因此CGW13在IG电源状态下，允许车辆控制数据的传送允许量相对于最大传送允许量为“50％”，允许写入数据的传送允许量相对于最大传送允许量为“30％”。另外，CGW13在ACC电源状态下，允许车辆控制数据的传送允许量相对于最大传送允许量为“30％”，允许写入数据的传送允许量相对于最大传送允许量为“50％”。另外，CGW13在+B电源状态下，允许车辆控制数据的传送允许量相对于最大传送允许量为“20％”，允许写入数据的传送允许量相对于最大传送允许量为“60％”。第二总线和第三总线也同样。

最后，规格数据生成部201将所生成或者获取的各数据按照预先决定的规定的数据构造进行配置，生成图17所示的改写规格数据(B6)。即，规格数据生成部201利用以车辆侧系统4能够解释的数据构造生成改写规格数据。此外，对于各ECU信息，可以按照组的从小到大的顺序并且按照组内ECU顺序记载于改写规格数据。例如，在图9中，在将组1设为“ADS”、将组2设为第一个为“BRK”、第二个为“EPS”的情况下，规格数据的ECU信息栏最初为“ADS”的ECU信息，接下来排列“BRK”的ECU信息，最后排列“EPS”的ECU信息。

在图17所示的规格数据中，ECU信息的“ECU ID”～“传输大小”是包含对象ECU19的种类的对象装置关联信息的一例，与上述的硬件属性信息和软件属性信息对应。另外，“更新程序版本”～“写入面”是更新数据关联信息的一例。另外，以ECU的组或者车辆整体为对象的“改写环境”是指定车辆中的更新处理的更新处理信息的一例。

在图19中，对包生成部202中的包生成处理进行说明。与上述同样，这里，对针对“车辆型号”＝“aaa”的车辆的包生成处理进行说明。如图19所示，以作业者的指示为契机，中心装置3将包管理部3A的包生成部202启动。包生成部202与步骤B1同样地决定成为更新对象的“ECU SW ID”(C1)。包生成部202从ECU重配置数据DB204获取与成为更新对象的“ECUSW ID”对应的各数据而生成一个重编数据(C2)。例如，在图10中，包生成部201获取新程序的完整性验证数据、作为差分数据的更新数据、更新数据的完整性验证数据、旧程序的完整性验证数据、作为差分数据的回滚数据、以及回滚数据的完整性验证数据，生成重编数据。而且，将所生成的重编数据和在步骤B1～B6中说明的对应的改写规格数据合并而生成一个分发包文件(C3)。接下来，生成关于所生成的包文件的完整性验证数据(C4)，与包文件一同登记于包DB206(C5)。

图20示意性表示如上述那样生成的包文件的内容。示意性表示根据ECU顺序，将与成为更新对象的“ADS”、“BRK”和“EPS”对应的更新数据、完整性验证数据合并为一个重编数据，而且与改写规格数据合并而生成一个分发包文件。这里，也可以仅在成为更新对象的ECU19的存储器结构为1面的情况下，回滚数据包含于重编数据。在存储器结构为2面或者挂起的情况下，由于不进行针对运用面的改写，因此能够省略作为旧程序的回滚数据。

像以上那样，根据本实施方式，在中心装置3的ECU重配置数据DB204中存储有搭载于车辆的多个ECU19中的、成为更新应用程序的对象的ECU19的更新程序的数据。在结构信息DB208中，与车辆的种类一同存储有与搭载于车辆的多个ECU19分别对应的“ECU ID”和存储于ECU19的应用程序的“ECU SW ID”等车辆关联信息。在ECU元数据DB205中存储有改写对象ECU19的属性和与更新数据相关联的更新数据关联信息。

而且，规格数据生成部201基于存储于结构信息DB208和ECU元数据DB205的信息，而生成与写入到对象ECU19的更新数据一同发送给车辆的规格数据，使其包含关于对象ECU19的种类、属性、更新数据关联信息、以及表示与数据更新相关的改写环境的信息。而且，包生成部202生成包含规格数据和重编数据的分发包，并登记于包DB206。而且，包分发部203向车辆侧系统4分发所登记的分发包。由此，车辆侧系统4通过接收与更新数据一同发送的规格数据，能够基于该规格数据，适当地选择对象ECU19，适当地控制使用了更新数据的写入处理。

而且，规格数据生成部201将针对多个ECU19的规格数据生成为一个文件，而且包生成部202与针对多个ECU19的重编数据一同打包为一个文件，因此车辆侧系统4如果接收一个分发包则能够向多个ECU19写入更新数据。

另外，在作为规格数据的车辆关联信息中包含将多个ECU19的一部分分组后的组信息，因此车辆侧系统4能够根据由组信息规定的顺序而选择成为对象的ECU19，并写入更新数据。例如，在存在多个成为某个功能改善的对象的ECU19的情况下，将组1设为车身系统ECU19，将组2设为行驶系统ECU19，将组3设为MM系统ECU19，由此能够使车辆侧系统4中的程序更新分三次执行。因此，与集中全部ECU执行程序更新的情况相比，能够缩短用户每次的等待时间。

另外，在改写环境信息中包含与车辆相关的“车辆状态(IG接通状态)”和“电池负荷”、与ECU19相关的“总线负荷表”，因此车辆侧系统4能够基于这些信息而决定写入更新数据的时机等。即，使用OEM或者中心装置3的服务企业通过指定针对车辆的执行制约条件来作为改写环境信息，能够运用灵活的程序更新。

此外，规格数据生成部201根据预先决定的数据构造，根据与预先设定的改写顺序较早的ECU19相关的信息依次生成规格数据，因此车辆侧系统4能够根据规格数据中的ECUID的配置顺序而写入更新数据。即，将具有相互协作的处理的ECU19分组为一个组，考虑该协作的处理的内容来规定ECU顺序，由此在车辆侧系统4中，即使在对新程序的更新时机没有完全同步的情况下，也能够没有不良情况地完成程序更新。例如可以是，在ECU(ID1)的新程序具有向ECU(ID2)发送规定消息的处理，ECU(ID2)的新程序具有在无法接收从ECU(ID1)发送的规定消息的情况下成为超时错误的处理的情况下，以先更新ECU(ID1)，然后更新ECU(ID2)的方式规定ECU顺序。

(第二实施方式)

如图21所示，第二实施方式涉及在图8中车辆侧系统4最初向中心装置3发送的“车辆结构信息同步”。若在车辆侧IG开关37接通，则以其为契机，CGW13对DCM12发送“同步开始请求”。DCM12接受该“同步开始请求”而将“结构信息收集请求”回复给CGW13。于是，CGW13对于各ECU19进行程序版本的询问。各ECU19将“ECU SW ID”回复给CGW13。另外，存储器结构为2面或者挂起的ECU19将表示多个面中的哪个是运用面、哪个是非运用面的面信息也一并地回复给CGW13。此外，各ECU19也可以将成为控制对象的致动器等的校准信息、用于接受程序更新服务的许可信息、在ECU19中产生的故障代码一并地发送给CGW13。

CGW13若完成来自各ECU19的“ECU SW ID”的接收，则将它们全部与“VIN”一同发送给DCM12。此时，也可以将由CGW13管理的“Vehicle SW ID”和“Sys ID”也一并地发送给DCM12。DCM12接受它们，以全部的“ECU SW ID”为对象，例如使用散列函数而生成一个作为摘要值的散列值。如上所述，在作为散列函数使用SHA-256的情况下，将全部的“ECU SW ID”的值串行连结而得的数据值按照每64字节划分为消息块，对于初始散列值应用最初的消息块的数据值，得到32字节长度的散列值，对该散列值依次应用后续的消息块的数据值，最终得到32字节长度的散列值。这里，DCM12不仅以全部的“ECU SW ID”为对象，而且也可以以包含“Vehicle SW ID”、“Sys ID”、面信息和校准信息的值为对象，生成一个散列值。

DCM12将像上述那样得到的“ECU SW ID”的摘要值与“VIN”一同发送给中心装置3。另外，DCM12也可以将故障代码、许可信息与摘要值一并地发送。以下，有时将上述摘要值称为“结构信息摘要”，将作为其基础的“ECU SW ID”的全部的数据值称为“全部结构信息”。在“全部结构信息”中，也可以包含“Vehicle SW ID”、“Sys ID”、面信息以及校准信息。

中心装置3像后述那样，进行摘要值的比较、单车信息DB213的更新。使结构信息同步的中心装置3确认程序更新的有无，在有更新的情况下将活动信息向车辆侧系统4通知。然后，车辆侧系统4下载分发包，进行对成为对象的ECU19的安装，进行新程序的激活。以这些更新处理完成为契机，CGW13对DCM12发送“同步开始请求”，以后直到同步完成通知为止进行与上述相同的处理。另外，以IG开关37被接通为契机而进行的上述的处理也可以在程序的更新后进行。

如图22所示，中心装置3的单车信息管理部3C若从车辆侧系统4接收“结构信息摘要”(D1)，则与在该时刻登记于单车信息DB213的对应的车辆的“结构信息摘要”进行对照，判断两者是否一致(D2)。“单车信息摘要”也可以预先在单车信息DB213中登记运算出的值，也可以在从车辆侧系统4接收到的时刻，使用登记于单车信息DB213的结构信息而对摘要值进行运算。如果两者一致(“是”)，则判断车辆的单车信息是否适合登记于结构信息DB208的正规的组合(D6)。另外，也有可能在规定的时机更新结构信息DB208，因此在步骤D2中两者一致的情况下(“是”)、在两者不一致的情况下(“否”)，都进行步骤D6的判断。

这里，例如如图23所示，在上述的是否适合的判断中，检查从车辆侧系统4上传的结构信息的“Vehicle SW ID”与“ECU SW ID”的组合是否正规。在该图所示的列表中，与登记于结构信息DB208的“Vehicle SW ID＝0001”对应的“ECU ID＝ADS”的“ECU SW ID”为“ads_001”，“ECU ID＝BRK”的“ECU SW ID”为“brk_001”，“ECU ID＝EPS”的“ECU SW ID”为“eps_010”。

与此相对，VIN＝300的车辆C同样为“Vehicle SW ID＝0001”，但“ECU ID＝ADS”的“ECU SW ID”为“ads_002”，“ECU ID＝BRK”的“ECU SW ID”为“brk_003”，这两个ECU19与登记于结构信息DB208的结构信息不同。因此，在步骤D6中判断为“否”，即为非正规“NG”，结构信息确认部210向车辆侧系统4和对OEM等所生产的车辆的信息进行管理的装置、即图8所示的管理装置220通知异常(D12)。例如通过SMS发送控制部212使用SMS来进行异常的通知。SMS发送控制部212为通信部的一例。假设这两个ECU19不是基于新程序的更新对象ECU，中心装置3也判断为该车辆为非正规，不进行步骤D7以后的处理。

另一方面，VIN＝100的车辆A为“Vehicle SW ID＝0001”，“ECU ID＝ADS”的“ECUSW ID”为“ads_001”，“ECU ID＝BRK”的“ECU SW ID”为“brk_001”，与登记于结构信息DB208的结构信息全部一致。因此，在步骤D6中判断为“是”，即为正规、“OK”，进入步骤D7。这里，结构信息确认部210也可以根据车辆C的“ECU SW ID”的组合是否存在于结构信息DB208，而判断是正规还是非正规。另外，除了“Vehicle SW ID”之外，也可以将“Sys ID”添加到判断的材料中。

接下来，更新有无确认部211经由活动管理部3D访问活动DB217，确认基于新程序的更新的有无(D7)。通过对从车辆侧系统4上传的“Vehicle SW ID”和活动DB217的“更新前Vehicle SW ID”进行比较而判断更新的有无。例如如图23所示，由于VIN＝100的车辆A是更新前的“Vehicle SW ID＝0001”，因此判断为有更新(“是”)。在该情况下，更新有无确认部211将对应的活动ID“Cpn_001”向上述车辆A的车辆侧系统4通知(D8)。活动信息相当于更新通知信息，活动DB217是更新通知信息存储部的一例。

另外，如果使活动DB217具有更新前后的“Sys ID”，则也可以通过“Sys ID”来确认更新的有无。另外，也可以取代“Vehicle SW ID”，对所上传的“ECU SW ID”列表与活动DB217的“更新前ECU SW ID列表”进行比较，来判断更新有无。

车辆侧系统4将所通知的活动ID作为密钥而从中心装置3获取与上述ID对应的活动文件(D9)。在活动文件中包含对活动内容进行说明的文本语句、执行程序更新时的制约事项等。制约事项是指执行下载、安装时的条件，例如为电池余量、分发包的下载所需要的RAM的空闲容量、车辆的当前位置等。车辆侧系统4对活动文件进行解析，使用车载显示器7来显示活动内容等。用户根据活动内容，参照在车载显示器7上显示的消息，决定是否更新ECU19的应用程序。若经由车载显示器7受理用户的同意操作，则CGW13经由DCM12向中心装置3通知同意更新的内容。于是，中心装置3向车辆侧系统4发送与上述活动ID对应的包ID的分发包文件和完整性验证数据(D10)。

另外，如果在步骤D7中没有更新(“否”)，则向车辆侧系统4通知“无更新”(D11)。例如如图23所示，VIN＝200的车辆A为更新后的“Vehicle SW ID＝0002”，与活动DB217的“更新前Vehicle SW ID”都不一致，因此判断为无更新。

另一方面，如果在步骤D2中“结构信息摘要”的对照结果不一致(“否”)，则中心装置3向车辆侧系统4请求“全部结构信息”的发送(D3)。该发送与“整体数据发送请求的通知”对应。与之对应地，若车辆侧系统4发送“全部结构信息”，则中心装置3接收该信息(D4)。而且，中心装置3的单车信息管理部3C对登记于单车信息DB213的该车辆的信息进行更新(D4)。然后，转移至步骤D6。单车信息DB213是车辆侧结构信息存储部的一例。

另外，也可以在IG开关37被断开的时机等进行基于CGW13的“同步开始请求”的发送。

像以上那样，根据第二实施方式，车辆侧系统4若从多个ECU19接收与各ECU19的结构相关的结构信息，则生成基于多个结构信息的数据值的散列值，并将该散列值发送给中心装置3。中心装置3具有单车信息DB213，对从车辆侧系统4发送来的散列值与存储于单车信息DB213的车辆的结构信息的散列值进行比较。而且，如果两者不一致，则向车辆侧系统4请求“全部结构信息”的发送。于是，车辆侧系统4接受该发送，并将“全部结构信息”发送给中心装置3，中心装置3若接收“全部结构信息”，则基于该数据值而更新存储于单车信息DB213的结构信息。

如果像这样构成，车辆侧系统4最初向中心装置3发送结构信息的散列值，仅在中心装置3中的散列值的比较结果不一致时，将结构信息的全部的数据值向中心装置3发送。由此，能够减少车辆侧系统4发送的数据的大小，因此即使将车辆侧系统4搭载于多个车辆，也能够总体上削减通信量。特别是，在车辆侧系统4中，在IG接通时等预先决定的时机上传结构信息的情况下，会产生该通信集中的时间段。因此，通过使用散列值来削减发送数据量，能够减少通信负荷。

另外，CGW13从成为更新数据的改写对象的全部的ECU19接收结构信息，生成基于这些全部的数据值的散列值，DCM12在车辆的点火开关37被接通或者断开的时机发送散列值，因此能够在车辆的行驶开始或者结束的时机，向中心装置3发送散列值。因此，中心装置3能够使单车信息DB213的结构信息适当地与车辆同步。

另外，车辆侧系统4若从多个ECU19接收各ECU19的“ECU SW ID”，则将在它们中组合了“Vehicle SW ID”的结构信息列表向中心装置3发送。中心装置3对从车辆侧系统4发送来的“ECU SW ID”列表与存储于结构信息DB208的对应的车辆的正规的ECU SW ID”列表进行比较，若判断为发送来的列表的组合为非正规，则向车辆侧系统4和管理装置220发送异常检测。

如果像这样构成，中心装置3能够将车辆的结构信息的组合处于多个ECU19无法配合而对车辆的行驶带来妨碍的状态的情况检测为异常，并向车辆侧系统4通知。由此，车辆侧系统4能够进行禁止车辆的行驶等的应对。

对于车辆的结构信息的组合为非正规的车辆，中心装置3不实施更新有无的确认处理(D7)。因此，能够防止在不正规的车辆中执行程序更新。即使不正规的ECU19不是基于新程序的更新对象ECU，中心装置3也不实施更新有无的确认处理(D7)。在车辆侧系统4中，在执行程序更新时，也产生针对不是更新对象的ECU19的控制。因此，在具有不正规的ECU19的车辆中，有可能程序更新不正常地完成，因此中心装置3不对该车辆执行程序更新。

另外，中心装置3具备活动DB217，该活动DB217存储有活动信息，该活动信息用于向车辆侧通知产生了基于新程序的更新，对于判断为正规的车辆，确认对应的车辆的活动信息的有无。如果有更新，则向车辆侧系统4发送该活动信息。由此，能够对用户提示活动信息，催促应用程序的更新。以来自车辆的结构信息上传为契机，作为一系列的处理，中心装置3执行这些结构信息的同步、是否是正规的结构信息的判断、以及更新有无的确认，由此能够对适当的车辆迅速地通知程序的更新。

另外，也可以像以下那样变形地实施第二实施方式。

·也可以使中心装置3对车辆侧系统4进行“同步开始请求”的发送，若接收“同步开始请求”则DCM12对CGW13发送“结构信息收集请求”。例如，在“车辆型号＝aaa”的结构信息DB208被更新时，中心装置3对该车辆型号的车辆发送“同步开始请求”。

·另外，在成为更新数据的改写对象的ECU19中，也可以在改写完成的时机向中心装置3发送散列值。即，在成为改写对象的ECU19全部的程序更新完成的时机，也执行图22所示的步骤D1～D12的流程图。

·在双方的散列值的比较结果一致时，中心装置3对车辆侧系统4请求各ECU16的结构信息的组合列表的发送。而且，若接收上述组合列表，则也可以进行步骤D6～D12的处理。

·中心装置3也可以在双方的散列值的比较结果一致时也参照活动DB217，确认对应的车辆的活动信息的有无。

也可以如图23A所示，从车辆侧系统4向中心装置3发送散列值。图23A是表示CGW13的处理的流程图。例如，在IG开关37被接通时，CGW13从各ECU19收集结构信息(D21)，对于所收集的结构信息的数据值而生成散列值(D22)。而且，将所生成的散列值与存储于闪存24d的散列值(上次生成值)进行比较，判断是否存在差异(D23)。如果存在差异(“是”)，则将这次生成的散列值存储于闪存24d(D24)，向中心装置3发送上述散列值。在步骤D23中，如果双方的散列值没有差异(“否”)，则结束处理。另外，在闪存24d中预先存储有针对结构信息的初始值的散列值。由此，车辆侧系统4能够削减对中心装置3上传结构信息的次数。

(第三实施方式)

第三实施方式涉及为了提高车辆侧系统4中的应用程序的更新率，而由中心装置3的活动管理部3D执行的功能。如图24所示，例如在车辆侧系统4中，用户通过Config文件将HTTP轮询的间隔预先设定为3日左右，由此车辆侧系统4对于中心装置3周期性地确认应用程序的更新有无。由此，关于与活动DB217对应的车辆，在设定了VIN的活动信息后进行了更新确认的时刻，从中心装置3向车辆侧系统4通知“有更新”。即，像第二实施方式中说明的那样，以从车辆侧系统4使用HTTP上传结构信息为契机，在经过3日后的IG接通的时机执行由中心装置3进行更新确认这样的处理。

如果像这样构成为以来自车辆的通知为契机进行更新有无，则中心装置3不需要在设定了活动信息的时刻从中心装置3向成为该活动的对象的全部的车辆发送活动信息。然而，在用户长期不使用车辆的情况下，在该期间一直不进行使用HTTP的更新有无的确认。因此，还设想用户不知道发行了新的活动，产生不进行应用程序的更新的车辆的情况。

因此，如图25所示，中心装置3的SMS发送控制部212定期地或者在规定的时机，参照单车信息DB213来检查各车辆的访问日志(E1)。而且，判断是否存在在规定期间未进行对中心装置3的访问、即用于应用程序的更新确认的结构信息的发送的车辆(E2)。规定期间以在活动DB217中设定了新的活动的日为起算日，例如设为7日左右。即，SMS发送控制部212以单车信息DB213的“Vehicle SW ID”对应于活动DB217的“更新前Vehicle SW ID”的车辆为对象，确定在7日内未进行更新确认的车辆。此外，SMS发送控制部212也可以以全部的车辆为对象，确定在规定期间未进行更新确认的车辆。

另外，在单车信息DB213中，在工厂生产车辆时通过OEM登记初始数据，然后，例如通过伴随着销售车辆的、来自OEM的通知而输入最初的访问日志。该访问日志实质上相当于用于使以后的程序的更新有效化的通知。未输入访问日志的车辆为步骤E2的判断对象以外的车辆。

如果存在在规定期间未进行更新确认的车辆(“是”)，则SMS发送控制部212根据单车信息DB213的型号、装备信息等来判断该车辆的特性(E3)。作为这里的特性，SMS发送控制部212判断是否是电动汽车；是能够接收SMS(Short Message Service)的EV、还是能够接收SMS的现有的汽油发动机车、即传统发动机车；是输送车、还是很难接收SMS的车辆。例如，在搭载于车辆的DCM12不具有接收SMS的功能的情况下或在没有进行接收SMS的协议的情况下，判断为是很难接收SMS的车辆。

如果是EV，则发送使该车辆的ECU19启动而开始结构信息发送步骤的SMS(E5、参照图26)。若DCM12接收SMS，执行在SMS中记载的指令，则成为IG接通电源状态，启动的CGW13经由DCM12向中心装置3发送结构信息。然后，像图22所示的步骤D1～D12那样，进行更新确认，执行分发包的下载等。在EV的情况下，由于电池的容量较大，因此认为在保持驻车状态下作为IG接通电源状态能够充分进行程序的下载。因此，使用SMS使ECU19启动而自动地开始更新确认和下载以后的步骤。

假设在EV车的电池的余量较少的情况下，在车辆侧系统4中，参照图17所示的改写规格数据，在低于所指定的电池余量的状态的情况下，控制为不开始安装。或者，中心装置3参照在步骤D9中发送的作为制约事项而记载于活动文件中的电池余量，在低于所指定的电池余量的状态的情况下，控制为在车辆侧系统4中不开始分发包的下载。

在输送车中，SMS发送控制部212向处于每次在DCM12间歇地启动的期间能够接收SMS的状态的车辆发送能够在车载显示器7上显示的SMS(参照E4、图26)。例如，CGW13在下次IG接通的时机向车载显示器7指示显示在接收到的SMS中记载的文本语句。另外，在单车信息DB213中登记用户的便携终端6的信息的情况下，也可以向该便携终端6发送SMS。例如，显示“存在活动信息。请使IG-ON。”这样的文字消息。单车信息DB213是用户信息存储部的一例。另一方面，对处于很难接收SMS的状态的车辆不进行任何处理，另外对用户邮寄等来应对(E6)。

像以上那样，根据第三实施方式，车辆侧系统4向中心装置3发送多个ECU19的结构信息，将从各车辆发送的结构信息与发送日一同存储于单车信息DB213。另外，在活动DB217中，作为活动信息，存储有活动ID以及能够识别数据更新的对象车辆的对象VIN列表。而且，中心装置3参照单车结构DB213，如果在从与对象车辆关联的发送日起的规定期间内未进行结构信息的发送，则通过SMS向对象车辆的车辆侧系统4发送用于催促数据更新的消息。

如果像这样构成，即使在由于用户没有乘坐车辆的机会，因此持续了未向中心装置3发送结构信息的状况的情况下，若从存储于单车信息DB213的发送日起经过了规定期间，则中心装置3向对象车辆的车辆侧系统4发送用于催促数据更新的消息。因此，用户能够通过参照该消息而识别出需要数据更新。

而且，中心装置3通过参照单车信息DB213和活动DB217而决定程序更新的对象车辆。即，在单车信息DB213中存储有从各车辆发送结构信息的日期，在活动DB217中存储有对象VIN列表。因此，中心装置3能够通过来自各车辆的结构信息的发送日和对象VIN列表来决定程序更新的对象车辆。

另外，车辆侧系统4若以车辆的点火开关37被接通为契机，从各ECU19接收各自的结构信息，则向中心装置3发送结构信息。因此，在用户乘坐车辆时，能够可靠地向中心装置3发送结构信息。

而且，如果对象车辆为电动汽车，则中心装置3使消息包含使该对象车辆的ECU启动的指令并进行发送，接收到该消息的车辆侧系统4使ECU19启动，执行与数据更新相关的处理。即，由于电动汽车的电池的容量比较充裕，因此不用等待用户的操作，就能够使ECU19执行与数据更新相关的处理。因此，能够高效地执行数据更新。

另外，如果对象车辆是输送车，则作为消息，中心装置3至少发送能够显示于对象车辆的车载显示器7的文字信息。因此，输送车的用户通过参照显示于车载显示器7的文字信息，能够识别出需要数据更新。

另外，在单车信息DB213中存储有用户的便携终端6的发送目的地时，作为消息中心装置3发送能够显示于便携终端6的文字信息。由此，用户即使没有乘坐车辆的机会，也通过参照显示于便携终端6的文字信息，能够识别出需要数据更新。

此外，若用户经由便携终端6，预先向中心装置3发送活动的发送日和发送目的地，中心装置3使该发送日和发送目的地存储于单车信息DB213。例如，作为发送日用户指定活动发行的第二日，作为发送目的地，用户指定便携终端6而不指定车载显示器7。另外，作为发送日，用户指定不乘车的规定时刻，作为发送目的地，用户指定车辆，自动地进行对于程序更新的同意操作。由此，不论结构信息的发送的有无，中心装置3都在上述发送日对上述发送目的地发送活动信息。因此，在预先掌握了用户暂时没有乘坐车辆的机会时，能够设定为在用户设定的发送日接收活动信息。

另外，也可以像以下那样变形地实施第三实施方式。

·也可以与单车信息DB213独立地设置用户信息存储部。

·活动信息的发送也可以使用SMS以外的方式。

·也可以取代将发送日存储于单车信息DB213，中心装置3例如存储没有进行来自车辆侧的发送的日期，在该日期连续了7日时发送催促数据更新的消息。

(第四实施方式)

第四实施方式表示用户指定活动信息、消息的通知方法的情况。例如，假定预先确定用户一个月左右未乘车，而没有使IG开关37接通的机会的情况。如图27所示，用户通过便携终端6向中心装置3发送活动产生时的通知目的地和所通知的时间的设定。例如，进行在一个月后向便携终端6通知活动信息这样的设定。由此，单车信息管理部3C使单车信息DB213存储上述通知目的地和通知时间的信息，根据设定向用户进行通知。例如，如果在该一个月的期间内设定两个活动(1、2)，SMS发送控制部212在一个月后向用户的便携终端6通知活动(1、2)的信息，而催促程序更新。

像以上那样，根据第四实施方式，若用户经由便携终端6向中心装置3发送活动信息的发送日和发送目的地，则中心装置3将上述发送日和发送目的地存储于单车信息DB213。而且，中心装置3在所存储的发送日对发送目的地发送活动信息。由此，在确定了用户在一定期间内不乘坐车辆的情况下，能够停止从中心装置3发送不需要的活动信息。

(第五实施方式)

第五实施方式表示在中心装置3向车辆侧系统4发送更新程序的数据时，车辆侧系统4赋予为了验证数据的完整性而使用的验证数据的功能。如图28和图29所示，供应商使用包管理部3A，制作登记于ECU重配置数据DB204的数据。具体而言，作为更新数据，包管理部3A制作用于将旧程序改写为新程序的新差分数据(Y1)，制作针对ECU19的新程序的完整性验证数据即散列值、以及针对新差分数据的散列值(Y2)。这里，在ECU为1面存储器的情况下，也可以是，作为回滚数据，制作用于将新程序改写为旧程序的旧差分数据，制作针对ECU19的旧程序的散列值、以及针对旧差分数据的散列值。

包管理部3A针对各散列值应用使用了规定的密钥即密钥值的加密化而生成认证符(Y3)。而且，包管理部3A发送更新数据和带有各认证符的完整性验证数据，并存储于ECU重配置数据DB204(Y4)。包管理部3A像上述那样生成包，生成针对包的完整性验证数据，并向车辆侧系统4发送(Y5)。

主装置(OTA主机)11对针对包的完整性验证数据进行运算，对该运算值与接收到的包的完整性验证数据进行比较，进行包的完整性验证(Y6)。若包的完整性验证成功，则主装置11向改写对象ECU(目标ECU)19发送ECU的更新数据和完整性验证数据(Y7)。

改写对象ECU19对针对更新数据的完整性验证数据进行运算，对该运算值与接收到的更新数据的完整性验证数据进行比较，进行更新数据的完整性验证(Y8)。若更新数据的完整性验证成功，则改写对象ECU19将更新数据即差分数据复元，进行对闪存28d的写入(Y9)。若写入完成，则改写对象ECU19对针对写入到闪存28d的数据的完整性验证数据进行运算，对该运算值与接收到的新程序的完整性验证数据进行比较，进行闪存28d的完整性验证(Y10)。改写对象ECU19向主装置11发送该验证结果(Y11)，主装置11将接收到的该验证结果作为安装结果通知而向中心装置3发送(Y12)。

例如如图10所示，包管理部3A针对最新的“ECU SW ID”，生成以下的完整性验证数据。在ECU的存储器结构为2面存储器或者挂起的情况下，能够省略以下(3)(4)。

(1)生成针对ECU的新程序的完整性验证数据即散列值。进行该处理的功能部分是第一验证值生成部(步骤A1)的一例。

(2)生成用于以ECU的旧程序为基础而更新为新程序的差分数据即更新数据、该更新数据的完整性验证数据即散列值。进行该处理的功能部分是第二验证值生成部(步骤A4)的一例。

(3)生成针对ECU的旧程序的完整性验证数据即散列值。进行该处理的功能部分是第四验证值生成部(步骤A5)的一例。

(4)生成用于以ECU的新程序为基础而更新为旧程序的差分数据即更新数据、该更新数据的完整性验证数据即散列值。进行该处理的功能部分是第五验证值生成部(步骤A7)的一例。

另外，“程序”还包含在程序中使用的常量数据等。如果是“ECU SW ID＝ads_002”，则针对更新数据“Adsfile001-002”，生成该散列值x1。散列函数像上述那样使用例如SHA-256。散列值相当于验证值。这里，包管理部3A也可以构成为，通过对散列值应用使用了规定的密钥即密钥值的加密化来生成认证符，而生成带有认证符的完整性验证数据。

接下来，供应商通过对完整性验证数据应用使用了规定的密钥即密钥值的加密化来生成认证符，而生成带有认证符的完整性验证数据，将更新数据与带有认证符的完整性验证数据对应起来而向OEM提供。即，通过包管理部3A，将各程序和针对该程序的带有认证符的完整性验证数据登记于ECU重配置数据DB204，由此向OEM提供。根据OEM的指示，包管理部3A使用ECU重配置数据DB204等，像上述那样生成改写规格数据，生成分发包，并登记于包DB206。若从车辆侧系统4产生更新数据的下载请求，则中心装置3根据该下载请求而向车辆侧系统4分发包含更新数据和带有认证符的完整性验证数据的分发包。

另外，技术方案中的“完整性验证数据”包含仅散列值的数据、包含基于密钥的加密化的带有认证符的完整性验证数据双方。

车辆侧系统4的主装置11若接收分发包，则使用赋予分发包的完整性验证数据(第三验证值)来验证分发包的妥当性。具体而言，对使用分发包而运算出的完整性验证数据与接收到的完整性验证数据进行比较，如果一致则判断为正常。在验证的结果，确认为正常的情况下，主装置11将分发包解包为每个ECU的数据(参照图6)。而且，主装置11向写入目的地的ECU19传输更新数据和带有认证符的完整性验证数据。

ECU19使用带有认证符的完整性验证数据(第二验证值)来验证更新数据的妥当性。具体而言，对使用接收到的更新数据而运算出的完整性验证数据与接收到的完整性验证数据进行比较，如果一致则判断为正常。在验证的结果，确认为正常的情况下，ECU19的CPU28a进行对闪存28d的写入处理。若写入处理完成，则ECU19使用带有认证符的完整性验证数据(第一验证值)而读出写入到闪存28d的数据，验证其妥当性。具体而言，对使用所读出的数据而运算出的完整性验证数据与接收到的完整性验证数据进行比较，如果一致则判断为正常。此外，这里的完整性验证数据在ECU19的启动时也使用，因此预先存储于闪存28d的规定区域。若这些处理完成，则ECU19向主装置11发送包含验证结果的写入响应。主装置11向中心装置3通知安装结果。另外，图中的“目标ECU”与“对象ECU”同义，“OTA主机”与“DCM”同义。CPU28a是写入处理部的一例。

这里，在安装的中途产生了程序更新的取消的情况下，ECU19进行回滚处理。ECU19写入更新数据，并且使用带有认证符的完整性验证数据(第五验证值)来验证回滚用差分数据的妥当性。具体而言，对使用回滚用差分数据而运算出的完整性验证数据与接收到的完整性验证数据进行比较，如果一致则判断为正常。在验证的结果，确认为正常的情况下，ECU19在完成更新数据的写入之后，开始进行使用回滚用差分数据的写入。而且，在完成写入后，ECU19使用带有认证符的完整性验证数据(第四验证值)，而读出写入到闪存28d的数据，验证其妥当性。

此外，也可以采用如下的结构，接收到的差分数据(更新数据、回滚用差分数据)的完整性验证不是由ECU19进行而是由主装置11进行。

如图30所示，然后，若上述车辆的IG开关37被接通，则以此为契机，ECU19进行启动时的数据验证。ECU19使用带有认证符的完整性验证数据(第一验证值或者第四验证值)来验证所启动的程序等的完整性。首先，在闪存28d中，对写入有更新后的程序、常量数据的评价对象区域的数据值应用散列函数，获取散列值。接下来，对带有认证符的完整性验证数据进行解码，对解码结果中包含的散列值(期待值)与所获取的散列值(运算值)进行对照，判断写入到闪存28d的程序等是否被篡改。如果双方的散列值一致而为“OK”，则ECU19像通常那样进行启动处理。对于各ECU19进行同样的处理，如果全部的评价对象ECU19的结果为“OK”，则结束处理。

另一方面，如果对于任意的ECU19，验证的结果为异常，为“NG”，则ECU19保存处理的日志而向主装置11通知错误。主装置11同样保存日志而向中心装置3通知错误。中心装置3同样保存日志而向OEM等管理装置220通知错误。向管理装置220的通知例如通过SMS发送控制部212使用SMS来进行、或者通过经由因特网线路的电子邮件的发送等来进行。

在上述的实施例中，在车辆侧系统4中，采用进行完整性的验证的结构。在图31中，对由中心装置3进行完整性的验证(与期待值的比较)的情况进行说明。在图31中，例如在IG接通等的时机，ECU19向主装置11发送更新后的应用程序的版本信息时，与版本信息一同与上述同样地生成带有认证符的完整性验证数据并发送(X1)。ECU19对针对闪存28d的数据的完整性验证数据进行运算，向主装置11发送该运算值。作为结构信息包含带有认证符的完整性验证数据，主装置11将其向中心装置3发送(X2)。

中心装置3访问ECU重配置数据DB204，获取符合目标ECU19的“ECU SW ID”的带有认证符的完整性验证数据(X3、X4)，与从车辆侧上传的完整性验证数据进行对照(X5)。具体而言，从ECU重配置数据DB获取与“ECU SW ID”对应的新程序的完整性验证数据，并进行对照。如果对照的结果不一致，为NG(X6；NG)，则对OEM的管理装置220通知异常(X7)。该处理部分的功能相当于异常报告部。

中心装置3向主装置11发送对照结果(X8)，主装置11向改写对象ECU19发送接收到的对照结果(X9)。改写对象ECU19在对照结果为OK的情况下，像通常那样使应用程序进行动作，在对照结果为NG的情况下，不使应用程序进行动作。另外，在本实施例中，包管理部3A能够省略新程序的完整性验证数据生成(步骤A1)、旧ECU程序的完整性验证数据生成(步骤A5)。

另外，在上述中，ECU19在进行了更新数据的写入之后，在车辆的IG开关37被接通的时机验证更新数据的完整性，但也可以取而代之，在进行了更新数据的写入之后验证完整性。

另外，在上述的实施方式中，仅对更新数据赋予带有认证符的完整性验证数据，但也可以如下那样实施。

·从ECU重配置数据DB204获取新程序和对应的更新数据(数据获取步骤；步骤A1)。

·第一验证值生成部对于新程序生成第一散列值(第一验证值生成步骤；步骤A2)。

·第二验证值生成部对于更新数据生成第二散列值(第二验证值生成步骤；步骤A4)。包生成部202使分发包包含更新数据、规格数据以及第一和第二散列值(分发包生成步骤)。更新数据与新差分数据对应。

·第三验证值生成部对于分发包生成第三散列值(第三验证值生成步骤；步骤C4)。

·包分发部203向车辆侧系统4发送分发包和第三散列值(发送步骤)。

另外，关于认证符，也可以仅对分发包和第三散列值赋予，也可以在生成各散列值的每个阶段赋予。包分发部203相当于发送部。

在该情况下，在车辆侧系统4中，

·接收处理部即DCM12接收分发包和第三散列值。

·第三验证处理部对根据分发包数据生成的散列值与接收到的第三散列值进行比较，而验证分发包数据的完整性。

·第二验证处理部对根据更新数据生成的散列值与接收到的第二散列值进行比较，而验证更新数据的完整性。

·写入处理部的一例即CPU28a将更新数据写入闪存28d。

·第一验证处理部对于通过写入更新数据而成为新程序的闪存28d内的数据值生成散列值，与接收到的第一散列值进行比较，而验证新程序的完整性。

如果更新数据的验证结果为NG，则对闪存28d的写入中止。另外，如果写入到闪存28d的新程序的验证结果为NG，则使新程序无效，根据需要进行回滚处理。另外，第一～第三验证处理部也可以由CPU28a实现。另外，如果第一～第三验证处理部中的任意的验证结果为NG，则作为发送处理部的DCM12向中心装置3通知异常。

此外，在上述基础上，如图10所示，在存在用于返回到写入更新数据前的旧程序的状态的回滚数据时，也可以像以下那样实施。

·第四验证值生成部对于旧程序生成第四散列值(第四验证值生成步骤；步骤A5)。

·第五验证值生成部对于用于使新程序返回到旧程序的回滚数据生成第五散列值(第五验证值生成步骤；步骤A7)。回滚数据表示回滚用差分数据，与旧差分数据对应。

·包生成部202使分发包包含更新数据、回滚用差分数据、改写规格数据以及第一、第二、第三和第四散列值(分发包生成步骤)。

在该情况下，在车辆侧系统4中，在闪存28d中改写更新数据的期间，例如若由用户指示改写中止，则成为改写取消，进行向旧程序的恢复、即回滚。这只是ECU19的存储器结构为1面存储器的情况。

·第二验证处理部计算针对在分发包中包含的回滚数据的散列值，对计算出的散列值与第五散列值进行比较来验证回滚数据的完整性。

·CPU28a使用回滚数据来进行对闪存28d的写入。

·第一验证处理部对于通过对闪存28d的写入而恢复的旧程序，计算散列值，对计算出的散列值与第四散列值进行比较来验证旧程序的完整性。

像以上那样，根据第五实施方式，在ECU重配置数据DB204中存储有改写对象即目标ECU19的新程序、旧程序、以及用于从旧程序更新为新程序的新差分数据即更新数据。第一验证值生成部使用新程序而生成第一散列值，第二验证值生成部使用更新数据而生成第二散列值。包生成部202生成包，该包包含针对多个目标ECU19的更新数据、第一和第二验证值以及规格数据。第三验证值生成部使用分发包而生成第三散列值，包分发部203将分发包与第三散列值一同向车辆侧系统4发送。

车辆侧系统4若接收分发包和第三散列值，则第三验证处理部计算针对分发包的散列值，与第三散列值进行比较来验证分发包的完整性。第二验证处理部对于与在分发包中包含的目标ECU19对应的更新数据计算散列值，将其与在分发包中包含的第二散列值进行比较来验证更新数据的完整性。

CPU28a将更新数据写入闪存28d，第一验证处理部计算针对闪存28d的更新后的新程序的数据的散列值，将其与第一散列值进行比较来验证新程序的数据的完整性。这样，能够使用各散列值而在多个阶段验证各数据值的完整性。而且，对于新程序，能够三次验证完整性，能够避免车辆侧系统4写入不完整的新程序、以不正当的新程序进行动作。

另外，在ECU重配置数据DB204中存在回滚数据时，第四验证值生成部对于旧程序生成第四散列值，第五验证值生成部对于回滚数据生成第五散列值。包生成部202使分发包包含更新数据、第一和第二散列值、回滚数据、以及第四和第五散列值。

而且，在车辆侧系统4中进行回滚时，第二验证处理部计算针对在分发包中包含的回滚数据的散列值，与第五散列值进行比较来验证回滚数据的完整性。CPU28a使用回滚数据而进行对闪存28d的写入。第一验证处理部对于通过对闪存28d的写入而恢复的旧程序计算散列值，与第四散列值进行比较来验证旧程序的完整性。由此，对于被回写的旧程序也能够验证完整性。在上述中，第一～第五验证值生成部是中心装置3的包管理部3A内的功能模块。第一、第二、第四和第五验证处理部是车辆侧系统4的目标ECU19内的功能模块。另外，第三验证处理部是车辆侧系统4的主装置11(OTA主机11)内的功能模块。

(第一实施方式的变形其一)

也可以如图32和图33所示，使一个活动“cpn_001”对应多个包“pkg_001_1”和“pkg_001_2”。另外，也可以将多个包作为多个组。在上述的实施例中，采用在一个包中包含多个组的结构。在本变形例中，利用一个组生成一个包，对于一个活动分发多个包。例如，在包“pkg_001_1”中包含属于组1的ECU即“ADS”和“BRK”，在包“pkg_001_2”中包含属于组2的ECU即“EPS”。

在该情况下，如图34和图35所示，按照每个组独立地生成规格数据和分发包。在图34中，作为组1的规格数据，规格数据生成部201例如生成记载了“ADS”和“BRK”的ECU信息的第一规格数据。作为组2的规格数据，规格数据生成部201例如生成记载了“EPS”的ECU信息的第二规格数据。而且，在图35中，包生成部202例如生成根据ECU顺序将属于组1的“ADS”和“BRK”的更新数据等进行合并而得的重编数据，与第一规格数据合并而生成包文件“pkg001_1.dat”。包生成部202使用属于组2的“EPS”的更新数据等而生成重编数据，与第二规格数据合并而生成包文件“pkg001_2.dat”。

(第一实施方式的变形其二)

图36表示将规格数据生成部201和包生成部202的功能合并而构成一个包生成工具221的情况下的处理内容。以下，对各处理重新进行说明。

在规格数据生成处理中，将作为规格数据信息由作业者输入的值以比特数和排列顺序被预先决定的数据构造输出，生成规格数据。作为规格数据信息，例如为图17中例示的值，除了ECU(ID1)、ECU(ID2)、ECU(ID3)这样的ECU单位的信息之外，还输入车辆单位或者系统(组)单位的信息。车辆单位的信息例如是指图17所示的改写环境信息，系统单位的信息例如是指图17所示的组信息、ECU顺序的信息。车辆单位、系统单位的输入信息也可以分别作为不同的文件。也可以使规格数据生成处理具有自动地计算更新数据的文件大小等一部分的值并使其反映到规格数据的功能。

在包生成处理中，将作为所生成的规格数据、各ECU的更新数据、各ECU的完整性验证数据而输入的值、文件以比特数、排列顺序被预先决定的数据构造输出，并生成分发包的文件。各ECU的更新数据和完整性验证数据按照组的从小到大的顺序、ECU的从小到大的顺序排列。这里，除了更新数据(新差分数据)之外，还可以将回滚用数据(旧差分数据)添加到输入中。作为完整性验证数据，输入“ECU程序(新)的完整性验证数据”、“更新数据的完整性验证数据”。在还添加回滚数据的情况下，还将“ECU旧程序的完整性验证数据”、“旧差分数据的完整性验证数据”添加到输入中。

在完整性验证数据生成处理中，如图19的步骤C4所述，对于所生成的包文件生成完整性验证数据。

所生成的包文件、对于包文件生成的完整性验证数据由作业者登记于包DB206。

(其他的实施方式)

中心装置3执行的功能也可以由硬件实现，也可以由软件实现。另外，也可以通过硬件与软件的配合而实现。

所改写的数据不仅是应用程序，也可以是地图等数据、控制参数等数据。

结构信息的内容不限于例示的内容，只要根据个别的设计而适当地选择即可。

规格数据的内容也不限于例示的内容。

活动信息、分发规格数据也可以包含于分发包而向车辆侧发送，也可以与分发包独立地向车辆侧发送。

在第五实施方式中，也可以预先将分发包和第三验证值存储于包存储部，包发送部213根据来自车载侧系统4的请求，向车载侧系统4发送与该请求相关联的分发包和第三验证值。

以下，参照附图对以车辆用程序改写系统1的动作为中心的第六实施方式进行说明。车辆用程序改写系统(相当于车辆用电子控制系统)是能够通过OTA(Over The Air)来改写搭载于电子控制装置(以下，称为ECU(Electronic Control Unit：电子控制单元))的车辆控制、诊断等应用程序的系统。在本实施方式中，对利用有线或者无线改写应用程序的情况进行说明，但例如也能够应用于利用有线或者无线来改写在地图应用中使用的地图数据、在ECU中使用的控制参数等在各种应用中使用的数据的情况。

利用有线的应用程序的改写除了包含经由有线从车辆外部获取应用程序并进行改写之外，还包含经由有线从车辆外部获取在执行应用程序时使用的各种数据并进行改写。利用无线的应用程序的改写除了包含经由无线从车辆外部获取应用程序并进行改写之外，还包含经由无线从车辆外部获取在执行应用程序时使用的各种数据并进行改写。

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

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

用户如果在车室外且在移动体通信网络的通信圈内，则能够一边通过便携终端6确认与应用程序的改写相关联的各种画面一边进行操作输入，能够进行与应用程序的改写相关联的手续。用户能够在车室内，一边通过车载显示器7确认与应用程序的改写相关联的各种画面一边进行操作输入，能够进行与应用程序的改写相关联的手续。即，用户能够在车室外和车室内分开使用便携终端6和车载显示器7，能够进行与应用程序的改写相关联的手续。

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

文件服务器8是对从中心装置3向车辆侧系统4分发的应用程序的文件进行管理的服务器。文件服务器8对从供应商等提供的更新数据(以下，也称为重编数据、写入数据)、从OEM(Original Equipment Manufacturer)提供的分发规格数据、从车辆侧系统4获取的车辆状态等进行管理，该供应商是从中心装置3向车辆侧系统4分发的应用程序的提供企业。文件服务器8能够经由通信网络2而在与车辆侧系统4之间进行数据通信，若产生分发包的下载请求，则将重编数据和分发规格数据打包为一个文件的分发包向车辆侧系统4发送。

网络服务器9是管理网络信息的服务器。网络服务器9根据来自便携终端6等所具有的网络浏览器的请求而发送自身管理的网络数据。管理服务器10是对在应用程序的改写的服务中登记的用户的个人信息、每个车辆的应用程序的改写历史等进行管理的服务器。

车辆侧系统4具有主装置11(相当于车辆用主装置)。主装置11具有DCM(DataCommunication Module：数据通信模块)12(相当于车载通信机)、CGW(Central Gate Way：中央通道)13(相当于车辆用网关装置)。DCM12与CGW13经由第一总线14而连接成能够进行数据通信。DCM12在与中心装置3之间经由通信网络2进行数据通信。DCM12若从文件服务器8下载分发包，则从该下载的分发包中提取写入数据，向CGW13传输该提取出的写入数据。

CGW13具有数据中继功能，若从DCM12获取写入数据，则对应用程序的改写对象即改写对象ECU指示该获取的写入数据的写入，向改写对象ECU分发写入数据。另外，若在改写对象ECU中写入数据的写入完成，应用程序的改写完成，则CGW13向改写对象ECU指示使该改写完成后的应用程序为有效的激活。

主装置11在车辆用程序改写系统1中总括车辆侧的程序更新功能，作为OTA主机发挥功能。另外，在图37中，例示DCM12和车载显示器7与同一个第一总线14连接的结构，也可以是DCM12和车载显示器7与不同的总线连接的结构。另外，也可以是CGW13具有DCM12的功能的一部分或者整体的结构，也可以是DCM12具有CGW13的功能的一部分或者整体的结构。即，在主装置11中，DCM12与CGW13的功能分担也可以任意构成。主装置11也可以由DCM12和CGW13这两个ECU构成，也可以由具有DCM12的功能和CGW13的功能的一个合并ECU构成。

除了第一总线14之外，第二总线15、第三总线16、第四总线17和第五总线18也作为车内侧的总线而与CGW13连接，经由总线15～17连接有各种ECU19，并且经由总线18连接有电源管理ECU20。

第二总线15例如是车身系统网络的总线。与第二总线15连接的ECU19是进行车身系统的控制的ECU。进行车身系统的控制ECU例如是控制车门的锁定/解锁的车门ECU、控制在仪表显示器上的显示的仪表ECU、控制空调的驱动的空调ECU、控制车窗的开闭的车窗ECU、为了防止车辆被盗取而驱动的安全ECU等。

第三总线16例如是行驶系统网络的总线。与第三总线16连接的ECU19是进行行驶系统的控制的ECU。进行行驶系统的控制的ECU例如是控制发动机的驱动的发动机ECU、控制制动器的驱动的制动器ECU、控制自动变速器的驱动的ECT(Electronic ControlledTransmission：电子控制传输)ECU、控制动力转向的驱动的动力转向ECU等。

第四总线17例如是多媒体系统网络的总线。与第四总线17连接的ECU19是进行多媒体系统的控制的ECU。进行多媒体系统的控制的ECU例如是用于控制导航系统的导航ECU、控制电子式收费系统(ETC(Electronic Toll Collection System、注册商标))的ETCECU等。总线15～17也可以是车身系统网络的总线、行驶系统网络的总线、多媒体系统网络的总线以外的系统的总线。另外，总线的根数、ECU19的个数不限于例示的结构。

电源管理ECU20是管理对DCM12、CGW13、各种ECU19等供给的电源的ECU。

第六总线21作为车外侧的总线而与CGW13连接。在第六总线21连接有DLC(DataLink Coupler：数据链路耦合器)连接器22，该DLC(Data Link Coupler)连接器22可装卸地与工具23(相当于服务工具)连接。车内侧的总线14～18和车外侧的总线21例如由CAN(Controller Area Network、注册商标)总线构成，CGW13根据CAN的数据通信标准、诊断通信标准(UDS(Unified Diagnosis Services：统一诊断服务)：ISO14229)而在DCM12、各种ECU19与工具23之间进行数据通信。另外，DCM12与CGW13也可以通过以太网连接，DLC连接器22与CGW13也可以通过以太网连接。

改写对象ECU19若从CGW13接收写入数据，则将该接收到的写入数据写入闪存(相当于非易失性存储器)而改写应用程序。在上述的结构中，CGW13作为如下的重编主机发挥功能，即若从改写对象ECU19接收写入数据的获取请求则向改写对象ECU19分发写入数据。改写对象ECU19作为如下的重编从机发挥功能，即若从CGW13接收写入数据则将该接收到的写入数据写入闪存而改写应用程序。

作为改写应用程序的形式，存在利用有线改写的形式和利用无线改写的形式。利用有线改写应用程序的形式是指使用经由有线从车辆外部获取的应用程序而对改写对象ECU19进行改写的形式。具体而言，若工具23与DLC连接器22连接，则工具23向CGW13传输写入数据。CGW13作为网关发挥功能，向改写对象ECU19发送有线改写请求，对改写对象ECU19指示写入数据的写入(安装)，向改写对象ECU19分发从工具23传输来的写入数据。向改写对象ECU19分发写入数据是指对写入数据进行中继。

利用无线改写应用程序的形式是指使用经由无线从车辆外部获取的应用程序而对改写对象ECU19进行改写的形式。具体而言，DCM12若从文件服务器8下载分发包，则从该下载的分发包中提取写入数据，向CGW13传输该写入数据。CGW13作为改写工具发挥功能，向改写对象ECU19指示写入数据的写入(安装)，向改写对象ECU19分发从DCM12传输来的写入数据。

作为诊断ECU19的形式，存在利用有线诊断的形式和利用无线诊断的形式。利用有线诊断的形式是指经由有线从车辆外部诊断ECU19的形式。具体而言，若工具23与DLC连接器22连接，则工具23向CGW13传输诊断请求。CGW13作为网关发挥功能，向诊断对象ECU19发送诊断请求，向诊断对象ECU19分发从工具23传输来的诊断指令。诊断对象ECU19进行与从CGW13接收到的诊断指令对应的诊断处理。

利用无线诊断的形式是指经由无线从车辆外部诊断ECU19的形式。具体而言，若从中心装置3对DCM12发送诊断指令来作为诊断请求，则DCM12向CGW13传输诊断指令。CGW13作为网关发挥功能，作为诊断请求将诊断指令向诊断对象ECU19分发。诊断对象ECU进行与从CGW13接收到的诊断指令对应的诊断处理。

如图38所示，作为电功能模块，CGW13具有微型计算机(以下，称为微机)24、数据传输电路25、电源电路26、以及电源检测电路27。微机24具有CPU(Central Processing Unit)24a、ROM(Read Only Memory)24b、RAM(Random Access Memory)24c、以及闪存24d。在闪存24d中包含不能从CGW13的外部读出信息的安全区域。微机24执行储存于非迁移实体存储介质的各种控制程序而进行各种处理，控制CGW13的动作。

数据传输电路25控制与总线14～18、21之间的依据CAN的数据通信标准、诊断通信标准的数据通信。电源电路26输入电池电源(以下，称为+B电源)、辅助电源(以下，称为ACC电源)、点火电源(以下，称为IG电源)。电源检测电路27对由电源电路26输入的+B电源的电压值、ACC电源的电压值、IG电源的电压值进行检测，将这些检测出的电压值与规定的电压阈值进行比较，向微机24输出该比较结果。微机24根据从电源检测电路27输入的比较结果，判定从外部向CGW13供给的+B电源、ACC电源、IG电源是正常还是异常。

如图39所示，作为电功能模块，DCM12具有微机28、无线电路29、数据传输电路30、电源电路31、以及电源检测电路32。微机28具有CPU28a、ROM28b、RAM28c、以及闪存28d。在闪存28d中包含不能从DCM12的外部读出信息的安全区域。微机28执行储存于非迁移实体存储介质的各种控制程序而进行各种处理，控制DCM12的动作。用于保存从中心装置3下载的数据的闪存也可以配置于CGW13。

无线电路29控制经由通信网络2的与中心装置3的数据通信。数据传输电路30控制与总线14之间的依据CAN的数据通信标准的数据通信。电源电路31输入+B电源、ACC电源、IG电源。电源检测电路32对由电源电路31输入的+B电源的电压值、ACC电源的电压值、IG电源的电压值进行检测，将这些检测出的电压值与规定的电压阈值进行比较，向微机28输出该比较结果。微机28根据从电源检测电路32输入的比较结果，而判定从外部向DCM12供给的+B电源、ACC电源、IG电源是正常还是异常。

另外，DCM12例如具有通过GPS(Global Positioning System：全球定位系统)来检测车辆位置的车辆位置检测功能。DCM12的闪存28d具有能够存储从中心装置3下载的分发包的足够的存储器容量，具有比CGW13的闪存24d大的存储器容量。即，由于采用DCM12的闪存28d具有足够的存储器容量的结构，因而即使不采用CGW13的闪存24d具有足够的存储器容量的结构，在主装置11中，也能够从中心装置3下载分发包，将该下载的分发包积蓄于DCM12。

如图40所示，作为电功能模块，ECU19具有微机33、数据传输电路34、电源电路35、以及电源检测电路36。微机33具有CPU28a、ROM28b、RAM33c、以及闪存28d。在闪存28d中包含不能从ECU19的外部读出信息的安全区域。微机33执行储存于非迁移实体存储介质的各种控制程序而进行各种处理，控制ECU19的动作。

数据传输电路34控制与总线15～17之间的依据CAN的数据通信标准的数据通信。电源电路35输入+B电源、ACC电源、IG电源。电源检测电路36对由电源电路35输入的+B电源的电压值、ACC电源的电压值、IG电源的电压值进行检测，将这些检测出的电压值与规定的电压阈值进行比较，向微机33输出该比较结果。微机33根据从电源检测电路27输入的比较结果，而判定从外部向ECU19供给的+B电源、ACC电源、IG电源是正常还是异常。另外，关于ECU19，自身连接的例如传感器、致动器等负荷不同，基本上是同等的结构。

车载显示器7具有与图40所示的ECU19相同的结构。电源管理ECU20具有与图40所示的ECU19相同的结构。电源管理ECU20在与后述的电源控制电路43之间连接成能够进行数据通信。

如图41所示，电源管理ECU20、CGW13、ECU19与电源供给线即+B电源线37、ACC电源线38、IG电源线39连接。+B电源线37与车辆电池40的正极连接。ACC电源线38经由ACC开关41与车辆电池40的正极连接。若用户进行ACC操作，则ACC开关41从断开切换为接通，对ACC电源线38施加车辆电池40的输出电压。所谓ACC操作，例如如果是将钥匙插入到插入口的类型的车辆，则是将钥匙插入到插入口而从“OFF”位置转动到“ACC”位置的操作，如果是按下开始按钮的类型的车辆，则是将开始按钮按下一次的操作。

IG电源线39经由IG开关42与车辆电池40的正极连接。若用户进行IG操作，则IG开关42从断开切换为接通，对IG电源线39施加车辆电池40的输出电压。所谓IG操作，例如如果是将钥匙插入到插入口的类型的车辆，则是将钥匙插入到插入口而从“OFF”位置转动到“ON”位置的操作，如果是按下开始按钮的类型的车辆，则是将开始按钮按下二次的操作。车辆电池40的负极接地。

在ACC开关41和IG开关42双方断开时，仅向车辆侧系统4供给+B电源。将仅向车辆侧系统4供给+B电源的状态称为+B电源状态。在ACC开关41接通、IG开关42断开时，向车辆侧系统4供给ACC电源和+B电源。将向车辆侧系统4供给ACC电源和+B电源的状态称为ACC电源状态。在ACC开关41和IG开关42双方接通时，向车辆侧系统4供给+B电源、ACC电源和IG电源。将向车辆侧系统4供给+B电源、ACC电源和IG电源的状态称为IG电源状态。另外，除了上述的各电源状态之外，还考虑施加适合基于无线的程序更新的电源的电源状态等。

ECU19的启动条件根据电源状态而不同，ECU19被区分为在+B电源状态下启动的+B电源系统ECU、在ACC电源状态下启动的ACC系统ECU、在IG电源状态下启动的IG系统ECU。例如在车辆被盗取等的用途中驱动的ECU19被区分为+B电源系统ECU。例如在音响等非行驶系的用途中驱动的ECU19被区分为ACC系统ECU。例如在发动机控制等行驶系的用途中驱动的ECU19被区分为IG系统ECU。

+B电源系统ECU构成为，与+B电源线37、ACC电源线38和IG电源线39连接，在+B电源状态时选择+B电源线37，在ACC电源状态时选择ACC电源线38，在IG电源状态时选择IG电源线39。ACC系统ECU构成为，与ACC电源线38和IG电源线39连接，在ACC电源状态时选择ACC电源线38，在IG电源状态时选择IG电源线39。IG系统ECU与IG电源线39连接。

CGW13通过向处于休眠状态的ECU19发送启动请求，而使该启动请求的发送目的地的ECU19从休眠状态转移至启动状态。另外，CGW13通过向处于启动状态的ECU19发送休眠请求，而使该休眠请求的发送目的地的ECU19从启动状态转移至休眠状态。CGW13例如通过使向总线15～17发送的发送信号的波形不同，能够使确定的ECU19转移至启动状态或者休眠状态。即，针对每个ECU19预先决定启动请求波形和休眠请求波形，ECU19若接收适合自身的启动请求波形，则从休眠状态转移至启动状态，若从CGW13接收适合自身的休眠请求波形，则从启动状态转移至休眠状态。

CGW13例如通过在ECU(ID1)和ECU(ID2)处于启动状态的情况下发送第一波形，而使ECU(ID1)从启动状态转移至休眠状态，将ECU(ID2)保持在启动状态。另外，CGW13通过在ECU(ID1)和ECU(ID2)处于启动状态的情况下发送第二波形，而将ECU(ID1)保持在启动状态，使ECU(ID2)从启动状态转移至休眠状态。

电源控制电路43与ACC开关41和IG开关42并联连接。CGW13向电源管理ECU20发送电源控制请求，使电源管理ECU20控制电源控制电路43。即，CGW13通过向电源管理ECU20发送电源启动请求来作为电源控制请求，而使ACC电源线38、IG电源线39与车辆电池40的正极在电源控制电路43的内部连接。在该状态下，即使ACC开关41、IG开关42断开也将ACC电源、IG电源向车辆侧系统4供给。另外，CGW13通过向电源管理ECU20发送电源停止请求来作为电源控制请求，而使ACC电源线38、IG电源线39与车辆电池40的正极在电源控制电路43的内部隔断。

DCM12、CGW13、ECU19、电源管理ECU20分别具有电源自保持电路，具有保持来自车辆电池40的电源供给的电源自保持功能。即，DCM12、CGW13、ECU19、电源管理ECU20若在处于启动状态时车辆电源从ACC电源或者IG电源切换为+B电源，则并不是在该切换之后立即从启动状态转移至停止状态或者休眠状态，而是通过来自车辆电池40的电源供给使启动状态持续规定时间(例如几分钟)而自保持驱动电源。DCM12、CGW13、ECU19、电源管理ECU20在车辆电源从ACC电源或者IG电源切换到+B电源之后经过了规定时间后从启动状态转移至停止状态或者休眠状态。例如如果是发动机控制系统的ECU19，则通过在车辆电源从ACC电源或者IG电源切换到+B电源之后电源自保持功能进行动作，从而将在车辆行驶中获取的与发动机控制相关的各种数据存储为日志。

接下来，对从中心装置3向主装置11分发的分发包进行说明。如图41所示，在车辆用程序改写系统1中，根据从应用程序的提供企业即供应商提供的写入数据、从OEM提供的改写规格数据(相当于规格数据)而生成重编数据。也可以利用中心装置3生成改写规格数据。作为从供应商提供的写入数据，存在与旧应用程序与新应用程序的差分相当的差分数据、与新应用程序的整体相当的整体数据。差分数据、整体数据也可以通过公知的数据压缩技术进行压缩。在图42中，例示了如下的情况，从供应商A～C提供差分数据来作为写入数据，根据从供应商A提供的ECU(ID1)的加密完毕的差分数据和认证符、从供应商B提供的ECU(ID2)的加密完毕的差分数据和认证符、从供应商C提供的ECU(ID3)的加密完毕的差分数据和认证符、从OEM提供的改写规格数据而生成重编数据。

认证符是为了验证差分数据的完整性而对每个写入数据赋予的数据，例如根据ECU(ID)、与该ECU(ID)关联的密钥信息和差分数据而生成。这里，在中途取消应用程序的改写的情况下，向旧版本的回写(回滚)用的写入数据也可以包含于重编数据。

作为与应用程序的改写相关联的信息，从OEM提供的改写规格数据包含能够确定改写对象ECU19的信息、能够确定在改写对象ECU19为多个情况下的改写顺序的信息、以及能够确定后述的回滚方法的信息等。改写规格数据是对DCM12、CGW13、改写对象ECU19等中的与改写相关联的动作进行定义的数据。改写规格数据被区分为DCM12使用的DCM用的改写规格数据、CGW13使用的CGW用的改写规格数据。

如图43所示，DCM用的改写规格数据包含规格数据信息和ECU信息。规格数据信息包含地址信息和文件名。ECU信息包含与改写对象ECU19的个数对应的数量的在将各改写对象ECU19的更新程序(写入数据)向CGW13发送时参照的地址信息等。具体而言，ECU信息至少包含：识别ECU的ID(ECU(ID))、获取更新程序时的参照地址(更新程序获取地址)、更新程序大小、获取回滚程序时的参照地址(回滚程序获取地址)、以及回滚程序大小。回滚程序是在中途取消应用程序的改写时，用于使应用程序返回到原来的版本的程序(写入数据)。

如图44所示，CGW用的改写规格数据包含组信息、总线负荷表、电池负荷、改写时的车辆状态、以及ECU信息。除此之外，CGW用的改写规格数据也可以包含改写顺序信息和显示的场景信息等。组信息是表示改写对象ECU19所属的组和改写顺序的信息，例如作为第一组信息，规定了按照ECU(ID1)、ECU(ID2)、ECU(ID3)的顺序改写应用程序的内容，作为第二组信息，规定了按照ECU(ID4)、ECU(ID5)、ECU(ID6)的顺序改写应用程序的内容。总线负荷表是后述的图136所示的表，详细情况后述说明。电池负荷是表示在车辆中能够允许的车辆电池40的电池余量的下限值的信息。改写时的车辆状态是表示在车辆状态处于怎样的情况下进行改写的信息。

ECU信息是与改写对象ECU19相关的信息，至少包含ECU_ID(相当于装置识别信息)、连接总线(相当于总线识别信息)、连接电源、安全访问密钥信息、存储器种类、改写方法、电源自保持时间、改写面信息、更新程序版本、更新程序获取地址、更新程序大小、回滚程序版本、回滚程序获取地址、回滚程序大小和写入数据种类。

连接总线表示连接有ECU19的总线。连接电源表示连接有ECU19的电源线。安全访问密钥信息表示用于由CGW13访问改写对象ECU19的认证所使用的密钥信息，包含随机数值或者唯一的信息、密钥模式和解码运算模式。存储器种类表示搭载于改写对象ECU19的存储器是1面独立存储器、1面挂起挂起存储器(也称为模拟2面存储器)、2面存储器中的哪一个。改写方法表示是基于电源自保持的改写或者基于电源控制的改写中的哪一种。电源自保持时间表示在改写方法为基于电源自保持的改写的情况下，持续电源自保持的时间。改写面信息表示哪个面是运用面，哪个面是非运用面。运用面也称为启动面，非运用面也称为改写面。

更新程序版本表示更新程序的版本。更新程序获取地址表示更新程序的地址。更新程序大小表示更新程序的数据大小。回滚程序版本表示回滚程序的版本。回滚程序获取地址表示回滚程序的地址。回滚程序大小表示回滚程序的数据大小。写入数据种类表示写入数据是差分数据或者全部数据中的哪个种类。另外，在改写规格数据中除了包含这些信息之外，还能够包含利用系统独自定义的信息。

DCM12若获取DCM用的改写规格数据，则对该获取的DCM用的改写规格数据进行解析。DCM12若对DCM用的改写规格数据进行解析，则从储存有改写对象ECU19的更新程序的地址获取写入数据，控制将该获取的写入数据向CGW13传输等与改写相关联的动作。

CGW13若获取CGW用的改写规格数据，则对该获取的CGW用的改写规格数据进行解析。CGW13若对CGW用的改写规格数据进行解析，则根据该解析结果，控制如下的与改写相关联的动作，向DCM12请求改写对象ECU19的更新程序的规定大小量的传输、或者以指定的顺序将写入数据向改写对象ECU19分发等。

在文件服务器8中登记上述的重编数据，并且登记从OEM提供的分发规格数据。从OEM提供的分发规格数据是对与显示终端5中的各种画面的显示相关联的动作进行定义的数据。如图45所示，分发规格数据包含语言信息、显示语句、包信息、图像数据、显示模式和显示控制程序等。

显示终端5若从CGW13获取分发规格数据，则进行该获取的分发规格数据解析，根据该解析结果而控制各种画面的显示。显示终端5例如相对于预先保存的显示用帧，重叠地显示从分发规格数据获取的显示语句、或者执行从分发规格数据获取的显示控制程序。另外，在分发规格数据中除了包含这些信息之外，还能够包含利用系统独自定义的信息。

文件服务器8若登记重编数据和分发规格数据，则对该登记的重编数据进行加密化，生成储存了用于认证包的包认证符、加密完毕的重编数据、分发规格数据的分发包。认证符是为了验证重编数据和分发规格数据的完整性而赋予的数据，例如是根据与CGW13相关联的密钥信息、重编数据和分发规格数据而生成的。文件服务器8若从外部接收分发包的下载请求，则向DCM12发送该分发包。另外，在图42中，例示了文件服务器8生成储存了重编数据和分发规格数据的分发包，并将重编数据和分发规格数据作为一个文件同时向DCM12发送的情况，但也可以将重编数据和分发规格数据作为不同的文件向DCM12发送。即，文件服务器8也可以先将分发规格数据向DCM12发送，然后将重编数据向DCM12发送。在该情况下，可以对分发规格数据、重编数据分别赋予认证符。

如图46所示，DCM12若从文件服务器8下载分发包，则使用储存于该下载的分发包的包认证符，来验证加密完毕的重编数据的完整性。若验证结果为正，则DCM12对加密完毕的重编数据进行解码化。DCM12若对加密完毕的重编数据进行解码化，则对该解码化的重编数据进行解封(以下，也称为解包)，分割为加密完毕的差分数据和认证符、DCM用的改写规格数据、CGW用的改写规格数据并提取。在图46中，例示了分割为ECU(ID1)的加密完毕的差分数据和认证符、ECU(ID2)的加密完毕的差分数据和认证符、ECU(ID3)的加密完毕的差分数据和认证符、DCM用的改写规格数据、CGW用的改写规格数据并提取的情况。

接下来，参照图47至图58对ECU19的闪存33d进行说明。根据存储器结构，ECU19的闪存33d被区分为在1面具有闪存面的1面独立存储器、在模拟的2面具有闪存面的1面挂起存储器、在实质的2面具有闪存面的2面存储器。以下，将搭载1面独立存储器的ECU19称为1面独立存储器ECU，将搭载1面挂起存储器的ECU19称为1面挂起存储器ECU，将搭载2面存储器的ECU19称为2面存储器ECU。

1面独立存储器是在1面具有闪存面的结构，因此不存在称为运用面和非运用面的概念，在应用程序的执行中不能改写应用程序。另一方面，1面挂起存储器、2面存储器是在2面具有闪存面的结构，因此存在称为运用面和非运用面的概念，在运用面的应用程序的执行中能够改写非运用面的应用程序。2面存储器是在完全分离的2面具有闪存面的结构，因此在车辆行驶中等的任意的时机能够改写应用程序。1面挂起存储器是伪2面划分1面独立存储器的结构，因此在正常地进行读出、写入的时机存在制约，在车辆行驶中不能改写应用程序，在IG电源被断开的驻车中能够改写应用程序。

另外，1面独立存储器、1面挂起存储器、2面存储器分别存在嵌入了重编固件的重编固件嵌入型(以下，称为嵌入型)、从外部下载重编固件的重编固件下载型(以下，称为下载型)。重编固件是用于改写应用程序的固件。

以下，依次说明各闪存的结构。

(A)1面独立存储器

(A-1)嵌入型的1面独立存储器

参照图47和图48对嵌入型的1面独立存储器进行说明。嵌入型的1面独立存储器具有差分发动机工作区域、应用程序区域和启动程序区域。在应用程序区域配置有版本信息、参数数据、应用程序、固件和通常时向量表。在启动区域配置有启动程序、进展状态点2、进展状态点1、启动判定信息、无线重编固件、有线重编固件、启动判定用程序和启动时向量表。

如图47所示，微机33在执行车辆控制处理、诊断处理等应用处理的通常动作时，执行启动判定用程序，参照启动时向量表和通常时向量表来探索起始地址，执行应用程序的规定地址。

微机33在执行应用程序的改写处理的改写动作时，执行无线或者有线重编固件而不执行应用程序。图48表示使用差分数据作为更新程序来改写应用程序的动作。如图48所示，微机33使应用程序作为旧数据而暂时存蓄于差分发动机工作区域。微机33读出暂时存蓄于差分发动机工作区域的旧数据，通过在嵌入的重编固件中包含的差分发动机，根据该读出的旧数据和存储于RAM33c的差分数据来复元新数据。微机33若根据旧数据和差分数据生成新数据，则将该新数据写入存储器的规定地址而改写应用程序。

(A-2)下载型的1面独立存储器

参照图49和图50对下载型的1面独立存储器进行说明。下载型与上述的嵌入型进行比较，在如下的方面不同，从外部下载无线重编固件、有线重编固件，在改写了应用程序之后，删除该无线重编固件、有线重编固件。在利用无线更新应用程序的情况下，例如在图42所示的重编数据中包含由各ECU19执行的无线重编固件。ECU19从CGW13接收面向本ECU的无线重编固件，将该接收到的面向本ECU的无线重编固件保存于RAM。

如图49所示，微机33在执行车辆控制处理、诊断处理等应用处理的通常动作时，与嵌入型同样地，执行启动判定用程序，参照启动时向量表和通常时向量表来探索起始地址，并执行应用程序的规定地址。

如图50所示，微机33在执行应用程序的改写处理的改写动作时，将应用程序作为旧数据而暂时存蓄于差分发动机工作区域。微机33读出暂时存蓄于差分发动机工作区域的旧数据，通过在从外部下载的重编固件中包含的差分发动机，根据该读出的旧数据和存储于RAM33c的差分数据复元新数据。微机33若根据旧数据和差分数据生成新数据，则写入该新数据而改写应用程序。

(B)1面挂起存储器

(B-1)嵌入型的1面挂起存储器

参照图51和图52对嵌入型的1面挂起存储器进行说明。嵌入型的1面挂起存储器具有差分发动机工作区域、应用程序区域和启动程序区域。进行程序更新的重编固件与1面独立存储器同样，配置在启动程序区域，是程序更新的对象以外的对象。程序更新的对象即应用程序区域疑似具有A面和B面，在A面和B面分别配置有版本信息、应用程序和通常时向量表。在启动区域配置有启动程序、重编固件、重编时向量表、启动面判定功能、启动面判定信息和启动时向量表。

如图51所示，微机33在执行车辆控制处理、诊断处理等应用处理的通常动作时，执行启动程序，通过启动面判定功能，根据A面和B面的各启动面判定信息来判定A面和B面中的哪个是运用面。微机33若将A面判定为运用面，则参照A面的通常时向量表来探索起始地址，执行A面的应用程序。同样，微机33若将B面判定为运用面，则参照B面的通常时向量表来探索起始地址，执行B面的应用程序。另外，在图51中，将重编固件配置于启动程序区域，但也可以构成为，使重编固件为程序更新的对象，配置在A面或者B面的各自区域。

如图52所示，微机33在执行非运用面的应用程序的改写处理的改写动作时，将非运用面的应用程序作为旧数据而暂时存蓄于差分发动机工作区域。微机33读出暂时存蓄于差分发动机工作区域的旧数据，通过嵌入的重编固件内的差分发动机，根据该读出的旧数据和存储于RAM33c的差分数据而复元新数据。微机33若根据旧数据和差分数据生成新数据，则将该新数据写入非运用面而改写非运用面的应用程序。在图52中，例示了A面为运用面、B面为非运用面的情况。

(B-2)下载型的1面挂起存储器

参照图53和图54对下载型的1面挂起存储器进行说明。下载型与上述的嵌入型进行比较，在如下的方面不同，从外部下载重编固件和重编时向量表，在改写了应用程序之后，删除该重编固件和重编时向量表。

如图53所示，微机33在执行车辆控制处理、诊断处理等应用处理的通常动作时，与嵌入型同样执行启动程序，通过启动面判定功能，根据A面和B面的各启动面判定信息来判定新旧，判定A面和B面中的哪个是运用面。微机33若将A面判定为运用面，则参照A面的通常时向量表来探索起始地址，执行A面的应用程序。同样，微机33若将B面判定为运用面，则参照B面的通常时向量表来探索起始地址，执行B面的应用程序。

如图54所示，微机33在执行应用程序的改写处理的改写动作时，将非运用面的应用程序作为旧数据而暂时存蓄于差分发动机工作区域。微机33读出暂时存蓄于差分发动机工作区域的旧数据，通过从外部下载的重编固件内的差分发动机，根据该读出的旧数据和存储于RAM33c的差分数据而复元新数据。微机33若根据旧数据和差分数据生成新数据，则写入该新数据而改写应用程序。在图54中，例示了A面为运用面、B面为非运用面的情况。这样，在1面挂起存储器中，能够执行A面的应用程序，并且在后台执行B面的应用程序的改写。

(C)2面存储器

(C-1)嵌入型的2面存储器

参照图55和图56对嵌入型的2面存储器进行说明。嵌入型的1面独立存储器具有A面的应用程序区域和改写程序区域、B面的应用程序区域和改写程序区域、以及启动程序区域。启动程序以不能改写的方式配置于启动区域。启动程序包含启动交换功能和启动时向量表。在各应用程序区域配置有版本信息、参数数据、应用程序、固件和通常时向量表。在各改写程序区域配置有控制改写的程序、重编进展管理信息2、重编进展管理信息1、启动面判定信息、无线重编固件、有线重编固件和启动时向量表。在启动区域配置有启动程序、启动交换功能和启动时向量表。

如图55所示，微机33在执行车辆控制处理、诊断处理等应用处理的通常动作时以及执行非运用面的应用程序的改写处理的改写动作时都执行启动程序，根据A面和B面的各启动面判定信息，通过启动交换功能而判定新旧，判定A面和B面中的哪个为运用面。微机33若将A面判定为运用面，则参照A面的启动时向量表和A面的通常时向量表来探索起始地址，执行A面的应用程序。同样，微机33若将B面判定为运用面，则参照B面的启动时向量表和B面的通常时向量表来探索起始地址，执行B面的应用程序。

如图56所示，微机33在执行非运用面的应用程序的改写处理的改写动作时，将非运用面的应用程序作为旧数据而暂时存蓄于差分发动机工作区域。微机33读出暂时存蓄于差分发动机工作区域的旧数据，通过嵌入的重编固件内的差分发动机，根据该读出的旧数据和存储于RAM33c的差分数据而复元新数据。微机33若根据旧数据和差分数据生成新数据，则将该新数据写入非运用面而改写非运用面的应用程序。另外，暂时存蓄于差分发动机工作区域的旧数据也可以以运用面的应用程序为对象，也可以以非运用面的应用程序为对象。此时，在以运用面的应用程序为对象的情况下，在新数据的写入前消除非运用面的数据。这里，在从车辆外部获取的重编数据不是差分数据而是整体数据(全部数据)的情况下，将所获取的重编数据作为新数据而写入非运用面。在图56中，例示了A面为运用面、B面为非运用面的情况。另外，暂时存蓄于差分发动机工作区域的旧数据也可以以运用面的应用程序为对象，也可以以非运用面的应用程序为对象。在需要使应用程序的执行地址一致的情况下，将非运用面的应用程序作为旧数据而进行存蓄。

(C-2)下载型的2面存储器

参照图57和图58对下载型的2面存储器进行说明。下载型与上述的嵌入型进行比较，在如下的方面不同，从外部下载无线重编固件、有线重编固件，在改写应用程序之后，删除该无线重编固件、有线重编固件。

如图57所示，微机33在执行车辆控制处理等应用处理、诊断处理的通常动作时以及执行非运用面的应用程序的改写处理的改写动作时，都与嵌入型同样，执行启动程序，根据A面和B面的各启动面判定信息，通过启动交换功能来判定新旧，判定A面和B面中的哪个为运用面，执行运用面的应用程序而执行应用处理。

如图58所示，微机33在执行应用程序的改写处理的改写动作时，将非运用面的应用程序作为旧数据而暂时存蓄于差分发动机工作区域。微机33读出暂时存蓄于差分发动机工作区域的旧数据，根据该读出的旧数据以及通过从外部下载的重编固件而存储于RAM33c的差分数据来复元新数据。微机33若根据旧数据和差分数据生成新数据，则将该新数据写入非运用面而改写非运用面的应用程序。另外，暂时存蓄于差分发动机工作区域的旧数据也可以以运用面的应用程序为对象，也可以以非运用面的应用程序为对象。此时，在以运用面的应用程序为对象的情况下，在新数据的写入前消除非运用面的数据。这里，在从车辆外部获取的重编数据不是差分数据而是整体数据(全部数据)的情况下，将所获取的重编数据作为新数据而写入非运用面。在图58中，例示了A面为运用面、B面为非运用面的情况。另外，暂时存蓄于差分发动机工作区域的旧数据也可以以运用面的应用程序为对象，也可以以非运用面的应用程序为对象。这样，在2面存储器中，能够执行A面的应用程序，并且在后台执行B面的应用程序的改写。

像上述那样，在嵌入型和下载型中的任意结构中，在各应用区域配置有应用程序和用于改写应用程序的改写程序。另外，在图56和图58中，将应用程序作为重编对象而示出，但改写程序也可以作为重编对象。另外，在希望使改写程序不能改写的情况下，也可以将改写程序配置于启动区域。例如也可以在启动区域中配置用于有线改写的程序，使得经销商等能够可靠地实施经由工具23的利用有线的改写。

接下来，参照图59至图61对改写应用程序的整体顺序进行说明。另外，这里，关于用户对作为显示终端5的便携终端6进行操作而在驻车中改写应用程序的情况进行说明，操作车载显示器7而在驻车中改写应用程序的情况也同样。在从中心装置3向DCM12发送的分发包储存有一个以上的改写对象ECU19的写入数据。即，在分发包中，如果改写对象ECU19为一个，则储存有朝向该一个改写对象ECU19的一个写入数据，如果改写对象ECU19为多个，则储存有朝向该多个改写对象ECU19中的每一个的多个写入数据。这里，改写对象ECU19为两个，将两个改写对象ECU19称为改写对象ECU(ID1)和改写对象ECU(ID2)。另外，将改写对象ECU(ID1)和改写对象ECU(ID2)以外的ECU19称为其他的ECU。

改写对象ECU(ID1)和改写对象ECU(ID2)若分别判定为例如从主装置11接收到版本通知信号的发送请求，则判定为版本通知信号的发送条件成立。若版本通知信号的发送条件成立，则改写对象ECU(ID1)向主装置11发送包含自身存储的应用程序的版本信息和能够识别自身的ECU(ID)在内的版本通知信号。主装置11若从改写对象ECU(ID1)接收版本通知信号，则向中心装置3发送该接收到的版本通知信号。同样，若版本通知信号的发送条件成立，则改写对象ECU(ID2)向主装置11发送包含自身存储的应用程序的版本和能够识别自身的ECU(ID)的版本通知信号。主装置11若从改写对象ECU(ID2)接收版本通知信号，则向中心装置3发送该接收到的版本通知信号。

中心装置3若从改写对象ECU(ID1)和改写对象ECU(ID2)接收到版本通知信号，则确定该接收到的版本通知信号中包含的应用程序的版本和ECU(ID)，判定应该向该版本通知信号的发送源的改写对象ECU19分发的写入数据的有无。中心装置3根据从改写对象接收到的版本通知信号来确定改写对象ECU19的当前的应用程序的版本，对该当前的应用程序的版本和管理的最新的版本进行对照。

如果根据版本通知信号确定的版本与管理的最新的版本为相同的值，则中心装置3判定为不存在应该向该版本通知信号的发送源的改写对象ECU19分发的写入数据，不需要更新存储于改写对象ECU19的应用程序。另一方面，如果根据版本通知信号确定的版本与管理的最新的版本相比为较小的值，则中心装置3判定为存在应该向该版本通知信号的发送源的改写对象ECU19分发的写入数据，需要更新存储于改写对象ECU19的应用程序。

中心装置3若判定为需要更新存储于改写对象ECU19的应用程序，则向便携终端6通知需要更新的内容。便携终端6若通知需要更新的内容，则显示可否分发画面(A1)。可否分发画面与后述的活动通知画面同等。用户能够通过显示于便携终端6的可否分发画面而确认需要更新的内容，能够选择是否更新。

若用户在便携终端6中选择更新的内容(A2)，则便携终端6向中心装置3通知分发包的下载请求。中心装置3若被从便携终端6通知分发包的下载请求，则向主装置11发送分发包。

主装置11若从中心装置3下载分发包，则针对该下载的分发包，开始进行包认证处理(B1)。主装置11认证分发包，若完成包认证处理，则开始进行写入数据提取处理(B2)。主装置11从分发包提取写入数据，若完成写入数据提取处理，则向中心装置3发送下载完成通知信号。

中心装置3若从主装置11接收下载完成通知信号，则向便携终端6通知下载的完成。便携终端6若被从中心装置3通知下载的完成，则显示下载完成通知画面(A3)。用户能够通过显示于便携终端6的下载完成通知画面而确认下载完成的内容，能够设定车辆侧的应用程序的改写开始时刻。

若用户在便携终端6中设定车辆侧的应用程序的改写开始时刻(A4)，则便携终端6向中心装置3通知改写开始时刻。中心装置3若被从便携终端6通知改写开始时刻，则将该用户设定的改写开始时刻存储为设定开始时刻。若当前时刻到达设定开始时刻(A5)，则中心装置3向主装置11发送改写指示信号。

主装置11若从中心装置3接收改写指示信号，则向电源管理ECU20发送电源启动请求，使改写对象ECU(ID1)、改写对象ECU(ID2)、其他的ECU从停止状态或者休眠状态转移至启动状态(X1)。

主装置11开始向改写对象ECU(ID1)分发写入数据，对改写对象ECU(ID1)指示写入数据的写入。改写对象ECU(ID1)若开始从主装置11接收写入数据的，被指示写入数据的写入，则开始写入数据的写入，开始程序改写处理(C1)。改写对象ECU(ID1)若完成从主装置11接收写入数据，完成写入数据的写入，完成程序改写处理，则向主装置11发送改写完成通知信号。

主装置11若从改写对象ECU(ID1)接收改写完成通知信号，则开始向改写对象ECU(ID2)分发写入数据，对改写对象ECU(ID2)指示写入数据的写入。改写对象ECU(ID2)若开始从主装置11接收写入数据，被指示写入数据的写入，则开始写入数据的写入，开始程序改写处理(D1)。改写对象ECU(ID2)若完成从主装置11接收写入数据，完成写入数据的写入，完成程序改写处理，则向主装置11发送改写完成通知信号。主装置11若从改写对象ECU(ID2)接收改写完成通知信号，则向中心装置3发送改写完成通知信号。

中心装置3若从主装置11接收改写完成通知信号，则向便携终端6通知应用程序的改写完成。便携终端6若被从中心装置3通知应用程序的改写完成，则显示改写完成通知画面(A6)。用户能够通过显示于便携终端6的改写完成通知画面而确认完成了应用程序的改写的情况，作为激活能够设定同步的实施。

若用户在便携终端6中设定同步的实施(A7)，即用户设定针对新程序的激活的同意，则便携终端6向中心装置3通知同步的实施。中心装置3若被从便携终端6通知同步的实施，则向主装置11发送同步切换指示信号。主装置11若从中心装置3接收同步切换指示信号，则向改写对象ECU(ID1)和改写对象ECU(ID2)分发该接收到的同步切换指示信号。

改写对象ECU(ID1)和改写对象ECU(ID2)若分别从主装置11接收同步切换指示信号，则开始进行将下次启动的应用程序从旧应用程序切换为新应用程序的程序切换处理(C2、D2)。改写对象ECU(ID1)和改写对象ECU(ID2)若分别完成程序切换处理，则向主装置11发送切换完成通知信号。

主装置11若从改写对象ECU(ID1)和改写对象ECU(ID2)接收切换完成通知信号，则向改写对象ECU(ID1)和改写对象ECU(ID2)分发版本读出信号。改写对象ECU(ID1)和改写对象ECU(ID2)若分别从主装置11接收版本读出信号，则读出以后运用的应用程序的版本(C3、D3)，向主装置11发送包含该读出的版本的最新版本通知信号。主装置11通过从改写对象ECU(ID1)和改写对象ECU(ID2)接收版本通知信号，而检查软件的版本、或者根据需要进行回滚。

主装置11若从改写对象ECU(ID1)和改写对象ECU(ID2)接收版本通知信号，则向电源管理ECU20发送电源停止请求，使改写对象ECU(ID1)、改写对象ECU(ID2)、其他的ECU从启动状态转移至停止状态或者休眠状态(X2)。

主装置11向中心装置3发送最新版本通知信号。中心装置3若从主装置11接收最新版本通知信号，则根据该接收到的最新版本通知信号来确定改写对象ECU(ID1)和改写对象ECU(ID2)的应用程序的最新的版本，向便携终端6通知该确定的最新的版本。便携终端6若被从中心装置3通知最新的版本，则在便携终端6中显示表示该通知的最新的版本的最新版本通知画面(A8)。用户能够通过显示于便携终端6的最新版本通知画面而确认最新的版本，能够确认激活完成的内容。

接下来，参照图62至图65对改写应用程序的情况下的DCM12、CGW13、改写对象ECU19的动作的时序图进行说明。另外，这里，对如下情况进行说明，即在通过用户操作将IG开关42接通的期间中，即在车辆能够行驶的过程中改写2面存储器ECU的应用程序，在通过用户操作将IG开关42断开以后的驻车中改写1面挂起存储器ECU和1面独立存储器ECU的应用程序。另外，对通过电源控制来改写应用程序的情况以及通过电源自保持来改写应用程序的情况进行说明。

(ア)在通过电源控制来改写应用程序的情况下

参照图62和图63对通过电源控制来改写应用程序的情况进行说明。基于电源控制的应用程序的改写是指不使用电源自保持电路，根据电源的切换来控制改写动作的结构。若通过用户使IG开关从断开切换到接通而将车辆电源从+B电源切换到IG电源，则DCM12、CGW13、2面存储器ECU、1面挂起存储器ECU、1面独立存储器ECU分别开始通常动作(t1)。

DCM12若被从中心装置3通知下载开始，则从通常动作转移至下载动作，开始从中心装置3下载分发包(t2)。DCM12可以进行通常动作，并且在后台进行分发包的下载。DCM12若完成从中心装置3下载分发包，则从下载动作复原到通常动作(t3)。

DCM12若被从中心装置3或者CGW13通知改写指示信号(安装指示信号)，则从通常动作转移至数据传输/中心通信动作，开始数据传输/中心通信动作(t4)。即，DCM12从分发包提取写入数据，开始向CGW13传输写入数据，并且从CGW13获取改写的进展状况，开始向中心装置3通知改写的进展状况。

CGW13若开始从DCM12获取写入数据，则从通常动作转移至重编主动作，开始重编主动作，开始向2面存储器ECU分发写入数据，指示写入数据的写入。2面存储器ECU若开始从CGW13接收写入数据，则在通常动作中开始编程阶段(以下，也称为安装阶段)。即，2面存储器ECU进行通常动作，在后台进行应用程序的安装。2面存储器ECU开始向闪存写入接收到的写入数据，开始应用程序的改写。

在2面存储器ECU中，在应用程序的改写中，若通过用户使IG开关从接通切换到断开而将车辆电源从IG电源切换到+B电源，则DCM12中断数据传输/中心通信动作，CGW13中断重编主动作，2面存储器ECU中断安装阶段，中断应用程序的改写(t5)。

然后，若通过用户使IG开关从断开切换到接通而将车辆电源从+B电源切换到IG电源，则DCM12重新开始数据传输/中心通信动作，CGW13重新开始重编主动作，2面存储器ECU重新开始安装阶段，重新开始应用程序的改写(t6)。即，通过用户使IG开关从接通切换到断开而将车辆电源从IG电源切换到+B电源，然后，通过用户使IG开关从断开切换到接通而将车辆电源从+B电源切换到IG电源，每次产生跳闸(trip)时，2面存储器ECU重复应用程序的改写的中断和重新开始(t7、t8)。

2面存储器ECU若完成写入数据的写入，完成应用程序的改写，则结束安装阶段，从通常动作转移至等待激活。即，2面存储器ECU在未进行激活阶段的时刻，不会在改写了应用程序的新面(B面)启动，保持旧面(A面)启动(t9)。

若在通过用户使IG开关从接通切换到断开而将车辆电源从IG电源切换到+B电源之后(t10)，在该时刻，2面存储器ECU完成应用程序的改写，则CGW13向电源管理ECU20发送电源启动请求。若通过CGW13将电源启动请求发送到电源管理ECU20而将车辆电源从+B电源切换到IG电源，则DCM12重新开始数据传输/中心通信动作，CGW13重新开始重编主动作，开始向1面挂起存储器ECU和1面独立存储器ECU分发写入数据。1面挂起存储器ECU和1面独立存储器ECU若分别开始从CGW13接收写入数据，则从通常动作转移至启动处理，在启动处理中开始安装阶段(t11)。即，1面挂起存储器ECU和1面独立存储器ECU不与通常动作并行地进行安装，而在应用程序未进行动作的启动(boot)处理中进行安装。

1面挂起存储器ECU若开始应用程序的改写，则在完成应用程序的改写之前通过用户操作将IG开关42从断开切换到接通的情况下，中断应用程序的改写。1面挂起存储器ECU不是将中断了应用程序的改写的非运用面(B面)复原为启动面，而是将运用面(A面)复原为启动面。1面独立存储器ECU若开始应用程序的改写，则即使在完成应用程序的改写之前通过用户操作将IG开关42从断开切换为接通，也持续应用程序的改写。这是因为，1面独立存储器ECU若在应用程序的改写中途中断，则不能复原为通常动作。优选在开始了1面独立存储器ECU的应用程序的改写之后，使用户对IG开关42的操作无效直到完成应用程序的改写为止。

1面挂起存储器ECU若完成写入数据的写入，完成应用程序的改写，则在启动处理中结束安装阶段，从启动处理转移至等待激活。即，1面挂起存储器ECU在未进行激活阶段的时刻，不会在改写了应用程序的新面(B面)启动，保持旧面(A面)启动。1面独立存储器ECU若完成写入数据的写入，完成应用程序的改写，则在启动处理中结束安装阶段，成为等待激活(t12)。

若电源管理ECU20根据来自CGW13的激活指示而将车辆电源从IG电源切换到+B电源，则2面存储器ECU和1面挂起存储器ECU分别进行从旧面向新面的切换，在新面启动，在新面启动中开始后序阶段(以下，也称为激活阶段)。1面独立存储器ECU开始重新启动，在安装完成后的重新启动中开始激活阶段(t13、t14)。在激活(activate)中，确认利用新程序正确地启动、向CGW13通知版本信息等。

若激活完成，电源管理ECU20根据来自CGW13的激活完成指示而将车辆电源从IG电源切换到+B电源，则DCM12从数据传输/中心通信动作转移至休眠/停止动作，开始休眠/停止动作。CGW13从重编主动作转移至休眠/停止动作，开始休眠/停止动作。2面存储器ECU、1面挂起存储器ECU、1面独立存储器ECU分别从新面启动转移至休眠/停止动作(t15)。

此后，若通过用户使IG开关从断开切换到接通而将车辆电源从+B电源切换到IG电源，则2面存储器ECU和1面挂起存储器ECU分别以新面(B面)为启动面而启动新应用程序，1面独立存储器ECU启动新应用程序(t16)。

(イ)在通过电源自保持来改写应用程序的情况下

参照图64和图65对通过电源自保持来改写应用程序的情况进行说明。基于电源自保持的应用程序的改写是指使用电源自保持电路来控制改写动作的结构。若通过用户使IG开关从断开切换到接通而将车辆电源从+B电源切换到IG电源，则DCM12、CGW13、2面存储器ECU、1面挂起存储器ECU、1面独立存储器ECU分别开始通常动作(t21)。

DCM12若被从中心装置3通知下载开始，即被通知为存在基于新程序的更新，则从通常动作转移至下载动作，开始从中心装置3下载分发包(t22)。DCM12若完成从中心装置3下载分发包，则从下载动作复原为通常动作(t23)。

DCM12若被从中心装置3或者CGW13通知改写指示信号(安装指示信号)，则从通常动作转移至数据传输/中心通信动作，开始数据传输/中心通信动作(t24)。即，DCM12从分发包提取写入数据，开始向CGW13传输写入数据，并且从CGW13获取改写的进展状况，开始向中心装置3通知改写的进展状况。

CGW13若开始从DCM12获取写入数据，则从通常动作转移至重编主动作，开始重编主动作，开始向2面存储器ECU分发写入数据，指示写入数据的写入。2面存储器ECU若开始从CGW13接收写入数据，则在通常动作中开始编程阶段(以下，也称为安装阶段)。即，2面存储器ECU进行通常动作，并且在后台进行应用程序的安装。2面存储器ECU开始向闪存写入接收到的写入数据，开始应用程序的改写。

在2面存储器ECU中，在应用程序的改写中，若通过用户使IG开关从接通切换到断开而将车辆电源从IG电源切换到+B电源(t25)，则在将车辆电源从IG电源切换到+B电源之后，DCM12持续数据传输/中心通信动作，CGW13持续重编主动作，2面存储器ECU持续安装阶段，持续应用程序的改写。若在车辆电源从IG电源切换到+B电源之后经过了预先设定的时间即自保持期间，则DCM12中断数据传输/中心通信动作，CGW13中断重编主动作，2面存储器ECU中断安装阶段，中断应用程序的改写(t26)。即，在将IG开关42断开之后直到经过了规定时间为止，通过来自车辆电池40的电力供给而持续安装。

然后，若通过用户使IG开关从断开切换到接通而将车辆电源从+B电源切换到IG电源，则DCM12重新开始数据传输/中心通信动作，CGW13重新开始重编主动作，2面存储器ECU重新开始安装阶段，重新开始应用程序的改写(t27)。即，通过用户使IG开关从接通切换到断开而将车辆电源从IG电源切换到+B电源，然后通过用户使IG开关从断开切换到接通而将车辆电源从+B电源切换到IG电源，每次产生跳闸时，2面存储器ECU重复应用程序的改写的中断和重新开始(t28～t30)。但是，在车辆电源从IG电源切换到+B电源之后直到经过了自保持期间为止，DCM12持续数据传输/中心通信动作，CGW13持续重编主动作，2面存储器ECU持续安装阶段，持续应用程序的改写。

2面存储器ECU若完成写入数据的写入，完成应用程序的改写，则结束安装阶段，从通常动作转移至等待激活。即，2面存储器ECU在未进行激活阶段的时刻，不会在改写了应用程序的新面(B面)启动，保持旧面(A面)启动(t31)。

若通过用户使IG开关从接通切换到断开而将车辆电源从IG电源切换到+B电源，在该时刻在2面存储器ECU中完成应用程序的改写，则1面挂起存储器ECU和1面独立存储器ECU分别从通常动作转移至启动处理，开始启动处理，在启动处理中开始安装阶段(t32)。

1面挂起存储器ECU和独立存储器ECU若分别完成写入数据的写入，完成应用程序的改写，则在启动处理中结束安装阶段(t33)。若通过CGW13向电源管理ECU20发送电源启动请求而将车辆电源从+B电源切换到IG电源，则DCM12重新开始数据传输/中心通信动作(t34)。

1面挂起存储器ECU若完成写入数据的写入，完成应用程序的改写，则从启动处理转移至等待激活。即，1面挂起存储器ECU在未进行激活阶段的时刻，不会在改写了应用程序的新面(B面)启动，保持旧面(A面)启动。1面独立存储器ECU若完成写入数据的写入，完成应用程序的改写，则在启动处理中结束安装阶段，成为等待激活(t35)。

若电源管理ECU20根据来自CGW13的激活指示而将车辆电源从IG电源切换到+B电源，则2面存储器ECU和1面挂起存储器ECU分别进行从旧面向新面的切换，在新面启动，在新面启动中开始激活阶段。1面独立存储器ECU开始重新启动，在安装完成后的重新启动中开始激活阶段(t36、t37)。

若激活完成，电源管理ECU20根据来自CGW13的激活完成指示而将车辆电源从IG电源切换到+B电源，则DCM12从数据传输/中心通信动作转移至休眠/停止动作，开始休眠/停止动作。CGW13从重编主动作转移至休眠/停止动作，开始休眠/停止动作。2面存储器ECU、1面挂起存储器ECU和1面独立存储器ECU分别从新面启动转移至休眠/停止动作(t38)。

此后，若通过用户使IG开关从断开切换到接通而将车辆电源从+B电源切换到IG电源，则2面存储器ECU和1面挂起存储器ECU分别以新面(B面)为启动面而启动新应用程序，1面独立存储器ECU启动新应用程序(t39)。

CGW13在从中心装置3下载分发包之前，在向写入数据的改写对象ECU19分发前，进行以下的检查。CGW13在从中心装置3下载分发包之前，进行电波环境、车辆电池40的电池余量、DCM12的存储器容量的检查，以使得能够正常地进行下载。CGW13在向写入数据的改写对象ECU19分发前，为了能够正常地进行写入数据的分发，作为用于不使安装环境不稳定的有人环境的检查，进行侵入传感器的检测、门锁的检测、窗帘的检测、IG断开的检测，作为改写对象ECU19是否能够写入的检查，进行版本、异常产生的检查。另外，作为向改写对象ECU19分发的写入数据的检查，CGW13在开始安装前，进行篡改检查、访问认证、版本检查等，在执行安装中，进行通信隔断检查、异常产生的检查等，在完成安装后，进行版本检查、完整性检查、DTC(Diagnostic Trouble Code：诊断故障码、错误代码)检查等。

接下来，参照图66至图82对显示终端5显示的画面进行说明。如图66所示，在通过OTA对改写对象ECU19的应用程序进行改写的结构中，存在活动通知、下载、安装、激活的阶段。活动通知是指程序更新的通知。例如接受在中心装置3中判断为存在应用程序的更新的情况，由主装置11下载分发规格数据等是活动通知。显示终端5随着应用程序的改写推进而在各阶段显示画面。另外，这里，对车载显示器7显示的画面进行说明。

如图67所示，CGW13在活动通知前的通常时，例如使车载显示器7显示导航功能之一即公知的路径启动画面等导航画面501。若从该状态产生活动通知，则如图32所示，CGW13在导航画面501的右下显示表示活动通知的产生的活动通知图标501a。用户能够通过确认活动通知图标501a的显示，而掌握与应用程序的更新有关的活动通知的产生。

若用户从该状态对活动通知图标501a进行操作，则如图69所示，CGW13在导航画面501上弹出显示活动通知画面502。另外，CGW13并不局限于弹出显示活动通知画面502，也可以采用其他的显示形式。CGW13在活动通知画面502中，例如显示“存在能够利用的软件更新”的提示而向用户通知活动通知的产生，并且显示“确认”按钮502a、“以后”按钮502b，等待用户的操作。在该情况下，用户通过对“确认”按钮502a进行操作，能够进入用于开始应用程序的改写的下一画面。另外，CGW13在用户操作了“以后”按钮502b的情况下，消除活动通知画面502的弹出显示，返回到图32所示的显示活动通知图标501a的画面。

若用户从该状态操作“确认”按钮502a，则如图70所示，CGW13使显示从导航画面501切换到下载同意画面503，使车载显示器7显示下载同意画面503。CGW13在下载同意画面503中，向用户通知活动ID、更新名称，并且显示“下载开始”按钮503a、“详情确认”按钮503b、“返回”按钮503c，等待用户的操作。在该情况下，用户能够通过操作“下载开始”按钮503a，而开始下载，能够通过操作“详情确认”按钮503b，而显示下载的详情，能够通过显示“返回”按钮503c，而拒绝下载，返回之前的画面。在操作了“返回”按钮503c的情况下，用户能够通过操作活动通知图标501a，而进入用于开始下载的画面。

若用户从显示该下载同意画面503的状态操作“详情确认”按钮503b，则如图71所示，CGW13切换下载同意画面503的显示内容，使车载显示器7显示下载的详情。作为下载的详情，CGW13使用接收到的分发规格数据，显示更新内容、更新所花费的时间、伴随着更新的车辆功能的制约等。另外，若用户操作“下载开始”按钮503a，则CGW13经由DCM12而开始分发包的下载。与开始发包的下载并行地，如图72所示，CGW13将显示从下载同意画面503切换到导航画面501，使车载显示器7再次显示导航画面501，在导航画面501的右下显示表示下载执行中的下载执行中图标501b。用户能够通过确认下载执行中图标501b的显示，而掌握分发包的下载执行中。

若用户从该状态操作下载执行中图标501b，则如图73所示，CGW13将显示从导航画面501切换到下载执行中画面504，使车载显示器7显示下载执行中画面504。CGW13在下载执行中画面504中，向用户通知下载的执行中，并且显示“详情确认”按钮504a、“返回”按钮504b和“取消”按钮504c，等待用户的操作。在该情况下，用户能够通过操作“详情确认”按钮504a，而显示下载执行中的详情，能够通过操作“取消”按钮504c，而中断下载。

若完成下载，则如图74所示，CGW13在导航画面501上弹出显示下载完成通知画面505。CGW13在下载完成通知画面505中，例如显示“下载完成，能够进行软件更新”的提示而向用户通知下载的完成，并且显示“确认”按钮505a、“以后”按钮505b，等待用户的操作。在该情况下，用户能够通过操作“确认”按钮505a，而进入用于开始安装的画面。

若用户从该状态操作“确认”按钮505a，则如图75所示，CGW13将显示从导航画面501切换到安装同意画面506，使车载显示器7显示安装同意画面506。CGW13在安装同意画面506中，向用户通知与安装有关的所需时间、制约事项和时间表的设定，并且显示“立即更新”按钮506a、“预约更新”按钮506b、“返回”按钮506c，等待用户的操作。在该情况下，用户能够通过操作“立即更新”按钮506a，而立刻开始安装。另外，用户能够通过设定希望执行安装的时刻，操作“预约更新”按钮506b，而开始预约安装。另外，用户能够通过操作“返回”按钮506c，而拒绝安装，返回之前的画面。在操作了“返回”按钮506c的情况下，用户能够通过操作下载执行中图标501b，而进入用于开始安装的画面。

若用户从该状态操作“立即更新”按钮506a，则如图76所示，CGW13切换安装同意画面506的显示内容，使车载显示器7显示安装的详情。CGW13在这里的安装同意画面506中，受理安装的请求，向用户通知开始安装的内容。

CGW13若开始安装，则如图77所示，将显示从安装同意画面506切换到导航画面501，使车载显示器7再次显示导航画面501，在导航画面501的右下显示表示安装执行中的安装执行中图标501c。用户能够通过确认安装执行中图标501c的显示，而掌握安装执行中。

若用户从该状态操作安装执行中图标501c，则如图78所示，CGW13将显示从导航画面501切换到安装执行中画面507，使车载显示器7显示安装执行中画面507。CGW13在安装执行中画面507中，向用户通知处于安装的执行中。CGW13例如也可以使安装执行中画面507显示安装所需剩余时间、进展百分比。

CGW13若完成安装，则如图79所示，将显示从导航画面501切换到激活同意画面508，使车载显示器7显示激活同意画面508。CGW13在激活同意画面508中，向用户通知激活的内容，并且显示“返回”按钮508a和“OK”按钮508b，等待用户的操作。在该情况下，用户能够通过操作“返回”按钮508a，而拒绝激活，返回之前的画面。另外，用户能够通过操作“OK”按钮508b，而同意激活。另外，在操作了“返回”按钮508a的情况下，用户能够通过操作安装执行中图标501c，而进入用于执行激活的画面。另外，关于这些显示、同意，也可以不根据用户的设定、程序的场景进行显示，而省略。

若用户从用户操作了“OK”按钮508b之后的状态接通IG电源，则如图80所示，CGW13在导航画面501上弹出显示激活完成通知画面509。CGW13在激活完成通知画面509中，例如显示“软件更新完成”的提示而向用户通知激活的完成，并且显示“OK”按钮509a、“详情确认”按钮509b，等待用户的操作。在该情况下，用户能够通过操作“OK”按钮509a，而消除激活完成通知画面509的弹出显示，能够通过操作“详情确认”按钮509b，而显示激活的完成的详情。

若用户从该状态操作“OK”按钮509a，则如图81所示，CGW13将显示从导航画面501切换到确认操作画面510，使车载显示器7显示确认操作画面510。CGW13在确认操作画面510中向用户通知激活的完成，并且显示“详情确认”按钮510a、“OK”按钮510b，等待用户的操作。在该情况下，用户能够通过操作“详情确认”按钮510a，而显示激活的完成的详情。

若用户从该状态操作“详情确认”按钮510a，则如图82所示，CGW13切换确认操作画面510的显示内容，使车载显示器7显示激活的完成的详情。CGW13将通过更新而追加的功能、变更后的功能等作为更新详情进行显示，并且显示“OK”按钮510b。CGW13基于由用户操作了“OK”按钮509a、510b，而判断为用户确认了软件更新完成。

像以上说明的那样，车辆侧系统4控制活动通知、下载、安装、激活、更新完成这样的各动作阶段，并且向用户提示符合各动作阶段的显示。另外，在上述的说明中，采用CGW13进行显示的控制的结构，但也可以构成为车载显示器7从CGW13接收动作阶段、分发规格数据，并进行显示。

接下来，参照图83至图269对由车辆用程序改写系统1进行的特征性处理进行说明。车辆用程序改写系统1进行以下所示的特征性的处理。

(1)分发包的发送判定处理

(2)分发包的下载判定处理

(3)写入数据的传输判定处理

(4)写入数据的获取判定处理

(5)安装的指示判定处理

(6)安全访问密钥的管理处理

(7)写入数据的验证处理

(8)数据储存面信息的发送控制处理

(9)非改写对象的电源管理处理

(10)文件的传输控制处理

(11)写入数据的分发控制处理

(12)激活请求的指示处理

(13)激活的执行控制处理

(14)改写对象的组管理处理

(15)回滚的执行控制处理

(16)改写进展状况的显示控制处理

(17)差分数据的整合性判定处理

(18)改写的执行控制处理

(19)会话的确立处理

(20)重试点的确定处理

(21)进展状态的同步控制处理

(22)显示控制信息的发送控制处理

(23)显示控制信息的接收控制处理

(24)进展显示的画面显示控制处理

(25)程序更新的报告控制处理

(26)电源自保持的执行控制处理

中心装置3、DCM12、CGW13、ECU19、车载显示器7作为分别进行上述的(1)～(26)的特征性的处理的结构，具有以下的功能模块。

如图83所示，中心装置3具有分发包发送部51。分发包发送部51若从DCM12接收分发包的下载请求，则向DCM12发送分发包。中心装置3除了上述的结构之外，作为进行特征性的处理的结构，具有分发包的发送判定部52、进展状态的同步控制部53、显示控制信息的发送控制部54、以及写入数据选择部55(相当于更新数据选择部)。写入数据选择部55(相当于更新数据选择部)若从主装置11接收数据储存面信息，则基于通过该接收到的数据储存面信息确定的软件版本和运用面，而选择适合非运用面的写入数据。即，分发包发送部51向DCM12发送包含由写入数据选择部55选择的写入数据的分发包。关于进行特征性的处理的功能模块，后述说明。

如图84所示，DCM12具有下载请求发送部61、分发包下载部62、写入数据提取部63、写入数据传输部64、改写规格数据提取部65、以及改写规格数据传输部66。下载请求发送部61向中心装置3发送分发包的下载请求。分发包下载部62从中心装置3下载分发包。写入数据提取部63若通过分发包下载部62从中心装置3下载分发包，则从该下载的分发包中提取写入数据。

写入数据传输部64若通过写入数据提取部63从分发包提取写入数据，则向CGW13传输该提取出的写入数据。改写规格数据提取部65若通过分发包下载部62从中心装置3下载分发包，则从该下载的分发包中提取改写规格数据。改写规格数据传输部66若通过改写规格数据提取部56从分发包提取改写规格数据，则向CGW13传输该提取出的改写规格数据。DCM12除了上述的结构之外，作为进行特征性的处理的结构，具有分发包的下载判定部67和写入数据的传输判定部68。关于进行特征性的处理的功能模块，后述说明。

如图85和图86所示，CGW13具有获取请求发送部71、写入数据获取部72(相当于更新数据存储部)、写入数据分发部73(相当于更新数据分发部)、改写规格数据获取部74、以及改写规格数据解析部75。写入数据获取部72通过被从DCM12传输写入数据，而从DCM12获取写入数据。写入数据分发部73若通过写入数据获取部72获取写入数据，则在成为该写入数据的分发时机时，向改写对象ECU19分发该获取的写入数据。改写规格数据获取部74通过被从DCM12传输改写规格数据，而从DCM12获取改写规格数据。改写规格数据解析部75若通过改写规格数据获取部74获取改写规格数据，则对该获取的改写规格数据进行解析。

CGW13除了上述的结构之外，作为进行特征性的处理的结构，具有写入数据的获取判定部76、安装的指示判定部77、安全访问密钥的管理部78、写入数据的验证部79、数据储存面信息的发送控制部80、非改写对象的电源管理部81、文件的传输控制部82、写入数据的分发控制部83、激活请求的指示部84、改写对象的组管理部85、回滚的执行控制部86、改写进展状况的显示控制部87、进展状态的同步控制部88、显示控制信息的接收控制部89、进展显示的画面显示控制部90、程序更新的报告控制部91、以及电源自保持的执行控制部92。关于进行特征性的处理的功能模块，后述说明。

如图87所示，ECU19具有写入数据接收部101和程序改写部102。写入数据接收部101从CGW13接收写入数据。程序改写部102若通过写入数据接收部101从CGW13接收写入数据，则将该接收到的写入数据写入闪存而改写应用程序。ECU19除了上述的结构之外，作为进行特征性的处理的结构，具有差分数据的整合性判定部103、改写的执行控制部104、会话的确立部105、重试点的确定部106、激活的执行控制部107、以及电源自保持的执行控制部108。关于进行特征性的处理的功能模块，后述说明。

如图88所示，车载显示器7具有分发规格数据的接收控制部111。分发规格数据的接收控制部111控制分发规格数据的接收。

以下，关于上述的(1)～(26)的各处理，依次进行说明。

(1)分发包的发送判定处理、(2)分发包的下载判定处理

参照图89和图90对中心装置3的分发包的发送判定处理进行说明，参照图91和图92对主装置11的分发包的下载判定处理进行说明。

如图89所示，中心装置3在分发包的发送判定部52中，具有软件信息获取部52a、更新有无判定部52b、更新适当与否判定部52c、以及活动信息发送部52d。软件信息获取部52a从车辆侧获取各ECU19的软件信息。具体而言，软件信息获取部52a从车辆侧获取包含版本、写入面等软件信息和硬件信息的ECU结构信息。软件信息获取部52a也可以从车辆侧，与这些ECU结构信息一并地获取故障代码、防盗警报功能的设定、许可协议信息等车辆状态信息。

更新有无判定部52b若通过软件信息获取部52a获取软件信息，则基于该获取的软件信息，而判定针对车辆的更新数据的有无。即，更新有无判定部52b对该获取的软件信息的版本与自身管理的最新的软件信息的版本进行比较，判定两者是否一致，判定针对车辆的更新数据的有无。更新有无判定部52b若判定为两者一致，则判定为不存在针对车辆的更新数据，若判定为两者不一致，则判定为存在针对车辆的更新数据。

更新适当与否判定部52c若通过更新有无判定部52b判定出存在针对车辆的更新数据，则判定车辆状态是否是适合于使用分发包的程序等的更新的状态。具体而言，更新适当与否判定部52c判定许可协议是否成立、车辆位置是否处于由用户预先登记的规定范围内、车辆的警报功能的设定是否有效化、是否产生ECU19的故障信息，判定车辆状态是否是适合于分发包的下载的状态。即，更新适当与否判定部52c判定是否是有可能成为违反用户的意图的更新的车辆、或者即使下载成功也有可能在下载后的安装中失败的车辆。

更新适当与否判定部52c若判定为许可协议成立、车辆位置处于由用户预先登记的规定范围内、车辆的警报功能的设定被有效化、处于未产生ECU19的故障信息的状态，则判定为车辆状态是适合于使用分发包的程序等的更新的状态。更新适当与否判定部52c若判定为许可协议不成立、车辆位置不处于由用户预先登记的规定范围内、车辆的警报功能的设定未被有效化、产生ECU19的故障信息中的至少任意一个，则判定为车辆状态不是适合于使用分发包的程序等的更新的状态。

活动信息发送部52d若通过更新适当与否判定部52c判定为车辆状态是适合于使用分发包的程序等的更新的状态，则向主装置11发送活动信息。活动信息发送部52d若通过更新适当与否判定部52c判定为车辆状态不是适合于使用分发包的程序等的更新的状态，则不向主装置11发送活动信息。活动信息发送部52d通过进行上述的判定，而预先存储与未将活动信息发送到主装置11的车辆相关的信息。另外，在中心装置3中，也可以显示与未将活动信息发送到主装置11的车辆相关的信息。

接下来，参照图90对中心装置3的分发包的发送判定部52的作用进行说明。中心装置3执行分发包的发送判定程序，进行分发包的发送判定处理。

中心装置3若开始分发包的发送判定处理，则从车辆侧获取软件信息(S101、相当于软件信息获取步骤)。即，中心装置3判定是否存在针对车辆的软件更新。中心装置3基于该获取的软件信息而判定针对车辆的更新数据的有无(S102、相当于更新有无判定步骤)。中心装置3若判定为存在针对车辆的更新数据(S102：“是”)，判定车辆状态是否是适合于使用分发包的程序等的更新的状态(S103、相当于更新适当与否判定步骤)。中心装置3若判定为车辆状态是适合于使用分发包的程序等的更新的状态(S103：“是”)，向主装置11发送活动信息(S104、相当于活动信息发送步骤)，结束分发包的发送判定处理。

中心装置3若判定为不存在针对车辆的更新数据(S102：“否”)，则向主装置11发送不是分发包的发送对象的内容、即不存在应用程序的更新的内容(S105)，结束分发包的发送判定处理。中心装置3若判定为车辆状态不是适合于使用分发包的程序等的更新的状态(S103：“否”)，则向主装置11发送不适合于程序等的更新的内容及其理由(S106)，结束分发包的发送判定处理。在该情况下，主装置11使车载显示器7显示适合于程序等的更新的内容及其理由。例如如果许可协议不成立，则主装置11使车载显示器7显示例如“由于许可无效，因此不能进行程序更新。请向经销商询问。”等。由此，能够向用户提示不适合于程序等的更新的内容的理由，能够向用户提示适当的信息。

像以上说明的那样，中心装置3在向主装置11发送分发包前且在活动信息的发送前，进行分发包的发送判定处理，由此能够判定是否是适合于使用分发包的程序等的更新的状态。而且，中心装置3仅在判定为适合于使用分发包的程序等的更新的状态的情况下，向主装置11发送分发包，而向主装置11发送活动信息。

在作为适合于使用分发包的程序等的更新的情况，许可协议成立、车辆位置处于由用户预先登记的规定范围内、车辆的警报功能的设定被有效化、未产生ECU19的故障信息的情况下，中心装置3能够向主装置11发送活动信息。即，在许可协议未成立、或者车辆位置处于远离自宅的位置等规定范围外、或者车辆的警报功能的设定被无效化、或者产生ECU19的故障信息的情况下，中心装置3能够避免向主装置11发送活动信息的情况。这样，中心装置3对于有可能成为违反用户的意图的更新的车辆、即使下载成功在安装中也有可能失败的车辆，能够不向主装置11发送活动信息。

另外，中心装置3也可以在分发包的发送中进行分发包的发送判定处理。在该情况下，中心装置3若在分发包的发送中判定为车辆状态是适合于使用分发包的程序等的更新的状态，则持续分发包的发送，但若在分发包的发送中判定为车辆状态不是适合于使用分发包的程序等的更新的状态，则中断分发包的发送。即，中心装置3若在分发包的发送中产生例如ECU19的故障信息，则中断分发包的发送。

接下来，对接收到从中心装置3发送来的活动信息的主装置11的处理进行说明。参照图91和图92对主装置11中的分发包的下载判定处理进行说明。车辆用程序改写系统1在主装置11中进行分发包的下载判定处理。上述的(1)分发包的发送判定处理是中心装置3在下载阶段之前的活动通知阶段进行的判定处理，但分发包的下载判定处理是由主装置11在下载阶段进行的判定处理。另外，在本实施方式中，说明了在主装置11中DCM12进行分发包的下载判定处理的情况，但也可以是，通过CGW13具有DCM12的功能，而由CGW13进行分发包的下载判定处理。

如图91所示，DCM12在分发包的下载判定部67中，具有活动信息接收部67a、可下载判定部67b、以及下载执行部67c。活动信息接收部67a从中心装置3接收活动信息。另外，若从中心装置3接收活动信息，则显示图68所示的活动通知图标501a。可下载判定部67b若通过活动信息接收部67a接收活动信息，则判定车辆状态是否是能够下载分发包的状态。即，可下载判定部67b判定用于与中心装置3进行通信的电波环境是否良好、车辆电池40的电池余量是否为规定容量以上、DCM12的存储器空闲容量是否为规定容量以上，判定车辆状态是否是能够下载分发包的状态。

可下载判定部67b若判定为电波环境良好、车辆电池40的电池余量为规定容量以上、DCM12的存储器空闲容量为规定容量以上，则判定为车辆状态是能够下载分发包的状态。可下载判定部67b若判定出电波环境不良好、车辆电池40的电池余量不为规定容量以上、DCM12的存储器空闲容量不为规定容量以上中的至少任意一个，则判定为车辆状态不是能够下载分发包的状态。

这样，可下载判定部67b判定是否有可能无法正常地完成下载。另外，在图70和图71所示的下载同意画面503中，以由用户操作了“下载开始”按钮503a为条件，进行基于可下载判定部67b的判定。另外，可下载判定部67b也可以构成为对于中心装置3的判定项目也进行判定。即，例如在车辆的警报功能的设定被有效化的情况下、或在未产生ECU19的故障信息的情况下，可下载判定部67b判定为处于能够下载的状态。

若由可下载判定部67b判定为车辆状态是能够下载分发包的状态，则下载执行部67c从中心装置3下载分发包。即，下载执行部67c在确认了能够正常地完成下载的基础上，执行分发包的下载。

若由可下载判定部67b判定为车辆状态不是能够下载分发包的状态，则下载执行部67c不从中心装置3下载分发包。即，在有可能无法正常地完成下载的情况下，下载执行部67c不执行分发包的下载。在该情况下，下载执行部67c向车载显示器7指示在导航画面501上显示表示无法开始下载的内容及其理由的弹出画面。

接下来，参照图92对主装置11中的分发包的下载判定部67的作用进行说明。主装置11执行分发包的下载判定程序，进行分发包的下载判定处理。

主装置11若开始分发包的下载判定处理，则从中心装置3接收活动信息(S201、相当于活动信息接收步骤)。主装置11判定车辆状态是否是能够下载分发包的状态(S202、相当于能够下载判定步骤)。主装置11若判定为车辆状态是能够下载分发包的状态(S202：“是”)，则从中心装置3下载与该活动对应的分发包(S203、相当于下载执行步骤)，结束分发包的下载判定处理。主装置11若判定为车辆状态不是能够下载分发包的状态(S202：“否”)，则不从中心装置3下载分发包，结束分发包的下载判定处理。

像以上说明的那样，主装置11在从中心装置3下载分发包之前，进行分发包的下载判定处理，由此判定车辆状态是否是能够下载分发包的状态。而且，主装置11能够仅在车辆状态是能够下载分发包的状态的情况下下载分发包。

在作为适合于分发包的下载的情况，电波环境良好、车辆电池40的电池余量为规定容量以上、DCM12的存储器空闲容量为规定容量以上的情况下，主装置11能够从中心装置3下载分发包。即，在电波环境良好、或者车辆电池40的电池余量小于规定容量、或者DCM12的存储器空闲容量小于规定容量的情况下，能够避免从中心装置3下载分发包的情况。

另外，主装置11也可以在分发包的下载中进行分发包的下载判定处理。在该情况下，主装置11若在分发包的下载中判定为车辆状态是能够下载分发包的状态，则持续从中心装置3下载分发包，但若在分发包的下载中判定为车辆状态不是能够下载分发包的状态，则中断从中心装置3下载分发包。即，若在分发包的下载中例如电波环境不良好、或者车辆电池40的电池余量小于规定容量、或者DCM12的存储器空闲容量小于规定容量，则主装置11中断分发包的下载。

这样，在中心装置3中，判定是否是有可能成为违反用户的意图的更新的车辆、或有可能安装失败的车辆，并且在主装置11中，判定是否有可能下载失败，由此能够抑制从中心装置3向主装置11发送无用的活动信息、分发包。

中心装置3具有以下的结构。具备：软件信息获取部52a，其从车辆侧获取电子控制装置的软件信息；更新有无判定部52b，其基于由上述软件信息获取部获取的软件信息，而判定针对车辆的更新数据的有无；更新适当与否判定部52c，其在由上述更新有无判定部判定为存在更新数据的情况下，判定车辆状态是否是适合于更新的状态；活动信息发送部52d，其在由上述更新适当与否判定部判定为车辆状态是适合于更新的状态的情况下，向车辆用主装置发送与更新相关的活动信息。

主装置11具有以下的结构。具备：活动信息接收部67a，其从中心装置接收活动信息；可下载判定部67b，其在通过上述活动信息接收部接收到活动信息的情况下，判定车辆状态是否是能够下载分发包的状态；以及下载执行部67c，其在由上述可下载判定部判定为车辆状态是能够下载分发包的状态的情况下，从中心装置下载分发包。

(3)写入数据的传输判定处理、(4)写入数据的获取判定处理、(5)安装的指示判定处理

参照图93和图94对写入数据的传输判定处理进行说明，参照图95和图96对写入数据的获取判定处理进行说明，参照图97至图100对安装的指示判定处理进行说明。车辆用程序改写系统1在DCM12中进行写入数据的传输判定处理。这里，从中心装置3发送到DCM12的分发包被解包，成为从分发包提取出写入数据的状态。

如图93所示，DCM12在写入数据的传输判定部68中具有获取请求接收部68a和通信状态判定部68b。获取请求接收部68a从CGW13接收写入数据的获取请求。若通过获取请求接收部68a接收写入数据的获取请求，则例如在由用户预先设定的传输可否判定标志为第一规定值的情况下，通信状态判定部68b判定中心装置3与DCM12之间的数据通信的状态。例如在安装时检查规定条件的情况下传输可否判定标志为1(第一规定值)，在省略检查的情况下传输可否判定标志为0(第二规定值)。以由通信状态判定部68b判定为中心装置3与DCM12之间的数据通信处于连接状态为条件，写入数据传输部64向CGW13传输写入数据。

接下来，参照图94对DCM12的写入数据的传输判定部68的作用进行说明。DCM12执行写入数据的传输判定程序，进行写入数据的传输判定处理。这里，说明根据来自中心装置3的安装指示，CGW13对DCM12请求写入数据的获取的情况下的处理。

DCM12若判定从CGW13接收到写入数据的获取请求，则开始写入数据的传输判定处理。DCM12若开始写入数据的传输判定处理，则判定传输可否判定标志(S301、S302)。DCM12若判定为传输可否判定标志是第一规定值(S301：“是”)，则判定中心装置3与自身之间的数据通信的状态(S303)。DCM12若判定为中心装置3与自身之间的数据通信处于连接状态(S303：“是”)，则向CGW13传输写入数据(S304)，结束写入数据的传输判定处理。DCM12若判定为中心装置3与自身之间的数据通信不处于连接状态而处于隔断状态(S303：“否”)，则不向CGW13传输写入数据，结束写入数据的传输判定处理。

另外，DCM12若判定为传输可否判定标志是第二规定值(S302：“是”)，则不判定中心装置3与自身之间的数据通信的状态，而向CGW13传输写入数据，结束写入数据的传输判定处理。

像以上说明的那样，DCM12通过在向CGW13传输写入数据之前进行写入数据的传输判定处理，而在传输可否判定标志为第一规定值的情况下，判定中心装置3与自身之间的数据通信的状态。DCM12若判定为数据通信处于连接状态，则开始写入数据的传输，若判定为数据通信处于隔断状态，则不开始写入数据的传输而待机。在能够进行与中心装置3的数据通信的状况下，能够向CGW13传输写入数据，能够在改写对象ECU19中执行安装。

例如在改写对象ECU19为多个，安装需要时间的情况下，能够从车载侧系统4向中心装置3通知安装的进展状况，能够在便携终端6逐一显示进展状况。另外，DCM12也可以在写入数据的传输中进行写入数据的传输判定处理。在该情况下，DCM12若在写入数据的传输中判定为数据通信处于连接状态，则持续写入数据的传输，但若在写入数据的传输中判定为数据通信处于隔断状态，则中断写入数据的传输。

接下来，对写入数据的获取判定处理进行说明。车辆用程序改写系统1在CGW13中进行写入数据的获取判定处理。上述的(3)写入数据的传输判定处理是在安装阶段由DCM12进行的判定处理，写入数据的获取判定处理同样是在安装阶段由CGW13进行的判定处理。

如图95所示，CGW13在写入数据的获取判定部76中具有事件产生判定部76a和通信状态判定部76b。事件产生判定部76a判定来自中心装置3的写入数据的获取请求(安装指示)的事件产生。若由事件产生判定部76a判定出写入数据的获取请求的事件产生，则例如在由用户预先设定的获取可否判定标志是第一规定值的情况下，通信状态判定部76b判定中心装置3与DCM12之间的数据通信的状态。例如在安装时检查规定条件的情况下，获取可否判定标志是1(第一规定值)，在省略检查的情况下，获取可否判定标志是0(第二规定值)。这里，事件产生判定部76a也可以基于用户指示了安装来判定事件产生的情况，例如若接受到用户在车载显示器7中进行安装的指示操作(参照图75)的内容的通知，则判定为产生了写入数据的获取请求的事件。

接下来，参照图96对CGW13中的写入数据的获取判定部76的作用进行说明。CGW13执行写入数据的获取判定程序，进行写入数据的获取判定处理。

CGW13若判定出写入数据的获取请求的事件产生，则开始写入数据的获取判定处理。CGW13若开始写入数据的获取判定处理，则判定获取可否判定标志(S401、S402)。CGW13若判定为获取可否判定标志是第一规定值(S401：“是”)，则判定中心装置3与DCM12之间的数据通信的状态(S403：CGW13若判定为中心装置3与DCM12之间的数据通信连接(S403：“是”)，则向DCM12发送写入数据的获取请求(S404)，结束写入数据的获取判定处理。此后，CGW13若被从DCM12传输写入数据，则向改写对象ECU19分发该传输来的写入数据。CGW13若判定为中心装置3与DCM12之间的数据通信隔断而不连接(S403：“否”)，则不向DCM12发送写入数据的获取请求，结束写入数据的获取判定处理。

另外，CGW13若判定为获取可否判定标志是第二规定值(S402：“是”)，则不判定中心装置3与DCM12之间的数据通信的状态，而向DCM12发送写入数据的获取请求，结束写入数据的获取判定处理。

像以上说明的那样，CGW13通过在从DCM12获取写入数据之前进行写入数据的获取判定处理，而在获取可否判定标志是第一规定值的情况下，判定中心装置3与DCM12之间的数据通信的状态。CGW13若判定为数据通信处于连接状态，则开始写入数据的获取，若判定为数据通信处于隔断状态，则不开始写入数据的获取而待机。在能够进行与中心装置3的通信的状况下，能够从DCM12获取写入数据，能够在改写对象ECU19中执行安装。

例如在改写对象ECU19为多个，安装需要时间的情况下，能够从车载侧系统4向中心装置3通知安装的进展状况，能够在便携终端6中逐一显示进展状况。另外，CGW13也可以在写入数据的获取中进行写入数据的获取判定处理。在该情况下，CGW13若在写入数据的获取中判定为数据通信处于连接状态，则持续写入数据的获取，但若在写入数据的获取中判定为数据通信处于隔断状态，则中断写入数据的获取。

接下来，更详细地说明上述的写入数据的获取判定。写入数据的获取是与安装相关的处理之一，这里，参照图97至图100对安装的指示判定处理进行说明。车辆用程序改写系统1在CGW13中进行安装的指示判定处理。上述的(1)分发包的发送判定处理、(2)分发包的下载判定处理是在下载阶段进行的判定处理，(3)写入数据的传输判定处理、(4)写入数据的获取判定处理是在下载完成后的安装阶段进行的处理，(5)安装的指示判定处理是在安装阶段和激活阶段进行的处理。这里，分发包被下载到DCM12，如图46所示，成为写入到写入对象ECU19的写入数据(更新数据、差分数据)被解包的状态。

如图97所示，CGW13在安装的指示判定部77中，具有安装条件判定部77a、安装指示部77b、车辆状态信息获取部77c、激活条件判定部77d、以及激活指示部77e。安装条件判定部77a判定第一条件、第二条件、第三条件、第四条件、第五条件是否成立。第一条件是得到与安装相关的用户同意这样的条件。与安装相关的用户同意例如表示在图75所示的画面中，为针对安装的用户的同意操作(例如按下“立即更新”按钮506a)。或者，也可以将从下载到激活为止视为一个更新，作为针对更新的用户的同意操作。

第二条件是CGW13能够与中心装置3进行数据通信这样的条件。第三条件是车辆状态为能够安装这样的条件。第四条件是改写对象ECU19能够安装这样的条件。这里，第四条件不仅包含安装对象的改写对象ECU19能够安装，而且还包含与该安装对象的改写对象ECU19协作的改写对象ECU19也能够安装。第五条件是写入数据为正常的数据这样的条件。这里，正常的数据包含适合于改写对象ECU19的数据、未被篡改的数据等。

若由安装条件判定部77a判定为第一条件、第二条件、第三条件、第四条件和第五条件全部成立，则安装指示部77b向改写对象ECU19指示应用程序的安装。即，若由安装条件判定部77a判定为得到与安装相关的用户同意、CGW13能够与中心装置3进行数据通信、车辆状态为能够安装的状态、改写对象ECU19处于能够安装的状态、写入数据为正常的数据，则安装指示部77b向改写对象ECU19指示应用程序的安装。具体而言，安装指示部77b从DCM12获取写入数据，向改写对象ECU19传输该获取的写入数据。若由安装条件判定部77a判定为第一条件、第二条件、第三条件、第四条件和第五条件中的至少任意一方不成立，则安装指示部77b不向改写对象ECU19指示应用程序的安装，向用户提示待机或者无法开始安装的内容及其理由。

车辆状态信息获取部77c从中心装置3获取车辆状态信息。在全部的改写对象ECU19中应用程序的安装完成的情况下，激活条件判定部77d判定第六条件、第七条件、第八条件是否成立。第六条件是得到与激活相关的用户同意这样的条件。与激活相关的用户同意例如表示在图79所示的画面中，为针对激活的用户的同意操作(例如按下“OK”按钮508b)。或者，也可以将从下载到激活为止视为一个更新，作为针对更新的用户的同意操作。第七条件是车辆状态为能够激活的状态这样的条件。第八条件是改写对象ECU19处于能够激活的状态这样的条件。

若由激活条件判定部77d判定为第六条件、第七条件和第八条件全部成立，则激活指示部77e向改写对象ECU19指示应用程序的激活。具体而言，在后述的(12)激活请求的指示处理中进行说明。即，若由激活条件判定部77d判定为得到与激活相关的用户同意、车辆状态为能够激活的状态、改写对象ECU19处于能够激活的状态，则激活指示部77e向改写对象ECU19指示应用程序的激活。通过进行激活，从而写入到改写对象ECU19的更新程序被有效化。若由激活条件判定部77d判定为第六条件、第七条件和第八条件中的至少任意一方不成立，则激活指示部77e不向改写对象ECU19指示应用程序的激活，向用户提示待机或者无法开始激活的内容及其理由。

接下来，参照图98至图100对CGW13中的安装的指示判定部77的作用进行说明。CGW13执行安装的指示判定程序，进行安装的指示判定处理。

CGW13若开始安装的指示判定处理，则判定第一条件是否成立，判定是否得到与安装相关的用户同意(S501、相当于安装条件判定步骤的一部分)。CGW13若判定为得到与安装相关的用户同意(S501：“是”)，则判定第二条件是否成立，判定是否能够与中心装置3进行数据通信(S502、相当于安装条件判定步骤的一部分)。CGW13基于DCM12中的通信电波状况，而判定是否能够与中心装置3进行数据通信。

CGW13若判定为能够与中心装置3进行数据通信(S502：“是”)，则判定第三条件是否成立，判定车辆状态是否为能够安装(S503、相当于安装条件判定步骤的一部分)。作为车辆状态，例如CGW13判定车辆电池40的电池余量是否为规定容量以上，在改写对象ECU19的存储器结构为1面存储器的情况下，判定车辆是否为驻车状态(IG断开状态)等，判定车辆状态是否为能够安装。这些车辆状态的条件也可以是参照接收到的改写规格数据(参照图44)的结构。例如在车辆电池40的电池余量为由改写规格数据指定的规定容量以上、且与由改写规格数据指定的车辆状态(仅可为驻车状态、或者仅可为行驶状态、或者驻车状态和行驶状态均可)一致等的情况下，CGW13判定为车辆状态为能够安装。

CGW13若判定为车辆状态为能够安装(S503：“是”)，则判定第四条件是否成立，判定改写对象ECU19是否能够安装(S504、相当于安装条件判定步骤的一部分)。例如在改写对象ECU19未产生故障代码，而对改写对象ECU19的安全访问成功等的情况下，CGW13判定为改写对象ECU19能够安装。这里，除了将写入数据写入的改写对象ECU19之外，对于与该改写对象ECU19进行协作控制的ECU19也可以确认故障代码的产生有无。即，CGW13不仅对于改写对象ECU19判定是否产生故障代码，而且对于与该改写对象ECU19进行协作控制的ECU19，也判定是否产生故障代码。

CGW13若判定为改写对象ECU19能够安装(S504：“是”)，则判定第五条件是否成立，判定写入数据是否是正常的数据(S505、相当于安装条件判定步骤的一部分)。在为符合改写对象ECU19的写入面(非运用面)的写入数据，针对写入数据的完整性的验证结果正常等的情况下，CGW13判定为写入数据为正常的数据。CGW13若判定为写入数据为正常的数据(S505：“是”)，则向改写对象ECU19指示应用程序的安装(S506、相当于安装指示步骤)，这样，CGW13以满足第一条件为条件，进行第二条件以后的判定。另外，CGW13最后进行第五条件的判定。CGW13若判定为第一条件至第五条件全部成立，则向改写对象ECU19指示应用程序的安装。

另一方面，CGW13若判定为未得到与安装相关的用户同意(S501：“否”)，判定为不能与中心装置3进行数据通信(S502：“否”)，判定为车辆状态为不能安装(S503：“否”)，判定为改写对象ECU19不能安装(S504：“否”)，判定为写入数据不是正常的数据(S505：“否”)，则不向改写对象ECU19指示应用程序的安装。另外，在上述的处理中，说明了在其他的条件之前判定得到与安装相关的用户同意的条件的结构，但也可以是在其他的条件之后进行判定的结构。

CGW13若向改写对象ECU19指示应用程序的安装，则向改写对象ECU19分发写入数据(S507)，判定是否完成了安装(S508)。CGW13若判定为完成了安装(S508：“是”)，则判定第六条件是否成立，判定是否得到与激活相关的用户同意(S509)。CGW13若判定为得到与激活相关的用户同意(S509：“是”)，则判定第七条件是否成立，判定车辆状态是否为能够激活的状态(S510)。

CGW13若判定为车辆状态为能够激活的状态(S510：“是”)，则判定第八条件是否成立，判定改写对象ECU19是否处于能够激活的状态(S511)。CGW13若判定为改写对象ECU19处于能够激活的状态(S511：“是”)，则向改写对象ECU19指示激活(S512)，这样，CGW13若判定为第六条件至第八条件全部成立，则向改写对象ECU19指示激活。

另外，在改写对象ECU19为多个的情况下，CGW13也可以单独地指示安装，也可以统一指示。在改写对象ECU19为ECU(ID1)、ECU(ID2)的情况下，在独立地指示安装的形式中，如图99所示，CGW13对于ECU(ID1)判定安装条件是否成立。CGW13若对于ECU(ID1)判定为安装条件成立，则向ECU(ID1)指示安装。接下来，CGW13对于ECU(ID2)判定安装条件是否成立。这里，作为安装条件，CGW13只要对于ECU(ID2)判定第四条件和第五条件是否成立即可。CGW13若对于ECU(ID2)判定为安装条件成立，则向ECU(ID2)指示安装。

在改写对象ECU19为ECU(ID1)、ECU(ID2)的情况下，在统一指示安装的形式中，如图100所示，CGW13对于ECU(ID1)判定安装条件是否成立。即，CGW13判定第一条件至第三条件、以及对于ECU(ID1)的第四条件和第五条件。CGW13若对于ECU(ID1)判定为安装条件成立，则对于ECU(ID2)判定安装条件是否成立。即，CGW13判定对于ECU(ID2)的第四条件和第五条件。若对于ECU(ID2)安装条件成立，则CGW13向ECU(ID1)和ECU(ID2)指示安装。CGW13例如同时并行地向ECU(ID1)传输改写数据以及向ECU(ID2)传输改写数据。这样，在统一指示安装的形式中，CGW13判定第一条件至第三条件、以及对于全部的改写对象ECU的第四条件和第五条件。而且，CGW13在满足这些全部的条件的基础上，指示安装。

像以上说明的那样，CGW13通过在向改写对象ECU19指示安装之前进行安装指示判定处理，若判定为得到与安装相关的用户同意的第一条件、能够与中心装置3进行数据通信的第二条件、车辆状态为能够安装的状态的第三条件、改写对象ECU19处于能够安装的状态的第四条件、写入数据为正常的数据的第五条件全部成立，则向改写对象ECU19指示应用程序的安装。能够对改写对象ECU19适当地指示应用程序的安装。

(6)安全访问密钥的管理处理

参照图101至图105对安全访问密钥的管理处理进行说明。安全访问密钥是用于在CGW13进行写入数据的安装之前在访问改写对象ECU19时进行设备认证的密钥。车辆用程序改写系统1在CGW13中进行安全访问密钥的管理处理。这里，以通过上述的(3)写入数据的传输判定处理、或者(4)写入数据的获取判定处理，CGW13处于能够从DCM12获取写入数据的状态为前提进行说明。使用安全访问密钥的设备认证相当于上述的(5)安装的指示判定处理的第四条件(步骤S505)。

在CGW13向改写对象ECU19分发写入数据时，CGW13需要在与改写对象ECU19之间使用安全访问密钥来进行安全访问(设备认证)。在该情况下，考虑如下的方法，即在CGW13中，向改写对象ECU19请求随机数值的生成，从改写对象ECU19获取由改写对象ECU19生成的随机数值，计算该获取的随机数值而生成安全访问密钥。然而，在这样的方法中，如果在未进行应用程序的改写时也从改写对象ECU19获取随机数值，则能够保存安全访问密钥，因此会产生安全访问密钥的泄漏风险。

另外，在CGW13中，如果构成为向中心装置3发送从改写对象ECU19获取的随机数值，中心装置3计算随机数值而生成安全访问密钥，则可以不用保存安全访问密钥，因此能够减少安全访问密钥的泄漏风险。然而，在中心装置3计算随机数值的结构中，直到改写对象ECU19从中心装置3获取随机数值为止的待机时间变长，很难满足诊断通信的时间规定。根据这样的情况，在本实施方式中采用以下的结构。

如图101所示，供应商使用安全访问密钥的加密、解码密钥将每个改写对象ECU19的安全访问密钥进行加密化而生成随机数值。这里所说的随机数值还包含与过去使用的值不同的值、与过去使用的值相同的值的双方，是指随机的值。随机数值是加密化的安全访问密钥。供应商将所生成的随机数值与重编数据一同提供。安全访问密钥、安全访问密钥的加密、解码密钥、随机数值对于每个ECU19是唯一的密钥。

OEM若被从供应商提供重编数据和随机数值，则将该提供的随机数值与识别ECU19的ECU(ID)建立对应关系，储存于图44所示的CGW用的改写规格数据。另外，OEM将为了对随机数值进行解码化所需要的密钥模式、解码运算模式也储存于CGW用的改写规格数据。作为密钥模式，储存有共用密钥/公开密钥等方式、密钥长度等，作为解码运算模式，储存有解码运算所使用的算法的种类等。OEM若将随机数值、密钥模式和解码运算模式储存于CGW用的改写规格数据，则将储存了该随机数值的CGW用的改写规格数据与重编数据一同向中心装置3提供。从这些供应商提供的信息被保存于后述的ECU重配置数据DB和ECU元数据DB。

中心装置3若被从OEM提供重编数据和改写规格数据(DCM用的改写规格数据和CGW用的改写规格数据)，则向主装置11发送包含该提供的改写规格数据和重编数据的分发包。在主装置11中，DCM12若从中心装置3下载分发包，则向CGW13传输改写规格数据和写入数据。

如图102所示，CGW13在安全访问密钥的管理部78中具有安全区域78a(相当于解码密钥存储部)、随机数值提取部78b(相当于密钥导出值提取部)、密钥模式提取部78c、解码运算模式提取部78d、密钥生成部78e、安全访问执行部78f、会话转移请求部78g、以及密钥消除部78h。安全区域78a不能从ECU19的外部读出信息，配置有安全访问密钥的加密、解码密钥、解码运算算法。随机数值提取部78b从CGW用的改写规格数据的解析结果中提取在该改写规格数据中包含的随机数值(密钥导出值)。随机数值是与改写对象ECU19的ECU(ID)建立对应关系而被加密化的值。

密钥模式提取部78c从CGW用的改写规格数据的解析结果中提取在该改写规格数据中包含的密钥模式。解码运算模式提取部78d从CGW用的改写规格数据的解析结果中提取在该改写规格数据中包含的解码运算模式。

密钥生成部78e若通过随机数值提取部78b提取随机数值，则检索安全区域78a，使用配置于安全区域78a的安全访问密钥的解码密钥组中的与ECU(ID)对应的解码密钥对该提取出的随机数值进行解码化，生成安全访问密钥。在该情况下，密钥生成部78e使用由密钥模式提取部78c提取的密钥模式所确定的解码密钥，按照由解码运算模式提取部78d提取出的解码运算模式所确定的解码运算方式，对密钥导出值进行解码化。即，准备多个密钥模式和多个解码运算模式，通过CGW用的改写规格数据来指定密钥模式和解码运算模式，密钥生成部78e使用该密钥模式和解码运算模式而生成安全访问密钥。

若通过密钥生成部78e生成安全访问密钥，则安全访问执行部78f使用该生成的安全访问密钥而执行针对改写对象ECU19的安全访问。具体而言，安全访问执行部78f例如使用安全访问密钥而发送对ECU(ID)进行加密化而得的加密化数据，向改写对象ECU19请求访问。改写对象ECU19若接收到加密化数据，则使用自身保存的安全访问密钥对该接收到的加密化数据进行解码化。而且，改写对象ECU19对通过解码化而生成的解码化数据与自身的ECU(ID)进行比较，在两者一致的情况下允许对自身的访问，在两者不一致的情况下不允许对自身的访问。

会话转移请求部78g请求转移至改写会话。在从默认会话转移至改写会话之后，安全访问执行部78f执行安全访问。另外，也可以在转移至默认会话以外的会话(例如诊断会话)的基础上进行安全访问，然后，转移至改写会话。在由安全访问执行部78f执行针对改写对象ECU19的安全访问而完成了改写对象ECU19的应用程序的改写之后，密钥消除部78h消除由密钥生成部78e生成的安全访问密钥。

接下来，参照图103至图105对CGW13的安全访问密钥的管理部78的作用进行说明。CGW13执行安全访问密钥的管理程序，进行安全访问密钥的管理处理。作为安全访问密钥的管理处理，CGW13进行安全访问密钥的生成处理和安全访问密钥的消除处理。以下，依次说明各个处理。

(6-1)安全访问密钥的生成处理

CGW13若开始安全访问密钥的生成处理，则对从DCM12获取的改写规格数据进行解析(S601、相当于改写规格数据解析步骤)，从CGW用的改写规格数据中提取随机数值、密钥模式、解码运算模式(S602、相当于密钥导出值提取步骤)。

CGW13检索安全区域78a，使用配置于安全区域78a的安全访问密钥的解码密钥组中的与ECU(ID)对应的解码密钥，对从CGW用的改写规格数据中提取出的随机数值进行解码化，生成安全访问密钥(S603、相当于密钥生成步骤)

如图104所示，CGW13根据CGW用的改写规格数据生成安全访问密钥。CGW13进行转移至能够将写入数据写入的改写会话的会话转移请求(S604)，使用安全访问密钥，执行针对改写对象ECU19的安全访问(S605)，CGW13若完成安全访问的执行，则向改写对象ECU19分发写入数据(S606)，进行会话维持请求(S607)。CGW13若判定为完成了安装(S608：“是”)，则结束安全访问密钥的生成处理。

(6-2)安全访问密钥的消除处理

CGW13若开始安全访问密钥的消除处理，则判定是否完成了改写对象ECU19的应用程序的改写(S611)。CGW13若判定为完成了改写对象ECU19的应用程序的改写(S611：“是”)，则消除执行安全访问密钥的生成处理而生成的安全访问密钥(S612)，结束安全访问密钥的消除处理。

像以上说明的那样，CGW13通过进行安全访问密钥的管理处理，而从改写规格数据的解析结果中提取与改写对象ECU19对应的随机数值，使用与存储于安全区域78a的改写对象ECU19对应的解码密钥对该随机数值进行解码化，生成安全访问密钥。不从外部获取安全访问密钥，而在CGW13中生成安全访问密钥，由此能够减少安全访问密钥的泄漏风险，并且适当地执行针对改写对象ECU19的安全访问。

另外，在改写对象ECU19为多个的情况下，优选CGW13在进行各个写入数据的安装之前进行安全访问密钥的生成处理。即，如果是改写对象ECU19为ECU(ID1)、ECU(ID2)、ECU(ID3)的情况，则优选CGW13按照ECU(ID1)的安全访问密钥的生成处理、向ECU(ID1)安装写入数据、ECU(ID2)的安全访问密钥的生成处理、向ECU(ID2)安装写入数据、ECU(ID3)的安全访问密4钥的生成处理、向ECU(ID3)安装写入数据的顺序进行。例如如图99所示，作为针对ECU(ID1)的安装条件是否成立之一，CGW13进行安全访问处理，在正常允许访问的情况下，对ECU(ID1)指示安装。然后，作为针对ECU(ID2)的安装条件是否成立之一，CGW13进行安全访问处理，在正常允许访问的情况下，对ECU(ID2)指示安装。

另外，改写对象ECU19若通过由CGW13进行了对自身的安全访问而允许对自身的访问，则通过从CGW13接收会话转移请求而解除安全访问，成为写入数据能够写入到闪存的状态。会话转移请求例如是图191所示的第二状态中的“改写会话转移请求”。改写对象ECU19若在允许对自身的访问之后在规定时间(例如5秒)以内未从CGW13接收会话转移请求，则成为超时，锁定安全访问，不受理会话转移请求的接收。在确定对改写对象ECU19允许访问之后在规定时间以内不向改写对象ECU19发送会话转移请求的情况下，CGW13需要向改写对象ECU19发送会话维持请求，保持改写对象ECU19不超时，向改写对象ECU19发送会话转移请求。

另外，例如由于在改写的中途被取消操作，而在运用面写入版本1.0的应用程序，在非运用面写入版本2.0的应用程序，若从该状态产生对版本2.0的活动通知，则可以不进行安装而仅进行激活，因此也可以省略安全访问处理。

(7)写入数据的验证处理

参照图106至图114对写入数据的验证处理进行说明。车辆用程序改写系统1在CGW13中进行写入数据的验证处理。CGW13也可以在获取上述的(6)安全访问密钥的管理处理的访问允许之前进行在本实施方式中说明的写入数据的验证处理，也可以在获取访问允许之后进行。

如图106所示，供应商、OEM若生成写入数据，则对该生成的写入数据应用数据验证值计算算法而生成数据验证值。这里，写入数据可以是更新的新程序，也可以是从旧程序向新程序的差分数据。供应商、OEM对该数据验证值应用使用了规定的密钥(密钥值)的加密化而生成认证符，将写入数据与认证符建立对应关系而登记于中心装置3。具体而言，在后述的重配置数据DB中按照每个ECU19存储这些数据。而且，中心装置3生成包含写入数据和认证符的分发包，存储于包DB。

中心装置3若从主装置11产生分发包的下载请求，则根据该下载请求而向主装置11发送包含写入数据和认证符的分发包。在该情况下，从中心装置3向主装置11发送的写入数据是暗文，从中心装置3向主装置11发送的认证符也是暗文。另外，从中心装置3向主装置11发送的认证符也可以是明文。在从中心装置3向主装置11发送的认证符是明文的情况下，不需要后述的解码处理。

主装置11若从中心装置3下载分发包，则从该下载的分发包中提取改写对象ECU19的写入数据，在向改写对象ECU19分发该写入数据之前，验证该写入数据的妥当性。即，主装置11依次执行解码处理、第一验证值计算处理、第二验证值计算处理、比较处理和判定处理、验证写入数据。解码处理是对利用暗文发送的认证符进行解码的处理。第一验证值计算处理是根据解码后的认证符，使用密钥(密钥值)对作为期待值的第一数据验证值进行计算的处理。第二验证值计算处理是使用数据验证值计算算法，根据写入数据计算第二数据验证值的处理。比较处理是对第一数据验证值与第二数据验证值进行比较的处理。判定处理是根据比较处理的比较结果来判定写入数据的妥当性的处理。

如图107所示，CGW13在写入数据的验证部79中，具有可写入判定部79a、处理执行请求部79b、处理结果获取部79c、以及验证部79d。可写入判定部79a判定在改写对象ECU19中是否能够进行写入数据的写入。若由可写入判定部69a判定为在改写对象ECU19中能够进行写入数据的写入，则处理执行请求部79b向DCM12通知处理执行请求，对DCM12请求处理的执行。处理执行请求部68b向DCM12通知解码处理、第一验证值计算处理、第二验证值计算处理、比较处理、判定处理中的至少任意处理的处理执行请求。处理结果获取部68c通过被DCM12通知处理结果，而从DCM12获取处理结果。验证部79d若通过处理结果获取部68c获取处理结果，则使用该处理结果来验证写入数据。即，在上述的结构中，CGW13相当于第一装置和第一功能部，DCM12相当于第二装置和第二功能部。

接下来，参照图108至图113对CGW13中的写入数据的验证部79的作用进行说明。CGW13执行写入数据的验证程序，进行写入数据的验证处理。

CGW13若开始写入数据的验证处理，则向DCM12通知处理执行请求，对DCM12请求处理的执行(S701、相当于处理执行请求步骤)。CGW13向DCM12通知上述的解码处理、第一验证值计算处理、第二验证值计算处理、比较处理、判定处理中的至少任意处理的处理执行请求。CGW13若从DCM12获取处理结果(S702、相当于处理结果获取步骤)，则使用该获取的处理结果来验证写入数据(S703、相当于验证步骤)。

以下，例示CGW13向DCM12通知处理执行请求的几个情况。在图109的例示中，CGW13向DCM12通知解码处理、第一验证值计算处理、第二验证值计算处理的处理执行请求。DCM12若被从CGW13通知解码处理、第一验证值计算处理、第二验证值计算处理的处理执行请求，则依次执行解码处理、第一验证值计算处理、第二验证值计算处理。DCM12执行处理结果通知处理，将通过第一验证值计算处理计算出的第一数据验证值、通过第二验证值计算处理计算出的第二数据验证值作为处理结果而向CGW13通知。CGW13若执行处理结果获取处理，从DCM12获取第一数据验证值和第二数据验证值，则使用该第一数据验证值、第二数据验证值，依次执行比较处理、判定处理。CGW13根据判定处理的判定结果的正确与否来验证写入数据。在本例示中，DCM12保存用于计算第一数据验证值的密钥。

在图110的例示中，CGW13向DCM12通知解码处理、第二验证值计算处理的处理执行请求。DCM12若被从CGW13通知解码处理、第二验证值计算处理的处理执行请求，则依次执行解码处理、第二验证值计算处理，向CGW13通知通过第二验证值计算处理计算出的第二数据验证值。CGW13若执行处理结果获取处理，从DCM12获取第二数据验证值，则执行第一验证值计算处理，使用通过第一验证值计算处理计算出的第一数据验证值、该第二数据验证值，依次执行比较处理、判定处理。CGW13根据判定处理的判定结果的正确与否来验证写入数据。在本例示中，CGW13保存用于计算第一数据验证值的密钥。

在图111的例示中，CGW13向DCM12通知解码处理、第一验证值计算处理、第二验证值计算处理、比较处理的处理执行请求。DCM12若被CGW13通知解码处理、第一验证值计算处理、第二验证值计算处理、比较处理的处理执行请求，则依次执行解码处理、第一验证值计算处理、第二验证值计算处理、比较处理。DCM12执行处理结果通知处理，将比较处理的比较结果作为处理结果而向CGW13通知。CGW13若执行处理结果获取处理，从DCM12获取比较结果，则使用该比较结果，执行判定处理。CGW13根据判定处理的判定结果的正确与否来验证写入数据。在本例示中，DCM12保存用于计算第一数据验证值的密钥。

在图112的例示中，CGW13向DCM12通知解码处理、第一验证值计算处理、第二验证值计算处理、比较处理，判定处理的处理执行请求。DCM12若被CGW13通知解码处理、第一验证值计算处理、第二验证值计算处理、比较处理、判定处理的处理执行请求，则依次执行解码处理、第一验证值计算处理、第二验证值计算处理、比较处理、判定处理。DCM12执行处理结果通知处理，将判定处理的判定结果作为处理结果而向CGW13通知。CGW13若执行处理结果获取处理，从DCM12获取处理结果，则根据该处理结果所示的判定结果的正确与否来验证写入数据。在本例示中，DCM12保存用于计算第一数据验证值的密钥。

在改写对象ECU19为多个的情况下，CGW13像以下那样进行针对多个改写对象ECU19的写入数据的验证处理。在改写对象ECU19为多个的情况下，有CGW13针对多个改写对象ECU19统一验证写入数据的方法和单独地验证的方法。

在针对多个改写对象ECU19统一验证写入数据的方法中，如图113所示，CGW13例如统一验证ECU(ID1)的写入数据、ECU(ID2)的写入数据、ECU(ID3)的写入数据，向ECU(ID1)的写入数据的写入对象ECU(ID1)分发，向ECU(ID2)的写入数据的写入对象ECU(ID2)分发，向ECU(ID3)的写入数据的写入对象ECU(ID3)分发。在该情况下，通过统一进行针对多个改写对象ECU19的写入数据的验证，能够缩短从针对多个改写对象ECU19的写入数据的验证的开始到程序的改写的完成为止所需要的时间。即，相比于针对多个改写对象ECU19单独地验证写入数据的结构，能够缩短从针对多个改写对象ECU19的写入数据的验证的开始到程序的改写的完成为止所需要的时间。

在针对多个改写对象ECU19单独地验证写入数据的方法中，如图114所示，CGW13例如验证ECU(ID1)的写入数据，向ECU(ID1)的写入数据的写入对象ECU(ID1)分发，验证ECU(ID2)的写入数据，向ECU(ID2)的写入数据的写入对象ECU(ID2)分发，验证ECU(ID3)的写入数据，向ECU(ID3)的写入数据的写入对象ECU(ID2)分发。在该情况下，通过在分发写入数据之前验证写入数据，能够避免不正当的访问，能够提高可靠性。即，在针对多个改写对象ECU19统一验证写入数据的结构中，从按照改写顺序完成验证之后直到分发写入数据为止的时间根据改写顺序而不同，若从完成验证之后到分发写入数据为止的时间变长，则有可能在该期间产生因不正当的访问引起篡改的危险性，但通过在分发写入数据之前验证写入数据，能够避免这样的情况。

像以上说明的那样，CGW13通过进行写入数据的验证处理，而使从中心装置3下载分发包的DCM12执行与写入数据的验证相关联的处理中的至少一部分。在CGW13、改写对象ECU19中，即使不能确保用于存储写入数据的区域、或者不能搭载验证用的运算程序，也能够在将写入数据向改写对象ECU19写入之前，适当地进行写入数据的验证。

在图110所例示的CGW13进行第一验证值计算处理的结构中，CGW13保存密钥(密钥值)，不将该密钥向DCM12发送而进行验证处理，因此与DCM12进行第一验证值计算处理的结构相比，能够提高安全性。另外，在改写对象ECU19为多个的情况下，也可以使用在多个改写对象ECU19中共用的共用密钥(密钥值)而进行第一验证值计算处理，也可以使用在多个改写对象ECU19中不同的个别密钥(密钥值)而进行第一验证值计算处理。

另外，以上，例示了CGW13向DCM12通知处理执行请求的结构，但例如在DCM12中处理负荷增大而对本来的处理产生妨碍的情况下，也可以取代DCM12而使用导航装置、改写对象ECU19以外的ECU，向导航装置、改写对象ECU19以外的ECU通知处理执行请求。

另外，在DCM12和CGW13为一体型的情况下，在能够不对本来的处理产生妨碍地应对的情况下，也可以对自身的处理执行部请求处理执行请求。例如也可以在同一ECU内在不同软组件间进行。另外，对于作为具有DCM12和CGW13的功能的一个合并ECU而构成的主装置11，也可以应用上述的发明。例如在图109至图112中，将CGW13的处理功能作为第一功能部，将DCM12的处理功能作为第二功能部，从第一功能部向第二功能部通知处理执行请求，使执行结果从第二功能部返回到第一功能部。在作为合并ECU而构成的主装置11中，在处理负荷增大而对通信处理、中继处理产生妨碍的情况下，也可以取代第二功能部，而向导航装置、改写对象ECU19以外的ECU通知处理执行请求。

另外，数据验证值也可以利用应用程序整体计算一个值，也可以利用应用程序的块单位计算多个值。如果写入数据是整体数据，则能够在写入数据的完成后在完整性验证中使用。

另外，相对于安全访问是验证CGW13与改写对象ECU19是否可以连接的方法，写入数据的验证包含作为写入数据的分发目的地的中心装置3正规(基于TLS通信的连接、相互认证)、从中心装置3下载写入数据的通信路径正规(通信路径的秘密化、加密化)、从中心装置3下载的写入数据未被篡改(篡改检测)、从中心装置3下载的写入数据不能篡改(加密化)这样的概念。

另外，虽然对新程序的改写时的写入数据进行了说明，但向旧程序回写时的回滚时的写入数据也同样。在该情况下，CGW13也可以在从中心装置3下载的时刻验证回滚时的写入数据，但也可以在由于产生了写入的取消请求而将回滚用的写入数据向改写对象ECU19分发之前进行验证。

(8)数据储存面信息的发送控制处理

参照图115至图117对数据储存面信息的发送控制处理进行说明。车辆用程序改写系统1在CGW13中进行数据储存面信息的发送控制处理。

如图115所示，CGW13在数据储存面信息的发送控制部80中具有数据储存面信息获取部80a、数据储存面信息发送部80b、改写方法确定部80c、改写方法指示部80d。作为ECU结构信息，数据储存面信息获取部80a从各ECU19获取与硬件和软件相关的信息。详细地说，在多个面具有数据储存面的2面存储器ECU和1面挂起存储器ECU的情况下，获取包含数据储存面各自的版本信息的软件ID和能够确定运用面的信息来作为2面改写信息(以下，称为面信息)。

数据储存面信息发送部80b若通过数据储存面信息获取部80a获取包含面信息的ECU结构信息，则将该获取的面信息作为ECU结构信息之一而从DCM12向中心装置3发送。数据储存面信息发送部80b也可以在每次IG开关42切换接通断开时向中心装置3发送ECU结构信息，也可以根据来自中心装置3的请求而向中心装置3发送ECU结构信息。另外，不仅对于2面存储器ECU和1面挂起存储器ECU，而且对于1面独立存储器ECU，数据储存面信息发送部80b也可以一并发送包含面信息的ECU结构信息。

改写方法确定部80c根据CGW13用的改写规格数据的解析结果来确定改写方法。改写方法表示改写对象ECU19的安装时的电源切换方法。改写方法指示部80d若通过改写方法确定部80c确定改写方法，则向改写对象ECU19指示基于该确定的改写方法的应用程序的改写。即，改写方法指示部80d若通过改写方法确定部80c确定基于电源自保持的改写方法，则向改写对象ECU19指示基于电源自保持的应用程序的改写。改写方法指示部80d若通过改写方法确定部80c确定基于电源控制的改写方法，则不使用电源自保持而向改写对象ECU19指示基于电源控制的应用程序的改写。

接下来，参照图116和图117对CGW13的数据储存面信息的发送控制部80的作用进行说明。CGW13执行数据储存面信息的发送控制程序，进行数据储存面信息的发送控制处理。

CGW13若开始数据储存面信息的发送控制处理，则向所有ECU19发送包含面信息的ECU结构信息请求(S801)，从所有ECU19获取包含面信息的ECU结构信息(S802、相当于数据储存面信息获取步骤)。CGW13若从各改写对象ECU19获取ECU结构信息，则向DCM12发送该获取的ECU结构信息(S803、相当于数据储存面信息发送步骤)，等待从DCM12获取写入数据和改写规格数据(S804)。这里，在改写对象ECU19预先确定的情况下，CGW13也可以仅从该确定的改写对象ECU19获取面信息等。

DCM12若从CGW13接收ECU结构信息，则暂时积蓄该接收到的ECU结构信息，在到了向中心装置3发送(上传)ECU结构信息的时机时，向中心装置3发送该ECU结构信息。中心装置3若从DCM12接收ECU结构信息，则对该接收到的ECU结构信息进行保存、解析。

中心装置3确定面信息的发送源即各ECU19的各面的应用程序的版本和哪个面是运用面，确定适合于该确定的两个面的应用程序的版本和运用面的写入数据(相当于更新数据选择步骤)。例如在A面为运用面、储存于该运用面的应用程序为版本2.0、B面为非运用面、储存于该非运用面的应用程序为版本1.0的情况下，中心装置3确定B面用的版本3.0的写入数据来作为写入数据。在写入数据为差分数据的情况下，中心装置3确定从版本1.0更新为版本3.0的差分数据。中心装置3若确定写入数据，则向DCM12发送包含该确定的写入数据和改写规格数据的分发包(相当于分发包发送步骤)。

中心装置3也可以静态地选择向DCM12发送的分发包，也可以动态地生成。中心装置3在静态地选择向DCM12发送的分发包的情况下，管理多个储存有写入数据的分发包，选择适合于非运用面的写入数据，从多个分发包中选择储存有该选择的写入数据的分发包而向DCM12发送。中心装置3在动态地生成向DCM12发送的分发包的情况下，若确定适合于非运用面的写入数据，则生成储存了该确定的写入数据的分发包而向DCM12发送。

DCM12若从中心装置3下载分发包，则从该下载的分发包中提取写入数据和改写规格数据，向CGW13传输该提取出的写入数据和改写规格数据。

CGW13若判定为从DCM12获取写入数据和改写规格数据(S804：“是”)，则对该获取的改写规格数据进行解析(S805)，根据该改写规格数据的解析结果来判定针对改写对象ECU19的改写方法(S806、S807)。

CGW13若判定为改写方法是基于电源自保持的改写(S806：“是”)，则以处于能够安装的车辆状态为条件，向DCM12发送写入数据获取请求，从DCM12获取写入数据，向改写对象ECU19分发该获取的写入数据，通过电源自保持来改写应用程序(S808)，结束数据储存面信息的发送控制处理。关于通过电源自保持来改写应用程序的方法，像在使用上述的图64和图65而通过(イ)电源自保持来改写应用程序的情况下说明的那样。

CGW13若判定为改写方法是基于电源控制的改写(S807：“是”)，则以处于驻车中为条件，向DCM12发送写入数据获取请求，从DCM12获取写入数据，向改写对象ECU19分发该获取的写入数据，通过电源控制来改写应用程序(S809)，结束数据储存面信息的发送控制处理。关于通过电源控制来改写应用程序的方法，像在使用上述的图62和图63而通过(ア)电源控制来改写应用程序的情况下说明的那样。

像以上说明的那样，CGW13通过进行数据储存面信息的发送控制处理，而向中心装置3通知包含面信息的ECU结构信息，使得从中心装置3向DCM12下载包含适合于ECU结构信息的写入数据的分发包。CGW13从DCM12获取适合于该面信息的写入数据，向改写对象ECU19分发该写入数据。在将搭载有在2面具有数据储存面的闪存的ECU19作为改写对象的情况下，能够适当地改写应用程序。

另外，作为中心装置3对分发包进行分发的形式，存在以下所示的第一分发形式至第三分发形式。在第一分发形式中，中心装置3例如分发储存A面用的版本2.0的写入数据和B面用的版本2.0的写入数据的一个分发包。DCM12从自中心装置3下载的分发包中提取A面用的版本2.0的写入数据和B面用的版本2.0的写入数据，向CGW13传输该提取出的写入数据。CGW13若被从DCM12传输A面用的版本2.0的写入数据和B面用的版本2.0的写入数据，则选择其中的任意一个而向改写对象ECU19分发。即，采用如下的结构：与各数据储存面对应的写入数据包含于分发包，在主装置11中选择适合于改写对象ECU19的改写数据。

在第二分发形式中，中心装置3例如选择储存了A面用的版本2.0的写入数据的分发包或者储存了B面用的版本2.0的写入数据的分发包中的任一方来分发。DCM12从自中心装置3下载的分发包中提取写入数据，向CGW13传输该提取出的写入数据。CGW13向改写对象ECU19分发从DCM12传输来的写入数据。即，采用如下的结构：基于从DCM12上传的面信息，中心装置3选择包含非运用面用的写入数据的分发包。

在第三分发形式中，中心装置3例如分发储存了在A面用和B面用中共享的版本2.0的写入数据的分发包。DCM12从自中心装置3下载的分发包中提取在A面用和B面用中共享的版本2.0的写入数据，向CGW13传输该提取出的写入数据。CGW13向改写对象ECU19分发从DCM12传输来的在A面用和B面用中共享的版本2.0的写入数据。改写对象ECU19若从CGW13接收在A面用和B面用中共享的版本2.0的写入数据，则向A面或者B面中的任一方写入该接收到的写入数据。在该情况下，在改写对象ECU19中，在执行应用程序时，微机的地址解决功能起作用，由此即使将写入数据写入A面或者B面中的任一方都适当地动作。即，写入对象ECU19的微机解决伴随着面的差异的执行地址的差异，由此中心装置3和主装置11能够在不意识面的情况下进行动作。

包含从CGW13经由DCM12向中心装置3发送的面信息的ECU结构信息除了包含能够确定两个面的应用程序的版本和运用面的信息之外，还可以包含车辆确定信息、系统确定信息、ECU确定信息、利用环境信息等。

车辆确定信息是用于确定分发包的分发目的地的车辆的唯一的信息，例如为VIN(Vehicle Identification Number：车辆识别编号)。在符合OBD(On-board diagnostics：车载诊断)法规的车辆中，能够根据OBD法规的规定来利用VIN，但如果是像例如EV车辆那样不符合OBD法规的车辆，则不能利用VIN，因此采用取代VIN的单车识别信息即可。

系统确定信息是用于确定是怎样的重编系统的唯一的信息。CGW13能够对于能够进行利用了自身管理的诊断通信的有线改写的系统，进行无线改写，但不能对除此以外的独自方式的系统进行无线改写。即，这是因为，利用经由有线获取的程序更新的结构，进行经由无线获取的程序更新的系统。因此，在中心装置3中，需要判定可以向哪个系统分发哪个分发包，通过使用系统确定信息，能够管理在车辆搭载了怎样的系统。中心装置3通过判定系统确定信息，能够判定每个系统的改写方式、将多个系统作为改写对象的情况下的改写顺序等。

ECU确定信息是用于确定改写对象ECU19的唯一的信息，是包含用于唯一地确定改写ECU和写入到该改写对象ECU19的应用程序的软件版本、以及硬件版本的信息。ECU确定信息也相当于ECU产品号。在以整体数据写入最新的软件的情况下，也可以仅是硬件版本。另外，也可以定义能够确定规格版本、配置版本等应用程序的信息，此外，也可以定义微机ID、子微机ID、闪存ID、软件子版本、软件后代版本等。

利用环境信息是用于确定用户利用车辆的环境的唯一的信息。通过从CGW13经由DCM12向中心装置3发送环境信息，中心装置3能够分发适合于用户利用车辆的环境的应用程序。例如向喜好从停止时起的急加速驾驶的用户分发专攻加速的应用程序，向喜好环保驾驶的用户分发虽然加速性能差但专攻环保驾驶的应用程序等，能够分发适合于用户利用车辆的环境的应用程序。

另外，以上，对在改写对象ECU19的微机中搭载有闪存的情况进行了说明，但在改写对象ECU19的微机连接有外置存储器的情况下，使外置存储器与2面存储器同等地进行处理，将外置存储器的写入区域区分为两个而将写入数据写入。在改写对象ECU19的微机搭载有闪存，并且连接有外置存储器的情况下，有时进行将储存于外置存储器的程序暂时复制(复印)到微机的存储器的处理。外置存储器通常作为ECU的动作日志的存储区域使用，因此优选在开始将写入数据写入到外置存储器的情况下，中断动作日志的存储，在完成了将写入数据写入到外置存储器的情况下，重新开始动作日志的存储。

并不局限于改写应用程序的情况，例如地图数据等具有逐一更新的性质的数据也具有2面和版本这样的概念，因此在改写地图数据的情况下也相同。

(9)非改写对象的电源管理处理

参照图118至图123对非改写对象ECU19的电源管理处理进行说明。车辆用程序改写系统1在CGW13中进行非改写对象ECU19的电源管理处理。在本实施方式中，成为通过DCM12完成分发包的下载，CGW13获取改写规格数据，在车辆处于驻车状态下CGW13向改写对象ECU19分发写入数据的状况。CGW13在向改写对象ECU19分发写入数据的情况下，向电源管理ECU20请求IG电源接通，使全部的ECU19成为启动状态。

如图118所示，CGW13在非改写对象ECU19的电源管理部81中具备改写对象确定部81a、可安装判定部81b、状态转移控制部81c、改写顺序确定部81d。改写对象确定部81a根据改写规格数据的解析结果而确定改写对象ECU19和非改写对象ECU19。可安装判定部81b判定是否能够安装于改写对象ECU19。

状态转移控制部81c能够转移ECU19的状态，使停止状态或者休眠状态的ECU19转移至启动状态(唤醒状态)、或者使启动状态的ECU19转移至停止状态或者休眠状态。另外，状态转移控制部81c使通常动作状态的ECU19转移至省电力动作状态、或者使省电力动作状态的ECU19转移至通常动作状态。状态转移控制部81c若由可安装判定部81b判定为能够安装，则控制为使至少一个以上的非改写对象ECU19处于停止状态、休眠状态或者省电力动作状态。改写顺序确定部81d根据改写规格数据的解析结果来确定改写对象ECU19的改写顺序。

接下来，参照图119至图123对CGW13的非改写对象ECU19的电源管理部81的作用进行说明。CGW13执行非改写对象的电源管理程序，进行非改写对象的电源管理处理。这里，对CGW13使成为管理对象的全部的ECU19处于启动状态的情况进行说明。

CGW13若开始非改写对象ECU19的电源管理处理，则根据CGW用的改写规格数据的解析结果来确定改写对象ECU19和非改写对象ECU19(S901)，根据改写规格数据的解析结果来确定一个以上的改写对象ECU19的改写顺序(S902)。CGW13判定是否能够进行写入数据的写入(S903、相当于可写入判定步骤)，若判定为能够进行写入数据的写入(S903：“是”)，则向ACC系的非改写对象ECU19和IG系的非改写对象ECU19发送电源断开请求(停止请求)，使ACC系的非改写对象ECU19和IG系的非改写对象ECU19从启动状态转移至停止状态(S904、相当于状态转移控制步骤)。

CGW13判定是否完成了向相应的全部的ECU19发送了电源断开请求(S905)，若判定为完成了向相应的全部的ECU19发送电源断开请求(S905：“是”)，则向+B电源系统的非改写对象ECU19发送休眠请求，使+B电源系统的非改写对象ECU19从启动状态转移至休眠状态(S906、相当于状态转移控制步骤)。

CGW13判定是否完成了向相应的全部的ECU19发送了休眠请求(S907)，若判定为完成了向相应的全部的ECU19发送休眠请求(S907：“是”)，则判定是否对于全部的改写对象ECU19完成了应用程序的改写(S908)。CGW13若判定为对于全部的改写对象ECU19完成了应用程序的改写(S908：“是”)，则结束非改写对象ECU19的电源管理处理。CGW13若判定为对于全部的改写对象ECU19未完成应用程序的改写(S908：“否”)，则返回步骤S904，重复步骤S904之后的步骤。

在改写对象ECU19为多个的情况下，CGW13也可以独立地转移多个改写对象ECU19的状态，也可以统一转移多个改写对象ECU19的状态。即，在图119中，表示CGW13对非改写对象ECU19发送电源断开请求或者休眠请求的处理。在如下所示的图120和图121中，关于除了进行针对非改写对象ECU19的电源管理处理，还进行针对改写对象ECU19的电源管理处理的情况进行说明。

首先，使用图120，对CGW13独立地转移多个改写对象ECU19的状态的情况进行说明。如图120所示，关于例如改写对象ECU19为ECU(ID1)、ECU(ID2)、ECU(ID3)，在驻车中从改写顺序较早的一方开始依次改写在ECU(ID1)、ECU(ID2)、ECU(ID3)中指定的改写对象ECU19的情况，进行说明。

CGW13使ECU(ID1)、ECU(ID2)、ECU(ID3)全部从停止状态或者休眠状态转移至启动状态。CGW13使在第一个改写的ECU(ID1)保持启动状态，使ECU(ID2)、ECU(ID3)从启动状态转移至停止状态或者休眠状态，向ECU(ID1)分发写入数据。CGW13若完成向ECU(ID1)分发写入数据，则使ECU(ID1)从启动状态转移至停止状态或者休眠状态，使第二个改写的ECU(ID2)从停止状态或者休眠状态转移至启动状态，使ECU(ID3)保持停止状态或者休眠状态，向ECU(ID2)分发写入数据。

CGW13若完成向ECU(ID2)分发写入数据，则使ECU(ID1)保持停止状态或者休眠状态，使ECU(ID2)从启动状态转移至停止状态或者休眠状态，使在第三个改写的ECU(ID3)从停止状态或者休眠状态转移至启动状态，向ECU(ID3)分发写入数据。CGW13若完成向ECU(ID3)分发写入数据，则使ECU(ID1)、ECU(ID2)保持停止状态或者休眠状态，使ECU(ID3)从启动状态转移至停止状态或者休眠状态。这样，CGW13控制为，多个改写对象ECU19中的仅当前改写中的ECU19为启动状态。

接下来，使用图121，对CGW13统一转移多个改写对象ECU19的状态的情况进行说明。如图121所示，关于例如改写对象ECU19为ECU(ID1)、ECU(ID2)、ECU(ID3)，在驻车中从改写顺序较早的一方开始依次改写在ECU(ID1)、ECU(ID2)、ECU(ID3)中指定的改写对象ECU19的情况进行说明。

CGW13使ECU(ID1)、ECU(ID2)、ECU(ID3)全部从停止状态或者休眠状态转移至启动状态。CGW13使ECU(ID1)、ECU(ID2)、ECU(ID3)全部保持启动状态，向ECU(ID1)分发写入数据。CGW13若完成向ECU(ID1)分发写入数据，则向ECU(ID2)分发写入数据。CGW13若完成向ECU(ID2)分发写入数据，则向ECU(ID3)分发写入数据。CGW13若完成向ECU(ID3)分发写入数据，则使ECU(ID1)、ECU(ID2)、ECU(ID3)全部从启动状态转移至停止状态或者休眠状态。这样，CGW13控制为，使多个改写对象ECU19全部成为启动状态直到安装全部完成为止。这里，CGW13也可以同时并行地向ECU(ID1)、ECU(ID2)、ECU(ID3)分发写入数据。

在驻车中改写对象ECU19改写应用程序的情况下，由于不一定是朝向改写对象ECU19的供给电压稳定的环境，因此在应用程序的改写中车辆电池40有可能变为电池耗尽。特别是若改写对象ECU19为多个，则应用程序的改写所需要的时间变长，因此在应用程序的改写中车辆电池40变为电池耗尽的可能性变高。关于这一点，通过像上述那样使非改写对象ECU19为停止状态或者休眠状态，而将在程序的改写中车辆电池40的电池余量不充分的情况防患于未然。此外，通过使改写对象ECU19中的当前未处于改写中的ECU19为停止状态或者休眠状态，能够进一步抑制消耗电力。

以上，说明了在驻车中对改写对象ECU19的应用程序进行改写的情况，然而对在车辆行驶中对改写对象ECU19的应用程序进行改写的情况进行说明。在车辆行驶中改写对象ECU19改写应用程序的情况下，由于朝向改写对象ECU19的供给电压处于稳定的环境，因此不用担心在应用程序的改写中车辆电池40变为电池耗尽的情况，但也存在车辆电池40的电池余量较少的情况。根据这样的情况，优选在车辆行驶中，使不需要动作的ECU19转移至停止状态或者休眠状态。如图122所示，在车辆行驶中不需要动作的ECU44与+B电源线37连接，但在采用不与ACC电源线38和IG电源线39连接的结构的情况下，CGW13使在该车辆行驶中不需要动作的ECU44从启动状态转移至停止状态或者休眠状态。ECU44例如是具有防盗等功能的ECU。即，在车辆行驶中全部的ECU19处于启动状态的过程中，CGW13使不需要动作且不是改写对象的ECU44转移至停止状态或者休眠状态。由此，能够抑制伴随着车辆行驶中的安装的消耗电力的增加。

另外，CGW13监视车辆电池40的电池余量，进行上述的非改写对象的电源管理处理。这里，使用图123对电池余量的监视处理进行说明。CGW13若开始电池余量的监视处理，则在向改写对象ECU19分发写入数据的过程中监视电池余量(S911)，判定电池余量是否为第一规定容量以上、电池余量是否小于第一规定容量且为第二规定容量以上、电池余量是否小于第二规定容量(S912～S914)。

CGW13若判定为电池余量为第一规定容量以上(S912：“是”)，则使非改写对象ECU19保持启动状态，持续向改写对象ECU19分发写入数据(S915)。CGW13若判定为电池余量小于第一规定容量且为第二规定容量以上(S913：“是”)，则使非改写对象ECU19中的在行驶中不需要动作的ECU转移至停止状态或者休眠状态，持续向改写对象ECU19分发写入数据(S916)。CGW13若判定为电池余量小于第二规定容量(S914：“是”)，则判定是否能够中断改写(S917)。

CGW13若判定为能够中断改写(S917：“是”)，则中断写入数据的分发(S918)。CGW13若判定为不能中断改写(S917：“否”)，则使非改写对象ECU19中的能够转移至停止状态或者休眠状态的全部的ECU转移至停止状态或者休眠状态(S919)。

CGW13判定是否完成了改写(S920)，若判定为未完成改写(S920：“否”)，则返回步骤S911，重复步骤S911以后的步骤。CGW13若判定为完成了改写(S920：“是”)，则使停止状态或者休眠状态的改写对象ECU19转移至启动状态(S921)，结束电池余量的监视处理。这里，第一规定容量和第二规定容量的值也可以由CGW13预先保存，也可以使用由改写规格数据指定的值。

另外，CGW13也可以在步骤S919中，例如将具有警报功能等特定的功能的ECU19从转移至停止状态或者休眠状态的对象中除去，使除了具有特定的功能的ECU19以外的非改写对象ECU19从启动状态转移至停止状态或者休眠状态。在改写对象ECU19在应用程序的改写中能够执行应用控制的情况下，CGW13也可以使除了能够与该改写对象ECU19进行通信的ECU19之外的非改写对象ECU19为停止状态或者休眠状态。也可以是，若在全部的ECU19处于停止状态或者休眠状态时，例如车辆位置处于规定位置、或者当前时刻为规定时刻等而改写条件成立，则CGW13使改写对象ECU19从停止状态或者休眠状态转移至启动状态。

CGW13也可以将启动电源(+B电源系统ECU、ACC系统ECU、IG系统ECU)、区域组(车身系统、行驶系统、多媒体系统)、同步时机中的任一方作为基准对改写对象ECU19或者非改写对象ECU19进行分组，使改写对象ECU19按照组单位成为启动状态、或者使非改写对象ECU19按照组单位成为停止状态或者休眠状态。

另外，CGW13也可以是按照总线单位进行电源控制的结构。即，CGW13若判定为与特定的总线连接的全部的ECU19为非改写对象ECU19，则通过使该特定的总线的电源断开，而使与该特定的总线连接的全部的非改写对象ECU19转移至停止状态或者休眠状态。

像以上说明的那样，CGW13通过进行非改写对象的电源管理处理，若判定为针对改写对象ECU19能够安装，则使至少一个以上的非改写对象ECU19为停止状态、休眠状态或者省电力动作状态。能够将在应用程序的改写中车辆电池40的电池余量不充分的情况防患于未然。另外，通过使非改写对象ECU19处于停止状态、休眠状态或者省电力动作状态，能够抑制通信负荷的增大。

(10)文件的传输控制处理

参照图124至图133对文件的传输控制处理进行说明。车辆用程序改写系统1在CGW13中进行文件的传输控制处理。本实施方式是将DCM12(相当于第一装置)保存的改写数据经由CGW13(相当于第二装置)向改写对象ECU19(相当于第三装置)发送时的处理。

如图124所示，CGW13在文件的传输控制部82中，具有传输对象文件确定部82a、第一数据大小确定部82b、获取信息确定部82c、第二数据大小确定部82d、以及分割文件传输请求部82e。传输对象文件确定部82a使用改写规格数据的解析结果，将包含写入到改写对象ECU19的写入数据的文件确定为传输对象文件。例如在改写对象ECU19为ECU(ID1)、ECU(ID2)和ECU(ID3)的情况下，传输对象文件确定部82a从图44所示的CGW用的改写规格数据中获取ECU(ID1)、ECU(ID2)和ECU(ID3)的ECU信息，根据该获取的ECU信息将包含写入数据的文件确定为传输对象文件。作为传输对象文件，也可以确定获取该文件时的地址、索引，也可以确定该文件的文件名。

若通过传输对象文件确定部82a确定传输对象文件，则第一数据大小确定部82b确定用于获取该传输对象文件的第一数据大小。若通过传输对象文件确定部82a确定传输对象文件，则作为用于获取该传输对象文件的获取信息，获取信息确定部82c确定地址。另外，在本实施方式中，作为用于获取传输对象文件的获取信息，确定地址，但如果是用于获取传输对象文件的获取信息，则并不局限于地址，也可以是文件名称、ECU(ID)等。第二数据大小确定部82d确定用于向改写对象ECU19分发写入数据的第二数据大小。即，第一数据大小是从DCM12向CGW13的数据传输大小，第二数据大小是从CGW13向改写对象ECU19的数据传输大小。

若通过获取信息确定部82c确定地址，通过第一数据大小确定部82b确定第一数据大小，则分割文件传输请求部82e向DCM12指定该地址和第一数据大小，向DCM12请求分割文件的传输。例如在应该向ECU(ID1)分发的写入文件的数据量为1M字节的情况下，分割文件传输请求部82e请求从地址0x10000000按照1k字节传输写入数据。

接下来，参照图125至图133对CGW13的文件的传输控制部82的作用进行说明。CGW13执行文件的传输控制程序，进行文件的传输控制处理。

CGW13若判定为从DCM12接收到解包完成通知信号，则开始文件的传输控制处理。如图46所示，解包是指将分发包文件分成每个ECU的数据和各改写规格数据的处理。CGW13若开始文件的传输控制处理，则向DCM12发送规定的地址(S1001)。DCM12若从CGW13接收规定的地址，则以该规定的地址的接收为契机，向CGW13传输CGW用的改写规格数据。CGW13通过被DCM12传输CGW用的改写规格数据，而获取CGW用的改写规格数据(S1002)。

CGW13若从DCM12获取CGW用的改写规格数据，则对该获取的CGW用的改写规格数据进行解析(S1003)，根据改写规格数据的解析结果来确定传输对象文件(S1004、相当于传输对象文件确定步骤)。CGW13确定与该传输对象文件对应的地址(S1005、相当于获取信息确定步骤)，确定与该传输对象文件对应的第一数据大小(S1006、相当于第一数据大小确定步骤)。CGW13根据SID(Service Identifier：服务标识符)35的规定向DCM12发送该确定的地址和数据大小，在存储器区域指定该地址和数据大小，向DCM12请求分割文件的传输(S1007)。

DCM12若从CGW13接收地址和数据大小，则对DCM用的改写规格数据进行解析，将与该地址和数据大小对应的文件作为分割文件而向CGW13传输。CGW13通过被DCM12传输分割文件而获取分割文件(S1008)。在该情况下，CGW13也可以在将该获取的文件存储于RAM之后，存储于闪存。

CGW13判定是否完成了应该获取的全部的分割文件的获取(S1009)。例如在应该向ECU(ID1)分发的写入文件的数据量为1M字节的情况下，CGW13获取按照每1k字节的分割文件，重复按照每1k字节的分割文件的获取而判定是否完成了获取1M字节的数据量。CGW13若判定为未完成应该获取的全部的分割文件的获取(S1009：“否”)，则返回步骤S1004，重复步骤S1004以后的步骤。CGW13若判定为完成了应该获取的全部的文件的获取(S1009：“是”)，则结束文件的传输控制处理。另外，在改写对象ECU19为多个的情况下，CGW13针对各改写对象ECU19重复上述的文件的传输控制处理。

即，例如在改写对象ECU19为ECU(ID1)、ECU(ID2)和ECU(ID3)的情况下，CGW13若完成向ECU(ID1)分发写入数据，则对于ECU(ID2)进行文件的传输控制处理，若完成向ECU(ID2)分发写入数据，则对于ECU(ID3)进行文件的传输控制处理。另外，CGW13也可以依次进行针对多个改写对象ECU19的传输控制处理，也可以并行进行。

在图126中，表示在DCM12的存储器内，例如ECU(ID1)的写入数据文件存储于地址“1000”～“3999”、ECU(ID2)的写入数据文件存储于地址“4000”～“6999”、ECU(ID3)的写入数据文件存储于地址“7000”～的情况。

在该情况下，如图127所示，CGW13若从DCM12接收解包完成通知信号，则向DCM12发送地址“0000”，从DCM12获取改写规格数据。即，DCM12若将地址“0000”的接收判定为是CGW用的改写数据的获取请求，则向CGW13发送CGW用的改写规格数据。CGW13指定ECU(ID1)作为写入数据的传输对象，指定地址“1000”和数据大小“1k字节”，从DCM12获取包含存储于地址“1000”～“1999”的ECU(ID1)的写入数据的分割文件。CGW13若从DCM12获取分割文件，则向ECU(ID1)分发在该分割文件中包含的写入数据。

CGW13接下来同样地指定ECU(ID1)作为写入数据的传输对象，指定地址“2000”和数据大小“1k字节”，从DCM12获取包含存储于地址“2000”～“2999”的ECU(ID1)的写入数据的分割文件。CGW13若从DCM12获取分割文件，则向ECU(ID1)分发在该分割文件中包含的写入数据。直到写入数据向ECU(ID1)的写入全部完成为止，CGW13重复从DCM12按照每1k字节获取分割文件，重复向ECU(ID1)分发在该分割文件中包含的写入数据。即，CGW13若从DCM12获取1k字节的写入数据，则向改写对象ECU19发送该1k字节的写入数据，若完成向改写对象ECU19的发送，则从DCM12获取下一1k字节的写入数据。CGW13重复这些处理直到写入全部完成为止。

CGW13若在ECU(ID1)中正常地完成写入数据的写入，则指定ECU(ID2)作为写入数据的传输对象，指定地址“4000”和数据大小“1k字节”，从DCM12获取包含存储于地址“4000”～“4999”的ECU(ID2)的写入数据的分割文件。CGW13若从DCM12获取分割文件，则向ECU(ID2)分发在该分割文件中包含的写入数据。

CGW13若在ECU(ID2)中正常地完成写入数据的写入，则指定ECU(ID3)作为写入数据的传输对象，指定地址“7000”和数据大小“1k字节”，从DCM12获取包含存储于地址“7000”～“7999”的ECU(ID2)的写入数据的分割文件。CGW13若从DCM12获取分割文件，则向ECU(ID2)分发在该分割文件中包含的写入数据。

像以上说明的那样，CGW13通过进行文件的传输控制处理，而根据改写规格数据的解析结果来确定传输对象文件，确定与该传输对象文件对应的地址和数据大小。CGW13向DCM12指定该地址和数据大小，对DCM12请求对传输对象文件进行了分割的分割文件的传输，从DCM12获取分割文件。由此，在利用DCM12的存储器保存容量较大的写入数据的状态下，能够向ECU19分发写入数据。即，在CGW13中不需要准备用于存储容量较大的文件的存储器，能够削减CGW13的存储器容量。

这里，对从DCM12向CGW13传输的分割文件的数据量与从CGW13向改写对象ECU19分发的写入文件的数据量的关进行说明。在上述的例示中，如图128所示，对从DCM12向CGW13传输的分割文件的数据量为1k字节的情况进行了说明，然而从DCM12向CGW13传输的分割文件的数据量与从CGW13向改写对象ECU19分发的写入文件的数据量的关系也可以是任意的。

即，例如如果由于CAN通信方面的理由，改写对象ECU19采用以4k字节接收写入数据的规格，则CGW13按照4k字节单位向改写对象ECU19分发写入文件的数据量。在该情况下，如果从DCM12向CGW13传输的分割文件的数据量为1k字节，则CGW13在从DCM12获取四个分割文件之后，向改写对象ECU19分发4k字节。即，从DCM12向CGW13传输的分割文件的数据量比从CGW13向改写对象ECU19分发的写入文件的数据量小。在这样的关系下，在CGW13中，能够抑制存储器容量的增大，并且并行地从DCM12获取分割文件、向改写对象ECU19分发写入数据。

即，若从DCM12向CGW13传输的分割文件的数据量为4k字节，则要想并行地从DCM12获取分割文件、向改写对象ECU19分发写入数据，需要使CGW13的存储器容量为8k字节。通过使从DCM12向CGW13传输的分割文件的数据量为1k字节，不用使CGW13的存储器容量为8k字节，就能够并行地从DCM12获取分割文件、向改写对象ECU19分发写入数据。例如预先确保CGW13的存储器容量为5k字节，CGW13向改写对象ECU19分发从DCM12完成获取的4k字节，并且从DCM12获取下一1k字节。而且，CGW13在完成了向改写对象ECU19分发4k字节之后，从DCM12进一步获取下一1k字节。

另一方面，例如如果由于CAN通信方面的理由，改写对象ECU19采用以128字节接收写入数据的规格，则CGW13以128字节向改写对象ECU19分发写入数据。在该情况下，如果从DCM12向CGW13传输的分割文件的数据量为1k字节，则CGW13在从DCM12获取一个分割文件之后，向改写对象ECU19按照128字节进行分发。即，从DCM12向CGW13传输的分割文件的数据量比从CGW13向改写对象ECU19分发的写入文件的数据量大。例如预先确保CGW13的存储器容量为2k字节，CGW13按照128字节单位向改写对象ECU19分发从DCM12完成获取的1k字节，并且从DCM12获取下一1k字节。而且，CGW13在完成了向改写对象ECU19分发128字节×8次之后，从DCM12进一步获取下一1k字节。

这样，只要使从DCM12向CGW13传输的分割文件的数据量为固定值(例如1k字节)，根据改写对象ECU19的规格使从CGW13向改写对象ECU19分发的写入文件的数据量为可变值即可。CGW13例如也可以使用由改写规格数据指定的各ECU的数据传输大小，决定向改写对象ECU19分发的数据量。

CGW13向DCM12发送传输请求，向DCM12请求分割文件的传输，但作为向DCM12请求分割文件的传输的形式，存在第一请求形式和第二请求形式。改写对象ECU19若完成写入数据的接收，则向CGW13发送表示完成了写入数据的接收的接收完成通知，若完成写入数据的写入，则向CGW13发送表示完成了写入数据的写入的写入完成通知。

使用图129对第一分发形式进行说明。CGW13若从DCM12获取分割文件，则将该获取的分割文件作为写入数据而向改写对象ECU19分发。改写对象ECU19若完成写入数据的接收，则向CGW13发送接收完成通知，开始写入数据的写入处理。CGW13若从改写对象ECU19接收写入数据的接收完成通知，则向DCM12发送传输请求，向DCM12请求下一分割文件的传输。CGW13若从DCM12获取下一分割文件，则将该获取的下一分割文件作为写入数据而向改写对象ECU19分发。

这样，CGW13在第一分发形式中，不用等待改写对象ECU19的写入数据的写入完成，而从DCM12获取下一写入数据，向改写对象ECU19分发。因此，在第一分发形式中，在CGW13中，若改写对象ECU19未完成写入数据的写入，则即使从DCM12获取下一分割文件而向改写对象ECU19分发下一写入数据，改写对象ECU19也有可能不能接收下一写入数据。然而，如果改写对象ECU19完成写入数据的写入，则能够从DCM12迅速地获取下一分割文件而迅速地向改写对象ECU19分发下一写入数据。

使用图130对第二分发形式进行说明。CGW13若从DCM12获取分割文件，则将该获取的分割文件作为写入数据而向改写对象ECU19分发。改写对象ECU19若完成写入数据的接收，则向CGW13发送接收完成通知，开始写入数据的写入处理。改写对象ECU19若完成写入，则向CGW13发送写入完成通知。CGW13若从改写对象ECU19接收写入完成通知，则向DCM12发送传输请求，向DCM12请求下一分割文件的传输。CGW13若从DCM12获取下一分割文件，则将该获取的下一分割文件作为写入数据而向改写对象ECU19分发。

这样，在第二分发形式中，CGW13在等待改写对象ECU19的写入数据的写入完成之后，从DCM12获取下一写入数据，向改写对象ECU19分发。因此，在第二分发形式中，在CGW13中，直到从DCM12获取下一分割文件为止需要时间，然而能够在改写对象ECU19完成了写入数据的写入的状态下向DCM12请求分割文件的传输。因此，若从DCM12获取下一分割文件而向改写对象ECU19分发下一写入数据，则能够向改写对象ECU19可靠地分发下一写入数据。

另外，CGW13通过SID34、36、37向改写对象ECU19分发写入数据，然而作为向改写对象ECU19分发写入数据的形式，存在第一分发形式和第二分发形式。在第一分发形式中，如图131所示，CGW13按照规定的数据量(例如1k字节)对应该分发的写入数据进行分割而分发。在第二分发形式中，如图132所示，CGW13不对应该分发的写入数据进行分割而统一地分发。CGW13通过最初向改写对象ECU19分发的SID34，选择第一分发形式或者第二分发形式中的任一方。如图133所示，CGW13通过接收针对最后向改写对象ECU19分发的SID37的ACK(SID74)，而确定改写对象ECU19的写入数据的接收。针对该SID37的ACK在图129和图130中相当于上述的写入数据的接收完成通知。即，在第一分发形式中，CGW13若接收针对最后向改写对象ECU19分发SID37的ACK，则通过使下一写入数据的地址自加1，而与向改写对象ECU19分发下一写入数据同时地进一步从DCM12获取下一写入数据。

另外，在DCM用的改写规格数据中将地址与文件建立对应，然而作为将地址与文件建立对应的方法，例如也可以设计文件夹结构，在文件夹1储存规格数据，在文件夹2储存文件1，在文件夹3储存文件2来进行管理，也可以按照文件名的顺序进行管理。在例如图46所示的解包中，在文件夹1储存DCM用的改写规格数据和CGW用的改写规格数据，在文件夹2储存ECU(ID1)的认证符和差分数据，在文件夹3储存ECU(ID2)的认证符和差分数据来进行管理。

另外，CGW13例如在由于通信隔断等某种理由而中断了向改写对象ECU19分发写入数据的情况下，从改写对象ECU19获取能够确定完成了写入数据的写入的地址的信息，向DCM12请求传输包含从未完成该写入的时刻起的写入数据的分割文件。或者，CGW13也可以向DCM12请求包含来自起始的写入数据的分割文件的传输。

像以上说明的那样，CGW13若通过进行文件的传输控制处理，将包含写入到改写对象ECU19的写入数据的文件确定为传输对象文件，确定用于获取传输对象文件的地址和第一数据大小，向DCM12请求分割文件的传输，从DCM12传输分割文件，则向改写对ECU分发写入数据。能够高效地进行从DCM12向CGW13的写入数据的传输、从CGW13向改写对象ECU19的写入数据的分发。

(11)写入数据的分发控制处理

参照图134至图144对写入数据的分发控制处理进行说明。车辆用程序改写系统1在CGW13中进行写入数据的分发控制处理。CGW13经由车辆内的总线而向ECU19发送写入数据，因此进行写入数据的分发控制处理，以使分发写入数据的过程中的总线负荷不会变得过高。

如图134所示，假定+B电源系统ECU、ACC系统ECU、IG系统ECU与同一总线连接的情况。在该情况下，在+B电源状态下，仅+B电源系统ECU启动，ACC系统ECU和IG系统ECU停止，因此向该总线传送仅+B电源系统ECU的车辆控制数据。在处于ACC电源状态时，+B电源系统ECU和ACC系统ECU启动，IG系统ECU停止，因此向该总线传送+B电源系统ECU和ACC系统ECU的车辆控制数据。在处于IG电源状态时，+B电源系统ECU、ACC系统ECU和IG系统ECU启动，因此向该总线传送+B电源系统ECU、ACC系统ECU和IG系统ECU的车辆控制数据。即，车辆控制数据的传送量按照较多的顺序为IG电源状态、ACC电源状态、+B电源状态。

如图135所示，CGW13在写入数据的分发控制部83中，具有第一对应关系确定部83a、第二对应关系确定部83b、传送允许量确定部83c、分发频度确定部83d、总线负荷测量部83e和分发控制部83f。

第一对应关系确定部83a根据改写规格数据的解析结果来确定表示电源状态与总线的传送允许量的关系的第一对应关系，确定图136所示的总线负荷表。传送允许量是指在未产生数据的冲突、延迟的状况下能够发送接收数据的传送负荷的值。总线负荷表是表示电源状态与总线的传送允许量的对应关系的表，按照每个总线来规定。传送允许量是相对于最大传送允许量能够传送的车辆控制数据与写入数据的传送量的合计。

在图136的例示中，第一总线的传送允许量相对于最大传送允许量为“80％”，因此CGW13在IG电源状态下，允许车辆控制数据的传送允许量相对于最大传送允许量为“50％”，允许写入数据的传送允许量相对于最大传送允许量为“30％”。另外，对于第一总线，CGW13在ACC电源状态下，允许车辆控制数据的传送允许量相对于最大传送允许量为“30％”，允许写入数据的传送允许量相对于最大传送允许量为“50％”。另外，对于第一总线，CGW13在+B电源状态下，允许车辆控制数据的传送允许量相对于最大传送允许量为“20％”，允许写入数据的传送允许量相对于最大传送允许量为“60％”。如图136所示，第二总线和第三总线也被同样地规定。

第二对应关系确定部83b根据改写规格数据的解析结果来确定表示改写对象ECU19所属的总线与电源系统的关系的第二对应关系，确定图137所示的改写对象ECU所属表。改写对象ECU所属表是表示改写对象ECU19所属的总线和电源系统的表。

在图137的例示中，CGW13对于第一改写对象ECU19，将其与第一总线连接，在+B电源状态、ACC电源状态、IG电源状态下都启动，因此将第一改写对象ECU19确定为+B电源系统ECU。另外，CGW13对于第二改写对象ECU19，将其与第二总线连接，在+B电源状态下停止，但在ACC电源状态、IG电源状态下启动，因此将第二改写对象ECU19确定为ACC系统ECU。另外，CGW13对于第三改写对象ECU19，将其与第三总线连接，在+B电源状态、ACC电源状态下停止，但在IG电源状态下启动，因此将第三改写对象ECU19确定为IG系统ECU。

CGW13使用图44所示的改写规格数据中的“连接总线”和“连接电源”的数据，而确定将改写对象ECU19与哪个总线连接，是哪个电源系统。另外，如果能够确定这些信息，则不一定需要以表的形式保存。

传送允许量确定部83c根据第一对应关系的确定结果和第二对应关系的确定结果来确定改写对象ECU19所属的总线的传送允许量、即与进行程序的更新时的车辆的电源状态对应的传送允许量。若具体地说明，传送允许量确定部83c使用第二对应关系即改写对象ECU所属表，而确定改写对象ECU19所属的总线，使用第一对应关系即总线负荷表，对于该确定的总线，确定每个电源状态的传送允许量。

分发频度确定部83d使用预先决定的电源状态与写入数据的分发频度的对应关系，确定与安装时的电源状态对应的写入数据的分发频度。若具体地说明，分发频度确定部83d使用总线负荷表，确定由传送允许量确定部83c确定的传送允许量中的、为了分发写入数据而分配的传送允许量，确定写入数据的分发频度。分发频度确定部83d例如确定改写对象ECU19所属的总线为第一总线，确定安装时的电源状态为IG电源状态，将传送允许量确定为“80％”，将其中为了分发写入数据而分配的传送允许量确定为“30％”，由此确定写入数据的分发频度。为了分发写入数据而分配的传送允许量相当于传送制约信息。

总线负荷测量部83e对改写对象ECU19所属的总线的总线负荷进行测量。总线负荷测量部83e例如通过对以单位时间接收到的帧数或者比特数进行计数而测量总线负荷。分发控制部83f根据由分发频度确定部83d确定的分发频度来控制写入数据的分发。

接下来，参照图138至图144对CGW13中的写入数据的分发控制部83的作用进行说明。CGW13执行写入数据的分发控制程序，进行写入数据的分发控制处理。

CGW13若从DCM12接收解包完成通知信号，则开始写入数据的分发控制处理。CGW13从DCM12获取CGW用的改写规格数据(S1101)，根据该CGW用的改写规格数据来确定总线负荷表和改写对象ECU所属表(S1102)。CGW13根据改写对象ECU所属表来确定改写对象ECU19所属的总线(S1103)。CGW13根据总线负荷表来确定与该改写对象ECU19所属的总线、即进行更新时的车辆的电源状态对应的传送允许量。而且，CGW13考虑所确定的传送允许量，确定写入数据的分发频度(S1104、相当于分发频度确定步骤)。例如在对于第一改写对象ECU19即ECU(ID1)，在车辆行驶中分发写入数据的情况下，CGW13参照IG电源状态下的第一总线的传送允许量。在图136的例示中，IG电源状态下的第一总线的传送允许量为“80％”，其中在车辆控制数据中允许“50％”的传送，在写入数据中允许“30％”的传送。另外，传送允许量终究是用于表示事例的值，关于数值，设定在按照适用的通信的规格的允许范围内。

由于在CAN的500[kbps]上的规格中为1帧250[μs]左右，因此若在1秒内产生4次中断，则产生四个帧，总线负荷为100％。CGW13通过判定在总线产生的中断，而确定写入数据的分发频度。CGW13开始以单位时间接收到的帧数的测量，开始总线负荷的测量(S1105)，判定该测量出的总线负荷是否超过传送允许量(S1106)，设定分发间隔。分发间隔是指在CGW13中向改写对象ECU19分发写入数据，从改写对象ECU19接收写入完成通知(ACK)，直到将下一写入数据向改写对象ECU19发送为止的时间间隔。

CGW13若判定为该测量出的总线负荷未超过传送允许量(S1106：“否”)，则将写入数据的分发间隔设定为预先设定的最短间隔，如图139所示，开始向改写对象ECU19分发写入数据(S1107、相当于分发控制步骤)。即，CGW13将CAN上的1帧的分发间隔设定为预先设定的最短间隔，开始向改写对象ECU19分发写入数据。另外，CAN上的1帧包含数据量为8字节的写入数据。另外，CAN FD(CAN with Flexible Data-Rate：具有灵活的数据速率的CAN)上的1帧包含数据量为64字节的写入数据。

另一方面，CGW13若判定为其测量出的总线负荷超过传送允许量(S1106：“是”)，则对总线负荷不超过传送允许量的间隔进行计算(S1108)，将写入数据的分发间隔设定为该计算出的间隔，如图140所示，开始向改写对象ECU19分发写入数据(S1109、相当于分发控制步骤)。

CGW13例如在IG电源状态下针对第一总线判定总线负荷是否超过传送允许量即“80％”，若判定为总线负荷不超过传送允许量，则设定成写入数据的传送允许量为“30％”的分发间隔T1。即，如图136的总线负荷表所示，CGW13在IG电源状态下使用第一总线中的写入数据的传送允许量即“30％”，来设定分发间隔T1。CGW13设定分发间隔T1，以成为所允许的最大传送量。另外，CGW13也可以将测量对象限定为写入数据的帧而测量总线负荷，判定基于写入数据的总线负荷是否超过写入数据的传送允许量“30％”。CGW13若判定为总线负荷超过传送允许量，则根据该总线负荷超过传送允许量的量，变更为总线负荷不超过传送允许量的分发间隔T2(＞T1)。这样，CGW13在从DCM12获取写入数据之后，直到达到所设定的分发间隔为止待机，而向改写对象ECU19分发写入数据。

CGW13若开始向改写对象ECU19分发写入数据，则判定是否完成了向改写对象ECU19分发写入数据，并且持续地判定该测量出的总线负荷是否超过传送允许量(S1110、S1011)。CGW13若判定为该测量出的总线负荷不超过传送允许量(S1111：“否”)，则将写入数据的分发间隔设定为预先设定的最短间隔，变更向改写对象ECU19分发写入数据的分发间隔(S1112)。另一方面，CGW13若判定为该测量出的总线负荷超过传送允许量(S1111：“是”)，则对总线负荷不超过传送允许量的间隔进行计算(S1113)，将写入数据的分发间隔设定为该计算出的间隔，变更向改写对象ECU19分发写入数据的分发间隔(S1114)。

CGW13若判定为完成了向改写对象ECU19分发写入数据(S1110：“是”)，停止以单位时间接收到的帧数的测量，停止总线负荷的测量(S1115)，结束写入数据的分发控制处理。这里，在改写对象ECU19为多个的情况下，CGW13针对向全部的改写对象ECU19的安装，进行写入数据的分发控制处理。

像以上说明的那样，CGW13通过进行写入数据的分发控制处理，使用预先决定的电源状态与写入数据的分发频度的对应关系，确定向改写对象ECU19分发写入数据的分发频度，根据该分发频度来控制写入数据的分发。能够抑制进行安装时的数据的冲突、延迟等。另外，不用妨碍同一总线中的车辆控制数据的分发，就能够使写入数据的分发共存。

另外，以上，在CGW13中，例示了根据改写规格数据的解析结果来确定总线负荷表的结构，然而也可以是预先保存总线负荷表的结构。另外，在CGW13中，例示了根据改写规格数据的解析结果来确定改写对象ECU所属表的结构，然而也可以采用预先保存改写对象ECU所属表的结构。

也可以在车辆处于行驶中的电源状态下使写入数据的分发量相对地少，在驻车中的电源状态下使写入数据的分发量相对地多。即，如图141所示，在车辆处于行驶中的IG电源接通时，CGW13通过IG系统ECU、ACC系统ECU、+B电源系统ECU发送CAN帧，而使车辆控制、诊断等应用数据的传送量相对地多，因此使写入数据的分发量相对地少。另外，如图142所示，在驻车中的IG电源断开时，CGW13仅通过+B电源系统ECU发送CAN帧，而使车辆控制、诊断等应用数据的传送量相对地少，使写入数据的分发量相对地多。即，CGW13在不妨碍车辆控制、诊断等应用数据的传送的空闲容量内调整写入数据的分发量。

另外，也可以如图143所示，在CGW13中，在从改写对象ECU19发送事件帧的情况下，通过接收事件帧而使中断的频度变高，总线负荷变高，因此使写入数据的分发量相对地少，在未从改写对象ECU19发送事件帧的情况下，使写入数据的分发量相对地多。

另外，也可以如图144所示，在车辆系统中，在确定了CGW13处于写入数据的分发中的情况下，通过使车辆控制、诊断等应用数据的发送间隔延长到所允许的最大间隔，而降低总线负荷。在CGW13中，也可以通过由车辆系统延长应用数据的发送间隔而降低总线负荷，由此使写入数据的分发量相对地多。

嵌入到改写规格数据中的总线负荷表例如被一律地共用设定，而与车辆制造商的车型、等级等无关。这是因为，若ECU的装备根据例如车型、等级等而大幅不同，则总线负荷大幅不同，若根据车型、等级等独立地设定最佳的总线负荷表，则在其验证中需要工时等需要繁琐的麻烦，因此避免这样的繁琐的麻烦。

与像上述那样车辆在行驶中进行安装的情况同样，在车辆在驻车中进行安装的情况下，也进行写入数据的分发控制处理。在该情况下，如果改写对象ECU19为+B电源系统ECU，则也可以在+B电源状态下进行更新，因此参照总线负荷表中的+B电源状态的传送允许量。另一方面，在改写对象ECU19为IG系统ECU的情况下，在IG电源状态下进行安装，因此参照总线负荷表中的IG电源状态的传送允许量。这里，例如在改写对象ECU19为ACC系统ECU的情况下，也可以在IG电源状态下进行安装。在该情况下，参照总线负荷表中的IG电源状态的传送允许量。另外，对保持总线负荷表和改写对象ECU所属表的结构进行了说明，但只要能够确定每个电源状态的写入数据的分发频度，则也可以是保持任意的表的形式。

(12)激活请求的指示处理

参照图145至图146对激活请求的指示处理进行说明。车辆用程序改写系统1在CGW13中进行激活请求的指示处理。CGW13针对完成了应用程序的改写的多个改写对象ECU19，进行激活请求以使该改写后的程序有效。在本实施方式中，CGW13通过对CGW用的改写规格数据进行解析，而成为掌握改写对象ECU19的组的状态。另外，CGW13仅在驻车中进行激活请求，在车辆行驶中不进行激活请求。

如图145所示，CGW13在激活请求的指示部84中，具有改写对象确定部84a、改写完成判定部84b、激活可执行判定部84c、以及激活请求指示部84d。改写对象确定部84a将协作控制的多个改写对象ECU19作为对象，确定多个改写对象ECU19。若通过改写对象确定部84a确定多个改写对象ECU19，则改写完成判定部84b判定在该确定的多个改写对象ECU19的全部中是否完成了程序的改写。

若由改写完成判定部84b判定为在多个改写对象ECU19的全部中完成了程序的改写，则激活可执行判定部84c判定是否能够执行激活。在得到用户的激活同意的情况下、并且在车辆处于驻车状态的情况下，激活可执行判定部84c判定为能够执行激活。

若由激活可执行判定部84c判定为能够执行激活，则激活请求指示部84d指示激活请求。具体而言，激活请求指示部84d在对新面指示了切换请求之后，指示复位请求，监视会话转移超时、或者监视改写对象ECU19的内部复位，由此指示激活请求。在2面存储器ECU或者1面挂起存储器ECU中，通过在写入了应用程序的新面(非运用面)启动，而激活应用程序。另一方面，在1面独立存储器ECU中，通过重新启动来激活应用程序。另外，改写对象ECU19也可以构成为在对新面指示了切换请求之后，不取决于激活请求，而由自身进行复位。

接下来，参照图146和图147对CGW13中的激活请求的指示部的作用进行说明。CGW13执行激活请求的指示程序，进行激活请求的指示处理。

CGW13若开始激活请求的指示处理，则确定多个改写对象ECU19(S1201、相当于改写对象确定步骤)。具体而言，CGW13通过参照在改写规格数据中记载的ECU(ID)，而确定改写对象ECU19。CGW13判定在该确定的多个改写对象ECU19的全部中是否完成了应用程序的改写(S1202、相当于改写完成判定步骤)。CGW13例如按照在改写规格数据中记载的ECU(ID)的顺序，而依次进行针对改写对象ECU19的安装，若针对最后记载的ECU(ID)的安装完成则判定为在全部的改写对象ECU19中完成了写入。

CGW13若判定为在该确定的多个改写对象ECU19的全部中完成了应用程序的改写(S1202：“是”)，则判定是否能够执行激活(S1203、相当于激活可执行判定步骤)。具体而言，CGW13判定在此之前是否得到了针对更新的用户同意、车辆是否处于驻车状态等，若满足这些条件，则判定为能够执行激活。用户同意也可以是针对更新处理整体的同意，也可以是针对激活的同意。CGW13若判定为能够执行激活(S1203：“是”)，则此后，同时向多个改写对象ECU19指示激活请求(相当于激活请求指示步骤)。这里，假设ECU(ID1)、ECU(ID2)和ECU(ID3)是同一组的改写对象ECU19而进行说明。

CGW13若判定为针对ECU(ID1)、ECU(ID2)和ECU(ID3)，能够执行激活，则开始激活请求的指示处理。CGW13若开始激活请求的指示处理，则向改写对象ECU19指示对新面的切换请求(S1204)。CGW13对电源管理ECU20请求使IG电源从断开切换为接通(S1205)。虽然车辆处于驻车状态，IG开关42处于断开的状态，但CGW13为了进行激活而使IG电源从断开切换为接通。另外，CGW13在安装之后接着进行激活的情况下，由于IG电源处于接通状态，因此不进行S1205，对休眠状态的改写对象ECU19进行启动请求(唤醒请求)。

CGW13向改写对象ECU19发送软件的复位请求，向改写对象ECU19指示软件的复位请求(S1206)。改写对象ECU19如果采用与软件的复位请求对应的规格，则在从CGW13接收软件的复位请求时，将软件复位而重新启动，激活应用程序。在改写对象ECU19为1面独立存储器ECU的情况下，改写对象ECU19通过利用新应用程序进行重新启动，而从旧应用程序切换为新应用程序。在改写对象ECU19为1面挂起存储器ECU或者2面存储器ECU的情况下，改写对象ECU19对存储于闪存的运用面信息(A面或者B面)进行更新，将写入了新应用程序的面切换为运用面，由此从旧应用程序切换为新应用程序。

CGW13对电源管理ECU20请求将IG电源从接通切换为断开、将IG电源从断开切换为接通的内容，向改写对象ECU19指示电源的复位请求，向改写对象ECU19指示重新启动(S1207)。即使采用不与软件的复位请求对应的规格，若将IG电源从接通切换为断开、将IG电源从断开切换为接通，则改写对象ECU19将自身复位而重新启动，激活应用程序。在该情况下也是，在改写对象ECU19为1面独立存储器ECU的情况下，改写对象ECU19通过利用新应用程序进行重新启动，而从旧应用程序切换为新应用程序。在改写对象ECU19为1面挂起存储器ECU或者2面存储器ECU的情况下，改写对象ECU19对存储于闪存的运用面信息(A面或者B面)进行更新，将写入了新应用程序的面切换为运用面，由此从旧应用程序切换为新应用程序。另外，CGW13监视会话转移超时(S1208)，监视改写对象ECU19的内部复位(S1209)。

即，如果改写对象ECU19采用不与软件的复位请求对应的规格，则CGW13即使向改写对象ECU19发送软件的复位请求也无法指示激活，因此通过向改写对象ECU19指示电源的复位请求，而进行不与软件的复位请求对应的规格的改写对象ECU19的激活。例如在发动机ECU等IG系统ECU中，由于是因电源接通断开而一定复位的结构，因此多数情况下是不与软件的复位请求对应的情况。从改写对象ECU19的观点来看，根据从CGW13指示了软件的复位请求、从CGW13指示了电源的复位请求、会话转移超时、内部复位中的任一方，而进行激活(新程序中的启动)。

与软件的复位请求对应的改写对象ECU19若被CGW13指示软件的复位请求，则自身强制地进行复位，进行激活。ACC系统、IG系统ECU的改写对象ECU19若被CGW13指示电源的复位请求，则不强制地供给电源，因此在下次的电源的供给时进行复位，进行激活。+B电源系统ECU的改写对象ECU19与ACC系统、IG系统ECU的改写对象ECU19不同，由于始终被供给电源，因此通过会话转移超时、内部复位而进行激活。另外，针对各改写对象ECU19的激活的方法由改写规格数据指定。

CGW13若被全部的改写对象ECU19通知利用新应用程序正常启动的内容，则向DCM12发送切换完成通知(S1210)。DCM12向中心装置3通知完成了更新程序的激活的内容。CGW13对电源管理ECU20请求使IG电源从接通切换为断开，完成应用程序的激活同步指示处理。若通过用户操作而将IG电源从断开切换为接通，则CGW13向DCM12发送各ECU的程序版本、启动面等。DCM12向中心装置3通知从CGW13接收到的各ECU19的信息。这里，也可以在DCM12向中心装置3通知激活完成时，向中心装置3发送包含各ECU的程序版本和面信息的ECU结构信息。图147表示改写对象ECU19为2面存储器ECU或者1面挂起存储器ECU的情况。

像以上说明的那样，CGW13通过进行激活请求的指示处理，而将完成了应用程序的改写的多个改写对象ECU19在独自的时机进行从旧程序向新程序的切换的情况防患于未然，适当地使在该多个改写对象ECU19中从旧程序向新程序的切换时机一致。即，避免相互协作的多个改写对象ECU19的程序版本成为不整合的状态，在协作的处理中产生不良情况。

(13)激活的执行控制处理

参照图148至图150对激活的执行控制处理进行说明。激活的执行控制处理是伴随着CGW13进行上述的(12)激活请求的指示处理，而被CGW13指示了激活请求的改写对象ECU19进行的处理。车辆用程序改写系统1在改写对象ECU19中进行激活的执行控制处理。这里，改写对象ECU19具有1面挂起方式存储器、2面存储器那样的多个数据储存面。改写对象ECU19具有第一数据储存面和第二数据储存面，成为在非运用面(新面)完成了改写数据的安装的状态。

如图148所示，ECU19在激活的执行控制部107中，具有运用面信息更新部107a、执行条件判定部107b、执行控制部107c、以及通知部107d。运用面信息更新部107a若被CGW13指示激活请求，则面向下次的重新启动，更新闪存的启动面判定信息(运用面信息)。运用面信息更新部107a例如在当前A面启动，在B面写入了新程序的情况下，将运用面信息从A面更新为B面。

作为激活的执行条件，执行条件判定部107b判定是否从CGW13指示了软件的复位请求、是否从CGW13向电源管理ECU20指示了电源的复位请求、与CGW13的通信隔断是否持续了规定时间。在满足任意一个条件的情况下，执行条件判定部107b判定为激活的执行条件成立。也可以不是来自CGW13的指示，而由电源检测电路36检测是否指示了电源的复位请求。若由执行条件判定部107b判定为激活的执行条件成立，则执行控制部107c根据运用面信息而进行将启动面从旧面(当前运用的面)向新面(当前未运用的面)切换的新面切换(激活)。通知部107d向CGW13通知运用面信息、版本信息等通知信息。

接下来，参照图149和图150对改写对象ECU19的激活的执行控制部107的作用进行说明。改写对象ECU19执行激活的执行控制程序，进行激活的执行控制处理。

(13-1)改写处理

改写对象ECU19若开始改写处理，则作为改写前处理，进行产品号读出、认证等存储器消除之前的处理(S1301)。改写对象ECU19判定是否从中心装置3接收到改写面信息(S1302)。改写对象ECU19例如根据是否从CGW13获取在包含于分发包的改写规格数据中记载的改写面信息，而判定是否接收到改写面信息。改写对象ECU19若判定为从中心装置3接收到改写面信息(S1302：“是”)，则对该改写面信息与自身管理的改写面信息(运用面信息)进行对照，判定两者是否一致(S1303)。这里，改写面信息例如记载于从中心装置3发送的改写规格数据。例如在自身管理的改写面信息是运用面为A面且非运用面为B面的情况下，在记载于改写规格数据的改写面信息表示非运用面(B面)的情况下判定为两者一致，在记载于规格数据的改写面信息表示运用面(A面)的情况下，判定为两者不一致。

改写对象ECU19若判定为两者一致(S1303：“是”)，则作为改写处理，进行存储器消除、写入数据的写入、检验(S1304)，结束改写处理。检验例如是写入到闪存的数据的完整性验证。改写对象ECU19若判定为两者不一致(S1303：“否”)，则向CGW13发送否定响应(S1305)，结束改写处理。

(13-2)激活的执行控制处理

改写对象ECU19若开始激活的执行控制处理，则将非运用面作为改写面，判定是否完成了向改写面改写应用程序(S1311)。改写对象ECU19若判定为完成了向改写面改写应用程序(S1311：“是”)，则对写入到闪存的应用程序的完整性进行验证，判定改写后的数据验证的正确与否(S1312)。改写对象ECU19若判定为改写后的数据验证为正(S1312：“是”)，则将新面的改写完成标志设定为“OK”并存储(S1313)。

然后，改写对象ECU19判定是否从CGW13指示了激活请求(S1314)。改写对象ECU19若判定为指示了激活请求(S1314：“是”)，则判定新面的改写完成标志是否为“OK”(S1315)，若判定为新面的改写完成标志为“OK”(S1315：“是”)，则更新运用面信息(S1316、相当于运用面信息更新步骤)。即，例如在运用面为A面且非运用面为B面的情况下将B面作为改写面而完成了向改写面改写应用程序的情况下，改写对象ECU19将表示运用面为A面且非运用面为B面的运用面信息更新为表示运用面为B面且非运用面为A面的运用面信息。

改写对象ECU19若更新为运用面信息，则判定是否从CGW13受理了软件的复位请求，是否从CGW13向电源管理ECU20指示了电源的复位请求、判定是否在指示了软件的复位请求之后与CGW13的通信隔断持续了规定时间，判定激活的执行条件是否成立(S1317、相当于执行条件判定步骤)。这里，若这些激活的执行条件中的任一方成立则改写对象ECU19重新启动、或由ECU分别设定重新启动条件。

改写对象ECU19若判定出从CGW13指示了软件的复位请求、从CGW13向电源管理ECU20指示电源的复位请求、在指示软件的复位请求之后经过了规定时间中的任一方，判定为激活的执行条件成立(S1317：“是”)，则执行重新启动(复位)。改写对象ECU19通过执行重新启动，而根据更新后的运用面信息，将新面(B面)作为启动面而启动(S1318、相当于启动控制步骤)，结束激活的执行控制处理。即，改写对象ECU19在重新启动后，在安装了应用程序的B面启动。

改写对象ECU19若判定为未完成向新面改写应用程序(S1311：“否”)、或者判定为改写后的数据验证为否(S1312：“否”)，则判定是否指示了激活请求(S1319)，若判定为指示了激活请求(S1319：“是”)，则向CGW13发送否定响应(S1320)，返回步骤S1311。另外，改写对象ECU19也可以在判定为改写后的数据验证为否的情况下，结束激活的执行控制处理，进行回滚等处理。另外，改写对象ECU19若判定为新面的改写完成标志不是“OK”(S1315：“否”)，则向CGW13发送否定响应(S1321)，返回步骤S1311。

像以上说明的那样，改写对象ECU19通过进行激活的执行控制处理，若被CGW13指示激活请求，则面向下次的重新启动，更新运用面信息，若激活的执行条件成立，则在重新启动后，根据运用面信息而进行将启动面从旧面切换为新面的新面切换。即，即使更新程序的安装完成，只要不从CGW13指示激活，改写对象ECU19也不会通过更新程序启动。例如，即使伴随着用户将IG开关42从断开操作到接通，改写对象ECU19重新启动，如果没有从CGW13指示激活，则在相同的运用面启动。CGW13向多个改写对象ECU19同时指示激活，然后，通过软件复位、电源复位或者会话超时来执行重新启动，由此能够使多个改写对象ECU19的更新程序同时有效化。另外，在上述的说明中，说明了数据储存面为2面的情况，但关于数据储存面为3面以上的情况也同样。

另外，在上述的(12)CGW13的激活请求的指示处理中，CGW13对完成了应用程序的改写的多个改写对象ECU19进行激活请求的指示处理，由此将完成了应用程序的改写的多个改写对象ECU19在独自的时机进行从旧程序向新程序的切换的情况防患于未然，能够适当地使在该多个改写对象ECU19中从旧程序向新程序的切换时机一致。

(14)改写对象的组管理处理

参照图151至图154对改写对象的组管理处理进行说明。车辆用程序改写系统1在CGW13中进行改写对象的组管理处理。CGW13对属于同一组的一个以上的改写对象ECU19同时指示应用程序的激活。另外，CGW13按照组单位进行从安装到激活为止的控制。这里，假设ECU(ID1)和ECU(ID2)为第一组的改写对象ECU19，ECU(ID11)、ECU(ID12)和ECU(ID13)为第二组的改写对象ECU19而进行说明。

如图151所示，CGW13在改写对象的组管理部85中，具有组生成部85a、指示执行部85b。组生成部85a根据CGW用的改写规格数据的解析结果，对应该同时进行版本升级的改写对象ECU19进行分组而生成组。若通过组生成部85a生成组，则指示执行部85b以该组为单位按照规定的顺序进行安装的指示，若安装完成，则以该组为单位进行激活的指示。

接下来，参照图152至图154对CGW13的改写对象的组管理部85的作用进行说明。CGW13执行改写对象的分组程序，进行改写对象的组管理处理。CGW13若开始改写对象的组管理处理，则从DCM12获取CGW用的改写规格数据(S1401、相当于改写规格数据获取步骤)，对该获取的改写规格数据进行解析(S1402、相当于改写规格数据解析步骤)，判定本次的改写对象ECU19的所属组。CGW13例如也可以参照与改写规格数据的ECU相关的信息，确定所属于哪个组，也可以参照与改写规格数据的组相关的信息，确定哪个ECU所属于该组。CGW13针对一个组，判定是否为最初的改写对象ECU19的改写(S1403)，判定是否是属于与前次的改写对象ECU19相同的组的改写对象ECU19的改写(S1404)，判定是否是属于与前次的改写对象ECU19不同的组的改写对象ECU19的改写(S1405、相当于组生成步骤)。

CGW13若判定为是最初的改写对象ECU19的改写(S1403：“是”)、或者判定为是属于与前次的改写对象ECU19相同的组的改写对象ECU19的改写(S1404：“是”)，则向改写对象ECU19指示应用程序的改写，进行改写对象ECU19的应用程序的改写(S1406)。而且，CGW13判定是否存在下一改写对象ECU19(S1407)。CGW13若判定为存在同一组内的下一改写对象ECU19(S1407：“是”)，则返回上述的步骤S1403～S1405，重复S1403～S1405。

CGW13若判定为是属于与前次的改写对象ECU19不同的组的改写对象ECU19的改写(S1405：“是”)，则转移至激活请求的指示处理(S1408、相当于指示执行步骤)。

CGW13若开始激活请求的指示处理，则判定是否存在下一改写对象ECU19(S1411)。即，CGW13判定是否存在未完成安装的组。CGW13若判定为存在下一改写对象ECU19(S1411：“是”)，则向属于完成了改写的组的改写对象ECU19指示激活请求(S1412)。即，在未对属于第二组的改写对象ECU19进行安装的情况下，CGW13对已经完成了改写的第一组的改写对象ECU(ID1)和ECU(ID2)指示激活。

CGW13向改写对象ECU19指示软件的复位请求，向改写对象ECU19指示基于经由电源管理ECU20将电源从接通切换为断开、从断开切换为接通的重新启动，而使改写对象ECU(ID1)和ECU(ID2)的应用程序同时启动。

CGW13判定下一改写对象ECU19的改写时机(S1413、S1314)。即，CGW13判定属于第二组的改写对象ECU19的改写时机。CGW13若判定为下一改写对象ECU19的改写时机是从下次的用户乘车到下车的切换时(S1413：“是”)，则将IG电源从接通切换为断开(S1415)，结束激活请求的指示处理，返回改写对象的组管理处理。例如由用户预先设定允许应用程序的更新的执行的时间段，CGW13在预测为在该时间段朝向属于第二组的改写对象ECU19的安装未完成时，在下次的驻车状态进行安装。在该情况下，应返回原来的驻车状态，CGW13指示电源管理ECU20将IG电源断开。

CGW13若判定为下一改写对象ECU19的改写时机为本次的下车中(驻车状态)(S1414：“是”)，则判定车辆电池40的电池余量是否为阈值以上(S1417)。这里，阈值也可以是预先设定的值，也可以是从CGW用的改写规格数据中获取的值。CGW13若判定为车辆电池40的电池余量不是阈值以上(S1416：“否”)，则向电源管理ECU20指示将IG电源从接通切换为断开(S1415)，结束激活请求的指示处理，返回改写对象的组管理处理。CGW13若判定为车辆电池40的电池余量为阈值以上(S1416：“是”)，则持续IG电源的接通(S1417)，结束激活请求的指示处理，返回改写对象的组管理处理。CGW13像图152所示那样，进行属于第二组的改写对象ECU19的应用程序改写。

CGW13若判定为不存在下一改写对象ECU19(S1411：“否”)，则向属于完成了改写的组的改写对象ECU19指示激活请求(S1418)，将IG电源从接通切换为断开(S1419)，结束激活请求的指示处理，返回改写对象的组管理处理。例如若完成属于第二组的改写对象ECU(ID11)、ECU(ID12)和ECU(ID13)的改写，则不存在下一改写对象ECU19、即下一组。在该情况下，CGW13对ECU(ID11)、ECU(ID12)和ECU(ID12)指示更新程序的激活，在激活完成后，向电源管理ECU20指示IG电源断开。

如图154所示，在改写ECU(ID1)至ECU(ID2)以及ECU(ID11)至ECU(ID13)的应用程序的情况下，如果ECU(ID1)、ECU(ID2)处于协作控制的关系，ECU(ID11)、ECU(ID12)、ECU(ID13)处于协作控制的关系，则在分发包中，作为第一组，ECU(ID1)和ECU(ID2)属于改写对象ECU19，作为第二组，ECU(ID11)、ECU(ID12)和ECU(ID13)属于改写对象ECU19。CGW13若在属于第一组的ECU(ID1)、ECU(ID2)中完成应用程序的改写，则对ECU(ID1)，ECU(ID2)同时指示激活请求。然后，CGW13若在属于第二组的ECU(ID11)、ECU(ID12)和ECU(ID13)中执行应用程序的改写，全部完成，则对ECU(ID11)、ECU(ID12)、ECU(ID13)指示激活请求。另外，通过对1面独立存储器即改写对象ECU19指示重新启动，而成为激活指示。

像以上说明的那样，CGW13通过进行激活请求的改写对象ECU19的组管理处理，而以该组为单位指示激活请求。能够同时进行处于协作控制的关系的多个ECU的版本升级。即，能够避免处于协作控制的关系的多个改写对象ECU19的应用程序的版本成为不整合的状态而在协作控制的处理中产生不良情况。另外，CGW13以该组为单位，按照规定的顺序进行安装。即，CGW13控制为，按照组单位进行从安装到激活。

另外，在本实施方式中，构成为在完成了属于第一组的改写对象ECU19的安装之后，进行属于第一组的改写对象ECU19的激活，接着在完成了属于第二组的改写对象ECU19的安装之后，进行属于第二组的改写对象ECU19的激活。然而，也可以持续进行针对属于第一组的改写对象ECU19的激活和针对属于第二组的改写对象ECU19的激活。即，也可以完成属于第一组的改写对象ECU19的安装，完成属于第二组的改写对象ECU19的安装，然后进行属于第一组的改写对象ECU19的激活，进行属于第二组的改写对象ECU19的激活。在该情况下，也可以同时进行针对属于第一组和第二组的改写对象ECU19的激活。

另外，在改写对象ECU19中包含1面独立存储器ECU的情况下，也可以将对该一面独立存储器ECU的安装的指示作为组内的最后。在向处于协作动作的关系的改写对象ECU19指示安装的情况下，也可以先对作为数据的发送侧进行动作的改写对象ECU19指示安装，然后对作为数据的接收侧进行动作的改写对象ECU指示安装。

CGW13参照改写规格数据的存储器种类，根据改写对象ECU19的存储器种类而决定安装顺序。例如为2面存储器、1面挂起存储器、1面独立存储器的顺序。另外，作为处于协作动作的关系的ECU19的信息，CGW13预先保存数据发送侧和数据接收侧中的任一方，基于该信息而决定改写对象ECU19的安装顺序。

另外，在存在多个组的情况下，安装的顺序例如也可以基于紧急度、安全度、功能、时间等来决定。紧急度是指是否需要立即安装的指标，在若放置而不安装则导致人灾、事故等的可能性比较高的情况下紧急度较高，在即使放置而不安装，与人灾、事故等相关连的可能性也比较低的情况下紧急度较低，优先安装紧急度高的组。安全度是指基于安装时的微机的种类的制约的指标，按照制约少的顺序、即2面存储器、1面挂起存储器、1面独立存储器的顺序进行安装。功能是指对于用户来说的便利性的指标，优先安装对于用户来说的便利性较高的组。时间是指安装所需要的时间的指标，优先对安装所需要的时间较短的组进行安装。

另外，CGW13在向属于同一组的第一改写对象ECU19和第二改写对象ECU19指示安装的情况下，在第一改写对象ECU19中安装成功、在第二改写对象ECU19中安装失败的情况下，向第二改写对象ECU19指示回滚，向第一改写对象ECU19指示回滚。

另外，CGW13在向属于第一组的改写对象ECU19和属于第二组的改写对象ECU19指示安装的情况下，在属于第一组的改写对象ECU19中安装失败的情况下，向属于第二组的改写对象ECU19指示安装。CGW13例如在图152中，在属于第一组的改写对象ECU19中安装失败的状态下成为第二组的改写的情况下(S1405；“是”)，跳过针对第一组的激活请求的指示处理(S1408)，进入步骤S1407。而且，CGW13返回步骤S1403，开始第二组的安装，在完成了安装的情况下，对第二组进行激活请求的指示处理(S1408)。即，即使针对第一组的更新失败，CGW13也执行针对第二组的更新。

另外，在一个活动(一个分发包内)存在2组的情况下，将针对活动的用户的同意操作和针对下载的用户的同意操作设为一次，使每个组进行二次针对安装的用户的同意操作和针对激活的用户的同意操作。即，在通过更新而变更的功能按照每个组而不同的情况下，优选按照每个该功能进行针对安装的用户的同意操作和针对激活的用户的同意操作。另外，还设想用户对于按照每个组进行针对安装的用户的同意操作和针对激活的用户的同意操作感到繁琐，因此也可以将针对安装的用户的同意操作和针对激活的用户的同意操作在组整体中设为一次。

例示了利用改写规格数据来判定改写对象ECU19的所属组的结构，但也可以是在CGW13中预先存储改写对象ECU19的所属组的结构。

(15)回滚的执行控制处理

参照图155至图166对回滚的执行控制处理进行说明。车辆用程序改写系统1在CGW13中进行回滚的执行控制处理。回滚是指在中断应用程序的改写的情况下，用于将应用程序返回到原来的版本等、使改写对象ECU19的存储器复原到规定状态的写入或者回写，从用户来看，将改写对象ECU19的状态返回到开始写入数据的写入之前的状态。

如图155所示，CGW13在回滚的执行控制部86中，具有取消请求判定部86a、回滚方法确定部86b、回滚执行部86c。取消请求判定部86a判定在应用程序的改写中是否产生了改写的取消请求。例如若用户操作便携终端6，选择程序改写的取消，则从获取了该取消的信息的中心装置3经由DCM12而向CGW13通知程序的改写的取消请求。

另外，在系统产生了异常的情况下，若向中心装置3通知系统的异常，则从中心装置3经由DCM12而向CGW13通知程序的改写的取消请求。系统的异常是指例如向一个改写对象ECU19的写入成功，但向与该一个改写对象ECU19进行协作控制的其他的改写对象ECU19的写入失败的情况等。若像这样协作控制的多个改写对象ECU19中的一个写入失败，则判定为系统的异常，针对写入成功的改写对象ECU19，从中心装置3经由DCM12向CGW13通知程序的改写的取消请求。即，在产生取消请求的因素中包含基于用户的操作和系统的异常产生。

回滚方法确定部86b根据搭载于改写对象ECU19的闪存的存储器种类、新程序或者旧程序的写入数据的数据种类，确定用于将改写对象ECU19的状态返回到开始写入数据的写入之前的状态的回滚方法。即，作为改写对象ECU19的存储器种类，回滚方法确定部86b确定闪存是1面独立存储器、1面挂起存储器或者2面存储器中的哪个，作为写入数据的数据种类，回滚方法确定部86b确定写入数据是全部数据或者差分数据中的哪个。

而且，回滚方法确定部86b根据这些存储器种类和数据种类，确定第一回滚处理、第二回滚处理或者第三回滚处理。若通过回滚方法确定部86b确定回滚方法，则回滚执行部86c向改写对象ECU19指示与该回滚方法对应的回滚，使改写对象ECU19以旧程序进行动作。即，回滚执行部86c进行使改写对象ECU19的动作状态复原到开始该应用程序的改写之前的状态的回滚。

接下来，参照图156至图166对CGW13中的回滚执行控制部86的作用进行说明。CGW13执行回滚执行控制程序，进行回滚执行控制处理。作为回滚的执行控制处理，CGW13进行回滚方法的确定处理、取消请求的判定处理。以下，对各个处理进行说明。

(15-1)回滚方法的确定处理

CGW13若开始回滚方法的确定处理，则对从DCM12获取的CGW用的改写规格数据进行解析(S1501)，根据该解析结果来确定回滚方法(S1502)，结束回滚方法的确定处理。CGW13从图44所示的改写规格数据中获取存储器种类和回滚程序的数据种类，确定回滚方法。如果是不论数据种类是新程序还是旧程序(回滚程序)都相同的运用，则也可以使用新程序的数据种类来确定回滚方法。

即，如果改写对象ECU19的闪存为1面独立存储器且写入数据为整体数据，则作为产生了取消请求时的回滚方法，CGW13确定如下的方法(第一回滚处理)，立即中断整体数据的分发，在改写对象ECU19中将旧应用程序的数据写入改写区域而改写为旧应用程序。用于1面独立存储器的旧应用程序(回滚用改写数据)与更新程序一同包含于分发包，CGW13利用与新应用程序相同的方法向改写对象ECU19分发旧应用程序。

如果改写对象ECU19的闪存为1面独立存储器且写入数据为差分数据，则作为产生取消请求时的回滚方法，CGW13确定如下的方法(第二回滚处理)，持续该差分数据的分发，在改写对象ECU19中将差分数据写入改写区域而改写为新应用程序之后，分发旧应用程序的差分数据，在改写对象ECU19中将旧数据写入改写区域而改写为旧应用程序。

在写入数据为差分数据的情况下，改写对象ECU19使用写入到闪存的当前应用程序和从CGW13获取的差分数据来复元新应用程序，进行新应用程序的写入。在向闪存写入不同的应用程序的状态下，写入对象ECU19无法根据差分数据复元新应用程序。因此，在1面独立存储器中，需要暂时改写为新应用程序的处理。这里，例如若当前应用程序为版本1.0，新应用程序为版本2.0，则改写程序(改写数据)是用于将版本1.0更新为版本2.0的差分数据，回滚用改写数据是用于将版本2.0更新为版本1.0的差分数据。

如果改写对象ECU19的闪存为1面挂起存储器或者2面存储器，则CGW13确定如下的方法(第三回滚处理)，持续写入数据的分发，如果在改写对象ECU19中运用面为A面，非运用面为B面，则CGW13将写入数据写入非运用面即B面而安装新应用程序，但抑制从A面向B面的运用面的切换。

(15-2)取消请求的判定处理

CGW13若确定为在改写对象ECU19中开始了应用程序的改写，则开始取消请求的判定处理，判定是否完成了应用程序的改写(S1511)，判定是否产生了取消请求(S1512)。即，CGW13像上述那样，判定是否由于用户的操作、系统的异常产生等而产生了取消请求。

CGW13若判定为在完成应用程序的改写之前产生了取消请求、即在安装中产生了取消请求(S1512：“是”)，则确定回滚对象的改写对象ECU19(S1513)。假设属于同一组的改写对象ECU19为ECU(ID1)、ECU(ID2)和ECU(ID3)，ECU(ID1)为1面独立存储器，ECU(ID2)和ECU(ID3)为2面存储器，完成向ECU(ID1)的安装，在向ECU(ID2)的安装中途产生了取消请求。在该情况下，CGW13在S1413中，对属于第一组的改写对象ECU19全部判定是否需要回滚。

CGW13确定为进行了应用程序的全部改写的ECU(ID1)和进行了应用程序的一部分改写的ECU(ID2)为回滚对象。CGW13判定该确定的回滚对象的改写对象ECU19的闪存的存储器种类，判定闪存是1面独立存储器、1面挂起存储器和2面存储器中的哪个(S1514、S1515)。CGW13若判定为闪存为1面独立存储器(S1514：“是”)，则判定回滚程序的数据种类，判定回滚用写入数据是整体数据和差分数据中的哪个(S1516、S1517)。

CGW13若判定为回滚用写入数据是整体数据(S1516：“是”)，则转移至第一回滚处理(S1518、相当于回滚执行步骤)。CGW13若开始第一回滚处理，则立即中断新程序即写入数据的分发(S1531)。而且，CGW13从DCM12获取整体数据即回滚用写入数据(旧程序)，向改写对象ECU19分发。改写对象ECU19将从CGW13获取的旧应用程序的数据写入闪存而改写为旧应用程序(S1532)，结束第一回滚处理，返回取消请求的判定处理。

CGW13若判定为回滚用写入数据是差分数据(S1517：“是”)，则转移至第二回滚处理(S1519、相当于回滚执行步骤)。CGW13若开始第二回滚处理，则持续新程序即写入数据的分发(S1541)，在改写对象ECU19中复元差分数据而写入闪存，改写为新应用程序(S1542)。CGW13在向新应用程序的改写完成后，向改写对象ECU19分发从DCM12获取的旧应用程序的写入数据(S1543)。在改写对象ECU19中复元旧应用程序的写入数据即差分数据，写入闪存而改写为旧应用程序(S1544)，结束第二回滚处理，返回取消请求的判定处理。

CGW13若判定为改写对象ECU19为1面挂起存储器ECU或者2面存储器ECU(S1515：“是”)，则转移至第三回滚处理(S1520、相当于回滚执行步骤)。在该情况下，CGW13不取决于改写数据种类，转移至第三回滚处理。CGW13若开始第三回滚处理，则持续该写入数据的分发(S1551)，在改写对象ECU19中将写入数据写入非运用面(B面)而改写为新应用程序(S1552)。CGW13抑制从旧面(运用面：A面)向新面(非运用面：B面)的运用面的切换(S1553)，结束第三回滚处理，返回取消请求的判定处理。另外，CGW13除了运用面的切换抑制之外，如图126所示，也可以将写入版本2.0的非运用面回写到改写为新应用程序之前的状态(例如版本1.0)。

CGW13若返回取消请求的判定处理，则判定对于全部的回滚对象的改写对象ECU19是否进行了回滚处理(S1521)。例如在上述的改写对象ECU19为ECU(ID1)、ECU(ID2)和ECU(ID3)的情况下的例示中，首先，CGW13根据回滚用数据种类，对于安装中途的1面独立存储器的ECU(ID1)，进行第一回滚处理或者第二回滚处理。然后，CGW13对于完成了安装的2面存储器的ECU(ID2)，进行第三回滚处理。

此外，CGW13根据改写数据种类，对于1面独立存储器即ECU(ID1)，进行第一回滚处理或者第二回滚处理。CGW13若判定为对于全部的回滚对象的改写对象ECU19未进行回滚处理(S1521：“否”)，则返回步骤S1513，重复步骤S1513以后的步骤。CGW13若判定为对于全部的回滚对象的改写对象ECU19进行了回滚处理(S1521：“是”)，则结束取消请求的判定处理。CGW13对进行了回滚处理的属于第一组的ECU(ID1)、ECU(ID2)和ECU(ID3)，同时指示旧应用程序的激活。1面独立存储器即ECU(ID1)重新启动，由此切换为旧应用程序。2面存储器即ECU(ID2)和ECU(ID3)不是在写入了更新程序的非运用面(B面)启动，而是在与此前相同的运用面(A面)启动。另外，在用户的意图发生变化，仍然执行程序更新时，在ECU(ID1)和ECU(ID3)中写入新应用程序，但由于在ECU(ID2)中已经在非运用面安装完了新应用程序，因此省略写入。

CGW13若判定为未产生取消请求而完成了应用程序的改写(S1511：“是”)，则判定是否完成了激活(S1522)，判定是否产生了取消请求(S1523)。

CGW13若判定为在完成激活前产生了取消请求、即在激活中产生了取消请求(S1523：“是”)，则判定激活的指示是否到达改写对象ECU19，判定是否完成了运用面的切换(S1524)。

CGW13若判定为激活的指示未到达改写对象ECU19，判定为未完成运用面的切换(S1524：“否”)，则进行第四回滚处理(S1525)。作为第四回滚处理，CGW13不切换运用面。或者，CGW13也可以不切换运用面而将非运用面返回到改写为新应用程序之前的状态。CGW13在不切换运用面的情况下，如图163所示，将写入版本1.0的面保存为运用面，将写入版本2.0的面保存为非运用面。在不切换运用面而将非运用面返回到改写为新应用程序之前的状态的情况下，如图164所示，CGW13将写入版本1.0的面保存为运用面，将写入版本2.0的面即非运用面回写到改写为新应用程序之前的状态(版本1.0)。

CGW13若判定为激活的指示到达改写对象ECU19，判定为完成了运用面的切换(S1524：“是”)，则进行第五回滚处理。如图165所示，运用面的切换完成表示写入了版本2.0的面从非运用面切换为运用面，版本1.0的面从运用面切换为非运用面的状态。作为第五回滚处理，CGW13切换运用面、或者在将非运用面返回到改写为新应用程序之前的状态之后切换运用面。CGW13在切换运用面的情况下，如图165所示，将写入版本2.0的面从运用面切换为非运用面，将写入版本1.0的面从非运用面切换为运用面。在将非运用面返回到改写为新应用程序之前的状态之后切换运用面的情况下，如图166所示，CGW13将写入版本2.0的面即运用面回写到改写为新应用程序之前的状态(例如版本1.0)，将返回到改写为该新应用程序之前的状态的面从运用面切换为非运用面，将写入版本1.0的面从非运用面切换为运用面。

像以上说明的那样，CGW13通过进行回滚的执行控制处理，若在应用程序的改写中产生改写的取消请求，则使改写对象ECU19的动作状态复原为从用户来看是开始该应用程序的改写之前的状态。由此，能够使属于同一组的改写对象ECU19全部同时地返回到原来的程序版本。另外，即使在下一程序更新中使用差分数据的情况下，也能够正确地复元写入数据。

(16)改写进展状况的显示控制处理

参照图167至图179对改写进展状况的显示控制处理进行说明。车辆用程序改写系统1在CGW13中进行改写进展状况的显示控制处理。为了向用户传达应用程序的改写的进展状况，显示终端5即便携终端6、车载显示器7显示进展状况。作为显示的进展状况，不仅包含更新程序的情况，还包含例如由于用户的取消操作、更新失败等而回滚的情况。

如图167所示，CGW13在改写进展状况的显示控制部87中，具有取消检测部87a、写入指示部87b、报告指示部87c。关于将存储于改写对象ECU19的第一写入数据改写为从中心装置3获取的第二写入数据的程序的改写，取消检测部87a检测取消。取消检测部87a例如检测用户的取消操作、向改写对象ECU19的写入失败等异常。在是不适合于改写对象ECU19的写入数据的情况下、在对于写入数据检测出篡改的情况下、在产生了对改写对象ECU19的写入错误的情况下等、取消检测部87a检测出规定的异常的情况下，也进行回滚处理，因此这些异常的检测也视为取消的检测。

写入指示部87b向改写对象ECU19分发第二写入数据，指示第二写入数据的写入。报告指示部87c指示与应用程序的改写相关的进展状况的报告。在通过写入指示部87b分发第二写入数据的过程中，报告指示部87c指示为通过第一形式来报告与应用程序的改写相关的进展状况，若通过取消检测部87a检测出取消，则指示为通过第二形式来报告与应用程序的改写相关的进展状况。写入指示部87b若在分发第二写入数据的过程中，通过取消检测部87a检测出取消，则持续第二写入数据的分发。

CGW13根据确定改写对象ECU19的内部状态、确定来自中心装置3的指示、确定用户操作中任一方，而确定改写对象ECU19中的应用程序的改写。CGW13若确定应用程序的改写，则判定是通常时的改写(安装)还是回滚时的改写(卸载)。CGW13若根据确定改写对象ECU19的内部状态、确定来自中心装置3的指示、确定用户操作中的任一方，判定是通常时的改写还是回滚时的改写，则根据该判定结果对通常时或者回滚时的改写的进展状况进行运算，向显示终端5指示该运算出的进展状况的显示。

CGW13根据表示是通常时的改写还是回滚时的改写的改写判定结果，而向显示终端5指示通常时的进展状况或者回滚时的进展状况的显示。CGW13以区别表示通常时的改写的进展状况的进展显示和表示回滚时的改写的进展状况的进展显示的方式指示显示。即，CGW13在通常时的改写的情况下以第一形式显示进展状况，在回滚时的改写的情况下，以与第一形式不同的第二形式显示进展状况。作为与显示进展状况时的显示相关的形式，CGW13在通常时和回滚时区别显示画面中的文字、项目、颜色、数值、闪烁等，而区别通常时的进展显示和回滚时的进展显示。另外，作为与显示进展显示时的显示以外的显示相关的形式，CGW13通过在通常时和回滚时区别声音、振动等，而区别通常时的进展显示和回滚时的进展显示。

接下来，参照图168至图179对CGW13的作用进行说明。CGW13执行改写进展状况的显示控制程序，进行改写进展状况的显示控制处理。

CGW13若接收到表示在改写对象ECU19中开始了程序的改写的内容的改写开始信号(若开始向改写对象ECU19的安装)，则开始改写进展状况的显示控制处理。CGW13若开始改写进展状况的显示控制处理，则对CGW用的改写规格数据进行解析，确定改写对象ECU19的闪存的存储器种类和写入数据种类，确定通常时的改写对象ECU19(S1601)。CGW13若确定改写对象ECU19的闪存的存储器种类、写入数据种类和更新程序的大小(S1602)，则根据该确定结果对通常时的改写进展状况进行运算，指示该运算出的通常时的改写进展状况的显示(S1603)。显示终端5根据来自CGW13的指示，以通常时的改写显示形式进行显示。

CGW13判定是否完成了应用程序的改写(S1604)，判定是否产生了取消请求(S1605、相当于取消检测步骤)。CGW13例如在向改写对象ECU(ID1)的安装中，重复S1604和S1605，随时更新进展状况而进行显示。

CGW13若接收到表示在改写对象ECU19中完成了应用程序的改写的内容的改写完成信号，判定为未产生取消请求而完成了应用程序的改写(S1604：“是”)，则结束通常时的改写进展状况的显示(S1606)，判定对于全部的改写对象ECU19是否完成了改写(S1607)。例如在完成了改写对象ECU(ID1)的安装的情况下，CGW13将ECU(ID1)的进展状况显示为100％。CGW13若判定为对于全部的改写对象ECU19未完成改写(S1607：“否”)，则返回步骤S1601，重复步骤S1601以后的步骤。CGW13例如在S1601以后的步骤中，进行关于接下来安装的改写对象ECU(ID2)的进展显示。

CGW13若判定为在完成应用程序的改写之前产生了取消请求(S1605：“是”)，则结束通常时的改写进展状况的显示(S1608)，转移至回滚时的显示控制处理(S1609、相当于报告指示步骤)。这里，取消请求包含基于用户的取消请求、以及基于向改写对象ECU19的写入失败等的系统的取消请求。

CGW13若开始回滚时的显示控制处理，则确定回滚时的改写对象ECU19(S1611)，确定该回滚时的改写对象ECU19的闪存的存储器种类、回滚程序的数据种类和大小(S1612)。假设CGW13例如使属于同一组的改写对象ECU19为ECU(ID1)、ECU(ID2)和ECU(ID3)，ECU(ID1)和ECU(ID2)的安装完成，在ECU(ID3)的安装中途产生了取消请求。在该情况下，CGW13根据各改写对象ECU19的存储器种类和写入数据种类，而确定回滚的需要与否和回滚方法。

CGW13确定成为回滚对象的改写对象ECU19的闪存的存储器种类和写入数据种类，确定回滚的需要与否和回滚方法(上述的S1518的第一回滚处理、S1519的第二回滚处理、S1520的第三回滚处理)。CGW13根据该确定结果对进展状况进行运算，显示进展状况，并且指示回滚时的改写进展状况的显示(S1613)。CGW13根据第一～第三回滚处理中的各个处理，写入的数据量不同。因此，CGW13根据第一～第三回滚处理来决定写入数据总量，根据与所写入的数据量的比例来运算进展(写入了几％)。CGW13判定作为回滚处理的应用程序的改写是否完成(S1614)。

CGW13向改写对象ECU19分发写入数据直到作为回滚处理的改写完成为止，并且重复上述的进展的运算和显示指示。CGW13在S1613中，以回滚时的显示形式显示运算出的进展状况。CGW13在S1614中，例如判定改写中途的ECU(ID3)的回滚是否正常完成。

CGW13若判定为针对回滚对象的改写对象ECU19的回滚完成(S1614：“是”)，则结束回滚时的改写进展状况的显示(S1615)。CGW13例如持续对于ECU(ID3)回滚完成了100％的内容的显示。

CGW13对于全部的回滚对象ECU19，判定是否完成了回滚时的改写(S1616)。CGW13若对于全部的回滚对象ECU19判定为未完成回滚时的改写(S1616：“否”)，则返回步骤S1611，重复步骤S1611以后的步骤。

例如在完成了安装的ECU(ID1)为1面独立存储器的情况下，CGW13进行回滚时的改写进展状况的显示(S1613)。另一方面，例如在完成了安装的ECU(ID2)为2面存储器且不需要回滚的情况下，从回滚时的改写对象除去ECU(ID2)。若ECU(ID3)和ECU(ID1)的回滚完成，则CGW13对于全部的回滚对象的改写对象ECU19，改写完成(S1616：“是”)，结束回滚时的显示控制处理。

另外，在上述的说明中，CGW13进行回滚时的显示控制处理，但也可以构成为，从CGW13获取需要的信息，并且车载显示器ECU7、中心装置3进行回滚时的显示控制处理。另外，也可以构成为，利用CGW13进行回滚时的改写、进展运算等，利用车载显示器ECU7、中心装置3进行回滚时的显示控制。即，并不局限于仅CGW13具有显示控制装置的功能的结构，也可以是利用CGW13和车载显示器ECU7分散地具有显示控制装置的功能的结构，也可以是利用CGW13和中心装置3分散地具有显示控制装置的功能的结构。

以下，参照图170至图178对改写进展状况的显示进行说明。显示终端5在通常时的改写进展状况的显示中，如图170所示，将整体进展状况显示为“通常改写”，使用户掌握是通常时的改写进展状况的显示。也可以将“通常改写”显示为“安装”。作为第一形式，显示终端5进行通常时的改写进展状况的显示。

显示终端5对于完成应用程序的改写、处于等待激活更新程序的同步指示的状态的改写对象ECU19，将进展状态显示为“等待同步指示”，对于处于改写中的状态的改写对象ECU19，将进展状态显示为“通常改写中”。也可以将“等待同步指示”显示为“等待激活”。也可以将“通常改写中”显示为“安装中”。图170例示了ECU(ID0001)和ECU(ID0002)完成应用程序的改写而处于等待同步指示的状态，ECU(ID0003)处于通常改写中的状态的情况。

显示终端5若从该状态产生取消请求，则如图171所示，例如弹出显示“受理了取消。复元到改写前的状态。请稍等。”这样的消息，使用户掌握受理了取消。作为第二形式，显示终端5进行受理了取消的内容的显示。

显示终端5若通过CGW13完成回滚时的改写的准备，则如图172所示，将整体进展状况显示为“回滚改写”，使用户掌握回滚时的改写进展状况的显示。也可以将“回滚改写”显示为“卸载”。显示终端5对于全部的改写对象ECU19将进展状态显示为“等待回滚”，将表示改写状况的进展的进展图表的数值显示为“0％”。也可以将“等待回滚”显示为“等待卸载”。这里，采用ECU(ID0001)和ECU(ID0002)是1面独立存储器ECU，ECU(ID0003)是2面存储器ECU的例子，除了改写中途的ECU(ID0003)之外，完成了安装的ECU(ID0001)和ECU(ID0002)也需要回滚。在图172中，采用表示一个整体进展状况、并且分别显示各改写对象ECU19的进展状况的形式。

CGW13若开始回滚时的改写，则如图173所示，对于处于改写中的状态的改写对象ECU19，将进展状态显示为“回滚改写中(或卸载中)”。作为第三形式，显示终端5进行回滚时的改写进展状况的显示。图173例示了ECU(ID0003)处于回滚改写中的状态的情况。显示终端5若完成改写对象ECU19中的回滚，则如图174所示，对于完成了改写的改写对象ECU19，将进展状态作为“回滚完成”，以100％显示进展状况。

在回滚对象ECU19是1面独立存储器ECU，是整体数据的改写的情况下，如图175所示，显示终端5使进展图表的显示转变。即，在回滚对象ECU19是1面独立存储器ECU，是整体数据的改写的情况下，立即中断全部数据的分发，在改写对象ECU19中将旧应用程序的数据写入闪存而改写为旧应用程序(第一回滚处理)。

例如若在通常改写完成到“50％”的阶段产生取消请求(图176(a))，则显示终端5将进展图表的数值显示为“0％”(图176(b))，根据写入旧应用程序的数据的进展而使进展图表的数值增加，改写为旧应用程序(图176(c)、(d)、(e))。若对旧应用程序的改写100％完成，则显示终端5显示该改写对象ECU19为“回滚完成”的内容。另外，图175和以后说明的图176～178表示各个ECU的进展显示。

在回滚对象ECU19是1面独立存储器ECU、是差分数据的改写的情况下，如图176或者图177所示，显示终端5使进展图表的显示转变。即，在回滚对象ECU19是1面独立存储器、是差分数据的改写的情况下，CGW13持续差分数据的分发，在改写对象ECU19中将差分数据写入闪存而改写为新应用程序。CGW13向改写对象ECU19分发旧应用程序的数据，在改写对象ECU19中将旧数据写入闪存而改写为旧应用程序(第二回滚处理)。

例如若在通常改写(安装)完成到“50％”的阶段产生取消请求(图176(a)、图177(a))，则显示终端5将进展图表的数值显示为“0％”(图176(b)、图177(b))。改写对象ECU19使在此前写入的差分数据有效，进行进行从CGW13分发的差分数据的写入。即，从“0％”的显示切换为相当于有效的“50％”的比例的安装完成这样的进展显示(图176(c)，图177(c))。显示终端5根据改写对象ECU19写入从CGW13分发的新程序的差分数据的进展而增加进展图表的数值(图176(d)、(e)、图177(d)、(e))。显示终端5在改写对象ECU19完成了新应用程序的改写之后，接着根据改写对象ECU19写入从CGW13分发的旧应用程序的差分数据的进展，而增加进展图表的数值(图176(f)、(g)、图177(f)、(g))。即，作为回滚处理，与产生新程序的持续安装和旧程序的安装相配合地，显示终端5进行显示，以使得可知新程序写入的进展状况和旧程序写入的进展状况。

在该情况下，也可以如图176所示，在显示终端5中，作为新应用程序的改写量，将左侧的进展图表显示为“100％”，作为旧应用程序的改写量，将右侧的进展图表显示为“100％”，由此使进展图表的宽度整体为“200％”。在该情况下，显示终端5根据新应用程序的文件大小和所写入的新应用程序的累积数据大小，对新应用程序的进展百分比进行运算，根据旧应用程序的文件大小和所写入的旧应用程序的累积数据大小对旧应用程序的进展百分比进行运算，显示进展状况。

另外，也可以如图177所示，在显示终端5中，通过使新应用程序的改写量为“50％”，使旧应用程序的改写量为“50％”，而使进展图表的宽度整体为“100％”。在该情况下，显示终端5根据新应用程序的文件大小与旧应用程序的文件大小的合计值、所写入的新应用程序的累积数据大小与旧应用程序的累积数据大小的合计值，而对进展百分比进行运算并进行显示。

在回滚对象ECU19为1面挂起存储器ECU或者2面存储器ECU的改写的情况下，如图178所示，显示终端5使进展图表的显示转变。即，在回滚对象ECU19为1面挂起存储器ECU或者2面存储器ECU的改写的情况下，CGW13持续向改写对象ECU19分发写入数据，在改写对象ECU19中将写入数据写入非运用面而改写为新应用程序(第三回滚处理)。

例如若在通常改写(安装)完成到“50％”的阶段产生取消请求(图178(a))，则显示终端5将进展图表的数值显示为“0％”(图178(b))。改写对象ECU19使在此前写入的差分数据有效，持续进行从CGW13分发的差分数据的写入。即，从“0％”的显示切换为有效的相当于“50％”的比例的安装完成这样的进展显示(图178(c))。显示终端5根据改写对象ECU19写入从CGW13分发的写入数据的进展而增加进展图表的数值(图178(d)、(e))。另外，在本实施方式中，说明了CGW13进行改写进展状况的显示控制处理的内容，但也可以是显示终端5进行改写进展状况的显示控制处理的结构。

像以上说明的那样，显示终端5通过进行改写进展状况的显示控制处理，在回滚处理的基础上，以区别应用程序的改写是通常时的改写(安装)还是回滚时的改写(卸载)的显示形式显示进展状况。用户受理更新程序的取消，能够掌握回滚推进。另外，以上，说明了针对每个改写对象ECU19显示进展状态的结构，但如图179所示，也可以是统一地显示改写对象ECU19的进展状态的结构。在该情况下，显示终端5将针对三个改写对象ECU19的进展显示作为一个进展状态进行显示而不是个别地显示。作为回滚处理，CGW13根据在三个改写对象ECU19中产生的写入完毕数据量相对于写入数据总量的比例，对进展进行运算。

(17)差分数据的整合性判定处理

参照图180至图183对差分数据的整合性判定处理进行说明。车辆用程序改写系统1在改写对象ECU19中开始安装之前进行差分数据的整合性判定处理。

如图180所示，ECU19在差分数据的整合性判定部103中，具有差分数据获取部103a、整合性判定部103b、写入数据复元部103c、数据写入部103d、数据验证值计算部103e、改写规格数据获取部103f、数据识别信息获取部103g、以及改写面信息获取部103h。

差分数据获取部103a获取用于对改写对象ECU19的电子控制装置的数据储存区域进行改写的数据、即表示旧数据与新数据的差分的差分数据。整合性判定部103b基于与在闪存的数据储存区域中存储的储存数据相关的第一判定信息、和以与差分数据相关联的形式获取的第二判定信息，而判定差分数据是否与数据储存区域或者储存数据整合。例如第一判定信息是针对储存数据的数据验证值，第二判定信息是针对旧数据的数据验证值或者针对新数据的数据验证值。若由整合性判定部103b判定为差分数据的整合性为正，则写入数据复元部103c使用差分数据和储存数据来复元写入数据，若由整合性判定部103b判定为差分数据的整合性为否，则写入数据复元部103c不复元写入数据。若通过写入数据复元部103c复元写入数据，则数据写入部103d将该复元后的写入数据储存于数据储存区域。数据验证值计算部103e计算针对将储存数据分割为一个以上的各块的数据验证值。另外，数据验证值计算部103e获取与差分数据一同接收到的针对各块的数据验证值。

改写规格数据获取部103f从CGW13获取CGW用的改写规格数据中的对应于自身的改写规格数据。数据识别信息获取部103g获取储存于差分数据的数据识别信息、以及旧数据即旧应用程序的数据识别信息。数据识别信息是能够识别差分数据是否为用于自身的数据的信息，例如是将规定的算法应用于旧数据而计算出的数据。

改写面信息获取部103h获取在从CGW13获取的改写规格数据中储存的改写面信息、以及旧数据即旧应用程序的改写面信息。改写面信息是表示作为写入数据的差分数据是用于写入闪存的哪个面的数据的信息，在改写对象ECU19为2面存储器或者1面挂起存储器的情况下，指定A面或者B面。在改写对象ECU19为1面独立存储器的情况下，不使用改写面信息。整合性判定部103b若通过写入数据接收部101接收从CGW13分发的差分数据，则使用数据识别信息、数据验证值、改写面信息中的至少任意一个来判定该差分数据的整合性。

接下来，参照图181至图183对改写对象ECU19的差分数据的整合性判定部103的作用进行说明。改写对象ECU19执行差分数据的整合性判定程序，进行差分数据的整合性判定处理。改写对象ECU19若开始差分数据的整合性判定处理，则作为用于判定差分数据的整合性的第一判定信息，获取与差分数据相关的数据识别信息、数据验证值和改写面信息(S1701)。作为第二判定信息，改写对象ECU19获取数据识别信息、旧数据的数据验证值、新数据的数据验证值和改写面信息(S1702)。

改写对象ECU19判定第一判定信息的数据识别信息与第二判定信息的数据识别信息是否一致，并且第一判定信息的改写面信息与第二判定信息的改写面信息是否一致(S1703)。改写对象ECU19若判定为第一判定信息的数据识别信息与第二判定信息的数据识别信息不一致、或者第一判定信息的改写面信息与第二判定信息的改写面信息不一致(S1703：“否”)，则判定为是不适当的写入数据，向CGW13通知错误信息，结束差分数据的整合性判定处理。

改写对象ECU19若判定为第一判定信息的数据识别信息与第二判定信息的数据识别信息一致，并且第一判定信息的改写面信息与第二判定信息的改写面信息一致(S1703：“是”)，则对第一判定信息的数据验证值与第二判定信息的新数据的数据验证值进行对照，判定两者是否一致(S1704、相当于整合性判定步骤)。改写对象ECU19若判定为两者不一致(S1704：“否”)，则对第一判定信息的数据验证值与第二判定信息的旧数据的数据验证值进行对照，判定两者是否一致(S1705、相当于整合性判定步骤)。

改写对象ECU19若判定为两者一致(S1705：“是”)，则复元写入数据(S1706、相当于复元写入数据的步骤)，将该复元后的写入数据写入闪存(S1707、相当于数据写入步骤)，判定是否完成了全部的写入(S1708)。改写对象ECU19若判定为未完成全部的写入(S1708：“否”)，则返回步骤S1703，重复步骤S1703以后的步骤。改写对象ECU19若判定为完成了全部的写入(S1708：“是”)，则结束差分数据的整合性判定处理。

改写对象ECU19若判定为第一判定信息的数据验证值与第二判定信息的新数据的数据验证值不一致(S1704：“否”)，并且第一判定信息的数据验证值与第二判定信息的旧数据的数据验证值不一致(S1705：“否”)，则判定是否是针对第一块的写入(S1709)。

改写对象ECU19若判定为是针对第一块的写入(S1709：“是”)，则由于是没有完成针对第一块的写入的状态，因此判定是否完成了全部的写入(S1708)。改写对象ECU19若判定为不是针对第一块的写入、即是针对第二块以后的块的写入(S1709：“否”)，则重试写入(S1710)，判定是否完成了全部的写入(S1708)。

参照图182对改写对象ECU19是1面独立存储器ECU的情况进行说明。在从CGW13分发的差分数据中添加有数据识别信息(旧)、针对每个旧数据的块而计算出的CRC值(数据验证值)。数据识别信息(旧)是指对旧数据(旧应用程序)应用规定的算法而计算出的数据。在将数据识别信息作为判定信息的情况下，改写对象ECU19对添加于差分数据的数据识别信息(旧)与存储于闪存的程序(旧数据)的数据识别信息(旧)进行对照，判定差分数据的整合性。存储于闪存的数据识别信息(旧)是在将程序写入改写对象ECU19的闪存时，一并地存储的信息。或者，也可以将从写入到闪存的程序的起始地址起规定比特数视为数据识别信息(旧)。

在将数据验证值作为判定信息的情况下，改写对象ECU19对存储于闪存的程序的每个块的CRC值进行计算，对在接收到的差分数据中添加的针对旧数据的CRC值(CRC(B1～Bn))和针对新数据的CRC值(CRC(B1’～Bn’)与该计算出的CRC值进行对照，判定差分数据的整合性。在未将新程序写入闪存的状态下，在全部的块中接收到的CRC值与计算出的CRC值一致。改写对象ECU19在直到闪存的m(＜n)块为止写入了新程序的状态下写入中断、并重新开始的情况下，直到块1～m为止与针对新数据的CRC值(CRC(B1’～Bn’)一致，因此跳过写入处理(S1706、S1707)。而且，改写对象ECU19从块m+1观察与针对旧数据的CRC值(CRC(B1～Bn))的一致来进行写入处理(S1706、S1707)。

另外，也可以在差分数据中添加新程序(新数据)的数据识别信息(新)和每个块的CRC值(CRC(B1‘～Bn’))。改写对象ECU19在将差分数据写入闪存，并完成了新程序的安装时，也一并地存储数据识别信息(新)，用于下次的程序更新中的整合性判定。另外，改写对象ECU19在完成了新程序的安装时，针对每个块读出写入到闪存的新程序而计算CRC值，与添加于差分数据的CRC值进行比较，验证是否正确地写入。

参照图183对改写对象ECU19为2面存储器ECU的情况进行说明。在该情况下也是，在将数据验证值作为判定信息的情况下，改写对象ECU19对存储于闪存的程序的每个块的CRC值进行计算，对添加于接收到的差分数据的针对旧数据的CRC值(CRC(B1～Bn))、针对新数据的CRC值(CRC(B1’～Bn’)与该计算出的CRC值进行对照，判定差分数据的整合性。在未将新程序写入于闪存的状态下，在全部的块中接收到的CRC值与计算出的CRC值一致。改写对象ECU19在直到闪存的m(＜n)块为止写入了新程序的状态下写入中断、并重新开始的情况下，直到块1～m为止与针对新数据的CRC值(CRC(B1’～Bn’)一致，因此跳过写入处理(S1706、S1707)。而且，改写对象ECU19从块m+1观察与针对旧数据的CRC值(CRC(B1～Bn))的一致来进行写入处理(S1706，S1707)。

假设闪存的A面为运用面并且是版本2.0，B面为非运用面并且是版本1.0，差分数据是用于将B面更新为版本3.0的差分数据(版本1.0与版本3.0的差分数据)。在从CGW13分发的差分数据中，添加有数据识别信息(表示旧(版本1.0)的信息)、针对旧数据(旧程序(版本1.0))的每个块而计算出的CRC值、以及针对新数据(新程序(版本3.0))的每个块而计算出的CRC值。

另外，在改写规格数据中包含表示针对改写对象ECU19的差分数据是写入闪存的哪个面的数据的改写面信息。在将改写面信息作为判定信息的情况下，改写对象ECU19对从改写规格数据中获取的改写面信息和改写对象ECU19的非运用面信息(B面)进行对照，判定差分数据的整合性。在将数据识别信息作为判定信息的情况下，改写对象ECU19对添加于差分数据的数据识别信息(旧(版本1.0))和存储于闪存的非运用面(B面)的旧程序(版本1.0)的数据识别信息(旧)进行对照，判定差分数据的整合性。在将数据验证值作为判定信息的情况下，改写对象ECU19对存储于闪存的非运用面(B面)的旧程序(版本1.0)的每个块的CRC值进行计算，对添加于差分数据的CRC值(CRC(B1～Bn))与该计算出的CRC值进行对照，判定差分数据的整合性。

在上述的图179和图180的例子中，说明了数据识别信息和数据验证值被添加于差分数据，与差分数据一同从CGW13分发的情况。然而，也可以将这些数据识别信息和数据验证值作为差分数据的头信息而添加，CGW13在向改写对象ECU19分发差分数据之前，向改写对象ECU19分发头信息。改写对象ECU19在从CGW13接收到头信息时，使用数据识别信息和数据验证值来判定差分数据的整合性。

另外，在图179和图180中，以改写数据为差分数据的情况为例进行了说明，但在改写数据为整体数据的情况下也相同。另外，在改写对象ECU19为1面独立存储器的情况下，在使用回滚用的差分数据而返回到原来的版本时也进行相同的整合性判定。

像以上说明的那样，改写对象ECU19通过进行差分数据的整合性判定处理，仅在差分数据的整合性为正的情况下，执行基于差分数据而生成的写入数据的写入，将在差分数据的整合性为否的情况下写入了基于差分数据而生成的写入数据的情况防患于未然。例如对于闪存的B面为非运用面的改写对象ECU19，在用于写入A面的差分数据包含于分发包的情况下，能够在将差分数据写入闪存之前检测不整合。另外，在将面向其他ECU的差分数据、版本不整合的差分数据作为面向自身的差分数据而包含于分发包的情况下，能够在将差分数据写入闪存之前检测不整合。

另外，改写对象ECU19在中断了写入数据的写入之后重新开始的情况下，基于针对闪存的储存数据的数据验证值、附带于接收到的差分数据的旧数据的数据验证值和新数据的数据验证值而判定差分数据的整合性。改写对象ECU19也可以基于针对储存数据的数据验证值和接收到的新数据的验证值而判定差分数据的整合性，从判定为该判定结果为否的最终块，基于针对储存数据的数据验证值和接收到的旧数据的数据验证值而判定差分数据的整合性。

另外，改写对象ECU19直到判定为差分数据的整合性为否的最终块的至少前段块为止跳过写入数据的写入，从最终块或者该终块的后段块重新开始写入数据的写入。在块大小与写入数据的写入区域的数据大小相等的情况下，由于直到最终块为止完成写入数据的写入，因此只要跳过直到最终块为止的写入，从最终块的后段块重新开始写入即可。另一方面，在块大小与写入数据的写入区域的数据大小不相等的情况下，有可能在最终块中断写入数据的写入，因此需要从最终块重新开始写入。

(18)改写的执行控制处理

参照图184至图191对改写的执行控制处理进行说明。车辆用程序改写系统1在ECU19中进行改写的执行控制处理。

如图184所示，ECU19在改写的执行控制部104中，具有程序执行部104a、切换请求接收部104b、数据获取部104c、面信息通知部104d、固件获取部104e、安装执行部104f、以及激活执行部104g。程序执行部104a在执行运用面的应用程序、参数数据的过程中，执行运用面的改写程序而改写非运用面。切换请求接收部104b从CGW13接收激活请求。数据获取部104c从外部获取非运用面中的需要改写的区域的写入数据。面信息通知部104d向外部通知2面改写信息(以下，称为面信息)。固件获取部104e从外部获取改写程序的固件。安装执行部104f若被CGW13指示安装，则将写入数据写入闪存，执行安装。激活执行部104g若被CGW13指示激活，则在重新启动时执行切换运用面的激活。

接下来，参照图185至图191对ECU19的改写的执行控制部104的作用进行说明。改写对象ECU19执行改写的执行控制程序，进行改写的执行控制处理。作为改写的执行控制处理，改写对象ECU19进行通常动作处理、改写动作处理、信息通知处理、以及应用程序的验证处理。以下，对各个处理进行说明。在本实施方式中，对改写对象ECU19为2面存储器ECU或者1面挂起存储器ECU的情况进行说明。

(18-1)通常动作处理

若伴随着IG电源接通等，从停止状态或者休眠状态转移至启动状态，则改写对象ECU19开始通常动作处理。改写对象ECU19若开始通常动作处理，则基于A面和B面的启动面判定信息来确定启动面(S1801)，在该启动面启动(S1802)。改写对象ECU19对存储于启动面(运用面)的程序的完整性进行验证，判定启动面是否为正(S1803)。

改写对象ECU19若判定为启动面的完整性的验证结果为否，判定为启动面为否(S1803：“否”)，则向CGW13发送表示启动面的完整性的验证结果为否的内容的错误信息(S1804)，结束通常动作处理。CGW13若从改写对象ECU19接收错误信息，则向DCM12发送该错误信息。DCM12若从CGW13接收错误信息，则将该接收到的错误信息上传到中心装置3。即，若在改写对象ECU19中判定为启动面的完整性的验证结果为否，则向CGW13、DCM12、中心装置3通知该内容。

改写对象ECU19若判定为启动面的完整性的验证结果为正，判定为启动面为正(S1803：“是”)，则对存储于改写面(非运用面)的程序的完整性进行验证，判定改写面是否为正(S1805)。

改写对象ECU19若判定为改写面的完整性的验证结果为否，判定为改写面为否(S1805：“否”)，则向CGW13发送表示改写面的完整性的验证结果为否的内容的错误信息(S1806)。CGW13若从改写对象ECU19接收错误信息，则向DCM12发送该错误信息。DCM12若从CGW13接收错误信息，则将该接收到的错误信息上传到中心装置3。即，若在改写对象ECU19中判定为改写面的完整性的验证结果为否，则向CGW13、DCM12、中心装置3通知该内容。

在执行应用程序之前由启动程序执行上述的完整性验证的处理。改写对象ECU19若结束完整性验证，则确定启动向量表的配置地址(S1807)，确定通常时向量表的配置地址(S1808)，确定应用程序的起始地址(S1809)，执行应用程序，结束通常动作处理。

(18-2)改写动作处理

改写对象ECU19若从CGW13接收改写请求，则开始改写动作处理。改写对象ECU19若开始改写动作处理，则在与CGW13之间使用安全访问密钥来进行认证(S1811)。改写对象ECU19若判定为认证结果为正(S1812：“是”)，则等待写入数据的接收(S1813)。改写对象ECU19若判定为从CGW13接收到写入数据(S1813：“是”)，则在执行配置于启动面(运用面)的应用程序的状态下，对配置于改写面(非运用面)的应用程序进行改写(S1814)。

改写对象ECU19判定是否完成了应用程序的改写(S1815)，若判定为完成了应用程序的改写(S1815：“是”)，则判定检验是否为正(S1816)。改写对象ECU19若判定为检验为正(S1816：“是”)，则将改写完成标志设定为“OK”(S1817)。检验是指写入到非运用面的应用程序的完整性验证。

改写对象ECU19判定是否从CGW13接收到激活请求(S1818)。改写对象ECU19若判定为从CGW13接收到激活请求(S1818：“是”)，则例如将改写面的启动面信息的数值自加1，更新改写面的启动面信息(S1819)。即，此后，更新为表示在该改写面启动的信息。改写对象ECU19判定是否从CGW13接收到版本读出信号(S1820)，若判定为接收到版本读出信号(S1820：“是”)，则向CGW13发送运用面的版本信息、非运用面的版本信息、能够确定哪个面是运用面的识别信息(S1821)，结束改写动作处理。这里，在改写对象ECU19中，也可以由切换前的运用面(旧面)的应用程序执行从S1811到S1821为止的全部的处理。另外，在改写对象ECU19中，由切换前的运用面(旧面)的应用程序执行从S1811到S1819为止的处理，在进行了S1819之后重新启动，由此也可以由切换后的运用面(新面)的应用程序执行从S1820到S1821为止的处理。

(18-3)信息通知处理

若从停止状态或者休眠状态转移至启动状态、或者例如IG电源接通或者从CGW13接收通知请求，则改写对象ECU19开始信息通知处理。改写对象ECU19若开始信息通知处理，则向CGW13通知能够唯一地确定与运用面、非运用面相关的应用程序、参数数据的识别信息和能够唯一地确定运用面、非运用面的存储器上的配置场所的识别信息。即，改写对象ECU19获取与启动面相关的启动面信息(S1831)，向CGW13发送该启动面信息(S1832)。改写对象ECU19向CGW13发送A面和B面中的哪个面是启动面的信息和启动面的版本信息等来作为启动面信息。

改写对象ECU19若完成向CGW13发送启动面信息，则获取与改写面相关的改写面信息(以下，也称为面信息)(S1833)，向CGW13发送该获取的改写面信息(S1834)。改写对象ECU19向CGW13发送A面和B面中的哪个面是改写面的信息和改写面的版本信息等来作为改写面信息。改写对象ECU19若完成向CGW13发送改写面信息，则向CGW13发送能够确定存储器上的启动面和改写面的配置地址的识别信息(S1835)，结束信息通知处理。改写对象ECU19例如向CGW13发送闪存中的A面的开始地址和结束地址以及B面的开始地址和结束地址，来作为能够确定地址的识别信息。

(18-4)改写程序的验证处理

改写对象ECU19若开始改写程序的验证处理，则判定是否获取了能够确定用于执行改写程序的地址的识别信息(S1841)。改写对象ECU19若判定为获取了能够确定用于执行改写程序的地址的识别信息(S1841：“是”)，判定该识别信息与改写对象ECU19的启动面信息是否一致(S1842)。具体而言，改写对象ECU19判定启动面信息中的表示启动面的面信息与该识别信息是否一致。

改写对象ECU19若判定为识别信息与改写对象ECU19的启动面信息一致(S1842：“是”)，则获取改写程序(S1843)，判定是否获取了能够确定用于进行应用程序的改写的地址的识别信息(S1844)。这里，改写对象ECU19如果是将改写程序预先嵌入于闪存的嵌入型的结构，则在S1843中，从闪存获取启动面的写入程序而在RAM上执行。改写对象ECU19如果是未将改写程序预先嵌入闪存，从外部下载改写程序的下载型的结构，则在S1843中，将改写程序下载到RAM而执行。

改写对象ECU19若判定为获取了能够确定用于进行应用程序的改写的地址的识别信息(S1844：“是”)，则判定该识别信息与改写对象ECU19的启动面信息是否一致(S1845)。具体而言，改写对象ECU19判定启动面信息中的表示非启动面的面信息与该识别信息是否一致。改写对象ECU19若判定为识别信息与ECU19的启动面信息一致(S1845：“是”)，则进行应用程序的改写(S1846)，结束改写程序的验证处理。

改写对象ECU19若判定为识别信息与ECU19的启动面信息不一致(S1842：“否”)、或者判定为识别信息与改写对象ECU19的启动面信息不一致(S1845：“否”)，则判定为不是在运用面、非运用面能够执行的应用程序、参数数据，向CGW13发送否定响应(S1847)，结束改写程序的验证处理。例如在闪存的A面为运用面且B面为非运用面的2面存储器ECU的情况下，用于执行改写程序的地址是运用面即A面的地址，用于进行应用程序的改写的地址是非运用面即B面的地址。

另外，如图186所示，改写对象ECU19也可以在从CGW13获取写入数据之前，从CGW13获取能够确定地址的识别信息。另外，如图187所示，改写对象ECU19也可以在从CGW13获取写入数据时获取能够确定地址的识别信息。改写对象ECU19例如在获取写入数据之前从CGW13接收改写规格数据，获取改写面信息。在改写面信息中包含能够识别哪个面是启动面、哪个面是改写面的数据，因此将该能够识别的数据作为能够确定地址的识别信息而使用。

另外，响应于CGW13进行安装指示处理，改写对象ECU19进行上述的(18-2)改写动作处理。这里，对由CGW13进行的安装指示处理进行说明。

CGW13若开始安装指示处理，则识别改写规格数据(S1851)，判定是否对于全部的改写对象ECU19指定驻车中的安装，是否对于全部的改写对象ECU19指定车辆行驶中的安装，是否对于改写对象ECU19的每个存储器种类指定安装(S1852～S1854)。

CGW13若判定为对于全部的改写对象ECU19指定驻车中的安装(S1852：“是”)，则以得到安装的同意并且处于驻车中为条件，向改写对象ECU19指示安装(S1855)。CGW13若判定为对于全部的改写对象ECU19指定车辆行驶中的安装(S1853：“是”)，则以得到安装的同意且处于车辆行驶中为条件，向改写对象ECU19指示安装(S1856)。

CGW13若判定为对于改写对象ECU19的每个存储器种类指定安装(S1854：“是”)，则根据改写规格数据来判定存储器种类是2面存储器、还是1面挂起存储器或者1面独立存储器(S1857、S1858)。

CGW13若判定为改写对象ECU19的存储器种类为2面存储器，满足第一规定条件(S1857：“是”)，则以得到安装的同意且处于车辆行驶中为条件，向改写对象ECU19指示安装(S1859)。CGW13若判定为改写对象ECU19的存储器种类是1面挂起存储器或者1面独立存储器，满足第二规定条件(S1858：“是”)，则以得到安装的同意且处于驻车中为条件，向改写对象ECU19指示安装(S1860)。

CGW13判定在全部的改写对象ECU19中是否完成了安装(S1861)，若判定为在全部的改写对象ECU19中未完成安装(S1861：“否”)，则返回步骤S1851，重复步骤S1851以后。

即，如果改写对象ECU19为2面存储器ECU，则CGW13在车辆能够行驶的过程中指示安装。2面存储器ECU通过在车辆能够行驶的过程中被CGW13指示安装，而在车辆能够行驶的过程中进行安装(相当于安装执行步骤)。如果改写对象ECU19为1面挂起存储器ECU、1面独立存储器ECU，则CGW13在驻车中指示安装。1面挂起存储器ECU、1面独立存储器ECU通过在驻车中被CGW13指示安装，而在驻车中进行安装(相当于安装执行步骤)。

CGW13若判定为在全部的改写对象ECU19中完成了安装(S1861：“是”)，则判定是否处于驻车中(S1862)，若判定为处于驻车中(S1862：“是”)，则在驻车中向改写对象ECU19指示激活(S1863)，结束安装指示处理。改写对象ECU19通过在驻车中被CGW13指示激活，而进行激活(相当于激活执行步骤)。

像以上说明的那样，改写对象ECU19通过进行改写的执行控制处理，而在多个面具有数据储存面的结构中，在执行运用面的应用程序的过程中，执行运用面的改写程序而改写非运用面。能够改写应用程序的期间不限于驻车状态，在车辆行驶中也能够改写应用程序。改写对象ECU19如果是2面存储器ECU，则通过在车辆能够行驶的过程中被CGW13指示安装，能够在车辆能够行驶的过程中进行安装。改写对象ECU19如果是1面挂起存储器ECU、1面独立存储器ECU，则通过在驻车中被CGW13指示安装，能够在驻车中进行安装。

(19)会话的确立处理

参照图192至图205对会话的确立处理进行说明。车辆用程序改写系统1在改写对象ECU19中进行会话的确立处理。

如图192所示，ECU19在会话的确立部105中，具有应用执行部105a、无线改写请求确定部105b、以及有线改写请求确定部105c。应用执行部105a具有对各程序的执行进行调停的功能。无线改写请求确定部105b具有确定经由无线的程序改写请求的功能。有线改写请求确定部105c具有确定经由有线的程序改写请求的功能。

图193表示存储于闪存的各程序的结构。车辆控制程序是用于实现搭载于ECU19自身的车辆控制功能(例如转向控制功能)的程序。有线诊断程序是用于从车辆外部经由有线进行ECU19自身的诊断的程序。无线诊断程序是用于从车辆外部经由无线进行ECU19自身的诊断的程序。无线改写程序是用于进行从车辆外部经由无线获取的程序的改写的程序。有线改写程序是用于进行从车辆外部经由有线获取的程序的改写的程序。车辆控制程序作为第一程序配置于应用区域。有线诊断程序和有线改写程序作为第二程序配置于应用区域。无线诊断程序和无线改写程序作为第三程序配置于应用区域。换言之，第二程序是进行车辆控制以外的经由有线的特殊处理的程序，第三程序是进行车辆控制以外的经由无线的特殊处理的程序。另外，有线改写程序也可以不配置于应用区域，而作为第四程序配置于启动区域。

应用执行部105a控制为能够同时执行第一程序、第二程序、以及第三程序(非排他控制)。应用执行部105a例如能够同时执行车辆控制程序、有线诊断程序、以及无线诊断程序。即，应用执行部105a能够同时执行车辆控制、利用有线的ECU19的诊断、以及利用无线的ECU19的诊断。同样，应用执行部105a控制为能够同时执行车辆控制程序、有线诊断程序、以及无线改写程序，能够同时执行车辆控制程序、有线改写程序、以及无线诊断程序，能够同时执行车辆控制程序、有线改写程序、以及无线改写程序。

另一方面，应用执行部105a进行排他控制，使得不能同时执行第二程序内的各程序。同样，进行排他控制，使得不能同时执行第三程序内的各程序。应用执行部105a例如对有线诊断程序和有线改写程序进行排他控制，对无线诊断程序和无线改写程序进行排他控制。即，应用执行部105a仅执行经由有线的特殊处理中的一个程序。同样，应用执行部105a仅执行经由无线的特殊处理中的一个程序。

换言之，也可以说，无线改写程序配置在无线诊断程序的内部，作为无线诊断程序的一部分而嵌入。即，若通过将无线改写程序配置在无线诊断程序的内部的结构，在执行车辆控制程序和有线诊断程序的过程中像后述那样从默认会话或者无线诊断会话向无线改写会话转变状态，则应用执行部105a控制为在持续车辆控制程序和有线诊断程序的执行的状态下，执行无线改写程序。应用执行部105a在持续车辆控制程序和有线诊断程序的执行的状态下，开始无线改写程序的执行，由此能够同时执行车辆控制程序、有线诊断程序、以及无线改写程序。即，应用执行部105a控制为能够同时执行车辆控制、利用有线的ECU19的诊断、以及利用无线的应用程序的改写。

这里，根据诊断处理、改写处理的具体的内容，产生无法同时执行利用有线的诊断和利用无线的诊断以及利用有线的改写和利用无线的改写的状况。例如在利用有线的改写和利用无线的改写对相同的区域进行改写的情况下，两者的处理冲突。因此，应用执行部105a根据处理、请求的具体内容，对有线诊断程序和无线诊断程序进行排他控制，另外，对有线改写程序和无线改写程序进行排他控制。另外，根据诊断处理的内容，还产生无法持续通常的车辆控制的情况。例如在进行使ECU进行动作而读出该结果的诊断处理的情况下，与通常的车辆控制不能同时执行。在该情况下，应用执行部105a进行如下的调停控制，使车辆控制程序待机，执行有线或者无线诊断程序。

另一方面，在有线改写程序不配置于应用区域，而作为第四程序配置于启动区域的情况下，应用执行部105a进行与上述一部分不同的调停控制。如图193中虚线所示，有线改写程序作为第四程序配置于有线诊断程序的外部，未作为有线诊断程序的一部分而嵌入。在该情况下，应用执行部105a在执行第四程序时，进行排他控制以结束第一～第三程序。即，应用执行部105a从执行第一～第三程序的模式切换为执行第四程序的专用模式。换言之，若通过将有线改写程序配置于有线诊断程序的外部的结构，在执行车辆控制程序和无线诊断程序的过程中像后述那样从有线诊断会话向有线改写会话转变状态，则有线改写程序控制为停止车辆控制程序和无线诊断程序的执行，开始有线改写程序的执行。应用执行部105a通过停止车辆控制程序和无线诊断程序的执行，开始有线改写程序的执行，而不能同时执行车辆控制程序、无线诊断程序、以及有线改写程序，能够仅执行有线改写程序。即，应用执行部105a控制为不能同时执行车辆控制、利用无线的ECU19的诊断、以及利用有线的应用程序的改写，能够仅执行利用有线的应用程序的改写。

如图194所示，作为与利用有线的特殊处理相关的第一状态，应用执行部105a管理默认的状态(默认会话)、有线诊断的状态(有线诊断会话)、以及有线改写的状态(有线改写会话)。另外，作为与利用无线的特殊处理相关的第二状态，管理默认的状态(默认会话)和无线改写的状态(无线改写会话)，管理动作的内部状态。

作为第一状态的状态转变，应用执行部105a使能够依据诊断通信标准进行车辆控制的默认会话、能够从车辆外部经由有线进行ECU19的诊断的有线诊断会话、能够进行从车辆外部经由有线获取的应用程序的改写的有线改写会话排他地进行状态转变。使会话排他地状态转变是指不能同时确立会话，使会话非排他地状态转变是指能够同时确立会话。

第一状态下的默认会话是表示没有进行利用有线的特殊处理的状态的模式，是能够执行车辆控制的状态。默认会话也可以说是可以执行对车辆控制完全没有带来影响的处理、例如执行与车辆控制无关的诊断程序的模式。与车辆控制无关的诊断程序是用于进行故障代码等信息的读出等的程序。有线诊断会话是执行与ECU19的诊断相关的诊断程序的模式。至少在通过执行诊断程序而成为能够对车辆控制带来影响的状态的情况下，从默认会话转移至有线诊断会话。与ECU19的诊断相关的诊断程序是用于进行通信停止、诊断屏蔽、致动器驱动等的程序。有线改写会话是执行从车辆外部经由有线获取的应用程序的改写的模式。

应用执行部105a在第一状态下像以下那样进行会话的状态转变。若在第一默认会话的状态下产生利用有线的诊断请求，则应用执行部105a根据诊断会话转移请求使从第一默认会话转移至有线诊断会话，执行利用有线的诊断处理。若在有线诊断会话的状态下产生会话复原请求、产生超时、电源断开或者接收法规服务，则应用执行部105a使从有线诊断会话转移至第一默认会话。若在第一默认会话的状态下产生有线改写请求，则应用执行部105a在根据诊断会话转移请求使从第一默认会话转移至有线诊断会话之后，根据改写会话转移请求使从有线诊断会话转移至有线改写会话，执行有线改写处理。若在有线改写会话的状态下产生会话复原请求、产生超时、电源断开或者接收法规服务，则应用执行部105a使从有线改写会话转移至第一默认会话。另外，应用执行部105a根据会话维持请求维持当前的会话而不转移。

作为第二状态的状态转变，应用执行部105a使能够依据诊断通信标准而进行车辆控制的默认会话、与从车辆外部经由无线获取的应用程序的改写相关的无线改写会话排他地状态转变。无线改写会话是执行从车辆外部经由无线获取的应用程序的改写的模式。

应用执行部105a在第二状态下像以下那样进行会话的状态转变。若在第二默认会话的状态下产生无线改写请求，则应用执行部105a根据改写会话转移请求使从第二默认会话转移至无线改写会话，执行无线改写处理。若在无线改写会话的状态下产生会话复原请求、产生超时或者电源断开，则应用执行部105a使从无线改写会话转移至第二默认会话。另外，应用执行部105a根据会话维持请求维持当前的会话而不转移。

应用执行部105a执行作为第一程序的车辆控制程序，并且管理与利用有线的特殊处理相关的第一状态以及与利用无线的特殊处理相关的第二状态。例如若第一状态和第二状态都在默认会话中产生有线诊断请求，则应用执行部105a在持续车辆控制程序的状态下，使第一状态转移至有线诊断会话，开始有线诊断程序的执行。在该状态下，若产生无线改写请求，则应用执行部105a在持续车辆控制程序和有线诊断程序的执行的状态下，使第二状态转移至无线改写会话，开始无线改写程序的执行。在该状态下，若产生有线改写请求，则应用执行部105a例如结束无线改写程序的执行，使第二状态转移至默认会话，并且结束有线诊断程序的执行，使第一状态转移至有线改写会话，开始有线改写程序的执行。应用执行部105a为了防止对相同的存储器区域的写入处理冲突，而进行排他地状态转变(进行排他地控制)，使得不同时确立第一状态的有线改写会话和第二状态的无线改写会话。

无线改写请求确定部105b判定从外部接收到的改写请求的识别信息，确定无线改写请求。即，若从中心装置3向DCM12下载重编数据，CGW13向改写对象ECU19分发从DCM12传输来的重编数据，则无线改写请求确定部105b通过从CGW13与重编数据一同接收表示无线改写请求的识别信息，而确定无线改写请求。

有线改写请求确定部105c判定从外部接收到的改写请求的识别信息，确定有线改写请求。即，若工具23与DLC连接器22连接，CGW13向改写对象ECU19分发从工具23传输来的重编数据，则有线改写请求确定部105c通过从CGW13与重编数据一同接收表示有线改写请求的识别信息，而确定有线改写请求。

识别信息例如也可以是对应于在有线改写请求和无线改写请求中不同的识别ID的信息，也可以是，虽然是在有线改写请求和无线改写请求中相同的识别ID但对应于不同的数据的信息。即，只要能够识别有线改写请求和无线改写请求，则也可以是任意的信息。

在应用执行部105a中，在图194中，说明了作为与利用无线的特殊处理相关的第二状态，管理默认会话和无线改写会话这两个状态的结构，也可以如图195和图196所示，采用作为第二状态，管理默认会话、无线诊断会话和无线改写会话这三个状态的结构。无线诊断会话是执行用于从车辆外部经由无线进行ECU19的诊断的无线诊断程序的模式。至少在执行对车辆控制带来影响的无线诊断程序的情况下，转移至无线诊断会话。

在图195所示的结构的情况下，应用执行部105a像以下那样进行第二状态的状态转变。若在第二默认会话的状态下产生利用无线的诊断请求，则应用执行部105a根据诊断会话转移请求从第二默认会话转移至无线诊断会话，执行无线诊断处理。若在无线诊断会话的状态下产生会话复原请求、产生超时、电源断开，则应用执行部105a使从无线诊断会话转移至第二默认会话。若在第二默认会话的状态下产生无线改写请求，则应用执行部105a在根据诊断会话转移请求使从第二默认会话转移至无线诊断会话之后，根据改写会话转移请求使从无线诊断会话转移至无线改写会话，执行无线改写处理。若在无线改写会话的状态下产生会话复原请求、产生超时、电源断开，则应用执行部105a使从无线改写会话转移至第二默认会话。

在图196所示的结构的情况下，应用执行部105a像以下那样进行第二状态的状态转变。若在第二默认会话的状态下产生利用无线的诊断请求，则应用执行部105a根据诊断会话转移请求使从第二默认会话转移至无线诊断会话，执行无线诊断处理。若在无线诊断会话的状态下产生会话复原请求、产生超时、电源断开，则应用执行部105a使从无线诊断会话转移至第二默认会话。若在第二默认会话的状态下产生无线改写请求，则应用执行部105a在根据诊断会话转移请求使从第二默认会话转移至无线诊断会话之后，根据改写会话转移请求使从无线诊断会话转移至无线改写会话、或者根据改写会话转移请求使从第二默认会话转移至无线改写会话，执行无线改写处理。若在无线改写会话的状态下产生会话复原请求、产生超时、电源断开，则应用执行部105a使从无线改写会话转移至第二默认会话。

另外，第一状态的有线诊断会话与第二状态的无线诊断会话可以执行相同的诊断程序，也可以执行不同的诊断程序。第一状态的有线改写会话与第二状态的无线改写会话可以执行相同的改写程序，也可以执行不同的改写程序。例如也可以执行存储器的消除、写入等共用的改写程序。

在图195和图196所示的结构中，对第一状态的各会话和第二状态的各会话的调停进行说明。像图193中说明的那样，说明如下的情况，即有线诊断程序作为第二程序配置于应用区域，无线诊断程序和无线改写程序作为第三程序配置于应用区域，有线诊断程序作为第四程序配置于启动区域。换言之，是关于如下的结构的说明，即无线改写程序作为无线诊断程序的一部分而嵌入，另一方面有线改写程序未作为有线诊断程序的一部分而嵌入。在该情况下，第一状态和第二状态的各会话中的程序执行的调停像图197所示那样。

在第二状态为无线改写会话、并且第一状态为默认会话的情况下，应用执行部105a执行车辆控制程序，并且执行无线改写程序。在第二状态为无线改写会话、并且第一状态为有线诊断会话的情况下，应用执行部105a执行车辆控制程序，并且同时执行无线改写程序和有线诊断程序。

另一方面，在第一状态为有线改写会话、并且第二状态为默认会话的情况下，应用执行部105a结束车辆控制程序，仅执行有线改写程序。在第一状态为有线改写会话、并且第二状态为无线诊断会话的情况下，应用执行部105a结束无线诊断程序和车辆控制程序，仅执行有线改写程序。即，作为仅执行第四程序即有线改写程序的专用模式，应用执行部105a对第一～第三程序进行排他控制。

另外，在有线诊断程序和有线改写程序作为第二程序配置于应用区域的结构中，各程序的调停与图197一部分不同。即，在无线改写程序作为无线诊断程序的一部分被嵌入并且有线改写程序作为有线诊断程序的一部分被嵌入的结构中，第一状态和第二状态的各会话中的程序执行的调停像图198所示那样。在这种情况下，在第一状态为有线改写会话、并且第二状态为默认会话的情况下，应用执行部105a执行车辆控制程序，并且执行有线改写程序。在第一状态为有线改写会话、并且第二状态为无线诊断会话的情况下，应用执行部105a执行车辆控制程序，并且同时执行有线改写程序和无线诊断程序。

接下来，参照图199至图203对上述的结构的作用进行说明。在ECU19中，微机33执行会话的确立程序，进行会话的确立处理。

微机33若检测出电源接通而启动，则执行会话确立程序而进行状态转变管理处理，进行管理第一状态的状态转变的状态转变管理处理和管理第二状态的状态转变的状态转变管理处理。以下，对各个状态转变管理处理进行说明。另外，这里，说明应用执行部105a通过图194所示的结构、即不具有无线诊断会话的结构来管理第二状态的情况。

(19-1)第一状态的状态转变管理处理

微机33若检测出电源接通而启动，开始第一状态的状态转变管理处理，则判定改写完成标志，判定是否正常地完成上次的应用程序的改写(S1901)。微机33若判定为改写完成标志为正，判定为正常地完成了上次的应用程序的改写(S1901：“是”)，则使第一状态转移至默认会话(S1902)。即，微机33通过使第一状态转移至默认会话，而开始车辆控制处理。

微机33若执行车辆控制程序而开始车辆控制处理，则判定在执行车辆控制处理的过程中，是否产生了有线诊断请求(S1903)，判定是否产生了有线改写请求(S1904)，判定状态转变管理的完成条件的成立(S1905)。微机33若判定为在执行车辆控制处理的过程中，产生了有线诊断请求(S1903：“是”)，则使第一状态从默认会话转移至有线诊断会话(S1906)，执行有线诊断程序而开始有线诊断处理(S1907)。微机33判定有线诊断处理的完成条件的成立(S1908)，若判定为有线诊断处理的完成条件成立(S1908：“是”)，则结束有线诊断程序而结束有线诊断处理(S1909)，使第一状态从有线诊断会话转移至默认会话(S1910)。

微机33若判定为在执行车辆控制处理的过程中，产生了有线改写请求(S1904：“是”)，则开始有线改写请求产生时的改写排他处理(S1911)。即，是用于进行排他控制的处理，以使有线改写处理与无线改写处理不冲突。微机33若开始有线改写请求产生时的改写排他处理，则判定在第二状态下是否处于转移至无线改写会话的过程中、即第二状态是否为无线改写会话(S1921)。微机33若判定为在第二状态下不处于转移至无线改写会话的过程中(S1921：“否”)，则将第一状态确定为能够转移至有线改写会话(S1922)。微机33结束有线改写请求产生时的改写排他处理，复原到第一状态的状态转变管理处理。

微机33若判定为在第二状态下处于转移至无线改写会话的过程中(S1921：“是”)，则判定使有线改写会话和无线改写会话中的哪个优先来进行排他控制。具体而言，微机33判定有线改写会话优先条件、无线改写会话优先条件、转移中改写会话优先条件中的任一方是否成立(S1923～S1925)。有线改写会话优先条件是使有线改写会话比无线改写会话优先的条件。无线改写会话优先条件是使无线改写会话比有线改写会话优先的条件。转移中改写会话优先条件是使转移中的改写会话优先、即使先转移的会话优先的条件。预先设定采用这些优先条件中的哪个条件，例如也可以针对车辆设定优先条件标志，也可以针对每个改写ECU设定优先条件标志。

微机33若判定为有线改写会话优先条件成立(S1923：“是”)，则在第二状态下根据会话复原请求使无线改写会话转移至默认会话而中断无线改写(S1926)，将第一状态确定为能够转移至有线改写会话(S1922)。伴随着默认会话转移，微机33结束无线改写程序。微机33结束有线改写请求产生时的改写排他处理，复原到第一状态的状态转变管理处理。

微机33若判定为无线改写会话优先条件成立(S1924：“是”)，则废弃有线改写请求而持续无线改写(S1927)。即，微机33将第二状态维持在无线改写会话，持续无线改写程序的执行，将第一状态确定为不能转移至有线改写会话(S1928)。微机33结束有线改写请求产生时的改写排他处理，复原到第一状态的状态转变管理处理。

微机33若判定为转移中改写会话优先条件成立(S1925：“是”)，则在该情况下，也废弃有线改写请求而持续无线改写(S1927)。即，微机33将第二状态维持在无线改写会话，持续无线改写程序的执行，将第一状态确定为不能转移至有线改写会话(S1928)。微机33结束有线改写请求产生时的改写排他处理，复原到第一状态的状态转变管理处理。微机33通过像这样执行有线改写请求产生时的改写排他处理，而排他地控制有线改写会话和无线改写会话，使得不同时确立会话。

微机33若复原到第一状态的状态转变管理处理，则作为有线改写请求产生时的改写排他处理的结果，判定是否能够转移至有线改写会话(S1912)。微机33若通过确定为利用有线改写请求产生时的改写排他处理能够转移至有线改写会话，而判定为能够转移(S1912：“是”)，则使第一状态从默认会话经由有线诊断会话而转移至有线改写会话(S1913)，中断车辆控制处理而开始有线改写处理(S1914)。伴随着有线改写会话转移，微机33结束车辆控制程序。

微机33判定有线改写处理的完成条件的成立(S1915)，若判定为有线改写处理的完成条件成立(S1915：“是”)，则完成有线改写处理(S1916)，使第一状态从有线改写会话转移至默认会话(S1917)。这里，有线改写处理的完成条件例如是指应用程序的写入全部完成，执行了完整性验证的情况等。

微机33若通过确定为利用有线改写请求产生时的改写排他处理不能转移至有线改写会话，而判定为不能转移(S1912：“否”)，则不使第一状态从默认会话经由有线诊断会话而转移至有线改写会话。即，微机33将第一状态维持在默认会话。微机33若判定为状态转变管理的完成条件成立(S1905：“是”)，则完成第一状态的状态转变管理处理。

另外，以上，说明了如下的情况，即微机33若在有线改写请求产生时的改写排他处理中，判定为在第二状态下处于转移至无线改写会话的过程中，判定为有线改写会话优先条件成立，则在第二状态下中断无线改写，但也可以根据无线改写的未改写余量而判定是否中断无线改写会话。

微机33若判定为在第二状态下处于转移至无线改写会话的过程中(S1921：“是”)，判定为有线改写会话优先条件成立(S1923：“是”)，则在该转移中的无线改写会话中判定无线改写的未改写余量是否为规定量以上(例如20％以上)(S1931)。微机33若判定为无线改写的未改写余量为规定量以上(S1931：“是”)，则使第二状态从无线改写会话转移至默认会话而中断无线改写(S1926)。微机33伴随着转移至默认会话，而结束无线改写程序。微机33若判定为无线改写的未改写余量不是规定量以上(S1931：“否”)，则废弃该有线改写请求而持续无线改写(S1927)。即，如果直到完成无线改写为止的剩余时间比较长，则微机33中断无线改写会话，但如果直到完成无线改写为止的剩余时间比较短，则微机33持续无线改写会话而不中断。

(19-2)第二状态的状态转变管理处理

微机33若检测出电源接通而启动，开始第二状态的状态转变管理处理，则判定改写完成标志，判定是否正常地完成了上次的应用程序的改写(S1941)。微机33若判定为改写完成标志为正，判定为正常地完成了上次的应用程序的改写(S1941：“是”)，则使第二状态转移至默认会话(S1942)。即，微机33通过使第二状态转移至默认会话，而执行车辆控制程序，开始车辆控制处理。

微机33若开始车辆控制处理，则判定是否产生了无线改写请求(S1943)，判定状态转变管理的完成条件的成立(S1944)。微机33若判定为在执行车辆控制处理的过程中，产生了无线改写请求(S1943：“是”)，则开始无线改写请求产生时的改写排他处理(S1944)。微机33若开始无线改写请求产生时的改写排他处理，则判定在第一状态下是否处于转移至有线改写会话的过程中、即第一状态是否为有线改写会话(S1961)。微机33若判定为在第一状态下不处于转移至有线改写会话的过程中(S1961：“否”)，则确定为能够转移至无线改写会话(S1962)。微机33结束无线改写请求产生时的改写排他处理，复原到第二状态的状态转变管理处理。

微机33若判定为在第一状态下处于转移至有线改写会话的过程中(S1961：“是”)，则判定使有线改写会话和无线改写会话中的哪个优先来进行排他控制。具体而言，微机33判定无线改写会话优先条件、有线改写会话优先条件、以及转移中改写会话优先条件中的任意条件是否成立(S1963～S1965)。

微机33若判定为无线改写会话优先条件成立(S1963：“是”)，则在第一状态下根据会话复原请求使有线改写会话转移至默认会话而中断有线改写(S1966)，将第二状态确定为能够转移至无线改写会话(S1962)。微机33伴随着转移至默认会话，而结束有线改写程序。微机33结束无线改写请求产生时的改写排他处理，复原到第二状态的状态转变管理处理。

微机33若判定为有线改写会话优先条件成立(S1964：“是”)，则废弃无线改写请求而持续有线改写(S1967)。即，微机33将第一状态维持在有线改写会话，持续有线改写程序的执行，将第二状态确定为不能转移至无线改写会话(S1968)。微机33结束无线改写请求产生时的改写排他处理，复原到第二状态的状态转变管理处理。

微机33若判定为转移中改写会话优先条件成立(S1965：“是”)，则在该情况下也废弃无线改写请求而持续有线改写(S1967)。即，微机33将第一状态维持在有线改写会话，持续有线改写程序的执行，将第二状态确定为不能转移至无线改写会话(S1968)。微机33结束无线改写请求产生时的改写排他处理，复原到第二状态的状态转变管理处理。微机33通过像这样执行无线改写请求产生时的改写排他处理，而排他地控制有线改写会话和无线改写会话，不会同时确立会话。

微机33若复原到第二状态的状态转变管理处理，则作为无线改写请求产生时的改写排他处理的结果，判定是否能够转移至无线改写会话(S1945)。微机33若通过确定为利用无线改写请求产生时的改写排他处理能够转移至无线改写会话，而判定为能够转移(S1945：“是”)，则使第二状态从默认会话转移至无线改写会话(S1946)，执行无线改写程序而开始无线改写处理(S1847)。微机33判定无线改写处理的完成条件的成立(S1948)，若判定为无线改写处理的完成条件成立(S1948：“是”)，则结束无线改写处理(S1949)，使第二状态从无线改写会话转移至默认会话(S1950)。伴随着转移至默认会话，微机33结束无线改写程序。这里，无线改写处理的完成条件例如是指应用程序的写入全部完成，执行了完整性验证的情况等。

微机33若通过确定为利用无线改写请求产生时的改写排他处理不能转移至无线改写会话，而判定为不能转移(S1945：“否”)，则不使第二状态从默认会话转移至无线改写会话。即，微机33将第二状态维持在默认会话。微机33若判定为状态转变管理的完成条件成立(S1951：“是”)，则结束第二状态的状态转变管理处理。

以上，说明了在应用执行部105a中，能够独立(同时)执行与利用有线的特殊处理相关的程序以及与利用无线的特殊处理相关的程序的情况，然而也可以如图201所示，采用将有线诊断程序和无线诊断程序共用化的结构。采用将车辆控制程序作为第一程序配置于应用区域、将诊断程序(有线诊断程序和无线诊断程序)和无线改写程序作为第二程序配置于应用区域的结构。有线改写程序也可以作为第二程序配置于应用区域，也可以作为第三程序配置于启动区域。应用执行部105a同时执行第一程序和第二程序。即，应用执行部105a控制为能够同时执行车辆控制程序和共用化的诊断程序。另一方面，应用执行部105a对构成第二程序的各程序的执行进行排他控制。即，控制为有线诊断程序、无线诊断程序、无线改写程序和有线改写程序中的仅任意一个进行动作。

如图202所示，作为状态，应用执行部105a管理默认的状态(默认会话)、诊断的状态(诊断会话)、有线改写的状态(有线改写会话)、以及无线改写的状态(无线改写会话)，管理动作的内部状态。这里管理的状态并不是在有线和无线独立地管理的状态，而是混合地作为一个状态进行管理。

在该结构中也是应用执行部105a执行车辆控制程序，开始诊断程序的执行。另外，应用执行部105a执行车辆控制程序，开始无线改写程序、有线改写程序的执行。另一方面，应用执行部105a排他地控制无线诊断程序和有线诊断程序的执行。另外，应用执行部105a也排他地控制有线诊断程序和无线诊断程序、有线改写程序和无线改写程序的执行。即，应用执行部105a排他地控制构成第二程序的各程序的执行。

这里，在将有线改写程序作为第三程序配置于启动区域的情况下，应用执行部105a排他地执行控制第三程序以及第一和第二程序。即，在执行有线改写程序的情况下，结束第一程序和第二程序，作为专用模式进行动作。

如图202所示，应用执行部105a若产生诊断请求，则持续车辆控制程序的执行，并且转移至诊断会话，开始诊断程序的执行。在该状态下，若产生无线改写请求，则应用执行部105a结束诊断程序，转移至无线改写会话，并且开始无线改写程序的执行。持续车辆控制程序的执行。另一方面，在产生了有线改写请求的情况下，应用执行部105a结束诊断程序和车辆控制程序，转移至有线改写会话，并且开始有线改写程序的执行。

即使无线改写程序配置在诊断程序的内部，若在执行车辆控制程序和诊断程序的过程中从诊断会话向无线改写会话转变状态，则应用执行部105a在中断车辆控制程序和诊断程序的执行之后开始无线改写程序的执行。另外，在不伴随会话的情况下能够持续处理。

如果有线改写程序配置于诊断程序的外部，则当在执行车辆控制程序和诊断程序的过程中从诊断会话向有线改写会话转变状态时，应用执行部105a停止车辆控制程序和无线诊断程序的执行，有线改写程序开始执行。即，应用执行部105a不能同时执行车辆控制、利用有线或者无线的ECU19的诊断、以及利用有线的应用程序的改写，能够仅执行利用有线的应用程序的改写。

像以上说明的那样，ECU19通过进行会话的确立处理，而执行第一状态的状态转变管理处理和第二状态的状态转变管理处理，管理第一状态和第二状态中的各会话的状态转变，非排他地确立第一状态的默认会话或者有线诊断会话和第二状态的无线改写会话。对于车辆控制或者ECU19的诊断和利用无线的程序的改写的请求，控制为非排他地执行车辆控制程序或者ECU19的诊断程序和无线改写程序，能够对于来自外部的各种请求适当地调停。

另外，在ECU19中，排他地确立有线改写会话和无线改写会话。能够控制为排他地执行有线改写程序和无线改写程序，适当地调停利用有线的程序的改写和利用无线的程序的改写。

另外，在ECU19中，若有线改写会话优先条件成立，则使有线改写会话比无线改写会话优先。通过预先设定有线改写会话优先条件，与利用无线的程序的改写相比，能够优先地执行利用有线的程序的改写。例如与由车辆的用户指示的利用无线的程序的改写相比，能够优先地执行由经销商等设置者指示的利用有线的程序的改写。

另外，在ECU19中，若无线改写会话优先条件成立，则使无线改写会话比有线改写会话优先。通过预先设定无线改写会话优先条件，与利用有线的程序的改写相比，能够优先地执行利用无线的程序的改写。例如与经销商等设置者指示的利用有线的程序的改写相比，能够优先地执行由车辆的用户指示的利用无线的程序的改写。

另外，在ECU19中，若转移中改写会话优先条件成立，则使转移中的改写会话优先。通过预先设定转移中改写会话优先条件，能够优先地执行转移中的改写。即，能够使有线改写和无线改写中的先开始的一方持续而不中断。

在2面具有应用区域的结构中，采用在各应用区域配置有车辆控制程序、诊断程序、以及无线改写程序的结构，并行(同时)地执行车辆控制程序或者诊断程序、以及无线改写程序。通过设计闪存30d的存储器结构，能够并行地执行车辆控制程序或者诊断程序、以及无线改写程序。

若在执行车辆控制程序或者有线诊断程序的过程中确定无线改写请求，则持续车辆控制程序或者有线诊断程序的执行，执行无线改写程序。在执行车辆控制程序或者有线诊断程序的过程中产生了无线改写请求时，能够并行(同时)地执行车辆控制程序或者有线诊断程序、以及无线改写程序。

若在执行无线改写程序的过程中确定车辆控制请求或者有线诊断请求，则持续无线改写程序的执行，执行车辆控制程序或者有线诊断程序。在执行无线改写程序的过程中产生了车辆控制请求或者有线诊断请求时，能够并行(同时)地执行无线改写程序、以及车辆控制程序或者有线诊断程序。

若在执行车辆控制程序或者无线诊断程序的过程中确定有线改写请求，则停止车辆控制程序或者无线诊断程序的执行，执行有线改写程序。在执行车辆控制程序或者无线诊断程序的过程中产生了有线改写请求时，能够仅排他地执行有线改写程序。

在嵌入重编固件的重编固件嵌入型的情况下，使用配置于应用区域的固件，执行改写程序。不用从外部下载重编固件，就能够执行非运用面的应用程序的改写处理。

在从外部下载重编固件的重编固件下载型的情况下，使用从外部下载的固件，执行改写程序。在减少了应用区域中的改写程序的容量的基础上，能够执行非运用面的应用程序的改写处理。

对在实质上的2面具有应用区域的2面存储器进行了说明，但在伪2面具有应用区域的1面挂起方式存储器、外置存储器，也能够应用。

对根据旧数据和差分重编数据生成新数据的差分改写的情况进行了说明，但在删除旧数据而写入新数据的全改写的情况下也能够应用。

对改写ECU19的应用程序的情况进行了说明，但在改写CGW13的应用程序的情况下也能够应用。即，也可以使CGW13的闪存26d为2面结构而成为与ECU19的闪存30d同等的结构，使微机26具有与ECU19的微机33相同的功能。

(20)重试点的确定处理

参照图206至图210对重试点的确定处理进行说明。车辆用程序改写系统1在改写对象ECU19中进行重试点的确定处理。重试点是指在将写入数据分多次写入的情况下，在中断写入数据的写入的情况下，为了从中途重新开始该中断的写入数据的写入，表示处理完成到何处的信息。作为中断写入数据的写入的情况，例如有产生了基于用户操作的取消的情况、产生了通信隔断等异常的情况、在驻车状态下点火从断开切换为接通的情况等。

在ECU19中，程序改写部102利用多个改写程序分担与应用程序的改写相关联的一系列的处理。程序改写部102具有进行第一处理的第一改写程序、进行第二处理的第二改写程序，依次执行各个改写程序。由第一改写程序进行的第一处理例如是消除闪存的数据的存储器消除处理、对写入数据进行写入的数据写入处理等。由第二改写程序进行的第二处理例如是检验处理、篡改检查处理等。

如图206所示，ECU19在重试点的确定部106中，具有第一处理标志设定部106a、第二处理标志设定部106b、以及重试点确定部106c。若程序改写部102执行第一改写程序，则第一处理标志设定部106a判定该程序改写部102是否通过第一改写程序完成了第一处理，设定表示该判定结果的第一处理标志。第一处理标志设定部106a若判定为程序改写部102完成了第一处理，则将第一处理标志设定为“OK”。

若程序改写部102执行第二改写程序，则第二处理标志设定部106b判定该程序改写部102是否通过第二改写程序完成了第二处理，设定表示该判定结果的第二处理标志。第二处理标志设定部106b若判定为程序改写部102完成了第二处理，则将第二处理标志设定为“OK”。

在中断了与程序的改写相关联的处理的一部分的情况下，重试点确定部106c根据第一处理标志和第二处理标志确定由程序改写部102重试应用程序的改写时的重试点。另外，重试点确定部106c预先存储直到中断时为止的更新数据的写入量，在重新开始与程序的改写相关联的处理的情况下，向CGW13请求发送基于该存储的更新数据的写入量的更新数据。如图207所示，第一处理标志和第二处理标志存储于改写对象ECU19的闪存的同一块内。

接下来，参照图208至图210对改写对象ECU19的重试点的确定部106的作用进行说明。改写对象ECU19执行重试点的确定程序，进行重试点的确定处理。作为重试点的确定处理，改写对象ECU19进行处理标志的设定处理、处理标志的判定处理。以下，对各个处理进行说明。

(20-1)处理标志的设定处理

改写对象ECU19若开始处理标志的设定处理，判定是否完成应用程序的改写前的预先处理(S2001)。改写对象ECU19若判定为完成应用程序的改写前的预先处理(S2001：“是”)，则将第一处理标志设定为“NG”，将第二处理标志设定为“NG”，并进行存储(S2002、相当于第一处理标志设定步骤、第二处理标志设定步骤)。

改写对象ECU19若从CGW13接收写入数据，则开始第一处理(S2003)，判定是否完成了第一处理(S2004)。改写对象ECU19若判定为完成了第一处理(S2004：“是”)，则在将第二处理标志维持为“NG”的状态下，将第一处理标志设定为“OK”，并进行存储(S2005、相当于第一处理标志设定步骤、第二处理标志设定步骤)。一并地，改写对象ECU19存储表示写入完成到闪存的哪处的写入完成地址。

改写对象ECU19开始朝向CGW13的写入完成通知等第二处理(S2006)，判定是否完成了第二处理(S2007)。改写对象ECU19若判定为完成了第二处理(S2007：“是”)，则在将第一处理标志维持为“OK”的状态下，将第二处理标志设定为“OK”并进行存储(S2008、相当于第一处理标志设定步骤、第二处理标志设定步骤)，结束处理标志的设定处理。

(20-2)处理标志的判定处理

改写对象ECU19若在从休眠或者停止状态启动时，开始处理标志的判定处理，则由启动程序启动(S2011)，从闪存读出第一处理标志和第二处理标志而进行判定(S2012～S2015)。

改写对象ECU19若判定为第一处理标志为“NG”且第二处理标志为“NG”(S2012：“是”)，则将重试点确定为第一处理的起始，向CGW13通知来自第一处理的起始的重试请求(S2016、相当于重试点确定步骤)，结束重试点的确定处理。即，改写对象ECU19向CGW13请求写入数据的分发。此时，改写对象ECU19还向CGW13通知从闪存读出的写入完成地址，由此CGW13确定可以对分割地分发的写入数据中的哪个进行分发。改写对象ECU19若判定为第一处理标志为“NG”且第二处理标志为“OK”(S2013：“是”)，则在该情况下也是将重试点确定为第一处理的起始(S2016、相当于重试点确定步骤)，向CGW13通知来自第一处理的起始的重试请求(S2017)，结束处理标志的判定处理。

改写对象ECU19若判定为第一处理标志为“OK”且第二处理标志为“NG”(S2014：“是”)，则将重试点确定为第二处理的起始(S2018、相当于重试点确定步骤)，向CGW13通知来自第二处理的起始的重试请求(S2019)，结束处理标志的判定处理。作为第二处理，ECU19例如向CGW13通知写入完成到哪个地址。

改写对象ECU19若判定为第一处理标志为“OK”且第二处理标志为“OK”(S2015：“是”)，则向CGW13通知与应用程序的改写相关联的处理的完成(S2020)，结束处理标志的判定处理。另外，在CGW13分割地分发写入数据的情况下，改写对象ECU19按照分割后的写入数据单位进行上述的重试点的设定。

像以上说明的那样，改写对象ECU19通过进行重试点的确定处理，而设定表示第一处理是否完成的第一处理标志，设定表示第二处理是否完成的第二处理标志，根据第一处理标志和第二处理标志来确定重试点。例如在第一处理完成且第二处理未完成的状态下改写对象ECU19被重新启动的情况下，能够抑制再次写入相同的写入数据。

另外，改写对象ECU19在预先存储完成了写入的写入数据的数据量、即将写入数据的写入完成到哪个字节，重新开始写入数据的写入的情况下，对CGW13请求从第几字节的写入数据起发送。改写对象ECU19在预先存储写入数据的写入完成到哪个字节，并重新开始的情况下，对CGW13请求从第几字节的写入数据起发送，由此在重新开始时，CGW13能够避免再次发送已发送的写入数据，改写对象ECU19能够从完成了写入数据的写入的下一写入区域对写入数据进行写入。另外，不具有这样的存储写入数据的写入完成到哪个字节的功能的改写对象ECU19在重新开始写入数据的写入的情况下，对CGW13请求从起始的写入数据起发送。

(21)进展状态的同步控制处理

参照图211至图216对进展状态的同步控制处理进行说明。车辆用程序改写系统1在CGW13和中心装置3中进行进展状态的同步控制处理。作为能够进行用户的输入操作的显示终端5，车辆用程序改写系统1具有便携终端6和车载显示器7。车载显示器7通过与CGW13的协作而显示表示改写的进展的进展画面。便携终端6通过与中心装置3连接，显示表示由中心装置3提供的改写的进展的进展画面。CGW13和中心装置3为了使在这些便携终端6和车载显示器7中显示的信息同步，而进行进展状态的同步控制处理。

如上述的图66所示，例如如果改写对象ECU19为搭载了2面存储器的ECU19，则根据告知应用程序的改写而得到用户的同意的活动通知阶段、执行从中心装置3向DCM12下载写入数据的下载阶段、执行从CGW13向改写对象ECU19分发写入数据的安装阶段、将下次启动时的启动面从旧面切换为新面的激活阶段，进行与应用程序的改写相关联的步骤。即，用户对便携终端6、车载显示器7进行操作，推进同意各阶段的执行等与应用程序的改写相关联的一系列的步骤。

如图211所示，CGW13在进展状态的同步控制部88中，具有第一进展状态判定部88a、第一进展状态发送部88b、第二进展状态获取部88c、以及第一显示指示部88d。第一进展状态判定部88a判定程序的改写所涉及的第一进展状态，例如判定活动通知阶段、下载阶段、安装阶段、激活阶段这样的进展状态。活动通知阶段是直到接收活动、显示图68～图69所示的画面、得到用户同意为止的阶段。下载阶段是显示图70～图73所示的画面，得到用户同意而执行下载的阶段。安装阶段是下载完成，显示图73～图78所示的画面，得到用户同意而执行安装的阶段。激活阶段是显示图79所示的画面，得到用户的同意而执行激活的阶段。

第一进展状态判定部88a若在用户乘车中，用户在车载显示器7中选择“同意程序更新的执行”，进行使阶段向下一步推进的操作，则通过将用户操作信号从车载显示器7向CGW13发送，而确定用户在车载显示器7中进行的操作，判定第一进展状态。在该情况下，选择“同意程序更新的执行”对应于对图70所示的“下载开始”按钮503a、图75所示的“立即更新”按钮506a、“预约更新”按钮506b、图79所示的“OK”按钮508b中的任意按钮进行操作。第一进展状态判定部88a若判定第一进展状态，则将该判定出的第一进展状态作为当前进展状态进行管理。

若通过第一进展状态判定部88a判定第一进展状态，则第一进展状态发送部88b向中心装置3发送该判定出的第一进展状态，并且向车载显示器7等各车载显示设备发送。第二进展状态获取部88c从中心装置3获取程序的改写所涉及的第二进展状态。若通过第一进展状态判定部88a判定第一进展状态，通过第二进展状态获取部获取第二进展状态，则第一显示指示部88d基于该判定出的第一进展状态和该获取的第二进展状态而指示在车载显示器7中能够显示的内容的制作。

这里，在第二进展状态获取部88c从中心装置3获取第二进展状态的情况下，如果第二进展状态是比当前进展状态靠前的阶段，则第一进展状态判定部88a将第二进展状态作为当前进展状态进行管理。即，利用第二进展状态的值更新第一进展状态。而且，第一进展状态发送部88b向中心装置3发送当前进展状态即第一进展状态。例如在第一进展状态为“等待下载阶段”中，进行了便携终端6中的用户同意操作的情况下，第二进展状态获取部88c从中心装置3获取“下载执行中阶段”来作为第二进展状态。由于从中心装置3获取的“下载执行中阶段”是比当前进展状态靠前的阶段，因此第一进展状态判定部88a利用第二进展状态的值更新当前进展状态即第一进展状态，并且向中心装置3发送该更新后的第一进展状态，并且向车载显示器7等各种车载显示设备发送。作为第一进展状态，除了“下载执行中阶段”之外，也可以发送表示下载的进展程度的“下载完成X％”。

在车载显示器7中产生了用户操作信号的情况下，第一显示指示部88d基于由第一进展状态判定部88a判定出的第一进展状态，而指示内容的制作。另外，在便携终端6中产生了用户操作信号的情况下，第一显示指示部88d基于由第二进展状态获取部88c获取的第二进展状态，而指示内容的制作。另外，如果采用管理为由第一进展状态判定部88a判定的第一进展状态始终为当前进展状态的结构、即采用主装置11管理当前进展状态的结构，则第一显示指示部88d只要基于第一进展状态来指示内容的制作即可。

如图212所示，中心装置3在进展状态的同步控制部53中，具有第二进展状态判定部53a、第二进展状态发送部53b、第一进展状态获取部53c、以及第二显示指示部53d。第二进展状态判定部53a判定程序的改写所涉及的第二进展状态，例如判定活动通知阶段、下载阶段、安装阶段、激活阶段这样的进展状态。若在用户下车中(驻车中)，用户在便携终端6中选择“同意程序更新的执行”，进行使阶段向下一步推进的操作，如果是便携终端6与中心装置3能够进行数据通信的环境，则第二进展状态判定部53a接收从便携终端6发送的用户操作信号。

第二进展状态判定部53a基于在此前由第一进展状态获取部53c从主装置11接收到的第一进展状态即当前进展状态和户操作信号，而判定第二进展状态。第二进展状态判定部53a例如若在当前进展状态为“等待安装阶段”时，接收表示“同意”的用户操作信号，则作为第二进展状态，判定为“安装执行中阶段”。另外，第二进展状态判定部53a也可以是“在等待安装阶段中有用户同意”这样的判定。如果是中心装置3与DCM12能够进行数据通信的环境，则从中心装置3向DCM12发送便携终端6的用户操作信号。而且，通过从DCM12向CGW13传输用户操作信号，CGW13能够判定用户在便携终端6中进行的操作，判定进展状态。

第二进展状态发送部53b若通过第二进展状态判定部53a判定第二进展状态，则向主装置11发送该判定出的第二进展状态。第一进展状态获取部53c从主装置11获取程序的改写所涉及的第一进展状态，作为当前进展状态进行管理。作为当前进展状态，也可以利用第一进展状态的值更新第二进展状态。第二显示指示部53d若通过第二进展状态判定部53a判定第二进展状态，通过第一进展状态获取部53d获取第一进展状态，则基于该判定出的第二进展状态和该获取的第一进展状态，而指示在便携终端6中能够显示的内容的制作。

例如如果仅是便携终端6的用户操作信号，则由第二进展状态判定部53a判定的第二进展状态与由第一进展状态获取部53d获取的第一进展状态表示相同的进展状态。因此，第二显示指示部53d也可以基于第二进展状态而指示内容的制作。然后，在产生了车载显示器7中的用户操作信号的情况下，第二显示指示部53d基于所获取的第一进展状态而指示内容的制作。

便携终端6例如若从中心装置3接收SMS来作为进展状态信号，则由用户选择记载于SMS的URL而与中心装置3连接，显示由中心装置3提供的规定阶段的画面。

接下来，参照图213至图216来说明CGW13中的进展状态的同步控制部88和中心装置3中的进展状态的同步控制部53的作用。

如图213所示，主装置11和中心装置3通过发送接收第一进展状态信号和第二进展状态信号，而使便携终端6和车载显示器7中的阶段的进展状态的显示同步。即，主装置11若更新当前进展状态即第一进展状态，则向中心装置3发送第一进展状态信号，并且向车载显示器7等各种车载显示设备发送第一进展状态信号。中心装置3将第一进展状态信号作为当前进展状态而向便携终端6发送。由此，如果便携终端6能够访问中心装置3，则使便携终端6和车载显示器7中的阶段的进展状态的显示同步。中心装置3基于便携终端6的用户同意操作而向主装置11发送第二进展状态信号，由此如果便携终端6能够访问中心装置3，则使便携终端6和车载显示器7中的阶段的进展状态的显示同步。

获取了第二进展状态信号的主装置11也可以在更新了当前进展状态即第一进展状态之后，向中心装置3和车载显示器7等各车载显示设备发送第一进展状态。即，通过由主装置11向中心装置3和车载显示器7等各车载显示设备发送当前进展状态，而实现作为阶段的管理装置的功能。这里，从便携终端6、车载显示器7和中心装置3发送的第二进展状态信号可以是表示某个阶段的通知，但也可以是表示存在用户同意操作的内容的通知、表示被操作的按钮的意向的通知。

CGW13若开始进展状态的同步控制处理，则向车载显示器7发送分发规格数据(S2101)。分发规格数据中包含车载显示器7朝向用户显示的文本、内容。CGW13基于来自车载显示器7或者中心装置3的通知而判定用户在车载显示器7或者便携终端6中是否进行了操作(S2102)。CGW13若判定为用户在车载显示器7或者便携终端6中进行了操作(S2102：“是”)，则基于第一进展状态，判定该操作是哪个阶段的操作(S2103～S2106、相当于第一进展状态判定步骤)。

CGW13若判定为是活动通知阶段(S2103：“是”)，则实施活动通知阶段的处理(S2107)，向车载显示器7和中心装置3发送表示该活动通知阶段的处理的进展状态的第一进展状态信号(S2111)。活动通知阶段的处理是指获取针对车载显示器7或者便携终端6的用户的输入操作等。

CGW13例如从车载显示器7、或者便携终端6经由中心装置3，除了获取同意或者不同意程序的更新之外，还获取允许执行的时间、场所等条件等。CGW13若从中心装置3经由DCM12获取到在便携终端6中存在同意的内容的用户的输入操作的情况，则向车载显示器7通知完成了同意的内容的进展。另一方面，CGW13若从车载显示器7获取到在车载显示器7中存在同意的内容的用户的输入操作的情况，则向中心装置3通知完成了同意的内容的进展。

CGW13若判定为是下载阶段(S2104：“是”)，则实施下载阶段的处理(S2108)，向车载显示器7和中心装置发送表示该下载阶段的处理的进展状态的第一进展状态信号(S2111)。下载阶段的处理例如是指计算分发包的下载完成了几％。

CGW13基于来自中心装置3的通知而决定下载完成了几％。CGW13向车载显示器7和中心装置3通知表示下载完成了几％的进展。CGW13重复这些处理直到分发包的下载完成为止。CGW13若下载完成，则向车载显示器7和中心装置3通知下载阶段完成的内容的进展。

CGW13若判定为是安装阶段(S2104：“是”)，则实施安装阶段的处理(S2108)，向车载显示器7和DCM12发送表示该安装阶段的处理的进展状态的进展状态信号(S2111)。安装阶段的处理例如是指计算向改写对象ECU19的安装完成了几％。

CGW13基于来自改写对象ECU19的通知而决定安装完成了几％。CGW13向车载显示器7和中心装置3通知表示安装完成了几％的进展。CGW13重复这些处理直到针对全部的改写对象ECU19的安装完成为止。CGW13若安装全部完成，则向车载显示器7和中心装置3通知安装阶段完成的内容的进展。

CGW13若判定为是激活阶段(S2104：“是”)，则实施激活阶段的处理(S2108)，向车载显示器7和DCM12发送表示该激活阶段的处理的进展状态的进展状态信号(S2111、相当于第一进展状态发送步骤)。激活阶段的处理例如是指计算属于同一组的一个以上的改写对象ECU19的激活完成了几％。CGW13基于来自改写对象ECU19的通知而决定激活完成了几％。CGW13向车载显示器7和中心装置通知表示激活完成了几％的进展。

CGW13判定是否完成了激活阶段(S2112)，若判定为完成了激活阶段(S2112：“是”)，则结束进展状态的同步控制处理。CGW13若判定为未完成激活阶段(S2112：“否”)，则返回S2102。而且，CGW13推进各阶段的处理，并且计算处理完成了几％(S2107～S2110)。CGW13定期地向中心装置3发送阶段和完成了X％的内容来作为第一进展状态(S2111)。

中心装置3若发送分发规格数据，开始进展状态的同步控制处理，则监视从DCM12发送的第一进展状态信号的接收(S2121)。中心装置3若判定为从DCM12接收到第一进展状态信号(S2121：“是”)，则允许来自便携终端6的访问(S2122)，判定根据第一进展状态信号确定的阶段是哪个阶段(S2123～S2126)。

中心装置3若判定为是活动通知阶段(S2123：“是”)，则实施活动通知阶段的处理(S2127)。即，中心装置3制作活动通知阶段的画面，并且向便携终端6发送指示该活动通知阶段的画面的显示的显示指示信号，在便携终端6中通过与中心装置3的连接来显示活动通知阶段的画面。

中心装置3若判定为是下载阶段(S2124：“是”)，则实施下载阶段的处理(S2128)。即，中心装置3制作下载阶段的画面，并且向便携终端6发送指示下载阶段的画面的显示的显示指示信号，在便携终端6中通过与中心装置3的连接来显示下载阶段的画面。中心装置3若被DCM12通知表示下载完成了几％的进展，则更新下载阶段的画面。

中心装置3若判定为是安装阶段(S2125：“是”)，则实施安装阶段的处理(S2129)。即，中心装置3制作安装阶段的画面，并且向便携终端6发送指示安装阶段的画面的显示的显示指示信号，在便携终端6中通过与中心装置3的连接来显示安装阶段的画面。中心装置3若被DCM12通知表示安装完成了几％的进展，则更新安装阶段的画面。

中心装置3若判定为是激活阶段(S2126：“是”)，则实施激活阶段的处理(S2130)。即，中心装置3制作激活阶段的画面，并且向便携终端6发送指示激活阶段的画面的显示的显示指示信号，在便携终端6中通过与中心装置3的连接来显示激活阶段的画面。中心装置3若被DCM12通知表示激活完成了几％的进展，则更新激活阶段的画面。中心装置3在对S2127～S2130中显示的画面进行了用户同意等操作的情况下，向主装置11发送第二进展状态信号(S2131)，结束进展状态的同步控制处理。

车载显示器7若从CGW13接收分发规格数据，则开始进展显示处理，监视从CGW13发送的进展状态信号的接收(S2141)。车载显示器7若判定为从CGW13接收到进展状态信号(S2141：“是”)，则允许车载显示器7中的用户操作(S2142)，判定根据进展状态信号确定的阶段是哪个阶段(S2143～S2146)。

车载显示器7若判定为是活动通知阶段(S2143：“是”)，则使用在分发规格数据中包含的文本、内容等而显示活动通知阶段的画面(S2147)。车载显示器7若判定为是下载阶段(S2144：“是”)，则显示下载阶段的画面(S2148)。车载显示器7若被CGW13通知表示下载完成了几％的进展，则更新下载阶段的画面。

车载显示器7若判定为是安装阶段(S2145：“是”)，则显示安装阶段的画面(S2149)。车载显示器7若被CGW13通知表示安装完成了几％的进展，则更新安装阶段的画面。车载显示器7若判定为是激活阶段(S2146：“是”)，则显示激活阶段的画面(S2150)。车载显示器7若被CGW13通知表示激活完成了几％的进展，则更新激活阶段的画面。

像以上说明的那样，在主装置11与中心装置3之间发送接收第一进展状态和第二进展状态。例如即使是便携终端6能够访问中心装置3，车载显示器7不能访问中心装置3的结构，通过在主装置11与中心装置3之间发送接收第一进展状态和第二进展状态，能够使应用程序的改写的进展状态等在多个显示终端适当地同步。

(22)显示控制信息的发送控制处理、(23)显示控制信息的接收控制处理

参照图181和图182对中心装置3中的显示控制信息的发送控制处理进行说明，参照图183至图185对主装置11中的显示控制信息的接收控制处理进行说明。

如图217所示，中心装置3在显示控制信息的发送控制部54中，具有写入数据存储部54a(相当于更新数据存储部)、显示控制信息存储部54b、以及信息发送部54c。写入数据存储部54a将针对多个改写对象ECU19的应用程序的改写作为一个活动，存储针对多个改写对象ECU19的写入数据。显示控制信息存储部54b存储包含显示控制信息的分发起始数据。显示控制信息是在车载显示器7中显示与改写对象ECU19中的应用程序的改写相关联的显示信息所需要的信息，是显示控制程序、属性信息。

显示信息是指构成与应用程序的改写相关联的各种画面(活动通知画面、安装画面等)的数据。显示控制程序是实现与网络浏览器同等的功能的程序。属性信息是规定显示文字、显示位置、颜色等的信息。信息发送部54c向主装置11发送存储于写入数据存储部54a的写入数据和存储于显示控制信息存储部54b的显示控制信息。信息发送部54c将针对多个改写对象ECU19的写入数据作为一个包而向主装置11发送。这里，作为显示控制信息，也可以包含表示是在哪个阶段显示的信息的阶段识别信息。例如是表示是在活动通知阶段、下载阶段、安装阶段和激活阶段中的哪个阶段显示的信息的阶段识别信息。

接下来，参照图218来说明中心装置3中的显示控制信息的发送控制部54的作用。中心装置3执行显示控制信息的发送控制程序，进行显示控制信息的发送控制处理。

中心装置3若开始显示控制信息的发送控制处理，则经由DCM12向CGW13发送分发起始数据(S2201、相当于控制信息发送步骤)，经由DCM12向CGW13发送写入数据(S2202)。中心装置3经由DCM12向CGW13发送显示信息(S2203、相当于显示信息发送步骤)，结束显示控制信息的发送控制处理。另外，中心装置3在发送与活动通知阶段、下载阶段、安装阶段、激活阶段的各阶段对应的显示控制信息的情况下，也可以将与各阶段对应的显示控制信息集中为一个文件而向车载显示器7发送，也可以在每次结束阶段时向车载显示器7发送与下一阶段对应的显示控制信息。这里，中心装置3发送分发起始数据的时机可以构成为根据来自主装置11的请求来发送。

如图219所示，CGW13在显示控制信息的接收控制部89中，具有信息接收部89a、改写指示部89b、以及显示指示部89c。信息接收部89a从中心装置3接收写入数据和显示控制信息。若通过信息接收部89a从中心装置3接收写入数据，则改写指示部89b向改写对象ECU19指示该接收到的写入数据的写入。在改写指示部89b向改写对象ECU19指示写入数据的写入之前，显示指示部89c向车载显示器7指示使用显示控制信息而显示与活动相关的信息。另外，显示指示部89c也可以在写入数据的写入全部完成之后，指示作为历史信息显示与活动相关的信息。

接下来，参照图220来说明CGW13中的显示控制信息的接收控制部89的作用。CGW13执行显示控制信息的接收控制程序，进行显示控制信息的接收控制处理。由此，在作为显示终端，具有便携终端6和车载显示器7的情况下，能够使这些显示方式接近，能够提高用户的便利性。

CGW13若开始显示控制信息的接收控制处理，则从中心装置3经由DCM12接收分发规格数据(S2301、相当于控制信息接收步骤)。从中心装置3经由DCM12接收写入数据(S2302)。CGW13从中心装置3经由DCM12接收显示信息(S2303、相当于显示信息接收步骤)。CGW13判定是否使用来自中心装置3的分发规格数据中包含的显示控制信息(S2304)。CGW13若判定为使用显示控制信息(S2304：“是”)，则向车载显示器7指示使用显示控制信息对显示信息进行显示(S2305)。即，CGW13向车载显示器7指示使用显示控制信息而显示与应用程序的改写相关联的画面。车载显示器7根据来自CGW13的指示，使用显示控制信息对显示信息进行显示。

CGW13若判定为不使用显示控制信息(S2304：“否”)，则向车载显示器7指示使用预先保存的内容对显示信息进行显示(S2306)。即，CGW13向车载显示器7指示使用预先保存的内容而显示与应用程序的改写相关联的画面。车载显示器7根据来自CGW13的指示，使用预先保存的内容对显示信息进行显示。另外，车载显示器7在显示与活动通知阶段、下载阶段、安装阶段、激活阶段的各阶段对应的显示信息的情况下，也可以将与各阶段对应的显示控制信息集中而从中心装置3接收，也可以每次结束阶段时从中心装置3接收与下一阶段对应的显示控制信息。

如图221所示，如果车载显示器7不具有网络浏览器的功能，在从中心装置3经由DCM12和CGW13向车载显示器7发送的发规格数据中包含属性信息但不包含显示控制程序，则车载显示器7使用预先保存的内容、帧，作为显示信息，在简易的画面显示属性信息。属性信息是指文本等数据及其显示位置、大小等，与由中心装置3制作的画面中使用的属性信息相同。即，车载显示器7显示的画面影像与中心装置3制作的画面影像在背景、位图等存在不同点，但显示内容与中心装置3同等。

如果车载显示器7不具有网络浏览器的功能，在从中心装置3经由DCM12和CGW13向车载显示器7发送的分发规格数据中包含显示控制程序和属性信息，则车载显示器7利用与中心装置3同等的画面对显示信息进行显示。这里，在分发规格数据中包含的显示控制程序和属性信息与在中心装置3制作的画面中使用的内容相同。

如果车载显示器7不具有网络浏览器的功能但保存有显示控制程序，在从中心装置3向车载显示器7发送的分发规格数据中包含属性信息，则车载显示器7在与中心装置3同等的画面显示显示信息。这里，车载显示器7保存的显示控制程序例如与在中心装置3制作的画面中使用的显示控制程序在版本方面不同。

如果车载显示器7具有网络浏览器的功能，则车载显示器7通过与中心装置连接而在与中心装置3相同的画面显示显示信息。

像以上说明的那样，中心装置3通过进行显示控制信息的发送控制处理，而向车载显示器7发送显示控制信息，根据显示控制信息而在车载显示器7中对显示信息进行显示。由此，在作为显示终端，具有便携终端6和车载显示器7的情况下，能够使这些显示方式接近，能够提高用户的便利性。CGW13通过进行显示控制信息的接收控制处理，而从中心装置3接收显示控制信息，从中心装置3接收显示信息，根据显示控制信息对显示信息进行显示。

(24)进展显示的画面显示控制处理

参照图222至图246对进展显示的画面显示控制处理进行说明。车辆用程序改写系统1在CGW13中进行进展显示的画面显示控制处理。

如图222所示，CGW13在进展显示的画面显示控制部90中，具有模式判定部90a和画面显示指示部90b。

模式判定部90a判定是否通过用户的自定义操作而设定自定义模式。另外，模式判定部90a根据在改写规格数据中包含的场景信息来判定是否设定有来自外部的外部模式。即，模式判定部90a参照图44所示的改写规格数据中包含的场景信息。如图44和图223所示，在改写规格数据中储存有场景信息、有效期限信息、位置信息。场景信息表示本更新的场景(种类、场面等)，并且指定本更新的画面显示。具体而言，存在召回标志、经销商标志、工厂用标志、功能更新通知标志、强制执行标志。

召回标志是指定根据召回进行应用程序的改写的情况下的画面显示的标志。召回是指在判明由于设计、制造上的过错等而在制品中存在缺陷的情况下，根据法令的规定或者制造者、销售者的判断进行无偿修理、更换、回收等措施。

经销商标志是指定在经销商进行应用程序的改写的情况下的画面显示的标志。工厂用标志是指定在工厂进行应用程序的改写的情况下的画面显示的标志。功能更新通知标志是指定在根据功能更新通知进行应用程序的改写的情况下的画面显示的标志。功能更新通知是指更新特定的功能。例如功能更新通知标志是指定用于有偿(或者无偿)追加新的功能的程序更新中的画面显示的标志。

强制执行标志是指定在根据强制执行进行应用程序的改写的情况下的画面显示的标志。强制执行是指虽然重复规定次数的活动通知，但不进行该应用程序的改写因而强制地进行应用程序的改写。例如强制执行标志是指定在强制地进行程序更新的情况下的画面显示的标志。

表示这些场景信息的标志被设定为，在不相应的情况下全部为0(标志不成立)，在相应的情况下任一个为1(标志成立)。模式判定部90a例如在召回标志成立时，判定为设定召回模式，在经销商标志成立时，判定为设定经销商模式，在工厂标志成立时，判定为设定工厂模式，在功能更新通知标志成立时，判定为设定功能更新模式，在强制执行标志成立时，判定为设定强制执行模式。

有效期限信息是表示有效期限的信息，是成为是否执行应用程序的改写的判定基准的信息。如果当前时刻在有效期限信息所示的有效期限内，则CGW13执行应用程序的改写，如果当前时刻在有效期限信息所示的有效期限外，则CGW13不执行应用程序的改写。即，CGW13在下载了分发包之后，在进行程序的安装时参照有效期限信息，如果当前时刻在有效期限外，则不执行程序的安装，而放弃分发包。

位置信息是表示位置的信息，是成为是否执行应用程序的改写的判定基准的信息，存在允许区域和禁止区域。在指定允许区域作为位置信息的情况下，如果车辆的当前位置在位置信息所示的允许区域内，则CGW13执行应用程序的改写，如果车辆的当前位置在位置信息所示的允许区域外，则CGW13不执行应用程序的改写。在指定禁止区域作为位置信息的情况下，如果车辆的当前位置在位置信息所示的禁止区域外，则CGW13执行应用程序的改写，如果车辆的当前位置在位置信息所示的禁止区域内，则CGW13不执行应用程序的改写。即，CGW13在下载分发包之后，在进行程序的安装时参照位置信息，如果当前位置在允许区域外，则不执行程序的安装，等待安装直到处于允许区域内为止。

画面显示指示部90b向显示终端5指示与应用程序的改写对应的画面显示。画面显示指示部90b通过指示与应用程序的改写的阶段对应的画面的显示有无、指示画面的项目的显示有无、指示画面的项目的显示内容的变更，而向显示终端5指示画面显示。

对用户的自定义操作进行说明。另外，这里，对车载显示器7显示的画面进行说明，但便携终端6显示的画面也相同。另外，在后述的画面中，按钮的个数、配置等布局也可以是例示以外的布局。若用户在车载显示器7中进行菜单画面的显示操作，则如图224所示，CGW13使车载显示器7显示菜单选择画面511。CGW13在菜单选择画面511中，显示“软件更新”按钮511a、“更新结果确认”按钮511b、“软件版本一览”按钮511c、“更新历史”按钮511d、以及“用户信息登记”按钮511e，等待用户的操作。

若用户从该状态操作“用户信息登记”按钮511e，则如图225所示，CGW13使车载显示器7显示用户选择画面512。CGW13在用户选择画面512中显示“用户”按钮512a～512c，等待用户的操作。

若用户从该状态操作“用户”按钮512a，则如图226所示，CGW13使车载显示器7显示用户登记画面513。CGW13在用户登记画面513中，作为个人信息登记，显示邮件地址和VIN信息(单车识别信息)的输入栏，作为收费信息登记显示信用卡号和有效期限的输入栏，作为应用程序的改写设定显示活动通知、下载、安装、激活的“接通断开”按钮513a～513d，显示“详细信息”按钮513e，等待用户的操作。

活动通知、下载、安装、激活的“接通断开”按钮513a～513d是选择对于活动通知、下载、安装、激活是否进行画面显示的按钮。具体而言，是在接收到活动通知时、开始下载时、开始安装时、开始激活时，使用户预先选择是否进行请求用户同意的内容显示的按钮。“详细信息”按钮513e是登记上述的有效期限信息和位置信息的按钮。这些用户设定的信息经由DCM12向中心装置3发送。另外，在用户利用便携终端6设定了这些信息的情况下，CGW13经由DCM12从中心装置3获取这些信息。

如果用户对于活动通知、下载、安装、激活的画面感到烦躁的情况下，只要将该“接通断开”按钮513a～513d设定为断开即可。通过设定为断开，而省略请求用户同意的内容的显示。用户例如如果对于活动通知、激活的画面显示未感到烦躁，但对于下载、安装的画面显示感到烦躁的情况下，只要通过“接通断开”按钮513a将活动通知设定为接通，通过“接通断开”按钮513b将下载设定为断开，通过“接通断开”按钮513c将安装设定为断开，通过“接通断开”按钮513d将激活设定为接通即可。

在该情况下，例如如果将活动通知设定为接通，将下载设定为断开，将安装设定为断开，将激活设定为接通，则显示终端5根据应用程序的改写阶段，显示活动通知画面，不显示下载同意画面和下载执行中画面，不显示安装同意画面和安装执行中画面，显示激活画面。即，如果用户在活动通知、下载、安装、激活的阶段中，设定为接通，则进行设定为该接通的阶段的画面显示，如果设定为断开，则不进行设定为该断开的阶段的画面显示，能够自定义画面显示。关于这样的画面显示的接通断开的设定，可以是按照每个阶段独立地设定，也可以是将全部的阶段一并地一次性设定。

另外，如果在用户希望登记有效期限、允许区域、禁止区域的情况下，只要操作“详细信息”按钮513e，设定有效期限、允许区域、禁止区域即可。用户能够自定义允许应用程序的改写的有效期限作为有效期限信息，能够自定义允许应用程序的改写的允许区域、禁止应用程序的改写的禁止区域作为位置信息。

接下来，参照图227至图250对上述的结构的作用进行说明。CGW13执行进展显示的画面显示控制程序，进行进展显示的画面显示控制处理。

CGW13若开始进展显示的画面显示控制处理，则判定在改写规格数据中是否储存有效期限信息，以及在自定义信息中是否设定有效期限信息(S2401)。CGW13若判定为在改写规格数据中储存有效期限信息(S2401：“是”)，则判定当前时刻是否满足有效期限信息(S2402)。在存在储存于改写规格数据的有效期限信息和设定为自定义信息的有效期限信息的情况下，CGW13判定是否满足双方。CGW13若判定为当前时刻在有效期限信息所示的有效期限外，当前时刻不满足有效期限信息(S2402：“否”)，则结束进展显示的画面显示控制处理。

CGW13若判定为当前时刻在有效期限信息所示的有效期限内，当前时刻满足有效期限信息(S2402：“是”)，则判定在改写规格数据中是否储存有场景信息(S2403)。CGW13若判定为在改写规格数据中储存有场景信息(S2403：“是”)，则判定为设定有外部模式，转移至按照该场景信息的设定内容的显示指示处理(S2404)，向车载显示器7指示根据该成立的标志的模式进行与应用程序的改写对应的画面显示。例如如果召回标志成立，则CGW13向车载显示器7指示根据召回模式进行与应用程序的改写中对应的画面显示。例如如果经销商标志成立，则CGW13向车载显示器7指示根据经销商模式进行与应用程序的改写中对应的画面显示。

CGW13若判定为在改写规格数据中未储存场景信息(S2403：“否”)，则判定是否通过用户的自定义操作设定有自定义模式(S2405、相当于自定义模式判定步骤)。CGW13若判定为设定有自定义模式(S2405：“是”)，则转移至按照自定义操作的设定内容的显示指示处理(S2406、相当于画面显示指示步骤)，向车载显示器7指示根据自定义模式进行与应用程序的改写对应的画面显示。

CGW13若判定为未设定自定义模式(S2405：“否”)，则转移至按照初始设定的设定内容的显示指示处理(S2407、相当于画面显示指示步骤)，向车载显示器7指示根据自定义模式进行与应用程序的改写对应的画面显示。即，CGW13优先应用储存于改写规格数据的场景信息，在未储存场景信息时，应用自定义模式。在场景信息和自定义模式都不存在的情况下，应用初始设定。这里，初始设定是指预先设定的值，例如活动通知、下载、安装和激活的设定都设为接通的设定作为初始设定。

接着，使用图228，对S2404、S2406和S2407的画面显示指示处理进行说明。这里，例示了安装阶段中的画面显示指示处理，但其他的阶段也相同。CGW13若转移至显示指示处理，则设定画面的显示有无(S2411)，设定画面的项目的显示有无(S2412)，指示画面的项目的显示内容的变更(S2413)。CGW13向DCM12发送画面显示请求通知，从DCM12向车载显示器7发送画面显示请求(S2414)，等待从DCM12接收操作结果信息(S2415)。操作结果信息是指表示用户操作了哪个按钮的信息。另外，CGW13也可以向车载显示器7直接发送画面显示请求通知，接收操作结果信息。

CGW13若通过从车载显示器7向DCM12发送操作结果，而判定出从DCM12接收操作结果信息(S2415：“是”)，则基于该操作结果信息来进行同意确认，判定用户是否同意了应用程序的改写(S2416)。

CGW13若判定为用户同意了应用程序的改写(S2416：“是”)，则判定在改写规格数据中是否储存有位置信息(S2417)。CGW13若判定为在改写规格数据中储存有位置信息(S2417：“是”)，则判定车辆的当前位置是否满足位置信息(S2418)。另外，在安装阶段以外的阶段，也可以省略S2417和S2418。在位置信息为允许区域的情况下，如果车辆的当前位置在允许区域内，则CGW13判定为车辆的当前位置满足位置信息(S2418：“是”)，持续应用程序的改写(S2419)。

另一方面，如果车辆的当前位置在允许区域外，则CGW13判定为车辆的当前位置不满足位置信息，中止应用程序的改写而不持续，结束画面显示指示处理。在位置信息为禁止区域的情况下，如果车辆的当前位置在禁止区域外，则CGW13判定为车辆的当前位置满足位置信息(S2418：“是”)，持续应用程序的改写(S2419)，结束画面显示指示处理。如果车辆的当前位置在禁止区域内，则CGW13判定为车辆的当前位置不满足位置信息，中止应用程序的改写而不持续，结束显示指示处理。

对从CGW13向DCM12发送的画面显示请求通知、从DCM12向CGW13发送的操作结果信息进行说明。如图229所示，从CGW13向DCM12发送的画面显示请求通知中包含阶段ID、场景ID、画面结构信息。阶段ID是指对活动通知、下载、安装、激活这样的各阶段进行识别的ID。场景ID是指对图223所示的场景信息进行识别的ID。从DCM12向CGW13发送的操作结果信息中包含发送源信息、阶段ID、场景ID、操作结果、追加信息。CGW13对储存于画面显示请求通知的阶段ID和场景ID与储存于操作结果信息的阶段ID和场景ID进行对照，进行背离、调停的确认。

即，如果在发送到DCM12的画面显示请求通知中储存的阶段ID和场景ID与在从DCM12接收到的操作结果信息中储存的阶段ID和场景ID一致，则CGW13判定为画面显示请求通知与操作结果信息整合，画面显示请求通知与操作结果信息不背离，不需要进行调停。另一方面，如果在发送到DCM12的画面显示请求通知中储存的阶段ID和场景ID与在从DCM12接收到的操作结果信息中储存的阶段ID和场景ID不一致，则CGW13判定为画面显示请求通知与操作结果信息不整合，画面显示请求通知与操作结果信息背离，需要进行调停。CGW13进行根据从DCM12接收到的操作结果信息是否进行处理这样的调停。

画面结构信息是表示画面的结构要素的信息，如图230所示，例如在激活同意画面514中，存在“活动ID…”按钮514a、“更新名称A…”按钮514b、“更新名称B…”按钮514c、“详情确认”按钮514d、“返回”按钮514e、以及“OK”按钮514f这6个项目。在该情况下，如图231所示，如果画面结构信息的6个项目的全部被设定为“显示”，则如图230所示，在激活同意画面514显示6个项目的全部。即，用户能够操作“活动ID…”按钮514a、“更新名称A…”按钮514b、“更新名称B…”按钮514c、“详情确认”按钮514d、“返回”按钮514e、“OK”按钮514f中的任意一个。

另一方面，如图232所示，如果画面结构信息的6个项目中的“活动ID…”按钮514a、“更新名称A…”按钮514b、“更新名称B…”按钮514c、“详细信息”按钮514d、“OK”按钮514f被设定为“显示”，“返回”按钮514e被设定为不显示，则如图233所示，在激活同意画面514显示“活动ID…”按钮514a、“更新名称A…”按钮514b、“更新名称B…”按钮514c、“详细信息”按钮514d、“OK”按钮514f，另一方面，不显示“返回”按钮514e。即，用户能够操作“活动ID…”按钮514a、“更新名称A…”按钮514b、“更新名称B…”按钮514c、“详情确认”按钮514d、“OK”按钮514f中的任意一个，不显示“返回”按钮514e，因此不能操作“返回”按钮514e。例如对于基于召回等的重要度、紧急度比较高的应用程序的改写，不希望拒绝该激活，因此通过像上述那样使“返回”按钮514e不能操作，能够设定为不拒绝该激活。在该情况下，通过由用户操作“OK”按钮514f，而同意激活。

对在与CGW13、DCM12、车载显示器7、中心装置3、仪表装置45之间发送接收的画面显示、与用户操作相关的消息帧工作进行说明。如图234所示，CGW13与DCM12利用CAN、以太网连接，DCM12与车载显示器7利用USB连接。

CGW13经由DCM12而在与中心装置3之间进行数据通信。从CGW13通过诊断通信发送来的数据在DCM12进行协议变换，从DCM12通过HTTP通信而由中心装置3接收。例如CGW13经由DCM12向中心装置3发送表示当前的阶段、进展比例等当前进展状态的数据。从中心装置3通过HTTP通信发送来的数据在DCM12进行协议变换，从DCM12通过诊断通信而由CGW13接收。

CGW13经由DCM12在与车载显示器7之间进行数据通信。从CGW13通过诊断通信发送来的数据在DCM12进行协议变换，从DCM12通过USB通信而由车载显示器7接收。从车载显示器7通过USB通信发送来的数据在DCM12进行协议变换，从DCM12通过诊断通信而由CGW13接收。例如CGW13经由DCM12获取与车载显示器7中的用户操作相关的信息。这样，在车辆用程序改写系统1中，构成为使DCM12具有协议变换功能，CGW13同样地处理便携终端6和车载显示器7。另外，通过将与用户操作相关的信息向CGW13汇总，从而CGW13对多个操作终端中的用户操作结果进行调停，能够管理当前进展状态。

对在与CGW13、DCM12、车载显示器7之间发送接收的消息帧的顺序进行说明。如图235至图242所示，在从CGW13向DCM12发送的画面显示请求通知、从DCM12向CGW13发送的操作结果信息中，在活动通知中将阶段ID设为“03”，在下载中将阶段ID设为“04”，在安装中将阶段ID设为“05”，在激活中将阶段ID设为“06”。在活动通知、下载、安装和激活的各阶段中，使消息帧的发送接收的顺序相同，通过使阶段ID不同来区分阶段。

在图235中例示了活动通知阶段。CGW13管理当前进展状态，指定阶段ID、场景ID和画面结构信息，向DCM12发送画面显示请求通知。DCM12若从CGW13接收画面显示请求通知，则向车载显示器7发送画面显示请求。车载显示器7若从DCM12接收画面显示请求，则显示活动通知时的画面，若用户进行活动通知的确认操作，则向DCM12发送其操作结果。DCM12若从车载显示器7接收操作结果，则向CGW13发送操作结果信息。在由CGW13接收的操作结果信息中指定了发送源信息、阶段ID、场景ID、操作结果和追加信息。CGW13基于从DCM12接收到的操作结果信息而更新当前进展状态。这里，在活动通知阶段中存在同意操作的情况下，CGW13将当前进展状态更新为下载阶段。

在图236中，例示了下载阶段。CGW13管理当前进展状态，指定阶段ID、场景ID和画面结构信息，向DCM12发送画面显示请求通知。DCM12若从CGW13接收画面显示请求通知，则向车载显示器7发送画面显示请求。车载显示器7若从DCM12接收画面显示请求，则显示下载同意时的画面，若用户进行下载的同意操作，则向DCM12发送该操作结果。DCM12若从车载显示器7接收操作结果，则向CGW13发送操作结果信息。在由CGW13接收的操作结果信息中，指定了发送源信息、阶段ID、场景ID、操作结果和追加信息。CGW13基于从DCM12接收到的操作结果信息而更新当前进展状态。这里，在下载阶段中存在同意操作的情况下，CGW13将当前进展状态更新为安装阶段。

在图237中，例示了安装阶段。CGW13管理当前进展状态，指定阶段ID、场景ID和画面结构信息，向DCM12发送画面显示请求通知。DCM12若从CGW13接收画面显示请求通知，则向车载显示器7发送画面显示请求。车载显示器7若从DCM12接收画面显示请求，则显示安装同意时的画面，若用户进行安装的同意操作，则向DCM12发送其操作结果。DCM12若从车载显示器7接收操作结果，则向CGW13发送操作结果信息。在由CGW13接收的操作结果信息中，指定了发送源信息、阶段ID、场景ID、操作结果和追加信息。CGW13基于从DCM12接收到的操作结果信息而更新当前进展状态。这里，在安装阶段中存在同意操作的情况下，CGW13将当前进展状态更新为激活阶段。

在图238中，例示了激活阶段。CGW13管理当前进展状态，指定阶段ID、场景ID和画面结构信息，向DCM12发送画面显示请求通知。DCM12若从CGW13接收画面显示请求通知，则向车载显示器7发送画面显示请求。车载显示器7若从DCM12接收画面显示请求，则显示激活同意时的画面，若用户进行激活的同意操作，则向DCM12发送其操作结果。DCM12若从车载显示器7接收操作结果，则向CGW13发送操作结果信息。在由CGW13接收的操作结果信息中，指定了发送源信息、阶段ID、场景ID、操作结果和追加信息。CGW13基于从DCM12接收到的操作结果信息而更新当前进展状态。

参照图239至图246对画面显示进行说明。在没有设定自定义模式，在改写规格数据的场景信息中没有设定任何标志的情况下，CGW13根据初始设定的内容而对显示终端5指示与应用程序的改写对应的画面显示(S2407)。如果初始设定是将活动通知、下载、安装、激活全部接通的设定，则如上述的图67至图82所示，CGW13对显示终端5指示画面显示，以依次显示导航画面501、活动通知画面502、下载同意画面503、下载执行中画面504、下载完成通知画面505、安装同意画面506、安装执行中画面507、激活同意画面508、激活完成通知画面509、确认操作画面510。此时，在活动通知画面502、下载同意画面503、安装同意画面506、激活同意画面508、确认操作画面510中，显示用于得到用户的同意(OK)的内容。

在设定有用户的自定义模式的情况下，CGW13根据自定义模式的内容而向显示终端5指示与应用程序的改写对应的画面显示(S2406)。但是，限于未指定场景信息的情况。例如如果在自定义模式中将活动通知设定为接通，将下载设定为断开，将安装设定为断开，将激活设定为接通，则CGW13向显示终端5指示画面显示，以使得在显示了活动通知画面502之后，不显示下载同意画面503、下载执行中画面504、下载完成通知画面505、安装同意画面506和安装执行中画面507，显示激活同意画面508。

在改写规格数据的场景信息中设定了召回标志的情况下，CGW13根据召回模式的内容而向显示终端5指示与应用程序的改写对应的画面显示(S2404)。在该情况下，如图240所示，CGW13在活动通知画面502中，使“以后”按钮502a不显示。另外，如图241和图242所示，CGW13在下载同意画面503中，使“返回”按钮503c不显示。另外，如图243所示，CGW13在下载执行中画面504中，使“返回”按钮504b不显示。另外，如图244和图245所示，CGW13在安装同意画面505中，使“返回”按钮505b不显示。另外，如图246所示，CGW13在激活同意画面518中，使“返回”按钮不显示。

即，在改写规格数据的场景信息中设定了召回标志的情况下，通过像上述那样将“以后”按钮、“返回”按钮设定为不显示，而使“以后”按钮、“返回”按钮不显示即可。或者，在显示活动通知画面502，在下载同意画面503中得到了用户的同意之后，也可以省略安装同意画面505、激活同意画面518的显示。以上，对在改写规格数据的场景信息中设定了召回标志的情况进行了说明，但在改写规格数据的场景信息中设定经销商标志、工厂用标志、功能更新通知标志、强制执行标志的情况下也相同，只要根据进行应用程序的改写的状况，指示与阶段对应的画面的显示有无、画面的项目的显示有无、画面的项目的显示内容的变更即可。

若具体地说明，在改写规格数据的场景信息中设定了经销商标志的情况下，在经销商环境中需要修理工序中的专用的画面显示，所以显示经销商用的专用的画面而不显示用户用的画面即可。即，经销商的作业者进行与应用程序的改写相关的操作，而不是由用户进行与应用程序的改写相关的操作，因此将“以后”按钮、“返回”按钮设定为显示用于经销商的作业，而使“以后”按钮、“返回”按钮显示即可。另外，例如也可以显示“请实施经销商的改写”等提示，催促经销商入库车辆。

在改写规格数据的场景信息中设定有工厂用标志的情况下，在工厂环境下的制造工序中不需要画面显示，因此不显示画面即可。

在改写规格数据的场景信息中设定有功能更新通知标志的情况下，即使用户利用自定义进行不需要显示的设定，也需要用于向用户可靠地通知变更内容的画面显示，因此只要与自定义的设定无关地显示面向用户的画面即可。即，在判断为用户不需要同意的情况下，也强制地实施同意，强制地显示同意画面即可，因此只要通过像上述那样将“以后”按钮、“返回”按钮设定为显示，而显示“以后”按钮、“返回”按钮即可。

在改写规格数据的场景信息中设定有强制执行标志的情况下，用户利用自定义进行需要显示的设定，即使在用户不进行同意的情况下，也需要用于可靠地实施车辆的软件更新的强制执行，因此与自定义的设定无关地，显示面向用户的画面即可。即，一边判断为用户需要同意一边即使不需要同意也实施应用程序的改写，因此通过像上述那样将“以后”按钮、“返回”按钮设定为不显示，而不显示“以后”按钮、“返回”按钮即可。另外，由于是以进行同意为前提的功能，因此也可以不显示画面本身而作为得到同意的画面来执行改写。

像以上说明的那样，CGW13通过进行进展显示的画面显示控制处理，在设定有自定义模式的情况下，向显示终端5指示与自定义模式的设定内容对应的画面显示。用户能够自定义与改写的进展对应的画面显示。

(25)程序更新的报告控制处理

参照图247至图253对程序更新的报告控制处理进行说明。车辆用程序改写系统1在CGW13中进行程序更新的报告控制处理。

如图247所示，CGW13在程序更新的报告控制部91中，具备阶段确定部91a、显示指示部91b、指示器显示控制部91c、图标显示控制部91d、详细信息显示控制部91e、以及无效化指示部91f。阶段确定部91a确定作为程序更新的进展状况的阶段。作为程序更新的阶段，阶段确定部91a确定活动通知、下载同意、下载执行中、安装同意、安装执行中、激活同意、激活执行中和更新完成。

显示指示部91b若通过阶段确定部91a确定程序更新的阶段，则指示以与该确定的程序更新的阶段对应的形式显示指示器。指示器显示控制部91c若被显示指示部91指示为显示指示器，则根据该指示而对指示器进行显示控制。具体而言，指示器显示控制部91c在仪表装置45中对指示器46进行点亮控制。

追随指示器显示控制部91c对指示器进行显示控制，图标显示控制部91d在车载显示器7中对图标进行显示控制。追随指示器显示控制部91c对指示器进行显示控制，详细信息显示控制部91e在车载显示器7或者便携终端6中对程序更新所涉及的图标和详细信息进行显示控制。图标是指图68所示的活动通知图标501a，详细信息例如是指图33所示的弹出显示的活动通知画面502、图70和图71所示的下载同意画面等。详细信息显示控制部91e指示以与通过阶段确定部91a确定的程序更新的阶段对应的形式显示图标、或者指示显示与阶段和用户操作对应的详细信息画面。

即使在通过在驻车中进行程序更新而由电源管理ECU20进行电源控制的情况下，无效化指示部91f也向电源管理ECU20、与用户操作相关的各ECU19指示用户操作的受理的无效化。例如通过向发动机ECU47(参照图243)指示用户操作的受理的无效化，在改写对象ECU19的存储器构造为1面存储器、在驻车中进行安装的情况下，即使用户进行了启动发动机的操作，也使受理无效化，抑制为发动机不启动。另外，通过向电源管理ECU20指示用户操作的无效化，在改写对象ECU19的存储器构造为1面存储器、在驻车中IG电源接通而进行安装的情况下，即使用户进行了断开IG电源的操作，也使受理无效化，抑制为IG电源不断开。此时，无效化指示部91f也可以指示车载显示器7进行使用户操作的受理无效化的内容的报告。

接下来，参照图248至图253对上述的结构的作用进行说明。CGW13执行程序更新的报告控制程序，执行程序更新的报告控制处理。

CGW13若开始程序更新的报告控制处理，则判定是否产生程序更新的活动(S2501)。CGW13若判定为产生了程序更新的活动(S2501：“是”)，则确定程序更新的阶段和存储器结构(S2502、相当于阶段确定步骤)。CGW13向仪表装置45指示以与该确定的程序更新的阶段对应的形式显示指示器46(S2503、相当于显示指示步骤)。向车载显示器7指示显示与该确定的程序更新的阶段对应的图标(S2504)。

CGW13判定详情显示请求的有无(S2505)，若判定出存在详情显示请求(S2505：“是”)，则判定是否能够与车载显示器7进行数据通信(S2506)。例如在用户按下了图32所示的活动通知图标501a、图33所示的“确认”按钮502a、图34所示的“详情确认”按钮503b等的情况下，CGW13判定为存在详情显示请求。CGW13若判定为能够与车载显示器7进行数据通信(S2506：“是”)，则获取详细信息(S2507)，向车载显示器7指示显示详细信息(S2508)，向中心装置3指示显示详细信息(S2509)。

CGW13获取与活动通知一同接收到的报告内容、分发规格数据的报告内容，向车载显示器7通知而指示详细信息显示。另外，CGW13向中心装置3通知阶段和用户的操作内容来作为详细信息的显示指示，以在便携终端6中也显示与车载显示器7相同的内容。

CGW13判定是否结束了程序更新的事件(S2510)。

例如若用户确认了激活完成、程序更新完成，则CGW13判定为事件结束。CGW13若判定为程序更新的事件未结束(S2510：“否”)，则返回步骤S2502，重复步骤S2502以后的步骤。CGW13在活动通知、下载同意、下载执行中、安装同意、安装执行中、激活同意、激活执行中和更新完成的各阶段中，重复步骤S2502以后的步骤。

CGW13若判定为程序更新的事件结束(S2510：“是”)，则结束程序更新的报告控制处理。

仪表装置45在用户能够确认的规定位置配置有指示器46，若从CGW13接收报告请求通知，则作为应用程序的改写中的报告，使指示器46点亮或者闪烁。这里，也可以取代闪烁，是改变指示器46的颜色或者列举亮度等与通常的点亮显示相比进一步强调的点亮显示。即，只要是与通常的显示相比进一步强调的显示即可。另外，与程序更新相关的指示器46是一个，通过一个外观设计构成。

如图249所示，在应用程序的改写对象为2面存储器的情况下、1面挂起存储器的情况下，1面独立存储器的情况下，仪表装置45使各阶段中的指示器的报告形式不同。具体而言，仪表装置45根据从CGW13指定的阶段和存储器结构，而确定指示器46的报告形式，根据该确定的报告形式进行报告。另外，也可以取代仪表装置45，由指示器显示控制部91c控制指示器46的报告形式，也可以由指示器显示控制部91c确定指示器46的报告形式，以该报告形式向仪表装置45指示对指示器46进行点亮控制。

如图249所示，指示器显示控制部91c在安装、激活等对车辆的行驶会产生制约的阶段中，使指示器46例如以绿色闪烁显示。在改写对象ECU19为2面存储器的情况下，指示器显示控制部91c仅在激活执行中的阶段进行闪烁显示。在改写对象ECU19为1面挂起起存储器的情况下，指示器显示控制部91c在IG断开中的安装执行中的阶段、激活同意的阶段和激活执行中的阶段进行闪烁显示。在改写对象ECU19为1面存储器的情况下，指示器显示控制部91c在安装执行中的阶段、激活同意的阶段和激活执行中的阶段进行闪烁显示。即，活动通知阶段、下载阶段和激活完成后的阶段(IG断开时、IG接通时、确认操作时)中的指示器46的显示不取决于存储器结构而是共用的，但安装阶段和激活阶段中的指示器46的显示取决于存储器结构而为不同的显示形式。这里，图249所示的IG断开时是指在驻车中执行激活，伴随着激活完成而将IG电源断开时的显示形式，伴随着IG电源断开而使指示器46熄灭。然后，在通过用户操作将IG电源接通时，使指示器46点亮。这是为了向用户报告程序更新全部完成。而且，在图91所示的确认操作画面510中，若用户按下“OK”按钮510b，则判断为进行了确认操作，使指示器46熄灭。

以下，对仪表装置45控制指示器46的报告形式的情况进行说明，但也可以是像上述那样指示器显示控制部91c控制指示器46的报告形式。在图250中表示改写对象ECU19的存储器种类为2面存储器的情况下的指示器的报告形式。基于来自CGW13的指示，仪表装置45在从活动通知到激活同意为止的阶段中使指示器46点亮，在激活执行中的阶段中使指示器46闪烁。然后，仪表装置45在IG断开时使指示器46熄灭，在IG接通时使指示器46点亮，若用户进行针对更新完成的确认操作，则使指示器46熄灭。即，在为2面存储器的情况下，有可能在车辆的行驶中产生制约，仅处于激活执行中。仅激活的执行在车辆处于驻车状态下进行，因此成为无法使车辆行驶的期间。因此，仪表装置45在激活执行中的阶段中使指示器46闪烁。另外，这里的指示器是规定的设计，在正常进展的情况下以绿色显示。

在图251中表示改写对象ECU19的存储器种类为1面挂起存储器的情况下的指示器的报告形式。在应用程序的改写对象为1面挂起存储器的情况下，基于来自CGW13的指示，仪表装置45在从活动通知到安装同意为止的阶段中使指示器46点亮，在安装执行中在IG接通时使指示器46点亮，在IG断开时使指示器46闪烁。即，仪表装置45在IG接通状态下不执行向1面挂起存储器ECU的闪存的写入，因此使指示器46点亮，但在IG断开状态下执行向闪存的写入，因此使指示器46闪烁。仪表装置45在从激活同意到激活执行中为止的阶段中使指示器46闪烁。然后，在IG断开时使指示器46熄灭，在IG接通时使指示器46点亮，若用户进行针对更新完成的确认操作，则使指示器46熄灭。即，在为1面挂起存储器的情况下，从IG断开时的安装执行中到激活执行中为止，有可能在车辆的行驶中产生制约。因此，仪表装置45在这些阶段中使指示器46闪烁。这里，在为1面挂起存储器的情况下，即使在向非运用面的安装执行中，也能够通过中断该安装，而启动运用面对车辆进行行驶控制。因此，也可以与为2面存储器的情况同样，仅在无法使车辆行驶的激活执行中采用闪烁显示。

在图252中表示改写对象ECU19的存储器种类为1面存储器的情况下的指示器的报告形式。在应用程序的改写对象为1面独立存储器的情况下，基于来自CGW13的指示，仪表装置45在从活动通知到安装同意为止的阶段中使指示器46点亮，在从安装执行中到激活执行中为止的阶段中使指示器46闪烁。然后，在IG断开时使指示器46熄灭，在IG接通时使指示器46点亮，若用户进行针对更新完成的确认操作，则使指示器46熄灭。即，在为1面存储器的情况下，从安装执行中到激活执行中为止，有可能在车辆的行驶中产生制约。因此，仪表装置45在这些阶段中使指示器46闪烁。

另外，在一次的活动通知中作为程序的改写对象ECU19，包含2面存储器、1面挂起存储器、1面独立存储器的ECU19的情况下，仪表装置45按照2面存储器、1面挂起存储器、1面独立存储器的顺序进行ECU19的应用程序的改写。CGW13在活动通知后，从针对2面存储器的ECU19的下载同意到安装执行中为止进行，仪表装置45在该期间使指示器46点亮。CGW13若结束针对2面存储器的ECU19的安装执行中的阶段，则从针对1面挂起存储器的ECU19的下载同意到安装执行中为止进行，仪表装置45在该期间使指示器46点亮。CGW13若结束针对1面挂起存储器的ECU19的安装执行中的阶段，则从针对1面独立存储器的ECU19的下载同意到安装同意为止进行，仪表装置45在该期间使指示器46点亮。

从1面独立存储器的安装执行中到针对这些存储器种类不同的3种ECU19的激活执行中为止，仪表装置45使指示器46闪烁。仪表装置45在之后的IG断开时使指示器46熄灭，在IG接通时使指示器46点亮，若用户进行针对更新完成的确认操作，则使指示器46熄灭。

另外，在一次的活动通知中作为程序的改写对象ECU19，包含2面存储器、1面挂起存储器、1面独立存储器的ECU19的情况下，仪表装置45也可以像以下那样进行控制。仪表装置45按照2面存储器、1面挂起存储器、1面独立存储器的顺序进行ECU19的应用程序的改写。CGW13在活动通知后，作为包含这些改写对象ECU19的更新数据的分发包的下载同意和下载执行中的指示器46，指示使绿色的规定设计点亮。然后，作为安装同意的指示器46，CGW13指示使绿色的规定设计点亮。另外，在包含1面独立存储器的ECU19的情况下，这里的安装同意兼用作激活同意。若得到针对安装的用户的同意，则CGW13第一步执行将向2面存储器的ECU19的安装。在执行将向2面存储器的ECU19的安装的期间，仪表装置45使指示器46点亮。CGW13若结束针对2面存储器的ECU19的安装执行中的阶段，则执行向1面挂起存储器的ECU19的安装。在执行向1面挂起存储器的ECU19的安装的期间，仪表装置45使指示器46点亮。CGW13若结束针对1面挂起存储器的ECU19的安装执行中的阶段，则执行针对1面独立存储器的ECU19的安装。在执行向1面挂起存储器的ECU19的安装的期间，仪表装置45使指示器46闪烁。若这些改写对象ECU19的安装全部完成，则CGW13在持续指示器46的闪烁的状态下，执行激活。CGW13在之后的IG断开时向仪表装置45指示使指示器46熄灭，在IG接通时向仪表装置45指示使指示器46点亮，若用户进行针对更新完成的确认操作，则向仪表装置46指示使指示器46熄灭。

在图250～图252所示的各阶段中，CGW13还向车载显示器7指示图标显示。CGW13在活动通知阶段中，指示显示图68所示的活动通知图标501a。CGW13在下载同意阶段中也持续该活动通知图标501a的显示。CGW13在下载执行中阶段中，指示显示图72所示的下载执行中图标501b。CGW13在安装同意阶段中，也可以持续该下载执行中图标501b的显示，也可以指示再次显示活动通知图标501a。CGW13在安装执行中阶段中，指示显示图77所示的安装执行中图标501c。CGW13在激活同意阶段中，也可以持续该安装执行中图标501c的显示，也可以指示再次显示活动通知图标501a。CGW13在激活执行中阶段和之后的IG断开时，不进行图标显示。CGW13在IG接通时，也可以指示再次显示活动通知图标501a，也可以使图80所示激活完成通知画面509弹出显示。若用户进行针对更新完成的确认操作，则CGW13不进行图标显示。另外，与程序更新相关的图标显示是一个，通过与各阶段对应的设计构成。

CGW13在像上述那样向指示器46指示应用程序的改写中的报告时，在应用程序的改写中产生了异常时，设为与正常时不同的报告形式。也可以是，在正常进行应用程序的改写时，CGW13例如指示以绿色进行点亮显示、闪烁显示，在产生了异常时，CGW13例如指示以黄色、红色进行点亮显示、闪烁显示。CGW13也可以根据异常的程度而使颜色不同，例如在异常的程度比较大时指示以红色进行点亮显示、闪烁显示，在异常的程度比较小时指示以黄色进行点亮显示、闪烁显示。这里所说的异常包含不能下载分发包的状态、不能安装写入数据的状态、在改写对象ECU19中不能对写入数据进行写入的状态、写入数据不正当的状态等。

作为详情显示，车载显示器7基于用户的操作而依次显示上述的活动通知画面502、下载同意画面503、下载执行中画面504、下载完成通知画面505、安装同意506、安装执行中画面507、激活同意画面508、IG接通时画面509、以及针对更新完成的确认操作时画面510。与车载显示器7相同的详情显示在连接成能够与中心装置3进行通信的便携终端6中也能够显示。例如在未搭载车载显示器7的车辆中，在用户通过手柄开关的操作等请求了详情显示的情况下，CGW13经由DCM12向中心装置3请求详情显示。中心装置3通过制作详情显示的内容，并由便携终端6显示该内容，用户能够在便携终端6中确认详细信息。

如图253所示，CGW13在驻车中改写IG系统ECU、ACC系统ECU的1面挂起存储器、1面独立存储器的应用程序的情况下，强制地启动电源管理ECU20，使车辆电源成为接通的状态。在该情况下，若电源管理ECU20强制地启动，则通过电源管理ECU20的动作使仪表装置45、车载显示器7启动。因此，CGW13向仪表装置45、车载显示器7指示与程序更新相关的报告的抑制。仪表装置45若被CGW13指示程序更新的报告的抑制，则不进行上述的指示器46的点亮、闪烁。车载显示器7若被CGW13指示程序更新的报告的抑制，则不进行上述的详情显示。即，在驻车中进行的安装、激活中，在用户不乘车的状况的情况下，由于不需要与程序更新相关的报告，因此控制为不进行报告。

另外，若电源管理ECU20强制地启动，使车辆电源成为接通的状态，则能够受理来自用户的按钮开关的操作而进行发动机控制，然而CGW13向电源管理ECU20指示用户操作的受理的无效化，向仪表装置45、车载显示器7以及与用户操作相关的ECU19指示用户操作的受理的无效化的报告。仪表装置45若被CGW13指示用户操作的受理的无效化，则即使用户在仪表装置45中进行操作，也使该操作的受理无效化。同样，车载显示器7若被CGW13指示用户操作的受理的无效化，则即使用户在车载显示器7中进行操作，也使该操作的受理无效化。另外，发动机ECU47若被CGW13指示用户操作的受理的无效化，则即使用户通过按钮开关进行使发动机启动的操作，也进行抑制以使该操作的受理无效化，使发动机不启动。

像以上说明的那样，CGW13通过进行程序更新的报告控制处理，而向仪表装置45指示应用程序的改写中的报告。即使在应用程序的改写中无法通过便携终端6、车载显示器7向用户通知的状况中也是通过仪表装置45向用户通知处于应用程序的改写中，而能够适当地向用户通知处于应用程序的改写中。另外，CGW13也可以根据应用程序的改写的进展状况而使报告形式发生变化。

(26)电源自保持的执行控制处理

参照图254至图258对电源自保持的执行控制处理进行说明。车辆用程序改写系统1在CGW13、ECU19、车载显示器7、电源管理ECU20中进行电源自保持的执行控制处理。在该情况下，CGW13对ECU19、车载显示器7、电源管理ECU20指示电源自保持。即，CGW13与车辆用主装置对应，ECU19、车载显示器7、电源管理ECU20与车辆用从装置对应。CGW13具有第二电源自保持电路，车辆用从装置具有第一电源自保持电路。

如图254所示，CGW13在电源自保持的执行控制部92中，具有车辆电源判定部92a、改写中判定部92b、第一电源自保持判定部92c、电源自保持指示部92d、第二电源自保持判定部92e、第二电源自保持有效化部92f、第二停止条件成立判定部92g、以及第二电源自保持停止部92h。

车辆电源判定部92a判定车辆电源的接通断开。改写中判定部92b判定是否处于应用程序的改写中。改写中判定部95b判定哪个改写对象ECU19处于改写中。若由车辆电源判定部92a判定为车辆电源断开，由改写中判定部92b判定为处于程序的改写中，则第一电源自保持有效化部92c判定在车辆用从装置中自保持电源的必要性。即，第一电源自保持有效化部92c参照图8所示的改写规格数据，如果改写对象ECU19的ECU信息的改写方法被指定为电源自保持，则判定为存在自保持电源的必要性，如果被指定为电源控制，则判定为不存在自保持电源的必要性。

电源自保持指示部92d若由第一电源自保持判定部92c判定为在车辆用从装置中需要自保持电源，则向车辆用从装置指示第一电源自保持电路的有效化。作为指示第一电源自保持电路的有效化的形式，电源自保持指示部92d具有指定电源自保持的完成时刻的形式、指示电源自保持的延长时间的形式、向车辆用从装置定期地持续输出自保持请求的形式。电源自保持指示部92d参照图44所示的改写规格数据，根据由改写对象ECU19的ECU信息的电源自保持时间指定的时间，向车辆用从装置指示第一电源自保持电路的有效化。

即，如果采用指定电源自保持的完成时刻的形式，则电源自保持指示部92d将从当前时刻加上由改写规格数据指定的时间而得的时刻指定为完成时刻。如果采用指定电源自保持的延长时间的形式，则电源自保持指示部92d将由改写规格数据指定的时间指定为延长时间。如果采用定期地向车辆用从装置持续输出自保持请求的形式，则直到由改写规格数据指定的时间经过为止，电源自保持指示部92d定期地向车辆用从装置持续输出自保持请求。

若由车辆电源判定部92a判定为车辆电源断开，由改写中判定部92b判定为处于程序的改写中，则第二电源自保持判定部92e判定自身自保持电源的必要性。即，考虑CGW13是IG电源系统或者ACC电源系统的结构，判定自保持电源的必要性。若由第二电源自保持判定部92e判定为自身需要自保持电源，则第二电源自保持有效化部92f进行第二电源自保持电路的有效化。

在该情况下，在第二电源自保持电路处于停止中的情况下，第二电源自保持有效化部92f通过使第二电源自保持电路启动，而使第二电源自保持电路有效化。在第二电源自保持电路处于启动中的情况下，第二电源自保持有效化部92f通过延长第二电源自保持电路的动作期间，而使电源自保持电路有效化。

第二停止条件成立判定部92g判定第二电源自保持电路的电源自保持的停止条件是否成立。具体而言，第二停止条件成立判定部92g监视车辆电池40的电池余量、超时的产生、改写对象ECU19的改写完成，若判定为车辆电池40的电池余量小于规定容量、或者产生超时、或者改写对象ECU19完成了改写，则判定为第二电源自保持电路的电源自保持的停止条件成立。若由第二停止条件成立判定部92g判定为第二电源自保持电路的电源自保持的停止条件成立，则第二电源自保持停止部92h停止第二电源自保持电路。

如图255所示，ECU19在电源自保持的执行控制部108中，具有指示判定部108a、第一电源自保持有效化部108b、第一停止条件成立判定部108c、以及第一电源自保持停止部108d。指示判定部108a判定是否被CGW13指示了第一电源自保持电路的有效化。

若由指示判定部108a判定为指示了第一电源自保持电路的有效化，则第一电源自保持有效化部108b使第一电源自保持电路有效化。在指定了电源自保持的完成时刻的情况下，第一电源自保持有效化部108b直到该指定的完成时刻为止使第一电源自保持电路有效化。在指定了电源自保持的延长时间的情况下，第一电源自保持有效化部108b直到从当前时刻起经过了该指定的延长时间为止使第一电源自保持电路有效化。在从CGW13输入自保持请求的情况下，第一电源自保持有效化部108b只要持续输入自保持请求，就使第一电源自保持电路有效化。

在该情况下，在第一电源自保持电路处于停止中的情况下，第一电源自保持有效化部108b通过使第一电源自保持电路启动，而使第一电源自保持电路有效化。在第一电源自保持电路处于启动中的情况下，第一电源自保持有效化部108b通过延长第一电源自保持电路的动作期间，而使第一电源自保持电路有效化。另外，第一电源自保持有效化部108b保存默认的电源自保持时间，即使不指示第一电源自保持电路的有效化，也在该默认的电源自保持时间内使第一电源自保持电路有效化。即，第一电源自保持有效化部108b若被指示第一电源自保持电路的有效化，则使默认的电源自保持时间与基于来自CGW13的指示的电源自保持时间中的较长的一方优先而使第一电源自保持电路有效化。

第一停止条件成立判定部108c判定第一电源自保持电路的电源自保持的停止条件是否成立。具体而言，如果电源自保持的对象是改写对象ECU19，则第一停止条件成立判定部108c监视超时的产生、来自CGW13的停止指示，若判定为产生超时、或者接收来自CGW13的停止指示，则判定为第一电源自保持电路的电源自保持的停止条件成立。如果电源自保持的对象是车载显示器7，则第一停止条件成立判定部108c监视超时的产生、用户的下车、来自CGW13的停止指示，若判定为产生超时、或者用户的下车、或者接收来自CGW13的停止指示，则判定为第一电源自保持电路的电源自保持的停止条件成立。如果电源自保持的对象是电源管理ECU20，则第一停止条件成立判定部108c监视来自CGW13的停止指示，若判定为接收来自CGW13的停止指示，则判定为第一电源自保持电路的电源自保持的停止条件成立。若由第二停止条件成立判定部108c判定为第一电源自保持电路的电源自保持的停止条件成立，则第一电源自保持停止部108d停止第一电源自保持电路。

接下来，参照图256至图258对上述的结构的作用进行说明。这里，对车辆用从装置为改写对象ECU19的情况进行说明。CGW13和改写对象ECU19分别执行电源自保持的执行控制程序，进行电源自保持的执行控制处理。

CGW13若开始电源自保持的执行控制处理，则判定车辆电源是否断开(S2601、相当于车辆电源判定步骤)。CGW13若判定为车辆电源断开(S2601：“是”)，则判定是否处于应用程序的改写中(S2602、相当于改写中判定步骤)。CGW13若判定为处于应用程序的改写中(S2602：“是”)，则将第二电源自保持电路启动(S2603、相当于第二电源自保持有效化步骤)，判定在改写对象ECU19中自保持电源的必要性(S2604、相当于电源自保持判定步骤)。

CGW13若判定为在改写对象ECU19中需要保持电源自身(S2604：“是”)，则向改写对象ECU19指示第一电源自保持电路的有效化(S2605、相当于电源自保持指示步骤)。CGW13判定电源自保持的停止条件是否成立(S2606)，若判定为电源自保持的停止条件成立(S2606：“是”)，则停止第二电源自保持电路(S2607)，结束电源自保持的执行控制处理。

以上，CGW13采用在判定为处于应用程序的改写中的情况下将电源自保持电路启动的结构，但也可以采用如下的结构，若判定为车辆电源断开，则将电源自保持电路启动，若判定为处于应用程序的改写中，将该启动中的电源自保持电路的动作时间延长。

改写对象ECU19若开始电源自保持的执行控制处理，则判定车辆电源是否断开(S2611)。改写对象ECU19若判定为车辆电源断开(S2611：“是”)，则将自保持电路启动(S2612)，判定电源自保持的停止条件是否成立(S2613)，判定是否从CGW13指示了电源自保持电路的有效化(S2614)。改写对象ECU19若判定为从CGW13指示了电源自保持电路的有效化(S2614：“是”)，则将该启动中的电源自保持电路的动作期间延长(S2615)。改写对象ECU19若判定为电源自保持的停止条件成立(S2613：“是”)，则停止电源自保持电路(S2616)，结束电源自保持的执行控制处理。

以上，改写对象ECU19采用在判定为车辆电源断开的情况下将电源自保持电路启动的结构，但也可以采用如下的结构，在判定为车辆电源断开的情况下使电源自保持电路不启动，若判定为车辆电源断开，并且判定为从CGW13指示了电源自保持电路的有效化，则使停止中的电源自保持电路启动。

以上，对车辆用从装置为改写对象ECU19的情况进行了说明，但车辆用从装置为车载显示器7、电源管理ECU20的情况也相同。如图258所示，在改写对象ECU19中，在从安装准备到改写后处理为止的期间中需要电源自保持电路的动作，在车载显示器7中，在等待更新同意、等待下载同意、等待安装同意、等待激活同意的期间需要电源自保持电路的动作。

像以上说明的那样，CGW13通过进行电源自保持的执行控制处理，若判定为车辆电源断开，处于应用程序的改写中，则判定在改写对象ECU19中自保持电源的必要性，若判定为需要自保持电源，则向改写对象ECU19指示电源自保持电路的有效化。在改写对象ECU19中，若判定为从CGW13指示了电源自保持电路的有效化，则使电源自保持电路有效化。通过使电源自保持电路有效化，能够确保用于进行应用程序的改写的动作电源，能够适当地完成应用程序的改写。

参照图259至图269对包含上述的特征性的处理(1)～(26)在内的程序更新的整体顺序进行说明。这里，说明如下的例子，对与第一总线连接的ECU(ID1)、ECU(ID2)和ECU(ID3)的应用程序进行改写，不对与第二总线连接的ECU(ID4)、ECU(ID5)和ECU(ID6)的应用程序进行改写。ECU(ID1)和ECU(ID4)为1面独立存储器，ECU(ID5)为1面挂起存储器，ECU(ID2)、ECU(ID3)和ECU(ID6)为2面存储器。另外，ECU(ID1)、ECU(ID4)、ECU(ID5)和ECU(ID6)为IG电源系统ECU，ECU(ID2)为ACC电源系统ECU，ECU(ID3)为+B电源系统ECU。

首先，作为提前准备，用户操作便携终端6等，输入车辆编号(车辆的识别编号)、移动电话号码等个人信息，对中心装置3登记帐户(S5001)。另外，用户操作便携终端6等，输入执行条件，作为允许程序更新的执行的条件，指定车辆位置、时间段等。中心装置3在数据库中存储经由便携终端6接收到的个人信息等(S5002)。

另外，车辆侧系统4的CGW13收集与车辆相关的信息(S5011)，经由DCM12向中心装置3上传(S5012)。具体而言，是程序版本、各ECU19的存储器结构、运用面信息、搭载于车辆的电装部件、车辆位置、车辆的电源状态等信息。中心装置3在数据库中存储从车辆侧系统4接收到的信息(S5013)。

若产生程序更新的必要性，则中心装置3根据从应用程序的提供企业即供应商提供的写入数据和存储于数据库的信息，生成图43和图44所示的改写规格数据。而且，中心装置3根据这些写入数据及其认证符、改写规格数据而生成重编数据。中心装置3将所生成的重编数据、另外生成的分发规格数据(图45)、包认证符打包于一个文件，生成分发包，并进行登记(S5021)。

中心装置3在完成了分发包的准备之后，对用户进行程序更新的告知。中心装置3参照存储于数据库的个人信息，对便携终端6发送短消息服务(SMS)(S5031)。通过用户操作，便携终端6与记载于SMS的URL(Uniform Resource Locator：统一资源定位符)连接，显示告知内容(S5032)。便携终端6向中心装置3通知同意基于用户操作的程序更新的内容、或者不同意的内容(S5033)。中心装置3将用户的意向信息(同意或者不同意)登记于数据库(S5034)。这里，也可以取代便携终端6，使用车载显示器7向用户告知。

CGW13经由DCM12接收从中心装置3发送来的分发规格数据，并向车载显示器7传输(S5035)。车载显示器7对分发规格数据进行解析，显示作为告知内容的显示语句等(S5036)。另外，车载显示器7显示图标等图像数据，受理用户是否同意程序更新的输入。CGW13从车载显示器7接收用户的意向信息，经由DCM12向中心装置3通知(S5037)。

在从用户得到了程序更新的同意的情况下，车辆侧系统4从中心装置3下载分发包。首先，中心装置3检查是否满足预先由用户指定的执行条件(S5041)。中心装置3在执行条件中的一个都不满足的情况下，不向DCM12发送分发包。在满足全部的执行条件的情况下，中心装置3向DCM12发送分发包(S5042)。DCM12若从中心装置3下载分发包，则将该下载的分发包保存于闪存。而且，DCM12从分发包提取分发包认证符，验证重编数据和分发规格数据的完整性(S5043)。

DCM12例如使用由CGW13存储的密钥信息，对重编数据和分发规格数据的认证符进行运算。DCM12对运算出的认证符与从分发包提取的分发包认证符进行比较，在一致的情况下判定为验证成功，在不一致情况下判定为验证失败。DCM12若判定为验证失败，则删除分发包，并且向CGW13和中心装置3通知验证失败的内容。

DCM12在判定为针对分发包的验证成功的情况下，像图46所示那样将分发包中包含的重编数据解包，分割为针对各改写对象ECU19的写入数据和改写规格数据(S5044)。改写规格数据预先分割为DCM用的改写规格数据和CGW用的改写规格数据。

DCM12向CGW13发送CGW用的改写规格数据(S5045)。CGW13对从DCM12接收到的CGW用的改写规格数据进行解析，在提取了所需要的信息之后，在与DCM12之间进行针对各ECU19的写入数据的认证(S5046)。CGW13例如使用自身存储ECU(ID1)的密钥信息，而对ECU(ID1)的写入数据(差分数据)的认证符进行运算。CGW13对运算出的认证符与从重编数据提取的认证符进行比较，在一致的情况下判定为验证成功，在不一致的情况下判定为验证失败。CGW13若判定为验证失败，则删除分发包，并且向DCM12和中心装置3通知验证失败的内容。这里，在针对任意一个写入数据判定为验证失败的情况下，CGW13不对全部的ECU19进行程序更新。

CGW13若针对全部的写入数据判定为验证成功，则从DCM12接收分发规格数据，向车载显示器7传输该接收到的分发规格数据(S5047)。车载显示器7存储从CGW13传输来的分发规格数据。若以上的下载处理完成，则CGW13经由DCM12向中心装置3通知下载完成的内容(S5048)。

中心装置3若被车辆侧系统4通知下载完成，则对便携终端6发送SMS(S5049)。便携终端6通过用户操作与记载于SMS的URL连接，显示安装预约画面(S5050)。便携终端6向中心装置3通知通过用户操作而输入的安装时间(S5051)。中心装置3将安装时间与个人信息相关联地存储于数据库(S5052)。这里，也可以取代便携终端6，使用车载显示器7而使用户预约安装时间。车载显示器7若被CGW13通知下载完成(S5053)，则显示安装预约画面(S5054)。CGW13经由DCM12向中心装置3通知从车载显示器7接收到的安装时间(S5055)。

在当前时间为登记于数据库的安装时间的情况下，中心装置3向车辆侧系统4指示安装开始(S5071)。DCM12若被中心装置3指示安装，则检查安装执行条件(S5072)。DCM12例如检查车辆位置、与中心装置3的通信状况等。DCM12在满足全部的执行条件的情况下，使用包认证符来认证分发包(S5073)。若认证成功，则DCM12对分发包进行解包(S5074)，提取DCM用的改写规格数据和CGW用的改写规格数据，在分割为每个ECU19的写入数据的基础上，向CGW13通知安装开始(S5075)。

CGW13若被DCM12通知安装开始，则对从DCM12获取的CGW用的改写规格数据进行解析，判定以哪个顺序改写哪个ECU19(S5076)。这里，设为第一个改写ECU(ID1)，第二个改写ECU(ID2)，第三个改写ECU(ID3)的顺序。CGW13使用各认证符而对DCM12保存的每个改写对象ECU19的写入数据全部进行验证(S5077)。这里，不仅可以验证用于版本升级的写入数据，而且还可以验证用于回滚的写入数据。

若写入数据的验证成功，则CGW13对电源管理ECU20请求IG电源接通(S5078)。在驻车中(IG开关42断开且ACC开关41断开)安装时，在改写对象ECU19为IG系统ECU或者ACC系统ECU的情况下，需要供给电力而使改写对象ECU19启动。电源管理ECU20向电源控制电路43请求进行与IG电源接通相同的电力供给(S5079)。若通过电源控制电路43向IG电源线39进行电力供给，则IG系统ECU和ACC系统ECU启动(唤醒)。

然后，CGW13对非改写对象ECU19即ECU(ID5)、ECU(ID5)和ECU(ID6)、第二个以后改写的ECU(ID2)和ECU(ID3)请求休眠(S5080)。另外，这里，在改写了第一个改写对象ECU19之后改写第二个改写对象ECU19，但也可以同时并行地改写多个改写对象ECU19。在该情况下，仅对非改写对象ECU19请求休眠。

CGW13与对各改写对象ECU19的安装并行地，进行电池余量的监视(S5081)和总线的通信负荷的监视(S5082)。CGW13参照从CGW用的改写规格数据中提取出的电池负荷的值、总线负荷的值(总线负荷表)，在不超过允许值的范围内控制安装。CGW13例如在驻车状态下，若电池负荷达到允许值，则在该时刻中断安装。

另外，例如若连接有改写对象ECU(ID1)的第一总线的总线负荷达到允许值，则CGW14延迟向ECU(ID1)发送写入数据的频度。若完成了向全部的改写对象ECU19的安装，则这些监视结束。另外，在为1面独立存储器的情况下，无法在安装的中途结束，因此需要在安装开始前确认存在足够的电池余量。

CGW13向第一个改写的ECU(ID1)通知安装开始(S5101)。ECU(ID1)若被CGW13通知安装开始，则使状态转变为基于无线的程序更新模式(S5102)。由于ECU(ID1)为1面独立存储器ECU，因此无法并行地进行应用程序的执行、使用工具的诊断处理，成为基于无线的程序更新专用模式。

在进行向第一个改写的ECU(ID1)的安装时，CGW13使用安全访问密钥进行访问认证(S5103)。若向ECU(ID1)的访问认证成功，则CGW13向ECU(ID1)发送写入数据即全部数据的信息。ECU(ID1)使用接收到的全部数据的信息，而判定写入数据是否与本ECU整合(S5104)。ECU(ID1)在判定为整合的情况下，进行写入处理。

CGW13从DCM12获取向ECU(ID1)的写入数据中的规定大小(例如1k字节)的分割文件，向ECU(ID1)分发(S5105)。ECU(ID1)将从CGW13接收到的分割文件写入闪存33d(S5106)。ECU(ID1)若写入完成，则存储重试点，该重试点表示写入到哪里的闪存地址，以使得能够从中途重新开始写入(S5107)。作为重试点，也可以存储表示执行到闪存的消除、写入以及这以后的处理中的哪里的标志。ECU(ID1)若存储重试点，则向CGW13通知写入完成(S5108)。

CGW13若从ECU(ID1)接受写入完成的通知，则经由DCM12向中心装置3通知改写状况的进展信息(S5109)。进展信息是指例如处于安装阶段以及ECU(ID1)的写入数据累积完成了多少字节写入等数据。中心装置3基于从DCM12发送来的进展信息，而对能够从便携终端6连接的网络画面进行更新(S5110)。便携终端6与中心装置3连接，作为更新后的进展状况，例如显示当前安装推进到几％等(S5111)。由此，即使在车辆处于驻车状态，用户位于车外的情况下，也能够通过便携终端6掌握安装的进展状况。这里，也可以取代便携终端6，利用车载显示器7显示进展。CGW13若从ECU(ID1)接受改写完成的通知，则向车载显示器7通知改写状况的进展信息(S5112)。车载显示器7更新并显示进展状况的画面(S5113)。在像ECU(ID2)、ECU(ID3)那样为2面存储器结构的情况下，即使车辆处于行驶状态也能够安装。因此，例如在车辆处于IG开关接通的情况下，车载显示器7可以显示进展状况。

CGW13若从ECU(ID1)接受写入完成的通知，则获取第二个分割文件作为下一写入数据，并向ECU(ID1)分发。此后，直到作为最后的写入数据的第N个分割文件为止，重复S5105～S5113的处理。ECU(ID1)若直到第N个分割文件为止完成写入，则对闪存的更新程序进行完整性验证，确认是否正确地写入(S5114)。CGW13若从ECU(ID1)接受完成全部的分割文件的写入、完整性验证成功的内容的通知，则对ECU(ID1)请求休眠(S5115)。ECU(ID1)不通过安装后的更新程序启动，而暂时休眠。

CGW13对第二个改写的ECU(ID2)请求唤醒(S5201)。CGW13向ECU(ID2)通知基于无线的程序更新、即开始安装的内容(S5202)。作为内部状态，ECU(ID2)使状态转变为基于无线的程序更新模式(S5203)。2面存储器即ECU(ID2)在基于无线的程序更新模式的期间，能够进行应用程序的执行、基于工具的诊断的执行。CGW13对ECU(ID2)进行访问认证(S5204)。ECU(ID2)判定写入数据即差分数据是否与本ECU整合(S5205)。由于ECU(ID2)为2面存储器，因此判定是否包含与闪存的非运用面整合的写入数据。例如若ECU(ID2)的A面为运用面，B面为非运用面，则在写入数据是与B面不一致的地址的情况下，不进入以后的处理，CGW13经由DCM12向中心装置3通知写入数据错误的内容。而且，CGW13进行后述的回滚的处理。在判定为写入数据与本ECU整合的情况下，进行对ECU(ID2)的写入处理。此后，与ECU(ID2)相关的S5206～S5216的处理与S5105～S5115相同。在S5207中，在向2面存储器即ECU(ID2)写入差分数据时，如图54所示，根据旧数据和差分数据对差分进行复元而生成新数据，并写入闪存33d。

若针对ECU(ID2)的安装全部完成，使ECU(ID2)休眠，则CGW13对第三个改写的ECU(ID3)请求唤醒(S5301)。CGW13向ECU(ID3)通知基于无线的程序更新、即开始安装的内容(S5302)。作为内部状态，ECU(ID3)使状态转变为基于无线的程序更新模式(S5303)。CGW13对ECU(ID3)进行访问认证(S5304)。ECU(ID3)判定写入数据即差分数据是否与本ECU整合(S5305)。在判定为写入数据与本ECU整合的情况下，进行对ECU(ID3)的写入处理。此后，与ECU(ID3)相关的S5306～S5315的处理与S5105～S5114相同。

若对ECU(ID3)的安装全部完成，则CGW13结束电池余量的监视和总线的通信负荷的监视(S5316，S5317)。而且，CGW13对ECU(ID1)和ECU(ID2)请求唤醒(S5401)。

为了使ECU(ID1)、ECU(ID2)和ECU(ID3)以更新后的程序同时启动，CGW13对各个ECU请求将更新后的程序激活(S5402)。另外，在是不与激活的请求对应的ECU的情况下，可以取代激活请求，通知电源断开和电源接通，进行重新启动。

ECU(ID1)若接受来自CGW13的激活请求，则使自身重新启动(S5403)。由于ECU(ID1)是1面独立存储器，因此通过重新启动，以更新后的程序使ECU(ID1)启动。若安装后的重新启动完成，则ECU(ID1)将更新后的程序版本与激活完成一同向CGW13通知(S5404)。

ECU(ID2)若接受来自CGW13的激活请求，则将所存储的运用面信息从A面更新为B面(S5405)，使自身重新启动(S5406)。而且，ECU(ID2)若在B面正常启动，则将激活完成与更新后的程序版本和运用面信息一同向CGW13通知(S5407)。

ECU(ID3)若接受来自CGW13的激活请求，则将所存储的运用面信息从A面更新为B面(S5408)，使自身重新启动(S5409)。而且，ECU(ID3)若在B面正常启动，则将激活完成与更新后的程序版本和运用面信息一同向CGW13通知(S5410)。

CGW13若接受来自ECU(ID1)、ECU(ID2)和ECU(ID3)的激活完成通知，则经由DCM12将程序的更新完成与改写对象ECU(ID1)、ECU(ID2)和ECU(ID3)相关的更新后的程序版本和运用面信息一同向中心装置3通知(S5411)。中心装置3将从DCM12通知的信息登记于数据库(S5412)，并且，将网络画面更新成作为进展状况的表示完成的显示(S5413)。便携终端6与中心装置3连接，显示完成了程序更新的内容的网络画面(S5414)。另外，CGW13若接受来自ECU(ID1)、ECU(ID2)和ECU(ID3)的激活完成通知，则向车载显示器7通知作为进展状况的完成了程序更新的内容(S5415)。车载显示器7显示完成了程序更新的内容(S5416)。另外，在车辆处于驻车状态等不需要进展显示的情况下，CGW13不向车载显示器7通知进展。

最后，CGW13对电源管理ECU20请求IG电源断开(S5418)。电源管理ECU20对电源控制电路43请求切断电力供给，以返回到安装开始前的IG开关断开的电源状态。若通过电源控制电路43，切断对IG电源线39和ACC电源线38的电力供给，则ECU(ID1)、ECU(ID2)、ECU(ID4)、ECU(ID5)和ECU(ID6)成为停止状态。

在上述的例子中，说明了如下，由于包含1面独立存储器即ECU(ID1)的程序更新，因此在车辆处于驻车状态时，从安装到激活为止连续进行。然而，例如在改写对象ECU19全部为2面存储器的情况下，也可以在行驶中在后台进行安装。另外，也可以构成为，在改写对象ECU19的安装完成的时刻，通过便携终端6从用户得到激活的同意。

接下来，参照图266至图269，对在应用程序的安装中，由用户选择了程序更新的取消的情况下的回滚顺序进行说明。具体而言，关于针对ECU(ID1)安装完成，针对ECU(ID2)在安装中途的时刻由用户选择了取消的情况，进行说明。

在由便携终端6通知了程序更新的取消的情况下，中心装置3向车辆侧系统4指示取消程序更新(S6001)。而且，中心装置3将网络画面变更为作为进展状况的回滚中的显示形式(S6002)。便携终端6显示表示回滚中的进展状况的网络画面(S6003)。

若经由DCM12从中心装置3指示程序更新的取消，则CGW13基于改写对象ECU(ID1)、ECU(ID2)和ECU(ID3)的存储器结构以及安装状况，判定需要对哪个ECU进行怎样的回滚处理(S6004)。在该例中，判定完成向ECU(ID2)的安装，并且需要将ECU(ID1)返回到原来的版本这样的回滚处理的内容。

而且，CGW13向车载显示器7通知回滚用的进展(S6005)。车载显示器7若被CGW13通知回滚用的进展，则变更为回滚用的显示形式而显示进展(S6006)。车载显示器7例如显示为“回滚中”，并且将需要回滚的ECU(ID1)的进展显示为0％，将ECU(ID2)的进展显示为0％。

作为针对ECU(ID2)的回滚处理，CGW13持续写入数据的安装。由于ECU(ID2)是2面存储器，因此也可以在中途中断向非运用面即B面的安装，持续将A面作为运用面进行动作。然而，在B面处于安装到中途的不完整的状态的情况下，在使用下次的差分数据的安装时，无法正确地复元差分。因此，针对ECU(ID2)将安装持续到最后。

具体而言，CGW13从DCM12获取针对ECU(ID2)的写入数据的分割文件(例如1k字节分)，并向ECU(ID2)分发(S6007)。ECU(ID2)将从CGW13接收到的分割文件写入闪存33d(S6008)。若写入完成，则ECU(ID2)存储重试点，以使得能够从中途重新开始写入(S6009)，向CGW13通知写入完成(S6010)。

CGW13若从ECU(ID2)接受写入完成的通知，则经由DCM12向中心装置3通知回滚状况的进展信息(S6011)。回滚状况的进展信息例如是指作为ECU(ID2)的回滚，需要多少字节的写入，其中累积完成了多少字节写入等数据。中心装置3基于从DCM12发送来的进展信息，而能够更新从便携终端6连接的网络画面(S6012)。作为更新后的进展状况，便携终端6例如显示回滚当前进行到几％等的网络画面(S6013)。这里，也可以取代便携终端6，利用车载显示器7显示进展。CGW13若从ECU(ID2)接受改写完成的通知，则向车载显示器7通知回滚状况的进展信息(S6014)。车载显示器7更新并显示进展状况的画面(S6015)。此后，直到作为最后的写入数据的第N个分割文件为止，重复S6007～S6015的处理。

ECU(ID2)若写入到第N个分割文件，则验证闪存33d的更新程序的完整性(S6016)。CGW13若从ECU(ID2)接受安装完成的通知，则对ECU(ID2)请求休眠(S6017)。ECU(ID2)休眠而不会利用安装于非运用面即B面的更新程序启动。

接着，CGW13为了进行对ECU(ID1)的回滚处理而对ECU(ID1)请求唤醒(S6101)。CGW13向ECU(ID1)通知开始用于回滚的安装的内容(S6102)。ECU(ID1)若被CGW13通知安装开始，则使状态转变为基于无线的程序更新模式(S6103)。CGW13与ECU(ID1)进行访问认证(S6104)。ECU(ID1)若访问认证成功，则判定回滚用的写入数据是否与本ECU整合(S6105)。在判定为回滚用的写入数据与本ECU整合的情况下，进行对ECU(ID1)的写入处理。

CGW13从DCM12获取向ECU(ID1)的回滚用的写入数据中的规定大小(例如1k字节)的分割文件，并向ECU(ID1)分发(S6016)。ECU(ID1)将从CGW13接收到的分割文件写入闪存33d(S6107)。ECU(ID1)若写入完成，则存储重试点，该重试点表示写入到哪里的闪存地址，以使得能够从中途重新开始写入(S6108)。ECU(ID1)若存储重试点，则向CGW13通知写入完成(S6109)。

CGW13若从ECU(ID1)接受写入完成的通知，则经由DCM12向中心装置3通知改写状况的进展信息(S6110)。中心装置3基于从DCM12发送来的进展信息，对能够从便携终端6连接的网络画面进行更新(S6111)。便携终端6与中心装置3连接，作为更新后的进展状况，例如显示回滚当前进行到几％等(S6112)。这里，也可以取代便携终端6，利用车载显示器7显示进展。CGW13若从ECU(ID1)接受写入完成的通知，则向车载显示器7通知改写状况的进展信息(S6113)。车载显示器7更新并显示回滚的进展状况的画面(S6114)。CGW13若从ECU(ID1)接受写入完成的通知，则作为下一写入数据，获取第二个分割文件，并向ECU(ID1)分发。此后，直到作为最后的写入数据的第N个分割文件为止，重复S6106～S6114的处理。

ECU(ID1)若完成第N个分割文件的写入，则对闪存的回滚用程序进行完整性验证，确认是否正确地写入(S6115)。CGW13若从ECU(ID1)接受完成全部的分割文件的写入、完整性验证成功的内容的通知，则结束电池余量的监视和总线的通信负荷的监视(S6116、S6117)。

接着，CGW13对ECU(ID2)和ECU(ID3)请求唤醒(S6201)。为了以进行安装前的旧版本启动，CGW13对ECU(ID1)、ECU(ID2)和ECU(ID3)请求回滚用的激活(S6202)。1面独立存储器即ECU(ID1)与通常时的改写同样，通过重新启动将旧版本的程序启动。2面存储器即ECU(ID2)和ECU(ID3)与通常时的改写不同，不切换运用面，而将当前运用面即A面的程序启动。

ECU(ID1)若从CGW13接受回滚用的激活请求，则使自身重新启动(S6203)。ECU(ID1)若完成重新启动，则将程序版本与回滚用的激活完成一同向CGW13通知(S6204)。

ECU(ID2)若从CGW13接受回滚用的激活请求，则不对所存储的运用面信息进行更新，而使自身重新启动(S6205)。ECU(ID2)若在持续运用面即A面正常启动，则将程序版本和运用面信息与回滚用的激活完成一同向CGW13通知(S6206)。

ECU(ID3)若从CGW13接受回滚用的激活请求，则不对所存储的运用面信息进行更新，而使自身重新启动(S6207)。ECU(ID3)若在持续运用面即A面正常启动，则将程序版本和运用面信息与回滚用的激活完成一同向CGW13通知(S6208)。

CGW13若从ECU(ID1)、ECU(ID2)和ECU(ID3)接受回滚用的激活完成通知，则经由DCM12向中心装置3通知回滚完成(S6209)。这里，CGW13还一并地通知与ECU(ID1)、ECU(ID2)和ECU(ID3)相关的程序版本和运用面信息。中心装置3将从DCM12通知的信息登记于数据库(S6210)，并且将网络画面更新为作为进展状况的表示取消完成的显示(S6211)。便携终端6与中心装置3连接，显示完成了取消的内容的网络画面(S6212)。

另外，CGW13若从ECU(ID1)、ECU(ID2)和ECU(ID3)接受分配返回用的激活完成通知，则向车载显示器7通知作为进展状况的完成了回滚的内容(S6213)。车载显示器7显示完成了回滚的内容(S6214)。

最后，CGW13对电源管理ECU20请求IG电源断开(S6215)。为了返回到安装开始前的IG开关断开的状态，电源管理ECU20请求电源控制电路43切断电力供给。若通过电源控制电路43切断对IG电源线39和ACC电源线38的电力供给，则ECU(ID1)、ECU(ID2)、ECU(ID4)、ECU(ID5)和ECU(ID6)成为停止状态。

像以上那样，能够将CGW13作为重编主机，对多个改写对象ECU19进行程序的更新。在本实施方式中，说明了将ECU(ID1)、ECU(ID2)和ECU(ID3)作为一个组而改写应用程序的内容，但在对于作为第二个组的ECU(ID4)、ECU(ID5)和ECU(ID6)改写应用程序时也相同。在该情况下，在对于第一组的ECU19进行了安装和激活之后，对于第二组的ECU19进行安装和激活。

另外，对于DCM12、CGW13、车载显示器装置7和电源管理ECU20等的应用程序，也能够同样地改写。但是，这些ECU需要在程序更新中能够使应用程序进行动作，因此优选由2面存储器构成。

本发明依据实施例来记述，但理解为本发明不限于该实施例、构造。本发明还包含各种变形例、均等范围内的变形。除此之外，各种组合、形式、进一步地仅包含这些元素中仅一个要素、一个要素以上的要素或者一个要素以下的要素的其他的组合、形式也进入本发明的范畴、思想范围。