4、Stateflow状态机建模：状态图、转移、事件、动作、层次化状态机、并行分解、状态机与Simulink的集成
Stateflow是MathWorks公司提供的基于有限状态机（FSM）和流程图理论的图形化建模环境，它嵌入在Simulink之中，用于设计组合逻辑和时序逻辑系统。在基于模型设计（MBD）的完整流程中，Stateflow承担了控制逻辑、调度逻辑、模式管理和故障处理等核心功能。与Simulink中基于连续时间或离散时间信号流的模块不同，Stateflow通过状态（State）、转移（Transition）、事件（Event）和动作（Action）来描述系统在离散时刻的行为变化。本章将深入剖析Stateflow的核心建模要素，阐述层次化与并行分解的架构设计方法，并重点讲解状态机与Simulink数据交互的工程实践，帮助学员建立从图形建模到嵌入式代码生成的完整认知。
4.1 状态图与转移的核心原理
状态图（State Diagram）是Stateflow中最基本的建模单元，它由状态（State）和转移（Transition）构成。状态代表系统在某一时刻所处的稳定模式，而转移则描述了系统在特定条件下从一个状态切换到另一个状态的过程。在嵌入式控制系统中，状态图非常适合描述模式切换、故障恢复、操作序列等离散逻辑。例如，一个电机控制系统可以定义"停止"、"启动"、"运行"、"故障"四个状态，通过转移条件实现状态间的切换。
状态具有三个关键动作（Action）关键字：entry（进入动作）、during（持续动作）和exit（退出动作）。entry动作在状态被激活时执行一次，during动作在状态保持激活期间每个时间步执行，exit动作在离开状态前执行。这种动作划分使得状态行为描述更加精确，也便于代码生成时映射为高效的C语言switch-case结构。转移由触发条件（Condition）和转移动作（Transition Action）组成，条件可以是逻辑表达式、事件发生或两者的组合。转移的优先级遵循"先到先得"原则，当多个转移同时满足条件时，系统按照转移在图形中的几何位置（从上到下、从左到右）决定优先级。
4.1.1 状态图建模操作流程
- 定义状态集合：分析系统需求，提取所有可能的稳定模式，为每个模式创建一个状态。状态命名应具有业务含义，如IDLE、RUN、FAULT。
- 确定转移条件：明确每个状态之间切换的触发条件，条件可以是信号阈值、事件、时间条件或组合逻辑。
- 分配动作：为每个状态定义entry、during、exit动作，为每个转移定义转移动作。动作可以是变量赋值、事件广播、函数调用或Simulink信号输出。
- 设置默认转移：每个状态图必须有一个默认转移（带箭头的实心圆点），用于指定系统启动时进入的初始状态。
- 验证完备性：检查是否所有可能的状态组合都有明确的转移路径，避免出现"卡死"状态。
4.1.2 案例：汽车车窗防夹系统状态图
考虑一个汽车车窗防夹系统，其核心需求是：车窗在上升过程中遇到障碍物时，应立即停止并反转下降一段距离。我们定义三个状态：IDLE（空闲）、UP（上升）、DOWN（下降）。初始状态为IDLE，当驾驶员按下上升按钮时，转移至UP状态；在UP状态中，若检测到防夹力超过阈值（如100N），则转移至DOWN状态并执行反转动作；在DOWN状态中，当车窗到达底部或下降时间超过2秒时，返回IDLE。该状态图清晰地表达了防夹逻辑，且每个状态的动作独立封装，便于后续维护和代码生成。
| 状态 | Entry动作 | During动作 | Exit动作 | 转移条件 |
|---|---|---|---|---|
| IDLE | 电机停止 | 无 | 无 | 上升按钮按下 → UP |
| UP | 电机正转 | 检测防夹力 | 电机停止 | 防夹力>100N → DOWN |
| DOWN | 电机反转 | 计时 | 电机停止 | 时间>2s → IDLE |
4.2 事件与动作的工程语义
事件（Event）是Stateflow中触发状态转移或动作执行的机制。事件分为两类：输入事件（从Simulink或其他Stateflow图传入）和内部事件（在状态图内部通过广播产生）。输入事件可以是边沿触发（上升沿、下降沿）或函数调用触发。在嵌入式应用中，事件常用于表示中断信号、定时器溢出、通信消息到达等异步事件。动作（Action）则是状态或转移中执行的具体操作，包括变量赋值、算术运算、函数调用、事件广播等。
在代码生成层面，事件和动作的映射方式直接影响生成代码的效率。Stateflow的代码生成器会将状态图转换为C语言中的switch-case结构，每个状态对应一个case分支，事件则映射为函数调用或标志位判断。理解这一映射关系，有助于工程师在建模时预估生成代码的结构和性能。例如，频繁使用事件广播可能导致函数嵌套调用，增加栈开销；而使用条件判断则可能生成更紧凑的代码。
4.2.1 动作执行顺序与优先级
当一个转移被触发时，动作的执行顺序遵循严格的语义：首先执行源状态的exit动作，然后执行转移动作，最后执行目标状态的entry动作。如果目标状态是复合状态（包含子状态），则还需执行子状态的默认转移和entry动作。这种"先退出、再转移、后进入"的顺序保证了状态切换的原子性和可预测性。在并行分解中，多个并行状态的执行顺序遵循它们在图形中的排列顺序（从上到下），这会影响共享变量的读写时序，建模时必须注意。
4.3 层次化状态机与并行分解
层次化状态机（Hierarchical State Machine）允许在一个父状态内部嵌套子状态，从而将复杂的系统行为分解为多个抽象层级。父状态可以看作一个"超级状态"，它封装了子状态的公共行为；子状态则继承父状态的转移和动作。这种建模方式极大地提高了状态图的可读性和可维护性。例如，在汽车电子系统中，"驾驶模式"可以作为一个父状态，其内部包含"经济模式"、"运动模式"和"舒适模式"三个子状态，而父状态级别的转移（如"切换到倒车"）可以统一处理。
并行分解（Parallel Decomposition）则通过"AND"分解将状态图划分为多个并行执行区域。每个区域独立维护自己的状态，但共享全局变量和事件。并行分解非常适合描述相互独立但需要协同工作的子系统，如"变速箱控制"和"发动机控制"可以并行运行，各自管理自己的状态，但通过共享变量（如目标扭矩）进行交互。在代码生成时，并行区域通常映射为独立的函数调用，在同一个时间步内依次执行。
4.3.1 层次化与并行的选择策略
| 维度 | 层次化状态机 | 并行分解 |
|---|---|---|
| 适用场景 | 状态之间存在包含关系，子状态共享父状态行为 | 多个功能模块独立运行，但需要同步协调 |
| 状态关系 | 父子关系，同一时刻只有一个子状态激活 | 兄弟关系，同一时刻所有区域均激活 |
| 代码生成 | 嵌套switch-case，层级清晰 | 多个函数调用，顺序执行 |
| 典型应用 | 系统模式管理、故障处理分级 | 多轴运动控制、多传感器融合 |
4.4 状态机与Simulink的集成
Stateflow状态机作为Simulink模型中的一个模块，通过输入输出端口与Simulink的其他模块进行数据交互。集成方式包括：信号输入（从Simulink信号线接收数据）、信号输出（将状态或动作结果输出到Simulink）、事件输入（从Simulink的Goto/From或Trigger模块接收事件）、参数共享（通过工作区变量或数据字典共享参数）。在MBD流程中，状态机通常与Simulink的连续时间模块（如PID控制器、滤波器）协同工作，形成完整的闭环控制系统。
在集成过程中，数据类型的匹配至关重要。Stateflow支持double、single、int8/16/32、uint8/16/32、boolean等基本数据类型，也支持总线（Bus）对象和枚举类型。推荐使用枚举类型定义状态，这样生成的代码可读性更高，且便于调试。例如，定义枚举类型enum {IDLE, UP, DOWN} WindowState;，在状态图中使用该枚举作为状态变量，生成的C代码将直接使用枚举常量，便于在嵌入式调试器中查看状态。
4.4.1 集成配置与代码生成设置
// 在Simulink模型中配置Stateflow模块
// 1. 设置输入事件：使用Trigger端口，选择"上升沿"触发
// 2. 设置输出数据类型：通过Signal Attributes指定输出为uint8
// 3. 在Stateflow中定义枚举类型：
// enum WindowState { IDLE=0, UP=1, DOWN=2 };
// 4. 在状态图中使用：
// {WindowState} state_var = IDLE;
// 5. 生成代码时，选择"ERT"目标，启用"Reusable function"选项在代码生成配置中，应关注以下关键选项：状态编码方式（枚举或整数）、函数打包方式（每个状态图生成独立函数或内联）、事件处理方式（函数调用或标志位）。对于资源受限的嵌入式目标，建议选择"内联"方式减少函数调用开销；对于复杂系统，选择"可重用函数"便于代码复用和测试。
4.4.2 实战案例：混合动力汽车能量管理策略
考虑一个混合动力汽车的能量管理控制器，需要根据驾驶员需求扭矩、电池SOC（State of Charge）和车速，决定发动机和电机的功率分配。我们使用Stateflow建立层次化状态机：顶层状态包括"纯电模式"、"混合模式"和"充电模式"；在"混合模式"下，又包含"并联驱动"和"串联驱动"两个子状态。同时，使用并行分解建立"电池保护"状态机，独立监控SOC，当SOC低于阈值时，强制切换至"充电模式"。
在Simulink集成层面，状态机的输入包括：驾驶员扭矩请求（来自踏板传感器模型）、电池SOC（来自电池模型）、车速（来自车辆动力学模型）。输出为：发动机扭矩指令、电机扭矩指令和模式标志位。通过Simulink的Bus对象将多个输出打包，便于后续传递给发动机控制器和电机控制器。在仿真验证中，我们设置了三种典型工况：城市低速行驶（纯电模式）、高速巡航（混合模式）、爬坡（充电模式），验证了状态切换的平滑性和电池保护的及时性。
4.5 常见误区与建模规范总结
在Stateflow建模实践中，以下误区需要特别注意：状态爆炸——当状态数量超过10个时，应考虑使用层次化或并行分解重构；隐式事件——避免在转移条件中直接使用Simulink信号边沿，应显式定义事件；动作副作用——during动作中不应包含耗时操作（如复杂计算），否则会影响实时性；数据类型不匹配——状态变量应使用枚举类型，避免使用魔法数字。
建模规范方面，建议遵循以下原则：每个状态图应有清晰的注释说明其功能；状态命名采用大写字母加下划线（如STATE_RUN）；转移条件使用有意义的变量名（如speed > 50而非x > 50）；所有输入输出端口应在Simulink模型中显式标注数据类型和单位。这些规范不仅提高了模型的可读性，也为后续的代码审查和功能安全认证（如ISO 26262）奠定了基础。