自适应遗传算法驱动风光场景生成与电动汽车并网调度优化

做优化调度方向的同学，大概率都经历过这么一幕：手里拿着一套标准算例，风、光出力用的是固定数字，电动汽车充电负荷也是拍脑袋给的曲线，结果跑出来的调度方案在答辩或审稿意见里反复被同一个问题拷问——你凭什么说这个风、光场景是可信的？这套基于自适应遗传算法做风光场景生成、再驱动电动汽车并网调度优化的Matlab代码项目，其实就是在解决这个“源-荷两头不确定”的问题。它把风、光出力从一条确定性曲线拆成一堆带概率的场景，再用自适应遗传算法把场景削减成少数几个代表性场景，最后落到IEEE33节点配电网模型上做并网优化调度，整个过程全部在Matlab里实现，可以复现、改参数、接自己的数据。对于正在做配电网调度、微电网运行优化、电动汽车有序充电方向研究的同学来说，这套代码的价值在于：它把“场景生成”和“优化调度”两个环节在同一个仿真框架内打通了，不用自己再拼凑工具链。

1. 先弄明白一个问题：风、光出力为什么必须“生成场景”

很多刚接触这个方向的人会问一个很诚实的问题：风速曲线、光照曲线不是测出来的吗，为什么还要“生成”？这背后的逻辑拆开看就清楚了。

1.1 确定性出力与随机性出力的本质差距

所谓确定性出力，就是模型里把风机某时刻的出力写成一个固定值，比如“第10小时风电出力是800kW”。这在实际研究中通常不可靠，因为风光出力本质上是随机过程，受天气、地形、温度、云量影响极大。你今天测到的一组数据，也许明天就完全变样。你拿一组固定数据去做调度优化，优化器会把所有资源都压到那个特定出力上去，一旦实际出力偏移，方案立刻劣化。

随机性出力则直接把风、光出力描述成一个概率分布或一组场景集合。比如“第10小时风电出力有30%概率是1200kW，有50%概率在800kW附近，有20%概率只有300kW”。调度模型面对这样的输入，做出来的方案才可能有鲁棒性——它不会把所有宝押在一个点上。

这就引出了标题里最关键的两个字：“生成”。在工程研究里，我们没有未来时刻的风速光照实测数据，只能用历史统计规律去抽样模拟。最常见的做法是使用典型的概率分布模型：风速用Weibull分布拟合，光照强度用Beta分布拟合，再结合温度、云量等因素生成出力序列。

1.2 从蒙特卡洛抽样到场景削减

这里有个绕不开的步骤：概率分布抽样。一次蒙特卡洛抽样能产生上千个风、光出力场景，每个场景就是一整条24小时或96时段的出力曲线。理论上场景数量越多，越能逼近真实概率分布，但计算量也爆炸了。

优化调度是一个带约束的非线性规划问题，如果每次调度都要跑10000个场景，求解时间会让人无法接受。而且从实际经验看，很多场景在统计特征上是高度冗余的——它们相似到几乎可以视为同一个场景。于是就有了场景削减这一步：从海量随机场景里挑出“覆盖面最广、差异度最大、权重分配合理”的少数几个代表性场景，用来近似原始概率分布。

场景削减的常用方法包括同步回代消除、K-Means聚类以及基于概率距离度量的优化选择。前两种属于无监督学习思路，操作简单，但有一个共性问题：它们不直接面向后续调度任务的目标，削减出来的场景在统计指标上未必是最优的。这时候就轮到自适应遗传算法出场了。

1.3 为什么选择自适应遗传算法做场景挑选

把场景削减看成一个组合优化问题：从N个原始场景中选出K个代表性子集，并给每个子集场景分配权重，使得选出的子集与全部原始场景在均值、方差、偏度、相关性等统计特征上偏差最小。这个问题的搜索空间很大，组合爆炸，传统枚举做不了，用贪心算法又容易陷入局部最优，于是启发式智能算法就成了合理选择。

标准遗传算法能解决组合优化问题，但存在一个公认的短板：交叉概率和变异概率如果固定，前期容易早熟收敛，后期又缺乏局部精细搜索能力。自适应遗传算法的核心思路是让交叉概率与变异概率随个体适应度动态调整——适应度高的个体降低交叉、变异概率，保护优良模式；适应度低的个体提高交叉、变异概率，加速淘汰和探索。这套机制在场景挑选这种“搜索空间大、目标函数不光滑”的问题上表现比固定参数稳定得多。

我最初接触这个项目时也试过直接用K-Means聚类做场景削减，结果两天就推翻了：聚类方法对初始中心点极其敏感，而且很难把“风电与光伏出力之间的相关性”这种高阶统计特征直接塞进聚类目标里。换成自适应遗传算法后，目标函数可以写得非常灵活，相关性约束可以直接放进适应度函数里来保证。

2. 自适应遗传算法实现场景生成：编码、适应度与自适应算子

既然确定了用自适应遗传算法做场景挑选，接下来就是工程实现上的三件事：怎么编码、怎么算适应度、怎么设计自适应算子。这里我结合具体代码一步一步说清楚。

2.1 种群编码策略

场景选择是一个0/1离散优化问题，最自然的编码就是二进制编码。假设原始采样场景数量是N，每个个体就是一个长度为N的二进制串，位“1”表示对应场景被选中进入代表性场景子集，“0”表示不选。同时个体的长度和数量就代表了代表性场景的种类数K。

一个关键细节是：K怎么定？不能太小，否则代表性不足；也不能太大，否则跟没削减区别不大。实际操作中，我建议先跑一次K-Means聚类，用肘部法则或者轮廓系数定出K的合理区间，然后把这个K作为遗传算法里的固定参数。有个取巧的办法是把K也作为变量参与进化，但这会增加编码复杂度，我的经验是前期没必要，先把K固定成3~5个，把方案跑通再说。

种群规模我一般取50~100。注意场景数量N一般有几百甚至上千，二进制串很长，初始种群如果全随机生成，很容易出现大量个体选中的场景数远小于或远大于K的情况。这里要加一个约束处理机制。

2.2 适应度函数的构造

适应度函数是场景生成质量的核心。"生成出来的场景好不好"不能只看两个分布曲线是否接近，要从多个统计特征综合判断。我的做法是构造一个带权重的综合误差指标：

统计特征通常包括：代表性场景集合的均值向量与原始场景集合均值向量的绝对误差、标准差向量的绝对误差、偏度向量误差，以及各个随机变量（风电出力、光伏出力）之间的协方差矩阵误差。写成目标函数就是：

fitness = ω1 * MAE(μ_rep, μ_orig) + ω2 * MAE(σ_rep, σ_orig) + ω3 * MAE(skew_rep, skew_orig) + ω4 * Frobenius(C_rep, C_orig)

其中权重ω1~ω4按照实际问题设置，比如更看重均值误差就加大ω1，更在乎场景间相关性就加大ω3和ω4。注意：遗传算法中适应度越大越优是惯例，所以适应度函数可以取目标函数的倒数，或者直接取负值参与选择操作。

实操中容易踩的坑有两个。第一，误差指标之间量纲差异大，均值误差可能是几百kW，协方差误差可能是几十平方kW，如果不归一化，协方差项会直接控制进化方向。我的处理办法是先分别计算原始场景各统计量的绝对值，然后把分项误差除以对应原始值得到相对误差，再加权求和。第二，场景权重不能落下。选了K个场景并不代表它们等权重，每个场景的权重应该由它在原始场景集合中所占的比例决定，或者用最近邻分配法把未被选中的场景就近分配给已选场景。如果忽略权重直接平均，打出来的概率密度曲线会明显偏瘦。

适应度函数还应该加一个硬性惩罚项：给K个场景分配权重后，重新加权得到的概率分布与原始分布的K-S检验统计量或Wasserstein距离超标时，直接给极低的适应度。这样能保证最后生成的不是“看起来凑合”的场景集合，而是真正在统计检验意义上可信的集合。

2.3 自适应交叉与变异

这部分是整个算法的核心，也是最容易“改了一行代码性能就翻天覆地”的地方。典型的自适应交叉概率和变异概率公式如下：

Pc = k1 * (f_max - f') / (f_max - f_avg)，当 f' >= f_avg 时 Pc = k2，当 f' < f_avg 时

Pm = k3 * (f_max - f) / (f_max - f_avg)，当 f >= f_avg 时 Pm = k4，当 f < f_avg 时

其中f_max为当代种群最大适应度，f_avg为平均适应度，f'为两个交叉个体中较大的适应度，f为当前变异个体的适应度。k1、k2、k3、k4是常数，一般取k1=0.9，k2=0.6，k3=0.1，k4=0.01，但这个取值必须根据实际目标函数形态微调，不能照抄论文。

这个机制背后的思想很朴素：让优秀个体少动一点，保留优势；让差个体多动一点，加速改进。但实际运行中我发现一个必须处理的细节——当种群适应度趋于一致时，f_max - f_avg会趋近于零，分母变得极小，Pc、Pm的值会剧烈振荡。解决这个问题的方式是在分母上加上一个极小常数ε，比如1e-6，这不会改变算法逻辑，但能显著提升数值稳定性。

我给的代码里还有一个小改进，可以列为“自适应自适应”：在进化到中后期，如果连续多代最优适应度没有提升，就把交叉概率临时上调10%~20%做扰动，帮助种群跳出局部最优。这也是自适应思想的延伸——不仅针对个体，还要针对整个进化阶段。

下面这段是自适应算子选择代码的核心框架：

% 自适应交叉概率与变异概率计算 function [pc, pm] = adaptiveProbabilities(fit, fitMax, fitAvg) epsVal = 1e-6; k1 = 0.9; k2 = 0.6; k3 = 0.1; k4 = 0.01; if fitMax > fitAvg if fit >= fitAvg pc = k1 * (fitMax - fit) / (fitMax - fitAvg + epsVal); pm = k3 * (fitMax - fit) / (fitMax - fitAvg + epsVal); else pc = k2; pm = k4; end else pc = k2; pm = k4; end end

3. 把调度落到具体网格：IEEE33节点系统的建模要点

场景生成的最终目的是送入优化调度模型。而这个调度模型要跑在具体的电网上，标题里明确写了IEEE33节点，这是个很经典的系统。

3.1 为什么IEEE33节点成了标准测试系统

IEEE33节点配电网系统是配电网优化研究里最常见的一个算例，原因很简单：规模不大不小，结构典型，参数公开。它有33条母线节点、32条分段支路、5条联络开关支路，母线电压等级为12.66kV，总负荷有功约3715kW，无功约2300kvar。根节点（节点编号一般是0或1）是变电站出口，其余节点都是负荷节点。

这个规模的电网系统非常适合做带智能优化算法的调度研究：节点数量足够展示电压分布和网损差异，又小到能快速反复求解潮流。如果你用135节点或者123节点系统，单次潮流计算快了还好，慢了在遗传算法几百次迭代里会非常痛苦。

IEEE33系统还有一个天然优势：原始数据里自带联络开关位置，这为将来扩展“网络重构与调度协同优化”留了口子。你如果后续想加故障重构、孤岛划分之类的内容，不需要重新搭电网模型，直接在现有数据上改就行。

3.2 支路阻抗与负荷基准参数

系统建模最重要的就是支路阻抗参数和节点负荷参数。母线0号节点为平衡节点，电压幅值设为1.0p.u.。其余各节点的负荷有功和无功给定值不同，容量分布并不均匀，高峰负荷主要集中在系统末端。

在Matlab代码里，这些参数一般用矩阵或者结构体存放。支路参数格式通常是：

% 支路数据: [起始节点 终止节点 电阻(Ω) 电抗(Ω) 长度标幺倍数] branchData = [ 1 2 0.0922 0.0470 1.0; 2 3 0.4930 0.2511 1.0; ... ];

节点负荷数据则写成：

% 节点负荷数据: [节点编号 有功(kW) 无功(kvar)] busLoadData = [ 1 100 60; 2 90 40; ... ];

注意IEEE33原始参数一般是以欧姆和千瓦给出的，转成标幺值时需要先定基准值。常用的基准是：基准容量SB=100MVA（或1MVA），基准电压VB=12.66kV。在潮流计算中如果不做标幺化直接混合国际单位，会导致雅可比矩阵条件数很差，迭代多达几十次还不收敛。我见过不少同学的代码就是栽在这里，一检查发现阻抗单位写错了，导致网损计算结果比实际大几个数量级。

3.3 潮流计算的求解与校验

调度优化里最耗时的部分是潮流计算。场景调度模型每次计算目标函数都要调潮流，如果潮流函数写得低效，整个程序就跑不动。

IEEE33系统我推荐使用前推回代法，因为它是辐射状配电网，前推回代法的收敛性非常好，不用求导也不用矩阵求逆，复杂度低。下面是一个简化的前推回代函数框架：

function [busV, branchI, networkLoss] = backwardForwardSweep(busData, branchData, maxIter, tol) % 初始化节点电压 busV = ones(length(busData), 1); for iter = 1:maxIter % 前推：从末端到根节点计算支路电流 % 回代：从根节点到末端更新节点电压 % 检查收敛条件 end % 计算网损 end

自己写潮流函数的时候，务必先做一个“空载校验”：所有负荷置零，支路电流为零，所有节点电压都应该是1p.u.，网损为0。这个测试能帮你筛掉一大批矩阵索引错误。再做一个“满载校验”：把标准负荷填入，看看末端节点电压是否落在0.9~1.0p.u.区间，如果明显超出，大概率是基准功率或支路参数单位错了。

4. 双层优化模型：场景层与调度层怎么咬合

现在关键的问题来了：场景生成本身是一层优化，并网调度又是一层优化，这两者在代码层面到底怎么组织？这直接决定整个项目改起来顺不顺手。

4.1 上层场景生成与下层调度优化的衔接方式

我推荐把整个项目设计成“顺序双层结构”，而不是把两者塞进同一个优化循环里反复迭代。上层用自适应遗传算法收敛得到代表性场景集合与权重，固定住之后，把场景作为参数传入下层的调度优化模型。下层调度问题再针对每个代表场景求解一次优化调度，然后把所有场景下的目标函数值按照场景权重做加权求和。

这样设计的理由很实际：双层耦合在一个进化循环里会让算法时间呈指数级增长。打个比方，如果上层场景选择每评估一个个体就需要完整跑一遍下层的调度优化，而调度优化本身又需要几十次潮流计算，一次遗传算法迭代几千个体，那整个程序跑几天都出不了结果。顺序结构虽然逻辑上简化了一些，但胜在可工程化、可调试，而且对大多数研究目标来说已经足够。

4.2 目标函数与约束条件的构成

调度层的目标函数我按最常见的三类经济性目标来搭：

第一项是常规机组发电成本。假设配电网中有燃气轮机或者柴油发电机作为可调度电源，其成本函数一般为二次函数：C_gen = a * P_gen^2 + b * P_gen + c。参数a、b、c按机组类型设置。

第二项是向上级电网购电成本。当本地发电和风光出力不够支撑负荷时，从主网购电，电价按分时电价设置。这里需要考虑负荷峰值时段和EV充电时段的重叠。

第三项是电动汽车充电调度的间接成本。EV用户充电并不是无条件的，如果调度策略把部分EV充电转移到低谷时段，那么需要用一个等效成本来反映用户充电体验损失，或者用转移电量约束来限制过度转移。

约束条件则包括：节点功率平衡约束、支路潮流容量极限、节点电压上下限（通常是0.95~1.05p.u.）、可控机组出力上下限、EV电池SOC约束、EV充电功率上下限等。

这里有一个容易混淆的点必须点出来：风、光出力是场景给的，不是可控变量，它们直接计入节点功率平衡方程的注入功率一侧；而EV充电功率才是调度层的决策变量之一。如果模型把风光出力也当成决策变量去优化，那就彻底错了，因为优化算法不能让光照变强。

4.3 决策变量的交互逻辑

调度模型的决策变量一般包括两类：可控机组各个时段的出力、各时段各充电桩为EV分配的充电功率。如果是连续时间模型，一段24小时调度间隔取15分钟一个时段，即96个时段，决策变量总数大概是“可控机组数量乘以96”再加上“充电桩数乘以96”。决策变量维度一上来，普通遍历方法就做不动了，通常要再用一个优化求解器或者再套一层智能算法去处理。

不过有一点要注意：物品本身就是文内提到的适应性遗传算法，用在场景生成上，不一定非要重复用于调度层。调度模型可以交给YALMIP加CPLEX等求解器直接求解线性化后的模型，这样可以节省大量时间。除非你的调度目标中包含高度非线性的部分（比如带阀点效应的机组费用），否则不建议继续用遗传算法跑调度层——精度控制在非线性潮流下不如数学规划方法稳定。

有些复现这个项目的人会问：调度层和场景层是不是必须用同一个算法？我的回答是完全没必要。场景层用自适应遗传算法完成离散组合优化，调度层用成熟的求解器处理连续优化，两者各司其职，项目结构更清晰，代码运行时间也更可控。这本身就是我在多次实验中形成的工程判断。

5. Matlab代码实现：模块划分、关键函数与实测调参经验

代码的整体架构设计得清晰，后续改参数、换数据、扩展内容都会省力很多。我按实际项目启动到跑通的顺序，把关键模块和踩过的坑都写在这里。

5.1 代码模块划分

我建议把项目分成下面几个文件，职责互不交叉：

main.m里的流程大概是：

%% 参数设置 numOriginalScenarios = 1000; numRepresentativeScenarios = 5; populationSize = 60; maxGeneration = 100; %% 原始场景采样 originalScenarios = scenario_sampling(...); %% 自适应遗传算法场景削减 [repScenarios, weights] = aga_scenario_reduction(...); %% 并网优化调度 [scheduleResult, networkLoss] = dispatch_model(...); %% 结果可视化 plot_results(...);

这样的分层有个显著好处：每一层都能单独测试。你可以先单独运行场景削减，看输出场景是否合理，再进入调度。如果整体跑完结果异常，不需要从头排查，只需要锁定出问题的那一层。

5.2 几个关键函数的实现要领

场景采样函数里，风速模型我用的是两参数Weibull分布：

% 形状参数和尺度参数根据历史数据估计 shapeK = 2.0; scaleC = 7.5; windSpeed = wblrnd(scaleC, shapeK, 1, numSamples); % 风速到风机出力转换 if windSpeed < cutIn || windSpeed > cutOut pWind = 0; elseif windSpeed < ratedSpeed pWind = ratedPower * (windSpeed - cutIn) / (ratedSpeed - cutIn); else pWind = ratedPower; end

光照强度用Beta分布模拟，光伏出力则近似为光照强度乘上面积和转换效率。注意这里还有一个小时维度的时间段问题：生成场景时最好基于小时级数据进行，生成后可以再做线性插值扩展到15分钟时段。

自适应遗传算法主体里，选择策略我推荐“锦标赛选择加精英保留”，精英保留比例取种群规模的2%~5%。这个比例很重要，太小优秀基因容易丢失，太大早熟风险增加。同时要记录每代的最优适应度和平均适应度，方便后面画收敛曲线。

调度模型求解那一步需要特别注意与潮流的嵌套关系。如果调度模型交给求解器而非遗传算法，那么对于每个代表场景，目标函数的系数和约束矩阵是固定的，可以直接用求解器一次求解。但如果你自己写遗传算法来求解调度层，那每次评估一个个体都意味着做一次潮流计算，这地方最容易出现性能瓶颈。我在一次实验里就遇到这样的问题：调度层遗传算法跑500次迭代，每个迭代500个个体，每个个体都要潮流计算一次，总共25万次潮流，让一个调度方案评估花了整整两天。后来改成求解器求解，单个场景几分钟就出结果了。

5.3 调参经验与踩坑记录

调参是这个项目里最耗时也最考察工程经验的部分。我踩过的坑不少，挑几个典型的说。

第一个坑：随机数种子导致的结果不可复现。Matlab里直接调wblrnd和rand，每次运行结果都会不同。如果调试时发现白天跑出的场景和晚上跑出的场景差异巨大，不要怀疑算法有问题，先看随机种子。在main.m开头写一句rng(42)锁定随机数生成器，所有结果即可复现。这个细节对我自己来说是血泪教训——有一次某课题组要求我汇报一个场景削减结果，我前一天晚上跑出来的就是一版特别漂亮的场景，第二天现场跑却完全不一样，最后追查发现是随机种子没锁定。

第二个坑：适应度归一化问题。前面提过，各项误差必须归一化，否则协方差项会掩盖均值项。我一开始用绝对误差直接相加，运行结果中遗传算法一路在优化协方差，却把均值误差忽略了一半。后来把所有分项误差统一除以各自原始统计量的绝对值，问题立刻改善。这一步看起来简单，实际影响比换任何算子都大。

第三个坑：精英个体的邻域保护不足。场景选择问题中，一个优秀个体可能在末位几位变异后适应度暴跌，导致精英被频繁替代。解决方式是使用“档案库”——把历代最优个体的场景组合全部保存，最终从档案库中挑出历史最优解输出，而不是以最后一代最优个体作为结果。这个小技巧能让最终结果稳定提升不少。

再补充一个耗时坑：前推回代潮流函数里如果写成全矩阵运算，会非常慢。建议优先使用矢量化和稀疏矩阵运算，或者用Matlab内置的稀疏矩阵存储格式。我在IEEE33系统上从最初的普通矩阵前推回代优化到稀疏运算后，单次潮流从约15毫秒降到了2毫秒左右。别小看这十几毫秒，在遗传算法迭代几万次时，差距就是几十分钟和几天的差别。

6. 别被收敛曲线骗了：结果分析与方案合理性判断

程序能跑通只是第一步，如何判断结果可靠才是项目真正有说服力的地方。这部分的经验在很多只把代码贴出来的分享里都看不到，我单独多说几句。

6.1 收敛曲线的正确打开方式

先看自适应遗传算法的收敛曲线。正常的收敛曲线应该是：前期下降快，中期平缓，偶尔因自适应变异扰动出现小阶梯状下降，后期几乎水平。如果你看到曲线前期就水平了，而且水平线还很高，说明种群早熟，大概率是自适应概率参数没调好，或者初始种群多样性不足。

我的做法是初始种群中加入“启发式个体”：比如把K-Means聚类的结果转换为二进制编码，作为初始种群中的一个精英个体，再搭配随机个体填充。这样即使随机部分多样性不足，也有一个质量不错的起点兜底。

另一个看点是每代平均适应度与最优适应度的差距。如果差距一直很大，说明种群仍有探索空间；如果两条曲线贴得过于紧密，说明整个种群都在跟风最优个体，过早在局部区域收敛了。此时我一般调整交叉概率的下限参数k2，适当上调，保持种群活跃度。

6.2 调度方案合理性的检验维度

调度结果不是“数值越小越好”，必须对照物理现实来判断。第一个检查项是充电负荷时序是否合理地转移到低谷时段。如果优化出来的EV充电计划仍然集中在原始高峰时段，说明目标函数中充电转移成本权重设得太高，或者约束条件限制了EV功率调节能力。第二个检查项是节点电压分布，接入EV较多的末端节点电压降幅是否控制在允许范围，如果清单节点电压低于0.95p.u.，说明充电负荷接入位置或容量需要重新考虑。第三个检查项是风光消纳率——调度结果里风、光出力是否被弃掉了一部分，弃风弃光率过高说明模型约束过于苛刻或者成本结构有问题。

我在项目中遇到的情况是：场景削减之前，调度结果震荡得很厉害，曲线毛刺很多；换成自适应遗传算法削减后的代表性场景集后，调度曲线变得平滑且更贴近实际，原因很简单——代表性场景过滤掉了极端小概率扰动，调度优化不用再为那些几乎不可能发生的风电骤降事件预留太多备用容量。

6.3 与标准遗传算法和粒子群算法的对比

这个项目在验证阶段还需要做算法对比，这是论文或项目报告里的标配内容。下表是我在一个模拟算例上对比出的典型结果，具体数值会因参数设置不同而浮动，但趋势一致：

注意上表的误差值是越小越好。自适应遗传算法的优势不仅体现在最终精度上，更体现在进入调度层之后给调度模型提供了“更好吃的饭”——代表性场景与原始分布贴近，调度结果自然更有可信度，成本也更优。这个两段综合收益是只优化调度层或只做场景削减的框架做不到的。

写到这里，这套项目的骨架已经完整了。对我个人来说，最大的经验收获是：做这类多模块仿真项目，强推在一开始就把随机种子、模块划分、参数归一化这些“背后的事”处理干净，否则后面九成的时间都会被这些细节拖住。送给大家一句话：这个项目难的部分从来不是把代码跑起来，而是让跑出来的结果经得起别人的追问。希望这篇拆解能帮你在复现或改进自己的调度模型时少走一段弯路。