本项目处于建设实施阶段，尚未整体交付运行。页面描述的是已确定的技术架构与实施中的取舍， 规模类数字来自设计与测算，不是运行后的统计值。已交付项目会单独标注「已交付」。
这个项目难在哪
每个案例的难点都不一样。先把难点说清楚，方案才有意义。
机场是大空间、全天候运行，能耗强度远高于普通公建，节能空间大但控制难度也大
空调、照明、电梯、通风分属不同厂商不同年代，协议五花八门
航班是动态的，延误、备降、临时加班都会打乱预设的节能策略
能耗数据要分到区域、分到系统、分到租户，计量点位的划分比采集本身更难
机场能耗的特殊性：为什么普通楼宇节能方案套不过来
机场航站楼有几个特点决定了它的能耗管理不能照搬写字楼方案：
- **大空间高挑空**：航站楼大厅层高动辄十几米，空调要处理的空气体积是普通公建的数倍，冷量损失也大
- **全天候运行**：首班航班到末班航班之间几乎不停，很多区域 24 小时有人
- **人流波动剧烈**：早高峰、晚高峰、航班集中到达时人流密度差异巨大，固定策略必然浪费
- **多租户**：商业、餐饮、广告、贵宾厅，能耗要能算到每个租户头上
但机场有一个普通楼宇没有的东西：**航班时刻表**。
航班什么时候到、什么时候走、延误多久，理论上都是已知的。这意味着空调和照明不需要按「几点到几点」这种死板的定时策略运行，可以按「这个登机口 40 分钟后有航班到达」来提前启动。
这是机场能耗管理真正的价值点，也是这个项目的核心设计。
五层架构：从终端到驾驶舱
| 层 | 组成 | 说明 |
|---|---|---|
| 物联终端 | 视频、空调、电梯、智能照明、通风、人体监测、环境监测、航班系统、区域门锁 | 9 类终端，含非能耗类设备 |
| 网络联接 | 局域网、防火墙、千兆光网、MQTT、IoT 网关、5G、WIFI、SNMP | 有线为主，无线补盲 |
| 智能服务 | 三维 GIS 引擎、AI 识别、仿真组件、边缘计算、空间平台、通信服务、业务流程、视频转码、IoT 平台 | 能力层，9 个组件 |
| 业务平台 | 能耗监控管理平台（8 个模块） | 核心业务逻辑 |
| 应用展示 | 能耗大屏、应急调度中心、智能驾驶舱、PC 端、移动端 | 5 种呈现形态 |
8 个业务模块是：能耗总览、能源能耗、给排水管理、照明管理、空调管理、安防管理、运维管理、充电桩管理。
这个模块划分值得说一句：它没有按「技术功能」划分（采集、存储、分析），而是按「业务对象」划分。每个模块对应一类设备或一类业务，使用者打开就知道去哪找。这是面向运维人员的划分方式，不是面向开发者的。
安防（视频、AI 抓拍、火灾监测）和充电桩看着和能耗无关，但放在同一个平台是有道理的：安防要为能耗策略提供「有没有人」的判断依据，充电桩本身就是新的能耗大户。把这三件事分开建系统，数据永远对不上。
难点一：分项计量，分到哪一层才算够
能耗系统第一件事是「分项计量」：把总用电拆成可归因的份额。拆得粗了没用，拆得细了成本扛不住。
机场通常要同时按三个维度拆：
| 维度 | 拆分方式 | 用途 |
|---|---|---|
| 按系统 | 空调、照明、动力、电梯、行李系统、弱电 | 看哪类设备耗电最多 |
| 按区域 | 航站楼、指廊、商业区、贵宾厅、机坪 | 看哪个区域有节能空间 |
| 按租户 | 商业、餐饮、广告、其他 | 向租户收能耗费 |
三个维度交叉，计量点位数量会翻几倍。现实做法是**主干必分、末端抽测**：空调、照明、动力三条主干必须有独立计量；末端区域用抽样点位 + 面积分摊估算。
「按租户」这一维最容易出纠纷。租户会质疑分摊规则，所以规则必须在合同里写清楚，系统只负责按规则算，不负责定规则。这一条如果一开始没说清，后面能耗账单永远扯皮。
见过不少项目，表装了但接错回路——把消防负荷接到了普通照明回路，把空调主机接到了动力总表。数据看着有，分析全是错的。验收时必须做「单设备启停验证」：关掉一台空调主机，看对应回路的读数是否下降。
难点二：航班联动，把时刻表变成控制指令
这是整个项目最有价值也最难的部分。逻辑听起来简单：航班要来了，提前把空调和照明打开；航班走了，关掉。实际落地要解决四个问题。
问题一：航班数据从哪来
机场有 AODB（航班信息集成系统），提供计划、预计、实际三类时间。能耗平台通过接口获取，不自己算。
关键在于要用**哪个时间**。计划时间不准，预计时间会变，实际时间滞后。正确做法是：预冷预热用「预计时间」，因为要提前启动；关闭策略用「实际时间」，因为要等旅客真的走完。
问题二：提前多久开
开早了浪费，开晚了旅客投诉。提前量和空间体积、空调能力、室外温度都相关。航站楼大厅这种大空间，夏季预冷可能需要 40 分钟以上；小型贵宾厅 10 分钟就够。
系统把提前量做成可配置参数，按区域类型分组设置，而不是全局一个值。并且支持按季节调整——夏季和冬季的预冷预热逻辑完全不同。
问题三：延误怎么办
航班延误是机场的常态。原定 20:00 起飞的航班延到 23:00，如果按原计划 20:30 关空调，旅客要在闷热的登机口等三个小时。
处理方式是订阅航班的预计时间变更事件：一旦预计时间后移超过阈值，自动延长该区域的供冷供热时段。同时设一个兜底——区域人体监测传感器检测到还有人，就不执行关闭。
问题四：夜间大面积降载的安全边界
末班航班结束后，航站楼进入夜间模式，大面积降低空调和照明。这时候必须保留哪些？应急照明、消防通道、安防监控、值班区域、以及次日首班航班的预冷预热能力。
这条边界必须在实施阶段和运行部门一起确认，写成清单。系统按清单执行，不能由算法自行决定——节能出事故，责任比省下的电费大得多。
难点三：设备年代跨度大，协议五花八门
机场的设备是分批建设的，新航站楼用最新的 IoT 设备，老指廊可能还在跑十年前的楼控系统。空调侧尤其复杂：VRV 空调、空气源热泵、集中冷水机组，三套系统三种控制方式。
接入策略是按设备能力分三档：
| 档位 | 设备特征 | 接入方式 |
|---|---|---|
| 原生接入 | 支持 MQTT / Modbus TCP 的新设备 | 直连 IoT 平台 |
| 网关接入 | 有本地总线或串口的老设备 | 加采集网关，协议转换后上行 |
| 系统对接 | 已有独立管理系统的（楼控、电梯、充电桩） | 对接厂商平台接口，不碰设备层 |
第三档最省事也最受限：能拿到什么数据取决于厂商开放什么。电梯系统通常只给运行状态和故障码，不给实时载荷；充电桩平台一般接口完整。
SNMP 在这个项目里也有用处——网络设备、部分机房设备走 SNMP 采集，和 IT 运维共用一套协议。
难点四：为什么必须有边缘计算
架构图里「智能服务」层有一个「边缘计算」组件，这不是为了概念好看。
空调和照明的控制指令，如果全部走「终端 → 云平台 → 下发」的链路，网络抖动或平台维护时就会失控。航站楼的空调不是开关灯，涉及冷水机组、风机、阀门联动，指令延迟太久会出问题。
边缘节点的作用是：**策略在云端算，执行在本地做**。云端下发的是「这个区域 19:30 开始预冷到 24℃」这样的策略，边缘节点自己按本地传感器数据执行，不依赖云端实时在线。
- 断网时边缘节点按最后一条策略继续运行，不会全楼停摆
- 本地闭环响应快，温度偏差能在秒级修正，不用等云端往返
- 云端只做策略优化和数据汇总，不承担实时控制职责
这个分界如果搞反——云端直接控设备——系统会非常脆弱，一次网络波动就可能造成大面积异常。
三维 GIS 与驾驶舱：给谁看，看什么
架构里同时有「三维 GIS 引擎」「能耗大屏」「智能驾驶舱」「移动端」，四套呈现方式。这不是重复建设，是给三类人看的。
| 呈现 | 使用者 | 核心内容 |
|---|---|---|
| 能耗大屏 | 领导、参观 | 总量、趋势、排名、达标情况 |
| 智能驾驶舱 | 能源管理岗 | 分项能耗、异常预警、策略执行情况 |
| 三维 GIS | 运维、调度 | 设备位置、故障定位、区域能耗热力 |
| 移动端 | 现场人员 | 工单、巡检、告警处理 |
三维 GIS 在机场场景里确实有用：航站楼是多层大空间，设备位置用二维平面图标不清。但要注意成本——精细建模的费用可能超过平台本身。务实做法是**先做重点区域**（航站楼主楼、主要机房），其余用二维。
大屏最容易变成摆设。判断标准很简单：如果这个大屏上的数据，能源管理岗每天不看就没法工作，它就有价值；如果只是参观时亮着，那就是装饰。
四条判断
- 1**航班联动是机场能耗系统的核心价值**，不是附加功能。没有它，这套系统就是个高级电表。
- 2**分项计量要先定规则再装表**。租户分摊规则、区域划分规则不写清楚，数据再准也会扯皮。
- 3**控制必须放在边缘**。云端只做策略优化，实时控制下沉到本地，否则系统脆弱到无法交付。
- 4**夜间降载的安全边界要写成清单并由运行部门签字**。算法不能自行决定关什么，节能出事故责任远大于电费收益。
机场能耗管理的难点不在采集，在「怎么把航班时刻表翻译成设备控制指令」，以及「出了问题谁负责」。前者是技术，后者是流程，两个都得设计。
有类似的项目？
把你的现场情况说清楚就行，不用先写需求文档。我们会告诉你从哪切入最划算、哪些环节其实可以不花钱。