Skkynet | Data Anywhere | MQTT

It’s big. It’s by far the biggest industrial automation show in Germany, in Europe, and possibly in the world. It’s SPS IPC Drives. “SPS” is German for PLC (Programmable Logic Controller), “IPC” stands for Industrial Process Control, and “Drives” are tools that control the speed of machinery. It comprises a dozen exhibition halls, each one practically a trade show in itself, filled with gigantic, colorful booths displaying robots, machines, and control system components. It’s where thousands of engineers, system integrators, machine builders and parts vendors gather for a massive show-and-tell featuring the latest and greatest—sensors, actuators, controllers, software, services and more.

The Cogent/Skkynet display was part of the OPC Foundation exhibit at the show, in the communications technologies hall. We had a demo of our completely integrated solution for Industrial IoT data communication and OPC UA (Unified Architecture), from embedded devices with ETK, to the factory floor with DataHub, to our SkkyHub service running in the cloud. We attracted plenty of interest, particularly for our ability to access data from inside a plant without opening any firewall ports, and using no VPNs.

Other exhibits featured IoT, and a few had working demos similar to ours, showing how they could put data from a sensor into the cloud. But there were significant differences. Most of them did not have bidirectional communication, and all of them had to make compromises on security and robust connectivity.

Data Communication must be Secure…

The two technologies most frequently mentioned for data communications were OPC UA and MQTT. Most users are finding out that OPC UA by itself cannot serve as an IIoT protocol, because like every industrial protocol, it functions on a client-server basis. An OPC UA client outside the plant needs an open firewall port at the plant to connect to an OPC UA server inside. This is inherently insecure, since any hacker could also enter the plant through that open firewall port. To surmount this obstacle, a number of companies have turned to the MQTT messaging protocol. Its publish/subscibe architecture allows it to make outbound connections. That does keep firewall ports closed, but MQTT is not suitable for IIoT for other reasons. Notably, it cannot guarantee data consistency.

… and Robust

Funnily enough, when you bring this up, people catch on quickly. I walked around the show and talked to people who had IIoT on their posters and brochures, who were demonstrating IIoT devices, and offering IIoT cloud services. Companies large and small, including some of the biggest names in the industry, are using or promoting MQTT or its close cousin, AMQP. And yet when I pointed out to them how MQTT is unable to guarantee consistent data, they soon understood. Everyone acknowledged that if an MQTT connection from a data source is broken, the data user will not know that his or her data may no longer be valid. “Isn’t that a problem? Couldn’t it be dangerous?” I would ask. “Yes,” they would admit, “but there isn’t any other way.”

Another Way

Finding out that there is another way opened a few eyes. People coming to our booth and those we met throughout the show were surprised and pleased to find out that there actually is a way to maintain a secure, robust connection for IIoT. There is no need to open any firewall ports or to use a VPN, and yet you can guarantee consistency of the data between the server and the client. All you need is the right technology, secure by design. Our task for the coming months is to continue sharing this message with the 1500+ exhibitors and 70,000+ visitors at SPS IPC Drives, along with anyone else who wants to connect industrial process control systems to the IoT.

Part 8 of Data Communication for Industrial IoT

MQTT, or Message Queue Telemetry Transport, is a publish/subscribe messaging protocol that was originally created for resource-constrained devices over low-bandwidth networks. It is being actively promoted as an IoT protocol because it has a small footprint, is reasonably simple to use, and features “push” architecture.

MQTT works by allowing data sources like hardware devices to connect to a server called a “broker”, and publish their data to it. Any device or program that wants to receive the data can subscribe to that channel. Programs can act as both publishers and subscribers simultaneously. The broker does not examine the data payload itself, but simply passes it as a message from each publisher to all subscribers.

The publish/subscribe approach has advantages for general IoT applications. “Push” architecture is inherently more secure, because it avoids the client-server architecture problem, allowing devices to make outbound connections without opening any firewall ports. And, by using a central broker, it is possible to establish many-to-many connections, allowing multiple devices to connect to multiple clients. MQTT seems to solve the communication and security problems I have identified in previous posts.

Despite these architectural advantages, though, MQTT has three important drawbacks that raise questions about its suitability for many IIoT systems and scenarios.

MQTT is a messaging protocol, not a data protocol

MQTT is a messaging protocol, not a data communications protocol. It acts as a data transport layer, similar to TCP, but it does not specify a particular format for the data payload. The data format is determined by each client that connects, which means there is no interoperability between applications. For example, if data publisher A and subscriber B have not agreed on their data format in advance, it’s not likely that they’ll be able to communicate. They might send and receive messages via MQTT, but they’ll have no clue to what they mean.

Imagine an industrial device that talks MQTT, say a chip on a thermometer. Now, suppose you have an HMI client that supports MQTT, and you want to display the data from the thermometer. You should be able to connect them, right? In reality, you probably can’t. This is not OPC or some other industrial protocol that has invested heavily into interoperability. MQTT is explicitly not interoperable. It specifies that each client is free to use whatever data payload format it wants.

How can you make it work? You must either translate data protocols for each new connected device and client, or you need to source all devices, programs, HMIs, etc. from a single vendor, which quickly leads to vendor lock-in.

The broker cannot perform intelligent routing

MQTT brokers are designed to be agnostic to message content. This design choice can cause problems for industrial applications communicating over the IoT. Here are a few reasons why:

1) The broker cannot be intelligent about routing, based on message content. It simply passes along any message it gets. Even if a value has not changed, the message gets sent. There is no damping mechanism, so values can “ring” back and forth between clients, leading to wasted system resources and high bandwidth use.

2) The broker cannot distinguish between messages that contain new or previously transmitted values, to maintain consistency. The only alternative is to send all information to every client, consuming extra bandwidth in the process.

3) There is no supported discovery function because the broker is unaware of the data it is holding. A client cannot simply browse the data set on the broker when it connects. Rather, it needs to have a list of the topics from the broker or the data publisher before making the connection. This leads to duplication of configuration in every client. In small systems this may not be a problem, but it scales very poorly.

4) Clients cannot be told when data items become invalid. In a production system a client needs to know that the source of data has been disconnected, whether due to a network failure or an equipment failure. MQTT brokers do not have sufficient knowledge to do that. The broker would need to infer that when a client disconnects it needs to synthesize messages as if they had originated from that client indicating that the data in certain topics are no longer trustworthy. MQTT brokers do not know how to synthesize those messages, and since they don’t know the message format, they would not know what to put in them. For this reason alone MQTT is a questionable choice in a production environment.

5) There is no opportunity to run scripts or otherwise manipulate the data in real time to perform consolidation, interpretation, unit conversion, etc. Quite simply, if you don’t know the data format you cannot process it intelligently.

No acceptable quality of service

MQTT defines 3 levels of quality of service (QoS), none of which is right for the IIoT. This is an important topic and one that I have gone into depth about in a previous post (see Which Quality of Service is Right for IIoT?). MQTT might work for small-scale prototyping, but its QoS failure modes make it impractical at industrial scale.

In summary, although the MQTT messaging protocol is attracting interest for IoT applications, it is not the best solution for Industrial IoT.

Continue reading, or go back to Table of Contents