Autor: Dr.-Ing. Detlef Zerfowski, ETAS GmbH<\/p>\n
In dem auf dem ESE-Kongress 2017 vorgestellten Artikel „(R)Evolution der Automotive-Software-Architekturen. Wie neue Software-Technologien die Automobilindustrie ver\u00e4ndern“ [2] wurde \u00fcber die Ausl\u00f6ser der revolution\u00e4ren \u00c4nderungen in der Automobil-SW-Industrie berichtet. Die in dem Artikel beschriebenen Tendenzen haben sich im vergangenen Jahr best\u00e4tigt. Die Revolution der Automobil-SW-Industrie schreitet weiter voran.<\/strong><\/p>\n Die Industrie k\u00e4mpft weiterhin mit den Ver\u00e4nderungen und den einhergehenden Herausforderungen. Zum einen stellt der \u00dcbergang von \u00b5-Controller-basierten, klassischen embedded Steuerger\u00e4ten hin zu \u00b5-Prozessor-basierten bzw. cloudbasierten L\u00f6sungen die entwickelnden Bereiche vor enorme Herausforderungen, z.B. wie die Kompetenzprofile der Software-Engineering-Bereiche zu \u00e4ndern bzw. zu erweitern sind.<\/p>\n In Abbildung 1 (s.\u00a0PDF<\/a>) [2] wird die Ver\u00e4nderung der ben\u00f6tigten Softwareprofile deutlich. Die stark durch signalbasierte Regelungsalgorithmen gepr\u00e4gte Software der „Deeply Embedded ECUs“ ist durch harte Realzeitanforderungen, Automotive SPICE (ASPICE), Entwicklung nach V-Model etc. charakterisiert.<\/p>\n Neue sich in der Entwicklung befindliche Fahrzeugrechner bauen auf v\u00f6llig anderen, aus der IT-Welt stammenden Betriebssytemen auf und f\u00fchren neue SW-Engineering-Paradigmen in die Automobilindustrie ein. Die klassische Lastenheft-getriebene Komponentenentwicklung \u00e4ndert sich bei Fahrzeugrechner immer st\u00e4rker zu einer Separierung von SW und HW.<\/p>\n Zus\u00e4tzlich dr\u00e4ngen zunehmend Anwendungen aus den Smartphone-Ecosystemen ins Fahrzeug (Abbildung 1 unten rechts).<\/p>\n Der technologischen Wandel in der Automobil-Software kommt gepaart mit organisatorischen Ver\u00e4nderungen, um die Herausforderungen ad\u00e4quat adressieren zu k\u00f6nnen.<\/p>\n Siehe Abbildung 2 (PDF<\/a>)<\/p>\n Wie bereits in [2] ausgef\u00fchrt, sind wir hier mit einem Fall von „Conway\u2019s Law“ [1] konfrontiert:<\/p>\n „\u2026organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.“<\/em><\/p>\n Das hei\u00dft, Produkte und deren Architekturen folgen den Organisationsstrukturen. Das bisherige Steuerger\u00e4tekomponenten-orientierte embedded ECU-Gesch\u00e4ft ist dabei vertikal vom OEM bis zu den Zulieferern durchorganisiert. Beispiele hierf\u00fcr sind die seit langem etablierten Zuordnungen von Funktionen auf dedizierte Steuerger\u00e4te, die wiederum in den seit Langem etablierten Dom\u00e4nen und Organisationen angesiedelt sind.<\/p>\n Die zuvor beschriebene embedded Entwicklung erfolgt stark vertikalisiert. Die Ziel-Hardware legt die maximal verf\u00fcgbaren Ressourcen fest, die \u00fcber zeitscheibenorientierte Realzeitbetriebssysteme die raren Rechnerressourcen den SW-Funktionalit\u00e4ten zur Verf\u00fcgung stellen. Auch die Kommunikationsstrukturen zwischen den unterschiedlichen Komponenten im Fahrzeug sind sehr stark eingeschr\u00e4nkt. Zentrale Designelemente sind statisch vorgegebene CAN-Matrizen, die bereits zur Entwicklungszeit festlegen, welche Botschaft in welchem Zeitraster an wen gesendet wird.<\/p>\n Auch auf h\u00f6herer Funktionsebene ist diese Struktur erkennbar. Einmalig an Steuerger\u00e4te zugewiesene Funktionen lassen sich sp\u00e4ter nicht bzw. nur mit sehr hohen Aufw\u00e4nden \u00fcber Steuerger\u00e4tegrenzen hinweg verschieben.<\/p>\n Ein wesentlicher Vorteil dieses Ansatzes liegt andererseits im erzwungenen Determinismus des Steuerger\u00e4teverhaltens und die hierdurch leichter zu beherrschenden Safety-Anforderungen. Gleichzeitig behindert dieses Design jedoch die Einf\u00fchrung moderner, aus der IT-Industrie kommender SW-Technologien.<\/p>\n Nat\u00fcrlich 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\u00fcr Basis-SW-Stacks f\u00fcr \u00b5-Controller-ECUs, der sich \u00fcber viele Jahre hinweg entwickelt hat.\u00a0 Der Ansatz war, einen m\u00f6glichst hohen Gleichanteil an hardwarenaher und applikationsunabh\u00e4ngiger Basis-SW zu standardisieren. Im laufenden Betrieb ist damit eine Horizontalisierung von Funktionen jedoch nicht sichtbar.<\/p>\n Mit den aufkommenden \u00b5-Prozessor-basierten Fahrzeugrechnern \u00e4ndert sich die Situation grundlegend.<\/p>\n Durch die aktuellen Markanforderungen bzgl. Konnektivit\u00e4t, automatisiertes Fahren, Elektrifizierung (Abbildung 3, s.\u00a0PDF<\/a>) und neue Eigent\u00fcmerkonzepte f\u00fcr Fahrzeuge ergeben sich massive Verschiebungen von Funktionalit\u00e4ten zwischen den im Fahrzeug vorhandenen Rechnerknoten sowie g\u00e4nzlich neue Funktionen, die auf \u00b5C-basierten Systemen effizient nicht darstellbar sind.<\/p>\n An dieser Stelle kommt der neue Standard AUTOSAR Adaptive zum Einsatz. Dieser auf \u00b5P-Systeme ausgerichtete Standard unterst\u00fctzt z.B. dynamische SW-\u00c4nderungen, hochparallele Architekturen und serviceorientierte Kommunikation. Mit diesen Ans\u00e4tzen werden \u00b5P-basierte Rechnern neben den bereits existierenden Infotainment-Anwendungen nun auch f\u00fcr Funktionen mit h\u00f6heren Safety-Anforderungen als im Infotainment-Umfeld ge\u00f6ffnet (Abbildung 4, s.\u00a0PDF<\/a>).<\/p>\n Aufgrund des dramatischen Anstiegs der verf\u00fcgbaren Rechnerressourcen (z.B. mehr als 1000facher Speicher) beim \u00dcbergang von \u00b5C- zu \u00b5P-Systemen m\u00fcssen andere Basis-SW-Systeme und Entwicklungsmethoden verwendet werden. Der Einsatz von aus der Konsumerelektronik stammenden POSIX-Betriebssystemen ist ein absolutes Muss.<\/p>\n Hierbei ist zu bemerken, dass es nicht das Ziel ist, dass AUTOSAR Adaptiv das klassische AUTOSAR abl\u00f6sen wird.\u00a0 Beide Systeme werden in Fahrzeugen koexistieren (Abbildung 5, s.\u00a0PDF<\/a>), da f\u00fcr realzeitkritische Anwendungen reine \u00b5P-Systeme nicht geeignet sind. Sch\u00e4tzungen gehen davon aus, dass weniger als 10% der im Fahrzeug verbauten Steuerger\u00e4te \u00b5P-basierte Fahrzeugrechner sein werden, diese werden jedoch den bei weitem gr\u00f6\u00dftem Anteil der Fahrzeugsoftware tragen.<\/p>\n Damit ist die Grundlage f\u00fcr eine st\u00e4rkere Horizontalisierung der SW innerhalb des Fahrzeuges gelegt. Die Entkopplung der SW von der HW durch Verwendung serviceorientierter Architekturen unterst\u00fctzt einen deutlich modularisierteren Aufbau dar\u00fcber liegender SW-Schichten.<\/p>\n Siehe Abbildung 5\u00a0(PDF<\/a>)<\/p>\n Das Thema der steigenden Horizontalisierung l\u00e4sst sich in diesem Zusammenhang am Beispiel Security verdeutlichen. In der Vergangenheit waren Fahrzeuge „implizit“ durch die Fahrzeuggrenzen gesch\u00fctzt. Um unberechtigten Zugang im Fahrzeugnetzwerk zu erlangen, war der physikalische Zugriff auf das Fahrzeug notwendig. Entsprechend konnte nur das konkret attackierte Fahrzeug manipuliert werden.<\/p>\n Mit der zunehmenden Konnektivit\u00e4t ver\u00e4ndert sich der Angriffsvektor vollst\u00e4ndig (Abbildung 6, s.\u00a0PDF<\/a>). Der physikalische Zugriff auf das Fahrzeug ist nicht mehr zwingend erforderlich, und bei einem erfolgreichen Angriff ist potentiell eine gro\u00dfe Menge an Fahrzeugen unmittelbar betroffen.<\/p>\n Um dieser Situation zu begegnen, m\u00fcssen Sicherheitskonzepte und -l\u00f6sungen etabliert werden, die nicht an ECU-Grenzen haltmachen. Mehrstufige Sicherheitskonzepte sind erforderlich. Diese k\u00f6nnen auch nicht auf Teile der in den Steuerger\u00e4ten 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\u00e4ten und Fahrzeugrechnern sicherzustellen. Dabei sind ganzheitliche Ans\u00e4tze erforderlich, wie sie die ETAS-Tochter ESCRYPT bereitstellt. Dass ETAS bereits vor mehreren Jahren ein eigenes Unternehmen f\u00fcr Automotive-Security am Markt etabliert hat, verdeutlicht die Notwendigkeit f\u00fcr die Horizontalisierung des Themengebietes Security.<\/p>\n Mit der Einf\u00fchrung der Fahrzeugrechner m\u00fcssen folgende Herausforderungen adressiert werden:<\/p>\n Bei all diesen Herausforderungen muss sichergestellt werden, dass alle im Fahrzeug verbauten Komponenten und deren Schnittstellen nach au\u00dfen einwandfrei aus Security-Sicht funktionieren. Ein einzelnes Steuerger\u00e4t kann bei einer fehlerhaften Kommunikation das ganze E\/E-Netzwerk lahmlegen (Abbildung 7, s.\u00a0PDF<\/a>).<\/p>\n Hieraus ergibt sich zwingend, dass Security kein Steuerger\u00e4te-spezifisches Thema ist, sondern sich \u00fcber deren Grenzen hinweg, \u00fcber das gesamte Fahrzeug bis in Fertigungsabl\u00e4ufe beim OEM und Tier1 auswirkt.<\/p>\n Wie bereits weiter oben erw\u00e4hnt, stellt AUTOSAR Adaptive einen zentralen Baustein f\u00fcr Fahrzeugrechner dar und wird die Horizontalisierung der SW im Fahrzeug weiter vorantreiben. Dabei wurde nur eine Instanz einer AUTOSAR Adaptive auf einem Fahrzeugrechner betrachtet. Solange auf einem Fahrzeugrechner nur eine einzelne Anwendungsdom\u00e4ne abl\u00e4uft, ist der Einsatz einer AUTOSAR Adaptive SW mit geeignetem POSIX-Betriebssystem als Basis-SW m\u00f6glicherweise ausreichend.<\/p>\n Bez\u00fcglich der Anforderungen aus zuk\u00fcnftigen E\/E-Architekturen ist AUTOSAR Adaptive ein erster notwendiger, aber nicht ausreichender Schritt.<\/p>\n Zuk\u00fcnftige Fahrzeugrechner, die als Integrationsplattformen f\u00fcr SW-Funktionen aus unterschiedlichen Bereichen mit unterschiedlichen ASIL-Anforderungen stammen, ben\u00f6tigen Plattformen, die diesen unterschiedlichen Safety-Anforderungen gen\u00fcgen.<\/p>\n Es werden flexible Plattformen ben\u00f6tigt, die \u00fcber gemischte \u00b5C-\u00b5P-Systeme unter Verwendung von Hypervisor-Technologien und damit \u00fcber das klassische AUTOSAR und AUTOSAR Adaptive skalieren (Abbildung 8, s.\u00a0PDF<\/a>).<\/p>\n Des Weiteren wird die Unterst\u00fctzung von Hypervisor-L\u00f6sungen ben\u00f6tigt, 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\u00fcllen.<\/p>\n Aus diesem Grund entwickeln BOSCH und ETAS die RTA-VRTE (Real-Time-Application Vehicle Run Time Environment), welche AUTOSAR Adaptive konform ist und zus\u00e4tzliche, cross-ECU relevante Plattformfunktionen bereitstellt. Dabei wird besonderes Augenmerk auf ein offenes, flexibles Framework gelegt, so dass eine einfache Integration von 3rd-Party-SW unterst\u00fctzt wird.<\/p>\n Siehe Abbildung 9 (PDF<\/a>)<\/p>\n Die VRTE stellt somit ein weiteres Beispiel f\u00fcr die SW-Horizontalisierung im Automobilsektor dar. Zuk\u00fcnftige Fahrzeugrechner werden somit aus einer Menge horizontaler SW-Anteile sowie vertikaler SW-Anteile innerhalb der Anwendungsdom\u00e4nen aufgebaut sein. Hieraus ergibt sich eine Aufteilung und Verschiebung von Verantwortlichkeiten bis hin zu organisatorischen \u00c4nderungen, um den Auswirkungen von Conway\u2019s Law entgegenzuwirken.<\/p>\n Mit dem Einzug der \u00b5-Prozessor-basierten Fahrzeugrechnern setzt sich die Separierung der SW von der HW fort. Gleichzeitig wird eine deutlich st\u00e4rkere Separierung der Software in horizontale und vertikale Anteile auftreten, die auch zu organisatorischen \u00c4nderungen in Unternehmen der Automobilindustrie f\u00fchren.<\/p>\nVom \u00b5-Controller mit klassischem AUTOSAR zum \u00b5-Prozessor mit AUTOSAR adaptive<\/h2>\n
Horizontalisierung am Beispiel Security<\/h2>\n
\n
RTA-VRTE und AUTOSAR Adaptive<\/h2>\n
Zusammenfassung<\/h2>\n
Abk\u00fcrzungsverzeichnis
\n<\/strong><\/h2>\n