Automotive-Software AUTOSAR auf dem Weg in die Serie

Immer mehr Automobilhersteller entwickeln ihre Steuergerätesoftware auf Basis von AUTOSAR. Die von einer Entwicklungspartnerschaft geschaffenen Standards wurden seit der Einführung im Jahr 2004 in vielen Evaluierungsprojekten getestet und mündet nun in die Realisierungsphase bei Serien-Steuergeräten. Wie hilft AUTOSAR, die komplexen Entwicklungsprozesse zu vereinfachen und die Software wiederverwendbar zu machen?

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Eurocircuits GmbH

Axivion GmbH

Vector Informatik GmbH

Die Automobilindustrie geht neuen Zeiten entgegen. Mit steigender Anzahl an komplexen Fahrzeugfunktionen wird die Entwicklung der Automobilelektronik zunehmend umfangreicher und komplizierter. Fahrzeuge, insbesondere im gehobenen Bereich, verfügen über etwa 1000 Softwarefunktionen, mehrere Bordnetzwerke und mehr als 70 Steuergeräte. Aufgrund der Vielfalt der verwendeten Hardwareplattformen sind Abhängigkeiten der Steuergerätesoftware von der eingesetzten Hardware und Systemkonfiguration problematisch. Mit jeder Änderung einer Randbedingung fällt eine Neuprogrammierung oder zumindest Anpassung der Software an.

Um die Komplexität der Steuergerätesoftware beherrschbar zu machen, hat die AUTOSAR-Entwicklungspartnerschaft eine praxiserprobte Softwarearchitektur definiert, auf deren Grundlage wieder verwendbare Anwendungen entwickelt werden können. Mit dem von Automobilherstellern, -zulieferern und weiteren Unternehmen der Software-, Halbleiter- und Elektronik-Industrie geschaffenen offenen Standard für die Systemarchitektur lassen sich proprietäre Lösungen vermeiden, die immer zu einem erhöhten Entwicklungsaufwand führen.

AUTOSAR unterteilt dazu die Elektronikarchitektur in mehrere Schichten und Module. Mit der gleichzeitigen Definition von Schnittstellen schafft AUTOSAR so Standards für einen einfachen Austausch von Softwarekomponenten oder Hardwareplattformen. Von der Entwicklungspartnerschaft gibt es jedoch nicht nur Vorgaben für die Basissoftwaremodule. Sie bietet auch eine Methodik für die Entwicklung von Applikationen und verteilten Systemen. Diese beginnt mit einer modellbasierten Beschreibung der Softwareapplikationen und des verteilten Systems, und endet idealerweise in einem automatisch generierten und reproduzierbaren Test. Durch diese formale Vorgehensweise wird es leichter, eine durchgängige Werkzeugkette einzusetzen.

Gute drei Jahre nach dem Start veröffentlichte die Entwicklungspartnerschaft AUTOSAR Anfang 2007 das Release 2.1. Damit wurde ein stabiler Stand geschaffen, der in mehreren Validierungsprojekten auf Praxistauglichkeit geprüft wurde. In vielen Unternehmen ist das Thema „Evaluierung AUTOSAR“ erfolgreich abgeschlossen. Nun steht die Umsetzung in konkreten Serien-Steuergeräten an.

Fahrzeugelektronik wird in mehrere abstrakte Layer unterteilt

Um die Ziele von AUTOSAR – Trennung der Applikationssoftware von Basismodulen und -funktionen – zu verwirklichen, wird die Fahrzeugelektronik abstrahiert und in mehrere Schichten (Layer) unterteilt (Bild 1). Die Verbindung zum Mikrocontroller und damit die physikalische Basis stellt der Microcontroller Abstraction Layer dar, der die Funktionen und Peripherie des Mikrocontrollers abbildet. Er definiert Schnittstellen für Speicher, I/O-Treiber und dessen Kommunikationsverbindungen. In dieser Schicht können auch die Features in Software nachgebildet werden, die der Mikrocontroller nicht bietet.

Als zweite Schicht liegt die ECU-Abstraktion darüber. Sie bestimmt die ECU-eigene Hardwareauslegung und stellt beispielsweise Treiber zu ECU-externer Peripherie zur Verfügung. In einer weiteren Schicht, dem Services Layer, werden verschiedene Basisdienste wie Netzwerkdienste, Speicherverwaltung, Buskommunikationsdienste und das Betriebssystem abgebildet. Sie ist von der Hardware bereits weitestgehend unabhängig.

Die RTE stellt den vierten Layer dar. Hier findet die eigentliche Trennung von Anwendungs- und Basissoftware (BSW) statt. Die RTE sorgt für die Integration der Anwendungssoftware und regelt den Datenaustausch zwischen Applikation und BSW. Erst durch diese Schicht wird es möglich, einmal geschriebene Applikationssoftware wieder zu verwenden möglich, denn die definierten Schnittstellen erlauben es, dass Applikationssoftware ohne besondere Kenntnis der später verwendeten Hardware entwickelt und beliebig auf anderen AUTOSAR-konformen Steuergeräten verwendet werden kann.

Applikationskomponenten können unabhängig von konkreten Steuergeräten entwickelt werden

Die Basis für die Konfiguration der Schichten ist der Virtual Functional Bus (VFB). Über ihn kommunizieren in einer abstrahierten Sicht alle Komponenten der Fahrzeugelektronik. Die Softwarekomponenten verwenden dafür Ports, deren Schnittstelle über Port Interfaces definiert werden können. Konnektoren verbinden die Ports. Ob es sich dabei um eine Verbindung innerhalb eines Steuergeräts oder um eine Verbindung über einen externen Bus handelt, spielt für den VFB keine Rolle. Dies entscheidet sich erst, wenn die endgültige Systemauslegung erfolgt und Funktionen einem bestimmten Steuergerät zugewiesen werden.

Die Softwarekomponente selbst benötigt kein Wissen über diese spätere Aufteilung und kann so unabhängig davon entwickelt werden. Sie ist in Ausführungseinheiten aufgeteilt, so genannte Runnable Entities, die wie Prozeduren beim Eintreten eines bestimmten Ereignisses ausgeführt werden. Ein solches Ereignis ist beispielsweise das Eintreffen eines neuen Sensorwerts oder eine periodische Aktivierung. Durch die aus Sicht des VFB formulierte Beschreibung des Elektroniksystems sind die Schnittstellen der jeweiligen Softwarekomponenten definiert. Die Applikationskomponenten können damit unabhängig vom konkreten Steuergerät entwickelt werden.

Die „Gegenstelle“ auf dem Steuergerät ist die RTE. Sie gewährleistet den Zugriff auf I/Os, Speicher und andere Basisdienste. Mittels der modellbasierten Beschreibung wird die RTE steuergerätespezifisch generiert und lässt sich damit ressourcenschonend an unterschiedliche Anforderungen anpassen.

AUTOSAR-Methodik als Hilfestellung für fehlerfreie Software

Neben der Softwarearchitektur des Steuergerätes definiert der AUTOSAR-Standard auch eine Methodik, die als Hilfestellung für die Entwicklung von AUTOSAR-Systemen dient. Für eine fehlerfreie Software ist es anerkanntermanßen eine wichtige Voraussetzung, strukturierte Entstehungsprozess einzuhalten. Mängel in der Anforderungsliste werden frühzeitig erkannt, die Wiederverwendung und Portierung von Softwarekomponenten vereinfacht und das System insgesamt zuverlässiger. Die Methodik gestattet dennoch Freiheiten: so bleibt es beispielsweise den Anwendern überlassen, ob ein Top-Down-Ansatz oder eine Bottom-Up-Entwicklung gewählt wird.

Die AUTOSAR-Initiative sieht eine durchgängige Unterstützung durch Werkzeuge vor. Mittels ausgereifter Tools werden Anforderungen strukturiert umgesetzt und konsistent weitergeführt, Konfigurationen systematisch erstellt und die komplexen Abhängigkeiten automatisch berücksichtigt.

Zunächst erfolgt die formale Beschreibung der drei Hauptbestandteile Software (SW Components), ECUs (ECU Resources) und Systemrandbedingungen (System Constraints). Durch Editoren entsteht daraus eine Konfigurationsbeschreibung des kompletten Systems (Bild 2). Diese System Configuration ist die Basis um die Steuergeräte-Konfigurationen (ECU Configuration) zu erstellen, die vom Anwender mithilfe der Konfigurationswerkzeuge für die einzelnen Basissoftwaremodule erstellt werden. Mehrere Generatoren liefern am Ende des Prozesses die steuergerätespezifische Implementierung von RTE und Basissoftware.

Alle im Entwicklungsprozess entstandenen Entwurfs- und Konfigurationsdaten werden in einem einheitlichen Format beschrieben. AUTOSAR hat dafür ein Format auf XML-Basis definiert. Es garantiert, dass der Entwicklungsprozess durchgängig bleibt und erleichtert das Einfügen zusätzlicher Tools.

Risikolose Migration durch wohldefinierte Schnittstellen

Die Softwarearchitektur eines AUTOSAR-Steuergerätes ist nicht monolithisch, sondern besteht aus einer Reihe von Standard-Modulen mit wohldefinierten Schnittstellen. Damit lassen sich auch Migrationslösungen realisieren, die einen risikolosen Übergang zu AUTOSAR ermöglichen. Eine solche Migrationslösung muss typischerweise projektspezfisch erarbeitet werden. Dies kann in der Praxis ein Mischverbau von AUTOSAR-Standardmodulen und proprietärer Software sein.

Um eine Migrationslösung zu erarbeiten, vergleicht man zunächst die bestehenden Individualsoftware und die AUTOSAR-Architektur. Nach Analyse hinsichtlich Überschneidungen und Integrationsmöglichkeiten fällt die Entscheidung, welche Module bestehen bleiben und welche durch Standardsoftware ersetzt werden können.

So empfiehlt es sich beispielsweise, eine Trennschicht zwischen Applikations- und Basissoftware einzuführen. Ein mögliches Szenario ist dabei, die Applikationen bereits frühzeitig als AUTOSAR-Softwarekomponenten auszulegen und über eine RTE zu integrieren. Unterhalb der RTE dient ein spezifischer Adaption Layer zur Anbindung and die bestehende Basissoftware (Bild 3).

Wenn Teile der bestehenden Basissoftware durch AUTOSAR-Basissoftware ersetzt werden sollen, sollte das Augenmerk auf dem Einsatz eines einheitlichen Konfigurationswerkzeugs für beide Welten liegen. Vector Informatik bietet dafür z. B. geeignete Werkzeuge an, die flexibel genug sind um auch proprietäre Basissoftware konfigurieren zu können. Sukzessive können nun Nicht-AUTOSAR-Module durch AUTOSAR-Module ersetzt werden, ohne die Gesamtarchitektur zu gefährden oder Umprogrammierungen an anderen Modulen vornehmen zu müssen.

Toolbeispiele für die AUTOSR-Entwicklung

Mit dem aktuellen AUTOSAR Release 3.0 ist ein weiterer Schritt getan, um die Qualität des AUTOSAR Standards zu erhöhen. An dem fortwährenden Engagement der beteiligten Firmen kann man ablesen, dass nach wie vor das Bekenntnis zum Ziel der AUTOSAR-Entwicklungspartnerschaft da ist. So werden zu Zeit Ideen eingebracht, die im Rahmen der zukünftigen Version 4.0 des AUTOSAR-Standards Realität werden sollen.

Auch bei den Anbietern rund ums Thema AUTOSAR entstehen neue Ideen. Aktuelle Entwicklungen bei Vector Informatik haben zum Ziel, die Steuergeräteentwicklung auf Basis von AUTOSAR besonders komfortabel und effizient zu machen. Ein Beispiel hierfür ist ein PC-basiertes Testwerkzeug für AUTOSAR-Applikationskomponenten, das auf Ebene des VFB als Emulator für die AUTOSAR-Steuergeräteumgebung dient. Damit lässt sich der Implementierungscode von AUTOSAR-Softwarekomponenten bequem am Entwicklungs-PC testen. Für die Ausführung von Tests, die Visualisierung während oder nach dem Test sowie für die Erzeugung von Testberichten können weit verbreitete Standardwerkzeuge wie Vector CANoe verwendet werden.

Zusammen mit der kompletten AUTOSAR-Basissoftware und einer durchgängigen Werkzeugkette aus Design- und Entwicklungstools bietet Vector damit Unterstützung für alle Phasen des Steuergeräte-Entwicklungsprozesses (Bild 4). Die Vector Lösung ist praxiserprobt durch den Einsatz in Evaluierungsprojekten und serienreif für das AUTOSAR Release 2.0 bzw. 2.1 (ab 2. Quartal 2008 auch 3.0) erhältlich.

*Dipl.-Ing. (FH) Matthias Wernicke ist für das Produktmanagement der DaVinci Tool Suite bei Vector Informatik verantwortlich und in der AUTOSAR-Standardisierungsarbeit aktiv. Kontakt: matthias.wernicke@vector-informatik.de

(ID:239109)