Evaluierungs-Kits Richtig wechseln zu AUTOSAR

Die richtige Auswahl der Tools bei AUTOSAR lässt die Vorteile im Entwicklungsprozesse wirklich ausnutzen.
Der Wechel zu AUTOSAR ist kein Spaziergang, bringt aber wichtige Vorteile mit sich.

AUTOSAR bietet zahlreiche Möglichkeiten zu Prozessverbesserungen und Wiederverwendung von Komponenten. Der Standard erfordert allerdings auch die Etablierung eines neuen Steuergeräte-Entwicklungsprozesses. Worauf es beim Wechsel ankommt.

Seit ihrer Gründung im Jahr 2003 hat die AUTOSAR-Allianz (AUTomotive Open System ARchitecture) die Art und Weise verändert, wie Fahrzeugnetzwerke und elektronische Steuergeräte (Electronic Control Units, ECUs) entwickelt werden. AUTOSAR bietet OEMs und Tier-1-Zulieferern einen standardisierten Ansatz für die Konzeption und Entwicklung von ECUs. Der Standard hilft, von Menschen verursachte Fehler im Designprozess zu reduzieren, und bietet Zulieferern und Herstellern ein wohldefiniertes, maschinenlesbares Datenformat für den Austausch von Designinformationen.

Zu den Mitgliedern der AUTOSAR-Allianz gehören Automobilhersteller sowie ein unterstützendes Ökosystem von Komponenten- und Service-Anbietern. Das Ziel der Allianz ist es, einen globalen offenen Standard für E/E-­Architekturen zu entwerfen und zu eta­blieren. Der Standard berücksichtigt zum einen die Fahrzeugarchitektur­ebene, wo er OEM-Netzwerkdesignern erlaubt, das komplexe Zusammenspiel von Fahrzeugfunktionen zu entwickeln und zu pflegen. Zum anderen unterstützt er auch die Zulieferebene, wo die Details individueller ECU-Schnittstellen vor der Herstellung spezifiziert werden müssen.

Warum zu AUTOSAR wechseln?

Die Migration zu AUTOSAR bietet für OEMs und Tier-1-Zulieferer eine Reihe von Vorteilen. Bis 2020 werden daher voraussichtlich alle Fahrzeuge mit AUTOSAR-basierten ECUs ausgestattet sein. Zu den Vorzügen von AUTOSAR gehören u.a.

  • die verbesserte Wiederverwendung von ECUs in neuen Fahrzeugplattformen und -architekturen;
  • die verbesserte Wiederverwendung von vorvalidierten und getesteten Software-Komponenten, die Kunden- und Systemfunktionen darstellen;
  • geringere Kosten für Tests und ­Sicherheitszertifizierungen;
  • die Reduzierung nachgelagerter Designfehler – die AUTOSAR-Methodik gestattet es, Funktionen bereits auf Architekturebene zu definieren und zu verifizieren;
  • Verbesserungen bei der Netzwerkeffizienz und Kapazitätsauslastung, welche die gesamten Hardware-Kosten verringern,
  • geringere Kosten für Analyse und Designprüfung der gesamten Netzwerkarchitektur;
  • die Verwendung eines standardisierten digitalen Austauschformats (AUTOSAR XML oder arxml), welches die Kommunikation zwischen OEMs und Tier-1-Zulieferern verbessert.

Die Migration zu AUTOSAR kann als Katalysator für Veränderungen genutzt werden – sei es eine ECU, die neu entwickelt werden muss, oder Verbesserungen im gesamten In-House-Design­zyklus. Der Wechsel zu einer AUTOSAR-Methodik kann neben anderen Prozessänderungen erfolgen, zum Beispiel begleitend zur Einführung eines neuen Werkzeug-Workflow oder von Sicherheitsstandards zum Erreichen der ISO-26262-Konformität. Wie auch immer der Wechsel implementiert wird, das erste AUTOSAR-basierte ECU-Projekt wird zeit­intensiver sein als bestehende Projekte im vorherigen Entwicklungsprozess, da sich die Ingenieure erst mit den neuen Methoden vertraut machen müssen. Die Kosteneinsparungen und Effizienzvorteile kommen dann in nachgelagerten Projekten zum Tragen. Wie schnell, hängt insbesondere von der Wahl der richtigen Tools ab.

Den Wechsel durchführen

Ein modernes Luxusfahrzeug kann über 100 ECUs enthalten. Es wäre ein großes Risiko, mit all diesen Komponenten auf einmal auf eine AUTOSAR-Methodik und den AUTOSAR-Standard zu wechseln. Die meisten Unternehmen, die AUTOSAR implementieren, erproben diese Methodik daher zuerst auf einer einzelnen ECU. Dies verringert das Risiko und die Kosten für die gesamte Organisation und dient als Lernerfahrung.

Eigentlich sollten die Produkte von AUTOSAR-Software-Anbietern technisch sehr ähnlich aussehen. In der Realität enthalten solche Lösungen aber immer auch zusätzliche proprietäre Software-Komponenten, Schnittstellen zu kundenspezifischen Designwerkzeugen sowie eine Reihe von ECU-spezifischen Portierungs- und Integrations-Services. Bei der Entscheidung für ein bestimmtes Produkt sollten einige Punkte beachtet werden. So sind die Lizenzkosten für eingebettete AUTOSAR-Software ein Faktor, genauso wichtig ist aber auch die Verfügbarkeit von Portierungs- und Integrations-Services, die helfen, auf der gewählten Halbleiterplattform eine zuverlässige Performance für den gesamten Software Stack zu gewährleisten.

Bei Designautomatisierungswerkzeugen sollten Benutzerfreundlichkeit und Funktionalität berücksichtigt werden. Für einen OEM sollten die Designwerkzeuge für Fahrzeugarchitekturen mit mehreren ECUs, Timing-Analyse und Signaldefinitionen geeignet sein, während für einen Tier 1 die Auswahl und das Management der vielen Konfigurationen und Designparameter für eine ECU wichtiger ist. AUTOSAR ist Hardware-unabhängig. Die Schnittstelle zum Silizium (Microcontroller Abstraction Layer, MCAL) wird üblicherweise vom Halbleiteranbieter zur Verfügung gestellt. Die Verfügbarkeit des MCAL für einen gewählten Halbleiter ist ein wichtiger Faktor. Falls kein MCAL verfügbar ist, muss dieser entwickelt werden, was oft mit zusätzlichen Kosten verbunden ist. Die meisten Halbleiteranbieter veröffentlichen ihren MCAL-Support zusammen mit den unterstützten Mikrocontrollern. Es liegt dann beim jeweiligen Embedded-AUTOSAR-Software-Anbieter, die Schnittstelle zwischen MCAL und dem AUTOSAR-Software-Stack zu entwickeln. Die Kosten hierfür variieren und hängen von den erforderlichen AUTOSAR-Leistungsmerkmalen sowie der Skalierbarkeitsklasse (Scalability Class, SC) des AUTOSAR-Betriebssystems ab. Skalierbarkeitsklassen sind von SC1 bis SC4 eingeteilt. SC1 bietet das grundlegende deterministische Timing und SC4 vollständigen Speicher- sowie Timing-Schutz und nutzt Funktionsmerkmale der zugrunde liegenden Halbleiter. Die Auswahl eines bestimmten Automotive Safety Integrity Level (ASIL), von A (niedrigster) bis D (höchster), wirkt sich auf den Test- und Dokumentationsumfang der Software und entsprechend auch auf die Entwicklungskosten aus.