CN110474961B - 纯电乘用车基于can总线实现多路远程ota升级方法 - Google Patents

Abstract

本发明公开了一种纯电乘用车基于CAN总线实现多路远程OTA升级方法，包括如下步骤：步骤1，管理人员先对OTA升级包进行测试和验证，在验证升级包完整性和安全性后，通过平台操作将升级包进行打包压缩并上传到服务器中，之后服务器对文件进行管理其中包括升级包版本管理、升级内容管理、升级操作日志管理；步骤2，服务器会将更新的升级信息通过网络发布给对应的车辆，在升级包下载的过程中，车载通信终端保持电源的正常提供，并且能够支持断点续传功能，来保证OTA升级包的完整性；步骤3，车载终端多OTA升级包进行解压缩；步骤4，将更新文件刷入ECU中。

Description

纯电乘用车基于CAN总线实现多路远程OTA升级方法

技术领域：

本发明涉及一种纯电动乘用车各个ECU软件远程OTA升级方法，特别涉及一种纯电乘用车基于CAN总线实现多路远程OTA升级方法，其属于高速纯电动乘用汽车各个ECU车载OTA升级技术领域。

背景技术：

人们对汽车动力性、安全性和舒适性要求的提高，电子控制单元ECU(ElectronicControl Unit)和电子控制系统也在不断增加，ECU功能的个性化亦在不断的增加和更替，ECU软件升级的频繁及必要性，在整个车辆生命周期中，车载电子控制系统的软件升级可能是多次甚至是反复的，除了部分为了提高客户使用满意度的升级(如车载信息娱乐系统等)，更重要的安全升级可能涉及汽车的召回，而传统的紧急通知车主到经销商处进行升级的解决措施往往意味着低效率和高成本，同时车企还可能背负巨大的品牌价值损失的代价。传统在线升级的方法是利用故障码设置服务Ox85禁止网络上ECU的故障识别和存储功能，利用通信控制服务Ox28禁止当前网络管理和通信信息，以获得最大的通信流量。该方法具有局限性，并且对车载电瓶损耗较大，升级条件仅限车辆内部的总线网络处于休眠状态，需重新唤醒由车载电瓶供电后进行远程升级，传统的点对点升级方式或者4S店人工通过线下OBD专有设备升级已经不能满足汽车分布式实时ECU控制升级的需要，专业设备的开发及使用和集中式升级ECU软件严重浪费开发资源，亦不能满足客户的体验，势必需要技术革命性变革。由于电子设备ECU的不断增加并且是由不同厂家所开发软件，厂家能力各不相同，软件升级方式各不相同，而导致不同的ECU要用不同的专业设备及工具或软件，也使得在售后服务及软件更新越来越困难，限制了ECU功能需求更替，及内部控制功能的进一步拓展。另一方面，各个电子控制单元并不是仅仅与负载设备简单地连接在一起，更多的是与外围设备及其他ECU进行信息备份交流，并经过复杂的控制决策运算，发出控制备份指令。为了提高信号的利用率，要求大批数据信息在不同的ECU之间进行交换和共享，因此采用车载CAN总线网络实现多路远程OTA升级系统是汽车电子发展的必然趋势。

现有车载网络中不同种控制器或控制模块都是统一连接到一条诊断OBD口上的。一般来说：一辆车一个OBD口，同一时间内只能对一个ECU升级的模式适应于简易的传统车，但是它的扩展性较差，实时性较差，市场上的更新成本大，当系统模块功能增加、通讯信息增加时网络的负载也会不断增加，带来网络的拥堵和可靠性降低等问题。

现有乘用车OTA(Over-the-Air Technology)实时多网段多ECU远程OTA技术升级是多条CAN总线分别对接不同的CAN芯片及控制逻辑(TBOX目前设计实现8条CAN线路)，各个ECU的eMMC存储器进行分区至少分为2区以上，其中1区专门为升级软件包临时存储和备份使用，它开发简便但功能强大，可以无损失系统升级，主要通过无线网络(如4G模块TBox)自动下载OTA升级包、自动升级，为避免OTA在远程升级，可能占用较大的CAN总线网络带宽，使CAN总线负载过大从而影响驾驶并引发安全性问题，会在eMMC存储器的专门分区内进行存储和备份，下次上电自动检测是否升级。

发明内容：

本发明是为了解决上述现有技术存在的问题而提供一种纯电乘用车基于CAN总线实现多路远程OTA升级方法，通过车内控制单元ECU进行分类、对CAN总线网络升级条件判断，简化了ECU升级流程。

本发明所采用的技术方案有：一种纯电乘用车基于CAN总线实现多路远程OTA升级方法，包括如下步骤：

步骤1，管理人员先对OTA升级包进行测试和验证，在验证升级包完整性和安全性后，通过平台操作将升级包进行打包压缩并上传到服务器中，之后服务器对文件进行管理其中包括升级包版本管理、升级内容管理、升级操作日志管理；

步骤2，服务器会将更新的升级信息通过网络发布给对应的车辆，在升级包下载的过程中，车载通信终端保持电源的正常提供，并且能够支持断点续传功能，来保证OTA升级包的完整性；

步骤3，车载终端多OTA升级包进行解压缩；

步骤4，将更新文件刷入ECU中。

本发明具有如下有益效果：

(1).透过主机厂管理的服务平台(TSP平台)可以实现，同一时间对不同的ECU进行远程升级，也可以同一时间对不同地点的多个车俩同时进行不同ECU进行远程升级(原则上不限制车辆数量，受制于车载4G网络的速率)；

(2).OTA远程升级减少现场人员的费用及专有设备服用，提高工作效率，避免因为软件造成的质量问题而进行召回，或者至不同的地点现场刷写，同时易于增加新功能；

(3).对于各个ECU的扩展技术的应用和验证提供更便捷，效率更高效，零费用的技术方案；

(4).也可以实现车俩4G网络上线/离线状态的管理，进行自动上线升级，离线标注管理的功能并反馈至TSP管理平台；

(5).根据ECU的工作状态，区分工作状态及非工作状态，下次自动升级；

(6).能够实现OTA远程新版本升级，升级失败，可以自动还原上一版本，不会造成因升级失败而无法正常工作的状况。

附图说明：

图1为预编程步骤图。

图2为主编程步骤图。

图3为后编程步骤图。

具体实施方式：

下面结合附图对本发明作进一步的说明。

一种纯电乘用车基于CAN总线实现多路远程OTA升级方法，包括如下步骤：

步骤1，管理人员需要先对OTA升级包进行测试和验证，在验证升级包完整性和安全性后，通过平台操作将升级包进行打包压缩并上传到服务器中，之后服务器对文件进行管理其中包括升级包版本管理、升级内容管理、升级操作日志管理等；

步骤2，服务器会将更新的升级信息通过网络发布给对应的车辆，在升级包下载的过程中，车载通信终端必须保持电源的正常提供，并且能够支持断点续传功能，来保证OTA升级包的完整性；

步骤3，车载终端多OTA升级包进行解压缩；

步骤4，将更新文件刷入ECU中。

其中步骤4又分为如下步骤：

步骤A)，预编程步骤

1)诊断会话控制10 03h：为了禁止ECU间的正常通信和控制DTC设置，预编程需要启动非默认会话模式。通过使用会话类型为扩展会话模式的诊断会话控制(10h)服务来完成。此请求使用一个单帧请求报文，通过功能寻址发送给所有的ECU。

2)例程控制“检查编程预条件”：例程控制“检查编程预条件”31h 01h 02h 03h：通过此例程来检查ECU编程条件，从而确保系统安全，预编程检验条件由ECU决定，如果有任何不安全的因素，ECU应该拒绝编程。

3)控制DTC设置：控制DTC设置85h 02h：诊断仪通过DTC设置类型设为“关闭”的控制DTC设置服务请求。此请求使用一个单帧请求报文，通过功能寻址发送给所有的ECU。

4)通信控制：通信控制28h 03h 01h：诊断仪通过通信控制(28h)服务请求，禁止非诊断报文的发送和接收。请求中的控制类型参数置为“disable the transmission andthe reception”，通信类型置为“normal communication messages”。此请求使用一个单帧请求报文，通过功能寻址发送给所有的ECU。

5)读取数据22h xxh yyh：读取数据22h xxh yyh：在禁止正常通信后，读取被编程的ECU的状态(如：编程的应用软件和数据)。

步骤B，主编程步骤

1)诊断会话控制10h 02h：在收到一个寻址方式为物理寻址，子功能为编程会话的诊断会话控制(10h)服务后，ECU启动Bootloader，并分配编程所需的所有资源。ECU需先发送肯定响应再执行跳转到编程模式动作。

2)判断应用程序所处的区域，假如当前应用程序在A区运行，则在B区升级程序。

3)安全访问27h 03h/04h：编程事件必须通过安全访问。安全访问(27h)服务在排放相关和安全系统中是强制的。下载前，通过安全访问过程是强制的，确保只有合法的诊断仪能对ECU进行下载操作。

4)写入指纹信息：写入数据2Eh F1h 84h：在擦除内存例程之前，将“指纹”写到ECU内存中是强制的，“指纹”标识了是哪个诊断仪对ECU内存做了修改。每启动一次重编程，需重写指纹信息，未写入或写入不成功将不允许重编程。诊断设备应在Bootloader和应用程序中均能通过读F1h 84h DID追踪到指纹信息。

5)驱动下载34h，36h，37h，31h：当ECU的非易失性存储单元中没有存储内存驱动时，将执行内存驱动的下载。下载应该按照如下时序来进行：请求下载、传输数据、请求传输退出。下载完所有字节后，用“检查编程完整性”例程(31h 01h 02h 02h)来检查所有的字节都正确传输。

6)例程控制——“擦除内存”31h 01h FFh 00h：为了允许应用软件和数据下载，ECU的内存将被擦除。此步骤通过例程控制服务(31h)来执行擦除内存。如果擦除内存例程被调用执行，那么应用软件的标志位将被置为无效。

7)下载过程34h，36h，37h：应用软件或者数据的每一个连续的数据块(也叫段，可能是一个完整的应用软件或者数据，也可能是应用软件或者数据的一部分)下载到ECU非易失性内存中，都是遵循下面的服务顺序完成数据传输。

8)例程控制——“检查编程完整性”31h 01h 02h 02h：此例程用来检查逻辑块的完整性。

9)例程控制——“检查编程依赖性”31h 01h FFh 01h：一旦完成所有的应用软件或数据块/模块的下载，诊断仪将开始一个例程来触发ECU检查重编程的依赖性。ECU供应商定义检查内容，但必须确保所有逻辑块的兼容性和一致性。

10)电控单元复位11h 01h：诊断仪使用物理寻址，发送一个复位类型为硬复位的ECU复位(11h)服务请求报文到CAN网络上。

11)根据编程结果选择应用程序所处的区域。

步骤C，后编程步骤

1)诊断会话控制10h 03h：为了禁止ECU正常通信报文，诊断仪发送一个会话类型为扩展会话的诊断会话控制(10h)服务请求报文到CAN网络上，使ECU进入扩展会话中。该请求为功能寻址。

2)通信控制28h 00h 01h：诊断仪通过发送通信控制(28h)服务请求来使能非诊断报文的接收和发送。控制类型参数为“使能接收和发送”，通信类型为“正常通信报文”。该请求为功能寻址。

3)DTC设置控制85h 01h：完成下载后，通过发送DTC设置类型为on的DTC设置控制服务请求，将所有ECU的DTC设置重新使能。该请求为功能寻址。

4)诊断会话控制10h 01h：诊断仪发送一个会话类型为默认会话的诊断会话控制(10h)服务请求报文到CAN网络上。所有的ECU接收到诊断会话控制(10h)，而进入到默认会话模式。此请求通过功能寻址发送。

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

Claims (1)

1.一种纯电乘用车基于CAN总线实现多路远程OTA升级方法，其特征在于：包括如下步骤：

步骤1，管理人员先对OTA升级包进行测试和验证，在验证升级包完整性和安全性后，通过平台操作将升级包进行打包压缩并上传到服务器中，之后服务器对文件进行管理其中包括升级包版本管理、升级内容管理、升级操作日志管理；

步骤2，服务器会将更新的升级信息通过网络发布给对应的车辆，在升级包下载的过程中，车载通信终端保持电源的正常提供，并且能够支持断点续传功能，来保证OTA升级包的完整性；

步骤3，车载终端多OTA升级包进行解压缩；

步骤4，将更新文件刷入ECU中；

所述步骤4包括如下步骤：

步骤A），预编程步骤

1）诊断会话控制10h 03h：为了禁止ECU间的正常通信和控制DTC设置，预编程需要启动非默认会话模式，通过使用会话类型为扩展会话模式的诊断会话控制（10h）服务来完成，此请求使用一个单帧请求报文，通过功能寻址发送给所有的ECU；

2）例程控制“检查编程预条件”：例程控制“检查编程预条件”31h 01h 02h 03h：通过此例程来检查ECU编程条件，预编程检验条件由ECU决定，如果有任何不安全的因素，ECU应该拒绝编程；

3）控制DTC设置：控制DTC设置85h 02h：诊断仪通过DTC设置类型设为“关闭”的控制DTC设置服务请求，此请求使用一个单帧请求报文，通过功能寻址发送给所有的ECU；

4）通信控制：通信控制28h 03h 01h：诊断仪通过通信控制（28h）服务请求，禁止非诊断报文的发送和接收，请求中的控制类型参数置为“disable the transmission and thereception”，通信类型置为“normal communication messages”，此请求使用一个单帧请求报文，通过功能寻址发送给所有的ECU；

5）读取数据22h xxh yyh：在禁止正常通信后，读取被编程的ECU的状态；

步骤B，主编程步骤

1）诊断会话控制10h 02h：在收到一个寻址方式为物理寻址，子功能为编程会话的诊断会话控制（10h）服务后，ECU启动Bootloader，并分配编程所需的所有资源，ECU需先发送肯定响应再执行跳转到编程模式动作；

2）判断应用程序所处的区域，假如当前应用程序在A区运行，则在B区升级程序；

3）安全访问27h 03h/04h：编程事件必须通过安全访问，安全访问（27h）服务在排放相关和安全系统中是强制的，下载前，通过安全访问过程是强制的，确保只有合法的诊断仪能对ECU进行下载操作；

4）写入指纹信息：写入数据2Eh F1h 84h：在擦除内存例程之前，将“指纹”写到ECU内存中是强制的，“指纹”标识了是哪个诊断仪对ECU内存做了修改，每启动一次重编程，需重写指纹信息，未写入或写入不成功将不允许重编程，诊断设备应在Bootloader和应用程序中均能通过读F1h 84h DID追踪到指纹信息；

5）驱动下载34h，36h，37h，31h：当ECU的非易失性存储单元中没有存储内存驱动时，将执行内存驱动的下载，下载应该按照如下时序来进行：请求下载、传输数据、请求传输退出，下载完所有字节后，用“检查编程完整性”例程（31h 01h 02h 02h）来检查所有的字节都正确传输；

6）例程控制——“擦除内存”31h 01h FFh 00h：为了允许应用软件和数据下载，ECU的内存将被擦除，此步骤通过例程控制服务（31h）来执行擦除内存，如果擦除内存例程被调用执行，那么应用软件的标志位将被置为无效；

7）下载过程34h，36h，37h：应用软件或者数据的每一个连续的数据块下载到ECU非易失性内存中；

8）例程控制——“检查编程完整性”31h 01h 02h 02h：此例程用来检查逻辑块的完整性；

9）例程控制——“检查编程依赖性”31h 01h FFh 01h：一旦完成所有的应用软件或数据块/模块的下载，诊断仪将开始一个例程来触发ECU检查重编程的依赖性，ECU供应商定义检查内容，确保所有逻辑块的兼容性和一致性；

10）电控单元复位11h 01h：诊断仪使用物理寻址，发送一个复位类型为硬复位的ECU复位（11h）服务请求报文到CAN网络上；

11）根据编程结果选择应用程序所处的区域；

步骤C，后编程步骤

1）诊断会话控制10h 03h：诊断仪发送一个会话类型为扩展会话的诊断会话控制（10h）服务请求报文到CAN网络上，使ECU进入扩展会话中，该请求为功能寻址；

2）通信控制28h 00h 01h：诊断仪通过发送通信控制（28h）服务请求来使能非诊断报文的接收和发送，控制类型参数为“使能接收和发送”，通信类型为“正常通信报文”，该请求为功能寻址；

3）DTC设置控制 85h 01h：完成下载后，通过发送DTC设置类型为on的DTC设置控制服务请求，将所有ECU的DTC设置重新使能，该请求为功能寻址；

4）诊断会话控制10h 01h：诊断仪发送一个会话类型为默认会话的诊断会话控制（10h）服务请求报文到CAN网络上，所有的ECU接收到诊断会话控制（10h），而进入到默认会话模式，此请求通过功能寻址发送。

Images