E/E-Architektur im Wandel Softwarelose und intelligente Endpunkte im Software-definierten Fahrzeug

Die Zentralisierung der Fahrzeug-Software verändert nicht nur die E/E-Architektur, sondern auch die Anforderungen an die Endpunkte im Fahrzeug. Softwarelose und intelligente Endpunkte übernehmen dabei unterschiedliche Aufgaben. Ethernet-basierte Netzwerke, darunter 10BASE-T1S, sowie das Remote Control Protocol ermöglichen ihre Einbindung in zonale und zentrale Rechnerstrukturen.

Die elektrische und elektronische Architektur (E/E-Architektur) moderner Fahrzeuge befindet sich im Wandel (Bild 1). Über Jahrzehnte hinweg führte die wachsende Zahl Software-gestützter Funktionen dazu, dass immer mehr spezialisierte elektronische Steuergeräte (ECUs) in das Fahrzeug integriert wurden. Die daraus entstandene verteilte Architektur wurde zunächst durch domänenorientierte Strukturen abgelöst. Dabei wurden Funktionen zum Beispiel nach Antrieb, Karosserie oder Infotainment gruppiert und über Domänencontroller vernetzt. In einem weiteren Entwicklungsschritt entstand die zonale Architektur. Anders als bei der Domänenarchitektur orientiert sich die Anordnung der ECUs und Kommunikationsverbindungen hier stärker an der physischen Position der Komponenten im Fahrzeug. Zonencontroller bündeln Verbindungen zu Sensoren und Aktoren, übernehmen Kommunikationsaufgaben und können auch die sekundäre Energieverteilung steuern. Funktionen wie Antrieb, Lenkung und Bremse bleiben jedoch häufig als eigenständige Domäne erhalten. Dadurch entstehen in der Praxis Mischarchitekturen mit zonalen und domänenorientierten Ansätzen.

In einer Software-definierten Fahrzeugarchitektur wird die Anwendungssoftware von der Peripherie in zonale oder zentrale Recheneinheiten verlagert, um Software-Updates zu vereinfachen. Aus Software-Sicht werden dabei viele Domänenfunktionen auf den zentralen Fahrzeugrechner verlagert. Dennoch dienen die Endpunkte weiterhin der Erfassung von Eingangssignalen und der Ansteuerung von Ausgängen, beispielsweise Tastern, Motoren und LEDs. Die Zentralisierung der Software soll den Update-Prozess vereinfachen, die Zahl der zu aktualisierenden Steuergeräte reduzieren und durch die Reduktion des Wartungsaufwandes für die zahlreichen Endpunkte Kosten sparen. Dafür werden jedoch softwarelose und intelligente Endpunkte benötigt.

Endpunkte als Schnittstellen zur Fahrzeugumgebung

Endpunkte bilden die Schnittstelle zwischen der E/E-Architektur und der Außenwelt. Sie erfassen Eingangssignale, steuern Ausgangsfunktionen wie Motoren, LEDs und Ventile oder stellen Schnittstellen für die Interaktion mit dem Anwender bereit. Dazu zählen Displays, Touchscreens, Audio- und Sprachsysteme sowie haptische Rückmeldungen.

Je nach Anwendungsfall lassen sich Endpunkte in zwei Kategorien einteilen: softwarelose, und intelligente Endpunkte. Softwarelose Endpunkte sind auf eine begrenzte Anzahl standardisierter Funktionen ausgelegt. Ihre Implementierung basiert beispielsweise auf einer Zustandsmaschine oder einem fest implementierten Protokoll-Handler. Über das fahrzeuginterne Netzwerk lassen sie sich mithilfe standardisierter Kommunikationsschnittstellen und Protokolle konfigurieren. Dazu zählt auch das Remote Control Protocol (RCP) der OPEN Alliance TC18.

Intelligente Endpunkte verfügen dagegen über einen frei programmierbaren Mikrocontroller. Dadurch unterstützen sie ein breiteres Spektrum an Anwendungen. Sie bieten ausreichend Flash- und RAM-Speicher sowie Rechenleistung für komplexere Aufgaben, die lokale Software erfordern. Darüber hinaus können sie über dedizierte Hardware wie Gate-Treiber und Analog-Digital-Wandler (ADC) verfügen. Die Anwendungssoftware wird normalerweise von einem Tier-1-Zulieferer oder dem Fahrzeughersteller bereitgestellt. Wird das Bauteil nach dem Aufspielen der Anwendungssoftware gesperrt, lässt sich ein intelligenter Endpunkt auch in einen softwarelosen Endpunkt überführen.

Heterogene und homogene Fahrzeugnetzwerke

Heutige Fahrzeugnetzwerke sind überwiegend heterogen aufgebaut und nutzen unterschiedliche Kommunikationstechnologien wie Ethernet, CAN und LIN. Um Daten zwischen den Netzwerken austauschen zu können, sind Gateways erforderlich, die jedoch Software benötigen, was sich auf die Skalierbarkeit auswirkt und den Wartungsaufwand erhöht. Auch wenn ein Netzwerkzweig lediglich um einen Endpunkt erweitert wird, kann es passieren, dass Aktualisierungen der Kommunikations-Stacks im gesamten betroffenen Zweig durchgeführt werden müssen (Bild 2).

Dagegen kommt ein homogenes, auf Ethernet basierendes Netzwerk ohne Gateways zwischen unterschiedlichen Netzwerktechnologien aus. Stattdessen übernehmen Ethernet-Switches die Weiterleitung der Nachrichten zwischen den Netzwerkzweigen, wodurch keine zusätzliche Software benötigt wird. Deswegen entsteht nur ein geringer Wartungsaufwand, wenn ein neuer Endpunkt hinzugefügt wird. Die geringere Komplexität erleichtert somit die Erweiterung des Netzwerks und verbessert seine Skalierbarkeit.

Remote Control Protocol der OPEN Alliance TC18

Im SDV werden Fahrzeugfunktionen und ‑eigenschaften durch Software festgelegt. Dafür muss die Software auf Hardware-Komponenten an unterschiedlichen Stellen im Fahrzeug und zu unterschiedlichen Zeitpunkten zugreifen können. Sensoren, Aktoren und Taster verfügen jedoch nicht über eine integrierte Ethernet-Schnittstelle. Das Remote Control Protocol der OPEN Alliance TC18 definiert, wie derartige Komponenten von einem zonalen oder zentralen Rechner aus angesteuert werden können (Bild 3).

Bei RCP handelt es sich um ein signalbasiertes Request-Response-Protokoll. Dabei werden Rohdaten, etwa SPI-Daten oder Werte von Analog-Digital-Wandlern, vom Client, etwa einem Zonen-Controller, an den RCP-Server übertragen oder von diesem angefordert. Der RCP-Server ist anwendungsunabhängig und bildet eine Brücke zwischen der Ethernet-Welt und der Nicht-Ethernet-Welt, ohne selbst die jeweilige Anwendungslogik auszuführen. Dadurch kann der RCP-Server als softwarelose Endpunkt ausgeführt werden, der standardisierte Kommunikationsschnittstellen und Funktionen bereitstellt. Als Anbindung an das übergeordnete Netzwerk kann beispielsweise 10BASE-T1S verwendet werden.

10BASE-T1S ist für den Anschluss von wenigstens acht Knoten an ein gemeinsames Übertragungsmedium ausgelegt und unterstützt alle bestehenden Ethernet-Protokolle. Die Datenübertragung erfolgt mit einer festen Bitrate von 10 Mbit/s im Halbduplexbetrieb, weshalb jeweils nur ein Knoten etwas senden kann. Um Kollisionen zu vermeiden, nutzt die Technologie das Physical-Layer-Collision-Avoidance -Verfahren (PLCA), wobei jedem Knoten ein Sendezeitfenster zugewiesen wird. In diesem Zeitraum darf der betroffene Knoten Daten übertragen, während die anderen Knoten zuhören. Die Sendezeitfenster werden zyklisch, also in einer Round-Robin-Reihenfolge, durchlaufen.

Halbleiter für intelligente und softwarelose Endpunkte

Durch die Kombination aus Ethernet, RCP und softwarelosen oder intelligenten Endpunkten ergeben sich neue Anforderungen an die Integration von Sensoren und Aktoren in eine zentralisierte Fahrzeugarchitektur. Kommunikationsschnittstellen, Rechenfunktionen und Leistungselektronik müssen auf die jeweilige Aufgabe zugeschnitten sein. Verschiedene Beispiele aus der Motor- und LED-Steuerung veranschaulichen die technischen Anforderungen.

Bei intelligenten Endpunkten, die unter anderem Motoren steuern, spielen neben dem Mikrocontroller, wie der Traveo T2G, und der Kommunikationsschnittstelle auch das Design und die Integration der Leistungsstufe eine entscheidende Rolle. Je nach erforderlicher Motorleistung kann diese mit diskreten MOSFETs, integrierten MOSFETs oder einer direkt in den System-on-Chip (SoC) integrierten Leistungsstufe realisiert werden. Ein Beispiel hierfür sind die Motix-Mikrocontroller von Infineon für die Ansteuerung von Gleichstrommotoren (DC) und bürstenlosen Gleichstrommotoren (BDLC). Die Bauteile werden direkt aus dem Bordnetz des Fahrzeugs mit Strom versorgt. Je nach Ausführung erfolgt die Kommunikation über LIN, beispielsweise beim TLE9879, oder über CAN, etwa beim TLE9899.

Die Leistungsstufe lässt sich je nach Motorleistung unterschiedlich konfigurieren: Für Motoren bis zu 1 kW können diskrete MOSFETs auf der Steuereinheit verwendet werden. Für Motoren bis zu 150 W stehen Varianten mit integrierten MOSFETs in einem System-in-Package (SiP) zur Verfügung. Für Motoren bis zu 15 W kann die Leistungsstufe direkt in den System-on-Chip integriert werden.

Bei softwarelosen Endpunkten liegt der Schwerpunkt hingegen auf der Bereitstellung einer definierten Funktion über standardisierte Kommunikationsschnittstellen. Ein Beispiel hierfür ist der LED-Treiber TLD7022 aus der LITIX™-Familie von Infineon. Er kann die Ansteuerung mehrerer LEDs übernehmen und eignet sich unter anderem für animierte Front- und Heckbeleuchtung. Die Kommunikation erfolgt über UART via CAN und erfordert keine programmierbare Anwendungssoftware direkt im Bauteil. Des Weiteren untersucht Infineon derzeit Konzepte für ein konfigurierbares Portfolio für softwarelose Endpunkte.

Praktisches Beispiel: Software-Verteilung in einem Scheibenwischersystem

Ein Demonstrator (Bild 4) auf Basis eines Fahrzeug-Scheibenwischersystems veranschaulicht, wie Aufgaben zwischen zentraler Software und intelligenten oder softwarelosen Endpunkten verteilt werden können. In diesem Aufbau wird die Anwendungssoftware für die Wischerfunktion von der dedizierten Wischersteuereinheit auf den Zonencontroller verlagert. Die Kommunikation zwischen dem Zonencontroller und den drei Endpunkten erfolgt über Ethernet mittels 10BASE-T1S. Durch die Multidrop-Funktion können alle drei Endpunkte über ein einziges Twisted-Pair-Kabel angeschlossen werden.

Der Lenkradschalter ist als softwareloser Endpunkt konzipiert, bei dem die SPI-Kommunikation mit dem 3D-Hall-Sensor über RCP an den Zonencontroller weitergeleitet wird. Bei den beiden auf bürstenlose Gleichstrommotoren (BLDC) basierenden Scheibenwischermotoren handelt es sich dagegen um intelligente Endpunkte, die per 10BASE-T1S kommunizieren. Die Motorsteuerungssoftware läuft auf einem Arm Cortex-M3-Mikrocontroller innerhalb des SoC und nutzt die Motor Control Software Library von Infineon.

Die Anwendungslogik für die Scheibenwischerfunktion befindet sich im Zonencontroller, während die Motor-Endpunkte die für die Motorsteuerung erforderlichen Funktionen ausführen. Der Lenkradschalter hingegen benötigt keine eigene, frei programmierbare Anwendungssoftware; seine Signale werden über RCP an den Zonencontroller übertragen. Damit veranschaulicht der Demonstrator das Zusammenspiel zwischen softwarelosen und intelligenten Endpunkten: Die Anwendungssoftware befindet sich im Zonencontroller, während die Endgeräte standardisierte Schnittstellen bereitstellen oder lokale Aufgaben wie die Motorsteuerung übernehmen.

Die Rolle der Endpunkte verändert

Mit der Zentralisierung der Fahrzeug-Software verändert sich auch die Rolle der Endpunkte. Während intelligente Endpunkte lokale Aufgaben wie Motorsteuerung übernehmen, stellen softwarelose Endpunkte standardisierte Funktionen bereit, etwa in Form eines Protokoll-Handlers. Mithilfe von Ethernet und RCP können beide Typen in eine zentralisierte Fahrzeugarchitektur eingebunden werden. Damit wird die Aufgabenteilung zwischen zentraler Software und dezentraler Hardware zu einem wichtigen Gestaltungsprinzip softwaredefinierter Fahrzeuge. (se)

* Tobias Otter ist Vice President Technical Marketing, Application and Platform bei Infineon Technologies. Daniel Mysliwitz arbeitet System Architekt bei Infineon Technologies.

(ID:51011233)