3. 状态机设计基础：有限状态机（FSM）的基本概念
好，咱们进入状态机设计的正题。说实话，我在BMS领域摸爬滚打这些年，最怕的就是看到新人一上来就写满屏的if-else。你想想看，一个BMS要处理充电、放电、休眠、故障保护、均衡……这么多模式，要是全靠if-else堆，那代码维护起来简直是噩梦。
有限状态机（FSM）就是来解决这个问题的。它不是什么高深的理论，说白了就是一种编程思想——把系统可能处于的“状态”画出来，然后定义清楚：什么情况下会触发状态跳转，跳转时做什么动作。
3.1 什么是有限状态机？
有限状态机，英文叫Finite State Machine，简称FSM。核心就三个字：有限、状态、机。
- 有限：状态的数量是确定的，不会无限多。比如BMS的充电状态，无非就是“空闲”、“预充电”、“恒流充电”、“恒压充电”、“充电完成”这几个。
- 状态：系统在某个时刻所处的“模式”或“情况”。
- 机：一个自动运行的机制，根据输入事件决定状态的转移。
我个人习惯把FSM比作一个自动售货机。你投币（事件），它根据当前状态（等待投币/已投币/出货中）决定下一步动作（亮灯/出货/找零）。BMS的状态机本质上也是这个逻辑，只不过输入事件变成了“电压过高”、“温度异常”、“SOC过低”这些信号。
3.2 状态（State）
状态是FSM最基本的元素。它代表系统在某一时刻的“快照”。在BMS里，我通常把状态分为三类：
| 状态类型 | 举例 | 说明 |
|---|---|---|
| 正常运行状态 | IDLE、CHARGING、DISCHARGING | 电池在正常工况下的工作模式 |
| 保护状态 | OVP（过压保护）、UVP（欠压保护）、OTC（过温保护） | 检测到异常后进入的保护模式 |
| 特殊状态 | INIT（初始化）、SLEEP（休眠）、FAULT（故障锁定） | 系统启动、低功耗或不可恢复故障 |
嗯，这里要注意：状态的定义要互斥且完备。互斥的意思是，同一时刻系统只能处于一个状态，不能既在充电又在放电。完备的意思是，所有可能的情况都要覆盖到，不能漏掉。
避坑指南：我曾经在一个项目中，只定义了“正常”和“故障”两个状态，结果发现电池在低温下既不算正常也不算故障，而是需要“加热”状态。这就是状态定义不完备的典型问题。后来我学乖了，画状态图之前先列一个“所有可能场景”的清单。
3.3 事件（Event）
事件是触发状态转移的“导火索”。没有事件，状态机就是一潭死水。事件可以是外部输入，也可以是内部定时器超时。
在BMS中，常见的事件有：
- 硬件事件：比如充电枪插入（CC/CP信号变化）、按键按下、电流采样值超过阈值。
- 软件事件：比如定时器溢出、通信接收到特定指令、SOC计算完成。
- 条件事件：比如电压从4.15V升到4.20V（触发恒流转恒压）、温度从-10°C升到0°C（退出低温保护）。
你可能会问：“事件和条件有什么区别？” 我个人理解是：事件是“发生了什么事”，条件是“当前满足什么条件”。比如“充电枪插入”是一个事件，而“电池电压低于4.2V”是一个条件。状态机通常用事件驱动，但转移时也会检查条件。
3.4 转移（Transition）
转移就是状态之间的“跳转”。一个完整的转移包含三个要素：
- 源状态：当前在哪个状态。
- 触发事件：什么事件导致跳转。
- 目标状态：跳转到哪个状态。
有时候还会加上一个守卫条件（Guard Condition）——事件发生了，但条件不满足，转移就不执行。举个例子：
// 伪代码：状态转移逻辑
if (current_state == CHARGING_CC) {
if (event == VOLTAGE_REACHED && battery_voltage >= 4.20V) {
// 守卫条件：电压达到4.20V
next_state = CHARGING_CV;
}
}你看，事件是VOLTAGE_REACHED，但只有电压确实≥4.20V时才会转移。这就是守卫条件的作用。
警告：千万别写出“无条件转移”。我记得有一次调试，发现BMS在充电过程中莫名其妙跳到了放电状态。查了半天，原来是一个全局变量被意外修改了，导致状态机误触发。从那以后，我要求所有转移都必须有明确的事件和条件，绝不允许“默认跳转”。
3.5 动作（Action）
动作是状态机“干活”的部分。没有动作的状态机只是个空壳子。动作可以发生在三个地方：
- 进入动作（Entry Action）：进入某个状态时执行一次。比如进入CHARGING状态时，打开充电MOS管。
- 退出动作（Exit Action）：离开某个状态时执行一次。比如退出CHARGING状态时，关闭充电MOS管。
- 转移动作（Transition Action）：在转移过程中执行。比如从IDLE转到CHARGING时，记录一条日志。
我个人强烈建议：把动作和状态转移逻辑分开。别在状态判断里写一堆操作代码。你想想看，如果每个状态转移里都混着GPIO操作、ADC读取、CAN发送，那代码根本没法维护。
我常用的做法是：状态机只负责“决策”——决定下一个状态是什么。而“执行”交给专门的函数。比如：
// 状态机只做决策
State_t next_state = current_state;
switch (current_state) {
case IDLE:
if (event == CHARGE_PLUG_IN) {
next_state = PRECHARGE;
action_log("进入预充电");
}
break;
// ... 其他状态
}
// 动作执行在状态切换后
if (next_state != current_state) {
exit_action(current_state); // 退出旧状态
entry_action(next_state); // 进入新状态
current_state = next_state;
}这样做的好处是，状态机逻辑清晰，动作也容易复用。我在项目中用这个模式，状态图画出来是什么样，代码就是什么样，几乎一一对应。
3.6 一个简单的BMS状态机示例
说了这么多，咱们看个实际的例子。下面是一个简化的BMS充电状态机：
| 当前状态 | 事件 | 守卫条件 | 动作 | 下一状态 |
|---|---|---|---|---|
| IDLE | 充电枪插入 | 电池电压 > 2.5V | 开启预充电继电器 | PRECHARGE |
| PRECHARGE | 预充电完成 | 电压差 < 10V | 闭合主继电器，断开预充 | CHARGING_CC |
| CHARGING_CC | 电压达到4.2V | 电流 < 0.05C | 切换充电模式 | CHARGING_CV |
| CHARGING_CV | 电流低于阈值 | 电流 < 0.02C | 停止充电，记录SOC | CHARGING_DONE |
| CHARGING_DONE | 充电枪拔出 | 无 | 断开所有继电器 | IDLE |
这个表看起来简单，但实际项目中，每个状态可能还有子状态，比如CHARGING_CC下面可能还有“正常充电”和“降流充电”两个子状态。不过那是后面章节的内容了，咱们先把基础打牢。
总结一下：FSM的核心就是“状态-事件-转移-动作”这四个要素。你只要把BMS的每个工作模式定义成状态，把触发条件定义成事件，把跳转规则写清楚，再把每个状态下的操作封装好，一个健壮的状态机就出来了。我见过太多人把状态机写得像意大利面条，其实只要遵循这个框架，代码质量能提升一大截。
下一章咱们会深入讨论状态机的实现方式——是用switch-case还是用状态表？各有啥优缺点？到时候我会结合BMS的实际案例，把两种方法都讲透。