CN108762783A - 车辆系统的软件更新方法、装置及车辆系统 - Google Patents

Abstract

本申请涉及一种车辆系统的软件更新方法，车辆系统包括车载控制组件、以及与所述车载控制组件连接的电子控制组件，该方法包括：通过所述车载控制组件获取软件更新包；所述软件更新包包括待更新文件；通过所述车载控制组件，基于所述待更新文件进行合法性验证；在所述合法性验证通过时，通过所述车载控制组件，基于所述待更新文件对目标组件上的待更新软件进行更新；其中，所述目标组件与所述待更新文件匹配，且所述目标组件包括所述车载控制组件和所述电子控制组件中的至少一个。本申请中的方案更新效率及安全性高。

Description

车辆系统的软件更新方法、装置及车辆系统

技术领域

本申请涉及计算机技术领域，特别是涉及一种车辆系统的软件更新方法、装置、车辆系统、计算机可读存储介质及计算机设备。

背景技术

车辆系统是硬件和软件有机结合的整体，通过硬件和软件相互配合，实现各种各样的车辆功能。随着信息技术的发展，车辆系统承载的软件越来越多，在系统生命周期中，经常需要对软件进行更新，以实现对系统功能的改进及对系统漏洞的修补等。例如，车辆系统包括：电子控制单元(Electronic Control Unit，ECU)等组件，ECU可用于对车辆中的执行机构(如发动机)进行控制，需要改进控制功能时，则可以对相应ECU上的固件进行更新。

传统方式中，需要将车辆送至经销商或修理厂，由专业维修人员使用专业测试仪器，对车辆的运行状态进行检测，再通过车辆上的专用物理接口写入更新内容，从而实现对相应组件上的软件的更新。以更新车辆中的ECU上的固件为例，需要由专业维修人员通过汽车上的OBD(On Board Diagnostics，车载自动诊断)接口写入相应更新内容，从而实现ECU上的固件的更新。然而，传统方式中需要专业维修人员参与，存在一定的局限性，且更新过程繁琐，效率低下。

发明内容

基于此，有必要针对传统方式中更新效率低下的技术问题，提供一种车辆系统的软件更新方法、装置、车辆系统、计算机可读存储介质及计算机设备。

一种车辆系统的软件更新方法，车辆系统包括车载控制组件、以及与所述车载控制组件连接的电子控制组件，所述方法包括：

通过所述车载控制组件获取软件更新包，所述软件更新包包括待更新文件；

通过所述车载控制组件，基于所述待更新文件进行合法性验证；

在所述合法性验证通过时，通过所述车载控制组件，基于所述待更新文件对目标组件上的待更新软件进行更新；其中，所述目标组件与所述待更新文件匹配，且所述目标组件包括所述车载控制组件和所述电子控制组件中的至少一个。

一种车辆系统，包括车载控制组件、以及与所述车载控制组件连接的电子控制组件；

所述车载控制组件用于获取软件更新包，所述软件更新包包括待更新文件；并基于所述待更新文件进行合法性验证；在所述合法性验证通过时，基于所述待更新文件对目标组件上的待更新软件进行更新，所述目标组件与所述待更新文件匹配，且所述目标组件包括所述车载控制组件和所述电子控制组件中的至少一个。

一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时，使得所述处理器执行上述车辆系统的软件更新方法的步骤。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行上述车辆系统的软件更新方法的步骤。

根据如上所述的方案，通过车载控制组件获得待更新文件，再基于待更新文件进行合法性验证，并在验证通过时，基于待更新文件对车载控制组件和/或电子控制组件上的待更新软件进行更新。首先，更新过程由车辆系统中的组件自动完成，无需专业维修人员参与，便捷性及效率高。再则，对待更新文件进行合法性验证，验证通过时才进行更新，更新的安全性高。此外，待更新文件的合法性验证操作，以及针对待更新对象的更新控制操作均由车载控制组件完成，即由待更新对象本身或与待更新对象直接连接的组件完成，进一步保证了更新的安全性。

附图说明

图1为一个实施例中车辆系统的软件更新方法的应用环境图；

图2为一个实施例中车辆系统的软件更新方法的流程示意图；

图3为一个实施例中车辆系统的结构示意图；

图4为一个实施例中车辆系统的结构示意图；

图5为一个实施例中车辆系统的结构示意图；

图6为一个实施例中车辆系统的结构示意图；

图7为一个实施例中域控制组件安全启动方法的流程示意图；

图8为一个实施例中车辆系统的软件更新方法的时序图；

图9为一个实施例中车辆系统的软件更新装置的结构示意图；

图10为一个实施例中计算机设备的结构框图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用于解释本申请，并不用于限定本申请。

需要说明的是，本申请文件中使用的术语“第一”、“第二”等是用于对类似的对象作出命名上的区分，但这些对象本身不受这些术语限制。应当理解，在不脱离本申请的范围的情况下，这些术语在适当的情况下可互换。例如，可将“第一合法发行方”描述为“第二合法发行方”，且类似地，将“第二合法发行方”描述为“第一合法发行方”。

可以理解，术语“包括”、“包含”、“具有”以及它们的任何变形，意图在于覆盖不排他的包含。例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备等不必限于已清楚地列出的步骤或单元，而是还可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。此外，本申请文件中使用的术语“和/或”，包括一个或多个相关的所列项目的任意的及所有的组合。

本申请各实施例提供的车辆系统的软件更新方法，可应用于如图1所示的应用环境中。该应用环境涉及车辆系统110和更新内容提供方120。车辆系统110可以包括用于实现车辆功能的组件，组件上可以搭载实现相应功能的软件。更新内容提供方120可用于提供对车辆系统110中的组件上的待更新软件进行更新所使用的软件更新包，该软件更新包中包括待更新文件，并且，更新内容提供方120可以将该软件更新包传递至车辆系统110。车辆系统110获取到待更新文件后，对其相应组件上的待更新软件进行更新。

其中，车辆系统110和更新内容提供方120可通过网络进行连接，更新内容提供方120通过网络将软件更新包发送至车辆系统110。在其他实施例中，也可以将更新内容提供方120提供的软件更新包拷贝到移动存储介质(如U盘、移动硬盘及存储卡等)中，再通过该移动存储介质将该软件更新包传入车辆系统110。

并且，车辆系统可以是智能网联车辆，智能网联车辆是搭载车载传感器、控制器、执行机构等器件，并融合现代通信与网络技术，具备复杂的环境感知、智能决策、协同控制和执行等功能的车辆。此外，更新内容提供方120可用独立的物理服务器，或者多个物理服务器构成的服务器集群来实现。

在一个实施例中，如图2所示，提供了一种车辆系统的软件更新方法。该方法可以应用于车辆系统(如上述图1中的车辆系统110)。并且，该方法可包括如下步骤S202至S206。

首先，如图3所示，车辆系统可以包括车载控制组件、以及与该车载控制组件连接的电子控制组件。此外，车载控制组件和电子控制组件的数目均可以仅为一个，也可以多于一个，图3中的电子控制组件311至313仅为示例，并不用于限定电子控制组件的数目。

S202，通过车载控制组件获取软件更新包，软件更新包包括待更新文件。

其中，车载控制组件是车辆系统的组成部件。对于车载控制组件而言，一方面，其可以具备与系统外部进行数据通信的能力，即可以从系统外部获取数据。另一方面，其可以具备与系统内部的电子控制组件进行信息交互的能力。其中，系统内部是车辆系统所涵盖的范围，系统外部是除车辆系统以外的其他范围。举例说明，若车辆系统SY1仅包括车载控制组件C1和电子控制组件E1，则车载控制组件C1和电子控制组件E1属于系统内部，除车载控制组件C1和电子控制组件E1以外的其他部件均属于系统外部。

在一个实施例中，车载控制组件可以是单一的硬件(下文中将该单一的硬件简称为集成控制组件)，该集成控制组件同时具备上述与系统外部进行数据通信的能力、以及与系统内部的电子控制组件进行信息交互的能力。在其他实施例中，车载控制组件也可以包括互相独立的多个硬件，多个硬件协同工作，共同完成与系统外部进行数据通信，以及与系统内部的电子控制组件进行信息交互等任务。

电子控制组件，又可以称为电子控制单元(Electronic Control Unit，ECU)，也是车辆系统的组成部件，其可以用于对车辆中的执行机构进行控制。执行机构是根据电子控制组件输出的电信号执行相应动作的装置，例如车辆内的发动机、变速箱、空调压缩机等。以功能作为分类依据，常见的电子控制单元包括：EMS(Engine Mangement System，发动机管理系统)，可用于控制车辆发动机的喷油、点火、扭矩分配等；TCU(Transmision ControlUnit，自动变速箱控制单元)，可用于根据车辆的驾驶状态实现档位控制；BCM(BodyControl Module，车身控制模块)，可用于对车身电器进行控制，例如整车灯具、雨刮、门锁等；BMS(Battery Management System，电池管理系统)，可用于对动力电池进行控制；VCU(Vehicle Control Unit，整车控制器)，可用于协调车辆内的发动机、驱动电机、变速箱、动力电池等各部件的工作。此外，就结构而言，电子控制单元通常可以包括微处理器(CentralProcessing Unit，CPU)及外围电路。

软件更新包，是封装有待更新文件的数据结构。可以理解，根据实际应用需求，软件更新包中除待更新文件以外，还可以包括对目标组件上的待更新软件进行更新时会使用到的其他数据，例如针对待更新文件的文件描述信息等。

待更新文件，可用于表征针对其匹配的目标组件上的待更新软件的更新内容。本质上，待更新文件可以是可运行的程序，例如固件，该固件具体可以是用于替换目标组件上的原有固件的新固件；待更新文件也可以是本身无法运行的数据，例如配置参数，该配置参数具体可以是用于替换目标组件上的固件中原有配置参数的新配置参数。

在一个实施例中，通过车载控制组件获取软件更新包，可以是由车载控制组件从系统外部获取软件更新包。具体地，车载控制组件直接与外部网络相连接时，车载控制组件可以直接通过网络访问更新内容提供方(如图1所示的更新内容提供方120)，从而获得软件更新包。

S204，通过车载控制组件，基于待更新文件进行合法性验证。

其中，合法性验证用于验证待更新文件的合法性，即验证待更新文件是否合法。在本实施例中，待更新文件合法时，可判定合法性验证通过，以允许车载控制组件根据该待更新文件对目标组件上的待更新软件进行更新；反之，待更新文件非法(即不合法)时，表明若根据该待更新文件对目标组件上的待更新软件进行更新，存在安全性风险，因而判定合法性验证未通过，以禁止车载控制组件根据该待更新软件对目标组件上的待更新软件进行更新。

在一个实施例中，合法性验证可以包括：验证待更新文件的数据来源是否合法。换言之，可以通过待更新文件的数据来源是否合法来衡量待更新文件是否合法。其中，数据来源是数据发行方，待更新文件的数据来源即为待更新文件的发行方，例如图1所示的更新内容提供方120。相应地，可以在确定待更新文件的数据来源合法时，判定合法性验证通过；反之，在确定待更新文件的数据来源非法时，判定合法性验证未通过。

在一个具体示例中，可以在确定车载控制组件获得的待更新文件来源于与该车载控制组件所在车辆对应的车辆主机厂时，认为该待更新文件的数据来源合法，从而判定合法性验证通过；反之，在确定车载控制组件获得的待更新文件不是来源于与该车载控制组件所在车辆对应的车辆主机厂时，认为该待更新文件的数据来源非法，从而判定合法性验证未通过。其中，车辆主机厂可以是具有相关品牌和核心技术的车辆公司，例如宝马公司(也称巴伐利亚机械制造厂股份公司)和奔驰车辆公司等。此外，车辆主机厂往往将其他非核心技术外包给其他按需进行生产的公司。

此外，在数据传输过程中，待更新文件存在被第三方篡改的可能性，这会导致更新存在安全性风险。基于此，在另一个实施例中，合法性验证除包括验证更新文件的数据来源是否合法以外，还可以包括：验证待更新文件是否被篡改。即，结合待更新文件的数据来源是否合法以及待更新文件本身是否被篡改，来衡量待更新文件是否合法。在此情况下，可以在待更新文件的数据来源合法且待更新文件未被篡改时，判定合法性验证通过；反之，可以在待更新文件的数据来源非法或待更新文件已被篡改时，判定合法性验证未通过。

其中，验证待更新文件是否被篡改，可以是验证车载控制组件获取到的待更新文件、与待更新文件的数据发行方发布的原始待更新文件是否一致。具体地，两者一致时，表明待更新文件未被篡改；反之，两者不一致时，表明车载控制组件获取到的待更新文件已被篡改。并且，可以基于任何适配的验证机制，来验证待更新文件的数据来源的合法性以及验证待更新文件本身是否被篡改，例如任何适配的密码学算法等，本申请不作具体限定。

S206，在合法性验证通过时，基于待更新文件对目标组件上的待更新软件进行更新；其中，目标组件与待更新文件匹配，且目标组件包括车载控制组件以及电子控制组件中的至少一个。

其中，目标组件是需要对其搭载的软件进行更新的组件。本申请各实施例中的组件，其本质是硬件，其可搭载用于实现相应功能的软件。

在一个实施例中，在合法性验证通过时，基于待更新文件对目标组件上的待更新软件进行更新之前，还可包括如下步骤：确定与待更新文件匹配的候选组件，与待更新文件匹配的候选组件即为目标组件。其中，候选组件可以是车辆系统内置的各组件中、符合更新支持条件的组件。具体地，更新支持条件可以包括：组件是车载控制组件本身、或者组件与车载控制组件直接连接且其根据车载控制组件传递信息进行工作。此外，两个组件直接连接，可以是两个组件之间除了连接介质以外，不存在任何中间部件，例如车载控制组件C1仅连接电子控制组件E1，电子控制组件E1仅连接执行机构M1，此时，车载控制组件C1与电子控制组件E1是直接连接，电子控制组件E1与执行机构M1也是直接连接，但车载控制组件C1与执行机构M1不是直接连接。

基于此，目标控制组件可以包括车载控制组件以及电子控制组件中的至少一个。此外，在其他实施例中，候选组件还可以包括用于提供影音娱乐、导航以及其他多媒体服务IVI(In-Vehicle Infotainment，车载信息娱乐系统)，在此情况下，当与待更新文件匹配的候选组件(即目标组件)中包括IVI时，车载控制组件便可以根据与该IVI匹配的待更新文件，对该IVI上的待更新软件进行更新，例如对IVI上的固件进行更新。

在一个实施例中，软件更新包中的待更新文件可与目标组件唯一匹配，即一个待更新文件唯一匹配一个目标组件。对于任一软件更新包而言，包内的待更新文件的数目可以仅为一个，此时，需要更新其待更新软件的目标组件也仅为一个；包内的待更新文件的数目也可以多于一个，此时，需要更新其更新软件的目标组件也相应多于一个。

待更新软件，是待进行更新的软件。对软件进行更新，是对软件作出修改。具体地，可以是对软件进行升级，即将软件从低版本升为高版本；也可以是对软件进行降级，即将软件从高版本降为低版本；还可以是更改软件的配置参数等等。

在一个实施例中，待更新软件可以是目标组件上的固件。其中，固件可以是担任电子器件最基础、最底层工作的软件，其一般存储于电子器件中的电可擦除只读存储器(Electrically Erasable Programmable ROM，EEPROM)或FLASH芯片中，且一般可通过特定的更新程序进行更新(也可称为刷新)。

此外，需要说明的是，在车载控制组件为单一的硬件(即集成控制组件)时，可以由该集成控制组件执行上述步骤S202至S206，即集成控制组件从外部获取软件更新包，再基于待更新文件进行合法性验证，并在合法性验证通过时，通过车载控制组件，基于待更新文件对目标组件上的待更新软件进行更新。其中，目标组件与待更新文件匹配，且目标组件包括集成控制组件和电子控制组件中的至少一个。然而，车载控制组件包括互相独立的多个硬件时，可以由多个硬件分工合作，共同完成上述集成控制组件完成的任务。

如上所述的软件更新方法中，通过车载控制组件获得待更新文件，再基于待更新文件进行合法性验证，并在验证通过时，基于待更新文件对车载控制组件和/或电子控制组件上的待更新软件进行更新。首先，更新过程由车辆系统中的组件自动完成，无需专业维修人员参与，便捷性及效率高。再则，对待更新文件进行合法性验证，验证通过时才进行更新，更新的安全性高。此外，待更新文件的合法性验证操作，以及针对待更新对象的更新控制操作均由车载控制组件完成，即由待更新对象本身或与待更新对象直接连接的组件完成，进一步保证了更新的安全性。

在一个实施例中，如图4所示，图3中的车载控制组件可以包括车载通信组件、以及与车载通信组件连接的域控制组件；并且，域控制器组件连接电子控制组件。类似地，图4中的电子控制组件411至413也仅为示例，并不用于限定电子控制组件的数目。在此情况下，可以通过车载通信组件，从外部获取软件更新包，并将软件更新包发送至域控制组件；并且，可以通过域控制组件，实现基于待更新文件进行合法性验证，以及在合法性验证通过时，基于待更新文件对目标组件上的待更新软件进行更新的步骤；其中，目标组件包括域控制组件和电子控制组件中的至少一个。

其中，车载通信组件是一个独立存在的硬件，其可以由具备无线网络通信能力的器件实现。如前文所述，车载控制组件具备与系统外部进行数据通信的能力，在本实施例中，即由车载通信组件负责与系统外部进行数据通信，并且，车载通信组件还可以与系统内部的域控制组件进行信息交互。具体地，车载通信组件可以是车载T-box(TelematicsBOX)，一方面，车载T-box可以用于与车辆内部的以太网总线和域控制组件进行通信，另一方面其可以用于与车辆后台系统进行通信，例如与车辆内部的以太网总线和域控制组件进行通信，获取车辆信息(如车身状态、车况信息等)，并将车辆信息上传至车辆后台系统，也可以接收车辆后台系统下发的指令并回传执行结果。其中，车辆后台系统是车辆的远程控制系统，可以由服务器或服务器集群实现。

域控制组件，也是一个独立存在的硬件。域控制组件又可以称为域控制器(DomainControl Unit，DCU)，其可以作为车辆内部不同总线之间的连接桥梁，为不同总线的设备提供信息交互方式。并且，域控制组件可以与电子控制组件连接，对电子控制组件进行控制。

需要说明的是，在车辆系统中，域控制组件可以多于一个。通常，根据车辆电子部件的功能进行划分，可以将整车划分为动力总成、车辆安全、车身电子、智能座舱、以及智能驾驶等多个域。对于各个域，可以分别设置与之对应的域控制器，域控制器用于对其对应的域进行控制。具体地，域控制器用于对其对应的域所涉及的电子控制组件进行控制。此外，域控制器具体可以采用具备一定数据处理能力的微处理器或图形处理器。当然，在其他实施例中，域控制器也可以仅为一个。

在本实施例中，车载控制组件包括车载通信组件和域控制组件，车载通信组件与域控制组件连接。并且，车载通信组件与域控制组件均是独立存在的硬件，即车载通信组件和域控制组件是两个硬件，而不是同一个硬件。

在此情况下，在车辆系统内，车载通信组件连接域控制组件，域控制组件连接电子控制组件。需要对车辆内的软件进行更新时，可以由车载通信组件从外部获取软件更新包，并将软件更新包发送至域控制组件，再由域控制组件基于车载通信组件发送的软件更新包中的待更新文件进行合法性验证，在合法性验证通过时，继续由域控制组件基于待更新文件对目标组件上的待更新软件进行更新。并且，目标组件包括域控制组件和电子控制组件中的至少一个。

举例说明，如图5所示，车辆系统SY2包括如下组件：车载T-Box、域控制器DC1、ECUA(即电子控制单元A)、ECU B、以及ECU C。其中，车载T-Box与域控制器DC1直接连接，ECU A、ECU B、以及ECU C分别与域控制器DC1直接连接，且均可以与域控制器DC1进行信息交互。此时，候选组件可包括域控制器DC1、ECU A、ECU B、以及ECU C。此外，假设域控制器DC1从车载T-Box处获得的软件更新包P1中包括待更新文件D1和待更新文件D2，共计两个待更新文件，且待更新文件D1与ECU A唯一匹配，待更新文件D2与域控制器DC1唯一匹配。基于此，在本次更新中，目标组件有两个，分别为ECU A和域控制器DC1。继而，域控制器DC1可以根据待更新文件D1对ECU A上的待更新软件进行更新，并根据待更新文件D2对域控制器DC1(自身)上的待更新软件进行更新(下文简称示例E-1)。

此外，当与车载通信组件连接的域控制组件多于一个时，车载通信组件从外部获取到软件更新包后，可以由车载通信组件对软件更新包进行初步分析，确定与该软件更新包内的待更新文件匹配的域控制器，进而可以将软件更新包发送至与之匹配的域控制器。

举例说明，在上述图5的基础上，如图6所示，车辆系统还包括域控制器DC2和ECUD。其中，域控制器DC2与图5所示的车载T-Box直接连接，ECU D与域控制器DC2直接连接。在此情况下，图5所示的车载T-Box获取到上述软件更新包P1时，由于其待更新文件D1与ECU A唯一匹配，待更新文件D2与域控制器DC1唯一匹配，因而图5所示的车载T-Box可以将软件更新包P1发送至域控制器DC1，而非域控制器DC2。

在一个实施例中，前文中的车辆系统的软件更新方法还可以包括如下步骤：获取与待更新文件对应的数字签名。在此情况下，基于待更新文件进行合法性验证，还可以包括如下步骤：基于预定密钥解密待更新文件对应的数字签名，获得该待更新文件的原始摘要；基于哈希函数，获得待更新文件的当前摘要；将原始摘要和当前摘要进行比对；当原始摘要和当前摘要一致时，判定合法性验证通过。

数字签名，可用于验证其对应的待更新文件的数据来源是否合法、以及该待更新文件是否被篡改。数字签名可采用如下方式生成：待更新文件的发行方基于哈希函数对待更新文件进行哈希处理，生成原始摘要，再使用私钥对原始摘要进行加密，生成数字签名。

后续，待更新文件的发行方将待更新文件及其对应的数字签名，传递至车辆系统。具体地，待更新文件可封装于软件更新包内，而软件更新包和数字签名彼此独立，在此情况下，待更新文件的发行方可将软件更新包和数字签名分别传递至车辆系统。或者，也可以将待更新文件和数字签名一并封装于软件更新包内，在此情况下，待更新文件的发行方可以将软件更新包传递至车辆系统，以实现将待更新文件和数字签名传递至车辆系统。

车辆系统中的车载控制组件获得待更新文件以及与该待更新文件对应的数字签名后，可基于该待更新文件和该数字签名进行合法性验证。具体地，本地控制组件基于预定密钥(即与待更新文件的发行方加密使用的私钥相匹配的公钥)解密与待更新文件对应的数字签名，此时，若能够解密出该待更新文件的原始摘要，表明待更新文件的数据来源合法，若无法解密出该原始摘要，表明待更新文件的数据来源非法。在解密出该原始摘要后，车载控制组件对待更新文件进行与待更新文件的发行方相同的哈希处理，获得当前摘要，再将当前摘要与解密出的原始摘要进行比对，此时，若两者一致，表明待更新文件未被篡改，若两者不一致，表明待更新文件已被篡改。

需要说明的是，在车载控制组件为单一的硬件(即集成控制组件)时，可以由该集成控制组件完成上述对基于该待更新文件和该数字签名进行合法性验证的任务。在车载控制组件包括车载通信组件和域控制组件时，具体可以由域控制组件完成上述对基于该待更新文件和该数字签名进行合法性验证的任务。

在一个实施例中，前文中的软件更新方法还可包括如下步骤：在域控制组件上的待启动固件满足第一可信条件时，启动待启动固件；其中，第一可信条件包括待启动固件为第一合法发行方认证的固件，第一合法发行方为域控制组件的合法发行方。并且，可以基于所启动的待启动固件，实现前文中的基于待更新文件进行合法性验证、以及在合法性验证通过时，基于待更新文件对目标组件上的待更新软件进行更新的步骤。

其中，域控制组件上的固件存储在域控制组件的软件存储区中。待启动固件是需要验证其是否满足第一可信条件，且在满足时即可启动的固件。在一个实施例中，域控制组件上的固件可以是固件镜像，即可以是验证域控制组件上的待启动固件镜像是否满足第一可信条件，在满足时，即可启动该待启动固件镜像。

需要说明的是，域控制组件本身可以具备安全启动功能，即域控制组件接通电源后，开始进行安全启动。在安全启动成功时，域控制组件进入正常工作状态，在且仅在域控制组件处于正常工作状态时，域控制组件才执行对获取到的待更新文件进行合法性验证等后续操作；反之，在安全启动失败时，可以拒绝启动域控制组件，即使得域控制组件处于不工作状态。

在本实施例中，验证域控制组件上的待启动固件是否满足第一可信条件，是实现域控制组件的安全启动中的环节。在安全启动阶段，域控制组件可以验证待启动固件是否满足第一可信条件，以确定待启动固件是否可信。具体地，在该待启动固件满足第一可信条件时，才启动该待启动固件；反之，在该待启动固件不满足第一可信条件时，不启动该待启动固件。并且，待启动固件成功启动后，可基于启动的待启动固件，实现前文中的基于待更新文件进行合法性验证、以及基于待更新文件对目标组件上的待更新软件进行更新的步骤。

其中，第一可信条件是判断待启动固件能否被启动的条件。在本实施例中，第一可信条件可以包括待启动固件为第一合法发行方认证的固件，第一合法发行方为域控制组件的合法发行方。其中，域控制组件的合法发行方(即第一合法发行方)，是具有域控制组件的正规发行资格的对象，即可信任的对象，例如域控制组件的合法发行方可以是域控制组件的厂商，或者也可以是获得域控制组件的厂商授权的对象。

需要说明的是，确保域控制组件上最终启动的固件受第一合法发行方信任，能够有效地防止攻击者篡改域控制组件上的固件，保证了更新的安全性。具体地，可有效地防止攻击者使用物理手段篡改域控制组件上的固件，使用物理手段篡改例如：攻击者将该待启动固件的软件存储区域对应的物理元件(如存储芯片)从域控制组件上拆卸下来，再将非法软件写入该物理元件中，使得域控制组件基于该非法软件进行启动。

需要说明的是，在域控制组件存储的固件仅为一个时，该固件即为待启动固件。在域控制组件存储的固件多于一个时，可根据实际应用需求在各固件进行选择，从而确定待启动固件。

还需要说明的是，在车载控制组件为单一的硬件(即集成控制组件)时，前文中的域控制组件上的固件，可以是集成控制组件上的固件，相应地，域控制组件上的待启动固件，可以是集成控制组件上的待启动固件。并且，可以由集成控制组件完成验证集成控制组件上的待启动固件是否满足第一可信条件，以及在满足时启动待启动固件的任务。

在一个实施例中，在前文中的启动待启动固件之前，还可包括如下步骤：在域控制组件上的启动引导软件满足第二可信条件时，运行该启动引导软件，其中，第二可信条件包括启动引导软件为第二合法发行方认证的软件，第二合法发行方为启动引导软件的合法发行方；并且，可以基于运行的启动引导软件，验证待启动固件是否满足第一可信条件。

其中，启动引导软件又可以称为BootLoader软件，可以通过启动引导软件实现验证域控制组件上的待启动固件是否满足第一可信条件的任务。此外，启动引导软件可是用户基于实际应用需求编写，并写入域控制组件。

在本实施例中，在验证域控制组件上的待启动固件是否满足第一可信性验证之前，还可以包括如下步骤：先通过芯片级安全验证软件验证域控制组件上的启动引导软件是否满足第二可信条件，即先确定启动引导软件是否可信。具体地，在该启动引导软件满足第二可信条件时，运行该启动引导软件；反之，在该启动引导软件不满足第二可信条件时，不运行该启动引导软件。而后，在运行该启动引导软件后，基于运行的启动引导软件，实现前文中的验证域控制组件上的待启动固件是否满足第一可信条件的步骤。

其中，芯片级安全验证软件可以是域控制组件上的验证芯片中预置的软件，即可以是该验证芯片出厂时便已写入的软件。验证芯片可以是域控制组件上负责验证启动引导软件是否满足第二可信条件的芯片。具体地，在域控制组件上，可由专用芯片负责验证启动引导软件是否满足第二可信条件，该专用芯片即为验证芯片。也可以由域控制组件上的中央处理单元(Central Processing Unit，CPU)负责验证启动引导软件是否满足第二可信条件，在此情况下，中央处理单元即为验证芯片。

需要说明的是，芯片级安全验证软件可基于任何适配的验证机制，实现验证域控制组件上的启动引导软件是否满足第二可信条件的任务。例如，可以是基于公钥/私钥的签名机制，也可以是基于哈希函数的MAC(消息认证码)机制。可以理解，具体的验证机制可基于实际业务需求进行确定。

其中，第二可信条件是判断启动引导软件能否被运行的条件。在本实施例中，第二可信条件可以包括启动引导软件为第二合法发行方认证的软件，第二合法发行方为启动引导软件的合法发行方。其中，启动引导软件的合法发行方(即第二合法发行方)，是具有启动引导软件的正规发行资格的对象，即可信任的对象。例如，启动引导软件的官方发布方，或者也可以是获得官方发布方授权的其他对象。

需要说明的是，确保域控制组件上运行的启动引导软件受第二合法发行方信任，能够有效地防止攻击者篡改该启动引导软件，从而保证了域控制组件启动的安全性，且进一步保证了更新的安全性。

还需要说明的是，在车载控制组件为单一的硬件(即集成控制组件)时，前文中的域控制组件上的引导启动软件，可以是集成控制组件上的引导启动软件。并且，可以由集成控制组件完成验证集成控制组件上的引导启动软件是否满足第二可信条件，以及在满足时运行启动引导启动软件的任务。

在一个实施例中，域控制组件上存储的固件多于一个。在此情况下，在基于运行的启动引导软件，验证待启动固件是否满足第一可信条件之前，还可以包括如下步骤：基于运行的启动引导软件，在候选固件中确定待启动固件，其中，候选固件包括：域控制组件上、未验证过其是否满足第一可信条件的各固件。

可以理解，域控制组件存储的固件多于一个，意味着域控制组件接通电源后，可以从其存储的各固件中选择一个进行启动。

在本实施例中，在需要启动域控制组件上的固件时，可先基于运行的启动引导软件，在候选固件中确定待启动固件。其中，候选固件包括：域控制组件上、未验证过其是否满足第一可信条件的各固件，亦即是说，在当前时刻还未验证过期是否满足第一可信条件的各固件中选择一个，作为待启动固件即可。当前时刻是需要确定待启动固件的时刻。确定待启动固件后，基于运行的启动引导软件，验证该待启动固件是否满足第一可信条件，满足时，启动该待启动固件，并执行后续操作。不满足时，在一个实施例中，可以返回在候选固件中确定待启动固件的步骤，即重新在候选固件中选择一个还未验证过其是否满足第一可信条件的固件，作为新的待启动固件，然后继续验证该新的待启动固件是否满足第一可信条件，以此类推，直至域控制组件上存储的各固件均已被验证过是否满足第一可信条件。

此外，若域控制组件上存储的各固件均已被验证过是否满足第一可信条件，并且各固件均不满足第一可信条件，则可以直接拒绝启动域控制组件，即使得域控制组件处于不工作状态。或者，也可以获取从域控制组件的串行接口写入的新固件，类似地，再对验证该新固件是否满足第一可信条件，并在满足时，启动该新固件。需要说明的是，启动串行接口写入的新固件的情况，多应用于工厂恢复的场景。

需要说明的是，在对候选固件进行选择，确定待启动固件时，具体的选择策略可以基于实际应用需求进行确定。例如，在一个实施例中，可以将候选固件中版本最高的固件，选为待启动固件，当然，也可以将候选固件中版本最低的固件，选为待启动固件。

还需要说明的是，在车载控制组件为单一的硬件(即集成控制组件)时，前文中的候选固件可以包括：集成控制组件上、未验证过其是否满足第一可信条件的各固件。

在一个实施例中，如图7所示，以车辆内的域控制器上有两个固件，一个为高版本固件，另一个为低版本固件为例，对该域控制器进行安全启动的方式进行说明。该方式具体可以包括如下步骤S702至S716。

S702，通过芯片级安全验证软件，验证域控制器上的启动引导软件是否满足第二可信条件；在满足第二可信条件时，跳转至步骤S704，在不满足第二可信条件时，拒绝启动域控制器。

S704，运行启动引导软件。

S706，通过启动引导软件，验证高版本固件是否满足第一可信条件；在满足第一可信条件时，跳转至步骤S708，在高版本固件不满足第一可信条件时，跳转至步骤S710。

S708，通过启动引导软件，启动高版本固件，完成安全启动。

S710，通过启动引导软件，验证低版本固件是否满足第一可信条件；在低版本固件满足第一可信条件时，跳转至步骤S712，在低版本固件不满足第一可信条件时，跳转至步骤S714。

S712，通过启动引导软件，启动低版本固件，完成安全启动。

S714，通过启动引导软件，验证通过串行接口写入的新固件是否满足第一可信条件；在新固件满足第一可信条件时，跳转至步骤S716，在新固件不满足第一可信条件时，结束启动流程。

S716，通过启动引导软件，启动新固件，完成安全启动。

在一个实施例中，目标组件多于一个，软件更新包还包括：待更新文件的文件描述信息。在此情况下，基于待更新文件对目标组件上的待更新软件进行更新的步骤，即步骤S206，可以包括如下步骤：基于文件描述信息确定更新顺序，更新顺序用于指示对各目标组件上的待更新软件进行更新的先后顺序；基于更新顺序，依次对各目标组件上的待更新软件进行更新。

其中，文件描述信息可用于描述待更新文件的属性特征。文件描述信息具体可包括：待更新文件匹配的组件标识、待更新文件对应的版本标识、待更新文件的数据大小信息、以及待更新文件对应的前置条件等中的至少一个。

待更新文件匹配的组件标识，是与待更新文件匹配的目标组件的唯一标识。例如，对于前文中的示例E-1，待更新文件D1匹配的组件标识是ECU A的唯一标识，待更新文件D2匹配的组件标识是域控制器DC1的唯一标识。

待更新文件对应的版本标识，是基于该待更新文件完成对相应待更新软件的更新后，待更新软件的版本标识。例如，待更新文件D3的版本编号为1.2.1，在基于该待更新文件D3对待更新软件S1进行更新之前，待更新软件S1的版本编号为1.2.0，完成本次更新后，该待更新软件S1的版本编号则为1.2.1。

待更新文件的数据大小信息，可用于衡量待更新文件的大小。例如，待更新文件D1的数据大小信息为280MB、待更新文件D2的数据大小信息为500MB。

待更新文件对应的前置条件，是开始执行“基于该待更新文件对相应待更新软件进行更新”这一操作所需要满足的前提条件，亦即是说，对于任一待更新文件，需要满足该待更新文件对应的前置条件，域控制组件才会开始执行基于该待更新文件对相应待更新软件进行更新的操作。可以理解，在车载控制组件是集成控制组件时，需要满足该待更新文件对应的前置条件，集成控制组件才会开始执行基于该待更新文件对相应待更新软件进行更新的操作。为便于说明，以下均以车载控制组件包括域控制组件的情况为例进行说明。

例如，对于前文中的示例E-1，假设ECU A用于控制车辆车身部件，待更新文件D1对应的前置条件为车辆后备箱当前处于关闭状态。在此情况下，域控制组件需要先检测车辆后备箱的当前状态，若车辆后备箱当前处于关闭状态，即满足前置条件，域控制组件则开始基于待更新文件D1对ECU A上的待更新软件进行更新；反之，若车辆后备箱当前处于开启状态，即不满足前置条件，域控制组件则不会开始执行基于待更新文件D1对ECU A上的待更新软件进行更新的操作。此外，在不满足前置条件时，也可以先控制车辆后备箱关闭，后续确定车辆后备箱当前处于关闭状态时，再开始基于待更新文件D1对ECU A上的待更新软件进行更新。

对于域控制组件确定更新顺序的操作，在一个实施例中，域控制组件可根据文件描述信息中的各项信息以及实际应用需求，自行确定更新顺序。具体地，域控制组件可生成更新顺序描述文件，该更新顺序描述文件可用于描述对各目标组件上的待更新软件进行更新的先后顺序。其中，更新顺序描述文件具体可以是更新顺序表。在另一个实施例中，软件更新包中的文件描述信息中可以直接包含更新顺序信息。在此情况下，域控制组件可以从文件描述信息中解析出更新顺序信息，继而，直接根据解析获得的更新顺序信息确定更新顺序。

需要说明的是，在一次更新过程中，若目标组件同时包括域控制组件和电子控制组件，亦即是说，在一次更新过程中，既需要对域控制组件上的软件进行更新，也需要对与该域控制组件连接的电子控制组件上的软件进行更新。在此情况下，通常是先对与域控制组件连接的电子控制组件上的待更新软件进行更新，在各电子控制组件上的待更新软件均更新成功后，再对域控制组件上的待更新软件进行更新，以此避免域控制组件完成更新后发生重启，从而导致还未进行更新的电子控制组件后续无法再完成更新。

当然，此处将域控制组件排列在最后进行更新，并不是对域控制组件和电子控制组件的更新顺序进行严格限定。只要能够克服上述电子控制组件无法更新的问题，域控制组件和电子控制组件的更新顺序可以没有严格的限定。域控制组件也可以排列在电子控制组件之前进行更新，例如，对于域控制组件完成软件更新后不会发生重启的情况，域控制组件排列在电子控制组件之前进行更新不会出现上述电子控制组件无法更新问题(电子控制组件因域控制组件完成更新后重启导致的无法更新的问题)，在此情况下，域控制组件则可以排列在在电子控制组件之前进行更新。此外，对于域控制组件完成软件更新后会发生重启的情况，若可以通过其他技术手段解决上述电子控制组件无法更新的问题，域控制组件也可以排列在电子控制组件之前进行更新。

在一个实施例中，目标组件多于一个。在此情况下，基于待更新文件对目标组件上的待更新软件进行更新，即步骤S206，可以包括如下步骤：在候选目标组件中确定当前目标组件，候选目标组件包括未对其待更新软件进行过更新的各目标组件；确定当前目标组件的组件类型；基于组件类型、以及与当前目标组件匹配的待更新文件，对当前目标组件上的待更新软件进行更新；并且，在当前目标组件完成更新后，返回在候选目标组件中确定当前目标组件的步骤。

候选目标组件，其包括未对其待更新软件进行过更新的各目标组件。可以理解，候选目标组件中包括的各目标组件会随着更新进度的推进而发生变化。例如，在针对车辆系统的一次更新过程中，各目标组件分别为目标组件A1、目标组件A2、以及目标组件A3，共计三个目标组件，首次确定当前目标组件时，候选目标组件包括目标组件A1至A3，共计三个目标组件，若本次将目标组件A2确定为当前目标组件，再对目标组件A2上的待更新软件进行更新后，第二次确定当前目标组件时，候选目标组件仅包括目标组件A1和A3，共计两个目标组件，以此类推。

在一个实施例中，目标组件多于一个时，可以依次对各目标组件上的待更新软件进行更新。具体地，先在候选目标组件中确定当前目标组件。由于对域控制组件上的待更新软件进行更新、以及对电子控制组件上的待更新软件进行更新，可采用不同的更新方式实现，在对当前目标组件进行软件更新之前，可先确定该当前目标组件的组件类型，如确定该当前目标组件属于域控制组件，还是属于电子控制组件。继而，根据当前目标组件的组件类型以及与当前目标组件匹配的待更新文件，对该当前目标组件上的待更新软件进行更新。而后，当前目标组件完成更新后，返回在候选目标组件中确定当前目标组件，即一个目标组件完成更新后，可以继续选取下一个需要进行更新的目标组件，并对选中的目标组件进行更新，直至车辆系统中的各目标组件均完成更新。

在一个实施例中，基于组件类型、以及与当前目标组件匹配的待更新文件，对当前目标组件上的待更新软件进行更新，可以包括如下步骤：在当前目标组件的组件类型对应电子控制组件时，确定当前目标组件的适配更新协议；基于适配更新协议，从与当前目标组件匹配的待更新文件中，获得第一适配更新数据；将第一适配更新数据发送至当前目标组件；第一适配更新数据用于供当前目标组件根据第一适配更新数据对其待更新软件进行更新。

其中，适配更新协议是对应的当前目标组件所支持的更新协议。可以理解，当前目标组件的组件类型对应电子控制组件(即当前目标组件属于电子控制组件)时，只有采用当前目标组件所支持的更新协议，才能完成对当前目标组件上的待更新软件的更新；反之，若采用当前目标组件不支持的更新协议，则无法完成对当前目标组件上的待更新软件的更新。并且，不同的当前目标组件支持的更新协议可能有所不同。例如，车辆中的电子控制组件涉及的更新协议，可以包括UDS(Unified Diagnostic Services，统一诊断服务)协议。

并且，同一待更新文件中可以包括两组以上的更新数据，各组更新数据对应的更新内容相同(即各组更新数据可以用于对同一待更新软件进行更新，并且可实现相同内容的更新)，但数据格式可以各不相同，各种数据格式分别匹配一种更新协议。在此情况下，当前目标组件的组件类型对应电子控制组件时，确定当前目标组件的适配更新协议后，可从与该当前目标组件匹配的待更新文件中获取与该适配更新协议匹配的更新数据，即该当前目标组件的第一适配更新数据。例如，待更新文件D3中包括三组更新数据，分别为更新数据Da1、更新数据Da2、以及更新数据Da3，这三组更新数据均对应相同的更新内容，但更新数据Da1的数据格式为与更新协议AG1匹配的数据格式F1，更新数据Da2的数据格式为与更新协议AG2匹配的数据格式F2，更新数据Da3的数据格式为与更新协议AG3匹配的数据格式F3。在此情况下，若某一当前目标组件N1的组件类型对应电子控制组件，且其适配更新协议为更新协议AG2，由于与适配更新协议AG2匹配的更新数据为更新数据Da2，因而该当前目标组件N1的第一适配更新数据为更新数据Da2。

当前目标组件的组件类型对应电子控制组件时，车载控制组件在获得当前目标组件的第一适配更新数据后，可以将该第一适配更新数据发送至该当前目标组件。相应地，该当前目标组件根据第一适配更新数据，对其待更新软件进行更新。

在一个实施例中，当前目标组件的组件类型对应电子控制组件时，将第一适配更新数据发送至当前目标组件的步骤之前，还可包括如下步骤：车载控制组件基于适配更新协议，向该当前目标组件发送更新开启通知，该更新开启通知用于触发该当前目标组件进入更新模式(即触发当前目标组件做好对软件进行更新的相关准备)。相应地，当前目标组件接收到更新开启通知后，进入更新模式，并在成功进入更新模式时，返回更新准备完成消息。在此情况下，车载控制组件可以在接收到当前目标组件返回的更新准备完成消息后，才将该当前目标组件的第一适配更新数据发送至该当前目标组件。

在一个实施例中，当前目标组件的组件类型对应电子控制组件时，将第一适配更新数据发送至当前目标组件的步骤之后，还可包括如下步骤：车载控制组件基于适配更新协议，向该当前目标组件发送更新结束通知，该更新结束通知用于触发该当前目标组件结束更新(如退出更新模式)。相应地，当前目标组件接收到更新结束通知后，结束更新。

在另一个实施例中，当前目标组件的组件类型对应电子控制组件时，将第一适配更新数据发送至当前目标组件的步骤之后，还可包括如下步骤：车载控制组件接收当前目标组件发送的更新结束消息，该更新结束消息为当前目标组件在结束更新时生成，用于表征该当前目标组件已结束更新。相应地，车载控制组件接收到当前目标组件发送的更新结束通知后，记录该当前目标组件的更新已结束。

在一个实施例中，当前目标组件的组件类型对应电子控制组件时，将第一适配更新数据发送至当前目标组件的步骤之后，还可包括如下步骤：在当前目标组件结束更新后，车载控制组件还可根据软件更新包中的文件描述信息，获取该当前目标组件的更新结果，更新结果可包括更新成功结果或更新失败结果。可以理解，更新结果为更新成功结果时，表明该当前目标组件更新成功，更新结果为更新失败结果时，表明该当前目标组件更新失败。

例如，在当前目标组件结束更新后，车载控制组件可以向该当前目标组件发送版本信息查询请求，该版本信息查询请求用于触发该当前目标组件向车载控制组件返回：该当前目标组件上的待更新软件的当前版本信息(即经历过更新操作以后的版本信息)。车载控制组件接收到该当前目标组件返回的当前版本信息后，可以将该当前版本信息与文件描述信息中、待更新文件对应的版本标识进行比对，当两者一致时，该当前目标组件的更新结果即为更新成功结果，反之，两者不一致时，该当前目标组件的更新结果即为更新失败结果。

此外，在当前目标组件的更新结果为更新失败结果时，车载控制组件可再次基于与该当前目标组件匹配的待更新文件，对该当前目标组件上的待更新软件进行更新，以此类推，直至该当前目标组件的累计失败次数达到预定次数阈值，结束更新流程。具体地，结束更新流程可以是结束该当前目标组件的更新流程，也可是结束整个车辆系统的更新流程，即停止对车辆系统中的任一目标组件进行更新。需要说明的是，当前目标组件的更新结果为更新失败结果时，车载控制组件的具体响应方式，可以基于实际应用需求进行确定，本申请不作具体限定。

需要说明的是，在车载控制组件是集成控制组件时，可由集成控制组件完成基于组件类型、以及与当前目标组件匹配的待更新文件，对当前目标组件上的待更新软件进行更新这一任务。然而，在车载控制组件包括车载通信组件和域控制组件两个独立的硬件时，具体可以由域控制组件完成基于组件类型、以及与当前目标组件匹配的待更新文件这一任务。

在一个实施例中，基于组件类型、以及与当前目标组件匹配的待更新文件，对当前目标组件上的待更新软件进行更新，可包括如下步骤：在当前目标组件的组件类型对应车载控制组件时，从待更新文件中获得当前目标组件的第二适配更新数据；确定当前目标组件上的目标软件存储区；目标软件存储区当前处于未活动状态，待更新软件存储于目标软件存储区；将第二适配更新数据写入目标软件存储区。

其中，目标软件存储区是用于存储待更新软件的存储区域。并且，在确定目标软件存储区的时刻，目标软件存储区处于未活动状态，表明在此时刻，目标软件存储区内的待更新软件处于未运行状态。在当前目标组件的组件类型对应车载控制组件时，将当前目标组件的第二适配更新数据写入目标软件存储区，即可以实现对当前目标组件上的待更新软件进行更新。

具体地，在车载控制组件是集成控制组件时，当前目标组件的组件类型对应车载控制组件，具体是指当前目标组件的组件类型对应集成控制组件，而在车载控制组件包括车载通信组件和域控制组件两个独立的硬件时，具体是指当前目标组件的组件类型对应域控制组件，为便于说明，以下均以车载控制组件包括域控制组件的情况为例进行说明。

具体地，如前文描述，域控制组件上存储的固件多于一个时，可在各固件中选择一个，在选中的固件满足第一可信条件时，启动该固件。由此可知，对于其组件类型对应域控制组件的当前目标组件而言，启动选中的固件后，当前目标组件上未被选中的其他固件处于未运行状态。在此情况下，需要对当前目标组件上的固件进行更新时，可将处于未运行状态的固件确定为待更新软件。相应地，该被确定的固件所在的软件存储区即为目标软件存储区。继而，可将当前目标组件的第二适配更新数据写入目标软件存储区，以对当前目标组件上的待更新软件进行更新。

此外，对于其组件类型对应域控制组件的当前目标组件，在当前目标组件上存储的固件仅为一个时，若该固件满足第一可信条件，当前目标组件接通电源后，该固件将被启动。如此，在需要对当前目标组件上的固件进行更新时，该固件处于运行状态，且当前目标组件上亦不存在处于未运行状态的其他固件可供更新使用。在此情况下，可将当前目标组件的第二适配更新数据写入内存中，而后，当前目标组件重新启动时，从内存中加载相应的数据，以实现对当前目标组件上的待更新软件进行更新。

在一个实施例中，在当前目标组件的组件类型对应域控制组件时，将第二适配更新数据写入目标软件存储区的步骤之后，还可包括如下步骤：在当前目标组件结束更新后，当前目标组件还可校验数据写入结果的正确性，获得当前目标组件的更新结果。可以理解，数据写入结果正确时，更新结果为更新成功结果，表明该当前目标组件更新成功；反之，数据写入结果错误时，更新结果为更新失败结果，表明该当前目标组件更新失败。

此外，与前文中对属于电子控制组件的当前目标组件的更新结果为更新失败结果类似，在当前目标组件的组件类型对应域控制组件时，若该当前目标组件的更新结果为更新失败结果，域控制组件可再次基于与该当前目标组件匹配的待更新文件，对该当前目标组件上的待更新软件进行更新，以此类推，直至该当前目标组件的累计失败次数达到预定次数阈值，结束更新流程。具体地，结束更新流程可以是结束该当前目标组件的更新流程，也可是结束整个车辆系统的更新流程。需要说明的是，当前目标组件的更新结果为更新失败结果时，域控制组件的具体响应方式，可基于实际应用需求进行确定，本申请中不作具体限定。

在一个实施例中，前文中的软件更新方法还可包括如下步骤：获取各目标组件的更新结果；在各更新结果均为更新成功结果时，触发各目标组件重新启动。

需要说明的是，各目标组件的更新结果均为更新成功结果，表明在本次对车辆系统中的各目标组件的更新中，各目标组件均更新成功。在此情况下，可以触发各目标组件重新启动，即在各目标组件均更新成功后，使各目标组件一并重新启动，以使各目标组件的更新生效。当然，在其他实施例中，各目标组件均更新成功后，也可以不触发目标组件重新启动。

在一个实施例中，车载控制组件包括车载通信组件、以及与车载通信组件连接的域控制组件时，触发各目标组件重新启动，可包括如下步骤：域控制组件向车载通信组件发送更新完成通知，车载通信组件将更新完成通知分发至车辆系统内的各组件，并在分发完成后的预定时长后，车载通信组件触发各目标组件重新启动。具体地，车载通信组件触发各目标组件重新启动，具体可以是车载通信组件触发整车重新启动，从而使得车辆系统中的各目标组件重新启动，以保证各目标组件运行软件的版本一致，且保证各目标组件均已切换至更新后的版本。此外，在分发完成后的预定时长后，也可以由域控制组件触发各目标组件重新启动。

在一个实施例中，如图8所示，提供了一种车辆系统的软件更新方法。以车辆系统包括车载T-Box、域控制器以及ECU，且目标组件包括域控制器和ECU为例进行说明。该方法具体可包括如下步骤S802至S820。

S802，域控制器验证其启动引导软件是否满足第二可信条件，并在满足第二可信条件时，跳转至S804。

S804，域控制器运行启动引导软件。

S806，域控制器基于启动引导软件，验证待启动固件是否满足第一可信条件，并在满足第一可信条件时，跳转至S808。

S808，域控制器启动待启动固件。

S810，车载T-Box从外部获取软件更新包，并将软件更新包发送至域控制器，软件更新包包括待更新文件。

S812，域控制器启动该待启动固件后，域控制器基于车载T-Box发送的软件更新包中的待更新文件进行合法性验证，合法性验证包括验证待更新文件的数据来源是否合法、以及验证待更新文件是否被篡改；并且，在合法性验证通过时，跳转至步骤S814。

S814，域控制器基于待更新文件对ECU上的待更新软件进行更新。

S816，域控制器基于待更新文件对与其自身的待更新软件进行更新。

S818，在ECU和域控制器的更新结果均为更新成功结果时，域控制器向车载T-Box发送更新完成通知。

S820，域控制器触发ECU以及其自身重新启动。

需要说明的是，对本实施例中的各技术特征的限定，可与前文各实施例中对相应技术特征的限定相同，此处不加赘述。

此外，对于车辆而言，车辆主机厂通常会为车辆设计诊断升级通道，该诊断升级通道的设计初衷是对出现故障的车辆进行诊断或整车升级。据此，在实际应用中，亦可复用诊断升级通道对车辆内的各电子控制组件上的待升级软件进行升级。具体地，由车载T-Box从外部获取软件升级包，并对该软件升级包进行处理，获得升级使用的底层报文。继而，车载T-Box在非实时总线(如以太网)上直接发送该底层报文。网关设备对该底层报文进行信息格式转换，获得升级报文，再将该升级报文透明传输至对应总线上，从而对各相应电子控制组件上的待升级软件进行升级。

上述复用诊断升级通道的方案具有以下风险：(1)安全性风险，该诊断升级通道是主机厂为了对出现故障的车辆进行诊断或整车升级而设计，缺乏对升级软件进行合法性校验的功能。攻击者或非授权的软件提供商可借用该诊断升级通道，对ECU的固件进行篡改，从而对车辆信息安全产生负面影响。(2)故障溯源风险，复用了诊断升级通道后，域控制器无法区分升级请求属于诊断升级还是OTA升级，因而域控制器的日志中无法追溯软件更新来源，对车辆故障和事故后的软件来源追查造成了极大不便。此外，升级报文由车载T-Box经由网关设备发送，一旦车载T-Box出现异常，与升级无关的各种控制报文均可经由网关设备透明传输至车内总线上，从而影响车内其他组件的正常工作。(3)软件管理风险，复用诊断升级通道后，软件发行方对升级使用的软件和正常软件需要采用类似的发行方式，容易造成软件管理的混乱，导致域控制器无法区分升级使用的软件和正常软件。

然而，本申请各实施例提供的车辆系统的软件更新方法中，车载T-Box从外部获取携带待更新文件的软件更新包，并将该软件更新包发送至域控制器。域控制器安全启动后，对待更新文件进行合法性验证，经验证确定待更新文件的数据来源的合法且待更新文件本身未被篡改后，由域控制器基于待更新文件对目标组件上的待更新软件进行更新，目标组件包括域控制器以及与域控制器连接的ECU中的至少一个。

本申请各实施例提供的车辆系统的软件更新方法，本质上属于OTA(Over-the-AirTechnology，空中下载技术)更新方法。相较于复用诊断升级通道的方案，本申请引入了合法性验证环节，提高了更新的安全性。并且，合法性验证操作和控制目标组件上的待更新软件进行更新的操作均在域控制器上实现。一方面，相较于车载T-Box等组件，域控制器对外提供的服务较少，且其对外提供的服务与OTA更新服务的耦合性较小，因而域控制器的攻击面较小(即遭受攻击后被攻破的可能性较小)。另一方面，域控制器本身进行安全启动，在安全启动后，才对待更新文件进行合法性验证，即先确保域控制器的固件是可靠的。综合上述两方面，本申请各实施例提供的车辆系统的软件更新方法，能够有效地提高更新的安全性。此外，本申请与车辆原有的诊断升级通道是独立的，因而不存在上述安全性风险、故障溯源风险、软件管理风险等风险。

应该理解的是，虽然前文各实施例涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以其它的顺序执行。而且，各流程图中的至少一部分步骤可包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，提供了一种车辆系统。请参照图3，该车辆系统可以包括车载控制组件、以及与车载控制组件连接的电子控制组件。在此情况下，车载控制组件用于获取软件更新包，软件更新包包括待更新文件；并基于待更新文件进行合法性验证；在合法性验证通过时，基于待更新文件对目标组件上的待更新软件进行更新，目标组件与待更新文件匹配，且目标组件包括车载控制组件和电子控制组件中的至少一个。

在一个实施例中，请参照图4，车载控制组件包括车载通信组件、以及与车载通信组件连接的域控制组件，域控制组件连接电子控制组件。在此情况下，车载通信组件用于从外部获取软件更新包，并将软件更新包发送至域控制组件；域控制组件用于接收车载通信组件发送的软件更新包；域控制组件还用于实现基于待更新文件进行合法性验证，在合法性验证通过时，基于待更新文件对目标组件上的待更新软件进行更新的步骤。

需要说明的是，对本申请提供的车辆系统涉及的各技术特征的限定，可与前文各实施例中对车辆系统的软件更新方法中涉及的相应技术特征的限定相同，此处不加赘述。

在一个实施例中，如图9所示，提供了一种车辆系统的软件更新装置900。车辆系统包括车载控制组件、以及与车载控制组件连接的电子控制组件。该装置可包括如下模块902至906。

更新包获取模块902，用于通过车载控制组件获取软件更新包；软件更新包包括待更新文件。合法性验证模块904，用于通过车载控制组件，基于待更新文件进行合法性验证。软件更新模块906，用于在合法性验证通过时，通过车载控制组件，基于待更新文件对目标组件上的待更新软件进行更新；其中，目标组件与待更新文件匹配，且目标组件包括车载控制组件和电子控制组件中的至少一个。

上述车辆系统的软件更新装置900，通过车载控制组件获得待更新文件，再基于待更新文件进行合法性验证，并在验证通过时，基于待更新文件对车载控制组件和/或电子控制组件上的待更新软件进行更新。首先，更新过程由车辆系统中的组件自动完成，无需专业维修人员参与，便捷性及效率高。再则，对待更新文件进行合法性验证，验证通过时才进行更新，更新的安全性高。此外，待更新文件的合法性验证操作，以及针对待更新对象的更新控制操作均由车载控制组件完成，即由待更新对象本身或与待更新对象直接连接的组件完成，进一步保证了更新的安全性。

在一个实施例中，车载控制组件包括车载通信组件、以及与车载通信组件连接的域控制组件；域控制器组件连接电子控制组件。在此情况下，通过车载通信组件，从外部获取软件更新包，并将软件更新包发送至域控制组件；通过域控制组件，实现基于待更新文件进行合法性验证，以及在合法性验证通过时，基于待更新文件对目标组件上的待更新软件进行更新的步骤；目标组件包括域控制组件和电子控制组件中的至少一个。

在一个实施例中，前文中的软件更新装置900还可包括如下模块：第一可信验证模块，用于在域控制组件上的待启动固件满足第一可信条件时，启动待启动固件；其中，第一可信条件包括待启动固件为第一合法发行方认证的固件，第一合法发行方为域控制组件的合法发行方。在此情况下，合法性验证模块904具体用于基于所启动的待启动固件，实现基于待更新文件进行合法性验证，软件更新模块906具体用于基于所启动的待启动固件，在合法性验证通过时，基于待更新文件对目标组件上的待更新软件进行更新的步骤。

在一个实施例中，前文中的软件更新装置900还可包括如下模块：第二可信验证模块，用于在域控制组件上的启动引导软件满足第二可信条件时，运行该启动引导软件；其中，第二可信条件包括启动引导软件为第二合法发行方认证的软件，第二合法发行方为启动引导软件的合法发行方；第一可信验证模块具体用于基于运行的启动引导软件，验证待启动固件是否满足第一可信条件。

在一个实施例中，域控制组件上的固件多于一个。在此情况下，前文中的软件更新装置900还可包括第一待启动固件确定模块，其用于基于运行的启动引导软件，在候选固件中确定待启动固件；候选固件包括：域控制组件上、未验证过其是否满足第一可信条件的各固件。

在一个实施例中，前文中的软件更新装置900第二待启动固件确定模块，其在域控制组件上的待启动固件不满足第一可信条件时，返回在候选固件中确定待启动固件的步骤。

在一个实施例中，目标组件多于一个，软件更新包还包括待更新文件的文件描述信息。在此情况下，软件更新模块906可以包括如下单元：更新顺序确定单元，用于基于文件描述信息确定更新顺序，更新顺序用于指示对各目标组件上的待更新软件进行更新的先后顺序；第一软件更新单元，用于基于更新顺序，依次对各目标组件上的待更新软件进行更新。

在一个实施例中，目标组件多于一个；在此情况下，软件更新模块906可以包括如下单元：第一当前组件确定单元，用于在候选目标组件中确定当前目标组件，候选目标组件包括：未对其待更新软件进行过更新的各目标组件；组件类型确定单元，用于确定当前目标组件的组件类型；第二软件更新单元，用于基于组件类型、以及与当前目标组件匹配的待更新文件，对当前目标组件上的待更新软件进行更新；第二当前组件确定单元，在当前目标组件完成更新后，调用第一当前组件确定单元，以返回在候选目标组件中确定当前目标组件的步骤。

在一个实施例中，第二软件更新单元可以包括如下子单元：更新协议确定子单元，用于在组件类型对应电子控制组件时，确定当前目标组件的适配更新协议；第一适配数据确定子单元，用于基于适配更新协议，从与当前目标组件匹配的待更新文件中，获得第一适配更新数据；适配数据发送子单元，用于将第一适配更新数据发送至当前目标组件；第一适配更新数据用于供当前目标组件根据第一适配更新数据，对其待更新软件进行更新。

在一个实施例中，第二软件更新单元可以包括如下子单元：第二适配数据确定子单元，用于在组件类型对应车载控制组件时，从待更新文件中获得当前目标组件的第二适配更新数据；目标存储区确定子单元，用于确定当前目标组件上的目标软件存储区，目标软件存储区用于存储待更新软件，且目标软件存储区当前处于未活动状态；更新数据写入子单元，用于将第二适配更新数据写入目标软件存储区。

在一个实施例中，前文中的软件更新装置900还可以包括如下模块：更新结果获取模块，用于获取各目标组件的更新结果；重启触发模块，用于在各更新结果均为更新成功结果时，触发各目标组件重新启动。

需要说明的是，关于上述软件更新装置900涉及的技术特征的具体限定，可参见前文中对于图像识别方法中涉及的对应技术特征的限定，在此不再赘述。此外，上述软件更新装置900中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可硬件形式内嵌于或独立于计算机设备中的处理器中，也可以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现本申请任一实施例提供的软件更新方法中的步骤。

在一个具体示例中，该计算机设备可是图1中示出的车辆系统110，其内部结构图可如图10所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中，该处理器用于提供计算和控制能力。该存储器包括非易失性存储介质和内存储器，该非易失性存储介质存储有操作系统和计算机程序，该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境，该计算机程序被处理器执行时以实现一种软件更新方法。该网络接口用于与外部的终端通过网络连接通信。该显示屏可是液晶显示屏或者电子墨水显示屏。该计算机设备的输入装置可是显示屏上覆盖的触摸层，也可是计算机设备外壳上设置的按键、轨迹球或触控板，还可是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解，图10中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，本申请提供的车辆系统的软件更新装置可实现为一种计算机程序的形式，计算机程序可在如图10所示的计算机设备上运行。计算机设备的存储器中可存储组成该软件更新装置的各个程序模块。比如，图9所示的更新包获取模块902、合法性验证模块904、以及软件更新模块906。各个程序模块构成的计算机程序使得处理器执行本文中描述的本申请各实施例的软件更新方法中的步骤。例如，图10所示的计算机设备可通过如图9所示的软件更新装置900中的更新包获取模块902执行步骤S202、通过合法性验证模块904执行步骤S204、通过软件更新模块906执行步骤S206等等。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一非易失性计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

据此，在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现本申请任一实施例提供的车辆系统的软件更新方法。

以上实施例的各技术特征可进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (15)

1.一种车辆系统的软件更新方法，其特征在于，车辆系统包括车载控制组件、以及与所述车载控制组件连接的电子控制组件，所述方法包括：

通过所述车载控制组件获取软件更新包；所述软件更新包包括待更新文件；

通过所述车载控制组件，基于所述待更新文件进行合法性验证；

在所述合法性验证通过时，通过所述车载控制组件，基于所述待更新文件对目标组件上的待更新软件进行更新；其中，所述目标组件与所述待更新文件匹配，且所述目标组件包括所述车载控制组件和所述电子控制组件中的至少一个。

2.根据权利要求1所述的方法，其特征在于：所述车载控制组件包括车载通信组件、以及与所述车载通信组件连接的域控制组件；所述域控制器组件连接所述电子控制组件；

通过所述车载通信组件，从外部获取所述软件更新包，并将所述软件更新包发送至所述域控制组件；

通过所述域控制组件，实现基于所述待更新文件进行合法性验证，以及在所述合法性验证通过时，基于所述待更新文件对目标组件上的待更新软件进行更新的步骤；所述目标组件包括所述域控制组件和所述电子控制组件中的至少一个。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

在所述域控制组件上的待启动固件满足第一可信条件时，启动所述待启动固件；其中，所述第一可信条件包括所述待启动固件为第一合法发行方认证的固件，所述第一合法发行方为所述域控制组件的合法发行方；

基于启动的所述待启动固件，实现基于所述待更新文件进行合法性验证、以及在所述合法性验证通过时，基于所述待更新文件对目标组件上的待更新软件进行更新的步骤。

4.根据权利要求3所述的方法，其特征在于，在所述启动所述待启动固件之前，还包括：

在所述域控制组件上的启动引导软件满足第二可信条件时，运行该启动引导软件；其中，所述第二可信条件包括所述启动引导软件为第二合法发行方认证的软件，所述第二合法发行方为所述启动引导软件的合法发行方；

基于运行的所述启动引导软件，验证所述待启动固件是否满足所述第一可信条件。

5.根据权利要求4所述的方法，其特征在于，所述域控制组件上的固件多于一个；

在基于运行的所述启动引导软件，验证所述待启动固件是否满足所述第一可信条件之前，还包括：

基于运行的所述启动引导软件，在候选固件中确定待启动固件；所述候选固件包括：所述域控制组件上、未验证过其是否满足所述第一可信条件的各所述固件。

6.根据权利要求5所述的方法，其特征在于，所述方法还包括：

在所述域控制组件上的待启动固件不满足所述第一可信条件时，返回在所述候选固件中确定待启动固件的步骤。

7.根据权利要求1所述的方法，其特征在于，所述目标组件多于一个，所述软件更新包还包括所述待更新文件的文件描述信息；

所述基于所述待更新文件对目标组件上的待更新软件进行更新，包括：

基于所述文件描述信息确定更新顺序，所述更新顺序用于指示对各所述目标组件上的待更新软件进行更新的先后顺序；

基于所述更新顺序，依次对各所述目标组件上的待更新软件进行更新。

8.根据权利要求1所述的方法，其特征在于，所述目标组件多于一个；

所述基于所述待更新文件对目标组件上的待更新软件进行更新，包括：

在候选目标组件中确定当前目标组件，所述候选目标组件包括：未对其待更新软件进行过更新的各所述目标组件；

确定所述当前目标组件的组件类型；

基于所述组件类型、以及与所述当前目标组件匹配的所述待更新文件，对所述当前目标组件上的待更新软件进行更新；

在所述当前目标组件完成更新后，返回在候选目标组件中确定当前目标组件的步骤。

9.根据权利要求8所述的方法，其特征在于，所述基于所述组件类型、以及与所述当前目标组件匹配的所述待更新文件，对所述当前目标组件上的待更新软件进行更新，包括：

在所述组件类型对应所述电子控制组件时，确定所述当前目标组件的适配更新协议；

基于所述适配更新协议，从与所述当前目标组件匹配的所述待更新文件中，获得第一适配更新数据；

将所述第一适配更新数据发送至所述当前目标组件；所述第一适配更新数据用于供所述当前目标组件根据所述第一适配更新数据，对其待更新软件进行更新。

10.根据权利要求8所述的方法，其特征在于，所述基于所述组件类型、以及与所述当前目标组件匹配的所述待更新文件，对所述当前目标组件上的待更新软件进行更新，包括：

在所述组件类型对应所述车载控制组件时，从所述待更新文件中获得所述当前目标组件的第二适配更新数据；

确定所述当前目标组件上的目标软件存储区，所述目标软件存储区用于存储所述待更新软件，且所述目标软件存储区当前处于未活动状态；

将所述第二适配更新数据写入所述目标软件存储区。

11.根据权利要求1至10任一项所述的方法，其特征在于，还包括：

获取各所述目标组件的更新结果；

在各所述更新结果均为更新成功结果时，触发各所述目标组件重新启动。

12.一种车辆系统，其特征在于，包括车载控制组件、以及与所述车载控制组件连接的电子控制组件；

所述车载控制组件用于获取软件更新包，所述软件更新包包括待更新文件；并基于所述待更新文件进行合法性验证；在所述合法性验证通过时，基于所述待更新文件对目标组件上的待更新软件进行更新，所述目标组件与所述待更新文件匹配，且所述目标组件包括所述车载控制组件和所述电子控制组件中的至少一个。

13.根据权利要求12所述的系统，其特征在于，所述车载控制组件包括车载通信组件、以及与所述车载通信组件连接的域控制组件，所述域控制组件连接所述电子控制组件；

所述车载通信组件用于从外部获取所述软件更新包，并将所述软件更新包发送至所述域控制组件；

所述域控制组件用于接收所述车载通信组件发送的所述软件更新包；

所述域控制组件还用于实现所述基于所述待更新文件进行所述合法性验证，在所述合法性验证通过时，基于所述待更新文件对目标组件上的待更新软件进行更新的步骤。

14.一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至12中任一项所述的方法的步骤。

15.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至12中任一项所述方法的步骤。