3. 迁移需求分析与可行性评估

快速控制原型（RCP）阶段的目标是“尽快验证控制策略是否有效”，而量产软件的目标是“在确定的硬件、确定的实时约束和确定的安全等级下，长期稳定地运行”。两者之间的差距，正是迁移需求分析要回答的问题。本节围绕三条主线展开：功能安全需求（ISO 26262）、实时性需求、资源约束需求，并给出迁移可行性评估报告的组织方法。

一、从原型功能需求到量产需求：转化的本质

原型阶段的需求通常以“功能能跑通”为验收标准，例如“电机转速跟随给定值，超调小于5%”。这类描述缺少安全等级、故障响应、执行周期、内存占用等量产必需属性。转化的本质，是把一条功能描述拆解为可验证的多维需求。

以“转速闭环控制”为例，原型需求是“转速跟随”。迁移到量产时，至少要拆成四类：

• 功能需求：目标转速范围 0～6000 r/min，稳态误差 ≤ ±20 r/min，阶跃响应超调 ≤ 5%。
• 安全需求：转速信号失效时进入安全状态，ASIL 等级由危害分析确定，例如误超速可能导致人员伤害，可定为 ASIL C。
• 实时需求：控制周期 1 ms，抖动 ≤ 50 μs，最坏执行时间（WCET）≤ 300 μs。
• 资源需求：RAM ≤ 8 KB，Flash ≤ 32 KB，CPU 占用率 ≤ 40%。

转化方法可以概括为“功能—危害—属性”三步：先明确功能边界与接口，再通过危害分析确定安全等级和故障响应，最后为每条需求绑定可测量的属性（周期、误差、资源上限）。缺少任何一维，需求都无法进入量产验证。

二、功能安全需求（ISO 26262）的落地

ISO 26262 对迁移工作的核心要求是：原型中未考虑的安全机制，必须在量产软件中补齐，并且可追溯。具体落地包括三件事。

第一，确定 ASIL 等级。通过危害分析与风险评估（HARA），从严重度（S）、暴露率（E）、可控性（C）三个维度评定。例如转速控制失效导致非预期加速，严重度 S3、暴露率 E4、可控性 C2，对应 ASIL C。等级决定了后续安全机制的强度。

第二，定义安全机制与故障响应时间。ASIL C 通常要求具备独立的监控通道。常见做法是：主控制通道计算控制量，监控通道用简化模型或独立传感器校验；一旦偏差超过阈值，在故障容错时间间隔（FTTI）内进入安全状态。假设 FTTI 为 100 ms，则从故障发生到执行安全动作的总延迟必须小于 100 ms，这直接约束了监控周期和任务优先级。

第三，建立需求追溯链。每条安全需求应能追溯到危害、安全目标、技术安全需求，再映射到具体函数和测试用例。迁移时，原型中“直接赋值”的代码往往缺少这种追溯，需要重新标注。

三、实时性需求：从“能跑”到“可证明”

原型常用变步长或较长的控制周期，量产则要求固定周期和可证明的最坏执行时间。实时性需求分析要回答三个问题：周期多长、抖动多大、WCET 多少。

以 1 ms 控制周期为例，若 WCET 为 300 μs，则 CPU 占用率约 30%，留出余量给监控和通信任务。抖动来源包括中断延迟、任务调度、缓存未命中等。评估时可用示波器测量 GPIO 翻转，或在代码中插入时间戳，统计多次执行的最大值和分布。

下面给出一个典型的任务时序关系示意，说明主控制、监控与安全输出在时间轴上的约束。

图中可见，主控制任务最先执行，监控、通信、安全输出依次排布，总占用时间需留有余量。若 WCET 之和接近周期，抖动会显著增大，此时应降低任务频率或优化代码。

四、资源约束需求：把“够用”变成“可量化”

原型常运行在性能充裕的实时机上，量产 ECU 的 RAM、Flash、CPU 往往紧张。资源约束需求应给出明确上限，并在迁移过程中持续测量。

若原型使用浮点运算而量产 MCU 无 FPU，则需改为定点或查表，这会同时影响精度和 WCET，必须在可行性评估中标注为风险项。

五、迁移可行性评估报告

可行性评估报告不是简单罗列，而是对每条需求给出“可迁移、需改造、不可迁移”的结论及依据。建议包含以下字段：需求编号、需求描述、来源（功能/安全/实时/资源）、当前原型状态、量产约束、差距、改造措施、风险等级、结论。

例如：需求“转速闭环控制周期 1 ms”，原型实际为 5 ms 变步长，差距明显，改造措施为重构调度器并测量 WCET，风险等级中，结论为“需改造后可迁移”。再如“ASIL C 独立监控通道”，原型无监控，改造措施为增加简化模型监控，风险等级高，结论为“需改造，且需补充安全验证”。

完成上述分析后，迁移工作就有了明确的输入：哪些代码可直接复用，哪些必须重写，哪些需要补充安全机制。可行性评估报告应作为后续迁移计划和验证活动的基线，并在每次设计变更后更新。