AUTOSAR – Part 2: Adaptive Platform

This article series consists of two parts: the first part discussed the AUTOSAR Classic Platform, which focuses on deeply embedded ECUs based on microcontrollers.

Motivation

The digitization of automobiles has not stopped with highly embedded devices. Rather, it led to further growth which is enabled by new dedicated hardware. Under the umbrella of autonomous driving, additional higher order functions will be integrated into future cars.

The Classic Platform aims at the C programming language and small, highly-embedded devices. The Adaptive Platform targets one abstraction level higher. This includes more powerful hardware. Both are needed to enable more complex use cases. Therefore, the Adaptive Platform uses the C++ programming language, starting with the C++11 and C++14 standards. The target hardware are powerful single-board PCs running a POSIX PSE51 compliant operating system with multi-core CPUs and possibly high-performance computing (HPC) capabilities.

Standard

The Adaptive Platform is positioned between the world of deeply embedded ECUs (will stay with Classic) and the world of infotainment devices (which might stay as-is, or converge even more with the mobile market). Slightly looser real-time requirements are to be handled, but millisecond delays are acceptable. Higher performance of used hardware (multi-core CPUs, HPC dedicated hardware) enables more demanding features.

Another difference between classic and adaptive: planned dynamics. In the Classic Platform, variability often has to be handled at compile-time, which means during the development of an ECU. In contrast, the Adaptive Platform supports run-time service discovery. The degree of flexibility that is actually allowed (only a pre-configured service instance may be discovered, or full open discovery) can be specified per SWC.

Architecture-wise, the Adaptive Platform follows a similar principal pattern as the Classic Platform: a layered architecture is standardized, offering largely hardware-agnostic APIs and services to applications. The following figure summarizes this graphically. The AUTOSAR Runtime for Adaptive Applications (ARA) becomes the spiritual successor of the RTE from the Classic Platform, offering a vast set of libraries and services. A so-called Adaptive Application is one that is only relying on these functions and becomes fully portable. For demanding use-cases, non-portable dependencies (e.g., on dedicated hardware) may be introduced, but with reduced portability among compatible ECUs.

Architecture of the AUTOSAR Adaptive Platform. Reproduced after Figure 3-1 from Explanation of Adaptive Platform Design, p.13.

Adaptive Platform Foundation

The foundation consists of 11 functional clusters, which can be loosely grouped into three categories: basic functionality, communication, and safety and security.

Basic functionality

Execution Management (ara::exec) deals with the state of applications and the ECU as a whole. After power-on and kernel boot, it starts the system initialization and controls launch and termination of all other application software components. It is highly configurable through manifests, which allow for machine-state dependent sets of active applications. For ease of use, related applications can be bundled in function groups for common execution properties.

Operating System Interface (n/a) specifies functionalities that cannot be efficiently implemented by the Adaptive Platform itself, but by the hosting operating system. These functionalities are (a) PSE51 compliance, (b) basic resource management for memory and CPU, and (c) support for time-triggered execution. This functional cluster also ensures that the operating system hands over control to Execution Management when the host system has been initialized.

Logging and Tracing (ara::log) provides APIs to Adaptive Applications and the rest of the platform to log events. It supports severity levels (debugging, informative, warning and error) and the concept of contexts and logger IDs to group and filter messages.

Persistency (ara::per) offers permanent storage for (read-only) configuration data, reading and writing of application-specific data formats. Feature-wise, it supports error detection and correction. Both file-based and key-value APIs are offered.

Time synchronization (ara::tsync) allows applications to set and retrieve a common time base. This functional cluster does not provide a time base itself but allows its users to act either as a time provider (master) or requester (slave). Different time bases (local, global, synchronized) allow clients to either maintain their own time base, or be synchronized within or among different ECUs.

Communication

Communication Management (ara::com) provides the basis for a service-based communication among applications and with platform services. It defines Service Interfaces, which are a flexible coupling mechanism to define provided and required interfaces. These interfaces can be methods (think: remote procedure calls), fields (read-writeable shared memory) and events (read-only notifications). Ports allow grouping multiple interfaces together. Communication management abstracts from the underlying protocol or bus (such as vSOMEIP and CAN).

Restful communication (ara::rest) offers an orthogonal communication paradigm that is less connection or service-based, but inspired by web-based stateless APIs. This functional cluster offers the basic building blocks to create Adaptive Applications that offer a REST-ful service (server part) or interact with another service (client part).

Safety and Security

Identity & Access Management (ara::iam) provides mechanisms akin to permission management which allows to grant or deny access from Adaptive Applications to the Adaptive Platform Foundation and Services.

Cryptography (ara::iam) provides a standardized interface to access implementations of multiple cryptographic algorithms. These include random number generation, hashing algorithms, and several symmetric and asymmetric cyphers.

Platform Health Management (ara::phm) allows the supervision of Adaptive and Platform Applications by using the APIs of Execution Management. In case of failure, specific actions can be configured. Possible actions include the restart of applications, or a state change within an application, function group or ECU.

Adaptive Platform Services

As of release R18-03, there are four specified Adaptive Platform Services:

Diagnostics (ara::diag) offers services as specified in Unified Diagnostics (UDS, ISO 14229) and Diagnostics over IP (DoIP, ISO 13400). This includes the concepts of Diagnostic Events, including errors, warnings or failures, and Diagnostic Communication, which deals with the transfer of the aforementioned events from the source to a persistent storage.

Signal-to-Services Mapping (ara::s2s) provides a compatibility layer towards the Classic Platform. It translates signals from the Classic to services in the Adaptive Platform. So, interoperability between CP and AP software components can be realized.

Network Management (ara::nm) deals with the status management of any connected bus, possibly keeping the bus alive if needed for time-critical communication.

State management (ara::sm) is responsible for defining the current active state of the ECU. For finer granularity, so-called functional groups allow separate state transitions for groups of functional clusters and/or Adaptive Applications. In case of a state change request, it triggers Execution Management for performing the necessary changes.

Update & Configuration Management (ara::ucm) provides means to install new and upgrade existing software components on ECUs. Both over-the-air (OTA) and workshop-based (through diagnostic devices) use cases are supported.

Demonstrator

With the Adaptive Platform, AUTOSAR has widened its scope from only creating specification. In addition to the previous working mode of publishing and maintaining a corpus of specification documents, the consortium has opted to accompany the specification release with an illustrative demonstrator codebase of what an Adaptive Platform basic software stack could look like in practice. However, this Adaptive Platform Demonstrator (APD) is not vetted for production use. While the specification documents are public, the Demonstrator codebase is accessible only to registered AUTOSAR partners, either via a static release (R17-03, R17-10, R18-03), or the latest development version.

Implementations

As with the Classic Platform, a software stack is needed to use AUTOSAR in production. The following table lists manufacturers that offer or have announced to offer an Adaptive Platform software stack: 

Roadmap

AUTOSAR is currently preparing for release R18-10 at the end of October 2018. This date also marks the transition of the work mode, as shown in the figure below. The standard development will switch from the current development phase to a more stable evolution phase. From that date on, the release cycles of the Classic (CP) and the Adaptive Platform (AP) will be synchronized. This change will make it easier to roll out new features impacting both platforms simultaneously.

Adaptive Platform release schedule. Maturity level increasing until R18-10, then stable quality while feature releases continue. R18-10 is planned to be synchronized with Classic Platform release 4.4.0. Derived from Adaptive Platform Release Overview, pp.4.