Die Rolle des Dienstleisters im AUTOSAR-Zeitalter Praxisnahe Veränderungen in der Basissoftware

Die AUTOSAR-Basis-Software ist nahezu fertig spezifiziert, erste Implementierungen sind bereits am Markt verfügbar. Als Folge müssen Zulieferer nicht mehr unterschiedliche Basis-Software-Strukturen für verschiedene Fahrzeughersteller bereitstellen. Wer aber kann die AUTOSAR-Module so ergänzen und integrieren, dass ein funktionsfähiges und effizientes System entsteht?

Die Rolle des Dienstleisters im AUTOSAR-Zeitalter

Die AUTOSAR-Basis-Software ist nahezu fertig spezifiziert, erste Implementierungen sind bereits am Markt verfügbar. Als Folge müssen Zulieferer nicht mehr unterschiedliche Basis-Software-Strukturen für verschiedene Fahrzeughersteller bereitstellen. Wer aber kann die AUTOSAR-Module so ergänzen und integrieren, dass ein funktionsfähiges und effizientes System entsteht?

Hier können Entwicklungsdienstleister helfen. Sie sind unabhängig von den Tool-Herstellern, werden nicht nach Anzahl verkaufter Lizenzen gemessen und können Erfahrungen aus AUTOSAR-Projekten oder aus den AUTOSAR-Arbeitsgruppen vorweisen. Um von AUTOSAR profitieren zu können, hat man erst einige Hausaufgaben zu erledigen. Denn die Anforderungen an die Systeme sind zwar die gleichen geblieben, die Art sie zu implementieren ändert sich jedoch.

Es ist erst etwa zehn Jahre her, dass die Entwickler völlig auf sich alleine gestellt waren und ganz ohne Standard-Software auskommen mussten. Die Vernetzung in Fahrzeugen hatte ihre Einführung noch nicht richtig erfahren, lediglich im Antriebsbereich fanden sich elektronischen Komponenten. Die Fahrzeughersteller hatten das Thema Vernetzung noch nicht aufgegriffen und auch die Forderung bestimmte Protokolle und Techniken einzusetzen bestand nur vereinzelt. Das führte dazu, dass die Zulieferer proprietäre Systeme herstellten, die mit hauseigenen Tools und Techniken diagnostiziert werden mussten.

Funktionen wurden in Assembler oder C realisiert und man begann erst langsam über modellbasierte Ansätze mit automatischer Codegenerierung nachzudenken. So waren auch die Schnittstellen dieser Funktionen proprietäre Lösungen und eine Verschiebbarkeit oder Wiederverwendbarkeit mit erheblichem Aufwand verbunden.

Die Explosion der Komplexität

Nur wenige Jahre später finden sich Mittelklassewagen mit über 50 elektronischen Baugruppen, die zudem noch miteinander, über mehrere Bussysteme vernetzt sind. In der Zwischenzeit wuchs die Komplexität dieser vernetzten Systeme überproportional zur Anzahl der elektronischen Baugruppen und Funktionen. Bis heute ist die Beherrschung dieser Komplexität ein Hauptthema in der Elektronikentwicklung. Ein wichtiger Ansatz, dem zu begegnen, ist die Standardisierung in der Software-Entwicklung. Die HIS (Hersteller-Initiative Software) hat Anstrengungen in diese Richtung unternommen. Und die Fahrzeughersteller entwickelten für sich einen Standard, der festlegt, wie man sich in der Vernetzung zu verhalten hat. Neben physikalischen Vorgaben, die durch Hardware zu realisieren sind, gibt es z.B. Vorgaben zu Transport- und Diagnoseprotokollen, der Handhabung von Fehlern, Software-Updates im Feld und zu Diagnosefunktionen. Damit diese Vorgaben nicht von jedem Zulieferer neu implementiert werden müssen, gaben die Fahrzeughersteller den Entwicklern Standard-Software mit auf den Weg.

Zum Leidwesen der Zulieferer unterscheidet sich die Handhabung dieser Standard-Software bei jedem Fahrzeughersteller. Während einige diese komplett und kostenfrei dem Zulieferer zur Verfügung stellen, liefern andere Hersteller nur einzelne Module an ihre Auftragnehmer. Vereinzelt erwarten OEMs auch, dass sich Zulieferer finanziell und organisatorisch eigenständig der Standard-Software annehmen. Doch auch die Inhalte sind nicht die gleichen. Dies bedeutet, dass jeder Fahrzeughersteller sich seine eigenen Standards schuf. Ein Zulieferer, der eben erst sein System für Fahrzeughersteller A in dessen Fahrzeug integriert hat, muss große Teile seiner Applikation ändern, um morgen sein System in ein Fahrzeug des Herstellers B zu integrieren.

Vorteile durch die Standard-Software

Dennoch haben die zum Teil sehr guten Standards der einzelnen Fahrzeughersteller Vorteile ergeben. Die Wiederverwendung von bereits erprobten Software-Modulen erhöht die Qualität und spart Entwicklungsmittel ein. Weitere Vorteile ergeben sich durch die vorgegebene Modularisierung, was sich am Beispiel des Fehlerspeichermanagers gut zeigen lässt: In der Standard-Software wird der Fehlerspeichermanager üblicherweise als zentrales Modul organisiert, das auf die Diagnose-Dienste aufsetzt und über ein geeignetes Transportprotokoll und eine CAN-Schnittstelle mit der Außenwelt kommuniziert (Bild 1). Wer in seinem Steuergerät nun auf UDS/ODX aufsetzen möchte, hat es mit zentral organisierten Strukturen sehr einfach. Durch Tausch der Module Transportprotokoll, Diagnose und Fehlerspeichermanager sowie durch geringe Änderungen in der Applikation, ist dies eine lösbare Aufgabe. In anderen Lösungen war der Fehlerspeichermanager dezentral organisiert, weshalb nicht von einem zur Verfügung gestellten Modul des Fahrzeugherstellers profitiert werden konnte. Änderungen betreffen somit die gesamte Steuergerätesoftware.

Auch die Funktionen profitieren von dem vorgegebenen Design. Durch den Einsatz einer geeigneten Hardware-Abstraktionsschicht muss keine Funktion mehr direkt mit der Hardware kommunizieren. Aber eine vereinheitlichte Schnittstelle oder eine einheitliche Schnittstellenbeschreibung gibt es nicht. So ist die Verschiebung von Funktionen auf andere Hardwaregrundlagen zwar einfacher geworden, ob die Funktion aber problemlos in eine andere bereits existierende Struktur eingebracht werden kann, ist keinesfalls gesichert.

zurück zur Übersicht