CN114115929A - 软件更新装置、更新控制方法以及非临时存储介质 - Google Patents

Abstract

本发明为一种软件更新装置，被配置为对搭载于车辆的电子控制单元的软件更新进行控制，具有：一个或多个存储装置，其被配置为，对用于从服务器下载所述电子控制单元的更新数据的相互不同的第一软件及第二软件进行存储；一个或多个处理器，其被配置为，通过执行所述第一软件及所述第二软件中的任一个而从所述服务器下载所述更新数据。

Description

软件更新装置、更新控制方法以及非临时存储介质

技术领域

本发明涉及一种用于对电子控制单元的软件的更新进行控制的软件更新装置、更新控制方法以及非临时存储介质。

背景技术

在车辆上搭载了用于控制车辆的动作的多个电子控制单元(ECU)。ECU具有处理器、RAM那样的临时存储部、闪存ROM那样的非易失性的存储部，处理器通过执行存储在非易失性的存储部中的软件来实现ECU的控制功能。各ECU存储的软件能够进行改写，通过更新为较新版本的软件，能够改善各ECU的功能、追加新的车辆控制功能。

更新ECU的软件的技术的示例为OTA(Over The Air)技术，在该技术中，通过以无线的方式将与车载网络连接的车载通信设备与互联网等通信网络连接，经由无线通信从服务器下载软件，并通过安装下载的软件来实施ECU的程序更新、追加(例如，参照日本特开2004-326689)。

在设置于中心的服务器中，通过安装OTA用软件而实现的软件分发功能。另一方面，搭载于车辆的软件更新装置使用与服务器执行的OTA用软件对应的客户端软件，实施针对服务器的更新数据的确认请求、更新数据的下载。

发明内容

在车辆的使用期间，在服务器中使用的OTA用软件可能被改变。在服务器中使用的OTA用软件被改变而在服务器与车辆中提供OTA用软件的供应商成为不同的情况下，如果在供应商之间没有软件的兼容性，则不能够实施基于OTA的软件更新。

本发明提供了一种在服务器中的OTA用软件被改变的情况下也能够实施基于OTA的软件更新的软件更新装置、更新控制方法及非临时存储介质。

本发明的第一方式涉及的软件更新装置被配置为对搭载于车辆的电子控制单元的软件更新进行控制，具有：一个或多个存储装置，其被配置为，对用于从服务器下载所述电子控制单元的更新数据的相互不同的第一软件及第二软件进行存储；一个或多个处理器，其被配置为，通过执行所述第一软件及所述第二软件中的任一个而从所述服务器下载所述更新数据。

本发明的第二方式涉及的更新控制方法为了控制搭载于车辆的电子控制单元的软件更新并由计算机执行，所述计算机具有处理器、存储器、存储装置，所述更新控制方法的特征在于，具有：对用于从服务器下载所述电子控制单元的更新数据的相互不同的第一软件及第二软件进行存储的步骤；通过执行所述第一软件及所述第二软件中的任一个而从所述服务器下载所述更新数据的步骤。

本发明的第三方式涉及的非临时存储介质存储能够由计算机执行的、为了控制搭载于车辆的电子控制单元的软件更新而使所述计算机执行以下功能的更新控制程序，所述计算机具有处理器、存储器、所述非临时存储介质，所述功能具有：对用于从服务器下载所述电子控制单元的更新数据的相互不同的第一软件及第二软件进行存储的步骤；通过执行所述第一软件及所述第二软件中的任一个而从所述服务器下载所述更新数据的步骤。

根据本发明，能够提供一种在服务器中的OTA用软件被改变的情况下也能够实施基于OTA的软件更新的软件更新装置、更新控制方法及非临时存储介质。

附图说明

以下，参考附图，说明本发明的示例性实施例的特征、优点以及技术和工业意义，在附图中，相同的标记表示相同的元件。

图1是表示实施方式涉及的网络系统的整体结构的框图。

图2是表示图1所示的服务器的概要结构的框图。

图3是表示图1所示的软件更新装置的概要结构的框图。

图4是第一实施方式涉及的服务器的功能框图。

图5是第一实施方式涉及的软件更新装置的功能框图。

图6A是表示第一实施方式中的软件切换的概要的示意图。

图6B是表示第一实施方式中的软件切换的概要的示意图。

图6C是表示第一实施方式中的软件切换的概要的示意图。

图7是表示第一实施方式涉及的服务器执行的控制处理的示例的流程图。

图8是表示第一实施方式涉及的软件更新装置执行的控制处理的示例的流程图。

图9是第二实施方式涉及的服务器的功能框图。

图10是第二实施方式涉及的软件更新装置的功能框图。

图11A是表示第二实施方式中的软件选择的概要的示意图。

图11B是表示第二实施方式中的软件选择的概要的示意图。

图12A是表示第二实施方式中的软件追加的概要的示意图。

图12B是表示第二实施方式中的软件追加的概要的示意图。

图12C是表示第二实施方式中的软件追加的概要的示意图。

图13是表示第二实施方式涉及的服务器执行的控制处理的示例的流程图。

图14是表示第二实施方式涉及的软件更新装置执行的控制处理的示例的流程图。

具体实施方式

(与第一及第二实施方式共通的结构)

图1是表示实施方式涉及的网络系统的整体结构的框图，图2是表示图1所示的服务器的概要结构的框图，图3是表示图1所示的软件更新装置的概要结构的框图。

图1所示的网络系统是用于对搭载于车辆的电子控制单元13a～13d的软件进行更新的系统，具有服务器1(中心)、搭载于车辆的车载网络2。

服务器1能够经由网络5与搭载于车辆的软件更新装置11进行通信，并对搭载于车辆的电子控制单元13a～13d的软件更新进行管理。

如图2所示，服务器1包含CPU21、RAM22、存储装置23、通信装置24。此外，服务器1也可以具有多个CPU21。服务器1可以具有多个RAM22。服务器1可以具有多个存储装置23。此外，服务器1也可以具有多个通信装置24。存储装置23具有硬盘、SSD等可读写的存储介质，并存储用于执行软件的更新管理的程序、用于更新管理的信息、电子控制单元的更新数据。在服务器1中，CPU21通过使用RAM22作为工作区域来执行从存储装置23读取的程序，从而执行后述的控制处理。通信装置24是经由网络与软件更新装置11实施通信的设备。

车载网络2包含软件更新装置11(OTA主机)、通信模块12、多个电子控制单元13a～13d、显示装置14。软件更新装置11经由总线15a与通信模块12连接，经由总线15b与电子控制单元13a及13b连接，经由总线15c与电子控制单元13c及13d连接，经由总线15d与显示装置14连接。软件更新装置11能够经由通信模块12与服务器1进行无线的通信。软件更新装置11根据从服务器1取得的更新数据，对电子控制单元13a～13d中的更新对象的电子控制单元(目标ECU)的软件更新进行控制。软件更新装置11有时也被称为中央网关。通信模块12是将车载网络2与服务器1连接的通信设备。电子控制单元13a～13d控制车辆的各部的动作。显示装置14(HMI)用于在电子控制单元13a～13d的软件的更新处理时，实施存在更新数据的显示、用于向用户、管理者请求批准软件更新的批准请求画面的显示、更新结果的显示等各种显示。作为显示装置14，典型地能够使用汽车导航系统的显示装置，但只要是能够显示程序的更新处理时所需的信息的装置即可，没有特别限定。此外，在图1中，例示了四个电子控制单元13a～13d，但电子控制单元的数量没有特别限定。此外，在图1所示的总线15d上，还可以连接了显示装置14以外的电子控制单元。

电子控制单元13a～13d分别具有CPU、RAM、非易失性存储器(存储器)、通信装置。此外，电子控制单元13a～13d也可以分别具有多个CPU。电子控制单元13a～13d也可以分别具有多个RAM。电子控制单元13a～13d也可以分别具有多个非易失性存储器。此外，电子控制单元13a～13d也可以分别具有多个通信装置。CPU通过使用RAM作为工作区域执行从非易失性存储器读取的软件(程序)，从而实现各电子控制单元的功能。在此，电子控制单元具有用于存储软件的一个数据存储区域(库)和用于存储软件的两个数据存储区域(库)。在电子控制单元的数据存储区域中，除了用于实现电子控制单元的功能的软件之外，有时还存储版本信息、参数数据、启动用的引导程序、软件更新用的程序等。在具有一个数据存储区域的电子控制单元中，由于在数据存储区域中安装更新数据，对电子控制单元的软件产生影响。另一方面，在具有两个数据存储区域的电子控制单元中，将两个数据存储区域中的任一个作为读取对象的存储区域(操作面)，执行存储在读取对象的存储区域中的软件。在非读取对象的另一方的存储区域(非操作面)中，在读取对象的存储区域(操作面)的程序的执行中，能够在后台写入更新数据。在软件更新处理中的激活时，通过切换基于CPU41的程序的读取对象的存储区域，能够使更新版本的软件有效化。

此外，在本发明中，在具有两个数据存储区域的电子控制单元中，包含：将非易失性存储器具有的一个面的数据存储区域虚拟地划分为双面，并在执行一个面的程序的期间能够在另一面写入程序的被称为“单面挂起存储器”的结构的存储器的电子控制单元；除了具有一个面的数据存储区域的非易失性存储器之外，还具有一个面的数据存储区域的扩展非易失性存储器，并能够将这两个非易失性存储器作为操作面和非操作面使用的电子控制单元。

如图3所示，软件更新装置11具有微型计算机35和通信装置36，微型计算机35具有CPU31、RAM32、ROM33和存储装置34(存储器)。此外，软件更新装置11也可以具有多个CPU。软件更新装置11可以具有多个ROM。软件更新装置11也可以具有多个存储装置。软件更新装置11也可以具有多个存储装置。此外，软件更新装置11也可以具有多个通信装置。在软件更新装置11中，微型计算机35的CPU31通过使用RAM32作为工作区域来执行从ROM33或存储装置34中读取的程序，从而执行后述的控制处理。通信装置36是经由图1所示的总线15a～15d与通信模块12、电子控制单元13a～13d、显示装置14实施通信的设备。

在此，软件的更新处理由从服务器1下载更新数据的阶段、将下载的更新数据传送到更新对象的电子控制单元并在更新对象的电子控制单元的存储区域中安装更新数据的阶段、在更新对象的电子控制单元中使安装的更新版本的软件有效化的激活的阶段构成。

关于下载，其是从服务器1接收并存储用于更新电子控制单元的软件的更新数据的处理。在下载的阶段中，不仅包含更新数据的接收，还包含下载的执行能否判断、更新数据的验证等与下载相关的一系列处理的控制。关于安装，其是根据下载的更新数据，将更新版本的程序(更新软件)写入更新对象的电子控制单元的存储部的处理。在安装的阶段中，不仅包含安装的执行，还包含安装的执行能否判断、更新数据的传送以及更新版本的程序的验证等与安装相关的一系列处理的控制。关于激活，是将安装的更新版本的程序有效化的处理。激活控制不仅包含激活的执行，还包含例如激活的执行能否判断、执行结果的验证等与激活相关的一系列的控制。

从服务器1发送到软件更新装置11的更新数据可以包含电子控制单元的更新软件、将更新软件压缩了的压缩数据、将更新软件或压缩数据分割了的分割数据中的任一个。此外，更新数据也可以包含识别更新对象的电子控制单元的标识符(ECUID)、识别更新前的软件的标识符(ECU软件ID)。更新数据作为上述的分发包被下载，但在分发包中包含一个或多个电子控制单元的更新数据。

在更新数据包含更新软件本身的情况下，在安装阶段中，软件更新装置将更新数据(更新软件)传送至更新对象的电子控制单元。此外，在更新数据包含更新软件的压缩数据、差分数据或分割数据的情况下，可以由软件更新装置11向更新对象的电子控制单元传送更新数据，由更新对象的电子控制单元根据更新数据生成更新软件，也可以由软件更新装置11在根据更新数据生成更新软件之后，将更新软件传送到更新对象的电子控制单元。在此，更新软件的生成能够通过压缩数据的解压缩、差分数据或分割数据的组合来实施。

更新软件的安装能够根据来自软件更新装置11的安装请求，由更新对象的电子控制单元实施。或者，接收了更新数据的更新对象的电子控制单元也可以无需接受来自软件更新装置11的明确的指示地自主实施安装。

更新软件的激活能够根据来自软件更新装置11的激活请求，由更新对象的电子控制单元实施。或者，接收了更新数据的更新对象的电子控制单元也可以无需接受来自软件更新装置11的明确的指示地自主实施激活。

此外，软件的更新处理能够针对多个电子控制单元的每一个连续地或并行地实施。

此外，本说明书中的“软件更新处理”不仅包含连续地实施全部下载、安装、激活的处理，还包含仅实施下载、安装、激活的一部分的处理。

(第一实施方式)

图4是第一实施方式涉及的服务器的功能框图。

服务器1具有存储部26、第一通信部27和控制部28。

存储部26存储OTA用的第一软件、用于对电子控制单元的软件的更新进行管理的更新管理信息、电子控制单元的软件的更新数据。存储部26由图2所示的存储装置23实现。第一软件是图2所示的CPU21能够执行的服务器侧的软件(程序)，并且是与搭载于车辆的软件更新装置11进行无线通信，并通过无线通信实现分发电子控制单元的软件的更新数据的功能的软件。通过图2所示的CPU21执行第一软件，实现后述的第一通信部27及控制部28。

关于存储部26存储的更新管理信息，其是针对每个识别车辆的车辆识别信息(车辆ID)，将表示在搭载于车辆的一个以上的电子控制单元中能够使用的软件的信息建立了关联的信息。作为表示在电子控制单元中能够使用的软件的信息，例如，定义多个电子控制单元各自的软件的最新的版本信息的组合。更新管理信息及更新数据在电子控制单元的软件更新的事件注册时被存储在存储部26中。

第一通信部27能够从软件更新装置11接收软件的更新确认请求。更新确认请求例如是在车辆中接通电源或点火开关时从软件更新装置11向服务器1发送的信息，并且是用于向服务器1请求确认是否存在电子控制单元的更新数据的信息。第一通信部27响应于从软件更新装置11接收的更新确认请求，向软件更新装置11发送表示更新数据的有无的信息。此外，第一通信部27能够接收来自软件更新装置11的分发包的发送请求(下载请求)。第一通信部27在接收分发包的下载请求时，将包含电子控制单元的软件的更新数据的分发包发送到软件更新装置11。

控制部28在第一通信部27接收更新确认请求时，根据存储在存储部26中的更新管理信息，对由包含在更新确认请求中的车辆ID确定的车辆的软件的更新数据是否存在进行判断。基于控制部28的更新数据是否存在的判断结果通过第一通信部27被发送到软件更新装置11。控制部28在判断为存在电子控制单元的更新数据的情况下，当从软件更新装置11接收分发包的下载请求时，生成包含存储在存储部26中的更新数据的分发包。该分发包通过第一通信部27被发送到软件更新装置11。

图5是图1所示的软件更新装置的功能框图。

软件更新装置11具有存储部37、控制部38。存储部37由图3所示的存储装置34实现，控制部38通过图3所示的CPU31使用RAM32执行在ROM33中存储的程序(软件更新装置11的控制用的程序)来实现。

存储部37存储OTA用的第一软件和OTA用的第二软件。存储部26由图3所示的存储装置34实现。第一软件及第二软件均为图3所示的CPU31能够执行的客户端侧的软件(程序)，并且是与服务器1实施无线通信，通过无线通信实现下载电子控制单元的软件的更新数据的功能的软件。关于第一软件及第二软件，更新数据的下载及其附带的各种功能(例如，确认针对服务器1的更新数据的有无的功能、在下载完成后通知服务器1的功能、在异常产生时将异常信息发送到服务器1的功能等)是共通的，但用于实现该功能的具体的处理、与服务器侧的软件的通信顺序不同。关于第一软件及第二软件之间的具体处理、通信顺序等的差异，由第一软件与第二软件之间的供应商的差异或版本差异引起。关于服务器侧的OTA用软件与客户端侧的OTA用软件，能够实现更新数据的下载功能的组合是被确定的，第一软件与第二软件分别与对应的服务器侧的软件组合地被执行。

此外，存储部37除了存储用于执行电子控制单元13a～13d的软件更新的程序、在执行软件更新时使用的各种数据之外，还存储从服务器1下载的软件的更新数据。

控制部38实施对电子控制单元的软件更新进行控制的各种处理。更详细而言，控制部38通过执行第一软件和第二软件中的任一个来实施更新数据的下载。控制部38以接通车辆的电源或点火开关等为契机，向服务器1发送软件的更新确认请求。更新确认请求例如包含用于识别车辆的车辆ID、与车载网络2连接的电子控制单元13a～13d的软件的版本。车辆ID和电子控制单元13a～13d的软件版本用于通过与服务器1针对每个车辆ID保存的最新的软件版本进行比较，从而判断是否存在电子控制单元的软件的更新数据。此外，作为针对更新确认请求的响应，控制部38从服务器1接收表示更新数据的有无的确认结果，并根据确认结果判断更新数据的有无。在存在任一个电子控制单元的软件的更新数据的情况下，控制部38向服务器1发送分发包的下载请求，并接收从服务器1发送的分发包。除了更新数据之外，分发包还可以包含用于验证更新数据的真实性的验证用数据、更新数据的数量、安装顺序、软件更新时使用的各种控制信息等。控制部38在从服务器1接收包含更新数据的分发包时，验证接收的分发包的真实性。

此外，控制部38在下载了包含更新数据的分发包的情况下，实施更新数据的安装处理、激活处理、安装处理或激活处理的执行时的批准请求处理。控制部38在执行软件更新时，作为批准请求处理，实施使输出装置输出表示需要批准软件更新的主旨的通知、催促表示输入批准了软件更新的主旨的通知的处理、承接来自用户的操作输入的处理。作为输出装置，能够使用设置在车载网络2中的显示装置14、实施基于声音的通知的声音输出装置等。例如，在批准请求处理中，在将显示装置14作为输出装置使用的情况下，控制部38使显示装置14显示用于请求软件更新的批准的批准请求画面，并在用户或管理者批准了的情况下，使显示装置14显示催促按下批准按钮等特定的输入操作的通知。此外，在批准请求处理中，控制部38使显示装置14显示通知电子控制单元的软件的更新数据为存在的文字、图标等、使显示装置14显示软件更新处理的执行中的限制事项等。

图6A至图6C是表示第一实施方式中的软件切换的概要的示意图。在以后的说明中，假设服务器侧的第一软件及客户端侧的第一软件的组合、服务器侧的第二软件及客户端侧的第二软件的组合为能够下载更新数据的组合，并且除此以外的软件的组合不能够下载更新数据。

首先，如图6A所示，假设在服务器1中作为OTA用软件运行第一软件的情况。在软件更新装置11的存储部37中，作为客户端侧的OTA用软件，安装了默认使用的第一软件和备选的第二软件。在软件更新装置11中默认执行的第一软件对应于在服务器1中运行的第一软件。因此，在该情况下，控制部38能够通过执行第一软件来进行针对服务器1的更新数据的确认请求、下载。

接着，如图6B所示，假定在服务器1中运行的OTA用软件被改变为第二软件的情况。作为服务器侧的第二软件的示例，例如考虑由与第一软件不同的供应商开发的、与第一软件不兼容的软件。作为第二软件的其他示例，例如考虑虽然是与第一软件相同的供应商开发的软件，但由于对应于服务器OS的种类改变、版本升级等进行更新，其结果为，至少部分地损害与第一软件的兼容性的软件。

在软件更新装置11中默认执行的第一软件不对应于在服务器1中运行的第二软件。因此，在该情况下，控制部38不能够通过执行第一软件来执行针对服务器1的更新数据的确认请求、下载。

在该情况下，如图6C所示，控制部38将执行的软件从默认的第一软件切换为备选的第二软件。切换后的第二软件对应于在服务器1中运行的第二软件。因此，在该情况下，控制部38能够通过执行第二软件而实施针对服务器1的更新数据的确认请求、下载。

图7是表示第一实施方式涉及的服务器执行的控制处理的示例的流程图。图7所示的控制处理例如以规定的时间间隔反复执行。

在步骤S1中，第一通信部27对是否从软件更新装置11接收了更新确认请求进行判断。在步骤S1的判断为是的情况下，处理进入步骤S2，在除此以外的情况下，处理进入步骤S3。

在步骤S2中，第一通信部27向发送了更新确认请求的车辆发送表示是否存在电子控制单元的软件的更新数据的信息。关于更新数据的有无，例如控制部28对与包含在更新确认请求中的车辆ID建立关联地存储在更新管理信息中的软件的版本的组合、和包含在更新确认请求中的当前的软件的版本的组合进行比较，在包含在更新确认请求中的当前的软件的版本的组合与存储在更新管理信息中的版本的组合相比而较旧的情况下，能够判断为存在更新数据。之后，处理进入步骤S3。

在步骤S3中，第一通信部27对是否从软件更新装置11接收了更新数据(分发包)的下载请求进行判断。在步骤S3的判断为是的情况下，处理进入步骤S4，在除此以外的情况下，处理进入步骤S1。

在步骤S4中，第一通信部27将控制部28生成的包含软件的更新数据的分发包发送到软件更新装置11。之后，处理进入步骤S1。

图8是表示第一实施方式涉及的软件更新装置执行的控制处理的示例的流程图。图8所示的控制处理例如以车辆的电源或点火开关被接通为契机来执行。

在步骤S11中，控制部38执行OTA用的第一软件，向服务器1请求确认是否存在电子控制单元的软件的更新数据。第一软件是控制部38默认执行的软件，在车辆制造时或销售后向车辆附加了基于OTA的软件更新功能时，对应于在服务器1中运行的OTA用软件地被安装。控制部38为了确认是否存在更新数据，向服务器1发送包含车辆ID和电子控制单元的软件的版本的组合的更新确认请求。之后，处理进入步骤S12。

在步骤S12中，控制部38判断是否处于能够从服务器1下载数据的状态。能够下载数据的状态指的是，控制部38能够根据由OTA用软件确定的顺序，经由通信与在服务器1中运行的OTA用软件进行消息、数据的发送接收，并且能够通过执行中的软件的功能从服务器1下载更新数据的状态。控制部38例如在检测到不能够建立与服务器1的链接、与服务器1的通信产生了超时、在OTA用软件中产生了异常这样的一个以上的事件时，能够判断为不能够进行下载的状态。在步骤S12的判断为“是”的情况下，处理进入步骤S15，在除此以外的情况下，处理进入步骤S13。

在步骤S13中，控制部38执行OTA用的第二软件，向服务器1请求确认是否存在电子控制单元的软件的更新数据。第二软件是在车辆的制造时或销售后被安装的备选的软件，但与在安装了第二软件的时刻在服务器1中运行的OTA用软件不对应(无兼容性)。控制部38为了确认是否存在更新数据，向服务器1发送包含车辆ID和电子控制单元的软件的版本的组合的更新确认请求。之后，处理进入步骤S14。此外，在步骤S13中，控制部38也可以在执行第二软件之前结束第一软件。

在步骤S14中，控制部38判断是否处于能够从服务器1下载数据的状态。步骤S14的判断处理与步骤S12的判断处理相同。在步骤S14的判断为“是”的情况下，处理进入步骤S15，在除此以外的情况下，结束处理。此外，在步骤S14中判断为“否”的情况下，由于不存在与在服务器1中运行的OTA用软件对应的软件，不能够进行基于OTA的软件更新，所以也可以实施异常的通知、催促销售店、检修工厂等的应对的通知。

在步骤S15中，控制部38从服务器1接收针对更新确认请求的确认结果。之后，处理进入步骤S16。

在步骤S16中，控制部38根据在步骤S15中接收的确认结果，判断是否存在电子控制单元13a～13d的任一个软件的更新数据。在步骤S16的判断为“是”的情况下，处理进入步骤S17，在除此以外的情况下，处理进入步骤S18。

在步骤S17中，控制部38通过OTA用软件的功能执行下载处理。更详细而言，控制部38向服务器1发送分发包的下载请求，接收响应于下载请求而发送的分发包，并将接收的分发包存储在存储部37中。控制部38验证在接收的分发包中包含的更新数据的真实性。在步骤S17中，也可以实施下载的执行能否的判断、针对服务器1进行下载完成的通知。之后，处理进入步骤S19。

在步骤S18中，控制部38判断是否承接了执行软件更新处理的指示。软件更新处理无需连续地执行，例如有时在下载完成的阶段，或者在安装完成的阶段被中断，在此后执行后续的更新处理。因此，在本实施方式中，在步骤S16中判断为不存在更新数据的情况下，通过设置步骤S18的判断，能够重新开始被中断的软件更新处理。步骤S18的判断例如能够在显示装置14上显示通知存在被中断的软件更新处理的文字、图标等之后，根据是否承接了使用输入按钮等的特定的操作输入来实施。在步骤S18的判断为“是”的情况下，处理进入步骤S19，在除此以外的情况下，结束处理。

在步骤S19中，控制部38针对更新对象的电子控制单元(目标ECU)执行安装处理及激活处理。更详细而言，控制部38向更新对象的电子控制单元传送更新数据，并指示安装。更新对象的电子控制单元将从软件更新装置11接收的更新数据写入数据存储区域。接着，控制部38向更新对象的电子控制单元指示更新版本的软件的激活。更新对象的电子控制单元以通过电源或点火开关断开等实施了特定的操作为契机，重新启动并执行更新后的软件。由此，电子控制单元的软件更新(功能更新)完成。在安装处理或激活处理结束后，结束图8的处理。

此外，在更新对象的电子控制单元为具有一个数据存储区域的结构的情况下，由于在数据存储区域中安装了更新数据的时刻对电子控制单元的软件产生影响，因此也可以连续实施安装和激活。此外，在该情况下，在更新对象的电子控制单元为具有一个数据存储区域的结构的情况下，也可以在安装执行之前实施针对安装及激活的批准请求处理，并省略激活执行之前的批准请求处理。

此外，在执行安装之前，控制部38也可以执行安装的执行能否的判断处理、针对安装的批准请求处理。作为针对安装的批准请求处理，控制部38例如使显示装置14显示开始电子控制单元的软件更新的主旨的显示、请求用户针对软件更新的批准的主旨的显示、根据需要显示更新数据的安装所需的时间、安装中的限制事项、注意事项的显示，并承接用户使用触摸面板、操作按钮等输入单元进行的操作输入。之后，控制部38判断是否实施了批准软件更新(安装)的操作输入。批准安装的主旨的操作输入例如能够根据在显示装置14上显示的“批准”或“开始更新”等按钮是否被按下进行判断。此外，在用户希望不立即批准软件的更新开始(安装)而是之后实施软件的更新开始(安装)的情况下，能够通过按下“之后进行”等按钮来承接该主旨。

同样地，在执行激活之前，控制部38可以执行激活的执行能否的判断处理、针对激活的批准请求处理。作为针对安装的批准请求处理，控制部38例如在显示装置14上显示电子控制单元的软件更新的准备就绪、通过实施电源或点火开关等的特定操作来更新程序的显示、以及根据需要显示激活所需的时间、激活中的限制事项、注意事项的显示，承接用户使用触摸面板、操作按钮等输入单元进行的操作输入。之后，控制部38判断是否实施了批准软件更新(激活)的操作输入。关于批准激活的主旨的操作输入，例如能够根据显示在显示装置14上的“批准”或“更新”等按钮是否被按下进行判断。此外，在用户希望不立即批准软件更新(激活)而是之后实施软件更新的情况下，能够通过按下“之后进行”等按钮来承接该主旨。

本实施方式涉及的软件更新装置11在存储部37中具有相互不同的第一软件及第二软件作为OTA用软件，通过执行任一个软件而从服务器1下载更新数据。因此，本实施方式的软件更新装置11能够分别应对与第一软件对应的服务器侧软件运行的服务器、和与第二软件对应的服务器侧软件运行的服务器。

此外，假设在车辆的生命周期中，在服务器1中运行的OTA用软件被改变，并且改变后的软件与在初始服务器1中运行的软件的兼容性消失的情况。本实施方式涉及的软件更新装置11在处于不能够通过OTA用的第一软件的功能下载更新数据的状态的情况下，执行存储在存储部37中的第二软件。以此方式，在以第一软件不能够接收更新数据的情况下，通过将执行的软件切换为第二软件，能够实施更新数据的下载。

(第二实施方式)

图9是第二实施方式涉及的服务器的功能框图。

第二实施方式涉及的服务器1是在第一实施方式的结构中增加了第二通信部29的服务器。第二通信部29不经由OTA用软件而与软件更新装置进行通信。具体而言，第二通信部29能够从软件更新装置11接收软件信息的发送请求，响应于发送请求而将软件信息发送到软件更新装置11。软件信息是确定在服务器1中用于分发更新数据的OTA用软件的信息。此外，第二通信部29能够从软件更新装置11接收OTA用软件的发送请求，并响应于发送请求，将与在服务器1中运行的OTA用软件对应的客户端侧软件发送到软件更新装置11。

图10是第二实施方式涉及的软件更新装置的功能框图。

第二实施方式涉及的软件更新装置11是在第一实施方式的结构中增加了通信部39的装置。通信部39能够不经由OTA用软件而与服务器的第二通信部29进行通信。通信部39将上述软件信息的发送请求发送到服务器1，作为对发送请求的响应，接收从服务器1发送的软件信息。接收的软件信息是为了控制部38判断在存储部37中是否存储了与在服务器1中运行的OTA用软件对应的软件而进行参照的信息。在控制部38判断为在存储部37中没有存储与在服务器1中运行的OTA用软件对应的软件的情况下，通信部39向服务器1请求发送与在服务器1中运行的OTA用软件对应的软件，并下载该软件。通信部39将下载的新的OTA用软件存储在存储部37中。

图11A和11B是表示第二实施方式中的软件选择的概要的示意图。

假设第二软件在服务器1中作为OTA用软件运行。在软件更新装置11的存储部37中，作为客户端侧的OTA用软件，安装有第一软件以及第二软件。

首先，如图11A所示，软件更新装置11的通信部39从服务器1接收软件信息。接着，如图11B所示，控制部38执行与由接收的软件信息确定的服务器侧的第二软件对应的客户端侧的第二软件。以此方式，在存储部37中存储了与由从服务器1接收到的软件信息确定的服务器侧软件对应的软件的情况下，控制部38能够根据从服务器1接收的软件信息而选择适当的软件，并实施针对服务器1的更新数据的确认请求、下载。

图12A到图12C是表示第二实施方式中的软件追加的概要的示意图。假设图12A～图12C所示的第三软件与第一软件及第二软件都不同，服务器侧的第三软件与客户端侧的第三软件的组合能够下载更新数据，除此以外的软件的组合不能够下载更新数据。

假设在服务器1中作为OTA用软件运行第三软件的情况。在软件更新装置11的存储部37中，作为客户端侧的OTA用软件而安装了第一软件以及第二软件。第一软件和第二软件均不能够根据在服务器1中运行的第三软件下载更新数据。

首先，如图12A所示，软件更新装置11的通信部39从服务器1接收软件信息。但是，在存储部37中没有存储与由软件信息确定的服务器侧的第三软件对应的软件。因此，如图12B所示，通信部39接收与在服务器1中运行的第三软件对应的客户端侧的第三软件。然后，如图12C所示，控制部38通过执行接收的第三软件，能够实施针对服务器1的更新数据的确认请求、下载。

图13是表示第二实施方式涉及的服务器执行的控制处理的示例的流程图。第二实施方式涉及的服务器还执行图7所示的控制处理，但省略重复的说明。图13所示的控制处理与图7所示的控制处理并行地例如以规定的时间间隔反复执行。

在步骤S5中，第二通信部29判断是否从软件更新装置11接收了软件信息的发送请求。在步骤S5的判断为“是”的情况下，处理进入步骤S6，在除此以外的情况下，处理进入步骤S7。

在步骤S6中，第二通信部29向发送了软件信息的发送请求的车辆发送软件信息。之后，处理进入步骤S7。

在步骤S7中，第二通信部29判断是否接收了OTA用软件(客户端侧)的发送请求。在步骤S7的判断“是”的情况下，处理进入步骤S8，在除此以外的情况下，进入步骤S5。

在步骤S8中，第二通信部29向发送了OTA用软件的发送请求的车辆发送OTA用软件(客户端侧)。之后，处理进入步骤S5。

图14是表示第二实施方式涉及的软件更新装置执行的控制处理的示例的流程图。图14所示的控制处理例如以车辆的电源或点火开关被接通为契机来执行。

在步骤S20中，通信部39向服务器1发送软件信息的发送请求。之后，处理进入步骤S21。

在步骤S21中，通信部39从服务器1接收软件信息。之后，处理进入步骤S22。

在步骤S22中，控制部38判断在存储部37中是否存储了与由接收的软件信息确定的服务器侧软件对应的软件。在步骤S22的判断为“是”的情况下，处理进入步骤S23，在除此以外的情况下，处理进入步骤S24。

在步骤23中，控制部38执行与由软件信息确定的服务器侧软件对应的软件，向服务器1请求确认是否存在电子控制单元的软件的更新数据。之后，处理进入步骤S15。

在步骤S24中，通信部39向服务器1发送与由软件信息确定的服务器侧软件对应的客户端侧软件的发送请求。之后，处理进入步骤S25。

在步骤S25中，通信部39从服务器1接收与由软件信息确定的服务器侧软件对应的客户端侧软件，并将接收的软件存储在存储部37中。之后，处理进入步骤S23。此外，在步骤S25中，在通信部39从服务器1接收了OTA用软件的情况下，在步骤S23中，控制部38执行在步骤S25中接收的软件。

此外，图14所示的步骤S15～S19的处理与图8中说明的处理相同，因此省略重复的说明。

此外，步骤S20及S21中的软件信息的发送请求及接收、步骤S24及S25中的OTA用软件的发送请求及接收是能够不经由OTA用软件而执行的处理。

本实施方式涉及的软件更新装置11在存储部37中具有相互不同的第一软件及第二软件作为OTA用软件，根据从服务器1接收的软件信息，选择并执行与服务器侧软件对应的软件。即使在服务器1中运行的OTA用软件被改变的情况下，也能够执行与服务器侧对应的软件，并下载更新数据。

此外，在不存在与服务器侧软件对应的软件的情况下，由于能够从服务器1下载软件，所以能够使用下载的软件实施更新数据的下载。

在上述第二实施方式中，对软件信息是确定在服务器1中运行的OTA用软件的信息的示例进行了说明，但软件信息也可以指定在软件更新装置11中应该执行的OTA用软件的信息。

在上述的第二实施方式中，对不经由存储在存储部37中的OTA用软件的功能而实施软件信息的发送请求及接收、OTA用软件的发送请求及接收的示例进行了说明，但也可以将与软件信息的发送请求及接收、OTA用软件的发送请求及接收相关的步骤共通化，并安装在全部的OTA用软件(服务器侧和客户端侧)中。

(其他变形例)

上述各实施方式中例示的服务器1的功能也可以作为具有处理器(CPU)、存储器、存储装置的计算机执行的更新管理方法、或者使该计算机执行的更新管理程序、存储了更新管理程序的计算机可读取的非临时存储介质来实现。同样地，在各实施方式中例示的软件更新装置11的功能也可以作为具有处理器(CPU)、存储器、存储装置的车载计算机执行的更新控制方法、或者使该车载计算机执行的更新控制程序、存储了更新控制程序的计算机可读取的非临时存储介质来实现。

在上述的各实施方式中，对在车辆侧设置在车载网络中的软件更新装置11作为主机装置控制全部的电子控制单元13a～13d的程序更新的示例进行了说明，但也可以代替设置软件更新装置11地，电子控制单元13a～13d中的任一个具有图8或图14所示的更新控制功能，并控制其他的电子控制单元的程序更新。此外，代替设置软件更新装置11地，也可以将图8或图14所示的更新控制功能设置在能够通过有线的方式与车载网络2连接的外部设备中，并使用该外部设备实施电子控制单元13a～13d的程序更新处理。

本发明的技术对于用于更新电子控制单元的程序的网络系统是有益的。

Claims (6)

1.一种软件更新装置，被配置为对搭载于车辆的电子控制单元的软件更新进行控制，所述软件更新装置的特征在于，具有：

一个或多个存储装置，其被配置为，对用于从服务器下载所述电子控制单元的更新数据的相互不同的第一软件及第二软件进行存储；

一个或多个处理器，其被配置为，通过执行所述第一软件及所述第二软件中的任一个而从所述服务器下载所述更新数据。

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

所述一个或多个处理器被配置为，在不能够通过执行所述第一软件下载所述更新数据的情况下，将执行的软件从所述第一软件切换为所述第二软件。

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

所述一个或多个处理器被配置为，

从所述服务器接收软件信息，所述软件信息确定在所述服务器中用于所述更新数据的分发的软件，

并执行在所述第一软件及所述第二软件中的、与由所述一个或多个处理器接收的所述软件信息确定的在所述服务器中使用的软件对应的软件。

4.根据权利要求3所述的软件更新装置，其特征在于，

所述一个或多个处理器被配置为，在判断为在所述存储装置中没有存储能够从所述服务器下载所述更新数据的软件的情况下，从所述服务器接收与由所述软件信息确定的在所述服务器中使用的软件对应的软件。

5.一种更新控制方法，为了对搭载于车辆的电子控制单元的软件更新进行控制并由计算机执行，所述计算机具有处理器、存储器、存储装置，所述更新控制方法的特征在于，具有：

对用于从服务器下载所述电子控制单元的更新数据的相互不同的第一软件及第二软件进行存储的步骤；

通过执行所述第一软件及所述第二软件中的任一个而从所述服务器下载所述更新数据的步骤。

6.一种非临时存储介质，存储能够由计算机执行的、为了控制搭载于车辆的电子控制单元的软件更新而使所述计算机执行以下功能的更新控制程序，所述计算机具有处理器、存储器、所述非临时存储介质，所述非临时存储介质的特征在于，所述功能具有：

对用于从服务器下载所述电子控制单元的更新数据的相互不同的第一软件及第二软件进行存储的步骤；

通过执行所述第一软件及所述第二软件中的任一个而从所述服务器下载所述更新数据的步骤。

Images