SECS/GEM协议介绍

——写给正在做国产半导体设备通信接口的研发工程师

系列文章目录

1. 《SECS/GEM 协议介绍》
2. 《HSMS（E37）通信层的正确实现方式》
3. 《SECS-II 报文结构：工程师最容易犯的 10 个错误》
4. 《GEM 事件/报警系统的完整实现》
5. 《GEM300（E87/E90/E94）流程详解：Carrier → Job → Recipe》
6. 《国产设备厂 SECS/GEM 接口常见问题与调试案例》
7. 《如何设计一个可扩展的 SECS/GEM 驱动程序》
8. 《如何用流程化工具做 Host/EAP 验收》

---

目录

系列文章目录

前言

1. SECS/GEM 是什么？一句话讲清楚

2. SECS/GEM 的组成

2.1 E37 — HSMS：基于 TCP 的通信层

2.2 E5 — SECS-II：报文语法（SxFy）

2.3 E30 — GEM：设备行为模型

2.4 GEM300（E87/E90/E94）：晶圆厂级流程

3. Host 与设备端的职责分界（工程师必须搞清楚）

4. 为什么国产设备厂在 SECS/GEM 上普遍吃力？

5. 工程师应该如何理解 SECS/GEM？

6. 成熟方案供应商选择

总结

---

---

前言

半导体设备通信里，SECS/GEM 是一个绕不过去的词。

但如果你真正做过国产设备的 Host/EAP、设备端接口、GEM300 流程，你会发现：

SECS/GEM 不是一个协议，而是一整套“设备行为模型 + 通信语法 + 状态机 + 事件系统”的组合。

这篇文章我不打算重复 SEMI 文档，而是从“工程师视角”讲清楚：

• SECS/GEM 到底由哪些部分组成

• 每个部分在工程实践中扮演什么角色

• 为什么国产设备厂在实现时会踩坑

• Host/EAP、设备端分别需要关注什么

---

1. SECS/GEM 是什么？一句话讲清楚

如果用一句话概括：

SECS/GEM = 设备如何“说话” + 设备应该“怎么表现”。

其中：

• SECS（SEMI Equipment Communication Standard）

    → 定义“怎么说话”（通信协议 + 报文格式）

• GEM（Generic Equipment Model）

    →  定义“设备应该怎么表现”（状态机 + 事件 + 报警 + 远程命令）

这两个结合起来，才是完整的设备通信能力。

---

2. SECS/GEM 的组成

2.1 E37 — HSMS：基于 TCP 的通信层

这是最底层的部分，负责：

• 建立 TCP 连接

• 维持心跳（Linktest）

• 管理超时（T3/T5/T6/T7/T8）

• 处理 Select.req / Select.rsp

工程实践里最常见的问题：

• 设备端没有正确处理 T5/T6，导致“假死”

• Host 端重连策略不规范

• 多线程读写导致报文粘包/拆包

• 心跳机制实现不完整

一句话：HSMS 是稳定性的根本。

2.2 E5 — SECS-II：报文语法（SxFy）

这是“语言本身”。

每条消息由：

• Stream（S）

• Function（F）

• 报文体（List/ASCII/U4 等）

组成。

例如：

• S1F1：Are You There

• S1F2：On-Line Data

• S2F41：Remote Command

• S6F11：Event Report

工程实践里最常见的问题：

• 报文结构不符合 SEMI（尤其是 List 嵌套）

• ASCII/U4 类型错误

• Host 和设备对同一条消息理解不一致

• 设备端漏字段、错字段

一句话：SECS-II 是“语法”，但工程里最容易出错。

2.3 E30 — GEM：设备行为模型

GEM 定义了设备应该具备的能力，包括：

• 远程命令（S2F41）

• 事件（S6F11）

• 报警（S5F1）

• 变量（VID）

• 采集计划（S2F33/S2F35）

• Spooling（断线缓存）

• 设备状态（Online/Offline/Local/Remote）

工程实践里最常见的问题：

• 事件没有绑定变量

• 报警没有恢复事件

• 采集计划未实现

• 远程命令 ACK 不规范

• Spool 没实现或实现错误

一句话：GEM 是“设备行为规范”，决定设备是否“像一个设备”。

2.4 GEM300（E87/E90/E94）：晶圆厂级流程

如果你做的是晶圆厂设备（Track、Etcher、CVD、CMP 等），你一定会遇到：

• E87：Carrier Management

• E90：Substrate/Job Management

• E94：Recipe Management

工程实践里最常见的问题：

• SlotMap 不一致

• CarrierID/JobID 不一致

• Recipe 版本管理混乱

• TrackIn/TrackOut 流程不完整

• 状态机跳转错误

一句话：GEM300 是“Fab 级流程”，是国产设备厂最难实现的部分。

---

3. Host 与设备端的职责分界（工程师必须搞清楚）

Host（EAP/MES）负责：

• 下发命令（S2F41）

• 订阅事件（S2F33/S2F35）

• 接收事件（S6F11）

• 接收报警（S5F1）

• 管理 GEM300 流程（TrackIn/TrackOut）

设备端负责：

• 正确上报事件

• 正确上报报警

• 正确执行命令

• 正确维护状态机

• 正确管理 Carrier/Job/Recipe

一句话：

Host 是“指挥官”，设备是“执行者”。

---

4. 为什么国产设备厂在 SECS/GEM 上普遍吃力？

我总结过几十家国产设备厂的情况，问题高度一致：

① 报文格式不一致（最常见）

• List 层级错误

• ASCII/U4 类型错误

• VID/CEID/ALID 配置混乱

② 事件系统不完整

• 事件没有绑定变量

• 事件不触发

• 事件触发顺序错误

③ GEM300 状态机不完整

• PP-SELECT → START → PROCESSING → COMPLETE 跑不通

• Carrier/Job 状态不一致

④ Host/EAP 验收周期长

• 缺少可视化工具

• 缺少自动化测试

• 缺少流程模拟

⑤ 缺少统一的驱动程序

每个项目都重新写一遍，导致：

• 代码不一致

• 行为不一致

• 兼容性差

---

5. 工程师应该如何理解 SECS/GEM？

一句最实用的总结：

SECS/GEM = 通信协议（HSMS） + 报文语法（SECS-II） + 设备行为（GEM） + Fab 流程（GEM300）。 任何一个环节不完整，整个系统就跑不通。

如果你是设备端研发：

• 先把 S1/S2/S5/S6 跑通

• 再做事件/报警

• 再做远程命令

• 最后做 GEM300

如果你是 Host/EAP 研发：

• 先做命令队列

• 再做事件订阅

• 再做流程状态机

• 最后做自动化测试

---

6. 成熟方案供应商选择

对于半导体设备的软件研发团队来说，如果希望将主要精力放在

• 设备工艺逻辑

• 上下位机控制

• 核心算法上

那么 SECS/GEM 这一层完全具备外采的条件。

从工程角度看，SECS/GEM 本质上是“设备功能之上的调度层”，它需要稳定的协议栈、完整的状态机、规范的事件/报警系统以及 GEM300 的流程调度能力。这些内容既专业又繁琐，自己从零实现不仅周期长，还容易在验收阶段暴露兼容性问题。因此，选择成熟可靠的 SECS/GEM 组件，可以显著降低研发成本，加快设备上线节奏。

我们团队长期深耕这一领域，也有稳定落地的方案，如有需要可以私信交流。

本系列文章会持续更新，从 SECS/GEM 基础，到 GEM 的工程实践，再到 GEM300 的复杂调度与全流程案例，逐步分享完整的实现思路与经验。

---

总结

以上内容只是对 SECS/GEM 的一个整体性介绍，更多细节在 SEMI 的标准文档中都有非常严格的定义。

标准本身并不难，难的是如何在真实设备中把它“工程化”——包括协议栈稳定性、事件系统一致性、GEM300 流程完整性、Host/EAP 验收效率等。后续文章我会结合实际项目经验，继续拆解这些模块的工程实现方式。