配电网韧性这两年是真的火尤其是极端天气频发之后大家发现传统可靠性那套“N-1校验、故障恢复”的思路在面对台风、冰灾这类小概率高损事件时根本不够用。我最近刚好在IEEE33节点系统上完整复现了一套移动储能预布局与动态调度策略从数学模型搭建到Matlab代码实现踩了不少坑也把整个逻辑链路摸透了。这篇就把核心思路、建模细节、代码结构和最容易出问题的地方一次性讲清楚想在这块入手的同学可以直接照着抄作业。1. 配电网韧性提升到底在解决什么问题1.1 韧性和可靠性的本质区别很多刚接触这个方向的人容易把韧性和可靠性混为一谈但这两个概念在电力系统里完全是两回事。可靠性关注的是日常运行中设备的随机故障比如某条线路因为绝缘老化跳闸了这时候通过联络开关转供、分段隔离大部分负荷能很快恢复。韧性对应的则是极端事件台风刮倒一排电杆、洪水泡了整座开闭所这种情况下故障不是单个元件的问题而是成片成片地停运常规的故障恢复手段基本失效。韧性研究里最经典的是那个“韧性曲线”也就是系统性能在极端事件前后随时间变化的轨迹。正常状态下系统性能是100%极端事件发生后性能骤降然后经过抢修、资源调度逐步恢复。韧性提升的核心就是让这个曲线的“凹陷”尽量浅、恢复段尽量陡——换句话说一是让系统在灾害中少丢负荷二是让系统在灾后恢复得更快。移动储能在这样的场景里就体现出独特价值了。固定储能只能守在一个点灾害发生后如果恰好不在关键负荷附近再大的容量也派不上用场。移动储能一般就是储能车的形式可以在灾前就开到预测的受灾区域附近待命灾后再根据实际故障情况灵活转移给失去主网供电的孤岛负荷供电、支撑关键节点电压、甚至辅助黑启动。这套“先预布局、再动态调”的思路本质上就是把储能变成了应急体系里一支可以机动的救援力量。1.2 为什么选择IEEE33节点系统作为验证平台IEEE33节点系统是配电网研究里用得最多的标准算例12.66kV电压等级33个节点、32条支路总负荷大约3715kW加2300kvar网络结构里还带了5条联络开关。这个系统规模不大不小单相潮流计算简单但拓扑结构足够复杂能体现出重构、孤岛划分、储能调度这些策略的效果差异。我复现的时候选它还有另一层考虑——顶会论文和期刊里凡是做配电网韧性、移动储能调度的十篇里有七八篇拿IEEE33节点做验证。算例参数公开、基准潮流结果明确代码跑出来的数据跟文献一对比就知道自己对不对。作为方案验证的“标准考场”IEEE33节点可以让你把精力集中在算法策略本身而不是花大量时间在系统建模上。提示IEEE33节点的基准数据网上很好找但要注意各篇文献对负荷系数的处理不完全一致。我做复现时统一按标幺值处理基准容量取10MVA电压基准12.66kV这样跟任何主流求解器对接都比较顺。2. 移动储能预布局与动态调度两阶段问题怎么拆2.1 预布局和动态调度的逻辑关系这套策略的核心是“两阶段决策”。第一阶段是预布局发生在极端事件来临之前但气象预报已经给出比较明确的灾害轨迹时决策者手里有移动储能车队需要决定每台储能车在灾害发生前停靠到哪个节点。第二阶段是动态调度发生在灾害已经发生、线路故障状态已经明确之后这时需要决定储能车在哪些时段移动到哪些节点、什么时候充放电、功率怎么分配。这两个阶段不是割裂的而是通过“场景”串联起来的。预布局阶段不知道灾害到底会让哪些线路断开只能用预测信息构造一批可能的故障场景动态调度阶段则是在故障场景揭晓后做精细化决策。两阶段放在一起建模型就是一个典型的两阶段随机规划或者两阶段鲁棒优化。我复现的这套代码用的是确定性场景法——预布局阶段构造多个灾害场景比如台风从不同路径经过造成不同范围的断线每个场景在第二阶段单独做动态调度第一阶段的目标是最小化所有场景下的总失负荷期望值。这样做的好处是模型直观、求解难度可控用商业求解器能直接求解也方便逐步改造成鲁棒优化版本。2.2 目标函数与约束条件怎么设计目标函数我采用的是失负荷惩罚最小化加上储能运行成本的综合目标核心是失负荷惩罚。实际编程中把每类负荷的重要性等级映射成不同的惩罚系数一级负荷医院、通信基站惩罚系数取最大二级负荷次之三级负荷最小。这样优化器在做取舍时会自动优先保住重要负荷。约束条件这块需要照顾到几个维度。储能自身有充放电功率限制和SOC上下限约束必须满足“充电时SOC上升、放电时SOC下降”的时序递推关系。移动特性用一组0-1变量表示某一时刻一台储能车只能停靠在一个节点从一个节点移动到另一个节点需要消耗时间这部分跟实际道路通行时间挂钩。配电网运行约束用DistFlow支路潮流方程描述节点电压必须维持在0.95到1.05pu的范围内支路电流不能越限。如果线路发生故障断开则该支路的有功无功潮流都必须强制为0。2.3 移动储能为什么要“动态”而不是“一次到位”最早看文献时候我也有个疑问既然预布局阶段已经决定了初始停靠位置灾害发生后故障清楚明了为什么不让储能车直接开到最需要的节点然后就不动了答案在于配电网的故障恢复是个动态过程——抢修队修好一条线路、恢复一段供电孤岛范围就在变化某个时段最缺电源的节点下一个时段可能已经通过联络开关恢复了主网供电。动态调度就是要让移动储能跟着负荷恢复的节奏走前期给最严重失电的孤岛供电中期配合重构策略移动到大负荷节点参与调峰后期主网恢复差不多了储能车可以回收到集中充电点补电。这种“跟着状态走”的调度方式能最大化移动储能的利用效率。我的仿真结果也证实了这一点——同样配置、同样场景下动态调度比固定接入方案的总失负荷量能低10%~20%具体取决于故障的分散程度。3. IEEE33节点系统建模与Matlab代码实现核心细节3.1 配电网DistFlow潮流方程的编程实现DistFlow是辐射状配电网最常用的潮流模型它把潮流方程写成支路首端流向末端的递推形式。在Matlab里实现这套方程有个关键技巧——用节点-支路关联矩阵来描述拓扑关系而不是逐条支路手写方程。这样不管系统是三节点还是三十三节点代码主体不用改只需要导入对应的关联矩阵和线路参数。编程时每一处非线性项都要特别注意收敛问题。DistFlow里的支路电流平方项和电压平方项在处理时通常做变量替换——用电流幅值平方和电压幅值平方作为新变量。如果直接用非线性约束丢给求解器不仅求解速度慢还容易陷入局部不可行。我复现时用的是二阶锥松弛来处理潮流约束在IEEE33节点这种辐射状网络上松弛误差非常小精度完全够用。需要说明的是故障场景通过修改节点关联矩阵来模拟把断开的支路对应的关联元素置0该支路的潮流自然为0。这样做的好处是不需要改变整体模型结构每个场景只需重新生成对应的关联矩阵即可。3.2 移动储能模型的状态转移与时空耦合移动储能是这套模型里最具挑战性的部分因为它的时间耦合和空间耦合是交织在一起的。时间上SOC必须逐时段递推空间上每一时刻停靠节点由0-1变量决定而移动本身又占用时间所以储能车在不同节点之间的转场必须满足时间窗约束。代码里我把这个约束展开成三维0-1变量一个维度是储能车编号一个维度是节点编号一个维度是时段编号。为了不让求解规模爆炸我在预布局阶段先筛掉不合理的接入节点——离故障预测区域太远的节点、本身没有重要负荷的节点都直接剔除把候选停靠节点限制在8到10个以内。这样0-1变量的数量可以压缩到一个可接受的范围。储能SOC的初值设定也很关键。预布局阶段结束时储能车应以满电或较高电量到达预布局节点这样灾害发生后才能第一时间支撑负荷。代码里我用“[0,1]区间表示SOC初值取0.9”经过充电约束校正后系统会在夜间负荷低谷自动安排储能补电。如果你想把场景做得更真实可以考虑加上储能容量退化成本每个循环按放电深度折算成本系数。3.3 Yalmip建模与求解器配置的关键操作Matlab代码实现里最核心的工具链是Yalmip加商业求解器。Yalmip是一个Matlab的建模语言工具箱可以在Matlab里直接用接近数学表达式的语法描述优化问题然后把模型交给CPLEX或Gurobi这类求解器去解。我在复现时选的是CPLEX配电网优化问题里CPLEX对混合整数二阶锥规划的处理很成熟。建模时有几个细节直接影响代码能不能跑通。变量定义阶段要明确区分连续变量和整数变量一般在Yalmip中用binvar定义0-1变量用sdpvar定义连续变量。约束条件通过循环逐条添加但循环次数多了求解效率会下降我的做法是把可以向量化的约束尽量写成矩阵运算只有那些跟拓扑强相关的约束才保留逐条循环。求解器参数设置也很重要。混合整数规划问题默认的求解时间上限是无限大如果不设限制复杂场景可能跑几个小时都不收敛。实际编码时我会设置opssdpsettings(solver,cplex,verbose,2,cplex.timelimit,3600)让求解器在一小时内给出可行解同时开启MIP gap容差一般控制在1%以内就能确保结果精度。Yalmip的安装其实很简单——下载最新版Yalmip压缩包解压后把整个文件夹加入Matlab路径就能用。但很多人忽略了一个前置依赖Yalmip自带的开源求解器只适用于极小规模问题真正求解中大规模优化必须装CPLEX或Gurobi这两个求解器需要单独安装并配置许可证还要在Matlab里添加相应路径。我见过太多人只装了Yalmip就去跑代码然后报一堆“No solver found”的错误。3.4 IEEE33节点的算例参数与故障场景构造IEEE33节点的线路参数和负荷参数是公开的我在代码里以表格形式内置了一份基准数据。需要提醒的是必须认真核对联络开关的节点编号——不同文献的表达方式略有差异如果你写的重构代码涉及联络开关编号对不上结果就会差很多。标准IEEE33节点共含33个节点、32条分段开关、5条联络开关总负荷3715kWj2300kvar。仿真中我把整个时间窗设为24小时步长取1小时这样一天之内的负荷波动、储能SOC变化都能体现出来。故障场景我是这样构造的——假定极端事件发生在第6小时持续到第12小时影响范围包括3到4条关键线路同时断开造成一个中等规模的停电区域。每个场景的负荷曲线都按实际时序取这比用恒定负荷更贴近真实运行状态。为了让复现效果更有说服力我会在代码里运行三个对照组方案一无储能纯靠配电网重构恢复负荷方案二固定储能储能车在灾前一次性停靠后不再移动方案三移动储能完整执行预布局与动态调度策略三组结果一对比移动储能策略的优势就很直观了——方案三的总失负荷量跟方案二比能下降一到两成方案二比方案一也有一定改善。4. 仿真流程与核心代码结构逐段拆解4.1 主程序框架和模块划分我复现的代码按功能划分成六个模块参数初始化、场景生成、预布局模型、动态调度模型、结果输出和绘图。主程序main.m做的事很简单——设置总时段数、调取IEEE33节点参数、生成故障场景然后按顺序调用预布局优化和动态调度优化最后汇总结果。推荐在代码开头用清晰的分节注释标注每一块功能比如用%% 1. 导入IEEE33节点参数、%% 2. 生成故障场景这样的段落标记。这样代码读起来清晰也方便后续修改。在调试阶段可以在关键位置增加disp输出观察每一步优化结果是否合理——比如预布局阶段你可以输出每台储能车的预布局节点人工核对一下是不是落在关键负荷附近。4.2 预布局阶段的计算流程和核心代码逻辑预布局阶段的输入是故障场景集合和储能车队参数输出是每台储能车的初始停靠节点。代码里我定义了一个结构体数组MESS每个元素代表一台储能车字段包括额定容量、额定功率、SOC初值、所在节点编号。核心计算流程大致是对所有故障场景逐个求解动态调度子问题得到对应场景下的最优失负荷量将各场景的失负荷量按概率加权求和得到目标函数值通过优化器迭代调整预布局位置直至目标函数最小这一步在实际求解时可以用Benders分解的思想理解但Yoalmip直接建混合整数二阶锥模型也能整体求解。考虑到模型规模如果场景数控制在3到5个求解时间一般能在几分钟内完成。我的经验是不要一上来就枚举20个场景先把单场景跑通确认所有约束都正确再逐步增加场景数。4.3 动态调度阶段的时序递推与状态更新动态调度阶段是在每个故障场景内部求解的。代码中两层循环的结构各司其职外层循环按场景遍历内层循环按24个时段做时序递推。每个时段需要决策的内容是每台储能车当前接入的节点、充放电功率、以及配电网中各节点负荷的恢复比例。这个阶段最容易出错的是SOC递推的方向问题。充电时SOC增加、放电时SOC减少这个方向如果写反了优化器为了“省电”可能会让SOC一直保持高位但实际放电功率却为零造成结果虚高。为了避免这类问题我在每次求解结束后都单独写了一段校验代码检查SOC曲线是否满足起止值约束和单调性约束这样能尽早发现BUG。动态调度阶段还需要考虑储能车移动所需的时间。这不仅仅是路程上的时间还得考虑接入、断开、安全校验这些操作环节。代码里我用一个转移时间矩阵描述任意两个节点之间移动所需的时段数。预布局阶段就要求储能车在故障发生前提前到达目标节点同样动态调度中状态转移也受到这个矩阵的严格约束。5. 常见问题、复现经验与避坑指南5.1 求解器报错找不到求解器或者求解器许可证过期这个问题几乎每个用Yalmip的人都会遇到通常的表现是运行optimize命令时提示“No suitable solver installed”。首先要确认Yalmip库已正确添加路径第二要确认CPLEX或Gurobi已经正确安装并且Matlab能识别到它们。可以在Matlab命令行输入yalmiptest来测试所有已注册的求解器状态。国内很多用户还会遇到CPLEX许可证过期的问题学术版许可证一般一年一续。如果实在暂时没拿到新许可证可以先用Gurobi或Mosek代替——Yalmip建模的好处就在这里切换求解器只需改一行solvesettings参数模型本身完全不用动。我复现时就是先用Gurobi跑通了整个流程后来才换回CPLEX做最终验证结果完全一致。注意不同求解器对二阶锥约束的支持程度略有差异如果你的模型里既有多面体约束又有二阶锥约束建议在求解前用check命令逐条核验所有约束的可行性避免因为求解器处理方式差异导致模型被吞约束。5.2 结果不合理失负荷量异常大或SOC曲线跳变如果仿真结果里失负荷量大得离谱第一件事不是改算法而是检查故障场景是不是设置得太苛刻。我调试时就遇到过把联络开关对应的支路也当作故障断开的低级错误结果整个网络被切成好几个孤立区域移动储能的容量根本不够用。检查方法是把故障场景里的断开支路编号打印出来跟网络拓扑逐一对照确认故障范围符合你的预期。SOC曲线跳变通常跟初值或功率约束有关。比如SOC设置成0到1的连续变量但充电功率的上限设得太低导致SOC在多个时段内无法恢复到合理水平。这种问题排查时把每台储能车的充放电功率和SOC画在同一个图上一眼就能看出约束是否合理。5.3 求解时间爆炸混合整数变量太多怎么办两阶段优化里最怕的就是0-1变量爆炸。我的经验是三条路并行第一压缩候选接入节点数量把33个节点按负荷重要性、故障概率排序只保留前10个作为储能接入候选第二把储能车移动动作的决策粒度从“每个时段都能移动”放宽到“每两小时才能移动一次”时间窗一收紧0-1变量立刻少一半第三给优化器设置合理的MIP gap不需要追求精确最优工程上1%以内的次优解已经完全可用。如果你后续想改进这套代码几种思路是比较常见的把随机场景拓展为两阶段鲁棒优化用列与约束生成算法迭代求解在动态调度阶段加入配电网重构决策让联络开关的状态也参与优化再就是把目标函数细化考虑储能寿命损耗、碳排放等更多的成本因子。这些方向文献里都有成熟的做法在现有代码框架上加改也比较方便。我个人在实际复现中的体会是移动储能预布局与动态调度这套策略真正难得不是某个单一模型而是把“时间维度上的能量转移”和“空间维度上的位置转移”耦合在一起建模。你既要把储能SOC的时序递推写对又要把0-1位置变量和配电网拓扑约束衔接好任何一个环节的疏漏都会让结果偏离物理实际。建议复现时一定分模块逐步验证先跑通纯固定储能的调度再加上移动约束最后再叠加预布局场景。这种渐进式的调试方法比一口气写完全部代码再回头找错要省时间得多。
