冰蓄冷空调在冷热电联供微网中的多时间尺度优化调度

做含冰蓄冷空调的冷热电联供型微网多时间尺度优化调度我最初的思路是“在原有电热联供模型里多加一个蓄能设备”结果发现整套调度逻辑都被改写了。冰蓄冷空调表面上只是一台可以制冰的制冷机但它把原本刚性的冷负荷变成了可以跨时段迁移的弹性资源配合峰谷电价差和燃气轮机的余热利用整个微网可以在电、热、冷三个维度上同时做经济性寻优。这篇文章把我在 Matlab 里搭建该多时间尺度优化调度框架的完整思路梳理一遍重点说清楚为什么需要“日前计划日内滚动”两级调度、蓄冰槽的状态约束到底怎么建、代码如何组织和求解以及模型跑通之后实际调参踩过的几个坑。如果你正在做微网调度、综合能源系统优化或者想复现论文里的这类算例可以拿这篇文章做个参照。说明文中所有设备参数和算例数据来自我自己的模拟项目不同场景下需要根据实际微网配置重新标定但建模思路和代码组织方式是可以直接迁移的。1. 冰蓄冷空调在冷热电联供微网中的定位把冷量变成可时移的弹性资源1.1 电冷热三条能量流的耦合关系冷热电联供型微网的典型结构是天然气进入燃气轮机发电发电产生的余热被回收装置收集一部分直接供热一部分驱动吸收式制冷机制冷电制冷机和蓄冰空调则作为电侧的补充冷源。这里的核心难点在于三条能量流不是独立的——燃气轮机发电量一变余热量跟着变吸收式制冷机的冷量也随之变化而冷负荷本身又是分钟级波动的。以前做纯电热联供调度时我只需要管电平衡和热平衡两条线加入冷负荷和冰蓄冷之后平衡约束从二维变成三维而且蓄冰槽自身是带状态量的设备调度问题也从“逐时段静态决策”变成了“跨时段状态依赖决策”。这种耦合直接决定了模型的复杂度。冷负荷高峰如果全部靠电制冷机扛电平衡会出现一个很大的尖峰如果不扛就必须靠吸收式制冷机多出力而这又受制于燃气轮机此时的余热回收量。所以你会看到冷负荷的削峰本质上要么是电侧的削峰要么是热侧的增发而蓄冰空调提供的是第三种路径把冷负荷整体搬到别的时段去处理。1.2 蓄冰储能和电储能的取舍有人会问微网里已经有电池储能了为什么还要专门建模冰蓄冷空调我的体会是两者能流形态完全不同。电池放的是电蓄冰槽放的是冷。理论上电能可以转化为冷但经过电制冷机 COP 3.5 左右的转换冷量等价成本里已经叠了一层效率损失反过来蓄冰槽在谷电时段用合适的 COP 制冰存冷高峰时段直接融冰供冷正好就在冷负荷侧完成削峰。如果指望电池同时扛住冷负荷峰值储能容量要翻好几倍经济上很不划算。从实际工程经济性看蓄冰槽的造价单位通常是按冷量 kWh 折算的比电池按电量 kWh 折算便宜得多这也促使它在楼宇综合能源、区域供冷场景里被大量使用。所以我的结论一直是在冷热电联供微网里冰蓄冷空调的价值不是替代电池而是把冷负荷从电平衡里“择出来”让电平衡的波动更平缓成本更低。1.3 模型里的角色定位储能型设备从调度模型的角度看冰蓄冷空调的本质就是一个储能型设备。设备状态用蓄冰量 SOC 描述运行模式分制冰、融冰、停机三种有些工况还允许制冰的同时供冷。它的储能效率不是 100%制冰过程 COP 比直接制冷低融冰也不能像电池放电那样瞬时满放这些特性直接决定它在目标函数里的行为——低谷电价时段吸收功率制冰高峰时段释放冷量替代电制冷出力。如果把蓄冰槽只看成一个冷负荷缓冲器而不给它加详细的 SOC 和速率约束优化结果会非常激进后面我会专门说这个问题。2. 两级调度框架日前定计划日内纠偏差2.1 日前调度怎么定“基调”多时间尺度调度的第一层是日前调度时间粒度通常取 1 小时共 24 个时段。它基于日前预测的光伏出力、冷热电负荷和电价曲线求解整个系统全天的最优运行计划。决策变量包括燃气轮机各时段出力、吸收式制冷机出力、电制冷机耗电功率、蓄冰槽制冰和融冰功率、与电网的购售电功率等。目标函数是全天运行成本最小包含购气成本、购电费用、售电收益、设备运维成本几项。这里有一个很多第一次做蓄冰模型的人容易漏掉的约束蓄冰槽 SOC 的日循环约束也就是一天结束后蓄冰量要回到起始水平。如果不加这条约束优化模型可以把蓄冰槽的“存量”当作免费资源白嫖掉得出的日前成本显著偏低且不可执行。类似地电池储能的日循环约束也有这个作用。加完日循环约束之后日前解才是一个可持续运行的计划。2.2 日内滚动优化的步长和窗口日内调度面对的是真实运行时刻。光伏和冷负荷的日前预测误差在实际项目中经常超过 20%如果只盯着日前计划执行某些时段会出现功率缺口或冷量不足。正确的做法是滚动时域控制在每个控制时刻比如每 15 分钟基于最新预测对未来 4 小时重新求解一个有限时域优化问题但只执行第一个时段的结果下一个时刻窗口向前滑动再重新预测、重新求解。控制步长和预测时域的选择有讲究。步长太短求解次数太多对数据刷新频率要求高步长太长又跟不上负荷的分钟级突变。我自己常用的是 15 分钟步长配 4 小时预测时域这个组合既能覆盖冷负荷午间和傍晚的两次高峰形态又不至于让滚动计算量失控。算下来一天滚动 96 次每次求解一个 16 时段的线性规划问题速度完全没问题。2.3 两个尺度之间的衔接SOC 轨迹做“契约”这是多时间尺度调度里最容易翻车的一环。日内优化如果完全不参考日前计划的 SOC 轨迹它会只顾眼前几个时段的成本把蓄冰量提前耗尽等到傍晚冷负荷高峰真的来了只能靠高价电制冷硬扛经济性反而变差。我的处理办法是在日内目标函数里加一个对日前 SOC 轨迹的跟踪项min 运行成本 ω · Σ(SOC_日内(t) - SOC_日前(t))²权重 ω 不能太大否则日内预测更新就失去意义也不能太小否则 SOC 轨迹跑得没边。我一般在典型日场景里做几次回测先取 0 跑一遍看偏差量级再逐步增大直到日内 SOC 曲线与日前计划的偏差收敛到可接受范围我自己用的算例里 ω 落在 0.1~0.5 之间效果比较好。这个思路相当于把日前计划作为“软约束”既保留了日内预测更新的灵活性又维持了蓄冰槽的日内蓄放节奏。3. 关键设备建模与约束搭建3.1 燃气轮机的电热气三联动模型燃气轮机是整个联供系统的核心也是建模时最容易出错的地方。简化的可靠做法是给定发电效率 η_MT常数或者按负载率查表输入燃料量与发电功率满足F_gas(t) P_MT(t) / η_MT发电产生的余热进入回收装置可用热量近似写成Q_hr(t) (1 - η_MT) · F_gas(t) · η_rec其中 η_rec 是余热利用效率工程上取 0.7~0.85 比较常见。回收热量一部分直接供给热负荷一部分进入吸收式制冷机驱动制冷剩余部分可以放空所以热平衡约束用不等式而不是等式。这种三联动模型虽然简化但对调度层面的净收益分析完全够用也比查表插值好写得多。3.2 吸收式制冷机与电制冷机的出力模型吸收式制冷机本质上是“热-冷”转换设备制冷量等于输入热功率乘以 COP_absCOP_abs 一般在 1.2~1.4 之间。这里要注意吸收式制冷机的输入是余热不是电所以在热平衡约束里要把这部分输入热量算进去而它产出的冷量又出现在冷平衡约束里建模时经常有人重复计算或者漏算。电制冷机模型更直觉制冷量等于耗电功率乘以 COP_ec额定工况下 COP_ec 可以取 3.5~4.5。部分负载下 COP 会掉但在线性规划模型里通常固定用额定 COP 近似误差在可接受范围内。如果希望更准确可以对 COP 做分段线性化这会让模型复杂不少我通常只在精度要求比较高的算例中才这么做。还有一个实际工程细节两台制冷机都需要设置出力上下限如果目标函数里没有启停变量最小出力别设成严格 0 再加一个很低的成本系数否则模型会让制冷机在 0 和较大出力之间频繁跳动日内执行时很难受。3.3 约束中的热放空处理热能不像电能那样必须时刻平衡余热过剩时可以放空。所以在热平衡约束里我把可用余热写成Q_hr(t) L_h(t) Q_in_abs(t) Q_dump(t)其中 Q_dump(t) 是非负的弃热变量。这样处理有几个好处一是等式约束比不等式更容易让求解器稳定收敛二是后续做能效分析时弃热量的数值可以直接拉出来看方便定位“余热利用率低”的时段。这个方法在做联供系统优化时几乎是标配建议直接写进模型。4. 蓄放冰策略里的细节约束4.1 蓄冰槽 SOC 状态方程与循环约束蓄冰槽的状态本质上和电池 SOC 一模一样。以小时为步长蓄冰槽容量记作 Q_capkWh制冰冷功率 Q_chkW融冰放冷功率 Q_meltkW制冰的冷量转化效率 η_ch 取 0.75~0.85状态递推关系为SOC(t1) SOC(t) (η_ch · Q_ch(t) - Q_melt(t)) · Δt / Q_cap注意单位如果 Δt 的单位是小时Q_cap 的单位是 kWh那么 Q_ch(t) 乘以 Δt 就是这段时间累计的冷量增量再除以容量得到 SOC 变化量。这个式子写完配合上下限约束 SOC_min ≤ SOC ≤ SOC_max就构成了蓄冰槽的核心状态模型。SOC 上下限我一般取 0.05 到 0.95不满量程 0~1因为蓄冰槽末端换热效率会明显下降硬塞满反而让融冰速率变慢。4.2 融冰速率上限的实践意义很多初学者只给蓄冰槽加 SOC 上下限漏了融冰速率上限 Q_melt(t) ≤ Q_melt_max。这条约束的实际意义非常大——蓄冰槽不是电池冰融化的换热速度受换热器面积和传热温差限制一个小时内能把额定功率的多少倍释放出来是物理上限约束的绝不能按照 SOC 里还有存量就无限放。我第一次跑模型时没加这条优化结果出现了一个时段融冰 150 kW、下一个时段融冰 0 kW 的剧烈切换真到工程上这个动作根本执行不出来。加上 Q_melt_max 之后蓄冰槽的“功率特性”才算真正进模型。Q_melt_max 的取值一般和蓄冰槽的换热器设计相关算例里我按蓄冰槽额定放冷功率来标定大约等于容量的 1/4 到 1/3 每小时。这个参数对结果影响很大值得单独做几次敏感性分析。4.3 峰谷电价下的典型蓄放冰曲线模型跑通之后一个典型的削峰填谷模式会自动涌现出来谷电时段比如凌晨 0 点到 6 点电制冷机一边供冷一边制冰蓄冰槽 SOC 稳步上升白天高电价时段优先融冰供冷吸收式制冷机尽量满发电制冷机降载运行。从 SOC 曲线上看蓄冰槽呈现“夜里蓄、白天放”的大锯齿形态这正是冰蓄冷参与冷热电联供调度后应当出现的结果。同时我也观察到蓄冰槽的蓄冰动作往往不是集中在单个最低价时段而是倾向于分布在连续几个低价时段。原因是融冰速率上限限制了每个时段能放出的冷量如果集中在某个时段蓄满对应的高峰时段也不可能全部放出来必须让蓄冰量跨多个高峰时段逐步释放。这个现象如果只看单时段静态优化是看不到的也就解释了为什么必须做跨时段的优化调度。5. Matlab 代码实现变量编排、约束组装与求解5.1 决策变量的组织方式多时间尺度优化调度在 Matlab 里实现我推荐用 YALMIP 建模再加 Gurobi 或 Cplex 求解。变量组织有一个很实用的小技巧不要建几十个命名变量而是把所有时段变量按固定顺序拼成一个大的列向量 x再通过索引切片来引用每一类变量。以日前模型为例7 类变量乘以 24 个时段总共 168 个决策变量变量顺序燃气轮机出力、吸收式制冷出力、电制冷耗电、蓄冰功率、融冰功率、购电功率、蓄冰SOC nH 24; nVar 7 * nH; x sdpvar(nVar, 1); P_mt x(1:nH); Q_abs x(nH1:2*nH); P_ec x(2*nH1:3*nH); Q_ch x(3*nH1:4*nH); Q_melt x(4*nH1:5*nH); P_buy x(5*nH1:6*nH); SOC x(6*nH1:7*nH);这样写后续目标函数和约束都用切片表达代码结构非常清晰也方便日后把 24 时段改成 96 时段或者扩展到 12 类变量。5.2 约束矩阵与成本向量的组装YALMIP 里约束可以直接写成表达式不需要手动拼接稀疏矩阵这是比手写 linprog 矩阵高效得多的原因。核心约束大概长这样Constraints []; %% 电功率平衡 for t 1:nH Constraints [Constraints, ... P_pv(t) P_mt(t) P_buy(t) L_e(t) P_ec(t) Q_ch(t)/COP_ice P_sell(t)]; end %% 冷量平衡 for t 1:nH Constraints [Constraints, ... COP_ec * P_ec(t) COP_abs * Q_abs(t) Q_melt(t) L_c(t)]; end %% 热平衡含弃热 Q_hr (1 - eta_mt) * (P_mt / eta_mt) * eta_rec; Q_dump sdpvar(nH, 1); for t 1:nH Constraints [Constraints, ... Q_hr(t) L_h(t) Q_abs(t)/COP_abs Q_dump(t)]; end %% 蓄冰槽SOC递推与约束 Constraints [Constraints, SOC(1) SOC_init]; for t 1:nH-1 Constraints [Constraints, ... SOC(t1) SOC(t) (eta_ice * Q_ch(t) - Q_melt(t)) * dt / Q_cap]; end Constraints [Constraints, SOC_min SOC SOC_max]; Constraints [Constraints, 0 Q_melt Q_melt_max];这里有个细节电平衡里蓄冰功率 Q_ch 除以 COP_ice 才是它的耗电功率因为 Q_ch 是冷量功率口径而划过电平衡的必须是电功率。类似这种单位不一致的问题几乎每个人第一次写蓄冰模型都会栽一次建议从一开始就把所有变量的单位口径统一标注在注释里。5.3 求解器选型与线性化技巧如果不含 0-1 变量整个日前模型就是线性规划变量规模不到 200 个、约束几百条Gurobi 或者 Cplex 一两秒就能求解完毕日内滚动 96 次也毫无压力。如果想更精确地模拟启停行为给燃气轮机和电制冷机引入 0-1 启停变量问题变成混合整数线性规划Gurobi 也能处理只是日内滚动次数多时求解时间会上升此时可以适当降低滚动频率或者缩小预测时域。再分享一个线性化技巧如果目标函数里想加入“购电功率峰值惩罚”直接把峰值设成辅助变量 P_peak加上 P_buy(t) ≤ P_peak再把 P_peak 乘以惩罚系数放入目标函数。这个方法比加二次项要稳定求解更快而且削峰效果非常直观。类似的技巧也可以用来限制蓄冰槽 SOC 的剧烈波动。6. 实际运行调参的几点经验6.1 日内 SOC 跟踪项的权重选取前面说了 SOC 跟踪项的加权形式权重的选取思路再补充一下执行细节。我一般先在某个典型日场景里把 ω 固定为 0跑完日内滚动记录 SOC 轨线与日前计划的偏差曲线然后逐步增大 ω观察运行成本和 SOC 偏差两个指标。比较好的取值出现在一个“临界点”附近——再增大 ωSOC 偏差不再明显缩小但运行成本开始显著上升。取这个临界值偏小一些即可既保住了蓄冰槽的蓄放节奏又不至于牺牲日内预测更新的经济收益。6.2 冷负荷预测偏差的应对在我的经验里冷负荷预测误差对冰蓄冷方案的影响比电负荷预测误差更直接因为冷负荷直接决定了蓄冰槽的放冷节奏。如果冷平衡约束写成严格的等式一旦预测比实际偏低日内优化可能在某个时段直接无解整个滚动循环就得中断这是多时间尺度框架里要极力避免的情况。我的做法是在冷平衡约束里加一个松弛变量COP_ec · P_ec(t) COP_abs · Q_abs(t) Q_melt(t) slack(t) L_c(t)并把 slack 设为非负、目标函数里给一个很小的惩罚系数。这样预测误差极端时模型仍然有可行解后续滚动修正再逐步消化偏差。严格等式看着漂亮实际工程里非常脆弱加松弛是一个务实的选择。6.3 判断优化结果是否合理的几个直观特征模型跑完之后不要只盯着目标函数值。我检查结果合理性的经验是看几条特征曲线谷电时段蓄冰功率是否达到合理幅度高峰时段融冰出力是否用满吸收式制冷机在高电价时段是否尽量满发燃气轮机发电曲线是否贴合电负荷峰谷而没有频繁启停。如果 SOC 曲线出现剧烈锯齿多半是某条约束漏了如果融冰几乎不用可能是电价差不够大或者蓄冰效率参数设得太低如果蓄冰槽整天都不蓄去检查 SOC 初值和日循环约束是不是被写成了 ≤ 导致模型直接“吃存量”。这些检查项往往比看成本数字更能暴露模型问题。最后分享一个小技巧我习惯在代码运行后用统一的绘图函数把 SOC、电价、各设备出力以小时分辨率输出在同一张图上。多时间尺度调度的问题往往不在某个单点时段的决策而在跨时段节奏的配合上。把蓄冰槽 SOC 和电价曲线画在一起一眼就能看出蓄放冰节奏是否和电价信号对齐这个习惯帮我排查掉了至少一半看起来“成本很低但根本没法执行”的结果。