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.

RoSy outlook for distributed autonomy within systems

I feel I must be one of the last people to discover the open source Robotic Operating Systems (RoS). RoS is more of a framework than an operating system. The framework could be atop any operating system. In practice, for now, it is on Linux. (There are some interesting DotNet / Mono extensions, but those appear incomplete). ROS is providing the base for open source robotics, and the effect of robotics on all our lives will expand because of it.

RoS engages my imagination because it is inherently distributed. “Service Oriented Robotics” as a phrase that is used. Replacing the step-by-step commands that have ruled robotic manufacturing, ROS developers aim at tasks such as “Go upstairs, go to my room, find my stapler on my desk, and bring it back”. This must be decoupled into applications for climbing stairs, navigating a floor plan, identifying a stapler, and picking that stapler up.

Just as smart energy looks to fractal dis-assembling of power grids, RoS looks to fractal dis-assembly of robotic tasks. There are multiple ROS services for a robotic hand, decoupling the technology and the mechanics from the request. As ROS-capable systems get smaller and cheaper, there will likely be RoS applications for each knuckle on a hand. A RoS-enabled knuckle can more easily incorporate advanced features such as haptic feedback leading to a “gentle touch”. Gentle touch and heavy lifting can be different limbs responding to the same command.

Robotics is outside of my wheel-house. Service enabling of the internet of things is in. Service oriented energy is in. Fractal microgrids as described by the Galvin Initiative seem natural, and they will have their decision-making local, where they can respond to the needs of site, and the owner, and the situation.

Robotics started out with fixed activities under direct control. In the larger systems, one can still see the single control even as they grow more autonomous. The future is distributed service oriented robotics. In the same way smart grids started with planned sequence to control transmission. It evolved into fixed sequences to control energy consumption, centrally operated, by OpenADR and by EnerNOC and by Constellation. It is slowly evolving into centrally orchestrated DR services.

Even Microgrids are often simply the old architecture, and the old protocols, but just a little bit of isolation. Duke is pushing microgrids barely distinguishable from their distribution networks. Oncor salutes service orientation while extending the old technologies. The real advances are among those building those “smart hands”, autonomous microgrids that make their own decisions and technology choices. >Eventually, just as in the smart knuckles, the same service orientations will arrive in the end appliances and systems of the end nodes.

When I was young, in my Dinosaur age, I was fascinated by the Stegosaurus, and its hind-brain bigger than its fore-brain. That was settled science then, although controversial now. I enjoyed imagining a slow placid creature able to defend itself with some nimble, precise tail-bludgeoning.

The microgrids of the future will leverage distributed energy and local storage to for some precise tail-bludgeoning in the smart building—the far away head will not even be sure what is going on.

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.

Smart Energy with a little bit of Seoul.

My visit to Seoul this month was fascinating. The country of Korea built its infrastructure essentially from scratch in the last 50 years, and in doing so was able to use modern technology to challenge some fundamental assumptions that we make in the USA. IP-based telephony predominates based on pervasive free Wi-Fi. Custom tailors use radical outsourcing mediated by IT to provide near-instant services. The National Virtual Power Plant (NVPP) is as up-to-date as any, while using big-data tools in ways not often seen here. There is a desire to embrace the new without fear that seems young and fresh in the way the US often does not. But somehow, the single observation that stays with me is how the use of IT to challenges our assumptions about natural monopolies.

The Seoul Metropolitan Subway system is by far the best I have been on. The signage is unusually good. Many stations have large interactive maps. Every car has digital signs that display the next station in multiple languages. Music plays on the platforms to warn of each impending arrival. In the winter, automatic seat warmers make even the ride itself pleasanter than expected.

The fare system is seamless. The system pioneered in Seoul is now used in many US systems: a card, a wave in, and a wave out, and a charge based on beginning and ending stations. The systems to add money to your fare card will tell you the remaining balance instantly, without inserting the card, or needing to punch buttons. Unlike in the US, every station has prominent stations on which to drop your card and get cash back. The $0.50 deposit on the card itself is just as easy to get back. There is even competition for these cards as three subway cards, one credit card, and several debit cards can be used interchangeably with your transit card. In short, it is customer focused, consumer friendly, and feels like anything but the bureaucratic experience it is in the US.

The high-tech experience extends into the amenities as well. Subways in the US are often dead zones. In Seoul, each line provides choices of digital connectivity: 4G, WiFi, DMB, and WiBro. This supports the widespread use of IP-telephony in Seoul; without the legacy commitment to lines, almost every smart phone uses the almost universal WiFi. (More on that later.)

All of this is supported by an easy to use App, one that puts the well-regarded BART App to shame. The free App, available for all the usual platforms, works out routes and provides station by station information with precise departure and arrival times. The cost for each route and stop is computed and displayed in advance. A potential rider always knows whether to rush, and when he will arrive.

In the US, this would all be delivered through a semi-private agency, a Transit Authority. In the Seoul, the nineteen subway lines are built and operated by ten separate companies. Some routes may have a higher cost per kilometer, or per station, but that information is readily available before your ride. Fares are automatically allocated to the different companies based on the same services that compute the entire fare. With appropriate use of IT, the multi-vendor service is provided as if through a single provider.

Regular readers may recognize that this is the model of Transactive Energy.

The Seoul Metropolitan Subway system tears down assumptions about how natural are our regulated natural monopolies. To someone who considers the smart grid, it stirs re-thinking of how we consider last mile distribution in a distributed energy world. Just as South Korean phones use the connectionless protocols of the internet to avoid considerable high-cost build out of telecommunications infrastructure, transactive energy and distributed energy can provide better service at lower costs.

To gain these advantages, we must embrace the distributed multi-supplier business models that enable them. Trust capitalism. Embrace minimal market design to limit friction when changing suppliers several times a day if desired. Use IT to smooth any bumps in transition. I’ve written about this in papers on microgrids and autonomous power nodes. It was nice to see it in the field.