1. 课程导入与工程目标

在汽车电子领域，OTA（Over-The-Air）升级已经从“锦上添花”变成了整车生命周期管理的基础能力。对于采用英飞凌AURIX系列多核安全微控制器的ECU而言，OTA不只是把新固件写进Flash那么简单：它涉及PFlash与DFlash的擦写特性、HSM（Hardware Security Module）的签名校验、多核启动流程、以及最关键的——当新固件启动失败或运行异常时，如何可靠地回滚到旧版本。本课程围绕“双分区OTA与回滚”这一工程主线，从需求分析、分区设计、Bootloader实现、HSM验签、A/B切换、回滚触发到量产约束，逐步展开。

为什么AURIX需要双分区OTA

AURIX TC3xx系列通常将程序存放在PFlash中，PFlash按Bank和Sector组织，擦除粒度大、写入次数有限。如果采用单分区原地升级，一旦升级过程中断电或新固件校验失败，ECU将失去可启动的应用程序，这在功能安全场景下是不可接受的。双分区（A/B分区）的核心思想是：Flash中同时保留两份可独立启动的应用程序镜像，当前运行的分区称为Active，待升级的分区称为Passive。升级时只擦写Passive分区，校验通过后通过启动标志切换，使新分区成为Active。若新分区启动失败或看门狗复位次数超限，Bootloader自动切回旧分区，实现回滚。

这种设计带来的直接收益是：升级过程不影响当前运行；回滚不依赖外部工具；配合HSM可实现端到端的安全启动链。代价是Flash空间翻倍、分区管理逻辑复杂、启动标志与元数据需要掉电安全存储。

典型需求与安全等级

在量产项目中，双分区OTA的需求通常来自整车厂的功能规范，可归纳为以下几类：

• 升级可靠性：任何时刻断电，ECU必须能启动到某个已知良好的版本。
• 回滚能力：新版本连续启动失败N次（示例：3次）后自动回滚，回滚时间不超过一个点火周期。
• 安全启动：每个镜像必须经过HSM的CMAC或ECDSA验签，未通过验签的镜像不得跳转。
• 版本管理：元数据中记录版本号、CRC、签名、分区状态，支持诊断读取。
• 刷写时间：以CAN FD或以太网为例，典型应用镜像约1~2MB，要求在整车下线或售后场景下可接受的时间内完成。

安全等级方面，若ECU涉及ASIL-B及以上功能，双分区与回滚机制通常被纳入安全概念。ISO 26262要求对安全相关软件的更新进行验证，AUTOSAR AP/CP的UCM（Update and Configuration Management）模块也定义了更新状态机。AURIX的HSM可承担密钥存储与验签，使OTA流程满足SecOC与安全启动要求。

量产约束

从工程落地角度看，双分区OTA面临若干硬约束。第一是Flash容量：TC3xx不同型号PFlash从2MB到16MB不等，双分区意味着可用应用空间减半，分区边界必须与Sector对齐，避免擦除时误伤Bootloader或元数据区。第二是DFlash的EEPROM仿真：启动标志、回滚计数、版本信息需要频繁写入且掉电安全，通常放在DFlash并用冗余+CRC保护。第三是HSM固件与密钥：HSM自身也需要升级策略，密钥更新必须与镜像更新解耦。第四是产线刷写：下线时通常通过调试接口或Bootloader刷入初始A/B镜像，需要保证两个分区都有效。第五是诊断与法规：UDS 0x34/0x36/0x37服务、0x31例程控制、0x22读取版本，均需与双分区状态机配合。

整体学习路径

本课程按“需求→设计→实现→验证→量产”的顺序组织，共30章。前段建立双分区与回滚的概念模型，中段深入AURIX的Flash驱动、HSM验签、启动标志与状态机，后段覆盖UDS刷写流程、回滚触发条件、测试用例与产线约束。学习时建议始终围绕一个具体对象：一个可运行的A/B分区Bootloader工程，配合示波器观察复位、配合调试器观察分区切换、配合诊断仪观察版本变化。

下面用一张信号链与状态关系图概括本节的核心对象：从整车OTA请求到AURIX内部的分区切换与回滚判断，帮助你在进入后续章节前建立全局视图。