Quick History of MQTT
MQTT is a machine-to-machine network protocol that is uses a publish-subscribe architecture for transmitting data. MQTT originally stood for Message Queuing Telemetry Transport. However, due to the changing nature of the protocol, the specification body in charge of MQTT has since dropped the full name and it is now simply MQTT.
The protocol was invented in the late 90’s to monitor remote oil pipelines. It was ideal for the job because MQTT is super lightweight and efficient and therefore could be easily transmitted via expensive satellite communication. MQTT has since found success in messaging applications like Facebook Messenger, However, today, due to its lightweight efficiency, MQTT is poised to be a major factor in industry 4.0.
What is MQTT?
MQTT is simple. The protocol is between two types of entities: a broker and its clients. The MQTT broker publishes data based of specific topics. Various clients can then subscribe to relevant topics. In addition, MQTT is bi-directional, so these clients can submit data to the broker.
The Benefits for Manufacturing
Lightweight and Simple
MQTT has done a remarkable job of maintaining its origins as an efficient, lightweight protocol. Therefore, it is a low bandwidth method of commuication and requires little power. Power and transmission capabilities are a premium in mobile IOT devices, so MQTT is a natural choice.
Publish-Subscribe architecture:
This publish-subscribe architecture offers the factory automation industry a big advantage over traditional server-client connections. Namely, the clients simply subscribe to a topic from the MQTT broker, rather than having to set up a server-client connection for each data stream. This makes the network significantly more scalable to large numbers of subscribers.
Publish-Subscribe Architecture
Secure by default
One big advantage of MQTT is its inherent security, especially given its simplicity. MQTT messages use TLS encryption. MQTT connections can require username and password credentials. For added security, the authorization and authentication can instead be achieved with a certificate file from the client that would match the file on the broker. Finally, because MQTT is streaming bare-bones data, the server does not need any information from the edge devices, so they only open the outbound connections.
In other protocols like OPC UA, the server needs data modeling information From the edge devices resulting in an insecure inbound connection. Manufacturers are growing more concerned about security and I believe MQTT provides enough inherent security features that additional measures are not needed.
Where MQTT is Currently Used
In theory, MQTT can exist at all levels of the automation stack, all the way down to reading sensor data. Eventually, MQTT will likely be used to send data from edge devices directly to a Unified Namespace. In practicality, MQTT is currently most useful for communication between the MES and the SCADA system. Essentially this means that MQTT is used to take data from the factory floor to the higher level data storage and processing servers, which could either be on-site or cloud based. The great thing about MQTT is there is so much data on the factory floor, that it seems intuitive to just get it all to another server that can then begin sorting through it. This is one of the driving ideas behind the Unified Namespace.
The alternative approach is to have devices model data in a complex and clearly defined way, then send that modeled data to be stored and analyzed. With MQTT you are simply breaking data streams up into topics and sending them securely and efficiently to a server. From there, other protocols and tools (such as Sparkplug, Kafka, GraphQL) can help to model, query, and analyze that data. Currently, most SCADA and MES systems are equipped to communicate via MQTT. HiveMQ is a great tool for creating a Unified Namespace that communicates with MQTT. They created the graphic below that helps show the potential use of MQTT.
Credit: HiveMQ.com