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 验收》

在 GEM（E30）体系中，事件（Event）和报警（Alarm）是最容易出问题、也是最容易被 Host/EAP 重点检查的部分。(因为GEM300部分也会用到事件上报，不过300部分依赖的数据与200的数据路径不同)

在设备开发过程中需要良好的设计和整体测试，才能很好的交付这部分内容。大体上这部分的内容包含以下几点：

• Host 收不到事件

• 机台报警触发了但 Host 不认可（没有收到）

• RPTID/VID 不一致

• CEID 上报但 Host 不解析

• 报警恢复（S5F2）漏发

• 事件顺序错乱

• 事件绑定的 VID 值不正确

这篇文章我会从工程角度讲清楚：

• 事件系统应该如何设计

• 报警系统应该如何实现

• RPTID/VID 如何绑定

• S6F11/S5F1/S5F2 如何构造

• 如何保证 Host 100% 能解析

• 如何避免国产设备厂最常见的坑

你看完这篇文章，就能实现一个可交付、可维护、可扩展的事件/报警系统。

1.事件系统的核心结构（CEID → RPTID → VID）

GEM 事件系统的本质是一个三层结构：

CEID（事件）
  └── RPTID（报告）
        └── VID（变量）

Host 订阅 CEID的行为，其实就是配置CEID的过程，而触发事件时的流程如下：

        → CEID 触发

        → 设备上报 S6F11

        → S6F11 中包含 RPTID

        → RPTID 中包含 VID

        → Host 根据 VID 解析事件内容

所以你必须实现：

• CEID 注册表

• RPTID 注册表

• VID 注册表

• CEID 与 RPTID 的绑定

• RPTID 与 VID 的绑定

• VID 的实时值获取

如果你缺任何一层，Host 都会报错。

2.事件触发流程

当设备内部发生某个事件（例如：Carrier Arrived、Door Open、Recipe Changed），你应该执行：

1. 查找 CEID

2. 找到所有 RPTID

3. 找到 RPTID 对应的 VID 列表

4. 获取每个 VID 的实时值

5. 构造 S6F11 报文

6. 发送 S6F11

具体如何使用，我会结合我们的团队的产品，单开一个系列介绍，请留意后续更新.

3. 报警系统的核心结构

报警系统比事件简单，但更容易出错。

报警有两个报文：

• S5F1（ARS）

• S5F2（ARA）

需要注意的是不管是触发报警还是清除报警，都是通过S5F1来实现的。

L,3
    1.<ALCD> 					
    2.<ALID> 					
    3.<ALTX> 				    

ALCD字段中按照bit位，既用来标记Alarm Set/Clear标记，也用来表达Alarm的报警等级（严重性）详细报警等级，读SEMI E5的ALCD字段解释。在下图的位置中

这里需要说明的是：

        实现S5F1指令时，不要省略字段，尤其是ALTX，这是SEMI标准要求的字段，就算是空字符，也要强制占位。

        还有一点需要说明的是，不能重复触发同一个报警，目前我们采取的方式是AlarmID 处于SET状态，上位机内部记录log，但不重复触发SxFy上报给HOST。

4.Host 最容易拒绝你的 8 种错误

5.如何验证你的事件/报警系统是否正确？

结合调试排查经验，给出以下步骤：

        ✔ Host 是否能订阅事件（S2F33）

        ✔ Link RPTID 是否正确（S2F35）

        ✔ VID 是否存在

        ✔ Host 统一使能事件

        ✔ Host 是否能收到事件（S6F11）

关于报警的排查，

        ✔ 报警全局禁用(S5F3)

        ✔ 报警启用

        ✔ 报警触发是否正确（S5F1）

        ✔ 报警触发是否正确

        ✔ 是否存在重复报警

        ✔ 是否存在未恢复报警

在设计这部分时，可以由驱动程序提供对应的SV，让HOST可以直接通过S1F3就能了解当前机台处于Alarm Set状态的AlarmID。

6.成熟方案供应商选择

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

• 设备工艺逻辑

• 上下位机控制

• 核心算法上

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

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

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

总结

SECS/GEM中的 事件/报警系统的本质是“数据绑定 + 报文构造”

你只需要记住：

事件系统不是协议问题，而是数据结构问题。

报警系统不是逻辑问题，而是状态机问题。

只要你的数据结构设计正确，报文构造正确，Host 就一定能解析。（如果真的遇到Fab EAP不标准，毕竟系统都是国外的，并且很多年了。遇到这种情况那就只能厂商来适配，但这种场景不多。）