1. Stateflow在Simulink模型中的定位

在基于模型的设计流程中，Simulink擅长描述连续或离散时间域中的信号处理与动态系统，例如滤波器、电机控制环路、被控对象模型等。它的核心语义是“每个采样步计算一次输出”，数据以信号线的方式在模块之间流动。而Stateflow解决的是另一类问题：系统行为并非由连续方程主导，而是由离散状态、事件触发和条件迁移决定。典型例子包括挡位切换、模式管理、故障分级、启停时序、按键状态机等。把这些逻辑硬塞进Simulink的开关和使能子系统，模型会迅速变得难以阅读和维护；Stateflow正是为这类“事件驱动的离散决策”提供图形化建模能力。

理解Stateflow的定位，关键是把它看作Simulink模型中的一个特殊子系统：它对外仍然是模块，有输入输出端口，参与Simulink的采样与求解；对内则用状态、迁移、条件动作和图形函数描述控制逻辑。也就是说，Stateflow不是替代Simulink，而是与Simulink形成分工——Simulink负责信号流与连续/离散计算，Stateflow负责模式判断与逻辑调度。

状态机与流程图：两种建模视角

Stateflow内部支持两种主要的图形表达方式，它们适用于不同场景。

状态机（State Machine）强调“系统当前处于哪个状态”。每个状态可以包含entry、during、exit动作，迁移线上写条件与动作。它天然适合表达具有记忆性的逻辑：例如“待机→运行→故障→复位”的循环，系统必须记住当前处于哪个模式。状态机的优势在于状态互斥、层次清晰，可以用父状态/子状态表达嵌套逻辑，用并行状态表达同时活跃的多个子系统。

流程图（Flow Chart）强调“从输入到输出的判断路径”。它由判断节点、连接节点和终止节点组成，没有状态记忆，每次执行都从入口重新走一遍。它适合表达组合逻辑：例如根据车速、油门开度、制动信号计算出一个请求扭矩或使能标志。流程图的优势是路径直观，适合把复杂的if-else或switch逻辑画清楚。

选择哪种方式，判断依据是：逻辑是否需要记忆。需要记忆历史模式，用状态机；只根据当前输入组合决定输出，用流程图。实际工程中两者经常混用：外层用状态机管理模式，状态内部用流程图计算具体输出。

与Simulink信号流的协同关系

Stateflow模块在Simulink中通过输入端口接收信号，通过输出端口发出控制量。协同的关键在于采样与执行顺序。Stateflow默认在每个采样步执行一次，其输入来自Simulink信号，输出又反馈给Simulink中的执行器或计算模块。因此，设计时必须明确：Stateflow的采样周期是否与所连信号一致；输入信号是否需要保持或做类型转换；输出是直接驱动执行器，还是作为使能/模式选择信号参与后续计算。

一个常见的协同模式是“Simulink算数值，Stateflow管模式”。例如在电机控制中，Simulink计算电流环和转速环的连续调节量，Stateflow根据使能、故障、方向请求决定当前应处于“待机、使能、运行、故障”中的哪个状态，并把模式字和使能标志送回Simulink，由Simulink决定最终输出。这样，连续控制与离散逻辑各司其职，模型层次清晰。

另一个要点是数据作用域。Stateflow可以访问Simulink的输入输出、参数和全局数据。输入数据在Stateflow内部是只读的，输出数据由Stateflow写入。若逻辑需要记忆中间变量，应使用Stateflow的局部数据或状态动作，而不是依赖Simulink信号反馈，否则容易引入不必要的代数环或采样延迟。

典型控制逻辑案例概览

为了建立直观认识，下面给出三个典型场景，它们分别对应状态机、流程图以及两者混合的用法。

以“电机使能与故障分级”为例，可以这样组织：顶层状态机包含“初始化、待机、预充、运行、降额、故障”六个状态。进入“运行”后，状态内部的流程图根据温度和电流计算降额系数；当温度超过阈值并持续一定时间，迁移到“降额”；若电流超过保护阈值，直接迁移到“故障”。故障状态中再根据故障类型决定是否可恢复。这样，状态机负责模式迁移，流程图负责数值判断，二者在同一模块内协作。

建模前的定位检查

在动手画Stateflow之前，建议先完成一次定位检查，避免把连续计算误放进状态机，也避免把有记忆的模式逻辑画成流程图。检查内容包括：明确哪些量是输入信号、哪些是输出控制量；确认采样周期与Simulink一致；确认状态数量与迁移条件是否覆盖所有工况；确认默认迁移和初始化动作是否明确。对于安全相关逻辑，还应考虑状态是否可恢复、故障是否可以自动清除、是否存在状态死锁。