OPC UA PubSub: MQTT vs UADP Architecture Comparison 2026

Most teams that adopt OPC UA PubSub make the key decision in the first ten minutes and regret it a year later: they pick a transport before they have written down what the data must do. Someone says “we already run an MQTT broker”, and an MQTT mapping is chosen. Or someone says “it has to be real time”, and UDP multicast is chosen. Both are defensible. Both are also incomplete, because the transport is only one of four independent choices in Part 14: the data model, the message encoding, the transport and the security model.

This guide separates those choices and then recombines them honestly. We walk through the Part 14 object model, compare UADP and JSON encodings with byte-level arithmetic, contrast broker-based MQTT with brokerless UDP and Ethernet transports, explain the Security Key Service, and place all of it next to OPC UA FX, Sparkplug and a unified namespace. We finish with a working open62541 configuration and the failure modes that tend to show up in commissioning.

What this covers: the Part 14 model, UADP vs JSON, MQTT vs UDP vs Ethernet and TSN, security and key distribution, FX and Sparkplug positioning, sizing math, code, failure modes and a decision matrix.

Context and Background

OPC UA began as a client/server protocol: a client opens a secure channel, creates a session, and reads, writes or subscribes to nodes on a server. That model is excellent for configuration, diagnostics and supervisory data access. It scales poorly in one direction, which is one producer feeding many consumers on a fixed schedule. Every additional consumer is another session, another set of monitored items and more load on the producing device.

Part 14 of the specification adds a second, decoupled interaction pattern. A publisher emits messages without knowing who receives them, and subscribers pick what they want. The OPC Foundation’s reference site lists the current release of OPC 10000-14 as 1.05.06, published 22 October 2025 (OPC 10000-14 reference), while the earlier 1.04 edition dates from February 2018. Several vendors still ship stacks written against 1.04, so check which edition a product claims before assuming a feature exists.

The field is crowded. Our comparison of DDS, MQTT and OPC UA covers how the protocol families differ at a high level, and the complete OPC UA protocol guide explains the client/server side that PubSub deliberately sidesteps. What this article adds is the internal fork inside PubSub itself, which receives far less attention than the PubSub versus client/server comparison.

A thesis worth stating up front: the MQTT versus UADP framing is slightly wrong. MQTT is a transport. UADP is an encoding. Part 14 defines mappings that pair them in different ways, including JSON over MQTT, UADP over MQTT, UADP over UDP and UADP over raw Ethernet. The real decision is whether you need a broker in the data path and whether you need deterministic timing. Those are two separate questions, and the answers are not always the same.

The Part 14 Reference Architecture

Short answer: OPC UA PubSub splits a publisher into DataSets (what is sent), a WriterGroup (when and how it is packaged) and a connection (where it goes). Messages are encoded as UADP binary or JSON and carried over UDP, Ethernet or an MQTT or AMQP broker. Subscribers mirror this with ReaderGroups and DataSetReaders.

Figure 1: The OPC UA PubSub object model on the publisher side and the two encoding and four transport choices below it.

The diagram shows one publisher application. The upper boxes are data modelling and are transport-neutral. The lower boxes are the mappings. Everything above the encoding line can be configured once and carried over different transports, which is the main architectural benefit of the design.

The object model: DataSets, writers and groups

A PublishedDataSet is a named, ordered list of fields. Each field is sourced from a variable in the publisher’s address space, with a data type and an optional alias. Think of it as a typed record: for example, temperature, pressure and valve position taken from three nodes. Because the field list is ordered and typed, a subscriber that knows the metadata can decode a message without any per-field names on the wire. That is the property that makes compact UADP possible.

A DataSetWriter produces DataSetMessages from one PublishedDataSet. It has a numeric DataSetWriterId, a field content mask that controls what each field carries (value only, value with status, value with source timestamp) and a key frame count. A key frame carries all fields. Between key frames the writer can emit delta frames containing only fields that changed. A key frame count of 10, as used in the open62541 tutorial, means one full frame in every ten messages.

A WriterGroup owns one or more DataSetWriters and defines how their messages are packaged into NetworkMessages. It carries the publishing interval, a WriterGroupId, the message settings (which header fields to include), the encoding and the security settings. It is the unit that shares timing and security, so two datasets that need different publishing rates or different keys belong in different WriterGroups.

A PubSubConnection binds groups to a concrete transport: a PublisherId, a transport profile URI and an address such as opc.udp://239.0.0.1:4840 or mqtts://broker.plant.example:8883. On the subscriber side, a ReaderGroup contains DataSetReaders, each filtering by PublisherId, WriterGroupId and DataSetWriterId and mapping decoded fields into target variables.

DataSetMetaData: the contract that makes the wire compact

A subscriber cannot decode a UADP payload without knowing field types and order. That description travels as DataSetMetaData, and Part 14 defines a configuration version (major and minor) so that a reader can detect when a publisher changed its dataset layout. For a UDP subscriber, metadata is normally supplied through configuration, an information-model export or discovery messages. For MQTT, the mapping defines a dedicated metadata topic level, and those messages are published with the MQTT RETAIN flag set, so a late-joining subscriber receives the schema immediately. The same specification clause marks the data level as not retained.

This asymmetry has a practical consequence. Retained metadata plus non-retained data is a deliberate design: the schema is state, the samples are events. If you later bridge into a unified namespace, keep that distinction, as discussed in our unified namespace architecture article.

Encoding: where UADP and JSON actually differ

UADP is the binary mapping. A NetworkMessage starts with a version and flags byte, followed by optional header fields selected by a content mask: PublisherId, a group header (WriterGroupId, sequence number, group version), a payload header listing the DataSetWriterIds present, timestamps, and security headers. The mask is why two UADP implementations can produce quite different byte layouts and both be conformant. Your subscriber has to be configured with the same mask the publisher uses, or auto-detect it from the flags.

JSON wraps the same logical structure in a JSON object. Field names appear in every message, values are text, and the structure is readable by any MQTT tool. Part 14 offers compact and verbose variants controlling how much header context is repeated. A rough illustration: one float field in UADP costs 4 bytes (plus a small field header if status or timestamp is included). The same field in JSON is a quoted name, a colon and a decimal string, easily 25 to 40 bytes. Section three works through a full example.

Figure 2: One WriterGroup publish cycle on the two main paths. The UDP path has no intermediary. The MQTT path adds a broker hop and a retained metadata message.

The sequence view makes the important difference visible. On the UDP path the publisher sends and is done: no acknowledgement, no connection, no state held by anyone else. On the MQTT path the publisher maintains a TCP connection to a broker and the broker holds retained state. Each is a legitimate architecture, with a different operational burden.

Transports Compared: MQTT, UDP Multicast and Ethernet

Part 14 defines transport mappings for UDP (unicast, multicast and broadcast), raw Ethernet with Ethertype framing, MQTT and AMQP. The first two carry UADP only. MQTT carries either UADP or JSON. This section walks through each and then does the arithmetic that usually decides the argument.

UDP multicast: brokerless fan-out

With opc.udp:// addressing, the publisher sends one datagram to a multicast group and the network replicates it. The open62541 tutorial uses opc.udp://224.0.0.22:4840/ as its default address. A hundred subscribers cost the publisher exactly what one subscriber costs, which is the strongest argument for this transport.

The costs are operational. Multicast needs IGMP snooping configured on switches, or every port floods. Routing multicast between VLANs requires PIM or equivalent. Many corporate and cloud networks drop multicast entirely. There is no delivery guarantee, so a lost datagram is simply gone, and subscribers detect gaps through the NetworkMessage sequence number. If you need the missing value, you need key frames to carry full state periodically.

Raw Ethernet: layer 2 and TSN

With opc.eth:// addressing, UADP NetworkMessages are placed directly in Ethernet frames, with no IP or UDP header. The publisher addresses a MAC (often multicast) and optionally a VLAN. This removes 28 bytes of IP and UDP overhead per frame and, more importantly, removes the IP stack from the time-critical path. As I recall, the Ethertype assigned to OPC UA PubSub is 0xB62C, but treat that as unverified until you check the spec text.

Raw Ethernet is the transport that pairs with IEEE 802.1 Time-Sensitive Networking. TSN gives scheduled transmission windows (802.1Qbv), frame preemption, time synchronisation (802.1AS) and stream reservation. The transport itself is not deterministic; TSN is. UADP over Ethernet simply gives TSN a frame format it can schedule. For the networking side, see our TSN architecture guide and the OPC UA over TSN reference architecture. The limitation is scope: layer 2 does not cross routers, so this is a cell or line level transport.

MQTT: a broker in the data path

The MQTT mapping publishes NetworkMessages to topics on a broker. Per the specification, versions 3.1.1 and 5.0 are both supported, with a MqttVersion setting of “3.1.1”, “5.0” or “BestAvailable”. Addresses use mqtt:// (default port 1883, no transport security), mqtts:// (TLS, port 8883) or wss:// (MQTT over secure WebSockets, port 443).

The version matters more than it appears. MQTT 3.1.1 has no mechanism to tell a subscriber which encoding a message uses, so subscribers must be pre-configured and publishers should use one encoding per topic. MQTT 5.0 adds encoding and message type information to message headers, so subscribers can detect them. If you are starting new, require 5.0. Our MQTT 5 features deep dive covers shared subscriptions and topic aliases, both useful for scaling subscriber groups.

Quality of service maps directly: AtMostOnce and BestEffort map to QoS 0, AtLeastOnce to QoS 1, ExactlyOnce to QoS 2. Data messages are typically QoS 0 or 1. Exactly-once semantics add a four-step handshake and are rarely worth it for periodic telemetry.

The topic convention

Part 14 prescribes a topic structure rather than leaving it to each vendor:

<Prefix>/<Encoding>/<MqttMessageType>/<PublisherId>/[<WriterGroup>[/<DataSetWriter>]]

The prefix defaults to opcua, the encoding level is json or uadp, and the message type level is one of data, metadata, application, endpoints, status, connection, action-request or action-response (the specification lists a few more for action metadata). A concrete example, with illustrative names: opcua/json/data/PLC-07/Line1/TempPressure. Subscribers may use MQTT wildcards, so opcua/json/data/+/Line1/# collects everything from one writer group name across publishers.

Two rules bite in practice. Topic levels may not contain /, +, #, a leading $, or whitespace other than space. And the specification warns that splitting the prefix into several levels prevents automatic publisher discovery unless subscribers are pre-configured with that prefix. Note also that this convention is not the ISA-95 style hierarchy most unified namespace deployments use, which we return to below.

Worked sizing and latency arithmetic

Numbers below are illustrative arithmetic, not benchmarks. Take a dataset of 20 float32 process values at a 10 ms publish interval (100 messages per second).

UADP over raw Ethernet. Assume a compact header of around 24 bytes (flags, PublisherId, group header, payload header, sequence number), a DataSetMessage header of around 6 bytes, and 20 fields x 4 bytes = 80 bytes of values. Payload is about 110 bytes. Add 14 bytes Ethernet header, 4 bytes FCS, 8 bytes preamble and 12 bytes inter-frame gap: roughly 148 bytes on the wire, which is 1,184 bits. At 100 messages per second that is 118 kbit/s, about 0.012% of a 1 Gbit/s link. On UDP/IP, add 28 bytes: 176 bytes, 141 kbit/s.

JSON over MQTT. Assume each field serialises as a name of about 12 characters, quotes, colon and a value such as 23.4567 with delimiters, near 30 bytes per field. Twenty fields is 600 bytes, plus an envelope of perhaps 150 bytes for message id, publisher id, writer group, timestamps and metadata version. Call it 750 bytes. Add MQTT fixed header and topic (about 45 bytes), TCP/IP headers (40 bytes at minimum) and Ethernet framing (38 bytes): about 870 bytes per message, 696 kbit/s at 100 messages per second. That is roughly five times the UADP bandwidth. If the broker fans out to ten subscribers, the broker egress is ten times that.

Bandwidth is rarely the real constraint on a modern network. The cost shows up in CPU: parsing 100 JSON messages per second on a constrained gateway is fine, but a PLC-class device doing the same at 1 kHz is not. Serialisation cost, not wire cost, is why controllers publish UADP.

Latency. On a TSN-scheduled Ethernet path, one-way delay is determined by the schedule and can be bounded in the tens to hundreds of microseconds per hop. On unscheduled UDP multicast over a lightly loaded switched LAN, typical delay is sub-millisecond but has no bound: a burst of competing traffic can queue your frame. Through a broker, add TCP handling, broker queueing and a second network traversal, typically single-digit milliseconds on a local broker and tens to hundreds across a WAN. These are order-of-magnitude statements from general networking behaviour; measure your own path with hardware timestamps before committing a control loop to it.

Figure 3: A common layered deployment. Time-critical UADP traffic stays on the cell network; a gateway republishes selected datasets to a broker for plant and cloud consumers.

The most robust pattern is the layered one in Figure 3. Do not choose one transport for the whole enterprise. Use UADP on the segment where timing matters, and an MQTT mapping at the boundary where you need routable, firewall-friendly, many-to-many distribution.

Security: Message-Level or Hop-Level

Security in PubSub works differently from the secure channel in client/server. There is no session between publisher and subscriber, so there is no handshake in which to negotiate keys. Part 14 solves this at two layers, and the MQTT and UADP choices expose different ones.

Transport-level security

For MQTT, the main protection is TLS between each client and the broker. The specification is explicit about the consequence: this requires trusting the broker, because the broker can read and modify what passes through. Username and password can be sent in the CONNECT packet (the spec says to use a secured connection when doing so), and MQTT 5.0 adds enhanced authentication using AUTH packets, including re-authentication. If no authentication profile is configured, SASL Anonymous is implied.

Message-level security with UADP

End-to-end protection requires UADP NetworkMessages. The publisher signs, or signs and encrypts, each NetworkMessage using symmetric keys, so a broker or any switch in between cannot alter it undetected. The specification states that JSON message bodies rely on MQTT and broker mechanisms rather than their own message-level protection. For this reason, if you need confidentiality across an untrusted broker, such as a cloud-hosted one, UADP over MQTT with security enabled is the mapping that delivers it, at the cost of losing human-readable payloads.

The Security Key Service

Symmetric keys need distribution. Part 14 introduces the Security Key Service (SKS), a server that holds keys for named SecurityGroups and hands them out through a GetSecurityKeys method call over an ordinary authenticated OPC UA client/server session. Publishers and subscribers each call the SKS, receive the current key, a number of future keys and the key lifetime, and then rotate locally without further calls until the future keys run low. Authorisation is per SecurityGroup, so a subscriber only receives keys for groups it is permitted to read.

Figure 4: Key distribution through an SKS. Keys flow over client/server sessions; data flows over PubSub without any session.

Design implications follow. The SKS is a control-plane dependency: if it is unreachable when keys expire, new subscribers cannot decode and rotating publishers stall. Fetch future keys with a margin of several key lifetimes, sized to your longest tolerable SKS outage. Clock skew matters, because key selection depends on time. And the SKS becomes a high-value target, so treat it like a certificate authority: segmented, monitored and backed up. Our zero-trust article for OT discusses where such components belong.

Where PubSub Sits: OPC UA FX, Sparkplug and the Unified Namespace

PubSub is a building block, not a complete interoperability story. Three neighbours determine how much work remains after you have messages flowing.

OPC UA FX

OPC UA FX (Field eXchange) layers semantics and engineering on top of the PubSub and client/server mechanisms. The OPC Foundation’s Field Level Communications initiative published the first set of UAFX specifications after what it describes as four years of work. The initial parts it lists are Part 80 (overview and basic concepts), Part 81 (base information model and communication concepts for factory and process automation), Part 82 (networking services such as topology discovery and time synchronisation) and Part 84 (the Controller Profile with conformance requirements). The OPC Foundation describes these as using Client/Server and PubSub extensions with peer-to-peer connections and basic diagnostics (OPC Foundation announcement).

The practical reading: plain PubSub tells a device how to emit a dataset. FX adds a standard way for two controllers to discover each other, establish a connection with defined roles and exchange cyclic data with diagnostics. If your goal is controller-to-controller exchange across vendors, you want FX conformance, not hand-rolled PubSub. If your goal is telemetry to a historian or cloud, plain PubSub is sufficient. I have not verified which vendors currently hold certified FX products; check the OPC Foundation’s certification listings. Our OPC UA FX analysis tracks the details.

Sparkplug B

Sparkplug defines a rigid MQTT topic namespace, a Protobuf payload, birth and death certificates and a state model on top of MQTT. OPC UA PubSub over MQTT defines a topic convention, two encodings and a metadata mechanism. They overlap in goal and differ in philosophy.

Aspect	OPC UA PubSub over MQTT	Sparkplug B
Payload	JSON or UADP, typed via DataSetMetaData	Protobuf, typed metrics
Schema discovery	Retained metadata topic	Birth certificates
Liveness	Status messages, MQTT keep alive	Death certificates and Last Will
Information model	Full OPC UA address space and companion specs	Flat metric list with templates
Message security	UADP signing and encryption via SKS	TLS and broker ACLs only
Transport scope	MQTT, AMQP, UDP, Ethernet	MQTT only

Neither is strictly superior. Sparkplug’s strength is a narrow, widely implemented contract between edge nodes and SCADA hosts. PubSub’s strength is semantic richness and the ability to leave the broker world for controller traffic. Our dedicated Sparkplug B versus OPC UA PubSub comparison goes further.

Unified Namespace

A unified namespace (UNS) is an architectural practice: one broker hierarchy, usually organised by enterprise, site, area, line and cell, where every system publishes current state. The Part 14 topic structure, which is publisher-centric (opcua/json/data/<PublisherId>/...), does not map onto an ISA-95 hierarchy without help. You have two choices. Specification text allows a system-specific topic to be used instead of the default for data, metadata and action-request messages, so you can configure writers to publish on UNS-shaped topics. Or you can keep PubSub topics as an ingest layer and run a normalising bridge that republishes into the UNS. The second approach decouples the plant’s internal addressing from the enterprise model and is what I would default to, at the cost of an extra component to operate.

Working Configuration with open62541

The following sketch uses the open62541 C API as shown in its 1.5 PubSub tutorial. It builds a UDP UADP connection, a dataset with one field, a writer group and a dataset writer. Treat it as a starting point; build flags (UA_ENABLE_PUBSUB) and API names change between releases, so check the documentation for your version.

UA_PubSubConnectionConfig connectionConfig;
memset(&connectionConfig, 0, sizeof(connectionConfig));
connectionConfig.name = UA_STRING("UADP Connection 1");
connectionConfig.transportProfileUri = UA_STRING(
    "http://opcfoundation.org/UA-Profile/Transport/pubsub-udp-uadp");
UA_NetworkAddressUrlDataType url = {UA_STRING_NULL,
    UA_STRING("opc.udp://239.0.0.1:4840/")};
UA_Variant_setScalar(&connectionConfig.address, &url,
    &UA_TYPES[UA_TYPES_NETWORKADDRESSURLDATATYPE]);
connectionConfig.publisherId.idType = UA_PUBLISHERIDTYPE_UINT16;
connectionConfig.publisherId.id.uint16 = 2234;
UA_NodeId connectionIdent;
UA_Server_addPubSubConnection(server, &connectionConfig, &connectionIdent);

UA_PublishedDataSetConfig pdsConfig;
memset(&pdsConfig, 0, sizeof(pdsConfig));
pdsConfig.publishedDataSetType = UA_PUBSUB_DATASET_PUBLISHEDITEMS;
pdsConfig.name = UA_STRING("Line1 Process");
UA_NodeId pdsIdent;
UA_Server_addPublishedDataSet(server, &pdsConfig, &pdsIdent);

UA_DataSetFieldConfig dsf;
memset(&dsf, 0, sizeof(dsf));
dsf.dataSetFieldType = UA_PUBSUB_DATASETFIELD_VARIABLE;
dsf.field.variable.fieldNameAlias = UA_STRING("Server localtime");
dsf.field.variable.publishParameters.publishedVariable =
    UA_NS0ID(SERVER_SERVERSTATUS_CURRENTTIME);
dsf.field.variable.publishParameters.attributeId = UA_ATTRIBUTEID_VALUE;
UA_NodeId dsfIdent;
UA_Server_addDataSetField(server, pdsIdent, &dsf, &dsfIdent);

UA_WriterGroupConfig wgConfig;
memset(&wgConfig, 0, sizeof(wgConfig));
wgConfig.name = UA_STRING("Line1 WriterGroup");
wgConfig.publishingInterval = 100;   /* ms */
wgConfig.writerGroupId = 100;
wgConfig.encodingMimeType = UA_PUBSUB_ENCODING_UADP;
UA_NodeId wgIdent;
UA_Server_addWriterGroup(server, connectionIdent, &wgConfig, &wgIdent);

UA_DataSetWriterConfig dswConfig;
memset(&dswConfig, 0, sizeof(dswConfig));
dswConfig.name = UA_STRING("Line1 Writer");
dswConfig.dataSetWriterId = 62541;
dswConfig.keyFrameCount = 10;
UA_NodeId dswIdent;
UA_Server_addDataSetWriter(server, wgIdent, pdsIdent, &dswConfig, &dswIdent);

UA_Server_enableAllPubSubComponents(server);

Read it top to bottom as the object model from Figure 1: connection (transport and PublisherId), PublishedDataSet, field, WriterGroup (interval and encoding), DataSetWriter (id and key frame count). The tutorial also sets a network message content mask on the writer group message settings, selecting PublisherId, group header, WriterGroupId and payload header; omit it and the stack falls back to defaults, which may not match your subscriber.

Moving this to MQTT is mostly a connection change. Use an MQTT transport profile, an mqtt:// or mqtts:// address, and set the encoding mime type to JSON if you want readable payloads. Which MQTT profile URIs your stack supports, and whether the MQTT transport is compiled in by default, varies by version; I did not verify the exact open62541 flags for MQTT in 1.5, so check its PubSub documentation. Our OPC UA PubSub over MQTT 5 tutorial walks through that setup in detail.

A subscriber-side checklist saves hours: confirm the PublisherId, WriterGroupId and DataSetWriterId match the reader filter; confirm the content mask agrees; confirm the metadata version; and capture with Wireshark, which dissects UADP, before blaming the stack.

Trade-offs, Gotchas, and What Goes Wrong

Multicast silently dies at the first router. A lab with one flat switch works perfectly; production with a VLAN boundary delivers nothing. Check IGMP snooping, querier presence and TTL. The symptom is a subscriber that sees no data and no error.

MQTT 3.1.1 with mixed encodings. Because the protocol cannot announce the encoding, a subscriber that receives UADP on a topic it expected to be JSON will fail to parse. Keep one encoding per topic, and prefer 5.0.

Retained metadata goes stale. Metadata is retained so late joiners get the schema. If a publisher changes its dataset layout and a retained message from the old version persists, subscribers decode with the wrong layout. Watch the configuration version, and clear or overwrite retained topics during upgrades.

Broker as single point of failure. One broker is a plant-wide dependency. Deploy clustered brokers or a local broker per site with bridging, and decide whether publishers buffer on disconnect. QoS 0 messages sent while the TCP connection is down are lost.

Key frame starvation. A subscriber that restarts between key frames has no full state until the next one. With a key frame count of 10 at a 100 ms interval, a restart can mean waiting up to one second. Tune it for your recovery requirement, or fetch state through client/server on startup.

Timestamps that disagree. UADP carries timestamps assigned by the publisher. Without disciplined clocks (PTP or 802.1AS), cross-device ordering is unreliable and key selection for secure groups can fail. Time sync is part of the design, not an add-on.

JSON at high rates. The serialisation CPU cost on embedded publishers is the usual surprise. Profile before committing.

Expecting determinism from the wrong layer. UADP over UDP on a shared network is not deterministic. Determinism comes from TSN scheduling and controlled traffic classes, not from the encoding.

Decision Matrix

Requirement	UADP over Ethernet and TSN	UADP over UDP multicast	JSON over MQTT	UADP over MQTT
Bounded latency, controller loops	Best	Possible, unbounded	No	No
Crossing routers and firewalls	No	Limited	Yes	Yes
Many-to-many cloud distribution	No	Limited	Best	Good
Bandwidth and CPU efficiency	Best	Best	Weakest	Good
Message-level security through a broker	Yes	Yes	No, relies on broker	Yes
Human readability and tooling	Low	Low	Highest	Low
Operational dependency	TSN network	Multicast network	Broker	Broker and SKS

Practical Recommendations

Start from requirements rather than transport. If a consumer must act within a control cycle, you need UADP on a TSN-capable layer 2 network, and you should look at FX for controller-to-controller exchange. If consumers are dashboards, historians, analytics and cloud services, use MQTT 5.0 with TLS and keep JSON unless bandwidth or CPU says otherwise. If the broker is not fully trusted, use UADP over MQTT with signing and encryption via an SKS.

Run both in a layered design. Keep time-critical traffic on the cell network, and let a gateway republish selected datasets to a broker. Decide the namespace question early: either configure system-specific topics to match your UNS or normalise through a bridge.

Checklist before commissioning:

Confirm the Part 14 edition and transport profiles each vendor supports.
Fix the encoding per topic and require MQTT 5.0 where possible.
Define PublisherId, WriterGroupId and DataSetWriterId allocation rules.
Plan metadata versioning and retained message cleanup.
Set key frame counts against restart recovery time.
Establish time synchronisation across all publishers.
Size the SKS key lifetime and future key count against outage tolerance.
Verify multicast: IGMP snooping, querier, routing.
Capture and decode traffic with Wireshark during acceptance.
Measure latency with hardware timestamps instead of assuming it.

Frequently Asked Questions

What is the difference between OPC UA PubSub and client/server?

Client/server is a session-based request and response model in which each client talks to a server. PubSub is decoupled: publishers send DataSetMessages without knowing the recipients, and subscribers receive what they filter for. PubSub scales better for one-to-many cyclic data, supports brokerless and broker-based transports, and uses sessionless message security with keys from an SKS. Client/server remains better for browsing, configuration, method calls and diagnostics.

Is UADP faster than MQTT?

UADP is an encoding and MQTT is a transport, so the comparison is mixed. UADP is smaller and cheaper to serialise than JSON, and UADP over Ethernet with TSN can give bounded latency. MQTT adds a TCP connection and a broker hop, so latency is higher and less predictable. You can still carry UADP over MQTT to save bandwidth while keeping the broker’s routing and reach.

Can OPC UA PubSub run in the cloud?

Yes, typically through the MQTT mapping to a broker the cloud platform exposes, using TLS on port 8883 or secure WebSockets on port 443. Multicast UDP generally does not work across cloud networks. If the broker is operated by a third party, use UADP with signing and encryption so the payload is protected end to end, rather than relying on the broker.

Does OPC UA PubSub require TSN?

No. PubSub works over ordinary UDP, MQTT and AMQP with no TSN. TSN is needed only when you require bounded, deterministic latency, typically for controller-level exchange, and it pairs with the raw Ethernet transport. Many telemetry deployments never need it. Treat TSN as a network capability you choose when timing demands it.

How does OPC UA PubSub security work?

Message-level security uses UADP NetworkMessages signed, or signed and encrypted, with symmetric keys. The keys belong to SecurityGroups and are distributed by a Security Key Service via a GetSecurityKeys method over an authenticated client/server session. For MQTT, TLS to the broker protects each hop, but JSON payloads depend on broker security and are readable by the broker.

How does PubSub relate to OPC UA FX?

FX builds on PubSub and client/server to standardise controller-to-controller and field-level communication, adding discovery, connection establishment, roles and diagnostics. The first specification parts released are Parts 80, 81, 82 and 84. Use PubSub directly for telemetry; use FX when you need interoperable, vendor-neutral cyclic exchange between controllers or between controllers and field devices.

OPC UA Pub/Sub: MQTT vs UADP Architecture Comparison