4. SECS/GEM协议栈深入解析

SECS/GEM 并不是单一协议，而是一套分层协作的通信体系。理解它的关键在于把“传输层怎么把字节送到”和“消息层怎么表达业务语义”分开看。设备与 EAP 之间真正交换的，是 SECS-II 定义的消息；而 HSMS 或 SECS-I 只负责把这些消息可靠地搬运过去。若把三者混为一谈，现场排障时就会分不清是网络连接问题、会话状态问题，还是消息格式问题。

协议栈分层与两种承载方式

从下往上看，SECS/GEM 通常分为四层：物理/链路层、消息传输层、消息语义层和应用行为层。物理层在 HSMS 下就是 TCP/IP 以太网，在 SECS-I 下则是 RS-232 串行链路。消息传输层负责建立连接、维持会话、分包与确认；SECS-II 层定义消息的 Stream、Function 和数据结构；应用行为层则由 GEM 规范约束，规定设备在什么状态下应发出什么消息、如何响应远程命令。

HSMS 与 SECS-I 的核心差异在于承载方式。SECS-I 使用串口，以块（Block）为单位传输，每个块有长度字节和校验和，接收方需逐块确认，适合早期低速设备。HSMS 则把 SECS-II 消息封装进 HSMS 消息头，通过 TCP 连接传输，支持主动连接和被动连接，速率高、组网灵活，是现代设备的主流选择。两者在消息内容上完全一致，只是“信封”不同。

SECS-II 消息结构：SxFy 与数据项

SECS-II 消息用“Stream + Function”标识，写作 SxFy，例如 S1F13、S2F41、S6F11。Stream 表示功能大类，Function 表示具体动作。消息体由若干数据项（Data Item）组成，每个数据项有格式码和长度，常见格式包括：

• L：列表，可嵌套，是组织结构化数据的核心；
• A：ASCII 字符串，常用于文本、名称、配方号；
• U1/U2/U4：无符号整数，1/2/4 字节；
• I1/I2/I4：有符号整数；
• F4/F8：浮点数；
• B：二进制字节串；
• Boolean：布尔值。

例如一条 S6F11 事件报告，其消息体通常是一个列表，内部包含事件 ID、报告 ID 以及报告数据。报告数据本身又是一个列表，里面按顺序放置若干数据项。EAP 解析时必须严格按设备定义的报告结构逐项读取，顺序或类型不匹配就会解析失败。这也是现场最常见的“消息收到了但内容对不上”的原因。

常用消息流：S1、S2、S5、S6、S7

不同 Stream 承担不同职责，理解它们的分工比死记编号更重要。

典型交互顺序是：先 S1F13 建立通信，再 S1F1 确认在线；随后主机用 S2F33 定义报告、S2F35 链接事件；设备在状态变化或工艺节点触发时发出 S6F11；若发生报警，则通过 S5F1 上报，主机用 S5F2 确认。配方管理则走 S7 系列。整个过程像一套约定好的“对话剧本”，双方必须按顺序和格式应答。

设备状态模型与事件报告机制

GEM 设备状态模型通常包含几个关键状态：Init（初始化）、Idle（空闲）、Executing（执行中）、Pause（暂停）、Error（故障）。状态迁移由设备内部逻辑或远程命令驱动，每次迁移都可能触发事件报告。EAP 通过订阅这些事件，实时掌握设备在做什么。

事件报告机制由三部分组成：报告定义（Report Definition）、事件链接（Event Link）和报告发送（Report Send）。主机先用 S2F33 告诉设备“报告 ID 1001 包含哪些数据项”，再用 S2F35 告诉设备“事件 ID 2001 触发时发送报告 1001”。设备在事件发生时，按链接关系组装 S6F11 发出。若主机没有定义报告或没有链接事件，设备就不会主动上报，这是调试时“设备明明有动作却收不到消息”的常见原因。

报警管理机制

报警管理独立于事件报告，使用 S5 系列。设备检测到异常后，通过 S5F1 发送报警，消息体包含报警 ID、报警码、报警类型（如 Personal、Equipment、Material）以及报警文本。主机收到后应回复 S5F2 确认。报警有“发生”和“清除”两种状态，设备在报警恢复时再次发送 S5F1，用报警码或状态位区分。EAP 需要维护报警列表，避免重复上报和漏报。

把协议栈、消息结构、常用消息流、状态模型和报警机制串起来看，SECS/GEM 的本质就是一套“有状态、有约定、有确认”的对话系统。EAP 侧要做的，是正确建立会话、按设备定义解析消息、按事件驱动业务逻辑，并对报警做出及时响应。只有把每一层的职责分清，才能在设备接入和自动化控制中稳定运行。