(R)Evolution der Automotive-Software-Architekturen

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.

Anbieter zum Thema

eSystems MTG GmbH

Robert Bosch GmbH

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.

(ID:45549478)