4. Stateflow核心建模元素

Stateflow 的建模能力并不是由“画了多少个框”决定的，而是由七类核心元素之间的语义关系决定的：状态定义系统“处于什么模式”，转移定义“何时离开当前模式”，事件提供触发时机，条件决定转移是否被允许，条件动作在转移被选中时执行数据更新，默认转移决定图或父状态首次激活时进入哪个子状态，历史节点决定重新进入父状态时恢复到哪个子状态，连接节点则用于组织多分支转移的汇合与判定。工程交付中，这七类元素如果语义混乱，会直接导致生成代码与需求不一致，因此必须从“语义—语法—代码”三个层面统一理解。

状态：层次与并行是工程组织的骨架

状态分为互斥（OR）与并行（AND）两种分解方式。互斥状态下，同一时刻只有一个子状态处于激活状态；并行状态下，所有子状态同时激活。工程中常见的错误是把本应并行的“监控”和“控制”写成互斥，导致监控逻辑在控制状态激活时被挂起。例如电池管理系统中，BMS_Active 父状态可分解为并行的 VoltageMonitor 与 CurrentMonitor，两者同时运行；而 ChargeMode 与 DischargeMode 则必须是互斥的，否则会出现充放电同时使能的危险逻辑。

状态的 entry、during、exit 动作是工程交付中最容易出问题的地方。建议约定：entry 只做初始化赋值，during 只做周期性计算，exit 只做资源释放或状态保存。不要把条件判断写在 during 里再触发转移，这会让代码生成后的执行顺序难以预测。

转移、事件与条件：触发语义必须显式

一条转移的完整语法是 event[condition]{action}。其中事件可以是输入事件、时间事件（如 after(5, sec)）或内部消息；条件必须是布尔表达式；动作在转移被选中且条件为真时执行。工程中建议把“事件”和“条件”分开写，不要用条件代替事件，也不要用事件代替条件。例如 after(10, msec)[speed > 100] 表示每 10 ms 检查一次速度是否超过 100，而不是“速度超过 100 后等 10 ms”。

转移的优先级由绘制顺序和层次决定：同一层级中，编号越小优先级越高；子状态转移优先于父状态转移。工程交付时应在转移上标注优先级编号，避免依赖工具默认顺序。条件动作中不要写复杂循环，只做赋值或简单函数调用，否则生成代码的可读性和可测试性都会下降。

默认转移与历史节点：首次进入与恢复进入

默认转移决定父状态首次被激活时进入哪个子状态。如果没有默认转移，Stateflow 会报错或进入不确定状态。工程中建议每个父状态都显式画出默认转移，并在默认转移上写清初始化动作。历史节点则用于“记住上次离开时的子状态”。浅历史（H）只恢复直接子状态，深历史（H*）恢复所有层级。例如 Operating 父状态包含 Idle、Run、Fault 三个子状态，使用浅历史后，从 Fault 退出再重新进入 Operating 时会回到 Fault，而不是默认的 Idle。这在故障恢复场景中非常有用，但必须确认“恢复进入”是否符合安全需求。

连接节点：多分支汇合与判定

连接节点（Connective Junction）用于把多条转移汇合到一点，再根据条件分发到不同目标。它本身不消耗时间，也不产生状态。工程中常用连接节点实现“多条件分支”和“循环转移”。例如根据 mode 变量选择进入 Manual、Auto 或 Safe，可以用一个连接节点加三条带条件的转移实现。注意连接节点上的条件必须互斥且完备，否则会出现死锁或不确定行为。

工程交付中的组合用法与检查要点

实际项目中，这七类元素往往组合出现。一个典型的“故障恢复”模式是：父状态 Operating 使用浅历史节点，子状态 Fault 通过 reset 事件和条件 [err==0] 转移回历史节点，再由历史节点恢复到 Run 或 Idle。此时必须确认：历史节点是否记录了正确的子状态；reset 事件是否在故障清除后才发出；条件动作是否清除了错误标志。

建议在模型评审时逐项检查：每个父状态是否有默认转移；每个历史节点是否明确浅/深；每条转移是否标注了事件、条件和动作；连接节点的分支条件是否互斥且完备；条件动作是否只做赋值。这些检查项可以直接作为交付前的自检清单，避免生成代码与需求脱节。