尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

冷热电多能互补系统优化调度中的用户舒适度建模与工程落地

冷热电多能互补系统优化调度中的用户舒适度建模与工程落地 大约在五年前我第一次把一套带地源热泵和蓄冷罐的小型冷热电联供系统从仿真推到真实园区时被运维工程师问住了一个问题你说这套调度方案是最优的为什么夏天下午三楼西侧办公室的人喊热而二楼大厅的人又嫌冷气太足当时我下意识想反驳“系统总体成本最低、总供能曲线匹配”但话到嘴边意识到传统优化调度里的“满足负荷”其实是个非常粗糙的假设——它默认用户侧只要给了冷/热/电的能量体验就没问题。但实际建筑里的人不是花洒开水龙头就有水他们要的是稳定、舒适、响应跟得上的环境。从那之后我几乎所有综合能源优化调度的项目里都主动把“用户舒适度”写进目标函数和约束条件。这篇就借着我最近做完的一个冷热电多能互补系统的调度项目从头拆一遍用户舒适度到底怎么量化、怎么塞进优化模型、对调度结果有多大影响以及落地时那些仿真里完全看不出来的坑。舒适度这东西听起来像个“软指标”好像谁都能说两句但真让它在优化模型里起作用就需要一个既能反映人体主观感受、又具备数学上可微可导可线性化的表达。我综合了几个项目的做法给你一套从衡量指标到目标建模再到约束处理都能直接拿去用的完整链路。1. 冷热电多能互补系统到底在“补”什么先说清楚系统本身不然后面讲调度会觉得跳跃。冷热电多能互补英文常叫CCHPCombined Cooling, Heating and Power或者更广义的MESMulti-Energy System核心思路不是简单地把燃气锅炉、电空调、光伏板堆在一起而是让不同品位、不同来源的能源在时空上相互配合用一次能源的梯级利用去节省整体成本。我的原则是项目开题先画一张能量流拓扑图手动或工具画都行但一定要能量守恒写清楚。拿那套我经手的园区系统举例典型的架构包括动力设备天然气驱动的一台小型燃气内燃机额定功率大约1.2MW发电的同时产生高温烟气和缸套水其中烟气进余热锅炉产生蒸汽或热水缸套水直接进换热站。制冷设备一台溴化锂吸收式制冷机利用蒸汽或热水驱动额定制冷量约1.4MW两台电驱动离心式冷水机组每台额定制冷量约0.9MW。制热设备燃气热水锅炉做调峰额定制热量约1.5MW另外冷凝器侧回收热量也可以直接供热。蓄能设备一个300m³的蓄冷水罐和一个200m³的蓄热水罐承担时移峰谷的调蓄作用。可再生能源屋顶分布式光伏装机约350kWp。这套结构里“互补”体现在两个层面设备层面互补——内燃机发电产生余热这是“先电后热”的联产逻辑但如果电负荷小、热负荷大内燃机全开会出现电用不完、上网又受限的状况这时候就得多开燃气锅炉让热负荷交给锅炉带内燃机降出力或停机。这个切换不是一个简单的0/1判断而是要考虑当时电价、气价、设备效率、负载率。更微妙的是制冷侧——溴化锂机用热制冷电制冷机用电制冷同一时刻同样的冷负荷可以由两种完全不同的驱动能源来满足选谁就得看“热”和“电”此刻谁的边际成本更低而且还要受到机组部分负荷率下性能衰减的影响。时间层面互补——白天电价高冷/热负荷同时高内燃机发出来的电可以替代高价市电同时余热又推动了溴化锂制冷一石二鸟夜间电价低电制冷机开起来往蓄冷罐里存冷燃气锅炉或者电锅炉往蓄热罐里存热白天电价高的时候蓄能装置再放能相当于时间套利。这就是互补调度的底层逻辑每一台设备承担什么角色不是拍脑袋定的而是由一个全局优化决策算出来的。但问题也随之而来——如果优化目标只盯着经济和一次能源消耗系统会在满足“平均负荷”的情况下自动选择让所有用户稍微热一点或冷一点来省钱因为末端温度的微小偏移在能量平衡方程里可能根本不构成约束。于是我的调度结果交付的是“能量”而不是“舒适”。你可能会问负荷预测环节不是都有温度指标吗那不是间接考虑舒适度了吗抱歉那只是预测室内得热的一个输入系数跟用户真实体感完全是两码事。做预测的行话是“预测的是房间空气温度响应”而调度模型里若是没有把温度设成状态变量也没有把温度区间设成约束那预测做得再准也仅仅是给能量购买数量做了个估计并不保证室内热环境达不达标。注意对于清洁供暖/供冷的项目考核政府或物业方比较看重室温是否达标尤其严寒地区冬季“室温不低于18℃”往往会上红头文件。如果你的优化模型完全不约束室温只盯着成本那运行结果可能“省了钱冷了人”后期投诉和返工成本远超节省的那点电费。2. 把“舒适度”翻译成数学语言用户舒适度的量化学术界最经典的是Fanger的PMV-PPD指标工程界尤其是暖通空调领域也大量采用。PMVPredicted Mean Vote预测平均投票值把冷热感觉映射成-3到3之间的刻度-3代表很冷3代表很热0代表热中性。PPDPredicted Percentage of Dissatisfied预测不满意百分数跟PMV之间有直接的函数关系。这俩指标考虑的因素包括空气温度、相对湿度、平均辐射温度、风速、代谢率、服装热阻。但直接拿PMV进优化的很少原因在于PMV方程是非线性的迭代求解在日内滚动优化里会有时间和稳定性问题。实际工程中常见的是把PMV做线性近似或者退而求其次直接以室内空气温度区间和相对湿度区间作为舒适度代理指标。我这里偏向后者同时引入一个基于温度偏离度的软性惩罚项把“舒适度”从一个刚性跳变约束变成一个弹性可妥协的劣化代价。具体建模思路分三步第一步室内温度动态方程典型做法是用一个一阶等效热容模型描述房间空气温度变化C_ind * dT_ind(t)/dt Q_hvac(t) - (T_ind(t) - T_out(t)) / R_env其中C_ind是房间等效热容kWh/℃T_ind是室内温度℃T_out是室外温度℃R_env是围护结构等效热阻℃/kWQ_hvac是空调系统供给该区域的冷/热量kW。为了进混合整数线性规划MILP用隐式欧拉或者梯形法做离散化写成T_ind(t1)关于T_ind(t)、Q_hvac(t)、T_out(t)的线性递推式。第二步舒适度区间约束设T_s,set(t)为舒适温度设定值ΔT_comf(t)为允许波动带宽则约束为T_s,set(t) - ΔT_comf(t) ≤ T_ind(t) ≤ T_s,set(t) ΔT_comf(t)ΔT_comf怎么取按照ISO 7730和GB/T 50785-2012《民用建筑室内热湿环境评价标准》热舒适等级I级对应的温度范围大致是夏季24℃~26℃、冬季22℃~24℃允许波动通常在±1℃~±1.5℃。如果预算充足、系统能效也够可以按等级I的严格要求来如果是为了降低运行费等级II温度范围放宽到夏季23℃~28℃、冬季18℃~22℃也能接受。第三步满意度惩罚函数把舒适度“软化”的常见做法是引入松弛变量让温度可以在一个硬约束区间之外继续运行但每偏离一度产生一个惩罚成本。偏离越小越好但不至于因为一个瞬时扰动导致模型无解。这样优化器就会自行权衡多花10块钱电费把温度拉回舒适区跟忍受用户投诉但省下50块钱哪个更划算——结果往往取决于惩罚系数的标定。这个惩罚系数的标定我踩过坑一开始拍脑袋定了个0.5元/℃结果优化器在电价高峰时段把室内温度整体抬高了2℃房间热得像蒸笼成本确实好看但物业那边炸了锅。后来改成“第一小时偏离30元/℃、第二小时偏离50元/℃、连续偏离超过三小时直接100元/℃”的分段递增罚函数情况才收敛系统知道连续背离要比短时波动付出更高代价。除了温度冷暖“冷热电”里的“冷”和“热”其实对应的是同一套热力学模型只是工况不同。夏天空调送冷Q_hvac取负值带进方程冬天供热Q_hvac取正值。这样一套方程就能完成全年四季的舒适度约束。3. 优化调度的数学建模目标函数与约束条件怎么搭有了舒适度的数学表达下面就可以搭建完整的优化调度模型了。这里我给出一套我在工程中常用的简洁框架项目上你想单列碳排放或一次能源消耗目标往这个骨架上加就行。3.1 目标函数综合目标写成三部分加权和min Σ_t [ C_elec(t) C_gas(t) C_battery(t) C_comf(t) C_penalty(t) ]C_elec(t)购电成本 购电功率 × 实时电价。光伏发电量在这个框架里直接作为负的负荷项处理或者作为可再生能源优先消纳项看你习惯。C_gas(t)购气成本 燃气消耗功率 × 天然气价格。燃气轮机和燃气锅炉都要算。C_battery(t)蓄能设备使用成本或折旧通常等于一个很小的单位功率成本乘充电/放电功率或者按日折旧摊到小时目的是防止蓄能设备无意义地频繁充放。C_comf(t)舒适度惩罚项 各区域温度偏离舒适区程度的加权平方和或分段线性函数。C_penalty(t)旋转备用不足惩罚、启停惩罚、功率越限惩罚等按项目需要追加。各目标项之间是量纲统一的经济量所以加权系数就是各物理量到人民币的换算。你不需要太纠结“成本最优”和“舒适最优”怎么平衡因为暖通里的舒适度本质上是可以货币化的——物业靠满意率收租金、企业靠工位环境保员工效率这些都能折算成钱。3.2 关键约束能量平衡约束电功率平衡P_gt(t) P_pv(t) P_grid_buy(t) P_discharge(t) P_load(t) P_grid_sell(t) P_charge(t) P_ec(t) P_pump(t)其中P_gt是内燃机发电功率P_pv是光伏出力预测值P_grid_buy/sell是电网购/售电P_discharge/charge是蓄电或蓄冷/蓄热的等效电功率P_ec是电制冷机耗电P_pump是水泵风机等辅助耗电P_load是用户电负荷。冷功率平衡Q_cool_abs(t) Q_cool_ec(t) Q_cool_storage_discharge(t) Q_cool_load(t) Q_cool_storage_charge(t)热功率平衡Q_heat_exh(t) Q_heat_boiler(t) Q_heat_storage_discharge(t) Q_heat_load(t) Q_heat_storage_charge(t)设备出力约束0 ≤ P_gt(t) ≤ P_gt_max P_gt_min ≤ P_gt(t) ≤ P_gt_max燃气轮机有最低稳定技术出力 0 ≤ Q_abs(t) ≤ Q_abs_max 0 ≤ Q_boiler(t) ≤ Q_boiler_max内燃机的热电耦合关系是模型里比较关键的一个发电功率P_gt和余热回收Q_exh之间不是独立的通常满足Q_exh(t) η_recover * (1 - η_elec) * P_gt_input(t)换个形式更常用给定余热回收系数α则Q_exh(t) α * P_gt(t)。这个α是内燃机部分负荷率、环境温度等参数的函数工程上一线做法是取几组典型工况用线性插值描述形成分段线性约束。溴化锂制冷机约束Q_abs(t) COP_abs * Q_exh_to_abs(t)COP_abs一般取1.3左右注意别按厂商样本上的额定制冷量/额定耗热量的比值去算部分负荷段实际部分负荷下的COP会打折最好用实测数据拟合。蓄能装置动态约束SOC_store(t1) SOC_store(t) - Q_discharge(t)/η_discharge * Δt Q_charge(t) * η_charge * Δt0 ≤ SOC_store(t) ≤ SOC_store_max 0 ≤ Q_discharge(t) ≤ Q_discharge_max * I_discharge(t) 0 ≤ Q_charge(t) ≤ Q_charge_max * I_charge(t)I_charge(t) I_discharge(t) ≤ 1防止同时充放3.3 舒适度相关约束的嵌入方式在完整的MILP模型里室内温度约束怎么加以每个功能区设一个代表性区域区域编号r 1, 2, ..., R为例T_ind_r(t1) a_r * T_ind_r(t) b_r * (Q_hvac_r(t) Q_gain_r(t)) c_r * T_out(t)其中a_r、b_r、c_r是由围护结构热容、热阻、面积等推导出的常系数。室温在舒适区间内时C_comf 0一旦越界惩罚项按分段线性函数加进去。为了让MILP能处理把温度区间外部分离散成几段斜率递增的线性函数这比二次函数更受求解器欢迎。约束软化处理如果模型在极端天气下完全不满足室温约束求解器会报不可行。务必将舒适度约束做软约束处理加入松弛变量s_r^和s_r^-T_ind_r(t) - s_r^(t) ≤ T_max_r(t) T_ind_r(t) s_r^-(t) ≥ T_min_r(t) s_r^(t), s_r^-(t) ≥ 0在目标函数中给松弛变量一个高额惩罚系数。这样做的意义不光是数学上保证可行解更重要的是工程上保留了运行人员在极端工况下手动越限的合理性——总有一些时刻比如极端寒潮和节假日过渡期必须牺牲短暂舒适度来换取系统安全。4. 求解策略与落地案例从MILP到滚动调度模型建好了接下来是求解。我这套模型用的是混合整数线性规划MILP因为设备启停状态、蓄能罐充放状态、分段报价这些都是整数变量线性化后交给求解器处理最方便。4.1 求解工具选型商业求解器Gurobi、CPLEX性能和稳定性最好园区规模的项目几十个区域、几十台设备、96个时段通常在几十秒到几分钟内收敛。开源求解器CBC、SCIP小规模或教学演示可以用但复杂模型求解时间会明显拉长特别是加了蓄能设备后整数变量变多。如果上了非线性舒适度模型比如直接用PMV就要用NLP求解器或者启发式算法粒子群、遗传算法等但这类算法没法保证全局最优而且日内滚动调度对耗时敏感我建议尽量线性化这件事不能怕麻烦。4.2 调度策略日前计划 日内滚动校正实际项目中我用的是典型的两阶段调度框架日前调度Day-ahead基于次日的气象预测、负荷预测、分时电价以1小时为步长或根据需要细化为15分钟优化次日00:00到24:00的设备开停计划。这一步决定大型设备如内燃机、双工况冷水机组的启停组合和蓄能罐的目标SOC曲线。日内滚动校正Intra-day Rolling以15分钟为控制周期向前滚动优化未来4小时。把日前计划里的设备状态作为边界条件固定下来只优化连续变量设备出力、充放功率、室温设定点的微调用实时状态实际室温、实际负荷、光伏实发功率刷新预测消除日前预测误差。为什么要滚动因为用户的舒适度跟“预测是否准确”高度相关。负荷预测往偏了预测室温就偏室温偏了再想拉回来就需要额外的冷/热出力而这个额外出力可能正好碰上电价峰值时段——如果不滚动就会连续几个小时室温偏离用户早就有意见了。说个实际数据给你体感同样一套系统只做日前调度不做日内校正夏季典型日累计室温偏离舒适区间的时长为47分钟加上日内滚动后降到9分钟。看起来不长但47分钟的偏离往往集中出现在下午3点到4点的电价高峰时段室内温度能升到28.5℃以上坐在窗边的人早就开始冒汗了。4.3 案例某办公园区的夏季设计日调度直接上一个我最近调完的案例。基础参数地点北方某市夏季典型设计日室外温度最高34℃园区办公少量商业空调面积约2.8万m²分三个区域建模A栋办公、B栋办公、C栋商业裙楼电价峰段1.02元/kWh8:00-11:00, 18:00-23:00平段0.63元/kWh7:00-8:00, 11:00-18:00谷段0.33元/kWh23:00-次日7:00气价按阶梯折算约2.8元/m³对应单位热值成本约0.29元/kWh按天然气低热值10.5 kWh/m³算锅炉效率0.9舒适度约束A/B栋办公按ISO等级II夏季温度24~28℃C栋商业裙楼按等级I24~26℃优化结果对比我跑了两个场景做对照。场景一不考虑室内温度约束只保证供冷量满足负荷预测传统做法。场景二完整带室温动态约束和舒适度惩罚。指标场景一传统供冷量匹配场景二考虑温度动态与舒适度当日总运行成本21870元22650元内燃机启停次数2次1次电制冷机总耗电量8.42MWh9.36MWh溴化锂制冷量占比34%41%室温越限总时长47分钟6分钟最大室温偏离幅度2.3℃0.4℃场景二总成本增加了3.6%但换来的是末端舒适度的大幅改善。落地运维方和物业对多出来的780块钱完全没意见反而很满意——因为过去三年夏天他们接到的温度投诉工单平均每周5到8单那套方案上线那一周投诉降到0单。从结果里能看到一个有意思的细节场景二的溴化锂制冷量占比从34%提升到41%。原因不复杂——溴化锂制冷机虽然单机制冷能效比没有电制冷机高但它用的是内燃机余热这部分热量的边际成本很低只要内燃机在高效区间运行余热供冷就是给用户房间“免费”降温系统在满足舒适度区间的前提下可以更多开内燃机整体购电量反而降了。这其实就是舒适度约束带来的“连锁反应”不是简单多花电费去压制温度而是促使系统调整了运行结构和能量流路径在相同的能源资源下既保住了成本可控又提升了体验。5. 室内热响应模型怎么建才能不出偏差讲到这里很多人会卡在建筑侧建模上。设备侧的模型再复杂至少厂家手册有参考值但建筑等效热容、围护结构热阻这些参数新项目往往没有经过标定硬套一个模型的话调度结果可能偏差不小。我推荐的做法是“RC网络模型”即把每个功能区的热动态等价成电阻-电容网络。一阶RC模型相当于一个房间用一个热容C和一个热阻R描述适合整个区域当作一个整体来看的情况。如果建筑体量大、不同朝向负荷差异显著至少拆成两个或三个分区各分区之间再加入一个耦合热阻。以常见的二阶RC模型两个热容分别对应室内空气和围护结构内表面为例C_air * dT_air/dt (T_wall - T_air) / R_wall Q_hvac Q_solar Q_occ Q_equip C_wall * dT_wall/dt (T_out - T_wall) / R_out (T_air - T_wall) / R_wall其中T_air是室内空气温度T_wall是墙体温度Q_solar是太阳辐射得热Q_occ是人体散热Q_equip是设备散热。这些参数怎么获取我的经验是三条路设计图纸倒推从建筑设计说明的围护结构传热系数K值表、玻璃的遮阳系数SC、窗墙比等参数计算R和C。优点是前期就能用缺点是模型和实际运行偏差大一般有20%~30%的误差。实测数据辨识装几个温度传感器记录一周的室内外温度、设备启停时间、送风温度用最小二乘法或者卡尔曼滤波辨识R、C参数。这是最靠谱的误差能压到5%以内。建筑能耗模拟软件联动用EnergyPlus或DeST生成多组工况下的室温响应数据再用这些数据拟合降阶RC模型。精度介于前两者之间但工作量不小。我现在基本是“设计图纸初值 实测辨识校准”的组合。项目启动第四周就把传感器数据和模型参数优一轮后续每隔三个月复校一次应对围护结构性能变化和功能分区调整。如果你不想手撕RC参数还有一个土办法直接从空调系统历史运行数据里反推“供冷量-室内温度”的近似斜率。例如记录过去一周每天10:00到16:00的冷量供给和室温斜率做一个线性回归dT/dt ≈ a * Q_hvac b * (T_out - T_air)。这个方法物理意义不如RC模型强但胜在快速、低门槛对一部分粗调度场景也够用了。6. 落地部署时的几个大坑和实用提醒模型跑通了、仿真也收得漂亮但部署到实际系统时才是真正的考验。我在几个园区项目上踩过不少坑挑几个影响最大的说。6.1 一定要分时段的舒适度要求不一样很多人把舒适度约束做成全天一个温度区间这是不对的。办公建筑白天需要严格舒适环境但夜间只有少量加班人员或保安值守如果还维持在24℃~26℃那就是巨大的能源浪费。实际调度中把夜间温度区间放宽到20℃~28℃甚至直接让空调进入待机模式能省不少钱。还有过渡季春秋季室外温度本身就在舒适区间内空调系统其实应该尽量不启动靠新风和自然通风就能维持室内热舒适。如果模型里不设置过渡季的舒适度优化模式系统还会机械地维持空调运行白白耗能。我现在的做法是让系统每天去匹配当天的气象修正舒适温度——按日平均室外温度自动调整室内目标温度平滑衔接避免“今天还24℃明天突然跳到26℃”的突兀跳变。6.2 区域差异化舒适度建模之前把整个园区的室内温度设成一个模型结果调度结果在A栋很舒适但C栋阳光直射区域下午热得不行。原因就是不同区域的围护结构条件、人员密度、设备散热差异很大用一个平均温度代替所有区域的温度就是把“用户舒适度”做成了“用户平均舒适度”这等于还是没有以人为本。所以前面案例里我建了三个区域的分区模型各用各的RC参数、各用各的舒适度区间。代价是模型规模和数据需求增加了但从结果看这个投入很值——物业那边能直观看到“A栋的室温设定和C栋的不同是系统有意为之不是故障”。6.3 舒适度惩罚系数要结合业务场景做园区、写字楼、医院、数据中心舒适度在目标函数里的权重应该不一样。医院对温度要求极高并且波动容忍度极低舒适度权重应该拉很高写字楼相对有弹性但涉及客户满意度数据中心里所谓的“舒适度”其实是服务器进风温度限制惩罚系数要按宕机风险来标定稍有不慎就是事故级损失。我在写字楼项目上按“室内温度每偏离舒适区间1℃、持续一小时惩罚成本 该区域一小时平均租金 × 影响面积比例”来标定理由是租户满意度影响出租率出租率就是写字楼的收入。这样标定出来的数值既能在优化器里跟电费气费抗衡又能在跟业主汇报解释时经得起推敲。6.4 求解时间和收敛性的工程权衡前面说过MILP模型尽量线性化但即便如此如果区域分了七八个时间粒度又细化到15分钟一天96个时段模型变量数可以轻松到几万个整数变量几千个Gurobi跑起来可能超过十几分钟。日前调度还能接受日内滚动调度15分钟一个周期求解时间必须控制在一两分钟内否则没法落地。几个工程上常用的技巧时段聚合把日内滚动的时间粒度拉长到30分钟或者把24小时的日前模型用1小时粒度只对近端2小时用15分钟粒度。这叫多分辨率时间建模。变量降维同型号设备聚合成一台等效设备减少对称性整数变量。例如三台同型号电制冷机等效成一台三倍容量的制冷机代价是失去了单独设备启停的颗粒度但对整体调度结果影响甚微。解修正先用松弛整数变量求一次连续最优得到热起步点再固定启停状态只优化连续变量作为MIP的热启动求解速度能提升一大截。限制MIP Gap设置相对最优间隙为1%~2%即求解器找到的可行解跟最优下界的差距在1%内就停。对工程场景来说1%的次优解和最优解之间的差别完全可以接受但求解时间可能从十几分钟降到两三分钟。6.5 与末端控制的联动别断了很多项目做完调度优化就停了调度下发一个总冷量信号给空调系统但末端风机盘管、变风量阀怎么配合完全没人管。结果就是调度模型算出来“现在供给这片区域100kW冷量”末端系统也照做了但实际上因为某个支路的水力失调东侧房间实际得到70kW西侧房间却超量到130kW室温照样不均匀。我现在的做法是调度优化的输出不仅仅是“供水温度 总流量”这种粗粒度信号而是直接下发到区域控制器每个区域的室温目标值曲线、区域冷量需求、空调系统供水温度设定值。末端控制器再去调节风机盘管或VAV阀位实现区域温度跟踪。调度层的“舒适度约束”和末端控制层的“舒适度实现”必须是一个闭环否则优化做得再精细都是雾里看花。6.6 调试验收阶段把满意度做成可观测指标调度系统上线之前我就跟运维团队一起把“用户舒适度”定义成可量化的KPI包括各区域室温实时偏差、室温越限累计时长按日/周/月统计、用户投诉工单数量、异常温度事件持续时长。每天定时生成一张“舒适度日报”运维人员打开就能看到昨天哪些时段哪些区域温度超限超了多少是调度原因还是末端故障。有一次日报发现B栋连续三天下午15:00左右室内温度偏高调度层面看各项指令都正常。后来查下去是B栋冷冻水支路电动阀卡滞每次在下午高温时段开度到了85%就上不去了。如果没有这份日报这种设备层面的偶发问题可能拖上几周才被用户投诉发现。调度系统不只是“算得准”还得“看得见”把抽象的舒适度变成可见的数字和趋势是运维环节最容易忽视却最有实用价值的一步。7. 如果做纯学术仿真哪些地方可以简化如果说你暂时没有实际项目只是做课题研究或者写论文那也不是非得建全套RC网络模型才有价值。学术场景下的简化策略也很清晰。一个常见做法是直接用文献里已经标定好的建筑模型参数类似ASHRAE标准里给出的一些典型建筑类型的热工参数代表值不再做辨识和校验。另一个是把室温动态约束退化成功率约束——比如用“瞬时冷热负荷满足舒适温度对应的冷热需求”这在仿真里完全可以接受因为你想研究的是综合能源系统侧的调度策略不是建筑热响应的精确模拟。还有就是把舒适度指标换成灵活性指标或者满意率指标例如定义“用户不满意率”为偏离温度区间的小时数占比把它做进多目标优化里画帕累托前沿。这类工作学术价值不小因为工程里一个惩罚系数就解决了的问题在学术框架里可以用多目标跟运行成本做权衡更直观也更有解释性。不过做学术仿真时有一点我建议保留模型一定要有时变特性——光伏出力曲线、负荷波动、电价波动都别用常数代替否则优化结果会虚高。因为你研究“冷热电多能互补”本身就是冲着“不确定性下的互补”去的把所有不确定都抹平这个问题就不用做了。以我个人经验写完初版模型后先拿一组已知结果的基准场景验证模型正确性再逐步放开约束和复杂度比一上来就堆复杂建模要高效得多。把每次模型改动前后结果差异记下来这既是学术报告的基础也是未来调试的参照。老话说得好搞综合能源优化调度最容易做成了“能源系统优化”而把“人”给忘了。后来我给自己写了一条备忘每次项目收尾时都会问一遍室外温度、电价、设备性能这些变量在变但用户的体感有没有被当作一个动态对象去跟踪、去约束、去优化如果答案是否定的那这套调度系统无论经济学指标多漂亮都只完成了一半的功课。希望这篇拆解里量化舒适度、嵌入优化模型、工程部署避坑的这些细节能让你在下一个冷热电多能互补项目里少走几段弯路一上来就能找到那个“既省钱又让人舒服”的调度方案。
返回列表