OPC UA Pub/Sub vs Client/Server: Choosing the Right Architecture for Dozens of PLCs
When an S7-300 fleet has to be migrated, the question is not limited to replacing controllers. It is also the right time to review how they communicate. Replacing controllers one by one on the same pattern used fifteen years ago can preserve an architecture that no longer fits the fleet's size or current uses.
OPC UA offers two fundamentally different ways to exchange data between PLCs, SCADA, MES and the cloud layer: Client/Server and Pub/Sub. Client/Server and Pub/Sub are two distinct communication models, not two versions of the same protocol or a cosmetic option to tick in TIA Portal. They don't behave the same way once the number of PLCs goes from five to fifty. This article lays out the decision grid, along with the standard developments that make this choice more pressing in 2026 than it was two years ago.
Client/Server and Pub/Sub: two models, not two menu options
Client/Server is the mode we've known since the early days of OPC UA. A client (a SCADA, a historian, an integration script) opens a session with a server (typically the PLC or a gateway) and explicitly requests data: a read, a write, a subscription to a value change. It's a point-to-point conversation, with per-connection session state and certificate-based security, and a model close to what a classic REST API does. It's robust and well understood by field teams. For that reason, it remains the default standard on almost every installation running today.
Pub/Sub flips the logic. A controller publishes its data on a channel without knowing who reads it or how many clients are listening. Subscribers receive the stream through a broker (MQTT, AMQP) or via direct broadcast (UDP multicast, Ethernet TSN). There's no session to maintain between each client-server pair anymore. The publisher speaks once, and everyone listening receives it. Our OPC UA glossary page notes that this mode has existed in the standard since version 1.04, built specifically to cover the real-time needs and cloud architectures that pure Client/Server doesn't handle well.
The difference shows up mostly at scale. In Client/Server, every new data consumer, an extra dashboard, a second historian, an MES feed, adds one more connection on each source PLC. In Pub/Sub, a new consumer subscribes to the existing stream without touching the publishing PLC. That's what changes the equation once you go beyond about ten controllers.
What actually changes: latency, network load, scalability
| Criterion | Client/Server | Pub/Sub |
|---|---|---|
| Connection model | Point-to-point session per consumer | One published stream, N subscribers |
| Load on the source PLC | Grows with the number of connected clients | Stays flat regardless of subscriber count |
| Typical latency | Good with few clients, degrades under load | Built for real time (UDP, TSN) |
| Adding a consumer | New connection to open and secure on the PLC | One more subscription, no impact on the publisher |
| Maturity and tooling | Very mature, standard since OPC UA's origin | Mature since version 1.04, ecosystem still maturing |
| Natural use case | Operator station, ad-hoc queries, small fleet | Distributed fleet, real-time ingestion, edge/cloud |
On a fleet of five to ten PLCs with a single SCADA polling each one, Client/Server causes no problems at all. It's the simplest mode to implement and the best documented. The entire tooling chain, TIA Portal, Studio 5000, most SCADA products on the market, has handled it natively for years without special tuning.
The math changes once you multiply sources and consumers. On a fleet of several dozen PLCs, each potentially read by a local SCADA, a central historian, an MES feed and an energy dashboard, the number of Client/Server connections explodes combinatorially. Each controller carries the load of all its active connections, which strains CPU and memory that are far more limited on a PLC than on a standard application server. Pub/Sub decouples this problem: the PLC publishes once, and the distribution load moves to the broker or network infrastructure, which is sized for it.
Compatibility with Siemens TIA Portal and Rockwell Studio 5000
On the ground, this question is never purely theoretical: it comes up the moment you open TIA Portal or Studio 5000 to configure communication. Siemens documents OPC UA PubSub as real-time one-to-many communication over UDP, explicitly positioned as complementary to Client/Server rather than a wholesale replacement. That positioning matters: Siemens isn't pushing customers to migrate their entire fleet to Pub/Sub, but recommends enabling it wherever real-time distribution to multiple consumers justifies it, while keeping Client/Server for classic request/response exchanges.
On the Rockwell side, the Studio 5000 and FactoryTalk ecosystem is still historically built around the native CIP protocol over EtherNet/IP for PLC-to-PLC and PLC-to-SCADA communication, with OPC UA carried in Client/Server mode through third-party servers or an integrated module depending on the controller family. Native OPC UA Pub/Sub support is less mature there than at Siemens, which in practice means that a predominantly Rockwell site considering Pub/Sub across a fleet of ControlLogix or CompactLogix controllers needs to verify the exact firmware version and available modules before basing a target architecture on it, rather than assuming it configures the same way as in TIA Portal. Our Siemens vs Rockwell vs Beckhoff comparison covers the ecosystem gaps between these three platforms in more detail, useful groundwork before this communication-architecture decision.
OPC UA FX: the standard is pushing Pub/Sub down to the field level
What makes this choice more consequential in 2026 than it was two years ago is the evolution of the standard itself. In November 2022, the OPC Foundation published the first OPC UA FX (Field eXchange) specification, standardizing Controller-to-Controller communication in Pub/Sub over TSN and 5G, with a multi-vendor demonstration held at SPS 2022 in Nuremberg. That first step covered communication between controllers, not yet the sensor and actuator level.
During 2026, the OPC Foundation's Field Level Communications working groups announced that the next step was in the works: a release candidate extending OPC UA FX to Controller-to-Device communication, reaching down to sensors, actuators and remote I/O, with a multi-vendor demonstration planned for SPS 2026 in Nuremberg in November 2026, illustrating communication from the field all the way to the edge and the cloud. In practice, Pub/Sub is moving down a level in the architecture. Pub/Sub is moving from a PLC-to-PLC communication mode toward the default mode envisioned all the way down to the sensor.
That signal matters for an architecture decision made in 2026. The installed base of OPC/OPC UA-compatible products is already very large and keeps growing every year. This is a gradual transition of a massive existing install base, not a theoretical greenfield project, and the direction the standard is heading weighs on what you choose to install today on a fleet meant to last ten to fifteen years.
The trigger: the actual lifecycle status of the S7-300 fleet
The second anchor point is the fleet's actual lifecycle status. For SIMATIC S7-300, check the exact reference against current Siemens documentation, then compare it with available parts, backups and in-house skills. A migration, often to S7-1500, can also prepare an OPC UA connection for MES integration or a data project.
This is exactly the moment when the Pub/Sub vs Client/Server question stops being abstract. A fleet migration project is the natural opportunity to redesign the communication architecture, not just swap hardware on a like-for-like basis. Copying the outgoing S7-300's communication pattern onto the incoming S7-1500 is the default choice, the one that requires the least upfront thinking. It isn't always the right one, especially if the fleet counts several dozen controllers and new data consumers (MES, energy platform, cloud historian) are already on the same project's roadmap.
Use cases: when the fleet tips toward Pub/Sub
The clearest case for Pub/Sub is a fleet spread across multiple sites or multiple zones of the same site, with several consumers that need the same data stream in parallel: a local SCADA for the operator, a central historian for traceability, an MES feed for manufacturing execution, and increasingly an energy monitoring layer that needs the same process signals to calculate consumption or detect drift. Adding that fourth consumer in Client/Server means opening a fourth connection on every PLC in the fleet. In Pub/Sub, it's one more subscription to the stream that's already being published, with no added sizing pressure on the controllers.
The same logic applies directly to energy and utilities sites: as soon as a substation or a plant needs to feed data to several consumers at once (local SCADA, historian, consumption monitoring), Pub/Sub's fan-out logic does exactly that job. We've seen it play out at an even larger scale on a program we ran for a major pharma player in the Basel region, where the target architecture relied on real-time ingestion via MQTT and OPC UA to unify data flows from more than twenty heterogeneous production, quality, maintenance and supply chain systems, feeding dashboards and analysis notebooks. At that volume, the choice weighed directly on operations: an architecture that multiplied point-to-point Client/Server connections would have become unmanageable to maintain and would have strained the availability of the source PLCs.
Conversely, a site with five to eight PLCs, a single local SCADA and no MES or data project on the horizon has no reason to move to Pub/Sub. The added complexity (managing an MQTT broker, securing subscriptions, monitoring one more component in the chain) isn't justified for a fleet that size. Client/Server stays simpler to operate and troubleshoot for a maintenance team that already knows it.
The pragmatic decision grid
Three questions settle it before launching a fleet migration project.
How many independent consumers read the same data today, and how many will in three years? A single SCADA, stay on Client/Server. Three or more consumers planned on the same stream (SCADA, historian, MES, energy monitoring), Pub/Sub avoids resizing PLC load with every new project.
Does the fleet exceed roughly twenty PLCs spread across multiple zones or sites? Below that, Pub/Sub's scalability gain stays theoretical against the operational complexity it adds. Above it, the combinatorial load of Client/Server becomes a real network sizing and controller load problem.
Does the migration project already include an MES, data or energy monitoring initiative in the same project timeline? If so, this is the moment to build the target architecture for those future needs rather than redo it in two years. Our article on the bottleneck between IT and OT explains why poorly anticipated interfaces like this become the number-one blocker in industrial data projects.
One important nuance: this choice isn't binary across an entire site. Nothing stops you from keeping Client/Server for command and one-off configuration exchanges while adding Pub/Sub only for high-fan-out process data streams. That's actually the position Siemens takes on TIA Portal: both modes coexist on the same controller, each handling the traffic it's suited for.
What we recommend before a PLC fleet migration
Don't treat the S7-300 replacement as a purely hardware project. It's an opportunity to check concretely where Pub/Sub delivers real scalability value, by cross-referencing the actual number of PLCs involved with an inventory of current and future consumers of your process data, rather than defaulting to a Client/Server architecture designed for a smaller fleet. In our article on MES, ISA-95 and ERP/PLC integration in pharma, we said a dedicated article would follow on this Pub/Sub vs Client/Server choice for level 3-2 interfaces: this is that article.
This is especially worth thinking through for energy and utilities sites, where distributed supervision across multiple substations or plants already combines real-time requirements with a growing number of data consumers. Our energy and utilities sector page describes the distributed supervision and OT cybersecurity work we do on this type of fleet. And for integration architecture in the broader sense, ERP, MES, SCADA and data platforms, our architecture services page details the approach we follow to settle these choices before they turn into inherited constraints.
If you're scoping a PLC fleet migration and the Pub/Sub vs Client/Server question doesn't yet have a clear answer in your project, better to settle it now, before the S7-1500's communication pattern ends up locked into the wiring documentation for the next ten years. Contact us for a technical review of your specific case.