4. Recipe自动下发的系统架构

Recipe自动下发不是“把文件从A拷到B”这么简单。它是一条跨越三层系统的受控数据链：MES负责“哪台设备、在哪个工单、用哪个版本”，EAP负责“翻译、校验、排队、重试、回执”，设备控制层负责“真正把参数写进机台并确认生效”。三层之间任何一层语义不一致，都会导致下发失败、版本错乱甚至批量报废。因此，理解系统架构的关键，是看清数据流的方向、接口的边界和部署拓扑对可靠性的影响。

三层职责与数据流方向

MES是Recipe的“权威源”。它维护Recipe主数据、版本号、适用产品/工序/设备型号的绑定关系，以及工单与Recipe的关联。当工单在某个工序派工到具体设备时，MES产生一条下发指令，内容通常包括：工单号、产品号、工序号、设备ID、Recipe名称、Recipe版本、校验码（如MD5或SHA-256）、生效时间窗和优先级。

EAP是“执行代理与协议适配层”。它接收MES指令后，先做本地校验：设备是否在线、当前是否处于可切换状态、Recipe是否已缓存在EAP本地库、版本校验码是否匹配。校验通过后，EAP把Recipe内容转换为设备能识别的格式（如SECS-II消息、文件传输、OPC UA节点写入），再下发到设备控制层。设备写入完成后返回结果，EAP将执行状态、耗时、错误码回传给MES。

设备控制层是“最终落点”。它接收EAP下发的参数集，执行本地校验（参数范围、互锁条件、当前工艺状态），写入控制器或配方存储区，并返回“已生效”或“拒绝”的明确回执。只有设备回执成功，整条链路才算闭环。

接口设计的关键约束

三层之间的接口不是随便定义的，必须满足几个硬约束。第一，幂等性：同一条下发指令可能因网络重试被重复投递，EAP必须能识别“同一工单+同一设备+同一Recipe版本”的重复请求，避免重复写入。第二，版本一致性：MES下发的Recipe版本号与校验码必须与EAP本地缓存、设备实际写入的内容三方一致，任何一方不匹配都应拒绝执行并告警。第三，超时与重试边界：EAP向设备下发通常设置5～30秒超时，超时后按策略重试1～2次，仍失败则标记为“下发失败”并通知MES，而不是无限重试。第四，回执语义明确：设备返回的“成功”必须区分“已接收”和“已生效”，只有“已生效”才能让MES把工单推进到下一工序。

典型部署拓扑

实际产线中，Recipe下发系统的部署拓扑主要有三种形态。第一种是集中式EAP：一台EAP服务器服务整条产线或整个车间，MES通过消息队列（如Kafka、RabbitMQ）把指令发给EAP，EAP再逐台设备下发。优点是维护简单、版本统一；缺点是单点风险高，EAP宕机会导致整线无法切换Recipe。

第二种是分布式EAP：每台设备或每组设备配一个EAP实例，MES通过服务注册与发现找到目标EAP。优点是故障隔离好、响应快；缺点是EAP数量多，版本升级和配置一致性管理复杂。第三种是边缘网关+EAP混合：在设备侧部署轻量边缘网关做协议转换和本地缓存，EAP部署在车间服务器做业务逻辑。这种拓扑适合设备品牌多、协议杂的旧线改造场景。

一次完整下发的时序与判断依据

以某工单在刻蚀工序派工到设备ETCH-01为例。MES生成指令：工单WO-20240517-003，产品P-28nm，工序ETCH-01，设备ETCH-01，Recipe名称ETCH_MAIN，版本V3.2，校验码a1b2c3d4。EAP收到后，先查本地缓存：ETCH_MAIN V3.2是否存在且校验码匹配。若匹配，直接进入协议转换；若不匹配，EAP向MES的Recipe仓库拉取该版本文件，拉取成功后再校验一次。

校验通过后，EAP通过SECS-II消息S7F3（Process Program Load）把Recipe内容发送给设备。设备端收到后，先检查当前是否处于“可切换”状态——如果机台正在跑片，则返回“忙，拒绝切换”；如果空闲，则写入Recipe存储区，执行参数范围校验，全部通过后返回S7F4确认。EAP收到确认后，把“已生效”状态回传MES，MES更新工单工序状态，允许开始加工。

如果设备返回“忙”，EAP不会立即重试，而是把指令放入等待队列，等设备空闲信号（如S6F11事件）触发后再下发。如果设备返回参数越界错误，EAP直接标记失败并告警，不重试，因为重试不会改变参数越界的事实。这些判断逻辑决定了Recipe下发不是简单的“发-收”，而是一个带状态机和条件分支的受控过程。

总结来看，Recipe自动下发的系统架构核心是三层职责清晰、接口约束明确、拓扑匹配产线规模。MES管“用哪个”，EAP管“怎么送”，设备管“是否真生效”。三者之间的数据流必须闭环，回执语义必须精确，才能让Recipe下发从“能跑”变成“可靠地跑”。