3、SECS/GEM标准体系：SEMI标准家族、SECS-I、SECS-II、HSMS、GEM的核心作用与关系
半导体设备通信协议的学习，最困难的部分往往不是某一条报文怎么写，而是面对SEMI标准家族中纷繁复杂的术语——SECS-I、SECS-II、HSMS、GEM——感到彼此纠缠、边界模糊。许多工程师在阅读设备手册或编写通信模块时，常混淆“传输层”与“消息层”的职责，或将GEM（Generic Equipment Model，通用设备模型）误认为一种独立的通信协议。实际上，SECS/GEM是一套分层协作的标准体系：底层解决“字节如何物理传输”，中层解决“消息如何结构化表达”，顶层解决“设备行为如何标准化”。本章将逐一拆解SEMI标准家族中每个成员的核心作用，并厘清它们之间的依赖关系与协作边界。
上图展示了SECS/GEM标准体系的纵向分层关系。从下往上看，物理介质（串口或以太网）承载传输层协议（SECS-I或HSMS），传输层之上是消息层SECS-II，最顶层是设备行为标准GEM。这种分层设计使得底层传输技术的更替（从串口到以太网）不会影响上层消息语义的稳定性，而GEM的引入则让不同厂商的设备在行为层面具备互操作性。下面逐一深入剖析每个标准的核心机制。
3.1 SEMI标准家族全景：从E4到E116
SEMI（Semiconductor Equipment and Materials International，国际半导体设备与材料协会）发布的标准编号体系覆盖了设备通信、物料管理、工厂集成等方方面面。与SECS/GEM直接相关的核心标准包括：E4（SECS-I）、E5（SECS-II）、E30（GEM）、E37（HSMS）。此外，E39（Equipment E-Standard，设备安全标准）、E87（Material Movement Management，物料搬运管理）、E90（Trace Management，追踪管理）、E94（Control Job Management，控制任务管理）、E116（Equipment Performance Tracking，设备性能追踪）等标准在GEM框架下扩展了设备行为模型。
这些标准并非彼此孤立，而是存在明确的依赖关系。E4和E37解决“字节如何传输”，E5解决“消息如何编码”，E30则定义了设备在正常生产、维护、报警等场景下应遵循的状态转换和消息交互规则。E87/E90/E94等标准则是在GEM基础模型之上，针对物料追踪、数据采集、任务调度等特定场景的补充规范。
| 标准编号 | 标准名称 | 核心作用 | 典型应用场景 |
|---|---|---|---|
| E4 | SECS-I | 串行传输层协议，定义物理层和数据链路层 | 老式设备RS-232通信，波特率9600 |
| E5 | SECS-II | 消息层协议，定义消息格式、数据项编码 | 所有SECS/GEM设备的消息解析 |
| E30 | GEM | 设备行为标准，定义状态模型、报警、远程命令 | 设备与主机之间的标准化交互 |
| E37 | HSMS | 以太网传输层协议，替代SECS-I的高速通信 | 现代设备TCP/IP通信，端口5000/5001 |
| E39 | EES | 设备安全标准，定义安全事件上报 | 设备安全联锁、紧急停机状态上报 |
| E87 | MMM | 物料搬运管理，定义载具、批次追踪 | 晶圆盒（FOUP）在设备间的流转追踪 |
| E90 | Trace | 追踪管理，定义设备内部信号采样与上报 | 设备工艺参数（温度、压力）实时追踪 |
| E94 | CJM | 控制任务管理，定义多配方协同执行 | 复杂工艺步骤的调度与监控 |
3.2 SECS-I：串行传输的基石
SECS-I（SEMI E4）是SECS/GEM体系中最底层的传输协议，设计于1980年代，基于RS-232或RS-422串行通信。它的核心职责是：将SECS-II消息拆分为多个数据块（Block），通过串口逐块发送，并确保接收方正确重组。SECS-I定义了严格的帧格式、校验机制和超时重试逻辑。
SECS-I的帧结构包含：块头（Block Header）和数据区（Data Area）。块头长度为10字节，包含设备ID（Device ID）、块号（Block Number）、消息ID（Message ID）、消息类型（Primary/Secondary）等信息。数据区最大长度为244字节，因此一条较长的SECS-II消息需要拆分为多个块传输。每个块发送后，接收方必须回复一个ACK（确认字符）或NAK（否定确认），发送方根据回复决定继续发送或重试。
SECS-I 块结构示例（十六进制）：
设备ID: 0x0001 (2字节)
块号: 0x0001 (2字节)
消息ID: 0x0001 (2字节)
类型: 0x00 (Primary) (1字节)
保留: 0x00 (1字节)
长度: 0x000A (2字节) -- 数据区长度10字节
数据区: 0x01 0x02 0x03 ... (最多244字节)SECS-I的传输速率通常为9600波特率，实际有效吞吐量约1KB/s。这在处理简单报警或状态上报时足够，但对于大量数据采集（如Trace数据）则显得力不从心。此外，SECS-I采用半双工通信，同一时刻只能一方发送，另一方接收，这进一步限制了通信效率。
3.3 SECS-II：消息层的结构化表达
SECS-II（SEMI E5）定义了设备与主机之间交换消息的格式和语义。它不关心消息如何传输（由SECS-I或HSMS负责），只关心消息“长什么样”以及“如何解析”。SECS-II消息由消息头（Message Header）和消息体（Message Body）组成。消息头包含标准字节（Stream/Function）、消息类型（Primary/Secondary）、设备ID等；消息体则采用SML（SECS Message Language）格式，由一系列数据项（Item）组成。
SECS-II的核心概念包括：
- Stream/Function（S/F）：每条消息通过S/F编号唯一标识。例如，S1F1是“Are You There”请求，S1F2是“On Line Data”回复，S6F11是“Event Report”事件上报。Stream表示消息类别（如S1是设备状态、S5是报警、S6是数据上报），Function表示具体操作。
- 数据项（Item）：消息体由多个Item组成，每个Item包含数据类型（如ASCII、Binary、U4、I8等）、长度和数据值。Item可以嵌套，形成复杂的数据结构。
- Primary/Secondary消息：Primary消息是主动请求，Secondary消息是对Primary的回复。例如，主机发送S1F1（Primary），设备回复S1F2（Secondary）。
S1F1 消息示例（SML格式）：
S1F1 W
<DeviceID> 0x0001
<Model> "SECS-GEM Simulator"
<SoftRev> "1.0.0"SECS-II的消息编码规则非常严格，每个字节都有明确含义。解析器必须严格按照标准读取消息头、遍历Item树、处理数据类型转换。在实际工程中，建议使用成熟的SECS-II解析库（如SEMI标准提供的参考代码或商业库），避免手写解析器带来的兼容性问题。
3.4 HSMS：以太网时代的高速传输
HSMS（High-Speed Message Service，高速消息服务，SEMI E37）是SECS-I的以太网替代方案，设计于1990年代中期，以满足半导体工厂对更高通信速率和更灵活网络拓扑的需求。HSMS基于TCP/IP协议，采用全双工通信，支持多个并发连接，传输速率可达100Mbps以上。
HSMS的核心机制包括：
- 连接管理：HSMS定义了主动建立连接（Active）和被动接受连接（Passive）两种模式。设备通常作为Active端主动连接主机，主机作为Passive端监听端口（默认5000或5001）。连接建立后，双方通过心跳消息（Heartbeat）维持连接状态。
- 消息帧格式：HSMS消息帧包含10字节的消息头（与SECS-I块头类似）和可变长度的数据区。消息头中的Session ID用于区分不同会话，Message ID用于匹配Primary和Secondary消息。
- 流量控制：HSMS支持消息级流量控制，发送方可以同时发送多条消息而不必等待回复，接收方通过TCP的滑动窗口机制进行流量控制。
| 特性 | SECS-I (E4) | HSMS (E37) |
|---|---|---|
| 物理介质 | RS-232/RS-422串口 | 以太网（RJ45/光纤） |
| 通信模式 | 半双工 | 全双工 |
| 典型速率 | 9600 bps | 10/100/1000 Mbps |
| 连接方式 | 点对点 | 点对点/多点 |
| 消息确认 | 块级ACK/NAK | TCP层确认 |
| 适用场景 | 老式设备、低速通信 | 现代设备、大数据量传输 |
3.5 GEM：设备行为的标准化框架
GEM（Generic Equipment Model，通用设备模型，SEMI E30）是SECS/GEM体系中最具业务价值的标准。它不定义新的传输协议或消息格式，而是规定设备在特定场景下应如何行为——即“何时发送什么消息”。GEM的核心内容包括：
- 设备状态模型：定义了设备从初始化、待机、运行、暂停、报警到停止的完整状态转换路径。每个状态对应一组允许的消息交互。
- 报警管理：设备检测到异常时，通过S5F1（Alarm Report）消息上报报警，主机可通过S5F2（Alarm Report Acknowledge）确认。报警分为Fatal（致命）和Non-Fatal（非致命）两类。
- 配方管理：主机可通过S7F1（Process Program Load）下载配方到设备，设备执行后通过S7F5（Process Program Request）上报配方列表。
- 远程命令：主机通过S2F41（Host Command）发送远程命令（如Start、Stop、Pause），设备执行后返回S2F42（Host Command Acknowledge）。
- 事件上报：设备在特定事件发生时（如批次完成、报警触发），通过S6F11（Event Report）主动上报数据。
- 数据采集：支持S2F23/S2F24（Trace Initialize/Data）实现周期性数据采集，以及S6F1/S6F2（Data Report）实现事件触发的数据上报。
GEM还定义了设备与主机之间的通信状态模型，包括：Disabled（禁用）、Enabled（启用）、Online（在线）、Offline（离线）等状态。设备必须支持主机通过S1F13（Establish Communication）建立通信，通过S1F15（Request Offline）切换离线模式。
3.6 案例拆解：从SECS-I升级到HSMS的实战过程
某半导体设备厂商的旧款刻蚀机原本使用SECS-I（RS-232）与工厂主机通信，波特率9600，仅支持基本的报警上报和状态查询。随着工厂产能提升，主机需要实时采集设备的工艺参数（如腔体温度、气体流量），数据量从原来的每秒几十字节增加到每秒数百字节。SECS-I的带宽成为瓶颈，且串口通信距离受限（最长15米），无法满足设备重新布局的需求。
初始现象与目标：设备通信频繁超时，Trace数据采集周期无法缩短到1秒以内。目标是将通信升级为HSMS，同时保持上层SECS-II消息语义不变，并确保GEM行为模型不受影响。
关键输入数据：
- 原SECS-I配置：波特率9600，8数据位，1停止位，无校验，块超时200ms
- Trace数据量：每周期约500字节，目标周期1秒
- 设备硬件：主控板预留以太网接口，支持TCP/IP
分析判断过程：首先确认设备主控板是否支持HSMS协议栈。由于主控板运行Linux系统，可选用开源SECS/GEM库（如secs4java或自研C++库）。其次，评估HSMS消息帧格式与SECS-I的差异——HSMS消息头长度相同（10字节），但数据区长度不再限制为244字节，因此Trace数据可以封装在单条消息中，无需分块。
实际操作步骤：
- 在设备主控板上实现HSMS协议栈，配置TCP端口5001，作为Active端连接主机。
- 将原有SECS-II消息处理模块复用，仅替换传输层接口——将SECS-I的块收发逻辑替换为HSMS的消息帧收发逻辑。
- 在GEM配置中增加Trace数据采集项，设置采样周期为1秒，通过S2F23初始化Trace。
- 进行联调测试：验证S1F13通信建立、S6F11事件上报、S2F41远程命令等核心流程。
- 对比升级前后数据：Trace数据上报周期从5秒缩短至1秒，通信超时率从2%降至0.1%。
结果对比与风险：升级后通信速率提升约100倍，但初期遇到一个问题：主机端防火墙未开放TCP 5001端口，导致连接失败。解决方法是协调IT部门开放端口，并配置设备IP白名单。此外，HSMS的心跳机制需要定期发送心跳消息（默认每10秒），若主机未响应，设备应主动断开连接并重连。
复盘经验：传输层升级的关键在于“隔离变化”——保持SECS-II消息语义和GEM行为模型不变，仅替换传输层实现。这样既降低了回归测试风险，又保留了未来继续升级（如从HSMS到SECS-II over TLS）的可能性。
3.7 常见误区与总结复盘
在SECS/GEM标准体系的学习和工程实践中，以下误区最为常见：
- 混淆SECS-I与SECS-II：SECS-I是传输层，SECS-II是消息层。调试时若发现消息解析错误，应先确认传输层是否完整接收了所有块，再检查消息层编码。
- 忽视GEM状态模型：GEM不仅是“一组消息”，更是一套状态机。设备必须在正确的状态下响应正确的消息，否则会导致主机端逻辑混乱。
- 认为HSMS只是“以太网版的SECS-I”：HSMS在连接管理、流量控制、消息帧格式上与SECS-I有本质差异，不能简单替换。
- 忽略SEMI标准版本兼容性：SEMI标准会定期修订（如E30从1992年发布至今多次更新），不同版本的消息定义可能存在差异。设备与主机必须协商使用相同版本的标准。