1. 课程导入与验证目标定义

车辆控制算法从需求到量产，通常要经历模型在环（MIL）、软件在环（SIL）、处理器在环（PIL）、硬件在环（HIL）以及实车标定等多个阶段。实时原型验证处在“算法逻辑已经跑通”与“嵌入式代码尚未冻结”之间，它的核心价值在于：用一台具备真实 I/O、真实总线接口和确定性调度的实时目标机，把控制算法以接近最终 ECU 的时序条件运行起来，从而在早期就暴露采样抖动、执行器延迟、总线丢帧、算力不足等只有在真实时间约束下才会出现的问题。如果跳过这一层，直接进入手工 C 代码或量产 ECU 集成，往往要到 HIL 甚至实车阶段才发现控制周期无法满足、CAN 报文超时或状态机抖动，返工代价极高。

典型应用场景可以归纳为四类。第一类是新能源车辆纵向控制，例如自适应巡航（ACC）与能量回收协调，需要验证 10 ms 控制周期下扭矩指令的响应与切换平顺性。第二类是底盘域横纵向耦合控制，例如线控转向与电子稳定程序协同，关注转向角指令与横摆角速度的相位关系。第三类是自动驾驶决策与运动规划的接口验证，把规划输出的轨迹点通过 CAN 或以太网送入实时目标机，检验轨迹跟踪控制器的实时性。第四类是电驱动总成的台架联调，用真实电机控制器与实时模型对接，验证电流环、转速环与整车控制器的信号链一致性。

验证层级需要与验证目标匹配。MIL 阶段算法与模型同机运行，时间不是真实约束，适合验证控制律正确性；SIL 把算法编译为可在 PC 上运行的代码，验证定点化与接口逻辑；PIL 把算法部署到目标处理器但 I/O 仍为仿真，验证算力与编译器行为；HIL 接入真实 ECU 或快速原型控制器，用实时模型模拟被控对象与传感器，验证总线、故障诊断与极限工况；实车阶段则验证环境适应性与标定。本课程聚焦的实时原型验证，主要覆盖 PIL 与 HIL 之间的快速控制原型（RCP）环节，强调“真实 I/O + 真实时序 + 可快速迭代”。

评价指标决定了验证是否“通过”。常用指标包括：控制周期抖动（jitter），例如目标 10 ms 周期下抖动应小于周期的 5%，即 0.5 ms；任务超时次数，在 30 分钟连续运行中应为 0；端到端延迟，从传感器采样到执行器指令输出的时间，例如要求小于 20 ms；总线报文周期偏差与丢帧率，例如 CAN 报文周期偏差小于 10%、丢帧率为 0；控制性能指标，如阶跃响应的超调量小于 10%、稳态误差小于 2%；以及资源占用，CPU 负载低于 70%、堆栈余量大于 30%。这些指标需要在项目任务书中明确，并给出测量方法与判定阈值。

课程项目任务书是本章的落地载体。建议以“某纯电 SUV 纵向速度跟踪”为示例对象：被控对象为整车纵向动力学模型，控制目标为在 0～80 km/h 范围内跟踪目标车速，控制周期 10 ms，通过 CAN 发送扭矩请求，通过 CAN 接收车速与电机转速。任务书应明确以下字段：验证层级为 RCP，目标机为 dSPACE MicroAutoBox 或同等实时系统；输入接口包括 CAN 通道 1（500 kbps）接收车速、CAN 通道 2 发送扭矩；输出记录包括控制周期抖动、端到端延迟、扭矩指令与车速响应曲线；通过条件为阶跃工况超调小于 10%、稳态误差小于 2%、30 分钟无任务超时。交付物包括 Simulink 模型、自动生成代码、测试用例与验证报告。

需要特别说明的是，实时原型验证不是“再跑一次仿真”。仿真中时间由求解器推进，而实时系统中时间由硬件时钟推进，任何一次超时都会直接导致控制输出滞后。因此，验证目标必须包含“时间正确性”与“功能正确性”两个维度。功能正确性回答“控制律对不对”，时间正确性回答“在真实时间约束下还能不能对”。两者缺一不可，这也是本课程后续所有实验与项目工作的基本出发点。