客车OTA 实施及其整车CAN 通信设计

2022-03-24周传树

汽车电器 2022年3期

陈鹏，徐梅，周传树，杨炜

（1.浙江吉利新能源商用车发展有限公司客车事业部，浙江杭州 311200；2.浙江吉利新能源商用车集团有限公司商用车研究院，浙江杭州 311200）

客车特别是电动客车正向着智能网联化快速发展，客车智能网联化要求其具备OTA （Over the Air Technology，OTA）功能，从而实现对车载系统软件和数据的及时升级和管控，提高售后服务的效率和品质。

当前主流客车CAN网络上的各控制器软硬件配置差异较大，很多控制器不支持在乘用车领域早已推广的UDS诊断协议，需要进行有针对性的差异化设计，以满足当前客车对OTA的需求。本文首先论述OTA实施的3项关键技术，然后就客车CAN通信设计进行分析。

1 OTA关键技术

1.1 OTA系统及其平台职责

OTA是云端-车端协同工作的系统，主要由云端的OTA管理平台以及车端的无线接收控制器组成。二者通过无线网络连接，共同完成车辆的OTA任务。 OTA管理平台需能够设定多控制器的软件下载顺序、软件版本登记、当前软件版本号识别、目标软件版本号确认、控制器既有软件备份、新软件加密传输、下载失败整体回滚等设定。

OTA管理平台一般采用面向服务的3层体系架构设计：人机交互层、业务逻辑层和数据访问层。人机交互层为管理员提供了OTA的操作页面，如权限管理、车辆信息管理、下载策略管理、下载任务管理等。

1.2 安全传输和安全访问

OTA源于个人移动通信终端业务，该技术应用在汽车，特别是客车，其功能安全就需要更严格的标准，例如要求支持TLS1.2及以上安全协议，支持第三方的安全证书和密钥管理，最终实现从后台到车端的多层级全方位的防护。软件从供应商到达OTA平台、 OTA平台到车端以及车端ECU本身都需采用不同类型的加密机制来确保OTA服务全程安全。在执行任何OTA服务相关操作之前，需完成OTA云端与OTA车辆端的双向认证。 OTA车辆端和OTA云端之间的所有数据通信必须有完整检查机制和防篡改检查机制，过程传输数据要进行加密，避免OTA服务实施成为整车安全的薄弱环节。

软件被下载到车辆终端之前， OTA云端和车端控制器首先根据PKI/CA认证系统进行身份双向认证。验证通过后，OTA服务端和车端建立起基于TLS1.2协议的安全通道，保证云端与车端之间信息传输的安全性。在车端部分，TBOX、 HMI和网关控制器之间的交互信息采用私有协议密文传输，软件包的加解密通过在TBOX、 HMI和网关控制器内部集成的HSM （硬件安全模块）来管理、处理和保存加密秘钥，防止软件包被篡改。

1.3 统一软件刷新标准

OTA的核心服务是完成车载控制器的软件更新，不同控制器的程序更新使用同一个软件诊断刷新规范是提高OTA运行效率和降低OTA服务成本的必然选择。 ISO 14229基于UDS诊断规范，应用于多种数据链路网络，是目前广泛应用的诊断协议标准，国内主流电动客车用控制器如CATL的BMS、主机厂自研的整车控制器以及汇川MCU基本都支持UDS的诊断刷新服务。

常见的ECU刷写文件格式有： Hex、 s19、 bin等。无论是哪种格式，这些文件都会包含：存储地址、数据、校验和（checksum）、记录类型和记录长度信息。 IS014229规范关于程序更新定义的几项基本刷写步骤是： ①请求例程控制； ②请求下载； ③数据传输； ④请求数据传输退出并验证校验。

2 客车端OTA相关的通信设计

客车电动化已成为一个明显趋势，本章节以电动客车为研究对象，以OTA需求为中心，针对电动客车网络通信从网络拓扑、网络管理以及人机交互设置3方面重点进行分析。

目前主流电动客车的整车CAN网络架构（网络拓扑、通信协议、控制器CPU算力及存储能力等）相对于传统燃油客车并未完成彻底转型，使得一些近年来在乘用车领域迅速推广的智能技术未能在电动客车上得到切实应用，如自动导航、辅助驾驶和OTA等。其中OTA技术的实施，迫切需要客车网络通信系统进行升级设计。

2.1 客车CAN网络拓扑设计

2.1.1 当前客车车载网络拓扑现状

当前电动客车常见的CAN网络拓扑是基于功能域进行设计，即将功能关系较为紧密的控制器规划在一个网段，整车网络拓扑大多是VCU集成网关或设置中央网关控制器的多路通信拓扑。这种网络拓扑对于早期电动客车是相对可靠和实用的。

2.1.2 当前客车车载网络拓扑不足

基于OTA的智能技术的实施和更高级的软件刷新服务产生，使得当前基于功能域设计的网络拓扑逐渐暴露出短板，如控制器节点多、功能重叠，造成软件反复开发升级，硬件资源冗余或无拓展性。一个临时的策略是增加网段来安放新增的控制器，例如增设底盘域来布置EPS和EPB。但随着整车配置和客户需求的变化，相应的VCU或网关控制器的程序便需要配合更新，如果增加仪表周边的智能化设备，例如电子后视镜和ADAS，对程序的更新需求会迅速增加，同时对硬件的需求也会更高，控制器数量的增加还会导致CAN线长度逐渐接近限值。

2.1.3 融合域控制器的网络拓扑设计

自动驾驶技术要求OTA服务更稳定流畅高效，以便及时关闭软件中的漏洞并实现更好的客户体验，本着高效刷新的原则，传统零散的单一功能控制器会逐渐被高集成度的域控制器所取代，同时自动驾驶技术要求不同域之间的通信更紧密，比如底盘域和动力域，动力域和车身域。NAVALE等指出驾驶辅助域和动力域也会因为通信的增多而逐渐融合，相应功能的不断丰富，演变成为整车行驶控制域。

本文提出面向服务的软件设计思想，自上而下建立整车3级网络拓扑，加入域控制器（PDC&BDC），车载高性能计算机（HPC）的角色，同时结合客车的布置特征，加入空间域的设计方法，形成一种兼容性强、灵活可靠的网络拓扑。

如图1所示，车端选择TBOX作为OTA升级的主控控制器，该控制器集成OTA升级的主控程序UC （Update Control），作为汽车端升级控制的主体与OTA平台侧进行数据通信，并控制整车其他控制器完成OTA升级活动。 TBOX对整车主要服务有：本地ECU配置信息的采集和上报、与OTA管理平台交互获得升级策略文件、目标升级包的下载、升级包安全性和完整性校验、按照升级策略文件逐个进行升级包分发和目标ECU升级流程的发起、升级过程的记录及上报、升级过程中与HMI的交互。

图1 一种支持OTA的整车网络拓扑

部分控制器的软件包较大，通过CAN通信传输时间较长， OTA数据传输介质需要考虑更高效的非CAN通道的数据传输方式，如图1 中人机交互界面的程序升级设计了LVDS的数据传输办法。

2.2 整车网络管理设计

2.2.1 OTA对整车网络管理的需求

一般OTA要求其所服务的控制器统一支持基于UDS的诊断刷新协议，要求整车进行OTA之前，同网段ECU实现以下需求。

1）接收UDS诊断服务指令，实现应用层通信的关闭，包含但不限于关闭常规应用报文和网络管理报文。

2）接收UDS诊断服务指令，停止或者恢复诊断故障代码的检测和记录，包含但不限于关闭常规应用报文和网络管理报文。

2.2.2 非UDS控制器网络管理的设计

客车生产设计往往存在客户对部分电气配置的指定，难以实现统一支持UDS协议，为使支持UDS的控制器能够稳定实施OTA服务，需采取措施来避免非UDS协议的控制器在OTA过程中的通信冲突。电动客车部分控制器的唤醒条件如下。

1）整车上下电流程强关联控制器： VCU、 BMS、低压配电盒等，其唤醒条件一般有充电信号有效、 ON挡电有效。

2）客户指定件：胎压监测、电子驻车等，其唤醒条件一般是ON挡电有效。

3）仪表总线模块和公交调度系统一般要求ACC电即唤醒工作。

对于与整车上下电流程强关联的非UDS控制器，通过补充CAN通信协议建立UDS需求的OTA通信管制和DTC管制。对于客户指定的与整车上下电无关联的一般电器件，可以统一由BCM对其电源进行逻辑控制实现UDS需求的通信管制和DTC管制，该方案的实施需要控制器配合程序修改和BCM配电逻辑的定向开发。

2.2.3 预约升级场景下的网络管理

预约升级场景中， TBOX需支持远程唤醒功能，在预约时间到时远程唤醒TBOX并判断车辆OTA前置条件均通过后，启动升级流程对目标控制器进行升级。对于控制器不具备在整车OFF 挡时被唤醒刷写升级的，需TBOX唤醒BCM 并提供ON 挡电，在ON 挡电状态下完成刷写升级。升级过程中BCM 需限制车内大功率用电负荷如空调、前照灯等，避免24V 蓄电池电量消耗过快导致OTA服务中断。

2.3 OTA升级人机交互

OTA人机交互界面是用户执行OTA升级流程的操作入口，通常将OTA的升级界面设计在整车HMI端。升级界面的内容包含升级任务通知、升级前置条件确认、免责条款告知、软件下载、确认安装等主要流程。整车端的OTA升级的交互流程如图2所示，图2流程中，确认下载和前置条件步骤需用户手动确认，其余为程序自动。前置条件选项可能会需要用户反复操作以确保整车按标准流程完成程序升级，为避免用户在确认升级后误断钥匙电或一键下低压电造成控制器升级异常， OTA模式下BCM模块会强制整车ON挡电，强制时间一般不超过30min， VCU会自动完成高压回路的断电处理，期间如用户因紧急情况需中断升级可以通过整车总闸断电处理，后台将记录升级日志并及时向客户反馈异常中断原因并告知其系统风险。