嵌入式 OTA 升级入门：分区、版本、校验、回滚和灰度

一、什么是 OTA

OTA 是 Over-The-Air，通过网络远程升级设备软件。嵌入式设备一旦部署到现场，人工拆机升级成本很高，所以 OTA 是产品化必备能力。

OTA 可能升级：

• 应用程序。
• 配置。
• RootFS。
• Kernel。
• U-Boot。
• 全量固件。

升级范围越底层，风险越高。

二、OTA 的基本流程

检查版本 -> 下载包 -> 校验包 -> 安装 -> 切换版本 -> 重启/重载 -> 健康检查 -> 确认成功

每一步都要能失败并安全退出。

三、版本管理

设备要知道：

• 当前版本。
• 目标版本。
• 最低可升级版本。
• 硬件型号。
• 架构。
• 渠道。

升级包命名示例：

my_device-v1.2.3-arm64-prod.tar.gz

版本信息建议写入：

/etc/device_version
/opt/my_app/current/VERSION

四、校验

升级包必须校验。

常见校验：

• sha256。
• 签名。
• 包大小。
• 版本匹配。
• 硬件型号匹配。

sha256：

sha256sum update.tar.gz

只做 hash 只能防止传输损坏，不能防止包被篡改。正式产品应考虑签名验证。

五、A/B 分区

可靠 OTA 常用 A/B 分区。

slot A 当前运行
slot B 写入新系统

升级流程：

当前从 A 启动
下载并写入 B
设置下次从 B 启动
重启
B 启动成功后标记成功
失败则回滚 A

优点：

• 升级失败不破坏当前系统。
• 可以自动回滚。

缺点：

• 占用更多存储空间。
• 启动控制更复杂。

六、应用级升级

如果只升级应用，可以使用 releases 目录：

/opt/my_app/releases/1.2.2
/opt/my_app/releases/1.2.3
/opt/my_app/current -> /opt/my_app/releases/1.2.3

升级失败时切回旧版本：

ln -sfn /opt/my_app/releases/1.2.2 /opt/my_app/current
systemctl restart my_app

应用级 OTA 风险比系统级 OTA 低，适合作为第一阶段。

七、回滚

必须明确什么叫升级成功。

成功条件可以是：

• 进程启动成功。
• 健康检查通过。
• 能连接服务器。
• 关键外设正常。
• 运行超过指定时间。

如果失败：

记录失败原因 -> 切回旧版本 -> 重启服务或系统 -> 上报失败

不要只以“安装完成”作为成功标准。

八、灰度升级

灰度可以降低风险。

策略：

• 先升级内部设备。
• 再升级 1%。
• 再升级 10%。
• 观察日志和指标。
• 最后全量。

设备端要支持：

• 查询是否有升级。
• 上报当前版本。
• 上报升级结果。
• 上报失败原因。

九、断点和断电

OTA 最怕：

• 下载中断。
• 安装中断。
• 写 Flash 中断。
• 切换版本后无法启动。

设计原则：

• 下载到临时文件。
• 完整校验后再安装。
• 安装过程可重复执行。
• 切换动作尽量原子。
• 保留可启动旧版本。

十、总结

OTA 的关键不是“能下载并替换文件”，而是安全升级：

可校验、可恢复、可回滚、可观测、可灰度

入门可以先做应用级 OTA，成熟后再做 RootFS 或 A/B 系统升级。