zurück zum Artikel

AUTOSAR: Chance der Softwareentwicklung im Automotive-Bereich

Mario Friedrich, Olaf Kindel, Alexander Neumann

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.

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 [1] (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 AUTOSAR-Architektur (Abb. 1)

Die Basissoftware enthält

OSEK [2]

Ü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.

Das Potenzial von AUTOSAR

Neben der grundlegenden Herausforderung, Software für Steuergeräte mit extremen Ressourceneinschränkungen entwickeln zu können, und durch die exakte Beschreibung des Verhaltens der Module und ihrer Schnittstellen bietet AUTOSAR Vorteile, die sich aus den grundlegenden Konzepten ergeben, welche die Spezifikation verfolgt:

Mehr Infos

Neuerungen mit AUTOSAR 4.0

  • Ausbau der AUTOSAR-Methodik, die Aktionen und daraus entstehende Arbeitsprodukte beschreibt. Die Methodik wird dann im jeweiligen unternehmensspezifischen Prozess abgebildet
  • Erweiterung der Templates, mit denen in AUTOSAR von der Systemebene bis zum Konfigurationsparameter eines ausgewählten Moduls auf einer konkreten ECU "fast alles" beschreibbar ist
  • Verbesserung von Messungen und Kalibrierung
  • Vervollständigung des ECU Resource Template
  • Weitere Anpassung an das Field Bus Exchange Format (FIBEX)

Mit AUTOSAR kann sich ein Zulieferer von vielen "Lasten" der Softwareentwicklung befreien und sich auf seine Kernkompetenzen konzentrieren. Die wichtigsten liegen typischerweise in Bereichen wie der Abstraktion der Steuergeräte-Hardware (on-board devices), der Ansteuerung der Sensoren und Aktoren sowie der Implementierung der Regelungsalgorithmen.

Entlastung findet der Zulieferer beispielsweise durch die folgenden Entwicklungsaufgaben:

Hinzu kommt, dass das nicht nur den Zulieferer entlastet, sondern die gesamte Softwareentwicklung. Experten wie die Hersteller von Prozesoren oder die von Kommunikations-Controllern können die notwendigen Treiber einmal entwickeln und dann einer Vielzahl von Zulieferern bereitstellen. Das reduziert letztlich den Testaufwand für den Integrator bis auf den Integrationstest.

Wieso jetzt einsteigen

Um die Frage zu beantworten, empfiehlt es sich, Hype- und Softwarelebenszyklus in Verbindung zu bringen. Der Hype-Zyklus [3] stellt dar, welche Phasen der öffentlichen Aufmerksamkeit eine neue Technik bei ihrer Einführung durchläuft. Den Begriff prägte die Gartner-Beraterin Jackie Fenn, weshalb er auch unter dem Namen Gartner's Hype-Cycle [4] bekannt ist. Der Software-Lebenszyklus beschreibt Phasen, die eine Software durchläuft – von ihrer Planung über die Implementierung und Wartung bis hin zum Tag, an dem die Software eingestellt wird.

Bei AUTOSAR handelt es sich zwar nicht um eine Software, sondern um eine Spezifikation für Software, als Abbildungsgrundlage ist der Software-Lebenszyklus dennoch gut geeignet. Er besitzt beispielsweise gegenüber dem Produktlebenszyklus den Vorteil, dass er vor der Markteinführung beginnt. Des Weiteren gibt es keine "speziellen" Spezifikationslebenszyklen. Die Definitionen haben zumindest einen anderen Fokus. Sie gehen auf das Erstellen der Dokumente, das Durchführen von Reviews und ihre Freigabe ein. Die "internen Phasen" sind für die Beantwortung der Frage, ob man jetzt einsteigen soll, nicht von Bedeutung. Da AUTOSAR bereits in Version 3.1 vorliegt, lässt sich von einem ausgereiften Dokumentenerstellungsprozess ausgehen.

Die Abbildung der AUTOSAR-Spezifikationsphasen auf die Software-Lebenszyklusabschnitte erfolgt wie folgt:

  1. Planung: Festlegen der Ziele und Ableiten der Aufgaben, Akquise von Partnern, um die Ressourcen bereitzustellen,
  2. Design: Entwickeln der Architektur mit Modulen und Schnittstellenkonventionen,
  3. Implementierung: Spezifikation der einzelnen Module,
  4. Deployment: Anwendung der Spezifikation in Automotive-Softwareprojekten undMaintenance: Wartung (Fehlerbereinigung und Optimierung).

Die beiden Zyklusmodelle lassen sich in der Praxis dazu nutzen, Aussagen zur aktuellen Situation treffen zu können, um daraufhin die Planung für das weitere Vorgehen anzupassen. Der Hype-Zyklus zeigt an, wann der beste Einstiegszeitpunkt ist. Die Herausforderung besteht jedoch darin, zunächst festzustellen, an welcher Stelle des Zyklus man sich befindet. Ist sie eher Position 2 (Gipfel der überzogenen Erwartungen) oder schon Position 7 (Pfad der Erleuchtung, der in das Plateau der Produktivität führt)? Die aktuelle Position festzustellen erfolgt im Folgenden durch die Kombination von Hype- und Lebenszyklus sowie weiterer unten beschriebener Faktoren.

Wie der Titel des Artikels erahnen lässt, führt der Beitrag Fakten auf, die zeigen sollen, dass der Verlauf genau wie in 3 ist. Das würde somit bedeuten, das aktuell der ideale Zeitpunkt zum Einstieg für eigene AUTOSAR-Projekte ist (Position 7 – Anfang des "Slope of Enlightenment").

Die Indikatoren stellen sich wie folgt dar: Nachdem AUTOSAR eine längere Phase aus Planung, Design und Spezifikation (Implementierung) erster wichtiger Module durchlaufen hatte, veröffentlichte die Initiative 2005 die Version 1.0. Danach begann das Interesse an AUTOSAR stark zu wachsen. Während man die Spezifikation weiterentwickelte (AUTOSAR 2 und 3 in den Jahren 2006 und 2008), hatte sich das Thema zu einem Hype entwickelt. Überall sprach man von AUTOSAR und startete mit Hochdruck eigene Projekte. Der Einstieg in das Thema war zu diesem Zeitpunkt teilweise zu früh, sodass einige Unternehmen ihre hoch gesteckten Ziel wieder korrigieren mussten. Es gab damals noch keinen wirklichen Markt, auch wenn erste Prototypenprojekte den Beginn eines neuen großen Markts vermuten ließen.

Daraufhin fanden erste Marktbereinigungen statt. Einige Firmen stellten AUTOSAR-Produktlinien wieder ein oder Akquisitionen fanden statt. So übernahm Anfang 2006 Vector die 4m-Softwareabteilung der Micron Electronic Devices AG, die zu dieser Zeit die Software-Modulsammlung MICROSAR entwickelte. Dadurch vervollständigte Vector sein Angebot an AUTOSAR-Basissoftwaremodulen.

Andere Unternehmen versuchten, Kosten zu reduzieren, indem sie unterschiedlich geartete Kooperationen eingingen. Ein Beispiel ist die Partnerschaft zwischen der dSPACE GmbH in Paderborn und der Elektrobit (EB) Automotive GmbH in Erlangen. Die 2008 geschlossene Kooperation dient dazu, eine möglichst umfassende AUTOSAR-Basissoftware und -Toolkette aus einer Hand anzubieten. Dabei deckt Elektrobits tresos die Erstellung und Konfiguration der Basissoftware ab, dSPACEs SystemDesk ist für die Applikationsebene und den Systementwurf zuständig.

Ein weiteres bekanntes Beispiel ist Artop, die von einer User Group entwickelte Artop [5] AUTOSAR Tool Platform. Sie eignet sich für die Erstellung eigener Tools. Die 2008 ins Leben gerufene Initiative ist für alle AUTOSAR-Mitglieder offen. Der Anstoß, sie zu nutzen, war die Einsicht vieler AUTOSAR-Tool-/Softwarehersteller, dass die Eigenentwicklung einer weitgehend vollständigen AUTOSAR Entwicklungsumgebung eine hohe finanzielle Herausforderung darstellt.

Betrachtet man den Lebenszyklus an der Stelle, zeigt auch er, dass ein Einstieg nur mit äußerster Vorsicht erfolgen konnte, denn die AUTOSAR-Spezifikation befand sich zu dieser Zeit noch voll in der Implementierungsphase. Das führte schnell zu hohen Kosten, um die AUTOSAR-Produkte immer wieder auf das neueste AUTOSAR-Release "zu heben". Der dafür nötige Aufwand war damals kaum abschätzbar. Mittlerweile gehen alle deutschen OEMs dazu über, AUTOSAR in Serienprojekten einzusetzen.

Das Hype-Thema AUTOSAR hat Einzug in die Grundanforderungen der Automotive-Softwareentwicklung gehalten. Bewegt man sich heute über eine Messe wie die Embedded World, steht nicht mehr an jedem Stand "AUTOSAR", denn das Thema stellt nichts Besonderes mehr dar. Betrachtet man beispielsweise die Vorträge des "Fachkongresses Echtzeitentwicklung 2009 [6]", ist zu konstatieren, dass AUTOSAR in keinem Titel erscheint, jedoch im Inhalt jedes Vortrags.

Bezieht man den Produktlebenszyklus nochmals in die Betrachtungen ein, zeigt er, dass genau jetzt, Ende 2009, der optimale, vielleicht schon letztmögliche Einstiegszeitpunkt für eigene AUTOSAR-Projekte ist. Denn es findet ein Wechsel von der Spezifikations- und Anwendungs- hin zur Anwendungs- und Wartungsphase statt. Klare Indikatoren, dass die Position im Produktlebenszyklus erreicht ist, sind unter anderem:

Die AUTOSAR-Spezifikation ist stabil und schwenkt in die Wartungsphase ein. Alle deutschen OEMs setzen mittlerweile AUTOSAR in Serienprojekten ein. Die häufig gestellt Frage nach dem optimalen Zeitpunkt für den Einstieg in AUTOSAR lässt sich klar beantworten mit: "Wer jetzt nicht einsteigt, kommt zu spät." Da Automotive-Softwareunternehmen nicht jede Woche neu entstehen, sondern sich über Jahrzehnte am Mark etablieren, scheint das Wort Einstieg etwas zu "euphorisch". Einstieg bedeutet hier eher "umsteigen" oder "umstellen" .

Mario Friedrich
ist seit 2006 bei der ICT Software Engineering GmbH im Bereich AUTOSAR tätig. In diesem Rahmen vertritt er seit 2007 die Volkswagen AG in unterschiedlichen AUTOSAR-Arbeitspaketen.

Olaf Kindel
konzentriert sich bei der ICT Software Engineering GmbH auf die Bereiche Geschäftsprozessmanagement und prozessorientiertes Software Engineering in Automotive-Projekten.

(ane [10])

URL dieses Artikels:
https://www.heise.de/-861055

Links in diesem Artikel:
[1] http://www.autosar.org
[2] http://www.osek-vdx.org/
[3] http://de.wikipedia.org/wiki/Hype-Zyklus
[4] http://www.gartner.com/resources/130100/130115/gartners_hype_c.pdf
[5] http://www.artop.org/
[6] http://www.inchron.de/news/echtzeitkongress.html
[7] http://www.dpunkt.de/buecher/3015.html
[8] http://www.dspace.de/shared/data/pdf/ankon2007/01_daimlerchrysler_dziobek_wohlgemuth_d.pdf
[9] http://www.autosar.org/download/media_release/02_AUTOSAR_MEDIA_RELEASE_2009_GER.pdf
[10] mailto:ane@heise.de

Copyright © 2009 Heise Medien