第4章 Stateflow状态机建模

Stateflow，说白了就是给嵌入式工程师用的“画图编程”工具。你想想看，传统的C代码里写状态机，一堆switch-case嵌套，改一个状态就得翻半天代码。Stateflow把这套逻辑可视化，状态怎么跳、事件怎么触发，一目了然。

我个人习惯把Stateflow看作是Simulink的“大脑”。Simulink处理连续信号，Stateflow处理离散逻辑。两者配合，才能搞定一个完整的ECU功能。

4.1 Stateflow基础概念

先搞清楚几个核心概念：

状态（State）：系统在某个时刻所处的模式。比如车窗“正在上升”、“停止”、“正在下降”。
转移（Transition）：从一个状态切换到另一个状态的条件。比如“上升到位”这个事件触发，从“上升”转移到“停止”。
事件（Event）：触发转移的外部或内部信号。比如按键按下、传感器信号跳变。
动作（Action）：进入、退出或停留在某个状态时执行的操作。比如进入“上升”状态时，给电机输出PWM。

核心要点：Stateflow里，状态是“持久”的，转移是“瞬时”的。状态会一直保持，直到某个事件触发转移发生。

我记得刚接触Stateflow时，总把状态和动作搞混。后来想明白一个道理：状态是“是什么”，动作是“做什么”。车窗处于“上升”状态，它执行的动作是“输出上升信号”。

4.2 状态与转移

状态和转移是Stateflow的骨架。我一般这样设计：

先画状态：把系统所有可能的模式列出来。别漏了“初始化”和“故障”状态。
再画转移：确定状态之间怎么跳。每个转移都要有触发条件。
最后填动作：进入状态做什么？退出状态做什么？状态保持时做什么？

举个例子，一个简单的车窗控制状态机：

// 伪代码逻辑，对应Stateflow图
状态：Idle（空闲）
  进入动作：电机停止
  转移条件：按键UP按下 -> 状态Rising

状态：Rising（上升）
  进入动作：电机正转
  转移条件：到达上限位 -> 状态Idle
  转移条件：按键DOWN按下 -> 状态Falling

状态：Falling（下降）
  进入动作：电机反转
  转移条件：到达下限位 -> 状态Idle
  转移条件：按键UP按下 -> 状态Rising

个人经验：画转移时，一定要考虑“所有可能的情况”。我曾经漏掉一个“同时按下UP和DOWN”的转移，结果台架测试时电机直接卡死。后来我加了一条规则：同时按下时，优先执行下降（安全考虑）。

4.3 事件驱动建模

事件驱动，说白了就是“有事才干活”。没有事件发生时，状态机保持当前状态，不执行任何转移。

Stateflow支持三种事件：

事件类型	说明	典型应用
输入事件	来自Simulink的信号边沿	按键按下、传感器触发
输出事件	Stateflow发出的信号	触发Simulink子系统
本地事件	状态机内部广播	状态间通信、超时触发

我建议把事件和条件分开理解：事件是“什么时候”触发，条件是“能不能”触发。比如“按键按下”是事件，“车速小于5km/h”是条件。两者结合，才能决定转移是否发生。

为什么会这样设计？你想想看，如果只有事件没有条件，那每次按键按下都会触发转移，不管车速多快。这在雨刮控制里很危险——高速行驶时误触雨刮，可能影响视线。

4.4 层次化状态机设计

这是Stateflow最强大的功能。层次化，就是状态里嵌套状态。我刚开始觉得这玩意儿花里胡哨，直到项目越来越复杂...

举个例子，雨刮控制：

顶层状态：Off（关闭）、Auto（自动）、Manual（手动）
Auto状态内部：又分为LowSpeed（低速）、HighSpeed（高速）、Intermittent（间歇）
Intermittent状态内部：又分为Wait（等待）、Wipe（刮刷）

这种层次结构的好处是：父状态管理公共逻辑，子状态管理细节。比如“Auto”状态有一个公共的退出动作：关闭雨刮电机。那么它下面的所有子状态退出时，都会自动执行这个动作。

避坑指南：我曾经在层次化状态机里犯过一个低级错误——父状态和子状态定义了同名的转移条件。结果子状态的转移永远不触发，因为父状态先“吃掉”了事件。后来我养成了一个习惯：子状态的事件尽量用本地事件，避免和父状态冲突。

4.5 典型应用场景：车窗控制

车窗控制是Stateflow入门的经典案例。我一般这样设计：

主状态机：Idle、Rising、Falling、AntiPinch（防夹）
防夹逻辑：在Rising状态检测电流异常，触发转移到AntiPinch状态
超时保护：每个状态都加一个超时转移，防止电机堵转

这里有个细节：防夹功能不能随便触发。我记得有一次测试，车窗导轨有点脏，正常上升时电流稍微偏大，结果防夹误触发了。后来我加了一个“持续检测100ms”的条件，才解决这个问题。

4.6 典型应用场景：雨刮控制

雨刮控制比车窗复杂一些，因为有多个工作模式：

Off：雨刮停止，回到初始位置
Intermittent：间歇刮刷，间隔时间可调
Low：低速连续刮刷
High：高速连续刮刷
Mist：单次刮刷（拨杆向上推一下）
Auto：根据雨量传感器自动调节

我个人习惯把Auto模式做成层次化状态机：

状态：Auto
  子状态：Idle（无雨）
  子状态：LightRain（小雨）- 间歇刮刷
  子状态：MediumRain（中雨）- 低速连续
  子状态：HeavyRain（大雨）- 高速连续
  
  转移条件：
    雨量传感器值 < 10 -> Idle
    雨量传感器值 10~30 -> LightRain
    雨量传感器值 30~60 -> MediumRain
    雨量传感器值 > 60 -> HeavyRain

经验之谈：雨刮的“回位”逻辑一定要处理好。很多新手会忽略这个——雨刮关闭时，必须等刮臂回到初始位置才能停止供电。我一般用一个单独的“Parking”状态来处理这个逻辑，不管从哪个模式退出，都先进入Parking，等位置传感器确认到位后，再进入Off。

4.7 建模规范与检查清单

最后，分享一份我自己的Stateflow建模检查清单：

状态完整性：所有可能的状态都覆盖了吗？包括故障状态。
转移完备性：每个状态都有出口吗？有没有“死锁”状态？
事件唯一性：同一个事件不会被多个父/子状态同时捕获吗？
动作正确性：进入动作、退出动作、保持动作都写对了吗？
超时保护：每个状态都有超时转移吗？防止硬件故障导致状态卡死。
初始化逻辑：上电后默认进入哪个状态？有没有初始化动作？

嗯，这套清单帮我避免过不少低级错误。有一次评审时，同事发现我漏了一个“电机过热”的故障状态，还好在代码生成前补上了。

Stateflow建模，说白了就是“画图+填逻辑”。但真正的高手，能把图画得清晰、逻辑填得严谨、测试覆盖得全面。希望这一章的内容，能帮你少走一些我当年走过的弯路。

📚 课程目录