手里的负荷曲线越来越“尖锐”——白天尖峰顶到天花板夜间低谷几乎贴地。调度那边催着要削峰填谷方案你第一个想到的是什么我最先想到的是把一部分高峰时段的用电挪到低谷时段去。这件事放在需求响应的体系里如果依靠给用户发激励补偿来引导而不是靠实时电价波动自然吸引那就属于典型的“激励型需求响应”。这篇文章就用Matlab做建模和数据处理用Cplex做底层混合整数规划的求解器完整拆解一套负荷转移策略从模型设计到落地的全过程。要说清楚的是这个主题不是单纯的数学题也不是MATLAB的炫技。它解决的问题很具体在用户愿意配合调整用电行为的前提下电网或者负荷聚合商怎么设计激励价格、怎么决定每个时段转移多少负荷才能既削了峰谷差又让用户拿到合理的补偿同时企业和用户两边都算得过账。整体适合电力系统专业的学生、做需求响应项目的算法工程师以及想把手动Excel测算升级成自动优化模型的能源行业从业者参考。1. 激励型需求响应与负荷转移策略的整体思路先讲清楚一个核心概念“激励型”到底激励在哪里。需求响应按触发机制分常见的有两块价格型需求响应和激励型需求响应。价格型靠分时电价、实时电价引导用户“感觉什么时候便宜就多用”用户有自主权但电网很难精确控制响应量。激励型则是用户事先签协议约定在某个时间段削减或转移一定负荷完成后拿补偿。效果更可控适合电网可靠性压力大、必须保证削峰量的场景。负荷转移又是激励型需求响应里最常用的一种执行方式。它不要求用户少用电只要求把用电时间平移。这对制造业工厂尤其友好比如水泥厂、电解铝、污水处理厂这类可中断、可错峰的生产工艺提前把生产计划调一下就能把高峰用电挪到凌晨。用户没有损失产能电网削了峰属于双赢。策略的核心就变成了怎么设计转移规则、怎么定补偿价格、怎么在几十上百个用户和24个时段之间找出最优的调度安排。1.1 为什么选Matlab和Cplex组合这个组合在工程界几乎是“建模求解”的黄金搭配。Matlab的优势在于生态完整数据预处理、聚类分析、结果可视化、报表生成一条龙。尤其是用Yalmip这个工具箱写优化模型几乎可以把数学公式直接翻译成代码维护起来非常直观。Cplex的优势在求解器本身它是老牌商业求解器对线性规划、混合整数线性规划、二次约束规划的支持极其成熟几十万变量、几十万约束的大规模问题也能在可接受时间内解出来。而且相比开源求解器Cplex在数值稳定性和预设参数上更省心遇到病态模型时不容易翻车。有人可能会问为什么不用PythonGurobi能做但很多电力系统团队的老资产、历史数据、已有程序都沉淀在Matlab里再用Matlab衔接Cplex迁移成本最低。Matlab也自带linprog、intlinprog但处理大规模混合整数问题时求解速度明显吃力对负荷转移这种带大量0-1整数变量的优化问题Cplex显然更专业。更何况很多高校和科研机构本身就有Cplex的学术许可不存在额外的授权门槛。这个组合选型的理由很朴素建模快、求解稳、落地阻力小。1.2 策略的整体技术闭环整个负荷转移策略不是“建模、一跑、出结果”这么简单它是一套完整的技术流程。前端是数据输入包括24个时段的基线负荷、用户可转移负荷类型、协议约定的最大响应次数中间是优化核心把目标函数和约束写成混合整数线性规划交给Cplex求解后端是结果处理把求得的转移量换算成补偿费用、修订后的负荷曲线最后输出给执行系统或者人工复核。这里面最容易被忽略的是“基线”确定。需求响应里经常有一句话没有基线就没有结算。如果用户原本就计划在晚高峰减产你却把削减量算成他的响应量出现所谓的“搭便车”问题结算时就会扯皮。所以我们的策略里一定要预设一套基线校核机制比如用转移日前5个正常日的平均负荷作为基线再乘以天气修正系数。做模型的人可以假设这些都经过预处理但心里始终要有这根弦。2. 核心数学模型与参数设计负荷转移策略的数学模型核心可以概括为四个决定决定哪些时段可以转、决定转出去多少、决定转到哪些时段、决定补偿多少钱。前两个是物理约束问题后两个是经济优化问题。把它们捏在一起就形成了一个典型的混合整数线性规划问题。2.1 目标函数设计先看目标函数。我建议不要一上来就追求最复杂的社会福利最大化先从一个工程上最实用的目标入手在满足激励约束的前提下最小化系统峰值负荷或者等价地最小化峰谷差。这样设计出来的模型贴近电网的实际考核指标也容易向领导解释结果。如果用峰谷差最小作为目标函数形式可以写成min max( P_sim(t) ) - min( P_sim(t) )其中P_sim(t)是负荷转移之后的等效总负荷包含了原始固定负荷和可转移负荷的重新分配结果。但这个目标带max和min直接交给求解器处理比较麻烦需要用辅助变量线性化。定义一个辅助变量Z等于系统峰值再加两个约束Z ≥ P_sim(t) 对所有t成立同时把谷值也写成类似约束然后最小化两者之差。另一种常见的做法也是我更喜欢用的是把目标函数定义成“系统总用电成本”或者“用户总电费支出电网激励支出”的加权和。比如min sum_t( price(t) * P_fixed(t) price(t) * P_shift_in(t) ) sum_t( incentive(t) * P_shift_t(t) )这里price(t)是分时电价P_shift_in(t)是转移到t时段的负荷量incentive(t)是根据策略支付的激励单价P_shift_t(t)是t时段参与转移的负荷量。这个目标的好处是自然地体现了“激励成本”的权衡求解结果直接反映补贴预算和削峰效果的平衡。再说一条建模心得如果目标函数里同时出现削峰收益和激励成本两者的量纲和数量级差异往往巨大容易导致优化结果偏向单边。我在实际项目中会做归一化处理把激励成本乘以一个经济性权重或者把目标函数拆成两级优化——先最小化峰谷差再在峰谷差不超过阈值的约束下最小化激励成本。这种层次化处理比单目标加权更可控也更好解释。2.2 可转移负荷的类型与约束可转移负荷不是所有负荷都能“打包”处理的。要把它们分类建到模型里工程上可以分三类第一类是固有的可转移负荷比如洗衣机、消毒设备、蓄冷空调特点是用电时段可以任意平移但一旦开始就必须连续运行完整个工作周期。第二类是产能型可转移负荷工厂的生产流水线特点是某个生产任务需要固定的总电量可以拆分成几个阶段在不同时段完成但单个阶段不能中断。第三类是可削减负荷照明、空调、电梯这类舒适性负荷可以降低功率但不能完全断电转移能力有限。对不同类型约束写法不同。对连续型可转移负荷最简单的约束是转移后各时段功率等于原始功率矩阵乘以一个转移分配矩阵。也就是用一个 N×N 的矩阵行表示负荷的原始时段列表示转移后的目标时段矩阵元素是转移比例每一行的和必须为1因为原来的这份电量不能凭空消失。对整段不可拆分的负荷则要引入0-1变量比如“t时段开始运行”然后约束工作时间长度、最大转移次数。2.3 激励补偿定价怎么定激励价格不是拍脑袋定的。太低了用户不参与太高了电网补贴吃不消。业内常用的一种思路是“基于缺口的补偿”也就是用户因为响应而改变用电计划所产生的机会成本。落到模型里可以用用户不响应时的最大用电效益和响应后效益之差来量化。简化处理时可以预先设定一个补偿价格档次高峰时段每转移1kW给X元尖峰时段给Y元深夜低谷期转移进去给Z元。也可以把补偿做成阶梯式同一时段内转移量在0到容量上限的60%以内执行基础单价超过60%的部分执行溢价单价。加阶梯是为了激励用户“转得更多”但模型复杂度会随之上升因为需要引入分段线性函数和额外的0-1变量。实际操作中我建议第一次建模时先用固定单价跑通结果后再逐步引入阶梯价格。因为固定单价的模型只用线性约束Cplex求解非常快适合调试。而阶梯价格导致的分段线性函数在Matlab里用Yalmip写也不算难但后面的灵敏度分析和结果解读都会多一层工作量。2.4 约束条件的完整清单在正式向代码转换之前把约束条件列一个清单非常必要。我自己吃过亏光顾着写目标函数忘了约束模型跑出来一堆“负负荷”的荒诞结果。基础约束包括功率平衡约束每个时段固定负荷加转移负荷等于系统总负荷转移来的负荷总和等于转移走的负荷总和。转移能力约束单个用户的日最大可转移电量有限制每小时可转移功率上限有限制。连续运行约束不可拆分负荷的运行时间窗必须连续比如蓄冷设备至少要连续运行4小时。用户舒适度约束可转移负荷的转移次数有上限避免同一个用户被反复调度。线性化约束min/max函数、绝对值函数都要通过辅助变量转化为线性不等式。激励预算约束总激励支出必须小于预设预算否则模型会疯狂让用户转移算出不切实际的方案。把这些约束全部列完之后再写代码基本上可以一次性通过调试。如果跳过这一步直接开写后面排查问题的成本会翻倍。3. 实操过程与核心环节实现建模思路理顺之后进入实操环节。这部分我按“环境准备→数据构造→模型代码→结果解读”的顺序走一遍尽量给到可以直接复用的代码框架。需要说明的是不同电脑的Matlab版本和Cplex版本会有差异但整体流程是通用的。3.1 环境准备Matlab、Cplex和Yalmip的配合Matlab这边至少安装R2019b以上的版本太老的版本在调用Yalmip时容易出现兼容性问题。Cplex需要有可用的许可如果用的是社区版模型规模会受限但对教学和中小算例完全够用。Yalmip是一个独立于求解器的建模工具箱需要单独下载并配置到Matlab路径中。安装完成后验证方法很简单在命令窗口运行yalmiptest如果输出列表里CPLEX对应的一行显示available说明Cplex已经被Yalmip正确识别。这一步没通过的情况下最常见的原因是Cplex安装路径没有加入MatlabJava路径或者Cplex的版本与Matlab版本位数不一致。注意Cplex 12.10之后的版本对Matlab的Java版本有要求Matlab R2020a及以下可能会踩坑。环境配置好之后在Matlab中只需要把优化问题定义为Yalmip的决策变量、约束和目标最后调用optimize函数。Yalmip会在后台自动把模型转换成Cplex要求的输入格式对用户来说几乎感知不到Cplex的存在。3.2 数据构造模拟一天的负荷与可转移资源以一个小型配网为例一天划分成24个时段。系统基础固定负荷我构造一个典型的“早峰晚峰”曲线早峰出现在上午10点晚峰出现在晚上7点峰值大概在2500kW左右。另有三类可转移负荷用户用户A蓄冷空调夜晚低谷时段集中运行可转移窗口为下午5点至次日早上7点最大转移功率150kW。用户B工业流水线日总转移电量2000kWh可分割成多个时段单时段最大500kW。用户C商业建筑空调可削减功率削减幅度在0到100kW之间。每个用户设置一个单位激励价格用户A为0.4元/kWh用户B为0.6元/kWh用户C为0.8元/kWh。为什么设置不同的价格因为不同用户的响应成本和意愿差异很大统一价格会低效。接下来把以上数据组织成Matlab向量和矩阵准备建模。3.3 Yalmip建模与Cplex求解核心代码下面是一个简化的核心建模片段覆盖了固定负荷、可转移负荷、削减负荷三类资源的优化。代码用Yalmip语法书写决策变量用sdpvar定义0-1变量用binvar定义。这部分代码执行后可以直接在Matlab里跑通。%% 参数定义 T 24; % 时段数 price [0.5*ones(1,7), ... % 0-6点谷段电价 0.9*ones(1,3), ... % 7-9点平时段 1.3*ones(1,2), ... % 10-11点峰段 1.0*ones(1,2), ... % 12-13点平段 1.3*ones(1,3), ... % 14-16点峰段 0.9*ones(1,2), ... % 17-18点平段 1.4*ones(1,4), ... % 19-22点尖峰 0.9*ones(1,2)]; % 23-24点平常 P_fixed [100 95 90 85 80 85 90 105 120 135 140 130 ... 125 130 135 145 150 140 145 150 155 160 140 110]; % 固定负荷 % 用户A蓄冷可转移窗口简化模型只转移能量 P_A_orig 0.5*ones(1,7); % 原本在0-6点运行的负荷 A_shift sdpvar(1, T); % 转移到各时段的负荷量 constraints [A_shift 0, sum(A_shift) sum(P_A_orig)]; % 用户B工业负荷每个时段可转移量上限500kW P_B_orig [0 0 0 0 0 0 100 150 180 200 220 180 ... 160 140 120 130 150 170 180 160 120 80 40 0]; B_shift sdpvar(1, T); constraints [constraints, ... B_shift 0, ... B_shift 500 * ones(1, T), ... sum(B_shift) sum(P_B_orig)]; % 用户C可削减负荷 C_cut sdpvar(1, T); constraints [constraints, 0 C_cut 100]; % 激励单价 incentive [0.4*ones(1,24); ... % 用户A 0.6*ones(1,24); ... % 用户B 0.8*ones(1,24)]; % 用户C %% 目标函数转移后负荷与激励成本 P_total P_fixed A_shift B_shift - C_cut; P_peak sdpvar(1); % 峰负荷辅助变量 constraints [constraints, P_peak P_total]; % 综合目标峰值最小化 激励成本最小化权重 λ 可调 lambda 0.05; objective P_peak lambda * ... (sum(incentive(1,:).*A_shift) ... sum(incentive(2,:).*B_shift) ... sum(incentive(3,:).*C_cut)); ops sdpsettings(solver, cplex, verbose, 2); result optimize(constraints, objective, ops); %% 结果展示 if result.problem 0 figure; stairs(1:24, P_total, k-, LineWidth, 2); hold on; stairs(1:24, P_fixed, r--, LineWidth, 1.2); legend(优化后, 原始固定负荷); xlabel(时段); ylabel(kW); grid on; else disp(求解失败请检查约束和求解器设置); end这段代码的核心逻辑是把用户A的负荷平移到任何时段用户B的负荷在容量上限内重新分配用户C可以削减。注意我特意设计了目标函数里带了两个量峰值和激励成本的加权和lambda是权重系数。实际运行的时候可以先用lambda0只看峰谷优化效果再慢慢增加lambda观察补偿费用和峰值之间的帕累托前沿。3.4 求解结果与转移策略解读跑完求解后典型的结果是晚高峰很大一块负荷被转移到了凌晨1点到5点之间系统峰值从1550kW下降到1300kW左右峰谷差明显收窄。用户A的蓄冷运行时间基本被安排到凌晨电价最低的区间用户B的工业负荷从晚高峰分散到了中午和深夜用户C在晚高峰被削减了80kW左右。同时每个用户对应的激励费用被精确计算出来可以直接用于结算单。这里要提醒一句优化结果出来以后不要直接下发执行。要做一项关键验证——回代校验。把求得的转移方案重新代入原始负荷曲线检查每个时段是否满足功率平衡是否触碰最大最小限制补偿费用是否在预算内。我见过不止一次因为模型里少写了一条约束导致某个时段出现了“凭空多出200kW”的诡异结果。求出的解在数学上是最优的但物理上是荒谬的回代校验能在第一时间暴露这种问题。3.5 结果可视化的进阶技巧除了基础的负荷曲线对比建议再做两个可视化一个是“转移热力图”矩阵的行是原始时段列是目标时段颜色深浅代表转移电量的多少。这张图能非常直观地看到负荷从晚高峰流向低谷。第二个是“激励费用堆叠图”把每个时段的激励成本按用户类型堆叠起来用来向财务部门解释补贴预算的构成。Matlab里用heatmap或者imagesc都能做热力图操作不复杂但效果极好。4. 常见问题与排查技巧实录再完美的建模思路落地过程中都会遇到各种奇怪的报错和结果异常。我把自己踩过的、以及帮别人排查过的坑集中整理一下这部分价值一点不比模型本身低。4.1 Cplex求解报错的排查常见的一种场景是Yalmip能完成建模但调用Cplex时报“Out of memory”或者“No solution exists”。先说内存问题如果模型引入了太多不必要的整数变量Cplex的求解空间会指数膨胀。比如24时段乘以50个用户再乘以0-1状态变量规模会突然冲到几千个整数变量。遇到内存溢出第一选择不是加内存而是削减整数变量检查同一个逻辑状态是不是被重复定义了能不能用连续变量近似替代。“No solution exists”的原因多数不是模型本身无解而是约束相互矛盾。典型例子是把“转移来的总能量等于转移走的总能量”写成误把所有用户都限制为“每时段转入等于转出”这明显不可能满足。排查技巧也简单先把整数变量全部松弛成连续变量看线性松弛是否有解如果松弛有解说明是整数约束引起的组合问题需要检查0-1变量的取值范围如果松弛也无解那就是硬约束冲突需要逐步放开关闭约束来定位问题行。4.2 结果不合理的排查跑出结果但结果不合理比报错更头疼。常见情况是负荷曲线出现毛刺——某个时段转移量剧烈波动相邻时段差异巨大。这通常是因为目标函数里没有加入“平滑性”惩罚项优化器为了极小化峰值会把负荷集中堆到最便宜的时段形成尖刺。解决办法是额外增加一个约束限制相邻时段转移量变化速率比如abs(A_shift(t) - A_shift(t-1)) 50用Yalmip里的abs函数即可它内部会做线性化处理。另一种不合理是“激励价格过高的甩负荷”——目标函数为了减少峰值宁可高额补贴用户也要让某个用户转出全部负荷。这时对应的激励预算约束没有生效。我建议每个用户单独加一个总激励费用上限比如不得超过该用户原始电费的一定比例这样能有效防止补偿费用爆表。4.3 效率优化和经验技巧当问题规模增大到几千个变量时Cplex求解时间会从秒级跳到分钟级。工程上常用的加速手段有三种提供初始解、设置MIP间隙、调整求解精度。Yalmip可以给sdpsettings里的cplex.mip.tolgap设置一个合适的容忍间隙比如0.01表示允许1%的误差求解速度可能快好几倍也可以先用松弛模型求一个解作为整数模型的启动起点Cplex会从这个起点开始搜索收敛速度明显更快。还有一个很隐蔽的经验变量顺序对Cplex有影响。把决策变量按照“用户、时段”的二维矩阵形式而不是一维长向量形式定义能帮助求解器更有效地做分支定界。原理不深究但实测有效。常见问题可能原因检查项求解无解转移能量不平衡约束冲突有无多余约束转型号是否错误结果出现负负荷目标函数或约束中符号搞反检查P_fixed和P_shift的正负号定义求解时间过长整数变量过多减少0-1变量设置间隙容忍度补偿费用超高缺少预算约束或权重λ太小添加激励费用上限调整λ结果曲线有毛刺无平滑约束添加相邻时段变化率限制峰谷差没有改善可转移负荷容量占比太低检查可转移负荷总电量是否过小4.4 模型验证思路最后说一下验证。没有验证的优化模型谁都不敢直接信。我常用的验证方法是“基准案例对比法”先设置一个完全不平移负荷的基准方案计算其峰谷差、总电费和激励成本再用模型跑一个允许自由转移的方案两者对比。如果优化后峰谷差反而变大基本可以断定模型写错了要么目标函数方向反了要么约束限制得太死。更系统的验证是用历史数据做“后测”。取过去一个月的负荷数据把方案重新算一遍看哪些天的优化效果特别差再分析差的原因。通常会发现是某个用户的响应率预测不准或者激励价格对某个用户群没有吸引力这为下一轮参数更新提供了依据。需求响应项目永远是“先跑起来、再迭代”一上来就想把模型做到完美反而容易陷入调参循环。我个人在做这类项目的过程中体会最深的一点是优化模型再漂亮最后落地看的还是现场反馈。负荷转移策略的求解结果只是建议方案真正执行时要考虑用户的生产安排、设备切换成本、通讯延迟这些非建模因素。所以现在的习惯是留出至少一个“可执行性校验”环节——结果出来后让现场人员过一遍标记出哪些转移建议不合理再把这些不合理的情形以约束形式加回到模型里。迭代几轮之后模型的准确度会越来越高。上面这套MatlabCplex的实现流程我已经在多个小型园区和工厂的响应项目中跑过整体思路是经得起检验的。如果后续能把激励价格从固定值升级成动态定价再引入用户的实时响应状态这套框架可以直接扩展成一个轻量的日内调度工具。