SOTA方案--总体设计参考

方案概要：后台准备，启动切换，校验确认，失败回退。

应用、模型频繁迭代，系统和驱动有自己的发布节奏。对征程 6 等 Linux 车载平台，可以用 SOTA 单独管理应用更新。

一、总体框架

完整镜像统一交付程序、依赖库和模型，签名清单绑定镜像摘要、平台及数据兼容条件。各模块围绕同一个制品工作：

部署库保存“运行切换上下文”，Slave 根据实际证据判断“是否升级成功”。

启动读取器、Slave 及恢复依赖放在稳定管理域，避免候选应用启动失败时，恢复入口也随之失效。平台监管负责保障稳定 Slave 可恢复工作。

二、升级逻辑

1. 后台准备：Master 发布完整本地包，Slave 接管、验签并检查兼容性，将最终镜像部署到可用槽，当前业务继续运行。
2. 提交激活：部署库可靠保存目标、回退引用和启动计划，正常流程等待下一次合格的自然启动。
3. 启动校验：系统执行计划后，先核对实际镜像、平台基线和启动实例，再只读检查本次系统状态。
4. 确认结算：校验通过后完成必要确认，持久保存任务结果并上报；失败则先执行有界恢复，再结算。

这套流程中的“后台更新”指准备阶段与业务并行，版本在启动窗口切换。Slave 重启或普通休眠恢复，不自动构成激活窗口。

三、A/B 与版本状态

应用 A/B 是两个持久逻辑槽，可以用目录实现，与系统启动分区分别管理。A 运行时准备 B，B 确认后，下一次才考虑复用 A。

槽位是否可写，要检查实际挂载、待激活计划和回退引用。两个槽不承诺永久保留多个历史版本，也不能隔离整个文件系统故障。

容量按准备阶段的峰值预算，同时覆盖当前镜像、新镜像、下载及解封装中间态，并留出业务余量。只读挂载还应配合底层文件写保护。

版本状态同样分开记录：

• pending：后续启动的目标。
• current：本次实际运行的版本。
• confirmed：已经校验并持久确认的版本。

提交 B 的启动计划后，current 仍可能是 A。此时不能判定为成功，计划落盘只完成了中间一步。

四、升级流程边界

• 先发布，再引用：完整镜像持久发布后，才能提交启动计划；回执未知时查询原操作，避免重复切换。
• 回退目标可用：选择兼容的上一应用版本，或当前平台的基础应用来源 BASE。数据也须兼容，恢复有次数上限。
• 平台条件有效：FOTA 改变基线后重新检查兼容性；电源事件保存检查点；资源预算覆盖整个执行组。
• 确认依据明确：Normal 必须覆盖目标应用组，并来自本次实例。它表示约定的系统就绪状态，不代表全部功能正确。

落地前，先确认镜像格式、启动入口、平台状态含义和数据兼容范围，再验证正常切换、掉电中断与失败回退。平台条件尚未落实时，先用离线原型检查状态和恢复逻辑。

自动回退成功只代表恢复完成，原升级仍应记录失败，便于区分版本质量与恢复能力。

总结

本文为脱敏设计参考，不包含内部接口及量产、性能实测结论。