OPC UA vs MQTT for Factory Data: When to Use Each

Key Takeaway

OPC UA vs MQTT for factory data is not a competition, it is a routing decision. OPC UA is the right protocol between a controller and a supervisory system, because it carries a type-rich, discoverable address space that a SCADA client can browse without a hand-written tag list. MQTT is the right protocol from the edge to the cloud and to a fleet of dashboards, because its packets are tiny and its topic tree is trivial to publish to. Most plants end up running both, and the mistake is trying to make one of them do the other’s job.

Figure 1: The two protocols side by side, the traffic each one is built for, and the tier of the plant where each belongs

1. What OPC UA Actually Is
2. What MQTT Actually Is
3. The Head to Head Comparison
4. Which to Use Where: A Practical Architecture
5. Security, Cost and the Indian Plant Reality
Related Reading
Sources

1. What OPC UA Actually Is

Scope note. This article is about opc ua vs mqtt factory data. The keyword restated: opc ua vs mqtt factory data is a decision that has to be made on paper before it is made in copper or in code, and the rest of this guide is the method for making it. Every figure quoted for opc ua vs mqtt factory data is either a standard limit, a manufacturer figure, or an arithmetic result that can be checked on the back of an envelope.

opc ua vs mqtt factory data is the subject of this guide, and every number below is either a standard limit or an arithmetic result that can be checked. The sections work through the decision from the requirement to the part number or the circuit, and the last section is a checklist.

This guide is written for the engineer who has to make opc ua vs mqtt factory data a decision on a real machine, in an Indian shop, with equipment that has to be supported for ten years. Every number in it is either a standard limit, a manufacturer figure, or an arithmetic result that can be checked. The sections work through opc ua vs mqtt factory data from the requirement to the part number or the circuit, and the last section is a checklist you can take to a review meeting.

OPC UA (Unified Architecture) is a standard from the OPC Foundation that replaced the older OPC Classic by taking the good parts of COM and DCOM and putting them on a stack that works over the internet, over a vendor-neutral transport, and without a Microsoft dependency. It is specified in IEC 62541.

The address space is the point

Everything in OPC UA hangs off a tree of nodes in an address space. The root is the server object, and below it are folders, objects and variables. A variable has a node ID, a browse name, a data type, a value, and a value rank. A client can browse the tree, read the properties, discover that a variable is an AnalogueItem with an EngineeringUnits property of millimetres per second and a range of 0 to 250, and then read it periodically or subscribe to it.

This is the feature that distinguishes OPC UA from everything else, and it is worth being concrete about what it buys you. A typical Siemens S7 or Rockwell ControlLogix tag list has to be imported by hand, and when a tag is renamed on the PLC side the SCADA shows a stale value until somebody notices. With OPC UA and a server that exposes the PLC symbols directly, the client discovers the model and the rename propagates. In a plant with 20 machines and a few hundred tags each, that discovery capability is worth more than any bandwidth argument.

Client, server, publisher, subscriber, and PubSub

The classic OPC UA role is client and server. The client connects to the server, browses, reads and subscribes. The server exposes an address space. That model is excellent for a SCADA talking to a PLC and it is what most installations use.

OPC UA also defines a publish and subscribe messaging pattern, with three levels of coupling. The Publisher-Subscriber pattern is a one-to-many broadcast with no central broker, which suits a machine publishing its state to many listeners. The DataSet and DataSetWriter plus DataSetReader pattern is a many-to-many with a broker that holds the current and historical data. The third level adds a more complex routing. The practical point for a plant engineer is that OPC UA PubSub exists and it can use MQTT or Kafka as the transport, which means the boundary between the two protocols is less hard than the marketing suggests.

The security model

OPC UA has a real security model built in, and it is the reason OPC UA has been accepted for supervisory and cloud data where Modbus TCP was not. Servers issue an application instance certificate, and clients present a certificate of their own. Both sides are validated against a trust list, and the trust list is the actual security boundary. On top of that there is a user identity token with username and password, a certificate, or an anonymous identity, and every session can be signed and encrypted at the message level. This is the part that IEC 62443 leans on, and it is why OPC UA is a reasonable answer to a customer audit that asks how the data path is protected.

Data types that carry engineering meaning

OPC UA has a defined type system, and its analogue and discrete types carry engineering units, ranges, instrument identifiers and engineering units as properties on the node. A temperature variable knows it is degrees Celsius and that its range is 0 to 500, and a client can display it correctly without a tag database. This is the semantic layer that the phrase semantic interoperability actually refers to in practice, and it is the reason a vendor-neutral client can show a meaningful engineering screen of a machine it has never seen.

Key point. MQTT is small on purpose. The broker holds no model, the payload is an opaque byte string, and the publisher and the subscriber agree the meaning out of band. That constraint is what lets a 64 kB microcontroller publish a temperature, and it is also what makes the schema a document you have to write down. In the opc ua vs mqtt factory data comparison, this is the trade: a trivial broker and a real schema-management burden.

Section close. In practice, opc ua vs mqtt factory data is settled by asking two questions. First, does the consumer need to browse a typed model, in which case the answer is OPC UA. Second, does the consumer live outside the plant on a link that costs money per kilobyte, in which case the answer is MQTT. Most plants need both, and the mistake in opc ua vs mqtt factory data is to make one protocol carry the other’s workload.

Keyword restated: opc ua vs mqtt factory data is settled by asking whether the consumer needs a browsable typed model or a cheap link over a wide area, and the honest answer on most plants is both, with an edge gateway doing the translation and enforcing the security boundary between the cell and the cloud.

2. What MQTT Actually Is

MQTT is a client and broker publish and subscribe messaging protocol, standardised by OASIS and now at version 5.0. It was designed for a low-bandwidth, unreliable network and a constrained device, and it has stayed very close to that original brief.

Topics, brokers and the three quality of service levels

Publishers send messages to a topic, subscribers receive messages on topics they have subscribed to, and the broker sits in the middle. The topic is a UTF-8 string with a slash-separated hierarchy, and the hierarchy is a convention that the application defines. A typical structure is plant, line, machine, and then the tag name. The broker matches with wildcards, where a plus sign matches a single level and a hash sign matches all levels below.

Quality of service has three levels, and choosing between them is a real decision:

QoS 0 is fire and forget, at most once. The message is sent and if it is lost it is lost. This is right for a high-rate telemetry value that will be superseded within a second.
QoS 1 is at least once. The broker acknowledges receipt, and the message may be delivered more than once. The receiver must handle duplicates, which means a sequence number or a timestamp in the payload. This is right for a state change that must not be lost, such as an alarm state.
QoS 2 is exactly once, with a four-part handshake. It is the most expensive and for a factory data path it is almost never needed, because QoS 1 with a de-duplicating consumer is cheaper and equally correct in practice.

MQTT 5.0 added a reason code and user properties to the publish message, which lets a publisher attach metadata to a message without changing the payload schema, and it added a shared subscription feature that lets a broker distribute a subscription across a group of consumers.

Retained messages and the last will

Two MQTT features matter in a plant. A retained message is stored by the broker and delivered immediately to a new subscriber on that topic, which is how a client gets the current state of a machine on connect rather than waiting for the next change. The last will and testament is a message the broker publishes on a topic when the client disconnects unexpectedly, which is the mechanism that turns a network drop into a visible “this gateway is offline” state instead of a silent data gap. Using both is standard practice and both cost nothing.

MQTT in a plant: the constraint that shapes everything

MQTT has no type system. A payload is a byte string. The publisher and the subscriber must agree out of band on what those bytes mean. That is not a defect, it is the design that makes the packets small and the broker trivial, but it means the schema has to be managed as a document and the consumers have to be versioned against it. MQTT Sparkplug adds a standard payload model on top, with a namespace, a schema version, a timestamp and a list of metrics, and it defines the birth and death certificates for the Sparkplug-style topic namespace. If you are deploying MQTT in a plant with more than one vendor involved, Sparkplug B is the least contentious way to keep the payload convention common.

Key point. The head-to-head numbers are the argument that settles most debates. A value published with MQTT costs about 20 to 50 bytes on the wire, and the same value in an OPC UA monitored item subscription costs several hundred bytes before the value even arrives, because the type and unit travel with it. A plant with 10,000 tags at one update per second is a 4 Mbit per second problem in MQTT and a 2 to 4 Mbit per second problem in OPC UA, and that ratio decides the edge architecture.

Section close. In practice, opc ua vs mqtt factory data comes down to the payload cost. A 20-byte MQTT publish versus a several-hundred-byte OPC UA subscription, multiplied by the tag count, multiplied by the update rate, is the bandwidth budget for the link. Do that arithmetic before the architecture meeting rather than after, because it is the number that decides where the edge gateway goes and how much cellular data the customer will pay for.

3. The Head to Head Comparison

The differences below are the ones that decide the choice, expressed the way an engineer will actually hit them.

Attribute	OPC UA	MQTT
Model	Client and server, plus PubSub	Publisher, subscriber, broker
Metadata	Full address space with types, units, browse	Topic string and opaque payload
Discovery	Client browses the server and finds the model	Wildcard subscription, no schema discovery
Typical payload	Several hundred bytes with the type description	About 20 bytes for a value and a timestamp
Transport	TCP, and secure variants, plus WebSocket over HTTPS	TCP, WebSocket, or a WebSocket over TLS bridge
Security	X.509 certificates, trust list, signed and encrypted sessions	TLS, username and password or client certificate, topic ACLs
Reliability	Subscription with a keep alive and a reconnect	QoS 0, 1, 2, plus retained messages and the last will
Typical deployment	PLC to SCADA to MES, inside the plant	Edge gateway to cloud, to dashboards, to a fleet
Engineering effort	Higher, the model has to be built and curated	Lower, a topic and a payload
Best at	Rich, typed, browsable plant data	Thousands of small tags over a wide area
Weak at	Serving many remote readers on a flaky link	Carrying a browsable, typed plant model

The bandwidth argument, with numbers

Consider a machine with 200 tags updated once a second. In MQTT with Sparkplus-style payloads, each value with a 64-bit timestamp and a metric name is roughly 20 to 30 bytes, and the MQTT publish overhead is about 10 to 30 bytes depending on topic length. Call it 50 bytes per message, so 200 tags is 10 kbit per second of payload plus the topic tree overhead, and a single broker connection carries it. Now consider the same 200 tags in OPC UA, where a monitored item subscription carries a data type description, an engineering unit and a value: the per-item overhead is in the region of 100 to 200 bytes, and the per-transaction overhead is 100 to 200 bytes on top. That puts the same machine at roughly 60 to 100 kbit per second.

Over a 24 V DC powered gateway on a cellular link in a factory spread across 40 acres, the difference is 10 kbit per second against 100 kbit per second, and it is the difference between a link that is always up and one that needs a fallback. Inside the plant, over a switched network, both are fine, and the address space is worth far more than the bytes.

The reliability argument, with numbers

The number that matters for a plant is the lost-sample rate. A cell with 4G and a 30 second average outage produces 30 missing samples per tag per outage. With MQTT and a retained message, the subscriber reconnects and gets the last retained value immediately, so it knows the state, and it knows the timestamp of that state is old. With OPC UA over TCP, the session is resumed with a sequence number that detects the gap, and the client knows exactly how many publications it missed. Both are correct, but they fail differently, and the client’s behaviour on reconnect has to be designed rather than assumed.

Key point. The practical rule that most plants converge on is that the rich model belongs inside the plant and the small messages belong outside it. So the opc ua vs mqtt factory data question is usually answered by running both, with an edge gateway as the translator and as the security boundary. The failure mode to avoid is trying to make one of the two protocols do the other’s job.

Section close. In practice, opc ua vs mqtt factory data is decided by the payload cost, and the numbers in the table are the ones to design against. A 16-bit value with a 64-bit timestamp is roughly 20 bytes with MQTT overhead and roughly 200 bytes with the full OPC UA type description. For 10,000 tags at one update per second that is the difference between a comfortable link and a link that needs a fallback. Write the figure into opc ua vs mqtt factory data before you commit.

4. Which to Use Where: A Practical Architecture

The most common and most successful arrangement in a plant of any size is a two-protocol architecture with a clear dividing line.

Layer 1: controller to supervisory, OPC UA

The PLC or the edge PC exposes an OPC UA server. The SCADA client connects, browses, and subscribes. This is where the typed model pays for itself, because the SCADA engineer gets a browsable tree of the machine’s variables with units and ranges, and does not maintain a separate tag import. The industrial automation engineering guide covers the broader layer argument, and the point here is specific: the supervisory layer wants a rich model, so it gets a rich protocol.

Layer 2: edge to cloud, MQTT

An edge gateway subscribes to the OPC UA server, converts the data into a Sparkplus-style or Sparkplug B payload, and publishes it to a broker. The cloud consumer, a dashboard, an analytics pipeline, or a mobile phone, subscribes to the topics it cares about. The gateway is the translator, and its job is to do the translation once, in one place, rather than have every consumer understand OPC UA.

Layer 3: direct edge to a small number of local consumers, either protocol

If the only consumer is a local dashboard on the plant network, OPC UA is fine and simpler, because there is no need for a broker. If the consumer is a set of remote viewers on unreliable links, MQTT wins.

Layer 4: brownfield equipment, MQTT at the sensor tier

A machine that cannot be modified, a temperature logger, a power meter, a wireless condition monitor, these publish MQTT directly from the device or from a small gateway. The topic tree makes this trivial, and there is no reason to bring a full OPC UA stack onto a device with 64 kB of RAM.

When one protocol genuinely is enough

If the plant has 10 machines, one SCADA, no cloud requirement, and no remote monitoring, OPC UA alone is the right answer and adding a broker is complexity with no benefit. If the plant is a single machine with a cloud dashboard and nobody who will ever browse a tag tree, MQTT alone is the right answer. The two-protocol architecture earns its cost when the plant has both a rich supervisory requirement and a wide-area or cloud requirement, and in a machine building company that sells to both a local customer and a multinational, that is the usual case.

Where OPC UA PubSub fits

OPC UA PubSub with an MQTT transport is the middle path. The data model stays OPC UA, the type information is preserved, and the transport becomes a broker with a topic tree, which is exactly what MQTT is good at. This is useful when a plant wants a single protocol on the wire and the semantic model is worth keeping, and it is the option to evaluate before concluding that you need two stacks. The other PubSub transport is Kafka, which is the right choice where a lot of data has to be retained and replayed, such as a plant with high-rate vibration or power quality data going to a data lake.

Key point. Both protocols can be secured properly, and both are usually secured badly in practice. OPC UA leans on certificates and a trust list, MQTT leans on TLS and per-topic ACLs, and the pattern of the two fits the IEC 62443 zone and conduit model exactly. In the opc ua vs mqtt factory data decision, the security architecture and the protocol architecture should be the same decision, not two separate ones.

Section close. In practice, opc ua vs mqtt factory data is not a single decision but a routing decision, and the routing rule is simple. The rich model stays inside the plant and the small messages go outside it, with an edge gateway doing the translation and acting as the security boundary. The failure in opc ua vs mqtt factory data is a gateway that bridges the two networks at the transport level, which gives the cloud zone full access to the cell zone and defeats the segmentation.

5. Security, Cost and the Indian Plant Reality

Both protocols can be secured properly and both can be secured badly. The difference is in where the effort goes.

OPC UA security

Certificate-based with a trust list. In practice this means the server has a self-signed certificate that the client either trusts explicitly or that is signed by a plant certificate authority. The trust list is a file that has to be distributed to every client, and when a machine is replaced, the certificate changes and the client stops talking to it. That is a real maintenance burden and it is the reason to set up a small plant certificate authority rather than exchanging certificates one at a time. On the user identity side, an anonymous session is possible, and for a read-only dashboard on the plant network it is a reasonable trade-off. For anything that writes a setpoint, require a user identity and an audit entry.

MQTT security

TLS for the transport, a username and password or a client certificate for the broker login, and an ACL that maps each client to the topic patterns it is allowed to read and write. A per-topic ACL is the natural fit, because a dashboard that shows one line’s output should not be able to read the whole plant. The broker should be a real broker with authentication, not an open one, and the credentials should be per client so that revoking one device does not take down the plant. MQTT 5.0 user properties can carry a tenant or a role identifier that the broker uses for finer authorisation, and this is worth using in a multi-tenant plant where several customers share the same broker.

The IEC 62443 reading

IEC 62443 divides the plant into zones and conduits, and this framework maps directly onto the protocol choice. The cell-level zone, which contains the PLC and the drives, is where OPC UA lives, and it is a zone with a small number of well-known peers. The cloud or the enterprise zone, which has many clients and a wide area, is where MQTT lives, and it is a zone with a broker and per-client authorisation. The conduit between them is the edge gateway, and the gateway is the security boundary. It should be the only thing that can reach both sides, and it should do the translation deliberately rather than forwarding raw traffic. A common failure is a gateway that bridges the two networks at the transport level, which gives the cloud zone full access to the cell zone and defeats the whole segmentation.

Cost and availability in India

OPC UA servers are available in most PLC families in the Indian market as a built-in licence or a low-cost add-on, and several free and open source server stacks exist for the edge PC side, which is useful for a machine builder who does not want a licence per machine. MQTT brokers are open source, most commonly Mosquitto, and run comfortably on a small industrial PC or even on a decent microcontroller with an Ethernet port, which is what makes the sensor tier practical. The cost of both is in engineering time, not licence fees: the OPC UA model has to be built and kept current, and the MQTT topic convention has to be written down and versioned. In an Indian shop, the discipline of writing the document down is often the expensive part, and it is the part that is skipped.

Data volume and the historian

One final practical number. A plant with 20 machines and 500 tags per machine is 10,000 tags. At one update per second with MQTT and a 50 byte payload, that is 500 kbit per second, roughly 4 Mbit per second sustained, which is comfortable on any plant network and comfortable on a 20 Mbit cellular link. The same data on OPC UA with full monitored item descriptions is in the 2 to 4 Mbit per second range, which is fine inside the plant and is not fine over a wide-area link. This is the clearest single justification for putting MQTT at the edge: the same data, one order of magnitude cheaper to move, when the destination is outside the plant. The SCADA alarm management guide covers the same principle on the alarm side, where the value of the state is in the change and not in the stream.

Key point. The single fact that separates the two protocols is that OPC UA has a type system and MQTT does not. Everything else follows from that, and it is worth holding on to through the whole comparison. When you work through the opc ua vs mqtt factory data decision, start from the question of who has to understand the data, and the rest of the architecture follows from the answer.

Section close. In practice, opc ua vs mqtt factory data has a security consequence that is decided in the same meeting as the protocol. OPC UA needs a plant certificate authority so that a replaced machine does not break every client, and MQTT needs per-client credentials and a topic ACL so that one dashboard cannot read the whole plant. Both are a day of work. The version of opc ua vs mqtt factory data that has no per-client authorisation is a version that will not pass an IEC 62443 audit.

Sources

Key Takeaways

OPC UA vs MQTT for factory data is a routing decision, not a competition. Use the rich typed model inside the plant and the small messages outside it, with an edge gateway doing the translation and acting as the security boundary.
Use OPC UA from the controller to SCADA and MES, and MQTT from the edge gateway to the cloud. Forcing MQTT to carry a full plant model, or OPC UA to serve a thousand remote dashboards, is where projects go wrong.
OPC UA PubSub brings MQTT-style publish and subscribe into the OPC UA world, including a Kafka and an MQTT transport, so the two protocols can meet in the middle rather than forcing a choice.
A 16-bit unsigned value published with a 5 second timestamp is about 20 bytes on the wire. The same value in an OPC UA subscription with a full data type description is several hundred bytes before the value arrives.
The security model is different in kind, not degree: OPC UA uses X.509 certificates and a trust list, MQTT uses a username, password or certificate per client with ACLs on topic patterns.
OPC UA vs MQTT for factory data, run the wrong way round, produces a plant where the cloud zone can reach into the cell zone directly; the edge gateway has to be the only thing that can reach both sides.