I am not sure who first coined the term “Internet of Things” (or, since everything technical must be an acronym, IoT), but I first heard it in the early 2000s. I thought at the time it had already outlived its usefulness. I thought the more mundane term “machine-to-machine communications” (or M2M, an even cuter acronym) was far better, and it appeared the market agreed with me, at least for a while.
However, the IoT is back with a vengeance, and this time the term is loaded with additional meaning that may be elusive. Early uses of the term conveyed the power of allowing “things” – ranging from vending machines to home appliances to building controls and sensors – to communicate with each other. The current use of the term implies much more: it’s not just that things should communicate, but it’s about how they communicate. Things should communicate like the Internet, with the capability of ubiquitous any-to-any communications. More specifically, they should accomplish this ultimate connectivity via the Internet Protocol (IP) or some relevant flavor of IP.
This more specific IoT understanding is attractive. The idea of open, layered protocols that mix and match physical media on the bottom of the protocol stack and virtually unlimited applications above them has been fundamental to Internet innovation. So all things being equal, all M2M communications should be based on IP. But all “things” are not equal and going all-IP is not necessarily free. Hence strict adherence to a narrow definition of IoT as being IP-based may hinder innovation more than it helps or at least imply over-hyped benefits that are rarely evident in the world of things.
Everything’s a Peer
One universe of things where this risk appears evident is in building automation and control systems. A true IoT implies that every sensor, actuator, thermostat, lighting ballast, and switch should be a peer IP-based communication node. However, these are rarely independent, intelligent nodes on a network, and rather elements of a specific subsystem (lighting control, HVAC control, humidity control, etc.). It’s highly unlikely that an occupancy sensor will ever need a software download to become something other than an occupancy sensor. So, top-of-stack application flexibility is not really a relevant benefit for these devices. The added cost in microcontroller memory and processing of supporting even a stripped-down IP stack in such a device may be higher than any benefit.
On the other hand, the situation of isolated, proprietary, non-connected subsystems that has been the norm in the building controls industry for about 100 years is unacceptable in the long run. There has been real, if gradual, progress in developing and applying reasonably open and interoperable building control networks using non-IP based specifications such as BACnet, though there are probably still too many such “standards” to choose from. Using IP networking and the application architectures implied by IP as the basis for subsystem integration and common network transport is not only a good idea but necessary for the continuing building systems evolution. Applying the IoT model to building controls, though, does not mean everything must have an IP address. This is similar to the difference between your laptop having IP networking and having the devices within your laptop – disk drives, video controller, keyboard, and so on – be IP-based.
So as we consider the IoT applied to our own universe of things, let’s be clear on how much Internet-ness we really need to pay for.
Tags: Smart Buildings Practice, Smart Grid Infrastructure, Smart Utilities Practice, Utility Innovations
| No Comments »