3. OTA系统架构设计

在整车OTA体系中，AURIX从来不是孤立存在的升级对象，而是被云端、T-Box/OTA Master、中央网关与自身Flash分区共同约束的一个“受控目标”。理解这套架构的关键，不是记住各节点的名字，而是看清一条升级指令从云端下发到AURIX内部生效，中间经过了哪些角色、每个角色承担什么职责、以及AURIX自身如何用状态机和分区策略保证“升级失败也不变砖”。

一、四层角色的职责边界

典型的英飞凌AURIX OTA架构可以划分为四层：云端OTA平台、车端T-Box/OTA Master、中央网关、目标ECU（AURIX）。四者不是简单的转发链，而是各自持有不同的“决策权”。

• 云端OTA平台：负责固件包管理、版本策略、差分/全量包生成、签名与加密、车辆分组与灰度发布。它决定“谁该升、升到哪个版本”，但不直接接触ECU。
• T-Box/OTA Master：车端升级的总调度者。负责与云端建立安全通道、下载并校验固件包、缓存到本地存储、按车辆状态（车速、挡位、电量、点火状态）决定何时启动升级，并向网关下发升级任务。
• 中央网关：负责跨网段路由与诊断报文转发。它把OTA Master的升级请求转换为目标ECU可识别的UDS诊断服务（如0x34/0x36/0x37、0x31例程控制），并管理CAN/CAN-FD/以太网之间的带宽与优先级。
• AURIX目标ECU：升级的真正执行者。它接收诊断服务、写入非活动分区、校验镜像、切换启动分区、复位并上报结果。AURIX内部的安全机制（HSM、Flash分区、Bootloader）决定了升级能否安全落地。

这四层分工的核心原则是：云端管策略，OTA Master管调度，网关管通道，AURIX管落地。任何一层越权或缺失，都会导致升级不可控。

二、AURIX升级状态机

AURIX作为目标ECU，其升级过程必须由一个明确的状态机驱动，而不是靠“收到数据就写Flash”的裸逻辑。一个工程上可用的状态机通常包含以下状态：

• IDLE：正常运行，未收到升级请求。
• PRE_CHECK：收到升级请求后，检查车辆状态、电压、温度、当前版本是否允许升级。
• DOWNLOAD：通过UDS 0x36服务接收固件数据块，写入非活动分区（如PFlash Bank B）。
• VERIFY：对写入的镜像做CRC校验、签名验证（HSM参与）、版本比对。
• ACTIVATE：将启动指针切换到新分区，写入启动标志。
• REBOOT：复位MCU，Bootloader根据启动标志跳转到新分区。
• CONFIRM：新分区运行后，向OTA Master上报“升级成功”，状态回到IDLE。
• ROLLBACK：若VERIFY失败或新分区启动后未在超时时间内确认，Bootloader回退到旧分区。

状态机的关键约束是：DOWNLOAD和VERIFY阶段绝不允许破坏当前运行分区。AURIX的Flash通常分为多个Bank，例如TC3xx系列支持PFlash Bank A/B，配合HSM的Secure Flash机制，可以实现“写非活动区、验签后切换”的安全流程。

三、双分区与多分区策略

双分区（A/B分区）是最常见的策略：当前运行分区为A，升级时写入B；B校验通过后切换启动指针到B，A保留为回退镜像。这种策略的优点是实现简单、回退可靠；缺点是Flash利用率只有50%左右。

多分区策略则进一步细分，例如：

• Bootloader分区：独立且不可升级（或仅通过特殊安全流程升级），负责启动决策、回退和最小化通信。
• 应用分区A/B：双备份应用镜像。
• 标定/数据分区：存放标定参数、配置数据，升级时通常不切换，但需保证与应用版本兼容。
• HSM固件分区：安全核固件，升级需更高权限和独立签名。

多分区的核心价值在于解耦升级粒度：应用升级不必动Bootloader，标定更新不必动应用，HSM升级走独立通道。但代价是Flash布局复杂、启动逻辑更重、版本兼容矩阵更难维护。

四、升级数据流与分区切换关系

下面这张图展示了从云端到AURIX内部的分工与数据流，以及双分区切换的关键路径。图中左侧为车外云端，中间为车端调度与网关，右侧为AURIX内部Flash分区与状态机。

五、工程落地中的关键约束

在实际项目中，AURIX OTA能否成功，往往不取决于状态机画得多漂亮，而取决于几个硬约束是否被满足。

第一，Flash分区必须与链接脚本、启动代码严格对齐。Bank A和Bank B的起始地址、向量表偏移、HSM配置区必须提前规划，不能等到升级功能开发完再改。TC3xx的PFlash Bank切换通常通过Bootloader读取启动标志（如UCB中的启动模式配置）实现，标志写入必须原子化，避免掉电导致标志半写。

第二，HSM验签必须在写入完成后、切换前完成。典型流程是：OTA Master下发完整镜像后，AURIX调用HSM对镜像做ECDSA或RSA验签，同时计算CRC32。只有两者都通过，才允许写启动标志。验签失败时，非活动分区直接标记为无效，不触发切换。

第三，回退超时时间要合理。新分区启动后，应用需要在规定时间内（例如3秒）向OTA Master发送“升级成功”确认。若超时未确认，Bootloader在下次复位时自动回退。这个超时不能太短（否则正常启动被误判），也不能太长（否则车辆长时间处于不确定状态）。

第四，网关的带宽与优先级要预留。一个AURIX应用镜像通常在1~4MB，通过CAN-FD传输需要数分钟。网关必须为OTA诊断报文分配足够带宽，同时避免影响安全相关报文。以太网骨干车型可显著缩短下载时间，但AURIX端的Flash写入速度仍是瓶颈。

六、一个可参考的分区与状态参数示例

以下参数为教学示例，用于说明分区规划与状态机超时设计，并非某款量产车型的实测配置。

这套架构的本质，是把“升级”从一个单点动作，变成一条有明确责任边界、有状态约束、有回退路径的工程链路。云端、T-Box、网关、AURIX各司其职，而AURIX内部的状态机与分区策略，是整条链路最后也最关键的“安全落地”环节。