OPC UA to MQTT Bridge Patterns

Industrial automation environments increasingly demand a two-tier data strategy: OPC UA for real-time, deterministic plant-floor communication and MQTT for scalable, firewall-friendly edge-to-cloud telemetry. Bridging these two protocols is not a matter of choosing one over the other — it is about building a reliable, secure, and performant gateway that lets each protocol do what it does best.

This article examines the architectural patterns, tools, and configurations for bridging OPC UA to MQTT, with a focus on the Turkish and regional industrial automation market. We cover Kepware's MQTT Client driver, Node-RED as a lightweight bridge, topic mapping strategies, payload encoding options, security hardening, and cloud platform integration.

Why Bridge OPC UA to MQTT?

OPC UA and MQTT are complementary, not competitive. The table below summarises their respective strengths:

A bridge between the two lets you:

• Expose OPC UA data to cloud platforms (AWS IoT Core, Azure IoT Hub) that speak MQTT natively.
• Reduce firewall complexity — MQTT needs only one outbound port (8883) open, whereas OPC UA requires an inbound port.
• Scale data distribution — MQTT brokers fan out data to many subscribers without adding load to the source PLC or OPC server.
• Add edge processing — Filter, aggregate, or transform OPC UA data before publishing to the cloud.

Architecture Patterns

Pattern 1: Direct Bridge via Kepware MQTT Client

KEPServerEX includes a native MQTT Client driver that reads tags from any configured device and publishes them to an MQTT broker. This is the simplest pattern for Kepware shops:

  +------------------+     OPC UA / Driver     +------------------+
  |  PLC / RTU / DCS  |<---------------------->|  KEPServerEX      |
  +------------------+                          +--------+---------+
                                                          |
                                               MQTT Client Driver
                                                          |
                                                    MQTT/TLS
                                                          |
                                                    +-----v-----+
                                                    | MQTT      |
                                                    | Broker    |
                                                    +-----------+
                                                    |     |     |
                                                    v     v     v
                                                 SCADA  Cloud  Mobile

Configuration steps:

1. In KEPServerEX Administration, right-click Connectivity and select New Channel.
2. Choose the MQTT Client driver.
3. Set the broker URL (e.g., ssl://broker.hivemq.cloud:8883).
4. Configure authentication — username/password or client certificate.
5. Map tags to topics using the Topic Mapping editor.
6. Set the publish interval (default 1000 ms, adjustable per tag group).

Advantages: Zero additional software, seamless Kepware integration, supports all Kepware device drivers.

Limitations: Only publishes Kepware-resident tags; limited transformation capability; no built-in Sparkplug support (requires Advanced MQTT Client plug-in).

Pattern 2: Node-RED as a Lightweight Bridge

Node-RED is an excellent choice for custom bridging logic, especially when transformation, filtering, or enrichment is required:

  +----------+     OPC UA     +----------+     MQTT      +-----------+
  | PLC/DCS  |<-------------->| Node-RED |-------------->| MQTT      |
  |          |   Client/Server|          |   Publish     | Broker    |
  +----------+                +----------+               +-----------+

Key Node-RED nodes required:

• node-red-contrib-opcua — OPC UA client node for browsing and reading tags.
• node-red-contrib-mqtt-broker — Built-in MQTT output node.
• node-red-contrib-sparkplug — Sparkplug B payload encoding (available as community contribution).

Example flow snippet (JSON):

[{"id":"opcua1","type":"OPC UA Client","endpoint":"opc.tcp://192.168.1.100:49320"},
 {"id":"mqtt1","type":"mqtt out","topic":"factory/line1/temperature","qos":1},
 {"id":"function1","type":"function","func":"msg.payload = {ts: Date.now(), value: msg.payload}; return msg;"}]

Advantages: Extremely flexible, visual programming, large ecosystem of community nodes, easily containerised.

Limitations: Not certified for safety-critical use; performance degrades with thousands of tags; no built-in HA failover.

Pattern 3: Dedicated Edge Gateway Appliance

For large-scale deployments, dedicated edge gateways (e.g., Siemens IOT2050, Advantech WISE-750, or a hardened industrial PC running Linux) provide a purpose-built bridge:

  +------------------+     OPC UA     +------------------+     MQTT      +----------+
  | Multiple PLCs    |<-------------->| Edge Gateway     |-------------->| Cloud    |
  | (Siemens, AB,    |                | (Linux + Python   |              | Platform |
  |  Modbus, etc.)   |                |  + OPC UA Client) |              +----------+
  +------------------+                +------------------+

Typical software stack:

• Python with opcua-asyncio or freeopcua for OPC UA client.
• Eclipse Paho MQTT client library for Python.
• Docker for containerised deployment and update management.
• Local buffering via SQLite or InfluxDB for network outage resilience.

Topic Mapping Strategies

The topic hierarchy you choose directly affects scalability, security, and ease of consumption. Three common strategies are:

Flat Namespace

factory/temperature
factory/pressure
factory/flow

Use for: Small deployments (<50 tags), quick prototyping.

Hierarchical by Location

factory/line1/zone3/temperature/PV
factory/line1/zone3/pressure/PV
factory/line1/zone3/motor/speed

Use for: Multi-line, multi-zone facilities where operators need to subscribe to subsets of data.

Sparkplug B Namespace

spBv1.0/factory1/NDATA/edge01/temperature
spBv1.0/factory1/DDATA/edge01/motor01/speed

Use for: IIoT deployments requiring birth/death certificates, template definitions, and strict state management.

Payload Encoding: JSON vs. Sparkplug B

Recommendation: For cloud-only pipelines where a human may debug payloads, JSON is acceptable for small tag counts. For production IIoT deployments with hundreds of devices and strict data quality requirements, Sparkplug B is strongly preferred.

Security Considerations

Bridging OT data to MQTT introduces several attack surfaces. Address each systematically:

1. Transport encryption — Always use MQTT over TLS (port 8883). Disable plain TCP (port 1883) on the broker. Use TLS 1.2 minimum.
2. Client authentication — Require username/password or X.509 client certificates. Never allow anonymous access in production.
3. ACL enforcement — Configure topic-level Access Control Lists (ACLs) on the broker. An OPC bridge client should have publish access only to its designated topic tree.
4. OPC UA side — Run the bridge with a least-privilege OPC UA user account (read-only, scoped to required tags).
5. Network segmentation — Place the bridge in an industrial DMZ (Purdue Level 3.5), not directly on the plant floor (Level 0–2).
6. Rate limiting — Configure the broker to limit publish rates per client to prevent accidental or malicious flooding.

Cloud Platform Integration

AWS IoT Core

AWS IoT Core supports MQTT natively. Configure the bridge to publish to device-specific topics:

# AWS IoT Core topic format
$aws/things/{thingName}/shadow/update
# or custom topics with IoT Core rules engine:
factory/line1/data

• Use AWS IoT Core's Rules Engine to route data to DynamoDB, Timestream, or Lambda.
• Authenticate the bridge using X.509 device certificates provisioned in AWS IoT Core.
• Enable AWS IoT Core's MQTT Client ID as the edge node identifier for traceability.

Azure IoT Hub

Azure IoT Hub also speaks MQTT. The bridge connects as a device or module:

# Azure IoT Hub topic format
devices/{deviceId}/messages/events/

• Authenticate using SAS tokens or X.509 certificates. IoT Hub rejects unauthenticated connections.
• Use IoT Hub Message Routing to send telemetry to Blob Storage, Azure Data Explorer, or Stream Analytics.
• For Sparkplug payloads, add a base64 encoding layer since IoT Hub's MQTT implementation does not support raw binary in all tiers.

Performance Tuning

Getting bridge performance right requires attention to several knobs:

Monitoring the Bridge

A bridge is a single point of failure. Monitor these metrics:

• Published message rate — Sudden drops indicate a communication failure upstream (OPC UA) or downstream (MQTT).
• Last message timestamp — Alert if no messages arrive from a given bridge within 2× the publish interval.
• Broker queue depth — Rising queues indicate downstream consumers are falling behind.
• OPC UA session state — Confirm the bridge maintains a connected session to the OPC UA server.
• Memory and CPU — Especially for Node-RED or Python-based bridges; memory leaks are a known issue in long-running deployments.

Practical Example: Kepware to HiveMQ Cloud

Step-by-step for a real deployment:

1. Deploy KEPServerEX v6.8+ on a Windows Server in the industrial DMZ.
2. Configure a Siemens S7-1200 channel reading 50 tags from a packaging line PLC.
3. Add an MQTT Client channel, point it to ssl://xxx.s1.eu.hivemq.cloud:8883.
4. Create a topic alias: factory/packaging/line1/+ and map all 50 tags.
5. Set publish interval to 2000 ms, QoS 1, retain flag off.
6. On the HiveMQ side, create an ACL that allows this client to publish only under factory/packaging/.
7. Subscribe with a Node-RED instance (or directly from a cloud dashboard) to consume and visualise the data.

Key takeaway: An OPC UA to MQTT bridge is not a product you buy — it is a pattern you implement. Choose the tooling based on your team's skills, your existing software investments, and the scale of data you need to move. Start simple with Kepware's MQTT Client, evolve to Node-RED or a custom gateway as requirements grow.

---

References & Further Reading

1. OPC Foundation — OPC UA Specifications — Official OPC UA specification documents covering client-server and Pub/Sub communication patterns, security policies, and information modelling.
2. OASIS MQTT — Message Queuing Telemetry Transport Standard — Official MQTT specification for publish-subscribe messaging, including QoS levels, topic wildcards, and session management essential for bridge implementations.
3. PTC Kepware KEPServerEX — MQTT Client Driver Documentation — Official Kepware documentation for the MQTT Client driver, covering configuration, topic mapping, and TLS security for OPC UA to MQTT bridging.
4. Eclipse Tahu — Sparkplug B Specification for Industrial MQTT — Official Eclipse Foundation specification for Sparkplug B, providing the industrial payload standard and topic namespace for MQTT bridging.
5. Node-RED — Flow-Based Programming for IoT Integration — Official Node-RED documentation, including OPC UA and MQTT nodes for building custom protocol bridges with visual flow programming.