WO2018045700A1

WO2018045700A1 - 一种车载自动诊断系统设备及其升级方法

Info

Publication number: WO2018045700A1
Application number: PCT/CN2017/071008
Authority: WO
Inventors: 梁雷
Original assignee: 中兴通讯股份有限公司
Priority date: 2016-09-07
Filing date: 2017-01-12
Publication date: 2018-03-15
Also published as: CN107809324A; CN107809324B

Abstract

本发明实施例提供了一种车载自动诊断系统设备及其升级方法；该方法包括：调制解调器获取车载自动诊断系统设备的设备升级包；调制解调器将设备升级包拆分为用于对调制解调器进行升级的第一软件包、以及用于对微控制器进行升级的第二软件包，并推送第二软件包至微控制器；微控制器根据第二软件包进行升级。

Description

一种车载自动诊断系统设备及其升级方法

技术领域

本发明涉及车载自动诊断系统设备领域，尤其涉及一种车载自动诊断系统设备车载自动诊断系统(OBD，On-Board Diagnostics)设备及其升级方法、计算机存储介质。

背景技术

随着汽车和互联网产业的快速发展，市场中不断的出现各种新型OBD设备等车载设备，与此同时，车载设备的功能需求方面也在不断的更新，越来越趋于智能化。在进行设备更新时，软件版本都打包在调制解调器(Modem)中，必须是先升级Modem，Modem升级完成之后通过下指令触发微控制器(MCU)升级。

由于在使用时，设备更新往往是针对MCU进行的，实际上不需要对Modem进行升级，因此，现有OBD设备升级方式存在Modem无效升级的问题。

发明内容

为解决现有存在的技术问题，本发明实施例提供了一种OBD设备及其升级方法。

一方面，本发明实施例提供了一种OBD设备的升级方法，OBD包括调制解调器及MCU，升级方法包括：

调制解调器获取OBD设备的设备升级包；

调制解调器将设备升级包拆分为用于对Modem进行升级的第一软件包、以及用于对MCU进行升级的第二软件包；

Modem推送第二软件包至MCU，以使MCU根据第二软件包进行MCU升级。

一方面，本发明实施例提供了一种OBD设备，OBD设备包括Modem及MCU，其中，

Modem，配置为获取OBD设备的设备升级包，将设备升级包拆分为用于对Modem进行升级的第一软件包、以及用于对MCU进行升级的第二软件包，并推送第二软件包至MCU；

MCU，配置为根据第二软件包进行MCU升级。

另一方面，本发明实施例提供了一种计算机存储介质，计算机存储介质中存储有计算机可执行指令，计算机可执行指令用于执行前述的OBD设备的升级方法。

本发明实施例的有益效果：

本发明实施例提供了的方案，在Modem收到数据包时进行拆分获得MCU的软件包，并推送至MCU，使得MCU可以根据软件包直接进行MCU升级，不再需要Modem升级之后来触发MCU升级，实现了Modem升级与MCU升级的解耦，避免了Modem的无效升级。

附图说明

图1为本发明第一实施例提供的OBD设备升级的流程图；

图2为本发明第二实施例提供的OBD设备结构示意图；

图3为本发明第三实施例涉及的Modem升级流程图；

图4为本发明第三实施例涉及的MCU升级流程图；

图5是本发明第三实施例涉及的MCU升级判断流程图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例只是本发明中一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

现通过具体实施方式结合附图的方式对本发明做出进一步的诠释说明。

在本发明的各种实施例中：Modem获取OBD设备的设备升级包；Modem将所述设备升级包拆分为用于对Modem进行升级的第一软件包、以及用于对MCU进行升级的第二软件包；Modem推送所述第二软件包至MCU，以使MCU根据所述第二软件包进行MCU升级。

第一实施例：

图1为本发明第一实施例提供的OBD设备升级方法的流程图，由图1可知，本实施例提供的OBD设备升级方法包括：

S101：Modem获取OBD设备的设备升级包；

S102：Modem将设备升级包拆分为用于对Modem进行升级的第一软件包、以及用于对MCU进行升级的第二软件包；

S103：Modem推送第二软件包至MCU；

S104：MCU根据第二软件包进行MCU升级。

本实施例提供了一种OBD设备升级方法，该方法在Modem收到数据包时进行拆分获得MCU的软件包，并推送至MCU，使得MCU可以根据软件包直接进行MCU升级，不再需要Modem升级之后来触发MCU升级，实现了Modem升级与MCU升级的解耦，避免了Modem的无效升级。

在实际应用中，由于MCU的升级频率远远大于Modem的升级频率，因此，为了避免Modem的无效升级，可以对Modem进行软件/硬件上的改进，这些改进仅需要修改Modem处理设备升级包的处理规则即可，如增加对设备升级包的处理规则字段。现有的处理规则是，Modem接收到设备升级包之后，直接进行Modem升级，然后进行MCU升级，本实施例可以通过对处理规则进行更改，将其更改为：Modem接收到设备升级包之后，解析得到第二软件包，并直接推送到MCU，供MCU进行升级，在MCU升级之后，调制解调器再判断是否需要升级，避免了调制解调器的无效升级，也使得MCU可以在第一时间进行升级。

在一些实施例中，为了兼容现有的升级规则，即优先进行Modem升级，上述实施例中的升级方法在Modem推送第二软件包至MCU之前，还包括：

Modem判断是否需要根据第一软件包进行Modem升级；

若不需要升级，则删除第一软件包，并推送第二软件包至MCU。

本实施例在兼容现有升级规则的同时，也避免了无效升级的出现，简化了升级流程。

具体地，上述实施例中，Modem判断是否需要根据第一软件包进行Modem升级包括：

获取当前的Modem软件版本标识；具体地，可以根据Modem在前一次更新时存储的版本号来确定当前的Modem软件版本标识；

判断当前的Modem软件版本标识与第一软件包的版本标识是否相同；

若相同，则代表着没有对Modem的软件进行更新，进而也就不需要升级；

若不相同，则代表着对Modem的软件进行了更新优化，进而也就需要升级。

在一些实施例中，上述实施例中的升级方法还可以包括：若需要升级，则根据第一软件包进行Modem升级，在进行Modem升级之后，推送第二软件包至MCU。本实施例实现了对现有升级流程的完全兼容。

在一些实施例中，上述实施例中的升级方法，在Modem根据第一软件包进行Modem升级之前，该方法还可以包括：

向MCU发送Modem升级请求；

若接收到不允许Modem升级消息时，暂停升级流程，并周期性地发送Modem升级请求；不允许Modem升级消息为MCU在工作模式时发送的，工作模式包括MCU处于升级状态和/或车辆未处于熄火状态；

若接收到允许Modem升级消息时，进入升级流程；允许Modem升级消息为MCU在非工作模式时发送的，非工作模式包括MCU未处于升级状态且车辆处于熄火状态。

本实施例实现了Modem与MCU不会同时升级的要求，也实现了Modem不会在车辆没有处于熄火状态时进行升级的要求，这样就可以避免现有Modem在车辆运行时进行升级导致的OBD设备与服务器通信中断的问题。

在一些实施例中，上述实施例中的升级方法在MCU根据第二软件包进行MCU升级之前，还可以包括：

MCU根据检测到的车辆运行信息，判断车辆是否处于熄火状态；

若车辆未处于熄火状态，则暂停升级流程，并周期性地判断车辆是否处于熄火状态；

若车辆处于熄火状态，则判断电量是否满足升级要求，若满足，则进入升级流程。

在实际应用中，若在车辆未处于熄火状态时，如正在行驶时，进行MCU的升级，将会导致MCU服务的中断，导致无法采集到安全数据等问题的出现，针对这个缺点，本发明实施例提供的方法中，在进行Modem和MCU在升级之前，都需要判断车辆是否处于熄火状态，避免车辆运行时，OBD设备升级导致的数据采集/传输的中断。

在一些实施例中，上述实施例中的升级方法，在MCU判断车辆处于熄火状态、且电量满足升级要求之后，执行升级流程之前，还包括：

向Modem发送MCU升级请求；

若接收到不允许ModemCU升级消息时，暂停升级流程，并周期性地发送MCU升级请求；不允许MCU升级消息为Modem处于升级状态时发送的；

若接收到允许MCU升级消息时，进入升级流程；允许MCU升级消息为Modem处于非升级状态时发送的。

本实施例实现了MCU与Modem不会同时升级的要求，避免了同时升级导致的设备升级失败的问题。

在一些实施例中，上述实施例中，MCU根据第二软件包进行MCU升级包括：

MCU读取当前的MCU软件版本标识；

判断当前的MCU软件版本标识与第二软件包的版本标识是否相同；

若相同，则MCU退出升级流程；

若不相同，则MCU执行升级流程。

第二实施例：

图2为本发明第二实施例提供的OBD设备的结构示意图，由图2可知，本实施例提供的OBD设备包括：Modem 1及MCU 2，其中，

Modem 1，配置为获取车载自动诊断系统设备的设备升级包，将设备升级包拆分为用于对Modem进行升级的第一软件包、以及用于对MCU进行升级的第二软件包，并推送第二软件包至MCU 2；

MCU 2，配置为根据第二软件包进行MCU升级。

在一些实施例中，上述实施例中的Modem 1，还配置为在推送第二软件包至MCU 2之前，判断是否需要根据第一软件包进行Modem升级，若需要升级，则删除第一软件包，并推送第二软件包至MCU 2，若需要升级，则根据第一软件包进行Modem升级，在进行Modem升级之后，推送第二软件包至MCU 2。

在一些实施例中，上述实施例中的Modem 1在根据第一软件包进行Modem升级之前，还向MCU 2发送Modem升级请求，若接收到不允许Modem升级消息时，暂停升级流程，并周期性地发送Modem升级请求，若接收到允许Modem升级消息时，进入升级流程；允许Modem升级消息为MCU 2在非工作模式时发送，非工作模式包括MCU未处于升级状态且车辆处于熄火状态，不允许Modem升级消息为MCU 2在工作模式时发送，工作模式包括MCU处于升级状态和/或车辆未处于熄火状态。

在一些实施例中，上述实施例中的MCU 2在根据第二软件包进行MCU升级之前，还根据检测到的车辆运行信息，判断车辆是否处于熄火状态；若车辆未处于熄火状态，则暂停升级流程，并周期性地判断车辆是否处于熄火状态；若车辆处于熄火状态，则判断电量是否满足升级要求，若满足，则进入升级流程。

在一些实施例中，上述实施例中的MCU 2在判断车辆处于熄火状态、且电量满足升级要求之后，执行升级流程之前，还配置为向Modem 1发送MCU升级请求；若接收到不允许MCU升级消息时，暂停升级流程，并周期性地发送MCU升级请求，若接收到允许MCU升级消息时，进入升级流程；允许MCU升级消息为Modem处于非升级状态时发送的，不允许MCU升级消息为Modem处于升级状态时发送的。

第三实施例：

现结合具体应用场景对本发明实施例做进一步的诠释说明。

现有的OBD软件版本都打包在Modem中，必须是先升级Modem，Modem升级完成之后通过下指令触发MCU升级，设备需要在汽车点火之后才能升级，会影响用户体验；MCU的BOOT管脚链接到Modem上，可以通过Modem作为主控来控制MCU；软件版本更新必须先升级Modem版本，再升级MCU，即使Modem侧软件无内容更新，仅需要更新MCU侧软件版本也得先启动Modem升级流程，完成Modem侧升级后再触发MCU侧的版本更新。

针对上述的问题，本实施例提供了新的OBD设备升级方法，该方法为Modem负责下载软件版本，解析下载的版本并将版本分类，将MCU版本推送至MCU侧，同时判断Modem部分软件是否需要更新，无更新时Modem不启动版本更新流程。MCU侧自行判断版本更新条件决定是否进入升级模式。同时，升级的触发条件为MCU检查车辆的状态是否达到熄火条件，升级必须在熄火之后进行。并且，Modem和MCU不能同时升级，Modem及MCU升级时均需及时通知对方，等待对方作出对应地状态调整后在进入下一步的流程。

该OBD设备为车载产品由Modem和MCU两块主板组成，Modem和MCU硬件通过连接器连接，可以满足软件的链接业务。用户软件更新由设备自动完成，无需手动操作。为了不影响用户体验，版本升级在车辆熄火的条件下进行且Modem和MCU不能同时升级，Modem及MCU升级时均需及时通知对方，等待对方作出对应的状态调整后再进入下一步的流程。升级分为Modem和MCU两部分，接下来从版本的获取方式及获取的版本处理方式、MCU的判断升级条件及MCU的升级流程、Modem的升级流程分别介绍整个升级的过程。

本实施例提供的OBD设备升级方法，包括以下步骤：

Modem下载版本及版本的处理：

Modem设置的轮回时间为24小时，每隔24小时设备会从服务器上查询是否有匹配的集成软件版本需要更新。服务器首先会连接设备获取到设配当前的集成版本号与服务器的版本号做对比，如果不一致则自动下载软件包(服务器只存储最新的集成版本)，软件包下载完成之后，Modem将软件包通过解压的方式解析，将集成版本内部的两个版本释放出来，两个版本为Modem的A版本和MCU的B版本，Modem会用校验版本名称的方式去判别是Modem还是MCU的版本，以A开头的为Modem版本，以B开头的为MCU版本。先将B版本的信息通过AT命令推送给MCU侧，对B这个版本仅仅是做推送动作，随后处理A，首先Modem会将当前设备的A版本号读出与已下载的A版本号进行比对，如果版本号不一致则启动Modem升级流程，如果版本号一致则终止Modem版本更新流程，同时删除A软件包。

MCU判断升级条件及MCU升级流程：

如图4及如5所示，Modem推送B版本至MCU，记录MCU升级标志位，MCU检测到车辆熄火后主动上报熄火及采集的用户信息至服务器，如果MCU判定设备没有熄火正处于正常工作状态，不能中断正常工作而去升级。熄火信息上报完成之后随即检查当前的设备是否准备进入休眠模式及读取电瓶的电量是否满足升级需求，如电量不满足则进入休眠，电量满足的话获取MCU升级标志位，MCU判断B版本是否与当前的版本号不一致，如一致则终止升级流程、删除软件包并反馈给Modem，如版本号不一致则启动升级流程，向Modem发出升级请求，如Modem没有处于升级状态则反馈允许升级信息，MCU重启进入基本输入输出系统(BIOS)开始升级应用程序(APP)，升级后参数及存储数据没有变化及损失。升级成功后向MCU上报升级结果，检测车辆是否点火，如果车辆点火则设备开始进入正常工作模式，如没点火则等待进入休眠模式。MCU升级中车辆点火启动，设备不作出任何反应，升级完成后启动APP进入正常模式，开始正常上报信息。

Modem升级流程：

如图3所示，Modem确认当前下载的A版本符合Modem升级条件则启动升级流程，先向MCU发送升级请求，如MCU判断设备处于正常工作模式，则反馈不允许升级的信息，非工作模式反馈允许升级信息。Modem收到MCU回应可以启动升级的指令后启动升级，先升级EFS文件再升级RECOVERY，两者升级成功(OK)后重启Modem进入RECOVERY升级SYSTEM，SYSTEM升级完成后再重启Modem进入SYSTEM同时删除软件包，然后向MCU上报升级的结果结束，Modem升级流程。Modem升级过程中需要重启两次，升级后除版本号外其余参数与升级前保持一致。如果Modem升级过程中车辆点火启动，MCU会将上报的数据先缓存起来，等到Modem升级完成后再连上服务器(SERVER)，Modem升级的时候MCU不能升级。

本实施例提供一种升级方法，可以自动判断Modem和MCU的版本是否有更新，仅对有更新的对象进行升级，免去不必要的升级浪费，同时熄火升级的条件会带来更好的用户体验。

综上可知，通过本发明实施例的实施，至少存在以下有益效果：

本发明实施例提供了提供的方案，在Modem收到数据包时进行拆分获得MCU的软件包，并推送至MCU，使得MCU可以根据软件包直接进行MCU升级，不再需要Modem升级之后来触发MCU升级，实现了Modem升级与MCU升级的解耦，避免了Modem的无效升级。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上仅是本发明的具体实施方式而已，并非对本发明做任何形式上的限制，凡是依据本发明的技术实质对以上实施方式所做的任意简单修改、等同变化、结合或修饰，均仍属于本发明技术方案的保护范围。

工业实用性

Claims

一种车载自动诊断系统设备的升级方法，所述车载自动诊断系统设备包括调制解调器及微控制器，所述升级方法包括：

所述调制解调器获取所述车载自动诊断系统设备的设备升级包；

所述调制解调器将所述设备升级包拆分为用于对所述调制解调器进行升级的第一软件包、以及用于对所述微控制器进行升级的第二软件包；

所述调制解调器推送所述第二软件包至所述微控制器；

所述微控制器根据所述第二软件包进行微控制器升级。
如权利要求1所述的升级方法，其中，在所述调制解调器推送所述第二软件包至所述微控制器之前，所述升级方法还包括：

所述调制解调器判断是否需要根据所述第一软件包进行调制解调器升级；

当不需要升级时，删除所述第一软件包，并推送所述第二软件包至所述微控制器。
如权利要求2所述的升级方法，其中，所述调制解调器判断是否需要根据所述第一软件包进行调制解调器升级，包括：

获取当前的调制解调器软件版本标识；

判断所述当前的调制解调器软件版本标识与所述第一软件包的版本标识是否相同；

若相同，则不需要升级；

若不相同，则需要升级。
如权利要求2所述的升级方法，其中，所述升级方法还包括：当需要升级时，根据所述第一软件包进行调制解调器升级，在进行调制解调器升级之后，推送所述第二软件包至所述微控制器。
如权利要求4所述的升级方法，其中，所述调制解调器根据所述第一软件包进行调制解调器升级之前，所述升级方法还包括：

向所述微控制器发送调制解调器升级请求；

若接收到不允许调制解调器升级消息时，暂停升级流程，并周期性地发送所述调制解调器升级请求；所述不允许调制解调器升级消息为所述微控制器在工作模式时发送的，所述工作模式包括所述微控制器处于升级状态和/或车辆未处于熄火状态；

若接收到允许调制解调器升级消息时，进入升级流程；所述允许调制解调器升级消息为所述微控制器在非工作模式时发送，所述非工作模式包括所述微控制器未处于升级状态且车辆处于熄火状态。
如权利要求1至5任一项所述的升级方法，其中，所述微控制器根据所述第二软件包进行微控制器升级之前，所述升级方法还包括：

根据检测到的车辆运行信息，判断车辆是否处于熄火状态；

若车辆未处于熄火状态，则暂停升级流程，并周期性的判断车辆是否处于熄火状态；

若车辆处于熄火状态，则判断电量是否满足升级要求，若满足，则进入升级流程。
如权利要求6所述的升级方法，其中，所述微控制器判断车辆处于熄火状态、且电量满足升级要求之后，执行升级流程之前，所述升级方法还包括：

向所述调制解调器发送微控制器升级请求；

若接收到不允许微控制器升级消息时，暂停升级流程，并周期性地发送所述微控制器升级请求；所述不允许微控制器升级消息为所述调制解调器处于升级状态时发送的；

若接收到允许微控制器升级消息时，进入升级流程；所述允许微控制器升级消息为所述调制解调器处于非升级状态时发送的。
如权利要求6所述的升级方法，其中，所述微控制器根据所述第二软件包进行微控制器升级，包括：

微控制器读取当前的微控制器软件版本标识；

判断所述当前的微控制器软件版本标识与所述第二软件包的版本标识是否相同；

若相同，则所述微控制器退出升级流程；

若不相同，则所述微控制器执行升级流程。
一种载自动诊断系统设备，所述车载自动诊断系统设备包括调制解调器及微控制器，其中，

所述调制解调器，配置为获取所述车载自动诊断系统设备的设备升级包，将所述设备升级包拆分为用于对所述调制解调器进行升级的第一软件包、以及用于对所述微控制器进行升级的第二软件包，并推送所述第二软件包至所述微控制器；

所述微控制器，配置为根据所述第二软件包进行微控制器升级。
如权利要求9所述的载自动诊断系统设备，其中，所述调制解调器还配置为，在推送所述第二软件包至所述微控制器之前，判断是否需要根据所述第一软件包进行调制解调器升级，若需要升级，则删除所述第一软件包，并推送所述第二软件包至所述微控制器，若需要升级，则根据所述第一软件包进行调制解调器升级，在进行调制解调器升级之后，推送所述第二软件包至所述微控制器。
如权利要求10所述的载自动诊断系统设备，其中，所述调制解调器，配置为根据所述第一软件包进行调制解调器升级之前，向所述微控制器发送调制解调器升级请求，若接收到不允许调制解调器升级消息时，暂停升级流程，并周期性地发送所述调制解调器升级请求，若接收到允许调制解调器升级消息时，进入升级流程；所述允许调制解调器升级消息为所述微控制器在非工作模式时发送的，所述非工作模式包括所述微控制器未处于升级状态且车辆处于熄火状态，所述不允许调制解调器升级消息为所述微控制器在工作模式时发送的，所述工作模式包括所述微控制器处于升级状态和/或车辆未处于熄火状态。
如权利要求9至11任一项所述的载自动诊断系统设备，其中，所述微控制器，还配置为根据所述第二软件包进行微控制器升级之前，根据检测到的车辆运行信息，判断车辆是否处于熄火状态；若车辆未处于熄火状态，则暂停升级流程，并周期性地判断车辆是否处于熄火状态；若车辆处于熄火状态，则判断电量是否满足升级要求，若满足，则进入升级流程。
如权利要求12所述的载自动诊断系统设备，其中，所述微控制器，还配置为在判断车辆处于熄火状态、且电量满足升级要求之后，向所述调制解调器发送微控制器升级请求；若接收到不允许微控制器升级消息时，暂停升级流程，并周期性地发送所述微控制器升级请求，若接收到允许微控制器升级消息时，进入升级流程；所述允许微控制器升级消息为所述调制解调器处于非升级状态时发送的，所述不允许微控制器升级消息为所述调制解调器处于升级状态时发送的。