4. MIL验证环境搭建

MIL（Model-in-the-Loop）验证的本质，是在不生成任何C代码的前提下，让Stateflow控制器模型与一个可执行的被控对象模型闭环运行，用测试信号驱动、用参考模型比对、用断言判定、用日志留痕。本节要交付的不是“能跑起来”，而是一个可复用、可判定、可追溯的最小MIL环境，并跑通第一个用例。

一、测试harness的三种组织方式与选型

Stateflow控制器通常以子系统或模型引用形式存在，harness就是包裹它的“测试外壳”。工程上常用三种结构：

• Signal Builder / Signal Editor 驱动型：把激励直接接到控制器输入端口，输出接Scope或To Workspace。搭建最快，适合单输入单输出、逻辑简单的首个用例。
• 闭环被控对象型：控制器输出经被控对象模型反馈回控制器输入，形成真实闭环。MIL阶段最推荐，因为Stateflow的迁移条件往往依赖反馈量（如温度、位置、计数），开环无法触发。
• 模型引用+Test Sequence型：用Test Sequence块或MATLAB脚本按时间步注入激励，适合多工况、多用例批量回归。

首个MIL用例建议采用“闭环被控对象型 + Signal Editor激励”的组合：既保证状态迁移能被真实触发，又便于后续扩展用例。

二、被控对象与参考模型的职责划分

被控对象模型（Plant）负责把控制器的离散输出转换为连续或离散的物理量反馈，例如一个一阶惯性环节：

% 被控对象：一阶惯性 + 饱和
T = 0.5;          % 时间常数(s)
K = 2.0;          % 增益
y_max = 100;      % 输出上限
y_min = 0;        % 输出下限
% 离散化后：y(k+1) = y(k) + Ts/T*(K*u(k) - y(k))
% 再经 Saturation 限幅到 [y_min, y_max]

参考模型（Reference Model）不是被控对象的复制品，而是“期望行为”的独立描述。它可以用MATLAB Function或Simulink基础块实现，输出与控制器输出同量纲的期望值。MIL判定的核心就是：控制器实际输出 vs 参考模型期望输出，而不是控制器输出 vs 被控对象反馈。

三、信号源、断言与日志的落地配置

信号源用Signal Editor定义，至少包含三组：启动使能、目标设定值、扰动注入。以温度控制为例，示例参数如下（属教学假设，非实测）：

断言用Assertion块挂在控制器输出与参考模型输出之间，判定条件写成：

abs(u_actual - u_ref) <= tol
% tol 建议取量程的 2%~5%，示例：tol = 2.0

日志用To Workspace块，Save format选Structure With Time，变量名统一加前缀mil_，例如mil_u_actual、mil_u_ref、mil_state。Stateflow状态可用Stateflow的Output State Activity或sf_state记录，便于事后定位迁移时刻。

四、首个MIL用例的执行与判读

把仿真步长设为Ts = 0.01s，仿真时长15s，求解器用定步长Fixed-step / discrete，保证Stateflow迁移时刻可复现。运行后按以下顺序判读：

1. 打开mil_state日志，确认在t≈1s处发生Idle→Heating迁移，在t≈8s扰动注入后发生Heating→Cooling或保持，与设计意图一致。
2. 绘制mil_u_actual与mil_u_ref曲线，观察偏差是否在tol=2.0内。若在迁移瞬间出现尖峰超差，通常是参考模型未同步迁移或采样时刻错位。
3. 查看Assertion块输出，若为false，用Simulation Data Inspector定位首次失败时刻，再回看该时刻的Stateflow状态与输入。

五、可复用的MIL用例记录表

首个用例跑通后，应立即固化为可追溯记录，后续30个用例沿用同一字段：

至此，MIL环境的最小闭环已经建立：激励可注入、控制器可迁移、参考可比对、断言可判定、日志可追溯。后续SIL/PIL只需替换被测对象为生成代码或目标板，harness、参考模型、断言与日志结构可整体复用，这正是MIL先行搭建的价值所在。