Confused about Industrial IoT Communication?

With so many open communication standards for automation networks now widely available, some users have begun to wonder whether they should use OPC UA, MQTT or AMQP. The answer depends on understanding the protocols and the applications.

Not so long ago, the protocol used on your industrial Ethernet network was determined, largely, by whose control systems you used. If you used Rockwell Automation products, your network was based on EtherNet/IP; if you used B&R, your network was POWERLINK, if you used Siemens, your network was Profinet; if you used Mitsubishi, your network was CC-Link IE. Since few, if any, manufacturing or processing facilities have ever been the domain of just one automation technology supplier, industry has long expressed a desire for open industrial communication technologies that could easily communicate with any controller, HMI, drive or other device on the network.

Today, that desire has largely been realized with the development of OPC UA, MQTT and AMQP — and is being pushed even further by the work of groups like the OPC UA Foundation, the Industrial Internet Consortium ,…. But the existence of these options has also created some confusion.

OPC UA and MQTT are M2M communication protocols. OPC evolved from an object-oriented remote procedure call system (DOM / CDOM), which was replaced in OPC-UA by its own improved system.

The open source standard MQTT evolved from WebSphere MQ. MQTT is an extremely simple and lightweight publish / subscribe messaging system. MQTT is designed for low bandwidth, high latency and unreliable networks. OPC-UA was further expanded in the latest version not only to transport machine data (process values, measured values, parameters, etc.), but also to describe machine-readable data semantically.

AMQP and MQTT

AMQP and MQTT have been intended to be used for vertical connectivity. They are both open protocols for asynchronous message queuing which have been developed and matured over several years. In 2011, the organisations who developed them have made announcements that their latest protocol versions that are 'ready' for widespread adoption, and have submitted them for standardisation. AMQP has selected the OASIS industry standards group1, with the intention of moving to becoming an ISO/IEC standard. MQTT has chosen to use the Eclipse foundation2.

Both provide basic messaging needs; beyond that, AMQP provides a very much richer set of messaging scenarios. AMQP is almost a complete superset, lacking only explicit protocol support for Last-Value-Queues and will messages. However, its deliberate design for extensibility, using an IANA-like approach with a discursive approach, ensures that such features can be added in a forward-compatible, widely agreed upon way.

Both protocols are being promoted for ?widespread? use in the internet:-

• MQTT as a low-overhead, simple to implement way to send data, especially from embedded devices;
• AMQP as the asynchronous complement to HTTP As such, both are being promoted as being ideal for cloud computing and the ?internet of things?. That essential thesis is correct; message queuing, with its asynchronous nature and minimal need for configuration when done right, is perfect for interoperating many different environments.

However, MQTT is constrained to providing basic messaging ?topics? in a single ?namespace?, with no long-lived ?store-and-forward? queuing pragmatic. This makes it difficult, if not often impossible, to multi-tenant server resources, or to dynamically migrate them or provide simple ?development to production? switch-over. Even worse, a woefully naive security / user model makes proper resource sandboxing and analysis very limited.

AMQP provides for sand-boxed, multi-tenanted or multi-hosted infrastructure, ideal for the modern cloud with multiple user security schemes appropriate to the modern internet.

Lastly, it?s worth noting that MQTT, intended for telemetry transmission, is not used in two of the world?s biggest message queue based telemetry projects: Scripps Oceanography?s monitoring of the Mid-Atlantic Ridge3, and Smith Electric Vehicle?s global fleet management4, both use versions of AMQP.

OPC UA

Secure, reliable and platform-independent information exchange - OPC-UA is the new technology generation of the OPC Foundation for the secure, reliable and manufacturer-independent transport of raw data and preprocessed information from the sensor and field level to the control system and the production planning systems. With OPC-UA, any type of information is available anytime, anywhere for any authorized application and authorized person. Independent of platform and manufacturer OPC-UA is independent of the manufacturer or system supplier who produces or delivers the respective application. The communication is independent of the programming language in which the respective software was programmed. And it does not depend on the operating system the application is working on. It is an open standard without any dependence or commitment to proprietary technologies or individual manufacturers.

Standardized Communication via Internet & Firewalls – OPC-UA extends the previous OPC industry standard with several important features such as platform independence, scalability, high availability and Internet capability. OPC-UA is no longer based on Microsoft's DCOM technology, it was redesigned based on service-oriented architecture (SOA). OPC-UA can therefore be adapted very easily. Even today, OPCUA links the enterprise level down to the embedded systems of automation components - independent of Microsoft, UNIX or any other operating system. OPC-UA uses a TCP-based, optimized, binary protocol for data exchange via a port 4840 entered in IANA. Web service and HTTP are optionally supported as an option. It is sufficient to enable a single port in the firewall. The integrated encryption mechanisms ensure secure communication over the Internet.

And there are many more advantages to report on OPC UA … (to be continued)