Choose by traffic class, not by preference. SOME/IP fits AUTOSAR-native vehicle services, body and comfort functions, and diagnostics where tooling and supplier familiarity dominate. DDS fits ADAS and autonomous compute that needs rich quality-of-service policies. Zero-copy shared memory carries high-bandwidth sensor data inside one ECU. Most production programs run all three.
Key takeaways
- Middleware selection is a traffic-class decision: one vehicle typically carries SOME/IP, DDS, and shared-memory transport at once.
- SOME/IP wins on AUTOSAR integration, OEM familiarity, and supplier tooling; it loses on QoS expressiveness.
- DDS wins on QoS policies and the ROS 2 ecosystem; it costs more memory, CPU, and discovery-tuning effort.
- Camera, lidar, and radar payloads should never cross a serializing middleware inside a single ECU.
- Signal-to-service gateways are permanent architecture, not a transitional hack.
- The hardest part is not the protocol — it is who owns the interface contract and how it is versioned.
Why did service-oriented communication replace signal-based CAN?
Signal-based communication assumes the network is fixed at design time. A CAN matrix defines every signal, its bit position, its cycle time, and every ECU that consumes it. Adding one consumer means re-releasing the matrix, re-integrating every affected ECU, and re-validating the bus. A feature added post-SOP has no clean path onto the network.
Service-oriented architecture inverts this. A provider publishes a service; consumers discover it at runtime and subscribe. Adding a consumer becomes a runtime event, not a database change — the property that makes over-the-air feature delivery structurally possible.
The trade is determinism. A statically scheduled CAN frame has bounded, provable timing. A discovered Ethernet service does not, unless you engineer that bound through TSN scheduling, traffic shaping, or a static configuration overlay. Teams that treat SOA as "CAN but easier" get burned here.
What is SOME/IP and where does it fit?
SOME/IP (Scalable service-Oriented MiddlewarE over IP) is the AUTOSAR-native service protocol for automotive Ethernet. It provides service discovery, remote procedure calls, event notification, and fields, with a serialization format defined by AUTOSAR.
Its strengths are institutional as much as technical:
- AUTOSAR integration. It is the transport binding for Adaptive Platform service interfaces (ara::com) and is supported in Classic through Ethernet stacks. See AUTOSAR Classic vs. Adaptive.
- Supplier ecosystem. Nearly every automotive stack vendor, test tool, and network analyzer supports it. Your Tier-1 has done it before.
- Modest footprint. It runs on constrained targets where a full DDS stack would not.
- OEM adoption. It is the protocol most OEM interface specifications already assume, which matters when your interface partners are twenty suppliers.
Its weakness is QoS. SOME/IP gives you TCP or UDP and multicast eventgroups, not per-topic deadline enforcement, durability, liveliness, or history depth. If you need those, you build them by hand in application code — which is where the saved integration effort comes back.
What is DDS and where does it fit?
DDS (Data Distribution Service) is an OMG standard for data-centric publish/subscribe. Instead of calling a service, participants read and write typed topics in a shared global data space, and the middleware reconciles who needs what.
The differentiator is the QoS policy set. Reliability, durability, deadline, latency budget, liveliness, ownership, history, and resource limits are declared per topic and enforced by the middleware. Where a stale detection is worse than a missing one, that is a real advantage rather than a specification detail.
DDS dominates in ADAS and AD compute for two reasons: the QoS model matches sensor-fusion problems, and ROS 2 uses DDS as its default middleware, so anything from a research or prototyping pipeline speaks it natively.
The costs are real:
- Footprint. Memory and CPU consumption are materially higher than SOME/IP; small zonal controllers usually cannot host it.
- Discovery scaling. Simple discovery scales with the square of participant count and floods a large domain at startup. Production needs discovery servers, static discovery, or partitioning — plan that work rather than finding it at integration.
- Configuration surface. Rich QoS means many ways to misconfigure. A mismatched reliability or durability setting produces a silently non-communicating pair.
When do you skip network middleware entirely?
When the payload is large and both endpoints sit on the same ECU. A 4K camera frame serialized, copied, and pushed through a socket burns CPU and adds latency for no architectural benefit.
Zero-copy shared-memory transports such as Eclipse iceoryx solve this. The publisher writes into a shared memory pool once; subscribers read the same physical memory. Transfer cost becomes largely independent of payload size — exactly what camera, lidar, and radar pipelines need.
This is not an alternative to DDS but a layer beneath it. Several DDS implementations use iceoryx or an equivalent as a local transport, so applications keep one API while intra-ECU traffic bypasses the network stack.
How do you bridge legacy CAN, LIN, and FlexRay?
Through a signal-to-service gateway. It unpacks CAN, LIN, or FlexRay frames into signals, republishes them as SOME/IP or DDS services, and translates service calls back into bus frames.
This is permanent architecture. Chassis actuators, body controllers, and safety-relevant sensors stay on classic buses because the parts are qualified, cheap, and deterministic. In a zonal architecture the zone controller usually hosts this translation.
Two things go wrong. Teams put logic in the gateway — unit conversion, plausibility, state machines — and it becomes an undocumented application ECU. And they ignore timing: a signal that was deterministic on FlexRay is not deterministic after gateway queuing and Ethernet transport. Measure it.
What criteria actually decide the choice?
Rank these against your specific traffic, not in the abstract.
- Bandwidth. At sensor-stream volumes, only zero-copy is viable intra-ECU.
- Latency determinism. If you need a provable bound, the answer is TSN plus static configuration, whatever middleware sits on top.
- Safety. Whether a qualified stack exists for your ASIL target eliminates candidates faster than any technical criterion. See functional safety in a CI/CD world.
- Security. Both have security specifications; check what your implementation ships and what key management costs in production. This is ISO/SAE 21434 territory.
- Tooling maturity. Can your validation team trace, replay, and inject faults on this transport? If not, you have bought integration debt.
- Supplier ecosystem. If fifteen partners deliver SOME/IP and one delivers DDS, standardizing on DDS costs fifteen conversations.
- Interface ownership. Who authors the service definition, who approves changes, how are versions deprecated? Programs fail here more often than on protocol choice.
How do the options compare?
| SOME/IP | DDS | Shared memory / zero-copy | Signal-based CAN | |
|---|---|---|---|---|
| Data model | Service-oriented: RPC, events, fields | Data-centric pub/sub over typed topics | Local pub/sub on shared buffers | Static signals in fixed frames |
| QoS | Reliable/unreliable transport, multicast eventgroups | Rich policy set: durability, deadline, liveliness, history, ownership | Minimal; buffer and history depth | None; determinism from static schedule |
| Footprint | Low to moderate | Moderate to high | Very low per byte transferred | Very low |
| Discovery | SOME/IP-SD, offer/find | Dynamic participant discovery; needs tuning at scale | Local registry, no network discovery | None; configured offline |
| Tooling | Broad automotive tool support | Strong in robotics and AD; narrower classic-automotive tooling | Vendor and open-source, limited tracing | Mature and universal |
| Best fit | Vehicle services, body, diagnostics, cross-supplier interfaces | ADAS and AD compute, ROS 2 pipelines, QoS-sensitive data | Intra-ECU camera, lidar, radar payloads | Actuation and legacy subsystems |
What does a sane architecture look like?
Segment by traffic class first. Four classes cover almost everything in a production vehicle.
Backbone vehicle services run on SOME/IP. Body, comfort, energy management, diagnostics, and anything a supplier delivers against a written interface specification belong here, because the specifications, the stacks, and the network analyzers already assume it.
High-bandwidth perception and AD compute run on DDS. That traffic needs deadline, liveliness, and durability declared per topic, and it usually arrives from a ROS 2 pipeline that speaks DDS natively. Keep it inside the compute node rather than spreading it across the vehicle.
Sensor payloads that never leave an ECU run on zero-copy shared memory. A camera frame handed between two processes on the same SoC should not be serialized, copied, and pushed through a socket to reach a neighbor.
Legacy CAN, LIN, and FlexRay stay where they are, behind a signal-to-service gateway that republishes them as services. Qualified actuators and sensors are not worth re-sourcing to change their transport.
Then govern the seams. Each bridge point is where QoS semantics, type systems, and versioning rules stop matching, so each needs a named owner and a place on your HIL, SIL, and vehicle-in-the-loop benches.
Frequently asked questions
Is DDS better than SOME/IP?
Neither is better in general. DDS offers a richer quality-of-service model and suits ADAS and autonomous-driving pipelines where deadline, durability, and liveliness policies matter. SOME/IP is lighter, is native to AUTOSAR Adaptive, and has broader automotive tooling and supplier familiarity. Most production vehicles use both, segmented by traffic class, with gateways between the domains.
Can SOME/IP and DDS coexist in one vehicle?
Yes, and this is the common production pattern. SOME/IP typically carries vehicle services across the Ethernet backbone while DDS runs inside the high-performance compute for perception and planning. A bridge translates between them. The engineering work is in that bridge: type mapping, QoS semantics that do not correspond one-to-one, and clear ownership of the translated interface contract.
Does SOME/IP require AUTOSAR?
No. SOME/IP is a protocol specification and can be implemented on any IP-capable stack, including Linux and QNX systems outside AUTOSAR. In practice it is most often deployed as the transport binding for AUTOSAR Adaptive service interfaces, and the surrounding toolchain assumes AUTOSAR artifacts, so non-AUTOSAR use means more integration work you build yourself.
What is iceoryx used for?
Eclipse iceoryx is a zero-copy inter-process communication library for high-bandwidth data on a single machine. Camera, lidar, and radar payloads are written once into shared memory and read in place by subscribers, so transfer cost stays roughly constant regardless of payload size. It is frequently used as a local transport underneath DDS rather than as a replacement for it.
Do we still need CAN in a service-oriented vehicle?
Yes. CAN, LIN, and FlexRay remain the right answer for actuation, body control, and many safety-relevant sensors: the parts are qualified, inexpensive, and deterministic. Service-oriented Ethernet supplements them rather than replacing them. Signal-to-service gateways connect the two worlds and should be treated as permanent architecture, not as temporary migration scaffolding.
How do you keep DDS discovery from overwhelming the network?
Default simple discovery scales with the square of participant count, which floods startup traffic on large domains. Production deployments use a discovery server, static or pre-configured discovery, domain and partition segmentation, and restricted participant counts per domain. Plan this before integration; discovering the limitation during vehicle bring-up is expensive and typically forces late architectural change.
Who should own the service interface definition?
The OEM, in almost all cases. The interface contract is the durable asset in a software-defined vehicle: it outlives suppliers, ECU generations, and protocol choices. Whoever owns it controls the pace of feature change. Define versioning and deprecation rules alongside the interfaces themselves, and enforce them in CI rather than in review meetings.
GEMMACON's engineers work on the seams: service definition, middleware integration, gateway design, and the validation that proves the timing holds. If you are deciding how to segment traffic across SOME/IP, DDS, and shared memory — or untangling a program where that decision was made implicitly — get in touch.
