Grundlagen der AUTOSAR Architektur

Die Automobilindustrie hat 2003 die Entwicklungspartnerschaft AUTOSAR gegründet, um der explodierenden Kosten, der wachsenden Komplexität und der Vielfältigkeit der verwendeten Herstellungstools zur Entwicklung von Steuergeräte-Software entgegenzuwirken. Damit wurde eine einheitliche Software-Architektur zur Kostenreduzierung, Qualitätsverbesserung und Wiederverwendbarkeit bereits entwickelter Komponenten bereitgestellt, die u. a. anwendungsnahen und hardwarenahen Code trennt sowie eine bessere Vernetzung von Steuergeräten unterschiedlicher Hersteller gewährleistet.

Aktuell gibt es zwei genutzte AUTOSAR Standards: ASR 3 und ASR 4. Grundsätzlich ist bei beiden Standards die Architektur gleich. Allerdings kommen in ASR 4 weitere BSW Module hinzu und beide Standards sind untereinander nur bedingt kompatibel. Eine der wichtigsten Neuerungen in ASR 4 ist die Einführung von Ethernet.

Der ASR Standard wird grundsätzlich in 3 Bereiche aufgeteilt: Methodik, Architektur und Schnittstellen. Ein vierter zusätzlicher Bereich sind die ASR Bibliotheken.

In der Methodik wird der Herstellungsprozess von Steuergeräte-Software beschrieben (Produktsicht, nicht Geschäftsprozesssicht), und über drei Teilaspekte eine teilweise Parallelisierung in der Herstellung erlaubt: Architektur, Kommunikation und Codegenerierung. Übergeordnet über diesen Teilaspekten steht dann noch die Integration.

Die Architektur ist ein Schichtenmodell zur Abstraktion der Software von der ihr zugrunde liegenden Hardware. Sie sieht auf den ersten Blick sehr komplex aus, aber in der Auflösung ihrer Schichten und deren Funktionalität wird sie schnell überschaubar.: Zuunterst liegt die Microcontroller-Schicht, die die Software mit der Hardware verbindet. Darüber liegt die Basissoftware-Schicht, die das Betriebssystem der entwickelten Software beinhaltet. Die darüber liegende RTE-Schicht verbindet sowohl die Basissoftware mit der zuoberst liegenden Applikationsschicht als auch die einzelnen Applikationen untereinander. Mit diesem Schichtenmodell unterliegt also die komplette Kommunikation der einzelnen Software-Bestandteile nicht nur einer allgemein nutzbaren Standardisierung, sondern verhindert insbesondere durch vorgegebene Kommunikationswege einen unbefugten, unkontrollierten oder direkten Zugriff von Softwarekomponenten untereinander.

Eine Ausnahme dieser streng gesteuerten Kommunikation bilden die Complex Driver (auch Complex Device Driver bzw. CDD genannt), mit denen NICHT-standardisierte Funktionalität innerhalb der BSW-Schicht implementiert werden kann. Damit wird unter Umgehung der BSW und der ASR Regeln ein direkter Zugriff der RTE auf den Microcontroller ermöglicht, z. B. für eine schrittweise Migration von vorhandener Software auf den ASR Standard. Oder es können Funktionen umgesetzt werden, die noch nicht im ASR Standard vorgesehen sind. Am wichtigsten ist allerdings die Nutzung für zeitkritische Funktionalität.

Die Basissoftware-Schicht unterteilt sich wiederum in 3 weitere Schichten: Die Microcontroller Abstraktionsschicht, welche die unterste Schicht direkt oberhalb der Hardware ist. Sie enthält die internen Treiber mit direktem Zugriff auf die µC interne Peripherie und den Speicher. Darüber liegt die ECU Abstraktionsschicht. Sie abstrahiert die Eigenschaften des Steuergerätes samt dessen Controller und bietet eine API an, die den Zugang zu Peripherie und Geräten (sowohl µC intern als auch µC extern) ermöglicht, mit allen I/O Signalen, auf welche die Applikationsschicht zugreifen darf. Dieser Schicht werden auch die CDDs zugeordnet, da diese den Applikationen ja einen direkten Hardwarezugriff erlauben. Die höchste Schicht der BSW ist die Service Schicht. Sie beinhaltet das eigentliche Betriebssystem, die Speicherverwaltung, Kommunikation, Diagnose Services und das ECU State und Mode Management. Der größte Anteil der Kommunikation zwischen Basissoftware und RTE findet somit über diese Schicht statt.

Zwischen Basissoftwareschicht und den Software Applikationen liegt die Run Time Environment Schicht. Sie stellt allen Applikationen die Kommunikations-Services zur Verfügung. Das heißt, dass alle Software-Komponenten der Applikationsschicht AUSSCHLIESSLICH über die RTE miteinander, mit der BSW, mit dem Steuergerät oder auch mit anderen Steuergeräten kommunizieren.

Schnittstellen sind streng genommen keine Schicht innerhalb der ASR Architektur, sondern sie sind die vollständige Beschreibung aller technischen Schnittstellen, die zur Herstellung von Steuergeräte-Software auf unterschiedlicher Hardware nötig ist. Innerhalb der ASR Architektur müssen infolgedessen exakt diese Schnittstellen genutzt werden. Sie werden in AUTOSAR Interfaces, Standardized AUTOSAR Interfaces und Standardized Interfaces (mit jeweils unterschiedlichen Aufgaben und Eigenschaften) unterschieden. Interfaces enthalten die Funktionalität, um die Realisierung einer spezifischen Hardware für obere Schichten der ASR Architektur zu abstrahieren und stellen eine generische API für ein spezifisches Steuergerät zur Verfügung, unabhängig der Anzahl dieser Geräte und unabhängig der Hardware-Realisierung unterschiedlicher Geräte. Sie verändern NIEMALS den Inhalt der Daten, die über sie gesendet oder empfangen werden.

Kommunikationswege und Regeln sind im AUTOSAR Standard beschrieben und werden hier zur einfacheren Übersicht nur graphisch dargestellt:

Ebenfalls kein Bestandteil der ASR Architektur sind die AUTOSAR Bibliotheken. Sie sind analog der Schnittstellen nach ASR spezifiziert und können von jedem Element der ASR Architektur gerufen werden und laufen dann in derselben geschützten Umgebung, wie das aufrufende Modul. Selbst können sie nur andere Bibliotheken aufrufen. Beispiele für diese Bibliotheken sind Fixed Point Operationen, Floating Point Operationen, Bit Handling, Checksummen Berechnung, etc.

Sämtliche Abbildungen und Inhalte sind der offiziellen AUTOSAR Spezifikation entnommen und einsehbar in der Beschreibung des AUTOSAR Schichtenmodells für ASR 3.2:

Zur besseren Lesbarkeit wurden die Abbildungen farblich angepasst.