控制器程序更新影响效率因素分析
2020-04-23李英凯王志海张方伟廖中华
李英凯,王志海,张方伟,廖中华,杨 超
(浙江吉智新能源汽车科技有限公司,浙江 杭州 518034)
随着车辆向电气化方向发展,整车控制器数量及代码量越来越多。再加上FOTA功能在国内越来越受到重视,如何缩短整车程序更新时间变得越来越重要。本文结合影响程序更新的因素,从工程化角度分析适用性。
1 影响因素说明
1.1 网络带宽
程序更新作为短时大数量传输的应用,加大车载网络带宽是最有效的方式。这涉及到整车网络架构调整,而且由于网络连接的特殊性,必定导致多控制器甚至整车所有控制器变更,难度颇大。
从具体网络类型来说,CAN、CANFD、Ethernet-T1均为整车主流应用方案。以博世公司发布的整车电子电器架构发展方向说明Ethernet-T1大概率成为整车主干网,CAN、CANFD构成域内子网。如图1所示。
图1 博世发布的EE架构发展预测
从程序更新效率出发,域内子网往往是限制更新速度的关键。就CAN而言,目前市场主流车型多采取125、250、500kb/s三种速率。为了提升程序更新效率,架构设计工程师对CAN线波特率应首选500kb/s,逐步放弃较低的波特率。
CANFD作为CAN的升级版通信方式,其优点明显,主机厂引入方便。但考虑车型历史包袱、供应商资源等限制,整车切换的案例并不多见。FD tolerant节点和FD节点混合组网,在车辆正常工作时其用CAN报文通信,在程序更新时对支持CANFD的节点切换为FD通信,如此可在整车提前上一两个CANFD节点,既可验证技术成熟度又方便后期其余节点逐步向FD切换,不失为一个过渡方案。
1.2 程序更新流量负载率
程序更新流量负载率加大多受限于网关路由能力、更新节点报文接收能力、Tester节点报文发送能力等。项目推进过程中需对路由节点、节点报文接收能力提出明确要求,不出现帧颠倒、丢帧的情况,以此保证较高负载率下的更新成功率。
1.3 有效载荷
此主要是针对目前主流程序更新方案依赖于诊断服务实现。在CAN/CANFD环境下由15765封装UDS服务,在Ethernet环境下为13400封装UDS服务。有效载荷加大主要有两方面,一为分配块大小时考虑将每帧报文占满,另一方面为约定控制器接收块大小的下限。前者是考虑不出现填充字节,后者为杜绝频繁发起数据传输请求、格式字节及等待应答造成的时间浪费。
1.4 Bootloader独立的网络层时间参数
有别于Application的应用场景,Bootloader应独立定义比Application更快的时间参数。以CAN节点为例,STmin参数在Bootloader的定义多快于Application。
1.5 并行更新
并行更新主要用于车内多域之间、同一域多网段之间,由于网络的独立性,依靠路由节点对多网段同时更新。此方案主要应用于主干网带宽明显高于各子网时,依靠多子网并行,提高主干网利用率,节约时间。
从工程角度,此方案应用的前提是将控制器程序更新Tester功能转移到网关控制器。另需将信息安全机制同步转移。以一典型FOTA方案说明,图示见图2。
1.6 同步处理
此处主要针对控制器对烧写报文的接收与Flash写入做同步处理。不再等待完整多帧报文接收完再传递到应用程序处理,变更为接收一帧处理一帧。需要注意不同芯片对Flash操作的最小字节数目不一致,控制器要协调好报文流有效数据与Flash操作之间的关系。此方式也有助于减少控制器对接收Buffer的要求,有助于增大1.3部分提到的块大小。除Flash操作外,校验部分同样适用于同步处理。具体项目而言,对于单一控制器采取同步处理还是串行处理应实际测试后作出决定。以CAN更新为例,图3表示烧写报文流接收与Flash操作之间的关系。
图2 典型FOTA方案框图
图3 报文流与Flash写入关系
1.7 压缩升级
在数据传送前对数据进行压缩并在控制器内完成数据解压还原,以此达到减少数据传输的目的。应用场景决定了压缩算法必须选取无损压缩且契合逐帧接收、逐帧解压的特点。
但在工程应用时,由于解压操作是在控制器内部完成,压缩比、解压效率、RAM消耗是选取解压算法的重要指标。解压效率上限受制于1.6部分提到的同步处理,即报文接收到执行解压、写Flash,其操作完成时间应早于下一帧报文。基于字典的压缩方式 (LZSS、LZMA等)都可以是压缩算法的备选方案,项目开展应根据控制器实际情况评估。
另外需补充一点,由于压缩升级方案其释放升级文件为压缩后的数据,其地址信息、长度与控制器解压完地址信息、长度不对应。烧写流程中应说明控制器内存起始地址、控制器内解压后数据长度、压缩数据长度的位置。以ISO14229-1 2013定义刷写流程为例,在擦除内存命令使用控制器实际内存起始地址、实际长度,请求下载命令使用实际起始地址和压缩后数据长度。
图4中SW Part 1示意为非压缩升级,SW Part 2示意为压缩升级。非压缩升级 (SW Part 1)的刷写文件Data Block与控制器内存储地址一一对应。压缩升级 (SW Part 2)的控制器内Data Block明显大于刷写文件Compressed Data Block,其通过刷写文件Compressed Data Block与控制器内对应Data Block起始地址相同,确定Data Block位置,长度信息通过后续的校验命令确认。
图4 压缩升级在控制器内内存对应示意
1.8 增量升级
增量升级是进一步减小升级文件的手段,一般配合压缩一起使用,进一步减少需传递的文件大小。增量更新从模型上可以描述为目标升级文件和原文件通过对比获取差异信息包,控制器内部将差异信息与原文件计算获得目标文件,完成升级。
由于车载控制器多为嵌入式系统,更新过程中并无太多富余的Flash存储完整差异信息、备份完整的原文件信息,但控制器内原文件为查分计算的基础,故常见于通过在Flash上分配一块备份区间,分批次对原文件所占内存空间进行更新。示例见图5。
图5 增量升级框图示意
2 结论与建议
增加带宽、负载率、有效载荷及调整网络层时间参数通过提升更新数据的传递速度提升更新效率。并行更新和同步处理旨在将程序更新的串行动作改变为并行动作,压缩升级和增量升级则将目光集中于缩小升级包大小。对于后者由于和控制器硬件关联性较大,更多时候为主机厂提出技术方向各个零部件供应商结合实际考虑实现方式。
实际项目过程中,为提升程序更新效率,往往多个方案共同应用。通过多种手段将控制器更新时间控制在需求之下。