AUTOSAR: Chance der Softwareentwicklung im Automotive-Bereich
Die AUTOSAR-Initiative zur Spezifikation einer Softwarearchitektur zeigt, wie sich im Automotive-Bereich Schnittstellen und Module programmieren lassen. Die Plattform ist seit Jahren stabil, und Softwareunternehmen sollten spätestens jetzt auf sie umsteigen.
- Mario Friedrich
- Olaf Kindel
- Alexander Neumann
Die AUTOSAR-Initiative zur Spezifikation einer Softwarearchitektur gibt Herstellern und Zulieferern im Automotive-Bereich einen Weg vor, wie sich Schnittstellen und Module programmieren lassen. Die Plattform ist seit Jahren stabil, und Softwareunternehmen sollten spätestens jetzt auf sie umsteigen.
AUTOSAR (AUTomotive Open System ARchitecture) ist ein 2003 initiierter Standard, den eine internationale Entwicklungspartnerschaft aus mittlerweile über 140 Automobilherstellern und Zulieferern trägt. Das "Produkt" der Zusammenarbeit ist eine Spezifikation, die inzwischen in Version 3.1 vorliegt. Sie deckt unterschiedliche Bereiche der Softwareentwicklung im Automotive-Bereich ab. Zum einen stellt sie Anforderungen an die Softwareentwicklung durch die Spezifikation konkreter Schnittstellen für Module wie Betriebssystem und Treiber. Zum anderen nimmt sie als Methode Einfluss auf den Softwareentwicklungsprozess. So beschreibt sie, welche Aktionen aus einem Softwaremodell auf der
Systemebene (die über alle Steuergeräte im Fahrzeug verteilte Software) die Software der jeweiligen ECU (Electronic Component Unit) ableiten.
AUTOSAR spezifiziert eine Architektur, die Schichten- und Komponentenarchitektur kombiniert. Die Abbildung 1 zeigt eine Schichtenarchitektur auf Basissoftwareebene. Sie abstrahiert von der Hardware und dient den Komponenten auf der Anwendungsebene als Laufzeitumgebung (Runtime Environment; RTE) .
Die Basissoftware enthält
- Module wie die Treiberabstraktion für den Prozessor und die in ihm integrierten Geräte (beispielsweise CAN-Bus-Controller),
- Module, die von der I/O-Hardware des gesamten Steuergeräts abstrahieren (beispielsweise externe CAN-Bus-Controller (Controller Area Network) oder die Kombination mehrerer I/O-Pins zur Ansteuerung eines Motors) und
- Servicemodule, die den übrigen Basissoftwaremodulen und der Anwendungssoftware Dienste bereitstellen (beispielsweise Diagnosemodule oder das Betriebssystem).
Über die AUTOSAR-Entstehung
Viele Automotive-Steuergeräte zeichnen sich durch Eigenschaften wie geringe Rechenleistung, geringen physikalischen Speicher und den Verzicht auf virtuellen Speicher aus. Eine virtuelle Speicherverwaltung lässt sich nicht einsetzen, da sie ihre volle Wirksamkeit erst im Zusammenspiel mit einem externen Speichermedium, zum Beispiel einer Festplatte, entfaltet und außerdem das empfindliche Echtzeitverhalten "zerstört".
Die Ressourcenknappheit erfordert einen bewussten und planbaren Umgang mit den verfügbaren Betriebsmitteln, das betrifft vor allem den verfügbaren Speicher. Hier hat "sparsamer" Umgang oberste Priorität. Weiterhin lässt sich keine dynamische Speicheralloziierung nutzen. Welchen Nutzen hätte es beispielsweise, wenn das ABS-Steuergerät in einer kritischen Situation "out of memory" meldet?
Die Anforderung nach einem planbaren Umgang mit den verfügbaren Betriebsmitteln führt somit dazu, dass der gesamte Speicherverbrauch des Systems zur Übersetzungszeit vollständig bekannt sein muss. Man spricht dann von einem statischen System. AUTOSAR kam zustande, da Betriebssysteme (wie Embedded Linux oder QNX) diese speziellen Anforderungen nicht vollständig erfüllten. Die beschriebenen Ressourceneinschränkungen beruhen auf einem hohen Kostendruck im Automotive-Bereich. Dieser hat wiederum seine Ursache im Potenzial, durch kleine Optimierungen bei hohen Stückzahlen hohe Kosteneinsparungen realisieren zu können. Volkswagen hat beispielsweise 2007 und 2008 jeweils über sechs Millionen Fahrzeuge ausgeliefert. Nimmt man weiterhin an, dass in einem Fahrzeug 50 Steuergeräte verbaut sind, wird klar, dass wenige Cent Einsparung je Steuergerät schnell zu sechsstelligen Summen pro Jahr führen können.
