4. 升级方案总体设计
在嵌入式 Linux 产品中，升级方案不是单一技术点，而是一组围绕“可交付、可回滚、可验证、可量产”的系统设计决策。总体设计阶段要回答五个问题：升级包传什么、写到哪、失败怎么办、如何验证、用什么框架承载。全量升级、增量升级、A/B 分区、双系统备份与 OTA 框架选型，正是这五个问题的核心答案。
一、核心原理：五种方案的定位与边界
全量升级把完整根文件系统或整包镜像写入目标分区，逻辑简单、校验直接，适合首次量产、大版本跨越或存储充裕的设备。增量升级只传输新旧版本差异，节省带宽与写入量，但依赖基线版本、差分算法和还原时的临时空间。A/B 分区通过两套可启动槽位实现“后台写入、切换生效、失败回退”，是当前 OTA 的主流形态。双系统备份更强调保留一套可恢复的出厂或稳定系统，常见于工业网关、医疗设备等对可用性要求极高的场景。OTA 框架选型则决定升级包格式、传输协议、签名校验、断点续传和状态机由谁实现。
二、方案对比：从五个维度做取舍
| 方案 | 传输/存储开销 | 回滚能力 | 实现复杂度 | 典型场景 |
|---|---|---|---|---|
| 全量升级 | 高，整包写入 | 弱，需额外备份 | 低 | 首次烧录、小批量维护 |
| 增量升级 | 低，仅传差异 | 中，依赖基线 | 中高 | 带宽受限、频繁小版本 |
| A/B 分区 | 中高，双槽存储 | 强，槽位切换 | 中高 | 消费类、车载、网关 OTA |
| 双系统备份 | 高，保留稳定系统 | 很强，可强制恢复 | 高 | 工业控制、医疗、电力 |
| OTA 框架 | 取决于框架 | 取决于后端策略 | 中 | 需要远程运维的量产设备 |
三、方法流程：从升级包到生效的完整链路
一个可落地的总体设计通常包含以下步骤：
- 版本建模：定义版本号、硬件兼容矩阵、基线版本和依赖关系。
- 包制作：生成全量包或差分包，附带 manifest、签名和校验值。
- 传输与下载：通过 HTTPS/MQTT/自定义协议下发，支持断点续传和限速。
- 校验与解包：校验签名、哈希、硬件型号和剩余空间。
- 写入与切换：写入备用槽或备份区，更新启动标志，重启生效。
- 健康检查与回滚：启动后上报状态，失败则切回原槽或恢复备份。
以 A/B 分区为例，启动参数中常见如下配置：
# 查看当前槽位
fw_printenv | grep -E "bootslot|upgrade_available|bootcount"
# 典型输出
bootslot=A
upgrade_available=0
bootcount=0
# 写入 B 槽后设置
fw_setenv bootslot B
fw_setenv upgrade_available 1
fw_setenv bootcount 0
若升级后连续启动失败，bootloader 可根据 bootcount 阈值自动回退到 A 槽。这种“写入不影响运行系统、切换才生效”的机制，是 A/B 分区最核心的价值。
四、场景案例：不同设备的选型差异
案例一：家用智能网关。存储为 128MB NAND，网络为 Wi-Fi，要求夜间静默升级。推荐 A/B 分区 + 全量包，配合后台下载和低优先级写入，保证用户无感。案例二：工业边缘控制器。现场不允许停机，且网络不稳定。推荐双系统备份 + 增量升级，保留出厂稳定系统，差分包减少传输时间。案例三：车载中控。必须满足功能安全和法规审计。推荐 A/B 分区 + 签名校验 + 灰度发布，升级失败自动回滚并上报云端。
五、OTA 框架选型：自研还是集成
常见选择包括 SWUpdate、RAUC、Mender、OSTree 以及厂商自研方案。选型时重点看：是否支持 A/B 与回滚、是否支持差分、签名与加密能力、与 Yocto/Buildroot 的集成度、后端服务是否开放、社区活跃度和许可证。若产品只需本地 U 盘升级，轻量脚本加校验即可；若要远程批量运维，建议采用成熟框架，避免重复实现状态机和断点续传。
六、误区与复盘
- 只做全量升级却未预留备份区：一旦写入中断，设备可能无法启动。
- 增量升级未校验基线：基线不匹配会导致还原失败或系统损坏。
- A/B 分区未同步 bootloader 环境：切换标志丢失会造成反复启动同一槽位。
- 忽略电源与存储寿命：频繁写入 eMMC 需考虑磨损均衡和掉电保护。
- OTA 框架选型只看功能不看维护：长期无人维护的框架会带来安全与兼容风险。
总体设计的最终产出应是一份可执行的升级规格：明确采用全量还是增量、是否启用 A/B、备份区大小、启动标志变量、回滚阈值、签名算法和上报字段。只有把这些决策前置，后续的 bootloader 改造、根文件系统制作、云端接口和产线烧录才能协同一致，升级方案才真正具备量产可用性。