基于UDS 协议的整车VCU 固件升级方案*

张开起，兰建平，周海鹰

(湖北汽车工业学院 汽车工程师学院，湖北 十堰442002)

0 引言

CAN 总线技术因其实时性强、可靠性高、网络结构灵活等优点，作为骨干通信网络，被广泛应用在汽车领域。 但随着汽车电子技术的快速发展，整车的电子电气架构日益复杂，车载电器与电子控制单元(Electronic Control Unit，ECU)数量越来越多，整车电控单元固件升级复杂性越来越高[1]。

在开发、测试和后期维护汽车ECU 的过程中，需要频繁进行ECU 软件更新操作，考虑汽车环境的复杂性，串口、JATG 等方式进行固件更新时需要增加额外控制单元外围电路且需拆卸相关ECU 单元才可进行升级操作，容易损坏硬件设备；传统Bootloader 缺乏UDS 的安全服务流程，下载数据可靠性无法保证。 如何在不进行拆卸的情况下，快速、可靠、稳定、安全地进行ECU 升级变得尤为重要。

陈姿霖等人[2]对UDS 整车诊断系统的设计方法进行了详细介绍和简单服务的实现，但并未具体展开介绍和进行升级服务设计；聂幸福等人[3]介绍了基于UDS 的Bootloader 设计，实现了上位机开发理论过程，为汽车电子系统提供了基础的技术支持，但缺乏与实际车辆ECU 结合的过程。

本文在研究Bootloader 技术和UDS 协议簇的基础上，以S32K144 为车辆ECU 主控芯片，以CAN 作为数据链路层和物理层实现，以ISO14229 和ISO15765应用层协议为统一诊断规范，构建CAN 总线通信诊断节点ECUs，设计基于UDS 协议的汽车VCU 升级方案，实现固件更新功能。

1 概述

1.1 Bootloader 应用UDS 服务及协议体系概述

统一诊断服务(Unified Diagnostic Services，UDS)是一个用于汽车行业诊断通信的通用需求规范，可以在不同的汽车总线(如K-line、CAN、LIN、FlexRay、Ethernet 等)上实现，主要包含6 大类服务单元(诊断和通信管理服务、数据传输服务、存储数据传输服务、输入输出控制服务、例程服务、上传/下载服务[4])共26 种具体诊断服务，每种服务都有自己的独立ID，即SID(Service ID)，每个SID 代表了一类指令。

Bootloader 是系统运行之前执行的一段引导加载程序，主要负责初始化硬件设备、加载启动和程序跳转等任务。 由于基于UDS 的Bootloader 在诊断升级规范方面进行了标准统一、在诊断升级方面设置权限机制、在数据上进行安全校验等特点，逐渐取代传统的Bootloader 成为主机厂在线固件更新升级模式只是时间问题而已[5]。

固件升级过程涉及的UDS 服务如表1 所示。

表1 固件升级过程涉及UDS 服务列表

基于CAN 总线实现UDS 诊断，完整的车载诊断协议体系结构应分为应用层、网络层、数据链路层和物理层。 诊断升级首先由符合ISO14229-1 或ISO15765-3 的应用层开始，经过网络层ISO15765-2实现数据的传输、打包、解包等，再由网络层映射到数据链路层ISO11898-1，转化为有效的CAN 数据帧，最后到物理层的传输介质。 UDSonCAN 在OSI 模型中的分层结构如表2 所示。

表2 UDSonCAN 在OSI 模型中的分层结构

1.2 整车通信节点系统组成

车载式多节点汽车最小电控系统主要由VCU(核心)、BCM、MCU 三个通信节点构成，如图1 所示，通信诊断节点由稳压电源电路、微控制器核心电路、CAN 通信电路、ADC/DAC 信号采集驱动电路、隔离电路、高边驱动电路组成，如图2 所示。各节点功能如表3 所示。

图1 整车最小电控系统节点组成

图2 VCU 通信节点构成

表3 诊断通信节点功能分配表

2 整车VCU 通信节点硬件设计

本文研究的样车对象为沙滩样车，该样车装配BTL15 系列专业直流电机，供电系统由5 个12 V/80 AH 的铅酸蓄电池构成，为整个车身提供60 V 的动力电源，搭配输入45 ～75 V 的DC-DC 直流转换器，为整个电控单元提供12 V 低压电源。

选择NXP 公司的S32K 系列芯片S32K144 作为车载ECU，该MCU 拥有多路CAN 模块，片上存储器包含512 KB 的Flash 以 及64 KB 的SRAM，是NXP于2017 年推出的基于32 位ARM®Cortex®-M4F和Cortex-M0+内核符合AEC-Q100 规范的通用汽车级微控制器。

(1)供电系统电路。 供电系统电路(如图3 所示)包含双输出直流降压电路，将供电源+12 V 通过降压型电压转换器输出直流电压为5 V 和3.3 V，分别为微型控制器和其他模块提供稳定直流低压电源。

(2)CAN 收发通信电路。 CAN 收发电路(如图4所示)主要由PHY 芯片(TJA1050T)电路构成，用于节点间数据通信传输。 TJA1050T 是最高可达1 Mbits/s速率的CAN 收发器，在芯片的CAN 协议控制器和物理双线CAN 总线之间提供物理接口。 其主要功能是将CAN 控制器的逻辑电平转换为CAN 总线的差分电平。

(3)高边驱动电路。高边驱动电路主要由6 路电桥驱动电路组成，每路驱动电路与各自执行器件相连，用于控制沙滩车喇叭(如图5 所示)、转向灯、制动灯、警示灯等执行器执行动作。

图3 供电系统电路

图4 CAN 收发通信电路

图5 高边驱动电路

(4)隔离电路。 隔离电路包括输入隔离电路和输出隔离电路(如图6 所示)，主要用于保护节点微控制器芯片不被损坏。

(5)AD/DA 转换电路。 AD/DA 转换电路分为ADC 信号采集电路和DAC 输出驱动电路(如图7 所示)，ADC 用于采集传感器的信号量供节点进行数据处理，DAC 输出电路采用射集跟随电路，可以减少噪音信号干扰。

图6 隔离电路

图7 AD/DA 转换电路

3 基于UDS 的IAP 升级软件设计

软件平台使用基于ARM 架构同时集成Eclipse IDE、GNU 编 译 器 集 合(GCC)和GNU 调 试器(GDB)的集成开发环境S32 Design Studio for ARM。开源平台S32DS for ARM 为设计人员提供了一个简单的开发工具，使得开发更加简单高效。

3.1 PHY 层驱动配置

图8 基于S32 Design Studio 的CAN 波特率配置

在使用S32K144 自带的CAN 模块进行收发报文时， 需要进行一些配置和初始化操作。 结合S32DS 平台项目向导创建使得操作更加简洁方便。图8 为配置CAN 500 kbit/s 波特率界面。

3.2 网络层协议软件设计

ISO15765-2 协议提供的网络层服务以客户端(Client)和服务端(Sever)的模式存在，上位机软件在C/S 模型中充当客户端； 而待诊断ECU 作为服务端。CAN 报文一次只能收发8 B，而如果进行大于8 B 传输，则需要网络层将数据以多帧方式传输，也就是将数据拆分和组装来实现[6]，其网络层数据帧格式如图9 所示。

程序中网络层首先调用network_recv_frame()函数对应用层发来的CAN 数据帧进行处理判断(功能寻址还是物理寻址，单帧还是多帧，有效帧长度等)，如果是单帧数据， 校验通过后调用recv_ singleframe()函数进行数据接收，最后直接调用回调函数中的N_USData.indication()函数通知应用层单帧信息接收完成或者失败。 如果是多帧数据，需要先对多帧数据的首帧、连续帧、流控帧进行switch 判断，校验通过后分别调用recv_firstframe()、recv_consecutiveframe()、recv_consecutiveframe()函数进行数据接收，最后调用回调函数中的N_USData.indication()函数通知应用层多帧信息接收完成或者失败。

图9 网络层协议单元格式

3.3 应用层协议软件设计

本文诊断服务代码严格按照ISO14229-1-2-3 和ISO15765-3 应用层协议编写实现，UDS 诊断的请求报文和响应报文格式内容包含SID(Service identifier)服务标识符、Sub-function(Subset-function)子功能、Parameter 参 数、DID(Data identifier) 数 据 标 识 符 和NRC(Negative Response Codes)否定响应码。肯定响应格式为：[SID+0x40]+[Sub-function]+[Parameter]或者[DID+0x40]+[Parameter]，否定格式为：[0x7F]+[SID]+[NRC]。

设置时间管理机制，防止系统长时间无响应进入死循环，在默认会话模式下设置P2 定时器，分为P2_SERVER 服务器定时器，其值为0x32，定时50 ms；P2x_SERVER 客 户 端 定 时 器， 其 值 为0x190， 定 时400 ms。 在非默认会话模式下设置S3 定时器TIMEOUT_S3SERVER，定时500 ms。如果Client 端或者Server 端在规定的时间内无响应， 则定时器向系统提出反馈，进行退出当前会话进入默认会话或者进行NRC回复等操作。 诊断服务同时设置否定响应码(Negative Respose Code，NRC)。 其内部代码执行流程如图10。

3.4 IAP 在线固件升级

传统的固件升级操作需要进行拆机操作，此举不仅费时费力，而且还容易损坏硬件。 为了日后可以方便地通过预留的通信口对诊断系统的固件程序进行更新升级， 本次研究基于UDS 服务的Bootloader 通 过IAP(In Application Programming) 技 术方法进行固件在线升级。

(1)Flash 配置与环境设置。 为了实现IAP，需要将512 MB 大小的内部Flash 分为Bootloader 区(接收固件数据并实现跳转功能，通过Jlink 烧入)、APP1(主程序)区和APP2(新的更新固件缓存)区，在设计固件程序时分别编写Bootloader 和APP1、APP2 项目代码。 S32K44 的内部Flash 的地址范围为0x0000 0000～0x0007 FFFF,其存储地址分配如表4 所示。

在进行Bootloader 下载之前需要进行相关配置操作，主要包括：在IDE 中分别设置Bootloader、APP1、APP2 程序起始地址和存储空间大小；设置APP1 中断向量表(VTCB)偏移量；接收及跳转函数实现；设置编译后运行fromelf.exe 工具，生成.bin 文件等。

图10 程序代码执行流程图

表4 内部Flash 存储地址分配表

(2)结合UDS 的IAP 升级过程。 整个升级过程主要分为三个部分：升级前预处理、IAP 固件升级和升级后后处理。

升级前预处理主要通过功能地址0x999 使VCU、MCU、BCM 节点进入扩展会话模式，然后通过例程控制诊断服务($31)、通信控制服务($28)和控制DTC 设置诊断服务($85)检查升级条件、关闭整车通信数据传输和检测、记录DTC 故障，目的是为整个升级过程提供可靠的升级环境。

经过升级环境预处理后，就可以通过UDS 服务实现IAP 在线升级，整个升级过程需要满足统一诊断服务规范协议要求，同时编程步骤在遵循标准化步骤的基础下，可根据需要进行自定义。 首先通过$10 服务进入扩展会话模式，保持会话，通过$27 服务进行安全访问权限申请(获取种子-发送密钥-算法验证匹配-解锁认证)，进入到$10 服务的02 子服务进到编程会话模式中，由于固件升级涉及敏感操作，需要通过$27 服务不同密钥算法进行二次身份验证。 验证通过后通过$31 服务启动UDS 升级控制，调用$34 服务进行固件下载，调用$36 服务(包含数据格式、地址和大小等信息)进行数据传输，传输数据过程中需要同时调用ECU 内部API 进行指定Flash 的APP2 地址读写操作，固件数据传输完成后通过$37 服务发送退出命令， 然后通过UDS 例程控制进行CRC 数据完整性校验。 校验通过后上位机发送$11 服务进行ECU 复位， 应用程序根据固件信息自行选择更新、复制和跳转工作。 整体固件升级流程如图11 所示。

固件升级后处理主要通过功能寻址的方式将预处理所禁用的功能进行正常恢复。

图11 基于UDS 的IAP 实现固件升级流程图

图12 上位机GUI 界面

(3)上位机软件设计。 上位机(如图12 所示)软件采用C# 编程语言， 软件开发平台为 Visual Studio 2019。 上位机软件利用ZLG 公司提供的开源二次开发库接口函数API 结合UDS 网络层TP 协议模块和相关时间参数定时模块程序进行二次开发，界面简洁，操作容易，主要用于下载需要更新的固件文件，实现IAP 固件升级功能。

4 功能实现与软件升级测试

本部分对上述VCU 升级方案进行诊断功能测试与固件升级验证，测试平台完全依照测试样车实验平台的实际架构搭建而成，使用ZLG 官方测试软件CANtest，接入总线使用其自带UDS 模块进行总线数据分析。

(1)诊断服务功能测试。本次测试选取几个具有代表性的诊断服务ID($10、$11、$3E、$27)为例，主要查看数据链路层对诊断数据包单帧、多帧收发通信效果。 测试结果表明，数据收发正常，无丢帧现象。 其测试结果如图13 所示。

图13 常规诊断报文测试

(2)IAP 固件升级测试。 在固件升级更新过程中，丢包现象是不允许的，将固件程序按(0x80)128 B大小分成若干包，设置连续发送数据帧，且帧间隔为30 ms，最终数据流显示结果如图14、15 所示。 修改固件大小进行多次重复传输测试， 统计结果如表5所示。

图14 固件传输数据流（部分包）

图15 固件分包下载完成

表5 数据传输测试统计表

经过多次测试，结果符合预期，其诊断报文符合ISO1422 和ISO15765 相关协议，同时在程序发生异常或否定时，时间处理机制（超时处理）和NRC否定响应码可以防止系统进入死循环，方便调试。IAP 功能也能够很好地完成软件的固件升级任务并在安全可靠性、成功率、稳定性上都能很好地满足设计需要。

5 结论

基于UDS 协议的VCU 通信诊断节点升级方案完全符合统一诊断服务规范要求，实现了基于CAN总线的IAP 在线固件升级，其诊断服务系统经过测试切实可行，为后续诊断工作奠定了基础，同时VCU升级优化后可以方便维修人员在不需要拆卸VCU的情况下进行升级维护等操作，减少其工作量，提升了工作效率。 该方案不但解决了真车环境中拆卸升级的窘境，同时采用基于UDS 协议的升级流程保证了固件升级数据的安全可靠性。