简介：这份资源是面向工业自动化与半导体设备工程师的 SECS/GEM 协议中文详解文档，针对网上相关介绍零散、不够系统的问题，整理出十章节内容，帮助读者从零建立对设备通信标准的完整认知。文档以 PDF 形式交付，压缩包内共 1 个文件，整体约 955KB，篇幅紧凑便于随时查阅。内容从协议降低设备集成成本、适用各类制造设备、支持多种应用程序、高效利用网络带宽等优势讲起，逐步深入到消息日志、常用术语解释，以及 Streams and Functions 的基础介绍，涵盖系统保留与自定义、Stream 分类、指令含义与使用场景等核心知识点，并配有目录结构方便按章节检索。目前已有 2253 人学习下载，适合设备集成、上位机开发及产线通信调试人员作为入门与速查参考。
1. secs/gem 中文详解：从设备通信黑匣子到产线数据闭环
半导体封测厂里，一台刚上线的焊线机如果只亮着绿灯却不往 MES 回传任何数据，现场工程师的第一反应往往是「网络通了，但协议没通」。这里的协议，十有八九就是 secs/gem。它是一套让设备与上位系统说同一种语言的通信标准，负责把设备状态、配方、报警、量测值这些信息结构化地传出去，也把上位机的指令传回来。做封测设备 secs/gem 协议对接、EAP 系统现场实施和日常运维的人，每天打交道的正是这套东西。这篇内容面向三类人：刚接手 EAP 对接、需要把设备接进 CIM 的新手；被「secs 是单向还是双向」这类问题绕晕的熟手；以及要评估这套方案值不值得投入的产线负责人。下面从概念、选型、动手配置到排错，一层层拆开讲。
2. secs/gem 到底是什么：分层结构、单向双向与选型理由
2.1 secs 与 gem 的分工，别把两层混成一件事
很多人把 secs/gem 当成一个东西，实际它是两层。SECS（SEMI Equipment Communications Standard）管的是「怎么把消息发出去、怎么收回来」，是通信层；GEM（Generic Equipment Model）管的是「发什么、什么时候发、状态怎么定义」，是行为层。常见做法是：SECS 负责报文编码和传输，GEM 在它之上定义了一套设备必须实现的标准行为和状态机。
拆开看更清楚。SECS 又分两半：SECS-I 走串口（RS-232），速率低、布线简单，老设备上还能见到；HSMS（High-Speed SECS Message Services）走 TCP/IP，是现在的主流。GEM 则规定了设备要支持哪些消息、状态模型怎么建、报警和事件怎么上报。只实现 SECS 不实现 GEM，设备能收发报文，但上位机不知道它处于什么状态，等于通了但没完全通。
选型上，新设备一律上 HSMS，串口方案只在改造老机台、且机台本身只支持 SECS-I 时才用。判断依据很简单：看设备手册里写的是 SECS-I 还是 HSMS，以及现场网络是否允许设备直接接入车间网。这一步定错，后面所有配置都是白费。
2.2 secs 是单向还是双向：从消息配对机制说清
「secs 是单向的还是双向的」是搜索里高频出现的问题，答案取决于你看哪一层。物理传输上，HSMS 建立的是 TCP 连接，天然双向。但 SECS 消息本身有主从之分：Primary Message（主消息）由发起方发出，接收方必须回一条 Secondary Message（从消息），这一对消息用同一个 System Bytes 关联。所以从消息交互看，它是「请求—应答」的双向机制，不是单向广播。
具体到消息编号，比如上位机发 S1F1（Are You There），设备必须回 S1F2；上位机发 S2F41 下发远程命令，设备回 S2F42 报告执行结果。如果只看到设备不停上报 S6F11 事件，没有对应的应答，那多半是事件上报走的是「无需回复」的通道，或者上位机没按配对规则处理。理解这一点，排查「设备发了但上位机没反应」时就不会瞎猜。
提示：判断一条消息是否需要回复，看它的 Function 编号是奇数还是偶数。奇数通常是 Primary，需要应答；偶数是对应的 Secondary。
2.3 为什么封测厂非要用 gem 而不是自定义协议
有人会问，直接自定义一套 TCP 协议传数据不行吗？短期看行，长期是坑。封测厂设备品牌杂，焊线机、划片机、测试机来自不同厂商，如果每家一套私有协议，EAP 侧要写 N 套解析逻辑，维护成本随设备数量线性上涨。GEM 的价值在于把「设备状态」「报警」「配方管理」「数据采集」这些共性行为标准化，EAP 只要实现一套 GEM 客户端，就能对接所有符合标准的设备。
代价是 GEM 规范本身比较重，状态模型、事件定义、变量字典都要按 SEMI 标准来，设备厂商实现成本不低。所以现实里常见的是「GEM 子集」：设备只实现产线真正用到的那部分消息和事件。做对接时要先拿到设备的 GEM 能力清单（通常叫 GEM Capability 或设备手册里的消息列表），确认它支持哪些 Stream/Function，再决定 EAP 侧怎么配。跳过这一步直接联调，大概率在某个事件上报上卡住。
3. 动手对接：HSMS 连接、消息收发与 EAP 侧配置
3.1 用 Python 跑通 HSMS 最小连接
联调第一步是确认 TCP 层能通。HSMS 默认端口是 5000，但设备厂商经常改，以手册为准。下面这段用 Python 起一个最小 HSMS 被动端（模拟设备侧），验证上位机能否连上并完成 Select 流程。
import socket import struct # HSMS 控制消息：Select.req，用于建立会话 # 格式：4字节长度 + 2字节SessionID + 1字节Stream + 1字节Function + 3字节Status + 4字节SystemBytes def build_select_req(system_bytes=1): session_id = 0xFFFF # 控制消息固定为 0xFFFF stream = 0 function = 1 # Select.req status = 0 body = struct.pack('>HBB I', session_id, stream, function, status) # 长度字段 = 后续字节数（不含自身4字节） return struct.pack('>I', len(body)) + body + struct.pack('>I', system_bytes) def main(): host, port = '0.0.0.0', 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('HSMS passive listening on', port) conn, addr = srv.accept() print('connected from', addr) data = conn.recv(1024) print('recv:', data.hex()) # 收到 Select.req 后回 Select.rsp，Function=2 rsp = build_select_req(system_bytes=1) # 把 Function 改成 2 表示 rsp rsp = rsp[:9] + b'\x02' + rsp[10:] conn.sendall(rsp) conn.close() if __name__ == '__main__': main()逻辑说明：HSMS 每条消息前面有 4 字节长度字段，后面跟 SessionID、Stream、Function、Status 和 SystemBytes。Select.req 的 Function 是 1，Select.rsp 是 2，SystemBytes 必须一致，否则对端会认为配对失败。参数上，SessionID 在控制消息里固定 0xFFFF，数据消息里才用真实设备 ID。端口 5000 是默认值，改端口要同步改上位机配置。
跑通这段只能证明 TCP 和 Select 流程没问题，真正的数据消息（比如 S1F1）还要在此基础上加 Stream/Function 和消息体。新手常犯的错是把长度字段算错，多算或少算 4 字节，导致对端解析错位，现象是「连上了但一收数据就断」。
3.2 EAP 侧要配的几个关键参数
EAP（Equipment Automation Program）是上位机里负责和设备通信的模块。配置时几个参数必须和设备侧对齐，错一个就连不上或收不到数据。
| 参数 | 含义 | 常见取值 | 对齐要求 |
|---|---|---|---|
| IP / Port | 设备 HSMS 监听地址 | 设备 IP，端口 5000 或厂商自定义 | 双方一致 |
| Device ID | 设备在 GEM 里的编号 | 0～32767 | 与设备配置一致 |
| Active / Passive | 谁主动发起连接 | EAP 常做 Active，设备做 Passive | 一方 Active 一方 Passive |
| T3 超时 | 等待回复超时 | 45 秒（SEMI 默认） | 按产线节拍调整 |
| T5 超时 | 连接断开重连间隔 | 10 秒 | 避免频繁重连 |
| T6 超时 | 控制消息超时 | 5 秒 | 一般不改 |
| T7 超时 | 未 Select 就发数据 | 10 秒 | 防止会话未建立就传数据 |
| T8 超时 | 消息间最小间隔 | 5 秒 | 高节拍产线可调小 |
Active/Passive 是最容易配反的一项。EAP 做 Active 时主动连设备，设备做 Passive 监听；反过来也行，但要看设备支持哪种。配反的现象是双方都在等对方连，日志里只有重试没有连接成功。T3 超时设太短，设备处理慢时会误判超时；设太长，设备真挂了 EAP 要等很久才发现。封测产线一般按设备响应时间实测后再定，不直接抄默认值。
3.3 消息收发的最小验证：S1F1 与 S1F2
Select 完成后，第一件事是发 S1F1（Are You There）确认设备在线。下面这段在已建立的连接上发 S1F1 并解析 S1F2。
import struct def build_data_msg(session_id, stream, function, system_bytes, body=b''): # 数据消息：SessionID 用真实设备 ID，Stream/Function 按需 header = struct.pack('>HBB I', session_id, stream, function, 0, system_bytes) payload = header + body return struct.pack('>I', len(payload)) + payload def parse_msg(data): length = struct.unpack('>I', data[:4])[0] session_id, stream, function, status, sys_bytes = struct.unpack('>HBB I', data[4:14]) return { 'length': length, 'session_id': session_id, 'stream': stream, 'function': function, 'system_bytes': sys_bytes, 'body': data[14:4+length] } # 发送 S1F1，SystemBytes 自增 msg = build_data_msg(session_id=1, stream=1, function=1, system_bytes=100) # conn.sendall(msg) # 收到回复后解析，确认 stream=1 function=2 system_bytes=100逻辑说明：数据消息的 SessionID 用设备 ID，不是 0xFFFF。SystemBytes 用来配对请求和应答，每次发新请求要换一个值，收到回复时比对是否一致。S1F1 的消息体通常为空，S1F2 会带回设备型号、软件版本等信息，具体格式看设备手册的 MDLN 和 SOFTREV 定义。参数上，Stream 和 Function 必须成对理解：S1F1 对应 S1F2，S2F41 对应 S2F42，发错 Function 设备会回 S9F5（不支持的 Function）。
验证顺序建议是：先 Select，再 S1F1，再 S1F13（建立通信），最后才是事件订阅和配方操作。跳过中间步骤直接上复杂消息，出问题时很难定位是哪一层没通。
4. 避坑与排查：现场最常见的五类翻车
4.1 连上了但收不到事件上报
现象：EAP 显示连接正常，S1F1 也能通，但设备状态变化时收不到 S6F11 事件。原因通常是事件没使能。GEM 里事件上报要先通过 S2F33 定义报告、S2F35 链接事件和报告、S2F37 使能事件，三步缺一不可。很多新手只做了连接，没做事件订阅，自然收不到。解决：按 S2F33 → S2F35 → S2F37 顺序配置，每步确认设备回 S2F34/S2F36/S2F38 且状态为成功。
4.2 SystemBytes 不匹配导致消息被丢弃
现象：设备发了回复，EAP 日志里能看到报文，但业务层没处理。原因多半是 SystemBytes 对不上。SECS 要求 Secondary 消息的 SystemBytes 必须和 Primary 一致，如果 EAP 侧生成 SystemBytes 的逻辑有并发问题，或者设备侧实现不规范，就会出现配对失败。解决：在 EAP 里加一层校验，收到消息先比对 SystemBytes，不匹配的记录告警而不是静默丢弃，方便定位是设备问题还是自己问题。
4.3 T3 超时设太短，高节拍下频繁误报
现象：产线节拍快的时候，EAP 频繁报 T3 timeout，但设备其实在正常处理。原因是 T3 默认 45 秒，但某些设备处理复杂命令（比如配方下发）耗时超过这个值，或者网络抖动导致回复延迟。解决：先实测设备各类命令的响应时间，把 T3 调到实测最大值的 1.5～2 倍。同时区分「真超时」和「网络延迟」，在日志里记录发送和接收时间戳，用数据判断而不是凭感觉调。
4.4 配方管理用错消息，导致配方丢失
现象：下发配方后设备报错，或者配方下发了但没生效。原因常见于把 S7F1（Process Program Load Inquire）和 S7F3（Process Program Send）用混。S7F1 是询问设备能否接收，设备回 S7F2 同意后才发 S7F3。跳过 S7F1 直接发 S7F3，部分设备会拒绝。解决：严格按 S7F1 → S7F2 → S7F3 → S7F4 流程走，每步确认回复状态。配方名（PPID）要和设备侧已存在的配方名一致，否则会新建而不是覆盖。
4.5 模拟器与真机行为不一致
现象：用 secs/gem 模拟器联调全通过，接真机就出问题。原因是模拟器通常只实现标准消息，不实现厂商私有扩展和边界行为。比如模拟器对未定义变量返回空，真机可能返回错误码；模拟器不模拟 T3 超时，真机在高负载下会超时。解决：模拟器只用于早期验证消息格式和流程，最终必须在真机或厂商提供的仿真环境上跑一遍完整流程。把模拟器当唯一验证手段，是现场翻车的常见起点。
5. 进阶：用日志和状态机把对接从「能通」做到「可运维」
对接做完只是开始，日常运维才是长期战场。我的习惯是给每条 SECS 消息打上时间戳、方向、Stream/Function、SystemBytes 和耗时，落到结构化日志里。这样出问题时不用猜，直接按 SystemBytes 串起一次完整交互。下面是一个日志字段设计，配合简单的状态机判断设备是否「真的在线」。
| 字段 | 说明 | 用途 |
|---|---|---|
| ts | 消息时间戳（毫秒） | 算耗时、排顺序 |
| dir | SEND / RECV | 区分方向 |
| sf | Stream/Function，如 1/1 | 定位消息类型 |
| sys_bytes | 系统字节 | 配对请求应答 |
| elapsed | 从发送到收到回复的毫秒数 | 判断是否接近 T3 |
| result | OK / TIMEOUT / ERROR | 快速筛选异常 |
状态机方面，设备在线不等于能干活。我一般维护三个状态：Connected（TCP 通）、Selected（HSMS 会话建立）、Communicating（S1F1 能通且事件在报）。只有三个都满足才认为设备可用。任何一层掉线，EAP 侧要能自动降级并告警，而不是等操作员发现数据不刷新。
# 简化的设备状态判断 def device_state(connected, selected, last_s1f1_ok, last_event_ts, now): if not connected: return 'OFFLINE' if not selected: return 'CONNECTED' if not last_s1f1_ok: return 'SELECTED' # 超过 60 秒没收到事件，认为通信异常 if now - last_event_ts > 60: return 'STALE' return 'COMMUNICATING'逻辑说明：这个状态机把「连接」「会话」「通信」分开判断，避免把 TCP 通就当成设备可用。参数上，60 秒是事件静默阈值，按设备上报频率调整，高频设备可以设更短。实际部署时，状态变化要写进日志并触发告警，而不是只存在内存里。
最后说个我踩过的坑：早期做对接时只看「能不能收到回复」，不看回复里的状态码。结果设备回了 S2F42 但 Status 是非零，业务层却当成成功处理，配方下发失败了好几天才发现。后来养成习惯，每条 Secondary 消息都先校验 Status 字段，非零就告警。这个习惯帮我省了很多后悔药。secs/gem 对接没有玄学，把消息配对、超时、状态码这三件事盯住，大部分问题都能定位。希望帮到你。
本文还有配套的精品资源，点击获取
