1. 项目定位与整体思路为什么微电网调度要引入MPC做微电网调度的同学对MPC这个词一定不陌生。最近我把一个基于模型预测控制Model Predictive ControlMPC的微电网调度优化项目完整重写了一遍用Python实现了一套滚动调度仿真把光伏出力预测、储能SOC约束、柴油机组爬坡限制和联络线购售电计划全部装进同一个优化框架。这篇文章是这次项目的完整复盘重点说清楚三件事为什么微电网调度适合用MPC而不是普通的前日优化数学模型里哪些约束最容易把自己绕进去以及Python代码怎么从零搭起来并跑出可用结果。传统微电网调度长期依赖“日前计划日内执行”的开环模式。电网调度员凌晨根据预测的光伏、负荷和电价算出一份24小时的机组出力和储能充放电计划然后下发给各设备执行。这个模式在预测非常准的年代够用但现在微网里分布式光伏渗透率越来越高一块云飘过来光伏出力几分钟内就能跌掉一半负荷侧的电动汽车充电行为又很难提前预估。开环计划最大的问题是没有反馈预测错了计划里该储能放电的时刻主网反而在尖峰电价段机组爬坡又被硬性约束卡死调度员只能手动干预或者忍受切负荷。MPC做的事情本质上是在每一个滚动周期内基于当前实测状态重新求解一个有限时域的优化问题求解完之后也只执行第一步的控制量等到下一个周期再刷新量测和预测再次求解。这种“滚动优化反馈校正”的机制相当于把调度从开环变成了闭环。我经常打一个比方日前计划像是出发前用导航规划全程路线MPC则像是每次看到前方路口情况后重新校准方向盘目标没变但路径一直在微调。正是因为微电网里的不确定性远比传统大电网严重MPC在这个场景下的价值才特别突出。1.1 微电网调度为什么必须处理“不确定性和耦合约束”微电网调度真正难的地方不是单个设备不好管而是设备之间的强耦合。储能出力会改变下一时刻的SOC柴油机组上一时刻的功率会限制这一时刻的爬坡速率联络线购电多了主网侧交换功率就可能越限。这些约束在时间上是跨时段绑定的如果在一个开环计划里把所有东西一次性算死任何一个预测误差都可能让后续时段集体失衡。MPC天然适合这种场地因为它的优化不是一次性全局求解而是分段滚动求解。每一个时段虽然也在解一个未来若干步的优化问题但下一步执行前必然用最新量测刷新状态所以单个时段的预测误差会被及时修正。另一个好处是约束处理特别自然SOC上下限、爬坡速率、联络线交换功率这些约束可以直接写进每个滚动周期的优化问题里不需要像PID那样额外设计一个防越限逻辑。对做工程落地的人来说这一点省掉的工作量非常可观。1.2 MPC方案与经典调度方法的对比选型我在项目设计初期其实对比过三条技术路线。第一条是传统的混合整数线性规划日前调度优点是能直接求出全天全局最优解缺点是一旦预测偏差大计划根本无法执行必须靠人工二次调整。第二条是专家规则或启发式算法比如“峰时放电、谷时充电”“光伏大发时优先储能消纳”这类方法实现简单且鲁棒但很难做到成本最优在复杂拓扑和分时电价环境下尤其吃力。第三条就是MPC它在“全局最优性”和“在线鲁棒性”之间找到了一个平衡点。方案计划形态对预测误差的处理约束满足能力在线执行成本日前开环优化一次性固化全天计划无修正手段计划层面满足低专家规则/启发式实时生成凭经验调整依赖规则设计中MPC滚动优化每周期刷新若干步计划闭环反馈修正在线写入约束中高但可接受从我的实践看MPC对硬件的要求并不像想象中高一个小型微电网的调度问题哪怕时域取24步、步长1小时单次求解也只需要零点几秒。这个速度完全符合实际控制周期要求也正因如此Python在工程仿真层面的灵活性成了非常大的优势。1.3 这个Python项目的边界与适用对象这套代码覆盖了从数据生成负荷、光伏、电价、模型建模目标函数与约束、滚动求解到结果可视化的完整链路。它不是工业级EMS系统而是把MPC调度算法的核心逻辑用最简方式跑通方便做毕设、课程项目或者小论文验证算法效果。如果你是想验证“MPC比传统日前优化成本更低”的假设或者想对比不同预测时域对调度结果的影响这个框架能直接复用。需要有一点优化理论和线性规划基础但不需要太高会用Python、看得懂二次函数就能把代码改造成自己的版本。2. 微电网对象建模与调度问题数学化实战项目里最花时间的环节不是写求解器而是把一个混合了分布式电源、储能、可控机组和负荷的微电网用数学表达式描述清楚。建模的粒度直接决定优化问题的规模和解的质量这里我按自己做项目的习惯把模型拆成目标函数、等式约束和不等式约束三块来拆解。2.1 典型微电网拓扑与调度单元的划分先明确调度对象。我搭建的示例微电网包含四类单元分布式光伏不可控、储能电池可控、柴油发电机组可控、主网联络线可控允许双向购售电同时负荷作为不可控单元参与功率平衡。实际工程里还有风机、微型燃气轮机、电动汽车充电桩等原理完全一致只需要按照“是否可控”把它们填进对应位置。这种划分对建模的意义在于不可控单元的输出直接作为预测输入序列可控单元的输出才是优化变量。楼宇或工业园区微电网通常还有温控负荷或可中断负荷这部分可以建模成“可削减负荷”在功率不平衡时允许以惩罚成本削减一部分用电量这就需要一个非负的松弛变量。我在项目里把它写成shed相当于给优化问题一个逃生通道否则高比例新能源微网在极端场景下很容易因为硬约束冲突而无解。2.2 目标函数运行成本最小化的层次设计微电网调度优化最常用的目标是“在满足供需平衡和设备约束的前提下使总运行成本最小”。总成本通常由五部分构成可控机组燃料成本、储能的充放电损耗与老化折算、从主网购电成本、向主网售电的收益负成本以及切负荷惩罚成本。写成数学表达式大致是$$ \min ; \sum_{k0}^{N-1} \left( c_g P_g(k) c_{bat} |P_{bat}(k)| c_{grid}(k)P_{grid}(k) c_{shed} P_{shed}(k) \right) $$其中 $N$ 是预测时域长度$P_g$ 是机组出力$P_{bat}$ 是储能输出功率$P_{grid}$ 是联络线交换功率$P_{shed}$ 是切负荷量。这里的核心技巧是权重的选取$c_g$ 根据柴油单价和机组热耗曲线折算$c_{grid}(k)$ 直接使用分时电价序列$c_{shed}$ 通常设成电价的数倍确保优化求解时宁愿动用储能或机组也不轻易切负荷。我还见过在目标函数里加入碳排放项的做法本质上就是给煤电或油气机组加一个环境成本系数结构上完全兼容。2.3 约束条件功率平衡、储能SOC与机组爬坡约束条件才是MPC模型里真正容易出问题的地方。最基本的功率平衡约束是$$ P_g(k) P_{pv}(k) P_{bat}(k) P_{grid}(k) P_{shed}(k) P_{load}(k) $$储能SOC的递推关系表示为$$ SOC(k1) SOC(k) - \frac{\eta_{bat} \cdot P_{bat}(k) \cdot \Delta t}{E_{bat}} $$这个约束连接了相邻两个滚动周期的状态意味着SOC不能只写成每一周期独立的不等式必须加入时间耦合。新手最容易犯的毛病是各周期孤立地给SOC设上下限结果变量在相邻周期之间突变储能出力完全失真。另外机组爬坡约束也是一个跨时段约束它限制 $P_g(k1)-P_g(k)$ 的绝对值不超过爬坡速率我一开始把这项漏掉求解结果中机组出力像脉冲一样跳变物理上根本无法执行。储能模型的细节值得多提一句。上面这个递推公式隐含了一个简化假设把储能等效成“一个既能吸收也能放出功率的可调电源”忽略充放电效率差异。如果你想把效率差异做进去就必须拆分充电功率和放电功率两个变量再加上非负约束和一个逻辑约束来保证不会同时充放电。这样模型就从线性问题变成混合整数问题计算量显著变大。在我的项目版本里由于主要验证调度经济性先用简化连续模型跑通再在扩展版本里引入充放电独立变量。建议你也按这个顺序处理先把主线跑通再叠复杂性。2.4 预测时域与步长的设计原则MPC里的预测时域 $N$ 和采样步长 $\Delta t$ 直接决定了优化问题的“视野”。步长越短控制精度越高但求解规模也随之增大时域越长优化越能前瞻性地安排储能充放电但远期预测的误差也会被放大。从我的实际调试经验看以小时级调度为例取 $\Delta t 1h$、$N 24$ 是个比较稳妥的组合既能覆盖一天内完整的峰谷电价周期又不会让求解器负担太重。如果你要做15分钟级控制我建议把 $N$ 缩到16到32之间对应4到8小时的窗口兼顾响应速度与计算量。3. Python实现MPC调度的核心代码拆解整个项目的代码结构并不复杂按照“数据准备→MPC求解→滚动执行→可视化”四层组织即可。这里重点讲清楚如何用cvxpy把上一节的数学模型直接转换为可求解的代码以及滚动主循环里的关键逻辑。3.1 工具选型与环境依赖项目核心依赖只有四个numpy做数据计算cvxpy做凸优化建模与求解底层可以切换ECOS、OSQP等求解器matplotlib画调度曲线pandas读入负荷和电价数据。安装非常省事执行pip install numpy cvxpy matplotlib pandas即可。这里提醒一点cvxpy版本更新较快如果后续遇到API变更问题推荐锁定cvxpy 1.3.x附近的稳定版本我在调试时发现新版对某些老写法的兼容性会变化。为什么选cvxpy而不是手写梯度下降或直接用scipy.optimize因为MPC本质上是带约束的凸优化问题cvxpy采用描述性建模方式你只需要把目标函数和约束条件“翻译”成它的语法求解器会自动处理矩阵变换和求解策略。手写传统优化算法在约束较多时很容易遗漏边界条件而scipy.optimize虽然灵活但处理矩阵形式的约束表达需要更繁琐的转换迭代效率也低。对工程实现来说cvxpy是当前性价比最高的选择。3.2 用cvxpy建模MPC优化问题下面是项目里MPC核心求解部分的代码框架我把注释写得比较详细方便直接对照前面的数学公式看import numpy as np import cvxpy as cp # ------- 参数设置单位kW, kWh, 元/kWh ------- H 24 # 预测时域步数 dt 1.0 # 步长单位小时 E_bat 200.0 # 储能容量 kWh SOC_0 0.5 # 初始SOC SOC_max, SOC_min 0.9, 0.2 P_bat_max 80.0 # 储能最大功率 P_g_max, P_g_min 150.0, 10.0 # 柴油机组功率范围 ramp_max 30.0 # 机组爬坡速率 kW/h P_line_max 120.0 # 联络线交换功率上限 # 预测序列实际项目中来自预测模块 P_load np.array([100, 105, 110, 120, 115, 105, 98, 102, 108, 118, 128, 135, 138, 130, 125, 118, 110, 108, 112, 118, 120, 116, 108, 100]) P_pv np.array([0, 0, 0, 0, 20, 55, 90, 108, 118, 125, 118, 90, 68, 45, 25, 12, 5, 0, 0, 0, 0, 0, 0, 0]) # 成本数据 c_g 0.6 # 机组发电成本 c_grid 0.5 # 购电电价 c_grid_sell 0.35 # 售电电价 c_shed 3.0 # 切负荷惩罚 # ------- 优化变量 ------- P_g cp.Variable(H) # 柴油机组出力 P_bat cp.Variable(H) # 储能母线功率正放电负充电 P_grid cp.Variable(H) # 联络线功率正购电负售电 P_shed cp.Variable(H, nonnegTrue) # 切负荷量必须非负 SOC cp.Variable(H1) # SOC轨迹比功率多一个端点 # ------- 约束条件 ------- constraints [] # 功率平衡约束 constraints.append(P_g P_pv P_bat P_grid P_shed P_load) # 柴油机组出力范围与爬坡约束 constraints.append(P_g P_g_min) constraints.append(P_g P_g_max) for k in range(H-1): constraints.append(P_g[k1] - P_g[k] ramp_max) constraints.append(P_g[k1] - P_g[k] -ramp_max) # 储能SOC递推与出力限制 constraints.append(SOC[0] SOC_0) constraints.append(P_bat P_bat_max) constraints.append(P_bat -P_bat_max) for k in range(H): constraints.append(SOC[k1] SOC[k] - P_bat[k] * dt / E_bat) constraints.append(SOC SOC_min) constraints.append(SOC SOC_max) # 联络线功率限制 constraints.append(P_grid P_line_max) constraints.append(P_grid -P_line_max) # ------- 目标函数与求解 ------- purchase_cost c_grid * cp.sum(cp.pos(P_grid)) # 只对购电部分计费 sell_income c_grid_sell * cp.sum(cp.neg(P_grid)) # 售电收入为负 objective c_g * cp.sum(P_g) purchase_cost - sell_income c_shed * cp.sum(P_shed) objective cp.Minimize(objective) prob cp.Problem(objective, constraints) prob.solve(solvercp.ECOS, verboseFalse)这段代码里有两个地方值得特别留意。第一个是购售电成本的处理我用了cp.pos和cp.neg把购电和售电拆开计费因为现实中购电价和上网电价往往不同不拆分就无法准确体现峰谷电价套利逻辑。第二个是SOC递推约束里 P_grid 的正负方向定义这决定了功率平衡方程里到底哪一项是流入哪一项是流出团队协作时最好在代码头部用注释统一约定否则看代码的人很容易把正负号搞反。3.3 滚动调度主循环每次只执行第一步MPC与常规优化最大的不同在于滚动执行主循环的处理模式很固定先用当前时刻状态构造预测序列求解一次优化取第一步控制量执行然后更新状态变量时间前移一步重新构造预测序列再次求解。我项目里的主循环是这样组织的# 总仿真时长为48小时 T_total 48 exec_P_g np.zeros(T_total) exec_P_bat np.zeros(T_total) exec_P_grid np.zeros(T_total) exec_SOC np.zeros(T_total1) exec_SOC[0] SOC_0 for k in range(T_total): # 实际预测模块会按k不断刷新这里用固定数据模拟 prob.solve(solvercp.ECOS, verboseFalse) # 从解中提取当前时刻的控制量 exec_P_g[k] P_g.value[0] exec_P_bat[k] P_bat.value[0] exec_P_grid[k] P_grid.value[0] # 执行后更新实际SOC这里更精确的设计会加上量测噪声 exec_SOC[k1] exec_SOC[k] - exec_P_bat[k] * dt / E_bat # 关键把下一次求解状态更新为当前实际状态 SOC_0 exec_SOC[k1] # 让预测序列整体前移一格 P_load np.roll(P_load, -1) P_pv np.roll(P_pv, -1) P_load[-1] P_load[-2] P_pv[-1] P_pv[-2]请注意这里SOC.value[0]其实没有被直接用来更新执行SOC段我刻意用了“执行后按实际功率递推”的做法目的是模拟测量值。虽然这个版本里没有加预测误差但结构上已经预留了误差注入的位置实测对比预测SOC与实际SOC时看到的差距完全可以作为预测误差对调度经济性影响的衡量指标。跑完循环后把执行功率用matplotlib画出来就能清楚看到储能如何避开高价时段、机组如何在爬坡约束下平滑跟踪负荷曲线。4. 参数整定与高频问题排查手册代码跑通离“好用”还有一段距离实际调试中大部分时间都花在参数整定和解决不可行问题上。按我的经验以下几个问题出现的频率最高解决方法也最值得提前掌握。4.1 预测时域与成本系数的整定经验预测时域N的整定本质是在“看得够远”和“算得准”之间找平衡。N太小比如只有4个时段MPC变成短视策略储能会在低谷电价时不敢充电因为看不到后面第6个时段的高价售电机会N太大比如取96个15分钟的时段求解矩阵规模增大更重要的是远期预测误差会误导决策储能可能为了一个根本不会到来的高价时段预留容量。我项目里最终使用24小时窗口和一个小时步长结果曲线比较平滑。成本系数方面最关键的教训是切负荷惩罚不能给得太小我一开始设了1.5倍电价结果优化器为了省机组燃料直接切负荷完全不满足工程安全预期后来改成3倍以上才让“保供电”成为硬约束之外的软保障。4.2 求解器报infeasible或unbounded的三大元凶我在调试过程中遇到过三次比较典型的不可行问题都是人为原因造成的。第一个是SOC初始值与约束冲突比如初始SOC设了0.95但代码同时限定了SOC最大只能到0.9第一步就会出现矛盾解决方法是让初始值始终落在可行域内部。第二个是充放电变量定义与效率约束相互矛盾特别是你想精细建模效率损耗时充电功率正负方向一旦写反递推方程会让SOC越跑越离谱。第三个是功率平衡里缺少松弛变量当光伏预测为0且负荷猛增、机组爬坡又赶不上时唯一的解就是切负荷如果你没给这个出口问题直接不可解。所以我把P_shed设置成始终可用、只在目标函数里惩罚而非硬禁这是工程上非常推荐的鲁棒化做法。4.3 预测误差如何影响MPC的表现有些人会误以为MPC不需要预测模型这个理解有偏差。MPC本质上是用“不断更新的预测反馈校正”来降低对预测精确度的依赖但如果预测数据本身系统性偏差很大比如光伏预测持续偏高50%再好的反馈机制也救不回来。我实验中的经验是给MPC加一个“执行偏差补偿项”在每个滚动周期开始前把上一时段实际功率与预测值的偏差按一定比例叠加到本时段的预测序列上。这个做法简单且非常有效类似控制理论里的反馈修正项能让调度结果在面对持续云层遮挡时依然稳定运行。4.4 常见问题速查表故障现象可能原因处理办法求解器报 InfeasibleSOC初始值越界/约束自相矛盾检查初始SOC逐个注释约束定位冲突求解器报 Unbounded目标函数缺少成本项或变量无界加装机组的上下限约束检查功率平衡储能出力反复抖动充放电效率建模不当或步长过短检查SOC递推正负号拉长步长测试功率曲线高频振荡爬坡约束缺失或N过小加机组爬坡限制增大预测时域求解耗时明显增大引入整数变量或N过大暂时改用连续模型减小N换OSQP求解器切负荷频繁发生切负荷惩罚过小提高c_shed到电价的3倍以上5. 扩展方向与个人实操体会这套MPC框架做出来后后续还能往几个方向延展几乎不需要改动主体结构。第一个是多目标扩展在目标函数里增加碳排放项或储能寿命损失项用权重系数平衡经济性与环保性。第二个是微电网群或多园区互动把单一微网模型复制成多个子微网在联络线约束处加总线互联约束就能做多主体分布式协调优化。第三个是引入预测算法把numpy模拟的固定预测序列替换成基于LSTM或随机森林的负荷和光伏预测模型把预测模块和MPC模块解耦后对比不同预测精度下的调度成本差非常适合写论文用。然后说点实际的个人体会。这个项目做完之后我对MPC最深的认知是MPC的难点从来不在求解算法而在建模的取舍。你要知道哪些约束是物理上绝对不能碰的底线哪些约束是可以用惩罚项软化的经济性考量。储能效率要不要展开成混合整数、机组启停要不要引入0-1变量、爬坡约束要不要转成逐步限制这些决定了解的实际计算量和工程可执行性。新手第一次做我的建议是先把线性版本跑通让基础调度逻辑在图上运转起来再逐步叠加复杂度而不是一步到位。最后分享一个调试小技巧把MPC每一步的解都保存下来画成曲线后盯着异常点检查。很多时候SOC曲线里面藏着的陡升陡降比求解器的报错信息更能告诉你模型哪里写错了。把这一步做到位你的MPC调度项目就真正从“能算”进入了“能用”的状态。