DDS and when to use it · Bhargava Mandapati

is not the only answer. — Data Distribution Service — solves an overlapping problem differently, and on most modern vehicles both are present, doing different jobs.

The different starting point#

What DDS adds: quality of service#

The distinguishing feature is that a subscriber can state its requirements, and the middleware enforces them.

QoS policy	What it controls
Reliability	Best-effort, or retransmit until delivered
Durability	Does a late subscriber receive the last value, or only new ones?
Deadline	Declare an expected update period; get notified if it is missed
Liveliness	Detect that a publisher has stopped, quickly and explicitly
History	How many past samples are kept for late joiners
Latency budget	Hint the middleware to batch or send immediately

Why ADAS chose it#

Why body electronics did not#

Now the opposite case. "Move the seat to position 42, and tell me if you refused."

Choosing between them#

Your situation	Use
Request with a specific answer and errors	SOME/IP
Continuous stream, several consumers	DDS
Need automatic deadline and liveliness detection	DDS
Migrating from CAN signals	SOME/IP fields
High-frequency sensor data	DDS
Occasional command	SOME/IP
Sharing with a ROS-based stack	DDS
Existing AUTOSAR toolchain	SOME/IP

Both, with a bridge#

Most real vehicles run both, with a bridge where they meet.

The common arrangement

  cameras, radar ──DDS──> ADAS perception ──DDS──> ADAS control
                                │
                            bridge (state only, not raw data)
                                │
  seat, lights, doors ──SOME/IP──> cockpit ──SOME/IP──> cluster & IVI

Practical notes#

Discovery is chatty. DDS discovery is more talkative than SOME/IP's. On a constrained network this needs tuning, and default settings are rarely right for a vehicle.

Configuration is where the complexity lives. The API is small; QoS policy interaction is not. Two policies that each look sensible can combine into behaviour nobody intended — a reliability setting that conflicts with a history depth, for instance.

Implementations differ. DDS is a specification with several implementations, some open source and some commercial. Interoperability is specified but worth testing rather than assuming.

Debugging

tcpdump -i eth0 -w dds.pcap        # Wireshark dissects RTPS, the DDS wire protocol
# then check: are participants discovering each other, and do QoS settings match?

Next#

The shared vocabulary both protocols carry.