4. 生产流程联动的事件驱动机制
在EAP与MES的联动体系中，派工决策并不是靠定时轮询“猜”出来的，而是由生产现场真实发生的事件驱动。设备状态变化、批次到达、物料就绪、异常报警，这些事件一旦产生，就应通过统一的事件总线进入规则引擎，触发派工计算，并把结果回写到流程执行环节。理解这条链路，是设计高实时、低耦合派工系统的关键。
四类核心事件及其触发语义
生产现场的事件可以归纳为四类，每类事件的触发语义和派工影响不同：
- 设备事件：设备状态从 RUN 变为 IDLE、从 DOWN 恢复为 UP、完成一次加工并上报完成信号。设备事件决定“哪台设备现在可以接活”。例如设备 EQ-03 上报
StateChange: RUN→IDLE，表示该设备空闲，可参与下一轮派工。 - 批次事件：批次创建、批次到达某工序、批次完工、批次被拆分或合并。批次事件决定“有哪些活需要派”。例如
LotArrived: LOT-A120 到达 PHOTO 工序，触发该工序的派工请求。 - 物料事件：物料到线、物料齐套、物料短缺、物料批次切换。物料事件决定“活能不能干”。例如
MaterialReady: LOT-A120 所需光刻胶已齐套，是派工可执行的前置条件。 - 异常事件：设备报警、质量异常、SPC 越限、设备停机。异常事件决定“是否需要暂停或改派”。例如
AlarmRaised: EQ-03 真空度超限，需要立即冻结该设备上的派工并触发改派。
这四类事件并非孤立，而是共同构成派工决策的输入条件。设备事件提供“资源可用性”，批次事件提供“任务需求”，物料事件提供“可执行性”，异常事件提供“约束与修正”。
事件如何触发派工决策
事件进入总线后，规则引擎按“事件类型 + 业务条件”进行匹配。以设备事件为例，当 EQ-03 上报空闲时，规则引擎会执行以下判断链：
- 该设备是否处于可用状态（非 PM、非 DOWN、非报警锁定）；
- 该设备当前是否有未完成的派工任务；
- 是否存在等待该设备能力的批次（按工序、产品、优先级匹配）；
- 候选批次所需物料是否齐套；
- 按优先级、交期、设备适配度排序，选出最优批次并生成派工指令。
批次事件则从“任务侧”触发：当 LOT-A120 到达 PHOTO 工序，规则引擎查询该工序所有可用设备，结合设备实时状态、WIP 负载、换型成本，计算最优设备并下发派工。物料事件和异常事件更多作为“约束修正”参与：物料未齐套时，派工结果进入等待队列；异常事件发生时，立即冻结相关设备上的派工并触发改派。
示例：一次完整的派工触发过程
事件1: EquipmentStateChanged {eqId:"EQ-03", from:"RUN", to:"IDLE", ts:"10:23:15.120"}
事件2: LotArrived {lotId:"LOT-A120", step:"PHOTO", priority:"HIGH", ts:"10:23:15.350"}
事件3: MaterialReady {lotId:"LOT-A120", material:"PR-001", qty:25, ts:"10:23:15.400"}
规则引擎匹配:
- EQ-03 可用，无在制任务
- LOT-A120 优先级 HIGH，物料齐套
- 设备能力匹配: EQ-03 支持 PHOTO 工序
- 派工计算得分: EQ-03=92, EQ-05=78, EQ-07=65
输出:
DispatchCommand {lotId:"LOT-A120", eqId:"EQ-03", step:"PHOTO", action:"LOAD"}
ProcessAdvance {lotId:"LOT-A120", fromStep:"PHOTO", toStep:"PHOTO_EXPOSE"}事件总线与消息中间件选型
事件总线的核心职责是：可靠接收、持久化、按主题路由、保证顺序、支持多消费者。选型时需要结合工厂的实时性要求、吞吐量、运维能力和已有技术栈。以下是常见中间件的对比：
| 中间件 | 适用场景 | 优势 | 注意事项 |
|---|---|---|---|
| Kafka | 高吞吐事件流、多消费者、事件回放 | 分区顺序、持久化强、生态成熟 | 运维较重，低延迟场景需调优 |
| RabbitMQ | 复杂路由、任务队列、中小规模 | 路由灵活、延迟低、易上手 | 高吞吐下需集群与镜像队列 |
| RocketMQ | 事务消息、顺序消息、金融级可靠 | 顺序保证好、支持事务 | 社区生态相对 Kafka 小 |
| MQTT | 设备侧轻量接入、边缘上报 | 协议轻、适合设备直连 | 不适合做核心事件总线 |
在EAP场景中，推荐采用“边缘 MQTT + 核心 Kafka”的组合：设备侧通过 MQTT 上报状态与报警，边缘网关转换为标准事件后写入 Kafka；MES/EAP 的规则引擎、派工服务、追溯服务分别作为独立消费者订阅 Topic。这样既保证了设备接入的轻量性，又获得了核心事件总线的持久化、顺序与回放能力。
选型判断要点：如果工厂已有 Kafka 运维能力且事件量较大（每秒数千条以上），优先 Kafka；如果事件量中等且路由规则复杂，RabbitMQ 更易维护；如果对事务消息和严格顺序有强要求，可评估 RocketMQ。无论选哪种，都必须实现事件幂等、死信队列和消费位点监控，否则派工决策会因重复消费或消息丢失而出现错派、漏派。
事件驱动机制的关键设计约束
要让事件驱动真正可靠，需要关注四个约束：
- 事件标准化：所有事件必须包含 eventId、eventType、source、timestamp、payload、version 字段，便于路由、去重和追溯。
- 顺序与幂等：同一设备的状态事件必须按时间顺序消费；派工指令需带唯一 dispatchId，消费端做幂等校验，避免重复派工。
- 超时与补偿：派工指令下发后若设备在设定时间内未确认（例如 30 秒），触发超时事件，规则引擎重新派工或转人工处理。
- 闭环反馈：设备执行结果、批次完工、异常恢复都要回写事件总线，形成“事件→决策→执行→反馈”的闭环，而不是单向触发。
事件驱动机制的价值在于把“派工”从定时批处理变成实时响应。设备一空闲、批次一到达、物料一齐套，系统就能在毫秒级完成决策并推进流程。但这也要求事件总线具备足够的可靠性和可观测性，否则一个丢失的异常事件就可能导致设备带病运行或批次错派。因此，事件总线的选型与治理，和派工规则本身同等重要。