两阶段鲁棒优化这几年在电力系统调度里几乎成了绕不开的"标准动作"。只要一提到风电、光伏、负荷的不确定性,随口能说出来的方法基本就是两阶段鲁棒加C&CG算法。我最初接触这个问题时也犯过嘀咕:明明确定性优化简单得多,随机规划看起来也更"精确",为什么大家偏偏喜欢鲁棒优化?后来在微电网日前调度项目里把方法真正跑通后,才算理解了这套组合拳的价值所在。
这篇文章就用"计及风、光、负荷不确定性两阶段鲁棒优化"这个题目为引子,把从建模、大M法处理、C&CG算法求解,到Matlab+YALMIP代码实现的全链路拆一遍。适合正在做电力系统优化调度、微电网能量管理、综合能源系统研究的硕博研究生,以及刚入门鲁棒优化的工程技术人员。文章不会只贴公式,我会把每一步设计的逻辑、迭代过程中容易踩的坑、代码骨架和调试技巧都讲清楚。
1. 为什么两阶段鲁棒优化成了调度问题的标配
1.1 风光负荷不确定性的三个来源
风电出力和光照强度本身是随机过程,负荷侧也有大量预测误差。我们做调度时,常规做法是拿一组预测曲线去做确定性优化,但预测曲线只是实际曲线的"期望",一旦第二天实际风光出力偏离预测值较大,之前排好的机组出力和联络线计划就可能不可行,严重的还会导致切负荷或弃风弃光。
这类不确定性有三个典型来源:
- 风电出力:受风速随机性影响,分钟级到小时级的波动都很大,尤其早晚时段风向风速切换频繁,功率曲线偏离预测值十几个百分点是很常见的事。
- 光伏出力:受云层遮挡影响,辐照度短时骤降可以带来光伏出力断崖式下跌,这是最考验系统应对能力的场景之一。
- 负荷需求:用户行为变化、温度波动、节假日效应,都让负荷预测带有误差,尤其高峰时段的负荷预测偏差影响更大。
三类不确定性叠加后,确定性优化方案的鲁棒性短板就更明显了。鲁棒优化的基本思路就是:我不去猜这些不确定量的具体概率分布,我只要求它们落在一个合理的波动区间内,然后在这个区间里找"即使在最坏情况下也能保证安全运行"的决策。
1.2 两阶段决策逻辑:先把能定的定了,剩下的留给实时
两阶段体现在决策时间尺度的分离。"两阶段"其实对应的是两类决策变量:
- 第一阶段变量(here-and-now决策):在不确定性实现前就要确定的量。典型代表是机组启停状态、储能是否参与充放电、外网购电/售电计划等。这些是0-1变量或整数变量,一旦定了当天很难改。
- 第二阶段变量(wait-and-see决策):不确定性实现后,系统运行人员做出的调整量。典型代表是各机组实际出力、储能充放电功率、弃风弃光量、切负荷量等。这些是在知晓实际风光出力后,通过经济调度实时确定的。
这样分解之后,优化问题天然形成"主从递阶"结构:第一阶段定方案,第二阶段在方案基础上做最坏情况下的最优响应。这正是两阶段鲁棒优化模型的决策框架。
1.3 确定性优化、随机优化与鲁棒优化怎么选
很多新手一上来就在纠结:用确定性优化加个旋转备用不就够了吗?为什么要上两阶段鲁棒优化?这个问题我觉得得从问题本身的容忍度去看。
确定性优化的缺陷在于,旋转备用容量是人为定的,定多了浪费,定少了又扛不住极端场景。随机规划(比如场景法)虽然考虑了概率分布,但需要精准的分布信息和大量场景采样,计算量大,而且分布估计错了,结果反而不稳定。
鲁棒优化走的是"保底路线":我不管你实际落在哪里,只要不越出事先定义的不确定集,我的决策就能保证系统安全运行。它给出的解往往偏保守,但计算复杂度远低于带概率分布的场景法,而且对分布信息的要求低很多。对电力系统这种安全性要求极高的场合,"保底"比"期望最优"更有吸引力。实际工程里,调度人员的核心诉求永远是"无论如何不能出事",这也解释了两阶段鲁棒优化在微电网和配电系统调度中成为主流的根本原因。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 两阶段鲁棒优化模型怎么搭
2.1 不确定集:盒式区间就是最常用的"鲁棒边界"
不确定集是鲁棒优化模型的灵魂。工程上最常用也最好处理的是盒式不确定集,也就是把每个不确定参数限制在一个区间内:
code复制P_w^t ∈ [ P_w_pre^t - ΔP_w^t , P_w_pre^t + ΔP_w^t ]
P_pv^t ∈ [ P_pv_pre^t - ΔP_pv^t , P_pv_pre^t + ΔP_pv^t ]
P_load^t ∈ [ P_load_pre^t - ΔP_load^t , P_load_pre^t + ΔP_load^t ]
其中 P_w_pre、P_pv_pre、P_load_pre 是预测值,Δ 是允许的最大偏差。盒式不确定集的好处是表达简单、对偶变换容易,且工程上"功率落在预测值加减一定百分比内"这个假设很直观,容易跟调度人员沟通。
如果想控制保守程度,还可以用预算不确定集(Budget-based uncertainty set),限制所有时段的总偏差不超过某个预算值,避免24个时段同时取到最坏值——这在实际系统中几乎不发生。但从代码实现角度看,盒式集是最容易起步的,等盒式集跑通了,再扩展预算约束也不难。
