(R)Evolution der Automotive-Software-Architekturen

Autor / Redakteur: Dr.-Ing. Detlef Zerfowski und Niranjan SK* / Sebastian Gerstl

Mit dem Einzug von prozessorbasierten Plattformen im Fahrzeug findet eine Leistungsexplosion hinsichtlich Speicher, Rechenleistung und Konnektivität statt. Dies lässt aber auch die Software-Komplexität gewaltig ansteigen. Um dem Herr zu werden, müssen sich Entwickler stark auf spezielle Automotive-Software-Architekturen fokussieren.

Firmen zum Thema

Mit zunehmender Komplexität der Softwarestrukturen müssen sich Entwickler stärker mit geänderten Anforderungen an Automotive-Software-Architekturen auseinandersetzen.
Mit zunehmender Komplexität der Softwarestrukturen müssen sich Entwickler stärker mit geänderten Anforderungen an Automotive-Software-Architekturen auseinandersetzen.
(Bild: Clipdealer)

Die gesamte Automobilindustrie wird aktuell mit dramatischen technologischen Änderung konfrontiert. Diese Veränderung ergibt sich durch den Einzug völlig neuer elektrischer und elektronischer Architekturen (E/E-Architekturen) und damit einhergehend völlig neuen Software-Architekturen. Schlüsseltreiber dieser Entwicklung sind insbesondere die Folgenden:

  • Übergang von Mikrocontroller basierten, klassischen embedded Steuergeräten hin zu Mikroprozessor basierten bzw. Cloud-basierten Lösungen,
  • Übergang von regelungsbasierten Algorithmen hin zu Daten getriebenen Algorithmen (Artificial Intelligence, Bildverarbeitung, Datenfusion, Connectivity),
  • Loslösung der Software im Fahrzeug von der darunterliegenden Hardware.
Bildergalerie
Bildergalerie mit 7 Bildern

Früher konnten Fahrzeuge softwareseitig als „geschlossene Systeme“ betrachtet werden, die nach Auslieferung in die Serie nur unter besonderen Bedingungen (d.h. in den Werkstätten) geändert werden konnte. Heute sind moderne Fahrzeuge eher Teile des Internet der Dinge. Diese Entwicklung führt zu gänzlich anderen Architekturtreibern als in der Vergangenheit und hat unmittelbare Auswirkungen auf die Software-Architekturen in der Automobilindustrie.

Mikrocontroller-basierte ECUs und ihre Architekturtreiber

Seit der Einführung des ABS für PKW im Jahr 1978 sind in den vergangenen Jahrzehnten sukzessive eine große Anzahl elektronischer Steuergeräte (Electronic Control Units, ECU) ins Fahrzeug eingeführt worden. In heutigen Premiumfahrzeugen werden mittlerweile um die 100 Steuergeräte der unterschiedlichen Tier 1 Lieferanten verbaut. Über die vergangenen Jahrzehnte haben sich diese Komponenten iterativ im Rahmen der OEM-spezifischen E/E-Architekturen im Fahrzeug weiterentwickelt.

Aus der Sicht eines Tier 1 Zulieferers wie Bosch werden die ECU-spezifischen Architekturen in einem Umfeld wie in Bild 1 (siehe Bildergalerie) entwickelt. Der OEM besitzt die Hoheit über das Fahrzeug und dessen E/E-Architektur. Entsprechend der E/E-Architektur werden die Funktionen den jeweiligen ECUs zugeordnet (Function Deployment). Hieraus werden die ECU Spezifikationen und Schnittstellen abgeleitet, die dann dem Tier 1 als Lastenheft zur Verfügung gestellt werden.

Der Tier 1 bewegt sich pro Produktsegment in einem ähnlichen Kontext mit mehreren OEM und optimiert sich über entsprechende Hardware-Plattformlösungen. In dieser Situation legen die Hardwarekomponenten die wesentlichen Architekturtreiber für die Software fest.

Dieses Zusammenarbeitsmuster ist in den unterschiedlichen Anwendungsdomänen (Body Electronic, Powertrain, Chassis und Infotainment) wiederzufinden (Bild 2). Es gibt jedoch erhebliche Unterschiede darin, wie (Prozesse, Methoden und Tools) die Produkte in den einzelnen Bereichen entwickelt werden. Somit unterscheiden sich die Architekturansätze in den Bereichen erheblich. Während es beispielsweise bei Motorsteuergeräten mit einer überschaubaren Anzahl von Hardwareplattformen eine extrem hohe Software-Variantenanzahl gibt, variiert bei Body Computern die Hardware deutlich mehr, was dazu führt, dass Software-Komponenten für eine breitere Verwendung Hardware-unabhängiger entwickelt werden müssen. Hieraus entwickelten sich AUTOSAR Ansätze für Mikrocontroller-basierte Basis Software Stacks.

Die Mikrocontroller-Technologie gibt restriktive Vorgaben an verfügbarem Speicher und Rechenlaufzeit vor. Eine moderne Motorsteuergerät-Software muss sich mit bescheidenen 8 MB Speicher begnügen. Für die Software resultiert das in einer speicheroptimierten Architektur, was zwangsläufig zu Lasten der Wartbarkeit geht. Dynamische Speicherallokierung sind aus Gründen der knappen Ressourcen und aus Sicherheitsgründen ebenfalls zu vermeiden. Um die deterministischen Laufzeitanforderungen (auch im Hinblick auf die Funktionale Sicherheit) einhalten zu können, kommen Realzeitbetriebssysteme zum Einsatz, die über deterministisch vergebene Zeitscheiben die Rechnerleistung auf die unterschiedlichen Tasks aufteilen.

Außerdem kommen statische Kommunikationsstrukturen (auf Fahrzeugebene definierte CAN-Kommunikationsmatrizen, die zur Entwicklungszeit feststehen) zum Einsatz, die einerseits die Systeme weniger anfällig gegenüber Angriffen von Hackern machen, andererseits jedoch flexible Service-orientierte Anwendungen nicht unterstützen. Des Weiteren wird den beschränkten Rechnerressourcen dadurch Rechnung getragen, dass implementierte Algorithmen häufig mit quantisierten Zahlen in Integer-Arithmetik gerechnet werden. Die aufgeführten Architekturtreiber schränken den Lösungsraum für Software-Architekturen erheblich ein.

Auch die in Bild 2 gezeigte, sich über mehrere Jahre bei OEMs und Tier 1 entwickelte Domänenaufteilung stellt implizit einen wesentlichen Architekturtreiber dar – die Verteilung der ECU-Komponenten (und damit der in ihnen liegenden Software) auf die unterschiedlichen Domänen!

Wir haben es hier mit einem Fall von „Conway’s Law“ [1] zu tun: „…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.”

Mit anderen Worten: Architekturen folgen den Organisationsstrukturen. Solange Aufgabenstellungen nur innerhalb der existierenden Organisationsstrukturen bearbeitet werden müssen, funktioniert dies gut. Wenn jedoch Problemstellungen auftauchen, die quer zu oder außerhalb von vorhandenen Strukturen liegen, lassen sich häufig keine geeigneten Architekturen etablieren. Organisatorische Änderungen sind die notwendige Folge.

In den nachfolgenden Abschnitten werden wir darauf eingehen, dass diese Entwicklung in der Automobilindustrie aktuell stattfindet.

Zusammengefasst ergeben sich für die Mikrocontroller-basierten Systeme folgende (nicht vollständigen) Software-Architekturtreiber, die durch neue, in die Automotive-Welt eindringende Technologien gleichzeitig in Frage gestellt werden.

Mikroprozessor-basierte Computer erobern das Fahrzeug

Im vorherigen Abschnitt haben wir das Umfeld beschrieben, in dem sich die Automobilsoftware in den vergangenen Jahrzehnten iterativ weiterentwickelt hat. Die zunehmende Vernetzung des Automobils inklusive seiner Komponenten sowie die Einführung der Mikroprozessor-Technologie im Fahrzeug führen aktuell zu einer disruptiven Änderung der Automobilsoftware.

Dabei ist zu bemerken, dass die Infotainment-Anwendungen bereits seit Jahren auf Mikroprozessor basierten Systemen mit Linux Betriebssystemen arbeitet. Damit sind einige der Aussagen in den nachfolgenden Abschnitten nur in Teilen für die Infotainment-Domäne zutreffend.

Bildergalerie
Bildergalerie mit 7 Bildern

Aufgrund der geringeren Anforderungen bezüglich Funktionaler Sicherheit und deutlich geringeren Realzeitanforderungen entwickelten sich die Infotainment-Anwendungen separat von den Embedded-Anwendungen. Mit der Integration von Anwendungsfunktionen unterschiedlicher Domänen auf gemeinsamen Fahrzeugrechnern laufen die bisherigen Entwicklungswege wieder verstärkt auf einander zu.

Anstieg der Rechnerressourcen

Der offensichtlichste Effekt bei der Einführung der Mikroprozessoren liegt in den verfügbaren höheren Rechnerressourcen. Während einem modernen Motorsteuergerät ein Speicher von bis zu 8 MB zur Verfügung steht (in dem neben der Anwendungssoftware auch das Realzeitbetriebssystem und Basis Software realisiert sind), besitzen die ersten Mikroprozessor-basierten Systeme 8 GB Speicher (SOP 2020) und Nachfolgesysteme 128 GB (SOP 2023). Obwohl dies aus Sicht der Consumer-Elektronik immer noch gering erscheint, hat dieser Zuwachs um einen Faktor von 1000 (SOP 2020) bzw. 16000 (SOP 2023) Auswirkungen, die über die reine Verfügbarkeit des Speichers weit hinausgehen.

Die früher vorhandene Trennung der domänenspezifischen Software auf dedizierte Steuergeräte entfällt, da zukünftige Fahrzeugrechner unterschiedlichste Fahrzeugfunktionen auf einem Rechner darstellen können. Speicheroptimierte Software-Designs und Implementierungen werden durch Software-Architekturen abgelöst, die insbesondere die Unabhängigkeit von der Hardware und somit Portabilität im Fokus haben. Hieraus folgt, dass sich die Anwendungssoftware von der darunterliegenden Hardware löst und somit auf Rechnern einer anderen Anwendungsdomäne ablaufen kann. Dies hat unmittelbare Auswirkungen auf die bisher etablierten Geschäftsmodelle und Entwicklungsorganisationen. (Bild 2). Bereiche, die bisher isoliert voneinander komponentenbasierte Lösungen mit integrierter Software entwickelt und vertrieben haben, müssen fortan domänenübergreifende Softwarelösungen entwickeln.

Die große Herausforderung ist dabei Conway’s Law. Die bisher vorhandenen domänenspezifischen und hardwareorientierten Software-Architekturen müssen domänenübergreifenden Software-Architekturen weichen. Diesen stehen jedoch die bisherigen organisatorischen Strukturen entgegen. Als Folge bilden sich aktuell in der Automobilindustrie neue, stärker softwareorientierte Organisationsformen heraus. Software-Architekturen und damit auch Software-Architekten gewinnen massiv an Bedeutung und Einfluss auf die Produktentwicklungen.

Neben der Verfügbarkeit hoher Speichergrößen ermöglicht der Anstieg der Rechnerleistung von ~4 kDMIPS (heutige Motorsteuergeräte) auf ~17 kDMIPS (SOP 2020) bzw. ~300 kDMIPS (SOP 2023) eine Vielzahl neuer Anwendungen, die auf bisherigen Systemen nicht realisierbar sind. Die für Mikrocontroller häufig notwendige Einschränkung auf Ganzzahlarithmetik entfällt und es finden zunehmend datenorientierte Algorithmen Einzug ins Fahrzeug bis hin zu Artificial Intelligence (AI) Lösungen auf Graphical Processor Units (GPU).

Es werden dabei Funktionen realisiert, die sich von Teilfunktionalitäten unterschiedlicher Domänen (inklusive Connectivity und Cloud-Diensten) bedienen und lassen sich somit nicht mehr den klassischen Automotive-Domänen zuordnen (Bild 3).

Beispiel Reibwertkarte

Ein Beispiel hierfür stellt die sogenannte Reibwertkarte dar, die dem Autofahrer über eine Internetverbindung in seiner Anzeige Informationen über gefährliche Straßensituationen (wie Glatteis, Aquaplaning etc.) nahezu in Realzeit zur Verfügung stellt. Das Datenmaterial für diese Reibwertkarte liefern vorausfahrende Fahrzeuge, die mittels der ESP-Funktionalität (Anwendungsdomäne Chassis) Informationen über den aktuellen Reibwert der Straße erfassen. Diese Information wird über ein Gateway (Body Computer Domäne) an den Dienstanbieter in der Cloud geschickt (bisher nicht durch entsprechende Domänen abgedeckt). Die von unterschiedlichen Fahrzeugen bereitgestellten Daten werden vom Dienstanbieter konsolidiert und umgehend an die Fahrzeuge verteilt, die den Reibwertkartendienst abonniert haben.

Die Information über die unmittelbar vor ihm liegende Gefahrensituation wird dem Fahrer als Warnmeldung und in der Navigationskarte dargestellt (Infotainment-Domäne). Zusätzlich kann der Stauassistent aufgrund der Information bereits die Geschwindigkeit des Fahrzeuges verringern (Powertrain-Domäne). Beim Einsatz im Hochautomatisierten Fahren wird die Information das System und damit das Fahrverhalten ohne Einwirkung des Fahrers direkt beeinflussen.

Anhand dieses einfachen Beispiels wird deutlich, dass die funktionale Architektur und damit auch die Software-Architekturen unterschiedliche Rechnerknoten innerhalb der E/E-Architektur abdecken muss. Dabei sind die E/E-Architekturen von OEM zu OEM unterschiedlich. Beim Software-Design muss dies berücksichtigt und eine starke Abstraktion von der Hardware sichergestellt werden.

Einflüsse der Konnektivität

Im obigen Beispiel wurde ein zusätzlicher Aspekt bereits angesprochen. Durch die Konnektivität mit der Cloud entstehen Datenströme ins Fahrzeug und aus ihm heraus, die im klassischen Mikrocontroller-Umfeld nicht zu bearbeiten waren. Die Bandbreiten der bisherigen Kommunikationsnetzwerke im Fahrzeug (CAN, LIN, FlexRay) sind für den entstehenden Kommunikationsbedarf nicht mehr ausreichend. Aus diesem Grund wird das Ethernet (aktuell 1 GBit/s) in Fahrzeugen eingeführt. Die Erweiterung auf 10 GBit/s Ethernet ist ebenfalls in Planung.

Diese Bandbreitenerhöhung ermöglicht eine enorme Vielfalt neuer Funktionalitäten im und um das Fahrzeug herum. Aber auch hier gilt, dass sich die Software-Architekturen hierfür grundlegend ändern werden. Die bisherige Kommunikation über die zuvor genannten statischen und damit deterministischen Kommunikationsprotokolle sind vorteilhaft bei Betrachtungen zur Funktionalen Sicherheit gemäß ISO26262. Mit der Einführung des Ethernets im Fahrzeug werden Service-orientierte Kommunikationslösungen realisiert werden.

Funktionen, die bisher eng an die jeweiligen Kommunikationsschnittstellen angebunden waren, werden zukünftig Daten über im Fahrzeug vorhandene Dienste empfangen, bzw. Informationen über bereitgestellte Dienste zur Verfügung stellen. Die verfügbaren Dienste können sich zur Laufzeit ändern bzw. mit unterschiedlichen Qualitäten ausgestattet sein. Damit ergeben sich völlig neue Ansätze für Fallback-Lösungen.

Beispiel Verkehrsschildererkennung

Als Beispiel für eine Service-orientierte Kommunikation nehmen wir die automatische Schildererkennung. Wir gehen davon aus, dass eine im Fahrzeug vorhandene Kamera die Verkehrssituation und mit ihr auch Verkehrszeichen aufnimmt. Die Software im Fahrzeug detektiert und erkennt die Verkehrsschilder und stellt diese im Navigationsdisplay dar. Möglicherweise wird der Fahrer informiert, falls seine aktuelle Geschwindigkeit zu hoch ist.

Gehen wir nun davon aus, dass aus irgendeinem Grund (verschmutzte Kamera, technischer Defekt der Kamera, etc.) die Schilderinformation nicht mehr zur Verfügung steht. Anstatt nun keine Information in der Anzeige mehr bereitzustellen, können über eine Service-orientierte Architektur anstelle der fehlenden Kamerainformation, die Daten von einem Cloud-Dienst die lokalen Schilderinformationen bereitgestellt werden. Diese sind sicherlich von geringerer Qualität, da die Schilderinformation nicht überall tagesaktuell vorliegen. Selbst wenn die Verbindung zur Cloud nun zusammenbricht, besteht die Möglichkeit statische Schilderinformation von dem im Fahrzeug lokal vorhandenen Navigationssystem zu verwenden.

Bildergalerie
Bildergalerie mit 7 Bildern

Software-Architekturen, die auf Quality-of-Service Ansätzen aufbauen, sind für solche Lösungen wesentlich flexibler aufgestellt, da die Funktionen nicht mehr berücksichtigen müssen, aus welcher Quelle (auch nicht von welchem Rechner im Fahrzeug) die Daten stammen. Lediglich die Qualität der Daten muss berücksichtigt werden. Damit werden diese Funktionen auch leichter auf andere Rechner im Fahrzeug verschiebbar.

Eine wesentliche Rolle spielt in diesem Zusammenhang der sich aktuell in der Entwicklung befindliche Standard AUTOSAR Adaptive, der Standards für Schnittstellen für Mikroprozessor basierte Basis Software festlegt, die in Anwendungen mit besonderen Anforderungen bzgl. Funktionaler Sicherheit (ISO26262 mit zugehörigen ASIL Level) zum Einsatz kommen.

Einflüsse von Fremdsoftware auf die Basis-Software

In den vorhergehenden Abschnitten sind wir auf einen wesentlichen Aspekt der Software für zukünftige Fahrzeugrechner noch nicht eingegangen. Wer erstellt eigentlich die Software für die Mikroprozessor basierten Fahrzeugrechner? Wie bereits oben erwähnt steigt der Umfang der in den Fahrzeugrechnern realisierten Software um mehrere Zehnerpotenzen den Umfang der Mikrocontroller-Software.

Bei letzterer entwickelt in der Regel der Tier-1-Zulieferer die Software für die entsprechende Hardware. Dabei kommen auch zugekaufte Teile wie Automotive-spezifische Realzeit Betriebssysteme und Basis Software Stacks (z.B. AUTOSAR für Mikrocontroller) zum Einsatz. Auch OEMs stellen eigenen Funktionalitäten bei, die in die finale Software integriert werden. Im Prinzip gilt hierbei, dass alle Softwareanteile direkt aus der Automobilindustrie und ihren Zulieferern stammen und somit mit den besonderen Anforderungen bzgl. Funktionaler Sicherheit vertraut sind.

Große Zulieferer, wie Bosch, sind zudem in der Lage Komplettsysteme aus einer Hand zu entwickeln und zu liefern, also mit einer Entwicklungstiefe von 100 Prozent: das Realzeitbetriebssystem von der Bosch-Tochter ETAS, die Basis Software als In-house-Lösung einer Querschnittsabteilung für Software und die Anwendungssoftware durch den beauftragten Geschäftsbereich. Diese Situation ändert sich grundlegend beim Einsatz von Mikroprozessoren. Zum einen werden POSIX-konforme Betriebssysteme eingesetzt, die nicht durch deterministische Realzeitbetriebssysteme realisiert werden.

Des Weiteren werden auf Fahrzeugrechnern Hypervisor verwendet, um Virtualisierungsansätze zur Separierung von Anwendungen mit unterschiedlichen ASIL Level auf einem Rechner zu ermöglichen. Sowohl die POSIX-Betriebssysteme als auch die Hypervisor kommen nicht von klassischen Automobilzulieferern. Das Marktsegment dieser Software-Arten befindet sich aktuell in rasanter Entwicklung. Umso wichtiger ist es, dass die auf diesen Systemen aufbauenden Automotive-spezifischen Lösungen ausreichend gekapselt werden. Eine durchgängige Schichtenarchitektur für Fahrzeugrechner-Software wird zwingend erforderlich.

Bild 4 (siehe Bildergalerie) zeigt die Schichtenarchitektur des sogenannten Vehicle Run Time Environment (VRTE), welches in zukünftigen Fahrzeugrechnern verwendet wird. Die fünf Ebenen des VRTE stellen sukzessive Kapselungen

  • der Hardware-abhängigen Kapselungen
  • der Betriebssystem-spezifischen Software
  • der verwendeten Kommunikationskanäle (Abstraktion von CAN, FlexRay, Ethernet, etc.)
  • Computerspezifische Dienste (z. B. Rechnerdiagnose) und
  • Fahrzeugspezifische Dienste, die es auf heutigen Mikrocontroller ECUs nicht gibt (z. B. Life-Cycle Management)

Es ist hierbei anzumerken, dass die abgebildete Software keine monolithische Struktur darstellt, sondern ein System aus unterschiedlichen Softwarekomponenten unterschiedlichster Hersteller ist, die in einem gemeinsamen Framework integriert und für die Automobilindustrie seriengehärtet wird. Besondere Herausforderungen ergeben sich dabei für die Software-Integration und deren Absicherung, da neben nicht quelloffenen „3rd Party“ Komponenten auch Open Source Software (z.B. in verwendeten Betriebssystemen) eingesetzt werden müssen. Auch diese Aspekte müssen im Entwurf der Software-Architekturen berücksichtigt werden.

Einflüsse unterschiedlicher Arten von Software

In dem bisher Gesagten wurde stillschweigend davon ausgegangen, dass bei allem Komplexitätszuwachs, den die neuen Fahrzeugrechner mit sich bringen, sich an der eigentlichen Entwicklungsmethodik der Software-Ingenieure und Informatiker nichts ändern wird. Die Realität sieht jedoch völlig anders aus.

Die Software für „Deeply Embedded ECUs“ ist durch die in Bild 5 unten links (siehe Bildergalerie) angegebenen Elemente charakterisiert. Insbesondere ist zu erwähnen, dass die Entwicklungsprozesse stark durch das in der Automobilindustrie etablierte V-Model und Automotive SPICE (ASPICE) geprägt sind.

Mit den Fahrzeugrechnern werden neue Software-Arten eingeführt. Neben Betriebssystem die aus der IT-Welt stammen, kommen andere Programmiersprachen und Programmierparadigmen in die Automobilindustrie. Die klassische Lastenheft-getriebene, V-Model-basierte Entwicklungsmethodik trifft nun auf die agile, durch DevOps getriebene Entwicklungsansätze, die aus dem Umfeld der Internetentwicklungsplattformen kommen. In Bild 5 wird deutlich, dass die Fahrzeugrechner softwareseitig eine deutlich stärkere Überlappung mit den IT-Softwaremethoden besitzen. Zusätzlich drängen zunehmend Anwendungen aus den Smartphone Eco-Systemen ins Fahrzeug (Bild 5 unten rechts).

Zusammen mit dem in Bild 3 dargestelltem Trend zu cross-Domänen Architekturen ergibt sich die Notwendigkeit, Software-Architekturen übergreifend über unterschiedliche Software-Plattformen und Zielsystemen konsistent zu beschreiben und zu pflegen. Hier liegt eine besondere Herausforderung für die Automobilindustrie, deren Produkte im Vergleich zu den schnelllebigen Konsumerprodukten der IT-Welt deutlich längere Lebenszyklen durchlaufen und in der Regel deutlich höhere Anforderungen hinsichtlich Sicherheit erfüllen müssen.

Als Konsequenz des Gesagten ergibt sich, dass die Automobilindustrie eine deutlich größere Anzahl an Informatikern mit einer Vielzahl unterschiedlicher Software-Fähigkeiten benötigt und das zusätzlich zu den bereits vorhandenen Ingenieuren der regelungsbasierten embedded Welt.

Bedeutung der Funktionalen Sicherheit und IT Sicherheit

In den vorherigen Abschnitten wurde ein wichtiger Themenkomplex und Architekturtreiber nur am Rande berührt. Die Kombination aus Funktionaler Sicherheit und IT-Sicherheit. (Die englische Sprache unterscheidet den Sicherheitsbegriff deutlich besser durch die Worte Safety und Security.) Die Kombination dieser Anforderungen ist nach unserem Wissen in keinem anderen Industriezweig so ausgeprägt. Selbst in der Luftfahrt als auch im Schienenverkehr stellt sich eine andere Situation dar. In beiden genannten Industriezweigen besitzen nur geschultes Personal (z.B. Piloten, Lokführer, etc.) Zugang zu den zentralen Systemen der Fortbewegungsmittel. Im privaten PKW-Umfeld hat jedoch jeder Autobesitzer im Prinzip den physikalischen Zugang zu den Systemen.

Des Weiteren ergeben sich durch die zunehmenden Connectivity-Lösungen und Cloud-basierten Dienste eine größer werdende Angriffsfläche für Hacker. Hiermit erhöht sich deutlich die Gefahr für einen unberechtigten Zugang in die Computersysteme des Fahrzeuges, die es durch geeignete Security-Maßnahmen abzuwehren gilt.

Bildergalerie
Bildergalerie mit 7 Bildern

Auch die Lösungsansätze zur Funktionalen Sicherheit sehen in der Luftfahrt und Schienenverkehr anders aus als im PKW-Sektor. Aufgrund der vergleichsweise geringen Volumina an Flugzeugen und Schienenfahrzeuge und einem deutlich geringerem Commodity-Druck kommen in den erstgenannten Bereichen teilweise komplett redundante Systeme zum Einsatz. Außerdem werden Flugzeuge und Schienenfahrzeuge mit einer deutlich höheren Frequenz auf mögliche Fehler überprüft als PKW. Diesem Aspekt müssen Software-Architekturen durch entsprechende Safety- und Sicherheits-Konzepte Rechnung tragen.

Bei Fahrzeugrechnern mit Applikationen unterschiedlicher ASIL Level ist eine Separierung bzw. Virtualisierung der Anwendungsdomänen unter Verwendung von Hypervisortechnologien erforderlich. Dabei nimmt der Hypervisor eine zentrale Rolle im Software-System ein, da er die Hoheit über Rechnerressourcen besitzt, deren Allokation zu den unterschiedlichen Anwendungsfunktionen sicherstellt und diese überwacht. Mit dieser zentralen Position des Hypervisors im System ergibt sich eine weitere zentrale Angriffsfläche für Software-Hacker. Aus diesem Grund müssen eingesetzte Hypervisor in besonderem Maße auf potentielle Security-Lücken überprüft werden.

Software-Architekturtreiber und ihre Dokumentation

In den vorhergehenden Abschnitten haben wir eine Reihe von Software-Architekturtreibern beschrieben, die mit der Einführung der Fahrzeugrechner massiv an Bedeutung gewinnen. Mit der steigenden Komplexität und Öffnung der Software-Systeme muss ein viel höheres Gewicht auf wohl durchdachte und mit allen relevanten Stakeholdern abgestimmte Software-Architekturen gelegt werden.

Die Fokussierung auf rein funktionalen Software-Aspekt ist bei weitem nicht ausreichend. Bild 6 gibt eine Übersicht der wesentlichen, domänenunabhängige Architekturtreiber für Mikroprozessor-basierte Fahrzeugrechner.

Im Rahmen des Architekturentwurfes muss sichergestellt werden, dass die nicht-funktionalen Treiber ausreichend berücksichtigt und nachvollziehbar dokumentiert werden. Insbesondere in einem zunehmend heterogenen und komplexer werdenden Software-Umfeld ist ein verstärkter Fokus auf Software-Architekturen von entscheidender Bedeutung. Ein Startpunkt für die den Architekturentwurf bietet der als arc42 bekannte Ansatz, welcher eine Strukturierungshilfe für Software-Architekturen darstellt und folgende Kapitel bzw. Architektursichten umfasst:

1. Einführung und Ziele: Wichtige Einflussfaktoren bzw. Kräfte, die auf die Software-Architektur einwirken. Insbesondere sind die Geschäftsziele zu benennen, die einen wesentlichen Einfluss auf die Software-Architektur haben.

2. Randbedingungen: Technische und organisatorische Randbedingungen, Konventionen, Tools, Stakeholder etc.

3. Kontextabgrenzung: Fachlicher und technischer Kontext, externe Schnittstellen, etc.

4. Lösungsstrategie: Überblick über Architektur-relevante, grundlegende Entscheidungen und Lösungsansätze (z.B. Verwendung zugekaufter Software versus eigener Programmierung).

5. Komponentensicht (Bausteinsicht): Überblicksbild der ersten Ebenen (hierarchisch) des zu entwerfenden Systems, inkl. Zusammenhänge und Abhängigkeiten der Bausteine untereinander.

6. Dynamische Laufzeitsicht: Beschreibung (z.B. als Laufzeitszenarien inklusive Latenzzeiten) der Bausteine wie sie sich während der Laufzeit verhalten (d.h. Prozesse, Tasks, Aktivitäten, Interruptaufrufe, etc.).

7. Verteilungssicht: Oberste Ebene von Hardware und technischer Infrastruktur mit der Beschreibung, wo welche Teilfunktion abzulaufen hat. Dies ist besonders wichtig für verteilte Anwendungen, z.B. Software-Lösungen die nicht auf einen Prozessor beschränkt sind (Multi-Prozessorlösungen, Connectivity-Lösungen, Zuordnung zu unterschiedlichen virtuellen Maschinen etc.)

8. Querschnittliche Konzepte: Umfangreicher Abschnitt der technische Konzepte beschreibt (z.B. Ablaufsteuerung, Fehlerbehandlung, Logging, Parallelisierung, Bedienoberflächen (UX) und vieles mehr).

9. Entwurfsentscheidungen: Wesentliche Entwurfsentscheidungen mit Gründen

10. Qualitätsszenarien: Beschreibung von Grenz- bzw. Stressszenarien und dem erwarteten Verhalten des Systems (z.B. unter definiert hoher Belastung von Kommunikationsbussen)

11. Risiken und technische Schulden: Dokumentiert Risiken aus SW-Architektursicht, die z.B. auch in das Risikomanagement des Projekts übernommen werden müssen

12. Glossar

In der praktischen Umsetzung von Architekturbeschreibung ist es eine große Herausforderung, die unterschiedlichen Sichten aktuell und konsistent zu halten, da diese oft über mehrere Dokumente und Tools verteilt erstellt werden. Aus diesem Grund wurde in Bosch eine entsprechendes arc42-Profile für das Software-Architekturtool Rhapsody der Firma IBM erstellt. Das Rhapsody-Profile unterstützt Architekten im Entwurf und Pflege konsistenter Architekturen und ihren Sichten.

Das Profil steht auf den arc42 Internetseiten zum Download zur Verfügung.

Zusammenfassung

In den vorhergehenden Kapiteln sind wir auf die disruptiven Änderungen in der Software-Entwicklung der Automobilindustrie eingegangen. Mit dem Einzug von Mikroprozessor-basierten Rechnerplattformen im Fahrzeug findet eine Leistungsexplosion hinsichtlich Speicher, Rechenleistung und Konnektivität statt, die völlig neue Lösungsräume für bisher nicht betrachtete Problemstellungen bietet.

Diese Leistungsexplosion geht einher mit

  • einem extremen Anstieg der Software-Komplexität hinsichtlich unterschiedlicher Arten von Software,
  • unterschiedlicher, aufeinander treffender Entwicklungsmethoden,
  • bei einem gleichzeitigen Anstieg der beteiligten Softwarelieferanten, deren Software-Komponenten in Fahrzeugrechnern integriert werden müssen und dabei Anforderungen zur Funktionalen Sicherheit und Security abdecken.

Diese Situation kann nur mit einem starken Fokus auf Software-Architekturen und deren relevanten Architektursichten beherrscht werden. Dies ist die Herausforderung der sich die gesamte Automobilindustrie aktuell stellt.

Dieser Beitrag stammt aus dem Tagungsband des Embedded Software Engineering Kongress 2017. Vielen Dank für die freundliche Genehmigung der Autoren für die Publikation.

* 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. Mit diesem Vortrag gewann er den Speaker Award als Newcomer auf dem ESE Kongress 2017.

* Niranjan SK arbeitet im Corporate Sector Automotive System Integration und an der unternehmensweiten Etablierung von Software-Architekturvorgehensweisen bei der Robert Bosch GmbH.

(ID:45549478)