3、GEM状态模型：设备状态模型、控制状态模型、处理状态模型
GEM 协议里最绕人的，就是这三套状态模型。我刚接触的时候也懵过——设备一个状态，控制一个状态，处理又一个状态，它们到底谁管谁？
说白了，这三套模型分别回答了三个问题：
- 设备状态模型：设备现在能不能干活？
- 控制状态模型：谁有权限让设备干活？
- 处理状态模型：设备正在干什么活？
你想想看，一台半导体设备在产线上，必须同时回答这三个问题，才能被 MES 系统正确调度。下面我一个一个拆开讲。
3.1 设备状态模型
设备状态模型描述的是设备整体的「可用性」。它只有三个状态，但每个状态之间的跳转逻辑，我在项目里踩过不少坑。
| 状态 | 含义 | 典型场景 |
|---|---|---|
| EQUIPMENT_STATE_OFF | 设备断电或完全不可用 | 设备关机、维护中、故障断电 |
| EQUIPMENT_STATE_IDLE | 设备已上电，但未开始生产 | 待机、等待配方、等待物料 |
| EQUIPMENT_STATE_RUNNING | 设备正在执行生产任务 | 正在加工晶圆、正在传输 |
关键跳转规则：
- OFF → IDLE：设备上电自检完成，上报
ONLINE事件。 - IDLE → RUNNING：收到
START命令，开始处理。 - RUNNING → IDLE：处理完成或异常停止，上报
IDLE事件。 - 任何状态 → OFF：设备断电或发生不可恢复故障。
我曾经在一个项目中，设备在 IDLE 状态下收到了非法命令，结果状态机卡死了。后来我养成了一个习惯——所有状态跳转都要做合法性校验，不合法的命令直接返回错误码，绝不执行。
3.2 控制状态模型
控制状态模型解决的是「权限」问题。GEM 协议里，设备可以被三种角色控制：
- 本地控制（Local）：操作员在设备面板上操作。
- 远程控制（Remote）：MES 或上位机通过 GEM 协议控制。
- 自动控制（Auto）：设备内部逻辑自动运行。
| 控制状态 | 说明 | 谁有操作权 |
|---|---|---|
| LOCAL | 本地控制模式 | 操作员面板 |
| REMOTE | 远程控制模式 | MES / 上位机 |
| AUTO | 自动控制模式 | 设备内部逻辑 |
我的经验： 控制状态模型最容易出问题的地方是「状态切换时的命令冲突」。比如设备在 LOCAL 模式下，MES 发来一个 START 命令，设备应该直接拒绝还是先切换模式？我建议的做法是：先检查当前控制状态，如果不匹配，返回 COMMAND_NOT_ACCEPTABLE，让 MES 先发 SET_CONTROL_STATE 切换模式。
3.3 处理状态模型
处理状态模型描述的是设备当前正在执行的「具体任务」。它比设备状态模型更细粒度，通常包含以下状态：
- PROCESS_STATE_IDLE：空闲，等待任务。
- PROCESS_STATE_SETUP：正在加载配方或参数。
- PROCESS_STATE_PROCESSING：正在加工。
- PROCESS_STATE_PAUSED：暂停（可恢复）。
- PROCESS_STATE_ABORTED：中止（不可恢复）。
- PROCESS_STATE_COMPLETE：任务完成。
注意： 处理状态模型和设备状态模型是「父子关系」。设备状态为 RUNNING 时，处理状态可以是 PROCESSING、PAUSED 或 COMPLETE。但设备状态为 IDLE 时，处理状态只能是 IDLE 或 SETUP。我曾经见过一个项目，设备状态是 IDLE，但处理状态却是 PROCESSING，这明显是状态机实现有 bug。
3.4 三模型关系图
下面这张图展示了三个状态模型之间的层级关系和数据流向。我建议你把它打印出来贴在工位上。
3.5 状态同步与事件上报
状态模型不是静态的，它们需要实时同步给 MES。GEM 协议通过事件（Event）来通知状态变化。
常用事件列表：
ONLINE：设备从 OFF 变为 IDLE。OFFLINE：设备从任何状态变为 OFF。START：设备从 IDLE 变为 RUNNING。IDLE：设备从 RUNNING 变为 IDLE。CONTROL_STATE_CHANGE：控制状态切换。PROCESS_STATE_CHANGE：处理状态切换。
我记得有一次，设备上报了 PROCESS_STATE_CHANGE 事件，但 MES 没收到，导致产线以为设备还在加工，实际上已经完成了。后来我强制要求：所有状态变化事件必须等待 MES 的 ACK 确认，超时重发 3 次，否则报警。
3.6 状态机实现要点
如果你要自己实现 GEM 状态机，下面这几点是我用真金白银换来的教训：
- 状态表驱动：不要用 if-else 硬编码状态跳转，用状态表 + 事件驱动的方式，方便后期维护。
- 状态合法性校验：每个状态跳转前，检查当前状态是否允许该跳转。
- 事件队列：状态变化事件要放入队列，按顺序发送，避免并发问题。
- 超时机制：MES 没响应时，设备不能一直等，要有超时重试和报警逻辑。
- 日志记录：每次状态变化都要记录时间戳、旧状态、新状态、触发源，方便排查问题。
我的习惯： 我会在设备启动时，把三套状态模型的初始值都打印到日志里。这样一旦出问题，我能立刻知道设备是从什么状态开始跑的，省去很多猜测时间。
3.7 常见问题与避坑
| 问题 | 原因 | 解决方案 |
|---|---|---|
| 设备状态与处理状态不一致 | 状态机实现有遗漏 | 增加状态一致性校验 |
| MES 收不到状态变化事件 | 网络丢包或事件未排队 | 引入事件队列 + ACK 机制 |
| 控制状态切换失败 | 权限冲突或命令顺序错误 | 先检查当前状态，再执行切换 |
| 状态机卡死 | 非法命令未处理 | 所有命令做合法性校验 |
嗯，状态模型这部分内容比较多，但它是 GEM 协议的骨架。你只要把这三套模型的关系理清楚，后面的通信、数据处理、异常处理都会顺很多。我个人建议你先把这张关系图背下来，再去看代码实现，会事半功倍。