★ FEATURED ARTICLE 楼宇微网优化调度这个话题做电力系统方向的人应该都不陌生。传统思路基本是盯着实体设备做文章——光伏、储能电池、可控机组再去套一套优化算法。但这两年越来越多项目开始往需求侧要灵活性虚拟储能的名头也越来越响。这个项目就是典型的“需求侧虚拟储能 楼宇微网”融合调度方案用Matlab把整套优化模型落地成可运行的代码。它解决的问题很明确在不用新增一块物理电池的前提下把楼宇里空调、照明、通风这些柔性负荷变成“看不见的储能”参与削峰填谷压降用电成本。我最早接触这个方向是因为一个模拟的商业楼宇节能项目。当时面临的困境很现实楼宇光伏装机不小但自发自用率上不去午间光伏大发时用不完傍晚高峰又要高价购电。增配电池的方案因为预算被否掉了最后我们就把目光转向了楼宇自身的负荷调节潜力。实测结果让我很意外光是中央空调系统在舒适度允许范围内的功率可调幅度就能达到额定功率的20%到30%配合温度惯性完全可以等效成一台“虚拟电池”来平抑功率波动。正是这个经历让我觉得虚拟储能和楼宇微网结合这件事值得好好写一写。这篇博文面向的读者是那些手里有楼宇微网数据、想用Matlab做优化调度但还不太清楚虚拟储能怎么建模的工程师和学生。我不会只给结论会把模型推导思路、参数选择依据、代码实现架构以及踩过的坑都摊开讲尽量让读完的人能直接照着搭出一版可运行的调度程序。1. 项目核心思路与整体方案拆解1.1 为什么楼宇微网需要“虚拟储能”这步棋先盘一盘楼宇微网运行的核心矛盾。光伏出力跟着太阳走负荷跟着人的作息走两者天然不同步。中午光照最好但办公楼里人员活动和设备负荷还没上来多余的光伏只能低价上网傍晚光照减弱负荷却因为照明、空调、下班前的设备使用迎来高峰这时候又得高价从电网买电。这种“低发高用”的时间错配是楼宇微网经济性差的根源。解决时间错配问题最容易想到的方案就是储能电池。但电池的初始投资高、循环寿命有限、后期衰减还要考虑更换成本。对一个预算敏感的商业楼宇来说这笔账往往算不过来。那还有没有别的路有就是需求侧响应。楼宇负荷并不是完全刚性的空调系统有热惯性、热水系统有蓄热能力、照明和电梯也有短时调节空间。把这些柔性能力聚合起来让它们配合光伏出力和电价信号在时间轴上平移用电量宏观效果上就像一台储能装置。这就是虚拟储能的底层逻辑没有物理的电池介质但通过负荷侧的功率调节和时间累积实现了与储能系统类似的“充电、放电、容量约束”等运行特征。把它融入楼宇微网的优化调度本质上是在不增加硬件投资的情况下从运营层面挖掘电力系统的灵活性。这也是这个项目的核心立足点。1.2 方案选型与建模路线技术路线选型上我在设计这个项目时经过了反复比较。最初的方案有两个一是物理仿真路线用热力学模型逐时模拟楼宇温度响应再用启发式算法寻优二是数学优化路线把温度动态简化为状态方程将调度问题纳入混合整数线性规划MILP框架求解。我最终选了后者。原因很直接MILP框架在工程调度领域已经被验证得非常成熟求解器可以给出全局最优解或可控精度内的近似最优解可解释性也强。相比之下启发式算法虽然建模灵活但每次运行结果都有随机性后续做敏感性分析和方案对比会非常头疼。既然定了数学优化方向工具链自然就落到了Matlab加YALMIP。Matlab的数据处理能力和矩阵运算效率是它的强项YALMIP则提供了一个非常直观的建模层写完约束和目标的符号表达之后可以无缝切换到不同求解器。调度问题本身是离散时间和连续功率混合的MILP是标准且稳妥的选择。至于为什么把虚拟储能单独建模而不是塞进负荷约束里这是为了把“温度状态”和“调节功率”这两层逻辑拆开方便后续扩展电池、储能等其它灵活性资源。2. 虚拟储能系统建模从负荷特性到储能等效2.1 楼宇热动态过程与等效热参数模型虚拟储能建模的第一步是把楼宇的物理热动态过程描述清楚。这里我用的是一阶等效热参数模型也叫ETP模型。它的思路是把一栋楼简化成一个“电阻-电容”电路室内空气的热容量对应电容墙体围护结构的热阻对应电阻室外温度相当于电压源空调的制冷/制热功率相当于可控电流源。模型的状态量是室内温度T_in输入量包括室外温度T_out、空调功率Q_ac以及室内人员设备的散热量Q_gain。微分方程写出来就是% 等效热参数模型一阶ETP % C_a * dT_in/dt (T_out - T_in)/R Q_gain Q_ac C_a 150; % 室内热容单位 kWh/℃ R 6; % 围护结构热阻单位 ℃/kW Q_gain 20; % 室内人员设备散热量单位 kW Q_ac -80; % 空调制冷功率负值表示制冷单位 kW看到这个模型学过电路的人应该会觉得很亲切。室内温度T_in就是电容两端的电压它不会突变而是会随着热量的流入流出缓慢变化。这种“惯性”正是虚拟储能的根本来源因为温度不会瞬时跳变所以空调短暂停机或者降功率室内温度并不会立刻突破舒适度边界。实际工程中C_a和R的数值不能想当然。我在项目里用的方法是结合建筑面积、围护结构材料、朝向等因素先估算初值再对照历史运行数据做最小二乘辨识。简单说就是拿某段时间的实测室内温度曲线去反推模型参数让它逼近真实动态。楼宇体量越大、外墙保温越好C_a越大能“存储”的热量就越多虚拟储能的可用容量也越大。2.2 虚拟储能SOC与充放电特性定义模型建立之后第二步是把温度动态映射成“储能系统”的语言。实体储能系统有SOC、充放电功率上下限虚拟储能也必须有对应的定义否则没法纳入统一优化框架。最常见的做法是用“温度偏移量”来定义虚拟SOC。设定温度舒适度区间[T_min, T_max]和基准温度T_ref当室内温度低于T_ref时等效于楼宇“多存了冷量”SOC偏高当室内温度高于T_ref时等效于冷量被“放掉”了一部分SOC偏低。为了计算方便我在项目中直接以温度作为状态变量虚拟SOC每时段的更新方程写为% 虚拟储能SOC更新单位时间步长为1小时 % E_ves(t1) E_ves(t) - P_ves(t) * dt % 其中P_ves Q_ac(t) - Q_ac_base(t)即相对基准功率的调节量 for t 1:24 E_ves(t1) E_ves(t) - P_ves(t) * 1; % dt 1h end这里面有个关键点要提醒虚拟储能的“容量”并不是固定值它取决于当前室内温度在舒适度区间内的位置。如果温度正好落在区间中线双向可调节范围最大如果已经贴近上界或下界能继续“放电”或“充电”的余量就很小了。这一点跟实体电池很不一样电池的SOC上下限是硬约束而虚拟储能的SOC边界会随状态变化动态收紧。空调功率的调节范围也要专门处理。一台变频多联机的输出功率并不是任意连续的要考虑额定制冷量、最小功率运行限制和启停逻辑。在调度模型中我通常把空调聚合功率视为一个连续可调变量但附加最小运行功率的约束避免优化结果给出“每15分钟开开关关”这种工程上不可行的方案。2.3 与实体储能的关键差异对照在项目评审或者技术汇报的时候经常会被问到虚拟储能和实体储能到底差在哪我整理了一个对比表基本能覆盖大部分提问对比维度实体电池储能虚拟储能楼宇柔性负荷初始投资高含电池本体、PCS、土建几乎为零主要靠控制策略响应速度毫秒至秒级分钟级取决于热惯性容量特性固定容量随寿命衰减动态容量取决于温度状态能量转化效率充放电存在损耗无能量转化损耗但影响体感主要约束SOC、充放电功率、寿命舒适度区间、连续调节时长从这个表格能看出虚拟储能在成本和效率上优势明显但在响应速度和容量确定性上不如实体电池。所以项目里我的做法不是“二选一”而是把虚拟储能作为实体储能之外的一层补充灵活性。当微网需要快速功率支撑时电池顶上当需要在电价高峰时段把负荷平移出去时通过预冷/减载的虚拟储能方式来完成。两者配合整个楼宇微网的调度可行域会宽很多。3. 优化调度数学模型目标、约束与场景设计3.1 目标函数设计与成本构成有了虚拟储能的模型接下来就可以搭优化调度框架了。这个项目的优化目标是典型的经济性目标全天运行总成本最小。成本构成拆开来看主要有四块。第一块是向电网购电的成本这是大头。第二块是光伏余电上网的收益注意是负成本会扣减总费用。第三块是虚拟储能调节的补偿成本实际工程中用户参与需求侧响应通常需要一定的激励模型中会用一个很小的单位补偿系数来体现。第四块是弃光惩罚如果调度结果出现光伏出力被迫削减的情况会记录惩罚项。目标函数写成% 目标函数总运行成本最小化 objective sum(P_buy .* price_buy * dt) ... - sum(P_sell .* price_sell * dt) ... sum(abs(P_ves) .* c_ves * dt) ... sum(P_pv_curtail .* c_curtail * dt);这里P_buy、P_sell是决策变量分别表示各时段从电网购电和向电网售电的功率price_buy和price_sell是分时电价P_ves是虚拟储能调节功率P_pv_curtail是弃光功率。有一点要注意在实际项目中P_buy和P_sell必须用二元变量限定不能同时为正这是MILP模型里典型的互斥约束。目标函数的设计看似简单真正调的时候要小心权重设置。虚拟储能补偿系数如果设得太高优化会倾向于不用虚拟储能设得太低又可能让空调功率频繁波动影响用户体验。我通常的做法是先跑一版只含购售电成本的基准模型观察虚拟储能被调用的频率和幅度再回头调整补偿系数使结果兼顾经济性和舒适性。3.2 约束条件体系拆解约束条件是优化模型的骨架这一部分出错求解器再强也白搭。我在项目中把约束分成五个层次来组织。第一层是功率平衡约束要求任意时段的电源出力与负荷消耗严格相等。这里的负荷包括基础负荷和空调负荷电源包括光伏、购电、售电以及虚拟储能调节量。第二层是虚拟储能运行约束包括SOC更新方程、SOC上下限、调节功率上下限以及温度舒适度边界。第三层是空调功率约束防止优化给出的功率指令超出空调系统的物理能力。第四层是电网交互约束包括购售电功率上限和互斥关系。第五层是光伏出力约束光伏发电功率不得超过预测值。把约束写进代码的时候我的建议是按“设备-网络-交互”的逻辑分块注释方便后期排查。认真做的话每一行约束都应该能对应到物理对象和工程语义而不是写成一堆让人看不懂的矩阵。约束之间的冲突是求解器报无可行解的最常见原因我习惯在循环里逐个时段检查约束的松弛程度而不是等整体模型跑挂了再从头看。3.3 典型日场景与输入参数准备模型搭好之后需要一套输入数据才能跑出有意义的结果。我项目里用的是夏季典型工作日场景覆盖24小时时间分辨率取1小时。电价采用分时电价结构光伏出力曲线、基础负荷曲线、室外温度曲线都是根据项目地的气象和负荷特性合成的典型日数据。下面这张表是项目中用到的一份输入数据示例读者可以参照这个结构准备自己的数据时段电价元/kWh光伏出力kW基础负荷kW室外温度℃10.450342660.4585227100.85526630121.20607232150.85427834181.201811033201.20012430220.4508828数据之间其实有物理关联。室外温度最高的下午时段空调负荷和基础负荷都会走高而光伏出力反而开始衰减这时候虚拟储能的价值就体现出来了利用午间光伏大发时把室内温度提前降低相当于“充电”下午时段让空调少出力、让温度在舒适度区间内缓慢回升相当于“放电”。这样就把高价时段的用电量转移到了低价时段。4. Matlab代码实现与求解要点4.1 代码整体架构与模块划分项目代码我采用了模块化组织方式这样后期改参数、换场景、加约束都很方便。整个工程分为以下几个文件main.m % 主程序入口串联所有步骤 input_data.m % 输入参数定义模块 build_model.m % YALMIP模型构建模块 solve_and_output.m % 求解与结果输出模块 plot_results.m % 结果可视化模块main.m是整个程序的门面它的职责很纯粹加载数据、构建模型、求解、输出结果。input_data.m里集中定义电价、光伏、负荷、温度等参数以及虚拟储能和电池的参数所有模型参数都放在这里避免散落在代码各处。build_model.m是核心模块负责创建优化变量、写目标函数和约束输出一个YALMIP模型对象。solve_and_output.m负责调用求解器处理求解结果并导出Excel表格。plot_results.m则负责画图生成功率平衡图、SOC曲线、虚拟储能调节功率图等。这种结构的好处是想改虚拟储能的容量参数只需要动input_data.m里的几行想增加新的约束类型只需要在build_model.m里追加想换一套典型日数据也完全不用碰模型代码。对于还在迭代探索阶段的调度项目来说这种模块划分能省掉大量重复调试的时间。4.2 核心建模代码解析YALMIP的建模方式其实很好上手核心就三件事定义变量、写目标、加约束。我从build_model.m里抽出几个关键片段来说明。变量定义部分需要区分连续变量和二元变量。连续变量包括购电功率、售电功率、虚拟储能调节功率和SOC状态二元变量用于表示购售电的互斥状态以及可能的空调启停状态。% 定义决策变量 P_buy sdpvar(24, 1, full); % 各时段购电功率 P_sell sdpvar(24, 1, full); % 各时段售电功率 P_ves sdpvar(24, 1, full); % 虚拟储能调节功率 E_ves sdpvar(24, 1, full); % 虚拟储能SOC u_bs binvar(24, 1, full); % 购售电互斥状态1购0售约束部分我按之前说的五个层次逐块添加。功率平衡约束写在最前面因为它是最硬性的物理约束% 功率平衡约束 Constraints []; for t 1:24 Constraints [Constraints, ... P_pv(t) - P_curtail(t) P_buy(t) P_ves(t) ... P_load(t) P_ac_base(t) P_sell(t)]; end这里P_ves的符号约定是正表示虚拟储能“放电”相当于减少空调消耗向系统提供功率支持负表示“充电”相当于增加空调消耗吸收多余功率。虚拟储能的SOC更新和温度舒适度约束写在一组% 虚拟储能运行约束 Constraints [Constraints, E_ves(1) E_ves_init]; for t 1:23 Constraints [Constraints, ... E_ves(t1) E_ves(t) - P_ves(t) * dt, ... E_min E_ves(t1) E_max, ... P_ves_min(t) P_ves(t) P_ves_max(t)]; end这里有个细节值得注意P_ves_max和P_ves_min不应该是常数而应该根据当前室内温度和空调运行状态动态计算。比如在制冷模式下室内温度越接近舒适度下界空调还能继续提升功率的空间越小P_ves_min就越接近0。把这些边界做成时变约束模型才更贴近真实物理过程。4.3 求解器配置与结果后处理模型构建完成之后求解环节同样有一些经验值得分享。YALMIP默认的求解器是bnb和内点法但不适合直接解MILP这类规模稍大的问题。我在项目中优先用商用求解器如CPLEX或Gurobi两者的求解速度和数值稳定性都比默认求解器好很多。调用方式非常简单% 求解MILP问题 ops sdpsettings(solver, cplex, ... verbose, 2, ... solver.output, compact); Diagnostics optimize(Constraints, objective, ops);求解结束之后先别急着看结果要检查Diagnostics.problem状态。0表示求解成功1表示不可行2表示数值问题。在实际项目中我遇到过好几次模型报告“成功求解”结果输出功率却出现跳变或者合理性错误的情况这时候要借助YALMIP的feasible函数逐条检查约束是否满足。结果处理上我会用表格导出各时段的购售电功率、虚拟储能调节量、SOC和室内温度再画出功率平衡曲线方便汇报和进一步分析。5. 常见问题与调试经验实录5.1 模型不可行与约束冲突排查做优化调度项目碰到最多的就是求解器报告“无可行解”。头几次遇到这个问题第一反应是怀疑求解器出了问题后来发现几乎都是约束条件之间相互矛盾。最常见的矛盾出现在功率平衡和虚拟储能上下限之间。比如某一时段基础负荷很高空调已经满负荷运行光伏出力又因为云层遮挡比预测值低这时候功率平衡等式要求虚拟储能“放电”提供支撑但温度舒适度约束又禁止继续调节空调功率就会走向无解。排查思路是先给虚拟储能的功率上下限和温度边界加一个松弛变量也就是把硬约束转成软约束看看松弛量出现在哪个时段就能定位矛盾的源头。建议做法是加松弛变量后用图形工具画出来观察松弛量的时段分布再针对性地调整对应参数。我在项目里就发现午后时段的热舒适约束过紧室外温度34摄氏度时还要求室内温度严格控制在下限附近这本来就不符合楼宇的实际运行逻辑。把温度边界放松2摄氏度之后问题立刻迎刃而解。5.2 虚拟储能SOC漂移与离散化错误第二个高频问题是虚拟储能的SOC曲线出现单调漂移或者最终SOC跟初始SOC偏差很大。这个问题的根源基本都是离散化公式写错了。YALMIP模型里的时间步长dt必须和输入数据的时间分辨率严格一致。如果输入数据按小时间隔dt就是1如果改成15分钟分辨率dt就得改成0.25。我在代码迭代的过程中改过分辨率但忘了同步修改SOC更新方程里的dt系数结果就是每个时段的SOC都在悄悄累积误差跑完一天下来SOC漂到毫无物理意义的位置。这种问题表面看是“参数错误”骨子里是离散化逻辑和实际数据周期不匹配。另外能量量纲也经常出问题。空调功率单位是千瓦时间步长单位是小时那么每个时段累积的能量就是千瓦时对应的虚拟储能容量也应该是千瓦时。千万别出现功率用千瓦、热容用千焦的情况这会凭空让模型差出3600倍的系数。建议在input_data.m里把所有量纲注释清楚再写一个基于数值量级的自检脚本确保输入参数都在合理的物理范围之内。5.3 参数敏感性分析与工程化落地建议虚拟储能模型跑通之后别忘了做参数敏感性分析。这个步骤在学术汇报和工程决策里都很重要。我习惯的做法是固定其他参数不变分别扫描虚拟储能容量、温度舒适度边界、补偿价格三组参数记录总运行成本和峰时段购电量的变化。结果通常会呈现一个有趣的趋势虚拟储能容量从0开始增大时经济收益提升非常明显但容量超过某个阈值后收益增速放缓最后几乎变成一条水平线。这说明不是虚拟储能容量做得越大越好容量受温度和用户舒适度承受能力的限制确定合理的虚拟储能容量是调度方案落地的重要前提。关于工程化落地还有一条重要建议优化调度算出来的指令必须经过一层执行校验才能下发给楼宇控制系统不能直接照搬。虚拟储能本质上是在调整用户的温度体验边界如果指令让空调长时间接近温度边界运行用户投诉风险会很高。我一般会把优化结果转到实时控制器里加上滚动预测和约束软化机制并设置用户可调的舒适度等级确保调度方案在实际项目中能稳定运行。按我个人的运维体会这类项目最怕的不是算法不够先进而是模型参数脱离实际。虚拟储能的容量有多大、调节能力能到什么程度这些都得靠楼宇的实际运行数据和用户行为数据来支撑。Matlab代码写清楚只是第一关找到靠谱的参数来源、做好约束的工程化处理才是项目真正能落地的关键。如果你正在做楼宇微网或者需求侧响应方向的调度项目建议可以从这个基础框架出发先跑通一个V1版本再逐步深入细节。后续还可以往多楼宇聚合、参与辅助服务市场、空调变频精细化建模这些方向扩展这套基础模型都留了充分的延展空间。
阅读完成 · 觉得有帮助？
)
