2. SECS/GEM 核心概念：设备端与主机端的角色定义与通信模型
在搭建 SECS/GEM 通信环境之前，必须清晰理解通信双方——设备端（Equipment）与主机端（Host）——在半导体制造自动化体系中的角色定位、职责边界以及它们之间的通信模型。这是后续所有工具选型与参数配置的基础。
2.1 角色定义：谁是谁？
SECS/GEM 协议定义了一种典型的主从（Client-Server）或对等（Peer-to-Peer）通信模型，但在实际工厂自动化（Factory Automation, FA）环境中，双方的角色分工非常明确。
| 角色 | 别名 | 物理实体 | 核心职责 |
|---|---|---|---|
| 设备端（Equipment） | 从站（Slave）、工具（Tool） | 光刻机、刻蚀机、薄膜沉积设备、检测设备等 | 执行晶圆加工、上报状态、响应主机指令、管理本地配方与报警 |
| 主机端（Host） | 主站（Master）、工厂主机（Factory Host） | MES（制造执行系统）、EAP（设备自动化程序）、RMS（配方管理系统） | 调度生产任务、下发配方、收集生产数据、监控设备状态、触发报警处理 |
关键区分：设备端是“被控制”与“数据产生”的一方，主机端是“控制”与“数据消费”的一方。设备端通常不主动发起业务请求，而是等待主机端的指令或按预定事件上报。
2.2 通信模型：消息如何流动？
SECS/GEM 通信模型建立在 SECS-I（RS-232）或 HSMS（TCP/IP） 传输层之上。消息的流动遵循严格的请求-响应模式，但根据发起方的不同，分为两种基本类型：
- Primary Message（主消息）：由发起方（可以是 Host 或 Equipment）发送的第一个消息，用于发起一次事务。
- Secondary Message（次消息）：由接收方返回的响应消息，用于确认、拒绝或返回数据。
一次完整的 SECS/GEM 事务（Transaction）由一对 Primary 和 Secondary 消息组成。消息通过 Stream（流）和 Function（功能） 来标识其用途，例如 S1F13（建立通信请求）和 S1F14（建立通信确认）。
记忆技巧：Stream 代表功能类别（如 S1 为设备控制、S2 为诊断、S6 为数据收集），Function 代表具体操作（F13 为请求、F14 为确认）。偶数 Function 通常为响应消息。
2.3 通信模型示意图
下图展示了 Host 与 Equipment 之间一次典型的 SECS/GEM 事务交互流程，以及消息在协议栈中的封装层次。
2.4 通信建立流程（典型场景）
设备端与主机端建立通信的典型流程如下，这是后续配置工具时必须理解的基础步骤：
- 网络就绪：设备端与主机端通过 TCP/IP 网络建立连接（HSMS 模式），或通过 RS-232 串口连接（SECS-I 模式）。
- 链路测试（Link Test）：主机端发送
S1F13（Establish Communication Request）到设备端。 - 通信确认：设备端回复
S1F14（Establish Communication Acknowledge），携带设备 ID、软件版本、GEM 支持能力等信息。 - 状态协商：主机端可选发送
S1F1（Are You There?）确认设备在线，设备回复S1F2（On-Line Data）。 - 进入在线模式：主机端发送
S1F17（Request On-Line），设备回复S1F18（On-Line Acknowledge），设备进入“在线（On-Line）”状态，准备接收生产指令。
常见陷阱：设备端在未收到
S1F17 或收到 S1F19（Request Off-Line）时，应保持在“离线（Off-Line）”状态，不执行任何来自主机的生产指令。这是 GEM 标准的安全要求。
2.5 设备端与主机端的职责对比
下表从多个维度对比设备端与主机端在 SECS/GEM 通信中的具体职责差异：
| 维度 | 设备端 (Equipment) | 主机端 (Host) |
|---|---|---|
| 通信发起 | 通常不主动发起业务事务，仅响应主机请求或按事件上报 | 主动发起大部分业务事务（如配方下发、启动加工） |
| 数据收集 | 收集设备内部状态、晶圆加工数据、报警信息，并按主机订阅上报 | 接收并存储设备上报的数据，用于生产追溯、统计分析 |
| 配方管理 | 存储本地配方，接收主机下发的配方，验证配方参数 | 管理配方库，选择并下发配方到指定设备 |
| 报警处理 | 检测报警条件，主动上报报警，记录报警历史 | 接收报警通知，触发报警处理流程（如通知维护人员） |
| 状态机管理 | 维护设备状态模型（如 INIT、IDLE、PROCESSING、ALARM），并上报状态变更 | 根据设备状态决定下一步生产调度 |
2.6 通信模型中的关键概念
- 事务 ID（Transaction ID, TID）：每个 Primary 消息携带一个唯一的事务 ID，Secondary 消息必须携带相同 ID 以完成配对。这是协议层保证消息可靠性的基础。
- 消息超时与重试：发送方在发送 Primary 消息后启动计时器（如
T3超时），若在超时时间内未收到 Secondary 响应，则重试或报错。 - 会话（Session）：从建立通信（S1F13/S1F14）到断开连接之间的完整交互过程。一个设备可以同时与多个主机建立会话吗？GEM 标准通常建议一对一会话，但 HSMS 支持多会话。
实践建议：在搭建测试环境时，建议先使用模拟器（如 SECS-I Simulator 或 HSMS Simulator）分别扮演 Host 和 Equipment 角色，验证通信建立流程，再接入真实设备。这可以大幅降低调试难度。
2.7 小结
设备端与主机端在 SECS/GEM 通信中扮演着明确且互补的角色：设备端是数据产生与执行端，主机端是控制与数据消费端。通信模型基于 Primary-Secondary 消息对，通过 Stream.Function 标识消息类型，并依赖事务 ID 保证消息的可靠配对。理解这些核心概念，是后续进行工具选型、参数配置以及故障排查的前提。