第2章：SECS/GEM协议基础：SECS-I与SECS-II协议介绍、HSMS通信机制、GEM标准功能集、设备状态模型
各位同行，今天我们来聊聊半导体设备自动化的核心——SECS/GEM协议。说实话，我刚入行那会儿，看到这一堆缩写就头大。但干久了你会发现，搞懂这套协议，就等于拿到了设备通信的钥匙。
我习惯把SECS/GEM比作设备的"通用语言"。没有它，你的设备就是个信息孤岛。有了它，MES系统才能指挥设备干活，设备才能汇报自己的状态。
2.1 SECS-I协议：物理层的"老黄牛"
SECS-I，全称是SEMI Equipment Communications Standard 1。它定义了最底层的通信方式。说白了，就是数据怎么通过线缆传输。
我记得最早接触SECS-I时，用的还是RS-232串口。波特率9600，半双工模式。现在听起来很慢对吧？但在那个年代，这已经是工业级的稳定方案了。
SECS-I的核心参数：
- 物理层：RS-232C 串行接口
- 传输速率：9600 bps（标准），可配置到19200或38400
- 通信模式：半双工
- 最大电缆长度：15米（标准RS-232限制）
- 数据块大小：最大254字节
这里有个坑，我必须要提醒你。SECS-I的RS-232不是普通的电脑串口。它用的是25针D-sub连接器，而且信号定义有特殊要求。我曾经见过有人直接用电脑的9针串口去接设备，结果通信死活不通。嗯，后来查了半天才发现是针脚定义不对。
注意：SECS-I的RS-232信号电平是±12V，不是TTL电平。别用USB转TTL的线去接，会烧端口的。
2.2 SECS-II协议：消息的"语法规则"
SECS-I管的是怎么传，SECS-II管的是传什么。它定义了消息的结构和编码方式。你想想看，如果两个人打电话，线路通了（SECS-I），但说的语言不一样，那也白搭。SECS-II就是那个统一语言。
SECS-II的消息格式，我习惯叫它"流和函数"。每个消息都有一个Stream编号和Function编号。比如S1F1就是"Are You There"请求，S1F2就是响应。
| 消息类型 | Stream.Function | 方向 | 说明 |
|---|---|---|---|
| Are You There | S1F1 | Host → Equipment | 主机询问设备是否在线 |
| On-Line Data | S1F3 | Host → Equipment | 请求设备状态数据 |
| Establish Communications Request | S1F13 | Equipment → Host | 设备主动请求建立通信 |
| Process Program Send | S7F3 | Host → Equipment | 下载工艺配方 |
SECS-II的数据类型也很有意思。它用L（List）、A（ASCII）、B（Binary）、U1/U2/U4（无符号整数）、I1/I2/I4（有符号整数）、F4/F8（浮点数）等。我刚开始学的时候，最头疼的就是嵌套的List结构。一个消息里套了好几层List，解析起来特别费劲。
我的经验：写SECS-II解析代码时，先画个树形结构图。把每个层级标清楚，再动手写代码。这样能避免80%的解析错误。
2.3 HSMS通信机制：高速的"新干线"
HSMS，全称是High-Speed SECS Message Services。它是SECS-I的升级版，用TCP/IP代替了RS-232。为什么要升级？因为现在的设备数据量太大了，9600波特率根本跑不动。
HSMS有两种连接模式：
- 主动模式（Active Mode）：设备作为TCP客户端，主动连接主机
- 被动模式（Passive Mode）：设备作为TCP服务器，等待主机连接
我个人习惯用主动模式。为什么？因为设备重启后能自动重连，不用主机那边再手动触发。你想想看，半夜设备重启了，如果还要工程师手动连一下，那多麻烦。
HSMS的消息格式也很简洁。每个消息包含一个消息头（10字节）和消息体（SECS-II数据）。消息头里有：
- 长度（4字节）：整个消息的长度
- 设备ID（2字节）：标识是哪台设备
- Stream和Function（2字节）：消息类型
- W-bit（1位）：是否需要回复
- 系统字节（4字节）：用于消息匹配
关键点：HSMS的端口号通常是5000或5001。但这不是硬性规定，我见过用5555、9999的都有。只要主机和设备约定好就行。
2.4 GEM标准功能集：设备的"行为规范"
GEM，全称是Generic Equipment Model。它定义了设备必须支持哪些SECS/GEM功能。说白了，就是给设备画了个框框，告诉它：你必须会这些，才能叫"支持GEM"。
GEM标准功能集包括：
- 通信建立：S1F13/S1F14，建立和断开连接
- 设备状态：S1F3/S1F4，查询设备状态
- 报警管理：S5F1/S5F2，上报和确认报警
- 数据收集：S6F11/S6F12，周期性或事件触发的数据上报
- 配方管理：S7F3/S7F4，下载和上传工艺配方
- 远程控制：S2F41/S2F42，远程启动、停止、暂停
我记得有一次做项目，客户说设备支持GEM。结果联调时发现，它只实现了最基本的通信建立，其他功能一概没有。嗯，那叫"支持SECS"，不叫"支持GEM"。GEM是有严格的功能清单的，少一个都不行。
避坑指南：采购设备时，一定要让供应商提供GEM功能清单。对照SEMI E30标准，逐条确认。别信"支持GEM"这四个字，要看具体实现了哪些功能。
2.5 设备状态模型：设备的"生命线"
设备状态模型，是GEM里最核心的概念之一。它定义了设备从启动到关机的整个生命周期。我习惯把它想象成设备的"状态机"。
标准的状态模型包括：
- INIT（初始化）：设备刚上电，正在自检
- NOT READY（未就绪）：自检完成，但还不能干活
- IDLE（空闲）：设备就绪，等待任务
- SETUP（设置）：正在加载配方或参数
- READY（就绪）：设置完成，可以开始生产
- EXECUTING（执行中）：正在生产
- PAUSED（暂停）：生产暂停
- ABORTED（中止）：生产异常中止
- OFF-LINE（离线）：设备与主机断开
为什么这个模型重要？因为MES系统需要根据设备状态来做决策。比如设备在EXECUTING状态，MES就不会再下发新任务。设备在ALARM状态，MES就要通知工程师处理。
这个状态模型，说白了就是设备的"心电图"。MES系统通过监控状态变化，就能知道设备在干什么。我见过有些设备厂商自己扩展了状态，比如加了"MAINTENANCE"（维护中）状态。这没问题，只要不破坏标准状态的定义就行。
我的建议：做设备集成时，先把状态模型画出来。每个状态之间的转换条件写清楚。这样写代码时思路清晰，调试时也容易定位问题。
好了，SECS/GEM协议的基础就讲到这里。这套协议虽然看起来复杂，但核心思想很简单：定义一套统一的通信语言和行为规范。搞懂了这些，你就能让设备和MES系统顺畅地"对话"了。