CN116743726A - 一种车辆升级方法、装置、设备及存储介质 - Google Patents

Abstract

本申请涉及一种车辆升级方法、装置、设备及存储介质，方法包括响应于车辆升级请求，对车辆的运行状态进行检测，得到检测结果；在检测结果表征运行状态满足升级条件的情况下，下载多个升级数据包至预设存储位置；对预设存储位置中的至少两个升级数据包进行数据一致性判断，得到判断结果；在判断结果表征至少两个升级数据包的数据一致的情况下，在至少两个升级数据包中确定目标升级数据包；基于目标升级数据包，对车辆的软件进行升级。本申请考虑了汽车软件升级过程中的多种失效场景，避免了失效导致车辆未达到升级条件，使得车辆不能成功升级的问题，同时整体方案满足车辆功能安全的要求，保证了汽车全生命周期的安全性。

Description

一种车辆升级方法、装置、设备及存储介质

技术领域

本申请实施例涉及软件技术领域，涉及但不限于一种车辆升级方法、装置、设备及存储介质。

背景技术

近年来，以高阶自动驾驶技术和空中下载升级技术(OTA，Over-the-AirTechnology)为代表的新技术不断引入汽车领域，使得汽车变得更智能，极大的拓展了汽车的应用场景，给消费者带了更多更好的体验。但同时，也使得车辆的系统越来越复杂，汽车的安全性要求越来越高。

但是，相关技术中大多数OTA升级方法中仅考虑了电池余量和存储空间等影响OTA升级成功的因素，但对于高阶自动驾驶需要满足的功能安全要求而言，相关技术中的OTA升级方法不足以达到汽车功能安全(ASIL D，Automotive Safety Integration Level D)的要求。

发明内容

本申请实施例的目的在于提供一种车辆升级方法、装置、设备及存储介质，以解决相关技术中的OTA升级方法不足以达到汽车功能安全的问题。

为了实现上述目的，本申请实施例提供一种车辆升级方法，所述方法包括：

响应于车辆升级请求，对车辆的运行状态进行检测，得到检测结果；在所述检测结果表征所述运行状态满足升级条件的情况下，下载多个升级数据包至预设存储位置；对所述预设存储位置中的至少两个升级数据包进行数据一致性判断，得到判断结果；在所述判断结果表征所述至少两个升级数据包的数据一致的情况下，在所述至少两个升级数据包中确定目标升级数据包；基于所述目标升级数据包，对车辆的软件进行升级。

根据上述技术手段，在获取到升级请求之后，先对车辆的硬件运行状态进行检测，在运行状态满足升级条件的情况下，下载多个数据包，对数据包进行内容一致性校验，在检验通过后，进行车辆升级。如此，本申请实施例考虑了汽车软件升级过程中的多种失效场景，避免了因不同失效场景导致车辆未达到升级条件，使得车辆不能成功升级的问题，提高了车辆的软件升级成功率；同时，由于考虑了多种失效场景，使得本申请提供的车辆升级的整体方案满足车辆功能安全的要求，保证了汽车全生命周期的安全性。

在一些实施例中，所述方法还包括：在所述检测结果表征所述运行状态不满足升级条件的情况下，在所述车辆的多个硬件中，确定不满足升级条件的目标硬件和所述目标硬件对应的硬件状态；在所述硬件状态为第一状态的情况下，向所述车辆对应的终端发出提示信息；其中，所述第一状态为目标硬件不能自行恢复的状态，所述提示信息用于指示持有所述终端的用户对车辆进行状态恢复操作；响应于所述状态恢复操作，对所述目标硬件的运行状态进行恢复，直至所述目标硬件的运行状态满足所述升级条件。

在一些实施例中，所述方法还包括：在所述硬件状态为第二状态的情况下，按照预设周期，对所述目标硬件的运行状态进行检测，直至所述目标硬件的运行状态满足所述升级条件；其中，所述第二状态与所述第一状态不同，所述第二状态为目标硬件能够自行恢复的状态。

根据上述技术手段，在车辆的运行状态不满足升级条件的情况下，对不满足升级条件的硬件进行状态恢复，使得车辆的运行状态满足升级条件，提高车辆升级成功率。

在一些实施例中，所述方法还包括：在所述判断结果表征所述至少两个升级数据包的数据不一致的情况下，对所述预设存储位置中的多个升级数据包进行删除处理；在车辆的运行状态满足所述升级条件的情况下，再次下载多个升级数据包至预设存储位置；对所述多个升级数据包中的至少两个升级数据包进行数据一致性判断，在所述至少两个升级数据包的数据一致的情况下，在所述至少两个升级数据包中确定目标升级数据包。

根据上述技术手段，通过对需升级的软件对应的升级数据包进行独立区域的多份下载及存储，可以避免下载过程的下载异常及车端的随机硬件失效对升级的结果造成影响，保证了下载过程不会对当前车辆的功能及性能造成影响。

在一些实施例中，在确定目标升级数据包之后，所述方法还包括：向所述车辆对应的终端发送升级确认请求，所述升级确认请求用于请求持有所述终端的用户进行升级确认；对应地，所述基于所述目标升级数据包，对车辆的软件进行升级，包括：响应于升级确认操作，基于所述目标升级数据包，对车辆的软件进行升级。

根据上述技术手段，通过与用户之间的交互和用户实时的反馈，使得对车辆的升级处理满足用户需求，提升了用户体验度。

在一些实施例中，在对车辆软件进行升级之后，所述方法还包括：获取升级结果，所述升级结果至少包括升级内容；对所述升级内容与所述升级数据包对应的内容进行内容一致性检验，得到检验结果；对所述车辆的安全状态进行检测，得到安全检测结果；在所述检验结果表征所述升级内容与所述升级数据包对应的内容一致，且所述安全检测结果满足安全条件的情况下，对所述车辆的软件进行版本切换，以完成所述车辆升级。

根据上述技术手段，在对升级后的软件进行版本切换时，考虑了车辆的安全状态，提升了升级过程中车辆的安全性。

在一些实施例中，所述方法还包括：获取软件更新信息，所述软件更新信息至少包括软件版本号；对所述软件版本号与车辆当前软件的版本号进行对比，得到对比结果；在所述对比结果表征所述软件版本号大于当前软件的版本号的情况下，生成所述车辆升级请求。

根据上述技术手段，实时或周期性的获取软件更新信息，使得车端能够在车机厂发布软件新版本时，快速对车端的软件进行升级，使得软件的性能更好，得到优化的效果，用户也能有更好的体验。

本发明的有益效果：

(1)在车辆的运行状态不满足升级条件的情况下，对不满足升级条件的硬件进行状态恢复，直至车辆的运行状态满足升级条件后进行车辆升级，避免了因不同失效场景导致车辆未达到升级条件，使得车辆不能成功升级的问题，提高了车辆的软件升级成功率；

(2)考虑了车辆的当前运行状态不满足需求、随机硬件失效和下载异常等多种失效场景，使得本申请提供的车辆升级的整体方案满足车辆功能安全的要求，保证了汽车全生命周期的安全性；

(3)通过与用户之间的交互和用户实时的反馈进行车辆的升级，使得对车辆的升级处理满足用户需求，提升了用户体验度；在车辆升级之后的车辆软件版本切换中，考虑了车辆的安全状态，提升了升级过程中车辆的安全性。

附图说明

图1是本申请实施例提供的车辆升级系统的架构示意图；

图2是本申请实施例提供的一种车辆升级方法的一个可选的实现流程示意图；

图3是本申请实施例提供的一种车辆升级方法的一个可选的实现流程示意图；

图4是本申请实施例提供的一种车辆升级方法的一个可选的实现流程示意图；

图5是本申请实施例提供的一种车辆升级方法的一个可选的实现流程示意图；

图6是本申请实施例提供的OTA升级系统的结构示意图；

图7是本申请实例提供的一种车辆升级方法的一个可选的流程示意图；

图8是本申请实施例提供的一种车辆升级装置示意图；

图9是本申请实施例提供的一种车辆升级设备的硬件实体示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。除非另有定义，本申请实施例所使用的所有的技术和科学术语与属于本申请实施例的技术领域的技术人员通常理解的含义相同。本申请实施例所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

基于相关技术存在的问题，本申请实施例提供一种车辆升级方法，在获取到升级请求之后，先对车辆的硬件运行状态进行检测，在运行状态满足升级条件的情况下，下载多个数据包，对数据包进行内容一致性校验，在检验通过后，进行车辆升级。如此，本申请实施例考虑了汽车软件升级过程中的多种失效场景，避免了因不同失效场景导致车辆未达到升级条件，使得车辆不能成功升级的问题，提高了车辆的软件升级成功率；同时，由于考虑了多种失效场景，使得本申请提供的车辆升级的整体方案满足车辆功能安全的要求，保证了汽车全生命周期的安全性。

本申请实施例提供一种车辆升级系统，图1是本申请实施例提供的车辆升级系统的架构示意图，如图1所示，该系统包括存放新版本软件的云端101、通信模块102和升级模块103。其中，通信模块102可以是车辆的远程通信终端(T-BOX，Telematics BOX)，升级模块103可以是车辆中独立的物理服务器，也可以是车辆对应的云服务器，位于车载系统的中间层，介于上层应用和底层系统之间，用于对车辆的软硬件资源进行管理、分配和调度。升级模块103中可以包括升级处理单元1031和预设存储位置1032。

在一些实施例中，云端101用于主机厂上传需升级的软件，并通过T-BOX建立与需升级车端的联系。通信模块102置于车端，主要功能是建立车端与云端的联系。预设存储位置1032位于中间层，是平台性高安全等级模块，主要功能是当需OTA升级的软件下载到车端时，对需升级的软件进行独立区域的多份下载及存储，防止下载过程的异常及车端的随机硬件失效对OTA升级的结果造成影响，且保证下载过程不会对当前车辆的功能及性能造成影响。

在一些实施例中，本申请实施例的车辆升级方法可以由升级管理单元1031来执行，也可以由车辆中的车辆升级设备来执行，车辆升级设备可以是车辆中独立的电子设备。

下面，将说明执行主体实施为升级管理单元时的示例性应用，将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

图2是本申请实施例提供的一种车辆升级方法的实现流程示意图，如图2所示，该方法通过步骤S201至步骤S205实现：

S201、响应于车辆升级请求，对车辆的运行状态进行检测，得到检测结果。

在一些实施例中，车辆升级请求可以是通信模块(即T-BOX)发出的，T-BOX周期性或者实时的对云端是否发布了固件或软件的新版本。在检测到车机厂的云端发布了新版本之后，对新版本和车端的版本进行对比，如果新版本与车端的版本不同，且对车端版本的缺陷做出了改进，则确定车端的固件或软件版本需要升级，则发出车辆升级请求至升级管理单元。

在一些实施例中，车辆升级请求也可以是升级管理模块基于通信模块实现的，本申请实施例提供的车辆升级方法还包括以下步骤：

首先，获取软件更新信息，所述软件更新信息至少包括软件版本号。这里，升级管理模块可以是基于通信模块周期性或者实时的对云端是否发布了固件或软件的新版本，在检测到车机厂的云端发布了新版本之后，获取包括软件版本号的软件更新信息。

其次，对所述软件版本号与车辆当前软件的版本号进行对比，得到对比结果。这里，车辆当前软件的版本号是指车端当前正在使用的软件或固件的版本号。对比结果可以包括软件版本号与车辆当前软件的版本号相同，即云端的软件版本与车端当前的版本相同，无需进行更新升级；还可以是软件版本号大于车辆当前软件的版本号，即云端的软件版本是车端当前的版本的更新版本，需进行更新升级；还可以是软件版本号小于车辆当前软件的版本号，即云端的软件版本是车端当前的版本的旧版本，无需进行更新升级。

最后，在所述对比结果表征所述软件版本号大于当前软件的版本号的情况下，生成所述车辆升级请求。

在本申请实施例中，在升级管理模块确定升级之后，需要判断当前是否可以进行软件新版本的下载，判断条件是对车辆当前多个硬件的硬件运行状态进行检测，例如，对车端电源情况、车端通信资源情况、车端芯片算力情况和车端存储空间剩余情况等进行检测，得到检测结果，根据检测结果判断是否可以进行软件新版本下载。

在一些实施例中，检测结果可以包括车辆的硬件运行状态允许进行软件新版本下载，或者车辆中的硬件运行状态不允许进行软件新版本下载。

在一些实施例中，车辆中硬件的状态会影响车辆的升级，例如，车端的电源电量太低或者车端的存储空间不足，此时车辆无法进行软件新版本的下载，且车端的电源电量和存储空间不会随着时间变化而恢复，此时需要通知车辆的驾驶员进行充电补能或存储空间释放等操作，直至可以进行软件新版本的下载。

S202、在所述检测结果表征所述运行状态满足升级条件的情况下，下载多个升级数据包至预设存储位置。

在一些实施例中，在车辆的运行状态满足升级条件的情况下，下载多个相同的升级数据包至预设存储位置。这里，下载多个升级数据包的目的是为了避免下载过程中由于网络异常、车辆的随机硬件失效或其他异常导致的数据包出现错误，进而导致通过错误的数据包无法升级的问题。

S203、对所述预设存储位置中的至少两个升级数据包进行数据一致性判断，得到判断结果。

在一些实施例中，数据一致性判断是指在预设存储位置中的多个升级数据包中，任意选择至少两个升级数据包进行数据对比，判断至少两个升级数据包的数据是否相同，在相同的情况下，认定数据下载过程无异常，可以在至少两个升级数据包中确定用于升级的数据包。如果至少两个升级数据包的数据不同，则认为下载过程中出现异常，无法在预设存储位置中的多个升级数据包中确定未出错的升级数据包，因此，需要将预设存储位置中已下载的多个升级数据包删除，并在满足升级条件的基础上，重新下载升级数据包以进行车辆升级。

S204、在所述判断结果表征所述至少两个升级数据包的数据一致的情况下，在所述至少两个升级数据包中确定目标升级数据包。

在本申请实施例中，在至少两个升级数据包的数据一致的情况下，可以在至少两个升级数据包中选择任意一个升级数据包作为目标升级数据包，并基于目标升级数据包对车辆进行升级。

S205、基于所述目标升级数据包，对车辆的软件进行升级。

在一些实施例中，在确定目标升级数据包之后，还需要向车辆对应的终端发送升级确认请求，车辆对应的终端可以是车辆的显示终端，也可以是车辆驾驶员的手机终端，升级确认请求用于请求持有终端的用户进行升级确认，然后，基于该用户基于终端的升级确认操作，通过目标升级数据包，对车辆的软件进行升级。

在一些实施例中，升级确认操作可以包括但不限于基于终端的选中操作、确定操作、滚动操作等。升级确认操作可以是用户通过输入组件或终端在展示界面中输入/选择的指令。其中，输入组件或设备可以包括但不限于键盘、鼠标、触控屏、触控板或音频输入器等。本申请实施例对升级确认操作的实施方式不作限定。

本申请实施例考虑了汽车软件升级过程中的多种失效场景，避免了因不同失效场景导致车辆未达到升级条件，使得车辆不能成功升级的问题，提高了车辆的软件升级成功率；同时，由于考虑了多种失效场景，使得本申请提供的车辆升级的整体方案满足车辆功能安全的要求，保证了汽车全生命周期的安全性。

在一些实施例中，在对车辆的运行状态进行检测之后，在检测结果表征车辆的运行状态不满足升级条件的情况下，需要根据不满足升级条件的硬件情况，对硬件状态进行调整，直至硬件满足升级条件。如图3所示，图3是本申请实施例提供的一种车辆升级方法的实现流程示意图，基于前述实施例，本申请实施例提供的车辆升级方法还包括步骤S301至步骤S304：

S301、在所述检测结果表征所述运行状态不满足升级条件的情况下，在所述车辆的多个硬件中，确定不满足升级条件的目标硬件和所述目标硬件对应的硬件状态。

在一些实施例中，当车辆的运行状态不满足升级条件时，在车辆的多个硬件中确定运行状态不满住升级条件的目标硬件。这里车辆的多个硬件是指影响车辆升级的硬件，例如，电池、存储单元、通信单元或芯片等硬件，如果因为车辆的电池电量低于阈值，导致车辆的运行状态不满足升级条件，则电池为目标硬件，并确定电池的硬件状态，此时电池的硬件状态为缺电状态。

S302、在所述硬件状态为第一状态的情况下，向所述车辆对应的终端发出提示信息；其中，所述第一状态为目标硬件不能自行恢复的状态，所述提示信息用于指示持有所述终端的用户对车辆进行状态恢复操作。

在一些实施例中，第一状态为目标硬件不能自行恢复的状态，即目标硬件的硬件状态不能随时间恢复，例如低电量的电池在不进行充电的条件下，不会随时间自动恢复电量；或者存储单元的容量满了，在不进行清理的情况下，不会时间自动恢复容量。

在本申请实施例中，如果目标硬件的硬件状态为第一状态时，可以向车辆对应的终端发出提示信息，用于指示持有终端的用户对车辆进行状态恢复操作，该状态恢复操作用于对目标硬件的运行状态进行恢复，例如，对车辆进行充电或释放存储单元容量的操作。

S303、响应于所述状态恢复操作，对所述目标硬件的运行状态进行恢复，直至所述目标硬件的运行状态满足所述升级条件。

在本申请实施例中，在接收到用户进行的状态恢复操作(例如，充电操作)之后，对目标硬件的状态进行恢复，此时，可以周期性或实时检测目标硬件的状态，例如周期性或实时检测电池的电量，在电池电量满足升级条件之后，下载多个升级数据包至预设存储位置。

S304、在所述硬件状态为第二状态的情况下，按照预设周期，对所述目标硬件的运行状态进行检测，直至所述目标硬件的运行状态满足所述升级条件；其中，所述第二状态与所述第一状态不同，所述第二状态为目标硬件能够自行恢复的状态。

这里，步骤S304与步骤S302为并列方案。

在一些实施例中，第二状态与第一状态不同，第二状态为目标硬件能够自行恢复的状态，例如车端通信模块的通信资源情况和车端芯片算力情况，会随着时间自行恢复。如果不满足升级条件的目标硬件处于第二状态，则按照预设的时间周期对目标硬件的运行状态进行检测，例如一分钟检测一次芯片算力，在芯片算力满足升级条件之后，下载多个升级数据包至预设存储位置。

在一些实施例中，还可以实时监测处于第二状态的目标硬件的运行状态，以快速确定目标硬件满足升级条件。

本申请实施例在车辆的运行状态不满足升级条件的情况下，对不满足升级条件的硬件进行状态恢复，使得车辆的运行状态满足升级条件，提高车辆升级成功率。

在一些实施例中，在对预设存储位置中的至少两个升级数据包进行数据一致性判断时，当至少两个升级数据包的数据不一致性时，还需要重新下载升级数据包，再次进行判断，直至预设存储位置中的升级数据包的数据一致。如图4所示，图4是本申请实施例提供的一种车辆升级方法的实现流程示意图，本申请实施例提供的车辆升级方法还包括步骤S401至步骤S403：

S401、在所述判断结果表征所述至少两个升级数据包的数据不一致的情况下，对所述预设存储位置中的多个升级数据包进行删除处理。

在本申请实施例中，如果预设存储位置中的至少两个升级数据包的数据不一致，说明升级数据包下载时出现了下载异常或者出现了随机失效，此时，无法确定预设存储位置中的多个升级数据包是否全部出现异常，也无法确定多个升级数据包中未出现异常的升级数据包，因此，本申情实施例在至少两个升级数据包的数据不一致的情况下，对预设存储位置中的多个升级数据包进行删除处理。

S402、在车辆的运行状态满足所述升级条件的情况下，再次下载多个升级数据包至预设存储位置。

在本申请实施例中，再次下载升级数据包时，为了提高升级效率，需要再次检测车辆的运行状态，并在运行状态满足升级条件的情况下进行升级数据包的下载，避免下载时由于硬件运行状态不满足升级条件而导致下载失败的问题。

S403、对所述多个升级数据包中的至少两个升级数据包进行数据一致性判断，在所述至少两个升级数据包的数据一致的情况下，在所述至少两个升级数据包中确定目标升级数据包。

在本申请实施例中，再次下载了多个升级数据包之后，需要再次对多个升级数据包中的至少两个升级数据包进行数据一致性判断，如果依旧数据不一致，再次删除预设存储位置中的多个升级数据包，并在运行状态满足升级条件的情况下，再次下载多个升级数据包，直至多个升级数据包中的至少两个升级数据包的数据一致。在至少两个升级数据包的数据一致的情况下，在至少两个升级数据包中确定任一升级数据包为目标升级数据包。

本申请实施例通过对需升级的软件对应的升级数据包进行独立区域的多份下载及存储，可以避免下载过程的下载异常及车端的随机硬件失效对升级的结果造成影响，保证了下载过程不会对当前车辆的功能及性能造成影响。

在一些实施例中，在升级完成之后，需要对已升级的内容与下载的升级数据包的内容进行一致性判定，并确定车辆的安全状态，在安全状态下进行软件版本的切换，避免软件切换途中出现软件功能失灵，导致出现事故的问题，提高车辆升级的安全性。如图5所示，图5是本申请实施例提供的一种车辆升级方法的实现流程示意图，本申请实施例提供的车辆升级方法还包括步骤S501至步骤S504：

S501、获取升级结果，所述升级结果至少包括升级内容。

在一些实施例中，升级结果是指软件升级的结果，包括升级后的升级内容。

S502、对所述升级内容与所述升级数据包对应的内容进行内容一致性检验，得到检验结果。

在本申请实施例中，对升级内容与升级数据包中的数据进行内容一致性检验是为了避免升级过程中出现差错，导致未能成功升级的问题。这里，检验结果包括内容一致和内容不一致。

在一些实施例中，如果升级内容与升级数据包中的数据不一致，则需重新进行升级。

S503、在所述检验结果表征所述升级内容与所述升级数据包对应的内容一致的情况下，对所述车辆的安全状态进行检测，得到安全检测结果。

在一些实施例中，如果升级内容与升级数据包中的数据一致，则对车辆的安全状态进行检测，安全检测结果包括车辆当前是否处于安全状态。例如，车辆在行驶中，表示车辆处于非安全状态，车辆如果是非行驶状态，表示车辆处于安全状态。

S504、在所述安全检测结果满足安全条件的情况下，对所述车辆的软件进行版本切换，以完成所述车辆升级。

在本申请实施例中，车辆满足安全条件是指车辆处于安全状态，例如，车辆停在停车场中，此时，可以对已经升级的软件进行软件版本的切换，来安全的完成车辆的升级。这里，如果车辆在行驶过程中，对软件进行版本的升级可能会导致车辆的部分功能出错，进而发生安全事故，例如，在对导航软件进行升级时，如果在行驶过程中进行软件版本的切换，可能会使得车辆走错路；或者是对车辆的控制组件进行升级时，如果在行驶过程中进行软件版本的切换，可能会使得车辆在行驶中控制组件失灵，导致事故的发生。因此，本申请实施例在对升级后的软件进行版本切换时，考虑了车辆的安全状态，提升了升级过程中车辆的安全性。

本申请实施例再提供一种车辆升级方法在实际场景中的应用。

本申请实施例提供了一种满足功能安全要求的OTA升级方法及系统，其用于进行高阶智能驾驶系统相关的OTA升级时，保证整个OTA升级的结果能达到功能安全的要求。从而保证整车汽车生命周期内都满足功能安全要求。

为达到上述技术效果，本申请提供一种OTA升级系统，如图6所示，OTA升级系统包括存放新版本软件的云端601，对比云端和车端软件版本信息的T-BOX602(即通信模块)，执行升级和安全校验的升级单元603(即升级模块)。

其中，所述升级单元603，包括冗余存储模块6031(即预设存储位置)和升级管理模块6032(即升级处理单元)，置于中间层。所述云端601，主要功能是用于主机厂上传需升级的软件，并通过T-BOX建立与需升级车端的联系。T-BOX602，置于车端，主要功能是建立车端与云端的联系，并通过车端版本与云端版本的比对结果判定是否进行OTA升级。此外，T-BOX还负责在车端确认升级时将待升级软件下载至车端。

在一些实施例中，所述冗余存储模块，置于中间层，是平台性高安全等级模块，主要功能是当需OTA升级的软件通过T-BOX下载到车端时，对需升级的软件进行独立区域的多份下载及存储，防止下载过程的异常及车端的随机硬件失效对OTA升级的结果造成影响且保证下载过程不会对当前车辆的功能及性能造成影响。

所述升级管理模块，置于中间层，是平台性高安全等级模块，主要功能是：在收到T-BOX升级请求时，判断车端条件是否满足下载条件，考虑车端电源余量、车端通信资源、车端存储资源、车端芯片算力资源等；在下载完成后，判定是否具备升级条件，考虑下载内容的一致性校验，并在下载内容一致性校验未通过时，擦除下载内容，返回下载条件判断及重新下载；在升级完成后，进行升级结果的判断，主要是升级结果与冗余存储模块中下载内容的一致性校验及汽车当前状态校验，并在校验未通过时进行重新升级。

这里，T-BOX作为车端的通信端通过以太网实现与云端的交互，又通过网关将云端信息同步到汽车相应位置。其还表明冗余存储模块及升级管理模块位于中间层，使得本方案的可移植性和可拓展性得到保障，更有利于当前快节奏的产品推出方式。

本申请实施例充分考虑了OTA升级过程中的各类失效场景，通过沿用中间层高安全等级的平台性模块，例如，冗余存储模块和升级管理模块，不仅使得OTA升级的整体方案满足功能安全的要求，保证了汽车全生命周期功能安全要求的达成，更是使得整体的OTA升级方案具有了可移植性和可拓展性。

图7是本申请实例提供的车辆升级方法的一个可选的流程示意图，车辆升级方法的执行主体可以是上述OTA升级系统，如图7所示，车辆升级方法包括步骤S701至S711。

S701、主机厂在云端发布待升级的软件云端版本。

S702、T-BOX确定软件云端版本是否更新。

车端的T-BOX周期性的获取云端的软件信息，并与本地存储的信息进行比对，并确认本地的软件版本是否需要升级。若确认结果为需要升级，则T-BOX将升级请求(即车辆升级请求)同步升级管理模块。

在一些实施例中，T-BOX确定软件云端版本更新之后，执行步骤S703；如果没有更新，重复执行步骤S702。

S703、升级管理模块判断是否下载软件新版本。

升级管理模块在收到T-BOX的升级请求之后，进入周期性的进行下载条件判断，判断条件包括车端电源情况、车端通信资源情况、车端芯片算力情况和车端存储空间剩余情况等。

如果可以进行下载，执行步骤705；如果不能进行下载，执行步骤S704。

S704、判断不能进行下载的硬件是否可以自我恢复。

若判定不可进行升级的原因是车端电源情况、车端存储空间情况等自身无法恢复的情形，则通知驾驶员，并提示驾驶员进行补能、释放存储空间等操作；若判定为不可进行升级的原因是车端通信资源情况、车端芯片算力情况等随着时间、场景变化自身可恢复的情形，则返回步骤S703周期性的判断是否可进行下载,。

S705、基于T-BOX下载软件新版本，并独立分区保存。

若判定结果为可进行下载，则通知T-BOX进行下载并基于冗余存储模块进行独立区域的冗余存储。

S706、升级管理模块周期性的判断下载是否完成。

当判定结果为下载完成后，进入步骤S707。

步骤S707、判断是否可进行升级。

此处的是否可进行升级判断主要考虑下载内容一致性情况，当下载内容的一致性校验未通过时，升级管理模块则将已下载的内容擦除，并返回步骤S707进行是否可进行下载的条件判断。当下载内容的一致性校验结果为通过时，升级管理模块则将本次升级相关信息同步给驾驶员，并请求驾驶员确认升级。

步骤S708、获取驾驶员确认升级请求。

步骤S709、基于软件新版本对软件进行升级。

步骤S710、升级管理周期性判定升级结果。

驾驶员确认进行升级后，升级管理模块进行本次升级并在升级完成后周期性的进行升级结果的判定。此处的判定主要考虑已升级内容与下载内容的一致性判定及车辆状态判定。若是升级内容和下载内容的一致性判定未过，则返回步骤S709重新升级，并在升级内容和下载内容一致性判定通过后进行车辆状态判定。当车辆状态判定也通过时，执行步骤S711。

步骤S711、切换版本，同步驾驶员及T-BOX升级结果。

当车辆状态判定也通过时，升级管理则进行最后的版本切换和同步驾驶员、T-BOX升级结果操作。

综上，本申请实施例提供的OTA升级方法及系统充分考虑了OTA升级过程中的各种失效形式，并对应的给出了措施进行覆盖。保证了OTA升级过程中功能安全要求的达成，有效避免了OTA升级的异常对整车安全的影响，提升了全生命周期中整车的安全性。此外，本OTA升级方法及系统将主要部件置于中间层，大大提升了升级方法的可移植性和可拓展性，能很好的应对当前快节奏的市场趋势。

基于上述实施例，本申请实施例提供一种车辆升级装置，图8是本申请实施例提供的一种车辆升级装置示意图，如图8所示，所述装置80包括检测模块801、下载模块802、判断模块803、确定模块804和升级模块805。

其中，检测模块801，用于响应于车辆升级请求，对车辆的运行状态进行检测，得到检测结果；下载模块802，用于在所述检测结果表征所述运行状态满足升级条件的情况下，下载多个升级数据包至预设存储位置；判断模块803，用于对所述预设存储位置中的至少两个升级数据包进行数据一致性判断，得到判断结果；确定模块804，用于在所述判断结果表征所述至少两个升级数据包的数据一致的情况下，在所述至少两个升级数据包中确定目标升级数据包；升级模块805，用于基于所述目标升级数据包，对车辆的软件进行升级。

在一些实施例中，所述装置还包括：第一确定模块，用于在所述检测结果表征所述运行状态不满足升级条件的情况下，在所述车辆的多个硬件中，确定不满足升级条件的目标硬件和所述目标硬件对应的硬件状态；发出模块，用于在所述硬件状态为第一状态的情况下，向所述车辆对应的终端发出提示信息；其中，所述第一状态为目标硬件不能自行恢复的状态，所述提示信息用于指示持有所述终端的用户对车辆进行状态恢复操作；恢复模块，用于响应于所述状态恢复操作，对所述目标硬件的运行状态进行恢复，直至所述目标硬件的运行状态满足所述升级条件。

在一些实施例中，所述装置还包括：第一检测模块，用于在所述硬件状态为第二状态的情况下，按照预设周期，对所述目标硬件的运行状态进行检测，直至所述目标硬件的运行状态满足所述升级条件；其中，所述第二状态与所述第一状态不同，所述第二状态为目标硬件能够自行恢复的状态。

在一些实施例中，所述装置还包括：删除模块，用于在所述判断结果表征所述至少两个升级数据包的数据不一致的情况下，对所述预设存储位置中的多个升级数据包进行删除处理；第一下载模块，用于在车辆的运行状态满足所述升级条件的情况下，再次下载多个升级数据包至预设存储位置；一致性判断模块，用于对所述多个升级数据包中的至少两个升级数据包进行数据一致性判断，在所述至少两个升级数据包的数据一致的情况下，在所述至少两个升级数据包中确定目标升级数据包。

在一些实施例中，在确定目标升级数据包之后，所述装置还包括：发送模块，用于向所述车辆对应的终端发送升级确认请求，所述升级确认请求用于请求持有所述终端的用户进行升级确认；对应地，升级模块805，还用于响应于升级确认操作，基于所述目标升级数据包，对车辆的软件进行升级。

在一些实施例中，在对车辆软件进行升级之后，所述装置还包括：第一获取模块，用于获取升级结果，所述升级结果至少包括升级内容；检验模块，用于对所述升级内容与所述升级数据包对应的内容进行内容一致性检验，得到检验结果；第二检测模块，用于在所述检验结果表征所述升级内容与所述升级数据包对应的内容一致的情况下，对所述车辆的安全状态进行检测，得到安全检测结果；切换模块，用于在所述安全检测结果满足安全条件的情况下，对所述车辆的软件进行版本切换，以完成所述车辆升级。

在一些实施例中，所述方法还包括：第二获取模块，用于获取软件更新信息，所述软件更新信息至少包括软件版本号；对比模块，用于对所述软件版本号与车辆当前软件的版本号进行对比，得到对比结果；生成模块，用于在所述对比结果表征所述软件版本号大于当前软件的版本号的情况下，生成所述车辆升级请求。

需要说明的是，本申请实施例装置的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果，因此不做赘述。对于本装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述车辆升级方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一台少样本模型学习设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read OnlyMemory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。

本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括可执行指令，该可执行指令是一种计算机指令；该可执行指令存储在计算机可读存储介质中。当终端接入管理设备的处理器从计算机可读存储介质读取该可执行指令，处理器执行该可执行指令时，使得该终端接入管理设备执行本申请实施例上述的方法。

本申请实施例提供一种存储有可执行指令的存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法，例如，如图2示出的方法。

在一些实施例中，存储介质可以是计算机可读存储介质，例如，铁电存储器(FRAM，Ferromagnetic Random Access Memory)、只读存储器(ROM，Read Only Memory)、可编程只读存储器(PROM，Programmable Read Only Memory)、可擦除可编程只读存储器(EPROM，Erasable Programmable Read Only Memory)、带电可擦可编程只读存储器(EEPROM，Electrically Erasable Programmable Read Only Memory)、闪存、磁表面存储器、光盘、或光盘只读存储器(CD-ROM，Compact Disk-Read Only Memory)等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，Hyper TextMarkup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。作为示例，可执行指令可被部署为在一个电子设备上执行，或者在位于一个地点的多个电子设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个电子设备上执行。

需要说明的是，图9是本申请实施例提供的一种车辆升级设备的硬件实体示意图，如图9所示，该车辆升级设备90的硬件实体包括：处理器901、通信接口902和存储器903，其中：

处理器901通常控制车辆升级设备90的总体操作。

通信接口902可以使车辆升级设备通过网络与其他终端或服务器通信。

存储器903配置为存储由处理器901可执行的指令和应用，还可以缓存待处理器901以及车辆升级设备90中各模块待处理或已经处理的数据(例如，图像数据、音频数据、语音通信数据和视频通信数据)，可以通过闪存(FLASH)或随机访问存储器(Random AccessMemory，RAM)实现。处理器901、通信接口902和存储器903之间可以通过总线904进行数据传输。

这里需要指出的是：以上存储介质和设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质和设备实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本申请实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (10)

1.一种车辆升级方法，其特征在于，所述方法包括：

响应于车辆升级请求，对车辆的运行状态进行检测，得到检测结果；

在所述检测结果表征所述运行状态满足升级条件的情况下，下载多个升级数据包至预设存储位置；

对所述预设存储位置中的至少两个升级数据包进行数据一致性判断，得到判断结果；

在所述判断结果表征所述至少两个升级数据包的数据一致的情况下，在所述至少两个升级数据包中确定目标升级数据包；

基于所述目标升级数据包，对车辆的软件进行升级。

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

在所述检测结果表征所述运行状态不满足升级条件的情况下，在所述车辆的多个硬件中，确定不满足升级条件的目标硬件和所述目标硬件对应的硬件状态；

在所述硬件状态为第一状态的情况下，向所述车辆对应的终端发出提示信息；其中，所述第一状态为目标硬件不能自行恢复的状态，所述提示信息用于指示持有所述终端的用户对车辆进行状态恢复操作；

响应于所述状态恢复操作，对所述目标硬件的运行状态进行恢复，直至所述目标硬件的运行状态满足所述升级条件。

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

在所述硬件状态为第二状态的情况下，按照预设周期，对所述目标硬件的运行状态进行检测，直至所述目标硬件的运行状态满足所述升级条件；其中，所述第二状态与所述第一状态不同，所述第二状态为目标硬件能够自行恢复的状态。

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

在所述判断结果表征所述至少两个升级数据包的数据不一致的情况下，对所述预设存储位置中的多个升级数据包进行删除处理；

在车辆的运行状态满足所述升级条件的情况下，再次下载多个升级数据包至预设存储位置；

对所述多个升级数据包中的至少两个升级数据包进行数据一致性判断，在所述至少两个升级数据包的数据一致的情况下，在所述至少两个升级数据包中确定目标升级数据包。

5.根据权利要求1至4任一项所述的方法，其特征在于，在确定目标升级数据包之后，所述方法还包括：

向所述车辆对应的终端发送升级确认请求，所述升级确认请求用于请求持有所述终端的用户进行升级确认；

对应地，所述基于所述目标升级数据包，对车辆的软件进行升级，包括：

响应于升级确认操作，基于所述目标升级数据包，对车辆的软件进行升级。

6.根据权利要求1至4任一项所述的方法，其特征在于，在对车辆软件进行升级之后，所述方法还包括：

获取升级结果，所述升级结果至少包括升级内容；

对所述升级内容与所述升级数据包对应的内容进行内容一致性检验，得到检验结果；

在所述检验结果表征所述升级内容与所述升级数据包对应的内容一致的情况下，对所述车辆的安全状态进行检测，得到安全检测结果；

在所述安全检测结果满足安全条件的情况下，对所述车辆的软件进行版本切换，以完成所述车辆升级。

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

获取软件更新信息，所述软件更新信息至少包括软件版本号；

对所述软件版本号与车辆当前软件的版本号进行对比，得到对比结果；

在所述对比结果表征所述软件版本号大于当前软件的版本号的情况下，生成所述车辆升级请求。

8.一种车辆升级装置，其特征在于，所述装置包括：

检测模块，用于响应于车辆升级请求，对车辆的运行状态进行检测，得到检测结果；

下载模块，用于在所述检测结果表征所述运行状态满足升级条件的情况下，下载多个升级数据包至预设存储位置；

判断模块，用于对所述预设存储位置中的至少两个升级数据包进行数据一致性判断，得到判断结果；

确定模块，用于在所述判断结果表征所述至少两个升级数据包的数据一致的情况下，在所述至少两个升级数据包中确定目标升级数据包；

升级模块，用于基于所述目标升级数据包，对车辆的软件进行升级。

9.一种车辆升级设备，其特征在于，所述设备包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现权利要求1至7任一项所述的车辆升级方法。

10.一种计算机可读存储介质，其上存储有可执行指令，用于引起处理器执行所述可执行指令时，实现权利要求1至7任一项所述的车辆升级方法。