50413.jpg

Was zu Beginn noch mit Skepsis beurteilt wurde, hat sich in den vergangenen zehn Jahren zu einer Erfolgsgeschichte entwickelt, die ihresgleichen sucht. Mittlerweile hat sich der Standard auf breiter Front in Serie durchgesetzt und viele der über 170 Mitglieder arbeiten an Volumenplattformen, bei denen ein Großteil der Steuergeräte auf Autosar basiert. Inzwischen stammen 80 Prozent der weltweit verkauften Pkw von Mitgliedern der Entwicklungspartnerschaft.

36870.jpg

Autosar

Bis 2012 basierte Autosar auf drei Phasen mit einer Dauer von jeweils drei Jahren. Phase I endete 2006 mit der Veröffentlichung von ersten Spezifikationsergebnissen. Phase II schloss 2009 mit den Releases 3.1 und 4.0, die in großem Umfang im Serienbetrieb bei zahlreichen Fahrzeugherstellern und Zulieferern zum Einsatz kommen. Die kürzlich abgeschlossene Phase III (2010 bis 2012) diente schwerpunktmäßig der Verbesserung der vorhandenen Funktionalität und der Qualität des Standards. In diesem Zeitraum entstand das Release 4.0.3 mit dem derzeit größten Innovationshub von insgesamt 176 Spezifikationsdokumenten. Zahlreiche neue technische Konzepte wie zum Beispiel die Unterstützung des Teilnetzbetriebs (Partial Networking) für energieeffiziente E/E-Architekturen unterstreichen die Marktrelevanz und Akzeptanz des Standards. Partial Networking ermöglicht es, in bestimmten Fahrsituationen beziehungsweise Fahrzeugzuständen den elektrischen Energieverbrauch des Fahrzeugs zu reduzieren, indem nicht benötigte Steuergeräte ausgeschaltet werden können.

Das Ende Juni 2012 veröffentlichte Release 3.2.2 brachte neue Features und Verbesserungen für den 3.x-Release-Zweig. Autosar legte den Fokus hierbei vor allem auf die Wartbarkeit der Spezifikation sowie auf eine einfachere Nutzung des Standards. Zusätzlich wurden kontinuierlich Erfahrungen und Rückmeldungen aus aktuellen Serienentwicklungsprojekten bei der Weiterentwicklung des Standards berücksichtigt. Gegen Ende von Phase III begann eine Weiterentwicklung von Release 4, bei der marktgetrieben ausgewählte rückwärtskompatible Konzepte integriert wurden. Diese Konzepte sind Bestandteil des Release 4.1.1, das im März 2013 an die Öffentlichkeit ging.

Durch die gleichzeitige Bereitstellung und Wartung zweier unterschiedlicher Release-Zweige – 3.2.x und 4.x – ermöglicht Autosar einen gleitenden Übergang und Kontinuität. Mithilfe einer stringenten Kompatibilitätsdokumentation und -prüfung erhalten die Nutzer zudem bei der Migration zwischen Releases oder Revisions Unterstützung. 2013 trat Autosar in  eine kontinuierliche Phase ein, welche einen weiteren wichtigen Meilenstein bei der Etablierung von Autosar als dem weltweiten Standard für automobile Software-Architekturen in der Serienentwicklung darstellt.

Autosar ab 2013

Mit der Fortsetzung ab 2013 hat sich die Entwicklungspartnerschaft Autosar strukturell neu ausgerichtet – unter anderem wird die Partnerschaft nun auf dauerhafter Basis geführt – und an das aktuelle Marktumfeld angepasst. So konzentriert sich die weitere Entwicklung auf stets marktgetriebene technische wie auch organisatorische Verbesserungen. Weitere Ziele bestehen in einer kontinuierlichen Funktionserweiterung und der Entwicklung einer flexiblen Work-Package-Struktur.

Bild 1: Neuer Lebenszyklus für Releases.

Bild 1: Neuer Lebenszyklus für Releases.Autosar

Die Intention besteht darin, eine Balance zwischen der Forderung nach Stabilität auf der einen Seite und weiteren Verbesserungen und Erweiterungen auf der anderen Seite herzustellen. Dabei gilt es bei der Stabilität zwischen zwei Faktoren zu unterscheiden: Der erste Aspekt ist die stringente Überwachung der Rückwärtskompatibilität zwischen Releases, um die Markteinführung eines neuen Release für die Nutzer zu erleichtern. Ein zweiter Aspekt ist die Konzentration auf nur wenige, aber qualitativ reife Releases, die parallel gewartet werden. Um den Standard schlank und das Konsortium möglichst effizient zu halten, pflegt die Entwicklungspartnerschaft eine Release-Strategie, die zu jedem Zeitpunkt nur maximal zwei aktive Release-Zweige erlaubt. Dieser Ansatz stellt einen Kompromiss dar zwischen der funktionalen Weiterentwicklung des lebendigen Standards und der Minimierung des Aufwands (wie zum Beispiel Expertise-Vorhalt oder Tool-Anpassungen), den jedes veröffentlichte Release im Markt bedeutet. Zur weiteren Strukturierung erfolgte eine Neudefinition der Release-Lebenszyklen:

  • Development Phase: Erstentwicklung eines Major Release, das nicht-rückwärtskompatible Erweiterungen sowie Reduktionen nicht mehr benötigter Funktionen enthalten kann (zum Beispiel Rel. 4.0.1).
  • Evolution Phase: beinhaltet Minor Releases und Revisions, wobei eine Minor Release rückwärtskompatible Erweiterungen enthalten darf (zum Beispiel Rel. 4.1.1).
  • Maintenance Phase: beinhaltet nur Revisions, die lediglich der Verbesserung des vorhandenen Funktionsumfangs dienen (zum Beispiel Rel. 3.2.2).
  • Issue Notice Phase: Wartung via LoKI (List of Known Issues). Hier werden die Spezifikationen eingefroren und Korrekturen ausschließlich in der LoKI bereitgestellt.

Durch die Beschränkung auf maximal zwei aktive Entwicklungszweige führt ein Minor Release zur Beendigung der Wartung des vorherigen Minor Release, so dass beispielsweise nach der Einführung von 4.1.1 keine weitere Wartung von Release 4.0.3 erfolgt. Dies ist auch nicht nötig, da das neue Release rückwärtskompatibel ist und somit auch die Wartung aller vorgeschalteten Minor Releases abdecken wird. In einem Wartungsfall wird eine Revision erzeugt; zur Einführung neuer rückwärtskompatibler Funktionen ein Minor Release. Die aktuelle Projektstrategie sieht vor, dass Release 3.2 fortlaufend gewartet wird, während Release 4.x ausgewählte rückwärtskompatible Erweiterungen und Wartungsumfänge enthalten wird.

Rückwärtskompatibilität als Grundvoraussetzung für eine erfolgreiche Gesamtintegration

Die Kompatibilität von Komponenten ist eine essenzielle Voraussetzung für eine erfolgreiche Gesamtintegration, denn Seriensteuergeräte beinhalten häufig Softwarekomponenten verschiedenen Ursprungs. Hierbei heißt es, sowohl unterschiedliche Zuliefererproduktlinien als auch OEM-interne Plattformentwicklungen zu koordinieren. Aus diesem Grunde erfolgt bei Autosar stringent eine Bewertung aller Änderungsanträge in Bezug auf ihre Rückwärtskompatibilität zu den aktuellen Releases sowie eine Kontrolle durch einen Change-Management-Prozess. Diese Kompatibilität ist zum Beispiel auch Grundvoraussetzung, um Änderungen in Minor Releases oder Revisions aufzunehmen. Rückwärtskompatibilität bedeutet in diesem Zusammenhang, dass Funktionen, die auf einer früheren Spezifikation basieren, weiterhin in einer Umgebung verwendet werden könnten, die auf einer geänderten Spezifikation basiert. Zu diesem Zweck gibt es bei Autosar eine fünfstufige Bewertungsskala:

  • Vollständig rückwärtskompatibel
  • Rückwärtskompatibel, wenn die neue Funktion nicht genutzt wird
  • Kompatibilität beeinträchtigt, aber geeignete Problemlösung via Konfiguration verfügbar
  • Kompatibilität beeinträchtigt, Problemlösung verlangt manuelle Anpassung
  • Inkompatible Änderung

Jede Stufe wird im Hinblick auf Buskompatibilität sowie Kompatibilität der Schnittstelle zur Applikation betrachtet. Um den Anwendern eine klare Kompatibilitätsaussage geben zu können erfolgt für jede Änderung im Standard diese Bewertung, die dann auch mit dem Release publiziert wird. Dies ermöglicht einen sehr effizienten Migrationsprozess zwischen zwei Autosar-Releases.

Frühe Implementierung durch integrierte Validierung

Um zukünftige Schwierigkeiten bei der Konzeptintegration so früh wie möglich aufzudecken, hat Autosar den neuen Prozess „integrierte Validierung“ etabliert. Jedes Konzept soll erst validiert werden, bevor der daraus resultierende Standard veröffentlicht wird. Durch diese neue Vorgehensweise lassen sich Validierungsschritte so herunterskalieren, dass sie eine frühe prototypische Implementierung ermöglichen.

Bild 2: Kontinuierliche Konzeptentwicklung.

Bild 2: Kontinuierliche Konzeptentwicklung.Autosar

Daher eignet sich dieses Verfahren speziell zur Integration kommender, vom Markt geforderter Technologien, ohne Kosteneffizienz oder Qualität zu gefährden. Vorzugsweise für komplexe Konzepte, die entweder zahlreiche Spezifikationsdokumente umfassen oder anderweitig technisch anspruchsvoll sind, ist eine integrierte Validierung die bevorzugte Variante, da so die Möglichkeit besteht, eventuelle konzeptionelle Schwächen frühzeitig zu erfassen und zu beseitigen, bevor eine Einarbeitung in die Spezifikationsdokumente des Release erfolgt. Der Prozess fand erstmalig Anwendung bei der Erstellung des Release 4.1.1, wo bereits zwei ausgewählte Konzepte auf Basis der „integrierten Validierung“ validiert wurden. Diese Vorgehensweise wird bei zukünftigen Releases angewendet, die den Standard mit neuen Konzepten erweitern.

Technische Inhalte für die zukünftige Entwicklung

Für zukünftige Releases sind unter anderem Weiterentwicklungen der folgenden technischen Inhalte geplant, die einen kurzen exemplarischen Einblick in die Zukunftsstrategie der Entwicklungspartnerschaft Autosar geben.

Diagnose

Zukünftig soll die Implementierung der Diagnose-Software bei gleichzeitiger Einhaltung von neuen Rechtsvorschriften weiter harmonisiert werden. Dies umfasst unter anderem die bessere Unterstützung der Diagnose im LKW-Sektor (SAE J1939).

Energiemanagement

Ziel ist es, die existierenden Mechanismen für den energieeffizienten Betrieb von Steuergeräteverbünden zu erweitern und weiter zu optimieren. Des Weiteren gilt es, den Anwender beim Einsatz dieser Mechanismen soweit wie möglich durch geeignete Vorgehensweisen und Konzepte zu unterstützen. Das Pretended-Networking-Konzept ermöglicht dies zum Beispiel durch ein auf das einzelne Steuergerät begrenztes Verfahren, das den Stromverbrauch senkt. Darüber hinaus erlaubt das Konzept eine einfache Integration von lokal optimierten ECUs in existierende Netzwerke.

Testunterstützung

Release 4.1.1 beinhaltet die erste Umsetzung einer Rapid-Prototyping-Unterstützung für ECUs, welche unter anderem die Überprüfung neuer Regelalgorithmen in Prototypmustern erlaubt.

Funktionale Sicherheit

In vorherigen Releases stellte Autosar bereits Mechanismen zur Entwicklung der sicherheitsrelevanten Steuergeräte zur Verfügung, die sukzessive erweitert werden. Dies umfasst unter anderem Memory-Partitioning und Time-Partitioning aber auch Absicherung der Kommunikation durch End-to-End-Protection. Zusätzlich wird die Methodik zum Austausch von safety-relevanten Informationen verbessert. So lassen sich beispielsweise ASIL-Klassifikationen (Safety-Integrity-Level) beim Austausch von Konfigurationen weitergeben.

Multi-Core-Unterstützung

Seit dem Release 4.0 unterstützt Autosar Multi-Core-Architekture, und seit Release 4.1.1. ist dies nun nicht mehr auf die Applikationssoftware begrenzt, sondern es ist auch die Ausführung von Teilen der Basissoftware auf verschiedenen Kernen möglich. Zukünftige Aktivitäten in diesem Umfeld konzentrieren sich darauf, den Integrator dabei zu unterstützen, diese Mechanismen effizient in konkreten Steuergeräteprojekten einsetzen zu können.

Ethernet

Release 4.1.1 beinhaltet eine TCP/IP-Protokollsuite für Ethernet, welche den Anforderungen in einem automobilen Umfeld gerecht wird. Dies umfasst zum Beispiel die Unterstützung für Anwendungsprotokolle wie Diagnose OBD (On-Board Diagnostic) sowie Service Discovery. Andere Erweiterungen ermöglichen beispielsweise OBD/Ethernet (ISO 27145), die Unterstützung des „Vehicle to Grid“-Kommunikationsprotokolls (ISO 15118) oder sicherheitsrelevanter Kommunikation durch die TCP/IP-Protokoll-Suite.

Des Weiteren unterstützt Autosar die Konfiguration von Ethernet-Switches – unter anderem mit Mechanismen zur semistatischen Auto-Konfiguration auf Basis von lernenden Algorithmen. Ein weiteres Konzept führt für die Sender-Receiver-Kommunikation eine spezifische Datenserialisierung ein, die für den Austausch großer Datenmengen auf Ethernet-Netzwerken vorgesehen ist.

Interaktion mit Infotainment-Steuergeräten

Mit der Einführung von Ethernet kam auch der Bedarf auf, Funktionsaufrufe zwischen Autosar-ECUs und Infotainment Steuergeräten zu ermöglichen, die typischerweise keine Autosar-Basissoftware besitzen. Diese Interaktion soll in Zukunft über gemeinsame Schnittstellenbeschreibungen unterstützt werden, welche später die Integration in heterogenen Netzwerken erleichtert.

Auf einen Blick

Autosar bis 2016
Im Übergang zum kontinuierlichen Fortbestand ist es Autosar gelungen, eine effiziente organisatorische Struktur zu etablieren, die zum einen in der Lage ist, ein breites Technologiespektrum abzudecken und weiterzuentwickeln und zum anderen eine hohe serientaugliche Qualität der resultierenden Spezifikationen zu gewährleisten. Nach aktueller Schätzung ist im Jahr 2016 mit einer Produktion von fast 300 Millionen auf Autosar basierenden ECUs zu rechnen. Darüber hinaus befinden sich einige OEMs bereits in der Markteinführung von Großserienplattformen, die den Standard in den meisten ihrer Steuergeräte zur Anwendung bringen. (av)

Dr. Stefan Schmerler

ist Autosar-„Spokesperson“ (Sprecher). Er arbeitet bei der Daimler AG in Sindelfingen.

(av)

Sie möchten gerne weiterlesen?