1. 课程导入与验证全景

在基于模型的设计（Model-Based Design，MBD）流程中，Stateflow 承担的是控制逻辑与状态决策的表达职责。Simulink 擅长描述连续时间动态、信号运算与物理对象，而 Stateflow 擅长描述离散事件驱动的状态迁移、条件判断、模式切换与故障处理。二者组合后，一个完整的控制器模型通常呈现为“Simulink 负责被控对象与信号通路，Stateflow 负责模式管理与逻辑仲裁”的分工结构。例如整车控制器中，上电自检、Ready、行驶、充电、故障降级等模式切换，几乎都由 Stateflow 状态机描述；而电机扭矩计算、滤波、限幅等连续运算则留在 Simulink 侧。

正因为 Stateflow 逻辑往往决定“系统在什么条件下做什么”，它的正确性无法仅靠模型外观判断，必须通过分阶段的验证手段逐层确认。MIL、SIL、PIL 就是 MBD 中最常用的三级验证方式，它们验证的是同一套算法逻辑在不同实现形态下的行为一致性。

• MIL（Model-in-the-Loop，模型在环）：被测对象是 Simulink/Stateflow 模型本身，在 PC 上以解释或加速方式运行。目的是验证算法逻辑、状态迁移、接口定义是否正确，此时不涉及任何 C 代码。
• SIL（Software-in-the-Loop，软件在环）：由模型自动生成 C 代码，在 PC 上编译为可执行程序，与测试激励、被控对象模型联合运行。目的是验证生成代码与模型行为是否等价，重点排查代码生成配置、数据类型、定点量化带来的偏差。
• PIL（Processor-in-the-Loop，处理器在环）：将生成的 C 代码交叉编译后下载到目标处理器（如 TC397、S32K、TMS320 等）上运行，PC 侧保留被控对象模型与测试激励，通过通信接口交换数据。目的是验证代码在真实目标硬件上的数值行为、编译器差异、时序与资源约束。

三级验证的核心目标可以概括为三点：逻辑正确（MIL 阶段确认状态机迁移与输出符合需求）、代码等价（SIL 阶段确认生成代码与模型行为一致）、硬件可信（PIL 阶段确认目标处理器上的执行结果与 SIL 一致）。三者构成一条从“设计意图”到“可执行代码”再到“真实硬件”的递进证据链。

支撑这套流程的工具链以 MathWorks 体系为主：Simulink 提供模型与仿真环境，Stateflow 提供状态机建模，Embedded Coder 负责生成面向嵌入式的 C 代码，Simulink Test 管理测试用例与基线，Simulink Coverage 统计状态、迁移、条件覆盖率，Polyspace 用于静态检查与运行时错误证明，处理器在环则依赖目标编译器、调试探针与串口/CAN/以太网通信链路。一个典型的工程案例是：某电驱控制器项目以 Stateflow 描述扭矩管理模式，MIL 阶段用 Simulink Test 跑 120 条场景用例，SIL 阶段将生成代码封装为 S-Function 回灌同一批用例，PIL 阶段把代码烧录到目标板并通过 CAN 回传状态量，最终以三阶段输出对比报告作为软件释放证据。

从工程落地角度看，联合验证并不是把三次仿真简单叠加，而是围绕同一套测试用例、同一套接口定义、同一套判据建立可追溯的证据链。测试用例通常以场景形式组织，例如“钥匙上电 → 自检通过 → 进入 Ready → 收到扭矩请求 → 输出使能”，每条用例记录输入信号序列、期望状态序列与期望输出范围。MIL 阶段用这些用例驱动模型，SIL 阶段把生成代码封装为 S-Function 或独立可执行程序回灌同一批用例，PIL 阶段则把代码下载到目标板，通过 CAN 或串口把状态量回传到 PC 侧与基线比对。

需要特别注意的是，Stateflow 的验证重点与纯 Simulink 不同。状态机的错误往往表现为迁移路径缺失、默认迁移误触发、并行状态竞争、事件排队顺序异常，这些在普通信号波形上不一定明显，必须结合状态覆盖率、迁移覆盖率以及状态活动日志来判断。因此在本课程后续章节中，会围绕 Stateflow 的状态、迁移、事件、并行与历史节点，逐一展开 MIL/SIL/PIL 的测试设计与结果判读方法。