CN111930407B - 车辆ecu软件升级方法、系统、车载tbox的微控制器和soc端 - Google Patents

Abstract

本发明公开了一种车辆ECU软件升级方法，应用于车载TBOX的微控制器，所述方法包括：响应于接收到的由车载TBOX的SOC端在满足允许进行ECU软件升级条件下发送的ECU刷新请求，进行ECU软件升级前的预处理；接收所述SOC端发送的当前从ECU软件升级包拆分出来的数据块，并将所述数据块发送至对应的ECU进行数据刷写，直到将接收到的最后一块从所述ECU软件升级包拆分出来的数据块发送至所述ECU进行数据刷写；所述ECU软件升级包是所述SOC端预先获得的。本发明还公开了一种车载TBOX的微控制器、一种车载TBOX的SOC端和一种车辆ECU软件升级系统。采用本发明实施例，能有效降低OTA升级时数据传输失败的风险，提高了刷新ECU软件的效率，同时无需增加外设，降低硬件成本。

Description

车辆ECU软件升级方法、系统、车载TBOX的微控制器和SOC端

技术领域

本发明涉及车辆控制技术领域，尤其涉及一种车辆ECU软件升级方法、系统、车载TBOX的微控制器和SOC端。

背景技术

汽车OTA(Over The Air，空间下载)技术是指通过移动通信的空中接口对汽车的软件进行远程升级的过程。随着汽车电气化的推行以及软件定义汽车趋势的发展，近年新车型所安装的ECU（Electronic Control Unit，电子控制单元）数目增加到60个以上，这也意味着汽车软件的复杂程度日益增加，在开发周期有限的情况下，对ECU进行升级显得愈发重要和紧迫。现阶段车辆中的TBOX（Telematics BOX，远程信息处理器）通常以SOC（Systemon Chip，系统级芯片）和MCU（Micro Control Unit，微控制单元）双CPU作为主控制器。SOC控制器主要负责通信功能，实现与云端的互联以及与多媒体设备的交互，MCU控制器实现与传统的车载ECU（车身控制器、座椅控制器等）的功能交互。

现有常用的通过OTA技术实现ECU节点升级的方式包括：通过在MCU外挂FLASH的方式存储ECU的软件升级包，整车其他ECU的刷新流程不需要SOC的参与，在进行更新之前，将软件升级包存储在MCU外挂的FLASH中，整个刷新流程只有MCU通过CAN总线与相关ECU节点进行通信和功能交互。传统升级方式将所有功能逻辑放到MCU中，实际的刷写速度和效果会因为MCU的性能而受限，在刷写其他ECU节点之前，需要先将软件升级包传输到MCU外挂的FLASH中，提升传输失败的风险同时降低了刷新的效率，不能做到实时刷新。另外，传统OTA技术额外增加了外设，需要改动硬件的架构，增加了硬件成本。

发明内容

本发明实施例的目的是提供一种车辆ECU软件升级方法、系统、车载TBOX的微控制器和SOC端，能有效降低OTA升级时数据传输失败的风险，提高了刷新ECU软件的效率，同时无需增加外设，降低硬件成本。

为实现上述目的，本发明实施例提供了一种车辆ECU软件升级方法，应用于车载TBOX的微控制器，所述方法包括：

响应于接收到的由车载TBOX的SOC端在满足允许进行ECU软件升级条件下发送的ECU刷新请求，进行ECU软件升级前的预处理；

接收所述SOC端发送的当前从ECU软件升级包拆分出来的数据块，并将所述数据块发送至对应的ECU进行数据刷写，直到将接收到的最后一块从所述ECU软件升级包拆分出来的数据块发送至所述ECU进行数据刷写；所述ECU软件升级包是所述SOC端预先获得的。

作为上述方案的改进，每一所述数据块包括帧头、帧尾和软件升级数据；则，在将所述数据块发送至ECU进行数据刷写之前，所述方法还包括：

通过所述帧头判断所述数据块的消息类型；

对所述软件升级数据进行CRC计算，得到所述数据块的校验值；

将所述数据块的校验值与预存在所述帧尾中的CRC值进行比对，以得到所述数据块的数据校验结果；

若数据块的数据校验结果为校验成功，则执行所述将所述数据块发送至ECU进行数据刷写。

作为上述方案的改进，在所述将接收到的最后一块所述数据块发送至所述ECU进行数据刷写之后，所述方法还包括：

对整车ECU进行复位；

根据接收到由所述SOC端发送的升级校验指令，控制所述ECU启动本地当前的ECU软件；

接收所述ECU返回的当前启动的ECU软件的版本号并发送给所述SOC端，以使得所述SOC端根据接收到的所述版本号与预先获得的所述ECU软件升级包的版本号的比对，来确定所述ECU的ECU软件升级包是否升级成功。

作为上述方案的改进，所述允许进行ECU软件升级条件包括：

检测到车辆车速为0、电池电量大于50%和车辆中的点火开关控制端子处于关闭状态中的至少一种。

作为上述方案的改进，所述进行ECU升级前的预处理，包括以下至少一种：

进入ECU诊断会话模式；

关闭网络中所有ECU的DTC检测和存储功能；

控制PEPS进入boot模式；

禁止CAN网络上所有ECU的非诊断报文的发送和接收。

作为上述方案的改进，将所述数据块发送至ECU进行数据刷写，包括：

将所述数据块发送至ECU进行UDS诊断刷新，以使得所述ECU将UDS诊断刷新成功的数据刷写入所述ECU的应用存储区中。

作为上述方案的改进，在将数据块发送至ECU进行数据刷写之后，所述方法还包括：

接收所述ECU反馈的对所述数据块的数据刷写结果及刷写进度并上报给所述SOC端。

作为上述方案的改进，所述微控制器的内存具有两个内存区；则，所述接收所述SOC端发送的当前从ECU软件升级包拆分出来的数据块，并将所述数据块发送至对应的ECU进行数据刷写，包括：

将接收到的所述SOC端发送的当前从ECU软件升级包拆分出来的当前数据块存入两个内存区中的为空闲状态的内存区，待另一个内存区将其自身存有的数据块发送至对应的ECU进行数据刷写完毕后，再将接收到的所述当前数据块发送至所述ECU进行数据刷写。

为实现上述目的，本发明实施例还提供了一种车辆ECU软件升级方法，应用于车载TBOX的SOC端，包括：

响应于满足允许进行ECU软件升级条件，向车载TBOX的微控制器发送ECU刷新请求，以使得所述微控制器进行ECU软件升级前的预处理；

对预先获得的ECU软件升级包进行数据块拆分，并将当前从ECU软件升级包拆分出来的数据块发送给所述微控制器，直到将最后一块拆分出来的所述数据块发送给所述微控制器；其中，所述微控制器将接收到的所述数据块发送至对应的ECU进行数据刷写。

为实现上述目的，本发明实施例还提供了一种车载TBOX的微控制器，包括处理器、存储器以及存储在所述存储器中且被配置为由所述处理器执行的计算机程序，所述处理器执行所述计算机程序时实现如上述任一实施例所述的车辆ECU软件升级方法。

为实现上述目的，本发明实施例还提供了一种车载TBOX的SOC端，包括处理器、存储器以及存储在所述存储器中且被配置为由所述处理器执行的计算机程序，所述处理器执行所述计算机程序时实现如上述任一实施例所述的车辆ECU软件升级方法。

为实现上述目的，本发明实施例还提供了一种车辆ECU软件升级系统，包括ECU和TBOX，所述TBOX包括如上述实施例所述的微控制器和如上述实施例所述的SOC端；其中，所述SOC端与所述微控制器连接，所述微控制器还与所述ECU连接。

相比于现有技术，本发明实施例公开的车辆ECU软件升级方法、系统、车载TBOX的微控制器和SOC端，将ECU软件升级包的拆分、传输过程以及升级进度的上报、与OTA刷新控制进程的交互移植到了SOC侧完成，MCU侧仅负责UDS诊断刷新的流程逻辑控制。双CPU（MCU和SOC）进行刷新任务的合理分工，提升了刷写的性能，有效降低OTA升级时数据传输失败的风险。同时，不需要在升级之前将ECU的软件升级包从SOC侧传输到MCU侧进行存储，可以在SOC传送升级包数据到MCU的同时进行诊断刷新，提升了刷写的效率和连续性。另外，为了提升刷写的效率，在MCU侧同时申请了两块同样大小的静态内存，在一块内存中的数据进行UDS刷写更新的同时，另外一块空闲的静态内存会接收SOC传输过来的下一包数据，通过两块内存的交互使用，无需增加外设，降低硬件成本。

附图说明

图1是本发明实施例提供的一种车辆ECU软件升级方法的流程图；

图2是本发明实施例提供的另一种车辆ECU软件升级方法的流程图；

图3是本发明实施例提供的另一种车载TBOX的微控制器的结构框图；

图4是本发明实施例提供的另一种车载TBOX的SOC端的结构框图；

图5是本发明实施例提供的一种车辆ECU软件升级系统的结构框图。

具体实施方式

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

参见图1，图1是本发明第一实施例提供的一种车辆ECU软件升级方法的流程图，所述车辆ECU软件升级方法包括：

S11、响应于接收到的由车载TBOX的SOC端在满足允许进行ECU软件升级条件下发送的ECU刷新请求，进行ECU软件升级前的预处理；

S12、接收所述SOC端发送的当前从ECU软件升级包拆分出来的数据块，并将所述数据块发送至对应的ECU进行数据刷写，直到将接收到的最后一块从所述ECU软件升级包拆分出来的数据块发送至所述ECU进行数据刷写；所述ECU软件升级包是所述SOC端预先获得的。

值得说明的是，本发明实施例所述的车辆ECU软件升级方法可以由车载TBOX的微控制器执行实现，所述微控制器为MCU，所述MCU分别连接SOC端和车辆中的若干个ECU。

具体地，在步骤S11中，当车辆需要通过OTA技术进行远程升级时，首先OTA policy检查车辆中的参数是否符合预设的允许进行ECU软件升级条件，若符合，则发起ECU节点的刷新动作。示例性的，所述允许进行ECU软件升级条件包括：检测到车辆车速为0、电池电量大于50%和车辆中的点火开关控制端子（IG）处于关闭状态中的至少一种。

在满足所述允许进行ECU软件升级条件后，SOC端还需要对ECU软件升级包进行校验，防止数据被恶意篡改，在检验成功后发送ECU刷新请求给微控制器。示例性的，所述SOC端对ECU软件升级包进行校验的过程包括步骤S101~S104：

S101、获取预存在所述ECU软件升级包的BIN文件中的CRC32值；

S102、对所述BIN文件中的数据部分进行CRC计算，得到数据的校验值；

S103、判断所述数据的校验值与所述CRC32值是否相等；

S104、若是，则判定对所述ECU软件升级包校验成功；若否，则判定对所述ECU软件升级包校验失败。

进一步地，所述进行ECU软件升级前的预处理，包括步骤S111~S115中的至少一种，步骤S111~S115：

S111、进入ECU诊断会话模式；诊断会话模式是一种ECU的拓展模式，在扩展模式会执行有效的应用程序；

S112、关闭网络中所有ECU的DTC（Diagnostic Trouble Code，诊断故障代码）检测和存储功能；为了避免误报故障，应该关闭网络中所有ECU的DTC检测和存储功能；

S113、控制PEPS（Passive Entry Passive Start，智能进入及启动系统）进入boot模式；PEPS不允许被刷新；

S114、禁止CAN网络上所有ECU的非诊断报文的发送和接收。

S115、进行刷写条件的检查；用于检查系统的状态是否为安全状态，比如车速为0，ECU处于正常工作的电压状态下。

具体地，在步骤S12中，接收所述SOC端发送的当前从ECU软件升级包拆分出来的数据块，并将所述数据块发送至对应的ECU进行数据刷写，直到将接收到的最后一块所述数据块发送至所述ECU进行数据刷写。值得说明是，因为ECU软件升级包是存储在SOC一侧的，需要通过SPI（Serial Peripheral Interface，串行外设接口）传输到MCU侧进行刷新，而SPI的传输带宽有限，所以需要在SOC侧将ECU软件升级包拆分之后才能通过SPI进行传输。

具体地，每一所述数据块包括帧头、帧尾和软件升级数据，则，在将所述数据块发送至ECU进行数据刷写之前，MCU还需要对数据块进行校验，防止数据被篡改，此时所述方法还包括步骤S121~S124：

S121、通过所述帧头判断所述数据块的消息类型；

S122、对所述软件升级数据进行CRC计算，得到所述数据块的校验值；

S123将所述数据块的校验值与预存在所述帧尾中的CRC值进行比对，以得到所述数据块的数据校验结果；

S124、若数据块的数据校验结果为校验成功，则执行所述将所述数据块发送至ECU进行数据刷写。

示例性的，帧头的部分一般是标识符，标识这帧SPI消息的类型，帧尾一般是CRC校验值，可以用来校验这一帧SPI的数据是不是没有被篡改过。SOD端将帧头+软件升级数据+帧尾组成了一帧SPI帧（即数据块），并将SPI帧发送给MCU。MCU在接收到一帧SPI消息之后，首先通过帧头判断SPI消息的类型，然后通过CRC32计算出这一帧软件升级数据的CRC校验值，与帧尾的CRC值做比对，完成校验，最后把ECU软件升级包的数据从这一帧SPI消息中拆分出来。

可选地，将所述数据块发送至ECU进行数据刷写，包括：将所述数据块发送至ECU进行UDS诊断刷新，以使得所述ECU将UDS诊断刷新成功的数据刷写入所述ECU的应用存储区中。

在本发明实施例中，MCU利用UDS诊断服务不仅仅可以获取和管理ECU的故障记录信息，并且还可以读取写入ECU软硬件信息、生产制造信息、实施检测和测试、以及更新代码。

可选地，在将数据块发送至ECU进行数据刷写之后，所述方法还包括：接收所述ECU反馈的对所述数据块的数据刷写结果及刷写进度并上报给所述SOC端。

可选地，MCU在完成数据拆包、校验之后，通过34、36、37服务将数据写入EUC控制器应用存储区。34服务：请求数据下载，上位机（这里是TBOX）将传输块的起始地址和长度通过34服务下发，进行下载请求，ECU节点回复该节点支持的最大刷新BLOCK的长度。36服务：数据传输，36服务用来传输刷新包的一包数据，具体长度由34服务响应返回的最大支持长度来确定。37服务：请求退出传输，每次完成一个数据块（segment）的传输之后都需要37服务。

进一步地，在所述将接收到的最后一块所述数据块发送至所述ECU进行数据刷写之后，所述方法还包括步骤S13~S15：

S13、对整车ECU进行复位；

S14、根据接收到由所述SOC端发送的升级校验指令，控制所述ECU启动本地当前的ECU软件；

S15、接收所述ECU返回的当前启动的ECU软件的版本号并发送给所述SOC端，以使得所述SOC端根据接收到的所述版本号与预先获得的所述ECU软件升级包的版本号的比对，来确定所述ECU的ECU软件升级包是否升级成功。

更进一步地，所述微控制器的内存具有两个内存区，通过两块内存的交互使用，无需增加外设，降低硬件成本；则，所述接收所述SOC端发送的当前从ECU软件升级包拆分出来的数据块，并将所述数据块发送至对应的ECU进行数据刷写，包括：

将接收到的所述SOC端发送的当前从ECU软件升级包拆分出来的当前数据块存入两个内存区中的为空闲状态的内存区，待另一个内存区将其自身存有的数据块发送至对应的ECU进行数据刷写完毕后，再将接收到的所述当前数据块发送至所述ECU进行数据刷写。

相比于现有技术，本发明实施例公开的车辆ECU软件升级方法，将ECU软件升级包的拆分、传输过程以及升级进度的上报、与OTA刷新控制进程的交互移植到了SOC侧完成，MCU侧仅负责UDS诊断刷新的流程逻辑控制。双CPU（MCU和SOC）进行刷新任务的合理分工，提升了刷写的性能，有效降低OTA升级时数据传输失败的风险。同时，不需要在升级之前将ECU的软件升级包从SOC侧传输到MCU侧进行存储，可以在SOC传送升级包数据到MCU的同时进行诊断刷新，提升了刷写的效率和连续性。另外，为了提升刷写的效率，在MCU侧同时申请了两块同样大小的静态内存，在一块内存中的数据进行UDS刷写更新的同时，另外一块空闲的静态内存会接收SOC传输过来的下一包数据，通过两块内存的交互使用，无需增加外设，降低硬件成本。

参见图2，图2是本发明第二实施例提供的一种车辆ECU软件升级方法的流程图，所述车辆ECU软件升级方法包括：

S21、响应于满足允许进行ECU软件升级条件，向车载TBOX的微控制器发送ECU刷新请求，以使得所述微控制器进行ECU软件升级前的预处理；

S22、对预先获得的ECU软件升级包进行数据块拆分，并将当前从ECU软件升级包拆分出来的数据块发送给所述微控制器，直到将最后一块拆分出来的所述数据块发送给所述微控制器；其中，所述微控制器将接收到的所述数据块发送至对应的ECU进行数据刷写。

值得说明的是，本发明实施例所述的车辆ECU软件升级方法可以由车载TBOX的SOC端执行实现，所述SOC端通过MCU连接车辆中的若干个ECU。

具体地，在步骤S21中，当车辆需要通过OTA技术进行远程升级时，首先OTA policy检查车辆中的参数是否符合预设的允许进行ECU软件升级条件，若符合，则发起ECU节点的刷新动作。示例性的，所述允许进行ECU软件升级条件包括：检测到车辆车速为0、电池电量大于50%和车辆中的点火开关控制端子（IG）处于关闭状态中的至少一种。

在满足所述允许进行ECU软件升级条件后，SOC端还需要对ECU软件升级包进行校验，防止数据被恶意篡改，在检验成功后向车载TBOX的微控制器发送ECU刷新请求。示例性的，所述SOC端对ECU软件升级包进行校验的过程包括步骤S201~S204：

S201、获取预存在所述ECU软件升级包的BIN文件中的CRC32值；

S202、对所述BIN文件中的数据部分进行CRC计算，得到数据的校验值；

S203、判断所述数据的校验值与所述CRC32值是否相等；

S204、若是，则判定对所述ECU软件升级包校验成功；若否，则判定对所述ECU软件升级包校验失败。

进一步地，所述微控制器进行ECU软件升级前的预处理，包括步骤S211~S215中的至少一种，步骤S211~S215：

S211、进入ECU诊断会话模式；诊断会话模式是一种ECU的拓展模式，在扩展模式会执行有效的应用程序；

S212、关闭网络中所有ECU的DTC（Diagnostic Trouble Code，诊断故障代码）检测和存储功能；为了避免误报故障，应该关闭网络中所有ECU的DTC检测和存储功能；

S213、控制PEPS（Passive Entry Passive Start，智能进入及启动系统）进入boot模式；PEPS不允许被刷新；

S214、禁止CAN网络上所有ECU的非诊断报文的发送和接收。

S215、进行刷写条件的检查；用于检查系统的状态是否为安全状态，比如车速为0，ECU处于正常工作的电压状态下。

具体地，在步骤S22中，对预先获得的ECU软件升级包进行数据块拆分，并将当前从ECU软件升级包拆分出来的数据块发送给所述微控制器，直到将最后一块拆分出来的所述数据块发送给所述微控制器，以使所述微控制器将接收到的所述数据块发送至对应的ECU进行数据刷写。

值得说明是，因为ECU软件升级包是存储在SOC一侧的，需要通过SPI（SerialPeripheral Interface，串行外设接口）传输到MCU侧进行刷新，而SPI的传输带宽有限，所以需要在SOC侧将ECU软件升级包拆分之后才能通过SPI进行传输。

具体地，每一所述数据块包括帧头、帧尾和软件升级数据，则，所述微控制器在将所述数据块发送至ECU进行数据刷写之前，所述微控制器还需要对所述数据块进行校验，校验过程包括步骤S221~S224：

S221、通过所述帧头判断所述数据块的消息类型；

S222、对所述软件升级数据进行CRC计算，得到所述数据块的校验值；

S223、将所述数据块的校验值与预存在所述帧尾中的CRC值进行比对，以得到所述数据块的数据校验结果；

S224、若数据块的数据校验结果为校验成功，则执行所述将所述数据块发送至ECU进行数据刷写。

示例性的，帧头的部分一般是标识符，标识这帧SPI消息的类型，帧尾一般是CRC校验值，可以用来校验这一帧SPI的数据是不是没有被篡改过。SOD端将帧头+软件升级数据+帧尾组成了一帧SPI帧（即数据块），并将SPI帧发送给MCU。MCU在接收到一帧SPI消息之后，首先通过帧头判断SPI消息的类型，然后通过CRC32计算出这一帧软件升级数据的CRC校验值，与帧尾的CRC值做比对，完成校验，最后把ECU软件升级包的数据从这一帧SPI消息中拆分出来。

可选地，所述微控制器将所述数据块发送至ECU进行数据刷写，包括：将所述数据块发送至ECU进行UDS诊断刷新，以使得所述ECU将UDS诊断刷新成功的数据刷写入所述ECU的应用存储区中。

在本发明实施例中，MCU利用UDS诊断服务不仅仅可以获取和管理ECU的故障记录信息，并且还可以读取写入ECU软硬件信息、生产制造信息、实施检测和测试、以及更新代码。

可选地，所述微控制器在将数据块发送至ECU进行数据刷写之后，还需要接收所述ECU反馈的对所述数据块的数据刷写结果及刷写进度并上报给所述SOC端。所述微控制器在完成数据拆包、校验之后，通过34、36、37服务将数据写入EUC控制器应用存储区。34服务：请求数据下载，上位机（这里是TBOX）将传输块的起始地址和长度通过34服务下发，进行下载请求，ECU节点回复该节点支持的最大刷新BLOCK的长度。36服务：数据传输，36服务用来传输刷新包的一包数据，具体长度由34服务响应返回的最大支持长度来确定。37服务：请求退出传输，每次完成一个数据块（segment）的传输之后都需要37服务。

进一步地，所述微控制器在所述将接收到的最后一块所述数据块发送至所述ECU进行数据刷写之后，还需要对整车ECU进行复位；所述SOC端会发送升级校验指令给所述微控制器，以使所述微控制器控制所述ECU启动本地当前的ECU软件，并接收所述ECU返回的当前启动的ECU软件的版本号并发送给所述SOC端，所述SOC端根据接收到的所述版本号与预先获得的所述ECU软件升级包的版本号的比对，来确定所述ECU的ECU软件升级包是否升级成功。

更进一步地，所述微控制器的内存具有两个内存区，通过两块内存的交互使用，无需增加外设，降低硬件成本；所述微控制器将接收到的所述SOC端发送的当前从ECU软件升级包拆分出来的当前数据块存入两个内存区中的为空闲状态的内存区，待另一个内存区将其自身存有的数据块发送至对应的ECU进行数据刷写完毕后，再将接收到的所述当前数据块发送至所述ECU进行数据刷写。

相比于现有技术，本发明实施例公开的车辆ECU软件升级方法，将ECU软件升级包的拆分、传输过程以及升级进度的上报、与OTA刷新控制进程的交互移植到了SOC侧完成，MCU侧仅负责UDS诊断刷新的流程逻辑控制。双CPU（MCU和SOC）进行刷新任务的合理分工，提升了刷写的性能，有效降低OTA升级时数据传输失败的风险。同时，不需要在升级之前将ECU的软件升级包从SOC侧传输到MCU侧进行存储，可以在SOC传送升级包数据到MCU的同时进行诊断刷新，提升了刷写的效率和连续性。另外，为了提升刷写的效率，在MCU侧同时申请了两块同样大小的静态内存，在一块内存中的数据进行UDS刷写更新的同时，另外一块空闲的静态内存会接收SOC传输过来的下一包数据，通过两块内存的交互使用，无需增加外设，降低硬件成本。

参见图3，图3是本发明第五实施例提供的一种车载TBOX的微控制器10的结构框图，所述车载TBOX的微控制器10包括处理器11、存储器12以及存储在所述存储器中并可在所述处理器上运行的计算机程序，例如行驶控制程序。所述处理器11执行所述计算机程序时实现上述第一实施例所述车辆ECU软件升级方法中的步骤，例如图1所示的步骤S11~S12。

示例性的，所述计算机程序可以被分割成一个或多个模块，所述一个或者多个模块被存储在所述存储器12中，并由所述处理器11执行，以完成本发明。所述一个或多个模块可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序在所述车载TBOX的微控制器10中的执行过程。

所述车载TBOX的微控制器10可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述车载TBOX的微控制器10可包括，但不仅限于，处理器11、存储器12。本领域技术人员可以理解，所述示意图仅仅是图像增强设备的示例，并不构成对车载TBOX的微控制器10的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述车载TBOX的微控制器10还可以包括输入输出设备、网络接入设备、总线等。

所称处理器11可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器 (Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列 (Field-Programmable Gate Array，FPGA) 或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，所述处理器11是所述车载TBOX的微控制器10的控制中心，利用各种接口和线路连接整个车载TBOX的微控制器10的各个部分。

所述存储器12可用于存储所述计算机程序和/或模块，所述处理器11通过运行或执行存储在所述存储器12内的计算机程序和/或模块，以及调用存储在存储器12内的数据，实现所述车载TBOX的微控制器10的各种功能。所述存储器12可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序（比如声音播放功能、图像播放功能等）等；存储数据区可存储根据手机的使用所创建的数据（比如音频数据、电话本等）等。此外，存储器12可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡（Smart Media Card, SMC），安全数字（SecureDigital, SD）卡，闪存卡（Flash Card）、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

其中，所述车载TBOX的微控制器10集成的模块如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、电载波信号、电信信号以及软件分发介质等。

参见图4，图4是本发明实施例提供的另一种车载TBOX的SOC端20的结构框图，所述车载TBOX的SOC端20包括处理器21、存储器22以及存储在所述存储器中并可在所述处理器上运行的计算机程序，例如行驶控制程序。所述处理器21执行所述计算机程序时实现上述第二实施例所述的车辆ECU软件升级方法中的步骤，例如图2所示的步骤S21~S22。

示例性的，所述计算机程序可以被分割成一个或多个模块，所述一个或者多个模块被存储在所述存储器22中，并由所述处理器21执行，以完成本发明。所述一个或多个模块可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序在所述车载TBOX的SOC端20中的执行过程。

所述车载TBOX的SOC端20可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述车载TBOX的SOC端20可包括，但不仅限于，处理器21、存储器22。本领域技术人员可以理解，所述示意图仅仅是图像增强设备的示例，并不构成对车载TBOX的SOC端20的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述车载TBOX的SOC端20还可以包括输入输出设备、网络接入设备、总线等。

所称处理器21可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器 (Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列 (Field-Programmable Gate Array，FPGA) 或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，所述处理器21是所述车载TBOX的SOC端20的控制中心，利用各种接口和线路连接整个车载TBOX的SOC端20的各个部分。

所述存储器22可用于存储所述计算机程序和/或模块，所述处理器21通过运行或执行存储在所述存储器22内的计算机程序和/或模块，以及调用存储在存储器22内的数据，实现所述车载TBOX的SOC端20的各种功能。所述存储器22可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序（比如声音播放功能、图像播放功能等）等；存储数据区可存储根据手机的使用所创建的数据（比如音频数据、电话本等）等。此外，存储器22可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡（Smart Media Card, SMC），安全数字（SecureDigital, SD）卡，闪存卡（Flash Card）、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

其中，所述车载TBOX的SOC端20集成的模块如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、电载波信号、电信信号以及软件分发介质等。

参见图5，图5是本发明实施例提供的一种车辆ECU软件升级系统30的结构框图，所述车辆ECU软件升级系统30包括ECU31和TBOX32，所述TBOX32包括上述实施例所述的微控制器10和上述实施例所述的SOC端20；其中，所述SOC端20与所述微控制器10连接，所述微控制器10还与所述ECU31连接。

具体的所述微控制器10和所述SOC端20的工作过程请参考上述实施例所述的车载TBOX的微控制器10和SOC端20的工作过程，在此不再赘述。

本发明实施例公开的车辆ECU软件升级系统30，将ECU软件升级包的拆分、传输过程以及升级进度的上报、与OTA刷新控制进程的交互移植到了SOC侧完成，MCU侧仅负责UDS诊断刷新的流程逻辑控制。双CPU（MCU和SOC）进行刷新任务的合理分工，提升了刷写的性能，有效降低OTA升级时数据传输失败的风险。同时，不需要在升级之前将ECU的软件升级包从SOC侧传输到MCU侧进行存储，可以在SOC传送升级包数据到MCU的同时进行诊断刷新，提升了刷写的效率和连续性。另外，为了提升刷写的效率，在MCU侧同时申请了两块同样大小的静态内存，在一块内存中的数据进行UDS刷写更新的同时，另外一块空闲的静态内存会接收SOC传输过来的下一包数据，通过两块内存的交互使用，无需增加外设，降低硬件成本。

以上所述是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本发明的保护范围。

Claims (10)

1.一种车辆ECU软件升级方法，其特征在于，应用于车载TBOX的微控制器，所述方法包括：

响应于接收到的由车载TBOX的SOC端在满足允许进行ECU软件升级条件下发送的ECU刷新请求，进行ECU软件升级前的预处理；

接收所述SOC端发送的当前从ECU软件升级包拆分出来的数据块，并将所述数据块发送至对应的ECU进行数据刷写，直到将接收到的最后一块从所述ECU软件升级包拆分出来的数据块发送至所述ECU进行数据刷写；所述ECU软件升级包是所述SOC端预先获得的；

其中，每一所述数据块包括帧头、帧尾和软件升级数据；则，在将所述数据块发送至ECU进行数据刷写之前，所述方法还包括：

通过所述帧头判断所述数据块的消息类型；

对所述软件升级数据进行CRC计算，得到所述数据块的校验值；

将所述数据块的校验值与预存在所述帧尾中的CRC值进行比对，以得到所述数据块的数据校验结果；

若数据块的数据校验结果为校验成功，则执行所述将所述数据块发送至ECU进行数据刷写；

所述微控制器的内存具有两个内存区；则，所述接收所述SOC端发送的当前从ECU软件升级包拆分出来的数据块，并将所述数据块发送至对应的ECU进行数据刷写，包括：

将接收到的所述SOC端发送的当前从ECU软件升级包拆分出来的当前数据块存入两个内存区中的为空闲状态的内存区，待另一个内存区将其自身存有的数据块发送至对应的ECU进行数据刷写完毕后，再将接收到的所述当前数据块发送至所述ECU进行数据刷写。

2.如权利要求1所述的车辆ECU软件升级方法，其特征在于，在所述将接收到的最后一块所述数据块发送至所述ECU进行数据刷写之后，所述方法还包括：

对整车ECU进行复位；

根据接收到由所述SOC端发送的升级校验指令，控制所述ECU启动本地当前的ECU软件；

接收所述ECU返回的当前启动的ECU软件的版本号并发送给所述SOC端，以使得所述SOC端根据接收到的所述版本号与预先获得的所述ECU软件升级包的版本号的比对，来确定所述ECU的ECU软件升级包是否升级成功。

3.如权利要求1所述的车辆ECU软件升级方法，其特征在于，所述允许进行ECU软件升级条件包括：

检测到车辆车速为0、电池电量大于50%和车辆中的点火开关控制端子处于关闭状态中的至少一种。

4.如权利要求1所述的车辆ECU软件升级方法，其特征在于，所述进行ECU升级前的预处理，包括以下至少一种：

进入ECU诊断会话模式；

关闭网络中所有ECU的DTC检测和存储功能；

控制PEPS进入boot模式；

禁止CAN网络上所有ECU的非诊断报文的发送和接收。

5.如权利要求1所述的车辆ECU软件升级方法，其特征在于，将所述数据块发送至ECU进行数据刷写，包括：

将所述数据块发送至ECU进行UDS诊断刷新，以使得所述ECU将UDS诊断刷新成功的数据刷写入所述ECU的应用存储区中。

6.如权利要求1所述的车辆ECU软件升级方法，其特征在于，在将数据块发送至ECU进行数据刷写之后，所述方法还包括：

接收所述ECU反馈的对所述数据块的数据刷写结果及刷写进度并上报给所述SOC端。

7.一种车辆ECU软件升级方法，其特征在于，应用于车载TBOX的SOC端，所述方法包括：

响应于满足允许进行ECU软件升级条件，向车载TBOX的微控制器发送ECU刷新请求，以使得所述微控制器进行ECU软件升级前的预处理；

对预先获得的ECU软件升级包进行数据块拆分，并将当前从ECU软件升级包拆分出来的数据块发送给所述微控制器，直到将最后一块拆分出来的所述数据块发送给所述微控制器；其中，所述微控制器将接收到的所述数据块发送至对应的ECU进行数据刷写；

其中，每一所述数据块包括帧头、帧尾和软件升级数据；则，所述微控制器将所述数据块发送至对应的ECU进行数据刷写前，所述微控制器还需要对所述数据块进行校验，校验过程包括：

通过所述帧头判断所述数据块的消息类型；

对所述软件升级数据进行CRC计算，得到所述数据块的校验值；

将所述数据块的校验值与预存在所述帧尾中的CRC值进行比对，以得到所述数据块的数据校验结果；

若数据块的数据校验结果为校验成功，则执行所述将所述数据块发送至对应的ECU进行数据刷写；

所述微控制器的内存具有两个内存区；将接收到的所述SOC端发送的当前从ECU软件升级包拆分出来的当前数据块存入两个内存区中的为空闲状态的内存区，待另一个内存区将其自身存有的数据块发送至对应的ECU进行数据刷写完毕后，再将接收到的所述当前数据块发送至所述ECU进行数据刷写。

8.一种车载TBOX的微控制器，其特征在于，包括处理器、存储器以及存储在所述存储器中且被配置为由所述处理器执行的计算机程序，所述处理器执行所述计算机程序时实现如权利要求1至6中任意一项所述的车辆ECU软件升级方法。

9.一种车载TBOX的SOC端，其特征在于，包括处理器、存储器以及存储在所述存储器中且被配置为由所述处理器执行的计算机程序，所述处理器执行所述计算机程序时实现如权利要求7所述的车辆ECU软件升级方法。

10.一种车辆ECU软件升级系统，其特征在于，包括ECU和TBOX，所述TBOX包括如权利要求8所述的微控制器和如权利要求9所述的SOC端；其中，所述SOC端与所述微控制器连接，所述微控制器还与所述ECU连接。

Images