Skkynet | Data Anywhere | data communications

What Makes an Ideal IIoT Protocol?

Agood IIoT protocol is the basis for effective IIoT data communication. Without a secure, robust IIoT protocol, data can be late, missing, inconsistent, or dangerously incorrect, leading to costly errors and wasted time.

With the IIoT still in its infancy, companies have turned first to familiar, well-tested data communication and messaging protocols such as MQTT, AMQP, REST and OPC UA for an IIoT protocol. Valid as these may be for their designed purposes, they were never intended to support IIoT data communication. Thus, when evaluated according to criteria for a robust, secure Industrial IoT implementation, they all come up somewhat short.

Skkynet’s software and services are designed for the IIoT, and meet all of the criteria for effective data communication. Here we provide a comparison report on how well MQTT, AMQP, REST, OPC UA, and Skkynet’s own DHTP (DataHub Transfer Protocol) meet the criteria summarized in the above table for an ideal IIoT protocol. Each of the criteria enumerated above is explained in further detail in subsequent sections.

Keeps all inbound firewall ports closed for both data sources and data users.

Keeping all inbound firewall ports closed at the plant resolves many security issues for Industrial IoT. MQTT, AMQP, REST and DHTP meet this criterion. OPC UA does not because it has a client/server architecture, which requires at least one firewall port be open on the server side (typically the plant) to allow for incoming client connections. This is an unacceptable risk for most industrial systems. Skkynet’s DataHub and ETK connect locally to servers and clients in the plant, and make outbound connections via DHTP to SkkyHub running on a cloud server, or to another DataHub running on a DMZ computer. This outbound connection keeps all inbound firewall ports closed and hides the plant from the outside world.

Consumes minimal bandwidth, while functioning with the lowest possible latency.

One goal of any industrial communication or IIoT protocol is to consume as little bandwidth as possible, and function with the lowest possible latency. MQTT and AMQP do this well. REST does not, because every transaction includes all of the socket set-up time and communication overhead. OPC-UA is partial, because it uses a smart polling mechanism that trades bandwidth for latency. Skkynet software and services maintain a connection and transmit only the data via DHTP, consuming very little bandwidth, at very low latencies.

Can support hundreds or thousands of interconnected data sources and users.

An important aspect of the Internet of Things is the vision of connecting hundreds, thousands, and even millions of things via the Internet, and providing access to the data from any single thing, or groups of things to any number of clients. Event-driven protocols like MQTT and AMQP allow for this kind of scaling up, while REST’s polling model prevents it. OPC UA is also event-driven, and so theoretically can scale up, but its underlying polling model does not allow for very large numbers of simultaneous connections. DHTP abstracts the data from the protocol across the connection, and also implements an event-driven model, which allows it to scale up well.

Adds virtually no latency to the data transmission.

Any kind of remote HMI or supervisory control system is much more effective when functioning in at least near-real time. Propagation delays of one or more seconds may be tolerable under certain conditions or for certain use cases, but they are not ideal. AMQP and MQTT offer real-time behavior only if they are not operating with a delivery guarantee. That is, if you choose the “guaranteed delivery” quality of service then a slow connection will fall further and further behind real-time. By contrast, DHTP guarantees consistency, not individual packet delivery, and can sustain that guarantee in real time on a slow connection. REST simply has too much connection overhead to allow real-time performance in most circumstances. OPC UA, being an industrial protocol, meets this criterion well.

Encodes the data so that clients and servers do not need to know each other’s protocols.

A well-defined data format is essential for interoperability, allowing any data source to communicate seamlessly with any data user. Interoperability was the primary driving force behind the original OPC protocols, and is fully supported by the OPC UA data format. Any Industrial IoT software or service should support at least one, if not multiple interoperable data formats. Skkynet’s DataHub software and ETK support several, and allow for real-time interchange between them and DHTP. MQTT, AMQP and REST do not support interoperability between servers and clients because they do not define the data format, only the message envelope format. Thus, one vendor’s MQTT server will most likely not be able to communicate with another vendor’s MQTT client, and the same is true for AMQP and REST.

A messaging broker responds appropriately when a data user is unable to keep up with the incoming data rate.

Overload handling refers to how the broker responds when a client is unable to keep up with the incoming data rate, or when the server is unable to keep up with the incoming data rate from the client. MQTT and AMQP respond in one of two ways. Either they block, effectively becoming inoperative and blocking all clients. Or they drop new data in favor of old data, which leads to inconsistency between client and server. REST saturates its web server and becomes unresponsive. OPC UA attempts to drop old data in favor of new data, but consumes massive amounts of CPU resources to do so. When needed, Skkynet’s DataHub and SkkyHub can drop old data efficiently, and using DHTP they guarantee consistency between client and server even over multiple hops. Data coming from or going to overloaded clients remains consistent, and all other clients are unaffected.

Each client application knows with certainty if and when a connection anywhere along the data path has been lost, and when it recovers.

Most protocols do not provide failure notification information from within the protocol itself, but rather rely on clients to identify that a socket connection is lost. This mechanism does not propagate when there is more than one hop in the communication chain. Some protocols (such as MQTT) use a “last will and testament” that is application-specific and thus not portable, and which is only good for one connection in the chain. Clients getting data from multiple sources would need to be specifically configured to know which “last will” message is associated with which data source. In MQTT, AMQP, REST and OPC UA alike, the protocol assumes that the client will know how many hops the data is traversing, and that the client will attempt to monitor the health of all hops. That is exceptionally fragile, since knowledge about the data routing must be encoded in the client. In general, this cannot be made reliable. DHTP propagates not only the data itself, but information about the quality of the connection. Each node is fully aware of the quality of the data, and passes that information along to the next node or client.

Guarantees consistency of data, preserved through multiple hops.

An important goal of the IIoT is to provide a consistent picture of the industrial data set, whether for archival, monitoring, or supervisory control. MQTT’s ability to guarantee consistency of data is fragile because its Quality of Service options only apply to a single hop in the data chain. And within that single hop, delivery can be guaranteed only at the expense of losing real-time performance. Real-time performance can be preserved, but only by dropping messages and allowing data to become inconsistent between client and server. AMQP’s ability to guarantee consistency of data is fragile because like MQTT it only applies to a single hop in the chain. Additionally, its delivery guarantee blocks when the client cannot keep up with the server and becomes saturated. REST provides no Quality of Service option, and while OPC UA guarantees consistency it cannot work over multiple hops. DHTP guarantees consistency, and the guarantee is preserved through any number of hops.

Brokers can connect to other brokers to support a wide range of collection and distribution architectures.

The requirements of the IIoT take it beyond the basic client-to-server architecture of traditional industrial applications. To get data out of a plant and into another plant, corporate office, web page or client location, often through a DMZ or cloud server, typically requires two or more servers, chained together. The OPC UA protocol is simply too complex to reproduce in a daisy chain. Information will be lost in the first hop. Attempts to daisy chain some aspects of the OPC UA protocol would result in synchronous multi-hop interactions that would be fragile on all but the most reliable networks, and would result in high latencies. Nor would OPC UA chains provide access to the data at each node in the chain. REST servers could in theory be daisy chained, but would be synchronous, and not provide access to the data at each node in the chain. MQTT and AMQP can be chained, but it requires each node in the chain to be aware that it is part of the chain, and to be individually configured. The QoS guarantees in MQTT and AMQP cannot propagate through the chain, so daisy chaining makes data at the ends unreliable. Skkynet’s DataHub and SkkyHub both support daisy-chained servers because DHTP allows them to mirror the full data set at each node, and provide access to that data both to qualified clients, as well as the next node in the chain. The DHTP QoS guarantee states that any client or intermediate point in the chain will be consistent with the original source, even if some events must be dropped to accommodate limited bandwidth.

In Conclusion

Far from exhaustive, this overview of effective IIoT data communication provides an introduction to the subject, and attempts to highlight some of the key concepts, through sharing what we have found to be essential criteria for evaluating some of the protocols currently on offer. Because none of MQTT, AMQP, REST, or OPC UA were designed specifically for use in Industrial IoT, it is not surprising that they do not fulfill these criteria. DHTP, on the other hand, was created specifically to meet the needs of effective industrial and IIoT data communication, making it an ideal choice for an IIoT protocol.

Download White Paper (PDF)

Data Communication for Industrial IoT – Conclusion

The Industrial IoT holds a lot of promise for improving productivity and cutting costs for industrial systems. Yet the IIoT is different from both the consumer IoT and traditional SCADA systems. In particular, data communications have unique requirements that you need to keep in mind if you are planning to implement an IIoT project that works well.

Re-Thinking Assumptions

Because industrial data communication was developed independently of the Internet, the merging of these two technologies requires a re-thinking of some basic assumptions. The most secure and reliable approach is to focus on the data, and to allow access to the data only. Accessing a device means that the device is open to an attack. Accessing the network leaves the network exposed, even if you use a VPN. A more secure-by-design approach allows the data source and the data user to make outbound connections to a public or private cloud service that holds only the data. This keeps all plant firewall ports closed, and provides a secure spot independent of the plant where the data can be accessed by authorized users.

Data Protocol Problems

A number of data communications protocols have been proposed for the IIoT, each with its advantages and drawbacks. UDP works for VOIP and streaming media, but it lacks the accuracy and completeness so necessary for good industrial communication. MQTT offers a publish/subscribe mechanism and many-to-many connectivity, but lacks a standard data protocol and the ability to handle messages intelligently. OPC UA is a good choice for in-plant connectivity, but suffers from the traditional server/client design that requires an open firewall port to connect from the Internet. REST over HTTP is popular for general IoT applications, but has issues with bandwidth, latency, scalability, symmetry, and robustness when faced with the high speed and large number of connection requirements of the IIoT. To implement security Blockchain may sound good in theory, but a closer look shows why it will fail in practice.

A New Approach

Clearly, a new approach specifically designed for IIoT is needed. This approach should use the robust foundation of TCP, the security of a publish/subscribe model like MQTT, and the in-plant connectivity of OPC UA. Its bandwidth use, latency, and scalability should far exceed RESTful HTML. This new approach should support edge processing, and in fact, provide the means for edge processing, cloud processing, and fog processing, as dictated by the circumstances on the ground or in the field. It should be available as a public cloud, a private cloud, or a hybrid combination of public and private clouds.

Something That Actually Works

Most important, this approach should actually work. You should be able to install it in greenfield or brownfield projects. It should connect to existing systems, use open protocols, and provide secure, robust, real-time performance at speeds not much slower than Internet propagation speeds. And it should be available today, right now. If you’re interested, give us a call.

Go back to Table of Contents