2. EAP系统架构与核心组件
EAP（Equipment Automation Program）是晶圆厂中连接 MES 与生产设备的自动化中枢。它并不是一个“大而全”的单体程序，而是由若干职责清晰、边界明确的模块协同构成的系统。理解 EAP 架构的关键，不是记住模块名称，而是搞清楚每个模块“管什么、不管什么、和谁交互、数据往哪流”。本节围绕 EAP 主机、设备驱动、通信中间件、配方管理、物料追踪、报警管理、日志与追溯七个核心组件，梳理它们的职责划分与协作关系。
一、EAP 主机：调度与业务编排的中枢
EAP 主机（Host）是系统的“大脑”，负责与 MES 交互、接收工单与派工指令、编排设备动作序列、维护设备状态机。它不直接操作设备端口，而是通过设备驱动下发命令。EAP 主机通常维护以下核心对象：设备状态（Idle、Run、Down、PM）、批次上下文（Lot ID、Recipe ID、Wafer Count）、命令队列与超时控制。
一个典型的 EAP 主机处理流程是：MES 下发“开始加工 Lot A，使用 Recipe R1”的指令，EAP 主机校验设备状态与配方可用性后，生成命令序列（Load Port → Read Carrier ID → Select Recipe → Start），逐条交给设备驱动执行，并在每一步等待设备回报结果。若某步超时或失败，主机根据预设策略决定重试、暂停还是报警。
二、设备驱动：协议适配与命令翻译层
设备驱动（Equipment Driver）是 EAP 与物理设备之间的“翻译官”。不同设备厂商使用不同协议（SECS/GEM、OPC UA、Modbus、自定义 TCP），驱动层负责将这些差异屏蔽，向上提供统一的命令接口。驱动的核心职责包括：连接管理、消息编解码、命令-响应匹配、事件订阅、超时与重连。
以 SECS/GEM 为例，驱动需要处理 S1F1（Are You There）、S1F13（Establish Communication）、S2F41（Host Command）等消息。驱动不关心“为什么要加工这个批次”，它只负责把主机的逻辑命令翻译成设备能理解的报文，并把设备的事件（如 Process Start、Wafer End）翻译成主机能理解的事件。
三、通信中间件：消息路由与解耦
通信中间件（Communication Middleware）是 EAP 内部各模块之间的“消息总线”。它通常基于消息队列（如 RabbitMQ、Kafka）或 RPC 框架实现，负责消息的发布/订阅、路由、缓冲与可靠投递。中间件的价值在于解耦：EAP 主机不需要知道报警管理模块部署在哪台机器上，只需把报警事件发布到指定 Topic，报警模块订阅后自行处理。
在晶圆厂场景中，中间件还需要处理高并发与消息顺序问题。例如，同一台设备的多个事件必须按时间顺序处理，否则会导致状态错乱。因此，中间件通常按设备 ID 进行分区（Partition），保证同一设备的消息有序。
四、配方管理：版本控制与一致性保障
配方管理（Recipe Management）负责 Recipe 的存储、版本控制、下发与校验。在晶圆厂中，Recipe 是决定工艺结果的核心数据，任何版本错用都可能导致整批晶圆报废。因此，配方管理模块必须做到：Recipe 与产品/工序绑定、版本可追溯、下发前校验、下发后回读比对。
实际实现中，配方管理通常维护一张 Recipe 映射表，记录 Recipe ID、版本号、适用设备类型、校验和（Checksum）。当 EAP 主机请求下发 Recipe R1 时，配方管理模块先检查设备当前 Recipe 版本，若不一致则触发下发流程：将 Recipe 内容分块传输到设备，设备回读后计算 Checksum，与主机端比对，一致才允许开始加工。若比对失败，立即报警并阻止批次启动。
五、物料追踪：Carrier 与 Wafer 的全程映射
物料追踪（Material Tracking）模块负责维护 Carrier（FOUP）、Wafer 与设备端口之间的映射关系。它需要实时回答三个问题：这个 Carrier 现在在哪台设备的哪个端口？里面有哪些 Wafer？这些 Wafer 处于什么状态（Waiting、Processing、Completed）？
物料追踪的数据来源包括：RFID Reader 读取 Carrier ID、设备上报的 Wafer Mapping 结果、EAP 主机下发的加工指令。模块内部通常维护一个内存映射表，并定期持久化到数据库。当设备上报“Wafer 3 加工完成”时，物料追踪模块更新对应 Wafer 状态，并通知 EAP 主机判断是否继续下一片或结束批次。
六、报警管理：分级、抑制与恢复
报警管理（Alarm Management）模块负责采集设备报警、分级、通知与恢复跟踪。晶圆厂设备报警数量庞大，若不加处理直接推送给操作员，会造成“报警风暴”。因此，报警管理需要实现：报警分级（Critical、Major、Minor、Warning）、报警抑制（同一报警在短时间内重复出现只通知一次）、报警恢复确认（设备报警清除后，模块需确认并记录恢复时间）。
实际配置中，报警管理模块通常维护一张报警规则表，字段包括 Alarm ID、级别、是否抑制、通知方式（邮件/短信/Andon）、恢复超时。当设备上报 Alarm ID 101（Critical）时，模块立即触发 Andon 灯与邮件通知；若 5 分钟内未恢复，升级通知到设备工程师。
七、日志与追溯：审计与问题定位的基础
日志与追溯（Logging & Traceability）模块负责记录 EAP 全链路的命令、事件、报警与状态变化。它的核心价值在于：当出现批次异常或设备故障时，能够快速还原“当时发生了什么”。日志通常分为三类：命令日志（Host → Driver → Equipment）、事件日志（Equipment → Driver → Host）、报警日志（Alarm 产生与恢复）。
追溯模块则需要支持按 Lot ID、Carrier ID、Wafer ID、时间范围等维度查询。例如，当某批次出现良率异常时，工程师可以通过追溯模块查询该批次在 EAP 中的所有命令与事件，确认 Recipe 版本是否正确、设备是否在加工过程中产生过报警、Wafer 映射是否异常。
八、模块协作的典型数据流
以“MES 派工 Lot A 到 ETCH 设备”为例，完整数据流如下：MES 通过中间件发送派工消息 → EAP 主机接收并校验设备状态 → 主机向配方管理请求 Recipe R1 版本信息 → 配方管理返回版本与 Checksum → 主机通过驱动下发 Recipe → 驱动翻译为 SECS 消息发送到设备 → 设备回读 Recipe 并返回 Checksum → 驱动上报主机 → 主机比对通过后，通知物料追踪更新 Carrier 状态 → 主机下发 Start 命令 → 设备开始加工并上报事件 → 驱动将事件转发中间件 → 报警管理订阅事件并判断是否触发报警 → 日志模块记录全链路消息。
这条数据流中，每个模块只处理自己职责范围内的数据，不越界、不耦合。正是这种清晰的职责划分，使得 EAP 系统在晶圆厂 7×24 小时运行中保持稳定、可维护、可扩展。