1. 前言
上世纪90年代后期，IT技术得到了进一步的发展，尤其是网络数据通信技术的发展，人们对现场总线或自控网络有了更深入和更完整的认识，并更深入地意识到解决“信息孤岛”和构建完整智能建筑系统的重要意义，以及制订专用于智能建筑自控领域自控网络的必要性。在这种背景下，由ASHRAE学会资助产生了BACnet标准，由此智能建筑自控网络由专有型向开放型转变。在要求开放的形势下，LonWorks标准也公布了参考实现源代码而成为开放标准。
在开放标准基础上，各种智能建筑子系统的信息可以共享，因而理论上可以构建完整的集成智能建筑系统。但事实上，由于不同标准之间存在差异，即使是公认的BACnet和LonTalk两大标准，也很难实现不同标准间的无缝集成。很明显，如果制定一个公共的集成接口，并且所有的自控网络标准均支持这个公共集成接口，则可以通过这个公共集成接口高效地进行集成。于是就出现了基于OPC(OLE for Process Control)标准的集成技术。虽然这种集成技术存在与Windows操作平台有关的缺点，但这种集成技术仍然是当前大多数智能建筑系统集成所采用的主要技术。
随着企业应用(如人力资源，客户关系，财务管理等)集成的需求，越来越多地要求智能建筑系统接入到企业管理信息系统(MIS)之中，以便全面分析企业的所有运行信息和进行决策。另外，随着更大数量的“机器-机器(M2M)”通信业务的快速发展，也必须发展出一种与“平台无关，语言无关和协议无关”的系统集成技术。在Internet发展过程中，XML/Web Services技术凭借其“平台无关，语言无关和协议无关”的特点逐渐成为企业应用集成的焦点。这种技术以其开放性、标准性和简便性在IT业界得到了广泛应用，并正向智能建筑自控领域及其系统集成应用高速渗透。利用XML/Web Services技术进行智能建筑自控系统集成正是这种发展趋势的具体表现，代表着智能建筑自控系统集成技术的发展方向[。
正是由于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)。
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绑定。
2.1 信息模型
oBIX标准的信息模型包括对象(object)和合同(contract)两种模型。oBIX标准定义的对象模型如图2所示。在oBIX标准中，对象是与“应用领域无关”的低层次XML词汇或命名空间，是oBIX XML文档的组成元素项(element)。该对象模型除用于描述智能建筑系统信息以外，还可以用于其他自控领域的信息描述。所有oBIX XML文档均由该对象模型所规定的XML词汇或命名空间所构成。
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即可。
(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所示的智能建筑系统集成方案和系统架构模型。 另外，由于oBIX标准均由oBIX对象所组成，为了标识不同类型的oBIX对象，oBIX标准采用了URI标识方式。
合同(Contract)是由oBIX对象按oBIX标准规定的语法所构成的XML文档，是与应用相关的语义“对象”模型。也就是说，合同是用对象模型描述具有互操作语义的XML文档，或是具有一定互操作语义的oBIX对象，其作用是使智能建筑系统的基本单元描述标准化，从而使实现或引用合同的用户均可以知道该合同所描述的互操作语义，这就使合同成为与应用相关的互操作语义实体，即合同是建立在低层次对象模型之上的、具有互操作语义的高层次oBIX对象。例如，名称为oBIX:Alarm的合同就是oBIX标准中与报警相关信息的标准描述单元，该合同用oBIX对象模型描述了报警源、报警时间、报警接收者等信息，使实现和引用该合同的用户均可以按照该合同的标准结构及其所蕴含的互操作语义使用和解读该合同，从而实现系统的集成和互操作。
从合同的作用可以看出，合同是较高层次语义的oBIX描述标准单元。合同与对象模型间的关系犹如面向对象计算机编程语言(如C++，Java等)的基本数据类型与对象类型之间的关系，虽然编程语言中的基本数据类型是有限的和固定的，但利用基本数据类型创建的对象类型并不是由编程语言硬性规定的，只要按照编程语言的语法规则就可以用基本数据类型创建任意与应用相关的对象类型，并且所有满足编程语法规则的对象类型均可以由同一编译器(compiler)进行识别和编译。oBIX标准的对象模型和合同也采用这种思想，虽然oBIX对象模型定义了有限的基本对象类型，但在oBIX标准规定的XML语法约束下可以用有限的基本对象类型和合同对象类型构造与应用相关的任意类型的合同，从而使oBIX标准在描述功能上具有强大的扩展机制。
4. 结束语
智能建筑系统的重点已由原来的自控网络通信协议标准转移到了以现代IT技术为主的系统集成技术标准，oBIX标准以其面向企业应用集成和独立于楼宇自控网络通信协议的特点逐渐成为智能建筑系统与企业应用集成的主要标准，并使智能建筑系统的集成不再以自控网络通信协议标准为核心，而是在现代IT技术的框架下逐渐“淡化”通信协议标准的作用，使各种通信协议标准“和平共处”，优势互补，共同完成智能建筑系统的功能。无论是开放的通信协议标准，还是专有通信协议标准，只要符合这个IT技术的集成和互操作标准，均可以用于智能建筑系统集成，并真正成为企业应用集成的基础。因此在我国继续争论不同自控网络通信协议标准的优劣，或否定现有主流自控网络通信协议标准，而重新制定自控网络通信协议标准是没有意义的。我们要站在时代的前沿，重新审视智能建筑系统的发展趋势，研究和开发并大力应用已有主流技术标准才是我们迎头赶上先进的最好途径。
微信咨询
