ROS 2 DDS (Data Distribution Service)

ROS 2 leverages the DDS Security specification (implemented via plugins like CycloneDDS or Fast-DDS) to provide a comprehensive security framework. This is a major advancement over ROS 1. Security features are enabled through governance and permission XML files and include:

• Authentication: Uses X.509 certificates to verify the identity of nodes and participants.
• Encryption: Encrypts all data in transit (e.g., using AES-GCM) to prevent eavesdropping.
• Access Control: Fine-grained permissions govern which nodes can publish/subscribe to specific topics or call services. This allows for the deployment of secure, production-grade robotic systems in sensitive or adversarial environments.

ROS 2 Quality of Service (QoS) policies are configurable settings that govern the behavior of data exchange between nodes via DDS. They allow developers to tune communication for specific operational needs, from best-effort to strict real-time guarantees.

Key policies include:

• Reliability: Choose between RELIABLE (guaranteed delivery) or BEST_EFFORT.
• Durability: Set VOLATILE (no history) or TRANSIENT_LOCAL (late-joining subscribers receive last sent message).
• Deadline: Define the maximum expected period between successive messages.
• Liveliness: Specify how often a node must signal it's alive to avoid being considered dead.
• History Depth: Control how many messages are kept in a queue for late-joining or slow subscribers.

These policies are negotiated between publishers and subscribers; a connection only forms if their QoS profiles are compatible.

ROS 2 does not implement DDS directly but acts as an abstraction layer over compliant DDS implementations. Each is a separate middleware library with its own performance characteristics, licensing, and platform support.

Common implementations include:

• RTI Connext DDS: A commercial-grade implementation known for robust performance, extensive tooling, and strong real-time guarantees. Often used in safety-critical and aerospace applications.
• Eclipse Cyclone DDS: A high-performance, open-source implementation developed as part of the Eclipse Foundation. It is the default for many ROS 2 distributions due to its balance of features and permissive license.
• eProsima Fast DDS: Another open-source implementation, offering a wide range of features and integration with the Micro-ROS project for embedded systems.

The chosen implementation is specified via the ROS Middleware Interface (RMW) layer. A system can use only one DDS implementation at a time per domain.

A core feature of DDS is its decentralized, peer-to-peer discovery process. Unlike ROS 1's centralized master node, ROS 2 nodes autonomously find each other on the network without a single point of failure.

The process involves:

1. Participant Discovery: When a node starts, its underlying DDS DomainParticipant broadcasts its existence using multicast or unicast protocols (Simple Discovery Protocol).
2. Endpoint Discovery: After participants discover each other, they exchange metadata about their specific data publishers and subscribers (topics, data types, QoS).
3. Connection Establishment: If a publisher and subscriber have compatible topics, data types, and QoS policies, a direct communication channel is established.

This architecture enhances system robustness and scalability, allowing for dynamic addition and removal of nodes.

The ROS_DOMAIN_ID environment variable is a critical network isolation mechanism. It segments the logical network into separate DDS domains, preventing unrelated ROS 2 systems from interfering with each other.

• Mechanism: The Domain ID (an integer from 0 to 232) is used by the DDS implementation to calculate multicast addresses and participant identifiers. Nodes with different Domain IDs are invisible to each other.
• Primary Use Case: Running multiple independent robot systems on the same physical network (e.g., in a lab or factory) without cross-talk.
• Secondary Use Case: Isolating development/testing graphs from a production system.
• Default: The default Domain ID is 0. All nodes must share the same Domain ID to communicate.

This is a simpler alternative to complex network configuration and is essential for multi-robot and shared-environment deployments.

ROS 2 Security (SROS 2) leverages the DDS Security specification to provide a comprehensive security framework for robotic communications. It is not a ROS 2-specific implementation but a configuration of the underlying DDS middleware's security plugins.

Core security services enabled include:

• Authentication: Uses X.509 certificates to verify the identity of nodes and participants before they can join the domain.
• Access Control: Governs which nodes are permitted to publish or subscribe to specific topics, based on security policies.
• Cryptography: Provides encryption for data in transit and signing to guarantee data integrity and origin.
• Logging: Captures security-relevant events for audit trails.

Configuration is managed through certificate authorities, governance files, and permissions files, which define the security policies for the entire ROS 2 domain.

The ROS Middleware Interface (RMW) is the abstraction layer that decouples ROS 2's core client libraries (rclcpp, rclpy) from the specific DDS implementation. It defines a pure C API that all DDS vendors must implement.

• Purpose: Allows swapping the DDS middleware (e.g., from Cyclone DDS to Connext) by changing a single environment variable (RMW_IMPLEMENTATION) without modifying application code.
• Architecture: rcl (ROS Client Library) calls the generic RMW API, which then calls the vendor-specific RMW adapter (e.g., rmw_connextdds, rmw_cyclonedds). This adapter translates calls into the native DDS API.
• Vendor Neutrality: This design promotes competition among DDS vendors and allows ROS 2 to leverage ongoing improvements in the DDS ecosystem.
• Alternative Middleware: The RMW architecture theoretically allows for non-DDS middleware implementations, though DDS remains the standard.