Interoperability issues on the Internet of Things
Just as microscopes let humans discover bacteria we could not see with the naked eye, the technologies behind the Internet of Things and big-data could help us "see" new realities. But to enable such vision we need ideas for how to overcome some interoperability issues.
The assumption that "things" are connected via sensors to networks is common these days. Indeed, factories have been highly instrumented for many years, but if we examine supply chains more closely we often lose visibility of products and processes precisely because of challenges in connecting to networks, which increasingly are wireless.
The Auto-ID Center at MIT developed a set of specifications for passive RFID wireless data collection systems at UHF frequencies, working with sister labs at Cambridge University, St. Gallen, Fudan, Keiyo, the University of Adelaide, and Kaist. The specs were licensed by GS1/EPCglobal, the worldwide association of all manufacturers.
The specs include a serialization scheme for uniquely identifying objects that has been widely adopted in the electronics industry and is spreading to other industries. Other wireless techniques to connect things include specifications at low frequency, high frequency, WiFi, Bluetooth, ZigBee, and UWB frequencies and protocols.
In addition to being able to "see" things remotely, it would be nice to add telemetry data to these transport protocols. Such data could tell us for instance how hot or cold, or how wet or dry objects are.
We could use diverse sensing techniques to measure physical, chemical, and biological qualities. For example, we could monitor the condition of bacteria, using various mechanical, optical, semiconductor, and biological sensors.
Unfortunately, there are very few common sensor specifications, especially for embedded systems that aim to minimize cost and power consumption. As a result, one hospital is running more than 90 network monitoring systems to validate, calibrate, and monitor medical devices and still has poor visibility on network interference, a hospital executive told me recently.
If we seek to add Real-Time Location Systems data to in-building wireless tracking systems using the WiFi standards, we run into similar interoperability issues. While we can all connect via laptops to wireless networks anywhere in the world, the minute we ask "where" a device is using the 802.11b in-building wireless protocol, we are restricted to proprietary triangulation algorithms that restrict interoperability of active RFID tags. In ad hoc networks such as 802.15.4, we have the same difficulty of connecting higher level functions of the protocol with devices from different manufacturers.
As a result of this lack of interoperability, every time we add a new telemetry device to a wireless network, we have the n2 problem of having to customize interfaces to every other device on the network.
US hospitals adopting electronic health records feel the negative effects of such fragmentation. In order to comply with government requirements, they must find ways to import data from hundreds of different proprietary medical devices. The only way to accomplish this today is to purchase connectivity middleware from third parties.
One way to address this issue is to create a lightweight, low-power layered network protocol, similar to IP, for granular data transmission and overlay protocols for control signals on it. 6LoWPAN, Z-Wave, and Ant represent attempts at gathering manufacturers together around such a common architecture.
Another approach is to create a lightweight set of API's for sensors. Kang Lee, who leads sensor research at NIST, proposed in a 2009 book (RFID Technology and Applications by Cambridge University Press) using the IEEE 1451 specifications for a common set of commands for all sensors, with little industry uptake.
In response to my previous blog, Laurent Liscia, president of OASIS, suggested that group's Message Queuing Telemetry Transport (MQTT) "might provide a lightweight publish/subscribe reliable messaging transport protocol suitable for communication in M2M/IoT contexts where a small code footprint is required and/or network bandwidth is at a premium."
What promising developments for unlocking data from remote wireless sensors do you see?
This article was previously published on EETimes.