2026/9/17 13:29:10
FEATURED · 精选文章 
简介《虚拟电厂总体规划建设方案》以PPT形式呈现面向能源电力从业者、综合能源服务人员及电气类专业师生可用于快速理解虚拟电厂从概念到落地的规划思路。全包共1个pptx文件约6.49MB以图文幻灯片承载完整方案框架便于直接演示或按需改写。内容按背景分析、总体分析、系统架构、业务规划与未来展望展开先梳理新能源高比例接入带来的潮流改变、电压波动、电能质量与保护、孤岛等问题界定虚拟电厂“聚合”与“通信”两大关键点并对比其与微网在控制目标和地理范围上的差异区分商业型与技术型虚拟电厂。还涉及智能调控、通信技术、多元聚合等技术架构以及辅助服务、需求响应、市场化交易、能效管理等业务方向并结合冀北、上海等地运营数据做效益分析。现有754人学习适合需要搭建规划框架、撰写汇报材料的读者参考。1. 一份虚拟电厂总体规划建设方案先回答可调容量凭什么可信很多团队写虚拟电厂总体规划建设方案第一版目录通常是平台架构、接入资源、通信方案、商业模式、投资估算。看着齐全评审时却常被一句你凭什么说这 5 万千瓦调得动问住。虚拟电厂与传统电站最大的差别在于容量不属于自己而是散落在几十上百个用户的空调、储能、充电桩和产线上签了约不等于可调可调不等于按时响应。所以总体规划的第一个交付物不是拓扑图而是一套能被调度和交易机构认可的可调容量测算与验证口径这也决定了方案的其余部分怎么写。它适合做聚合平台的产品与研发、负责园区能源改造的工程人员以及为项目立项把关的技术负责人。下面按建模、调度、数据链路、验证四段推进每段都给出能直接抄的参数和代码。2. 虚拟电厂总体规划中的资源分层与可调容量建模2.1 资源层、聚合层、调控层的职责边界规划方案里最容易画错的是分层。不少版本把平台当成一个盒子从终端设备到调度接口全塞进去实施时才发现设备侧没人负责、接口对不上口径。更贴近工程的切法是三层资源层负责把物理设备的状态和可控边界采集上来聚合层负责把分散的小容量拼成可申报的大容量调控层负责接收邀约或调度指令并回传执行结果。三层的边界不是按软件模块划的而是按谁对哪个数字负责划的。资源层的核心输出是实时功率、可控上下限和可用状态时间尺度在秒级到分钟级聚合层要输出基线、聚合可调容量和指令分解结果节奏通常与 15 分钟结算周期对齐调控层则是日前邀约、实时指令和考核结算周期从 15 分钟到日前不等。方案的正文结构最好与这三层一一对应否则文档写给评审看实施时又要重新拆一遍。层级典型组件时间尺度关键输出资源层空调控制器、储能 PCS、充电桩、边缘网关秒级到分钟级实时功率、SOC、可调上下限聚合层聚合平台、能量管理系统、负荷预测服务分钟级到 15 分钟聚合可调容量、基线、指令分解调控层调度自动化系统、交易平台、需求响应平台15 分钟到日前邀约、出清结果、考核结算数据提示三层之间要约定可调容量的口径——是交流侧还是直流侧、是并网点计量还是设备本体、是否扣除厂用电。口径不一致会让同一批资源算出两个相差两三成的数字。2.2 四类资源的可调容量折算方法与代码把设备折算成千瓦是这份方案里最需要写细的一节。常见做法是按资源类型分别给出折算系数而不是统一乘一个同时率。空调类负荷走短时轮停可调容量按额定功率、可中断比例和同时率三者相乘可中断比例一般取 0.2 到 0.3同时率取 0.6 到 0.8具体看建筑类型和室外温度。储能不用系数直接受功率和能量双重约束取两者较小值。充电桩看的是有充电需求且允许顺延的那部分比例常在 0.3 到 0.5 之间。工业负荷按合同约定的可中断段算必须逐户确认不能按行业平均值估。def adj_capacity(res_list, dt_min15, soc_floor0.2, soc_ceil0.9): 估算聚合可调容量返回上调、下调两个数值单位 kW res_list: 资源列表每条含 type / rated_kw / 以及该类资源特有字段 dt_min: 本次响应的持续时长分钟储能受能量约束时必须传入 up, down 0.0, 0.0 for r in res_list: t r[type] if t ac: # 空调轮停 p r[rated_kw] * r.get(k_interrupt, 0.25) * r.get(k_simul, 0.7) up p # 压负荷视作对电网的上调能力 down p * 0.3 # 回弹功率有限只计三成 elif t storage: # 储能双向 p_rated r[rated_kw] e_avail r[cap_kwh] * (min(r[soc], soc_ceil) - soc_floor) p_energy e_avail / (dt_min / 60.0) # 能量换算成功率 up min(p_rated, max(p_energy, 0)) down p_rated * (1 - r[soc]) # 充电方向余量 elif t charger: # 充电桩可延迟 p r[rated_kw] * r.get(k_delay, 0.4) up p elif t industry: # 工业可中断段来自合同 up r.get(contract_kw, 0.0) return round(up, 1), round(down, 1)这段代码里有两个容易忽略的点。一是储能的能量约束同样一台 500 kW / 1000 kWh 的储能响应 15 分钟和响应 2 小时可调容量完全不是一回事p_energy这一项就是干这个的。二是空调的回弹压下去之后设备还要把温度拉回来所以下调能力只按三成计写进方案时最好单独注明避免结算时被认定虚报。2.3 资源台账字段与建表语句方案里不要只给一张 Excel 模板直接给建表语句后续接入开发不用再翻译一遍。台账的关键在于把合同容量和实测可调容量分开存两者差得越多越需要在方案里写明补充措施。CREATE TABLE vpp_resource ( res_id VARCHAR(32) PRIMARY KEY, -- 资源唯一编码建议 主体编码序号 vpp_id VARCHAR(32) NOT NULL, -- 所属虚拟电厂/聚合单元 res_type VARCHAR(16) NOT NULL, -- ac / storage / charger / industry rated_kw DECIMAL(10,2) NOT NULL, -- 额定功率交流侧并网点口径 cap_kwh DECIMAL(12,2) DEFAULT 0, -- 储能容量非储能资源为 0 contract_kw DECIMAL(10,2) DEFAULT 0, -- 合同约定的可调容量 meter_kw DECIMAL(10,2) DEFAULT 0, -- 最近一次实测可调容量 soc DECIMAL(5,4), -- 储能荷电状态其余为 NULL online TINYINT DEFAULT 1, -- 在线状态 gateway_sn VARCHAR(64), -- 边缘网关序列号用于定位 updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_vpp_type (vpp_id, res_type) ) COMMENT虚拟电厂资源台账;contract_kw和meter_kw两列并存是为了在方案评审时能说清签约 8 万千瓦、实测 5.2 万千瓦这件事。gateway_sn这一列在排障时价值很高一旦某个网关掉线能立刻圈出受影响的资源集合和容量缺口。3. 从聚合到调度需求响应指令下发与响应闭环3.1 基线负荷的三种算法与代码基线是结算的起点算法必须是事先约定好的、双方都认的那一种。平均法最常用取响应日前若干个工作日的同时段负荷去掉其中最高的若干点再取均值最后乘一个修正系数。最大负荷法偏向用户一般只在特定季节使用。回归法精度最高但对历史数据质量要求高方案里可以作为二期内容列出来。import statistics as st def baseline(hist, event_day, n_days5, trim1, adj1.0): 计算需求响应基线负荷 hist: {日期: [96 个 15 分钟功率点]}已按日期排序 event_day: 响应日需从历史中剔除 n_days: 取参考日的天数 trim: 每个时段剔除的最大值个数 adj: 修正系数按当地规则取常见 0.9~1.1 days [d for d in hist if d event_day][-n_days:] # 只取响应日之前 points len(hist[days[0]]) base [] for i in range(points): vals sorted(hist[d][i] for d in days) kept vals[:len(vals) - trim] if trim else vals # 去掉顶峰点 base.append(round(st.mean(kept) * adj, 2)) return base调用时把节假日和检修日从hist里排除掉否则基线会被异常的低负荷拉偏。trim取 1 表示每天剔一个最大值规则里怎么写就怎么实现别在代码里自作主张。基线算完之后响应量就是基线与实测负荷的差值积分需要按 15 分钟粒度逐点算再汇总成响应电量。3.2 指令下发与回执MQTT 主题与超时重试聚合层往下走指令最省事的通道是 MQTT。主题设计要在方案里定死不要等开发时再拍脑袋。下行指令用 QoS 1遥测用 QoS 0回执用 QoS 1这是比较常见的组合。主题方向QoS载荷要点vpp/{vppId}/cmd/{resId}下行1指令号、上调/下调、目标功率、起止时间vpp/{vppId}/ack/{resId}上行1指令号、执行结果、失败原因码vpp/{vppId}/tele/{resId}上行0实时功率、SOC、在线状态import json, time import paho.mqtt.client as mqtt PENDING {} # 指令号 - 下发时间戳用于超时判断 def send_cmd(cli, vpp_id, res_id, cmd_no, target_kw, ts_end, timeout30): payload {cmdNo: cmd_no, targetKw: target_kw, tsEnd: ts_end, dir: up if target_kw 0 else down} cli.publish(fvpp/{vpp_id}/cmd/{res_id}, json.dumps(payload), qos1) PENDING[cmd_no] time.time() return cmd_no def on_message(cli, userdata, msg): 收到回执后清除待确认记录未回执的由巡检线程重下 data json.loads(msg.payload) PENDING.pop(data.get(cmdNo), None) def retry_loop(cli, vpp_id, res_id, gap120): while True: now time.time() for cmd_no, t0 in list(PENDING.items()): if now - t0 gap: # 超过两个周期没回执 cli.publish(fvpp/{vpp_id}/cmd/{res_id}, json.dumps({cmdNo: cmd_no, retry: True}), qos1) PENDING[cmd_no] now time.sleep(5)gap不要小于一个采集周期否则会重复下发。重试要带retry标记设备侧据此判断是覆盖还是忽略避免同一台设备收到两条互相冲突的指令。3.3 响应率与偏差考核的数据口径方案里必须写清楚考核怎么算否则结算日一定扯皮。常用的三个指标是响应率、偏差率和到位时间。指标计算口径常见阈值响应率实际响应量 / 指令响应量不低于 80%偏差率各时段偏差绝对值之和 / 指令总量不高于 15%到位时间从下发到达到 90% 目标功率的耗时视资源类型约定空调 15 分钟内-- 按 15 分钟时段统计单条指令的响应量与偏差 SELECT cmd_no, SUM(actual_kw) * 0.25 AS actual_kwh, -- 15 分钟即 0.25 小时 SUM(target_kw) * 0.25 AS target_kwh, SUM(ABS(actual_kw - target_kw)) * 0.25 / NULLIF(SUM(ABS(target_kw)) * 0.25, 0) AS dev_ratio FROM vpp_response_15m WHERE vpp_id ? AND biz_date ? GROUP BY cmd_no;这里用绝对值求和而不是代数求和是因为正偏差和负偏差抵消后看起来很准实际上下调多了和少调了都要考核。方案落地时把这条 SQL 的口径写进结算说明验收环节能省掉大量沟通。4. 虚拟电厂总体规划的数据链路计量、通信与边缘接入4.1 采集频率与协议选型协议选型取决于设备本体不是取决于平台偏好。规划阶段最好按对象分档站内设备走 Modbus 或 IEC 104分散的楼宇设备走 MQTT电表数据靠已有的采集终端转发。频率也不宜一刀切秒级数据只对调频类资源有意义常规负荷 15 分钟足够。协议适用对象典型周期说明Modbus TCP储能 PCS、充电桩1 到 5 秒点表简单需约定寄存器地址映射IEC 104站内保护与测控装置1 到 15 秒遥测变化上送注意品质位处理MQTT楼宇空调、分散网关15 秒到 15 分钟弱网环境友好需自建主题规范平台转发已有电表采集系统15 分钟直接对接数据库或接口不重复采集注意同一种资源不要同时走两条通道送数双通道在时序库里会产生重复点后续做响应率统计时会把同一个 15 分钟算两遍。4.2 时序表结构与写入参数遥测数据量在方案里通常被低估。一个 500 台设备的项目按 15 秒上送一天就是约 288 万个点规划时必须给分区和压缩留出余量。CREATE TABLE vpp_telemetry ( res_id VARCHAR(32) NOT NULL, ts DATETIME(3) NOT NULL, p_kw DECIMAL(10,3), -- 有功功率 soc DECIMAL(5,4), -- 储能荷电状态 quality TINYINT DEFAULT 0, -- 0 正常 1 可疑 2 无效 PRIMARY KEY (res_id, ts) ) COMMENT资源遥测时序表; -- 按月分区便于冷数据归档 ALTER TABLE vpp_telemetry PARTITION BY RANGE (TO_DAYS(ts)) ( PARTITION p202601 VALUES LESS THAN (TO_DAYS(2026-02-01)), PARTITION p202602 VALUES LESS THAN (TO_DAYS(2026-03-01)) );写入侧建议批量提交单次 500 到 1000 行间隔一秒左右比逐条写入快一个量级。quality字段不要省采集器给出可疑点时打标记统计响应量时把可疑点剔除比事后猜测数据为什么跳变更省事。4.3 边缘网关的本地缓存与补传通信中断是常态方案里必须写明断网期间的数据怎么处理本地缓存、限长、断点续传。缓存长度按最长断网时长加一档余量设计一般 24 小时起步。# 边缘网关采集配置片段 collector: interval_ms: 15000 # 采集周期 points: [p_kw, soc, u_a, u_b, u_c] buffer: path: /data/buffer # 环形缓存目录 max_hours: 24 # 缓存时长上限超出按最旧覆盖 flush_batch: 800 # 单批上传条数 upload: url: https://vpp.example.local/api/v1/telemetry retry_backoff_s: [5, 15, 60, 300] # 退避重传 checkpoint: true # 记录上传位点重启后续传flush_batch与采集周期要对得上15 秒采一次、800 条一批大约 3 小时上传一批批量太大反而增加失败重传成本。checkpoint打开后网关重启会从上次位点继续不会整体重传这一项在方案验收时经常被单独拿出来测试。5. 规划方案的验证用仿真回测检验可调容量与响应精度5.1 回测要比对的三个数字方案写完不等于数字站得住。比较务实的做法是拿上一个月的实测数据做一次离线回测比对三组数字申报可调容量与实测可聚合容量、指令响应量与实际响应量、理论响应时长与实测到位时长。三组里头两组偏差超过两成说明建模系数需要重标定第三组超差多半是指令下发链路或设备侧执行策略的问题。回测不需要新写平台把台账表、遥测表和指令表导出来跑一遍就够。关键是回测用的系数必须与方案正文里写的完全一致否则回测只能证明代码自洽。5.2 一个最小回测脚本import pandas as pd def backtest(cap_df, tele_df, cmd_df, tol0.2): 回测虚拟电厂可调容量与响应精度 cap_df: res_id / vpp_id / adj_kw按 2.2 节折算得到 tele_df: res_id / cmd_no / base_kw / actual_kw15 分钟粒度 cmd_df: cmd_no / target_kw / act_ts / done_ts report {} # 1) 容量核对申报值与实测聚合值的偏差 declared cap_df[adj_kw].sum() measured tele_df[actual_kw].max() report[cap_dev] round((declared - measured) / measured, 3) # 2) 响应精度逐条指令算偏差率 g tele_df.groupby(cmd_no).apply( lambda x: (x[actual_kw] - x[base_kw]).sum()) t cmd_df.set_index(cmd_no)[target_kw] ratio (g / t).dropna() report[resp_rate] round(ratio.mean(), 3) # 平均响应率 report[under] int((ratio 1 - tol).sum()) # 响应不足条数 # 3) 到位时长从下发到完成的中位数单位分钟 dt (pd.to_datetime(cmd_df[done_ts]) - pd.to_datetime(cmd_df[act_ts])).dt.total_seconds() / 60 report[t90_min] round(dt.median(), 1) return report跑完这一遍方案里的数字就有了出处。实战里更值得花时间的是把under的指令逐条翻出来看是设备离线、是基线偏高还是指令目标本身超出了资源边界。这三类原因的处置方式完全不同——前者补网关运维中者调基线的trim和adj参数后者要在方案里修正可调容量的申报口径而不是在下一次响应里靠多签资源硬撑。本文还有配套的精品资源点击获取
虚拟电厂总体规划建设方案：可调容量测算与验证
简介《虚拟电厂总体规划建设方案》以PPT形式呈现面向能源电力从业者、综合能源服务人员及电气类专业师生可用于快速理解虚拟电厂从概念到落地的规划思路。全包共1个pptx文件约6.49MB以图文幻灯片承载完整方案框架便于直接演示或按需改写。内容按背景分析、总体分析、系统架构、业务规划与未来展望展开先梳理新能源高比例接入带来的潮流改变、电压波动、电能质量与保护、孤岛等问题界定虚拟电厂“聚合”与“通信”两大关键点并对比其与微网在控制目标和地理范围上的差异区分商业型与技术型虚拟电厂。还涉及智能调控、通信技术、多元聚合等技术架构以及辅助服务、需求响应、市场化交易、能效管理等业务方向并结合冀北、上海等地运营数据做效益分析。现有754人学习适合需要搭建规划框架、撰写汇报材料的读者参考。1. 一份虚拟电厂总体规划建设方案先回答可调容量凭什么可信很多团队写虚拟电厂总体规划建设方案第一版目录通常是平台架构、接入资源、通信方案、商业模式、投资估算。看着齐全评审时却常被一句你凭什么说这 5 万千瓦调得动问住。虚拟电厂与传统电站最大的差别在于容量不属于自己而是散落在几十上百个用户的空调、储能、充电桩和产线上签了约不等于可调可调不等于按时响应。所以总体规划的第一个交付物不是拓扑图而是一套能被调度和交易机构认可的可调容量测算与验证口径这也决定了方案的其余部分怎么写。它适合做聚合平台的产品与研发、负责园区能源改造的工程人员以及为项目立项把关的技术负责人。下面按建模、调度、数据链路、验证四段推进每段都给出能直接抄的参数和代码。2. 虚拟电厂总体规划中的资源分层与可调容量建模2.1 资源层、聚合层、调控层的职责边界规划方案里最容易画错的是分层。不少版本把平台当成一个盒子从终端设备到调度接口全塞进去实施时才发现设备侧没人负责、接口对不上口径。更贴近工程的切法是三层资源层负责把物理设备的状态和可控边界采集上来聚合层负责把分散的小容量拼成可申报的大容量调控层负责接收邀约或调度指令并回传执行结果。三层的边界不是按软件模块划的而是按谁对哪个数字负责划的。资源层的核心输出是实时功率、可控上下限和可用状态时间尺度在秒级到分钟级聚合层要输出基线、聚合可调容量和指令分解结果节奏通常与 15 分钟结算周期对齐调控层则是日前邀约、实时指令和考核结算周期从 15 分钟到日前不等。方案的正文结构最好与这三层一一对应否则文档写给评审看实施时又要重新拆一遍。层级典型组件时间尺度关键输出资源层空调控制器、储能 PCS、充电桩、边缘网关秒级到分钟级实时功率、SOC、可调上下限聚合层聚合平台、能量管理系统、负荷预测服务分钟级到 15 分钟聚合可调容量、基线、指令分解调控层调度自动化系统、交易平台、需求响应平台15 分钟到日前邀约、出清结果、考核结算数据提示三层之间要约定可调容量的口径——是交流侧还是直流侧、是并网点计量还是设备本体、是否扣除厂用电。口径不一致会让同一批资源算出两个相差两三成的数字。2.2 四类资源的可调容量折算方法与代码把设备折算成千瓦是这份方案里最需要写细的一节。常见做法是按资源类型分别给出折算系数而不是统一乘一个同时率。空调类负荷走短时轮停可调容量按额定功率、可中断比例和同时率三者相乘可中断比例一般取 0.2 到 0.3同时率取 0.6 到 0.8具体看建筑类型和室外温度。储能不用系数直接受功率和能量双重约束取两者较小值。充电桩看的是有充电需求且允许顺延的那部分比例常在 0.3 到 0.5 之间。工业负荷按合同约定的可中断段算必须逐户确认不能按行业平均值估。def adj_capacity(res_list, dt_min15, soc_floor0.2, soc_ceil0.9): 估算聚合可调容量返回上调、下调两个数值单位 kW res_list: 资源列表每条含 type / rated_kw / 以及该类资源特有字段 dt_min: 本次响应的持续时长分钟储能受能量约束时必须传入 up, down 0.0, 0.0 for r in res_list: t r[type] if t ac: # 空调轮停 p r[rated_kw] * r.get(k_interrupt, 0.25) * r.get(k_simul, 0.7) up p # 压负荷视作对电网的上调能力 down p * 0.3 # 回弹功率有限只计三成 elif t storage: # 储能双向 p_rated r[rated_kw] e_avail r[cap_kwh] * (min(r[soc], soc_ceil) - soc_floor) p_energy e_avail / (dt_min / 60.0) # 能量换算成功率 up min(p_rated, max(p_energy, 0)) down p_rated * (1 - r[soc]) # 充电方向余量 elif t charger: # 充电桩可延迟 p r[rated_kw] * r.get(k_delay, 0.4) up p elif t industry: # 工业可中断段来自合同 up r.get(contract_kw, 0.0) return round(up, 1), round(down, 1)这段代码里有两个容易忽略的点。一是储能的能量约束同样一台 500 kW / 1000 kWh 的储能响应 15 分钟和响应 2 小时可调容量完全不是一回事p_energy这一项就是干这个的。二是空调的回弹压下去之后设备还要把温度拉回来所以下调能力只按三成计写进方案时最好单独注明避免结算时被认定虚报。2.3 资源台账字段与建表语句方案里不要只给一张 Excel 模板直接给建表语句后续接入开发不用再翻译一遍。台账的关键在于把合同容量和实测可调容量分开存两者差得越多越需要在方案里写明补充措施。CREATE TABLE vpp_resource ( res_id VARCHAR(32) PRIMARY KEY, -- 资源唯一编码建议 主体编码序号 vpp_id VARCHAR(32) NOT NULL, -- 所属虚拟电厂/聚合单元 res_type VARCHAR(16) NOT NULL, -- ac / storage / charger / industry rated_kw DECIMAL(10,2) NOT NULL, -- 额定功率交流侧并网点口径 cap_kwh DECIMAL(12,2) DEFAULT 0, -- 储能容量非储能资源为 0 contract_kw DECIMAL(10,2) DEFAULT 0, -- 合同约定的可调容量 meter_kw DECIMAL(10,2) DEFAULT 0, -- 最近一次实测可调容量 soc DECIMAL(5,4), -- 储能荷电状态其余为 NULL online TINYINT DEFAULT 1, -- 在线状态 gateway_sn VARCHAR(64), -- 边缘网关序列号用于定位 updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_vpp_type (vpp_id, res_type) ) COMMENT虚拟电厂资源台账;contract_kw和meter_kw两列并存是为了在方案评审时能说清签约 8 万千瓦、实测 5.2 万千瓦这件事。gateway_sn这一列在排障时价值很高一旦某个网关掉线能立刻圈出受影响的资源集合和容量缺口。3. 从聚合到调度需求响应指令下发与响应闭环3.1 基线负荷的三种算法与代码基线是结算的起点算法必须是事先约定好的、双方都认的那一种。平均法最常用取响应日前若干个工作日的同时段负荷去掉其中最高的若干点再取均值最后乘一个修正系数。最大负荷法偏向用户一般只在特定季节使用。回归法精度最高但对历史数据质量要求高方案里可以作为二期内容列出来。import statistics as st def baseline(hist, event_day, n_days5, trim1, adj1.0): 计算需求响应基线负荷 hist: {日期: [96 个 15 分钟功率点]}已按日期排序 event_day: 响应日需从历史中剔除 n_days: 取参考日的天数 trim: 每个时段剔除的最大值个数 adj: 修正系数按当地规则取常见 0.9~1.1 days [d for d in hist if d event_day][-n_days:] # 只取响应日之前 points len(hist[days[0]]) base [] for i in range(points): vals sorted(hist[d][i] for d in days) kept vals[:len(vals) - trim] if trim else vals # 去掉顶峰点 base.append(round(st.mean(kept) * adj, 2)) return base调用时把节假日和检修日从hist里排除掉否则基线会被异常的低负荷拉偏。trim取 1 表示每天剔一个最大值规则里怎么写就怎么实现别在代码里自作主张。基线算完之后响应量就是基线与实测负荷的差值积分需要按 15 分钟粒度逐点算再汇总成响应电量。3.2 指令下发与回执MQTT 主题与超时重试聚合层往下走指令最省事的通道是 MQTT。主题设计要在方案里定死不要等开发时再拍脑袋。下行指令用 QoS 1遥测用 QoS 0回执用 QoS 1这是比较常见的组合。主题方向QoS载荷要点vpp/{vppId}/cmd/{resId}下行1指令号、上调/下调、目标功率、起止时间vpp/{vppId}/ack/{resId}上行1指令号、执行结果、失败原因码vpp/{vppId}/tele/{resId}上行0实时功率、SOC、在线状态import json, time import paho.mqtt.client as mqtt PENDING {} # 指令号 - 下发时间戳用于超时判断 def send_cmd(cli, vpp_id, res_id, cmd_no, target_kw, ts_end, timeout30): payload {cmdNo: cmd_no, targetKw: target_kw, tsEnd: ts_end, dir: up if target_kw 0 else down} cli.publish(fvpp/{vpp_id}/cmd/{res_id}, json.dumps(payload), qos1) PENDING[cmd_no] time.time() return cmd_no def on_message(cli, userdata, msg): 收到回执后清除待确认记录未回执的由巡检线程重下 data json.loads(msg.payload) PENDING.pop(data.get(cmdNo), None) def retry_loop(cli, vpp_id, res_id, gap120): while True: now time.time() for cmd_no, t0 in list(PENDING.items()): if now - t0 gap: # 超过两个周期没回执 cli.publish(fvpp/{vpp_id}/cmd/{res_id}, json.dumps({cmdNo: cmd_no, retry: True}), qos1) PENDING[cmd_no] now time.sleep(5)gap不要小于一个采集周期否则会重复下发。重试要带retry标记设备侧据此判断是覆盖还是忽略避免同一台设备收到两条互相冲突的指令。3.3 响应率与偏差考核的数据口径方案里必须写清楚考核怎么算否则结算日一定扯皮。常用的三个指标是响应率、偏差率和到位时间。指标计算口径常见阈值响应率实际响应量 / 指令响应量不低于 80%偏差率各时段偏差绝对值之和 / 指令总量不高于 15%到位时间从下发到达到 90% 目标功率的耗时视资源类型约定空调 15 分钟内-- 按 15 分钟时段统计单条指令的响应量与偏差 SELECT cmd_no, SUM(actual_kw) * 0.25 AS actual_kwh, -- 15 分钟即 0.25 小时 SUM(target_kw) * 0.25 AS target_kwh, SUM(ABS(actual_kw - target_kw)) * 0.25 / NULLIF(SUM(ABS(target_kw)) * 0.25, 0) AS dev_ratio FROM vpp_response_15m WHERE vpp_id ? AND biz_date ? GROUP BY cmd_no;这里用绝对值求和而不是代数求和是因为正偏差和负偏差抵消后看起来很准实际上下调多了和少调了都要考核。方案落地时把这条 SQL 的口径写进结算说明验收环节能省掉大量沟通。4. 虚拟电厂总体规划的数据链路计量、通信与边缘接入4.1 采集频率与协议选型协议选型取决于设备本体不是取决于平台偏好。规划阶段最好按对象分档站内设备走 Modbus 或 IEC 104分散的楼宇设备走 MQTT电表数据靠已有的采集终端转发。频率也不宜一刀切秒级数据只对调频类资源有意义常规负荷 15 分钟足够。协议适用对象典型周期说明Modbus TCP储能 PCS、充电桩1 到 5 秒点表简单需约定寄存器地址映射IEC 104站内保护与测控装置1 到 15 秒遥测变化上送注意品质位处理MQTT楼宇空调、分散网关15 秒到 15 分钟弱网环境友好需自建主题规范平台转发已有电表采集系统15 分钟直接对接数据库或接口不重复采集注意同一种资源不要同时走两条通道送数双通道在时序库里会产生重复点后续做响应率统计时会把同一个 15 分钟算两遍。4.2 时序表结构与写入参数遥测数据量在方案里通常被低估。一个 500 台设备的项目按 15 秒上送一天就是约 288 万个点规划时必须给分区和压缩留出余量。CREATE TABLE vpp_telemetry ( res_id VARCHAR(32) NOT NULL, ts DATETIME(3) NOT NULL, p_kw DECIMAL(10,3), -- 有功功率 soc DECIMAL(5,4), -- 储能荷电状态 quality TINYINT DEFAULT 0, -- 0 正常 1 可疑 2 无效 PRIMARY KEY (res_id, ts) ) COMMENT资源遥测时序表; -- 按月分区便于冷数据归档 ALTER TABLE vpp_telemetry PARTITION BY RANGE (TO_DAYS(ts)) ( PARTITION p202601 VALUES LESS THAN (TO_DAYS(2026-02-01)), PARTITION p202602 VALUES LESS THAN (TO_DAYS(2026-03-01)) );写入侧建议批量提交单次 500 到 1000 行间隔一秒左右比逐条写入快一个量级。quality字段不要省采集器给出可疑点时打标记统计响应量时把可疑点剔除比事后猜测数据为什么跳变更省事。4.3 边缘网关的本地缓存与补传通信中断是常态方案里必须写明断网期间的数据怎么处理本地缓存、限长、断点续传。缓存长度按最长断网时长加一档余量设计一般 24 小时起步。# 边缘网关采集配置片段 collector: interval_ms: 15000 # 采集周期 points: [p_kw, soc, u_a, u_b, u_c] buffer: path: /data/buffer # 环形缓存目录 max_hours: 24 # 缓存时长上限超出按最旧覆盖 flush_batch: 800 # 单批上传条数 upload: url: https://vpp.example.local/api/v1/telemetry retry_backoff_s: [5, 15, 60, 300] # 退避重传 checkpoint: true # 记录上传位点重启后续传flush_batch与采集周期要对得上15 秒采一次、800 条一批大约 3 小时上传一批批量太大反而增加失败重传成本。checkpoint打开后网关重启会从上次位点继续不会整体重传这一项在方案验收时经常被单独拿出来测试。5. 规划方案的验证用仿真回测检验可调容量与响应精度5.1 回测要比对的三个数字方案写完不等于数字站得住。比较务实的做法是拿上一个月的实测数据做一次离线回测比对三组数字申报可调容量与实测可聚合容量、指令响应量与实际响应量、理论响应时长与实测到位时长。三组里头两组偏差超过两成说明建模系数需要重标定第三组超差多半是指令下发链路或设备侧执行策略的问题。回测不需要新写平台把台账表、遥测表和指令表导出来跑一遍就够。关键是回测用的系数必须与方案正文里写的完全一致否则回测只能证明代码自洽。5.2 一个最小回测脚本import pandas as pd def backtest(cap_df, tele_df, cmd_df, tol0.2): 回测虚拟电厂可调容量与响应精度 cap_df: res_id / vpp_id / adj_kw按 2.2 节折算得到 tele_df: res_id / cmd_no / base_kw / actual_kw15 分钟粒度 cmd_df: cmd_no / target_kw / act_ts / done_ts report {} # 1) 容量核对申报值与实测聚合值的偏差 declared cap_df[adj_kw].sum() measured tele_df[actual_kw].max() report[cap_dev] round((declared - measured) / measured, 3) # 2) 响应精度逐条指令算偏差率 g tele_df.groupby(cmd_no).apply( lambda x: (x[actual_kw] - x[base_kw]).sum()) t cmd_df.set_index(cmd_no)[target_kw] ratio (g / t).dropna() report[resp_rate] round(ratio.mean(), 3) # 平均响应率 report[under] int((ratio 1 - tol).sum()) # 响应不足条数 # 3) 到位时长从下发到完成的中位数单位分钟 dt (pd.to_datetime(cmd_df[done_ts]) - pd.to_datetime(cmd_df[act_ts])).dt.total_seconds() / 60 report[t90_min] round(dt.median(), 1) return report跑完这一遍方案里的数字就有了出处。实战里更值得花时间的是把under的指令逐条翻出来看是设备离线、是基线偏高还是指令目标本身超出了资源边界。这三类原因的处置方式完全不同——前者补网关运维中者调基线的trim和adj参数后者要在方案里修正可调容量的申报口径而不是在下一次响应里靠多签资源硬撑。本文还有配套的精品资源点击获取 
