MQTT Technology Solutions

What is MQTT?

MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol based on publish/subscribe. Devices do not send their data to a specific recipient; they publish it under a topic, such as plant1/hall3/press7/temperature, to a central broker. Every application subscribed to that topic receives the message. MQTT runs over TCP/IP, has been an OASIS standard since 2014 and, in version 3.1.1, is standardised as ISO/IEC 20922. The current version, MQTT 5, adds better error reporting and message metadata, among other things.

How MQTT is used in the IIoT

In industry, MQTT is primarily the transport between shop floor and IT: gateways and edge devices collect values from machines, sensors and controllers and send them via MQTT to a cloud platform, dashboard or database. Because publishers and subscribers do not need to know each other, an MQTT architecture scales easily. Three quality-of-service levels (QoS 0, 1 and 2), retained messages and the last-will message on disconnect make the protocol robust on unreliable networks such as cellular links. MQTT is also the backbone of most Unified Namespace architectures.

MQTT or OPC UA?

The two standards compete less than is often claimed. OPC UA describes machine data semantically, with data types, units and standardised information models, and is widespread in controllers and machines. MQTT moves data efficiently and at scale but does not define how a message is structured. In practice, a gateway reads data from the machine via OPC UA and distributes it via MQTT. If you want structure in the MQTT payload as well, use Sparkplug B or OPC UA PubSub over MQTT.

What an MQTT architecture looks like in practice

It usually starts with an edge gateway at the machine or in the control cabinet. It reads values via OPC UA, Modbus or IO-Link, converts them into MQTT messages and publishes them to a broker in the plant. There, dashboards, time-series databases and the MES subscribe to the topics they need. A bridge or a second broker in the cloud takes over selected data for cross-site analysis. If the external connection fails, the local level keeps running.

What to consider when choosing

The most important decision is the broker. Eclipse Mosquitto is lean and open source and sufficient for many single sites. For multiple sites, high availability and tens of thousands of connections, clustered brokers such as HiveMQ or EMQX or the cloud providers' MQTT services are the usual choice. Decide early on topic naming and payload format, because renaming later is expensive. And no broker belongs on a production network without TLS encryption and per-device authentication.