Five Doors Into One Siemens Controller: What Each One Costs You

Walk any trade fair and you hear the same answer. Standardise on OPC UA and talking to machines becomes a solved problem.

Most of that is true. OPC UA really is a standard, really is vendor-neutral, and really does carry an information model the older protocols do not have. For many plants it is the right choice.

What the pitch leaves out is the bill, and it arrives in one of two ways.

The first is a rollout. A brownfield line that has run for fifteen years is told to standardise. Nobody re-specifies the controllers, because the controllers work fine. Then the network carries several times the traffic it used to, and the CPUs spend part of every cycle on communication they were never sized for.

The second is slower, and much harder to see coming. An Industry 4.0 project starts small and works well. So it grows. Somebody adds a dashboard. A quality system wants the same values, faster. Maintenance wants trends. Someone wants all of it archived. Every request is reasonable on its own, and every one gets granted, because the last one was fine.

Nobody ever decides to overload a controller, or a network. You arrive there one good idea at a time, until the PLC can no longer serve the information and run the machine at the same time.

Both roads end in the same place. The line stops running properly. Not dramatically. It just gets less reliable, in ways that take a long time to trace back to a connectivity decision.

So this article asks a narrow question. Not "which protocol is best", but what does it cost to read data out of a controller you already own — and how much of that cost is the protocol, how much is the controller, and how much is your own client.

Other vendors get the same treatment in their own articles, starting with Beckhoff’s TwinCAT controllers. A third article crosses vendor lines on purpose. It runs the same jobs on the controllers of seven vendors.

Five Siemens controllers. Six ways in. One number that changes: how many values I ask for at once.

The curve below and the connect times in the security section come from September, from an earlier build of the driver. The six-way table, the controller load, OPC UA over separate variables and the subscriptions were measured in October, from the driver exactly as it ships.

Start here, because everything else follows from it.

Over classic S7Comm I read one contiguous block of memory and varied only how many bytes it held:

Flat. Two hundred times the data for the same time.

The tables further down say the same thing from the other direction. On one controller, reading a hundred values takes 1.9 ms in one request and 318 ms in a hundred requests — for ten times fewer bytes in the slow case.

A request to a PLC is almost all fixed cost. The controller has to notice the request, schedule it around the program it is running, build an answer and send it. The data itself is nearly free.

So the way to make a client faster is not to ask for less. It is to ask fewer times.

Which raises the obvious question: how much fewer, and when does it stop helping?

I ran the same values at nine sizes, with the client merging requests and without, on four controllers. Every figure below is one batched read against one batched read — the same hundred or thousand values, asked for once each way.

Merging works by reading a span of memory in one go. If your values are neighbors, that span is nearly all data you asked for.

If they are scattered across a data block with big gaps between them, the client is reading bytes nobody wants in order to save round trips. At some point that trade stops paying, and if they are far enough apart it buys nothing at all.

Every number above reads one contiguous array, which is the best case for merging. On your plant it will depend on your layout.

For OPC UA the same array is the worst case. Its server treats every element as a separate node read through an index range, and on the G2 it answered separate variables about eight times as fast as array elements. So every OPC UA row in this article up to the next section is a lower bound. The section after the six-way table measures OPC UA the way most projects are written.

Modbus on a SIMATIC is unusually well placed here. You cannot speak Modbus to an S7 at all without building a data block for it and mapping your values into register ranges by hand, so they end up beside each other because the protocol made you put them there. The layout that makes merging work is the layout you were forced into anyway.

Now the protocols against each other. One controller, one read carrying 80 values, every protocol in the same run, with the driver as it ships:

Look at the two Modbus rows before anything else. Same controller, same 80 values, same protocol. One of them asks once and takes 3.7 ms. The other asks 80 times and takes 258. That is the whole argument of this article in two rows.

One figure to explain before the rest: the web interface’s request count is approximate. Its traffic is TLS records rather than a protocol the capture can read, so those are what was counted.

🔒 marks the ways in that were measured with the channel encrypted and the client authenticated: S7CommPlus, the web interface over HTTPS and OPC UA when secured. Everything else ran in the clear.

*S7CommPlus comes in several versions. The older ones can run without any protection. Only the newest is fully secured, with the client authenticated and the channel encrypted. Our driver implements only that version, so every S7CommPlus figure in this article was measured with full security.

Five things in that table.

S7Comm is the cheapest thing a SIMATIC can do, and it ships with the controller. It is also unauthenticated, unencrypted and blind to variable names: it reads bytes at an address, so your client has to know the memory layout from somewhere else. Move a variable in your program and something breaks quietly, with no compiler to catch it.

Plain S7CommPlus costs about five times the merged S7Comm read and buys two real things. Variable names instead of addresses, and a secured session. It is free and already on the controller. Merged, it comes close to merged S7Comm, for reasons the last point in this list explains, and under heavy load it can pull ahead, as the next section shows.

Read as array elements, OPC UA costs fifty times the merged S7Comm read and nine times plain S7CommPlus. Array elements are its worst case. Read as separate variables it takes 26 ms, seven times the merged S7Comm read and a little behind plain S7CommPlus; a later section compares the two shapes on all three CPUs. Note the requests column while you are there: OPC UA reads all 80 values in a single request. Its cost is not round trips. It is what the server does with them.

Connecting is a separate cost, paid once per connection, and there the protocols differ even more. The security section below has those figures.

The bytes column does not predict the time column. OPC UA over array elements moves 3,810 bytes in one request and takes 179 ms. Plain Modbus moves half that and takes 258 ms across 80 requests. The web interface moves three times as much as OPC UA and is faster. Whatever you are paying for, it is not data volume.

And the same weakness that makes S7Comm blind is what makes it tunable. Because an S7Comm address is a position rather than a name, a client can see that your values are neighbors and fetch them in one span. A protocol that uses names cannot do that from the request alone: arrInt[7] and arrInt[8] are two opaque names, and nothing in the request says they sit next to each other.

S7CommPlus can do better than that too, in data blocks with standard (non-optimized) access. There our client merges S7CommPlus reads as well, and the S7CommPlus, merged row measures the result. The feature is a direct result of this benchmark work: it grew out of surprises we ran into while building a hybrid S7Comm/S7CommPlus driver. In a block with optimized access it does not apply, and S7CommPlus reads one item per value. The cheapest door is still the one with the most headroom left in the client.

The four controllers are not equally fast, and the reason is not what people assume.

One takes six times longer per request than another of the same family. The old S7-1212C needs about 12.6 ms for a request the G2 answers in 2.0 ms. Both are S7-1200s.

And it negotiates a 240-byte request where the others manage 960. A smaller request holds fewer values, so the same read needs more of them.

Those two facts explain every slow row on that controller. Its idle cycle does not: it is twice the G2’s, but a read takes four to twenty times as long. Its age does not come into it, except that both facts are things the newer generation improved.

It is worth being careful in the other direction too. The S7-1511 on this bench is three to six times slower per request than the S7-1516 over unmerged S7Comm. Merged S7Comm and Modbus show no such gap. It is the smallest S7-1500 and the S7-1516 is a much faster class, which is the likely explanation but not a proven one. Read its absolute times as that controller’s, not as "an S7-1500’s".

Everything so far measures what your client experiences. There is a second question, and on a busy plant it is the one that decides whether you have a problem: what does all this asking cost the PLC?

A PLC is not a server. It runs your program in a loop and answers questions in the gaps. Ask too much and the loop gets longer.

A longer loop does not look slow. Decisions are taken once per scan, so stretching the scan does not make the machine slower in any way an operator would call slow. It makes it less precise. The cut lands a millimetre off. The actuator overshoots, sometimes. The reject rate creeps up.

That is close to the worst diagnostic signature a fault can have. It is intermittent. It looks mechanical. Everything a maintenance engineer would sensibly check sits downstream of the cause. Nobody walks up to a machine cutting slightly out of tolerance and asks what protocol the historian is using.

This is also where the second story from the beginning of this article ends up. Nobody adds the dashboard that breaks the line. They add the eleventh one.

This surprised me, and it is the most useful thing in the article for anyone currently arguing about it.

Look back at the six-way table. One read of 80 values over OPC UA takes 179 ms unsecured and 181 ms signed and encrypted. That is a difference of 1%.

Push it further. On one controller I timed a single batched read at several sizes:

Encryption costs about a millisecond per read at 700 values, and 70 ms at a thousand. It is too small to plan around.

The cost is all in the handshake, and that is where it hurts. Opening the connection is a separate number, and it is not small:

The table has no row for merged S7CommPlus because merging does not touch the connection. Both open the same session: in a later sweep, plain and merged S7CommPlus exchanged the same bytes while connecting, on all three CPUs, to within 0.2%. The S7CommPlus row stands for both.

The connect column is a ladder. Modbus is the only protocol with no handshake at all. There is no session to establish because Modbus has no concept of one, so its 82 ms on the G2 is a TCP socket and nothing else. S7Comm does negotiate, but barely: a hundred bytes or so each way, and that exchange is where the request size from earlier gets agreed. S7CommPlus sets up a proper session and costs half a second. OPC UA costs two seconds, and nine with security switched on.

You pay that once per connection. So it matters enormously if your client reconnects for every poll, and not at all if it holds the connection open.

Read the bottom row twice. Turning OPC UA’s security on takes the connection from two seconds to nine on one controller, and from under half a second to twenty-eight and a half seconds on the old one. That is not a rounding error on a startup cost. That is a client that looks broken.

And S7CommPlus is in the same territory on that controller — ten seconds to open a session, against 149 ms for S7Comm on the same wire.

Which gives a rule you can act on:

That is not a small ask in practice. Plenty of tooling connects, reads and disconnects on a schedule, because that is the simple thing to write, and on that old controller a secured OPC UA poll built that way spends twenty-eight seconds connecting to do 214 ms of work. Every time.

Which is where people reach for the obvious fix and turn security off. Then they are paying a licence fee for a protocol that is now protecting nothing, and the thing that was actually wrong was never the encryption.

Several rows in my sweep failed. Almost none of them are what they look like.

Nearly every failure was my own timeout running out. The client gives a read request a deadline when it is submitted. An unmerged Modbus read of 1000 values is a thousand requests against one deadline, so once the clock passes five seconds every remaining value fails at once. Raise the timeout to sixty seconds and those rows pass. That is a speed difference crossing a default, not a protocol refusing to do something.

One controller’s OPC UA server does not get cheaper per value as the batch grows. It needs about 12.4 ms per value whether you ask for six hundred or a thousand. So it never refuses; it simply takes longer than whatever timeout the client set. Where it "stops" is wherever you put your deadline.

There was exactly one real size limit in the whole sweep. The web interface on one controller refuses a request body over 64 KiB, which a thousand reads exceeds. Bisected to the byte. Our driver had assumed twice that for a controller that reports nothing, and it now assumes the smaller number.

The general lesson is worth more than any of the specifics. A failure in a benchmark is evidence of something, and the something is usually your own configuration.

There is a cost that never appears in a benchmark, and on a plant-sized rollout it often decides the argument.

S7Comm, S7CommPlus and the web interface are all on board and free. Nothing to order, nothing to renew.

OPC UA is a separately licensed product. They are runtime licences: Basic on an S7-1200, and Small, Medium or Large on an S7-1500, picked by how big the CPU is.

Nothing enforces it. There is no key to install and no check on the controller. TIA tells you which size your configuration needs, and the CPU serves OPC UA whether you bought one or not. So it is a legal obligation rather than a technical gate, which makes it the kind of cost that surfaces in an audit rather than at commissioning.

Siemens do not publish a price list, so treat these as orders of magnitude from public distributor listings, converted to euros at an approximate rate:

Per controller. Twenty controllers is a four-figure sum. Two hundred is a five-figure one.

And there is a loop worth naming, because it is invisible in a feature comparison. The price is set by how big the CPU is, not by how much OPC UA you use:

Decide the protocol and the hardware together. Deciding the protocol afterwards is how a project finds a line item nobody budgeted for.

Ask for what you need in as few requests as your client will build. This is the single highest-value change available to most installations and it costs nothing.

Check whether your client merges adjacent addresses, and on which protocols. If you are on Modbus and it does not, you are leaving two orders of magnitude on the table. If you are on S7Comm you are leaving somewhere between five and thirty times, depending on the controller. On S7CommPlus over a standard-access data block, between three and fifty times, growing with the size of the read.

On an old or small SIMATIC, prefer merged S7CommPlus over a standard-access data block. On the old S7-1212C it read 2500 values 2.6 times faster than merged S7Comm and cost the cycle a third as much, with names, authentication and encryption on top.

Hold your connections open. Security is nearly free once connected and expensive to establish. A client that reconnects per poll pays the worst of both.

Before you buy OPC UA for variable names on Siemens hardware, price S7CommPlus. It is on the controller and it costs nothing. Read merged from a standard-access block, it is four to ten times faster than OPC UA over separate variables on the G2, and 57 to 148 times faster on the S7-1511. Read item by item, it is still about level with OPC UA on the G2. Buy OPC UA for vendor-neutrality, for the information model, or for a security story an auditor recognises. Do not buy it for naming you already have.

If your read volume is modest and your security requirements are real, buy OPC UA. The overhead is affordable at low rates and you get certificates, user authentication and selectable encryption to a public specification. This is where the standard advice is simply right. Budget the licence per CPU before you price the project.

If you have many vendors on the floor, you want one API — and there are two ways to get one. OPC UA gives you one by making every device speak the same protocol. The other way is to put the single API in your own application, and let it speak whatever each device speaks best. Which of those you want is a real decision with real trade-offs, and it gets a chapter of its own further down rather than a bullet here.

Before you replace a slow controller, check its request cost and its request size. A six-fold difference per request and a 240-byte limit explained every slow row on my oldest device. Both are cheaper to work around in software than in hardware.

Check the communication cap on every controller you are comparing. It is worth a factor of two and the default is not the same on every family.

And measure on your oldest, busiest machine, not your newest. Watch the cycle time rather than the response time. A controller that is answering you at the cost of its own scan will not tell you so; it will just get less precise, and you will look for the cause somewhere else.

And if security is the axis you care about most, it may be worth waiting a few weeks. On 13 October 2026 we are publishing a series on S7 security, written with Siemens under coordinated disclosure. This article has deliberately stayed on what these protocols cost. That one is about what they actually protect, and if you are close to a decision that turns on the difference, read it before you commit.

A disclosure first, because this is published by a company with an interest in its conclusions. I work on ToddySoft Connect, which provides drivers for every protocol here, and every number came out of its test suite. The tables came first and the argument came out of them. You should still know about my interest before you weigh my conclusions.

OPC UA’s strongest selling point is not speed and it is not really security either. It is the unified API. One client, one address space, one set of semantics, across controllers from vendors who agree on nothing else. That is a genuine engineering good and the free protocols offer nothing like it.

But look at how it delivers that. The abstraction lives on the wire. You get one API because every device speaks the same protocol, which means every device must speak it, including the ones that are worst at it. You cannot buy the unification without paying for the transport on every controller you own.

There is another place to put that abstraction. Move it up a layer, so you have one API in your application and many protocols underneath, and the protocol becomes a deployment detail instead of an architectural commitment.

So the new cell runs OPC UA, signed and encrypted, because there the security costs almost nothing. The twelve-year-old controller at the far end of the hall runs S7CommPlus, still named, still free. The old S7-300 that speaks nothing else runs S7Comm. Your application does not know the difference.

That is what ToddySoft Connect does, and it is the reason this bench exists at all: every protocol in this article is a driver we maintain, so the cost of each one is a question we have to keep answering anyway.

Read the next section before you take that as a recommendation.

Every section above has a correction folded into it. Not one was caught by review. Each was caught by somebody asking an obvious question of a number that looked fine.

"Merging is worth 7.6x on S7Comm, and 18x on Modbus." Both figures were diluted by the benchmark’s own design. Each run read every value individually before reading them in batches, and nothing can merge a request carrying one value — so both halves of every comparison paid that phase, which capped every ratio near the number of batched rounds. Measured batched read against batched read, it is 100 to 130 times on Modbus and 14 to 30 on S7Comm.

"Our optimizer makes some controllers slower." JVM warm-up, not the driver. The benchmark was measuring its own compilation.

"The old S7-1212C is slow because it is old." Its 240-byte request size and its six-fold per-request cost explain it. The PLC program contributes nothing measurable.

"Unmerged Modbus cannot read 2000 values." It can. That was our own five-second timeout, applied once per read request.

"OPC UA hits a request-size limit somewhere above a hundred values." No. One controller’s server needs 12.4 ms per value and ran past the deadline we set it.

"OPC UA is a hundred times slower than S7Comm on a SIMATIC." Only for the shape we first read it in. Every OPC UA value was an array element, which is that protocol’s worst case. Read as separate variables, the G2’s server was about seven times faster, and close to plain S7CommPlus.

Six mistakes, one shape. Five of the six were our own configuration mistaken for a property of somebody else’s product. Which is worth remembering the next time a benchmark tells you something convenient.

There is no best protocol. There is a controller with a budget, a network with a budget, a threat model, and a set of options that spend those budgets very differently.

But the biggest number in this whole article is not a protocol choice at all. It is the difference between a client that asks well and one that does not — a hundredfold on Modbus, and up to thirty on S7Comm, on the same wire, to the same controller, for the same data.

Group your reads. Hold your connections open. Measure before you commit. And when somebody tells you a protocol is the answer, ask them what it costs.