3. 验证需求与可测性设计

在Stateflow MIL/SIL/PIL联合验证中，真正决定验证效率的不是工具本身，而是“需求是否被翻译成可执行的测试需求”。系统需求通常以自然语言描述功能行为，例如“当车速超过30 km/h且驾驶员未踩制动时，车门应自动上锁”。这类描述对测试而言仍过于笼统：30 km/h是精确阈值还是带迟滞？未踩制动是否包含制动踏板信号无效？车门上锁的判定依据是锁执行器命令还是锁状态反馈？如果这些问题在测试需求阶段没有澄清，后续无论MIL还是PIL都只能验证“模型与自身一致”，无法证明“模型满足系统意图”。

从系统需求到Stateflow测试需求

把系统需求转化为Stateflow测试需求，核心动作是识别需求中的状态、迁移条件、输入信号、输出动作和时序约束。以车门自动上锁为例，可拆解为：状态集合{未上锁, 上锁}；迁移条件为“车速 > 30 km/h 且 制动踏板 == 未踩下 且 挡位 == 前进”；输出动作为“LockCmd = 1”；时序约束为“条件持续满足200 ms后执行，避免抖动误触发”。这些要素正好对应Stateflow中的状态、转移、条件表达式和after算子。

测试需求应写成可判定的形式，推荐采用“前置条件—激励—预期响应—判定容差”四元组。例如：

TR-03-01 车门自动上锁
前置：Ignition=ON, Gear=Drive, Brake=Released, LockState=Unlocked
激励：VehicleSpeed 从 0 斜坡升至 35 km/h，斜率 5 km/h/s
预期：VehicleSpeed 超过 30 km/h 后 200±20 ms 内 LockCmd 由 0 变为 1
判定：LockCmd 上升沿时刻与阈值跨越时刻之差在 [180,220] ms 内

这里“200±20 ms”就是判定容差，它来自需求中的防抖时间，而不是随意设定。没有容差的测试需求在PIL阶段几乎无法通过，因为目标硬件上的调度周期、中断延迟和浮点运算都会引入偏差。

覆盖目标：从模型结构到需求语义

Stateflow的覆盖目标不能只停留在“状态被访问过”。工程上通常同时关注四类覆盖：状态覆盖（每个状态至少进入一次）、迁移覆盖（每条转移至少触发一次）、条件覆盖（转移条件中每个布尔子项取真取假）、迁移路径覆盖（关键状态序列被完整走过）。对于安全相关逻辑，还应补充MC/DC，确保复合条件中每个原子条件能独立影响判定结果。

以“车速 > 30 且 制动未踩下 且 挡位为前进”为例，条件覆盖要求至少构造：车速高于/低于阈值、制动踩下/未踩下、挡位前进/非前进共6种组合中的有效组合；MC/DC则要求固定其余两个条件，单独翻转车速条件时判定结果改变，单独翻转制动条件时判定结果也改变。这样能暴露“与”条件中某个子项被短路或写错变量的问题。

可观测性设计与测试接口

可观测性指在不修改模型功能逻辑的前提下，能否从外部获取足够信息判断测试是否通过。Stateflow中大量中间变量、局部状态和转移条件是默认不可见的，因此需要在建模阶段就规划观测点。常用做法包括：将关键中间量提升为输出端口、使用Data Store Memory并配置为可观测、在Stateflow中增加只读的观测输出（不参与控制逻辑），以及在信号记录中启用“Test Point”标记。

测试接口的设计要与MIL/SIL/PIL三阶段兼容。MIL阶段可直接访问模型内部信号；SIL阶段通过生成的代码接口访问；PIL阶段只能通过目标硬件的物理或通信接口访问。因此测试接口应尽量统一为“输入激励接口 + 输出观测接口 + 时间同步接口”。输入激励可以是MATLAB脚本、Signal Builder或外部CAN报文；输出观测可以是Scope记录、日志文件或XCP测量。时间同步接口用于对齐激励时刻与响应时刻，尤其在PIL中必须记录目标硬件的采样时刻。

信号记录策略

信号记录不是“把所有信号都存下来”就万事大吉。记录策略要回答三个问题：记什么、记多快、记多久。记什么取决于判定依据：如果测试需求只判定LockCmd的上升沿时刻，那么必须记录LockCmd、VehicleSpeed、Brake和Gear，以及一个高精度时间戳；Stateflow内部状态可作为辅助诊断信号记录。记多快取决于信号变化速率：车速斜坡5 km/h/s，200 ms内变化约1 km/h，采样周期10 ms足以捕捉阈值跨越；但若判定容差是±20 ms，采样周期应不大于5 ms，否则时间量化误差会吃掉容差。记多久取决于测试时长和存储深度，通常采用“预触发+后触发”方式，只保留激励前后各若干秒的数据，避免海量日志。

在PIL阶段，信号记录还要考虑目标硬件的缓冲区和通信带宽。若通过XCP测量，应优先使用事件触发采样而非固定周期轮询，减少总线负载；若通过CAN记录，需注意报文周期与信号更新率的关系，避免把“报文未更新”误判为“信号未变化”。

可测性设计的检查要点

• 每条测试需求是否都有明确的判定依据和容差，而不是“观察是否正常”。
• 关键中间变量是否已提升为可观测输出，且不改变功能逻辑。
• 覆盖目标是否量化，未覆盖项是否有处理结论。
• MIL/SIL/PIL三阶段的测试接口是否尽量统一，激励和观测方式是否可迁移。
• 信号记录的时间精度是否满足最严苛的判定容差。
• 时间参照是否统一：所有时刻均以激励开始时刻为t=0，还是以硬件采样时刻为基准，必须在测试需求中写明。

综上，验证需求与可测性设计的产出不是一份文档，而是一组可执行的测试需求、量化的覆盖目标、明确的观测点和统一的记录策略。它们共同决定了后续MIL/SIL/PIL联合验证能否从“跑通”走向“可信”。