3. OTA升级基础：OTA定义、升级流程、差分升级与全量升级的对比
在低功耗物联网终端的全生命周期管理中，OTA（Over-The-Air，空中下载）升级已成为不可或缺的基础能力。它不仅是修复固件漏洞、发布新功能的核心手段，更是决定终端能否在无人值守环境下长期稳定运行的关键工程环节。与手机或PC不同，物联网终端往往受限于窄带通信（如NB-IoT、LoRa）、有限Flash存储、低算力MCU以及严苛的功耗预算，这使得OTA升级不能简单照搬互联网应用的“下载-替换”模式，而必须针对资源约束进行深度优化。本节将系统梳理OTA的定义与价值、标准升级流程，并重点剖析差分升级与全量升级在工程实践中的本质差异与选型逻辑。
3.1 OTA定义与核心价值
OTA升级是指通过无线通信方式，将固件镜像、配置文件或应用逻辑从云端服务器安全地传输到终端设备，并在设备本地完成校验、写入和激活的过程。其本质是远程可编程性的工程化实现。在低功耗物联网场景中，OTA的价值不仅体现在“不用跑现场”的便利性上，更在于它直接决定了产品的可维护边界和商业闭环能力。
从工程视角看，OTA系统需要解决四个核心问题：传输可靠性（窄带环境下如何保证数据完整）、存储效率（有限Flash如何容纳新旧版本）、执行安全性（升级失败如何自恢复）以及功耗控制（升级过程如何不触发电池过放）。这四个问题相互耦合，构成了低功耗OTA设计的核心矛盾。
3.2 标准OTA升级流程拆解
一个完整的OTA升级流程，无论采用何种策略，都遵循“准备→下发→执行→确认”的四阶段模型。但在低功耗终端上，每个阶段都有特殊的工程约束。
| 阶段 | 核心动作 | 低功耗终端关键考量 | 典型耗时/资源 |
|---|---|---|---|
| 1. 版本检测 | 终端定期或事件触发向云端查询新版本 | 心跳周期设计（如24h一次），避免频繁唤醒；携带当前版本号、硬件ID、区域码 | 1~3s，电流~20mA |
| 2. 升级包下载 | 按分片拉取固件数据，写入外部Flash缓存区 | 分片大小（如1KB~4KB）；窄带下需断点续传；校验每片CRC32 | 10KB包约2~5min（NB-IoT） |
| 3. 完整性校验 | 对完整包做SHA256/MD5校验，验签 | 校验过程CPU全速运行，注意功耗尖峰；需在低电量时中止 | 100KB约1~3s |
| 4. 版本激活 | 写入App分区，更新启动标志 | 差分升级需合并缓冲区；全量升级需擦除+写入；掉电保护机制 | 写入速度~50KB/s（SPI Flash） |
| 5. 回滚确认 | 重启后运行新版本，上报结果 | 看门狗超时回滚；新版本启动失败自动切回旧版 | 重启+自检约5~10s |
在工程实现中，断点续传是低功耗OTA的必备能力。由于NB-IoT、LoRa等窄带网络的不稳定性，一次下载过程可能中断多次。设计上通常将固件划分为固定大小的块（Chunk），每块独立校验，终端记录已完成的块位图（Bitmap），重启后从断点继续。同时，下载过程应支持低电量暂停——当电池电压低于阈值（如3.3V）时，暂停下载并保存进度，待充电后再恢复。
3.3 差分升级与全量升级的深度对比
差分升级（Delta OTA）与全量升级（Full OTA）的核心区别在于传输内容和终端处理逻辑。全量升级传输完整固件镜像，终端直接写入；差分升级仅传输新旧版本之间的差异数据，终端需要本地合并生成新固件。
3.3.1 差分升级的技术原理
差分升级的底层依赖二进制差分算法，如bsdiff、HDiffPatch或厂商自研算法。其核心思想是：在旧版本二进制文件和新版本二进制文件之间，找到最长公共子序列（LCS），提取出“新增块”“删除块”“修改块”的指令序列。生成的差分包通常只有原固件大小的10%~30%。
终端侧的执行流程为：
- 读取旧固件（当前运行版本）到内存或直接映射Flash地址；
- 解析差分包中的控制指令（COPY/ADD/INSERT）；
- 将旧数据块复制到合并缓冲区，插入新增数据块；
- 生成完整新固件，写入备用分区；
- 校验新固件完整性，切换启动标志。
这一过程对终端的RAM和Flash提出了额外要求。例如，一个256KB的固件，差分合并时可能需要额外的64KB RAM作为工作缓冲区，同时需要一块与固件大小相当的Flash区域（或双Bank结构）来存放合并后的新固件。对于资源极受限的MCU（如STM32L0系列，仅20KB RAM），这往往成为瓶颈。
3.3.2 全量升级的工程优势与代价
全量升级的逻辑简单直接：下载完整固件→校验→擦除目标分区→写入→重启。它不需要复杂的合并算法，对RAM要求低（只需流式写入），且不容易出现“合并后固件损坏”的中间状态。但其代价是传输时间和功耗显著增加。
以一个典型的NB-IoT终端为例：固件大小256KB，NB-IoT实际下行速率约15~25kbps。全量升级需要约2~3分钟持续接收；而差分升级若差异仅30KB，则只需15~20秒。在电池供电场景下，这意味着一颗CR2032纽扣电池（约220mAh）可能因一次全量升级消耗掉5%~8%的电量，而差分升级仅消耗1%~2%。
3.3.3 选型决策矩阵
| 评估维度 | 差分升级 | 全量升级 | 决策建议 |
|---|---|---|---|
| 传输数据量 | 小（10%~30%原包） | 大（100%原包） | 窄带/低功耗场景优先差分 |
| 终端RAM要求 | 高（需合并缓冲区） | 低（流式写入） | RAM<32KB时慎用差分 |
| 终端Flash要求 | 需双Bank或额外存储区 | 需双Bank或可擦写区 | Flash<512KB时评估差分可行性 |
| 升级功耗 | 低（传输短，但合并耗电） | 高（传输长） | 电池容量<500mAh时优先差分 |
| 实现复杂度 | 高（算法+容错） | 低（简单可靠） | 团队能力有限时从全量起步 |
| 升级失败风险 | 合并失败概率较高 | 传输中断概率较高 | 需配套回滚机制 |
3.4 实战案例：NB-IoT水表固件升级策略选型
背景与约束：某智能水表项目采用NB-IoT通信，主控为STM32L431（Cortex-M4，64KB RAM，256KB Flash），电池为ER18505（锂亚硫酰氯，容量约2400mAh，但最大脉冲电流仅50mA）。固件当前版本v1.2，需升级至v1.3，主要变更包括：新增漏水检测算法（增加约12KB代码）、修复Modbus寄存器映射错误（修改约3KB）、优化数据上报逻辑（重排约8KB函数）。
初始方案与问题：开发团队最初计划采用全量升级，因为实现简单。但实测发现：全量固件包为248KB，在NB-IoT实际速率约18kbps下，下载需约110秒。下载期间终端平均电流为35mA（射频发射+Flash写入），单次升级耗电约1.07mAh。虽然看似不大，但考虑到水表需在电池下工作6年（约2190天），若每年升级2次，仅OTA耗电就占电池总容量的0.18%，尚可接受。然而，更严重的问题是：下载期间若遇到基站信号波动，重传机制会导致功耗翻倍，且长时间高电流工作可能触发电池电压跌落，导致系统复位。
分析判断过程：团队随后评估差分升级。使用bsdiff算法生成差分包，v1.2→v1.3的差异数据仅28KB。下载时间缩短至约12秒，耗电约0.12mAh。但问题转移到终端侧：STM32L431的64KB RAM能否支撑差分合并？经分析，bsdiff合并需要约“旧固件大小×1.2”的RAM作为工作区，即约300KB，远超64KB。团队改用HDiffPatch的轻量级合并模式，将工作区压缩至约40KB，勉强可行。同时，Flash方面需预留一个128KB的合并缓冲区（使用外部SPI Flash W25Q128，容量16MB，不是瓶颈）。
实际操作步骤：
- 在云端生成差分包，并附加SHA256校验值和版本元数据；
- 终端在低功耗定时唤醒后，检测到新版本，进入升级模式；
- 分片下载差分包（每片2KB），写入外部SPI Flash缓存区，每片校验CRC16；
- 下载完成后，从外部Flash读取差分包，结合内部Flash中的旧固件，在RAM中执行合并，边合并边写入外部Flash的新固件暂存区；
- 合并完成后，校验新固件SHA256，然后擦除内部Flash的App分区，从外部Flash搬运新固件；
- 设置启动标志，软复位，Bootloader校验新固件有效性，运行新版本。
结果对比：差分升级方案将单次升级耗电从1.07mAh降至0.15mAh（含合并和搬运），降幅86%。升级时间从110秒缩短至约35秒（含合并和Flash搬运）。更重要的是，由于下载时间短，遇到信号中断的概率大幅降低，断点续传的压力也显著减小。
风险与代价：差分合并过程CPU全速运行约8秒，电流约12mA，虽低于电池最大脉冲电流，但仍需在固件中增加“升级前电压检测”逻辑——若电压低于3.4V则推迟升级。此外，差分算法对固件编译的确定性有要求：如果两次编译的二进制文件因时间戳、编译器版本差异导致大量无关字节变动，差分包会急剧膨胀。团队最终通过可重复构建（Reproducible Build）解决了这一问题。
3.5 常见误区与总结
误区一：认为差分升级一定优于全量升级。实际上，当固件变更频繁且差异较大时（如UI重构、协议栈更换），差分包可能接近全量包大小，此时差分算法带来的计算开销和复杂度就得不偿失。建议设定阈值：当差分包超过全量包的60%时，自动切换为全量升级。
误区二：忽略升级过程中的功耗尖峰。无论是差分合并还是Flash擦写，都会产生瞬时高电流。在电池供电的终端上，这可能导致电压跌落触发欠压复位。必须在升级流程中嵌入电压监测，并在低电量时中止升级。
误区三：没有设计回滚机制。OTA升级失败是常态而非异常。一个健壮的OTA系统必须包含三级回滚：Bootloader检测启动失败自动回滚、应用层看门狗超时回滚、云端指令强制回滚。缺少任何一级，都可能导致终端变砖。
误区四：忽视安全校验。低功耗终端同样面临OTA劫持风险。必须使用非对称签名（如ECDSA或RSA）验证升级包来源，而不仅仅是CRC校验。签名验证的算力开销在Cortex-M4上约需100~300ms，完全可接受。
总结而言，OTA升级策略的选择本质上是传输成本、终端资源、实现复杂度、可靠性四者的权衡。对于低功耗物联网终端，建议采用“默认差分、阈值切换全量、双通道回滚”的混合策略：在云端根据差分包大小自动决策，在终端实现两种模式的支持，并始终保留回滚能力。这既能最大化节省功耗和带宽，又能保证升级的鲁棒性。