SECS/GEM协议开发指南：从HSMS链路到GEM功能配置

简介面向半导体设备自动化从业者的SECS/GEM标准规范资料包源自广州金南瓜科技2020年发布的规格说明书适用于设备工程师、软件开发者及产线集成人员理解和落地SEMI通信标准。内容系统梳理通信状态模型、控制状态模型与设备处理状态并详解主机发起场景、事件通知、在线识别、动态事件报告配置、变量数据采集、跟踪数据采集、状态数据采集、报警管理、远程控制、设备常数、过程程序管理与终端服务等GEM核心能力同时涉及TCP/IP通讯超时等协议细节可帮助读者建立设备与主机间完整的数据交互逻辑并直接用于实际开发与调试。资源以PDF格式提供整个压缩包仅含1个文件大小约1006KB便于作为离线技术手册随时查阅。已有732人学习下载对正在推进半导体设备互联与自动化改造的团队具有明确参考价值可作为设备联调与方案比对的底稿。1. SECS/GEM标准规范到底是什么设备联网的第一道门槛在光伏、半导体、新能源装备这一类的产线上设备端软件工程师被问得最多的一句话就是你们这台设备支持 SECS/GEM 标准规范吗这句话背后不是一次认证考试而是设备能不能真正接进产线中枢Host能不能被远程下发配方、上报产量、转发报警。国内早年能看的中文资料很少很多初入这个方向的人第一次摸到标准大门的门缝靠的是一份以“金南瓜”为名的中文导读和配套示例它把几十页晦涩的标准文档拆成了能照着做的步骤。这篇文章就按“这是什么 — 怎么把链路跑通 — GEM 功能怎么配 — 哪些地方容易翻车 — 怎么用抓包验证”的顺序展开适合设备软件、上位机开发、PLC 集成的同行也适合刚接手设备联网的工艺工程师。2. SECS/GEM标准规范的协议栈先把E4、E5、E30、E37装进一张图2.1 为什么“一层一层学”才是最快的路径从串口时代到TCP/IP的跳跃SECS/GEM 不是某一个协议而是一整个协议族。很多新同事第一次打开标准文档时被吓退就是因为误以为只需要读一份文件。实际上完整对接至少要分清四份标准SECS-I行业标准里编号 E4 的那份传输规范、HSMS编号 E37、SECS-II编号 E5和 GEM编号 E30。这里我先不写全称因为干这行的人平时嘴上说的就是 E4、E37、E5、E30金南瓜那套资料也是按这个顺序给自己排的目录。传输层决定“数据怎么过去”SECS-I 走的是 RS-232 串口HSMS 走的是 TCP/IP。新建产线几乎全部走 HSMS只有存量老设备还在用串口。消息层决定“过去的数据长什么样”SECS-II 定义了消息头、消息体、数据类型和 Stream/Function 编号。行为层决定“设备该怎么表现”GEM 规定了一台设备从离线到在线、从生产到报警的完整状态迁移和行为边界。这三层的关系我用一张表来说明层次标准编号行业通用说法作用生产环境选型传输层E4 / E37字节流怎么封装、怎么建连新项目一律 HSMSE4 只用于老设备改造消息层E5消息头的字节布局、数据项编码所有项目必学抓包调试靠它行为层E30状态机、事件、报警、远程命令的规则决定设备是不是“合规设备”为什么必须分层学因为现场排错都是跨层进行的TCP 握手都成功了但设备就是不报事件问题大概率在 E30 的行为配置而不是网络。我曾见过一个团队在 E37 的 Select 流程上反复调参最后才发现设备端压根没使能事件上报这是 E30 的范畴。金南瓜的资料有一个好处就是它先把 E30 放在主线位置再回过来讲 E37 和 E5这个顺序符合实际落地逻辑。2.2 消息的骨架10 字节 Message Header 怎么读才是入行的第一个手艺SECS-II 消息的每一个帧最前面都固定跟着 10 个字节的消息头。抓包、写驱动、对日志第一件事就是看懂这 10 个字节。字段顺序和含义如下第 1 字节到第 2 字节是 Session ID其中最高位bit15是设备 ID 的最高位低 15 位才是真正的会话 ID第 3 字节的高位是 W 位是否需要回复低 7 位是 Stream第 4 字节是 Function第 5 字节是 PType正常数据消息取 0第 6 字节是 SType普通数据消息取 0控制消息取 1 到 6第 7 字节保留第 8 字节到第 9 字节是 Block Number第 10 字节保留。这里最容易搞混的是 W 位和 SType。S1F13 这种“请求握手”的消息W 位必须为 1意思是“请回复我 S1F14”。如果 W 位为 0对端就会认为这条消息不需要应答握手流程就直接断了。下面是一段演示性的解析代码我习惯用一个三行的小函数把 10 字节消息头拆开看import struct def parse_secs_header(raw: bytes): # raw 是 HSMS 帧中除 4 字节长度字段外的 10 字节消息头 session_raw, byte2, byte3, ptype, stype, resv, block_num, resv2 struct.unpack(HBBBBHB, raw) device_id session_raw 0x7FFF # bit15 是设备 ID 最高位但低 15 位才是会话 ID w_bit (byte2 7) 0x01 # 是否期望对方回复 stream byte2 0x7F function byte3 return { device_id: device_id, w_bit: w_bit, stream_function: fS{stream}F{function}, ptype: ptype, stype: stype, block: block_num, } header b\x00\x00\x80\x0D\x00\x00\x00\x00\x00\x01 print(parse_secs_header(header))参数说明session_raw是前两个字节拼成的无符号短整型0x7FFF用来把设备 ID 的位域摘出来如果对端设备 ID 配的是 0那前两个字节通常就是00 00。stream和function组合成消息编号比如0x80 0x0D解析出来就是 S1F13。运行这段代码后输出结果里能看到 device_id0、w_bit1、消息编号 S1F13这正好是一台设备收到 Host 端建立连接请求时的典型场景。2.3 GEM 的状态模型要放在代码之前设备状态、控制状态、通信状态三张表GEM 标准的核心不是“能收发消息”而是“设备的行为可预测”。标准里定义了三套状态模型设备状态Equipment State、控制状态Control State和通信状态Communication State。大部分新设备只需要实现控制状态因为 Host 端判断设备可不可用看的就是控制状态里 OFF_LINE、ONLINE/LOCAL、ONLINE/REMOTE 这三个位置。控制状态有一条铁律设备默认处于 OFF_LINE只有收到 Host 发来的 S1F13或 S1F17且回复成功后设备才能切到 ONLINE。在 ONLINE/REMOTE 状态下操作员在设备本地的某些操作会被限制这是为了防止人机界面和 Host 远程控制打架。金南瓜的导读里对这部分有一句很实在的提醒先画状态迁移图再写代码不然最后改的一定是状态机而不是业务逻辑。通信状态相对简单就是 NOT_CONNECTED 和 CONNECTED。但要注意通信状态和控制状态是独立的TCP 链路还连着不代表设备处于 ONLINE。很多对接现场出现的诡异现象——Host 端显示“已连接”但发命令无响应——原因就是设备 TCP 层正常但控制状态还停在上电初始的 OFF_LINE。理解这三张表是接下来配置 GEM 事件和命令的前提。3. 本地跑通 HSMS 链路用自写 Equipment 端和仿真 Host 完成第一次握手3.1 为什么上手不碰硬件先把“能连上、能回复、能超时重连”用仿真验证直接拿一台真机去和产线 Host 联调是成本最高的做法。真机一旦启动报文日志不方便抓状态机又不能随便改出了问题只能靠生产间隙排查。我一般会先在本地搭一个纯软件的仿真环境一台电脑本机回环地址左边是自写的 Equipment 端右边是现成的 Host 仿真工具消息先在这个环境里跑通再上真机。金南瓜这套资料里也推荐了类似的路径先做“连通性验证”再做“行为验证”。连通性验证只看三件事TCP 能不能建连、HSMS Select 流程能不能完成、S1F13/S1F14 握手能不能互相应答。只要这三件事通了设备接入产线的基础就已经成立。下面我用一个最小的 Python Equipment 端来演示这第一步。3.2 最小 Equipment 端代码用 Python socket 建立 HSMS 被动服务这段代码的目的只有一个在本机 5000 端口监听 HSMS 连接收到 Select 请求后回一个 Select 响应收到 S1F13 后回 S1F14。为了保持逻辑清晰我把数据帧的读取单独抽了出来import socket, struct def read_hsms_frame(sock): # 先读 4 字节长度字段再读取完整的一帧 len_data b while len(len_data) 4: chunk sock.recv(4 - len(len_data)) if not chunk: raise ConnectionError(连接被对方关闭) len_data chunk msg_len struct.unpack(I, len_data)[0] body b while len(body) msg_len: chunk sock.recv(msg_len - len(body)) if not chunk: raise ConnectionError(连接在读取消息体时断开) body chunk return body[:10], body[10:] def build_hsms_frame(session_id, byte3, byte4, ptype, stype, bodyb): # 构造一个 HSMS 帧10 字节消息头 消息体 header struct.pack(HBBBBHB, session_id, byte3, byte4, ptype, stype, 0, 1) header b\x00 # 第 10 字节保留 frame header body return struct.pack(I, len(frame)) frame HOST, PORT 127.0.0.1, 5000 srv socket.socket(socket.AF_INET, socket.SOCK_STREAM) srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) srv.bind((HOST, PORT)) srv.listen(1) print(Equipment 端已监听 5000 端口) conn, _ srv.accept() print(Host 已连接等待 Select 请求) while True: header, payload read_hsms_frame(conn) session_id, byte3, byte4, ptype, stype struct.unpack(HBBBB, header[:6]) if stype 1: # Select.req # Select.rspCommitStatus0 表示成功SType2 conn.sendall(build_hsms_frame(session_id, 0x00, 0x00, 0x00, 0x02, b\x00)) print(已回复 Select.rsp) elif stype 0: # 数据消息 stream byte3 0x7F function byte4 if stream 1 and function 13: # S1F13 # S1F14 的回复正文MDLN 和 SOFTREV 两个值 body b\x01\x00\x01\x01 # 简单示例1 个 LIST包含 2 个 ASCII 项 conn.sendall(build_hsms_frame(session_id, 0x81, 0x0E, 0x00, 0x00, body)) print(已回复 S1F14) break逻辑说明read_hsms_frame是整个 HSMS 通信的地基它先按照 HSMS 的规矩读出 4 字节的大端长度字段再循环 recv 直到读够整帧长度这样能避免 TCP 粘包把两条消息混在一起。build_hsms_frame负责把消息头和数据体拼成一个完整帧我这里 Block Number 固定为 1实际项目里如果消息体超过 4KB 就要处理多块拆分。参数说明SType1 是 Host 发出的 Select.reqSType2 是设备回的 Select.rspSType0 表示这是一条携带 SECS-II 数据的消息。S1F14 的回复里0x81 0x0E表示 W 位为 1、Stream1、Function14意思是“这条回复也期望对方确认”。这个最小实现足够验证 TCP 链路和 HSMS 会话建立但它没有处理 T3 超时、没有心跳真实项目里需要继续加状态处理。3.3 用仿真 Host 发一条 S1F13确认“设备身份”能不能被读出来Equipment 端写好后还需要一个 Host 端来主动连接。常见做法是找一个独立的 HSMS 调试器这类工具通常支持填写远端 IP、端口号、设备 ID然后一键发起 Select。如果你手头暂时没有现成工具也可以用 Python 的 socket 写一个十几行的客户端模拟 Host 发起连接。下面这行命令序列演示的是用独立仿真工具连接时必然经历的三个阶段TCP 建连、Select 握手、S1F13/S1F14 命令交换。金南瓜的资料里通常把这称为“三连验证”也就是验证网络层、会话层、消息层是否都通畅。# 启动 Equipment 端上面保存成 equipment.py python equipment.py # 另一个终端用调试工具发起连接 # 目标地址127.0.0.1:5000 # 连接成功后发送 Select.req等待 Select.rsp # 再发送 S1F13等待设备回 S1F14需要注意仿真工具的 S1F13 请求里通常带一个 MDLN设备型号名参数但有些工具只是空请求设备端依然要回 S1F14只是数据项内容可以更简短。真实产线里S1F14 里的 MDLN 和 SOFTREV 会被 MES 系统记录下来用于资产盘点所以不要随便填需要和设备实际铭牌一致。3.4 超时参数要在一开始就定义好T3、T5、T6、T7、T8 各有归宿HSMS 通信里最影响调试体验的是那组以 T 开头的超时参数。很多现场问题都是默认参数被改乱了导致的所以我建议在项目一开始就用一张表把它们固定下来。下表是我在项目里常用的初始值可以作为起点再按需调整参数默认值参考作用常见调大原因T345 秒等待消息回复的超时设备单条命令处理时间长比如配方校验T510 秒连接重试间隔网络抖动频繁避免重连风暴T65 秒控制消息回复超时设备 CPU 负载高Select 回复慢T710 秒未收到数据时的保活间隔产线网络有防火墙需要主动心跳T85 秒接收数据帧间隔超时设备在传输大文件时帧间隔偏大T3 是曝光率最高的一个因为设备处理一条命令如果超过 45 秒没回Host 端就会判定超时并可能断开连接。我见过很多设备端代码在事件上报线程里做同步数据库查询一个 SQL 慢查询就把 T3 拖爆了。下一章的避坑部分会专门讲这类问题。4. GEM 功能怎么配才像一台“合格设备”状态、事件、报警与远程命令4.1 设备身份先立住S1F13/S1F14 与 S1F17/S1F18 的用途差异设备接入 Host 后第一步永远是身份确认。S1F13 的全称是“Establish Communications Request”它请求设备上报型号和软件版本设备用 S1F14 回复。S1F17 的全称是“Request Report”类命令它请求的是设备当前状态不要求上报型号。两者的区别很微妙但实际场景里容易用错Host 在设备重启后通常会发 S1F13 重新建立通信而在正常运行中做周期巡检Host 更喜欢发 S1F17因为它的返回内容更轻量不携带大数据块。我在配置设备端时会把 S1F13 的处理函数单独做成一个模块里面只做三件事组织 MDLN、组织 SOFTREV、回复 S1F14。不要把任何业务逻辑塞进这个握手流程里。金南瓜的导读里有句很实用的话“握手只负责确认身份不负责启动生产。”如果设备端在 S1F13 的处理函数里顺带初始化了某个运动轴一旦 Host 在设备还没准备好时发起握手设备就可能卡在中间状态。S1F14 的回复报文里还有一个容易被忽略的细节S1F14 的 W 位一般设置为 1。原因是这是对 S1F13 的回复回复本身不再要求对方继续回执但很多 Host 还是希望收到一个 S1F15即收到了对 S1F14 的确认。如果设备端不打算处理 S1F15那就把 S1F14 的 W 位设为 0。这个细节会直接影响部分 MES 系统的握手日志表现为“通信建立成功但会有一条未确认消息残留”。4.2 Collect Event 和 Report事件不是“推”而是“Host 先订阅”GEM 里最核心的机制是事件上报但它的工作方式和很多工程师直觉里的“主动推送”不一样。GEM 要求 Host 先订阅设备才能上报。订阅的过程涉及两套东西Collect EventCE和 Report。一个 CE 定义“什么时候上报”比如“一片晶圆加工完成”一个 Report 定义“上报哪些数据”比如“加工时间、设备腔体温度、产品批号”。Host 订阅的典型命令链是四条S2F33 定义 ReportS2F35 定义 CE 和 Report 的绑定S2F37 使能 CES2F39 使能 Report。设备端每处理一条都要回对应双号消息例如收到 S2F33 后回 S2F34。下面是一个 Host 下发 S2F33 的报文示例这段文本里我用简化的格式列出它的数据项结构Host - Equipment: S2F33 W L[2] L[3] U4[1] RPTID 1 A[3] CEID 表示是本设备的 CEID L[1] A[1] PROCESS_TIME L[3] U4[2] RPTID 2 A[3] DVVAL L[1] A[1] CHAMBER_TEMP这段报文的意思是定义两个 Report编号分别是 1 和 2第一个 Report 里包含变量 PROCESS_TIME第二个 Report 里包含变量 CHAMBER_TEMP。设备端收到后要做两件事第一检查这些变量名是不是自己支持的变量不支持的变量要能明确返回错误码第二把 RPTID 和对应的变量ID 存下来供后续 S2F35 绑定 CE 时使用。参数说明L[n]表示一个列表U4表示无符号 4 字节整数A[n]表示固定长度 ASCII 字符串。设备端如果认为某个变量不存在需要在 S2F34 里返回非 0 的 acknowledge 码。很多设备第一次对接失败都是因为把所有变量都当成已知变量回 0 了结果 Host 下发事件上报后设备又拿不出对应数据。4.3 Remote Command 与 Alarm两条最常被验收的功能线Remote Command远程命令用 S2F41 下发、S2F42 回复是设备对接验收时必测的功能。它最典型的应用是“远程启动配方”和“远程暂停设备”。设备端在收到 S2F41 时要立即返回正在执行的回执等命令真正执行完毕后再通过事件上报结果。如果你在一个耗时的操作里同步回复 S2F42Host 端会一直阻塞等待稍慢一点就会触发 T3 超时。正确做法是先回 S2F42 表示“已收到并开始执行”再异步处理业务。Alarm报警用 S5F1 上报、S5F2 回复。设备发生硬件故障、安全互锁触发、工艺参数越界时都要通过 S5F1 把报警代码 ALID 和报警文本 ALTXT 发给 Host。这里有一个设计建议报警代码和报警文本必须在设备端持久化存储不能只在内存里。因为产线断电重启后如果设备还有未确认的报警需要具备“重新上报”的能力。金南瓜的资料里将这一条列进了“验收前自查清单”。S5F1 的报文结构并不复杂设备端需要注意的是 ALID 必须全局唯一、报警级别要和产线约定一致。下面是一个最小 S5F1 消息体的字节构造示例import struct def build_s5f1_current_alarm(alid: int, text: str): # S5F1 消息体ALID ALTXT # 这里简化表示为一个 LISTU4 报警代码 A 报警文本 body struct.pack(B, 0x01) # LIST body struct.pack(B, 0x25) # U4 类型标识 body struct.pack(B, 0x04) # 4 字节长度 body struct.pack(I, alid) body struct.pack(B, 0x41) # A 类型标识 body struct.pack(B, len(text)) # 字符串长度 body text.encode(ascii, errorsreplace) return body这段代码演示了 SECS-II 二进制编码里最基本的三段式类型字节、长度字节、数据字节。0x25是 U4 的 SECS-II 类型码0x41是 ASCII 字符串的类型码。真要交付项目时我不建议手写这种编码直接使用现成的 SECS-II 编码库会更稳妥。但是理解这个结构对排查乱码和长度错位非常有帮助。Remote Command 的验收关键是设备必须能在收到 S2F41 后正确区分“命令名”和“参数列表”。一个典型的 S2F41 报文里包含 CPNAME命令名和 CPVAL参数值。设备端要做的是白名单匹配而不是把所有命令名都接收下来。只有白名单内的命令才回 0成功不认识的命令统一回非 0并且要保证回执里的 RMD回复代码和命令执行结果一致。5. SECS/GEM 实战避坑现场最容易翻车的五个排查点5.1 现象链路刚建好T3 超时就断日志里全是 Timeout这是现场最经典的问题。TCP 连接正常Select 也成功了但只要 Host 一发数据命令设备迟迟不回几秒后链路被 Host 断开。原因几乎不是网络而是设备端的事件线程阻塞。常见的阻塞点有三个同步查数据库、同步调用第三方接口、在大循环里执行耗时运算。解决方法是把所有可能超过 1 秒的操作移出消息接收线程使用异步队列来处理。排查时第一步先看设备端日志里 S1F13 的回复时间戳如果从收到请求到发出响应超过 20 毫秒就已经能说明问题。5.2 现象S1F13 回复成功但 Host 端就是不显示设备在线这类问题在第一次做 MES 对接时特别多见。现象是 S1F14 已经发出Host 也收到了但 Host 界面上设备始终处于离线状态。原因通常是设备在回复 S1F14 后又主动关闭了 TCP 连接或者把设备 ID 配错。很多设备端代码在 Select 成功后误以为需要主动断开重连结果每次握完手就断。排查时用抓包软件过滤 5000 端口看 S1F14 发出后是否立刻跟了一个 FIN 包。如果看到 FIN就去设备端代码里找 close 调用多半是状态机里连接建立的逻辑写错了位置。5.3 现象S6F11 事件上报后Host 一直回 S6F12 且 ack 非 0设备已经按配置上报了事件但 Host 返回的应答码不对。原因大多是 RPTID 和 CEID 之间没有完成绑定。Host 在订阅阶段发 S2F33 定义了 Report又发 S2F35 绑定了 CE但设备端在重启后把这份配置丢了导致上报时找不到对应的 Report ID。解决方法是把 CE 和 Report 的配置持久化设备重启后从非易失存储里恢复或者在开发阶段每次启动后用 Host 重新下发一遍订阅命令。我见过一个项目为了解决这个问题把 S2F33/S2F35/S2F37/S2F39 这四条命令的执行结果全部写进了启动日志每次设备重启后第一件事就是核对配置这个习惯很值得推荐。5.4 现象中文字符串在 Host 界面变成乱码数据长度错位很多设备有中文报警文本比如“冷却水压过低”。SECS-II 标准里的 ASCII 类型是单字节的如果你的设备端用 UTF-8 编码存中文一个中文会占 3 个字节但编码层按单字节字符数计算长度就会导致消息体长度和实际字节数不一致。Host 按长度字段切分时下一个字段就被错位吞掉了。解决方法是新项目建议统一使用 SECS-II 的 A 类型并强制单字节编码传输如果必须传中文要在项目启动前和 MES 团队约定好编码方式并保证长度字段按字节数计算。排查时直接看抓包里长度字节和实际内容长度是否一致不一致基本就是这个问题。5.5 现象拔网线重插后Host 无法再次 Select设备恢复网络后TCP 半开连接还留在系统里Host 发 Select.req 得不到响应。原因主要是设备端没有按 HSMS 规范处理 T5 重连和 Link Test。标准里要求设备端周期性发送 Link Test 消息SType5来探测链路如果对方不回应就要关闭连接并重新回到监听状态。有些设备端把 Link Test 遗漏了链路断了就永远处于假连接状态。解决方法是实现 Link Test 的收发并启用 T5 重连逻辑检测到对端无响应时主动关闭 socket回到 TCP listen 状态。交付前做一次拔网线测试是必须的这也是下一章要展开的验证技巧。6. 抓包验证与交付习惯让“先断一次”成为标准动作当你把设备端代码已经跑通、事件上报也正常了最容易掉以轻心的是“线上没测过异常路径”。我现在的团队养成了一个习惯任何设备在交付前都要用抓包工具完整记录一次“断电-重连-恢复上报”的过程。这个习惯源于一次我在现场的经历设备平时联调都很正常结果产线真实断电重启后Host 端足足等了 20 分钟才恢复在线原因就是设备端没有做断线重连TCP 半开连接把状态卡死了。抓包工具层面我通常用 tcpdump 抓取本机回环或设备侧网卡流量再导入 Wireshark 分析。HSMS 是明文 TCP 协议Wireshark 能直接解析出 SType 和 SECS-II 消息内容。常用的过滤命令是# 抓取 5000 端口上的所有 HSMS 报文 tcpdump -i any -s 0 -w hsms.pcap tcp port 5000抓完包后重点看四段记录第一TCP 三次握手是否正常第二Select.req/Select.rsp 的 SType 是否为 1/2第三S1F13/S1F14 的 W 位和消息编号是否正确第四S6F11 事件上报后 Host 的回执代码。任何一个环节缺失都能在报文里直接看到。另一个技巧是抓包时把时间戳精度开到微秒判断设备侧响应耗时是否在合理范围内。HSMS 的响应如果超过 1 秒就要去查设备端处理线程的负载了。最后想说SECS/GEM 标准的难点不在于语法而在于你愿不愿意把“异常路径”当主线来验证。只测正常流程交付后迟早要翻车。我现在不管做设备端还是 Host 端验收单里永远有一项“断开重连测试”而且必须在交付前做不能等到了客户现场再做。希望这篇内容能帮你把设备联网的第一道门槛跨过去少走一些我当年走过的弯路。本文还有配套的精品资源点击获取