Blog Details

Teams building connected vehicle or IoT-adjacent systems eventually face the same question: which middleware handles the data plane? The three most common answers — DDS, MQTT, and SOME/IP — are frequently discussed as if they're interchangeable. They aren't. Each was built for a different network topology and failure model, and picking the wrong one shows up later as latency problems, brittle scaling, or a rewrite.

The One-Paragraph Version

MQTT is a broker-based, lightweight pub/sub protocol built for constrained devices and unreliable networks (originally for SCADA over satellite links); it's the right default for cloud-connected telemetry and fleet-scale IoT. DDS is a brokerless, peer-to-peer pub/sub protocol with rich QoS, built for real-time systems that need low-latency data distribution without a central point of failure; it's the right default for in-vehicle compute clusters (perception, planning) and industrial control. SOME/IP is an automotive-specific RPC + pub/sub protocol built to integrate with AUTOSAR; it's the right default when your in-vehicle domain needs to talk to classic ECUs.

Topology Is the First Filter

Before comparing features, ask: where do the endpoints live?

• Cloud ↔ vehicle, many-to-one fan-in: MQTT. A broker (e.g., a cloud MQTT broker or fleet-scale telemetry ingestion service) naturally models thousands of vehicles publishing to topics that backend services subscribe to.
• Within a single vehicle's compute cluster, peer-to-peer: DDS. No broker needed; nodes discover each other directly on the local network, which matters when a broker crash shouldn't take down control loops.
• Within a vehicle, integrating with classic AUTOSAR ECUs: SOME/IP. It's the protocol the rest of the AUTOSAR stack already speaks.

Trying to use MQTT for a real-time in-vehicle control loop introduces a broker as a single point of failure and extra latency hops (publisher → broker → subscriber) that DDS and SOME/IP avoid by design.

Feature Comparison

Feature MQTT DDS SOME/IP Architecture Broker-based Brokerless (peer-to-peer) Peer-to-peer with SD Transport TCP UDP (RTPS) or TCP TCP/UDP QoS levels 3 (0/1/2 delivery guarantees) 20+ fine-grained policies Basic (event/method, TTL) Payload format Opaque bytes (app-defined) CDR (typed, IDL-defined) SOME/IP binary format Typical latency Tens of ms+ (broker hop, TCP) Sub-ms to low ms (UDP, no broker) Low ms (designed for in-vehicle Ethernet) Scale pattern Very high fan-in (thousands of publishers) Moderate node count, low latency Bounded to vehicle network size Security model TLS + broker ACLs DDS Security spec (auth, access control, encryption) AUTOSAR SecOC at lower layers Best network condition Works over lossy/high-latency WAN Assumes reliable LAN Assumes in-vehicle Ethernet/CAN

Where Each One Breaks

MQTT breaks down when you try to use it for low-latency control — the broker hop and TCP overhead make it unsuitable for anything approaching real-time deadlines. It also concentrates risk in the broker; if you don't operate a highly available broker cluster, you've created a new single point of failure for your whole fleet.

DDS breaks down when deployed over WAN or lossy links without careful tuning — its discovery protocol assumes a reasonably well-behaved multicast-capable LAN. Over cellular/WAN, you need DDS routing services or a WAN-aware discovery configuration, otherwise discovery storms and reliability retransmits get expensive.

SOME/IP breaks down outside the vehicle network context — it has no first-class answer for cloud connectivity, WAN operation, or non-automotive IoT devices. It's not trying to be a general-purpose protocol, and treating it as one leads to reinventing cloud connectivity poorly.

A Realistic SDV Architecture Uses All Three

A software-defined vehicle platform commonly ends up with a layered middleware architecture rather than one protocol everywhere:

1. Vehicle-to-cloud: MQTT (or a managed IoT message broker) carries telemetry, OTA status, and fleet commands over cellular.
2. In-vehicle compute cluster: DDS carries perception, planning, and control data between domain controller processes with real-time QoS.
3. In-vehicle body/classic domain: SOME/IP carries service calls between the compute cluster and classic AUTOSAR ECUs (body control, powertrain).
4. Gateway bridging: A gateway service translates between these domains — e.g., relaying a DDS topic's summarized state to MQTT for cloud visibility, or translating a SOME/IP event into a DDS topic for the compute cluster.

Decision Framework

Ask these questions in order:

1. Does this data cross the vehicle boundary (cloud, fleet backend)? → MQTT.
2. Does this data stay inside the vehicle and need per-topic QoS tuning for mixed real-time streams? → DDS.
3. Does this data need to interoperate with classic AUTOSAR ECUs or existing AUTOSAR tooling? → SOME/IP.
4. Is there no broker infrastructure you're willing to operate and maintain HA for? → Rule out MQTT for that path; use DDS or SOME/IP instead.
5. Do you need protocol-level security policy (auth/ACL/encryption) without building it yourself? → DDS Security or TLS-based MQTT; SOME/IP typically defers security to lower AUTOSAR layers (SecOC).

Common Mistake

The most common mistake is picking one protocol for "consistency" across the whole platform. This nearly always produces worse outcomes than matching each domain to its natural protocol and investing in solid gateway/bridge code at the boundaries. The bridge is a small, well-defined piece of code; a mismatched protocol baked into every subsystem is a much larger and more permanent cost.