第4章数据采集软件架构

4. 数据采集软件架构：OPC DA/UA架构、MQTT协议在工业中的应用、边缘计算节点设计

各位同学，大家好。这一章我们聊聊数据采集的软件架构。说实话，这是整个PLC联网方案里最核心的部分。你硬件接得再好，软件架构搭得不对，数据上不来，一切都是白搭。

我个人习惯把数据采集架构分成三个层次来看：现场层、传输层、平台层。现场层就是PLC、传感器这些设备；传输层解决数据怎么出来、怎么走的问题；平台层就是你的SCADA或者云平台。今天咱们重点讲传输层里的三个关键技术：OPC DA/UA、MQTT，还有边缘计算节点。

先说说OPC。很多老工程师一听到OPC，第一反应就是OPC DA。没错，OPC DA（Data Access）是工业界的老将，从90年代就开始用了。它的核心思想很简单：让不同厂商的设备和软件能互相读写数据。

OPC DA的特点：

我在项目中遇到过最头疼的事，就是OPC DA的DCOM配置。两台Windows机器，防火墙一开，权限一设，折腾半天连不上。说白了，DCOM这玩意儿就不是为互联网设计的。

避坑指南： 我曾经在一个汽车零部件工厂里，因为OPC DA的DCOM配置问题，导致数据采集延迟了整整两周。后来我学乖了，能用OPC UA绝不用DA。

那OPC UA（Unified Architecture）呢？它是OPC基金会推出的新一代标准。跟DA相比，UA有几个革命性的变化：

你想想看，OPC UA相当于把OPC DA的功能全部重写了一遍，还加上了现代工业互联网需要的所有特性。我个人建议，新项目直接上OPC UA，别犹豫。

说完OPC，咱们聊聊MQTT。MQTT（Message Queuing Telemetry Transport）最早是IBM为石油管道监控设计的。它的特点是轻量、低带宽、支持QoS（服务质量等级）。

为什么MQTT在工业物联网里这么火？原因有三：

我记得有一次在水泥厂做项目，现场网络环境很差，经常断线。用OPC DA根本不行，一断就全挂了。后来换成MQTT，设备本地缓存数据，网络恢复后自动补传，问题就解决了。

小技巧： 在工业现场，我建议MQTT的QoS等级设为1。QoS 0可能丢数据，QoS 2性能开销太大。QoS 1是性价比最高的选择。

MQTT在PLC数据采集中的典型架构：

PLC → OPC UA Server → MQTT Gateway → MQTT Broker → SCADA/云平台

或者更直接一点：

PLC（支持MQTT） → MQTT Broker → 多个订阅者（SCADA、MES、手机App）

现在很多新型PLC已经原生支持MQTT了，比如西门子的S7-1200/1500，通过固件更新就能直接发MQTT数据。嗯，这里要注意，老款PLC还是得靠网关转换。

最后说说边缘计算节点。这是近几年最火的概念。说白了，边缘计算就是在靠近设备的地方做数据处理，而不是把所有数据都扔到云端。

为什么要做边缘计算？

我在设计边缘计算节点时，一般会考虑以下几个组件：

组件	功能	推荐方案
数据采集引擎	从PLC、传感器读取数据	Kepware、Ignition Edge、自研OPC UA Client
协议转换模块	将不同协议转为统一格式	Modbus TCP、Profinet、EtherNet/IP转MQTT
本地存储	缓存数据，防止断网丢失	SQLite、InfluxDB、TimescaleDB
边缘计算引擎	执行本地逻辑，如报警、滤波、聚合	Node-RED、Python脚本、C++程序
上行通信	将处理后的数据发送到云端或SCADA	MQTT、OPC UA、HTTP

一个典型的边缘计算节点硬件配置：

CPU: Intel Celeron J4125 或 ARM Cortex-A72
内存: 4GB ~ 8GB
存储: 64GB SSD（工业级）
网络: 双网口（一个接PLC网络，一个接办公网络）
系统: Ubuntu 20.04 LTS 或 Windows 10 IoT Enterprise

我个人习惯用树莓派4B做原型验证，成本低、社区资源多。但真正上产线，我会用研华、西门子或者贝加莱的工业边缘盒子。为什么？树莓派的SD卡容易坏，工业环境里扛不住震动和温度。

    核心思路： 边缘计算不是要把所有计算都放在边缘，而是只放必要的计算。我的原则是：能本地处理的绝不云端处理，能简单处理的绝不复杂处理。比如，一个温度传感器，你只需要在边缘做阈值判断，超过80度就报警，没必要把原始数据全传上去。

最后总结一下：

这三者结合起来，基本就能覆盖90%的PLC数据采集与远程监控场景了。下一章我们会讲具体的硬件选型和网络规划，到时候再结合实例深入聊聊。

好，这一章就到这里。有什么问题，咱们课后交流。