📚 课程目录第3章 HSMS通信协议详解

3. HSMS 通信协议详解

HSMS（High-Speed SECS Message Services）是 SEMI E37 标准定义的 TCP/IP 承载层协议，负责在主机与设备之间建立可靠的双向连接，并在此连接上传输 SECS-II 消息。本章深入剖析 HSMS 的连接建立与断开、会话管理、链路测试（Linktest）、消息传输与重传机制，为后续协议栈移植提供底层通信基础。

3.1 HSMS 连接建立与断开

HSMS 使用 TCP 作为传输层，默认端口号 5000。连接建立遵循“主动方（Active）”与“被动方（Passive）”角色模型。主动方发起 TCP 连接，被动方监听等待连接。连接建立后，双方通过 Select.req / Select.rsp 消息完成会话初始化。

3.1.1 连接建立流程

TCP 三次握手：主动方（通常是主机）向被动方（设备）发起 TCP 连接。
Select.req 发送：主动方发送 Select.req 消息，携带设备 ID 和会话 ID。
Select.rsp 响应：被动方验证设备 ID 后，回复 Select.rsp，状态码为 0（成功）或非 0（失败）。
连接就绪：双方进入“已连接”状态，可以开始传输 SECS-II 消息。

  关键参数： Select.req 中的 DEVICE_ID 必须与设备配置一致，否则连接被拒绝。

实践建议： 在嵌入式系统中，建议将 Select.req 超时设置为 10 秒，避免因网络延迟导致连接失败。

3.1.2 连接断开流程

连接断开分为 正常断开 和 异常断开 两种场景。正常断开由应用层发起，通过 Deselect.req / Deselect.rsp 消息完成；异常断开由 TCP 连接中断或超时触发。

断开类型	触发条件	消息序列	状态处理
正常断开	应用层主动关闭	Deselect.req → Deselect.rsp → TCP FIN	释放会话资源，进入空闲状态
异常断开	TCP 连接中断 / 超时	无消息，直接检测到 TCP 关闭	启动重连定时器，尝试重新建立连接

注意： 异常断开后，设备必须等待 T5 定时器超时（默认 10 秒）才能重新接受连接，防止连接风暴。

3.2 会话管理

HSMS 会话管理基于 会话 ID（Session ID） 和 设备 ID（Device ID） 进行标识。每个 TCP 连接可以承载多个会话，但实际应用中通常采用“一个连接一个会话”的简化模型。

3.2.1 会话状态机

HSMS 会话状态机包含以下状态：

NOT_SELECTED：TCP 已连接，但未完成 Select 握手。
SELECTED：Select 握手成功，可以传输数据。
NOT_CONNECTED：TCP 连接已断开。

3.2.2 会话超时参数

定时器	默认值	用途
T3	45 秒	等待回复超时（Reply Timeout）
T5	10 秒	连接分离超时（Connect Separation Timeout）
T6	5 秒	等待 Select.rsp 超时
T7	10 秒	等待 Linktest.rsp 超时

3.3 链路测试（Linktest）

Linktest 是 HSMS 的保活机制，用于检测 TCP 连接是否仍然有效。设备或主机可以主动发送 Linktest.req 消息，对方必须在 T7 超时内回复 Linktest.rsp。

3.3.1 Linktest 触发条件

空闲超时：当连接空闲时间超过 T6（默认 5 秒）时，主动方发送 Linktest.req。
周期性保活：某些实现会以固定间隔（如 10 秒）发送 Linktest，确保连接健康。

3.3.2 Linktest 消息格式

Linktest.req:
  Message Length: 10 bytes
  Session ID: 0xFFFF (广播)
  Header Byte 2: 0x00
  Header Byte 3: 0x00
  Stream: 0x00
  Function: 0x00
  PType: 0x00 (Data Message)
  SType: 0x09 (Linktest.req)

Linktest.rsp:
  Message Length: 10 bytes
  Session ID: 0xFFFF
  Header Byte 2: 0x00
  Header Byte 3: 0x00
  Stream: 0x00
  Function: 0x00
  PType: 0x00
  SType: 0x0A (Linktest.rsp)

  注意： Linktest 消息的 Session ID 固定为 0xFFFF，表示广播给所有会话。

3.4 消息传输与重传机制

HSMS 消息传输基于 TCP 的可靠传输，但应用层仍需处理 消息确认 和重传逻辑。SECS-II 消息通过 HSMS 封装后，以 Message ID 唯一标识，接收方必须回复确认消息。

3.4.1 消息传输流程

发送方：构造 SECS-II 消息，封装为 HSMS 数据消息（PType=0, SType=0），通过 TCP 发送。
接收方：解析 HSMS 头部，提取 SECS-II 消息，处理业务逻辑。
回复：接收方发送对应的 SECS-II 回复消息（如 S1F2），携带相同的 Message ID。

3.4.2 重传机制

当发送方在 T3 超时（默认 45 秒）内未收到回复，触发重传。重传策略如下：

重传次数	等待时间	动作
第 1 次	T3 (45s)	重新发送原消息
第 2 次	T3 × 2 (90s)	重新发送原消息
第 3 次	T3 × 4 (180s)	重新发送原消息
超过 3 次	—	断开连接，报告错误

重要： 重传时 Message ID 必须保持不变，否则接收方无法识别为同一消息，可能导致重复处理。

3.4.3 消息传输状态机

3.5 本章小结

HSMS 协议是 SECS/GEM 通信的基石，其连接管理、会话控制、链路测试和重传机制共同保证了半导体设备与主机之间稳定、可靠的数据交换。在嵌入式系统移植时，需重点关注：

定时器配置：T3、T5、T6、T7 必须根据实际网络环境调整。
状态机实现：严格遵循 NOT_CONNECTED → NOT_SELECTED → SELECTED 状态转换。
重传策略：避免无限重传，设置最大重传次数（通常为 3 次）。