简介面向半导体制造与设备自动化领域这是一份SECS/GEM协议通信示例工程主要面向设备软件开发者、MES系统集成工程师以及协议初学者也适合需要快速了解设备通信机制的测试与技术支持人员。通过C#工程与HSMS通信模块演示设备与主机之间的消息建立、数据交换与命令交互流程可帮助读者将SEMI标准落地到实际代码层面减少从协议文档到程序实现之间的转换成本。资源共72个文件压缩包约296KB以12个cs源码文件、sln/csproj工程文件、dll依赖库和exe可执行程序为主同时包含json配置文件与pdb调试符号目录结构清晰便于直接打开工程调试运行或二次开发。已有596人学习下载。读者可获得一套完整的Visual Studio解决方案内含HSMS底层通信处理、基础SECS消息封装及可运行的演示程序适合作为学习SECS-I/SECS-II协议交互、GEM设备行为建模的入门参考也可在其基础上扩展数据采集、状态上报与远程控制等自定义逻辑。 第一次把SECS/GEM当成一个“需要单独开会研究的课题”是刚接触半导体设备软件开发那会儿。做设备联调的时候客户MES工程师丢给我一份SEMI规范文档让我先把“通讯建立”跑通再说工艺数据。后来在好几个项目里反复被SECS、GEM、HSMS、SECS-I、SECS-II这些名字绕进去我才意识到这套协议并不是“一个接口”而是一整套半导体设备与工厂自动化系统之间的语言和约定。这篇文章我想结合自己现场调机和写设备端通信模块的经验把SECS/GEM背后的标准关系、消息结构、设备状态机以及实施中的常见坑串成一份可以照着参考的实操笔记。无论你是在做半导体设备端软件还是在工厂侧写EAP/MES接口都应该能用得上。1. 为什么晶圆厂把SECS/GEM写进验收清单1.1 没有它设备就是信息孤岛半导体产线的自动化程度比大多数人想象得高得多。从光刻、刻蚀到清洗、封装每一台设备都运行在MES、EAP、RMS、SPC这些系统的编排之下。设备要实时上报工艺参数、维护状态、报警信息Host系统才能判断“这批产品能不能继续往下走”“这台设备当前OEE是多少”。如果设备不支持SECS/GEM那它就只是一个物理上联网、逻辑上却完全孤立的“哑终端”。举个实际例子。后道封装产线的WB打线机需要下载当前的打线程序、设定压力和时间参数如果每换一个产品都要人工去设备面板上一项项输入不仅效率低还极其容易输错。品保要求追溯每一批产品的工艺配方人工记录基本是灾难。客户验收时直接在协议验收项里写“设备必须支持SECS/GEM通信并能够实现配方下发、事件上报和警报上报”如果你不把这一层做好设备连进入量产评估的资格都没有。所以SECS/GEM的第一个价值不是“给软件工程师增加工作量”而是让设备自动成为工厂数据闭环的一部分。设备状态、工艺结果、报警信息、配方变更全部通过标准化协议自动流转才谈得上实时OEE、工艺追溯和良率分析。1.2 协议家族E4、E5、E30、E37到底谁管谁SECS/GEM不是单独一个标准而是一组由SEMI组织发布的半导体设备通信标准。我第一次接触时报文文件堆了一桌子其实把它们按层级拆开逻辑非常清晰标准编号常用名称主要作用SEMI E4SECS-I基于RS232串口的传输层负责比特流和物理帧SEMI E5SECS-II消息层定义消息结构、Stream/Function以及数据项编码SEMI E30GEM设备行为模型定义状态机、事件收集、警报、远程命令等SEMI E37HSMS基于TCP/IP的高速消息传输层取代串口时代很多客户说“设备支持HSMS”其实他指的是传输层用TCP/IP说“支持GEM”指的是设备行为符合E30的模型要求说“支持SECS/GEM”则是默认你同时落实了E5的消息格式和E30的设备行为。我习惯打一个比方E37是高速公路负责把数据从一个城市运到另一个城市SECS-II是货车上的货箱编码规则规定了每件货怎么打包、怎么拆包GEM是运输公司的调度制度规定车辆什么时候出发、什么时候报平安、遇到故障怎么报警。三层各司其职缺了任何一层现场都会出乱子。2. 通讯建立那几分钟最容易翻车的环节2.1 HSMS握手与心跳消失很多新手在SECS/GEM调试时最困惑的一点是“TCP已经连上了为什么协议不通”。这是把TCP连接状态和HSMS连接状态搞混了。HSMS在TCP连接之上还有一套自己的会话流程。TCP建立完成后双方需要先进行Select交互由连接发起方通常是Host发送Select请求对端设备回复Select应答。这步成功之后HSMS状态才会从“已连接”进入“可通信”。如果设备端不支持当前会话模式或者Host ID在设备端没有登记Select阶段就会被拒绝TCP连接很快被断开。更隐蔽的问题是“心跳消失”。HSMS进入通信状态后双方会用Link Test消息定期确认链路仍然健康。如果设备长时间没有收到Host的Link Test主动断开TCP连接反过来Host也会因为收不到心跳把设备标记为离线。实际项目里遇到过设备端心跳超时配置被改成了默认值现场网络稍微抖动一下设备就和Host失联OEE统计直接出现一个大洞。这里我的调试经验是先用telnet或nc测端口确认TCP能连通再抓包看有没有完整的TCP三次握手和HSMS Select/Select应答最后再去看业务消息。很多“设备连不上”的问题在抓到HSMS Select失败的那一刻就真相大白了。2.2 常见的“建联成功但消息不通”的现场印象最深的一个售后问题设备IP能ping通TCP连接显示ESTABLISHED但Host一直收不到设备主动上报的消息。抓包发现设备端HSMS报文里的Session ID总是一个固定值而Host侧按多会话模式配置期望不同会话使用不同Session ID结果设备上行的消息全被Host丢弃了。两边的工程师各查各的查了两三天最后把两边报文头部的字节拉出来一比对问题秒级定位。另一个高频坑是设备端只实现了一个HSMS单会话实例但Host侧同时和同一台设备建立了多个TCP连接每个连接都尝试Select。设备端只响应第一个连接第二个连接被静默丢弃或直接Close。表面看是“换个Host软件就连不上”实际是会话并发模型不匹配。所以HSMS联调阶段我强烈建议双方把报文抓包工具开好先确认三条链路物理链路通、HSMS Select通、第一条业务消息通。任何一条没通先别急着看后面的业务逻辑。3. 读懂SECS消息体从S1F13到S6F113.1 消息头里的Stream/Function与WbitSECS-II的消息用“Stream/Function”来编号。比如S1F13表示Stream 1的Function 13一般用于建立通信S1F14是对S1F13的应答。整个半导体设备通信中Stream 1是设备状态通知Stream 2用于设备控制和远程命令Stream 5是报警管理Stream 6是事件报告Stream 7是工艺配方这样分类以后看到消息编号心里就有数。每条消息还有个非常重要的Wbit全称是Wait bit。Wbit为1时表示请求方希望对方回复一条Secondary消息相当于“我说完你要回我”Wbit为0时表示这是一条单向通知对方不需要回复。打个比方S1F13W就是Host对设备喊了一句“咱们把通信关系建立起来收到请回答”设备回S1F14S6F11W则是设备向Host上报事件“这是我发生的事件收到请确认”Host回S6F12。如果业务上忘了确认对方会一直重传同一个事件严重时产生消息风暴。3.2 数据项格式List里套List是常态SECS消息的body不是普通JSON那样键值对直白而是用一套固定的数据项类型组成的树状结构。最常用的是List其他还有ASCII字符串、Binary二进制、U1/U2/U4/U8无符号整数、I1/I2/I4/I8有符号整数、F4/F8浮点数等。一个典型的事件上报消息S6F11body结构类似于这样S6F11 L U4 1001 U4 50 L L U4 3 L A TEMPERATURE F4 25.3 这段伪代码的意思是消息先是一个List第一项是事件上报的数据集IDDATAID第二项是收集事件IDCEID第三项又是一个List里面放着报告ID和对应的一组设备变量值。每个元素都有自己的类型标签和长度信息所以SECS消息体是自解释的解析器拿到字节流可以按类型和长度一层层拆出完整数据树。这也是为什么很多人在写解析器时容易出问题嵌套List没有维护好“还剩多少字节没解析完”或者U4和U2解析错了长度导致后续所有字段错位。对付这种事我建议先把所有SECS数据类型的长度表贴在工位上解析器每读取一个数据项都严格记录剩余长度不要用“哪段顺眼就停在哪段”的办法。3.3 事件上报和警报怎么写才合规设备端上报“我现在开始跑这批货”“温度过高了”“状态从待机切到运行”在GEM里并不是随心所欲发个字符串就行。事件要通过收集事件IDCEID来标识CEID必须在设备端的配置表里提前定义好而且要和事件上报数据集绑定。现场常见的做法是Host用S2F33消息下发数据收集计划告诉设备“我需要收集哪些CEID每个事件打包哪些设备变量”。设备收到后保存配置当工艺状态满足事件触发条件时主动发S6F11给HostHost回S6F12确认。一个事件没被确认设备端通常会按配置重传避免因网络瞬断丢失关键数据。警报则走另一套通道。设备检测到明确异常时通过S5F1上报报警并携带报警代码和报警文本Host回S5F2确认。报警消息不能和普通事件混在一起因为E30里对报警有一套独立的生命周期管理分为报警发生、报警清除Host端要用这套状态去驱动声光告警或自动停线动作。4. 设备端状态机建模GEM的灵魂4.1 状态模型与收集事件很多设备软件团队在做SECS/GEM时只关注“消息对没对”却忽略了GEM的核心状态机。GEM标准要求设备维护一套完整的控制状态模型至少能区分离线、在线、Host接管等状态。这套模型的意义是让Host随时知道“我现在到底能不能远程操作这台设备”。举个例子如果设备面板上被人切到了“本地模式”即使TCP连接和HSMS会话都正常设备端收到Host的远程启动命令也应该拒绝——因为操作员在本地优先接管。反过来如果Host系统显示设备在线但设备现场实际已经断电重启状态机没有正确回到离线初始态后续事件上报就是一套错乱的数据。状态跳变必须驱动事件上报。设备从上电初始化到可生产中途经历多少个状态每进入一个稳定状态都要有一个对应的CEID。否则Host端只知道TCP连接活着却不知道设备现在是在抽真空、待机还是正在加工。OEE里最关键的“有效运行时间”就是靠这一格一格的状态事件拼出来的。4.2 远程命令、设备变量、警报的联动GEM的远程命令通常通过S2F41/S2F42实现。Host发S2F41携带命令名和参数列表设备收到后判断当前控制状态能否执行命令能执行就回S4F42并返回命令应答码。这个应答码不是“命令执行成功”而是“命令已被接收”真正执行结果还要靠后续事件来反馈。这里最容易犯的错误是Host把S2F42当成“已经做完了”。S2F42只代表设备端接受了指令真正开始和完成需要设备再发对应的事件。如果业务逻辑只等一个应答码就跳转到“运行完成”极有可能在设备真正启动前就提前通知MES放行下一批产品。设备变量查询则是Host了解设备内部状态的手段。比如查询温度、压力、主轴转速现场通常会通过S1F3/S1F4或S2F13/S2F14这类消息按需获取。实际项目里不建议高频轮询设备变量尤其是几十台设备同时在线时轮询会占用大量消息队列。更合理的方案是订阅关键变量的变化事件设备在阈值越限或状态翻转时主动上报Host端被动接收网络压力小得多。5. 项目上线之前的自测清单与OEE场景落地5.1 自测清单三分钟定位问题我在设备端和Host侧都写过不少自测脚本最后沉淀成一张固定清单。每次现场联调先按这张表完整跑一遍大部分问题都能在十分钟内暴露。自测项方法常见失败现象TCP连接telnet或nc访问设备IP和端口不通先查网段、防火墙、设备侧监听状态HSMS Select抓包检查Select请求和应答无应答查Host ID、会话并发模式是否匹配时间同步Host发S2F17/S2F18查询设备时间回复超时或时间差异大影响后续事件时间戳事件上报在设备手动触发一个已知事件没有收到S6F11查CEID配置和事件触发条件远程命令Host下发S2F41启动命令回复命令拒绝查控制状态是否在Online且Host接管报警上报人为制造一个可恢复报警未收到S5F1查报警配置和报警状态机每次联调我建议两边协议团队用同一份报文抓包文件核对不要各看各的日志。项层协议最怕的就是“我发了你没回”和“你回了我没收到”两种现象看起来一样实际原因完全不同。5.2 OEE数据采集的经典请求序列OEE是半导体工厂绕不开的指标而OEE数据质量本质上取决于设备状态数据采集质量。一套标准的SECS/GEM数据采集序列大概是这样的建立TCP连接完成HSMS Select通过S1F13/S1F14建立SECS通信关系通过S2F17/S2F18同步设备时钟用S2F33配置Host需要的数据收集计划和事件订阅设备正常运行后持续接收S6F11事件记录每个状态的时间戳按需查询设备状态变量、产量计数和良率数据用于计算可用率、性能率和良率。这套流程跑通后设备每个状态的起止时间都能精确到秒OEE计算不再依赖人工填表。设备一出现故障报警EAP系统马上通过S5F1收到消息通知维护人员解除报警又收到清除事件自动结束停机计时。整个链条只要有一个消息没接上OEE报表就会失真。我特别提醒一句事件订阅不是越多越好。每增加一个CEID设备端就多一次事件匹配和队列处理。有的团队为了“以后可能用得上”一口气订阅几十个事件结果设备CPU占用明显升高正常工艺数据反而上报不及时。上线初期先订阅和OEE、报警强相关的核心事件之后按需求逐步扩展才是稳妥路线。最后分享一个我踩过几次坑之后养成的小习惯在开发设备端协议栈时我会先把协议日志和业务日志分开打。SECS/GEM的调试信息大部分是二进制帧如果混在业务日志里出了问题很难快速定位。专开一个协议日志文件记录TCP连接、HSMS状态变化、每个消息的Stream/Function和方向问题定位时间能缩短一大半。等系统稳定上线后再打开过滤器持续记录日常运维会少很多头痛时刻。本文还有配套的精品资源点击获取