📚 课程目录第3章 SECS/GEM协议核心机制精讲

3. SECS/GEM协议核心机制精讲

SECS/GEM 是半导体设备与主机（Host）之间通信的事实标准。它并不是单一协议，而是由 SEMI E4（SECS-I）、E37（HSMS）、E5（SECS-II）、E30（GEM）等多份标准叠加而成的协议族。理解它，关键要抓住五件事：消息长什么样、连接怎么建立、事务怎么配对、事件怎么上报、数据怎么采集与控制。下面结合一段真实风格的设备日志，把这几条主线串起来。

一、SECS-II 消息结构：SxFy 是语义骨架

SECS-II 消息由 Stream（S） 和 Function（F） 组成，写作 SxFy，例如 S1F13、S2F33、S6F11。Stream 表示功能域，Function 表示该域内的具体动作，奇数 F 通常为“请求”，偶数 F 为“回复”。消息体由数据项（Data Item）树构成，每个数据项带格式码：L（List）、A（ASCII）、U1/U2/U4（无符号整数）、I1/I2/I4（有符号整数）、F4/F8（浮点）、B（二进制）、BOOLEAN 等。

例如一条 S6F11 事件报告，其结构大致是：L,3 → [DATAID, CEID, L,n → 若干报告]。CEID 是事件号，报告里是 VID（变量号）与对应值。设备日志中常见形如 S6F11 W CEID=1001 的记录，就是设备主动上报“某事件发生”。

二、HSMS 连接管理：TCP 之上的会话层

HSMS（E37）把 SECS-II 消息封装在 TCP 之上，定义了两种角色：Active（主动发起连接）和 Passive（监听等待）。连接建立后，双方通过 Select 流程进入“已选择”状态，才能交换数据消息。核心控制消息包括 Select.req/rsp、Deselect.req/rsp、Linktest.req/rsp 和 Separate.req。Linktest 用于心跳保活，通常每 30～60 秒一次；若超时未响应，则判定链路异常并触发重连。

HSMS 消息头固定 10 字节，包含 SessionID、HeaderByte2/3（含 PType、SType、System Bytes）等字段。System Bytes 是事务配对的钥匙，请求与回复必须一致。

三、SxFy 事务模型：请求—回复的配对

SECS-II 采用“一问一答”的事务模型。主机发 S1F13（建立通信请求），设备回 S1F14；主机发 S2F33（定义报告），设备回 S2F34。每个请求都带 System Bytes，回复必须原样带回，否则视为超时。事务超时通常由 T3（回复超时，默认 45 秒）控制，连接超时由 T5、T6、T7、T8 分别约束。日志中若出现 T3 Timeout on S2F33，说明设备未在 45 秒内回复，需检查设备是否处于忙状态或链路是否中断。

四、事件报告与变量采集

GEM 的数据采集不是主机轮询，而是“订阅—上报”模式。流程分三步：

主机用 S2F33 定义报告（Report），把若干 VID 组合成一个报告；
主机用 S2F35 把报告链接到事件（CEID）；
设备用 S2F37 使能/禁用事件，之后事件发生即主动发 S6F11。

例如主机定义报告 RPTID=1 包含 VID 1001（温度）、1002（压力），再链接到 CEID=1001（工艺开始）。设备在工艺开始时自动上报 S6F11，主机回 S6F12。若主机想临时读取某变量，可用 S1F3（请求状态）指定 SVID 列表，设备回 S1F4 带值。

五、远程命令与配方管理

远程命令走 S2F41（Host Command），设备回 S2F42。命令体包含 RCMD（命令名）和参数列表，例如 RCMD=START, PPID=RECIPE_A。配方管理则用 S7 系列：S7F1/S7F2 协商配方、S7F3/S7F4 上传、S7F5/S7F6 下载、S7F19/S7F20 查询配方列表。设备端通常把配方存为 PPID 索引的文件，主机通过 S7F3 把配方体（PPBODY）下发，设备校验后回 S7F4 确认。

实操提示：调试时优先确认 Select 是否成功、System Bytes 是否配对、T3 是否超时。这三项能覆盖 80% 的通信故障。

六、日志分析示例

2024-06-11 10:23:01.221 [HSMS] Select.req sent, SType=1
2024-06-11 10:23:01.245 [HSMS] Select.rsp received, Status=0
2024-06-11 10:23:02.010 [SECS] S1F13 W SystemBytes=0x0001
2024-06-11 10:23:02.033 [SECS] S1F14 W SystemBytes=0x0001, MDLN=EQP-300
2024-06-11 10:23:05.100 [SECS] S2F33 W SystemBytes=0x0002, RPTID=1, VID=[1001,1002]
2024-06-11 10:23:05.122 [SECS] S2F34 W SystemBytes=0x0002, DRACK=0
2024-06-11 10:23:06.300 [SECS] S2F35 W SystemBytes=0x0003, CEID=1001, RPTID=1
2024-06-11 10:23:06.318 [SECS] S2F36 W SystemBytes=0x0003, LRACK=0
2024-06-11 10:23:10.500 [SECS] S6F11 W SystemBytes=0x0004, CEID=1001, VID1001=185.2, VID1002=2.4
2024-06-11 10:23:10.512 [SECS] S6F12 W SystemBytes=0x0004, ACKC6=0

这段日志完整展示了：Select 握手 → S1F13 建立通信 → S2F33 定义报告 → S2F35 链接事件 → S6F11 主动上报。每一步的 System Bytes 都严格配对，DRACK=0、LRACK=0、ACKC6=0 表示设备接受。若某步返回非 0，则需按 GEM 标准查错误码含义，例如 DRACK=1 表示报告定义超限，LRACK=2 表示 CEID 未定义。

掌握这五条主线后，再看任何 SECS/GEM 交互日志，都能快速定位到“当前处于哪个阶段、哪条消息、哪个参数出了问题”。这也是后续中间件做高并发接入时，必须内建的状态机与事务管理基础。