AUTOSAR – das hat jeder schon mal gehört, der sich mit Software-Entwicklung im Automobilbereich befasst. Bezeichnet wird damit ein Standard für Software-Architektur, auf dessen Vorgaben beruhend in weiteren Schritten Basis-Software (bei AUTOSAR Classic) und Middleware entwickelt und von spezifischen Stack Vendors vertrieben wird. Grob einordnen lässt sich die Beschäftigung mit AUTOSAR in die Abteilung Embedded Systems. Aber was ist AUTOSAR genau? Was unterscheidet Classic von Adaptive? Was macht man damit und wie kann das Kosten sparen? Wir beantworten diese und weitere Fragen kurz und bündig, geben Beispiele und Ausblicke in die Zukunft und informieren rund ums Thema – viel Spaß!
- AUTOSAR – was genau ist das?
- Strukturelle Betrachtung von AUTOSAR – Die Schichten
- Details sind wichtig: AUTOSAR Classic erklärt
- Details sind dynamisch: AUTOSAR Adaptive erklärt
- AUTOSAR Classic vs Adaptive: Der Vergleich
- Und was jetzt? AUTOSAR in der Zukunft – immer noch Hunger?
- Auswirkungen von AUTOSAR auf die Softwareentwicklung
- AUTOSAR (Classic und Adaptive): Das Fazit (es musste ja so kommen)
Marc
Marketing Professional
20.07.23
Ca. 21 min
AUTOSAR – was genau ist das?
AUTOSAR (Automotive Open System Architecture) ist ein industrieller Standard für Software-Architektur, der von einer Gruppe von Automobilherstellern, Zulieferern und Elektronikunternehmen ins Leben gerufen wurde. Gedacht wurde er, um die Komplexität und Inkompatibilität von Elektronik- und Softwarekomponenten in modernen Fahrzeugen zu reduzieren. Unter den beteiligten Unternehmen waren beispielsweise BMW, Bosch, Continental, Daimler, Ford, General Motors, PSA, Toyota und Volkswagen.
AUTOSAR hat das grundsätzliche Potenzial, enorme Einsparungen zu erzielen, indem es – zumindest in der Theorie – die Entwicklungszeit verkürzt, die Wiederverwendbarkeit von Code erhöht und die Kompatibilität von Komponenten verbessert. Laut einer Studie des Beratungsunternehmens McKinsey können die Einsparungen durch den Einsatz von AUTOSAR in der Automobilbranche bis zu 30% betragen. Es sollte aber auch erwähnt werden, dass dies theoretische Vorstellungen sind, die in der Praxis mitunter abweichen können, und dass die Möglichkeit zur plattformübergreifenden Entwicklung der größere Vorteil ist.
AUTOSAR Adaptive, das im Jahr 2016 eingeführt wurde, unterscheidet sich von der ursprünglichen Classic-Version durch die Möglichkeit, die Funktionalität von Softwarekomponenten während der Laufzeit zu ändern. Dies ermöglicht eine flexiblere Nutzung von Ressourcen und erleichtert die Integration von neuen Funktionen und Komponenten – und das ist wichtig, denn: Die Anforderungen an Steuergeräte haben sich durch z.B. Connected Cars und autonomes Fahren geändert. Fahrzeuge müssen hochvernetzt sein und in der Lage, mit Cloudbasierten Services zu kommunizieren. Außerdem müssen ECUs (Electronical Control Unit = Steuergerät) in der Lage sein, komplexe ADAS Algorithmen (Advance Driver Assistance System) zu berechnen, wodurch die Anforderungen an die Rechenleistung steigen. Daraus resultieren weitere Hardware-Architekturen, die ihrerseits neue Anforderungen an Software haben, die AUTOSAR Classic nicht erfüllen konnte. Grund hierfür ist, dass Classic-Plattformen (ECUs) Microcontroller-basiert sind, während Adaptive-Plattformen CPU-basiert sind, Stichwort High Performance Computing.
Für weitere Informationen zu AUTOSAR und seinen Anwendungen im Detail könnt ihr die offizielle Website von AUTOSAR besuchen: www.autosar.org. Wir konzentrieren uns in diesem Artikel nun aber vor allem auf die strukturellen Eigenheiten von AUTOSAR und stellen die Frage, wie zukunftsträchtig AUTOSAR als Basis für Domänen-Middleware bleiben wird, nicht zuletzt auch im Angesicht des Aufkommens neuer Player wie beispielsweise Apex.AI.
Strukturelle Betrachtung von AUTOSAR – Die Schichten
AUTOSAR definiert eine Standardarchitektur für die Softwareentwicklung in der Automobilbranche. AUTOSAR Classic ist dabei in drei Schichten aufgeteilt: Die Anwendungsschicht, die Basissoftware-Schicht und die Laufzeitschicht. Innerhalb jeder Schicht werden verschiedene Module definiert, die spezifische Funktionalitäten bereitstellen. Das hauptsächliche Konzept hierbei ist, dass die Applikationen in der Anwendungsschicht unabhängig von Hardware und somit leichter portierbar sind. Die Basissoftware-Schicht umfasst Module für die grundlegende ECU-Funktionalität, wie den Zugriff auf Sensoren und Aktoren, die Signalverarbeitung und die Netzwerkfunktionen. Die Laufzeitschicht (Runtime Environment) ist für die Ausführung von Anwendungen und Basissoftware zuständig und stellt somit die Laufzeit-Infrastruktur für AUTOSAR dar.
Im Vergleich dazu führte AUTOSAR Adaptive eine völlig neue Architektur ein. Besonders nennenswert ist dabei die Service-Schicht, die es ermöglicht, Funktionalitäten während der Laufzeit zu ändern und somit eine höhere Flexibilität bei der Entwicklung und Integration neuer Funktionen bietet.
Anwendungsbeispiele für die AUTOSAR-Architektur sind zahlreich. Beispielsweise verwendet Continental AUTOSAR zur Integration von Elektromotoren in Hybrid- und Elektrofahrzeuge, um eine einheitliche Steuerung der Motoren und die effiziente Nutzung der Batterien zu gewährleisten – was nicht bedeutet, dass sich diese Funktionen nicht auch anderweitig umsetzen ließen. Indes sind dies typische Funktionen für AUTOSAR. Die Firma Bosch setzt AUTOSAR aktuell zum Beispiel bei der Entwicklung von Fahrerassistenzsystemen ein, um eine einheitliche Verarbeitung der Sensorsignale und eine einfachere Integration in das Gesamtsystem zu erreichen.
Details sind wichtig: AUTOSAR Classic erklärt
AUTOSAR Classic wurde ursprünglich eingeführt, um die Komplexität der Softwareentwicklung in der Automobilbranche zu reduzieren. Durch die Definition einer Standardarchitektur konnten verschiedene Unternehmen miteinander kompatible Softwaremodule entwickeln. Ein Beispiel dafür ist die Zusammenarbeit zwischen BMW und Continental, die eine gemeinsame Plattform für die Fahrzeugelektronik entwickelt haben, die auf der AUTOSAR Classic -Architektur basiert. AUTOSAR Classic ist in der Regel auf festgelegte Funktionen und Eigenschaften beschränkt, bietet jedoch eine bessere Kontrolle über den Speicherplatz und die Prozessor-Auslastung. Laut Schätzungen von IHS Markit können Unternehmen, die AUTOSAR Classic einsetzen, die Entwicklungszeit um bis zu 20 Prozent reduzieren und die Softwarekosten um bis zu 30 Prozent senken.
Das bringt beinahe automatisch neue Fragen mit sich, beispielsweise: Kann AUTOSAR Classic nur für festgelegte Funktionen und Eigenschaften verwendet werden oder kann es auch für die Implementierung neuer Funktionen eingesetzt werden? Welche Vorteile bietet AUTOSAR Classic gegenüber anderen Architekturen in der Automobilbranche?
Ein Vorteil ist der bislang aufgebaute Erfahrungsschatz mit AUTOSAR Classic. Auch wenn AUTOSAR Adaptive grundlegend für völlig andere Hardware-Architekturen und deren Anforderungen konzipiert ist, lassen sich doch Basis-Vorgehen aus der Classic-Version in die Entwicklung nach Adaptive-Standard übertragen. Nicht unbedingt copy/paste, da wie gesagt andere Anforderungen bestehen, aber der grundsätzliche Aufbau lässt sich übertragen. So kann AUTOSAR Classic ein Stück weit auch mit neuen Funktionen mithalten, auch wenn dies eher im übertragenen Sinne zu verstehen ist – ohne AUTOSAR Adaptive wären viele Anforderungen aus der Industrie nicht mehr umsetzbar.
Zur zweiten Frage wird erwartet, dass sich AUTOSAR in Zukunft weiterentwickeln wird, um den Anforderungen neuer Technologien und Branchenstandards gerecht zu werden. Ein Beispiel dafür ist die Integration von 5G-Konnektivität, die es ermöglichen wird, fortschrittlichere Funktionen wie selbstfahrende Fahrzeuge zu unterstützen. Darüber hinaus könnten auch neue Anwendungen wie intelligente Verkehrssysteme und vernetzte Mobilität durch AUTOSAR ermöglicht werden.
So setzen beispielsweise Unternehmen wie BMW oder Daimler bei der Entwicklung von Software in der Automobilbranche auf AUTOSAR-basierte Module. Ein Beispiel ist das „AUTOSAR COM Stack„, das bei der Kommunikation zwischen den verschiedenen Steuergeräten im Fahrzeug verwendet wird und von verschiedenen Unternehmen wie Vector oder Elektrobit bereitgestellt wird. Ein weiteres Beispiel ist die „AUTOSAR Basic Software„, die von Continental entwickelt wurde und eine Vielzahl von Basisfunktionen wie Speicherverwaltung, Treiber und Netzwerk-Stacks bereitstellt – diese Basisschicht muss jeder Hersteller entwickeln und vereinfacht somit die Interoperabilität zwischen verschiedenen Entwicklerteams von beispielsweise Zulieferern und OEMs.
Details sind dynamisch: AUTOSAR Adaptive erklärt
AUTOSAR Adaptive bietet gegenüber AUTOSAR Classic den Vorteil einer zusätzlichen Service-Schicht, die dynamische Funktionen in die Software integrieren kann. Der Vollständigkeit halber sei der „Vorteil“ in Anführungszeichen gesetzt, da eine Gegenüberstellung in dieser Form so gar nicht möglich ist. Schließlich, wie bereits erarbeitet, bedienen AUTOSAR Classic und Adaptive schlicht unterschiedlich Anforderungen für unterschiedliche Hardware-Architekturen. Nichtsdestotrotz ermöglicht AUTOSAR Adaptive insgesamt eine höhere Flexibilität bei der Implementierung von neuen Funktionen, was besonders in zukünftigen Anwendungen wie autonomen Fahrzeugen von Bedeutung ist. Ein Beispiel für eine dynamische Funktion, die in Adaptive AUTOSAR integriert werden kann, ist die Software-Überwachung des Fahrzeugzustands. Durch die kontinuierliche Überwachung des Zustands des Fahrzeugs können potenzielle Probleme frühzeitig erkannt werden, was zu einer höheren Sicherheit und Zuverlässigkeit führt, Stichwort „predictive maintenance“.
AUTOSAR Classic vs Adaptive: Der Vergleich
Die größten Unterschiede zwischen AUTOSAR Classic und AUTOSAR Adaptive haben wir im Verlauf bereits ausreichend erarbeitet, daher fassen wir hier nur noch einmal kurz zusammen: Der Hauptunterschied zwischen AUTOSAR Classic und Adaptive liegt in ihrer Architektur. Beide sind standardisiert, bedienen aber unterschiedliche Hardware-Architekturen und deren Anforderungen, arbeiten also meist schlicht in verschiedenen Anwendungsgebieten. Ein Beispiel für eine dynamische Funktion könnte das automatische Einparken bei Autos sein, das in Echtzeit erfolgt. Adaptive bietet hierfür eine zusätzliche Service-Schicht und die Möglichkeiten, Applikationen per UCM während der Laufzeit nachzuladen oder zu konfigurieren.
Classic ist im Vergleich etwas eingeschränkter und kann zwar ebenfalls mit hinzugefügten Funktionen arbeiten, allerdings nicht während der Laufzeit. Außerdem muss stets ein komplettes Steuergeräteupdate vorgenommen werden, während UCM (Update and Configuration Management) auch einzelne Applikationen mit partiellen Updates versorgen kann.
Obwohl AUTOSAR Adaptive also mehr Freiheit bei der Implementierung neuer Funktionen bietet, ist es auch komplexer und erfordert mehr Ressourcen, vor allem hinsichtlich der Rechenleistung als Classic. Bedauerlicherweise wird AUTOSAR (anders als beispielsweise das bekannte ROS alias „Robotic Operating System„) nicht an den Universitäten unterrichtet, so dass hier auch eine etwas höhere Einstiegshürde in den Beruf besteht (der üblicherweise im Bereich Embedded Systems Engineering liegt). Positiv erwähnt sei an dieser Stelle allerdings die TU Darmstadt, die dies geändert hat und nun auch AUTOSAR-Kenntnisse vermittelt.
Und was jetzt? AUTOSAR in der Zukunft – immer noch Hunger?
AUTOSAR hat sich in den letzten Jahren zu einem unverzichtbaren Standard der Automobilbranche entwickelt. Die Einführung von AUTOSAR Adaptive hat die Flexibilität und Funktionalität des Standards verbessert und eröffnet neue Möglichkeiten für die Entwicklung von Software in der Automobilindustrie. Schließlich sind die zunehmende Vernetzung von Fahrzeugen und die Integration von autonomen Funktionen ein höchst aktueller Trend, dessen Ansprüche an die Entwicklung und deren Flexibilität deutlich gestiegen sind. AUTOSAR Adaptive wurde hauptsächlich für genau diese Herausforderungen eingeführt, um die Entwicklung von intelligenten Fahrzeugen zu beschleunigen.
Doch was bedeutet das konkret? Unternehmen wie BMW und Daimler nutzen bereits AUTOSAR-basierte Softwaremodule, um sicherzustellen, dass ihre Fahrzeuge über die neuesten und besten Funktionen verfügen. BMW setzt beispielsweise AUTOSAR-Softwaremodule ein, um Funktionen wie autonomes Fahren, Navigation und Unterhaltung in ihre Fahrzeuge zu integrieren. Ein weiteres Beispiel ist die Daimler AG, die ebenfalls AUTOSAR-basierte Softwaremodule für ihre elektronischen Steuergeräte einsetzt.
Woher rührt also die Aussage, die durchaus in der einen oder anderen Automotive-Kantine zu hören ist, dass AUTOSAR ein „jahrzehntealter Standard, der in die Tage gekommen“ sei? Vermutlich stammen derlei Aussagen aus dem reinen Druck der Innovation, oder auch wenig Erfahrung mit den vielseitigen Optionen der Entwicklung nach AUTOSAR Adaptive. Der Standard ist keine einmalig festgelegte Definition, die nun abgeschlossen ist. Vielmehr handelt es sich um ein „lebendes Dokument“, das ständig weiterentwickelt wird – eine wichtige Aufgabe beispielsweise des AUTOSAR Konsortiums und der beteiligten OEMs und Zulieferer, darunter teils auch Premium Partner, die erfahren und gut vernetzt sind und den Standard mitunter augenzwinkernd als „continuous AUTOSAR“ betiteln.
Auch die hohe Interoperabilität, erklärter Zweck des Standards, dessen weite Verbreitung zwischen Fahrzeugherstellern und Zulieferern ist Grund für die aktuell schnelle Entwicklung, in der die deutsche Traditionsindustrie auch wieder internationale Innovationserfolge verzeichnet.
Gut, zugegeben: Die Einführung neuer Konzepte wie Vehicle API oder SOVD (Service Oriented Vehicle Diagnostics) könnte bisweilen etwas schneller vonstatten gehen – hier finden Kritiker einen Ansatzpunkt, der indes keinen der bislang genannten Punkte entkräften kann. Somit bleibt AUTOSAR auch in den kommenden Jahren zweifelsfrei der Platzhirsch für Softwareentwicklung in der Automobilindustrie.
Auswirkungen von AUTOSAR auf die Softwareentwicklung
AUTOSAR hat die Art und Weise, wie Software in der Automobilbranche entwickelt wird, grundlegend verändert. Früher mussten Entwickler jede Funktion von Grund auf neu implementieren, was zu hohen Zeitaufwand und Kosten führte. Heute können Entwickler dank AUTOSAR bestehende Funktionen wiederverwenden und neue Funktionen schneller und effizienter implementieren, und sie können die Entwicklung auch besser auf interne und externe Projektteams aufteilen, auf OEMs und Zulieferer: Alle Steuergeräte sprechen dank standardisierten Schnittstellen die gleiche Sprache und können also miteinander kommunizieren. Dies vereinfacht die Software-Entwicklung als auch Systemdesign und -integration erheblich – und senkt somit die Gesamtkosten für die Software-Entwicklung. Natürlich geht damit auch eine erhöhte Wartbarkeit und Sicherheit einher, ein Beispiel sind Over-the-Air-Updates, die vor allem in Zeiten von UNECER155 und Co. von immenser Bedeutung sind.
Gehen wir an dieser Stelle noch einmal ins Detail und nennen dazu konkrete Beispiele, um festzuhalten, wie elementar AUTOSAR für die branchenweiten Entwicklungsstandards ist:
Wir haben festgestellt, dass AUTOSAR „Layer“ besitzt, also „Abstraktionssschichten“, die die spezifischen Eigenschaften der Hardwareplattform durch standardisierte Schnittstellen abstrahiert. So können Microcontroller von unterschiedlichen Herstellern zwar abweichende Architekturen aufweisen, wodurch sich der Zugriff der Software auf die Hardware von Typ zu Typ unterscheiden kann. Durch die Implementierung der Schichten werden die diese spezifischen Eigenheiten der Hardware aber abstrahiert, was bedeutet, dass der Zugriff auf die Hardware zwar noch immer individuell ist, aber über „nach oben hin“ gleiche Schnittstellen verfügt. Anwendungen können dank dieser nun unabhängig von der Hardware genutzt und implementiert werden.
Ein konkretes Beispiel wäre, das Signal eines Input Pins (z.B. digital Ein/Aus, die Erkennung der Zündung im Fahrzeug betreffend, ob ein- oder ausgeschaltet). Um auf das Signal zugreifen zu können, müssen bestimmte Registeradressen aufgerufen werden, und diese Adressen sind in der Regel bei jedem Hersteller unterschiedlich. Ohne die beschriebenen Abstraction Layer müsste jede Applikation für jede unterschiedliche Hardware, auf der sie laufen soll, jedes Mal komplett neu implementiert werden. Dank AUTOSAR und dessen Abstraktionsschichten muss nur noch die jeweils „unterste“ Schicht angepasst werden – die Applikation selbst bleibt immer gleich und fragt in diesem Fall lediglich eine standardisierte Schnittstelle ab. Wieso AUTOSAR als Standard Zeit, Kosten, Ressourcen und Entwicklungsaufwand einsparen kann, liegt somit auf der Hand.
Eine in diesem Zusammenhang unbedingt lesenswerte Abhandlung über AUTOSAR ist übrigens die Publikation „AUTOSAR: A Comprehensive Automotive Software Architecture“ von M. Bauer und S. Fey, die viel zu sagen hat über Entstehung und vor allem Zukunftsaussichten dieses interessanten Standards.
AUTOSAR (Classic und Adaptive): Das Fazit (es musste ja so kommen)
Das Fazit fällt letztlich simpel aus, immerhin wurden die wichtigsten Eigenschaften des AUTOSAR Standards ausführlich etabliert und benannt. Insbesondere mit Blick auf die autonom fahrende Zukunft und, beinahe wichtiger, das allgegenwärtige Connected Car, ist die Zukunftsfähigkeit von AUTOSAR bis auf Weiteres gesichert. Wo AUTOSAR Classic sich zunehmend zurückhält und dem großen Bruder Adaptive das Feld überlässt, sind Interoperabilität, Kommunikation und Funktionalität wesentliche Entwicklungsbausteine. Ernsthafte Alternativen scheinen am automobilen Horizont dünn gesät, spielen theoretische Mitwettbewerber wie Apex.AI und Co. doch in grundlegend anderen Ligen und Anwendungsgebieten.
Noch dazu sind Weiterentwicklungen des Standards denkbar – ein Beispiel dafür ist die Konfiguration von AUTOSAR Software durch Manifeste (ARXML Dateien). Mit dem grundlegenden Ansatz „configuration before implementation“ sind Konfigurationen größtenteils mittels einfach bedienbarer Tools möglich, statt wie bisher direkt implementiert werden zu müssen. Stack Vendors verwenden dafür Code Generatoren und greifen auf einen deutlich größeren Schatz an Optionen zu als bislang. Ein modellbasierter Entwicklungsansatz und der Einsatz generativer K.I. wie „ChatGPT“, die die Manifeste generiert, könnte diesen Ansatz noch deutlich beschleunigen
Wenn ihr euch noch weiter informieren möchtet, empfehlen wir euch unsere Embedded Rubrik sowie, durchaus eng damit verbunden, interessante Themen wie Funktionale Sicherheit, Datenschutz oder Machine Learning. Viel Spaß und danke für eure Aufmerksamkeit!