Autoren: Dr.-Ing. Detlef Zerfowski, Niranjan SK, Robert Bosch GmbH Automotive System Integration (C\/AIS)<\/p>\n
Die gesamte Automobilindustrie wird aktuell mit dramatischen technologischen \u00c4nderung konfrontiert. Diese Ver\u00e4nderungen ergeben sich durch den Einzug v\u00f6llig neuer elektrischer und elektronischer Architekturen (E\/E-Architekturen) und damit einhergehend v\u00f6llig neuen SW-Architekturen.<\/strong><\/p>\n Die gesamte Automobilindustrie wird aktuell mit dramatischen technologischen \u00c4nderung konfrontiert. Diese Ver\u00e4nderungen ergeben sich durch den Einzug v\u00f6llig neuer elektrischer und elektronischer Architekturen (E\/E-Architekturen) und damit einhergehend v\u00f6llig neuen SW-Architekturen. Schl\u00fcsseltreiber dieser Entwicklung sind insbesondere die Folgenden:<\/p>\n Fr\u00fcher konnten Fahrzeuge softwareseitig als „geschlossene Systeme“ betrachtet werden, die nach Auslieferung in die Serie nur unter besonderen Bedingungen (d.h. in den Werkst\u00e4tten) ge\u00e4ndert werden konnten.\u00a0 Heute sind moderne Fahrzeuge eher Teile des Internet der Dinge.\u00a0 Diese Entwicklung f\u00fchrt zu g\u00e4nzlich anderen Architekturtreibern als in der Vergangenheit und hat unmittelbare Auswirkungen auf die SW-Architekturen in der Automobilindustrie.<\/p>\n Seit der Einf\u00fchrung des ABS f\u00fcr PKW im Jahr 1978 sind in den vergangenen Jahrzehnten sukzessive eine gro\u00dfe Anzahl elektronischer Steuerger\u00e4te (Electronic Control Units, ECU) ins Fahrzeug eingef\u00fchrt worden. In heutigen Premiumfahrzeugen werden mittlerweile um die 100 Steuerger\u00e4te der unterschiedlichen Tier 1 Lieferanten verbaut.<\/p>\n \u00dcber die vergangenen Jahrzehnte haben sich diese Komponenten iterativ im Rahmen der OEM-spezifischen E\/E-Architekturen im Fahrzeug weiterentwickelt.<\/p>\n Aus der Sicht eines Tier 1 Zulieferers wie Bosch werden die ECU-spezifischen Architekturen in einem Umfeld wie in Abb\u00a01<\/em>\u00a0entwickelt. Der OEM besitzt die Hoheit \u00fcber 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\u00fcgung gestellt werden.<\/p>\n Der Tier 1 bewegt sich pro Produktsegment in einem \u00e4hnlichen Kontext mit mehreren OEMs und optimiert sich \u00fcber entsprechende Hardware-Plattforml\u00f6sungen. In dieser Situation legen die Hardwarekomponenten die wesentlichen Architekturtreiber f\u00fcr die Software fest.<\/p>\n (siehe Abb.1,\u00a0PDF<\/a>)<\/p>\n Dieses Zusammenarbeitsmuster ist in den unterschiedlichen Anwendungsdom\u00e4nen (Body Electronic, Powertrain, Chassis und Infotainment) wiederzufinden (siehe\u00a0PDF<\/a>, Abb.\u00a02<\/em>). Es gibt jedoch erhebliche Unterschiede (Prozesse, Methoden und Tools) darin, wie die Produkte in den einzelnen Bereichen entwickelt werden. Somit unterscheiden sich die Architekturans\u00e4tze in den Bereichen erheblich. W\u00e4hrend es beispielsweise bei Motorsteuerger\u00e4ten mit einer \u00fcberschaubaren Anzahl von Hardwareplattformen eine extrem hohe Software-Variantenanzahl gibt, variiert bei Body Computern die Hardware deutlich mehr, was dazu f\u00fchrt, dass SW-Komponenten f\u00fcr eine breitere Verwendung hardwareunabh\u00e4ngiger entwickelt werden m\u00fcssen. Hieraus entwickelten sich AUTOSAR-Ans\u00e4tze f\u00fcr \u00b5-Controller-basierte Basissoftware-Stacks.<\/p>\n Die \u00b5-Controller-Technologie gibt restriktive Vorgaben an verf\u00fcgbarem Speicher und Rechenlaufzeit vor. Eine moderne Motorsteuerger\u00e4t-Software muss sich mit bescheidenen 8 MB Speicher begn\u00fcgen. F\u00fcr die Software resultiert das in einer speicheroptimierten Architektur, was zwangsl\u00e4ufig zu Lasten der Wartbarkeit geht.<\/p>\n Dynamische Speicherallokierung ist aus Gr\u00fcnden der knappen Ressourcen und aus Sicherheitsgr\u00fcnden ebenfalls zu vermeiden.<\/p>\n Um die deterministischen Laufzeitanforderungen (auch im Hinblick auf die Funktionale Sicherheit) einhalten zu k\u00f6nnen, kommen Realzeitbetriebssysteme zum Einsatz, die \u00fcber deterministisch vergebene Zeitscheiben die Rechnerleistung auf die unterschiedlichen Tasks aufteilen.<\/p>\n Au\u00dferdem kommen statische Kommunikationsstrukturen (auf Fahrzeugebene definierte CAN-Kommunikationsmatrizen, die zur Entwicklungszeit feststehen) zum Einsatz, die einerseits die Systeme weniger anf\u00e4llig gegen\u00fcber Angriffen von Hackern machen, andererseits jedoch flexible Service-orientierte Anwendungen nicht unterst\u00fctzen.<\/p>\n Des Weiteren wird den beschr\u00e4nkten Rechner-Ressourcen dadurch Rechnung getragen, dass implementierte Algorithmen h\u00e4ufig mit quantisierten Zahlen in Integer-Arithmetik gerechnet werden.<\/p>\n Die aufgef\u00fchrten Architekturtreiber schr\u00e4nken den L\u00f6sungsraum f\u00fcr SW-Architekturen erheblich ein.<\/p>\n Auch die in Abb.\u00a02<\/em>\u00a0(s.\u00a0PDF<\/a>) gezeigte, sich \u00fcber mehrere Jahre bei OEMs und Tier 1 entwickelte Dom\u00e4nenaufteilung stellt implizit einen wesentlichen Architekturtreiber dar \u2013 die Verteilung der ECU-Komponenten (und damit der in ihnen liegenden Software) auf die unterschiedlichen Dom\u00e4nen!<\/p>\n Wir haben es hier mit einem Fall von \u201eConway\u2019s Law\u201c [1] zu tun:\u00a0\u201e\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.\u201d<\/em><\/p>\n Mit anderen Worten: Architekturen folgen den Organisationsstrukturen. Solange Aufgabenstellungen nur innerhalb der existierenden Organisationsstrukturen bearbeitet werden m\u00fcssen, funktioniert dies gut. Wenn jedoch Problemstellungen auftauchen, die quer zu oder au\u00dferhalb von vorhandenen Strukturen liegen, lassen sich h\u00e4ufig keine geeigneten Architekturen etablieren. Organisatorische \u00c4nderungen sind die notwendige Folge.<\/p>\n In den nachfolgenden Abschnitten werden wir darauf eingehen, dass diese Entwicklung in der Automobilindustrie aktuell stattfindet. Zusammengefasst ergeben sich f\u00fcr die \u00b5-Controller-basierten Systeme folgende (nicht vollst\u00e4ndigen) SW-Architekturtreiber, die durch neue, in die Automotive-Welt eindringende Technologien gleichzeitig in Frage gestellt werden.<\/p>\nAusl\u00f6ser f\u00fcr \u00c4nderungen der Automotive-SW-Architekturen<\/h2>\n
\n
\u00b5-Controller-basierte ECUs und ihre Architekturtreiber<\/h2>\n