3. Stateflow入门：Stateflow图表创建、状态与转移、事件驱动机制、与Simulink的接口

Stateflow是MathWorks公司提供的基于有限状态机（FSM）和流程图建模的工具，它嵌入在Simulink环境中，用于描述复杂的逻辑决策、状态转换和事件响应行为。在工程实践中，当控制逻辑涉及模式切换、故障保护、顺序调度或状态记忆时，纯Simulink的连续/离散模块往往难以清晰表达，而Stateflow则能以图形化的方式直观呈现这些逻辑。本章将围绕Stateflow图表的创建流程、状态与转移的核心语义、事件驱动机制的本质，以及它与Simulink主引擎之间的数据交互接口展开，帮助读者建立从“画框图”到“工程建模”的完整认知。

上图展示了Stateflow在Simulink环境中的核心位置与交互关系。左侧是Simulink主引擎提供的信号源、执行器接口和连续/离散计算模块；中间是Stateflow图表，内部包含状态、转移、事件和数据接口；右侧则是后续代码生成与验证的延伸。理解这张图，就掌握了本章的全局脉络。

3.1 Stateflow图表创建：从模型到状态机

3.1.1 核心原理：Stateflow图表的本质

Stateflow图表本质上是一个有限状态机（FSM）的图形化实现。它允许工程师将复杂的逻辑分解为若干个离散的“状态”（State），并通过“转移”（Transition）描述状态之间的切换条件。每个状态可以包含进入（entry）、持续（during）、退出（exit）三种基本动作，分别对应状态激活瞬间、状态保持期间和状态离开瞬间需要执行的操作。这种“状态+动作”的建模方式，特别适合描述模式切换、故障处理、协议解析等具有明确离散特征的逻辑。

在Simulink中创建Stateflow图表的操作路径为：在Simulink库浏览器中拖入“Stateflow Chart”模块，或直接使用MATLAB命令行输入sfnew创建新模型。双击图表模块即可进入Stateflow编辑器，开始绘制状态和转移。

3.1.2 操作流程：创建第一个Stateflow图表

1. 新建模型：在MATLAB命令窗口输入sfnew，或通过Simulink工具栏“新建→Stateflow Chart”创建。
2. 添加状态：在编辑器左侧工具栏选择“State”图标，在画布上拖拽绘制矩形状态框。双击状态框可命名并编辑动作。
3. 绘制转移：使用“Transition”工具，从源状态边缘拖拽箭头到目标状态边缘。转移上可标注条件（如[x > 5]）和转移动作（如{y = 1;}）。
4. 设置默认转移：每个图表必须有一个默认转移（带空心圆箭头的转移），用于指定初始激活状态。
5. 定义输入输出：通过“符号”面板（Symbols Pane）添加输入、输出、局部变量和参数。输入输出变量需与Simulink端口关联。
6. 仿真验证：返回Simulink模型，连接信号源和示波器，运行仿真观察状态切换是否满足预期。

3.1.3 案例拆解：电机控制模式切换

以一个直流电机控制为例，我们需要实现三种模式：待机（Idle）、加速（Accelerating）和恒速（Cruising）。输入信号为速度参考值speed_ref和启动指令start_cmd，输出为PWM占空比duty。

初始状态为Idle。当start_cmd == 1时，转移到Accelerating，在entry动作中设置duty = 0.6。在Accelerating状态中，通过during动作持续检测当前速度speed，当speed >= speed_ref * 0.95时，转移到Cruising，并在entry动作中设置duty = 0.3（维持恒速）。若start_cmd == 0，则从任何状态直接回到Idle，并在exit动作中清零duty。

这个案例展示了Stateflow处理“事件触发+条件判断+动作执行”的典型模式。相比用Simulink逻辑模块搭建，Stateflow的图形化表达让模式切换一目了然，且易于修改和扩展。

3.1.4 常见误区与总结

• 误区一：状态数量过多。有些工程师将连续变化的值也建模为状态，导致状态爆炸。正确做法是：只有离散的、互斥的模式才适合作为状态。
• 误区二：忽略默认转移。没有默认转移的图表在仿真时会报错，因为Simulink不知道初始激活哪个状态。
• 误区三：在状态动作中编写复杂算法。Stateflow适合逻辑控制，不适合数值计算。复杂算法应放在Simulink模块中，Stateflow只做决策。

3.2 状态与转移：深入理解语义

3.2.1 核心原理：状态动作的执行时序

Stateflow的状态动作执行遵循严格的时序逻辑。当一个状态被激活时，首先执行其entry动作；在状态保持期间，每个仿真步长执行一次during动作；当状态被转移离开时，执行exit动作。理解这个时序是调试Stateflow逻辑的基础。

转移的执行优先级为：首先检查是否存在由事件触发的转移，然后评估转移条件。如果多个转移同时满足条件，则根据转移的“执行顺序”（即绘制时的先后顺序，或通过“Execution Order”属性指定）决定优先级。默认情况下，Stateflow按照转移在图表中的几何位置从上到下、从左到右评估。

3.2.2 判断方法：转移条件与动作的编写规范

转移条件使用方括号[ ]包裹，内部为逻辑表达式，例如[x > 3 && y < 10]。转移动作使用花括号{ }包裹，在转移发生时执行，例如{counter = 0;}。条件动作（Condition Action）则写在条件之后、转移动作之前，用{ }包裹，仅在条件为真且转移被激活时执行。

一个完整的转移标注格式为：事件[条件]{条件动作}/{转移动作}。例如：E1[temp > 100]{alarm = 1;}/{state_count++;}。其中事件E1触发后，若temp > 100为真，则先执行alarm = 1，再执行state_count++，最后完成状态切换。

3.2.3 实战场景：交通信号灯控制器

设计一个十字路口交通信号灯控制器，包含四个状态：NS_Green（南北绿灯）、NS_Yellow（南北黄灯）、EW_Green（东西绿灯）、EW_Yellow（东西黄灯）。使用一个周期为1秒的时钟信号clk作为事件源。

在NS_Green状态中，设置一个局部变量timer，在during动作中执行timer++。当timer >= 30时，转移到NS_Yellow，并在entry动作中重置timer = 0。NS_Yellow持续5秒后转移到EW_Green。以此类推。通过这个案例，可以清晰看到“时间驱动+状态记忆”的建模方式。

3.2.4 常见误区与总结

• 误区一：混淆“条件动作”和“转移动作”。条件动作在条件满足时立即执行，即使转移最终未发生（例如被更高优先级的转移抢占）；转移动作仅在转移真正执行时运行。
• 误区二：忽略状态内部的历史节点。对于包含子状态的状态，可以使用历史节点（History Junction）记录上次激活的子状态，但需谨慎使用，否则容易导致逻辑混乱。
• 误区三：过度使用“during”动作。如果during动作中执行了耗时操作，会拖慢仿真速度。建议将复杂计算放在Simulink模块中，Stateflow只做判断和赋值。

3.3 事件驱动机制：让逻辑响应外部变化

3.3.1 核心原理：事件与触发

Stateflow的事件（Event）是一种异步或同步的触发机制，用于激活转移评估。事件分为三类：输入事件（由Simulink信号上升沿/下降沿触发）、输出事件（由Stateflow发送给Simulink，用于触发其他模块）、局部事件（在图表内部广播，用于状态间通信）。

输入事件通过Simulink中的“Function Call”或“Trigger”端口接入。例如，一个脉冲信号可以配置为上升沿触发事件RISE_E。当该事件发生时，Stateflow会立即评估所有以该事件为条件的转移。输出事件则通过Stateflow的“Output Event”端口发送到Simulink，可用于触发子系统执行。

3.3.2 操作流程：配置事件驱动

1. 在Stateflow编辑器中，通过“符号”面板添加事件，类型选择“Input”或“Output”。
2. 对于输入事件，在Simulink中双击Stateflow模块，在端口列表中勾选对应的事件端口，并连接信号源。
3. 在转移标注中，将事件名称写在条件之前，例如RISE_E[cond]。
4. 对于局部事件，在状态动作中使用broadcast(event_name)函数广播，其他状态可响应此事件。

3.3.3 案例拆解：按键消抖与长按检测

在嵌入式系统中，按键输入需要消抖和长按检测。使用Stateflow可以优雅地实现：输入事件KEY_PRESS由按键信号的上升沿触发。状态Wait等待按键事件，一旦触发则转移到Debounce状态，在entry动作中启动一个计数器cnt = 0。在Debounce状态的during动作中，若cnt < 5则cnt++，否则转移到Confirm状态，表示按键有效。在Confirm状态中，若持续按住超过50个时钟周期，则触发长按事件LONG_PRESS，否则在释放时回到Wait状态。

这个案例展示了事件驱动与时间逻辑的结合。相比纯Simulink实现，Stateflow的层次化状态结构让消抖和长按检测逻辑清晰分离，便于维护和参数调整。

3.3.4 常见误区与总结

• 误区一：滥用事件。事件驱动会增加模型复杂度，如果逻辑可以简单地用条件判断实现，就不必引入事件。
• 误区二：忽略事件优先级。当多个事件同时到达时，Stateflow按照事件在图表中的声明顺序处理。需通过“Event Priority”属性显式指定。
• 误区三：在输出事件中传递数据。输出事件只传递触发信号，不携带数据。如需传递数据，应使用输出端口变量。

3.4 与Simulink的接口：数据交互与集成

3.4.1 核心原理：数据接口类型

Stateflow与Simulink之间的数据交互通过端口和变量实现。主要接口类型包括：Input（从Simulink读取信号）、Output（输出到Simulink）、Local（图表内部使用）、Parameter（从MATLAB工作空间或模型参数获取）。

在Simulink中，Stateflow模块的端口数量由输入输出变量的个数决定。每个输入输出变量对应一个端口，端口数据类型可以是double、single、int8、boolean等，也可以是Simulink总线（Bus）对象。参数则通过“Parameter”类型变量引用，可在模型初始化时从工作空间加载。

3.4.2 操作流程：建立数据连接

1. 在Stateflow符号面板中，添加输入变量speed，类型为double，作用域为Input。
2. 添加输出变量duty，类型为double，作用域为Output。
3. 返回Simulink模型，Stateflow模块自动显示两个端口：speed和duty。
4. 使用Simulink信号线连接传感器输出到speed端口，连接duty端口到执行器模型。
5. 在Stateflow图表中，直接使用变量名speed和duty进行读写。

3.4.3 实战场景：电池管理系统（BMS）状态机

在BMS中，需要根据电池电压、电流和温度实时判断工作状态。输入变量包括：voltage（V）、current（A）、temp（℃）。输出变量包括：relay_cmd（继电器控制）、fault_code（故障码）。

状态包括：Normal（正常）、Overvoltage（过压）、Undervoltage（欠压）、Overtemp（过温）、Fault（故障锁定）。在Normal状态中，持续监测输入变量，当voltage > 4.2时转移到Overvoltage，并输出relay_cmd = 0（断开继电器）。在Overvoltage状态中，若电压回落到voltage < 4.0，则回到Normal。若温度超过temp > 60，则进入Overtemp状态。任何状态下若检测到硬件故障（如电流突变），则进入Fault状态并锁定，需人工复位。

这个案例中，Stateflow与Simulink的接口承担了实时数据采集和控制指令输出的任务。通过Simulink的Scope模块可以观察状态切换过程，通过“Signal Logging”可以记录状态序列用于后续分析。

3.4.4 常见误区与总结

• 误区一：数据类型不匹配。Simulink信号线默认double类型，但Stateflow内部变量可能定义为int8，导致隐式转换错误。建议在符号面板中显式设置数据类型，并启用“Data Type Conversion”模块。
• 误区二：忽略采样时间。Stateflow默认继承Simulink的采样时间。如果输入信号是连续时间，而Stateflow需要离散采样，需在模块参数中设置采样时间，否则可能导致代数环。
• 误区三：参数未初始化。Parameter类型的变量如果在MATLAB工作空间中不存在，仿真会报错。建议在模型回调函数（如InitFcn）中初始化所有参数。