3. SECS-II消息结构
SECS-II 消息是设备与主机之间交换数据的“信封+正文”。要读懂一条报文，必须同时看清三层：消息头（Header）负责寻址与事务控制，系统字节（System Bytes）负责事务配对，数据项（Data Item）负责承载工艺参数与状态。流（Stream）与功能（Function）则构成消息的“编号坐标”，例如 S1F13、S2F41、S6F11。理解这些字段的位级含义，是后续做协议测试、日志解析和故障定位的基础。
一、消息整体结构：从字节流到语义
一条 SECS-II 消息在 HSMS 或 SECS-I 之上传输时，可拆成“消息头 + 消息体”两部分。消息头固定 10 字节，前 4 字节是设备 ID 与 W-bit、流、功能，后 6 字节是 P-bit、SECS-II 版本、系统字节等控制信息。消息体由若干数据项按顺序排列，每个数据项自带格式码和长度，形成可嵌套的树形结构。
二、流与功能：消息的“编号坐标”
流（Stream）用 S 表示，功能（Function）用 F 表示，合起来写作 SxFy。流代表一类业务主题，例如 S1 是设备状态与通信建立，S2 是设备控制与工艺参数，S6 是事件报告。功能是同一流下的具体动作，奇数功能通常表示“请求”，偶数功能表示“回复”。例如 S1F13 是主机请求建立通信，S1F14 是设备回复；S2F41 是主机下发远程命令，S2F42 是设备回复命令执行结果。
测试时最常见的错误是把 SxFy 写错或把请求/回复方向搞反。解析日志时，先看流号判断业务域，再看功能号判断动作类型，最后看 W-bit 判断是否需要回复，这样能快速定位一条消息在交互中的位置。
三、消息头字段与系统字节
消息头是 10 字节的二进制结构，不同传输层（SECS-I 与 HSMS）在字节序和部分字段上略有差异，但核心字段一致。下表列出关键字段的含义与解析要点：
| 字段 | 长度 | 含义 | 解析要点 |
|---|---|---|---|
| Device ID | 2 字节 | 设备标识，用于多点连接寻址 | HSMS 中通常为 0xFFFF 表示不指定；SECS-I 中用于区分设备 |
| W-bit | 1 bit | Wait-bit，表示发送方是否等待回复 | W=1 表示需要对方回复；W=0 表示单向通知，不期待回复 |
| Stream | 7 bit | 流号，取值 0~127 | 与 Function 组合成 SxFy；S0 保留用于特殊用途 |
| Function | 1 字节 | 功能号，取值 0~255 | 奇数为请求，偶数为回复；F0 常用于中止事务 |
| P-bit | 1 bit | Protocol-bit，表示是否要求回复 | 与 W-bit 配合使用；P=1 时接收方必须回复 |
| System Bytes | 4 字节 | 事务标识，用于请求与回复配对 | 请求与对应回复必须使用相同的 System Bytes；测试时重点核对 |
四、W-bit 与 E-bit 的含义与区别
W-bit 位于消息头第一个字节的最高位，是“等待回复”标志。当 W=1 时，发送方发出请求后会启动超时计时器（常见 T3 超时），等待对方回复；若超时未收到回复，则判定通信异常。W=0 时，消息是单向通知，发送方不等待回复，也不应期待对方回消息。
E-bit 是“结束位”（End-bit），位于消息体数据项的长度字段中，用于标识一个数据项的值是否结束。在 SECS-II 中，数据项长度字段的最高位（bit7）就是 E-bit：E=1 表示该数据项的值到此结束；E=0 表示后面还有后续数据项或该数据项尚未结束。对于长度超过 1 字节的数据项，E-bit 帮助解析器判断边界，避免把多个数据项误读成一个。
核心区别：W-bit 控制“消息级”的请求-回复行为，决定是否等待回复；E-bit 控制“数据项级”的边界，决定一个数据项的值在哪里结束。两者作用层级不同，解析时不能混淆。
五、解析方法与实操步骤
解析一条 SECS-II 消息，建议按以下顺序进行：
- 读取消息头 10 字节：先取前 10 字节，按传输层规则解析 Device ID、W-bit、Stream、Function、P-bit、System Bytes。
- 判断消息方向与类型：根据 SxFy 判断是请求还是回复，结合 W-bit 判断是否需要回复。
- 解析数据项：从消息体起始位置开始，读取格式码，判断类型和长度字节数，再读取长度和值。
- 递归处理列表：遇到 L 类型时，按列表长度递归解析内部数据项，直到所有数据项读完。
- 核对 System Bytes：将请求与回复的 System Bytes 配对，确认事务完整。
下面是一段典型的日志解析示例，展示如何从十六进制字节流中提取关键字段：
原始报文（HSMS Data Message）：
00 00 00 0A 00 01 81 0D 00 00 00 01 01 02 41 08 53 54 41 54 55 53
解析结果：
Device ID = 0x0000
W-bit = 1（等待回复）
Stream = 1
Function = 13
P-bit = 0
System Bytes= 0x00000001
数据项 = L,2 → A,8 "STATUS" → U4,1 0x00000001
消息语义 = S1F13 请求建立通信，等待 S1F14 回复
六、常见误区与复盘
误区一：把 W-bit 当成 P-bit。W-bit 表示“是否等待回复”，P-bit 表示“是否要求回复”。两者语义相近但位置不同，测试中若混淆会导致超时判断错误。
误区二：忽略 System Bytes 配对。请求与回复的 System Bytes 必须一致。若日志中出现多个并发事务，必须靠 System Bytes 区分，否则会把回复错配到其他请求上。
误区三：E-bit 解析错误。当数据项长度超过 1 字节时，E-bit 位于长度字段最高位。若直接按整字节读取长度，会把 E-bit 当成长度的一部分，导致数据项长度计算错误。
误区四：流功能号写反。S1F13 与 S1F14 是成对的请求/回复，测试脚本中若把方向写反，设备会返回错误或直接超时。
复盘时建议建立一张“消息字段核对表”，把 Device ID、W-bit、SxFy、P-bit、System Bytes、数据项格式码逐项打勾确认。对于高频消息如 S1F13/S1F14、S2F41/S2F42、S6F11/S6F12，可以预先准备解析模板，提高排障效率。
实用技巧：在抓包工具中过滤 HSMS 的 Data Message，先看消息头前 4 字节确定 SxFy 和 W-bit，再用 System Bytes 搜索配对回复。对于数据项解析，优先识别 L 类型，因为列表是嵌套结构的入口。
掌握消息头、系统字节、W-bit、E-bit 与数据项的解析方法后，就能把一串十六进制字节还原为有业务含义的 SECS-II 交互。这是后续做协议一致性测试、超时排查和日志分析的基本功。