老哥学习网 - www.lg9.cn 2024年05月06日 17:12 星期一
当前位置 首页 >公文范文 > 公文大全 >

基于CANFD的智能汽车域控制器软件升级系统设计

发布时间:2023-03-20 14:50:12 浏览数:

张 震,尤伟强,肖利华,王小玲,余红英

(1. 中北大学 电气与控制工程学院,山西 太原 030051;

2. 重庆长安新能源科技有限公司整车开发部,重庆 400000)

电子控制单元(ECU)功能扩充或出现漏洞时,都需要进行应用软件升级[1]. 目前,国内域控制器软件升级大多是基于CAN总线[2],该总线广泛应用于诊断仪与ECU之间数据的交换. 但是,CAN总线升级仍存在速度较慢、 误码率高等问题[2],汽车升级的效率和安全性无法保证. 为解决该问题,高天宇[3]提出了基于差分方法的远程数据刷写系统,通过压缩数据量来提高升级速率;

刘宇等[4]将采用标准帧和减少填充位等方式结合起来,改进了CAN数据传输速度. 以上这些方式均可有效提升CAN升级速率,但是仍无法改变CAN协议有效数据率低的缺陷. 针对该问题,BOSCH公司研发了CANFD(Flexible Data-rate),可以支持更长的数据场,在不改变CAN物理层的情况下提高了有效数据率. 目前,基于CANFD的ECU应用软件刷写方式成本高、 效率低且过度依赖专业维修人员和外部设备,导致软件无法高效便捷地升级. 而且由于升级数据包格式不固定,通常需提前进行格式转换,影响了升级效率. 为解决该问题,本文采用UDS诊断协议[5]和CANFD总线设计了一套域控制器软件升级系统,该系统实现了多格式文件的兼容. 为保证升级的安全性,系统采用了UDS诊断协议中的安全服务,同时,利用会话模式将升级过程合理分块,保证数据的完整性以及升级过程的逻辑性.

1.1 系统设计方案

为了使上位机和bootloader[6]通讯更加高效和安全,本文采用UDS诊断协议对ECU中应用程序进行了重编程. ECU上电后,首先通过Bootloader执行必要的硬件初始化步骤,之后检查外部重编程标志是否设置为重编程请求状态[7]. 若重编程请求无效且原应用程序有效,则无需升级,引导程序启动原有应用程序即可. 如果重编程标志有效并且应用程序无效,ECU进入编程会话模式等待升级. 总体设计框图如图 1 所示.

图 1 总体设计框图Fig.1 Block diagram of overall design

在重编程过程中,上位机通过预编程步骤、 编程步骤、 后编程步骤[8]下载相应的S19,Hex和Bin文件到ECU中. 其中,预编程步骤为重编程过程提供升级环境,编程步骤用来下载驱动文件和应用文件,后编程步骤主要用来结束重编程步骤.

1.2 CANFD协议概述

升级系统采用CANFD协议进行数据交互,其中,CANFD数据帧结构由帧起始、 仲裁场、 控制场、 数据场、 CRC场、 ACK场和帧结束构成. CANFD延用了CAN物理层和数据链路层,并在此基础上对CAN总线的不足做出改进,两种帧结构区别如表 1 所示.

表 1 CANFD与CAN结构主要区别Tab.1 Main differences between CANFD and CAN structures

在传输过程中,该协议采用两种传输方式,如果数据长度(DLC表示)小于64字节则采用单帧发送,否则采用多帧发送.

1) 单帧:
单帧协议控制信息由一个字节构成,其中高四位固定为0,低四位表示报文的数据长度[9]. 单帧通常采用一发一收机制,请求帧发送后,等待下位机响应. 若为肯定响应,则接收成功,上位机执行后续程序或发送新的指令;

否则继续等待肯定响应或直接退出诊断会话. 单帧传输框图如图 2(a) 所示.

2) 多帧:
由首帧、 流控帧、 连续帧组成[10]. 在多帧协议传输中,首先通过首帧确定传输数据的大小,其次利用流控帧控制连续帧的帧间隔,然后利用连续帧发送数据内容,最后利用流控帧判断传输是否完成,多帧传输报文如图 2(b) 所示.

图 2 帧传输框图Fig.2 Block diagram of frame transmission

单帧传输较大的数据流,会产生许多无用的等待响应时间,而采用连续帧进行大容量数据传输时,中途无需等待ECU响应,可连续发送数据直至结束. 与单帧协议相比,多帧协议实现更加复杂,代码逻辑性更强,适用于大容量数据传输.

车载域控制器安全运行,关乎汽车行驶的安全性. ECU软件更新必须充分考虑整个系统的安全环境,本系统从ECU上电安全性、 下载数据完整性校验、 强制刷写三个方面保障应用程序升级的安全性[11].

2.1 ECU上电安全性设计

上位机和ECU之间通过安全校验来确保升级环境的安全性,用户没有正确的密钥无法解锁ECU,就无法对ECU进行升级操作,从而降低误操作升级的概率. 上位机通过安全服务向ECU发送请求获取安全种子,此种子为供应商提供的一组16进制数. 上位机利用种子和安全算法计算出相应的密钥,并将该密钥值通过安全服务下发到ECU. ECU将自己计算的密钥与上位机计算的密钥值进行比对,确定升级者身份. 若身份校验通过,ECU做出肯定响应,否则退出升级. 安全访问框图如图 3 所示.

图 3 安全访问框图Fig.3 Block diagram of secure access

2.2 数据完整性校验设计

CANFD总线CRC校验场由CRC Count和CRC Sequence组成,CRC Count采用3位格雷码来表示填充位的数量,CRC Sequence由极性相反的填充位FSB和CRC值构成,CRC校验场填充规则如图 4 所示,其中,CRC校验值由控制场中的DLC计算得出,校验算法如表 2 所示. 通过CANFD新型填充规则和CRC计算法则,降低了数据未被检测到的错误风险[12].

图 4 CANFD填充规则Fig.4 Filling rules of CANFD

表 2 CRC校验值Tab.2 CRC check value

通过数据传输服务将数据包下载至ECU后,ECU通过CRC-16对数据进行完整性校验[13]. 上位机提前计算数据的校验值,ECU将两次计算的结果进行比较,若值相等则表示传输的数据完整. 如果校验通过,ECU将数据块标志位置1后将该数据包写入Flash中. 为简化CRC算法,提高数据的下载速率,本文采用查表法计算CRC值,表中校验码值为X16+X15+X2+1.

该方法对数据包每一个字节进行校验,取数据包中第一个字节与CRC寄存器值低8位进行异或,并把计算结果存入CRC寄存器低8位,之后将此CRC寄存器值右移8位并与式(1)算出的校验值进行异或,更新CRC寄存器值,依此循环,直至校验完数据包中最后一个数据,得出最终CRC校验值.

该方法通过传输过程和传输后校验保证了数据的完整性,避免了由于传输过程中和写入Flash时造成数据丢失,导致刷写失败.

2.3 强制刷写功能

升级环境变化可能导致升级程序出现漏洞,使主程序一直处于初始化状态,无法跳转到重编程会话. 为解决应用程序出现漏洞无法实现再升级的难题,本系统开发了强制刷写功能.

上位机在正常刷写流程前加入强制刷写代码. 操作人员下达强制刷写指令时,先执行此段代码,循环发送两组特殊单帧报文. ECU在上电20 ms的窗口期内会检测到此请求,跳出原有应用程序,执行Bootloader程序,后续升级步骤和正常升级步骤一致,上位机进入预编程步骤对升级环境进行配置,之后执行编程步骤将待升级文件下载至ECU中,完成升级操作.

为提高软件升级效率,设计中从硬件软件多个方面进行改进. 利用CANFD总线协议替代CAN协议,在此基础上,通过文件兼容性以及双线程设计来提高数据传输的效率.

3.1 硬件设备更改

CAN总线传输速率慢,升级效率低,本文采用周立功USB-CANFD诊断设备,负责将上位机的USB信号转换为CANFD差分信号并与ECU进行交互[14]. CANFD继承了CAN的主要特性,还具有以下两个优点:
具有两种不同速率,其中仲裁段的速率与CAN的速率相同,而数据域速率最高可以达到5 Mbit/s;

CAN的最大数据长度为8字节,而CANFD的最大数据长度为64字节[15]. CANFD比CAN速率更快,传输效率更高.

3.2 文件兼容性解析

文件解析是程序刷写的重要过程,现有的升级方式均需要提前将文件格式转换为固定格式. 本设计将文件[10]解析步骤提前,升级过程中可直接将解析好的S19(Hex或者Bin)数据打包发送至下位机. S19文件由类型标识符、 数据长度、 存储地址、 数据、 校验和组成. 上位机在程序升级前,采用文件后缀名识别文件,采用文本方式扫描读取每一行信息,并根据每一行的Flash地址信息、 数据长度信息来确定所升级数据包地址是否连续,如果连续则记录起始地址和数据总长度信息,否则单独记录. 上位机将记录的数据长度信息、 存储地址信息和数据信息分别存入3个不同的缓存区,此3个缓存区数据为一一对应关系. 上位机根据UDS协议将数据内容、 flash长度信息、 flash地址信息发送给ECU. Hex文件由数据长度、 存储地址、 数据组成,每两个字符表示一个字节数据,解析方法与S19文件相同. Bin文件中只有数据内容,上位机在解析Bin文件时,还需要一个配置文件,此配置文件记录着数据长度、 存储地址. 软件下载过程包含请求下载、 数据传输、 退出下载三部分. 数据传输过程如图 5 所示,ECU响应若为肯定响应则进行后续升级流程,否则退出升级.

图 5 数据传输过程Fig.5 Process of data transmission

1) 请求下载服务(34服务)将一个数据包起始地址、 数据长度信息下载至ECU中,Bootloader 收到请求后应做好接收文件的准备.

2) 数据传输服务(36服务)通过连续帧将解析后的文件数据以16进制形式下载到Flash中. 由于传输的数据量通常大于ECU接收缓存区的容纳量,上位机需要将数据拆解成多个数据包进行传输.

3) 上位机通过退出数据下载服务(31服务)告知ECU一个数据包发送完成.

3.3 双线程软件设计

上位机发送完升级请求后,由于无法确定ECU的响应时间,从而无法确定下条指令发送的时间. 传统单线程升级软件通过在发送命令与接收命令之间设置固定等待时间来解决此问题,由于设置的等待时间比实际响应时间长,造成时间上的浪费. 为了更好地解决该问题,本系统采用双线程设计思路,将上位机数据发送和接收置于不同线程来并发运行. 发送线程采用状态机思维设计重编程会话,即一个状态发送一条诊断服务. 发送线程按照预编程步骤、 编程步骤、 后编程步骤进行升级.

接收线程接收到ECU响应报文后,立即将状态跳转标志位发送至发送线程,发送线程跳转到下个状态,同时将此标志位清零,直到整个刷写完成. 编程步骤中,在传输解析好的文件数据时,发送端需要不断地从缓冲区读取数据,接收端需要判断上一次发送的反馈. 设计中将这种发送与接收步骤分别设置为子线程,由于这两个步骤操作不同的内存空间,所以互不干扰. 为避免线程抢占资源过程中可能产生的死锁问题,设计中用pthread_mutex_t实现数据缓冲区的互斥. 利用多线程的设计,系统不必等到解析结果后再读取缓冲区数据,在正常升级过程中就可以实现并发操作. 线程之间利用共享内存进行交互,发送端读取数据完毕后,利用共享内存中的标志位进行循环阻塞,直到接收端线程判断无误.

图 6 显示了原系统收发和采用双线程收发的大致流程差异,可以看到,本设计不需要等待接收线程的反馈结果就可以直接从缓冲区读取要发送的数据. 这种方式减少了大量的系统阻塞时间,提高了传输效率. 接收线程同时通过识别ID滤除无用波,增加了刷写的可靠性.

图 6 双线程设计框图Fig.6 Block diagram of dual thread design

本文采用MFC设计了基于CANFD智能汽车域控制器升级系统并应用于某型智能汽车. 诊断仪采用周立功USBCANFD设备,完成USB信号到CANFD信号的转换,确保通信电平正确,应用周立功官方测试软件ZCANPRO进行数据监测与分析.

为验证应用软件升级过程的安全性和高效性,通过ZCANPRO提取了部分诊断报文,其中CAN总线采用500 kbit/s的波特率,CANFD总线采用 5 Mbit/s 的波特率,如图 7 和图 8 所示. 从诊断报文可以看出,ECU上电前先进行安全校验(0x27),通过种子算出密钥,最后通过密钥值确保升级环境的安全. 数据传输完成后,通过CRC校验(0x37)确定传输后的数据完整性,CRC校验通过后可继续传输数据,如图 7 所示. ECU上电瞬间,通过上位机发送强制刷写指令,可以使ECU从应用程序跳转到Boot状态,完成应用软件升级. 从图 7 和图 8 可以看出,CAN诊断报文的响应时间大约在1 ms左右,而CANFD诊断报文的响应时间大约在 0.7 ms 左右,CANFD的速率比CAN的速率提升30%左右. 在数据传输服务中(0x36),CANFD报文长度最长为64字节,而CAN报文最长只有 8字节,传输大容量数据时,CANFD具有更快的传输速率. 通过日志中的时间比较,本文设计的CANFD升级系统的速率比传统CAN提升了40%左右. 由此可见,基于CANFD总线的UDS诊断协议的升级方案具有合理化、 安全性高、 传播速率快等特点.

图 7 CAN诊断报文Fig.7 Message about CAN diagnosis

图 8 CANFD诊断报文Fig.8 Message about CANFD diagnosis

为了提高升级软件的兼容性,上位机支持SVDC-MC,SVDC-MU,SVDC-SWITCH,BMS,IPU等多域控制器刷写,并且兼容USBCANII,USBCANFD等刷写设备. 上位机刷写完成界面如图 9 所示.

图 9 上位机刷写完成界面Fig.9 Interface of upper computer brushing completion

本文以满足应用软件更新安全性能与减少升级时间需求为目的,结合UDS诊断协议和刷写流程,开发了一款应用于CANFD智能汽车域控制器升级的软件. 该软件提前进行文件数据输出,省略了文件格式转换流程,并利用硬件模块设计和软件双线程模块设计提高了ECU软件升级的效率;

通过增加ECU上电安全校验、 数据完整性与有效性校验步骤保证了升级过程中的安全性. 通过与某型汽车ECU的联合测试,该设计实现了多种格式文件解析并且兼容USBCANII, ValueCAN, USBCANFD设备,在兼顾升级安全的同时将智能汽车域控制器控制软件升级的速度提高了约40%.

猜你喜欢 校验上位线程 5G终端模拟系统随机接入过程的设计与实现计算机应用与软件(2022年9期)2022-10-10复杂多耦合仿真模型校验工具研究计算机仿真(2022年6期)2022-07-20使用Excel朗读功能校验工作表中的数据中学生学习报(2022年15期)2022-04-17实时操作系统mbedOS 互斥量调度机制剖析现代电子技术(2022年8期)2022-04-13浅析体育赛事售票系统错票问题的对策研究体育科技文献通报(2022年1期)2022-01-15电能表在线不停电校验技术机电工程技术(2021年3期)2021-09-10一场史无前例的乐队真人秀智族GQ(2019年9期)2019-10-28精通文件校验的“门道”电脑知识与技术·经验技巧(2017年9期)2018-02-24基础油“上位”汽车观察(2015年10期)2016-04-06基于VC的PLC数据采集管理系统现代电子技术(2009年6期)2009-05-31

推荐访问:域控制器 升级 智能

相关文章:

Top