一种基于订阅发布模式的车辆OTA升级系统和方法

摘要

本发明涉及一种基于订阅发布模式的车辆OTA升级系统和方法，系统包括OTA云端管理平台、服务器和若干客户端；所述服务器包括信息协调器，若干客户端之间通过信息协调器相互通信，与信息协调器直接通信连接的各客户端之间通过对指定主题的订阅发布模式通信。这样，让OTA系统的各个节点不必关注通信对象的类型、链路等细节，只需要关注通信的主题即可，这使得系统具有很强的平台化能力，便于不同车型平台移植。订阅发布的通信模式，可以做到信息从发布节点到订阅节点的主动推送，避免了传统C/S（Client/Server）模式大量周期性查询的通信报文，因此降低了通信的冗余数据，同时提高了信息的实时性。

说明书

技术领域

本发明属于通信技术领域，具体涉及一种基于订阅发布模式的车辆OTA升级系统和方法。

背景技术

目前行业内，在车辆OTA系统结构中，升级主控节点(Master)与其他子控制节点(SubMaster)或被升级对象(Object)的OTA过程控制，大多通过各厂商的私有协议或部分通用诊断协议完成。不论是私有协议还是通用协议，升级主控节点和被刷节点之间的通信都是基于C/S(Client/Server)模式的，如图1所示。

目前的系统模式有如下问题：

1)系统扩展性受限，平台化能力差，节点增删需要修改Client与Server两端软件。现有的OTA节点间的C/S架构是典型基于“请求/响应”模式的通信机制，控制节点与被控制节点无法解耦，且由于车辆本地通信网络类型多样，升级主控节点和其他节点之间的通信可能通过以太网、CAN、LIN等，每当有节点增加或删除，亦或切换车型平台，都需要变动主控节点和其他节点两端的软件。

2)通信冗余，数据量大。由于请求只能是主控节点发起，因此在OTA过程控制的通信中，难以避免主控节点频繁对其他节点周期性发送查询报文的场景，这极大地增加了通信的冗余。这对于在CAN、LIN等车端带宽受限的通信链路上实现控制通信是极为不利的。

3)通信容错能力不足。现有的OTA节点间的C/S架构是典型基于“请求/响应”模式点对点通信，通信容错需要通过双方软件协议上约定来实现，特别是离线数据无法找回。如：当一个控制器被拔下或部分通信链路异常，这个时候主控节点发送给该控制器的数据自然无法被该控制器接收，等到控制器再次插上或链路恢复的时候，主控节点发送给该控制器的关键数据已经无法找回。

4)并行控制不易。目前并行部署、并行安装是影响车辆OTA性能的关键技术，但是基于目前的系统架构，主控节点在软件上实现并行管理逻辑复杂，需要同时建立多条链路且性能开销也非常大。

发明内容

针对现有技术的上述不足，本发明要解决的技术问题是提供一种基于订阅发布模式的车辆OTA升级系统和方法，避免目前业界OTA系统中固有的系统扩展性受限、平台化能力差、通信冗余数据量大、通信容错能力不足以及并行控制不易的问题。

为解决上述技术问题，本发明采用如下技术方案：

一种基于订阅发布模式的车辆OTA升级系统，包括OTA云端管理平台、服务器和若干客户端；所述服务器包括信息协调器，若干客户端之间通过信息协调器相互通信，与信息协调器直接通信连接的各客户端之间通过对指定主题的订阅发布模式通信；

除信息协调器之外的任一客户端既可以是信息的订阅者也可以是信息的发布者，各客户端与信息协调器通信连接后，任一与信息协调器直接通信连接的客户端与信息协调器连接后均会创建一个独立的会话，每个会话内包括对若干主题的订阅；

当作为发布者的客户端发布指定主题的消息时，信息协调器将该消息主动推送给订阅该指定主题的作为订阅者的客户端。

进一步完善上述技术方案，所述信息协调器用于解耦消息的订阅者和发布者、进行消息的发布与分发，用于对主题、订阅者以及发布者的关系进行集中维护，用于动态管理各客户端的接入与拔出、动态创建主题、进行会话管理和维护离线数据，还用于与客户端相配合提供不同的通信质量服务。

进一步地，所述若干客户端包括车端主控节点和若干升级对象，车端主控节点与信息协调器直接通信连接，与信息协调器直接通信连接的升级对象与车端主控节点之间通过订阅发布模式进行通信。

进一步地，所述若干客户端还包括子控节点，子控节点与信息协调器之间直接通信连接，部分升级对象与信息协调器直接通信连接，部分升级对象与子控节点直接通信连接；与信息协调器直接通信连接的升级对象与车端主控节点之间通过订阅发布模式进行通信，与子控节点直接通信连接的升级对象与子控节点之间通过C/S模式进行通信。

进一步地，所述通信质量服务包括最多一次、最少一次和只有一次；

所述最多一次指信息的发布者向信息协调器仅传输一次消息，信息协调器向信息的订阅者仅推送一次该消息，不保证消息成功地从发布者传输到订阅者；

所述最少一次指确保发布者向订阅者成功传输一次消息；

所述只有一次指确保订阅者只接收到消息一次。

本发明还涉及一种基于订阅发布模式的车辆OTA升级方法，本方法基于上述的一种基于订阅发布模式的车辆OTA升级系统而进行，包括如下步骤：

S1：车端主控节点读取各个升级对象的版本信息；

S2：基于步骤S1获取的版本信息，车端主控节点向OTA云端管理平台请求更新信息；

S3：车端主控节点根据从云端获取的更新信息，下载更新软件包；

S4：车端主控节点将更新软件包部署到与信息协调器直接通信连接的升级对象；

S5：车端主控节点控制更新软件包安装，与信息协调器直接通信连接的升级对象执行对应更新软件包的安装；

所述步骤S1、S4和S5中车端主控节点和各与信息协调器直接通信连接的升级对象之间通过对指定主题的订阅发布模式实现通信。

进一步完善上述技术方案，所述步骤S1中，

车端主控节点作为版本信息的订阅者，与信息协调器直接通信连接的升级对象作为版本信息的发布者，车端主控节点收集到所有升级对象的版本信息后，进入步骤S2。

进一步地，所述步骤S4中，

车端主控节点向与信息协调器直接通信连接的升级对象传输更新软件包，传输过程中，车端主控节点作为更新软件包数据的发布者，与信息协调器直接通信连接的升级对象作为更新软件包数据的订阅者；车端主控节点每发布一包数据，作为订阅者的升级对象则接收到一包数据，直至更新软件包传输完毕。

进一步地，所述步骤S5中，

更新软件包安装过程中，与信息协调器直接通信连接的升级对象订阅车端主控节点发布的安装指令，并执行安装指令；车端主控节点订阅该升级对象发布的安装状态数据，并观察其状态。

相比现有技术，本发明具有如下有益效果：

1、本发明的一种基于订阅发布模式的车辆OTA升级系统，车端参与OTA功能的各个节点通过信息协调器相互通信。各个OTA节点之间的消息传递与交换通过对消息类型主题的订阅发布模式实现。这样，让OTA系统的各个节点不必关注通信对象的类型、链路等细节，只需要关注通信的主题即可，这使得系统具有很强的平台化能力，便于不同车型平台移植。订阅发布的通信模式，可以做到信息从发布节点到订阅节点的主动推送，避免了传统C/S(Client/Server)模式大量周期性查询的通信报文，因此降低了通信的冗余数据，同时提高了信息的实时性。

2、本发明的一种基于订阅发布模式的车辆OTA升级系统，由于信息协调器具有动态管理节点的插入拔出及动态创建主题能力，故系统的可扩展性能极好，因为增删一个节点，只需要对其对应的主题进行增删即可，完全不必修改节点的软件代码；同时由于信息协调器可以维护节点间的离线数据，即使本发明的系统中某一节点被拔出或因通信链路一时故障不能接收其他节点数据，当再次被插入或链路恢复的时候，依然可以从信息协调器获取到离线数据，故而系统具有很好的容错能力。

3、本发明的一种基于订阅发布模式的车辆OTA升级系统和方法，将订阅发布模式应用到车端OTA升级，由于车端主控节点与其他升级对象之间的通信抽象成了面向主题的通信，因此车端主控节点在进行并行部署和升级安装的时候不必再关注与对端节点具体类型的通信模块调用与维护，这大大简化车端主控节点并行控制的逻辑，降低并行控制的难度。

附图说明

图1为现有基于C/S(Client/Server)模式的车辆OTA系统架构图

图2为本发明中订阅发布模式下消息的发布与分发的示意图；

图3为实施例1的一种基于订阅发布模式的车辆OTA升级系统的架构图；

图4为实施例2的一种基于订阅发布模式的车辆OTA升级系统的架构图。

具体实施方式

下面结合附图对本发明的具体实施方式作进一步的详细说明。

请参见图3-图4，具体实施例的一种基于订阅发布(Sub/Pub)模式的车辆OTA升级系统，包括OTA云端管理平台(OTA Cloud Platform)、服务器和若干客户端；所述服务器包括信息协调器(Broker)，若干客户端之间通过信息协调器相互通信，与信息协调器直接通信连接的各客户端之间通过对指定主题的订阅发布模式通信；除信息协调器之外的任一客户端既可以是信息的订阅者也可以是信息的发布者，各客户端与信息协调器通信连接后，任一与信息协调器直接通信连接的客户端与信息协调器连接后均会创建一个独立的会话，每个会话内包括对若干主题的订阅；当作为发布者的客户端发布指定主题的消息时，信息协调器将该消息主动推送给订阅该指定主题的作为订阅者的客户端。

实施例的一种基于订阅发布模式的车辆OTA升级系统，车端参与OTA功能的各个节点通过信息协调器相互通信。各个OTA节点之间的消息传递与交换通过对消息类型主题的订阅发布模式实现。这样，让OTA系统的各个节点不必关注通信对象的类型、链路等细节，只需要关注通信的主题即可，这使得系统具有很强的平台化能力，便于不同车型平台移植。订阅发布的通信模式，可以做到信息从发布节点到订阅节点的主动推送，避免了传统C/S(Client/Server)模式大量周期性查询的通信报文，因此降低了通信的冗余数据，同时提高了信息的实时性。

实施时，如图2所示，订阅发布模式的实现步骤具体如下：

S1：升级对象连接到Broker，Broker创建会话；Master、SubMaster、Object等各客户端节点首先连接到Broker，Broker创建与节点的会话每个节点和Broker之间连接后都会创建一个独立的会话，每个会话可以包含对多个主题的订阅。

S2：消息发布与分发；当Broker与节点之间建立了会话、完成了主题的订阅后，就可以进行消息的发布和分发了。

图2中，当Master、Object_1、Object_2分别与Broker创建会话后，Broker中创建了三个主题T1/T2/T3，其中T1的发布者是Master，订阅者是Object_1、Object_2，故而当Master发布T1主题的消息的时候，Broker会同时将消息推送给Object_1、Object_2；T2的发布者是Object_1，订阅者是Master，当Object_1发布主题T2的消息时，Broker会将消息推送给Master；T3的发布者是Object_2，订阅者是Master，当Object_2发布主题T3的消息时，Broker会将消息推送给Master；综上，可以看出Master和其他客户端节点通信可以是一对多、多对一、一对一。

请继续参见图3和图4，所述信息协调器用于解耦消息的订阅者和发布者、进行消息的发布与分发，用于对主题、订阅者以及发布者的关系进行集中维护，用于动态管理各客户端的接入与拔出、动态创建主题、进行会话管理和维护离线数据，还用于与客户端相配合提供不同的通信质量服务。

这样，由于信息协调器具有动态管理节点的插入拔出及动态创建主题能力，故系统的可扩展性能极好，因为增删一个节点，只需要对其对应的主题进行增删即可，完全不必修改节点的软件代码；同时由于信息协调器可以维护节点间的离线数据，即使本发明的系统中某一节点被拔出或因通信链路一时故障不能接收其他节点数据，当再次被插入或链路恢复的时候，依然可以从信息协调器获取到离线数据，故而系统具有很好的容错能力。

其中，所述通信质量服务包括最多一次、最少一次和只有一次；

所述最多一次指信息的发布者向信息协调器仅传输一次消息，信息协调器向信息的订阅者仅推送一次该消息，不保证消息成功地从发布者传输到订阅者；

所述最少一次指确保发布者向订阅者成功传输一次消息，在这个过程中，发布者可能会向信息协调器传输多次消息，直到接收到订阅者确认信号，订阅者有可能接收到重复消息；

所述只有一次指发布者向订阅者成功传输消息一次，发布者有可能会重发消息，但确保订阅者只接收到一次消息，不会接收到重复消息。

本发明还提供一种基于订阅发布模式的车辆OTA升级方法，本方法基于上述的一种基于订阅发布模式的车辆OTA升级系统而进行，包括如下步骤：

S1：车端主控节点读取各个升级对象的版本信息；

S2：基于步骤S1获取的版本信息，车端主控节点向OTA云端管理平台请求更新信息；

S3：车端主控节点根据从云端获取的更新信息，下载更新软件包；

S4：车端主控节点将更新软件包部署到与信息协调器直接通信连接的升级对象；

S5：车端主控节点控制更新软件包安装，与信息协调器直接通信连接的升级对象执行对应更新软件包的安装；

所述步骤S1、S4和S5中车端主控节点和各与信息协调器直接通信连接的升级对象之间通过对指定主题的订阅发布模式实现通信。

其中，所述步骤S1中，

车端主控节点作为版本信息的订阅者，与信息协调器直接通信连接的升级对象作为版本信息的发布者，车端主控节点收集到所有升级对象的版本信息后，进入步骤S2。

所述步骤S4中，

车端主控节点向与信息协调器直接通信连接的升级对象传输更新软件包，传输过程中，车端主控节点作为更新软件包数据的发布者，与信息协调器直接通信连接的升级对象作为更新软件包数据的订阅者；车端主控节点每发布一包数据，作为订阅者的升级对象则接收到一包数据，直至更新软件包传输完毕。

所述步骤S5中，

更新软件包安装过程中，与信息协调器直接通信连接的升级对象订阅车端主控节点发布的安装指令，并执行安装指令；车端主控节点订阅该升级对象发布的安装状态数据，并观察其状态。

请参见图3，实施例1：

本实施例公开了一种基于订阅发布模式的车辆OTA升级系统及其升级方法，所述若干客户端包括车端主控节点(Master)和若干升级对象，车端主控节点与信息协调器直接通信连接，与信息协调器直接通信连接的升级对象(Object)与车端主控节点之间通过订阅发布模式进行通信。

在本实施例的一种基于订阅发布模式的车辆OTA升级系统中，Broker通常位于车辆上具有报文路由功能控制器上，比如：网关、域控制器等；Master通常位于车辆连接移动网络的控制器上，比如车载主机、TBOX等；Object可以为车辆子网络上的任意支持软件包持久化存储的控制器节点。

实施时，升级方法的具体步骤如下：

S1：Master读取各个Object的版本信息：Master作为版本信息的订阅者，Object作为版本信息的发布者，Object向Master发布自身的版本信息，当Master将本地所有Object的版本信息收集完毕后，执行步骤S2；

S2：基于当前收集到的版本信息，Master以这些版本信息为参数，向OTA云端管理平台请求更新信息，OTA云端管理平台通过对比版本号大小判定是否有版本更新，如果有更新，则下发更新信息，执行步骤S3；反之则退出OTA更新；

S3：Master根据从OTA云端管理平台获取的更新信息，下载更新软件包；

S4：Master将更新软件包部署到Object；Master向Object传输更新软件包数据，传输文件过程中，Master作为更新软件包数据的发布者，Object作为更新软件包数据的订阅者，Master每发布一包数据，Object则接收到一包数据，如此循环直到更新软件包传输完毕；

S5：Master控制更新软件包的安装，Object执行软件更新包的安装；安装过程中，Object订阅Master发布的安装指令，并执行安装指令，Master订阅Object发布的安装状态数据，并观察升级对象状态。

请参见图4，实施例2：

本实施例公开了一种基于订阅发布模式的车辆OTA升级系统及其升级方法，所述若干客户端还包括子控节点(Submaster)，子控节点与信息协调器之间直接通信连接，部分升级对象与信息协调器直接通信连接，部分升级对象与子控节点直接通信连接；与信息协调器直接通信连接的升级对象与车端主控节点之间通过订阅发布模式进行通信，与子控节点直接通信连接的升级对象与子控节点之间通过C/S模式进行通信。

所述C/S模式指的是Client/Server模式，为现有技术，故不多加赘述。

在本实施例的一种基于订阅发布模式的车辆OTA升级系统中，Broker通常位于车辆上具有转发路由功能控制器上，比如：网关、域控制器等；Master通常位于车辆连接移动网络的控制器上，比如车载主机、TBOX等；SubMaster通常位于搭载操作系统的控制器上，这种控制器通常与多个Object在同一子网络，如车载主机、TBOX、域控制器等；Object通常是不搭载操作系统的MCU，不支持软件包的持久存储，与其对应的SubMaster在同一子网络，SubMaster直接对其进行刷写。

实施时，升级方法的具体步骤如下：

S1：Master读取本地各个升级对象(包括SubMaster和Object)的版本信息；Master作为版本信息的订阅者，SubMaster作为版本信息的发布者，当SubMaster收集到升级对象Object以及自身的版本信息后，向Master发布收集到的所有版本信息，当Master将本地所有升级对象的版本信息收集完毕后，执行步骤S2；

S2：基于当前收集到的版本信息，Master以这些版本信息为参数，向OTA云端管理平台请求更新信息，OTA云端管理平台通过对比版本号大小判定是否有版本更新，如果有更新，则下发更新信息，执行步骤S3；反之则退出OTA更新；

S3：Master根据从OTA云端管理平台获取的更新信息，下载更新软件包；

S4：Master将更新包部署到SubMaster；Master向SubMaster传输更新软件包文件，传输文件过程中，Master作为更新软件包数据的发布者，SubMaster作为更新软件包数据的订阅者，Master每发布一包数据，SubMaster则接收到一包数据，如此循环直到更新软件包传输完毕；

S5：Master控制更新软件包的安装，SubMaster执行更新软件包的安装：安装过程中，SubMaster订阅Master发布的安装指令，并执行安装指令，Master订阅SubMaster发布的安装状态数据，并观察升级对象状态。

上述两个实施例，将订阅发布模式应用到车端OTA升级，由于Master与SubMaster、Object之间的通信抽象成了面向主题的通信，因此Master在进行并行部署和升级安装的时候不必再关注与对端节点具体类型的通信模块调用与维护，这大大简化Master并行控制的逻辑，降低并行控制的难度。

根据上述提供的两个实施例，本发明所提及的指定主题如下表所示：

最后说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或者等同替换，而不脱离本发明技术方案的宗旨和范围，其均应涵盖在本发明的权利要求范围当中。