半导体工厂的设备联网和外面的工业互联网不太一样。大部分行业接设备灌一个 OPC UA 或者 MQTT 就能跑半导体车间不行设备厂商从上世纪 90 年代就约定了一套专用语言——SECS/GEM。做了十年 EAP设备数据采集与自动化相关的工作这套协议踩过的坑值得单独聊一聊。一、SECS/GEM 到底是什么SECS 是 SEMI 制定的设备通信标准GEM 是它的通用模型。简单说它定义了设备和主机Host也就是 EAP 系统之间「说什么、怎么说、出事了怎么办」。- SECS-I基于 RS-232 的物理层老标准现在基本只在很老的设备上见到。- HSMS基于 TCP/IP 的通信方式现在主流。- GEM在 SECS 消息之上的一套行为约定比如设备要能上报事件、响应远程指令、维护状态机。通信的内容用 **SxFy** 编号比如 S1F1 是「你在线吗」S6F11 是「上报一个事件」。设备端把「温度到了」「片子取走了」这类事打包成消息发给 Host。二、坑一HSMS 的连接状态机新手最容易栽在连接管理上。HSMS 有被动Passive和主动Active两种模式设备和 Host 必须一端主动一端被动搞反了永远连不上。更隐蔽的是**状态机**。GEM 规定设备有 Communication、Control、Process 几大类状态。很多现场问题是网络闪断恢复后设备没主动重发「我回来了」Host 这边还以为连着结果一批事件悄无声息丢了。稳健的做法是在 EAP 侧做连接心跳 状态对账断线后主动重新建立通信并补拉设备当前状态而不是单纯依赖 TCP 重连。三、坑二SVID 和 Event 的定义权在设备方SECS/GEM 标准给了框架但**具体哪些变量SVID、哪些事件Event是可采的由设备厂商决定。同一家厂商不同型号SVID 表可能都不一样哪怕是同一型号固件版本升级后变量也可能变。所以 EAP 项目里一大块工作量是「对点表」拿到设备的 GEM 手册把你要采的温度、压力、节拍、报警代码逐个映射成系统的字段。千万别假设「买了一台新设备就能直接采」到现场大概率要重新对一遍。建议把设备通信能力做成可配置的元数据而不是写死在代码里。四、坑三老设备的协议栈不全并不是所有标称「支持 GEM」的设备都真的完整。我们遇到过设备能上报 S6F11 事件但 Process 状态机实现得不完整导致 Host 无法判断它到底在跑还是 idle。也有设备只实现了「Receive」方向远程指令S2F41 远程命令压根不响应。遇到这类情况要么推动设备厂商打补丁要么在 EAP 侧用「状态推断」兜底——比如根据节拍信号和报警信号反推机台状态。但这属于补偿方案长期还是要在选型设备时把 GEM 合规等级写进技术协议。五、坑四采到了数据语义层才是开始很多项目以为「设备连上了、数据进库了」就结束了其实真正的价值在后面。举个例子S6F11 上报一个事件「EQP_ALARM_001」系统里如果只存一个字符串没人看得懂。你需要把 001 映射到「贴片压力超上限」再关联到具体机台、批次、工艺段才能用于 SPC 分析和异常预警。也就是说设备数采的完成度 连通30% 变量映射40% 语义建模与业务联动30%。只做前两步数据只是躺在库里的字节。六、一点经验半导体设备联网技术难点不在「通信」本身而在**标准化与碎片化的拉扯**标准统一了语言但每家设备的「口音」都不一样。做 EAP 的人一半是协议工程师一半是设备工艺的翻译官。如果正在评估设备数采方案建议先拉一份厂内主流设备的 GEM 能力清单——这比任何 PPT 都更能预判项目工期。—作者益普科技 半导体芯片数字制造专注 EAP 设备数采 / SECS/GEM / MES