OPC UA vs MQTT: which protocol belongs where for production data

Anyone who wants to get production data off the shop floor soon comes up against the question of OPC UA vs MQTT. It is often asked as if you had to choose one. In fact the two protocols solve different problems. OPC UA is built to describe a machine together with the meaning of its data and to query it selectively. MQTT is built to distribute messages reliably and with little overhead across untrusted networks. There is a second question that matters at least as much: where does the computing happen, at the machine or in the cloud? This article explains both protocols, compares them and uses our condition monitoring for CNC spindles to show what an architecture looks like that combines the two sensibly.

OPC UA: client/server with an information model

At its core, OPC UA (Open Platform Communications Unified Architecture) follows the client/server principle. The CNC control runs an OPC UA server; a client connects, browses the address space and reads values, once or repeatedly. The standard port is 4840.

The real difference from simple protocols is the information model. An OPC UA server does not just deliver numbers but nodes with type, unit, description and relationships to one another. A client can browse the address space and find values via browse paths instead of relying on hard-wired addresses.

For machine tools there is a dedicated Companion Specification, OPC 40501, known as umati. It defines where a machine provides states, overrides, program information and alarms in a uniform model. For condition monitoring this has a limit: according to our reading of the specification, continuous process values such as spindle speed or spindle load are not part of the base model. They come from manufacturer-specific parts of the address space.

Security is built into OPC UA. Client and server each have an application certificate that the other side must explicitly classify as trusted. The security mode determines whether messages are only signed or signed and encrypted (Sign, SignAndEncrypt). The security policy determines the algorithms, for example Basic256Sha256. In addition, the client logs on with a user whose rights are defined on the control.

MQTT: publish/subscribe via a broker

MQTT works differently. There is no direct connection between data source and recipient. Both connect to a broker. The sender publishes messages under a topic; recipients subscribe to the topics they are interested in. The broker distributes them.

For reliability, MQTT has three Quality of Service levels:

• QoS 0: at most once. The message is sent but not acknowledged.
• QoS 1: at least once. The message is repeated until it is acknowledged. Duplicate delivery is possible.
• QoS 2: exactly once, with a more elaborate handshake.

For the IT department of a manufacturing company, one property is decisive: an MQTT client opens the connection to the broker itself and outbound. The box on the shop floor therefore does not need to be reachable from outside. The connection is secured with TLS; the standard port for this is 8883. With a client certificate, each device identifies itself to the broker without a password. Where port 8883 is blocked, MQTT can be run over secure WebSockets on port 443.

What MQTT does not provide is an information model. To the protocol, the content of a message is just a sequence of bytes. Which fields it has and what they mean must be defined by a separate data contract.

OPC UA and MQTT compared directly

The outcome of the comparison is not an either-or decision. OPC UA is strong where you need to understand a machine. MQTT is strong where data has to cross a firewall to a central platform. A good architecture uses each protocol for the section it was built for.

Our architecture: OPC UA on the shop floor, MQTT to the outside

Our condition monitoring for CNC spindles is split into three sections. Each uses the protocol that fits:

CNC control to box: OPC UA, read-only

SINUMERIK and HEIDENHAIN TNC controls offer OPC UA as a manufacturer option. There, the box is a pure read client. It queries values such as speed, load, program and alarms once per second. Technically, querying is limited to at most every 0.1 seconds so that the control is not put under load. Every request passes through a single point with an allowlist: read, browse, subscribe and session set-up are permitted. Writes, method calls and adding or deleting nodes are blocked before they leave the box. The connection uses SignAndEncrypt and Basic256Sha256, and the control's certificate is explicitly stored during set-up. Signal paths are determined on site from the address space with a read tool and entered in the configuration, not guessed. Details in the article Connecting SINUMERIK and HEIDENHAIN via OPC UA.

Sensor to box: our own measurement

The CNC control is not enough for bearing diagnostics. Its standard interfaces deliver values well below 1 kHz, whereas envelope analysis needs signals in the kilohertz range. That is why a vibration sensor measures directly on the spindle housing. The article Detecting rolling bearing damage early explains why.

Box to platform: MQTT over TLS, outbound only

The box sends its results to the platform via MQTT over TLS 1.2 or higher, on port 8883, otherwise via port 443. It opens no inbound port and cannot be reached from outside.

Edge or cloud: why raw data does not go to the cloud

The second fundamental question is where the computing happens. Our answer: signal analysis takes place on the box at the machine, evaluation over time on the platform. Raw signals do not leave the plant. There are three reasons for this.

Bandwidth. A vibration signal for bearing diagnostics is recorded at a sampling rate in the kilohertz range. Suppose one channel is sampled at 25.6 kHz with 4 bytes per value: that is around 100 kilobytes per second and just under 9 gigabytes per day, for a single channel without compression. The computed features, by contrast, are a few numbers per measurement window. For a company internet line that has other jobs to do as well, that is a considerable difference.

Data protection and know-how. A raw signal contains more than the bearing condition. From the tooth-passing frequencies you can draw conclusions about speeds, tools and cutting conditions. That is manufacturing know-how. The box therefore only transmits computed vibration features, speed, load, temperature, machine status and alarms. It does not read NC programs, tool offsets, drawings or operator data. A complete list is on the Data security page.

Latency and independence. Milliseconds do not matter for bearing diagnostics. Something else is decisive: a measurement window is only comparable if the spindle ran at constant speed during the measurement. The box therefore checks whether the speed reported by the control was the same before and after the window, within ±2 % and above 300 rpm. This linking of control data and vibration works most reliably where both signals are available at the same moment. In addition, the box keeps computing if the internet connection fails.

Buffering and delivery: no gaps and no duplicates

Networks fail, routers are restarted, firewall rules change. A condition monitoring system that loses data during these periods has gaps exactly when you need it. Our box therefore works on the store-and-forward principle:

1. Store: every computed record is first written to a local SQLite database and given a sequence number. The database is configured so that even a power cut does not lose stored data.
2. Send: the box sends a batch and waits for the platform to confirm that it has arrived and been stored. Only then does the next one follow.
3. Delete: only after this confirmation does the box delete the records from the buffer. If no confirmation arrives, it sends the batch again.
4. Detect duplicates: using the sequence numbers, the platform recognises what it already has and ignores repeats.

Why is MQTT with QoS 1 not simply enough? Because QoS 1 only covers the leg between box and broker. It does not tell the box whether the data actually ended up in the platform's database. Only the confirmation from the platform via a separate return channel closes this gap. Together with duplicate detection, this results in delivery without gaps and without duplicate values.

The buffer holds at least seven days. If the connection is down for longer, the oldest data is discarded and the loss is reported, rather than letting the disk fill up.

What the IT department needs to know

• Firewall: box to CNC control on port 4840 (OPC UA), box to platform on port 8883, otherwise 443. From outside to the box: no connection.
• Device identity: every box has its own certificate. The private key is generated on the box and never leaves it. There is no password login.
• Tenant separation: each box may only publish to the broker under its own identifier. Which customer belongs to which box is decided by the platform alone.
• TLS inspection: if the firewall uses TLS inspection, the box needs an exception. Otherwise mutual certificate validation fails and nothing is transmitted.
• Updates and storage location: the box only installs signed updates. Processing and storage take place exclusively in data centres in Germany.

The page Process describes the steps from initial assessment to connection. For a technical conversation with your IT team, use Contact.

Frequently asked questions