我最早被SECS/GEM这套东西教育是在一条量产线的MES联机调试现场。设备侧报着乱码一样的报错主机侧日志里全是超时重连操作员站在终端前干瞪眼我翻着几百页的SEMI标准文档翻到凌晨。那时候才明白半导体设备通讯不是写个Socket对接一下那么简单SECS/GEM/GEM300背后的设计逻辑、状态机和消息规范决定了你的设备能不能在产线上真正稳定跑起来。这篇内容写给三类人一是刚接手设备自动化、被HSMS连不上S1F13不回复这类问题折磨的工程师二是设备厂商里要开发SECS/GEM通讯模块的软件同事三是想搞懂半导体工厂的设备和MES之间到底怎么说话的行业新人。我会把这套协议家族从传输层到业务层完整拆开再把联机落地时最容易踩的坑一并交代清楚。1. 先把成员认全SECS-I、SECS-II、HSMS、GEM、GEM300在协议栈里的位置很多人第一次接触这堆缩写是懵的SECS、HSMS、GEM、GEM300名字长得像却分别处在完全不同的层级。先用一张纵向的视角把它们排开你才能明白每条标准到底在解决哪一段的问题。1.1 从物理线缆到业务逻辑各标准各管一段这套协议体系由SEMISemiconductor Equipment and Materials International组织发布编号从E4开始一路铺开SECS-ISEMI E4最早的物理传输层标准定义了基于RS-232串口的半双工块传输规则解决字节怎么在线缆上可靠传输的问题。SECS-IISEMI E5消息内容和语义标准定义了消息的编码格式、Stream/Function消息对、数据项类型解决双方交换的数据长什么样的问题。HSMSSEMI E37后来取代SECS-I成为主流传输方式基于TCP/IP定义了在以太网上如何建立会话、校验连接、传输SECS-II消息。GEMSEMI E30在SECS-I/II或HSMS之上的一层设备行为规范把零散的消息约定整合成标准的状态机、事件上报、远程命令、报警管理等能力。GEM300SEMI E39/E40/E84/E87/E90/E94等系列面向300mm晶圆厂的进阶标准集合重点解决载具管理、晶圆级追踪、作业管理和搬运自动化的问题。打个比方如果把设备和主机比作两个人打电话SECS-I/HSMS是电话线路本身SECS-II是你们约定的语言词汇GEM是你们约定的对话礼仪和办事流程GEM300则是针对工厂车间协同办公这套复杂场景的完整规章制度。1.2 为什么不用HTTP/REST非要搞一套二进制协议这个问题我每次讲都会被问到。现代软件都走REST API、JSON半导体设备通讯为什么还用上世纪风格的二进制消息原因无非三点。第一产线对实时性和确定性的要求极高。设备在高速运转中一条报警或状态变化必须毫秒级到达主机HTTP的握手开销和JSON解析成本在这种场景下是不可接受的。SECS-II消息用紧凑的二进制编码一条状态上报通常只有几十字节解析在单片机上都能轻松完成。第二协议栈的功能覆盖远比业务API完整。状态机同步、会话保活Linktest、消息确认W-bit机制、多块传输、异常中止Abort这些机制在半导体产线的高可靠性要求下缺一不可是一套完整的工业级会话协议而不是单纯的数据接口。第三历史包袱和生态绑定。这套标准从上世纪80年代一路演进到今天所有设备厂商、MES厂商的工具链、测试规范、验收流程都围绕它建立。换一套新协议意味着整个供应链的推倒重来这在制造业里几乎不可能发生。2. HSMS与SECS-I传输层的两种活法以及定时器里的大学问传输层解决的是消息怎么从A点到B点。SECS-I属于老黄牛HSMS则是今天绝对的主流。但无论哪种定时器都是整个传输层最容易出问题的命门。2.1 SECS-I串口时代的半双工规矩SECS-I的年代设备还没有网口一条RS-232串线波特率9600半双工。它的协议细节在今天看来相当有年代感但设计思路值得了解因为存量产线里仍有大量旧设备在跑SECS-I。SECS-I将一个完整的消息Message切分为一个或多个块Block。每个块最大254字节其中10字节是块头包含设备ID、Stream/Function、块号、系统字节等剩余最多244字节是数据。块与块之间通过ENQ/EOT/ACK/NAK这组控制字符做握手需要确认后才会发下一个块。每个块头里的块号最高位标识这是不是最后一个块接收方据此组装完整消息。它的定时器设计非常关键T1字符间超时接收方等待下一个字符的间隔超时防止线路卡死。T2块间超时发送方等待接收方ACK的时限。T3应答超时消息接收方需要回复时发送方等待回复的时限。T4主动发送方在多块消息的块与块之间等待接收方就绪的时限。SECS-I的问题也很明显半双工意味着同一时间只能一方发送效率低串口的传输速率跟不上现代设备的吞吐量块的分割和重组逻辑复杂。所以当以太网普及后HSMS几乎完全取代了它。2.2 HSMSTCP/IP上的会话协议HSMSHigh-Speed SECS Message Services基于TCP/IP默认端口5000报文结构比SECS-I清爽得多| Message Length4字节 | Message Header10字节 | Data可选 |Message Header的10字节是整个协议的核心Session ID2字节即设备ID标识是哪个设备会话。Stream1字节六位有效表示消息流号。Function1字节低位7位是功能号最高位是W-bitWait-bit标识是否需要对方回复。PType1字节消息负载类型0表示SECS-II消息。SType1字节消息类型。0表示数据消息1-9是控制消息Select.req、Select.rsp、Deselect.req、Deselect.rsp、Linktest.req、Linktest.rsp、Reject.req、Reject.rsp、Separate.req。System Bytes4字节系统字节用于把请求和回复对应起来。HSMS与普通TCP长连接的本质区别在于它定义了完整的会话概念。连接建立后主动方需要发送Select.req收到对方的Select.rsp确认后这个会话才算真正可用。连接空闲时需要周期性发送Linktest.req进行保活检测确保链路没有半死状态。HSMS支持三种连接模式主动模式设备主动连主机、被动模式设备监听等待主机连接、以及主动/被动同时启用的模式。实际产线里设备端通常配置为主动模式开机即向主机发起连接。2.3 T3/T5/T6/T7/T8五个定时器定生死HSMS比SECS-I省心但定时器依然不能乱配。GEM标准里对HSMS相关定时器有明确建议值定时器含义GEM建议值T3消息应答超时等回复45秒T5主动连接重试间隔5秒T6控制消息应答超时5秒T7TCP连接建立超时10秒T8网络字符间隔超时5秒这五个定时器里T8是最容易被忽视的坑。T8定义了连接上两个字节之间的最大间隔超时如果对方发了一半数据停住超过T8会被判定为连接异常。有些设备在传输大数据时没有把数据一次性写入socket缓冲而是分多次写中间停顿一长主机侧就直接断开连接。这种问题在实验室里很难复现一上产线就频繁掉线。T3的配置也要讲究。如果一处通讯交互中主机发了请求但设备迟迟不回复超过T3后发送方就会终止等待并可能引发Abort。很多联机故障的根因都是设备端某条消息处理逻辑走了慢路径超过45秒没有回包主机已经按超时处理了两边状态就错位了。所以凡涉及与数据库、文件系统交互的消息处理都要确保在T3窗口内完成或者单独放在后台线程处理。3. SECS-II消息究竟长什么样从Stream/Function到SML传输层把消息搬到对方门口真正的内容要由SECS-II来解读。这一层是日常开发打交道最多的部分你调试时看到的S1F13、S2F41、S6F11每一个都代表一个具体的业务动作。3.1 一条消息的完整旅程SECS-II消息的核心标识是Stream流和Function功能。Stream代表消息的类别域比如S1是设备状态类S2是设备控制类S5是报警类S6是数据报告类Function代表该类别下的具体操作。约定上请求类Primary消息的Function通常是奇数回复类Secondary消息是偶数。比如S1F1是主机问你在吗S1F2是设备回答我在。一条消息是否要求回复由W-bit决定。W-bit1时接收方必须回复同一Stream/Function对中的偶Function消息并用相同的System Bytes这样发送方才能把回复和请求关联起来。消息体的数据部分用SECS-II的数据项类型编码常见的有LList列表相当于数组可以嵌套。AASCII定长ASCII字符串。U1/U2/U4/U8无符号整数按位数区分。I1/I2/I4/I8有符号整数。F4/F8浮点数。BOOLEAN布尔值。BIN二进制字节。S8八字节字符串常用于文本。开发时通常不直接面对二进制而是使用SMLSECS Message Language这种文本表示。SML长这样的S1F13 W U1 0 .这条消息表示主机向设备发起建立通讯请求Establish Communications Request负载是一个U1类型的数据项值为0含义是请求建立通讯。3.2 高频消息实战建立通讯、远程命令、事件上报联机调试中最高频的几个消息对我逐个说。S1F13/S1F14建立通讯设备上线后主机发S1F13或设备主动发S1F13设备回复S1F14带上设备型号MDLN、软件版本SOFTREV等信息。这是所有通讯的第一步跑不通这个后面都免谈。S1F14的负载结构里有三个List第一个是通讯状态0表示成功第二个是设备ID和型号第三个是软件版本。很多新人在这里栽跟头把List的结构写错或者直接把S1F14发成空List主机解析失败就会反复重发S1F13。S2F41/S2F42远程命令主机通过这条消息命令设备执行动作比如开始制程START、停止STOP、切换配方。S2F41的负载第一项是命令IDRCMD后面跟着参数列表。设备收到后执行再通过S2F42回复执行结果ACKC6区分成功、参数错误、不支持等。这条消息是GEM远程命令机制的基础。S6F11/S6F12事件报告设备主动向主机上报事件比如腔体压力异常晶圆开始处理制程完成。S6F11的负载里最关键的是CEIDCollection Event ID事件ID主机通过CEID就能识别发生了什么事件。S6F11后面还要带一串Report每个Report里放具体的变量数据比如温度采样值、配方名、载具ID。这个容量不固定可以很大几十上百个变量塞在一条报告里都正常。S5F1/S5F2报警报告设备发生报警时主动上报。S5F1包含报警IDALID报警编号、报警级别ALCD1-9级1最低、9最高和报警文本。S5F2是设备对主机清除报警确认的回复。如果消息对不上号或超时SECS-II还有一个兜底机制——S9F1消息格式错误报告和S9F3未定义消息报告。收到这类消息意味着对方根本没法解析你发的东西赶紧回头查编码。3.3 数据项编码不是简单的字节序问题SECS-II数据项在每个消息里的排列顺序是固定的不能随便换。我曾见过一个设备厂商把S2F41的参数顺序写反导致主机收到后把配方名解析成了工艺参数整个批次全部错乱那真是半夜被叫起来的惨痛教训。整数数据的字节序按大端Big-Endian传输这一点和网络字节序一致但很多从嵌入式行业转过来的工程师习惯小端思维在这里容易写反。字符串类型要严格按声明长度填充不足补空格超长要截断否则对方解析时会把后续字段位置整体推偏引发S9F1错误。4. GEME30把碎散的通讯约定焊成一套设备行为规范SECS-II定义了消息怎么编码但它没规定设备什么时候该发S6F11主机能不能在任何时候发S2F41设备掉线后要怎么恢复。GEM标准把这些补充完整相当于给设备和主机之间立了一份完整的行为契约——双方都按同一套状态机和流程行事产线自动化才可能成立。4.1 GEM的九大核心能力到底在管什么GEME30标准定义了设备的九类标准能力我列个表能力说明典型消息标准通讯Communications建立/断开会话在线/离线切换S1F13/S1F14、S1F15-S1F18设备状态Equipment Status通过变量SV和设备常数EC查询设备数据S1F3/S1F4、S2F13/S2F14数据收集Data Collection按事件上报或按轨迹追踪收集数据S6F11/S6F12、S6F1/S6F2报警管理Alarm Management报警上报、清除、查询S5F1/S5F2、S5F3/S5F4远程命令Remote Commands主机远程发起设备动作S2F41/S2F42配方管理Process Program Management配方的上传、下载、删除、查询S7F1-S7F8文件传输File Transfer设备与主机间传输文件S6F13-S6F16、S1F15/S1F16部分场景设备常数Equipment Constants可配置参数的读取和设置S2F29/S2F30、S2F31/S2F32在线/离线控制On-line/Off-line控制设备是否接受主机控制S1F15-S1F18注意在线在GEM语境里不是指网络连通而是指设备接受主机控制的运营状态。很多时候设备网络是通的但状态机处于Offline或Online Local主机发的远程命令会被拒绝。4.2 状态机Communication、Host、Equipment三层状态GEM状态模型分三层三层是嵌套关系Communication状态通讯状态表示设备与主机之间的会话是否建立。有Not Ready未就绪、Ready就绪但没建立会话、Communication Enabled通讯已建立三个状态。S1F13成功后进入Communication Enabled。Host状态主机状态表示主机侧的逻辑状态。NOT READY主机刚启动还没准备好、READY主机已就绪、ONLINE LOCAL主机在线但设备处于本地控制、ONLINE REMOTE主机在线且远程控制。Equipment状态设备状态表示设备当前被谁控制。OFF-LINE设备本地控制不接受主机命令、ON-LINE LOCAL设备在线但按本地逻辑运行主机只能查看、ON-LINE REMOTE设备在线且完全由主机远程控制可接收远程命令。三层状态相互约束比如Equipment状态只有在Online Remote时主机才能发S2F41执行远程命令。很多联机问题都出在状态不一致上设备认为自己在Online Local主机认为设备在Online Remote两边各执一词命令发下去被拒绝还找不到原因。所以联调的第一步永远是先把状态同步跑通让双方对状态机的认知一致。4.3 Collection Event把状态变化变成数据资产GEM的数据收集机制围绕Collection Event收集事件展开这是整个标准里最核心也最灵活的部分。设备厂商需要先定义CE比如制程开始制程结束报警产生每个CE关联一个或多个Report每个Report引用若干个数据变量温度、压力、流量、配方ID等。主机通过S2F33/S2F34数据报告配置或S2F35/S2F36事件报告配置来动态使能或禁用这些CE。这套设计的价值在于事件的触发由设备决定事件包含哪些数据由配置决定。产线工程师可以随时调整Report内容而不用改设备软件。我在实际项目里经常遇到一种情况主机那边要新增一个监控参数设备厂商说改代码要排期三个月但如果当初CE的Report配置做得足够灵活只需要通过S2F33把新的数据变量挂进已有Report里主机侧配置下发就搞定了完全不用动设备固件。5. GEM300当300mm晶圆厂要求设备零手工干预GEM300不是单条标准而是面向300mm晶圆厂的一系列标准的统称。300mm产线相比200mm最大的变化是晶圆装载完全自动化、载具FOUP在整个工厂流转、每片晶圆的制程历史都需要精确追踪。这些需求不是一个GEM标准能覆盖的于是SEMI推出了一系列补充标准。5.1 300mm产线为什么不能靠人工扫码撑下去200mm时代的载具是开放式的晶圆盒操作员可以手工开盒、取片、扫码记录。到了300mm晶圆尺寸变大、重量增加、对洁净度和防静电要求极高FOUPFront Opening Unified Pod是完全封闭的内部环境受控晶圆不能暴露在外部。搬运、开盒、装载全部由自动化设备完成人工干预既不可能也不允许。这就带来一个核心问题主机MES/BC必须实时知道每个FOUP在哪台设备上、每片晶圆在什么位置、当前正在执行哪个制程步骤。于是E87载具管理和E90基板追踪应运而生。5.2 E87与E90载具管理和基板追踪E87Carrier Management定义了一套载具生命周期的状态模型和消息。载具从进入设备开始经过载入Carrier ID读取、装载Load、解锁、处理、锁定、卸载Unload等环节每个环节都有对应的状态和事件上报。设备通过S2F41远程命令接收开始装载或卸载指令通过S6F11上报载具状态变化。E90Substrate Tracking则下沉到晶圆级。每片晶圆在设备内部移动到哪个工位、正在被哪个加工模块处理、處理完了没有都要通过E90定义的状态和事件精确上报。主机依靠这些信息维护每片晶圆的实时位置和制程进度这也是最终生成完整晶圆制程历史Genealogy的数据来源。我参与过的项目里E90的数据准确率是衡量设备自动化成熟度的关键指标。出现过这样的情况设备报告晶圆已处理完成但主机侧的实际数据根本没更新最后查出是设备内部把处理终止和处理完成两个事件用了同一个CEID上报S6F11发出去后主机解析到了相同事件ID直接丢弃了后面一条。这种问题只有靠在测试阶段严格核对状态转换矩阵才能堵住。5.3 E40/E94制程作业与控制作业的关系E40定义的是Process Job制程作业PJE94定义的是Control Job控制作业CJ。举个例子容易理解一个Control Job对应主机下达的一个生产批次指令它可能包含了多个Process Job每个Process Job对应一个设备上一组晶圆的具体处理任务。Control Job的管理逻辑更偏产线调度Process Job则更贴近设备执行。设备收到主机下发的CJ后会解析里面的PJ序列按顺序或按并行关系执行每完成一个PJ就上报一次状态。CJ和PJ的状态模型在E94/E40里有明确定义包括Pending、Active、Paused、Complete、Aborted等主机和设备的交互就是围绕这些状态变化展开的。这里的坑在于PJID和CJID的全局唯一性管理。两边各自维护一套ID序列一旦出现ID冲突或重复使用主机就会把新作业关联到旧作业的制程历史上。规范的做法是在设备端用独立的自增序列或时间戳组合来生成ID并在E40的PJ创建消息S2F41 RCMD CreateProcessJob里带上完整的PJID、载具ID、基板ID列表让主机可以从源头核对。5.4 E84搬运系统的光通讯交接E84Enhanced Carrier Handoff解决的是搬运设备比如OHT天车或AGV和加工设备之间载具交接的标准化问题。过去搬运设备和加工设备之间的交接依赖机械限位加人工确认速度慢且容易出错。E84使用一组标准的光通讯信号PHS、Transfer等让搬运设备与加工设备通过握手信号同步吗不是光通讯信号实际上是定义了标准的信号引脚和握手时序。E84定义了标准的载具交接端口Load Port信号交互时序搬运设备到达后通过一组离散信号请求交接加工设备确认端口就绪后搬运设备将FOUP放入并完成机械锁紧然后双方通过状态信号确认交接完成。这套标准化的时序保证了不同厂商的搬运设备和加工设备能够无缝对接。6. 联机落地的实战心得从开发环境到量产线的六个坑理论讲完说说实际联机时最容易踩的坑。这些全是我在项目里真金白银换来的教训按从开发到量产的时间顺序排。6.1 第一步永远是模拟器不是真设备开始写SECS/GEM代码前先找一个好用的模拟器。主流的免费选项包括一些开源SECS模拟器商用工具功能更全。联机调试时至少需要两个角色Host模拟器和Equipment模拟器。我的建议是开发设备侧代码时用Host模拟器反向测试开发主机侧时用Equipment模拟器模拟设备。模拟器能帮你快速构造各种边界消息空List、超长字符串、非法数据项类型、乱序的System Bytes。这些场景在真设备上很难复现但在生产环境里一旦出现就是重大事故。6.2 定时器与系统字节最隐蔽的联调杀手前面提到的T3/T8超时以及System Bytes匹配问题是联调阶段排查量最大的两类问题。System Bytes不匹配的典型表现是设备收到了主机的请求正确地执行了动作并回复了但回复里携带的System Bytes跟请求对不上主机端根本找不到对应的等待队列直接把回复丢弃然后按超时处理重新发起请求。结果就是同一条命令反复执行。排查这类问题的标准动作是抓包。HSMS走的是TCP/IPWireshark能直接解析HSMS报文可以清楚看到每个消息的System Bytes、W-bit、S/F。我在调试时习惯同时抓三路数据Wireshark抓网络包、设备端日志、主机端日志三路对齐比对定位效率最高。6.3 消息并发与乱序处理很多人写通讯代码时默认一问一答的串行模型但SECS/GEM场景里消息完全可以并发。Host可能在设备处理S1F13的同时又发来S2F41设备可能在上报S6F11的过程中收到S1F3的查询请求。如果设备侧的消息分发处理是单线程阻塞的一条慢消息会拖死整条通讯链路。必须采用接收线程分发线程业务处理线程池的架构接收线程只负责把消息解包并查表业务线程池处理具体逻辑回复动作由处理逻辑完成后发出。对特别耗时的任务比如读取数据库、访问文件系统处理线程内要先回一个已收到、处理中的中间消息部分消息支持Processed状态比如S6F12的ACKC2避免触发T3超时。6.4 事件报告配置先想清楚要哪些数据GEM里CE/Report的配置不是开发完再补的而是在方案设计阶段就要和主机方、工艺工程师一起敲定的。实际项目里最常见的返工原因就是S6F11的事件报告把工艺需要的数据漏了或者把几十个不需要的变量全塞进去导致报文过大。合理做法是分两层设计设备侧预先定义好全部可上报的变量和CE但默认全部禁用主机上线后通过S2F33/S2F35下发配置动态使能需要的CE。这样设备软件发布后主机怎么调整都不需要动设备固件。6.5 日志怎么打才能快速定位问题SECS/GEM联调过程中日志设计决定你的排障效率。很多设备日志只打收到S2F41不打消息内容出了问题完全没法定位。我的日志模板包含这些字段时间戳精确到毫秒、消息方向RX/TX、S/F、W-bit、System Bytes、CEID/RCMD如有、完整负载的SML格式化文本、处理耗时。另外一定把设备状态机的状态切换也打进日志这样能肉眼看到状态变化和消息的对应关系。排查问题时先搜System Bytes能把请求和回复串起来整个对话流程一目了然。6.6 从实验室到产线那些协议之外的问题协议本身跑通了不代表产线能稳定跑。我在多个项目里反复遇到下面几类协议之外的问题一是网络环境差异。实验室是二层直连产线要经过多个交换机、可能还有防火墙。TCP的超时重传、MTU限制、防火墙会话超时都可能导致HSMS连接假死。解决方案是确保设备支持KeepaliveTCP层和Linktest应用层并让主机和设备的超时参数匹配。二是设备时间不同步。SECS/GEM消息里的时间戳一旦和设备真实时间偏差过大主机侧的批次追溯数据就全是脏数据。产线上通常有NTP服务设备机台必须接入NTP或由主机定期用S2F17/S2F18校准时间。三是多设备同时并发时的资源竞争。设备侧同时管理多个FOUP消息里通过Carrier ID和Slot ID区分如果设备内部的数据结构没用好同一个FOUP的并发操作会把内部状态冲掉导致上报数据错乱。开发时要把按Carrier ID维度的状态锁设计好并发请求先加锁再处理。四是版本漂移。设备固件升级后CEID定义、变量ID顺序可能发生变化但主机侧配置没同步更新结果就是所有事件报告的解析全部错位。产线上一定要建立设备和主机之间的版本对应表升级固件前先对版本兼容性。7. 写在最后把标准当成工具别当成负担接触这套协议快十年我最大的感受是SEMI标准文档写得极其枯燥但每一条标准背后都是产线真实问题的沉淀。学习的时候不要试图背下所有消息号而是先建立传输层-消息层-行为层-工厂应用层的框架遇到问题就知道去哪一层找答案。我自己常用的学习路径供参考先用Wireshark抓一段正常联机的报文把HSMS消息头逐字节对照标准看一遍再拿模拟器跑通S1F13/S1F14和S6F11的收发然后对照GEM的状态机文档把设备的Online/Offline切换流程走一遍最后才接触E87/E90这些GEM300标准。真正的成长发生在产线出问题时。我记忆最深的一次是一台设备的S6F11上报偶尔丢失现场抓包发现是设备在高压发的瞬间把报文分成了两个TCP包发送主机侧的老版本解析代码没有处理TCP粘包和半包直接丢弃了不完整的消息。换用正确的流式解析后问题彻底消失。这种经验是任何文档都教不了的只能靠一遍遍抓包、看日志、和现场设备慢慢磨出来。希望这篇梳理能让你少走些弯路。也欢迎带着你联机调试中遇到的具体问题来交流很多坑往往是相似的。