简介：SECS-GEM规格书（SECS版本）以Word文档形式整理，面向半导体设备工程师、自动化软件开发者及工厂集成人员，用于快速掌握设备与主机间标准通讯协议。文档围绕GEM适应性展开，系统梳理状态模型、设备处理状态、主机发起场景、事件通知、在线识别、动态事件报告配置、变量与状态数据采集、报警管理、远程控制等核心模块，并结合消息摘要、TCP/IP通讯协议、变量与命令实现、消息类型实现等章节，帮助读者建立SECS/GEM完整知识框架，支撑实际项目中的设备联调、功能开发与异常排查。压缩包内仅含1个doc文件，大小约514KB，章节划分明确，便于按需查阅。目前已有1251人学习下载，适合需要接触半导体设备自动化通讯协议的工程人员作为入门指引或规范速查手册使用。

1. SECS-GEM规格书 SECS版本：设备端与主机端都绕不过的那道协议门

上个月在封测厂帮朋友查设备联调，设备商的软件交付了，MES侧照着一个老项目的代码改了三天，结果一拉日志，S1F3 能收到回复，S1F14 之后直接掉线。我翻出通信记录一看，问题出在“系统字节没有原样带回”这种规格书里写得清清楚楚的细节上。这种情况我遇到不止一次，多数人都是先把协议跑通，翻车了才回头去翻《SECS-GEM规格书 SECS版本.doc》。

这份规格书把 SECS-I、SECS-II、HSMS、GEM 四块内容捆在一起，对设备开发、MES 集成、中间件维护的工程师来说，等于把“设备怎么开口、MES 怎么接话”的标准答案提前摆在你桌上。它解决的是联调现场最耗时的那类问题：报文格式对不上、链路反复断、CEID 事件编号各说各话。适合搞设备软件、搞工厂自动化、写通信中间件的人，新手能当敲门砖，老手能当查错字典。

2. 拆开 SECS 和 HSMS：传输层与消息层的分工比你想的重要

2.1 先分清 SECS-I 和 HSMS：联调现场第一步是选对传输层

很多现场工程师把“SECS”和“HSMS”混成一个词，真到配置界面就卡住。SECS-I 是串口时代的产物，基于 RS-232/RS-422，消息按块传输，一块最多 2KB，适合老式单机设备；HSMS 是基于 TCP/IP 的新一代传输，端口传统上走 5000，消息长度用 4 个字节前置定义，数据量能上大很多。

选型原则不复杂：设备端支持 HSMS 就优先用 HSMS，不要图省事去走串口转换。现在新出厂的半导体设备基本默认开 HSMS，有些设备厂甚至只留 TCP 口，串口连上去也没响应。判断方法很简单，打开设备的 Service 菜单看有没有“Host Port”或“SECS Comm”相关选项，里面若出现端口号，就是 HSMS 无疑。

真机上我遇到过一台老款固晶机只支持 SECS-I，主机端非要走 HSMS，最后加了一个串口服务器才把事情办了。反过来也一样，有些一体化设备模块默认 HSMS 但防火墙没开放 5000，TCP 连不上。联调前先搞清楚双方各自能跑哪一层，能省掉半天无谓的排查时间。

2.2 SECS-II 消息结构：从 SxFy 到头部字段的直读法

SECS-II 是“消息内容”的规范。所有 SECS-I 和 HSMS 传输的数据，载荷部分都用 SECS-II 来定义。每条消息有一个编号，写成 SxFy 的形式，S 是 Stream 流号，F 是 Function 功能号。比如 S1F13 表示“建立通信请求”，S1F14 是它的应答，S2F41 是“远程命令请求”。

消息头总计 10 个字节，打开规格书里“消息格式”那一节，主要看这几个字段：

这里给一段按字节拆解头部的 Python 代码，我在写解析工具时就是这么处理的，直接对应规格书里的头部定义：

import struct def parse_secs2_header(h): """ h 是从消息缓冲区里截出来的 10 字节 SECS-II 头。 返回 (设备ID, Wbit, Stream, Function, SystemBytes) """ if len(h) < 10: raise ValueError("SECS-II header must be 10 bytes") # 第0字节高1位是W bit，低7位是设备ID高7位；第1字节是设备ID低8位 wbit = (h[0] >> 7) & 0x01 device_id = ((h[0] & 0x7F) << 8) | h[1] # 第2字节高4位是Stream，低4位是Function stream = (h[2] >> 4) & 0x0F function = h[2] & 0x0F # 第6-9字节是系统字节，请求和响应必须一致 sys_bytes = int.from_bytes(h[6:10], byteorder='big') return device_id, wbit, stream, function, sys_bytes

这段代码的关键在最后两行：规格书里明确要求响应消息把请求消息的系统字节照搬回来，很多底层库并不会帮你校验这个，得自己在协议层盯。如果 W bit 为 1 而你发了消息后没收到回复，第一个要查的就是对端的系统字节是否有跟你消息里一致的值。另外注意字节序，标准里系统字节是大端，别用本地小端直接读，否则数值会倒过来比较。

2.3 GEM 把设备“行为”管了起来

GEM 是 SEMI E30 里定义的设备模型，我把它理解成“设备怎么表现才算合格”。SECS-II 只规定消息格式，GEM 规定设备在什么状态做什么事：上电后要先做自检，自检完进入通信建立，再切到空闲，随后才能收远程命令。这个状态迁移过程，是设备厂家软件和 MES 侧都必须遵守的共同规则。

GEM 覆盖五件事：状态模型、在线/离线控制、事件报告、报警管理、远程命令与数据收集。联调时很多“设备没反应”的问题，其实不是消息格式错，而是设备当前状态不允许做这个动作。比如设备还在 DEVICE_INITIALIZATION 阶段，主机就发 S2F41 远程命令，设备直接忽略。这种情况规格书的 GEM 状态模型章节里写得明明白白，但现场很少人愿意翻到那页。

3. 打开规格书先读这三块：从目录到关键章节的寻路法

3.1 规格书里的四层协议对应关系

拿到《SECS-GEM规格书 SECS版本.doc》，像拿到一张协议地图，但别指望从头看到尾。我一般先用五分钟确认四个标准分别是干什么的，再去抽自己需要的部分。

阅读顺序我的建议是：先看 E37 的通信建立部分，明白 TCP 连上之后还有一次 select 握手，很多人忽略这一步直接发 S1F13，设备压根不理；再看 E5 的头部定义和数据项格式，这是写解析器的基本功；最后再啃 E30 的状态模型和事件模型，这块直接决定你 MES 侧的设备模型怎么写。

3.2 常用消息流：“五张牌”覆盖九成联调需求

SECS-GEM 消息流很多，但实际工程项目里翻来覆去就那几个。我把规格书里最常用的流整理成表，联调前逐条确认一遍：

这五个流基本能覆盖一条产线从设备上线到正常生产的全过程。比如设备一上线，主机发 S1F13 建立通信；生产过程中设备报个警，走 S5F1；批次结束想采集参数，通过 S2F41 触发一次数据收集。规格书里每条消息都附了完整的数据项结构，照抄即可。

3.3 从目录到可执行清单：三步建出联调基线

读规格书最怕读完就忘。我现在的习惯是先搭一个“通信基线清单”，把规格书里的关键信息转成可执行参数，具体分三步。

第一步列消息清单：把设备需要支持的 SxFy 列表抄出来，标清每条消息的发起方、数据项、W bit 置位规则。第二步定义事件映射表：把设备要上报的 CEID 事件号、对应报告 ID、包含的变量列出来，这表是后续 MES 配置的底稿。第三步画状态迁移图：用纸笔写清楚设备从上电到生产的必经状态，标注哪些状态可由远程命令切换。

我一般会把这三样东西合并成一页纸，夹在规格书封面内侧。联调现场不翻整本规格书，只看这一页纸加对应消息的详细结构就够了。过了两周再看新项目，直接翻这一页纸就能恢复记忆。

4. 对照规格书看懂报文交互：从 HSMS 握手到 GEM 状态迁移

4.1 HSMS 握手关键参数与计时器

HSMS 连上 TCP 端口不等于通信建立完成，它还有一层 select 握手。联调中最常见的翻车现场是：TCP 显示“已连接”，但主机发 SECS-II 消息石沉大海。原因是设备在等 select.req 报文，双方没有建立 HSMS 会话。正确的顺序是 TCP 连通后，主机发 select.req，设备回 select.rsp，状态从 NOT CONNECTED 跳到 CONNECTED，之后才能发 S1F13。

规格书中还定义了一组计时器，现场配置不当会引发“握完手就断线”的怪问题。常见做法是保留这些默认值：

这些值虽然各家设备软件略有差异，但同一工程中主机端和设备端必须一致，否则就会出现“主机 45 秒没等到回复就断开，设备却还在发呆”的混乱局面。我处理这类问题必做的动作是：先 ping 通，再看 select 是否成功，最后核对计时器参数，按这个顺序基本能定位九成链路问题。

4.2 一套最简联调报文序列

真机联调不要上来就跑业务场景，先把通信链路基础打牢。我常用的一套最小序列如下，拿到任何一台设备都按这个顺序试：

这套序列跑通后，设备才算是真正纳入 MES 管理，后续的远程命令、数据采集、报警上报都建立在这个基础上。序列中任何一步没通过，都要先停下排查上一步，不要往下带病试。

4.3 GEM 状态迁移与在线/离线控制

GEM 状态模型是设备行为的总纲。状态在规范里是按一个有限状态机来走的，大致关系是：设备上电处于禁用状态，完成自检后进入通信建立阶段，之后到 DEVICE_INITIALIZATION，再进入空闲 IDLE，最后才能接受业务命令。

联调中一个高频错误是:设备还停在 DEVICE_INITIALIZATION,主机已经开始发 S2F41 远程命令，设备毫无响应。正确做法是先查设备当前状态，如果是初始化未完成，等待设备自行完成或通过 S1F13 重新初始化；如果设备卡在 DISABLED，需要先检查前序条件是否满足。另一个常见操作是主机通过 S1F15/S1F17 这类控制消息切换设备离线/在线，但切换前必须确认设备处于 IDLE 状态，否则切换命令同样会被忽略。

提示：状态迁移要以设备回复为准，不要以主机发送顺序为准。发控制消息后务必看响应码，响应码非 0 就要打开对应规范页查原因。

5. 用规格书排查八大联调故障：现象、根因与对症处理

5.1 现象一：HSMS 握完手，两分钟后自动断链

现象：TCP 能连上，select 也成功了，S1F13 正常回复，但每隔一两分钟链路就断，日志里报 linktest timeout。原因：主机端和设备端的链路测试周期不一致，一方按 30 秒发 linktest，另一方把超时设得太短，网络稍微延迟就判定超时。解决：统一双方的 linktest 间隔和超时时间，我习惯先把链路测试间隔设成 30 秒，超时设成 45 秒，跑通后再调优。参数通常在设备软件的通信配置页或主机配置文件的 HSMS 段里，找到后两边改成一致即可。

5.2 现象二：设备回了 S1F14，主机却报消息不合法

现象：设备侧日志显示已发送 S1F14，主机侧却提示“消息结构无效”，联调卡死在第一步。原因：绝大多数情况是系统字节没按规格书要求原样返回，或者 W bit 位置被设备软件写错。解决：抓包软件抓一条 S1F13 和 S1F14 做对比，核对两者第 6 到第 9 字节的系统字节是否完全一致。若不一致，找设备厂家改协议栈，这不是主机侧能兼容的问题。

5.3 现象三：事件触发了，主机的 CEID 完全不认识

现象：设备已上报 S6F11，主机日志收到数据但提示“未知事件号”。原因：设备端 CEID 事件号是由设备厂家自定义的，不同厂家同一事件编号可能含义不同，主机按另一个项目的表硬解析必然对不上。解决：先从设备端导出事件定义表，或者在规格书里查该设备的 CEID 映射，把事件号、事件名称、关联报告 ID 对应到主机的配置文件里。这里最忌讳拍脑袋猜事件含义，一定要以设备实测上报为准。

5.4 现象四：消息长度算错，解析时多读少读

现象：日志提示长度不足或长度溢出，报错信息指向消息尾部。原因：SECS 消息的 4 字节长度字段表示的是头部 10 字节加体部字节的总和，有的开发习惯只算体部，导致接收端等不到完整消息。解决：接收时先把 4 字节长度字段读出来，加 10 得到总长，再按总长收包。分块传输的情况还要处理块拼接，注意规格书中分块消息的块序和结束标志。

5.5 现象五：设备状态卡在 DEVICE_INITIALIZATION 不动

现象：设备一直显示初始化状态，主机发任何业务命令都没反应。原因：主机没发送 GEM 要求的在线/离线控制消息，或者发送的时机不对，设备等不到状态切换指令。解决：按规格书状态迁移图，先确认设备是否已进入 IDLE 前的最后一个待命状态，然后主机发送 S1F15 或 S1F17 让设备切换在线模式，收到确认后再操作业务。

5.6 现象六：W bit 设为 1，却不等回复就发下一条

现象：主机连续发了多条请求消息，设备只回了第一条，后面全部丢失。原因：SECS-II 规定同一时间只能有一个未完成的“需要回复”请求，W bit 为 1 时，主机必须等对端回包后才能发下一条。原因二：主机在发下一条时系统字节里置了新的值，导致对端无法对应。解决：串行化自己的请求队列，每条 W bit=1 的消息必须等到响应或超时才放行下一条。

6. 把规格书翻译成验收测试矩阵：我的最后一关习惯

6.1 做一张“消息流×通过条件”的测试矩阵

联调不是凭感觉试，我习惯把规格书每个功能点翻译成一张测试矩阵，每行一条用例，每列一个通过标准。这张表同时给设备厂家和 MES 侧用，双方按同一张表验收，扯皮的事少一半。

这张表填完后，联调就是“一行行过”的机械动作，出问题直接定位到具体用例。

6.2 用模拟器先把主机端跑通，再碰真设备

跟真实设备联调前，我强烈建议先用一个 SECS-GEM 模拟器把主机端逻辑跑一遍。模拟器可以模拟设备端行为，建通信、报事件、回报警，全都能在一个软件里配出来。这样有两个好处：一是把主机端的解析逻辑问题先暴露掉，免得把“主机 bug”和“设备 bug”混在一起排查；二是可以模拟异常场景，比如故意不回系统字节、故意延迟响应，检验主机端超时处理是否健壮。

用模拟器时我一般会额外做一件事：打开抓包工具，把所有报文录下来，建一个报文数据库，后续真机联调时随时对比模拟器跑出的标准报文和真机报文的差异，排查效率提升非常明显。

6.3 跑真机前的最后十分钟

真机联调前，我最后十分钟永远是同一套动作：打开规格书，确认 HSMS 参数一致；打开测试矩阵，勾选本次要跑的用例；启动抓包工具，确保端口 5000 的流量都在记录范围内。这套动作成习惯之后，几乎没再遇到过那种“连上又断、断了又连”的前半夜。

有一次新设备到场，对方工程师说他这设备“肯定没问题”，我不慌不忙把抓包记录拉出来，看到 select 握手后设备发来的响应里系统字节被写成了全零。这种问题不抓包、不对照规格书，靠看界面永远查不出来。从那以后我每次联调第一件事，都是先确认系统字节规则和计时器参数，再谈其他。希望帮到你，少走那些我走过的弯路。

本文还有配套的精品资源，点击获取