“Stop fighting the MQTT vs OPC UA war. It’s a trap. Real architecture demands both. OPC UA is the machine’s dictionary; MQTT is the cloud’s envelope. You need both to build a scalable Unified Namespace.

Key Takeaways

• Best Practice: Use OPC UA for local machine control and MQTT for enterprise data streaming.
  
• Security: Avoid opening inbound firewall ports for OPC UA. Misconfigurations here are a leading cause of OT cyber exposure.
  
• Efficiency: MQTT fixed headers are just 2 bytes; OPC UA secure sessions exchange kilobytes of certificates during handshakes.
  
• Context: Sparkplug B is the required standard to add data modelling (the “dictionary”) to MQTT.
  
• PubSub: OPC UA Part 14 offers PubSub, but MQTT 5.0 remains the dominant choice for cloud integration.
  

Table of Content

Comparison Table

Feature	OPC UA (Client/Server)	MQTT (Sparkplug B)
Primary Role	The Dictionary (Context)	The Envelope (Transport)
Standard	IEC 62541	OASIS MQTT 5.0 / ISO 20922
Network Architecture	Request / Response (Coupled)	Publish / Subscribe (Decoupled)
Security Posture	Inbound Ports (Misconfiguration Risk)	Outbound Only (Secure by Design)
Session Overhead	Heavy (Certificates + Handshake)	Light (Keep-Alive + Last Will)
Best For	Local Machine-to-Machine Control	Cloud / AI / Unified Namespace

The Envelope vs. Dictionary Analogy

Stop comparing these protocols like apples to apples. They serve fundamentally different purposes in the industrial IoT protocol stack architecture.

Think of MQTT (ISO/IEC 20922) as a standard envelope. It transports messages incredibly fast and light. It does not care if the message inside is a love letter or a ransom note; it just delivers the payload. It is decoupled and efficient.

Think of OPC UA (IEC 62541) as a dictionary. It defines the exact meaning of words. It ensures that “Temperature” specifically means “Celsius” and “Int32”. It is heavy, precise, and context-rich.

In the past, engineers debated the merits of Modbus, OPC UA, and MQTT. Today, the verdict is clear: use the dictionary (OPC UA) to talk to the machine and the envelope (MQTT) to mail that data to the cloud.

The Firewall Test: Why MQTT Wins the Cloud

This is the single biggest reason IT departments reject OPC UA for cloud connections. The classic OPC UA Client/Server model requires a handshake. To let a cloud server talk to your factory, you often have to punch a hole in your firewall.

Is OPC UA secure for internet-facing connections?

While the protocol supports strong security, real-world misconfigurations are common. Internet-exposed OPC UA servers without proper access control are a risk. Opening inbound ports exposes your PLC to these risks.

MQTT solves this with a publish/subscribe model. The device inside the factory pushes data out to a broker. The connection is outbound-only. No open ports. No IT nightmares.

Security Checklist for 2025

• Outbound Only: Ensure all cloud connections initiate from inside the factory (MQTT).
  
• TLS 1.3: Enforce encryption for both OPC UA (local) and MQTT (cloud).
  
• Disable Defaults: Change default ports (4840 for OPC UA, 1883 for MQTT) on any public interface.
  

The Bandwidth Battle: By the Numbers

If you are running cables, bandwidth is cheap. If you are using cellular 4G/5G gateways, every byte costs money.

An MQTT vs OPC UA overhead bandwidth comparison in 2025 reveals a stark difference.

1. MQTT 5.0 Efficiency

The MQTT fixed header is a minimum of 2 bytes (1 byte control + 1+ bytes for remaining length encoding). Even with a topic string (e.g., spBv1.0/Group/Node/Device) and variable header properties, a typical telemetry packet often stays under 100 bytes.

2. OPC UA Session Weight

OPC UA requires a “Secure Channel” before data flows. This involves a four-step handshake:

1. Hello
   
2. OpenSecureChannel (exchanges certificates — can be ~1–4 KB depending on key size)
   
3. CreateSession
   
4. ActivateSession
   

This chatter happens before you send a single sensor value.

Micro-Table: Bytes on the Wire (Estimated)

Action	MQTT (v5.0)	OPC UA (Binary)
Connect / Session	~60 Bytes	~3000+ Bytes (Cert Exchange)
Single Publish/Write	~30-50 Bytes	~150-600 Bytes
Keep Alive	2 Bytes (PINGREQ)	~50+ Bytes (Empty Response)

The 2025 Solution: Unified Namespace (UNS)

Don’t choose one. Bridge them.

The modern architecture is the Unified Namespace. You use OPC UA on the machine network (LAN) because it handles the complex data structures of PLCs perfectly. Then, you use an Edge Gateway to convert that data and publish it to MQTT.

The gateway acts as a translator. It subscribes to the OPC UA tags, strips the heavy overhead, and wraps the value in an MQTT envelope. This is bridging OPC UA to MQTT for Unified Namespace.

What about Context?

This is where Sparkplug B comes in. The debate of MQTT Sparkplug B vs OPC UA data modelling is settled by combining them. Sparkplug B (Eclipse TAHU) adds a standardised payload definition to MQTT. It essentially writes the dictionary inside the envelope.

Implementation: How to Bridge Them

You have a Siemens PLC. You want JSON in the cloud. How do you do it?

You need middleware. Tools like HighByte, Kepware, or Node-RED are essential here. They handle the task of converting Siemens OPC UA to MQTT JSON.

1. The Source (OPC UA Node)

Your gateway reads a specific node path from the PLC.

• Path: ns=2;s=MachineA.Motor.Temperature
  
• Action: MonitoredItem (Subscribe)
  

2. The Payload (Conversion)

The gateway converts that heavy node object into a lightweight payload.

Option A: Raw JSON (Simple)

{
  "machine_id": "Press_01",
  "temperature": 42.5,
  "timestamp": 1716234000
}

Option B: Sparkplug B (Standard — decoded view)

Sparkplug uses Google Protobuf for efficiency. When decoded to JSON, it looks like:

{
  "timestamp": 1716234000,
  "metrics": [{
    "name": "Temperature",
    "value": 42.5,
    "type": "Float"
  }]
}

Note: The actual Sparkplug B payload is binary/protobuf, making it smaller on the wire than equivalent JSON.

3. The Publish

The gateway pushes this to the broker on a structured topic:

spBv1.0/Plant1/DDATA/Line1/Press_01

Mini Case Study: Cellular Cost Reduction

A midstream oil & gas operator monitored 50 wellheads via cellular modems. Initially, they polled tags via OPC UA. The session heartbeat and handshake consumed ~300MB/month per site.

The Fix: They switched to an Edge Gateway pushing MQTT (Sparkplug B).

• Change: Polling stopped. Data is published only on change (Report by Exception).
  
• Result: Data usage dropped to <15MB/month per site.
  
• Savings: Latency reduced from 2 seconds to 200 ms.
  

FAQs

1. Can OPC UA replace MQTT?

Not effective for cloud scale. OPC UA PubSub (Part 14) exists, but native MQTT 5.0 is far more mature and supported by major cloud vendors.

2. Is MQTT secure?

Yes, when implemented correctly. It uses TLS encryption and supports client certificate authentication without opening dangerous inbound ports.

3. What is the Unified Namespace?

A single source of truth where all data lives; any consumer (ERP, AI, SCADA) can read from the broker instead of querying the PLC.

4. Why is OPC UA bad for 4G?

Its session-based architecture requires constant keep-alive chatter and certificate handshakes, which can consume cellular data.

5. Does MQTT lose data context?

Raw MQTT does. That is why Sparkplug B is used to enforce structure and schema.

Recommended Standards

• OPC UA: IEC 62541 Specification – The gold standard for machine modelling.

• MQTT 5.0: OASIS MQTT Standard – The bible for lightweight messaging.

• Sparkplug: Eclipse Sparkplug Specification – The guide for industrial context over MQTT.

Ready to Build Your Architecture?

Don’t let protocol wars stall your project. Use OPC UA for machine context, MQTT (with Sparkplug B) for cloud transport, and an Edge Gateway to build a scalable Unified Namespace.

Explore the Industry 4.0 Course at industryx.ai