SECS/GEM协议层全解析：从HSMS到SECS-II再到EAP对接的实战指南

说实话我刚接触SECS/GEM/GEM300/EAP这套体系的时候第一反应是这不是给工程师看的协议这是给密码学家看的暗号。满屏的S1F13、S6F11、W位、Header、Block像是某种古老的电报码。后来在设备自动化项目里泡了几年被各种莫名其妙的“能连上但没消息”“发了请求不回复”“回复了但是报格式错”折腾过之后才慢慢把这条链路摸顺。这篇是系列第二讲专门把协议层一次说透——它到底分几层、消息是怎么编码的、设备上线要经历哪些流程、GEM和GEM300在协议上额外约束了什么以及EAP这类上位机系统对接时最该盯住哪些点。不管你是刚入行的设备工程师、要写EAP的软件开发者还是被设备厂商文档绕晕的集成人员这篇都适合当一份“能落地”的参考。1. 协议层到底包含哪些东西先打破“通信协议报文格式”的误解很多人以为协议层就是“消息长什么样”这是最大的误解。SECS/GEM的协议层本质上是一整套“设备与上位机之间怎么建立会话、怎么传输消息、怎么处理超时、消息内容用什么语法表达、哪些消息在什么状态下允许出现”的规则集合。它远远不止报文格式。1.1 四层模型里协议层占据的位置整个SECS/GEM体系在逻辑上可以切成四层我从下往上排一下层级对应标准/概念干什么用类比物理传输层SECS-I串口方式、HSMS以太网方式把字节从A设备传到B设备管连接、管断开、管传输正确性快递运输车只管把包裹送到消息层SECS-II定义消息的结构、数据类型、Stream/Function编号规则让双方能“读懂同一个句子”包裹里的货物清单规定每个格子放什么设备模型层GEM、GEM300定义设备有哪些状态、哪些事件、哪些变量规定“什么场景下允许收发哪条消息”快递驿站的操作流程规定先签收再入库、先扫码再上架应用层EAP / MES 集成逻辑把上面的协议能力变成业务动作比如配方下发、数据采集、报警联动快递公司的调度系统决定发哪辆车、走哪条路线协议层在严格意义上指的是“物理传输层消息层”这两层。但实际项目里大家提到“协议层”时往往把GEM对消息的使用约束也一起讲了因为脱离GEM的SECS-II消息只是一堆合法但无意义的句子。所以这篇文章把SECS-I/HSMS、SECS-II、GEM约束、GEM300扩展都归入“协议层”这个大范围内来聊。1.2 为什么协议层是整个设备自动化项目里最容易扯皮的地方我做过的项目里几乎每个都能在协议层上遇到分歧。典型场景是设备厂商说“我们支持SECS/GEM”EAP工程师拿着SEMI标准去对发现设备根本不按标准来。比如某些设备把S6F11的事件数据顺序写得和文档完全不同或者在S1F14回复里塞了厂商私有字段。原因在于SEMI标准定义的是一套“能力范围”而设备厂商实际实现的是“一个子集一堆私有扩展”。协议层就是双方博弈的前线——你只有真正理解了每一层在解决什么问题才能在面对“不完全兼容”时快速判断问题出在传输、格式还是状态约束上。这也是我在后面几章反复强调“为什么”的原因。2. 从串口到以太网SECS-I与HSMS的选型逻辑2.1 SECS-I是怎么把一条消息送出去的靠RS-232串口协议就直接跑在串口线路上。SECS-I把一条SECS-II消息拆成若干个Block数据块每个Block最大128字节有些实现可配置为256或512然后逐块发送。发送方每发一个Block接收方要回一个ACK确认确认通过后才能发下一个Block。一条几千字节的大消息就要来回拆装几十次加上串口的波特率通常只有9600、19200实际传输速度非常慢。SECS-I还有个让我很抓狂的特点它依赖RTS/CTS这类硬件握手信号做流控两端必须把串口参数、块大小、超时时间全部配得严丝合缝。任何一个参数不一致带来的故障现象都是“完全连不上”或者“连上了但传输老是中断”。如果调试现场两头离得远拿笔记本去抓串口数据包又没工具这种问题极其痛苦。现在的新设备几乎不用SECS-I了但很多老设备还在产线上服役。如果你接手的是老产线升级项目遇到串口通信的设备别想着改协议——那是设备固件决定的。老老实实准备一个“串口转以太网网关”把SECS-I的数据包封装到TCP里送给上层EAP。注意网关的参数波特率、数据位、停止位、校验位必须和设备侧一致这是这类项目里最常见的配置坑。2.2 HSMS为什么成为事实标准连接建立的关键细节HSMSHigh-Speed Message Service跑在TCP/IP上默认端口是5000替代了SECS-I的物理层角色。它把消息分成Header10字节Data Body可选的结构底层由TCP保证传输可靠性不需要像SECS-I那样一个Block一个ACK地等。HSMS定义了几种连接模式Active、Passive、Selective。最常见的组合是“上位机Active、设备Passive”——也就是EAP主动去连接设备的5000端口反过来“设备Active、上位机Passive”也存在。Selective模式一般用于多端口场景平时不太碰得到。这里有个容易翻车的细节双方建立TCP连接后并不代表会话就“通了”。设备侧和上位机侧各自维护一个连接状态机连接建立后通常要由一端发送Link Test测试连接消息来探活另一端收到后回复。如果有一方没实现Link Test或者T7空闲超时设置太短就会出现“TCP连接还在但逻辑上已经断开了”的假死状态。我在项目里见过最离谱的一次设备侧T7设了5秒EAP这边设了120秒设备每5秒没收到消息就主动断开EAP还一直以为连接正常直到下次发消息才发现对端没有响应。2.3 实际项目中端口、心跳、超时的取值经验先说结论HSMS默认端口5000但不要想当然。某些设备厂商会把端口改成6000、9000甚至其他值设备文档里也不一定写在显眼位置可能要翻到通信手册的附录去找。配对端口的顺序也重要——Active端告诉你要连哪个IP和端口Passive端监听自己的端口两个搞反了就是“客户端连不上服务器”的经典报错。超时参数方面实际项目中我常用的默认值是这样一组具体以设备文档为准参数典型默认值作用调优方向T345秒等待回复消息的超时设备处理慢就调大T510秒TCP连接建立超时跨网段通信时调大T65秒消息传输超时发到对端确认网络丢包严重可调大T7120秒连接空闲超时超时后断开连接业务长间隔时要调大我个人的习惯是上线初期把T7调大到300秒以上等到系统稳定了再逐步调小避免因为“消息间隔稍长就被断开”这种破事干扰联调。T3则是要特别小心的——设备端如果有一个很耗时的操作比如配方下载校验回复时间可能超过45秒这时候EAP会因为T3超时认为消息失败而设备端其实已经执行完了最后两边状态不一致。这种问题排查起来特别隐蔽后面我会再展开讲。3. SECS-II消息编码与SML和设备说话的唯一语法协议层里的“语言”就是SECS-II。它定义了消息如何表达、数据如何编码、以及一条消息的基本结构。这部分掌握得好不好直接决定你解析设备日志、定位问题是快还是慢。3.1 Stream/Function与W位的实际含义SECS-II把消息按“Stream流”和“Function功能号”来组织。Stream是消息的大类比如S1是设备状态通信S2是设备控制与诊断S5是报警S6是事件通知与数据收集S7是配方管理S10是终端显示。Function是具体功能号奇数通常表示“请求/命令”需要对方回复偶数通常是“回复/响应”。组合起来就是S1F13、S2F41、S6F11这种写法。W位Wait bit是决定“对方是否需要回复”的标志W位为1表示发送方在等待回复W位为0表示这是单方向的通知对方可以不回复。习惯上我们会在消息里显式标注W比如“S1F13 W”表示这是一个需要回复的请求“S6F11 W”表示事件上报并要求确认。这个设计会直接影响超时判断。一对典型的SECS-II消息是“奇数请求偶数回复”比如S1F13请求建立通信对应S1F14回复。如果W位标了1但设备没有回偶数消息发送方就会一直等到T3超时。所以排查“EAP说超时了设备说我没收到请求”这类问题第一步就是确认双方对W位的理解是否一致。3.2 SML长什么样拆解一条真实的S1F13消息SMLSECS Message Language是SECS-II消息的文本表示形式绝大多数厂商日志和EAP调试界面都用它来展示消息。一条典型的S1F13长这样S1F13 W L L U4 1 A 4 MDLN A 8 SOFTREV 逐行拆解一下L ... 表示一个List列表在SECS-II里相当于一个“结构体”可以嵌套。最外层的L里套了一个内层L。U4 1是无符号4字节整数值是1一般代表MDLN和SOFTREV的版本号。A 4 MDLN是ASCII字符串长度4内容是设备型号名称。A 8 SOFTREV是ASCII字符串长度8内容是软件版本号。设备收到S1F13后回复S1F14格式类似但会把数据区补上真正的设备型号和软件版本。EAP拿到这些信息后才能确定后续用哪个配置模板去解释设备的变量和事件。也就是说S1F13/14不仅仅是一个“握手”它是在做“能力协商”。SECS-II的常用数据类型还包括B二进制、BOOLEAN布尔、U1/U2/U4/U8无符号整数I1/I2/I4/I8有符号整数、F4/F8浮点、A定长ASCII、String变长字符串。实际项目里A和String是最容易出问题的地方——有些设备把所有文本都按A处理有些按String处理长度解析逻辑不同导致EAP把字符串读歪。3.3 看设备日志和数据包时最该注意的解析陷阱厂商设备日志里展示的SML通常已经是“格式化后的文本”看着没问题。但真正到二进制报文解析时有几个坑高频出现第一字节序。SECS-II的大部分数值是大端Big-Endian存储的但有些嵌入式实现会搞成小端。尤其在解析U4、U8这种多字节整数时顺序反了读出来的值完全是天文数字。排查方法是找一条已知消息做锚点比如S1F14里的MDLN版本号手动把二进制转成十进制校验字节序。第二List里的元素顺序和Tag名。SML文本能看到A MDLN、A SOFTREV这种名字但到了二进制数据体里只是一串类型码长度值并没有字段名字。EAP解析唯一可靠的方式是“按位置解析”——第0个元素是型号第1个元素是版本。如果设备厂商偷偷在中间多塞了一个字段后面的全错位。所以EAP代码里别写死固定索引要按List长度动态解析解析完再校验字段数量对不上就记一条“协议解析异常”日志。第三消息长度字段的边界。HSMS的消息头里带了一个字节长度表示后面数据体有多长有些EAP实现会把Header自身10字节也算进去有的不算。这种差异会导致整条消息被截断或者多读直接触发T3超时或者协议解析错误。4. 从S1F13到在线/离线切换一次完整的状态通信链路讲完消息语法我们把消息串起来看一次真实的设备通信过程。这部分我建议所有做EAP的人都反复读几遍因为你后续调试80%的问题都会落在这条链路的某个环节。4.1 设备上电后被EAP“接管”的完整流程第一步EAP与设备建立HSMS连接。前面说的Active/Passive模式决定EAP是去连设备还是等设备来连。连接建好后EAP主动发S1F13 W意思是“你好我要跟你建立通信”。设备回S1F14如果回复的ACK代码是0表示接受非0表示拒绝拒绝原因常见的是“设备正在被另一个上位机控制”。第二步EAP发S1F1 W你是活的吗Are you there?设备回S1F2回复里带上设备当前状态比如IDLE、READY。这步的意义是确认设备应用层已经就绪而不仅仅是TCP连接存在。第三步EAP请求上线发S1F17 WRequest ON-LINE设备回S1F18确认设备从Local/离线状态切换为Online状态。只有进入Online状态EAP才能向设备下发远程指令比如S2F41、S7F1。这个流程里最容易出问题的是第三步。部分老设备在“本地操作”状态下根本不会响应S1F17或者需要操作员在设备面板上手动打到“Remote”状态。EAP发了S1F17后一直等不到S1F18最后T3超时。遇到这种情况别急着改代码先看设备当前处于什么模式——很多设备的HMI人机界面上有个钥匙开关或软按钮写着Local/Remote不切到RemoteEAP再怎么做都被动。4.2 报警与事件上报S5和S6系列怎么配合设备运行过程中出现异常会主动上报报警消息号是S5F1Alarm Report。报警ID由设备的ALID唯一标识每个ALID对应一条具体的报警含义这个对应关系在GEM配置里定义EAP侧会维护一张映射表。EAP收到S5F1后要回S5F2确认。S5F3/4是启用/禁用某条报警的指令——如果你只关心关键报警可以用S5F3把次要报警全关掉减少大量刷屏。真正承载“自动化数据”的是S6系列。S6F11是事件上报Event Report设备在某个Event发生时把预先定义好的变量集合打包发给EAP。EAP回S6F12确认。一个事件可以携带多种数据比如“批次开始”事件里带上配方号、晶圆ID、腔体压力等。这些变量集合不是设备随机塞的而是EAP提前用S2F33/34Define Report定义好的。我在项目里遇到一个有意思的情况设备把S5F1报警也当成S6F11事件来发导致EAP同时收到两条路径的同一报警。后来发现是设备配置里把“报警”的Report也勾上了。这种问题不影响功能但会把报警数据在数据库里写两份严重干扰后端的统计分析。排查时不要只盯着EAP代码也要看设备的报告配置。4.3 配方下发与数据收集的典型交互模式配方管理走S7系列。EAP用S7F1Process Program Load Request把配方内容下发给设备设备回S7F2确认。S7F5是删除配方S7F19是查询当前配方列表。大多数设备会在收到配方后做格式校验和CRC校验校验失败回一个错误码EAP得能把这个错误码映射成可读的失败原因。数据收集不一定非要等事件。EAP可以使用S2F17获取设备日期时间校准系统时间用S6F1Trace Init启动周期性的数据追踪——比如每500毫秒采集一次温度压力持续到指定条件结束。这在工艺调试阶段特别有用能拿到连续曲线而不是“事件触发才记录”的离散点。实际调试经验下发一个复杂配方时设备可能长时间不回复S7F2因为它在校验和存储。EAP侧的T3最好针对这类消息单独放宽或者干脆改成“异步等待后续查询”模式——发完S7F1后不傻等回复而是轮询S7F19确认配方是否真的存在。这条经验帮我解决过好几个“配方下发总失败”的疑难杂症。5. GEM在协议层上到底约束了什么没有GEM的SECS只是空壳5.1 状态模型为什么“能发消息”不等于“可以在任何时候发消息”SECS-II只是定义了“这么说合语法”但GEM定义了“在这种状态下允不允许你这么说”。GEM的核心之一就是设备状态模型。它把设备分成两大类状态通信状态Communications State和控制状态Control State。通信状态简单说就是“链路开着还是关着”——对应HSMS的Connection和Disconnected。控制状态则复杂一点设备可以处于Online、Offline、Paused等状态。EAP执行远程操作前不仅要求HSMS连接正常还要求设备处于Online状态、且没有被本地操作打断过分区控制模型里Host有权、Local有权两边能同时操作不同部件。这个模型直接解释了为什么有些请求会失败。比如设备处于Offline状态时你发S2F41让它开腔门它会回复一个“无效操作”或干脆不响应。第一次遇到这种问题的EAP开发人员容易误判为“设备通信坏了”其实只是状态机不允许。5.2 SVID/ECID/ALID/VID四类ID的划分规则GEM把设备里的数据点抽象成几类IDEAP的配置模板基本就是围绕这几个ID转的ID类型全称用途典型例子SVIDStatus Variable可读取的状态变量当前温度、压力、真空度ECIDEquipment Constant可读写的设备常量腔体上限温度、报警延时时长ALIDAlarm ID报警编号冷却水流量低VIDVariable ID事件/报告里要采集的变量集合配方号、晶圆批次号EAP要做的事是把这些ID和实际业务含义绑定。比如SVID 1001可能是“反应腔压力”也可能在另一台设备上代表“机械手当前位置”不同设备即使型号相同ID映射也可能不同。所以每接一台新设备都要先读它的GEM配置设备厂商通常提供一份变量清单再维护到自己EAP的配置库里。5.3 怎么理解GEM合规性检查很多采购合同里写着“设备需支持SECS/GEM”但实际验收时你会发现设备厂商能跑起来一套最小流程不代表所有GEM要求都满足。GEM合规性的底层逻辑是“子集自选一致性声明”设备可以声明自己实现了GEM的哪个子集比如“支持报警管理但不支持Trace”。对EAP这边来说与其对着SEMI标准逐条核对不如直接做三轮验证第一轮用GEM标准工具跑一遍基本消息S1F13/14、S1F1/2、S5F1/2、S6F11/12看设备是否都正确回复第二轮把你要用到的业务消息都发一遍确认设备的响应在预期内第三轮做异常测试比如在设备忙时发指令看它会不会正确地返回Busy错误码。这三轮过了基本就能支撑实际生产。6. GEM300扩展了协议层的哪些空间300mm产线的核心诉求是“尽量少的人工干预”。晶圆搬运、载具交接、批次追踪都要靠系统自动完成这对SECS/GEM的协议层提出了远超传统GEM的要求。我在做300mm项目时感受最深的是EAP不再只是“收数据、发命令”而是要和设备协同管理“批次的完整生命周期”。6.1 面向300mm工艺线的消息扩展配方执行与批次追踪GEM300引入了Process Job工艺任务的概念。一个Process Job对应设备执行一个完整工艺过程里面关联了配方Process Program、晶圆/Lot批次、承载盘Carrier等信息。通过S2F49Process Job Command下发指令S2F50回复结果S2F51查询任务信息。EAP需要维护Process Job的状态等待、运行、完成、异常中止并且要和MES里Lot的加工批次做一一对应。这里有个看起来很基础、实际很容易乱的细节一台设备同时只能跑一个Process Job但设备内部可能有多个腔体每个腔体可以同时处理不同批次。EAP要管理的是“Process Job”和“物理腔体”之间的关系而不是简单地把整个设备当成一个大黑盒。我见过有EAP设计者把Process Job和设备腔体混为一谈结果一个腔体出问题后整个Job被错误地标记为失败连带把其他腔体正常处理的批次也给Cancel了。6.2 载具管理与自动搬运的协议协同300mm产线里设备前后有Port物料口搬运系统比如天车要把载具FOUP放到Port上设备才能取片加工。这一整套动作在协议层上通过载具管理消息与设备状态同步。Port从空到有载具、从锁定到解锁、载具ID的读取每一步都有对应的状态切换和消息通知。EAP在这里的角色有点像“翻译官调度员”从MES收到“某批次已准备送料”的消息然后驱动设备侧把对应Port状态切到“允许装载”天车系统放完载具后设备读载具ID并上报EAP核对ID和批次是否匹配。ID核对失败是最常见的异常——FOUP上的RFID读取偶发失败设备就会报“Carrier ID Mismatch”这时候产线只能人工干预。6.3 EAP在GEM300协议层下真正要做的事在GEM300环境下做EAP和传统GEM最大的区别是状态管理从“设备级”细化到“批次级/载具级”。EAP侧要维护的数据结构会复杂很多至少要包含设备状态、每个Port的状态、每个Process Job的状态、每批晶圆的位置和加工进度。这也要求EAP的消息处理不能是简单的“请求-响应”模式而要有一个“状态机引擎”。比如收到设备上报“Process Job完成”事件后EAP要先更新本地任务状态再检查该批次是否有下一道工序如果有主动触发搬运系统把载具移到下一台设备。这套逻辑在协议层上并没有标准规定完全是EAP自己的实现。但底层通信的可靠性还是靠前面讲的S1、S5、S6系列消息打底。7. EAP对接协议层的常见坑与排查习惯最后这部分是我最想在社区里分享的。协议层的理论知识翻标准都能看到但实际对接时那些“不致命却特别耗时间”的坑才是真正体现经验的地方。7.1 T3/T5/T6/T7超时的真实含义与调优前面参数表里列了默认值这里展开说说项目里具体怎么调。T3回复超时是所有超时里最影响用户体验的。设备执行一个动作可能需要5秒、10秒甚至更久如果EAP对每条消息都用同一个T3就会出现“设备其实在做但EAP已经判失败”的局面。我的做法是给EAP的消息发送接口设计一个“按消息类型覆盖超时”的能力S1F13、S1F1这种轻查询用30秒S2F41这种控制命令用60秒S7F1配方下发用300秒。设备端如果也支持T3配置最好两头都放宽保证一致。T5连接建立超时在跨网段、有防火墙的现场最容易触发。设备在车间EAP在厂务机房中间经过三层交换、安全策略过滤TCP握手慢几秒很正常。T5默认10秒在跨网段场景可能不够我习惯调到20到30秒。T7连接空闲超时前面提过了默认值往往偏短联调阶段直接调到300秒避免EAP和设备的“逻辑连接”被设备单方面干掉。等系统稳定了再按业务周期去收紧。7.2 “能连上但消息不通”的完整排查链路这类问题占到协议层故障的一半以上。我总结的排查顺序是物理链路→连接会话→握手消息→业务消息→消息内容。第一步先确认TCP有没有通。在EAP服务器上直接ping设备IPtelnet设备端口确认端口在监听。如果不通看VLAN、防火墙、网线别进应用层折腾。第二步确认HSMS会话有没有建起来。很多设备的状态页面上有“Connection”指示灯或者EAP的日志会打“Connected”。如果这里显示OK看有没有周期性Link Test消息在跑。没有Link Test的话连接处于“半开”状态随时可能假死。第三步看S1F13有没有发出、有没有回复。用设备端的抓包工具或EAP日志确认S1F14是否回来、ACK是0还是非0。如果S1F14的ACK非0说明设备拒绝了通信请求多半是“另一个上位机占用了”或“设备没有处于可通信状态”。第四步看具体业务消息的超时。比如S2F41发出后设备没反应那就要看是不是T3到了。此时最好能拿到设备侧的操作日志确认设备是否真的收到了消息。如果设备没收到那就是消息发出去了但没到达或者设备根本在忙。第五步解析消息内容。用SML格式把二进制转出来核对字段数量、长度、类型。这里最容易暴露设备厂商实现和标准不一致的问题。这套链路走下来80%的问题都能定位到明确层次。怕的是跳过物理层直接查应用层最后绕一大圈回来发现是交换机端口被禁了。7.3 我处理过的几个典型兼容性问题最后分享三个我印象深刻的真实案例都用虚构代称描述。案例一某设备商A的机台EAP发S2F17获取时间后设备一直不回但设备自身面板操作正常。查了很久最后发现是设备固件版本太老S2F17的回复逻辑有Bug——只有先收到S1F13建立通信后才会正常回S2F17而那次现场是先重启了EAP、设备侧通信进程还活着导致设备认为“通信早建立了”但EAP侧会话信息丢了。解决方式是EAP启动后强制重新建立一次完整的S1F13流程而不是复用之前的通信状态。案例二某设备商B的机台S6F11事件上报的数据里把变量名Tag完全颠倒和文档对不上。EAP按标准解析全部失败。后来我们EAP侧加了一层“按Tag名解析不匹配时报详细日志”的容错逻辑才在几天内定位到是设备配置模板的问题最后设备厂商远程刷新配置解决。案例三某国产设备商C的机台HSMS连接建立后EAP发S1F13设备回了一个“格式错误”的S9F1。抓包后发现设备把消息头里的Session ID解析错了它期望的是0实际收到的是1。原因是我们EAP在连接建立后把Session ID从0递增到1设备端固件没处理好。这种问题只能双方协调——让EAP侧保持Session ID为0或者让设备升级固件。这三个案例的共同点都不是标准上“写没写”的问题而是“实现时碰上了什么细节”的问题。协议层的经验基本就是这么一点点攒出来的。如果你正在做设备自动化对接我的建议是手里备一份SEMI标准的目录结构不用背全文但要能在5分钟内查到某个消息号属于哪个Stream、大致格式是什么同时一定在EAP代码里把原始报文和解析后的SML同时记录下来别只记录解析结果。很多兼容性问题最后都是靠翻原始日志定位的。