1

I am wondering what is the difference between DDS and AUTOSAR. As I know, both of them are communication middlewares. AUTOSAR WAS originally proposed by a group of car manufacturer that's why I guess should be much more suitable for intra-vehicle communications. DDS was proposed for military and critical-mission use cases first. But I really want to know should DDS be an alternative for AUTOSAR? If not, why?

Please correct me, if I am wrong and add more to this.

2

DDS is not a direct replacement for Autosar as they do different things, but DDS can be considered in Automoated Vehicler that do not use Autosar AND can be used as a compliment to Autosar in advanced ADAS and Autonomous Car platforms. There is a concept of a CDD (complex device drive) in Autosar that allows other protocols to be bridged to Autosar domain. DDS supports application development from Research, through pre-production and into production environment (including safety certified versions available from RTI). This is an advantage when developing for systems with unknown technical outcomes or specification.

Autosar is a standard developed by and for the Automotive industry to reduce the cost of design, development, and procurement of the electronic (including ECUs and embedded software) subsystems of production cars. It includes a framework to define and develop these subsystem as well as standards for communication, device driver interfaces, APIs, and basic software services. Autosar includes communication standards like CAN and Flexray. It is common in current production vehicles but has not been much used outside of the Automotive industry and does not currently support Quality of Service over ethernet that will be important for Autonomous Car applications.

DDS is a standard for communication middleware that has been used in robotic, mission critical and autonomous systems -- including land, sea and air vehicles -- for many years. Automotive companies building advanced ADAS and Autonomous Cars are using DDS to compliment existing vehicle platforms, like Autosar, but add additional capability, especially around Quality of Service, that DDS can provide. DDS is design to support time sensitive communication in ‘system-of-systems’ type architectures and can simplify the development process. As the in-car platform changes to support Autonomous Cars, increasingly complex data flows are needed to support new sensors (radar, lidar, and vision) and control algorithms in dynamically changing environments. DDS is well suited to this type of architecture.

Both Autosar and DDS abstract the communication and hardware interfaces from the application level but Autosar defines many other software services and interfaces that have no equivalent in the DDS standard.

You can learn more about DDS in Automotive from RTI here.

1

AUTOSAR is targeted at standardizing a software platform (OS, run time environment, communication, and architecture) while DDS focuses more at standardizing specifically the data communication. They have similar high-level goals to support scalability, flexibility, and portability.

Due to the different focus of the two technologies, I don't think that either should be considered a replacement for the other. However, one could certainly consider using DDS in an AUTOSAR environment to augment the available communication facilities. This could be achieved either at the application level, or more tightly integrated as a specialized component below the AUTOSAR Run Time Environment API.

  • I don't think that it it is possible or worth the hassle to put DDS on top of AUTOSAR. The biggest improvement of DDS over AUTOSAR is the support for all sorts of QoS. But in many cases you need control of the whole stack to implement the QoS functionality properly. – Uwe Honekamp Jul 15 '16 at 17:32
0

DDS is mostly focused on communication, using a publisher-subscriber pattern. Until recently, DDS did not support client-server communication (AFAIK there is now a "beta" implementation available).

Client-server communication, beside the sender-receiver pattern, is a big thing in AUTOSAR.

In an automotive stack, communication is just a small part of the overall functionality. Network management, mode management, diagnostics, etc. are all covered by AUTOSAR. Out of the box, DDS only supports Ethernet as the physical layer. For this, the protocol RTPS is defined within the DDS Context.

AUTOSAR, on the other hand, supports all relevant bus systems in the automotive domain: CAN, LIN, FlexRay, and Ethernet.

DDS beats AUTOSAR when it comes to the support for "quality of service".

The DDS standard documents are made of untagged text, which is a problem for an integration in an automotive development process. Requirements tracing is bigger than you might think.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.