Colin Geis, Director of Product Management, IIoT
Red Lion Controls
The IIoT revolution is in full swing, but there are several contenders in the protocol market for communicating plant floor data to IIoT cloud platforms. While the leader of this race to connectivity appears to be MQTT, alternatives like AMQP, STOMP and REST APIs (among others) provide a variety of benefits that make a choice less than straightforward. Even within the MQTT universe, despite its status as a standard, varied interpretations and implementation practices cause difficulties for those crafting a solution. Making an informed decision on which protocol to select needs to originate with a recognition of the goals of IIoT programs, an understanding of how this compares to traditional industrial communications objectives and protocol choices, and a review of the benefits and limitations of competing IIoT protocols and platforms.
It is not uncommon to look at IIoT as a simple extension of existing industrial networks, wherein the data from end devices is compiled through the network and then stored remotely in some cloud-based data repository. While accurate, this surface level view glosses over key differences between traditional networked information and the actual benefit driving the movement to a true IIoT environment, which is broad insight.
The emergence of cloud-based IIoT platforms is breaking down the traditional linkages between discrete data points and individual application intelligence. In traditional manufacturing applications, specific data was collected for a particular application with the intent of monitoring or improving that single operation. For example, an optical sensor could increment a counter panel meter to make sure pallets had the correct number of goods prior to shipment. That same data may have also been written to a historian, but the intent for the use of that data was still focused on the specific function from which it was derived. It wasn’t intended or formatted to be used in other processes or upstream applications.
With today’s IIoT platforms, that same finished good count data can be used in a number of applications including Overall Equipment Effectiveness (OEE), loss, waste, production efficiency, and even identifying if differences of efficiency exist between production shifts. Within this framework, data should no longer be polled for specific applications. It should be collected to a big-data database which is designed to efficiently provide information to different applications which are requesting data. For IIoT initiatives to succeed, the goals should be efficient and ubiquitous data aggregation and availability. This means that as much data as possible needs to be gathered and made available in a common format to allow for broader business insights to emerge.
This framework helps to clarify important ways in which the selection criteria for IIoT protocols should differ from those employed when designing traditional industrial applications. Even when thinking about a plant floor, the decision of which protocol (or protocols) to use to connect PLCs, drives, servos, cameras, etc. can be almost overwhelming. Modbus is an easy choice due to its ubiquity of support in most equipment and stable communication. EtherNET/IP and OPC-UA are gaining a lot of traction in the market as well, due to their increased performance and security capabilities. Realistically, there are countless numbers of published materials available to discuss the merits of different plant floor communication protocols, but traditional ones like Modbus, Profibus, etc. were never designed for the much more complex task of transmitting data to a cloud environment over communication mediums that may constantly drop a network connection or where network latency can change continuously. Most importantly, there is the need to address todays growing concerns over security and scalability.
In the move toward the IIoT, the consideration of what network medium the data will be transferred over cant be overlooked. Will you use high-speed fiber or cable, or cellular? All have their pros and cons. Wired solutions provide higher data rates and lower latency than cellular, but commonly they consume IT resources due to security and firewall policies. Cellular is gaining momentum in the industrial space, both on the factory floor as well as for remote sites, due to its simplicity of deployment and secure communication. When deployed within a factory environment, cellular devices do not need to access the corporate network to transmit data, so there is no need to manage or modify enterprise security measures or navigate through existing firewalls. At remote sites, there is typically very limited or no communication available, so deploying a cellular router is likely the easiest solution to provide reliable communication. Regardless of location, cellular is a very robust communication medium both in reliability and security. The availability of traditional data encapsulation like VPN tunnels can be used with cellular, but also more advanced methods to secure data like private APNs or Software Defined Networking (SDN) can provide a layered approach to securing data over cellular networks.
The final step in the process to selecting an IIoT protocol is choosing an IIoT cloud platform that meets the requirements of your application. There are so many IIoT platforms available, with options ranging from those providing simple remote connectivity, to data dashboards, to the more advanced platforms that offer device management and data analytics. Most platforms support a number of different protocols to collect data from field devices as well as other communication protocols for transferring large amounts of data from cloud to cloud, if the application requires. For the purposes of this article well continue to focus on the edge to cloud communication protocols.
Recognizing that many traditional industrial protocols probably arent suited for the task of scalable and secure communications to a cloud environment, and considering both the transmission network and platform options available, lets touch on the protocols that are emerging as the front runners for IIoT communication to a cloud platform.
Just like plant floor communications, each competing IIoT protocol was designed for something specific, and as such offers unique functionality to meet the needs of specific applications. Each prioritizes specific features like security or real-time at the cost of larger packets or more complex code, so finding the right balancing point for the IIoT and the array of applications that are being deployed can be challenging. Currently the list includes AMQP, ZeroMQ, DDS, STOMP, MQTT and more. So which protocol do you select, and more importantly, how do you get your current industrial protocol to communicate with these newer and likely more secure ones?
AMQP(Advanced Message Queuing Protocol) – AMQP is a more advanced protocol developed for the financial industry to “provide a robust standard for passing business messages between applications”. AMQP is ideally deployed in communication networks that offer high-availability and bandwidth with low-latency between resources. While AMQP offers robust features like queuing, packet retransmission, and a host of other data integrity functions, it requires a good deal of processing power at the edge of the network where the sensor data is collected, which can be problematic for sensor to cloud integration applications.
ZeroMQ- This is a high-performance messaging library for communicating between applications or processes regardless of hardware or software architecture. ZeroMQs extensible architecture provides a platform for supporting any number of different applications. ZeroMQ could be an ideal IIoT protocol, except that IIoT applications dont require high-performance or real-time operation, and the larger packet overhead required for high-performance operation isnt ideal for use on metered data connections like satellite or cellular networks where it can lead to higher costs.
DDS(Data Distribution Service) – DDS is designed for real-time systems that commonly require deterministic performance and therefore requires highly available network communications with little tolerance for networks with more than nominal latency. This protocol should be evaluated for use if control at both ends of the network is required and it is a new application with a designated communication network that can support the protocols demanding requirements.
STOMP- Streaming Text Oriented Messaging Protocol is similar to HTTP and is designed for interoperability of brokers.  With such an open protocol, there has been little standardization of brokers so real-world interoperability has been challenging. In addition, STOMP has limited (if any) acceptance in the world of IIoT platforms and has high consumption of data due to overhead.
MQTT- Message Queue Telemetry Transport is a lightweight messaging protocol designed for volatile communication networks like cellular or satellite. MQTT’s lightweight design minimizes data consumption and doesn’t require high-bandwidth or high-availability network connections. MQTT’s lightweight design was architected to support emerging low-bandwidth communication technologies like LPWAN, LTE-M, and NB-1 as well as operate efficiently over wired communications. An example of this optimization is its use of 1 byte keep alive packets.
IIoT and associated applications neednt be focused on requiring absolute fidelity and completeness from each and every single data point, which should be considered tactical data. Instead the focus should be on larger quantities (i.e. big data) that yield trends and strategic insights. As the IIoT continues to balloon at an almost exponential rate, resources must be used efficiently, which includes the data collection process, endpoint resources, and bandwidth that ties the IIoT together. IIoT platform providers have almost unanimously selected MQTT as the preferred messaging protocol due to the efficiency of communication, security and scalability associated with it. While platforms are also supporting other protocols, implementations using these alternatives aren’t ideal due to lesser or more complex security, diminished scalability or data inefficiency.
To overcome some of the perceived limitations of the MQTT protocol, the application layer is increasing in functionality. For example, when comparing the functionality of MQTT to the more advanced AMQP which includes Quality of Service (QoS) or message caching, manufacturers are engineering their applications to include message queuing if communication is lost. By relocating the management of this capability to the application or hardware, users can be assured that important data will not be lost without having to give up the benefits that MQTT provides.
MQTT seems to be the protocol of choice not only for IIoT platforms but also for hardware manufacturers due to its efficiency, security and scalability, but this race of protocols is not over. New protocols will come to market which will address the needs and concerns of other IIoT applications with unique requirements. Standardization of protocols is important, but maintaining flexibility for the future will ensure preparedness for the next revolution in industrial technology.
Red Lion Controls is a US manufacturer of industrial automation and networking solutions that help organizations connect, monitor and control assets worldwide. Visit www.redlion.netto learn more.
 AMQP – https://www.amqp.org/about/what
 ZeroMQ www.zeromq.org
 DDS – http://portals.omg.org/dds/
 STOMP – https://stomp.github.io/
 MQTT – http://mqtt.org/