3. 版本升级需求分析
版本升级不是“把新固件烧进去”这么简单。在嵌入式 Linux 项目中，一次升级往往牵动内核、根文件系统、驱动、应用、配置、分区布局乃至产线烧录流程。若需求分析不到位，升级后可能出现功能缺失、启动失败、性能退化或安全漏洞。因此，本节把升级需求拆成五个维度：功能、安全、性能、兼容性与风险，并给出可落地的评估方法。
一、五维需求模型与关系
五个维度并非孤立：功能需求决定要改什么，安全需求约束怎么改，性能需求限定改完后的边界，兼容性需求保证新旧环境可过渡，风险评估则决定升级策略与回滚方案。下图给出五维需求与升级决策之间的输入输出关系。
二、功能需求：明确“改什么、不改什么”
功能需求要回答三个问题：新增哪些能力、修复哪些缺陷、裁剪哪些冗余。建议用“功能项—优先级—验收方式”三列表格管理。例如新增 OTA 差分升级、修复看门狗误复位、裁剪调试串口日志。每项必须绑定可验证的验收命令或测试用例，避免“升级后感觉更快了”这类模糊描述。
# 功能验收示例：确认新版本已启用差分升级
root@target:~# cat /etc/os-release | grep VERSION
VERSION="2.3.0"
root@target:~# ota-client --query-capability
support_delta: true
support_rollback: true
max_payload: 64MB三、安全需求：升级链路必须可信
安全需求覆盖镜像签名、传输加密、权限最小化与防回滚。典型要求包括：固件包使用 RSA-2048 或 ECDSA 签名，升级前校验签名与哈希；传输使用 TLS 或带 HMAC 的私有协议；升级进程以独立低权限用户运行；禁止降级到已知漏洞版本。若设备部署在无人值守场景，还需考虑安全启动链与密钥存储（如 TPM、OTP 区）。
四、性能需求：给出可量化边界
性能需求常被忽略，却直接影响用户体验与设备寿命。建议至少定义：升级包大小上限、下载耗时上限、写入耗时上限、升级期间内存峰值、CPU 占用率、重启后首次启动时间。对于电池设备，还要评估升级功耗。下表给出一个可参考的性能指标清单。
| 指标项 | 目标值 | 测量方法 | 风险阈值 |
|---|---|---|---|
| 升级包大小 | ≤ 64 MB | ls -lh 查看包体 | > 100 MB 需重新裁剪 |
| 写入耗时 | ≤ 90 s | time ota-client apply | > 180 s 影响产线节拍 |
| 内存峰值 | ≤ 80 MB | free -m 或 /proc/meminfo | > 120 MB 可能 OOM |
| 首次启动时间 | ≤ 25 s | systemd-analyze | > 40 s 用户可感知 |
| CPU 占用 | ≤ 60% | top -b -n 1 | > 85% 影响业务 |
五、兼容性需求：新旧环境平滑过渡
兼容性分为硬件兼容、接口兼容、配置兼容与数据兼容。硬件兼容关注新内核是否仍支持旧板卡的 PHY、Flash、Wi-Fi 模组；接口兼容关注应用调用的库版本、ABI 与系统调用；配置兼容关注旧配置文件能否被新版本解析；数据兼容关注用户数据、数据库 schema 是否可迁移。建议在升级前用“兼容性矩阵”逐项确认，并对不兼容项给出迁移脚本或降级方案。
# 兼容性检查示例：确认旧配置可被新版本解析
root@target:~# /usr/bin/config-migrate --check /etc/app/old.conf
[OK] section [network] recognized
[WARN] key 'legacy_mode' deprecated, mapped to 'compat_mode'
[FAIL] key 'old_auth' removed, manual action required六、升级风险评估方法
风险评估建议采用“概率×影响”矩阵，并对每项风险给出缓解措施与回滚触发条件。常见风险包括：升级包损坏、断电导致写入中断、分区空间不足、签名校验失败、升级后业务不兼容、回滚失败。评估时不要只列风险，而要明确“谁在什么条件下触发回滚”。
最后，把五维需求汇总为一份可执行的升级需求规格说明，包含：功能清单、安全基线、性能指标、兼容性矩阵、风险登记表与回滚预案。只有这份基线通过评审，才进入方案设计与实现阶段。否则，后续任何“临时加需求”都会让升级变成不可控的冒险。