一、OTA升级概述

大家好，我是你们的讲师。今天咱们聊聊OTA升级。说实话，这个主题我讲了不下几十次，但每次都有新感悟。OTA，全称Over-the-Air，说白了就是「空中升级」。你想想看，一个设备部署在野外，或者装在用户家里，总不能派人挨个去刷固件吧？OTA就是解决这个问题的。

1.1 OTA的定义

OTA升级，指的是通过无线通信方式（比如Wi-Fi、蜂窝网络、蓝牙等），对嵌入式设备的固件、软件或配置进行远程更新。不需要物理连接，不需要拆机，甚至不需要用户干预。

我记得2018年做一个智能电表项目，设备分布在全省各地。那时候还没有成熟的OTA方案，每次升级都要派工程师去现场。一个工程师一天最多跑3个站点，全省2000多个站点...嗯，你算算要多久？后来我们自研了一套OTA系统，效率提升了上百倍。

1.2 OTA升级在物联网中的重要性

为什么说OTA重要？我给你列几个场景：

• 安全漏洞修复：设备上线后发现安全漏洞，OTA可以快速打补丁。我曾经遇到一个案例，某智能门锁被发现存在蓝牙协议漏洞，如果不及时修复，黑客可以远程开锁。OTA在48小时内完成了所有设备的固件更新。
• 功能迭代：产品上市后还能加新功能。比如智能音箱，通过OTA不断优化语音识别算法，用户感觉设备「越用越聪明」。
• 降低运维成本：不用派人去现场，省人工、省差旅、省时间。一个OTA平台可能花几十万开发，但一年能省下几百万的运维费用。
• 提升用户体验：用户不用操心升级的事，设备自动完成。我见过一些用户，你让他手动升级，他永远不升，结果设备一直有bug。

1.3 OTA升级的典型流程

OTA升级看起来简单，其实涉及好几个环节。我习惯把它分成五个步骤：

第一步：固件打包

把编译好的固件、配置文件、签名信息等打包成一个升级包。这里要注意：

• 压缩算法选什么？gzip、lzma还是zstd？压缩率越高，传输越快，但解压时占用的RAM也越多。
• 签名怎么加？我建议用RSA或ECDSA签名，防止固件被篡改。
• 版本号怎么管理？语义化版本号（比如v2.1.3）是最基本的，还要考虑兼容性标记。

# 一个典型的固件打包脚本示例
#!/bin/bash
# 打包固件并签名

FW_VERSION="2.1.3"
FW_FILE="firmware.bin"
SIGN_KEY="private_key.pem"

# 1. 编译固件
make clean && make

# 2. 计算哈希
sha256sum $FW_FILE > firmware.hash

# 3. 签名哈希
openssl dgst -sha256 -sign $SIGN_KEY -out firmware.sig firmware.hash

# 4. 打包成升级包
tar czf upgrade_${FW_VERSION}.tar.gz $FW_FILE firmware.hash firmware.sig

echo "升级包生成完成: upgrade_${FW_VERSION}.tar.gz"

第二步：分发

升级包上传到服务器，然后推送给设备。分发策略有很多种：

• 全量推送：所有设备同时升级。简单粗暴，但容易把服务器打爆。
• 灰度推送：先推1%的设备，观察没问题再逐步扩大。我强烈推荐这种方式。
• 按区域/型号推送：不同区域、不同硬件版本的设备，推送不同的固件。

第三步：下载

设备从服务器下载升级包。这里要考虑：

• 断点续传：下载过程中网络断了怎么办？支持断点续传是基本要求。
• 流量控制：如果是蜂窝网络，要考虑流量费用。我建议只在Wi-Fi环境下下载大包。
• 存储空间：设备Flash够不够放升级包？不够的话要边下载边解压。

第四步：校验

下载完成后，必须校验升级包的完整性和合法性：

1. 检查文件大小是否匹配
2. 计算哈希值，对比服务器下发的哈希
3. 验证数字签名，确保固件来自可信源
4. 检查版本号，不能降级（除非特殊场景）

// 设备端校验代码片段（C语言）
bool verify_firmware(const uint8_t *fw_data, uint32_t fw_size) {
    // 1. 计算SHA256
    uint8_t hash[32];
    sha256_calculate(fw_data, fw_size, hash);
    
    // 2. 验证签名
    if (!rsa_verify_signature(hash, sizeof(hash), 
                              received_signature, public_key)) {
        printf("签名验证失败！\n");
        return false;
    }
    
    // 3. 检查版本号
    if (get_fw_version(fw_data) <= current_version) {
        printf("版本号不满足升级条件\n");
        return false;
    }
    
    return true;
}

第五步：激活

校验通过后，设备开始应用新固件。激活方式有两种：

• 冷启动：设备重启，从新固件分区启动。简单可靠，但会有短暂停机。
• 热更新：不重启，直接替换运行中的代码。难度大，但用户体验好。

我个人更倾向于冷启动。为什么？因为热更新太容易出问题了。你想想看，替换一个正在运行的函数，指针、内存、中断...任何一个环节出错，设备就挂了。除非你的RTOS或MCU原生支持热更新，否则别轻易尝试。

小结

OTA升级不是简单的「发个文件过去」。它涉及打包、分发、下载、校验、激活五个环节，每个环节都有技术细节和坑。我在后面的章节会逐一深入讲解。

嗯，这一章就到这里。下一章我们聊聊「OTA升级的架构设计」，包括客户端、服务端、通信协议的选择。到时候我会分享一些实际项目中的架构选型经验。