Middleware

DDS Middleware

The LDM SDK uses the Data Distribution Service (DDS) standard for all publish/subscribe communication between vehicle subsystems. DDS provides real-time, scalable, and decentralised data distribution — ideal for safety-critical military vehicle architectures where reliability and deterministic latency matter.

Astute Systems Astute DDS

Astute DDS is the recommended DDS middleware for the LDM SDK. Developed by Astute Systems, it is purpose-built for GVA deployments and provides:

  • Tight LDM integration — tested and validated against all LDM IDL topic definitions
  • Lightweight footprint — optimised for embedded and resource-constrained platforms (ARM64 Jetson, single-board computers)
  • Defence-grade quality — developed with military vehicle deployment in mind
  • First-class support — direct engineering support from the LDM SDK team
  • Open documentation — full API reference at astute-systems.github.io/astutedds-cxx

Quick Start with Astute DDS

# Astute DDS is built automatically as part of the LDM SDK
mkdir -p build && cd build
cmake ..
make external -j $(nproc)
cmake ..
make -j $(nproc)

When Astute DDS is used, no additional configuration is required — the SDK build system handles everything automatically.

Astute DDS Documentation

Full API documentation, configuration guides, and examples are available at:
https://astutesys.com/dds · API Reference

Supported DDS Providers

The LDM SDK is designed to be DDS-vendor agnostic. While Astute DDS is the recommended and default middleware, the SDK supports any major DDS implementation that conforms to the OMG DDS standard:

Provider Organisation Notes
Astute DDS Astute Systems Recommended. Default middleware, optimised for LDM.
Eclipse Cyclone DDS Eclipse Foundation Open-source, widely used in ROS 2 and automotive.
RTI Connext DDS Real-Time Innovations Commercial, used in major defence programmes.

Vendor Compatibility

All DDS providers that implement the OMG DDS and DCPS standards are interoperable at the wire level via RTPS (Real-Time Publish-Subscribe). Applications built with one provider can communicate with applications using another, provided they share the same domain and topic definitions.

Architecture

DDS sits between the application layer and the network, handling discovery, serialisation, and reliable delivery:

graph TB subgraph "GVA Applications" HMI[gva-hmi] REG[gva-registry] ALM[gva-alarms] BMS[gva-app-bms] EXT[External Apps] end subgraph "LDM SDK Layer" IDL[IDL-Generated Types] QT[Qt Wrapper Pub/Sub] end subgraph "DDS Middleware" DDS[Astute DDS / Cyclone DDS / RTI Connext] end subgraph "Network" NET[UDP Multicast / Shared Memory] end HMI --> QT REG --> QT ALM --> QT BMS --> QT EXT --> QT QT --> IDL IDL --> DDS DDS --> NET

DDS Configuration

Domain ID

All applications on the same vehicle must use the same DDS domain ID:

# Default domain
./gva-registry --domain=0
./gva-hmi --domain=0

# Separate domain for testing
./gva-registry --domain=1
./gva-hmi --domain=1

Network Configuration

DDS can be configured for different network topologies using XML configuration files:

# Localhost only (development)
export CYCLONEDDS_URI=file://$(pwd)/cyclonedds-localhost.xml

# Wi-Fi / multi-host (integration testing)
export CYCLONEDDS_URI=file://$(pwd)/cyclonedds-wifi.xml

Switching DDS Provider

To use a different DDS provider, rebuild the SDK with the appropriate CMake options pointing to the desired DDS installation. The IDL-generated types and Qt wrapper layer remain unchanged — only the underlying middleware library is swapped.

For detailed instructions on building with a specific provider, refer to the provider's documentation and the LDM SDK build guide.

See Also