SECS/GEM接口方案设计：状态模型、能力声明与消息子集实现

简介这份PDF文档面向半导体设备自动化领域的工程师与集成开发人员系统梳理SECS/GEMSEMI设备通信标准/通用设备模型规范及广州金南瓜科技的落地实施方案帮助读者理解设备与主机系统之间的通信机制与互操作要求。内容涵盖通讯状态模型、控制状态模型与设备处理状态以及主机发起场景、事件通知、在线识别、动态事件报告配置、变量与跟踪数据采集、报警管理、远程控制、设备常数、过程程序管理等设备能力条目并附TCP/IP通讯超时、事件与变量实现等章节目录结构完整便于按模块查阅与对照实施。资源包共1个PDF文件约1006KB轻量易读。目前已有741人学习下载适合需要快速掌握SECS/GEM规范要点、推进设备联网与产线自动化改造的技术人员参考。1. 从一台“哑设备”说起SECS/GEM 接口方案要解决什么产线上有一台半导体加工设备本地跑得好好的一接厂务主机就出问题主机不知道它现在是在线还是离线采不到温度、压力这些变量报警只能靠人喊配方还得工程师拿 U 盘拷。这类“哑设备”在自动化改造里非常典型问题不在设备本身而在设备与主机之间缺一套标准语言。SECS/GEM 就是这套语言SECS-II 定义消息内容GEM 定义通用行为模型HSMS 负责在 TCP/IP 上跑消息。这份方案要交付的就是一台设备如何按 SEMI E5、E30、E37、E37.1 把接口做出来、验过去适合正在做设备联网课设、产线自动化毕设或要给客户交一份主机通信手册的工程师参考。2. 总体设计状态模型、能力清单与消息子集三件套做 SECS/GEM 接口最怕一上来就写消息收发代码。我一般先把三件事定死状态模型怎么走、GEM 能力声明勾哪些、SECS-II 消息子集实现到哪一层。这三件定不下来后面每加一个功能都要返工。方案里把状态模型放在第 2 章、能力实施放在第 3 章、消息类型放在第 6 章顺序是对的——先有行为骨架再填能力血肉最后才是报文格式。2.1 通信状态模型DISABLED / ENABLED 与两个连接子状态通信状态模型决定链路什么时候算“通”。顶层只有两个状态DISABLED 和 ENABLED。DISABLED 下 SECS-II 通信完全停止操作员从 ENABLED 切过去时所有通信立即中断ENABLED 是系统默认值它下面再分 COMMUNICATING 和 NOT COMMUNICATING 两个子状态。只要通信被使能——不管是系统初始化还是操作员切换——先进入的都是 NOT COMMUNICATING直到正式建立连接才转 COMMUNICATING。NOT COMMUNICATING 里还有两个 AND 子状态HOST-INITIATED CONNECT 和 EQUIPMENT-INITIATED CONNECT设备不通信时两者同时有效。设备主动连接走 WAIT CRA / WAIT DELAY 循环进入时把 CommDelay 定时器置为“过期”发 S1F13 等 S1F14连接事务失败就初始化 CommDelay 定时器、清空发送队列必要时按生成顺序转入 spool 缓冲等定时器到期再发。收到 COMMACK0 的 S1F14 才算建立通信。主机主动连接则停在 WAIT CR FROM HOST收到 S1F13 后回 S1F14、COMMACK0直接进 COMMUNICATING。状态迁移表里有一条容易被忽略在 WAIT DELAY 收到非 S1F13 的消息要丢弃、不回复、把定时器置过期、重发 S1F13。很多实现在这里回了 Sx,F0结果主机侧状态机跟着乱。相关数据项只有一个 ECID——EstablishCommunicationsTimeout建立通信超时这个值要和主机侧对齐否则两边一个在等、一个已放弃。2.2 控制状态模型OFF-LINE 下只认 S1F13 和 S1F17控制状态模型定义主机与设备的协作级别。OFF-LINE 时设备对主机发来的任何 primary 消息都回 Sx,F0唯独 S1F13 和 S1F17 例外——这两个要正常处理和响应S1F17 就是主机用来请求设备切到 ON-LINE 的。这条规则是控制状态机的“黑匣子”级细节离线不等于失联离线只是拒绝业务消息握手和上线请求必须放行。设备处理状态Equipment Processing States在方案里单独成节通常的做法是把它和 GEM 的 Control State 分开建模控制状态管“主机能不能指挥设备”处理状态管“设备自己在干什么”。两者混在一张图里答辩时被问一句“离线时设备还能不能跑片”就容易卡住。2.3 GEM 能力声明哪些勾 Yes哪些必须诚实勾 No方案第 1.4 节是一张 GEM Compliance Statement 勾选表基本要求里 State Models、Equipment Processing States、Host Initiated S1F13/F14、Event Notification、On-Line Identification、Error Messages、Documentation、ControlOperator Initiated全部勾 Yes。附加能力里 Establish Communications、Dynamic Event Report Configuration、变量与事件名列表请求、Variable/Trace/Status Data Collection、Alarm Management、Remote Control、Equipment Constants、Process Program Management、Equipment Terminal Services、Clock、Limits Monitoring、ControlEquipment-Initiated也都是 YesMaterial Movement 和 Spooling 明确勾 No。这张表不是形式主义。勾了 Yes 就意味着主机可以按 GEM 标准去调勾 No 的功能主机侧要另做兜底。Spooling 勾 No 的直接后果是通信中断期间产生的消息不缓存恢复后主机拿不到断档数据验收时要提前和主机方说清楚。我一般会把这张表当成合同附件来对待而不是文档里的一页装饰。2.4 消息子集与 SML先定字典再定报文第 6 章把 SECS-II 消息子集、SML 语言、消息格式、Data Item Dictionary 和 Data Format 分开写这个结构值得照搬。Data Item Dictionary 是“变量字典”每个数据项的类型、长度、含义在这里定死Data Format 是“报文模板”每个消息的 Structure 长什么样在这里定死。两者分开的好处是加一个采集变量只改字典不动报文模板。SML 是 SECS 消息的文本表示调试时比十六进制好读得多。下面是一段典型的 S1F13 建立通信请求的 SML 写法以及对应的处理逻辑示意# S1F13 建立通信请求的 SML 表示设备侧发送 # S1F13 W # L [2] # A [6] EQUIP1 # MDLN 设备型号 # A [8] VER1.0.0 # SOFTREV 软件版本 # def handle_s1f13(msg, session): 收到主机 S1F13回 S1F14COMMACK0 表示接受 mdln msg.get(0) # 设备型号来自 Data Item Dictionary softrev msg.get(1) # 软件版本 session.log(fhost handshake: {mdln}/{softrev}) # S1F14 结构L[2] B COMMACK L[2] A MDLN A SOFTREV return build_s1f14(commack0, mdlnsession.mdln, softrevsession.softrev)这段代码的关键不在函数本身而在两个约定COMMACK0 才代表接受非 0 是拒绝码S1F14 里要回带自己的 MDLN 和 SOFTREV主机侧据此做在线识别。参数上MDLN 和 SOFTREV 必须和 1.4 节能力声明、设备铭牌一致改版本号时三处同步否则主机日志里会出现“版本对不上”的玄学问题。3. 设备能力落地从事件报告到远程控制的实现路径能力清单勾完只是承诺第 3 章和第 5 章才是兑现。方案把主机发起场景、事件通知、在线识别、动态事件报告配置、变量/跟踪/状态数据采集、报警管理、远程控制、设备常数、过程程序管理、时钟、终端服务逐项列出第 5 章再给出实际实现的事件、变量、状态变量、报警、常量和主机命令。这个“能力—实现”两段式结构正好对应开发时的两张表能力表回答“支持什么”实现表回答“具体编号是多少”。3.1 动态事件报告配置S2F33 / S2F35 / S2F37 三件套GEM 的数据采集不是设备主动乱推而是主机先配置、设备再上报。配置链路是三段S2F33 定义报告Report ID 对应哪些 VIDS2F35 把报告挂到采集事件CEID上S2F37 使能或禁用事件。设备侧要维护三张映射表Report→VID 列表、CEID→Report 列表、CEID 使能标志。# 设备侧动态事件报告配置的核心数据结构 reports {} # report_id - [vid, ...] event_links {} # ceid - [report_id, ...] event_enabled {} # ceid - bool def s2f33_define_report(msg): S2F33定义/重定义报告DATAID0 表示全部重建 data_id msg.get(0) if data_id 0: reports.clear() for item in msg.get(1): # L[2] U4 RPTID L[n] VID rptid, vids item.get(0), item.get(1) reports[rptid] list(vids) return ack(0) # ACKC60 接受 def s2f35_link_event(msg): S2F35把报告链接到采集事件 for item in msg.get(1): # L[2] U4 CEID L[n] RPTID ceid, rptids item.get(0), item.get(1) event_links[ceid] list(rptids) return ack(0) def s2f37_enable_event(msg): S2F37CEED0 全部使能/禁用否则按 CEID 列表 ceed, ceids msg.get(0), msg.get(1) if ceed 0: for ceid in event_enabled: event_enabled[ceid] bool(msg.get(2)) else: for ceid in ceids: event_enabled[ceid] bool(msg.get(2)) return ack(0)三个函数的 ACKC6 返回码要按 SEMI 约定给0 接受1 至少一个常量不存在2 忙3 至少一个常量超出范围。踩坑最多的是 S2F33 的 DATAID 语义——DATAID0 是“清空重建”非 0 是“增量修改”实现时如果一律清空主机分两次下发的报告会互相覆盖表现为“配了 A 报告B 报告就没了”。3.2 变量、跟踪与状态数据采集三条采集通道别混用Variable Data Collection 是事件触发上报Trace Data Collection 是按固定周期采样S2F23 设采样周期、总数、TIDS6F1 回传Status Data Collection 是主机随时点名要状态值S1F3/S1F4。三条通道的数据源可以重叠但触发机制完全不同。常见的翻车是把 Trace 做成事件触发主机按周期等 S6F1 等不到最后靠超时重试掩盖问题。实现上我给每条通道单独一个采集器事件采集器挂在 CEID 触发点上Trace 采集器用独立定时线程按 S2F23 的 SMPRT 周期采样、按 TOTSMP 控制总数状态采集器只读当前快照。VID 编号在 Data Item Dictionary 里统一分配三条通道共用同一份字典避免同一个物理量出现两个编号。3.3 报警管理与远程控制S5F1 与 S2F41 的边界报警管理走 S5F1 上报ALCD 报警码、ALID 报警 ID、ALTX 报警文本主机用 S5F3 使能/禁用S5F5 查询报警列表。ALCD 的最高位表示报警是“发生”还是“解除”这个位搞反主机侧会看到报警永远不消。远程控制走 S2F41RCMD 命令名 CP 参数列表设备回 S2F42 带 HCACK0 接受、1 命令不存在、2 现在不能执行、3 参数无效、4 命令已启动但完成结果稍后报。边界在于远程控制只做“主机允许的动作”设备内部安全联锁不能因为 S2F41 就被绕过。我一般会在 RCMD 分发表前面加一层权限和状态检查OFF-LINE 或设备处理状态不允许时直接回 HCACK2而不是先执行再报错。3.4 设备常数、过程程序与时钟三个“低频但必考”的模块设备常数EC走 S2F15 设置、S2F13 查询、S2F11 要名列表ECID 和值类型在字典里定死设置时要做范围校验越界回 S2F16 的 EAC。过程程序管理走 S7 系列S7F1/S7F2 是上传下载的授权握手S7F3/S7F4 下载S7F5/S7F6 上传S7F17/S7F18 删除S7F19/S7F20 要目录。时钟走 S2F17 要时间、S2F31 设置时间格式是 A[12] 的 “YYYYMMDDhhmmss”。终端服务走 S10F3 往设备显示屏推文本S10F5 是多行。这三个模块平时用得少但验收时主机方一定会点一遍因为它们是 GEM 合规声明的必查项。过程程序管理的 PPID 命名规则要和主机约定我见过因为 PPID 大小写不一致导致 S7F19 目录对不上、下载一直失败的案例。4. 通信协议与场景验证HSMS 超时、SML 调试与场景脚本第 4 章只讲 TCP/IP 通信超时篇幅不大但很关键第 7 章把建立通信、动态报告配置、名列表请求、报警、远程控制、设备常数、过程程序、终端服务、时钟、控制这十类场景逐一给出交互序列。场景章的价值在于它把前面所有能力串成可执行的验收用例。4.1 HSMS 连接与 T3/T5/T6/T7/T8 定时器HSMS 跑在 TCP/IP 上单会话模式HSMS-SS下设备作为实体、主机作为会话方或者反过来。连接建立后先发 Select.req收到 Select.rsp 才进入数据收发。定时器是这套协议里最容易被忽略的部分T3 是回复超时发 primary 后等 secondaryT5 是连接分离超时T6 是控制事务超时T7 是 NOT SELECTED 状态超时T8 是网络字符间超时。方案里只给了 EstablishCommunicationsTimeout 一个 ECID实际实现时 T3/T5/T6/T7/T8 通常做成可配置项默认值按 SEMI E37 取。# 用 SML 文件做一次手工联调的典型流程示意 # 1. 设备侧监听端口等待主机 Select # 2. 主机发 S1F13设备回 S1F14 COMMACK0 # 3. 主机发 S1F1 Are You There设备回 S1F2 # 4. 主机发 S2F33 定义报告设备回 S2F34 ACKC60 # 5. 主机发 S2F37 使能事件触发后设备主动发 S6F11联调时我习惯先只跑第 2、3 步确认链路和握手没问题再往上叠报告配置。一上来就配报告出错时分不清是链路问题还是配置问题排查成本翻倍。4.2 名列表请求与控制场景S1F11/S1F21 与 ON-LINE 切换Data Variable Namelist RequestS1F11/S1F12和 Collection Event Namelist RequestS1F21/S1F22是主机“摸底”的手段设备要返回 VID/CEID 的名称列表。这两个消息的返回结构是三层列表实现时注意长度字段和实际条目数一致多一个少一个主机侧解析就崩。控制场景里主机 S1F17 请求 ON-LINE设备回 S1F18 的 ONLACK0 接受、1 不接受、2 已在线。OFF-LINE 下除 S1F13/S1F17 外一律回 Sx,F0 的规则在这里被反复验证。4.3 场景脚本化把第 7 章变成可回归的用例集第 7 章每个场景都可以写成一条脚本用例前置状态、发送消息、期望回复、期望状态迁移。我一般用一张表管理跑完一轮就知道哪些能力真的通了。场景触发消息期望回复关键校验点建立通信设备发起S1F13S1F14 COMMACK0状态进 COMMUNICATING建立通信主机发起S1F13S1F14 COMMACK0WAIT CR FROM HOST 退出定义报告S2F33S2F34 ACKC60DATAID0 时旧报告清空链接事件S2F35S2F36 ACKC60CEID 与 RPTID 映射正确使能事件S2F37S2F38 ACKC60触发后收到 S6F11报警上报设备侧 S5F1主机 S5F2ALCD 发生/解除位正确远程命令S2F41S2F42 HCACK0非法状态回 HCACK2设时钟S2F31S2F32 TIACK0格式 A[12]这张表既是开发自测清单也是答辩时演示的脚本顺序。先握手、再配置、再采集、最后控制顺序乱了演示效果会打折。5. 避坑与排查五条最容易翻车的点5.1 现象主机显示已连接但一条数据都收不到原因通常是只完成了 TCP 连接或 HSMS Select没走 S1F13/S1F14 握手通信状态还停在 NOT COMMUNICATING。解决在状态机上强制要求 COMMACK0 的 S1F14 才置 COMMUNICATING日志里把每次状态迁移打出来别只看 socket 是否 alive。5.2 现象报告配了事件也触发了S6F11 就是不发先查 S2F37 的使能标志——很多实现把“定义报告”当成“使能事件”漏了使能这一步。再查 CEID 是否真的挂在触发点上最后查 S6F11 里的 DATAID 和 CEID 顺序是否符合字典。解决配置完成后主动回读一次使能状态和主机侧对账。5.3 现象报警解除后主机侧报警不消失ALCD 的 bit7 是“发生/解除”标志置 1 表示报警发生置 0 表示解除ALID 保持不变。实现时如果解除也发一个新 ALID主机侧会当成两条不同报警。解决报警状态表以 ALID 为主键发生和解除共用同一 ALID只翻转 ALCD 标志位。5.4 现象Trace 采集周期忽快忽慢主机侧时间戳对不上S2F23 里的 SMPRT 是采样周期单位通常为百分之一秒TOTSMP 是总采样数。用事件触发或主循环顺带采样都会漂。解决独立定时器按 SMPRT 触发S6F1 里带 TID 和样本序号主机侧按序号重组丢样本时能看出来。5.5 现象OFF-LINE 时主机发什么都被拒连上线请求也失败控制状态模型规定 OFF-LINE 下只放行 S1F13 和 S1F17其余回 Sx,F0。如果实现时把 S1F17 也拦了主机永远上不了线。解决在消息分发入口先判控制状态白名单只放这两条其余统一回 Sx,F0并在日志里记录被拒消息的 Stream/Function。6. 验收与答辩用合规声明表和场景脚本收口验收这件事我一般分两步走先对表再跑脚本。对表就是拿 1.4 节的 GEM Compliance Statement 逐项核对勾 Yes 的每一项都要能指出对应的实现位置和验证用例勾 No 的Material Movement、Spooling要能说清楚主机侧怎么兜底。这张表是答辩时最硬的证据评委问“你凭什么说支持报警管理”直接翻到 S5F1/S5F2/S5F3/S5F5 的实现和用例比讲十分钟原理管用。跑脚本就是第 4.3 节那张场景表按“握手—配置—采集—控制”的顺序走一遍。演示时有个技巧先故意制造一次失败比如在 OFF-LINE 下发 S2F41让设备回 HCACK2再切 ON-LINE 重发成功。这一下就把控制状态模型的边界讲清楚了比平铺直叙地念功能列表有说服力。时间允许的话再演示一次通信中断后重连拔掉链路观察状态机从 COMMUNICATING 退回 NOT COMMUNICATING、发送队列清空恢复后重新 S1F13 握手。Spooling 勾了 No 的话这里正好说明断档数据不补发主机侧要靠轮询状态变量补齐。答辩材料我建议控制在三样一张状态迁移图通信 控制、一张能力声明勾选表、一份场景用例执行记录。文档里那些“错误!未定义书签”的目录项交付前一定要清掉——我见过因为目录页码全是错误提示被质疑文档没做完的。参数类问题提前准备好答案EstablishCommunicationsTimeout 设多少、T3 默认几秒、SMPRT 单位是什么、ALCD 哪一位是解除这些都是一问就能分出有没有真做过的问题。血泪经验是我第一次交这类接口文档时把能力声明表当成附录放在最后结果评审全程在翻附录正文反而没人看。从那以后我每次做 SECS/GEM 方案都把合规声明表和场景用例表放在验收章最前面让评审顺着表往下查而不是在文档里找。希望帮到你。本文还有配套的精品资源点击获取