简介面向半导体及通用制造设备工程师的 SECS/GEM 中文学习文档针对协议资料分散、细节不足的问题系统梳理设备通信集成所需的基础概念与实战要点。压缩包共 1 个 PDF 文件约 955KB篇幅精炼但目录完整便于随身查阅和按章节检索。内容以十章展开从降低设备集成成本、适用设备范围、网络带宽利用与安全机制讲起延伸到消息日志、常用术语、Stream 与 Function 的分类、系统保留与自定义规则以及具体指令含义和使用场景能帮助读者建立从协议入门到接口调试的知识框架。已有 2272 人学习适合设备集成、上位机开发和产线运维人员查漏补缺也可作为团队内部培训的参考材料。1. 什么是 SECS/GEM设备与工厂之间的一门“普通话”想象一条产线几十台设备来自不同厂家每台设备的软件脾气都不一样。有的用私有协议往外吐数据有的只认自家上位机有的连“我这边报警了”都得靠人跑过去看一眼指示灯。工厂想把它们拧成一股绳最省事的办法不是给每台设备配一个翻译而是让所有设备都学同一门普通话。SECS/GEM 就是这门普通话——一份规定了制造设备与工厂主机之间怎么打招呼、怎么报数据、怎么接指令的行业标准。搜“SECS/GEM 中文详解”的人多半是被那几个缩写砸懵了E5、E37、E30、SxFy、HSMS散落在各处看得见字却拼不成一张图。这篇就把这门普通话从头讲一遍它由哪几块拼成、每条指令名怎么读、链路跑起来之后看什么、哪些地方最容易认错最后说清楚什么情况下值得上、什么情况下先别急。2. 三份标准各管一段SECS/GEM 为什么非要拆开讲很多人第一次看到 SECS/GEM以为它是一个协议的名字。其实它是三个字母的合称背后站着三份各管一段的标准E5、E37、E30。分开不是为了显得复杂而是因为“说什么”“怎么送”“做什么”本来就是三件可以独立更换的事。打个比方寄快递要填单子内容长什么样、要走运输网络用什么方式送、还要有一套服务条款哪些东西能寄、丢了怎么办。三件事拆开谁想升级哪一段就升级哪一段不用推倒重来。2.1 E5 管“说什么”一张通用的消息骨架SECS-IIE5定义的是一个通用的消息结构外加一个包含许多标准化消息的库。关键在“通用”两个字它没有规定设备必须发什么只规定了发出去的东西长什么样。每条消息由一串数据项组成每个数据项带一个格式码标明自己是整数、浮点、字符串还是布尔。收的一方不需要事先知道对方是哪家厂的设备只要按格式码读就能把结构还原出来。这种设计顺带解决了一个老问题——无数据翻译。传统做法里A 厂设备给 B 厂主机发数据中间往往要架一层转换软件把私有格式翻成对方能吃的格式翻译层越多出错点越多延迟也越长。SECS-II 把格式统一在消息本身设备发出去的就是主机能直接读懂的结构中间那一层可以拿掉。举个最常见的例子双方第一次建立通信时的消息体可能就长这样# 一条 S1F13建立通信请求的消息体用列表模拟数据项序列 # 每个元组的第一位是格式码L列表AASCII 字符串 body [ (L, 2), # 列表结构告诉对方我下面有 2 项 (A, EQP-01), # 第 1 项设备标识ASCII (A, 1.0.0), # 第 2 项软件版本ASCII ]这段不是真代码是把消息的层次关系摊开给人看。L 表示列表后面的数字是子项个数A 表示 ASCII 字符串。真实传输时这些字符不会原样出现格式码会被压成一个字节字符串前面缀上长度字节整条消息再套上 10 字节的消息头。看懂了这个结构再去看任何一条 SxFy 的定义无非是“一个列表里装了几项、每项是什么格式”。2.2 E37 管“怎么送”把消息塞进 TCP/IP消息有了形状还得有路。HSMSE37干的就是这件事它定义了使用 TCP/IP 传输 SECS-II 消息的二进制结构。注意关键词是“二进制结构”——不是把消息转成文本再发而是按字节直接铺在连接上。这一层解决的是工程上最烦的几个问题连接怎么建立、谁先开口、连上之后怎么判断对方还活着、一条消息发出去多久没回信算失败。HSMS 给出的答案是一套状态机和一组定时器。设备刚启动时处在未连接状态主动去连主机的端口或者监听主机来连连上之后进入“已连接但未选中”双方交换几轮控制消息确认彼此的身份和能力才能进入“已选中”正式传业务数据。提示调试时最常见的现象是“网络能通、端口也通但业务消息一条都不动”八成是卡在“已连接未选中”这一段而不是网络问题。2.3 E30 管“做什么”GEM 是一份功能清单不是协议GEME30最容易被误解。它不定义新的报文格式也不管传输它定义的是一组最低要求、附加可选功能、用例以及部分 SECS-II 消息的用户场景。说白了GEM 回答的是“一台设备要对外提供哪些能力才算得上一台能被主机管起来的设备”。最低要求像是入场券设备要能被主机识别、要能上报自己当前的状态、要能发事件、要能响应几条基本查询。附加功能则是选配配方管理、报警管理、远程命令、跟踪数据、假脱机。为什么做成可选因为不是所有设备都用得上。原文举的例子很直白——有些设备压根没有配方那就没必要实现配方管理这一大块功能。这也解释了为什么 SECS/GEM 能落在各种规模的设备上。一台很简单的设备可能只发布 10 个不同的采集事件一台复杂的设备可能发布 5000 个两者用的是同一套技术区别只在数量不在机制。设备商不必因为自己的产品“太小”就被挡在标准门外也不必一上来就把所有高级功能全做齐可以先把入场券拿到再按客户需求往上加。2.4 拆成三层换来的四件事三层拆开之后落在工厂和设备商身上的收益很具体。第一是集成成本。工厂往往从多家设备商买设备每家控制软件都不一样。给每台设备单独写定制集成软件做得出但不划算而且定制软件写起来贵、维护起来更贵质量还常常低于预期。设备商那边同样难受产品卖到不同工厂每个工厂的数据采集和应用软件都不同等于每进一个新客户就要重做一遍对接。标准接口把这个循环打断了——设备商做一套接口卖给所有客户工厂用同一套集成软件对接所有设备双方的软件都能复用。复用带来的是质量上升、成本下降省下来的预算才有机会投到更高级的功能上。第二是适用范围。基础需求必做、附加功能选做这个分层让 SECS/GEM 可以按数据规模伸缩从几十个采集事件的小设备到几千个采集事件的大设备用的是同一种技术。第三是带宽效率。每个 SECS/GEM 接口本身充当消息代理主机没订阅的数据不会往网络上发。要收报警、要收采集事件、要跟踪数据都得先订阅而且每一项订阅独立管理。所以一台设备可以实现一个接口同时满足多个工厂应用的需求又不会因为没人要的数据把带宽吃掉。订阅跟踪数据时还能指定采集速率比那种“按写死的频率往外播”的协议灵活得多。加上消息一律走二进制比 ASCII 格式的协议省带宽。第四是链路本身的可信度。设备与主机之间直接交换结构化的原始数据不需要中间转换层链路短、错误面小、延迟低维护时也不用顺着一堆中间件找问题。原文里“环路保证”和“安全”这两条讲的是同一类事链路要能证明自己是通的、是闭环的而不是发出去就不管了。这一点在自动化产线上尤其要紧——主机发了一条指令它必须知道设备到底收没收到、执行没执行。3. Streams 与 Functions指令名的“姓”与“名”每条 SECS-II 消息都有一个编号写成 SxFy比如 S1F1、S6F11、S10F3。第一次看像乱码其实是一套很规整的命名法记住规则比死背编号有用得多。3.1 SxFy 这个写法到底怎么读S 后面的数字是 Stream流F 后面的数字是 Function功能。Stream 大致可以理解成“消息的姓”按大用途分组Function 是“名”在同一个姓下面区分具体动作。S6F11 就是“第 6 族里的第 11 号动作”。同一族里的奇数、偶数常常配对主机发 S1F1 问“你在吗”设备回 S1F2 说“我在这是我的信息”。奇数一般由发起方发出偶数是对应的回复这条规律覆盖了大量常见的请求/回复对记住它能省不少查表时间。但配对不是绝对的遇到具体编号还是要翻一眼定义别凭感觉套。配对的另一半是 W 位。消息头里有一位叫 WWait bit置 1 表示“这条消息必须给我一个回复”置 0 表示“发完就完不用回”。同一条 SxFyW 位不同行为完全不同。设备发事件报告时把 W 位置 1主机就必须回一条对应的确认置 0 则设备发完继续干活主机回不回它都不等。所以看文档时不能只看 SxFy得连 W 位一起看否则很容易出现“我明明回了它为什么还超时”的困惑——很可能是回的消息编号不对或者对方那条压根没要求回复。3.2 Stream 按“干什么用”分类Stream 的划分不按设备品牌按用途。常见的几族大致是这样Stream大致用途典型例子S0系统层管链路本身的建立与维护建立通信、在线确认、时间询问S1设备状态与基本身份状态查询、上线通知、在线/离线切换S2设备控制与诊断远程命令、时间同步、设备常数S5报警报警上报、报警查询、报警使能S6数据收集事件报告、跟踪数据S7配方与工艺程序配方上传、下载、列表S9错误识别出错的报文S10终端服务往操作员屏幕推一行字这张表不用背记住“按用途分族”这个思路就够了。真到对接时顺序是先看要办什么事再定位到族最后翻具体编号。比如要往操作员屏幕上打一行“请更换料盒”先想到“这是给人看的提示”落到 S10再查到具体的那一对。3.3 系统保留区与自定义区Stream 和 Function 的编号空间不是随便用的分成系统保留和自定义两段。系统保留段由标准定义含义固定谁都不能改自定义段留给设备商和工厂自己约定用来传标准没覆盖的数据。为什么需要自定义区因为标准不可能预见到所有设备的特殊性。某台设备有个独有传感器想把读数传给主机标准里没有对应的消息就只能在自定义段里开一条两端约定好格式。代价是这条消息不再通用——换一台设备、换一套主机就得重新约定一次。所以实践中的原则是能用标准消息就用标准消息实在没有再动自定义区而且一旦动了就得把约定写成文档别只留在某个人的脑子里。注意自定义段的消息不要和标准消息混用同一个编号否则将来标准升级、编号被占用对接会出问题。3.4 从一条消息到一次完整的业务单看一条消息没什么意义SECS/GEM 的威力在于把消息串成流程。以数据收集为例主机先发一条建立报告链接的消息告诉设备“我要这几个变量打包成这个报告编号”设备记下来之后设备每次采到数据发一条带事件编号和报告编号的消息主机按之前的约定解析。整个过程里主机只订阅自己真正要的东西设备也只发被订阅的部分。这也是为什么前面说“接口充当消息代理”。代理在设备上跑它知道谁订阅了什么没订阅的数据根本不出设备。如果主机临时断开设备也不会把数据丢了——GEM 的假脱机功能会把这段时间该发的消息存进非易失性存储等主机回来再补发。这一条后面还会碰到它是最容易被忽略、也最容易在事故复盘时被翻出来的一项能力。4. 连接、超时与日志链路跑起来之后看什么前面的章节讲的是“消息长什么样、叫什么名字”。真把线接上、端口配好之后工程上遇到的绝大多数问题不在消息内容而在链路状态和时序。这一段讲的就是上线之后盯什么。4.1 HSMS 的三段连接状态HSMS 的连接状态分三段未连接、已连接但未选中、已选中。刚启动时是未连接一端主动去连另一端的端口或者被动监听连接建立之后进入第二段此时通道是通的但双方还不能传业务消息得先交换控制消息确认对方是谁、支持什么确认通过才进入第三段业务消息才被允许通过。这套设计的用意是把“线通了”和“人认识了”分开。线通了不代表对方是你要找的那台设备也可能是另一台设备连错了端口。先握手确认身份再放业务数据比连上就发要稳得多。代价是多了一次状态切换调试时需要知道有这么一个中间态。提示如果日志里能看到连接建立记录但一条业务消息都没有先检查是不是一直停在第二段。很多时候是两边的端口配置对上了但选通条件没满足。4.2 控制状态谁在“在线”除了链路状态还有一层控制状态回答的是“这台设备此刻听谁的”。设备可以处于本地状态——现场操作员在面板上按按钮也可以处于远程状态——主机在指挥。同样设备对主机而言有在线和离线两种。这两组状态交叉起来就有四种组合每种组合下能做什么事都不一样。主机想让设备进入在线会发一条在线请求设备同意后回一条确认想让它退出就发离线请求。看似简单实际项目中出问题最多的恰恰是这里主机以为设备在线一直在发命令设备那边因为某个条件没满足其实还停在本地模式命令全被丢掉从主机侧看就是“发出去没反应”。排查这类问题第一件事是核对两边的状态显示而不是怀疑消息格式。4.3 超时定时器链路不通时先看哪几个数SECS/GEM 给链路上的每一段等待都定义了定时器业界习惯用 T 加编号来称呼。原文对这些超时事件有专门一节这里挑几个最常打交道的说定时器管什么超时之后通常意味着T1发出一条需要回复的消息后等对方回复的时间对方没收到、收到没处理、或处理完没回T2发出控制消息后等对方控制消息的时间协议层握手卡住T3等待连接建立完成的时间端口不通、地址配错、对端没起服务T5连接断开后等待重新连上的时间网络抖动或对端重启T6一次控制事务从开始到结束的时间事务被中途打断T7未选中状态下等待恢复的时间选通流程没有走完T8单个字符之间的间隔时间链路质量差字节流被拉长具体秒数标准给了推荐区间实际项目里往往按工厂规范再调。这里不需要背数值需要建立的是判断顺序先看 T3确认连接能不能建起来再看 T2 和 T7确认握手和选通是否完成最后看 T1确认业务消息有没有回。按这个顺序走能少走很多弯路。这些年踩过的坑里最常见的翻车方式是把 T1 调得特别大企图“多等一会儿就回来了”。等待时间拉长只会让问题暴露得更晚真正该做的是看日志确认对方到底收没收到。4.4 消息日志出问题时的黑匣子消息日志记录每条收发的消息带时间戳、方向、编号。它平时不起眼出事时是唯一的现场证据。没有日志只能靠猜是没发出去、发出去了对方没回、还是回了但解析错了有日志顺着时间线一看谁先发的、谁没回、回的是什么编号一目了然。一份有用的日志至少要包含四个信息时间、方向、消息编号含 W 位、消息体摘要。少了方向分不清是谁发的少了 W 位判断不了这条该不该有回复。很多现场问题最后能定位靠的就是把日志按时间排开发现某条消息的回复编号和请求对不上——设备回了个偶数主机却在等另一个偶数。4.5 数据密度的账怎么算二进制传输到底省在哪值得单独算一笔。原文给了一个典型例子一条事件报告里含 2 个 4 字节整数、2 个 8 字节浮点数、1 个 4 字节事件编号、1 个 4 字节报告编号真正的业务数据是 32 字节。SECS 的固定开销是消息头 10 个字节加上描述消息体大小的 1 到 4 个字节。每个数据项在线上还要带 1 字节格式码和 1 字节长度。算一算# 估算一条事件报告在线上实际占用的字节数 HEADER 10 # 消息头固定 10 字节 BODY_LEN 4 # 消息体长度字段按最多的 4 字节算 def item_bytes(value_size): 单个数据项的线上开销1 字节格式码 1 字节长度 值本身 return 1 1 value_size items [ item_bytes(4), # 4 字节整数 item_bytes(4), # 4 字节整数 item_bytes(8), # 8 字节浮点 item_bytes(8), # 8 字节浮点 item_bytes(4), # 事件编号 item_bytes(4), # 报告编号 ] payload 32 # 真正有用的业务数据 wire HEADER BODY_LEN sum(items) print(payload, wire, round(payload / wire, 2))算下来业务数据 32 字节线上大约 60 字节密度五成出头。这个比例不算惊艳因为数据项太少固定开销摊不薄。原文里还有一个更有说服力的对照把这条消息换成 100 个 8 字节浮点数数据项一多同样的固定开销被摊到 800 字节业务数据上SECS 的数据密度就升到 78% 左右——用上面的算法复算结果基本对得上。同样的内容用 JSON 或 XML 表达键名和标签会随数据量一起膨胀密度提升远没有这么明显。这就是二进制的价值小包看开销大包看密度。设备上报的数据量越大、频率越高这个差距累积起来就越可观。反过来如果一台设备一天只发几条状态消息省下来的带宽意义有限这时候带宽不该成为选型的主要理由。5. 最容易混的几个概念初学者踩坑清单概念讲到这里大部分名词已经能对上号了。真正让人栽跟头的往往是几个听起来差不多、实际差很远的东西。下面这五组是对接现场最常被问混的。5.1 误区一把 SECS 和 GEM 当成一个东西易混点口语里常说“这台设备支持 SECS/GEM”听上去像一个协议。为什么混两者永远同时出现缺一个都对接不起来久而久之就被当成一体。怎么区分SECS 是“怎么说”管消息格式和传输GEM 是“说什么、做什么”管功能清单和场景。一台设备可以只实现 SECS 不实现 GEM——能通信但主机管不动它因为该有的功能一个都没有。反过来不成立GEM 建立在 SECS 之上没有 SECS 就没有 GEM。跟人沟通的时候说“支持 SECS”只代表链路能通说“支持 GEM”才代表业务能跑。5.2 误区二把 S1F1 当成心跳易混点不少资料把 S1F1/S1F2 说成“心跳包”。为什么混它确实经常被周期性发出去形式上很像心跳。怎么区分S1F1 是身份询问回答里带的是设备信息它的用途是确认“你是哪台设备、还在不在”而链路层真正的心跳由 HSMS 自己的控制消息负责不占 SECS-II 的编号。判断链路是否活着看控制消息判断设备是否在线看控制状态。把这两件事混在一起会出现“心跳一直在发但业务消息全超时”的怪现象——链路活着业务层没握手。5.3 误区三以为事件报告是设备随便推易混点从主机侧看数据确实是设备主动发过来的像是“设备一有变化就推”。为什么混推的行为太明显让人忽略了推之前的约定。怎么区分推之前必须先订阅。主机要先发建立报告链接的消息约定好事件编号、报告编号、变量清单设备才有东西可发。没订阅设备不会主动推也没有义务推。这一条对带宽的意义很大——正是因为有订阅机制设备才不会把全量数据往网络上广播。5.4 误区四把假脱机和消息日志当成一回事易混点两者都跟“把消息存起来”有关形式上都落盘。为什么混名字里都带“记录”的意味而且经常在同一个调试场景里被同时提到。怎么区分消息日志是给人看的诊断记录通常调试期才打开量小不负责重发假脱机是给主机补课的业务机制当主机不可用时设备把该发而没发出去的消息存进非易失性存储等主机恢复后按顺序补发保证不丢。日志丢了顶多难排查假脱机里存的东西丢了就是数据缺口事后要花大力气补。5.5 误区五把报警管理和数据收集混成一套易混点报警本身也是一种“事件”看起来完全可以塞进数据收集里一起上报。为什么混两者都靠 S5/S6 往外发触发方式也像——条件满足就报。怎么区分报警有独立编号、独立使能状态、独立的清除逻辑主机要单独订阅、单独确认还要能区分“发生”和“解除”两种状态。数据收集管的是过程变量和状态量是连续的量报警管的是异常的发生与消除是成对的事件。把报警硬塞进采集事件最直接的后果是丢掉“解除”这一半事后看记录只看到报警发生看不到什么时候恢复复盘时根本还原不出时间线。注意这五组里最容易在项目后期造成返工的是第三组和第五组。前者影响数据能不能收到后者影响数据收到之后能不能解释。6. 什么时候该上 SECS/GEM什么时候先别急讲到这里概念和边界都清楚了剩下的问题很实际我这台设备、我这个厂到底要不要上。6.1 三种值得上的情况第一种设备要卖进多供应商混线的产线。买方的产线里已经有别人的设备主机软件也跑起来了你的设备如果只有私有协议买方要么让你改、要么让你加转换层成本最后都会回到设备价格上。做一套符合标准的接口等于一次投入、所有客户复用。第二种工厂要把人从设备旁边撤走。SECS/GEM 让设备上发生的事都能被追踪到支持远程控制和系统配置。设备发布的数据越多工厂能实现的应用就越多——统计工艺控制、故障排查、预测性维护、前后馈工艺控制、设备利用率、物料跟踪、配方校验。这些应用减少了对设备面板的依赖操作员数量跟着下降。第三种配方和追溯要求高。把黄金配方存在工厂的中央存储里通过接口下发并校验能显著减少用错配方造成的报废。这类需求一旦出现靠人工核对是撑不住的。6.2 三种可以先放一放的情况第一种单机台、单工序压根没有主机。设备自己跑自己的数据存在本地没有人来订阅上一整套标准接口就是空转。第二种数据量极小、频次极低。一天几条状态消息人工记录完全够用此时二进制省带宽、订阅省流量这些优势都体现不出来。第三种团队里没人能长期维护这条链路。这一点最容易被低估。SECS/GEM 不是装完就完的东西状态机、定时器、订阅关系、假脱机存储任何一处配置漂移都会在某个夜班爆发。如果没有人能看懂消息日志、能判断是链路问题还是业务问题那么这条链路迟早会变成一个没人敢碰的黑匣子。上之前先想清楚出了事谁来看。6.3 一个具体例子新设备进场假设某实验室引进一台新设备要接进已有的主机系统。比较稳的顺序是这样先确认设备支持哪些 Stream、实现了哪些 GEM 功能。这一步不是看宣传页而是看设备提供的接口文档重点确认基础需求是否齐全、附加功能里哪些是选配、自定义段有没有额外约定。再配网络。确认端口、地址、谁是主动连接方。这一段做完先别急着发业务消息把连接建起来确认能走到“已选中”。然后跑最基本的身份确认看设备回的标识和版本对不对。对不上就先停下来查配置别往下走。接着建立一条最小的事件报告只订阅一两个变量观察设备是否按约定上报。这一步跑通说明订阅关系和消息结构都对。最后再打开假脱机测一次主机断开、设备继续跑、主机恢复后补发的完整流程。整个过程里消息日志从第一步就要打开。这不是流程要求是血泪经验——很多问题在现象消失之后就再也复现不出来只有日志还留着。从那以后我每次接新设备都会先把消息日志打开再连线宁可多花十分钟看日志也不要在半夜被叫起来猜是哪条消息没回。上面这套顺序还有 Streams 的分类、超时定时器的排查路径、五组易混概念的区分方式都收在这份 SECS/GEM 中文详解资料里十章内容从协议介绍一路讲到消息日志、格式码、通信状态和常用功能需要的时候按章节翻比在零散帖子之间来回跳要省事得多。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/27 2:09:11 · 阅读 1.2k SECS/GEM中文详解：E5/E37/E30、HSMS与链路排障
简介面向半导体及通用制造设备工程师的 SECS/GEM 中文学习文档针对协议资料分散、细节不足的问题系统梳理设备通信集成所需的基础概念与实战要点。压缩包共 1 个 PDF 文件约 955KB篇幅精炼但目录完整便于随身查阅和按章节检索。内容以十章展开从降低设备集成成本、适用设备范围、网络带宽利用与安全机制讲起延伸到消息日志、常用术语、Stream 与 Function 的分类、系统保留与自定义规则以及具体指令含义和使用场景能帮助读者建立从协议入门到接口调试的知识框架。已有 2272 人学习适合设备集成、上位机开发和产线运维人员查漏补缺也可作为团队内部培训的参考材料。1. 什么是 SECS/GEM设备与工厂之间的一门“普通话”想象一条产线几十台设备来自不同厂家每台设备的软件脾气都不一样。有的用私有协议往外吐数据有的只认自家上位机有的连“我这边报警了”都得靠人跑过去看一眼指示灯。工厂想把它们拧成一股绳最省事的办法不是给每台设备配一个翻译而是让所有设备都学同一门普通话。SECS/GEM 就是这门普通话——一份规定了制造设备与工厂主机之间怎么打招呼、怎么报数据、怎么接指令的行业标准。搜“SECS/GEM 中文详解”的人多半是被那几个缩写砸懵了E5、E37、E30、SxFy、HSMS散落在各处看得见字却拼不成一张图。这篇就把这门普通话从头讲一遍它由哪几块拼成、每条指令名怎么读、链路跑起来之后看什么、哪些地方最容易认错最后说清楚什么情况下值得上、什么情况下先别急。2. 三份标准各管一段SECS/GEM 为什么非要拆开讲很多人第一次看到 SECS/GEM以为它是一个协议的名字。其实它是三个字母的合称背后站着三份各管一段的标准E5、E37、E30。分开不是为了显得复杂而是因为“说什么”“怎么送”“做什么”本来就是三件可以独立更换的事。打个比方寄快递要填单子内容长什么样、要走运输网络用什么方式送、还要有一套服务条款哪些东西能寄、丢了怎么办。三件事拆开谁想升级哪一段就升级哪一段不用推倒重来。2.1 E5 管“说什么”一张通用的消息骨架SECS-IIE5定义的是一个通用的消息结构外加一个包含许多标准化消息的库。关键在“通用”两个字它没有规定设备必须发什么只规定了发出去的东西长什么样。每条消息由一串数据项组成每个数据项带一个格式码标明自己是整数、浮点、字符串还是布尔。收的一方不需要事先知道对方是哪家厂的设备只要按格式码读就能把结构还原出来。这种设计顺带解决了一个老问题——无数据翻译。传统做法里A 厂设备给 B 厂主机发数据中间往往要架一层转换软件把私有格式翻成对方能吃的格式翻译层越多出错点越多延迟也越长。SECS-II 把格式统一在消息本身设备发出去的就是主机能直接读懂的结构中间那一层可以拿掉。举个最常见的例子双方第一次建立通信时的消息体可能就长这样# 一条 S1F13建立通信请求的消息体用列表模拟数据项序列 # 每个元组的第一位是格式码L列表AASCII 字符串 body [ (L, 2), # 列表结构告诉对方我下面有 2 项 (A, EQP-01), # 第 1 项设备标识ASCII (A, 1.0.0), # 第 2 项软件版本ASCII ]这段不是真代码是把消息的层次关系摊开给人看。L 表示列表后面的数字是子项个数A 表示 ASCII 字符串。真实传输时这些字符不会原样出现格式码会被压成一个字节字符串前面缀上长度字节整条消息再套上 10 字节的消息头。看懂了这个结构再去看任何一条 SxFy 的定义无非是“一个列表里装了几项、每项是什么格式”。2.2 E37 管“怎么送”把消息塞进 TCP/IP消息有了形状还得有路。HSMSE37干的就是这件事它定义了使用 TCP/IP 传输 SECS-II 消息的二进制结构。注意关键词是“二进制结构”——不是把消息转成文本再发而是按字节直接铺在连接上。这一层解决的是工程上最烦的几个问题连接怎么建立、谁先开口、连上之后怎么判断对方还活着、一条消息发出去多久没回信算失败。HSMS 给出的答案是一套状态机和一组定时器。设备刚启动时处在未连接状态主动去连主机的端口或者监听主机来连连上之后进入“已连接但未选中”双方交换几轮控制消息确认彼此的身份和能力才能进入“已选中”正式传业务数据。提示调试时最常见的现象是“网络能通、端口也通但业务消息一条都不动”八成是卡在“已连接未选中”这一段而不是网络问题。2.3 E30 管“做什么”GEM 是一份功能清单不是协议GEME30最容易被误解。它不定义新的报文格式也不管传输它定义的是一组最低要求、附加可选功能、用例以及部分 SECS-II 消息的用户场景。说白了GEM 回答的是“一台设备要对外提供哪些能力才算得上一台能被主机管起来的设备”。最低要求像是入场券设备要能被主机识别、要能上报自己当前的状态、要能发事件、要能响应几条基本查询。附加功能则是选配配方管理、报警管理、远程命令、跟踪数据、假脱机。为什么做成可选因为不是所有设备都用得上。原文举的例子很直白——有些设备压根没有配方那就没必要实现配方管理这一大块功能。这也解释了为什么 SECS/GEM 能落在各种规模的设备上。一台很简单的设备可能只发布 10 个不同的采集事件一台复杂的设备可能发布 5000 个两者用的是同一套技术区别只在数量不在机制。设备商不必因为自己的产品“太小”就被挡在标准门外也不必一上来就把所有高级功能全做齐可以先把入场券拿到再按客户需求往上加。2.4 拆成三层换来的四件事三层拆开之后落在工厂和设备商身上的收益很具体。第一是集成成本。工厂往往从多家设备商买设备每家控制软件都不一样。给每台设备单独写定制集成软件做得出但不划算而且定制软件写起来贵、维护起来更贵质量还常常低于预期。设备商那边同样难受产品卖到不同工厂每个工厂的数据采集和应用软件都不同等于每进一个新客户就要重做一遍对接。标准接口把这个循环打断了——设备商做一套接口卖给所有客户工厂用同一套集成软件对接所有设备双方的软件都能复用。复用带来的是质量上升、成本下降省下来的预算才有机会投到更高级的功能上。第二是适用范围。基础需求必做、附加功能选做这个分层让 SECS/GEM 可以按数据规模伸缩从几十个采集事件的小设备到几千个采集事件的大设备用的是同一种技术。第三是带宽效率。每个 SECS/GEM 接口本身充当消息代理主机没订阅的数据不会往网络上发。要收报警、要收采集事件、要跟踪数据都得先订阅而且每一项订阅独立管理。所以一台设备可以实现一个接口同时满足多个工厂应用的需求又不会因为没人要的数据把带宽吃掉。订阅跟踪数据时还能指定采集速率比那种“按写死的频率往外播”的协议灵活得多。加上消息一律走二进制比 ASCII 格式的协议省带宽。第四是链路本身的可信度。设备与主机之间直接交换结构化的原始数据不需要中间转换层链路短、错误面小、延迟低维护时也不用顺着一堆中间件找问题。原文里“环路保证”和“安全”这两条讲的是同一类事链路要能证明自己是通的、是闭环的而不是发出去就不管了。这一点在自动化产线上尤其要紧——主机发了一条指令它必须知道设备到底收没收到、执行没执行。3. Streams 与 Functions指令名的“姓”与“名”每条 SECS-II 消息都有一个编号写成 SxFy比如 S1F1、S6F11、S10F3。第一次看像乱码其实是一套很规整的命名法记住规则比死背编号有用得多。3.1 SxFy 这个写法到底怎么读S 后面的数字是 Stream流F 后面的数字是 Function功能。Stream 大致可以理解成“消息的姓”按大用途分组Function 是“名”在同一个姓下面区分具体动作。S6F11 就是“第 6 族里的第 11 号动作”。同一族里的奇数、偶数常常配对主机发 S1F1 问“你在吗”设备回 S1F2 说“我在这是我的信息”。奇数一般由发起方发出偶数是对应的回复这条规律覆盖了大量常见的请求/回复对记住它能省不少查表时间。但配对不是绝对的遇到具体编号还是要翻一眼定义别凭感觉套。配对的另一半是 W 位。消息头里有一位叫 WWait bit置 1 表示“这条消息必须给我一个回复”置 0 表示“发完就完不用回”。同一条 SxFyW 位不同行为完全不同。设备发事件报告时把 W 位置 1主机就必须回一条对应的确认置 0 则设备发完继续干活主机回不回它都不等。所以看文档时不能只看 SxFy得连 W 位一起看否则很容易出现“我明明回了它为什么还超时”的困惑——很可能是回的消息编号不对或者对方那条压根没要求回复。3.2 Stream 按“干什么用”分类Stream 的划分不按设备品牌按用途。常见的几族大致是这样Stream大致用途典型例子S0系统层管链路本身的建立与维护建立通信、在线确认、时间询问S1设备状态与基本身份状态查询、上线通知、在线/离线切换S2设备控制与诊断远程命令、时间同步、设备常数S5报警报警上报、报警查询、报警使能S6数据收集事件报告、跟踪数据S7配方与工艺程序配方上传、下载、列表S9错误识别出错的报文S10终端服务往操作员屏幕推一行字这张表不用背记住“按用途分族”这个思路就够了。真到对接时顺序是先看要办什么事再定位到族最后翻具体编号。比如要往操作员屏幕上打一行“请更换料盒”先想到“这是给人看的提示”落到 S10再查到具体的那一对。3.3 系统保留区与自定义区Stream 和 Function 的编号空间不是随便用的分成系统保留和自定义两段。系统保留段由标准定义含义固定谁都不能改自定义段留给设备商和工厂自己约定用来传标准没覆盖的数据。为什么需要自定义区因为标准不可能预见到所有设备的特殊性。某台设备有个独有传感器想把读数传给主机标准里没有对应的消息就只能在自定义段里开一条两端约定好格式。代价是这条消息不再通用——换一台设备、换一套主机就得重新约定一次。所以实践中的原则是能用标准消息就用标准消息实在没有再动自定义区而且一旦动了就得把约定写成文档别只留在某个人的脑子里。注意自定义段的消息不要和标准消息混用同一个编号否则将来标准升级、编号被占用对接会出问题。3.4 从一条消息到一次完整的业务单看一条消息没什么意义SECS/GEM 的威力在于把消息串成流程。以数据收集为例主机先发一条建立报告链接的消息告诉设备“我要这几个变量打包成这个报告编号”设备记下来之后设备每次采到数据发一条带事件编号和报告编号的消息主机按之前的约定解析。整个过程里主机只订阅自己真正要的东西设备也只发被订阅的部分。这也是为什么前面说“接口充当消息代理”。代理在设备上跑它知道谁订阅了什么没订阅的数据根本不出设备。如果主机临时断开设备也不会把数据丢了——GEM 的假脱机功能会把这段时间该发的消息存进非易失性存储等主机回来再补发。这一条后面还会碰到它是最容易被忽略、也最容易在事故复盘时被翻出来的一项能力。4. 连接、超时与日志链路跑起来之后看什么前面的章节讲的是“消息长什么样、叫什么名字”。真把线接上、端口配好之后工程上遇到的绝大多数问题不在消息内容而在链路状态和时序。这一段讲的就是上线之后盯什么。4.1 HSMS 的三段连接状态HSMS 的连接状态分三段未连接、已连接但未选中、已选中。刚启动时是未连接一端主动去连另一端的端口或者被动监听连接建立之后进入第二段此时通道是通的但双方还不能传业务消息得先交换控制消息确认对方是谁、支持什么确认通过才进入第三段业务消息才被允许通过。这套设计的用意是把“线通了”和“人认识了”分开。线通了不代表对方是你要找的那台设备也可能是另一台设备连错了端口。先握手确认身份再放业务数据比连上就发要稳得多。代价是多了一次状态切换调试时需要知道有这么一个中间态。提示如果日志里能看到连接建立记录但一条业务消息都没有先检查是不是一直停在第二段。很多时候是两边的端口配置对上了但选通条件没满足。4.2 控制状态谁在“在线”除了链路状态还有一层控制状态回答的是“这台设备此刻听谁的”。设备可以处于本地状态——现场操作员在面板上按按钮也可以处于远程状态——主机在指挥。同样设备对主机而言有在线和离线两种。这两组状态交叉起来就有四种组合每种组合下能做什么事都不一样。主机想让设备进入在线会发一条在线请求设备同意后回一条确认想让它退出就发离线请求。看似简单实际项目中出问题最多的恰恰是这里主机以为设备在线一直在发命令设备那边因为某个条件没满足其实还停在本地模式命令全被丢掉从主机侧看就是“发出去没反应”。排查这类问题第一件事是核对两边的状态显示而不是怀疑消息格式。4.3 超时定时器链路不通时先看哪几个数SECS/GEM 给链路上的每一段等待都定义了定时器业界习惯用 T 加编号来称呼。原文对这些超时事件有专门一节这里挑几个最常打交道的说定时器管什么超时之后通常意味着T1发出一条需要回复的消息后等对方回复的时间对方没收到、收到没处理、或处理完没回T2发出控制消息后等对方控制消息的时间协议层握手卡住T3等待连接建立完成的时间端口不通、地址配错、对端没起服务T5连接断开后等待重新连上的时间网络抖动或对端重启T6一次控制事务从开始到结束的时间事务被中途打断T7未选中状态下等待恢复的时间选通流程没有走完T8单个字符之间的间隔时间链路质量差字节流被拉长具体秒数标准给了推荐区间实际项目里往往按工厂规范再调。这里不需要背数值需要建立的是判断顺序先看 T3确认连接能不能建起来再看 T2 和 T7确认握手和选通是否完成最后看 T1确认业务消息有没有回。按这个顺序走能少走很多弯路。这些年踩过的坑里最常见的翻车方式是把 T1 调得特别大企图“多等一会儿就回来了”。等待时间拉长只会让问题暴露得更晚真正该做的是看日志确认对方到底收没收到。4.4 消息日志出问题时的黑匣子消息日志记录每条收发的消息带时间戳、方向、编号。它平时不起眼出事时是唯一的现场证据。没有日志只能靠猜是没发出去、发出去了对方没回、还是回了但解析错了有日志顺着时间线一看谁先发的、谁没回、回的是什么编号一目了然。一份有用的日志至少要包含四个信息时间、方向、消息编号含 W 位、消息体摘要。少了方向分不清是谁发的少了 W 位判断不了这条该不该有回复。很多现场问题最后能定位靠的就是把日志按时间排开发现某条消息的回复编号和请求对不上——设备回了个偶数主机却在等另一个偶数。4.5 数据密度的账怎么算二进制传输到底省在哪值得单独算一笔。原文给了一个典型例子一条事件报告里含 2 个 4 字节整数、2 个 8 字节浮点数、1 个 4 字节事件编号、1 个 4 字节报告编号真正的业务数据是 32 字节。SECS 的固定开销是消息头 10 个字节加上描述消息体大小的 1 到 4 个字节。每个数据项在线上还要带 1 字节格式码和 1 字节长度。算一算# 估算一条事件报告在线上实际占用的字节数 HEADER 10 # 消息头固定 10 字节 BODY_LEN 4 # 消息体长度字段按最多的 4 字节算 def item_bytes(value_size): 单个数据项的线上开销1 字节格式码 1 字节长度 值本身 return 1 1 value_size items [ item_bytes(4), # 4 字节整数 item_bytes(4), # 4 字节整数 item_bytes(8), # 8 字节浮点 item_bytes(8), # 8 字节浮点 item_bytes(4), # 事件编号 item_bytes(4), # 报告编号 ] payload 32 # 真正有用的业务数据 wire HEADER BODY_LEN sum(items) print(payload, wire, round(payload / wire, 2))算下来业务数据 32 字节线上大约 60 字节密度五成出头。这个比例不算惊艳因为数据项太少固定开销摊不薄。原文里还有一个更有说服力的对照把这条消息换成 100 个 8 字节浮点数数据项一多同样的固定开销被摊到 800 字节业务数据上SECS 的数据密度就升到 78% 左右——用上面的算法复算结果基本对得上。同样的内容用 JSON 或 XML 表达键名和标签会随数据量一起膨胀密度提升远没有这么明显。这就是二进制的价值小包看开销大包看密度。设备上报的数据量越大、频率越高这个差距累积起来就越可观。反过来如果一台设备一天只发几条状态消息省下来的带宽意义有限这时候带宽不该成为选型的主要理由。5. 最容易混的几个概念初学者踩坑清单概念讲到这里大部分名词已经能对上号了。真正让人栽跟头的往往是几个听起来差不多、实际差很远的东西。下面这五组是对接现场最常被问混的。5.1 误区一把 SECS 和 GEM 当成一个东西易混点口语里常说“这台设备支持 SECS/GEM”听上去像一个协议。为什么混两者永远同时出现缺一个都对接不起来久而久之就被当成一体。怎么区分SECS 是“怎么说”管消息格式和传输GEM 是“说什么、做什么”管功能清单和场景。一台设备可以只实现 SECS 不实现 GEM——能通信但主机管不动它因为该有的功能一个都没有。反过来不成立GEM 建立在 SECS 之上没有 SECS 就没有 GEM。跟人沟通的时候说“支持 SECS”只代表链路能通说“支持 GEM”才代表业务能跑。5.2 误区二把 S1F1 当成心跳易混点不少资料把 S1F1/S1F2 说成“心跳包”。为什么混它确实经常被周期性发出去形式上很像心跳。怎么区分S1F1 是身份询问回答里带的是设备信息它的用途是确认“你是哪台设备、还在不在”而链路层真正的心跳由 HSMS 自己的控制消息负责不占 SECS-II 的编号。判断链路是否活着看控制消息判断设备是否在线看控制状态。把这两件事混在一起会出现“心跳一直在发但业务消息全超时”的怪现象——链路活着业务层没握手。5.3 误区三以为事件报告是设备随便推易混点从主机侧看数据确实是设备主动发过来的像是“设备一有变化就推”。为什么混推的行为太明显让人忽略了推之前的约定。怎么区分推之前必须先订阅。主机要先发建立报告链接的消息约定好事件编号、报告编号、变量清单设备才有东西可发。没订阅设备不会主动推也没有义务推。这一条对带宽的意义很大——正是因为有订阅机制设备才不会把全量数据往网络上广播。5.4 误区四把假脱机和消息日志当成一回事易混点两者都跟“把消息存起来”有关形式上都落盘。为什么混名字里都带“记录”的意味而且经常在同一个调试场景里被同时提到。怎么区分消息日志是给人看的诊断记录通常调试期才打开量小不负责重发假脱机是给主机补课的业务机制当主机不可用时设备把该发而没发出去的消息存进非易失性存储等主机恢复后按顺序补发保证不丢。日志丢了顶多难排查假脱机里存的东西丢了就是数据缺口事后要花大力气补。5.5 误区五把报警管理和数据收集混成一套易混点报警本身也是一种“事件”看起来完全可以塞进数据收集里一起上报。为什么混两者都靠 S5/S6 往外发触发方式也像——条件满足就报。怎么区分报警有独立编号、独立使能状态、独立的清除逻辑主机要单独订阅、单独确认还要能区分“发生”和“解除”两种状态。数据收集管的是过程变量和状态量是连续的量报警管的是异常的发生与消除是成对的事件。把报警硬塞进采集事件最直接的后果是丢掉“解除”这一半事后看记录只看到报警发生看不到什么时候恢复复盘时根本还原不出时间线。注意这五组里最容易在项目后期造成返工的是第三组和第五组。前者影响数据能不能收到后者影响数据收到之后能不能解释。6. 什么时候该上 SECS/GEM什么时候先别急讲到这里概念和边界都清楚了剩下的问题很实际我这台设备、我这个厂到底要不要上。6.1 三种值得上的情况第一种设备要卖进多供应商混线的产线。买方的产线里已经有别人的设备主机软件也跑起来了你的设备如果只有私有协议买方要么让你改、要么让你加转换层成本最后都会回到设备价格上。做一套符合标准的接口等于一次投入、所有客户复用。第二种工厂要把人从设备旁边撤走。SECS/GEM 让设备上发生的事都能被追踪到支持远程控制和系统配置。设备发布的数据越多工厂能实现的应用就越多——统计工艺控制、故障排查、预测性维护、前后馈工艺控制、设备利用率、物料跟踪、配方校验。这些应用减少了对设备面板的依赖操作员数量跟着下降。第三种配方和追溯要求高。把黄金配方存在工厂的中央存储里通过接口下发并校验能显著减少用错配方造成的报废。这类需求一旦出现靠人工核对是撑不住的。6.2 三种可以先放一放的情况第一种单机台、单工序压根没有主机。设备自己跑自己的数据存在本地没有人来订阅上一整套标准接口就是空转。第二种数据量极小、频次极低。一天几条状态消息人工记录完全够用此时二进制省带宽、订阅省流量这些优势都体现不出来。第三种团队里没人能长期维护这条链路。这一点最容易被低估。SECS/GEM 不是装完就完的东西状态机、定时器、订阅关系、假脱机存储任何一处配置漂移都会在某个夜班爆发。如果没有人能看懂消息日志、能判断是链路问题还是业务问题那么这条链路迟早会变成一个没人敢碰的黑匣子。上之前先想清楚出了事谁来看。6.3 一个具体例子新设备进场假设某实验室引进一台新设备要接进已有的主机系统。比较稳的顺序是这样先确认设备支持哪些 Stream、实现了哪些 GEM 功能。这一步不是看宣传页而是看设备提供的接口文档重点确认基础需求是否齐全、附加功能里哪些是选配、自定义段有没有额外约定。再配网络。确认端口、地址、谁是主动连接方。这一段做完先别急着发业务消息把连接建起来确认能走到“已选中”。然后跑最基本的身份确认看设备回的标识和版本对不对。对不上就先停下来查配置别往下走。接着建立一条最小的事件报告只订阅一两个变量观察设备是否按约定上报。这一步跑通说明订阅关系和消息结构都对。最后再打开假脱机测一次主机断开、设备继续跑、主机恢复后补发的完整流程。整个过程里消息日志从第一步就要打开。这不是流程要求是血泪经验——很多问题在现象消失之后就再也复现不出来只有日志还留着。从那以后我每次接新设备都会先把消息日志打开再连线宁可多花十分钟看日志也不要在半夜被叫起来猜是哪条消息没回。上面这套顺序还有 Streams 的分类、超时定时器的排查路径、五组易混概念的区分方式都收在这份 SECS/GEM 中文详解资料里十章内容从协议介绍一路讲到消息日志、格式码、通信状态和常用功能需要的时候按章节翻比在零散帖子之间来回跳要省事得多。希望帮到你。本文还有配套的精品资源点击获取