虚拟储能与楼宇微网优化调度:Matlab聚合并调度需求侧柔性负荷

发布时间:2026/10/8 10:10:47
虚拟储能与楼宇微网优化调度:Matlab聚合并调度需求侧柔性负荷 楼宇微网优化调度这个方向大家通常默认的核心是电池储能——怎么充、怎么放、跟电网怎么交互。但我在实际项目里做了几轮之后发现真正决定调度收益上限的往往是需求侧那批柔性负荷空调、热水器、电梯、充电桩它们每一种都具备天然的“虚拟储能”特性。我们最终落地的这套融合需求侧虚拟储能系统的楼宇微网优化调度方案就是用 Matlab 把这批柔性负荷聚合成等效储能模型参与了楼宇微网的日前调度优化。跑通之后算例电费下降了十几个百分点峰值购电功率也降了关键是没增加一块实体电池。这套方案从模型推导到代码实现我踩了不少坑今天把完整思路和代码骨架整理出来供同样在做微网调度、需求响应、建筑能源管理的朋友参考。1. 楼宇微网为什么要引入虚拟储能需求侧柔性资源的再认识1.1 楼宇微网调度的真实痛点储能贵、波动大、电价差吃不透楼宇微网的典型结构不复杂屋顶光伏、配电变压器、电池储能、空调为主的可控负荷、照明电梯等不可控负荷再加上跟大电网的交换关口。目标说起来也简单——在满足楼宇正常使用的前提下让日运行成本最低。但真把数据摆到桌面上问题就出来了。第一是光伏的波动性。中午光照强的时候发电多甚至可能倒送电但楼宇午间负荷往往不是最高峰傍晚光伏骤降、负荷攀升这中间存在一个很尴尬的“鸭子曲线”时段。没有储能要么高价买电要么眼睁睁看着光伏浪费。第二是峰谷电价差。国内很多工商业用户执行分时电价峰段和谷段价差能到 0.6~0.9 元/kWh理论上拿谷段电充进去、峰段放出来就能套利但实体电池的度电成本、循环寿命损耗会吃掉一大部分收益。第三是电池储能的投资门槛一套 100 kWh 的工商业储能系统光设备加施工就要二十万以上很多楼宇业主根本算不过账。这些痛点共同指向一个判断楼宇微网缺的不是“存电的仓库”而是“能灵活调整用电节奏的手段”。而这个手段恰恰就藏在空调启停、热水器加热、充电桩充电这些每天都在发生的用电行为里。1.2 虚拟储能与电池储能的本质区别不存电存“用电器行为”虚拟储能Virtual Energy Storage, VES这个概念第一次听的人很容易绕晕。它不是什么新设备而是一种对柔性负荷的抽象——通过调节用电设备的运行功率或运行时段让楼宇的净负荷曲线发生“充电”或“放电”一样的变化。我常用一个类比来解释实体电池是“仓库”电是货物白天把货存进去、晚上取出来虚拟储能则是“调整生产线节奏”——订单高峰时让一部分工序加班赶工订单低谷时让它们停工休息。对电网或者微网调度员来说看到的净负荷功率曲线效果是一样的高峰时段用电功率下降等效于储能放电低谷时段用电功率上升等效于储能充电。两者的本质区别在于能量存储形态不同。实体电池存的是电能充放电效率通常在 90% 以上虚拟储能存的是“热能”“冷水”“时间弹性”这些间接形态比如空调提前把房间温度降到比舒适下限更低相当于把“冷量”存进了墙体、家具和空气里之后关掉压缩机冷量慢慢释放室内温度仍然维持在舒适范围内——这个过程里电没有直接存起来但用电功率确实被平移了。理解了这个区别才能明白虚拟储能的调度边界为什么是舒适度而不是荷电状态。1.3 楼宇里到底有多少虚拟储能潜力可挖很多人觉得虚拟储能是花架子觉得空调稍微调一两度能有多大作用。我在一个中型办公楼项目里统计过办公楼层中央空调系统总额定功率约 500 kW夏季制冷时运行功率在 350 kW 左右。室内温度允许在舒适区间 22~26°C 内波动按楼宇综合热容折算前后能平滑掉的电功率约 200~250 kW持续时间可达 2~3 小时。这就是一个等效 400~600 kWh 的“温度储能”接近一组中小型电池柜的容量。热水器的潜力更直接。商业楼宇常用的电热水器和水蓄热系统本身就是以热能形式储能的水箱保温让热量可以保存数小时。蓄热式电锅炉在谷段加热、峰段利用热水本质上就是一个完整的大容量虚拟储能。电动汽车充电桩就更典型了——车辆实际停在车位上的时间通常远大于充满电所需时间这中间天然存在 2~6 小时的可延迟窗口完全可以参与调度。把这些都聚合起来一栋中型楼宇的虚拟储能潜力在MWh级别都不夸张。当然潜力不等于可调度容量。实际能挖多少取决于楼宇用途、设备类型、用户舒适度容忍度以及控制系统的响应速度。但这些数字至少说明一件事需求侧柔性资源不是可有可无的小零碎而是楼宇微网里一块被严重低估的调度资源。2. 虚拟储能建模的关键把楼宇里的柔性负荷变成可调度储能2.1 一阶ETP热动力学模型空调虚拟储能的基础要把空调这种负荷写成储能的形式第一步是描述房间温度随制冷量和室外温度变化的动态过程。工程上最常用的是等效热参数模型Equivalent Thermal Parameters, ETP一阶形式已经能获得足够的准确性T_in(t1) T_in(t) * exp(-dt/(R*C)) (T_out(t) - Q_cool(t) * R) * (1 - exp(-dt/(R*C)))其中 R 是房间综合热阻°C/kWC 是综合热容kWh/°CQ_cool(t) 是空调制冷功率kW正值表示制冷T_out(t) 是室外温度dt 是调度步长。这个公式的物理直觉是房间温度会向一个“平衡温度”T_out - Q_cool * R 指数趋近。空调开得越猛平衡温度越低房间降温越快同时R*C这个时间常数决定了温度变化的快慢。大办公楼墙体厚重、家具多时间常数可能有 1~2 小时这给了虚拟储能足够的“缓冲空间”。我在建模时会先用实测数据辨识 R 和 C——简单做法是取一段空调恒功率运行记录用最小二乘拟合温度曲线比查设计手册的参数更贴合实际楼宇。2.2 等效SOC的定义与状态转移方程有了温度动态就可以定义空调虚拟储能的等效荷电状态SOC。我的做法是SOC_vess(t) (T_in(t) - T_min) / (T_max - T_min)T_max 和 T_min 是舒适度上边界和下边界。注意物理含义室内温度越低说明“蓄冷量”越充足SOC 越高等效于电池处于高电量状态。这样定义的好处是SOC 天然被限制在 0 到 1 之间和电池储能模型完全对齐。虚拟储能的“功率”和 SOC 通过热容联系起来。室内温度变化一步对应的等效电功率变化是P_vess(t) C * (T_in(t) - T_in(t1)) / dt / COPCOP 是空调能效比这一步是把热功率折算回电功率。这个式子说明虚拟储能的放电功率减少制冷、温度上升受到温度变化速率和热容的共同限制不能想放多少就放多少。由此可以推出一个调度周期内的最大等效容量E_vess_max C * (T_max - T_min) / COP代入典型办公楼参数C 约 100 kWh/°CΔT4°CCOP3E_vess_max ≈ 133 kWh。这是一个偏保守的估计实际热容还会更大。这组关系是整个虚拟储能建模的核心后面所有优化约束都建立在它之上。2.3 多类柔性负荷的聚合虚拟储能模型单台空调的建模只是第一步楼宇里还有热水器、充电桩、蓄热电锅炉不能各自为政。工程上我倾向于把它们聚合为一个统一的“动态容量”虚拟储能模型每个时段给出聚合虚拟储能的总功率上下限以及聚合 SOC 的转移方程。热水器的处理方式和空调类似只不过把房间温度换成水箱温度把制冷换成加热SOC 定义为水箱温度线性映射。蓄热电锅炉就更简单本质上就是一个大热库只需考虑产热功率、放热功率和蓄热量的平衡。充电桩则是三个离散动作不能充、可延时充、必须马上充——在调度模型里表现为一个能量需求累积约束到用户取车时刻累计充电量必须达到设定电量的下限。聚合时要注意一个陷阱不同设备的“充放电效率”和响应速度差异很大。空调调节基本是分钟级响应热水器蓄热是小时级充电桩是事件驱动。强行把所有设备捆成一个固定参数模型会在部分时段出现容量虚高。我的处理方式是分别建模、聚合调度边界——每个时段先求各类柔性负荷可上调、可下调功率的代数和再约束聚合 SOC 的转移。这样既保住了模型的线性结构又不丢设备个性。2.4 虚拟储能与电池储能的统一调度接口模型搭好后虚拟储能和电化学储能在数学上就统一了。调度模型里只需要定义“广义储能”集合每个储能单元都有 SOC(t)、充放电功率 P_ch/P_dis、效率和容量边界。电池储能的 SOC 转移是SOC_bat(t1) SOC_bat(t) - (P_dis(t)/(eta_dis*E_bat) - P_ch(t)*eta_ch/E_bat) * dt虚拟储能的 SOC 转移写成类似形式只是“充放电”对应的是负荷功率的增减。优化求解器根本不需要区分哪个是实体电池、哪个是空调——只要给它一组一致的变量和约束它会自动分配每个时段谁来承担调峰任务。我在做联合调度时发现优化算法通常会优先调用响应快、调节成本低的虚拟储能来应对短时波动而把容量更大但循环损耗高的电池储能留给深度削峰两者互补效果非常明显。3. 优化调度问题的数学化目标函数、约束与求解器选择3.1 目标函数设计从单一省钱到多目标权衡日前优化调度的目标函数我建议先以运行成本最小为主目标再逐步叠加惩罚项。一个实用的目标函数如下min J sum( c_buy(t)*P_grid_buy(t) - c_sell(t)*P_grid_sell(t) ) % 净购电费用 sum( c_bat_op * (P_ch(t) P_dis(t)) ) % 电池损耗成本 sum( c_vess * abs(P_vess(t)) ) % 虚拟储能调节成本 sum( lambda * (S_res(t) S_vess(t)) ) % 约束松弛惩罚逐项解释背后的工程考量。净购电费用是主项峰时电价高优化器会自然倾向于减少峰时购电。电池损耗成本用充放电电量线性近似——电池每循环一次都有衰减如果目标函数里不含这一项优化器会为了省几块钱电费把电池充放得体无完肤算出来的调度策略根本不可执行。虚拟储能调节成本给的是空调等设备的额外损耗和用户舒适度补偿数值不宜设太大否则虚拟储能不会参与调节也不宜太小否则整日调度会疯狂调节室内温度。松弛惩罚是给约束留的“后门”后文会详细说。3.2 核心约束条件拆解功率平衡与舒适度的红线约束条件按功能分成五组。第一是功率平衡约束这是微网模型的骨架时刻P_grid_buy(t) P_pv(t) P_dis(t) P_vess_discharge(t) ... P_base(t) P_ch(t) P_vess_charge(t) P_grid_sell(t)注意虚拟储能的“放电”在这里表现为削减空调功率所以它出现在等号左侧作为供给项“充电”表现为增加用电功率出现在右侧作为负载项。建模时用两个非负变量 P_vess_discharge 和 P_vess_charge 来拆解双向调节避免绝对值带来的非线性。第二是储能 SOC 转移约束电池和虚拟储能各自一套前文已经给出公式这里不再重复。第三是边界约束包括 SOC 上下限、最大充放电功率、电网交互功率上限。第四是温度舒适度约束室内温度必须在用户设定带内这是虚拟储能的“红线”。第五是逻辑约束比如同一时段电池不能同时充放电、电网不能同时买入卖出这类约束用二元变量配合大M法写。3.3 求解器与建模工具选型YALMIP还是纯linprog我在Matlab里做优化调度几乎固定使用 YALMIP 外部求解器的组合。YALMIP 负责把高层的数学表达式翻译成求解器需要的标准形省去手写大规模系数矩阵的麻烦。这个问题的典型规模是 24 时段乘几十个变量本身不大但带有 0-1 变量和绝对值线性化本质是混合整数线性规划MILP。求解器方面有CPLEX或Gurobi就用它们求解速度在几秒内没有商用求解器的场景Matlab自带的 intlinprog 也能跑只是大规模时会慢一些。我用 intlinprog 跑 96 时段、四个广义储能的模型大约需要 30 秒到 1 分钟勉强可以接受。如果模型里温度动态用了非线性 ETP 公式就要谨慎了。我的做法是先把 ETP 方程在舒适度边界内线性化解耦或者直接把温度转移方程作为线性约束放进模型因为 exp(-dt/(R*C)) 在固定步长下是常数整个公式其实是线性的。YALMIP 的核心代码风格如下Constraints [Constraints, 0 P_grid_buy P_grid_max]; Constraints [Constraints, T_min T_in T_max]; Constraints [Constraints, T_in(2:end) a*T_in(1:end-1) b*(T_out(1:end-1) - Q_cool(1:end-1)*R)]; Constraints [Constraints, Q_cool Q_fixed P_vess_charge - P_vess_discharge];最后一行把空调制冷功率拆成固定部分和可调部分虚拟储能的充放电功率直接接入制冷功率变量干净利落。3.4 时间尺度细化与预测误差兜底这里额外提醒一个容易被忽略的细节日前调度的时间尺度不是越小越好。用 5 分钟间隔会显著放大负荷预测误差而且会让 MILP 规模爆炸。我常用的配置是日前调度用 1 小时、96 点时段的日内滚动修正用 15 分钟。虚拟储能最大的价值恰恰在于日内修正——它响应快、不需要充放电切换的机械损耗可以在滚动窗口里以很小的代价吸收预测偏差。还有一个兜底思路在日前模型里给功率平衡约束留一个小的备用松弛量。比如把电网交互上限设为关口变压器额定容量的 95%剩下的 5% 作为安全裕度。否则光伏预测偏乐观时实时调度阶段会出现功率越限又要临时砍空调负荷用户的体感就很差了。4. Matlab代码实现从数据准备到调度结果输出4.1 数据准备与参数初始化建模前先把“真实值”备齐代码工程的第一步不是写优化模型而是把参数整理得干净可复用。我的习惯是集中定义一组结构体避免散落一堆同名全局变量%% 基础参数 par.T 24; % 日前调度时段数 par.dt 1; % 时间步长小时 par.PV [0 0 0 ... 0.2 0.4 0.8 1.2 1.5 1.4 1.0 0.6 ... 0]; % 光伏预测 par.P_base [110 100 95 ... 180 190 170 ... 120 115]; % 基础负荷kW par.PriceBuy [0.32*ones(1,8), 0.78*ones(1,4), ...]; par.PriceSell par.PriceBuy * 0.75; %% 电池参数 par.E_bat 100; % 电池容量kWh par.P_bat_max 50; % 最大充放电功率kW par.eta_ch 0.95; par.eta_dis 0.92; par.SOC_init 0.5; par.SOC_min 0.1; par.SOC_max 0.9; %% 虚拟储能参数聚合空调系统 par.C 100; % 综合热容kWh/°C par.R 0.05; % 综合热阻°C/kW par.COP_AC 3.0; par.T_set_min 22; % 舒适度下限 par.T_set_max 26; % 舒适度上限 par.P_AC_fixed 150; % 空调基础制冷功率kW par.P_AC_adjustable 50;% 空调可调功率幅度kW这里特别提醒光伏和基础负荷的曲线一定要用真实楼宇的典型日数据至少是用同季节、同天气类型的历史平均。我用过一次开源数据集直接导致虚拟储能调度结果和实际差很多——空调功率基线对不上温度约束形同虚设。4.2 虚拟储能初始SOC计算从当前室温推算虚拟储能调度结果对初值很敏感这点后文细说。代码里的正确做法是先用当前室内温度推算初始 SOC%% 虚拟储能初始SOC计算 t0 26.5; % 当前室内温度 par.T_out 28*ones(1, par.T); % 室外温度预测 par.SOC_vess_init (t0 - par.T_set_min) / (par.T_set_max - par.T_set_min);如果调度日前室内温度已经接近舒适上限虚拟储能初始 SOC 就很低意味着可放出的“冷量”少调度优化器会自动减少它的放电任务。初始化不准第一时段调度就会冒进或保守。4.3 YALMIP建模核心脚本变量定义与约束组装建模样式的核心代码给出如下%% 优化变量 P_grid_buy sdpvar(1, par.T); P_grid_sell sdpvar(1, par.T); P_ch sdpvar(1, par.T); P_dis sdpvar(1, par.T); P_vess_ch sdpvar(1, par.T); % 虚拟储能“充电”即增加制冷功率 P_vess_dis sdpvar(1, par.T); % 虚拟储能“放电”即减少制冷功率 SOC_bat sdpvar(1, par.T1); SOC_vess sdpvar(1, par.T1); T_in sdpvar(1, par.T1); delta_bat binvar(1, par.T); % 电池充放电互斥标志 delta_grid binvar(1, par.T); % 电网买卖互斥标志 %% 约束组装 Constraints []; % 功率平衡 for t 1:par.T Constraints [Constraints, ... P_grid_buy(t) par.PV(t) P_dis(t) P_vess_dis(t) ... par.P_base(t) P_ch(t) P_vess_ch(t) P_grid_sell(t)]; end % 电池SOC转移 Constraints [Constraints, ... SOC_bat(2:end) SOC_bat(1:end-1) ... (P_ch*par.eta_ch - P_dis/par.eta_dis)/par.E_bat*par.dt]; % 虚拟储能温度转移线性ETP a_therm exp(-par.dt/(par.R*par.C)); b_therm 1 - a_therm; for t 1:par.T Constraints [Constraints, ... T_in(t1) a_therm*T_in(t) b_therm*(par.T_out(t) - (par.P_AC_fixed P_vess_ch(t) - P_vess_dis(t))*par.R)]; end % 舒适度与SOC边界 Constraints [Constraints, par.T_set_min T_in(1:end-1) par.T_set_max]; Constraints [Constraints, 0 SOC_vess 1]; Constraints [Constraints, SOC_bat(1) par.SOC_init, SOC_bat(end) par.SOC_init]; % 充放电互斥 Constraints [Constraints, ... 0 P_ch par.P_bat_max*delta_bat, ... 0 P_dis par.P_bat_max*(1-delta_bat)];目标函数里用到绝对值对 YALMIP 来说直接用 abs() 会自动处理但我更常用非负变量拆分的方式代码可读性更好转成标准形时的辅助变量也更少。4.4 求解与结果可视化一眼看出调度质量求解用一行命令注意把面板参数关掉避免刷屏ops sdpsettings(solver, cplex, verbose, 1, showprogress, 0); sol optimize(Constraints, Objective, ops); if sol.problem ~ 0 warning(求解状态: %s, yalmiperror(sol.problem)); end P_grid value(P_grid_buy) - value(P_grid_sell);结果可视化我一般画三张图。第一张是功率平衡堆叠图基础负荷、光伏、电池、虚拟储能四条曲线叠起来和电网交互曲线并排一眼能看出平衡关系。第二张是温度与 SOC 对比图室内温度曲线落在舒适区间里SOC 曲线贴着边界走说明虚拟储能在“满负荷”工作。第三张是电价与购电功率对照图理想状态下购电功率曲线应该主动避峰就谷。这三张图也是给业主汇报时的核心材料。5. 仿真结果对比与边界条件分析5.1 三种方案的经济性与削峰效果对比以一个典型办公日为例我在这里给出折算后的对比表格方便大家直观看到虚拟储能的价值数据做过去标识化处理调度方案日运行成本元峰值购电功率kW峰谷差kW无任何储能3860312148仅电池储能3415278112电池 虚拟储能融合316023678成本下降了 18%峰值购电功率下降了约 24%。这不是故事而是融合调度的典型结果——电池承担深度削峰虚拟储能负责扛短时波动和峰时前段的平抑两者配合把电网交互曲线压得非常平。不过我要提醒一句具体数字跟楼宇负荷特性、电价结构、温度舒适度范围都有关系不同项目差别很大不要拿这张表去套所有场景。5.2 虚拟储能在“鸭子曲线”时段的特殊价值关注下午 16:00~20:00 这个时段。光伏出力快速下降基础负荷快速攀升这是一个双梯度叠加的时段。电池储能因为容量有限通常在午后已经充满此时只能看着电量一点点耗尽而虚拟储能可以在这个时段逐步关停空调压缩机让房间温度从 24°C 缓慢爬升到 26°C释放出大量“冷量”支撑起 200 kW 级别的削峰能力。在仿真曲线上这个动作呈现为一条平滑的功率斜坡而不是电池那种阶梯状出力对关口变压器和上级电网都要友好得多。5.3 边界条件虚拟储能何时会失效作为从业者我要坦诚另一个方向的话虚拟储能不是所有场景都灵的。第一个失效场景是极端高温或低温天气室外温度逼近设计极限空调几乎没有关停余量舒适度约束直接锁死可控功率虚拟储能容量骤降趋近于零。第二个失效场景是用户舒适度带宽被压缩到 1°C 以内温度调节空间太小等效容量和功率都会被压得不成样子。第三个是电价峰谷差过小比如峰谷价差低于 0.2 元/kWh调节行为产生的收益覆盖不了设备损耗和舒适度成本此时虚拟储能主动参与调度反而亏本。这些边界条件说明一个道理虚拟储能是调度工具箱里的一件工具不是万能的替代方案。工程落地时最好先估算楼宇各时段的虚拟储能可调度潜力再决定要不要把虚拟储能的效益写进投资测算。6. 调试过程中踩过的坑与调参经验6.1 虚拟储能SOC初值引发的首时段振荡问题初版代码里我把 SOC_vess 初值设为 0.5结果第一时段调度结果非常激进空调功率被压到可调下限以下室内温度直线冲顶。原因很简单初值 0.5 对应室温 24°C看起来“电量充足”优化器误以为背后有巨大的蓄冷库存可以任意调度但空调功率调整速率约束没跟上。解决办法有两个一是初值必须从实际室温推算二是给第一时段的温度变化速率单独加上限制防止瞬时大幅调节。这个问题在电池储能里也存在只不过电池的 SOC 是仪表直接测的不存在温度映射的不确定性所以更容易被忽略。6.2 舒适度边界约束过紧导致模型无解我试过把温度带缩到 23~25°C配合室外 35°C 的高温日模型直接返回无解。检查发现是光伏预测偏乐观可调功率不足温度边界被顶穿。靠人为加大功率边界也不是办法因为空调压缩机有物理极限。工程上最实用的做法是引入松弛变量slack_up sdpvar(1, par.T); slack_dn sdpvar(1, par.T); Constraints [Constraints, ... par.T_set_min - slack_dn(1:end-1) T_in(1:end-1) par.T_set_max slack_up(1:end-1), ... 0 slack_up 1.5, 0 slack_dn 1.5];松弛变量设一个较小的上界比如 1.5°C配合一个较大的惩罚系数。这样模型永远有解而且只有在极端情况下才会轻微突破舒适边界属于可接受的工程折中。这个技巧我在实际项目中用过多次比写死约束再反复调整参数高效得多。6.3 绝对值线性化与求解器精度一个容易被忽略的“慢来源”早期版本里目标函数直接用 abs(P_vess)YALMIP 会自动引入辅助变量和 0-1 变量问题规模大了之后求解时间翻了好几倍。后来我全部改成非负变量拆分P_vess P_vess_ch - P_vess_dis成本项写成 sum(P_vess_ch P_vess_dis)。这样既消灭绝对值也不用额外加互斥约束——因为虚拟储能同一时刻增加负荷和削减负荷在物理上可能同时发生不同空调设备反而更贴合实际情况。求解器精度上也有个坑intlinprog 默认的MIP相对间隙是 0.05%但对这种长时间尺度的调度问题改成 0.1% 甚至 0.5% 都能接受求解时间能缩短一半以上。严格最优在这个问题里意义不大调度场景本身就有预测误差纠结 0.1% 的优化差毫无价值。6.4 代码运行提速与批量场景测试建议最后说代码性能。这类 MILP 模型在 24 时段下很小瓶颈反而在参数调整和批量测试环节。如果你要对不同电价、不同季节场景跑几十组对比建议把建模部分封装成函数输入只有参数结构体输出调度结果汇总表。另外避免在循环里反复拼接 sdpvar 数组YALMIP 的变量拼接耗时随规模增长正确的做法是先预分配一个 sdprvar 向量再通过索引赋值。我踩过这个坑同样是 96 时段模型循环拼接版跑了 2 分钟索引赋值版只要 20 秒。调试时还有一个实用习惯每轮修改完参数后先检查解的状态sol.problem再检查约束的最大违反量。YALMIP 可以用 check(Constraints) 查看每个约束的残差这比肉眼看曲线找问题高效得多。我做调度模型这么久最后分享一个小技巧把虚拟储能的可调功率留出 10% 的富余量。永远不要按理论最大可调值建模因为设备响应延迟、用户行为随机性会让实际调节能力打个折扣。这 10% 的余量是拿成本换鲁棒性整体收益往往比贴着边界跑更好。楼宇微网里的“储能”从来不应该只有电池这一张牌。虚拟储能用调度软件层面的功夫替代了一部分硬件投资对存量楼宇尤其友好。这项目做完我的体会是优化调度的难点往往不在算法本身而在于是否敢于把需求侧那些“不听话”的负荷当成正经资源来建模利用。想清楚这一点Matlab代码反而是最不费劲的部分。