“集成”还是“融合”
——论IBMS与物联网智慧云平台的选择

刘宇辉，周祖寿，李杭

（筑博设计-智慧建筑研究中心）

1 智能建筑的痛点

建筑智能化工程技术起源于自动控制技术、计算机技术、通信技术在建筑工程领域的应用。在其二十多年的发展历程中，不断吸收ICT行业的科技成果优化和丰富自身，它曾经历过标准化、数字化、网络化的发展与演变，伴随近年来物联网、大数据、云计算、AI、5G的兴起，业已朝向泛在化、协同化、智慧化演进。然而，由于智能化工程的各组成子系统是独立设计研发的，整体上缺乏顶层设计，且各子系统的技术革新程度差异悬殊，其结果是子系统之间协同性差、难以发挥工程的整体效益与优势。

智能建筑中的近三四十个子系统，皆是应当时的市场需求而被陆续一一创生的。智能建筑产品供应商为了解决现代建筑某一方面的管理问题，采取传统的垂直系统架构，配制服务器和数据库、架设网络连接设备、建模型，采用面向过程的程序设计实现业务逻辑，基本上都是垂直地搭建封闭的应用系统。

而各个系统创生年代不同、设计生产的厂商不同，数据格式、编程思想、遵循协议均不相同。为了满足智能建筑的功能需要，智能化工程的实施单位在同一建筑中将它们生硬地汇集在一起，交付给建筑管理方，构建出一种烟囱丛林式的智能化工程架构。在这种构架之中，各个子系统都是完整独立的，在硬件软件体系、数据结构上都是各自为政，从终端、管线到后台服务器与存储均相对独立。既没有统一的数据格式、语义标准，也没有实现数据互联互通，形成多个信息孤岛。

为解决各子系统之间的互联互通问题，传统办法是在众烟囱之上叠加智能化集成系统IBMS。然而，这种基于外部数据库的集成方案，数据既不及时也不完整，数据通道的可靠性、安全性也得不到障，大多只能起到信息集中展示的功用，难以实现稍复杂的系统间联动，难以达到系统整合的目的。同时，由于其开发、维护、管理的难度高，该集成系统往往建成不久即被闲置，各子系统又回复到一盘散沙或烟囱丛林的状态。

需要指出的是，上述这些子系统均没有采用分布式架构和高可用技术，一旦系统服务器故障，这个子系统的服务也就全部中断或丧失。由于没有定义统一的资源命名、数据模型、关系模型，各个子系统之间的数据并没有真正打通，不能实现“如身使臂，如臂使指”的效用。因而难以支撑现代建筑的各类智慧化应用。

具体来说，传统的基于系统集成的智能建筑有如下问题：

①系统未采用分布式架构，无法扩展、升级；

②缺乏全面而完整的数据标准，各系统之间仍然无法有效地交换数据；

③各子系统分别建模，没有统一的建模方法和命名方法，没有命名空间的概念，缺乏对技术、业务、生产、管理、经营五个平面的统一建模；

④各系统数据结构不同，缺乏统一的规划、设计和关系关联定义，导致一些必要的数据维度缺失或无法有效记录与利用；

⑤各系统产生的数据以及人机物之间互动的数据，往往在一次性使用后即被拋弃，缺乏数据沉淀，潜在价值无法被进一步挖掘；

⑥缺少智慧建筑的数据中台，无法进行大数据分析利用，无法在此之上体系化地推进人工智能，推理、判断和决策的综合智慧能力无从谈起；

⑦系统集成项目缺乏可复制性，每个项目分别定制化开发和集成，一次性投入，往往由于赶工而需求分析不够、软件测试不足，系统稳定性差、功能实现率低；

⑧无法交付全生命周期的产品，建成交付即被遗弃，二年维保期过后几成摆设，未实现辅助建筑运维的初衷。

2 基于物联网的奥卡姆剃刀

那么，在当前ICT技术日新月异、信息化正助力各行各业数字化转型的时代大背景下，有没有一套完整的思维方法和工具来协助我们，去实践建筑智能化行业的数字化转型，去进行“科学的顶层设计”呢？答案是肯定的，它正是“物联网”。物联网以信息统一、网络融合、资源共享、应用互通以及终端复用的方式，实现了将相关的信息服务融合在一起。

在GB/T33474-2016《物联网参考体系结构》及GB/T35319-2017《物联网系统接口要求》中，将物联网概念模型规定为六个域，即用户域、目标对象域、感知控制域、服务提供域和运维管控域。其中，感知控制域中的实体又分为传感网系统、智能化设备接口系统、标签识别系统、位置信息系统与音视频系统[1-3]。透过现象看本质，我们在物联网的视角下，重新审视GB 50314归纳的智能建筑常用子系统，并将它们分为物联网网络、运维系统、物联网对象（音视频）、物联网对象（传感网）、物联网服务、物联网环境设施共五种类别（见表1）。

表1 物联网视角下智能建筑常用子系统分类表

其中，归属物联网的网络本身的通信类子系统如表2所示（见表2）。

表2 归属物联网传输网络的通信类子系统

基于上述梳理，我们不难得出采用新一代ICT技术解构与重构后的全新“智能化工程架构规划图”（见图1）。

图1 智能化工程架构规划图

在此图表中，我们依托物联网六域模型给出的所谓工程架构，实际上正是智慧建筑操作系统的雏形，它已综合了智慧建筑操作系统的硬件架构和业务逻辑。将原有众多的子系统解体，消弭其疆界、融合其数据、统一其流程，将整个大系统规范为“云—管—端”的简洁架构，云即云平台、管即物联网网络、端即物联网终端。其革新意义在于采用物联网思维及其工具解构与重构了传统智能化系统，将各系统的硬件与业务逻辑分离、对各系统原本封闭的IT架构进行功能解耦，打造全新的涵盖数据、模型和APP的水平架构层，把通用的东西平台化，把业务功能API化。其结果是用“融合”替代了“集成”，实现整个建筑数据、资源、功能的统一和深度融合，实现数据高可用，并以此作为大数据应用、AI应用的基础。将之与建筑智能化工程类比，我们把这种具备“云—管—端”简洁工程架构、深度融合的一体化系统工程称之为建筑物联网工程，简称建筑物联网。

在物联网视角之下，传统智能化系统的前端现场设备，各传感、控制、显示单元等都属于建筑物联网前端。如果将智慧建筑类比于人体，这些前端就是眼、鼻、耳、手、口、面。它们经由物联网这一张“神经网络”与智慧建筑的“大脑”暨管控营一体化云平台实时连接，共同组成完整的“智慧生命体”（见图2）。它不仅能实现智能化功能，还能依托场景、依据用户身份提供差异化的智慧服务。

图2 建筑智慧生命体示意图

3 物联网智慧云平台的实现

云端服务的物联网云平台由服务器、容器基础设施、物联网中台、智能化中台服务、智能化服务与应用、运营管理应用构成。智能化中台服务对资源模型和资源数据进行统一管理，对各专业设备的实时运行数据进行融合，为上层的智能化服务和应用提供支撑，而智能化服务和应用是为物联网云平台运营管理应用场景提供技术支撑的。

1）云脑基础设施

宜采用基于容器技术搭建统一的私有云服务器集群，具体如下。

①采用不少于两台通用服务器构成物联网平台服务器集群，采用负载均衡技术和高可用技术，通过宽带物联网与部署在各楼层的边缘网关通信，实现对现场机电设备的接入和控制。

②采用不少于两台存储和计算一体化通用服务器构成视频管理服务器集群，同样采用负载均衡技术和高可用技术，通过宽带物联网与部署在各楼层的摄像机和地下空间的停车场车位引导摄像头通信，负责收取各摄像头实时上传的码流数据，并进行解码、存储、推流等操作。

③采用不少于两台带有GPU的通用服务器（数量按路数定）构成视频分析服务器集群，对实时视频数据进行人员行为识别、车牌识别、交通事件和交通参数识别以及人流统计等功能。

④采用两台通用服务器构成应用服务器集群，运行智能化服务、运营管理服务和应用。

⑤采用两台通用服务器构成数据库服务器集群，采用负载均衡技术和高可用技术，实现对各种资源、配置、性能、空间、告警数据的存储、查询、统计等相关处理。

2）容器云基础设施

容器已经在生产环境中被广泛采用，以实现资源的动态分配和弹性伸缩，因此推荐采用开源K8s管理平台Rancher，在生产环境中实现Docker的全栈化容器部署与管理。

3）综合呈现系统

采用LED显示屏及相应的编解码器和控制器，搭建综合呈现系统。配套数据计算、数据分析服务、平台门户服务等，为管控营人员提供大数据的多维呈现。

注意在建筑规模较小、实际接入终端较少的情况下，上述服务器可以进行合并简化、减少初投资，一般建议将物联网平台服务器、应用服务器和数据库服务器合并在同一台物理服务器中。

3.1 软件架构设计

信息系统的本质在于以业务应用为目的，对所获取的信息进行处理和加工。硬件设施是整个系统所有数据生产、传输、处理、存储的载体，而各种数据信息的处理过程则是由软件技术架构来承载的。

3.1.1 设计指导思想

1）“书同文、车同轨、行同伦”

①首要的目标是终结以往孤岛丛生的多系统集成态势，锻造大一统的建筑操作系统。

②解决沟通障碍和信息割裂的前提在于做好底层的数据通信、数据采集、指令下发和数据建模。因此要搭建统一的动态数据建模平台，统一实现各种数据的建模、关系建模、数据结构设计、数据字典以及元数据管理，从而实现“书同文”。

③通过统一的通信协议选择、统一的组网设计、统一的服务器部署、统一的信息安全及权限管理，实现“车同轨”。

④通过统一的算法框架、统一的规则引擎、统一的调度引擎、统一的流程引擎、统一的数据呈现，规约数据的处理和驱动模式，实现“行同伦”。

2）开源与开放性

①采用通用技术或者是与通用技术兼容，避免单一来源的问题。

②保持数据的开放性，也就是一定要使用通用的通信协议。

3.1.2 架构设计

关注整个架构的稳定、持续、健壮和可扩展能力。在软件架构设计中应综合运用现有ICT成熟技术，包括数据建模、多协议适配的物联网平台、算法引擎、规则引擎、调度引擎、负载均衡及高可用、软件容器技术等。在整体技术架构上，我们选择SpringCloud（云计算）框架技术来实现基于容器技术和微服务的云平台架构（见图3）。

图3 软件技术架构图

1）微服务架构

采用传统软件的单体应用模式，而是基于服务和功能组件，将应用拆分为多个小的、互相连接的微服务，微服务之间基于轻量级的REST-API接口方式互联和调用，使各个微服务既有独立完成服务的能力，又能高效地与其他服务基于业务逻辑完成特定业务功能。采用Docker容器云架构较好地整合了分布式系统的系统层面功能，包括服务路由、服务网关、服务发现、链路跟踪等全要素。对于本系统要求的高可用、可扩展、快速部署、快速升级、服务切换等有较好的支持。当外部的系统需要调用微服务中的一些功能的时候，需要通过框架对外暴露的接口——微服务网关Spring Cloud Gateway来访问。

逻辑集中的服务调度管理平台Rancher，对系统各个服务的状态进行监控，快速进行故障切换和服务恢复，具备秒级的服务故障自愈能力。

2）数据库服务与缓存服务

从图3中可以看出，系统采用了redis的内存数据存储、Postgresql进行时序数据、结构化和非结构化数据的统一存储。

3）消息服务

在微服务架构中，服务之间是松耦合，主要采用消息订阅方式发布数据，以达到前后端应用的分离。服务内部通信需要依赖消息总线，系统采用RabbitMQ作为消息服务总线。

4）负载均衡服务

对负载较大的前端WEB服务、数据计算服务、资源服务，系统采用了Spring‐Cloud的Ribbon组件实现负载均衡服务。

5）多协议适配引擎

需采用多协议适配引擎来支持多种协议和规约，如BACNET、MODBUS、CBUS、EIB、ZigBee协议IEC102、104规约等等，能够与各相关厂家的终端设备通信，解析采集到的数据，远程调用相应指令对这些设备进行监控等。

多协议适配引擎内部基于模块化设计，支持动态网络协议解析脚本的加载和适配，可以将封装在以太帧中的异构协议数据正确获取和解析，归一化为标准的数据格式（JSON），以便上位系统能正常处理。反之，系统的联动或控制指令由协议适配引擎翻译为受控对象及设备的协议指令格式，由边缘网关下发到受控对象及设备，以便其正确执行。

6）算法引擎、规则引擎与调度引擎

通过平台的多协议适配引擎打通了与各种终端设备之间的数据通道，从而获取各种实时的运行数据，然后通过算法引擎驱动各种算法框架和算法对这些数据进行相应处理，这些算法形成的结果会被各种规则利用，对这些过程数据进行进一步的处理，然后再通过规则引擎管理各种规则的正常运行。

时间和空间在建筑智能化中有着重要作用，既需要基于不同的时间段（如上班前、上班期间、午休期间、周末、节假日等），也需要基于不同的空间（如大堂、食堂、会议室、独立办公室等）定制智能化场景，然后基于这些场景做功能和数据的联动。调度引擎就是用来定义场景，并串联各种功能和数据的。调度引擎支撑了人与设备、人与空间、人与建筑的互动，展现出智慧平台的人性化与智能化。

3.2 云平台功能模块

3.2.1 物联网中台

物联网中台是智慧建筑操作系统的基座，物联网平台负责虚拟设备对象（数字孪生体或设备影子）的生命周期管理，借助虚拟设备对象实现对实体设备的管控，并为上层平台提供统一的接口。具体功能包括设备注册和认证、同步资源模型和资源数据、虚拟设备对象生命周期管理、虚实对象状态同步等。

3.2.2 智能化中台

智能化中台可分为数据中台和业务中台，数据中台侧重于数据服务，业务中台侧重于业务应用支持。智能化数据中台对资源模型和资源数据进行统一管理，对各专业设备的实时运行数据进行融合，为上层的智能化服务和应用提供支撑；而业务中台的服务又可细分为前端应用服务和后端应用服务。

后端应用服务包括资源服务、数据计算服务、监控告警服务、事件服务等，它们处理感知系统和交互系统产生的各种数据，使其成为标准格式，增加业务的可理解性，以共享的数据服务构成智慧建筑数据中台，向前端各类应用服务提供订阅调用。

上层应用服务需要统一使用的中台支撑，包括API网关服务、数据访问服务、负载均衡服务、消息服务、缓存服务、日志服务、监控服务、数据库服务等。这些前端应用服务是为了让应用系统其他服务得以正常工作、互相访问、提供可维护性而存在的平台级服务。

3.2.3 智能化服务与应用

智慧建筑场景下的应用系统在统一的数据模型、网络架构、技术架构下，基于统一的服务框架构建上层应用的组合，且服务间能通过内部API接口互访。实现灵活适配业主多样化需求、基于场景的跨应用调用与融合，比之前的智能化工程展现出超强的灵活性、可扩展与可实施性。

如图4所示，鉴于当前用户的使用习惯，平台提供的智能化服务主要涵盖了GB 50314中智能建筑常见通用功能服务（子系统），如物业管理应用、一库（卡）通应用、各项信息设施系统服务、各项建筑设备管理服务、各项公共安全管理服务等；以及面向专业场景的服务，如客流统计、资产管理、位置服务、智能家居、智慧医疗、访客管理与车位引导。

图4 物联网应用支撑平台功能架构

3.2.4 运营管理应用

通过采用“云、管、端”的技术架构，实现了对基础设施的一体化接入和管理。接下来可将基础设施的能力进行封装和编排，以“空间、时间、设施、规则”作为关键要素，为上层业务运营管理系统提供可标准化描述，可自动化开通、智能化运行、定义服务水平、实时精确计量和计费的基础设施服务，从而实现“建筑即服务”。

依托建筑智慧平台实现基于数据、事实和理性分析的精细化管理，打通建筑运营过程中涉及的客服接待、运维管理、设备监控、事务响应、计划安排、任务管控、人力资源、大数据分析、商业智能诸多业务领域，可全面提高业主和用户的工作、生活体验，大幅提升物业服务的品质、提升人员的工作效率，节能降耗、提升收益。

4 结语

伴随建筑规模的增大和子系统的增长，传统智能建筑管理难度越来越大、管理成本不断提高，越来越难以适应当代建筑智慧化管理、人性化服务的需要。“BAT”等互联网领军企业跨界试水智慧建筑与智慧园区，取得较好效果；于是智能建筑界纷纷跟风上阵。然而，基于“BAT”自身禀赋与基因的智慧建筑方案往往让地产界难以削足适履。我们有必要透析其方案本质、辩证地”扬与弃”，采用通用技术破解行业难题。为了避免未来对项目的智能化系统进行伤筋动骨的改造，做好技术路线选择，考察案例实效，从项目的全生命周期考虑，采纳当下成本可控、经济实效的智慧建筑操作系统是项目建设方的明智之选。