ROS 2 Integration With Legacy Factory Control Systems

Most factories running today were wired for control 15 to 25 years ago, and the PLCs and SCADA systems from that era are not going anywhere. They were built around one job: deterministic, millisecond-accurate control of safety stops, timing sequences, and physical actuation. Swapping a general-purpose computer in for a PLC on the floor doesn't work without shielding against electromagnetic noise from variable frequency drives and welders, metal shavings, coolant spray, and washdown pressure that would kill consumer-grade electronics in a season. The installed base survives because it's too expensive to rip out and too safety-critical to interrupt. The actual engineering task is connecting modern robotics software to infrastructure that was built decades before anyone wrote a line of ROS code. It's connecting modern robotics software to infrastructure that was built decades before anyone wrote a line of ROS code.

The pressure ROS 1's end-of-life put on operators already invested in legacy infrastructure

ROS 1 Noetic hit end-of-life on May 31, 2025. Regular updates stopped, community support dried up, and every plant still running Noetic lost the option of just staying put.

Moving to ROS 2 was never going to be a version bump. Custom packages need rebuilding, hardware-specific integrations need re-validating, and application code that took years to harden in real deployments needs retesting from scratch. That's a large part of why adoption has dragged: migration complexity and gaps in documentation are the complaints raised repeatedly in the community, and debugging workflows feel unfamiliar even to teams who know ROS 1 cold. A survey spanning 2025 and 2026 pulled together more than 8,500 publications from 2009 through 2026, touching 176 packages, and the sheer size of that literature says something on its own: the field still hasn't settled the question of whether ROS 2 is ready for industrial deployment at scale.

What changed on May 31, 2025 is that the question stopped being theoretical. Plants with PLCs and SCADA systems that will keep running for another decade now have to figure out how ROS 2 fits alongside them, not whether it's worth thinking about.

The architectural principle that makes integration possible: ROS 2 complements PLCs rather than replacing them

The idea holding this together is simple to state and harder to execute: let the PLC keep doing what it's good at, deterministic control, fieldbus communication, functional safety, and let ROS 2 handle the computation and coordination layered on top. Nobody's asking the PLC to give up the safety-critical work. ROS 2 adds intelligence and analytics; the PLC keeps its hands on the controls.

This is the pattern behind most brownfield retrofits worth studying: an edge gateway talks to the enterprise network while the legacy PLC and SCADA system keep executing their control loops locally, untouched by whatever overhead or delay the new network layer introduces. The retrofit philosophy is to give old hardware new networking and software capability without displacing the control systems that already work.

Once that separation is in place, every downstream decision, which protocol, which middleware, how the real-time network gets designed, how security gets enforced, becomes a decision about the boundary between the two systems. What crosses it, in which direction, at what latency, under what policy. Get the boundary right and the rest follows.

Protocol options for crossing the boundary: Modbus, OPC UA, and EtherCAT compared on industrial fitness

Three protocols keep appearing across real industrial ROS 2 projects, and each earns its place differently.

Modbus TCP is old, simple, and cheap to implement, so it keeps getting picked for projects bridging ROS 2 Humble to Siemens PLCs where Industry 4.0 readiness is the goal but the PLC side can't be upgraded. OPC UA does more: it gives a unified interface across mixed devices and platforms, and it's the protocol of choice when ROS 2 nodes need to publish robot status, alarm states, and process data up to an existing SCADA dashboard without a custom translation layer for every vendor involved. Then there's the fieldbus layer underneath both, EtherCAT, CANOpen, Modbus, Beckhoff ADS, CtrlX DataLayer, covered by Denis Stogl and Nikola Banović of b-robotized GmbH at the ROS-Industrial Conference 2025 as the set of industrial communication protocols that actually make production-ready robotic systems possible.

The choice between Modbus TCP and OPC UA isn't purely a technical one. OPC UA's richer information model and built-in security layer suit an architecture built to scale and last; Modbus TCP's bare-bones simplicity suits a plant where the PLC side is frozen in place and nobody's touching it. Mixing ROS 1 and ROS 2 devices onto the same OPC UA testbed adds yet another wrinkle: two robots on different middleware can't talk directly, they need a bridge solution sitting between them. And in practice, the protocol decision often isn't even yours to make freely, most plant control systems run manufacturer-specific communication environments that narrow the field before anyone gets to weigh trade-offs.

How the PLCnext ROS Bridge works as a reference architecture

Fraunhofer IPA, working with Phoenix Contact, published the PLCnext ROS Bridge in March 2026 as an open-source layer connecting Phoenix Contact's PLCnext industrial PLCs to ROS-based robots. Walking through it shows what a disciplined version of this boundary looks like in practice.

The bridge runs as a Docker-packaged PLCnext App, so deployment is containerized and doesn't depend on painstakingly matching environment configurations by hand. It gives bidirectional communication between the PLC's Global Data Space and ROS topics over gRPC. An Interface Description File drives a code-generation workflow that automates the creation of ROS publishers and subscribers for chosen PLC variables, cutting down on hand-written glue code that would otherwise need maintaining forever. The PLC still owns EtherCAT/FSoE and PROFINET/PROFIsafe fieldbus communication along with functional safety; ROS keeps the high-performance computation.

A concrete example: when the navigation stack publishes a command velocity, the bridge (subscribed to that topic) writes the value straight to the corresponding PLC variable. Safety status and system state flow the other way, from PLC to ROS, over a topic defined for that purpose. What matters here is the discipline: the boundary is managed through a defined interface file that specifies the mapping explicitly, avoiding a patchwork of ad hoc topic mappings someone will have to reverse-engineer two years from now. That's the design choice that keeps an integration maintainable.

One thing the bridge does not solve: determinism on the ROS side. The PLC stays the deterministic anchor. ROS remains best-effort unless something further is done to change that, which is a separate problem covered later.

ros2_control as the hardware abstraction layer that sits between ROS logic and physical actuators

ros2_control is the hardware-agnostic framework that abstracts low-level control away from higher-level systems like MoveIt2 and Nav2, so those systems don't need to know or care what's on the other end of the wire. It carries forward a similar abstraction model but is built for ROS 2's communication and lifecycle management.

The repository breaks down into pieces integrators will actually touch: ros2_control holds the main interfaces and framework components, ros2_controllers ships the widely used controllers (forward command, joint trajectory, differential drive), realtime_tools provides real-time buffers and publishers, and control_toolbox holds PID and other control theory implementations.

At ROSCon 2025, Dr. Denis Stogl reported that the number of maintainers has doubled and that ros-controls is now an Open Source Robotics Alliance project. Recent merges include fully async components, support for variants, URDF access from every component, and integrated joint limiters at the hardware layer that controllers can draw on too. A 2026 ROSCon workshop, titled "Scaling ros2_control: From Async Hardware Drivers to RL Inference Engines," digs into the harder production questions: thread-safe data exchange, managing inference jitter, keeping drivers and controllers synchronized, and holding real-time stability while deploying RL policy models through ONNX or Torch.

For anyone integrating with legacy hardware, this abstraction layer is what protects the rest of the ROS application from the specifics of any one fieldbus or PLC interface. Swapping the protocol only requires a driver change, not a rewrite of the application logic sitting on top.

Where real-time determinism breaks down in ROS 2

ROS 2 does not provide hard real-time guarantees out of the box. This limitation carried over from ROS 1, and while it was a driving reason behind the ROS 2 redesign, it was never fully closed. DDS-based communication adds its own latency and resource cost, and that cost bites hardest on embedded platforms where CPU and memory contention already push jitter higher than anyone would like.

Florian Gramß of Siemens AG addressed the tension at the ROS-Industrial Conference 2025: traditional automation demands determinism, ROS-based systems offer flexibility, and the two don't merge cleanly. The challenge of bridging that gap remains a central theme across industrial ROS 2 deployments.

The DDS implementations in common use include Eclipse CycloneDDS, eProsima Fast DDS, and RTI Connext DDS, each with its own trade-offs for industrial deployment. But configuring that QoS layer correctly is its own specialty, and the gap between how sophisticated the architecture looks on paper and how hard it is to operate correctly is a real and often-cited problem in the ecosystem.

Time-Sensitive Networking is a direction worth watching for closing the gap between ROS 2's best-effort delivery and the harder real-time guarantees industrial applications need. Tighter integration between ROS 2 middleware and emerging network standards remains an active area of development, with the goal of narrowing the gap with legacy fieldbus real-time guarantees.

Zenoh sits outside the DDS lineage as a middleware option, particularly for wireless, WAN, or multi-network industrial setups, where its latency advantages over DDS tend to appear most clearly. DDS still wins on latency over plain wired Ethernet. Zenoh isn't a settled replacement yet, but it belongs in any serious conversation about middleware strategy over the next several years.

For anyone designing around this, for hard real-time needs, the PLC remains the anchor, full stop. TSN and careful DDS QoS tuning can close much of the gap for soft real-time needs on the ROS side, but neither happens by accident. Both demand deliberate network design, not default settings left as they came out of the box.

Security considerations when connecting ROS 2 to plant networks that were never designed to be networked

SROS2 builds security into ROS 2 through DDS-Security 1.1: mutual authentication using X.509 certificates and PKI, AES-GCM encryption for data in transit with session keys derived through ephemeral ECDH, and fine-grained XML policies that scope which nodes can publish or subscribe to which topics and domains.

The overhead this adds is small. The latency overhead SROS2 adds has been characterized in the security literature as modest, small enough to leave other factors as the deciding consideration. That's not the reason to avoid it.

The real limitations sit elsewhere. Managing certificate lifecycles and keystore administration across a multi-robot plant deployment gets complicated fast, and complexity at scale is where security models tend to fail in practice, not in the cryptography itself. More importantly, legacy PLCs and SCADA systems have no equivalent security model. The OT-side endpoint of a ROS 2 bridge is often sitting there unprotected no matter how carefully SROS2 is configured on the ROS side.

Brownfield deployments make this worse before they make it better. OT networks were built to be isolated, air-gapped, cut off from anything resembling an open network. Connecting them to IT infrastructure through a ROS 2 bridge exposes years of accumulated network architecture debt that nobody had to think about while the OT side stayed sealed off. The same separation-of-concerns pattern recommended for brownfield retrofits, edge gateway handling enterprise communication, PLC staying local and isolated, doubles as a security control, since it keeps the attack surface on the OT side narrower by design. Security has to be designed into the architecture from the start. Bolting it on after the bridge is already running doesn't work.

What a production-ready integration requires beyond the protocol and middleware decisions

Robert Wilbrandt of the FZI Research Center, speaking at the ROS-Industrial Conference 2025, drew a line between a research prototype and an industrial system: driver lifecycles, memory management, and allocation tracking are what make "robustness" something you can measure, rather than a word on a slide. Denis Stogl and Nikola Banović, at the same conference, put diagnostics and hardware abstraction on equal footing with protocol integration, treating them as essential from the start.

None of this is solvable in software alone. EMI from variable frequency drives and welding equipment needs shielded cabling and proper grounding, full stop. Metal shavings, lubricants, and coolant spray need industrial-grade enclosures around any compute hardware added to the floor, and no amount of clever middleware configuration substitutes for that.

Felix Exner of Universal Robots, also speaking at the ROS-Industrial Conference 2025, raised a structural concern that gets less attention than it deserves: keeping a stable ROS ecosystem across multiple distributions while balancing documentation quality, development speed, and long-term support. That's a genuine operational headache for a plant that can't push a software upgrade on the same schedule a startup would.

The async hardware interface components merged into ros2_control in 2025 directly target one of these production concerns, the I/O bottlenecks that synchronous hardware interfaces used to cause, which showed up as jitter in the control loop. And once a single robot's integration is solid, multi-robot coordination is the next layer of complexity waiting: frameworks like ROSCell and Nav2-based fleet management sit one tier up from everything discussed here, and they inherit every one of these boundary, determinism, and security decisions rather than starting fresh.