1. 课程导入与验证工程全景
在基于模型的设计（Model-Based Design，MBD）体系中，Simulink 负责把控制算法、被控对象与信号接口表达为可执行的模型，Stateflow 负责把离散逻辑、状态迁移与事件驱动行为表达为可判定的状态机，而 Simulink Test 则负责把这些模型放到可重复、可追溯、可度量的验证环境中。三者不是并列的工具清单，而是一条从“设计意图”到“可验证证据”的链路：Stateflow 让逻辑变得可读、可执行，Simulink 让系统行为可仿真，Simulink Test 让“模型是否正确”从主观判断变成有输入、有预期、有判据、有报告的工程结论。
很多初学者会把验证理解为“跑一遍仿真看看波形对不对”。在工程实践中，这种做法的最大问题是不可复现：换一个人、换一个版本、换一组参数，结论就可能不同。验证工程要解决的核心问题是——把验证意图固化为可执行的资产。测试用例、测试序列、基线数据、评估判据、覆盖率目标、需求链接，这些资产共同构成模型验证的证据链。本课程后续 29 章将围绕这条证据链展开，而本章先建立全景认知：工具各自站在什么位置、V 模型流程如何映射到具体操作、工具链之间靠什么协同、以及贯穿全课的实战项目是什么。
一、三个工具在验证链中的定位
Simulink 是系统行为的载体。它承载连续与离散动态、代数环、采样率、定点与浮点数据类型，是“被验证对象”的主体。Stateflow 通常嵌入 Simulink 模型内部，以 Stateflow Chart 的形式存在，处理模式切换、故障降级、使能条件、超时保护等逻辑。它的验证难点不在数值精度，而在状态可达性、迁移条件完备性、互斥与并行语义、事件顺序。Simulink Test 则是验证活动的组织者：Test Manager 管理测试文件与测试用例，Test Sequence 或 Excel 描述激励，Baseline 与 Assess 描述预期，Test Harness 隔离被测对象，Coverage 与报告输出结论。
理解定位的一个实用判断是：当你发现缺陷表现为“数值偏差、响应超调、稳态误差”，问题多半在 Simulink 侧的参数与动态；当缺陷表现为“该进故障模式却没进、两个状态同时激活、事件丢失”，问题多半在 Stateflow 侧的逻辑；当你发现“无法判断这次修改是否破坏了原有功能”，问题在验证资产的组织方式，也就是 Simulink Test 侧。这个判断不是绝对的，但它能帮助你在排障时快速缩小范围。
二、模型验证的 V 模型流程
V 模型的价值在于把“分解”和“集成验证”对应起来。左侧下行是设计分解：系统需求 → 系统架构 → 子系统设计 → 组件模型（含 Stateflow 逻辑）。右侧上行是逐级验证：组件级单元测试 → 子系统集成测试 → 系统集成测试 → 系统确认。关键对应关系是：左侧每一层的设计产物，都应在右侧同一层有对应的验证活动。组件模型对应单元测试，子系统接口对应集成测试，系统需求对应确认测试。
在 Simulink Test 中，这个对应关系落地为：组件级用 Test Harness 隔离被测 Chart 或 Subsystem，用 Test Sequence 构造边界与异常激励；子系统级用 Signal Builder 或 Excel 驱动多组件协同，用 Assess 检查接口时序与数据一致性；系统级用 Baseline 捕获期望轨迹，用覆盖率确认需求是否被充分执行。需要强调的是，V 模型不是“先做完左边再做右边”，而是每一层设计完成后即可开展对应层验证，越早发现缺陷，修复成本越低。
三、工具链协同关系
工具链协同的关键不是“都能打开”，而是数据能否在工具之间无损传递。Simulink 与 Stateflow 之间通过信号线、数据对象、事件广播协同：Simulink 的输入信号进入 Chart 后成为状态迁移的触发条件，Chart 的输出又回到 Simulink 参与动态计算。这里最容易出问题的是采样率与事件顺序：如果 Chart 的输入信号采样率与触发事件不同步，就可能出现“条件已满足但迁移未发生”的现象。验证时应在 Test Sequence 中显式控制信号变化时刻，而不是依赖默认求解器步长。
Simulink Test 与 Simulink/Stateflow 的协同体现在三个层面。第一层是激励注入：Test Sequence 可以按时间轴精确设置信号值，Excel 用例适合批量参数扫描。第二层是结果评估：Baseline 比较实际输出与期望轨迹，Assess 用逻辑表达式判断“是否在允许范围内”，两者可组合使用。第三层是覆盖率反馈：Stateflow 的决策覆盖率、条件覆盖率、状态覆盖率能直接指出哪些迁移从未被执行，从而暴露测试用例的盲区。覆盖率不是目标本身，而是发现“没测到”的手段。
四、贯穿全课的实战项目
本课程以一个典型的电机控制器模式管理模块作为实战对象。该模块包含三个主要状态：初始化（Init）、正常运行（Run）、故障降级（Fault）。输入包括使能信号 Enable、转速反馈 Speed、温度 Temp、故障标志 FaultFlag；输出包括模式字 Mode、使能输出 Cmd、故障指示 FaultLamp。逻辑约束为：Enable 为真且无故障时进入 Run；Temp 超过 120℃ 或 FaultFlag 为真时进入 Fault；Fault 状态下 Speed 低于 50 rpm 且故障消失后，需保持 2 秒再回到 Init，防止抖动。
这个项目规模不大，但覆盖了验证工程的典型难点：状态迁移条件、超时保护、边界值、异常注入、时序约束。后续章节将围绕它逐步展开——用 Stateflow 实现模式逻辑，用 Test Harness 隔离测试，用 Test Sequence 构造正常与异常激励，用 Assess 判断模式字是否符合预期，用覆盖率确认所有迁移都被执行。示例中的 120℃、50 rpm、2 秒均为教学假设值，实际工程中应以需求规格为准。
本章建立了全景认知：Simulink 是行为载体，Stateflow 是逻辑载体，Simulink Test 是证据载体；V 模型把设计分解与逐级验证对应起来；工具链协同靠激励、判据、覆盖率三条数据流贯通；实战项目提供了贯穿全课的验证对象。接下来进入具体工具与操作，每一步都会回到这条证据链上。