Wikipedia

AUTOSAR

Entwicklungspartnerschaft von Automobilherstellern

AUTOSAR (AUTomotive Open System ARchitecture) ist eine 2003 gegründete weltweite Entwicklungspartnerschaft von Automobilherstellern, Zulieferern und anderen Unternehmen aus der Elektronik-, Halbleiter- und Softwareindustrie. Sie verfolgt den Zweck, eine offene und standardisierte Softwarearchitektur für elektronische Steuergeräte (ECUs) zu entwickeln und zu etablieren.

AUTOSAR GbR

Logo
Rechtsform GbR
Gründung 2003
Sitz München (Administration)
Leitung Michael Niklas-Höret (Chairperson, 2024)

Thomas Rüping (Deputy Chairperson, 2024) Carmine De Iesu (Project Lead Speaker, 2024)

Mitarbeiterzahl 366 Firmen (12/2023)
Branche Automobilindustrie, E/E, Software, Semiconductor
Website www.autosar.org

Ziele sind die Skalierbarkeit auf unterschiedliche Fahrzeug- und Plattformvarianten, die Übertragbarkeit von Software, die Berücksichtigung von Verfügbarkeits- und Sicherheitsanforderungen, die Zusammenarbeit verschiedener Partner, die nachhaltige Nutzung natürlicher Ressourcen und die Instandhaltbarkeit über den gesamten Produktlebenszyklus.[1][2]

Geschichte Bearbeiten

Die AUTOSAR-Entwicklungspartnerschaft wurde im Juli 2003 von Bayrische Motoren Werke AG (BMW), Robert Bosch GmbH, Continental AG, Mercedes-Benz Group AG, Siemens VDO und Volkswagen AG zur Entwicklung und Etablierung eines offenen Industriestandards für die Automotive E/E-Architektur gegründet. Im November 2003 trat Ford Motor Company als Core-Partner bei und im Dezember schlossen sich Peugeot Citroën Automobiles S.A. und Toyota Motor Corporation an. Im folgenden November wurde auch General Motors Holding LLC ein Core-Partner. Nachdem Siemens VDO im Februar 2008 von Continental übernommen wurde, ist es kein eigenständiger Core-Partner von AUTOSAR mehr.[3]

Seit 2003 hat AUTOSAR vier Hauptversionen der standardisierten Automotive Software-Architektur für seine Classic Plattform und eine Version von Acceptance Tests zur Verfügung gestellt. Die Arbeit an der AUTOSAR Classic Plattform kann in drei Phasen unterteilt werden:

  • Phase III (2004–2006): Grundlegende Entwicklung des Standards (Releases 1.0, 2.0 und 2.1)
  • Phase III (2007–2009): Erweiterung des Standards in Bezug auf Architektur und Methodik (Releases 3.0, 3.1 und 4.0)
  • Phase III (2010–2013): Wartung und ausgewählte Verbesserungen (Versionen 3.2, 4.1 und 4.2)[4]

Im Jahr 2013 hat das AUTOSAR-Konsortium einen kontinuierlichen Arbeitsmodus für die Classic Plattform eingeführt, um den Standard beizubehalten und ausgewählte Verbesserungen bereitzustellen (einschließlich der Version R4.2 sowie der Version 1.0 der Akzeptanztests).

Im Jahr 2016 begann die Arbeit an der Adaptive Plattform. Ein erstes Release (17-03) wurde Anfang 2017 veröffentlicht, gefolgt von Release 17-10 im Oktober 2017 und Release 18-03 im März 2018. Mit der Release 18-10 im Oktober 2018 wurden schließlich die wichtigsten Entwicklungsaktivitäten in einer gemeinsamen Version von AUTOSAR Classic, Adaptive und Foundation im Oktober 2018 zusammen veröffentlicht. In den nächsten Schritten sollen nun jährlich weitere gemeinsame Veröffentlichungen der drei AUTOSAR Plattform veröffentlicht werden.[3]

Im Dezember 2023 wurde AUTOSAR R23-11 virtuell veröffentlicht.[5]

Konzept und Ziele Bearbeiten

AUTOSAR stellt eine Reihe von Spezifikationen zur Verfügung, die grundlegende Softwaremodule beschreiben, Anwendungsschnittstellen definieren und eine gemeinsame Entwicklungsmethodik auf der Grundlage eines standardisierten Austauschformats erstellen. Basissoftwaremodule, die durch die AUTOSAR Layered Software Architecture zur Verfügung gestellt werden, können in Fahrzeugen unterschiedlicher Hersteller und Elektronikkomponenten unterschiedlicher Anbieter eingesetzt werden, wodurch der Aufwand für Forschung und Entwicklung sowie die zunehmende Komplexität von automobilen Elektronik- und Softwarearchitekturen reduziert wird.[6]

Softwarearchitektur Bearbeiten

Einteilung Bearbeiten

AUTOSAR verwendet eine dreischichtige Architektur:[7]

  • Basis-Software: standardisierte Software-Module (meistens) ohne funktionale Aufgabe, welche Dienste anbietet, die notwendig sind, um den funktionalen Teil der oberen Software-Ebene zu betreiben.
  • Laufzeitumgebung (Run-Time Environment, RTE): Middleware, die von der Netzwerktopologie für den inter- und intra-ECU-Informationsaustausch zwischen den Anwendungssoftwarekomponenten und zwischen der Basissoftware und den Anwendungen abstrahiert.
  • Anwendungsschicht: Anwendungssoftwarekomponenten, die mit der Laufzeitumgebung interagieren.

Die AUTOSAR-Methodik Bearbeiten

  • Die Systemkonfigurationsbeschreibung enthält alle Systeminformationen und zwischen den verschiedenen Steuergeräten (ECU) vereinbarten Informationen (z. B. Definition von Bussignalen).
  • ECU-Extrakt: enthält die Informationen aus der Beschreibung der Systemkonfiguration, die für ein bestimmtes Steuergerät benötigt werden (z. B. jene Signale, auf die ein bestimmtes Steuergerät Zugriff hat).
  • ECU-Konfigurationsbeschreibung: enthält alle grundlegenden Softwarekonfigurationsinformationen, die für ein bestimmtes Steuergerät lokal sind. Diese Informationen werden verwendet, um die ausführbare Software, den Code der Basissoftwaremodule und den Code der Softwarekomponenten daraus zu erstellen.[8]

Classic Plattform Bearbeiten

Die AUTOSAR Classic Plattform ist der Standard für eingebettete Echtzeit-Steuergeräte auf Basis von OSEK. Das wichtigste Ergebnis sind die Spezifikationen.

Die AUTOSAR Classic Plattform-Architektur unterscheidet auf der höchsten Abstraktionsebene drei Software-Schichten, die auf einem Mikrocontroller laufen: Anwendung, Laufzeitumgebung (RTE) und Basissoftware (BSW). Die Anwendungssoftwareschicht ist größtenteils hardwareunabhängig. Die Kommunikation zwischen Softwarekomponenten und der Zugriff auf BSW erfolgt über RTE, welche die vollständige Schnittstelle für Anwendungen darstellt.

Die BSW ist in drei Hauptschichten und komplexe Treiber unterteilt:

  • Dienstleistungen,
  • ECU (elektronische Steuereinheit) Abstraktion und
  • Mikrocontroller-Abstraktion.

Die Dienste sind außerdem in funktionale Gruppen unterteilt, welche die Infrastruktur für System-, Speicher- und Kommunikationsdienste darstellen.

Ein wesentliches Konzept der Classic Plattform ist der Virtual Functional Bus (VFB). Dieser virtuelle Bus ist ein abstraktes Set von RTEs, die noch nicht für bestimmte Steuergeräte bereitgestellt wurden und entkoppelt die Anwendungen von der Infrastruktur. Kommuniziert wird über dedizierte Ports, d. h. die Kommunikationsschnittstellen der Anwendungssoftware müssen auf diesen Ports abgebildet werden. Der VFB übernimmt die Kommunikation innerhalb der einzelnen Steuergeräte und zwischen den Steuergeräten. Aus Sicht der Anwendung sind keine detaillierten Kenntnisse von Technologien oder Abhängigkeiten auf niedrigerer Ebene erforderlich. Dies unterstützt die hardwareunabhängige Entwicklung und Nutzung von Anwendungssoftware.

Die Classic Plattform ermöglicht auch die Integration von Nicht-AUTOSAR-Systemen wie GENIVI unter Verwendung der Franca Interface Description Language (IDL).

Akzeptanztests Bearbeiten

2014 wurden AUTOSAR-Abnahmetests für die Classic Platform eingeführt, um den Testaufwand und die Testkosten zu minimieren. Abnahmetestspezifikationen sind Systemtestspezifikationen unter Verwendung der angegebenen Schnittstellen. Außerdem berücksichtigen sie das festgelegte Verhalten auf dem Bus. Sie können als Black-Box-Testfall für eine bestimmte Plattformfunktion angesehen werden oder als Spezifikation von Standard-Abnahmetests für zuvor definierte Ziele.[9]

Standardisierte Anwendungsschnittstellen Bearbeiten

Die Standardisierung funktionaler Schnittstellen zwischen Herstellern und Zulieferern und die Standardisierung der Schnittstellen zwischen den verschiedenen Softwareschichten wird als Grundlage für die Erreichung der technischen Ziele von AUTOSAR angesehen.[10] Nur durch die Standardisierung konkreter Schnittstelleninhalte hinsichtlich ihrer physikalischen und zeitlichen Repräsentation erreicht man die notwendige Kompatibilität bei der Integration.[11]

Adaptive Plattform Bearbeiten

Neue Anwendungsfälle erforderten die Entwicklung der Adaptive Plattform. Ein prominentes Beispiel ist das hochautomatisierte Fahren, bei dem der Fahrer vorübergehend und / oder teilweise die Verantwortung für das Fahren an das Fahrzeug überträgt. Dies erfordert beispielsweise die Kommunikation mit der Verkehrsinfrastruktur (z. B. Verkehrszeichen und -lichter), Cloud-Backends (z. B. Zugriff auf die neuesten Verkehrsinformationen oder Kartendaten) oder die Verwendung von Mikroprozessoren und Hochleistungs-Computing-Hardware für parallele Verarbeitung (z. B. GPUs).

Darüber hinaus erfordern Car-2-X-Anwendungen eine Interaktion mit Fahrzeugen und Off-Board-Systemen. Das bedeutet, dass das System eine sichere On-Board-Kommunikation, Unterstützung von domänenübergreifenden Computing-Plattformen, Smartphone-Integration, Integration von Nicht-AUTOSAR-Systemen usw. bereitstellen muss. Cloudbasierte Dienste erfordern darüber hinaus dedizierte Sicherheitsmaßnahmen wie sichere Cloud-Interaktion und Vorfahrt für Einsatzfahrzeuge. Sie ermöglichen ferngesteuerte und verteilte Dienste, z. B. Ferndiagnose, Over-the-Air (OTA) -Aktualisierung, Reparatur und Austausch.

Um die dynamische Bereitstellung von Kundenanwendungen zu unterstützen und Rahmenbedingungen für die Anwendungen bereitzustellen, die High-End-Rechenleistung erfordern, standardisiert AUTOSAR derzeit die AUTOSAR Adaptive Plattform. Sein Kern ist ein Betriebssystem, das auf dem POSIX-Standard basiert. Das Betriebssystem kann von der Anwendung über eine Teilmenge des POSIX nach IEEE1003.13 (nämlich PSE51) verwendet werden. Eines der Hauptmerkmale der Adaptive Plattform ist die serviceorientierte Kommunikation.

Für die Adaptive Plattform sind zwei Arten von Schnittstellen verfügbar: Dienste und Anwendungsprogrammierschnittstellen (APIs). Die Plattform besteht aus funktionalen Clustern, die in Dienste und die AUTOSAR Adaptive Plattform Basis gruppiert sind.

Funktionale Cluster:

  • Zusammenstellung von Funktionalitäten der Adaptive Plattform
  • Definition der Clusterung von Anforderungsspezifikationen
  • Beschreibung des Verhaltens der Softwareplattform aus Anwendungs- und Netzwerksicht
  • Beschränkt jedoch nicht das endgültige Software-Design der Architektur, die die Adaptive Plattform implementiert.

Funktionale Cluster in der AUTOSAR Adaptive Plattform müssen mindestens eine Instanz über einer (virtuelle) Maschine sein, während die Dienste im fahrzeuginternen Netzwerk verteilt werden können.

Adaptive Plattform-Dienste umfassen:

  • Update- und Konfigurationsverwaltung
  • Statusverwaltung
  • Netzwerk Management
  • Diagnose

Die AUTOSAR Adaptive Plattform enthält sowohl Spezifikation als auch Code. Im Vergleich zur Classic Plattform entwickelt AUTOSAR eine Implementierung, um den Validierungszyklus zu verkürzen und die zugrunde liegenden Konzepte zu veranschaulichen. Diese Implementierung steht allen AUTOSAR-Partnern zur Verfügung.[12]

Foundation Bearbeiten

Der Zweck der Foundation ist die Gewährleistung der Interoperabilität zwischen den AUTOSAR-Plattformen. Die Foundation enthält gemeinsame Anforderungen und technische Spezifikationen (z. B. Protokolle) für die AUTOSAR-Plattformen sowie die gemeinsame Methodik.[13]

Organisation Bearbeiten

AUTOSAR definierte sechs verschiedene Arten der Mitgliedschaft. Der Beitrag der Partner variiert je nach Art der Partnerschaft:[14][15]

  • Premium Partner Plus
  • Premium Partner
  • Development Partner
  • Associate Partner
  • Attendees
  • Subscribers

Core-Partner sind die Gründungspartner Bayrische Motoren Werke, Robert Bosch GmbH, Continental AG, Mercedes-Benz Group AG, Ford Motor Company, General Motors Holding LLC, Peugeot Citroën Automobiles S.A., Toyota Motor Corporation und Volkswagen AG.[14] Diese Unternehmen sind verantwortlich für die Organisation, Verwaltung und Kontrolle der AUTOSAR-Entwicklungspartnerschaft.[15] In diesem Kern definiert der Vorstand die Gesamtstrategie und den Fahrplan.[15] Der Steuerkreis verwaltet alltägliche nichttechnische Vorgänge und die Zulassung von Partnern, Öffentlichkeitsarbeit und Vertragsangelegenheiten.[16] Der Vorsitzende und der stellvertretende Vorsitzende, die für ein Jahr ernannt werden, vertreten zu diesem Zweck den Steuerkreis.[15] Der AUTOSAR-Sprecher übernimmt die Kommunikation mit der Außenwelt.[17]

Premium Partner Plus unterstützen das Projektleiter-Team in den vielfältigen technischen, organisatorischen und alltäglichen Prozessen. Ebenso geben sie neuen strategischen Input in die Projektleiterrunde. Premium- und Development-Partner tragen zu Arbeitspaketen bei, die von den Kernpartnern eingerichteten Projektleiterteam koordiniert und überwacht werden. Associate-Partner nutzen die Standarddokumente, die AUTOSAR bereits veröffentlicht hat. Attendees nehmen derzeit an akademischen Kooperationen und nicht-kommerziellen Projekten teil. Die Subscriber Mitgliedschaft richtet sich an Einzelpersonen, die sich an der Spezifikationsarbeit beteiligen wollen.[15]

Seit 2024 nehmen mehr als 360 Unternehmen an der AUTOSAR-Entwicklungspartnerschaft teil.[18]

Konferenzen Bearbeiten

Es existieren diverse Konferenzen und Meetings, z. B. die AUTOSAR OPEN CONFERENCE, welche im Juni 2024 zum 15. mal geplant ist.[19]

Literatur Bearbeiten

  • Oliver Scheid: AUTOSAR Compendium – Part 1: Application & RTE. 2015, ISBN 978-1-5027-5152-2.
  • Olaf Kindel, Mario Friedrich: Softwareentwicklung mit AUTOSAR. Grundlagen, Engineering, Management für die Praxis. dpunkt.verlag, 2009, ISBN 978-3-89864-563-8.
  • Werner Zimmermann, Ralf Schmidgall: Bussysteme in der Fahrzeugtechnik – Protokolle, Standards und Softwarearchitektur. 5. Auflage. Springer Vieweg, 2014, ISBN 978-3-658-02418-5.
  • Jörg Schäuffele, Thomas Zurawka: Automotive Software Engineering: Grundlagen, Prozesse, Methoden und Werkzeuge effizient einsetzen. 5. Auflage. Springer Vieweg, 2013, ISBN 978-3-8348-2469-1.

Siehe auch Bearbeiten

Weblinks Bearbeiten

Einzelnachweise Bearbeiten

  1. ↑ Elektrobit Automotive: AUTOSAR. Abgerufen am 17. November 2015.
  2. ↑ AUTOSAR. Abgerufen am 24. Februar 2020.
  3. ↑ a b AUTOSAR: History. Abgerufen am 24. Februar 2020.
  4. ↑ AUTOSAR – The worldwide automotive standard for e/e systems. In: ATZextra. Oktober 2013, S. 7.
  5. ↑ AUTOSAR development cooperation: AUTOSAR R20-11 Release Event. Abgerufen am 9. Dezember 2020 (englisch).
  6. ↑ AUTOSAR: General Information. Abgerufen am 15. Februar 2023 (englisch).
  7. ↑ AUTOSAR CP: Layered Software Architecture. Abgerufen am 15. Februar 2023 (englisch).
  8. ↑ AUTOSAR: Methodology. Archiviert vom Original am 19. Dezember 2015; abgerufen am 17. November 2015.
  9. ↑ AUTOSAR: Acceptance Test. Abgerufen am 24. Februar 2020.
  10. ↑ AUTOSAR: Technical Overview. Archiviert vom Original am 19. Dezember 2015; abgerufen am 17. November 2015.
  11. ↑ AUTOSAR: Application Interface. Abgerufen am 24. Februar 2020.
  12. ↑ AUTOSAR: Adaptive Platform. Abgerufen am 24. Februar 2020.
  13. ↑ AUTOSAR: Foundation. Abgerufen am 24. Februar 2020.
  14. ↑ a b AUTOSAR: Current Partners. Abgerufen am 15. Februar 2023 (englisch).
  15. ↑ a b c d e AUTOSAR: Organization. Abgerufen am 15. Februar 2023.
  16. ↑ Rüping turnusmäßig neuer Sprecher bei AUTOSAR. In: auto-presse.de. Abgerufen am 17. November 2015.
  17. ↑ AUTOSAR – The worldwide automotive standard for e/e systems. In: ATZextra. Oktober 2013, S. 6–7.
  18. ↑ AUTOSAR: History. Abgerufen am 15. Februar 2023 (englisch).
  19. ↑ AUTOSAR development cooperation: News & Events. Abgerufen am 21. Februar 2024 (englisch).
Abgerufen von „https://de.wikipedia.org/w/index.php?title=AUTOSAR&oldid=242419158“