Iterative Zusammenarbeit von OEM, Zulieferer und Software-Lieferant – Teil 1 Neue Wege zur Steuergeräte-Software

Ein Hauptgrund für die Einführung von AUTOSAR ist neben der Standardisierung der Basis-Software auch eine höhere Wiederverwendbarkeit der Funktions-Software. Dies hat allerdings auch Einfluss auf die Zusammenarbeit von OEM, Zulieferer, Halbleiterhersteller und Software-Lieferant. Dieser erste Teil der zweiteiligen Serie erläutert die Grundlage für die erfolgreiche Zusammenarbeit: die AUTOSAR-spezifischen Austauschformate und Werkzeuge.

Iterative Zusammenarbeit von OEM, Zulieferer und Software-Lieferant – Teil 1

Ein Hauptgrund für die Einführung von AUTOSAR ist neben der Standardisierung der Basis-Software auch eine höhere Wiederverwendbarkeit der Funktions-Software. Dies hat allerdings auch Einfluss auf die Zusammenarbeit von OEM, Zulieferer, Halbleiterhersteller und Software-Lieferant. Dieser erste Teil der zweiteiligen Serie erläutert die Grundlage für die erfolgreiche Zusammenarbeit: die AUTOSAR-spezifischen Austauschformate und Werkzeuge.

Von Pascale Morizur, Matthias Wernicke und Justus Maier

Jeder OEM hat für die Steuergeräte seiner Fahrzeuge eigene Anforderungen hinsichtlich Funktionen, Kommunikation und Diagnose. Diese Anforderungen sind in OEM-spezifischer Software umgesetzt. Bedient ein Zulieferer mehrere OEMs, muss er die Steuergeräte-Software für jedes Projekt manuell ändern. Selbst wenn die Funktions-Software von der Software zur Anpassung an die OEM-spezifischen Anforderungen entkoppelt ist, ist dieser Vorgang doch arbeitsintensiv und fehleranfällig. Bild 1 zeigt, wie eine unveränderte Funktions-Software ohne AUTOSAR an verschiedene Fahrzeugprojekte angepasst wird.

Ein Ziel von AUTOSAR ist das Minimieren dieses Anpassungsaufwands bei der Software-Integration. Dafür sind in AUTOSAR die konsequente Abstraktion der Software von der Hardware sowie die Aufteilung der Software in Module mit definiertem Funktionsumfang und genauen Schnittstellen festgelegt. Diese Module können kombiniert und vor allem weitgehend konfiguriert werden, um die Anforderungen verschiedener OEMs abzudecken. Die manuelle Anpassung der Software entfällt und die Wiederverwendung wird erhöht. OEM-spezifische Software-Teile, z.B. für die Diagnose, sind durch die definierten Schnittstellen mit geringem Aufwand austauschbar.

Die AUTOSAR-Referenzarchitektur

Die Beschreibung der AUTOSAR-Referenzarchitektur ist in dem Dokument „AUTOSAR Layered Software Archi-tektur“ [1] enthalten. Darin ist die Steuergeräte-Software in drei Teile gegliedert (Bild 2):

  • Die Funktions-Software besteht aus Software-Komponenten (SWCs). Diese werden auf Basis eines Virtual Functional Bus (VFB) unabhängig von den Steuergeräten erstellt und können über Schnittstellen miteinander kommunizieren.
  • Die Run-time Environment (RTE) dient als Laufzeitumgebung für die SWCs und bildet die technische Realisierung des VFB auf einem konkreten Steuergerät.
  • Die Basis-Software-Module (BSW) übernehmen die Grundfunktionen des Steuergeräts. Diese enthalten auch höherwertige Standarddienste, z.B. die Verwaltung der ECU-Zustände oder Diagnosedienste.