1. 课程导入与工程全景

在制造企业里，EAM（企业资产管理）与 MES（制造执行系统）往往各自运行多年：EAM 管设备台账、点检、维修工单、备件与设备状态，MES 管工单排产、工序报工、在制品流转与生产实绩。两者单独看都“能用”，但一旦设备突发故障，MES 仍在向该设备派工；维修完成后，MES 又不知道设备已恢复可用，只能靠电话或微信群通知。这类“状态不同步”带来的损失，通常不是系统故障，而是信息断层。

本课程要解决的核心问题，就是让 EAM 的设备状态与 MES 的生产状态形成可定义、可传递、可校验的联动关系。所谓生产状态联动，不是把两个系统简单对接，而是建立一套“状态语义 + 事件触发 + 数据映射 + 异常兜底”的工程机制：EAM 侧设备从“运行”变为“故障停机”，MES 侧对应工作中心或产线应自动进入“不可派工/暂停报工”状态；EAM 侧维修完工并验收，MES 侧应恢复“可派工”，同时把停机时长、故障代码回写到生产实绩，用于 OEE 与停机分析。

业务价值：从“事后知道”到“事中可控”

联动的价值可以落在三个可量化的方向。第一是减少无效派工：设备已停机，MES 若继续把工单派到该机台，操作工只能等待或做无效报工，联动后可在派工时直接过滤不可用资源。第二是缩短停机响应时间：EAM 报修事件实时推送到 MES，MES 可立即冻结该资源上的在制工单，避免“设备坏了还在报工”造成的数据污染。第三是提升 OEE 数据可信度：停机原因、停机区间由 EAM 维修工单与 MES 生产实绩共同确定，而不是靠人工事后补录。

以一个注塑车间为例：某台注塑机在 14:05 由操作工在 EAM 移动端提交“设备故障”报修，故障代码为 HYD-01 液压压力异常。若没有联动，MES 侧该机台仍显示“运行中”，14:05—15:20 之间可能继续产生报工记录，OEE 中的“可用率”被高估。若已联动，MES 在 14:05 收到事件后将该工作中心置为“停机待修”，暂停新工单派发，并把该时段标记为计划外停机；15:20 维修完工验收后，EAM 推送“恢复可用”，MES 恢复派工，同时把 75 分钟停机时长与故障代码写入当班生产实绩。这个例子说明：联动的本质是让状态在正确的时间、以正确的语义、到达正确的系统。

典型场景与系统边界

典型联动场景通常包括四类：设备故障停机与恢复、计划性保养停机、设备状态变更（如待机、换模、调试）、维修工单与生产工单的关联。每类场景都要明确“谁触发、谁接收、谁确认”。EAM 是设备状态的权威源，负责设备可用性、维修进度、停机原因；MES 是生产执行的权威源，负责工单、工序、报工与在制品。两者边界不能模糊：EAM 不应直接改写 MES 的工单状态，MES 也不应自行判定设备“已修好”。边界清晰，联动才不会变成互相覆盖数据。

整体技术架构

从工程实现看，EAM 与 MES 的联动通常采用“事件驱动 + 接口服务 + 状态映射”的三层结构。EAM 侧在设备状态变更或维修工单状态变更时产生业务事件，经集成层（ESB、消息队列或 API 网关）传递到 MES；MES 侧通过资源状态映射表，把 EAM 的设备编码、状态码、故障代码转换为 MES 的工作中心/设备资源状态，并触发派工过滤、报工校验与停机记录。反向链路则用于 MES 向 EAM 回传生产实绩、停机时段与关联工单号，供设备维修与 OEE 分析使用。

下面这张图给出本节最需要看清的整体关系：左侧是 EAM 的设备与维修域，右侧是 MES 的生产执行域，中间是集成层；箭头表示状态事件与回写数据的流向，底部是共享的主数据映射。图中同时标出了“故障停机”和“恢复可用”两条关键路径，便于理解联动的方向与边界。