CN113238489A

CN113238489A - 智慧建筑控制方法、装置及系统

Info

Publication number: CN113238489A
Application number: CN202110373787.6A
Authority: CN
Inventors: 王建勋; 鲁国良; 汪涛
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2016-11-23
Filing date: 2016-11-23
Publication date: 2021-08-10
Anticipated expiration: 2036-11-23
Also published as: CN108089450A; CN108089450B; CN113238489B

Abstract

本申请实施例公开了智慧建筑控制方法、装置及系统，其中，所述系统包括：位于建筑物内部的至少一个网关中间件，用于控制所述建筑物内部多个不同设备类别的底层基础设备的接入，并对同一设备类别内不同底层基础设备的数据表达方式进行统一化处理；以及，位于云端的控制服务器，用于提供应用程序编程接口API，接收上层应用程序对所述API的调用请求，并通过所述网关中间件下发到对应的底层基础设备，以便对所述底层基础设备进行操作。通过本申请实施例，能够使得整个建筑形成一个有机的、不断进化的、开放生命体。

Description

智慧建筑控制方法、装置及系统

本分案申请是基于申请号为201611051522X，申请日为2016年11月23日，发明名称为“智慧建筑控制方法、装置及系统”的中国发明专利申请的分案申请。

技术领域

本申请涉及智慧建筑控制技术领域，特别是涉及智慧建筑控制方法、装置及系统。

背景技术

从实现技术而言，智慧建筑(IB)系统就是将先进的传感器技术、通讯技术、网络技术、自动控制技术、计算机技术以及数据处理技术等有机地运用于建筑的运行和管理过程，而建立的一种实时、准确、高效的综合控制和管理系统，其目标就是增强建筑的效能(performance)和提高建筑的产出(productivity)。

当前的智慧建筑管理系统虽然将建筑自动化系统(BAS，Building AutomationSystem)、消防系统(FAS，Fire Alarm System)、安防系统等各子系统进行集中管理。但是，每个子系统都是在同一设备类别的垂直领域内进行控制，实质上增加了各个子系统设备基本数据在横向互联互通的难度，客观上造成了“信息孤岛”的现象，难以实现真正的智能化，而且后期系统维护成本很高。另外，系统方案不具有可复制性，需要在每个项目分别定制集成。

发明内容

本申请提供了智慧建筑控制方法、装置及系统，能够使得整个建筑形成一个有机的、不断进化的、开放生命体。

本申请提供了如下方案：

一种智慧建筑控制系统，包括：

位于建筑物内部的至少一个网关中间件，用于控制所述建筑物内部多个不同设备类别的底层基础设备的接入，并对同一设备类别内不同底层基础设备的数据表达方式进行统一化处理；

位于云端的控制服务器，用于提供应用程序编程接口API，接收上层应用程序对所述API的调用请求，并通过所述网关中间件下发到对应的底层基础设备，以便对所述底层基础设备进行操作。

一种智慧建筑控制方法，包括：

位于云端的控制服务器提供应用程序编程接口API；

根据上层应用程序对所述API的调用请求，确定目标智慧建筑以及其中部署的目标网关中间件；

向所述目标网关中间件发送所述调用请求，以使所述目标网关中间件对所述调用请求中携带数据的数据表达方式进行数据转换，并向所述底层基础设备发送数据转换后的调用请求；其中，所述调用请求携带数据的数据表达方式，在所述底层基础设备对应设备类别的范围内统一；所述数据转换后的调用请求携带数据的数据表达方式，符合所述底层基础设备对应的厂商定义。

一种智慧建筑控制方法，应用于位于建筑物内部的网关中间件，包括：

接收云端的控制服务器发送的调用请求；所述调用请求由上层应用程序发出；

根据所述调用请求确定目标底层基础设备；

对所述调用请求中携带数据的数据表达方式进行数据转换；其中，所述调用请求携带数据的数据表达方式，在所述目标底层基础设备对应设备类别的范围内统一；数据转换后的调用请求携带数据的数据表达方式，符合所述目标底层基础设备对应的厂商定义；

向所述目标底层基础设备发送数据转换后的调用请求，以便对所述目标底层基础设备进行操作。

一种智慧建筑控制装置，应用于位于云端的控制服务器，包括：

API提供单元，用于提供应用程序编程接口API；

网关中间件确定单元，用于根据上层应用程序对所述API的调用请求，确定目标智慧建筑以及其中部署的目标网关中间件；

调用请求下发单元，用于向所述目标网关中间件发送所述调用请求，以使所述目标网关中间件对所述调用请求中携带数据的数据表达方式进行数据转换，并向所述底层基础设备发送数据转换后的调用请求；其中，所述调用请求携带数据的数据表达方式，在所述底层基础设备对应设备类别的范围内统一；所述数据转换后的调用请求携带数据的数据表达方式，符合所述底层基础设备对应的厂商定义。

一种智慧建筑控制装置，应用于位于建筑物内部的网关中间件，包括：

调用请求接收单元，用于接收云端的控制服务器发送的API调用请求；所述API调用请求由上层应用程序发出；

底层基础设备确定单元，用于根据所述调用请求确定目标底层基础设备；

数据转换单元，用于对所述调用请求中携带数据的数据表达方式进行数据转换；其中，所述调用请求携带数据的数据表达方式，在所述目标底层基础设备对应设备类别的范围内统一；数据转换后的调用请求携带数据的数据表达方式，符合所述目标底层基础设备对应的厂商定义；

调用请求发送单元，用于向所述目标底层基础设备发送数据转换后的调用请求，以便对所述目标底层基础设备进行操作。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，传感器作为建筑的感觉器官，可以搜集建筑内的各类基础数据(环境、人、设施设备)，经过建筑的网关设备到达云端的控制服务器，云端的控制服务器则开放出各类API接口，供开发者开发使用这些基础数据，以提供更好的服务给建筑的使用者和业主。通过这种平台化的开放标准，使得上层应用程序可以综合使用各个设备类别的基础设备产生的数据，也可以对各个设备类别设备进行联动性的控制，因此，可以避免“信息孤岛”的形成，实现感知用户，感知自身，感知周边。同时依靠自身的生态体系，可以吸引第三方机构/个人进入到建筑中来，对建筑、人、设备提供无穷无尽、不断进化的服务，从而不断满足建筑中人的多样化、个性化的需求，使整个建筑形成一个有机的、不断进化的、开放生命体。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的系统的示意图；

图2是本申请实施例提供的第一方法的流程图；

图3是本申请实施例提供的第二方法的流程图；

图4是本申请实施例提供的第三方法的流程图；

图5是本申请实施例提供的第一装置的示意图；

图6是本申请实施例提供的第二装置的示意图；

图7是本申请实施例提供的第三装置的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

实施例一

在本申请实施例一中，为了解决现有技术中的信息孤岛问题，提供了一种智慧建筑控制系统，该系统可以对建筑内部的底层基础设备(包括空调、灯具等等)进行数据采集，或者发送控制指令，并且，还可以为上层应用服务提供API(应用程序编程接口)，使得上层应用服务可以通过API调用的方式来获得底层基础设备的数据，或者，向底层基础设备发送控制指令。为了达到上述目的，具体的，参见图1，该系统可以包括：

位于建筑物内部的至少一个网关中间件101，用于控制所述建筑物内部多个不同设备类别的底层基础设备的接入，并对同一设备类别内不同底层基础设备的数据进行统一化处理；

以及

位于云端的控制服务器102，用于提供应用程序编程接口API，接收上层应用程序对所述API的调用请求，并通过所述网关中间件下发到对应的底层基础设备，以便对所述底层基础设备进行操作。

具体实现时，建筑物内的底层基础设备可以包括两大类，一类是传感器类设备，包括温度传感器、湿度传感器、光敏传感器、人脸识别设备、车牌识别设备，等等；另一类是执行类的设备，包括空调、照明设备、门禁设备，等等。其中，传感器类设备主要用于采集建筑物内部的环境数据，并且可以提交到云端的控制服务器。执行类设备在实现自身功能的过程中，还可以将自身产生的数据提交到云端的控制服务器，或者在云端的控制服务器的控制下，执行具体的指令。

在实际应用中，为了能够通过云平台对底层设备数据进行不断的采样和持续的优化控制，达到最有效的利用能源，减少运营和维护成本等目的，还可以对底层基础设备的布局等进行规范，也即，可以按照具体的规范标准对建筑物内的底层基础设备进行部署。具体可以包括室内照明设计规则、电力分项计量设计标准、环境综合传感器数据采集点的选择原则和空间布置规则、变风量空调系统及风机盘管+新风系统设计导则、无线WIFI(无线保真，Wireless Fidelity)设计导则、智慧建筑对机电设备数据接入的要求规范，等等。具体的规则或者规范内容可以根据实际需要进行指定，这里不进行详述。

上层应用程序可以包括云平台开发的原生应用，另外，还可以包括一些第三方开发者开发的第三方应用，具体的上层应用程序可以具体自动化灯控、访问识别、工位分时租赁、预约车位，等等。

本申请实施例在底层基础设备与上层应用程序之间增加了两层，其中一层是网关层，另一层是云端的控制层。其中，关于网关层，可以在建筑物内部署一个或多个网关设备(具体的网关设备数量可以根据建筑物内的底层基础设备数量等来确定)，并在这种网关设备中安装预置的网关中间件，建筑物内的各种底层基础设备可以接入到该网关中，底层基础设备产生的数据可以通过网关中间件上传给云端的控制服务器，控制服务器产生的控制指令也可以通过这种网关中间件下发给底层基础设备。

具体的，网关中间件的作用可以包括：对同一设备类别(通常也可以称为行业，例如，照明设备类别也称为照明设备行业，空调设备类别也称为新风行业，等等)内不同底层基础设备的数据进行统一化处理。这是因为，关于各类底层基础设备，还可以从设备类别角度划分为不同的设备类别设备，包括照明设备类别的设备、新风设备类别的设备，等等。并且，在同一建筑物内，对于同一设备类别的设备，也可能存在不同厂商、不同类型等差异，而不同厂商不同类型的设备，即使属于同一设备类别，也可能在数据表达等方面存在差异。例如，同样是照明设备，不同厂商对亮度值范围可能具有不同的定义，其中，厂商A定义为0～100，厂商B定义为0～10，等等。因此，为了便于进行统一的控制，可以由网关中间件对同一设备类别内不同厂商不同类型的设备的数据进行统一化处理，使得上层应用程序可以通过统一的指令对同一设备类别内的设备进行控制。例如，可以将各个照明设备厂商对亮度值的范围统一表示为0～100；并且，在网关中间件中，可以保存不同厂商原有定义的数据表达方式，在收到上层应用程序下发的控制指令的情况下，还可以首先由网关中间件进行数据转换，然后，再下发给具体的底层基础设备。例如，某底层基础设备原有定义的亮度值的范围为0～10，收到的控制指令中，是将该底层基础设备的亮度调节为“80”，则可以首先进行换算，在具体向该底层基础设备发送调节指令时，可以将调节的目标亮度值换算为“8”，等等。

在具体实现中，网关中间件还可以将各厂商定义的数值范围，以及统一后的数值范围之间的对应关系进行保存，以便在具体的查询或者控制过程中进行换算。例如，对于前述照明设备的例子，具体可以如以下表1所示：

表1

除了照明设备之外，关于温度控制设备的温度调节范围、湿度控制设备的湿度调节范围、网络设备的信号强度范围，等等，都可以按照上述方式，对不同厂商之间的差异进行统一化处理，并保存相应的对应关系。例如，关于温度控制设备，保存的对应关系可以如以下表2所示：

表2

关于湿度控制设备，保存的对应关系可以如以下表3所示：

表3

另外，网关中间件还可以具有权限管理、数据缓存、本地服务数据处理等功能。例如，关于数据缓存功能，可以是将采集到的底层基础设备的数据在网关本地进行缓存，这样，在上层应用程序需要查询某数据的情况下，可以直接根据缓存的数据提供响应，等等。这里不再一一描述。

关于云端的控制服务器，属于云平台中核心的部分，可以称为整个智慧建筑的“大脑”，并且，由于控制服务器位于云端，因此，也可以称为“云大脑”，该“云大脑”可以对多个不同的智慧建筑中的底层基础设备进行控制。并且，在本申请实施例中，该云端的控制服务器的作用可以包括：为上层应用程序提供API(应用程序编程接口，ApplicationProgramming Interface)，这样，上层应用程序可以通过这种API进行构建，进而，在应用程序运行过程中，就可以通过调用API的方式，向云端的控制服务器发送相应的调用请求，这样，云端的控制服务器就可以通过所述网关中间件下发到对应的底层基础设备，以获取对应底层基础设备的相关数据或者向所述对应底层基础设备下发控制指令。

具体实现时，关于API的提供，在一种实现方式下，可以是提供普通的API，此种情况下，应用程序在调用API的情况下，可以指定被控对象的名称、类型，等等。但是，这种方式的缺点在于，应用程序的开发人员需要对具体底层基础设备的名称、类型、功能点都具有相应的了解，这就提高了对开发人员的知识门槛。例如，对于上述普通的API调用，通常需要通过多个参数来唯一定位一个具体的设备，例如(device ID,device type，state/actionname)，等。其中，具体的device ID，device type，state/action name都需要由开发人员在程序中进行指定。

为了降低开发人员的知识门槛，使得对底层基础设备的名称、类型、功能点等知识没有足够了解的技术人员，也能够进行应用程序的开发工作，在本申请实施例中，还可以在协议层面上进行相应的改进，具体而言，可以提供用于对各设备类别的底层基础设备产生的数据进行统一化描述的元数据，其中，所谓的元数据，又可以称为中介数据、中继数据，为描述数据的数据(data about data)，在本申请实施例中，元数据就是用于对智慧建筑系统中的各项数据进行描述的数据，例如，某个具体的底层基础设备就可以对应一个唯一的元数据。这样，通过这种元数据，上层应用程序就可以以所述元数据为参数对所述API进行调用，而不需要设定多个参数值。

为了实现用元数据的方式进行数据标识，在本申请实施例中，可以在开放楼宇信息交换oBIX(开放式楼宇信息交换，Open Building Information eXchange)规范下实现Haystack的三类实体，所述三类实体包括地理位置实体、设备实体、设备功能点位实体。

为了便于理解，下面首先对智慧建筑云平台中涉及到的软件层面的相关知识以及oBIX规范、Haystack标签进行简单的介绍。

为了构建完整智慧建筑系统，现有技术中产生了BACnet标准，由此智慧建筑自控网络由专有型向开放型转变。在开放标准基础上，各种智慧建筑子系统的信息可以共享，因而理论上可以构建完整的集成智慧建筑系统。但事实上，由于不同标准之间存在差异，即使是公认的BACnet标准，也很难实现不同标准间的无缝集成。因此，如果制定一个公共的集成接口，并且所有的自控网络标准均支持这个公共集成接口，则可以通过这个公共集成接口高效地进行集成。

随着企业应用(如人力资源，客户关系，财务管理等)集成的需求，越来越多地要求智慧建筑系统接入到企业管理信息系统(MIS，Management Information System)之中，以便全面分析企业的所有运行信息和进行决策。另外，随着更大数量的“机器-机器(M2M)”通信服务的快速发展，也需要发展出一种与“平台无关，语言无关和协议无关”的系统集成技术。在Internet发展过程中，XML/Web Services技术凭借其“平台无关，语言无关和协议无关”的特点逐渐成为企业应用集成的焦点。这种技术以其开放性、标准性和简便性在IT(信息技术，Information Technology)业界得到了广泛应用，并正向智慧建筑自控领域及其系统集成应用高速渗透。利用XML/Web Services技术进行智慧建筑自控系统集成正是这种发展趋势的具体表现，代表着智慧建筑自控系统集成技术的发展方向。

正是由于XML/Web Services技术的优点，一些标准组织和设备类别学会已经将已有的智慧建筑自控网络标准进行XML/Web Services技术扩展，或制订新的XML/WebServices技术应用标准。其中，CABA(北美大陆楼宇自动化)协会发起和制订了基于XML/WebServices技术的——开放楼宇信息交换标准oBIX。

oBIX标准就是多学科交叉和融合的智慧建筑系统集成技术，具有明确的运行管理功能和综合的特征，其作用是屏蔽不同楼宇自控网络标准的差异，提供统一和开放的智慧建筑系统集成技术，其意义在于将智慧建筑系统作为企业应用集成的一个子系统，无缝地集成到企业管理信息系统之中，从而使智慧建筑系统具有更广阔的应用。

从智慧建筑系统集成技术的发展过程可以看出，oBIX标准是基于现代IT技术的智慧建筑系统集成技术标准。正如其他系统集成技术一样，oBIX标准利用XML/Web Services技术的数据描述功能和互操作机制等核心内容定义智慧建筑系统的信息模型(Information Model)、互操作方式(Interoperation Mode)和互操作语义的网络传输(Network Transport)等内容，由此形成了其基本体系和对应的基本内容。在oBIX标准中，信息模型是以对象(object)和合同(contract)为基础的对象模型，互操作方式是建立在对象模型之上以Read(读)、Write(写)和Invoke(调用)为基础的REST(Representation StateTransfer)互操作方式。

在oBIX标准中，对象(object)是与“应用领域无关”的低层次XML词汇或命名空间，是oBIX XML文档的组成元素项(element)。该对象模型除了用于描述智慧建筑系统信息以外，还可以用于其他自控领域的信息描述。所有oBIX XML文档均可以由该对象模型所规定的XML词汇或命名空间所构成。另外，由于oBIX标准均由oBIX对象所组成，因此，为了标识不同类型的oBIX对象，oBIX标准采用了URI(Uniform Resource Identifier，统一资源标识符)标识方式。

合同(Contract)是由oBIX对象按oBIX标准规定的语法所构成的XML文档，是与应用相关的语义“对象”模型。也就是说，合同是用对象模型描述具有互操作语义的XML文档，或是具有一定互操作语义的oBIX对象，其作用是使智慧建筑系统的基本单元描述标准化，从而使实现或引用合同的用户均可以知道该合同所描述的互操作语义，这就使合同成为与应用相关的互操作语义实体，即合同是建立在低层次对象模型之上的、具有互操作语义的高层次oBIX对象。例如，名称为oBIX:Alarm的合同就是oBIX标准中与报警相关信息的标准描述单元，该合同用oBIX对象模型描述了报警源、报警时间、报警接收者等信息，使实现和引用该合同的用户均可以按照该合同的标准结构及其所蕴含的互操作语义使用和解读该合同，从而实现系统的集成和互操作。

从合同的作用可以看出，合同是较高层次语义的oBIX描述标准单元。合同与对象模型间的关系犹如面向对象计算机编程语言(如C++，Java等)的基本数据类型与对象类型之间的关系，虽然编程语言中的基本数据类型是有限的和固定的，但利用基本数据类型创建的对象类型并不是由编程语言硬性规定的，只要按照编程语言的语法规则就可以用基本数据类型创建任意与应用相关的对象类型，并且所有满足编程语法规则的对象类型均可以由同一编译器(compiler)进行识别和编译。oBIX标准的对象模型和合同也采用这种思想，虽然oBIX对象模型定义了有限的基本对象类型，但在oBIX标准规定的XML语法约束下可以用有限的基本对象类型和合同对象类型构造与应用相关的任意类型的合同，从而使oBIX标准在描述功能上具有强大的扩展机制。

利用上述思想，任何人都可以根据应用需求构造任意类型的合同。为了使常用的合同类型标准化，oBIX标准经过抽象总结，将常用的合同类型定义为“标准类型合同”，例如，oBIX:Point,oBIX:Alarm和oBIX:History等均为标准合同对象。在oBIX标准中，由oBIX标准定义的标准合同也可以简称为“合同”，而由用户或楼宇自控设备厂家根据应用自己定义的合同通常称为“扩展合同”。

在互操作方式上，oBIX标准采用了“客户/服务器(C/S，Client-Server)”模型，并将所有互操作过程归纳为Read(读)、Write(写)和Invoke(调用)三种操作过程。其中，Read用于客户读取服务器的oBIX信息，Write用于客户向服务器写入oBIX信息，Invoke用于客户调用服务器的操作过程。这种互操作方式在Web网络环境中通常称为REST(REpresentational State Transfer)方式。REST方式是上述资源访问方式的总称，是一种面向网络资源访问的设计方式，凡是符合这种访问方式的资源操作均可以称为REST方式。

通过以上介绍可见，现有技术中的oBIX标准具有扩展性强的特点，但是，本申请发明人在实现本申请实施例的过程中发现，oBIX的缺点在于：缺乏确定的服务API，在对数据进行查询、设置等操作时，显得不够灵活。换言之，oBIX标准更适合作为工业应用中的规范，但是，在智慧建筑系统直接应用该oBIX标准的情况下，则会显得不够灵活，难以在该规范基础上提供具体的API。

为此，在本申请实施例中，可以结合oBIX标准的扩展性强的特点，在原有的oBIX标准基础上进行扩展，使得扩展后的标准在原有优点的基础上，兼具数据简洁、轻便等特点，进而便于实现具体的API，为上层应用程序的集成提供更便利的条件。具体的，本申请发明人想到了HayStack标签，因为其在数据简洁、轻便、设备类别标签成熟的优势。其中，HayStack将服务对象抽象为site(地理/建筑位置)、equip(设备实体)、point(功能点位)三类实体，并允许在其间建立关联关系，数据格式简洁明朗。因此，在本申请实施例中，就可以将oBIX标准与HayStack标签相结合，在oBIX规范下实现Haystack的上述三类实体结构，也就是说，将HayStack的设备类别标签作为扩展服务数据，并在oBIX规范下具体落实site/equip/point这三层数据实体。

具体的，各层数据实体可以分别通过以下方式进行扩展：

(1)关于HayStack中的Site标签，可以在oBIX扩展出Location类，该oBIXLocation可以是所有地理位置对象的顶层父类，遵循HayStack的site标签，另外，还包括一个指向下层的sublocation，一个指向上层的upperLocation，一个指向该Location上关联的服务实体entityCollect，等等。也就是说，通过将Location类进行实例化，可以用于表示一个地理位置对象，例如，具体某座大厦、某层、某个区域，等等。

(2)关于HayStack的Equip标签，在oBIX中可以实现commEntity类，该oBIXcommEntity类可以是所有设备对象的公共父类。也就是说，通过实例化该类，可以用于表示一个具体的底层基础设备，例如，某部空调，某个照明设备，等等。具体实现时，对于commEntity类，可以针对不同的设备类别，生成不同的设备类别模板，具体在表达某个底层基础设备时，可以通过继承对应设备类别的模板来进行描述。

(3)关于HayStack的Point标签。在oBIX中可以扩展出commPoint类，该类可以是对设备功能点位的顶层抽象，所有Point模板都可以继承它，而Point实例则继承对应模板，它的主要成员可以是一个指向其上层设备的引用，表示任何一个点位都从属于特定的设备。例如，对于“空调”设备类别，其设备功能点位可以有：“power”、“speed”、“highspeed”、“minspeed”、“lowspeed”、“model”、“temp”、“value”等8个功能点位，则可以分别为各个功能点位设定对应的模板。不同设备类别的设备具有不同的功能点位，因此，也可以分别为各个设备类别设备各自对应的各个功能点位生成对应的模板。具体实现时，还可以定义设备元数据之间的依赖关系。例如，某设备信息模板为新风行业模板AirCondition，其is字段:“h:equip h:hvac obix/def/contract/commEquip”，说明该模板除了继承obix的commEquip模板，并且还遵循HayStack标签库的equip标签和hvac标签，这保证了该设备实例满足HayStack的数据规范。

通过上述方式，就可以将系统中的数据用元数据的方式来进行表示，并且，由于符合oBIX规范，因此，每一类数据对象都可以用URI的方式来进行标识。

例如，对于某地理位置对象“一号楼二楼西侧区域”，可以用标识为：“href”：“http：//beehive/obix/def/contract/location/01/02/W”，同时，还可以通过“is”字段来说明该对象具体符合的规范，以及带有的HayStack标签。例如，“is”：“h：site obix/def/contract/location”，通过该“is”字段可知，该对象继承了oBIX location类，并且遵循HayStack标签库的site标签。

又如，对于某名称为“th_001_XYZ”的具体底层基础设备，其URI标识可以为：“http：//…obix/things/th_001_XYZ”，同样，还可以通过“is”字段来说明该对象具体符合的规范，以及带有的HayStack标签。例如，“is”：obix/def/schema/aircondition obix/def/contract/siteRef h:equip h:hvac，通过该“is”字段可知，该对象继承了oBIX的aircondition设备类别模板，以及siteRef模板，并且遵循HayStack标签库的equip标签以及hvac标签。另外，该设备有8个功能点位对象(Power、Speed、HighSpeed、MinSpeed、LowSpeed、Model、Temp、Value)。

通过上述方式，在云端的控制服务器，可以对具体智慧建筑内部的各个地理位置对象、基础设备、设备上的功能点位，分别按照上述方式进行实例化，也就是说，智慧建筑内的每个地理位置、每个基础设备、每个具体的功能点位，都可以对应各自的URI。这样，如果上层应用程序需要获取某个具体对象的数据，或者对某个具体对象进行控制，就可以以该对象的URI为参数调用相关的API。

具体的API可以有多种，例如，可以包括GET、PUT、POST等等，并且，可以在云端的控制服务器中定义各个API的内部实现，也即，当具体的API被调用时具体的处理流程。例如，对于空调设备th_001_XYZ，如果某上层应用程序需要获取其温度数据，则可以通过以下语句来实现：

GET http://beehive/obix/things/th_001_XYZ/temp

云端的控制服务器在接收到该调用请求后，可以根据请求中的URI进行查询，通过该对象的“is”字段，可以确定出该对象继承了oBIX的aircondition设备类别模板，以及siteRef模板，并且遵循HayStack标签库的equip标签以及hvac标签，这样就可以识别出具体是新风设备类别的一种空调设备，然后就可以根据API中定义的具体处理流程，对该请求进行相应的处理，向对应的网关中间件发送获取该设备温度数据的指令，在网关中间件上传具体的温度数据后，再将该温度数据提供给具体的上层应用程序。

又如，如果某上层应用程序需要设置空调设备th_001_XYZ的温度为38度，则可以通过以下语句来实现：

PUT http://beehive/obix/things/th_001_XYZ/temp

{

“val”:99

}

需要说明的是，关于上述查询某设备某功能点位的数据，或者对某设备某功能点位的数据进行设置的过程通常是在上层应用程序的运行过程中进行，也就是说，在上层应用程序的代码中已经写明具体的API调用语句，并在语句的参数值写明具体操作对象的URI。

另外，通过增加了HayStack的h:前缀标签，使得平台使用者不仅能通过oBIXLocation位置一级一级地查询到设备，还可以通过HayStack的标签特性综合查询所有带有该标签的设备，比如，查询位于一号楼二楼(siteRef:0102)的所有灯光传感器(haystack标签为lights)设备：

POST http://beehive/obix/compoundQuery

{“tag”:h:“lights”,siteRef:“0102”}

云端的控制服务器在收到该请求后，可以将位于一号楼二楼的所有灯光传感器设备的列表返回：

[{“obix”:“obj”,“name”:“th_001_ABC”,href＝“obix/things/th_001_ABC”...}]

再者，通过HayStack的h:前缀标签，使得平台使用者还可以通过HayStack的标签特性综合查询某设备所具有的所有功能点位，例如：

GET http://beehive/obix/things/th_001_XYZ/

云端的控制服务器在收到该请求后，可以将该设备关联的所有功能点位标识的列表返回：

[http://beehive/obix/things/th_001_XYZ/Power，http://beehive/obix/things/th_001_XYZ/Speed，http://beehive/obix/things/th_001_XYZ/HighSpeed，http://beehive/obix/things/th_001_XYZ/MinSpeed，http://beehive/obix/things/th_001_XYZ/LowSpeed，http://beehive/obix/things/th_001_XYZ/Model，http://beehive/obix/things/th_001_XYZ/Temp，http://beehive/obix/things/th_001_XYZ/Value]

需要说明的是，在具体实现中，对于基于标签特性的综合查询，通常是在开发应用程序的过程中有所涉及，例如，本申请实施例可以为应用程序的开发方提供开发平台，通过这种开发平台，开发人员可以通过输入这种查询语句，来查询某个位置下具体某设备类别的设备都有哪些，或者，查询某个设备具体有哪些功能点位等，进而再根据查询结果，编写具体的数据查询或者控制语句，等等。

通过以上所述可见，通过在oBIX规范中结合HayStack的标签属性(Site位置、Equip设备类型、Point功能点位)，可以更灵活地查询并控制具体的操作对象，仅借助一个操作对象URI作为元数据，就可以得到所有需要的信息，或者实现对操作对象的控制。由此，无论是平台原生的应用程序，还是第三方开发者开发的应用程序，都可以通过API调用的方式来实现具体的应用程序，而不需要理解具体设备的设备类别、类型、功能属性等信息。

另外，通过这种方式，也可以更好的实现不同设备类别的设备之间的联动。具体的，上次应用程序在运行过程中提交的调用请求可以包括对不同设备类别中多个底层基础设备进行操作的调用请求，此种情况下，云端的控制服务器可以通过所述网关中间件将所述调用请求下发到对应的底层基础设备，以获取对应底层基础设备的相关数据、或者向对应底层基础设备分别下发控制指令。对于上层应用程序而言，可以分别实现对各个底层基础设备进行操作的语句，通过这种语句设定具体的联动规则，例如，在某区域的照明设备的亮度达到某第一数值的情况下，将该区域的空调设备的温度调节到某第二数值，等等。或者，为了进一步简化开发人员的操作，还可以将上述语句进行组件化处理，使得开发人员可以通过选择组件的方式，来进行联动规则的设定。这种联动的控制方式，可以实现真正的智能化，例如，通过对无卡视频识别停车系统、物业管理、会议室使用管理、小邮局、WIFI接入、打印机等软硬件的结合控制，使用户可以轻松快速完成楼宇中的大量工作，同时物业管理人员可以在很便捷地对楼宇进行维护更新，节约运营成本，等等。

需要说明的是，在本申请实施例中，关于具体的上层应用程序的实现形式可以不进行限定，平台自身或者第三方开发者，都可以基于平台开放的API进行编程，为智慧建筑中的用户提供具体的服务。例如，平台自身可以提供一些原生的应用或者服务，其中可以包括：通过所述网关中间件采集所述建筑物内部各设备的数据，并进行数据分析(包括能耗分析等)，具体的数据分析结果可以提供给应用程序进行使用，或者还可以提供给建筑物的管理人员，等等。而关于第三方开发的应用程序，则可以更加灵活多样，例如，可以包括自动化灯控、预约订餐、人脸识别、工位分时租赁、访客自助、反向寻车、预约车位，等等。关于应用程序内具体的控制逻辑等，则可以由开发者自行进行设定，这里不进行限定。

总之，传感器作为建筑的感觉器官，可以搜集建筑内的基础数据(环境、人、设施设备等)，经过建筑的网关设备到达云端的控制服务器，云端的控制服务器则开放出API接口，供开发者开发使用这些基础数据，以提供更好的服务给建筑的使用者和业主。通过这种平台化的开放标准，使得上层应用程序可以综合使用各个设备类别的基础设备产生的数据，也可以对各个设备类别设备进行联动性的控制，因此，可以避免“信息孤岛”的形成，实现感知用户，感知自身，感知周边。同时依靠自身的生态体系，可以吸引第三方机构/个人进入到建筑中来，对建筑、人、设备提供无穷无尽、不断进化的服务，从而不断满足建筑中人的多样化、个性化的需求，使整个建筑形成一个有机的、不断进化的、开放生命体。

实施例二

该实施例二是与前述实施例一相对应的，从云端的控制服务器的角度，提供了一种智慧建筑控制方法，参见图2，该方法具体可以包括以下步骤：

S201：位于云端的控制服务器提供应用程序编程接口API；

S202：接收到上层应用程序对所述API的调用请求时，确定目标智慧建筑以及其中部署的目标网关中间件；

S203：通过所述目标网关中间件将所述调用请求下发到对应的底层基础设备，以对所述底层基础设备进行操作。

具体实现时，为了更方便的实现API调用，还可以提供用于对各设备类别的底层基础设备产生的数据进行统一化描述的元数据，以便所述上层应用程序以所述元数据为参数对所述API进行调用。

具体的，可以在开放楼宇信息交换oBIX规范下实现Haystack的三类实体，所述三类实体包括地理位置实体、设备实体以及设备功能点位实体，然后，通过所述三类实体对所述底层基础设备相关的数据进行统一化描述，生成所述元数据。

在这种情况下，在接收到上层应用程序对所述API的调用请求的情况下，还可以根据所述调用请求中携带的元数据，确定请求的操作对象所继承的oBIX规范下的目标实体，以及所遵循的Haystack规范下的目标标签，然后将所述目标实体以及所述目标标签提供给所述目标网关中间件，以便所述目标网关中间件根据所述目标实体以及所述目标标签，将所述调用请求下发到对应的底层基础设备。

在具体实现中，所述调用请求包括获取目标底层基础设备目标功能点位相关数据的请求，此种情况下，可以通过所述目标网关中间件将所述获取相关数据的请求下发到对应的底层基础设备，以便所述底层基础设备将所述目标功能点位的相关数据返回，并由所述目标网关中间件将所述相关数据返回给所述控制服务器；然后，将所述目标网关中间件返回的相关数据，提供给所述上层应用程序。

或者，所述调用请求包括对目标底层基础设备目标功能点位进行设置的请求，此种情况下，可以通过所述目标网关中间件将所述设置请求下发到对应的底层基础设备，以便所述底层基础设备按照所述请求对所述目标功能点位进行设置。

另外，通过Haystack标签的使用，还可以实现更方便的查询，具体的，还可以接收查询目标地理位置带有目标Haystack标签的设备对象信息的请求，并提供所述带有Haystack标签的各个设备对象的元数据。或者，还可以接收查询目标设备对象关联的功能点位信息的请求，提供所述目标设备对象关联的各个功能点位的元数据。

实施例三

该实施例三也是与实施例一相对应的，从网关中间件的角度，提供了一种智慧建筑控制方法，具体的，参见图3，该方法可以包括：

S301：位于建筑物内部的网关中间件对建筑物内同一设备类别内不同底层基础设备的数据表达方式进行统一化处理；

S302：接收云端的控制服务器发送的API调用请求；所述API调用请求由上层应用程序发出；

S303：根据所述调用请求确定目标底层基础设备；

S304：向所述目标底层基础设备发送所述调用请求，以便对所述目标底层基础设备进行操作。

其中，所述调用请求包括获取目标底层基础设备目标功能点位相关数据的请求，此种情况下，在接收到所述目标底层基础设备返回的相关数据后，还可以按照所述统一化处理后的数据表达方式进行数据换算，然后将换算后的数据返回给所述云端的控制服务器，以便由所述云端的控制服务器返回给所述上层应用程序。

或者，所述调用请求包括对目标底层基础设备目标功能点位进行设置的请求，此种情况下，在向所述目标底层基础设备发送所述调用请求之前，还可以根据所述统一化处理后的数据表达方式，以及所述目标底层基础设备原有的数据表达方式，将所述请求中携带的数值进行换算，以便利用换算后的数值，向所述目标底层基础设备发送所述设置请求，由所述目标底层基础设备按照所述设置请求执行设置操作。

关于上述实施例二以及实施例三，具体的实现细节可以参见前述实施例一中的介绍，这里不再赘述。

实施例四

在前述各个实施例中，都是从基于智慧建筑控制系统，对具体的实现方式进行了介绍。而在实际应用中，关于本申请实施例中提供的“元数据”描述方式，还可以在其他的系统中应用，为此，本申请实施例还提供了一种数据处理方法，参见图4，该方法可以包括以下步骤：

S401：在开放楼宇信息交换oBIX规范下实现Haystack的三类实体，所述三类实体包括地理位置实体、设备实体以及设备功能点位实体；

S402：通过所述三类实体对所述底层基础设备相关的数据进行统一化描述，生成所述元数据；

S403：提供应用程序编程接口API，以便利用所述API以及所述元数据进行上层应用程序开发；

S404：接收到上层应用程序对所述API的调用请求时，根据所述调用请求中携带的元数据，确定目标操作对象所继承的oBIX规范下的目标实体，以及所遵循的Haystack规范下的目标标签，以便根据所述目标实体以及所述目标标签，对所述操作对象进行操作。

具体实现时，所述地理位置实体包括地理位置对象的顶层父类Location，其成员包括指向下层的类sublocation、指向上层的类upperLocation、以及指向地理位置对象关联设备对象的类entityCollect。

所述设备实体可以包括分别为各个设备类别建立的设备类别模板，其成员包括对应设备类别的设备所具有的功能点位，以便通过继承对应设备类别的设备类别模板，生成设备对象的元数据。

所述设备功能点位实体的成员包括指向其上层设备的引用。

在具体实现中，所述调用请求包括获取目标底层基础设备目标功能点位相关数据的请求，具体在根据所述目标实体以及所述目标标签，对所述操作对象进行操作时，可以根据所述目标实体以及所述目标标签，获取所述目标底层基础设备在目标功能点位的相关数据，并提供给所述上层应用程序。

其中，所述底层基础设备包括目标智慧建筑内部的底层基础设备，其中，所述目标智慧建筑内部还部署有网关中间件，通过所述网关中间件对同一设备类别内不同底层基础设备的数据表达方式进行统一化处理；

此种情况下，具体在根据所述目标实体以及所述目标标签，获取所述目标底层基础设备在目标功能点位的相关数据时，可以首先根据所述目标实体以及所述目标标签，向所述网关中间件发送获取所述相关数据的请求，以便所述网关中间件在接收到所述目标底层基础设备提交到数据后，按照所述统一化处理后的数据表达方式进行数据换算，并将换算后的数据返回，然后，可以接收所述网关中间件提供的关于所述目标底层基础设备在目标功能点位的相关数据。

另外，所述调用请求也可以包括对目标底层基础设备目标功能点位进行设置的请求，此种情况下，具体在根据所述目标实体以及所述目标标签，对所述操作对象进行操作时，可以根据所述目标实体以及所述目标标签，将所述设置请求下发到所述目标底层基础设备，以便所述目标底层基础设备按照所述请求对所述目标功能点位进行设置。

类似的，如果所述底层基础设备包括目标智慧建筑内部的底层基础设备，其中，所述目标智慧建筑内部还部署有网关中间件，通过所述网关中间件对同一设备类别内不同底层基础设备的数据表达方式进行统一化处理；则具体在所述将所述设置请求下发到所述目标底层基础设备时，可以根据所述目标实体以及所述目标标签，将所述设置请求发送给所述网关中间件，以便所述网关中间件根据所述统一化处理后的数据表达方式，以及所述目标底层基础设备原有的数据表达方式，将所述请求中携带的数值进行换算，利用换算后的数值，向所述目标底层基础设备发送所述设置请求，由所述目标底层基础设备按照所述设置请求执行设置操作。

可见，通过在oBIX规范下结合HayStack的标签属性(Site位置、Equip设备类型、Point功能点位)，可以更灵活地查询并控制设备，仅借助一个设备对象URI，就能得到所需要的数据，或者对设备进行控制操作。另外，通过增加HayStack的h:前缀标签，使得平台使用者不仅能通过OBIX Location位置一级一级地查询到设备，还可以通过HayStack的标签特性综合查询所有带有该标签的设备。

例如，在应用程序的开发阶段，可以接收查询目标地理位置带有目标Haystack标签的设备对象信息的请求，提供所述带有Haystack标签的各个设备对象的元数据。

或者，还可以接收查询目标设备对象关联的功能点位信息的请求，提供所述目标设备对象关联的各个功能点位的元数据。

关于该实施例四的具体实现，也可以参见前述实施例一中的介绍，这里不再赘述。

与实施例二相对应，本申请实施例还提供了一种智慧建筑控制装置，具体的，该装置应用于位于云端的控制服务器，参见图5，该装置可以包括：

API提供单元501，用于提供应用程序编程接口API；

网关中间件确定单元502，用于接收到上层应用程序对所述API的调用请求时，确定目标智慧建筑以及其中部署的目标网关中间件；

调用请求下发单元503，用于通过所述目标网关中间件将所述调用请求下发到对应的底层基础设备，以对所述底层基础设备进行操作。

具体实现时，该装置还可以包括：

元数据提供单元，用于提供用于对各设备类别的底层基础设备产生的数据进行统一化描述的元数据，以便所述上层应用程序以所述元数据为参数对所述API进行调用。

其中，在一种实现方式下，元数据提供单元具体可以包括：

实体实现子单元，用于在开放楼宇信息交换oBIX规范下实现Haystack的三类实体，所述三类实体包括地理位置实体、设备实体以及设备功能点位实体；

元数据生成子单元，用于通过所述三类实体对所述底层基础设备相关的数据进行统一化描述，生成所述元数据。

具体实现时，所述接收到上层应用程序对所述API的调用请求时，还包括：

信息确定单元，用于根据所述调用请求中携带的元数据，确定请求的操作对象所继承的oBIX规范下的目标实体，以及所遵循的Haystack规范下的目标标签；

所述通过所述目标网关中间件将所述调用请求下发到对应的底层基础设备时，还包括：

信息提供单元，用于将所述目标实体以及所述目标标签提供给所述目标网关中间件，以便所述目标网关中间件根据所述目标实体以及所述目标标签，将所述调用请求下发到对应的底层基础设备。

其中，所述调用请求包括获取目标底层基础设备目标功能点位相关数据的请求，所述调用请求下发单元具体可以用于：

通过所述目标网关中间件将所述获取相关数据的请求下发到对应的底层基础设备，以便所述底层基础设备将所述目标功能点位的相关数据返回，并由所述目标网关中间件将所述相关数据返回给所述控制服务器；将所述目标网关中间件返回的相关数据，提供给所述上层应用程序。

或者，所述调用请求包括对目标底层基础设备目标功能点位进行设置的请求，所述调用请求下发单元具体可以用于：

通过所述目标网关中间件将所述设置请求下发到对应的底层基础设备，以便所述底层基础设备按照所述请求对所述目标功能点位进行设置。

另外，还可以通过Haystack标签实现批量查询操作，具体的，该装置还可以包括：

第一查询请求接收单元，用于接收查询目标地理位置带有目标Haystack标签的设备对象信息的请求；

第一查询结果提供单元，用于提供所述带有Haystack标签的各个设备对象的元数据。

或者，该装置还可以包括：

第二查询请求接收单元，用于接收查询目标设备对象关联的功能点位信息的请求；

第二查询结果提供单元，用于提供所述目标设备对象关联的各个功能点位的元数据。

与实施例三相对应，本申请实施例还提供了一种智慧建筑控制装置，该装置应用于位于建筑物内部的网关中间件，参见图6，该装置具体可以包括：

统一处理单元601，用于对建筑物内同一设备类别内不同底层基础设备的数据表达方式进行统一化处理；

调用请求接收单元602，用于接收云端的控制服务器发送的API调用请求；所述API调用请求由上层应用程序发出；

底层基础设备确定单元603，用于根据所述调用请求确定目标底层基础设备；

调用请求发送单元604，用于向所述目标底层基础设备发送所述调用请求，以便对所述目标底层基础设备进行操作。

其中，所述调用请求包括获取目标底层基础设备目标功能点位相关数据的请求；

此种情况下，所述装置还可以包括：

第一换算单元，用于在接收到所述目标底层基础设备返回的相关数据后，按照所述统一化处理后的数据表达方式进行数据换算；

换算结果返回单元，用于将换算后的数据返回给所述云端的控制服务器，以便由所述云端的控制服务器返回给所述上层应用程序。

或者，所述调用请求包括对目标底层基础设备目标功能点位进行设置的请求；

所述装置还包括：

第二换算单元，用于在向所述目标底层基础设备发送所述调用请求之前，根据所述统一化处理后的数据表达方式，以及所述目标底层基础设备原有的数据表达方式，将所述请求中携带的数值进行换算，以便利用换算后的数值，向所述目标底层基础设备发送所述设置请求，由所述目标底层基础设备按照所述设置请求执行设置操作。

与实施例四相对应，本申请实施例还提供了一种数据处理装置，参见图7，该装置可以包括：

实体实现单元701，用于在开放楼宇信息交换oBIX规范下实现Haystack的三类实体，所述三类实体包括地理位置实体、设备实体以及设备功能点位实体；

元数据生成单元702，用于通过所述三类实体对所述底层基础设备相关的数据进行统一化描述，生成所述元数据；

API提供单元703，用于提供应用程序编程接口API，以便利用所述API以及所述元数据进行上层应用程序开发；

调用请求处理单元704，用于接收到上层应用程序对所述API的调用请求时，根据所述请求中携带的元数据，确定目标操作对象所继承的oBIX规范下的目标实体，以及所遵循的Haystack规范下的目标标签，以便根据所述目标实体以及所述目标标签，对所述操作对象进行操作。

其中，所述地理位置实体包括地理位置对象的顶层父类，其成员包括指向下层的类、指向上层的类、以及指向地理位置对象关联设备对象的类。

所述设备实体包括分别为各个设备类别建立的设备类别模板，其成员包括对应设备类别的设备所具有的功能点位，以便通过继承对应设备类别的设备类别模板，生成设备对象的元数据。

所述设备功能点位实体的成员包括指向其上层设备的引用。

具体实现时，所述调用请求包括获取目标底层基础设备目标功能点位相关数据的请求，所述调用请求处理单元具体可以用于：

根据所述目标实体以及所述目标标签，获取所述目标底层基础设备在目标功能点位的相关数据，并提供给所述上层应用程序。

所述调用请求处理单元具体可以包括：

请求发送子单元，用于根据所述目标实体以及所述目标标签，向所述网关中间件发送获取所述相关数据的请求，以便所述网关中间件在接收到所述目标底层基础设备提交到数据后，按照所述统一化处理后的数据表达方式进行数据换算，并将换算后的数据返回；

数据接收子单元，用于接收所述网关中间件提供的关于所述目标底层基础设备在目标功能点位的相关数据。

或者，所述调用请求包括对目标底层基础设备目标功能点位进行设置的请求，所述调用请求处理单元具体可以用于

根据所述目标实体以及所述目标标签，将所述设置请求下发到所述目标底层基础设备，以便所述目标底层基础设备按照所述请求对所述目标功能点位进行设置。

所述调用请求处理单元具体可以用于：

根据所述目标实体以及所述目标标签，将所述设置请求发送给所述网关中间件，以便所述网关中间件根据所述统一化处理后的数据表达方式，以及所述目标底层基础设备原有的数据表达方式，将所述请求中携带的数值进行换算，利用换算后的数值，向所述目标底层基础设备发送所述设置请求，由所述目标底层基础设备按照所述设置请求执行设置操作。

另外，该装置还可以包括：

或者，该装置还可以包括：

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的智慧建筑控制方法、装置及系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims

1.一种智慧建筑控制系统，其特征在于，包括：

2.根据权利要求1所述的系统，其特征在于，所述调用请求包括：对不同设备类别中多个底层基础设备进行操作的调用请求，所述控制服务器用于通过所述网关中间件将所述调用请求下发到对应的底层基础设备，以获取底层基础设备的相关数据、或者向对应的底层基础设备分别下发调用请求。

3.根据权利要求1所述的系统，其特征在于，所述控制服务器还用于提供用于对设备类别的底层基础设备相关的数据进行统一化描述的元数据，以便所述上层应用程序以所述元数据为参数对所述API进行调用。

4.根据权利要求3所述的系统，其特征在于，所述控制服务器还用于在开放楼宇信息交换oBIX规范下实现Haystack的三类实体，所述三类实体包括地理位置实体、设备实体以及设备功能点位实体，以便通过所述三类实体对所述底层基础设备相关的数据进行统一化描述，生成所述元数据。

5.根据权利要求2所述的系统，其特征在于，所述网关中间件，还用于在获取底层基础设备的相关数据后，对所述相关数据的数据表达方式进行统一化处理，并向所述控制服务器发送统一化处理后的相关数据；其中，所述统一化处理后的相关数据的数据表达方式，在所述底层基础设备对应设备类别的范围内统一；或者

所述网关中间件，还用于在向底层基础设备发送调用请求之前，对所述调用请求中携带数据的数据表达方式进行数据转换，并向所述底层基础设备发送数据转换后的调用请求；其中，所述调用请求携带数据的数据表达方式，在所述目标底层基础设备对应设备类别的范围内统一；所述数据转换后的调用请求携带数据的数据表达方式，符合所述目标底层基础设备对应的厂商定义。

6.根据权利要求1至5中任一所述的系统，其特征在于，所述统一化处理的结果包括：厂商定义的数值范围与其统一后的数值范围之间的对应关系。

7.根据权利要求1至5中任一所述的系统，其特征在于，所述数据表达方式包括：数值范围。

8.一种智慧建筑控制方法，其特征在于，包括：

位于云端的控制服务器提供应用程序编程接口API；

9.一种智慧建筑控制方法，其特征在于，应用于位于建筑物内部的网关中间件，包括：

根据所述调用请求确定目标底层基础设备；

10.根据权利要求9所述的方法，其特征在于，所述对所述调用请求中携带数据的数据表达方式进行数据转换，包括：

根据厂商定义的数值范围与其统一后的数值范围之间的对应关系，对所述调用请求中携带数据的数据表达方式进行数据转换。

11.根据权利要求9所述的方法，其特征在于，所述调用请求包括：获取目标底层基础设备的相关数据的请求；

所述方法还包括：

在接收到所述目标底层基础设备返回的相关数据后，对所述相关数据的数据表达方式进行统一化处理；其中，统一化处理后的相关数据的数据表达方式，在所述目标底层基础设备对应设备类别的范围内统一；

将统一化处理后的相关数据返回给所述控制服务器。

12.根据权利要求11所述的方法，其特征在于，所述对所述相关数据的数据表达方式进行统一化处理，包括：

根据厂商定义的数值范围与其统一后的数值范围之间的对应关系，对所述相关数据的数据表达方式进行统一化处理。

13.一种智慧建筑控制装置，其特征在于，应用于位于云端的控制服务器，包括：

API提供单元，用于提供应用程序编程接口API；

14.一种智慧建筑控制装置，其特征在于，应用于位于建筑物内部的网关中间件，包括：