The Industrial Internet of Things (IIoT) is a true alphabet soup of technologies. OPC UA, HTTP, REST, JSON, MQTT, CoAP, DDS, AMQP, and the list goes on. Conceptually, we’ve discussed IIoT 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 time to work on that alphabet.
A big challenge in IIoT is interoperability. In a recent Nexus survey, 77 percent of respondents stated that interoperability was their biggest challenge when it comes to IIoT. 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 based on open standards. All are jockeying to be the one and only IoT protocol, but it’s clear this will never be the case. These protocols will co-exist—each with their own strengths and weaknesses—and it’s our job to understand where and when to use them.
The two protocols I’ll discuss in this article—HTTP and MQTT—have the potential to connect industrial devices with IoT platforms.
HTTP (REST/JSON)
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 programmable logic controllers (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.
MQTT
Message Queuing Telemetry Transport (MQTT) is a publish/subscribe protocol designed for SCADA and remote networks. It focuses on minimal overhead (2 byte header) and reliable communications. It’s also very simple. Like HTTP, MQTT’s payload is application-specific, and most implementations use a custom JSON or binary format.
MQTT isn’t as widely used as HTTP, but it still has a large market share in IT. There are many open source clients/producers, brokers, projects and examples in every language. Many IoT platforms support HTTP and MQTT as their first two inbound protocols for data.
Use MQTT when bandwidth is at a premium and you don’t know your infrastructure. Make sure you or your vendor has an MQTT broker you can publish data to—and always secure communication via Transport Layer Security (TLS).
Does the end application not support MQTT? If so, there are a lot of open source tools for getting MQTT data into databases and other formats like HTTP.
Beware of interoperability issues similar to HTTP. Just because two applications support MQTT doesn’t mean they are interoperable. The topic and JSON formats may need to be adjusted to make the two products interoperable.
Next steps
It’s important to pick the protocol that best fits your needs, and then select technology partners that can adapt to these protocols. This will ensure the success of your IoT applications and protect you from the protocol wars.
If you would like to read more on this topic, please download the complete whitepaper “IIoT Protocols to Watch” at www.kepware.com/iiot-protocols-to-watch.
