2. HSMS通信基础:HSMS协议定义、TCP/IP连接建立、会话管理与心跳机制
2.1 HSMS协议定义与协议栈定位
HSMS(High-Speed SECS Message Services)是SEMI标准E37定义的通信协议,它替代了传统的RS-232串行通信方式,将SECS-II消息承载于TCP/IP网络之上。HSMS并非独立的应用层协议,而是SECS/GEM协议栈中负责传输层与网络层适配的关键中间层。
核心定位:HSMS将SECS-II的Message ID、System Bytes、Data等结构化数据封装为TCP报文段,通过标准Socket接口实现设备(Equipment)与主机(Host)之间的可靠、高速、双向通信。
HSMS协议栈在SECS/GEM体系中的位置如下表所示:
| OSI层 | SECS/GEM协议组件 | HSMS职责 |
|---|---|---|
| 应用层 | GEM (E30) / SECS-II (E5) | 定义设备状态模型、事件报告、远程命令 |
| 表示层 | SECS-II (E5) | 消息编码(SML/二进制)、Item格式 |
| 会话层 | HSMS (E37) | 连接建立/释放、会话管理、心跳保活 |
| 传输层 | HSMS (E37) | 消息分帧、长度前缀、重传控制 |
| 网络层 | TCP/IP | IP寻址、路由、可靠字节流传输 |
| 数据链路层 | 以太网 | MAC帧封装、物理介质访问 |
关键概念:HSMS不负责SECS-II消息的语义解析,它只保证消息字节流在TCP连接上完整、有序、不重复地到达对端。语义解析由上层SECS-II/GEM模块完成。
2.2 TCP/IP连接建立:主动连接与被动监听
HSMS定义了两种通信实体角色:主动方(Active)和被动方(Passive)。主动方发起TCP连接请求,被动方监听并接受连接。在半导体工厂自动化场景中,通常Host作为被动方(监听端口),Equipment作为主动方(发起连接)。
2.2.1 连接建立流程
- 被动方启动监听:Host在指定端口(默认5000)上调用
listen(),等待Equipment连接。 - 主动方发起连接:Equipment通过
connect()向Host的IP:Port发起TCP三次握手。 - TCP连接就绪:三次握手完成后,双方Socket进入
ESTABLISHED状态。 - HSMS会话初始化:TCP连接建立后,Equipment发送
Select.req消息,Host回复Select.rsp,完成HSMS会话激活。
常见陷阱:TCP连接建立成功 ≠ HSMS会话可用。必须等待
Select.req/rsp握手完成后,才能开始传输SECS-II消息。部分设备在TCP连接后立即发送数据,会导致Host端协议解析异常。
2.2.2 连接参数配置
| 参数 | 默认值 | 说明 |
|---|---|---|
| 端口号 | 5000 | SEMI标准推荐端口,可自定义 |
| 连接超时 | 10秒 | 主动方等待TCP连接建立的最大时间 |
| 重连间隔 | 15秒 | 连接断开后自动重连的等待时间 |
| 最大重连次数 | 无限制 | 通常持续重连直到成功或手动停止 |
2.3 会话管理:状态机与消息类型
HSMS会话管理基于有限状态机(FSM)模型,定义了5种会话状态和6种控制消息。状态机确保通信双方在连接建立、数据传输、连接释放等阶段的行为一致。
2.3.1 会话状态定义
| 状态 | 名称 | 说明 |
|---|---|---|
| 1 | NOT CONNECTED | TCP连接未建立,无任何通信 |
| 2 | CONNECTED | TCP连接已建立,但HSMS会话未激活 |
| 3 | SELECTED | HSMS会话激活,可传输SECS-II数据消息 |
| 4 | NOT SELECTED | TCP连接存在,但会话被对方取消选择 |
| 5 | WAIT | 等待对方响应Select.req或Deselect.req |
2.3.2 控制消息类型
- Select.req / Select.rsp:激活HSMS会话。Equipment发送Select.req,Host回复Select.rsp(成功/失败)。
- Deselect.req / Deselect.rsp:释放HSMS会话。任一方可发起,成功后状态回到CONNECTED。
- Linktest.req / Linktest.rsp:心跳检测。用于验证TCP连接和会话是否仍然存活。
- Separate.req:分离通知。通知对端即将关闭连接,无需回复。
最佳实践:在SELECTED状态下,Equipment应定期发送
Linktest.req(默认间隔30秒),Host必须在T3超时(默认45秒)内回复Linktest.rsp。连续3次心跳超时,应主动关闭TCP连接并触发重连。
2.4 心跳机制:Linktest协议与超时处理
心跳机制是HSMS保证通信链路健康的核心手段。通过定期交换Linktest.req和Linktest.rsp消息,双方可以检测TCP连接是否仍然有效,以及对方协议栈是否正常运行。
2.4.1 心跳参数
| 参数 | 符号 | 默认值 | 说明 |
|---|---|---|---|
| 心跳发送间隔 | T5 | 30秒 | Equipment发送Linktest.req的周期 |
| 心跳响应超时 | T3 | 45秒 | 等待Linktest.rsp的最大时间 |
| 最大重试次数 | — | 3次 | 连续超时次数达到阈值后断开连接 |
2.4.2 心跳处理流程
- Equipment启动定时器T5,每30秒触发一次Linktest.req发送。
- Equipment发送Linktest.req后,启动T3超时计时器。
- Host收到Linktest.req后,立即回复Linktest.rsp。
- Equipment收到Linktest.rsp,重置T3计时器,继续等待下一个T5周期。
- 若T3超时未收到回复,Equipment重发Linktest.req,重试计数器+1。
- 连续3次T3超时,Equipment判定连接失效,关闭TCP连接并进入NOT CONNECTED状态。
工程经验:在MES与设备集成调试阶段,建议将T5临时缩短至10秒、T3缩短至15秒,以便快速验证心跳交互是否正常。上线运行后再恢复为标准值。
2.4.3 心跳消息格式
Linktest消息使用HSMS控制消息格式,消息头长度为10字节,不携带数据体:
字节偏移 字段 长度(字节) 说明
0-1 消息长度 2 固定为0x000A (10字节头长度)
2-3 Session ID 2 0xFFFF (控制消息专用)
4 消息类型 1 0x05 (Linktest.req) / 0x06 (Linktest.rsp)
5 保留 1 0x00
6-9 System Bytes 4 递增的会话序列号
注意:Session ID在控制消息中固定为0xFFFF。数据消息(SECS-II)的Session ID由Select握手时协商分配,通常从0x0001开始递增。
2.5 消息分帧与长度前缀
HSMS在TCP字节流之上定义了消息分帧机制,解决TCP粘包/拆包问题。每个HSMS消息包含一个4字节长度前缀(Message Length),后跟10字节消息头和可选的数据体。
2.5.1 消息帧结构
| 字段 | 长度 | 说明 |
|---|---|---|
| Message Length | 4字节 | 后续消息头+数据体的总长度(大端序) |
| Message Header | 10字节 | 包含Session ID、消息类型、System Bytes等 |
| Data Body | 0~N字节 | SECS-II编码后的数据(控制消息无此字段) |
2.5.2 消息头字段详解
字节偏移 字段 长度(字节) 说明
0-1 Session ID 2 数据消息: 设备ID; 控制消息: 0xFFFF
2 消息类型 1 0x00=数据消息; 0x01~0x06=控制消息
3 保留 1 0x00
4-5 S/F 2 Stream/Function编码 (仅数据消息)
6-9 System Bytes 4 消息序列号,用于请求-响应匹配
解析要点:接收方从TCP缓冲区读取4字节得到Message Length,再根据该长度读取完整的消息帧。如果Message Length为0x0000000A,表示只有10字节消息头,无数据体(控制消息场景)。