Empfehlungen für den richtigen Umgang mit AUTOSAR Regelgerecht

Vier Jahre nach Gründung der AUTOSAR-Entwicklungspartnerschaft ist mit der aktuellen Version 2.1 der Spezifikation der notwendige Reifegrad für den Serieneinsatz erreicht. Trotz der immer stärkeren Beachtung von AUTOSAR bei OEMs und Zulieferern bestehen nach wie vor einige Unsicherheiten, wie mit AUTOSAR in der Praxis verfahren werden soll. Die folgenden Regeln sind aus praktischen Arbeiten sowie Gesprächen über AUTOSAR entstanden.

Empfehlungen für den richtigen Umgang mit AUTOSAR

Vier Jahre nach Gründung der AUTOSAR-Entwicklungspartnerschaft ist mit der aktuellen Version 2.1 der Spezifikation der notwendige Reifegrad für den Serieneinsatz erreicht. Trotz der immer stärkeren Beachtung von AUTOSAR bei OEMs und Zulieferern bestehen nach wie vor einige Unsicherheiten, wie mit AUTOSAR in der Praxis verfahren werden soll. Die folgenden Regeln sind aus praktischen Arbeiten sowie Gesprächen über AUTOSAR entstanden.

Das Beherrschen des komplexen Entwicklungsprozesses von AUTOSAR erfordert eine ineinandergreifende, individuelle Toolkette aus Design- und Entwicklungswerkzeugen. AUTOSAR-XML ist beispielsweise ohne ein spezielles Design-Werkzeug nicht handhabbar.

Wie in anderen Domänen auch wird aber oft erwartet, dass ein einzelner Hersteller eine allumfassende Toolkette anbieten muss, die dann alle Aufgaben bewältigt. Dies ist jedoch unrealistisch: Zur Unterstützung der spezifischen Prozesse und Anforderungen eines Steuergeräteherstellers ist eine Kombination aus kommerziellen Werkzeugen mit eigenen Erweiterungen oder sogar eigenen Werkzeugen wie Generatoren, Editoren oder Schnittstellen vonnöten.

Wie bereits häufig verbreitet, wird durch AUTOSAR das Denken in konkreten Steuergeräten durch das Denken in Funktionen ersetzt. Viele OEMs beginnen bereits beim Aufbau der Systemarchitektur mit dem Funktionskatalog, der im Prinzip keine Rücksicht auf Steuergerätegrenzen nimmt.

Damit tritt das Steuergerät in den Hintergrund: Funktionen werden in AUTOSAR-Applikationskomponenten umgesetzt und diese dann auf den verfügbaren Steuergeräten integriert. Damit werden wiederverwendbare Funktionen genauso möglich wie die unterschiedliche Zusammenstellungen abhängig vom Fahrzeugtyp.

Weitreichende Möglichkeiten auf der Applikationsebene

Die üblichen Darstellungen der AUTOSAR-Architektur zeigen detailliert den Aufbau der Basissoftware, während die Applikationen oberhalb der RTE als einfache, gleichberechtigt nebeneinander stehende Software-Blöcke erscheinen. Diese Darstellung ist zwar technisch korrekt, allerdings kann dabei leicht übersehen werden, welche weitreichenden Möglichkeiten diese Komponentenarchitektur auf Applikationsebene bietet.

Die logische Struktur der Applikationskomponenten ist keineswegs flach, sondern durch komplexe Abhängigkeiten und Hierarchien geprägt. So kann es zum Schutz des eigenen Know-hows sinnvoll sein, eine Komponente zu entwerfen, die nach außen hin eine offengelegte, funktionsorientierte Schnittstelle anbietet, darüber hinaus aber nichts über ihre interne Funktionsweise erkennen lässt. Das Innere dieser Komponente kann und sollte dann weitere, hierarchisch strukturierte Komponenten beinhalten, die sich nicht zufällig ergeben, sondern durch bewusste Architekturarbeit entworfen werden. Alle Methoden guter Architektur, wie das gezielte Planen von Abhängigkeiten und Varianten, lassen sich hier anwenden und erhöhen die Software-Qualität erheblich, vor allem die Wart- und Erweiterbarkeit.

Stärker als in der bisherigen Steuergeräte-Entwicklung setzt AUTOSAR auf bewährte Konzepte der Informatik. So spielt beispielsweise das explizite Beschreiben von Schnittstellen und Daten auf verschiedenen Abstraktionsebenen eine große Rolle. Während bisher häufig nur auf einer maschinennahen Implementierungs-Ebene programmiert wird (z.B. uint8), müssen diese Entwickler nun auch die anderen Abstraktionsebenen kennen, trennen und anwenden (z.B. AUTOSAR-Datentypen wie Integer, limits = [0;4] und deren Semantik wie 0: door closed).

Das vorhandene Know-how aus der Entwicklung hochoptimierter Steuergeräte wird dadurch keineswegs hinfällig. Vielmehr ist eine enge Zusammenarbeit von Fachleuten mit verschiedenen Schwerpunkten wichtig. AUTOSAR trägt dazu durch die Vorgabe einer gemeinsamen Sprache wesentlich bei. Auch die Verteilung der Rollen und Zuständigkeiten kann durch die AUTOSAR-Vereinbarungen klarer gefasst werden:

  • Architekten: entwerfen Strukturen und Abläufe primär oberhalb der RTE.
  • Funktionsentwickler: setzen Kundenanforderungen mit Domänenwissen um.
  • Basis-Software- und Hardware-Entwickler: stellen die Funktionsentwicklung auf eine tragfähige und effiziente Basis.

Durch die Anwendung des Komponentenkonzeptes ermöglicht AUTOSAR Unit-Tests auf der Ebene der Applikationen. Ein Unit-Test prüft immer nur einen sehr kleinen und autarken Teil des Software-Systems, wie beispielsweise eine einzelne Funktion, Schnittstelle oder Software-Komponente. In der Software-Entwicklung werden Unit-Tests direkt von den Software-Entwicklern parallel zur eigentlichen Entwicklung implementiert und ausgeführt. Grundlegende Fehler können mit Hilfe von Unit-Tests schon früh erkannt und behoben werden.

Für Unit-Tests wird ein sehr einfaches Test-Framework eingesetzt. Mit AUTOSAR kann ein solches Framework als eigenständige Software-Komponente implementiert werden, die wie eine gewöhnliche AUTOSAR-Komponente in der RTE auf der Zielplattform läuft.

Es ist sogar möglich, solche Tester-Komponenten automatisch aus AUTOSAR-XML und Testskripten zu generieren, was ohne die expliziten Komponenten-Beschreibungen von AUTOSAR nicht so effizient möglich wäre (Bild).

zurück zur Übersicht