3、通信协议详解：IEC 104规约、MQTT协议、HTTPS API、本地通信（Modbus/RS485）、协议选型对比
各位同行，大家好。这一章我们来聊聊通信协议。
说实话，做VPP聚合商接入，最头疼的往往不是业务逻辑，而是通信协议。我见过太多项目，前期没把协议选型当回事，结果联调时发现数据上不来、指令下不去，最后只能推倒重来。嗯，今天我就把这几种主流协议掰开揉碎了讲清楚。
3.1 IEC 104规约：电力系统的“普通话”
IEC 104，全称是IEC 60870-5-104。说白了，它就是电力系统里的“普通话”。省级VPP平台跟变电站、大型光伏电站通信，基本都用它。
核心特点：
- 面向连接：基于TCP/IP，端口号2404。先建立连接，再传数据。
- 遥测、遥信、遥控、遥调：四遥功能全覆盖。遥测是模拟量（电压、电流），遥信是状态量（开关分合），遥控是下发指令，遥调是设定值调整。
- ASDU格式：应用服务数据单元，结构固定。我刚开始看ASDU时觉得头大，后来发现其实就是个“信封”，里面装着类型标识、传送原因、信息体地址这些字段。
我在项目中遇到过一个问题：某光伏电站用104规约上报数据，但平台总是收不到遥测值。排查了半天，发现是信息体地址没对齐。电站侧用的是0-65535的地址范围，平台侧默认是1-65536。差一个数，全乱套。所以，地址映射表一定要提前对齐。
我的习惯：做104接入时，先让厂家导出一份完整的“点表”，包括每个信息体地址对应的物理量、单位、系数。然后逐条核对，别偷懒。
3.2 MQTT协议：轻量级物联网“快递员”
MQTT，Message Queuing Telemetry Transport。名字挺长，但核心就三个字：轻、快、省。
为什么VPP里要用MQTT？因为很多中小型聚合商接的是分布式光伏、储能、充电桩，这些设备数量多、分布广，而且网络环境不稳定。用104规约太重了，MQTT正好合适。
MQTT的关键机制是发布/订阅模式。设备端发布消息到某个主题（Topic），平台端订阅这个主题，就能收到消息。反过来也一样。
// 伪代码示例：MQTT客户端发布遥测数据
client.publish("vpp/station_001/telemetry",
"{\"voltage\": 220.5, \"current\": 10.2, \"power\": 2249.1}");
这里要注意QoS（服务质量）等级。QoS 0最多发一次，丢了不管；QoS 1至少发一次，可能重复；QoS 2恰好发一次，最可靠但最慢。我建议遥测数据用QoS 1，遥控指令用QoS 2。为什么？遥测丢一帧问题不大，但遥控指令重复执行可能出事故。
避坑指南：我曾经遇到一个项目，MQTT Broker（消息代理）配置了默认的keepalive时间，结果设备网络闪断后，Broker没及时检测到，导致数据积压。后来我把keepalive设成了30秒，并启用了Last Will Testament（遗嘱消息），设备离线时自动通知平台。
3.3 HTTPS API：RESTful风格的“标准接口”
HTTPS API，说白了就是通过HTTP协议调用的接口，数据格式通常是JSON。省级VPP平台现在越来越喜欢用这个，因为它简单、通用、好调试。
典型的场景是：聚合商平台定时调用VPP平台的API，上报聚合数据，或者查询调度指令。
// 示例：POST请求上报聚合功率
POST /api/v1/aggregator/report
Content-Type: application/json
Authorization: Bearer <token>
{
"aggregator_id": "AGG001",
"timestamp": "2025-03-21T10:00:00Z",
"total_power": 12500.5,
"power_units": [
{"unit_id": "PV001", "power": 5000.2},
{"unit_id": "ES001", "power": -2000.0},
{"unit_id": "CP001", "power": 7500.3}
]
}
HTTPS API的好处是生态成熟。用Postman就能调试，用Swagger就能生成文档。但缺点也很明显：实时性差。每次请求都要建立TCP连接、TLS握手，延迟通常在几百毫秒到几秒。所以它适合分钟级的数据上报，不适合毫秒级的控制。
我的建议：API的鉴权一定要用Token，别用简单的API Key。Token有过期时间，可以定期刷新，安全性高很多。另外，接口要设计幂等性，防止重复请求导致数据错误。
3.4 本地通信：Modbus/RS485
Modbus/RS485是“老黄牛”了。在设备端，比如逆变器、电表、BMS（电池管理系统），几乎清一色用Modbus。
RS485是物理层，Modbus是应用层。Modbus有两种模式：RTU（二进制）和TCP（网络）。在VPP场景里，聚合商边缘网关通常通过RS485总线采集设备数据，然后转换成MQTT或104上报给平台。
// Modbus RTU读取寄存器示例（伪代码）
// 读取地址为1的设备，起始寄存器0，读取2个寄存器
send: 01 03 00 00 00 02 C4 0B
recv: 01 03 04 02 1E 00 64 7A 9C
// 解析：电压=0x021E=542（实际值需乘以系数），电流=0x0064=100
Modbus有个坑：寄存器地址和协议地址经常搞混。有些厂家文档写的是“寄存器地址40001”，对应Modbus协议地址是0。你直接填40001去读，肯定读不到。我一般会跟厂家确认：你们用的是PLC地址还是Modbus地址？
避坑指南：我曾经调试一个储能BMS，Modbus通信总是超时。后来发现是RS485总线上接了太多设备，而且终端电阻没加。RS485总线两端必须各加一个120欧姆的终端电阻，否则信号反射会导致通信错误。另外，波特率别设太高，9600或19200最稳。
3.5 协议选型对比
好了，四种协议都讲完了。那到底怎么选？我画了一张对比表，你一看就明白。
| 特性 | IEC 104 | MQTT | HTTPS API | Modbus/RS485 |
|---|---|---|---|---|
| 适用层级 | 站控层到平台 | 设备/网关到平台 | 聚合商到平台 | 设备到网关 |
| 实时性 | 高（秒级） | 中（秒级） | 低（分钟级） | 高（毫秒级） |
| 可靠性 | 高（有确认机制） | 中（依赖QoS） | 高（HTTP状态码） | 中（无确认） |
| 数据量 | 大（支持批量） | 小（单条消息） | 中（JSON结构） | 小（寄存器级） |
| 安全性 | 弱（需额外加密） | 中（TLS+认证） | 强（HTTPS+Token） | 弱（无加密） |
| 开发难度 | 高（协议复杂） | 低（库丰富） | 低（RESTful） | 低（简单指令） |
| 典型场景 | 光伏站、变电站 | 分布式储能、充电桩 | 聚合商数据上报 | 逆变器、电表采集 |
选型时，我一般遵循这个原则：
- 设备端到网关：用Modbus/RS485，简单可靠。
- 网关到平台（实时控制）：用IEC 104，符合电力标准。
- 网关到平台（非实时数据）：用MQTT，轻量灵活。
- 聚合商到省级平台（业务接口）：用HTTPS API，通用易集成。
你想想看，如果一个充电桩用104规约上报数据，那开发成本得多高？反过来，一个220kV变电站用MQTT上报，平台敢信吗？所以，选对协议，事半功倍。
核心逻辑图：下面这张图展示了VPP通信协议的分层架构，从设备端到省级平台，每一层用什么协议，一目了然。
好了，这一章的内容就到这里。通信协议这块，说白了就是“因地制宜”。没有最好的协议，只有最合适的协议。你只要把每种协议的特点、适用场景、常见坑点记牢了，做接入时就能少走弯路。