面向OTA需求的汽车电控单元Bootloader设计

lidenghui

最近很多读者对车联网相关知识非常感兴趣，并在后台多次联系小编，希望多多分享相关知识，公众号本着非盈利单纯传播知识的理念，转发中国科学技术大学陈睿智同学等发表的《面向OTA需求的汽车电控单元Bootloader设计》一文中部分内容作为本期小课堂分享内容。
本期小课堂内容选自仪表技术期刊2021年第6期文章，文章DOI为：10.19432/j.cnki.issn1006-2394.2021.02.003

1.引言
随着现代汽车不断地推进智能化、网联化，软件正成为汽车技术的核心之一，如今高端车型的总代码量已经达到上亿行。代码量的增加使得整车出厂前无法完全规避软件漏洞，必须售后通过软件更新修复，但传统的软件升级过程需要诊断设备连接车上 OBD ( On-Board Diagnostics，车载诊断系统) 接口进行，无论是让车主前往 4S 店进行升级还是厂商召回，都将大量消耗时间、人力成本。
为了解决软件升级的难题，特斯拉、蔚来等新兴汽车公司开始采用空中升级( Over-the-Air，OTA) 技术，使用无线网络推送软件包，让升级过程能够远程进行。在该技术的帮助下，不仅软件漏洞可以被及时修复，还 能以增加软件新特性的方式提升车辆性能，改善用户驾驶体验，让汽车成为可以不断进化的智能终端。
但汽车 OTA 的出现也为汽车 ECU 的 Bootloader设计提出了新的需求: 车内控制器数量、种类繁多，软硬件差异很大，网络构成复杂，通信速率有限，使得车辆内网上的软件包传输不稳定，OTA 升级过程容易出现丢包、下载中断等情况，需要支持断点续传功能。由于车企最终的软件包大多由供应商提供，如果软件版本管理不善，也容易出现新版 ECU 软件与原系统不适配的情况，需要支持软件回滚功能。本文将给出一套基于 UDS 诊断协议的 CAN 总线 Bootloader 软件实现方案，满足上述 OTA 功能需求。

2.UDS 协议概述
UDS 即统一诊断服务( Unified Diagnostic Serv- ices) ，该协议由 ISO 14229 所制定，是用于汽车 ECU故障诊断以及维护的通信标准。协议中除了包含常用诊断相关服务的实现标准，还提供了一套参考的Bootloader 软件刷写流程。流程分为必须执行的标准步骤和可选的推荐步骤、自定义步骤，主机厂可在实现标准的基础上，根据需要对 Bootloader 进行定制化。
UDS 协议过去被用于 OBD 接口软件升级的场景， 而在 OTA 场景下，整套协议栈可被复用，区别在于上位机由诊断仪变为了车载的 OTA 主控制器。可在标准允许的范围内增加一些步骤，来实现 OTA 所需要的功能。

3.基于 UDS 协议的 Bootloader 方案设计

3．1实现平台

本文设计的 Bootloader 诊断刷写软件运行于 NXP公司的 16 位单片机 MC9S12XEQ512上，该款单片机具有 512KB 的 P-Flash，32KB 的 RAM，以及 4KB 的模拟 EEPＲOM。其中，P-Flash 最大可设置 24KB 的保护区，可用于存放 Bootloader 软件，防止其被可能发生的 Flash 误操作所破坏; 模拟的 EEPＲOM 本质上是 D- Flash，硬件提供相关机制使其能像 EEPＲOM 一样被使用，可用于存储与程序跳转相关的标志位。

3．2软件升级方案

单片机所配套的IDE 编译源代码后会生成S19 文件，文件包含 Flash 地址以及应刷写的程序内容。S19文件先是保存在 OTA 服务器中，后会经过无线加密传输发送到车载 OTA 主控制器上。该控制器会对 S19 文件进行解析，并将解析后的结果包装成 UDS 诊断服务的形式发送给汽车 ECU，最后再由 Bootloader 软件进行文件接收和 Flash 烧写。

3．3 Bootloader 软件概述

Bootloader 软件是一段出厂时固化在Flash 中的软件，在地址空间分布上和系统应用程序分开。汽车ECU 上电后一般先执行 Bootloader 程序，之后再根据非易失存储器中的标志位来决定，是跳转至系统应用程序，还是停留在 Bootloader 等待接收程序文件。Bootloader 程序与系统应用程序之间的跳转条件如图 1所示。



UDS 协议中定义了三种会话模式，默认会话、编程会话以及扩展会话( 后两个合称为非默认会话) 。在系统应用程序中请求切换编程会话，ECU 会复位并切换到 Bootloader 程序，此举可用于启动刷写流程; 在 Bootloader 程序中请求切换默认会话，如果应用程序有效，ECU 会复位并切换到系统应用程序，此举可用于刷写流程后返回。图 1 中“S3 定时器”为维持非默认会话的定时器，一旦超时则要退回默认会话; “编程请求有效”和“应用程序有效”为跳转所需标志位。

3．4涉及到的诊断服务

为了实现基于 UDS 协议的 Bootloader，系统至少需要支持的服务如表 1 所示。另外，出于功能实现需要，在本设计中会额外增如表 2 所示的服务。





其中，表 2 的流程控制可根据请求中的流程 ID 执行内置在 Bootloader 软件中的一个函数，属于一个比较弹性的服务，在软件运行过程中可以实现多种功能。

3．5刷写步骤

整个软件刷写过程分为三个阶段: 预编程、编程中和编程后。每个阶段都由一系列的诊断服务请求构成。

3.5.1  预编程

预编程阶段需要进行软件下载前的准备流程，将网络环境配置成编程状态，大致步骤如图2 所示。



每个步骤的详细说明如下:
① 诊断会话控制: 网络配置相关的服务无法在默认会话下进行，因此要切换到扩展会话，此时会启动S3 定时器。
② 流程控制( 推荐) : 在OTA 的场景下，为了保证刷写过程的安全进行，编程的前置条件检查十分重要。OTA 升级的前置条件包括钥匙开关打在KL15，车速为 0，档位为 P 档等。该步骤通过流程控制服务实现，条件判断由 ECU 内部的函数进行。
③ 控制故障码设置: 当网络中某一 ECU 处在编程状态时，为了让出带宽，网络上其他 ECU 应停止发送应用相关报文，但此举可能会导致误报故障。因此， 上位机需要通过广播发送( 功能寻址，或通过物理寻址逐一发送) 的形式禁用网络上所有 ECU 的故障记录功能。
④ 通信控制: 禁用网络上所有 ECU 的应用相关以及网络管理相关报文的发送，同样采用广播发送。

3.5.2  编程中

该阶段实现程序文件传输以及刷写过程，大致步骤如图 3 所示。



每个步骤的详细说明如下:
① 诊断会话控制: 切换到编程会话来让 ECU 跳转到Bootloader 程序。具体的做法是将 D-Flash 中“编程请求有效”标志位置位，之后执行单片机软件复位，根据跳转流程( 图 1) ，系统最终会停在 Bootloader 程序中。
② 安全访问( 推荐) : 为了保证程序来源可靠， Bootloader 在执行刷写步骤前要通过安全访问服务确认上位机的身份。服务执行分为四步:
a.  上位机向下位机请求种子(Seed)
b.  下位机根据当前时间信息生成一个随机种子， 通过诊断响应返回给上位机;
c.  上位机将种子代入事先约定的函数，计算出密钥( Key) ，并再次发送给下位机;
d.  下位机用相同的函数计算密钥，并进行比对。如果两者计算出的密钥相同，则解锁刷写权限，否则便 停止刷写。
③流程控制( 推荐) : 调用 Flash 操作的相关函数，将保护区以外的 P-Flash 内容全部清除，并将“应用程序有效”标志位清除。在执行 OTA 所需的断点续传时，该步骤可以跳过。
④请求下载: 由于刷写内容的地址不一定连续， S19 文件中通常包含若干段( Segment) 的程序，因此刷写过程也以程序段为单位进行。该服务请求中包含段起始地址、段长度信息，Bootloader 收到请求后应做好接收文件的准备。
⑤传输数据: 该服务会请求多次，直到程序段内的数据全部传输完毕。每次传输数据服务请求会发送S19 文件中的一行数据，并附上 8 位校验和; Bootloader收到请求后先进行完整性校验，如果通过，就进行Flash 烧写，如果不通过，返回否定响应请求重新传输。
⑥请求传输退出: 整个程序段的数据已经传输完毕后，上位机会请求该服务告知 Bootloader 传输结束，并附上整个程序段的校验值，Bootloader 对刷写进 Flash 的程序文件代入校验算法计算，进行完整性检验。若检验通过，如果还有程序段未下载，则从步骤④ 开始继续进行; 若检验不通过便终止下载。
⑦ 流程控制( 推荐) : 进行程序有效性校验。由于步骤⑤和⑥已经对数据进行了两次校验，此处对已刷写的程序段数量进行校验即可，校验通过则将“应用程序有效”标志位置位。至此编程阶段结束。

3.5.3 编程后

在程序刷写完成以后，ECU 应跳转回系统应用程序运行，同时还要将网络状态恢复到刷写开始前，该流程称为编程后同步，大致步骤如图 4 所示。



每个步骤的详细说明如下:
① 诊断会话控制: 请求切换默认会话，下位机在收到该服务请求后将“编程请求有效”标志位清除，并 执行软件复位。由于“应用程序有效”标志位已置位， 所以复位后会跳转到应用程序运行。
② 诊断会话控制: 切换到扩展会话以执行网络配置相关服务。
③ 通信控制: 与预编程步骤④对应，恢复非诊断信息发送。
④ 控制故障码设置: 与预编程步骤③对应，开始正常记录故障码。
⑤ 清除诊断信息: 由于 ECU 已被重新编程，旧程序存储的故障码已不再需要，因此需要通过该服务将之前存储的故障码清除。
⑥ 诊断会话控制: 切换默认会话，恢复初始状态， 至此整个刷写流程结束。

4.面向 OTA 需求的相关功能设计
前文所述的刷写流程可以满足大多数情况的汽车ECU 升级需要，但为了更好应对 OTA 升级的需求，此处提出断点续传和软件回滚的实现方案。

4.1 断点续传设计

由于车内电气环境和网络环境都比较复杂，OTA主控制器对汽车 ECU 的刷写过程很有可能受到电源过压/ 欠压、CAN 总线拥塞等情况的干扰，因此 Boot- loader 软件在设计时要考虑到刷写流程被中断后该如何继续。良好的续传设计既能提高刷写的稳定性，还能减少不必要的下载时间浪费。

4.1.1短时中断处理

对于网络拥塞等情况导致的短时中断，采用超时重发的方式进行处理。
上位机每当要发送诊断请求时，都应设置一个发送定时器，如果定时器超时仍未收到响应，则认为此次服务请求不成功，重新发送一次，但重发次数一般不得超过 3 次。
另外，下位机应做好与上位机的流程同步，如果需 要处理的服务不可重复执行( 或重复执行比较耗时) ， 例如“传输数据”、“流程控制-清除 Flash”等，必须设置标志位记录是否执行过相关服务，防止进行复数次 服务处理; 如果服务的重复执行对刷写流程没有很大影响，例如“通信控制”、“控制故障码设置”等，那么可 以不做另外处理。

4.1.2长时中断处理

对于电源欠压等情况导致的长时中断，应进行断点续传相关处理。
软件上的处理逻辑是，上位机在重发服务请求超过 3 次后仍没得到响应，可视为某些故障导致了下载中断，应在用户界面上提示司机进行问题排查，之后再重启下载流程，可根据中断位置进行不同的处理:
(1)中断发生在预编程阶段，那么重启后按照原流程进行;
(2)中断发生在编程后同步阶段，那么重启后仅执行编程后阶段;
(3)中断发生在编程阶段，若未清除 Flash，那么重启后按照原流程进行，若已清除，那么重启后从断点处继续下载。
长时中断续传的技术要点有:
(1)续传时，编程阶段跳过清除 Flash 的步骤，即图 3 中的步骤③;
(2)上位机应将刷写进度实时记录在非易失存储器当中，包括当前的程序段编号、行编号，以便在续传时找到起点;
(3)对于已下载完成的程序段，不用重复进行“传输数据”服务，但“请求下载”和“请求传输退出” 两个服务依然执行，主要目的是根据两个服务提供的 段首地址、数据长度和校验值，对已下载的程序段进行 完整性校验;
(4) 使用断点续传功能下载的程序，其出错概率相比连续传输的程序要高，为了更好地检测错误，要选择安全性更高的完整性校验算法，SHA1 校验算法可获得 160 比特的散列值，安全性好，运行效率也较高，在 Bootloader 设计中可替代校验和。

4.2软件回滚设计

如果 OTA 下载的软件出现兼容性问题，例如协议与其他 ECU 不匹配，可能导致软硬件失效，进而引发安全问题。因此，汽车 ECU 的 Bootloader 程序应设计软件回滚功能，及时恢复到应用程序的稳定版本，技术要点如下:
(1) OTA 主控制器应对历史刷写成功的程序文件进行备份，至少保留两个版本;
(2) 刷写成功的判断条件为，编程后同步阶段的所有服务成功执行;
(3) 软件回滚的流程基本可按照正常刷写流程进行，可在编程后流程中使用“通过 ID 读取数据”服务读取版本号，对刷写结果进行确认。

5.软件功能测试
为了使结果能够直观体现，测试过程使用的是在桌面 Linux 系统上开发的具有图形界面的上位机，用于模拟车载 OTA 主控制器。上位机采用面向对象的编程思想进行编写，与 UDS 诊断相关的软件部分实现分层、模块化，以便移植到 OTA 主控制器上。
上位机通过 CAN 接口卡连接到 CAN 总线上，之后可对总线上的所有汽车 ECU 发送诊断服务请求，并且诊断相关的报文信息和软件刷写进度都将实时显示在界面上，如图 5 所示。



上位机支持上文所提到的 S19 文件解析、超时重发、断点续传、软件备份、回滚等功能。为验证 Boot- loader 软件功能实现情况，所进行的测试工作如下:
(1)进行多轮次刷写测试，验证 Bootloader 软件能否正确执行刷写流程并跳转回系统应用程序;
(2)将上位机的报文发送时间间隔调小，人为制造总线拥堵，使系统多次触发超时重发机制，验证该情况下 Bootloader 是否还能正确刷写;
(3)在刷写过程中切断电源或将电压降至可运行阈值之下，人为使下载中断，并在恢复后使用断点续传机制，验证该情况下 Bootloader 是否还能正确刷写;
(4)通过上位机后台程序，在断点续传开始后随机修改 1 比特下载文件，并且保持校验值不变，验证该情况下 Bootloader 能否检测出文件变化并返回否定响应;
(5)连续刷写两版不同的程序，并紧接着使用软件回滚功能，使用“通过 ID 读数据”服务读取版本号，验证下位机程序是否成功回滚。
经过以上测试，本文所设计的 Bootloader 软件不仅能够实现稳定的软件升级，还满足了 OTA 断点续传和软件回滚的功能需求，提升了软件升级过程的安全性和可靠性。

6.结论
本文以满足汽车 ECU 的 OTA 软件升级功能需要为目的，结合 UDS 诊断协议 ISO 14229 所提供的编程流程，设计了一款用于汽车 ECU 的 CAN 总线 Boot- loader 软件。该软件除了具备诊断刷写软件的常规功能之外，还支持断点续传、软件回滚等功能。经过与上 位机的联合测试，该软件被证明能够应付网络拥塞、电 源欠压等情况导致的下载中断，检测出软件包的变化， 以及回滚到旧版程序，保证了软件升级的稳定性和安 全性，达到了本文的设计目的。

注：文章中引用数据和图片来源网络

您的点赞留言，是我们的最大动力!