基于UDSonCAN的Bootloader设计

陈祖锐，廖振伟，谷城，刘志军，刘虎山

柳州赛克科技发展有限公司，广西柳州 545005

0 引言

由于TCU在汽车中的安装环境复杂，拆卸TCU硬件十分困难，再加上利用串口、JTAG等交互手段均需要给TCU增加额外的硬件电路，增加开发成本。所以本文参照ISO14229标准的UDS(unified diagnostic services)诊断规范，结合整车厂的诊断规范和软件升级规范需求。设计一套UDSonCAN为基础的TCU软件升级方案，即TCU的Bootloader方案设计。该方案以CAN(controller area network)网络通信为基础，基于UDS诊断服务规范，实现对TCU特定的Flash地址区域进行程序刷新。此方案的实现，在不需要对TCU进行硬件拆卸就可以快速、可靠、稳定地进行TCU软件更新，大大缩短软件开发周期，减少开发成本，提高软件程序的交付质量。

1 Bootloader的介绍

1.1 Bootloader应用UDS服务

ISO 14229标准中准确定义了UDSonCAN的全部诊断服务，包括数据传输服务、通信管理服务、上传下载服务、例程控制模式，且每个服务都有特定的SID(service identify)。

此方案是基于UDSonCAN的Bootloader设计方案，主要用到的UDS服务及其功能概述如下：

(1)诊断会话控制：控制电控单元处于不同的诊断会话模式中。

(2)通过标识符读数据：向电控单元读取特定的信息。

(3)通过标识符写数据：向电控单元写入特定的信息。

(4)例程控制：启动或停止特定的程序。

似乎所有津津乐道的故事都有类似这样一个“风骚”的开始：初识只作乍见之欢。我们似乎都是习惯了喜新厌旧的人，喜欢去新的城市，喜欢探索新的事物，喜欢更换新的物品，喜欢接触新的人……世间的美好，多数在于初见，初见你初妆、初见你笑颜……然而好的事物容易有一个通病，那就是都不长远。越是璀璨，就越是脆弱。花前月下，尘梦如烟，似曾相识，昙花一现！其实，人生难得的是日后久处不厌，如果是，那么，有生之年，有幸遇见。

(5)安全访问：向电控单元请求种子和发送秘钥。

(6)通信控制：开启或关闭电控单元特定报文的接收或发送。

(7)DTC设置控制：停止或恢复电控单元的故障诊断功能。

(8)请求下载：向电控单元请求进行下载服务。

(9)传输数据：向电控单元传输数据。

(10)请求退出传输：向电控单元请求退出数据传输。

(11)ECU复位：向电控单元请求复位操作。

UDS服务对应的SID见表1。

表1 UDS服务对应的SID

1.2 Bootloader应用CAN总线

CAN是基于开放式系统互联通信参考模型(OSI)设计的一种通信协议。CAN协议采用CRC检验和相应的错误处理功能，保证数据传输的可靠性。CAN的通信介质为双绞线、同轴电缆或光导纤维，速率可达1 MB/S，性价比极高。所以CAN总线是当前汽车领域广泛使用的一种通信方式，实现了整车电控单元之间的信息交互，以及电控单元和上位机之间的数据传输和命令交互。其中UDSonCAN在OSI模型中的分层结构见表2。

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

1.3 Bootloader和APP框架设计

Bootloader是嵌入式系统在加电后执行的第一段代码，所以也称为引导程序，主要用于软件刷新。在一个成熟的嵌入式系统方案中，Bootloader和APP(应用层程序)是分开的，分别存放于不同的内存区域中。

此方案设计了多级Bootloader，如图1所示。上电之后默认进入Boot1,逐级跳转至APP，各级Bootloader和APP互不干扰。

图1 多级Bootloader的设计

FlashDriver是一段具备擦除内存数据功能的程序，出于功能安全考虑，Bootloader中不能包含FlashDriver(刷新驱动)，避免程序跑飞运行至FlashDriver中，对TCU程序造成不可逆的破坏。为了避免上述情况，FlashDriver一般存放于上位机中，在编程过程中才将FlashDriver下载至特定的内存区域中，通过Bootloader调用FlashDriver程序，实现内存擦除功能。

2 Bootloader的设计

2.1 预编程设计

在程序刷新之前，需要通知整车其他的电控单元TCU即将进行程序刷新，所以功能寻址需要进入扩展会话模式;利用UDS的28服务，通过功能寻址禁止其他节点的报文发送，使整个CAN总线处于安静的状态，降低总线的负载率，提高程序刷写速度;利用UDS的85服务，禁止整车其他电控单元的故障诊断，防止程序刷新过程中其他电控单元误触发故障码;利用UDS的22服务，读取当前TCU的特定信息(如标定数据版本、软件版本、硬件版本)保证软件版本的匹配性。预编程设计流程如图2所示。

图2 预编程设计流程

2.2 编程设计

在预编程结束之后，进入编程阶段。首先进入编程会话模式，然后通过安全访问。

由于FlashDriver是不存储于TCU内部中的，所以第一步是将FlashDriver下载至指定内存区域中。下载完毕利用UDS的31服务进行数据校验，校验无误之后通过Bootloader开始调用FlashDriver程序。

接下来是根据需求擦除特定的内存区域并传输新的数据。传输完毕利用UDS的31服务进行数据校验，校验无误TCU才保存至特定的内存区域中。编程设计流程如图3所示。

图3 编程设计流程

该方案可对各级Bootloader进行更新，在擦除Bootloader内存前会对最基础的Bootloader做备份，防止下载过程中出错导致最基础的Bootloader丢失。

2.3 后编程设计

在预编程和编程结束之后，功能寻址进入扩展会话模式，利用UDS中的28服务，恢复其他节点的报文发送;利用UDS中的85服务，恢复其他电控单元的故障诊断。

根据整车厂的刷新规范，还要利用UDS中的2E服务，写入一些特定的信息(如软件版本号、供应商号等)，便于保持软件刷新的可追溯性。后编程设计流程如图4所示。

图4 后编程设计流程

3 Bootloader测试验证

为了验证此方案的可行性和可靠性，利用了INCA软件和ETAS582硬件工具进行测试。根据设计的刷新流程，编写INCA软件的Prof(INCA软件的刷新流程)文件，Prof界面如图5所示。通过Prof界面选择要刷新的区域，对整个Bootloader方案进行多次测试和验证，INCA刷新界面如图6所示。

图5 Prof界面

图6 INCA刷新界面

测试结果表明，该方案能满足对TCU的程序刷新，并且整个过程方便、快速、稳定。即使人为操作导致刷新过程失败，也可以通过上位机界面或CAN总线数据中判断出失败的原因所在。

4 结论

基于UDSonCAN服务的Bootloader的设计，实现了只需要与TCU进行CAN总线连接，不需要对TCU硬件拆卸，就可以随时随地进行软件刷新。在前期的开发设计中，节约了开发人员的时间成本;在后期的功能升级中，提高了售后服务的工作效率。该方案在整个刷新过程中稳定、防错能力强、可靠性极高，并且严格遵循整车厂的诊断规范和刷新流程,可拓展于OTA软件升级流程中。