3. 监控数据源与采集架构

MOM运营监控的第一道工程难题，不是"看什么指标"，而是"数据从哪里来、以什么口径来"。制造现场的数据天然分散在多个层级：最底层是设备PLC的毫秒级过程量，往上是SCADA的产线级汇总，再往上是MES的工单与批次执行，横向还有QMS的质量判定、WMS的库存与库位、ERP的订单与成本。这些系统由不同厂商、不同年代、不同协议构建，若直接让监控平台逐个对接，会形成"点对点蜘蛛网"，任何一处字段变更都会引发连锁故障。因此本节的核心任务是：先建立分层采集架构，再在其上构建统一语义层，把"物理信号"翻译成"业务可理解的指标"。

一、六类数据源的定位与采集特征

六类系统并非平级，它们在时间粒度、数据形态和采集方式上有本质差异，这决定了接入策略必须分层设计。

关键判断：PLC与SCADA属于"高频时序流"，必须走流式采集通道；MES、QMS、WMS属于"业务事件流"，适合消息驱动；ERP属于"低频批处理"，用ETL抽取即可。若把ERP订单数据也做成秒级轮询，既无必要，也会拖垮源系统。

二、分层采集架构：从边缘到语义

推荐采用"边缘采集层—消息缓冲层—语义映射层—指标服务层"四层架构。边缘侧部署采集网关（如基于OPC UA的Edge Gateway），负责协议转换与本地缓存，断网时数据不丢；消息缓冲层用Kafka或MQTT Broker承接高并发写入，起到削峰填谷作用；语义映射层是本节重点，负责把不同来源的原始标签统一到标准模型；指标服务层对外提供统一查询接口。

三、统一语义层的设计方法

语义层不是简单的字段映射表，而是一套"实体—属性—关系—指标"的元模型。设计时按以下顺序推进。

第一步：定义核心实体。制造运营监控通常需要五类实体：设备（Equipment）、工单（WorkOrder）、批次（Batch）、物料（Material）、人员（Operator）。每个实体有唯一业务主键，例如设备用"产线号+设备编号"，工单用"MES工单号"，批次用"批次号+物料编码"。

第二步：建立标签到属性的映射。以某注塑车间为例，PLC寄存器地址 DB100.DBD0 存放合模压力，量程0～200 bar，而监控指标要求以 MPa 展示。映射规则应写成：

{
  "source": "PLC_S7_1200",
  "raw_tag": "DB100.DBD0",
  "entity": "Equipment",
  "entity_id": "LINE01-IMM-03",
  "attribute": "clamp_pressure",
  "raw_unit": "bar",
  "target_unit": "MPa",
  "scale": 0.1,
  "offset": 0,
  "valid_range": [0, 20],
  "sample_interval_ms": 500
}

其中 scale=0.1 表示原始值乘以0.1得到MPa，valid_range 用于边缘侧量程校验，超出范围的数据标记为可疑而非直接丢弃。

第三步：处理时间对齐。PLC数据带设备时间戳，MES报工带业务时间戳，两者可能相差数秒到数分钟。语义层需统一采用"事件时间"（Event Time）而非"处理时间"（Processing Time），并设置允许的乱序窗口。例如OEE计算中，设备停机事件与工单结束事件的关联窗口设为±30秒，超出窗口则进入人工复核队列。

第四步：固化指标口径。同一指标在不同系统中定义可能不同。以"一次合格率"为例，QMS可能按检验单计算，MES可能按报工数量计算。语义层必须明确：分子为"首次检验合格数量"，分母为"首次检验总数量"，排除返工后复检数据，统计周期为自然班次。口径一旦确定，写入指标字典并版本化管理。

四、采集架构中的典型问题与判断依据

实际接入时，以下三类问题最常见，需要提前设计应对策略。

• PLC标签命名混乱：不同厂商设备标签命名规则不统一，如"Motor1_Run"与"M1_运行状态"并存。解决方式是在边缘层建立标签字典，由采集工程师维护"原始标签→标准属性"的对照表，语义层只认标准属性名。
• MES接口限流：部分MES的REST API对并发请求有限制，若监控平台直接高频调用会导致接口超时。应改为消息订阅模式，由MES在工单状态变更时主动推送事件到Kafka，监控平台消费消息而非轮询。
• ERP数据延迟：ERP通常按小时或按日批量同步，若监控大屏要求实时显示订单达成率，需明确告知业务方该指标存在固有延迟，并在界面上标注数据截止时间，避免误判。

判断采集架构是否合格，可以看三个信号：一是断网恢复后数据是否完整补传，二是同一指标在不同页面查询结果是否一致，三是新增一个数据源时是否需要修改监控应用代码。前两个反映数据质量，第三个反映语义层的解耦程度。若新增数据源只需在语义层增加映射配置、无需改动上层应用，说明架构分层是有效的。

五、语义层配置示例：从PLC到OEE指标

以某装配线OEE监控为例，完整链路如下：PLC提供设备运行/停机信号（DB200.DBX0.0，1=运行，0=停机），SCADA提供产线速度，MES提供工单计划数量与实际报工数量。语义层将三者关联到同一设备实体，按以下规则计算OEE：

可用率 = 实际运行时间 / 计划生产时间
性能率 = (实际产量 × 理论节拍) / 实际运行时间
合格率 = 合格数量 / 实际产量
OEE = 可用率 × 性能率 × 合格率

其中"实际运行时间"由PLC运行信号累计得出，"计划生产时间"来自MES工单的班次计划，"理论节拍"维护在语义层的设备属性中。所有输入参数均带来源标记，便于追溯。若OEE低于设定阈值（示例设为65%），监控平台触发告警并下钻到具体损失项：是停机时间过长、节拍偏慢，还是合格率偏低。

语义层的最终交付物是一份可执行的映射配置和一份指标字典。映射配置供采集平台加载，指标字典供业务方确认口径。两者版本同步管理，任何变更都记录变更人和生效时间。这样，当监控大屏上的数字出现异常时，排查路径是清晰的：先看原始标签值是否正常，再看映射规则是否被误改，最后看指标计算逻辑是否与业务预期一致。