3、HSMS协议详解：TCP/IP传输层、会话建立与断开、连接模式（主动/被动）、消息封装与超时管理
HSMS（High-Speed SECS Message Services）是SECS/GEM协议族中基于TCP/IP的传输层协议。它替代了传统的RS-232串口通信，为半导体设备提供了高速、可靠的网络通信能力。本章将深入剖析HSMS的传输层机制、会话生命周期、连接模式、消息帧结构以及关键的定时器管理。
3.1 HSMS在SECS/GEM协议栈中的位置
HSMS位于OSI模型的传输层与表示层之间，负责将上层的SECS-II消息（Stream/Function）封装成标准的数据帧，并通过TCP/IP网络进行可靠传输。
核心定位： HSMS是SECS-II与TCP/IP之间的桥梁，它不关心消息的业务含义，只负责消息的可靠投递、连接管理和流量控制。
3.2 TCP/IP传输层基础
HSMS完全依赖TCP/IP协议栈提供面向连接的、可靠的字节流服务。理解TCP的特性是掌握HSMS的前提。
| TCP特性 | 对HSMS的影响 | 工程注意事项 |
|---|---|---|
| 面向连接 | 通信前必须建立TCP连接（三次握手） | 设备IP/端口配置必须正确，防火墙需放行 |
| 可靠传输 | HSMS无需实现重传逻辑，依赖TCP保证 | 需关注TCP窗口大小对吞吐量的影响 |
| 字节流 | HSMS必须自己定义消息边界（长度字段） | 粘包/拆包是HSMS实现的核心难点 |
| 全双工 | HSMS支持双向同时发送消息 | 需处理并发消息的时序问题 |
⚠ 常见陷阱： TCP是流协议，没有消息边界。HSMS通过在消息头部添加4字节长度字段来解决粘包问题。初学者常犯的错误是假设一次recv()调用就能收到一个完整的HSMS消息。
3.3 HSMS会话建立与断开
HSMS会话建立在TCP连接之上，但比TCP连接有更严格的状态管理。一个完整的HSMS会话生命周期包括：TCP连接建立、HSMS会话协商、数据传输、会话断开。
3.3.1 会话建立流程
- TCP三次握手： 底层网络连接建立。
- 发送Select.req： 主动方发送连接请求消息。
- 接收Select.rsp： 被动方回复确认，包含通信能力协商。
- 会话就绪： 双方进入Communicating状态，可以交换SECS-II消息。
3.3.2 会话断开流程
HSMS会话断开可以是正常断开或异常断开。正常断开通过发送Deselect.req/rsp消息完成；异常断开则直接关闭TCP连接。
| 断开类型 | 触发条件 | 消息交互 | 状态迁移 |
|---|---|---|---|
| 正常断开 | 应用层主动请求断开 | Deselect.req → Deselect.rsp | Communicating → Selected → Not Selected |
| 异常断开 | 网络故障、超时、对端崩溃 | 无消息交互，直接关闭TCP | Communicating → Not Connected |
| 链路测试失败 | Linktest.rsp超时 | Linktest.req未收到响应 | Communicating → Not Connected |
3.4 连接模式：主动与被动
HSMS定义了两种连接模式，决定了哪一方负责发起TCP连接和HSMS会话。
3.4.1 主动模式 (Active Mode)
- 角色： 设备作为TCP客户端，主动向主机发起连接。
- 适用场景： 设备需要主动上报事件，或主机IP固定。
- 配置： 设备需配置主机的IP地址和端口号。
3.4.2 被动模式 (Passive Mode)
- 角色： 设备作为TCP服务器，等待主机连接。
- 适用场景： 主机统一管理所有设备，由主机发起连接。
- 配置： 设备需配置自己的监听端口。
3.4.3 连接模式对比
| 对比维度 | 主动模式 | 被动模式 |
|---|---|---|
| 连接发起方 | 设备 | 主机 |
| 设备配置复杂度 | 高（需配置主机地址） | 低（仅需配置本地端口） |
| 网络穿透性 | 好（设备主动出站） | 差（需主机能访问设备） |
| 典型应用 | 设备主动上报、NAT环境 | 主机集中管理、内网环境 |
💡 工程建议： 在产线集成中，推荐使用被动模式。主机作为中心节点统一管理连接，便于监控和故障排查。如果设备位于防火墙后或NAT内，则必须使用主动模式。
3.5 消息封装：HSMS数据帧结构
HSMS消息在TCP字节流中通过固定格式的帧头进行封装。每个HSMS消息由消息头和消息体组成。
3.5.1 消息头格式 (10字节)
| 偏移 | 长度 | 字段 | 说明 |
|---|---|---|---|
| 0 | 4字节 | Length | 消息体长度（不包括这4字节本身），大端序 |
| 4 | 1字节 | Device ID (高7位) | 设备ID，用于多设备复用连接 |
| 5 | 1字节 | Stream | 消息流编号 (0x01-0xFF) |
| 6 | 1字节 | Function | 消息功能编号 (0x00-0xFF) |
| 7 | 1字节 | PType | 消息类型 (0x00=SECS-II, 0x01=HSMS控制) |
| 8 | 1字节 | SType | 会话类型 (0x00=数据消息, 其他=控制消息) |
| 9 | 1字节 | System Bytes (高8位) | 系统字节，用于消息配对 |
| 10-13 | 4字节 | System Bytes (低32位) | 系统字节，完整为5字节，但通常只使用低4字节 |
关键字段解析：
- Length： 解决TCP粘包的关键。接收方先读取4字节得到长度N，再读取N字节得到完整消息。
- PType： 区分SECS-II业务消息和HSMS控制消息（如Select/Linktest）。
- System Bytes： 用于关联请求和响应。发送请求时生成唯一ID，响应中必须回传相同ID。
3.5.2 消息封装示例
以下是一个完整的HSMS消息字节序列示例（十六进制）：
// 示例：S1F13 (Select.req) 控制消息
// 消息体为空，Length = 0
00 00 00 00 // Length = 0 (消息体长度)
80 01 0D 01 // Device ID=0, Stream=1, Function=13, PType=1(HSMS控制)
00 00 00 01 // SType=0(Select.req), System Bytes=1
// 示例：S1F14 (Select.rsp) 响应消息
// 消息体包含1字节数据 (0x00 表示成功)
00 00 00 01 // Length = 1
80 01 0E 01 // Device ID=0, Stream=1, Function=14, PType=1
00 00 00 01 // SType=0, System Bytes=1 (与请求相同)
00 // 消息体: 通信结果 (0=成功)
3.6 超时管理
HSMS定义了多个定时器来保证通信的健壮性。超时管理是HSMS实现中最容易出错的部分。
3.6.1 核心定时器
| 定时器 | 默认值 | 用途 | 超时处理 |
|---|---|---|---|
| T3 | 45秒 | 等待回复超时（Reply Timeout） | 重发或上报错误 |
| T5 | 10秒 | 连接建立超时（Connect Timeout） | 重试连接或切换IP |
| T6 | 5秒 | 控制消息超时（Control Timeout） | 关闭连接 |
| T7 | 10秒 | 连接空闲超时（Not Selected Timeout） | 关闭TCP连接 |
| T8 | 5秒 | 链路测试间隔（Linktest Interval） | 发送Linktest.req |
3.6.2 超时状态机
3.6.3 超时配置工程建议
- T3 (Reply Timeout)： 根据设备处理能力调整。复杂设备（如刻蚀机）可能需要更长的超时时间（60-90秒）。
- T6 (Control Timeout)： 应小于T3，确保控制消息快速失败。建议设置为3-5秒。
- T8 (Linktest Interval)： 用于检测死连接。在稳定的有线网络中可设置为10-15秒；在无线或不稳定网络中建议缩短至5秒。
- 重试策略： 超时后应进行有限次重试（通常3次），避免无限重试导致资源耗尽。
⚠ 关键避坑： 很多集成问题源于超时配置不当。例如，T3设置过短会导致正常慢速设备被误判为故障；T8设置过长会导致死连接长时间未被发现，影响产线整体稳定性。建议在设备验收测试中专门进行超时边界测试。
3.7 本章小结
HSMS作为SECS/GEM的传输层协议，其核心机制包括：
- TCP/IP基础： 依赖TCP的可靠传输，但需自行处理消息边界。
- 会话管理： 通过Select/Deselect消息建立和断开会话，状态机清晰。
- 连接模式： 主动模式适合设备主动上报，被动模式适合主机集中管理。
- 消息封装： 10字节固定头+可变体，Length字段是粘包处理的关键。
- 超时管理： T3/T5/T6/T7/T8五个定时器共同保障通信健壮性。