Inferensys

Glossary

Data Distribution Service (DDS)

Data Distribution Service (DDS) is an Object Management Group (OMG) standard for data-centric, real-time publish-subscribe middleware enabling scalable, high-performance communication in distributed systems.
Knowledge manager reviewing enterprise knowledge management system on laptop, document library visible, casual office.
INTER-AGENT COMMUNICATION PROTOCOLS

What is Data Distribution Service (DDS)?

A definition of the Data Distribution Service (DDS) standard for real-time, data-centric communication in distributed systems.

The Data Distribution Service (DDS) is an open, vendor-neutral middleware standard defined by the Object Management Group (OMG) for scalable, real-time, dependable, high-performance data exchange between software components using a data-centric publish-subscribe (DCPS) model. Unlike message-centric systems, DDS manages a global data space where applications directly read and write data objects, with the middleware handling discovery, delivery, and lifecycle. It is defined by the formal specification DDSI-RTPS (Real-Time Publish-Subscribe Wire Protocol), ensuring interoperability.

DDS provides fine-grained Quality of Service (QoS) policies—such as deadlines, latency budgets, and reliability—that publishers and subscribers can negotiate to control data flow deterministically. This makes it a foundational protocol for Industrial Internet of Things (IIoT), autonomous systems, and Heterogeneous Fleet Orchestration, where low-latency, reliable communication between agents like robots and vehicles is critical. Its decentralized architecture eliminates single points of failure, supporting complex, mission-critical deployments.

ARCHITECTURAL PRINCIPLES

Key Features of DDS

The Data Distribution Service (DDS) is defined by a set of core architectural principles that enable scalable, real-time, and dependable data exchange for mission-critical systems like heterogeneous fleet orchestration.

01

Data-Centric Publish-Subscribe

DDS implements a data-centric architecture, where applications interact directly with a Global Data Space. Publishers write data objects (topics) into this space, and subscribers read them, without direct knowledge of each other. This decoupling is fundamental for dynamic systems like multi-agent fleets, where robots and vehicles can join or leave the network without disrupting communication.

  • Key Benefit: Enables true anonymous communication, where data producers and consumers are discovered dynamically.
  • Contrast: Unlike traditional message-centric middleware (e.g., MQTT brokers), DDS focuses on the state and value of data objects, not just the transmission of messages.
02

Rich Quality of Service (QoS) Policies

DDS provides over 20 configurable Quality of Service (QoS) policies that allow developers to precisely control data delivery semantics, resource usage, and timeliness. These are negotiated between publishers and subscribers to establish a contract.

  • Delivery Guarantees: Policies like RELIABILITY (best-effort vs. reliable), DURABILITY (transient vs. persistent), and HISTORY (keep last N samples) define data survivability.
  • Timeliness & Resources: DEADLINE (maximum period between data updates), LATENCY_BUDGET (acceptable delivery delay), and RESOURCE_LIMITS prevent system overload.
  • Use Case: For fleet coordination, a high-priority collision warning topic would use RELIABILITY.reliable and DEADLINE with a short period, while routine telemetry might use RELIABILITY.best_effort.
03

Dynamic Discovery (DCPS)

The Data-Centric Publish-Subscribe (DCPS) layer handles automatic, decentralized discovery of participants, topics, and endpoints. There is no central broker; discovery uses multicast or unicast protocols.

  • Process: When a new autonomous mobile robot (publisher) comes online, it announces its data topics. Orchestrators (subscribers) interested in those topics discover it and begin receiving data.
  • Advantage: Enables plug-and-play scalability essential for fleets where agents are constantly deployed, retrieved, or fail.
  • Standard: Defined by the Real-Time Publish-Subscribe (RTPS) wire protocol, which ensures interoperability between different DDS implementations.
04

Type Safety & Content Filtering

DDS enforces strong type safety using Interface Definition Language (IDL) to define data structures. Subscribers can also filter data based on content, reducing network and processing load.

  • IDL Definition: Data types (e.g., RobotPose, TaskUpdate) are defined in IDL, generating type-safe code for various languages.
  • Content-Based Filtering: Subscribers can use SQL-like queries to receive only data matching specific criteria (e.g., WHERE robot_id = 'AMR_05' AND battery_level < 0.2).
  • Efficiency: In a large warehouse, a path planner only subscribes to pose updates from robots in its specific zone, ignoring irrelevant data.
05

Real-Time Performance

DDS is designed from the ground up for deterministic, low-latency communication, making it suitable for hard and soft real-time systems. It minimizes overhead through zero-copy operations and efficient wire protocols.

  • Determinism: Predictable timing behavior is achieved through thread models, priority-aware scheduling, and avoiding blocking calls.
  • Transport: Can utilize shared memory for intra-process communication and efficient UDP-based protocols for network communication.
  • Application: Critical for collision avoidance systems and real-time replanning engines where sub-second latency is mandatory for safe operation.
06

Scalability & Fault Tolerance

The decentralized architecture and configurable QoS policies allow DDS systems to scale from a few devices to vast, geographically distributed networks while maintaining robustness.

  • Decentralization: No single point of failure. The loss of one agent or even a central orchestrator node does not collapse the data bus.
  • Redundancy: The OWNERSHIP QoS policy allows for active-active replication, where multiple publishers can provide the same data topic, and DDS automatically manages failover.
  • Large-Scale Deployments: Used in systems like air traffic control, autonomous vehicles, and industrial IoT, connecting thousands of nodes.
ARCHITECTURAL OVERVIEW

How DDS Works: The Data-Centric Model

The Data Distribution Service (DDS) is a middleware standard defined by the Object Management Group (OMG) that implements a **data-centric publish-subscribe** communication model, fundamentally differing from message-centric or channel-centric approaches.

In the data-centric model, the system's global data space is the primary abstraction. Applications define DataWriters and DataReaders that interact with Topics, which represent strongly typed data objects with a unique key. The DDS middleware, not the application, is responsible for discovering endpoints, matching data types, and managing the lifecycle and distribution of data instances. This model provides a virtual global data space where data producers and consumers are decoupled in time, space, and flow.

DDS enforces data consistency and quality through configurable Quality of Service policies that govern reliability, durability, latency, and resource usage. Its Real-Time Publish-Subscribe protocol enables deterministic, low-latency data exchange critical for autonomous systems. This architecture is inherently scalable and fault-tolerant, as the middleware handles discovery, connection management, and data delivery without a central broker, making it ideal for heterogeneous fleet orchestration where agents must share a consistent, real-time view of their operational state.

FEATURE COMPARISON

DDS vs. Other Communication Protocols

A technical comparison of Data Distribution Service (DDS) against other common protocols used in heterogeneous fleet orchestration and inter-agent communication.

Feature / MetricData Distribution Service (DDS)Message Queuing Telemetry Transport (MQTT)Advanced Message Queuing Protocol (AMQP)gRPC

Core Communication Model

Data-Centric Publish-Subscribe

Topic-Based Publish-Subscribe

Message-Centric with Queues

Client-Server RPC (Streaming)

Primary Design Goal

Scalable, real-time data distribution

Lightweight M2M for constrained networks

Reliable enterprise messaging

High-performance service-to-service calls

Discovery Mechanism

Dynamic, decentralized discovery (built-in)

Requires a broker for discovery

Requires a broker for discovery

Requires external service discovery (e.g., DNS)

Quality of Service (QoS) Granularity

Rich, configurable per-data-topic QoS policies

Three predefined levels (0,1,2)

Configurable at the message/channel level

Limited; relies on HTTP/2 and application logic

Data Modeling

Strongly-typed data models via IDL

Unstructured payload (typically JSON)

Typed, but broker-agnostic payload

Strongly-typed via Protocol Buffers

Built-in State Awareness

Yes (DataReader/DataWriter cache)

Latency (Typical)

< 1 ms (LAN, optimized)

5-50 ms (broker-mediated)

10-100 ms (broker-mediated)

< 1 ms (direct connection)

Throughput Scalability

High (peer-to-peer, multicast capable)

Medium (broker as bottleneck)

Medium-High (broker-mediated)

High (HTTP/2 multiplexing)

Fault Tolerance Model

Decentralized redundancy

Centralized (broker as SPOF)

Centralized (broker cluster)

Client-side load balancing & retries

DATA DISTRIBUTION SERVICE

Common Use Cases for DDS

The Data Distribution Service (DDS) is a middleware standard designed for demanding, data-centric applications. Its core strengths—real-time performance, deterministic latency, and scalable discovery—make it the protocol of choice for systems where data is the central asset and reliability is non-negotiable.

DATA DISTRIBUTION SERVICE

Frequently Asked Questions

Essential questions about the Data Distribution Service (DDS), a critical middleware standard for real-time, data-centric communication in heterogeneous fleets and distributed systems.

The Data Distribution Service (DDS) is a middleware protocol and API standard defined by the Object Management Group (OMG) for scalable, real-time, dependable, high-performance, data-centric publish-subscribe communication. It works by establishing a Global Data Space (GDS) where applications, acting as DataWriters (publishers) and DataReaders (subscribers), exchange data objects defined by a Topic and a Type. DDS handles discovery, connection management, and data delivery according to configurable Quality of Service (QoS) policies, abstracting the underlying network complexity. Unlike message-centric brokers, DDS is data-centric; it manages the lifecycle and distribution of data values, not just transient messages, enabling direct peer-to-peer communication for ultra-low latency.

Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.