物联网设备 OTA 怎么做分批升级：任务状态、包校验和回滚

设备接入平台后，固件升级迟早会遇到。早期设备少，直接点一个“全部升级”看起来很省事；设备一多，这个按钮就有点危险。

最常见的问题不是升级功能写不出来，而是出了问题以后不知道停在哪一步：设备有没有收到任务、包有没有下载完整、校验是否通过、升级失败后还能不能回到旧版本。

在星野云联这类多门店设备接入场景里，OTA 通常不能按“全量一把推”来做。门店设备分布广，网络质量不一致，有些设备还承担现场控制功能，升级过程需要更保守。

1. 升级包先做版本档案

升级任务不要直接绑定一个下载地址。建议先把固件包登记成独立版本：

{
"firmware_id": "fw_gw_1.8.3",
"device_model": "edge_gw_v2",
"version": "1.8.3",
"sha256": "a71c9d8e…",
"size": 24813210,
"min_version": "1.6.0",
"created_at": "2026-09-28T10:00:00+08:00"
}

这里最容易漏的是 sha256 和 min_version。前者用于校验下载包是否完整，后者用于限制过老版本直接升级，避免跨版本太大导致兼容问题。

2. 升级任务要按批次推进

设备数量多时，可以把任务拆成几批：

batch_01 5 台试点设备
batch_02 同一地区 20 台设备
batch_03 剩余设备按门店分组

每一批都要有独立状态：

pending 等待下发
dispatched 已下发
downloading 设备下载中
verified 包校验通过
installing 安装中
rebooting 重启中
reported 上报新版本
failed 失败
rolled_back 已回滚

状态拆细以后，失败原因会清楚很多。downloading 卡住，优先查网络和下载地址；verified 前失败，多半是包损坏或存储不足；reported 没回来，可能是设备升级后没有正常重连。

3. 设备侧要先校验再安装

设备收到任务后，不应该马上覆盖当前固件。更稳妥的流程是：

下载升级包
↓
校验 sha256
↓
写入备用分区
↓
切换启动标记
↓
重启并上报版本

如果设备支持 A/B 分区，可以把新固件写入备用分区。启动成功并上报健康状态后，再确认新版本生效。这样升级失败时，设备还有机会从旧分区启动。

设备资源有限时，至少也要保留当前版本号、目标版本号和升级任务号：

{
"task_id": "ota_20260928_003",
"current_version": "1.8.2",
"target_version": "1.8.3",
"step": "verified",
"error_code": null
}

这条回执很重要。平台不能只知道“任务发出去了”，还要知道设备现在走到哪一步。

4. 回滚不是再发一次旧包

回滚最好在设计升级流程时就考虑，而不是失败后临时补救。

一种常见做法是设置启动确认窗口：

设备安装新版本并重启
↓
平台等待健康上报
↓
5 分钟内未确认
↓
设备自动回到旧版本

健康上报可以包含：

{
"device_id": "gw_10023",
"firmware_version": "1.8.3",
"boot_ok": true,
"network_ok": true,
"service_ok": true
}

如果新版本启动后无法联网，平台没有机会再发回滚命令，所以设备本地必须有自动回退逻辑。很多 OTA 事故都是因为只设计了升级，没有设计“升级后平台联系不上设备”的情况。

5. 失败率超过阈值就停止后续批次

分批升级的意义，是让问题先暴露在小范围内。可以给任务设置停止条件：

单批失败率 >= 10%
同一错误码连续出现 >= 3 次
设备离线数量超过预期
关键门店设备未恢复在线

满足条件后，平台应停止后续批次，把任务状态改成 paused。不要在失败原因还没看清时继续扩大范围。

任务表可以这样设计：

ota_task
task_id
firmware_id
batch_no
device_count
success_count
failed_count
paused_reason
status

设备维度再单独保存明细：

ota_task_device
task_id
device_id
from_version
target_version
step
error_code
updated_at

这样平台既能看总体进度，也能查某台设备的具体失败点。

6. 下载地址要有有效期

固件包下载地址不要长期公开。可以使用带有效期的 URL，设备拿到任务后在规定时间内下载。

{
"download_url": "https://example.com/fw/1.8.3?token=…",
"expires_at": "2026-09-28T11:00:00+08:00"
}

设备如果超过时间才开始下载，应重新请求任务，而不是继续访问旧地址。这样能减少旧包被长期暴露的风险。

7. OTA 上线前检查清单

• 固件包是否有版本号、大小和校验值；
• 目标设备是否按型号、版本、门店或区域分组；
• 设备是否能上报下载、校验、安装、重启等状态；
• 新版本启动失败时，设备是否能自动回到旧版本；
• 单批失败率超过阈值后，任务是否会暂停；
• 重复下发同一任务时，设备是否会重复升级。

OTA 不是一个“上传文件然后推送”的功能。真正难的是把升级过程拆成可观察、可暂停、可恢复的状态。只要设备还在现场跑，就要默认网络会断、包会坏、设备会重启失败，然后把这些情况写进任务模型里。

参考标签：物联网、OTA、固件升级、灰度发布、设备运维、回滚