2、数据采集层设计：边缘网关选型、传感器协议适配（Modbus/OPC UA/MQTT）
数据采集层是整个远程监控平台的「地基」。地基没打好，上层再花哨也是白搭。我见过太多项目，数据采不上来，或者采上来全是乱码，最后整个系统推倒重来。这一章，咱们就聊聊怎么把这个地基夯实。
2.1 边缘网关选型：别只看参数，要看场景
边缘网关，说白了就是现场设备和云平台之间的「翻译官」+「守门员」。它既要读懂各种传感器的「方言」，又要做初步的数据清洗和压缩，还得扛得住现场的恶劣环境。
选型时，我一般会盯死这五个维度：
| 维度 | 核心关注点 | 我的经验 |
|---|---|---|
| 硬件性能 | CPU主频、内存、存储 | 别只看核心数，要看实际负载下的温度。我踩过坑，某款工控板标称四核，夏天车间40度直接降频死机。 |
| 接口丰富度 | RS485/232、以太网、DI/DO、AI/AO | 尽量选接口冗余的。现场总有你意想不到的设备要接，留两个备用口心里不慌。 |
| 协议支持 | Modbus、OPC UA、MQTT、Profinet等 | 最好选支持「协议插件化」的网关。换协议不用换硬件，后期维护省大事。 |
| 环境适应性 | 防护等级、宽温、防尘防水 | 户外或车间环境，IP65起步。我曾经在粉尘车间用过普通网关，三个月后风扇堵死，直接烧了。 |
| 安全性 | TLS加密、证书管理、防火墙 | 现在黑客盯上工业设备了。网关必须支持安全启动和固件签名，这是底线。 |
2.2 传感器协议适配：Modbus、OPC UA、MQTT 三剑客
协议适配是数据采集层最磨人的环节。你想想看，现场可能有几十种传感器，每种都有自己的「脾气」。有的用Modbus RTU，有的用Modbus TCP，还有的只支持OPC UA。怎么把它们统一起来？
2.2.1 Modbus：老当益壮的工业「普通话」
Modbus 是工业领域最古老的协议之一，但至今仍是主流。它简单、可靠、占用资源少。我做过一个项目，现场有200多个温湿度传感器，全是Modbus RTU，一根双绞线就全串起来了。
适配要点：
- 地址映射： 每个传感器都有唯一的Modbus地址（1-247）。别搞混，我曾经因为地址冲突，排查了整整两天。
- 功能码： 读线圈（01）、读寄存器（03/04）、写线圈（05）、写寄存器（06/16）。记住这几个就够了。
- 数据解析： 注意字节序（Big-Endian vs Little-Endian）。很多坑都出在这里。
// Modbus RTU 读取温湿度示例（C语言伪代码）
uint8_t slave_addr = 0x01; // 传感器地址
uint8_t func_code = 0x03; // 读保持寄存器
uint16_t start_reg = 0x0000; // 起始寄存器地址
uint16_t reg_count = 0x0002; // 读取2个寄存器（温度+湿度）
// 构建报文
uint8_t frame[] = {0x01, 0x03, 0x00, 0x00, 0x00, 0x02, 0xC4, 0x0B};
// 发送并接收响应
// 解析响应：温度 = (reg0 << 8 | reg1) / 10.0
// 湿度 = (reg2 << 8 | reg3) / 10.0
2.2.2 OPC UA：面向未来的「统一语言」
OPC UA 比 Modbus 复杂得多，但它解决了 Modbus 的很多痛点：安全性、跨平台、信息模型。说白了，OPC UA 不只是传数据，它还告诉你怎么理解这些数据。
适配要点：
- 地址空间： OPC UA 用节点（Node）组织数据，每个节点有唯一的NodeId。别想着用Modbus那种「寄存器地址」的思路去理解它。
- 安全策略： 必须配置证书。很多初学者嫌麻烦直接关掉安全，这是大忌。
- 订阅机制： 用MonitoredItem订阅数据变化，比轮询高效得多。
// OPC UA 客户端连接示例（Python + opcua-asyncio）
import asyncio
from opcua import Client
async def main():
client = Client("opc.tcp://192.168.1.100:4840")
try:
await client.connect()
# 获取根节点
root = client.get_root_node()
# 读取温度值（假设节点ID为 ns=2;i=1001）
temp_node = client.get_node("ns=2;i=1001")
temp_value = await temp_node.read_value()
print(f"当前温度: {temp_value} °C")
finally:
await client.disconnect()
asyncio.run(main())
2.2.3 MQTT：云边协同的「快递员」
MQTT 不是用来替代 Modbus 或 OPC UA 的，它是用来做「云边通信」的。边缘网关采集到数据后，通过 MQTT 发布到云端。它轻量、支持 QoS、支持遗嘱消息，非常适合物联网场景。
适配要点：
- 主题设计： 主题（Topic）要分层设计。比如
factory/line1/temperature，方便云端订阅和过滤。 - QoS 选择： 一般用 QoS 1（至少一次）。QoS 0 可能丢数据，QoS 2 太慢。
- 遗嘱消息： 设置遗嘱消息，网关掉线时云端能第一时间知道。
// MQTT 发布数据示例（Node.js + mqtt.js）
const mqtt = require('mqtt');
const client = mqtt.connect('mqtt://broker.emqx.io:1883', {
clientId: 'gateway_001',
will: {
topic: 'gateway/001/status',
payload: 'offline',
qos: 1,
retain: true
}
});
client.on('connect', () => {
// 每5秒发布一次温湿度数据
setInterval(() => {
const payload = JSON.stringify({
temperature: 25.3,
humidity: 60.1,
timestamp: Date.now()
});
client.publish('factory/line1/environment', payload, { qos: 1 });
}, 5000);
});
2.3 协议适配的「统一抽象层」设计
现场设备五花八门，但上层应用只关心数据。所以，我们需要在边缘网关上做一个「统一抽象层」。说白了，就是把 Modbus、OPC UA、MQTT 的数据都转成统一的 JSON 格式，再往上送。
我的做法是这样的：
- 定义统一数据模型： 每个数据点包含
deviceId、metric、value、timestamp、quality五个字段。 - 编写协议驱动： 每种协议写一个驱动插件，负责把协议特有的数据格式转成统一模型。
- 配置驱动映射： 通过配置文件或 Web 界面，把物理设备的数据点映射到统一模型。
// 统一数据模型示例（JSON）
{
"deviceId": "sensor_temp_001",
"metric": "temperature",
"value": 25.3,
"timestamp": 1712345678000,
"quality": "good" // good / bad / uncertain
}
2.4 本章知识体系图
下面这张图，把数据采集层的核心逻辑串起来了。你可以把它当作「施工蓝图」来用。
嗯，这张图你看懂了吗？从下往上，物理设备通过三种协议接入，经过统一抽象层「翻译」成标准格式，再由边缘网关做初步处理，最后上云。每一层各司其职，缺一不可。
公众号:蓝海资料掘金营，微信deep3321