OPC UA to MQTT Gateway
for Scalable Industrial Data Flow
Proxus gives you an OPC UA to MQTT gateway that does more than relay tags. Browse industrial assets, map them into a clean topic structure, buffer through outages, and publish governed operational data through an industrial MQTT gateway pattern into your Unified Namespace.
Why teams look for an OPC UA to MQTT gateway
Most plants already expose valuable telemetry through OPC UA. The problem starts when you need that data in dashboards, analytics, UNS topics, or enterprise systems that work better with MQTT. A useful bridge must preserve structure, security, and delivery reliability, not just pass values from one protocol to another.
- done Normalize once so OT, IT, dashboards, and AI all read the same topic model.
- done Keep delivery outbound-only so plant-floor systems do not need inbound exposure.
- done Survive WAN interruptions with local buffering and ordered replay at the edge.
Bridge outcomes
Need a broader ingestion layer? Start with the Connectivity platform.
OPC UA to MQTT gateway vs a generic MQTT broker
A generic MQTT broker receives and distributes messages. An industrial gateway has to do more: connect to OPC UA sources, preserve asset context, map tags into stable topics, buffer through interruptions, and make the resulting stream usable for dashboards, data platforms, and IT systems.
- schema Topic mapping turns raw OPC UA node paths into site, line, asset, and metric topics.
- hub UNS readiness lets the same MQTT flow support broader Unified Namespace architectures.
- sync_alt Data platform delivery routes MQTT telemetry into storage, dashboards, MES, ERP, and AI workflows.
Best-fit searches
From OPC UA tags to usable MQTT topics
Proxus combines edge connectivity, topic mapping, and governance so the bridge becomes part of your operating model, not another one-off integration.
Connect to OPC UA servers, browse namespaces, and select only the tags, methods, or structures you want to expose.
Map signals into a governed MQTT hierarchy or UNS topic design so downstream systems stop depending on raw tag paths.
Run the bridge at the edge with local buffering, health monitoring, and controlled outbound delivery to MQTT brokers.
Built for plant-floor reliability
A production bridge cannot fail every time a WAN link drops or a broker restarts. Proxus runs the bridge with edge-local resilience patterns that keep collection and delivery consistent.
- cloud_off Store-and-forward protects telemetry during network outages.
- shield Outbound-only architecture reduces attack surface for OT networks.
- monitoring Central observability shows connection state, lag, and replay health.
Typical rollout
- 01 Connect an OPC UA endpoint on the edge gateway.
- 02 Map node paths into MQTT topics or a site-wide UNS structure.
- 03 Publish to your MQTT broker, cloud, or internal data consumers.
- 04 Reuse the same template across lines, plants, and OEM variants.
Factory dashboards
Feed MQTT topics into real-time dashboards without rewriting OPC UA browsing logic for every consumer.
Industrial data platforms
Bridge asset telemetry into an industrial data platform for storage, routing, and downstream integration.
IT and analytics consumers
Publish plant-floor context once, then fan it out to MES, ERP, lakes, and AI assistants through governed topics.
FAQ
Common questions buyers ask when evaluating an OPC UA to MQTT gateway.
Yes, but the stronger pattern is to map raw OPC UA structures into a stable industrial topic model before publishing.
No. It runs at the edge so collection, buffering, and local resilience stay close to the process.
Yes. The bridge fits naturally into UNS-style topic hierarchies and broader MQTT-based industrial architectures.
Proxus supports MQTT-based flows, but the higher-value pattern is the gateway layer around the broker: protocol ingestion, topic mapping, buffering, governance, and downstream delivery.
Technical and Commercial Evaluation
OPC UA to MQTT Gateway evaluation guide
Operational problem it addresses
OPC UA exposes rich industrial data, but enterprise and multi-site consumers often need a governed MQTT contract rather than direct sessions to every server. The gateway maps selected OPC UA nodes, metadata, and quality into stable MQTT topics without turning a generic broker into the data-model owner.
Data sources it connects
- OPC UA servers on PLCs, machines, SCADA, and gateway systems
- Selected nodes, values, timestamps, status codes, and supported metadata
- Asset and site context used to build the target MQTT topic model
How the data is processed
- 1.Establish a secured OPC UA client session and select the required nodes.
- 2.Normalize names, units, timestamps, quality, and asset context.
- 3.Map the resulting model to governed MQTT topics and payloads.
- 4.Publish through the approved broker with configured buffering, acknowledgements, and monitoring.
Edge and outage behavior
OPC UA source loss, broker loss, certificate failure, subscription resync, and target rejection are separate failure modes. Buffered MQTT delivery is limited by configured capacity and retention, while OPC UA history recovery depends on source capabilities and the chosen collection strategy.
Systems that consume the data
- UNS
- Industrial data platform
- Dashboards
- MES
- Data lake
- Analytics
- Cloud IoT services
Security and deployment boundary
Use explicit OPC UA trust, certificate validation, least-privilege source accounts, broker TLS, topic authorization, controlled outbound routes, and credential rotation. The gateway should not create an uncontrolled path from enterprise consumers back to machine control.
Technical validation and next step
When it is a good fit
- Several consumers need a reusable MQTT view of OPC UA data.
- OPC UA servers should remain isolated from direct enterprise connections.
- Topic mapping, quality handling, buffering, and observability must be governed.
When it is not a good fit
- A consumer needs full OPC UA method, alarm, or information-model semantics that the MQTT contract does not preserve.
- The design assumes every missed source sample can be reconstructed without OPC UA history support.
- Bidirectional machine control would be exposed without a separate authorization and safety design.
Evaluation FAQ
Does an OPC UA to MQTT gateway preserve the full OPC UA information model?
Not automatically. The MQTT contract preserves the values, context, quality, metadata, and hierarchy selected in the mapping. Methods, alarms, events, and complex information-model semantics require explicit design.
What happens when the MQTT broker is unavailable?
Configured outbound data can be buffered within capacity and retention limits. Recovery depends on acknowledgements, reconnect behavior, outage duration, data rate, and target availability.
Can MQTT consumers write back to OPC UA?
Writeback requires a separate command model, authorization, validation, audit, timeout, and safety boundary. It should not be inferred from the outbound telemetry bridge.