Suchen

Automotive Software: Vertikalisierung versus Horizontalisierung

| Autor/ Redakteur: Dr.-Ing. Detlef Zerfowski * / Sebastian Gerstl

Die Automobilindustrie kämpft weiterhin mit den Veränderungen und den einhergehenden Herausforderungen. Der Übergang von klassischen Embedded-Steuergeräten hin cloudbasierten Lösungen stellt die entwickelnde Bereiche vor enorme Herausforderungen. Die Revolution der Automobil-Software-Industrie schreitet – zwangsweise – weiter voran.

Firmen zum Thema

Bild 1: Software ist nicht gleich Software. Unterschiedliche Arten von Software dringen in die Automotive Domäne ein.
Bild 1: Software ist nicht gleich Software. Unterschiedliche Arten von Software dringen in die Automotive Domäne ein.
(Bild: ETAS GmbH)

In dem auf dem ESE-Kongress 2017 vorgestellten Artikel „(R)Evolution der Automotive-Software-Architekturen. Wie neue Software-Technologien die Automobilindustrie verändern“ [2], wurde über die Auslöser der revolutionären Änderungen in der Automobil-Software-Industrie berichtet. Die in dem Artikel beschriebenen Tendenzen haben sich im vergangenen Jahr bestätigt.

Die Industrie kämpft weiterhin mit den Veränderungen und den einhergehenden Herausforderungen. Zum einen stellt der Übergang von Mikrocontroller-basierten, klassischen Embedded-Steuergeräten hin zu Mikroprozessor-basierten bzw. cloudbasierten Lösungen die entwickelnde Bereiche vor enorme Herausforderungen, z.B. wie die Kompetenzprofile der Software-Engineering-Bereiche zu ändern bzw. zu erweitern sind.

In Bild 1 [2] wird die Veränderung der benötigten Softwareprofile deutlich. Die stark durch signalbasierte Regelungsalgorithmen geprägte Software der „Deeply Embedded ECUs“ (Electronic Control Unit; Elektronisches Steuergerät) ist durch harte Realzeitanforderungen, Automotive SPICE (ASPICE), Entwicklung nach V-Model etc. charakterisiert.

Neue sich in Entwicklung befindlicher Fahrzeugrechner bauen auf völlig anderen aus der IT-Welt stammenden Betriebssytemen auf und führen neue Software-Engineering-Paradigmen in die Automobilindustrie ein. Die klassische Lastenheft-getriebene Komponentenentwicklung ändert sich bei Fahrzeugrechner immer stärker zu einer Separierung von Software und Hardware. Zusätzlich drängen zunehmend Anwendungen aus den Smartphone Eco-Systemen ins Fahrzeug (Bild 1, unten rechts).

Der technologischen Wandel in der Automobil-Software kommt gepaart mit organisatorischen Veränderungen, um die Herausforderungen adäquat adressieren zu können.

Wie bereits in [2] ausgeführt, sind wir hier mit einem Fall von „Conway’s Law“ [1] konfrontiert: „…organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.”

Das heißt, Produkte und deren Architekturen folgen den Organisationsstrukturen. Das bisherige Steuergerätekomponenten-orientierte embedded ECU-Geschäft ist dabei vertikal vom OEM bis zu den Zulieferern durchorganisiert. Beispiele hierfür sind die seit langem etablierten Zuordnungen von Funktionen auf dedizierte Steuergeräte, die wiederum in den seit Langem etablierten Domänen und Organisationen angesiedelt sind.

Vom Mikrocontroller mit klassischem AUTOSAR zum Mikroprozessor mit AUTOSAR adaptive

Bild 2: Conway's Law trifft die Automobilindustrie.
Bild 2: Conway's Law trifft die Automobilindustrie.
(Bild: ETAS GmbH)

Die zuvor beschriebene embedded Entwicklung erfolgt stark vertikalisiert. Die Ziel-Hardware legt die maximal verfügbaren Ressourcen fest, die über zeitscheibenorientierte Realzeitbetriebssysteme, die raren Rechnerressourcen den Software-Funktionalitäten zur Verfügung stellen. Auch die Kommunikationsstrukturen zwischen den unterschiedlichen Komponenten im Fahrzeug sind sehr stark eingeschränkt. Zentrale Designelemente sind statisch vorgegebene CAN-Matrizen, die bereits zur Entwicklungszeit festlegen, welche Botschaft in welchem Zeitraster an wen gesendet wird.

Auch auf höherer Funktionsebene ist diese Struktur erkennbar. Einmalig an Steuergeräte zugewiesene Funktionen lassen sich später nicht, bzw. nur mit sehr hohen Aufwänden über Steuergerätegrenzen hinweg verschieben.

Ein wesentlicher Vorteil dieses Ansatzes liegt andererseits im erzwungenen Determinismus des Steuergeräteverhaltens und die hierdurch leichter zu beherrschenden Safety-Anforderungen. Gleichzeitig behindert dieses Design jedoch die Einführung moderner, aus der IT-Industrie kommender Software-Technologien.

Natürlich wurden auch im Deeply-Embedded-Bereich Horizontalisierungsaspekte vorangetrieben. Als Beispiele seien hier Diagnose-Standards und AUTOSAR genannt. Aber auch in diesem Kontext gilt: Es handelt sich um einen zentral definierten Standard für Basis Software-Stacks für Mikrocontroller ECUs, der sich über viele Jahre hinweg entwickelt hat. Der Ansatz war, einen möglichst hohen Gleichanteil an hardwarenaher und applikationsunabhängiger Basis-Software zu Standardisierung. Im laufenden Betrieb ist damit eine Horizontalisierung von Funktionen jedoch nicht sichtbar.

Bild 3: Konnektivität, automatisiertes Fahren und Elektrifizierung verändern den Automobilsektor.
Bild 3: Konnektivität, automatisiertes Fahren und Elektrifizierung verändern den Automobilsektor.
(Bild: ETAS GmbH)

Mit den aufkommenden Mikroprozessor-basierten Fahrzeugrechnern ändert sich die Situation grundlegend. Durch die aktuellen Markanforderungen bzgl. Konnektivität, automatisiertes Fahren, Elektrifizierung (Bild 3) und neue Eigentümerkonzepte für Fahrzeuge ergeben sich massive Verschiebungen von Funktionalitäten zwischen den im Fahrzeug vorhandenen Rechnerknoten, sowie gänzlich neuer Funktionen, die auf Mikrocontroller-basierten Systemen effizient nicht darstellbar sind.

An dieser Stelle kommt der neue Standard AUTOSAR Adaptive zum Einsatz. Dieser auf Mikroprozessor-Systeme ausgerichtete Standard unterstützt z.B. dynamische Software-Änderungen, hoch-parallele Architekturen und Service-orientierte Kommunikation. Mit diesen Ansätzen werden Mikroprozessor-basierte Rechnern, neben den bereits existierenden Infotainment-Anwendungen nun auch für Funktionen mit höheren Safety-Anforderungen als im Infotainment-Umfeld geöffnet (Bild 4).

Bild 4: AUTOSAR Adaptive schließt die Lücke zwischen klassischem AUTOSAR und Infotainment.
Bild 4: AUTOSAR Adaptive schließt die Lücke zwischen klassischem AUTOSAR und Infotainment.
(Bild: ETAS GmbH)

Auf Grund des dramatischen Anstiegs der verfügbaren Rechnerressourcen (z.B. mehr als 1000facher Speicher) beim Übergang von Mikrocontroller- zu Mikroprozessor-Systemen müssen andere Basis-Software-Systeme und Entwicklungsmethoden verwendet werden. Der Einsatz von aus der Konsumerelektronik stammenden POSIX Betriebssystemen ist ein absolutes Muss.

Hierbei ist zu bemerken, dass es nicht das Ziel ist, dass AUTOSAR Adaptiv das klassische AUTOSAR ablösen wird. Beide Systeme werden in Fahrzeugen koexistieren (Bild 5), da für realzeitkritische Anwendungen reine Mikroprozessor-Systeme nicht geeignet sind. Schätzungen gehen davon aus, dass weniger als 10% der im Fahrzeug verbauten Steuergeräte Mikroprozessor-basierte Fahrzeugrechner sein werden, diese werden jedoch den bei weitem größtem Anteil der Fahrzeugsoftware tragen.

Bild 5: AUTOSAR Adaptive und klassisches AUTOSAR bleiben parallel im Fahrzeug.
Bild 5: AUTOSAR Adaptive und klassisches AUTOSAR bleiben parallel im Fahrzeug.
(Bild: ETAS GmbH)

Damit ist die Grundlage für eine stärkere Horizontalisierung der Software innerhalb des Fahrzeuges gelegt. Die Entkopplung der Software von der Hardware durch Verwendung Service orientierter Architekturen unterstützt einen deutlich modularisierteren Aufbau darüber liegender Software-Schichten.

Horizontalisierung am Beispiel Security

Das Thema der steigenden Horizontalisierung lässt sich in diesem Zusammenhang am Beispiel Security verdeutlichen. In der Vergangenheit waren Fahrzeuge „implizit“ durch die Fahrzeuggrenzen geschützt. Um unberechtigten Zugang im Fahrzeugnetzwerk zu erlangen, war der physikalische Zugriff auf das Fahrzeug notwendig. Entsprechend konnte nur das konkret attackierte Fahrzeug manipuliert werden.

Mit der zunehmenden Konnektivität verändert sich der Angriffsvektor vollständig (Bild 6). Der physikalische Zugriff auf das Fahrzeug ist nicht mehr zwingend erforderlich und bei einem erfolgreichen Angriff ist potentiell eine große Menge an Fahrzeugen unmittelbar betroffen.

Bild 6: Security-Angriffsvektoren verändern sich.
Bild 6: Security-Angriffsvektoren verändern sich.
(Bild: ETAS GmbH)

Um dieser Situation zu begegnen, müssen Sicherheitskonzepte und –lösungen etabliert werden, die nicht an ECU-Grenzen haltmachen. Mehrstufige Sicherheitskonzepte sind erforderlich. Diese können auch nicht auf Teile der in den Steuergeräten verwendeten Software begrenzt sein. So stellen die aktuellen Security-Anforderungen im klassischen AUTOSAR einen wichtigen Baustein dar, sind aber nicht ausreichend wenn es darum geht Security-Anforderungen zwischen AUTOSAR basierten und anderen Steuergeräten und Fahrzeugrechnern sicherzustellen. Dabei sind ganzheitliche Ansätze erforderlich, wie sie die ETAS Tochter ESCRYPT bereitstellt. Das ETAS bereits vor mehreren Jahren ein eigenes Unternehmen für Automotive-Security am Markt etabliert hat, verdeutlicht die Notwendigkeit für die Horizontalisierung des Themengebietes Security.

Mit der Einführung der Fahrzeugrechner müssen folgende Herausforderungen adressiert werden:

  • Deutlich mehr potentielle Einfalltüren für Angreifer müssen abgesichert werden.
  • Dynamische Kommunikationsinfrastrukturen erfordern den Einsatz von Security-Maßnahmen aus der IT-Industrie.
  • Die Integrität von sich in der E/E-Architektur dynamisch verändernder Software muss sichergestellt werden.
  • Security-Maßnahmen müssen etabliert werden, die cross-ECU und über Fahrzeuggrenzen hinweg wirken.
  • Security-Updates müssen über die Luftschnittstelle über den Lebenszyklus des Fahrzeugs bereitstehen.

Bild 7: Auswirkung wenn Security nicht funktioniert.
Bild 7: Auswirkung wenn Security nicht funktioniert.
(Bild: ETAS GmbH)

Bei all diesen Herausforderungen muss sichergestellt werden, dass alle im Fahrzeug verbauten Komponenten und deren Schnittstellen nach außen einwandfrei aus Security-Sicht funktionieren. Ein einzelnes Steuergerät kann bei einer fehlerhaften Kommunikation das ganze E/E-Netzwerk lahmlegen (Bild 7).

Hieraus ergibt sich zwingend, dass Security kein Steuergeräte-spezifisches Thema ist, sondern sich über deren Grenzen hinweg, über das gesamte Fahrzeug, bis in Fertigungsabläufe beim OEM und Tier1 auswirkt.

RTA-VRTE und AUTOSAR Adaptive

Wie bereits weiter oben erwähnt, stellt AUTOSAR Adaptive einen zentralen Baustein für Fahrzeugrechner dar und wird die Horizontalisierung der Software im Fahrzeug weiter vorantreiben. Dabei wurde nur eine Instanz einer AUTOSAR Adaptive auf einem Fahrzeugrechner betrachtet. Solange auf einem Fahrzeugrechner nur eine einzelne Anwendungsdomäne abläuft, ist der Einsatz einer AUTOSAR Adaptive Software mit geeignetem POSIX Betriebssystem als Basis-Software möglicherweise ausreichend.

Bezüglich der Anforderungen aus zukünftigen E/E-Architekturen ist AUTOSAR Adaptive ein erster notwendiger, aber nicht ausreichender Schritt.

Zukünftige Fahrzeugrechner, die als Integrationsplattformen für Software-Funktionen aus unterschiedlichen Bereichen, mit unterschiedlichen ASIL-Anforderungen stammen, benötigen Plattformen, die diesen unterschiedlichen Safety-Anforderungen genüge tragen.

Bild 8: VRTE jenseits von AUTOSAR Adaptive.
Bild 8: VRTE jenseits von AUTOSAR Adaptive.
(Bild: ETAS GmbH)

Es werden flexible Plattformen benötigt, die über gemischte Mikrocontroller-Mikroprozessor-Systeme unter Verwendung von Hypervisor-Technologien und damit über das klassische AUTOSAR und AUTOSAR Adaptive skalieren (Bild 8).

Des Weiteren wird die Unterstützung von Hypervisor-Lösungen benötigt, auf denen gemischte ASIL-Anwendungen mit unterschiedlichen Betriebssystemen auf demselben Fahrzeugrechner laufen. Dies erzwingt entsprechende Plattformkonzepte um sowohl Safety- und Security-Anforderungen (z.B. Freedom from Interference) zu erfüllen.

Aus diesem Grund entwickeln BOSCH und ETAS die RTA-VRTE (Real-Time-Application Vehicle Run Time Environment), welche AUTOSAR Adaptive konform ist und zusätzliche, cross-ECU relevante Plattformfunktionen bereitstellt. Dabei wird besonderes Augenmerk auf ein offenes, flexibles Framework gelegt, so dass eine einfache Integration von 3rd-Party-Software unterstützt wird.

Bild 9: Unterschiedliche Software-Ebenen (L1 bis L5) adressiert durch die VRTE.
Bild 9: Unterschiedliche Software-Ebenen (L1 bis L5) adressiert durch die VRTE.
(Bild: ETAS GmbH)

Die VRTE stellt somit ein weiteres Beispiel für die Software-Horizontalisierung im Automobil-Sektor dar. Zukünftige Fahrzeugrechner werden somit aus einer Menge horizontaler Software-Anteile, sowie vertikaler Software-Anteile innerhalb der Anwendungsdomänen aufgebaut sein. Hieraus ergibt sich eine Aufteilung und Verschiebung von Verantwortlichkeiten bis hin zu organisatorischen Änderungen, um den Auswirkungen von Conway’s Law entgegenzuwirken.

Zusammenfassung

Mit dem Einzug der Mikroprozessor-basierten Fahrzeugrechnern setzt sich die Separierung der Software von der Hardware fort. Gleichzeitig wird eine deutlich stärkere Separierung der Software in horizontale und vertikale Anteile auftreten, die auch zu organisatorischen Änderungen in Unternehmen der Automobilindustrie führen.

Literaturverzeichnis

[1] Conway, Melvin E. (1968): How do committees invent?
[2] Detlef Zerfowski, S K Niranjan: „(R)Evolution der Automotive-Software-Architekturen. Wie neue Software-Technologien die Automobilindustrie verändern.”

Dieser Beitrag stammt aus dem Tagungsband zum ESE Kongress 2018.

* Dr.-Ing. Zerfowski ist im Corporate Sector Automotive System Integration für die strategische Ausrichtung der Software-Themen im Automotive-Bereich der Firma Bosch verantwortlich.

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de (ID: 46267437)