基于空中下载技术OTA的通信方法和装置

摘要

本申请实施例提供一种基于空中下载技术OTA的通信方法和装置，涉及通信技术领域，包括：获得第一信息和第二信息；第一信息包括第一软件版本信息和/或第一标识码；第二信息包括第一映射；第一映射包含第二软件版本信息和第二标识码的关联关系；标识码用于指示软件版本的权限信息；根据第一信息和第二信息，验证第一软件版本信息与第一映射对应的第二软件版本信息的一致性。这样，可以实现在OTA的维护以及安装软件的过程中，保证汽车软件的正常升级，进而维护车辆的安全性。

说明书

技术领域

本申请涉及通信技术领域，尤其涉及一种基于空中下载技术OTA的通信方法和装置。

背景技术

随着自动驾驶的发展，人们对于汽车的计算和控制能力要求越来越高。越来越多的功能以软件的形式提供给用户，因此软件定义汽车正在成为汽车发展的重要趋势。当汽车中的软件需要安装或更新时，可以利用空中下载技术(over the air technology，OTA)，借助OTA联网到云端安装或更新汽车中的软件。

然而OTA给人们带来便利的同时，也给汽车的准入带来了挑战。其中，准入可以理解为在汽车上市前，经历的一系列安全或排放等的相关测试，以满足相关标准的要求的过程。具体的，利用OTA更新汽车软件，可能会使得上市之后的汽车的准入参数发生改变。例如，通过OTA升级汽车的电池管理软件后，可能会使得汽车的续航里程提高，使其与准入时测量的续航里程不一致，进而可能出现汽车准入时测试的数据无效，需要重新测试的情况。因此，通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，对OTA的发展带来了一定的挑战。

发明内容

本申请实施例提供一种基于空中下载技术OTA的通信方法和装置，可以实现在OTA的维护以及安装软件的过程中，保证汽车软件的正常升级，进而维护车辆的安全性。

第一方面，本申请实施例提供一种基于OTA的通信方法，包括：获得第一信息和第二信息；第一信息包括第一软件版本信息和/或第一标识码；第二信息包括第一映射；第一映射包含第二软件版本信息和第二标识码的关联关系；标识码用于指示软件版本的权限信息；根据第一信息和第二信息，验证第一软件版本信息与第一映射对应的第二软件版本信息的一致性。

这样，可以利用第一信息和第二信息中的标识码与软件版本的匹配关系，验证第一信息与第二信息的一致性，实现在OTA的维护以及安装软件的过程中，通过维护车端和/或服务器(或称云端或云端设备)中，软件版本与标识码的一致性，进而保证汽车软件的正常升级，维护车辆的安全性。

结合第一方面，在一种可能的实现方式中，根据第一信息和第二信息，验证第一软件版本信息与第一映射对应的第二软件版本信息的一致性，包括：在第一软件版本信息与第二软件版本信息不一致，和/或，第一标识码与第二标识码不一致的情况下，确定第一软件版本信息与第二软件版本信息不一致；或者，在第一软件版本信息与第二软件版本信息一致，和/或，第一标识码与第二标识码一致的情况下，确定第一软件版本信息与第二软件版本信息一致。

这样，可以利用云端或车端验证第一软件版本信息与第二软件版本信息的一致性，进而可以通过维护车端和/或云端中，软件版本与标识码的一致性，防止软件版本和/或标识码被篡改，保证通过OTA升级的汽车软件正常升级。

结合第一方面，在一种可能的实现方式中，方法还包括：在第一软件版本信息与第二软件版本信息不一致的情况下，更新第一软件版本信息和/或第一标识码；或者，在第一软件版本信息与第二软件版本信息一致的情况下，更新第一软件版本信息和/或第一标识码。

这样，云端和车端可以基于标识码与软件版本的匹配关系，维护车端的软件版本信息和/或标识码，与云端设备的映射关系的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。

结合第一方面，在一种可能的实现方式中，在更新第一软件版本和/或第一标识码之前，方法还包括：向第一车辆发送第一任务；第一任务用于指示更新第一软件版本信息和/或第一标识码；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一任务包括第一映射；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一任务包括第二映射；第二映射包含第三软件版本信息和第三标识码的关联关系；第三软件版本信息不同于第二软件版本信息，和/或，第三标识码不同于第二标识码。

这样，可以在OTA升级软件的过程中保证软件版本信息和标识码的匹配关系，进而基于车端和/或云端中，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。

结合第一方面，在一种可能的实现方式中，方法还包括：向第一车辆发送第一软件包；第一软件包用于更新第一车辆对应的软件版本信息；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一软件包包括第二标识码；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一软件包包括第三标识码。

这样，可以在OTA升级软件的过程中保证软件版本信息和标识码的匹配关系，进而基于车端和/或云端中，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。

结合第一方面，在一种可能的实现方式中，还包括：在第一软件版本信息与第二软件版本信息不一致的情况下，向服务器和/或第一车辆的显示设备发送第一软件版本信息、第一标识码和/或告警信息；告警信息用于指示第一车辆的标识码和/或软件版本信息与服务器的映射关系不一致。

这样，可以使得云端设备和/或第一车辆的显示设备可以基于车端发送的告警信息进行及时处理，进一步保障汽车软件的正常升级。

结合第一方面，在一种可能的实现方式中，更新第一软件版本信息和/或第一标识码，包括：接收来自服务器的第一任务，第一任务用于指示更新第一软件版本信息和/或第一标识码；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一任务包括第一映射；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一任务包括第二映射；第二映射包含第三软件版本信息和第三标识码的关联关系；第三软件版本信息不同于第二软件版本信息，和/或，第三标识码不同于第二标识码。

这样，可以在OTA升级软件的过程中保证软件版本信息和标识码的匹配关系，进而基于车端和/或云端中，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。

结合第一方面，在一种可能的实现方式中，还包括：接收来自服务器的第一软件包；第一软件包用于更新第一车辆对应的软件版本信息；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一软件包包括第二标识码；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一软件包包括第三标识码。

这样，可以在OTA升级软件的过程中保证软件版本信息和标识码的匹配关系，进而基于车端和/或云端中，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。

结合第一方面，在一种可能的实现方式中，第一车辆中包括多个与第一软件包相关的电子控制单元，根据第一软件包更新第一车辆中的软件，包括：向N个电子控制单元发送各电子控制单元对应的第一软件包；N为正整数；接收来自N个电子控制单元的N个软件安装结果；在N个软件安装结果为任意一个或多个安装失败的情况下，回滚第一车辆的整车软件版本和标识码。

这样，可以在OTA升级软件的过程中保证软件版本信息和标识码的匹配关系，进而基于车端和/或云端中，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。

结合第一方面，在一种可能的实现方式中，接收来自第一车辆的告警信息；显示告警信息。

结合第一方面，在一种可能的实现方式中，标识码包括第一法规相关软件识别码RXSWIN。这样，可以利用RXSWIN与软件版本的匹配关系，在OTA的维护以及安装软件的过程中，保证RXSWIN与软件版本的一致性，保证汽车软件的正常升级。

这样，可以将系统内部用于指示软件版本信息与标识码不一致的告警信息，通过用户界面直观的显示给用户，方便用户及时进行后续处理，进一步保障汽车软件的正常升级。

第二方面，本申请实施例提供一种基于OTA的通信装置，通信单元，用于获得第一信息和第二信息；第一信息包括第一软件版本信息和/或第一标识码；第二信息包括第一映射；第一映射包含第二软件版本信息和第二标识码的关联关系；标识码用于指示软件版本的权限信息；处理单元，还用于根据第一信息和第二信息，验证第一软件版本信息与第一映射对应的第二软件版本信息的一致性。

结合第二方面，在一种可能的实现方式中，处理单元，具体用于：在第一软件版本信息与第二软件版本信息不一致，和/或，第一标识码与第二标识码不一致的情况下，确定第一软件版本信息与第二软件版本信息不一致；或者，在第一软件版本信息与第二软件版本信息一致，和/或，第一标识码与第二标识码一致的情况下，确定第一软件版本信息与第二软件版本信息一致。

结合第二方面，在一种可能的实现方式中，处理单元，还用于：在第一软件版本信息与第二软件版本信息不一致的情况下，更新第一软件版本信息和/或第一标识码；或者，在第一软件版本信息与第二软件版本信息一致的情况下，更新第一软件版本信息和/或第一标识码。

结合第二方面，在一种可能的实现方式中，通信单元，具体用于：向第一车辆发送第一任务；第一任务用于指示更新第一软件版本信息和/或第一标识码；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一任务包括第一映射；在第一软件版本信息与第二软件版本信息一致的情况下，第一任务包括第二映射；第二映射包含第三软件版本信息和第三标识码的关联关系；第三软件版本信息不同于第二软件版本信息，和/或，第三标识码不同于第二标识码。

结合第二方面，在一种可能的实现方式中，通信单元，还用于：向第一车辆发送第一软件包；第一软件包用于更新第一车辆对应的软件版本信息；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一软件包包括第二标识码；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一软件包包括第三标识码。

结合第二方面，在一种可能的实现方式中，通信单元，还用于：在第一软件版本信息与第二软件版本信息不一致的情况下，向服务器和/或第一车辆的显示设备发送第一软件版本信息、第一标识码和/或告警信息；告警信息用于指示车辆的标识码和/或软件版本信息与服务器的映射关系不一致。

结合第二方面，在一种可能的实现方式中，通信单元，具体用于：接收来自服务器的第一任务，第一任务用于指示更新第一软件版本信息和/或第一标识码；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一任务包括第一映射；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一任务包括第二映射；第三软件版本信息不同于第二软件版本信息，和/或，第三标识码不同于第二标识码。

结合第二方面，在一种可能的实现方式中，通信单元，还用于：接收来自服务器的第一软件包；第一软件包用于更新第一车辆对应的软件版本信息；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一软件包包括第二标识码；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一软件包包括第三标识码。

结合第二方面，在一种可能的实现方式中，通信单元，具体用于向N个电子控制单元发送各电子控制单元对应的第一软件包；N为正整数；通信单元，具体用于接收来自N个电子控制单元的N个软件安装结果；处理单元，具体用于在N个软件安装结果为任意一个或多个安装失败的情况下，回滚第一车辆的整车软件版本和标识码。

可能的实现方式中，通信单元，具体用于接收来自第一车辆的告警信息；显示单元，具体用于显示告警信息。

结合第二方面，在一种可能的实现方式中，标识码包括第一法规相关软件识别码RXSWIN。

第三方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序或指令，当计算机程序或指令在计算机上运行时，使得计算机执行如第一方面以及第一方面中的任意一种可能的实现方式中描述的基于OTA的通信方法。

第四方面，本申请实施例提供一种基于OTA的通信装置，该装置包括处理器和存储器，存储器存储有指令，指令被处理器运行时，实现如第一方面以及第一方面中的任意一种可能的实现方式描述的基于OTA的通信方法。

第五方面，本申请提供一种芯片或者芯片系统，该芯片或者芯片系统包括至少一个处理器和通信接口，通信接口和至少一个处理器通过线路互联，至少一个处理器用于运行计算机程序或指令，以实现第一方面以及第一方面的任意一种可能的实现方式中任一项所描述的基于OTA的通信方法。其中，芯片中的通信接口可以为输入/输出接口、管脚或电路等。

在一种可能的实现中，本申请中上述描述的芯片或者芯片系统还包括至少一个存储器，该至少一个存储器中存储有指令。该存储器可以为芯片内部的存储单元，例如，寄存器、缓存等，也可以是该芯片的存储单元(例如，只读存储器、随机存取存储器等)。

第六方面，本申请实施例提供一种计算机程序产品，当所述计算机程序产品在一个或多个处理器上运行时，实现第一方面以及第一方面中任意一种可能的实施方式所描述的方法。

应当理解的是，本申请的第二方面至第六方面与本申请的第一方面的技术方案相对应，各方面及对应的可行实施方式所取得的有益效果相似，不再赘述。

附图说明

图1为本申请实施例提供的一种RXSWIN与软件版本对应关系示意图；

图2为本申请实施例提供的第一种应用场景示意图；

图3为本申请实施例提供的一种车辆中软件更新的系统架构的示意图；

图4为本申请实施例提供的第二种应用场景示意图；

图5为本申请实施例提供的第三种应用场景示意图；

图6为本申请实施例提供的一种基于OTA的通信方法的流程示意图；

图7为本申请实施例提供的一种云端维护标识码与软件版本信息一致性的流程示意图；

图8为本申请实施例提供的一种车端维护标识码与软件版本信息一致性的流程示意图；

图9为本申请实施例提供的一种显示告警信息的界面示意图

图10为本申请实施例提供的一种云端进行一致性判断的流程示意图；

图11为本申请实施例提供的一种更新软件的流程示意图；

图12为本申请实施例提供的一种云端向车端下发软件包的流程示意图；

图13为本申请实施例提供的一种车端安装软件包的流程示意图；

图14为本申请实施例提供的另一种车端安装软件包的流程示意图；

图15为本申请实施例提供的一种基于OTA的通信装置的结构示意图；

图16为本申请实施例提供的一种控制设备的硬件结构示意图；

图17为本申请实施例提供的一种芯片的结构示意图。

具体实施方式

为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。例如，第一标识码和第二标识码是为了区分不同的标识码，并不对其先后顺序进行限定。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。

需要说明的是，本申请中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a和b，a和c，b和c，或a、b和c，其中a，b，c可以是单个，也可以是多个。

随着自动驾驶的发展，人们对汽车的计算和控制能力要求越来越高。越来越多的汽车功能通过软件的形式提供给用户，因此软件定义汽车正在成为汽车发展的重要趋势。软件定义汽车，要求汽车能够像计算机或智能手机一样，便捷的实现软件的安装和更新，使汽车的各种功能可以常用常新。通常情况下，当汽车软件需要更新时，用户可以将汽车开到4S店或维修网点，由专业技术人员通过专用设备去刷新车内的软件，进而实现汽车软件的更新。汽车OTA提供了一种远程升级汽车软件或修复汽车软件缺陷的技术手段，用户可以借助OTA技术联网到云端下载和安装软件，OTA可以减轻目前汽车软件升级对于时间和空间的限制，因此OTA在汽车领域得到了广泛的应用。

然而OTA给人们带来便利的同时，也给汽车准入带来了挑战。其中，准入可以理解为在汽车上市前，经历的一系列安全或排放等的相关测试，以满足相关标准的要求的过程。具体的，由于汽车的缺陷可能导致重大的人身和财产损失，因此汽车是一种特殊产品。在汽车上市前，需要经历准入测试，当通过准入，汽车才可以允许进入市场。当汽车产品申请并通过准入后，作为汽车的准入监管机构可以进行记录，并向社会公告该汽车的准入信息。公告后的车可以允许销售。其中，该公告中可以包括汽车轮距、重量或排量等基本信息，还可以包括如续航里程或最高车速等技术特征参数信息。

为了保证汽车在准入后的生产一致性，监管部门可以定期抽查汽车产品的相关参数，并与公告信息进行比对，如果该公告信息与准入的参数不一致，则违反了生产一致性，可以要求汽车厂家整改或要求汽车厂家执行停产等措施。

在汽车上市后，可以通过OTA更新汽车软件，然而更新过程可能改变该软件准入时的测试参数。例如，通过OTA升级汽车的电池管理软件后，可能会使得汽车的续航里程提高，使其与准入时测量的续航里程不一致，进而出现汽车准入时测试的数据无效，需要重新测试的情况。因此，通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，对OTA的发展带来了一定的挑战。基于此，联合国欧洲经济委员会(the united nations economiccommission for europe，UNECE)下属的联合国世界车辆法规协调论坛建立了OTA工作组，研讨将OTA纳入到准入监管体系。其中提到汽车的OTA可能影响准入一致性的，需要在OTA升级前向准入监管机构申请准入变更。为了监管这种变更，提出法规相关软件识别码(rxsoftware identification number，RXSWIN)。该RXSWIN可以记录软件版本与准入的关系，其作用是以准入法规的角度记录和追溯对准入有影响的软件和软件升级，便于准入监管机构管理汽车软件升级。其中，RXSWIN的变更可以表示软件升级引起的准入的变更。

示例性的，图1为本申请实施例提供的一种RXSWIN与软件版本对应关系示意图。如图1中的a所示，准入时可以配置初始RXSWIN及其对应的软件版本，如初始RXSWIN为R79110。其中，R79 110对应的软件版本可以包括：助力转向电子控制单元(electroniccontrol unit，ECU)对应的软件版本为v1.0；车身稳定ECU对应的软件版本为v2.0；整车控制ECU对应的软件版本为v1.0。

当借助OTA进行软件升级后，可以升级为如图1中的b所示的，升级后的RXSWIN与软件版本的对应关系示意图。其中，由于此时经过OTA后的软件，没有对准入时该软件对应的测试数据进行改变，因此发生不影响准入的软件升级后，RXSWIN关联的软件版本信息可以变更，但RXSWIN保持不变。此时，R79 110对应的软件版本可以包括：助力转向ECU对应的软件版本为v1.1；车身稳定ECU对应的软件版本为v2.2；整车控制ECU对应的软件版本为v1.0。

当进一步借助OTA进行软件升级后，可以升级为如图1中的c所示的，影响准入的软件升级后的RXSWIN与软件版本的匹配关系示意图。其中，发生影响准入的软件升级后，RXSWIN关联的软件版本信息变更，且RXSWIN变更。例如，RXSWIN由R79 110变更为R79 111。此时，R79 111对应的软件版本可以包括：助力转向ECU对应的软件版本为v2.0；车身稳定ECU对应的软件版本为v2.2；整车控制ECU对应的软件版本为v1.0。其中，OTA升级使得助力转向ECU对应的软件版本由原来的v1.1升级为v2.0，助力转向ECU的升级导致准入时该软件对应的测试参数的改变，故RXSWIN由R79 110变更为R79 111，该RXSWIN用以标识OTA升级影响了准入时参数。

也就是说，如图1所示，RXSWIN可以应用在基于OTA的软件升级时，用于表示与软件版本的对应关系。然而，在OTA的维护以及安装软件的过程中，无法保证车端与云端的RXSWIN与软件版本的一致性，也就无法很好的解决通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，进而难以维护汽车软件的安全升级。如何管理RXSWIN，以及如何维护车端和/或云端的RXSWIN与软件版本的一致性，目前还缺少合适的方法。

有鉴于此，本申请实施例提供一种基于OTA的通信方法和装置，可以在OTA的维护以及软件安装的过程中，获取第一信息和第二信息，利用第一信息和第二信息中的标识码与软件版本的匹配关系，基于标识码与软件版本的匹配关系验证第一信息与第二信息的一致性，进而可以通过维护车端和/或云端中，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。

可选的，该标识码可以为RXSWIN。

为了更好的理解本申请实施例的方法，下面首先对本申请实施例适用的应用场景进行描述。

可能的实现方式中，本申请实施例提供的一种基于OTA的通信方法，可以应用于各类型车辆OTA的维护及升级的场景中，例如通过车端与云端设备的数据交互，维护标识码与软件版本的一致性，或者下载或更新车辆中的软件等的场景中。其中，该车端和/或云端设备的数量均可以为一个或多个。

车端(或称车辆或车端设备)可以是进行软件升级的任意形式的车辆，或任意形式的车辆辅助设备(例如车辆充电桩等)等，本申请实施例对此不作具体限定。

云端(或称云端设备或服务器)可以是用于下发整车升级包的OTA服务器，也可以是代理服务器，例如代理服务器可以是为车队服务的服务器等。在该云端设备为代理服务器时，代理服务器可以先与OTA服务器之间通过双向认证，建立安全通信，之后，代理服务器将车辆的硬件和软件信息发送给OTA服务器，OTA服务器生成整车升级包后，可以将整车升级包下发给代理服务器，可以理解的，OTA服务器也可以将整车升级包分块后，下发给多个代理服务器。

云端也可以是用于更新软件的软件客户端服务器，也可以是已从软件客户端服务器中获取并更新软件的车队服务器或其他任意可能的服务器。

云端还可以是任意形式的车辆、任意形式的车辆辅助设备(例如车辆充电桩等)或移动终端(例如手机、平板、可穿戴设备等)，本申请实施例对此不作具体限定。

上述车辆和云端设备可以建立通信连接，例如车辆和云端设备可以通过超文本传输协议(hyper text tansfer protocol，HTTP)或基于安全套接字层的超文本传输协议(hyper text transfer trotocol over secure socket layer，HTTPS)等协议建立通信连接，本申请实施例中对此不做任何限制。

图2为本申请实施例提供的第一种示例性应用场景示意图。如图2所示，该场景中可以包括车辆201和软件OTA云设备202。车辆201为安装有软件OTA客户端的任意形式的车辆。软件OTA云设备202为提供OTA升级的服务器，用于存储软件包，以及存储标识码(例如RXSWIN)和软件版本的映射关系等。当对车辆201中的软件进行更新时，软件OTA云设备202可以获取车辆201中的软件OTA客户端上各软件的软件版本信息和/或标识码，并与自身存储的标识码和软件版本的映射关系进行比对，当汽车201中的各软件的软件版本信息和/或标识码与该映射关系一致时，可以自动发送或根据软件OTA客户端的请求命令发送软件包，至车辆201中的软件OTA客户端中，其中该软件包中包含标识码。车辆201中的软件OTA客户端可以根据来自软件OTA云设备的软件包，更新软件以及标识码。

车辆201和软件OTA云设备202的数量均可以为一个或多个，本申请实施例对此不作具体限定。

可能的实现方式中，该软件OTA云设备也可以为车厂OTA云设备。此时，车厂OTA云设备可以为用于下发整车升级包的OTA服务器。

下面对上述软件OTA云设备以及车厂OTA云设备在车辆中的实现过程进行说明。示例性的，图3为本申请实施例提供的一种车辆中软件更新的系统架构的示意图。如图3所示，该系统中可以包括：车厂OTA云设备301、软件OTA云设备302、主控OTA客户端303和软件OTA客户端304。

其中，车厂OTA云设备301可以是车辆厂商或车辆中软件服务商的服务器，用于管理车辆中软件和存储软件数据。车辆中软件可以包括车身控制软件等。软件OTA云设备302可以是用于存储软件包，以及存储标识码和软件版本的映射关系等。车厂OTA云设备301可以与软件OTA云设备302进行交互。车厂OTA云设备301的软件信息来自软件OTA云设备302，或者车厂OTA云设备301也可以自行确定软件信息。

需要说明的是，车辆中OTA升级可以包括主控节点和从属节点两级。如图3所示，主控OTA客户端303与主控节点相对应，可以接收整车升级包，并拆分分发给其控制的多个从属客户端。软件OTA客户端304与从属节点相对应，可以是主控OTA客户端303下的从属OTA客户端。软件OTA客户端304可以作为整车OTA升级的一部分进行软件更新。

因此，该系统架构中有两种可能的软件更新方式。一种可能的实现方式是软件OTA云设备302与软件OTA客户端304交互，对软件进行更新。具体实现过程与图1所示的应用场景的描述一致，此处不再赘述。

另一种可能的实现方式是车厂OTA云设备301、主控OTA客户端303和软件OTA客户端304交互，对软件进行更新。示例性的，车厂OTA云设备301可以基于自身存储的标识码与软件版本的映射关系，以及从主控OTA客户端303(或软件OTA客户端304)获取的软件版本和/或标识码的一致性，将需要更新的软件包通过整车升级包发送给主控OTA客户端302。主控OTA客户端302接收下载整车升级包，将整车升级包拆分后发送到软件OTA客户端304。软件OTA客户端304根据拆分后的整车升级包中的软件包，更新软件以及标识码。

如图4所示，图4为本申请实施例提供的第二种示例性应用场景示意图。如图4所示，该应用场景中可以包括服务器401、第一车辆402、第二车辆403、第二车辆404和第二车辆405。

服务器401可以是车队服务器，车队服务器可以提前从OTA服务器中获取该车队服务器所服务的车队(例如包括第一车辆402、第二车辆403、第二车辆404和第二车辆405)所需的整车升级包。

在车队例行检修期间，无线保真(wireless-fidelity，WIFI)等联网情况下，第一车辆402、第二车辆403、第二车辆404和第二车辆405链接车队服务器，当收到升级包下载通知时，车队服务器与第一车辆402、第二车辆403、第二车辆404和第二车辆405进行双向认证(如基于公钥基础设施的认证方式)，认证通过后，车队服务器将升级包的加密密钥k加密(利用车辆的公钥加密)后下发给第一车辆402、第二车辆403、第二车辆404和第二车辆405。

示例的，第一车辆402、第二车辆403、第二车辆404和第二车辆405均可以利用密钥k解密密钥，并从服务器下载各自需要的整车软件包。例如，第一车辆402可以根据完整的整车升级包完成软件的更新。该整车升级包中可以包括用于更新标识码的软件包。第一车辆402可以根据软件包，更新软件以及标识码。

如图5所示，图5为本申请实施例提供的第三种示例性应用场景示意图。如图5所示，该应用场景中可以包括车辆501以及车辆辅助设备502。车辆501可以是任意形式的车辆。车辆辅助设备502可以是车辆充电桩或其他任意辅助车辆OTA更新的终端设备(例如手机和平板等)。车辆辅助设备502可以基于自身存储的标识码与软件版本的映射关系，以及从车辆501获取的软件版本和/或标识码的一致性，向车辆501发送需要更新的软件包。车辆501可以根据接收的软件包，更新软件以及标识码。

为便于理解本申请实施例，首先对本申请中涉及到的一些词汇作简单说明。

1、汽车OTA：指汽车通过网络从远程服务器下载软件更新包对自身系统进行更新升级的过程。例如但不限于，汽车OTA每次更新对应一个整车升级包和一个整车版本号，一个整车升级包中包含车内的多个ECU的软件。

2、车厂OTA云设备：汽车厂商或服务商提供的一种云服务，负责在云端管理升级任务和软件升级包，或标识码等信息，并以OTA的方式下发给需要软件升级的车辆。其中，OTA方式可以通过WIFI、长期演进(long term evolution，LTE)、第五代(5th generation，5G)移动通信系统或新无线(new radio，NR)和卫星等进行接入。

3、软件OTA云设备：针对软件的一种云服务，负责在云端管理汽车中的某种软件，或标识码等信息，并以OTA的方式下发给需要升级的用户或车辆。

可以理解的是，本申请实施例中的车厂OTA云设备或软件OTA云设备可以统称为OTA云端，用于实现软件和标识码的更新。

4、主控节点(update master，简称Master节点)：部署在车辆中某个ECU上的软件，负责集中控制整车OTA升级，从OTA云端下载整车升级包，拆分后分发给对应ECU。

或者，也可以为车辆上单独存在的模块单元，本申请实施例对此不作限定。

5、电子控制单元：包括自动驾驶控制器、座舱控制器、通信盒子(telematics box，T-Box)和网关等。ECU的软件升级可以从OTA云下载软件升级包并安装升级，也可以在主控节点的集中控制和协调下由主控节点拆分整车升级包后分发得到软件升级包进行升级。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以独立实现，也可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

图6为本申请实施例提供的一种基于OTA的通信方法的流程示意图，如图6所示，该方法可以包括如下步骤：

S601、获得第一信息和第二信息。

本申请实施例中，第一信息和第二信息，可以为用于车端和/或云端，验证软件版本信息与标识码的一致性的信息，例如该第一信息可以包括：第一软件版本信息和/或第一标识码；第二信息可以包括第一映射；该第一映射包含第二软件版本信息和第二标识码的关联关系。其中，该第一信息可以来自车端；该第二信息可以来自云端。

本申请实施例中，标识码可以用于指示软件版本的权限信息。其中，权限可以理解为允许汽车准入的限制。

示例性的，标识码可以为RXSWIN等其他标识。软件版本信息可以为用于标识不同软件版本的信息，例如该软件版本信息可以为软件版本号等其他信息。

可以理解的是，标识码和软件版本信息可以根据实际场景包括其他内容，本申请实施例中对此不做限定。

示例性的，获得第一信息和第二信息的主体可以为云端，或者车端。当执行主体为云端时，车端可以向云端上报第一信息，进而云端可以接收该车端上报的第一信息，并获取自身保存的第二信息，进而可以对该第一信息和第二信息的一致性进行验证；当执行主体为车端时，云端可以向车端下发第二信息，进而车端可以接收该自云端下发的第二信息，并获取自身保存的第一信息，进而可以对该第一信息和第二信息的一致性进行验证。

S602、根据第一信息和第二信息，验证第一软件版本信息与第一映射对应的第二软件版本信息的一致性。

本申请实施例中，该第一软件版本信息与第一映射对应的第二软件版本信息的一致性的情况可以包括：第一软件版本信息与第二软件版本信息一致，或者，第一软件版本信息与第二软件版本信息不一致。

示例性的，根据第一信息和第二信息，验证第一软件版本信息与第一映射对应的第二软件版本信息的一致性的主体可以包括两种：云端，或者车端。可以理解的是，本申请实施例中对验证第一软件版本信息与第一映射对应的第二软件版本信息的一致性的执行主体不做限定。

综上所述，本申请实施例提供一种基于OTA的通信方法和装置，可以在OTA的维护以及安装软件的过程中，获取来自车端的第一信息和来自云端的第二信息，利用第一信息和第二信息中的标识码与软件版本的匹配关系，验证第一信息与第二信息的一致性，进而可以通过维护车端和/或云端中，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。

在图6对应的实施例的基础上，可能的实现方式中，S601-S602所示的步骤中，验证第一软件版本信息与第一映射对应的第二软件版本信息的一致性的执行主体可以为云端，或者车端。

示例性的，方式一：利用云端验证第一软件版本信息与第一映射对应的第二软件版本信息的一致性(如图7对应的实施例)。

方式二：利用车端验证第一软件版本信息与第一映射对应的第二软件版本信息的一致性(如图8对应的实施例)。

方式一：利用云端验证第一软件版本信息与第二软件版本信息的一致性。

示例性的，图7为本申请实施例提供的一种云端维护标识码与软件版本信息一致性的流程示意图。在图7对应的实施例中，以云端为OTA云端，车端包括主控节点、ECU1以及ECU2，标识码为RXSWIN，以及第一映射为RXSWIN映射(包含RXSWIN与软件版本信息的关联关系)为例，对云端根据第一信息和第二信息，验证第一软件版本信息与第二软件版本信息的一致性进行说明，该示例并不构成对本申请实施例的限定。

如图7所示，云端维护标识码与软件版本信息一致性的过程可以包括如下步骤：

S701、主控节点收集各个ECU(包括ECU1和ECU2)上的软件版本信息。

示例性的，主控节点可以定期收集各个ECU上的软件版本信息。例如，设定每周收集一次各个ECU上的软件版本信息。

S702、主控节点将车端的软件版本信息上报至OTA云端。

适应的，OTA云端接收该车端上报的软件版本信息。

可选的，当车端保存有RXSWIN标识时，车端可以执行S703所示的步骤。

S703、主控节点将车端的RXSWIN标识上报至OTA云端。

适应的，OTA云端接收该车端上报的RXSWIN。

S704、OTA云端检查RXSWIN相关软件版本信息一致性，若不一致，则进行软件升级。

示例性的，OTA云端将S702所示的步骤中上报的软件版本信息，与OTA云端保存的RXSWIN映射表进行比较，当该主控节点上报的软件版本信息与RXSWIN映射表中的软件版本信息不一致时，则可以表示与准入相关的软件遭到了不合规的修改，此时OTA云端可以通过OTA升级软件，并修改车端的软件版本信息，保证车端的软件版本信息与OTA云端保存的RXSWIN映射表的一致性。

可选的，当车端上报RXSWIN标识至云端时，云端可以执行S705所示的步骤。

S705、OTA云端检查RXSWIN一致性，若不一致则更新RXSWIN。

示例性的，OTA云端将S703所示的步骤中上报的RXSWIN标识，与OTA云端保存的RXSWIN映射表进行比较，当该车端上报的RXSWIN标识与RXSWIN映射表中的RXSWIN标识不一致时，则可以表示车端RXSWIN被篡改，此时OTA云端可以下发指令，更新车端RXSWIN标识，保证车端的RXSWIN标识与OTA云端保存的RXSWIN映射表的一致性。

可以理解的是，OTA云端可以基于S704所示的步骤中对于车端和云端软件版本信息的一致性判断进行软件升级；可以基于S705所示的步骤中对于车端和云端RXSWIN的一致性判断进行软件升级；或者，可以基于S704和S705所示的步骤中，分别对于车端和云端的软件版本信息的一致性，以及RXSWIN的一致性，判断是否进行软件升级。

方式二：利用车端验证第一软件版本信息与第二软件版本信息的一致性。

示例性的，图8为本申请实施例提供的一种车端维护标识码与软件版本信息一致性的流程示意图。在图8对应的实施例中，以云端为OTA云端，车端包括主控节点、ECU1以及ECU2，标识码为RXSWIN以及第一映射为RXSWIN映射(包含RXSWIN与软件版本信息的关联关系)为例，对车端根据第一信息和第二信息，验证第一软件版本信息与第二软件版本信息的一致性进行说明，该示例并不构成对本申请实施例的限定。

如图8所示，车端维护标识码与软件版本信息一致性的过程可以包括如下步骤：

S801、OTA云端下发RXSWIN和RXSWIN映射表至主控节点。

适应的，主控节点接收该OTA云端下发的RXSWIN和RXSWIN映射表。

示例性的，当OTA云端保存的RXSWIN映射表中的任一RXSWIN标识，或任一软件版本信息发生变化时，OTA云端则可以将变化后的RXSWIN映射表下发至主控节点。

S802、主控节点收集各个ECU(包括ECU1和ECU2)上的软件版本信息。

S803、主控节点检查RXSWIN相关软件版本信息一致性。

S804、若主控节点确定RXSWIN相关软件版本信息不一致，则可以向OTA云端告警，并上报该不一致的软件版本信息。

示例性的，若主控节点确定S802所示的步骤中，各ECU上报的软件版本信息与的步骤中，OTA云端下发的RXSWIN映射表中的软件版本信息不一致时，则可以表示车端与准入相关的软件遭到了不合规的修改，此时主控节点可以将不一致的消息上报至OTA云端。

基于此，利用云端或车端验证第一软件版本信息与第二软件版本信息的一致性，进而可以通过维护车端和/或云端中，软件版本与RXSWIN的一致性，防止软件版本和/或RXSWIN被篡改，保证通过OTA升级的汽车软件正常升级。

在图6对应的实施例的基础上，可能的实现方式中，还包括：

S603(图中未示出)、在第一软件版本信息与第二软件版本信息不一致的情况下，第一车辆向云端和/或第一车辆的显示设备，发送第一软件版本信息、第一标识码和/或告警信息。

适应的，显示设备可以接收来自第一车辆的第一软件版本信息、第一标识码和/或告警信息。其中，本申请实施例描述的车端可以包括第一车辆。

本申请实施例中，该告警信息用于指示车辆的标识码和/或软件版本信息与服务器的映射关系不一致。该显示设备可以为第一车辆的中控显示屏、第一车辆的仪表盘显示屏，或者与车辆连接的其他显示设备，例如手机等。本申请实施例中，该显示设备可以根据实际场景包括其他内容，本申请实施例中对此不做限制。

S604(图中未示出)、显示设备显示告警信息。

示例性的，图9为本申请实施例提供的一种显示告警信息的界面示意图。如图9所示，该界面可以为第一车辆的中控显示屏900所显示的界面，该中控显示屏900显示的界面中，可以包括软件版本更新的指示消息901，系统提示消息902，停止控件903，以及继续控件904等内容。该指示消息901中显示“助力转向软件V2.0(R79 90)正在更新中…”。其中，V2.0可以为该助力转向软件的软件版本信息，R79 90可以为该助力转向软件的软件版本对应的标识码。

在进行软件更新前，当第一车辆检测到第一软件版本信息与第二软件版本信息不一致时，可以向中控显示屏900发送告警信息，该告警信息可以为显示在中控显示屏900上的系统提示消息902。其中，该系统提示消息902中显示，“车辆软件可能受到非法篡改，请及时处理！”后续当用户看到该提示消息时，可以触发停止控件903，暂停软件的更新；或者，将车辆开到4S店进行处理。

基于此，可以将系统内部用于指示软件版本信息与标识码不一致的告警信息，通过用户界面直观的显示给用户，方便用户及时进行后续处理，进一步保障汽车软件的正常升级。

在图6对应的实施例的基础上，可能的实现方式中，S602可以包括：

一种实现中，在第一软件版本信息与第二软件版本信息不一致，和/或，第一标识码与第二标识码不一致的情况下，确定第一软件版本信息与第二软件版本信息不一致。

可以理解为，第一软件版本信息与第二软件版本信息不一致，第一标识码与第二标识码不一致，或者，第一软件版本信息与第二软件版本信息不一致且第一标识码与第二标识码不一致的情况下，确定第一软件版本信息与第二软件版本信息不一致。

其中，第一软件版本信息与第二软件版本信息不一致，可以理解为，此时第一标识码与第二标识码可以一致，或者第一标识码与第二标识码可以不一致；第一标识码与第二标识码不一致，可以理解为，此时第一软件版本信息与第二软件版本信息可以一致，或者第一软件版本信息与第二软件版本信息可以不一致。

另一种实现中，在第一软件版本信息与第二软件版本信息一致，和/或，第一标识码与第二标识码一致的情况下，确定第一软件版本信息与第二软件版本信息一致。

可以理解为，第一软件版本信息与第二软件版本信息一致，第一标识码与第二标识码一致，或者，第一软件版本信息与第二软件版本信息一致且第一标识码与第二标识码一致的情况下，确定第一软件版本信息与第二软件版本信息一致。

基于此，在云端下发第一任务的场景中，可以在第一软件版本信息和/或第一标识码，与第一映射一致的条件下，基于一致性校验进一步保证通过OTA升级的汽车软件正常升级；在云端和/或车端定期检查标识码与软件版本信息一致性的场景中，可以在第一软件版本信息和/或第一标识码，与第一映射不一致的条件下，及时发现由于该不一致产生的不合规风险，防止标识码和/或软件版本信息被篡改，保证通过OTA升级的汽车软件正常升级。

在图6对应的实施例的基础上，可能的实现方式中，还包括：在第一软件版本信息与第二软件版本信息不一致的情况下，更新第一软件版本信息和/或第一标识码；或者，在第一软件版本信息与第二软件版本信息一致的情况下，更新第一软件版本信息和/或第一标识码。

一种实现中，第一软件版本信息与第二软件版本信息不一致的场景可以为，由于车端的第一软件版本信息和/或第一标识码遭到篡改，导致车端的第一软件版本信息与云端的第二软件版本信息不一致。进而云端可以将自身保存的软件版本信息和/或标识码，下发至车端，保证云端与车端的软件版本信息和标识码的一致性。其中，云端下发的软件版本信息和/或标识码，可以与车端遭到篡改前保存的软件版本信息和/或标识码一致。在此场景下，若第一软件版本信息与第二软件版本信息一致，则可以不进行第一软件版本信息和/或第一标识码的更新处理。

示例性的，基于不一致更新第一软件版本信息和/或第一标识码的过程可以如图7以及图8对应的实施例，在此不再赘述。

另一种实现中，第一软件版本信息与第二软件版本信息一致的场景可以为，由云端下发第一任务(或称更新任务)，当云端确定由车端上报的第一软件版本信息和/或第一标识码，与云端保存的第二软件版本信息一致时，进而云端可以基于一致性的保证，将第一任务中携带的软件版本信息和/或标识码下发至车端。在此场景下，若第一软件版本信息与第二软件版本信息不一致，则可以不进行第一软件版本信息和/或第一标识码的更新处理。

示例性的，图10为本申请实施例提供的一种云端进行一致性判断的流程示意图。在图10对应的实施例中，以云端为OTA云端，车端包括主控节点，第一映射为RXSWIN映射，以及标识码为RXSWIN为例，对在第一软件版本信息与第二软件版本信息一致的情况下，更新第一软件版本信息和/或第一标识码进行说明，该示例并不构成对本申请实施例的限定。

如图10所示，云端进行一致性判断的过程可以包括：

S1001、OTA云端收集主控节点上的RXSWIN标识。

S1002、OTA云端检查RXSWIN一致性。

示例性的，若OTA云端确定车端的RXSWIN标识与第一映射中的RXSWIN标识不一致时，则OTA云端可以确定不进行OTA。

若OTA云端确定车端的RXSWIN标识与第一映射中的RXSWIN标识一致时，则OTA云端可以向主控节点下发更新任务，该更新任务可以携带新的RXSWIN标识和RXSWIN映射表。

S1003、主控节点保存新的RXSWIN标识和RXSWIN映射表。

基于此，云端和车端可以基于标识码与软件版本的匹配关系，维护车端的软件版本信息和/或标识码，与云端的映射关系的一致性，进而消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。

上述为车端和/或云端维护软件版本信息与标识码一致性的过程下面对OTA升级汽车软件的过程中，保证软件版本信息和标识码的一致性的过程进行描述。

示例性的，图11为本申请实施例提供的一种更新软件的流程示意图。如图11所示，更新软件的主体可以包括云端和第一车辆。其中第一车辆中可以包括主控节点以及一个或多个ECU。

如图11所示，该更新软件的过程可以包括如下步骤：

S1101、云端向第一车辆发送第一任务。

适应的，第一车辆接收第一任务，并可以根据第一任务更新第一软件版本信息和/或第一标识码。其中，接收第一任务的主体可以为第一车辆中的主控节点。

本申请实施例中，第一任务用于指示更新第一软件版本信息和/或第一标识码；在第一软件版本信息与第二软件版本信息不一致的情况下，第一任务包括第一映射；在第一软件版本信息与第二软件版本信息一致的情况下，第一任务包括第二映射；第二映射包含第三软件版本信息和第三标识码的关联关系；第三软件版本信息不同于第二软件版本信息，和/或，第三标识码不同于第二标识码。

示例性的，当云端确定第一车辆的第一软件版本信息与云端的第二软件版本信息不一致时，可以理解为此时第一车辆的软件版本和/或标识码可能遭到篡改，此时云端可以发送包含第一映射的第一任务。其中，第一映射可以理解为第一车辆的软件版本和/或标识码遭到篡改之前，云端保存的软件版本信息和标识码的关联关系。

示例性的，当云端确定第一车辆的第一软件版本信息与云端的第二软件版本信息一致时，可以理解为此时第一车辆设备与云端已经经过，进行OTA升级软件前的一致性判断，此时云端可以发送包含第二映射的第一任务。其中，第二映射可以理解为由OTA触发的包含新的软件版本信息与新的标识码的映射关系。

可以理解的是，当进行OTA对软件进行更新，不足以改变准入时该软件对应的测试参数时，第二映射中的第三标识码可以与第一车辆保存的第一标识码一致。示例性的，若第一车辆的电池管理系统为V1.0，其系统可以支持可续航里程为500km；当对该电池管理系统通过OTA进行软件升级时，将第一车辆的电池管理系统更新为V1.1，其系统可以支持可续航里程为500km；此时由于对电池管理系统的更新没有改变准入时，可持续里程的具体参数。因此，此时第一车辆通过OTA进行软件升级时，云端下发的第二映射中的第三软件版本信息与第一车辆保存的第一软件版本信息不一致，第二映射中的第三标识码可能与第一车辆保存的第一标识码一致。

S1102、云端向第一车辆发送第一软件包。

适应的，第一车辆可以接收第一软件包，并根据第一软件包更新车辆的软件。其中，软件包中可以包含软件，以及该软件对应的软件版本信息。

本申请实施例中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一软件包包括第二标识码；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一软件包包括第三标识码。

示例性的，当云端确定，第一车辆的第一软件版本信息与云端的第二软件版本信息不一致时，可以理解为此时第一车辆的软件版本或者标识码可能遭到篡改，此时云端可以发送包含第二标识码的第一软件包。其中，第一软件包可以理解为第一车辆的软件版本或者标识码遭到篡改之前，云端保存的软件包。其中，该云端保存的软件包中，可以保存第一车辆的软件版本或者标识码遭到篡改之前的软件和标识码。

示例性的，当云端确定，第一车辆的第一软件版本信息与云端的第二软件版本信息一致时，可以理解为此时第一车辆设备与云端已经经过，进行OTA升级软件前的一致性判断，此时云端可以发送包含第三标识码的第一软件包。其中，第一软件包可以理解为由OTA触发的软件包。

可以理解的是，当进行OTA时的软件版本更新，不足以改变准入时的参数时，第三标识码可以与第一标识码一致，其具体过程不再赘述。

S1103、第一车辆向ECU发送各ECU对应的第一软件包。

适应的，各ECU接收该第一软件包。其中，ECU的数量可以为一个或多个。例如，当ECU的数量为N个时，第一车辆可以向N个ECU发送各ECU对应的第一软件包；N为正整数。

示例性的，当第一车辆中包含主控节点时，主控节点可以接收到云端发送的第一软件包，并将该第一软件包分发给相应的ECU。

S1104、ECU安装第一软件包并更新标识码。

本申请实施例中，该标识码可以为第二标识码或第三标识码。

示例性的，当ECU在安装第一软件包出现异常时，ECU可以回滚至安装前的软件，并恢复第一标识码。其中，ECU回滚至安装前的软件，可以表示ECU恢复第一软件版本信息。

示例性的，当ECU在安装第一软件包成功时，ECU可以更新第一标识码和第一软件版本信息。

S1105、ECU将安装结果发送至第一车辆。

适应的，第一车辆接收该安装结果。其中，该安装结果可以为安装成功，或者任一个或多个ECU安装失败。

S1106、在该软件安装结果为任意一个或多个安装失败的情况下，回滚第一车辆的整车软件版本和标识码。

可选的，当该软件安装结果为安装成功的情况下，可以更新整车版本和/或标识码。示例性的，当软件安装结果为安装成功，且更新的软件不足以改变整车版本时，该整车版本可以不发生改变。

基于此，可以在OTA升级软件的过程中保证软件版本信息和标识码的匹配关系，进而基于车端和/或云端中，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。

基于上述实施例中所描述的内容，为了更好的理解本申请各实施例，下面以车端更新软件的整体过程进行分别描述。具体的，该过程可以包括：云端向车端下发软件包(如图12对应的实施例)，车端成功安装软件包(如图13对应的实施例)，以及车端安装软件包失败(如图14对应的实施例)。

图12为本申请实施例提供的一种云端向车端下发软件包的流程示意图。在图12对应的实施例中，以云端为OTA云端，车端包括主控节点、ECU1和ECU2，标识码为RXSWIN，第一映射为RXSWIN映射为例，对云端向车端下发软件包的过程进行说明，该示例并不构成对本申请实施例的限定。

如图12所示，云端下发软件包的过程可以包括如下步骤：

S1201、OTA云端向主控节点下发软件包。

适应的，主控节点接收该OTA云端下发的软件包。其中，该软件包携带相关RXSWIN标识。

S1202、主控节点向ECU1和ECU2分发软件包。

适应的，该ECU1和ECU2接收该主控节点发送的软件包。其中，该ECU1和ECU2可以为该软件包对应的ECU。

S1203、ECU1和ECU2接收软件包，记录RXSWIN标识。

基于此，可以在OTA升级软件的过程中保证软件版本信息和标识码的匹配关系，进而基于车端和/或云端，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。

上述为云端向车端下发软件包的过程，下文对车端安装软件包，且安装成功的过程进行描述。

示例性的，图13为本申请实施例提供的一种车端安装软件包的流程示意图。在图13对应的实施例中，以云端为OTA云端，车端包括主控节点、ECU1和ECU2，标识码为RXSWIN，第一映射为RXSWIN映射为例，对车端成功安装软件包的过程进行说明，该示例并不构成对本申请实施例的限定。

如图13所示，ECU安装软件包的过程可以包括如下步骤：

S1301、ECU1和ECU2安装软件。

示例性的，当主控节点向ECU1和ECU2分发软件包后，ECU1和ECU2可以基于软件包安装软件。

S1302、ECU1和ECU2安装软件成功，更新相关RXSWIN。

S1303、ECU1和ECU2将安装结果发送至主控节点。

S1304、主控节点更新整车版本和/或更新RXSWIN。

其中，该整车版本也可以不发生改变，在此不再赘述。

基于此，可以在OTA升级软件的过程中保证软件版本信息和标识码的匹配关系，进而基于车端和/或云端中，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。

上述为车端安装软件包，且安装成功的过程，可能的实现方式中，车端安装软件包可能发生异常，下文对车端安装软件包，且安装失败的过程进行描述。

示例性的，图14为本申请实施例提供的另一种车端安装软件包的流程示意图。在图14对应的实施例中，以云端为OTA云端，车端包括主控节点、ECU1和ECU2，标识码为RXSWIN，第一映射为RXSWIN映射为例，对车端安装软件包失败的过程进行说明，该示例并不构成对本申请实施例的限定。

如图14所示，ECU安装软件包的过程可以包括如下步骤：

S1401、ECU1和ECU2安装软件，更新相关RXSWIN。

S1402、ECU1和ECU2安装软件出现异常，软件回滚。

其中，该ECU1和ECU2保存有安装软件包前的软件，当ECU1和ECU2安装软件出现异常时，ECU1和ECU2可以回滚至该安装软件包前的软件。

S1403、ECU1和ECU2恢复旧RXSWIN。

其中，该ECU1和ECU2保存有安装软件包前的RXSWIN，当ECU1和ECU2安装软件出现异常时，ECU1和ECU2可以回滚至该安装软件包前的RXSWIN。

S1404、ECU1和ECU2向主控节点通知异常。

S1405、主控节点恢复相关旧RXSWIN。

基于此，可以在OTA升级软件的过程中保证软件版本信息和标识码的匹配关系，进而基于车端和/或云端中，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。

上面结合图6-图14，对本申请实施例提供的方法进行了说明，下面对本申请实施例提供的执行上述方法的装置进行描述。

示例性的，图15为本申请实施例提供的一种基于OTA的通信装置的结构示意图，如图8所示，基于OTA的通信装置150可以用于通信设备、电路、硬件组件或者芯片中，该基于OTA的通信装置包括：显示单元1501、处理单元1502和通信单元1503。其中，显示单元1501用于支持配网方法执行的显示的步骤；处理单元1502用于支持基于OTA的通信装置执行信息处理的步骤；通信单元1503用于支持基于OTA的通信装置执行数据发送或接收的步骤。

具体的，本申请实施例提供一种基于OTA的通信装置，通信单元1503，用于获得第一信息和第二信息；第一信息包括第一软件版本信息和/或第一标识码；第二信息包括第一映射；第一映射包含第二软件版本信息和第二标识码的关联关系；标识码用于指示软件版本的权限信息；处理单元1502，还用于根据第一信息和第二信息，验证第一软件版本信息与第二软件版本信息的一致性。

可能的实现方式中，处理单元1502，具体用于：在第一软件版本信息与第二软件版本信息不一致，和/或，第一标识码与第二标识码不一致的情况下，确定第一软件版本信息与第二软件版本信息不一致；或者，在第一软件版本信息与第二软件版本信息一致，和/或，第一标识码与第二标识码一致的情况下，确定第一软件版本信息与第二软件版本信息一致。

可能的实现方式中，处理单元1502，还用于：在第一软件版本信息与第二软件版本信息不一致的情况下，更新第一软件版本信息和/或第一标识码；或者，在第一软件版本信息与第二软件版本信息一致的情况下，更新第一软件版本信息和/或第一标识码。

可能的实现方式中，通信单元1503，用于：向第一车辆发送第一任务；第一任务用于指示更新第一软件版本信息和/或第一标识码；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一任务包括第一映射；在第一软件版本信息与第二软件版本信息一致的情况下，第一任务包括第二映射；第二映射包含第三软件版本信息和第三标识码的关联关系。

可能的实现方式中，通信单元1503，还用于：向第一车辆发送第一软件包；第一软件包用于更新第一车辆对应的软件版本信息；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一软件包包括第二标识码；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一软件包包括第三标识码。

可能的实现方式中，通信单元1503，还用于：在第一软件版本信息与第二软件版本信息不一致的情况下，向服务器和/或第一车辆的显示设备发送第一软件版本信息、第一标识码和/或告警信息；告警信息用于指示车辆的标识码和/或软件版本信息与服务器的映射关系不一致。

可能的实现方式中，通信单元1503，具体用于接收来自服务器的第一任务，第一任务用于指示更新第一软件版本信息和/或第一标识码；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一任务包括第一映射；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一任务包括第二映射；第二映射包含第三软件版本信息与第三标识码的关联关系。

可能的实现方式中，通信单元1503，还用于：接收来自服务器的第一软件包；第一软件包用于更新第一车辆对应的软件版本信息；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一软件包包括第二标识码；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一软件包包括第三标识码。

可能的实现方式中，标识码包括第一法规相关软件识别码RXSWIN。

通信在一种可能的实施例中，基于OTA的通信装置还可以包括：存储单元1504。处理单元1502、存储单元1504通过线路相连。

存储单元1504可以包括一个或者多个存储器，存储器可以是一个或者多个设备、电路中用于存储程序或者数据的器件。

存储单元1504可以独立存在，通过通信线路与基于OTA的通信装置具有的处理单元1502相连。存储单元1504也可以和处理单元1502集成在一起。

其中，则通信单元1503可以是输入或者输出接口、管脚或者电路等。示例性的，存储单元1504可以存储雷达或目标设备的方法的计算机执行指令，以使处理单元1502执行上述实施例中雷达或目标设备的方法。存储单元1504可以是寄存器、缓存或者RAM等，存储单元1504可以和处理单元1502集成在一起。存储单元1504可以是ROM或者可存储静态信息和指令的其他类型的静态存储设备，存储单元1504可以与处理单元1502相独立。

图16为本申请实施例提供的一种控制设备的硬件结构示意图，如图16所示，该控制设备包括处理器1601，通信线路1604以及至少一个通信接口(图16中示例性的以通信接口1603为例进行说明)。

处理器1601可以是一个通用中央处理器(central processing unit，CPU)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制本申请方案程序执行的集成电路。

通信线路1604可包括在上述组件之间传送信息的电路。

通信接口1603，使用任何收发器一类的装置，用于与其他设备或通信网络通信，如以太网，无线局域网(wireless local area networks，WLAN)等。

可能的，该控制设备还可以包括存储器1602。

存储器1602可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory，EEPROM)、只读光盘(compactdisc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过通信线路1604与处理器相连接。存储器也可以和处理器集成在一起。

其中，存储器1602用于存储执行本申请方案的计算机执行指令，并由处理器1601来控制执行。处理器1601用于执行存储器1602中存储的计算机执行指令，从而实现本申请实施例所提供的基于OTA的通信方法。

可能的，本申请实施例中的计算机执行指令也可以称之为应用程序代码，本申请实施例对此不作具体限定。

在具体实现中，作为一种实施例，处理器1601可以包括一个或多个CPU，例如图16中的CPU0和CPU1。

在具体实现中，作为一种实施例，控制设备可以包括多个处理器，例如图16中的处理器1601和处理器1605。这些处理器中的每一个可以是一个单核(single-CPU)处理器，也可以是一个多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。

示例性的，图17为本申请实施例提供的一种芯片的结构示意图。芯片170包括一个或两个以上(包括两个)处理器1720和通信接口1730。

在一些实施方式中，存储器1740存储了如下的元素：可执行模块或者数据结构，或者他们的子集，或者他们的扩展集。

本申请实施例中，存储器1740可以包括只读存储器和随机存取存储器，并向处理器1720提供指令和数据。存储器1740的一部分还可以包括非易失性随机存取存储器(non-volatile random access memory，NVRAM)。

本申请实施例中，存储器1740、通信接口1730以及存储器1740通过总线系统2020耦合在一起。其中，总线系统2020除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。为了便于描述，在图17中将各种总线都标为总线系统2020。

上述本申请实施例描述的方法可以应用于处理器1720中，或者由处理器1720实现。处理器1720可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器1720中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器1720可以是通用处理器(例如，微处理器或常规处理器)、数字信号处理器(digitalsignal processing，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field-programmable gate array，FPGA)或者其他可编程逻辑器件、分立门、晶体管逻辑器件或分立硬件组件，处理器1720可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。

结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。其中，软件模块可以位于随机存储器、只读存储器、可编程只读存储器或带电可擦写可编程存储器(electricallyerasable programmable read only memory，EEPROM)等本领域成熟的存储介质中。该存储介质位于存储器1740，处理器1720读取存储器1740中的信息，结合其硬件完成上述方法的步骤。

在上述实施例中，存储器存储的供处理器执行的指令可以以计算机程序产品的形式实现。其中，计算机程序产品可以是事先写入在存储器中，也可以是以软件形式下载并安装在存储器中。

计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包括一个或多个可用介质集成的服务器、数据中心等数据存储设备。例如，可用介质可以包括磁性介质(例如，软盘、硬盘或磁带)、光介质(例如，数字通用光盘(digital versatile disc，DVD))、或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。

本申请实施例还提供了一种计算机可读存储介质。上述实施例中描述的方法可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。计算机可读介质可以包括计算机存储介质和通信介质，还可以包括任何可以将计算机程序从一个地方传送到另一个地方的介质。存储介质可以是可由计算机访问的任何目标介质。

作为一种可能的设计，计算机可读介质可以包括紧凑型光盘只读储存器(compactdisc read-only memory，CD-ROM)、RAM、ROM、EEPROM或其它光盘存储器；计算机可读介质可以包括磁盘存储器或其它磁盘存储设备。而且，任何连接线也可以被适当地称为计算机可读介质。例如，如果使用同轴电缆，光纤电缆，双绞线，DSL或无线技术(如红外，无线电和微波)从网站，服务器或其它远程源传输软件，则同轴电缆，光纤电缆，双绞线，DSL或诸如红外，无线电和微波之类的无线技术包括在介质的定义中。如本文所使用的磁盘和光盘包括光盘(CD)，激光盘，光盘，数字通用光盘(digital versatile disc，DVD)，软盘和蓝光盘，其中磁盘通常以磁性方式再现数据，而光盘利用激光光学地再现数据。

上述的组合也应包括在计算机可读介质的范围内。以上，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。