工厂中央空调能效KPI监测体系：SCADA架构落地与跨基地数据治理实战

（平台提示：本文可能是商业推广软文）

 

这篇文章面向工业能源管理工程师、工厂设施部、暖通运维负责人。工厂的中央空调和通风系统年耗电动辄占工厂总能耗的 30~50%，但很多工厂连"自己一个月用了多少电、用在哪个车间"都说不清楚。本文系统讲解一套面向制造业工厂的中央空调能效 KPI 监测体系，从 SCADA 架构、KPI 拆解、数据治理到跨基地对标，配合广州一木机电团队在曼盛包装跨区工厂（广州+安徽双基地）的真实落地案例。

一、工厂能耗监测的"三大灵魂拷问"

每次给工厂客户做能耗诊断，几乎都会遇到三个问题：

1. "我们一个月空调用电多少？" —— 没人答得上来
2. "哪个车间最耗电？" —— 没人答得上来
3. "为什么这个月电费比上个月多 8 万？" —— 还是没人答得上来

这三个问题答不上来的根本原因不是没有电表，而是没有体系——电表数据散落在各个柜子里，没人定期抄、没人对账、没人分析。

要解决这个问题，必须建立一套自上而下的能效 KPI 监测体系。

 

二、KPI 体系：从"瓦数"到"业务指标"

工业能耗监测的 KPI 不是单一指标，而是一个层级体系：

plaintext

 

Level 1（公司级）：单位产值能耗 (kWh/万元产值)

│

Level 2（基地级）：单位面积能耗 (kWh/㎡·a)、空调能耗占比

│

Level 3（系统级）：冷站综合 EER、单位制冷量电耗 (kWh/RT·h)

│

Level 4（设备级）：单台主机 COP、水泵效率

 

每一层 KPI 都有不同的"用户"：

 

层级	KPI	用户	频率
L1	单位产值能耗	总经理、董事会	月度
L2	单位面积能耗、空调能耗占比	设施总监	周度
L3	冷站 EER、单位制冷量电耗	能源经理	日度
L4	主机 COP、水泵效率	运维班长	实时

 

只关注一层是不够的——总经理只看"单位产值能耗"，运维只看"主机 COP"，中间层断了，问题永远找不到根因。

2.1 关键 KPI 公式

text

 

冷站综合 EER = 总制冷量 (kW) / 冷站总耗电 (kW)

= (冷量表读数) / (主机+水泵+冷塔耗电之和)

 

单位制冷量电耗 = 冷站总耗电 / 总制冷量

= 1 / 综合 EER

通常以 kWh/RT·h 表示

 

单位面积空调能耗 = 空调系统全年耗电 / 服务面积

= kWh/㎡·a

 

单位产值能耗 = 全厂总耗电 / 产值

= kWh/万元产值

2.2 KPI 基准值（工业空调参考）

KPI	落后水平	中等水平	先进水平
冷站 EER	< 3.5	3.5 ~ 4.5	> 4.8
单位制冷量电耗 (kWh/RT·h)	> 1.0	0.7 ~ 1.0	< 0.65
工厂车间单位面积空调能耗 (kWh/㎡·a)	> 200	130 ~ 200	< 120
工厂总能耗中空调占比	> 50%	30 ~ 50%	< 30%

 

三、SCADA 架构：从底层到展现

工厂级能效监测系统的标准架构（笔者团队的工程模板）：

plaintext

┌────────────────────────────────────────────────┐

│ Web 看板 + 移动 App + BI 报表 │ ← 展现层

└──────────┬─────────────────────────────────────┘

│ HTTPS / WebSocket

┌──────────▼─────────────────────────────────────┐

│ SCADA 主站（自研 / Wonderware / iFIX） │ ← 监控层

│ 历史库 + 趋势 + 报警 + 工单 │

└──────────┬─────────────────────────────────────┘

│ OPC UA / MQTT

┌──────────▼─────────────────────────────────────┐

│ 时序数据库（TDengine / InfluxDB） │ ← 数据层

└──────────┬─────────────────────────────────────┘

│ MQTT

┌──────────▼─────────────────────────────────────┐

│ 边缘网关（工控机） │ ← 边缘层

│ 协议转换 + 本地缓存 + 预处理 │

└──────────┬─────────────────────────────────────┘

│ Modbus RTU/TCP, BACnet

┌──────────▼─────────────────────────────────────┐

│ PLC + 主机 + 水泵 + 冷塔 + 电表 + 冷量表 │ ← 现场层

└────────────────────────────────────────────────┘

 

每一层都有明确的职责：

• 现场层：把物理量变成电信号
• 边缘层：协议转换+缓冲+预处理
• 数据层：长期存储+查询
• 监控层：实时展现+报警+工单
• 展现层：业务 KPI 与决策支持

 

四、关键测点布局：哪些点必须接、哪些可选

很多工厂能耗监测项目失败，原因是"什么都想接，结果什么都没接好"。建议按"必须 + 可选"分级

4.1 必须接（核心 KPI 计算依赖）

测点	数量	设备	用途
冷站总进线电表	1	多功能电能表	计算冷站总耗电
主机分电表	N（每台主机 1 块）	电能表	计算主机 COP
冷量表（冷冻水侧）	1~2	超声波冷量表	计算总制冷量
冷冻水进出温度	各 1	Pt100	冷量计算备用
冷冻水流量	1	电磁/超声波流量计	冷量计算备用
冷却水温度	各 1	Pt100	冷塔效率分析
主机运行状态/负荷率	每台	Modbus	加减载分析
室外温湿度	1 套	一体式传感器	工况修正

 

4.2 推荐接（精细化分析需要）

• 末端电表（按车间 / 按生产线）
• 水泵单机电表
• 冷塔风机电表
• 关键车间室内温湿度（每车间 ≥ 3 点）
• 新风温湿度

4.3 可选接（高级运维诊断）

• 主机蒸发/冷凝压力
• 主机进出水压力
• 冷冻水管路压差
• 阀门开度反馈

实战经验：必须类接齐 80% 价值就有了，推荐类拿到剩下的 15%，可选类是 5% 。预算有限时，优先把必须类做实。

 

五、案例：曼盛包装跨区工厂能效监测体系

5.1 项目背景

曼盛包装是华南一家专业的包装制造企业，在广州（黄埔区）和安徽（合肥）建有双生产基地，业务涉及食品包装、消费品包装等。两地生产场景类似但气候差异大：

• 广州：高温高湿、空调季长（4~10 月）
• 安徽：四季分明、冬天需要供暖

业主诉求：

1. 双基地能耗统一可视化
2. 找出能耗"黑洞"（哪个车间、哪个时段最耗电）
3. 印刷车间温湿度精控（直接影响产品质量）
4. 月度能耗报告自动生成（替代 Excel 手工）
5. 跨基地数据对标（同样产能下，谁更省）

 

5.2 系统部署情况

广州基地：

• 6 台中央空调主机（含 2 台变频螺杆机）
• 14 台空压机
• 32 台车间通风/降温机组
• 多台岗位送风末端
• 总冷负荷 1800kW

安徽基地：

• 4 台中央空调主机
• 9 台空压机
• 20 台车间通风/降温机组
• 总冷负荷 1100kW

监测系统部署：

 

部分	数量/规模
现场电表	86 块
冷量表	4 块
流量计	12 块
温湿度传感器	60+ 个
边缘网关	4 台（每基地 2 台双机热备）
时序数据库	TDengine 3 节点集群
总数据点位	约 3200 个

 

5.3 KPI 仪表盘示例

我们为业主设计的几个核心仪表盘：

【1. 总经理驾驶舱】

• 双基地本月总耗电与同比
• 单位产值能耗排名
• 重大异常告警

【2. 设施总监周报】

• 各车间能耗分布饼图
• 空调系统能耗占比
• 周对比柱状图

【3. 能源经理日报】

• 冷站综合 EER 趋势
• 主机分台 COP 对比
• 异常时段热点图

【4. 运维班长实时屏】

• 主机运行状态
• 进出水温度
• 报警列表

每张报表针对不同角色，避免"一张报表给所有人，所有人都用不上"的困境。

 

5.4 实施后的效果

系统稳定运行 12 个月后的核心数据：

 

KPI	实施前（估算）	实施后（实测）	变化
广州基地冷站 EER	3.6	4.3	+19%
安徽基地冷站 EER	3.4	4.1	+21%
单位产值能耗	基准 100	88	-12%
月度能耗报告生成时间	2~3 天人工	自动 1 分钟
故障平均发现时间	4 小时	8 分钟	-97%
印刷车间温湿度合规率	86%	99%	+13pp

 

电费节省：合并测算，全年节省电费约 78 万元。系统投资约 165 万元，回收期 2.1 年。

更关键的是，业主第一次"看到了"自己的能耗——以前总觉得"反正都得用"，看到数据后主动要求做更深的优化（比如车间空压机移机、新风预冷等）。

 

六、跨基地数据治理的几个关键点

6.1 时间戳标准化

不同基地的服务器时区可能不同，必须统一存储为 UTC，前端按用户时区展示。

python

 

# 写入数据时

timestamp_utc = datetime.datetime.now(datetime.timezone.utc)

db.write(measurement, fields, timestamp_utc)

 

# 查询展示时

timestamp_local = timestamp_utc.astimezone(timezone('Asia/Shanghai'))

 

6.2 单位统一

电量统一用 kWh，温度统一用 ℃，流量统一用 m³/h——任何"看着像 SI 但其实是字段约定不同"的情况都要在数据治理阶段杜绝。

 

6.3 设备元数据管理

每个设备都要有"身份档案"：

yaml

device_id: GZ-CHILLER-01

device_type: water_cooled_screw_chiller

brand: 麦克维尔

model: WPV-300

location:

base: 广州基地

building: 1#冷站

floor: 1F

nominal_capacity_kw: 300

commission_date: 2023-05-15

 

元数据放在专门的资产管理库，KPI 计算和报表都引用它，避免硬编码。

 

6.4 数据质量监控

每个测点都要做：

• 死值检测（连续 N 个采样值不变）
• 异常值检测（超过 3 倍标准差）
• 缺失率统计（日缺失率 > 5% 报警）
• 跳变检测（前后两个采样值差超过物理合理范围）

这些规则要在数据入库前的 ETL 层执行，不能等到 BI 层才发现"数据有问题"。

 

七、几个常见反面教材

反面 1：电表装了但从不抄

某工厂装了 30 块电表，全部接到一个集中显示屏上，但 6 年没人导出过数据。这种"形式主义"投资完全是浪费。

反面 2：报警太多导致"报警麻木"

某项目刚上线时一天 200+ 报警，3 个月后运维人员形成"看到告警就 dismiss"的习惯，真正的故障反而被忽略。报警必须分级，关键事件优先弹出，普通事件汇总报告。

反面 3：报表没人看

辛辛苦苦做了 20 张 KPI 报表，结果只有能源经理看，老板看不懂、运维觉得没用。报表设计必须围绕"用户决策需要的信息"来做，每张报表要回答一个具体问题。

反面 4：数据库无限膨胀

某项目运行 3 年后，数据库占用 4TB，查询从秒级退化到分钟级。必须做数据生命周期管理——原始数据保留 30 天，1 分钟聚合保 1 年，1 小时聚合长期保留。

八、几条工程化建议

1. 先 KPI 后系统：先和业主对齐 KPI 定义，再设计系统架构，不要倒过来
2. 必须类先做：核心电表、冷量表、温度传感器先到位，其他可分期
3. 报表给"用的人" ：不同角色的报表分别定制，避免大杂烩
4. 运维深度参与：运维不参与设计的系统，最终都会被运维改回手动
5. 每月做能耗例会：把数据用起来才是节能的开始
6. 跨基地对标要谨慎：不同基地工艺、产能、气候都不同，对标前先做"工况修正"

 

九、写在最后

工厂中央空调的能效 KPI 监测体系，本质是一项 "先治理、后优化" 的工程。如果数据本身不准、不全、不及时，所有"AI 节能、智能优化"都是空中楼阁。

广州一木机电技术团队过去几年在曼盛包装跨区工厂、华南理工大学等多个项目里都按上述方法论搭建了能效监测体系。我们的核心理念是：节能不是一个一次性项目，而是一套持续运营的体系——它需要数据基础、KPI 体系、运维流程、定期评审四件事一起做。任何一件少了，节能效果都会随时间衰减。

如果你正在评估自己工厂是否值得做能效监测改造，可以从以下几个维度判断：

• 月度电费是否超过 30 万元（投资回报够）
• 是否涉及温湿度敏感的工艺（如印刷、电子、食品）
• 是否有多个生产基地或车间需要对标
• 是否有节能减碳的合规压力（双碳、绿色工厂认证）

满足两条以上，就值得动手做。

 

作者：广州一木机电技术团队
领域：工厂能效监测 / SCADA 系统集成 / 工业暖通节能
关键词：能效KPI、SCADA系统、TDengine、工厂中央空调、能耗监测平台