简介：这份资源面向综合能源优化调度与需求响应方向的研究生、科研人员及工程技术人员，聚焦建筑蓄热系统的模型预测控制（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(k+1) = 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(N+1) x_t = cp.Variable(N+1) 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[k+1])*C_tank/dt] # SOC动态 constraints += [x_soc[k+1] == 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(solver=cp.OSQP)这段代码的逻辑是：在每个控制周期，用最新的SOC和储热温度作为初始状态，用未来N步的预测数据构造优化问题，求解后只取第一个控制量下发。参数上，N=24对应6小时预测时域，dt=0.25是15分钟滚动步长，comp=0.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(solver=cp.OSQP)参数说明：Parameter是cvxpy的占位符，值可以在不重建问题的情况下更新。注意参数不能出现在约束的左右两边同时作为变量系数，否则问题变成双线性，求解器不认。
3.3 滚动执行的时序与状态更新
滚动执行最容易翻车的地方是状态更新。每个周期结束后，必须用实测值更新SOC和储热温度，而不是用优化器预测的值。如果实测SOC和预测偏差超过5%，下一周期要适当放宽SOC约束的软边界，否则可能无解。常见做法是加松弛变量，对SOC越限做惩罚，保证问题始终可行。
soc_slack = cp.Variable(N+1, nonneg=True) 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分钟
原因：预测时域太长，或者整数变量太多。N=96（24小时，15分钟步长）的混合整数问题，求解时间可能到分钟级。
解决：缩短预测时域到6到8小时，或者把整数变量松弛成连续变量。如果必须保留整数，用滚动时域分解，只对前几个周期做整数优化，后面做连续松弛。
4.5 现象：SOC在一天结束时回不到初始值，第二天调度无解
原因：MPC没有终端约束，优化器倾向于把SOC用光来省钱。
解决：加终端SOC约束，要求最后一步SOC等于或接近初始值。如果预测时域不够长，可以设一个终端惩罚项，对偏离初始值的SOC做惩罚。
5. 进阶技巧：用场景法处理预测不确定性，让MPC更抗扰动
前面讲的MPC用的是确定性预测，但实际预测总有误差。想让调度更抗扰动，常见做法是场景法：不只用一条预测曲线，而是生成多条场景（比如光伏高、中、低三种出力），在优化目标里最小化期望成本，同时约束所有场景下都可行。这样得到的控制策略对预测误差不敏感，代价是求解规模翻几倍。
具体实现上，可以用历史预测误差的分布采样生成场景，每个场景一套光伏和负荷曲线，共享同一组控制变量，但状态变量分场景演化。目标函数是各场景成本的加权平均。场景数一般取5到10个，再多求解时间吃不消。
另一个技巧是加反馈校正：每个滚动周期结束后，用实测值与预测值的偏差去修正下一周期的预测。简单做法是加一个偏差项，比如过去三个周期光伏预测平均偏低5%，下一周期就把预测值上调5%。这个校正系数用滑动平均更新，不需要复杂模型。
我自己的习惯是，每上线一套MPC调度，先跑两周确定性版本，记录预测误差和实际成本，再用这些数据标定场景生成和反馈校正参数。不要一上来就上随机优化，参数没标定好，效果可能还不如确定性MPC。这套东西值不值得做，取决于你的预测误差有多大——如果光伏预测误差常年低于5%，确定性MPC够用；如果误差经常超过15%，场景法带来的鲁棒性提升是实打实的。希望帮到你。
本文还有配套的精品资源，点击获取
