工业物联网架构：基于边缘计算的OEE数据采集与预处理实践

最新推荐文章于 2025-12-19 14:32:03 发布

原创最新推荐文章于 2025-12-19 14:32:03 发布 · 692 阅读

CC 4.0 BY-SA版权

文章标签：

摘要：本文面向IIoT开发者，从架构设计与代码实现的角度，探讨如何利用边缘网关完成PLC/CNC数据采集。重点解析如何通过边缘脚本实现数据的去抖、清洗与OEE因子（A/P/Q）预计算，并设计高效的MQTT Topic与Payload结构，实现OT与IT的深度融合。

导语：在开发MES或工业SaaS应用时，最棘手的问题往往不是云端业务逻辑，而是底层的“脏数据”。机床直接输出的原始信号充斥着干扰与冗余，直接上云会导致数据库臃肿且查询缓慢。如何利用边缘计算节点（Edge Node）在源头解决这一问题？本文将以通用的工业网关为例，分享一套标准化的技术实现路径。

边缘侧数据预处理的技术必要性

一、南向采集架构：多协议并发与点位映射

在工业现场，我们需要采集的数据通常分为三类：

离散量（Digital I/O）：如运行信号、故障信号。通常通过Modbus或直接读取PLC M区/I区。
模拟量（Analog）：如主轴负载、温度。通常读取PLC D区或DB块。
专用数据集：如CNC的报警履历、刀具寿命。需要调用Focas API或S7 Comm协议。

技术实现的难点在于点位映射（Mapping）。我们需要在网关配置工具中，建立从PLC Address (e.g., DB1.DBD0)到Gateway Tag (e.g., Spindle_Speed)的映射关系，并统一数据类型（Float/Integer）。

二、边缘计算逻辑：OEE因子的预处理

为了得到OEE，我们不能只上传Raw Data，必须在边缘侧运行脚本（Python/Lua/Node-RED）进行预处理。

1. 状态判定逻辑（Availability计算基础）

JSON

// 伪代码示例：设备状态状态机
if (Alarm_Code != 0) {
    Current_Status = "FAULT";
} else if (Run_Signal == 1 && Spindle_Load > 2.0) {
    Current_Status = "RUNNING"; // 负载大于阈值才算真运行
} else {
    Current_Status = "IDLE";
}

通过上述逻辑，我们过滤了“空跑”时间，提高了数据的真实性。

节拍计算逻辑（Performance计算基础） 利用网关的本地计时器，记录上一次Part_Count变化的时间戳T1和当前时间戳T2。 Real_Cycle_Time = T2 - T1 如果Real_Cycle_Time异常短（如<2s），视为信号抖动，予以丢弃。

三、北向数据模型：MQTT Payload设计

经过边缘处理后，我们通过MQTT上报结构化数据。建议采用如下JSON格式，以降低云端解析难度：

JSON

{
  "device_id": "cnc_001",
  "timestamp": 1633024800000,
  "metrics": {
    "status": "RUNNING",
    "oee_raw": {
        "availability_time": 3600, // 秒
        "target_output": 120,
        "actual_output": 115,
        "rejects": 2
    }
  }
}

总结：通过引入具备边缘计算能力的工业网关（如本例架构中使用的鲁邦通网关），我们将大量的数据清洗和逻辑判断任务下沉到了边缘侧。这不仅降低了云平台的带宽和算力成本，更重要的是，它保证了OEE计算逻辑的实时性和可靠性，为上层应用提供了高质量的数据基座。