3、数据采集与通信协议：IEC 61850、Modbus、MQTT在VPP中的应用

各位同行，咱们今天聊聊VPP里的“神经末梢”——数据采集和通信协议。说白了，VPP就是个“虚拟大管家”，它得知道每个分布式资源（光伏、储能、充电桩）的实时状态，才能发号施令。这个“知道”的过程，就是数据采集。而通信协议，就是它们之间沟通的“语言”。

我这些年做VPP项目，最深的感触就是：协议选不对，后面全白费。今天我就把IEC 61850、Modbus、MQTT这三兄弟在VPP里的用法，掰开了揉碎了讲清楚。

3.1 三大协议：各显神通

先说说这三位的定位。你可以这么理解：

• Modbus：老黄牛，皮实耐用，专治各种不服。几乎所有PLC、电表、逆变器都支持它。
• IEC 61850：高富帅，变电站和新能源场站的标配，自带“自描述”能力，数据模型非常标准。
• MQTT：轻骑兵，专为物联网而生，发布/订阅模式，天生适合海量设备接入。

嗯，这里要注意：VPP里不是只用一种协议，而是混合使用。我见过一个项目，光伏用Modbus，储能用61850，温控负荷用MQTT，最后统一汇聚到VPP平台。这很常见。

3.1.1 Modbus：最通用的“翻译官”

Modbus是我用得最多的协议。为什么？因为几乎所有设备都支持它。它的核心就是“读寄存器”和“写寄存器”。

举个例子，你要读一个逆变器的有功功率：

// Modbus RTU 读取保持寄存器
功能码：0x03 (读保持寄存器)
起始地址：0x0040 (功率寄存器地址)
读取数量：0x0002 (32位浮点数占2个寄存器)
CRC校验：0xC40B

// 响应报文
功能码：0x03
字节数：0x04
数据：0x4120 0x0000 (浮点数10.0，表示10kW)
CRC校验：0x3F0A

我个人习惯，在VPP里用Modbus TCP多一些，因为走以太网，不用考虑RS485的接线问题。但要注意，Modbus是“主从”模式，VPP平台是主站，设备是从站。主站得轮询所有从站，设备一多，轮询周期就长。我曾经遇到一个项目，200多个逆变器，轮询一遍要30秒，根本没法做实时控制。

3.1.2 IEC 61850：变电站的“普通话”

IEC 61850，这名字听着就高大上。它不像Modbus那样只传“裸数据”，它自带数据模型。比如一个断路器，它不仅有“位置”这个数据，还有“位置”的语义——是“合”还是“分”，以及它的质量戳（是否有效）。

在VPP里，61850主要用于大型储能站和光伏电站。它的核心是“面向对象”的建模。举个例子：

// 逻辑节点：MMXU (测量单元)
// 数据对象：TotW (总有功功率)
// 数据属性：mag (幅值), q (品质), t (时标)

MMXU1.TotW.mag.f = 100.5  // 有功功率100.5MW
MMXU1.TotW.q = 0x00       // 品质良好
MMXU1.TotW.t = 2024-01-15T10:30:00.000  // 时标

你看，它把数据、品质、时标都打包在一起了。这在VPP里非常有用。为什么？因为VPP需要知道数据是否可信。如果一个设备离线了，它的数据品质会变成“无效”，VPP平台就不会用它来做决策。

我记得有一次，一个储能站上报的功率数据忽大忽小，排查了半天，发现是CT（电流互感器）接线松动。但61850的数据品质戳直接标记为“可疑”，我们一下子就定位到了问题。换成Modbus，你只能看到一堆乱跳的数字，根本不知道是设备坏了还是通信干扰。

3.1.3 MQTT：海量设备的“传声筒”

MQTT，说白了就是“物联网界的微信”。它采用发布/订阅模式，设备（发布者）把数据发到“主题”（Topic），VPP平台（订阅者）订阅这个主题就能收到数据。反过来，VPP平台也可以发布控制指令，设备订阅控制主题来接收。

在VPP里，MQTT特别适合接入海量的分布式资源，比如：

• 居民屋顶光伏（几千户）
• 电动汽车充电桩（几百个）
• 智能空调、热水器等温控负荷

你想想看，如果用Modbus轮询几千个设备，那得等到猴年马月？但MQTT是“事件驱动”的，设备有变化才上报，或者按固定周期（比如5秒）上报一次，VPP平台被动接收就行。这大大减轻了平台的通信压力。

一个典型的MQTT数据包长这样：

// 主题：vpp/device/pv001/data
// 载荷（JSON格式）：
{
  "device_id": "PV001",
  "timestamp": "2024-01-15T10:30:00.000Z",
  "metrics": {
    "active_power": 5.2,      // 有功功率，单位kW
    "reactive_power": 0.1,    // 无功功率，单位kVar
    "voltage": 220.5,         // 电压，单位V
    "current": 23.6           // 电流，单位A
  }
}

3.2 数据采集架构设计：分层解耦

协议选好了，怎么搭采集架构？我建议采用“分层解耦”的思路。说白了，就是把采集功能拆成几层，每层各司其职，互不干扰。

下面这张图，是我在多个VPP项目里沉淀下来的架构，你可以参考：

这个架构的核心思想是：设备层只负责“说话”，网关层负责“翻译”，通信层负责“传话”，平台层负责“理解”。每一层都可以独立升级、替换，互不影响。

3.2.1 设备层：百花齐放

设备层就是那些分布式资源。它们用的协议五花八门：

设备类型	常用协议	数据特点	采集频率
光伏逆变器	Modbus RTU/TCP	功率、电压、电流、发电量	1-5秒
储能BMS	IEC 61850 / Modbus	SOC、SOH、电压、温度、充放电功率	0.1-1秒
充电桩	OCPP / Modbus / MQTT	充电状态、功率、电量、车辆信息	1-10秒
智能电表	DL/T 645 / Modbus	有功/无功电量、功率因数、需量	15分钟-1小时
温控负荷	MQTT / HTTP	开关状态、设定温度、实际温度	10-60秒

你看，不同设备的数据特点差异很大。储能BMS要求毫秒级响应，智能电表15分钟采集一次就行。所以，采集架构必须能适配不同的采集频率。

3.2.2 采集网关层：承上启下

网关层是VPP的“神经中枢”。它负责：

• 协议转换：把Modbus、61850等“方言”转成统一的MQTT“普通话”
• 数据汇聚：把多个设备的数据打包，减少网络连接数
• 边缘计算：在网关本地做简单的数据处理，比如滤波、异常检测、数据压缩
• 断点续传：网络断了，数据先存本地，网络恢复后自动补传

我个人习惯，在网关里做一层“数据清洗”。比如，有些老旧的Modbus设备，偶尔会冒出个“65535”这种无效值。网关直接把它过滤掉，别让它污染平台的数据质量。

3.2.3 通信层：稳定可靠

通信层是VPP的“高速公路”。我建议用MQTT Broker作为核心。为什么？

• 解耦：设备和平台不直接通信，通过Broker中转，谁挂了都不影响对方
• 可扩展：加设备，只需要订阅新的Topic，不用改平台代码
• 安全：支持TLS加密，支持用户名/密码认证，支持ACL（访问控制列表）

嗯，这里要注意：Broker的选型很重要。小项目用Mosquitto就行，大项目（上万设备）得用EMQX或NanoMQ这类高性能Broker。我见过一个项目，用Mosquitto接了5000个设备，结果Broker直接OOM（内存溢出）了。

3.2.4 平台层：数据变现

平台层是VPP的“大脑”。数据到了这里，要经过：

1. 数据解析：把JSON、二进制等格式解析成内部数据结构
2. 实时数据库：存最新的数据，供实时监控和调度用（比如Redis）
3. 时序数据库：存历史数据，供分析和预测用（比如InfluxDB、TimescaleDB）
4. 应用服务：资源聚合、功率预测、优化调度、市场交易

说白了，前面的所有工作，都是为了平台层能“算得准、调得快”。数据质量不行，再牛的算法也是白搭。

---

好了，关于数据采集和通信协议，我就讲这么多。记住一句话：协议选型看场景，架构设计看规模。小项目用Modbus+MQTT就够了，大项目得上61850+高性能Broker。下一章，咱们聊聊VPP的“大脑”——资源聚合与优化调度。