这两年做混合配电系统规划我最大的感受就是真正难的不是把某个可靠性指标算出来而是怎么把经济性和可靠性这两个天生互相打架的目标放进同一个规划框架里同时还能用代码把整套流程跑通。这个项目恰好就是干这件事——用Python实现了一套兼顾经济与可靠性的双目标混合配电系统规划方法并配套了可靠性评估模块。非常适合正在接触配电网规划、想从纯手工计算转到编程实现的电力专业研究生以及需要做方案比选的一线配网规划人员阅读。整套代码不依赖商业电力软件用Python的numpy、pandas、matplotlib生态就能完全跑通。我会从问题背景、数学模型、算法实现、实操细节和踩坑经验这几个角度来拆解这个项目。如果你也想做一个能实际用的规划工具而不是停留在公式推导上这篇内容应该能帮你少走不少弯路。1. 项目定位与核心思路1.1 混合配电系统为什么值得专门研究传统配电网是单向辐射状供电结构变电站降压之后电能顺着馈线流到各负荷点。但最近几年情况变化很大越来越多的分布式电源比如屋顶光伏、工商业储能、小型燃气轮机接入配电网负荷节点不再只是用电的有些节点也开始发电。这就形成了所谓的混合配电系统——既有传统单向上级电源又有分布式电源的灵活出力拓扑结构也更复杂。在这种系统里做规划首先要面对的问题就是可靠性分析不能再沿用传统配电网那套简化假设。传统配电网里故障影响范围主要靠开关分段和联络开关来隔离而混合系统里分布式电源可能在被隔离的孤岛内继续供电也可能因为保护配合不当导致故障范围扩大。所以混合配电系统的规划实际上是在选择新增哪些设备和线路决定分布式电源安装在哪、装多大容量的同时还必须重新评估系统的可靠性水平。这也是为什么不能简单套用一个经典可靠性模型的原因。值得注意的是混合配电系统的规划变量比传统问题多得多。传统规划主要考虑线路扩容和变电站新建而混合系统还要考虑分布式电源的选址定容、储能配置、开关位置优化。这些变量相互耦合比如一个位置装光伏可能对电压有提升作用但故障时可能带来孤岛运行风险。项目里把这些问题统一到一个优化框架里本质上是在做一个多变量、多约束的组合优化问题难度明显高于传统单目标规划。1.2 双目标规划要解决的真实矛盾电力系统规划里经常存在又要马儿跑又要马儿不吃草的情况。可靠性提升通常意味着投资增加——要装更好的开关设备、要增加冗余线路、要建设更多分布式电源和储能。但反过来如果过度投资成本会飞快上涨可靠性提升却越来越有限。这个矛盾就是双目标规划存在的根本原因。我举一个直观的例子在某条关键馈线上加装分段开关能把故障隔离范围缩小一半SAIDI用户平均停电持续时间可能降低20%但需要增加几十万投资。如果你再加装一台联络开关可靠性可能只再提高3%成本却又要增加几十万。单目标规划只能选择一个方向优化要么做成成本最低要么做成可靠性最高可实际工程里需要的是用合理的成本获得可接受的可靠性这就要在多个候选方案里权衡。双目标优化的意义就在于它不直接给你一个最优解而是输出一组帕累托前沿——这条前沿上的每个方案都有一个特点想提高可靠性就必须接受成本上升反过来想省钱就必须接受可靠性下降。决策者可以根据手里的预算和供电可靠性考核指标在这条前沿上挑一个最合适的点。这个思路比传统的加权单目标更符合工程实际因为不同地区、不同负荷性质的可靠性需求差别很大城市核心区和高新区对停电时间极度敏感而乡村用户对投资成本更敏感。1.3 为什么选择Python而不是传统电力软件现在很多高校和设计院还在用MATLAB配合某些商业化电力分析工具做规划计算但我在实际项目里越来越倾向用Python。原因有三个第一Python的生态更适合做优化—评估耦合的循环流程。配电系统规划需要在优化算法里反复调用潮流计算和可靠性评估这是一个典型的外层搜索、内层评估结构。用numpy和scipy写这种循环非常顺手向量化之后速度不比MATLAB差而且代码更容易维护和扩展。第二Python的数据处理能力能大幅度提高前处理的效率。规划问题需要处理负荷数据、地理信息、元件参数、故障率数据pandas可以直接读Excel、CSV还能方便地合并和清洗数据。以前我用别的工具光整理数据就要花不少时间换成Python之后这部分工作顺畅很多。第三可视化能力和可复现性很重要。matplotlib加上plotly能很快画出系统单线图、帕累托前沿散点图、可靠性指标柱状图。给导师或者甲方汇报时有一张清晰的图比解释半小时公式都有用。而且Python代码的复现门槛低同一套代码在不同机器上跑只要环境一致结果完全可复现对科研和工程评审都很友好。2. 模型构建与数学化表达2.1 目标函数全寿命周期成本结构双目标规划的第一步是把两个目标量化。经济性目标我用的是全寿命周期成本LCC不只是一个简单的初始投资。LCC包含四个部分设备投资成本包括新增线路的单位长度造价、断路器/隔离开关的设备购置与安装费用、分布式电源的单位容量造价、储能系统的单位容量造价。运行维护成本设备投运后每年的运维费用一般按投资成本的比例系数估算分布式电源和储能的比例系数会比线路高不少。网损成本系统运行过程中在网络里损耗的电量对应的费用需要调用潮流计算结果把各支路损耗加起来再乘以电价。停电损失成本也就是可靠性目标对应的经济损失需要把系统年平均缺供电量乘以单位停电损失费用。这里有一个关键细节投资是一次性的而运维、网损、停电损失是逐年发生的不同年份的钱不能直接相加必须做等年值处理。例如把总投资折算到每年再叠加年运维、年网损、年停电损失费用这样才能让规划期内的总成本口径统一。我的代码里用了一个标准的等额分付资本回收系数把现值投资折算到每年公式是折算后的年投资费用 总投资成本 × r × (1r)^n / ((1r)^n - 1)其中r是贴现率n是规划年限。很多初学者在这个地方容易漏掉直接把投资和运行费用相加导致成本目标量纲不统一优化结果自然不对。可靠性的目标函数我选择的是系统平均缺供电量ENSEnergy Not Supplied。ENS是一个绝对量单位是千瓦时/年比SAIFI和SAIDI更适合做优化目标因为它既能反映停电的频率也能反映停电的深度和规模。可以用下面的思路理解为每次故障发生时由可靠性评估模块计算出受影响的负荷功率和停电时间两者相乘并累加起来就是该故障事件对ENS的贡献。优化算法在迭代过程中把所有规划方案的ENS都计算出来与LCC一起构成双目标向量用于非支配排序。2.2 可靠性评估指标体系与选择逻辑可靠性评估不能只盯一个指标。工程上通常会看四个指标系统平均停电频率指标SAIFI用户平均停电持续时间指标SAIDI系统平均缺供电量ENS以及用户平均停电持续时间指标CAIDI。它们之间的关系大体是SAIFI衡量停电频率SAIDI衡量每个用户在统计时间内平均停了多久ENS衡量总的少供了多少电量CAIDI则是SAIDI除以SAIFI反映每次停电平均持续多长时间。在这个项目里为什么优化目标选ENS而不是SAIDI我解释一下SAIDI侧重用户停电时长它对停电影响范围不敏感举个例子一个变电站故障导致100户停电5小时和一条分支线故障导致10户停电5小时SAIDI的贡献可能相差不大但实际经济损失差异巨大。ENS是功率×时间的累积量停电范围大、停电时间长ENS就大它天然能反映故障对供电量的实际影响跟经济性目标里的停电损失成本直接挂钩。所以用ENS做可靠性目标双目标之间的逻辑更统一——LCC代表花钱ENS代表缺电的实物量两者可以对应到同一个经济框架里。当然最终的规划结果展示不能只有ENS我还会把SAIFI、SAIDI、CAIDI都算出来放在结果表里。这样决策者跟上级部门汇报时既可以说这个方案每年能少缺供多少电也可以说用户平均停电时间降到多少分钟两种话语体系都覆盖了。2.3 约束条件的取舍与处理技巧规划模型不是把目标定好就能算还必须满足各种技术和安全约束。我在这套代码里重点实现了五类约束潮流平衡约束每个节点的注入功率和流出功率必须平衡这个靠调用潮流计算程序来校验而不是显式写出全部方程。节点电压上下限约束根据不同供电区域的标准一般设定在额定电压的±5%或±7%范围内。支路容量约束流过每条支路的电流不能超过载流量防止重载和过载。辐射状网络拓扑约束这是配电网的刚性要求混合系统接入分布式电源之后网络仍必须保持辐射状运行结构不能形成闭环导致保护复杂化。分布式电源渗透率约束分布式电源总容量不能超过系统最大负荷的一定比例避免出现大量倒送功率等不利情况。约束处理上我采用的是惩罚函数可行性修正混合策略。对于潮流计算直接能判断的电压越限、支路过载我在目标函数里加惩罚项对于拓扑约束在生成网络结构时就直接检查不符合的就丢弃该个体。为什么不在所有约束上都用惩罚函数因为拓扑约束如果用惩罚值去处理会出现大量非法个体占用计算资源的情况种群整体趋向可行域的速度很慢。而先硬性过滤拓扑再用惩罚处理电压和容量越限收敛效率会高很多。惩罚系数的取值也有一点讲究。如果惩罚系数太小约束破坏换来的目标值下降会让优化算法觉得值得最终结果就经常越限如果系数太大又会让目标函数值变得非常大导致算法过度保守很难找到边界解。我一般取每个目标数量级的一半作为初始惩罚系数然后根据结果微调这个参数不要一开始就拉到很大。3. Python实现的算法选型与代码设计3.1 多目标优化算法为什么是NSGA-II双目标优化看似复杂其实主流做法就是多目标进化算法。我选择NSGA-II而不是其他算法是因为它在双目标问题上兼顾了收敛性和分布性而且实现相对成熟不需要太复杂的公式推导就能在Python里写出来。NSGA-II的核心思路可以概括为三步非支配排序、拥挤度距离计算、精英保留策略。非支配排序负责把种群中的个体分成多个层级第一层是当前最优的帕累托前沿第二层次之以此类推。拥挤度距离则是为了保持解的多样性让前沿上的个体分布更均匀避免所有解挤在一个角落。精英保留策略保证父代里的好解不会因为交叉变异丢失下一代种群一定包含上一代的优秀个体。实际代码中一个关键点是交叉和变异算子的设计。规划问题里个体是混合编码的线路是否新建、开关是否装设这些用二进制位表示分布式电源的安装容量可能是离散档位也可以是连续实数。我在项目里用的是二进制编码用于拓扑选择、实数编码用于DG容量的混合表达。交叉时对二进制部分做单点交叉对实数部分做模拟二进制交叉SBX变异时二进制位做基本位变异实数部分做多项式变异。这种混合编码比统一用二进制或统一用实数都更贴近变量的物理属性。算法参数方面我建议种群规模N100~200迭代次数T100~200代。双目标问题不像高维多目标那么吃种群100个个体已经能画出比较完整的前沿迭代次数太多会拖慢速度太少则前沿会残缺。交叉概率取0.9、变异概率取0.1是比较稳妥的起点。如果帕累托前沿某段凹陷很明显优先调大种群规模而不是迭代次数——这个我在后面踩坑部分还会详细说。3.2 配电网潮流计算的Python实现思路优化算法每评估一个个体就要对当前规划方案下的配电系统做一次潮流计算找出节点电压和支路电流。配电网是辐射状结构采用前推回代法最合适。这个方法的思想很朴素回代是从末端往根节点推功率前推是从根节点往末端推电压反复迭代到前后两次电压差满足精度为止。用Python实现时我做了这样的模块划分# 定义配网拓扑数据类 class NetworkData: def __init__(self): self.branch [] # 每条支路的起点、终点、电阻、电抗、容量 self.bus_load [] # 每个节点的有功无功负荷 self.head_node 0 # 根节点编号 # 前推回代潮流函数 def power_flow(net: NetworkData): # 初始化节点电压向量 # 回代从末端向根节点累加支路功率 # 前推从根节点向末端更新节点电压 # 迭代判断电压偏差是否收敛 return voltage, branch_flow, network_loss这段代码看起来简单但里面有不少细节点需要注意。比如配电网节点编号和支路父子关系的构建必须唯一不能有孤岛再比如分布式电源在潮流计算里要作为PQ节点还是PV节点处理如果做PQ节点就直接把有功和无功放进节点注入功率里如果设备有无功调节能力可能需要更复杂的处理。我项目里默认把分布式电源和储能当作PQ节点给定有功出力和功率因数这样前推回代实现最简单也足够满足多数规划阶段的精度需求。向量化处理是提升潮流计算效率的关键一步。如果对于每条支路单独计算Python的循环开销会非常可观。把支路参数全部放进numpy数组用数组运算一次更新所有支路的功率和电压速度能快一个数量级。我在项目里实测过一个33节点的网络单次潮流计算从毫秒级下降到百微秒级优化循环里要调用上千次累积下来差距非常大。3.3 可靠性评估模块的两种实现路线可靠性评估模块是这套代码里最有分量的部分。我实现了两种方法状态枚举法和序贯蒙特卡洛模拟法。这里解释一下两者的适用场景。状态枚举法适合元件数量不太多、故障模式清晰的系统。它的思路是把系统中各个元件馈线、变压器、开关、分布式电源看作一个个可以故障的设备每个设备有故障率和修复时间。把所有可能发生的故障状态枚举出来逐一分析影响范围再按概率加权汇总成系统指标。比如系统里有一条线路故障率是0.2次/年平均修复时间5小时那这次故障每年预期发生0.2次每次影响若干负荷累加就能得到ENS的一部分贡献。当元件数量很多时枚举所有状态组合会爆炸所以状态枚举法更适合规划阶段的小型算例分析。序贯蒙特卡洛模拟法则更适合考虑时序特性的情况比如光伏出力随时间变化、储能充放电策略随状态变化。它的思路是模拟一个很长的时间过程比如8760小时一年根据每个元件的可靠性参数随机抽样故障发生时刻和修复时长在时间轴上演化整个系统状态最后统计全年的指标。这种方法灵活能考虑时变负荷和可再生能源出力的时序性但计算代价明显更大。在双目标优化的循环里我不建议每个个体都跑完整的序贯蒙特卡洛模拟而是先使用状态枚举法快速评估用来在优化过程中筛选方案等得到最终的帕累托前沿后再对少数几个推荐方案用序贯蒙特卡洛做精细校核。这种粗筛细校的策略能把可靠性评估的计算量控制在线性范围。如果反过来上来就用蒙特卡洛一次优化几千次评估每评估一次跑8760个小时的时序模拟代码可能要跑一整天。4. 实操过程与关键环节实现4.1 算例设置与数据准备我用经典的IEEE 33节点配电系统作为基础测试算例。这个系统包含33个节点、32条支路、1个变电站根节点系统总负荷大约5083j2547 kVA。它现在已经成为配电领域公认的标准测试系统参数在网上和很多论文里都能找到直接拿来做算法的验证和对比非常方便也方便读者复现结果。数据准备阶段要准备四类数据文件网络参数表节点编号、支路阻抗、负荷功率、节点类型、候选规划方案表可新建线路位置、可安装分布式电源的候选节点、可靠性参数表每条线路的故障率、故障修复时间、开关操作时间、经济参数表各类设备的单位造价、电价、贴现率、规划年限。在做数据清洗时我有个经验一定要把负荷数据的量纲统一。IEEE标准算例里负荷单位是kVA和kW经济参数里电价单位是元/千瓦时最后计算的能量单位是千瓦时/年如果在数据导入时没有统一单位算出来的成本可能偏差极大。我的做法是全部用pandas读入后马上做单位检查统一换算成标幺值或者有名值的同一量纲体系再交给优化程序。4.2 双目标优化的完整流程设计整套优化流程的顺序是这样的初始化种群生成N个随机规划方案每个方案对应一种线路增建组合和分布式电源配置组合。对每个个体进行拓扑校验检查方案是否满足辐射状网络要求不满足就重新生成或修复。调用潮流计算模块校验电压和容量约束同时得到网损成本。调用可靠性评估模块用状态枚举法计算ENS。计算两个目标值年化LCC、ENS放入种群。进行非支配排序和拥挤度距离计算。通过锦标赛选择、交叉、变异生成子代种群。合并父代和子代做精英保留生成新一代种群。重复步骤2~8直到达到最大迭代次数。输出最终帕累托前沿绘制散点图统计各方案的可靠性指标。这个流程里最容易被忽略的是第2步拓扑校验。很多代码实现没有这一层过滤导致优化算法在大量非法解里浪费时间甚至最终前沿里混入闭环网络方案。我在程序里直接用一个DFS深度优先搜索判断图是否满足辐射状连通条件不符合的个体直接不给评估机会这样能节省至少30%的无效计算。代码层面优化主体用一个类封装每个个体是类里的一个对象包含决策变量、目标值、拥挤度、支配层级这些属性。用类组织的好处是直观一个个体就是一个候选规划方案后期调试时你可以单独拎出某个个体去看它的目标值怎么来的不用在多个数组之间跳来跳去。4.3 可靠性评估模块的关键实现细节可靠性评估模块内部需要一个故障影响分析子程序这是整个项目正确性的基石。每次枚举一条线路故障我都要确定哪些负荷点受停电影响、影响多长时间、是否有分布式电源可以孤岛供电、联络开关是否能把负荷转移到相邻馈线。一个典型的处理流程是首先找出故障线路的位置并判断以该线路为边界哪些节点处于上游哪些处于下游。上游节点只要变电站侧正常工作通常不受影响下游负荷是否停电取决于故障点有没有分段开关可以隔离故障。如果没有分段开关下游全部失电停电时间等于故障修复时间。如果有分段开关故障段上游的分区可以通过开关动作快速恢复供电停电时间变为开关操作时间故障段本身则要等修复。如果网络中有联络开关且和相邻馈线有连接还可以把部分负荷通过联络转供出去转供负荷只经历操作时间没有经历完整修复时间。如果故障后存在分布式电源孤岛且孤岛内电源容量足够带起部分负荷则这部分负荷的停电时间更短或者不受影响。这个判断逻辑写起来不复杂但边界条件非常多。我建议用字典加集合的方式组织拓扑关系而不是只用数组因为故障隔离位置判断需要频繁查找父子关系和上下游节点集合。关于分布式电源在故障评估中的处理我发现一个容易出错的地方DG孤岛能不能成立取决于孤岛内DG容量是否大于孤岛负荷。如果小于那么这个孤岛依然要损失一部分负荷。代码里我不能只判断存在DG即恢复供电还要做容量匹配计算把差额负荷损失计入ENS。很多初版代码在这里估算偏乐观原因就是忽略了DG容量约束。4.4 代码性能优化从半小时提速到几分钟这套程序最大的性能瓶颈在优化迭代 × 可靠性评估的双重循环里。每评估一个个体都要遍历线路故障枚举如果一条馈线有32条支路每个个体就需要做32次故障影响分析。种群200个个体、迭代100代整体就是64万次故障分析如果每次分析都用低效的循环去扫描节点速度会非常难看。我做了三个层面的优化效果非常明显第一用numpy向量化替代纯Python循环。故障影响分析过程中节点上下游集合的判断可以用数组索引一次完成不再逐个节点遍历。第二把可靠性评估中不变的拓扑参数比如支路父子关系、分段开关位置提前计算好缓存起来每个个体评估时只需要修改变更后的部分而不是从头建立整棵拓扑树。规划阶段每次拓扑变化其实很小大部分网络结构是共享的。第三如果机器有多核可以用multiprocessing做并行评估。把种群个体分成多个批次用进程池并行跑潮流和可靠性计算。我这里试验过4个核的并行速度大约能提升3倍16核机器上速度提升更明显。不过要注意数据分割和结果汇总的编码细节不要多个进程之间共享可变对象。经过这套优化IEEE 33节点系统的一轮全过程优化从最初的接近40分钟降到大约5分钟完全在可接受范围内。5. 常见问题与排查技巧实录5.1 帕累托前沿分布很差怎么办帕累托前沿如果拧成了一个团或者集中在一个角落里最常见的原因是拥挤度距离没有生效。NSGA-II的拥挤度计算是为了让前沿上的解均匀分布如果附近解过于密集这个解的拥挤度距离就小在精英保留时更容易被淘汰。但如果代码里拥挤度距离计算有误算法就只收敛不分布所有解会堆到目标函数值比较接近的区域。排查方法也很直接打印几代种群的目标值分布看看是不是某一代开始所有个体聚集在某个小区间。如果是我建议先检查拥挤度距离的计算公式确认是否对目标函数做了归一化。如果不同目标数值量级差距过大LCC可能是几千万元ENS可能是几万千瓦时拥挤度距离会被大数值目标主导一定要先进行min-max归一化再做距离计算否则分布性一定受影响。另一个容易导致前沿残缺的问题是惩罚系数设置不当。如果停电损失成本在LCC里的占比太高优化算法会过于偏向低ENS方案整个前沿就缩到高成本端反过来如果惩罚系数里可靠性评估的权重太低成本优先方案会统治种群。这个平衡没有通用解要靠多跑几组参数观察前沿形状来调整。5.2 可靠性指标结果异常偏大或偏小怎么查可靠性评估结果偏大的常见原因是对故障影响范围的判断过于保守。比如明明有分段开关可以快速隔离故障但代码里没有正确实现开关动作的效果导致下游所有负荷都按修复时间停电ENS自然偏大。类似的联络结构如果转供能力判断错误也会高估停电电量。反过来结果偏小的常见原因前文提过在孤岛评估时忽略了DG容量小于孤岛负荷的情况以及开关拒动概率没有考虑。在规划阶段做方案对比不考虑开关拒动概率是可以接受的但如果在正式报告中要给出绝对可靠性数据就需要把保护开关的可靠动作概率纳入模型否则结果会偏乐观。我自己排查这类问题时习惯把某个具体的故障事件单独拿出来手算一遍和程序输出对比。比如指定支路5故障程序算出ENS贡献是某个数我手工按拓扑推一遍影响范围和停电时长很快就能发现是停电时间算错了还是影响节点集合判断错了。这个单事件对照法虽然笨但比漫无目的地改参数高效得多。5.3 潮流计算不收敛的几种典型原因前推回代法有时会不收敛最直接的表现是电压越限、网损出现负值、迭代次数达到上限。针对这个项目我遇到的案例主要有三类原因第一是网络参数里出现电抗远大于电阻的支路数据错误。配电网的特点是高阻低抗如果填写数据时电阻电抗颠倒了收敛性能会明显变差。第二是分布式电源接入了但容量设置过大导致部分节点电压严重越上限。这种情况潮流计算会不断震荡因为回代功率方向来回变化出现假性不收敛。解决办法是先检查DG容量设置是否在渗透率约束范围内再看节点的PQ设置是否有功为负。第三是拓扑结构出现了孤岛节点或者接触不良的串联不入网结构导致回代过程无法从末端向根节点汇聚。我在程序里加入了一个拓扑连通性校验函数任何时候构建新的个体之前都先调用一次能避免90%的潮流发散问题。提示调试潮流不收敛时先别急着调精度阈值大概率是数据或者拓扑的问题先确认这两点再考虑算法本身。5.4 运行时间长的线程级别优化心得整套代码跑完一次优化是一件事但实际工程里我要对比多个场景不同折扣率、不同负荷增长率、不同DG渗透率上限每个场景都要跑一轮完整规划。所以运行时长直接影响研究效率。除了前面说的向量化和多进程还有一个很有用的技巧是早期终止。在迭代初期种群的目标值离最终收敛状态很远如果此时就进行完整的可靠性评估其实是很浪费的。可以先在流程里用更粗糙的模型比如不考虑开关动作时间的简化评估快速算出一个大概的ENS用来做初筛当种群进化到中后期再把评估模型切换到精确状态枚举法。这个设计需要保证迭代中两次切换之间种群连续否则可能突然因目标值尺度变化导致排名振荡。保守一点的做法是前一半迭代用简化评估后一半全程用精确评估中间做一次对个体目标值的重新标定。我实测这种方式能再省掉大约20%~30%的总运行时间。结尾一点点个人的实操体会最后分享一个我在这套项目里最深的感觉写规划代码最大的坑往往不是算法公式写错了而是你以为模型对了、代码也对了但结果就是不合理。我在跑双目标优化时第一次拿到帕累托前沿图看到一个点上LCC很低但ENS也很低特别兴奋觉得找到了完美方案。后来仔细检查才发现这个个体其实违背了辐射状拓扑约束潮流和可靠性评估直接给了异常值两个指标都被人为压低看起来就是又便宜又可靠。所以我现在每次跑完优化都会随机抽几个前沿上的个体人工看一下它们的规划结果——线路增建在哪里、DG建没建、可靠性指标跟拓扑是否匹配。这一步虽然麻烦但能挡住一大半看起来正确的错误方案。如果你也想在这个方向继续深入我建议下一步可以扩充两个维度一是加入储能时序运行策略利用序贯蒙特卡洛模拟评估DG出力和负荷的时序匹配性二是把配电网重构运行阶段动态调整拓扑纳入规划阶段让经济性和可靠性目标在更真实的运行策略下得到评估。这两个方向都会让模型更贴近实际但代码复杂度也会上一个台阶值得预留足够的时间慢慢打磨。
基于Python的双目标混合配电系统规划与可靠性评估实现
这两年做混合配电系统规划我最大的感受就是真正难的不是把某个可靠性指标算出来而是怎么把经济性和可靠性这两个天生互相打架的目标放进同一个规划框架里同时还能用代码把整套流程跑通。这个项目恰好就是干这件事——用Python实现了一套兼顾经济与可靠性的双目标混合配电系统规划方法并配套了可靠性评估模块。非常适合正在接触配电网规划、想从纯手工计算转到编程实现的电力专业研究生以及需要做方案比选的一线配网规划人员阅读。整套代码不依赖商业电力软件用Python的numpy、pandas、matplotlib生态就能完全跑通。我会从问题背景、数学模型、算法实现、实操细节和踩坑经验这几个角度来拆解这个项目。如果你也想做一个能实际用的规划工具而不是停留在公式推导上这篇内容应该能帮你少走不少弯路。1. 项目定位与核心思路1.1 混合配电系统为什么值得专门研究传统配电网是单向辐射状供电结构变电站降压之后电能顺着馈线流到各负荷点。但最近几年情况变化很大越来越多的分布式电源比如屋顶光伏、工商业储能、小型燃气轮机接入配电网负荷节点不再只是用电的有些节点也开始发电。这就形成了所谓的混合配电系统——既有传统单向上级电源又有分布式电源的灵活出力拓扑结构也更复杂。在这种系统里做规划首先要面对的问题就是可靠性分析不能再沿用传统配电网那套简化假设。传统配电网里故障影响范围主要靠开关分段和联络开关来隔离而混合系统里分布式电源可能在被隔离的孤岛内继续供电也可能因为保护配合不当导致故障范围扩大。所以混合配电系统的规划实际上是在选择新增哪些设备和线路决定分布式电源安装在哪、装多大容量的同时还必须重新评估系统的可靠性水平。这也是为什么不能简单套用一个经典可靠性模型的原因。值得注意的是混合配电系统的规划变量比传统问题多得多。传统规划主要考虑线路扩容和变电站新建而混合系统还要考虑分布式电源的选址定容、储能配置、开关位置优化。这些变量相互耦合比如一个位置装光伏可能对电压有提升作用但故障时可能带来孤岛运行风险。项目里把这些问题统一到一个优化框架里本质上是在做一个多变量、多约束的组合优化问题难度明显高于传统单目标规划。1.2 双目标规划要解决的真实矛盾电力系统规划里经常存在又要马儿跑又要马儿不吃草的情况。可靠性提升通常意味着投资增加——要装更好的开关设备、要增加冗余线路、要建设更多分布式电源和储能。但反过来如果过度投资成本会飞快上涨可靠性提升却越来越有限。这个矛盾就是双目标规划存在的根本原因。我举一个直观的例子在某条关键馈线上加装分段开关能把故障隔离范围缩小一半SAIDI用户平均停电持续时间可能降低20%但需要增加几十万投资。如果你再加装一台联络开关可靠性可能只再提高3%成本却又要增加几十万。单目标规划只能选择一个方向优化要么做成成本最低要么做成可靠性最高可实际工程里需要的是用合理的成本获得可接受的可靠性这就要在多个候选方案里权衡。双目标优化的意义就在于它不直接给你一个最优解而是输出一组帕累托前沿——这条前沿上的每个方案都有一个特点想提高可靠性就必须接受成本上升反过来想省钱就必须接受可靠性下降。决策者可以根据手里的预算和供电可靠性考核指标在这条前沿上挑一个最合适的点。这个思路比传统的加权单目标更符合工程实际因为不同地区、不同负荷性质的可靠性需求差别很大城市核心区和高新区对停电时间极度敏感而乡村用户对投资成本更敏感。1.3 为什么选择Python而不是传统电力软件现在很多高校和设计院还在用MATLAB配合某些商业化电力分析工具做规划计算但我在实际项目里越来越倾向用Python。原因有三个第一Python的生态更适合做优化—评估耦合的循环流程。配电系统规划需要在优化算法里反复调用潮流计算和可靠性评估这是一个典型的外层搜索、内层评估结构。用numpy和scipy写这种循环非常顺手向量化之后速度不比MATLAB差而且代码更容易维护和扩展。第二Python的数据处理能力能大幅度提高前处理的效率。规划问题需要处理负荷数据、地理信息、元件参数、故障率数据pandas可以直接读Excel、CSV还能方便地合并和清洗数据。以前我用别的工具光整理数据就要花不少时间换成Python之后这部分工作顺畅很多。第三可视化能力和可复现性很重要。matplotlib加上plotly能很快画出系统单线图、帕累托前沿散点图、可靠性指标柱状图。给导师或者甲方汇报时有一张清晰的图比解释半小时公式都有用。而且Python代码的复现门槛低同一套代码在不同机器上跑只要环境一致结果完全可复现对科研和工程评审都很友好。2. 模型构建与数学化表达2.1 目标函数全寿命周期成本结构双目标规划的第一步是把两个目标量化。经济性目标我用的是全寿命周期成本LCC不只是一个简单的初始投资。LCC包含四个部分设备投资成本包括新增线路的单位长度造价、断路器/隔离开关的设备购置与安装费用、分布式电源的单位容量造价、储能系统的单位容量造价。运行维护成本设备投运后每年的运维费用一般按投资成本的比例系数估算分布式电源和储能的比例系数会比线路高不少。网损成本系统运行过程中在网络里损耗的电量对应的费用需要调用潮流计算结果把各支路损耗加起来再乘以电价。停电损失成本也就是可靠性目标对应的经济损失需要把系统年平均缺供电量乘以单位停电损失费用。这里有一个关键细节投资是一次性的而运维、网损、停电损失是逐年发生的不同年份的钱不能直接相加必须做等年值处理。例如把总投资折算到每年再叠加年运维、年网损、年停电损失费用这样才能让规划期内的总成本口径统一。我的代码里用了一个标准的等额分付资本回收系数把现值投资折算到每年公式是折算后的年投资费用 总投资成本 × r × (1r)^n / ((1r)^n - 1)其中r是贴现率n是规划年限。很多初学者在这个地方容易漏掉直接把投资和运行费用相加导致成本目标量纲不统一优化结果自然不对。可靠性的目标函数我选择的是系统平均缺供电量ENSEnergy Not Supplied。ENS是一个绝对量单位是千瓦时/年比SAIFI和SAIDI更适合做优化目标因为它既能反映停电的频率也能反映停电的深度和规模。可以用下面的思路理解为每次故障发生时由可靠性评估模块计算出受影响的负荷功率和停电时间两者相乘并累加起来就是该故障事件对ENS的贡献。优化算法在迭代过程中把所有规划方案的ENS都计算出来与LCC一起构成双目标向量用于非支配排序。2.2 可靠性评估指标体系与选择逻辑可靠性评估不能只盯一个指标。工程上通常会看四个指标系统平均停电频率指标SAIFI用户平均停电持续时间指标SAIDI系统平均缺供电量ENS以及用户平均停电持续时间指标CAIDI。它们之间的关系大体是SAIFI衡量停电频率SAIDI衡量每个用户在统计时间内平均停了多久ENS衡量总的少供了多少电量CAIDI则是SAIDI除以SAIFI反映每次停电平均持续多长时间。在这个项目里为什么优化目标选ENS而不是SAIDI我解释一下SAIDI侧重用户停电时长它对停电影响范围不敏感举个例子一个变电站故障导致100户停电5小时和一条分支线故障导致10户停电5小时SAIDI的贡献可能相差不大但实际经济损失差异巨大。ENS是功率×时间的累积量停电范围大、停电时间长ENS就大它天然能反映故障对供电量的实际影响跟经济性目标里的停电损失成本直接挂钩。所以用ENS做可靠性目标双目标之间的逻辑更统一——LCC代表花钱ENS代表缺电的实物量两者可以对应到同一个经济框架里。当然最终的规划结果展示不能只有ENS我还会把SAIFI、SAIDI、CAIDI都算出来放在结果表里。这样决策者跟上级部门汇报时既可以说这个方案每年能少缺供多少电也可以说用户平均停电时间降到多少分钟两种话语体系都覆盖了。2.3 约束条件的取舍与处理技巧规划模型不是把目标定好就能算还必须满足各种技术和安全约束。我在这套代码里重点实现了五类约束潮流平衡约束每个节点的注入功率和流出功率必须平衡这个靠调用潮流计算程序来校验而不是显式写出全部方程。节点电压上下限约束根据不同供电区域的标准一般设定在额定电压的±5%或±7%范围内。支路容量约束流过每条支路的电流不能超过载流量防止重载和过载。辐射状网络拓扑约束这是配电网的刚性要求混合系统接入分布式电源之后网络仍必须保持辐射状运行结构不能形成闭环导致保护复杂化。分布式电源渗透率约束分布式电源总容量不能超过系统最大负荷的一定比例避免出现大量倒送功率等不利情况。约束处理上我采用的是惩罚函数可行性修正混合策略。对于潮流计算直接能判断的电压越限、支路过载我在目标函数里加惩罚项对于拓扑约束在生成网络结构时就直接检查不符合的就丢弃该个体。为什么不在所有约束上都用惩罚函数因为拓扑约束如果用惩罚值去处理会出现大量非法个体占用计算资源的情况种群整体趋向可行域的速度很慢。而先硬性过滤拓扑再用惩罚处理电压和容量越限收敛效率会高很多。惩罚系数的取值也有一点讲究。如果惩罚系数太小约束破坏换来的目标值下降会让优化算法觉得值得最终结果就经常越限如果系数太大又会让目标函数值变得非常大导致算法过度保守很难找到边界解。我一般取每个目标数量级的一半作为初始惩罚系数然后根据结果微调这个参数不要一开始就拉到很大。3. Python实现的算法选型与代码设计3.1 多目标优化算法为什么是NSGA-II双目标优化看似复杂其实主流做法就是多目标进化算法。我选择NSGA-II而不是其他算法是因为它在双目标问题上兼顾了收敛性和分布性而且实现相对成熟不需要太复杂的公式推导就能在Python里写出来。NSGA-II的核心思路可以概括为三步非支配排序、拥挤度距离计算、精英保留策略。非支配排序负责把种群中的个体分成多个层级第一层是当前最优的帕累托前沿第二层次之以此类推。拥挤度距离则是为了保持解的多样性让前沿上的个体分布更均匀避免所有解挤在一个角落。精英保留策略保证父代里的好解不会因为交叉变异丢失下一代种群一定包含上一代的优秀个体。实际代码中一个关键点是交叉和变异算子的设计。规划问题里个体是混合编码的线路是否新建、开关是否装设这些用二进制位表示分布式电源的安装容量可能是离散档位也可以是连续实数。我在项目里用的是二进制编码用于拓扑选择、实数编码用于DG容量的混合表达。交叉时对二进制部分做单点交叉对实数部分做模拟二进制交叉SBX变异时二进制位做基本位变异实数部分做多项式变异。这种混合编码比统一用二进制或统一用实数都更贴近变量的物理属性。算法参数方面我建议种群规模N100~200迭代次数T100~200代。双目标问题不像高维多目标那么吃种群100个个体已经能画出比较完整的前沿迭代次数太多会拖慢速度太少则前沿会残缺。交叉概率取0.9、变异概率取0.1是比较稳妥的起点。如果帕累托前沿某段凹陷很明显优先调大种群规模而不是迭代次数——这个我在后面踩坑部分还会详细说。3.2 配电网潮流计算的Python实现思路优化算法每评估一个个体就要对当前规划方案下的配电系统做一次潮流计算找出节点电压和支路电流。配电网是辐射状结构采用前推回代法最合适。这个方法的思想很朴素回代是从末端往根节点推功率前推是从根节点往末端推电压反复迭代到前后两次电压差满足精度为止。用Python实现时我做了这样的模块划分# 定义配网拓扑数据类 class NetworkData: def __init__(self): self.branch [] # 每条支路的起点、终点、电阻、电抗、容量 self.bus_load [] # 每个节点的有功无功负荷 self.head_node 0 # 根节点编号 # 前推回代潮流函数 def power_flow(net: NetworkData): # 初始化节点电压向量 # 回代从末端向根节点累加支路功率 # 前推从根节点向末端更新节点电压 # 迭代判断电压偏差是否收敛 return voltage, branch_flow, network_loss这段代码看起来简单但里面有不少细节点需要注意。比如配电网节点编号和支路父子关系的构建必须唯一不能有孤岛再比如分布式电源在潮流计算里要作为PQ节点还是PV节点处理如果做PQ节点就直接把有功和无功放进节点注入功率里如果设备有无功调节能力可能需要更复杂的处理。我项目里默认把分布式电源和储能当作PQ节点给定有功出力和功率因数这样前推回代实现最简单也足够满足多数规划阶段的精度需求。向量化处理是提升潮流计算效率的关键一步。如果对于每条支路单独计算Python的循环开销会非常可观。把支路参数全部放进numpy数组用数组运算一次更新所有支路的功率和电压速度能快一个数量级。我在项目里实测过一个33节点的网络单次潮流计算从毫秒级下降到百微秒级优化循环里要调用上千次累积下来差距非常大。3.3 可靠性评估模块的两种实现路线可靠性评估模块是这套代码里最有分量的部分。我实现了两种方法状态枚举法和序贯蒙特卡洛模拟法。这里解释一下两者的适用场景。状态枚举法适合元件数量不太多、故障模式清晰的系统。它的思路是把系统中各个元件馈线、变压器、开关、分布式电源看作一个个可以故障的设备每个设备有故障率和修复时间。把所有可能发生的故障状态枚举出来逐一分析影响范围再按概率加权汇总成系统指标。比如系统里有一条线路故障率是0.2次/年平均修复时间5小时那这次故障每年预期发生0.2次每次影响若干负荷累加就能得到ENS的一部分贡献。当元件数量很多时枚举所有状态组合会爆炸所以状态枚举法更适合规划阶段的小型算例分析。序贯蒙特卡洛模拟法则更适合考虑时序特性的情况比如光伏出力随时间变化、储能充放电策略随状态变化。它的思路是模拟一个很长的时间过程比如8760小时一年根据每个元件的可靠性参数随机抽样故障发生时刻和修复时长在时间轴上演化整个系统状态最后统计全年的指标。这种方法灵活能考虑时变负荷和可再生能源出力的时序性但计算代价明显更大。在双目标优化的循环里我不建议每个个体都跑完整的序贯蒙特卡洛模拟而是先使用状态枚举法快速评估用来在优化过程中筛选方案等得到最终的帕累托前沿后再对少数几个推荐方案用序贯蒙特卡洛做精细校核。这种粗筛细校的策略能把可靠性评估的计算量控制在线性范围。如果反过来上来就用蒙特卡洛一次优化几千次评估每评估一次跑8760个小时的时序模拟代码可能要跑一整天。4. 实操过程与关键环节实现4.1 算例设置与数据准备我用经典的IEEE 33节点配电系统作为基础测试算例。这个系统包含33个节点、32条支路、1个变电站根节点系统总负荷大约5083j2547 kVA。它现在已经成为配电领域公认的标准测试系统参数在网上和很多论文里都能找到直接拿来做算法的验证和对比非常方便也方便读者复现结果。数据准备阶段要准备四类数据文件网络参数表节点编号、支路阻抗、负荷功率、节点类型、候选规划方案表可新建线路位置、可安装分布式电源的候选节点、可靠性参数表每条线路的故障率、故障修复时间、开关操作时间、经济参数表各类设备的单位造价、电价、贴现率、规划年限。在做数据清洗时我有个经验一定要把负荷数据的量纲统一。IEEE标准算例里负荷单位是kVA和kW经济参数里电价单位是元/千瓦时最后计算的能量单位是千瓦时/年如果在数据导入时没有统一单位算出来的成本可能偏差极大。我的做法是全部用pandas读入后马上做单位检查统一换算成标幺值或者有名值的同一量纲体系再交给优化程序。4.2 双目标优化的完整流程设计整套优化流程的顺序是这样的初始化种群生成N个随机规划方案每个方案对应一种线路增建组合和分布式电源配置组合。对每个个体进行拓扑校验检查方案是否满足辐射状网络要求不满足就重新生成或修复。调用潮流计算模块校验电压和容量约束同时得到网损成本。调用可靠性评估模块用状态枚举法计算ENS。计算两个目标值年化LCC、ENS放入种群。进行非支配排序和拥挤度距离计算。通过锦标赛选择、交叉、变异生成子代种群。合并父代和子代做精英保留生成新一代种群。重复步骤2~8直到达到最大迭代次数。输出最终帕累托前沿绘制散点图统计各方案的可靠性指标。这个流程里最容易被忽略的是第2步拓扑校验。很多代码实现没有这一层过滤导致优化算法在大量非法解里浪费时间甚至最终前沿里混入闭环网络方案。我在程序里直接用一个DFS深度优先搜索判断图是否满足辐射状连通条件不符合的个体直接不给评估机会这样能节省至少30%的无效计算。代码层面优化主体用一个类封装每个个体是类里的一个对象包含决策变量、目标值、拥挤度、支配层级这些属性。用类组织的好处是直观一个个体就是一个候选规划方案后期调试时你可以单独拎出某个个体去看它的目标值怎么来的不用在多个数组之间跳来跳去。4.3 可靠性评估模块的关键实现细节可靠性评估模块内部需要一个故障影响分析子程序这是整个项目正确性的基石。每次枚举一条线路故障我都要确定哪些负荷点受停电影响、影响多长时间、是否有分布式电源可以孤岛供电、联络开关是否能把负荷转移到相邻馈线。一个典型的处理流程是首先找出故障线路的位置并判断以该线路为边界哪些节点处于上游哪些处于下游。上游节点只要变电站侧正常工作通常不受影响下游负荷是否停电取决于故障点有没有分段开关可以隔离故障。如果没有分段开关下游全部失电停电时间等于故障修复时间。如果有分段开关故障段上游的分区可以通过开关动作快速恢复供电停电时间变为开关操作时间故障段本身则要等修复。如果网络中有联络开关且和相邻馈线有连接还可以把部分负荷通过联络转供出去转供负荷只经历操作时间没有经历完整修复时间。如果故障后存在分布式电源孤岛且孤岛内电源容量足够带起部分负荷则这部分负荷的停电时间更短或者不受影响。这个判断逻辑写起来不复杂但边界条件非常多。我建议用字典加集合的方式组织拓扑关系而不是只用数组因为故障隔离位置判断需要频繁查找父子关系和上下游节点集合。关于分布式电源在故障评估中的处理我发现一个容易出错的地方DG孤岛能不能成立取决于孤岛内DG容量是否大于孤岛负荷。如果小于那么这个孤岛依然要损失一部分负荷。代码里我不能只判断存在DG即恢复供电还要做容量匹配计算把差额负荷损失计入ENS。很多初版代码在这里估算偏乐观原因就是忽略了DG容量约束。4.4 代码性能优化从半小时提速到几分钟这套程序最大的性能瓶颈在优化迭代 × 可靠性评估的双重循环里。每评估一个个体都要遍历线路故障枚举如果一条馈线有32条支路每个个体就需要做32次故障影响分析。种群200个个体、迭代100代整体就是64万次故障分析如果每次分析都用低效的循环去扫描节点速度会非常难看。我做了三个层面的优化效果非常明显第一用numpy向量化替代纯Python循环。故障影响分析过程中节点上下游集合的判断可以用数组索引一次完成不再逐个节点遍历。第二把可靠性评估中不变的拓扑参数比如支路父子关系、分段开关位置提前计算好缓存起来每个个体评估时只需要修改变更后的部分而不是从头建立整棵拓扑树。规划阶段每次拓扑变化其实很小大部分网络结构是共享的。第三如果机器有多核可以用multiprocessing做并行评估。把种群个体分成多个批次用进程池并行跑潮流和可靠性计算。我这里试验过4个核的并行速度大约能提升3倍16核机器上速度提升更明显。不过要注意数据分割和结果汇总的编码细节不要多个进程之间共享可变对象。经过这套优化IEEE 33节点系统的一轮全过程优化从最初的接近40分钟降到大约5分钟完全在可接受范围内。5. 常见问题与排查技巧实录5.1 帕累托前沿分布很差怎么办帕累托前沿如果拧成了一个团或者集中在一个角落里最常见的原因是拥挤度距离没有生效。NSGA-II的拥挤度计算是为了让前沿上的解均匀分布如果附近解过于密集这个解的拥挤度距离就小在精英保留时更容易被淘汰。但如果代码里拥挤度距离计算有误算法就只收敛不分布所有解会堆到目标函数值比较接近的区域。排查方法也很直接打印几代种群的目标值分布看看是不是某一代开始所有个体聚集在某个小区间。如果是我建议先检查拥挤度距离的计算公式确认是否对目标函数做了归一化。如果不同目标数值量级差距过大LCC可能是几千万元ENS可能是几万千瓦时拥挤度距离会被大数值目标主导一定要先进行min-max归一化再做距离计算否则分布性一定受影响。另一个容易导致前沿残缺的问题是惩罚系数设置不当。如果停电损失成本在LCC里的占比太高优化算法会过于偏向低ENS方案整个前沿就缩到高成本端反过来如果惩罚系数里可靠性评估的权重太低成本优先方案会统治种群。这个平衡没有通用解要靠多跑几组参数观察前沿形状来调整。5.2 可靠性指标结果异常偏大或偏小怎么查可靠性评估结果偏大的常见原因是对故障影响范围的判断过于保守。比如明明有分段开关可以快速隔离故障但代码里没有正确实现开关动作的效果导致下游所有负荷都按修复时间停电ENS自然偏大。类似的联络结构如果转供能力判断错误也会高估停电电量。反过来结果偏小的常见原因前文提过在孤岛评估时忽略了DG容量小于孤岛负荷的情况以及开关拒动概率没有考虑。在规划阶段做方案对比不考虑开关拒动概率是可以接受的但如果在正式报告中要给出绝对可靠性数据就需要把保护开关的可靠动作概率纳入模型否则结果会偏乐观。我自己排查这类问题时习惯把某个具体的故障事件单独拿出来手算一遍和程序输出对比。比如指定支路5故障程序算出ENS贡献是某个数我手工按拓扑推一遍影响范围和停电时长很快就能发现是停电时间算错了还是影响节点集合判断错了。这个单事件对照法虽然笨但比漫无目的地改参数高效得多。5.3 潮流计算不收敛的几种典型原因前推回代法有时会不收敛最直接的表现是电压越限、网损出现负值、迭代次数达到上限。针对这个项目我遇到的案例主要有三类原因第一是网络参数里出现电抗远大于电阻的支路数据错误。配电网的特点是高阻低抗如果填写数据时电阻电抗颠倒了收敛性能会明显变差。第二是分布式电源接入了但容量设置过大导致部分节点电压严重越上限。这种情况潮流计算会不断震荡因为回代功率方向来回变化出现假性不收敛。解决办法是先检查DG容量设置是否在渗透率约束范围内再看节点的PQ设置是否有功为负。第三是拓扑结构出现了孤岛节点或者接触不良的串联不入网结构导致回代过程无法从末端向根节点汇聚。我在程序里加入了一个拓扑连通性校验函数任何时候构建新的个体之前都先调用一次能避免90%的潮流发散问题。提示调试潮流不收敛时先别急着调精度阈值大概率是数据或者拓扑的问题先确认这两点再考虑算法本身。5.4 运行时间长的线程级别优化心得整套代码跑完一次优化是一件事但实际工程里我要对比多个场景不同折扣率、不同负荷增长率、不同DG渗透率上限每个场景都要跑一轮完整规划。所以运行时长直接影响研究效率。除了前面说的向量化和多进程还有一个很有用的技巧是早期终止。在迭代初期种群的目标值离最终收敛状态很远如果此时就进行完整的可靠性评估其实是很浪费的。可以先在流程里用更粗糙的模型比如不考虑开关动作时间的简化评估快速算出一个大概的ENS用来做初筛当种群进化到中后期再把评估模型切换到精确状态枚举法。这个设计需要保证迭代中两次切换之间种群连续否则可能突然因目标值尺度变化导致排名振荡。保守一点的做法是前一半迭代用简化评估后一半全程用精确评估中间做一次对个体目标值的重新标定。我实测这种方式能再省掉大约20%~30%的总运行时间。结尾一点点个人的实操体会最后分享一个我在这套项目里最深的感觉写规划代码最大的坑往往不是算法公式写错了而是你以为模型对了、代码也对了但结果就是不合理。我在跑双目标优化时第一次拿到帕累托前沿图看到一个点上LCC很低但ENS也很低特别兴奋觉得找到了完美方案。后来仔细检查才发现这个个体其实违背了辐射状拓扑约束潮流和可靠性评估直接给了异常值两个指标都被人为压低看起来就是又便宜又可靠。所以我现在每次跑完优化都会随机抽几个前沿上的个体人工看一下它们的规划结果——线路增建在哪里、DG建没建、可靠性指标跟拓扑是否匹配。这一步虽然麻烦但能挡住一大半看起来正确的错误方案。如果你也想在这个方向继续深入我建议下一步可以扩充两个维度一是加入储能时序运行策略利用序贯蒙特卡洛模拟评估DG出力和负荷的时序匹配性二是把配电网重构运行阶段动态调整拓扑纳入规划阶段让经济性和可靠性目标在更真实的运行策略下得到评估。这两个方向都会让模型更贴近实际但代码复杂度也会上一个台阶值得预留足够的时间慢慢打磨。
