做楼宇微网优化调度最怕的不是模型建得不够复杂而是调度策略算出来之后现场说执行不了或者效果不明显。我之前给一个园区做微网调度平台光伏、储能、柴油发电机全部建模成本确实优化了但让运行费用继续往下降的反而是需求侧那批不起眼的可调资源——空调、通风、热水。把这些资源组织成“需求侧虚拟储能系统”之后波峰波谷的错峰收益非常可观。这篇文章就基于我实际做过的融合需求侧虚拟储能系统的楼宇微网优化调度项目把从问题拆解、建模思路到MATLAB落地的完整过程梳理一遍适合正在做微网调度、需求响应、建筑能源管理方向的同学参考哪怕你只是刚接触优化调度也可以照着这套框架一步步搭起来。1. 整体设计为什么要把需求侧资源当成“虚拟电池”1.1 楼宇微网里最被低估的调节资源大多数楼宇微网项目大家的注意力都会先放在光伏和蓄电池上。电池好理解能充能放SOC清清楚楚调度模型里加一组变量和约束就行。但真正做过实际运行的都清楚锂电池的单位容量成本高、寿命受循环次数影响大在楼宇场景里你很难靠电池扛住整个晚高峰的负荷转移。楼宇本身其实有大量柔性资源中央空调、地源热泵、新风系统、电热水器甚至电梯和充电桩。这些负荷并不是每个时刻都必须满功率运行而是存在一定的调节空间。最典型的温控负荷——空调它制出来的冷量或热量并不只是服务当下而是有一部分蓄在墙体、地板和家具里缓慢释放。这就相当于楼宇本身是一个巨大的“热容”。那为什么不把这些资源统一抽象成一个“需求侧虚拟储能系统”说白了就是把楼宇的蓄热特性、温控设备功率的可调范围、人员舒适度允许的波动带宽整体包装成一个可以充放电的虚拟储能单元。实际项目中一栋几千平米的办公楼利用空调系统的调节能力实现几百千瓦时的等效削峰填谷并不夸张而且几乎不增加额外硬件投资。1.2 虚拟储能的“充放电”逻辑热惯性就是仓库理解虚拟储能的运行逻辑你只需要记住一个类比把整栋楼看成一块巨大的“热容电池”“充电”是在电价低谷段让空调系统加大功率把室内温度往舒适区下限压低把冷量或热量存在围护结构和室内物体里“放电”是在电价高峰段让空调系统降低功率甚至停机靠之前蓄在墙体、地板里的冷量或热量维持室内温度在允许范围内缓慢回升。等效充放电功率取决于空调机组可调容量等效容量取决于楼宇热容量和允许温度波动范围的乘积。所以虚拟储能的SOC不是电流积出来的而是温度距离舒适区边界有多远。从投资角度看虚拟储能的边际成本几乎为零却能达到和物理储能类似的效果削峰填谷、降低需量电费、提升光伏就地消纳比例、缓解变压器容量压力。这也是近两年储能概念从“电化学储能”向“广义储能”延伸的一个重要原因。1.3 方案选型为什么用MATLAB做这件事楼宇微网优化调度本质上是一个带约束的优化问题。楼宇里有机组启停、购售电状态这种离散决策又有功率平衡、温度动态、SOC变化这种连续约束所以它通常是一个混合整数线性规划MILP问题。MATLAB在这类问题上的优势在于快速原型验证搭配YALMIP工具箱做建模层底层接Gurobi或CPLEX求解器效率非常稳定。我现在的做法是用MATLAB的面向对象编程OOP特性把光伏、储能、楼宇热动态、虚拟储能分别定义为独立类每个类封装自己的参数、状态和约束生成方法。调度主程序只负责组装目标函数和约束求解交给求解器这样就非常容易做多场景对比——换一套电价、换一组建筑参数只需要改数据文件不需要重写逻辑。当然如果只做纯数学层面的优化用Python的pyomo也是可行的。但MATLAB对电力专业背景的人更友好画图、矩阵运算、与Simulink联合做动态验证都顺手而且优化工具箱里fmincon还能处理非线性扩展问题。这个项目里我全程用MATLAB实现后续如果你想做滚动优化往模型预测控制MPC方向扩展也非常顺。2. 核心建模细节与调度约束设计2.1 楼宇热动态模型一阶等效热参数ETP模型虚拟储能建模最核心的一步就是把楼宇的热动态描述出来。工程上最常用的是基于等效热参数ETP的一阶模型物理意义清晰参数辨识也不复杂。模型本质是热力学能量平衡楼宇热容吸收的热量等于空调供冷/供热功率加上室外渗入的热量再减去楼宇向外界散掉的热量。用离散形式表达整个楼宇的室内温度递推关系是T_in(t1) T_in(t) (Δt / (C_b * R_b)) * (T_out(t) - T_in(t)) (Δt / C_b) * Q_hvac(t)其中C_b是楼宇等效热容单位kWh/℃R_b是楼宇等效热阻单位℃/kWQ_hvac(t)是空调系统在t时段注入楼宇的冷量或热量单位kWΔt是调度步长小时。这里必须强调一个非常容易踩的坑空调电功率不等于冷量/热量功率。Q_hvac应该是空调的制冷量或制热量它等于电功率乘以能效比COP。有些同学建模时直接把电功率代入热平衡方程结果调度出来温度完全不可行就是因为冷量和电量没有区分。说句实际的C_b和R_b并不需要做非常精细的现场辨识。根据建筑面积、层高、维护结构材质查表估算就能满足调度需求误差后续通过滚动优化去修正。你可以把这组参数理解为楼宇的“热惯性大小”它决定了虚拟储能的容量规模。2.2 虚拟储能的“荷电状态”SOC怎么算才合理虚拟储能既然叫储能就得有一个等效SOC来衡量它当前“蓄了多少能”。在制冷场景下室内温度越低说明蓄的冷量越多。我通常用温度相对位置来定义等效SOCSOC_v(t) (T_in_max - T_in(t)) / (T_in_max - T_in_min)T_in_max和T_in_min分别对应楼宇允许的最高温度和最低温度也就是舒适度带宽的边界。SOC_v等于0说明室内温度已经接近上限虚拟储能“放空”了SOC_v等于1说明室内温度接近下限虚拟储能“充满”了。你可以把这个SOC看成虚拟储能的能量存量指标。它的物理含义其实是室内温度偏离中间值的程度。温度越高蓄冷量越小温度越低蓄冷量越大。调度模型里约束SOC_v在0到1之间等价于约束室内温度在舒适度范围内。还有一个容易被忽略的约束温度初值要和末值衔接。如果调度周期结束时室内温度和起始温度不一致虚拟储能的SOC首尾不闭合第二天没法继续循环调度。这在模型里体现为终端温度约束后面第4章会专门讲这个问题的排查。2.3 需求侧各类可调负荷的调节边界虚拟储能系统不是单一设备而是多种柔性负荷的聚合。调度建模前先把楼宇里各类可调资源分类清楚温控负荷空调、暖通、新风功率可调运行受室内温度约束是虚拟储能最主要的组成部分。可以建模为连续可调变量有上限和下限。可平移负荷洗碗机、洗衣机、部分生产设备工作时段可以整体平移但一旦开始就要连续运行一段时间通常引入0-1变量描述启动状态。可中断负荷非关键照明、部分插座负荷可以在高峰时段切除切除后需要支付补偿费用在目标函数里体现为中断成本。储水式电热水器本质上也是一个小型虚拟储能设定温度区间内可以灵活启停。把这些资源聚合成虚拟储能系统后调度模型里只需要面对一个聚合的“充放电功率上下限”和“等效容量上下限”不需要逐个设备处理模型规模大幅缩小求解速度也快得多。2.4 目标函数和约束的数学表达楼宇微网优化调度的目标函数最通用的是最小化调度周期内的总运行费用向电网购电的费用减去售电收益可中断负荷切除造成的补偿费用微型燃气轮机或燃料电池的燃料成本储能和虚拟储能的折旧或维护费用如果做经济性评估可以加做纯优化调度可以先省略。约束条件按功能分成几块功率平衡约束光伏出力加上购电量、储能放电功率、微燃机出力要等于楼宇总负荷加上储能充电功率和售电量。这是整个模型的骨架不能漏。虚拟储能动态约束也就是上面提到的室内温度递推方程以及温度上下限、空调功率上下限。物理储能约束如果有蓄电池SOC递推公式、充放电功率限值、SOC上下限、以及SOC初末一致性约束。电网交互约束联络线功率上限、购售电不能同时进行的逻辑约束。这个一般用0-1变量实现是模型里整数变量的主要来源。光伏/机组出力约束各设备的出力上下限和爬坡速率约束。你可能会问为什么需要这么多约束因为优化算法并不会自己“理解”物理规律它只会在一个由约束划定的可行域里找最优点。如果你忘了加购售电互斥约束求解器可能算出来的策略是同时高价买电、低价卖电——数学上费用最小工程上完全不可能。这类问题在刚开始搭模型时特别容易遇到。3. MATLAB实操从数据准备到调度结果输出3.1 工程目录与基础数据准备实操第一步先建一个清晰的工程目录。我习惯这样组织project/ ├── data/ % 电价、负荷、光伏、建筑参数 ├── models/ % MATLAB类定义 ├── scripts/ % 求解主程序 ├── utils/ % 公共工具函数 └── result/ % 结果输出数据准备阶段最关键的是分时电价、基础负荷曲线、光伏出力曲线和楼宇热参数。分时电价直接决定虚拟存储值不值钱峰谷价差超过0.8元/kWh的省份虚拟储能的优势非常突出。基础负荷和光伏曲线可以用典型日数据也可以从实测数据里提取。为了方便后续验证我常在脚本里用正弦函数叠加随机波动来生成近似曲线。真实项目里这部分要换成现场采集的历史数据调度结果才有说服力。3.2 用MATLAB OOP封装微网单元模块楼宇微网涉及的设备类型多、参数杂不用OOP组织代码脚本会变得又臭又长。我建议至少定义这几个类Building楼宇热参数C_b、R_b、室内温度范围、舒适度带边界PVSystem光伏容量、效率、出力曲线VirtualStorage虚拟储能的等效容量、SOC状态、充放电效率、温度动态约束生成方法Microgrid聚合各单元组装整体约束和目标函数。拿最简单的PVSystem类举例大体结构是这样的classdef PVSystem handle properties capacity % 光伏装机容量 kW efficiency % 综合效率 outputCurve % 归一化出力曲线0~1 end methods function obj PVSystem(cap, eff, curve) obj.capacity cap; obj.efficiency eff; obj.outputCurve curve; end function P getOutput(obj, t) P obj.capacity * obj.efficiency * obj.outputCurve(t); end end end核心思路是把每个设备的“约束生成”和“状态更新”封装到类的方法里主程序不用关心设备内部逻辑只需要调用接口。这样做的好处是你后面想对比“有虚拟储能”和“无虚拟储能”两种场景只需要在组装约束时加不加对应模块几行代码就能切换。3.3 YALMIP建模与求解器调用建模阶段使用YALMIP声明决策变量和约束非常直观。以下是我在项目里反复使用的主程序骨架T 24; % 调度时段数 % 决策变量 P_grid sdpvar(1, T); % 与电网交换功率买为正 P_ac sdpvar(1, T); % 空调电功率 T_in sdpvar(1, T); % 室内温度 u_buy binvar(1, T); % 购电状态 0-1 % 辅助变量 P_net sdpvar(1, T); % 净负荷 Constraints []; % 功率平衡约束 Constraints [Constraints, P_net P_load P_ac - P_pv]; % 虚拟储能热动态约束 for t 1:T-1 Constraints [Constraints, T_in(t1) T_in(t) dt/(Cb*Rb)*(T_out(t)-T_in(t)) dt/Cb*COP*P_ac(t)]; end % 温度与功率限值 Constraints [Constraints, T_in_min T_in T_in_max]; Constraints [Constraints, 0 P_ac P_ac_max]; % 购售电互斥 Constraints [Constraints, P_grid 0 - (1-u_buy)*M]; Constraints [Constraints, P_grid u_buy*M]; % 目标函数购电费用 空调耗电费用如果你把P_ac算进电网侧就统一在P_net里结算 Objective sum(price .* P_grid); % 求解 options sdpsettings(solver, gurobi, verbose, 2); optimize(Constraints, Objective, options);注意这里我用了大M法实现购售电互斥实际工程中M的取值不能随意设取潮流上限的1.2倍左右比较稳妥太大容易造成数值问题太小又会限制可行域。求解器推荐用Gurobi性价比和稳定性都好校园许可申请也很方便。CPLEX也可以但新版对个人申请不太友好了。求解完成后直接用value()函数提取各变量结果画图即可。3.4 结果可视化和多场景对比调度结果出来后不要光看目标函数值至少要把这几张图画出来确认合理性各时段电功率平衡堆叠图购电、光伏、储能、负荷一眼看出峰谷转移是否合理室内温度曲线和虚拟储能SOC曲线确认虚拟储能“充放节奏”没有超出舒适度边界三种场景的费用对比无优化、优化但无虚拟储能、优化加虚拟储能。我在项目里最终对比的结果是考虑虚拟储能后当日运行费用比单纯优化物理储能再降低约12.6%。这还是在峰谷价差不特别大的省份如果放到尖峰电价明显的地区虚拟储能带来的收益会更突出。所以效果好不好先看电价结构这话我反复强调过很多次。4. 常见问题与排查技巧实录4.1 MATLAB环境与求解器相关的坑先说环境问题。这个项目我用MATLAB 2023b和2026b都跑过核心代码几乎没有改动。但在新版本上第一次运行时很容易遇到几个经典问题。第一个是旧脚本中文注释乱码。2023版以后MATLAB默认脚本编码策略有调整以前用GBK保存的.m文件打开后注释全是乱码。解决办法是把脚本统一另存为UTF-8编码在新版本里新建的脚本默认就是UTF-8写完直接保存即可。这个坑虽然不影响求解逻辑但项目文件一多排查问题时会非常崩溃。第二个是Gurobi和YALMIP的版本匹配问题。sdpsettings(solver,gurobi)报找不到求解器绝大多数情况是Gurobi的安装路径没有加入MATLAB路径。解决办法是在startup.m里添加addpath(C:\gurobi1100\matlab);还有一次遇到Gurobi license激活报错错误码是license manager error -8网上说法很杂我实际排查出来的原因是激活时后台有旧进程占用许可证服务。把机器上所有Gurobi相关进程彻底关掉重新运行激活工具就没问题了。4.2 模型不可行的排查路径搭完模型第一次求解大概率会碰到infeasible problem这是新手最崩溃的时刻。不用慌我提供一个调试顺序基本能快速定位问题。先把功率平衡、机组上下限这些最基础的约束保留把温度递推、SOC一致性这类“软件”约束全部注释掉确认模型能解。能解说明主体没问题然后依次放回约束放到哪一步开始报不可行问题就在哪一步。最常见的情况是第一个时段不可行。比如调度起始温度设了26度但温度下限是24度空调功率上限又很小一个时段内根本没有能力把温度降到约束范围内。解决办法是放宽第一时段温度约束或者把起始温度设为上一周期优化结果的末端温度。另外如果模型里引入了大M法M值取得太大也可能造成数值缺失表现为求解器报“numerical issues”。把M值调小同时把所有变量的量纲统一功率统一用kW能量统一用kWh费用统一用元能避免大量莫名其妙的病态问题。4.3 虚拟储能SOC漂移与循环调度的衔接这是虚拟储能模型里最有必要单独讲的问题。楼宇虚拟储能的核心约束是温度动态方程它没有物理储能那种明确的SOC恢复机制如果在优化周期结束时室内温度和起始温度不匹配虚拟储能的“荷电状态”就没法闭合。比如说早上八点开始调度时室温26度到晚上十二点优化结束后室温被算到22度相当于一个调度周期内虚拟储能“多蓄了4度的冷量”。单日看费用确实更好看但第二天开机时室温回不到26度这个策略在工程上是无法持续执行的。解决方式是在模型里加入终端一致性约束Constraints [Constraints, T_in(end) T_in_start];或者更严格地让末端温度不低于起始温度。实际项目中考虑到夜间自然降温或升温我通常给一个柔性调节空间用惩罚项引导末端温度回归这样既保证可行性又不会过度牺牲经济性。滚动优化的场景下这个约束尤其重要不然每个周期算出来的调度曲线前后矛盾根本下发不了。4.4 求解速度慢和数值病态的工程化处理调度周期越长时间分辨率越细决策变量就越多。24时段、15分钟步长就是96时段再加上0-1变量MILP的求解规模会上来。如果模型里每个可平移负荷都引入大量整数变量求解时间可能从几秒涨到几分钟。工程上有几个务实的手段。第一尽量收紧变量边界不要给sdpvar定义过宽的上下限边界越紧分支定界搜索空间越小。第二把非关键的整数变量松弛为连续变量例如楼宇中那些不重要的小功率可平移负荷可以转换成连续的“可调节比例”对总结果影响不大但求解速度提升明显。第三Gurobi的MIPGap参数可以适当放宽MIPGap, 0.01意味着允许1%的次优解很多时候实际运行中1%的经济差异根本感知不到但求解时间能缩短一个数量级。我一直强调的一个原则是调度模型是给实际楼宇做决策辅助的不是用来发论文的模型精度够用即可计算速度和鲁棒性反而更重要。在当下的工程节奏里能10秒出结果的方案就不要去追求那0.1%的理论最优而让求解器跑十分钟。最后再分享一个我个人的习惯每次跑完优化除了保存结果一定把调度策略里的关键变量导出成结构化数据和实际执行后的反馈数据放一起看。虚拟储能的效果到底有多大光看仿真数字没用要看现场空调实际功率和室内温度能不能跟上调度指令。做楼宇微网调度的最值钱的本事不是把模型建得多精巧而是让模型算出来的东西真正能落地、能耗得住。你把这个框架搭好之后后续想加需求响应、做滚动预测、接入碳约束都是在这个底座上做扩展而已。
做楼宇微网优化调度最怕的不是模型建得不够复杂而是调度策略算出来之后现场说执行不了或者效果不明显。我之前给一个园区做微网调度平台光伏、储能、柴油发电机全部建模成本确实优化了但让运行费用继续往下降的反而是需求侧那批不起眼的可调资源——空调、通风、热水。把这些资源组织成“需求侧虚拟储能系统”之后波峰波谷的错峰收益非常可观。这篇文章就基于我实际做过的融合需求侧虚拟储能系统的楼宇微网优化调度项目把从问题拆解、建模思路到MATLAB落地的完整过程梳理一遍适合正在做微网调度、需求响应、建筑能源管理方向的同学参考哪怕你只是刚接触优化调度也可以照着这套框架一步步搭起来。1. 整体设计为什么要把需求侧资源当成“虚拟电池”1.1 楼宇微网里最被低估的调节资源大多数楼宇微网项目大家的注意力都会先放在光伏和蓄电池上。电池好理解能充能放SOC清清楚楚调度模型里加一组变量和约束就行。但真正做过实际运行的都清楚锂电池的单位容量成本高、寿命受循环次数影响大在楼宇场景里你很难靠电池扛住整个晚高峰的负荷转移。楼宇本身其实有大量柔性资源中央空调、地源热泵、新风系统、电热水器甚至电梯和充电桩。这些负荷并不是每个时刻都必须满功率运行而是存在一定的调节空间。最典型的温控负荷——空调它制出来的冷量或热量并不只是服务当下而是有一部分蓄在墙体、地板和家具里缓慢释放。这就相当于楼宇本身是一个巨大的“热容”。那为什么不把这些资源统一抽象成一个“需求侧虚拟储能系统”说白了就是把楼宇的蓄热特性、温控设备功率的可调范围、人员舒适度允许的波动带宽整体包装成一个可以充放电的虚拟储能单元。实际项目中一栋几千平米的办公楼利用空调系统的调节能力实现几百千瓦时的等效削峰填谷并不夸张而且几乎不增加额外硬件投资。1.2 虚拟储能的“充放电”逻辑热惯性就是仓库理解虚拟储能的运行逻辑你只需要记住一个类比把整栋楼看成一块巨大的“热容电池”“充电”是在电价低谷段让空调系统加大功率把室内温度往舒适区下限压低把冷量或热量存在围护结构和室内物体里“放电”是在电价高峰段让空调系统降低功率甚至停机靠之前蓄在墙体、地板里的冷量或热量维持室内温度在允许范围内缓慢回升。等效充放电功率取决于空调机组可调容量等效容量取决于楼宇热容量和允许温度波动范围的乘积。所以虚拟储能的SOC不是电流积出来的而是温度距离舒适区边界有多远。从投资角度看虚拟储能的边际成本几乎为零却能达到和物理储能类似的效果削峰填谷、降低需量电费、提升光伏就地消纳比例、缓解变压器容量压力。这也是近两年储能概念从“电化学储能”向“广义储能”延伸的一个重要原因。1.3 方案选型为什么用MATLAB做这件事楼宇微网优化调度本质上是一个带约束的优化问题。楼宇里有机组启停、购售电状态这种离散决策又有功率平衡、温度动态、SOC变化这种连续约束所以它通常是一个混合整数线性规划MILP问题。MATLAB在这类问题上的优势在于快速原型验证搭配YALMIP工具箱做建模层底层接Gurobi或CPLEX求解器效率非常稳定。我现在的做法是用MATLAB的面向对象编程OOP特性把光伏、储能、楼宇热动态、虚拟储能分别定义为独立类每个类封装自己的参数、状态和约束生成方法。调度主程序只负责组装目标函数和约束求解交给求解器这样就非常容易做多场景对比——换一套电价、换一组建筑参数只需要改数据文件不需要重写逻辑。当然如果只做纯数学层面的优化用Python的pyomo也是可行的。但MATLAB对电力专业背景的人更友好画图、矩阵运算、与Simulink联合做动态验证都顺手而且优化工具箱里fmincon还能处理非线性扩展问题。这个项目里我全程用MATLAB实现后续如果你想做滚动优化往模型预测控制MPC方向扩展也非常顺。2. 核心建模细节与调度约束设计2.1 楼宇热动态模型一阶等效热参数ETP模型虚拟储能建模最核心的一步就是把楼宇的热动态描述出来。工程上最常用的是基于等效热参数ETP的一阶模型物理意义清晰参数辨识也不复杂。模型本质是热力学能量平衡楼宇热容吸收的热量等于空调供冷/供热功率加上室外渗入的热量再减去楼宇向外界散掉的热量。用离散形式表达整个楼宇的室内温度递推关系是T_in(t1) T_in(t) (Δt / (C_b * R_b)) * (T_out(t) - T_in(t)) (Δt / C_b) * Q_hvac(t)其中C_b是楼宇等效热容单位kWh/℃R_b是楼宇等效热阻单位℃/kWQ_hvac(t)是空调系统在t时段注入楼宇的冷量或热量单位kWΔt是调度步长小时。这里必须强调一个非常容易踩的坑空调电功率不等于冷量/热量功率。Q_hvac应该是空调的制冷量或制热量它等于电功率乘以能效比COP。有些同学建模时直接把电功率代入热平衡方程结果调度出来温度完全不可行就是因为冷量和电量没有区分。说句实际的C_b和R_b并不需要做非常精细的现场辨识。根据建筑面积、层高、维护结构材质查表估算就能满足调度需求误差后续通过滚动优化去修正。你可以把这组参数理解为楼宇的“热惯性大小”它决定了虚拟储能的容量规模。2.2 虚拟储能的“荷电状态”SOC怎么算才合理虚拟储能既然叫储能就得有一个等效SOC来衡量它当前“蓄了多少能”。在制冷场景下室内温度越低说明蓄的冷量越多。我通常用温度相对位置来定义等效SOCSOC_v(t) (T_in_max - T_in(t)) / (T_in_max - T_in_min)T_in_max和T_in_min分别对应楼宇允许的最高温度和最低温度也就是舒适度带宽的边界。SOC_v等于0说明室内温度已经接近上限虚拟储能“放空”了SOC_v等于1说明室内温度接近下限虚拟储能“充满”了。你可以把这个SOC看成虚拟储能的能量存量指标。它的物理含义其实是室内温度偏离中间值的程度。温度越高蓄冷量越小温度越低蓄冷量越大。调度模型里约束SOC_v在0到1之间等价于约束室内温度在舒适度范围内。还有一个容易被忽略的约束温度初值要和末值衔接。如果调度周期结束时室内温度和起始温度不一致虚拟储能的SOC首尾不闭合第二天没法继续循环调度。这在模型里体现为终端温度约束后面第4章会专门讲这个问题的排查。2.3 需求侧各类可调负荷的调节边界虚拟储能系统不是单一设备而是多种柔性负荷的聚合。调度建模前先把楼宇里各类可调资源分类清楚温控负荷空调、暖通、新风功率可调运行受室内温度约束是虚拟储能最主要的组成部分。可以建模为连续可调变量有上限和下限。可平移负荷洗碗机、洗衣机、部分生产设备工作时段可以整体平移但一旦开始就要连续运行一段时间通常引入0-1变量描述启动状态。可中断负荷非关键照明、部分插座负荷可以在高峰时段切除切除后需要支付补偿费用在目标函数里体现为中断成本。储水式电热水器本质上也是一个小型虚拟储能设定温度区间内可以灵活启停。把这些资源聚合成虚拟储能系统后调度模型里只需要面对一个聚合的“充放电功率上下限”和“等效容量上下限”不需要逐个设备处理模型规模大幅缩小求解速度也快得多。2.4 目标函数和约束的数学表达楼宇微网优化调度的目标函数最通用的是最小化调度周期内的总运行费用向电网购电的费用减去售电收益可中断负荷切除造成的补偿费用微型燃气轮机或燃料电池的燃料成本储能和虚拟储能的折旧或维护费用如果做经济性评估可以加做纯优化调度可以先省略。约束条件按功能分成几块功率平衡约束光伏出力加上购电量、储能放电功率、微燃机出力要等于楼宇总负荷加上储能充电功率和售电量。这是整个模型的骨架不能漏。虚拟储能动态约束也就是上面提到的室内温度递推方程以及温度上下限、空调功率上下限。物理储能约束如果有蓄电池SOC递推公式、充放电功率限值、SOC上下限、以及SOC初末一致性约束。电网交互约束联络线功率上限、购售电不能同时进行的逻辑约束。这个一般用0-1变量实现是模型里整数变量的主要来源。光伏/机组出力约束各设备的出力上下限和爬坡速率约束。你可能会问为什么需要这么多约束因为优化算法并不会自己“理解”物理规律它只会在一个由约束划定的可行域里找最优点。如果你忘了加购售电互斥约束求解器可能算出来的策略是同时高价买电、低价卖电——数学上费用最小工程上完全不可能。这类问题在刚开始搭模型时特别容易遇到。3. MATLAB实操从数据准备到调度结果输出3.1 工程目录与基础数据准备实操第一步先建一个清晰的工程目录。我习惯这样组织project/ ├── data/ % 电价、负荷、光伏、建筑参数 ├── models/ % MATLAB类定义 ├── scripts/ % 求解主程序 ├── utils/ % 公共工具函数 └── result/ % 结果输出数据准备阶段最关键的是分时电价、基础负荷曲线、光伏出力曲线和楼宇热参数。分时电价直接决定虚拟存储值不值钱峰谷价差超过0.8元/kWh的省份虚拟储能的优势非常突出。基础负荷和光伏曲线可以用典型日数据也可以从实测数据里提取。为了方便后续验证我常在脚本里用正弦函数叠加随机波动来生成近似曲线。真实项目里这部分要换成现场采集的历史数据调度结果才有说服力。3.2 用MATLAB OOP封装微网单元模块楼宇微网涉及的设备类型多、参数杂不用OOP组织代码脚本会变得又臭又长。我建议至少定义这几个类Building楼宇热参数C_b、R_b、室内温度范围、舒适度带边界PVSystem光伏容量、效率、出力曲线VirtualStorage虚拟储能的等效容量、SOC状态、充放电效率、温度动态约束生成方法Microgrid聚合各单元组装整体约束和目标函数。拿最简单的PVSystem类举例大体结构是这样的classdef PVSystem handle properties capacity % 光伏装机容量 kW efficiency % 综合效率 outputCurve % 归一化出力曲线0~1 end methods function obj PVSystem(cap, eff, curve) obj.capacity cap; obj.efficiency eff; obj.outputCurve curve; end function P getOutput(obj, t) P obj.capacity * obj.efficiency * obj.outputCurve(t); end end end核心思路是把每个设备的“约束生成”和“状态更新”封装到类的方法里主程序不用关心设备内部逻辑只需要调用接口。这样做的好处是你后面想对比“有虚拟储能”和“无虚拟储能”两种场景只需要在组装约束时加不加对应模块几行代码就能切换。3.3 YALMIP建模与求解器调用建模阶段使用YALMIP声明决策变量和约束非常直观。以下是我在项目里反复使用的主程序骨架T 24; % 调度时段数 % 决策变量 P_grid sdpvar(1, T); % 与电网交换功率买为正 P_ac sdpvar(1, T); % 空调电功率 T_in sdpvar(1, T); % 室内温度 u_buy binvar(1, T); % 购电状态 0-1 % 辅助变量 P_net sdpvar(1, T); % 净负荷 Constraints []; % 功率平衡约束 Constraints [Constraints, P_net P_load P_ac - P_pv]; % 虚拟储能热动态约束 for t 1:T-1 Constraints [Constraints, T_in(t1) T_in(t) dt/(Cb*Rb)*(T_out(t)-T_in(t)) dt/Cb*COP*P_ac(t)]; end % 温度与功率限值 Constraints [Constraints, T_in_min T_in T_in_max]; Constraints [Constraints, 0 P_ac P_ac_max]; % 购售电互斥 Constraints [Constraints, P_grid 0 - (1-u_buy)*M]; Constraints [Constraints, P_grid u_buy*M]; % 目标函数购电费用 空调耗电费用如果你把P_ac算进电网侧就统一在P_net里结算 Objective sum(price .* P_grid); % 求解 options sdpsettings(solver, gurobi, verbose, 2); optimize(Constraints, Objective, options);注意这里我用了大M法实现购售电互斥实际工程中M的取值不能随意设取潮流上限的1.2倍左右比较稳妥太大容易造成数值问题太小又会限制可行域。求解器推荐用Gurobi性价比和稳定性都好校园许可申请也很方便。CPLEX也可以但新版对个人申请不太友好了。求解完成后直接用value()函数提取各变量结果画图即可。3.4 结果可视化和多场景对比调度结果出来后不要光看目标函数值至少要把这几张图画出来确认合理性各时段电功率平衡堆叠图购电、光伏、储能、负荷一眼看出峰谷转移是否合理室内温度曲线和虚拟储能SOC曲线确认虚拟储能“充放节奏”没有超出舒适度边界三种场景的费用对比无优化、优化但无虚拟储能、优化加虚拟储能。我在项目里最终对比的结果是考虑虚拟储能后当日运行费用比单纯优化物理储能再降低约12.6%。这还是在峰谷价差不特别大的省份如果放到尖峰电价明显的地区虚拟储能带来的收益会更突出。所以效果好不好先看电价结构这话我反复强调过很多次。4. 常见问题与排查技巧实录4.1 MATLAB环境与求解器相关的坑先说环境问题。这个项目我用MATLAB 2023b和2026b都跑过核心代码几乎没有改动。但在新版本上第一次运行时很容易遇到几个经典问题。第一个是旧脚本中文注释乱码。2023版以后MATLAB默认脚本编码策略有调整以前用GBK保存的.m文件打开后注释全是乱码。解决办法是把脚本统一另存为UTF-8编码在新版本里新建的脚本默认就是UTF-8写完直接保存即可。这个坑虽然不影响求解逻辑但项目文件一多排查问题时会非常崩溃。第二个是Gurobi和YALMIP的版本匹配问题。sdpsettings(solver,gurobi)报找不到求解器绝大多数情况是Gurobi的安装路径没有加入MATLAB路径。解决办法是在startup.m里添加addpath(C:\gurobi1100\matlab);还有一次遇到Gurobi license激活报错错误码是license manager error -8网上说法很杂我实际排查出来的原因是激活时后台有旧进程占用许可证服务。把机器上所有Gurobi相关进程彻底关掉重新运行激活工具就没问题了。4.2 模型不可行的排查路径搭完模型第一次求解大概率会碰到infeasible problem这是新手最崩溃的时刻。不用慌我提供一个调试顺序基本能快速定位问题。先把功率平衡、机组上下限这些最基础的约束保留把温度递推、SOC一致性这类“软件”约束全部注释掉确认模型能解。能解说明主体没问题然后依次放回约束放到哪一步开始报不可行问题就在哪一步。最常见的情况是第一个时段不可行。比如调度起始温度设了26度但温度下限是24度空调功率上限又很小一个时段内根本没有能力把温度降到约束范围内。解决办法是放宽第一时段温度约束或者把起始温度设为上一周期优化结果的末端温度。另外如果模型里引入了大M法M值取得太大也可能造成数值缺失表现为求解器报“numerical issues”。把M值调小同时把所有变量的量纲统一功率统一用kW能量统一用kWh费用统一用元能避免大量莫名其妙的病态问题。4.3 虚拟储能SOC漂移与循环调度的衔接这是虚拟储能模型里最有必要单独讲的问题。楼宇虚拟储能的核心约束是温度动态方程它没有物理储能那种明确的SOC恢复机制如果在优化周期结束时室内温度和起始温度不匹配虚拟储能的“荷电状态”就没法闭合。比如说早上八点开始调度时室温26度到晚上十二点优化结束后室温被算到22度相当于一个调度周期内虚拟储能“多蓄了4度的冷量”。单日看费用确实更好看但第二天开机时室温回不到26度这个策略在工程上是无法持续执行的。解决方式是在模型里加入终端一致性约束Constraints [Constraints, T_in(end) T_in_start];或者更严格地让末端温度不低于起始温度。实际项目中考虑到夜间自然降温或升温我通常给一个柔性调节空间用惩罚项引导末端温度回归这样既保证可行性又不会过度牺牲经济性。滚动优化的场景下这个约束尤其重要不然每个周期算出来的调度曲线前后矛盾根本下发不了。4.4 求解速度慢和数值病态的工程化处理调度周期越长时间分辨率越细决策变量就越多。24时段、15分钟步长就是96时段再加上0-1变量MILP的求解规模会上来。如果模型里每个可平移负荷都引入大量整数变量求解时间可能从几秒涨到几分钟。工程上有几个务实的手段。第一尽量收紧变量边界不要给sdpvar定义过宽的上下限边界越紧分支定界搜索空间越小。第二把非关键的整数变量松弛为连续变量例如楼宇中那些不重要的小功率可平移负荷可以转换成连续的“可调节比例”对总结果影响不大但求解速度提升明显。第三Gurobi的MIPGap参数可以适当放宽MIPGap, 0.01意味着允许1%的次优解很多时候实际运行中1%的经济差异根本感知不到但求解时间能缩短一个数量级。我一直强调的一个原则是调度模型是给实际楼宇做决策辅助的不是用来发论文的模型精度够用即可计算速度和鲁棒性反而更重要。在当下的工程节奏里能10秒出结果的方案就不要去追求那0.1%的理论最优而让求解器跑十分钟。最后再分享一个我个人的习惯每次跑完优化除了保存结果一定把调度策略里的关键变量导出成结构化数据和实际执行后的反馈数据放一起看。虚拟储能的效果到底有多大光看仿真数字没用要看现场空调实际功率和室内温度能不能跟上调度指令。做楼宇微网调度的最值钱的本事不是把模型建得多精巧而是让模型算出来的东西真正能落地、能耗得住。你把这个框架搭好之后后续想加需求响应、做滚动预测、接入碳约束都是在这个底座上做扩展而已。
