两套系统一张屏：为什么融合成了必答题

工厂、园区、大型公共建筑里常见这样的场景：配电室、水泵房归SCADA管，空调、照明、新风归楼宇自控（BA/BMS）管——两套系统、两块大屏、两份报表。设备管理部门每天在两套界面之间来回切换，想回答一个简单的问题——"昨天这栋楼用了多少电、其中空调占多少"——得先从两边各导出一份数据再手工拼表。项目验收时甲方最常提的要求就是"能不能一个屏看全部"。

融合架构不是技术炫技，而是运维效率问题。但融合也绝不是把两套系统简单对接：控制权限、实时性要求、协议生态都不一样，设计失误轻则数据不通，重则威胁控制安全。本文给出一套经过项目验证的融合架构设计方法。

一、先认清两套系统的基因差异

SCADA（数据采集与监视控制系统）出身流程工业，强项是"监视"——面向变配电、动力、水泵房这类源网侧设备，强调报警分级、事故追忆与毫秒级事件顺序记录。楼宇自控出身建筑环境控制，强项是"闭环调节"——温湿度、新风、照明的自动运行，控制回路周期以分钟计，点位分散、协议多样。

差异决定了融合的第一原则：控制逻辑不动，监视数据上行。

二、三种融合模式，按项目规模选型

模式一：BA为控制核心，SCADA只做监视层（多数单体建筑推荐）。DDC控制器闭环控制原样保留，SCADA通过OPC UA或Modbus TCP以只读方式采集BA侧关键运行参数：冷站群控状态、空调机组运行频率、区域温湿度、分项能耗总量。SCADA获得全局视图但不碰控制，控制安全边界清晰，也是验收阻力最小的路线。

模式二：SCADA上收多楼宇、园区（集团级能源管理）。各楼BA数据经边缘侧网络控制器汇聚后统一上行至园区SCADA或能源管理平台，做跨楼对标、负荷预测与需量管理。楼宇侧汇聚节点的选型直接决定工程量——支持BACnet/IP与Modbus TCP双栈、自带历史缓存的控制器能省掉一层协议网关。

模式三：并行运行加数据中台（既有项目改造）。两套系统都不动，由数据中台分别从两侧取数，做统一看板与报表。适合运行多年、没人敢动的老系统，代价是实时性降一档，报警闭环仍需回原系统处理。

三、数据流设计：点位先行，分级上行

融合失败最常见的根因，是点位没规划就开发接口。上行SCADA的点建议只保留四类：设备运行状态、关键运行参数、分项能耗、系统级报警。点表冻结前可参考能耗监测数据采集点设置原则与实战技巧中的分项计量思路——上行点位越少、语义越清晰，后期维护成本越低。

上行数据按用途分级采集：设备状态1分钟以内，温湿度5分钟，电耗15分钟；趋势存储按短周期（30天高频）加长周期（3年日统计）双档设计。所有系统先统一时钟——跨系统报警对齐、能耗曲线比对都建立在时间同步之上，这一步漏掉，联调阶段要付出成倍代价。

报警同样要分级：就地控制类报警留在BA系统实时处理，SCADA只接收设备级与系统级报警，并配置合理的重复告警抑制——否则一次冷站跳机，就是几百条刷屏。

四、协议与接口：融合的技术底座

BA侧接入以Modbus和BACnet为主，两者的对象模型与寄存器组织方式直接决定点表设计的工作量，楼宇自控通信基础的细节见Modbus/BACnet协议详解：楼宇自控通信基础。跨系统、跨厂商的上行接口优先走OPC UA——命名空间统一、自带安全通道，比逐设备开发Modbus轮询稳健得多，其架构优势见OPC UA：工业4.0时代的统一通信标准。

楼宇侧控制器承担"承下启上"的关键角色：对下用BACnet收末端DDC数据，对上用Modbus/OPC UA向SCADA供数。选型时重点核查双协议栈支持、断线缓存容量与重连补传机制——弱电集成项目中这类分层架构的实践，可参考ECC200网络控制器在楼宇自控和弱电集成项目中的数据架构。

接口开发清单务必包含五项：双方确认的点表及命名规则、读写权限矩阵、断线缓存与重连补传策略、时钟同步方案、联调用例（含断网演练）。

五、实施路线与验收要点

推荐实施顺序：现状调研、点表冻结、接口开发、并行联调、30天试运行、培训交接。每一步都有明确交付物，避免边开发边改需求。

验收时重点核查四类问题：点位抽查（命名、单位、倍率）、报警重复与抑制策略、历史数据连续性（重点看断网补传时段）、跨系统时间偏差。涉及控制网与信息网互联的，按分区分域原则加防火墙，SCADA侧默认只读权限，控制写操作单独审批留痕。

按建筑类型对照落地的融合案例，可在智颖汇项目案例库中按场景检索。

结语

SCADA与楼宇自控的融合，本质是一次"分层分工"的设计：控制留在BA，监视交给SCADA，数据在统一时钟和统一点表下流动。事先想清楚哪些数据上行、以什么周期、走什么协议，融合就只是工程量问题，而不是技术赌博。