课程导入：Stateflow与Simulink联合开发的价值、典型应用场景、课程学习路径与目标
在工业自动化、汽车电子、航空航天与机器人控制等领域的复杂逻辑系统开发中，工程师常常面临一个核心矛盾：控制算法（如PID、滤波、状态观测器）可以借助Simulink的连续与离散模块高效搭建，但系统的决策逻辑、模式切换、故障保护与状态机管理却难以用纯数据流模型清晰表达。Stateflow正是为解决这一矛盾而生的图形化建模工具，它基于有限状态机（FSM）与流程图理论，允许工程师以状态转移图、时序图、真值表等形式描述事件驱动逻辑。当Stateflow与Simulink联合使用时，二者形成互补：Simulink负责连续/离散动态系统的数学运算与信号流，Stateflow负责事件驱动的模式管理与逻辑决策，从而构建出完整、可仿真、可生成嵌入式代码的混合系统模型。本课程将系统讲解这一联合开发方法，从基础概念到工程实战，帮助学习者掌握从模型设计到代码生成的全链路技能。
一、核心原理：为什么需要联合开发
Simulink与Stateflow的联合开发并非简单的工具叠加，而是基于两种建模范式的本质互补。Simulink采用数据流驱动模型，每个模块在仿真步长内根据输入信号计算输出，适合描述连续时间动态、离散采样控制以及代数运算关系。然而，当系统存在多种工作模式（如启动、运行、待机、故障保护）、需要响应离散事件（如按钮按下、传感器超限、通信超时）或要求执行顺序决策时，纯Simulink模型会退化为大量Switch模块与逻辑门电路，导致模型可读性急剧下降、维护成本升高。
Stateflow则基于有限状态机理论，将系统行为建模为有限个状态（State）与状态之间的转移（Transition）。每个状态可以包含进入动作（entry）、驻留动作（during）和退出动作（exit），转移条件由事件、条件表达式和时间逻辑组合触发。这种建模方式天然适合描述离散事件系统与混合逻辑。联合开发的核心价值在于：Simulink提供连续/离散动态的数值计算引擎，Stateflow提供事件驱动的逻辑决策引擎，二者通过输入输出端口、事件广播和共享变量进行双向交互。例如，一个电机控制系统，Simulink负责电流环与速度环的PID运算，Stateflow负责启停控制、正反转切换、过流保护等逻辑决策，两者协同完成完整的控制闭环。
二、判断方法与建模决策：何时使用Stateflow
在实际工程中，工程师需要判断哪些逻辑适合放入Stateflow，哪些应保留在Simulink中。以下提供一套实用的判断流程：
- 检查是否存在显式状态：如果系统行为可以划分为若干互斥的工作模式（如手动/自动、正常/降级/故障），且模式切换由事件触发，则适合使用Stateflow。
- 检查是否存在顺序逻辑：如果系统需要按步骤执行（如启动序列：先上电→再自检→然后使能输出），Stateflow的流程图（Graphical Function）可以清晰表达。
- 检查是否存在复杂条件组合：当转移条件涉及多个信号的逻辑组合（如温度>80℃且压力>2MPa且使能信号为真），Stateflow的条件表达式比Simulink的Logic模块更直观。
- 检查是否存在时间逻辑：Stateflow支持after(n, tick)、temporalCount等时间操作符，适合描述延时、超时、定时等逻辑。
- 如果以上均为否：则使用Simulink原生模块即可，避免过度设计。
| 判断维度 | 适合Simulink | 适合Stateflow |
|---|---|---|
| 信号类型 | 连续信号、采样信号、数值运算 | 离散事件、布尔条件、状态枚举 |
| 系统行为 | 线性/非线性动态、传递函数 | 模式切换、顺序流程、故障处理 |
| 触发方式 | 采样时间驱动、连续时间积分 | 事件驱动、条件触发、时间逻辑 |
| 可维护性 | 适合数学算法迭代 | 适合逻辑审查与变更管理 |
| 代码生成 | 生成C代码的数学函数部分 | 生成C代码的状态机部分 |
三、案例拆解：汽车自动空调控制系统的联合建模
为深入理解联合开发的价值，我们以一个汽车自动空调系统为例。该系统需要根据车内温度、车外温度、用户设定温度以及压缩机状态，自动调节鼓风机风速、压缩机启停和内外循环模式。系统包含四个主要工作模式：关闭模式（用户关闭空调）、手动模式（用户手动设定风速与温度）、自动模式（系统自动调节）和故障模式（压缩机过压或传感器失效时进入）。
初始现象与目标：使用纯Simulink建模时，模式切换逻辑需要约15个Switch模块和8个逻辑门，模型混乱且难以调试。目标是通过Stateflow重构逻辑层，使模式管理清晰化，同时保留Simulink中的温度计算模型与风机控制模型。
关键输入数据：车内温度（连续信号，范围-10℃~50℃）、车外温度（连续信号）、设定温度（用户输入，16℃~32℃）、压缩机电流（模拟量，用于过流检测）、蒸发器温度（用于防冰保护）。
分析判断过程：首先识别出四个互斥状态，每个状态有明确的进入条件和退出条件。例如，从自动模式切换到故障模式的条件是压缩机电流>15A持续2秒（用after(2,sec)实现）。从手动模式切换到自动模式的条件是用户按下AUTO键（事件触发）。在Stateflow中，每个状态内部可以调用Simulink函数（通过Stateflow的Simulink函数调用接口），例如在自动模式中调用温度控制算法模块。
实际操作步骤：
- 在Simulink模型中添加Stateflow Chart模块，命名为AC_Logic。
- 定义输入事件：AUTO_BTN、OFF_BTN、MANUAL_BTN；定义输入数据：compressor_current、evap_temp；定义输出数据：blower_speed、compressor_on、recirc_mode。
- 创建四个状态，使用默认转移（Default Transition）指向关闭模式。
- 在关闭模式中，当AUTO_BTN事件发生时，转移到自动模式；当MANUAL_BTN事件发生时，转移到手动模式。
- 在自动模式中，使用during动作调用Simulink函数计算目标风速，并检测故障条件。
- 在故障模式中，强制关闭压缩机，并点亮故障灯（输出到Simulink显示）。
结果对比：重构后，模型中的逻辑模块数量从23个减少到6个，仿真速度提升约15%，且通过Stateflow的模型检查器可以自动验证状态可达性，避免了死锁和不可达状态。后续维护时，新增一个“经济模式”只需在Stateflow中增加一个状态和若干转移，无需改动Simulink中的控制算法。
风险与代价：联合建模初期需要额外学习Stateflow的语法与执行语义，且状态图与Simulink模块之间的接口定义需要仔细设计，否则可能出现信号类型不匹配或事件丢失问题。建议在项目启动时先建立接口规范文档。
四、常见误区与总结复盘
在初学者和中级工程师的实践中，以下误区最为常见：
- 误区一：将所有逻辑都放入Stateflow。有些工程师习惯将PID参数切换、滤波器选择等数值逻辑也放入状态机，导致状态图臃肿且难以调试。正确做法是：数值计算留在Simulink，Stateflow只负责决策与模式管理。
- 误区二：忽略事件与数据的作用域。Stateflow中的事件可以是局部事件（仅Chart内部使用）或输入事件（从Simulink触发），数据也有局部、输入、输出、参数等不同作用域。混淆作用域会导致仿真结果与预期不符，且难以排查。
- 误区三：状态转移条件过于复杂。一个转移条件中堆砌超过5个逻辑表达式时，可读性急剧下降。建议将复杂条件拆分为多个中间状态或使用Stateflow的图形函数（Graphical Function）封装。
- 误区四：忽视状态转移的优先级。当多个转移条件同时为真时，Stateflow按照转移的拓扑顺序执行。工程师需要理解“从上到下、从左到右”的优先级规则，否则可能触发非预期转移。