Resource Frameworks for the Internet of Things

The first wave of the Internet of Things (IoT) was widespread but disorganized. SCADA operated nearly every industrial process, and was proprietary and the network rarely left the building. Power grid sensors and telemetry, if available, only extended to the substation. Home Security systems bundled sensors and a hardware-based app to provide fixed functionality. Building systems moved slowly off of pneumatics and onto digital controls. Hobbyists built apps on X10, but they enjoyed the making as much as the function. Over all of them, security was non-existent.

The second wave was the Internet of Sensors—thousands and thousands of sensors. These sensors were typically carefully placed. The meaning of the sensors came from the deliberate placement and recording of metadata.  Some of this was encoded in SensorML, but few sensors could describe themselves.  There were limited if intriguing demonstrations of sensors that could describe their locations, typically in the interoperability demonstrations of the Open Geospatial Consortium (OGC). Wearable sensors were identified types that gained meaning through the person that wore them.

During the second wave, the low level descriptions were standardized in some domains. BACnet and LON and KNX identified standardized communications in buildings.  OPC, which began as OLE for Process control, matured into more robust protocols. OBIX normalized the base of communications to read, change, and interact with control systems. Higher level vertical smokestack ontologies such as MIMOSA saw limited acceptance.

The second wave began to transition to the next wave with efforts to homogenize systems and guide them through central control. One-size-fits-all cloud applications were the standard. The energy Standard Energy Profiles (SEP) treated all home systems as commodities, with identical energy use and minimal involvement of those who owned the systems. This created its own risks, as the fan and ducts for fume hoods, office cooling, and biohazard labs are all identical form distance. In homes, these were unpopular because most people do not want to cede control over their personal spaces and possessions to third parties.

The third wave will be built on Apps of Things, and ontologies based on composite semantics of sensors. The pervasive availability of the AllJoyn platform, as multi-platform open source, and now as a core component of Windows 10 will enable the wide development of Apps for Things. The Smart Television Alliance will soon bring its own App platform into consumer electronics and smart phones. The larger applications already in existence, for large building operations and the like, will gain some App characteristics.

Apps, as we know them on our smart phones, can be thought of as re-collecting and re-purposing feature sets for novel purposes. You may have a dozen apps on your phone that make use of the GIS functions and the SMS functions available. A sensor on a system component of your Smart Kitchen App may be used by an Aging at Home App to alert near-by relatives. Smart laundry systems already sends text when you can move clothes to the dryer. Smart EV chargers with their own storage may plan their strategies by consulting other Apps in the home.

More and more I think of Apps as the Device Drivers for the Internet of Things. My first commercial microcomputer app was a bubble sort that incorporated explicit memory mapping, explicit disk IO, and even disk head activity into a single hot mess of assembly code. It was a great relief to let the disc activity go as we got enough memory to support drivers, and later to stop moving blocks of memory around within business code. The first SCSI drives moved the disk IO out of the CPU and onto the device. RAID controllers are Apps that manage both IO optimization and fault recovery. Today the IO is off on network attached storage, with the technology optimization incorporated into the storage service. There are some conversations about using transactive frameworks to manage multi-application and multi-system allocation of storage services.

A growing challenge of overall efficiency is managing the interactions between these quite different Apps. A highly efficient dishwasher may reduce an instant hot water heater to the inefficiency of a peaker plant. Resource smoothing is of growing importance, not just for electric power, and not just to incorporate distributed energy. Resource frameworks, at the App level, can be a big part of that. This is why the Energy Mashup Lab joined the AllSeen Alliance—the cross-industry group pressing for wide adoption of the AllJoyn platform.

I will write more about the resource frameworks, from smart energy (EMIX) to the BIM for O&M (COBie), from UNITY to the Classification of Everyday Living (COEL). Come and see me at TechIntersection in Monterrey, California in mid-September (http://ow.ly/QSKGp), use my code CONSIDINE for a $50 Discount.

The Great IoT Roll-Out

Today, is the largest roll-out of an open platform for the Internet of Things ever. So you have to be thinking, “How does this change my plans”

Today, millions of users are installing a securable open source IoT Platform. Users of Windows 7, Windows 8, and Windows 8.1 are eligible for free upgrade to Windows 10. Windows 10 includes an AllJoyn server as a core service.

The developers of digital controls in buildings have long been pioneers in the Internet of Things (IoT). For a long time, a strong concern was how to keep these systems off the Internet, especially as the level of security in these technologies was so poor. For the home hobbyist, the IoT began in with the release of the X10 protocol in 1975. X10-based systems were only embraced by hobbyists, because unless it was your hobby, you would never tolerate the drudgery and significant weekend time to configure and operate your systems.

Despite all the buzz, the IoT has been a confusing mass of non-standard protocols and custom applications. In 2011, Qualcomm presented AllJoyn as a common framework for interacting with the IoT. The code was later open-sourced and presented to the Linux Foundation. In 2013, the AllSeen Alliance was formed to encourage adoption of the AllJoyn platform.

The AllSeen Alliance is more than startups and communications companies, although there are plenty of those. Old line computer companies such as Microsoft and Lenovo are members. Building centric companies that shun open source, such as Honeywell are members. NREL has signed on. By now, each of your customers has probably installed some AllJoyn in a building.

AllJoyn complements the Message Queueing Telemetry Transport (MQTT), and open source bridges between the two are available. While AllJoyn is designed to handle discovery and message transfer over a proximal [local] network or local network. AllJoyn interfaces can support need from control applications to media streaming. MQTT is a publish/subscribe framework in which a MQTT broker acts as a public IP addressable node. Publishers and subscribers connect through the broker. MQTT was designed for remote monitoring and control for most part. Most deployments of MQTT deployments use WAN network atop cellular technologies.

Last week, the OBIX Technical Committee voted out OBIX 1.1 to what I hope is the final public review. The focus of the entire effort was improved interoperability of different code-bases through more abstract formal information models. Standardized encodings enable easy and accurate exchange of messages from XML to JSON, the protocol of choice for today’s web developers, and COaP, a newer protocol appropriate for very large sensornets.

All this get especially interesting when you consider Bindings rather than Encodings. One of the new Bindings defined in OBIX is WebSocket. The Smart TV Alliance has embraced OBIX encoded in JSON and bound to WebSocket as a means to communicate between consumer electronics. To a growing degree, MQTT is being used as a lighter weight, higher performance variant of WebSocket, with binding gateways also available in Open Source.

We now have some standards that stir the pot in a way the pot has not been stirred for a while. With wireless network companies supporting the AllSeen Alliance, we may soon see the open source AllJoyn as an option on your home router. A home router is a natural gateway between a proximal network and a Pub/Sub network. Less open solutions such as ZigBee will need to re-position themselves.

Larger systems using formal controls schemas, and probably OBIX, will soon look to AllJoyn as a way to extend their situation awareness. Natural bridges between the Consumer Electronics Association with the Smart TV Alliance platform and AllJoyn-based applications come from compatible bindings, compatible encodings, and open standards.

What will really turbo-charge this is the cross-platform development environment that comes with Windows 10. It can come as no surprise that Microsoft is releasing DotNet development tools for AllJoyn applications. ROTOR has long supported DotNet on multiple platforms, but support for the advanced development libraries that make DotNet so valuable on Microsoft platforms has been spotty.

This changes with AllJoyn component on Windows 10. Each version of the pre-production DotNet AllJoyn library has been released on the same day for Windows, Android, and IOS. At the end of June, 2015, the high-touch Microsoft development environment is now available to for all three platforms in all DotNet Languages.

Building system programming has always been isolated, and not really up to consumer and corporate expectations. The bar is now raised. Time to polish up your your IoT plans.

Smart TVs, OBIX, and your next Commercial Building

As regular readers know, I have been caught up in the production of OBIX 1.1 for most of last year. OBIX has world-wide use in niche locations. It has open source platforms. They do not interoperate as well as they might. To improve interoperation, and ti improve telemetry, we started work on 1.1. Then the Smart TV Alliance upped our game.

But first, a little about how 1.1 is shaping up. We broke oBIX up into smaller pieces, to make it simpler for a programmer to tell what rules they are using. With smaller pieces we can more easily say “An Application conforms only if…” This makes interoperation of different platforms much more likely.

By last May, we had isolated the core information model and interactions (OBIX 1.1) and separated out Encodings and Bindings. We added features to support large data-set telemetry. We added the capability of adding metatags to points, to support semantic sets such as Haystack and BIM. We specified Common Encodings for OBIX (XML, JSON, COAP). XML is the original encoding. JSON is much beloved by current web developers. COAP, or the Constrained Application Protocol, is on track to be the recommended communications platform for the Internet of Things. COAP is designed to translate HTTP down to the level of constrained and lossy communications. We also developed two binding specifications: REST and SOAP. The REST binding formalizes what Tridium has long provided. The SOAP binding is typified in the multi-tiered architecture used by ETSI projects and by products such as Energle.

These formal encodings and bindings make it easy to tell what the other side expects. A typical web page might integrate with a server that uses the OBIX 1.1 model encoded in XML and bound with REST.

Then I received email from the Smart TV Alliance. They liked what we were up to, but wanted us to add a Binding for WebSocket (RFC 6445). That was easy enough to do—which is why we went to the multi-part format described above. WebSocket provides for full-duplex (two-way) communications over an HTTP connection. WebSocket is a standard part of HTML5, so you are probably reading this in a device that supports WebSocket already. The 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 eclipse plug-in to write once, run everywhere.

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

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.

But that is before we consider WebSocket and OBIX. The Alliance assumes that WiFi is available. The first add-on application that comes to my mind is the smart home theater. This requires communications with lighting and with sound systems and other consumer electronics. (In possibly related news, Apple, not a member of the Alliance, pushed through an RFC draft for aggregated service discovery to support their televisions.) Mobile internet provider Obigo brings the Alliance into smart phones and PDAs. I wonder what applications will be built based on dynamic interactions between phone and television. Is this the end of hunting for the remote?

From there is it a small hop to communicating with the WiFi enabled thermostat. This is sure to intensify sparring between Honeywell’s WiFi 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, using existing infrastructure.

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 is part of this picture.

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. Buildings will adopt new apps if the old ones do not perform as they like. Will there be Freemium Energy Apps?

Only time will tell, but it should be a wild ride for the next few years.

The Taxonomies of oBIX

Note: Niels Bohr famously observed that prediction is very difficult, especially about the future. Getting down into the technical weeds of a specification that is not yet complete is also difficult. I received numerous requests to explain how Haystack fits into future versions of oBIX. OBIX is a specification whose development is in mid-flight. OBIX 1.1 comes out for its first public review in July. The enterprise wrapper for oBIX, aka oBIX 2.0 is months away. Perhaps some readers here will join and help us get to the final form faster.

OBIX does 1.1 not require or support Haystack. OBIX 1.1 will not even mention haystack, except, perhaps, as an example. OBIX 1.1 will be able to provide metadata for any point. That metadata may be drawn from any formal or informal taxonomy. oBIX 1.1 does not define how taxonomies are applied to an oBIX server. Haystack is useful taxonomy of growing popularity that can be used to provide metadata about any oBIX point.

Haystack is a taxonomy that describes a lightweight building information model (Slim BIM) for BAS systems. Haystack tags are unique in that they were developed as a folksonomy, i.e., through an informal consensus among users. Haystack advocates may point out that all the formal taxonomies once created to classify internet searches were beaten by the automatically generated folksonomy at the heart of the Google search engines. Traditional large BIM models provide taxonomies developed through formal processes and often mandated by national agencies; metadata in oBIX can be the entry point into Big BIM. OBIX is taxonomy agnostic, and can support both, or either.

Interactions with an oBIX server begin by entering the “lobby” and asking for information about the system. One of the new inquiries in 1.1 will be “Which meta-information standards do you support?” A valid answer is “None”. For backward compatibility, an error message, from an oBIX 1.0 server that does not understand the question must be interpreted as answering “None”. If the oBIX server supports one or more meta-information standards, it will name them. We have not spent much time on the Lobby inquiries yet, but I think this answer should include a local tag, a URI for each taxonomy, and an optional URL for queries based on that taxonomy. Those queries are a subject for oBIX 2.x.

Under oBIX 1.1, a client can query a point for its metadata. The oBIX server returns a collection, with each element including a tag identifying the element’s taxonomy, and the metadata information. If some of that metadata is based on Haystack, then the returned metadata information may include one or more Haystack Tags. The same set may include elements drawn from other taxonomies. It is not hard to imagine a single BAS gateway that supports a Haystack, EMIX (Energy Market Information Exchange), Tenant Information, and situation awareness / security.

There are many taxonomies for building systems already in wide use. Walmart and Target, two companies that have unusually complete construction and commissioning specifications, have long mandated the use of specific tagging standards. The Intelligent Kitchen standard, promulgated by McDonald’s could specify a meta-information specification. Many use oBIX to interact with control systems that have nothing to do with BAS. Groups such as OPC, used widely in industrial scenarios, have their own taxonomies. SensorML, a standard developed by the Open Geospatial Consortium (OGC) is widely used for scientific observations and for situation awareness; SensorML provides a taxonomy that can easily be applied to oBIX points.

Every taxonomy is the outward manifestation of an information model. Haystack assigns responsibility for assembling a building’s specific model to the client. The client must assemble the sum of all the tags, and follow all the references, to create a coherent model of the systems exposed. There will be many incomplete models generated from BAS gateways that are badly integrated or commissioned. To enable a client to query the model directly, the server itself must have a model. Model-based queries are part of oBIX 2.x and have no place in oBIX 1.x.

Not all BAS systems need to or will incorporate model service or even meta-information. It is easy to imagine an information appliance that acts as the model holder for an underlying metadata-free [BACnet] system. Such a system would provide direct access to the points in the underlying system, and offer up the meta-information provided by the taxonomy. There might be advantages to setting these up as audit-servers unable to interfere with the underlying control operations. A standards-based BIM server, serving up BIMSie, may be an example that brings such systems into conformance with DOD and EU expectations without requiring re-development of the underlying control protocols.

We should resist the impulse to develop the one, true, absolute application model for all time, and baking the taxonomy that represents that model into every low level protocol everywhere. What we should do, is develop standard lamina, layered information models that live outside the work of an individual integrator, but provide higher level access that increases the value of the initial integration.

Consider a microgrid consisting of a green building, and an oBIX serving using Haystack to describe its underlying systems. Alongside could be an oBIX server managing solar generation, and another managing private wind farm. The oBIX gateway to these distributed energy resources could support SensorML-derived tags, useful to describe the weather and environmental data gathering that best predict energy generation. All three systems could also support the EMIX taxonomy to describe the energy supplied as well as the energy used in the green building.

oBIX works with collections of points named Contracts. Within the simpler taxonomies, one can imagine building a contract to include all points with a given tag. A more interesting query might leverage the model in the taxonomy; for Haystack, this might include all temperature sensors on Air Handlers with a relation to a given chilled water loop. Some queries will not be answerable from a single interface. An external BIM server might be the appropriate way to build a query against a more complex taxonomy. Such queries are out of scope for oBIX 1.x; we intend to define a model for such queries within oBIX 2.0.

The most interesting contracts will be built from querying two or more taxonomies at the same time. Look to a generic query language for both intra- and cross-taxonomy contracts in oBIX 2.x. We have some ideas on how to do this already, but that is much, much deeper in the weeds then I want to go at this time.