摘要: 本文面向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计算逻辑的实时性和可靠性,为上层应用提供了高质量的数据基座。