Implementing AUTOSAR’s DDS Network Binding

By Emilio Guijarro, automotive applications engineer, RTI

AUTOSAR 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. Questions arise such as: What is DDS Network Binding? As well as questions around the challenges with DDS and the AUTOSAR type system, efficient memory management and compliance.

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.

RTI has been and continues to be a key contributor to the specification, maintenance and evolution of the Data Distribution Service (DDS) Network Binding, which enables AUTOSAR Adaptive applications to interoperate with existing and future DDS systems.

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

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.) 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

As RTI’s involvement in AUTOSAR Adaptive now goes beyond standards publishing, it includes the specification, maintenance and further development of the DDS network binding that enables AUTOSAR Adaptive applications to interoperate with existing and future DDS systems. The goal is to enable easy setup and operation in any environment, as well as flexibility for all types of network bindings, and thus also to be independent of AUTOSAR third-party vendors.

 

https://www.rti.com/industries/automotive

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

 

 

 

Caption: RTI Connext Drive architecture