SECS/GEM协议实战解读：从报文结构到状态模型与调试方法

半导体行业里的人提到 SECS/GEM，第一反应往往是：一堆缩写，标准文件厚得能当砖头，厂商手册写得像天书。但真到了设备要联工厂主机、要接 MES/EAP、要自动采集数据的时候，你会发现这个协议绕不过去。它不是某个厂商的私有协议，而是半导体设备世界里的"通用语言"；搞懂它，设备工程师能跟软件工程师顺畅对话，自动化工程师能独立把一台设备接进系统，测试人员也能快速定位联机问题。这篇教程我会从协议定位、消息结构、状态模型一直讲到可复现的抓包实验，覆盖我从实际项目中沉淀下来的学习路径和调试经验。

1. 先弄清楚SECS/GEM在整个半导体自动化里的位置

1.1 SECS/GEM不是网络协议，而是"设备与主机之间的会话规范"

很多从 PLC、Modbus 转过来的工程师容易把它理解成一种"net协议"，这其实是个误区。SECS/GEM 涵盖的层级比通常说的网络协议要厚得多，它不只规定字节怎么传输，更规定消息的内容格式、设备在什么状态下该干什么、事件怎么上报、配方怎么下发。拿人来做类比：TCP/IP 解决的是"声音在电话线上怎么传输"，SECS/GEM 解决的是"双方接通电话后，该说什么话、用什么样的句式、谁先说谁后说"。

具体到工厂场景，设备（Equipment）和主机（Host）之间要干的活基本上就这几类：

• 通信建立与握手：设备开机后向主机报到，上报自身标识和软件版本。
• 状态管理：主机把设备切到离线/在线/远程，控制权在谁手里要一目了然。
• 报警上报：设备出现异常时主动告诉主机，主机可以确认并记录。
• 数据采集：按事件或周期上报工艺参数、状态值。
• 配方管理：主机下发、读取、比对设备的工艺配方。
• 远程命令：主机远程触发设备执行某个动作或流程。

理解了这个定位，你就明白为什么学习 SECS/GEM 不能只盯着报文格式看，必须把"设备行为"一起纳入视野。

1.2 缩与谱系：SECS-I、SECS-II、GEM、HSMS到底什么关系

新手最容易懵的，就是发现标准文档里同时出现 E4、E5、E30、E37 这串编号。它们其实各管一段，我做了张表帮你把关系理顺：

SECS-I 是串口时代的老将，传输速度慢，现在主流新项目基本都是 HSMS。HSMS 跑在 TCP 上，默认端口 5000，设备通常作为 TCP Server 监听，主机作为 Client 发起连接。SECS-II 定义的消息不依赖传输层，所以你在 HSMS 传输里看到的 SxFx 消息格式，跟 SECS-I 时代是一致的，换的只是"运载工具"。

GEM 则相当于一个"行为章程"，它规定设备必须具备哪些能力、状态怎么跳转、事件怎么组织、报告怎么绑定。这也是为什么很多项目里说的"GEM 功能"、"SECS/GEM 通讯"，本质上是在说：设备按 E30 标准把 SECS-II 消息用 HSMS 传出来。

1.3 哪些场景必须懂它

• 半导体前道/后道设备的自动化集成，光刻、刻蚀、薄膜、清洗、测试、分选机等。
• 光伏、LED、封装测试行业里大量从半导体移植的工艺设备。
• MES/EAP 厂商的项目实施人员，要对接来自不同国家的设备商。
• 工厂内部负责设备联网的 IT/自动化团队，排查联机故障。

可以这么说：只要设备要跟工厂级系统说话，SECS/GEM 就是无法绕开的公共频道。

2. 协议栈拆解：消息在设备和主机之间到底怎么走

2.1 传输层的两代方案：串口时代的SECS-I和以太网时代的HSMS

SECS-I 的年代，设备背后拉一根 RS-232 线，波特率通常 9600，消息按"块"传输，每个块有块头、块号，大消息要拆成多个块再按顺序重组。这套机制在几十年前很实用，但放到现在，无论是速率、布线还是可靠性，都满足不了 Fab 的需求。

HSMS 直接用 TCP/IP，把原来串口的物理细节都替换掉了。它定义了自己的消息帧格式：每一条 HSMS 消息，前面有一个 4 字节的长度字段，指明后面"消息头+数据"的总长度。这个设计跟很多应用层协议类似，抓包的时候尤其要留意，因为 TCP 是流式的，可能一次 recv 拿到半条消息，也可能一次拿到好几条，必须按长度字段做分帧。

HSMS 还定义了几个连接超时参数：T3 是等待响应超时，T5 是连接建立超时，T6 是控制消息响应的超时，T7 是连接空闲超时。实操中我见过不少联机异常，就是设备或主机某个定时器设置不一致，导致连接被无端断开。学习阶段不用背参数，但要知道：所有超时背后都对应"等不到该等的东西"。

2.2 一个消息的骨架：十字节报文头里藏着关键信息

不管是 SECS-I 还是 HSMS，消息结构都分为两块：固定 10 字节的消息头（Message Header），后面跟着可选的数据区。报文头是理解协议的关键，各字段如下：

举个最经典的例子，主机发起 "你还在吗" 的探测，对应消息 S1F1。报文头大概是：

Device ID = 0x0000 Stream = 0x01 Function = 0x01 W bit = 0x01（请求，需要回复） System = 0x00000001（握手时生成，每次递增）

设备收到后回复 S1F2，注意看：Stream=1、Function=2、W bit=0，最关键的是 System Bytes 必须原样返回。如果设备回的消息里面的 System Bytes 对不上，主机就会丢弃或报错。这也是调试时最常检查的点之一。

2.3 SECS-II数据项：真正承载内容的格式

SECS-II 定义的消息内容是一棵数据项树。每个数据项（Data Item）由三部分构成：格式码、字节长度、实际数据。常见格式有 List、Binary、ASCII、Boolean，以及无符号/有符号整数、浮点数。

List 是最核心的格式，类似编程语言里的数组或结构体。比如 S1F2 的响应内容，用 SML（SECS 消息文本描述）写出来是：

<L <A "SIMULATOR"> <A "V1.0"> >

其中 L 表示一个列表，里面有两个 ASCII 字符串，分别是设备型号和软件版本。用十六进制看，这条消息的数据区大致就是：20 02 40 09 53 49 4d 55 4c 41 54 4f 52 ...这种结构。初学不用强背每个格式码，但一定要会看结构：List 包含多项，每一项又可能是 List，这种嵌套是 SECS-II 数据区的常态。很多解析问题，本质上就是嵌套层级数错了。

2.4 W位与事务：一问一答的基本规则

协议规定，带 W=1 的消息必须收到对应回复。这个"对应"靠的就是 System Bytes。举个实际操作中的经验：如果主机连续发送多个请求，每个请求都带不同的 System Bytes，设备回复时也复刻这些 System Bytes，主机就能把响应准确匹配到请求上。这跟 HTTP 的请求 ID、Modbus 的事务号是同一个思路。

常见的基础消息对你在学习中会反复遇到，我把它们整理一下：

记住这张表，你就掌握了 SECS/GEM 最常用的几十次对话。

3. 把GEM状态模型吃透，才算真正入门

3.1 设备并不是只有"在线/离线"两个状态

现在很多设备面板上有 Online、Offline 之类的按键，但 SECS/GEM 里的状态模型比这要严谨。E30 规定的控制状态（Control State）至少包含三个关键档位：

• OFFLINE：设备不接收主机远程控制，操作员在机台本地操作。
• ONLINE_LOCAL：设备与主机连接正常，但控制权在本地，主机可以读取数据但不能远程改变工艺。
• ONLINE_REMOTE：设备完全由主机控制，配方下载、工艺启动都由主机触发，这是工厂自动化最常用的状态。

你可能已经发现，"在线"和"远程"不是一回事。有些设备联了网、通信状态正常，但还在 LOCAL 模式，主机下发的远程命令不会被执行。排查问题时，如果发现主机命令石沉大海，第一反应不是看网络，而是查设备当前到底在哪个控制状态。

E30 还会区分设备的上电状态、通信状态等，比如 PREPOWER、NOT_READY、DEVICE_OFFLINE、DEVICE_ONLINE 这些，本质上是把"设备有没有准备好对话"和"归谁管"拆开。理解了"控制权"这条主线，状态机就不难了。

3.2 通信建立与状态切换的标准流程

典型的上电联机流程是这样的：

1. 设备上电，处于 PREPOWER 或 NOT_READY 状态，TCP 监听已打开。
2. 主机发起 TCP 连接，成功后发送 S1F13（建立通信请求），消息里带设备型号和软件版本。
3. 设备回复 S1F14，附带自己的设备型号和软件版本，双方握手完成，通信状态变为就绪。
4. 主机发送 S1F17，请求设备进入 ONLINE 状态。
5. 设备回复 S1F18，进入 ONLINE_LOCAL 或 ONLINE_REMOTE，具体由设备配置决定。

上述过程中如果中间某一步失败，后续流程肯定走不通。所以我一直建议工程师学会看设备的通信状态和告警日志，很多联机问题都是卡在"设备没有进入 ONLINE_REMOTE"这一环。

3.3 事件、报告与数据采集机制

SECS/GEM 的主动上报机制是学习中的一个难点，也是最有价值的部分。它把"设备发生了什么"和"主机要什么数据"解耦了，概念如下：

• 事件（Event）：设备内部发生的可上报时刻，例如 Process Start、Process End、Alarm Raised。
• 数据变量（Data Variable，DV）：设备上的某个可观测值，例如当前的腔体温度、压力。
• 报告（Report）：一篮子数据变量列表。
• 采集事件（Collection Event，CE）：把某个事件跟报告绑定在一起。事件发生时，设备按绑定的报告收集数据，发给主机。

主机想要收到带数据的 S6F11 报告，必须在设备上做两件事：定义报告（S2F33/S2F34）和绑定采集事件（S2F35/S2F36）。不少初学者以为设备天然就会上报，结果发现配置里少绑定了报告，或者报告里引用了不存在的变量，导致 S6F11 发不出来。

还有一类常见需求是周期性数据采集（Trace），主机通过 S2F23/S2F24 配置，设备按照设定的周期自动上报变量数据。它的好处是不依赖事件，拿来做曲线监控很方便。

远程命令（S2F41）也很实用，主机可以远程触发清洗、下料、暂停等动作。设备需要提前把可用的命令ID 定义清楚，主机在界面上配置好命令参数，实际运行中发过去，设备执行完通过 S2F42 回结果。

4. 动手搭建学习环境：不碰机台也能把协议跑起来

4.1 最小验证环境的选型思路

学协议最怕"只看不练"。好在 SECS/GEM 不需要真实机台也能跑通，我建议你在自己的电脑上搭一个最小环境，目标就两个：能发包，能看包。

• 传输层：直接用 HSMS，端口 5000。
• 模拟器：网上有不少设备模拟器和主机模拟器，开源社区里也有可用的 Python 库可以快速写模拟端点。
• 抓包：Wireshark 用来观察 TCP 流里的 HSMS 消息帧，虽然它不一定能像 HTTP 那样把每条消息完整解析成树形结构，但配合十六进制视图足够帮助我们看清报文头和负载。

我第一次跑通这个环境时，做的事特别简单：设备模拟器监听 5000 端口，主机模拟器连过去，发 S1F1，看设备回 S1F2。当你在抓包里亲眼看到一问一答的完整过程，前面那些抽象概念瞬间就落地了。

4.2 用抓包观察一次完整的S1F1/S1F2握手

我以 Wireshark 抓包为例。主机发起 TCP 连接后，发出 S1F1，对应的 HSMS 帧大致如下（这是十六进制视图，不是完整标准命令）：

00 00 00 0a ; 长度：消息头10字节，无数据区 00 00 ; Device ID = 0 01 ; Stream = 1 01 ; Function = 1 01 ; W bit = 1（请求） 00 ; 保留 00 00 00 01 ; System Bytes = 1

设备回 S1F2 时，对比几个关键字段：

00 00 00 1c ; 长度：10字节头 + 数据区长度 00 00 ; Device ID = 0，必须与请求一致 01 ; Stream = 1 02 ; Function = 2 00 ; W bit = 0（普通消息） 00 ; 保留 00 00 00 01 ; System Bytes = 1，复刻请求里的值

如果你抓到的响应 System Bytes 跟请求不一样，那就说明设备侧实现有问题，或者你解析帧的起始位置偏了，把长度字段当成了头的一部分。

4.3 一个极简解析器Demo：看懂消息头

我会用一段很短的 Python 代码来解析 HSMS 帧的消息头。它不依赖任何秒秒级框架，只是为了验证你对报文结构的感觉。

import struct def parse_hsms_frame(data): if len(data) < 14: raise ValueError("帧太短，至少需要4字节长度+10字节消息头") total_len = struct.unpack(">I", data[:4])[0] header = data[4:14] device_id, stream, func, wbit, reserved, sysbytes = struct.unpack( ">HBBBBL", header ) print(f"总长度: {total_len}") print(f"Device ID: {device_id & 0x7FFF}") # 低15位为设备ID print(f"Stream/Function: S{stream}F{func}") print(f"W bit: {wbit}") print(f"System Bytes: {sysbytes}")

跑一下，你就能把之前表格里的字段对应到实际字节上。注意 Device ID 的高位在标准里可能用作控制区标志，所以我这里做了& 0x7FFF，常规项目里它是 0。

4.4 从"能通信"到"会调试"：几个自测实验

环境搭好之后，我强烈建议你按这套实验顺序练：

做完这些实验，你对 SECS/GEM 的感知完全不一样了。第 4 个实验尤其有用，因为现实中最大的问题往往不是"消息格式不懂"，而是"消息发出去了，但对方根本不理会"。懂得如何验证"对方到底有没有收到、为什么不理"，就是调试水平的分水岭。

5. 学习路径上的典型坑与实用心得

5.1 最容易卡住人的几个细节

第一个坑是用处理 HTTP 的思维去处理 HSMS。TCP 是流式协议，你会遇到粘包、半包，必须按 4 字节长度字段做分帧。不少新人在抓包里看到好几条消息黏在一起，就以为协议解析有问题，其实只是没分帧。

第二个坑是不理解 Device ID 和 System Bytes 的作用。设备侧通常固定一个 Device ID，主机发送时如果带错，设备会直接丢弃。System Bytes 关联请求和响应，调试时要确认响应里的 System Bytes 确实复刻了请求值。

第三个坑是对 W 位的忽略。有的设备实现里，明明是一个需要回复的请求，却把 W=0 发出去了，对方当成普通消息处理，自然不会有响应。这是实际项目中我会第一个排查的字段。

第四个坑是 SECS-II 数据区的长度解析。对于长字符串或大数据块，长度字段的编码有别名扩展规则，如果解析器没有正确处理，数据区会偏移。初学阶段不必完全实现，但你要知道：长度字段不是永远只有一个字节。

5.2 调试中的三层排查法

我总结过一套排查思路，遇到 SECS/GEM 联机问题先从三个层面切：

这个顺序是固定的：先确保 TCP 通，再看报文头对不对，最后才怀疑业务逻辑。很多团队一上来就查配方数据、查设备工艺参数，绕了一大圈才发现是设备 ID 写错了。

5.3 给初学者的阅读顺序与实际建议

SEMI 标准原文是权威，但不适合从头啃。我的建议顺序是：

1. 先把 SECS-II 消息格式和 HSMS 帧结构吃透，把 S1F1、S1F13、S5F1、S6F11 这类常见消息在抓包里认出来。
2. 再看 E30 的状态模型，重点关注 OFFLINE、ONLINE_LOCAL、ONLINE_REMOTE 三个控制状态的区别。
3. 然后研究事件、报告、采集事件的联动关系，把 S2F33/S2F35/S6F11 这条链路跑通。
4. 最后回到具体设备厂商的手册，把抽象模型映射到真实机台的变量、事件和命令上。

说到底，SECS/GEM 的学习一定要带着"谁先说话、谁该响应、数据怎么组织"这三个问题去学。标准文件里的表格再复杂，落到一次真实的 S1F13/S1F14 握手里，也就那么十几个字节的事。

我在项目里带过不少新人，最快上手的那批人，没有一个是从头到尾读完 E30 才动手的，都是先搭模拟环境、抓包、改包、触发报警，踩过几个坑之后回头翻标准，突然就全通了。如果你现在正被一堆缩写搞得头大，别硬啃，先把环境跑起来，让设备模拟器跟主机模拟器说上话，再回来看这篇文章，很多细节自然就对上了。