干楼宇能源这一行很多东西都是“计划赶不上变化”逼出来的。日前调度排得好好的光伏预测半天更新一次实际出力比预报少了三成空调还在按既定计划跑电网需求响应邀约偏偏在这个节骨眼发过来室内温度眼瞅着往上走——这种手忙脚乱的场景做过楼宇能量管理的人多少都经历过。所以这次我把方案拆成了四个时间尺度来解日前调度定大方向日内非滚动调度做批次修正日内滚动调度做短时跟踪实时修正层兜底每一层都考虑需求侧响应带来的激励与约束用Matlab把整条链路跑通。这套策略适合两类人一类是做智慧楼宇、微电网或者综合能源优化方向的研究者可以参考多时间尺度调度的建模与衔接框架另一类是正在给楼宇能源管理系统写控制逻辑的工程师可以直接对照代码结构实测。1. 为什么楼宇调度必须拆成四层单一时间尺度方案的三个硬伤先说结论单靠一个时间尺度去调度楼宇本质上是在用“过期信息”做决策或者用“远期噪声”做近处动作。很多项目一上来就只做一个日前优化把24小时每条功率曲线都排到分钟级看起来精细实际运行起来全是偏差。1.1 预测的“保质期”比你想象得短电力系统的预测精度是时间的函数这是反复被验证过的规律。负荷预测、光伏预测、风电预测都一样24小时前的日前预测误差普遍能到10%到20%到了4小时以内的短期预测误差能压到5%到8%而15分钟内的超短期预测数据源好一点的话能到2%到3%。这不是预测算法不够高级而是气象变化和负荷随机性本身就是随时间和空间演化的。如果只有一个调度层比如每天优化一次并把指令直接下发给设备那你实际上是在用可能有20%误差的预测去指挥一台台15分钟内就要动作的设备。反过来如果只做高分辨率滚动优化远期信息质量又太差很容易让优化器只盯着眼前一两步错过日内大时段级别的电价调整机会。多时间尺度的本质就是让每个调度层只处理自己时间尺度内相对可靠的信息。1.2 楼宇里不同设备的“响应性格”差异巨大楼宇设备的时间常数差别特别大这也是必须分层调度的重要原因之一。HVAC系统热惯性大房间温度变化是分钟级到小时级的今天下午两点关闭空调室温要到三四点才缓慢走高储能系统的功率响应却是秒级到分钟级的逆变器随时能充能放照明可以秒级调光但不宜长时间削减充电桩可以转移充电时段却要照顾用户的取车时间。这些设备如果在同一个时间尺度里统一指挥必然有人“跟得上”、有人“跟不上”。日前层做长周期的启停计划日内层做中短期的功率分配实时层做秒级的偏差校正本质上就是把设备按响应速度分开管理让合适的调度层去指挥合适的设备。1.3 需求侧响应信号本身也是分层的需求侧响应不是一种单一命令。价格型DR的电价信号可能提前一天就公布了电网调度的削减邀约可能是提前2小时通知紧急削峰可能就是15分钟前的电话而现货实时电价则是分钟级变化的。楼宇要接得住这些信号就必须在对应的时间尺度上预留可调空间。这也是为什么不能只做“日前实时”两层中间少了日内层很多DR事件根本来不及响应或者响应了却无法把温度、储能状态顺利恢复。1.4 四层调度架构总览四层方案的分工可以先用一张表看明白调度层执行周期决策分辨率预测时域核心职责日前调度每日1次1小时24小时确定启停计划、DR合同量、储能日循环基线日内非滚动调度每4小时1次1小时未来4-6小时修正批量偏差调整HVAC设定点和可转移负荷日内滚动调度每15分钟1次15分钟未来1-4小时高频跟踪预测更新限制功率波动实时修正每1分钟或秒级1分钟未来5-15分钟消除实际与预测偏差兜底功率平衡这里要特别提醒一个容易混淆的点日内非滚动和日内滚动不是一回事。非滚动是先把一天切成几段每段独立优化一次做完就走不反复滚动则是典型模型预测控制思路每15分钟优化一次未来4小时但只执行第一个15分钟的指令然后窗口往前推。两者解决的问题不一样后面会展开讲。2. 楼宇需求侧响应建模把可调资源和响应代价写进优化模型需求侧响应建模是整个调度策略的基础也是很多Matlab代码里最容易被写坏的部分。很多初学者把DR简单理解成“电网让我降我就降”但实际建模要回答三个问题什么东西能调调到什么程度调整的代价是什么2.1 楼宇负荷画像与可调潜力一栋典型办公综合楼的负荷构成大概是这样的负荷类型典型占比可调方式响应时间可调潜力HVAC系统35%-50%温度设定点、启停、变频分钟到小时大受热惯性支撑照明系统15%-25%调光、分区关停秒级中不宜长时间削减插座与办公设备15%-20%柔性调度需用户配合分钟级中电梯水泵5%-10%基本固定不可调小充电桩0%-15%功率限制、时段转移分钟级中受用户取车时间约束从这张表能看出HVAC是楼宇需求侧响应的绝对主力。原因很简单热惯性让房间成了一个“热量缓冲池”短时间少供冷或供热室温不会立刻越限。所以优化模型里必须先给HVAC建立热动态模型否则后面谈DR削减都是空中楼阁。2.2 HVAC热动态模型把房间当成一个“热容器”楼宇热过程可以简化成等效电阻-电容模型也就是常说的RC模型。RC模型的核心想法是房间像一个大电容墙壁窗户像电阻空调像给这个电容充放热的源。用Matlab建模时离散化后的温度迭代关系可以写成T_in(k1) T_in(k) Δt/(R_eq*C_eq) * (T_out(k) - T_in(k)) Δt * Q_hvac(k) / C_eq其中C_eq是房间等效热容代表房间储存热量的能力R_eq是等效热阻代表墙体窗户对热传导的阻碍Q_hvac(k)是空调在时段k向房间供给的冷量或热量它和空调电功率通过能效比COP关联Q_hvac(k) P_hvac(k) * COP舒适度约束则把室温限制在一个区间里T_min ≤ T_in(k) ≤ T_max这里有个很关键的建模技巧温度迭代是线性等式舒适度约束是线性不等式所以整个优化模型可以保持为线性规划或混合整数线性规划。这意味着哪怕有启停状态变量、DR削减变量Matlab里借助Yalmip这类建模工具加商业MILP求解器依然能高效求解。很多项目把RC模型写出了非线性项没必要线性化足够支撑工程精度。2.3 价格型需求侧响应让电价信号进入目标函数价格型DR不需要约定某时段必须削减多少负荷它只是把电价信号暴露给优化器让优化器自己去权衡这个时段电价贵是降低空调设定点还是提前把储能充满还是把充电桩的功率压低。在Matlab优化模型里价格型DR主要体现在目标函数上minimize Σ P_grid(k) * price(k) * Δt Σ 需求响应成本 Σ 惩罚项其中P_grid(k)是时段k从电网购电的功率price(k)是日前或实时电价。目标函数最小化的是总购电成本优化器会自动在温度舒适区、储能SOC上下限、充电桩功率限制之间寻找最经济的运行点。分时电价尖峰时段它宁可让室温略微靠近舒适区上限也不愿多买一块钱的贵电。2.4 激励型需求侧响应削减合同、补贴与违约惩罚激励型DR与价格型不同楼宇和电网或聚合商签订了削减合同承诺在某个时段削减指定容量换取容量补贴和电量补贴但如果没执行到位会有惩罚。目标函数里要增加三项DR收益 r_cap * P_DR_cap r_eng * P_DR_exec分别是按照承诺容量给的容量补贴和按实际削减电量给的电量补贴违约惩罚 r_pen * max(0, P_DR_cap - P_DR_exec)即没削减够的部分要付出罚金。max(0, ...)这种项在Matlab代码里不能直接参与线性优化需要用辅助变量线性化。这也是很多新手在写DR建模时最容易卡住的地方。实际代码里我会引入一个非负变量slack_dr约束P_DR_cap - P_DR_exec ≤ slack_dr然后在目标函数里加上r_pen * slack_dr问题就变成标准线性约束了。2.5 DR基线算收益绕不开的基础最后还必须强调基线功率。DR削减量的计量方式是“基线功率减去实际功率”不是“昨日功率减去今日功率”。基线算法一般用两类日前预测功率曲线或者过去10个工作日同时段功率的中位数。许多项目在仿真阶段不重视基线等到实际结算对不上账才发现模型里根本没存基线。建议在Matlab工程结构里把基线作为独立数据保存别混在预测数据里后面做收益核算时你会感谢这个决定。3. 四个调度层的衔接逻辑从日前计划到实时动作怎么逐级消差分层调度最容易写成“四个互不相关的优化程序”这是大忌。真正有效的四层方案每一层都要接收上一层的约束边界和状态快照再向下层传递可调范围。3.1 日前层把什么“锁死”把什么“放开”日前层的输出不只是功率曲线更重要的是启停计划、储能日充放节奏和DR承诺量。这些长周期、强耦合的决策必须由日前层提前锁定否则日内层完全独立优化会把设备启停搞得很乱。但注意我建议把这些输出作为“软约束”传给日内层而不是硬性固定。完全固定日内层面对更新预测时没有调整空间经常直接无解完全放开日内层又能把日前层的长期规划全部推翻设备动作会失去一致性。工程做法是给日内层加松弛变量允许它小幅偏离启停计划但偏离要付出惩罚代价。这样既保住了日前层的战略意图又给了日内层应变余地。3.2 日内非滚动层中间层不是可有可无的过渡很多简化方案只有日前和实时两层实际跑下来实时层压力巨大因为缺乏“中等级调整”。日内非滚动层的典型做法是把一天剩余时间切成若干长度4小时左右的区间每个区间开始时做一次优化区间与区间之间只有状态衔接不往返滚动。它适合处理批量性调整比如下午整体抬高HVAC温度设定点或者把可转移负荷重新排班。非滚动层的计算量小、决策稳定适合安排需要持续一段时间的调峰策略。它和滚动层的区别就像“改航班计划”和“调整当前航线上的高度”前者是时段级的大调整后者是分钟级的微调。如果缺了这个中间层很多属于“持续几小时”的DR事件就只能靠滚动层一点一点去凑效果既慢又差。3.3 日内滚动层典型MPC式的反馈校正日内滚动层采用的是标准模型预测控制思路有三个关键要素预测模型更新、有限时域优化、只执行第一步。每15分钟唤醒一次用最新实测数据刷新预测优化未来4小时但真正下发到设备的只有第一个15分钟的指令然后窗口整体前移。滚动层最常见的问题是预测时域怎么选。时域太短看不到DR事件和电价变化的完整轮廓时域太长又与日内非滚动层职责重叠计算负担成倍增加。我在实际项目里一般选4小时步长15分钟也就是预测步数16步。这样既覆盖了大多数光伏云层波动和负荷短期变化又不至于和4小时周期的非滚动层打架。3.4 实时修正层秒级兜底尽量别做大规模优化实时修正层不需要再跑大规模优化至少不应该每秒钟都跑。我的做法是预计算一套基于规则的控制逻辑以并网点功率偏差为输入按优先级调整储能充放电功率、充电桩功率限制、照明调光最后才动HVAC设定点。优先级设计很直接谁反应快、谁对舒适度影响小谁先动。典型优先级可以是储能最灵活先动充电桩可暂停次之照明可调光再次HVAC热惯性大最迟钝放最后。只有偏差持续超过设定阈值时实时层才向滚动层申请调整温度设定点。这样设计的好处是滚动层不需要被每秒唤醒计算资源和执行寿命都更友好。3.5 层间信息流与防冲突机制四层之间的接口数据流最好在建代码之前就画清楚。我常用的接口可以总结成这张表上游层到下游层传递的信息传递形式冲突处理方式日前到日内非滚动启停计划、DR承诺、储能SOC计划软约束加边界松弛松弛量加权惩罚日内非滚动到日内滚动HVAC设定点、可调功率上下界边界约束滚动层不得越界日内滚动到实时修正指令序列、各资源可调余量参数加上下界实时层按优先级动作核心原则就一句话上一层锁死的东西越少下一层的应变能力越强。但每一层都必须清楚哪些约束是不可触碰的安全边界哪些是可以谈判的经济边界。这个分寸拿捏好了四层调度才真正“咬合”起来。4. Matlab代码实现四层调度器的主流程与核心建模细节写代码之前先把数据整理干净否则后面全是坑。Matlab工程里我最常用的目录结构是数据、模型、求解、结果四块分开四层调度分别对应四个独立函数主脚本只负责串流程。4.1 主脚本与模块划分主脚本的控制流可以用下面的伪代码表示%% 主脚本 main_building_scheduler.m clc; clear; close all; % 1 加载基础数据负荷、光伏、电价、温度、楼宇参数 load_building_data; % 2 日前调度得到启停计划、DR承诺、储能SOC计划 plan_da day_ahead_scheduling(par, price_da, load_fc_da, pv_fc_da, dr_contract); % 3 日内非滚动调度分批次修正日前计划 plan_idn intraday_nonrolling(plan_da, load_fc_idn, pv_fc_idn, price_idn); % 4 日内滚动调度15分钟步长滚动优化 plan_idr intraday_rolling(plan_idn, mpc_setup); % 5 实时修正按规则控制兜底 rt_result real_time_correction(plan_idr, real_data); % 6 结果评估与可视化 eval_scheme(rt_result, plan_da);函数分开的意义不只是整洁更是方便调试。四层调度最容易出问题的地方是层间接口参数传错把每个函数输入输出固定下来排查时判断哪一层出了问题会很省事。4.2 日前层优化的Yalmip建模日前调度是典型的混合整数线性规划核心决策变量包括电网购电功率、空调启停、HVAC电功率、室内温度、DR削减量。借助Yalmip建模时核心思路是这样的%% 日前调度核心模型示意使用Yalmip建模 yalmip(clear); P_grid sdpvar(1, 24); % 电网购电功率 u_hvac binvar(1, 24); % 空调启停状态 P_hvac sdpvar(1, 24); % 空调电功率 T_in sdpvar(1, 25); % 室内温度路径 P_dr sdpvar(1, 24); % 需求响应削减功率 % 目标函数购电成本 DR电量补贴成本 - DR容量补贴收益 obj sum(P_grid .* price_da * dt) sum(P_dr .* price_dr * dt) ... - dr_cap_revenue; % 约束 C []; % 功率平衡 C [C, P_grid P_fix P_hvac P_charge P_dr - P_pv - P_ess_dch]; % HVAC功率与启停关联 C [C, 0 P_hvac P_hvac_rated .* u_hvac]; % RC温度动态 C [C, T_in(2:25) T_in(1:24) dt/(R_eq*C_eq)*(T_out - T_in(1:24)) ... dt*P_hvac*COP/C_eq]; % 舒适度约束 C [C, T_min T_in T_max]; % DR削减量上下限 C [C, 0 P_dr P_dr_cap]; ops sdpsettings(solver, solver_name, verbose, 0); optimize(C, obj, ops);这个示意里P_dr是削减量我习惯把它放进功率平衡表达式来表示“负荷侧少用的那部分”。如果楼宇还配了储能或充电桩再继续加SOC约束和充电功率约束即可。4.3 滚动窗口的数据切片与状态传递日内滚动层在Matlab里实现时最容易写错的是索引切片和状态初值传递。每次滚动都只取当前时刻到未来4小时这一段预测数据优化完只取第一步指令但优化器内部的初始室温必须用最新实测值而不是上一次的优化值%% 日内滚动优化循环示意 H 16; % 预测时域4小时15分钟步长 N_step 96; % 一天96个15分钟时段 x_state x_measured_0; % 初始状态取实测值 for k 1:N_step range k : min(k H - 1, N_total); % 载入最新预测数据 pv_fc_k pv_fc(range); load_fc_k load_fc(range); % 用当前实测状态初始化温度变量 T_in0 x_state; % 调用滚动优化函数得到未来H步的决策序列 u_seq rolling_optimize(T_in0, pv_fc_k, load_fc_k, plan_idn); % 只应用第一步指令 result(:, k) u_seq(:, 1); % 用实测状态更新下一轮初值 x_state measure_state(k); end这个循环结构是MPC的标准骨架。任何滚动调度都离不开“应用第一步、滚动推进、用实测刷新状态”这个基本节奏楼宇调度也不列外。我在调试时经常打印x_state和预测温度曲线确认状态初值是否正确更新防止状态飘移导致优化结果一路偏离。4.4 实时修正控制函数实时修正层我建议写成独立的规则函数输入是实时的功率偏差和各资源可调余量输出是每个资源需要调整的功率。简单示意function u_rt rt_correction(p_grid_error, ess_avail, charge_avail, light_avail) u_rt zeros(1, 4); % 分别为储能、充电桩、照明、HVAC e p_grid_error; if e 0 % 实际功率高于计划需要降低 u_rt(1) min(e, ess_avail.down); e e - u_rt(1); u_rt(2) min(e, charge_avail.down); e e - u_rt(2); u_rt(3) min(e, light_avail.down); e e - u_rt(3); % 如果还有偏差才允许调整HVAC设定点 else % 实际功率低于计划需要提升 % 对称逻辑处理 end end实际项目中实时层的频率可以达到秒级所以函数内部不要做矩阵求逆或者大规模优化尽量用if-else和min-max操作完成。规则越简单越容易排查问题也越容易在控制器上部署。4.5 结果评估与可视化四层调度跑完不能只看一条功率曲线至少要评估三类指标经济性、舒适度、DR执行情况。经济性指标用单日购电成本舒适度用温度越限时间占比DR执行用实际削减量与承诺量的比值。画图的时候我通常把日前计划、滚动层实际下发指令、实时修正后的实际功率画在同一张图上再单独画温度和储能SOC曲线一眼就能看出哪一层在哪个时刻发挥了作用。5. 实测效果对比四层方案到底比两层方案强在哪为了验证四层方案的价值我拿一个典型办公综合楼模型做过对比测试。场景是配置屋顶光伏和一套储能办公面积适中HVAC为变频多联机充电桩若干参与价格型和激励型两类DR。对比方案是“日前优化实时修正兜底”的两层方案和完整的四层方案。5.1 核心指标对比指标两层方案四层方案单日购电成本基准下降6%-9%温度舒适满意度87%94%DR事件执行率73%96%并网点功率越限次数基准减少约一半不同场景、不同楼宇参数下数字会有浮动但这个趋势是稳定的四层方案并不是在某一项指标上大幅碾压而是把各项指标均衡地变好了。成本下降主要来自日内层对电价波动的响应更及时DR执行率提升主要来自非滚动层和滚动层能提前预留可调容量。5.2 为什么效果会更好层层递进消差四层方案的优势不在于某一层的算法有多先进而在于每一层都只处理自己时间尺度内相对可靠的信息。日前层看的是趋势日内非滚动层修的是批次偏差滚动层盯的是短时波动实时层兜的是最后残差。每一层消化掉一部分不确定性下一层面对的变化自然更小。这就像一个团队接力如果每个人都只负责自己这段距离整体节奏一定比一个人从头跑到尾要稳。我也遇到过一种质疑四层方案计算量是不是太大了实测下来还好。真正跑优化的是日前层和非滚动层滚动层16步的小型MILP求解时间通常在几秒以内实时层是纯规则计算。整体比“只用日前实时”的两层方案增加的计算负担完全在可控范围普通工业控制电脑跑起来没有压力。6. 落地过程踩过的三个坑不可行解、末端抖动与恢复过冲写代码和调模型的过程中四层调度最难的其实不是其中任意一层而是层与层之间的边界问题。下面这三个坑每一个都让我花了相当多时间排查值得单独拿出来说。6.1 坑一日前启停与日内温度设定冲突导致无解第一次跑完整四层链路时日内层经常直接报不可行。查了很久才发现问题出在HVAC启停约束上日前层为了成本最优在某个时段把空调启停定为0而日内层基于更新的温度预测发现如果该时段不开启HVAC室温会越限。启停被当成了硬约束日内层又没有温度越限的余地于是模型直接无解。解决方案是引入启停松弛变量把日前启停变成软约束。在日内层代码里增加类似这样的约束delta_u sdpvar(1, 24); % 启停偏离松弛 C [C, u_idn - u_da delta_u]; C [C, u_da - u_idn delta_u]; obj obj M * sum(delta_u); % M为惩罚系数这样日内层可以在必要时少量偏离日前启停计划但偏离要付出代价。既避免了无解又不会允许日内层随意推翻日前的长期决策。惩罚系数M的取值需要试一般取到购电成本量级的10倍左右效果比较合适。6.2 坑二滚动优化窗口末端的功率抖动滚动优化有个经典毛病模型在预测时域末端没有终端约束设备功率容易在窗口边界出现跳跃。虽然理论上我们只执行第一步但这种抖动会通过状态约束传递到下一轮导致实际运行时某些时段功率上下乱跳尤其是温度设定点切换的时刻。我用的解决办法是给窗口末端加一个软参考约束窗口最后一段的功率必须与日内非滚动层的计划值相差不超过允许范围相当于把非滚动层的计划当成滚动层的“遥远锚点”。加了之后末端抖动明显缓解设备运行也平滑了很多。如果你看到功率曲线末尾一直是直上直下首先检查是不是缺了这个锚定。6.3 坑三DR削减后的温度恢复过冲第三个坑出在DR事件结束后。执行削减时HVAC把制冷功率压低甚至短停室内温度会缓缓上升并接近舒适区上限。等削减窗口结束空调为了把温度拉回设定点会满负荷猛跑形成“削峰反补峰”的恢复高峰甚至比削减前还高电网看到的不是削峰而是负荷搬家。破解办法是把恢复过程也纳入优化而不是削减完就不管。我在日内滚动层的目标函数里增加了温度偏差的软约束惩罚温度离舒适中心越远付出的代价越大。这样优化器在临近DR结束时段就会提前开始温和恢复而不是等到最后一刻才猛拉制冷。这个坑特别隐蔽仿真曲线上一开始完全看不出来只有把并网点功率拉到24小时全图里对比才会发现恢复峰比削减峰还刺眼。写代码和调模型这段时间我最大的体会是四层调度最难的不是其中任意一层而是层与层之间的边界。每一层往下传的应该是“可调范围”而不是“死命令”上一层锁死的东西越少下一层的应变能力越强。建议先花半天把接口数据流画清楚再写主程序否则后面改接口会改到怀疑人生。这套结构在具体落地时可以有各种简化比如不用每次都跑优化把滚动层换成查表规则但“逐级消差、留有裕度”的思路是通用的至少我做完这个项目之后再看任何楼宇能量管理需求都习惯性地先问一句这个问题该放在哪个时间尺度上解决。