混合配电系统规划：经济性与可靠性的多目标优化与Python实现

1. 这个课题到底在算什么混合配电系统规划问题的本质这几年做配电网方向的研究和工程落地绕不开一个高频课题混合配电系统规划。我最早接触这类项目时也犯过不少想当然的错误这里先把问题的本质讲透后面每一段内容都是基于实际项目中的模型搭建和Python实现过程。所谓混合配电系统目前比较通行的理解是配电网中同时接入多类资源比如分布式光伏、风电、储能、电动汽车充放电设施甚至冷热电联供彼此在能量流和管理边界上互相耦合。规划问题就是在给定的配电网络拓扑上决定这些分布式资源在哪里装、装多大容量、要不要新建联络开关、是否需要升级馈线从而在满足运行约束的前提下让年综合费用尽量低同时让系统的供电可靠性尽量高。这两个目标往往互相撕扯多装储能和分布式电源投资运维成本上去了但停电概率和缺供电量下来了少装设备经济性好了可靠性可能跌得没法看。显然这不是一个单目标优化能回答的问题。很多人拿到课题后的第一反应是从可靠性评估开始先写出一个蒙特卡洛仿真的Python脚本跑出系统平均停电时间然后再去套优化。我最初也走了这个顺序结果发现后面接口对不上可靠性模型和规划模型用两套数据结构潮流计算和故障模拟之间没有统一的网络描述最后整个项目推倒重来。后来想明白这类研究的正确起点是先回答三个问题决策变量是什么——分布式资源的选址定容、馈线升级的型号选择、开关位置与拓扑变更策略目标函数怎么量化——经济性用等年值成本包括投资、运维、网损和停电损失可靠性用SAIFI、SAIDI、EENS等指标两个目标之间怎么折中处理——是统一货币化还是生成帕累托前沿。这个课题的典型算例是IEEE 33节点或IEEE 69节点配电网节点规模不大但麻雀虽小五脏俱全联络开关、支路潮流、分布式电源和储能、时序负荷都齐了。我在项目里选用Python做实现原因很简单pymoo这样的进化算法库成熟numpy和pandas做数据计算方便matplotlib画帕累托前沿直观而且和后续的可靠性仿真循环写成一套代码不会出现多语言互相调用的麻烦。1.1 为什么非要把经济性和可靠性放在一个框架里有些文献会把可靠性作为约束处理比如设定一个SAIFI上限值然后优化经济性。这种做法在工程上可行但存在一个隐患可靠性目标很难先验地给定一个合理阈值。你拍一个5次/年还是3次/年背后是没有经济权衡的。配电公司真正关心的是多花多少钱、换来多少停电损失的减少这本质上是一个性价比问题。把EENS换算成期望缺供电量成本后虽然可以并入经济性目标但单位停电成本在不同用户类型之间差异极大居民用户和工商业用户的停电损失可能相差一个数量级统一折算容易被质疑。所以我在项目里保留双目标结构用帕累托前沿把投资方和用户侧的权衡显式呈现出来再由决策者在全套非劣解里选点。这是比较稳妥的做法。1.2 混合系统中潮流与可靠性评估的耦合细节混合配电网的特性会让传统可靠性评估方法失效。例如储能参与调峰后某些时段馈线负载率很低N-1故障情况下可能不需要负荷削减就能转供成功而光伏大发时段又可能造成反向潮流保护整定要重新考虑。用静态负荷和恒定潮流去算可靠性结果偏差很大。我在实现中采用时序模拟的思路把8760小时或典型日场景逐小时展开储能SOC和DG出力随场景变化再逐时点做潮流校验。这样可靠性评估的输入不是一个潮流断面而是全年/典型周的动态序列评估结果才具备工程参考价值。2. 经济性模型的成本拆解与目标函数构造经济性目标如果只算设备购买费用那这个模型基本没法用于规划决策。实际项目中我需要把账算到“全寿命周期等年值”的尺度上。所有成本按等年值法折算避免不同寿命设备之间的比较失真。光伏组件寿命25年储能电池10到15年变压器和馈线可能30年以上不折算到年值优化算法很容易被前期投资大但长期收益低的方案带偏。2.1 总投资成本、运行成本和停电损失成本的计算口径目标函数取年综合费用最小值用标准形式表示为[ \min \quad C_{\text{total}} C_{\text{inv}} C_{\text{om}} C_{\text{loss}} C_{\text{ens}} ]各部分在Python里的计算方式如下投资成本等年值 ( C_{\text{inv}} \sum_{i} (C_{\text{unit},i} \cdot S_i ) \cdot \frac{r(1r)^{Y_i}}{(1r)^{Y_i}-1} )其中 ( S_i ) 是安装容量或数量( Y_i ) 是设备寿命( r ) 是折现率。这个公式在很多论文里直接出现但实际计算时要注意多个项目的 ( Y_i ) 不一致时必须分别折现再加总不能把总投资的加权平均寿命代进去误差会很大。运维成本 ( C_{\text{om}} ) 通常按投资成本的比例估算光伏取1%到2%储能取2%到3%或者按每千瓦时处理电量单独计费。我习惯把储能运维拆成两部分固定比例加循环次数相关的磨损成本因为在优化中储能充放电策略会显著改变运行成本固定比例法会低估运行差异。网损成本 ( C_{\text{loss}} ) 来自时序潮流计算各时段支路损耗乘以对应时段电价再累加。这里可以稍作简化不用8760个小时全跑潮流用典型日乘以权重折算能省大量计算时间规划阶段精度完全够。停电损失成本 ( C_{\text{ens}} ) EENS × 单位停电成本这个在双目标模型里要特别处理。我是保留EENS作为一个独立目标同时计算一个按单位停电成本折算后的停电损失放到经济性目标里作为辅助参考这样一方面保证帕累托前沿的两维正交性另一方面决策者能看到货币化停电成本后方案是否划算。2.2 约束条件中经常被忽略的几类约束写不全优化结果看着漂亮实际工程一对接就要出问题。我在文献复现和项目实践中整理出的关键约束包括以下这些约束类型数学表达要点常见遗漏点潮流约束DistFlow分支潮流方程忽略反向潮流、储能充放电两种状态下的潮流变化电压约束节点电压上下限不同馈线末端的电压偏差差异按区域设限支路容量电流/有功流上限夏季和冬季载流量不同储能SOC约束充放电深度、SOC边界忽略循环寿命对SOC上下限的约束辐射状拓扑图论约束混合系统接入多联络开关后的环网校验DG渗透率总装机不超过最大负荷的一定比例忽略单点接入容量的上限最容易犯的错是储能SOC建模。连续时间表达式里的SOC边界看起来简单但时序模拟时SOC在充放电切换瞬间的连续性很容易算漏。我在初版代码里就吃过这个亏优化算法给出一个储能方案可靠性仿真时SOC从0.2跳变到0.9充放电功率和电量对不上EENS算出来异常偏低。后来用逐时递推公式强制校验能量平衡并增加惩罚项处理不可行解才算稳下来。3. 可靠性评估的工程化落地指标、蒙特卡洛与潮流校验可靠性评估这个模块是所有环节里最好写但最难写对的。简单做法是抽样故障元件、累加停电时间和停电电量复杂做法要区分故障类型、保护动作逻辑、开关操作时序、DG孤岛运行可能性。我的项目选择一处居中的复杂度非序贯蒙特卡洛模拟为骨架时序负荷和时序DG出力为输入故障后潮流校验来判定是否真的停电。3.1 可靠性指标怎么选如何和规划目标衔接规划层面常用的指标有三个系统平均停电频率指标SAIFI、系统平均停电持续时间指标SAIDI、期望缺供电量EENS。SAIFI体现频次SAIDI体现时长EENS体现电量维度的严重程度。前两个是传统配电网考核指标EENS是规划经济性分析中更核心的量因为它可以直接和停电成本挂钩。我在结果输出中三者都算但在双目标优化时只用EENS作为可靠性目标原因是SAIFI和SAIDI无法反映负荷大小差异一个不重要支路停电和一个主干线停电对用户的绝对影响完全不同EENS则天然带权重。指标计算遵循以下逻辑对每一条支路、每一台变压器和每一段母线上的元件按故障率 λ 和时间序列的随机抽样确定故障状态。每次故障发生后通过潮流计算判断是否有节点电压越限或支路过载如果有按削减策略逐步切除负荷至潮流可行最后统计被削减的负荷量和持续时间。Python代码里我按如下框架组织def simulate_year(components, loads, dg, storage, network): total_energy_not_supplied 0.0 total_outage_time 0.0 total_outage_count 0 for comp in components: if comp.fail(): duration comp.repair_time() curtailed lf_with_curtailment(network, loads, dg, storage) total_energy_not_supplied curtailed * duration # 统计逻辑... return saifi, saidi, eens逐元件独立抽样在数学上没问题前提是假设元件故障相互独立。对同一杆塔上的多回线路、同一变电站母线进线独立性假设可能不成立实际工程数据里这些元件往往关联故障。作为研究项目我在文末会备注这一假设条件。3.2 故障后的负荷削减策略前推回代潮流与切负荷故障后的潮流校验是整个可靠性评估里最坑的环节。IEEE 33节点这类系统故障后负荷转供路径有限若联络开关容量不足或对侧馈线无法承担全部负荷就需要按优先级削减负荷。我的实现是这样的先用DistFlow前推回代法解故障后的潮流如果存在电压越限或支路过载则按负荷重要程度从低到高逐步切除节点负荷每切一次重新跑潮流直到约束满足或全部切完。这个过程和N-1校验的程序逻辑是同一套代码规划出来的网架是否满足N-1在故障模拟循环里自动检验。对于时序模型还要处理的是故障发生时刻的DG出力和储能SOC状态。比如光伏在夜间出力为零若故障发生在夜间DG对削减负荷的帮助是零储能剩余电量不足时即使容量很大也只能带很小的负荷。把这些写进模拟后EENS和SAIDI的值会比用恒定高峰负荷计算的经典结果高出不少也更接近真实运维数据。3.3 模拟次数与收敛判据的设定非序贯蒙特卡洛的收敛性是我最关心的。元件故障概率低故障率极低的元件在短时间内根本不会抽到故障指标波动很大。在项目里我采用批次模拟并监控EENS的变异系数每5000次抽样统计一次当变异系数小于0.05时停止。这个方法来自工程统计学常用做法远比拍脑袋定十万次要可靠。实测下来IEEE 33节点、38条支路的系统大约需要3万到5万次抽样才能稳定。抽样次数太少优化算法会把噪声当成目标改进进而选出错误的方案。4. 优化求解框架NSGA-II加熵权TOPSIS的取舍求解双目标优化问题传统做法是加权求和但在配电系统规划里经济性和可靠性的量纲不同权重系数非常主观。我试过用ε约束法把EENS转成约束也试过加权法最终稳定使用的是NSGA-II生成帕累托前沿再用熵权TOPSIS从前沿中挑推荐方案。理由如下。4.1 为什么帕累托前沿优于单一权重组合权重求和时一个很大的问题是前沿形状会直接影响权重选择的敏感度。如果两个目标的数量级差距大小权重目标的改进完全被淹没。EENS的单位是兆瓦时投资成本是万元量纲差异极大加权结果基本等于只优化投资成本。而NSGA-II的多目标排序机制不依赖量纲个体之间的支配关系由两个目标向量本身决定。我用pymoo库实现种群100、迭代200代在33节点系统上大概一两个小时可以收敛。真实感受是这个求解时间勉强可以接受但系统节点加到100以上后需要把可靠性评估的蒙特卡洛循环做轻重分离否则单次优化要跑好几天。4.2 决策变量的编码方式和约束处理决策变量包括DG的接入位置和容量、储能的功率和容量、联络开关的组合。pymoo默认的连续变量对选址问题不太友好我采用混合编码接入位置用整数编号容量用连续变量开关状态用二进制。这在pymoo里需要继承ElementwiseProblem类自定义变量类型。约束处理上辐射状拓扑和潮流可行域这类非线性约束直接用惩罚函数加到目标函数里比硬性裁剪要稳定得多。class DistPlanProblem(ElementwiseProblem): def __init__(self, network_data): super().__init__( n_varparse_variables(network_data), n_obj2, xllower_bounds, xuupper_bounds, vtypefloat ) def _evaluate(self, X, out): plan decode(X) cost annual_cost(plan) eens evaluate_reliability(plan) penalty topology_penalty(plan) out[F] [cost penalty, eens penalty]这个框架的好处是后续换算法只要改solver配置模型接口不用动。我从deap转到pymoo的原因也是看中它内置了NSGA-II、NSGA-III、RVEASA等多种算法比较研究起来方便。4.3 帕累托前沿的折中决策熵权TOPSIS的计算路径生成前沿后不是直接把帕累托解交给工程方就完事了。现实中决策者需要的是一个推荐方案。熵权TOPSIS是我用过比较稳的手法。计算路径分几步将帕累托解的经济性成本和EENS做归一化消除量纲后计算信息熵由信息熵确定两个指标的客观权重最后按理想解和负理想解的欧式距离排序。为什么要用熵权而不是主观赋权因为在项目阶段业主方往往说不清“经济性到底比可靠性重要多少”用数据本身的信息量来决定权重至少提供一个可解释的客观基准。这套代码不到100行numpy就能完成性价比非常高。5. Python代码实现的主干结构从算例数据到结果输出整套代码我控制在2500行左右分为数据模型、潮流计算模块、可靠性仿真模块、优化模块、结果后处理模块。下面把这个结构的核心骨架和设计思路讲清楚。5.1 数据结构与算例导入方式节点和支路的基本属性用Python类表示比直接用字典要清晰得多后续给类增加方法也方便。Class内存储额定电压、负荷、DG接入量、支路阻抗等。对于IEEE 33节点的标准参数我直接把支路参数表和节点负荷表写入CSV文件代码启动时读取这样更换算例不用改代码。class Bus: def __init__(self, bus_id, load_kw, load_kvar, v_base12.66): self.id bus_id self.load_kw load_kw self.load_kvar load_kvar self.p_dg 0.0 self.q_dg 0.0 self.voltage v_base class Branch: def __init__(self, fb, tb, r, x, cap): self.fb, self.tb, self.r, self.x, self.cap fb, tb, r, x, cap储能和DG另外单独建类运行时把规划方案里的决策变量映射到对应节点上。这个映射关系是整个程序中最容易出错的地方因为优化算法输出的变量顺序和节点编号不一定一致。我花了一晚上调试最终发现是变量索引映射偏移了一位导致DG配置到了完全不同的节点上。后来统一用一个解析函数管理变量到对象的映射输出时再对同一份数据做反向栓核。5.2 可靠性评估函数的设计边界可靠性评估函数只负责给定一个规划方案返回SAIFI、SAIDI和EENS。函数签名要设计成和优化器解耦接收的是一个已解码的方案对象内部完成时序负荷生成、元件故障抽样、潮流校验和统计。这个函数不感知自己在优化循环内还是单独做评估。一个关键的性能优化点是所有蒙特卡洛抽样中元件状态矩阵可以预先向量化生成。故障率低的元件每次抽样绝大多数是正常状态。把元件状态按年份生成一个布尔矩阵故障年份里才执行潮流计算能减少90%以上的无效计算。我在初版代码里用for循环逐支路判断跑一次评估就要十几秒优化200代后根本无法收尾。向量化之后单次评估降到1秒左右整个优化流程才算工程可行。5.3 结果输出和帕累托前沿可视化优化结束后输出三部分内容帕累托前沿数据表、前沿图和推荐方案的详细配置清单。前沿图用matplotlib画成二维散点图横轴为年综合费用纵轴为EENS标出熵权TOPSIS选出的推荐点。这个图在论文和项目报告中都很常用也是我判断算法是否收敛的最直观方式——前沿形态如果持续变化说明迭代还没稳定。另外我还会输出推荐方案的逐节点配置表、各成本分项占比、可靠性指标明细这样业主方拿到的不是一张空泛的帕累托图而是可以直接用来做施工图设计的输入。这个细节对项目交付非常重要。6. 调试与避坑我在复现过程中踩过的五个实际问题这部分内容价值比较高因为文献里通常只给结论不会告诉你中间的坑。我按问题类型、触发现象、根因分析和解决路径四个维度整理成表方便后面做类似课题的人直接对照。问题症状根因解决路径潮流不收敛迭代次数超限电压振荡DG接入后PV节点处理不当检查DG无功控制方式改用PQ恒功率建模EENS波动剧烈前后两次评估结果相差30%抽样次数不足低故障率元件未被抽到引入变异系数收敛判据动态增加抽样数量优化结果和单次验证偏差大推荐方案复评时另一个目标异常优化内评估样本数少于复评优化时用代理样本最终方案单独大样本复评变量映射错位爬坡曲线正常但DG位置明显不合理决策变量索引和节点编号错位统一映射函数输出时反向校验时序上SOC不连续储能充放能量不守恒逐时递推的SOC更新被跳过了强制逐小时更新并校验能量平衡每个问题背后都能讲出一个具体的调试故事这里挑两个最值得说的展开。6.1 潮流不收敛分布式电源的无功建模坑最初我在故障后潮流计算中把所有DG都建模为PQ节点结果光伏的注入功率和负荷比例达到一定水平后前推回代法出现了电压振荡迭代几十次不收敛。排查下来发现问题是这样的前推回代法本身适合放射状网络但分布式电源在故障后转供路径发生变化时原来的拓扑结构可能形成弱环。弱环情况下不加处理的前推回代法需要指定一个环网断开点否则计算无解。模拟故障转供时我直接沿联络开关闭合后的路径做了潮流计算没有在计算前先对网络做拓扑重构判断。后来加了一个环节潮流计算前先检查是否存在环路有环路的用节点撕裂法把环网变成两棵放射状树后再计算。这一步把不收敛问题解决了90%。剩下10%出现在DG输出超过局部消纳能力时属于优化过程中的不可行解交给惩罚函数处理。6.2 EENS结果波动大的根因低故障率元件的抽样偏见故障率最低的元件是电缆线路每百公里每年可能只有几次故障。如果蒙特卡洛抽样总次数只有一万次这条线路几乎永远抽不到故障但一旦抽到带来的停电电量可能是其他元件的几十倍。这种“偶发大数字”会让EENS的统计均值出现阶梯跳变。我用变异系数作为收敛判据之后抽样次数自动从两万调整到五万结果才算平稳。更进一步的改进是采用重要抽样法对低故障率元件做概率提升并在统计时回退权重但代码复杂度显著增加作为规划研究的学术项目没必要追求到这个程度。6.3 优化与评估解耦怎么压缩上百小时的求解时间最能劝退外行的问题在于时序蒙特卡洛和NSGA-II结合后计算量爆炸。单个方案可靠性评估2秒种群100迭代200代就是4万次评估对应8万秒超过22小时。实际项目里不可能等这么久。我用了三个加速手段叠加优化迭代中每次评估只跑5000次抽样结果必然有噪声但NSGA-II对噪声的鲁棒性其实比预期好因为排序时轻微波动不会改变大多数个体之间的支配关系终局阶段选出帕累托前沿后再对前沿上的非劣解做一次50000次抽样的大样本复评保证最终结果可信对公共场景数据负荷曲线、光伏出力序列全局只生成一次所有评估共用避免重复随机数序列带来的额外方差。这个方案实测可以把总耗时压缩到4到5小时且最终推荐方案和全精度计算的结果差异在5%以内。工业项目的做法还可以走并行化把每个个体的评估分配到多核进程上但这不是本课题必选项。7. 基于算例的研究结论与实际体会这个项目最终在IEEE 33节点算例上形成了可复现的模型闭环。从结果看一个典型的模式是纯经济最优方案往往在DG渗透率15%左右达到极值再往上加装光伏只会推高投资成本但减少的EENS有限而可靠性最优方案会把储能容量配置得偏高导致年费用大幅上升。帕累托前沿上存在一个拐点区域在这个区域里增加少量投资可以换得明显的可靠性改善超出拐点后投入产出比急剧下降。熵权TOPSIS选出的推荐方案恰恰落在拐点附近这也验证了双目标优化比单目标加权更贴合真实工程决策。我在实际运行中的体会是这个课题成败的关键不在数学模型有多精致而在三个模块之间的接口是否稳定。很多毕业设计和横向项目做不下去不是算法不行而是规划方案和可靠性仿真之间的数据传递经常出错优化算法花了大量算力在评估不可行解上。先把小算例闭环跑通再用Python的模块化结构逐层增加复杂度这条路径比一开始就堆完整技术栈要稳得多。最后再分享一个实操建议把每个方案的关键中间量都输出到日志文件尤其是各成本分项和EENS分元件统计。调试时你会感谢自己保留了这些现场数据因为优化算法给出的异常方案往往只有靠分解量才能定位是潮流越限、SOC违反还是故障抽样噪声导致的问题。这个习惯我保持了好几个项目省下的排查时间远比多写几十行日志的成本划算。