状态机基础：状态、事件、转移、动作的定义，以及状态机的分类（Moore/Mealy、FSM/HSM）

状态机（State Machine）是嵌入式系统、通信协议、UI交互逻辑和硬件控制中最核心的建模工具之一。它通过“状态—事件—转移—动作”四要素，将复杂的时序逻辑和条件响应转化为可验证、可维护的离散模型。本章将深入剖析这四个基本概念的精确定义与工程含义，并系统梳理Moore与Mealy两种输出模型的差异，以及有限状态机（FSM）与层次状态机（HSM）在工程实践中的选型依据。理解这些基础，是后续进行状态建模、代码生成和验证测试的基石。

2.1 核心概念精讲：状态、事件、转移、动作

2.1.1 状态（State）——系统的稳定快照

状态是状态机中最基本的元素，它表示系统在某一时刻所处的稳定情形。在工程实践中，状态应当满足三个特征：可区分性（不同状态必须有明确的边界）、可记忆性（状态本身隐含了历史信息的累积）、可观测性（至少存在一种方式判断当前处于哪个状态）。例如，一个串口接收模块的状态可以是“空闲”“接收中”“校验中”“帧完成”，每个状态对应不同的内部变量组合和外部行为表现。

状态的设计需要遵循“高内聚、低耦合”原则。一个常见的错误是将状态设计得过于细碎，导致状态数量爆炸；另一个极端是状态过于粗放，使得转移条件复杂难懂。好的状态设计应当让每个状态内部的逻辑相对独立，状态之间的转移路径清晰。

2.1.2 事件（Event）——驱动转移的触发器

事件是导致状态机从当前状态转移到另一个状态的外部或内部刺激。事件可以是异步信号（如GPIO中断、定时器超时）、同步信号（如时钟上升沿）、数据条件（如接收缓冲区达到阈值）或内部消息（如任务完成通知）。在建模时，事件通常被抽象为枚举类型或消息ID。

事件与状态转移的关系需要特别注意：同一事件在不同状态下可能触发不同的转移，甚至可能被忽略（即事件被消费但不产生转移）。例如，在UART接收状态机中，“收到字节”事件在“空闲”状态会触发转移到“接收中”，但在“校验中”状态可能只是追加数据而不改变状态。

2.1.3 转移（Transition）——状态间的路径规则

转移定义了状态机在特定事件驱动下从源状态到目标状态的跳转逻辑。一个完整的转移包含五个要素：源状态、目标状态、触发事件、守卫条件（Guard）、动作（Action）。守卫条件是一个布尔表达式，只有事件发生且守卫条件为真时，转移才真正执行。例如，在电梯控制系统中，“到达楼层”事件只有在“当前楼层=目标楼层”的守卫条件下才会触发“开门”转移。

转移的完备性检查是状态机设计中的关键环节。每个状态都必须明确列出所有可能事件的响应方式，包括“忽略”或“报错”。遗漏转移是导致系统进入未知状态的常见原因。

2.1.4 动作（Action）——转移的执行效应

动作是状态机在转移过程中执行的具体操作，它可以是：输出信号（如拉高GPIO）、变量赋值（如计数器清零）、调用函数（如启动DMA传输）、发送消息（如通知其他任务）。动作的执行时机有三种：进入状态时（Entry Action）、退出状态时（Exit Action）、转移过程中（Transition Action）。

在工程实践中，推荐使用“进入动作”来初始化状态相关的资源，使用“退出动作”来释放资源或保存现场。这样可以将状态内部的逻辑与转移逻辑解耦，提高代码的可维护性。

2.2 状态机分类：Moore与Mealy

2.2.1 Moore型状态机——输出仅由状态决定

Moore型状态机的输出信号只依赖于当前状态，与输入事件无关。这意味着输出是状态的函数：Output = f(State)。这种模型的优点是输出稳定、无毛刺，因为输出在状态转移完成后才更新；缺点是输出对输入的响应存在一个时钟周期的延迟。Moore型适合输出信号需要保持稳定的场景，如LED状态指示、电源管理模式切换。

2.2.2 Mealy型状态机——输出由状态和输入共同决定

Mealy型状态机的输出同时依赖于当前状态和当前输入事件：Output = f(State, Event)。这种模型响应速度快，输入变化立即反映到输出；但缺点是输出可能产生毛刺，且组合逻辑复杂。Mealy型适合对时序响应要求高的场景，如通信协议中的应答信号生成。

2.3 状态机分类：FSM与HSM

2.3.1 有限状态机（FSM）——扁平化建模

经典FSM将所有状态放在同一层次中，状态之间通过转移直接连接。这种模型直观、易于实现，适合状态数量较少（通常少于20个）且状态间关系简单的场景。FSM的实现方式包括switch-case、状态转移表、函数指针数组等。其局限性在于：当系统复杂度上升时，状态数量急剧膨胀，转移关系变得混乱，且无法表达“状态共享行为”。

2.3.2 层次状态机（HSM）——嵌套与继承

HSM引入了状态的层次结构，允许一个状态包含子状态（嵌套状态），子状态可以继承父状态的转移和动作。这种模型极大地减少了重复逻辑，提高了可维护性。例如，在通信协议栈中，“连接建立”状态可以包含“TCP握手”“TLS协商”“应用层认证”三个子状态，而“超时重传”的公共处理逻辑可以放在父状态中。

HSM的转移规则更加丰富：局部转移（仅在子状态内部跳转）、全局转移（从任意子状态直接跳转到其他高层状态）、历史状态（记住上次退出的子状态，重新进入时恢复）。这些特性使得HSM非常适合复杂控制逻辑，如无人机飞控、自动驾驶状态管理。

2.4 实战案例：智能门锁状态机设计

下面通过一个智能门锁的案例，综合展示本章概念的应用。系统需求：支持密码输入、指纹识别、远程开锁三种方式；连续5次验证失败则锁定30秒；具备低电量报警功能。

初始现象与约束：门锁MCU资源有限（Flash 32KB，RAM 4KB），要求状态机代码可读性强、便于后续添加新功能（如NFC开锁）。

状态定义：

• IDLE：待机状态，等待用户操作
• PASSWORD_CHECK：密码校验中
• FINGERPRINT_CHECK：指纹校验中
• UNLOCKED：已开锁
• LOCKED_OUT：锁定状态（30秒）
• LOW_BATTERY：低电量告警（可与其他状态并行）

事件定义：密码输入完成、指纹采集完成、远程开锁指令、验证失败、验证成功、定时器超时。

转移与动作设计（节选）：

// 伪代码示例
STATE(IDLE) {
  EVENT(密码输入完成) {
    GUARD(输入长度==6);
    ACTION(读取密码缓存);
    TRANSIT(PASSWORD_CHECK);
  }
  EVENT(指纹采集完成) {
    ACTION(启动指纹比对);
    TRANSIT(FINGERPRINT_CHECK);
  }
}
STATE(PASSWORD_CHECK) {
  ENTRY_ACTION(启动500ms超时定时器);
  EVENT(验证成功) {
    ACTION(驱动电机开锁);
    TRANSIT(UNLOCKED);
  }
  EVENT(验证失败) {
    ACTION(失败计数++);
    GUARD(失败计数>=5);
    ACTION(启动30s锁定定时器);
    TRANSIT(LOCKED_OUT);
  }
  EVENT(定时器超时) {
    ACTION(清空输入缓存);
    TRANSIT(IDLE);
  }
}

分析判断过程：该设计采用Moore型输出模型，因为“UNLOCKED”状态的输出（电机驱动信号）仅由状态决定，避免在验证成功瞬间产生输出毛刺。同时，将“低电量”设计为并行区域（HSM的Orthogonal Region），避免与主状态逻辑耦合。

结果对比与复盘：采用HSM后，状态数量从扁平FSM的12个减少到8个（含子状态），重复的“超时返回IDLE”逻辑被提取到父状态中。代码量减少约30%，且新增“NFC开锁”功能时只需增加一个子状态和两条转移，无需修改现有逻辑。风险点在于：锁定状态的定时器需要独立管理，避免在低电量告警时被意外重置。

2.5 常见误区与设计要点

• 误区一：状态与条件混淆。状态是持久的稳定阶段，而条件是一次性的判断。例如“正在等待ACK”是状态，“ACK已收到”是事件或条件，不应将条件作为状态。
• 误区二：忽略守卫条件。两个状态之间可能有多条转移路径，必须通过守卫条件区分。否则会出现“事件冲突”导致状态机行为不确定。
• 误区三：动作执行时机不明确。必须明确动作是Entry、Exit还是Transition Action。推荐在状态图中使用“/”符号标注动作类型，如“EVT_TIMEOUT / 清空缓存 / TRANSIT(IDLE)”。
• 误区四：FSM与HSM选型不当。状态少于10个且无共享行为时，强行使用HSM反而增加理解成本；状态超过20个且存在公共处理逻辑时，继续使用扁平FSM会导致维护噩梦。

在实际工程中，建议在项目初期使用状态转移图（State Diagram）进行可视化建模，并借助工具（如Stateflow、Yakindu、PlantUML）进行仿真验证。状态机的可测试性设计同样重要：应提供状态查询接口和事件注入接口，便于在HIL（硬件在环）测试中自动化验证。