1. 课程导入与迁移工程全景

快速控制原型（Rapid Control Prototyping，RCP）与量产软件之间的差异，不是“代码写得好不好”的差异，而是目标、约束、验证方式和责任边界的系统性差异。RCP 的核心目标是“尽快验证控制策略是否有效”，量产软件的核心目标是“在确定的硬件、确定的成本、确定的法规与安全约束下，长期稳定地交付一致行为”。理解这一点，是迁移工程全部工作的起点。

在 RCP 阶段，工程师通常使用 Simulink/Stateflow 搭建控制模型，通过自动代码生成工具（如 TargetLink、Embedded Coder）生成 C 代码，下载到原型控制器（如 dSPACE MicroAutoBox、Speedgoat 或带旁路的快速原型 ECU）上运行。此时模型可以包含浮点运算、动态内存分配、未裁剪的查表、未做边界保护的除法，甚至直接调用主机端调试接口。这些做法在原型阶段是合理的，因为原型允许“先跑通、再优化”。但量产软件必须运行在资源受限的定点 MCU 上，必须满足 MISRA C 等编码规范，必须通过 ISO 26262 或 IEC 61508 等功能安全流程，必须支持 OTA 升级、诊断服务（UDS）和网络管理（AUTOSAR NM）。

迁移工程的核心挑战可以归纳为四类。第一类是数值语义差异：原型中的 double 运算迁移到量产定点平台后，溢出、舍入和饱和行为都会改变。例如一个 PI 调节器在原型中积分项使用 double 累加，迁移到 16 位定点后若未做抗积分饱和，输出会在限幅后继续累积，导致退出饱和时出现大幅超调。第二类是执行时序差异：原型任务周期可能是 1 ms 且抖动较大，量产软件要求 1 ms 周期抖动小于 50 μs，且任务调度受 OS 优先级和中断延迟影响。第三类是接口与标定差异：原型通过 XCP 在线标定，量产必须使用 A2L 文件配合标定工具，且标定量需固化到 NVM 或通过诊断服务写入。第四类是安全与诊断差异：量产软件需要 RAM/ROM 自检、看门狗、E2E 保护、故障降级策略，而原型通常没有这些机制。

典型失败模式往往不是单点技术错误，而是上述差异的连锁反应。例如某电机控制器项目在 RCP 阶段使用 double 型电流环，迁移到 16 位定点 MCU 后，电流采样值经过 ADC 量化后直接参与 Park 变换，由于未做 Q 格式对齐，d 轴电流在高速段出现周期性尖峰，最终触发过流保护。根因不是算法错误，而是数值表示与运算顺序在迁移中未被显式验证。

成功要素同样可以对应到四个维度。数值层面，需要在迁移前完成定点化仿真，用与量产一致的 Q 格式和饱和策略重新验证控制性能；时序层面，需要测量量产平台的实际任务执行时间和抖动，确认最坏情况执行时间（WCET）满足周期要求；接口层面，需要建立标定量与测量量的 A2L 映射，并验证 NVM 读写和诊断写入的可靠性；安全层面，需要从危害分析出发，定义安全机制和降级策略，并保留可追溯的验证证据。

建立全流程认知框架的意义在于：让团队在项目早期就识别出哪些原型设计决策会成为迁移障碍。例如，原型中大量使用动态查表和浮点积分，迁移时就需要提前规划定点化方案和查表压缩策略；原型中依赖主机端在线调参的接口，迁移时就需要设计 A2L 变量和 NVM 存储结构。越早识别，迁移成本越低。