很多人第一次听到“虚拟储能”这个概念时第一反应是这不就是把空调温度调一调吗这也能算储能然后就被论文里的公式和仿真曲线劝退了。但如果你真的在楼宇微网优化调度这个方向上写过代码、跑过仿真、算过经济账就会明白——在一栋中型办公楼里空调、通风、热水系统所蕴含的可调节潜力在多数时段里比一台几十千瓦的电池柜更值钱。这篇内容我想把“融合需求侧虚拟储能系统的楼宇微网优化调度”这个题目背后的建模思路、优化调度架构和Matlab代码实现逻辑完整梳理一遍。目标是让你看完之后能把这么长一个题目变成一段能跑通、能出图、能对比的数据链路。适合正在做微电网调度方向研究的硕博生、刚接手建筑能源管理项目的工程师以及那些准备把“虚拟储能”写进课程设计或毕业论文里但还没有头绪的同学。1. 虚拟储能并不玄乎先搞清楚楼宇里的“储能”藏在哪里1.1 物理电池的“不可能三角”与需求侧资源的真实价值楼宇微网最常见的配置是什么光伏板、储能电池、充电桩再加一套能量管理系统。这里面的物理电池本质上是把电能转化成化学能等需要的时候再反向变回来。听起来很完美但物理电池目前仍然有它的“不可能三角”容量、寿命、成本很难三者兼得。以常见的磷酸铁锂电池为例一个100 kW/200 kWh的电池柜采购成本按当前市场行情并不低而且循环寿命再长跑个几千次也会衰减。更关键的是在配电网容量已经给定的条件下你很难无限往上加电池——变压器容量、并网接口、消防要求都是硬约束。那有没有一种方式不需要买电池也能在楼宇里“削峰填谷”有。这就是需求侧的虚拟储能。所谓虚拟储能本质上是把楼宇里那些具有能量缓冲能力的物理设备和可调节负荷用数学模型“包装”成一个虚拟的储能元件。它在物理上不是一个柜子但在调度模型里它拥有与电池类似的充放电约束、容量边界和动态方程。而这个虚拟的充放电能力恰恰来自你每天都在用的空调系统、热水箱、通风设备和可平移负荷。我第一次接触这个概念时也觉得是“学术包装”但后来在一个模拟项目里把空调温度区间从22±1℃放宽到22±2℃同样一天下来峰时购电量下降了差不多15%这才意识到楼宇热惯性的潜力被严重低估了。1.2 空调热惯性、热水箱与可平移负荷三类典型的虚拟储能载体先说空调热惯性这是最典型、也是建模中最有意思的一个虚拟储能载体。建筑围护结构本身有蓄热能力墙体、地板、家具、空气都是热容的一部分。室外32℃的下午室内空调设定22℃你并不需要让空调每一秒都把室内温度钉死在22℃上而是允许它在21℃到24℃之间波动。这个波动区间就是“存储”冷量或热量的空间。简单理解房间就像一个大水箱温度像水位空调像水泵。允许水位在一定范围内浮动水泵就可以在电价高的时候少抽水电价低的时候多抽水最后保证水箱里的水位没有超出边界。你说这算不算储能从调度视角看完全算。第二类载体是热水箱。很多楼宇用的蓄热式电热水系统水箱本身就是储热装置它的能量密度虽然不高但容量可以做得很大。对那些不允许空调温度大范围波动的场合比如手术室、恒温实验室热水箱往往是更合适的VES载体。第三类是电梯、水泵、照明、充电桩这类可平移或可削减负荷。它们没有热惯性但可以在时间轴上平移或用能区间内调整这在调度模型里表现为“可时移负荷”和“可削减负荷”的上下限约束。1.3 等效SOC把温度区间翻译成储能容量既然要把虚拟储能写进优化模型就必须让它有“状态”就像电池有SOC一样。虚拟储能的SOC怎么定义最常见的方式是把室内温度的偏离程度映射成一个0到1之间的量。比如制冷模式下室内温度越低代表“冷量储备”越充足可以把虚拟储能的SOC定义为[ SOC_{ves}(k) \frac{T_{set} - T_{in}(k)}{T_{set} - T_{min}} ]其中T_set是用户设定温度T_min是允许的最低温度。温度越接近下限冷量储备越足相当于电池“充满电”。同理在制热模式下温度越接近上限热量储备越足。这个定义的物理意义很清楚而且它天然把舒适度约束转换成了储能容量约束。你不必再单独分析“空调功率和温度之间的关系到底怎么影响电网”只需要把温度动态方程写进约束把温度上界下界变成SOC边界求解器会自动完成整个调度决策。很多人理解虚拟储能卡在了一个误区总想给它找一个物理实体。其实它就是一个边界清晰的调节空间不用纠结“电到底存到哪里去了”你只需要关心“能不能在电价高的时候少用电电价低的时候多用电同时保证用户舒适度不出界”。2. 楼宇微网优化调度模型目标函数与约束条件的逐条拆解2.1 目标函数三层结构购电成本、电池损耗与舒适度惩罚楼宇微网调度问题的目标函数第一层当然是经济性也就是一天下来的净购电成本最低。这个“净”字很关键因为你不仅要从电网买电如果有光伏或者储能在特定时段还可能向电网卖电。目标函数的核心形式是[ C \sum_{k1}^{N} \left( price_{buy}(k) \cdot P_{grid}(k) - price_{sell}(k) \cdot P_{sell}(k) \right) \cdot \Delta t ]其中P_grid(k)是从电网购电功率P_sell(k)是反送电网的功率price_buy是分时购电价price_sell是上网电价。第二层成本是电池损耗。很多人第一次建模时容易忽略这个但如果你把电池当作免费的工具用求解器会让电池频繁充放一天循环好几圈算出来的成本非常低放到实际里根本不可能成立。简化的做法是给每次充放电加一个单位损耗成本[ C_{deg} \lambda_{deg} \cdot |P_{bat}(k)| \cdot \Delta t ]lambda_deg根据电池循环寿命折算单位是元/kWh。我在仿真里通常取0.1~0.2元/kWh这个值不算大但足以让调度策略避免电池的无效充放。第三层是舒适度惩罚。如果你用硬约束把温度死死限制在某个区间内求解出的结果可能为了保证舒适度而在峰时仍然开启高功率空调。更符合实际的做法是允许温度在极端情况下轻微越限但在目标函数里设置越限惩罚项让求解器在“越限一点”和“多花电费”之间做权衡。这种方法在文献里叫软约束它会显著改善目标函数值和求解速度。2.2 功率平衡与物理储能约束必须守住的硬边界优化调度模型的根基是节点功率平衡方程。在单楼宇微网里它写出来很直白[ P_{grid}(k) P_{pv}(k) P_{bat}^{dis}(k) P_{load}(k) P_{ac}(k) P_{bat}^{ch}(k) ]这里P_load是非空调的基本负荷P_ac是空调电功率P_pv是光伏出力。模型里每个时刻的发电和用电都必须严格平衡这一条不能有任何松动。物理电池的约束包括动态方程、功率上下限和SOC边界[ SOC(k1) SOC(k) - \frac{P_{bat}(k) \cdot \Delta t}{E_{bat}} ][ P_{bat}^{min} \le P_{bat}(k) \le P_{bat}^{max} ][ SOC_{min} \le SOC(k) \le SOC_{max} ]这里有个容易被忽略的点电池的功率方向定义。我在代码里统一规定“P_bat为正表示放电为负表示充电”然后功率平衡式里直接加P_bat。这样SOC动态方程里就要跟上负号SOC(k1)SOC(k)-P_bat(k)*Δt/E_bat。方向搞反整个系统就会“凭空产生能量”目标函数还能算出负成本。2.3 温度动态方程与虚拟储能约束把舒适区间写成数学模型虚拟储能的建模核心是一个描述室内温度变化的一阶等效热参数模型ETP模型。简化形式是[ T_{in}(k1) T_{in}(k) \frac{\Delta t}{R \cdot C} \left( T_{out}(k) - T_{in}(k) \right) - \frac{\Delta t}{C} \cdot \eta_{ac} \cdot P_{ac}(k) ]其中R是建筑围护结构热阻C是室内热容T_out是室外温度eta_ac是空调制冷效率系数。这个公式的物理含义是房间温度的变化由室外传热、空调制冷/制热共同决定。你可能会问为什么用一阶模型不用复杂的热力学仿真模型因为调度优化的核心是“在满足动态特性的前提下做经济决策”如果模型太复杂、微分方程阶数太高求解难度会急剧上升在Matlab里往往很难在合理时间内收敛。一阶ETP模型在精度和可解性之间是很好的折中这也是大量学术论文采用它的原因。舒适度边界是虚拟储能的核心约束[ T_{min} \le T_{in}(k) \le T_{max} ]正是这个不等式给虚拟储能画出了“安全运行区间”。室内温度只要在这个区间内空调功率如何变化、何时变化求解器都有完全的自由度。高温时段少开空调、低温时段“预冷”蓄冷这些行为都是从这一个边界约束里“长”出来的。在Matlab里把所有时刻的T_in变量都限制在上下界里虚拟储能模型的骨架就搭起来了。你不需要显式定义P_ves温度偏差和空调功率变化本身就是虚拟储能的充放电行为。3. Matlab代码实现一套可复用的优化调度代码链路3.1 数据组织时序参数、分时电价与负荷曲线的预处理Matlab实现的第一步不是写优化模型而是把数据组织清楚。我习惯把整个仿真参数集中在一个参数初始化脚本里方便后续修改和复用。时间粒度我推荐取15分钟也就是一天96个调度点。太粗比如1小时间隔会浪费虚拟储能的调节能力太细比如1分钟会让求解时间成倍增长而且热动态模型在分钟级的时间常数下数值稳定性反而更难保证。关键参数包括N调度周期内的时段数取96dt时间步长0.25小时price_buy、price_sell分时购电价和上网电价曲线P_load非空调基础负荷曲线P_pv光伏预测出力曲线P_ac_max、P_ac_min空调电功率的上下限T_set、T_min、T_max设定温度和舒适区间R、C等效热阻和热容E_bat、SOC_min、SOC_max电池容量与SOC边界如果你手头没有实测数据这里有个实用的做法先按典型负荷曲线生成一个基础数据集用正弦曲线叠加随机波动来模拟负荷和光伏出力再把随机种子固定下来。这样既能复现又不会让算例显得太假。3.2 用YALMIP定义决策变量、约束与目标函数Matlab里做优化调度我建议直接上YALMIP工具箱再用Gurobi或Cplex做底层求解器。YALMIP的好处是你可以用类似数学表达式的语法来定义决策变量、约束条件和目标函数代码阅读起来和论文公式是对应的不用花大量时间在矩阵化操作上。核心代码骨架大致如下%% 决策变量定义 P_grid sdpvar(1, N); % 从电网购电功率, kW P_bat sdpvar(1, N); % 电池出力, 正值为放电 SOC sdpvar(1, N); % 电池荷电状态 P_ac sdpvar(1, N); % 空调电功率, kW T_in sdpvar(1, N); % 室内温度, ℃ %% 约束集合 Constraints []; Objective 0; for k 1:N-1 % 功率平衡 Constraints [Constraints, P_grid(k) P_pv(k) P_bat(k) P_base(k) P_ac(k)]; % 物理储能动态与边界 Constraints [Constraints, SOC(k1) SOC(k) - P_bat(k) * dt / E_bat]; Constraints [Constraints, P_bat_min P_bat(k) P_bat_max]; Constraints [Constraints, SOC_min SOC(k) SOC_max]; % 虚拟储能动态与边界简化ETP模型 Constraints [Constraints, T_in(k1) T_in(k) dt/(R*C) * (T_out(k) - T_in(k)) - dt/C * eta_ac * P_ac(k)]; Constraints [Constraints, T_min T_in(k1) T_max]; % 空调功率边界 Constraints [Constraints, 0 P_ac(k) P_ac_max]; % 目标函数购电成本 电池损耗 舒适度惩罚 Objective Objective price_buy(k) * P_grid(k) * dt lambda_deg * abs(P_bat(k)) * dt; end %% 求解 ops sdpsettings(solver, gurobi, verbose, 0); result optimize(Constraints, Objective, ops);这里面有两个细节需要注意。第一目标函数里的abs(P_bat(k))YALMIP会自动把它线性化成辅助变量和不等式约束交给求解器处理时不会破坏线性结构。但你不应该在目标函数里写P_bat(k)^2这样的非线性项除非求解器支持二次规划并且你有意引入二次成本。第二功率平衡等式里P_pv和P_base都是已知参数只有P_grid、P_bat、P_ac是变量这个等式在每时段都会把自由度限制住。如果光伏出力很大、负荷很小P_grid可能降为0甚至为负——这代表向电网馈电。但你是否允许馈电取决于实际项目有没有并网售电条件建模时要想清楚。3.3 求解器选择、结果导出与可视化求解器选择上如果模型是线性规划目标函数为线性、约束为线性直接用Gurobi或Cplex效率最高。如果加了二次惩罚项就是二次规划QPGurobi同样能处理。YALMIP安装之后在sdpsettings里指定solver, gurobi或者cplex即可。如果手头没有商业求解器许可证免费的sedumi或glpk也可以跑小规模问题。但楼宇调度模型动辄几十上百个变量、几千条约束免费求解器的求解速度会明显吃亏做参数敏感性分析时会很想摔键盘。我个人的建议是尽量通过学校或公司的许可证渠道拿到Gurobi。结果导出是这个环节很容易被忽视的部分。优化得到的变量存在value()函数取出的数据结构里P_grid_opt value(P_grid); P_bat_opt value(P_bat); SOC_opt value(SOC); T_in_opt value(T_in); P_ac_opt value(P_ac);保存这几个关键变量后就可以绘制功率平衡图、SOC轨迹图、室内温度轨迹图和分时电价下的购电策略图。一个值得养成的习惯是输出结果之后顺手做一个“功率总和校验”——把所有时段的P_grid P_pv P_bat和P_base P_ac做差若误差超过10的负8次方量级说明约束没有严格满足那这个解是不能拿去写论文做分析的。可视化部分我常用stairs画阶梯功率曲线用plot画温度和SOC曲线再加一条时间轴在x轴上图例标清楚。调试阶段把功率平衡三个来源电网、光伏、电池和两个去向负荷、空调画在同一个子图里一眼就能看出调度策略是否合理。4. 算例设计与对比分析虚拟储能究竟省了多少成本4.1 三个对照场景基线、只加电池、电池加虚拟储能评估虚拟储能的价值不能只看单条仿真曲线拍脑袋必须有规范的对照实验。我的做法是设定三个递进场景场景A无电池、无虚拟储能空调功率固定为维持设定温度的常数值。这是基线场景。场景B加入物理储能电池空调仍然恒温运行。这是“纯电池方案”。场景C同时加入物理储能和虚拟储能允许空调功率按优化指令调整温度在舒适区间内自由浮动。场景B和场景C的差异就是虚拟储能带来的边际价值。这样设计对比比直接拿“有VES/无VES”二场景对比更能说明问题——因为读者会想知道我多买了电池之后再叠加VES到底还有没有意义。以某典型中型办公楼的简化参数为例日基础负荷峰值约420 kW光伏装机120 kW电池100 kW/200 kWh空调最大电功率80 kW舒适区间22±2℃分时电价峰谷价差约0.6元/kWh。仿真一天的日运行成本对比如下场景日运行成本元相比基线降幅场景A基线恒温、无电池1280-场景B纯物理电池115210.0%场景C电池VES104818.1%三组数据放在一起VES额外带来了约8个百分点的成本下降。单独看可能觉得不大但如果折算到一年、一个园区几十栋楼节省的绝对金额就非常可观了。4.2 从结果曲线看调度逻辑温度轨迹、SOC轨迹与功率分配仿真完成之后真正有价值的是读曲线。我每次都会先看三个关键图温度轨迹、电池SOC轨迹、各时段的购电功率。温度轨迹这条曲线几乎能“讲出”虚拟储能的调度逻辑。在场景C里你会看到下午电价进入高峰前一小时左右室内温度已经开始缓慢下降逼近下限T_min——这是空调在“预冷蓄冷”相当于把能量提前存进墙体里。等到下午高峰电价时段空调功率明显下降室内温度逐渐回升但始终不超出上限T_max。整个过程就是一次完整的虚拟储能“充电-放电”循环。SOC轨迹则反映电池和虚拟储能的协同关系。你会发现在光伏出力强的中午时段电池会优先充电把光伏盈余“搬”到晚间而VES的发力时段更灵活它不仅可以响应电价还能在电池SOC见底的时候继续提供调节空间。两种储能的互补性正是这个模型最精彩的地方。购电功率曲线能告诉你整体策略是否健康。一个合理的调度解应当在高电价时段购电功率明显压低低电价时段适当提高且功率曲线没有频繁的锯齿状波动。如果曲线某段出现高频振荡通常不是求解器的问题而是约束或参数设置有问题比如电池损耗系数取太小导致无意义充放、或者负荷数据本身噪声过大。4.3 我踩过的三个坑不收敛、约束过紧和单位混乱第一个坑模型不收敛或解不可行。最常出现在温度动态约束上。ETP模型里R、C参数如果取值显著偏离实际温度方程就会变得数值刚性求解器在迭代过程中发现变量无法同时满足所有约束直接报无解。解决办法是先用开环推演检查模型给定一组合理的P_ac序列看T_in轨迹是否落在舒适区间内如果温度疯狂飞出去说明R、C设置有问题需要参考建筑能耗领域的典型取值。第二个坑舒适区间设得太紧。有些同学为了体现“严格保证舒适度”把温度约束写成22±0.5℃。这样虚拟储能的调节空间几乎为零模型退化成恒温方案VES一点价值都体现不出来。实际建筑热舒适标准允许的温度波动范围远比研究者的直觉要宽。仿真中建议从±2℃起步如果论文需要再做±1℃、±1.5℃、±2℃的敏感性分析。第三个坑单位混乱。这个坑我栽过一次至今记忆犹新。某次仿真结果算出来日成本上千万元查了很久才发现是把功率变量当成能量变量用了电价是元/kWh功率是kW必须乘上时间步长才是能量。这个错误特别隐蔽因为从量纲上看公式“好像对”但数量级完全不对。我的经验是在参数表里把每个参数的单位写进注释写约束的时候盯着单位做换算避免“觉得对了就往下走”。5. 从确定性模型到工程落地还可以继续深挖的方向5.1 不确定性环境下的滚动时域调度MPC前面整套流程本质上是开环的确定性优化光伏出力、负荷曲线、室外温度都是已知的“完美预测”。实际运行中预测误差是躲不掉的——午后一片云飘过来光伏出力瞬间掉20%开环调度给出的策略就会在接下来的时段里偏离预期值。走得更远一点的方案是换成模型预测控制MPC框架。具体做法是仍然用YALMIP建立同样的优化模型但不是一次求解96个时段而是在每个控制周期只求解未来若干小时比如12个时段取第一个时段的控制指令执行然后滚动刷新预测数据、重新求解。代码层面MPC只是把前面的求解过程包进一个循环里再引入一个滚动预测窗口。关键难点在于预测数据的更新逻辑和每个窗口初始状态的传递——比如电池SOC、室内温度都需要从上一轮的最终状态传递到下一轮作为初始条件。这个方向非常值得做和纯开环模型相比它在论文和工作中的说服力都上升一个档次。5.2 从单栋楼宇到多楼宇协同分布式优化与VES聚合虚拟储能在单栋楼里的价值我们已经看到了。但当你手上有一整个园区、十几栋楼的时候调度问题会变成一个多主体协同问题。不同楼宇的负荷类型、围护结构热惰性、用能时段曲线往往差异很大。写字楼和白天的商业综合体白天负荷高住宅楼则是早晚两个高峰。把这些楼宇的VES聚合在一起园区级的负荷曲线可以被削得更平整体购电成本会比每栋楼各自为政低不少。模型上可以建立统一园区调度中心把所有楼宇的变量统一建模。随着楼宇数量增加问题规模呈线性增长集中式求解会越来越吃力这时候就要研究分布式优化方法——比如交替方向乘子法各楼宇保留自己的隐私数据只和调度中心交换边界耦合的功率信息。这已经是一个独立的研究方向但入口就是本文这栋单楼宇的VES模型。5.3 代码扩展建议与我的使用习惯最后聊一点代码工程习惯。我始终坚持把参数初始化、模型构建、求解、画图分成四个独立脚本或函数模块。参数脚本放在最前面数据生成用单独的函数封装模型构建函数只接收参数和决策变量的结构体画图脚本单独跑。这样做的好处是当你要换一组电价、换一栋楼的热参数、或者加一组新的对比场景时不需要去翻几百行代码改一个文件就行。另外所有关键参数估计值我都会在旁边写注释注明来源依据。比如R和C的取值是参考同类办公建筑的典型热工参数估计的电池损耗系数是根据循环寿命折算的。做研究时这些注释看起来不起眼但等你三个月后回头复核数据、或者导师和审稿人追问参数来源的时候就会发现它们是救命稻草。从需求侧荷-储协同的角度去理解虚拟储能再把它和物理电池一同放进楼宇微网的优化调度框架里这件事本身并不复杂核心就是一套功率平衡方程、一组温度动态约束加上一个会优化求解的Matlab模型。真正拉开差距的是对参数的理解、对结果曲线的解读以及对仿真细节的把控。我个人的习惯是拿到任何一个调度类题目先不急着调求解器先画一张能量流图把“哪些是决策变量、哪些是已知参数、哪些是硬约束、哪些是软约束”分清楚再动手写代码。这个习惯帮我省掉了大量反复调试的时间。希望这篇内容也能帮你把“虚拟储能”从概念变成一段跑得通的仿真代码少踩几个我没有绕过去的坑。
