虚拟电厂售电与共享储能落地:资源聚合、交易链路与收益分配
简介这份70页PPT聚焦虚拟电厂售电业务与共享储能等新型业态趋势面向电力市场研究者、售电公司从业者、储能项目开发者及高校电气专业师生帮助系统理解虚拟电厂在新型电力系统中的定位、商业模式与政策环境。压缩包内为1个pptx文件约12.73MB内容以图文并茂的演示文稿形式呈现便于直接用于汇报、教学或方案参考。已有51人学习关注。资料从引言切入梳理新能源发电波动性、储能需求增长与市场体制改革等背景进而展开虚拟电厂的概念、资源组成与功能分类涵盖电源型、负荷型、储能型及混合型等不同组合方式随后深入商业模式与售电业务分析参与主体、市场定位与收益来源并延伸至共享储能技术与商业模式、新兴业态发展前景及政策支撑最后以总结收束。整体结构清晰适合作为虚拟电厂与共享储能方向的入门框架或项目策划参考。1. 虚拟电厂售电业务到底在卖什么从一份70页PPT的目录说起虚拟电厂售电业务这个词第一次听容易误解成“把电卖给虚拟电厂”。实际恰恰相反虚拟电厂是把分散的屋顶光伏、储能柜、可调负荷、充电桩聚合起来作为一个整体去参与售电和电网调节。售电业务是它的收入出口共享储能是它的调节资源池两者叠在一起才构成新型业态的完整闭环。我见过不少团队拿着几十页的方案PPT去汇报讲完聚合能力、调控平台、商业模式台下第一个问题永远是“那你到底靠什么赚钱、钱从哪一笔结算里出”。这份70页的方案材料价值不在页面数量而在于它把“资源聚合—售电交易—共享储能调度—收益分配”这条链路拆成了可讨论的模块。适合谁看做能源数字化的产品经理、售电公司的交易员、储能集成商的技术负责人以及准备把园区负荷接进聚合平台的一线工程师。接下来我不复述PPT而是把这条链路里真正要落地的部分讲清楚。2. 虚拟电厂售电业务的资源聚合与交易链路怎么搭2.1 先分清三层角色别把聚合商和售电公司混成一件事虚拟电厂售电业务最常见的翻车是把“聚合商”和“售电公司”当成同一个主体。聚合商负责把分散资源聚起来、做可调能力评估、下发调节指令售电公司负责在批发市场买电、在零售侧卖电、承担偏差考核。两者可以是同一家公司但账要分开算。共享储能在这里是第三种角色它既是可调资源又可能是独立的市场主体参与调峰调频拿补偿。我一般会先把资源分成三类来建模资源类型可调方向响应速度结算依据分布式光伏向下限发秒级到分钟级发电量损失补偿用户侧储能双向秒级充放电量容量补偿可调负荷向下削峰分钟级响应电量补偿这张表决定了后面交易策略怎么写。光伏只能往下压储能可以双向吞吐负荷只能削不能发。把方向搞错调度指令下去就是无效动作。2.2 用一份最小配置跑通聚合侧的数据接入落地第一步不是买平台是把资源侧的数据接进来。常见做法是用 Modbus TCP 或 IEC 104 采集储能 PCS、电表、光伏逆变器的实时数据再通过 MQTT 上报到聚合平台。下面是一段我常用的采集侧伪代码用来把储能柜的 SOC、充放电功率、可调上限读出来并打包上报import time import json import paho.mqtt.client as mqtt from pymodbus.client import ModbusTcpClient # 储能柜寄存器地址按实际设备手册改 REG_SOC 40001 # 荷电状态单位 % REG_POWER 40003 # 当前充放电功率单位 kW正放负充 REG_MAX_CHARGE 40005 # 最大充电功率单位 kW REG_MAX_DISCHARGE 40007 # 最大放电功率单位 kW client ModbusTcpClient(192.168.1.50, port502) mqtt_client mqtt.Client(storage_gateway_01) mqtt_client.connect(broker.local, 1883, 60) def read_registers(): rr client.read_holding_registers(REG_SOC, 8, unit1) if rr.isError(): return None regs rr.registers return { soc: regs[0] / 10.0, power: (regs[2] - 65536 if regs[2] 32767 else regs[2]) / 10.0, max_charge: regs[4] / 10.0, max_discharge: regs[6] / 10.0, ts: int(time.time()) } while True: data read_registers() if data: # 可调上限按 SOC 做安全裁剪避免过充过放 if data[soc] 90: data[max_charge] 0.0 if data[soc] 10: data[max_discharge] 0.0 mqtt_client.publish(vpp/resource/storage_01, json.dumps(data)) time.sleep(5)逻辑说明每5秒轮询一次寄存器把 SOC 和功率做量纲还原再根据 SOC 边界裁剪可调上限。参数说明REG_SOC这类地址必须对着设备点表改不同厂家差一个偏移量就全错unit1是 Modbus 从站号多台设备串在一条总线上时这个值不能重复SOC 裁剪阈值 90/10 是保守值实际项目里要结合电芯厂家给的充放电窗口调整。这段代码跑通聚合平台才有“可调能力”这个输入后面的交易和调度才有依据。2.3 售电交易侧要盯的三个量申报量、偏差、结算价聚合侧数据通了接下来是交易。虚拟电厂售电业务在批发市场的动作本质是每天在指定时间前申报次日的用电曲线和可调能力。这里三个量决定盈亏申报量、实际偏差、结算价。申报量靠负荷预测偏差靠实时调节能力兜底结算价看的是中长期和现货的组合。我一般会用一个简单的滚动预测做申报基线再留 5% 到 10% 的调节裕度给共享储能去补偏差。裕度留太少偏差考核罚款吃掉利润留太多储能充放电次数上去了循环寿命掉得快。这个平衡点没有标准答案得按当地考核规则和储能度电成本算。共享储能的价值就在这里它不绑定单一用户可以在多个售电套餐之间腾挪把偏差补得更经济。3. 共享储能的调度策略与收益分配怎么算3.1 共享储能不是“大家共用一块电池”是容量和功率的时分复用共享储能最容易被误解成物理上共用一套电池。实际落地里它是把储能系统的充放电功率和容量按时间片切给不同用户或不同售电套餐。A 用户白天用光伏余电充电B 用户晚高峰放电套利C 售电套餐用它补偏差。三者时间上错开物理上还是同一套 PCS 和电芯。调度策略的核心是一个带约束的优化问题在每个时间片决定储能充还是放、充放多少使得套利收益加补偿收益减寿命损耗最大。约束包括 SOC 上下限、充放电功率上限、不能同时充放、以及和售电申报的耦合。工程上不会真去解一个大优化常见做法是分时段定策略谷段充满、峰段放、平段待命补偏差。3.2 用分时电价表驱动一个可复现的充放电排程下面这段排程逻辑输入是分时电价和 SOC输出是每个时段的充放电计划。它不追求最优但足够跑通共享储能的日内套利# 分时电价谷/平/峰单位 元/kWh TOU_PRICE { valley: 0.30, flat: 0.65, peak: 1.20 } # 时段划分24 小时每小时一个标签 HOUR_TAG ( [valley] * 8 # 00:00-08:00 [flat] * 4 # 08:00-12:00 [peak] * 4 # 12:00-16:00 [flat] * 2 # 16:00-18:00 [peak] * 4 # 18:00-22:00 [valley] * 2 # 22:00-24:00 ) CAPACITY 1000.0 # 储能容量 kWh P_MAX 250.0 # 最大充放电功率 kW SOC_MIN, SOC_MAX 0.10, 0.90 EFF 0.95 # 单程效率 def build_schedule(soc_init): soc soc_init plan [] for h in range(24): tag HOUR_TAG[h] if tag valley and soc SOC_MAX: # 谷段充电受功率和 SOC 上限约束 energy min(P_MAX, (SOC_MAX - soc) * CAPACITY / EFF) soc energy * EFF / CAPACITY plan.append((h, charge, round(energy, 1))) elif tag peak and soc SOC_MIN: # 峰段放电受功率和 SOC 下限约束 energy min(P_MAX, (soc - SOC_MIN) * CAPACITY * EFF) soc - energy / EFF / CAPACITY plan.append((h, discharge, round(energy, 1))) else: plan.append((h, idle, 0.0)) return plan, soc plan, soc_end build_schedule(0.20) for h, action, energy in plan: if action ! idle: print(f{h:02d}:00 {action} {energy} kWh) print(日末 SOC:, round(soc_end, 3))逻辑说明谷段充电、峰段放电、平段待命这是共享储能最朴素的套利骨架。参数说明TOU_PRICE要换成项目所在地的实际分时电价峰谷价差小于 0.6 元/kWh 时这套策略基本不赚钱EFF单程效率 0.95 是偏乐观的实际 PCS 加电芯往返效率常在 0.85 到 0.90算收益时要用往返效率SOC_MIN/SOC_MAX留 10% 到 90% 是为了寿命磷酸铁锂长期满充满放循环寿命会明显下降。跑完这段你能看到一天充放几次、日末 SOC 落在哪再拿价差一乘就是毛收益减掉度电寿命成本才是净收益。3.3 收益分配要写进合同别只写在PPT里共享储能的收益分配是商务问题但技术方案必须给它留接口。常见分法有三种按容量比例分、按实际调用电量分、按固定租金加超额分成。我一般建议在平台里把每个用户的调用电量单独计量结算时按合同规则出账单。技术上就是给每次充放电打上用户标签聚合平台按标签汇总。这一步不做后期对账就是一笔糊涂账血泪经验。4. 虚拟电厂售电业务落地避坑五个真实会踩的坑4.1 可调能力上报虚高调度指令下去执行不了现象聚合平台上报可调容量 5MW电网真下指令时只执行了 2MW被考核。原因可调能力是按设备铭牌功率累加的没扣掉 SOC 边界、用户生产约束、通信延迟。解决可调能力要按“当前时刻真实可执行”算SOC 裁剪、负荷基线扣除、通信在线率都要乘进去宁可少报。4.2 共享储能被多个套餐同时调用功率撞车现象两个售电套餐在同一时段都要求储能放电实际功率超限PCS 保护停机。原因调度层没有做功率互斥和优先级仲裁。解决在调度入口加一层资源锁同一时间片一个储能资源只响应一个最高优先级指令其余排队或拒绝。4.3 偏差考核算错方向越补越亏现象为了补偏差让储能频繁充放结果偏差是小了但储能度电成本加损耗超过了罚款。原因没算边际成本把“补偏差”当成无条件动作。解决设一个偏差补尝阈值当补偏差的度电成本高于考核单价时选择接受考核而不是硬补。4.4 数据采集丢点交易申报基线失真现象负荷预测曲线在某个时段突然掉到零申报量严重偏低。原因采集网关断线或 MQTT 丢包平台没做断点补全。解决采集侧加本地缓存断线重连后补传平台侧对缺失点做插值并标记数据质量位低质量数据不参与申报。4.5 结算口径和计量点不一致对账对不上现象平台算出的调用电量和电网结算电量差几个百分点。原因计量点位置不同平台采的是 PCS 侧结算是并网点侧中间差了变压器损耗和线损。解决明确结算计量点平台要么直接采结算表要么做损耗折算折算系数按实测标定。5. 把方案变成能跑的系统一个最小验证路径如果你手上只有一份方案材料想验证虚拟电厂售电业务加共享储能这条路走不走得通我建议不要一上来就搭大平台。先做一个最小闭环一台储能柜、一个可调负荷、一个采集网关、一个能算充放电排程的脚本。用第 3 章那段排程代码跑一周把实际充放电量和分时电价乘出来看毛收益能不能覆盖度电寿命成本。这一步花不了多少钱但能告诉你这个场景的价差够不够。验证通过后再往上加两层一层是售电申报用第 2 章的采集数据做负荷基线留调节裕度一层是收益分配给每次调用打用户标签。这两层都跑通才谈得上多资源聚合。验证阶段输入输出通过标准单储能套利分时电价、SOC日充放电计划毛收益 度电寿命成本加可调负荷负荷基线、响应指令实际响应量响应偏差 15%加售电申报负荷预测、调节裕度申报曲线偏差考核可控加收益分配调用标签、合同规则用户账单对账差异 2%一个具体技巧度电寿命成本别拍脑袋用储能循环寿命和系统造价反算。比如 1000kWh 系统造价 80 万循环 6000 次度电寿命成本约 0.13 元/kWh再叠加充放电损耗。这个数算出来你才知道峰谷价差要多大才值得做。我自己做这类方案习惯先把度电成本算清楚再谈商业模式不然PPT上写得再漂亮一算账就露馅。希望帮到你。本文还有配套的精品资源点击获取