Last week at the inaugural IoT Slam® Live, Internet of Things conference, OCF member and Principal Architect of Emerging Technologies at Shaw Communications, Clarke Stevens outlined the need for developers to have a common “language” to ensure interoperability in a presentation called Developing for the Interoperable Internet of Things. We have excerpted some of his presentation here.

The technology and implementation in the Internet of Things doesn’t really account for much unless the devices across different ecosystems don’t just work together – they must TALK to each other to work together.

But for any developer, how they talk together is a challenge. Which language? How many languages does an app or service need to understand?  For most developers, that’s not a simple question to answer because for a generic IoT application, as innovation happens, there’s always one more device it could potentially talk to; one more language it could potentially understand.

Wouldn’t it be nice if everything talked one language?  If the developer could focus instead on the more innovative aspects that are really going to add value?

That’s the goal of OCF – create one language for the Internet of Things. One language to talk to the Internet of Things.  One language to talk about the Internet of Things.  One language regardless of the underlying radio of lower-layer protocol. The language of the Internet of Things should be the same whether it’s on a home Wi-Fi network, a Bluetooth connection, or between Cloud services.

As with any language, there are some fundamentals that must be included, such as grammar to establish the fundamental rules of how things are put together to make sense; words, or the things that you put together according to the rules of grammar; and sentences, what you end up with when you put your words together. All of these combine to form a language to help us all understand what someone else is trying to communicate

OCF is building the grammar that will make up the IoT, ensuring that all the communication across devices or platforms makes sense.

The grammar of OCF is it’s Resource Model & Interaction Model. The Resource Model defines the format of OCF’s fundamental particles, which are called, entirely unsurprisingly, “Resources.”  Everything in OCF is a resource.  A temperature sensor is a resource.  A temperature setting is a resource.  The ubiquitous light bulb?  Resource.  If you dig into the details of OCF security, you’ll find credentials stored as resources…and access control lists also stored as…resources.

OCF also contains an Interaction Model…defines how you interact with a resource.  And by “you” I mean any application or service…running on any device.

OCF also defines ways to describe common types of data.  A binary switch; temperature; acceleration; blood pressure.  There are standard Data Models for all these things and many, many more.

For actual communication the Data Models combine with the Resource and Interaction Models to describe actual devices and allow them to communicate.  And again: this architecture is designed for consistency across multiple device types – from small sensors to Cloud services – multiple OSs and platforms, and across many different vertical markets.

By defining the components that make up a language that ensures interoperability, OCF is helping deliver the standard devices will use to not just connect, but communicate, and make the IoT a reality.