Helping Things in the IoT speak the same language

We need to build APIs for Things that are interoperable — we need an application layer for the IoT.

Register for our free webcast “Building IoT Systems with Web Standards,” which will be hosted by Vlad Trifa and Dominique Guinard on December 8, 2015, at 10 a.m. PT.

Magnetic-core_memory_close-up

When the term “IoT” was first coined, the idea was to move from a model where data is generated by humans bridging media gaps between the physical and the virtual worlds to a model where data is gathered by the Things themselves.

Fifteen years later, we’re moving in the right direction to make this a reality, but we still have several challenges ahead. One major challenge is interoperability: many Things do talk using the Internet, but they don’t talk the same language. Having been involved in the IoT for about as long as it’s been around, I’m pretty sure of one thing: a universal networking protocol for the IoT will never exist — and for a good reason! The IoT is a vast world where the needs of one field (e.g. Industry 4.0) to another (e.g. the smart home) are fundamentally different. As a consequence, the list of automation protocols is actually growing, not shrinking.

A consequence of these different needs is the focus on the connectivity aspect of the IoT. This is not unusual, but as we ascend the pyramid of IoT needs, we must think about the data interoperability of Things. We need to build APIs for Things that are interoperable; in short, we need an application layer for the IoT.

Why? Let’s look at a simple example: a smart hotel. The hotel owner would like to digitally connect the appliances in all the rooms of the hotel. This gives guests access to a variety of services, from controlling their room (lights, air conditioning, entertainment, etc.), to booking hotel facilities, to ordering food and drinks — all from a mobile phone. This would also enable the owner to coordinate and optimize all aspects of the hotel (e.g. energy consumption) in a centralized and efficient manner, without having to use a variety of siloed applications and tools.

Building a smart hotel system will likely require electronic door locks made by one company, security cameras from another company, and a control application to manage all of this made by yet another company. Making these devices and systems talk and work with each other will require a lot of custom system integration work. The hotel owner likely will have to contract a specialist company and spend well-earned savings on a substantial project that will take months to deliver. Why? Because of the lack of a common application layer.

The best example of interoperability at the application layer is the Web. The Web made the Internet successful by creating an open, simple, and highly interoperable layer where data can be exchanged between servers and consumed by applications. I believe that technical details about how physical things talk to each other over the Web will make a massive difference to whether or not the IoT realizes its true vision, or becomes a complex mesh of proprietary or semi-proprietary standards.

Together with my colleague Vlad Trifa, we have been promoting this approach for more than a decade now and call it the Web of Things. This approach also underpins the IoT platform of the company Vlad and I co-founded: EVRYTHNG; these principles have been applied, and the platform deployed in the wild to connect millions of products, from bottles of whisky or soda, to smart plugs and lighting systems. The core of the Web of Things approach is quite simple: re-use Web standards to build the APIs of Things.

iot-vs-wot-sized

Image courtesy of Dominique Guinard and EVRYTHNG.

There are many areas where the Web can help:

  • REST and its Web implementation: HTTP helps us structure and create APIs for Things. Why should actuating a device be more complex than sending an HTTP PUT request to it?
  • WebSockets for real-time updates: One of the issues of HTTP is the request-response paradigm, which does not fit the sensing and monitoring use cases of the IoT. Here, WebSockets can help: why should monitoring the humidity level in a room be more complicated than subscribing to a resource via WebSockets?
  • JSON: Why should the data format of Things be different than the de facto standard of Web APIs: JSON?

There are a lot more Web tools to leverage to build the application layer of the IoT, such as those for security (e.g. TLS, oAuth), semantics (e.g. JSON-LD, RDFa, Schema.org), or to create composite applications (e.g. Mashups).

As the Web embraces the IoT (and vice-versa), the IoT will also influence the new developments of the Web. For instance, the recently approved HTTP/2 standard implements a number of improvements directly impacting the IoT. CoAP is another example: a protocol for low-power Things inspired by Web patterns that can be translated to HTTP and WebSockets. These are steps in the right direction.

Standard Web protocols: Things will be accessible, but still isolated

However, just as Web APIs created thousand of isolated Web silos, a Web of Things where we only agree on using the same protocols creates accessible silos, but still silos of Things.

The next step toward true interoperability is to go beyond the protocols and look at common syntax and semantics for Things. This is the gap that platforms like Google/Nest Weave, Apple HomeKit, and the EVRYTHNG API are filling: they integrate via Internet protocols at the network layer, Web protocols at the Web layer, and define the models and semantics of Things.

We are at a critical turning point in the development of the IoT, and relying on commercial de-facto standards can be detrimental to consumers. Independent institutions like W3C are essential to balance individual commercial agendas, ensuring that the IoT moves from a complicated maze of disjointed standards to an open, universal Web-based system. I love what the power of the World Wide Web has helped our societies and economies achieve so far, and believe it makes all the sense in the world to take the same approach with the IoT.

To address this need for a Web-based approach, EVRYTHNG, alongside partners from the COMPOSE Project (with members from IBM, W3C, Barcelona Supercomputing Centre, Fraunhofer Institute, and other universities), has authored an official W3C Member Submission called the Web Thing Model, graphically represented below. This submission contributes to the pre-standard work around the Web of Things at W3C within the WoT Interest Group.

WEBTHINGS-sized

Image courtesy of Dominique Guinard and EVRYTHNG.

Guidelines for RESTful APIs of Things that speak the same language

The submission starts by providing guidelines on how to implement RESTful APIs for Things. It also discusses different integration patterns (Gateways, Cloud, Direct). On the semantic level, we focus on five simple constructs as illustrated below:

  • Things
  • Models
  • Actions
  • Properties
  • Subscriptions
wot-resources-sized

Image courtesy of Dominique Guinard and EVRYTHNG.

Things are the physical objects. They are semantically described by simple Models based on the Web Linking standard, and semantic extensions using JSON-LD are supported. This allows a Thing to extend its description using a well-known semantic format such as the Schema.org Product schema. Using this approach, existing services like search engines can automatically get metadata about Things.

Properties are the variables of a device, such as location, temperature sensor ready, or state. These are meant to be changed by the Things themselves (or by a gateway / cloud). Properties can be observed by clients using push mechanisms such as WebSockets or WebHooks via Subscriptions.

If an external application wants to change the state of a device, it must do so by sending Actions to the device — for example, lightState, garageDoorState.

The Web Thing Model also provides guidelines on how to implement these constructs using Web standards, focusing on HTTP and WebSockets. However, it could also be applied and used with other application protocols such as CoAP or MQTT.

While this submission is not yet a standard, we hope it will bootstrap the discussions in several areas:

  • The need for independent and open standards: do we want the future of the IoT to belong to a handful of players or to be a space where open innovation is possible?
  • Reusability: do we want the application layer of the IoT to be built from scratch, or do we want to leverage, adapt, and evolve the omnipresent World Wide Web?
  • Semantics: how far into the world of ontologies do we have to go to create sufficient machine-to-machine understanding to implement the automatic and spontaneous compositions the IoT has long been dreaming of? Can the semantic Web help there, too?

No matter the outcome, these discussions are what we are looking for to finally implement the powerful vision of the Internet of Things.

Image by Jud McCranie on Wikimedia Commons.

tags: , , , ,

Get the O’Reilly Hardware Newsletter

Get weekly insight and knowledge on how to design, prototype, manufacture, and market great connected devices.

  • ianlee74

    I’ll read this a little slower later tonight but in my brief scan this appears to be very much like the AllJoyn protocol which already has a large backing from many companies and I believe covers all your scenarios and more. If you’re familiar with AllJoyn, I’d enjoy hearing your explanation of the differences.