1. 课程导入与故障诊断全景

SECS/GEM 是半导体与泛半导体设备与工厂主机（Host）之间最通用的通信标准。其中 HSMS（High-Speed SECS Message Services）负责在 TCP/IP 之上承载 SECS-II 消息，是设备联网、远程控制、数据采集与配方管理的基础通道。一旦 HSMS 连接建立失败或中途断开，设备在 Host 侧就会表现为“离线”“不可选”“无法下发配方”，产线因此停线。本课程的目标，是让学员具备从“现象”到“根因”的完整诊断能力，并能独立完成通信调试。

学习目标可以归纳为三层：第一层是看懂连接，理解 HSMS 的连接状态机、被动/主动模式、端口与设备 ID 的约定；第二层是定位故障，能根据日志、抓包和状态码判断问题出在网络、配置、状态机还是消息层；第三层是完成调试，能使用工具链验证链路、模拟 Host、复现并修复典型故障。

核心对象与角色

HSMS 通信涉及几个必须分清的对象：设备端（Equipment）运行 SECS/GEM 驱动，通常作为被动方监听端口；主机端（Host）主动发起连接；中间网络包括交换机、防火墙、网关；消息层承载 SECS-II 的 SxFy 消息与 HSMS 控制消息（如 Select、Deselect、Linktest）。诊断时必须先确定“谁主动、谁监听、连到哪个 IP 和端口”，否则后续所有判断都会失去基准。

典型故障场景

实际产线中，HSMS 连接故障高度集中在以下几类：

• 连接根本建立不起来：TCP 三次握手失败，常见于 IP/端口填错、防火墙拦截、设备未启动监听。
• TCP 通了但 HSMS 选不中：TCP 已连接，但 Select 请求无响应或返回拒绝，常见于设备 ID 不匹配、状态机卡在 Not Selected。
• 连接频繁闪断：T5、T6、T7、T8 等超时参数设置不当，或 Linktest 未启用导致死连接无法被察觉。
• 消息能发不能回：S1F1 能发出但收不到 S1F2，常见于消息层解析错误、W-bit 与事务 ID 处理异常。
• 偶发性通信异常：网络抖动、双网卡路由冲突、NAT 导致源端口变化。

这些场景的排查顺序并非随意。合理的做法是自下而上：先确认物理与网络可达，再确认 TCP 连接，再确认 HSMS 状态机，最后才进入 SECS-II 消息层。跳过底层直接查消息，往往会在错误的方向上耗费大量时间。

诊断流程框架

下面这张图给出了 HSMS 连接故障诊断的整体框架：从现象出发，沿“网络层 → 传输层 → HSMS 状态层 → 消息层”逐层收敛，每一层都有对应的观察点和判断依据。图中同时标出了各层常用的调试工具，便于在实际排障时快速选择手段。

调试工具链概览

工具的选择与故障层级直接对应。网络层用 ping、telnet、tracert 快速判断可达性；传输层用 Wireshark 抓包，重点看三次握手与 RST 包；HSMS 状态层依赖设备端或 Host 端的连接日志，观察 Select 交互与状态迁移；消息层则用 SECS 模拟器（如模拟 Host 或模拟设备）主动构造 S1F1、S1F13 等消息进行验证。

需要强调的是，抓包是贯穿全层的核心手段。一次完整的 Wireshark 抓包可以同时看到 TCP 握手、HSMS Select 控制消息和 SECS-II 数据消息，是定位“到底卡在哪一层”的最直接证据。建议在排障开始时就同步开启抓包，而不是等到怀疑网络时才补抓。

关键超时参数速查

HSMS 定义了若干超时定时器，理解它们是判断“闪断”和“假连接”的基础。下表列出最常用的几个参数及其典型含义，具体数值应以设备与 Host 双方约定为准。