DDS Has a Rival in ROS 2 for the First Time

If your product moves data between moving parts, whether that is a fleet of autonomous machines, a production cell, a vehicle platform or a distributed control system, there is a reasonable chance it runs on the Data Distribution Service. DDS is the Object Management Group standard for data-centric publish and subscribe messaging, and it has spent twenty years quietly underpinning systems where late data is the same as wrong data.

Most engineers meet it through ROS 2, which was built on DDS from the beginning. That decision shaped a generation of robotics software. It is also the decision that has just been reopened.

What DDS actually gives you

It is worth being precise about this, because the value of DDS is often described in the vaguest possible terms and then dismissed as heavyweight.

DDS is data-centric rather than message-centric. Instead of shipping opaque payloads between endpoints, participants share a typed global data space. The middleware understands the shape of your data, which is what allows it to filter, cache and enforce guarantees on your behalf rather than leaving that to application code.

There is also no broker. Participants discover each other and communicate peer to peer, so there is no central process whose failure takes the system with it. For anything safety related or genuinely distributed, that property is difficult to give up.

The part that earns its keep in production is Quality of Service. DDS exposes policies that let you state your real requirements and have the middleware enforce them:

Written out like that, the appeal is obvious. These are requirements every distributed system has. The question is only whether you implement them yourself or inherit them.

The new development: ROS 2 has a non-DDS option

With the Jazzy Jalisco release, ROS 2 gained rmw_zenoh, a middleware layer built on the Zenoh protocol. Until then, every officially supported ROS 2 middleware had been a DDS implementation: Fast DDS, Cyclone DDS, Connext and GurumDDS among them.

This is the genuinely new thing, and it is worth stating carefully because it is easy to over-read. Fast DDS remains the default middleware in Jazzy and in Kilted. Zenoh is an additional option, not a replacement, and the ROS 2 project has been clear that DDS is not going anywhere.

What makes it significant is not that DDS lost. It is that the middleware layer in ROS 2 is now genuinely pluggable in practice rather than in principle, and that teams have a supported way to make a different trade.

Where the pressure came from

Alternatives appear where an incumbent strains. In DDS deployments, the strain tends to show up in the same few places.

Discovery at scale. DDS participants find each other automatically, which is superb until the participant count climbs. Discovery traffic grows with the number of participants, and on large systems that background chatter becomes something you have to design around rather than something you can ignore.

Networks that were never the target. DDS discovery leans on multicast, which is exactly right on a controlled wired segment and awkward almost everywhere else. Wi-Fi, cellular links, containerised environments and enterprise networks with multicast disabled all turn a solved problem back into a configuration exercise.

Crossing network boundaries. Getting DDS traffic between subnets, across a site, or out to a cloud endpoint is achievable, but it usually means discovery servers, routing services or bridges. That is additional infrastructure to specify, deploy and support.

Zenoh was designed with those cases in the foreground, offering publish and subscribe alongside a distributed query model, with routing that suits sparse and unreliable links. That is the trade being offered.

Meanwhile, the DDS family kept growing

The attention on middleware alternatives has obscured a quieter and arguably more consequential trend. DDS is no longer one specification. It is a family, and two members deserve attention from anyone building industrial or embedded products.

DDS-XRCE, for extremely resource constrained environments, extends the databus down to devices that could never host a full DDS stack. A lightweight client on the constrained device talks to an Agent, which acts as its gateway into the DDS domain. This is the mechanism behind micro-ROS, and it matters because it removes the historic assumption that participating in a DDS system requires a Linux class processor. Your microcontroller can be a first class participant.

The OPC UA/DDS Gateway is the one we find industrial clients have most often not heard of. Standardised by the OMG, it defines a vendor independent gateway between DDS systems and OPC UA systems, in both directions. An OPC UA to DDS bridge lets DDS applications work with the address space of OPC UA servers. A DDS to OPC UA bridge lets OPC UA clients participate in the DDS global data space.

The practical consequence is worth dwelling on. Plant floors standardised on OPC UA and its industrial information models. Robotics and real-time systems standardised on DDS and its QoS and performance characteristics. Those two worlds have historically met through custom integration code written once, understood by one engineer, and maintained badly. There is now a standard way to join them.

Rounding out the family are DDS-RTPS, the wire protocol that makes interoperability between different vendors’ implementations possible, DDS-XTYPES for type definition and evolution, DDS-RPC for request and reply patterns, and DDS-Security, which adds authentication, access control and encryption as a pluggable layer rather than something bolted on afterwards.

What we would suggest doing about it

If you are running DDS in production, none of this is a reason to change course. It is a reason to check three things.

Are your QoS policies deliberate? Defaults are a starting point, not a design. Reliability, durability, deadline and liveliness settings should reflect stated requirements for each topic. If nobody can explain why a given topic is configured the way it is, that is the place to look first when behaviour surprises you.

Is DDS-Security actually enabled? The specification exists and the plugins are available. Whether they are switched on and correctly configured in your deployment is a separate question, and in our experience the answer is often no.

How does your data leave the domain? If the answer is a bespoke bridge to OPC UA, an MQTT hop, or a script somebody wrote for a demonstration and never removed, the standardised gateway route is worth evaluating. Custom integration code at a system boundary is the most expensive kind to maintain.

If you are choosing middleware for a new system, evaluate honestly rather than by reputation. The right question is not which protocol is better. It is which set of constraints matches the network you will actually deploy on, the assurance case you will actually have to make, and the team that will actually maintain it in five years.

Sources and further reading:
Object Management Group, OPC UA/DDS Gateway specification (DDS-OPCUA)
DDS Foundation, What is in the DDS standard
ROS 2 documentation, Different ROS 2 middleware vendors
ROS 2 project, rmw_zenoh