车联网OTA最怕断电与回滚失序

远程升级失败并不可怕，真正危险的是升级中断后设备不知道该信任哪个版本。车联网 OTA 如果没有把断电恢复和回滚标志做成原子流程，车辆会在半升级状态里反复重启。

断电风险来自车辆工况本身。升级可能发生在停车、充电、低压电瓶边缘或用户临时上车启动车辆时，车端电源并不总能稳定覆盖整个写入窗口。差分包下载完成只代表文件到达，解包、校验、刷写、激活和首次启动仍然各有失败点。若更新流程在写入元数据前后没有事务边界，断电可能让旧版本被标记为无效，新版本又没有写完整，T-Box 或域控就会失去可启动路径。

A/B 分区能降低风险，但前提是状态机清晰。新版本应先写入备用区，完整校验后只把启动指针切到试运行；应用启动后，还要在通信、关键外设和业务自检都通过时才提交成功。车联网设备如果一启动新版本就立即提交，后续看门狗复位或网络栈异常时，回滚通道已经被自己关闭。试运行次数、失败原因和上一次稳定版本都要持久化保存。

回滚标志最怕顺序错误。若先删除旧版本再写新版本，节省了空间，却牺牲了恢复能力；若先写成功标志再做业务自检，会把半可用版本永久化。更稳妥的顺序是：下载校验、写备用区、标记试运行、启动新版本、业务确认、提交成功。任何一步失败，都应能回到旧版本或继续等待人工处理，而不是反复尝试同一个坏镜像。

依赖版本也要纳入回滚。车端软件常由主控、T-Box、网关、地图、模型和配置共同组成，只回滚一个组件可能造成接口不匹配。升级前应声明依赖矩阵，平台分批下发时要保证车辆不会长期停在不兼容组合。若某个 ECU 成功、另一个 ECU 失败，系统要知道是整体回滚、局部冻结，还是进入降级模式。

升级窗口不能只按云端计划。车端应检查电瓶电压、车辆状态、网络质量、预计写入时长和用户使用场景；平台则要做灰度、限速和失败率熔断。若同一车型大规模同时升级，服务器、蜂窝网络和售后响应都会被放大。分批策略要能按地区、批次、硬件版本和失败特征暂停，而不是只按数量比例推进。

升级包本身也要可验证。差分包应绑定源版本、目标版本和硬件配置，不能让不匹配车辆勉强套用；下载完成后要先做完整性和签名校验，再进入刷写阶段。若校验失败，车端应保留旧版本和失败原因，等待平台重新下发，而不是反复消耗写入寿命。

升级任务还要防止平台重放。车辆恢复网络后，可能收到之前已经失败或已回滚的旧任务，如果任务号、版本条件和有效期不严谨，车端会再次进入同一坏路径。平台应把任务状态和车辆当前版本双向校验，车端也要拒绝低版本、过期任务和不满足前置条件的指令。

验证 OTA 时，应在下载、解包、写分区、切换启动、首次启动和提交成功各阶段注入断电，并检查最终状态。还要模拟旧包重放、依赖版本缺失和网络恢复后重复指令，确认车端不会被平台旧任务拉回错误状态。

所以，OTA 可靠性不在于升级一次成功，而在于失败后仍能解释当前版本。把断电窗口和回滚顺序做成事务，远程升级才敢规模化。