开头就先说点实在的。SECS/GEM这套协议在半导体工厂里永远是那个“看不见但离不开”的角色。前一篇我们讲了它是什么、能干什么这篇直接往深处挖从物理端口到SECS-II消息结构从GEM状态机到GEM300的FDC数据采集再加上EAP在和设备对话时到底在忙些什么。如果接下来要对接设备、写EAP侧逻辑、或者排查通讯故障这篇应该能帮你把整个协议层的骨架搭起来。我自己刚接触这块的时候最大感受是文档里全是缩写每个缩写背后又套着一层协议根本不知道从哪看起。后来啃协议、抓报文、被现场故障折腾过几轮才算把“物理链路—消息封装—状态机—业务语义”这条线走通。这篇文章就按这条线来写尽量用实际报文和典型场景说话少堆概念。1. 底层通讯HSMS和SECS-I数据怎么从设备到主机1.1 先分清两条物理链路协议层之下就是传输层。SECS/GEM最常见的有两种物理传输方式SECS-I基于RS-232串口半双工波特率通常在9600到38400之间现在老设备或某些特殊场景还在用调试麻烦速度也慢。HSMS基于TCP/IP全双工现代工厂绝对的主流。默认端口是5000和5001一收一发支持长连接吞吐量和稳定性都远超串口。在HSMS里TCP连接建立之后报文不是裸着发而是套一个固定格式的消息头。这个消息头一共10个字节结构如下Session ID2字节逻辑会话编号告诉对端消息属于哪条会话通常设备ID就在这里面高四位还要拼上控制标志位。Header Byte 21字节包含Message Type和Session Type。比如Select.req消息类型是0x01Data Message是0x09。PType1字节协议类型SECS-II取值0。SType1字节会话类型0表示SECS-II数据消息非0表示控制消息。System Bytes4字节消息ID用于把请求和响应配对排查问题的时候特别关键。这里有个点容易忽略TCP只是保证了字节流但SECS消息有明确的边界和长度字段。HSMS每个报文最前面是4个字节的Message Length表示后面跟着多少字节的Header加Data。这个长度字段如果解析错了整个数据流就全乱了所以EAP侧解析器第一步一定是严格校验长度和Header里的细节不能想当然。1.2 为什么必须区分Select/Reject/LinktestHSMS不是TCP一连上就直接传SECS-II数据的。连接建立后先走一遍会话建立流程基本是“选择—响应—确认”的节奏主动方发Select.req。被动方回Select.rsp。主动方再发一个Data消息或直接进入正常通讯。这套流程本质是“握手”。虽然TCP也握手但HSMS的握手是解释“你要用哪些Session ID来跑SECS-II”相当于业务层确认。Select.rsp里会带一个状态码0表示成功其他值都是错误原因。连接建立后还有个非常容易被忽视的机制Linktest。链路不能光靠TCP的心跳SECS标准里规定通常每45秒到2分钟要发一次Linktest.req对方回Linktest.rsp。如果连续几次没收到响应就判定链路断开需要重新Select。做过现场的人应该懂很多设备状态显示Online但实际数据全断八成就是Linktest超时后重连逻辑没处理好。调试的时候我自己习惯抓三层包配合看先看TCP层有没有重传再看HSMS的SType和System Bytes能不能对上最后才是SECS-II消息本身。如果系统里出现大量重发消息先别怀疑应用逻辑查链路和超时参数往往是更高效的路径。1.3 端口选择的讲究标准端口是TCP 5000和5001但实际部署里不一定非得这两个。有些设备用任意的自定义端口有些EAP只能配置单个IP加端口。这里常见的坑有两个设备只监听一个端口主机侧却配置了双向连接导致一组连接一直连不上。防火墙只放行了5000设备却改用了5001结果Select一直不成功。所以对接初期先把端口和连接方向确认清楚再谈报文。端口这块我踩过不止一次有一次是设备配置错误端口被改成了6000EAP这边按5000去连抓包看了半天才发现是端口不通。单纯看日志只能看到“Connection Refused”非常迷惑人。2. SECS-II消息Stream和Function怎么配合2.1 Stream/Function就是“大类和具体指令”SECS-II把消息按StreamS和FunctionF分类写法就是SxFy。比如S1F1是“Are You There”S1F2是“On Line Data”S6F11是“Event Report”S2F41是“Host Command”。Stream相当于类别Function相当于这个类别里的具体动作。每个Stream的含义基本固定S1设备状态、通讯控制。S2设备控制和诊断。S5报警。S6数据上报。S7配方管理。S10终端显示。S12晶圆地图。S15配方管理扩展。S16FDC数据采集。S1F1这种消息不光要发STM还要带System Bytes。S1F1发过去之后设备必须回复S1F2即使没有数据也要回一个空LIST。这里有一个容易混淆的点SECS里和“指令”相近的词有Primary Message、Reply Message、Secondary Message。Primary Message是主动发起的Reply Message是回应Primary的。一条Primary消息可以对应多条Reply。SxFy中的F单数一般是Primary双数一般是Reply这个规律适用于绝大多数消息但不是绝对。2.2 消息结构拆解Header后面的Data才是重点SECS-II消息的Header是固定的10字节Data部分用特定格式编码。这里拿一个真实场景举例设备在线后EAP发起S1F1查询00 00 00 0B 00 01 00 00 00 00 00 00 01 01 01 01拆开看是这样00 00 00 0BMessage Length表示后面有11字节。00 01Session ID这里是1。00Header Byte 2表示Stream1、Function1、W-bit0。00PType0。00SType9表示SECS-II Data Message。00 00 00 01System Bytes这条消息的ID为1。后面的Data部分就是一个Item。Item的结构分为Format Code、Length、Value。具体来说01Format Code1表示LIST。01Length1表示LIST里有一个元素。01Format Code1但这一层是L/B空列表不对这里要小心格式码1是LIST格式码2是BINARY等。实际数据取决于设备。严格说S1F1不带Body时Data部分就是一个空LIST有些实现甚至Data长度为0只发Header。标准要求S1F1的Body是LS,我见过有些EAP对空Body处理不够健壮S1F1发出去后如果设备回了带异常内容的S1F2解析就会崩。所以在解析器层面一定要做“预期外数据容忍”处理不能假设所有回复的LIST结构都和文档完全一致。常见Format Code如下0LIST最常用。1BINARY1字节无符号整数。2BOOLEAN。3ASCII字符串。4INT8。5INT16。6INT32。7INT64。8UINT8。9UINT16。10UINT32。11UINT64。12FLOAT432位浮点。13FLOAT864位浮点。解析LIST时要注意嵌套层级和长度很多解析bug就出在这里。比如以为某个字段是固定位置结果前面多了一个可选Item整个索引就全错位了。2.3 W-bit的妙用SECS-II Headers里有一个W-bitWait-bit用来指示设备收到这个Primary消息之后是否需要回复。一般W-bit1时消息需要回复W-bit0时不一定需要但大多数情况还是回。W-bit最有价值的应用场景是Host CommandS2F41。比如EAP下发一个“Start Process”命令可以把W-bit设成1要求设备处理完以后用S2F42回复命令执行结果。这样EAP就能判断命令是被接受还是被拒绝以及执行状态是否完成。如果不带W-bit或者设备实现得不严谨命令有没有执行成功完全靠猜那后面产线就有得折腾了。TTT3/T5/T6这些超时参数的关注点也在这里。发送S2F41之后如果设备没有在期望时间内回S2F42EAP侧要能识别并做超时处理。有些设备处理命令本身就慢比如需要几秒钟才能完成的动作超时时间设得太短会一直误报设太长又会拖累异常发现速度。一般T6的推荐值是5秒但实际要根据设备类型调整。3. GEM标准设备必须具备的“行为规范”3.1 GEM不是新协议而是“设备必须做到什么”GEMGeneric Equipment Model不是独立的协议它是建立在SECS-I/II之上的功能标准规定了半导体设备向主机暴露哪些能力。也就是说SECS-II定义了消息格式但设备什么时候发、怎么回、状态怎么变是由GEM约束的。核心要点包括状态模型设备有Offline/Online状态Online里又分Local和Remote。事件报告设备发生重要行为如Process Start、Recipe Start/End、Alarm Set/Clear时要主动发S6F11事件报告。变量采集设备提供设备变量和状态变量EAP通过S1F3/S1F4等消息查询或订阅。报警管理设备产生报警时通过S5F1发报警消息清除时发S5F2。远程命令EAP通过S2F41下发命令设备执行后S2F42回报。配方管理GEM300中通过S7Fxx等消息进行配方处理。状态模型里最经典的几个状态Offline设备在本地模式不接受远程控制。Online-Local在线但本地操作可以上报数据但不能远程控制。Online-Remote完全远程控制EAP可以直接下命令。注意有一种情况是Equipment本身处于Online但控制状态还是Local。这种情况下有些命令设备会拒绝所以EAP必须先查询状态再决定是否下发命令。有些设备实现里ControlState的切换要通过S1F17/S1F18这类消息来设置不能直接在SE里改。我在现场遇到过一台设备从设备面板切到Auto之后EAP里状态迟迟不变。排查了老半天结果不是EAP问题也不是插件问题而是设备只在某些条件下才上报On-Line状态。这就说明GEM事件模型里每个状态转换都不是必然上报的EAP侧最好用周期性的S1F1/S1F3查询兜底别完全依赖事件。3.2 事件报告S6F11是怎么组织的S6F11格式是S6F11 organized as: L DATAID // 报告ID L DATAID2 // 比较ID RPTID1 // 报告ID1 L ...DVVAL... // 变量值 实际解析时有点绕。第一个DATAID是给整条Event Report的唯一标识第二个DATAID是这个event里第一个Report的比较IDRPTID指向报告模板后面的LIST是具体变量值。S6F11里可以带多个Report所以嵌套层数很深代码里处理递归List结构要特别小心。举个例子一个Process Start事件报告里可能带设备时间戳。当前Recipe ID。当前Slot ID。Process腔体压力。腔体温度。这些变量的顺序和类型由设备的Report配置决定。EAP侧解析S6F11时必须知道每个RPTID对应的变量排列不然拿到一串值也看不懂。3.3 变量查询S1F3/S1F4S1F3用来查询设备变量或状态变量。发S1F3时Body是一个LIST里面可以混合设备变量DVVAL和状态变量SV。设备回S1F4把每一个变量的ID和值都返回回来。格式如下S1F3: L DVVAL1 DVVAL2 SV1 S1F4: L L DVVAL1 value1 L DVVAL2 value2 L SV1 value1 这个查询看似简单但在大产线上有个性能问题一台设备几百个变量频繁查询会占用大量链路带宽。所以GEM里定义了“数据收集”Data Collection机制通过S2F33/S2F34等消息配置采集周期和采集组设备按配置定时上报EAP就省了查询开销。4. GEM300扩展FDC、APC和配方管理4.1 FDC数据采集是实时监控的关键GEM300不是独立协议是SEMI E5、E37、E39、E40、E87等标准的集合主要面向300mm晶圆工厂的需求。它最大的特点是引入了面向晶圆的数据追踪能力。FDCFault Detection and Classification就是通过S2F41/S6F11等消息把设备的腔体压力、温度、气体流量、RF功率等高频数据采集到主机侧用于异常检测和分类。采集参数的关键项有采集范围一个或多个腔体。采集周期毫秒级到秒级不等取决于参数变化速度和检测要求。采集触发通常绑定到Process Start事件。FDC采集的数据量非常大一条Process可能持续几分钟每秒采集多个参数一个批次下来就是海量数据。EAP侧要能及时处理这些上报不能阻塞也不能丢失。一般建议用异步队列接收FDC上报数据处理放到专用线程池接口层只负责快速解析和入库。4.2 APC过程控制闭环APCAdvanced Process Control更多体现在主机侧逻辑不是协议本身的强制内容。常见实现方式是设备上报FDC数据后APC模块通过分析模型计算下一步的工艺参数调整量再通过S2F41下发调整后的Recipe或参数。这个闭环要求通讯延迟非常低。从设备事件发生到APC计算结果回写到设备整个链路通常在几秒内必须完成。如果中间任何一个环节阻塞工艺就会跑偏。所以EAP侧不光要处理消息还要关心消息通道的优先级。一般建议把S6F11这种事件消息和S2F41这种命令消息放在同一个连接但要通过业务层的优先级排队机制保证命令不被海量FDC上报挤压。这一块在生产上是最容易遇到性能瓶颈的。设备在Process中一秒上报几十条FDC数据EAP如果每条都同步处理CPU占用会很高。我自己的做法是消息解析和业务处理彻底分离解析完直接放入环形队列业务线程批量消费数据库插入走批量提交实测能扛住每秒几百条消息的负载。4.3 配方管理R2D是重点GEM300里配方管理通过S7系列消息实现包括S7F1请求配方列表。S7F3请求当前配方ID。S7F5请求配方内容。S7F19配方确认和校验。S7F21配方删除。S7F23配方存档和加载。实际业务里主机下发一个配方通常不是直接把整个文件丢给设备而是先通过EAP把配方内容拆成标准格式的S7F5/S7F6消息逐条发送最后再校验。配方文件的传输对协议解析的健壮性要求很高一个字节错了整个Recipe就要重传。R2DRecipe-to-Device是面向300mm产线的配方分发模型强调在配方下载前做完整性校验、下载中做分块传输、下载后做数据比对。EAP在R2D链路里既要当翻译器还要当校验器。我见过有些项目里R2D下载的Recipe大小有好几MB远远超过单条SECS消息的承载能力所以必须拆分成多条S7F5消息还要维护会话状态确保所有分片到达后设备才能组装出完整Recipe。5. EAP的角色它到底在协议层做了什么5.1 EAP是“翻译官”加“调度员”EAPEquipment Automation Program处于MES和设备之间。从协议层角度看它做三件事和设备建立并维护HSMS连接解析SECS-II消息。把设备的SECS消息翻译成MES能理解的数据模型如批次、晶圆、配方、工艺步骤。把MES下发的工单、工艺要求翻译成设备能执行的消息指令。所以EAP本质上是个协议转换器不只是透传。它要处理的细节非常多维护会话状态和消息重传。处理设备主动上报的事件更新内部状态。管理配方和参数的缓存。处理并发——多台设备同时上报EAP不能被拖死。日志记录必须要完整尤其是消息二进制和解析后的结构化日志最好都有排查问题的时候能少抓瞎。5.2 常见的通讯实现框架成熟的EAP通讯层一般分层设计传输层管理HSMS连接、心跳、重连。编解码层把二进制转为SECS-II对象模型。业务层根据SECS消息类型分配处理器。应用层对接MES、调度、质检、FDC等模块。传输层最核心的挑战是重连机制。设备可能因为断电、重启、面板操作而断开连接EAP侧要有自动重连和重新Select的流程。重连时不能简单地把旧连接关掉再建新的有些设备对并发连接很敏感必须先等旧Socket完全关闭再发起新连接。编解码层要注意字节序。不同设备的实现可能在U4/U8等字段上存在字节序差异严格按标准来实现的同时也要给某些特殊情况留一下扩展点。5.3 消息处理和超时处理消息处理流程大概是这样收到TCP数据按HSMS长度字段切割出完整消息。解析Header判断是控制消息还是SECS-II数据消息。如果是SECS-II根据Stream/Function找到对应的处理器。处理器里解析Data部分更新业务状态。如果需要回复构造Reply消息填充原始System Bytes发送。如果超时未收到对应Reply触发重发或异常告警。超时处理的参数建议做成可配置不要硬编码。不同设备的处理能力差异很大一台老设备处理S1F3查询可能就要几百毫秒设3秒超时都未必够。但FDC文件传输的下载超时又不能设太长否则悬死一个下载任务挂半天。6. 报文示例一次完整交互可以这样看6.1 建立连接和Select假设EAP作为主动方连接设备IP: 192.168.1.100:5000TCP连接建立后EAP发Select.req00 00 00 0A 80 01 00 00 01 00 00 00 00 01 00 00 00 01解析一下00 00 00 0A总长度为10字节。80 01Session ID0x8001控制消息的标志位是0x8000这个会话ID是控制会话。00Header Byte20因为Select是控制消息没有Stream/Function。00PType0。01SType1表示Select.req。00 00 00 01System Bytes1。设备回Select.rsp00 00 00 0A 80 01 00 00 00 02 00 00 00 01 00 00 00 01关键差异是SType2。如果Byte11状态字节是0说明Select成功否则是失败原因。6.2 设备上报事件假设设备发生“Process Start”事件上报的S6F11大致如下简化到只剩核心字段00 00 00 33 00 01 00 01 00 01 00 00 00 05 01 01 01 16 02 01 03 0B 45 76 65 6E 74 53 74 61 72 74 04 03 80 01 01 04 03 80 01 02虽然报文看起来乱但按Item结构拆解后就能看到LIST( DATAID1, LIST ( REPORT-ID5001, EVENT-NAMEEventStart, ... ) )数据部分包含事件原因、时间戳、触发源等信息。EAP收到后要快速解析出事件类型和关键数据再映射到业务模型里。如果事件上报里带的数据不完整EAP应该能识别并打告警不能把空数据当正常事件处理。6.3 命令下发EAP下发“启动工艺”命令用S2F41S2F41 W L L ASCII START_PROCESS L ASCII PASS_1 ASCII RCP001 设备执行后回S2F42Header里带上这条消息的Message Type和System Bytes确保上下文的关联。如果设备忙或者参数不合法S2F42里会带HCKHost Command Acknowledge状态码EAP要根据HCK码做后续处理。7. 常见问题与排查技巧实录7.1 连接反复断开现象EAP和设备之间的连接建立后过几秒就断日志里出现超时重连记录。排查点检查防火墙是否只允许单向连接。检查Select.rsp里状态字节是否成功。确认设备是否配置了允许来自该主机IP的连接。看TCP层是否有RST包如果有说明某一侧主动断了连接。实际现场中最常见的坑是设备面板或配置界面里启用了“双主机”模式导致同一时间只能有一台主机连接EAP连上后被另一台顶掉。这种情况日志里极难发现只能通过抓包看RST方向和时机。7.2 S6F11上报后EAP无响应现象设备持续上报EAP没有回S6F12。排查点看EAP侧是否实现了S6F11的处理如果只处理了S6F13等消息就没回复。检查消息里的RPTID与配置的Report是否匹配不匹配会导致业务层拒收。确认解析器没有因为前面的异常消息卡住。GEM规范要求设备上报之后主机必须在T5时间内回复S6F12。但实践中有些设备即使没收到S6F12也能继续工作而有些设备会一直等着。所以EAP侧务必保证S6F12的回复不出错。7.3 变量值漂移或数据类型不对现象EAP解析出的温度、压力值明显不在合理范围或者直接解析失败。排查点检查Format Code是否匹配设备可能把INT4当成了INT8。确认变量在设备侧的单位和EAP侧是否一致。检查滑动窗口重叠问题比如消息顺序错乱导致后续报文解析错位。这种问题只能在联调阶段通过抓报文和实际值对照来发现。建议在EAP侧加一个“协议字段级日志”每个解析出的关键变量都打出原始字节和解析结果方便快速对比。8. 协议对接中的经验补充到这里想额外说几点经验都是踩过坑换来的。第一联调阶段永远先确认设备侧版本。很多“怪异现象”其实是设备固件版本不一致导致的有的版本S1F4返回的结构和文档描述的差一个Item有的版本S6F11的DATAID类型从INT2变成了INT4。平台侧一定要在启动时做协议版本协商或配置化兼容方案别把设备版本写死。第二日志做得好排查快十倍。SECS通讯日志至少要有这几层原始报文Hex、解析后的结构化消息、业务处理结果。三层缺一不可。原始报文Hel用于深入抓包分析结构化消息能快速定位是协议层还是业务层的问题业务处理结果能判断是不是MES侧逻辑出错。