4. OTA系统需求与方案选型

OTA（Over-The-Air）在车载与工业场景中并不是一个“把固件通过网络写进Flash”的简单动作，而是一套受安全、实时性、供电与回滚能力约束的系统工程。ST Stellar 系列 MCU 内部集成双银行（Dual-Bank）Flash，为“运行中升级、失败可回滚”提供了硬件基础。但在动手写 Bootloader 之前，必须先回答三个问题：场景到底需要什么？单银行和双银行差在哪里？双银行方案要满足哪些可量化的工程约束？本节围绕这三个问题展开，为后续的 Flash 分区、Boot 切换与刷写实现建立设计基线。

一、车载与工业OTA的场景需求拆解

车载与工业OTA的需求可以归纳为五类，它们直接决定方案选型：

• 可用性需求：升级期间车辆或设备是否允许停机。车载ECU通常要求“升级不中断关键功能”，工业控制器则可能允许计划性停机窗口。可用性要求越高，越倾向双银行。
• 回滚需求：新固件启动失败、校验失败或功能异常时，能否自动退回旧版本。这是双银行最核心的价值。
• 安全需求：固件需签名验签、防篡改、防降级（Anti-Rollback），传输需加密。安全校验必须在切换运行银行之前完成。
• 供电与掉电需求：升级过程可能持续数十秒到数分钟，期间掉电不能导致设备“变砖”。这要求写入与切换具备原子性或可恢复性。
• 带宽与时间需求：CAN/CAN-FD、以太网、UART 或无线链路的带宽差异巨大，决定传输策略与分块大小。

以某车载域控制器为例（示例假设）：固件镜像 1.5 MB，CAN-FD 有效载荷约 4 Mbps，理论传输约 3 秒，但加上擦除、写入、验签与切换，整体升级窗口约 20～40 秒。若此时车辆正在行驶，单银行方案必须停机，双银行方案则可让旧固件继续运行，新固件在后台银行写入，最后通过一次复位切换。

二、单银行与双银行方案对比

单银行方案只有一个可执行固件区，升级时必须先擦除当前固件再写入新固件，期间设备无法运行；一旦掉电或写入失败，设备将失去可执行代码，需要外部调试器或恢复模式介入。双银行方案则把 Flash 划分为 Bank A 与 Bank B，当前运行银行保持不动，新固件写入另一银行，写入并校验通过后再切换启动银行。

结论很明确：只要场景对“升级不中断”或“失败可回滚”有硬性要求，就应选择双银行。ST Stellar 的双银行 Flash 支持在 Bank A 运行时对 Bank B 进行擦写，并在复位后通过选项字节或启动地址映射切换执行银行，这正是双银行OTA的硬件前提。

三、双银行OTA的工程约束与设计指标

选定双银行后，必须把需求转化为可验证的工程约束。以下指标建议在项目初期就写入设计文档（数值为示例假设，需按实际芯片型号与链路确认）：

• 银行容量约束：单银行容量必须 ≥ 最大固件镜像 + 元数据。若 Stellar 单银行为 2 MB，固件镜像 1.5 MB，则剩余约 0.5 MB 用于 Boot 标志、版本号、签名与日志。
• 切换原子性：银行切换标志的写入必须是一次原子操作，且带 CRC 或双副本，避免标志位半写导致启动银行不确定。
• 校验完整性：新固件写入后必须完成整镜像 CRC32 与签名验签，两项均通过才允许置位切换标志。
• 回滚触发条件：新固件连续启动失败 N 次（示例 N=3）或看门狗超时，Boot 应自动切回旧银行并记录失败原因。
• 掉电恢复：任意时刻掉电，重新上电后 Boot 必须能判断“当前有效银行”，并继续或回退，不允许出现两个银行都不可用。
• 升级时间预算：从开始传输到切换完成的总时间应满足整车或产线节拍，示例目标 ≤ 60 秒。
• 安全指标：支持固件签名验签、防降级版本号比较、传输加密（如 TLS 或 SecOC）。

四、从需求到方案的判断路径

把上述分析串成一条可执行的判断路径，有助于在项目评审时快速达成一致。下图展示了从场景需求出发，经过可用性、回滚、供电与安全四道判断，最终落到单银行或双银行方案，并输出关键设计指标的关系。

图中把“可用性、回滚、供电与安全”作为三道判断闸门：只要其中任意一项为“是”，就应选择双银行；三项全为“否”时，才可评估单银行以节省 Flash 成本。选定双银行后，右侧的风险点提示了两个最容易出问题的环节——切换标志的原子性与回滚触发条件，它们必须在 Bootloader 设计阶段就明确。

五、设计指标落地示例

以下是一份可直接用于项目评审的双银行OTA设计指标表（示例假设，需按实际芯片与链路校准）：