HSMS（E37）通信层的正确实现方式

——写给正在做国产半导体设备通信接口的研发工程师

系列文章目录

1. 《SECS/GEM 协议介绍》
2. 《HSMS（E37）通信层的正确实现方式》
3. 《SECS-II 报文结构：工程师最容易犯的 10 个错误》
4. 《GEM 事件/报警系统的完整实现》
5. 《GEM300（E87/E90/E94）流程详解：Carrier → Job → Recipe》
6. 《国产设备厂 SECS/GEM 接口常见问题与调试案例》
7. 《如何设计一个可扩展的 SECS/GEM 驱动程序》
8. 《如何用流程化工具做 Host/EAP 验收》
    

目录

系列文章目录

1. HSMS 的本质是什么？

2. HSMS 的连接流程（工程师能理解的版本）

3. HSMS 的 5 个超时（T3/T5/T6/T7/T8）到底怎么用？

4. HSMS 的线程模型（工程师必须搞清楚）

5. HSMS 报文结构（工程师最容易犯的错误）

6. HSMS 的异常恢复机制

7. 一个真实调试案例：为什么设备“偶尔掉线”？

8. 工程师应该如何正确实现 HSMS？

9. 成熟方案供应商选择

总结

前言

如果你正在做 SECS/GEM，那么你一定绕不开 HSMS（High-Speed SECS Message Services）。 它是整个协议栈的最底层，负责：

• 建立 TCP 连接

• 维持心跳

• 管理超时

• 发送/接收报文

• 保证通信稳定性

一句话：

HSMS 是 SECS/GEM 的地基。地基不稳，楼再高也会塌。

这篇文章我会从工程实践的角度，讲清楚 HSMS 的正确实现方式，以及国产设备厂最容易踩的坑。

Note： 严谨的说，地基是TCP，而HSMS则是跑在TCP上的应用，考虑到TCP属于系统内核层已经封装好的对象，我们为了方便理解HSMS，所以将HSMS理解为SECS/GEM的地基。

1. HSMS 的本质是什么？

很多人把 HSMS 当成“TCP + 报文头”，但这只是表面。从工程角度看，HSMS 是一个带状态机的通信框架，包含：

• 连接状态机

• 选择（Select）握手

• 心跳（Linktest）

• 超时管理（T3/T5/T6/T7/T8）

• 报文收发

• 异常恢复

它不是“发包收包”这么简单，而是一个完整的通信生命周期管理。这里的详细信息需要读者自行查阅SEMI E37标准文档。文档中详细介绍了HSMS的状态机切换逻辑。

2. HSMS 的连接流程（工程师能理解的版本）

下面是一个典型的 HSMS Active 模式连接流程：

TCP Connect
   ↓
Select.req
   ↓
Select.rsp
   ↓
Linktest（周期性）
   ↓
正常通信（SxFy）

Passive 模式则是：

等待 TCP
   ↓
收到 Select.req
   ↓
回复 Select.rsp
   ↓
Linktest
   ↓
正常通信

注意：Select 是 HSMS 的“握手”，不是可选项。这在E37中会详细描述报文结构。

3. HSMS 的 5 个超时（T3/T5/T6/T7/T8）到底怎么用？

这是国产设备厂最容易搞错的地方。

4. HSMS 的线程模型（工程师必须搞清楚）

一个稳定的 HSMS 实现，至少需要：

① 接收线程（Receive Thread）

• 负责从 TCP 读取数据

• 负责粘包/拆包

• 负责解析报文头

② 发送线程（Send Thread）

• 负责发送队列

• 负责重试

• 负责超时管理

③ 心跳线程（Linktest Thread）

• 定时发送 Linktest.req

• 检测对端是否存活

④ 状态机线程（State Machine Thread）

• 管理 Select

• 管理超时

• 管理异常恢复

如果你把所有逻辑塞进一个线程，通信不稳定。

5. HSMS 报文结构（工程师最容易犯的错误）

关于HSMS报文头格式，网上一堆，我就不展开了，只说几个避坑点：

HSMS 报文头固定 10 字节

常见错误：

• Message Length 不包含前 4 字节

• SystemBytes 不唯一（重点标记，这个是跟SessionID相关的，请仔细读E37）

• Stream/Function 错误（要按位取到具体值，请看E37文档）

• 报文体 List 结构错误

提供以下截图，各位看官老爷 可自行抓包后理解HSMS头封装。

6. HSMS 的异常恢复机制

一个成熟的 HSMS 实现必须具备：

① 自动重连

TCP 断开 → 等待 T5 → 自动重连

② 自动重新 Select

连接成功 → 自动发送 Select.req

③ 自动心跳检测

Linktest 超时 → 断开 → 重连

④ 自动清理未完成事务

T3 超时 → 清理命令队列

⑤ 自动恢复状态机

恢复到“Selected”状态

如果没有这些机制，设备在 Fab 环境里会频繁掉线。

7. 一个真实调试案例：为什么设备“偶尔掉线”？

某国产设备在客户现场出现“偶尔掉线”，抓包后发现：

• Host 发 Linktest.req

• 设备没有回复

• Host 等待 T6 超时

• Host 主动断开连接

• 设备端日志显示“对端异常断开”

根因：

• 设备端心跳线程被阻塞

• 导致 Linktest.rsp 无法及时发送

解决方案：

• 心跳线程必须独立

• 不得被业务逻辑阻塞

• 发送队列必须无锁或轻量锁

这是 HSMS 最典型的工程问题。

8. 工程师应该如何正确实现 HSMS？

一个最实用的建议：

把 HSMS 当成一个“通信框架”，而不是“发包收包”。 它必须有状态机、线程模型、超时管理、异常恢复。

如果你做到以下几点，HSMS 就会非常稳定：

• 独立线程模型

• 完整的超时管理

• 完整的 Select 流程

• 完整的心跳机制

• 完整的异常恢复

• 完整的报文解析器

• 完整的命令队列

9. 成熟方案供应商选择

对于半导体设备的软件研发团队来说，如果希望将主要精力放在

• 设备工艺逻辑

• 上下位机控制

• 核心算法上

那么 SECS/GEM 这一层完全具备外采的条件。

从工程角度看，SECS/GEM 本质上是“设备功能之上的调度层”，它需要稳定的协议栈、完整的状态机、规范的事件/报警系统以及 GEM300 的流程调度能力。这些内容既专业又繁琐，自己从零实现不仅周期长，还容易在验收阶段暴露兼容性问题。因此，选择成熟可靠的 SECS/GEM 组件，可以显著降低研发成本，加快设备上线节奏。

我们团队(ModuleMotion Systems)长期深耕这一领域，也有稳定落地的方案，如有需要可以私信交流。

总结

以上内容只是对 HSMS协议的一个整体性介绍，更多细节在 SEMI 的标准文档中都有非常严格的定义。如果立项自研，HSMS建议大家按照通讯框架来实现，千万不要当作一个收发数据包的接口。HSMS不标准后期的改动会影响到上层实现。

SEMI标准本身并不难，难的是如何在真实设备中把它“工程化”——包括协议栈稳定性、事件系统一致性、GEM300 流程完整性、Host/EAP 验收效率等。后续文章我会结合实际项目经验，继续拆解这些模块的工程实现方式。