简介SECS/GEM协议是半导体及高端制造设备集成中常用的通信标准但网上中文资料分散、深入讲解有限。这份中文详解文档以10个章节系统梳理了协议价值、消息日志、常用术语、Streams and Functions等内容适合设备厂商、工艺整合与MES/EAP系统实施人员作为入门与查阅手册。压缩包内共1个PDF文档体积仅955KB方便下载后在电脑或移动设备上查看。文中重点解读了协议如何降低设备集成成本、支持多类制造设备、高效利用网络带宽、保持数据密度小并涵盖无数据翻译、环路保证与安全机制结合指令使用场景说明用法有助于读者快速理解SECS/GEM的设计思想与实际应用。目前已有2256人学习尤其适合需要快速建立协议全景认知、评估或实施设备互联方案的工程师。1. SECS/GEM 中文详解刚入设备联机这行先把手册读薄SECS/GEM 在半导体制造里跑了二十多年如今光伏、面板、锂电这些制造场景的设备联机也大量在向它靠拢。对设备工程师、MES 开发者和自动化集成商来说它不是一个需要“学不学”的新协议而是要跟设备厂商对报文、对事件、对状态时绕不开的黑匣子英文标准动辄几百页网上中文资料又碎又旧真正能当速查手册的很少。这份中文详解把协议介绍、术语解释、Streams and Functions、超时事件、格式码、通信状态、常用功能整合成一份能当模板使用的资料连环路保证和安全边界也单独做了说明覆盖面足够日常排错用。适合刚接手设备联机的新手也适合被厂商文档反复折磨的中级工程师当检索工具。2. 先立住三件套E5、E37、E30 怎么分工选型为什么绕不开 SECS/GEM很多第一次接触 SECS/GEM 的人会被 SEMI 标准编号吓到觉得 E5、E37、E30 是三座大山。实际拆开看并不复杂SECS/GEM 不是单个协议而是三层标准的合称每一层解决一个明确的问题。搞懂这三层后续读 Streams and Functions、格式码、通信状态都会顺很多。2.1 三层协议的分工谁定义消息谁定义传输谁定义行为E5、E37、E30 这三份标准的分工可以浓缩成一句话E5 管消息长什么样E37 管消息怎么在 TCP/IP 上跑E30 管设备应该有哪些行为。E5 即 SECS-II是消息层标准。它定义了一个通用的消息结构以及一个包含大量标准化消息的库。你在联调里喊的 S1F13、S6F11、S2F41 这些消息 ID就是 E5 定义的。消息结构里最核心的是消息头设备 ID、W-bit、Stream/Function、System Bytes这十个字节决定了整条消息的身份、方向和事务归属。E37 即 HSMS是协议层标准。它负责把 SECS-II 消息编码成二进制结构再通过 TCP/IP 传输。这里涉及连接建立、Select/Separate 控制事务、超时参数 T3~T8以及接收缓冲和网络断线重连的处理。对现场排查来说E37 层面的问题往往表现为“TCP 通但 SECS 不通”“T3 超时”“T5 分离超时”这类现象。E30 即 GEM是设备模型标准。它定义了一组最低要求外加一组可选功能。最低要求保证任何符合 GEM 的主机软件都能对接任何符合 GEM 的设备可选功能则允许简单设备和复杂设备按需裁剪。你看到的通信状态、控制状态、事件报告、报警上报、远程命令、配方管理、终端服务、时钟同步都属于 E30 的范畴。用表格概括起来更清楚标准作用层级联调中你见到它的地方SEMI E5 SECS-II消息层S1F13、S6F11 等消息 ID消息头结构格式码SEMI E37 HSMS传输层TCP 端口、Select/SelectAck、T3~T8 超时SEMI E30 GEM行为层通信状态、控制状态、事件、报警、配方、时钟这三层的关系可以类比成E5 是信封和信纸的格式E37 是邮递员的投递规则E30 是收信人收到信之后必须做出哪些反应。2.2 选型对比SECS/GEM vs Modbus vs 裸 TCP在设备联机场景里选型争论最常见的是“为什么不直接用 Modbus TCP”和“为什么不能自己定一套 JSON 协议”。这两问都有道理但放到 SECS/GEM 的适用场景里答案很清楚。Modbus TCP 的强项是 PLC 和传感器级别的点位读写寄存器地址定义简单轻量好上手。但它在事件驱动、消息语义、报告结构上有天然短板采集事件来了要主动推送报警要带等级和文本配方要整体下载和校验Modbus 点位轮询做这些事既慢又别扭而且每个设备厂商的点位表都不一样集成软件没法复用。裸 TCP 自由度最高想发什么发什么很多设备厂商内部的私有协议就是这么做的。但代价是每接入一种设备MES 团队就要写一套解析设备升级版本、改字段解析代码要跟着改两套协议之间联调一旦出问题责任边界很难扯清楚。SECS/GEM 的价值在于“标准化消息语义”S1F13 就是协商通信S6F11 就是事件报告S2F41 就是远程命令接口通了业务方看到的消息 ID 是一致的。另一个常被忽略的选型理由是订阅机制。GEM 的每个报警、采集事件、跟踪数据的订阅都是单独管理的设备端作为消息代理只发布主机订阅过的内容未订阅的数据不会出现在网络上。这意味着一个复杂设备可以同时服务多套工厂应用而不会把无关数据堆到带宽里。再加上消息体是紧凑二进制比 JSON/XML 少很多键名开销原文里有个典型事件报告对比同样一组 32 字节实际数据SECS 的开销主要是 10 字节消息头加 1~4 字节长度描述而 JSON 和 XML 的键名和标签会把数据密度拖低一大截。对高频率事件上报的机台这个差异是实打实的。2.3 从文档里抄一张术语对照表读 SECS/GEM 资料时术语不一致是新手最大的障碍。同一个概念厂商文档叫 Collection Event标准里叫 CEID演示代码里又写成 EVENT_ID。这份文档的第三章专门整理了常用术语建议直接拿来当速查。英文术语中文俗称一句话含义Host / Equipment主机 / 设备通信两端工厂系统侧和机台侧Stream / Function消息大类 / 小类S1F13 表示 Stream 1 Function 13Message ID消息 IDStream 和 Function 的组合标识W-bit等待位置 1 表示要求对方应答System Bytes系统字节事务 ID用于回复和报文配对Collection Event采集事件设备侧发生的、可上报的业务事件Report / Data ID报告 / 数据 ID事件预计上报的数据集合标识Alarm报警设备异常或状态变化的上报Recipe配方 / 加工程序一组加工参数可下载和校验Terminal Service终端服务在设备屏幕上显示文本消息Spooling假脱机断线期间缓存消息重连后补发NVS非易失存储掉电不丢的存储区域假脱机依赖它我的习惯是把这张表打印出来放在工位上遇到厂商文档里看不懂的缩写先来这里查一圈。术语通了后面读格式码和消息日志才有抓手。3. Streams and Functions 实操把指令分类、消息头与日志读透Streams and Functions 是 SECS/GEM 消息系统的骨架。理解它不只是记几个消息编号而是要读懂分类逻辑、系统保留区和自定义区的关系以及一条消息从发出到收到应答的完整事务过程。日志分析也是从这里入手的。3.1 Stream 分类与系统保留区为什么公共区是有限的Stream 是消息的大类Function 是大类下的具体功能编号。标准用“SxFy”表示一条消息比如 S1F13 表示 Stream 1 的 Function 13。消息头里 Stream 和 Function 合起来占了两个字节其中 Stream 占 6 位Function 占 10 位因此理论上最多可以表达 64 个 Stream 和 1024 个 Function。但真正被标准定义的是前面一小段后面的空间留给厂商自定义。常见分类大致如下Stream归类用途S0系统消息通信建立、通信测试等基础消息S1设备状态请求设备状态、查询数据变量S2设备控制远程命令、定义报告、定义采集事件S5异常告警报警上报和确认S6数据收集事件报告、追踪数据发送S7加工程序管理配方上传、下载、校验S9错误消息对端无法识别的错误反馈S10终端服务终端文本显示、请求输入这里特别提醒Stream 0~127 是系统保留区128~255 通常留给厂商自定义。实际联调中厂商私有功能往往会占用保留区这不算违约但两边需要提前把消息映射表对齐。协议里“系统保留与自定义”的边界不是安全边界而是兼容边界用了自定义区就意味着这套消息只能在特定厂商的特定设备版本里有效。3.2 高频指令速查表与业务含义联机开始后最先用到的消息基本集中在 S1、S2、S5、S6、S7、S10 这几个 Stream 里。我把常见消息列成速查表联调时对着它查消息方向和数据含义比翻几百页标准快得多。消息 ID方向业务含义和典型内容S1F13 / S1F14H-E / E-H建立通信请求/应答联机第一步S1F3 / S1F4H-E / E-H请求设备状态变量返回变量名和值列表S2F33 / S2F34H-E / E-H定义报告主机把多个数据变量绑到报告 ID 上S2F35 / S2F36H-E / E-H定义采集事件把报告链路到具体事件上S2F41 / S2F42H-E / E-H远程命令比如切换配方、执行清洗、开始生产S5F1 / S5F2E-H / H-E报警上报/应答含报警 ID、等级、文本S6F11 / S6F12E-H / H-E事件报告/应答含事件 ID、报告 ID、数据值S7F5 / S7F6H-E / E-H加工程序请求/返回用于配方校验和比对S10F3 / S10F4双向终端文本消息/应答设备屏幕显示S9F1E-H无法识别消息 ID格式错或 Stream/Function 非法S6F11 是日常出镜率最高的消息。设备侧发生了一个采集事件会按定义好的 Report 把一组数据变量值打包发上来。这条消息的正文通常是“List 包 List”的嵌套结构最外层是 Data ID、采集事件 ID里面是 Report ID 加一个或多个变量值。调试时不要指望数据顺序和设备厂商文档完全一致要按 Report 定义逐个字段解析少一个字节都可能让整包解析错位。3.3 用消息日志复原一次联机握手日志分析是 SECS/GEM 排错的基本功。抓包或者从设备端导出消息日志之后别急着看报文正文先按事务把消息配对再去看每个字段。我的常规读法分四步。第一步按时间戳把消息排序去掉重复帧和心跳帧保留完整的事务记录。第二步按 System Bytes 配对同一条事务的请求和应答System Bytes 一定相同。请求带 W-bit 置 1应答必须存在W-bit 为 0则对端可以不应答。第三步按 Stream/Function 判断业务类型对照速查表看语义是否合理。第四步再看消息正文里的格式码和数据值确认字段类型和长度对得上。以一次典型的联机为例消息日志通常长这样时刻方向System Bytes消息业务动作00:00:00.123H-EA1B2C3D4S1F13协商通信W-bit100:00:00.156E-HA1B2C3D4S1F14同意通信00:00:01.200H-EA1B2C3D5S2F33定义报告绑定变量00:00:01.280E-HA1B2C3D5S2F34定义成功00:00:02.100E-HA1B2C3D6S6F11上报设备状态事件00:00:02.130H-EA1B2C3D6S6F12确认收到如果日志里出现“S1F13 发了但 S1F14 一直没回来”问题大概率在设备端没有正确响应而不是 TCP 不通。如果“S6F11 连发几条、S6F12 一条都没回”先查主机程序是不是把事务配对逻辑写错了再看是不是没有正确处理异步上报。日志能还原事实接下来才能决定调整哪一端。4. 避坑清单超时、状态机、格式码和日志里最常翻车的四件事SECS/GEM 项目里十个有九个翻车翻的不是协议本身而是对超时参数、状态模型和格式码的误用。把这些坑写出来比重新读一遍标准更有用。以下四条是我在多个机台联调里反复踩过、也看别人踩过的真实案例。4.1 四类高频翻车记录现象一设备上线后主机日志里 T3 超时刷屏S6F11 事件报告发出去S6F12 确认迟迟不来。排查半天发现不是网络问题而是设备端事件队列拥堵主机一口气订阅了几百个事件设备把所有上报都压在同一线程里处理不过来。原因事件订阅范围过大、数据变量过多超出了设备端一次上报的处理能力主机侧的应答线程又被其他事务阻塞。解决把订阅范围缩小优先订阅真正需要的事件报告里的变量数量精简确认主机应答线程在处理 S6F12 时没有被其他同步操作卡死。T3 超时可以适当调大但调大只是给设备争取时间不是治本。现象二联调时 TCP 端口已经通Select 也成功但主机发 S1F13 一直得不到 S1F14日志里反复出现连接断开重连。原因设备 ID 不一致。主机侧把 Device ID 配成 1设备侧实际配置是 2消息头的设备 ID 字段对不上设备直接丢弃消息。解决联调前先核对设备面板或配置文件里的通信参数Device ID、端口号、IP、消息头里的设备 ID 四者必须完全一致。项目上最常见的低级错误就是 Device ID 配错。现象三主机发 S2F41 远程命令设备返回 S9F1 无法识别消息。看设备端日志消息头解析成功但正文格式码和期望不符。原因格式码表用错。SECS 的格式码区分明确ASCII 文本要用 A4 字节整型用 I48 字节浮点用 F8。有的代码库把所有参数都按整数打包配方路径这种字符串也强行转成数值设备端解析自然失败。解决把所有消息正文的格式码核对一遍字符串用字符串格式码数值用数值格式码布尔量用布尔格式码。不要依赖“反正对方能猜”这种想法SECS 的格式码不匹配就是硬错误。现象四机台网络断开几秒再恢复主机和设备的会话就再也建立不起来必须人工重启设备端软件才恢复。原因HSMS 状态机没有被正确驱动。设备在断网后进入了 Not Selected 状态T5 分离超时没有触发重新监听或者主机侧没有按状态迁移规则重新发起 Select。解决按协议要求处理 Not Connected、Not Selected、Selected 的状态迁移网络恢复后主动重新 Select而不是等待设备端来连。联调时专门做一次人为拔网线测试确认自动恢复路径是通的。4.2 超时参数别乱改T3~T8 各有各的脾气超时参数是 SECS/GEM 联调里最容易被误操作的地方。厂商不给参数清单工程师只能从设备配置界面手动调调多了又出新的问题。超时名称只管什么误改后果T3Reply Timeout等待对端回复的时间太小误报超时太大掩盖性能问题T4Connect TimeoutTCP 连接建立超时网络差时频繁断连T5Separation Timeout分离后会话保持时间影响断线重连体验T6Control Transaction TimeoutHSMS 控制事务超时Select 流程异常T7Not Selected Timeout未选择连接保持时间常驻连接被提前断开T8Network Intercharacter Timeout接收字符间隔超时误判网络丢包为协议错误我见过一个项目把 T3 从 45 秒改成 5 秒因为测试时“觉得响应慢”结果生产环境高峰期事件上报稍微排队就大面积超时。改超时之前先把慢的根因找到是设备处理慢、网络延迟高还是主机线程阻塞。超时参数是兜底机制不是性能调优工具。4.3 通信状态与控制状态两个维度别混在一起看GEM 协议里通信状态和控制状态是两条独立的轴。通信状态描述的是 HSMS 连接是否建立Not Connected 到 Not Selected 到 Selected。控制状态描述的是设备允许主机控制到什么程度OFFLINE、ONLINE-LOCAL、ONLINE-REMOTE。很多联调问题出在“物理链路通了就以为设备可以接受远程命令”主机发 S2F41 下发配方设备没有任何响应其实设备控制状态还在 OFFLINE操作员在设备侧把状态切到 REMOTE命令立刻生效。判断问题时先分清是通信问题还是控制问题。通信问题看 TCP 和 Select 状态机控制问题看设备面板上的模式指示灯和状态反馈。两份状态模型在协议里是分开定义的排查日志时也要分开看千万别混在一起猜。5. 验证协议栈的两个笨招日志回放与状态迁移自检协议栈写完之后最怕的是“开发环境跑通了搬进车间就哑”。先别急着接真实机台我在项目上会强制做两个笨验证日志回放和状态迁移自检。这两个动作都不需要复杂工具但能挡掉大部分低级故障。5.1 日志回放按 System Bytes 重放一遍历史会话拿厂商提供的真实机台消息日志或者在测试环境抓的一整段联机会话按时间戳回放。回放时只看三件事每条带 W-bit 的消息是否都有对应应答每对请求/应答的 System Bytes 是否一致每个 S6F11 事件报告里的 Report ID 是否能对应到定义过的报告。如果开发环境用的消息日志是手工造的假数据务必先拿生产现场的真实日志换一遍再做回放。假日志通常太干净没有乱序、没有重复帧、没有设备主动上报的意外消息回放出来意义不大。5.2 状态迁移自检清单每次联调新机台我都会把下面这组状态迁移走一遍从完全断电到上电设备是否能进入 Not Connected再被主机 Select 成 Selected主机把连接断掉设备是否在 T5 后正确进入 Not Selected再能自动重连设备控制状态从 OFFLINE 切到 ONLINE-REMOTE主机远程命令是否立即生效切回 ONLINE-LOCAL 后主机命令是否被明确拒绝而不是被静默忽略人为拔网线 3 分钟恢复后主机和设备能否自动恢复会话期间产生的事件报告是否通过假脱机补发有一次测试里假脱机补发没有生效设备在断网期间把事件报告存进了非易失存储重连后也按协议重发了但主机侧的去重逻辑只认 System Bytes发现重发的报文和原报文 System Bytes 相同直接丢弃了。实际断网期间的数据就这样丢了。后来我在主机侧加了序号校验并让设备端日志和主机端日志按时间戳对账才把这类问题暴露出来。从那以后我每次联调都强制走一遍日志回放和状态迁移自检宁可多花半天也绝不让问题带到量产阶段。希望帮到你。本文还有配套的精品资源点击获取