4. 固件升级需求分析
在 DroneCAN 设备固件升级工程中，需求分析决定了后续 Bootloader 设计、传输协议选择、安全机制与测试策略。若跳过需求分析直接编码，常见后果是：现场升级失败无法回滚、远程升级被中间人篡改、新旧节点混用导致总线异常。本节从升级场景、远程与本地升级、安全要求、可靠性指标与兼容性约束五个维度展开，并给出可落地的需求清单。
一、升级场景：先分清“谁在什么条件下升级”
DroneCAN 设备的升级场景可按触发者、物理通道和运行状态三个维度划分。触发者可能是地面站操作员、飞控自动任务、产线工装或设备自身；物理通道可能是 CAN 总线、USB-CAN 适配器、串口转 CAN 网关或无线数传链路；运行状态则分为地面维护、上电初始化、飞行中禁止升级等。
典型场景包括：
- 产线批量烧录：设备未装配，通过 USB-CAN 适配器并行升级，要求速度快、可重复、失败可重试。
- 外场维护升级：整机已装配，通过地面站经 CAN 总线逐节点升级，要求不影响其他节点通信。
- 远程空中升级：通过数传链路对已起飞或待起飞设备升级，要求断点续传、校验和回滚。
- 应急修复升级：设备进入 Bootloader 后无法正常启动，要求最小依赖、固定波特率、固定节点 ID。
需求分析的第一步是把这些场景写成可验证的条目，例如“外场维护升级时，单节点升级时间不超过 90 秒，升级期间总线负载率不超过 60%”。
二、远程与本地升级：通道差异决定协议参数
本地升级通常指设备与升级工具处于同一物理总线或短距离连接，链路稳定、带宽高、延迟低。远程升级则经过无线数传、网关或互联网，链路存在丢包、抖动、带宽受限和中断风险。两者对 DroneCAN 升级协议的要求不同：本地可选用较大的传输块和较短的超时；远程必须支持分块重传、断点续传和会话恢复。
在 DroneCAN 中，固件升级通常基于 uavcan.protocol.file 或厂商自定义的 BeginFirmwareUpdate 服务，配合 file.Read 分块读取。远程升级时，建议将块大小从 256 字节降至 128 字节，并将确认超时从 500 ms 提高到 2000 ms，以适应数传链路的往返延迟。
通道参数建议：
本地 CAN 升级：
block_size = 256 bytes
ack_timeout = 500 ms
retry_count = 3
bitrate = 1 Mbps
远程数传升级：
block_size = 128 bytes
ack_timeout = 2000 ms
retry_count = 5
bitrate = 56~115 kbps
resume = enabled三、安全要求：完整性、真实性与防回滚
固件升级是攻击面最大的环节之一。需求分析必须明确三类安全目标：完整性（固件未被篡改）、真实性（固件来自可信发布者）、防回滚（不能降级到存在漏洞的旧版本）。在 DroneCAN 设备上，常用手段包括：
- CRC 校验：对每个传输块和整包做 CRC32，检测传输错误。
- 数字签名：使用 Ed25519 或 ECDSA 对固件摘要签名，Bootloader 内置公钥验证。
- 版本号单调递增：Bootloader 拒绝版本号低于当前版本的固件。
- 安全启动链：Bootloader 自身也需校验，防止被替换。
常见误区：只做 CRC 不做签名。CRC 只能发现随机错误，无法抵御恶意篡改。若设备通过无线链路升级，必须假设链路可被监听和注入，签名验证不可省略。
四、可靠性指标：用可量化目标约束设计
可靠性指标应覆盖升级成功率、失败恢复能力和对系统的影响。下表给出建议指标，可根据项目等级调整。
| 指标 | 本地升级目标 | 远程升级目标 | 验证方法 |
|---|---|---|---|
| 单节点升级成功率 | ≥ 99.9% | ≥ 99% | 批量重复升级 1000 次 |
| 断点续传支持 | 可选 | 必须 | 升级中拔线/断链后恢复 |
| 失败回滚时间 | ≤ 5 s | ≤ 10 s | 注入错误固件后观察 |
| 升级期间总线负载 | ≤ 60% | ≤ 40% | CAN 分析仪统计 |
| 掉电安全 | 任意时刻掉电可恢复 | 任意时刻掉电可恢复 | 随机掉电测试 |
其中“掉电安全”要求 Bootloader 采用双区或 A/B 分区设计：新固件先写入备份区，校验通过后再切换启动标志。若升级中断，设备仍从旧区启动，保证节点不会变砖。
五、兼容性约束：协议、硬件与版本矩阵
DroneCAN 设备种类多，升级需求必须考虑兼容性约束，否则会出现“新 Bootloader 不认旧固件”或“新固件无法在旧硬件运行”的问题。主要约束包括：
- 协议版本：Bootloader 与升级工具需支持相同的 DroneCAN 服务版本，必要时保留旧版服务入口。
- 节点 ID 与名称：升级期间节点可能使用固定 ID，需避免与总线其他节点冲突。
- 硬件版本：固件头部应包含硬件 ID，Bootloader 拒绝不匹配的固件。
- 存储布局：Flash 分区表、页大小和写入对齐要求需在需求中明确。
- 回滚兼容：旧固件需能识别新 Bootloader 的启动标志，避免升级后无法回退。
建议在需求阶段建立“设备—硬件版本—Bootloader 版本—固件版本”四维矩阵，并在 CI 中自动校验。例如：
设备型号: DroneCAN-ESC-4IN1
硬件版本: HW_REV_C
Bootloader: bl_v2.3+
固件版本: fw_v1.8.0
兼容规则: fw.major == bl.major 且 hw_id 匹配六、需求分析输出物与复盘要点
完成上述分析后，应输出一份可追踪的需求规格，至少包含：场景清单、通道参数表、安全机制列表、可靠性指标表、兼容性矩阵和验收测试用例。每个需求条目应有唯一编号，便于在设计、测试和评审中追溯。
复盘提示：若项目后期出现升级失败率偏高，优先回查需求阶段是否遗漏了“链路中断恢复”和“掉电安全”两项。多数现场问题并非代码缺陷，而是需求未定义清楚导致的边界缺失。
综上，DroneCAN 固件升级需求分析不是简单罗列功能，而是把场景、通道、安全、可靠性和兼容性转化为可量化、可验证、可追踪的工程约束。只有这些约束在需求阶段被明确，后续 Bootloader 设计、协议实现和现场升级才能稳定可控。