2. SECS/GEM协议族入门
在半导体设备联机领域，SECS/GEM 并不是一个单一协议，而是一组分工明确的协议族。很多初学者第一次接触时，会把 SECS-I、HSMS、SECS-II、GEM 混为一谈，结果在配置 EAP 时不知道该改哪一层。理解它们的关键，是把它们看成一条从“物理链路”到“业务语义”的分层栈：底层负责把字节可靠地送过去，中间层负责把字节组织成有意义的消息，上层负责规定设备与主机之间该交换哪些消息、在什么状态下交换。
先看消息结构。一条 SECS-II 消息由消息头和消息体组成。消息头固定 10 个字节，包含：设备 ID（2 字节）、消息头第 3 字节（含 W-bit 与 Stream）、功能号（1 字节）、PType（1 字节）、SType（1 字节）、System Bytes（4 字节）。其中 W-bit 表示该消息是否需要回复；Stream 与 Function 合称“流与功能号”，例如 S1F13 表示第 1 流第 13 功能，常用于建立通信请求。消息体由若干数据项（Data Item）组成，每个数据项带格式码和长度，支持 L（列表）、A（ASCII）、U1/U2/U4（无符号整数）、I1/I2/I4（有符号整数）、F4/F8（浮点）、B（二进制）等类型。例如设备上报温度时，消息体可能是 <A "TEMP"><F4 25.3>，表示一个 ASCII 名称加一个 4 字节浮点值。
接下来是“流与功能号”。Stream 表示一类业务主题，Function 表示该主题下的具体动作。常用流包括：S1 通信与状态、S2 设备控制与诊断、S5 报警、S6 事件报告、S7 配方、S9 错误、S10 终端消息。以 S6 为例，S6F11 是“事件报告发送”，设备在状态变化或工艺完成时主动上报；主机收到后回 S6F12 确认。S5F1 是报警上报，S5F3 用于使能或禁止报警。理解流与功能号，等于掌握了设备与主机之间的“对话词典”。
会话层与事务层是实际联机调试中最容易出问题的部分。会话层负责“连接是否建立、是否保持”。HSMS 通过 Select 请求进入 Selected 状态，之后才能收发数据；如果长时间无数据，需靠心跳（Linktest）维持。SECS-I 则通过 ENQ/EOT/ACK/NAK 握手建立块传输。事务层负责“一次请求—回复”的配对：每条带 W-bit 的消息都有唯一 System Bytes，回复消息必须携带相同 System Bytes，否则会被判为孤立消息。EAP 侧通常维护一个事务表，记录已发出但未回复的消息，超时后触发重试或报警。
| 层次 | 代表协议 | 关键职责 | 常见参数/状态 |
|---|---|---|---|
| 应用层 | GEM | 状态模型、报警、事件、配方 | Control State、Events、Alarms |
| 消息层 | SECS-II | 流/功能号、数据项编码 | SxFy、L/A/U4/F4 |
| 传输层 | SECS-I / HSMS | 串行块传输 / TCP 会话 | Baud、Device ID、Select、Linktest |
用一个教学示例串起来：假设 EAP 要读取设备温度。EAP 发送 S1F3（请求状态变量），消息头 W-bit=1，System Bytes=0x00000001，消息体列出要查询的 SVID 列表。设备收到后，若支持该功能，回复 S1F4，System Bytes 仍为 0x00000001，消息体携带对应温度值，例如 <F4 25.3>。若设备不支持，则回 S1F0 或 S9F5。整个过程在 HSMS 的 Selected 会话内完成，底层 TCP 只负责字节流，不关心里面是 S1F3 还是 S6F11。这就是分层带来的清晰边界：传输层保证可达，消息层保证可解析，GEM 保证行为可预期。
最后强调一个常见误区：GEM 不是一种传输方式，也不是一种消息格式，而是一套“设备应该怎么表现”的规范。它规定了设备在收到 S1F13 后应回 S1F14、在报警发生时主动发 S5F1、在状态变化时发 S6F11。SECS-II 只定义消息长什么样，GEM 定义消息在什么场景下该出现。把这三层关系理清，后续配置 EAP、抓包分析和排障时，就能快速定位问题出在链路、消息还是业务语义层。