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. A third article puts both vendors side by side with five more.

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, with the driver exactly as it ships. Where the three passes disagree, the figure is not quoted. 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.

A subscription is either cyclic, at an interval the client names, or on change. What a cyclic subscription does with its interval differs by protocol:

The values did not change during the test. So it measures what watching costs and what a cyclic subscription delivers, not what delivering changes costs.

ADS delivers what it is asked, down to 10 ms. Every mode, Secure ADS included, delivered within about 1% of the requested rate on both controllers, up to 250,000 values a second for 2500 values every 10 ms.

OPC UA sent the initial values, then nothing. The server accepted all 2500 subscriptions. With static values it reports each value once and nothing after, at any requested rate. The protocol works that way; no server limit is involved.

What watching costs. For ADS in our driver’s default mode:

The C6920 does not notice any of it, even 2500 values every 10 ms. The CX1010 pays a little, and more CPU as the cycle tightens. The CX9240’s figures moved the most and disagreed the most between passes. Across all its ADS modes, the stable cells put 80 values at about 2 to 3 µs, 500 at 3 to 6 µs, and 2500 at around 9 to 12 µs, 27 µs with handles kept at 10 ms.

What delivering changes costs was not part of this run: the values held still throughout.

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.

A separate capture measured exactly the reads of the load runs on the wire: the same values, at 80, 500 and 2500 per read, every way of asking. The figures are whole Ethernet frames in both directions, acknowledgements included.

Indented rows are the unindented row above them with security added. The two Secure ADS rows send the first row’s reads over TLS. Sign and Sign and encrypt are OPC UA’s two security levels on the same read.

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.

OPC UA moves about 19 times the bytes ADS does for 2500 separate variables, 23 times over array elements, and eight to ten times for 80 values. Every OPC UA value travels with its node id and its own encoding. That overhead does not shrink as the read grows. ADS by address does: the fixed part of the request is spread over more values.

The ADS modes split the same way. per-request adds one lookup per read and ends up next to the default at large reads. The three modes that work by handle or by name carry something per value: handle-on-demand a small request of its own for every handle, by-name and handle-per-request the symbol name in every read.

Security adds little to either. Secure ADS adds about 105 to 145 bytes per read for its TLS framing, and nothing per value. OPC UA’s three security levels stay within a few percent of each other.

At the rates in this article that adds up, but not to a problem. 2500 values every 10 ms come to about 0.55 MB a second over ADS. Over OPC UA the same 2500 separate variables once a second come to about 0.1 MB a second. Those totals are our arithmetic from the bytes per read, not a separate measurement. Even the heavier one is a small fraction of the controller’s 100 Mbit/s port.

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 55 reads a second, at 2500 about 12. 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. Polled faster, it cost the task 17 to 37 µs at its 95th percentile, depending on how the values were stored.

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 up to 40% of TwinCAT’s CPU.

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.

For subscriptions, the two do different jobs. ADS delivered every value at every cycle, down to 10 ms, and on the C6920 that cost nothing measurable. OPC UA reports only changes. What delivering them costs was not part of this run.

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. Reading 2500 values, ADS moved 2.2 bytes per value and OPC UA 51, about 23 times the network volume. At 80 values it was 5.7 against 53.5, about nine times.

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 40% 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.