企业官网建设流程全解析

简介：「SECS/GEM标准规范-金南瓜」面向半导体设备自动化领域的工程师、上位机开发人员与工艺集成学习者，聚焦设备与主机系统之间通信标准化这一核心问题，帮助读者理解不同厂商设备如何实现互操作与数据交换。内容以广州金南瓜科技的SECS-GEM规格说明书为主体，系统梳理通讯状态模型、控制状态模型与设备处理状态，并展开主机发起场景、事件通知、在线识别、动态事件报告配置、变量/跟踪/状态数据采集、报警管理、远程控制、设备常数、过程程序管理、时钟与终端服务等能力项，同时给出TCP/IP通讯超时及已实现事件、变量、报警的说明，便于对照落地。整包为1个PDF文件，约1006KB，轻量易读，适合通勤或工位快速查阅。已有746人学习，可作为自动化产线通信方案设计与设备接入的参考手册。

1. 设备进厂那天，主机端工程师问的第一句话

设备进厂那天，主机端工程师问的第一句话往往不是产能多少，而是「这台机的 S1F13 能不能回 COMMACK=0」。听着像黑话，实际上是在确认一件事：这台设备到底会不会说 SECS/GEM 这套普通话。很多人的第一反应是「加个网口、定时把数据推出去不就行了」，真做下去就会发现，自动化产线要的不是一堆数值，而是一套能被主机信任的对话规则：什么时候能连、谁能控制谁、事件按什么节奏报、断线以后怎么收场，这些都得落在规范里。

这份 SECS/GEM 规格说明书解决的正是这一段。它把 SEMI E5、E30、E37、E37.1 四份标准落成一台设备可交付的通信接口，覆盖通讯状态模型与控制状态模型、十二类设备能力清单、SECS-II 消息子集与数据项字典，以及建立通讯、事件报告配置、数据采集、报警、远程命令等一整套场景时序。做设备端接口固件的人、做主控与 MES 对接的人，还有要交一份完整设备通信方案毕设或课设的人，都能直接把它当作架构底稿。

2. 需求与技术选型：四份标准怎么落到一套软件模块上

2.1 先把四份标准的边界划清，报错时才知道该翻哪一本

接口出问题的时候，最常见的浪费是把三层的故障混在一起查：主机解析不了消息，就去怀疑网络；网络断线重连不上，就去改消息结构。规格说明书里列的四份标准其实各管一段，先把边界划清楚，排查效率差出好几倍。

E5 和 E30 的分工最容易被搞混。E5 管「话怎么说」：S6F11 的第一个数据项是 DATAID，第二个是 CEID，第三个是报告链表，结构错了主机直接抛解析异常。E30 管「什么时候该说话、说话算不算数」：设备在 OFF-LINE 状态下收到 S2F41，即使报文完全合法，也应该回 Sx,F0 而不是执行命令。很多自研接口栽在这一层——报文全对，行为全错。

2.2 传输层选型：新设备一律 HSMS-SS，串口只在改造老机时保留

传输层有两条路：老的 SECS-I 走 RS-232 串口，新的 HSMS 走 TCP/IP。规格说明书选择的是 HSMS，并且明确落在 E37.1 的单选定会话模式上，也就是设备端只服务一个主机会话，不做多会话仲裁。

这个选择在工程上几乎没有争议。串口方案的速率被压在 9600bps 这一档，一条带十几个变量的 S6F11 就要占掉几十毫秒，事件密集时排队排到超时；而且串口没有标准的连接概念，所谓「断线」只能靠字符间隔超时去猜。HSMS 走以太网，设备端做被动监听、主机主动连接，连接状态是显式的，断线重连的行为也能被状态机描述清楚。代价是多了一套定时器要维护，五个参数调错一个，现象就足够让人查一整天。

# hsms_config.py 设备端 HSMS-SS 连接参数 HSMS = { "mode": "passive", # 设备端被动监听，由主机发起连接 "port": 5000, # HSMS 约定的默认端口，双方必须一致 "device_id": 0, # 与主机约定的设备号，0 表示不校验 "session_id": 0, # HSMS-SS 下单选定会话固定为 0 "timers": { "T3": 45, # 回复超时，按最慢一条 S2F41 的执行时间来定 "T5": 10, # 重连间隔，产线网络建议不低于 5 秒 "T6": 5, # 控制事务超时，一般不需要改 "T7": 10, # 未选中超时，用于回收僵死连接 "T8": 5, # 字节间隔超时，跨交换机时适当放宽 }, }

参数里真正需要现场调的一般只有 T3 和 T5。T3 要按设备最慢的一条命令来定，比如某个回零动作要 30 秒，T3 还留 45 秒是合理的，压到 10 秒就会出现「命令执行成功但主机认为失败」的诡异局面。T5 则跟车间网络质量相关，重连打得太频繁会把交换机的日志刷爆，也不好定位真正的问题。

2.3 部署形态：工控机上的软件模块，不碰设备内部逻辑

规格说明书在第 1.3 节把硬件边界写得很干脆：SECS/GEM 接口模块运行在工控级电脑上，属于软件模块。这句话在答辩和评审时经常被追问，因为很多人默认「接口是设备固件的一部分」。

把它做成独立软件模块有三个实际好处。第一，接口的重启、升级不需要停设备主控，产线试产阶段这一点很关键。第二，接口只做两件事——把设备内部的状态和参数读出来、把主机的命令转成设备能懂的动作请求，它不参与任何实时控制回路，设备的安全联锁仍然由原控制器负责。第三，验收时可以单独对接口做压力测试，不影响生产。代价是多了一次进程间通信，实时性要求高的数据不能走这条路，只能走事件触发后的批量上报。

提示：接口模块与设备主控之间的数据通道，建议做成「只读快照 + 命令队列」两段，接口侧永远不直接写设备内存，避免接口进程崩溃时把设备状态带偏。

3. 总体架构设计：两层状态机撑起十二个能力模块

3.1 通讯状态模型：把十几条迁移写成可执行的分支

通讯状态模型描述的是链路层之上的「会话是否成立」。顶层两个状态：DISABLED 和 ENABLED。DISABLED 下所有 SECS-II 通信立即停止，操作员从 ENABLED 切过去的那一刻就生效。ENABLED 下面分 COMMUNICATING 和 NOT COMMUNICATING，而 NOT COMMUNICATING 里又并着两个子状态——设备发起连接和主机发起连接，两者同时活动，谁先成功算谁的。

设备发起连接这条路上，还有 WAIT CRA 和 WAIT DELAY 两个子状态。进入 NOT COMMUNICATING 时，CommDelay 定时器被置为「已过期」，于是立刻进 WAIT CRA，发一条 S1F13 出去等 S1F14；连不上就进 WAIT DELAY，把发送队列里的消息清空（必要时转存），等定时器到期再回 WAIT CRA 重发。这个「清队列」的动作是很多实现会漏掉的一步，漏了以后现象是断线重连成功，主机却收到一堆几十分钟前的过期事件。

from enum import Enum, auto class CommState(Enum): DISABLED = auto() WAIT_CRA = auto() # 设备发 S1F13 后等主机 S1F14 WAIT_DELAY = auto() # CommDelay 计时中 WAIT_CR_FROM_HOST = auto() # 等主机发 S1F13 COMMUNICATING = auto() def on_primary(state, stream, func, ctx): """返回 (新状态, 是否回复, 回复消息) ctx 持有 commack、comm_delay_expired 和待发队列""" if state is CommState.DISABLED: return state, False, None # 通信被关闭，任何消息都不处理 if state is CommState.WAIT_DELAY: if (stream, func) == (1, 13): return state, True, ("S1F14", 0) # 主机主动来了，直接建立 ctx.drop_all_pending() # 非 S1F13 一律丢弃且不回复 return CommState.WAIT_CRA, False, None if state is CommState.WAIT_CRA: if (stream, func) == (1, 14) and ctx.commack == 0: return CommState.COMMUNICATING, False, None return state, True, ("S1F0", 0) # 其他消息回中止 if state is CommState.COMMUNICATING: return state, False, None # 交给上层控制状态机处理

这段代码里有两个关键点。COMMACK 只认 0，非 0 表示主机拒绝，设备应当留在 WAIT CRA 或转入 WAIT DELAY，不能自作主张认为通了。另一处是 WAIT DELAY 收到 S1F13 时的处理——规格写的是「表示有建立通讯的机会」，所以要立刻回 S1F14 建立连接，而不是等定时器到期。

3.2 控制状态模型：OFF-LINE 时为什么只认 S1F13 和 S1F17

控制状态模型定义主机与设备之间的协作级别。设备在 OFF-LINE 状态下，对主机发来的任何 primary 消息都应回 Sx,F0，唯独 S1F13 和 S1F17 例外：前者是建立通讯，后者是主机请求设备切到 ON-LINE。原因很直白——如果连上线请求都被拒，主机就再也没有合法的办法把设备拉回线上了。

ON-LINE 之后还要再分 LOCAL 和 REMOTE。设备面板上被操作员切到本地模式时，主机下发的 S2F41 应回 HCACK=2（无法执行），而不是假装执行成功。这一点很多自研接口做成了「先收下再说」，结果主机侧看到命令已被接受、设备侧毫无动作，两边日志对不上，排查起来非常痛苦。

设备处于 OFF-LINE，主机发 S1F3 请求状态变量： S1F3 W <L[2] <U4 VID 1001> <U4 VID 1002> >. 设备回复： S1F0 <B ABORT 4>. // 4 = 实体不支持该消息，在 OFF-LINE 下统一用中止回

把 OFF-LINE 的应答策略做成一张白名单，比在业务代码里到处写 if 判断要稳得多：白名单里只有 (1,13)、(1,17)、(1,1) 三条，其余全部走中止分支，行为一致性有保障。

3.3 能力矩阵取舍：哪些打勾，哪些必须诚实地留空

规格说明书里有一份 GEM Compliance Statement，逐项勾选基础要求和附加能力。基础项全部打勾：状态模型、设备处理状态、主机发起 S1F13/F14 场景、事件通知、在线识别、错误消息、文档、操作员发起的控制。附加项里，其它几乎全打勾，只有两项明确留空——物料搬送和 Spooling。

留空这两项不是偷懒。物料搬送要求设备具备 Load Port 一类的搬运机构，能做到「主机指定把哪片料送到哪个腔」，而这类设备没有搬运执行机构，硬勾上去等于给自己挖坑，主机按标准来调接口的时候会直接调不通。Spooling 则是在断线期间把事件缓存到磁盘、恢复后补发，实现成本不低，而这条产线的设备断线时长通常很短，权衡之后放弃。代价要写在文档里：断线期间产生的事件丢失，验收时主机侧不能拿「断线后补报」来要求设备。

注意：能力清单是合同级别的承诺，勾了就代表主机可以按标准场景来验证。宁可少勾一条并写清原因，也不要在评审时被逐条追问。

4. 关键模块实现：事件报告、数据采集、报警与远程控制

4.1 动态事件报告配置：S2F33 到 S2F35 再到 S2F37，顺序不能反

GEM 里最核心的一段交互是「主机告诉设备，发生什么事的时候、把哪些变量的值报给我」。这件事被拆成三步，由三条消息完成，顺序错了后面全乱。

第一步 S2F33 定义报告：指定一个 RPTID，以及这个报告里包含哪些 VID，顺序即上报顺序。第二步 S2F35 把报告挂到事件上：指定一个 CEID，以及触发这个事件时要发哪些 RPTID。第三步 S2F37 使能事件：给一个 CEID 列表和使能标志，只有使能了的事件才会真正发出 S6F11。

'S2F33' W <L[2] <L[0]> // DATAID，未使用给空 <L[1] // 本次定义 1 个报告 <L[2] <U4 RPTID 1001> <L[3] // 报告里 3 个变量，顺序即上报顺序 <U4 VID 1001> // 腔体温度 <U4 VID 1002> // 腔体压力 <U4 VID 1003> // 射频功率 > > > >. 'S2F35' W <L[2] <L[0]> <L[1] <L[2] <U4 CEID 2001> // 事件：工艺开始 <L[1] <U4 RPTID 1001> > // 该事件触发时发 1001 号报告 > > >. 'S2F37' W <L[2] <BOOLEAN 1> <L[1] <U4 CEID 2001> > >. // 使能该事件

这三条消息分别回 S2F34（DRACK）、S2F36（LRACK）、S2F38（ERACK），返回码 0 才算成功。DRACK 的几个非零值要分清含义：1 是结构不合法，2 是变量不存在，3 是报告数量已满，4 是报告已存在。现场最常遇到的是 2——主机侧用了字典里没登记的 VID，这时不该去改设备代码，而应该回头核对数据项字典。

REPORTS = {} # RPTID -> [VID, ...]，有序 LINKS = {} # CEID -> [RPTID, ...] ENABLED = {} # CEID -> bool def s2f33_define_report(body, vid_dict): """body: [DATAID, [[RPTID, [VID...]], ...]] 返回 DRACK""" if not isinstance(body, list) or len(body) != 2: return 1 # 结构不合法 new_reports = {} for rpt in body[1]: rptid, vids = rpt[0], rpt[1] if any(v not in vid_dict for v in vids): return 2 # 存在未登记的数据变量 new_reports[rptid] = list(vids) # list 保留顺序 REPORTS.clear() # 覆盖式：不是增量追加 REPORTS.update(new_reports) return 0 def s2f35_link(body): """body: [DATAID, [[CEID, [RPTID...]], ...]]，返回 LRACK""" new_links = {} for ceid, rptids in body[1]: if any(r not in REPORTS for r in rptids): return 2 # 报告未定义 new_links[ceid] = list(rptids) LINKS.update(new_links) # 关联式：按 CEID 覆盖 return 0

两个细节值得单独说明。S2F33 是整体覆盖语义，主机发一条空的 S2F33 就等于把所有报告清空，实现里必须 clear 而不是 update，否则主机的「重新定义」会变成反复追加，跑到几十个报告后直接顶到上限。S2F35 则是按 CEID 覆盖，同一个 CEID 重复关联时以最后一次为准。

报告定义和事件关联最终要落到存储上，重启后不能丢，否则设备一断电主机就得重新配一遍：

CREATE TABLE gem_report_def ( rpt_id INT NOT NULL, vid INT NOT NULL, vid_order SMALLINT NOT NULL, -- 决定 S6F11 里变量的排列顺序 updated_at TIMESTAMP NOT NULL, PRIMARY KEY (rpt_id, vid) ); CREATE TABLE gem_event_link ( ceid INT NOT NULL, rpt_id INT NOT NULL, enabled BOOLEAN NOT NULL DEFAULT FALSE, updated_at TIMESTAMP NOT NULL, PRIMARY KEY (ceid, rpt_id) );

vid_order 这一列看着多余，实际上是排查「值全对但位置全错」问题的唯一依据。主机侧按定义顺序解析 S6F11 的数据链，一旦设备用无序字典存 VID，Python 3.7 之前或者跨进程序列化之后就很容易乱序，最后表现成温度字段里显示的是压力值。

4.2 变量数据、跟踪数据与状态数据：三种采集的节奏完全不同

GEM 把数据采集拆成三类，很多人以为只是叫法不同，实际上采样机制和应用场合差得很远。

变量数据采集是「主机要什么给什么」，用 S1F3 请求一组 VID，S1F4 返回当前值。它适合主机做画面刷新和报表，节奏由主机控制，设备只要保证取值时不阻塞。状态数据采集偏静态，用 S1F11 拿状态变量名列表、S1F3 拿值，典型的对象是设备型号、软件版本、当前配方名这类变化很慢的量。跟踪数据采集则是设备按固定周期主动上报，靠 S2F23 初始化，参数有四个：TRID 跟踪号、DSPER 采样周期、TOTSMP 总采样数、REPGSZ 每包采样数，之后设备按周期发 S6F1。

DSPER 的取值直接决定网络负载。一条 S6F1 带三个四字节变量大约 60 字节，100 ms 周期下每秒 600 字节，对千兆网毫无压力；但如果主机同时开了十条跟踪、每条都 50 ms，再加上事件上报，设备端发送队列就会开始堆积，表现出来的现象是「数据延迟越来越长」，而不是报错。我一般会在设备侧给发送队列设一个水位线，超过 200 条就丢弃最旧的跟踪数据并置一个内部告警位，宁可丢数据也不能把事件上报堵死。

4.3 报警与远程命令：S5F1 上报与 S2F41 下发怎么配对

报警管理的核心是一条 S5F1，三个数据项：ALCD、ALID、ALTX。ALCD 是位标志，最高位表示置位还是消除，低七位表示报警类别。这个位定义踩过坑的人不少——把置位和消除都发成同一个 ALCD 值，主机侧看到的报警列表会一直加，永远不会清。

ALARM_SET, ALARM_CLEAR = 0x80, 0x00 def build_s5f1(alid, text, is_set, category=1): """ALCD = 置位/消除位 | 类别（低七位）""" alcd = (ALARM_SET if is_set else ALARM_CLEAR) | (category & 0x7F) return ("S5F1", {"ALCD": alcd, "ALID": alid, "ALTX": text}) def handle_s5f3(body, alarm_table): """S5F3：主机使能/禁止某条报警，返回 S5F4 与 ACKC5""" enable_flag, alids = body[0], body[1] for alid in alids: if alid not in alarm_table: return 1 # 1 = 报警不存在 alarm_table[alid].enabled = bool(enable_flag) return 0 # 0 = 全部接受

ALTX 是给人看的文本，长度一般控制在 40 个字符以内。这里有个绕不开的现实问题：SECS-II 的字符串按 ASCII 定义，中文报警文本需要双方事先约定编码，否则主机侧收到就是乱码。稳妥的做法是报警文本统一用英文短语，中文说明放在数据项字典的注释列里，主机界面自己做映射。这样既不会破坏协议一致性，产线维护人员也能看懂。

远程命令走 S2F41，结构是 RCMD 加一组 CPNAME/CPVAL 参数对，回复 S2F42 里的 HCACK 有几个值必须分清楚：0 表示命令存在且参数合法，1 表示命令不存在，2 表示命令存在但当前无法执行，3 表示参数不合法，4 表示命令已被接受但尚未完成。把「已接受未完成」和「已成功」混为一谈是常见错误——长动作命令应该先回 4，动作结束后再通过事件 S6F11 通知结果。

4.4 时钟、终端服务与工艺程序：验收必查但常被跳过的模块

时钟这块有三条消息：S2F17 请求当前时间并回 S2F18，S2F31 由主机下发时间、设备回 S2F32 确认。规格里把时钟单列一项是有原因的——事件上报的每一帧都带时间戳，设备与主机差几分钟，事后追工艺曲线就无法对齐。我一般要求设备侧每小时与主机对一次表，偏差超过 1 秒就打日志。

终端服务是 S10F3 把一行文本送到设备显示区，设备回 S10F4 带 ACKC10。这条能力看着可有可无，但主机侧的操作提示、换料提醒都靠它，缺了以后只能靠人喊。工艺程序管理是一组以 S7 开头的消息：S7F19 请求配方目录、S7F3 下载配方、S7F5 上传配方、S7F17 删除配方。如果这个项目的主机需要做配方集中管理，这几条必须实现完整，不能只做下载不做校验；上传回来和下载下去的配方要做逐字节比对，这一步省掉，后面配方对不上的问题极难定位。

5. 排查与避坑：上线前最容易翻车的五个点

5.1 通讯显示已建立，但事件一条都不上报

现象很典型：主机侧看到连接正常，S1F1 也能拿到回复，但触发工艺开始之后，S6F11 一条都没有。原因几乎都在配置链路上——S2F33 定义了报告、S2F35 也关联了事件，唯独漏了 S2F37 的使能；或者 S2F35 关联时用的 RPTID 已经被后一条 S2F33 覆盖掉了。

解决方式是把这三步做成一个可回读的闭环：设备侧保存报告定义、事件关联、使能状态三张表，主机侧配置完成后发一次「查配置」的请求，把三张表的内容原样回读一遍，双方比对。我在项目里固定要求：任何一次 S2F33 之后，必须重新走一遍 S2F35 和 S2F37，不依赖上一轮的残留状态。

5.2 断线重连成功，主机却收到一批很久以前的事件

现象是重连后瞬间涌入几十条 S6F11，时间戳全是断线之前的。原因在通讯状态机的 WAIT DELAY 分支——规格要求连接事务失败时清空发送队列，实现里没做这一步，消息一直堆在内存里，等链路恢复后按原顺序全部喷出去。

解决办法是在发送队列外面再套一层「代次号」：每次进入 NOT COMMUNICATING 就把代次加一，队列里的消息带着自己的代次，发送时比对不一致就丢弃。这样做比直接 clear 更安全，因为 clear 有可能把正在发送中的那条也一并抹掉，造成主机侧收到半个报文。

5.3 主机收到的变量值顺序全乱，或者干脆是空值

现象是 S6F11 结构合法，但温度和压力对不上号，或者某些位置是空的。原因有两类：一是 RPTID 到 VID 的映射用了无序容器，序列化后顺序漂移；二是主机用了数据项字典里没登记的 VID，设备侧不报错，直接给了一个空值占位。

解决方式是双管齐下。存储层用 vid_order 显式记录顺序，序列化时按它排序；取值时如果 VID 不存在，不要静默填空，而应该在 S2F33 的 DRACK 里回 2 提前拒绝，问题暴露在配置阶段总比暴露在量产阶段好。

5.4 命令执行成功了，主机却判定失败

这类问题通常不是设备的问题，而是 T3 设得太小。某条动作命令实际执行 40 秒，T3 留了 15 秒，主机侧等到超时就把这条命令标记成失败，可能还会触发重试，设备那边于是执行了两次。另一种情形是设备把长动作命令直接同步执行完才回 S2F42，中间没有任何反馈。

正确的做法是把长动作拆成三段：收到 S2F41 立即回 HCACK=4（已接受未完成），动作过程中用事件上报进度，动作结束后再发一条携带结果码的事件。主机侧拿到 4 就不该判超时，这条约定必须写进接口文档，不能靠双方默契。

5.5 现场联调时通时不通，日志上看不出任何异常

现象是同一套代码，在实验室百试百灵，到车间就时不时断一下。原因多半在网络层：设备工控机和主机不在同一个网段，中间过了两级交换机，或者工控机开了双网卡而默认路由指到了办公网。

排查顺序建议从下往上走：先在设备工控机上持续 ping 主机，记录丢包；再确认 HSMS 端口双向可达，很多车间的交换机策略默认只放行常用端口；最后查定时器，T8 在跨交换机场景下容易被抖动触发。我在项目里一般要求联调前先跑满半小时的连接保持测试，日志里没有任何一次非预期重连，再开始对消息。

6. 验收与答辩：用一份 Trace 把六个场景走完

验收 SECS/GEM 接口，最省事的办法是把所有能力压缩成六个场景，每个场景用固定的一对消息做证据，跑通即为通过。这套清单我用了几年，答辩时把 Trace 投出来，评委的问题基本都会被提前挡住。

Trace 的读法比工具更重要。一次完整的交互应该能对齐三样东西：SYSTEM BYTES 里的会话号、消息头里的 SEQUENCE NUMBER、以及设备端和主机端各自记录的本地时间。SEQUENCE NUMBER 对不上，说明中间有消息被丢弃或者重发逻辑写错了；时间差超过一秒，说明时钟没同步。这两点一查，八成的悬案当场结掉。

演示环节不要贪多，把一条完整链路走透比罗列十个功能更有说服力。我的习惯是现场触发一次工艺开始事件，屏幕上依次出现 S2F33 定义报告、S2F35 关联、S2F37 使能、S6F11 带上货真价实的三组变量值，最后主机回 S6F12。中间任何一个 ACK 非 0，立刻停下来解释原因，而不是跳过继续。

答辩时的提问集中在两处。第一处是能力清单：为什么物料搬送和 Spooling 留空，答案要能落到机构缺失和断线时长这两个具体原因上，而不是「暂时没做」。第二处是边界：这台工控机上的模块和设备主控谁负责安全联锁，答案必须是主控负责、接口只做数据转发，说错了就是设计缺陷。

从那以后我每次接手设备接口，都强制走一遍「先跑半小时连接、再配一遍报告、最后触发事件看值」这条最小闭环，确认无误才往上叠功能。这套顺序看起来笨，但把返工挡在了最前面，比事后补日志强太多。希望帮到你。

本文还有配套的精品资源，点击获取