简介这份资源面向综合能源优化调度与需求响应方向的研究生、科研人员及工程技术人员聚焦建筑蓄热系统的模型预测控制MPC实现。背景设定为纽约市一栋配备被动与主动蓄热的办公楼费率计划包含三级需求费及系统运营商日前调度确定的逐时能源价格并建立锥形需求响应程序同时兼顾建筑人员热舒适性问题以随机最优控制语言描述通过MPC近似求解参考文档为《Model predictive control of thermal storage for demand response》。压缩包共11个文件以9个m脚本为主另含1个pdf参考文档与1个mat数据文件整体约1.59MB脚本覆盖主流程、MPC求解、参数配置与结果绘图等模块运行优化例程需CVX工具箱。目前已有1727人学习下载读者可据此复现蓄热需求响应仿真、理解锥形需求响应建模思路并借助结果图与参数脚本快速验证与二次开发。1. 综合能源优化调度遇上MPC为什么“预测不准”反而成了落地突破口做综合能源优化调度的人迟早会撞上同一个尴尬日前调度排得漂漂亮亮电价低谷猛充电、高峰少买电结果第二天光伏出力比预测少三成负荷又比预测高两成调度方案直接变成一张废纸。这不是算法不行而是“开环”调度天生对预测误差没有还手之力。模型预测控制MPC之所以在这两年被反复提起就是因为它把“预测—优化—执行—再预测”做成了滚动闭环用最新的实测数据不断修正下一步的动作。需求响应则提供了另一只手电价信号、激励补偿、可平移负荷都是调度器手里的可调资源。把这三样捏在一起——综合能源优化调度、MPC、需求响应——本质上是在解决一个很具体的问题当电、热、气多能耦合且源荷两侧都不确定时怎么让每一刻的调度决策既经济又可行。这套东西适合已经能跑通单时段优化、但被预测误差反复折磨的从业者也适合想把需求响应真正做成闭环、而不是停留在报价表上的工程团队。2. MPC滚动优化怎么嵌进综合能源调度从预测模型到控制时域2.1 为什么综合能源系统特别适合MPC而不是纯日前优化综合能源系统的核心特征是“多能耦合 多时间尺度”。电负荷秒级波动热负荷因为管网热惯性有十几分钟到小时的滞后气负荷又跟生产班次挂钩。日前优化只能给一条固定曲线一旦某个环节偏离后面全乱。MPC的价值在于它不追求一次性算准全天而是每个控制周期只优化未来一段有限时域并且只执行第一个控制量下一周期拿新数据重算。这种“走一步看一步”的策略对热惯性这种慢过程尤其友好——你不需要精确预测四小时后的热负荷只需要预测未来一到两个控制周期够用。从选型上说常见做法是把MPC的预测时域设成24小时、控制时域设成1小时滚动步长15分钟。预测时域覆盖完整的电价峰谷周期控制时域保证执行动作不会太频繁导致设备频繁启停。这个参数不是拍脑袋后面会讲怎么调。2.2 状态空间模型把电热气耦合写成MPC能吃的形式MPC要跑起来先得有预测模型。综合能源系统里最通用的是离散状态空间模型x(k1) A x(k) B u(k) E d(k) y(k) C x(k)其中x是状态量比如储电SOC、储热罐温度、室内温度u是控制量各设备出力、购电量、需求响应削减量d是可测扰动光伏、风电、负荷预测值。A、B、E可以通过机理建模或系统辨识得到。对于电热耦合常见做法是把热网惯性用一阶惯性环节近似电侧用功率平衡约束直接进优化。下面是一个用Python构造MPC优化问题的骨架基于cvxpy适合中小规模综合能源系统import cvxpy as cp import numpy as np # 时域参数 N 24 # 预测时域单位15min共6小时 dt 0.25 # 步长小时 # 状态SOC(储电), T_tank(储热) # 控制P_grid(购电), P_dr(需求响应削减), P_chp(热电联产), P_boiler(电锅炉) # 扰动P_pv(光伏预测), P_load(电负荷预测), Q_load(热负荷预测) x_soc cp.Variable(N1) x_t cp.Variable(N1) u_grid cp.Variable(N) u_dr cp.Variable(N) u_chp cp.Variable(N) u_boil cp.Variable(N) # 成本分时电价 需求响应补偿 price np.array([...]) # 24点电价 comp 0.3 # 需求响应补偿系数 cost cp.sum(cp.multiply(price, u_grid)*dt) - comp*cp.sum(u_dr*dt) constraints [] for k in range(N): # 电功率平衡 constraints [u_grid[k] u_chp[k] P_pv[k] P_load[k] - u_dr[k] u_boil[k]] # 热功率平衡简化 constraints [u_chp[k]*eta_heat u_boil[k]*eta_boil Q_load[k] (x_t[k]-x_t[k1])*C_tank/dt] # SOC动态 constraints [x_soc[k1] x_soc[k] (u_grid[k]*eta_ch - u_dr[k]/eta_dis)*dt/Cap] # 设备出力上下限 constraints [0 u_chp[k], u_chp[k] P_chp_max] constraints [0 u_boil[k], u_boil[k] P_boil_max] constraints [0 u_dr[k], u_dr[k] 0.2*P_load[k]] # 需求响应不超过负荷20% constraints [0.1 x_soc[k], x_soc[k] 0.9] prob cp.Problem(cp.Minimize(cost), constraints) prob.solve(solvercp.OSQP)这段代码的逻辑是在每个控制周期用最新的SOC和储热温度作为初始状态用未来N步的预测数据构造优化问题求解后只取第一个控制量下发。参数上N24对应6小时预测时域dt0.25是15分钟滚动步长comp0.3是需求响应补偿单价。需求响应约束里限制不超过负荷20%是常见做法避免过度削减影响生产。求解器选OSQP是因为问题本质是二次规划OSQP对这类稀疏QP收敛稳定。2.3 需求响应怎么进约束价格型与激励型要分开建模需求响应分两类价格型用户看到分时电价自发调整和激励型调度方直接给削减指令并补偿。在MPC里价格型体现在目标函数的电价系数上激励型则是一个独立的决策变量u_dr带补偿收益和削减上限约束。常见错误是把两者混在一起结果优化器为了拿补偿拼命削减负荷反而推高购电成本。正确做法是价格型通过电价曲线自然引导激励型单独设变量并限制总量比如全天削减量不超过总负荷的10%到15%。另外需求响应有响应延迟和反弹效应。空调群控削减后温度回升会导致后续负荷反弹。MPC里可以用一个反弹系数来修正比如削减量的30%会在下一周期补回来。这个系数需要根据实测数据标定没有万能值。3. 代码清晰的关键模块拆分、数据接口与求解器选择3.1 把MPC拆成预测、优化、执行三个独立模块“代码清晰”不是多写注释而是模块边界清楚。我一般把整个MPC调度器拆成三个文件predictor.py负责输出未来N步的光伏、负荷、热负荷预测序列optimizer.py只做一件事——接收预测序列和当前状态返回控制序列controller.py负责滚动调用、下发指令、记录实际执行结果。这样拆分的好处是预测模型换算法从LSTM换成XGBoost不影响优化器优化器换求解器也不影响预测模块。数据接口用统一的字典或dataclass字段名固定p_pv_forecast、p_load_forecast、q_load_forecast、soc_init、t_tank_init。每个模块只依赖这个接口不直接读数据库或文件。这样单元测试也好写——给一组固定输入检查输出是否满足功率平衡和SOC约束。3.2 求解器选择与求解时间控制综合能源MPC的优化问题通常是混合整数线性规划设备启停或二次规划功率连续可调。如果设备启停不频繁建议先做连续松弛用OSQP或ECOS求解时间在几十毫秒到几百毫秒。如果必须考虑启停用SCIP或CBC但求解时间可能到秒级15分钟滚动周期够用5分钟周期就紧张。一个实用技巧把优化问题写成参数化形式用cvxpy的Parameter定义预测数据这样每次滚动只更新参数值不重建问题。重建问题在Python里开销不小参数化后求解时间能降30%以上。p_pv_param cp.Parameter(N) p_load_param cp.Parameter(N) # 约束里用参数代替具体数值 constraints [u_grid[k] u_chp[k] p_pv_param[k] p_load_param[k] - u_dr[k] u_boil[k]] # 滚动时只更新参数 p_pv_param.value new_pv_forecast p_load_param.value new_load_forecast prob.solve(solvercp.OSQP)参数说明Parameter是cvxpy的占位符值可以在不重建问题的情况下更新。注意参数不能出现在约束的左右两边同时作为变量系数否则问题变成双线性求解器不认。3.3 滚动执行的时序与状态更新滚动执行最容易翻车的地方是状态更新。每个周期结束后必须用实测值更新SOC和储热温度而不是用优化器预测的值。如果实测SOC和预测偏差超过5%下一周期要适当放宽SOC约束的软边界否则可能无解。常见做法是加松弛变量对SOC越限做惩罚保证问题始终可行。soc_slack cp.Variable(N1, nonnegTrue) constraints [x_soc[k] 0.1 - soc_slack[k]] constraints [x_soc[k] 0.9 soc_slack[k]] cost 1000 * cp.sum(soc_slack) # 高惩罚尽量不越限这个松弛变量的惩罚系数要远大于电价成本一般取1000以上否则优化器会故意越限来省钱。4. 避坑与排查MPC需求响应调度里最容易翻车的5件事4.1 现象优化器频繁启停设备电费没省多少设备磨损严重原因目标函数只考虑了购电成本没有加启停惩罚。MPC每个周期独立优化设备在相邻周期可能反复切换状态。解决在目标函数里加启停惩罚项用相邻周期控制量的变化量乘以惩罚系数。对于热电联产惩罚系数取单次启停成本的等效值一般设为购电成本的5到10倍。4.2 现象需求响应削减量拉满但总成本反而上升原因激励型需求响应的补偿收益设得过高或者削减上限太松优化器为了拿补偿不惜多购电来满足反弹负荷。解决检查补偿系数是否超过峰谷电价差。补偿单价应低于峰电价与谷电价之差否则会出现套利。削减上限建议不超过负荷的15%并且加反弹约束。4.3 现象MPC求解失败报infeasible原因预测数据突变导致约束冲突比如光伏预测突然降到零而电负荷预测很高购电上限又不够。解决给关键约束加松弛变量尤其是功率平衡和SOC约束。松弛惩罚要大但必须存在保证问题始终有可行解。另外检查购电上限是否设得太紧一般留20%裕量。4.4 现象滚动周期设成5分钟但求解时间超过4分钟原因预测时域太长或者整数变量太多。N9624小时15分钟步长的混合整数问题求解时间可能到分钟级。解决缩短预测时域到6到8小时或者把整数变量松弛成连续变量。如果必须保留整数用滚动时域分解只对前几个周期做整数优化后面做连续松弛。4.5 现象SOC在一天结束时回不到初始值第二天调度无解原因MPC没有终端约束优化器倾向于把SOC用光来省钱。解决加终端SOC约束要求最后一步SOC等于或接近初始值。如果预测时域不够长可以设一个终端惩罚项对偏离初始值的SOC做惩罚。5. 进阶技巧用场景法处理预测不确定性让MPC更抗扰动前面讲的MPC用的是确定性预测但实际预测总有误差。想让调度更抗扰动常见做法是场景法不只用一条预测曲线而是生成多条场景比如光伏高、中、低三种出力在优化目标里最小化期望成本同时约束所有场景下都可行。这样得到的控制策略对预测误差不敏感代价是求解规模翻几倍。具体实现上可以用历史预测误差的分布采样生成场景每个场景一套光伏和负荷曲线共享同一组控制变量但状态变量分场景演化。目标函数是各场景成本的加权平均。场景数一般取5到10个再多求解时间吃不消。另一个技巧是加反馈校正每个滚动周期结束后用实测值与预测值的偏差去修正下一周期的预测。简单做法是加一个偏差项比如过去三个周期光伏预测平均偏低5%下一周期就把预测值上调5%。这个校正系数用滑动平均更新不需要复杂模型。我自己的习惯是每上线一套MPC调度先跑两周确定性版本记录预测误差和实际成本再用这些数据标定场景生成和反馈校正参数。不要一上来就上随机优化参数没标定好效果可能还不如确定性MPC。这套东西值不值得做取决于你的预测误差有多大——如果光伏预测误差常年低于5%确定性MPC够用如果误差经常超过15%场景法带来的鲁棒性提升是实打实的。希望帮到你。本文还有配套的精品资源点击获取