简介针对制造设备通信协议学习需求这份中文详解系统整理了SECS/GEM的完整知识体系。内容涵盖协议发展背景、降低设备集成成本与带宽优势、消息日志机制、常用术语解释以及Streams and Functions基础与指令用法适合半导体及泛制造业的设备工程师、自动化集成人员阅读。文档共10章以单一PDF文件呈现压缩包大小955KB便于离线查阅。目前已有2256人学习下载。相比零散的网络资料该文档将分散信息汇总为结构化手册并重点说明数据密度、无数据翻译、环路保证与安全特性可帮助读者快速建立协议整体认知并直接对照章节定位实际通信场景中的指令含义与使用方式。1. SECS/GEM 到底是什么一条报错背后牵出的设备通信协议在产线上排查设备与 MES 之间的通信很多人最初当作网络问题IP 通了、端口能访问可设备就是不回应。抓包一看设备 ID 对不上消息刚发过去就被丢弃。这类问题大多出在 SECS/GEM 设备层。SECS/GEM 不是某个软件而是半导体设备与工厂上位机之间的一套通信标准族涵盖传输方式、消息格式、状态模型、事件上报和远程命令。搞清这一套设备软件和上位机集成工程师才能在同一套协议语言里把设备接进自动化系统而不是靠反复试错和猜。2. 标准家族拆解从传输层到设备状态模型谁规定什么在真正投入联调之前我建议先把 SECS/GEM 这串字母拆开看。它不是单一协议而是一组标准的合称里面既有消息格式定义也有传输方式和设备行为约定。我们平时说“设备支持 SECS/GEM”其实意味着设备同时满足了传输层、消息层、行为模型三方面要求任何一层缺了都会在联调中暴露问题。2.1 传输层SECS-I 和 HSMS为什么现在几乎都走 TCP底层传输有两条经典路径一条是 SECS-I基于 RS-232 串口另一条是 HSMS基于 TCP/IP 以太网。SECS-I 出现在设备通信量小、距离近的年代优点是实现简单缺点是速率低、线缆短、扩展麻烦。现在新项目里绝大多数设备都已经转向 HSMS因为这时的产线网络基本是标准以太网直接一条网线就能接入车间系统。HSMS 的通信模型并不复杂设备端作为服务端持续监听一个 TCP 端口Host 端作为客户端主动发起连接。连接建立后Host 再发送一个 Select 控制消息完成“会话选择”相当于在链路上再确认一次身份。这一步经常被忽视有人以为 TCP 连上就是通信建立了其实 TCP 只负责搬运字节Select 成功之后消息交互才真正有意义。我在选 HSMS 方案前会向设备厂商确认三件事固件是否支持 HSMS端口号可不可以自定义车间网络是否允许设备端口对外监听设备侧的超时参数能不能在配置文件里调整。前两条不满足项目就要退回串口方案第三条不满足后续联调会非常被动因为所有超时只能 Host 侧去迁就设备。联调时需要查标准文档先做一个快速索引方便对照各类问题该找哪份文档标准编号管什么联调时怎么用E4SECS-I 串口传输规范老设备串口接入看波特率、校验位E5SECS-II 消息格式与数据项定义写 SML、查消息结构、自定义消息E30GEM 通用设备模型查状态模型、事件上报规则、远程命令E37HSMS 以太网传输规范设置 TCP 端口、会话选择、控制消息2.2 SECS-II 消息格式与 SML每条消息都有一个骨架传输层解决“字节怎么流动”SECS-II 解决“消息长什么样”。SECS-II 用 Stream 和 Function 两层编号定位消息S1F13 表示建立通信请求S1F14 是对它的回复S6F11 表示事件上报S6F12 是收到事件后的应答S2F41 表示远程命令S2F42 是命令回执。这套编号是全协议的通用规则调试时只要盯住 Stream/Function就能知道这条消息在干什么。消息内部的数据靠数据项组织。常见类型包括列表、ASCII 字符串、二进制、有符号和无符号整型、布尔量、浮点数嵌套规则就像一棵树。新手看 SML 容易晕因为大量消息都是列表套列表但只要把每一层缩进对齐逐层向外剥离很快就能读懂。一个典型 S1F14 回复是这样写的S1F14 L3 A COMMACK A 0 A MDLN A EQ-A-200 A SOFTREV A 1.00 这个响应表达了三层意思设备接受通信建立请求设备型号是 EQ-A-200软件版本是 1.00。COMMACK 取值 0 表示接受建立通信非 0 值则代表拒绝。这里的消息头 W-bit 是 0也就是不需要 Host 再回复如果消息头 W-bit 置 1对端就必须在超时内回一条消息否则就会触发 T3 超时。初学 SECS/GEM 最容易犯的错就是 W-bit 与是否需要回复不匹配。Host 发出去一条消息迟迟没有回包先不要怀疑链路先回看这条消息到底需不需要回复、对端是否具备回复能力。我的习惯是调试时把 SML 在编辑器里先缩进检查一遍再发出去很多因为标签、类型、逗号缺失导致的异常都能在发出前被发现。2.3 GEM 状态模型与超时参数设备不是收到命令就会照做GEM 标准对应编号 E30它解决的是一个比消息格式更麻烦的问题设备在什么状态下允许做什么事。状态机里最核心的几个状态包括未建立通信、正在建立通信、通信已建立、通信中断。不同状态下的消息处理权限不一样设备不会在你还没建立通信时就乖乖执行你的远程命令。很多翻车都发生在状态机理解不到位。设备看似在线实际上还停留在“通信未建立”的旧状态Host 发 S2F41 远程命令它不执行发事件订阅它也不应答。排查时我一般先看 S1F13/S1F14 的交互结果只有 COMMACK 返回 0双方才真正进入“通信已建立”状态后面的消息交互才有基础。这个前置条件不满足后面所有操作都是空谈。超时参数同样是联调的高频坑。GEM/HSMS 里典型超时包括 T3、T5、T6、T7、T8各自负责不同环节不能混用也不要随意缩短。联调初期我习惯先把所有超时设成标准默认值或厂商推荐值等消息流程稳定后再根据产线节拍微调。为了追求“响应快”把 T3 设成几秒会在高频消息场景制造大量假超时反而把问题搞复杂。还要特别提醒超时参数不是只有 Host 侧有设备侧同样有一套。两侧参数不一致时设备可能先于 Host 判定超时并断开Host 端却还认为链路正常直到下一次发送才发现异常。这种错位的典型表现是联机后前几分钟消息正常再往后第一批消息开始全部超时。遇到这种规律性异常先把两侧超时参数逐项对齐比反复抓包更有效率。3. 搭一套能本地演练的 GEM 测试环境模拟器和最小联调SECS/GEM 这种协议不太适合直接在真机上调。真机一旦出问题设备状态、产线调度、安全互锁全搅在一起很难判断是哪一层出错。我建议先搭一套最小测试环境把通信链路、消息格式、状态机分开验证。3.1 环境选型模拟器、中间件、还是从零实现常见做法有三种第一种是使用设备厂商提供的模拟器模拟真实设备的通信表现适合验证 Host 侧逻辑第二种是选用商业中间件内部已经封装好协议栈你只需要配置设备参数和消息模板第三种是从零实现一套协议栈常见于设备端或上位机嵌入式场景成本和难度都最高。项目初期我倾向于先用模拟器把流程跑通。设备厂商的模拟器通常支持常见消息交互、报警上报和远程命令模拟足够覆盖联调的大部分场景。没有模拟器时可以退而求其次用通用 TCP 工具先把链路层打通再逐步往上加消息解析。从零实现协议栈不是不行但工作量远超预期光是 SECS-II 数据项的字节级编码和多块传输处理就够写很长时间。3.2 最小命令本地起一个监听口先验证链路在没有现成模拟器的情况下我用 Python 写一个最小的监听脚本先验证 Host 能否连上设备端口。这段代码不做协议解析只确认链路通不通方便后面排查问题时有参照import socket import threading LISTEN_IP 0.0.0.0 LISTEN_PORT 5000 def handle(conn, addr): print(f[连接] {addr}) conn.settimeout(5) buf b try: while True: chunk conn.recv(1024) if not chunk: break buf chunk print(收到字节数:, len(buf), buf[:16].hex()) # 回一个固定短包表示端口可达、设备端在回应 conn.sendall(b\x00 * 10) except socket.timeout: print([超时] 5 秒无数据) finally: conn.close() server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.bind((LISTEN_IP, LISTEN_PORT)) server.listen(5) print(模拟设备端监听:, LISTEN_PORT) while True: conn, addr server.accept() threading.Thread(targethandle, args(conn, addr), daemonTrue).start()这段代码的用处在于把“链路问题”和“协议问题”切分开。参数说明LISTEN_IP 设为 0.0.0.0 表示监听本机所有网卡地址LISTEN_PORT 是设备侧端口Host 侧连接的就是这个端口conn.settimeout(5) 表示 5 秒内没收到数据就算超时断开。需要注意这段脚本只回显 10 个零字节并不等价于真实的 HSMS 响应。真正的设备在收到连接后要先处理 Select 控制消息再进入消息交互。这里的目标只是确认端口、防火墙、网络路由有没有问题。把这一层验证通过后再换协议模拟器继续下一阶段。3.3 设备侧参数三件套设备 ID、网络号、超时用模拟器或真实设备联调前设备侧有几项参数必须提前确认并记录。最常出问题的三项是设备 ID、网络号、超时配置。设备 ID 相当于这台设备在协议世界里的身份证消息报头里会带上这个 IDHost 侧也配置同一个值否则消息会被丢弃。参数通常取值配置位置联调确认点设备 ID0 或自定义整数设备参数页 / 配置文件与 Host 侧一致端口号自定义常见 5000/9998设备通信配置可被车间网络访问T3 超时45 秒设备通讯参数与 Host 侧匹配网络号0 或项目分配值设备参数页多设备场景不要冲突我见过不止一次把设备 ID 搞错导致联调失败的案例。现象是 TCP 已经连上Select 也发了但设备就是不回业务消息。原因往往是设备侧设备 ID 配成了 1Host 侧发消息用 0协议栈在消息头部校验时直接丢弃。联调开始前把设备 ID、端口号、超时这三项在两侧过一遍可以省掉后面一整天的排查时间。4. 把消息真正发起来从 S1F13 建会话到事件上报链路通了参数也对齐了接下来就是真正把 SECS-II 消息跑起来。这个阶段的核心是验证三个流程建立通信会话、读取设备基础信息、处理事件上报和远程命令。三个流程走完设备的自动化接入就基本成型了。4.1 S1F13/S1F14 建立会话确认双方进入同一状态无论设备是来自哪家厂商联调第一步基本都是 S1F13。Host 发送 S1F13 W 给设备询问设备型号和软件版本同时要求建立通信。设备收到后回复 S1F14COMMACK 为 0 时表示接受建立通信随后双方进入“通信已建立”状态。一条完整的 S1F13 在 SML 里长这样S1F13 W L2 A MDLN A EQ-A-200 A SOFTREV A 1.00 注意 S1F13 W 的 W 表示期待回复。设备收到这条消息后在 T3 超时内回复 S1F14。Host 侧收到 S1F14 并解析 COMMACK 字段就能判断建会话是否成功。这个流程看起来简单但有几个检查点需要养成习惯。第一S1F13 的会话 ID设备 ID必须正确第二消息头的 W-bit 必须置 1否则设备认为不需要回复第三系统字节要保留并在回复中原样带回Host 靠它把回复和请求关联起来。如果 S1F14 一直不来按这三个点逐个排查基本都能定位。4.2 事件上报与远程命令订阅、触发、响应三件事建会话成功之后紧接着要验证事件上报。事件机制在 GEM 里是核心很多设备自动化场景都依赖它比如设备启动完成、批次开始、报警产生。事件上报的完整链路分三步Host 向设备订阅事件、设备侧触发事件、设备向 Host 发送 S6F11。S6F11 W L2 U4 10020001 U4 501 L2 U4 506 U4 100 这段 SML 表示设备上报了一个事件数据 ID 是 10020001事件 ID 是 501事件附带的参数里有一个数值 506对应值 100。Host 收到 S6F11 后需要回复 S6F12 表示已经收到否则设备侧可能按超时处理导致事件流程中断。远程命令则走另一组消息。Host 发送 S2F41 W设备执行后回 S2F42并在消息里携带执行结果状态码。这个场景最常遇到的问题不是消息格式而是设备状态机不允许执行命令。比如设备还处于“通信未建立”或“正在初始化”状态S2F41 就会被忽略或直接返回错误码。遇到这种情况先回到状态机确认当前状态允许哪些操作再调整测试顺序。4.3 看 Trace 日志而不是只看结果抓时序、抓系统字节联调时我会习惯性保持一份完整的消息 Trace格式大致如下[00:00:00.123] Host - Dev S1F13 W SYS0x0001 [00:00:00.145] Dev - Host S1F14 SYS0x0001 COMMACK0 [00:00:00.200] Host - Dev S2F17 W SYS0x0002 [00:00:00.213] Dev - Host S2F18 SYS0x0002 TIME20240610120000 [00:00:02.500] Host - Dev S2F41 W SYS0x0003 RCMDSTART [00:00:02.612] Dev - Host S2F42 SYS0x0003 HCACK0看 Trace 主要看三个字段系统字节、时间戳、消息编号。系统字节在请求和回复中必须一致不一致说明消息关联出错时间戳用来判断超时尤其是两条消息间隔接近 T3 时要找系统瓶颈消息编号则帮助判断交互顺序是否正确。有一个容易被忽略的点单纯看到 S2F42 返回并不代表设备真的执行了命令。S2F42 只表示收到命令并开始执行真正的执行结果要通过后续事件上报来确认。如果你只是看 RC 返回 0 就宣布测试通过可能漏掉设备根本没动作的问题。把 Trace 和事件上报对照起来看才能判断整条链路是否完整。5. 联机调试避坑5 个高频翻车点联调现场最常见的翻车往往不是协议多难而是几个基础配置反复出问题。我把这几年遇到的高频坑整理成 5 条每一条都按“现象、原因、解决”来写方便你对照排查。5.1 设备 ID 不匹配连接成功却立刻被断开现象Host 能建立 TCP 连接也能收到 Select 响应但后续业务消息发出后设备毫无反应或在短时间内主动断开连接。原因设备侧配置的设备 ID 与 Host 侧不一致。SECS-II 消息头里带有会话 ID设备协议栈收到消息后第一件事就是校验这个 ID不匹配就直接丢弃甚至触发连接断开。解决联调前把设备侧参数页里的 Device ID 和 Host 侧配置放在一张表里核对确保完全一致。多设备项目尤其小心不同设备可能分配了不同 IDHost 侧需要按设备维度分别配置。5.2 超时参数乱调T3/T6 设得太短设备频繁掉线现象消息交互在低负载时一切正常高负载或批量上报时频繁出现超时日志里能看到大量 T3 超时记录。原因为了追求反馈速度有人把 T3 或 T6 设成几秒。设备在高负载时回复变慢超过超时阈值Host 判定超时并中断事务反而加剧负载形成恶性循环。解决先把 T3、T5、T6、T7、T8 恢复成标准默认值或厂商推荐值确认流程稳定后再逐步缩短。缩短要一次只调一个参数并且观察至少一整轮完整生产过程不要凭感觉一起调。5.3 事件没订阅或没启用主机收不到任何事件上报现象设备已经处于“通信已建立”状态Host 也确认订阅了事件但设备就是不发送 S6F11。原因事件机制在 GEM 里有三个层次事件要存在、事件要启用、事件要通知。很多设备的默认状态是“事件存在但没有启用”或者“启用但没有通知”只有三个层次都配置正确事件才会主动上报。解决先通过消息确认设备侧事件列表再检查事件 ID 是否存在于设备配置中。然后在设备侧把对应事件设为启用、通知状态设为有效再次触发确认 S6F11 能否正常发出。5.4 长消息没走多块传输大块数据被接收端丢弃现象事件上报里附带大量过程数据时消息发送异常接收端迟迟不回复或回复时提示消息不完整。原因SECS-II 支持长消息分块传输当一条消息超过设备或 Host 的接收缓存时需要按块拆分并在消息头里置块标志。没有正确置位或块序号异常接收端就无法重组完整消息。解决先确认收发两端的单块最大长度限制再让大消息走系统指定的分块逻辑。排查时看消息头里的块标志和块序号确认每一块的顺序和总量是否一致不要用加大缓存的方式去掩盖分块逻辑错误。5.5 模拟器跑通真机失败真机状态机比模拟器严格得多现象本地用模拟器联调全部通过换到真实设备后同样的消息却报错或不响应。原因模拟器通常只模拟正常路径对状态机约束比较宽松真实设备会严格检查当前状态、事件启用条件、权限位状态不对就直接拒绝或忽略。解决不要因为模拟器通过就跳过合规性测试。上真机前先准备一份最小用例清单覆盖建会话、读参数、事件上报、远程命令、报警处理五个场景每一条都记录实际返回值和预期返回值逐项对照才能快速定位差异。6. 进阶验证把 SECS/GEM 当黑匣子来测的最后一个习惯做到后面你会发现SECS/GEM 联调的瓶颈通常不是语法而是缺少一套可重复执行的验证方法。我现在接手这种项目第一步不是翻代码而是先整理一份“最小回归用例表”把最关键的消息交互固化下来。验证场景发送消息预期回复通过标准建会话S1F13 WS1F14COMMACK0读取设备时间S2F17 WS2F18时间字段正确远程命令S2F41 WS2F42状态码为 0事件上报触发设备事件S6F11Host 回 S6F12断线重连手动断开连接设备重新监听Host 可再次选择每一条用例都在模拟器上先跑通再上真机跑一遍并把两边的结果录成 Trace 文件对比。这个方法看起来很笨但在排障时非常救命真机上所有偏差都变成了“模拟器和真机的行为差异”而不是每次都得从头抓包分析。几年的经验告诉我凡是反复出问题的项目几乎都是没有把这一层“回归”做扎实。我自己的习惯是联调第一天绝不碰真机先在模拟器上把上述几十条用例全跑完真机调试时每一轮只改一个配置项不批量修改超时、设备 ID、事件通知状态。这样即使出现新问题也知道上一个动作是唯一变量定位起来很快。希望帮到你。本文还有配套的精品资源点击获取