OBIX, Smart TVs, and the Commercial Building

We started work on OBIX 1.1 nearly a year ago. OBIX has world-wide use but no unified market. Today’s Asian SOAP implementations do not interoperate well with the North American middleware versions which do not interoperate well with the European systems for energy and the internet of things. Our first goal was to improve interoperation through tightening conformance. We added support for additional application models and communication choices. We ended up finding our way into consumer electronics and the internet of things.

Last month, the OBIX Technical Committee released five specifications for public review. OBIX is a generic web service interface for control systems. OBIX started as a CABA project for BAS interoperability. This is the first update to OBIX 1.0 which was completed in 2005. The current public review runs through February 14. A link to the original announcement is at the bottom of this article.

There are a few interactions common to all control systems. Turn something on. Turn it off. Read a set-point (say a thermostat). Set a set point. Read a sensor. Discover the exposed points and find out what you can do with them. OBIX 1.0 is a simple model that represents all of these control system interactions as web services in XML. The use of OBIX is free, free to download, free to develop with, free to use.

There are OBIX drivers for just about everything: BACnet, LON, KNX, Metasys, ModBus, DNP, … Honeywell / Tridium use OBIX to stitch together the predominant BAS middleware system in North America. IBM uses it as BAS Middleware in the European market. It is used in numerous ETSI projects. It is the wide area communications protocol for all the Smart Tokyo work. In Korean systems , OBIX is transported over ZigBee to communicate with smart lighting and smart power bars.

One of our first decisions was to break OBIX into smaller pieces, to make it simpler for a programmer to know which rules apply in his scenario. With smaller pieces we can more easily say “An Application conforms only if…” This makes interoperation of different platforms much more likely.

By May, we had isolated the core information model and interactions (OBIX 1.1), including a machine-readable XML data model (XDM) that supports validation by software development tools. We separated out Encodings and Bindings. We added features to support large data-set telemetry. We added the capability of adding metatags to points, that is additional standardized information about that point.

OBIX does not specify any of the meta-information used in these tags. Different groups will define their own meta-information specifications. Many in North America are considering using this feature to include tags from the folksonomy Haystack. Building owners with more formal processes are looking to BIM as a source of these tags, perhaps using the semantics defined in COBie Lite. Other markets will surely define their own tags. For example, neither of the standards above makes sense for medical equipment tracking applications. OBIX 1.1 adds a structure to the Lobby to name the meta-information specifications.

We found that users were already using wide-ranging Encodings other than the original XML. Several skunk-works projects were encoding OBIX in JSON. The European research universities were building sensornets around OBIX using CoAP and EXI.

The specification “Common Encodings for OBIX” defines how to use the encodings listed above. XML is the original encoding. JSON is vigorously supported by current web developers and is a natural interface to the many languages that descend from LISP. EXI (Efficient XML Interchange) is a W3C specification for using XML in environments where bandwidth is constrained. CoAP (Constrained Application Protocol) is an IETF protocol intended to be used in very simple electronics devices, targeted at small low power sensors, switches, valves, and similar components, and is designed to easily translate to HTTP.

We also developed two binding specifications: REST and SOAP to better codify existing practice. The REST binding is typified by the communications long provided by Tridium. The SOAP binding is typified in the multi-tiered architecture used by ETSI projects and by Asian products such as Energle.

These formal encodings and bindings make it easy to understand what the other side of a communication expects. The new model would describe current NIAGARA as using the OBIX 1.0 model encoded in XML and bound with REST; Energle would be described as the OBIX 1.0 model encoded in XML and bound with SOAP.

Representatives of the Smart TV Alliance (STVA) joined the Committee last June, just as the specifications above went out for initial public review. The STVA is using JSON, and wanted the committee to standardize binding WebSocket (RFC 6445). WebSocket provides for full-duplex (two-way) communications over an HTTP connection. WebSocket is a recommended aspect of HTML5, so you are probably reading this on a device that supports WebSocket already. It was easy to accommodate the Alliance using our new specification model—which is why we went to the multi-part format. The Smart TV Alliance proposes to use OBIX encoded in JSON and bound to WebSocket.

The initial goal of the Alliance is to create a common platform for TV apps. Today a company such as NetFlix must write an app for each TV. Under the Alliance plans, the same app would run on televisions from LG, Panasonic, Phillips, Toshiba, and Vestel. These televisions will all support HTML5 applications. I expect an explosion of TV-based apps as companies exploit the Alliance-developed Eclipse plug-in to write once, run everywhere.

The other aspect of the STVA vision is a common platform for Phones and Pads that communicate with Smart TVs. Why fumble for your remote when your Android phone is in your pocket, and your iPad is on the table. The Alliance SDK uses OBIX over WebSocket for communication between PDA and TV. While many foresee fancy interfaces with more options, I foresee apps with big icons and simple interfaces for the elderly market as well. Consumers will be able to choose what works best for them at the App Store.

The Smart TV Alliance announced their SDK at the Consumer Electronics Show 2014, just as the latest OBIX specifications went out for public review.

The Smart TV Alliance is likely to further expand the use of OBIX in homes. An obvious extension is the home theatre, in which the Smart TV communicates communications with lighting, with sound systems and with other consumer electronics. The communication model implicitly standardizes ways for the phone and the pad to communicate with these systems directly.

It remains to be seen if the CES will take advantage of the new metatags with consumer-oriented tagging. (In possibly related news, Apple, not a member of the Alliance, last summer pushed through an RFC draft for aggregated service discovery to support their own televisions.) Doing so would aid their vision of “zero effort integration”.

This brings App culture and App technology to smart homes, and, to me, that means Smart Energy Apps won’t be far behind. Homeowners won’t tolerate long integration requirements, so energy system discoverability over existing infrastructure (Wi-Fi) is critical. It is a small hop to communicating with the Wi-Fi enabled thermostat. This is sure to intensify sparring between Honeywell’s Wi-Fi Smart and Google’s Nest. U-SNAP can bring WebSocket to standard appliances.

Smart homes might at last be here, not just for hobbyists, but for the rest of us. Interested readers might look to the IPSO Alliance for more ideas as to how this potentially fits together. I expect that CABA, where OBIX originated, will soon take this up in their Digital Home Forum.

Does this mean that home automation and home energy will start to drive commercial buildings? Corporate IT has been driven for years now by expectations that users develop on their newer, more sophisticated systems at home.

Digital Signage, whose platform is essentially flat panel televisions, will be the first commercial building system to be remade. It takes only a moment to imagine how advanced signage will change with a consistent local HTML5 platform. Multi-screen digital advertising company YuMe is already a member of the Alliance. Custom development kits will need to remake themselves. Wayfinding, building directories, restaurant menus with dietary information are just a few of the applications that will change rapidly.

It is only a matter of time before this creeps back into commercial building energy management. The predominant building system middleware is already built on OBIX. Digital signage everywhere can provide energy management platforms everywhere. The old model of long-term lock-in may fade. Buildings will adopt new apps if the old ones do not perform as they like. Will there be Freemium Energy Apps?

The Announcement of Public Review for five OBIX Specifications ending February 14, including instructions for submitting comments, can be found at:

Events	Want Ads
Our Sponsors	Resources