手头这个复现项目推完上篇的预配置之后很多同行问得最多的就是下篇的动态调度到底怎么接上。说实话预配置和动态调度这两步看着像两个独立优化问题实际在实现层面要趟的坑一点都不少。这篇就专门把下篇的MPS动态调度拆开讲从数学模型到Matlab实现细节再到仿真踩坑实录。先说清楚它能做什么给定配电网的故障场景和MPS的初始预置位置动态调度模块负责在恢复周期内安排每台移动应急电源的移动路径、并网时机和输出功率让重要负荷的失电损失尽可能小。适合正在复现韧性提升类论文、准备做应急调度方向研究或者想把手里的Cplex/Gurobi求解器和配电网潮流模型练熟的研究生和工程师参考。1. 项目拆解为什么动态调度这一步必不可少1.1 配电网韧性研究的整体思路先简单回顾一下背景。配电网韧性指的是电网抵御极端事件并从故障中恢复的能力。台风、冰灾这类极端天气一来配电线路成片倒杆断线传统抢修流程是故障排查—人工修复—逐户复电恢复周期以小时甚至天计。这些年学术界和工程界都在想一件事能不能在灾害来临之前就把可移动的电源设备放在关键位置等故障发生后让这些移动电源跑起来在大电网修复完成之前先行恢复一部分负荷的供电。这个思想对应了两类决策问题灾前的预配置和灾后的动态调度。预配置解决的是提前把MPS放在哪里的问题面对的是不确定性场景通常用随机规划或鲁棒优化处理。动态调度解决的是故障已经发生MPS该怎么走、怎么出力的问题此时网络拓扑和故障情况基本明确优化目标变成在有限的时间窗口内最大化恢复效果。两个问题放在一起才是完整闭环预配置的输出作为动态调度的输入约束条件动态调度的结果反过来验证预配置方案的质量。1.2 动态调度与预配置的分工逻辑我在第一次做这类项目时犯过一个大错误试图把预配置和动态调度合并成一个确定性优化问题直接求解。结果是变量爆炸、求解器直接卡死。原理上这是两个完全不同的决策阶段——预配置在灾前、信息集是历史数据与灾害预测动态调度在灾后、信息集是实际故障位置与状态估计。它们的约束结构和目标权重也不一样。所以在复现论文时一定要把两个阶段拆开用两个脚本或两个模块分别实现通过文件或数据结构传递结果。下篇的动态调度模块输入是故障后网络拓扑、节点负荷曲线、预配置阶段给出的MPS初始位置清单、道路网络的通行时间矩阵。输出是每台MPS在恢复周期内每个时段的停靠节点、并网时段和注入功率、各节点的负荷削减量。这层设计还有一个实际好处便于调参和对比实验。比如想测试预配置位置更靠近负荷中心还是更靠近网络边缘只需要改预配置模块的输出文件动态调度模块不需要动一行代码。这是所有可复现代码都应该具备的模块化意识。1.3 这篇复现代码的目标读者与应用场景这套代码不是学术PPT式的示意实现而是能实打实跑出结果的方案。我复现时采用的算例是IEEE 33节点配电系统配3台MPS和24小时恢复周期时间步长取1小时。如果是硕士论文或者期刊复现这个规模刚好合适如果要做更大规模如IEEE 123节点的研究后面会讲到怎么扩展。目标读者我分了三类做韧性方向研究的研究生——需要理解模型如何转成代码方便改造自己的算法电力系统工程师——想快速评估应急移动电源配置在实际网络中的效果Matlab建模爱好者——想学习Yalmip与Cplex/Gurobi配合求解大规模MILP的工程实现。这篇文章会覆盖完整的技术路径但不做纸面上的原理堆砌每一步都对应代码里的实际写法。2. 动态调度数学模型从物理逻辑到代数约束2.1 目标函数怎么设才合理动态调度问题最常见的建模目标是最小化整个恢复周期内所有节点的加权负荷削减总量。直接用负荷量作为权重是最省事的做法但论文中往往会对重要负荷医院、通信基站、水厂额外提高权重系数。这里的目标函数写成[ \min \sum_{t \in T} \sum_{i \in N} w_i \cdot P_{i,t}^{shed} \cdot \Delta t ]其中(w_i)是节点i的负荷优先级权重(P_{i,t}^{shed})是时段t节点i的负荷削减量。如果考虑移动电源的移动成本或启停成本可以在此基础上加入相应的惩罚项但要特别注意成本和削减量之间的量纲匹配。工程上建议把移动成本设成相对负荷削减惩罚的一个较小比例否则求解器可能为了省一点移动费用而牺牲大量负荷恢复这在物理上不合理。我测试时用的权重方案是普通负荷权重1.0一级负荷权重10.0在结果中能明显看到求解器优先保一级负荷。追加的移动成本每台MPS每次迁移设为固定值(C_{move}150)相比单时段一个大节点的失电惩罚假设平均负荷200kW×1h×权重要小一个数量级这样目标函数的主次才不会倒挂。2.2 潮流约束用DistFlow加锥松弛配电网是放射状结构DistFlow模型是经典选择。每条支路( (i,j) )满足功率平衡和电压降落关系[ \begin{aligned} P_{j,t} \sum_{k \in C(j)} P_{jk,t} r_{ij} I_{ij,t}^2 \ Q_{j,t} \sum_{k \in C(j)} Q_{jk,t} x_{ij} I_{ij,t}^2 \ V_{j,t}^2 V_{i,t}^2 2(r_{ij}P_{ij,t} x_{ij}Q_{ij,t}) (r_{ij}^2x_{ij}^2)I_{ij,t}^2 \end{aligned} ]这里的非线性主要来自电流平方项和乘积项。论文中常用的处理是引入辅助变量并做二阶锥松弛SOCP。在Yalmip中这一步可以很优雅地表达成锥约束。配电网的电压幅值变化范围通常很小0.95~1.05pu实际复现时可以用电压幅值的线性化简化但SCI一区论文多数还是用SOCP以保证精度和凸性。关于潮流约束的线性化有个经验如果算例规模在100节点以上且调度周期超过24小时严格SOCP会让求解时间呈指数上升。此时可以考虑交流潮流对电压幅值不敏感的部分改成线性化模型先跑通再考虑做精确约束这是复现论文时最实战的权衡。2.3 MPS时空移动约束整个模型最容易被写崩的部分MPS动态调度的核心难点不是潮流而是移动性。一台MPS在时刻t只能在一个位置这是唯一性约束从一个节点到另一个节点花费的时间不能小于道路通行时间这是连续性约束到达并网节点之后才能开始出力这是能力约束。三者组合起来才是完整的MPS行为描述。唯一性约束的代数形式[ \sum_{i \in N_{MP}} x_{m,i,t} 1,\quad \forall m,t ]其中(x_{m,i,t})是0-1变量表示MPS (m)在时段t是否停在节点i(N_{MP})是所有可以停靠的候选节点集合。连续性约束依赖于预定义的出行时间矩阵(D),如果MPS在t时刻在节点i、t1时刻在节点j且i≠j必须满足(D_{ij} \le 1)以调度步长1小时为基准。这类约束可以通过线性不等式组实现但要注意大M法系数选得不好会导致数值问题。还有一个容易忽略的约束同一节点在同一时段允许停靠的MPS台数上限。这个上限通常由节点的物理容量决定论文里一般设为1或2。如果不设这个约束所有MPS挤在同一个重要负荷节点模型从数学上可行但从工程上完全不合理。我复现时把这个容量写成了一个参数方便测试不同物理场景。移动时序上还需要设置MPS从预配置初始位置出发的时间。调度周期开始时MPS已经在初始位置对应t1时(x_{m,i,1}1)其中i等于预配置给出的初始节点。这个初值看起来简单但如果没有正确传入模块会导致后面所有移动约束错乱。我自己就犯过把初始位置矢量和候选节点编号未对齐的错结果求解器报不可行。2.4 预配置结果如何传入动态调度两阶段模型的接口设计要明确哪些量是预配置的决策变量结果、哪些是动态调度的决策变量。预配置输出的应该是每台MPS的初始停靠节点一组离散值以及可用台数。动态调度把这些值当作固定参数读入防止它改变初始位置。在代码层面我用一个JSON格式的结果文件在模块间传递包含每台MPS的编号、类型容量MW、预置节点编号。动态调度模块启动时先读文件再用这些值初始化约束。这个方法的好处是可视化和调试非常方便随时可以人工修改预配置结果来测试动态调度的鲁棒性。3. Matlab代码实现细节从建模到求解3.1 技术栈的选择依据这个项目用的是MatlabYalmipCplex的组合。为什么这么选第一个原因是建模效率Yalmip允许你几乎按照数学公式的原样写约束不需要手动把每个矩阵展开成标准形式这对涉及大量时空变量的配网调度问题来说节省的工时是巨大的。第二个原因是调试Matlab的工作区可以随时查看每个变量的结构出问题的时候能很快定位是哪个维度没对齐。Cplex或者Gurobi作为底层求解器处理这种几千变量级别的MILP非常稳。如果只用Matlab自带的intlinprog在30节点不超24时段的场景可能也能跑但在33节点24时段3台MPS的规模下求解时间差距能达到十倍以上。我自己的测试中Gurobi在默认参数下30-60秒内能收敛到1%MIP gapintlinprog五分钟未必能找到可行解。个人建议Matlab可选的求解器中Gurobi的许可证对学生比较友好Cplex则更适合已经在用IBM工具链的团队。两个求解器在Yalmip下的接口写法几乎一致切换成本很小所以可以先装一个跑通再加另一个对比。3.2 代码目录结构与数据接口复现项目最好不要把所有代码塞进一个主脚本里。我采用的分层结构是这样的MPS_DynamicScheduling/ ├── data/ # 输入数据节点参数、线路参数、预配置结果 ├── src/ │ ├── load_data.m # 数据加载与预处理 │ ├── build_network.m # 构建DistFlow模型和网络拓扑 │ ├── build_mps_model.m # MPS移动与出力约束 │ └── solve_schedule.m # 主求解函数 ├── results/ │ ├── mps_trajectory.xlsx # MPS路线表 │ ├── load_curve.xlsx # 恢复负荷曲线 │ └── log_solver.txt # 求解日志 └── main_run.m # 主入口脚本数据接口设计中我特别想强调一点所有输入数据统一组织成结构体不要散落在一堆零散的矩阵里。我的load_data.m返回data结构体包括nodes含节点类型、负荷曲线索引、branches、travel_time_matrix、mps_init_position等字段。这样做的好处是build_mps_model.m中可以按字段名访问代码可读性大幅提升也方便替换不同算例。3.3 核心建模代码手把手写约束建模过程最核心的是变量定义和约束构建。下面给出关键代码片段基于Yalmip兼容写法%% 决策变量定义 % x_mps(m, i, t) 表示MPS m在时段t是否停靠在节点i x_mps binvar(MPS_num, N_mp_nodes, T, full); % p_mps(m, i, t) 表示MPS m在时段t在节点i的注入有功功率 p_mps sdpvar(MPS_num, N_mp_nodes, T, full); % p_shed(i, t) 节点i在时段t的负荷削减量 p_shed sdpvar(N_load, T, full); %% MPS唯一性约束 Constraints []; for m 1:MPS_num for t 1:T Constraints [Constraints, sum(x_mps(m, :, t)) 1]; end end注意我用了sdpvar和binvar而不是直接调用intlinprog——Yalmip会自动把模型转换成求解器需要的标准形式。变量维度必须和数据维度严格对齐N_mp_nodes不一定等于系统节点数N只有候选停靠节点才可行。这里如果没对齐后面所有约束维度都会报错。MPS出力约束要满足只有停在节点才能出力的逻辑。假设MPS的额定容量为Cap(m)这个约束可以写成for m 1:MPS_num for t 1:T % 方式一使用幂等逻辑 Constraints [Constraints, p_mps(m, :, t) Cap(m) * reshape(x_mps(m, :, t), 1, N_mp_nodes)]; Constraints [Constraints, p_mps(m, :, t) 0]; end end这里利用了大M思想把二进制变量乘上容量上限作为连续变量的上界。要注意的是MPS在移动途中的出力应该为0它们只有到达目标节点才能注入有功。上面这种写法没有完全杜绝移动过程中出力的逻辑漏洞因为x_mps的状态只代表了停靠在某节点还需要额外判断MPS是否处于到岗状态。更严谨的做法是单独定义一个arrive状态变量或者把移动过程中的时段强制p_mps0。3.4 移动约束和出行时间矩阵出行时间矩阵是MPS调度建模里的隐形主角。我们在数据里维护一个Tmax矩阵表示MPS从节点i移动到节点j需要几个调度时段。比如Tmax(i,j)2意思是MPS从i出发到j需要在路上花2小时这2小时内它不能在任何节点出力。用线性约束表达连续的移动逻辑非常绕。比较常用的写法是如果MPS在t时刻位于i节点那么tTmax(i,j)时刻之前它不能出现在j节点。这个逻辑可以通过一组不等式组实现for m 1:MPS_num for t 1:T for i 1:N_mp_nodes for j 1:N_mp_nodes if i ~ j Tmax(i,j) 0 in_time t Tmax(i,j); if in_time T Constraints [Constraints, ... x_mps(m, i, t) x_mps(m, j, in_time) 1]; end end end end end end循环套循环实测在小规模没问题但在大规模算例中约束数量会爆。优化思路是预计算一个转移禁止列表只对Tmax≤某个阈值的(i,j)对生成约束。我在实际项目中把这种生成约束前先过滤的做法作为默认策略求解器压力小很多。3.5 求解器配置与结果输出Cplex和Gurobi的求解参数可以通过Yalmip的sdpsettings进行配置options sdpsettings(solver, gurobi, verbose, 2); options.gurobi.MIPGap 0.01; % 1%最优间隙 options.gurobi.TimeLimit 300; % 最长求解时间 sol optimize(Constraints, Objective, options); if sol.problem 0 disp(求解成功); else disp([求解失败: sol.info]); end求解器参数配置是复现中很容易被忽视的环节。默认gap往往设置得过小比如0.0001在大规模调度问题中要跑到这个精度会耗时很久。我的经验是把MIPGap设置在0.5%~2%之间对配电网调度决策完全够用求解时间通常能缩短一半。论文表格里的目标值写的是这个gap下的次优解也没关系实验部分注明参数即可。结果输出建议直接用writetable导出到xlsx结构上涵盖三张表MPS轨迹表包含时间、节点编号、出力功率、节点负荷削减表、目标函数值与求解时间记录。这样后面做对比实验或者画图直接读取Excel就行不用反复重跑仿真。4. 算例仿真与结果分析4.1 IEEE 33节点算例配置算例采用标准IEEE 33节点系统基准电压12.66kV总负荷约3.7MW。故障场景设为台风导致线路5-6、8-9和14-15三条支路同时断开故障开始于第4小时持续到第20小时。预配置阶段给出的3台MPS初始位置分别是节点8、节点18和节点30容量分别为0.5MW、1.0MW和0.5MW。Travel time矩阵按照道路距离折算节点间通行时间为1~3个时段不等。调度周期设为24小时时间步长1小时。目标函数权重按负荷类型区分普通用户权重1商业负荷权重2关键负荷医院类权重5。4.2 动态调度结果核心指标先看整体指标。经过求解器计算最优目标值为5476.2加权削减量·h对应的供电恢复率为71.4%。3台MPS中1MW大容量MPS优先被调度到节点18附近的负荷集中区域该区域负荷量约0.45MW接续供电后瞬时恢复了当地停电负荷的近一半。0.5MW的两台MPS分别支援了节点8侧和节点30侧的单条馈线负荷。调度路径清楚地展示了论文里逐次投放、随修随走的思想MPS并不是在故障开始时一股脑全部投到各自预置位置而是根据线路修复的动态进程调整停靠位置。例如1MW的MPS在前4个时段一直位于节点18为周边重要用户供电第10时段感知到节点8一侧的部分负荷恢复之后才迁移到节点21去支援另一条线路。这种动态调整带来的增量效益在第4章表格里才能直观看到。4.3 静态vs动态调度带来的增益为了说明动态调度的价值我做了一组对比实验把所有MPS固定在预配置位置不动静态方案与动态调度方案对比。结果非常有意思静态方案的加权负荷削减量为6217.8相比动态方案的5476.2高出13.5%。这13.5%就是移动带来的增益。在有2台以上MPS、故障点分散的复杂场景下这个差距会进一步拉大。进一步拆解原因静态方案中MPS只能覆盖所放置节点附近的负荷而动态调度允许MPS在不同时段服务多个负荷块。本质上移动MPS在时间维度复用了同一个电源容量这个增益本质上是时间复用带来的效率提升。这部分结论建议写论文时重点突出因为它直接说明了移动调度的不可替代性。4.4 MPS台数与容量灵敏度分析我还测试了不同MPS配置下动态调度的表现。把台数从2台提升到3台恢复率从67.2%提升到71.4%再增加到4台恢复率只提升到73.1%边际效益明显递减。这说明在33节点算例中3台MPS差不多是个经济性拐点。容量方面把1MW的MPS替换成1.5MW恢复率增加了2.3%但目标函数中负荷削减量的边际减少值其实低于成本增加这也是预配置阶段要权衡的问题。这组灵敏度分析有个实际操作价值如果你手头只有X台MPS不要盲目平均分配在不同位置而是观察动态调度结果中哪些节点被反复访问、哪些节点的功率缺口最大这些节点就是预配置应重点关注的候选位置。这是从动态调度反过来指导预配置的有效手段。5. 常见问题与排查技巧实录5.1 求解器报错不可行的排查最常踩的坑是求解器返回infeasible problem。这个错误出现的直接原因是约束集合互相矛盾但具体是哪组约束冲突需要手动定位。我总结了一套三步排查法先用注释的方式分组禁用约束比如先只加潮流约束求解再加MPS唯一性约束逐步增加直到找出冲突点然后检查预配置传递的初始位置是否包含在候选节点集合中如果初始节点编号不在N_mp_nodes里唯一性约束会直接不可行最后检查出行时间矩阵的连通性如果某个MPS在t1位于节点i而它在t2需要出现在节点j但Tmax(i,j)3必然不可行。这个方法在实际项目中能解决95%的infeasible问题。剩下5%可能是数值问题导致的伪不可行这种情况把某几条约束的容差放宽即可解决。5.2 求解时间不可接受的优化手段动态调度MILP求解时间长有两个主要原因一是二进制变量太多二是约束里的系数尺度差别太大。解决变量多的问题我通常先做两项预处理排除不可能在恢复周期内到达的节点对排除负荷高峰时段之外几乎没有恢复必要的节点。在这些排除约束下x_mps的候选(i,t)组合会被大幅压缩。MIPGap调整是最直接的杠杆。在我测试的33节点案例中MIPGap从0.0005调到0.01时求解时间从近5分钟降到70秒左右而目标值只恶化了0.6%。这在工程中完全可接受。还有一招是用启发式初始解——人为指定一条合理的MPS方案赋给x_mps作为初始可行解Gurobi和Cplex都会极大受益求解时间能再优化20%~30%。5.3 结果不合理怎么定位有时候求解器成功收敛但结果怪怪的比如某台MPS频繁在两个节点之间来回迁移或者大容量MPS在一个时段只输出很小的功率。出现这类问题优先检查目标函数权重设置和MPS移动成本的相对大小。如果移动成本太低模型会倾向于让MPS频繁挪动寻找一点点负荷增量的收益这在目标函数上确实最优但在物理上是荒谬的。解决方案是把移动成本调到合适范围或者在约束中对同一节点重复到访实施次数限制。另一种情况是MPS的输出功率远低于容量看起来像闲置。此时多数不是模型的问题而是潮流约束导致接入点的电压或者线路容量限制了注入功率。检查该节点的线路容量约束是否被激活必要时可以增加一条无功补偿支路或调整MPS接入点。5.4 数值问题大M法系数选择与量纲归一化配电网模型中变量数值范围跨度很大电压幅值在百伏量级电流平方项和功率在兆瓦量级如果直接用原始单位做计算求解器会遇到明显的数值问题。一个直接教训约束中涉及的大M系数不能随手写100000太大容易引起精度问题太小又会错误修剪可行域。我的做法是先对系统中的功率和电压做标幺化处理把电压、功率都归一到pu量级这时候所有大M系数都在10~100的范围问题规模小很多求解数值也稳定得多。另外Yalmip会把带幂次的变量自动转换成双线性项这也是数值问题来源之一。个人经验是在构建约束前先手动整理成线性或二次锥形式不仅能加快求解还便于后期排查。6. 写在最后从论文复现到工程落地的三点体会这三个月的复现过程让我对移动电源调度有了更深的理解。第一预配置和动态调度两个问题确实必须拆开写但要保证接口数据结构设计了非常好的扩展性。日后想加入抢修队伍协同、移动储能或光伏联动只需要在现有数据结构里加字段不需要把整个代码推倒重来。第二论文模型写得再漂亮落地到求解器总要面对离散时间粒度的问题。一小时一个时段做24h周期已经相对粗糙但时间步长细化到半小时变量数量就翻一倍很多论文为了可解性不得不在精度和效率之间做折中。做复现时一定要敢于接受论文中次优解的现实并把这个gap明明白白写进实验分析部分。第三也是最重要的一点结果可视化是判断模型行为是否正确的第一道关卡。我强烈建议把每台MPS的轨迹画成时间-空间图用色块标注出力功率。一眼就能看出模块是否存在移动途中出力、反复横跳这类模型漏洞。这些工程细节比优化算法本身更能决定你能否把一个复现项目真正用起来。如果你想继续扩展这个项目可以考虑在动态调度模块中加入实时信息更新的滚动时域优化框架或者把MPS的充电行为也纳入考虑允许它在部分节点从电网取电补能。无论朝哪个方向走都建议先把今天说的这套数据接口和模块结构跑熟悉了再做加法。