STATERA Library · Series 07 · Volume 09 · Chapter 01 · EN
Source: https://github.com/Statera-Library/07_Vol_09_Robotics_Communication/blob/main/09_01_DDS/09_01_DDS_EN.md

Volume 09 Robotics Communication

Chapter 1. DDS

1.1 OMG DDS Standard Overview

The Object Management Group (OMG) Data Distribution Service (DDS) Standard represents one of the most important communication technologies for modern distributed real-time systems. DDS was developed to address the growing need for scalable, reliable, deterministic, and data-centric communication in complex cyber-physical systems. Unlike traditional client-server communication models, DDS was designed from the beginning to support decentralized architectures where large numbers of distributed computing nodes exchange information in real time without relying on centralized brokers or message servers. As a result, DDS has become a foundational communication technology in robotics, autonomous vehicles, aerospace systems, defense platforms, industrial automation, smart manufacturing, railway control systems, medical devices, and emerging Physical AI infrastructures. Within modern robotics, DDS serves as the underlying communication backbone of ROS2 (Robot Operating System 2), making it one of the most widely deployed middleware technologies in advanced robotic systems.

The development of DDS emerged from the limitations of earlier communication architectures. Traditional communication systems often relied on tightly coupled client-server models where one device explicitly requested information from another device. While this approach was suitable for many business applications, it introduced significant challenges in real-time distributed systems. Large-scale autonomous systems frequently contain hundreds or thousands of communication participants generating continuous streams of sensor data, control commands, status messages, diagnostic information, telemetry data, and artificial intelligence outputs. Maintaining direct communication links between all participants quickly becomes impractical as system complexity increases. DDS was created to solve this problem by introducing a data-centric publish-subscribe communication paradigm.

The fundamental philosophy of DDS is that data should be the primary focus of communication rather than individual network connections. In DDS architectures, applications do not communicate directly with each other. Instead, they communicate through shared information spaces known as Global Data Spaces. Publishers generate data and make it available to the network, while subscribers express interest in specific categories of information. DDS automatically manages discovery, matching, transport, reliability, and delivery. This abstraction dramatically simplifies application development while improving scalability.

At the core of DDS is the publish-subscribe communication model. A Publisher creates data associated with a specific Topic. A Subscriber expresses interest in that Topic and automatically receives relevant information whenever it becomes available. Neither the publisher nor the subscriber needs explicit knowledge of the other. This decoupling significantly reduces system dependencies and enables flexible system architectures. New devices can join the network dynamically without requiring modifications to existing applications.

Topics represent one of the most important concepts within DDS. A Topic defines a specific category of information that can be exchanged throughout the system. Examples in robotics include robot position, battery status, motor commands, camera images, LiDAR point clouds, navigation goals, obstacle information, diagnostic reports, and AI inference results. Each Topic has an associated data type that specifies the structure of information being exchanged. The DDS middleware ensures that publishers and subscribers using compatible Topic definitions can communicate seamlessly.

The DDS architecture is organized into several layers. The application layer contains user software such as robot control systems, autonomous navigation modules, perception algorithms, fleet management services, and monitoring tools. Beneath the application layer resides the DDS middleware layer responsible for communication management. Below DDS are transport services utilizing Ethernet, Wi-Fi, TCP/IP, UDP/IP, shared memory, real-time networks, or specialized communication infrastructures. This layered architecture allows DDS applications to remain independent of underlying communication technologies.

One of the defining characteristics of DDS is its data-centric nature. Unlike message-centric systems that focus primarily on transmitting messages between endpoints, DDS focuses on maintaining a consistent and shared view of data across the entire distributed system. The middleware understands the structure, ownership, lifecycle, and quality requirements of data objects. This awareness enables advanced communication optimizations that are difficult to achieve in traditional messaging systems.

Automatic discovery is another key feature of DDS. In conventional distributed systems, administrators often need to manually configure communication endpoints, addresses, and routing information. DDS eliminates much of this complexity through automatic participant discovery. When a new device joins the network, it announces its presence and discovers other participants automatically. Publishers and subscribers identify compatible communication partners without requiring manual configuration. This capability significantly simplifies deployment and maintenance in large-scale systems.

Real-time performance is one of the primary reasons DDS has achieved widespread adoption in robotics and autonomous systems. Many robotic applications require deterministic communication behavior with predictable latency and timing characteristics. Motion control systems, obstacle avoidance algorithms, sensor fusion pipelines, autonomous navigation systems, and safety controllers all depend on timely information delivery. DDS provides extensive mechanisms for controlling latency, bandwidth utilization, delivery reliability, message prioritization, and resource allocation to satisfy real-time requirements.

Quality of Service (QoS) policies are among the most powerful features of DDS. QoS policies allow developers to define communication behavior according to application requirements. Different data streams often have different priorities and performance expectations. For example, emergency stop commands require extremely low latency and high reliability, while diagnostic information may tolerate delays or occasional message loss. DDS QoS policies allow each communication channel to be configured independently.

Reliability QoS determines whether data delivery should be guaranteed or best-effort. Reliable communication ensures that messages are retransmitted if delivery failures occur. Best-effort communication prioritizes speed and efficiency while accepting occasional packet loss. Robotics systems frequently employ both approaches simultaneously depending on operational requirements.

Durability QoS controls data persistence. Certain information should only be delivered to currently active subscribers, while other information may need to remain available for future subscribers joining the network. DDS allows developers to define how long information remains accessible after publication. This capability is particularly useful for configuration data, operational status information, and initialization parameters.

History QoS specifies how much previously published information should be retained. Applications may require only the most recent data sample or multiple historical samples. Sensor systems often use short histories to minimize memory consumption, while diagnostic and analytics applications may retain larger histories for analysis purposes.

Deadline QoS defines expected update frequencies. Subscribers can detect communication failures when publishers fail to provide information within predefined time intervals. This capability supports fault detection, health monitoring, and safety supervision functions within autonomous systems.

Latency Budget QoS allows applications to communicate acceptable delivery delays. The middleware can use this information to optimize network resource allocation while satisfying application timing requirements. Similar mechanisms exist for bandwidth management, message ordering, resource limits, and transport prioritization.

DDS employs a peer-to-peer architecture that eliminates the need for centralized message brokers. Many messaging systems rely on broker servers that receive and redistribute all communication traffic. While this approach simplifies certain aspects of system management, it can introduce bottlenecks, single points of failure, and scalability limitations. DDS participants communicate directly whenever possible, improving performance and increasing fault tolerance.

Scalability is one of DDS\'s most important advantages. Small systems may contain only a few communication participants, while large autonomous ecosystems may involve thousands of devices distributed across multiple networks. DDS was designed to support this entire spectrum. Automatic discovery, decentralized communication, efficient multicast utilization, and advanced QoS mechanisms enable DDS to scale effectively without fundamental architectural changes.

Security has become increasingly important as robotic systems connect to cloud platforms, enterprise networks, industrial infrastructure, and public communication channels. DDS Security extends the core DDS specification with comprehensive cybersecurity capabilities. Security features include authentication, authorization, encryption, access control, message integrity verification, secure discovery, and audit logging. These mechanisms help protect distributed systems against unauthorized access and malicious attacks.

DDS Security employs certificate-based authentication to verify participant identities. Access control policies determine which participants may publish or subscribe to specific Topics. Encryption protects sensitive information during transmission. Integrity verification ensures that messages cannot be modified without detection. Together, these features create a robust security framework suitable for safety-critical and mission-critical environments.

ROS2 represents one of the most visible implementations of DDS technology. Unlike ROS1, which relied on custom communication mechanisms, ROS2 adopted DDS as its middleware foundation. This decision provided ROS2 with enterprise-grade communication capabilities including automatic discovery, QoS management, real-time performance, security support, and scalability. As a result, DDS has become deeply integrated into modern robotics development.

Multiple DDS implementations exist within the industry. Examples include Fast DDS, Cyclone DDS, RTI Connext DDS, OpenDDS, CoreDX DDS, and Twin Oaks DDS. While all implementations conform to OMG DDS standards, they may differ in performance characteristics, supported features, licensing models, resource utilization, and optimization strategies. This interoperability allows organizations to select implementations that best satisfy their requirements while maintaining compatibility with standardized DDS interfaces.

DDS plays a critical role in autonomous robotics systems. Sensor data from cameras, LiDARs, radars, IMUs, GNSS receivers, motor controllers, and environmental sensors must be distributed efficiently throughout the robotic architecture. Perception systems generate object detections, semantic maps, and obstacle information. Planning systems generate trajectories and navigation goals. Control systems issue actuator commands. Fleet management systems coordinate multiple robots simultaneously. DDS provides the communication infrastructure connecting these functional modules.

Industrial automation environments similarly benefit from DDS technology. Modern factories increasingly employ distributed intelligence, collaborative robots, digital twins, predictive maintenance systems, edge computing platforms, and Industrial Internet of Things architectures. DDS enables real-time information exchange across these heterogeneous systems while supporting deterministic performance requirements.

Aerospace and defense applications were among the earliest adopters of DDS. Mission-critical systems require extremely reliable communication under challenging operational conditions. DDS supports radar systems, command-and-control platforms, unmanned systems, aircraft avionics, naval combat systems, satellite operations, and distributed sensor networks. The standard\'s emphasis on real-time performance and reliability aligns closely with the requirements of these domains.

The emergence of Physical AI further increases the importance of DDS. Future intelligent systems will combine robotics, artificial intelligence, cloud computing, edge computing, autonomous decision-making, and distributed sensing into highly interconnected ecosystems. These systems require communication infrastructures capable of transporting perception data, AI inference results, language model outputs, action plans, control commands, world models, and multimodal sensor information. DDS provides a strong foundation for supporting these complex communication requirements.

Future developments are expected to expand DDS capabilities even further. Integration with Time Sensitive Networking (TSN), 5G communication systems, edge computing architectures, cloud-native infrastructures, AI-native middleware frameworks, and next-generation autonomous systems will continue enhancing DDS relevance. Advanced resource management, adaptive QoS optimization, intelligent routing, and AI-assisted communication management may become increasingly important areas of innovation.

Ultimately, the OMG DDS Standard represents far more than a communication protocol. It is a comprehensive data distribution framework specifically designed for large-scale distributed real-time systems. By combining publish-subscribe communication, data-centric architecture, automatic discovery, QoS management, decentralized operation, cybersecurity support, and scalability, DDS provides the communication foundation required by modern robotics, autonomous systems, industrial automation platforms, and future Physical AI ecosystems. For ROS2-based robotics and next-generation intelligent machines, DDS has become one of the most important enabling technologies supporting reliable, scalable, and real-time system integration.

1.2 QoS Policy Design

Quality of Service (QoS) Policy Design is one of the most important concepts in the Data Distribution Service (DDS) ecosystem and serves as the foundation for achieving deterministic, reliable, scalable, and real-time communication in modern robotics systems. While traditional communication frameworks often treat network behavior as a fixed characteristic of the underlying infrastructure, DDS introduces a policy-driven communication architecture in which application developers can explicitly define how data should be delivered, stored, prioritized, filtered, and synchronized. This capability enables DDS to support a wide range of robotic applications, from low-bandwidth telemetry systems to mission-critical autonomous platforms operating in dynamic and unpredictable environments. QoS policies transform communication from a best-effort mechanism into a configurable engineering discipline, allowing system architects to design communication behavior that aligns with operational requirements and safety objectives. The topic is positioned within DDS communication architecture as a key element of 01_02_QoS_Policy_Design under the DDS section of Robotics Communication.

In robotics systems, communication requirements vary significantly between different types of data. A battery status message may tolerate occasional packet loss, while an emergency stop command requires guaranteed delivery within strict timing constraints. High-resolution camera streams generate large volumes of data and prioritize throughput, whereas localization and navigation messages require consistency and low latency. DDS addresses these diverse requirements through a comprehensive collection of QoS policies that can be individually configured for each Topic, Publisher, Subscriber, DataWriter, and DataReader. Rather than relying on a one-size-fits-all communication model, DDS allows every communication channel to be optimized according to its specific purpose.

The DDS QoS framework is based on the principle that communication behavior should be explicitly defined rather than implicitly assumed. Every participant in the DDS domain can advertise its communication requirements through QoS profiles. During the discovery process, DDS automatically evaluates whether communication endpoints are compatible. This mechanism is commonly known as Request versus Offered matching. A Subscriber requests a certain level of service, while a Publisher offers a certain level of service. Communication is established only when compatibility rules are satisfied. This approach prevents communication failures caused by mismatched assumptions and ensures predictable system behavior.

Reliability is one of the most frequently used QoS policies in DDS. The Reliability QoS determines whether messages must be delivered reliably or whether occasional packet loss is acceptable. Best Effort reliability prioritizes speed and low overhead by allowing data loss under network congestion. This mode is suitable for high-frequency sensor streams such as LiDAR point clouds, depth cameras, and telemetry messages where the latest data is more valuable than historical data. Reliable reliability guarantees delivery through acknowledgment and retransmission mechanisms. This mode is appropriate for command messages, mission instructions, safety notifications, and critical state updates where missing information could compromise system functionality. The choice between Best Effort and Reliable communication directly affects bandwidth utilization, latency, and system robustness.

Durability is another fundamental QoS policy that defines how historical data is managed. In a Volatile durability configuration, data exists only while active subscribers are connected. New subscribers receive only future messages. This behavior is suitable for real-time streaming applications where historical information has limited value. Transient Local durability enables publishers to retain recent data and provide it to late-joining subscribers. This capability is particularly valuable in robotic systems where components may restart during operation. For example, when a visualization tool reconnects to a running robot, it can immediately obtain the latest map, localization state, or system configuration without waiting for a new publication cycle.

History QoS determines how many data samples are stored by the middleware. The Keep Last policy retains a specified number of recent samples, while the Keep All policy stores every sample until resource limits are reached. Keep Last is commonly used in robotics because it provides predictable memory consumption. For example, a localization topic may retain the most recent ten messages, allowing subscribers to recover from temporary communication interruptions. Keep All is more appropriate for applications requiring complete event histories, such as diagnostics, auditing, or data recording systems.

Depth QoS works in conjunction with History QoS to specify the number of samples retained. When Keep Last is selected, Depth defines the buffer size. A depth of one ensures that subscribers always receive the latest information. Larger depths provide resilience against temporary processing delays and network jitter. However, increasing depth also increases memory consumption and potentially introduces latency. System architects must balance these factors according to application requirements.

Deadline QoS specifies the expected maximum interval between data updates. Publishers declare how frequently data should be transmitted, while subscribers monitor compliance with this expectation. If a deadline is missed, DDS generates a notification indicating a potential communication or application failure. Deadline monitoring is particularly useful in safety-critical robotic systems where timely updates are essential. For example, a navigation controller may expect localization updates every 50 milliseconds. Missing this deadline could indicate sensor failure, communication disruption, or software malfunction, triggering fault-handling procedures.

Latency Budget QoS allows applications to communicate acceptable delivery latency requirements to the DDS middleware. This policy helps optimize resource allocation and transmission scheduling. Low-latency applications such as motion control and collision avoidance require minimal communication delay, while monitoring and logging systems may tolerate larger delays. Although DDS implementations are not obligated to guarantee latency budgets, the policy provides valuable information that middleware can use to optimize communication behavior.

Liveliness QoS enables participants to verify that communication partners remain operational. In distributed robotic systems, detecting node failures rapidly is essential for maintaining safe operation. DDS supports Automatic, Manual by Participant, and Manual by Topic liveliness modes. Automatic liveliness relies on DDS-generated heartbeats, while manual modes allow applications to explicitly assert their operational status. If a liveliness lease expires, DDS informs subscribers that the publisher is no longer active. This capability supports fault detection, redundancy management, and failover mechanisms in autonomous systems.

Lifespan QoS determines how long a data sample remains valid after publication. Once the specified lifespan expires, DDS automatically discards the sample. This policy prevents outdated information from influencing decision-making processes. In robotics, sensor measurements often become obsolete within milliseconds. For example, obstacle detection data generated several seconds ago may no longer represent the current environment. Lifespan enforcement ensures that consumers operate on fresh and relevant information.

Ownership QoS controls how DDS handles multiple publishers writing to the same topic. Shared ownership allows data from multiple publishers to coexist, while Exclusive ownership designates a single publisher as authoritative based on ownership strength. This mechanism is valuable in redundant control systems where primary and backup controllers operate simultaneously. If the primary controller fails, DDS can automatically transition authority to the backup controller without requiring extensive application-level logic.

Ownership Strength complements Exclusive Ownership by defining priority levels among competing publishers. Higher-strength publishers take precedence over lower-strength publishers. This feature enables seamless failover architectures in autonomous vehicles, industrial robots, and mission-critical control systems. By embedding ownership management into the middleware layer, DDS simplifies redundancy implementation and improves system reliability.

Destination Order QoS specifies how subscribers should interpret message ordering. Messages may be ordered according to source timestamps or reception timestamps. Source-based ordering is particularly important in distributed robotic systems where network delays vary between communication paths. Consistent temporal ordering supports sensor fusion, event correlation, and synchronized decision-making processes.

Transport Priority QoS provides a mechanism for assigning relative importance to different data streams. High-priority traffic such as emergency stop commands, safety alerts, and motion control instructions can receive preferential treatment compared to lower-priority traffic such as logging or diagnostics. Although implementation support varies among DDS vendors and operating systems, transport prioritization remains an important design consideration for real-time robotic networks.

Resource Limits QoS defines memory allocation boundaries for DDS entities. These limits constrain the number of samples, instances, and cached data maintained by the middleware. Proper resource configuration prevents memory exhaustion and ensures predictable behavior under heavy communication loads. Resource planning is especially important in embedded robotics platforms where computational resources are constrained.

Presentation QoS governs how related data samples are grouped and presented to subscribers. Coherent access and ordered access options help maintain consistency across multiple topics. For example, a robot may publish position, velocity, and acceleration information as a coherent set. Presentation QoS ensures that subscribers receive these values in a synchronized and logically consistent manner.

Time-Based Filter QoS allows subscribers to specify the minimum interval between received samples. This capability reduces unnecessary processing and network utilization by filtering excessive update rates. A monitoring dashboard may only require updates every second, even if the source publishes data at 100 Hz. Time-Based Filter policies enable efficient resource utilization without modifying publisher behavior.

Partition QoS provides logical segmentation of communication domains. Multiple robot fleets operating within the same DDS domain can be isolated through partition assignments. Maintenance systems, simulation environments, testing platforms, and production robots may coexist while maintaining communication separation. Partitioning enhances scalability, security, and organizational flexibility.

QoS interoperability represents a major challenge in large-scale robotic deployments. Different DDS vendors may interpret certain policies differently or support varying feature sets. Engineers must carefully validate QoS configurations during integration testing. ROS 2 further abstracts DDS through the RMW layer, but underlying QoS compatibility remains critical for reliable operation. Understanding the interaction between ROS 2 QoS profiles and DDS QoS policies is essential for designing robust robotic applications.

In autonomous mobile robots, QoS policy design directly influences navigation reliability, perception accuracy, fleet coordination, and safety performance. LiDAR data often uses Best Effort reliability with shallow history depth to minimize latency. Localization information may use Reliable delivery and moderate history depth to ensure consistency. Safety-related commands typically employ Reliable reliability, strict deadlines, transient durability, and high transport priority. Fleet management systems frequently combine DDS QoS with cloud communication technologies such as MQTT, REST APIs, and gRPC to balance local autonomy with centralized coordination.

Future robotic systems driven by Physical AI, foundation models, multimodal perception, and distributed intelligence will place even greater demands on communication infrastructure. QoS policies will evolve beyond traditional message transport to support AI inference synchronization, action-token streaming, distributed world models, collaborative reasoning, and real-time coordination among heterogeneous robotic agents. As robotic ecosystems become increasingly complex, QoS policy engineering will remain a foundational discipline that bridges application requirements, middleware capabilities, network behavior, and system-level reliability. Effective QoS design is not merely a communication configuration task but a core architectural practice that determines the scalability, determinism, safety, and operational success of next-generation autonomous robotic platforms. Based on the Hills Robotics communication architecture, DDS and QoS policy engineering form a central component of the Robotics Communication domain and provide the communication foundation for Indoor AMR, Outdoor AMR, Mobile Manipulators, Physical AI systems, Cargo UAVs, Quadruped Robots, and Humanoid Robots operating within distributed autonomous environments.

01_02_QoS_Policy_Design

1.3 Topic Publisher Subscriber

The Topic--Publisher--Subscriber model is the foundational communication paradigm of the Data Distribution Service (DDS) standard and serves as the core mechanism enabling scalable, decoupled, real-time data exchange in modern robotics, autonomous systems, distributed control platforms, and Physical AI architectures. Unlike traditional client-server communication models, where communication endpoints must know each other\'s identities and locations, DDS adopts a data-centric publish-subscribe architecture that separates data producers from data consumers. This decoupling significantly improves modularity, scalability, fault tolerance, maintainability, and system flexibility, making DDS particularly suitable for large-scale robotic systems such as Autonomous Mobile Robots (AMRs), Outdoor Autonomous Vehicles, Mobile Manipulators, Quadruped Robots, Humanoid Robots, Cargo UAVs, and future AI-native robotic ecosystems.

At the heart of DDS communication is the concept of a Topic. A Topic represents a logical communication channel through which information is exchanged. Rather than defining who is communicating, a Topic defines what information is being communicated. Topics provide a semantic description of data within the system and act as the common interface between publishers and subscribers. Every Topic is associated with a specific data type, which defines the structure, fields, and meaning of the information being transmitted. This data-centric approach allows communication participants to interact through shared data definitions without requiring direct knowledge of each other.

In a robotic system, Topics often correspond to meaningful information flows. A LiDAR sensor may publish point cloud data on a Topic named "/lidar/points." A localization module may publish robot pose information on "/robot/pose." A navigation planner may publish trajectory commands on "/planner/path," while a motor controller subscribes to velocity commands from "/cmd_vel." Because Topics represent logical data channels rather than physical communication paths, the underlying system remains flexible and highly extensible.

The Publisher is the DDS entity responsible for producing and transmitting information into a Topic. A Publisher creates one or more DataWriters, each associated with a particular Topic. The DataWriter is responsible for actually writing data samples into the DDS middleware. Publishers define the characteristics of outgoing communication, including update frequency, Quality of Service settings, durability requirements, reliability guarantees, and timing constraints. The Publisher essentially acts as the source of information within the DDS ecosystem.

In robotics applications, Publishers are typically associated with sensors, control systems, perception algorithms, localization modules, planning systems, diagnostics software, or fleet management services. A LiDAR driver continuously publishes point cloud data. An IMU driver publishes inertial measurements. A GNSS module publishes global position information. A battery management system publishes battery state data. A fleet server may publish mission assignments and traffic coordination instructions. Every data-producing component becomes a Publisher in the DDS architecture.

The Subscriber is the DDS entity responsible for consuming information from a Topic. Subscribers create DataReaders that receive and process data associated with Topics of interest. Unlike traditional communication systems where data is explicitly sent to known recipients, DDS Subscribers simply express interest in specific Topics. DDS automatically establishes communication paths between compatible Publishers and Subscribers. This dynamic discovery process removes the need for manual network configuration and greatly simplifies distributed system deployment.

Subscribers can exist in many forms. A navigation controller may subscribe to localization data and obstacle information. A monitoring dashboard may subscribe to system diagnostics and battery status. A perception module may subscribe to camera images and LiDAR point clouds. A fleet management system may subscribe to robot status updates from dozens or hundreds of robots simultaneously. Because DDS supports one-to-many and many-to-many communication patterns, the same Topic can serve numerous Subscribers without requiring additional complexity from Publishers.

One of the most important aspects of the Topic--Publisher--Subscriber model is decoupling. Publishers do not know who their Subscribers are. Subscribers do not know where Publishers are located. Neither side requires knowledge of network addresses, process identifiers, hardware configurations, or deployment details. Communication occurs solely through Topics and data definitions. This loose coupling dramatically improves maintainability and scalability because individual components can be added, removed, upgraded, or replaced without impacting the rest of the system.

For example, consider an AMR operating within a warehouse environment. A LiDAR sensor publishes obstacle information. Initially, only the obstacle avoidance system subscribes to this data. Later, engineers add a visualization tool, a recording system, and an AI perception module. All three can subscribe to the same Topic without requiring any modifications to the LiDAR Publisher. This flexibility significantly reduces integration effort and supports continuous system evolution.

DDS communication is inherently asynchronous. Publishers write data whenever information becomes available, while Subscribers receive data independently according to their processing requirements. Publishers are not blocked by slow Subscribers, and Subscribers do not need to synchronize directly with Publishers. This asynchronous behavior is essential for real-time robotic systems where deterministic execution and predictable timing are critical requirements.

The Topic concept also introduces strong type safety into distributed communication systems. Every Topic is associated with a data type definition, typically specified using Interface Definition Language (IDL). DDS uses this type information during the discovery process to ensure compatibility between Publishers and Subscribers. If two participants attempt to communicate using incompatible data structures, DDS prevents the connection from being established. This mechanism helps eliminate many common integration errors and improves overall system reliability.

DDS discovery is another critical component of the Topic--Publisher--Subscriber architecture. When a DDS participant joins the network, it automatically announces its presence and discovers other participants. Publishers advertise the Topics they provide along with their Quality of Service characteristics. Subscribers advertise the Topics they require and their QoS expectations. DDS middleware automatically matches compatible entities and establishes communication channels without requiring centralized configuration servers or manual endpoint management.

This discovery mechanism enables plug-and-play operation in robotic systems. New sensors can be connected and immediately become available to existing applications. Diagnostic tools can join running systems and begin receiving data without interrupting operations. Simulation environments can seamlessly integrate with physical robots through shared DDS domains. Such flexibility is particularly valuable in research environments, industrial automation systems, and large-scale robotic fleets.

The Topic--Publisher--Subscriber model also supports multiple communication patterns simultaneously. A single Publisher may transmit data to dozens of Subscribers. Multiple Publishers may write data to the same Topic. Numerous Subscribers may consume information from multiple Topics simultaneously. DDS supports highly dynamic communication topologies where nodes can appear, disappear, restart, or migrate during system operation without disrupting overall functionality.

In fleet robotics applications, this scalability becomes particularly important. Hundreds of robots may publish status information, localization data, diagnostics, mission progress, and environmental observations. Fleet management software subscribes to these Topics while simultaneously publishing commands and task assignments. The DDS architecture allows such large-scale communication networks to operate efficiently while maintaining deterministic behavior and low latency.

Topic design itself is an important engineering discipline. Effective Topic structures improve system clarity, maintainability, and performance. Topics should be organized according to semantic meaning rather than hardware implementation details. Common practices include hierarchical naming schemes such as "/robot/pose," "/robot/velocity," "/sensor/lidar/front," "/sensor/camera/left," "/navigation/path," and "/diagnostics/system." Consistent naming conventions improve interoperability and simplify system integration.

QoS policies play a crucial role in Topic--Publisher--Subscriber communication. Every Publisher offers specific QoS settings while Subscribers request particular service levels. DDS automatically verifies compatibility before establishing communication. Reliability, Durability, History, Deadline, Liveliness, Latency Budget, Ownership, and Lifespan policies collectively determine communication behavior. Through QoS engineering, DDS can support applications ranging from low-latency motion control to high-throughput perception pipelines and long-term data logging systems.

The Topic--Publisher--Subscriber architecture is particularly beneficial in ROS 2, which uses DDS as its underlying middleware. ROS 2 Nodes communicate primarily through Topics. Publishers and Subscribers form the primary communication mechanism between software components. Perception nodes publish sensor data, localization nodes publish robot poses, planning nodes publish trajectories, and control nodes subscribe to command streams. DDS provides the transport layer that enables this communication while maintaining real-time performance and scalability.

Security considerations are also integrated into the DDS communication model. DDS Security extensions provide authentication, authorization, encryption, and governance mechanisms that protect Topic-based communication. Publishers and Subscribers can be authenticated before communication is allowed. Topic-level access control policies restrict who may publish or subscribe to specific data streams. Encryption protects data from interception while governance policies enforce security rules throughout the communication infrastructure.

Modern Physical AI systems increasingly rely on the Topic--Publisher--Subscriber paradigm to manage complex data flows between perception, cognition, planning, reasoning, and actuation modules. Large multimodal AI models generate information that must be distributed efficiently across robotic subsystems. Sensor fusion engines consume information from multiple Publishers simultaneously. Planning systems integrate outputs from localization, perception, semantic understanding, and fleet coordination modules. DDS Topics provide a structured communication framework capable of supporting these increasingly sophisticated information flows.

In multi-robot environments, Topic-based communication enables collaborative intelligence. Robots can share maps, localization information, detected objects, task assignments, environmental observations, and operational status. Distributed teams of robots become information-sharing networks where each participant contributes to a common understanding of the environment. DDS facilitates this collaboration through efficient multicast communication, automatic discovery, and scalable data distribution mechanisms.

The emergence of AI-native robotics further increases the importance of the Topic--Publisher--Subscriber architecture. Future robotic systems will exchange not only sensor measurements and control commands but also semantic world models, reasoning results, foundation model outputs, action tokens, task plans, and collaborative intelligence artifacts. DDS Topics provide an abstraction layer capable of supporting these evolving communication requirements while maintaining compatibility with existing robotic software architectures.

In large-scale industrial deployments, Topic--Publisher--Subscriber communication improves maintainability and lifecycle management. New software modules can be introduced without redesigning existing communication pathways. Legacy systems can coexist with newer components through shared Topics. Simulation systems can operate alongside physical hardware using identical communication interfaces. Development teams can work independently on different subsystems while maintaining interoperability through agreed Topic definitions and data contracts.

Ultimately, the Topic--Publisher--Subscriber model represents far more than a simple communication mechanism. It is a fundamental architectural principle that enables modularity, scalability, flexibility, reliability, and long-term maintainability in distributed robotic systems. By separating data producers from data consumers and focusing communication around well-defined Topics, DDS creates a robust foundation for modern robotics, autonomous vehicles, fleet systems, industrial automation platforms, Physical AI architectures, and next-generation intelligent machines. As robotic ecosystems continue to grow in complexity and scale, the Topic--Publisher--Subscriber paradigm will remain one of the most important communication abstractions supporting the future of autonomous and intelligent systems.

01_03_Topic_Publisher_Subscriber

1.4 DDS Security Plugin

DDS Security Plugin is the standardized security framework defined by the Object Management Group (OMG) for securing Data Distribution Service (DDS) communications in distributed systems. As DDS has become the dominant middleware technology for modern robotics, autonomous vehicles, industrial automation, aerospace platforms, defense systems, and Physical AI architectures, the need for robust cybersecurity mechanisms has increased dramatically. Traditional DDS deployments focused primarily on performance, scalability, and deterministic communication. However, as robots and autonomous systems became connected to enterprise networks, cloud infrastructures, public wireless networks, and multi-vendor ecosystems, communication security emerged as a critical engineering requirement. DDS Security was developed to address these challenges by providing authentication, authorization, encryption, access control, and audit capabilities while preserving the real-time characteristics that make DDS suitable for mission-critical applications.

The DDS Security specification extends the standard DDS architecture without modifying the core communication model. Security mechanisms are implemented through pluggable security modules, allowing security functionality to be added without changing application-level software. This design philosophy maintains compatibility with existing DDS applications while enabling organizations to deploy security policies according to operational requirements. Security functionality becomes an integral part of the DDS middleware layer rather than being implemented separately by each application developer. This approach reduces engineering complexity, improves consistency, and enables standardized security management across large distributed systems.

The security architecture is based on several core principles. The first principle is identity verification. Every DDS participant must be able to prove its identity before joining a DDS domain. The second principle is authorization. Even after a participant is authenticated, it should only access information and services that it is explicitly permitted to use. The third principle is confidentiality. Sensitive data must be protected from unauthorized observation. The fourth principle is integrity. Data must be protected from modification during transmission. The fifth principle is accountability. Security events must be traceable to support auditing and forensic analysis. Together, these principles establish a comprehensive cybersecurity framework for distributed robotic systems.

DDS Security defines five major security plugins. These include the Authentication Plugin, Access Control Plugin, Cryptographic Plugin, Logging Plugin, and Data Tagging Plugin. Each plugin performs a specialized security function while interacting with other plugins through standardized interfaces. This modular design enables different vendors to implement their own security solutions while maintaining interoperability across DDS ecosystems.

The Authentication Plugin is responsible for verifying the identity of DDS participants. When a participant attempts to join a DDS domain, it must present credentials proving its identity. DDS Security commonly uses Public Key Infrastructure (PKI) mechanisms based on X.509 certificates. Each participant possesses a digital certificate issued by a trusted Certificate Authority. During the authentication process, participants exchange certificates and perform cryptographic handshakes to establish mutual trust. Only participants with valid credentials are permitted to join the communication environment.

Authentication is particularly important in robotics environments where unauthorized devices could potentially disrupt operations. Consider an autonomous warehouse containing hundreds of AMRs. Without authentication, a malicious device could attempt to impersonate a fleet management server or robot controller. DDS Authentication prevents such attacks by ensuring that only trusted entities can participate in communication. The authentication process occurs automatically during participant discovery and is transparent to application-level software.

Once authentication has been completed, the Access Control Plugin determines what actions a participant may perform. Authentication answers the question of who the participant is, while authorization answers the question of what the participant is allowed to do. DDS Access Control uses governance and permissions documents to define security policies. These policies specify which participants may publish or subscribe to specific Topics, which domains they may access, and what communication operations are permitted.

For example, a robot localization module may be authorized to publish position information but may not be allowed to publish motor control commands. A monitoring dashboard may be authorized to subscribe to diagnostics Topics but not to safety-critical Topics. A fleet management server may have permission to publish mission assignments while ordinary robot nodes may only subscribe to them. This fine-grained access control significantly reduces the attack surface of distributed robotic systems.

Governance documents define security rules at the domain level. They specify which Topics require encryption, which communication paths require authentication, and how security policies should be enforced. Permissions documents define participant-specific privileges. Together, governance and permissions establish the security framework governing DDS communications.

The Cryptographic Plugin provides confidentiality and integrity protection for DDS communications. After authentication and authorization are completed, communication channels can be secured through encryption. DDS Security supports modern cryptographic algorithms including Advanced Encryption Standard (AES) and secure key exchange mechanisms. Encryption ensures that intercepted network traffic cannot be understood by unauthorized observers.

Confidentiality protection is particularly important in industrial and military applications. Autonomous inspection robots operating within critical infrastructure may transmit sensitive operational data. Cargo UAV systems may exchange flight control information. Defense robots may communicate tactical information. Encryption prevents adversaries from gaining access to these communications.

Integrity protection ensures that transmitted data cannot be modified without detection. Cryptographic message authentication codes and digital signatures allow receivers to verify that received information has not been altered during transmission. This capability is essential for safety-critical systems where corrupted data could lead to hazardous behavior. Navigation commands, safety signals, and localization information all require strong integrity guarantees.

DDS Security supports multiple levels of encryption. Entire participant communications may be encrypted. Individual Topics may be encrypted selectively. Certain data fields may receive stronger protection than others. This flexibility allows engineers to balance security requirements against computational overhead. High-performance sensor streams may use different protection strategies than low-bandwidth command channels.

The Logging Plugin provides security auditing capabilities. Security-related events are recorded and stored for later analysis. Authentication attempts, authorization failures, policy violations, certificate expiration events, and cryptographic errors may all be logged. These logs support incident investigation, compliance verification, and cybersecurity monitoring.

Logging is particularly important in regulated industries where traceability requirements exist. Industrial automation systems, aerospace platforms, medical robotics systems, and critical infrastructure robots often require comprehensive security audit trails. Security logs provide evidence of policy enforcement and assist engineers in identifying potential vulnerabilities or operational anomalies.

The Data Tagging Plugin enables security metadata to be associated with DDS data samples. Security labels may indicate classification levels, sensitivity categories, ownership information, or policy requirements. Subscribers can use these labels to enforce additional security decisions. Data tagging becomes increasingly important in multi-organizational environments where information sharing policies vary between participants.

DDS Security is tightly integrated with the DDS discovery process. During participant discovery, security negotiations occur before communication channels are established. Participants exchange credentials, verify trust relationships, negotiate cryptographic parameters, and establish secure communication contexts. Only after successful completion of these procedures does normal DDS communication begin.

One of the most significant advantages of DDS Security is that security policies are enforced at the middleware level. Application developers do not need to implement authentication, encryption, or access control logic within every software component. Instead, security becomes a shared infrastructure capability managed by the DDS framework. This approach reduces implementation errors and promotes consistent security practices throughout the system.

In ROS 2 environments, DDS Security provides the foundation for secure robotic communication. Since ROS 2 relies on DDS middleware, DDS Security mechanisms can be leveraged directly. Secure ROS 2 deployments use DDS Security to authenticate nodes, encrypt communication channels, and control access to Topics, Services, and Actions. This capability is particularly valuable for robots operating in public environments, industrial facilities, smart cities, and cloud-connected infrastructures.

Security becomes increasingly important in fleet robotics systems. Modern fleets may consist of hundreds or thousands of robots communicating through wireless networks. Fleet management platforms exchange operational commands, mission assignments, telemetry data, software updates, and safety information. Without robust security mechanisms, these systems become vulnerable to unauthorized access, spoofing attacks, data theft, denial-of-service attacks, and command injection attacks. DDS Security provides a standardized framework for mitigating these risks.

Autonomous vehicles represent another major application domain. Self-driving platforms depend on distributed communication among perception systems, localization modules, planning engines, control systems, and cloud services. Security failures could have severe safety consequences. DDS Security helps ensure that communication channels remain trustworthy even in hostile network environments.

Industrial automation environments also benefit significantly from DDS Security. Modern factories increasingly connect robots, PLCs, edge computers, AI systems, quality inspection platforms, and cloud services. DDS provides the communication backbone for many of these systems. Security plugins ensure that operational technology networks maintain appropriate protection against cyber threats while supporting real-time performance requirements.

As Physical AI systems evolve, DDS Security will play an increasingly important role. Future AI-native robots will exchange not only sensor data and control commands but also semantic world models, learned behaviors, reasoning outputs, foundation model inferences, collaborative planning information, and distributed intelligence artifacts. These data assets may possess significant economic, operational, or strategic value. Protecting them requires robust authentication, authorization, encryption, and auditing mechanisms.

The integration of cloud computing further expands security requirements. Hybrid architectures combining edge devices, on-premise GPU servers, cloud AI platforms, and fleet management systems create complex trust relationships. DDS Security provides mechanisms for establishing secure communication across these heterogeneous environments while maintaining interoperability and scalability.

Performance considerations remain important when deploying DDS Security. Cryptographic operations introduce computational overhead and may increase communication latency. Engineers must carefully balance security requirements against real-time performance objectives. Hardware security modules, cryptographic accelerators, Trusted Platform Modules (TPM), secure boot technologies, and modern processor security features can help mitigate these impacts. Security architecture should be considered during system design rather than added as an afterthought.

Security testing is an essential component of DDS Security deployment. Authentication failures, certificate management procedures, key rotation mechanisms, authorization policies, encryption performance, vulnerability assessments, penetration testing, and incident response planning must all be validated systematically. Security should be treated as an ongoing lifecycle activity rather than a one-time implementation effort.

Ultimately, DDS Security Plugin technology transforms DDS from a high-performance communication middleware into a comprehensive secure communication platform. By integrating authentication, authorization, encryption, integrity protection, logging, and policy enforcement directly into the middleware layer, DDS Security provides the trust foundation required for modern autonomous systems. As robotic fleets, autonomous vehicles, Physical AI platforms, industrial automation systems, smart infrastructure networks, and collaborative intelligent machines continue to expand in scale and complexity, DDS Security will remain a critical architectural component ensuring that communication remains trustworthy, resilient, and protected against evolving cybersecurity threats. Based on the Hills Robotics communication architecture, DDS Security serves as a foundational technology enabling secure communication across Indoor AMR platforms, Outdoor Autonomous Vehicles, Mobile Manipulators, Fleet Management Systems, Cargo UAV architectures, Quadruped Robots, Humanoid Robots, and future AI-native robotic ecosystems.

01_04_DDS_Security_Plugin

1.5 FastDDS vs CycloneDDS

Fast DDS and Cyclone DDS are the two most widely adopted open-source DDS implementations in modern robotics and autonomous systems. As DDS has become the foundational communication middleware for ROS 2 and many distributed real-time systems, selecting an appropriate DDS implementation has become an important architectural decision. Both Fast DDS and Cyclone DDS implement the OMG DDS standard and provide interoperability through standardized DDS protocols. However, they differ significantly in architecture, performance characteristics, scalability behavior, configuration mechanisms, memory management strategies, debugging capabilities, ecosystem maturity, and optimization priorities. Understanding these differences is essential for engineers designing Autonomous Mobile Robots, Outdoor Autonomous Vehicles, Mobile Manipulators, Fleet Management Systems, Physical AI platforms, Cargo UAVs, Quadruped Robots, and Humanoid Robots.

DDS itself defines communication behavior through standards such as RTPS (Real-Time Publish Subscribe), QoS policies, Topic-based communication, discovery protocols, security extensions, and data serialization rules. DDS vendors implement these standards using different internal architectures. Fast DDS is developed and maintained by the company eProsima, while Cyclone DDS is primarily developed under the stewardship of the Eclipse Foundation as part of the Eclipse ecosystem. Both implementations are actively used within ROS 2 and are considered production-grade middleware platforms.

Fast DDS originated from the need to provide a highly scalable DDS implementation capable of supporting large distributed systems. Its architecture was designed with flexibility and configurability as primary goals. Over time, Fast DDS became the default DDS implementation in several ROS 2 distributions because of its broad feature set, active development, DDS Security support, extensive tooling, and strong enterprise adoption. The middleware supports a wide range of operating systems, hardware platforms, and deployment environments, making it suitable for industrial robotics and large-scale autonomous systems.

Cyclone DDS emerged from a different design philosophy. The developers focused heavily on deterministic behavior, simplicity, efficient discovery mechanisms, low latency, and predictable resource consumption. Rather than maximizing configurability, Cyclone DDS emphasizes robustness, stability, and ease of deployment. As a result, Cyclone DDS gained popularity among robotics developers seeking reliable communication performance with minimal configuration complexity.

One of the most significant differences between Fast DDS and Cyclone DDS lies in discovery behavior. DDS participants must discover each other before communication can begin. Discovery traffic becomes increasingly important as the number of participants grows. Fast DDS uses a highly configurable discovery framework supporting Simple Discovery, Discovery Servers, and advanced discovery topologies. Discovery Servers allow large deployments to reduce multicast traffic and improve scalability. This architecture is particularly useful in enterprise environments, large robot fleets, and cloud-connected robotic systems.

Cyclone DDS traditionally emphasizes efficient peer-to-peer discovery mechanisms. Its discovery implementation is often regarded as lightweight and highly efficient for typical robotics deployments. In many ROS 2 applications involving moderate node counts, Cyclone DDS demonstrates fast startup behavior and rapid participant matching. This simplicity contributes to its reputation for stable operation in development and research environments.

Latency performance is frequently discussed when comparing the two middleware systems. Communication latency represents the time required for a message to travel from a Publisher to a Subscriber. Low latency is particularly important for motion control, sensor fusion, collision avoidance, autonomous navigation, and real-time perception systems.

Historically, Cyclone DDS has often demonstrated slightly lower latency in many ROS 2 benchmark environments. Its internal architecture minimizes communication overhead and reduces unnecessary processing paths. This characteristic can be advantageous in systems requiring extremely responsive communication. However, modern Fast DDS releases have significantly improved latency performance through architectural optimizations, reducing the performance gap considerably.

Throughput represents another critical performance metric. Throughput measures how much data can be transmitted over a communication channel within a given period. High-throughput communication is important for camera streams, LiDAR point clouds, perception systems, mapping applications, and AI data pipelines.

Fast DDS has traditionally performed very well in high-throughput scenarios. The middleware includes numerous optimization mechanisms for handling large data streams efficiently. Advanced memory management, configurable transport layers, shared memory communication, and optimized serialization mechanisms contribute to strong throughput performance. In large-scale robotic systems transmitting substantial sensor data volumes, Fast DDS often demonstrates excellent scalability.

Cyclone DDS also performs well under heavy data loads but tends to prioritize predictable behavior over maximum throughput optimization. For many robotics applications, the throughput difference is negligible. However, systems handling multiple high-resolution cameras, dense LiDAR streams, or distributed AI inference workloads may benefit from detailed benchmarking before selecting a middleware platform.

Memory management represents another important area of comparison. Embedded robotic systems frequently operate under constrained computational resources. Efficient memory utilization directly impacts system reliability and scalability.

Cyclone DDS is often praised for its efficient memory footprint and predictable resource consumption. The implementation minimizes unnecessary allocations and strives for deterministic behavior. These characteristics make Cyclone DDS attractive for resource-constrained platforms and embedded deployments.

Fast DDS provides highly configurable memory management mechanisms that allow developers to optimize behavior according to application requirements. While default configurations may sometimes consume more resources than Cyclone DDS, careful tuning can significantly improve performance. Large enterprise deployments often benefit from the flexibility provided by Fast DDS configuration options.

ROS 2 integration is one of the most important practical considerations. ROS 2 abstracts DDS implementations through the RMW (ROS Middleware) layer. This abstraction allows applications to switch between DDS vendors without modifying application code.

Fast DDS has historically served as the default ROS 2 middleware implementation in multiple ROS 2 distributions. As a result, many ROS 2 tutorials, examples, documentation resources, and community discussions have focused on Fast DDS. Engineers often encounter Fast DDS first when learning ROS 2.

Cyclone DDS has gained substantial adoption within the ROS 2 community due to its strong communication reliability, low latency characteristics, and straightforward configuration. Many developers report excellent out-of-the-box performance with Cyclone DDS, particularly for development environments and robotics research platforms.

Reliability under network stress is another critical evaluation criterion. Real-world robotic systems frequently operate in imperfect network environments characterized by packet loss, wireless interference, variable latency, and intermittent connectivity.

Fast DDS provides extensive Quality of Service configuration options that allow engineers to optimize communication behavior under challenging network conditions. Reliable communication modes, retransmission strategies, discovery server architectures, and transport configuration flexibility enable robust operation across diverse deployment environments.

Cyclone DDS is widely regarded as highly stable and resilient under common robotics networking conditions. Its simplified architecture often results in predictable behavior even when network quality fluctuates. Many robotics teams appreciate this stability when deploying field robots, autonomous vehicles, and mobile robotic systems.

Shared memory communication has become increasingly important for modern robotics workloads. Large sensor streams can overwhelm network interfaces when multiple processes reside on the same machine. Shared memory transport allows DDS participants on the same host to exchange data without unnecessary network serialization and transmission.

Fast DDS includes a mature shared memory transport implementation that significantly improves performance for high-bandwidth applications. Camera processing pipelines, perception systems, AI inference frameworks, and mapping engines benefit substantially from this capability.

Cyclone DDS also supports optimized local communication mechanisms, though implementation details differ. Both middleware platforms continue to improve intra-process and inter-process communication efficiency as robotic workloads become increasingly data intensive.

Security support is a major consideration for industrial and enterprise deployments. DDS Security provides authentication, authorization, encryption, governance policies, logging, and secure discovery mechanisms.

Fast DDS offers comprehensive DDS Security support and has historically been a preferred choice for security-sensitive deployments. Its security framework integrates well with enterprise infrastructure and supports sophisticated policy configurations.

Cyclone DDS also supports DDS Security and continues to enhance its security capabilities. For many robotics applications, both platforms provide adequate security functionality. However, organizations with extensive cybersecurity requirements often conduct detailed evaluations based on specific compliance and certification needs.

Scalability becomes increasingly important as robotic systems evolve toward fleet-scale deployments. Modern warehouses may contain hundreds of AMRs. Smart cities may integrate thousands of autonomous devices. Physical AI ecosystems may involve distributed compute clusters, cloud services, edge devices, and collaborative robots.

Fast DDS has invested heavily in scalability features. Discovery Servers, transport customization, memory tuning options, and enterprise-oriented deployment architectures support very large communication infrastructures. These capabilities make Fast DDS attractive for industrial fleet management systems and large autonomous deployments.

Cyclone DDS scales effectively for many robotics environments and continues to improve large-system performance. However, Fast DDS often provides more advanced tooling and configuration mechanisms specifically targeting large enterprise-scale deployments.

Debugging and observability are important operational considerations. Understanding communication behavior becomes increasingly difficult as systems grow more complex.

Fast DDS provides extensive diagnostic tools, monitoring capabilities, logging mechanisms, and configuration inspection utilities. These tools assist engineers in identifying communication bottlenecks, discovery problems, QoS mismatches, and performance issues.

Cyclone DDS generally emphasizes simplicity and predictable operation, reducing the need for extensive troubleshooting in many scenarios. Nevertheless, debugging support continues to improve as adoption expands.

From a Physical AI perspective, both middleware platforms are becoming increasingly important. Future robotic systems will exchange not only sensor data and control commands but also semantic world models, foundation model outputs, reasoning results, action tokens, collaborative plans, and distributed AI state information. Communication infrastructures must support massive data movement while maintaining deterministic timing and high reliability.

For Hills Robotics-style architectures involving Indoor AMRs, Outdoor Autonomous Vehicles, Mobile Manipulators, Fleet Management Systems, Cargo UAVs, Quadruped Robots, and Humanoid Robots, the choice between Fast DDS and Cyclone DDS depends largely on system priorities. If maximum scalability, extensive configuration flexibility, enterprise deployment capabilities, advanced security integration, and large fleet support are primary objectives, Fast DDS is often the preferred choice. If simplicity, low latency, efficient resource utilization, predictable behavior, and rapid deployment are the dominant requirements, Cyclone DDS may offer significant advantages.

In practical ROS 2 development, both middleware platforms are fully capable of supporting production-grade robotic systems. Many organizations perform benchmarking using their own workloads before making a final decision. Sensor characteristics, network architecture, computational resources, fleet size, security requirements, and operational constraints all influence middleware selection. Rather than viewing Fast DDS and Cyclone DDS as competitors with a universally superior solution, it is more accurate to regard them as optimized for different deployment philosophies. Fast DDS emphasizes flexibility, configurability, and enterprise scalability, while Cyclone DDS emphasizes simplicity, efficiency, and deterministic behavior.

As autonomous systems continue to evolve toward large-scale Physical AI ecosystems, both Fast DDS and Cyclone DDS will remain foundational technologies supporting distributed intelligence, real-time communication, collaborative robotics, and next-generation autonomous platforms. Their continued development ensures that DDS remains one of the most powerful and versatile communication standards available for modern robotics and intelligent systems.

01_05_FastDDS_vs_CycloneDDS

---

Author: Richard Minsoo Go

LinkedIn: Richard Minsoo Go