Standardisierte Architekturen und Schnittstellen sollen komplexe Systeme beherrschbar machen

Status Quo AUTOSAR

8. Januar 2007, 10:40 Uhr | Matthias Wernicke und Jochen Rein
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

AUTOSAR vereint Hardware, Basis- und Anwendungssoftware

In AUTOSAR wurden alle Bestandteile eines Steuergeräts abstrahiert und in Anwendungssoftware, Basissoftware und Hardware-Ebene unterteilt (Bild 1). Die unterste Schicht stellt die Hardware-Ebene dar. In ihr werden alle Hardware-Features des Mikrocontrollers abstrahiert. Fehlende Hardware-Features werden an dieser Stelle durch entsprechende Softwaremodule egalisiert. Diese SPAL (Standard Peripheral Abstraction Layer) genannte Schicht beinhaltet Mikrocontroller-Treiber, Speicheransteuerung, Kommunikations- und I/O-Treiber.

Über dem SPAL steht die Abstraktionsebene der ECU. Diese Schicht abs-trahiert alle Basiskomponenten, die sich in der ECU befinden. Hier befinden sich auch die Treiber für externe Peripheriekomponenten. Die nächsthöhere Schicht, Services Layer, ist bereits weitgehend von der Hardware unabhängig und stellt verschiedene Arten von Hintergrunddiensten wie Speicherverwaltung, Netzwerk- oder Buskommunikationsdienste bereit. Der RTE als vierte Schicht kommt eine besonders wichtige Bedeutung zu: Sie verbindet die Komponenten der Anwendung mit der Basissoftware, indem sie den Datenaustausch und die Interaktion zwischen ihnen regelt.

Um diese Schichten konfigurieren zu können, wird das System zunächst in einer abstrahierten Sicht auf Basis des Virtual Functional Bus (VFB) entworfen. Diese Sicht beschreibt die Anwendungssoftware in Form von miteinander kommunizierenden Komponenten. Zwischen den Komponenten erfolgt die Kommunikation über Ports, deren Schnittstelle über das Port Interface definiert ist. Die Schnittstelle kann entweder für Datenkommunikation oder für Funktionsaufrufe gemäß dem Client/Server-Prinzip ausgeführt sein. Konnektoren verbinden die Ports miteinander. Dabei spielt es auf System-ebene keine Rolle, ob die Konnektoren intern innerhalb eines Steuergerätes oder extern durch Kommunikation über einen Datenbus realisiert werden. Erst bei der konkreten Systemauslegung entscheidet sich dies durch die Zuweisung der Softwarekomponenten auf die einzelnen ECUs.

Die Softwarekomponente selbst hat kein Wissen über diese spätere Aufteilung und kann daher unabhängig vom Systemkontext entwickelt werden. Die Ausführungseinheiten einer Softwarekomponente werden Runnable Entities genannt. Sie entsprechen Prozeduren und werden bei Eintreten eines bestimmten Ereignisses ausgeführt, wie etwa einer zyklischen Aktivierung oder bei Ankunft eines neuen Eingangswertes.

Aus der gemäß VFB-Sicht erstellten Beschreibung des Systems ergibt sich die Programmierschnittstelle (API) der Softwarekomponenten, die über die RTE bereitgestellt wird. Mittels dieser API lassen sich Eingangswerte lesen oder Ausgangswerte schreiben. Auch für den Zugriff auf die Basisdienste, wie etwa dem Memory-Service, kann eine API bereitgestellt werden.

Durch das Prinzip der modellbasierten Beschreibung der Software-Architektur sind RTE und Basissoftware skalierbar und können ressourcenschonend an die jeweiligen Anforderungen angepasst werden.

66ah0501_03.jpg
Bild 1. AUTOSAR-Schichtenmodell. Durch Module mit standardisierten Schnittstellen werden die Mikrocontroller- und ECU-Spezifika von der Anwendungsebene abstrahiert.

AUTOSAR definiert die Methodik der Software-Entwicklung

Neben den Vorgaben zur Bestimmung der Architektur definiert AUTOSAR auch die Methodik der Software-Erstellung. Hierin liegt ein wesentliches Element der Entwicklung zuverlässiger Komponenten: Eine strukturierte Herangehensweise zeigt früh fehlende oder falsche Anforderungen, vereinfacht die Wiederverwendung von Softwarekomponenten sowie deren Portierung und führt zu einem zuverlässigeren System. AUTOSAR setzt dabei auf werkzeuggestützte Entwicklungsprozesse. Die Methodik dient der strukturierten Herangehensweise, lässt aber dennoch genug Freiheiten für unterschiedliche Entwicklungsprozesse.

Dank Werkzeugunterstützung erstellen die Entwicklungsteams die System- und Steuergerätekonfigurationen systematisch und konsistent. Die komplexen Abhängigkeiten der Daten werden von den Werkzeugen automatisch berücksichtigt. Die drei Hauptbestandteile Software (SW Component), ECUs (ECU Ressource) und System-Randbedingungen (System Constraints) werden zunächst formal beschrieben. Durch geeignete Editoren entsteht daraus eine Konfigurationsbeschreibung des kompletten Systems. Diese System Configuration dient als Basis zur Erstellung der Steuergeräte-Konfigurationen (ECU Configuration), die vom Anwender mithilfe geeigneter Konfigurationswerkzeuge für die einzelnen Basissoftwaremodule erstellt werden. Mehrere Generatoren liefern am Ende des Prozesses die Steuergeräte-spezifische Implementierung von RTE und Basissoftware.

Wichtig ist, dass alle während des Entwicklungsprozesses entstandenen Entwurfs- und Konfigurationsdaten in einem einheitlichen Format beschrieben werden können. Dazu wurde ein Format auf XML-Basis (Extensible Markup Language) definiert, das die Durchgängigkeit des Entwicklungsprozesses garantiert und das nahtlose Einfügen notwendiger oder zusätzlicher Tools erleichtert.


  1. Status Quo AUTOSAR
  2. Tool-Unterstützung für den Entwurf verteilter Funktionen
  3. AUTOSAR vereint Hardware, Basis- und Anwendungssoftware
  4. Status Quo AUTOSAR

Jetzt kostenfreie Newsletter bestellen!