IoT is the alphabet soup. IIoT, IoE, HTTP, REST, JSON, MQTT, OPC UA, DDS, and the list goes on.
The major 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 most of the abbreviations are generated in this process. To achieve this, there exist many protocols including proprietary and 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.
This white paper focuses on the open standards for connecting industry to IT and provides use cases for each.
For the sake of this discussion, it’s important to group protocols into two categories: client/server and publish/subscribe.
Client/server protocols require the client to connect to the server and make a requests. In this model, the server holds the data and responds to requests from the client. For example, the client may read a temperature. This requires the client to know about the server in advance and be able to connect.
Publish/subscribe protocols require the devices to connect and publish data to a topic on an intermediary broker. Consumers can connect to the broker and subscribe to data from the topic. For example, a device can sample the temperature every minute and publish once per hour. An application subscribed to the data stream receives an hourly one-minute samples every hour. This model separated the data producer from data consumer.
In terms of pros and cons, client/server protocols are more interoperable and secure because they are based on point-to-point connections. They are, however, less scalable, because point-topoint connections are harder to manage and more resource intensive.
In contrast, publish/subscribe protocols are more scalable because the decoupling of producers and consumers allows each to be added and removed independently. That said, securing these protocols is more complex because there are more pieces involved. They can also have interoperability issues given the lose coupling of the producer and consumer. For example, changing the message format that a producer sends requires all consumers to adapt to the new message type.
Now that we understand the basic categories, let’s look at client/ server and publish/subscribe protocols in detail.
Protocols
The protocols we discuss here have the potential to connect together industrial devices with IoT platforms. We’ll describe each protocol and when to use it. Here is the short list that we’ll cover:
• OPCUA • MQTT • DDS
• HTTP (REST/JSON) • CoAP • AMQP
OPC UA
OPC Unified Architecture (OPC UA) is the next generation standard from the OPC Foundation. Conventional OPC is well known in the industrial space and provides a standard interface to communicate with PLCs.
OPC UA is a client/server protocol. Clients connect, browse, read, and write to industrial equipment. UA defines communications from the application to the transport layer, making it very interoperable between vendors. It’s also highly secure, and uses two-way message signing and transport encryption.
OPC UA has a wide install base in the industrial space. It is a good solution to connect PLC and sensor data to existing industrial applications such as SCADA and MES systems, where OPC and OPC UA connectivity are already available.
OPC UA is, however, new to IT field.. Some people in IT are intimidated by the complexity of UA compared to other IT protocols. A lot of this complexity is a result of OPC UA being an industrial protocol, but this perception has led to slow adoption by IoT platforms and the open source community.
For now, use OPC UA when you need to get PLC and sensor data into existing SCADA and MES solutions, and keep an eye out for OPC UA adoption by IoT platform providers and the open source community.
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 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 being standardized 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, rather a few industrial platforms do. This is
changing as more gateways and PLCs begin to begins to include local 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.
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.
CoAP
The Constrained Application Protocol (CoAP) was developed by the Internet Engineering Task Force (IETF) to provide the
interoperability of HTTP with minimal overhead. CoAP is similar to HTTP, but uses UDP/multicast instead of TCP. It also
simplifies the HTTP header and reduces the size of each request. CoAP is used in edge-based devices where HTTP would be too resource intensive, and is often the third protocol supported by IoT platforms after HTTP and MQTT. Similar to HTTPS, CoAP uses Datagram Transport Layer Security (DTLS) to secure communications.
Use CoAP when HTTP is too bandwidth intensive. Keep in mind that CoAP’s market adoption is not as large as HTTP, so it may limit your software and hardware options. There are solutions for converting CoAP messages to and from HTTP that make CoAP solutions more interoperable.
DDS
Data Distribution Service (DDS) is a publish/subscribe protocol that’s focused on communication at the edge of the network. DDS is an open standard managed by the Object Management Group (OMG). Unlike MQTT which requires a centralized broker, DDS is decentralized. DDS nodes communicate directly in peer- to-peer fashion using UDP multicast. This removes the need for centralized network management and also makes DDS a faster protocol, reaching submillisecond
resolution.
DDS is a good solution for reliable, real-time data delivery at the edge. Use it for fast M2M communications. DDS supports brokers to integrate DDS networks with the enterprise, but in practice it is not well positioned as the integration point between industry and IT as brokers are often secondary to the DDS network.
AMQP
Advanced Message Queuing Protocol (AMQP) is another publish/ subscribe protocol that comes out of the financial services sector. It has a presence in IT, but a limited presence in industry.
AMQP’s biggest benefit is its robust communications model that supports transactions. Unlike MQTT, AMQP can guarantee transactions complete— which, though useful, is not always required by IoT applications.
AMQP often forms a group with IoT protocols but its biggest con is that it is a heavy protocol. It was meant for backend IT systems, and not the edge of the network.
Conclusion
OPC UA, HTTP, MQTT, CoAP, DDS, and AMQP all have a place in IoT. Which protocols take majority market share is unclear, but each has its pros and cons.
Being aware of these pros and cons will ensure the success of your IoT applications and protect you from the protocol wars.
“It is crucial to choose the protocol that best suits your needs and to prefer the technology partners that can adapt to these protocols.”
Kepware uses the REST and MQTT protocols in the IoT Gateway solution of KEPServerEX, which enables the OPC UA in by its function.