I was asked last month “Whatever happened to oBIX?” I paused. I knew I was using it. I know I get phone calls about it regularly. Still, aside from the recent Frost & Sullivan report on oBIX and the enterprise, matters related to oBIX have been quiet since the ratification of version 1.0. There are two types of reasons that you don’t hear about oBIX.

[an error occurred while processing this directive]

As in the long running ad by a chemical company, you don’t buy oBIX; oBIX just makes the things you buy, better. oBIX is a small protocol among the many small protocols in the enterprise. oBIX enterprise-enables control systems. oBIX lets you build new kinds of applications. If you did buy oBIX, you bought it as part of an application.

The people who know oBIX best have been going out and doing things with oBIX. Many of these projects are large, and may take years to complete. We’ve been busy.

Here is a quick list of projects that I have some, even if often just a very little, knowledge of:

• The Enterprise Building Management System (EBMS) at UNC operates more than 100 buildings with systems of all brands and technologies. All external interactions with buildings are by web services. Sixty-six of these buildings are operated by oBIX. An iLON-style controller with full oBIX support would attract strong consideration as our preferred platform for future integration.

• The Dubai Airport. Dubai has become known for leadership and innovation in construction and sustainability in capital projects. I do not have a contact for this, but would be very happy to know more. I hear the Dubai airport integration is based on product from Tridium. oBIX is a key component of the newest NIAGARA integration platform from Tridium. Tridium’s NIAGARA is used to integrate many complex systems. oBIX even provides the integration layer between their current product (R3) and their previous product (R2) (http://www.tridium.com/cs/products_/_services/niagaraax). If anyone can tell me more about the Dubai project, please drop me a line.

• Building systems in the Olympic Stadium, the Olympic Village, and all outdoor lighting in the Olympic District in Beijing are monitored and operated using oBIX. If I am informed correctly, this work was based upon a variant of the 0.7 draft of the specification. As stated above, these projects take years to complete, and decisions get locked in long before construction completion.

• I hear some reports that the Olympic variant of oBIX is used for energy management of whole city districts of mixed use new buildings in Chinese cities.

• Powernab’s YouTility service is integrating in-house services, weather conditions, and solar monitoring for end-user. If I am correct, Powernab uses oBIX interfaces developed by Controlco. (www.powernab.com, www.controlco.com)

• Hawkesbury’s eSight M&T (Monitoring and Targeting) suite provides and comprehensive fully web based energy management. eSight is able to interact with any oBIX enabled system. eSight is available for installation on-sight or remotely, providing Software as a Service (Saas). (http://www.eSightenergy.com/)

• NTT in Tokyo is developing oBIX drivers, but I know little more than that.

The new draft specification for Automated Demand-Response (OpenADR) is one of the more exciting new efforts that will drive oBIX applications. Lawrence Berkeley National Labs released OpenADR for public review this month (http://drrc.lbl.gov/openadr/) and may emerge as a national standard for communications between buildings and the power grid. From conversations, I expect that there will be a quick convergence on standard oBIX contracts for interaction with OpenADR. With some effort, those contracts may well converge with the higher level Load Control objects proposed by BACnet. 

(Editor's Note: See press release "Open Auto-DR Communication Standards" released! and this month's article Open Automated Demand Response Communication Standards for more information on this topic.)

As Chair of oBIX, I continue to hear other projects, ones that people tell me expecting me to keep their product plans quiet. I look to more products soon in areas such as building security and in other systems far from buildings. That last point is one of the more consistent pieces of feedback. I consistently hear that oBIX is a great abstraction layer for any embedded system, whether in a building, boat or in the field.

There is an active developer community of oBIX implementers around the world. Tridium hosts some of the most active blogs and forums at its NIAGARA portal (http://www.niagara-central.com/ord?portal:/home) A more technical, less branded forum can be found as a Google group (http://groups.google.com/group/obix-developers/).

A very interesting project is the SourceForge oBIX Server project (http://sourceforge.net/projects/obix-server/) headed up by Peter Michalek. This project is creating a pluggable architecture for a small server to talk to just about any device or system.

Peter’s architecture will expand as developers add more “vertical modules” to the open repository, available under a BSD license. If I am not mistaken, a thought leader in the BACnet community passed Peter an open source driver a couple weeks ago. This work will accelerate the adoption of oBIX.

[an error occurred while processing this directive] So far, oBIX implementations are relying on the REST personality defined in the standard. oBIX also defines SOAP-based communications. SOAP is message-based rather than API-based, and so is more interesting for long-running interactions between distributed entities within and without the enterprise. These messages are composite, meaning they tend to use many standards at once, mixing and matching them to meet business objectives much as many standards are mixed in each email you send.

As energy markets heat up, e-commerce developers are putting building interaction in the middle of business negotiations. Security discussions are maturing from simple concepts like encryption to identity management, delegation of authority, and non-repudiation of contracts. Interaction patterns are changing from simple “do it now” interactions to price-based schedule negotiation, to business process integration (BPEL), and to results-based requests.

On the security and safety side, we are just beginning to define security and emergency response integration. The emergency response community has just begun to define the interactions between CAP, the web-services based successor to the old Emergency Broadcasting System, and building-based oBIX. Deep enterprise security in IT is managed by policy declarations external to the services. Federal researchers are looking to apply the same policy based security and policy based event management to oBIX-based access control and intrusion detection using service component architecture (SCA).

In short, oBIX is still around and flourishing. The committee, with Brian Frank’s clear vision, crafted a lean general purpose object model that meets both the needs of today’s building integration and tomorrow's e-commerce and enterprise integration. Most people who know it well are too busy to talk about it much—and perhaps that knowledge of oBIX is the reason why.

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]