logo Micro XRCE-DDS

For extremely constrained devices

logo Micro XRCE-DDS

Bring tiny devices into the DDS Global Data Space.

Use a lightweight DDS-XRCE Client and an Agent bridge when a microcontroller or FPGA is too constrained to host a complete DDS implementation.

< 2 kB RAM

Documented simple publisher/subscriber client configuration.

Flexible transports

UDP, TCP, Serial, CAN FD and custom transports.

Apache 2.0

Open-source Client and Agent implementation.

EXTREMELY CONSTRAINED DEVICE PATH
Micro XRCE-DDS Client and Agent architecture Two microcontrollers and an FPGA run XRCE Clients and connect to an XRCE Agent software process inside a host device. The Agent creates represented DDS publisher and subscriber endpoints outside the DDS Global Data Space. Data travels from each endpoint to a topic boundary and emerges on the opposite side toward a native DDS endpoint. 01 · CONNECT 02 · REPRESENT 03 · EXCHANGE MCU AXRCE Client < 2 kB RAM MCU BXRCE ClientSERIAL / CAN FD FPGAXRCE ClientCUSTOM TRANSPORT DDS-XRCE AGENT HOST XRCE Agent PUB SUB REPRESENTED DDS ENDPOINTS Requested by Client · created by Agent DDS Global Data Space Telemetry Command Status NATIVE DDS ENDPOINTS

OPEN SOURCE · SPECIALIZED PATH Micro XRCE-DDS is deliberately narrow.

It solves the edge case where the target is extremely constrained. For regular embedded products, deterministic systems and safety-critical applications, evaluate Safe DDS first.

How the architecture works

A small Client. An Agent bridge. One DDS data space.

The XRCE Client does not participate in DDS directly. It sends DDS-XRCE operations to an Agent, which creates and manages DDS entities on its behalf.

01
Run the XRCE Client

DEVICERun the XRCE Client

Compile a lightweight C client with only the profiles and transport required by the target.

02
Connect to the Agent

BRIDGEConnect to the Agent

The Agent maintains Client sessions and translates XRCE operations into DDS entities and data exchanges.

03
Exchange with DDS

DATA SPACEExchange with DDS

Fast DDS participants communicate with the entities represented by the Agent in the DDS Global Data Space.

Core capabilities

Use only when the device constraints demand it.

Micro XRCE-DDS is optimized around a compact Client, flexible transports and an Agent-mediated path to DDS.

Profile-based footprint · Static-memory operation
Profile-based footprint · Static-memory operation

Fit extremely constrained targets

Run a small C client on devices that cannot host a complete DDS implementation. A simple publisher/subscriber can operate with less than 2 kB of RAM in the documented reference configuration.

  • Small, portable C implementation
  • Static-memory operation
  • Footprint shaped for the target
Built-in and custom transports
Built-in and custom transports

Choose the transport that fits the device

Use UDP, TCP, Serial, CAN FD or a custom packet- or stream-oriented transport according to the interfaces available on the target.

  • UDP and TCP
  • Serial and CAN FD
  • Custom packet or stream transports
Compile-time feature profiles
Compile-time feature profiles

Select only what you need

Enable or remove transport, discovery, framing, multithread and shared-memory profiles at compile time to shape the client for the target.

  • Compile-time selection
  • Remove unused capabilities
  • Create a target-specific client
Client / Agent architecture
Client / Agent architecture

Bridge constrained devices into DDS

Let the Agent create DDS entities and exchange data with the DDS Global Data Space on behalf of each XRCE Client.

  • XRCE session management
  • DDS entities represented by the Agent
  • Interoperability with DDS participants

Choose the embedded path

Micro XRCE-DDS or Safe DDS?

The decision is architectural, not simply a matter of footprint. Start with the target constraints, the required runtime model and the product lifecycle.

logo Micro XRCE-DDS
Open source

Choose XRCE when every kilobyte matters.

  • The target genuinely cannot host a complete DDS implementation
  • An external Agent is acceptable in the system architecture
  • You need UDP, TCP, Serial, CAN FD or a custom constrained link
  • You will own integration, validation and lifecycle management
logo Sage DDS
Commercial · Asil D

Choose Safe DDS for a professional embedded product.

  • You need direct DDS / RTPS participation without an Agent
  • Predictable real-time behavior and memory control matter
  • You want an independent implementation with no external dependencies
  • You need ISO 26262 ASIL D evidence or a safety-oriented lifecycle

Open source

Micro XRCE-DDS

Commercial · Asil D

Safe DDS

Primary target

Extremely constrained MCUs and FPGAs

Embedded, real-time and safety-critical systems

Architecture

Lightweight XRCE Client plus external Agent

Independent DDS / RTPS implementation

DDS participation

The Agent acts on behalf of the Client

Direct participation in the DDS Global Data Space

Footprint strategy

Minimum XRCE client footprint through compile-time profiles

Controlled embedded footprint with deterministic behavior as a core design priority

Runtime dependency

Requires an Agent to reach the DDS network

No external dependencies

Functional safety

Not safety certified

ISO 26262 ASIL D certified

Best fit

When the device genuinely cannot host a DDS implementation

Professional embedded products and systems with lifecycle, real-time or safety requirements

Developer resources

Start with the supported architecture.

Use the current documentation for architecture, installation, profiles, transports and examples.

icon
01

Documentation

Architecture, installation, Client API, Agent configuration, transports and examples.

icon
02

XRCE Client

The lightweight C implementation intended for the constrained target.

icon
03

XRCE Agent

The bridge that represents XRCE Clients in the DDS Global Data Space.

Architecture first

Is the target truly XRCE-constrained?

Tell us about the processor, memory, operating system, transport and safety requirements. We will help determine whether Micro XRCE-DDS or Safe DDS is the stronger long-term architecture.

Target footprint and memory model.

Agent dependency and network topology.

Real-time and safety requirements.

Migration and product lifecycle.