CN115277671A - 车辆的ota升级方法、装置、车辆及存储介质 - Google Patents

Abstract

本申请涉及汽车技术领域，特别涉及一种车辆的OTA升级方法、装置、车辆及存储介质，其中，方法包括：在识别到本车周围存在满足预设目标条件的至少一个空中下载OTA下载节点时，发送升级请求至每个OTA下载节点；接收一个或多个OTA下载节点基于升级请求生成的升级数据帧，其中，每个升级数据帧在升级包中的位置不同；根据所有升级数据帧在升级包中的实际位置依次组合得到升级包，并利用升级包升级本车。由此，解决了相关技术中，OTA安装包下载操作繁琐，效率较低，灵活性和智能性较差，对安装包数据完整性和云端服务器性能要求较高，无法满足实际使用中用户的需要等问题。

Description

车辆的OTA升级方法、装置、车辆及存储介质

技术领域

本申请涉及车辆技术领域，特别涉及一种车辆的OTA(Over-The-Air，空中下载技术)升级方法、装置、车辆及存储介质。

背景技术

OTA属于一种云端下载技术，随着汽车智能化的发展，汽车上支持OTA的控制器也越来越多。

为了对汽车上支持OTA的控制器进行升级，相关技术中，方法为：管理员云端进行挂包，OTA下载节点通过内置运营商物联卡等手段与云端建立连接，而后通过版本收集节点查询车内的版本号，以此判断是否需要本次升级；若需要，则从云端下载至OTA下载节点，再通过OTA部署节点部署至各个控制器。其中，下载来源可以由V2X(Vechile To Everything，车对外界的信息交换)等多种方式提供。

然而，对用户而言，若一次升级的控制器较多，则需要下载的升级包就较大，下载时间就较长；对主机厂而言，若要对仓库内每台车进行升级，则需要在云端挂包后对每辆车执行下载操作，操作繁琐且对云端服务器性能有较高要求。相关技术中，即便使用对基础设施要求较高的分布式升级，仍不能改变上述一对一的下载方式，无法充分利用附近资源，且仍需附近节点具有完整安装包才可进行软件包的下载、升级等过程。

发明内容

本申请提供一种车辆的OTA升级方法、装置、车辆及存储介质，以解决相关技术中，OTA安装包下载操作繁琐，效率较低，灵活性和智能性较差，对安装包数据完整性和云端服务器性能要求较高，无法满足实际使用中用户的需要等问题。

本申请第一方面实施例提供一种车辆的OTA升级方法，包括以下步骤：在识别到本车周围存在满足预设目标条件的至少一个空中下载OTA下载节点时，发送升级请求至每个OTA下载节点；接收一个或多个OTA下载节点基于所述升级请求生成的升级数据帧，其中，每个升级数据帧在升级包中的位置不同；根据所有升级数据帧在所述升级包中的实际位置依次组合得到所述升级包，并利用所述升级包升级所述本车。

根据上述技术手段，本申请实施例可以通过与周围OTA下载节点连接，允许汽车OTA下载节点从附近多个可达OTA下载节点中获取升级数据，提高了大文件的传输速率，显著降低云端服务器的压力，节省用户时间；且在没有连接云端OTA服务器的条件下，只要周围存在合适节点，也可进行OTA下载，为OTA安装包从云端到车辆提供了新的通道；同时OTA下载节点发送的是数据帧，因此发送方无需具有完整的升级包，也可将自身已有的数据字段进行发送，以用于OTA升级，降低OTA升级的条件限制，提升用户的升级体验。

进一步地，所述升级数据帧包括升级数据字段和所述升级数据字段在所述升级包中的实际偏移量，所述接收一个或多个OTA下载节点基于所述升级请求生成的升级数据帧，包括：判断所述升级包中是否存在与所述实际偏移量相同的升级数据字段；如果存在，则丢弃所述升级数据帧，否则根据所述实际偏移量创建二进制文件，并基于所述实际偏移量将所述升级数据字段写入所述二进制文件中。

根据上述技术手段，本申请实施例可以基于偏移量作为文件名的二进制文件中存储升级数据帧，按照逻辑进行文件的写入操作，无需一次性存储完整的升级包，为升级包从云端到车辆提供了新的通道，提升用户升级体验。

进一步地，所述根据所有升级数据帧在所述升级包中的实际位置依次组合得到所述升级包，包括：根据所述二进制文件的实际偏移量进行排序，得到排序结果；将所述二进制文件中升级数据字段按照排序结果依次组合，得到所述升级包。

根据上述技术手段，本申请实施例可以按照文件写入操作的逻辑进行排序生成升级包，无需一次性接收完整升级包，为升级包从云端到车辆提供了新的通道，提升用户升级体验。

进一步地，在将所述二进制文件中升级数据字段按照排序结果依次组合之前，包括：根据所述排序结果判断所有升级数据字段是否为连续字段，如果是，则将所述二进制文件中升级数据字段按照排序结果依次组合，否则继续接收升级数据帧。

根据上述技术手段，本申请实施例可以根据所有升级数据字段是否为连续字段判断是否传输完成，并在数据包传输完成时，通过排序组合得到数据包，否则继续接收升级数据帧，从而在组合数据包之前才进行连续判断，在传输逻辑中不对偏移量进行连续性判断，提高升级的适用性。

进一步地，在同时接收多个OTA下载节点发送的升级数据帧时，每个OTA下载节点发送数据的起始位置不同。

根据上述技术手段，本申请实施例可以同时接收多个可达OTA下载节点中获取升级数据，并且每个发送的起始位置不同，实现多个不同升级数据的同时传输，从而可以大大提高大文件的传输速率，显著降低云端服务器的压力，节省用户时间。

本申请第二方面实施例提供一种车辆的OTA升级方法，包括以下步骤：接收其他车辆发送的升级请求；根据所述升级请求识别所述其他车辆与本车类型相同时，判断本车的升级包版本是否高于所述其他车辆的升级包版本；如果本车的升级包版本高于所述其他车辆的升级包版本，则发送升级数据帧至其他车辆，否则，忽略所述升级请求。

根据上述技术手段，本申请实施例可以根据其他车辆的升级请求发送升级数据给其他车辆，由于发送的升级数据是以数据帧的形式发送的，因此无需具有完整的安装包，也可将自身已有的数据字段进行发送，有效降低OTA升级的条件限制，为车辆的OTA升级提供了新的升级通道，提升用户的升级体验。

本申请第三方面实施例提供一种车辆的OTA升级装置，包括：识别模块，用于在识别到本车周围存在满足预设目标条件的至少一个空中下载OTA下载节点时，发送升级请求至每个OTA下载节点；第一接收模块，用于接收一个或多个OTA下载节点基于所述升级请求生成的升级数据帧，其中，每个升级数据帧在升级包中的位置不同；升级模块，用于根据所有升级数据帧在所述升级包中的实际位置依次组合得到所述升级包，并利用所述升级包升级所述本车。

本申请第四方面实施例提供一种车辆的OTA升级装置，包括：第二接收模块，用于接收其他车辆发送的升级请求；判断模块，用于根据所述升级请求识别所述其他车辆与本车类型相同时，判断本车的升级包版本是否高于所述其他车辆的升级包版本；执行模块，用于如果本车的升级包版本高于所述其他车辆的升级包版本，则发送升级数据帧至其他车辆，否则，忽略所述升级请求。

本申请第五方面实施例提供一种车辆，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现如上述实施例所述的车辆的OTA升级方法。

本申请第六方面实施例提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行，以用于实现如上述实施例所述的车辆的OTA升级方法。

由此，本申请至少具有如下有益效果：

(1)通过与周围OTA下载节点连接，允许汽车OTA下载节点从附近多个可达OTA下载节点中获取升级数据，提高了大文件的传输速率，显著降低云端服务器的压力，节省用户时间；且在没有连接云端OTA服务器的条件下，只要周围存在合适节点，也可进行OTA下载，为OTA安装包从云端到车辆提供了新的通道；同时OTA下载节点发送的是数据帧，因此发送方无需具有完整的升级包，也可将自身已有的数据字段进行发送，以用于OTA升级，降低OTA升级的条件限制，提升用户的升级体验。

(2)本申请实施例可以基于偏移量作为文件名的二进制文件中存储升级数据帧，按照逻辑进行文件的写入操作，无需一次性存储完整的升级包，为升级包从云端到车辆提供了新的通道，提升用户升级体验。

(3)本申请实施例可以按照文件写入操作的逻辑进行排序生成升级包，无需一次性接收完整升级包，为升级包从云端到车辆提供了新的通道，提升用户升级体验。

(4)本申请实施例可以根据所有升级数据字段是否为连续字段判断是否传输完成，并在数据包传输完成时，通过排序组合得到数据包，否则继续接收升级数据帧，从而在组合数据包之前才进行连续判断，在传输逻辑中不对偏移量进行连续性判断，提高升级的适用性。

(5)本申请实施例可以同时接收多个可达OTA下载节点中获取升级数据，并且每个发送的起始位置不同，实现多个不同升级数据的同时传输，从而可以大大提高大文件的传输速率，显著降低云端服务器的压力，节省用户时间。

(6)本申请实施例可以根据其他车辆的升级请求发送升级数据给其他车辆，由于发送的升级数据是以数据帧的形式发送的，因此无需具有完整的安装包，也可将自身已有的数据字段进行发送，有效降低OTA升级的条件限制，为车辆的OTA升级提供了新的升级通道，提升用户的升级体验。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为根据本申请实施例提供的一种车辆的OTA升级方法的流程图；

图2为根据本申请实施例提供的一种可能的下载流程图；

图3为根据本申请实施例提供的发现周围列表流程图；

图4为根据本申请实施例提供的对比信息流程图；

图5为根据本申请实施例提供的保存安装包的文件层级示意图；

图6为根据本申请实施例提供的接收数据报文流程图；

图7为根据本申请实施例提供的另一种车辆的OTA升级方法的流程图；

图8为根据本申请实施例提供的发送数据报文流程图；

图9为根据本申请实施例提供的车辆的OTA升级装置的示例图；

图10为根据本申请实施例提供的另一个车辆的OTA升级装置的示例图；

图11为根据本申请实施例提供的车辆的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。

下面参考附图描述本申请实施例的车辆的OTA升级方法、装置、车辆及存储介质。针对上述背景技术中提到的相关技术中，OTA安装包下载操作繁琐，效率较低，灵活性和智能性较差，对安装包数据完整性和云端服务器性能要求较高，无法满足实际使用中用户的需要的问题，本申请提供了一种车辆的OTA升级方法，在该方法中，本申请实施例可以通过与周围OTA下载节点连接，允许汽车OTA下载节点从附近多个可达OTA下载节点中获取升级数据，提高了大文件的传输速率，显著降低云端服务器的压力，节省用户时间；且在没有连接云端OTA服务器的条件下，只要周围存在合适节点，也可进行OTA下载，为OTA安装包从云端到车辆提供了新的通道；同时OTA下载节点发送的是数据帧，因此发送方无需具有完整的升级包，也可将自身已有的数据字段进行发送，以用于OTA升级，降低OTA升级的条件限制，提升用户的升级体验。由此，解决了相关技术中，OTA安装包下载操作繁琐，效率较低，灵活性和智能性较差，对安装包数据完整性和云端服务器性能要求较高，无法满足实际使用中用户的需要等问题。

具体而言，图1为本申请实施例所提供的一种车辆的OTA升级方法的流程示意图。

如图1所示，该车辆的OTA升级方法包括以下步骤：

在步骤S101中，在识别到本车周围存在满足预设目标条件的至少一个空中下载OTA下载节点时，发送升级请求至每个OTA下载节点。

其中，预设目标条件可以根据实际情况具体设置，比如，预设条件可以是同车企、同型号和本车版本低于周围某节点版本等，对此不做具体限定。

需要说明的是，为了实现附近通信功能，本申请实施例的OTA下载节点至少应该具有通信模块和OTA模块；通信模块可以用于提供传统通信通道并允许车辆发现周围终端以收发数据，OTA模块可以用于提供下载、部署、安装的应用功能，其中，下载可以指OTA下载节点中的OTA模块通过通信模块获得OTA安装包的过程。

具体而言，(1)为完成车辆之间的互相识别，本申请实施例OTA下载节点的通信模块会固定时间向附近可达节点广播发送识别报文，其中，识别报文中应包括但不限于具有如下信息：车辆品牌，用于防止型号与其他品牌车辆冲突；车辆型号，用于识别不同车型，不同车型OTA安装包可能不同；车辆识别号，作为网络中唯一识别码；版本信息，包括在版本收集节点的所有的版本信息；已下载文件信息，包括文件名，版本号，每个文件块的起始地址和大小。

(2)为完成安装包传输，本申请实施例OTA下载节点的通信模块能够根据OTA模块逻辑需求，向附近可达节点发送数据报文，其中，数据报文中应包括但不限于具有如下信息：文件名，用于确定需要传输的安装包名；文件大小，用于确认需要传输的安装包总大小；版本号，用于确认该安装包成功安装后的版本号；文件校验值，可以选择某种散列算法作为整个文件的校验值；偏移量，可以是数据字段位于文件的偏移量；数据长度，即数据字段的长度；数据字段，即本次传输的数据报文的有效数据域；数据校验值，可以选择某种校验算法作为“数据字段”的校验值。

可以理解的是，本申请实施例可以调用车辆OTA下载节点的通信模块，在发现附近存在可达OTA下载节点后，交换OTA识别报文，判断是否满足预设目标条件，在满足条件的情况下发送升级请求至每个OTA下载节点。

为便于叙述，以下实施例中，将以预设目标条件为同车企、同型号且本车相关版本低于周围某节点版本为例，对本申请实施例的车辆的OTA升级方法进行具体阐述。

举例而言，如图2所示，本申请实施例可以根据OTA识别报文来对比相关版本信息，若满足预设目标条件，则可以接收OTA节点的数据；若满足同车企、同型号但本车相关版本高于周围某节点版本，则需要发送数据，发送过程将在后续发送实施例中进行具体阐述，在此不做过多叙述；若既不需要发送也不需要接受，进行等待，比如可以等待两分钟等，但等待期间内仍允许接收附近可达节点发送的报文。具体交换识别报文和对比版本信息过程如下：

(1)交换识别报文：如图3所示，本申请实施例可以发送自身识别报文并接收周围所有节点的识别报文，将车辆识别码与其ip绑定，并将周围所有节点(包括自己)的识别报文保存至可存储的介质中，便于对比版本信息流程使用。

(2)对比版本信息：本申请实施例可以根据交换识别报文流程中的识别报文信息，将每一个的车辆品牌和车辆型号与自身识别报文中相同字段做比较，若符合，则进一步比较版本信息字段中，其他车辆版本收集节点的版本信息和自身的版本信息字段中相同项；若无符合项，则既不需要发送也不需要接收，只需释放资源，等待固定时间再次发现周围节点，进行下载流程。

在步骤S102中，接收一个或多个OTA下载节点基于升级请求生成的升级数据帧，其中，每个升级数据帧在升级包中的位置不同。

可以理解的是，本申请实施例可以在判断执行接收流程后，接收满足预设目标条件的OTA下载节点的升级数据帧，以用于后续对本车的升级。

在本申请实施例中，升级数据帧包括升级数据字段和升级数据字段在升级包中的实际偏移量，接收一个或多个OTA下载节点基于升级请求生成的升级数据帧，包括：判断升级包中是否存在与实际偏移量相同的升级数据字段；如果存在，则丢弃升级数据帧，否则根据实际偏移量创建二进制文件，并基于实际偏移量将升级数据字段写入二进制文件中。

其中，二进制文件可以以安装包中的偏移量作为文件名。

举例而言，如图5所示，filename为以安装包名命名的文件夹，其下包括file.info和一系列二进制文件；其中，file.info文件保存文件的相关信息，如校验值，总大小等，二进制文件以在安装包中的偏移量作为文件名，可以储存从该字节开始的数据。

可以理解的是，每一个节点发送的数据报文，本车收到后会根据数据报文中的文件名，找到相对应的文件夹，若文件夹不存在，根据数据报文中的文件名进行创建即可；再根据偏移量和数据长度，判断该段数据是否存在，若存在则否定响应，响应码为数据重复；若不存在，写入文件并回复肯定响应。

具体而言，由于车辆可能处于活动状态，周围节点可能发生变化，因此本申请实施例的数据报文每一帧都是独立的，前一帧数据报文与后一帧数据报文可以没有任何关联，而是可以通过文件名和偏移量，在文件层级上做到报文的序列化。

如图6所示，本申请实施例可以获取不大于数据报文中偏移量的最大文件名，同时获取大于输数报文中偏移量最小的文件名，接着判断是否在以上二者中获取到有效值，如果没有有效值，则以偏移量作为文件名，创建文件并写入数据字段，接着设置肯定相应码并发送肯定相应；如果存在有效值，则进行偏移量和数据长度大小的判断的流程，在此不做过多叙述。

在本申请实施例中，在同时接收多个OTA下载节点发送的升级数据帧时，每个OTA下载节点发送数据的起始位置不同。

可以理解的是，在满足预设目标条件时，即在附近可达节点中有多个节点版本号相同且大于本车的版本号时，则这些节点同时向本车发送该文件，但发送的起始位置不同。

在步骤S103中，根据所有升级数据帧在升级包中的实际位置依次组合得到升级包，并利用升级包升级本车。

可以理解的是，本申请实施例可以根据二进制文件名(即偏移量)从小到大将分散的二进制文件合为安装升级包，并利用该安装升级包对本车进行升级。

在本申请实施例中，根据所有升级数据帧在升级包中的实际位置依次组合得到升级包，包括：根据二进制文件的实际偏移量进行排序，得到排序结果；将二进制文件中升级数据字段按照排序结果依次组合，得到升级包。

其中，本申请实施例可以根据实际情况对二进制文件中升级数据字段进行排序和组合，比如，本申请实施例可以由小到大进行排序组合等，对此不做具体限定。

可以理解的是，如图6所示，本申请实施例可以判断偏移量和数据长度的和值是否大于或等于最大文件名和文件大小的和值，若小于，则设置肯定响应码并发送肯定响应；若大于或等于，则可以判断偏移量和数据长度的和值是否小于或等于最小文件名和文件大小的和值，若小于或等于，则可以对二进制文件名从小到大进行排序，否则将数据字段基于偏移量计算后写入该文件，并设置肯定响应码、发送肯定响应。

在本申请实施例中，在将二进制文件中升级数据字段按照排序结果依次组合之前，包括：根据排序结果判断所有升级数据字段是否为连续字段，如果是，则将二进制文件中升级数据字段按照排序结果依次组合，否则继续接收升级数据帧。

可以理解的是，本申请实施例还可以进一步判断上述根据偏移量的排序结果是否为连续字段，判断数据是否是连续数据，若连续，则可以表明传输数据源过程结束。

根据本申请实施例提出的车辆的OTA升级方法，可以通过与周围OTA下载节点连接，允许汽车OTA下载节点从附近多个可达OTA下载节点中获取升级数据，提高了大文件的传输速率，显著降低云端服务器的压力，节省用户时间；且在没有连接云端OTA服务器的条件下，只要周围存在合适节点，也可进行OTA下载，为OTA安装包从云端到车辆提供了新的通道；同时OTA下载节点发送的是数据帧，因此发送方无需具有完整的升级包，也可将自身已有的数据字段进行发送，以用于OTA升级，降低OTA升级的条件限制，提升用户的升级体验。

基于上一实施例，本申请实施例可以提供另一种车辆的OTA升级方法，用以说明如何进行数据报文的发送，本实施例和上一实施例在描述内容上各有侧重，各实施例之间对于未尽述步骤可相互参考。

图7为本申请实施例所提供的一种车辆的OTA升级方法的流程示意图。

如图7所示，该车辆的OTA升级方法包括以下步骤：

在步骤S201中，接收其他车辆发送的升级请求；

在步骤S202中，根据升级请求识别其他车辆与本车类型相同时，判断本车的升级包版本是否高于其他车辆的升级包版本；

在步骤S203中，如果本车的升级包版本高于其他车辆的升级包版本，则发送升级数据帧至其他车辆，否则，忽略升级请求。

可以理解的是，本申请实施例可以接收其他OTA节点的数据报文，比如可以接收其他车辆的升级请求，在对请求车辆的类型和升级包版本进行识别判断后，若本车升级包版本高于该请求车辆版本，则本申请实施例可以发送升级数据帧至目标请求车辆，以对该车进行升级；如果本车升级包版本不高于请求车辆版本，则忽略请求，不做任何响应动作。

需要说明的是，如图2所示，在本申请实施例可以在判断本车版本高于某OTA下载节点版本时，发送数据报文至该节点。因此，如图8所示，本申请实施例可以在发送数据报文流程开始时首先判断本车是否存在完整的安装包，若存在完整的安装包，优先从完整安装包进行数据字段读取；若不存在完整的安装包，则判断是否存在以安装包文件名命名的文件夹，若存在以安装包文件名命名的文件夹，将本车已有的分段二进制文件数据进行发送，若不存在以安装包文件名命名的文件夹，结束流程。其中，若数据中有否定响应，本申请实施例可以在组成数据报文阶段根据否定响应码动态调整本次发送的数据报文的相关数据，包括但不限于，调整偏移量，使接收方没有此次发送的数据。

根据本申请实施例提出的车辆的OTA升级方法，可以根据其他车辆的升级请求发送升级数据给其他车辆，由于发送的升级数据是以数据帧的形式发送的，因此无需具有完整的安装包，也可将自身已有的数据字段进行发送，有效降低OTA升级的条件限制，为车辆的OTA升级提供了新的升级通道，提升用户的升级体验。

其次参照附图描述根据本申请实施例提出的一个车辆的OTA升级装置。

图9是本申请实施例的一个车辆的OTA升级装置的方框示意图。

如图9所示，该车辆的OTA升级装置10包括：识别模块110、第一接收模块120和升级模块130。

其中，识别模块110用于在识别到本车周围存在满足预设目标条件的至少一个空中下载OTA下载节点时，发送升级请求至每个OTA下载节点；第一接收模块120用于接收一个或多个OTA下载节点基于升级请求生成的升级数据帧，其中，每个升级数据帧在升级包中的位置不同；升级模块130用于根据所有升级数据帧在升级包中的实际位置依次组合得到升级包，并利用升级包升级本车。

在本申请实施例中，第一接收模块120用于：判断升级包中是否存在与实际偏移量相同的升级数据字段；如果存在，则丢弃升级数据帧，否则根据实际偏移量创建二进制文件，并基于实际偏移量将升级数据字段写入二进制文件中。

在本申请实施例中，第一接收模块120进一步用于：在同时接收多个OTA下载节点发送的升级数据帧时，每个OTA下载节点发送数据的起始位置不同。

在本申请实施例中，升级模块130用于：根据二进制文件的实际偏移量进行排序，得到排序结果；将二进制文件中升级数据字段按照排序结果依次组合，得到升级包。

在本申请实施例中，升级模块130进一步用于：根据排序结果判断所有升级数据字段是否为连续字段，如果是，则将二进制文件中升级数据字段按照排序结果依次组合，否则继续接收升级数据帧。

需要说明的是，前述对车辆的OTA升级方法实施例的解释说明也适用于该实施例的车辆的OTA升级装置，此处不再赘述。

根据本申请实施例提出的车辆的OTA升级装置，可以通过与周围OTA下载节点连接，允许汽车OTA下载节点从附近多个可达OTA下载节点中获取升级数据，提高了大文件的传输速率，显著降低云端服务器的压力，节省用户时间；且在没有连接云端OTA服务器的条件下，只要周围存在合适节点，也可进行OTA下载，为OTA安装包从云端到车辆提供了新的通道；同时OTA下载节点发送的是数据帧，因此发送方无需具有完整的升级包，也可将自身已有的数据字段进行发送，以用于OTA升级，降低OTA升级的条件限制，提升用户的升级体验。

图10是本申请实施例的另一个车辆的OTA升级装置的方框示意图。

如图10所示，该车辆的另一个OTA升级装置20包括：识别模块210、第二接收模块220和升级模块230。

其中，第二接收模块210用于接收其他车辆发送的升级请求；判断模块220用于根据升级请求识别其他车辆与本车类型相同时，判断本车的升级包版本是否高于其他车辆的升级包版本；执行模块230用于如果本车的升级包版本高于其他车辆的升级包版本，则发送升级数据帧至其他车辆，否则，忽略升级请求。

需要说明的是，前述对车辆的OTA升级方法实施例的解释说明也适用于该实施例的车辆的OTA升级装置，此处不再赘述。

根据本申请实施例提出的车辆的OTA升级装置，可以根据其他车辆的升级请求发送升级数据给其他车辆，由于发送的升级数据是以数据帧的形式发送的，因此无需具有完整的安装包，也可将自身已有的数据字段进行发送，有效降低OTA升级的条件限制，为车辆的OTA升级提供了新的升级通道，提升用户的升级体验。

图11为本申请实施例提供的车辆的结构示意图。该车辆可以包括：

存储器1101、处理器1102及存储在存储器1101上并可在处理器1102上运行的计算机程序。

处理器1102执行程序时实现上述实施例中提供的车辆的OTA升级方法。

进一步地，车辆还包括：

通信接口1103，用于存储器1101和处理器1102之间的通信。

存储器1101，用于存放可在处理器1102上运行的计算机程序。

存储器1101可能包含高速RAM(Random Access Memory，随机存取存储器)存储器，也可能还包括非易失性存储器，例如至少一个磁盘存储器。

如果存储器1101、处理器1102和通信接口1103独立实现，则通信接口1103、存储器1101和处理器1102可以通过总线相互连接并完成相互间的通信。总线可以是ISA(IndustryStandard Architecture，工业标准体系结构)总线、PCI(Peripheral Component，外部设备互连)总线或EISA(Extended Industry Standard Architecture，扩展工业标准体系结构)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图11中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

可选的，在具体实现上，如果存储器1101、处理器1102及通信接口1103，集成在一块芯片上实现，则存储器1101、处理器1102及通信接口1103可以通过内部接口完成相互间的通信。

处理器1102可能是一个CPU(Central Processing Unit，中央处理器)，或者是ASIC(Application Specific Integrated Circuit，特定集成电路)，或者是被配置成实施本申请实施例的一个或多个集成电路。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上的车辆的OTA升级方法。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不是必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或N个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“N个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更N个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，N个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。如，如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列，现场可编程门阵列等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (10)

1.一种车辆的OTA升级方法，其特征在于，包括以下步骤：

在识别到本车周围存在满足预设目标条件的至少一个空中下载OTA下载节点时，发送升级请求至每个OTA下载节点；

接收一个或多个OTA下载节点基于所述升级请求生成的升级数据帧，其中，每个升级数据帧在升级包中的位置不同；

根据所有升级数据帧在所述升级包中的实际位置依次组合得到所述升级包，并利用所述升级包升级所述本车。

2.根据权利要求1所述的方法，其特征在于，所述升级数据帧包括升级数据字段和所述升级数据字段在所述升级包中的实际偏移量，所述接收一个或多个OTA下载节点基于所述升级请求生成的升级数据帧，包括：

判断所述升级包中是否存在与所述实际偏移量相同的升级数据字段；

如果存在，则丢弃所述升级数据帧，否则根据所述实际偏移量创建二进制文件，并基于所述实际偏移量将所述升级数据字段写入所述二进制文件中。

3.根据权利要求2所述的方法，其特征在于，所述根据所有升级数据帧在所述升级包中的实际位置依次组合得到所述升级包，包括：

根据所述二进制文件的实际偏移量进行排序，得到排序结果；

将所述二进制文件中升级数据字段按照排序结果依次组合，得到所述升级包。

4.根据权利要求3所述的方法，其特征在于，在将所述二进制文件中升级数据字段按照排序结果依次组合之前，包括：

根据所述排序结果判断所有升级数据字段是否为连续字段，如果是，则将所述二进制文件中升级数据字段按照排序结果依次组合，否则继续接收升级数据帧。

5.根据权利要求1-4任意一项所述的方法，其特征在于，在同时接收多个OTA下载节点发送的升级数据帧时，每个OTA下载节点发送数据的起始位置不同。

6.一种车辆的OTA升级方法，其特征在于，包括以下步骤：

接收其他车辆发送的升级请求；

根据所述升级请求识别所述其他车辆与本车类型相同时，判断本车的升级包版本是否高于所述其他车辆的升级包版本；

如果本车的升级包版本高于所述其他车辆的升级包版本，则发送升级数据帧至其他车辆，否则，忽略所述升级请求。

7.一种车辆的OTA升级装置，其特征在于，包括：

识别模块，用于在识别到本车周围存在满足预设目标条件的至少一个空中下载OTA下载节点时，发送升级请求至每个OTA下载节点；

第一接收模块，用于接收一个或多个OTA下载节点基于所述升级请求生成的升级数据帧，其中，每个升级数据帧在升级包中的位置不同；

升级模块，用于根据所有升级数据帧在所述升级包中的实际位置依次组合得到所述升级包，并利用所述升级包升级所述本车。

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

第二接收模块，用于接收其他车辆发送的升级请求；

判断模块，用于根据所述升级请求识别所述其他车辆与本车类型相同时，判断本车的升级包版本是否高于所述其他车辆的升级包版本；

执行模块，用于如果本车的升级包版本高于所述其他车辆的升级包版本，则发送升级数据帧至其他车辆，否则，忽略所述升级请求。

9.一种车辆，其特征在于，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现如权利要求1-5任一项所述的车辆的OTA升级方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行，以用于实现如权利要求1-5任一项所述的车辆的OTA升级方法。

Images