第3章数据采集与边缘计算

第三课：数据采集与边缘计算

大家好，我是老张。今天咱们聊聊数据采集和边缘计算。说实话，这俩词儿在自动化圈子里已经火了好几年了。但真正能把它们落地到项目里的，其实不多。

我记得刚入行那会儿，PLC数据采集全靠上位机轮询。一个车间几十台PLC，上位机忙得跟什么似的。后来边缘计算出来了，我才发现——原来很多活儿，根本不用往云端送。

3.1 PLC数据采集实战

PLC数据采集，说白了就是把PLC里的寄存器值读出来。但这里有个坑——不同品牌的PLC，协议完全不同。

我常用的几种方式：

Modbus TCP/RTU：最通用的协议，西门子、三菱、施耐德都支持
OPC UA：适合跨平台，安全性好，但配置稍复杂
厂家私有协议：比如西门子的S7协议、三菱的MC协议

举个例子，用Python通过Modbus TCP读取西门子S7-1200的数据：

from pymodbus.client import ModbusTcpClient

# 连接PLC
client = ModbusTcpClient('192.168.1.100', port=502)
client.connect()

# 读取保持寄存器，从地址0开始，读10个
result = client.read_holding_registers(0, 10, unit=1)

if result.isSuccess():
    for i, val in enumerate(result.registers):
        print(f"寄存器 {i}: {val}")
else:
    print("读取失败")

client.close()

嗯，这里要注意——很多PLC的寄存器地址和Modbus地址不是一一对应的。我曾经在项目里吃过这个亏，读出来的数据全是乱的。后来才发现，西门子的地址映射需要做偏移。

⚠️ 避坑指南：我曾经遇到过PLC的Modbus从站地址设置错误，导致数据全部错位。建议在调试阶段先用Modbus扫描工具确认地址映射关系。

3.2 边缘网关配置

边缘网关，你可以把它理解成一个「小电脑」。它负责把PLC的数据收上来，做初步处理，再决定是本地存储还是上传云端。

我常用的边缘网关有几种：

类型	代表产品	适用场景
工业级网关	西门子IoT2040、研华WISE系列	工厂车间、恶劣环境
嵌入式网关	树莓派+Node-RED	小规模、原型验证
软网关	Kepware、Ignition Edge	已有PC环境、快速部署

我个人习惯用树莓派搭边缘网关。成本低，社区资源多。配置Node-RED做数据流转，大概半小时就能跑起来。

配置要点：

确定数据采集频率——别太快，PLC扛不住；也别太慢，实时性不够
设置断线重连机制——网络不稳定是常态
本地缓存——网络断了，数据不能丢

💡 小技巧：我建议在边缘网关上装个看门狗。曾经有个项目，网关跑了一个月突然死机，现场没人发现。后来加了硬件看门狗，再没出过问题。

3.3 数据清洗与预处理

从PLC采集上来的数据，说实话，挺「脏」的。你想想看，传感器偶尔跳变、通信偶尔丢包、PLC偶尔死机——这些都会产生异常数据。

数据清洗，就是把这些「脏数据」处理掉。常用的方法：

去重：同一时间戳的重复数据，只保留一条
去噪：明显超出量程的值，直接丢弃
插值：缺失的数据，用前后值平均补上
滤波：比如滑动平均，让曲线更平滑

举个例子，用Python做滑动平均滤波：

def moving_average(data, window_size=5):
    """滑动平均滤波"""
    result = []
    for i in range(len(data)):
        start = max(0, i - window_size // 2)
        end = min(len(data), i + window_size // 2 + 1)
        avg = sum(data[start:end]) / (end - start)
        result.append(avg)
    return result

# 原始数据（含噪声）
raw_data = [25.1, 25.3, 28.7, 25.2, 25.0, 24.8, 25.1]
filtered = moving_average(raw_data)
print(filtered)

为什么会这样？因为28.7明显是个异常值。经过滑动平均后，它被「拉」回来了。

  ⚠️ 注意：数据清洗不是越狠越好。我曾经在项目里把滤波窗口设得太大，结果真正的故障信号也被滤掉了。后来现场出了事故，我才意识到——清洗要适度，关键是要保留异常特征。

3.4 边缘侧规则引擎

规则引擎，说白了就是「如果...就...」。在边缘侧做规则判断，好处是响应快——毫秒级，不用等云端返回。

我常用的规则引擎有两种：

Node-RED的function节点：写JavaScript逻辑，简单直观
轻量级规则引擎：比如Drools、EasyRules，适合复杂规则

举个例子，用Node-RED写一个温度报警规则：

// 输入：msg.payload = { temp: 85.3, timestamp: "..." }
// 规则：温度超过80度，触发报警

if (msg.payload.temp > 80) {
    msg.payload.alert = "高温报警";
    msg.payload.level = "critical";
    return msg;  // 发送到报警节点
} else {
    return null; // 不处理
}

嗯，这里要注意——规则引擎的优先级。我曾经在项目里设了十几条规则，结果它们互相冲突，导致报警乱发。后来我用了优先级排序，才搞定。

常见的边缘侧规则：

阈值报警（温度、压力、流量超限）
变化率报警（数据变化太快，可能设备故障）
组合条件（温度高且压力低，可能是冷却系统故障）
心跳检测（设备长时间没上报数据，可能离线）

💡 实战经验：我建议把规则引擎的日志打开。曾经有个项目，规则触发了但没人知道，因为日志没开。后来排查了三天才发现是规则写错了。日志是调试的好帮手。

知识体系总览

下面这张图，是我自己画的。它把本章的知识点串起来了。你一看就明白——数据从PLC出来，经过边缘网关，再到清洗和规则引擎，最后决定是本地存储还是上传云端。

你看，整个流程其实不复杂。但每个环节都有坑。我做了这么多年，最大的体会就是——数据采集不难，难的是让数据「靠谱」。

好了，这一章就到这里。记住：边缘计算不是万能的，但它能帮你解决80%的实时性问题。剩下的20%，交给云端去处理。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

第三课：数据采集与边缘计算

3.1 PLC数据采集实战

3.2 边缘网关配置

3.3 数据清洗与预处理

3.4 边缘侧规则引擎

知识体系总览