📚 课程目录第4章接口协议基础

4. 接口协议基础

说到半导体设备的通信协议，很多刚入行的工程师会觉得头大。一堆缩写，什么SECS、GEM、HSMS，看着就晕。其实没那么复杂，说白了就是设备跟工厂上位机之间怎么“说话”的问题。

我刚开始接触这行的时候，也觉得这些协议很神秘。后来在产线上蹲了几个月，跟着老工程师调机，才慢慢摸到门道。今天我就把这几层协议的关系和实际应用，给你捋清楚。

4.1 协议栈的整体架构

先看一张图，你就明白这几层协议是怎么叠在一起的。

你看，从上到下分四层。最上面是GEM，定义设备该有什么行为。中间是SECS-II，规定消息怎么写。下面是HSMS，负责把消息打包发出去。最底下是TCP/IP，干的是网络传输的苦活。

我习惯把GEM比作“规矩”，SECS-II比作“语法”，HSMS比作“信封”，TCP/IP比作“邮局”。这样一想，是不是清楚多了？

4.2 SECS/GEM 到底是什么

SECS是SEMI标准里的一套通信协议族。全称是SEMI Equipment Communications Standard。GEM是它的应用层规范，全称Generic Equipment Model。

你想想看，如果每家设备厂商都用自己的私有协议，工厂的MES（制造执行系统）得适配多少种接口？那不乱套了。SECS/GEM就是为了解决这个问题，让所有设备用同一种“语言”跟工厂系统对话。

4.2.1 SECS-II 消息格式

SECS-II定义的消息，核心是SML格式。SML全称是SECS Message Language。一个典型的SECS-II消息长这样：

S1F1 W
S1F2
<L>
  <A>MDXX-001</A>
  <A>REV-3.2</A>
  <A>S/N-2024-001</A>
</L>
.

这里S1F1是Stream 1 Function 1，W表示等待回复。S1F2是回复消息。里面的<L>是列表，<A>是ASCII字符串。这套格式看着简单，但实际用起来坑不少。

我的经验：调试SECS-II消息时，最容易出问题的是数据类型不匹配。比如设备发了个<U4>（无符号4字节整数），上位机却按<I4>（有符号4字节整数）解析，结果就是负数。我遇到过好几次这种问题，排查起来特别费时间。建议你在设计阶段就把数据类型表定死，双方签字确认。

4.2.2 GEM 核心模型

GEM定义了设备必须支持的一组能力。主要包括：

设备状态机：设备有INIT、IDLE、PROCESSING、ALARM等状态，状态切换有严格规则
报警管理：设备发生异常时，通过报警消息通知上位机
事件通知：设备状态变化、物料到位等事件，主动上报
配方管理：上位机可以下载、上传、切换配方
数据收集：按周期或事件触发，采集工艺参数

我参与过一个项目，设备的状态机没按GEM标准来，结果上位机总是收不到正确的状态切换通知。后来查了三天，发现是设备在PROCESSING完成后直接跳到了INIT，跳过了IDLE状态。GEM标准里明确要求必须经过IDLE。这就是不守规矩的代价。

4.3 HSMS：高速SECS消息服务

HSMS是SECS在TCP/IP上的传输实现。它替代了早期的RS-232串口SECS，把通信速度从9600波特率提升到了千兆以太网级别。

4.3.1 HSMS 会话管理

HSMS定义了两种角色：主动方（Active）和被动方（Passive）。设备通常作为被动方，上位机作为主动方。连接建立的过程是这样的：

被动方（设备）在指定端口监听，等待连接
主动方（上位机）发起TCP连接请求
连接建立后，主动方发送Select.req消息
被动方回复Select.rsp，确认会话建立
双方开始正常通信

注意：我曾经遇到过一个问题，设备作为被动方，但上位机主动断开连接后，设备没有及时释放端口资源。结果端口被占满，新连接进不来。后来我们在设备端加了心跳检测和超时重连机制，才彻底解决。建议你在设计时一定要考虑连接异常后的恢复逻辑。

4.3.2 HSMS 消息帧格式

HSMS在TCP数据流中，用固定的帧头来分割消息。一个HSMS消息帧包含：

字段	长度（字节）	说明
消息长度	4	后续数据的总长度（不包括这4字节）
Stream编号	1	消息类别，如S1、S2、S6等
Function编号	1	具体功能号，如F1、F2
W位	1	是否需要回复（0=不需要，1=需要）
系统字节	4	消息ID，用于匹配请求和回复
消息体	可变	SECS-II格式的数据内容

这个帧头设计很巧妙。系统字节用来匹配请求和回复，这样上位机可以同时发送多条消息，不用等一条回复再发下一条。说白了就是支持并发通信。

4.4 TCP/IP 在半导体设备中的特殊要求

TCP/IP本身是通用协议，但在半导体设备场景下，有几个特殊要求需要注意。

4.4.1 网络稳定性

半导体产线对网络稳定性要求极高。设备通信中断哪怕几秒钟，都可能导致批次报废。我见过一个案例，产线交换机的STP（生成树协议）触发了一次拓扑变更，导致设备断连了3秒，结果整批晶圆报废，损失几十万。

所以，半导体设备的网络设计有几个原则：

使用独立的管理型交换机，不跟办公网络混用
配置端口快速收敛（PortFast），避免STP延迟
设备端和上位机端都配置静态IP，不用DHCP
网线用工业级屏蔽双绞线，避免电磁干扰

4.4.2 端口和连接数

HSMS默认使用TCP端口5000。但实际项目中，一台设备可能同时跟多个上位机通信。比如设备既要跟MES通信，又要跟EAP（设备自动化平台）通信，还要跟RMS（配方管理系统）通信。

我建议的做法是：设备作为被动方，监听一个固定端口。上位机作为主动方，各自建立独立的TCP连接。设备端需要支持多连接管理，每个连接独立处理消息。

  关键点：多连接场景下，消息的路由要清晰。每条消息必须携带设备ID或连接标识，上位机才能知道这条消息来自哪台设备。我曾经见过一个系统，两台设备用了相同的系统字节，结果消息串了，A设备的数据跑到了B设备的界面上。排查了整整两天才找到原因。

4.5 实际集成测试中的常见问题

说了这么多理论，来点实际的。我在集成测试中遇到过的问题，列几个典型的：

消息超时：设备处理慢，上位机等不及就超时了。解决办法是调整T3超时时间（HSMS的回复等待超时），一般设成45秒比较合理
数据字节序：有些设备用大端，有些用小端，解析出来的数据完全不对。必须在协议文档里明确字节序
心跳丢失：HSMS有链路测试消息（Link Test），如果连续几次心跳没收到，连接会被断开。网络稍微抖动一下就可能触发
消息粘包：TCP是流式协议，多条消息可能粘在一起。接收端必须按帧头长度字段正确分割

避坑指南：我曾经在测试中发现，设备发送的消息长度字段算错了，多算了4字节。结果上位机解析时，把下一条消息的头4字节当成上一条消息的尾巴，整个解析全乱套了。后来我们在测试用例里专门加了一条：验证消息长度字段是否准确。这个用例后来成了我们的标准测试项。

4.6 小结

SECS/GEM、HSMS、TCP/IP这三层协议，是半导体设备通信的基石。GEM定规矩，SECS-II定语法，HSMS负责打包传输，TCP/IP提供网络通道。每一层都有它的职责，也都有它的坑。

做集成测试的时候，我的习惯是先从底层往上测。先确认TCP/IP能通，再测HSMS会话建立，然后验证SECS-II消息收发，最后测GEM的业务逻辑。一层一层往上走，问题出在哪一层，一眼就能看出来。

嗯，这些协议看着复杂，但只要你亲手调通过一次，后面就顺了。多踩几个坑，经验就攒起来了。