4. 通信与信息架构

虚拟电厂(VPP)的调度能力,本质上取决于它能否在正确的时间、以可接受的时延,把分散在成百上千个站点上的可调资源状态汇聚到云端,并把调度指令可靠地下发到每一个终端。因此,通信与信息架构不是 VPP 的“配套设施”,而是决定其可调容量上限、响应速度和结算可信度的核心底座。本节围绕三条主线展开:终端与平台之间用什么协议对话、数据如何被采集与监控、云与边如何分工协同。

一、通信协议:分层选型,而非单一协议打天下

VPP 的通信链路通常分为三段:站内设备层(逆变器、储能 PCS、BMS、充电桩、电表)、边缘汇聚层(边缘网关/EMS)、云平台层。三段对协议的要求完全不同,必须分层选型。

站内设备层以工业现场总线与电力规约为主。常见组合是:光伏逆变器与储能 PCS 走 Modbus TCP/RTU,电表走 DL/T 645 或 IEC 61850 MMS,BMS 走 CAN 总线 或厂商私有协议。这一层的特征是设备异构、刷新率高(秒级)、但通信范围局限在站内局域网。

边缘到云端则更适合用面向广域网的物联网协议。MQTT 采用发布/订阅模型,天然支持海量终端、断线重连和 QoS 分级,是遥测数据上行的主流选择;IEC 60870-5-104 与 IEC 61850 则用于需要与电网调度主站对接的场景,满足电力系统对遥测、遥信、遥调、遥控“四遥”的规范性要求。控制指令下行若要求毫秒级确定性,可考虑 OPC UA over TSN 或专用光纤通道。

选型时需重点权衡四个参数:单点数据刷新周期、端到端时延上限、单连接并发终端数、以及是否要求时间同步。例如一次调频类辅助服务通常要求端到端时延小于 1 秒,而日前能量申报类业务分钟级即可满足。协议选错,后续再优化业务逻辑也无法弥补。

二、数据采集与监控:从“采得到”到“采得准”

数据采集的核心不是把所有点位都上传,而是按业务价值分级。工程上通常把测点分为三类:

  • 实时控制类:有功/无功功率、SOC、可调上下限、开关状态,刷新周期 1~5 秒,用于闭环调度;
  • 状态监视类:温度、告警字、通信质量、设备在线状态,刷新周期 10~60 秒,用于运维;
  • 统计结算类:电量、充放电量、可用率,刷新周期 15 分钟或按结算周期,用于计量与考核。

采集链路一般遵循“边缘网关轮询设备 → 本地缓存与预处理 → 按主题发布上云 → 云端时序库落库 → 监控与告警”的顺序。边缘侧必须做三件事:一是数据清洗,剔除跳变与坏点;二是时间戳对齐,统一采用 UTC 或带时区标记,避免跨区域站点结算错位;三是断点续传,网络中断时本地缓存,恢复后补传,防止数据缺口影响可调容量评估。

监控看板应至少覆盖三类视图:站点在线率与通信质量、实时可调容量与 SOC 分布、指令下发成功率与响应时延。这三项直接对应 VPP 能否被调度机构信任。

三、云边协同机制:把“快”留在边缘,把“全局”放在云端

云边协同的分工原则是:时延敏感、安全关键的逻辑下沉到边缘;全局优化、跨站点聚合、结算与市场申报放在云端。

边缘侧负责本地闭环:接收云端下发的功率目标值,结合本站 SOC、设备约束和并网点限值,分解为各 PCS/逆变器的具体指令,并在通信中断时按预设策略自主运行(如 SOC 低于下限自动停止放电)。云端负责全局:聚合各站点可调能力,参与调峰、调频、需求响应等市场,生成调度计划并下发。

协同的关键在于指令模型的一致性。云端下发的不应是“把 3 号 PCS 调到 50 kW”这类设备级指令,而应是“本站未来 15 分钟目标功率 200 kW、爬坡率不超过 100 kW/min”这类站点级目标,由边缘自行分解。这样既降低云端计算与通信负担,也让边缘在断连时仍能维持基本响应。

下面这张图展示了从站内设备到云平台的完整信息流,以及云边两侧的职责边界。

云平台层(全局优化 · 市场申报 · 结算) 可调容量聚合 跨站点能力评估 调度计划生成 调峰/调频/需求响应 时序数据库 遥测/遥信/电量 监控告警与结算 在线率/响应时延/电量 遥测上行 MQTT / IEC 104 指令下行 站点级目标值 边缘汇聚层(本地闭环 · 断连自治 · 数据预处理) 协议转换网关 Modbus→MQTT DL/T645→IEC104 本地EMS控制器 功率分解与分配 SOC约束校验 数据缓存与清洗 断点续传 时间戳对齐 安全隔离 纵向加密 访问白名单 站内设备层(异构设备 · 秒级刷新 · 现场总线) 光伏逆变器 Modbus TCP 储能 PCS/BMS Modbus / CAN 智能电表 DL/T 645 充电桩 OCPP / Modbus 环境 传感器 数据上行 指令下行 站内采集

四、一个可参考的协同配置示例

假设某 VPP 接入 50 个工商业储能站点,参与日前调峰。云端与边缘的协同参数可按如下方式设定(示例参数,需按实际设备与市场规则调整):

云端下发(站点级目标):
  target_power_kw: 200
  ramp_limit_kw_per_min: 100
  valid_from: 2025-06-01T14:00:00+08:00
  valid_to:   2025-06-01T14:15:00+08:00
  fallback_policy: hold_last / stop_discharge

边缘执行(本地分解):
  采样周期: 2 s
  控制周期: 5 s
  SOC下限: 15%   SOC上限: 95%
  并网点限值: 250 kW
  断连自治: SOC<15% 停止放电,SOC>95% 停止充电

上行遥测(MQTT主题):
  vpp/{station_id}/telemetry  周期 5 s
  vpp/{station_id}/alarm      事件触发
  vpp/{station_id}/meter      周期 15 min

判断协同是否正常,可观察三个指标:指令下发成功率应接近 100%,端到端响应时延中位数应低于 3 秒,遥测数据完整率应高于 99%。若响应时延持续偏高,优先排查边缘网关的轮询周期与网络链路,而非直接调整云端调度算法。

常见误区:把云端当作“实时控制器”,每秒向每个站点下发设备级指令。这会造成通信拥塞、云端算力浪费,且一旦断网站点立即失控。正确做法是云端下发目标、边缘负责分解与自治。

综上,通信协议解决“用什么语言对话”,数据采集与监控解决“采什么、采得准不准”,云边协同解决“谁在什么时候做决定”。三者共同构成 VPP 的信息骨架,也决定了它能否从“能看”走向“能调、能结算”。