Integrating DDS Into the AUTOSAR Adaptive Platform

Solving new challenges is what drives innovation, but one fact is inescapable: Across a wide variety of industries, system architectures are rapidly evolving and becoming ever-more complex. To tame this complexity and maximize data throughput, Data Distribution Service™ (DDS) has emerged as a more efficient, scalable and secure solution for meeting the most demanding mission-critical deployments. 

As a result of this trend, over the past few years consortia and standards organizations spanning multiple industries have already begun choosing DDS as the underlying technology for their next-generation connected systems. Examples of these standards and frameworks include the Open Group Future Airborne Capability Environment (FACE) for airborne systems, Open Field Message Bus (OpenFMB) for smart grid, the Medical Device "Plug-and-Play" Interoperability Program (MD PnP) for medical devices, and the Robot Operating System (ROS 2) for robotics.

One of the latest organizations to adopt DDS is AUTOSAR. In this blog, we’ll delve into the new DDS Network Binding for the AUTOSAR Adaptive Platform, which introduces DDS and its rich set of Quality of Service (QoS) policies into the AUTOSAR service-oriented architecture (SOA), enabling new interoperability scenarios where AUTOSAR systems can be integrated into larger systems of systems based on the DDS databus.

AUTOSAR Overview

AUTOSAR (AUTomotive Open System ARchitecture) is a global partnership of vehicle manufacturers, suppliers, software and electronics vendors. It produces standards for interoperable software architectures for automotive systems.

In 2004, AUTOSAR introduced its widely-adopted Classic Platform, a layered software architecture that provides a comprehensive solution to handle the development, communication and execution of time-critical applications deployed in microcontroller-based electronic component units (ECUs). The Classic Platform leverages well-known connectivity buses, such as CAN, LIN or Flexray to provide robust communication capabilities.

In the last decade, the introduction of new ECUs—based on more powerful microprocessors and Ethernet technology—has opened the door to more integrated and autonomous vehicular systems. In response, AUTOSAR introduced the Adaptive Platform, a completely new software architecture that aims to address an entirely new array of use cases. To help the consortium realize this vision, RTI joined AUTOSAR back in 2017 as a development partner. And over the last few years, we’ve lent our expertise to extending the AUTOSAR Adaptive Platform communication management API to use DDS and exploit its many benefits.

Communication Management in AUTOSAR Adaptive

The AUTOSAR Adaptive Platform defines a number of functional clusters, ranging from execution management to time synchronization, monitoring, diagnostics and communication management.

For communication, AUTOSAR Adaptive defines ara::com, a standard C++ API based on SOA. Initially based on SOME/IP, ara::com aims to define an API that is agnostic of the underlying connectivity technology, providing the means to define and deploy well-known services and to expose functionality to client applications as if they were local resources.

AUTOSAR service interfaces are usually defined using ARXML, a modeling language derived from the AUTOSAR UML metamodel. As a result of code generation, the ARXML compiler generates code for proxies and skeletons for client and server applications, respectively. On the client side, applications instantiate proxies that bind to service instantiates running on the server side. Each proxy can only be bound to a service instance at a time, explicitly coupling proxies to service instances.

Ara::com services provide the following resources:

• Events - Notify client applications of events triggered on the server side.
• Methods - Expose remote procedures that client applications can invoke.
• Fields - Provide data values that client applications can modify with remote getters and setters. Clients may also subscribe to field value changes.

Integrating DDS into the AUTOSAR Adaptive Platform

DDS and ara::com present stark differences at the architectural level. Ara::com is based on a pure service-oriented architecture, where clients (i.e., proxies) and servers (i.e., service instances) are tightly coupled. DDS introduces a data-centric publish-subscribe model that effectively decouples publisher and subscribers by providing a logical databus for communication.

However, the DDS data-centric publish-subscribe model is extremely flexible and is often considered a super pattern that can be used to implement publish-subscribe as well as other patterns, such as request-reply and queuing. As a result, DDS can adhere to semantics of the ara::com and the AUTOSAR Adaptive Platform using mechanisms that are already available in the DDS family of specifications. Below, we introduce the basic mechanisms for the implementation of these concepts.

Coupling Service Instances and Proxies

As I mentioned above, upon instantiation, proxies can only be bound to a specific service instance. In DDS terms, that implies a subscriber application can only receive data from a specific publisher application. Such semantics require special coupling between publishers and subscribers that can be implemented with mechanisms such as Partitions and Content Filters.

To limit the amount of processing and resources that Content Filters would require, the DDS Network Binding uses Partitions to bind proxies with service instances. Each ara::com service instance publishes data on a specific Partition named after the Service ID, and each proxy subscribes to data using the Partition named after the Service ID they are bound to. Native DDS applications or tools that may wish to subscribe to data published by different ara::com service instances may subscribe to the specific partition or to the "*" partition.

Mapping Events, Methods and Fields

To map Events, Methods and Fields to DDS concepts, such as Topics and Services, we leverage the mechanisms defined in the OMG DDS and RPC over DDS specifications. With these mechanisms:

• Events map to regular Topics. Such mapping allows existing DDS tools such as HMI systems to visualize AUTOSAR Adaptive systems based on DDS by simply subscribing to the corresponding DDS Topics representing events using the appropriate partition.
• Methods map to DDS Service methods. Each ara::com service is indeed composed of a DDS Service that exposes all the methods that a client application can invoke.
• Fields map to getter and setter methods of a DDS Service follow the same mechanisms as regular methods. Field notifications map to regular Topics that provide the current field value.

All the Topics and DDS entities created to handle communication can be configured according to the corresponding QoS policies.

Benefits of the DDS Network Binding for ara::com

The DDS Network Binding provides ara::com with a comprehensive connectivity solution that has been proven in thousands of deployments across multiple industries. In this sense, DDS introduces:

• Deterministic real-time communication, using the DDS reliability protocol and other QoS policies, such as liveliness and deadline.
• Configurable data distribution, using its rich set of QoS policies.
• Secure communication, leveraging the DDS Security standard with its fine-grained security capabilities.
• Extensible and pluggable infrastructure, based on a transport-independent wire protocol that can be efficiently deployed on top of shared memory, UDP and TCP.

On top of that, the DDS Network Binding enables AUTOSAR Adaptive applications to interoperate with existing and future DDS systems.

Upcoming Webinar

On February 12, we will be discussing these topics in a one-hour webinar that will introduce and extend these topics. We will also show RTI’s reference implementation of the DDS network binding and illustrate how it can be easily integrated with DDS ecosystems. In addition, we will also address some of the ongoing efforts to integrate DDS into the AUTOSAR Classic Platform.

To register for the upcoming webinar, please follow this link.

About the author

Fernando Garcia-Aranda is a Principal Software Engineer at Real-Time Innovations (RTI) and a PhD Student at the University of Granada. He holds a BSc in Computer Systems Engineering from the University of Cordoba and a MSc equivalent degree in Computer Engineering from the University of Granada. He is an active member of the Object Management Group® (OMG®), where he has authored a number of adopted specifications, and chairs several revision and finalization task forces. He is also a member of the AUTOSAR Consortium where he led the integration of DDS in the new AUTOSAR Adaptive Platform for automotive systems. His research interests include peer-to-peer and data-centric architectures, deterministic networking and distributed IIoT systems.