企业官网建设流程全解析

简介：该PDF论文围绕神经网络与等SCOP算法的中央空调节能控制技术展开研究，面向暖通空调、建筑节能及机器学习交叉领域的工程师与科研人员。整个资源包仅含1个PDF文件，大小约854KB，完整呈现了作者的研究路线：采用神经网络建立冷水机组、水泵、冷却塔等核心设备的数学模型，并结合等SCOP算法对系统能效进行最优求解。文中以某地铁项目冷冻机房为实例，利用厂家设备设计性能模型验证了神经网络模型精度和算法可行性，同时提醒设计模型数据训练出的模型直接用于实际项目控制会带来较大误差，需要基于现场运行数据重新训练。目前该资源已有150人学习，适合希望掌握中央空调系统建模方法、节能群控优化思路以及在碳中和背景下推进建筑节能的专业读者参考。

1. 这篇 PDF 到底讲了什么：一套能吃透的中央空调 AI 节能控制方案

做楼宇自控或暖通节能的同行，对“群控”这个词应该不陌生。传统群控依赖人工经验和 PID 调节，项目换了、设备换了，控制参数就得从头调一遍，通用性很差。这篇《基于神经网络和等 SCOP 算法的中央空调节能控制技术研究》给出了另一条路：用神经网络把冷水机组、水泵、冷却塔分别建成“黑箱模型”，再用等 SCOP 算法做系统级寻优，把“设备怎么调才最省电”变成一个可迭代计算的数学问题。论文以某地铁冷冻机房为验证对象，全年平均能效算到了 5.14，和厂家设计模型的直接求解结果 5.18 误差极小。但更值得留意的是论文最后那个“翻车”结论——用厂家设计数据训练的模型直接拿去控制实际项目，误差能到 10% 以上，必须用现场实测数据重新训练。这条教训对任何想做 AI 节能控制的人来说，都值回下载成本。

2. 神经网络建模：四个设备的输入输出怎么定，直接决定控制精度上限

2.1 为什么选数学模型而不是物理模型：复制性优先

论文里对比了两条建模路径。物理模型有清晰的数学公式，理论上最“白”，但需要针对每个项目做大量测量，换热系数、阻力特性、表冷器效率这些参数在不同项目之间没法直接复用。数学模型则纯粹靠运行数据学习输入输出映射关系，标准化程度高，适合做产品化推广。这篇论文的立场很明确：要的是能跨项目复制的通用建模方法，所以选了神经网络。

神经网络在中央空调控制里的用法其实分两派。一派直接让网络输出控制目标，比如“给我一个冷水出水温度设定值”，另一派只让网络输出设备性能映射，比如“给定运行条件，输出制冷量”。论文明确说直接输出控制目标的做法稳定性不好，控制目标会出现异常波动。所以它采用的是后者——让神经网络只做“性能预测器”，寻优的事交给等 SCOP 算法。

2.2 四个模型的输入输出设计：这是全文最值得抄的作业

论文定义了四个设备的神经网络模型，每个模型的输入输出都经过了精心设计。这里我把它们整理成一张表，方便对照理解：

这套输入输出设计有几个讲究的地方。冷水机组的模型把功率作为输入、制冷量作为输出，而不是反过来，这样做的原因是：在寻优过程中，我们要“给定一个功率调整量，看制冷量怎么变”，功率是先决条件，制冷量是响应结果。冷却塔模型的输入特意包含了环境湿球温度——冷却塔的散热能力本质上是湿球温度驱动的，没有这个变量，模型在不同气候条件下完全不可迁移。冷冻水泵模型把最不利环路压差作为输入，这个压差信号反映了末端负荷侧的实际需求，比单纯用频率或流量更能代表管网的真实状态。

2.3 一个可运行的神经网络模型训练框架

论文没有给出具体的网络结构，只说用了神经网络。按这类项目的常见做法，用三层 MLP（多层感知机）就足够。这里给一个训练框架，输入特征数量按照前述的模型定义来定：

import numpy as np import pandas as pd from sklearn.model_selection import train_test_split from sklearn.preprocessing import StandardScaler from tensorflow.keras.models import Sequential from tensorflow.keras.layers import Dense, Dropout from tensorflow.keras.optimizers import Adam from tensorflow.keras.callbacks import EarlyStopping def build_mlp(input_dim, hidden_units=(64, 32)): model = Sequential() model.add(Dense(hidden_units[0], activation='relu', input_dim=input_dim)) model.add(Dropout(0.1)) model.add(Dense(hidden_units[1], activation='relu')) model.add(Dense(1, activation='linear')) model.compile(optimizer=Adam(learning_rate=0.001), loss='mse', metrics=['mae']) return model def train_device_model(df, feature_cols, target_col, epochs=300): # 训练前先做标准化，神经网络对量纲敏感 X = df[feature_cols].values y = df[target_col].values X_train, X_val, y_train, y_val = train_test_split( X, y, test_size=0.2, random_state=42 ) scaler_X = StandardScaler() scaler_y = StandardScaler() X_train_s = scaler_X.fit_transform(X_train) X_val_s = scaler_X.transform(X_val) y_train_s = scaler_y.fit_transform(y_train.reshape(-1, 1)).ravel() y_val_s = scaler_y.transform(y_val.reshape(-1, 1)).ravel() model = build_mlp(len(feature_cols)) early_stop = EarlyStopping(monitor='val_loss', patience=50, restore_best_weights=True) history = model.fit( X_train_s, y_train_s, validation_data=(X_val_s, y_val_s), epochs=epochs, batch_size=32, callbacks=[early_stop], verbose=0 ) return model, scaler_X, scaler_y, history

逻辑说明：这个训练函数接收一个 DataFrame，指定特征列和目标列，自动完成数据划分、标准化和训练。EarlyStopping 的 patience 设为 50，防止过拟合的同时给了模型足够的收敛时间。返回的 scaler_X 和 scaler_y 是推理阶段必须保存的对象——实际使用时要先做同样的标准化变换，再喂给网络。

参数说明：hidden_units=(64, 32) 是一个稳妥的起点，对四个设备模型都适用。dropout 设置为 0.1 就够，中央空调运行数据的噪声没有想象中大，常规回归任务里过高的 dropout 反而拉低精度。learning_rate=0.001 配合 Adam 优化器是回归任务的标配。如果你的项目数据量更大，可以把第一层扩到 128，但要注意训练样本数量至少要撑得住参数量的增长。

2.4 精度衡量用 WAPE，别用 R2

论文里用了“加权绝对百分比误差”这个指标，这是设备性能模型评估的关键细节。代码实现很简单：

def wape(y_true, y_pred): y_true = np.asarray(y_true, dtype=np.float64) y_pred = np.asarray(y_pred, dtype=np.float64) return np.sum(np.abs(y_true - y_pred)) / np.sum(np.abs(y_true)) * 100

这个指标的含义是“总绝对误差占真实值总量的百分比”，相比 MAPE（平均绝对百分比误差），它对大值样本天然给了更高权重。冷机在部分负荷工况下制冷量可能是满负荷的一半，如果小负荷工况预测偏差大，MAPE 会被严重放大，WAPE 更贴近工程上的“总能耗算得准不准”这个真实诉求。论文报告的误差：冷水机组 0.5%、冷冻水泵 0.33%、冷却水泵 0.92%、冷却塔 1.88%，都是基于这个口径。你在自己的项目里对比模型效果时，务必用同一个指标，否则数字没有可比性。

3. 等 SCOP 算法：让系统能效最优的迭代寻优逻辑与实现

3.1 核心原理：dCOP 相等是系统最优的判据

先说结论背后的推导直觉。系统的 SCOP（季节能效比）定义为总制冷量除以总能耗。任何一个设备调整功率，都会同时影响两个量：系统总制冷量变化 dQ 和系统总功率变化 dW。定义 dCOP = dQ / dW，它衡量的是“这个设备每多耗 1 kW 电，能多带来多少 kW 制冷量”。如果某个设备的 dCOP 大于当前系统 SCOP，说明把功率加在这个设备上，制冷量增幅大于能耗增幅，整体能效提升；反之则应该减功率。

当所有设备的 dCOP 都等于系统 SCOP 时，任何设备的微调都无法再提升系统能效——这就是等 SCOP 算法的最优判据。这个思想跟经济学里的“等边际原理”如出一辙：当所有资源的边际产出相等时，资源分配达到最优。理解了这个原理，你就知道为什么算法每一步都在比较“设备 dCOP 和系统 SCOP 的大小关系”。

3.2 为什么不能直接对设备做设定值寻优

论文特别解释了一个工程痛点：如果直接调整设备的设定值（比如冷水出水温度）来做寻优，设备会一直处于调整状态，系统稳定性被破坏，冷水机组频繁加减载会严重缩短压缩机寿命。所以实际做法是：用神经网络模型离线计算“某个功率调整量 dW 对应的制冷量变化 dQ”，提前判断该调整的方向和幅度，再向设备下发一次性的、确定性的调节指令。模型在这里是“计算器”，不是“控制器”。

另一个技术原因：神经网络是黑箱模型，激活函数是非线性的，无法直接求导。你没法算出“当前工况下 dQ/dW 的精确解析值”，只能通过数值方法——给功率一个微小增量 dW，前向计算得到 dQ，用差分近似替代导数。论文的做法就是这种数值差分的思路。

3.3 完整迭代计算流程拆解

算法的每一步在论文里都写得很具体，这里我把它翻译成可执行的操作序列：

第一步，计算当前系统 SCOP。系统总制冷量 Q 除以所有设备能耗之和。这里的 Q 可以用冷冻水流量乘以供回水温差算出来，所有能耗从电表读取。

第二步，逐个设备做正向扰动测试。以冷却水泵为例：给定功率增量 dW，代入冷却水泵模型算出新的冷却水流量，再把新流量代入冷水机组模型，算出一个新的制冷量，和当前制冷量做差得到 dQ。dCOP = dQ / dW。如果 dCOP 大于系统 SCOP，说明“加水泵功率”这个方向是正收益；如果小于 SCOP，反方向调整再算一遍。

第三步，对所有设备计算完正的 dCOP 增量后排序，选出最大的两个。以最大值的设备为基准，把另一台设备的功率往反方向调，使得它的制冷量变化量刚好抵消基准设备的制冷量变化量——总制冷量不变，但总功率下降了。

第四步，重复第一到第三步，直到所有设备的 dCOP 和系统 SCOP 的差值收敛到预设阈值以内。

3.4 一个简化的 Python 寻优框架

import numpy as np def compute_scop(Q_total, powers): return Q_total / np.sum(powers) def compute_dcop(model_dict, device_name, dW, current_state): # 以冷却水泵为例: 给功率增量 dW, 计算制冷量增量 dQ Q_before = model_dict['chiller'].predict(current_state['chiller_input']) new_cw_flow = model_dict['cw_pump'].predict( current_state['cw_pump_power'] + dW ) # 冷却水流量变化会影响冷机冷凝侧工况，重算冷机输入 new_chiller_input = update_chiller_input( current_state['chiller_input'], cw_flow=new_cw_flow ) Q_after = model_dict['chiller'].predict(new_chiller_input) dQ = Q_after - Q_before return dQ / dW def equal_scop_optimize(model_dict, current_state, dW=0.01, max_iter=50, tol=0.02): device_names = ['chiller', 'cw_pump', 'ct_pump', 'cooling_tower'] for iteration in range(max_iter): Q_total = current_state['Q_total'] powers = np.array([current_state[f'{d}_power'] for d in device_names]) scop = compute_scop(Q_total, powers) dcop_values = {} for dev in device_names: dcop = compute_dcop(model_dict, dev, dW, current_state) dcop_values[dev] = dcop if dcop > scop else -compute_dcop( model_dict, dev, -dW, current_state ) sorted_devices = sorted(dcop_values.items(), key=lambda x: x[1], reverse=True) dev_max, dcop_max = sorted_devices[0] dev_second, dcop_second = sorted_devices[1] if abs(dcop_max - scop) < tol and abs(dcop_second - scop) < tol: break dW_adjust = current_state['Q_total'] / dcop_max * 0.01 # 基准设备加功率, 另一台减功率, 保持总制冷量不变 current_state[f'{dev_max}_power'] += dW_adjust current_state[f'{dev_second}_power'] -= dW_adjust current_state['Q_total'] = recompute_Q(current_state) return current_state

参数说明：dW 的取值建议取设备额定功率的 1%～2%。论文里的冷机额定功率 270 kW，那 dW 取 3～5 kW 左右比较合适。dW 太小，差分结果会被神经网络预测误差淹没；dW 太大，得到的 dCOP 就不是“当前工况点的边际值”，而是跨了一段区间后的平均值，方向判断会失真。tol 是收敛阈值，论文里没有给具体值，工程上 SCOP 控制在 0.02 以内就足够了。

逻辑说明：这个代码框架里做了一个简化——用最大 dCOP 设备和第二大 dCOP 设备配对调节。实际工程中，每轮参与配对的设备不一定是固定的两台，要视当前系统运行状态而定。比如某轮可能只有冷却塔风机和冷却水泵有正 dCOP，下一轮可能冷水机组自己就有余量。这个框架的收敛条件，对应论文中“所有设备 dCOP 与系统 SCOP 相等”的最优判据。你需要根据实际设备数量修改 device_names 列表，并将 update_chiller_input 和 recompute_Q 替换成真实的模型调用逻辑。

4. 地铁冷冻机房工程验证：从设备参数到能效结果全流程复现

4.1 项目基础配置与样本集构建

论文的验证对象是某地铁站冷冻机房，核心设备配置如下：

以冷水机组为例，训练样本 582 组，覆盖的工况范围从 10% 冷负荷率到 100% 冷负荷率，冷却水流量百分比 50%～100%，冷冻水流量百分比 50%～100%，冷却水进水温度按 18/20/22/24/26/28/30/32℃ 八个档位离散取值，冷冻水出水温度固定在 7℃。这个样本设计有一个细节值得注意：冷却水进水温度用的是离散档位而不是连续变量，这是为了和厂家的设计性能模型输出格式对齐——厂家提供的选型软件通常就是按这些离散工况点输出的。

4.2 训练-验证流程怎么搭

一个可复用的验证流程大致是这么走的：

第一步，从厂家获取各设备的设计性能模型。以冷机为例，就是选型软件里按不同冷却水温度和负荷率导出的 COP 表。这些表格数据就是神经网络的训练集来源。

第二步，按第 2 章的框架训练四个设备模型，记录每个模型的 WAPE。论文给出的结果是冷机 0.5%、冷冻水泵 0.33%、冷却水泵 0.92%、冷却塔 1.88%。这里建议你训练完以后额外做一件事：把训练集和验证集的误差单独列出来对比，如果两者差距过大，说明模型过拟合了，需要调整网络结构或加正则化。

第三步，把全年运行时间按负荷率加权，用等 SCOP 算法做全年逐时寻优仿真。论文使用的全年负荷率权重分布是：10% 负荷率占 2.73%、20% 占 17.00%、30% 占 19.75%、40% 占 14.10%、50% 占 14.50%、60% 占 25.65%、70% 占 4.38%、80% 占 1.74%、90% 占 0.16%、100% 负荷率权重视设备运行模式而定。算出的全年平均系统能效 5.14，和直接求解厂家设计模型得到的 5.18 误差在 1% 以内。

第四步，对比实测运行数据。论文随机选了制冷季两天的现场数据，每隔 10 分钟记录一次，发现冷机实际运行能效和厂家设计模型的偏差达到 10.18% 和 12.75%。这一步的意义在于：验证了算法框架本身是对的，也暴露了数据源头的问题——厂家的设计模型是在标准工况下测出来的，现场有水质、污垢、安装误差、部分负荷衰减等各种因素，实际特性和设计曲线偏差巨大。

4.3 这份资源里你能直接用到的验证代码

这里把从设计模型样本集到误差对比的完整流程写成一个脚本骨架：

import pandas as pd import numpy as np def generate_design_samples(design_curves, load_rates, cooling_temps): # 遍历冷机选型表, 生成训练样本 samples = [] for load_rate in load_rates: for tc_water in cooling_temps: cop = design_curves.interp(load_rate, tc_water) q_chill = load_rate * 1160 # 额定冷量1160kW power = q_chill / cop samples.append({ 'load_rate': load_rate, 'tc_in': tc_water, 'q_chill': q_chill, 'power': power }) return pd.DataFrame(samples) def validate_with_field_data(model, field_data): # 用现场数据预测冷机功率, 和实测功率对比 field_data['pred_power'] = model.predict( field_data[['tc_in', 'tc_out', 'flow_cw', 'flow_chw']] ) field_data['error_pct'] = np.abs( field_data['pred_power'] - field_data['power'] ) / field_data['power'] * 100 wape_value = np.sum( np.abs(field_data['pred_power'] - field_data['power']) ) / np.sum(field_data['power']) * 100 return wape_value, field_data

这个脚本骨架的 generate_design_samples 函数，用厂家选型表的插值结果生成训练样本，validate_with_field_data 函数用现场实测数据做反向验证。如果你的项目没有厂家设计模型数据，可以用设备铭牌上的额定点配合部分负荷性能曲线公式来造样本——精度会差一些，但作为算法验证已经够用。

4.4 数据采集频率的坑

论文实测数据的采样间隔是 10 分钟一次。这个频率在暖通领域已经是偏密的了——很多 BA 系统的历史数据是 15 分钟甚至 1 小时一条。但要注意：10 分钟采样下冷机的功率波动仍然很大，压缩机的启停、滑阀调节都会造成瞬时功率抖动。建议你在做模型训练之前，先对原始数据做滑动平均平滑处理，窗口设 3～5 个采样点。不处理的话，训练出来的模型会对噪声过度敏感，WAPE 会偏高。另外，如果做逐时寻优仿真，时间步长建议对齐到 15 分钟或 30 分钟，因为冷冻水系统本身有较大的热惯性，1 分钟内完成一次功率调整在物理上不可行，算出来的“最优”也只是数学意义上的最优。

5. 避坑指南：设计模型训练出的神经网络，别直接拿去控制实际项目

5.1 设计模型偏差 10% 以上，训练数据必须用现场实测

这是论文最核心的结论，也是我这篇笔记最想强调的坑。现象：用厂家设计性能模型训练的冷机神经网络，在实测数据上预测功率的误差达到 10.18% 和 12.75%。原因：厂家的设计模型是基于新机、标准工况、额定流量下测得的，而实际运行中冷机存在换热器结垢、冷冻油老化、安装位置散热不良、部分负荷率下频繁加减载等问题，导致实际 COP 曲线整体下移。解决：模型训练数据必须来自项目现场的实测运行数据，并且要覆盖全年不同负荷率和不同湿球温度的组合。论文给出的标准是“依据全年不同负荷率和不同环境湿球温度下的实际运行数据，生成大量数据样本”。实操中，至少要积累一个完整制冷季的数据，确保样本覆盖 30%～100% 的负荷率区间，每个区间至少 200 组以上样本。

5.2 黑箱模型不能求导，只能用数值差分近似 dCOP

现象：想在寻优算法里直接调用神经网络的梯度，发现报错或者结果完全不合理。原因：神经网络由多层非线性激活函数堆叠而成，ReLU、sigmoid 这些激活函数导致输出对输入的梯度是分段常数甚至不连续，直接用反向传播算出的梯度在工程尺度上没有意义。而且你要算的 dCOP = dQ/dW 不是单一网络对输入的梯度，而是跨了多个设备模型的链式复合，误差会被逐级放大。解决：老老实实用数值差分，给功率一个有限增量 dW，前向跑一遍各设备模型，用输出差除以输入差。dW 的量纲和数量级前面已经提过——取额定功率的 1%～2% 是一个比较可靠的区间。

5.3 寻优步长太大，系统直接震荡

现象：等 SCOP 算法下发调节指令后，冷冻水出水温度在目标值附近来回振荡，机组频繁启停。原因：算法每次计算的调整量是基于线性近似的 dCOP，但实际系统是非线性的，尤其在冷机接近满载或最小负载区段，制冷量对功率的响应会明显偏离线性关系。步长取太大，一步就跨过了最优工作点。解决：对下发的功率调整量做限幅，单次调整幅度不超过设备额定功率的 5%。另外在算法里加了阻尼系数，实际下发值是计算调整量乘以 0.6～0.8，剩下的部分在下一轮迭代里继续调整。这样可以避免超调。

5.4 只见设备不见系统，冷机模型精度再高也没用

现象：单独验证冷水机组模型，WAPE 只有 0.5%，但整个寻优算出来的能效和实际运行差距很大。原因：冷机模型再准，也只代表冷机这一台设备的特性。寻优算法要的是“冷机功率变化如何影响冷冻水泵、冷却水泵和冷却塔的运行状态”这个完整的链路。比如你把冷机功率加大，冷却水回水温度会升高，冷却塔的散热负担加重，风机可能要提速，这时候系统总能耗可能不降反升。解决：做寻优的时候，每轮计算必须把所有设备的模型都刷新一遍，不能只更新正在调节的那台设备。这也是论文强调“系统 SCOP”而不是“设备 COP”的根本原因。

5.5 训练数据的工况覆盖不完整，模型外推会乱飙

现象：训练集里没有 18℃ 以下冷却水进水温度的数据，结果春季过渡季气温骤降时，模型预测的冷机功率出现严重偏差。原因：神经网络擅长插值，不擅长外推。训练数据的最小值和最大值之外，网络行为完全不可控——ReLU 网络在外推区间的输出往往是直线外延或者直接饱和，没有任何物理约束。解决：对模型做输入边界检查，实际运行参数超出训练集范围时，回退到最近邻工况的预测值，或者用物理模型的输出做兜底。更进一步的办法是在训练时做数据增强，给冷却水温度加入 ±1℃ 的随机扰动，让模型在边界处的预测平缓一些。

6. 把模型搬到实际项目：在线学习与滑动窗口重训的落地技巧

整套技术里，从论文走向产品化最关键的一步是解决“模型会老”的问题。冷机运行三个月后，换热器结垢导致换热效率下降；冷却塔填料老化导致散热能力衰减；冷冻水泵轴承磨损导致同样频率下流量下降——静态模型在这些变化面前会逐渐失效。我一般会用“离线训练 + 定期重训”的分层策略来应对，而不是每时每刻都在线更新模型，那样会把噪声也学进去。

具体做法是维护一个滑动窗口：保留最近 90 天的运行数据，每周触发一次重训任务，用最新数据重新训练四个设备模型，并自动对比新旧模型在最近一周数据上的 WAPE。只有当新模型的 WAPE 比旧模型低 0.3 个百分点以上时才切换，否则继续沿用旧模型。这样做的好处是既跟上了设备特性的慢漂移，又不会因为单周的异常数据导致模型跳变。

滑动窗口重训的伪代码框架大致是这样：

def scheduled_retrain(window_data, current_models): # window_data: 最近90天运行数据 # 按设备拆分成四个训练集 train_data = split_by_device(window_data) # 训练新模型 new_models = {} for device, data in train_data.items(): new_models[device] = train_device_model( data, device_feature_cols[device], device_target_col[device] ) # 用最近7天数据做A/B对比 val_data = window_data[window_data.timestamp >= now() - 7d] old_wape = evaluate_models(current_models, val_data) new_wape = evaluate_models(new_models, val_data) # 只在新模型明显更优时切换 if new_wape < old_wape - 0.3: return new_models else: return current_models

触发条件里加一个强制重训的兜底：如果当前模型的 WAPE 超过 5%，不管新旧对比结果如何，都必须用最近 30 天的数据做紧急重训。这对应的是冷机发生故障维修、冷却塔更换填料等重大设备变更的场景——这时设备特性发生了突变，正常的滑动窗口更新跟不上变化速度。

参数调优方面，90 天的窗口长度、0.3 个百分点的切换阈值、5% 的强制重训阈值，这几个数字是经验值。南方地区的制冷季长，90 天窗口足够覆盖负荷率的大幅变化；北方地区冬天不制冷，窗口要适当放宽到 120 天甚至更长，否则窗口里全是过渡季的低负荷数据，训出来的模型应对盛夏工况会力不从心。

这篇论文提到的所有坑里，我最想提醒的是：算法框架本身是能复现的，但结果好不好，完全取决于你有没有一套靠谱的现场数据采集和清洗流程。从那以后我每次都强制走一遍“数据质量检查 → 工况覆盖分析 → 模型训练 → 偏差对比 → 现场验证”的完整流程，宁可多花一周时间做数据预处理，也绝不用设计模型直接顶上去。希望帮到你——下载这篇论文回去对照着把四个模型建出来，再做一轮等 SCOP 寻优仿真，你会比我更快吃透整套逻辑。

本文还有配套的精品资源，点击获取