2. 设备接入总体架构

在半导体制造场景中，设备接入并不是“把网线插上、把数据读出来”这么简单。它要同时满足设备控制、工艺追溯、生产调度、良率分析等多类系统的数据需求，因此工程上通常把接入体系划分为三层：设备端、EAP端、工厂端。理解这三层的职责边界，是后续状态建模与自动化控制能否落地的前提。

三层结构的职责划分

设备端是数据与动作的源头。它包含机台本体、嵌入式控制器、PLC、运动控制卡、传感器与执行器，以及设备厂商提供的通信接口。设备端对外暴露的能力通常有两类：一类是“数据能力”，如温度、压力、流量、阀门开度、晶圆位置、报警码；另一类是“动作能力”，如开始配方、暂停、复位、开门、取片。设备端的关键约束是实时性与厂商封闭性——很多机台只提供SECS/GEM接口，且内部变量不对外开放。

EAP端（Equipment Automation Program，设备自动化程序）是承上启下的中间层，也是本课程的核心。它一侧面向设备，负责协议解析、指令下发、状态采集与异常处理；另一侧面向工厂端，负责把设备语义转换为MES/EAP上层可理解的数据模型。EAP端通常承担：设备连接管理、状态机维护、配方管理、物料与载具跟踪、报警上报、数据采集与缓存、以及自动化控制逻辑（如自动上下料、自动换配方）。EAP端是“设备语言”与“工厂语言”的翻译器，也是自动化控制的执行中枢。

工厂端是业务与决策层，包括MES、EAP集群管理、SPC、FDC、RMS、AMHS调度等系统。它关心的是批次、工单、良率、设备综合效率（OEE）、报警趋势与生产节拍，而不是某个阀门的原始电压值。工厂端通过EAP端获取经过语义化、结构化处理后的设备数据，并向EAP下发工单、配方切换、派工等指令。

三种主流接入方式的定位与差异

三层结构确定后，真正决定工程实现难度的是“设备端到EAP端”这一段采用什么协议。半导体行业常见的有SECS/GEM、OPC UA和MQTT三类，它们并非互相替代，而是面向不同设备年代、不同数据粒度和不同实时性要求。

SECS/GEM是SEMI标准体系下的设备通信协议，由SECS-I/HSMS承载消息、GEM定义行为模型。它的优势是语义标准化：设备状态、报警、事件、配方、物料跟踪都有标准消息（如S1F1、S2F41、S6F11）。在成熟半导体设备上，SECS/GEM几乎是默认选项。它的局限是配置复杂、调试周期长，且对非半导体设备支持有限。

OPC UA面向工业自动化，强调信息模型与地址空间，适合PLC、传感器、厂务设备等。它支持订阅、方法调用和安全通道，数据粒度可以细到单个变量。对于没有SECS/GEM接口的新设备或辅助设备，OPC UA是很好的补充。但它不天然携带半导体工艺语义，需要EAP端做语义映射。

MQTT是轻量级发布/订阅协议，适合数据量大、实时性要求不极端、网络不稳定的场景，例如环境传感器、能耗表、辅助设备状态。它的优势是部署简单、扩展性好，但缺少设备控制所需的请求/响应与事务保证，通常只用于数据采集，不用于关键动作控制。

选型原则：从设备能力与业务需求出发

选型不应从“哪个协议先进”出发，而应从三个问题出发：设备支持什么、业务需要什么、EAP端能维护什么。

第一，优先尊重设备原生能力。如果设备厂商已提供SECS/GEM接口，应优先使用SECS/GEM，因为它的状态模型、报警定义、配方管理已经与半导体业务对齐，EAP端不需要从零构建语义。强行用OPC UA去读SECS设备，往往只能拿到部分变量，反而丢失标准事件。

第二，按数据用途分层选择。关键控制路径（如远程命令、配方下发、联锁）应使用SECS/GEM或OPC UA这类具备请求/响应和确认机制的协议；非关键监测数据（如温度趋势、能耗、环境湿度）可以用MQTT上报，降低EAP端连接负担。

第三，考虑EAP端的统一抽象。无论底层是SECS/GEM、OPC UA还是MQTT，EAP端都应向上提供统一的数据模型：设备状态、报警、变量、配方、物料。这样工厂端不需要关心底层协议差异。实践中常见做法是：EAP端为每台设备建立“设备驱动”，驱动内部处理协议细节，驱动外部输出统一接口。

一个可参考的接入配置示例

假设某8英寸晶圆厂新增一台清洗机，厂商提供HSMS接口，同时厂务系统需要采集该设备的纯水流量与排风压力。EAP端可以这样组织：

设备驱动配置（示例）
设备ID: CLN-01
主协议: HSMS/SECS-GEM
  IP: 10.20.30.41
  Port: 5000
  DeviceID: 1
  T3超时: 45s
  T5超时: 10s
  T6超时: 5s
  T7超时: 10s
  T8超时: 5s
采集项:
  - S1F1 在线检查（周期30s）
  - S1F3 状态查询（周期5s）
  - S6F11 事件上报（配方开始/结束、报警）
  - S2F41 远程命令（START/STOP/RESET）
辅助协议: MQTT
  Broker: mqtt://10.20.1.10:1883
  Topic: factory/utility/CLN-01/water_flow
  Topic: factory/utility/CLN-01/exhaust_pressure
  QoS: 1
 上报周期: 10s

在这个示例中，SECS/GEM承担设备状态、事件、报警和远程命令，MQTT只承担厂务辅助数据。EAP端把两路数据统一映射为设备模型，工厂端看到的是一台完整的CLN-01，而不是两个割裂的数据源。

三层结构下的数据流与责任边界

从数据流看，设备端产生原始信号，EAP端完成协议解析、状态判定、数据缓存与语义转换，工厂端消费业务数据并下发业务指令。责任边界清晰后，排障也会更有方向：设备不响应，先查EAP端连接与超时参数；EAP端状态不对，查状态机与事件解析；工厂端看不到数据，查EAP端上报接口与工厂端订阅关系。

需要特别注意的是，EAP端不是简单的“协议转换器”。它还要维护设备状态机、处理报警去重与恢复、管理配方版本、保证指令幂等。这些能力决定了接入层是否稳定，也决定了后续自动化控制能否可靠运行。选型时如果只关注协议连通性，而忽略EAP端的状态建模与异常处理能力，上线后往往会在报警风暴、状态跳变、配方错配等问题上付出代价。

总结来看，设备端、EAP端、工厂端三层结构解决的是“谁负责什么”的问题；SECS/GEM、OPC UA、MQTT解决的是“用什么语言沟通”的问题。选型的核心不是追求单一协议统一，而是让每类设备用最合适的方式接入，再由EAP端统一抽象、统一建模、统一上报。这样既尊重设备现实，又满足工厂端业务需求，也为后续状态建模与自动化控制打下稳定基础。