1. 为什么先研究MPS预配置而不是等故障后再调度去年我在复现某SCI一区的配电网韧性提升论文时最难啃的其实不是后半程的动态调度而是前面这个看似不起眼的环节——应急移动电源MPSMobile Power Source的预配置。很多刚接触这个方向的人会把注意力放在故障发生后“怎么把电源车派到最需要的地方”但真正决定调度上限的恰恰是故障发生前你把这些移动电源放在了哪里、放了多少台、容量够不够。配电网韧性这个词翻译成大白话就是电网在经历台风、冰灾、暴雨这类极端扰动时能不能少停电、停完电能尽快恢复。传统规划思维关注的是“平时经济性最优”而韧性研究关注的是“极端场景下资源是不是在最该在的位置”。MPS预配置就是这个思路的落地产物在灾害预警发布后、实际故障还没发生前把移动电源提前布置到关键节点附近。我当时复现这篇论文时先把预配置和动态调度拆开看。预配置解决的是“哪台移动电源在哪个候选点待命”动态调度解决的则是“故障发生后如何根据实时网架变化把电源再移动到目标位置”。这两个问题必须放在同一个框架里建模但在求解和代码结构上可以分成两个阶段。这篇文章只写预配置也就是论文里常说的第一阶段决策动态调度部分我后面会单独出一篇。1.1 为什么预配置能显著提升韧性道理其实很朴素。极端天气下交通容易中断维修人员和应急设备进入受灾区域的时间窗口很短。如果等故障已经发生、负荷已经丢了再派电源车路上要花几个小时甚至更久这段时间内的失负荷是白损失的。相反如果在灾害预警阶段就把MPS放到高风险负荷点附近故障隔离后就可以快速接入恢复供电。这里有个容易被忽略的点预配置不只是“提前停车”它是在信息不完备的前提下做的资源配置决策。因为灾害路径、故障点、负荷损失大小都有不确定性预配置方案不能只针对某一个确定的故障场景而要在一组可能的场景上综合权衡。这本质上是一个随机优化问题而不是一个传统的确定性选址问题。1.2 预配置究竟要回答哪三个问题我在写代码前先把问题抽象成三个问题第一配置多少台MPS预算有限移动电源数量有限不可能每个节点都放一台。数量太少会在多场景同时故障时不够用数量太多又会造成资源浪费。第二配置在哪些候选节点候选节点通常不是所有变电站而是有接入条件、离高负荷区域近、并且在地理位置上能兼顾多个可能故障区域的位置。第三配置容量多大不同型号的移动电源额定功率不同接入了这个电源能带多大负荷能持续供电多长时间这些都要在预配置阶段考虑。如果你把这三个问题直接写进代码会发现它们不是相互独立的。比如多配一台大容量电源可能意味着少配一台中容量的电源放错了节点则可能导致某些场景下所有电源都帮不上忙。这就是为什么预配置需要用优化模型来做不能靠人工经验拍脑袋。1.3 预配置和动态调度怎么分工有些读者会问反正故障后调度还能移动这些电源预配置是不是多此一举答案不是。动态调度当然可以把电源从A点挪到B点但移动需要时间而且路线可能因为道路中断、网架解列而变得不可行。预配置的意义在于给动态调度一个更好的起点。在我的复现框架里这两者属于典型的两阶段随机优化第一阶段决定预配置位置第二阶段针对每个故障场景决定实际调度路径和供电方案。第一阶段决策要在所有场景发生前统一确定第二阶段决策可以随场景不同而变化。这种“现在决策未来调整”的结构正是预配置问题的核心。2. 预配置问题的数学建模目标、约束与不确定性复现这篇论文时我踩过的第一个坑就是“怎么把预配置描述成数学问题”。刚开始我只建了一个优化目标“失负荷最小”结果跑出来的方案完全不合理。后来才明白预配置模型的科学性不在于单个公式有多复杂而在于它是否真正抓住了“决策—不确定—后悔值”之间的关系。2.1 两阶段随机优化的整体框架标准的两阶段随机规划可以写成下面这种紧凑形式min C(x) Σ_s π_s · Q(x, ξ_s) s.t. A x ≤ b, x ∈ {0,1}其中x是第一阶段决策变量代表每台MPS预配置到哪个候选节点C(x)是预配置的直接成本π_s是第s个灾害场景的概率Q(x, ξ_s)是在给定预配置方案x和场景ξ_s下第二阶段动态调度问题的最优值通常表示为该场景下的最小失负荷。第二阶段问题本身又是一个优化问题Q(x, ξ_s) min Σ_t Σ_i w_i · ls_{i,t}(ξ_s) s.t. 关于MPS移动、接入、供电、潮流、孤岛等约束这里ls_{i,t}是节点i在时段t的失负荷量w_i是负荷权重。为什么要把两个阶段写成嵌套形式因为预配置方案会直接影响第二阶段能恢复多少负荷如果把第二阶段忽略掉预配置就退化成单纯的地理选址失去了韧性含义。2.2 第一阶段变量和约束我实际建模时用的变量定义如下K可用的MPS台数N候选预配置节点数x_{k,i}0-1变量表示第k台MPS是否预配置到候选节点iC_k第k台MPS的额定功率单位kWP_i^max候选节点i可接入的容量上限受接入开关和变压器限制第一阶段约束主要有几个每台MPS最多只能预配置到一个节点对任意kΣ_i x_{k,i} ≤ 1每个候选节点接入的MPS总容量不能超过该节点上限对任意iΣ_k C_k · x_{k,i} ≤ P_i^max如果候选节点没有停车场或接入条件则对应的x_{k,i}必须为0这通常通过候选节点集合限制实现这里我要特别提醒一点第一阶段的约束千万不要顺手写成“每台MPS都必须预配置出去”。在部分场景中把某台MPS留在基地作为后备反而是最优的。因为一旦预配置到错误的位置第二阶段即使知道正确位置也无法瞬移过去留作后备至少还能根据实际情况再决定去向。2.3 第二阶段模型的关键工程简化第二阶段动态调度涉及的内容很多我在“上篇”里不展开全貌但必须说明预配置的Q(x, ξ_s)是怎么和它挂钩的。第二阶段在给定场景下需要决定MPS在哪些时段移动到哪个节点、接入后给哪些负荷供电、是否形成孤岛运行。为了保证预配置模型可求解我采用了几个工程简化用DistFlow线性化潮流代替完整交流潮流误差在千伏级配网里可以接受把MPS移动时间离散成“故障后前几个时段内不能接入”的约束而不是建立完整的交通网络模型负荷按重要程度分两级权重不同目标函数用加权失负荷量而不是简单加总。这些简化不是论文作者拍脑袋定的而是数学规划和配电网工程之间的常规折中。完整非线性潮流会让两阶段模型变成大规模MINLP以我当时的算力基本跑不动。2.4 不确定性场景怎么生成很多初学者会忽略场景生成这一步直接用几组手动画出来的故障场景这样结果说服力很差。我在复现时参考了论文的做法基于历史台风路径和线路故障率用蒙特卡洛抽样生成候选故障线路集合再结合负荷波动生成每个场景的节点负荷系数。生成的原始场景可能很多比如上千个直接都放进模型会非常慢。我的做法是先做场景削减保留概率接近、后果特征差异较大的30到50个代表性场景。场景削减可以用聚类也可以用概率距离迭代法我习惯用聚类因为实现起来简单效果也够用。3. Matlab实现思路从数据准备到求解器调用既然标题里写了Matlab代码实现我就把代码层面的思路完整拆一遍。我不打算给一个可以直接复制运行的长脚本因为不同人手里的算例数据结构不一样直接套代码反而容易出错。我更建议你按下面这个结构自己组织代码。3.1 建议的代码目录结构MPS_Preconfig/ main_preconfig.m % 主脚本 data_case33.m % 配电网参数和MPS参数 scenario_generator.m % 场景生成与削减 build_two_stage_model.m % 构建两阶段优化模型 post_process.m % 结果分析主脚本只负责调用不写具体模型这样后续改参数、换算例都很方便。data_case33.m里我放的是33节点配电网参数、线路故障概率、负荷权重、MPS型号参数。scenario_generator.m输出一个结构体数组每个元素包含故障线路集合和修正后的节点负荷。3.2 第一阶段决策变量怎么定义在MATLAB里我使用Optimization Toolbox的optimvar来创建决策变量。核心代码大概是nUnit 3; % MPS台数 nNode 5; % 候选节点数 X optimvar(X, nUnit, nNode, ... Type, integer, LowerBound, 0, UpperBound, 1);这段代码创建了nUnit乘nNode的0-1变量矩阵X(k,i)1表示第k台MPS预配置到候选节点i。接下来定义问题对象prob optimproblem(ObjectiveSense, minimize);如果你用的是较老版本的Matlab也可以直接用intlinprog只是需要把变量和系数手动组合成矩阵麻烦一些。我建议能用optimproblem就用它可读性好很多。3.3 约束和目标组装示例第一阶段约束的代码比较直观% 每台MPS最多预配置到一个候选节点 prob.Constraints.uniquePosition sum(X, 2) 1; % 每个候选节点接入容量不能越限 % unitCap是nUnit×1列向量nodeCap是nNode×1列向量 capacityAtNode sum(X .* unitCap, 1); % 转成nNode×1 prob.Constraints.nodeCap capacityAtNode nodeCap;这里有个很容易踩的坑X .* unitCap需要unitCap是列向量且X是nUnit×nNode矩阵这样MATLAB会自动做广播得到每个MPS在每个节点的接入容量矩阵。如果你把维度搞错了会报矩阵维度不一致或者更隐蔽地算出一堆错误的零。第二阶段目标项的组装要在场景循环里完成示意如下objTerms zeros(nScenario, 1); for s 1:nScenario % 根据预配置变量X和场景scen(s)构造并求解第二阶段的线性化约束 % 把该场景最小失负荷存到objTerms(s) end prob.Objective sum(scenProb .* objTerms);这个循环里要用到第二阶段变量比如Y表示各时段MPS在哪接入。更精确的写法需要定义带场景维度的第二阶段变量例如Y optimvar(Y, [nUnit, nNode, nScenario, nPeriod], ... Type, integer, LowerBound, 0, UpperBound, 1);但这样变量维度会非常大直接写进去可能内存爆炸。我的经验是先用小规模算例把逻辑跑通再决定要不要用延迟约束或者分解算法。3.4 求解和结果输出求解代码很简单options optimoptions(intlinprog, Display, iter, MaxTime, 600); [sol, fval] solve(prob, Options, options);MaxTime设成600秒是防止极端情况下一直跑不完。求解结束后用sol.X查看每台MPS的预配置节点用fval查看目标值。我一般还会把候选节点的接入容量剩余率打印出来用来判断方案是否把容量用得太满太满往往意味着鲁棒性不足。4. 算例设计、结果解读与方案评价论文复现最怕的是“代码跑通了但结果没法解释”。我在跑完第一阶段模型后把算例结果和基准方案做了对比发现了很多有意思的规律这里用一套模拟算例数据来说明数字本身不是重点重点是解读方法。4.1 测试系统与参数我以常见的33节点配电网测试系统为基础做了一套虚构算例源节点在节点1其余节点为负荷节点。选出5个候选预配置节点8、13、18、25、30。MPS参数设置如下MPS编号额定功率(kW)是否可接入中压开关柜1号500是2号800是3号500是场景方面我生成了2000个原始灾害场景削减后保留30个代表性场景。每个场景包含若干条线路故障和节点负荷系数。负荷权重设为重要负荷1.5倍普通负荷1倍。目标函数是30个场景的加权失负荷期望值。4.2 预配置结果求解后得到的最优预配置方案是1号电源预配置到节点82号电源预配置到节点253号电源留在基地备用。这个结果乍看有点反直觉为什么不把所有三台都预配置出去因为节点8和节点25分别覆盖了上半网和下半网两个高概率故障区第三台如果硬塞到一个确定节点反而可能在某些场景下离真正需要它的位置太远。留在基地意味着第二阶段可以根据实际故障点灵活判断下一步去向这种“故意留一手”的现象在随机优化里很常见。对比不预配置任何MPS故障后再从基地出发的基准方案预配置后的期望失负荷从42.6MWh降到了31.2MWh下降了约26.8%。这说明预配置的价值非常可观尤其是在故障后交通时间被限制在2小时以内的场景下。4.3 灵敏度分析MPS数量对韧性的影响我还做了一组MPS数量从1台到4台的灵敏度分析结果如下MPS数量期望失负荷(MWh)相比基准下降比例042.60%137.911.0%233.820.7%331.226.8%430.129.3%可以看到从3台到4台的边际收益明显变小。这个现象在工程上很关键不是移动电源配得越多越好预算有限时应该把资源优先投在前几台上。你如果自己想设计方案也建议做这种边际收益分析比单纯看总成本更说明问题。5. 复现踩坑记录与个人体会最后这部分我想写几个实际复现过程中真正让我头疼的问题以及在代码和模型上的处理经验。5.1 直接上大算例导致求解器长时间无解我第一次把两阶段模型完整写到33节点算例上用了60个场景跑了三个小时还没收敛。后来排查发现第二阶段变量定义得太细每个时段每个节点每个MPS都有0-1变量再加上预配置变量整体规模爆炸了。我的处理办法是先用6节点小算例加10个场景跑通全链路再逐步放大。放大过程中优先削减场景而不是削减网络规模。场景数量对求解时间的影响往往比节点数量更显著因为每个场景都复制了一套第二阶段变量。5.2 “大M”写法导致数值不稳定在建立“MPS是否在节点i供电”和“失负荷量是否为正”这类逻辑约束时很容易用大M法。我一开始写成类似L_i ≤ S_i M(1-z_i)的形式M取了1万。结果目标函数和约束数值量级差太远求解器在数值稳定性上出了很多问题。后来我改了两种做法一是尽量把M的下界取小二是能不用大M的地方改成直接逻辑约束。如果必须用大M就把所有约束数值scale到相近量级否则求解器容易给出让人看不懂的“数值坏解”。5.3 负荷权重设置不合理会让方案偏向普通负荷失负荷期望看着很简单但如果不加权优化器会只关注“少停下来”而不管哪些负荷重要。我第一版算例里重要负荷占比比较低优化结果把MPS都配置到了普通负荷高的区域重要负荷在故障时反而没保住。后来把重要负荷权重改成1.5倍甚至2倍方案才符合直觉。这个教训对任何做韧性评估的人都有参考价值。5.4 我建议的试验顺序如果你也想复现这类论文我建议按这样的顺序来做第一步把预配置当成纯选址问题忽略第二阶段细节只验证第一阶段约束是否合理第二步加入一个最简单的第二阶段场景比如单线路故障、单台MPS跑通目标函数闭环第三步扩展场景数量和网络规模最后再做灵敏度分析和可视化。这一步一步来的方式能帮你把建模错误和代码错误分隔开不然模型和代码混在一起出了问题你根本不知道是数学没建对还是矩阵维数写错。我在实际复现中还有一个体会韧性研究的难点经常不在“模型丰富”而在于“化简得当”。预配置问题看起来只是选址但如果不放在随机优化的框架里不把第二阶段的调度响应纳进去那算出来的方案很可能是假最优。下一篇我会接着写动态调度阶段也就是MPS故障后怎么移动、怎么形成孤岛如果你正在做这个方向正好可以接着往下看。