半导体设备通信协议解读：SECS/GEM、HSMS与GEM300联调实战-北京尧图网络

你第一次接触半导体设备软件联调时十个有九个会被这四个词绕晕HSMS、SECS、GEM、GEM300。设备厂商说“我们支持SECS/GEM”MES工程师问“你们走HSMS还是SECS-I”你夹在中间看着一堆S1F13、S6F11、wafer map、process program脑子里只剩一个念头这些缩写到底谁是谁这不是段子是我在半导体设备自动化项目里经常遇到的真实场景。这四个术语不是四个平行协议而是一套按功能拆开的SEMI标准族。这篇文章就按“传输层、消息层、行为层、300mm扩展”这条主线把整个SECS/GEM体系讲清楚告诉你实际对接时先做什么、后做什么、哪些地方最容易翻车。1. 先理清概念四个协议名到底对应什么1.1 传输、消息、行为三层职责不能混搞懂这套体系的第一步是接受一个现实SECS/GEM不是一个单一协议而是为了“设备主控软件”和“工厂主机Host/MES”之间通信而设计的三层结构。最底层是传输层解决“数据怎么从A到B”。早期用串口标准叫SECS-ISEMI E4用RS-232线缆速率不高但足够传文本和设备状态。后来工厂自动化程度上来串口速度不够、布线也不方便就出了HSMSSEMI E37改走TCP/IP以太网。对应用层来说传输层换掉不影响消息内容但从串口换到网络连接管理、心跳保活、并发处理全得重写。往上一层是消息层解决“数据长什么样”。这一层的标准叫SECS-IISEMI E5它定义了消息格式S1F13、S6F11这种编号是什么意思消息里的数据用什么类型编码哪些消息需要回复。打个比方传输层是邮局和卡车SECS-II就是信封上必须写清楚收件人、邮编和内容格式。最上层是行为层标准叫GEMSEMI E30解决“设备在什么情况下发什么消息”。GEM不是新的传输方式而是规定了设备必须具备哪些SECS-II交互能力怎么上报报警、怎么上报事件、怎么接收远程命令、怎么管理配方。它把一台工艺设备的行为变成一套可预期的剧本MES才能统一调度不同厂商的设备。1.2 SEMI标准族和这四个俗称的关系如果你去翻SEMI官网会看到一串标准编号E4、E5、E6、E30、E37……对应关系大致是这样俗称标准编号作用SECS-ISEMI E4串口传输层物理层和链路层定义SECS-IISEMI E5消息层定义消息格式与数据项编码SECS-I服务SEMI E6串口传输的会话规则现在很少单独提GEMSEMI E30行为层定义设备与主机间的标准行为模型HSMSSEMI E37以太网传输层TCP/IP上的SECS消息封装GEM300多个标准集合面向300mm产线的自动化扩展如E40、E84、E87、E90、E94、E116等所以你常听到的“SECS/GEM”其实是“SECS-I/II GEM”的缩写泛指而“HSMS”是新传输层跟“SECS-I”是同一层级的替代关系“GEM300”则是在“SECS/GEM”之上再加一批面向300mm晶圆厂的标准。1.3 选型逻辑串口SECS-I与网络HSMS怎么切换既然SECS-I和HSMS都是传输层项目上怎么选一句话能走网络就走网络。HSMS是TCP/IP调试方便、速度快、支持多连接和多会话现在几乎所有新设备都默认支持HSMS。SECS-I保留在老设备或者特殊隔离网络里比如一些旧的扩散炉、清洗机还在用串口服务器转换。不过要注意的是很多设备虽然声称支持HSMS但实际固件里对HSMS状态机的实现并不完整有些甚至只在特定固件版本里才支持Select流程。这点在选型或者写技术协议时要问清楚最好让对方提供GEM Compliance的版本号比如“GEM 1.0, HSMS 1.1”而不是只给一句“支持SECS/GEM”。2. HSMS连接层主动方、被动方和前10个字节2.1 Active与Passive谁先找谁说话HSMS建立TCP连接时双方的角色分为Active和Passive。Active是主动发起连接的一方Passive是监听端口等待连接的一方。设备软件里通常会配置一个Port和角色模式常见做法是设备端配PassiveMES主机端配Active这样MES可以根据排产主动去连设备。但实际项目里两边都可能配错。我见过最典型的问题设备配了ActiveHost也配了Active两边同时在等对方先发界面一直显示“connecting”就是不成功。这种问题排查起来特别浪费时间所以联调第一步先确认角色连上TCP后主动方会先发Select.req被动方回Select.rsp这条消息能对上连接状态才能进入Selected。2.2 HSMS消息头协议谈判的关键字节HSMS的每一条消息在TCP流里都有一个固定结构前4字节是消息长度后面10字节是消息头。这14个字节是整个HSMS通信的地基你抓包调试时第一眼就要能看懂它。消息长度字段是大端序的uint32表示“消息头消息体”的总长度。10字节的消息头里前2字节是Session ID会话ID数据消息里通常就是Device ID第6字节是Header Byte 2一般填0第7字节是PType0表示SECS-II消息第8字节是SType0表示数据消息1表示Select.req2表示Select.rsp5表示Linktest.req6表示Linktest.rsp9表示Separate.req最后4字节是System Bytes事务标识。字节偏移字段说明0-3Message Length大端uint32后续消息头消息体总长度4-5Session ID会话ID数据消息里通常是设备ID6Header Byte 2保留/会话类型标记一般填07PType0表示SECS-II消息8SType0数据、1选择请求、2选择应答、5心跳请求、6心跳应答等9-12System Bytes事务ID回复时原样返回消息解析时最容易踩的坑是大端小端搞反尤其长度字段抓包软件里看着是0x0000000A自己解析却当成0x0A000000连接判断直接就断了。我在工具脚本里会先把整个buffer按大端读再逐步推进偏移避免这个问题。2.3 建立连接的完整时序和状态机设计HSMS连接不是TCP一建立就能发SECS消息的。TCP链路通之后双方要经过Select握手连接才进入通信状态。流程大致是Active方建立TCP连接。Active方发送Select.reqSType1System Bytes填一个随机数。Passive方收到后检查Session ID等参数返回Select.rspSType2System Bytes原样带回。双方进入Selected状态之后才可以收发SECS-II数据消息。这在设备侧软件里实现成一个状态机比较稳妥TCP Connect - Select Sent - Selected - Comm Ready。别用标志位裸写因为连接会断会重连状态一多就乱。开发时可以用现成库省时间。我试过在Python里用secsgem库写模拟Host配置一个HsmClient示例几条代码就能连上设备并收发S1F13。遇到复杂的场景先用这类库把交互流程验证通了再移植到自己的C或C#代码里效率高不少。2.4 心跳与断线连接保活的实战参数TCP链路本身可能因为网络设备超时、对端崩溃等原因静默断开HSMS定义了Linktest机制一方发Linktest.req就是心跳请求另一方必须在规定时间内回Linktest.rsp否则认为连接失效。心跳参数里最重要的是超时时间。SEMI标准里有T3事务超时、T5连接未建立超时、T6控制消息超时、T7心跳间隔等。实际项目里心跳间隔通常配成10秒到30秒具体值要跟MES侧协商。如果间隔太短网络一抖动就误断太长中间防火墙容易把空闲链接回收。踩过一次坑某台设备的T7配了5秒Host侧却配了30秒设备发Linktest.req后Host没及时回设备单方面切断连接然后又重发Select看起来就是“每10秒掉线一次然后又自动恢复”。后来统一把T7配到15秒两边一致问题消失。联调时把T3、T5、T6、T7这些超时参数提前写入双方对照表能省掉很多“幽灵断连”的排查时间。3. SECS-II消息层读懂S5F1、S6F11这些“电报”3.1 消息头里的四个关键字段SECS-II消息本质上是放在HSMS数据消息体里的一串字节它的最前面也是一个10字节消息头但含义跟HSMS消息头不一样。前2字节是Session ID第3字节是Stream第4字节是Function第5到第10字节是System Bytes。Stream消息大类比如S1是设备状态类S2是设备控制类S5是报警类S6是事件类S7是配方类。Function消息的具体功能奇数一般是请求需要回偶数一般是确认或者响应。W-BitFunction字节的最高位即第8位置1表示这条消息需要对方回复。所以S1F13就是Stream 1、Function 13且W-Bit为1全称是Establish Communications Request建立通信请求对方回S1F14作为应答。S6F11是事件上报请求Host或设备发了之后收到方要回S6F12。3.2 SECS-II数据项从ASCII到List的编码规则消息头之后是数据项区域。SECS-II有一套自描述的数据编码每个数据项由一个格式字节开头格式字节的高4位是类型低4位是长度字节数后面跟长度值再后面是数据内容。格式码高4位类型习惯写法0x0List 列表L0x1Binary 二进制B0x2Boolean 布尔Boolean0x3ASCII 字符串A0x6INT8 有符号整数I10x7INT16 有符号整数I20x8INT32 有符号整数I40xAUINT8 无符号整数U10xBUINT16 无符号整数U20xCUINT32 无符号整数U4举例说明一个ASCII字符串“ABC”编码出来是0x41 0x03 0x41 0x42 0x43。0x41的高4位是0x4表示ASCII低4位是1表示后面用1字节表示长度0x03是长度后面三个字节是字符内容。如果是一个包含两个字符串的List则先在开头写0x01List长度字节数为1再写后续项。联调时看到一堆“L, A, U2, F4”就是这些数据项的写法。很多库会把它抽象成“数据字典”但你要能一眼看出这段报文里有没有List、有几个元素、每个元素长度对不对因为格式写错了设备端经常直接不回或者回错误码。3.3 一次典型通信建立流程的完整拆解拿实际的通信建立过程举个例子假设设备是PassiveHost是ActiveHost发起TCP连接。Host发Select.reqSystem Bytes填0x10000001。设备回Select.rspSystem Bytes填0x10000001表示连接建立成功。Host发S1F13W1携带MDLN、SOFTREV等参数告诉设备“我要建立SECS通信”。设备回S1F14携带COMMACK0表示通信正常并附上设备型号和软件版本。之后Host可以通过S1F1/S1F2查询设备在线状态或通过S1F3/S1F4读取状态变量。这套流程看起来简单但在不同设备上差异很大。有的设备支持热连接不重启设备就能重新Select有的设备必须在Select之前先确认某个初始化标志还有的设备S1F14里COMMACK非0说明设备权限没就绪。联调时拿到设备手册先看通信建立章节再动手。3.4 回复规则W-Bit、System Bytes与超时处理SECS-II里最基础也最容易出问题的就是回复规则。W-Bit为1的消息必须回收到请求后回复消息的Stream和Function按标准要求对应比如S1F13回S1F14S2F17回S2F18S7F5回S7F6。同时回复消息的System Bytes必须原样带回请求的System Bytes主机才能把回复和请求关联起来。如果收到一个W-Bit为0的消息常理上可以不回但不少设备实现里即使W0也会回一个等Function的偶数确认消息。这不算错只是实现差异。反过来如果你发的请求带W1对方却迟迟不回先看System Bytes有没有被对方正确回带再看T3超时是否配置合理。我遇到过一种情况Host发S2F41远程命令设备执行要30秒但Host侧T3设了10秒超时后Host主动断开设备执行完想回确认却找不到连接。后来把这类慢命令的超时单独设置或者改用异步事件上报的方式问题才解决。4. GEM是什么把设备行为变成一套标准剧本4.1 状态模型从初始化到就绪的标准化GEM最核心的价值是规定了设备必须有一组标准状态和状态迁移。这组状态让MES不用关心“这台PVD设备什么时候算准备好”所有设备都按同一套剧本走。主要的几个状态维度Host Link State通信连接状态分为ACTIVE、COMMUNICATING、INACTIVE等表示设备与主机之间的逻辑连接是否建立。Control State设备控制权状态OFF-LINE表示本地手动操作ON-LINE LOCAL表示设备在线但由本地控制ON-LINE REMOTE表示远程由主机控制。Processing State工艺执行状态一般分为IDLE、READY、EXECUTING等区分设备当前在待机还是在跑工艺。设备启动时先进入OFF-LINE主机通过S1F13建立通信后再通过S1F17/S1F18等消息请求上线并切换到ON-LINE REMOTE。有些设备还要求执行一系列初始化流程比如回传配方版本、上报当前报警全部完成才能进REMOTE。4.2 报警、事件、配方和远程命令GEM要求的核心能力可以概括为四类报警、事件、配方、远程命令。报警Alarm通过S5F1上报F1里带ALID报警ID和ALCD报警级别/类型Host回S5F2确认。设备侧要维护报警状态报警发生时上报报警解除时也要上报用ALCD区分SET和CLEAR。我见过不少设备把“报警解除”漏了导致MES一直认为设备在故障中。事件Event通过S6F11上报事件要预先在设备侧用CEIDCollection Event ID定义好并且把相关变量Data Variable绑定进去。实际项目中事件是最灵活也最容易被滥用的功能建议尽量精简只上报MES真正需要的事件比如Process Start、Process End、Alarm Set、Carrier Load/Unload等避免高频事件把网络和MES服务打满。配方Process Program走Stream 7消息族设备要支持配方上传、下载、删除、校验等功能Host侧把某个产品对应的全套参数下发设备执行前还要做版本比对。远程命令Remote Command走S2F41/S2F42比如START、STOP、ABORT、PAUSE等。关键点是“参数名”要固定MES下RCMD时按参数名逐项传给设备设备如果收到未定义的命令要回错误码不能静默忽略。4.3 一个设备对接GEM的最低功能清单GEM标准本身有三种符合级别但实际项目里MES要求的功能通常是一份功能清单。以我经历过的设备对接项目为例最低清单大致是支持S1F13/S1F14通信建立以及S1F1/S1F2在线查询。支持S1F3/S1F4状态变量读取至少要能读取设备状态和当前Recipe。支持S2F17/S2F18时间设置保证设备与MES时间同步。支持S5F1/S5F2报警上报与确认。支持S6F11/S6F12事件上报至少包含Process Start/End。支持S7F1到S7F7配方管理相关消息。支持S2F41/S2F42远程命令。支持S2F49/S2F50高级配方管理视设备能力而定。这些功能不是“设备支持GEM”就自动具备的很多设备固件只实现了标准子集。写技术协议时最好把上述消息一条条列清楚验收时逐项测试不要凭一句“支持SECS/GEM”就放行。5. GEM300扩展300mm产线自动化的额外要求5.1 载具、晶圆盒与工艺程序管理到了300mm产线设备周边多了一堆自动化硬件EFEM、Load Port、FOUP、OHT搬运系统。这时候协议层面光有Core GEM不够需要GEM300这一组标准来管理晶圆载具和更复杂的调度逻辑。典型的标准包括SEMI E40工艺程序管理比基础配方管理更细支持多级工艺程序引用、查询和版本管理。SEMI E87载具管理定义Carrier在Load Port上的放置、锁定、解锁、移除状态以及Carrier ID读取和上报。SEMI E90基板追踪按基板Wafer粒度追踪片子在设备内的位置和状态。SEMI E94控制作业管理把多个Carrier、多组Recipe组织成一个Control Job统一调度执行。SEMI E84载具交接协议定义OHT天车与Load Port之间的硬件交接时序通过光通信和IO信号实现不走SECS消息。5.2 传输系统对接与基板追踪E84经常被误解为一种网络协议其实它定义的是搬运机与设备之间的物理交接时序类似“请求交接—允许交接—夹爪下降—释放—完成”的IO锁存信号。你在软件层面不会去解析E84的报文但你要在设备主控里把它的状态机跟SECS/GEM的状态关联起来。E90基板追踪则很依赖SECS事件。设备每完成一次Wafer级别的动作就要上报对应事件比如Wafer Start工艺开始、Wafer End工艺结束、Wafer State Change状态变化事件里要携带Carrier ID、Slot ID、Wafer ID等数据变量。MES根据这些事件来维护每一片晶圆在产线上的实时位置实现追溯。这种按片追踪的场景最考验事件上报的准确性和频度。如果设备在某个中间状态漏发了一个事件MES里的Wafer位置就对不上后续自动调度会直接卡住。5.3 GEM300一次性到位还是分步走新建300mm项目我建议在立项阶段就把GEM300相关标准都列进设备规范因为硬件设计和软件接口如果一开始没预留后面再补成本很高。但也不是每个功能都要首版全做。实际经验是分两步首版先实现Core GEM E87载具管理基础事件/报警保证MES能监控设备、能上下载工艺、能知道当前哪批货在做第二版再上E40/E94的复杂作业调度和E90的Wafer级追溯等产线稳定后再做更细的自动化。这样分阶段的好处是不会让设备厂商为了赶交付把所有协议都“实现”一遍结果每项都半吊子验收时到处是坑。协议覆盖广不等于覆盖深先保证关键链路稳再扩展功能是我在300mm项目里最深的体会。6. 联调排障实录我踩过的坑和排查清单6.1 连接层故障连不上、掉线、Select失败连接层问题有一个特点现象五花八门根因往往就在十几个字节的头上。最常见的几个端口不通先确认Passive端的监听端口有的设备默认5000有的是5010还有的会在多个端口同时监听。用telnet或者nc试一下端口通不通立刻见分晓。Select发了没响应重点看会话ID和PType。会话ID超出设备允许范围设备会不回或者直接回RejectPType不是0设备认为不是SECS-II消息直接忽略。连上后频繁掉线先抓包看Linktest交互。如果一直没有Linktest.req说明心跳机制没触发多半是T7配置没开启或者超时配置不一致。TCP连接建立但状态一直是Connecting多半是Active/Passive角色配置重复两边都在等对方。确认一遍配置改掉就好。排查连接层问题最好用网络抓包工具直接看TCP流。能看到Select.req、Select.rsp的交互说明传输层OK再往上看SECS消息。6.2 消息层故障格式错、不回W-Bit、解析异常消息层问题比连接层更隐蔽因为抓包能抓到报文但报文的语义不对。遇到最多的几类W-Bit不回请求发了但对方无响应先看Function有没有带0x80再看System Bytes是不是0或者固定值有的设备会过滤掉系统字节为0的请求。次数对不上回复的System Bytes没原样返回主机侧关联不上事务超时。这个在自研Host时出现频率最高写代码时务必把“回复携带相同System Bytes”写进公共逻辑。数据项格式不匹配设备返回的SECS-II消息里某个数据项长度和类型跟你预期不一致。比如S1F4里状态变量返回了一个空List而不是期望的U2类型。这类问题只能靠严格解析和打日志才能快速定位。消息长度字段被错误截断HSMS的Message Length包含消息头10字节如果客户端只处理数据段后续消息就全部错位。我看过好几版内部工具把长度当成“SECS-II body长度”来用导致第二条消息永远解析失败。6.3 开发自检清单与调试工具推荐联调前照着这个清单过一遍能省掉大量来回扯皮的时间确认设备IP、端口、Device ID、Active/Passive角色是否一致。确认T3/T5/T6/T7超时参数是否对齐。确认GEM版本和HSMS版本号最好有书面文件。准备一个抓包脚本或工具能实时看到HSMS消息头。先走S1F13/S1F14通信建立再走S1F1/S1F2最后再测事件和远程命令。每个功能测完记录消息编号、方向、耗时和返回码留作验收证据。调试工具方面我常用的组合是Wireshark抓包看TCP流确认HSMS层的Select和Linktest正常再用Python的secsgem库写一个模拟Host或模拟Equipment快速验证消息交互最后拿设备自带的Log界面或者状态机工具做最后定位。这套组合拳用下来绝大多数协议问题都能在半天内定位到具体是哪一层出的问题。跑过几个项目之后我自己有个习惯每到一个新设备型号第一时间拉一份报文清单把“Host发什么—设备回什么—耗时多少—是否异常”记录下来整理成一张表。这张表不仅是验收依据后面设备出问题复盘也是第一手资料。半导体设备通讯协议的东西看着门槛高真正理清分层和标准关系后剩下的就是耐心跟每一步消息较真。

半导体设备通信协议解读：SECS/GEM、HSMS与GEM300联调实战

相关推荐

RH294实战拆解：Ansible playbook驱动的RHEL 8.6系统治理

企业级宿舍维修管理系统：SpringBoot+Vue+MyBatis实战拆解

悬臂梁连续体振动分析：Matlab解析解与有限元仿真全流程

更多资讯

企业知识库问答Agent：RAG+MCP+多模态架构实战指南

基于Python深度学习的GFPGAN图片修复：从源码到实战

GPU推理并发上限计算器：从物理瓶颈到工程落地

单文件AI编码代理：融合GUI操控与MCP协议的自动化利器

AI Agent治理：防止企业数据泄露的四大缺口与落地实践

FPGA定点牛顿-拉夫逊除法器：Verilog手写高吞吐除法实现

今日更新

插件加载失败深度解析：从did not activate到生命周期排查指南

SpringBoot+Vue+MyBatis企业级房屋租赁管理系统源码解析

企业核心数据灾备自动化：用 OpenClaw 备份到本地 + 云端 + 离线存储的 TaoToken 统一通道实践

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？