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 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 will present the newer Adaptive Platform, which targets more powerful board computers for higher-level functions.

 

AUTOSAR Classic Platform

Motivation

Since the 1980s, cars have gained more and more features through the power of electronics. Each feature usually consisted of one or several sensors/actuators and an ECU. The ECU usually implements a crucial piece of control logic through a small piece of software. Implemented features range from safety systems, 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.

 

The Standard

The changes outlined above lead to a consortium of car manufacturers to cooperate on the the first version of a common standard. In 2004, the first major release 1.0 was published, the latest minor release 4.3.0 in 2016. In between, the standard has improved in maturity and gained additional features.

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:

 

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 on 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, like non-volatile memory (EEPROM, Flash), communication (CAN, LIN, Ethernet, FlexRay), and I/O (ADC, PWM, 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 basic software 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 be able 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 basic software (BSW) components must be implemented and provide interfaces compliant with the specification. Most commercially available stacks fall into this conformance class.

 

Implementations

The standard defines the structure and interfaces of Basic Software (BSW) and the methodology for the exchange of interface definitions, but does not provide any implementation. Implementations of the AUTOSAR standard are provided by software suppliers. The following table gives a short summary of major stack vendors, based on a more extensive list found on automotive.wiki:

Vendor	Stack	Latest release	Targeting
ArcCore	Arctic Core	2017	4.0.2–4.1.1
Elektrobit	EB tresos AutoCore	2018	3.x–4.3
ETAS	RTA-RTE	Apr 2018	3.x–4.x
KPIT	K-SAR	—	3.x–4.x
Mentor Graphics	Volcano VSTAR	—	4.0.3–4.2
Vector	MICROSAR	May 2018	3.x–4.3