253开放楼宇信息交换oBIX标准及其应用探讨.doc

开放楼宇信息交换(oBIX)标准及其应用探讨清华大学 董春桥 江亿摘要：论述智能建筑系统集成技术的发展历程和当前状况，说明oBIX标准在智能建筑系统集成中的作用和意义；分析oBIX标准的基本原理，提出oBIX标准的应用解决方案和实现架构。关键词：oBIX，智能建筑(IB)，系统集成，实现架构Open Building Information Exchange (oBIX) Standard and its ApplicationTsinghua University, Dong Chunqiao & Jiang YiAbstract: The process and status of Intelligent Building(IB) system integration are reviewed, the function and significance of oBIX standard in IB system integration are explained. After that, the principle of oBIX standard is analyzed, its application solution and implementation framework are given.Keywords: oBIX, Intelligent Building (IB), System Integration, Implementation Framework1. 前言智能建筑(IB)经过二十余年的发展，其理论和技术逐渐形成，并已形成了巨大的市场和产业。随着社会和科技的进步，智能建筑仍将不断采用高新技术，并不断发展。这种不断发展的特性使智能建筑在不同的时期具有不同的技术特性。虽然无法预测未来，但回顾智能建筑系统的发展历程，并对不同发展阶段中具有里程碑意义的技术特点进行分析，既可以在智能建筑系统中恰当地应用现代高新技术，也可以准确把握智能建筑系统的发展方向，及时掌握新技术，以迎接新技术的挑战。从智能建筑系统的实现技术来看，智能建筑系统就是将先进的传感器技术、通讯技术、网络技术、自动控制技术、计算机技术以及数据处理技术等有机地运用于建筑的运行和管理过程而建立的一种实时、准确、高效的综合控制和管理系统，其目标就是增强建筑的效能(performance)和提高建筑的产出(productivity)。为了实现这个目标，智能建筑系统在不同的时代采用了不同的技术方案。(1) 单功能系统：上世纪80年代，出现了以通用型控制器(GPC)为基础的直接数字控制(DDC)智能建筑自控系统。一个DDC智能建筑自控系统控制一个或多个楼宇设备，并形成一个功能单一的自控系统(如电梯自控系统、照明自控系统等)。这个阶段的技术特点是，通用控制器没有通信功能，没有出现现场总线或自控网络。正因为如此，这种智能建筑自控系统的自控系统形成了完全封闭的“信息孤岛”。(2) 多功能系统：上世纪90年代中期，随着信息技术的发展，尤其是微电子技术的发展，出现了以微控制器(MCU)为核心的专用控制器(ASC)。这种专用控制器面向具体应用对硬件系统资源进行定董春桥，男，1976年1月，博士后，地址：北京市海淀区清华大学建筑学院建筑节能研究中心，邮政编码：100084，电话：（010）62780201， E-mail：制，具有非常高的性能/价格比。由于这种专用控制器硬件资源有限，一般仅能完成特定的控制功能，复杂的控制功能必须上传给硬件和软件资源丰富、且功能强大的上位计算机系统进行处理，由此形成了具有多功能的自控系统，即所谓的“集散控制系统(DCS)”。在集散控制系统中，专用控制器具有通信功能，并通过现场总线或自控网络进行互连，以实现各专用控制器间的信息共享及“分散处理、集中管理”的功能。但不同的集成系统基于不同的现场总线标准(如EIB, Modbus, Profibus等)，这种智能建筑子系统虽然内部实现了互连和信息共享，但不同子系统间仍然形成了更大的“信息孤岛”。(3) 集成系统：上世纪90年代后期，IT技术得到了进一步的发展，尤其是网络数据通信技术的发展，人们对现场总线或自控网络有了更深入和更完整的认识，并更深入地意识到解决“信息孤岛”和构建完整智能建筑系统的重要意义，以及制订专用于智能建筑自控领域自控网络的必要性。在这种背景下，由ASHRAE学会资助产生了BACnet标准，由此智能建筑自控网络由专有型向开放型转变。在要求开放的形势下，LonWorks标准也公布了参考实现源代码而成为开放标准。在开放标准基础上，各种智能建筑子系统的信息可以共享，因而理论上可以构建完整的集成智能建筑系统。但事实上，由于不同标准之间存在差异，即使是公认的BACnet和LonTalk两大标准，也很难实现不同标准间的无缝集成。很明显，如果制定一个公共的集成接口，并且所有的自控网络标准均支持这个公共集成接口，则可以通过这个公共集成接口高效地进行集成。于是就出现了基于OPC(OLE for Process Control)标准的集成技术。虽然这种集成技术存在与Windows操作平台有关的缺点，但这种集成技术仍然是当前大多数智能建筑系统集成所采用的主要技术。(4) 企业应用集成(EAI, Enterprise Application Integration)系统：随着企业应用(如人力资源，客户关系，财务管理等)集成的需求，越来越多地要求智能建筑系统接入到企业管理信息系统(MIS)之中，以便全面分析企业的所有运行信息和进行决策。另外，随着更大数量的“机器-机器(M2M)”通信业务的快速发展，也必须发展出一种与“平台无关，语言无关和协议无关”的系统集成技术。在Internet发展过程中，XML/Web Services技术凭借其“平台无关，语言无关和协议无关”的特点逐渐成为企业应用集成的焦点。这种技术以其开放性、标准性和简便性在IT业界得到了广泛应用，并正向智能建筑自控领域及其系统集成应用高速渗透。利用XML/Web Services技术进行智能建筑自控系统集成正是这种发展趋势的具体表现，代表着智能建筑自控系统集成技术的发展方向1。正是由于XML/Web Services技术的优点，不少标准组织和行业学会正在将已有的智能建筑自控网络标准进行XML/Web Services技术扩展，或制订新的XML/Web Services技术应用标准。其中最有影响的标准组织和协会有ASHRAE学会和CABA(北美大陆楼宇自动化)协会。ASHRAE学会在BACnet标准上扩展了XML/Web Services接口，形成了BACnet/Web Services标准；CABA发起和制订了基于XML/Web Services技术的开放楼宇信息交换标准oBIX(open Building Information eXchange)2。为了使oBIX标准更具影响力和权威性，CABA加入OASIS(一个全球非盈利组织，目标是制定和发展电子商务领域标准)并成立了oBIX技术分会，于2006年6月30日正式发布了oBIX标准(V1.0)。而LonWorks阵营虽然意识到了XML/Web Services技术的重要性，并进行了许多研究和产品(i.Lon系列产品)开发工作，但不制定相关的标准，只支持CABA制定和完善oBIX标准。综上所述，智能建筑本身具有多学科交叉和融合的特征，不仅利用相关基础学科的原理发展其规划、设计、施工和运行管理等技术，而且自身也具有明确的基本科学问题和特点，综合特征明显。oBIX标准就是多学科交叉和融合的智能建筑系统集成技术，具有明确的运行管理功能和综合的特征，其作用是屏蔽不同楼宇自控网络标准的差异，提供统一和开发的智能建筑系统集成技术，其意义在于将智能建筑系统作为企业应用集成的一个子系统，无缝地集成到企业管理信息系统之中，从而使智能建筑系统具有更广阔的应用。2. oBIX基本原理从智能建筑系统集成技术的发展过程可以看出，oBIX标准是基于现代IT技术的智能建筑系统集成技术标准。正如其他系统集成技术一样，oBIX标准必须利用XML/Web Services技术的数据描述功能和互操作机制等核心内容定义智能建筑系统的信息模型(Information Model)、互操作方式(Interoperation Mode)和互操作语义的网络传输(Network Transport)等内容3，由此形成了如图1所示的基本体系和对应的基本内容。在oBIX标准中，信息模型是以对象(object)和合同(contract)为基础的对象模型，互操作方式是建立在对象模型之上以Read(读)、Write(写)和Invoke(调用)为基础的REST (Representation State Transfer)互操作方式，网络传输采用SOAP绑定或HTTP绑定。图1 oBIX标准体系结构图2.1 信息模型oBIX标准的信息模型包括对象(object)和合同(contract)两种模型。oBIX标准定义的对象模型如图2所示。在oBIX标准中，对象是与“应用领域无关”的低层次XML词汇或命名空间，是oBIX XML文档的组成元素项(element)。该对象模型除用于描述智能建筑系统信息以外，还可以用于其他自控领域的信息描述。所有oBIX XML文档均由该对象模型所规定的XML词汇或命名空间所构成。另外，由于oBIX标准均由oBIX对象所组成，为了标识不同类型的oBIX对象，oBIX标准采用了URI标识方式。合同(Contract)是由oBIX对象按oBIX标准规定的语法所构成的XML文档，是与应用相关的语义“对象”模型。也就是说，合同是用对象模型描述具有互操作语义的XML文档，或是具有一定互操作语义的oBIX对象，其作用是使智能建筑系统的基本单元描述标准化，从而使实现或引用合同的用户均可以知道该合同所描述的互操作语义，这就使合同成为与应用相关的互操作语义实体，即合同是建立在低层次对象模型之上的、具有互操作语义的高层次oBIX对象。例如，名称为oBIX:Alarm的合同就是oBIX标准中与报警相关信息的标准描述单元，该合同用oBIX对象模型描述了报警源、报警时间、报警接收者等信息，使实现和引用该合同的用户均可以按照该合同的标准结构及其所蕴含的互操作语义使用和解读该合同，从而实现系统的集成和互操作。图2 oBIX对象模型关系图从合同的作用可以看出，合同是较高层次语义的oBIX描述标准单元。合同与对象模型间的关系犹如面向对象计算机编程语言(如C+，Java等)的基本数据类型与对象类型之间的关系，虽然编程语言中的基本数据类型是有限的和固定的，但利用基本数据类型创建的对象类型并不是由编程语言硬性规定的，只要按照编程语言的语法规则就可以用基本数据类型创建任意与应用相关的对象类型，并且所有满足编程语法规则的对象类型均可以由同一编译器(compiler)进行识别和编译。oBIX标准的对象模型和合同也采用这种思想，虽然oBIX对象模型定义了有限的基本对象类型，但在oBIX标准规定的XML语法约束下可以用有限的基本对象类型和合同对象类型构造与应用相关的任意类型的合同，从而使oBIX标准在描述功能上具有强大的扩展机制。利用上述思想，任何人都可以根据应用需求构造任意类型的合同。为了使常用的合同类型标准化，oBIX标准经过抽象总结，将常用的合同类型定义为“标准类型合同”，例如，oBIX:Point, oBIX:Alarm和oBIX:History等均为标准合同对象。在oBIX标准中，由oBIX标准定义的标准合也可以简称为“合同”，而由用户或楼宇自控设备厂家根据应用自己定义的合同通常称为“扩展合同”。2.2 互操作方式在互操作方式上，oBIX标准采用了“客户/服务器(C/S)”模型，并将所有互操作过程归纳为Read(读)、Write(写)和Invoke(调用)三种操作过程。其中，Read用于客户读取服务器的oBIX信息，Write用于客户向服务器写入oBIX信息，Invoke用于客户调用服务器的操作过程。这种互操作方式在Web网络环境中通常称为REST(REpresentational State Transfer)方式。REST方式是上述资源访问方式的总称，是一种面向网络资源访问的设计方式，凡是符合这种访问方式的资源操作均可以称为REST方式。具体地说，oBIX标准利用REST方式的具体内容如下：(1) Read操作：客户指定访问oBIX对象的URI，当访问的对象在服务器中存在时，则由服务器返回访问对象的结果。当服务器不能执行访问操作时，则向客户返回一个指明访问操作失败的err对象，以说明该操作失败的原因。(2) Write操作：该操作用于更新对象的状态或信息。客户请求该操作时，必须指定要更新对象的URI和更新值。当服务器正确执行该操作时，则返回更新对象的更新值。反之，则向客户返回err对象，以说明失败的原因。一般情况下，该操作仅用于对象val属性的更新操作，而且当更新带有unit属性的int或real对象的val属性值时，更新值必须与原val属性具有相同单位。(3) Invoke操作：该操作用于调用服务器上的一个操作过程。客户请求该操作时，必须指定调用op对象的URI，若该操作要求输入参数时，则必须指定输入参数的对象值。当正确执行时，该操作按输出参数的形式返回结果。反之，则返回err对象，以示操作失败。2.3 网络传输上述互操作模式只说明了oBIX标准的互操作设计模式及其功能和交互规程，一个实际可运行的oBIX Web系统必须是上述互操作模式在具体网络环境中的实现(implementation)，这就是所谓的“协议绑定(protocol binding)”。从理论上来说，几乎已有的通信协议均可用于oBIX标准互操作模式的实现，如SMTP, POP3, HTTP等。但考虑到通信协议应用的普遍性和实现效率，同时也为了规范实现过程和易于系统集成，oBIX标准规定了如下两种协议绑定方式。(1) HTTP绑定方式：HTTP绑定只是简单地将oBIX标准的REST互操作功能和规程映射为HTTP协议。例如，oBIX标准的Read(读)请求可简单地映射为HTTP协议的GET请求，这样只需在Web浏览器中输入Read请求对象的URI即可。表1列出了oBIX请求与HTTP协议的映射关系。表1 oBIX请求与HTTP协议的映射表oBIX请求HTTP方法访问目标ReadGET具有href属性的对象WritePUT具有href属性且其Writable属性为true的对象InvokePOST任意op对象在表1的映射表中，HTTP协议的URI必须与oBIX请求的URI相同，并且所有对应的HTTP协议过程均返回oBIX请求操作的XML文档。当oBIX请求有输入和输出参数时，不仅输入为oBIX文档，而且输出结果也是oBIX文档。所有oBIX文档应通过HTTP协议的头部的MIME类型指定为“text/xml”，并且建议使用UTF8编码。(2) SOAP绑定方式：SOAP绑定就是将oBIX标准的Read、Write和Invoke操作映射为SOAP协议的操作。与HTTP绑定方式一样，Read操作可应用于所有的oBIX对象，Write操作只应用于Writable属性为真的oBIX对象，调用只应用于op对象。但与HTTP绑定方式不同的是，SOAP操作并不是通过访问对象的URI进行访问的，而是将访问对象的URI编码在SOAP信封的主体(body)中，并通过服务器的URI进行访问的。当服务器正确执行请求时，则在返回SOAP信封的主体中返回请求的结果。当服务器不能正确执行操作请求时，仍返回正确的SOAP信息，但其主体为指明不能正确执行操作请求的err对象信息。3. oBIX实现架构根据oBIX标准的基本原理，从理论上可以直接利用oBIX标准对智能建筑系统现场层和控制层的信息进行描述，并且这种技术的编码比已有的自控网络通信协议标准所定义的格式灵活。但由于oBIX标准编码为文本方式，当需要进行高速处理时，对通信带宽和信息处理能力要求较高。这表明基于oBIX标准的应用需要较多的计算资源、较大的传输带宽和较强的处理能力。在目前技术水平和经济状况下，直接将oBIX标准应用于对价格和效率比较敏感的现场层自控设备是不现实的。因此，oBIX标准在近期内不会在现场层和控制层与已有自控网络通信协议标准(如BACnet或LonTalk等标准)形成竞争，更不会取代已有的自控网络通信协议标准，而是这些标准在管理层的补充和扩展，或是在系统管理层取代OPC系统集成方式的新技术。尽管如此，在国内外已有这方面的大量研究和尝试。随着IT技术的发展，尤其是微电子技术的发展，当计算成本、传输成本和存储成本降低到一定程度时，oBIX标准的应用就会延伸至自控网络系统的现场控制层，从而成为真正的“统一标准”，并最终实现智能建筑系统与企业应用的融合和统一。从上面的分析可知，oBIX标准通常用于对现有各种智能建筑子系统的集成。基于这种应用方式，本文提出了如图3所示的智能建筑系统集成方案和系统架构模型。图3所示的“oBIX通用接口”是利用oBIX对象和合同的信息模型映射接口，其作用是将各种已有自控网络通信协议的信息模型转化为通用的oBIX标准模型，使各种企业应用通过统一的REST操作方式进行访问和控制，从而实现智能建筑系统与企业应用的集成。为了形象地说明地oBIX通用接口的作用，北卡罗莱纳大学(University of North Carolina)教授Toby Considine形象地称之为“抽象仪表级接口4”，这种抽象仪表级接口的功能和作用可以用汽车仪表的功能和作用来比拟：无论哪种汽车，不管其发动机是哪家生产的，不管其内部控制系统是如何运行的，只要驾驶仪表提供相同的功能(如行驶速度、发动机转速等)，则不论驾驶者是谁，在相同功能仪