简介：面向半导体设备厂商、MES/EAP 集成开发人员与自动化工程师的 SECS/GEM 通讯平台资料，聚焦设备与工厂系统之间的标准化通讯问题。内容围绕 SEMI 标准协议展开，涵盖 SECS/GEM、GEM300、Interface-A 等规范，并介绍 API 接口转换器、PLC SECS、EAP 软件与 SECS Driver 等实现方式，涉及 C、C++、C#、VB、Labview 等多语言开发场景，以及湿法、注胶、退火等设备的落地案例，适合需要将国产设备接入 MES 或 EAP 的工程人员参考。资源包共 1 个 PDF 文件，约 1.1MB，以图文方案说明为主，便于快速了解协议框架与产品能力边界。目前已有 372 人学习下载，可帮助读者建立 SECS/GEM 通讯的整体认知，理解 PLC 地址映射、事件与警报管理、Recipe 与 Trace 处理等关键环节，为设备联调与方案选型提供参考。

1. 一套国产 SECS/GEM 通讯平台，到底能替设备厂省掉多少二次开发

去年帮一家做湿法清洗设备的客户做产线对接，对方 EAP 团队甩过来一份 Host 侧联调清单，要求两周内跑通 E5、E30、E37 全套。设备端用的是三菱 Q 系列 PLC，电气工程师连 SECS 是什么都没听过，上位机软件又是外包的，按老路子走，光协议栈选型和消息字典对齐就得拖一个月。后来换了个思路：不写一行 SECS 代码，让 PLC 直接“说” SECS/GEM。这就是这套国产 SECS/GEM 通讯平台要解决的问题——它把 SEMI 标准里那套 SxFy 消息、状态机、事件报告，封装成可配置的映射关系，设备厂只需要告诉软件“哪个 PLC 地址对应哪个 VID、哪个上升沿触发哪个 CEID”，剩下的握手、超时、重连、异常处理全交给平台。适合两类人：一类是设备厂里被 EAP 联调追着跑的电气/上位机工程师，另一类是工厂 IT 侧要做 MES-EAP-设备三层打通的集成人员。下面按“它是什么、怎么配、坑在哪”拆开讲。

2. 先搞懂 SECS/GEM 在设备侧的角色：为什么不是“装个驱动”那么简单

2.1 SECS/GEM 是设备与 Host 之间的“通讯语言”，不是普通串口协议

很多刚接触的人会把 SECS/GEM 当成 Modbus 那种“读寄存器”的协议，这是第一个认知偏差。SEMI E5（SECS-II）定义的是消息内容和格式，E37（HSMS）定义的是传输层，E30（GEM）定义的是设备行为模型——三者叠起来才是一套完整的“设备会说话、知道什么时候该说话、说的话 Host 能听懂”的体系。设备侧要实现的不只是收发字节，还要维护通信状态机（Not Communicating / Communicating）、控制状态（Online Local / Online Remote / Offline）、以及一堆标准报告：设备常数 EC、报警 AL、事件 CEID、变量 VID、工艺程序 Recipe、追踪 Trace。这套平台的价值就在于把这些状态机和报告管理做成了现成的，你配置的是“数据从哪来、到哪去”，而不是从头实现 E30 的状态迁移。

从选型角度看，设备厂通常有三条路：自己啃 SEMI 文档写协议栈（周期以季度计，且容易在边界条件上翻车）、买国外商业库（授权费高、绑定语言、现场支持慢）、用这类国产平台做配置化对接。第三条路的核心优势是“电气工程师能直接上手”，不需要上位机团队介入，这对中小设备厂尤其关键——他们的软件人力往往就一两个人，还要同时应付好几台设备的交付。

2.2 三种接入形态：API SDK、PLC SECS、EAP 软件，选错形态等于白干

这套平台实际提供三种落地形态，选型时最容易翻车的就是形态选错。第一种是 API SDK，给你 C、C++、C#、VB、Labview 的原生 DLL，上位机软件里调接口，适合设备本身就有自研上位机、且需要深度定制消息的场景，比如 12 寸设备要按 E95 做 Run To Run、要对接 OHT 天车。第二种是 PLC SECS，软件直接和 PLC 通讯（支持西门子 S7、倍福、三菱 MC、欧姆龙 Fins、基恩士、Modbus），把 PLC 内存地址的数据转成 SECS 消息，收到的 SECS 数据也直接写回 PLC 地址，用户零二次开发，只配映射表。第三种是 EAP 软件，集成 SEMI 功能，通过 WebServer、MQTT 或 API 和 MES 交互，适合工厂侧做设备集中管理。

判断标准很直接：设备有成熟上位机且要定制 → SDK；设备是 PLC + 组态、没有软件团队 → PLC SECS；工厂要多设备统一管控 → EAP。我见过一个项目，设备明明只有 PLC 和触摸屏，偏要选 SDK 路线，结果外包团队为了调 DLL 又搭了个工控机跑 C# 程序，成本和工期都翻倍，这就是形态选错的典型代价。

2.3 标准覆盖范围决定你能接什么厂：E4/E5/E37 是底线，GEM300 是 12 寸门票

平台按标准覆盖分了三档，这个分档直接对应你能接什么类型的客户。基础 SECS Driver 覆盖 E4、E5、E37，能跑通最基本的消息收发和 HSMS 连接；SECS/GEM 档加上 E30，具备完整的 GEM 行为模型，这是绝大多数 8 寸及以下设备厂的要求；GEM300 档再加 E39、E40、E87、E90、E94、E116，覆盖 Process Job、Control Job、Carrier 管理、Run To Run 这些 12 寸晶圆厂必备能力。下面这张表是我按实际项目整理的对照，选型时对着看：

提示：如果客户是 12 寸线，别抱侥幸心理只上 SECS/GEM 档，Process Job 和 Carrier 管理缺失会在 Host 侧联调第一轮就被打回，返工成本远高于一开始选高配。

3. PLC SECS 配置实战：把三菱 Q 的地址映射成 VID/CEID 的完整步骤

3.1 先理清数据流：PLC 地址 → 映射表 → SECS 消息 → EAP

PLC SECS 的运行逻辑是一条单向加反向的链路：上行时，平台按配置周期或事件触发去读 PLC 指定地址（比如 D100、M200），把读到的值填进对应 VID 的 S1Fy 或事件报告；下行时，Host 发来的 S2Fy 写值请求被解析后，平台把值写回映射的 PLC 地址。中间那层映射表就是全部工作量所在，它至少包含四类条目：VID 映射（变量 ID ↔ 地址 + 数据类型 + 长度）、CEID 映射（事件 ID ↔ 触发地址/条件）、ALID 映射（报警 ID ↔ 报警位地址）、ECID 映射（设备常数 ↔ 地址）。数据类型要写清楚是 bit、word、dword 还是 string，长度对 string 尤其关键，长度配错会导致截断或越界读。

我一般建议先在 Excel 里把这张表拉出来，和 Host 侧的 EAP 工程师对一遍 VID 列表再导入配置工具，比在工具里逐条敲效率高得多，也方便版本管理。下面是一个映射配置的示意结构（不同版本字段名可能略有差异，以实际工具为准）：

{ "plc": { "protocol": "MC", "ip": "192.168.1.10", "port": 5000, "station": 0 }, "vid_map": [ { "vid": 1001, "addr": "D100", "type": "word", "len": 1, "name": "ChamberTemp" }, { "vid": 1002, "addr": "D101", "type": "dword", "len": 2, "name": "RecipeID" }, { "vid": 1003, "addr": "D110", "type": "string", "len": 20, "name": "LotID" } ], "ceid_map": [ { "ceid": 2001, "trigger": "M200", "edge": "rising", "report_vids": [1001, 1003] } ], "alid_map": [ { "alid": 3001, "addr": "M300", "type": "bit", "text": "DoorOpen" } ] }

这段配置的含义：plc段声明用 MC 协议连三菱 PLC 的 IP 和端口；vid_map里每条把 VID 号绑到具体地址，type和len决定读取时按几个字节解析，string 类型必须给足len；ceid_map定义事件触发条件，edge: rising表示 M200 上升沿触发一次事件报告，报告里带上 1001 和 1003 两个 VID 的当前值；alid_map把报警位绑到 ALID。配置导入后平台会自动生成对应的 S1F1/S1F3/S1F13/S5F1 等消息处理逻辑，不需要你手写。

3.2 26 槽位、数千变量的响应优化：分组上报和变化触发是两把钥匙

前面提到的湿法设备案例，26 个槽位、变量事件警报加起来数千个，如果每个 VID 都单独轮询、每个变化都单独发事件，Host 侧会被消息淹没，响应也上不去。实操里两个手段最有效：一是分组上报，把同一槽位的相关 VID 打包进一个 CEID 的报告里，一次 S6F11 带多个 VID，减少消息条数；二是变化触发而非周期轮询，对温度、压力这类缓变量用周期采样，对槽位状态、门开关这类离散量用地址变化触发。平台支持配置采样周期和触发方式，把高频变化量走事件、低频量走周期，实测能把交互压到毫秒级。

具体配置时，ceid_map的report_vids数组就是分组的手段，一个 CEID 挂十几个 VID 很常见。但要注意报告长度：SECS-II 单条消息有长度上限，VID 太多要拆成多个 CEID，否则 Host 侧解析会报消息过长。我一般按“一个工位一个 CEID、一个报警组一个 CEID”来切，既控制长度又方便 Host 侧做逻辑。

3.3 五工位共用地址的唯一性处理：用偏移量隔离，别让数据串台

注胶设备那个案例暴露的是另一个典型问题：五个工位同时作业，但 PLC 里工位共用同一段地址模板，如果映射表里五个工位都指向同一个 D 区地址，Host 收到的数据必然混乱。解决办法是地址偏移隔离——每个工位在 PLC 里其实有独立的地址段（比如工位 1 用 D100-D199，工位 2 用 D200-D299），映射时按工位号加偏移量生成 VID。如果 PLC 程序确实是共用地址、靠时序切换，那就必须在平台侧加“工位上下文”判断，用当前活跃工位号去选择对应的映射条目，这需要在触发条件里带上工位标识位。

# 按工位号生成带偏移的 VID 映射（示意，实际在配置工具中批量生成） base_vid = 1000 stations = 5 vids_per_station = 50 addr_base = {"D": 100, "step": 100} # 每工位 D 区偏移 100 for st in range(1, stations + 1): for i in range(vids_per_station): vid = base_vid + (st - 1) * vids_per_station + i addr = f"D{addr_base['D'] + (st - 1) * addr_base['step'] + i}" print(f"VID {vid} -> {addr} # 工位{st} 第{i}项")

这段脚本只是演示偏移逻辑，实际项目里我会用它批量生成映射表再导入，避免手敲出错。关键参数是vids_per_station和step，前者要和 Host 侧约定的每工位 VID 数量一致，后者要和 PLC 程序的地址分配一致，两者对不上就会出现“工位 2 的数据写进了工位 3 的 VID”这种血泪问题。

4. API SDK 路线：12 寸设备做 GEM300 和 OHT 对接时怎么落地

4.1 从 DLL 到状态机：SDK 集成的四个必做动作

走 SDK 路线的设备通常上位机是自研的，集成时不是“调个函数发消息”就完事，有四个动作必须做扎实。第一，初始化时注册所有 VID、CEID、ALID、ECID 和 Recipe 管理回调，平台靠这些注册信息才知道设备有哪些数据；第二，实现通信状态和控制状态的回调，Host 切 Online Remote 时设备要能响应远程命令，切 Offline 时要停掉自动上报；第三，处理 S2F41 远程命令和 S2F49 工艺程序相关消息，这是 GEM300 的核心；第四，把超时和异常处理挂到平台的通讯保持机制上，别自己另写一套重连逻辑，两套逻辑打架是联调期最常见的黑匣子。

// C# 集成示意：注册 VID 与事件回调（接口名以实际 SDK 为准） var gem = new SecsGemDriver(); gem.OnInit += (s, e) => { gem.RegisterVid(1001, "ChamberTemp", SecsFormat.F4); // 浮点温度 gem.RegisterVid(1003, "LotID", SecsFormat.A, 20); // 20 字节字符串 gem.RegisterCeid(2001, new[] { 1001, 1003 }); // 事件报告含两个 VID gem.RegisterAlid(3001, "DoorOpen"); }; gem.OnControlStateChanged += (s, state) => { if (state == ControlState.OnlineRemote) EnableRemoteCommands(); else DisableRemoteCommands(); }; gem.OnSecsMessage += (s, msg) => { if (msg.Stream == 2 && msg.Function == 41) HandleRemoteCommand(msg); }; gem.Start("192.168.1.20", 5000); // 被动模式监听 Host 连接

这段代码的要点：RegisterVid的格式参数决定 Host 侧解析方式，F4 是 4 字节浮点、A 是 ASCII 字符串且要带长度；RegisterCeid把 VID 打包进事件；OnControlStateChanged是远程/本地切换的钩子，漏了它 Host 发远程命令设备不响应；Start的被动模式表示设备作为服务端等 Host 连，主动模式则相反，选哪种要和工厂 IT 确认，选错连不上。

4.2 GEM300 的 Process Job 与 Carrier 管理：E40/E87 的配置边界

12 寸设备上 GEM300，绕不开 Process Job（E40）和 Carrier（E87）。Process Job 管理的是“一批片子按什么工艺跑”，Carrier 管理的是“哪个载具在哪个 Load Port、里面有多少片”。平台把这两块的状�态机做成了可视化配置，但边界要自己划清楚：哪些 Job 属性由 Host 下发、哪些由设备本地生成、Carrier ID 的读写时机、Load Port 状态（E87 定义的 Transfer Blocked、Ready To Load 等）怎么和 PLC 的传感器信号对应。退火设备那个案例里，4 到 8 寸直接跑 SECS/GEM，12 寸才上 GEM300，就是因为小尺寸线根本不需要 Job 和 Carrier 这套，硬上只会增加联调面。

实操建议：先在配置工具里把 Load Port 数量和 Carrier 容量设对，再把 E87 的状态位逐一映射到 PLC 的传感器地址，最后用平台自带的 GEM 模拟器扮演 Host 跑一遍 Load → Process → Unload 全流程，确认状态迁移正确再上真机。模拟器这一步别省，它是唯一能在不占用产线的情况下把状态机跑穿的后悔药。

4.3 和 OHT 天车对接：E84 的独立 Load Port 场景

有些设备只需要 E84（载具交接）和 E87，不需要完整 GEM300，平台支持独立 Load Port 管理正是为这种场景准备的。E84 的核心是几组握手信号：VALID、CS_0/CS_1、TR_REQ、BUSY、COMPT、CONT，设备和天车之间靠这些信号完成载具交接。配置时把每个 Load Port 的这几路信号映射到 PLC 的 IO 地址，平台负责按 E84 时序驱动，设备侧只要保证 IO 响应及时。OHT 对接最容易翻车的是时序——天车对信号响应时间有硬要求，PLC 扫描周期太长或映射地址选在慢速区，握手就会超时。我一般把 E84 相关 IO 放在 PLC 的高速扫描任务里，并在平台侧把这几路的采样周期调到最小。

5. 避坑与排查：联调期最容易翻车的五个点

5.1 现象：Host 连不上，HSMS 一直 Select 超时

原因通常有三类：设备侧监听端口和 Host 配置的端口不一致；设备配成了主动模式而 Host 也是主动模式，双方都在等对方连；防火墙或网段隔离。解决顺序是先确认平台侧是 Active 还是 Passive，和工厂 IT 对清楚谁连谁，再 telnet 测端口通不通，最后看平台日志里的 Select 请求有没有发出去。这一步的排查逻辑和普通 TCP 服务一样，别一上来就怀疑协议栈。

5.2 现象：事件报告 Host 收到了，但 VID 值全是 0 或乱码

原因多半是数据类型或长度配错。word 配成 bit、string 长度给少了、dword 高低字节序反了，都会导致值不对。解决方法是拿平台自带的 SECS 模拟器抓一条 S6F11 的原始消息，对照映射表逐字段核对格式和长度，字节序问题则确认 PLC 和平台的大小端约定。这类问题看着玄学，其实全是配置层面的确定性错误。

5.3 现象：远程命令下发后设备没反应

先看控制状态是不是 Online Remote——很多设备默认停在 Online Local，Host 发 S2F41 会被拒。再看远程命令的回调有没有注册、命令码（RCMD）和 Host 约定的是不是同一个字符串。还有一个隐蔽点：部分平台要求先完成 S1F1/S1F2 在线握手和 S1F3 状态查询，Host 才会认为设备可远程控制，握手没走完就发命令，设备侧直接丢弃。

5.4 现象：多工位数据串台，工位 2 的数据出现在工位 3 的报告里

这就是前面说的地址偏移没做对。排查时把每个工位的映射条目单独拉出来，核对 VID 号和 PLC 地址的对应关系，重点看偏移量是否和 PLC 程序的地址分配一致。如果 PLC 是共用地址靠时序切换，还要检查工位上下文判断逻辑有没有在触发时带上工位标识。这类问题在单工位调试时完全看不出来，一上多工位就爆发，所以映射表评审必须按工位逐个过。

5.5 现象：跑一段时间后通讯断开，重连后状态错乱

原因通常是超时和心跳参数没配好，或者平台的重连逻辑和上位机自己写的重连逻辑冲突。解决方法是统一由平台管通讯保持，上位机只监听状态回调，别自己再发心跳；T3（回复超时）、T5（连接分离超时）、T6（控制超时）、T7（未选择超时）、T8（网络字符超时）这几个定时器按 Host 要求设，设太短会误判断线，设太长故障恢复慢。重连后要重新走一遍在线握手和状态同步，别假设重连就等于恢复。

6. 用模拟器把联调前置：一套自测流程和参数核对表

真正让我少加班的习惯，是每次上真机前先用平台自带的 SECS/GEM 模拟器把 Host 侧行为跑一遍。模拟器能扮演 Host 发 S1F1 在线询问、S1F3 选状态、S2F33 定义报告、S2F35 链接事件报告、S2F37 开关事件、S2F41 远程命令，也能扮演设备回消息，双向都能测。我的固定流程是：先在模拟器里配一份和真实 Host 一致的 VID/CEID 列表，跑通在线握手和状态查询；再触发几个关键 CEID，确认报告内容和 VID 值正确；然后下发远程命令验证控制状态切换；最后模拟断线重连，看状态恢复是否干净。这套流程跑完，真机联调基本只剩网络和时序问题。

参数核对表我一般固定核这几项，联调前和 Host 对一遍能省掉大量来回：

还有个小技巧：把平台日志级别在联调期开到最细，每条收发的 SxFy 都带十六进制原文，出问题时直接拿原文和 SEMI 文档对照，比猜快得多。联调结束后再把日志级别降回去，避免长期跑满磁盘。

从那以后我每次接新设备项目，都强制先跑一遍模拟器自测加参数核对表，哪怕工期再紧也不跳过——跳过省下的半天，往往要在产线上用两个通宵还回来。希望帮到你。

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