本发明涉及车载自动诊断系统设备领域，尤其涉及一种车载自动诊断系统设备及其升级方法。
背景技术：
随着汽车和互联网产业的快速发展，市场中不断的出现各种新型obd(on-boarddiagnostics，车载自动诊断系统设备)等车载设备，与此同时，车载设备的功能需求方面也在不断的更新，越来越趋于智能化。在进行设备更新时，软件版本都打包在调制解调器modem中，必须是先升级modem，modem升级完成之后通过下指令触发微控制器mcu升级。
由于在使用时，设备更新往往是针对微控制器mcu进行的，实际上不需要对modem进行升级，因此，现有obd升级方式存在modem无效升级的问题。
技术实现要素：
本发明实施例提供了一种车载自动诊断系统设备及其升级方法，以解决现有obd升级方式存在的modem无效升级的问题。
一方面，提供了一种用于车载自动诊断系统设备的升级方法，车载自动诊断系统设备包括调制解调器及微控制器，升级方法包括：
调制解调器获取车载自动诊断系统设备的设备升级包；
调制解调器将设备升级包拆分为用于对调制解调器进行升级的第一软件包、以及用于对微控制器进行升级的第二软件包；
调制解调器推送第二软件包至微控制器；
微控制器根据第二软件包进行微控制器升级。
一方面，提供了一种载自动诊断系统设备，其特征在于，车载自动诊断系统设备包括调制解调器及微控制器，其中，
调制解调器用于获取车载自动诊断系统设备的设备升级包，将设备升级包拆分为用于对调制解调器进行升级的第一软件包、以及用于对微控制器进行升级的第二软件包，并推送第二软件包至微控制器；
微控制器用于根据第二软件包进行微控制器升级。
另一方面，提供了一种计算机存储介质，计算机存储介质中存储有计算机可执行指令，计算机可执行指令用于执行前述的obd升级方法。
本发明实施例的有益效果：
本发明实施例提供了一种obd升级方法，该方法在modem收到数据包时进行拆分获得mcu的软件包，并推送至mcu，使得mcu可以根据软件包直接进行mcu升级，不再需要modem升级之后来触发mcu升级，实现了modem升级与mcu升级的解耦，避免了modem的无效升级。
附图说明
图1为本发明第一实施例提供的obd升级的流程图；
图2为本发明第二实施例提供的obd设备的结构示意图；
图3为本发明第三实施例涉及的modem升级流程图；
图4为本发明第三实施例涉及的mcu升级流程图；
图5是本发明第三实施例涉及的mcu升级判断流程图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例只是本发明中一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
现通过具体实施方式结合附图的方式对本发明做出进一步的诠释说明。
第一实施例：
图1为本发明第一实施例提供的obd升级方法的流程图，由图1可知，本实施例提供的obd升级方法包括：
s101：调制解调器获取车载自动诊断系统设备的设备升级包；
s102：调制解调器将设备升级包拆分为用于对调制解调器进行升级的第一软件包、以及用于对微控制器进行升级的第二软件包；
s103：调制解调器推送第二软件包至微控制器；
s104：微控制器根据第二软件包进行微控制器升级。
本实施例提供了一种obd升级方法，该方法在modem收到数据包时进行拆分获得mcu的软件包，并推送至mcu，使得mcu可以根据软件包直接进行mcu升级，不再需要modem升级之后来触发mcu升级，实现了modem升级与mcu升级的解耦，避免了modem的无效升级。
在实际应用中，由于mcu的升级频率远远大于调制解调器的升级频率，因此，为了避免调制解调器的无效升级，可以对调制解调器进行软件/硬件上的改进，这些改进仅需要修改调制解调器处理设备升级包的处理规则即可，如增加对设备升级包的处理规则字段。现有的处理规则是，调制解调器在接收到设备升级包之后，直接进行调制解调器升级，然后进行mcu升级，本实施例可以通过对处理规则进行更改，将其更改为：调制解调器在接收到设备升级包之后，解析得到第二软件包，并直接推送到mcu，供mcu进行升级，在mcu升级之后，调制解调器再判断是否需要升级，避免了调制解调器的无效升级，也使得mcu可以在第一时间进行升级。
在一些实施例中，为了兼容现有的升级规则，即优先进行调制解调器升级，上述实施例中的升级方法在调制解调器推送第二软件包至微控制器之前，还包括：
调制解调器判断是否需要根据第一软件包进行调制解调器升级；
若不需要升级，则删除第一软件包，并推送第二软件包至微控制器。
本实施例在兼容现有升级规则的同时，也避免了无效升级的出现，简化了升级流程。
具体的，上述实施例中的调制解调器判断是否需要根据第一软件包进行调制解调器升级包括：
获取当前的调制解调器软件版本标识；具体的，可以根据调制解调器在前一次更新时存储的版本号来确定当前的调制解调器软件版本标识；
判断当前的调制解调器软件版本标识与第一软件包的版本标识是否相同；
若相同，则代表着没有对调制解调器的软件进行更新，进而也就不需要升级；
若不相同，则代表着对调制解调器的软件进行了更新优化，进而也就需要升级。
在一些实施例中，上述实施例中的升级方法还包括：若需要升级，则根据第一软件包进行调制解调器升级，在进行调制解调器升级之后，推送第二软件包至微控制器。本实施例实现了对现有升级流程的完全兼容。
在一些实施例中，上述实施例中的升级方法，在调制解调器根据第一软件包进行调制解调器升级之前，还包括：
向微控制器发送调制解调器升级请求；
若接收到不允许调制解调器升级消息时，暂停升级流程，并周期性的发送调制解调器升级请求；不允许调制解调器升级消息为微控制器在工作模式时发送，工作模式包括微控制器处于升级状态和/或车辆未处于熄火状态；
若接收到允许调制解调器升级消息时，进入升级流程；允许调制解调器升级消息为微控制器在非工作模式时发送，非工作模式包括微控制器未处于升级状态且车辆处于熄火状态。
本实施例实现了调制解调器与mcu不会同时升级的要求，也实现了调制解调器不会在车辆没有处于熄火状态时进行升级的要求，这样就可以避免现有调制解调器在车辆运行时进行升级导致的obd设备与服务器通信中断的问题。
在一些实施例中，上述实施例中的升级方法在微控制器根据第二软件包进行微控制器升级之前，还包括：
根据检测到的车辆运行信息，判断车辆是否处于熄火状态；
若车辆未处于熄火状态，则暂停升级流程，并周期性的判断车辆是否处于熄火状态；
若车辆处于熄火状态，则判断电量是否满足升级要求，若满足，则进入升级流程。
在实际应用中，若在车辆未处于熄火状态时，如正在行驶时，进行mcu的升级，将会导致mcu服务的中断，导致无法采集到安全数据等问题的出现，针对这个缺点，本申请提供的新方法中，在进行调制解调器和mcu在升级之前，都需要判断车辆是否处于熄火状态，避免车辆运行时，obd设备升级导致的数据采集/传输的中断。
在一些实施例中，上述实施例中的升级方法，在微控制器判断车辆处于熄火状态、且电量满足升级要求之后，执行升级流程之前，还包括：
向调制解调器发送微控制器升级请求；
若接收到不允许微控制器升级消息时，暂停升级流程，并周期性的发送微控制器升级请求；不允许微控制器升级消息为调制解调器在处于升级状态时发送的；
若接收到允许微控制器升级消息时，进入升级流程；允许微控制器升级消息为调制解调器在处于非升级状态时发送的。
本实施例实现了mcu与调制解调器不会同时升级的要求，避免了同时升级导致的设备升级失败的问题。
在一些实施例中，上述实施例中的微控制器根据第二软件包进行微控制器升级包括：
微控制器读取当前的微控制器软件版本标识；
判断当前的微控制器软件版本标识与第二软件包的版本标识是否相同；
若相同，则微控制器退出升级流程；
若不相同，则微控制器执行升级流程。
第二实施例：
图2为本发明第二实施例提供的obd设备的结构示意图，由图2可知，本实施例提供的obd设备包括：调制解调器1及微控制器2，其中，
调制解调器1用于获取车载自动诊断系统设备的设备升级包，将设备升级包拆分为用于对调制解调器进行升级的第一软件包、以及用于对微控制器进行升级的第二软件包，并推送第二软件包至微控制器2；
微控制器2用于根据第二软件包进行微控制器升级。
在一些实施例中，上述实施例中的调制解调器1在推送第二软件包至微控制器2之前，还用于判断是否需要根据第一软件包进行调制解调器升级，若需要升级，则删除第一软件包，并推送第二软件包至微控制器2，若需要升级，则根据第一软件包进行调制解调器升级，在进行调制解调器升级之后，推送第二软件包至微控制器2。
在一些实施例中，上述实施例中的调制解调器1在根据第一软件包进行调制解调器升级之前，还向微控制器2发送调制解调器升级请求，若接收到不允许调制解调器升级消息时，暂停升级流程，并周期性的发送调制解调器升级请求，若接收到允许调制解调器升级消息时，进入升级流程；允许调制解调器升级消息为微控制器2在非工作模式时发送，非工作模式包括微控制器未处于升级状态且车辆处于熄火状态，不允许调制解调器升级消息为微控制器2在工作模式时发送，工作模式包括微控制器处于升级状态和/或车辆未处于熄火状态。
在一些实施例中，上述实施例中的微控制器2在根据第二软件包进行微控制器升级之前，还根据检测到的车辆运行信息，判断车辆是否处于熄火状态；若车辆未处于熄火状态，则暂停升级流程，并周期性的判断车辆是否处于熄火状态；若车辆处于熄火状态，则判断电量是否满足升级要求，若满足，则进入升级流程。
在一些实施例中，上述实施例中的微控制器2在判断车辆处于熄火状态、且电量满足升级要求之后，执行升级流程之前，还用于向调制解调器发送微控制器升级请求；若接收到不允许微控制器升级消息时，暂停升级流程，并周期性的发送微控制器升级请求，若接收到允许微控制器升级消息时，进入升级流程；允许微控制器升级消息为调制解调器在处于非升级状态时发送的，不允许微控制器升级消息为调制解调器在处于升级状态时发送的。
第三实施例：
现结合具体应用场景对本发明做进一步的诠释说明。
现有的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回应可以启动升级的指令后启动升级，如mcu判断设备处于正常工作模式，则反馈不允许升级的信息，非工作模式反馈允许升级信息，先升级efs文件再升级recovery，两者升级ok后重启modem进入recovery升级system，system升级完成后再重启modem进入system同时删除软件包，然后向mcu上报升级的结果结束modem升级流程。modem升级过程中需要重启两次，升级后除版本号外其余参数与升级前保持一致。如果modem升级过程中车辆点火启动，mcu会将上报的数据先缓存起来，等到modem升级完成后再连上服务器，modem升级的时候mcu不能升级。
本实施例提供一种方法，可以自动判断modem和mcu的版本是否有更新，仅对有更新的对象进行升级，免去不必要的升级浪费，同时熄火升级的条件会带来更好的用户体验。
综上可知，通过本发明实施例的实施，至少存在以下有益效果：
本发明实施例提供了一种obd升级方法，该方法在modem收到数据包时进行拆分获得mcu的软件包，并推送至mcu，使得mcu可以根据软件包直接进行mcu升级，不再需要modem升级之后来触发mcu升级，实现了modem升级与mcu升级的解耦，避免了modem的无效升级。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
以上仅是本发明的具体实施方式而已，并非对本发明做任何形式上的限制，凡是依据本发明的技术实质对以上实施方式所做的任意简单修改、等同变化、结合或修饰，均仍属于本发明技术方案的保护范围。