Choose your preferred language

Friday, October 30, 2015

IoT Alphabet Soup

Posted by Candace Letizia

Seven years ago, I started working as a Technical Writer for Kepware. I brought grammar and technical writing knowledge and authoring software expertise to my role, and thought I was ready to dive into our library of product manuals. Little did I know exactly how long it would take me to learn the abbreviations commonly used within our different vertical industries. Understanding the different terms for systems, networks, and processes was one thing; mastering the different protocols—and discerning when to use one over another—was entirely different.

With the help of patient colleagues, technical resources, and time, I was able to create a foundation of knowledge that continues to expand today. As industry turns its attention toward the Internet of Things and Industrie 4.0, the abbreviations and definitions added to our language (and my Kepware dictionary) multiplies.

Luckily, there is less guesswork required this time around. A whitepaper by Aron Semle, Kepware’s R&D Lead, explores several IIoT protocols that are available for connecting industrial devices to IT and IoT platforms. With that last sentence using three abbreviations alone, it’s no wonder that he refers to the Internet of Things (IoT) space as alphabet soup!

IIoT, IoE, HTTP, REST, JSON, MQTT, OPC UA, DDS, and the list goes on. Conceptually, we’ve discussed IoT for a long time and understand the basic idea and technical feasibility. Now we’re moving forward, identifying use cases and building prototypes. So it’s about time to work on that alphabet.

A big challenge in IoT is interoperability. In a recent Nexus survey, 77% of respondents stated that interoperability was their biggest challenge in IoT. Connecting industrial devices to IT and IoT platforms is big business, and it’s where a lot of the abbreviations come from. There are many protocols to accomplish this: some that are proprietary and others that are open standards. All are jockeying to be the one and only IoT protocol, but it’s clear this will never be the case.

Defining the Different IIoT Protocols

Before diving into the protocols, Aron provides background information on the two categories of protocols: client/server and publish/subscribe. Then, he describes the strengths and weaknesses of OPC UA, HTTP (REST/JSON), MQTT, CoAP, DDS, and AMQP—and helpfully identifies when to use each. For example, the following excerpt defines the HTTP protocol and then offers use case examples and potential pitfalls:

Hypertext Transfer Protocol (HTTP) is a connectionless client/server protocol ubiquitous in IT and the web. Because there are countless open source tools that use HTTP, and every coding language has HTTP libraries, it is very accessible.

The focus on HTTP in IoT is around Representational State Transfer (REST), which is a stateless model where clients can access resources on the server via requests. In most cases, a resource is a device and the data that a device contains.

HTTP provides a transport, but doesn’t define the presentation of the data. As such, HTTP requests can contain HTML, JavaScript, JavaScript Object Notation (JSON), XML, and so forth. In most cases, IoT is standardizing around JSON over HTTP. JSON is similar to XML—without all the overhead and schema validation—making it more lightweight and flexible. JSON is also supported by most tools and programming languages.

Industry has some experience using HTTP for device and product configuration, but not for data access. As such, many IoT and IT platforms support consuming and providing data in HTTP form, but few industrial platforms do. This is changing as more gateways and PLCs begin to add native HTTP support.

Use HTTP for sending chunks of data, like one-minute temperature readings every hour. Don’t use HTTP for streaming high-velocity data. HTTP can do sub-second data, but 100 ms updates over HTTP are difficult. It has a lot of overhead per message, so streaming small messages is inefficient. And always secure communications with HTTPS. The overhead is minimal.

Be aware of interoperability issues with HTTP products. Just because two products support HTTP/REST/JSON doesn’t mean they’ll work out of the box. Often the JSON formats are different and require minimal integration to get things working.

Wrap Up

For our customers, understanding these new terms and acronyms is increasingly important as they are being asked to bridge the gap between Operations Technology and Information Technology. Often, speaking the same language is the first step. I hope this post helps you better understand these new terms being used in our space, and encourage you to download Aron’s whitepaper to learn more about the IIoT protocols available.

Don’t hesitate to leave us a comment with any questions you may have. We’re looking forward to hearing your thoughts and experiences!