Implementing AUTOSAR’s DDS Network Binding

RTI has a long history of participation in AUTOSAR, which stands for AUTomotive Open System ARchitecture. AUTOSAR encompasses a worldwide development partnership of vehicle manufacturers, suppliers, service providers and companies from the automotive electronics, semiconductor and software industries.

For companies building vehicles with AUTOSAR, two different platforms have emerged -- AUTOSAR Classic and AUTOSAR Adaptive -- as well as the Foundation standard that enforces interoperability between the AUTOSAR platforms. RTI’s involvement in AUTOSAR Adaptive is now moving beyond standards publication, not only with leading AUTOSAR software vendors, but also through the internal development of a fully-featured implementation of the Communication Management functional cluster.

For example, RTI has been and continues to be a key contributor to the specification, maintenance and evolution of the Data Distribution Service^TM (DDS) Network Binding, which enables AUTOSAR Adaptive applications to interoperate with existing and future DDS systems. For more on this, you can read a related RTI blog post here.

Our work has been driven since day one to be independent from third-party AUTOSAR companies, easy to build and run in any environment where RTI Connext Drive^® does, compliant with the AUTOSAR standards it has been modelled after, and finally, flexible enough to accommodate all kinds of Network Bindings.

What is the DDS Network Binding?

Within the AUTOSAR Adaptive platform, the Communication Management functional cluster provides service-oriented communications modeling and infrastructure. Application-level APIs are protocol agnostic, and thus built on top of a middleware that is brokering between the APIs and the actual underlying communication technologies.

Such mappings are called “Network Bindings” in AUTOSAR parlance, and only three of these are standardized:

• DDS
• SOME/IP
• Signal-based communications

RTI’s involvement in AUTOSAR Adaptive is now moving beyond standards publication, not only with leading AUTOSAR software vendors, but also through the internal development of a fully-featured implementation of the Communication Management functional cluster (also known as “ara::com”). The present blog post elaborates on key facts, goals and challenges related to this later effort.

Challenges

Designing and implementing Network Binding components for AUTOSAR is in general a complex task, due to various design aspects of the AUTOSAR Adaptive Platform:

1. No standardized API layer exists between Application-facing APIs and Network Binding components, requiring implementers of specific Network Bindings to approach each integration slightly differently
2. AUTOSAR has its own type system that features orthogonal UML and C++ programming language renditions, which must be reconciled by the Network Bindings with the type system and capabilities of each underlying communications technology (i.e., DDS’ own Extensible Types)
3. AUTOSAR also dictates very specific object lifecycle and memory management protocols, which again must be matched against the underlying frameworks encapsulated by the Network Bindings
   
   

Mapping DDS and the AUTOSAR type system

Even though AUTOSAR types are fairly common and map naturally to DDS-XTypes (booleans, numerics, strings, structures, arrays, sequences, etc.)  – and such mapping is already specified in the DDS Network Binding materials within the Communication Management specifications – an actual integration requires bringing together PSMs (Platform-Specific Modules) for both type systems in the C and C++ programming languages. 

Moving forward, we will choose the only language binding supported by AUTOSAR, C++ (up to C++14), and the C language PSM of DDS (the latter for reasons that will become obvious a couple of sections ahead).

Starting with a simple example, here’s how a simple Point3D type might look like after translation from DDS-IDL or DDS-XML to C:

struct Point3D {

        float x;

        float y;

        float z;

};

And then after translation from AUTOSAR’s ARXML to C++:

struct Point3D {

        float x;

        float y;

        float z;

};

Similar, right? Is AUTOSAR/DDS type compatibility then a battle that’s already won? Not so fast. Let’s evolve our type catalog a bit further, grouping 3D points into point clouds that are arranged, for the sake of simplicity, as mere fixed-length arrays. According to the DDS C PSM, this would look like:

typedef Point3D PointCloud[1024];

But the same type (a point array of 1024 elements) would be produced in AUTOSAR Adaptive as follows:

typedef ara::core::Array<Point3D, 1024> PointCloud;

As the reader can see, similar but not identical types have been produced. In fact, ara::core::Array<> preserves some semantics of plain fixed-length array types (such as indexed access), but also adds STL-like semantics like begin() and end() methods, and doesn’t implicitly convert to a Point3D pointer. This gap grows even larger for other types, such as strings and vectors.

In RTI’s ara::com, implementation types for structured, user-defined types via AUTOSAR modeling do not contain value fields, but instead functionally compatible wrappers referencing an internally managed “backend storage”. Such backend storage might be based on Adaptive Platform’s PSM (standard C++ numerical types and ara::core container types) or DDS’ PSM auto-generated types from DDS-IDL or DDS-XML.

This approach not only eases integration with communication frameworks of many natures, but also leaves the door open for efficient memory management and reduction/elimination of sample copies when sharing data, as shown in the next section.

Achieving efficient memory management

With the flexibility of the data type structure described in the previous section, two non-exclusive memory management strategies arise for data samples:

• Implementation type instances may be stack or heap-allocated directly by the application, which causes the internal type implementation to use AUTOSAR’s in-memory PSM types. When passed to the underlying framework, these data types must be converted and/or serialized according to the required target data format (i.e., DDS auto-generated types from DDS-IDL or DDS-XML)
• When seeking zero-copy transfers, applications may also leverage the standard Allocate() method provided by events and field notifiers. In this case, the network binding will, whenever possible, ask the underlying framework to “loan” an internally allocated data sample that will, in turn, be “returned” when filled and sent back by the application

The latter is an extremely powerful mechanism, allowing size-independent constant-time transfers in several scenarios:

• Shared memory transports
• Memory-mapped network interfaces
• Intra-process communication
  
  

Thriving towards compliance

On top of mapping type systems and APIs in a performant way, the automotive product focus of AUTOSAR brings an additional challenge: functional safety compliance.

Assessment of any DDS implementation as a Safety Element out of Context (SEooC) in any ISO-26262 ASIL level is a challenge in itself, which RTI is already successfully addressing in its Connext Drive line of products. Given the nature and expense of functional safety assessments, trading functionality for codebase size and footprint can be a strategic necessity.

Such constraints inform RTI’s ara::com design choices and future AUTOSAR standard directions:

• C is the one and only DDS language PSM allowed in the implementation of DDS Network Bindings, thus allowing easy adaptability for DDS implementations of many varieties (small footprint, safety-aware)
• Multi-binding support is a must, as certainly more than one DDS Network Binding will need to be provided in order to support the aforementioned variety of DDS implementations
• A leaner approach to service discovery and binding features in the AUTOSAR Adaptive DDS Network Binding specification, using common DDS features (topics, instances) that are easier to find in most DDS middleware implementations
  
  

Getting it

If you represent an automotive OEM, Tier-N or AUTOSAR tools supplier and are interested in getting access to our ara::com implementation, please contact sales@rti.com for details on RTI Connext Drive.

About the author

Emilio Guijarro is a software engineer with over 15 years of experience in the defense and automotive industries, including automotive infotainment systems. In 2019 he joined RTI to work on the integration of DDS in automotive use cases and in specific development environments, including the AUTOSAR ecosystem.