简介电力系统机组组合优化调度是运行管理中的核心问题需要在满足负荷需求的前提下合理安排机组启停状态与功率分配。这份资料以IEEE14节点、30节点和118节点标准测试系统为分析对象系统梳理不同规模电网下机组组合问题的建模要点与求解思路适合电力系统专业研究生、科研人员及Matlab仿真开发者用于算法验证、课程设计与论文复现。文档逐一说明三种系统的结构特点14节点系统包含5台发电机便于初步验证30节点系统包含6台发电机更接近实际中型电网118节点系统包含54台发电机约束条件多对算法计算效率与鲁棒性要求更高三种规模由简到繁覆盖从局部电网到大规模互联电网的典型场景。资源共一个PDF文件大小约610KB内容涵盖问题描述、系统建模要点、运行结果说明附运行结果示意与参考文献完整代码与仿真咨询可私信获取。目前已有35人学习下载可作为机组组合优化方向从入门到进阶的参考资料。1. 机组组合为什么难在建模而不是算力之前带过一位A同学做课程设计他拿三节点系统练手时跑得飞快一换到IEEE118节点就卡死换了好几台机器也没救回来最后发现根本不是内存不够而是他把机组启停状态全按连续变量写了——这种问题不算少见一旦规模上来任何错误都会被放大到不可收拾。这份关于电力系统机组组合优化调度的Matlab代码包正好让你用IEEE14、30、118三档节点系统把整套问题走通。它解决的是火电机组在24小时时间尺度上的启停与出力分配问题适合电力专业学生、调度方向的从业者和刚接触YALMIP的开发者既能把原理落到代码上也能看到规模变大以后计算瓶颈在哪儿。2. 机组组合的数学模型从目标函数到五类约束再谈节点规模的意义2.1 目标函数与决策变量为什么必须用二进制机组组合Unit CommitmentUC是一个典型的大规模混合整数规划MIP问题决策变量有两类每台机组在每个时段的启停状态是0/1变量对应时段的出力水平是连续变量。目标函数是让整个调度周期内的总成本最小燃料成本通常写成出力的二次函数再加上机组启动、停机的一次性成本。启动成本常按机组停机时间分冷启动和热启动冷启动成本高得多如果建模时不区分算出来的调度方案可能不切实际。这里我先讲一个简化版本假设所有机组都是热启动启动成本固定为一个常数。这样变量和约束都清晰等代码跑通后再慢慢放开往完整模型靠拢。YALMIP里定义变量的标准写法如下nG 5; % 机组数量 T 24; % 调度时段数 u binvar(nG, T, full); % 启停状态0/1 p sdpvar(nG, T, full); % 出力水平连续这里binvar声明二进制变量sdpvar声明连续变量第三个参数full表示不使用稀疏结构。在YALMIP中默认变量是稀疏的但对机组组合来说几乎每个机组每个时段都会被约束引用稀疏结构反而可能在后续索引时报错。我一般在写UC模型时都显式加full这个习惯会省掉不少排查时间。启动成本可以提前算成一个nG×T的矩阵再参与目标函数求和。目标函数写成fuelCost sum(sum(a .* p.^2 b .* p c .* repmat(u, 1, 1)), 1); startCost sum(sum(sc .* u)); objective fuelCost startCost;说明YALMIP支持二次项和线性项的sum(sum(...))写法a/b/c分别对应机组燃料成本的二次项系数、一次项系数和常数项维度都是nG×1通过广播和p逐元素运算。sc是启动成本矩阵维度与u一致这里把启动成本建模为一旦u1就支付全部费用是最简化的方式。真实系统中启动成本会随停机时长变化需要辅助变量追踪连续停机时长这个进阶扩展放到第6章提一下。为什么要用二进制变量因为它决定了机组是否在线而在线与否直接决定可行域是离散的。如果把它放松成连续变量约束会被连续化得到的最优解往往会让机组处于“半开半不开”的虚拟状态产生部分出力在实际调度中毫无意义。这就是混合整数规划在机组组合中不可替代的原因也是后面118节点规模下计算时间暴涨的根源。2.2 五类约束怎么写功率平衡、备用、出力上下限与爬坡机组组合的可行约束通常按五类来组织系统功率平衡、系统备用要求、机组出力上下限、机组爬坡约束、最小开停机时间约束。后两类是让模型从静态经济调度升级到动态调度的关键写错了最容易出现“看起来能跑算出来一团糟”的情况。这里直接给出YALMIP约束构建的核心代码C []; % 1. 系统功率平衡各机组出力之和 系统负荷 C [C, sum(p, 1) load_demand(1, T)]; % 2. 系统备用在线机组的最大出力之和 负荷 备用 C [C, sum(u .* Pmax, 1) (1 reserve_ratio) * load_demand(1, T)]; % 3. 机组出力上下限u0时出力为0u1时出力在[Pmin, Pmax] C [C, p u .* Pmax]; C [C, p u .* Pmin]; % 4. 爬坡约束相邻时段出力变化量受爬坡率限制 C [C, p(:, 2:T) - p(:, 1:T-1) RampRate]; C [C, p(:, 1:T-1) - p(:, 2:T) RampRate];这段代码的关键点在于出力上下限用u .* Pmax和u .* Pmin实现当u0时强制出力为0这是机组组合最核心的建模技巧让二进制状态直接参与连续变量边界。备用约束用在线最大出力之和覆盖负荷的1备用率倍这里的reserve_ratio通常取0.1到0.2之间表示系统需要留出10%—20%的旋转备用容量。爬坡约束我在这里用了常数RampRate实际场景中不同机组爬坡率不同应该改成nG×T的矩阵逐项约束。另外要注意爬坡约束只覆盖了第2到第24时段的相邻关系首时段没有爬坡约束——如果机组在第一个时段就开机并直接跑到高出力默认是允许的。真实调度会要求首时段与初始状态也满足爬坡代码包里一般会有initial_state变量来承接这个逻辑。最小开停机时间约束是线性化最麻烦的部分。常见做法是用辅助变量表示开机动作与停机动作再累加开机时段的窗口约束。落地写法通常会单独封装成一个函数输入机组初始运行状态与已连续开机时段数。这里不展开每一行但你要知道这个约束写不好容易出现一台机组开了两小时就关掉或者关了三小时又开起来优化结果被判定为违背物理规律这也就是我在第5章要讲的典型坑之一。2.3 三个节点系统为什么值得挨个跑一遍IEEE14节点、IEEE30节点、IEEE118节点是电力系统分析中最常见的标准测试系统。它们的数据格式相似但规模差异很大逐个跑一遍能帮你理解节点规模对建模深度和计算复杂度的影响。下面这张表列出了三个系统的主要差异。系统母线数支路数机组数负荷规模使用场景IEEE1414205259 MW学习建模、验证代码正确性IEEE3030416283 MW测试网损和线路潮流约束IEEE118118186544242 MW大规模MIP、研究算法性能从14到118机组数量从5跳到54二进制变量数量从5×24120变成54×241296。混合整数规划的求解时间通常随约束矩阵的非零元数量成指数级增长现实中118节点系统的24小时调度在普通笔记本上用默认求解器可能要跑几十分钟甚至更久而14节点系统几秒就能出结果。这也是我强烈建议先跑14的原因它能让你在不牺牲反馈速度的前提下检验约束逻辑确认模型无误后再切到118避免把“建模错误”和“求解器瓶颈”混在一起排查白白消耗两三个小时在等待上。3. 把IEEE14跑起来代码目录、数据接口与求解器依赖3.1 代码包里有什么主程序、数据文件与结果输出拿到这份资源后解压出来的Matlab代码包通常分成三类文件主程序入口、各节点系统的数据文件、以及约束构建与结果输出的辅助函数。我第一次看这类包的结构时习惯先理清楚谁来调用谁避免一头扎进某个函数细节里出不来。下面是常见的文件清单文件类型作用run_uc.m主程序读取节点数据、构建模型、调用求解器、输出结果case14.m/case30.m/case118.m数据文件返回MATPOWER格式的mpc结构体build_uc_constraints.m函数把机组参数与负荷曲线组合成约束plot_schedule.m函数把机组启停和出力结果可视化load_profile.mat数据存放24小时负荷曲线你需要先确认代码包用的是MATPOWER数据格式还是自有格式。MATPOWER的case14/30/118返回的mpc结构体包含bus、gen、branch、gencost四个核心字段机组数据在mpc.gen里成本系数在mpc.gencost里。如果这份代码包自定义了数据格式那case14.m这种文件的返回结构会不同但核心信息不外乎机组号、母线号、Pmin/Pmax、爬坡率、启停成本系数这几项。3.2 15分钟跑通IEEE14安装YALMIP与执行主脚本跑通这份代码的前置条件有三个Matlab环境、YALMIP工具箱、以及一个有能力的MIP求解器。YALMIP是建模层负责把约束和变量转换成求解器能读的标准形式求解器负责实际求解MIP。没有求解器时YALMIP会默认用内置的最简求解器能出结果但速度很慢14节点问题不大118节点基本跑不动。我建议的安装顺序是先把YALMIP下载解压到tools目录然后在Matlab里加路径% 把YALMIP和代码包加入Matlab路径 addpath(genpath(D:/tools/yalmip)); addpath(genpath(D:/uc_project));路径根据你本机实际位置改一下。加完路径后最好跑一句which sdpvar确认YALMIP生效如果显示YALMIP目录下的sdpvar.m说明路径设置没问题。接着直接运行mpc case14; % 载入IEEE14节点数据 [result, solution] run_uc(mpc); % 执行机组组合主程序 plot_schedule(solution); % 绘制24小时调度结果主程序run_uc.m会完成这几件事从mpc.gen读取机组参数从mpc.gencost读取成本系数加载24小时负荷曲线构建binvar和sdpvar变量组装目标函数与约束调用求解器求解最后把最优解拆分成机组启停矩阵、出力矩阵和总成本。运行结束后如果result.total_cost能正常显示一个数值比如十几万量级说明整条链路是通的。这里有个关键点case14返回的mpc结构体里mpc.gen的列顺序是固定的——第1列是机组所在母线编号第2到第7列是发电机的实时出力、可调出力下限和上限等后面几列是电压相关参数。读取时不要用硬编码列号去对接成本数据最好让run_uc.m内部统一从mpc.gen和mpc.gencost提取避免不同版本数据文件列偏移导致的错位问题。3.3 数据接口mpc结构里哪里藏着机组参数和成本数据如果你想把这份代码迁移到自己的系统上数据接口是最需要关注的部分。mpc.bus每行代表一个节点第3列是负荷有功MW第8列是节点类型——平衡节点、PQ节点或PV节点。mpc.gen每行代表一台机组重点看第2列PG当前出力、第9列Pmax、第10列Pmin这些是构建出力上下限约束的直接来源。mpc.branch每行代表一条支路第6列是支路容量上限如果做带线路潮流的机组组合潮流约束要用到这里的参数。成本系数藏在mpc.gencost里第1列MODEL为2表示多项式成本第2列NCOST表示多项式阶数比如3阶后面依次是二次项系数、一次项系数和常数项。需要留意的坑是成本系数单位是美元/MWh还是标幺值系数数量级直接决定目标函数数值如果发现结果总成本异常小大概率是成本系数没有做单位换算。我一般会在读完mpc后加一句打印检查% 打印前3台机组的成本参数确认量级 disp(mpc.gencost(1:3, :));输出结果里二次项系数应该在0.001—0.01量级一次项系数在10—50量级常数项在几百量级。如果看到二次项是50这种明显过大的数值八成是数据单位不一致。这个检查花不了10秒钟但能避免后续一堆诡异结果。4. 参数怎么设成本系数、备用率、爬坡率与求解器容差的调整逻辑4.1 成本系数与启停成本改哪个数字对最优解影响最大接触机组组合一段时间后你会发现模型的解对成本参数极其敏感尤其是启停成本与燃料成本之间的相对关系。当启动成本设得很低时系统可能频繁启停机组来追求燃料成本的微小下降得到的结果在物理上虽然可行在运维上却不可接受。反过来启动成本设得过高系统会尽量让所有机组一直在线又失去了优化的意义。在代码包里调整成本参数通常直接改case14.m或case30.m中的mpc.gencost表。一次项的调整对结果影响最直接% 把第2台机组的燃料成本一次项系数上调20% mpc.gencost(2, 5) mpc.gencost(2, 5) * 1.2; % 把第2台机组的启动成本设置为80 start_cost(2) 80;mpc.gencost每一行对应一台机组第4列开始依次是常数项、一次项和二次项系数。之所以说一次项系数影响最大是因为它在目标函数中对所有出力水平都生效而二次项只在较大出力时才有明显作用。你可以做一个简单实验把某台高成本机组的一次项系数上调30%重新求解观察它的平均出力是否明显下降。这个测试能帮你快速判断代码包的模型和数据是否正确串联。启动成本的调整还有一种比较实用的方式就是区分热启动与冷启动。热启动成本低冷启动成本高中间用辅助变量追踪机组停机时长。如果代码包里没有这个区分你可以在现有模型里加一个简化的分段启动成本做法是用两个二进制变量分别表示“热启动”和“冷启动”事件这样目标函数里就多了两类启动成本的加权项。但要注意这会增加两个二进制变量与对应约束在IEEE118系统上会进一步拖慢求解速度所以我一般只在30节点及以下尝试这个扩展。4.2 备用率与爬坡率让结果更接近实际调度的几个关键设置备用率和爬坡率是连接“数学可行”与“工程可用”的两个阀门。备用率设得太高比如0.3会让多台机组为了提供备用而保持空转抬高成本设得太低比如0.05又会让系统面对负荷预测偏差时没有回旋余地。工程上旋转备用率通常是最大单机容量的1.5—2倍或者系统负荷的8%—10%这是一个值得根据具体场景去试的区间。代码里修改备用率通常直接改主程序中的常量reserve_ratio 0.1; % 备用率10%对应典型旋转备用要求如果你想把备用约束做得更细可以把“旋转备用”和“非旋转备用”拆开。旋转备用要求机组在线且可以快速增出力非旋转备用允许停机机组启动。在代码包默认模型里备用约束所有机组都参与算出来的备用成本会偏高。更精细的做法是只在u1的机组集合里要求旋转备用容量并给每台机组设一个备用响应上限% 每台机组最多提供其Pmax的8%作为旋转备用 C [C, sum(min(u .* Pmax, 0.08 * Pmax), 1) reserve_ratio * load_demand(1, T)];这里的min在凸约束中可以用线性化处理YALMIP会自动转换。爬坡率方面IEEE标准测试系统的机组爬坡参数在mpc.gen里没有直接字段代码包一般会单独建一个机组参数表比如单位是MW/小时。通常火电机组爬坡率在3%—5%额定容量每分钟换算成每小时就是180%—300%额定容量所以一个200MW的机组爬坡率设为400—600MW/h。如果发现结果中频繁出现某台机组出力在相邻时段大幅跳变多半是爬坡率给定过大可以缩小到额定容量的50%/小时左右再求解。4.3 大系统实用化gap、time limit与MIP求解器的取舍IEEE118节点系统跑起来不再是几秒钟的事这时求解器参数调整就成了必修课。YALMIP里通过sdpsettings来传求解器参数最常见的两个是mip.relgaptol和solver。options sdpsettings(solver, cplex, mip.relgaptol, 0.01); options sdpsettings(options, solver, cplex, mip.tilim, 300); optimize(C, objective, options);这里mip.relgaptol0.01允许求解器在最优解1%的容差范围内提前终止mip.tilim300表示最多求解300秒。这样设置的好处是在规定时间内即使没有找到严格最优解也会返回一个可行的次优解工程上完全可以接受。实际项目中调度计划通常需要在一个小时内给出而商业求解器在118节点系统上跑24小时模型往往在15—30分钟内就已经能把gap压到1%以下再往下压就非常慢了。如果你用的求解器是开源的那一类比如默认的sedumi只能解连续锥规划对MIP支持很弱那118节点基本无解。此时优先更换求解器而不是修改模型。开源可选项里有几个知名的MIP求解器配置方式不同但都从sdpsettings(solver, ...)切入。更换求解器时注意一个点不同求解器对约束矩阵的预处理能力差异巨大同一份模型在A求解器跑3分钟在B求解器可能10秒就结束所以不要因为一个求解器慢就怀疑模型本身可以多换两个对比时间。5. 避坑与排查五个高发错误与对应的解决办法5.1 现象Matlab报错“未定义函数或变量 binvar”这是我看到最多的一类问题也最容易解决。报错出现在代码运行的第一行变量定义处说明YALMIP根本没有被正确加进Matlab路径或者当前工作目录被另一个同名文件干扰了。原因基本分两种第一种YALMIP工具箱根本没有下载解压第二种你用addpath只加了YALMIP外层目录但实际函数在下一层子目录里没有被递归加入。解决办法是使用addpath(genpath(...))并且确认which sdpvar有输出。如果which sdpvar仍然显示“未找到”就是YALMIP包本身的问题换一个渠道重新获取。提示安装完成后先重启Matlab再跑一次which sdpvar。老版本的Matlab对路径变更反应迟缓不重启可能会有偶发识别失败。5.2 现象IEEE14能跑换IEEE30就报“矩阵维度必须一致”这类维度错误几乎都出在数据文件的机组数量与代码硬编码的机组数量不一致上。比如某些版本代码里定义nG 5而IEEE30系统有6台机组后续所有矩阵就全部错位。解决办法把主程序开头所有硬编码的nG、nBus改成从mpc结构体动态获取。nG size(mpc.gen, 1); nBus size(mpc.bus, 1);动态获取后从14切到30再到118主程序几乎不用改只要把入口的case14换成case30或case118即可。顺带检查一下run_uc.m里有没有用到repmat的地方其展开的维度必须与nG、T匹配如果写成repmat(Pmax, 1, 24)而Pmax本身是5×1、机组数是6就会触发这种错误。5.3 现象IEEE118系统求解时间极长几十分钟后仍然在跑IEEE118系统有54台机组、24个时段二进制变量超过1200个千万不能让求解器裸跑到默认结束。内存里保存的每个节点约束矩阵都非常巨大默认容差会让求解器花大量时间在验证最优性上。解决办法有三个按推荐顺序执行。第一增加时间上限并用相对gap控制提前终止options sdpsettings(mip.tilim, 300, mip.relgaptol, 0.01);第二把问题分解成两阶段先做不带最小启停时间的经济调度用连续变量结果给出机组在线状态的初始解再把它作为MIP的热启动。YALMIP里给二进制变量赋初始值可以显著加速割平面收敛assign(u, warm_start); % warm_start为之前得到的近似启停矩阵第三如果仍然很慢考虑把调度周期从24小时压缩到关键时段比如当年负荷最高的12小时先跑通验证约束逻辑后再扩展回24小时。这套方法在代码包适用的场景中屡试不爽。5.4 现象求解结束但结果功率不平衡量很大这一类问题通常不出在求解器而出现在约束本身。一种常见的情况是功率平衡约束只考虑了机组出力的总和却漏掉了网络损耗和节点间交换功率。IEEE14系统中网损相对负荷比例不小如果忽略功率平衡误差按绝对值计算可能达到好几兆瓦。另一种常见的建模错位是负荷数据用的是系统总负荷但同时每条母线还有本地无功和电压相关约束在潮流意义上与机组出力天然存在差异。解决办法是把功率平衡约束改写成含网损的形式最简单用固定网损系数近似C [C, sum(p, 1) load_demand(1, T) loss_coeff * sum(p, 1)];loss_coeff按系统参数大概取0.03—0.05。如果你需要严格的潮流平衡就得引入直流潮流模型把节点相角作为变量加入约束这是一大步改动代码包里通常不默认开启。5.5 现象结果中某台机组时而开机时而停机违反最小启停时间这个坑经常藏得比较深因为求解器不会报错结果的总成本也合理只有把机组启停序列打印出来才能看出端倪。出现频率最高的原因是最小启停时间约束里初始状态处理错误。比如一台机组在调度开始前已连续运行了10小时但模型把它当成“刚从停机状态启动”导致前几个时段本来必须保持在线模型却把它关掉了。常见做法是在构建约束前先传入初始状态init_state.on ones(nG, 1); % 每台机组开机状态 init_state.time zeros(nG, 1); % 已连续运行时间为0然后把init_state与最小启停时间约束函数对接让首时段状态直接锁定已运行时长。如果代码包里自带min_up_down_constraints函数调用时需要明确传递这两个字段。另一个容易被忽略的细节是最小启动时间约束应当从机组首次开机点开始累积如果模型里写的是“累计开机时段数≥最小启动时间”而不是“连续开机状态”就会出现机组中间关了一会又重新开的虚假合法解。6. 结果验证与进阶功率平衡检查、机组组合曲线与168小时扩展拿到一组优化结果后我最先做的不是看成本而是先跑三个验证功率平衡检查、备用容量检查、爬坡约束违反检查。这三个检查全部通过我才会去信任成本数字。功率平衡检查很简单把每时段各机组出力求和与负荷曲线做差看差值是否在容差范围内备用检查看每个时段在线机组的最大出力之和是否不小于负荷的1.08倍爬坡检查逐台机组逐时段对比相邻时段出力差是否超过爬坡率。下面这段代码能一次完成三项检查balance_err sum(p_opt, 1) - load_demand; reserve_margin sum(u_opt .* Pmax, 1) - 1.1 * load_demand; ramp_violation max(abs(diff(p_opt, 1, 2)) - RampRate * ones(nG, 1), [], all); fprintf(最大功率不平衡: %.4f MW\n, max(abs(balance_err))); fprintf(最小备用裕度: %.4f MW\n, min(reserve_margin)); fprintf(最大爬坡越限: %.4f MW\n, ramp_violation);p_opt和u_opt分别是最优出力和启停矩阵从solution结构体中提取。如果ramp_violation带出几个兆瓦的值就要回到第4章去调爬坡率参数或者检查初始状态的爬坡约束有没有遗漏。三项检查通过以后我会进一步画调度曲线。画图不只是为了好看它能直观暴露“某台机组在负荷尖峰前1小时才启动”这种时序问题靠数字扫出来要费不少时间。用代码包自带的plot_schedule.m或者自己写一段简短的可视化figure; stairs(1:T, sum(p_opt, 1), LineWidth, 1.5); hold on; stairs(1:T, load_demand, r--); bar(1:T, u_opt(1, :) * 50, FaceAlpha, 0.3); legend(总出力, 负荷, 机组1启停状态(缩放)); xlabel(时段(h)); ylabel(功率(MW));这类图里能看出机组启停序列和负荷曲线的匹配度——不匹配的地方往往是约束写错或者参数设置不合常理的地方。对于想在这份资源上再进一步的人我推荐一个扩展方向把24小时调度拉长为168小时周调度。这个改动看起来只是把T从24改成168但计算规模会翻好几倍而且机组的最少启停时间、检修安排、燃料库存约束都会开始产生影响。这时候建议引入滚动优化先跑前24小时得到方案把联合循环机组或大机组的启停状态固定再滚动优化后面24小时每步只留一部分变量可变。这种策略在工程调度中非常常见代码包跑通一天的模型以后你完全可以在这个基础上做滚动扩展。另外可以尝试的进阶方向是给不同机组加上区域约束比如“区域A内至少保持一台机组在线”用于模拟新能源出力不确定性下的备用容量需求。只需要在约束里加一个基于节点分区矩阵的线性表达式也就是用一组0/1矩阵把机组映射到区域再对每个区域累加在线状态。这类改动对模型结构冲击小但对实际调度没有用处不大。最后说一个我的习惯从那以后我每次拿到任何一份机组组合代码都强制先跑一遍IEEE14的小算例确认功率最大不平衡量在0.01 MW以内、备用裕度为正再上30节点和118节点。这个动作成本低却能过滤掉大多数低级错误省下的排查时间远大于跑算例的几分钟。希望帮到你。本文还有配套的精品资源点击获取