半导体行业里的人提到 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 这串编号。它们其实各管一段我做了张表帮你把关系理顺标准编号简称负责的内容生活化类比SEMI E4SECS-I基于 RS-232 串口的物理传输用对讲机还是固定电话SEMI E37HSMS基于 TCP/IP 的高速传输换成了手机通话SEMI E5SECS-II消息内容与数据格式SxFx规定句式、语法、用词SEMI E30GEM设备的标准行为状态机、事件、报告、远程命令规定通话中的礼仪和流程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和以太网时代的HSMSSECS-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后面跟着可选的数据区。报文头是理解协议的关键各字段如下偏移字节数含义说明0-12Device ID设备标识常见为 021Stream消息的流号31Function消息的功能号41W bit0 表示 Message1 表示 Request需要回复51保留字段通常为 06-94System Bytes事务标识请求与响应用它关联举个最经典的例子主机发起 你还在吗 的探测对应消息 S1F1。报文头大概是Device ID 0x0000 Stream 0x01 Function 0x01 W bit 0x01请求需要回复 System 0x00000001握手时生成每次递增设备收到后回复 S1F2注意看Stream1、Function2、W bit0最关键的是 System Bytes 必须原样返回。如果设备回的消息里面的 System Bytes 对不上主机就会丢弃或报错。这也是调试时最常检查的点之一。2.3 SECS-II数据项真正承载内容的格式SECS-II 定义的消息内容是一棵数据项树。每个数据项Data Item由三部分构成格式码、字节长度、实际数据。常见格式有 List、Binary、ASCII、Boolean以及无符号/有符号整数、浮点数。List 是最核心的格式类似编程语言里的数组或结构体。比如 S1F2 的响应内容用 SMLSECS 消息文本描述写出来是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位与事务一问一答的基本规则协议规定带 W1 的消息必须收到对应回复。这个对应靠的就是 System Bytes。举个实际操作中的经验如果主机连续发送多个请求每个请求都带不同的 System Bytes设备回复时也复刻这些 System Bytes主机就能把响应准确匹配到请求上。这跟 HTTP 的请求 ID、Modbus 的事务号是同一个思路。常见的基础消息对你在学习中会反复遇到我把它们整理一下消息方向含义S1F1 / S1F2Host - Eq / Eq - Host通信探测/响应S1F13 / S1F14Host - Eq / Eq - Host建立通信请求/响应S1F15 / S1F16Host - Eq / Eq - Host请求离线/响应S1F17 / S1F18Host - Eq / Eq - Host请求在线/响应S2F17 / S2F18Host - Eq / Eq - Host请求时间/响应S2F41 / S2F42Host - Eq / Eq - Host远程命令/响应S5F1 / S5F2Eq - Host / Host - Eq报警上报/确认S6F11 / S6F12Eq - Host / Host - Eq事件报告/确认S7F1 / S7F2Host - Eq / Eq - Host请求配方列表/响应记住这张表你就掌握了 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 通信建立与状态切换的标准流程典型的上电联机流程是这样的设备上电处于 PREPOWER 或 NOT_READY 状态TCP 监听已打开。主机发起 TCP 连接成功后发送 S1F13建立通信请求消息里带设备型号和软件版本。设备回复 S1F14附带自己的设备型号和软件版本双方握手完成通信状态变为就绪。主机发送 S1F17请求设备进入 ONLINE 状态。设备回复 S1F18进入 ONLINE_LOCAL 或 ONLINE_REMOTE具体由设备配置决定。上述过程中如果中间某一步失败后续流程肯定走不通。所以我一直建议工程师学会看设备的通信状态和告警日志很多联机问题都是卡在设备没有进入 ONLINE_REMOTE这一环。3.3 事件、报告与数据采集机制SECS/GEM 的主动上报机制是学习中的一个难点也是最有价值的部分。它把设备发生了什么和主机要什么数据解耦了概念如下事件Event设备内部发生的可上报时刻例如 Process Start、Process End、Alarm Raised。数据变量Data VariableDV设备上的某个可观测值例如当前的腔体温度、压力。报告Report一篮子数据变量列表。采集事件Collection EventCE把某个事件跟报告绑定在一起。事件发生时设备按绑定的报告收集数据发给主机。主机想要收到带数据的 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(fDevice ID: {device_id 0x7FFF}) # 低15位为设备ID print(fStream/Function: S{stream}F{func}) print(fW bit: {wbit}) print(fSystem Bytes: {sysbytes})跑一下你就能把之前表格里的字段对应到实际字节上。注意 Device ID 的高位在标准里可能用作控制区标志所以我这里做了 0x7FFF常规项目里它是 0。4.4 从能通信到会调试几个自测实验环境搭好之后我强烈建议你按这套实验顺序练实验操作预期观察1主机连设备发 S1F1设备回 S1F2System Bytes 一致2发 S1F13设备回 S1F14能看到设备型号和软件版本3让设备触发一个报警主机收到 S5F1回复 S5F2 后设备不再重发4故意用错误的 Device ID 发请求设备可能不回或回 S9F1 之类错误消息5配置一个采集事件后触发设备事件主机收到带数据的 S6F11做完这些实验你对 SECS/GEM 的感知完全不一样了。第 4 个实验尤其有用因为现实中最大的问题往往不是消息格式不懂而是消息发出去了但对方根本不理会。懂得如何验证对方到底有没有收到、为什么不理就是调试水平的分水岭。5. 学习路径上的典型坑与实用心得5.1 最容易卡住人的几个细节第一个坑是用处理 HTTP 的思维去处理 HSMS。TCP 是流式协议你会遇到粘包、半包必须按 4 字节长度字段做分帧。不少新人在抓包里看到好几条消息黏在一起就以为协议解析有问题其实只是没分帧。第二个坑是不理解 Device ID 和 System Bytes 的作用。设备侧通常固定一个 Device ID主机发送时如果带错设备会直接丢弃。System Bytes 关联请求和响应调试时要确认响应里的 System Bytes 确实复刻了请求值。第三个坑是对 W 位的忽略。有的设备实现里明明是一个需要回复的请求却把 W0 发出去了对方当成普通消息处理自然不会有响应。这是实际项目中我会第一个排查的字段。第四个坑是 SECS-II 数据区的长度解析。对于长字符串或大数据块长度字段的编码有别名扩展规则如果解析器没有正确处理数据区会偏移。初学阶段不必完全实现但你要知道长度字段不是永远只有一个字节。5.2 调试中的三层排查法我总结过一套排查思路遇到 SECS/GEM 联机问题先从三个层面切层面典型现象排查点传输层TCP 连不上、连上就断防火墙、端口号、Server/Client 模式、网络通断消息层连上了但没响应报文头字段、Device ID、System Bytes、分帧语义层有响应但报错或行为不对Stream/Function 是否正确、数据项结构、设备当前状态这个顺序是固定的先确保 TCP 通再看报文头对不对最后才怀疑业务逻辑。很多团队一上来就查配方数据、查设备工艺参数绕了一大圈才发现是设备 ID 写错了。5.3 给初学者的阅读顺序与实际建议SEMI 标准原文是权威但不适合从头啃。我的建议顺序是先把 SECS-II 消息格式和 HSMS 帧结构吃透把 S1F1、S1F13、S5F1、S6F11 这类常见消息在抓包里认出来。再看 E30 的状态模型重点关注 OFFLINE、ONLINE_LOCAL、ONLINE_REMOTE 三个控制状态的区别。然后研究事件、报告、采集事件的联动关系把 S2F33/S2F35/S6F11 这条链路跑通。最后回到具体设备厂商的手册把抽象模型映射到真实机台的变量、事件和命令上。说到底SECS/GEM 的学习一定要带着谁先说话、谁该响应、数据怎么组织这三个问题去学。标准文件里的表格再复杂落到一次真实的 S1F13/S1F14 握手里也就那么十几个字节的事。我在项目里带过不少新人最快上手的那批人没有一个是从头到尾读完 E30 才动手的都是先搭模拟环境、抓包、改包、触发报警踩过几个坑之后回头翻标准突然就全通了。如果你现在正被一堆缩写搞得头大别硬啃先把环境跑起来让设备模拟器跟主机模拟器说上话再回来看这篇文章很多细节自然就对上了。