4、更新包制作规范：学习如何构建适用于离线更新的固件包、模型包或应用包，包含版本号与校验信息

离线更新是Edge AI设备在无互联网或受限网络环境下的核心维护手段。无论是工业控制器、智能网关还是边缘推理盒子，更新包的规范性直接决定了现场升级的成败。一个结构混乱、缺乏校验或版本标识不清的更新包，轻则导致升级失败，重则可能使设备变砖或模型推理结果异常。本章将系统讲解固件包、模型包和应用包的构建方法，重点聚焦版本号语义、校验机制、包内目录结构以及签名验证流程，帮助学员建立一套可复用、可追溯、可回滚的离线更新包制作规范。

4.1 更新包的核心构成与设计原则

离线更新包并非简单地将二进制文件拷贝到U盘，而是一个包含元数据、负载内容、校验信息和回滚策略的完整交付物。一个规范的更新包应满足三个核心原则：可识别性（通过版本号明确知道包的内容和适用对象）、可验证性（设备端能够独立验证包的完整性和来源可信度）、可恢复性（升级失败时能够安全回退到原版本）。

从工程实践角度看，更新包通常采用以下目录结构：

edge_ai_update_v2.3.1/
├── manifest.json          # 元数据描述文件
├── payload/
│   ├── firmware.bin       # 固件镜像（若适用）
│   ├── model.tflite       # 模型文件（若适用）
│   └── app.asar           # 应用打包文件（若适用）
├── checksum.sha256        # 所有文件的SHA-256哈希列表
├── signature.der          # 对checksum文件的数字签名
└── rollback/
    └── previous_version/  # 升级前自动备份的旧版本文件

manifest.json 是整个更新包的“身份证”，它至少应包含以下字段：

4.2 版本号管理策略与设备端判断逻辑

版本号不仅是标识，更是设备端升级决策的重要依据。在离线场景下，设备无法查询云端版本列表，因此版本号必须携带足够的决策信息。除了语义化版本号本身，建议在manifest中增加 compatibility 字段，描述该版本与硬件、驱动、依赖库的兼容矩阵。

设备端升级判断流程通常如下：

1. 读取当前版本：从设备持久化存储中读取当前固件/模型/应用的版本号。
2. 解析更新包manifest：读取U盘或蓝牙接收到的更新包中的manifest.json。
3. 版本比较：按语义化规则比较目标版本与当前版本。若目标版本 ≤ 当前版本，拒绝升级并提示“无可用更新”。
4. 兼容性检查：验证 target_hw 是否与设备硬件ID匹配，验证 min_supported_version 是否满足。
5. 校验和验证：计算payload目录下所有文件的SHA-256哈希，与checksum.sha256逐项比对。
6. 签名验证：使用设备内置的公钥验证signature.der是否由可信私钥签发。
7. 执行升级：所有验证通过后，先备份当前版本到rollback目录，再写入新版本。

以下是一个典型的manifest.json示例：

{
  "package_name": "edge_ai_gateway",
  "version": "2.3.1",
  "target_hw": "rk3588",
  "min_supported_version": "2.0.0",
  "package_type": "combined",
  "build_date": "2025-06-18T10:30:00Z",
  "checksum_algorithm": "sha256",
  "compatibility": {
    "driver_version": ">=1.8.0",
    "npu_sdk_version": ">=6.4.0",
    "os_version": "ubuntu20.04"
  },
  "files": [
    {"path": "payload/firmware.bin", "size": 134217728},
    {"path": "payload/model.tflite", "size": 45875200},
    {"path": "payload/app.asar", "size": 20971520}
  ]
}

4.3 校验信息生成与验证机制

校验信息是更新包防篡改、防传输错误的第一道防线。推荐使用SHA-256算法生成哈希值，因为其碰撞概率极低且计算速度快，适合在嵌入式设备上运行。校验信息应覆盖payload目录下的所有文件，包括固件、模型和应用，确保任何一个字节的变化都能被检测到。

生成校验信息的标准流程如下：

# 在构建服务器上执行
cd edge_ai_update_v2.3.1
find payload -type f -exec sha256sum {} \; > checksum.sha256
# 输出示例：
# a3f5c8d9e1b2...  payload/firmware.bin
# 7c9e1d2f3a4b...  payload/model.tflite
# 5b8a6c7d9e0f...  payload/app.asar

设备端验证时，需要逐行读取checksum.sha256，对每个文件重新计算哈希并进行比对。若任一文件哈希不匹配，应立即终止升级流程，并提示用户重新获取更新包。这里需要注意，校验文件本身也可能被篡改，因此必须对checksum.sha256文件进行数字签名。

数字签名推荐使用RSA-2048或ECDSA P-256算法。构建服务器持有私钥，设备端预置公钥。签名流程为：先对checksum.sha256文件内容计算哈希，再用私钥对该哈希进行签名，生成signature.der文件。设备端验证时，用公钥解密签名得到原始哈希，与本地计算的checksum.sha256哈希比对，一致则说明校验文件未被篡改。

4.4 案例拆解：某工业视觉检测设备的离线模型更新

某汽车零部件工厂部署了20台基于RK3588的Edge AI视觉检测设备，用于检测焊接缺陷。由于工厂网络隔离，无法连接外网，所有模型更新必须通过U盘离线完成。初始部署时模型版本为v1.2.0，现需升级到v2.0.0，新模型增加了对微小裂纹的检测能力。

初始现象与目标：现场工程师发现部分微小裂纹漏检，算法团队在训练服务器上优化了模型结构，将输入分辨率从640×640提升到1280×1280，同时更换了特征提取骨干网络。新模型文件大小为45MB，旧模型为28MB。目标是在不影响产线节拍的前提下，安全完成20台设备的模型更新。

关键输入数据：

• 旧模型版本：v1.2.0，文件大小28MB，SHA-256: 7c9e1d2f3a4b...
• 新模型版本：v2.0.0，文件大小45MB，SHA-256: 8b2a4c6d8e0f...
• 设备端NPU SDK版本：6.4.0，满足新模型对SDK的最低要求
• 设备可用存储空间：剩余1.2GB，足够容纳新模型及备份

分析判断过程：由于主版本号从1.x跨越到2.x，意味着模型架构发生了不兼容变更。设备端升级逻辑会检查 min_supported_version，若设置为1.5.0，则当前v1.2.0无法直接升级，需要先升级到v1.5.0再升级到v2.0.0。为避免两次升级，算法团队决定将 min_supported_version 设置为1.2.0，但需在manifest中明确标注“升级后不可回退到v1.2.0以下版本”。

实际操作步骤：

1. 在构建服务器上生成新模型文件 model_v2.0.0.tflite，并计算SHA-256哈希。
2. 创建更新包目录结构，将模型放入 payload/ 目录。
3. 编写manifest.json，版本号设为2.0.0，min_supported_version 设为1.2.0，package_type 设为model。
4. 生成checksum.sha256，并使用RSA私钥签名生成signature.der。
5. 将整个更新包拷贝到U盘，插入第一台设备进行试点升级。
6. 设备端验证通过后，先备份旧模型到 rollback/ 目录，再写入新模型。
7. 运行推理自检程序，验证检测精度和推理延迟。实测单帧推理时间从35ms增加到52ms，但仍满足产线节拍要求（<100ms）。
8. 确认无误后，批量升级剩余19台设备。

结果对比与风险：升级后，微小裂纹召回率从82.3%提升到94.7%，但误检率从1.2%上升到2.8%。由于产线对误检容忍度较高（人工复检可处理），该指标可接受。风险方面，由于模型体积增大，U盘拷贝时间从5秒增加到12秒，但仍在可接受范围。另外，升级过程中有一台设备因U盘接触不良导致校验失败，设备端自动中止升级并保留旧版本，重新插拔U盘后升级成功。

复盘经验：本次升级暴露了一个问题——设备端在升级前未检查剩余存储空间是否足够容纳新模型和备份。虽然本次空间充足，但若未来模型继续增大，可能因空间不足导致升级失败。后续应在manifest中增加 required_storage 字段，设备端在升级前主动检查。

4.5 常见误区与总结复盘

在离线更新包制作过程中，以下误区需要特别注意：

总结而言，更新包制作规范的核心在于“三可”原则：可识别（版本号清晰、元数据完整）、可验证（哈希校验+数字签名双重保障）、可恢复（备份机制+回滚策略）。在实际操作中，建议建立更新包构建的CI/CD流水线，每次构建自动生成版本号、计算校验和、执行签名，并输出构建报告。同时，在设备端维护一个更新日志文件，记录每次升级的时间、版本号、校验结果和操作人员，便于事后审计和问题追踪。