CN117651932A - 软件更新装置、软件更新系统以及软件更新方法 - Google Patents

Abstract

一种软件更新装置(10)，用于更新搭载于车辆(1)的车载控制装置(14A～14C)的软件，所述软件更新装置(10)具备：信息获取部(41)，其获取与车载控制装置(14A～14C)的软件的更新有关的更新处理信息；输出部(43)，其输出用于向用户征求是否同意软件的更新的同意请求信息；更新处理执行部(45)，其根据作为用户对同意请求信息的答复的答复信息，来执行更新处理；以及控制部(50)，其在更新在更新所需要的估计时间内未完成的情况下，使车载控制装置(14A～14C)执行与更新前软件对应的程序，在更新在估计时间内完成了的情况下，使车载控制装置(14A～14C)执行与更新完毕软件对应的程序。

Description

软件更新装置、软件更新系统以及软件更新方法

技术领域

本发明涉及一种软件更新装置、软件更新系统以及软件更新方法。

背景技术

以往，已知一种能够在与用户的喜好相应的定时自动地更新软件的信息处理终端(专利文献1)。该信息处理终端能够还作为搭载于车辆的车载终端来使用。

现有技术文献

专利文献

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

发明内容

发明要解决的问题

在执行与软件的更新有关的处理的期间不能够启动车辆，因此用户无法使用车辆。上述信息处理终端存在以下问题：在发生了软件的更新不结束这一错误的情况下，作为车载控制装置的执行对象的软件未确定，用户有可能无法使用车辆。

本发明要解决的问题是提供一种即使在发生了软件的更新不结束这一错误的情况下用户也能够使用车辆的软件更新装置、软件更新系统以及软件更新方法。

用于解决问题的方案

本发明通过以下方式来解决上述问题：从设置在车辆的外部的服务器获取与车载控制装置的软件的更新有关的更新处理信息，输出用于向用户征求是否同意软件的更新的同意请求信息，根据作为用户对同意请求信息的答复的答复信息来执行更新处理，在更新在更新所需要的估计时间内未完成的情况下，使车载控制装置执行与更新前软件对应的程序，在更新在估计时间内完成了的情况下，使车载控制装置执行与更新完毕软件对应的程序。

发明的效果

根据本发明，即使在发生了软件的更新不结束这一错误的情况下，也能够决定作为车载控制装置的执行对象的程序，因此用户能够使用车辆。

附图说明

图1是示出包括第一实施方式所涉及的软件更新装置的软件更新系统的一例的框图。

图2是用于说明基于OTA的软件更新的流程的说明图。

图3是用于说明与ECU的存储器结构相应的、基于OTA的软件更新的说明图。

图4是图1所示的软件更新装置的控制器所具有的功能块的一例。

图5是第一实施方式所涉及的软件更新方法的流程图。

图6是第二实施方式所涉及的软件更新装置的控制器所具有的功能块的一例。

图7是第二实施方式所涉及的软件更新方法的流程图。

具体实施方式

下面，基于附图来说明本发明所涉及的软件更新装置、软件更新系统以及软件更新方法的实施方式。

《第一实施方式》

本实施方式所涉及的软件更新装置10如图1所示那样实现为软件更新系统100的一部分。图1是示出本实施方式所涉及的软件更新系统100的一例的框图。软件更新系统100是能够通过OTA(Over The Air：空中下载)来更新由车辆1的电子控制装置(以下，称为ECU(Electronic Control Unit：电子控制单元))执行的车辆控制、诊断等软件的系统。通过这种OTA来更新软件的技术也称为FOTA(Firmware Over The Air：空中固件升级)。通过由ECU所具备的微型计算机执行程序来实现ECU的软件。在本实施方式中，作为通过无线方式进行的ECU的软件更新，举出通过无线方式改写ECU的微型计算机所执行的程序的情况为例来进行说明，但是软件更新系统100例如能够还适用于通过无线方式改写在车辆1的导航系统中使用的地图数据、在ECU中使用的控制参数等在各种软件中使用的数据的情况。另外，在ECU中使用了FPGA(Field Programmable Gate Array：现场可编程门阵列)的情况下，软件更新系统100能够还适用于通过无线方式改写FPGA的功能(逻辑)的情况。另外，在图1中，作为车辆1，图示了一台车辆，但是软件更新系统100是能够以多个车辆1为对象进行软件更新的系统。

另外，在本实施方式中，所谓“ECU的软件更新”，是指ECU的软件的版本变为新版本、即作为微型计算机的执行对象的程序变为新版本。另外，通过无线方式进行的软件更新除了包括从车辆1的外部经由无线获取新版本的程序本身并进行改写的情况以外，还包括从车辆1的外部经由无线获取执行新版本的程序时所使用的各种数据、以及新版本的程序与旧版本的程序的差数据并进行改写的情况。在此后的说明中，将新版本的程序、差数据等软件的更新所需要的数据称为“更新用数据”。另外，将“新版本的程序”称为“新程序”，将“旧版本的程序”称为“旧程序”，将“新版本的程序与旧版本的程序的差数据”称为“差数据”。另外，在本实施方式中，所谓“处理的完成”，是指处理正常结束了的情况，不包括处理异常结束了的情况。另外，在本实施方式中，作为进行与软件的更新有关的手续的用户，举出处于车辆1的车室外的用户为例来进行说明。

如图1所示，软件更新系统100包括车辆1、服务器2以及用户终端3。软件更新系统100所包括的各结构能够经由无线通信线路网4进行信息的发送接收。无线通信线路网4构成为包括例如基于4G线路等的移动体通信网络、因特网、Wifi(Wireless Fidelity：无线保真)(注册商标)等。首先，对软件更新系统100中的车辆1、服务器2以及用户终端3各自的作用进行说明。

车辆1搭载有能够更新软件的ECU。车辆1与服务器2之间进行与软件更新有关的各种信息的发送接收。从车辆1向服务器2发送与搭载于车辆1的各ECU有关的信息。作为与ECU有关的信息，例如能够例举软件的当前的版本。基于规定的发送条件(例如，每规定的周期)从车辆1向服务器2发送与车辆1所搭载的各ECU有关的信息。

另外，从服务器2向车辆1发送与软件更新有关的信息。作为与软件更新有关的信息，例如能够例举活动信息、更新用数据、更新处理所需要的时间的估计、更新的重要程度等。所谓活动，是服务器2将分发包向一个或多个车辆1分发的事件。分发包中包含更新用数据、在更新用数据的认证处理中使用的认证用数据等。活动信息是用于向用户呈现软件更新的概要的信息。关于活动信息的具体例、更新处理所需要的时间的估计，在后面进行叙述。更新处理所需要的时间的估计也可以包含于分发包中。在用户同意了开始进行软件的更新处理的情况下，在车辆1中由后述的软件更新装置10执行软件的更新处理。当在车辆1中开始进行更新处理时，从车辆1向服务器2发送表示更新处理的经过状况的信息。

服务器2是在软件更新系统100中统括软件更新处理并作为OTA中心发挥功能的服务器。服务器2与车辆1之间进行上述的与软件更新有关的各种信息的发送接收。另外，服务器2与用户终端3之间也进行各种信息的发送接收。

服务器2具有保存功能、数据管理功能、活动管理功能以及分发功能等，其中，该保存功能用于保存更新用数据，该数据管理功能用于对各软件的版本、成为更新对象的车辆1的车辆识别号码(VIN：Vehicle Identification Number)、更新对象的ECU等进行管理，该活动管理功能用于对活动信息的分发时机等与活动有关的信息进行管理，该分发功能用于分发活动信息和更新用数据。服务器2例如在从更新用数据的提供商接收到包含更新用数据的各种信息时，将更新用数据保存于存储装置。服务器2基于从提供商接收到的信息来确定作为更新用数据的分发对象的VIN以及更新对象的ECU(此后称为更新对象ECU)。服务器2设定活动信息的分发时机，当来到活动信息的分发时机时，向车辆1和/或用户终端3发送活动信息。在用户同意了向车辆1发送分发包的情况下，服务器2向车辆1发送分发包。在由服务器2进行的分发包的发送完成之后，当在车辆1中开始进行更新处理时，服务器2从车辆1接收表示更新处理的进度状况的进度信息，并将接收到的进度信息发送到用户终端3。

用户终端3具有受理来自用户的操作输入的功能和显示各种画面的功能，是用户能够携带的终端。作为用户终端3，例如能够例举智能手机、平板电脑等。用户终端3与服务器2之间进行活动信息等各种信息的发送接收。用户终端3在从服务器2接收到活动信息时，向用户通知活动信息。另外，在用户对用户终端3进行了表示同意发送分发包的操作的情况下，用户终端3向服务器2发送表示用户同意了的同意信息。另外，用户终端3经由服务器2来与车辆1之间进行与更新处理有关的信息的发送接收。用户终端3在被服务器2输入了用于向用户征求同意更新处理开始的信息的情况下，显示用于向用户征求同意的图像。另外，在用户对用户终端3进行了表示同意更新处理开始的操作的情况下，用户终端3向服务器2发送表示用户同意了的同意信息。当在车辆1中开始进行更新处理时，用户终端3从服务器2接收进度信息，并将接收到的进度信息通知给用户。

接着，使用图1对车辆1、服务器2以及用户终端3各自的结构进行说明。首先对服务器2的结构进行说明。如图1所示，服务器2具备通信装置21、数据库22以及控制装置23。

通信装置21具有经由无线通信线路网4来与车辆1及用户终端3之间进行数据通信的通信功能。为了通信装置21与车辆1之间进行数据的发送接收，车辆1需要位于无线通信线路网4的服务区内。另外，为了通信装置21与用户终端3之间进行数据的发送接收，用户终端3需要位于无线通信线路网4的服务区内。

数据库22保存车辆1的登记信息、活动信息、更新用数据等。车辆1的登记信息至少包含车辆1的VIN、车辆1所搭载的ECU的数量及各ECU的类型、以及各ECU的软件的版本。活动信息包含更新用数据的数据大小、用于识别更新对象ECU的信息(ECU名称、ECU的ID等)、作为更新对象的软件的版本的信息(版本名称、版本的ID等)、被更新的功能的概要说明、直到分发包的下载完成为止的估计时间(下载估计时间)、以及直到车辆1中的更新处理完成为止的估计时间(更新处理估计时间)等。

控制装置23是作为服务器2的指挥塔而发挥功能的装置，例如由处理器和存储器构成，其中，该处理器被以执行通过计算机程序实现的一个或多个功能的方式进行了编程。控制装置23具有上述的数据管理功能、活动管理功能、分发功能等。在本实施方式中，作为控制装置23的功能的一例，对计算更新处理估计时间的功能进行说明。

控制装置23基于更新用数据的数据大小来计算更新处理估计时间。例如，在数据库22中预先保存有表示更新用数据的数据大小与更新处理估计时间之间的关系的对应表的情况下，控制装置23参照该对应表来计算与数据大小相应的更新处理估计时间。另外，例如，更新用数据的数据大小越大，则控制装置23计算出越长的更新处理估计时间。此外，更新用数据的数据大小也可以是新程序本身的数据大小和差数据的数据大小中的任一者。

另外，控制装置23也可以不是基于更新用数据的数据大小而是基于更新对象ECU的类型来计算更新处理估计时间，或者基于更新用数据的数据大小和更新对象ECU的类型来计算更新处理估计时间。例如，控制装置23基于ECU所具备的微型计算机和/或快闪存储器的规格来计算更新处理估计时间。例如，在更新对象ECU所具备的微型计算机的动作频率比规定的基准频率高的情况下控制装置23计算出的更新处理估计时间比在该微型计算机的动作频率比规定的基准频率低的情况下控制装置23计算出的更新处理估计时间短。这是基于微型计算机的动作频率越高则更新处理所需要的时间越短这个观点。另外，例如，在更新对象ECU所具备的快闪存储器的存储器容量比规定的基准容量大的情况下控制装置23计算出的更新处理所需要的时间比在该快闪存储器的存储器容量比规定的基准容量低的情况下控制装置23计算出的更新处理所需要的时间长。这是基于快闪存储器的存储器容量越大、则程序的文件大小越大从而更新处理所需要的时间越长这个观点。另外，更新处理估计时间的计算方法是一例，控制装置23也可以使用其它计算方法来计算更新处理估计时间。

对用户终端3的结构进行说明。如图1所示，用户终端3具备终端通信装置31、终端HMI(Human Machine Interface：人机接口)32以及终端控制装置33。

终端通信装置31具有经由无线通信线路网4来与服务器2之间进行数据通信的功能。终端HMI 32作为受理用户的操作输入的装置和向用户通知信息的装置中的至少任一方而发挥功能。作为终端HMI 32，例如能够例举触摸面板显示器等。此外，终端HMI 32不限于是显示信息的装置，例如也可以是扬声器等将信息以声音形式输出的装置。此外，在用户终端3通过Bluetooth(注册商标)等来与车辆1的车载装置直接连接的情况下，用户终端3也可以经由车辆1的车载通信装置11来与服务器2进行数据通信。另外，在车载装置与用户终端3直接连接的情况下，车载装置也可以从用户终端3经由无线通信线路网4来与服务器2进行通信。

终端控制装置33是作为用户终端3的指挥塔而发挥功能的装置，例如由处理器和存储器构成，其中，该处理器被以执行通过计算机程序实现的一个或多个功能的方式进行了编程。终端控制装置33在车辆1的ECU的软件更新处理中执行用于向用户通知活动信息和更新处理的进度信息的处理。如果举出活动信息为例，终端控制装置33在经由终端通信装置31从服务器2接收到活动信息的情况下，将活动信息输出到终端HMI 32，并使终端HMI 32显示活动信息。另外，终端控制装置33在车辆1的ECU的软件更新处理中执行用于向用户征求同意的同意请求处理。如果举出向用户征求同意更新处理开始的情况为例，则终端控制装置33生成用于向用户征求同意更新处理开始的同意请求图像，将同意请求图像输出到终端HMI 32，并使终端HMI 32显示同意请求图像。

在用户终端3位于无线通信线路网4的服务区内的情况下，处于车辆1的车室外的用户能够一边通过用户终端3确认与软件更新有关的各种信息一边进行操作输入，并进行与软件更新有关的手续。此外，上述的用户终端3的块结构和功能是一例，并不是限定用户终端3。另外，在本实施方式中，举出用户使用用户终端3进行与更新处理有关的手续的情况为例来进行说明，但是本发明所涉及的软件更新装置、软件更新系统以及软件更新方法能够还适用于用户使用车载终端12进行与更新处理有关的手续的情况。

接着，对车辆1的结构进行说明。如图1所示，车辆1包括软件更新装置10、车载通信装置11、车载终端12、点火开关13、车身系统ECU 14A、行驶系统ECU 14B、多媒体系统ECU14C以及电源系统ECU 14D。车辆1所包括的各结构例如通过CAN(Controller AreaNetwork：控制器局域网)、LIN(Local Interconnect Network：局域互连网络)等车载网络进行连接。

车载通信装置11具有经由无线通信线路网4来与服务器2之间进行数据通信的功能。作为车载通信装置11，例如能够例举远程信息控制单元(TCU：Telematics ControlUnit)。

车载终端12是具有受理来自搭乘车辆1的用户(乘员)的操作输入的功能和显示各种画面的功能的终端。作为车载终端12，例如能够例举触摸面板显示器等。从软件更新装置10向车载终端12输入用于向乘员通知各种信息的信号。车载终端12例如在被软件更新装置10输入了用于向乘员征求同意更新处理开始的信息的情况下，显示用于向乘员征求同意的图像。另外，例如在乘员对车载终端12进行了表示同意更新处理开始的操作的情况下，车载终端12向软件更新装置10输出表示乘员已同意的同意信息。在车辆1位于无线通信线路网4的服务区内的情况下，处于车辆1的车室内的用户能够一边通过车载终端12确认与软件更新有关的各种信息一边进行操作输入，并进行与软件更新有关的手续。此外，车载终端12不限于是显示信息的装置，例如也可以是扬声器等将信息以声音形式输出的装置。

点火开关13作为车辆1的启动开关而发挥功能，是用于将车辆1的点火装置接通或断开的开关。例如在乘员进行了将点火装置从接通变为断开的操作的情况下，点火开关13向软件更新装置10输出表示用户的操作内容的信号。

车身系统ECU 14A、行驶系统ECU 14B以及多媒体系统ECU 14C是由软件更新装置10进行更新的对象ECU的一例。各ECU具有微型计算机、电源电路、数据传送电路等来作为功能块，其中，该微型计算机由CPU(Central Processing Unit：中央处理单元)、ROM(ReadOnly Memory：只读存储器)、RAM(Random Access Memory：随机存取存储器)以及快闪存储器(Flash Memory)构成。在快闪存储器中保存有用于实现ECU的软件的程序。通过由微型计算机执行快闪存储器中保存的程序并进行各种处理，来实现ECU的软件。

ECU的快闪存储器根据存储器结构被划分为单存储体存储器和双存储体存储器。单存储体存储器在程序的保存区域和由微型计算机执行的程序的执行区域上没有区别，在微型计算机执行程序的期间，无法在单存储体存储器中改写程序。另一方面，双存储体存储器具有双面的区域来作为程序的保存区域，微型计算机执行双面的保存区域中的任一方的保存区域的程序。因此，在双存储体存储器中，即使在微型计算机执行程序的期间，也能够向不保存执行中的程序的另一方的保存区域写入程序。此后，为了方便，将双存储体存储器所具有的双面的程序保存区域称为第一存储器和第二存储器。

车身系统ECU 14A是进行车辆1的车身系统的控制的ECU的总称。作为车身系统ECU14A，例如能够例举对车辆1的门的锁定/解锁进行控制的门控制用ECU、对车辆1的仪表显示进行控制的仪表控制用ECU、对车辆1的空调的驱动进行控制的空调控制用ECU、对车辆1的车窗的开闭进行控制的车窗控制用ECU等。行驶系统ECU 14B是进行车辆1的行驶系统的控制的ECU的总称。作为行驶系统ECU 14B，例如能够例举对车辆1的驱动源进行控制的驱动源控制用ECU、对车辆1的制动器的驱动进行控制的制动器控制用ECU、对车辆1的动力转向的驱动进行控制的动力转向控制用ECU等。多媒体系统ECU 14C是进行车辆1的多媒体系统的控制的ECU的总称。作为多媒体系统ECU 14C，例如能够例举对车辆1的导航系统进行控制的导航控制用ECU、对车辆1的音频设备进行控制的音频控制用ECU等。

从软件更新装置10向车身系统ECU 14A、行驶系统ECU 14B以及多媒体系统ECU14C输入更新处理的控制信号，各ECU执行软件的更新处理。此外，在图1中，各ECU各示出了1个，但是更新对象ECU的数量没有特别地限定，软件更新系统100能够对多个更新对象ECU更新软件。另外，图1所示的车身系统ECU 14A、行驶系统ECU 14B以及多媒体系统ECU 14C是搭载于车辆1的ECU的一例，并不是限定搭载于车辆1的ECU的类型、ECU的区分方法。另外，车辆1也可以搭载除图1示出的ECU以外的ECU。

电源系统ECU 14D是进行车辆1的电源系统的控制的ECU的总称。作为电源系统ECU14D，例如能够例举对搭载于车辆1的ACC(附件)电源和IG(点火装置)电源进行控制的电源控制用ECU。从软件更新装置10向电源系统ECU 14D输入更新处理的控制信号。例如，电源系统ECU 14D执行使车辆1的点火装置断开的处理。

这里，使用图2和图3对基于OTA的软件更新流程的概要与ECU的存储器结构之间的关系进行说明。图2是用于说明基于OTA的软件更新的流程的说明图。如图2所示，经过多个阶段进行基于OTA的软件更新。具体地说，在基于OTA的软件更新中，依次进行活动信息的通知(步骤S1)、下载(步骤S2)、安装(步骤S3)、激活(步骤S4)、更新完成确认(步骤S5)。

在步骤S1中，从服务器2向车辆1和/或用户终端3发送活动信息，经由车载终端12和/或用户终端3向用户通知活动信息。在步骤S2中，从服务器2向车辆1发送包含更新用数据的分发包，在车辆1中保存分发包。在步骤S3中，对更新对象ECU进行新程序的写入处理。在步骤S4中，通过由微型计算机进行的新程序的读入处理来使新程序有效。在步骤S5中，经由车载终端12和/或用户终端3向用户通知软件更新的完成。

图3是用于说明与ECU的存储器结构相应的、基于OTA的软件更新的说明图。图3将图2所示的多个步骤中的下载、安装、激活以及更新完成确认的各步骤表示为“更新状态”。另外，图3将各更新状态下的车辆1的状态表示为“车辆状态”，将更新对象ECU的动作表示为“对象ECU”，将用户的状态表示为“用户”。图3的(A)是ECU的存储器结构为单存储体的情况下的软件更新流程的一例，图3的(B)是ECU的存储器结构为双存储体的情况下的软件更新流程的一例。

如图3的(A)所示，在更新对象ECU的存储器结构为单存储体的情况下，在车辆1能够行驶的状态下(点火开关13接通)，在车辆1中进行分发包的“下载”。在下载完成后，当在车辆1已停车的状态下点火开关13从接通切换为断开时，进行向用户征求同意更新处理开始的“同意请求”。在本实施方式中，处于车辆1的车室外的用户一边通过用户终端3确认与软件更新有关的各种信息一边进行操作输入，并进行与软件更新有关的手续。

在完成了从服务器2的下载之后，当车辆1的乘员(驾驶员)将点火开关从接通切换为断开时，例如在用户终端3中显示用于征求同意更新处理开始的信息(例如，“是否更新软件？”的显示)以及作为用户能够操作的2个图标的表示同意的图标(例如，“立即”的显示)和表示拒绝的图标(例如，“稍后”的显示)。在用户同意更新处理开始并按下了“立即”的图标的情况下，在车辆1中进行使用了更新用数据的“安装”。具体地说，在ECU的快闪存储器中，在删除旧程序之后进行写入新程序的改写处理。当改写处理完成时，进行使ECU的微型计算机读入新程序的“激活”。之后，经过车辆1的电源重启处理(重新启动处理)，软件更新完成。当软件更新完成时，在用户终端3中显示表示更新已完成的更新完成通知(例如，“软件更新已完成”的显示)。另外，在更新处理完成之后，由电源系统ECU 14D执行使车辆1的点火装置断开的处理。另一方面，在用户不同意更新处理开始并按下了“稍后”的图标的情况下，在车辆1中不开始进行ECU的软件更新处理，由电源系统ECU 14D执行使车辆1的点火装置断开的处理。另外，在用户终端3中显示表示更新处理的延期的更新处理延期通知(例如，“延期到下次”的显示)。

另外，如图3的(B)所示，在ECU的存储器结构为双存储体的情况下，在车辆1能够行驶的状态下，在车辆1中除了进行分发包的“下载”以外，还进行使用了更新用数据的“安装”。在ECU的微型计算机正在执行第一存储器中保存的程序(旧程序)的情况下，在第二存储器中进行写入新程序的写入处理。在安装完成后，当车辆1的乘员(驾驶员)将点火开关13从接通切换为断开时，进行向用户征求同意更新处理开始的“同意请求”。与图3的(A)中的例子同样地，在用户终端3中例如显示用于征求同意更新处理开始的信息、表示同意的图标以及表示拒绝的图标。当用户同意更新处理开始时，进行将微型计算机的作为读入目的地的存储器从第一存储器变更为第二存储器的“激活”。之后，经过车辆1的电源重启处理，软件更新完成。

这样，根据ECU的快闪存储器的结构，在软件更新处理的具体内容中存在“安装”及“激活”与“激活”的差异，但无论是哪一种更新处理，都向乘员征求同意更新处理开始，在乘员进行了同意更新处理开始的操作的情况下，在车辆1中执行更新处理。另外，在更新处理完成了的情况下，用户能够通过显示于用户终端3的更新完成通知来获知更新处理已完成。例如，在存在处于自己家的第一用户和使用车辆1的第二用户的情况下，设为第二用户使车辆1停在自己家的停车场并将点火开关从接通切换为断开，第一用户经由用户终端3进行了软件的更新手续。之后，在第一用户要使用车辆1外出的情况下，确认了更新完成通知的第一用户能够使用软件的更新处理已完成的状态的车辆1。然而，存在以下问题：在由于某种异常而在更新处理的中途发生循环处理等从而更新处理不完成的情况下(还包括更新处理不异常结束的情况)，在用户终端3中不显示更新完成通知，因此第一用户有可能无法使用车辆1。因此，本实施方式所涉及的软件更新装置10通过以下结构和方法来解决上述的问题。

接着，对软件更新装置10进行说明。如图4所示，软件更新装置10具备控制器40。图4是软件更新装置10的控制器40所具有的功能块的一例。控制器40由具备硬件和软件的计算机构成，具有保存有程序的存储器和执行该存储器中保存的程序的CPU等。此外，作为动作电路，能够代替CPU或与该CPU一起使用MPU、DSP、ASIC、FPGA等。

如图4所示，控制器40具有信息获取部41、存储部42、输出部43、开始判定部44、更新处理执行部45、控制部50以及电源处理执行部51来作为功能块。控制器40通过存储器中存储的软件来实现功能块的各功能。

信息获取部41从服务器2经由车载通信装置11获取与软件更新有关的更新处理信息。更新处理信息包含上述的活动信息和分发包。另外，信息获取部41从点火开关13获取表示点火开关13的接通状态或断开状态的信号。另外，信息获取部41从车载终端12获取表示用户的操作的信号。另外，信息获取部41经由服务器2获取表示用户在用户终端3中的操作的信号。例如，在用户按下了显示于用户终端3的同意显示的情况下，信息获取部41从用户终端3经由服务器2获取表示同意显示被用户按下的信号。另外，例如在用户按下了显示于用户终端3的拒绝显示的情况下，信息获取部41从用户终端3经由服务器2获取表示拒绝显示被用户按下的信号。

存储部42作为存储装置而发挥功能，该存储装置存储由信息获取部41获取到的信息中的、从服务器2获取到的信息。作为存储部42，例如使用快闪存储器等非易失性记录介质。存储部42保存从服务器2获取到的活动信息和分发包。另外，存储部42也可以存储与搭载于车辆1的ECU有关的信息(ECU的存储器结构等)。存储部42中存储的各种信息被使用于更新处理执行部45中的处理。

输出部43输出用于向用户征求是否同意更新处理执行部45开始进行更新处理的同意请求信息。作为同意请求信息，例如能够例举图像、声音等，但是向用户征求同意的方法没有特别地限定。例如，从存储器读出如上所述的“是否更新软件？”的显示图像，并经由车载通信装置11将图像信号发送到服务器2。另外，例如输出部43也可以将用于向用户征求是否同意更新处理开始的声音信号与图像信号一起经由车载通信装置11发送到服务器2，或者代替图像信号而将用于向用户征求是否同意更新处理开始的声音信号经由车载通信装置11发送到服务器2。从车载通信装置11发送的同意请求信息被服务器2接收，之后，被从服务器2发送到用户终端3。

另外，在本实施方式中，输出部43在满足了规定的输出条件的情况下输出同意请求信息。输出部43基于由信息获取部41获取到的信息来判定点火开关13是否被乘员从接通操作为断开。在表示点火开关13的状态的信号从接通状态切换为断开状态的情况下，输出部43输出同意请求信息。此外，输出部43的输出条件是一例，输出条件也可以是其它条件。

开始判定部44判定更新处理执行部45是否开始进行更新处理。在用户针对由输出部43输出的同意请求信息同意了更新处理开始的情况下，开始判定部44判定为开始进行更新处理，在用户针对同意请求信息拒绝了更新处理开始的情况下，开始判定部44判定为不开始进行更新处理。例如在用户对用户终端3进行了表示同意更新处理开始的操作的情况下，如上所述，信息获取部41从服务器2获取同意信息，开始判定部44判定为开始进行更新处理。另一方面，例如在用户对用户终端3进行了表示拒绝更新处理开始的操作的情况下，如上所述，信息获取部41从服务器2获取拒绝信息，开始判定部44判定为不开始进行更新处理。

更新处理执行部45根据作为用户对同意请求信息的答复的答复信息，来执行更新处理。在由开始判定部44判定为开始进行更新处理的情况下，更新处理执行部45执行更新处理，在由开始判定部44判定为不开始进行更新处理的情况下，更新处理执行部45使更新处理的执行延期。在更新对象ECU中的更新处理正常地结束了的情况下，从更新对象ECU向更新处理执行部45输入更新处理完成通知，更新处理执行部45将所输入的通知输出到控制部50。此外，在由开始判定部44判定为不开始进行更新处理的情况下，使更新处理的执行延期即可，更新处理执行部45也可以执行其它处理。

更新处理执行部45包括与更新对象ECU存储器结构相应的安装执行部和激活执行部，来作为执行更新处理的功能块。如图4所示，更新处理执行部45包括：存储器结构与单存储体对应的第一安装执行部46及第一激活执行部47；以及存储器结构与双存储体对应的第二安装执行部48及第二激活执行部49。如使用图3所说明的那样，根据ECU的存储器结构是单存储体还是双存储体的不同，在“安装”和“激活”各自的处理内容中产生差异。因此，在本实施方式中，设置有多个安装执行部和多个激活执行部。在更新对象ECU的存储器结构为单存储体的情况下，由第一安装执行部46进行新程序的安装，并由第一激活执行部47进行新程序的激活。另一方面，在更新对象ECU的存储器结构为双存储体的情况下，由第二安装执行部48进行新程序的安装，并由第二激活执行部49进行新程序的激活。更新处理执行部45根据存储部42中存储的与搭载于车辆1的ECU有关的信息，来判别更新对象ECU的存储器结构。

第一安装执行部46在将快闪存储器中保存的旧程序删除之后执行写入新程序的安装处理。第一激活执行部47执行使更新对象ECU所具备的微型计算机读入被写入到快闪存储器中的新程序的激活处理。

在快闪存储器的第一存储器和第二存储器中的第一存储器中保存旧程序且微型计算机读入了旧程序的情况下，第二安装执行部48执行向没有保存旧程序的第二存储器写入新程序的安装处理。第二激活执行部49执行将由更新对象ECU所具备的微型计算机读入的程序的读入目的地从第一存储器切换为第二存储器的激活处理。

控制部50基于更新处理所需要的估计时间来决定更新对象ECU要执行的对象程序。在本实施方式中，更新处理所需要的估计时间是由服务器2计算出的更新处理估计时间。如使用图3所说明的那样，更新处理的具体内容根据更新对象ECU的存储器结构而存在“安装”及“激活”与“激活”的差异。因此，由服务器2计算出的更新处理估计时间的明细根据更新对象ECU的规格而变化。具体地说，在更新对象ECU的存储器结构为单存储体的情况下，更新处理估计时间由安装处理所需要的时间和激活处理所需要的时间构成。在更新对象ECU的存储器结构为双存储体的情况下，更新处理估计时间由激活所需要的时间构成。

在更新处理在更新处理估计时间内未完成的情况下，控制部50使更新对象ECU执行与更新前软件对应的旧程序。另一方面，在更新处理在更新处理估计时间内完成了的情况下，控制部50使更新对象ECU执行与更新完毕软件对应的新程序。

例如，当由更新处理执行部45开始进行更新处理时，控制部50使用于测量更新处理时间的计时器启动，从而开始测量从更新处理开始起的经过时间。控制部50一边将经过时间与更新处理估计时间进行比较，一边等待从更新处理执行部45输入更新处理完成通知。在比更新处理估计时间短的经过时间内输入了更新处理完成通知的情况下，控制部50使更新对象ECU所具备的微型计算机执行新程序。另一方面，在经过时间超过了更新处理估计时间的情况下，控制部50使更新对象ECU所具备的微型计算机执行旧程序。

更详细地说明经过时间超过了更新处理估计时间的情况下的控制部50的处理。在经过时间超过了更新处理估计时间的情况下，控制部50执行与更新对象ECU的存储器结构相应的不同的处理。在存储器结构为单存储体的情况下，控制部50对更新对象ECU执行回滚(Rollback)处理。所谓回滚，是指在中断更新处理的情况下将程序的版本恢复为原始版本等用于使更新对象ECU的快闪存储器恢复为规定状态的写入或回写。也就是说，回滚是指从用户来看将更新对象ECU的状态恢复为开始进行更新处理之前的状态。能够对控制部50应用在提出本申请时已知的回滚处理。例如，在分发包中包含回滚用程序的情况下，控制部50使用回滚用程序对更新对象ECU执行回滚处理。

在存储器结构为双存储体的情况下，控制部50使新程序保存于更新对象ECU的快闪存储器。例如，如果将旧程序的保存目的地设为第一存储器、将新程序的写入目的地设为第二存储器，则控制部50使得保存被写入到第二存储器的新程序。如图3的(B)的例子那样，在点火开关13接通的状态下进行安装，在完成了新程序向第二存储器的写入的情况下，即使更新处理在估计经过时间内未完成，控制部50也使得保存第二程序。

电源处理执行部51向电源系统ECU 14D输出用于使作为车辆1的IG电源的驱动用电池的输出电力为零的控制信号，来使车辆1的点火装置断开。

接着，一边参照图5的流程图一边说明本实施方式所涉及的软件更新方法的一例。图5所示的流程图由图4所示的软件更新装置10的控制器40执行。此外，图5的流程图是更新对象ECU的存储器结构为单存储体的情况下的流程图。另外，图6的流程图是图2所示的下载(步骤S2)～更新完成的确认(步骤S5)的流程图。

在步骤S11中，控制器40从服务器2经由车载通信装置11获取(下载)分发包。分发包包含更新用数据、在更新用数据的认证处理中使用的认证用数据、以及更新处理估计时间。在步骤S12中，控制器40从在步骤S11中获取到的分发包中获取更新处理估计时间。

在步骤S13中，控制器40判定是否通过乘员的操作将点火开关13从接通切换为断开。控制器40从点火开关13获取表示乘员的操作的信号。在乘员将点火开关13从接通切换为断开的情况下，进入步骤S14，在点火开关13维持接通的情况下，在步骤S13中待机，直到乘员将点火开关从接通切换为断开为止。

在步骤S14中，控制器40输出用于向用户征求同意软件的更新处理开始的同意请求信息。在本实施方式中，控制器40经由车载通信装置11向服务器2发送同意请求信息。之后，同意请求信息被从服务器2发送到用户终端3。

在步骤S15中，控制器40判定用户针对在步骤S14中输出的同意请求信息是否同意了。在用户对用户终端3进行了表示同意更新处理开始的操作的情况下，从用户终端3向服务器2发送同意信息来作为用户针对同意请求信息的答复信息。控制器40从服务器2获取同意信息，并判定为开始进行更新处理。在该情况下，进入步骤S16。另一方面，在用户对用户终端3进行了表示拒绝更新处理开始的操作的情况下，从用户终端3向服务器2发送拒绝信息来作为用户针对同意请求信息的答复信息。控制器40从服务器2获取拒绝信息，并判定为不开始进行更新处理。在该情况下，进入步骤S19。

在步骤S15中判定为用户同意了的情况下，进入步骤S16。在步骤S16中，控制器40使更新对象ECU开始进行软件的更新处理。具体地说，在ECU的存储器结构为单存储体的情况下，控制器40执行如图3的(A)的例子所示的安装处理和激活处理。关于各处理的具体内容，引用已经叙述的说明。另外，在该步骤中，控制器40使用于测量更新处理时间的计时器启动，从而开始测量从更新处理开始起的经过时间。

在步骤S17中，控制器40判定在步骤S16中开始的更新处理是否正常结束了。在从更新对象ECU向控制器40输入了更新处理完成通知的情况下，控制器40判定为更新处理正常结束了。在该情况下，进入步骤S18。另一方面，在没有从更新对象ECU输入更新处理完成通知的情况下，控制器40判定为更新处理没有正常结束。在该情况下，进入步骤S20。

在步骤S17中判定为更新处理正常结束了的情况下，进入步骤S18。在步骤S18中，控制器40将更新对象ECU要执行的对象程序决定为新程序，使更新对象ECU执行新程序。在步骤S19中，控制器40执行使车辆1的点火装置断开的处理，来作为与在步骤S13中乘员对点火开关进行的操作对应的处理。具体地说，控制器40向电源系统ECU 14D输出用于使车辆1的点火装置断开的控制信号。当步骤S19的处理结束时，图5所示的流程图中的处理结束。

在步骤S17中判定为更新处理没有正常结束的情况下，进入步骤S29。在步骤S20中，控制器40判定更新处理是否异常结束了。例如，控制器40在从更新对象ECU输入了异常结束通知的情况下，判定为更新处理异常结束了。在该情况下，进入步骤S21。另一方面，例如，控制器40在没有从更新对象ECU输入异常结束通知的情况下，判定为更新处理没有异常结束。在该情况下，进入步骤S22。

在步骤20中判定为更新处理异常结束了的情况下，进入步骤S21。在步骤S21中，控制器40将更新对象ECU要执行的对象程序决定为旧程序，使更新对象ECU执行旧程序。例如，控制器40对更新对象ECU进行回滚处理。当步骤S21的处理结束时，进入步骤S19，控制器40执行上述的步骤S19中的处理。

在步骤S20中判定为更新处理没有异常结束的情况下，进入步骤S22。在步骤S22中，控制器40判定从步骤S16起开始测量的经过时间是否超过了在步骤S12中获取到的更新处理估计时间。在由控制器40判定为经过时间超过了更新处理估计时间的情况下，进入步骤S21，控制器40执行上述的步骤S21中的处理。另一方面，在由控制器40判定为经过时间没有超过更新处理估计时间的情况下，返回到步骤S17，此后，执行上述的各步骤中的处理，直到图5中的处理结束为止。

关于更新对象ECU的存储器结构为双存储体的情况下的流程图，使用图5来仅说明与单存储体时的处理不同的步骤。在存储器结构为双存储体的情况下，当步骤S11的处理结束时，控制器40在进入步骤S12之前，使用在步骤S11中获取到的新程序来执行安装处理。具体地说，在ECU的存储器结构为双存储体的情况下，控制器40执行如图3的(B)的例子所示的安装处理。关于处理的具体内容，引用已经叙述的说明。

另外，在步骤S12中，控制器40获取激活处理的估计时间来作为更新处理估计时间。因此，步骤S22中的与经过时间进行比较的比较对象为激活处理的估计处理时间。另外，在步骤S16中，控制器40执行激活处理来作为针对更新对象ECU的软件的更新处理。在ECU的存储器结构为双存储体的情况下，控制器40执行如图3的(B)的例子所示的激活处理。关于处理的具体内容，引用已经叙述的说明。另外，在步骤S21中，控制器40使得保存被写入到存储器的新程序，将ECU的微型计算机的读入目的地切换为保存有旧程序的存储器。

如上所述，本实施方式所涉及的软件更新装置10是用于更新搭载于车辆1的车身系统ECU 14A、行驶系统ECU 14B、多媒体系统ECU 14C的软件的软件更新装置。软件更新装置10具备输出部43、更新处理执行部45以及控制部50。输出部43从服务器2获取与软件的更新有关的更新处理信息。更新处理执行部45根据作为用户对同意请求信息的答复的答复信息，来执行更新处理。控制部50基于更新处理估计时间来决定更新对象ECU要执行的对象程序。另外，在更新处理在更新处理估计时间内未完成的情况下，控制部50使更新对象ECU执行旧程序，在软件的更新在更新处理估计时间内完成了的情况下，控制部50使更新对象的ECU执行新程序。

作为引起软件的更新处理不结束这一错误的原因，例如考虑更新对象ECU的周边环境等。例如，当更新对象ECU的周边温度因某种原因而上升时，更新对象ECU执行基于温度传感器的检测结果的自诊断处理，微型计算机的运算负荷降低。认为如果微型计算机的运算负荷降低，则微型计算机的处理速度下降，导致更新处理不结束这一错误。然而，根据本实施方式所涉及的软件更新装置10、软件更新系统100以及软件更新方法，即使在由于这种原因而发生了更新处理不结束这一错误的情况下，也能够决定更新对象ECU要执行的对象程序，因此车辆1成为能够使用的状态，用户能够使用车辆1。

另外，在本实施方式中，信息获取部41从服务器2获取更新处理估计时间。由此，软件更新装置10不计算更新处理估计而能够决定更新对象ECU要执行的对象程序，因此能够减轻软件更新装置10中的运算负荷。

另外，在本实施方式中，更新对象ECU具有保存旧程序的快闪存储器，更新处理执行部45包括第一安装执行部46和第一激活执行部47。第一安装执行部46在从快闪存储器删除了旧程序之后执行向快闪存储器写入新程序的安装处理。第一激活执行部47执行使微型计算机读入被写入到快闪存储器中的新程序的激活处理。在更新处理在更新处理估计时间内未完成的情况下，控制部50对更新对象ECU执行回滚处理。由此，即使在更新对象ECU的存储器结构为单存储体的情况下，也能够针对更新处理不结束这一错误的发生决定更新对象ECU要执行的对象程序。

另外，在本实施方式中，更新对象ECU具有快闪存储器，该快闪存储器由保存旧程序的第一存储器和第二存储器的双存储体构成，更新处理执行部45包括第二安装执行部48和第二激活执行部49。第二安装执行部48向第二存储器写入新程序。第二激活执行部49执行将微型计算机的程序的读入目的地从第一存储器切换为第二存储器的激活处理。控制部50使得保存被写入到第二存储器的新程序，来作为更新处理在更新处理估计时间内未完成的情况下的处理。由于能够在更新对象ECU的第二存储器中保存新程序，因此在再次进行更新处理时，不需要进行安装，能够减轻软件更新装置10的运算负荷。

另外，在本实施方式所涉及的软件更新系统100中，服务器2基于更新用数据的大小和更新对象ECU的类型中的至少任一方，来计算更新处理估计时间。由此，能够减轻软件更新装置10中的运算负荷。

此外，在本实施方式中，举出软件更新装置10从服务器2获取更新处理估计时间的结构为例进行了说明，但是计算更新处理估计时间的主体不限定于是服务器2，也可以由软件更新装置10计算更新处理估计时间。

作为本实施方式的变形例，控制器40也可以具有计算部来作为功能块，该计算部基于更新用数据的数据大小和更新对象ECU的类型中的至少任一方，来计算更新处理估计时间。例如，在存储部42中预先保存有表示更新用数据的数据大小与更新处理估计时间之间的关系的对应表的情况下，计算部也可以参照该对应表来计算与数据大小相应的更新处理估计时间。另外，例如也可以是，更新用数据的数据大小越大，则计算部计算出越长的更新处理估计时间。另外，例如，控制装置23也可以基于ECU所具备的微型计算机和/或快闪存储器的规格来计算更新处理估计时间。关于具体的计算方法的例子，引用上述的控制装置23中的计算方法的例子。如变形例那样，通过由软件更新装置10计算更新处理估计时间，能够减轻服务器2中的运算负荷。此外，控制器40计算更新处理估计时间的时机只要是开始进行更新处理之前即可，没有特别地限定，例如，在图5的流程图的步骤S12中，控制器40计算更新处理估计时间，来代替获取更新处理估计时间。

《第二实施方式》

接着，对第二实施方式所涉及的软件更新装置进行说明。在上述的第一实施方式中，举出图2所示的基于OTP的软件更新的各步骤中的安装(步骤S3)和激活(步骤S4)为例进行了说明，但是在本实施方式中，对除了包括安装和激活以外还包括下载(步骤S2)的例子进行说明。例如，假定以下场景：在步骤S1中通知了活动信息之后向用户征求是否同意更新开始，在用户同意的情况下，之后不向用户征求同意就依次进行下载～激活。作为一例，能够例举以下场景：在车辆停在自己家的停车场等、车辆没有被用户使用的状况下，进行基于OTP的软件更新。

第二实施方式所涉及的软件更新系统相对于第一实施方式所涉及的软件更新系统100而言，除了服务器2所计算的估计时间以及软件更新装置10的控制器60所具备的功能块不同以外，与第一实施方式所涉及的软件更新系统100为相同结构。因此，关于与第一实施方式相同的结构，引用已经叙述的说明。

在本实施方式中，服务器2将直到分发包的下载完成为止的下载估计时间和第一实施方式中的更新处理估计时间相加来计算为直到软件的更新完成为止的估计时间(更新完成估计时间)。服务器2向一个或多个车辆1分发包含更新完成估计时间的活动信息。

服务器2的控制装置23基于分发包的数据大小来计算下载估计时间。例如，在数据库22中预先保存有表示分发包的数据大小与下载估计时间之间的关系的对应表的情况下，控制装置23参照该对应表来计算与数据大小相应的下载估计时间。另外，例如，分发包的数据大小越大，则控制装置23计算出越长的下载估计时间。

接着，对本实施方式的控制器40的功能块进行说明。图6是本实施方式所涉及的软件更新装置10的控制器60所具有的功能块的一例。在本实施方式中，控制器60除了具有第一实施方式中的功能块以外，还具有通信状况获取部52、校正部53以及通知部54。另外，在本实施方式中，输出部43的功能有一部分与第一实施方式中的输出部43的功能不同。控制器60通过存储器中存储的软件来实现功能块的各功能。此外，关于与第一实施方式相同的功能块，引用第一实施方式中的说明。

在本实施方式中，不仅在由更新处理执行部45进行的更新处理中，还包括从服务器2下载分发包的处理在内，输出部43输出用于向用户征求是否同意软件的更新的同意请求信息。关于同意请求信息的具体例和直到发送到用户终端3为止的方法，引用第一实施方式中的说明。另外，在本实施方式中，输出部43在从由信息获取部41获取活动信息起直到信息获取部41获取分发包为止的期间输出同意请求信息。

通信状况获取部52获取与同服务器2之间的通信状况有关的通信状况信息。通信状况获取部52在车载通信装置11与服务器2的通信装置21之间探测通信状态，获取所探测到的通信状态来作为通信状况信息。例如，在车载通信装置11与通信装置21之间为通信不成立的状态的情况下，通信状况获取部52探测为通信状态异常。另外，通信状况获取部52也可以计算无线数据通信中的延迟时间。延迟时间包括由车载通信装置11的能力决定的固定的延迟时间以及根据访问无线通信线路网4的通信装置的多少、进行通信的数据大小(通信费用)等而发生变动的延迟时间。能够对通信状况获取部52应用在提出本申请时已知的获取通信状况的技术。

校正部53从活动信息中获取更新完成估计时间，基于由通信状况获取部52获取到的通信状况信息来对更新完成估计时间进行校正。对于更新完成估计时间中的由服务器2计算出的下载估计时间，由于没有考虑实际的通信状况，因此下载估计时间与实际的下载时间有可能不同。例如，存在以下情况：由于车载通信装置11与通信装置21之间的通信状态良好，因此无线数据通信中的延迟时间变短，实际的下载时间比下载估计时间提前。校正部53根据无线数据通信中的延迟时间来缩短下载估计时间。当然，还存在以下情况：由于车载通信装置11与通信装置21之间的通信状态差，因此无线数据通信中的延迟时间变长，实际的下载时间比下载估计时间晚。在该情况下，校正部53根据通信状况信息中包含的无线数据通信中的延迟时间来延长下载估计时间。

通知部54输出将由校正部53进行了校正的下载估计时间(此后称为校正后的下载估计时间)与更新处理估计时间相加所得到的更新估计时间(此后称为校正后的更新估计时间)的信息。在本实施方式中，通知部54经由车载通信装置11向服务器2发送校正后的更新估计时间的信息。从车载通信装置11发送的校正后的更新估计时间的信息被服务器2接收，之后，被从服务器2发送到用户终端3。通过在用户终端3中显示校正后的更新估计时间的信息，来向用户通知校正后的估计时间。

另外，作为输出校正后的更新估计时间的信息的输出条件，通知部54也可以在校正后的更新估计时间比由服务器2计算出的更新估计时间(此后称为校正前的更新估计时间)长规定的阈值时间以上的情况下，输出校正后的更新估计时间。作为规定的阈值时间，例如能够例举5分钟等以分钟为单位的时间这样的预先决定的时间。在预计实际的更新时间与估计时间相比大幅地延迟的情况下，给用户对于是否同意更新的判断带来影响的可能性高，因此在下载分发包之前向用户通知校正后的更新时间。另一方面，通知部54也可以在校正后的更新估计时间比校正前的更新估计时间短的情况下不输出校正后的估计时间。在预计实际的更新时间比估计时间提前的情况下，给用户对于是否同意更新的判断带来影响的可能性低，因此在下载分发包之前不向用户通知校正后的更新时间。

接着，一边参照图7的流程图一边说明本实施方式所涉及的软件更新方法的一例。图7所示的流程图由图6所示的软件更新装置10的控制器60执行。此外，图7的流程图是更新对象ECU的存储器结构为单存储体的情况下的流程图。另外，图7的流程图是图2所示的、活动信息的通知(步骤S1)～更新完成的确认(步骤S5)的流程图。另外，图7的流程图包括一部分与图6的流程图相同的步骤。对与图6相同的步骤标注与图6的步骤相同的附图标记，关于与图6相同的步骤，引用已经叙述的说明。在图7的流程图中，设为点火开关13是断开的，省略了图6所示的步骤S19。此外，在图7的流程图中，也可以进行图6所示的步骤S19中的处理。

在步骤S31中，控制器60从服务器2经由车载通信装置11获取(下载)活动信息。活动信息包含更新用数据的数据大小、用于识别更新对象ECU的信息、作为更新对象的软件的版本的信息、被更新的功能的概要说明、下载估计时间以及更新处理估计时间等。在步骤S32中，控制器60从在步骤S31中获取到的活动信息中获取将下载估计时间与更新处理估计时间相加所得到的更新估计时间。

在步骤S33中，控制器60基于与同服务器2之间的通信状况有关的通信状况信息，来对在步骤S32中获取到的更新估计时间中的下载估计时间进行校正。控制器60输出将被进行了校正的下载估计时间与在步骤S31中获取到的更新处理估计时间相加所得到的校正后的更新估计时间。在本实施方式中，控制器60经由车载通信装置11和服务器2向用户终端3发送校正后的更新估计时间。

在步骤S34中，控制器60输出用于向用户征求同意软件的更新的同意请求信息。在本实施方式中，控制器60经由车载通信装置11和服务器2向用户终端3发送同意请求信息。

在步骤S35中，控制器60判定用户针对在步骤S34中输出的同意请求信息是否同意了。在用户对用户终端3进行了表示同意软件的更新的操作的情况下，从用户终端3向服务器2发送同意信息来作为用户针对同意请求信息的答复信息。控制器60从服务器2获取同意信息，并判定为开始进行软件的更新。另外，在本实施方式中，在判定为用户同意了的情况下，控制器60使用于测量分发包的下载时间和更新处理时间的计时器启动，从而开始测量从下载分发包起的经过时间。

另一方面，在用户对用户终端3进行了表示拒绝更新处理开始的操作的情况下，从用户终端3向服务器2发送拒绝信息来作为用户针对同意请求信息的答复信息。控制器60从服务器2获取拒绝信息，结束图7所示的流程图中的处理。

在步骤S35中判定为用户同意了的情况下，进入步骤S11，与第一实施方式同样地，开始由控制器60下载分发包。在完成了分发包的下载之后，进入步骤S16，与第一实施方式同样地，开始由控制器60进行更新处理。

步骤S37是与图6所示的步骤S22对应的步骤。在步骤S37中，控制器60将在步骤S35中用户同意了的情况下开始测量的测量时间与在步骤S33中进行校正所得到的校正后的更新估计时间进行比较，来判定经过时间是否超过了校正后的更新估计时间。除了经过时间的起算时机和经过时间的比较对象不同以外，与步骤S22相同，因此引用已经叙述的说明。

如上所述，本实施方式所涉及的软件更新装置10具备通信状态获取部52、校正部53以及通知部54。通信状况获取部52获取与同服务器2之间的通信状况有关的通信状况信息。校正部53基于通信状况信息来对更新估计时间进行校正。通知部54输出校正后的更新估计时间的信息。由此，能够提高下载估计时间的精度。另外，由于能够向用户通知包含下载估计时间的更新估计时间，因此用户能够识别包括下载在内的软件更新所需要的估计时间。

另外，在本实施方式中，在校正后的更新估计时间比校正前的更新估计时间长预先设定的规定的阈值时间以上的情况下，通知部54输出校正后的更新估计时间的信息。由此，例如，即使在由于车载通信装置11与通信装置21之间的通信状态差而实际的下载时间比下载估计时间晚的情况下，用户也能够识别考虑了实际的通信状况的估计时间。

另外，在本实施方式中，在校正后的更新估计时间比校正前的更新估计时间短的情况下，通知部54不输出校正后的更新估计时间的信息。由此，例如，在由于车载通信装置11与通信装置21之间的通信状态良好而实际的下载时间比下载估计时间提前的情况下，能够省略向用户通知估计时间的处理。其结果，能够实现基于OTP的软件更新流程整体所需要的时间的缩短。

此外，以上说明的实施方式是为了使本发明易于理解而记载的，不是为了限定本发明而记载的。因而，上述的实施方式中公开的各要素的主旨在于还包括属于本发明的技术范围内的全部设计变更、等同物。

例如，在上述的第一实施方式中，举出在车辆1能够行驶的状态下进行分发包的下载的流程为例进行了说明，但是能够将第一实施方式中的“更新处理估计时间”置换为第二实施方式中的“将下载估计时间与更新处理估计时间相加所得到的更新估计时间”。例如，在第一实施方式的变形例中，举出控制器40具有计算更新处理估计时间的计算部的结构为例进行了说明，但是第二实施方式所涉及的控制器60也可以具有计算更新估计时间中的下载估计时间的计算部。在车辆1沿行驶路径行驶的情况下，信息获取部41从车辆1的导航系统(未图示)获取车辆1的行驶路径的信息。计算部基于由通信状况获取部52获取到的通信状况信息和由信息获取部41获取到的车辆1的行驶路径来计算下载估计时间。例如，计算部从通信运营商所提供的表示无线通信线路网4的通信状况的通信地图获取行驶路径上的多个地点的无线通信线路网4的通信状况信息。计算部基于车辆1在行驶路径上的通信状况信息来计算车辆1沿行驶路径行驶的情况下的下载估计时间。在车辆1能够行驶的状态下能够提高下载分发包的情况下的下载估计时间的精度。

另外，例如，在上述的第二实施方式中，举出对更新估计时间进行校正的结构为例进行了说明，但是不限定于是对更新估计时间进行校正的结构。控制器60也可以使用校正前的更新估计时间来决定更新对象ECU的执行对象程序。

另外，例如，在上述的第二实施方式中，举出在图2所示的下载(步骤S2)～更新完成的通知(步骤S5)为止的期间不存在向用户的同意请求的流程为例进行了说明，但是控制器60也可以在各步骤的处理开始之前输出用于向用户征求是否同意处理开始的同意请求信息。另外，控制器60也可以对更新对象ECU执行回滚处理，来作为存储器结构为双存储体且经过时间超过了更新估计时间(还包括进行了校正的情况)的情况下的处理。例如，在图7的流程图中，假设实际的下载时间比下载估计时间长，在执行安装处理的期间判定为经过时间超过了校正后的更新估计时间(在步骤S36中判定为“是”)。在该情况下，由于新程序向第二存储器的写入未完成，因此控制器60对更新对象ECU执行回滚处理。即使在更新对象ECU的存储器结构为双存储体且新程序的写入未完成的情况下，也能够决定更新对象ECU要执行的对象程序，因此车辆1成为能够使用的状态，用户能够使用车辆1。

另外，例如，控制器60也可以具备测量部，该测量部测量从更新处理开始起直到更新处理完成为止所需要的实际的所需时间。当测量部的测量完成时，输出部43经由车载通信装置11向服务器2发送更新处理所需要的实际的所需时间的信息。由此，能够反映到针对没有完成软件更新的其它车辆1的更新处理估计时间，能够提高更新处理估计时间的精度。

附图标记说明

100：软件更新系统；1：车辆；10：软件更新装置；40：控制器；41：信息获取部；42：存储部；43：输出部；44：开始判定部；45：更新处理执行部；46：第一安装执行部；47：第一激活执行部；48：第二安装执行部；49：第二激活执行部；50：控制部；51：电源处理执行部；11：车载通信装置；12：车载终端；13：点火开关；14A：车身系统ECU；14B：行驶系统ECU；14C：多媒体系统ECU；14D：电源系统ECU；2：服务器；21：通信装置；22：数据库；23：控制装置；3：用户终端；31：终端通信装置；32：终端HMI；33：终端控制装置。

Claims (14)

1.一种软件更新装置，用于更新搭载于车辆的车载控制装置的软件，所述软件更新装置具备：

信息获取部，其从设置在所述车辆的外部的服务器获取与所述软件的更新有关的更新处理信息；

输出部，其输出用于向用户征求是否同意所述软件的更新的同意请求信息；

执行部，其根据作为所述用户对所述同意请求信息的答复的答复信息，来执行所述软件的更新处理；以及

控制部，其基于所述更新所需要的估计时间来决定所述车载控制装置要执行的对象程序，

其中，在所述更新在所述估计时间内未完成的情况下，所述控制部使所述车载控制装置执行与更新前软件对应的程序，

在所述更新在所述估计时间内完成了的情况下，所述控制部使所述车载控制装置执行与更新完毕软件对应的程序。

2.根据权利要求1所述的软件更新装置，其中，

所述信息获取部从所述服务器获取所述估计时间。

3.根据权利要求1所述的软件更新装置，其中，

还具备计算部，所述计算部基于用于更新所述软件的数据的大小和所述车载控制装置的类型中的至少任一方，来计算所述估计时间。

4.根据权利要求1～3中的任一项所述的软件更新装置，还具备：

通信状况获取部，其获取与同所述服务器之间的通信状况有关的通信状况信息；

校正部，其基于所述通信状况信息来对所述估计时间进行校正；以及

通知部，其输出被进行了所述校正的估计时间的信息。

5.根据权利要求4所述的软件更新装置，其中，

在被进行了所述校正的估计时间比所述估计时间长规定的阈值时间以上的情况下，所述通知部输出被进行了所述校正的估计时间的信息。

6.根据权利要求4或5所述的软件更新装置，其中，

在被进行了所述校正的估计时间比所述估计时间短的情况下，所述通知部不输出被进行了所述校正的估计时间的信息。

7.根据权利要求1或2所述的软件更新装置，还具备：

通信状况获取部，其获取表示与所述服务器之间的通信状况的通信信息；以及

计算部，其计算所述估计时间，

所述信息获取部获取所述车辆的行驶路径的信息，

所述计算部基于所述车辆的行驶路径和所述通信状况来计算所述估计时间。

8.根据权利要求1～7中的任一项所述的软件更新装置，其中，

所述车载控制装置具有第一存储器，所述第一存储器保存用于实现旧版本的所述软件的第一程序，

所述执行部包括：

安装执行部，其在从所述第一存储器删除了所述第一程序之后执行向所述第一存储器写入用于实现新版本的所述软件的第二程序的安装处理；以及

激活执行部，其执行用于读入被写入到所述第一存储器中的所述第二程序的激活处理，

在所述更新处理在所述估计时间内未完成的情况下，所述控制部对所述车载控制装置执行回滚处理。

9.根据权利要求1～7中的任一项所述的软件更新装置，其中，

所述车载控制装置具有第一存储器和第二存储器，其中，所述第一存储器保存用于实现旧版本的所述软件的第一程序，

所述执行部包括：

安装执行部，其向所述第二存储器写入用于实现新版本的所述软件的第二程序；以及

激活执行部，其执行将程序的读入目的地从所述第一存储器切换为所述第二存储器的激活处理，

所述控制部使得保存被写入到所述第二存储器的所述第二程序，来作为所述更新处理在所述估计时间内未完成的情况下的处理。

10.根据权利要求9所述的软件更新装置，其中，

所述控制部对所述车载控制装置执行回滚处理，来作为所述更新在所述估计时间内未完成的情况下的处理。

11.根据权利要求1～7中的任一项所述的软件更新装置，其中，

还具备测量部，所述测量部测量从所述更新处理开始起直到所述更新处理完成为止所需要的实际的所需时间，

所述输出部向所述服务器输出所述实际的所需时间的信息。

12.一种软件更新系统，包括：

根据权利要求1～11中的任一项所述的软件更新装置；以及

所述服务器。

13.根据权利要求12所述的软件更新系统，其中，

所述服务器基于用于更新所述软件的数据的大小和所述车载控制装置的类型中的至少任一方，来计算所述估计时间。

14.一种软件更新方法，是由控制器更新搭载于车辆的车载控制装置的软件的软件更新方法，包括：

从设置在所述车辆的外部的服务器获取与所述软件的更新有关的更新处理信息；

输出用于向用户征求是否同意所述软件的更新的同意请求信息；

根据作为所述用户对所述同意请求信息的答复的答复信息，来执行所述软件的更新处理；

在所述更新在所述更新所需要的估计时间内未完成的情况下，使所述车载控制装置执行与更新前软件对应的程序；以及

在所述更新在所述估计时间内完成了的情况下，使所述车载控制装置执行与更新完毕软件对应的程序。