AUTOSAR Classic
August 2, 2018 | 8:00 pm
CDT
AUTOSAR (AUTomotive Open System ARchitecture) ist eine 2003 gegründete Entwicklungspartnerschaft von Automobilherstellern, deren Ziel es ist, eine standardisierte Softwarearchitektur für elektronische Steuergeräte (ECUs) zu etablieren. Die Mission von AUTOSAR ist
eine Kooperation im Bereich Standards und Wettbewerb bei der Umsetzung.
Die Trennung dieser beiden Ziele führt zu einer Zusammenarbeit einer großen Anzahl an Automobilherstellern und -zulieferern. Außerdem hat sich dadurch ein vielfältiges Ökosystem für die Umsetzung des Standards in Produktionssoftware etabliert.
Dieser Artikel besteht aus zwei Teilen. Im ersten Teil geht es um die Classic Platform für tief eingebettete Steuergeräte auf Grundlage von Microcontrollern. Im zweiten Teil geht es um die neuere Adaptive Platform. Dieser ist hier zu finden.
AUTOSAR Classic Platform
Motivation
Durch die Verbreitung der Elektronik haben Autos seit den 1980er Jahren immer mehr Features erhalten, die normalerweise aus mindestens einem Sensor/Aktor und einem Steuergerät bestehen. Normalerweise setzt das Steuergerät einen wichtigen Teil der Steuerlogik mithilfe einer kleinen Softwarekomponente um. Solche Features reichen von Sicherheitssystemen bis zu Fahrerassistenz- und Beifahrerkomfortfunktionen.
Es liegt auf der Hand, dass sich die Anzahl der Steuergeräte pro Fahrzeug deutlich erhöht hat. Ein handelsübliches Fahrzeug enthält heutzutage über 40 Steuergeräte. So entstand der Wunsch, mehrere Features mit einem Steuergerät abzudecken und damit von der zunehmenden Integration von Halbleitern zu profitieren und Produktionskosten zu senken. Da unterschiedliche Features häufig von unterschiedlichen Herstellern angeboten werden, brauchte es eine gemeinsame Architektur, damit die – früher maßgeschneiderte – Steuergeräte-Firmware portabel werden konnte.
Die folgende Abbildung fasst die übergeordneten Ziele zusammen. Sie stammt aus einem der neu erstellten Grundlagendokumente, deren Inhalte sowohl für die Classic als auch für die Adaptive Platform gelten.
AUTOSAR Projektziele. Zusammenfassung der AUTOSAR Projektziele auf Grundlage der offiziellen Anforderungen, Seiten 7–10.
Der Standard
Die folgende Abbildung zeigt die Layered Software Architecture. Sie zeigt die logische Sicht der AUTOSAR-Struktur und die durch den Standard definierten grundlegenden Softwarekomponenten:
AUTOSAR Classic Platform mit einer aus verschiedenen Schichten bestehenden Softwarearchitektur. Nach dem technischen Bericht AUTOSAR Layered Architecture, S. 21.
AUTOSAR definiert eine Middleware (d. h. alle Schichten zwischen der zugrundeliegenden Hardware, der Mikrocontroller-Schicht) und dem anwendungsspezifischen Code (Anwendungsschicht). Um die Portierung einer Anwendung zu ermöglichen, wird das Konzept der Softwarekomponente gebildet. Eine Anwendungssoftware, die nur in Beziehung zur AUTOSAR Middleware steht, ist vom zugrundeliegenden Steuergerät unabhängig und kann theoretisch in jedes Steuergerät im Zielfahrzeug integriert werden. Dazu bieten die folgenden Middleware-Schichten eine große Bandbreite an Programmierschnittstellen und Diensten. Diese APIs sind zu sogenannten Basissoftware-Komponenten (BSW) zusammengefasst:
Schichten
Der Microcontroller Abstraction Layer (MCAL) bietet Standard-Treiber für vom Mikrocontroller zur Verfügung gestellte Features. Dabei handelt es sich um Treiber für Hardware-Elemente innerhalb des Mikrocontrollers wie etwa nichtflüchtige Speicher (EEPROM, Flash), Kommunikationssysteme (CAN, LIN, Ethernet, FlexRay), oder E/A (ADC, PWM, Pins).
Der ECU Abstraction Layer bietet einen einheitlichen Zugriff innerhalb und außerhalb des Mikrocontrollers. In dieser Schicht befinden sich generische Dienste für Bordgeräte (z. B. Watchdog), Speicherschnittstellen, Kommunikationssysteme sowie E/A-Schnittstellen. Je nach Anwendungsfall werden diese Schnittstellen entweder von den Hintergrunddiensten oder von Softwarekomponenten in der Anwendungsschicht verwendet.
Der Services Layer stellt verschiedene Dienste wie Fehlermanagement, eine abstrakte Speicherschnittstelle und Kommunikationsmanagement bereit.
Diese drei Schichten werden weiter in sogenannte Funktionsgruppen unterteilt, die BSW-Komponenten schichtenübergreifend bündeln. Diese Gruppen stellen Dienste für Kommunikation, Diagnose, Logging, Speicherung und Netzwerkmanagement zur Verfügung.
Die oberste Schicht, die Runtime Environment (RTE), ist die Laufzeitumgebung der AUTOSAR Softwarekomponenten (SWC). Eine valide SWC beruht ausschließlich auf den von der RTE bereitgestellten Schnittstellen. Diese Schnittstellen sind hochgradig anwendungsabhängig und werden von einem speziellen RTE-Generator erstellt.
Die spezielle Schicht, der Complex Device Driver, ist eine extrem leistungskritische Softwarekomponente oder Legacy-Software, mit der die Schichtenarchitektur umgangen wird. Dafür können Complex Device Driver von allen Schichten aus direkt auf die grundlegenden Softwarefeatures zugreifen.
Die Methode
Wie oben beschrieben, definiert die Spezifikation der AUTOSAR Classic Platform lediglich, welche Programmierschnittstellen ein Softwarestack bereithalten muss. Um zwischen den verschiedenen Erfüllungsebenen eines Softwarestacks zu unterscheiden, definiert AUTOSAR drei Konformitätstestklassen:
Konformitätsklasse ICC1 beschreibt die Einhaltung des Standards durch externes Verhalten. Dies besteht aus Zugang zur obersten Schicht, also zur RTE und zur Bus-Kommunikation. Die interne Struktur aller BSW-Komponenten kann dann auf die jeweilige Umsetzung angepasst werden. Dies eröffnet eine Vielzahl von Möglichkeiten zur Leistungsoptimierung und die Möglichkeit, sogar kleinste Mikrocontroller (8 oder 16 Bit) in die AUTOSAR-Umgebung einzubinden.
Konformitätsklasse ICC2 erfordert, dass der jeweilige Softwarestack der groben Struktur der geschichteten Softwarearchitektur entspricht.
Konformitätsklasse ICC3 bedeutet, dass alle BSW-Komponenten nach der Spezifikation umgesetzt sein müssen und entsprechende Schnittstellen bereitstellen müssen. Die meisten kommerziell erhältlichen Stacks entsprechen dieser Konformitätsklasse.