Making things interoperate

Last week the IP for Smart Objects (IPSO) Alliance released its Smart Objects Starter Pack (SOSP), the IPSO first draft on semantic Interoperability for the Internet of Things (IoT). This document, together with the existing Constrained Application Protocol (CoAP) RFC and the OMA Lightweight M2M specification compose the backbone of what the future of IoT can be like.

When the scale of connected devices grows to hundreds of millions of connected devices, interoperability will be what makes IoT open and successful, more Internet-like, as opposed to one or two individual companies’ playground. In order to provide such interoperability there is a need for service abstractions that developers can understand and use to create device applications-in fact you can already find some in XML on github. Those abstractions, or objects, are what IPSO has now defined.

Finding a set of reusable objects that are simple enough to act as building blocks for more complex data structures is no easy task. Since there are already examples of toasters, TVs and vacuum cleaners, we will take another one of the most common home devices: your washing machine.

Iot Home

Your washing machine already has quite many different sensors and actuators; humidity, temperature, water level sensors, water-valves (for the hoses going to to/from it), a pump, a timer, electricity sockets, a capacitor and what not. It also could include some simple software from the washing machine vendor.

In the future that washing machine could be connected to other devices or to a management system for functionality updates, status reporting or actuation. The washing machine could also have connectivity to your phone or for reporting any possible anomalies in the functioning of the previously mentioned components. At any time you could, for example, forecast whether some parts are about to break or not.

Let's say that the washing machine’s door lock is increasingly jamming over time. Your vendor’s management system will get periodic reports indicating that the lock is starting to malfunction. Since it gets reports from other washing machines of the same model with a similar malfunction, the vendor can analyze what the problem is and look for a solution. Once it knows the reason (the plastic lock is a bit too weak and bends too easily) it can send you a new lock even before yours actually breaks.

If the future APIs used by these devices would follow the same patterns and tools that developers find in today's Internet, from your phone’s browser you could use an open sourced HTML+JS application to manage your home. This app would warn you with interesting disaster animations how your washing machine is about to flood your home. All this without the developer having to know in detail how the washing machine is built.

In order to get there, standards have come a long way. First the IETF with CoAP that introduced the REST model to the Sensor Networks world. Around CoAP an increasing amount of entities for caching, resource discovery, proxying, etc. have appeared, along with the security protocols for them.

Then, using those structures OMA added a set of interfaces for the management of constrained devices. OMA LWM2M defined too the usage for UDP and SMS on the transport layer, as well as a simple set of objects and resources that simplified the existing OMA DM spec.

Finally we move to the present time, where IPSO is picking up the baton left by LWM2M and is focusing on increasing the amount of objects and resources in collaboration with hardware and device vendors.

Continuing with the example of the washing machine, we sadly do not have a “lock” object yet but let us use a temperature one instead. An object representing the sensor should report a remote temperature measurement. It should also provide resources for minimum and maximum measured values and the minimum and maximum range that can be measured by the temperature sensor. The units used by the sensor would be Celsius. Such object representation would also contain a Universal Resource Name (URN) that uniquely identifies that object type with an ID, its actual value being assigned by the Open Mobile Naming Authority (OMNA).

With those minimal components you could create the following object structure, the XML for which is already publicly available:

Once objects like these are available and standardized across multiple industries (so that all washing machines use the same objects regardless of the vendor) a device manager would start testing them, querying sensors and getting responses from them.

On our washing machine we would have one LWM2M client taking care of controlling its sensors. We could send a request for an IPSO Temperature Object on it (Req: GET /3303/0), the client would then return the following small JSON payload in the response (Res: 2.04 Content).

{“e”:[{
"n":"0", "v":"32",
"n":"1", "v":"30",
"n":"2", "v":"60",
"n":"3", "v":"0",
"n":"4", "v":"100"}]}

We could probably do something smarter with this technology though, like automatically ending the washing process, since knowing the temperature would not prevent the washing machine from ruining the parquet once the lock breaks.

Compare the simple example above to your favorite pick of legacy protocol for embedded devices where they usually are bloated with application dependent stuff. I think this proves a point when it comes to making devices simple and leave it to the large web developer community to come up with all the fancy applications we all long for.

Jaime Jiménez, Ericsson Research