4、状态机建模方法：状态图、状态转移表、伪代码，从需求到模型的转换

状态机设计的起点并非代码，而是对系统行为的精确描述。在嵌入式开发中，需求文档往往以自然语言撰写，存在歧义、遗漏和边界条件模糊等问题。建模的目的，就是将非形式化的需求转化为无歧义、可验证、可实现的模型。本章围绕三种核心建模载体——状态图（State Diagram）、状态转移表（State Transition Table）与伪代码（Pseudocode），系统阐述各自的适用场景、构建方法以及从需求到模型的完整转换路径。三种模型并非互斥，而是分别从可视化、结构化、可执行化三个维度互补支撑，共同构成状态机设计的“三视图”。

4.1 状态图：可视化行为全景

4.1.1 核心原理

状态图（UML State Machine Diagram）以图形化方式描述对象在其生命周期内所经历的状态序列，以及响应外部事件时的状态转移。其核心元素包括：状态（State）——对象满足某种条件、等待某个事件或执行某动作时的情形；转移（Transition）——从当前状态到下一状态的路径，由事件触发并可能附带守卫条件与动作；初始状态（Initial State）与终止状态（Final State）——分别标记生命周期的起点与终点。状态图擅长表达层次化状态（父状态嵌套子状态）与并发区域（正交状态），这是表格与伪代码难以直观呈现的。

4.1.2 构建方法

从需求文本中提取状态图元素，建议遵循以下步骤：

1. 圈定状态集合：找出需求中所有“当…时”“在…情况下”“处于…模式”等描述，将其归纳为离散状态。例如，一个智能门锁的需求中，“待机”“验证中”“开锁”“报警”即为候选状态。
2. 识别事件与动作：事件是触发转移的外部或内部信号，如“按键按下”“定时器超时”“传感器触发”；动作是转移过程中执行的操作，如“点亮LED”“发送数据”“启动电机”。
3. 绘制转移路径：对每个状态，逐一考虑每个可能事件，判断是否发生转移、转移到何处、是否附带动作。特别注意自转移（事件发生后仍留在原状态但执行动作）与内部转移（不触发进入/退出行为的转移）。
4. 检查完备性：每个状态必须明确所有可能事件的处理方式，包括“未定义事件”的默认行为（忽略或报错）。

4.1.3 案例拆解：智能门锁状态图

考虑一个低功耗智能门锁，需求描述如下：“门锁平时处于待机状态，低功耗运行。用户按下指纹传感器时，进入验证状态，此时启动指纹比对算法。若比对成功，进入开锁状态，驱动电机转动开锁，3秒后自动回到待机。若比对失败，进入报警状态，蜂鸣器鸣响5秒，然后回到待机。任何时候检测到暴力撬锁信号，立即进入报警状态。” 该需求可绘制为包含4个状态、5个转移的状态图。状态图直观展示了从待机出发的两条主要路径（成功/失败），以及一个异步闯入事件（撬锁）如何打断当前状态强制进入报警。评审时，团队成员能一眼看出“验证状态下若再次按下指纹如何处理”这一未定义场景——这正是状态图可视化带来的查漏价值。

4.1.4 常见误区

• 状态粒度过粗或过细：将“正在处理”作为单一状态，掩盖了内部多个子阶段；或将每个函数调用都设为状态，导致状态爆炸。判断标准：状态是否具有可观测的、对外部事件响应不同的行为。
• 遗漏初始与终止状态：嵌入式系统多为循环运行，但初始化状态与故障终止状态必须明确。
• 忽略守卫条件：同一事件在不同条件下应转移到不同状态，必须用守卫条件（如“温度 > 80℃”）区分，而非画成两条无条件转移。

4.2 状态转移表：结构化完备性验证

4.2.1 核心原理

状态转移表以二维矩阵形式，将当前状态作为行、事件作为列，交叉单元格填写“转移目标状态/动作”。其最大优势在于穷举性——表格强制设计者回答每个状态×每个事件的组合，从而暴露未定义转移。对于状态数不超过10个、事件数不超过8个的中小型状态机，转移表是最有效的完备性检查工具。

4.2.2 构建与检查流程

上表为智能门锁的状态转移表。填写过程中发现两个需求未覆盖的场景：①验证状态下再次按下指纹——设计决定“忽略并重新计时”；②验证状态增加超时保护（5秒无结果自动回待机），防止算法卡死。这些补全正是转移表的核心价值。

4.2.3 操作要点

• 每个单元格必须填写：目标状态（或“—”表示不可能）、动作（可为空）。
• 使用“—”时需注明理由（如“该事件在此状态物理上不可能发生”），而非简单留空。
• 对于“忽略”事件，建议显式标注“忽略”，避免与“未定义”混淆。
• 转移表完成后，与状态图交叉核对：图中每条转移必须在表中有对应项，表中每个非空项必须在图中存在路径。

4.3 伪代码：从模型到代码的桥梁

4.3.1 核心原理

伪代码以接近高级语言的描述性语法，将状态转移逻辑转化为可读、可验证的算法步骤。它不要求严格语法，但必须清晰表达：状态变量、事件检测、转移条件、动作执行顺序。伪代码的价值在于逻辑验证——在编写实际C代码之前，通过“走查”伪代码发现逻辑漏洞，同时为编码提供直接蓝图。

4.3.2 典型结构

// 状态机主循环伪代码
typedef enum { STANDBY, VERIFY, UNLOCK, ALARM } State_t;
State_t current_state = STANDBY;

while (1) {
    Event_t evt = wait_for_event();  // 阻塞或轮询获取事件
    
    switch (current_state) {
        case STANDBY:
            if (evt == FINGER_PRESSED) {
                start_fingerprint_match();
                current_state = VERIFY;
            } else if (evt == TAMPER_SIGNAL) {
                start_buzzer();
                current_state = ALARM;
            }
            // 其他事件忽略
            break;
            
        case VERIFY:
            if (evt == MATCH_SUCCESS) {
                drive_motor_open();
                current_state = UNLOCK;
            } else if (evt == MATCH_FAIL) {
                start_buzzer();
                current_state = ALARM;
            } else if (evt == TIMEOUT_5S) {
                stop_fingerprint_match();
                current_state = STANDBY;
            }
            // FINGER_PRESSED 忽略并重置计时
            break;
            
        case UNLOCK:
            if (evt == TIMEOUT_3S) {
                drive_motor_lock();
                current_state = STANDBY;
            } else if (evt == TAMPER_SIGNAL) {
                start_buzzer();
                current_state = ALARM;
            }
            break;
            
        case ALARM:
            if (evt == TIMEOUT_5S) {
                stop_buzzer();
                current_state = STANDBY;
            }
            break;
    }
}

4.3.3 编写规范与验证方法

编写伪代码时，应遵循以下原则：

1. 状态变量显式化：使用枚举类型定义所有状态，避免魔法数字。
2. 事件检测与处理分离：事件获取（wait_for_event）与状态处理（switch-case）解耦，便于后续替换为中断驱动或RTOS消息队列。
3. 动作函数化：每个动作（如start_buzzer）对应一个函数调用，保持伪代码与最终代码结构一致。
4. 默认分支兜底：每个case必须包含default或显式忽略逻辑，防止未处理事件导致状态机“卡死”。

验证伪代码时，可采用走查法：选取典型场景（如“指纹成功开锁”“连续失败两次”“验证中撬锁”），手动模拟事件序列，逐步跟踪状态与动作变化，与需求预期比对。此过程能发现状态转移表中的逻辑矛盾（如两个事件同时到达时的优先级问题）。

4.3.4 案例复盘：伪代码暴露的优先级问题

在智能门锁的伪代码走查中，发现一个隐蔽问题：当门锁处于VERIFY状态且指纹比对正在进行时，若同时发生TAMPER_SIGNAL和MATCH_SUCCESS，代码按顺序先检查MATCH_SUCCESS，导致门锁进入UNLOCK状态而非ALARM。这在实际系统中是严重安全漏洞。修正方案：在VERIFY状态中，将TAMPER_SIGNAL的检查优先级置于MATCH_SUCCESS之前，或引入事件优先级仲裁机制。该问题在状态图中难以察觉（因为状态图不表达事件同时性），但在伪代码的顺序执行逻辑中暴露无遗。

4.4 从需求到模型的系统化转换流程

4.4.1 五步转换法

4.4.2 转换过程中的关键决策

在转换过程中，设计者需做出若干关键决策，这些决策直接影响模型质量：

• 状态 vs. 标志位：若某个条件仅影响动作执行而不改变对外行为，应使用标志位而非状态。例如“指纹比对算法已初始化”是标志位，不是状态。
• 事件 vs. 条件：事件是瞬时的（如“按键按下”），条件是持续的（如“温度高于阈值”）。条件通常建模为守卫条件，而非事件。
• 动作放置位置：动作可放在转移上（转移动作）、进入状态时（entry）、退出状态时（exit）或状态内部（do活动）。选择原则：动作与状态生命周期绑定则用entry/exit，与转移绑定则用转移动作。

4.4.3 案例闭环：车载车窗防夹控制器

以车窗防夹控制器为例，完整演示转换过程。需求要点：①车窗支持手动/自动升降；②升降过程中检测电机电流，超过阈值判定为防夹触发；③防夹触发后车窗反转下降100ms后停止；④收到停止命令立即停止；⑤系统故障时进入安全模式，禁止升降。

步骤1 需求解析：提取状态——IDLE（待机）、MOVING_UP（上升中）、MOVING_DOWN（下降中）、ANTI_PINCH（防夹反转）、FAULT（故障）。提取事件——CMD_UP、CMD_DOWN、CMD_STOP、CURRENT_HIGH、TIMER_100MS_EXPIRED、FAULT_DETECTED。

步骤2 状态图：绘制6个状态及转移。关键设计：MOVING_UP状态下收到CURRENT_HIGH转移到ANTI_PINCH，同时启动100ms定时器；ANTI_PINCH状态下TIMER_100MS_EXPIRED转移到IDLE。FAULT状态为吸收态，任何状态检测到FAULT_DETECTED均转入。

步骤3 转移表：建立6×6矩阵。填写时发现：MOVING_DOWN状态下收到CURRENT_HIGH如何处理？需求未明确。与系统工程师确认后，决定“下降过程中防夹功能禁用”，故该单元格填“忽略”。此决策记录在表中，避免后续争议。

步骤4 伪代码：编写主循环。走查时发现：若车窗在MOVING_UP状态，同时收到CMD_STOP和CURRENT_HIGH，按代码顺序先处理CMD_STOP，车窗停止，但电流过高信号被丢弃。实际场景中，电机堵转可能持续存在，应在停止后重新检测。修正：在IDLE状态增加“电流过高”事件处理，若持续高电流则直接进入FAULT。

步骤5 需求回溯：逐条核对，确认“防夹触发后反转下降100ms”在伪代码中体现为ANTI_PINCH状态的TIMER_100MS_EXPIRED事件处理。最终模型通过评审，进入编码阶段。

4.4.4 常见误区与应对策略

• 误区一：只画状态图不建转移表——导致大量未定义转移在编码阶段才暴露。应对：强制要求状态数×事件数≤100时必建转移表。
• 误区二：伪代码直接照搬C代码——伪代码应聚焦逻辑而非语法细节，避免过早优化。应对：伪代码中禁止出现指针、内存操作等实现细节。
• 误区三：需求变更后只改代码不改模型——导致模型与实现脱节，后续维护困难。应对：将模型文件纳入版本管理，需求变更时先更新模型再改代码。
• 误区四：忽略状态机的非功能属性——如实时性（事件响应时间）、安全性（故障处理）、功耗（低功耗状态）。应对：在状态图中标注状态的时间约束与资源消耗，作为设计约束。

综上所述，状态图、状态转移表与伪代码构成了嵌入式状态机建模的完整工具链。状态图回答“系统有哪些状态、如何流转”，转移表回答“每个状态对每个事件如何响应”，伪代码回答“逻辑如何用程序结构实现”。三者结合，能够系统性地将模糊的需求转化为无歧义、可验证、可实现的模型，为后续编码、测试与维护奠定坚实基础。在实际项目中，建议根据状态机复杂度灵活选用：简单状态机（少于5个状态）可跳过转移表直接编写伪代码；复杂状态机（含嵌套或并发）则必须三种模型并用，并辅以工具（如UML建模软件）进行一致性检查。