By Patrick Mannion, Contributing Editor
In the rapidly evolving Internet of Things, technology vendors are working to agree on a data model that will allow millions of resource-constrained devices to connect and communicate usefully. In the meantime, designers of wearable devices — for fitness, medical, location tracking, building access, or other applications — continue to find themselves having to pick sides, reducing interoperability and restricting the usefulness of devices.
There are almost as many reasons not to be interoperable as there are to be interoperable, especially if a device needs to be ultra-low-power, as is the case for wearables. While interoperability at the protocol level lets more devices communicate with each other, the downside is a “heavy” protocol with too much overhead that tries to account for too many device types and usage models that take up too much memory and consume too much power during communication. It also adds cost.
For manufacturers, there are certain strategic advantages to be had by having a proprietary approach, including complete control over the interface, user experience, and security. Apple’s Home Kit is a classic example. For end users, however, the net result is a device that can perform its explicit function, such as detecting heart rate and perspiration levels, but can’t effect any change in the environment to help alleviate extremes because it may not be able to communicate its attributes to the already-installed climate-control system.
However, the advantages of interoperability for developers also include better future proofing of designs, an overall greater ecosystem of compatible devices, and better overall ecosystem support during the development stages.
This is not to say that that there hasn’t already been a substantial effort to achieve interoperability. The best way to appreciate how this is evolving is to look at the OSI and TCP/IP communications models (Fig. 1 ).
Fig. 1: While various interfaces have historically been incompatible, the IoT has driven interoperability at the network and transport layers around IP. Now the emphasis is shifting to defining data models for the application layer. Image source: Steve Iveson, www.networkstuff.eu.
While Wi-Fi is natively IP-addressable, common wireless interfaces like Bluetooth and zigbee had to work on it. Both now support IPv6 using 6LoWPAN for end-to-end IP support at the network and transport layer, as does Thread, which also emphasizes mesh networking and security.
The convergence is largely around constrained application protocol (CoAP) over user datagram protocol (UDP) using JavaScript Object Notation (JSON) and Concise Binary Object Representation (CBOR) compression. Unlike the more mature message queue telemetry transport (MQTT), CoAP supports both synchronous and asynchronous messaging. Also, it is a representational state transfer (REST)ful protocol for access to web services and supports data transport layer security (DTLS). Other characteristics of CoAP that make it attractive for low-power applications include a fast transmit cycle and fewer message types.
Compared to the older XML-dependent Simple Object Access Protocol (SOAP), RESTful protocols are lighter and can use URLs directly for web services. REST can actually use a number of verbs directly — such as GET, POST, PUT, and DELETE — to execute tasks.
All of these are good for wearable devices that need to communicate asynchronously with minimal fuss. However, having more or less solved the interoperability at the network and transport layer, the emphasis has now shifted to the application layer and the data model, which have not yet been agreed upon. However, the IPSO Alliance has set forth some fundamental application-layer requirements for a smart object in an effort to reach some level of consensus (Fig. 2 ).
Fig. 2: The IPSO Alliance set up some basic application-layer and data model requirements in an effort to achieve consensus so that smart objects can communicate more effectively. Image source: Centero.
As mentioned, Home Kit from Apple is one approach. Others include Google’s Weave, the Open Connectivity Foundation (OCF), Z-Wave, and the zigbee alliance has pulled its cluster of profiles together and overlaid it with dotdot to let IoT devices communicate independent of the underlying network. All address or are ultra-low-power, low-resource devices, from wearables to light bulbs, and attempt to define workable data models at the application layer that will help various devices to communicate.
However, there are a few things that need a clearer definition. One of these is how to describe an object and its capabilities, and it’s literally a matter of semantics.
According to Geoff Mulligan, founder and Board of Directors member of the IPSO Alliance, “Now it’s all about the data model, the semantics of the IoT data.” For example, if a temperature sensor on the wearable or in the room says “40,” is that hot or cold? Fahrenheit or Celsius? Does the device getting the number even know that it’s coming from a temperature sensor? “You can’t send an entire dictionary to say what 40 means and to say it’s from a temperature sensor,” said Mulligan. The trick is finding the data model that gives sufficient information about the smart object without going overboard.
From Mulligan’s perspective, the zigbee cluster library (ZCL) got the model wrong. “IPSO’s Smart Objects (SO) model separates the verb from the object; zigbee put them both together,” he said. For example, “ZCL puts 70 together with ‘set the temperature to,’ so you need more binding between source and destination. That binding creates a highly complex system that risks being unmanageable and inextensible.” Instead, IPSO SO sends out a message saying, “Temp is 70 degrees C or F,” and then the SO defines the context.
IPSO Smart Objects sits on top of the Open Mobile Alliance’s (OMA) Lightweight M2M protocol (LWM2M) and could run well over Thread (Fig. 3 ). However, it will be competing with dotdot.
Fig. 3: Thread is a well-defined and secure IP mesh-networking protocol upon which the application layer can sit. However, defining an acceptable, interoperable data model for the application layer puts zigbee’s dotdot in competition with IPSO’s Smart Objects. Image source: Centero.
“We want a system that is unbound to any lower layer,” said Mulligan. “IPSO SO would run fine over zigbee, but they are currently pursuing dotdot.”
At least dotdot and IPSO SO are making an effort to define an interoperable approach. Others, like LONWorks, is strictly proprietary and popular in building control systems. Then there’s Siemens and Emerson, which are also siloed. “Each defines the energy characteristics in a proprietary way,” said Mulligan. This provides classic vendor lock-in. “Wi-Sun is more open, but even many open standards have a closed set of data models, so you’re locked into their solution.”
A metamodel of models: Are you crazy?
The closed and siloed approach has many deficiencies. Among them, according to Skip Ashton, vice president of software at Silicon Labs, is that, from a user’s point of view, various devices are unable to interact and reinforce each other. From a developer’s point of view, the total available market for a device is artificially limited.
For sure, organizations are building bridges between networks, so a zigbee device can get on an Apple Home Kit network, but in general, its ability to scale is limited. Also, developers are wary of developing for a network that is so smartphone-centric and controlled by one or two companies (Apple’s Home Kit and Google’s Weave). An Apple Home Kit security system won’t talk to an Android door lock.
For the object model point of view, Ashton sees the numerous approaches collapsing to two or three, and he is biased toward dotdot on top of Thread. That said, he does wrestle with modeling in general. On one hand, he sees the need for absolute clarity in the descriptions of an object’s attributes, such as those associated with a light bulb. However, describing it too definitively impedes interoperability until such time as everyone converges on a universal description of, “What should a light bulb object look like as a canonical truth?”
Ashton has heard of a solution that might solve the conundrum: a metamodel of models. “Semantically, this takes it up a layer, and therefore, you can map all of them [other protocols] to it,” said Ashton. “This sounds good, but if I go to a light bulb or door-lock manufacturer and suggest this, they’ll think I’m crazy.” From their point of view, the metamodel of models only adds cost. The cost is small, but when they’re shipping millions, the pennies quickly add up. “So they don’t want to semantically model anything; they want it to be very specific.”
Conclusion
How the modeling of objects evolves over the coming years will greatly affect the efficiency and utility of wearable devices. Clearly, there are many approaches and good reasons for those approaches, but the work of the IPSO Alliance (Smart Objects) and zigbee (dotdot), while competing, may end up with a mutually beneficial solution that will help designers broaden the available market for their product designs.
Advertisement
