1. 先搞懂SECS/GEM到底在解决什么问题1.1 半导体工厂“设备联网”的第一道门槛做半导体设备软件这行绕不开SECS/GEM。不管是做前道光刻机、刻蚀机还是后道测试机、分选机只要这台设备要进晶圆厂要跟工厂的MES制造执行系统对话就必须支持SECS/GEM。没有这个协议设备在工厂里就是个信息孤岛工艺参数靠人输、生产数据靠人抄产线自动化根本无从谈起。很多刚入行的人第一次接触SECS/GEM第一反应都是“这不就是个通信协议吗跟MODBUS、CAN差不多”。这个理解不能算错但会让后面的学习走很多弯路。SECS/GEM不是一条简单的总线协议而是一整套面向半导体制造场景的“设备通信与行为规范”。它定义了设备以什么格式上报数据、在什么时间点报、主机能不能干预、设备状态怎么迁移甚至连超时时间、重传机制、数据精度都做了统一约定。一句话概括SECS/GEM解决的问题是“晶圆厂里几百台不同厂家的设备如何用一种统一语言和主机对话”。有了它换一台设备不用重写MES接口加一台新设备只要它符合GEM规范主线系统就能直接接管。1.2 协议族不是一个协议而是一套组合SECS/GEM通常被当作一个词来用实际上它至少包含四层东西SECS-ISEMI E4最早基于RS-232串口的物理传输协议定义了数据块怎么在串口上分包、校验、重发。现在已经逐步退居二线但老设备还在用。SECS-IISEMI E5消息层定义数据怎么编码、消息由“Stream/Function”分组、数据项用什么类型嵌套这是所有通信内容的“语法”。HSMSSEMI E37基于TCP/IP的以太网传输协议现在主流设备基本都用HSMS替代SECS-I端口一般约定为5000。GEMSEMI E30这层最关键它规定设备必须具备哪些“行为能力”——怎么报告事件、怎么响应远程命令、怎么管理状态、怎么处理报警。打个比方SECS-I/HSMS是“邮局和邮车”负责把信送到SECS-II是“通用信纸格式”规定了字怎么写、句子怎么排而GEM是一本“办事员手册”规定收到某封信之后该做什么动作、什么时候回信、哪些情况要主动发信。很多初学者只盯着SECS-II的消息格式研究忽略了GEM的行为规范结果报文能收发联调时依然一塌糊涂。2. 核心细节解析消息格式和GEM行为模型2.1 SECS-II 消息的四个核心字段解析任何一条SECS-II消息先看四个东西Stream、Function、W-Bit、System Bytes。Stream和Function缩写为“SxFy”比如S1F13就是指Stream 1、Function 13。Stream是消息的大类Function是具体功能。为了方面记忆业内一般按“S1Fxx是通信相关、S2Fxx是设备控制和数据采集相关、S5Fxx是报警相关、S6Fxx是事件报告相关、S7Fxx是配方相关”这个规律来查。当然这只是大类具体还得翻SEMI E5标准。W-BitWait-Bit表示这条消息是否需要对方回复。置1就是“请求-应答”模式主方发一条带W的消息从方必须回一条对应的消息才能结束这一个会话。典型的就是S1F13Establish Communication RequestW位一定为1对方回S1F14。如果W-Bit为0表示这是单方面通知不需要回复。System Bytes呢相当于这次会话的交易流水号。发请求时需要把用户自定义的四个字节系统字节带上回复时原样带回这样收发双方才能把“一问一答”配对起来。实际联调排障时第一件事就是看系统字节能不能对上。对不上要么是设备端代码写错了要么是中间有网关做了消息改写。2.2 SECS-II 数据项与SML嵌套结构SECS-II的数据项类型不多但嵌套规则很严格。最常见的类型有类型含义说明LList列表类似JSON里的数组可以继续嵌套任何类型AASCII字符串不定长按字节数限制U1/U2/U4/U8无符号整数按字节宽度区分注意对齐I1/I2/I4/I8有符号整数常用于带符号的参数F4/F8浮点数单精度/双精度B二进制原始字节流Boolean布尔值单字节0或1SMLSECS Message Language是描述SECS-II消息的文本格式类似XML一样可读可解析。比如S1F14返回设备信息和软件版本SML长这样S1F14 W L A MDLN-2024 A SW-V1.0.3 但实际数据往往嵌套很深一个事件报告里经常是“List套List里面再套若干个Data Variable”层级七八层都很常见。看这种报文我建议手头准备一个带缩进的SML解析工具或者直接用Wireshark的SECS/GEM插件把十六进制报文转成人类可读的树状结构。要是纯靠肉眼盯十六进制十个有九个会看花眼。顺带说一句SECS-II这种嵌套列表结构和JSON类似考验的就是“嵌套深度”这个基本功。报文解析报错时优先检查左右两边的List数量是否对称、每个元素的类型是否和双方约定的格式一致。2.3 GEM比SECS重要的地方状态模型很多人在SECS-II消息上花了很多时间但真正的难点在GEM。GEM规范的核心不是“怎么发消息”而是“设备在什么状态下允许干什么事”。GEM最常见的是三个状态维度Communication State通信状态描述设备与主机之间的连接状态是否已建立通信、是否正常会话。Control State控制状态描述设备由谁控制通常有OFFLINE、ONLINE/LOCAL、ONLINE/REMOTE三态。OFFLINE就是设备独立运行不接收主机远程指令ONLINE/LOCAL是操作员在设备端本地控制ONLINE/REMOTE是设备完全由主机远程控制。Processing State处理状态描述设备当前是否在加工、是否空闲、是否处于待料等。这三个状态维度相互约束。比如主机想下发远程命令“开始加工”设备只有在ONLINE/REMOTE且当前处于非加工状态下才能接受。如果设备还在OFFLINE主机发命令过去设备就该回错误码而不是“无视”或者“照单全收”。我见过不少设备端开发把SECS消息收发写得挺顺但状态机一塌糊涂。设备还在本地模式主机一连接就认为可以远程操控或者还在处理中收到下一个Start命令也不拒绝。这种设备去FAB做资格认证时会被GEM审计查得很难看。学SECS/GEM一定要把状态模型当成一等公民报文格式反而是学起来最快的部分。3. 实操过程从零搭建一套可运行的通信环境3.1 学习路径标准、工具、模拟器很多新人一上来就问我“先学哪个标准”。我的建议路径很直接先看SEMI E5找消息格式的感觉再看E37了解TCP/IP传输层怎么建立连接然后直接上手E30看GEM场景E4串口协议可以放最后除非你要维护老设备。SEMI标准文档要收费但E5、E30、E37这些核心资料在很多大学的镜像站、行业技术社区里都能找到搬运版本。注意标准版本会更新学习阶段用老版本问题不大但上项目时一定要跟客户确认对方用的是哪个标准版本。工具方面我自己常用的搭配是模拟器开源社区有很多SECS/GEM模拟器设备端和Host端都有。设备端可以用Python开源库自建Host端可以找现成的模拟Host快速发指令验证。抓包工具Wireshark自带SECS/GEM支持但要确认插件版本和TCP端口识别正常。抓包时过滤条件就写tcp.port 5000一目了然。SML编辑器很多商业协议模拟工具自带SML编辑和报文树查看调试效率比看十六进制高太多。3.2 设备端和Host端的角色分工先明确角色Host主机是主动发起方一般部署在工厂MES或EAP设备自动化平台里Equipment设备端是被动响应方像光刻机、刻蚀机这类装备自己带一个软件模块负责跟主机通信。实际开发中设备端工程师和主机端工程师都要懂协议但侧重点不同。设备端更关心“怎么正确响应请求、怎么组织事件报文”Host端更关心“怎么调度采集任务、怎么下远程命令”。学习阶段我建议两边都模拟一遍先用设备端模拟器跟一个现成Host工具联调再反过来用Host脚本去连一个现成的设备端模拟器这样双向视角都有体感排障时不至于一头雾水。3.3 用Python快速搭一个HSMS设备端示例以最常见的HSMS通信为例端口5000设备向Host主动建立连接Active Connection。下面这段Python伪代码演示了设备端如何响应S1F13握手请求# 假设使用一个支持SECS/GEM的Python库 # 更贴近业务的写法如下实际需参考具体库API from secsgem.gem import GemEquipmentHandler from secsgem.hsms import HsmsSettings settings HsmsSettings( activeTrue, # 设备端主动连Host address192.168.1.100, # Host 地址 port5000 ) device GemEquipmentHandler(settings) # 注册S1F13的处理函数设备收到建立通信请求后回S1F14 device.stream(1).function(13) def handle_s1f13(handler, message): # 返回设备型号和软件版本 return [ MDLN-2024, SW-V1.0.3 ] device.start()代码的核心并不是语法细节而是你注册了S1F13的回复逻辑后协议库会自动帮你完成SECS-II消息的编码、HSMS的组包、TCP的收发。这让你可以把精力聚焦到设备业务逻辑上。从报文角度来说Host发S1F13时实际TCP负载大致是HSMS头部带Message Length随后是SECS-II的10字节HeaderDevice IDStreamFunctionW位System Bytes正文为空。设备回S1F14时Header一样但正文是带两个A字符串的List。这段交互是所有SECS/GEM联调的“第一次握手”能在抓包工具里完整看到并读懂它基本就入门了。3.4 常见GEM流程怎么走事件上报、远程命令、报警设备上线之后最常见的三个业务流程是事件上报比如一片晶圆加工完成设备主动向主机发S6F11Event Report主机回S6F12确认。事件里要带上对应的数据变量Data Variable比如腔体温度、加工时间、良率参数。远程命令主机给设备发S2F41Host Command命令名和参数都由Register过的远程命令表决定设备执行完回S2F42带上执行结果。报警上报设备发现工艺异常发S5F1Alarm Report给主机主机回S5F2。报警码和报警级别需要事先在对齐阶段定义好。建议你按这三个流程做三个小实验自己写设备端模拟器再用现成Host工具走通比看十遍标准都有用。做完这三个流程GEM的核心场景就掌握七八成了。3.5 关于工具选型的一些真心话商业化的SECS/GEM中间件像Cimetrix、SECSMI等功能非常全但授权费用不便宜一般中小企业未必愿意掏。开源方案更适合学习和原型验证。Python生态里确实有几个可用项目但功能完备度参差不齐有些人可能还要看C/Java的老库。选型不用太纠结学习阶段重点是一头扎进去把协议逻辑吃透工具只要能跑通就行。项目选型时再根据现场的设备平台、Host框架、性能要求来定。4. 常见问题与排查技巧实录4.1 连接不稳定总是断线HSMS连接建立后双方靠心跳机制维持会话。E37里定义了完整的握手控制消息和超时参数比如T3是“等待回复超时”T5是“连接未建立时的重试间隔”T6是“控制消息等待回复超时”T7是“连接建立超时”T8是“网络传输超时”。联调时最常见的就是T8太小网络稍微抖动一下设备端判断超时主动断开主机还一脸懵。遇到连接不稳定先看两端的超时配置是不是合理再抓包看是不是有对端根本没回消息的异常。4.2 消息能发出去但对方解析失败这类问题90%出在SECS-II消息的数据类型和嵌套层数不一致。比如约定好的返回格式是L [A 设备编号, U2 温度]结果设备端填成了L [A 设备编号, U4 温度]Host端按约定解析当然就报错。另一种常见错误是字符串长度没控制A类型是按字节截断的中文用UTF-8编码后长度很容易算错。建议两端的消息数据结构做成配置文件联调时逐字段核对别靠脑子记。4.3 设备收不到远程命令远程命令的前提是设备处于ONLINE/REMOTE状态。先查设备当前的控制状态S1F1请求设备状态可以返回设备的控制状态如果状态不对主机需要先发S1F15请求离线或S2F17? 其实是S1F16等切换状态的指令。很多调试问题最后定位都是“设备还在LOCAL模式”压根不是协议格式问题。4.4 事件报告丢失或延迟事件报告是设备主动发S6F11给主机主机必须在超时时间内回S6F12否则设备会觉得消息没被确认按GEM规范可能触发事件队列溢出。如果设备上配置了很大的事件队列延迟会越来越大。联调时建议把事件上报频率压得低一点先把链路稳定性验证好再逐步加量。4.5 开发联调阶段最重要的几个习惯第一日志要详细尤其是系统字节System Bytes和收发原始报文都必须记录。没有日志寸步难行。第二抓包工具要随时能上。很多时候设备端和Host端各说各话只有抓包能还原现场。第三建立一套从“S1F13-S1F14握手”到“状态切换-事件上报-报警上报”的冒烟测试用例集每次改完代码先跑一遍能省掉大量返工时间。现象优先排查项补充建议连接建立不成功端口不通、IP配置错误、T5/T7超时太短用telnet或nc先测TCP层通不通握手后马上断设备版本与Host版本不兼容抓包看Response消息的状态码消息解析失败数据类型/长度不匹配用SML树逐节点对比远程命令不执行设备控制状态不是ONLINE/REMOTE先查状态模型再查报文事件丢失事件队列溢出、S6F12未及时回检查事件队列配置和T3超时5. 一点学习心法和后续扩展方向学习SECS/GEM最忌讳的是只研究报文不会看状态或者只会用工具不懂原理。我的体会是先把SECS-II的SML结构和GEM三大状态模型刻在脑子里再上手模拟器效率最高。另外这个协议虽然名字老但演进一直没有停。GEM 300标准已经覆盖了300mm产线更细化的自动化需求一些新的设备端软件架构也开始往微服务方向切把GEM通信模块独立成服务。后续如果条件允许可以再去研究一下GEM 300的Advanced Process Control相关部分以及设备端如何通过SECS/GEM实现配方管理和设备参数追溯。方向很多但核心能力始终是“真正理解设备和主机之间如何可靠地协同工作”这个底层逻辑到哪里都通用。最后再分享一个小技巧遇到复杂场景先把报文手工写成SML文本再翻译成十六进制对照学习坚持一段时间你对数据类型的敏感度会有质的提升。这套方法我带过的不少新人用过普遍反馈比较有效希望对正在学SECS/GEM的你也一样有用。