3. 数据采集架构:PLC、RTU、边缘网关的架构设计,数据流从现场到云端的路径

在厂务状态监测系统中,数据采集架构是连接物理设备与数字平台的桥梁。本章聚焦于从现场传感器到云端平台的数据流路径,详细解析PLC、RTU、边缘网关三种核心采集设备的角色分工与协同设计。

3.1 核心采集设备对比

PLC、RTU、边缘网关在厂务监测中承担不同层级的任务,下表从功能定位、通信方式、适用场景三个维度进行对比:

设备类型 功能定位 典型通信方式 适用场景
PLC 现场逻辑控制与高速采集 EtherNet/IP、Profinet、Modbus TCP 生产线、洁净室环境控制、空压机联控
RTU 远程数据采集与遥测 Modbus RTU、DNP3、4-20mA 模拟量 水处理站、冷站、配电房、室外管网
边缘网关 协议转换、数据预处理与上云 MQTT、OPC UA、HTTP/HTTPS 多协议汇聚、本地规则引擎、断点续传
选型提示: 对于需要毫秒级响应的控制回路(如空压机PID调节),必须使用PLC;对于分散在厂区各角落的监测点(如纯水pH值),RTU更具成本优势;边缘网关则作为“数据中继站”,解决协议异构与网络不稳定的问题。

3.2 数据采集架构分层设计

典型的厂务数据采集架构分为三层:现场设备层、边缘汇聚层、云端平台层。每一层都有明确的数据处理职责。

架构核心原则: 现场层负责“采”,边缘层负责“转”,云端层负责“存与算”。数据流自下而上,控制指令自上而下。

3.2.1 现场设备层

  • 传感器与执行器: 温度、压力、流量、振动、液位等传感器通过4-20mA、0-10V或IO-Link接入PLC或RTU。
  • PLC/RTU: 执行本地数据采集、滤波、量程转换,并向上层边缘网关发送标准化数据。
  • 通信协议: 现场总线以Modbus RTU/TCP、Profinet、EtherCAT为主。

3.2.2 边缘汇聚层

  • 边缘网关: 支持多协议解析(Modbus、OPC UA、BACnet),将异构数据统一为JSON或Protobuf格式。
  • 本地处理: 执行数据清洗、异常值剔除、阈值预判,降低云端计算压力。
  • 断点续传: 当网络中断时,数据暂存本地SD卡或SSD,恢复后自动补传。

3.2.3 云端平台层

  • 数据接入: 通过MQTT Broker或Kafka接收边缘网关推送的数据。
  • 时序数据库: 存储海量监测数据,支持高并发写入与快速查询。
  • 应用服务: 异常预警、趋势分析、报表生成、数字孪生。

3.3 数据流路径详解

以下SVG图展示了从现场传感器到云端平台的标准数据流路径,包含关键节点与协议转换过程。

厂务数据采集架构与数据流路径 厂务数据采集架构与数据流路径 现场设备层 温度传感器 压力传感器 流量传感器 振动传感器 PLC RTU 边缘汇聚层 Modbus TCP 边缘网关 协议转换 · 数据清洗 本地规则引擎 断点续传缓存 MQTT/OPC UA 云端平台层 MQTT/TLS MQTT Broker 时序数据库 预警引擎 可视化大屏 厂务监测应用 · 异常预警 · 报表 说明:数据流自下而上,现场层通过Modbus TCP/RTU将数据推送至边缘网关;边缘网关完成协议统一与本地预处理后,通过MQTT over TLS上传至云端;云端时序数据库存储数据,预警引擎实时分析并触发告警。 控制指令反向:云端 → 边缘网关 → PLC/RTU → 执行器,实现远程调控。

3.4 关键设计考量

3.4.1 协议转换与数据标准化

厂务现场设备协议繁杂,边缘网关必须支持以下主流协议的解析与转换:

  • Modbus RTU/TCP: 最通用的工业协议,PLC和RTU几乎都支持。
  • OPC UA: 面向未来的统一架构,支持安全通信与信息模型。
  • BACnet: 楼宇自控领域常用,适用于暖通空调、照明系统。
  • MQTT: 云端首选协议,轻量级、支持QoS、适合物联网场景。
常见陷阱: 很多项目在协议转换时忽略了字节序(Big-Endian vs Little-Endian)和数据类型映射(如32位浮点与16位整数的转换),导致上云数据出现“跳变”或“死值”。务必在边缘网关中配置明确的解析规则,并在测试阶段用真实传感器数据验证。

3.4.2 数据采集频率与缓存策略

数据类型 推荐采集频率 缓存策略 说明
温度/湿度 10-30秒 变化量触发 + 定时上报 变化缓慢,降低网络负载
压力/流量 1-5秒 定时上报 + 本地缓存 波动较快,需较高分辨率
振动/电流 毫秒级(边缘处理) 边缘计算特征值后上报 原始数据量大,不宜直接上云
设备状态/报警 事件触发 即时上报 + 本地日志 实时性要求最高

3.4.3 网络冗余与断点续传

厂务网络环境复杂,Wi-Fi干扰、交换机故障、光纤中断时有发生。边缘网关必须具备以下能力:

  • 双链路冗余: 同时连接有线以太网和4G/5G蜂窝网络,主链路断开自动切换。
  • 本地缓存: 至少存储7天的原始数据,采用环形缓冲区或SQLite数据库。
  • 断点续传: 网络恢复后,按时间戳顺序补传缺失数据,避免数据空洞。
  • 心跳检测: 每30秒向云端发送心跳包,云端可据此判断网关在线状态。

3.5 架构设计示例:冷站数据采集

以厂务冷站为例,展示典型的数据采集架构部署:

冷站数据采集架构示例 冷站数据采集架构示例 冷机 #1 温度·压力·电流 冷机 #2 温度·压力·电流 冷却塔 #1 水温·风机振动 冷却塔 #2 水温·风机振动 冷冻水泵 流量·振动 冷却水泵 流量·振动 PLC 冷站控制柜 Modbus TCP 边缘网关 协议转换·缓存 MQTT 云平台 时序库·预警 冷站架构要点:冷机、冷却塔、水泵通过硬接线或现场总线接入冷站PLC;PLC负责冷机群控逻辑,同时将运行数据通过Modbus TCP推送至边缘网关;边缘网关汇聚所有冷站数据,执行本地阈值判断(如冷机排气压力过高则本地报警),再上传至云端进行全局能效分析。 边缘网关同时接收云端下发的设定值(如冷冻水出水温度目标),转发给PLC执行远程调控。

3.6 实施建议与避坑指南

实施建议:
  1. 统一数据模型: 在边缘网关层定义标准化的数据点表,包括设备ID、时间戳、数值、质量戳(Good/Bad/Uncertain),避免云端解析混乱。
  2. 时钟同步: 所有PLC、RTU、边缘网关必须通过NTP同步时钟,确保数据时间戳一致,否则时序分析会出现偏差。
  3. 安全加固: 边缘网关与云端通信必须启用TLS加密;PLC/RTU的Modbus端口不应暴露在办公网,需通过防火墙或VPN隔离。
  4. 带宽规划: 根据采集频率和数据量计算上行带宽,例如1000个测点、5秒周期、每个点50字节,上行带宽需求约为80Kbps,预留余量至200Kbps。
避坑指南:
  • 不要将所有原始数据直接上云: 毫秒级振动数据直接上传会耗尽带宽和存储,应在边缘侧计算RMS、峰值、峭度等特征值后再上报。
  • 不要忽略网关的散热与供电: 边缘网关通常部署在配电柜或现场控制箱内,环境温度可能超过50℃,必须选用工业级宽温设备并配置UPS。
  • 不要依赖单一通信链路: 至少配置有线+无线双链路,避免因光纤被挖断导致数据全丢。

3.7 本章小结