第三章 设备互联与数据采集：SECS/GEM协议详解、设备联网方案、边缘计算网关部署
各位工程师，咱们直接进入正题。
晶圆厂搞数字化，第一步是什么？不是上MES，不是搞大数据。是把设备连起来，把数据采上来。设备不联网，后面全是空谈。这一章，我就把设备互联这件事儿，从协议到方案，再到落地部署，掰开了讲清楚。
3.1 SECS/GEM协议：半导体设备的通用语言
先说说SECS/GEM。这玩意儿，说白了就是半导体设备之间、设备和上位系统之间沟通的“普通话”。
我刚开始接触这行时，觉得这协议太古老了，怎么还在用？后来吃过亏才明白，稳定可靠才是工业现场的第一要义。SECS/GEM虽然看着笨重，但它在半导体行业扎根了几十年，所有主流设备都支持。
3.1.1 协议栈结构
SECS/GEM不是一个协议，是一组协议。从上到下分几层：
- SECS-I (E4)：物理层和链路层。早期用RS-232，现在基本都是TCP/IP了。
- SECS-II (E5)：消息层。定义了消息的格式和内容，比如“设备状态报告”、“配方下载”这些。
- GEM (E30/E37)：应用层。定义了设备的行为模型，比如设备该在什么时候主动上报数据。
嗯，这里要注意。很多人把SECS和GEM混着叫，其实不对。SECS是通信协议，GEM是设备行为标准。你设备支持GEM，才算是真正意义上的“可互联”。
3.1.2 核心概念：HSMS与SECS-II消息
现在工厂里，设备互联基本都用HSMS（High-Speed SECS Message Services）。说白了，就是把SECS消息封装在TCP/IP包里传。
我给大家看一段典型的SECS-II消息结构，用Python模拟一下：
# 模拟一个SECS-II消息：设备状态数据上报 (S1F1)
# Stream 1, Function 1: Are You There Request
secs_message = {
"header": {
"stream": 1,
"function": 1,
"direction": "host_to_eqp", # 主机到设备
"block": 0,
"system_bytes": 0x0001
},
"body": None # 空body，表示询问
}
# 设备回复 S1F2: 设备在线
secs_reply = {
"header": {
"stream": 1,
"function": 2,
"direction": "eqp_to_host",
"block": 0,
"system_bytes": 0x0001
},
"body": {
"mdln": "ASML NXT:1980Di", # 设备型号
"softrev": "3.2.1" # 软件版本
}
}
你看，结构很清晰。Stream和Function组合起来，就定义了一条指令。S1F1就是“你在吗？”，S1F2就是“我在，这是我的型号”。
3.2 设备联网方案：从单机到互联
协议讲完了，咱们聊聊怎么把设备真正连起来。工厂里的设备五花八门，新设备、老设备、进口的、国产的，联网方案不能一刀切。
3.2.1 新设备：原生SECS/GEM支持
现在的新设备，尤其是200mm、300mm产线上的，基本都自带SECS/GEM接口。你只需要：
- 跟设备厂商确认支持的协议版本（E5、E30、E37）。
- 配置IP地址和端口号（通常是5000或5001）。
- 联调测试，确认数据能正常收发。
我建议，新设备到厂验收时，就把SECS联调作为一项必测项。别等到上线了才发现通信有问题，那时候再改就麻烦了。
3.2.2 老设备：加装协议转换器
老设备就头疼了。很多只有干接点、RS-232串口，甚至只有指示灯。怎么办？加装协议转换器。
市面上有专门的SECS/GEM网关盒子，一头接设备的串口或IO，另一头输出标准的SECS/GEM协议。我见过最极端的案例，是一台90年代的扩散炉，只有几个继电器触点。我们硬是加了个PLC，把触点信号转成Modbus，再用网关转成SECS/GEM。虽然绕了点，但数据总算是采上来了。
3.2.3 联网拓扑：星型还是链型？
设备多了，网络拓扑就得规划。我个人习惯用星型拓扑，每台设备单独拉网线到车间交换机。虽然布线成本高一点，但故障隔离性好。一台设备网线松了，不影响其他设备。
链型拓扑（菊花链）虽然省线，但一个节点断了，后面一串都断。除非是空间极度受限的机台，否则我不推荐。
3.3 边缘计算网关部署：数据的第一道处理站
数据采上来了，直接往云端或MES送？别急。数据量太大，网络带宽扛不住，而且很多数据需要实时处理。这时候，就需要边缘计算网关。
3.3.1 网关的核心功能
边缘网关不是简单的协议转换器。它要做三件事：
- 数据采集：从设备收数据，支持SECS/GEM、Modbus、OPC UA等多种协议。
- 数据预处理：过滤掉无效数据，做简单的计算（比如求平均值、统计良率）。
- 数据转发：把处理后的数据，用MQTT、HTTP等方式，发给上层系统。
你想想看，一台光刻机每秒产生几百条数据，全传上去，服务器不崩才怪。在网关里做一层过滤，只传关键数据，这才是聪明的做法。
3.3.2 部署架构：一拖多 vs 一对一
网关部署有两种模式：
| 模式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 一拖多（1个网关管多台设备） | 同类型设备集中区域 | 成本低，管理方便 | 单点故障风险高 |
| 一对一（每台设备配1个网关） | 关键设备、高价值设备 | 故障隔离，性能有保障 | 成本高，部署工作量大 |
我个人建议，关键设备（光刻机、刻蚀机）用一对一模式。辅助设备（清洗机、烘箱）可以用一拖多。平衡成本和可靠性。
3.3.3 实战：用Node-RED搭建一个简单的边缘网关
这里我给大家演示一个轻量级的方案。用Node-RED，配合SECS/GEM插件，几分钟就能搭一个原型。
// Node-RED 流程示例：接收SECS消息，过滤后转发到MQTT
// 1. 输入节点：SECS/GEM Listener (监听设备消息)
// 2. 函数节点：数据过滤 (只保留状态变化的数据)
// 3. 输出节点：MQTT Out (发布到broker)
// 函数节点代码示例 (JavaScript)
let msg = context.get('lastMsg') || {};
let currentData = msg.payload;
// 如果数据没有变化，丢弃
if (currentData.status === msg.lastStatus) {
return null; // 返回null表示丢弃消息
}
// 更新缓存
msg.lastStatus = currentData.status;
context.set('lastMsg', msg);
// 添加时间戳
currentData.timestamp = Date.now();
return { payload: currentData };
你看，逻辑很简单。收到设备状态，跟上次比一下。没变化就扔掉，有变化才发出去。这一下就能过滤掉90%的冗余数据。
3.4 本章知识体系总览
说了这么多，我画张图帮大家理一理思路。这张图展示了从设备到上层系统的完整数据流。
这张图从下往上看，就是数据从设备产生，经过协议封装，到边缘网关处理，最后送到上层系统的完整链路。每一层都有它的职责，缺一不可。
好了，设备互联和数据采集这部分，我就讲这么多。记住，协议是基础，方案是骨架，网关是大脑。把这三样搞明白了，你的晶圆厂数字化改造，第一步就算走稳了。