For most of the last decade, integrating a cobot into a plant’s control architecture meant one thing: a fistful of digital I/O points, maybe a couple of analog signals for tool changers, and a handshake protocol you drew up yourself on a whiteboard. It worked. It was also brittle, hard to diagnose, and completely blind to anything happening inside the robot controller beyond a handful of discrete bits. That era isn’t over, but it’s no longer the default. Universal Robots, Fanuc’s CRX line, Doosan, and Techman have all spent the last several years building out native OPC UA servers and PLCopen-style function block libraries for their controllers. The teach-pendant-only, I/O-only cobot is increasingly the exception on new builds, not the rule.
That’s a real architectural choice now, not a hypothetical one, and it’s worth treating it like one. Each of the three patterns — native OPC UA, vendor PLCopen function blocks, and traditional fieldbus/I/O handshake — has a legitimate place. The mistake is picking one out of habit instead of matching it to what the cell actually needs to do.
The three patterns, plainly
Hard I/O / fieldbus handshake is the pattern everyone already understands: digital signals for start, stop, fault, in-position, part-present, plus maybe a Profinet or EtherNet/IP fieldbus connection carrying a small block of registers for recipe number or part count. It’s dumb in the best sense — deterministic, low-latency, and easy for a controls tech with no robotics background to troubleshoot with a multimeter and a ladder diagram.
PLCopen-style function blocks are the middle path. The robot vendor ships a certified FB library — usually for Siemens TIA Portal or Rockwell Studio 5000 — that wraps motion and I/O commands into structured, standardized calls: move to position, gripper open/close, get robot status, fault reset. The PLC still owns the sequencing logic, but it’s talking to the robot through a much richer, semantically meaningful interface than raw bits, and the library handles the underlying fieldbus mapping for you.
Native OPC UA flips the ownership model. The robot controller exposes its own information model — position, program state, I/O, diagnostics, sometimes safety status — as OPC UA nodes that a PLC, SCADA system, or MES can subscribe to directly. In this pattern the robot is doing more of its own sequencing and simply reporting state and accepting commands, rather than being puppeted point-to-point by the PLC.
Cycle time is the first filter, not the last
If your cell is running a cycle measured in a couple of seconds — pick-and-place, machine tending with tight takt — latency and determinism matter more than information richness. OPC UA, even client/server done well, introduces polling or subscription overhead that a hard-wired discrete signal simply doesn’t have. For genuinely tight cycles, the traditional handshake or a PLCopen FB call over a real-time fieldbus is still the right answer. The PLC’s scan cycle and the fieldbus’s deterministic timing are doing the work OPC UA isn’t built for.
Where cycle time is looser — assembly cells with dwell time, inspection stations, cells where the cobot is one of several asynchronous stations — the latency penalty of OPC UA stops mattering and its advantages start to dominate. You’re not fighting milliseconds; you’re trying to get good visibility into what the robot is doing and why it stopped.
Changeover frequency changes who should own the logic
This is the part of the decision that gets skipped too often. Ask where you want changeover and recipe logic to actually live.
High-mix cells that reconfigure often — different programs, different grippers, different part families multiple times a shift — benefit from pushing more autonomy into the robot controller and using OPC UA to pass high-level state: program name, recipe ID, cycle complete, fault code. The robot vendor’s own programming environment is usually better at managing a library of programs and tool offsets than a PLC ladder routine reinvented for the purpose. Let the robot be smart about the how; let the PLC and MES be smart about the what and when.
Low-mix, high-volume cells — one part, one program, running for a long time between changeovers — don’t need that flexibility, and the overhead of an information model you barely touch after commissioning isn’t worth it. PLCopen function blocks or straight I/O keep the sequencing centralized in the PLC where your maintenance team already knows how to read it.
A rough decision framework
- Sub-second, tightly synchronized cycles, low mix: traditional I/O/fieldbus handshake, or PLCopen FBs if you want richer diagnostics without giving up PLC-side determinism.
- Moderate cycle times, occasional changeover, PLC-centric plant: PLCopen function blocks. You get standardized, higher-level commands and better fault visibility while keeping sequencing where your team already lives.
- Longer or asynchronous cycles, frequent changeover, or MES/SCADA wants direct visibility into robot state: native OPC UA. Let the robot controller own its own program logic and expose state for supervisory systems.
- Cell needs to report into a historian or MES without PLC involvement at all: OPC UA is close to mandatory — this is the scenario it was built for, and running that data through the PLC as a pass-through is usually a design smell.
Where PLCopen quietly wins
The undersold advantage of the PLCopen approach is organizational, not technical. If your plant standardizes on Siemens or Rockwell platforms and your maintenance techs are PLC people first, a certified function block library means they can read robot interaction the same way they read every other piece of equipment on the line — as structured logic in an environment they already know cold. You don’t need a robotics specialist on shift to understand why a fault bit tripped. That matters more than it sounds like it should when you’re troubleshooting at 2 a.m. and the person on the floor has never touched a teach pendant.
OPC UA’s advantage is the mirror image: it’s the right choice when the consumer of the data isn’t your PLC at all, but your MES, a historian, or a fleet-level dashboard watching several cells at once. Trying to force that use case through discrete I/O means building a shadow reporting layer in the PLC that nobody asked for and everybody has to maintain.
Don’t mix patterns inside one cell without a reason
The failure mode worth watching for on new builds is a cell that half-commits — hard I/O for the safety-critical handshake, PLCopen FBs for motion commands, and a native OPC UA connection bolted on for MES reporting, all configured by different people at different points in the project. Each piece might be defensible in isolation, but now you’ve got three interfaces to a single robot controller, three places a fault can hide, and no one diagram that shows the whole picture. If you’re going to blend patterns — and sometimes you should, using I/O for safety and OPC UA for supervisory data is a legitimate split — document why each interface exists and who’s responsible for it. The vendors have finally given you real architectural options. The job now is making a deliberate choice and writing it down, not defaulting to whatever the last integrator happened to know.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
