智慧建筑及其进路之元启篇——智慧建筑原理与实现概论

刘宇辉，周祖寿

（筑博设计股份有限公司智慧建筑研究中心）

1 引言

如果把“智慧建筑”比喻成云遮雾罩的蓬莱仙山，本文旨在论述智慧建筑这座“仙山”可定义（位）、可接近、可攀登。

如果说智慧建筑是具备深度感知、泛在互联、数据共享、全面服务的智慧体，具备认知、学习、推理、预测、自主调控、人机交互等智慧能力。那么，这些外化的智慧能力离不开“深度感知、泛在互联、数据共享、全面服务”等智慧建筑内在禀赋作为基础和必要条件。

本文着墨点在于智慧建筑落地实现这一主要矛盾，以及数据互联互通、数据共享这一矛盾的主要方面，至于智慧建筑的内涵及外延之总总，限于篇幅，不在此探讨。

谈到智慧建筑自然绕不开智能建筑，智能建筑是伴随着人类对建筑安全性、舒适性、便利性和节能性的要求而产生的。依靠建筑智能化提高用户工作效率、提升建筑适用性、降低使用成本，已经成为发展趋势。

智能建筑是一个发展中的概念，随着时代的发展和科技的进步，它的内涵正不断被更新和拓展（见表1）。

表1 前国标阶段的智能建筑定义

原国家标准《智能建筑设计标准》（GB/T50314-2000）对智能建筑的定义为：“以建筑为平台，兼备建筑自动化设备、办公自动化及通信网络系统，集结构、系统、服务、管理及它们之间的最优化组合，向人们提供一个安全、高效、舒适、便利的建筑环境”。

而在修订版《智能建筑设计标准》GB/T50314-2006）中，对智能建筑的定义扩充为“以建筑物为平台，兼备信息设施系统、信息化应用系统、建筑设备管理系统、公共安全系统等，集结构、系统、服务、管理及其优化组合为一体，向人们提供安全、高效、便捷、节能、环保、健康的建筑环境”。

新一代信息技术和通信技术加快融合，云计算、智慧城市、物联网、移动互联、大数据、AI等蓬勃发展，信息通信技术渗透到经济和社会生活各个领域，人类社会正进入到以人工智能为特征的大数据时代，依托物联网、云计算，以大数据和AI为智能建筑赋能，智慧建筑因此应运而生。

在新国标《智能建筑设计标准》GB50314-2015中，我们发现智能建筑的定义已悄然升华：“以建筑物为平台，基于对各类智能化信息的综合应用，集架构、系统、应用、管理及优化组合为一体，具有感知、传输、记忆、推理、判断和决策的综合智慧能力，形成以人、建筑、环境互为协调的整合体，为人们提供安全、高效、便利及可持续发展功能环境的建筑”。可见该定义已融入智慧建筑的理念。

阿里研究院借鉴上述智能建筑定义，不失时机地提出自己对智慧建筑的定义，“智慧建筑是一个具有感知和永远在线的“生命体”，一个拥有大脑的、自进化智慧平台、一个人机物深度融合的开放生态系统”（阿里研究院《智慧建筑白皮书》2017），一时业界反响强烈。大体说来，大众对智慧建筑的认同和关注更侧重于“高级生命体”这一特征，归纳如下：

①具有完备的感知能力；②具有记忆和思维能力，能够利用已有的知识对信息进行分析、计算、比较、判断、联想、决策；③具有学习能力和自适应能力，能够适应环境变化；④具有行为决策能力，即对外界的刺激作出反应，形成决策并传达相应的信息。

技术创新、经济发展、人们对智慧化体验的追求、能源和环境压力，是建筑智能不断进行自我更新升级的核心推动力。笔者认为，智慧建筑是智能建筑演进的高级阶段，其本身同智能建筑一样也是一个发展中的概念，（依据认识论，人类对复杂事物的认知是一个螺旋上升的过程）笔者无意在文中对其给出新的定义，本文探讨的侧重点是智慧建筑的根基。

参照以上定义及解析，我们拿智慧建筑这个度规去衡量当下的智能建筑，不难发现，现实中的智能建筑非但未能体现出智慧，其当前智能系统体系架构的固有问题还有碍于它向智慧建筑平滑演进，具体如下。

1）智能建筑系统大多是由几十个各自独立的子系统（信息系统）拼凑而成，相互之间缺少互通互联，信息孤岛现象严重；

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

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

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

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

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

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

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

9）无法交付全生命周期的产品，建成交付即被遗弃，二年维保期过后几成摆设，未实现通过辅助建筑运维而产生预期效益。

所有的智慧系统都是为了建筑物有效与高效运营而设置的，建筑物的运营需求才是建筑物智慧的动力，建筑的全生命周期管理也应从运营需求作为出发点。

以上种种问题，究其根本，是认识上的错位、指导上的缺失，而导致行动上的迷误。解决之道是不忘初心，回归本源；以系统论的思想重新审视建筑信息系统集成工程；将物联网的理念融入到信息系统集成项目的规划设计当中，实现整个建筑数据、资源、功能的统一和深度融合、实现数据高可用，并以此作为大数据、AI智能应用的基础；以数据治理暨标准化为抓手，实现统一建模、统一数据通道、统一数据处理和存储，实现数据之间的连接和联动。

我们仔细考量“建筑智能化系统”，发现其原本就是一个约定俗成的派生词汇，本身并没有被严格的定义。粗略来讲，就是指被纳入到智能建筑范畴的弱电系统，在工程项目管理上，建筑智能化往往与主体建筑一起被纳入到建筑工程当中，但其与机电系统、装修装饰工程等建筑配套项目存在很大的差异，究其本质应归属信息系统集成范畴，其设计施工都需要由具备信息系统集成资质的单位来完成。

既然是单项信息系统集成工程，我们的交付的成果应该是一个融合的大系统，还是众多孤立的小系统呢？我想结论是不言而喻的。试问智能建筑建设方的初衷是想日后雇佣一群人看护一堆子系统客户端，扩展升级毫无希望、落伍淘汰毫无悬念吗？还是想获得安全、高效、舒适、便利的用户体验呢？建设方原本期望能获得领先业界5a～10a的智慧建筑，不曾想往往项目建成就已落伍；

数据治理的核心思想就是“车同轨，书同文，统一度量衡”，其中蕴藏的智慧不亚于“四大发明”，具体可包括数据标准化、数据一致性和数据标记。

2 数据一致性

各子系统数据一致性的获得离不开物联网技术这颗银弹。物联网是指通过各种信息传感设备，实时采集任何需要监控、连接、互动的物体或过程等各种信息，并通过网络将信息上传至管控中心物联网云平台进行分析处理。通过各类可能的网络接入，实现物与物、物与人的泛在连接，实现对物体和过程的智能化感知、识别和管理。

因此，在物联网所构建的数字世界里，我们首先需要对“物”有一个清晰、统一的定义，用于描述“物”具体能做什么，能够提供什么样的服务和资源。物联网数据一致性的主要目的是为了消除物联网数据属性的不同，解决设备间数据互联互通的问题。

举例来说，在BACnet协议之中，设备模型又可称为对象模型，是楼宇自控设备的模型化和抽象化的描述。对象及其属性提供了对一个楼宇自控设备“网络可见信息”的抽象描述，而对象服务提供了如何访问和操作这些信息的命令和方法。BACnet设备通过在网络中传递服务请求和服务应答报文实现服务。通常，我们采用物联网路由器/hub连接各类异构网络，通过物联网路由器将各类协议数据转换为物联网平台选定的某种统一协议上来（如BACnet、lonworks、TCP/IP等），从而实现设备层语言语义的统一（见表2）。

3 数据标准化

数据标准化简单理解就是数据编码遵循一致的规则，选用一致的数据字典，达到信息沟通传递无障碍的目的。数据结构的标准化，应包括统一数据元定义，统一命名空间（namespace），统一数据字典。

智慧建筑不仅仅是一座孤立的建筑，而且是更大系统“智慧城市”的组成部分，因此选取数据规则的时候要尽可能采用现行最高标准，按照国家标准-地方标准-城市标准-园区或企业标准依次选择，例如现行国标GB/T 29854-2013《社区基础数据元》。

实现了统一数据之后，接着就要对资源对设备统一建模，实现设备虚拟化、实现数据之间的连接和联动。信息集成及软件实现可以形象地比喻历经数字化(虚拟化)、自动化、智能化、智慧化的四个渐进的阶段。

表2 BACnet协议设备（对象）模型示例

建筑要实现智慧化首先是要进行数字化、虚拟化，需要遵照统一的建模体系，通过建模固化建筑内的设备属性，生成静态的虚拟实体。设备属性当中已经隐含了相关设备之间相互识别、相互配合、相互通信的逻辑关系，通过关系描述将建筑内的各设备之间建立起有机关联，从而将众多(虚拟设备)细胞有机地组织起来组成一个有机体。

每个虚拟设备对应于虚拟机中运行的一个线程或协程，运行在分布式网格计算（云计算）服务器上，化为（有生命的）动态的虚拟实体。通过众多的虚拟实体的有机结合生成活的虚拟建筑。

通过能力抽象赋予虚拟设备以功能，暨模仿实体设备的实际功能，该能力不是固化的是可以动态扩展的，结合相关虚拟设备间的通讯能力，构成了初步的组合联动关系，实现了所谓的“自动化”。

在此之上，加入相应的规则（算法）就具备了初步的“智能化”，而真正完整的“智能化”还必须考虑人的因素，智能化建筑需要与建筑物内外的各类人员互动，通过加入流程引擎、规则引擎、调度引擎实现人、事、物、时的统一整合，使得智能化业务实现闭环，实现人与环境，人与空间的交互。

通过软件容器和软件程序来实现各种业务逻辑和功能，通过各种算法和规则实现对各类数据的处理，通过调度引擎实现各种场景的定制，通过流程引擎实现对各种生产流程和管理流程的承载和流转。即通过数据、规则、算法、时间、事件、流程来驱动整个系统的运转，连接所有的人，事，物、时、空间、设备。物联网平台获取大数据经由结合应用场景的AI算法GPU引擎处理，表现为“类人”的推理、判断智慧、人机互动、人与空间的交互的“智慧化”能力。

到此为止，通过物联网云平台实现了建筑的深度感知、泛在互联和统一数据采集，与传统的建筑BMS不同，物联网云平台采集的设备数据具有实时、高并发、多维度的特点，是结合了人、事、物、时的统一多维度的大数据。

从技术上看，大数据与云计算的关系就像一枚硬币的正反面一样密不可分。大数据必然无法用单台的计算机进行处理，必须采用分布式架构。它的特色在于对海量数据进行分布式数据存储、挖掘。它必须依托云计算的分布式处理、分布式数据库和云存储、虚拟化技术。

对于智慧建筑云平台的数据存储，不同的数据源需要采用不同的数据库来管理，对于一次性导入很少变化的数据较为适合关系型数据库，而对于实时变化的数据，适合采用时序数据库进行存储和分析，同时将重要数据导入到大数据平台进行长期存储和持续分析。

对于结合了人、事、物、时的统一多维度的大数据是异构多样化的数据，为了实现数据的融合，需要对各种数据进行必要的数据清洗和处理，实现语义层面的统一，同时规划必要的统一的标识机制，实现在异构数据体内的数据定位和聚合。

平台引入微服务和容器云技术，将建筑智能化不同场景中的各个功能封装成多个相对独立运行的软件容器，以微服务的方式将相应的功能交付给用户使用。将传统方案中硬件实现的功能和业务逻辑，均通过容器以建筑功能虚拟化（BFV）的方式来实现。每个微服务运行在其独立的进程/协程中，服务和服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。通过引入负载均衡和高可用技术，平台实现系统的稳定性和健壮性以及强大的水平扩展能力。

每个微服务都可以独立的部署和投产，其实也就意味着很多的微服务有自己独立的数据库。整个业务数据被分散在各个子服务之后会带来两个最明显的问题：①业务管理系统对数据完整的查询，比如分页查询、多条件查询等，数据被割裂后如何来整合；②如何对数据进一步的分析挖掘。

利用Spring Boot和MongoDB组合可以轻松的解决这个问题，通过技术手段将分裂到N个微服务的数据同步到MongoDB集群中，在同步的过程中进行数据清洗，来满足项目的各项业务需求。使用 Spring Boot 可便利的处理对MongoDB 查询和操作。一方面 Spring Data 技术预生成很多常用方法便于使用，另一方面 Spring Boot 封装了分布式计算的相关函数，可以让我们以较简洁的方式来实现统计查询。MongoDB自带了副本集的概念，通过设计恰当的副本集和驱动程序，可以便利地实现高可用、读写负载均衡。MongoDB 支持Aggregate 和 Mapreduce 利用分而治之的理念来处理大规模数据分析。

究竟是采用公有云还是私有云方案，坊间有一个形象的比喻：是年双11大促销，甲乙二人各自在商城网购了一台机器人。甲得到一个完整的机器人，而乙拆开包裹却发现机器人少了脑袋，打客服电话，客服答复他，“机器人只要启动开关连上网即可使用，没头完全不影响使用功能。按我司管理规定，机器人的头脑统一存放在公司数据中心，我司还提供超级智能及各项增值服务，您只需按月交少许费用就好”。试问甲乙二人谁会更满意些呢？这里还没包括考虑数据资产价值和数据安全的问题。

如图1所示，物联网云平台整体架构分为三层：物联网层、平台服务层、和应用（呈现）层。其中平台服务层还包括基础服务子层、容器与微服务子层、消息总线、数据存储等模块。

图1 典型方案架构示例

物联网层提供现场智能化末端设备接入，物联网层以下都是设备、传感器、数据接口。

基础服务子层提供包括进程监控、事件处理、数据路由、设备模拟等公共基础服务，以及流程、规则、调度、算法、指令解析引擎在内的各类引擎。

容器与微服务子层将各种面向对象的服务（包括以往智能化各功能子系统的业务逻辑）封装在一个个独立运行的软件容器中，以微服务的方式将相应的功能交付给用户使用。容器云架构较好的整合了分布式系统的系统层面功能，包括服务路由、服务网关、服务发现、链路跟踪等，同时容灾热备份技术还提供了负载均衡和高可用性。

数据存储模块包括传统数据库、实时数据库和高速缓存，通过数据持久化接口与微服务对接。

消息总线提供微服务之间通信。微服务之间是松耦合，采用消息订阅方式发布消息来通信，以此达到前后端应用的分离。

应用（呈现）层主要负责用户界面和交互。

该物联网云平台采用现行主流互联网通用技术及通用软件搭建。

我们把建造智慧建筑比作爬山，有没有容易的便道可以走呢？——“有，但是要收费”，即采用现有的软件框架作应用开发。

软件框架是项目软件开发过程中提取特定领域软件的共性部分形成的体系结构，不同领域的软件项目有着不同的框架类型。框架不是现成可用的应用系统，而是一个半成品，是一个提供了诸多服务，供开发人员进行二次开发实现具体功能的应用系统，暨框架是一个可供二次开发的程序实体。主流的框架包括.NET和Java。其中.NET是基于Windows操作系统运行的，而Java具备跨平台的通用性，基于Java开发的Niagara Framework提供了一种底层协议及平台无关性。

Niagara体系结构是一个建立在对象模型上的软件套件，并且被用来设计成用各种即插即用软件组件把不同种类的设备和协议汇集到一个公共的基础设施中，可在此框架上做面向楼宇智能的应用服务开发。限于篇幅所限，详情请读者自行查看山东大学肖进的2011年发表的硕士论文《基于Niagara的建筑智能化系统集成的设计与开发》，该论文中详细阐述了Baja 标准、Niagara Framework“和信息集成系统实现的具体原理，分析了各个系统之间应采取的连接方式、编码情况，对各个系统应实现的集成功能、使用的参数变量、采用的协议类型、接入方式进行了分析，从而给出了这些系统功能集成的逻辑框图、程序设计流程图，使用网络控制器将子系统连接到总系统中，进行软件程序的开发，调试和页面设计，最后连接到中央集成管理服务器，完成集成，并通过联动控制实现了系统的联动。文中详细论述了共28个子系统的集成。

该论文具备当时的技术领先性，暂且按下不表。该论文的局限性在于：①受限于当时流行的BMS集成方式，采用事后集成，即在所有子系统已建成基础上进行上位集成，而没有将这个项目作为一个整体来做归一化开发和优化；②受当时技术发展限制，没有引入分布式、云计算、高可用、大数据分析等相关新技术。

此外，Baja 标准、Niagara Framework虽然开放性比较好、成熟案例比较多，终究是美国产品。一是要顾虑其持续供货许可（贸易战）和信息安全后门（对于政务项目），二是要付出一定的采购成本。因此，本文呼吁国内的软件公司尽快推广国产优秀的物联网中间件平台。

智慧建筑究竟离我们有多远？我们的观点是非常近，“放弃智能化，立得智慧化”。放弃以往几十个孤立子系统+外部数据库集成的架构，采用本文阐述的架构体系，即已具备了智慧建筑的坚实基础和平滑演进的能力，可以说与普通的智能建筑存在代际差异。智能化的架构模式陈陈相因，存在认识错位、指导缺失、设计实施将错就错，其包括数据孤岛在内的内部固有问题不是能通过外部堆叠一些模块、功能、亮点所能弥补的。必须革旧鼎新，否则就是对项目的不负责任，将来必付出改造的学费。

智慧建筑究竟有多昂贵？我们的调研是并没有想像的昂贵，虽然前期会有一些“新技术溢价”，初始投资会增加7%～15%，但站在项目全生命周期成本、项目综合收益视角上考虑，相信精明的业主都不难作出正确的选择。甚至目前已有解决方案商通过全面自主研发、深度优化，项目整体造价上能与普通的智能化方案持平。

智慧建筑究竟有多可靠？国际上依照物联网云平台构建的准智慧建筑近似的项目案例数以万计。通过在物联网云平台引入KeepAlive和ZooKeeper高可用技术，搭建服务器池池化计算资源，实现云端（私有云）的负载均衡和高可用性，从而消除单点故障、保障系统不间断持续运行。信息安全方面按照国家信息安全等级保护的各项要求严格落实，统一考虑数据安全、网络安全、系统安全、应用安全，统一组织、角色、用户定义，统一权限定义和认证，统一加密算法，统一支付通道。

4 结语

我们认为，传统的建筑智能化系统存在着“陈陈相因，各自为政、以邻为壑、抱残守缺、敝帚自珍”等问题，将近二三十个子系统采取烟囱式的架构模式，从终端到通信网络到后台服务器及存储都各自独立，这种架构必然导致建设成本偏高，系统架构单薄，处理能力薄弱等一系列问题。无法带给用户真正的价值，与智慧建筑背道而驰。

笔者倡导将物联网的理念融入到智慧/智能建筑规划设计当中，实现整个建筑数据、资源、功能的统一和深度融合、实现数据高可用，并以此作为大数据、AI智能应用的基础。采用“书同文、车同轨”的模式重构一个具备多种感知能力、信息交互能力、学习和进化能力的智慧建筑。

写作此文的目的是为建设方出谋划策；为同道拨开云雾、排除杂音、树立路标；呼吁业界的研发方向，整合优势资源，研究、替代、超越，为建设方提供高性价比的解决方案；给行业协会、主管部门乃至部委建言献策，希望上级管理部门给出指导意见、调整指导文件，促使我国智能智慧楼宇的建设水平更上层楼，实现集约高效可持续。

智能建筑发展近40年，一直像是在搭积木，为某项功能新增某个子系统，多年发展下来子系统近40个而互不贯通；所沿用的标准、架构、协议进化缓慢，较之其他领域已日显陈旧； 面对一堆互不贯通子系统，管理难度越来越大、管理成本不断提高；越来越难以适应智慧化管理、人性化服务的需求。而传统基于OPC、ODBC的数据采集及外部数据库集成美其名曰BMS或IBMS ，大多仅是起到数据展示的作用，无法实现数据面，功能面真正融合，更不可能达到资源、功能、网络、界面的融合； 工程商往往满足于来拿主义、东拼西凑，缺乏系统性调研，没有针对甲方的业务痛点、管理难点、运维糟点提供精准有效的解决方案；更有甚者工程与厂商沆瀣一气、多卖产品，硬件配置虚高、过度设置网关已成为业界通病。

智能(智慧)建筑设计师应该站在业主角度，换位思考，提供高性价比、高可用的智能信息一体化解决方案。应照顾到业主的长远利益，以终为始交付全生命周期的产品，而不仅仅是完成项目，套用现成的方案。 我们认为在技术路线选择上优先选取物联网云平台作为基础架构，以达到整个智能化系统数据、资源、功能的统一和深度融合、实现各子系统数据的高可用。 最终实现人、设备、环境、数据真正意义的互联互通，打破各个子系统间的藩篱，将建筑智能化系统搭建成一体化的生命有机体，实现场景可定制，实现有价值的数据消费。并达到提升系统健壮性，水平扩展能力和快速升级能力，减少建设期间投入，降低运维期间成本的根本目标。

上述生命有机体基于开放式分布式架构，既能横向扩展又能持续演进，从而即为建设方信息化智能化资产实现保值的同时，又能确保项目智能化水平持续领先，同时在节能降耗、易化管理、降本增效、提升体验方面为业主持续创造价值。