本文选自由向满和童维勇编著，机械工业出版社出版的《新能源汽车诊断UDS协议及实现》， 本书结合汽车电控系统软件中的BootLoader程序和上位机及脚本介绍UDS的使用场景，并深入讲解其功能，分为基础篇、核心篇、提升篇三部分。主要内容包括新能源汽车电控系统基础知识、基于CAN/LIN总线的通信协议、UDS协议栈架构、基于UDS的BootLoader、通过脚本实现UDS客户端通信、UDS测试等内容。是业内首部UDS的专著，推荐给大家。本文节选了其第八章内容基于 UDS 的 BootLoader：- 06 BootLoader 电控单元 OTA 介绍
由于工艺和安装环境的要求，车辆 ECU 需要在线升级和在线调试，即便是 仅使用 LIN 总线通信的低成本 ECU，也被车辆制造商要求满足这一需求。在线升级和在线调试为 ECU 升级和维护带来了巨大的方便，极大节约了维护成本。以 UDS 协议为基础的通信技术使车辆制造商可以统一管理车载 ECU 的软件升级，目前正在迅速发展的 OTA 技术也是基于 UDS 通信的。
本章以车辆 ECU 软件升级为背景，介绍 UDS 在 ECU 软件升级过程中的 应用。同时，本章既是对前面章节中 UDS 协议应用的补充，也可为初次接触 BootLoader 设计的读者提供设计参考。
BootLoader 即引导加载程序，是为 ECU 提供运行环境初始化和应用数据 更新功能的软件。BootLoader 程序一般包含 UDS 通信协议的实现，闪存的读写和程序跳转处理等功能。一般微控制器（MCU）中包含芯片制造商的 BOOT 程序，但该 BOOT 程序用户无法访问，用户设计的 BootLoader 仅能作为 MCU 的二级 BOOT 程序。图 1 所示为两种 BootLoader 设计方式。
其中，图1a 中用户 BootLoader 只有一级；图1b 中设计了二级 Boot- Loader，其中“BootLoader Manager”为第一级 BootLoader 程序，BootLoader Manager 程序可用于更新第二级 BootLoader 程序；第二级 BootLoader 程序可 用于更新应用程序。二级 BootLoader 程序的设计方式相较于仅包含一级 Boot- Loader 程序的设计复杂得多，特别是程序跳转的处理。BootLoader 机制主要描述 MCU 启动时序和 ECU 软件诊断会话模式的切换 机制。设计引导加载程序时需要考虑不同芯片的启动要求。本节假设 ECU 均采用仅包含一级用户 BootLoader 和应用程序的设计方案。电控单元上电或复位后，MCU 首先执行芯片厂商的 BOOT 程序，在开始 执行用户程序后总是首先执行 BootLoader 程序。BootLoader 程序根据跳转条件， 判断是否跳转到应用程序处运行，如图 2 所示。BootLoader 程序会初始化运行的基本模块，如前面章节中介绍的最小系统等。初始化完成后，BootLoader 程序会检查外部重编程请求（重编程请求通常为通过应用程序写在非易失性存储器中的标识），如果重编程请求判断有效，MCU 会持续运行 BootLoader 程序。MCU 检查重编程请求有效后，需要清除非易失性存储器（根据存储位置，也可是易失性存储器）中的重编程请求标识，同时切换到编程模式，并主动回复在应用程序中接收到的请求进入编程模式服务的响应。 如果没有外部编程请求，BootLoader 程序会检查应用程序是否有效，如果应用程序无效，MCU 停留在 BootLoader 程序中运行；如果应用程序有效，MCU 会跳转到应用程序的起始启动地址处执行应用程序代码。图 3 所示为一种 ECU 软件的诊断会话模式切换机制，不同车辆制造商在 切换机制的实现上有所不同，同时本节仅体现 BootLoader 机制下的模式切换。应用程序与 BootLoader 程序在实现编程会话模式有所不同，应用程序在接 收到编程诊断会话请求后会执行复位，因此应用程序不支持编程诊断会话模式。通常，进入编程会话模式需要从扩展会话模式切换，ECU 也不支持直接从编程会话模式切换到扩展会话模式。在应用程序运行时接收到“10 02”编程会话模式请求后，ECU 将重编程请求标识符置为有效，并复位。ECU 复位后，启动时序见“MCU 启动时序”小节的描述。在 BootLoader 模式下，ECU 首先检查重编程请求标识符，如果有效，则不 会进行跳转判断，ECU 会一直运行 BootLoader 程序，并直接切换到编程会话模式。在编程会话模式下，由客户端进行安全认证解锁后即可进行软件升级流程。在 BootLoader 模式下，如果没有重编程请求，并且应用程序无效的情况 下，ECU 仍会一直运行 BootLoader 程序。此时，当 ECU 接收到重编程请求后， BootLoader 程序会进行模式切换，并根据客户端的命令进行软件升级。BootLoader 程序的主要功能是软件升级，因此其一般要求主要围绕电控单 元软件刷写的安全性与稳定性展开，这些细则可作为 BootLoader 软件开发的基本要求。然而，不同车辆制造商的软件刷写要求并不相同，希望读者在理解这些要求的基础上举一反三。电控单元基于 UDS 通信进行软件刷写时，诊断通信报文的数据域长度一般 固定为 8B。无效的字节以车辆制造商要求的字符填充，如填充 0x55 或 0xAA，以减少 CAN 通信时的位填充。电控单元应遵守车辆制造商定义的网络层定时参数和诊断会话层的定时要 求进行网络层的配置。为提高软件刷写过程的数据传输效率，减少通信过程中客户端和服务器的 请求和应答交互频次，电控单元的 BootLoader 程序流控参数的设置对性能的要求比较高见表 1。表 1 电控单元的 BootLoader 程序流控参数设置电控单元在软件刷新过程中需要校验刷写软件的合法性和刷写条件的安全 性，以确保电控单元在安全的条件下进行有效的升级。 电控单元需要支持安全访问，软件编程功能需要在安全访问通过后才能激 活，以确保软件刷写得到授权。 电控单元在软件升级的过程中若遇到电源供电异常和 CAN 通信异常等情况 仍需保持软件升级能力。电控单元应确保在合法授权的前提下更新软件。在更新了软件后，电控单 元仍具备再升级的能力。电控单元应对软件有效性进行校验，在数据校验或其他检查项目未通过时，不运行应用软件，以防止意外情况发生。电控单元在进行软件升级时，应通过软件数据下载服务将闪存（Flash）驱 动下载到随机存储器（RAM），以避免电控单元中的闪存驱动意外触发。ISO 15765-3 标准介绍了 ECU 重编程相关的知识。基于 UDS 的 ECU 重编 程流程一般分为 Pre-Programming 、Programming 、Post-Programming 三个阶段。除此三个阶段外，在 ECU 重编程过程中，测试仪（Tester）将以固定时间间隔通过功能寻址发送诊断仪在线的请求（并且设置抑制积极响应指示位为“ 1”）， 使网络上所有 ECU 保持会话模式直至重编程结束。Pre-Programming 阶段是 ECU 进行重编程的准备。该阶段的主要目的是提 高重编程阶段网络通信的稳定性，避免重编程阶段 ECU 报告非预期的故障和读取车辆数据供重编程前校验等。图 4 所示为 Pre-Programming 阶段的 UDS 命令流。其中：1 ）测试仪通过功能寻址方式发送诊断会话控制请求，请求网络上的所有 ECU 进入扩展会话模式。该命令为后面其他功能寻址请求做准备。2 ）测试仪通过物理寻址方式发送通过标识符读数据的请求，读取 ECU 的 特定数据，这些数据可以是版本号等数据，也可以是其他车辆信息。测试仪可以通过读取到的数据进行重编程前的校验。3 ）测试仪通过物理寻址方式发送例程控制请求，请求 ECU 进行重编程条 件检查。重编程的条件通常由零部件制造商和车辆制造商共同确定。 4 ）测试仪通过功能寻址方式发送控制 DTC 设置请求，请求网络上所有 ECU 关闭 DTC 设置。该步骤的目的是防止由 ECU 在重编程时的记录导致的故障。5 ）测试仪通过功能寻址方式发送通信控制请求，请求网络上所有 ECU 关 闭非诊断报文的通信，这使得在 ECU 重编程期间，网络上仅有测试仪和 ECU 之间的诊断通信，以保证重编程过程中通信的稳定性。Programming 阶段用于下载应用数据。应用数据一般是应用程序、闪存驱 动程序或标定数据。Programming 阶段均为测试仪和目标 ECU 之间的通信，因此所有命令都使 用物理寻址方式。图 5 所示为 Programming 阶段的流程，该流程仅下载闪存 驱动和应用程序数据，其中：1 ）测试仪发送进入编程会话模式的请求，如果 ECU 处于应用程序模式， 则会设置外部编程请求标识，然后复位 ECU ，ECU 将重启进入 BootLoader 模式运行；如果 ECU 处于 BootLoader 模式，则直接切换到编程会话模式。2）测试仪发送安全访问请求，ECU 将解锁 BootLoader 安全级别。3 ）测试仪发送通过 DID 写数据的请求，向ECU 写入指纹标识以及日期等 信息。4）测试仪通过发送请求下载、传输数据、请求退出传输的请求，将 ECU 的闪存驱动程序下载到 RAM 区域执行。ECU 下载数据时，将循环使用传输数据请求将所有数据下载到 ECU。5）闪存驱动程序下载完毕后，测试仪发送例程控制请求，校验闪存驱动的 完整性。6）开始下载应用程序之前，测试仪先发送擦除内存的例程控制请求， BootLoader 程序将根据请求的范围进行内存擦除。7）与下载闪存驱动程序一样，测试仪通过发送请求下载、传输数据、请求 退出传输等命令来下载应用程序。8）应用程序下载完毕后，测试仪发送例程控制请求，请求校验应用程序完 整性。9）下载应用程序的最后一个步骤是检查编程依赖性，测试仪发送检查编程依赖性的例程控制请求，BootLoader 程序执行编程依赖性检查，检查通过后，程序将会设置相关标识符。该标识符也是 BootLoader 跳转的关键条件之一。10）应用程序下载步骤完成后，测试仪发送 ECU 复位的请求。ECU 将复 位重启。Programming 阶段中，任何一个步骤失败都将终止程序的下载。Post-Programming 阶段主要用于 ECU 软件重编程成功后总线网络的同步设 置，因为在 Pre-Programming 阶段，测试仪将网络状态设置为关闭状态。图 6 所示为 Post-Programming 流程，其中：1 ）测试仪通过功能寻址方式发送进入扩展诊断会话模式请求，总线上所有
ECU 都切换到扩展诊断会话模式。
2 ）测试仪通过功能寻址方式发送开启非诊断报文通信的请求，使在 Pre- Programming 阶段关闭的非诊断报文通信恢复通信。3 ）测试仪通过功能寻址方式发送开启 DTC 设置的请求，使在Pre-Program- ming 阶段关闭的 DTC 设置为开启。4 ）测试仪通过功能寻址方式发送进入默认会话模式的请求，使网络上所有 ECU 恢复到默认会话模式。本书前面章节已经介绍了 UDS 软件架构，基于 UDS 的 BootLoader 软件也 是以此为基础实现的，不同的是 BootLoader 软件实现了闪存重编程流程和应用程序跳转功能。本节重点介绍基于 S32K144 芯片的 BootLoader 设计要点。与通用 UDS 软件架构相同，BootLoader 软件亦需要支持软件运行的最小系统、CAN 总线通信和诊断协议栈（ ISO 15765/ISO 14229），及闪存驱动 程序。重编程主要由诊断层的 0x31 、0x34 、0x36 、0x37 等服务完成，重编程步骤可参考介绍 BootLoader 流程章节的描述。BootLoader 程序还应保证其任务调度器在所有跳转条件都满足的情况下运 行一段时间，通常设置为 10ms 左右，以保证软件升级的安全性。内存分配包含闪存分配和 RAM 分配，需要给 BootLoader 和应用程序分配 合适的存储空间以供其运行。MCU 启动用户程序时通常首先跳转到复位向量所在的位置，复位向量存储 了用户程序的启动地址。因此，为保证 MCU 启动时总是首先执行 BootLoader 程序，需要将 BootLoader 程序分配到复位向量所在的区域。图7 所示为 S32K144 芯片的 P-Flash 内存分配，S32K144 共有 512KB 大 小的 P-Flash 供存储代码。其中，BootLoader 程序内存分配空间从 0x00000000 开始，分配大小为 80KB ；应用程序的内存分配空间从 0x00014000 开始，分配大小为 432KB。图 8 和图 9 所示为 BootLoader 程序和应用软件的内存分配细节，这些设置通过软件代码中的链接文件实现。BootLoader 不需要永久占用 RAM 区域，在 BootLoader 程序执行完毕跳转 到应用程序后，RAM 区域可被应用程序使用。此时 BootLoader 程序和应用程序共享芯片的 RAM 内存。程序从 BootLoader 跳转到应用程序后，中断向量表需要重新映射，以保证 系统能正确响应应用程序设置的中断，可参考图 8 和图 9 中的 m_interrupts 段分配。ECU 重编程时通常要求 ECU 的闪存驱动从测试仪下载到芯片的 RAM 区域，闪存驱动提供基本的闪存擦除和编程功能。在 BootLoader 程序中需要在 RAM 区域分配一块内存供闪存驱动临时存储，可参考图 8 中的 m_flash_api 段分配。根据内存分配，BootLoader 的起始地址为 0x00000000，应用程序的起始地 址为 0x00014200。根据 S32K144 的启动机制，在运行用户程序时，MCU 从地址0x00000000 处获取栈顶地址，并从地址 0x00000004 处获取 BootLoader 程序的启动地址。在程序跳转时，BootLoader 软件从地址 0x00014204 处获取应用程序的启动地址，并跳转到启动地址执行，由此就完成了 BootLoader 向应用程序跳转。 OTA，是 Over the Air 即空中下载技术的简称，也可称为远程升级技术。在 通信和互联网领域，远程升级技术早已成熟，如日常移动终端的应用软件升级等都使用这种技术。汽车远程升级技术是随着车联网的发展而出现的，目前已有部分车辆制造商实现了这一技术。OTA 技术分为两类，一类是固件在线升级（Firmware Over the Air，FOTA ）， 一类是软件在线升级（ Software Over the Air，SOTA ）。FOTA 是针对发动机、变速器、电机及底盘等电控单元的固件升级。SOTA 是基于操作系统，更新应用程序、UI 界面、车载地图以及影音娱乐应用等。当前，OTA 架构通常由三部分组成：OTA 云端、OTA 终端、OTA 升级。OTA 云端为车辆制造商的云端服务器，OTA 终端一般在车载 Tbox。读者可以借助相关资料了解 OTA 云端到 OTA 终端的升级过程，本节着重介绍电控单元的 OTA 技术。与电控单元相关的 OTA 过程主要是车内总线网络中的代码 BootLoader 升 级技术和代码回滚。BootLoader 在 OTA 上的实现仍然基于前面章节介绍的软件升级流程。不过 部分 OTA 过程要求电控单元能静默升级，即 OTA 过程不影响电控单元的应用软件功能，这要求电控单元能在应用程序执行时保持升级能力。OTA 时将电控单元分为两类，一类电控单元不需要代码备份，适用于功能单一的低成本执行器，另一类需要电控单元支持代码备份。支持代码备份的电控单元需要更大的存储空间同时存储两份软件，这种代码回滚方式通常被称为 A/B 交换。A/B 交换方案的实现有多种方式，最高效的方式是基于硬件地址重映射的 A/B 交换方案，如图 10 所示。图 10 a 中 ECU 激活的应用软件版本为 V1.0，通过 BootLoader 重编程后 将新的应用软件下载到另一个分区，软件版本为 V2.0。图 10 b 中当 ECU 复位或重新上电运行后，A/B 交换生效，激活 V2.0 版的应用软件。在 S32K1 × 系列中，S32K146 可以实现 A/B 分区方案，其有 1MB 的程序存储空间，有两个各 512KB 的读取分区。双 P-Flash 读取分区允许擦除及写入其中一个分区，同时读取另一个分区或从那里执行代码，从而实现软件静默升级。
