1. 调度问题从哪里开始区域微电网为什么非做鲁棒不可接手“含可再生能源和储能的区域微电网最优运行”这个题目时很多人第一反应是先找代码、先跑通模型但真到了现场你会发现最难的从来不是求解器怎么调而是“不确定的东西怎么描述”。风、光出力天然波动负荷侧又有预测误差如果调度方案只按某一组确定数值来算那这个方案在第二天八成是废纸一张。实际运行里我踩过的坑就是确定性调度模型在仿真里指标很漂亮一接入实时数据就频繁需要人工干预根源就在于没有把不确定性放进优化过程本身。这也就是多阶段鲁棒调度模型存在的意义。它跟随机规划不同不需要强行假设光伏、风电、负荷服从某个具体概率分布而是用一个“不确定集合”把可能出现的场景先框起来然后求解在“最坏情况”下仍然可行的调度策略。对于微电网这种规模不大、但运行约束错综复杂的系统来说这种做法格外合适不用为了概率分布的精确性做太多统计工作又能保证方案在绝大多数工况下不越限、不失负荷、不损坏储能。本文适合三类人一是刚接触微电网优化、想弄明白鲁棒和随机规划差别的学生二是手里已经有一套确定性调度代码、想升级成带不确定性处理的工程师三是做项目汇报时需要解释“为什么采用多阶段鲁棒而非两阶段鲁棒”的落地人员。我会从模型逻辑、场景构造、MATLAB实现细节和求解坑点几个层面展开尽量做到照着文章能自己搭出一版可运行的多阶段鲁棒调度框架。2. 模型到底在算什么东西设备建模与目标函数拆解2.1 微电网里的设备对象和运行边界先不碰鲁棒理论把物理对象说清楚。一个典型的区域微电网至少包含光伏阵列、风力机组、储能电池、本地负荷以及和上级电网的交换接口。部分场景里还有柴油发电机或微型燃气轮机但“含可再生能源和储能”这个题目限定下核心设备就是风光储加联络线功率。每个设备都有它自己的约束边界。光伏和风电的出力上限由资源情况决定而且这个上限本身就是不确定参数储能要同时考虑充放电功率限制和SOC上下限还要注意不能让SOC在调度周期开始和结束时差得太大否则下一个周期没法接力联络线功率受变压器容量和购售电协议约束有时候还会被要求功率因数在一定范围。这些约束在确定性问题里都不难写难的是当光伏预测值、负荷预测值变成一个区间而不是一个点时所有涉及这些参数的不等式都要重新设计。储能建模还有一个容易被忽略的细节充放电效率。大多数文献用一个固定的效率值实际电池在不同倍率、不同SOC区间下效率有差异但多阶段鲁棒模型本身计算量就不小再引入非线性效率曲线会显著增加求解难度。我在复现时用的是分段线性近似在SOC范围内划分三段每段给不同的充放电效率系数这样既保住了精度又没有破坏整个模型的线性结构。2.2 目标函数经济性优先还是可靠性兜底目标函数直接反映调度策略的倾向性。常见写法是运行成本最小化包括向上级电网购电的成本、储能充放电的折旧成本以及可能的弃风弃光惩罚。但在鲁棒框架里成本项的写法要尤其谨慎因为“最坏场景下成本最低”和“期望成本最低”本质上是两种不同决策逻辑。我更倾向于采用两阶段决策结构的思路把目标函数写成第一阶段决策变量相关的成本 第二阶段在最坏场景下的运行调整成本。这样做的好处是第一阶段确定储能的充放电计划、联络线功率基准值这些决策在不确定性还未完全暴露时就要拍板第二阶段则根据实际光伏、负荷的偏移量以再调度成本最小为目标调整机组出力。多阶段鲁棒的“多”就体现在这种决策时序的划分上而不是简单地把所有变量放在一个大优化里求解。在实际代码里我会把目标函数的各项费用统一折算成“单个调度时段内每千瓦时的成本”这样不同量纲的成本项可以线性叠加。储能折旧成本采用“单位充放电循环成本 × 实际充放电功率”这比单纯按容量摊销更符合电池的损耗机制。2.3 多阶段与两阶段的本质差异决策时序决定保守程度两阶段鲁棒优化的经典框架是“这里做决策 → 不确定性暴露 → 那里做调整”结构调整上像是先走一步棋再应对。多阶段鲁棒在此基础上引入多个决策时刻每个时段既能看到前期不确定性的部分实现又要为剩下的时段做决策。这意味着调度策略能从“整体打包应对”变成“逐时段滚动修正”保守性大幅下降。用一个简单的例子解释两阶段相当于一次性定好全天96个时段的储能出力基线全天结束才允许调整多阶段则是每15分钟重新定一次后几个时段的基线上一时段的实际风光数据已经成为下一个时段的已知信息。这带来的直接效果是在光伏中午大发、傍晚骤减这类规律性变化明显的场景里多阶段方案的弃光率和失负荷率都更低储能SOC更贴近实际可用范围。但代价也很直观决策变量规模呈“时段数 × 场景数”倍增求解时间会上升。做这个项目时我的经验是先在两阶段模型上把约束和参数调试正确再扩成多阶段否则一上来就多阶段盒式不确定集调试问题的来源根本分不清是建模错误还是求解器数值问题。3. 不确定集怎么构造盒式、盒式椭球还是数据驱动3.1 最常用的四种不确定集类型与取舍多阶段鲁棒里不确定集合的形式直接决定模型的保守程度和可解性。我见过不少复现项目在这一步含糊带过直接套一个盒式集合虽然求解方便但所有时段所有参数都顶到边界调度方案过保守储能几乎一直在预留容量经济性大打折扣。常用不确定集可以归纳为四种盒式、椭球式、多面体式、数据驱动式。盒式集合最直观把每个不确定参数写成一个区间但组合起来最坏情况几乎不可能发生椭球式更精确但会引入二阶锥约束求解器要求升高多面体式通过引入系数限制总偏差是盒式和椭球的折中在实际工程中使用最广数据驱动式则基于历史样本构造包络集合比较新数据量大时效果好但样本质量差会把噪声也包进去。我的实际选择是盒式 总偏差约束的多面体形式。具体来说光伏出力和负荷预测值按下式进入模型实际值 预测值 偏差项偏差项的绝对值不超过各自的上限且所有偏差项的线性组合不超过一个预算系数。这样集合保留了“每个时段都可能偏”的能力又限制了“所有时段同时偏到最坏”的可能性保守程度可以由预算系数连续调节。这个系数就是调鲁棒强度最直接的旋钮。3.2 预算系数的物理意义和取值逻辑预算系数听起来像纯数学参数实际上它对应运行人员对未来不确定性的主观判断。系数取0.5意味着预测偏差超过一半预算的场景就不纳入优化考虑系数取1.0则必须应对所有同时达到边界的最坏场景。取值没有绝对标准但有几个工程经验可以参考对光伏取0.6~0.8比较合适因为光伏出力在晴天有强规律性总偏差不会同时往同一方向极端发展对负荷预测可以取高一些到0.9因为负荷是由多个用户叠加的个体波动叠加后相对稳定对风电要看风况大风天取0.8以上平稳天可以取0.5。在实际代码中预算系数会转化为一个额外的线性约束参与对偶变换或切割平面生成。需要注意的是这个系数一旦改变最优解的保守程度会连续变化但不一定是单调的因为风光储之间的互补关系会在某些区间改变调度策略的结构。做项目汇报时画出“预算系数-运行成本”的曲线会比单纯给一个最优方案有说服力得多。3.3 场景生成从历史数据到最坏场景的抽取逻辑不确定集构建好之后需要生成一组能代表“最坏情况”的离散场景用于多阶段决策过程中的子问题求解。这里有一个常见的误解鲁棒优化不需要场景生成所有场景都在集合内自动覆盖。实际上多阶段问题的求解往往采用列约束生成算法每一轮迭代都需要求解“在当前决策下哪个场景最让系统为难”这个内层问题而内层问题的结果本质上就是从无限场景中抽取出的“最坏场景”。生成过程在MATLAB里很容易做得可视化。我常用linspace构造基准预测曲线再用随机数生成不同幅度的算例偏差叠加形成一个候选场景池然后针对第一阶段的决策用线性规划搜索池中使调整成本最大的那组偏差值。这一步不需要枚举全部组合只需在每一轮CCG迭代时重新求解一次内层max问题。初始的场景池规模不需要太大500组足够因为内层问题的本质是找极端工况极端点通常落在不确定集的顶点附近顶点数量有限。4. 两阶段CCG框架落地从矩阵拼装到迭代求解4.1 大规模约束的矩阵化构造技巧多阶段鲁棒模型的规模比确定性模型大得多如果沿用写确定性模型时“一行约束一个变量”的风格代码会膨胀到无法维护。我的做法是把所有变量分成三个向量第一阶段变量储能充放电、联络线基准功率、第二阶段变量各时段再调度量、辅助变量松弛量。每个阶段的约束用稀疏矩阵拼装统一存入一个结构体数组每一轮迭代只更新受影响的行。MATLAB里构造这种约束矩阵时一定要提前用sparse预分配内存不要用循环去逐行添加。64位系统上直接稀疏矩阵的运算速度能比稠密矩阵快几个量级。还有一个细节是约束矩阵的行顺序先列等式约束再列不等式约束最后列变量边界约束这个顺序能显著减少求解器预处理阶段的时间。4.2 主问题、子问题的信息流与角色分工整个CCG迭代的骨架可以这样概括主问题在给定一组离散场景下求第一阶段变量的最优值子问题则在主问题得到的变量基础上寻找最坏场景并把最坏场景作为新的一组约束送回主问题。这个过程循环往复直到子问题返回的最坏情况偏差值低于阈值说明当前的第一阶段决策在所有场景下都能找到可行调整。从代码结构看主问题和子问题各自是一个optimproblem对象。主问题每次迭代增加一个场景对应的约束组子问题每次迭代只更新第二阶段变量的系数。通信的数据是主问题输出的x_first传给子问题子问题输出的u_worst和lambda回传给主问题。这里最容易出错的环节是子问题返回的对偶变量符号一旦符号反了迭代根本不会收敛。4.3 一个可靠的双层迭代求解流程我在复现时把完整的求解流程固定成了五步。第一步初始化场景集从历史数据中抽一个典型日场景作为首个场景保证主问题有可行解。第二步求解主问题得到第一阶段变量初值。第三步将初值带入子问题求解当前场景集下的最坏偏差值。第四步检查偏差值是否大于收敛阈值若大于则把对应的最坏偏差场景加入主问题场景集并约束新增场景下的第二阶段可行性。第五步重复第二至第四步。收敛阈值的选取直接影响计算时间我试过10^-4和10^-6两档结果差别微乎其微但迭代次数却从平均12轮升到了21轮。实际工程应用中除非要做学术对比实验否则建议阈值取10^-3或10^-4即可。我还会在每次迭代后记录当前主问题的目标值和子问题的偏差值画出一条收敛曲线这条曲线是排查模型错误的最好依据——若是偏差值来回震荡基本可断定是子问题的对偶变换出了问题。5. 储能与联络线的鲁棒约束细节别在最容易忽略的地方翻车5.1 SOC递推约束在不同场景间如何共享储能SOC是一个跨时段的状态量在多阶段模型里处理SOC约束时有个隐蔽的坑SOC的递推关系对每个场景独立成立但每个场景的初始SOC必须由所有场景共用的第一阶段变量决定。这个约束关系写不好会出现一个荒唐的结果——每个场景里储能行为各干各的作为一个物理设备却是多种“分身”。正确做法是把t0时刻的初始SOC设定为第一阶段决策变量所有场景的SOC递推都从同一初始值出发然后各时段的充放电功率在第二阶段是场景相关的这样储能就能在“初始状态一致”的前提下根据不同场景做出不同的充放电调整。代码实现时这个约束对应一组带场景索引的等式矩阵维度会比直觉上大一层拼装时千万别漏了场景索引维。5.2 联络线功率的购售电约束如何避免对称性退化联络线功率在很多模型里被拆成购电和售电两个非负变量物理上合理但数学上会引入对称性退化导致求解器在多个等价解之间反复横跳收敛速度变得很慢。更稳妥的做法是定义一个有符号的联络线变量正值表示购电、负值表示售电并用两个不等式把上下限卡住。不过这样修改后目标函数里的购电成本和售电收入就不能直接乘以一个光标量了。我的处理是把有符号变量拆成两个部分一个买电分量和一个卖电分量二者在约束中互斥用0-1变量控制目标函数分别乘上对应的价格。虽然在连续模型里引入0-1变量会让求解难度上一个台阶但换来的是稳定的收敛性这个交换在实际调试中非常值得。5.3 弃风弃光与失负荷的惩罚权重设计鲁棒优化的最后一道防线是松弛变量即允许在最坏场景下少量弃风弃光或切除次要负荷否则子问题可能直接不可行主问题也会跟着无解。这部分的关键是惩罚系数的量级如果惩罚系数太高松弛变量永远不会被使用等于没有松弛模型退化成纯硬约束如果太低优化会优先用松弛掉出力或负荷的方式降低成本看起来成本很漂亮实际上不是调度策略而是主动摆烂。根据我的经验弃风弃光惩罚单位成本应该设定为购电成本的1.2~1.5倍失负荷惩罚设定为购电成本的10~20倍。这样量级设计下正常情况下不会弃光弃风只有在真正无法消纳的极端场景才会动用松弛符合微电网实际运行中“先保负荷再保新能源消纳”的优先级。6. 求解效率优化热启动、变量缩放和求解器选项调优6.1 为什么默认求解选项会让中大规模算例卡死MATLAB的optimproblem默认使用内点法中小规模问题体验不错但多阶段鲁棒模型的子问题每一轮都要重新求解内点法在迭代后期会浪费大量时间在重新求逆矩阵上。换成对偶单纯形法之后同样的算例求解时间能缩短40%以上因为每一轮的Basis可以继承上一轮的热启动信息。求解器选项里有两个参数对收敛影响巨大一是ConstraintTolerance默认值1e-6我会放宽到1e-5二是OptimalityTolerance放宽到1e-6。这里不要担心精度损失——工程约束本身就建立在预测精度不超过5%的基础上优化精度的微小松弛对结果的影响完全可以接受。我测试过一个48时段的算例容差从1e-6放宽到1e-5后目标值只变化了0.02%求解时间几乎减半。6.2 变量缩放的“意外收获”与数值稳定性不同设备的功率量级差异很大储能功率可能就几百千瓦联络线容量可能到兆瓦级如果不做变量归一化约束矩阵的条件数会非常高。求解器在这种病态问题上容易被数值扰动带着跑时不时冒出一个奇怪的“最优解”其实根本不是可行解。我的解决方案是对所有功率变量统一除以基准功率比如系统最大负荷功率对所有成本变量除以基准成本比如购电价×基准功率然后整个模型都在标幺体系下运行最后再把结果乘回去。这个操作看起来只是多了一步乘除法实际效果是迭代次数更稳定、对偶变量不容易发散。调试时先在标幺模型上验证约束再转回有名值做最终结果分析比在有名值模型里来回找数值问题要高效得多。6.3 场景索引维度如何影响矩阵稀疏度多阶段模型的矩阵规模主要由场景数、时段数、设备数三个维度决定其中场景数维度在迭代中不断增长矩阵稀疏结构也会动态变化。如果一开始就用稠密矩阵存所有场景的约束1万列以上就明显吃力用稀疏矩阵按场景拼接时最好是每个场景的约束行单独成块这样新增场景时只需要做一次块对角拼接不需要改动原有矩阵的索引结构。MATLAB里做块对角拼接有一个自然函数blkdiag但直接在循环里多次调用也会有开销。更高效的做法是先定义每个场景的约束矩阵模板然后一次性生成所有场景的完整矩阵这样能复用许多下标索引计算。代码可读性稍微差一点但换来的是内存峰值大幅下降尤其在96时段、50个场景的规模下这个优化直接决定了能否在普通笔记本上跑完。7. 复现过程中最常见的5类问题与排查路径7.1 迭代发散或震荡主问题目标值在大小值之间横跳出现这种情况时九成原因出在子问题返回的最坏场景没有正确转化为主问题的新约束。我在排查时会先打印每一轮子问题求得的偏差场景数值跟主问题场景集里已有的场景做对比看看新场景是否只是某个旧场景的微小扰动。如果确实是“假新场景”说明子问题的搜索方向不对需要检查内层max问题的约束是否把不确定参数的可行域限制正确。还有一种情况是主问题里对第二阶段变量没有加场景索引导致新增场景约束覆盖了旧场景的决策空间历史场景的最优性被破坏。这个错误在代码上非常隐蔽因为运行不会报错只有数值行为异常。建议在模型中用断言检查每个第二阶段变量是否都有场景维度的索引。7.2 子问题不可行所有场景都通过但最坏场景满足不了本质上是第一阶段让储能背了太多责任预留容量不够导致某些极限偏差下无法调平功率。这里优先检查SOC的上下限约束和初始SOC是否留有余地。如果初始SOC是定死为50%而场景要求连续充电那么后半段SOC可能撞顶子问题自然不可行。修复手段有两个方向一是把初始SOC也纳入不确定集合的优化范围让它有±5%的浮动空间二是增加子问题里的松弛变量以最小化松弛量作为子问题的目标再把松弛量对应的对偶乘子反馈给主问题。工程上我更推荐第一种因为它改动小且物理意义明确。7.3 结果保守度过高光伏大发时段仍在买电很多复现者第一次看到多阶段鲁棒的结果时都会疑惑明明午间光伏预测很高为什么调度还从电网买电这不是bug是因为不确定集设置的预算系数过高模型在防范“光伏突然大幅下降”的最坏情况。处理方法是调整预算系数而不是去怀疑模型的正确性。我习惯在代码里加入一个人工干预开关允许运行人员输入当天是晴、多云还是阴雨的天气预判程序根据预判自动缩放光伏不确定预算系数。实战中这个方法非常实用模型既保留了鲁棒性又不至于在好天气白白浪费清洁电力。7.4 多阶段与两阶段结果几乎一致保守性优势没体现先确认决策时段的划分是否真的实现了“滚动更新”。我曾见过一个复现表面上写了96个时段的多阶段代码实际上所有场景都在初始阶段的决策中被一次性固定后面的“阶段”根本没有决策变量。这等于挂羊头卖狗肉算出来的当然和两阶段一样。检修方法是在第一阶段求解后人为改动光伏出力然后重新求解后续阶段看储能出力是否随之变化。如果变化说明决策确实逐阶段更新如果纹丝不动说明模型没有给后续阶段留决策变量需要修正变量索引的结构。7.5 求解时间过长体现在子问题的重复求解成本上初始场景集太小虽然能让第一轮跑得飞快但会导致CCG迭代需要更多轮次来发现足够多的极端场景。反过来初始场景集过大第一轮就非常慢。我的调节经验是从50个场景起步每连续三轮迭代目标值下降幅度低于0.5%时将场景集扩容到200挤出一轮更宽泛的搜索。这种渐进式策略兼顾了前期速度和后期覆盖度。另一个大优化点是严格检查子问题里是否有冗余约束。比如SOC约束里同时写了上限和下限而上下限在多阶段场景里互不绑定凑在一起会白白增加矩阵行数。用spy画一次矩阵结构图冗余行一眼就能辨认出来。8. 从复现到工程应用这个模型还能往哪些方向延伸鲁棒调度模型跑通只是起点我实际交付项目时发现客户最关心的往往不是模型本身而是能不能在原有设备拓扑上快速适配。如果某个节点新增了一台储能柜模型里只需要增加一组变量和约束CCG框架的主问题会自动把新设备的容量纳入场景保障这个扩展性是我选择这套框架的重要原因。另一个让模型真正落地的方向是跟日内滚动计划结合。多阶段鲁棒天然支持“每15分钟滚动优化一次”的运行逻辑只要把时段索引循环起来每次滚动时把上一时段的实测数据作为已知输入模型就会自动修正剩余时段的策略。这个特性在跟现场运行人员介绍时特别加分因为这意味着调度策略不是一份好看的报告而是一个能跟SCADA系统实时对接的动态控制器。关于风光预测误差的建模目前也有很多团队在做0到1小时的超短期预测与鲁棒结合的尝试。思路是在多阶段框架的每个决策点重新训练一次不确定集参数随最新气象信息更新。这个方向的代码实现比固定不确定集复杂很多但效益明显尤其是在台风、冷锋过境这类天气剧变的时段模型对事件的响应速度远超市值预测更新频率。最后再分享一个我自己实践中的体会这类模型最怕的不是数学推不出来而是运行人员看不懂结果、不敢用结果。我在每次交付时都会增加一张“最坏场景日历表”把模型在该场景下给出的调度指令逐条翻译成通俗语言比如“11:00至14:00光伏功率下调18%储能充电功率下调至120kW联络线购入功率提升至360kW”。让现场人员真正理解“这个方案在防什么、怎么做、为什么这么做”鲁棒调度才算真正落地否则再强的保守性设计也只是一堆没人敢按的按钮。 
长河君 · 2026/10/19 10:58:36 · 阅读 1.2k 区域微电网多阶段鲁棒优化调度：从不确定集构建到CCG求解
1. 调度问题从哪里开始区域微电网为什么非做鲁棒不可接手“含可再生能源和储能的区域微电网最优运行”这个题目时很多人第一反应是先找代码、先跑通模型但真到了现场你会发现最难的从来不是求解器怎么调而是“不确定的东西怎么描述”。风、光出力天然波动负荷侧又有预测误差如果调度方案只按某一组确定数值来算那这个方案在第二天八成是废纸一张。实际运行里我踩过的坑就是确定性调度模型在仿真里指标很漂亮一接入实时数据就频繁需要人工干预根源就在于没有把不确定性放进优化过程本身。这也就是多阶段鲁棒调度模型存在的意义。它跟随机规划不同不需要强行假设光伏、风电、负荷服从某个具体概率分布而是用一个“不确定集合”把可能出现的场景先框起来然后求解在“最坏情况”下仍然可行的调度策略。对于微电网这种规模不大、但运行约束错综复杂的系统来说这种做法格外合适不用为了概率分布的精确性做太多统计工作又能保证方案在绝大多数工况下不越限、不失负荷、不损坏储能。本文适合三类人一是刚接触微电网优化、想弄明白鲁棒和随机规划差别的学生二是手里已经有一套确定性调度代码、想升级成带不确定性处理的工程师三是做项目汇报时需要解释“为什么采用多阶段鲁棒而非两阶段鲁棒”的落地人员。我会从模型逻辑、场景构造、MATLAB实现细节和求解坑点几个层面展开尽量做到照着文章能自己搭出一版可运行的多阶段鲁棒调度框架。2. 模型到底在算什么东西设备建模与目标函数拆解2.1 微电网里的设备对象和运行边界先不碰鲁棒理论把物理对象说清楚。一个典型的区域微电网至少包含光伏阵列、风力机组、储能电池、本地负荷以及和上级电网的交换接口。部分场景里还有柴油发电机或微型燃气轮机但“含可再生能源和储能”这个题目限定下核心设备就是风光储加联络线功率。每个设备都有它自己的约束边界。光伏和风电的出力上限由资源情况决定而且这个上限本身就是不确定参数储能要同时考虑充放电功率限制和SOC上下限还要注意不能让SOC在调度周期开始和结束时差得太大否则下一个周期没法接力联络线功率受变压器容量和购售电协议约束有时候还会被要求功率因数在一定范围。这些约束在确定性问题里都不难写难的是当光伏预测值、负荷预测值变成一个区间而不是一个点时所有涉及这些参数的不等式都要重新设计。储能建模还有一个容易被忽略的细节充放电效率。大多数文献用一个固定的效率值实际电池在不同倍率、不同SOC区间下效率有差异但多阶段鲁棒模型本身计算量就不小再引入非线性效率曲线会显著增加求解难度。我在复现时用的是分段线性近似在SOC范围内划分三段每段给不同的充放电效率系数这样既保住了精度又没有破坏整个模型的线性结构。2.2 目标函数经济性优先还是可靠性兜底目标函数直接反映调度策略的倾向性。常见写法是运行成本最小化包括向上级电网购电的成本、储能充放电的折旧成本以及可能的弃风弃光惩罚。但在鲁棒框架里成本项的写法要尤其谨慎因为“最坏场景下成本最低”和“期望成本最低”本质上是两种不同决策逻辑。我更倾向于采用两阶段决策结构的思路把目标函数写成第一阶段决策变量相关的成本 第二阶段在最坏场景下的运行调整成本。这样做的好处是第一阶段确定储能的充放电计划、联络线功率基准值这些决策在不确定性还未完全暴露时就要拍板第二阶段则根据实际光伏、负荷的偏移量以再调度成本最小为目标调整机组出力。多阶段鲁棒的“多”就体现在这种决策时序的划分上而不是简单地把所有变量放在一个大优化里求解。在实际代码里我会把目标函数的各项费用统一折算成“单个调度时段内每千瓦时的成本”这样不同量纲的成本项可以线性叠加。储能折旧成本采用“单位充放电循环成本 × 实际充放电功率”这比单纯按容量摊销更符合电池的损耗机制。2.3 多阶段与两阶段的本质差异决策时序决定保守程度两阶段鲁棒优化的经典框架是“这里做决策 → 不确定性暴露 → 那里做调整”结构调整上像是先走一步棋再应对。多阶段鲁棒在此基础上引入多个决策时刻每个时段既能看到前期不确定性的部分实现又要为剩下的时段做决策。这意味着调度策略能从“整体打包应对”变成“逐时段滚动修正”保守性大幅下降。用一个简单的例子解释两阶段相当于一次性定好全天96个时段的储能出力基线全天结束才允许调整多阶段则是每15分钟重新定一次后几个时段的基线上一时段的实际风光数据已经成为下一个时段的已知信息。这带来的直接效果是在光伏中午大发、傍晚骤减这类规律性变化明显的场景里多阶段方案的弃光率和失负荷率都更低储能SOC更贴近实际可用范围。但代价也很直观决策变量规模呈“时段数 × 场景数”倍增求解时间会上升。做这个项目时我的经验是先在两阶段模型上把约束和参数调试正确再扩成多阶段否则一上来就多阶段盒式不确定集调试问题的来源根本分不清是建模错误还是求解器数值问题。3. 不确定集怎么构造盒式、盒式椭球还是数据驱动3.1 最常用的四种不确定集类型与取舍多阶段鲁棒里不确定集合的形式直接决定模型的保守程度和可解性。我见过不少复现项目在这一步含糊带过直接套一个盒式集合虽然求解方便但所有时段所有参数都顶到边界调度方案过保守储能几乎一直在预留容量经济性大打折扣。常用不确定集可以归纳为四种盒式、椭球式、多面体式、数据驱动式。盒式集合最直观把每个不确定参数写成一个区间但组合起来最坏情况几乎不可能发生椭球式更精确但会引入二阶锥约束求解器要求升高多面体式通过引入系数限制总偏差是盒式和椭球的折中在实际工程中使用最广数据驱动式则基于历史样本构造包络集合比较新数据量大时效果好但样本质量差会把噪声也包进去。我的实际选择是盒式 总偏差约束的多面体形式。具体来说光伏出力和负荷预测值按下式进入模型实际值 预测值 偏差项偏差项的绝对值不超过各自的上限且所有偏差项的线性组合不超过一个预算系数。这样集合保留了“每个时段都可能偏”的能力又限制了“所有时段同时偏到最坏”的可能性保守程度可以由预算系数连续调节。这个系数就是调鲁棒强度最直接的旋钮。3.2 预算系数的物理意义和取值逻辑预算系数听起来像纯数学参数实际上它对应运行人员对未来不确定性的主观判断。系数取0.5意味着预测偏差超过一半预算的场景就不纳入优化考虑系数取1.0则必须应对所有同时达到边界的最坏场景。取值没有绝对标准但有几个工程经验可以参考对光伏取0.6~0.8比较合适因为光伏出力在晴天有强规律性总偏差不会同时往同一方向极端发展对负荷预测可以取高一些到0.9因为负荷是由多个用户叠加的个体波动叠加后相对稳定对风电要看风况大风天取0.8以上平稳天可以取0.5。在实际代码中预算系数会转化为一个额外的线性约束参与对偶变换或切割平面生成。需要注意的是这个系数一旦改变最优解的保守程度会连续变化但不一定是单调的因为风光储之间的互补关系会在某些区间改变调度策略的结构。做项目汇报时画出“预算系数-运行成本”的曲线会比单纯给一个最优方案有说服力得多。3.3 场景生成从历史数据到最坏场景的抽取逻辑不确定集构建好之后需要生成一组能代表“最坏情况”的离散场景用于多阶段决策过程中的子问题求解。这里有一个常见的误解鲁棒优化不需要场景生成所有场景都在集合内自动覆盖。实际上多阶段问题的求解往往采用列约束生成算法每一轮迭代都需要求解“在当前决策下哪个场景最让系统为难”这个内层问题而内层问题的结果本质上就是从无限场景中抽取出的“最坏场景”。生成过程在MATLAB里很容易做得可视化。我常用linspace构造基准预测曲线再用随机数生成不同幅度的算例偏差叠加形成一个候选场景池然后针对第一阶段的决策用线性规划搜索池中使调整成本最大的那组偏差值。这一步不需要枚举全部组合只需在每一轮CCG迭代时重新求解一次内层max问题。初始的场景池规模不需要太大500组足够因为内层问题的本质是找极端工况极端点通常落在不确定集的顶点附近顶点数量有限。4. 两阶段CCG框架落地从矩阵拼装到迭代求解4.1 大规模约束的矩阵化构造技巧多阶段鲁棒模型的规模比确定性模型大得多如果沿用写确定性模型时“一行约束一个变量”的风格代码会膨胀到无法维护。我的做法是把所有变量分成三个向量第一阶段变量储能充放电、联络线基准功率、第二阶段变量各时段再调度量、辅助变量松弛量。每个阶段的约束用稀疏矩阵拼装统一存入一个结构体数组每一轮迭代只更新受影响的行。MATLAB里构造这种约束矩阵时一定要提前用sparse预分配内存不要用循环去逐行添加。64位系统上直接稀疏矩阵的运算速度能比稠密矩阵快几个量级。还有一个细节是约束矩阵的行顺序先列等式约束再列不等式约束最后列变量边界约束这个顺序能显著减少求解器预处理阶段的时间。4.2 主问题、子问题的信息流与角色分工整个CCG迭代的骨架可以这样概括主问题在给定一组离散场景下求第一阶段变量的最优值子问题则在主问题得到的变量基础上寻找最坏场景并把最坏场景作为新的一组约束送回主问题。这个过程循环往复直到子问题返回的最坏情况偏差值低于阈值说明当前的第一阶段决策在所有场景下都能找到可行调整。从代码结构看主问题和子问题各自是一个optimproblem对象。主问题每次迭代增加一个场景对应的约束组子问题每次迭代只更新第二阶段变量的系数。通信的数据是主问题输出的x_first传给子问题子问题输出的u_worst和lambda回传给主问题。这里最容易出错的环节是子问题返回的对偶变量符号一旦符号反了迭代根本不会收敛。4.3 一个可靠的双层迭代求解流程我在复现时把完整的求解流程固定成了五步。第一步初始化场景集从历史数据中抽一个典型日场景作为首个场景保证主问题有可行解。第二步求解主问题得到第一阶段变量初值。第三步将初值带入子问题求解当前场景集下的最坏偏差值。第四步检查偏差值是否大于收敛阈值若大于则把对应的最坏偏差场景加入主问题场景集并约束新增场景下的第二阶段可行性。第五步重复第二至第四步。收敛阈值的选取直接影响计算时间我试过10^-4和10^-6两档结果差别微乎其微但迭代次数却从平均12轮升到了21轮。实际工程应用中除非要做学术对比实验否则建议阈值取10^-3或10^-4即可。我还会在每次迭代后记录当前主问题的目标值和子问题的偏差值画出一条收敛曲线这条曲线是排查模型错误的最好依据——若是偏差值来回震荡基本可断定是子问题的对偶变换出了问题。5. 储能与联络线的鲁棒约束细节别在最容易忽略的地方翻车5.1 SOC递推约束在不同场景间如何共享储能SOC是一个跨时段的状态量在多阶段模型里处理SOC约束时有个隐蔽的坑SOC的递推关系对每个场景独立成立但每个场景的初始SOC必须由所有场景共用的第一阶段变量决定。这个约束关系写不好会出现一个荒唐的结果——每个场景里储能行为各干各的作为一个物理设备却是多种“分身”。正确做法是把t0时刻的初始SOC设定为第一阶段决策变量所有场景的SOC递推都从同一初始值出发然后各时段的充放电功率在第二阶段是场景相关的这样储能就能在“初始状态一致”的前提下根据不同场景做出不同的充放电调整。代码实现时这个约束对应一组带场景索引的等式矩阵维度会比直觉上大一层拼装时千万别漏了场景索引维。5.2 联络线功率的购售电约束如何避免对称性退化联络线功率在很多模型里被拆成购电和售电两个非负变量物理上合理但数学上会引入对称性退化导致求解器在多个等价解之间反复横跳收敛速度变得很慢。更稳妥的做法是定义一个有符号的联络线变量正值表示购电、负值表示售电并用两个不等式把上下限卡住。不过这样修改后目标函数里的购电成本和售电收入就不能直接乘以一个光标量了。我的处理是把有符号变量拆成两个部分一个买电分量和一个卖电分量二者在约束中互斥用0-1变量控制目标函数分别乘上对应的价格。虽然在连续模型里引入0-1变量会让求解难度上一个台阶但换来的是稳定的收敛性这个交换在实际调试中非常值得。5.3 弃风弃光与失负荷的惩罚权重设计鲁棒优化的最后一道防线是松弛变量即允许在最坏场景下少量弃风弃光或切除次要负荷否则子问题可能直接不可行主问题也会跟着无解。这部分的关键是惩罚系数的量级如果惩罚系数太高松弛变量永远不会被使用等于没有松弛模型退化成纯硬约束如果太低优化会优先用松弛掉出力或负荷的方式降低成本看起来成本很漂亮实际上不是调度策略而是主动摆烂。根据我的经验弃风弃光惩罚单位成本应该设定为购电成本的1.2~1.5倍失负荷惩罚设定为购电成本的10~20倍。这样量级设计下正常情况下不会弃光弃风只有在真正无法消纳的极端场景才会动用松弛符合微电网实际运行中“先保负荷再保新能源消纳”的优先级。6. 求解效率优化热启动、变量缩放和求解器选项调优6.1 为什么默认求解选项会让中大规模算例卡死MATLAB的optimproblem默认使用内点法中小规模问题体验不错但多阶段鲁棒模型的子问题每一轮都要重新求解内点法在迭代后期会浪费大量时间在重新求逆矩阵上。换成对偶单纯形法之后同样的算例求解时间能缩短40%以上因为每一轮的Basis可以继承上一轮的热启动信息。求解器选项里有两个参数对收敛影响巨大一是ConstraintTolerance默认值1e-6我会放宽到1e-5二是OptimalityTolerance放宽到1e-6。这里不要担心精度损失——工程约束本身就建立在预测精度不超过5%的基础上优化精度的微小松弛对结果的影响完全可以接受。我测试过一个48时段的算例容差从1e-6放宽到1e-5后目标值只变化了0.02%求解时间几乎减半。6.2 变量缩放的“意外收获”与数值稳定性不同设备的功率量级差异很大储能功率可能就几百千瓦联络线容量可能到兆瓦级如果不做变量归一化约束矩阵的条件数会非常高。求解器在这种病态问题上容易被数值扰动带着跑时不时冒出一个奇怪的“最优解”其实根本不是可行解。我的解决方案是对所有功率变量统一除以基准功率比如系统最大负荷功率对所有成本变量除以基准成本比如购电价×基准功率然后整个模型都在标幺体系下运行最后再把结果乘回去。这个操作看起来只是多了一步乘除法实际效果是迭代次数更稳定、对偶变量不容易发散。调试时先在标幺模型上验证约束再转回有名值做最终结果分析比在有名值模型里来回找数值问题要高效得多。6.3 场景索引维度如何影响矩阵稀疏度多阶段模型的矩阵规模主要由场景数、时段数、设备数三个维度决定其中场景数维度在迭代中不断增长矩阵稀疏结构也会动态变化。如果一开始就用稠密矩阵存所有场景的约束1万列以上就明显吃力用稀疏矩阵按场景拼接时最好是每个场景的约束行单独成块这样新增场景时只需要做一次块对角拼接不需要改动原有矩阵的索引结构。MATLAB里做块对角拼接有一个自然函数blkdiag但直接在循环里多次调用也会有开销。更高效的做法是先定义每个场景的约束矩阵模板然后一次性生成所有场景的完整矩阵这样能复用许多下标索引计算。代码可读性稍微差一点但换来的是内存峰值大幅下降尤其在96时段、50个场景的规模下这个优化直接决定了能否在普通笔记本上跑完。7. 复现过程中最常见的5类问题与排查路径7.1 迭代发散或震荡主问题目标值在大小值之间横跳出现这种情况时九成原因出在子问题返回的最坏场景没有正确转化为主问题的新约束。我在排查时会先打印每一轮子问题求得的偏差场景数值跟主问题场景集里已有的场景做对比看看新场景是否只是某个旧场景的微小扰动。如果确实是“假新场景”说明子问题的搜索方向不对需要检查内层max问题的约束是否把不确定参数的可行域限制正确。还有一种情况是主问题里对第二阶段变量没有加场景索引导致新增场景约束覆盖了旧场景的决策空间历史场景的最优性被破坏。这个错误在代码上非常隐蔽因为运行不会报错只有数值行为异常。建议在模型中用断言检查每个第二阶段变量是否都有场景维度的索引。7.2 子问题不可行所有场景都通过但最坏场景满足不了本质上是第一阶段让储能背了太多责任预留容量不够导致某些极限偏差下无法调平功率。这里优先检查SOC的上下限约束和初始SOC是否留有余地。如果初始SOC是定死为50%而场景要求连续充电那么后半段SOC可能撞顶子问题自然不可行。修复手段有两个方向一是把初始SOC也纳入不确定集合的优化范围让它有±5%的浮动空间二是增加子问题里的松弛变量以最小化松弛量作为子问题的目标再把松弛量对应的对偶乘子反馈给主问题。工程上我更推荐第一种因为它改动小且物理意义明确。7.3 结果保守度过高光伏大发时段仍在买电很多复现者第一次看到多阶段鲁棒的结果时都会疑惑明明午间光伏预测很高为什么调度还从电网买电这不是bug是因为不确定集设置的预算系数过高模型在防范“光伏突然大幅下降”的最坏情况。处理方法是调整预算系数而不是去怀疑模型的正确性。我习惯在代码里加入一个人工干预开关允许运行人员输入当天是晴、多云还是阴雨的天气预判程序根据预判自动缩放光伏不确定预算系数。实战中这个方法非常实用模型既保留了鲁棒性又不至于在好天气白白浪费清洁电力。7.4 多阶段与两阶段结果几乎一致保守性优势没体现先确认决策时段的划分是否真的实现了“滚动更新”。我曾见过一个复现表面上写了96个时段的多阶段代码实际上所有场景都在初始阶段的决策中被一次性固定后面的“阶段”根本没有决策变量。这等于挂羊头卖狗肉算出来的当然和两阶段一样。检修方法是在第一阶段求解后人为改动光伏出力然后重新求解后续阶段看储能出力是否随之变化。如果变化说明决策确实逐阶段更新如果纹丝不动说明模型没有给后续阶段留决策变量需要修正变量索引的结构。7.5 求解时间过长体现在子问题的重复求解成本上初始场景集太小虽然能让第一轮跑得飞快但会导致CCG迭代需要更多轮次来发现足够多的极端场景。反过来初始场景集过大第一轮就非常慢。我的调节经验是从50个场景起步每连续三轮迭代目标值下降幅度低于0.5%时将场景集扩容到200挤出一轮更宽泛的搜索。这种渐进式策略兼顾了前期速度和后期覆盖度。另一个大优化点是严格检查子问题里是否有冗余约束。比如SOC约束里同时写了上限和下限而上下限在多阶段场景里互不绑定凑在一起会白白增加矩阵行数。用spy画一次矩阵结构图冗余行一眼就能辨认出来。8. 从复现到工程应用这个模型还能往哪些方向延伸鲁棒调度模型跑通只是起点我实际交付项目时发现客户最关心的往往不是模型本身而是能不能在原有设备拓扑上快速适配。如果某个节点新增了一台储能柜模型里只需要增加一组变量和约束CCG框架的主问题会自动把新设备的容量纳入场景保障这个扩展性是我选择这套框架的重要原因。另一个让模型真正落地的方向是跟日内滚动计划结合。多阶段鲁棒天然支持“每15分钟滚动优化一次”的运行逻辑只要把时段索引循环起来每次滚动时把上一时段的实测数据作为已知输入模型就会自动修正剩余时段的策略。这个特性在跟现场运行人员介绍时特别加分因为这意味着调度策略不是一份好看的报告而是一个能跟SCADA系统实时对接的动态控制器。关于风光预测误差的建模目前也有很多团队在做0到1小时的超短期预测与鲁棒结合的尝试。思路是在多阶段框架的每个决策点重新训练一次不确定集参数随最新气象信息更新。这个方向的代码实现比固定不确定集复杂很多但效益明显尤其是在台风、冷锋过境这类天气剧变的时段模型对事件的响应速度远超市值预测更新频率。最后再分享一个我自己实践中的体会这类模型最怕的不是数学推不出来而是运行人员看不懂结果、不敢用结果。我在每次交付时都会增加一张“最坏场景日历表”把模型在该场景下给出的调度指令逐条翻译成通俗语言比如“11:00至14:00光伏功率下调18%储能充电功率下调至120kW联络线购入功率提升至360kW”。让现场人员真正理解“这个方案在防什么、怎么做、为什么这么做”鲁棒调度才算真正落地否则再强的保守性设计也只是一堆没人敢按的按钮。