What is OPC UA, and who should be the server on your line

Sooner or later somebody asks you to explain OPC UA to a plant manager in five minutes. I have given that pitch. Machines speak one language, the business systems speak another, OPC UA is the interpreter sitting between them. It gets nods. It rarely gets budget, because a manager hears an analogy and then asks what it costs and what it saves.

The analogy is not wrong. It is just useless the moment you sit down to build the thing, because the hard part of what is OPC UA is not the definition. It is deciding which box owns the data, and finding out how many tags your controller can actually publish before it runs out of room. Both of those have hard numbers behind them, and both of them are cheaper to get right on paper than in commissioning.

What is OPC UA once you drop the analogy

OPC UA is an open standard for moving machine data between systems that were never designed to talk to each other. It is standardized as IEC 62541. It runs its own protocol over TCP on port 4840 by default, and it does not care what operating system sits on either end.

What separates it from Modbus or a plain fieldbus read is that it does not only move numbers. It moves the description of the numbers along with them. A server does not hand a client register 40001. It hands it a named node with a data type, an access level, and a place in a tree the client can browse. A client that has never seen the machine before can connect, walk the address space, and work out what it is looking at without an OEM mapping spreadsheet.

That is the whole idea. The rest is detail, and detail is where projects go sideways.

Classic OPC vs OPC UA, and why DCOM had to go

People ask what is OPC UA versus plain OPC, and the honest answer is that one of them was built on Microsoft plumbing and one was not.

The first OPC spec landed in 1996, a few months after the OPC Foundation was incorporated. It worked, and on a Windows-only plant it worked well for years. It was also built on COM and DCOM: Windows on both ends, security settings nobody enjoyed touching, and a transport that opens dynamic ports and gets shredded by any firewall worth having. Anyone who has burned an afternoon in dcomcnfg getting a historian to see a server two subnets away knows why a replacement was necessary.

OPC UA shipped in 2006 as a clean break. No COM, no DCOM, no Windows requirement.

	Classic OPC	OPC UA
Underlying technology	COM / DCOM	own binary protocol over TCP
Operating system	Windows only	Windows, Linux, embedded, controller firmware
Port	dynamic DCOM port range	4840 by default
Through a firewall	painful	one port
Security	Windows and DCOM permissions	certificates, signing and encryption in the standard
What the data looks like	tag name and value	typed nodes in a browsable address space
Can run inside a PLC	no	yes, on current controllers

 

The last row is the one that changes how you design a retrofit. Classic OPC always needed a PC in the middle. A current controller runs the server itself, and that removes a whole machine from the drawing.

Who should be the OPC UA server, and who should be the client

The default is the PLC as server and the PC as client. Anything else needs a reason you can say out loud.

It is not really a protocol question, it is a question of who owns the machine. The PLC has the I/O and the true state of the equipment, so it publishes. The PC consumes that and writes commands back down. If the robot in the cell exposes its own OPC UA server, and plenty do, subscribe to it directly rather than routing everything through the PLC.

Where people get in trouble is deciding that both ends should be server and client at the same time so each can call methods on the other. It looks tidy on a whiteboard, especially if you came from software where every service has an API. On a line it means the same value now lives in two places, and the first time the two copies disagree there is nothing in the system that can tell you which one is right. That is not a bug you fix in an afternoon.

Two habits keep this clean.

First, never publish your internal logic tags. Build a dedicated exchange area and expose only that, with separate tags for what the PLC writes and what the client writes. Nothing should be writable by two owners. On a Logix controller the access level sits on the tag itself, and safety tags are capped at read only or no access. That cap is a good habit for the rest of your tags too.

Second, use a handshake instead of a shared scratchpad. Say you have an HMI button that kicks off a task the PC actually executes:

1.  PLC sets Task1_Ready. The HMI button lights up.

2.  Operator presses it. PLC sets Task1_Start and clears Task1_Ready.

3.  PC sees Task1_Start, begins the work, writes back the task identifier it picked up.

4.  PC sets Task1_Done. PLC runs its post-processing, unlocks the doors, resets the robot state, clears the request.

Every step has one writer and one clearer. If the PC can fire a second request before the PLC has accepted the first, put an identifier on each request and a small queue behind it. A UTC timestamp is a perfectly good identifier. Skip that and the PLC eventually raises an error flag while the PC sits there with three outstanding requests and no way to know which one died.

What is OPC UA in practice: one side owns the data and publishes it, the other side only writes into an area built for it.

When neither end should be the server

There is a third pattern, and it is the one worth reaching for once the endpoint count climbs.

Put dedicated OPC UA middleware between them. Kepware is the usual choice. It sits between everything, reads from many sources including protocols that are not OPC UA at all, and presents one table that every device reads from and writes to.

A real shape for it: roughly forty particle counters on one system. he PLC needs status and counts from all of them. The HMI needs those counts too. And the counters themselves have to see command flags that the PLC sets. Wiring that as direct connections is a maintenance problem on day one and it dumps all the polling onto the controller. With that table in between, each device only ever talks to it, and the middleware can live on its own machine so the controller barely feels it.

The cost is another box to license, patch and back up. For a dozen tags that is not worth it. For forty endpoints across three protocols it pays for itself the first time you add a device.

Put it on its own machine and the controller stops carrying forty polling connections.

What a Logix controller actually gives you

Now the numbers, because they decide whether a job is possible at all.

Rockwell enables native OPC UA on the ControlLogix 5580, GuardLogix 5580, CompactLogix 5380 and Compact GuardLogix 5380 families, plus the ControlLogix and CompactLogix Process controllers. You need firmware version 36 or newer and Studio 5000 Logix Designer v36 or newer. The server runs on port 4840.

Limits worth knowing before anyone draws the architecture:

·       As a server the controller handles up to 10 external clients. As a client it connects to up to 10 external servers.

·       On firmware V36 the controller is either a server or a client, not both. Simultaneous server and client operation arrived with V37. If your design has the controller publishing to SCADA and also pulling from a robot's server, V36 will not do it.

·       OPC UA does not get a budget of its own. It shares the controller's communication resources with CIP Class 3 messaging and sits below CIP in priority. Your CIP traffic is protected, which is the right call, but it means OPC UA requests are what get rejected when the communication core is loaded.

·       ControlLogix 5580 redundancy does not support OPC UA on V36. Communication only runs through the embedded Ethernet port, and that port is disabled in a redundant 5580 system.

·       Synchronize the controller clock before you enable the OPC UA engine.

·       Subscriptions cap at 20 per session and 20 total, with 5000 monitored items.

The node budget, and why it runs out faster than you expect

Every controller has a hard ceiling on how many OPC UA nodes it can expose, and on the small processors that ceiling is low.

The counting rule is what catches people. Every member of a structure counts as one node, the structure itself counts as one, and every element of an array counts as one. So four DINT tags, one UDT with three members, and one 100-element DINT array is not six nodes. It is 4 + 1 + 3 + 1 + 100 = 109 nodes. A 5069-L310ER gets 300 of them. One decent-sized array and a third of the budget is gone before you have exposed anything a human would call useful.

Node counting on a Logix server. Arrays are what quietly eat the budget.

Controller	OPC UA nodes
ControlLogix 5580
1756-L81E, 1756-L81EP	none
1756-L82E	600
1756-L83E, 1756-L83EP	1200
1756-L84E	10000
1756-L85E, 1756-L85EP	15000
GuardLogix 5580
1756-L81ES	none
1756-L82ES	900
1756-L83ES	1500
1756-L84ES	15000
CompactLogix 5380
5069-L306ER*	none
5069-L310ER*, 5069-L320ER*, 5069-L330ER*	300
5069-L340ER*, 5069-L350ER*	600
5069-L380ER*	900
5069-L3100ER*	2000
Compact GuardLogix 5380
5069-L306ER*S*	none
5069-L310ER*S*, 5069-L320ER*S*, 5069-L330ER*S*	300
5069-L340ER*S*	600
5069-L350ER*S*	900
5069-L380ER*S*	1200
5069-L3100ER*S*	4000

 

Four rows on that table deserve a red circle. The 1756-L81E and 1756-L81EP expose no OPC UA nodes at all. Neither does the 1756-L81ES, and neither does the 5069-L306ER or its safety variants. These are current products, they will take V36 firmware, and they still cannot act as an OPC UA server. If a spec comes across your desk reading "CompactLogix 5380 with OPC UA" and the quote comes back with a 5069-L306ER on it, that job is dead before the panel ships.

5069-L340ERM. That side label is the only thing on this controller that tells you its OPC UA node budget is 600. On the smallest processor in the same family it is zero.

The 5480 does it a different way

CompactLogix 5480 is the odd one out. It has a Windows core sitting alongside the Logix engine, and the OPC UA server there is not the controller. You run FactoryTalk Linx and FactoryTalk Linx Gateway on the Windows side, and that is what your clients connect to. Same protocol on the wire, different capacity, different licensing, different thing to patch.

What it costs on the Siemens side

Worth knowing if you run a mixed plant. On a 5580 or a 5380 there is no separate license behind the server; turning it on is a firmware and configuration job. Siemens is not set up that way. The S7-1500 has an OPC UA server sitting in firmware, but it needs a runtime license to switch on, tiered by CPU: Small, Medium, Large. A 1515 or a 1516 lands in Medium. One license per CPU, not per site, and it is the line item that gets left off the first quote almost every time.

FAQ

What is OPC UA in plain terms?

An open standard for machine data that carries the description of the data along with the value. A server publishes a browsable tree of named, typed nodes. Clients connect, browse, read, write, and subscribe to changes instead of polling on a timer.

What is OPC UA used for on a plant floor?

Getting controller data into things that are not controllers: MES, historians, SCADA, a database, a quality system. It also joins equipment from vendors that share no common fieldbus. If your whole cell is one brand on one network and the data already gets where it needs to go, you may not need it at all. That is a legitimate answer and I have given it to customers.

Do I need OPC UA if my native drivers already work?

Probably not, and I would not tear out something that works to get it. A Rockwell shop pulling tags through a native driver is already getting the data. OPC UA earns its place when you have several vendors, several protocols, or a consumer that is going to move to a different platform later without you rewriting the interface. Buying it as a philosophy rather than a requirement is how it gets a bad name.

What is OPC UA doing to my controller's scan time?

On a Logix controller, nothing to the logic scan. It runs on the communication core and shares that budget with CIP Class 3 messaging at lower priority. Your drives and I/O keep their bandwidth. OPC UA is what gets squeezed when the comms core is busy, which shows up as rejected requests rather than a slow machine. Watch the communication core usage on the controller web pages if you are pushing it hard.

Is it secure out of the box?

Certificates, signing and encryption are in the standard. Whether they are switched on depends on how that particular server was set up, and plenty of endpoints are sitting wide open right now. Treat an OPC UA endpoint as an open door until you have checked its security policy, its certificate trust list, and the access level on every published tag.

Before you spec the controller

By this point what is OPC UA matters less than which part number can actually run it. Decide the server role first, then pick the hardware. Count the nodes you genuinely need with the structure and array rule applied, add margin for the tags somebody will inevitably ask for in month three, and check that number against the capacity table before a purchase order goes anywhere.

We keep ControlLogix 5580 and CompactLogix 5380 controllers in stock, including the higher-memory processors that carry enough node capacity to be a real OPC UA server rather than a demo. If you are replacing a controller specifically to get OPC UA onto an existing line, send over your tag count and the model you are considering and we will tell you straight whether that part will carry it. Sometimes the answer is that the processor already in your rack cannot, and that is a much cheaper thing to hear before the order than after.