This article was written by Steve Hechtman, president, CEO, and founder of Inductive Automation.
A number of competing technologies and protocols have been in play for the Industrial Internet of Things (IIoT), each with strengths and weaknesses. There is one protocol, however, that appears to best address the unique demands and challenges of the controls business: MQ Telemetry Transport (MQTT). MQTT is an OASIS standard that is open and royalty free.
MQTT is a publish/subscribe protocol whereby edge-of-network devices publish to an MQTT server that can be on or off the premises. The data can then be discovered by, and delivered to, any number of subscribing clients. Clients can be supervisory control and data acquisition (SCADA) systems or other enterprise applications. This one-to-many capability decouples edge-of-network devices and data-consuming client applications for more efficient information distribution and increased scalability.
Traditional polling systems usually require clients to know everything about edge-of-network devices in advance. In brokered publish/subscribe systems, such as MQTT, data can be discovered and tags can be automatically generated by the simple act of subscribing from a client—which can save an immense amount of development time.
Several features of the protocol make it particularly suitable for remote sensing and control. It reports by exception and has extremely lightweight overhead (2-byte header). Unlike the usual poll/response model that generally saturates data connections with unchanging data, MQTT maximizes available bandwidth. In fact, it was originally developed for the often low-bandwidth, high-latency, and unreliable data links used in the oil and gas industry. Update rates in the 100-millisecond range are possible even with external cloud-based brokers.
MQTT also maintains stateful session awareness and is bidirectional. When an edge-of-network device loses network connectivity, all subscribed clients will be notified with the “last will and testament” feature of the MQTT server (which is important in the SCADA world). The last known and time-stamped value will still be available using the “retain” message feature of the transport. The bidirectional capability of MQTT means that any authorized client in the system can publish a new value to the edge-of-network device, so bidirectional connectivity is maintained, as you would expect of any SCADA system. The changed value is then read and published back to the broker from the edge-of-network device, thus confirming to all subscribed clients that the value has changed.
Being a lightweight and efficient protocol facilitates a higher throughput rate, which in turn significantly increases the amount of data that can be monitored or controlled. Therefore, organizations can publish stranded intelligence from field devices, such as flowmeters, to the MQTT server, and maintenance folks can subscribe to it (whereas operational clients would subscribe to operational data). Previously, this metadata had to be manually retrieved from the location, because it was often so voluminous that bandwidth limitations made transporting it out of the field hard to justify.
Security is permission based in that the credentials used to log into an MQTT server determine the resources available to that user. Because MQTT was designed on top of TCP/IP, authentication and encryption are typically transport layer security. They are implemented outside of the specification to keep it simple, lightweight, and future proofed as TCP/IP security models change. Security can be further enhanced with on premise brokers or a hybrid model.
The MQTT specification is data agnostic; it does not define a data representation for the message payload. This can present a problem of compatibility between different MQTT systems, because each can have different data representations. The controls industry has a limited number of well-known data types, so the formation of compatible edge-of-network devices, brokers, and subscription clients is within reach. In fact, a number of companies are already working together on it.
There are quite a few open-source projects for MQTT clients (e.g., the Eclipse Paho project) and brokers (e.g., Mosquito and RabbitMQ). Although MQTT was borne from oil field requirements, it is now used as far afield as Facebook Messenger. Amazon Web Services announced that Amazon IIoT is based on MQTT as well.
Most likely, polling schemes and existing protocols will remain the standard on local area networks, but wide area data acquisition and control systems will transition toward one of the industrial IIoT paradigms. MQTT appears to be a protocol with a good track record, good adoption, and unique suitability for the control systems used by industry.
About the Author
Connect with Steve:
A version of this article also was published at InTech magazine.