What an OPC UA Broker Actually Does (and What It Doesn't)

The term "broker" has a problem in industrial software. A vendor selling an OPC UA server might call it a broker. An MQTT middleware layer is technically a broker. A Unified Namespace hub often gets called a broker. A historian with a REST API has been called a broker too.

When every product claims the same label, the label stops working. This post defines what an industrial data broker actually is, maps the adjacent categories so you can tell them apart, and explains where OPC Data Wrangler sits on that map.

---

The OPC UA Server

Start here, because everything else builds from it.

An OPC UA server hosts an address space. That address space is a tree of nodes: variables, objects, methods, and event sources. A client connects, browses the tree, reads variables, subscribes to data changes, or calls methods. The server side owns the data; the client side consumes it.

OPC UA Part 1 of the specification defines the architecture. Part 4 defines the services (session, browse, read, write, subscription). A server does not push data to arbitrary targets; it waits for clients to connect and ask.

This matters because an OPC UA server alone cannot route data from a Siemens PLC to an Azure Event Hub. That is not what it is designed to do. It can expose the PLC data to a subscribing client, but the client is responsible for deciding what to do with it next.

Kepware and similar products are, at their core, OPC UA servers with connectivity drivers layered underneath. They read from PLCs and expose that data as OPC UA nodes. The client side remains your problem.

---

The MQTT Broker

An MQTT broker is a publish/subscribe message router. Publishers push messages to topics; the broker holds them and forwards to subscribers. That's it. There is no address space, no browsing, no schema, no concept of a tag. A topic is a string like factory/line-3/temp-sensor-4. The payload is whatever bytes the publisher decided to send.

MQTT works well for lightweight telemetry from sensors and PLCs that have an MQTT client library. It is poor at data discovery (you cannot browse topics like you browse OPC UA nodes), poor at historical access (no subscription semantics that guarantee delivery ordering with timestamps), and poor at schema enforcement (anything can publish anything to a topic).

The broker is the infrastructure layer. It does not transform, validate, or route intelligently. It delivers.

---

The Unified Namespace Hub

The Unified Namespace (UNS) is an architecture, not a product category. The idea comes from Walker Reynolds and others: treat your factory as a single message bus where every piece of information has one authoritative address, like enterprise/site/area/line/cell/device/data-point. All producers publish there; all consumers subscribe there. No point-to-point integrations.

In practice, most UNS implementations run on top of an MQTT broker (HiveMQ, EMQX, VerneMQ). The broker provides the infrastructure; the UNS discipline provides the naming convention, the payload standard (usually Sparkplug B or plain JSON with an agreed schema), and the governance layer that prevents two systems publishing contradictory data to the same address.

A UNS hub is not a data broker in the sense used here. It is a discipline applied to a message bus. The distinction: a UNS hub accepts data from producers and makes it available to consumers with minimal transformation. An industrial data broker, as defined below, transforms, routes, and integrates across dissimilar systems.

---

The Industrial Data Broker

An industrial data broker sits at the integration layer. It pulls from multiple data sources (OPC UA servers, historians, PLCs, databases, REST APIs), transforms what it receives (unit conversion, tag normalization, protocol translation, filtering), and routes results to one or more sinks (cloud storage, data warehouses, UNS topics, BI tools, other systems).

The broker owns the pipeline between sources and consumers. It is stateful where required: it can buffer data during connectivity interruptions, deduplicate, timestamp-correct, or apply windowed aggregations. It defines the transformation logic in a way that operators or engineers can inspect and change without writing code.

The key boundaries:

• It is not a SCADA. It does not drive control. It does not render HMI screens or execute setpoints.
• It is not a historian. It may write to a historian, but the historian holds the time-series archive; the broker holds the pipeline.
• It is not a UNS in itself. It can publish to a UNS topic as one of its sinks, but the UNS is the destination, not the broker's identity.
• It does not replace the OPC UA server. The OPC UA server stays at the device layer and exposes machine data. The broker connects to it as a client.

---

Where OPC Data Wrangler Fits

OPC Data Wrangler is an industrial data broker in the sense above. It connects to OPC UA servers as a client, subscribes to node changes, and routes that data to configurable sinks. The pipeline is defined in configuration, with a configuration-as-code option for sophisticated teams that want their pipelines under GitHub or DevOps version control.

Current protocol coverage: OPC UA on the ingestion side, multiple sink options on the output side. Modbus, MQTT, and REST ingestion are on the roadmap; if those matter to your integration, ask before assuming they're ready.

What it is not: it is not a historian, not a SCADA replacement, and not a UNS hub. If your primary problem is "I need to expose my PLC data as OPC UA nodes to existing SCADA clients," an OPC UA server like Kepware or a native device server solves that.

The OPC Data Wrangler problem is configurable ETL with the emphasis on the T: synchronizing data between systems while transforming what flows through. Examples that show up on real plant floors: normalizing units when sensors report metric and the consuming system expects imperial, smoothing or filtering noisy signals before they hit a downstream model, applying real-time cleanup rules so bad reads don't propagate, or acting as a bridge between two OPC UA servers across a network boundary to pump data into a DMZ. Cloud routing to a Snowflake, S3, or Azure data lake is one possible sink among many; it is not the defining use case.

The honest competitive set is not OPC UA servers. It is the ETL tooling that data engineers reach for when they need to move time-series and event data from operational systems to analytics destinations. Most of those tools are cloud-only and price by data volume, which works against you when you have a continuous stream of plant-floor data running at high cardinality. OPC Data Wrangler is cloud-native by design but also runs on-premises and at the edge, so the same pipeline definition holds whether the operating profile is "ship everything to a data lake" or "transform locally, send aggregates upstream." The pricing is not bandwidth-coupled. That is the real wedge for industrial workloads.

---

Choosing the Right Layer

The layers are not competing; they stack.

A PLC exposes data through its native protocol. An OPC UA server (Kepware or a native server built into the device) translates that to OPC UA. An industrial data broker (OPC Data Wrangler) connects to the OPC UA server, applies the pipeline definition, and routes to cloud or analytics sinks. A UNS, if in use, might be one of those sinks.

When each layer is the right tool:

OPC UA server: your downstream consumers speak OPC UA, you need read/write/subscribe from existing clients, and the data model is stable. Classic SCADA, MES, or historian integration.

MQTT broker: you have many lightweight sensors or edge devices already publishing MQTT, and your consumers can subscribe. Works best within a governed naming convention; degrades without it.

Industrial data broker: you need to connect heterogeneous sources to heterogeneous sinks without writing and maintaining integration code per pair. The pipeline is the asset; it should be inspectable and changeable by someone who is not a software engineer.

UNS discipline: you want a single source of truth for all operational data across a site or enterprise, and you are willing to govern the naming and schema conventions that make that coherent. Requires organizational buy-in beyond the tool itself.

None of these are mutually exclusive. The common pattern for a greenfield data modernization is OPC UA servers at the device layer, a broker handling the cloud routing, and a UNS architecture governing the naming if the organization is ready for that discipline.

---

The word "broker" will keep getting misused. When a vendor uses it, ask which layer they actually occupy: are they hosting an address space, routing messages, or running a transformation pipeline? The answer matters more than the label.

---

Talking to us

OPC Data Wrangler is an industrial data broker built by Thingamatronics. If you are working through an OPC UA to cloud or edge integration and want to discuss where the pipeline complexity actually lives, request information on the OPC Data Wrangler site or reply to this post directly.

We are honest about what is shipped versus on the roadmap, and we will tell you when a different tool is the better fit for your problem.