Why Pay for the OPC UA Server on a Beckhoff Controller?

ADS is the protocol TwinCAT itself is built on. Engineering, the runtime and every Beckhoff tool talk to the controller over it. It is on every controller. It costs nothing extra.

OPC UA is something you add. Beckhoff’s server, TF6100, is a licensed TwinCAT function. Install it, license it, configure it, and any OPC UA client can browse the program’s variables by name. Standard protocol, standard security, standard tooling.

So when a project specifies OPC UA for a Beckhoff line, the question is worth asking out loud. Why pay for a second server on a controller that already has a native one?

The usual answer is interoperability. Often that answer is right. This article adds a question the license price does not show: what does each way of reading cost the controller itself?

A PLC runs its program in a fixed cycle and answers requests in the time that is left. Whatever a client asks for has to be paid for somewhere on that controller. Either inside the task that runs the machine or beside it. The interesting part is not only how much, but where the work lands and how it grows when you ask for more.

The Siemens article looked at the same kind of question from the client’s side. This one stays on the controller.

The license price is only part of what the OPC UA server costs. The rest is the effort of getting it running, and on Beckhoff hardware that effort is considerable.

On a Siemens controller, the OPC UA server is a setting in the device’s properties in TIA Portal. On our Linux-based Beckhoff controller it took four separate steps:

None of these steps is hard once you know it. Together they are a procedure someone has to document, and repeat on every controller.

ADS needs none of them. It is already running.

A client reads N integers from a TwinCAT 3 controller. N is 80, 500 or 2500. It either polls at a held rate (every 2 s, 500 ms, 200 ms, 50 ms, 20 ms or 10 ms) or subscribes to the values.

The values come in two shapes: elements of one array, and separately 2500 distinct variables. The array is never read as a whole. Each value is its own item in the read, addressing one element, so 2500 values are 2500 items either way. The difference turns out to matter a great deal for OPC UA.

While it does, I read the controller’s own figures beside the workload:

Every rate is held for 10 s and compared against an idle baseline. Every measurement runs three passes, in rotated order. A positive control proves the figures can move at all before a flat row is read as "no cost". Without it, a quiet row could simply mean the probe was not looking.

Two controllers:

So every OPC UA figure below comes from the CX9240. The C6920 shows how the ADS results change on a different machine.

An ADS client names a variable by its symbol. The runtime serves memory by address. Every client has to turn one into the other somewhere. Where it does that turns out to matter a great deal.

The driver measured here can do it six ways (symbol-resolution=…​). Together they cover how ADS clients in general work. on-demand is our driver’s default. Other drivers might default to other modes:

Beside them I measured on-demand over Secure ADS, both with a pre-shared key and with certificates. On the OPC UA side, three security levels: None, Sign, and Sign and encrypt (Basic256Sha256). None of them made a measurable difference to the load on the controller. Secure ADS measured the same as plain ADS, and the three OPC UA levels measured the same as each other. For OPC UA that held on the client too: every security level read at the same rate.

Subscribing moves the work into the controller. The client stops asking. The controller has to watch the values and report them.

The table below mixes two kinds of subscription. All rows but one are cyclic: the client names an interval, and the controller works on the values at that interval. What it does then differs by protocol:

One row is on change: no interval at all, the controller reports a value only when it changes.

The first run used values that never change, elements of one array. That measures what it costs the controller to sample and watch, but not to deliver. A second run, further down, changes the values.

On the CX9240, both protocols reach the PLC task, in different ways.

The two grow along different curves.

ADS grows with the number of values and how often it sends them. More values, faster, costs more. Gradually.

OPC UA behaves like a step. Sampling slowly costs nothing measurable. Sampling fast costs about 9 µs, almost regardless of size.

So a small, fast OPC UA subscription costs the task about three times what ADS does. At 2500 values every 10 ms the two look about equal. Keep in mind that the OPC UA server had nothing to send here, while ADS sent every value at every interval.

Over 2500 separate variables the picture moves towards ADS. ADS costs the same as over the array, 11.8 µs at 10 ms. Fast OPC UA sampling costs more, about 17 µs instead of 9. There, ADS subscriptions cost the task about 5 µs less than OPC UA.

Secure ADS costs the same as plain ADS here too.

On the C6920, ADS subscriptions leave the PLC task flat. Only the CPU figure moves, to 1–2%.

So far every figure was about the controller. The same reads also cross the network, and there the protocol and the client’s habits show up in bytes.

Two separate runs measured this, both on the CX9240, counting every byte of request and answer.

The first reads the same 56 values of mixed types over both protocols:

OPC UA moves about four and a half times the bytes ADS does for the same values. Security adds little to either: about a fifth to ADS, a few percent to OPC UA.

The second reads 3000 integers of one array over ADS, in each of the ways a client can ask:

An integer is two bytes. So the first row moves the data and almost nothing else. The client sees that the values sit next to each other and asks for the whole span at once. Every other row pays a header per value, and the name-based modes also send the name, or a handle, for every value on every read.

At the rates in this article that adds up. 2500 values every 10 ms come to about 0.5 MB a second read the first way, and about 4.5 MB a second with one item per value. Those totals are our arithmetic from the bytes per read, not a separate measurement.

We did not measure OPC UA’s bytes at those sizes. At 56 values it was already the heaviest row.

A disclosure first. I work on ToddySoft Connect. It provides both drivers measured here, the ADS one and the OPC UA one, and every number came out of its test suite. The OPC UA server on the controller is Beckhoff’s own. You should know that before you weigh my conclusions.

With that said, here is what the figures support.

If you need high-frequency data, the license buys you less of it. Polled every 10 ms, ADS delivered every read we asked for, at every size we tried. The OPC UA server kept up at 80 values. At 500 separate variables it managed 52 reads a second, at 2500 about 11. If your data needs to be fresh every few tens of milliseconds, that settles the question before the license price comes up.

If you poll, the native protocol is the one the controller barely notices. ADS by address kept the PLC task within about 3 µs of idle at every size and rate we tried. OPC UA left the task alone at slow rates. Once its server was kept busy, the task paid 15–19 µs, against 2–4.5 µs for ADS at the same rate.

Skipping the license only helps if the ADS client reads well. Resolve once and read by address, and the controller stays idle. Ask the runtime to resolve on every read, and the same data can take a third of TwinCAT’s CPU or more.

The mode you get is usually an implementation detail of your driver. The ToddySoft driver supports all six. Its default, on-demand, resolves each name once and then reads by address, which puts it in the rows that left the controller idle. If you are writing your own client, or choosing a library, find out which of the six it uses.

Subscriptions are closer. Neither protocol wins everywhere. Small and fast favors ADS by about three times in the task. Over 2500 separate variables, ADS is still about 5 µs cheaper. With changing values, ADS on change delivered every change for less than OPC UA needed to sample fast. OPC UA is cheapest where a change is allowed to wait: sampling every 2 s cost the task almost nothing.

The license is not the whole bill. The setup is paid again on every controller: installed as root, configured in two places, licensed by email. Every new variable is then a change to the PLC code, and on our controller a restart. ADS is there from the start and picked up new variables as soon as they were downloaded.

ADS is also the lighter load on the network. For the same 56 values, ADS moved 623 bytes per read and OPC UA 2,880, about four and a half times the network volume.

Security is not a reason to buy it. Secure ADS measured the same as plain ADS, with a pre-shared key and with certificates. The three OPC UA security levels measured the same as each other.

So the license buys neither speed nor a lighter load on the controller. What it buys is real all the same. Every other system on the floor can read OPC UA without knowing anything about Beckhoff. It brings an information model and security an auditor recognizes. Its cost in the task is measured in microseconds. If a system you cannot change only speaks OPC UA, that alone settles it.

If the client is yours, the choice is open. The Siemens article makes the longer case for putting the unified API in your application and letting each device speak what it speaks best. On a Beckhoff controller, what it speaks best is ADS.

The figures say the two ways in put their work in different places. A busy OPC UA server puts part of it in the task that runs your machine. ADS by address puts almost none anywhere. On a busy controller, weigh that before you weigh the license.

The license is the cost you see. The other one lands on the controller.

Read natively by address, and the controller hardly knows you are there. Make the runtime resolve names on every read, and one of our two controllers spent up to 46% of its CPU doing it. Keep the OPC UA server busy, and the task that runs the machine pays for it.

None of those costs is large on its own. They are the kind that add up one dashboard at a time. So before you buy a second server for a controller that already has one, find out what the first one can do.