oBIX - Open Building Information Exchange

The ``Organization for the Advancement of Structured Information Standards'' (OASIS) is an international consortium that releases standards concerning Web Services. OASIS is the successor of the SGML Open consortium, founded in 1993, which concentrated on developing guidelines for the interoperability of SGML-based applications. Today OASIS concentrates on XML and accompanying technologies such as SOAP, WSDL and UDDI and released several standards for Web Services.

The ``open Building Information Exchange'' (oBIX) is an OASIS initiative which defines XML and Web Services-based mechanisms for building control systems. The oBIX specification version 0.6 is a mature working draft and is expected to become a standard in the near future. Further information about the oBIX working draft can be obtained in [OBIX].

oBIX represents data as objects in a hierarchical, tree-like structure as depicted in figure 21. The top level object is called ``root object'' and is the parent of all other objects.³⁴ Data can be addressed in a hierarchical way, such as /Floor1/Room3/Lights. oBIX additionally utilizes this object tree for data browsing by recursively returning subtrees of objects.

Figure 21: oBIX Data Structure

The standard defines so-called ``oBIX Services'' which represent Web Services. These contain one or more ``oBIX Operations'' which are methods that can be called by a client. Currently oBIX specifies only one service, namely the ``SysService'' which defines basic operations such as read/write. It is expected that oBIX will specify further services in future releases of the standard for tasks like retrieving historic data or handling alarms.

The oBIX Specification contains the following key elements:

Localization:

Most oBIX operations support the ``locale'' element which handles language and country specific issues. This way, data types like date and time can be formatted to specific needs, in addition strings may be displayed in applications in the local language.

Data Types:

For simplicity reasons, oBIX contains only the following simple data types: bool, int, real, string, enum, absTime and relTime. Data structures can be represented by utilizing the hierarchical data tree.

oBIX introduces so-called ``facets'' which enable defining meta-data to oBIX data types, such as possible minimum/maximum values, resolution and precision³⁵.

Units:

Handling different units is no easy task in distributed systems. oBIX chooses an interesting approach to this problem by mathematically defining units with XML. The standard itself provides only basic SI units³⁶. Moreover, oBIX utilizes a simple, linear equation which can be used to express most common units. Listing 11 shows an example of the definition of the unit ``hour''³⁷.

language=XML

Status:

Every object has a status element which is returned as a companion to values. The element contains important information about the object, such as the quality³⁸ and actual time of the read data and an alarm element which may be utilized for providing a summary of alarm states.

SysService:

The SysService defines all operations and forms the base of the oBIX specification. It contains the following items:

About:

This operation is defined for retrieving status information about the oBIX server and returns elements like server name, vendor, uptime and available locales.

Read/Write:

These operations implement reading and writing of one or more data objects. The key elements of these operations are best described by a simple example, given in listing 12.

language=XML

The read request contains the identification (id) of the object that should be read. The response contains the value, as seen in line 8, the status and the facets of the value. oBIX uses an interesting way to assign the data type to the value. Instead of using XML-Schema such as <value xsi:type="xsd:double">21.2</value> oBIX defines tags that directly map to data types, such as <real> or <str>.

As denoted above, read requests can also be used for browsing, which is shown in Listing 13.

language=XML

To enable browsing, the read request contains the element ``depth'', which specifies how many hierarchies of the object tree the read operation should descend. Moreover, the request may contain the element ``include'', which is used to specify what kind of data should be returned.

Write operations are very similar to read operations: a client issues a write request and the server replies with a write response. Multiple data objects can be written simultaneously.

Subscription:

As HTTP does not support notifications due to it statelessness, oBIX chooses a similar approach to OPC and implements ``polled subscription'' where the client periodically³⁹ polls the server for changed data. oBIX does not specify advanced techniques like OPC for minimizing the delay between data updates⁴⁰.

By the time of this writing, version 0.7 of the oBIX working draft emerged, which is very different to the prior standard. The new draft is not SOAP Web Service-based, instead it is based on the ``Representational State Transfer'' (REST) architecture⁴¹. The oBIX 0.7 working draft contains the following key elements:

Addressing:

oBIX 0.7 addresses objects with URIs, such as "http://server1/room1/sensor1". An URI identifies a unique oBIX object.

REST Verbs:

oBIX objects may be accessed by so-called ``Verbs'', which consist of the four functions Get, Put, Create and Delete and map directly to their HTTP counterparts.

Prototypes:

The working draft specifies so-called ``prototypes'', which are used to model objects. oBIX objects always inherit from prototypes and may define new elements or override elements of their parent.

Listing 14 depicts a simple ``get'' response:

language=XML