3. EAP核心功能与架构
EAP（Equipment Automation Program，设备自动化程序）是MES与生产设备之间的“翻译层”和“执行层”。MES关心的是工单、批次、配方版本和良率，而设备只认SECS/GEM消息、寄存器地址和IO信号。EAP的核心价值，就是把这两套语言稳定地对接起来，并在设备状态变化、指令执行、数据采集和异常发生的过程中，保证信息不丢、不错、可追溯。理解EAP，不能只看它“连了设备”，而要看它内部六个功能域如何协同：设备连接、状态管理、指令下发、数据采集、异常处理与消息总线。
一、设备连接：从物理链路到逻辑会话
设备连接是EAP的第一层能力。以典型的SECS/GEM设备为例，EAP作为Host端，通过HSMS（High-Speed SECS Message Services）与设备建立TCP连接。连接过程不是简单“连上就行”，而是包含几个关键阶段：物理链路建立、HSMS选择请求与确认、SECS-II会话激活、以及设备模型（Equipment Model）的在线识别。
在配置层面，EAP通常需要维护设备连接参数表，例如：设备ID、IP地址、端口号（HSMS常用5000）、设备类型、通信协议、超时时间、重连间隔、心跳周期等。一个典型的连接配置示例如下：
设备ID: ETCH-01
IP: 10.20.30.41
端口: 5000
协议: HSMS-SS
T3超时: 45s
T5超时: 10s
T6超时: 5s
T7超时: 10s
T8超时: 5s
心跳间隔: 30s
重连间隔: 5s
其中T3是回复超时，T5是连接分离超时，T6是控制事务超时，T7是未选择超时，T8是网络中断超时。这些参数直接决定EAP在设备响应慢、网络抖动或设备重启时的行为。连接建立后，EAP还需要通过S1F13/S1F14交换设备身份，通过S1F1/S1F2确认在线状态，并订阅设备事件和报警。只有逻辑会话激活，后续的指令下发和数据采集才有意义。
二、状态管理：设备状态与EAP内部状态的双层模型
设备状态管理是EAP最容易被低估的部分。设备本身有SEMI E10定义的状态模型，例如：Non-Scheduled、Unscheduled、Scheduled、Engineering、Productive、Standby、Engineering、Idle等。EAP不能只做“透传”，而要在内部维护一份与MES对齐的状态视图。
EAP内部通常维护三层状态：通信状态（Connected/Disconnected）、控制状态（Online Local/Online Remote/Offline）、过程状态（Idle/Run/Pause/Error）。这三层状态共同决定EAP当前能做什么。例如，当设备处于Online Remote且过程状态为Idle时，EAP可以下发配方和启动指令；当设备处于Online Local时，EAP只能采集数据，不能远程控制；当通信状态为Disconnected时，所有指令都应进入等待队列或直接拒绝，而不是盲目发送。
状态管理的实现要点是“事件驱动 + 状态机”。EAP订阅设备的事件报告（如S6F11），结合自身定时轮询（如S1F3状态查询），更新内部状态机。每次状态变化都要记录时间戳、旧状态、新状态、触发源（设备事件、MES指令、人工操作），并写入日志。这样在出现“设备明明在跑，MES却显示Idle”这类问题时，才能快速定位是设备事件丢失、EAP状态机卡死，还是MES同步延迟。
三、指令下发：从MES工单到设备动作
指令下发是EAP最核心的执行功能。MES下发的通常是一个工单或批次任务，EAP需要把它拆解为设备可执行的SECS指令序列。以“开始加工”为例，典型流程包括：校验设备状态、校验配方版本、下载配方（若需要）、选择配方、设置参数、启动设备、确认启动结果。
每一步都对应具体的SECS消息。例如，配方下载可能使用S7F3/S7F4，配方选择使用S7F5/S7F6，启动指令使用S2F41（Remote Command），参数设置使用S2F15/S2F16。EAP不能假设设备一定成功，必须处理回复中的错误码。例如S2F42回复中HCACK=0表示命令已执行，HCACK=1表示命令不存在，HCACK=2表示命令参数错误，HCACK=3表示命令当前不可执行。EAP要根据这些返回码决定重试、回滚还是上报异常。
指令下发还需要考虑幂等性和顺序性。同一工单的启动指令如果因为网络重发被设备收到两次，可能导致重复加工。EAP通常通过指令ID、事务ID和状态锁来保证幂等。同时，对于同一台设备，配方下载、配方选择、启动这三步必须串行执行，不能并发，否则设备可能处于不一致状态。
四、数据采集：从设备事件到MES可用的数据
数据采集分为两类：事件驱动采集和轮询采集。事件驱动采集依赖设备主动上报的S6F11事件报告，例如“加工开始”“加工结束”“报警发生”“参数超限”。轮询采集则由EAP按周期发送S1F3或S1F4，读取设备当前状态和关键参数。
采集到的数据不能直接丢给MES，通常需要经过清洗、映射和聚合。例如，设备上报的腔体压力单位可能是Torr，MES需要的是Pa；设备上报的报警代码是数字，MES需要的是报警名称和等级。EAP需要维护数据映射表，把设备原始数据转换为MES可理解的结构化数据。
一个典型的数据采集配置可以包含：采集项名称、SECS消息类型、触发方式、采集周期、数据类型、单位、映射规则、上报MES的字段名。例如：
采集项: ChamberPressure
消息: S6F11 CEID=1001
触发: 事件驱动
数据类型: F4
单位: Torr
映射: Pa = Torr * 133.322
MES字段: chamber_pressure_pa
数据采集的关键指标是完整性和时效性。完整性要求不丢事件，通常通过事件订阅确认和本地缓存实现；时效性要求采集延迟可控，通常通过消息总线异步处理，避免EAP主线程被数据库写入阻塞。
五、异常处理：分类、隔离与恢复
EAP的异常处理不能只靠“报错重试”。更合理的做法是先分类，再决定处理策略。常见异常包括：通信异常（连接断开、超时）、协议异常（消息格式错误、非法回复）、设备异常（报警、互锁、命令拒绝）、业务异常（配方版本不匹配、工单状态不允许）、系统异常（EAP内部服务崩溃、数据库不可用）。
对于通信异常，EAP应进入重连流程，同时把未完成的指令挂起，待连接恢复后根据指令状态决定重发或取消。对于设备报警，EAP应订阅S5F1报警消息，记录报警代码、发生时间、清除时间，并通知MES暂停派工。对于命令拒绝，EAP应根据HCACK返回码决定是否重试；如果是参数错误，重试没有意义，应直接上报异常并等待人工处理。
异常处理还需要“隔离”思想。一台设备的通信异常不应影响其他设备的EAP线程；一个工单的指令失败不应阻塞整个消息队列。EAP通常采用多线程或异步任务模型，每个设备一个独立会话，异常在会话内处理，必要时上报到全局异常队列。
六、消息总线设计：EAP内部与EAP之间的解耦
当EAP需要同时对接多台设备、多个MES模块和多个上层系统时，点对点调用会迅速变成一张难以维护的网。消息总线的作用，是把“谁发给谁”变成“谁发布什么主题、谁订阅什么主题”。
EAP内部消息总线通常包含几个关键主题：设备状态变更、指令请求、指令结果、采集数据、报警事件、异常事件。设备连接模块发布状态变更，指令模块订阅状态变更并发布指令结果，数据采集模块发布采集数据，异常模块订阅所有异常事件并统一处理。MES侧则通过总线订阅工单执行结果和设备状态，而不需要直接调用EAP的接口。
消息总线的设计要点包括：消息格式统一（建议使用JSON或Protobuf）、消息持久化（关键指令和结果不能丢）、消费确认（避免重复消费）、死信队列（处理无法消费的消息）、以及消息追踪ID（贯穿工单、指令、设备事件和采集数据）。一个典型的指令消息可以包含：消息ID、工单号、设备ID、指令类型、参数、时间戳、追踪ID。这样从MES下发工单到设备执行完成，整条链路都可以通过追踪ID串联起来。
七、六个功能域如何协同：一个完整的加工指令闭环
把六个功能域串起来看，一个完整的“MES下发工单→设备加工完成→MES收到结果”闭环大致如下：MES通过消息总线发布工单指令；EAP指令模块订阅到指令后，先查询状态管理模块，确认设备处于Online Remote且Idle；然后通过设备连接模块向设备发送配方下载和选择指令；设备回复成功后，EAP发送启动指令；设备开始加工并上报S6F11事件，数据采集模块接收事件并发布采集数据；加工结束后，设备上报完成事件，EAP更新状态并发布指令结果；如果过程中出现报警或超时，异常处理模块介入，决定重试、挂起或上报MES。
这个闭环中，消息总线承担了“解耦”和“缓冲”两个作用。解耦让MES不需要知道EAP内部有多少线程、多少设备会话；缓冲让设备短暂离线时，指令不会直接丢失，而是进入等待队列。对于工程实现来说，EAP的稳定性往往不取决于单个功能有多强，而取决于这六个功能域之间的边界是否清晰、状态是否一致、异常是否可追溯。
总结来说，EAP不是简单的“协议转换器”，而是一个带状态、带队列、带异常恢复能力的设备协同中枢。设备连接解决“通不通”，状态管理解决“能不能做”，指令下发解决“怎么做”，数据采集解决“做了什么”，异常处理解决“出问题怎么办”，消息总线解决“怎么协同”。把这六个功能域设计清楚，EAP才能在高节拍、多设备、多异常的半导体产线中稳定运行。