AUTOSAR – Part 1: The Classic Platform

AUTOSAR, the abbreviation for AUTomotive Open System ARchitecture, is a collaboration of car manufacturers that was founded in 2003. Its goal is to maintain a standard for software architecture in on-board electronic control units (ECUs). The AUTOSAR mission is:

“Cooperate on standards, compete on implementation.”

This separation of concerns leads to a collaboration of many car manufacturers and suppliers. Additionally, a rich ecosystem for implementing this standard into production software has evolved.

This article series consists of two parts. The first part deals with the Classic Platform which aims at deeply embedded ECUs, based on microcontrollers. The second part, which presents the newer Adaptive Platform, can be found here.

AUTOSAR Classic Platform

Motivation

Cars have gained an increasing number of features through the power of electronics since the 1980s. Each feature usually consists of one or several sensors/actuators and an ECU. The ECU typically implements a crucial piece of control logic through a small piece of software. Implemented features range from safety systems and over driving assistance to passenger comfort.

Logically, the number of ECUs per car increased dramatically. A typical commercial vehicle today contains over 40 ECUs. To benefit from the increasing integration of semiconductors and to reduce production costs, the wish arose to combine several features on a single ECU. As different features are often supplied by individual suppliers, a common architecture had to be provided to them to achieve portability among their — formerly custom-made — ECU firmwares.

Their high-level goals are briefly summarized in the following figure. It stems from one of the new-formed foundation documents, which contain content that is common to both the Classic and the Adaptive Platform.

 AUTOSAR project objectives. Collected from the official requirements document AUTOSAR Project Objectives, pp. 7-10.

The Standard

The figure below demonstrates the common representation of the Layered Software Architecture. It shows the main logical view of the AUTOSAR structure and the Basic Software Components defined by the standard: 

Layered software architecture of the AUTOSAR Classic Platform. Reproduced after technical report AUTOSAR Layered Architecture, p. 21.

AUTOSAR defines a middleware (i.e., all layers between the underlying hardware Layer Microcontroller) and the application-specific code (Application Layer). To make an application portable, the concept of a Software Component is defined. A piece of application software, which only has dependencies to AUTOSAR middleware, is independent of the underlying ECU and can — in principle — be deployed freely to any suitable ECU within the target vehicle. To accomplish this, the following middleware layers provide a broad range of APIs and services. These APIs are grouped in so-called basic software (BSW) components:

Layers

The Microcontroller Abstraction Layer (MCAL) contains standard drivers for features provided by the microcontroller. These are drivers for hardware units within the microcontroller, including non-volatile memory (EEPROM, Flash), communication (CAN, LIN, Ethernet, FlexRay), and I/O (such as ADC, PWM and Pins).

The ECU Abstraction Layer provides a generic way to access features within or outside the microcontroller. At this level, generic services for onboard devices (like a Watchdog interface), memory interface, communication and I/O service interfaces can be found. Depending on the use case, these interfaces are either used by the services layer or by software components in the application layer.

The Services Layer provides high-level services like fault management, an abstract memory interface or communication management.

These three layers are further divided into so-called functional groups, which bundle BSW components across layers. These groups provide services for topics like communication, diagnostics, logging, memory and network management.

The topmost layer, Runtime Environment (RTE), provides the runtime environment for the AUTOSAR software components (SWCs). A valid SWC depends only on the interfaces provided by the RTE. These interfaces are highly application-dependent and generated by a special RTE generator.

The special layer, Complex Device Driver, is an extremely performance-critical software component or legacy software to circumvent this layered architecture. To allow for this, complex device drivers may access basic software features from all layers. 

The Methodology

As stated above, the AUTOSAR Classic Platform specification only defines the APIs a software stack must offer. To differentiate between different compliance levels of a given software stack, AUTOSAR defines 3 different implementation conformance classes:

Conformance Class ICC1 only requires external behavior to comply with the standard. This comprises the top-level RTE access and bus communication. The internal structure of all BSW components can be entirely implementation specific. This offers vast possibilities for performance optimization and the option to integrate even the smallest microcontrollers (8- or 16-bit) into the AUTOSAR environment.

Conformance Class ICC2 mandates that the implemented software stack follows the major structure of the layered software architecture as shown in the layered software architecture.

Conformance Class ICC3 requires that all BSW components must be implemented and provide interfaces compliant with the specification. Most commercially available stacks fall into this conformance class.