📚 课程目录第4章升级工程需求分析

4. 升级工程需求分析

在动手写一行 Bootloader 代码之前，需求分析决定了整个升级工程的边界与成败。很多团队在项目后期才发现“升级包太大放不下”“刷写时间超出产线节拍”“断电后设备变砖”，这些问题本质上都不是编码问题，而是需求阶段没有把功能、性能、安全、兼容性和量产维护五个维度梳理清楚。本节将围绕这五类需求，给出可落地的分析方法与量化指标。

一、五维需求的核心原理

CAN Bootloader 的升级工程需求可以看作一个约束系统：功能需求定义“能做什么”，性能需求定义“做得多快多稳”，安全需求定义“出错时如何不失控”，兼容性需求定义“能适配多少种硬件与协议”，量产维护需求定义“在工厂和售后如何高效执行”。五者相互牵制，例如提高安全等级会增加校验时间，压缩升级包体积会影响功能完整性，因此需求分析的目标是找到一组可验证、可权衡的指标集合。

二、功能需求：明确“升级链路”的每个环节

功能需求要回答升级流程中每一步由谁完成、用什么报文、产生什么状态。典型清单包括：

进入升级模式：通过诊断服务（如 0x10 0x02）或特定 CAN ID 触发，需定义超时与退出条件。
传输升级包：支持分包传输、序号管理、流控（如 ISO-TP 的 FC 帧）。
完整性校验：整包 CRC32 或哈希校验，失败时重传或终止。
写入与跳转：擦除、编程、校验、设置有效标志、跳转 APP。
回滚与恢复：升级失败时保留旧版本或进入安全模式。

功能需求必须写成可测试的条目，例如“在 500kbps 总线上，单次升级包 128KB，支持断点续传，连续 3 次重传失败后进入安全模式”，而不是“支持升级”。

三、性能需求：用数字约束刷写体验

性能需求直接影响产线节拍和售后效率。关键指标包括刷写总时间、有效吞吐率、CPU 占用、RAM 缓冲区大小、Flash 擦写次数。以 500kbps CAN 为例，理论最大有效载荷约 4000 字节/秒，但受 ISO-TP 流控和 Flash 编程时间限制，实际吞吐往往只有 1.5～2.5KB/s。若升级包 256KB，刷写时间可能超过 100 秒，这在产线上是不可接受的。

需求维度	典型指标	验证方式
刷写时间	≤ 60s（256KB @ 500kbps）	示波器/日志时间戳
RAM 占用	≤ 4KB 缓冲区	Map 文件分析
Flash 占用	Bootloader ≤ 32KB	编译后 size 输出
擦写寿命	≥ 1000 次	Flash 手册与实测

四、安全需求：让“刷坏”可控

安全需求不是可选项。Bootloader 一旦被错误刷写，设备可能无法启动。核心措施包括：

传输校验：每帧 CRC 或整包 CRC32，防止总线干扰导致数据错误。
签名验证：使用非对称签名（如 ECDSA）验证升级包来源，防止恶意固件。
防回滚：版本号单调递增，拒绝旧版本覆盖。
断电保护：升级标志与有效标志分开存储，写入完成后再置位。
看门狗：升级过程中喂狗，超时复位进入安全模式。

常见误区：只在 APP 中做 CRC 校验，而 Bootloader 不校验。一旦 APP 被破坏，Bootloader 仍会跳转，导致设备反复重启。正确做法是 Bootloader 在跳转前必须校验 APP 的有效标志和 CRC。

五、兼容性需求：一套 Bootloader 适配多版本

量产产品往往有多个硬件版本和多个 APP 版本。兼容性需求要明确：Bootloader 与 APP 的接口约定（如共享内存区、版本号存放地址）、CAN ID 分配、诊断服务子集、Flash 分区布局。建议在 Flash 中固定一个“升级信息区”，存放 Bootloader 版本、APP 版本、硬件版本、升级标志、CRC 等，双方通过该区域解耦。

/* 升级信息区结构示例 */
typedef struct {
    uint32_t magic;          // 0x5A5A5A5A
    uint16_t boot_version;   // Bootloader 版本
    uint16_t app_version;    // APP 版本
    uint16_t hw_version;     // 硬件版本
    uint8_t  upgrade_flag;   // 0=正常 1=请求升级
    uint8_t  valid_flag;     // 0=无效 1=有效
    uint32_t app_crc;        // APP 区 CRC32
    uint32_t reserved[4];
} UpgradeInfo_t;

六、量产维护需求：从产线到售后

量产维护需求关注“批量执行”和“可追溯”。产线需要支持一拖多烧录、自动校验、失败重试、烧录记录上传 MES。售后需要支持远程诊断、版本查询、差分升级（减少流量）。典型需求包括：

产线节拍：单台刷写 ≤ 45 秒，支持 8 工位并行。
版本追溯：每台设备记录 Bootloader 版本、APP 版本、烧录时间、操作员。
售后升级：支持 UDS 0x34/0x36/0x37 服务，兼容主流诊断仪。
维护模式：保留一个“强制升级”入口，防止 APP 无法启动时无法刷写。

七、案例与复盘：一次“刷写超时”的教训

某项目在样机阶段升级正常，但量产时发现单台刷写时间达到 120 秒，产线节拍无法满足。复盘发现：Bootloader 每收到一帧就立即擦写 Flash，而 Flash 扇区擦除耗时 20ms，导致大量等待。优化方案是先在 RAM 中缓存一个扇区数据，再一次性擦写，同时提高 ISO-TP 块大小。最终刷写时间降至 55 秒。这个案例说明：性能需求必须在设计初期量化，并在样机阶段用真实数据验证，而不是等到量产才暴露。

需求分析输出物建议包括：需求清单（含优先级）、验收指标表、接口约定文档、风险清单。每一条需求都要有对应的测试方法，否则无法闭环。

综上，CAN Bootloader 升级工程的需求分析不是一次性文档，而是贯穿设计、编码、测试、量产的主线。功能需求定义链路，性能需求约束体验，安全需求兜底风险，兼容性需求保证复用，量产维护需求决定落地效率。五者共同构成升级工程的基线，后续的架构设计与代码实现都应以此为准绳。