====== DDS in industrial systems: the data backbone explained ====== DDS (Data Distribution Service) is an OMG-standard, data-centric publish/subscribe middleware for distributing real-time data between the software components of a distributed system (controllers, HMIs, data loggers, gateways), with no central broker. Instead of sending messages to a server, applications publish and subscribe to typed topics, and the middleware handles discovery, delivery and quality of service. It is the backbone technology behind ROS 2 and behind many naval, energy and large distributed-control systems. AEI Corporation designs and integrates DDS backbones, with the QoS and redundancy engineering that goes with them. ===== What is the DCPS model? ===== DDS applications live in a domain and exchange strongly-typed data over named topics. A topic's type can declare key fields, so one topic carries many keyed instances (one ''MotorStatus'' topic with one instance per motor), and subscribers receive per-instance state, not just a message stream. DataWriters and DataReaders find each other by automatic peer-to-peer discovery: no broker process, and therefore no single point of failure to make redundant. The data-centric part is the distinction worth holding onto. A broker-based system moves messages and leaves meaning to the endpoints; DDS knows the type, the instance and the state, so it can tell a subscriber that a particular motor has stopped publishing. A message queue structurally cannot. ===== Why is QoS the actual engineering surface? ===== Behaviour is governed by QoS policies attached to writers and readers, and matched at discovery time under request/offered rules: a reader whose requirements the writer cannot satisfy simply does not match. Most "DDS is not working" moments are QoS mismatches, and the matching rules are the first thing to learn. The families that matter in practice: * **Reliability** — best-effort or reliable. Reliable is not free: it implies acknowledgement and retransmission, and therefore buffering. * **Durability** — whether a late-joining reader receives data published before it existed, which is what lets a restarted HMI show current state immediately rather than wait for the next update. * **History and resource limits** — how many samples are retained per instance, and the bound on memory. On an embedded node these are a hard design constraint, not a tuning knob. * **Deadline and liveliness** — how a subscriber learns that an expected update did not arrive, or that a publisher has gone: the failure-detection mechanism, which belongs in the design rather than in application-level heartbeats. * **Ownership** — redundant writers for the same instance with automatic failover by strength, the primitive most redundancy patterns are built from. {{ :technology:technology-dds-dcps-model.svg |DDS DCPS model — Publisher, DataWriter, Topic, DataReader, Subscriber with QoS matching}} **Figure 1 — DDS DCPS data flow.** A DataWriter publishes to a typed Topic; a DataReader subscribes. The middleware matches them only when the DataWriter's offered QoS is at least as strong as the DataReader's requested QoS — mismatched pairs are silently not connected. ===== How does discovery work, and does it scale? ===== Discovery is peer-to-peer and two-staged: participants find each other (typically by multicast on well-known ports), then exchange the endpoint information that lets writers and readers match. Nothing has to be configured centrally, which makes small systems trivially easy to bring up. At scale that same mechanism is the first thing to engineer. Discovery traffic grows with the number of participants and endpoints, and on a large or multi-segment system it needs deliberate handling: partitioning into domains, restricting or explicitly configuring peer lists where multicast does not propagate, and (in implementations that offer it) a discovery server to replace full-mesh discovery. A system that comes up in seconds on a bench and takes minutes in the plant is almost always a discovery problem, not a data problem. ===== How is redundancy built with DDS? ===== DDS gives redundancy primitives rather than a redundancy product, which is usually the right trade for control systems that each need something slightly different: * **Redundant publishers** via the ownership QoS: two writers publish the same instance, subscribers consume from the stronger one, and failover happens in the middleware without application logic. * **Redundant network paths**, with the middleware using multiple interfaces so a link failure is a transport event rather than an outage. * **Deadline and liveliness** as the detection layer that makes a failover deterministic in time instead of eventual. * **Durability** so that whatever takes over presents current state to its subscribers rather than an empty address space. The design question is always what "failover is transparent" must mean numerically (within one cycle, within a defined number of missed samples), because that number sets the QoS values. ===== On the wire: RTPS ===== DDS interoperates across vendors via the DDSI-RTPS wire protocol. Practically this means two things: implementations from different vendors can exchange data, and Wireshark dissects RTPS out of the box: discovery traffic, heartbeats and data submessages are all inspectable, which makes capture-based debugging of DDS systems unusually tractable. ===== DDS or OPC UA? ===== The two are complements more often than competitors. DDS is strongest inside a system: high-rate, low-latency, peer-to-peer distribution with fine-grained QoS. [[technology:industry40:opcua:start|OPC UA]] is strongest at the boundary: standardised information models and companion specifications that make data meaningful to third parties, SCADA and MES. A common architecture uses DDS as the internal backbone and OPC UA at the integration edge. OPC UA PubSub overlaps DDS at the transport level but does not replace its QoS depth or keyed-instance model. Choosing between them is an architecture decision, not a features checklist. ===== The ROS 2 connection ===== ROS 2 uses DDS as its default middleware underneath the RMW layer (Fast DDS and Cyclone DDS are the common choices). If you run ROS 2, you already run DDS. DDS-level QoS, discovery configuration and RTPS captures are often where ROS 2 communication problems are actually diagnosed and fixed. ===== Implementations ===== Open source: **Eclipse Cyclone DDS** and **eProsima Fast DDS** (both actively maintained, both ROS 2 RMW options) and **[[technology:industry40:dds:open-dds|OpenDDS]]**; see also [[technology:industry40:dds:eclipse-dds|the Eclipse Cyclone DDS notes]]. Commercial implementations add tooling, support and certification artefacts. Hands-on quick-start guides for Cyclone DDS and Fast DDS are planned for this namespace. They will be written from real lab runs, so they appear as those labs are completed. ===== Where does AEI's work sit? ===== Our focus areas are QoS design for deterministic behaviour, redundancy and failover architecture, RTPS-level capture diagnostics, and DDS↔OPC UA edge integration. A delivered example: a marine distributed control system built on a dual-redundant Ethernet network, time-synchronised with PTP (IEEE 1588) so failover is transparent to the process, with a DDS backbone holding a 10 ms distribution cycle between controllers, gateways and engine-room HMIs, OPC UA northbound to the HMI layer, and 2 ms EtherCAT (alongside Modbus TCP and CANopen) southbound to machinery and drives. ===== References ===== * OMG DDS — the Data Distribution Service specification family (DCPS model and QoS policies) * OMG DDSI-RTPS — the interoperability wire protocol * IEC 62541 — OPC Unified Architecture, for the boundary-layer comparison above * IEEE 1588 (PTP) — precision time synchronisation, as used in the redundant network above * IEC 61158 Type 12 — EtherCAT, the deterministic southbound layer in that system ===== Related ===== * [[technology:industry40:dds:use-cases:start|DDS use cases]] * [[technology:industry40:start|Industry 4.0 — OT/IT convergence]] * [[technology:industry40:opcua:start|OPC UA]] * [[technology:industrial-ethernet:ethercat:start|EtherCAT]] * [[https://aeicor.com/services/opc-ua-dds/|AEI Corporation — OPC UA and DDS engineering]] * [[https://aeicor.com/industries/marine/|AEI Corporation — marine automation]]