1. 课程导入与工程场景

在嵌入式控制软件中，Stateflow 并不是一个“画流程图更方便”的装饰工具，它承担的是离散状态与模式切换逻辑的精确建模与可执行化。典型对象包括车身控制器（BCM）的灯光模式管理、电机控制器的使能/预充/运行/故障状态机、电池管理系统（BMS）的接触器时序与故障降级、变速箱控制单元（TCU）的换挡阶段管理等。这些逻辑的共同特征是：输入是离散事件与条件组合，输出是模式、使能、故障等级和动作序列，而连续控制律往往由 Simulink 侧的 PID、滤波或查表模块完成。Stateflow 与 Simulink 的边界因此非常清晰：连续量走 Simulink，离散决策走 Stateflow，两者通过信号线在同一模型内闭环。

以一个教学示例说明这种分工。假设某 BMS 需要在“上电自检→预充→主继电器闭合→正常运行→故障降级”之间切换，关键输入为 Ignition、PrechargeDone、BusVoltage、FaultLevel，输出为 MainRelayCmd、PrechargeRelayCmd、SystemMode。在 Stateflow 中，这些输入输出以数据对象形式绑定到 Simulink 端口，状态迁移条件写成 [Ignition==1 && FaultLevel==0] 这类布尔表达式，迁移动作写成 SystemMode = 2;。仿真时，若 BusVoltage 在预充阶段未达到阈值，状态不会进入“主继电器闭合”，而是停留在预充并触发超时迁移。这种“条件—迁移—动作”的可执行语义，正是 Stateflow 区别于普通状态图的价值。

模型覆盖率把上述问题量化。对 Stateflow 而言，常用的覆盖指标包括：状态覆盖（每个状态是否被进入）、迁移覆盖（每条迁移是否被触发）、条件覆盖（迁移条件中每个子条件的真假组合是否被评估）、决策覆盖（复合条件的整体真假是否都出现）。例如一条迁移条件为 [FaultLevel>=2 && BusVoltage<18]，仅让整体为真并不够，条件覆盖要求 FaultLevel>=2 为真/假、BusVoltage<18 为真/假都被评估到。覆盖率报告会以百分比和未覆盖对象清单呈现，未覆盖项往往直接指向需求遗漏、测试用例缺失或模型中存在不可达逻辑。

本课程的学习路径围绕“需求—模型—测试—覆盖—追溯”这条主线展开，但不会把它做成一条单向流水线。实际工程中，需求变更会反向修改模型，覆盖率缺口会反向补充测试，追溯矩阵会暴露需求与实现的不一致。因此课程按能力递进组织：先建立 Stateflow 语义与建模规范，再掌握需求条目化与链接方法，随后进入测试用例设计、覆盖率采集与缺口分析，最后完成一个贯穿式实战项目。

实战项目设定为一个电池管理系统状态机，规模控制在可完整走通的范围内。项目包含约 8 个状态、14 条迁移、3 个并行区域（主状态机、故障计数、诊断上报），需求条目约 20 条，覆盖正常上电、预充超时、过压降级、过温降级、故障恢复五类场景。交付物包括：Stateflow 模型、需求追溯矩阵、测试用例集、覆盖率报告和缺口分析记录。示例参数如预充目标电压 BusVoltage >= 0.9 * PackVoltage、预充超时 PrechargeTimeout = 500 ms、故障恢复延时 RecoveryDelay = 2 s，均为教学假设值，实际项目需按硬件与安全需求标定。

从图中可以看到，需求、模型、测试、覆盖率四者并非线性关系，而是通过追溯矩阵形成双向链接，并通过覆盖率缺口形成反馈回路。工程上最常见的失败模式是：模型状态齐全、仿真能跑通，但追溯矩阵中大量需求没有链接到具体状态或迁移，覆盖率报告中迁移覆盖只有 60% 左右，未覆盖项集中在故障降级和恢复路径。这类问题不会在“功能看起来正常”时暴露，却会在安全评审或现场故障复现时集中爆发。

后续内容将逐步展开 Stateflow 的语义细节、需求条目化写法、链接与追溯矩阵构建、测试用例设计方法、覆盖率采集与报告解读，以及缺口分析与整改流程。你不需要一开始就掌握全部工具操作，但需要先建立“模型即证据、覆盖即可信”的工程意识，这是本课程所有技术方法的共同前提。