01

Durch die oben genannten Funktionen steigt die Menge und Komplexität der Software im Fahrzeug weiter rapide an. Dieser Trend ist keineswegs neu. Doch gerade jetzt sind außergewöhnlich viele Bereiche der Automobilbranche im Umbruch, um den neuen Marktanforderungen gerecht zu werden. Dies gilt für die Fahrzeugelektronik in besonderem Maße. Da die benötigte Rechenleistung für die neuen Auf-gaben hoch ist, finden in den Steuergeräten vermehrt Mikroprozessoren Verwendung und ergänzen die bisher im Automobilbereich eingesetzten Mikrocontroller. Ein oder mehrere dieser Mikroprozessoren bilden dann, häufig im Verbund mit einem Mikrocontroller, sogenannte Hochleis-tungssteuergeräte.Die Mikroprozessoren in diesen Steuergeräten ähneln den in Smartphones oder PCs eingesetzten Prozessoren sehr. Dies macht neue Softwarearchitekturen erforderlich. Um einen Mikroprozessor effizient auszulasten, kommen typ-ischerweise POSIX-basierte Betriebssysteme zum Einsatz.

Diese Betriebssysteme erlauben einen dynamischeren Umgang mit der ausgeführten Software und abstrahieren stärker von der Hardware als bisher eingesetzte Echtzeit-betriebssysteme. Um auch diese Mikroprozessoren nahtlos in das bestehende Fahrzeugnetz einzubinden, basiert die Middleware oberhalb des Betriebssystems auf dem Stan-dard AUTOSAR Adaptive.

Auch die E/E-Architektur eines Fahrzeugs befindet sich im Umbruch. Domänen- und Zentralserverarchitekturen bind-en die Hochleistungsrechner in den Verbund mit ein. Unter-stützt durch schnelle Datennetze und leistungsstarke Proz-essoren, liegt der Fokus nun nicht länger auf der effizienten Datenübertragung, sondern auf der stärkeren Entkopplung einzelner Steuergeräte. Die Änderung eines einzelnen Steuergeräts soll möglichst wenig Auswirkungen auf das restliche System haben. Eine wirkungsvolle Maßnahme ist daher die Einführung service-orientierter Architekturen.

E/E-Architekturen mit AUTOSAR AdaptiveMehr Leistung, bitte!Assistenzsysteme für das teilautomatisierte Fahren, regelmäßige Over-the-Air-Updates sowie das nachträgliche Instal-lieren von zusätzlicher Software gehören in vielen Fahrzeugen bald zur Grundausstattung. Ohne neue Architekturen und Hochleistungssteuergeräte sind diese anspruchsvollen Elektronikfunktionen jedoch nicht umsetzbar. Welche Rolle spielt dabei der neue Softwarestandard AUTOSAR Adaptive?

02

Fachartikel / Mai 2019

Bild 1a: Verteilte E/E-Architektur

Bild 1b: Domänen-Architektur

Bild 1c: Zentralserver-Architektur

03

Fachartikel / Mai 2019

noch eine weitere wichtige Funktion: Sie agieren als Gate-way zwischen den Bus-Systemen der Sensorik und Aktua-torik, also CAN, LIN, FlexRay und Ethernet. Ethernet bildet in diesem Verbund das Haupt-Bussystem in Richtung Zen-tralrechner. Durch eine passend abstrahierte Schnittstelle zu den Sensor- und Aktuator-Steuergeräten entsteht eine modulare und funktional erweiterbare Architektur.

Komplexe Architekturen eines ZentralserversZentralserver oder Integrationsknoten sind komplexe Steuergeräte. Sie beinhalten nicht selten mehrere Mikro-controller und Mikroprozessoren. Dieser heterogene Auf-bau bietet einige Vorteile, denn Controller und Prozessor ergänzen sich gut in ihren Eigenschaften. Zu nennen ist hier beispielsweise die schnellere Startzeit des Mikrocontrollers. Nach dem Einschalten ist er rasch betriebsbereit und kann so an der Kommunikation mit anderen Steuergeräten teil-nehmen und seine Teilfunktion erbringen. Des Weiteren sind mit einem Mikrocontroller selbst höchste Zeitan-forderungen im Mikrosekundenbereich mit niedrigen Schwankungsbreiten (Jitter) erfüllbar. Der Mikrocontroller eignet sich ebenfalls besser, wenn die umgesetzte Funktion häufige Interrupts benötigt.Der Mikroprozessor hat seine Stärken in anderen Bere-ichen. An erster Stelle ist hier natürlich die Leistungs-fähigkeit zu nennen. Die eigesetzten Rechenkerne erlauben eine höhere Taktung und bringen viele Funktionen wie Multi-Skalarität oder Sprungvorhersagen mit, welche die durchschnittliche Leistung verbessern. Größere Caches er-möglichen zudem das Anbinden von langsameren aber dafür größeren externen Speicherbausteinen. Neben einer üppigeren Ressourcenausstattung bieten Mikroproz-essoren eine bessere Unterstützung zur Virtualisierung der Hardware, was den Einsatz von Hypervisor-Technologie er-leichtert.Ein weiterer Vorteil der heterogenen Ausstattung mit Mikrocontroller und -prozessor liegt in der Erfüllung von Si-cherheitsanforderungen. Aktuelle Prozessoren erreichen gemäß ISO 26262 maximal die Integritätsstufe ASIL B. Durch den Einsatz von Redundanz lässt sich trotzdem die für das hochautomatisierte Fahren geforderte Stufe ASIL D erreichen. In einem solchen System übernimmt der zusät-zliche Mikrocontroller zwei Aufgaben: Zum einen führt er weitere Überwachungsfunktionen durch. Er kann aber auch dazu verwendet werden, im Fehlerfall eine degradierte Funktionalität zur Verfügung zu stellen, damit das System weiterhin seine Funktion mit einer hohen Zuverlässigkeit erbringen kann. Dies ist eine wichtige Eigenschaft, die für Fail-Operational-Systeme, also Systeme, die trotz eines Funktionsausfalls weiterhin funktionieren müssen, ge-fordert ist (Bild 2).Durch die Ausstattung des Steuergeräts mit mehreren pro-grammierbaren Komponenten ergibt sich ein weiterer As-

Neue E/E-Architektur mit ZentralservernNeben der Entkopplung einzelner Komponenten ist die Steigerung der Wiederverwendbarkeit von Hard- und Soft-ware ein weiteres Ziel. Damit sollen Komponenten fahrze-ug- und sogar herstellerübergreifend einsetzbar sein. Mit den klassischen E/E-Architekturen der letzten Jahre lässt sich diese Anforderung nicht umsetzen. Bild 1.a zeigt die ausgeprägte Steuergeräteorientierung dieser Architek-turen. Hier wird eine Funktion durch genau ein Steuergerät realisiert. Dieses bringt dann einen zugehörigen Satz an Sensorik und Aktuatorik mit und erhält andere notwendige Daten aus dem Fahrzeugnetz. Die Kommunikationsmatrix des Fahrzeugs beschreibt die dazu notwendigen Kommu-nikationskanäle zwischen den Steuergeräten. Ein solches Design schränkt allerdings die Wiederverwend-barkeit ein. So sind Sensorik und Aktuatorik einem Funk-tionssteuergerät zugeordnet. Zudem erfordert eine Nutzu-ng durch ein anderes Steuergerät eine aufwändige An-passung der Kommunikationsmatrix sowie der Software aller beteiligten Steuergeräte. Um diesem Problem zu be-gegnen, hat sich die Domaincontroller-Architektur etabliert (Bild 1.b). Typische Domänen sind beispielsweise “Body”, “Drivetrain” und “Infotainment”. Die Grundidee dieser Ar-chitektur ist die Verwendung eines leistungsstarken Con-trollers pro Domäne, an dem ein Großteil der notwendigen Sensorik/Aktuatorik angeschlossen ist. In der Domäne übernimmt er zudem die Koordination der nachgelagerten Steuergeräte. Die Flexibilität in Bezug auf Funktionser-weiterungen innerhalb einer Domäne erhöht sich dadurch stark, da Anpassungen häufig nur Domänen-lokale Änderungen nach sich ziehen. Doch die zu Beginn erwähnt-en Anwendungsfälle lassen sich nicht direkt einer Domäne zuordnen. Gerade hochautomatisierte Fahrfunktionen benötigen Informationen aus allen Domänen und speisen auch Daten in diese zurück.Die Weiterentwicklung dieses Ansatzes ist die Zentralrech-nerarchitektur (Bild 1.c). Die Domänen werden in einem großen Hochleistungsrechner beziehungsweise Rech-ner-Cluster zusammengelegt. Es gibt jedoch noch weitere Unterschiede zur Domänenarchitektur. So ist es nicht länger möglich, direkt die Sensorik/Aktuatorik mit dem Ze-ntralsteuergerät zu verbinden, da sich eine so große Menge an I/O-Peripherie nicht an heute verfügbaren Prozessor an-schließen lässt. Sensoren/Aktuatoren werden nun als soge-nannte “Smart Sensors” und “Smart Actuators” direkt an den Bus angeschlossen und erfüllen mechatronische Auf-gaben. Ihre Funktion beschränkt sich damit auf das Bereit-stellen eines Wertes oder das Stellen einer physikalischen Größe. Allerdings: Bei sehr kostengünstigen Sensoren würde dieses Vorgehen in keinem guten Kosten-Nut-zen-Verhältnis stehen. Sensoren können daher auch direkt an die in Bild 1.c blau dargestellten Integrations-Knoten an-geschlossen werden. Diese Knoten-Steuergeräte haben

04

Fachartikel / Mai 2019

AUTOSAR Adaptive als Plattform für ZentralsteuergeräteWie bereits dargestellt, beruhen die auf dem Mikroproz-essor ausgeführten Softwarebestandteile in der Regel nicht auf dem klassischen AUTOSAR-Standard. Um die An-forderungen an Modularität, Dynamik und Up-date-Fähigkeit zu erfüllen, kommt auf dieser Hardware AUTOSAR Adaptive zum Einsatz. AUTOSAR Adaptive en-twickelt sich zum De-Facto-Standard für Hochleis-tungs-Computerplattformen in Fahrzeugen. Die AUTO-SAR-Adaptive-Middleware verwendet POSIX-Betriebssys-teme wie beispielsweise Linux, PikeOS oder QNX und vervollständigt diese um alle notwendigen Automotive-Er-weiterungen. Eine der Hauptfunktionen von AUTOSAR Adaptive stellt die Kommunikationsschicht ara::com dar. Diese ermöglicht die Kommunikation mit anderen AUTO-SAR-Adaptive-Anwendungen sowie mit anderen Software-komponenten (SWC) im Fahrzeug (Bild 3). Diagnose sowie Security- und Safety-Funktionen ergänzen die Funktions-merkmale. Dies mag sehr nach einer AUTOSAR-Classic-Ba-sissoftware klingen. Es gibt jedoch mehrere architek-tonische und technologische Unterschiede. So ist ara::com eine service-orientierte Middleware. Damit lassen sich zur Laufzeit dynamisch Kommunikationswege aufbauen. Diese Dynamik ist eine Voraussetzung für nachinstallierbare An-wendungssoftware. Eine klassische Kommunikationsma-trix müsste angepasst werden, um neue Inhalte an ein Steuergerät zu senden. Mit einem service-orientierten An-satz hingegen kann eine Information zur Laufzeit abon-niert werden.Doch es gibt noch weitere, weniger offensichtliche Vorteile: Die Hardwaretreiber und die High-Level-Software sind voneinander getrennt. Die Hardware-unabhängigen An-

pekt: Von außen betrachtet handelt es sich immer noch um ein einzelnes Steuergerät. Intern jedoch setzen viele un-abhängige Softwarebestandteile die Funktionalität um. Dies führt zu technischen und organisatorischen Heraus-forderungen. Aus technischer Sicht müssen die Bestand-teile miteinander kommunizieren können, um eine gemeins-ame Funktion bereitzustellen. Die Aufgabe des Steuergeräteherstellers ist es nun, die Komponenten mit-tels einer Inter-Prozessor-Kommunikation (IPC) zu verbin-den und die ausgetauschten Daten zu beschreiben. Für den Steuergerätehersteller ist dies eine neue Aufgabe, denn im bisherigen Arbeitsablauf ergab sich dieser Arbeitsschritt für ihn nicht. Lediglich der Datenaustausch zwischen den Steuergeräten musste bislang beschrieben werden. Diese Verantwortung lag aber ausschließlich beim Fahrzeugher-steller. Gleiches gilt für Diagnosefunktionen, die Aktualis-ierung der Software sowie für das Hoch- und Herunter-fahren des Systems: Was bei einfacheren Steuergeräten von einer Entwicklungspartei definiert wurde, erfordert nun eine verteilte und koordinierte Umsetzung.

Die unterschiedlichen Softwarebestandteile zu integrieren stellt aus organisatorischer Sicht eine zunehmende Her-ausforderung dar. Der modulare Aufbau des Steuergeräts und das POSIX-Betriebssystem erleichtern es zwar, Soft-ware von mehreren, unabhängig voneinander agierenden Teams einzubinden. Die Rolle des Steuergeräteintegrators allerdings gewinnt dadurch an Bedeutung. Umso wichtiger ist es, dass der Steuergeräteintegrator für seine an-spruchsvolle Aufgabe von professionellen Werkzeugen un-terstützt wird.

Bild 2: Typische Sicherheitsarchitektur für das Autonome Fahren mit AUTOSAR Classic und Adaptive.

05

Fachartikel / Mai 2019

wendungen im Fahrzeug sind dadurch hochgradig porta-bel. Dies ermöglicht eine wesentlich stärkere Ressou-rcenoptimierung als bei AUTOSAR-Classic-Steuergeräten. So kann beispielsweise Software in der Entwicklungsphase bei Überschreitung der Ressourcenbegrenzung problemlos zwischen verschiedenen Steuergeräten verschoben werden, um Änderungen im Hardware-Design zu vermeiden. Ein weiterer Vorteil: Die Wiederverwendbarkeit von Software-komponenten für mehreren Fahrzeugtypen nimmt zu.

Die Trennung der Software von der Hardware ermöglicht bei AUTOSAR-Adaptive-Projekten zudem eine völlig neue Arbeitsteilung zwischen Fahrzeugherstellern und Zuliefer-ern. Während bislang die Funktionalität immer als materi-elles Gerät im Fahrzeug bestellt wurde, kann sie nun gän-zlich in Software ausgeschrieben werden. Damit dies funk-tioniert, ist jede AUTOSAR-Adaptive-Anwendung nun eine separate Binärdatei. Die Anwendungsentwicklung ist dadurch unabhängig von der Steuergeräteentwicklung. Der Fahrer des Fahrzeugs wird somit selbst zum Integra-tor, indem er zusätzliche Anwendungen aus einem App-Store installiert. Wer aber ist verantwortlich, wenn Störungen im System auf der Straße auftreten? Es könnte ja durchaus eine unge-

Bild 3: Komponenten der AUTOSAR-Adaptive-Software.

testete Kombination von Anwendungen im Fahrzeug in-stalliert sein. Diese Situation steht im Gegensatz zu den typischen Integrationsansätzen in AUTOSAR-Clas-sic-Steuergeräten, bei denen jede Konfiguration aus-führlich getestet wird. Um das Testen aller App-Kombina-tionen zu vermeiden, muss die Störungsfreiheit zwischen den Anwendungen gewährleistet sein. Kommerzielle Be-triebssysteme können auch für sicherheitsrelevante An-wendungen garantieren, dass Speichergrenzen nicht über-schritten werden. Sie bieten dazu hart-echtzeitfähige Scheduling-Verfahren an. Dies erfordert die Definition von Speicherobergrenzen und eine Worst-Case-Execu-tion-Time (WCET) für die Anwendung. Da es keine direkte Interaktion mit der Hardware gibt, sind zeitliche Nebenef-fekte, ausgelöst durch veränderte Interrupt-Belastung, kaum mehr signifikant. Dieser Aufwand ist natürlich nur für sicherheitsrelevante Anwendungen notwendig. Der Einsatz eines Hypervisors ermöglicht es, Systeme mit unterschiedlichem Grad an Dynamik und Sicherheit parallel zu betreiben. QM-An-wendungen können sich in einer dynamischeren und IT-ähnlicheren Partition des Systems befinden, die auch Open-Source-Software nutzen kann. In sicherheitsrele-vanten Partitionen ist hier jedoch Vorsicht geboten, da

06

Fachartikel / Mai 2019

eine Behebung von Softwarefehlern und Sicherheitslücken nicht in der notwendigen Geschwindigkeit gewährleistet ist. Auch im Hinblick auf die Produkthaftung stellt der Ein-satz von Open-Source-Software ein Risiko dar.

AusblickDie erhöhten Anforderungen an Leistung und Flexibilität in der Softwareentwicklung bei zugleich steigender Kosten-sensitivität setzen weitreichende Änderungen in der gesa-mten Entwicklungskette voraus. AUTOSAR Adaptive ist ein wesentlicher Softwarebestandteil, der in Zukunft einen entscheidenden Beitrag zur Entwicklung leistungsstarker Steuergeräte liefert. Die Anpassungen der E/E-Architektur haben in aktuellen Fahrzeuggenerationen bereits begon-nen. Die Verschiebung von Funktionalität aus den Sensor- und Aktuator-Komponenten in zentrale Steuergeräte muss allerdings noch konsequenter umgesetzt werden.

Autoren

Dr. Markus Oertelist seit 2015 bei Vector und dort als Teamleiter für das Produkt Adaptive MICROSAR, der AUTOSAR-Adaptive-Lösung vonVector, verantwortlich.

Ursprünglich erschienen in ATZ elektronik, Ausgabe 05 - Mai 2019

Bildrechte: Vector Informatik GmbH

Dr. Bastian Zimmerist seit 2015 bei Vector und dort Teamleiter „Solution Manage-ment - Embedded Software and Systems“.Zusammen mit seinem Team ist er für die Etablierung voninnovativen Themen und Technologien zuständig.