Einführung in die Grundlagen von AUTOSAR

Überblick

Der Begriff AUTOSAR ist aus den Worten AUTomotive Open System ARchitecture zusammengesetzt. Es handelt sich um einen umfangreichen Standard, der die Entwicklung von Steuergerätesoftware im Automotiveumfeld festlegt. Der Standard wird sicherlich eine große Rolle bei zukünftiger Software für Steuergeräte spielen, da er viele Vorteilen gegenüber den klassischen Ansätzen bietet.

Dieser Artikel soll eine (relativ) kompakte Aufbereitung der Grundlagen von AUTOSAR bieten, die in den sehr umfangreichen Dokumenten auf der AUTOSAR-Homepage frei zugänglich sind.

Obwohl die Methodik von AUTOSAR einen der Grundpfeiler des Standards darstellt, wird darauf nur am Rande eingegangen. Vielleicht finde ich zukünftig ein bischen Zeit, um auch darüber einen Artikel zu schreiben. ;-)

Entstehung und Ziele von AUTSOAR

Im Jahr 2002 schlossen sich einige namhafte Automobil-OEMs und Zulieferer zu einer Entwicklungspartnerschaft zusammen. Ziel war es eine Software-Architektur zu standardisieren, die den stetig wachsenden Anforderungen der Kunden und des Gesetzgebers besser gewachsen ist. Die klassischen Ansätze besitzen aus heutiger Sicht einige ungünstige Eigenschaften:

Daraus folgt, dass die Wiederverwendbarkeit von Softwareteilen eingeschränkt ist. Die Wartung und Erweiterung einer Software gestaltet sich unter diesen Umständen ebenfalls schwierig.

Die oben aufgezählten Schwächen sollen mit AUTOSAR ausgeräumt werden. Der Standard definiert eine modulare Softwarearchitektur, bei der die einzelnen Schichten jeweils eine definierte Schnittstelle besitzen. Zudem wird durch das Schichtenmodell erreicht, dass die eigentliche Anwendung hardwareunabhängig implementiert werden kann.

Ein weiteres Ziel ist die Etablierung eines Standardstacks, der unnötigen Entwicklungsaufwand vermeidet und dafür sorgt, dass die Entwicklungsingenieure das Rad nicht immer wieder neu erfinden müssen. Standardfunktionalität wird durch den Stack bereitgestellt. Damit wird man dem Slogan der AUTOSAR-Gemeinschaft gerecht:Cooperate on standards - compete on implementation.

Das Schichtenmodell

Abbildung 1 zeigt eine vereinfachte Darstellung der Software-Layer die durch den AUTOSAR-Standard spezifiziert sind. Wir werden später noch sehen, dass die Basissoftware (BSW) aus weiteren Komponenten besteht.

SoftwarearchitekturenAbbildung 1: AUTOSAR-Architektur als Schichtenmodell

Im vorherigen Abschnitt wurde erwähnt, dass jede Schicht bzw. Komponenten ihrem direkten Nachbar eine standardisierte Schnittstellen in Form eines Application Programming Interface (API) anbietet. Die APIs ermöglicht die Kommunikation zwischen den einzelnen Schichten und falls vorhanden deren Komponenten. Dabei darf keine Schicht übersprungen werden.

AUTOSAR definiert drei unterschiedliche API-Arten:

Jede dieser Schnittstellen-Art ist für eine bestimmte Aufgabe vorgesehen und wird dementsprechend durch den Standard vorgegeben. Für die Funktionsprototypen der AUTOSAR Interfaces ist ein bestimmtes Muster festgelegt. Ein Beispiel für ein solches Muster ist RteWrite<Port>_<Data>(...). Die Standardized Interfaces sind fest vorgegebene Funktionsprototypen. Die Funktion Schedule() ist solch eine Standardized Interface Funktion. Die Standardized AUTOSAR Interfaces unterscheiden sich von den AUTOSAR Interfaces nur durch ihre Verwendung: Sie werden ausschließlich von einer bestimmten Komponente, nämlich der Servicekomponente der BSW, angeboten.

Virtual Function Bus

Bei der Planung einer AUTOSAR-konformen Steuergerätesoftware werden in einem Zwischenschritt alle Softwarekomponenten durch den Virtual Function Bus (VFB) miteinander verbunden. Dabei ist unerheblich, ob sich die Softwarekomponenten später auf dem gleichen Steuergerät befinden werden oder auf einem anderen. Wichtig ist nur, das alle Steuergeräte die eine Softwarekomponente eines VFB erhalten bussystemseitig miteinader verbunden sind. Ein VFB ist beispielhaft in Abbildung 2 dargestellt.

Virtual Function BusAbbildung 2: Der Virtual Function Bus

Der VFB hat einen rein symbolischen Charakter und erlaubt die abstrakte Beschreibung der Kommunikation zwischen Softwarekomponenten. Damit kann jede Softwarekomponente inklusive ihrer Schnittstelle spezifiziert und implementiert werden.

Softwarekomponenten, Runnables und Ports

Beim VFB sind Softwarekomponenten (SW-C) schon kurz angesprochen worden, ohne sie jedoch zu erklären. Bei einer SW-C handelt es sich um ein atomares Softwaremodul. Atomar bedeutet an dieser Stelle das eine SW-C nicht auf mehrere Steuergeräte verteilt werden kann. Die AUTOSAR Spezifikation definiert drei Arten von Softwarekomponenten: