3. GEM 设备状态模型：核心状态定义

GEM（Generic Equipment Model）标准定义了半导体设备必须实现的一组有限状态机（Finite State Machine, FSM），用于规范设备在通信与自动化环境中的行为。设备状态模型是 GEM 功能验证的基石，所有 SECS 消息的收发、控制权限的切换、报警与事件的上报，都必须在正确的设备状态下执行。

3.1 通信状态（Communication State）

通信状态描述设备与主机（Host）之间的连接与数据交换能力。GEM 定义了三种通信状态：

3.2 控制状态（Control State）

控制状态决定设备操作权限的归属——是由本地操作员控制，还是由远程主机控制。GEM 定义了两种控制状态：

3.3 状态组合与迁移

设备在任何时刻都处于一个通信状态与一个控制状态的组合。GEM 标准定义了 6 种有效组合（3 种通信状态 × 2 种控制状态），但实际设备通常只使用以下 4 种常见组合：

• INIT + LOCAL：上电初始，本地控制
• NOT_READY + LOCAL：连接建立但未就绪，本地维护
• READY + LOCAL：通信正常，本地操作
• READY + REMOTE：通信正常，远程自动化控制（生产模式）

以下 SVG 图展示了 GEM 设备状态机的核心状态迁移路径：

3.4 状态迁移触发条件

设备状态迁移由特定事件或 SECS 消息触发。以下是主要迁移路径的触发条件：

1. INIT → NOT_READY：设备收到并响应 S1F13（Establish Communications Request），发送 S1F14 后进入 NOT_READY。
2. NOT_READY → READY：设备完成内部初始化（如加载配方、校准传感器），自动迁移到 READY。
3. READY → NOT_READY：设备发生严重故障、通信中断或收到 S1F15（Request OFF-LINE）消息。
4. LOCAL → REMOTE：主机发送 S2F17（Remote Command）且设备允许远程控制。
5. REMOTE → LOCAL：操作员在设备面板上切换控制模式（通常需要硬件确认）。

3.5 状态相关的 GEM 功能约束

不同设备状态下，GEM 功能的可用性有严格约束。以下表格总结了核心功能在各状态下的支持情况：

3.6 状态机实现示例（伪代码）

以下伪代码展示了设备状态机的基本实现框架：

// 设备状态枚举
enum CommState { INIT, NOT_READY, READY };
enum ControlState { LOCAL, REMOTE };

// 设备状态结构体
struct DeviceState {
    CommState comm;
    ControlState ctrl;
};

// 状态迁移函数
bool transitionTo(DeviceState& current, CommState newComm, ControlState newCtrl) {
    // 验证迁移合法性
    if (current.comm == INIT && newComm == NOT_READY) {
        // 允许：收到 S1F13 响应
    } else if (current.comm == NOT_READY && newComm == READY) {
        // 允许：初始化完成
    } else if (current.ctrl == LOCAL && newCtrl == REMOTE) {
        // 允许：收到 S2F17 且设备支持远程
    } else {
        return false;  // 非法迁移
    }
    
    // 执行迁移
    current.comm = newComm;
    current.ctrl = newCtrl;
    
    // 触发状态变更事件
    onStateChanged(current);
    return true;
}

// SECS 消息处理示例
void handleS1F13(DeviceState& state) {
    if (state.comm == INIT) {
        transitionTo(state, NOT_READY, state.ctrl);
        sendS1F14();  // 发送确认响应
    } else {
        sendS9F5();   // 发送错误响应
    }
}