OTA升级要解决什么
OTA 指通过空中接口把新固件或配置下发到设备并完成写入与生效。它与普通软件升级的区别在于：设备散布在现场、往往无人值守、供电与网络都不受控。所以真正难的不是下载，而是保证设备在任意时刻只有两种状态——旧版本能跑，或者新版本能跑，绝不出现写到一半的半成品固件把设备锁死。整套策略都围绕这个目标展开：传输要能续传、写入要能校验、启动要能自检、出错要能回滚。
基本信息
| 典型对象 | 网关、DTU、PLC、传感器、车载与消费类模组 |
|---|---|
| 常见通道 | MQTT、HTTPS、CoAP 与 LwM2M、私有 TCP 长连接 |
| 固件形态 | 整包升级、差分即增量升级 |
| 设备侧约束 | Flash 分区布局、可用内存缓冲、断电风险、流量计费 |
| 回滚基础 | 双分区 A/B 或独立备份区，配合引导标志位 |
| 服务端要点 | 版本台账、分批灰度、失败聚合告警 |
典型使用场景
- 设备量大且分散，无法停机上门刷机，只能远程分批推送
- 蜂窝网络按流量计费，需要用差分包压缩下载体积
- 现场供电不稳定，必须支持断电续传与失败回滚
- 产品已出货，需要修复安全漏洞或补齐功能
- 按区域或批次灰度，先小范围验证再全量放开
- 需要留存版本台账，作为售后追溯与合规材料
一次升级的典型状态机
一次升级的典型状态机
设备上报当前版本并轮询任务 # 服务端据此判断是否要升级
下载固件到备用分区 # 不覆盖正在运行的那一份
校验哈希与签名 # 只接受可信来源的镜像
写入引导标志并重启 # 切换到新分区启动
启动自检：网络、外设、关键进程 # 自检不过就触发回滚
上报结果与版本号 # 服务端记录成功或失败
成功后提交新版本并释放旧分区 # 保留回滚能力到下一轮升级校验维度与失败动作
| 校验点 | 目的 | 失败时处理 |
|---|---|---|
| 哈希比对 | 确认下载内容完整无缺 | 重新下载，连续失败则放弃本轮 |
| 签名验证 | 确认固件来源可信，防伪固件 | 拒绝写入并上报安全事件 |
| 兼容性检查 | 防止固件与硬件版本不匹配 | 服务端改派对应硬件版本的包 |
| 空间检查 | 确认备用分区放得下 | 改用差分包或先释放旧分区 |
| 启动自检 | 确认新固件真的能工作 | 回滚旧分区并告警 |
差分升级的前提是设备当前版本与服务端基线版本完全一致。现场一旦混着多个历史版本，就要为每个基线各生成一份差分包，否则会出现同型号设备有的能升、有的升不了。库存版本混乱时，整包升级的运维成本往往反而更低。
停电与耗电是两个容易被忽略的约束。带电池的设备应要求升级前电量高于阈值，写入阶段禁止休眠；工业设备应安排在停机窗口内重启，避免升级重启与生产节拍冲突。
回滚能力必须在设备侧就绪，而不能依赖服务端。若设备只保留单分区，新固件启动失败后服务端没有任何命令能把它救回来，只能上门返修。量产固件应默认启用双分区或独立引导区。