BlueRithm - Improve Quality, Accelerate Deliverables, Save Time and Money
OBIX, Smart TVs, and the Commercial Building
OBIX is a generic web service interface for control systems.
The New Daedalus
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
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
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?
So, what App will you provide? What App do you want?
The Announcement of Public Review for five OBIX Specifications ending
February 14, including instructions for submitting comments, can be
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]