Babel Buster Network Gateways: Big Features. Small Price.
The Open Building Information Exchange (oBIX) is a specification advanced by the OASIS international standards consortium to provide a standardized foundation for this M2M Web.
You’ve probably heard the term M2M or Machine-to-Machine applied to the building automation space. Really M2M is just about the inevitable march of technology and its ripple effect in our business models. Microprocessors continue to drop in price and pack more horsepower. Concurrently the Internet is becoming ubiquitous, especially with wireless technology making instant-on Internet access easy to install. Together these two trends mean that we can increasingly push software smarts and Internet connectivity further out to the edges of our device networks.
So how does the world change when our lowliest devices are sporting gigahertz processors and ubiquitous Internet connectivity? Often embedded systems can look to their desktop and IT brethren to see what the future might hold. Here we can attribute the explosion of the Internet to its driving application – the World Wide Web. The Web has profoundly changed how we publish and consume information. The Web itself is composed of a few simple but highly scalable technologies: URLs for identifying information on the Internet; HTTP to move data over the Internet; and HTML as a standard document format. Originally the Web was designed to publish information in HTML for human consumption. Increasingly information is published as XML for machine consumption. Given the pervasive installed base and mind share of Web technologies, it’s not hard to fathom what our future M2M world might look like. It’s highly likely that not only will all our devices live on the Internet, but they will all have their own URLs and HTTP server to publish information in XML – the M2M Web.
The Open Building Information Exchange (oBIX) is a specification advanced by the OASIS international standards consortium to provide a standardized foundation for this M2M Web. The oBIX architecture embodies three core principles:
Object Model: a common model for M2M data and services designed to provide high fidelity with vendor’s existing systems;
Contracts: provide the foundation for normalizing and tagging the object model with semantics;
Web Based: oBIX is built upon the core technologies that make the Web so successful today: URLs, XML, and HTTP.
The heart of oBIX is an object model and XML syntax for exposing M2M data and services on the Web. The oBIX object model is deliberately quite low level and domain independent. In fact it provides a level of abstraction more on par to the primitives of a typical programming language like Java or C#. Domain specific abstractions like points, alarms, and historical trends are modeled at a higher level with contracts - much like these concepts would be captured in a class library if using Java or C#.
Contracts are a unique aspect of oBIX designed to provide a mechanism for “tagging” the object model with semantics. A contract is itself an oBIX XML document used to define both semantics and structure. For example, the obix:Alarm contract defines semantics by saying anything that implements it must conform to the rules associated with modeling an alarm. It also predefines the structure of an alarm such as its timestamp, where it came from, and who has acknowledged it.
oBIX contracts are designed to enable open-ended extension of the specification without changes to the core object model and XML syntax. For example, alternate standards groups can build domain specific vocabularies formally defined as libraries of oBIX contracts. Additionally, vendors can provide contract libraries specific to their native systems. If successful, we can create an oBIX ecosystem that provides rich semantics across multiple domains.
oBIX is deliberately designed so that vendors aren’t required to build “native oBIX systems”. Instead oBIX embraces the concept of vendor extensions to promote creativity and differentiation without punishing vendors with impedance mismatch. We call this design goal “high fidelity” – vendors shouldn’t have to force fit their native system into some rigidly defined model dictated by a standards organization. Instead we desire oBIX interfaces to enable high fidelity with vendors’ native data models and features. In practice this approach actually enhances interoperability between systems because we start from square one determining how to encompass vendor-specific features instead of relegating them to second class citizens. oBIX achieves the goal of high fidelity through its design principles of a low level object model and contracts. Because the object model is deliberately designed at a low level of abstraction, there is very little impedance mismatch between oBIX and the primitives used to build systems with common programming languages. Because contracts can be mixed together, vendors have broad creative license to expose their native object models while simultaneously mixing in standard contracts.
Last but not least, oBIX is designed to leverage and mimic the highly successful design of the Web which exists today. This design is based upon URLs to globally identify documents, HTTP to move documents over the network, and HTML as a standard format for documents. Perhaps the most powerful aspect of the Web is that the combination of the HTML anchor tag with URLs has enabled us to wire all these documents together into what is effectively a unified repository for all human knowledge.
oBIX plugs right into the Web by fixing the only piece of the existing Web which doesn’t quite work for M2M – replacing HTML with XML. Instead of using HTML as the format for data, we use oBIX XML which is friendlier toward M2M data models and designed for machine consumption rather than human consumption. But we still leverage URLs to identity all our data and HTTP to move that data over the network. Most importantly we mimic the “web” aspect of the WWW with refs which are the oBIX version of HTML anchor tags. Refs allow oBIX documents to cross-reference other oBIX documents with URLs. Effectively this allows us to wire oBIX data together to create a global M2M Web. The M2M Web isn’t something new rather it’s just the extension of the existing Web into the M2M domain.
If this vision sounds exciting to you, then please join us as we build the oBIX ecosystem. The oBIX specification is soon to enter public review, and we really want community feedback to help us make it successful. For more information visit the OASIS oBIX Technical Committee at http://www.oasis-open.org/committees/obix where you can download the spec and learn more about how to participate in the development effort. Also visit http://sourceforge.net/projects/obix to download the open source Java oBIX Toolkit which is designed to help you incorporate oBIX into your software quickly and easily.
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]