4. SECS-II 消息结构:Stream/Function 编码规则、W-Bit/S-Bit/E-Bit 含义、Message ID 与 Reply Expected 机制

SECS-II(SECS-2)是 SEMI 标准 E5 定义的消息层协议,它建立在 SECS-I 或 HSMS 的传输层之上,为设备与主机之间的通信提供了标准化的消息格式和语义。本章将深入解析 SECS-II 消息的核心结构,包括 Stream/Function 编码规则、三种控制位(W-Bit、S-Bit、E-Bit)的含义,以及 Message ID 与 Reply Expected 机制的工作原理。

4.1 Stream/Function 编码规则

SECS-II 消息的核心标识由两个数字组成:Stream (S) 和 Function (F)。Stream 定义了消息的类别或功能组,Function 则定义了该类别下的具体操作。消息格式通常表示为 SxFy,例如 S1F1、S2F41。

关键概念: Stream 和 Function 共同构成消息的“身份证”,设备与主机通过解析 SxFy 来识别消息的意图和后续数据格式。

4.1.1 Stream 编号与分类

Stream 编号从 0 到 127,其中 0-63 由 SEMI 标准定义,64-127 保留给用户自定义。常见的标准 Stream 包括:

Stream 名称 描述
S1 Equipment Status 设备状态查询与报告
S2 Equipment Control 设备控制与参数管理
S3 Material Status 物料状态管理
S4 Material Control 物料控制与传输
S5 Exception Handling 异常处理与报警
S6 Data Collection 数据采集与事件报告
S7 Equipment Constants 设备常数管理
S9 System Errors 系统错误报告
S10 Terminal Services 终端显示与服务

4.1.2 Function 编号与消息方向

Function 编号从 0 到 255。Function 的奇偶性决定了消息的方向和类型:

  • 奇数 Function (F1, F3, F5...):表示 Primary Message(主消息),通常由请求方(如 Host)发起。
  • 偶数 Function (F2, F4, F6...):表示 Secondary Message(次消息),是对应奇数 Function 的回复消息。

例如,S1F1 是“请求设备列表”的主消息,而 S1F2 是“返回设备列表”的次消息。

开发提示: 在驱动开发中,收到一个奇数 Function 的消息时,通常需要准备一个对应的偶数 Function 消息作为回复,除非消息中明确设置了 W-Bit = 0。

4.1.3 消息编码结构

SECS-II 消息在传输层(SECS-I/HSMS)的 Data Message 中承载。其编码结构如下:

+----------------+----------------+----------------+----------------+
|   Length (4B)  |  Device ID (2B)|  SxFx (2B)     |  W-Bit (1bit)  |
+----------------+----------------+----------------+----------------+
|  S-Bit (1bit)  |  E-Bit (1bit)  |  Reserved (5b) |  System Bytes  |
+----------------+----------------+----------------+----------------+
|                    Data Block (可变长度)                          |
+-----------------------------------------------------------------+
SECS-II 消息编码结构 消息头 (Message Header) - 10 字节 数据块 (Data Block) - 可变长度 Length (4B) Device ID (2B) SxFx (2B) W-Bit S-Bit E-Bit System Bytes 说明: • SxFx 字段包含 Stream (高字节) 和 Function (低字节) 编码。 • W-Bit、S-Bit、E-Bit 位于消息头的控制位区域,共 3 位。

4.2 W-Bit / S-Bit / E-Bit 含义

SECS-II 消息头中的三个控制位(W-Bit、S-Bit、E-Bit)决定了消息的交互行为和事务处理方式。理解这三个位是正确实现 GEM 状态机的基础。

4.2.1 W-Bit (Wait-Bit)

W-Bit 表示发送方是否期望收到回复。它是 SECS/GEM 通信中最重要的控制位之一。

  • W-Bit = 1:发送方期望接收方在收到消息后,回复一个对应的 Secondary Message(偶数 Function)。
  • W-Bit = 0:发送方不期望回复,消息为“即发即忘”类型。
关键规则: 只有 Primary Message(奇数 Function)可以设置 W-Bit = 1。Secondary Message(偶数 Function)的 W-Bit 必须为 0。

4.2.2 S-Bit (Secondary-Bit)

S-Bit 用于标识消息是否为 Secondary Message(回复消息)。

  • S-Bit = 1:表示该消息是一个 Secondary Message,即对某个 Primary Message 的回复。
  • S-Bit = 0:表示该消息是一个 Primary Message。
开发提示: 在驱动实现中,S-Bit 通常与 W-Bit 配合使用。当收到一个 W-Bit = 1 的 Primary Message 时,回复的 Secondary Message 必须设置 S-Bit = 1。

4.2.3 E-Bit (End-Bit)

E-Bit 用于多块消息传输(Multi-Block Message)中,标识是否为最后一块数据。

  • E-Bit = 1:表示当前数据块是消息的最后一块。
  • E-Bit = 0:表示后续还有数据块,消息尚未结束。
注意: 对于单块消息(Single-Block Message),E-Bit 必须设置为 1。多块消息中,除最后一块外,所有数据块的 E-Bit 必须为 0。

4.2.4 控制位组合示例

W-Bit S-Bit E-Bit 消息类型 说明
1 0 1 Primary, 单块, 需回复 最常见的请求消息,如 S1F1
0 1 1 Secondary, 单块 对 Primary 的回复,如 S1F2
0 0 1 Primary, 单块, 无需回复 通知类消息,如 S6F11 事件报告
1 0 0 Primary, 多块, 需回复 大数据传输的第一块
0 1 0 Secondary, 多块 大数据回复的中间块
W-Bit / S-Bit / E-Bit 交互流程 主机 (Host) 设备 (Equipment) S1F1 (W=1, S=0, E=1) S1F2 (W=0, S=1, E=1) 流程说明: 1. 主机发送 S1F1 (W=1),期望设备回复。 2. 设备回复 S1F2 (S=1),表示这是对 S1F1 的回复。

4.3 Message ID 与 Reply Expected 机制

Message ID 和 Reply Expected 机制是 SECS-II 协议中实现可靠通信和事务管理的关键。它们确保消息能够被正确匹配和超时处理。

4.3.1 Message ID (System Bytes)

Message ID 是消息头中的 System Bytes 字段,用于唯一标识一个消息事务。在 HSMS 中,它占用 4 字节;在 SECS-I 中,占用 2 字节。

  • 唯一性:每个 Primary Message 必须分配一个唯一的 Message ID。
  • 匹配规则:Secondary Message 必须使用与对应的 Primary Message 相同的 Message ID。
  • 超时管理:发送方通过 Message ID 跟踪未回复的消息,并在超时后触发重试或错误处理。
实现要点: 在驱动中,通常使用一个递增的计数器或时间戳来生成 Message ID。同时,需要维护一个“待回复消息表”,记录所有已发送但未收到回复的 Message ID 及其超时时间。

4.3.2 Reply Expected 机制

Reply Expected 机制是 W-Bit 在协议层面的具体实现。它定义了消息发送方如何等待和接收回复。

场景 W-Bit 发送方行为 接收方行为
需要回复 1 保存 Message ID,启动超时计时器,等待回复 处理消息后,使用相同 Message ID 回复 Secondary Message
无需回复 0 发送后立即释放资源,不等待回复 处理消息后,不发送回复
回复超时 1 触发 T3 超时(Reply Timeout),重试或报告错误 —
收到意外回复 0 忽略该回复,或记录警告日志 —

4.3.3 超时处理与重试策略

在 Reply Expected 机制中,超时处理是保证通信可靠性的重要环节。SECS/GEM 标准定义了多个超时计时器,其中与消息回复相关的主要是 T3 (Reply Timeout)。

  • T3 超时:发送方在发送 W-Bit = 1 的消息后,等待回复的最大时间。默认值通常为 45 秒。
  • 重试策略:超时后,发送方可以选择重试(重新发送相同的 Primary Message)或报告错误。
  • 重试次数:通常建议重试 2-3 次,超过后判定为通信故障。
避坑指南: 重试时必须使用相同的 Message ID,否则接收方可能无法正确匹配。同时,重试间隔应逐渐增大(指数退避),避免网络拥塞。

4.3.4 消息事务生命周期

一个完整的 SECS-II 消息事务(Transaction)从发送 Primary Message 开始,到收到对应的 Secondary Message 或超时结束。其生命周期如下:

  1. 创建:发送方生成唯一的 Message ID,构造 Primary Message(W-Bit = 1)。
  2. 发送:消息通过传输层发送到接收方。
  3. 等待:发送方将 Message ID 加入待回复列表,启动 T3 计时器。
  4. 处理:接收方解析消息,执行相应操作,构造 Secondary Message(S-Bit = 1,Message ID 相同)。
  5. 回复:接收方发送 Secondary Message。
  6. 完成:发送方收到回复,从待回复列表中移除 Message ID,释放资源。
  7. 超时:如果 T3 超时,触发重试或错误处理。
消息事务生命周期 创建 Primary 发送消息 等待回复 (T3) 收到回复 T3 超时 事务完成 重试 / 报错

4.4 本章小结

SECS-II 消息结构是 SECS/GEM 协议的核心,理解 Stream/Function 编码规则、W-Bit/S-Bit/E-Bit 的含义以及 Message ID 与 Reply Expected 机制,是开发可靠设备驱动的基础。在实际开发中,需要特别注意以下几点:

  • 编码规范:严格遵循 SxFx 的奇偶规则,确保消息方向正确。
  • 控制位设置:根据消息类型正确设置 W-Bit、S-Bit 和 E-Bit,避免通信混乱。
  • 事务管理:合理管理 Message ID 和超时机制,确保消息的可靠传输和错误恢复。