OPC UA vs MQTT: not a choice between two competitors

They are not really competitors

The comparison gets framed as a choice.

But the two protocols were designed to solve different halves of the same problem.

OPC UA answers: what does this data mean?

A value does not arrive as a bare number. It arrives with a data type, an engineering unit, a quality flag, a timestamp, and a position in a structured address space that describes how it relates to everything else on that machine.

MQTT answers: how do I move this efficiently?

It is a publish and subscribe transport with a deliberately minimal footprint, designed for constrained devices and unreliable networks.

It makes no claim at all about what the payload contains.

Once framed that way, the “versus” mostly dissolves.

In most plants the question is not which one to standardise on. It is which one fits each connection.

What each one brings

	OPC UA	MQTT
Standard	IEC 62541	OASIS standard
Model	Client/server and pub/sub	Publish and subscribe via a broker
Payload meaning	Defined by the information model	Undefined, whatever you publish
Discovery	Built in, browse the address space	None, you must know the topics
Security	In the specification	Delegated to TLS and broker configuration
Overhead	Higher	Very low
Works well over	Reliable plant networks	Unreliable, high-latency, metered links
Typical fit	Machines, PLCs, process equipment	Sensors, remote sites, cellular links

The row that matters most is payload meaning.

With OPC UA, a client can connect to a machine it has never seen and browse what is available, with types and units attached.

With MQTT, a subscriber receives bytes on a topic and has to already know what they represent.

That is not a flaw in MQTT. It is the design decision that makes it small and fast.

But it means something else has to supply the structure.

Which is why Sparkplug B exists

Because plain MQTT says nothing about content, industrial users kept reinventing the same conventions.

How to name topics. How to know whether a device is alive. How to type a value.

Sparkplug B standardises that.

It defines a topic namespace, a birth and death certificate mechanism so subscribers know device state rather than inferring it from silence, and a typed payload format.

If you are building an industrial data layer on MQTT, you need some such convention. This is the one with the most adoption.

Worth noting: this makes the two protocols converge somewhat.

OPC UA gained a pub/sub profile that can run over MQTT. MQTT gained a structure specification.

The gap is narrower than the framing suggests.

Choosing per connection

Rather than standardising on one, most plants end up deciding connection by connection.

A few reliable rules.

Reach for OPC UA when:

• The equipment already speaks it, which most machinery built in the last decade does
• You want to browse what is available rather than maintain a tag list by hand
• Data types, units and quality flags matter to what you are building
• The network is a normal, reliable plant network

Reach for MQTT when:

• The device is constrained. Battery powered, limited memory, a simple sensor
• The link is unreliable, high-latency, or metered, such as a cellular connection to a remote site
• You are collecting from many endpoints where per-connection overhead adds up
• The site is remote and the connection cannot be assumed to stay up

And where neither applies: plenty of installed equipment speaks only Modbus TCP.

No information model, no security to speak of, and a register map you maintain yourself.

It is still worth connecting. A register that reliably reports running or stopped plus a unit count is enough to calculate availability and detect downtime.

Modbus remains extremely common in Indonesian plants. Refusing to support it in the name of modernity mostly means leaving equipment unmonitored.

The cost of translation hops

One consideration outlives the protocol debate.

How many times the data gets reshaped between the machine and the system that uses it.

A common architecture puts a gateway between equipment and MES, translating protocols and normalising tags.

Sometimes that is necessary. But each hop is a place where things go wrong.

Timestamps get replaced with arrival time rather than event time. Quality flags get dropped because the intermediate format has no field for them. Values get resampled and short events disappear between polls.

And a failure becomes silent, because the gateway keeps publishing the last known value.

That last one is the expensive failure.

A stalled gateway republishing stale data looks exactly like a machine running steadily.

OEE keeps computing, and the number is fiction.

The practical implication for choosing an MES is not which protocols are on the datasheet.

It is whether the system connects to them natively at the resource level, rather than through a translation layer per protocol.

Fewer hops, fewer places for meaning to leak out.

Where VECHR MES fits

VECHR MES connects natively over OPC UA, MQTT and Modbus TCP at the resource level.

Equipment attaches to the resource it belongs to, rather than to a separate integration layer that has to be mapped back afterwards.

Live tag values carry their quality flags. That is what allows a stale or bad reading to be distinguished from a genuine value, rather than quietly feeding OEE.

Those three protocols are what runs today. Others are on the roadmap rather than in the support list.

That distinction is worth insisting on with any vendor, since “supports” and “has customers running it in production” are not the same claim.

Because connectivity, execution and analytics sit on one platform, a tag value arrives already in context. Which resource, which production order, which material, which process step.

That context is what makes a downtime event traceable to a cause rather than merely counted.