简介这份PDF文档面向半导体设备自动化领域的工程师与集成人员系统讲解SECS/GEM设备接口协议及其落地实现帮助读者理解设备与主机系统之间的标准化通信机制。内容以广州金南瓜科技的SECS/GEM方案为主线涵盖通讯状态模型、控制状态模型与设备处理状态并逐项展开主机发起场景、事件通知、在线识别、动态事件报告配置、变量与跟踪数据采集、报警管理、远程控制、设备常数及过程程序管理等设备能力同时涉及TCP/IP通讯超时等协议细节目录结构完整便于按模块查阅与对照实施。资源包共1个PDF文件约1006KB轻量便携适合随时翻阅。目前已有741人学习下载可作为半导体产线自动化改造、设备联网调试与协议学习的实用参考。1. 一份能直接对着写代码的 SECS/GEM 规格书到底长什么样手上拿到一份设备通信规格书翻两页发现全是「错误!未定义书签。」这种场面做过半导体设备对接的人大概都不陌生。这次拆的是一份 SECS/GEM 规格说明书来自某半导体解决方案厂商 2020 年的版本正文覆盖通讯状态模型、控制状态模型、GEM 能力清单、SECS-II 消息子集、SML 语法以及十几组典型交互场景。它不是协议科普而是一份「主机侧程序员拿着就能对着写消息解析」的实施文档。适合三类人正在给设备加 GEM 接口的嵌入式工程师、要写 Host 端 EAP/MES 对接层的上位机开发者、以及需要判断某台设备 GEM 合规性到什么程度的产线自动化从业者。下面按「文档怎么读 → 状态机怎么落 → 消息怎么发 → 坑在哪」的顺序拆。2. 先读状态模型通讯与控制两张图决定了你 80% 的异常处理逻辑很多人拿到 SECS/GEM 文档直接翻到消息格式那一章结果联调时设备一直回 S9F5 或者干脆不回又回头找原因。血泪经验是先把两张状态模型图吃透后面所有超时、重连、Sx,F0 的处理都能对上号。这份文档用的是 Harel 记法画状态图读法和普通状态机略有区别先把这个门槛过了。2.1 通讯状态模型DISABLED / ENABLED 与四个子状态文档把通讯状态拆成两层。顶层是 DISABLED 和 ENABLEDDISABLED 下 SECS-II 通信完全停止操作员从 ENABLED 切到 DISABLED 时所有通信立即中断。ENABLED 下分 COMMUNICATING 和 NOT COMMUNICATING 两个子状态而 NOT COMMUNICATING 又用 AND 关系同时挂着 HOST-INITIATED CONNECT 和 EQUIPMENT-INITIATED CONNECT 两条并行分支——这是 Harel 记法里容易看漏的地方AND 状态意味着两条建链路径同时处于活动状态谁先成功谁生效。设备主动建链走 EQUIPMENT-INITIATED CONNECT内部再分 WAIT CRA 和 WAIT DELAY。进入 NOT COMMUNICATING 时先到 WAIT CRA把 CommDelay 定时器置为「已过期」立刻发 S1,F13 等 S1,F14。如果连接事务失败进 WAIT DELAY初始化 CommDelay 定时器把发送队列里的消息全部出队必要时按生成顺序放进 spool 缓冲等定时器到期再回 WAIT CRA 重发 S1,F13。主机主动建链走 HOST-INITIATED CONNECT子状态 WAIT CR FROM HOST就是干等主机发 S1,F13收到后回 S1,F14 且 COMMACK0进入 COMMUNICATING。这张图落到代码里核心就是一个定时器加一个发送队列。下面是我一般会写的建链重试骨架语言用 Python逻辑和文档的状态迁移表一一对应import time COMM_DELAY 10 # CommDelay 秒数对应 ECID 建立通讯超时 MAX_RETRY 0 # 0 表示无限重试产线设备通常不设上限 class CommStateMachine: def __init__(self, send_s1f13, on_established): self.state WAIT_CRA self.send_s1f13 send_s1f13 # 发 S1,F13 的底层函数 self.on_established on_established self.timer_start time.time() self.retry 0 def on_s1f14(self, commack): # 迁移 9收到 S1,F14 且 COMMACK0 才算建链成功 if commack 0: self.state COMMUNICATING self.on_established() else: self._to_wait_delay() # COMMACK 非 0 视为事务失败 def on_other_message(self): # 迁移 8WAIT_DELAY 期间收到非 S1,F13 的消息丢弃不回立即重发 if self.state WAIT_DELAY: self.timer_start time.time() - COMM_DELAY self._to_wait_cra() def tick(self): if self.state WAIT_DELAY and time.time() - self.timer_start COMM_DELAY: self._to_wait_cra() def _to_wait_cra(self): self.state WAIT_CRA self.send_s1f13() # 迁移 5/7发 S1,F13 等 S1,F14 def _to_wait_delay(self): self.state WAIT_DELAY self.timer_start time.time() self.retry 1 # 迁移 6出队所有待发消息按生成顺序进 spool 缓冲 self._flush_queue_to_spool()参数上最要紧的是 CommDelay文档在「相关数据」里把它对应到 ECID 的 EstablishCommunicationsTimeout。这个值设太小网络抖动时设备疯狂重发 S1,F13主机侧日志被刷满设太大断链后恢复慢产线会报通信超时。常见做法是 10 到 30 秒之间具体看主机侧 EAP 的容忍窗口。另外注意迁移 8 的细节WAIT DELAY 期间收到任何非 S1,F13 的消息文档要求「丢弃、不回复、定时器置过期、立即发 S1,F13」这个「不回」很关键回了反而会让主机误判链路已通。2.2 控制状态模型OFF-LINE 下为什么还要回 S1,F13 和 S1,F17控制状态模型定义主机和设备之间的协作级别。文档写得很明确OFF-LINE 状态下设备对主机发来的任何 primary message 都回 Sx,F0表示该消息不被接受但 S1,F13 和 S1,F17 例外设备会正常处理和响应。S1,F17 是主机用来请求设备切到 ON-LINE 的消息。这条规则踩过坑的人不少。有次联调设备明明上电了主机发 S1,F1 要在线识别设备一直回 S1,F0查了半天以为是消息格式错最后发现设备停在 OFF-LINE而 S1,F1 不在豁免列表里。所以主机侧的状态机要单独维护一个「设备是否 ON-LINE」的标志在发任何业务消息前先确认或者干脆先发 S1,F17 把设备拉上线。控制状态迁移里还有一条容易忽略设备从 ON-LINE 切回 OFF-LINE 有两种触发操作员本地切换或者主机发 S1,F15Request OFF-LINE。后者设备要回 S1,F16 确认。如果你的 Host 端在换产品、换配方时依赖 S1,F15 让设备下线记得等 S1,F16 再继续别发完就走否则设备可能还在处理上一条消息状态就乱了。3. GEM 能力清单怎么用从合规声明反推你要实现哪些消息文档第 1.4 节的 GEM Adaptability 是一张勾选表基本 GEM 要求和附加能力逐项标了 Yes/No。这张表的价值不在于「看它支不支持」而在于它是你和设备厂商对齐范围的合同附件——主机侧要实现的每一条消息都应该能在这张表里找到对应的 Yes。3.1 基本要求与附加能力的边界基本 GEM 要求里全部勾了 Yes状态模型、设备处理状态、主机发起的 S1,F13/F14 场景、事件通知、在线识别、错误消息、文档、操作员发起的控制。附加能力里大部分也是 Yes但有两项明确是 NoMaterial Movement物料移动和 Spooling消息暂存。这两项 No 直接决定了你的实现策略。Material Movement 为 No意味着设备不通过 SECS 消息报告载具或晶圆的位置移动物料追踪得靠 MES 侧的其他手段补。Spooling 为 No 影响更大通讯状态模型迁移 6 里提到「出队的消息如适当应放入 spool 缓冲」但设备不支持 spooling断链期间产生的事件就真的丢了。所以主机侧不能假设「断链恢复后能补收事件」必须在 EAP 层做事件丢失告警或者要求设备在关键事件上做本地缓存再重发。这一点在选型阶段就要问清楚别等上线了发现数据有洞。3.2 用能力表反查消息子集文档第 6 章给了 SECS-II 消息子集第 5 章列了实现的事件、变量、报警、常量和主机命令。正确的读法是拿 1.4 的表当索引表里 Event Notification 是 Yes就去第 5.1 节看实现了哪些 collection eventVariable Data Collection 是 Yes就去 5.2 节看 data variable 清单Alarm Management 是 Yes就去 5.4 节对报警号。这样读不会漏也不会把文档里没实现的功能当成有。举个具体例子动态事件报告配置Dynamic Event Report Configuration勾了 Yes对应消息是 S2,F33Define Report和 S2,F35Link Event Report。主机侧的标准流程是先 S1,F3 或 S1,F11 拿事件和变量名单再 S2,F33 定义报告再 S2,F35 把事件和报告关联最后 S2,F37 开事件报告。这四步的顺序不能乱S2,F35 引用的报告 ID 必须是 S2,F33 已经定义过的否则设备回 S2,F34 带错误码。我一般会在 Host 端把「已定义报告 ID 集合」做成内存状态每次 S2,F33 成功后更新S2,F35 前校验能省掉大量来回排查。4. 消息格式与 SML把文档里的 Data Item Dictionary 变成解析代码第 6 章是整份文档最「可抄」的部分6.1 是 SECS-II 消息子集6.2 讲 SML 语言6.2.1 是 Data Item Dictionary6.2.2 是 Data Format。SML 是 SECS Message Language 的缩写用文本形式描述一条 SECS-II 消息的结构调试时比看十六进制报文直观得多。4.1 SML 长什么样怎么用它对照报文一条典型的 S1,F13 在 SML 里大概是这样S1F13 W L [2] A [6] EQUIP1 A [4] 1.00 .S1F13是消息名W 表示需要回复Wait bit 置位L [2]是长度为 2 的列表A [6]是长度 6 的 ASCII 字符串。设备回 S1,F14 时结构类似只是内容换成 COMMACK 等。联调时我习惯让设备侧或抓包工具把报文转成 SML 打印和文档 6.2.2 的 Data Format 逐项对比对着裸 hex 猜快十倍。Data Item Dictionary 里定义了每种数据项的类型码和长度规则常见的有 L列表、AASCII、B二进制、BOOLEAN、U1/U2/U4无符号整数、I1/I2/I4有符号整数、F4/F8浮点。解析代码的核心就是按类型码递归下降。下面是一个最小可用的 SML 解析骨架只处理 L 和 A够你起步import re TOKEN re.compile(r([A-Z][0-9]?)\s*\[(\d)\]\s*(?:([^]*))?) def parse_sml(text): # 去掉消息头和结尾的 .只留 body body text.split(\n, 1)[1].rstrip(.\n ) pos 0 def parse_item(): nonlocal pos m TOKEN.match(body, pos) if not m: raise ValueError(f无法解析位置 {pos}: {body[pos:pos20]}) typ, length, val m.group(1), int(m.group(2)), m.group(3) pos m.end() if typ L: items [] for _ in range(length): items.append(parse_item()) return items if typ A: return val if val is not None else # 其他类型按需扩展U4 转 intB 转 bytes 等 return val return parse_item()逻辑说明TOKEN匹配类型 [长度] 值这种结构parse_item遇到 L 就按长度递归解析子项遇到 A 直接取值。参数上要注意两点一是长度字段对 L 表示子项个数、对 A 表示字符数别混用二是 SML 里字符串可能含转义实际解析前先确认设备侧用的是哪种转义约定文档 6.2.2 的 Data Format 会写。这个骨架跑通后把 U4、BOOLEAN 等类型补上就能覆盖文档 6.2.1 里大部分数据项。4.2 消息子集与场景章节的对应关系第 6.1 节的 SECS-II 消息子集列了设备支持的所有消息第 7 章 SECS Scenario 则按业务场景把这些消息串起来。读法建议是「以场景为纲、以子集为目」先看 7.1 建立通讯对应 S1,F13/F147.2 动态事件报告配置对应 S2,F33/F34/F35/F36/F37/F387.3 变量和事件名单请求对应 S1,F11/F12、S1,F3/F47.4 报警管理对应 S5,F3/F4、S5,F5/F67.5 远程控制对应 S2,F41/F427.6 设备常量对应 S2,F15/F16、S2,F13/F147.7 处理程序管理对应 S7 系列7.8 终端服务对应 S10,F37.9 时钟对应 S2,F17/F18、S2,F31/F327.10 控制对应 S1,F15/F16、S1,F17/F18。这张对应表建议直接抄进你的接口设计文档每个场景一节每节写清楚「主机发什么、设备回什么、失败回什么、超时怎么办」。文档第 7 章每个场景都给了消息流但没给超时值超时得按 SEMI E37 的 T3/T5/T6/T7/T8 定时器自己定常见做法是 T3 回复超时 45 秒、T5 连接分离超时 10 秒、T6 控制超时 5 秒、T7 未选中超时 10 秒、T8 网络字符超时 5 秒具体以主机侧 EAP 配置为准。5. 避坑与排查联调现场最常翻车的五个点5.1 现象设备一直回 S9F5主机侧日志显示消息格式错误原因通常是主机发的消息里数据项类型和文档 6.2.1 的 Data Item Dictionary 对不上比如文档要求 U4主机发了 A。SECS-II 对类型是强校验的类型错直接 S9F5Unrecognized Data Item。解决把文档 6.2.2 的 Data Format 逐条抄成主机侧的 schema 校验表发送前先本地校验类型和长度别等设备回错再查。5.2 现象S2,F35 之后事件报告没上来原因多半是 S2,F37 没发或者 S2,F35 引用的报告 ID 在 S2,F33 里没定义成功。文档 7.2 的场景里这三步是连着的但没强调依赖关系。解决Host 端维护报告 ID 状态机S2,F33 收到 S2,F34 且 ACKC60 才标记该 ID 可用S2,F35 前校验S2,F37 后再开一个「报告已使能」标志事件上来时先查这个标志。5.3 现象断链恢复后主机侧事件数据有缺口原因就是 1.4 节里 Spooling 勾了 No设备断链期间的事件不缓存。解决EAP 层对关键事件做丢失检测比如按事件序号或时间戳连续性判断发现缺口就触发补采用 S1,F3 或 S6,F11 主动读变量同时在设备选型阶段把 Spooling 列为加分项。5.4 现象设备停在 OFF-LINE主机发业务消息全回 Sx,F0原因见 2.2 节OFF-LINE 下只有 S1,F13 和 S1,F17 被处理。解决主机侧上线流程固定为「S1,F13 建链 → S1,F17 请求 ON-LINE → 等 S1,F18 确认 → 再发业务消息」中间任何一步失败都回退重来别跳步。5.5 现象CommDelay 到期后设备疯狂重发 S1,F13主机日志被刷爆原因是 CommDelay 设得太小或者主机侧对 S1,F13 的回复延迟超过了 CommDelay。解决CommDelay 按主机 EAP 的最坏回复延迟乘 2 到 3 倍来设同时主机侧收到 S1,F13 要尽快回 S1,F14别在回复前做耗时操作。另外检查是不是有多个设备实例共用同一个 CommDelay 配置产线设备多的时候容易串。6. 进阶用文档第 5 章的变量清单做一套自检脚本文档第 5 章列了实现的事件、数据变量、状态变量、报警、设备常量和主机命令这些清单不只是给人看的可以直接变成联调自检脚本的输入。我的习惯是把 5.1 到 5.6 的清单导成一张表每行一个条目字段包括类型事件/变量/报警/常量/命令、ID、名称、数据类型、是否已在主机侧实现。然后写一个脚本按表逐项发对应的请求消息比对设备返回值。比如变量清单用 S1,F11 请求 data variable namelist拿回来的列表和文档 5.2 的清单做集合比对多出来的说明设备固件版本比文档新少了的说明文档没更新或者设备没实现。报警清单用 S5,F3 请求比对报警号和文档 5.4。设备常量用 S2,F13 请求 namelist比对 5.5。主机命令没法主动枚举就按 5.6 的清单逐条发 S2,F41看设备回 S2,F42 的 HCACK 是否为 0。这套脚本跑一遍基本能判断「设备实际实现」和「文档声明」的偏差有多大。偏差大的时候别急着改主机代码先找设备厂商确认是文档滞后还是固件没刷。我一般会把自检结果存成 CSV联调会议直接投屏比口头对清单高效得多。还有一个细节值得单独说文档里大量章节标题后面跟着「错误!未定义书签。」这是 Word 目录域没更新导致的不影响正文内容但说明这份文档在发布前没做最终排版检查。读的时候以正文标题为准别被目录页码带偏。另外文档 2.2 节里「设备处理状态」的页码也是未定义书签实际内容在 2.2 节正文里翻的时候直接看正文。从那以后我每次拿到这类规格书第一件事是把 1.4 的能力表和 5.x 的清单导成结构化表格第二件事是把 2.x 的状态迁移表逐条写成单元测试两件事做完再动手写业务代码返工率能降一大截。希望帮到你。本文还有配套的精品资源点击获取
简介这份PDF文档面向半导体设备自动化领域的工程师与集成人员系统讲解SECS/GEM设备接口协议及其落地实现帮助读者理解设备与主机系统之间的标准化通信机制。内容以广州金南瓜科技的SECS/GEM方案为主线涵盖通讯状态模型、控制状态模型与设备处理状态并逐项展开主机发起场景、事件通知、在线识别、动态事件报告配置、变量与跟踪数据采集、报警管理、远程控制、设备常数及过程程序管理等设备能力同时涉及TCP/IP通讯超时等协议细节目录结构完整便于按模块查阅与对照实施。资源包共1个PDF文件约1006KB轻量便携适合随时翻阅。目前已有741人学习下载可作为半导体产线自动化改造、设备联网调试与协议学习的实用参考。1. 一份能直接对着写代码的 SECS/GEM 规格书到底长什么样手上拿到一份设备通信规格书翻两页发现全是「错误!未定义书签。」这种场面做过半导体设备对接的人大概都不陌生。这次拆的是一份 SECS/GEM 规格说明书来自某半导体解决方案厂商 2020 年的版本正文覆盖通讯状态模型、控制状态模型、GEM 能力清单、SECS-II 消息子集、SML 语法以及十几组典型交互场景。它不是协议科普而是一份「主机侧程序员拿着就能对着写消息解析」的实施文档。适合三类人正在给设备加 GEM 接口的嵌入式工程师、要写 Host 端 EAP/MES 对接层的上位机开发者、以及需要判断某台设备 GEM 合规性到什么程度的产线自动化从业者。下面按「文档怎么读 → 状态机怎么落 → 消息怎么发 → 坑在哪」的顺序拆。2. 先读状态模型通讯与控制两张图决定了你 80% 的异常处理逻辑很多人拿到 SECS/GEM 文档直接翻到消息格式那一章结果联调时设备一直回 S9F5 或者干脆不回又回头找原因。血泪经验是先把两张状态模型图吃透后面所有超时、重连、Sx,F0 的处理都能对上号。这份文档用的是 Harel 记法画状态图读法和普通状态机略有区别先把这个门槛过了。2.1 通讯状态模型DISABLED / ENABLED 与四个子状态文档把通讯状态拆成两层。顶层是 DISABLED 和 ENABLEDDISABLED 下 SECS-II 通信完全停止操作员从 ENABLED 切到 DISABLED 时所有通信立即中断。ENABLED 下分 COMMUNICATING 和 NOT COMMUNICATING 两个子状态而 NOT COMMUNICATING 又用 AND 关系同时挂着 HOST-INITIATED CONNECT 和 EQUIPMENT-INITIATED CONNECT 两条并行分支——这是 Harel 记法里容易看漏的地方AND 状态意味着两条建链路径同时处于活动状态谁先成功谁生效。设备主动建链走 EQUIPMENT-INITIATED CONNECT内部再分 WAIT CRA 和 WAIT DELAY。进入 NOT COMMUNICATING 时先到 WAIT CRA把 CommDelay 定时器置为「已过期」立刻发 S1,F13 等 S1,F14。如果连接事务失败进 WAIT DELAY初始化 CommDelay 定时器把发送队列里的消息全部出队必要时按生成顺序放进 spool 缓冲等定时器到期再回 WAIT CRA 重发 S1,F13。主机主动建链走 HOST-INITIATED CONNECT子状态 WAIT CR FROM HOST就是干等主机发 S1,F13收到后回 S1,F14 且 COMMACK0进入 COMMUNICATING。这张图落到代码里核心就是一个定时器加一个发送队列。下面是我一般会写的建链重试骨架语言用 Python逻辑和文档的状态迁移表一一对应import time COMM_DELAY 10 # CommDelay 秒数对应 ECID 建立通讯超时 MAX_RETRY 0 # 0 表示无限重试产线设备通常不设上限 class CommStateMachine: def __init__(self, send_s1f13, on_established): self.state WAIT_CRA self.send_s1f13 send_s1f13 # 发 S1,F13 的底层函数 self.on_established on_established self.timer_start time.time() self.retry 0 def on_s1f14(self, commack): # 迁移 9收到 S1,F14 且 COMMACK0 才算建链成功 if commack 0: self.state COMMUNICATING self.on_established() else: self._to_wait_delay() # COMMACK 非 0 视为事务失败 def on_other_message(self): # 迁移 8WAIT_DELAY 期间收到非 S1,F13 的消息丢弃不回立即重发 if self.state WAIT_DELAY: self.timer_start time.time() - COMM_DELAY self._to_wait_cra() def tick(self): if self.state WAIT_DELAY and time.time() - self.timer_start COMM_DELAY: self._to_wait_cra() def _to_wait_cra(self): self.state WAIT_CRA self.send_s1f13() # 迁移 5/7发 S1,F13 等 S1,F14 def _to_wait_delay(self): self.state WAIT_DELAY self.timer_start time.time() self.retry 1 # 迁移 6出队所有待发消息按生成顺序进 spool 缓冲 self._flush_queue_to_spool()参数上最要紧的是 CommDelay文档在「相关数据」里把它对应到 ECID 的 EstablishCommunicationsTimeout。这个值设太小网络抖动时设备疯狂重发 S1,F13主机侧日志被刷满设太大断链后恢复慢产线会报通信超时。常见做法是 10 到 30 秒之间具体看主机侧 EAP 的容忍窗口。另外注意迁移 8 的细节WAIT DELAY 期间收到任何非 S1,F13 的消息文档要求「丢弃、不回复、定时器置过期、立即发 S1,F13」这个「不回」很关键回了反而会让主机误判链路已通。2.2 控制状态模型OFF-LINE 下为什么还要回 S1,F13 和 S1,F17控制状态模型定义主机和设备之间的协作级别。文档写得很明确OFF-LINE 状态下设备对主机发来的任何 primary message 都回 Sx,F0表示该消息不被接受但 S1,F13 和 S1,F17 例外设备会正常处理和响应。S1,F17 是主机用来请求设备切到 ON-LINE 的消息。这条规则踩过坑的人不少。有次联调设备明明上电了主机发 S1,F1 要在线识别设备一直回 S1,F0查了半天以为是消息格式错最后发现设备停在 OFF-LINE而 S1,F1 不在豁免列表里。所以主机侧的状态机要单独维护一个「设备是否 ON-LINE」的标志在发任何业务消息前先确认或者干脆先发 S1,F17 把设备拉上线。控制状态迁移里还有一条容易忽略设备从 ON-LINE 切回 OFF-LINE 有两种触发操作员本地切换或者主机发 S1,F15Request OFF-LINE。后者设备要回 S1,F16 确认。如果你的 Host 端在换产品、换配方时依赖 S1,F15 让设备下线记得等 S1,F16 再继续别发完就走否则设备可能还在处理上一条消息状态就乱了。3. GEM 能力清单怎么用从合规声明反推你要实现哪些消息文档第 1.4 节的 GEM Adaptability 是一张勾选表基本 GEM 要求和附加能力逐项标了 Yes/No。这张表的价值不在于「看它支不支持」而在于它是你和设备厂商对齐范围的合同附件——主机侧要实现的每一条消息都应该能在这张表里找到对应的 Yes。3.1 基本要求与附加能力的边界基本 GEM 要求里全部勾了 Yes状态模型、设备处理状态、主机发起的 S1,F13/F14 场景、事件通知、在线识别、错误消息、文档、操作员发起的控制。附加能力里大部分也是 Yes但有两项明确是 NoMaterial Movement物料移动和 Spooling消息暂存。这两项 No 直接决定了你的实现策略。Material Movement 为 No意味着设备不通过 SECS 消息报告载具或晶圆的位置移动物料追踪得靠 MES 侧的其他手段补。Spooling 为 No 影响更大通讯状态模型迁移 6 里提到「出队的消息如适当应放入 spool 缓冲」但设备不支持 spooling断链期间产生的事件就真的丢了。所以主机侧不能假设「断链恢复后能补收事件」必须在 EAP 层做事件丢失告警或者要求设备在关键事件上做本地缓存再重发。这一点在选型阶段就要问清楚别等上线了发现数据有洞。3.2 用能力表反查消息子集文档第 6 章给了 SECS-II 消息子集第 5 章列了实现的事件、变量、报警、常量和主机命令。正确的读法是拿 1.4 的表当索引表里 Event Notification 是 Yes就去第 5.1 节看实现了哪些 collection eventVariable Data Collection 是 Yes就去 5.2 节看 data variable 清单Alarm Management 是 Yes就去 5.4 节对报警号。这样读不会漏也不会把文档里没实现的功能当成有。举个具体例子动态事件报告配置Dynamic Event Report Configuration勾了 Yes对应消息是 S2,F33Define Report和 S2,F35Link Event Report。主机侧的标准流程是先 S1,F3 或 S1,F11 拿事件和变量名单再 S2,F33 定义报告再 S2,F35 把事件和报告关联最后 S2,F37 开事件报告。这四步的顺序不能乱S2,F35 引用的报告 ID 必须是 S2,F33 已经定义过的否则设备回 S2,F34 带错误码。我一般会在 Host 端把「已定义报告 ID 集合」做成内存状态每次 S2,F33 成功后更新S2,F35 前校验能省掉大量来回排查。4. 消息格式与 SML把文档里的 Data Item Dictionary 变成解析代码第 6 章是整份文档最「可抄」的部分6.1 是 SECS-II 消息子集6.2 讲 SML 语言6.2.1 是 Data Item Dictionary6.2.2 是 Data Format。SML 是 SECS Message Language 的缩写用文本形式描述一条 SECS-II 消息的结构调试时比看十六进制报文直观得多。4.1 SML 长什么样怎么用它对照报文一条典型的 S1,F13 在 SML 里大概是这样S1F13 W L [2] A [6] EQUIP1 A [4] 1.00 .S1F13是消息名W 表示需要回复Wait bit 置位L [2]是长度为 2 的列表A [6]是长度 6 的 ASCII 字符串。设备回 S1,F14 时结构类似只是内容换成 COMMACK 等。联调时我习惯让设备侧或抓包工具把报文转成 SML 打印和文档 6.2.2 的 Data Format 逐项对比对着裸 hex 猜快十倍。Data Item Dictionary 里定义了每种数据项的类型码和长度规则常见的有 L列表、AASCII、B二进制、BOOLEAN、U1/U2/U4无符号整数、I1/I2/I4有符号整数、F4/F8浮点。解析代码的核心就是按类型码递归下降。下面是一个最小可用的 SML 解析骨架只处理 L 和 A够你起步import re TOKEN re.compile(r([A-Z][0-9]?)\s*\[(\d)\]\s*(?:([^]*))?) def parse_sml(text): # 去掉消息头和结尾的 .只留 body body text.split(\n, 1)[1].rstrip(.\n ) pos 0 def parse_item(): nonlocal pos m TOKEN.match(body, pos) if not m: raise ValueError(f无法解析位置 {pos}: {body[pos:pos20]}) typ, length, val m.group(1), int(m.group(2)), m.group(3) pos m.end() if typ L: items [] for _ in range(length): items.append(parse_item()) return items if typ A: return val if val is not None else # 其他类型按需扩展U4 转 intB 转 bytes 等 return val return parse_item()逻辑说明TOKEN匹配类型 [长度] 值这种结构parse_item遇到 L 就按长度递归解析子项遇到 A 直接取值。参数上要注意两点一是长度字段对 L 表示子项个数、对 A 表示字符数别混用二是 SML 里字符串可能含转义实际解析前先确认设备侧用的是哪种转义约定文档 6.2.2 的 Data Format 会写。这个骨架跑通后把 U4、BOOLEAN 等类型补上就能覆盖文档 6.2.1 里大部分数据项。4.2 消息子集与场景章节的对应关系第 6.1 节的 SECS-II 消息子集列了设备支持的所有消息第 7 章 SECS Scenario 则按业务场景把这些消息串起来。读法建议是「以场景为纲、以子集为目」先看 7.1 建立通讯对应 S1,F13/F147.2 动态事件报告配置对应 S2,F33/F34/F35/F36/F37/F387.3 变量和事件名单请求对应 S1,F11/F12、S1,F3/F47.4 报警管理对应 S5,F3/F4、S5,F5/F67.5 远程控制对应 S2,F41/F427.6 设备常量对应 S2,F15/F16、S2,F13/F147.7 处理程序管理对应 S7 系列7.8 终端服务对应 S10,F37.9 时钟对应 S2,F17/F18、S2,F31/F327.10 控制对应 S1,F15/F16、S1,F17/F18。这张对应表建议直接抄进你的接口设计文档每个场景一节每节写清楚「主机发什么、设备回什么、失败回什么、超时怎么办」。文档第 7 章每个场景都给了消息流但没给超时值超时得按 SEMI E37 的 T3/T5/T6/T7/T8 定时器自己定常见做法是 T3 回复超时 45 秒、T5 连接分离超时 10 秒、T6 控制超时 5 秒、T7 未选中超时 10 秒、T8 网络字符超时 5 秒具体以主机侧 EAP 配置为准。5. 避坑与排查联调现场最常翻车的五个点5.1 现象设备一直回 S9F5主机侧日志显示消息格式错误原因通常是主机发的消息里数据项类型和文档 6.2.1 的 Data Item Dictionary 对不上比如文档要求 U4主机发了 A。SECS-II 对类型是强校验的类型错直接 S9F5Unrecognized Data Item。解决把文档 6.2.2 的 Data Format 逐条抄成主机侧的 schema 校验表发送前先本地校验类型和长度别等设备回错再查。5.2 现象S2,F35 之后事件报告没上来原因多半是 S2,F37 没发或者 S2,F35 引用的报告 ID 在 S2,F33 里没定义成功。文档 7.2 的场景里这三步是连着的但没强调依赖关系。解决Host 端维护报告 ID 状态机S2,F33 收到 S2,F34 且 ACKC60 才标记该 ID 可用S2,F35 前校验S2,F37 后再开一个「报告已使能」标志事件上来时先查这个标志。5.3 现象断链恢复后主机侧事件数据有缺口原因就是 1.4 节里 Spooling 勾了 No设备断链期间的事件不缓存。解决EAP 层对关键事件做丢失检测比如按事件序号或时间戳连续性判断发现缺口就触发补采用 S1,F3 或 S6,F11 主动读变量同时在设备选型阶段把 Spooling 列为加分项。5.4 现象设备停在 OFF-LINE主机发业务消息全回 Sx,F0原因见 2.2 节OFF-LINE 下只有 S1,F13 和 S1,F17 被处理。解决主机侧上线流程固定为「S1,F13 建链 → S1,F17 请求 ON-LINE → 等 S1,F18 确认 → 再发业务消息」中间任何一步失败都回退重来别跳步。5.5 现象CommDelay 到期后设备疯狂重发 S1,F13主机日志被刷爆原因是 CommDelay 设得太小或者主机侧对 S1,F13 的回复延迟超过了 CommDelay。解决CommDelay 按主机 EAP 的最坏回复延迟乘 2 到 3 倍来设同时主机侧收到 S1,F13 要尽快回 S1,F14别在回复前做耗时操作。另外检查是不是有多个设备实例共用同一个 CommDelay 配置产线设备多的时候容易串。6. 进阶用文档第 5 章的变量清单做一套自检脚本文档第 5 章列了实现的事件、数据变量、状态变量、报警、设备常量和主机命令这些清单不只是给人看的可以直接变成联调自检脚本的输入。我的习惯是把 5.1 到 5.6 的清单导成一张表每行一个条目字段包括类型事件/变量/报警/常量/命令、ID、名称、数据类型、是否已在主机侧实现。然后写一个脚本按表逐项发对应的请求消息比对设备返回值。比如变量清单用 S1,F11 请求 data variable namelist拿回来的列表和文档 5.2 的清单做集合比对多出来的说明设备固件版本比文档新少了的说明文档没更新或者设备没实现。报警清单用 S5,F3 请求比对报警号和文档 5.4。设备常量用 S2,F13 请求 namelist比对 5.5。主机命令没法主动枚举就按 5.6 的清单逐条发 S2,F41看设备回 S2,F42 的 HCACK 是否为 0。这套脚本跑一遍基本能判断「设备实际实现」和「文档声明」的偏差有多大。偏差大的时候别急着改主机代码先找设备厂商确认是文档滞后还是固件没刷。我一般会把自检结果存成 CSV联调会议直接投屏比口头对清单高效得多。还有一个细节值得单独说文档里大量章节标题后面跟着「错误!未定义书签。」这是 Word 目录域没更新导致的不影响正文内容但说明这份文档在发布前没做最终排版检查。读的时候以正文标题为准别被目录页码带偏。另外文档 2.2 节里「设备处理状态」的页码也是未定义书签实际内容在 2.2 节正文里翻的时候直接看正文。从那以后我每次拿到这类规格书第一件事是把 1.4 的能力表和 5.x 的清单导成结构化表格第二件事是把 2.x 的状态迁移表逐条写成单元测试两件事做完再动手写业务代码返工率能降一大截。希望帮到你。本文还有配套的精品资源点击获取
