楼宇群热电联供与储能协同调度优化：从单栋节能到集群收益挖潜

1. 从"单栋节能"到"楼群协同"：这个项目到底在解决什么问题

先把结论放在前面：这个项目把原本各管各的七栋楼当作一个能量系统来调度，核心设备是三台燃气热电联供机组、一套水蓄热系统和两套电储能装置，通过一个滚动优化的调度器，在保证每栋楼室内舒适度的前提下，把整个区域的综合能源成本压低了大约18%，碳排放量减少约22%。这里面的关键并不是某台机组性能有多好，而是"协同"这两个字——不同楼宇的用电和用热曲线天然错峰，单独优化时没法互济，放在一起就能互相补位。

这个思路适合谁？如果你正在做园区能源托管、综合智慧能源、楼宇群节能改造，或者你手上恰好管理着一片多业态建筑群（写字楼、酒店、医院、学校揉在一起），那这篇内容应该能给你一些可以直接拿来用的思路。我后面会把建模过程、硬件选型、调试踩坑和经济测算都摊开讲，尽量少讲空话。

1.1 热电联供的本质：把本该浪费掉的废热变成资源

燃气热电联供，英文缩写CHP（Combined Heat and Power），最容易被人误解成"边发电边供热"的两用设备。实际上它只有一个燃料入口，燃气内燃机或燃气轮机先发电，发电过程中产生的缸套水余热、烟气余热再通过换热器回收，供给采暖、生活热水或制冷。纯凝发电时，燃料里的化学能只能变成大约30%到40%的电，剩下60%以上全散到大气里；回收废热之后，电热总效率能做到80%以上。这就是CHP的底层逻辑：不是既能发电又能供热，而是把本来要扔掉的热捡回来用。

但为什么不是所有楼宇都愿意上CHP？答案很残酷：在很多单体楼里，热需求不够大、不够稳。一台1.5 MW的燃气内燃机，满发每小时大概能回收1.8到2.4 GJ的热。如果单栋写字楼只有冬季白天需要采暖，夏天和夜间用不了多少热，机组要么只能降负荷运行，要么得把热排掉，经济性一下就垮了。所以从单栋视角看，CHP是个风险很大的投资；切换到楼群视角后，热负荷曲线被多栋楼叠加平滑，这台机组的运行时数才能被拉满。

1.2 协同不是简单地把设备连起来

"楼宇群协同"这四个字，我在项目里理解成一个模型一句话：让整个区域的能量流按最优路径流动，而不是让每栋楼各自做最优。

最直白的例子是医院和办公楼。医院24小时都要热水和蒸汽，办公楼晚上几乎零热负荷；写字楼白天电负荷高、热负荷低，医院的电力负荷相对平稳。这两类建筑如果放在一个系统里，白天办公楼多出来的余热可以直接供给医院消毒和生活热水，晚上医院依旧在放热需求，就为CHP机组提供了夜间运行的"热基荷"，机组不用频繁启停，效益自然比各开各的高。

这里顺便驳一个常见错觉：有人以为协同就是弄一个集中控制平台把所有楼的数据投到一块大屏上。那是可视化，不是协同。真正协同的核心是调度策略——在每一个调度周期内，系统要替整个区域的设备回答几个问题：燃气机组发多少电、蓄热罐是蓄还是放、电储能充还是放、热网阀门开多大、哪栋楼的空调可以短时调低负荷。这些问题交织在一起，才是后面要讲的优化模型。

2. 楼群负荷画像：电热需求不在同一时刻出现，才是优化空间的来源

既然要做协同，第一件任务就是搞清楚每一栋楼的"作息时间"。我用这个项目里的七栋楼（五栋办公楼、一栋酒店、一栋医院）来拆开讲。

2.1 典型楼宇的负荷曲线差异

办公楼的负荷特征是"白天高、夜间低"，工作日早8点到晚7点是硬需求，其余时间几乎接近零。酒店则是另一种形态，客房全天24小时有人，早晚各有一个用冷热水的峰值，但峰值比办公楼平滑得多。医院最特殊，急诊、手术室、检验科不停歇，用电和用热的波动最小，而且对供电可靠性要求极高。三种曲线放到同一张图上，你会看到明显的"错峰互补"空间。

具体到数值，我摘一段典型夏季日的数据：办公楼白天最高电负荷约3.8 MW，夜间降到0.5 MW左右，白天冷负荷峰值大约4.2 MW，夜间只有0.3 MW；酒店全天电负荷在0.9至1.4 MW之间波动，热水负荷白天0.6 MW、夜间0.4 MW；医院电负荷一天内基本贴着2.2 MW上下浮动，热负荷约1.5 MW且很少跌破1.2 MW。把这些数加起来，整个楼群的电负荷峰谷差约为3.1 MW，热负荷峰谷差约为2.4 MW。如果只看单栋，峰谷差普遍在3倍以上。峰谷差缩小，对系统里机组的容量配置和运行经济性是决定性的。

2.2 热电比是选择运行策略的关键指标

热电比，也就是热负荷和电负荷的比值，决定了CHP机组在这个时点应该"以电定热"还是"以热定电"。燃气内燃机有个特点：在很大范围内，燃料输入确定后，发电量和可回收热量基本是固定比例关系，机组不是想少出热就能少出的。如果楼群热负荷小于机组能回收的热量，系统就必须加装冷却塔或旁通把多余热散掉，等于白白浪费燃料；如果热负荷大于机组产热，就得用燃气锅炉补燃，那补燃的部分就不享受联供的能效红利。

所以调度模型的智慧在于，把"什么时候开机组、开几台、开多大"和"什么时候用蓄热罐蓄热"放在一起解。夏天白天电负荷高、冷负荷高，但热负荷往往不高，这时候可以让燃气机组多发电，把富余热打进蓄热罐，晚上再用蓄热罐驱动吸收式制冷机解决夜间冷负荷。这样机组白天能顶着电价高峰多发电，晚上也不至于把热排空。这一步是后面整个收益的核心来源之一。单独一栋楼自己往往没有这么大的蓄热罐容量冗余，所以储能设备在楼群协同中的价值被显著放大了。

2.3 用数据结论指导设备容量

把楼群负荷画像做完后，我们对设备容量就有了明确的数据支撑。原来单栋楼各自配置CHP时，可能每栋楼都要配一台1兆瓦左右的机组，总共需要7台；现在我们只配了2台1.5 MW燃气内燃机和1台0.8 MW燃气轮机，总装机3.8 MW，却基本能覆盖整个楼群70%以上的峰值电负荷和90%以上的基础热负荷。

这个容量设计的依据是：前面统计的日负荷数据已经表明，不可能所有楼在同一时刻达到各自的峰值，楼群的峰值叠加后打了折，这个"峰值的非同时性"就是容量配置时的安全边际，也直接拉低了初始投资。后面我会再细说经济账，这里先记住一个结论：协同的意义首先体现在少花钱买设备，其次才是运行时的能源成本节省。

3. 协同调度模型：目标函数、决策变量和约束条件的搭建思路

前面全是定性分析，接下来进入可执行的部分：协同调度的数学建模。这是整篇内容里我投入最久的部分，也是最容易踩坑的部分。先说一句，我用的方法是确定性混合整数线性规划（MILP）加滚动时域修正，这是目前工程上普适性和可解释性最平衡的方案，比一上来就直接上强化学习靠谱得多，至少调试期不会让你抓瞎。

3.1 目标函数：成本优先还是碳排放优先？可以一起做

我建议不要只做一个单纯的经济目标，因为政策风向会变，而且业主方很可能既看钱也看碳指标。我们的目标函数是多项的加权和：运行费用（购电、燃气、运维）、碳排放费用、以及设备启停惩罚项。运行费用和碳排放费用是同类量纲，可以用一个价格系数把它们统一起来。

具体系数举例：天然气价格3.2元/立方米，对应的单位热值成本约0.32元/kWh；外购电价采用峰平谷三段电价，峰时1.15元/kWh，平时0.75元/kWh，谷时0.38元/kWh；碳排的虚拟成本我们取0.1元/kg CO2。目标函数可以写成：

min Σ_t [ C_grid(t) · P_grid(t) + C_gas(t) · P_fuel(t) + C_om · Σ_i P_i(t) + C_co2 · Em_co2(t) + C_start · bool_start(t) ]

这里P_grid是购电功率，P_fuel是燃料输入功率，P_i是第i台CHP机组的出力，目标是让所有时段的成本加起来最小。注意，碳排费用我们设了一个不高的单价，让它能影响排序但不能过于激进地牺牲经济性，这样决策结果在用户侧更容易接受。你要是把碳价设得太高，模型会疯狂减少机组出力，完全靠买电，表面上碳少了，实际把排放转移到了电网侧，这显然不是项目的初衷。

3.2 决策变量：几十个变量互相牵连，别漏掉蓄热罐

模型里主要的决策变量包括：每台CHP机组的启停状态（0/1变量）、出力大小、蓄热罐的充放能功率和蓄热量、电储能的充放电功率和SOC、从电网购电功率、卖给电网的功率、各楼宇分支阀门开度等。看起来多，但真正麻烦的是蓄热罐和电储能的时序耦合状态，它们构成了模型里的状态变量，需要把每个时段的状态和上一个时段串起来。

蓄热罐的模型写成：

SOC_heat(t+1) = SOC_heat(t) + (η_ch · P_ch(t) - P_dis(t)/η_dis) · Δt - loss · SOC_heat(t)

其中η是充放热效率，取0.95左右；loss是热损失率，取1%每小时。电储能类似，但电储存效率更高，充放效率可以取0.92。如果漏掉状态变量或者不设上下限，优化结果一定会出现"今天把电都放光、明天再猛充"的疯狂动作。这个问题我在初版模型里真实遇到过，调度结果里蓄电池的SOC像锯齿一样上下乱窜，一看就是约束没写明白。

3.3 约束条件：能拿到手的一定要写全，不然解出来没法用

约束是模型里最容易和现场脱节的部分。我按重要性排一下：

第一是能量平衡约束。每个时段，楼群用电需求 = CHP发电 + 电网购电 + 电储能放电 - 电储能充电 - 卖电网电量；热需求 = CHP回收热 + 燃气锅炉补燃 + 蓄热罐放热 - 蓄热罐蓄热。这是系统层面的大平衡，写错任何一个符号，结果都会偏差十万八千里。我建议先把所有设备的能量流图画清楚再动手写代码，不然调度结果必然莫名其妙。

第二是机组运行边界。每个CHP机组有最小技术出力，通常为额定出力的40%到50%，低于这个值不能稳定运行，需要直接设为一个运行区间约束。同时，机组爬坡速率要限制，比如每分钟不超过额定出力的5%。不然优化器会给你疯狂的爬坡指令，现场设备根本跟不上，调度指令执行率很低。

第三是热网与分支约束。各楼宇的换热站热功率上限、供回水温度限制、热网输送延迟都可以先简化成热功率传输上限。这一步不建议一上来就用流体动力学模型，太复杂了。先用稳态能量流模型，延迟统一按1到2个调度周期处理，后面再慢慢细化。

第四是舒适度约束。室内温度允许短时轻微偏离设定点，但要保证在许可范围内。这个约束让系统能利用楼宇的热惯性削峰，是协同优化区别于简单"跟踪负荷"的关键。没有这个约束，模型只能被动满足每一时刻的负荷，优化空间会小很多。

3.4 求解策略：MILP加滚动时域修正

我实际用的方法分两层。

第一层，以15分钟为调度周期，96个点形成一个完整日调度，用MILP求解全局最优解。解的规模大概是：7栋楼、4台发供热设备、2类储能、96个时段，总变量数约4000个左右，CPLEX或Gurobi跑完约5到10秒，完全可接受。这个求解时间在15分钟的调度周期里根本不构成压力，甚至可以在边缘服务器上跑。

第二层，每15分钟滚动一次，用最新实测数据修正一次未来4小时的预测，把上一周期预测偏差纠正回来。滚动时域的优点是：即使预测模型有偏差，系统也能一直跟着实际状态走，不会因为早上的预测错误导致全天决策都不对。

这里分享一个我早期犯过的错误：一开始我想用更复杂的非线性模型描述热网和机组效率，结果模型跑起来又慢又难收敛，调库和厂家参数对应不上。后来把效率曲线分段线性化，效果立刻稳定。工程上先简单后复杂，不要为了论文里的漂亮曲线去堆模型复杂度，这是我从这个项目里得到的最重要教训之一。

4. 落地硬件与系统架构：从调度算法到实际能跑的工程环节

模型再漂亮，最终都要落到现场的设备和系统里。这章我写一写实际项目实施中的硬件层级和控制架构，这部分资料通常不太容易在公开文档里找到，属于偏经验性的内容。

4.1 硬件构成：CHP机组、蓄热罐、电储能、管网和控制点

我们的物理系统分四块：

第一块是发电源：两台燃气内燃机，单台额定电功率1.5 MW，热回收量1.8 MW，综合效率85%左右；一台0.8 MW的小型燃气轮机，热回收量1.1 MW，主要用于医院这种需要持续供热的场所。

第二块是蓄能设备：一个1500 m³的常压蓄热罐，设计温度95°C进出水，最大蓄热量约70 GJ，折合约19.4 MWh；一套2 MW/4 MWh的磷酸铁锂电储能系统。

第三块是热网：整个楼群用一次侧热网串联，支路接入各栋楼的换热站。管网供回水温度设计95°C/60°C，总输送能力约12 MW。

第四块是控制点：每台机组配独立PLC，每栋楼换热站配热量计、供回水温度传感器、电动调节阀，楼栋内中央空调主机的配电室加装智能电表和通信模块。全部数据汇聚到本地边缘计算服务器，再同步到云端管理平台。控制指令必须由边缘层下发，防止断网时系统停摆。

4.2 通讯与数据采集：标准协议之间做好对接

现场设备通讯是我最头疼的环节。燃气内燃机厂家通常用Modbus TCP把机组运行参数传上来，换热站热量计支持BACnet，电表走DL/T 645，这几种协议要统一到同一个数据平台。我们的做法是在边缘服务器上装一个协议转换网关，先把各协议统一成OPC UA格式，再往上层传递，避免上层应用被厂商协议绑架。

数据采集频率上有个细节容易忽略：调度需要的实时数据（电功率、热功率、蓄热罐温度、阀门开度）按5秒采集，用于状态估计和历史分析；但调度决策需要的是15分钟聚合值，不能直接用5秒瞬时值，否则波动太大的数据会让优化模型出现过激反应。我一度以为是模型参数问题，最后才排查到是数据频率和聚合方法的问题。聚合值用平均值，不是末值，这个细节很多人会踩。

4.3 控制架构三层分离

整个控制系统分三层。最底层是设备控制层，各设备PLC独立闭环，保障设备本体安全和基本调节。中间层是协同调度层，跑前面说的MILP模型，每个15分钟周期输出一次调度指令。最上层是策略管理层，负责设置边界参数、评估目标权重、人工干预等。

三层分开的好处是安全。调度算法再怎么抽风，最多是给设备层下发一个不合理的出力指令，但设备层PLC自己的安全联锁还在，不会直接损坏设备。这个容错设计在调试期救了我们很多次。比如有一次优化模型因为数据异常把蓄热罐的放热功率设成了1.5倍额定值，PLC侧直接限幅，没有造成实际设备损伤。

分享一个工程细节：调度指令下发后，设备实际出力往往会有偏差。我们做了一个"跟随误差监测"，如果某台机组的目标出力和实际出力偏差持续超过5%超过五分钟，系统自动将这一台切换到本地手动模式，并把该台设备的出力从调度模型中剔除，重新计算剩余设备的出力分配。这样保证单台设备故障不会拖垮整个楼群的协同。这套机制在实际运行中触发过两次，都成功避免了系统级停机。

4.4 一套可以抄作业的初始化参数

我整理了一份部署时常用的初始参数表，你可以根据自己的项目规模调整：

这些参数不是拍脑袋定的。蓄热罐容量如果太小，机组调峰能力不足；太大又会增加热损失和占地。30%到50%这个区间是我们在多个项目中试出来的均衡点。调度周期为什么是15分钟而不是5分钟？往下看调试章节就明白了，主要是热网延迟和楼宇热惯性决定的。

5. 调试阶段被忽略的问题：水力平衡、回水温度与热惯性

模型调通了，真到现场试运行才发现，很多麻烦不在算法里，而在物理世界。这章专门讲调试阶段踩过的坑，希望对有条件自己抄作业的人有帮助。

5.1 水力平衡：所有支路都在抢热水，远端的楼宇没热用

联供系统投运初期，最明显的问题是远端楼宇热功率达不到设定值。一次侧热网如果按管径简单配置，没有做水力平衡调试，水总是流向阻力小的近端支路，远端换热站流量不足。我们项目里两栋离供能站最远的楼，供热能力只有设计的60%左右，室内温度始终上不去。

解决办法是逐支路做水力平衡：关小近端换热站的调节阀开度，强制分配流量，再在每栋楼换热站入口装平衡阀，根据设计流量重新标定。这个工作在正式运行前一定要做完，否则调度模型给远端楼宇下发再精确的热功率指令也实现不了，系统会陷入"模型说行、现场不行"的尴尬境地。水力平衡做完后，远端楼宇的热功率可以提升到设计的95%以上，这个提升是实打实的，不需要任何额外能耗。

5.2 回水温度：蓄热罐和热网的能量效率都取决于它

第二个坑是回水温度异常高。项目刚开始时，蓄热罐放热效率明显偏低，后来查出来是各楼宇换热站二次侧回水温度降不下来。二次侧采暖系统设计供回水温差是15°C，但实际只降了6到8°C。回水温度高，一次侧回水也高，进入蓄热罐的低温水不够低，蓄放热的温差就缩小了，同样的罐容储不了那么多热量。

排查后发现，根本原因是二次侧系统里有大量末端设备在部分负荷下运行，风机盘管水阀开度很小，流量过少导致换热不足。解决办法是调整二次侧水泵的变频控制策略，保证最低流量，同时协调换热站的一次侧电动调节阀，不让它在小开度下震荡。回水温度稳定后，蓄热罐有效容量直接提升了约25%。这个教训告诉我们：优化算法再聪明，也替代不了最基础的暖通水系统调试。

5.3 热惯性：调度指令不是即时的，别把分钟级模型当秒钟级用

热网和楼宇热惯性都很大，从蓄热罐调整放热功率，到远端楼宇室内温度变化，中间往往有10到30分钟的滞后。如果调度周期设成5分钟，优化出来的结果会因为反馈滞后不断震荡。我们曾经把调度周期改成5分钟跑过测试，结果蓄热罐的放热指令一会儿上一会儿下，跟抽风一样，最后只能改回15分钟。

调试时还发现，楼宇自身的蓄热能力（墙体、家具、空气的总热容）可以当成天然的储能来用：在电价高峰时段，允许楼宇室内温度上浮0.5°C，相当于给系统增加了几百千瓦时的"虚拟蓄能"，这是不花一分钱设备费用就能获得的调峰能力。这个发现对项目收益贡献很大。实际操作中，我们会在午后电价高峰前提前0.5到1小时降低供热量，让楼宇自然吸收一部分热量，等电价高峰来临时再减少机组出力，靠楼宇自身的热惯性能耗支撑一段时间。

5.4 预测不确定性：天气预报是最大的变量

调度模型依赖负荷预测。我们的光伏总量不大，主要变量是天气导致的负荷预测偏差。夏天午后一场雷阵雨，冷负荷会在20分钟内下降2 MW以上，如果调度模型还按原计划运行，燃气机组和蓄热罐都会出现过调。

处理方式是两层兜底：一层是滚动时域修正，下一周期的模型会把上次的预测误差作为修正量考虑进去；另一层是安全约束，楼群与电网的连接容量留出20%的余量，极端天气下宁可多购电也不让系统波动吓到运维人员。这层电网余量并不是技术落后，而是大规模系统稳定运行的刚需。你优化做得再漂亮，如果整个系统一遇到预测偏差就崩溃，那谁也不敢用它。

6. 投入产出测算、适用边界与下一步扩展

一个技术方案能不能持续运行，最终还是看经济账。这章我做一个开放的测算框架，不写死最终数字，因为气价和电价在各地区差异很大，但拆解方法是可以通用的。

6.1 成本与收益拆解

收入端主要来自三个方面。

第一是替代外购电带来的电费节省。按楼群年用电量约2500万kWh、峰谷电价差0.77元/kWh算，仅把20%的峰时电量转移到谷时运行，一年就能省约38万元。当然这还只是需求侧错峰的部分，大头来自CHP替代外购电：全年发电约1600万kWh，自用率85%，每度电比外购峰时电便宜约0.4元，一年节省约544万元。

第二是热力侧的替代收益。CHP回收的废热替代了原有燃气锅炉的燃气消耗，一年节省约180万元。

第三是需求响应收入。楼群作为整体参与当地需求响应，一年能拿到约30万元补贴。这部分不是每个地区都有，只能作为可选收入。

三项加一起，年收益大概在700万元上下。支出端主要是燃气成本增加、运维成本和设备折旧。设备投资大约4500万元，按10年折旧每年450万元，运维按装机规模测算每年80万元，燃气成本增加要参考实际发电量计算。用上面的数据，年净收益大约能落在250万到350万元区间，动态回收期在6到8年。

需要注意，这里面很多数字有很强的地区性。天然气便宜的地方、峰谷电差大的地方，回收期会显著缩短；如果当地峰谷电价差只有0.2元，电储能那一块的收益模型可能就彻底不成立了。所以我不建议直接把上面数字拿到你那儿套用，这里给出的只不是拆解成本项的方法，每个项目都需要自己做一版本地化的财务模型。

6.2 什么情况不适合做这种协同

再好的技术也有边界。我总结了几条，遇到这些情况建议谨慎：

• 楼群之间距离太远。比如超过500米，供热管网投资会变得很高，热损失也大，协同收益会被管网成本吃掉。
• 高峰热负荷太小且特别集中在冬季，其他季节几乎没有热需求。CHP机组全年运行时间不够，综合效率再高也难回本。
• 没有足够屋顶或场地放蓄热罐和电储能，或者消防审批卡得很严。
• 楼宇产权分属不同业主，利益分配机制谈不拢。这是最容易被低估的障碍。协同有收益，但收益如何划分，决定项目能不能真正落地。需要借助合同能源管理的模式，把各方的边界和分成比例在项目启动前就谈清楚。我们项目里医院和办公楼分属两家业主，光是收益分配就谈了两个月，最后定了按各自用电用热量和参与调峰的贡献度来分。没有这个机制，算法再聪明也落不了地。

6.3 下一步扩展：把冷、热、电、气、碳综合起来

这套架构做完热电协同之后，我看到的合理扩展方向有三个。

第一个方向是加入电力市场交易，通过能源互联网平台让楼群作为整体参与电力现货市场和辅助服务市场。参与需求响应，一个大型楼群可以在电网周期间提供数兆瓦的削峰容量，收益比内部协同更可观。

第二个方向是引入吸收式制冷机组，把夏天的热需求不足问题转成制冷需求的补充，实现冷热电三联供。这样机组夏季也能维持高热负荷运行，全年利用小时数可以有效拉长。项目原本夏季热需求低的问题，通过吸收式制冷可以转化掉一大部分。

第三个方向是把楼群作为虚拟电厂的节点，将电动汽车充电桩、楼宇双向充电桩等柔性负荷一并纳入调度，进一步挖掘需求侧灵活性。这块我们已经在做前期的试点，初步数据表明，在协同调度框架下加入50辆有车网互动能力的电动汽车，能额外提升约8%的系统可调度容量。电动汽车的电池就是移动的储能，和楼宇储能配合得当的话，效果相当可观。

我个人实际做完这个项目的一个体会是：不要一开始就追求最复杂最完美的协同模型，先把负荷数据摸透、把设备通讯打通、把水力平衡做好，再逐步把调度模型从简单到复杂演进。等到系统稳定运行之后，再回头建更漂亮的优化算法也不迟。能源管理这个行当，最值钱的往往不是算法参数，而是对现场物理约束的理解和踩坑经验。这套热电联供协同策略如果能在你的项目里落半个地，我这篇经验就没白写。