What's the difference between DDS and SOME/IP?

Question

SOME/IP is an automotive middleware solution that can be used for control messages. DDS is also an automotive middleware for communication. I want to know what's the difference between them? and, why and when should i choose one of them?

Answer 1

SOME/IP and DDS both allow distributed applications to communicate using both the publish/subscribe pattern and the service request/reply pattern (RPC). But there are also significant differences.

SOME/IP was specifically designed for the automotive industry. SOME/IP is a collection of specifications developed as part of AUTOSAR that describe its serialization protocol, service discovery, and a transformer for integration with Classic AUTOSAR.

DDS (Data Distribution Service) targets the broader Industrial IoT domain. It is a family of open standards published by the Object Management Group (OMG). It was specifically designed for distributed real-time systems, and is used in many industries including transportation, energy, medical systems, industrial automation, aerospace and defense, etc. There are many independent implementations both commercial and open source. The first specification in the DDS family was released in 2004 and since then has grown to a set of 12 DDS standards, which include a standard wire-protocol (DDS-RTPS), APIs (DDS-PSM-CXX, DDS-PSM-JAVA and the mappings from IDL to C, Ada , etc.) a type system (DDS-XTYPES), data delivery patterns (DDS for data-centric publish-subscribe and DDS-RPC for request-reply), security (DDS-SECURITY), system description (DDS-XML), data modeling (IDL), and gateways to other communication frameworks (DDS-WEB, DDS-OPCUA and DDS-XRCE).

Technically and conceptually there are many differences, so I organized them into separate categories:

• Communication Patterns
• Application Programming Interfaces (APIs)
• Network Transports
• Approach to Security
• QoS
• Use from other specifications

Communication Patterns

SOME/IP can be seen as an object-based Service-oriented Architecture. Information is provided to the system by instantiating service objects, these are accessed by client applications who instantiate corresponding “proxy” objects for each service instance they want to access. Client applications subscribe to information by attaching a Proxy Object to the Service Object and using it to monitor the events and field changes. They can also invoke operations on the service object to perform remote procedure calls or read/write specific fields.

DDS fundamentally provides a decoupled, data-centric publish subscribe model. Aso referred as a “databus” pattern. Applications participate in the DataBus a peers and can publish/subscribe any data (identified by the DDS-Topic name) as well as invoke or implement any service operation (identified by the DDS-Service name). DDS is fully peer-to-peer -- it does not require any brokers in the middle. There is a discovery mechanism that continually runs to detect compatible publisher and subscriber applications that reference the same Topic name; as soon as they are detected they start exchanging information directly. Subscribers applications can specify filters (content or time-based) to indicate the information that they want to receive. Firtering can occur on the publisher side to reduce the information that goes on the wire.

A significant difference between DDS and SOME/IP is that with DDS an application does not need to bind to specific implementations of services. It simple references the Topics and Services and it may communicate one-to-one or one-to-many fully transparently without any changes to application code. It does need to track the presence of separate peers or manage any new objects in response to peers joining or leaving. It is all handled automatically. In this sense it is much more dynamic than SOME/IP.

Application Programming Interfaces

SOME/IP does not define a standard API, implementations typically provide a C++ API but they are not portable across implementations. However typically SOME/IP is used as part of AUTOSAR, which does define some standard APIs.

DDS has standard APIs for several languages. For C++ and Java, these are included in the DDS-PSM-JAVA and DDS-PSM-CXX specifications. The standard C and ADA APIs are derived from the IDL to C and ADA specifications. On top of that there vendor-specific APIs for C# and other languages. Therefore it is generally possible to port DDS applications and switch between DDS implementations.

Network Transports

SOME/IP supports both UDP and TCP for data transmission. AUTOSAR 4.3 introduced support for segmentation of payloads bigger than 1400 bytes over UDP. For reliable communication, SOME/IP falls back to TCP.

DDS used a a wire protocol called RTPS (Real-Time Publish Subscribe), which is defined in a platform-independent model that can be mapped to different network transport protocols. Most DDS (DDS-RTPS) implementations support at least, UDP, TCP, and shared memory. RTPS implements a transport-agnostic reliability and fragmentation protocol, which runs on top of any transport, including UDP with multicast. So with DDS it is possible to do large data and reliable data over multicast UDP. SOME/IP cannot do that.

Many DDS implementations provide a “custom transport” SDK, so it is possible to run DDS over your own custom transport without sacrificing any of the capabilities and QoS. This is not possible with SOME/IP as certain features (like reliability and fragmentation) have to be implemented by the Transport.

Approach to Security

Generally speaking SOME/IP also relies on the transport for security. So to use it securely it becomes required to run on TLS or DTLS.

It is also possible to run DDS over TLS or DTLS as transports, but this is not the preferred solution. Rather, with DDS it is best to use the mechanisms defined in the DDS Security specification, which are transport-agnostic. DDS security also provides much finer-grained control over security and a language to do access control, so it becomes possible to separately protect DDS Domains and Topics, and differentiate between read and write permissions to a Topic. Also since DDS security is transport agnostic it can be used with any transport including shared memory, multicast or a custom application-defined transport.

Quality of Service Support

SOME/IP only offers one the “reliability” Qos setting used to select UDP versus TCP. Anything else would have to be implemented with custom application-logic which, depending on the QoS policy, can be very hard. Also application-layer code is not so portable and requires all applications to include that same code or at least link a common non-standard library.

DDS provides a number of QoS policies that enable users to specify declaratively how information is exchanged between publishers and subscribers. The DDS standard defines more than 20 separate policies. These policies control not only reliability, but other aspects such as resource usage, data prioritization, data availability and failover. For example, QoS settings provide the ability to establish deadlines to provide notifications if a publisher or a subscriber application fails to send or deliver information at a certain rate; setup durability of the data so that it can be retransmitted to subscriber applications who join after the information was produced and sent; configure the history depth of the publisher and subscriber applications; deploy redundant systems that automatically select one source among many based on ownership strength, configure automatic liveliness messages to determine whether remote applications are still alive and perform automatic failover when applications are not responsive. You can get a lot more details from section 2.2.3 of the DDS Specification or from the documentation of the different implementations (see for example this Qos Cheat-Sheet from RTI Connext DDS).

Use from other Specifications

SOME/IP is primarily used by AUTOSAR for automotive applications.

DDS has a more horizontal use. It is often used directly as a Connectivity Framework. In fact it was identified by the Industrial Internet Consortium (IIC) as one of the “core connectivity frameworks” for IIoT (see the Industrial Internet of Things Connectivity Framework document). It is used also as part of other standards and frameworks such as OpenFMB, ROS2, MD PnP, FACE, and its is also being included into AUTOSAR Adaptive (starting in version 18.03).