ECUs in Fahrzeugen

Klassisch verteilte ECUs – Zentralisierung in Domains – Softwaredefiniertes Fahrzeug: Durch die Konsolidierung der Architektur lassen sich die Funktionalität im Fahrzeug verbessern und Kosten reduzieren. (Bild: RTI)

Eckdaten 'Kommunikations-Framework für E-Autos'

Die Nutzung eines datenzentrierten Frameworks, das nicht nur Standardfunktionen besitzt, sondern unter anderem auch DDS-XTypes und benutzerdefinierte Datenflüsse ermöglicht, gewährt ein flexibles und anpassungsfähiges Datenmodell. Der datenzentrierte Ansatz erlaubt zudem verschiedene Kommunikationsmuster wie Command und Control, SOA, Pub/Sub und mehr, um die Integration zu erleichtern.

Was der Markt für Elektrofahrzeuge in Zukunft braucht, lässt sich nur schwer voraussagen, vor allem in einer Umgebung, die sich so schnell verändert. Für Softwareingenieure wirkt sich diese Ungewissheit auch darauf aus, wie sie Software für diesen expandierenden Markt designen und entwickeln.

4 Regeln, um ein E/E-System der nächsten Generation anpassungsfähig zu machen

Auf dem Markt besteht der Trend, die Anzahl der Steuergeräte zu verringern und zonale Controller sowie Zentraleinheiten hinzuzufügen. In vielen derzeitigen Entwicklungen ist die Software jedoch stark an diese spezifischen Steuergeräte sowie an den Datenaustausch auf lokaler Hardware und proprietären Stacks gekoppelt. Erwartungsgemäß kann die Umstellung auf einen anderen Ansatz einen enormen Aufwand bedeuten, sofern keine sorgfältige Auswahl der Software erfolgt.

Um ein E/E-System der nächsten Generation anpassungsfähig zu machen, gibt es vier Hauptregeln zu beachten:

1. Entkopplung: Ein erfolgreiches zukunftsorientiertes System sollte idealerweise auf einem Framework aufbauen, welches das Betriebssystem sowie hardwarespezifische Details abstrahiert. Auf diese Weise muss jedes Softwaremodul nur einmal entwickelt werden und lässt sich dann beliebig oft bereitstellen. Der Schlüssel zum Erfolg bei der Entkopplung liegt in der Minimierung des Overheads der Abstraktionsschicht bei gleichzeitiger transparenter Nutzung der Hardware- und Betriebssystemfunktionen.

2. Flexibilität: Wird ein Fahrzeug der Autonomiestufe 2 designt, soll sich dessen Verhalten auch beim Hinzufügen von Eigenschaften der Stufe 4 nicht verändern. Der Trick dabei lautet Datenschnittstellen zu definieren, die sich ändern können, denn sie werden sich ändern. Glücklicherweise kann dieser Schritt genauso einfach sein wie die Verwendung eines flexiblen Datenmodells.

3. Kundenspezifische Anpassung: Ein mühsamer Ansatz ist es für jede Art von gesendeten Daten eine andere Technologie zu verwenden. Dies scheint zunächst mehr Leistung zu ermöglichen, erhöht jedoch unnötigerweise die Komplexität des Systems und bindet die Entwickler an die Hardware. Eine bessere Option besteht in der Auswahl einer einzigen Lösung, die transportunabhängig ist und sich auf einfache Weise so justieren lässt, dass sie sich an die verschiedenen Datenflüsse im System anpasst, die zugrundeliegenden Technologien voll ausnutzt und die Leistung basierend auf den Datenanforderungen optimiert.

4. Integration: In der Regel möchte man bestehende Systeme gerne beibehalten und viele innovative neue Technologien mit einbeziehen. Um diese verschiedenen Systeme erfolgreich zu integrieren, muss ein Gleichgewicht zwischen den bereitgestellten Funktionen, der technologischen Ausgereiftheit und der damit verbundenen Komplexität erreicht werden.

Blockdiagramm Datenflüsse in E-Fahrzeugen
Datenflüsse im System eines elektrischen Fahrzeugs. (Bild: RTI)

Ein langlebiges System aufzubauen ist nicht einfach. Um erfolgreich zu sein ist es unerlässlich ein System zu entwickeln, das während des Wachstums skalierbar ist und noch unbekannte Anforderungen, die erst im Laufe der Entwicklung auftauchen, mitberücksichtigt. Doch es gibt einen schnellen Weg um es mit dem Elektrofahrzeug zur Marktreife zu schaffen.

Wie hilft ein Kommunikations-Framework?

Im Hinblick auf diese vier Regeln kann ein Kommunikations-Framework speziell für die Automobilindustrie dazu beitragen, die richtige Richtung einzuschlagen. RTI Connext Drive, das auf dem Data Distribution Service (DDS) -Standard basiert, bietet eine Abstraktionsschicht, welche die Entwicklung vereinfacht, indem sie Hardware- und betriebssystemspezifische Konfigurationen ausblendet. Gleichzeitig geht es über den Standard hinaus und bietet zusätzliche wichtige Funktionen.

Entkopplung der Inbetriebnahme von der Entwicklung

Beim Entwickeln einer neuen Architektur möchte man es vermeiden, die Hälfte der Entwicklungsarbeit wiederholen zu müssen, wenn ein neues Board oder Betriebssystem zum Einsatz kommt. Die Software sollte so unabhängig wie möglich sein.

Durch das Kommunikations-Framework definiert jedes Modul Schnittstellen mithilfe von Standard-IDLs der Object Management Group (OMG), wodurch eine datenzentrische Architektur erstellt wird. Die Module werden dann automatisch und dynamisch mit kompatiblen Schnittstellen und Anforderungen über eine Discovery-Funktion verbunden (mehr dazu im Abschnitt „Anpassung des Datenflusses“). Darüber hinaus generieren die Schnittstellen plattformunabhängigen Code für die gewählte Programmiersprache. Das Architekturparadigma abstrahiert die Punkt-zu-Punkt-Verbindungen, die vom Framework erstellt und einfach in bekannte Design-Tools integriert werden. Diese Abstraktion schafft zwei zusätzliche Vorteile: Erstens lässt sich die Software auf jeder Hardware einsetzen und reduziert damit Zeit und Kosten. Zweitens nutzt das Kommunikations-Framework die zugrundeliegende Infrastruktur sehr transparent.

Ein Beispiel: Bei der ersten Inbetriebnahme werden mehrere kleinere Steuergeräte (ECU) verwendet, die über Ethernet verbunden sind. Hier nutzt das Framework Ethernet und UDP, um die Module zu verbinden. Die nächste Serie erhält dann eine leistungsstärkere zentrale GPU/ECU mit gemeinsam genutztem Speicher und geht in eine zonale Architektur über. Dabei müssen nur mehrere Module in der neuen GPU bereitgestellt werden und das Framework überträgt ganz einfach und transparent alles in den gemeinsam genutzten Speicher – ohne Codeänderungen.

Flexibilität und Anpassungsfähigkeit

Um den Entwicklungsaufwand zu reduzieren, ist die Wiederverwendung der eigenen Softwaremodule für verschiedene Fahrzeugserien sinnvoll. Dafür muss jedes Modul in der Lage sein, entweder hochentwickelte kostspielige Sensoren zu nutzen oder falls nötig auch einfachere Sensoren zu verwenden. Zudem müssen sich die Softwaremodule an neue Funktionen anpassen und mit minimalen Änderungen höhere Autonomieebenen ermöglichen. Aufbauend auf dem Datenmodell bietet ein spezifisches Kommunikations-Framework wie Connext Drive zwei wichtige Aspekte, um die Softwareflexibilität eines Elektrofahrzeugs zu erhöhen: Zum einen die Option neue Module per Plug-and-Play hinzuzufügen und zum anderen die Möglichkeit, das Datenmodell zu erweitern. Der erste Aspekt wird dank datenzentrischen Designprinzipien und der im vorherigen Abschnitt erläuterten Erkennungsfunktion bereitgestellt. Der zweite Aspekt wird dank der erweiterbaren Typen (DDS-XTypes) ermöglicht.

Wird ein eigenes Datenmodell definiert, sollte es sich an neue Daten (von komplexeren Sensoren) oder neue Funktionen (von einer neuen Autonomieebene) anpassen können. Wie in C++ oder Java definieren Entwickler mit DDS-XTypes ihre Basic-„Klasse“ und erstellen dann neue „Klassen“, die darauf aufbauen. Alle diese abgeleiteten Klassen sind theoretisch miteinander kompatibel.

Hier ein Beispiel

Die Basic-Klasse für erkannte Objekte umfasst die dunkelgrünen Felder. Jede neue erweiterte Klasse fügt eines oder mehrere der hellgrünen Felder hinzu. Auf diese Weise verwenden die Module, die diese Daten nutzen (blaue und orangefarbene Boxen), abhängig von den verfügbaren Daten nur die Felder, die sie verstehen und ignorieren den Rest.

Darstellung eines Datenmodells
Datenmodell: Die dunkelgrünen Felder sind die Basic-Klasse für erkannte Objekte, jede neue erweiterte Klasse fügt hellgrüne Felder hinzu. Die blauen und orangefarbenen Boxen, also die Module, die diese Daten nutzen, verwenden nur Felder, die sie verstehen, und ignorieren den Rest. (Bild: RTI)

Anpassung des Datenflusses

Für einen Datenaustausch in einem elektrischen Fahrzeugsystem reicht die gemeinsame Nutzung von Datenschnittstellen nicht aus, denn unterschiedliche Daten besitzen unterschiedliche Anforderungen an Zuverlässigkeit, Latenz und vieles mehr. Alle Module müssen sich auf die Art des Datenaustauschs einigen. Für die Feinabstimmung in der Kommunikation bietet Connext Drive über 20 Quality-of-Service-Einstellungen (QoS). Auf diese Weise kann eine einzelne Konnektivitätslösung alle möglichen Daten übertragen, ohne dass Technologien ausgelagert werden müssen, um die Leistung zu erzielen.

Die QoS-Einstellungen verhalten sich im Prinzip wie ein Vertrag. Beim Erstellen eines Empfangsmoduls erfolgt die Definition der Anforderungen wie Häufigkeit, Zuverlässigkeit, Stammdaten und so weiter. Genauso lassen sich im Produktionsmodul die Lieferperiode, Beständigkeit, Reparaturhäufigkeit und vieles mehr definieren. Wenn sich diese Module gegenseitig erkennen, tauschen sie ihre Verträge aus und stellen nur dann eine Verbindung her, wenn ihre Kommunikationsvereinbarungen kompatibel sind. Diese Anpassung des Datenflusses nutzt auf transparente Weise zugrundeliegende Technologien wie Time-Sensitive Networking (TSN).

Integration

Das automobile Ökosystem ist sehr groß und vielfältig. Es gibt viele Software- und Hardwarelösungen, um die Entwicklung einfacher zu gestalten und die Produktivität zu beschleunigen. Durch die aktive Arbeit von RTI in mehreren Automobilkonsortien wie AUTOSAR und ROS 2 sowie der Zusammenarbeit mit marktführenden Unternehmen soll die Integration erleichtert und die Entwicklungszeit verkürzt werden.

Das betrifft nicht nur die Kommunikation im Fahrzeug, sondern auch die Arbeit in anderen Marktbereichen wie zum Beispiel Simulation. Damit lassen sich zum Beispiel fahrzeuginterne Daten in einer Datenbank speichern, ohne das Echtzeitverhalten des Systems zu beeinträchtigen. Diese Datenbank lässt sich dann für die Simulation oder Hardware-/Software-in-the-Loop-Tests verwenden. Die Möglichkeiten sind unbegrenzt – das einzige Limit besteht darin, inwieweit die Wiederverwendbarkeit und Integration erfolgen soll.

Standard-Organisationen wie ROS 2 und AUTOSAR nutzen den Data Distribution Service (DDS) als Teil ihres Frameworks. Über 200 Automobilprojekte sowie immer mehr Unternehmen im Bereich autonome und elektrische Fahrzeuge setzen auf RTI Connext als Kommunikationslösung. (na/neu)

Funktionsweise des DDS
Der DDS-Datenbus verbindet primäre Autonomiefunktionen und teilt ein gemeinsames Datenmodell mit anderen Systemen und Standards, einschließlich AUTOSAR Adaptive und ROS2. (Bild: RTI)

Autorin

Autorin Sara Granados Cabeza

Sara Granados Cabeza, Principal Field Application Engineer bei Real-Time Innovations (RTI)

Autor

Autor Peter Schmuckermaier

Peter Schmuckermaier, Senior Account Manager bei RTI für Continental Europe

Kostenlose Registrierung

Bleiben Sie stets zu allen wichtigen Themen und Trends informiert.
Das Passwort muss mindestens acht Zeichen lang sein.
*

Ich habe die AGB, die Hinweise zum Widerrufsrecht und zum Datenschutz gelesen und akzeptiere diese.

*) Pflichtfeld

Sie sind bereits registriert?