3、通信协议与数据采集：Modbus TCP/RTU协议详解、OPC UA协议集成、数据采集服务开发
各位同行，大家好。这一章我们聊聊通信协议与数据采集。说实话，这是整个监控系统的“神经末梢”。数据采不上来，后面做再漂亮的界面、再牛的分析，都是空中楼阁。我自己在风场调试时，最怕的就是半夜被电话叫醒，说“数据不动了”。嗯，咱们今天就把这块彻底讲透。
3.1 Modbus TCP/RTU 协议详解
Modbus 协议，说白了就是工业界的“普通话”。它简单、可靠，几乎所有风电设备——PLC、逆变器、测风塔——都支持。我见过最老的设备，2005年的，照样跑 Modbus RTU。
3.1.1 RTU 与 TCP 的区别
先看一张对比表，一目了然：
| 特性 | Modbus RTU | Modbus TCP |
|---|---|---|
| 物理层 | RS-232 / RS-485 | 以太网 |
| 传输距离 | 约 1200 米（RS-485） | 100 米（交换机可扩展） |
| 节点数 | 最多 32 个（无中继器） | 理论上无限制 |
| 校验方式 | CRC16 | TCP 协议自带校验 |
| 典型场景 | 老旧设备、长距离、强干扰 | 新站、高速率、集中监控 |
我个人习惯是：如果现场有以太网，优先用 TCP。为什么？调试方便啊！一根网线插电脑上，Wireshark 一抓包，什么问题都看得清清楚楚。RTU 就得拿串口转接器，还得算 CRC，麻烦不少。
3.1.2 数据模型与功能码
Modbus 的数据模型分四张表：
- 线圈（Coil）：可读可写，1 bit。比如“启动风机”、“复位故障”。
- 离散输入（Discrete Input）：只读，1 bit。比如“急停状态”、“断路器位置”。
- 输入寄存器（Input Register）：只读，16 bit。比如“风速”、“发电机温度”。
- 保持寄存器（Holding Register）：可读可写，16 bit。比如“功率设定值”、“PID 参数”。
常用的功能码就几个：
0x03：读保持寄存器0x04：读输入寄存器0x06：写单个保持寄存器0x10：写多个保持寄存器
举个例子，读取风机 1 号机（站号 1）的瞬时风速（地址 0x0020）：
// 请求报文（十六进制）
01 04 00 20 00 01 31 CA
// 解析：站号1，功能码04，起始地址0x0020，读取1个寄存器，CRC校验
// 响应报文
01 04 02 00 3C B9 86
// 解析：站号1，功能码04，数据长度2字节，数据值0x003C（即60，单位0.1m/s，实际风速6.0m/s）
3.1.3 避坑指南：RTU 的时序问题
另外，RS-485 总线要加终端电阻（120Ω），不然长距离通信时信号反射，数据会乱码。嗯，这个坑我踩过不止一次。
3.2 OPC UA 协议集成
Modbus 虽好，但有个硬伤：它只传“裸数据”。你读到一个寄存器值是 60，但不知道它代表什么。OPC UA 就不一样了，它自带“语义”。说白了，它告诉你“这个值是风机 1 号机的风速，单位是 m/s，量程是 0-50”。
现在新建的大型风场，尤其是需要和第三方系统（如电网调度、集团监控）对接的，基本都要求 OPC UA。我个人觉得，这是未来的趋势。
3.2.1 OPC UA 的核心概念
- 地址空间（Address Space）：所有数据都组织成“节点”，像一棵树。根节点是“Objects”，下面挂“风机1”、“风机2”……
- 变量（Variable）：具体的数值，比如“风速”、“功率”。
- 方法（Method）：可调用的操作，比如“启动风机”、“复位故障”。
- 订阅（Subscription）：客户端可以订阅变量，数据变化时服务器主动推送，不用轮询。
你想想看，Modbus 你得每秒轮询一次，100 台风机就是 100 次请求。OPC UA 用订阅模式，数据变了才发，网络压力小很多。
3.2.2 集成示例：用 open62541 库
我推荐用 open62541，开源、轻量、C 语言写的，很适合嵌入式环境。下面是一个简单的客户端代码，读取风机风速：
#include <open62541/client.h>
#include <open62541/client_config_default.h>
int main() {
UA_Client *client = UA_Client_new();
UA_ClientConfig_setDefault(UA_Client_getConfig(client));
// 连接到 OPC UA 服务器
UA_StatusCode retval = UA_Client_connect(client, "opc.tcp://192.168.1.100:4840");
if (retval != UA_STATUSCODE_GOOD) {
UA_Client_delete(client);
return 1;
}
// 读取节点 "ns=2;s=WindTurbine_01.WindSpeed"
UA_Variant value;
UA_Variant_init(&value);
retval = UA_Client_readValueAttribute(client,
UA_NODEID_STRING(2, "WindTurbine_01.WindSpeed"), &value);
if (retval == UA_STATUSCODE_GOOD && UA_Variant_hasScalarType(&value, &UA_TYPES[UA_TYPES_DOUBLE])) {
double windSpeed = *(UA_Double *)value.data;
printf("风速: %.2f m/s\n", windSpeed);
}
UA_Variant_clear(&value);
UA_Client_disconnect(client);
UA_Client_delete(client);
return 0;
}
3.2.3 集成时的常见问题
我遇到过最头疼的问题是“证书验证”。OPC UA 为了安全，默认要求客户端和服务器互相验证证书。第一次连接时，服务器会拒绝。解决办法是：在服务器端把客户端的证书添加到“信任列表”里。或者，在开发阶段直接关闭安全验证（不推荐生产环境用）。
3.3 数据采集服务开发
好了，协议讲完了，咱们聊聊怎么把这些东西落地成代码。数据采集服务，说白了就是一个“搬运工”——把设备的数据搬进实时数据库。
3.3.1 架构设计
我习惯用三层架构：
- 驱动层：负责和具体设备通信。Modbus 驱动、OPC UA 驱动、IEC 104 驱动……每种协议一个驱动。
- 数据管道层：负责数据清洗、协议转换、缓存。比如把 Modbus 的原始值乘以缩放系数，变成物理值。
- 存储层：写入实时数据库（如 InfluxDB、PI System）或关系库（如 MySQL）。
下面这张图，是我自己总结的采集服务核心逻辑：
3.3.2 代码实现要点
我一般用 C# 写采集服务，因为 .NET 的异步编程模型很适合 IO 密集型的任务。核心逻辑就是一个 while(true) 循环，里面跑着各个驱动的轮询任务。
// 伪代码：采集服务主循环
public class DataAcquisitionService
{
private List<IDriver> _drivers; // Modbus驱动、OPC UA驱动等
private DataPipeline _pipeline; // 数据管道
public async Task RunAsync()
{
while (true)
{
// 并行采集所有驱动
var tasks = _drivers.Select(driver => driver.CollectAsync());
var results = await Task.WhenAll(tasks);
// 处理采集结果
foreach (var result in results)
{
_pipeline.Process(result);
}
// 控制采集间隔，避免CPU跑满
await Task.Delay(100); // 100ms 轮询一次
}
}
}
3.3.3 数据质量标记
采集上来的数据，不全是“好”的。设备断线、通信超时、数值越限……这些情况都要标记。我习惯在数据点里加一个 Quality 字段：
- Good：数据正常
- Bad_Timeout：通信超时
- Bad_OutOfRange：数值超出量程
- Uncertain：设备处于启动/停止过渡态，数据可能不准
为什么要这么做？因为上层做告警分析时，不能把“坏数据”当成真实值。比如风机停机时，风速传感器可能读到 0，但你不能真的认为“没风了”。
1. 把数据从设备“拿”出来（驱动层）
2. 把数据“洗”干净（管道层）
3. 把数据“存”起来（存储层）
每一层都有坑，但踩过去之后，系统就会很稳。
好了，这一章的内容就到这儿。通信协议和数据采集是基本功，但也是最容易出问题的地方。希望我分享的这些经验，能帮大家少走一些弯路。