★ FEATURED ARTICLE 做设备自动化这些年我接触过不少刚接手 EAP 项目的工程师第一反应都是去翻 SECS/GEM 厚厚一摞标准文档结果被一堆编号和格式给劝退了。其实换个角度把协议当成人话来看事情会简单很多。SECS/GEM/GEM300 这一整套东西说白了就是设备和主机之间的“对话规则”而事件Collection Event是这套对话里最不能绕开的一环——设备什么时候开工、什么时候完工、中途有没有异常全要靠事件来主动通知主机。这个系列第一篇我想把事件单独拎出来从报文结构、订阅流程到工程落地一路讲到底。如果你正在做晶圆厂、光伏厂或者面板厂的设备自动化或者刚接手 EAP 相关需求这篇读完基本能上手处理 S6F11 了。1. 事件在 SECS/GEM 协议栈中的定位设备凭什么“开口说话”1.1 从“打电话”到“报业务”一整套标准在解决什么问题先帮大家把几个名词理顺。SECS/GEM 不是一个单一协议而是一族标准配合起来用。SECS-I 和 HSMS 解决的是“怎么把消息从一个地方送到另一个地方”前者走串口后者走 TCP/IP现在大多数产线都走 HSMSSECS-II 解决的是“每一句话按照什么格式说”定义了消息的流Stream和功能Function而 GEM也就是 E30 标准解决的是“在什么业务场景下说什么话”它规定了设备与主机之间如何处理事件、报警、状态变量到了 300mm 时代又扩展出一批 GEM300 相关的标准把物料搬运、加工流程、设备之间的自动化集成也纳入了统一模型EAPEquipment Automation Program就是在这个阶段成为产线自动化的核心载体。打个比方SECS-I/HSMS 相当于电话线路SECS-II 相当于语法规则GEM 相当于客服话术手册GEM300 则相当于把整个公司业务流程都规范成了标准操作。事件在这套体系里属于“设备主动向主机汇报”的消息类型用 S6 这条流来承载。所以说事件是协议的“上行主力”一点也不为过。1.2 事件、报警、状态变量它们根本不是一回事很多新人上来就问“事件是不是就是报警”这是最常见的误解。我把三者放在一起对比大家就清楚了概念触发方向消息流典型用途状态变量SVID主机主动查询设备被动回答S1F3/S1F4获取设备当前状态、配方名、腔体压力等报警Alarm设备主动上报异常S5F1 等设备门未关、真空异常、硬件故障事件Collection Event设备主动上报状态/流程变化S6F11/S6F13/S6F15开始生产、完成生产、物料到位等状态变量永远都是“主机问设备答”适合做低频的核对和巡检报警是设备在喊“救命”它说明出了异常而事件是不论正常还是异常只要业务节点发生变化设备就会主动发一条通知。举个例子腔体当前的真空度是状态变量你要主动去读真空泵抽气完成、工艺开始这是事件真空度掉了且触发保护这才是报警。分清这三者你在设计 EAP 逻辑时就不会把所有需求都压在轮询上。1.3 为什么事件是 EAP 的地基如果没有事件机制EAP 想感知设备进度就只能不停轮询状态变量。设备台数少还好一旦上百台设备同时运行轮询周期根本没法保证实时性而且设备响应也会被拖垮。事件机制让设备在关键节点主动上报主机不用猜不用问事情发生了就知道。GEM300 下面的自动化流程比如 Process Job 的启停、物料在搬运站点到位都依赖事件来驱动。换句话说事件是 EAP 感知产线动态的神经末梢这一环断了再好的调度逻辑都是空谈。2. 事件消息拆解S6F11、S6F13、S6F15 到底长什么样2.1 SECS-II 消息的骨架理解事件消息之前先记住 SECS-II 消息的基本结构一个消息由消息头加数据体组成。消息头固定 10 字节左右包含长度、Stream 号、Function 号、消息 ID、系统字节等信息。Stream 和 Function 的组合决定了这条消息是“干什么的请求”还是“干什么的应答”。事件相关的消息集中在 Stream 6也就是“数据传输和报告”这条流。其中最重要的三个S6F11Event Report Send设备向主机发送单个事件报告S6F13Data Set Send设备发送数据集S6F15Multi-Data Set Send设备一次发送多个数据集。数据体则是一串按 SECS-II 格式编码的数据项最外层的结构是列表List。List 可以嵌套里面可以放整数、浮点数、ASCII 字符串等各类数据类型。SECS-II 之所以难入门很多人就是卡在这层嵌套格式上。2.2 S6F11最基础的“事件报到”消息S6F11 的数据体标准结构可以写成下面这样S6F11, W Data: L U4 CEID # 事件编号 L U4 RPTID # 报告编号 L ...数据项... # 与该事件绑定的数据集我来拆一个实际例子。假设某台刻蚀设备在工艺完成后上报事件CEID 2002RPTID 5报告里带了一条状态字符串和一组测量数据L U4 2002 # CEID工艺完成 L U4 5 # RPTID L A Completed F8 25.5主机收到这条 S6F11 后第一件事就是从数据体里读出 CEID判断是哪个事件发生了接着读 RPTID找到对应的数据定义最后把后面的数据项按顺序解析出来。EAP 就可以用这些信息更新设备状态、写数据库、触发下一步搬送逻辑。这里有一个工程细节值得单独强调S6F11 消息头里有个 W 位Reply Expected 标志如果设备置 1就要求主机回一条 S6F12 作为确认。S6F12 的数据体是 HCACK0 表示接受。主机即使业务处理失败也应该先回 0再异步处理异常否则会让设备认为消息根本没送达触发超时重发。2.3 数据量撑不住时S6F13 和 S6F15 的适用场景有些事件要携带的数据量很大。比如一台量测设备完成一片晶圆后要上报几百个测量点的图谱数据如果用 S6F11 硬塞一条消息可能会超过几 KB 甚至几十 KB这在高速产线上容易把通信窗口占满拖累其他消息的时效性。GEM300 时代引入了数据集Data Set的概念用 DATAID 标识一组数据通过 S6F13 一次性上传更多场景下用 S6F15一次携带多个数据集。工程上很多设备厂商会把“量测完成”这类大数据事件默认走 S6F13 或 S6F15而把“工艺开始”“工艺完成”这种小负载事件走 S6F11。你写 EAP 解析逻辑时不能只兼容 S6F11最好是三种消息的解析都做成独立模块再统一转成内部事件模型。3. 事件的订阅与生命周期管理不是设备默认就会上报一切3.1 先定义报告S2F33给事件配上要带的数据包设备上虽然有很多事件编号但它不会默认把所有事件都上报也不会自动带上你想要的全部数据。主机需要先通过 S2F33Define Report把一组数据项打包成一个报告Report用 RPTID 标识。比如你想在工艺完成事件里带出“结束状态”和“实测温度”就要先在设备端定义一个 RPTID 5 的报告把对应的 SVID、DVVAL、ECID 放进去。S2F33 的数据体结构大致是S2F33, W Data: L U4 RPTID # 报告编号 L U4 VID1 # 第一个数据项编号 U4 VID2 # 第二个数据项编号 ...定义报告前你一定要先拿到设备端的 SECS 手册确认哪些 SVID 和 DVVAL 是设备支持的。不同厂商的设备甚至同一家厂商不同型号支持的参数编号都不同。我遇到过不少联调现场因为漏看了手册定义了一个不存在的 VID结果事件数据一直解析异常。3.2 再启用事件S2F35Link 是决定上报与否的关键报告定义好之后还要把 CEID 和 RPTID 绑定起来这一步通过 S2F35Link Event Report完成。S2F35 的数据体大致是S2F35, W Data: L U4 数量 L U4 CEID U4 RPTID ...这个 Link 动作有两个含义一是告诉设备“事件发生时要带上这份报告”二是把该事件的状态从禁用Disabled变为启用Enabled。反过来如果想停用某事件发送一个空的报告列表即可相当于 Unlink。现场最典型的翻车现场就是“我明明定义了 Report也看到设备事件触发了但主机就是收不到 S6F11。” 原因十有八九是漏了 S2F35事件没被启用。请把这个流程刻在脑子里先 Define Report再 Link Event Report最后才能在主机侧收到事件。3.3 订阅关系的持久化与恢复事件订阅关系并不一定是持久化的。有些设备断线重连后 Link 关系还能保留有些设备重启后就恢复成出厂默认状态。你无法靠猜必须在联调阶段做一次“断线重连测试”确认行为的设备差异。我的建议是EAP 侧维护一张订阅表把“设备 ID、CEID、事件含义、RPTID、使能状态、订阅时间”全部记录下来。每次 EAP 启动或者发生网络重连后都主动重新执行订阅流程。很多现场故障就是重连之后订阅关系丢失设备链路看着是通的心跳也正常但事件就是不上来。有了这张表排查起来就一句话的事对照表看看当前的 CEID 有没有处于 Enabled 状态。4. 事件的工程化设计从 CEID 规划到事件风暴防护4.1 CEID 编号规划没有跨厂商统一标准但有自己的约定CEID 是设备厂商自定义的没有一套跨厂商的强制编号规范。不过我在实际项目里观察很多设备厂商都遵循类似的分段习惯编号段典型含义1xxx设备状态类事件如 Ready、Running、Idle2xxx工艺类事件如 Recipe Start、Process Complete3xxx物料类事件如 Slot 状态变化、FOUP 到达5xxx报警相关的事件7xxx维护保养类事件这种分段的做法的好处很明显看 CEID 就能大概判断事件属于哪个环节方便 EAP 侧路由和日志过滤。但千万不要凭经验硬套到新设备上每个型号都要以厂商的 CEID 清单为准。做设备验收时我会把“CEID 清单文档”列为正式交付物缺失的话联调阶段必然吃亏。4.2 用事件驱动设备状态机设计在前编码在后EAP 内部维护的设备状态机本质上就是被事件推着走的。我常用的状态集合是IDLE、RUNNING、COMPLETE、ALARM、DOWN。事件与状态迁移的对应关系可以提前规划成这样当前状态触发事件目标状态IDLEProcess StartCEID 2xxxRUNNINGRUNNINGProcess CompleteCEID 2xxxCOMPLETERUNNINGAlarmS5F1 伴随事件ALARMCOMPLETE物料搬离/ResetIDLE设计事件类型的时候最好从业务反推哪些状态迁移必须被 EAP 感知哪些环节即使漏报也不会造成大问题把这些想清楚再决定订阅哪些 CEID而不是把所有事件一次性全 Link。事件订阅得越多解析和处理的复杂度越高出问题的面也就越大。风险在于事件丢失后状态机会卡住。所以状态机不能完全依赖事件还要有兜底机制定时用 S1F3 读几个关键 SVID 做对账或者周期性地发 S1F1 探测设备在线状态。这样即使偶发丢事件也能及时发现状态不一致。4.3 事件风暴一个容易被低估的问题某次现场调试一台设备因为门传感器抖动一晚上向主机发了上千条同类事件直接把主机的日志存储打满还把消息队列堵了。这种事不是个例。处理事件风暴有三层手段第一层在设备侧能去抖就去抖从源头减少无效上报第二层在配置侧只订阅你真正需要的事件不要一股脑全 Link第三层在 EAP 侧做限频处理比如同一 CEID 在 1 秒内最多处理一次或者对连续重复事件做合并。在设计 EAP 时最好给每个 CEID 预留“预期频率”这个属性。工艺类事件几十秒一次、报警类事件不定期、传感器类事件可能密集出现。有了预期频率线上出现异常高频时就能快速识别出来。5. EAP 收到事件之后处理流程与业务逻辑设计5.1 从解析到 Ack动作顺序不能搞错EAP 收到一条 S6F11 后我建议按这个顺序走记录原始报文至少保留消息 ID、CEID、时间戳解析数据体把 CEID 和所有 RPTID 数据提取出来查询订阅表找到该事件对应的业务处理模块立即回 S6F12HCACK 置 0异步执行业务逻辑更新状态机、写库、通知 MES 或调度系统。这里最重要的一点是 Ack 必须先回业务后做。很多初学者把业务逻辑写在 Ack 之前结果处理一慢设备就超时重发了。重发本身不可怕可怕的是 EAP 把同一条事件处理了两遍导致状态机错乱或数据库重复写入。解决重复处理的通用手段是幂等。你可以利用 SECS-II 消息头里的系统字节System Bytes作为唯一键也可以自己维护“设备 ID CEID 时间戳”的 hash 表处理前先查重。加上幂等之后即使网络偶发抖动导致重发处理逻辑也安全很多。5.2 一条 Process Complete 事件背后的完整业务流我用一条最常见的“工艺完成”事件来串一遍全流程。设备进入 RUNNING 时会发 CEID 2001 的事件携带 Process Job ID 和 Recipe IDEAP 收到后更新状态机为 RUNNING记录开始时间回 Ack。设备工艺结束发 CEID 2002 的事件携带结束状态码和一批工艺数据EAP 收到后先校验这个 Process Job 是否在跟踪列表中然后把数据整理成统一的事件模型写入数据库再根据业务规则通知 MES 或调度系统触发下一批物料搬送或者生成完成记录。如果工艺本身失败设备通常还会同时发一条报警S5F1。EAP 不能孤立处理报警要把报警和前后事件关联起来结合上下文判断现场应该进入“自动恢复流程”还是“停线等待人工介入”。这就是事件链的意义所在。5.3 断线重连后最容易踩的坑EAP 编写时很多同学只在启动的时候做一次订阅就完事了。设备断线重连后如果设备的 Link 关系是易失的那么所有订阅都会失效。典型现象是网络恢复了心跳也正常但不管发生什么操作主机都收不到任何 S6F11。排查半天链路最后发现只是订阅关系没了。解决办法是在连接建立成功的回调里重新执行完整的订阅流程先 S2F33 定义必要的 Report再 S2F35 重新 Link 需要的事件。重连后的日志里我会专门输出一句“当前已订阅 CEID 列表”方便确认状态。这个小习惯在多次现场抢救中帮我省了不少时间。6. 常见问题与排查技巧实录事件调试速查表问题现象排查方向处理方式主机永远收不到某个 CEID 事件事件是否已 LinkCEID 是否处于 Enabled重发 S2F35确认订阅表中的 Link 状态S6F12 回非 0HCACK 非 0 说明设备不认该 CEID/RPTID核对 CEID 和 RPTID 是否定义无误重新 S2F33事件偶发丢失检查 Ack 延时、HSMS 窗口是否过小增大通信窗口确认 Ack 处理足够快事件重复上报大概率是 Ack 超时导致的设备重发在 EAP 侧加幂等不要试图完全消除重发事件延迟大消息量大、处理串行阻塞将大块数据改用 S6F13/S6F15Ack 与业务异步化某个事件上报异常高频传感器抖动、设备去抖不充分设备侧去抖EAP 侧限频合并断线重连后事件全部消失订阅关系是易失的断线后失效在重连回调里重新执行订阅流程事件数据解析出来全乱码数据类型或字节序不对对照 SECS 手册确认 VID 类型用模拟器比对原始帧我自己调试事件相关问题时还有个习惯先搭一个纯软件环境用事件模拟器把设备的 S6F11 报文灌给 EAP或者用抓包工具先把真实设备的事件报文完整采集下来再慢慢解析。这个“离线赛道”能帮你把解析逻辑、幂等逻辑、状态机逻辑都调到稳定再上真机联调能省下大量现场时间。上真机之后我也不会一次性把设备的所有事件全订阅下来而是挑三个核心事件先跑通全链路设备 Ready、Process Start、Process Complete。这三个事件能跑通说明订阅流程、解析流程、Ack 流程、状态机更新流程都没问题再逐步放开其他事件。这样即使出了问题排查范围也被控制得很小。事件这个主题还有不少可以深挖的地方比如报警体系和状态变量的分工配合以及大数据量数据集在 GEM300 产线上的落地技巧我放到后面的篇幅里慢慢聊。
阅读完成 · 觉得有帮助？
