CN111385191A - 车载互联网关、车辆ota升级系统和方法、计算机存储介质 - Google Patents

Abstract

本发明提供一种车载互联网关、车辆OTA升级系统、车辆OTA升级方法、计算机存储介质及车辆，以利用车载互联网关实现一站式OTA刷新方案，既能完成车辆上的智能控制器的升级刷新，又能完成所有CAN子网的非智能控制器的升级刷新，而且还能使得所有OTA控制策略均在车载互联网关内部完成，由此可以形成统一的刷新策略和文件格式，使得整车厂可以统一不同车型、不同配置的车辆OTA升级刷新方案；更进一步，可以给出更加深度定制的车辆OTA升级刷新方案，比如可以实现对每个控制器的每个模块的单独刷新、刷新先后顺序配置以及多子网并行刷新等。

Description

车载互联网关、车辆OTA升级系统和方法、计算机存储介质

技术领域

本发明涉及汽车通信技术领域，尤其涉及一种车载互联网关、车辆OTA升级系统、车辆OTA升级方法、计算机存储介质及车辆。

背景技术

随着社会的进步，汽车几乎成为每家每户所必须的交通工具，使得人们的生活越来越便捷。而且随着汽车领域内各种先进技术的发展，越来越智能的各种装置和功能被集成到汽车里，这些装置和功能通常会通过相应的ECU(Electronic Control Unit，电子控制单元)来控制，据统计，当今一辆普通的家用汽车上平均含有30个ECU，每个ECU通常包括控制模块和存储模块，存储模块用于存储与该ECU相关的装置或功能的软件和参数等。但随着汽车智能化的不断提高，人们对汽车各系统的功能、性能的需求也不断提高，而且车载电子设备的软件日趋复杂，出现软件问题的几率随之相应增加，通过升级软件往往可以进一步挖掘车载电子设备的潜能，满足人们的需求以及修复软件问题，保证汽车运行安全以及各功能的正常使用，因此汽车开发商常常需要对其生产的已交付汽车进行软件升级。

传统方式中，需要将汽车送至经销商或修理厂处，由专业维修人员使用专业测试仪器，对汽车的运行状态进行检测，再通过汽车上的专用物理接口写入更新内容，从而实现对相应组件上的软件的更新。以更新汽车中的ECU上的固件为例，需要由专业维修人员通过汽车上的OBD(On Board Diagnostics，车载自动诊断)接口写入相应更新内容，从而实现ECU上的固件的更新。显然，这种传统方式，需要专业维修人员参与，存在一定的局限性，且更新过程繁琐，效率低下。

随着科技的进步，OTA技术(Over The Air Technology，即空中系统升级技术或空中下载技术)，无需让客户前往经销商或修理厂处，就能对汽车上相应的ECU进行升级刷新，因而能够使得用户具有较好的体验，且对于汽车开发商来说成本也较低，因此逐渐成为车载电子设备的软件升级的趋势。

请参考图1，目前的OTA升级刷新方式是，云端升级平台通过远程安全链接的方式将升级包FOTA(Firmware Over-The-Air)传送给汽车的车载车联网终端T-BOX(TelematicsBOX)，T-BOX的车联网客户端解析(例如解密验签)后通过USB或以太网(ETH)传输给汽车的车机HU(Head Unit)、汽车仪表板IPC(Instrument Panel Cluster)等具有智能控制器(即智能ECU)的电子设备处，并同时通过控制器局域网总线CAN1传输给网关GW(Gateway)，再由车机HU和汽车仪表板IPC等电子设备各自的智能ECU进行升级信息的处理解析再进行具体的升级步骤，同时网关GW的网关客户端通过控制器局域网总线CAN2、CAN3…..等分别传输给车身控制器BCM(body control module)、尾门控制器TGC(Tailgate Controller)、电池管理系统BMS(Battery Management System)以及发动机管理系统EMS(Engine ManagementSystem)等具有传统控制器(即非智能ECU)的电子设备系统处，以实现这些非智能ECU的升级。这样的升级方式存在较多问题，具体包括：

1.上述的OTA升级方案，采用T-BOX、GW、BCM、TGC、BMS、EMS等多主节点协作的方式，通信链路长，主节点间交互多，数据保护能力差，开发周期长；

2.上述的OTA升级方案，一般由多家供应商联合完成，难以形成统一策略和数据格式，当车型或车辆配置变换时往往需要重新定制策略开发；

3.上述的OTA升级方案，通常只拥有云端和智能控制器(即带Linux等智能操作系统的ECU，简称智能ECU)的处理能力，而针对汽车上的传统控制器(即带有嵌入式实时操作系统的ECU，简称非智能ECU)的OTA升级刷新，一般需跨领域合作才能形成完整的OTA服务，交互较多，无法形成整体优势；

4.上述的OTA升级方案，无法对各个ECU的升级刷新进行深度定制，如刷新顺序判断、ECU模块级刷新控制、刷新失败处理及回滚策略等。

发明内容

本发明的目的在于提供一种车载互联网关、车辆OTA升级系统、车辆OTA升级方法、计算机存储介质及车辆，能够缩短通信链路，减少主节点间交互，并且能完成车辆上的智能控制器和传统控制器的刷新。

为了实现上述目的，本发明提供一种车载互联网关，安装在一车辆上，包括：

微处理器，其被配置为与云端交互以接收所述云端下发的升级包，并从所述升级包中解析出第一升级刷新数据和第二升级刷新数据，以及根据所述第一升级刷新数据对所述车辆上的智能控制器进行升级刷新，其中，所述第一升级刷新数据用于对所述车辆上的智能控制器进行升级刷新，所述第二升级刷新数据用于对所述车辆上的非智能控制器进行升级刷新；

微控制器，其被配置为与所述微处理器通信连接，并在所述微处理器解析出所述第二升级刷新数据时被所述微处理器触发，以根据所述微处理器下发的所述第二升级刷新数据对所述车辆上的非智能控制器进行升级刷新。

可选地，所述微处理器包括：

云端交互模块，其被配置为与所述云端建立安全通信链路，以从所述云端下载所述升级包；

文件解析模块，其被配置为对所述升级包进行文件解析，以从所述升级包中解析出用于对所述车辆上的智能控制器进行升级刷新的第一升级刷新数据以及用于对所述车辆上的非智能控制器进行升级刷新的第二升级刷新数据；

智能控制器客户端模块，其被配置为与所述车辆上的智能控制器通信连接，以根据所述第一升级刷新数据对所述车辆上的智能控制器进行升级刷新；以及，

通信服务端模块，其被配置为通过通信总线与所述微控制器通信连接，在所述文件解析模块解析出所述第二升级刷新数据时触发所述微控制器，并将所述第二升级刷新数据下发至所述微控制器。

可选地，所述文件解析模块进一步被配置为对所述升级包进行文件解析，并将从所述升级包中解析出的包括所述第一升级刷新数据和所述第二升级刷新数据在内的文件转换为统一的文件格式。

可选地，所述统一的文件格式包括:用于描述对所述车辆进行一次OTA刷新的需求的升级包配置文件、用于描述各个所述智能控制器和所述非智能控制器的刷新信息的控制器刷新配置文件、用于刷新各个所述智能控制器和所述非智能控制器的原始数据刷新文件以及差分数据刷新文件四类文件；其中，所述升级包配置文件包含所述车辆上需要刷新的控制器数量、基本的刷新信息以及整体刷新包的校验信息；所述控制器刷新配置文件包含某个所述智能控制器或所述非智能控制器具体需要刷新的文件数量、地址范围、安全算法信息和校验方法信息；所述原始数据刷新文件和所述差分数据刷新文件均包含文件头和文件内容，所述文件头用于描述文件内容的版本信息和校验信息。

可选地，所述文件解析模块进一步被配置为：将所述四类文件保存在所述车辆本地的嵌入式多媒体存储器中，并对所有的所述四类文件全生命周期保持加密，且将加密的信息在所述微处理器和微控制器中交叉存放并实现互相校验；所述智能控制器客户端或所述微控制器进一步被配置为：在所述车辆的某个所述控制器的升级刷新被触发时，动态解密所述控制器对应的所述四类文件并临时保存，且在车载互联网关发生断电时，清除动态解密出的所有数据。

可选地，所述文件解析模块进一步被配置为：对每次刷新时的所述四类文件配置不同的加密和校验方式，且每次刷新时转换的所述控制器刷新配置文件中包含相应的所述智能控制器或所述非智能控制器的模块划分信息；所述智能控制器客户端模块进一步被配置为：根据所述智能控制器的每个模块的前一次升级刷新的软件版本以及所述文件解析模块从本次的升级包中的所述第一升级刷新数据转换出的所述四类文件，对所述智能控制器中需要升级刷新的模块进行模块级的升级刷新。

可选地，所述控制器刷新配置文件中包括升级刷新的尝试次数；所述智能控制器客户端模块进一步被配置为：当升级刷新某个所述智能控制器失败时，依据所述智能控制器对应的所述控制器刷新配置文件中配置的尝试次数重新启动对所述智能控制器的刷新流程，并在所述尝试次数全部尝试失败后，进一步尝试将所述智能控制器的软件版本刷回上次升级刷新成功时的软件版本。

可选地，所述智能控制器客户端模块进一步被配置为：获取所述车辆上的智能控制器之间的依赖关系，并根据所述依赖关系确定所述智能控制器的刷新顺序，以及按照所述刷新顺序对相应的智能控制器进行升级刷新。

可选地，所述文件解析模块从所述升级包中解析出的数据还包括用于对所述车载互联网关进行升级刷新的第三升级刷新数据；所述微处理器还包括自升级模块，其被配置为当所述文件解析模块从所述升级包中解析所述第三升级刷新数据时，根据所述第三升级刷新数据对所述微控制器及所述微处理器自身进行升级刷新。

可选地，所述微处理器为具有主系统和备份系统的双备份系统，所述主系统被配置为先对所述车辆上的所述智能控制器进行升级刷新，后对所述微控制器以及所述备份系统进行升级刷新；所述备份系统用于在所述车载互联网关重启时对所述微处理器的主系统进行升级刷新。

可选地，所述微控制器包括：

通信客户端模块，其被配置为通过通信总线与所述通信服务端模块通信连接，以接收所述通信服务端模块下发的所述第二升级刷新数据，以及向所述通信服务端模块反馈所述非智能控制器的升级刷新进度；以及，

传统控制器管理模块，其被配置为与所述车辆上的各个所述非智能控制器通信连接，并根据所述第二升级刷新数据对相应的所述非智能控制器进行升级刷新以及将所述非智能控制器的升级刷新进度反馈至所述通信客户端模块。

可选地，所述传统控制器管理模块包括：

传统控制器客户端单元，其被配置为接收所述第二升级刷新数据并获取用于验证和解析所述第二升级刷新数据的相关信息，以及，获取所述车辆上的非智能控制器的软件版本信息，并根据所述第二升级刷新数据对所述车辆上的非智能控制器进行升级刷新，以及将升级刷新的进度反馈至所述通信客户端模块；

文件校验单元，其被配置为根据所述传统控制器客户端单元获取的用于验证所述第二升级刷新数据的相关信息，验证所述文件解析模块下发的所述第二升级刷新数据的合法性；

文件解析单元，其被配置为根据所述传统控制器客户端单元获取的用于解析所述第二升级刷新数据的相关信息，对所述第二升级刷新数据进行解析；

刷新流程控制单元，其被配置为通过传统控制器客户端单元获取所述车辆上的非智能控制器之间的依赖关系，并根据所述依赖关系确定所述非智能控制器的刷新顺序，所述传统控制器客户端单元进一步被配置为根据所述刷新顺序以及所述文件解析单元解析的数据对所述车辆上的非智能控制器进行升级刷新。

可选地，所述微控制器还包括：

硬件安全模块，其被配置为对所述微控制器接收和向外发送的数据进行加密，并对所述第一升级刷新数据和所述第二升级刷新数据中的加密信息进行映射存储；以及，

启动加载模块，其被配置为在所述文件解析模块从所述升级包中解析出用于对所述车载互联网关进行升级刷新的第三升级刷新数据时，根据所述第三升级刷新数据对所述微控制器自身进行升级刷新。

可选地，所述第二升级刷新数据中包含所述非智能控制器的模块划分信息；所述传统控制器客户端单元进一步被配置为：根据所述车辆上的所述非智能控制器的每个模块的前一次升级刷新的软件版本以及所述文件解析单元对本次升级包中的所述第二升级刷新数据的解析结果，对所述非智能控制器中需要升级刷新的模块进行模块级的升级刷新。

可选地，所述文件解析单元对本次升级包中的所述第二升级刷新数据的解析结果中包括本次升级刷新的尝试次数；所述传统控制器客户端单元进一步被配置为：当升级刷新所述非智能控制器失败时，依据所述非智能控制器对应的所述尝试次数重新启动对所述非智能控制器的刷新流程，并在所述尝试次数全部尝试失败后，进一步尝试将所述非智能控制器的软件版本刷回上次升级刷新的软件版本。

可选地，所述传统控制器客户端单元进一步被配置为对所述车辆上的多个所述非智能控制器并行升级刷新，并依据各个所述非智能控制器的升级刷新的进度，实时向所述微处理器请求所述非智能控制器的升级刷新数据。

基于同一发明构思，本发明还提供一种车辆OTA升级系统，包括：

云端服务器，其上存储有至少一个升级包；

安装在车辆上的智能控制器和非智能控制器；以及，

本发明所述的车载互联网关，所述车载互联网关分别与所述云端服务器以及各个所述智能控制器和所述非智能控制器通信连接。

基于同一发明构思，本发明还提供一种车辆OTA升级方法，包括：

一车载互联网关与云端建立通信连接，以接收所述云端下发的升级包；

所述车载互联网关从所述升级包中解析出用于对车辆上的各个控制器进行升级刷新的升级刷新数据，其中，所述控制器包括智能控制器和非智能控制器，所述升级刷新数据包括用于对所述智能控制器进行升级刷新的第一升级刷新数据以及用于对所述非智能控制器进行升级刷新的第二升级刷新数据；

所述车载互联网关根据所述第一升级刷新数据对所述车辆上的智能控制器进行升级刷新，并在解析出所述第二升级刷新数据时触发对所述车辆上的非智能控制器进行升级刷新的流程，以根据解析出的所述第二升级刷新数据对所述车辆上的非智能控制器进行升级刷新。

可选地，所述车载互联网关对所述车辆上的某个所述控制器进行升级刷新的步骤包括：

读取所述控制器的软件版本；

判断所述车辆本地上是否具有对应所述软件版本的备份包，若有，则从所述云端下载所述升级包，若无，则向所述云端请求下载备份包；

在下载好所述升级包后，判断所述控制器当前所处的环境条件是否满足刷新条件，若否，则结束退出，若是，则触发对所述智能控制器和/或非智能控制器进行升级刷新的流程，并依据从所述升级包中解析出的所述控制器对应的升级刷新数据对所述控制器进行升级刷新，当本次的所述升级刷新失败时，依据所述升级刷新数据中配置的尝试次数重新启动所述流程，当所述尝试次数全部尝试完但对所述控制器的升级刷新依旧失败时，进一步尝试将所述控制器的软件版本刷回上次升级刷新的软件版本。

可选地，所述的车辆OTA升级方法还包括：当所述车载互联网关根据所述第一升级刷新数据和所述第二升级刷新数据对所述车辆上所有的智能控制器和非智能控制器进行升级刷新完成后，判断从所述升级包中解析出的升级刷新数据是否有用于对所述车载互联网关自身进行升级刷新的第三升级刷新数据，当有时，根据所述第三升级刷新数据进行自刷新。

可选地，所述的车辆OTA升级方法还包括：所述车载互联网关在对所述车辆上的智能控制器和非智能控制器进行升级刷新之前，先将从所述升级包中解析出的第一升级刷新数据以及第二升级刷新数据转换为统一的文件格式。

可选地，所述统一的文件格式包括：用于描述对所述车辆进行一次OTA刷新的需求的升级包配置文件、用于描述所述车辆上的各个所述控制器的刷新信息的控制器刷新配置文件、用于刷新各个所述控制器的原始数据刷新文件以及差分数据刷新文件四类文件；其中，所述升级包配置文件包含所述车辆上需要刷新的控制器数量、基本的刷新信息以及整体刷新包的校验信息；所述控制器刷新配置文件包含某个所述控制器具体需要刷新的文件数量、地址范围、安全算法信息和校验方法信息；所述原始数据刷新文件和所述差分数据刷新文件均包含文件头和文件内容，所述文件头用于描述文件内容的版本信息和校验信息。

可选地，所述车载互联网关采用不同的加密和校验方式对所述四类文件进行配置，在对所述车辆上的智能控制器和非智能控制器进行升级刷新的过程中，将所述四类文件保存在所述车辆本地的嵌入式多媒体存储器中，并对所有的所述四类文件全生命周期保持加密，且将加密的信息在内部交叉存放并实现互相校验；在所述车辆的某个所述控制器的升级刷新流程被触发时，动态解密所述控制器对应的所述四类文件并临时保存，且在发生断电时，自动清除动态解密出的所有数据。

可选地，所述车载互联网关在对所述车辆上的智能控制器和非智能控制器进行升级刷新之前，先确定所述车辆上的所述控制器之间的依赖关系，并制定一套依赖算法来确定有依赖关系的所述控制器之间的刷新顺序，再依据所述刷新顺序对有依赖关系的所述控制器进行升级刷新，且对刷新顺序不敏感的所述控制器进行并行刷新。

可选地，所述车载互联网关在对所述车辆上的智能控制器和非智能控制器进行升级刷新的过程中，当有总线故障或信号干扰或所述车辆上的某个所述控制器与其升级刷新的版本不兼容的情况时，所述车载互联网关会依据所述控制器对应的升级刷新数据中配置的尝试次数重新启动对所述控制器的刷新流程，并在所有尝试次数均尝试失败时，尝试将所述控制器的软件版本刷回上次升级刷新后的版本。

可选地，所述车载互联网关按照所述车辆上的某个所述控制器的模块划分，对所述控制器进行模块级的升级刷新。

基于同一发明构思，本发明还提供一种计算机存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时，实现本发明所述的车辆OTA升级方法。

基于同一发明构思，本发明还提供一种车辆，包括：

多个控制器，所述控制器包括智能控制器和非智能控制器；以及，

本发明所述的车载互联网关，所述车载互联网关与云端交互，并与各个所述控制器通信连接。

与现有技术相比，本发明的技术方案具有以下有益效果：

1.采用一个车载互联网关能完成现有的OTA升级方法中的车载车联网终端T-BOX和网关GW等多个主节点的所有功能，因此可以减少通信链路，屏蔽了这些主节点之间交互的细节，增加了数据保护能力，缩短了OTA升级方案的开发周期；

2.采用一个车载互联网关，不仅可以对车辆上的智能控制器进行OTA升级刷新，还能对车辆上的非智能控制器进行OTA升级刷新，无需跨领域合作就能形成完整的OTA服务；

3.采用一个车载互联网关作为主节点，可以对车联网的所有子网(即车辆上的所有智能控制器和非智能控制器)实施并行刷新，以减少刷新时间；

4.通过所述车载互联网关可以形成统一的OTA升级刷新策略，不会因为车辆的车型配置变换或车辆上的控制器供应商变更而导致OTA升级刷新策略变更，由此可以给汽车开发商OEM带来极大的便利；

5.所述车载互联网关能够为OTA升级刷新定义出灵活安全的统一的文件格式，可以兼容车辆上的智能控制器和非智能控制器的升级刷新，便于车辆上的所有的控制器统一管理；

6.可以针对车辆上的各个控制器的升级刷新进行深度定制，例如为车辆上的多个控制器设定刷新顺序，以按照设定的刷新顺序对这些控制器进行升级刷新，以提高升级刷新的成功率，并缩短刷新时间；再例如将各个所述控制器进行模块划分，以对某个控制器的某个模块或者几个模块进行单独刷新，以节省流量且可以缩短刷新时间；

7.设计了相应的错误处理和回滚策略，例如刷新过程中因为总线故障、信号干扰或发现控制器的升级版本不兼容时，依据刷新配置文件中配置的尝试次数重新启动刷新流程，如果多次尝试失败，还会尝试刷回之前的老版本；

8.不仅可以对车辆上的智能控制器和非智能控制器进行升级刷新，还能对车载互联网关进行自刷新，以保证车载互联网关的正常运行以及功能升级。

附图说明

图1为现有的OTA升级刷新方式下的系统架构图；

图2为本发明一实施例的车载互联网关的功能模块图；

图3是本发明一实施例中的统一的文件格式的示意图；

图4是本发明另一实施例的车载互联网关的功能模块图；

图5是本发明一实施例的车载互联网关对控制器进行模块级刷新后的结果示意图；

图6是本发明一实施例的车辆OTA升级方法流程图；

图7是本发明一实施例的车辆OTA升级方法中的车载互联网关与云端服务器之间的信息交互流程图。

具体实施方式

本发明的技术方案的核心思想在于，设计一款一站式刷新方案，即车载互联网关以及利用该车载互联网关实现车辆OTA升级刷新的方法，使其既能完成针对USB/Ethernet(以太网)等连接的智能控制器的升级刷新，又能完成所有CAN子网的非智能控制器(即具有嵌入式实时操作系统的传统控制器)的升级刷新，而且还能使得所有OTA控制策略均在车载互联网关内部完成，由此可以形成统一的刷新策略和数据格式，使得整车厂可以统一不同车型、不同配置的车辆OTA升级刷新方案；更进一步，可以给出更加深度定制的车辆OTA升级刷新方案，比如可以实现对某个控制器(ECU)的每个模块的单独刷新、刷新先后顺序配置以及多子网并行刷新等，以解决背景技术中所提到的现有的车辆OTA升级刷新方案中存在的问题。

为使本发明的目的、特征更明显易懂，下面结合附图对本发明的技术方案作详细的说明，然而，本发明可以用不同的形式实现，不应只是局限在所述的实施例。此外，需要说明的是，本文的框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机程序指令的组合来实现。对于本领域技术人员来说公知的是，通过硬件方式实现、通过软件方式实现以及通过软件和硬件结合的方式实现都是等价的。

请参考图2，本发明一实施例提供一种车载互联网关，安装在一车辆上，包括集成在一起的微处理器(MPU)21和微控制器器(MCU)22。MCU22和MPU21之间采用SPI总线通信。其中，MPU 21被配置为：与云端(即云端服务器，未图示)交互以接收所述云端下发的升级包1，并从所述升级包1中解析出用于对所述车辆上的智能控制器(即智能ECU1、…..、智能ECUm)进行升级刷新的第一升级刷新数据以及用于对所述车辆上的非智能控制器(即非智能ECU1、…..、非智能ECUn)进行升级刷新的第二升级刷新数据，以及根据所述第一升级刷新数据对所述车辆上的智能控制器(即智能ECU1、…..、智能ECUm)进行升级刷新。MCU22被配置为：通过SPI总线与所述MPU21通信连接，并在所述MPU21解析出所述第二升级刷新数据时被所述MPU触发，以根据所述MPU下发的所述第二升级刷新数据对所述车辆上的非智能控制器(即非智能ECU1、…..、非智能ECUn)进行升级刷新。智能ECU1、…..、智能ECUm例如是通过USB、Ethernet(以太网)或MOST光纤网络等与MPU21连接的汽车仪表板IPC、汽车的车机HU、导航设备以及各种多媒体设备(例如音箱、显示屏、摄像头、车载电话等)的控制器等，非智能ECU1、…..、非智能ECUn例如是通过控制器局域网CAN总线、高速车载总线FlexRay总线或低速串行总线LIN总线等连接MCU22的车身控制器BCM(例如包括车灯、门锁、电动座椅、汽车空调等)、尾门控制器TGC(该控制器可以实现脚踢控制后备箱打开的等功能，具备电机控制算法，可标定控制参数)、电池管理系统BMS以及发动机管理系统EMS(例如包括引擎控制、ABS、悬挂控制等)等。也就是说，利用MCU22配备嵌入式实时操作系统，可以实现传统CAN节点等连接的非智能控制器的升级刷新，利用MPU21配备智能操作系统(例如Linux操作系统)，可以实现对USB或Ethernet或MOST光纤网络等节点连接的智能控制器的升级刷新，MCU22可以实现并行刷新并依据刷新的进度，实时向MPU21请求各个非智能控制器的第二升级刷新数据。

请继续参考图2，本实施例中，所述MPU21包括云端交互模块211、文件解析模块212、智能控制器客户端模块213、自升级模块214以及通信服务端模块215。

其中，云端交互模块211为4G或5G通信模块，被配置为与所述云端建立安全通信链路，以从所述云端下载所述升级包1，其具体包括：下载单元2111、安全通信链路单元2112以及ECU版本管理单元2113，其中安全通信链路单元2112可以与云端交互，以建立起安全通信链路，以保证车载互联网关和云端服务器之间的通信安全，并使得该通信链路能够供下载单元2111和ECU版本管理单元2113使用，下载单元2111用于从云端下载相应版本的升级包1以及用于验证升级包1的验证信息、用于解密升级包1的密钥信息，ECU版本管理单元2113用于管理下载的升级包版本以及获取各个智能控制器和非智能控制器已安装有的软件版本，以确定将各个智能控制器和非智能控制器的软件版本升级到具体哪个版本。其中各个升级包1包括文件头、数据块信息头、数据块内容以及验证信息等。

文件解析模块212被配置为对所述升级包1进行文件解析，以从所述升级包1中解析出用于对所述车辆上的智能控制器(即智能ECU1、…..、智能ECUm)进行升级刷新的第一升级刷新数据以及用于对所述车辆上的非智能控制器(即非智能ECU1、…..、非智能ECUn)进行升级刷新的第二升级刷新数据。本实施例中，所述文件解析模块212包括升级包验证单元2121、密钥管理单元2122、文件管理单元2123。其中，所述升级包验证单元2121用于对下载单元2111下载的升级包1进行合法性验证；密钥管理单元2122用于管理下载单元211下载的密钥信息以帮助文件管理单元2123解析通过合法性验证的升级包1，以及，为文件管理单元2123解析和转换的文件进行加密保护；文件管理单元2123用于根据所述密钥管理单元2122中的相关密钥对通过合法性验证的升级包1进行解析，以从所述升级包中解析出的用于升级刷新智能控制器的第一升级刷新数据、用于升级刷新非智能控制器的第二升级刷新数据以及用于车载互联网关自刷新的第三升级刷新数据。本实施例中，为统一策略，提高OTA刷新方案的整体安全性以及兼容智能控制器和非智能控制器的刷新需求，所述文件管理单元2123还将第一升级刷新数据以及第二升级刷新数据的文件格式转换为统一的文件格式。具体地，所述统一的文件格式包括:用于描述对所述车辆进行一次OTA刷新的需求的升级包配置文件(即FOTA配置文件)、用于描述所述车辆上的各个控制器的刷新信息的控制器刷新配置文件(即ECUi刷新配置文件，i为自然数)、用于刷新各个所述控制器的原始数据刷新文件(即ECU刷新文件-原始数据)以及差分数据刷新文件(即ECU刷新文件-差分数据)四类文件，如下表所示：

文件类型	字节	含义
			0x0001	2	FOTA配置文件
0x0002	2	ECU刷新配置文件
			0x0003	2	ECU刷新文件-原始数据
0x0004	2	ECU刷新文件-差分数据

目前市面上对车辆上的控制器的刷新都是依据该控制器的整体管理，但售后车辆经常只需要更新某个控制器中的某个标定数据或应用程序，因此，为了节省流量且缩短刷新时间，所述这四类文件均按各个控制器及其模块进行划分，以用于实现各个控制器的模块级刷新策略和刷新失败时的回滚处理，此时，针对一个升级包，文件管理单元2123转换后的统一的文件格式中各个文件的组织关系如图3所示，其中，升级包配置文件(即FOTA配置文件)用于描述一次OTA升级刷新的需求，其包含需要刷新的控制器数量(即刷新包ECU数量)、基本的刷新信息(包括刷新顺序、总线、系统类型等)以及整体刷新包的校验信息(包括通用的消息认证码或密钥TotalCMAC、每个控制器的刷新数据的消息认证码或密钥CMAC、签名、访问凭证等)；控制器刷新配置文件(即ECUi刷新配置文件，i为自然数)用于描述具体某个控制器ECU的刷新信息，其包含某个所述控制器的地址范围(ECUID)、具体需要刷新的文件数量(即模块数量)、模块加密CMAC子网、安全算法信息和校验方法信息(即每个模块的消息认证码或密钥CMAC)；所述原始数据刷新文件和所述差分数据刷新文件组成具体某个控制器ECU的刷新文件，均包含文件头和文件内容，所述文件头用于描述文件内容的版本信息和校验信息，文件内容(BIN)包含具体的刷新数据内容，每个差分数据刷新文件的文件头包括差分配置、编号、地址、总长、分段长度以及校验方法信息(CAMC)等。其中，具体的某个控制器的刷新文件由各个模块的刷新文件组成，例如图3中的控制器ECU1具有n个模块，其包含的差分数据刷新文件为与n个模块一一对应的n个刷新文件，即ECU1刷新文件1至ECU1刷新文件n；控制器ECU2具有n个模块，其包含的差分数据刷新文件为与其n个模块一一对应的n个刷新文件，即ECU2刷新文件1至ECU2刷新文件n；控制器ECU3具有n个模块，其包含的差分数据刷新文件为与其n个模块一一对应的n个刷新文件，即ECU3刷新文件1至ECU3刷新文件n。对于某个控制器ECU的升级刷新描述，文件管理单元通过其转换出来的刷新文件(包括原始数据刷新文件和差分数据刷新文件)和控制器刷新配置文件来描述，这些文件组成一个原子包，对于一次OTA刷新，会由一个FOTA配置文件和多个原子包组成，称之为分子包。MPU21的云端交互模块211完成分子包下载后，文件解析模块212会解密并分析刷新任务，因智能控制器的刷新文件较大，MPU21的云端交互模块211一般会采用差分数据来下载分子包，文件解析模块212在本地通过差分算法还原为原始数据，然后对相应的智能控制器进行升级刷新，针对智能系统刷新一般是通过USB/Ethernet/MOST与智能控制器建立https的连接，直接传递刷新文件，并实时反馈刷新进度给到云端。MPU21的文件解析模块212如果发现需要对CAN子网上的非智能控制器进行升级刷新，则触发MCU22，以切换核间通信协议(即切换MPU21和MCU22之间的SPI通信)，并启动MCU22的传统控制器客户端模块(FOTA Client)224的功能，MCU22可以通过其通信连接单元2246(即UDS的Client端协议模拟诊断仪)对各个CAN子网的非智能控制器进行升级刷新。

本实施例中，所述文件管理单元2123进一步采用不同的加密和校验方式，将所有的配置文件(包括FOTA配置文件和各个控制器对应的控制器刷新配置文件)和刷新文件(包括各个控制器对应的原始数据刷新文件和差分数据刷新文件)进行加密保护，且各个控制器的刷新文件(包括原始数据刷新文件和差分数据刷新文件)的加密密钥会随每次下载的分子包不同而不同，以提高安全性。

本实施例中，所述文件管理单元2123进一步将所有的刷新文件和备份刷新文件都保存在车辆本地的嵌入式多媒体存储器(eMMC)系统中，为防止eMMC系统被黑客单独剥离出来而放到其他系统去解析，密钥管理单元2122能够使得所述文件管理单元2123转化的所有的刷新文件全生命周期保持加密，在刷新触发时，所述文件管理单元2123能动态解密这些刷新文件并将解密后的数据临时存放到RAM中，一旦发生断电，解密后的所有数据会自动被清除，由此大大增加了数据的安全性，密钥管理单元2122将加密解析文件后的加密信息交叉存放在MCU22和MPU21内部，以使得MCU22和MPU21内的加密信息互相校验，并进一步映入到MCU22的安全硬件模块222和MPU21的安全硬件模块(未图示)进行存储，由此，即使Linux系统被入侵，也能有效的保护各个控制器的OTA升级刷新进程和刷新数据。

智能控制器客户端模块213被配置为：与所述车辆上的智能控制器(即智能ECU1、…..、智能ECUm)通信连接，以根据所述文件解析模块212解析和转化的文件对所述车辆上的智能控制器(即智能ECU1、…..、智能ECUm)进行升级刷新。

通信服务端模块215被配置为：通过SPI通信总线与MCU22的通信客户端模块221通信连接，在所述文件解析模块212解析出所述第二升级刷新数据时触发所述MCU22，并将所述第二升级刷新数据(即加密的四类文件)下发至所述MCU22，以使其能够根据所述第二升级刷新数据对相应的非智能控制器进行升级刷新。

自升级模块214被配置为：在所述文件解析模块212解析出用于车载互联网关自刷新的第三升级刷新数据时，在车辆上的智能控制器和非智能控制器均升级刷新完成后，先通过SPI自刷新MCU22，然后完成MPU21的自刷新，以确保OTA整个刷新过程的进度和状态都可见。请参考图4，本实施例中，MPU21为具有主系统A和备份系统B的双备份系统，所述主系统A被配置为先对所述车辆上的所述智能控制器进行升级刷新，后对所述MCU21以及所述备份系统B进行升级刷新；所述备份系统B用于在所述车载互联网关重启时对所述微处理器的主系统A进行升级刷新，具体的，当MCU22和MPU21都完成刷新时，通过车载互联网关重启，以使得MCU22和MPU21均切换到最新的软件状态。

本实施例中，所述MCU22包括通信客户端模块221、硬件安全模块222、启动加载模块223以及传统控制器管理模块224。

通信客户端模块221被配置为通过SPI通信总线与所述MPU22的通信服务端模块215通信连接，以接收所述通信服务端模块215下发的所述第二升级刷新数据(即文件解析模块212转换用于非智能控制器升级刷新的四类文件)，以及向所述通信服务端模块215反馈相应的所述非智能控制器的升级刷新进度。MPU22的文件解析模块212解析出第二升级刷新数据时，会触发通信服务端模块215和通信客户端模块221之间的通信，进而启动传统控制器管理模块224的功能，以对各个子网的非智能控制器进行升级刷新。

硬件安全模块222(hardware security module，HSM)用于保护和管理MCU22所使用的密钥，并同时为MCU22的其他模块提供相关密码学操作的功能模块，本实施例中，所述硬件安全模块222被配置为对所述微控制器MCU22接收和向外发送的数据进行加密，并对所述第一升级刷新数据和所述第二升级刷新数据中的加密信息进行映射存储，可以使得所有的非智能控制器的刷新文件能够在全生命周期中保持加密，且即使智能控制器的系统被入侵，也能有效的保护OTA升级刷新的进程和数据。

启动加载模块223被配置为在所述文件解析模块从所述升级包中解析出用于对所述车载互联网关进行升级刷新的第三升级刷新数据时，根据所述第三升级刷新数据对所述微控制器MCU22自身进行升级刷新，具体地，当MCU22和MPU21都完成刷新后，在车载互联网关重启时，启动加载模块223可以使得MCU22切换到最新的软件状态。

传统控制器管理模块224被配置为与所述车辆上的各个所述非智能控制器(即非智能ECU1、……、非智能ECUn)通信连接，并根据所述第二升级刷新数据对相应的所述非智能控制器进行升级刷新以及将所述非智能控制器的升级刷新进度反馈至所述通信客户端模块221。本实施例中，所述传统控制器管理模块包括：传统控制器客户端单元2241、缓存管理单元2242、文件校验单元2243、刷新流程控制单元2244、文件解析单元2245以及通信连接单元2246。所述传统控制器客户端单元2241被配置为接收所述第二升级刷新数据并获取用于验证和解析所述第二升级刷新数据的相关信息，以及，获取所述车辆上的非智能控制器的软件版本信息，并根据所述第二升级刷新数据对所述车辆上的非智能控制器进行升级刷新，以及将升级刷新的进度反馈至所述通信客户端模块221；缓存管理单元2242用于缓存文件解析单元2245解析出的数据等；文件校验单元2243被配置为根据所述传统控制器客户端单元2241获取的用于验证所述第二升级刷新数据的相关信息，验证所述文件解析模块212下发的所述第二升级刷新数据的合法性；文件解析单元2245被配置为根据所述传统控制器客户端单元2241获取的用于解析所述第二升级刷新数据的相关信息(例如消息密钥等)，对所述第二升级刷新数据进行解析；刷新流程控制单元2244被配置为通过传统控制器客户端单元2241获取所述车辆上的非智能控制器之间的依赖关系，并根据所述依赖关系确定每个所述非智能控制器的刷新顺序，所述传统控制器客户端单元2241进一步被配置为根据所述刷新顺序以及所述文件解析单元2245解析的数据对所述车辆上的非智能控制器进行升级刷新。通信连接单元2246被配置为实现所述传统控制器客户端单元2241和各个非智能控制器之间的安全通信连接，以在传统控制器客户端单元2241和各个非智能控制器之间实现双向通信。

其中，当文件解析模块212和文件解析单元2245解析出的配置文件和刷新文件中包含相应的控制器的模块划分信息时，所述智能控制器客户端模块213和传统控制器客户端单元2241进一步被配置为：根据所述车辆上的控制器(即智能ECU1、…..、智能ECUm和非智能ECU1、…..、非智能ECUn)的每个模块的前一次升级刷新的软件版本、所述文件解析模块212从本次的升级包中解析和转化的四类文件以及文件解析单元2245从所述文件解析模块212下方的文件中解析出的四类文件，对相应的所述控制器中需要升级刷新的模块进行模块级的升级刷新以及在刷新失败时进行模块级的回滚处理，具体地，如图5所示，因为每次ECU刷新时其对应的加密密钥都不一样，密钥管理单元2122需要记录每个ECU的每个版本的加密密钥，假定第一次下载升级包后，所述智能控制器客户端模块213或传统控制器客户端单元2241对控制器ECU1和ECU2进行模块级升级刷新，且通过并行刷新来同时升级刷新控制器ECU1的模块1至3以及控制器ECU2的模块1至2；第二次下载升级包后，所述智能控制器客户端模块213或传统控制器客户端单元2241对控制器ECU1和ECU2进行模块级升级刷新，且仅升级刷新控制器ECU1的模块1以及控制器ECU2的模块1；第三次下载升级包后，所述智能控制器客户端模块213或传统控制器客户端单元2241对控制器ECU1和ECU2进行模块级升级刷新，且仅升级刷新控制器ECU1的模块1和2以及控制器ECU2的模块1；第四次下载升级包后，所述智能控制器客户端模块213或传统控制器客户端单元2241对控制器ECU1和ECU2进行模块级升级刷新，且升级刷新控制器ECU1的模块1至3以及控制器ECU2的模块1至2，但对控制器ECU2升级刷新模块1和2均失败，此时，所述智能控制器客户端模块213或传统控制器客户端单元2241会依据控制器ECU2的每个模块的上一次升级刷新后的版本的备份数据，按照不同的密钥解密，来对控制器ECU2的每个模块进行回滚刷新，即将控制器ECU2的模块1回刷为第三次升级刷新的版本M21V3+Key3，将控制器ECU2的模块2回刷为第一次升级刷新的版本M22V1+Key1。在本发明的其他实施例中，当基于第四次升级包对控制器ECU2的模块1和2升级刷新时，若模块1刷新成功，版本变为版本M21V4+Key4，而模块2刷新失败，则可以仅仅将控制器ECU2的模块2回刷为第一次升级刷新的版本M22V1+Key1。

此外，在智能控制器和非智能控制器的刷新过程中，有可能会因总线故障(busoff)、信号干扰时或控制器发现版本不兼容等情况而导致本次升级刷新失败，为了解决该问题，文件解析模块212转换出的各个所述控制器刷新配置文件中优选的包括对该控制器升级刷新的尝试次数，此时，所述智能控制器客户端模块213和传统控制器客户端单元2241进一步被配置为：当升级刷新某个控制器失败时，依据所述控制器对应的所述控制器刷新配置文件中配置的尝试次数重新启动对所述控制器的刷新流程，并在所述尝试次数全部尝试失败后，进一步尝试将所述控制器的软件版本刷回上次升级刷新的软件版本，例如，请参考图5，假如所述智能控制器客户端模块213或传统控制器客户端单元2241基于第四次下载的第四次升级包对控制器ECU2的模块1和模块2就进行升级刷新时，该第四次升级包中为控制器ECU2配置了4次尝试机会，在尝试的第一次升级刷新失败时，所述智能控制器客户端模块213和传统控制器客户端单元2241可以再次基于第四次下载的第四次升级包对控制器ECU2的模块1和模块2就进行升级刷新，若4次尝试机会均尝试完成，但对控制器ECU2的模块1和模块2的升级刷新仍失败时，所述智能控制器客户端模块213和传统控制器客户端单元2241会依据控制器ECU2的每个模块的上一次升级刷新成功后的版本的备份数据，按照不同的密钥解密，来对控制器ECU2的每个模块进行回滚刷新，即将控制器ECU2的模块1回刷为基于第三次升级包升级刷新成功的版本M21V3+Key3，将控制器ECU2的模块2回刷为基于第一次升级包升级刷新成功的版本M22V1+Key1。

此外，如果多个控制器(智能控制器之间或智能控制器和非智能控制器之间或非智能控制器之间)的刷新有依赖关系，比如某个控制器的软件版本依赖于另一个控制器的某个版本，则依赖关系产生，此时文件解析模块212或智能控制器客户端模块213或刷新流程控制单元2244会制定一套依赖算法来确定每个控制器ECU的刷新顺序，由此使得所述智能控制器客户端模块213和传统控制器客户端单元2241按照所述刷新顺序对相应的控制器进行升级刷新，其中对刷新顺序不敏感的控制器ECU，则所述智能控制器客户端模块213和传统控制器客户端单元2241可依据各个控制器的启动情况实行并行刷新策略。

可以理解的是，MPU和MCU及其各自包含的各个模块可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以以对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式的适当组合来实现。或者，MPU和MCU及其各自包含的各个模块中的至少一个可以至少被部分地实现为计算机程序模块，当该程序被计算机运行时，可以执行相应模块的功能。

请参考图2，本发明一实施例还提供一种车辆OTA升级系统，包括：云端服务器(未图示)，其上存储有至少一个升级包1；安装在车辆上的多个控制器，所述控制器包括至少一个智能控制器(即智能ECU1、…..、智能ECUm，m不小于1)和至少一个非智能控制器(即非智能ECU1、…..、非智能ECUn，n不小于1)；以及，图2所示的车载互联网关，所述车载互联网关与分别所述云端服务器以及所述智能控制器和/或非智能控制器通信连接。其中，，所述智能控制器包括汽车仪表板IPC、汽车的车机HU、导航设备以及各种多媒体设备(例如音箱、显示屏、摄像头、车载电话等)等设备上的控制器，所述非智能控制器包括车身控制器BCM(例如包括车灯、门锁、电动座椅、汽车空调等)、尾门控制器TGC(可以实现脚踢控制后备箱打开的等功能)、电池管理系统BMS以及发动机管理系统EMS(例如包括引擎控制、ABS、悬挂控制等)等；所述车载互联网关与云端交互，并通过USB/Ethernet/MOST光纤网络等与相应的智能控制器通信连接，通过CAN总线、高速车载总线FlexRay总线或低速串行总线LIN总线与各个所述非智能控制器通信连接。云端服务器可以被理解为是提供处理、数据库、通讯设施的业务点。例如，云端服务器可以指具有相关通信和数据存储和数据库设施的单个的物理处理器，或它可以指联网或集聚的处理器、相关网络和存储设备的集合体，并且对软件和一个或多个数据库系统和支持服务器所提供的服务的应用软件进行操作。在本发明的一实施例中，云端服务器可以包括一个或多个处理器、一个或者多个存储器、一个或多个电源、一个或多个有线或无线网络接口、一个或多个输入/输出接口、或一个或多个操作系统，诸如，Windows Server、Mac OS X、Unix、Linux、FreeBSD，等等。云端服务器可以是整体式服务器或是跨多计算机或计算机数据中心的分散式服务器。服务器可以是各种类型的，例如但不限于，网络服务器，新闻服务器，邮件服务器，消息服务器，广告服务器，文件服务器，应用服务器，交互服务器，数据库服务器，或代理服务器。在一些实施例中，每个服务器可以包括硬件，软件，或用于执行服务器所支持或实现的合适功能的内嵌逻辑组件或两个或多个此类组件的组合。

请参考图2，本发明一实施例还提供一种车辆，包括：多个控制器以及图2所示的车载互联网关，其中，所述控制器包括至少一个智能控制器和至少一个非智能控制器，所述智能控制器包括汽车仪表板IPC、汽车的车机HU、导航设备以及各种多媒体设备(例如音箱、显示屏、摄像头、车载电话等)等设备上的控制器，所述非智能控制器包括车身控制器BCM(例如包括车灯、门锁、电动座椅、汽车空调等)、尾门控制器TGC(可以实现脚踢控制后备箱打开的等功能)、电池管理系统BMS以及发动机管理系统EMS(例如包括引擎控制、ABS、悬挂控制等)等；所述车载互联网关与云端交互，并通过USB/Ethernet/MOST光纤网络等与相应的智能控制器通信连接，通过CAN总线、高速车载总线FlexRay总线或低速串行总线LIN总线与各个所述非智能控制器通信连接。

请参考图2和6，本发明一实施例还提供一种应用本发明的车载互联网关进行车辆OTA升级的方法，包括以下过程：

第一步，将本发明一实施例的车载互联网关的MPU21与云端建立通信连接，以接收所述云端下发的升级包，具体地，所述云端通过短信触发车辆OTA升级的流程，进而使得车载互联网关的MPU21与云端建立通信连接，车载互联网关的MPU21读取车辆上的各个智能控制器的软件版本，MCU22读取车辆上的各个非智能控制器的软件版本，并判断车辆本地的eMMC系统中是否有备份包(即上次升级刷新成功后的备份刷新文件)，若有备份包，则进一步从云端下载用于本次升级刷新的升级包，若没有备份包，则从云端先下载所述备份包，该备份包能在本次升级刷新失败时，用于故障自恢复和版本回滚。

第二步，所述车载互联网关或所述云端向用户确认刷新环境或预约确定的刷新时间，在用户确认当前可以进行刷新或者到达用户约定的刷新时间(即刷新条件满足)时，所述车载互联网关的MPU21从下载的所述升级包中解析出用于对车辆上的智能控制器进行升级刷新的第一升级刷新数据以及用于对所述车辆上的非智能控制器进行升级刷新的第二升级刷新数据，之后，MPU21根据所述第一升级刷新数据对所述车辆上的智能控制器进行升级刷新，并在解析出所述第二升级刷新数据时触发MCU22，使MCU22对所述车辆上的非智能控制器进行升级刷新，其中对刷新顺序不敏感的多个控制器之间采用并行刷新策略，而当多个控制器之间存在依赖关系时，先确定所述车辆上的控制器之间的依赖关系，并制定一套依赖算法来确定有依赖关系的控制器之间的刷新顺序，再依据所述刷新顺序对所述有依赖关系的控制器进行升级刷新。

第三步，在车辆上的智能控制器和非智能控制器的升级刷新流程均执行完毕(包括全部刷新成功以及部分控制器回滚)后，所述车载互联网关的MPU21判断是否解析出用于对车载互联网关自刷新的第三升级刷新数据(即是否有自刷新请求)，若有，则读取MCU22和MPU21的软件版本号，并根据第三升级刷新数据，先对MCU22进行自刷新，在对MPU21进行自刷新，若无，则进行下一步；

第四步，判断车辆上的所有智能控制器和非智能控制器以及车载互联网关是否全部刷新成功，当发现至少一个没有刷新成功的时，进一步判断对其的升级刷新尝试次数是否达到最大重试次数，若没有达到最大重试次数，则进一步尝试对该控制器的升级刷新，直至在达到最大重试次数之前刷新成功，在达到最大重试次数仍旧没成功，则对其进行回滚。

请参考图7，在本实施例中，车载互联网关和云端服务器采用OMA-DM协议完成本实施例的车辆OTA升级方法，具体通信流程如下：

1、云端服务器向车载互联网关下发通知；

2、车载互联网关根据短信内容进行身份验证(此过程需要用户输入和确认相关信息)；

3、车载互联网关向云端服务器发起会话请求；

4、云端服务器向车载互联网关下发替换下载地址命令；

5、车载互联网关向云端服务器反馈命令执行结果；

6、云端服务器向车载互联网关下发下载命令；

7、车载互联网关向云端服务器上报命令执行结果；

8、云端服务器向车载互联网关下发获取进度命令；

9、间隔一定时间，车载互联网关向云端服务器反馈进度；

10.1、将下载进度显示到Web页面，具体可以通过Web服务将下载进度显示到云端服务器的Web页面和/或车载互联网关的Web页面上；

10.2、云端服务器通过车载互联网关或通过Web页面推送进度给用户；

10.3、云端服务器向车载互联网关下发获取进度命令；

11、车载互联网关定时向云端服务器上报下载进度；

12、车载互联网关定时向云端服务器上报下载结果(下载成功或下载失败)；

13.1、将下载结果显示到Web页面，具体可以通过Web服务将下载结果显示到云端服务器的Web页面和/或车载互联网关的Web页面上；

13.2、云端服务器通过车载互联网关或通过Web页面推送结果给用户；

13.3、云端服务器告知车载互联网关结束会话；

14、车载互联网关回归静默；

15、云端服务器通过车载互联网关向用户推送升级确认消息；

16、用户通过车载互联网关或web服务器或者短信等手段将用户确认/预约升级的消息告知云端服务器；

17、云端服务器向车载互联网关下发短信通知，以激活升级刷新流程；

18、车载互联网关向云端服务器发起会话请求；

19、云端服务器向车载互联网关下发获取数据命令(例如控制器的软件版本、备份包等)；

20、车载互联网关向云端服务器上报数据；

21、云端服务器向车载互联网关下发刷新命令；

22、车载互联网关向云端服务器反馈刷新命令执行结果；

23、云端服务器向车载互联网关下发获取刷新进度命令；

24、间隔一定时间，车载互联网关向云端服务器上报刷新进度；

25.1、将刷新进度显示到Web页面，具体可以通过Web服务将刷新进度显示到云端服务器的Web页面和/或车载互联网关的Web页面上；

25.2、云端服务器通过车载互联网关或通过Web页面推送刷新进度给用户；

25.3、云端服务器向车载互联网关下发获取刷新进度命令；

26、车载互联网关定时向云端服务器上报刷新进度；

27、车载互联网关定时向云端服务器上报刷新结果(刷新成功或刷新失败)；

28.1、将刷新结果显示到Web页面，具体可以通过Web服务将刷新结果显示到云端服务器的Web页面和/或车载互联网关的Web页面上；

28.2、云端服务器通过车载互联网关或通过Web页面推送刷新结果给用户；

28.3、若刷新成功，通知车载互连网关结束会话；

29、若刷新失败，云端服务器向车载互联网关下发获取回退进度指令(即回滚进度指令)；

30、间隔一定时间，车载互联网关向云端服务器上报回退进度(即回滚进度)；

31.1、将回退进度显示到Web页面，具体可以通过Web服务将回退进度显示到云端服务器的Web页面和/或车载互联网关的Web页面上；

31.2、云端服务器通过车载互联网关或通过Web页面推送回退进度给用户；

31.3、云端服务器向车载互联网关下发获取回退进度命令；

32、车载互联网关定时向云端服务器上报回退进度；

33、车载互联网关定时向云端服务器上报回退结果(即回滚结果)；

34.1、将回退结果显示到Web页面，具体可以通过Web服务将回退结果显示到云端服务器的Web页面和/或车载互联网关的Web页面上；

34.2、云端服务器通过车载互联网关或通过Web页面推送回退结果给用户；

34.3、回退结束，云端服务器通知车载互联网关结束会话；

35、升级刷新完成，车载互联网关回归静默。

需要说明的是，为了确保OTA整个刷新过程的进度和状态都可见，优选地，先对车载互联网关之外的智能控制器和非智能控制器进行升级刷新以及尝试回滚等，这些智能控制器和非智能控制器的升级刷新流程均执行完毕后，再刷新车载互联网关自己，对于自刷新，车载互联网关先通过SPI自刷新MCU，同时完成MPU的备份系统刷新，当MCU和MPU的备份系统都完成刷新时，通过重启车载互联网关切换到最新的软件状态，其中当MCU和MPU的备份系统都完成刷新任意刷新失败时，也可以进一步判断自刷新尝试次数是否达到最大重试次数，若没有达到最大重试次数，则进一步尝试自刷新，直至在达到最大重试次数之前自刷新成功，在达到最大重试次数仍旧没成功，则对自刷新失败的MCU或MPU的备份系统进行回滚。其中，这种在一次刷新失败时进行回滚的策略，可以避免因总线故障、信号干扰或所述车辆上的控制器和车载互联网关与升级刷新的版本不兼容的情况而引起刷新失败，进而导致车辆上的控制器和车载互联网关不能正常工作的问题。

为统一策略，提高OTA刷新方案的整体安全性以及兼容智能控制器和非智能控制器的刷新需求，优选地，所述的车辆OTA升级方法还包括：所述车载互联网关在对所述车辆上的智能控制器和非智能控制器进行升级刷新之前，所述车载互联网关先将从所述升级包中解析出的第一升级刷新数据以及第二升级刷新数据转换为统一的文件格式，所述统一的文件格式具有上文中的文件解析模块转换出的所述的四类文件，具体内容在此不再赘述。所述车载互联网关采用不同的加密和校验方式对所述四类文件进行配置，在对所述车辆上的智能控制器和非智能控制器进行升级刷新的过程中，将所述四类文件保存在所述车辆本地的嵌入式多媒体存储eMMC系统中，并对所有的所述四类文件全生命周期保持加密，且将加密的信息在MCU和MPU内部交叉存放并实现互相校验；在所述车辆的某个所述控制器的升级刷新流程被触发时，所述车载互联网关动态解密各个所述控制器对应的所述四类文件并临时保存，且在发生断电时，自动清除动态解密出的所有数据。

优选地，在所述车载互联网关在对所述车辆上的智能控制器和非智能控制器进行升级刷新时，所述车载互联网关按照所述车辆上的各个控制器的模块划分，来对所述车辆上的各个控制器进行模块级的升级刷新，以对某个控制仅更新其中的某个标定数据或应用程序，由此节省流量且缩短刷新时间

本发明一实施例还提供一种计算机存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时，能实现本发明所述的车辆OTA升级方法。所述计算机存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备，例如可以是但不限于电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机存储介质的更具体的例子(非穷举的列表)包括：便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、静态随机存取存储器(SRAM)、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。这里所描述的计算机程序可以从计算机存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收所述计算机程序，并转发该计算机程序，以供存储在各个计算/处理设备中的计算机存储介质中。用于执行本发明操作的计算机程序可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，所述编程语言包括面向对象的编程语言—诸如Smalltalk、C++等，以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。所述计算机程序可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机程序的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA)，该电子电路可以执行计算机可读程序指令，从而实现本发明的各个方面。

这里参照根据本发明实施例的方法、系统和计算机程序产品的流程图和/或框图描述了本发明的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机程序实现。这些计算机程序可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器，从而生产出一种机器，使得这些程序在通过计算机或其它可编程数据处理装置的处理器执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机程序存储在计算机存储介质中，这些计算机程序使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有该计算机程序的计算机存储介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机程序加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的计算机程序实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

综上所述，本发明的技术方案，采用一个车载互联网关能完成现有的OTA升级方法中的车载车联网终端T-BOX和网关GW等多个主节点的所有功能，因此可以减少通信链路，屏蔽了这些主节点之间交互的细节，增加了数据保护能力，缩短了OTA升级方案的开发周期；不仅可以对车辆上的智能控制器进行OTA升级刷新，还能对车辆上的非智能控制器进行OTA升级刷新，无需跨领域合作就能形成完整的OTA服务；而且采用一个车载互联网关作为主节点，可以对车联网的所有子网(即车辆上的所有智能控制器和非智能控制器)实施并行刷新，以减少刷新时间，并可以形成统一的OTA升级刷新策略，不会因为车辆的车型配置变换或车辆上的控制器供应商变更而导致OTA升级刷新策略变更，由此可以给汽车开发商OEM带来极大的便利；所述车载互联网关能够为OTA升级刷新定义出灵活安全的统一的文件格式，可以兼容车辆上的智能控制器和非智能控制器的升级刷新，便于车辆上的所有的控制器统一管理；此外，还可以针对车辆上的各个控制器的升级刷新进行深度定制，例如为车辆上的多个控制器设定刷新顺序，以按照设定的刷新顺序对这些控制器进行升级刷新，以提高升级刷新的成功率，并缩短刷新时间；再例如将各个所述控制器进行模块划分，以对某个控制器的某个模块或者几个模块进行单独刷新，以节省流量且可以缩短刷新时间；进一步地，设计了相应的错误处理和回滚策略，例如刷新过程中因为总线故障、信号干扰或发现控制器的升级版本不兼容时，依据刷新配置文件中配置的尝试次数重新启动刷新流程，如果多次尝试失败，还会尝试刷回之前的老版本；不仅可以对车辆上的智能控制器和非智能控制器进行升级刷新，还能对车载互联网关进行自刷新，以保证车载互联网关的正常运行以及功能升级。

此外，应当认识到，本发明的技术方案实现了一站式OTA刷新策略，给汽车开发商OEM的OTA管理带来了极大的便利，必然会引领后续OTA的发展趋势，如果把无线互联功能和网关功能集成到其他控制器中，也能带来一站式的效果，本质实现原理和本文提到的是相同的，也属于本发明的保护范围。

针对车载刷新过程的深度定制设计，比如刷新顺序配置、模块级刷新管理、刷新错误处理和回滚策略，也是本发明技术方案的一大优势，其中设定的统一的文件格式可以进行相应的变通设计，但只要实现的核心思想还是上述的内容，就属于本发明的保护范围。因此，本领域的技术人员可以对发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (28)

1.一种车载互联网关，安装在一车辆上，其特征在于，包括：

微处理器，其被配置为与云端交互以接收所述云端下发的升级包，并从所述升级包中解析出第一升级刷新数据和第二升级刷新数据，以及根据所述第一升级刷新数据对所述车辆上的智能控制器进行升级刷新，其中，所述第一升级刷新数据用于对所述车辆上的智能控制器进行升级刷新，所述第二升级刷新数据用于对所述车辆上的非智能控制器进行升级刷新；

微控制器，其被配置为与所述微处理器通信连接，并在所述微处理器解析出所述第二升级刷新数据时被所述微处理器触发，以根据所述微处理器下发的所述第二升级刷新数据对所述车辆上的非智能控制器进行升级刷新。

2.如权利要求1所述的车载互联网关，其特征在于，所述微处理器包括：

云端交互模块，其被配置为与所述云端建立安全通信链路，以从所述云端下载所述升级包；

文件解析模块，其被配置为对所述升级包进行文件解析，以从所述升级包中解析出用于对所述车辆上的智能控制器进行升级刷新的第一升级刷新数据以及用于对所述车辆上的非智能控制器进行升级刷新的第二升级刷新数据；

智能控制器客户端模块，其被配置为与所述车辆上的智能控制器通信连接，以根据所述第一升级刷新数据对所述车辆上的智能控制器进行升级刷新；以及，

通信服务端模块，其被配置为通过通信总线与所述微控制器通信连接，在所述文件解析模块解析出所述第二升级刷新数据时触发所述微控制器，并将所述第二升级刷新数据下发至所述微控制器。

3.如权利要求2所述的车载互联网关，其特征在于，所述文件解析模块进一步被配置为对所述升级包进行文件解析，并将从所述升级包中解析出的包括所述第一升级刷新数据和所述第二升级刷新数据在内的文件转换为统一的文件格式。

4.如权利要求3所述的车载互联网关，其特征在于，所述统一的文件格式包括:用于描述对所述车辆进行一次OTA刷新的需求的升级包配置文件、用于描述各个所述智能控制器和所述非智能控制器的刷新信息的控制器刷新配置文件、用于刷新各个所述智能控制器和所述非智能控制器的原始数据刷新文件以及差分数据刷新文件四类文件；其中，所述升级包配置文件包含所述车辆上需要刷新的控制器数量、基本的刷新信息以及整体刷新包的校验信息；所述控制器刷新配置文件包含某个所述智能控制器或所述非智能控制器具体需要刷新的文件数量、地址范围、安全算法信息和校验方法信息；所述原始数据刷新文件和所述差分数据刷新文件均包含文件头和文件内容，所述文件头用于描述文件内容的版本信息和校验信息。

5.如权利要求4所述的车载互联网关，其特征在于，所述文件解析模块进一步被配置为：将所述四类文件保存在所述车辆本地的嵌入式多媒体存储器中，并对所有的所述四类文件全生命周期保持加密，且将加密的信息在所述微处理器和微控制器中交叉存放并实现互相校验；所述智能控制器客户端或所述微控制器进一步被配置为：在所述车辆的某个所述控制器的升级刷新被触发时，动态解密所述控制器对应的所述四类文件并临时保存，且在车载互联网关发生断电时，清除动态解密出的所有数据。

6.如权利要求5所述的车载互联网关，其特征在于，所述文件解析模块进一步被配置为：对每次刷新时的所述四类文件配置不同的加密和校验方式，且每次刷新时转换的所述控制器刷新配置文件中包含相应的所述智能控制器或所述非智能控制器的模块划分信息；所述智能控制器客户端模块进一步被配置为：根据所述智能控制器的每个模块的前一次升级刷新的软件版本以及所述文件解析模块从本次的升级包中的所述第一升级刷新数据转换出的所述四类文件，对所述智能控制器中需要升级刷新的模块进行模块级的升级刷新。

7.如权利要求3所述的车载互联网关，其特征在于，所述控制器刷新配置文件中包括升级刷新的尝试次数；所述智能控制器客户端模块进一步被配置为：当升级刷新某个所述智能控制器失败时，依据所述智能控制器对应的所述控制器刷新配置文件中配置的尝试次数重新启动对所述智能控制器的刷新流程，并在所述尝试次数全部尝试失败后，进一步尝试将所述智能控制器的软件版本刷回上次升级刷新成功时的软件版本。

8.如权利要求2所述的车载互联网关，其特征在于，所述智能控制器客户端模块进一步被配置为：获取所述车辆上的智能控制器之间的依赖关系，并根据所述依赖关系确定所述智能控制器的刷新顺序，以及按照所述刷新顺序对相应的智能控制器进行升级刷新。

9.如权利要求2所述的车载互联网关，其特征在于，所述文件解析模块从所述升级包中解析出的数据还包括用于对所述车载互联网关进行升级刷新的第三升级刷新数据；所述微处理器还包括自升级模块，其被配置为当所述文件解析模块从所述升级包中解析所述第三升级刷新数据时，根据所述第三升级刷新数据对所述微控制器及所述微处理器自身进行升级刷新。

10.如权利要求1或9所述的车载互联网关，其特征在于，所述微处理器为具有主系统和备份系统的双备份系统，所述主系统被配置为先对所述车辆上的所述智能控制器进行升级刷新，后对所述微控制器以及所述备份系统进行升级刷新；所述备份系统用于在所述车载互联网关重启时对所述微处理器的主系统进行升级刷新。

11.如权利要求2所述的车载互联网关，其特征在于，所述微控制器包括：

通信客户端模块，其被配置为通过通信总线与所述通信服务端模块通信连接，以接收所述通信服务端模块下发的所述第二升级刷新数据，以及向所述通信服务端模块反馈所述非智能控制器的升级刷新进度；以及，

传统控制器管理模块，其被配置为与所述车辆上的各个所述非智能控制器通信连接，并根据所述第二升级刷新数据对相应的所述非智能控制器进行升级刷新以及将所述非智能控制器的升级刷新进度反馈至所述通信客户端模块。

12.如权利要求11所述的车载互联网关，其特征在于，所述传统控制器管理模块包括：

传统控制器客户端单元，其被配置为接收所述第二升级刷新数据并获取用于验证和解析所述第二升级刷新数据的相关信息，以及，获取所述车辆上的非智能控制器的软件版本信息，并根据所述第二升级刷新数据对所述车辆上的非智能控制器进行升级刷新，以及将升级刷新的进度反馈至所述通信客户端模块；

文件校验单元，其被配置为根据所述传统控制器客户端单元获取的用于验证所述第二升级刷新数据的相关信息，验证所述文件解析模块下发的所述第二升级刷新数据的合法性；

文件解析单元，其被配置为根据所述传统控制器客户端单元获取的用于解析所述第二升级刷新数据的相关信息，对所述第二升级刷新数据进行解析；

刷新流程控制单元，其被配置为通过传统控制器客户端单元获取所述车辆上的非智能控制器之间的依赖关系，并根据所述依赖关系确定所述非智能控制器的刷新顺序，所述传统控制器客户端单元进一步被配置为根据所述刷新顺序以及所述文件解析单元解析的数据对所述车辆上的非智能控制器进行升级刷新。

13.如权利要求12所述的车载互联网关，其特征在于，所述微控制器还包括：

硬件安全模块，其被配置为对所述微控制器接收和向外发送的数据进行加密，并对所述第一升级刷新数据和所述第二升级刷新数据中的加密信息进行映射存储；以及，

启动加载模块，其被配置为在所述文件解析模块从所述升级包中解析出用于对所述车载互联网关进行升级刷新的第三升级刷新数据时，根据所述第三升级刷新数据对所述微控制器自身进行升级刷新。

14.如权利要求12所述的车载互联网关，其特征在于，所述第二升级刷新数据中包含所述非智能控制器的模块划分信息；所述传统控制器客户端单元进一步被配置为：根据所述车辆上的所述非智能控制器的每个模块的前一次升级刷新的软件版本以及所述文件解析单元对本次升级包中的所述第二升级刷新数据的解析结果，对所述非智能控制器中需要升级刷新的模块进行模块级的升级刷新。

15.如权利要求12所述的车载互联网关，其特征在于，所述文件解析单元对本次升级包中的所述第二升级刷新数据的解析结果中包括本次升级刷新的尝试次数；所述传统控制器客户端单元进一步被配置为：当升级刷新所述非智能控制器失败时，依据所述非智能控制器对应的所述尝试次数重新启动对所述非智能控制器的刷新流程，并在所述尝试次数全部尝试失败后，进一步尝试将所述非智能控制器的软件版本刷回上次升级刷新的软件版本。

16.如权利要求12所述的车载互联网关，其特征在于，所述传统控制器客户端单元进一步被配置为对所述车辆上的多个所述非智能控制器并行升级刷新，并依据各个所述非智能控制器的升级刷新的进度，实时向所述微处理器请求所述非智能控制器的升级刷新数据。

17.一种车辆OTA升级系统，其特征在于，包括：

云端服务器，其上存储有至少一个升级包；

安装在车辆上的智能控制器和非智能控制器；以及，

权利要求1至16中任一项所述的车载互联网关，所述车载互联网关分别与所述云端服务器以及各个所述智能控制器和所述非智能控制器通信连接。

18.一种车辆OTA升级方法，其特征在于，包括：

一车载互联网关与云端建立通信连接，以接收所述云端下发的升级包；

所述车载互联网关从所述升级包中解析出用于对车辆上的各个控制器进行升级刷新的升级刷新数据，其中，所述控制器包括智能控制器和非智能控制器，所述升级刷新数据包括用于对所述智能控制器进行升级刷新的第一升级刷新数据以及用于对所述非智能控制器进行升级刷新的第二升级刷新数据；

所述车载互联网关根据所述第一升级刷新数据对所述车辆上的智能控制器进行升级刷新，并在解析出所述第二升级刷新数据时触发对所述车辆上的非智能控制器进行升级刷新的流程，以根据解析出的所述第二升级刷新数据对所述车辆上的非智能控制器进行升级刷新。

19.如权利要求18所述的车辆OTA升级方法，其特征在于，所述车载互联网关对所述车辆上的某个所述控制器进行升级刷新的步骤包括：

读取所述控制器的软件版本；

判断所述车辆本地上是否具有对应所述软件版本的备份包，若有，则从所述云端下载所述升级包，若无，则向所述云端请求下载备份包；

在下载好所述升级包后，判断所述控制器当前所处的环境条件是否满足刷新条件，若否，则结束退出，若是，则触发对所述智能控制器和/或非智能控制器进行升级刷新的流程，并依据从所述升级包中解析出的所述控制器对应的升级刷新数据对所述控制器进行升级刷新，当本次的所述升级刷新失败时，依据所述升级刷新数据中配置的尝试次数重新启动所述流程，当所述尝试次数全部尝试完但对所述控制器的升级刷新依旧失败时，进一步尝试将所述控制器的软件版本刷回上次升级刷新的软件版本。

20.如权利要求18所述的车辆OTA升级方法，其特征在于，还包括：当所述车载互联网关根据所述第一升级刷新数据和所述第二升级刷新数据对所述车辆上所有的智能控制器和非智能控制器进行升级刷新完成后，判断从所述升级包中解析出的升级刷新数据是否有用于对所述车载互联网关自身进行升级刷新的第三升级刷新数据，当有时，根据所述第三升级刷新数据进行自刷新。

21.如权利要求18所述的车辆OTA升级方法，其特征在于，还包括：所述车载互联网关在对所述车辆上的智能控制器和非智能控制器进行升级刷新之前，先将从所述升级包中解析出的第一升级刷新数据以及第二升级刷新数据转换为统一的文件格式。

22.如权利要求21所述的车辆OTA升级方法，其特征在于，所述统一的文件格式包括：用于描述对所述车辆进行一次OTA刷新的需求的升级包配置文件、用于描述所述车辆上的各个所述控制器的刷新信息的控制器刷新配置文件、用于刷新各个所述控制器的原始数据刷新文件以及差分数据刷新文件四类文件；其中，所述升级包配置文件包含所述车辆上需要刷新的控制器数量、基本的刷新信息以及整体刷新包的校验信息；所述控制器刷新配置文件包含某个所述控制器具体需要刷新的文件数量、地址范围、安全算法信息和校验方法信息；所述原始数据刷新文件和所述差分数据刷新文件均包含文件头和文件内容，所述文件头用于描述文件内容的版本信息和校验信息。

23.如权利要求22所述的车辆OTA升级方法，其特征在于，所述车载互联网关采用不同的加密和校验方式对所述四类文件进行配置，在对所述车辆上的智能控制器和非智能控制器进行升级刷新的过程中，将所述四类文件保存在所述车辆本地的嵌入式多媒体存储器中，并对所有的所述四类文件全生命周期保持加密，且将加密的信息在内部交叉存放并实现互相校验；在所述车辆的某个所述控制器的升级刷新流程被触发时，动态解密所述控制器对应的所述四类文件并临时保存，且在发生断电时，自动清除动态解密出的所有数据。

24.如权利要求18所述的车辆OTA升级方法，其特征在于，所述车载互联网关在对所述车辆上的智能控制器和非智能控制器进行升级刷新之前，先确定所述车辆上的所述控制器之间的依赖关系，并制定一套依赖算法来确定有依赖关系的所述控制器之间的刷新顺序，再依据所述刷新顺序对有依赖关系的所述控制器进行升级刷新，且对刷新顺序不敏感的所述控制器进行并行刷新。

25.如权利要求18所述的车辆OTA升级方法，其特征在于，所述车载互联网关在对所述车辆上的智能控制器和非智能控制器进行升级刷新的过程中，当有总线故障或信号干扰或所述车辆上的某个所述控制器与其升级刷新的版本不兼容的情况时，所述车载互联网关会依据所述控制器对应的升级刷新数据中配置的尝试次数重新启动对所述控制器的刷新流程，并在所有尝试次数均尝试失败时，尝试将所述控制器的软件版本刷回上次升级刷新后的版本。

26.如权利要求18所述的车辆OTA升级方法，其特征在于，所述车载互联网关按照所述车辆上的某个所述控制器的模块划分，对所述控制器进行模块级的升级刷新。

27.一种计算机存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，实现权利要求18至26中任一项所述的车辆OTA升级方法。

28.一种车辆，其特征在于，包括：

多个控制器，所述控制器包括智能控制器和非智能控制器；以及，

权利要求1至16中任一项所述的车载互联网关，所述车载互联网关与云端交互，并与各个所述控制器通信连接。

Images