OPC UA (Unified Architecture) supports two distinct communication models: client-server and Publish-Subscribe (PubSub). In client-server, a client establishes a session with a server and requests data directly — communication is point-to-point and bidirectional. In PubSub, publishers broadcast data to a message-oriented middleware without any knowledge of who is receiving it, and subscribers consume only the data they have expressed interest in. The right model depends on your topology, latency requirements, and how many endpoints need to exchange data simultaneously.
How OPC UA Client-Server Works
Client-server is the original communication model in OPC UA, defined in Part 4 of the OPC UA specification. A client opens a secure session with a server, then uses standardised services to browse the server’s address space, read and write values, and set up monitored subscriptions for value changes.
Key characteristics:
- Point-to-point sessions — each client maintains its own connection to the server.
- Request-response pattern — the client initiates every interaction; the server responds.
- Guaranteed delivery — the server tracks each subscription and confirms delivery to the specific client.
- Bidirectional — clients can read, write, and call methods on the server.
- Session state — the server maintains context per client, including security credentials and subscriptions.
This model is well-suited to supervisory applications where a SCADA system, HMI, or historian needs reliable, on-demand access to a known set of devices. Because the server knows exactly which clients are connected, it can enforce fine-grained security policies and ensure every data change reaches its intended recipient.
For more on how OPC clients and servers relate to each other, see What is the difference between an OPC client and server?
How OPC UA PubSub Works
OPC UA PubSub was formalised in Part 14 of the OPC UA specification (version 1.04, 2018). Rather than establishing sessions, publishers send data messages to a message-oriented middleware — such as an MQTT broker or a UDP multicast group — without any knowledge of who, if anyone, is listening. Subscribers register interest in specific data and receive matching messages from the middleware.
Key characteristics:
- Decoupled architecture — publishers and subscribers have no direct awareness of each other.
- One-to-many — a single publisher can reach unlimited subscribers simultaneously.
- Connectionless — no persistent session is required between endpoints.
- Transport flexibility — supports MQTT, AMQP, and UDP/UADP (UA Datagram Protocol).
- No guaranteed delivery (by default) — delivery assurance depends on the underlying transport; MQTT QoS levels can add reliability, but the PubSub model itself is inherently fire-and-forget.
PubSub is optimised for high-volume, time-critical scenarios — such as synchronising motion controllers on a production line or streaming sensor data to cloud analytics — where the overhead of maintaining individual client sessions would be prohibitive.
Side-by-Side Comparison
| Feature | Client-Server | PubSub |
|---|---|---|
| Communication pattern | Request-response | Publish-broadcast |
| Topology | One-to-one (per session) | One-to-many |
| Session required | Yes | No |
| Guaranteed delivery | Yes (per client) | Depends on transport |
| Bidirectional | Yes | Publisher → subscriber only |
| Typical transport | TCP/IP (OPC Binary, HTTPS) | MQTT, AMQP, UDP/UADP |
| Best for | SCADA, HMI, historians | IIoT, cloud, high-speed control |
| Latency profile | Higher (session overhead) | Lower (stateless broadcast) |
Which Model Should You Use?
The two models are complementary, not competing. Most production deployments use both.
Use client-server when:
- You need bidirectional communication (reading and writing values).
- Guaranteed, per-client delivery is a hard requirement.
- You are building a supervisory layer — SCADA, MES, or data historian.
- Security policies must be enforced at the session and user level.
Use PubSub when:
- Data must be delivered to many consumers simultaneously without scaling connection overhead.
- You are integrating with IIoT platforms, cloud services, or MQTT brokers.
- Low-latency, high-frequency data broadcasting is required.
- The producer should not need to know or manage its consumers.
It is also worth noting that a single OPC UA application can act as both a server (for client-server connections) and a publisher (for PubSub) simultaneously — the two modes share the same underlying information model.
OPC UA Subscriptions vs PubSub: A Common Point of Confusion
OPC UA client-server already includes a subscription mechanism: a client asks the server to monitor specific nodes and push change notifications. This can look similar to PubSub, but the two are architecturally distinct.
In a client-server subscription, the server tracks the subscriber’s session and delivers changes directly to that specific client. In PubSub, the publisher broadcasts to middleware with no knowledge of any subscriber. The client-server subscription model offers stronger delivery guarantees; PubSub offers greater scalability and transport flexibility.
For a deeper look at how polling and subscription work within the client-server model, see Polling versus Subscription on opcexpert.com.
Practical Context
OPC Expert supports both communication models, enabling engineers to connect OPC UA clients and servers while also working with MQTT-based PubSub architectures in the same environment. The OPC Foundation publishes the full specifications for both models, and the OPC Training Institute (OPCTI) offers structured training for engineers implementing either approach.