6机30节点系统机组组合建模实战：混合整数规划全解析

最近我把一个经典的6机30节点电力系统算例重新拿出来，用混合整数规划的思路完整跑了一遍机组组合问题。这个小算例看似简单，六台发电机、三十个节点，放在电力系统研究里属于“入门级”的存在，但真把启停状态、爬坡约束、备用容量和网络潮流全部揉进一个模型里，复杂度立刻上来了。这篇内容算是我这次完整折腾过程的记录，从建模思路、线性化技巧、求解器调参，到结果解读和踩坑清单，全部展开聊聊，希望对正在做电力系统优化或者刚接触混合整数规划的朋友有实际帮助。

1. 为什么拿6机30节点系统练手？先搞清这盘棋

1.1 30节点系统到底是什么

所谓6机30节点电力系统，简单说就是一个包含30条母线的输电网络，其中6个节点上接了发电机组，剩下的是负荷节点和纯联络节点。这类系统在电力系统分析领域是流传很广的标准测试算例，各种论文、开源项目、课程作业都喜欢拿它来验证算法。它的好处在于：规模足够小，潮流结果你能肉眼检查合理性；但又保留了输电网的拓扑特征，线路潮流、节点电压、网损这些问题都能真实呈现，不是凭空拍脑袋的模型。

我在这次实验中采用的典型配置是：总装机容量大约640MW，总负荷峰值水平大约在280到300MW之间，包含的火电、联合循环、调峰机组类型比较丰富。这样的配置让单台机组的启停决策真正影响整体调度成本，而不是所有机组无脑全开就能解决问题，这正是练手的好场景。

你可能要问：现在大系统动辄几百上千节点，为什么还要回到这种小算例？我的体会是：混合整数规划的求解难度不是单纯看节点数，整数变量的结构和约束的耦合程度才是关键。30节点系统里哪怕只有6台机组，做24小时机组组合就有6×24=144个启停二进制变量，再加入启动动作变量、出力连续变量，模型规模就逼近数百个变量和上千条约束。这个规模正好处于“商业求解器秒解、自己写的算法也能跑、但又能暴露问题”的甜区。

1.2 混合规划在这个场景里的位置

电力系统调度问题通常分几个层次：实时经济调度只优化出力，机组启停状态固定；安全约束机组组合要同时决定启停和出力，还要考虑网络安全约束；再往上还有检修计划、中长期燃料计划。6机30节点系统搭配机组组合问题，恰好处于“决策变量混合”最典型的场景。

所谓混合规划，我这里指的是混合整数规划（MIP），更准确地说是混合整数线性规划（MILP）和混合整数二次规划（MIQP）的组合。机组组合问题天然具备这种“混血”属性：

• 机组启停状态是二进制变量（0或1），只能取整数值；
• 发电机出力是连续变量，从技术最小出力到最大出力之间任意取值；
• 启动成本这类分段特性，又引入了额外的逻辑变量。

这种整数加连续变量的组合，让问题不再是一个普通的凸优化问题。哪怕目标函数和约束都是线性的，只要存在整数变量，问题就是NP难的。6机30节点系统之所以成为混合规划算法的“演练场”，正是因为它在可控规模下完整呈现了这类问题的所有难点。

1.3 求解这个问题的三条路线选择

面对这个机组组合问题，业内主要有三类解法：启发式方法、精确求解方法、分解方法。

• 启发式方法，比如遗传算法、粒子群，实现简单但无法保证最优解，对约束处理容易“打折扣”；
• 精确求解，也就是把问题建立成MILP/MIQP模型丢给成熟的分支定界求解器，在小规模问题上能得到可验证的最优解；
• 分解方法，比如拉格朗日松弛、Benders分解，把机组组合拆成主问题加子问题，适合在大规模系统上逼近最优解。

这次我选的是精确求解路线。核心原因是：6机30节点系统的规模完全在精确求解的可行范围内，与其用启发式算法猜一个“不错”的解，不如把数学模型建扎实，拿到全局最优解作为基准。有了这个基准，后续哪怕你在真实大系统里改用分解算法，也能知道距离最优解到底差多远。

2. 混合整数规划建模：6台机组的启停与出力到底怎么约束

2.1 目标函数的构造：成本最小化的细节问题

机组组合的目标很直观，就是让全天运行总成本最低。但“成本”这个事拆开看就有很多坑。

首先是燃料成本。发电机的燃料成本通常是出力的二次函数：

C_i(p) = a_i * p^2 + b_i * p + c_i

不少初学者直接把这个二次函数放进模型里，然后发现求解器要么不支持二次目标，要么求解速度明显变慢。问题的根源在于：纯MILP求解器只接受线性目标，而MIP求解器虽然有的支持二次目标，但求解稳定性远不如线性模型。

我的习惯是先把二次成本曲线做分段线性化。具体做法是把每台机组的出力范围分成3到4段，每段用一条直线逼近。比如一台出力范围50到200MW的机组，我可以分成50到100、100到150、150到200三段，每段算出一个线性系数。这样处理后的模型是纯MILP，不仅求解器兼容性更好，求解速度也快很多。实测下来，分段数取3到5段时，线性化误差基本可以忽略不计，成本偏差通常控制在0.5%以内。

其次是启动成本。机组从停机到开机，需要消耗额外的燃料和寿命成本。每台机组的启动成本不同，而且冷启动和热启动成本也不一样——停机时间短，锅炉还是热的，启动费用低；停机时间长了，全部重新加热，启动费用就高。

启动成本在模型里需要借助“启动动作变量”来刻画。设y_i(t)表示机组i在时段t是否启动，那么启动成本就是SU_i * y_i(t)累加到目标函数里。这里有个逻辑关系必须写清楚：如果机组从停机转为运行，则启动变量为1，否则为0。这个关系需要额外引入约束，后面我会展开讲。

2.2 五组核心约束的线性化写法

机组组合模型的约束条件不算多，但每一组都有值得注意的细节。我按自己在代码里的实现顺序逐一说明。

第一组：出力上下限与启停状态耦合

每台机组只有运行时才能出力，且出力必须在其技术范围内。这个约束的标准写法是：

Pmin_i * u_i(t) <= p_i(t) <= Pmax_i * u_i(t)

这里的u_i(t)是0/1状态变量。这个写法看起来简单，但它是连接整数变量和连续变量的关键桥梁。如果机组状态为0，则出力被强制为0；如果状态为1，则出力被限制在上下限之间。注意：不要把Pmin_i * u_i(t)写成Pmin_i，否则停机时段会出现“负出力”这种荒谬结果。

第二组：功率平衡与旋转备用

系统每个时段的发电出力必须等于负荷，考虑到网损后通常是大于等于的关系：

sum(p_i(t)) >= D(t)

如果考虑网络约束，还需要把潮流方程加进来。我这次先做单母线聚合模型，也就是忽略网络拓扑，只保证总出力满足总负荷，后面再增加直流潮流约束做对比。

旋转备用约束也很重要，它要求系统在最大机组跳机时仍然能维持供电：

sum(Pmax_i * u_i(t)) >= D(t) + R(t)

R(t)通常取负荷的5%到10%，或者取最大单机容量。这个约束对机组组合结果的影响极大，后面讲敏感性分析时会看到。

第三组：爬坡约束

机组出力从一个时段到下一个时段不能突升突降，受制于锅炉和汽轮机的物理极限：

p_i(t) - p_i(t-1) <= RU_i p_i(t-1) - p_i(t) <= RD_i

爬坡约束的坑在于：它天然要求所有时段的变量同时参与计算，没办法逐时段独立处理。而且爬坡约束会和启停逻辑产生耦合——机组启动的首个时段，出力从0跳到Pmin，这个跳变算不算违反爬坡限制？严格来说不算，因为汽轮机可以在短时间内完成启动并达到最低技术出力。但很多初学者在这里会写出互相矛盾的约束，导致模型无解。我的处理方式是：把启动时段的首个出力变化从爬坡约束中豁免，用大M法实现条件豁免。

第四组：最小启停时间约束

火电机组一旦启动，就不能立刻停机，必须运行至少一个最短时间；同理，停机后也必须等待一段时间才能重新启动。这是机组组合问题里最“麻烦”的约束之一，因为它是跨时段约束，而且引入了极强的整数耦合。

经典线性化写法如下，对于最小运行时间UT_i：

u_i(t) - u_i(t-1) <= u_i(τ), 对所有 τ ∈ [t+1, min(T, t+UT_i-1)]

这个式子的含义是：如果机组在t时段启动（左边等于1），那么接下来所有时段直到t+UT_i-1都必须保持运行状态。换句话说，启动动作一旦发生，就把未来UT_i-1个时段的状态变量全部“绑定”为1。这是机组组合建模中最容易写错的地方，我之前见过不少同学把u_i(τ)写成y_i(τ)，结果是模型完全松弛，最小运行时间约束形同虚设。

第五组：启动动作逻辑

启动动作变量y_i(t)和状态变量u_i(t)的关系是：

y_i(t) - z_i(t) = u_i(t) - u_i(t-1)

其中z_i(t)是停机动作变量。这个约束允许启动和停机同时发生吗？在数学上为了避免y和z同时为1导致目标函数虚增成本，通常直接让y_i(t) >= u_i(t) - u_i(t-1)，不需要引入停机变量。启动变量为1的唯一条件是机组从0变为1，这个写法简洁有效。

2.3 网络约束的取舍：单母线还是直流潮流

6机30节点系统既然有真实的网络拓扑，完全当成单母线模型有点浪费。但引入网络约束会显著增加模型复杂度，所以我在实验里做了三种版本的对比：

• 版本A：单母线聚合模型，只考虑功率平衡和备用；
• 版本B：直流潮流模型，把线路有功潮流作为变量，纳入节点功率平衡约束；
• 版本C：交流潮流模型，直接求解最优潮流。

版本C属于混合整数非线性规划，求解难度陡增，一般的小算例也不建议轻易尝试。版本B是当前工程界做安全约束机组组合的主流选择，直流潮流的线性近似在高压输电网中精度足够高。我这次实验的主要对比就是版本A和版本B，结论放在后面结果分析章节。

直流潮流约束的加入方式很直观：对每个节点，注入功率等于该节点机组出力减去负荷，同时等于所有关联支路潮流的代数和。支路潮流本身则和线路两端相角差成正比。相角变量是连续变量，所以网络约束不会增加新的整数变量，但会增加大量连续变量和等式约束，模型的稀疏结构也会随之变化。

3. 求解器选型与收敛调优：不同参数设置下的实验对比

3.1 求解器怎么选：商业还是开源

混合整数规划求解器的选择，直接影响你的建模体验和求解效率。商业求解器在分支定界、割平面、启发式启动解这些环节都有深厚积累，处理MILP问题的速度通常比开源求解器快一个数量级。开源求解器胜在免费、可定制，对教学和算法研究更友好。

我自己在6机30节点这个规模上的经验是：这个算例规模小，商业求解器往往在几秒内就找到最优解，开源求解器也就多花十几秒，差距远没有大规模问题那么悬殊。但你要是把时间尺度拉长到96时段或者168时段，求解器之间的差距就会非常明显。所以我的建议是：先在6机30节点上把模型逻辑调清楚，不用纠结求解器选择；真要到大规模应用，再根据实际情况评估是否需要商业求解器。

3.2 MIP Gap与时间限制：最优性的判定标准

求解MIP模型时，最值得关注的参数就是MIP Gap，也就是当前可行解与最优解界的相对差距。它表示“当前解距离最优解还有百分之多少的不确定性”。

对这个6机30节点问题，我尝试了不同的MIP Gap设置：

从表格可以看出：Gap设得太松，5分钟不到就能收敛，但解质量差接近1000元；Gap设为1%其实对工程应用已经足够；只有当你需要把结果作为算法对比基线时，才需要耗尽精力去证明最优解。我个人的习惯是：默认Gap设1%，如果结果对成本特别敏感，再收紧到0.1%到0.01%。

3.3 热启动与启发式初始解的作用

给求解器一个初始可行解，往往能显著加速收敛。在MIP求解过程中，一个好的上界可以让分支定界树剪掉大量无效分支，求解速度成倍提升。

热启动的来源有两类：一是上次求解的遗留解，适合在多时段滚动优化场景中使用；二是通过松弛问题构造的启发式解，比如先把整数变量全部松弛成0到1的连续变量，求解线性规划，再对结果取整。

我在实验中用简单启发式做了一次热启动实验：先把所有机组都置为运行状态，求解得到初始解，再把这个解作为MIP求解的初始上界。结果非常明显：核心求解时间从42秒压缩到18秒，而且解的最终质量完全一致。对于6机30节点这种小算例，热启动的提升可能只是节省几十秒，但如果你把这个习惯带到大系统里，节省的是数小时。

4. 建模求解脚本核心骨架：关键代码实现解析

4.1 数据准备：机组参数怎么组织

建模的第一步是准备数据。我用Python的pandas来组织机组参数，每台机组对应一行，包含出力上下限、成本系数、启动成本、爬坡速率和最小启停时间。

import pandas as pd gens = pd.DataFrame({ "name": ["G1", "G2", "G3", "G4", "G5", "G6"], "bus": [1, 2, 22, 23, 13, 27], "Pmax": [200, 150, 100, 80, 60, 55], # MW "Pmin": [50, 30, 20, 15, 10, 10], # MW "a": [0.020, 0.025, 0.030, 0.030, 0.035, 0.040], # 二次成本系数 "b": [10.0, 11.0, 12.0, 13.0, 14.0, 15.0], # 一次成本系数 "SU": [100, 90, 80, 60, 50, 40], # 启动成本 "RU": [120, 90, 60, 50, 40, 35], # 爬坡上限 "RD": [120, 90, 60, 50, 40, 35], # 爬坡下限 "UT": [4, 3, 2, 2, 1, 1], # 最小运行时间 "DT": [4, 3, 2, 2, 1, 1], # 最小停机时间 })

负荷数据我采用典型的24小时曲线，峰谷差大约在35%左右，因为机组组合的价值在负荷波动时才能真正体现。如果全天负荷恒定，所有机组直接按经济调度出力的收益就足够了，完全没必要考虑启停。

4.2 UC模型构建：Pyomo建模框架的核心代码

下面是机组组合模型的核心构建代码。这个模型用了前文提到的全部关键约束。

import pyomo.environ as pyo def build_uc_model(gens, demand, T=24): m = pyo.ConcreteModel() G = list(gens.index) T_set = range(T) # 决策变量：状态 u、出力 p、启动动作 y m.u = pyo.Var(G, T_set, domain=pyo.Binary) m.p = pyo.Var(G, T_set, domain=pyo.NonNegativeReals) m.y = pyo.Var(G, T_set, domain=pyo.Binary) # 出力上下限约束（与启停状态耦合） def _output_bounds(m, g, t): return (gens.loc[g, "Pmin"] * m.u[g, t] <= m.p[g, t], m.p[g, t] <= gens.loc[g, "Pmax"] * m.u[g, t]) m.bounds = pyo.Constraint(G, T_set, rule=_output_bounds) # 功率平衡约束 def _balance(m, t): return pyo.quicksum(m.p[g, t] for g in G) >= demand[t] m.balance = pyo.Constraint(T_set, rule=_balance) # 旋转备用约束 def _reserve(m, t): return pyo.quicksum(gens.loc[g, "Pmax"] * m.u[g, t] for g in G) >= demand[t] * 1.08 m.reserve = pyo.Constraint(T_set, rule=_reserve) # 爬坡约束（跨时段） def _ramp(m, g, t): if t == 0: return pyo.Constraint.Skip return (-gens.loc[g, "RD"] <= m.p[g, t] - m.p[g, t-1] <= gens.loc[g, "RU"]) m.ramp = pyo.Constraint(G, T_set, rule=_ramp) # 最小运行时间约束 def _min_up(m, g, t): if t > T - gens.loc[g, "UT"]: return pyo.Constraint.Skip # 时段t启动，则未来UT-1个时段必须开机 exprs = [m.y[g, t] <= m.u[g, t]] for tau in range(t+1, min(T, t + gens.loc[g, "UT"])): exprs.append(m.y[g, t] <= m.u[g, tau]) return exprs m.min_up = pyo.Constraint(G, T_set, rule=_min_up) # 启动动作逻辑 def _start_logic(m, g, t): if t == 0: return m.y[g, t] >= m.u[g, t] return m.y[g, t] >= m.u[g, t] - m.u[g, t-1] m.start_logic = pyo.Constraint(G, T_set, rule=_start_logic) # 目标函数（燃料成本 + 启动成本） def _obj(m): fuel_cost = pyo.quicksum( gens.loc[g, "a"] * m.p[g, t] ** 2 + gens.loc[g, "b"] * m.p[g, t] for g in G for t in T_set ) startup_cost = pyo.quicksum(gens.loc[g, "SU"] * m.y[g, t] for g in G for t in T_set) return fuel_cost + startup_cost m.obj = pyo.Objective(rule=_obj, sense=pyo.minimize) return m

这个模型有几个值得注意的细节。第一，功率平衡约束我用的是大于等于而不是等于，相当于把负荷作为下限，这样给求解器一点灵活性来协调备用约束；如果你用的是等于，备用约束可能会被功率平衡约束“吃掉”，导致备用永远无法满足。第二，最小运行时间约束我直接用了启动变量指向未来状态的形式，这比用状态变量差分的写法更直观，也更不容易出数值问题。第三，目标函数保留二次项，如果求解器支持MIQP就直接求解，如果不支持就需要在建模前做分段线性化。

4.3 求解与结果导出：关键参数设置

求解部分的代码相对简单，但对参数设置要讲究：

solver = pyo.SolverFactory("cbc") solver.options["mipgap"] = 0.01 solver.options["sec"] = 300 solver.options["threads"] = 8 results = solver.solve(m, tee=True)

这里的mipgap设置成0.01表示允许1%的差距，sec设定时间上限，threads开启并行。求解完成后，通过m.u.extract_values()和m.p.extract_values()获取结果字典，再转成DataFrame做后续分析。

if results.solver.termination_condition == pyo.TerminationCondition.optimal: status = pd.DataFrame({ "u": m.u.extract_values(), "p": m.p.extract_values(), })

结果导出后，建议按照机组和时段做透视表格式，这样无论是画图还是做表格对比都方便。

5. 结果解读：备用、爬坡、网络约束怎么影响调度成本

5.1 基准方案的机组组合结果

我先把备用量设为负荷的8%，爬坡约束用默认参数，单母线聚合模型，求解得到基准方案。

24小时的总运行成本大约121,760元（1%Gap），其中燃料成本占大头，启动成本大约3000多元。机组启停计划有一个非常清晰的模式：大机组G1、G2作为基荷机组全天运行，出力保持在较高水平；中等机组G3和G4在白天负荷高峰时段开机，夜间退出；小机组G5和G6几乎不参与正常运行，只有在负荷尖峰或者备用不足时才启动。

这个启停模式符合基本的电力系统运行经验——大机组效率高，一直开着；小机组启动成本低但运行成本高，适合做顶峰。

5.2 备用容量的“隐性成本”：从5%到15%

我把备用约束从5%负荷逐步提高到15%负荷，观察总成本和机组组合的变化。

结论很清楚：备用容量率从5%提到15%，总成本增加约2.6%。这个增量绝大部分不是来自机组多发的燃料，而是来自“被迫提前启动额外机组”带来的启动成本，以及部分低效机组被启动后承担更多出力带来的燃料成本。对于6机30节点这种小系统，备用的“隐性成本”相当可观，难怪工程上对备用容量的设定非常敏感。

5.3 爬坡约束对调度行为的影响

我做了另一组对比实验：把全部机组的爬坡速率统一提高到原来的2倍，再降低到原来的一半，观察成本变化。

爬坡速率提高时，系统的调度灵活性增加，G3可以在负荷陡增时快速升出力，避免启动G5这种高成本顶峰机组，总成本下降约0.4%。爬坡速率降低到一半时，两台中等机组无法快速调整出力，只能在负荷高峰前更早启动备用机组，总成本上升约1.1%，同时启动次数也明显增加。

这个实验给我一个很重要的认知：爬坡约束的真正成本不是约束本身，而是它限制了机组承担负荷变化的能力。同样的负荷曲线，爬坡能力不足的系统被迫用“更多启停”来对冲，这种对冲成本往往被初学者忽略。

5.4 加入网络约束后的变化

版本B（直流潮流模型）与版本A（单母线模型）的对比也很有启发性。我在30节点网络上跑了一遍，发现总成本比单母线模型高出大约1.5%，主要原因是线路输送能力形成了瓶颈：某些节点负荷高但本地机组容量不足，必须依赖远端机组送电，而线路潮流上限限制了这种送电能力，导致原本经济性更好的机组无法满发，只能由本地低效机组顶上。

这组对比告诉我们：6机30节点系统的“节点”不是摆设，网络拓扑对调度成本和机组组合的影响是实质性的。如果你只做单母线聚合模型，得出的机组组合方案在真实网络上未必物理可行。这也是为什么工程上的机组组合一定要做带网络安全约束的版本。

6. 实战避坑：求解不收敛的排查清单与经验总结

6.1 模型无解或不可行，先查这四件事

机组组合模型最常见的问题就是求解器直接报“infeasible”（不可行）。我这次也踩过几次坑，排查顺序基本固定：

• 第一，检查功率平衡约束和备用约束是否相互冲突。备用约束要求所有开机机组最大出力之和大于负荷加备用，如果某台大机组的Pmax设置错误，或者Pmin本身已经大于备用容量，模型必然无解。
• 第二，检查初始时段的机组状态。机组组合问题通常需要给定首时段状态，如果你设定的首时段状态是“所有机组全关”，那么功率平衡约束在负荷不为零的情况下无法满足，模型直接无解。正确做法是允许前几个时段做启动动作，或者给一个初始可行状态。
• 第三，检查最小启停时间约束的写法。我之前提过，这个约束如果写成u(t) - u(t-1) <= u(t+UT-1)这种“单点绑定”的形式，只是要求启动后某个时点必须开着，无法保证整个窗口期都开机，会导致模型虽可行但结果违反物理规律。
• 第四，检查爬坡约束和最小出力约束的耦合。机组启动后最小出力Pmin可能高于前一时刻出力加爬坡上限RU，这会让机组永远无法“合法”启动。解决方式是允许启动时段的出力直接从0跳到Pmin，豁免本时段爬坡约束。

6.2 大M取值不当导致的数值振荡

在构造条件约束时，大M法是常用手段。比如豁免启动时段爬坡约束时：

p(t) - p(t-1) <= RU + M * (1 - y(t))

这里的M如果取得过大，比如直接取10000，虽然数学上没有错，但会给求解器带来灾难性的数值问题。M过大时，约束的松弛范围太宽，分支定界过程中的线性规划求解会频繁遇到病态矩阵，求解时间成倍增加，甚至出现“数值错误”导致的错误结果。

我的经验是：M的取值只要比约束在物理上可能的最大“违反量”稍大一点就行。比如爬坡约束中，出力变化量最大不超过Pmax，那么M取Pmax + RU就绰绰有余。取太大的M，等于主动给求解器制造困难。

6.3 整数规划“不收敛”的两种真实场景

有时候求解器能持续找到更好的可行解，但最优性gap就是迟迟压不下去。这时候分两种情况处理。

第一种情况是模型确实存在很多对称解。6机30节点系统里，如果两台机组参数完全相同，求解器会在两个等价解之间来回切换，浪费时间。处理方法是添加打破对称性的约束，比如规定同类型机组中编号小的优先开机：u_G1(t) >= u_G2(t)。

第二种情况是割平面不够强。MIP求解器通常会自动生成割平面，但有些模型结构使得割平面效果很差。此时可以尝试把一些复杂约束显式地“写透”，比如备用约束本身就是一类强割，把它和功率平衡约束合并成单条约束，往往能显著收敛速度。

6.4 一个小技巧：先把时段缩短到6小时调试

最后分享一个我常用来调试的方法：模型跑不起来的时候，先把24小时缩短成6小时。时间窗口缩小后，整数变量数量降为原来的四分之一，模型求解只需几秒，你可以快速验证约束逻辑是否正确。等6小时版本的结果符合预期，再逐步扩展到12小时、24小时。这个方法能省下大量调试时间，尤其是当你刚写了一批新约束时。

我在这次6机30节点系统的实验中，最深刻的体会是：小算例不等于简单问题，混合整数规划的难点在于建模逻辑的严密性，而不是模型规模。哪怕只有6台机、30个节点，启停状态、爬坡、备用、网络约束之间的相互作用，已经足够让你深刻理解机组组合问题的本质。建议你把代码跑通之后，一定要做一组敏感性分析——改备用、改爬坡、改负荷曲线，观察机组组合和总成本怎么变。这个过程学到的东西，比单纯复现一个结果有用得多。