Datengetriebene Kommunikation für SDV-Plattformen

Die Entwicklung softwaredefinierter Fahrzeuge (SDVs) ist zwar nach wie vor vielversprechend, hat aber einen Dämpfer erlitten. Ähnlich wie beim Konzept des autonomen Fahrens der SAE-Levels 4+ lässt sich das Ideal eines datengesteuerten SDVs zwar relativ einfach beschreiben, doch die praktische Umsetzung ist wesentlich schwieriger. Ein zentraler Grund dafür ist die Komplexität der Systemintegration.

Ein SDV wird im Kern durch Daten gesteuert. Dabei kommen riesige Datenmengen aus unzähligen Quellen zum Einsatz. Jede davon hat spezifische Anforderungen, und die Daten müssen genau dann und dorthin in Echtzeit gesendet werden, wo sie benötigt werden.

Die Herausforderung liegt in den Daten selbst: Wie werden sie dargestellt? Als Textzeichenfolge, als Ganzzahl oder als Gleitkommazahl? Sind sie absolut oder relativ? Gibt es einen Offset oder einen Skalierungsfaktor?

Woher kommen diese Daten? Idealerweise sind sie überall dort verfügbar, wo sie im Fahrzeug benötigt werden. Dafür muss ihre Quelle jedoch auffindbar und verständlich sein.

Das sind die Strategien für das Software-defined Vehicle (SDV)

Es gilt jetzt Software-defined Vehicles (SDV) holistischer zu betrachten. Schließlich gehen komplett neue Geschäftsmodelle damit einher. Wer setzt auf welche Strategie?

Und schließlich: Wie erfolgt der Zugriff auf diese Daten? Geschieht dies über eine serviceorientierte Architektur (SOA), eine herstellerspezifische API oder eines der von der Allianz entwickelten Frameworks? Erfordert dies eine enge Kopplung zwischen den Komponenten?

Fahrzeuge bestehen aus Komponenten, die aus einem Ökosystem aus Zulieferern und Integratoren stammen. Wenn diese „besten“ Subsysteme digital miteinander verschweißt werden, bringt das neue Komplexitäten und Kosten mit sich. Um dieses Problem zu lösen, hat die Automobilindustrie gemeinsame Software-API-Standards für die Kommunikation zwischen Komponenten geschaffen. Diese Ansätze stellen Entwickler jedoch weiterhin vor Herausforderungen. Die APIs sind für ein SDV von entscheidender Bedeutung. Ein datenzentrierter Ansatz kann die Komplexität der Systemintegration reduzieren. COVESA arbeitet bereits an der Entwicklung und Integration entsprechender Modelle.

Wie funktioniert datengetriebene Kommunikation im SDV? 

Das Ideal eines datengesteuerten SDVs kann um drei Punkte ergänzt werden: Erstens verwenden alle Daten einen gemeinsamen Typ- und Formatstandard. Dies umfasst alle Daten im und um das Fahrzeug herum, z.B. Sensoren, Aktoren, Software-Datenobjekte, für alle Systeme: Fahrgastraum, Fahrwerk, ADAS, Infotainment, V2X usw..

Außerdem bilden die Daten selbst die Schnittstelle zwischen den Komponenten. Beispielsweise könnte ein Wahrnehmungssystem Eingaben von Kamera, LiDAR, Radar, GNSS und IMU unter Verwendung der Standarddatentypen erwarten und eine Liste der wahrgenommenen Objekte sowie deren Position und Bewegung exportieren. Dabei würden ebenfalls die Standarddatentypdefinitionen verwendet.

Und zuletzt gibt es im Fahrzeug einen „globalen Datenraum”. Jede ECU und jeder Verarbeitungsknoten im Fahrzeug hat vollen Zugriff auf alle Daten im globalen Datenraum. Dadurch wird die Aufgabe der Erstellung und Integration eines SDV erheblich vereinfacht:

• Softwarefunktionen, die mit diesen Datentypen arbeiten, können an beliebiger Stelle im Fahrzeug platziert werden – in jeder ECU oder jedem Rechenknoten.

Strategien für die softwaredefinierte Zukunft

Software wird zum Taktgeber der Autoindustrie: Auf der Automotive Software Conference 2025 zeigte sich, wie Code Innovation, Geschäftsmodelle und neue Strategien im Zeitalter der SDVs antreibt.

• Komponenten können frei ausgetauscht oder aufgerüstet werden, ohne dass die üblichen Integrationsprobleme auftreten.

• Für aktuelle Fahrzeuge geeignete Komponenten können auch in zukünftigen Fahrzeugen weiter eingesetzt werden.

• Komponenten können unabhängig von Marke oder Modell entwickelt werden – sie sind auf die Daten zugeschnitten, nicht auf das Fahrzeug.

Welche Rolle spielt das COVESA VSS-Datenmodell?

Ein solches System wird aktuell aktiv entwickelt. Mit COVESA und DDS sind diese datenzentrierten Systeme bereits auf dem Weg in die Umsetzung – sie werden derzeit erstellt, getestet und eingesetzt. COVESA übernimmt eine führende Rolle bei der Weiterentwicklung datengesteuerter SDVs und der Erweiterung ihrer Fähigkeiten durch Open Source- / offene Standards und kommerzielle Unterstützung.

COVESA (Connected Vehicle Systems Alliance) ist eine Technologieallianz, die weltweit Organisationen zusammenbringt, um neue Technologien für vernetzte Fahrzeuge zu entwickeln. Sie ist Gründungsmitglied der SDV Alliance und hat einen Schwerpunkt auf der Definition eines Katalogs gemeinsamer Datentypen, die in der Vehicle Signal Specification (VSS) enthalten sind.

Middleware: Rückgrat für smarte SDV-Architekturen

Im softwaredefinierten Fahrzeug übernimmt Middleware eine zentrale Rolle. Sie verbindet Hardware, Software und Cloud-Systeme und ermöglicht flexible Funktionen über den gesamten Fahrzeuglebenszyklus – ein entscheidender Baustein moderner SDV-Architekturen.

DDS (Data Distribution Service) ist ein von der Object Management Group (OMGR) entwickelter Standard für datenzentrierte Kommunikation. Bei DDS bilden die Daten selbst die Schnittstelle zwischen den Systemkomponenten. Es verwendet ein Publish-Subscribe- oder Request-Reply-Muster mit automatischer Erkennung, ist unabhängig vom zugrunde liegenden Transport und bietet eine Vielzahl von Quality-of-Service-Funktionen (QoS), die einen Betrieb auch unter härtesten Bedingungen ermöglichen. DDS bietet durch eine effiziente binäre Datenkodierung eine extrem hohe Leistung und kann die zugrunde liegenden Transportfunktionen nutzen, ohne die Code-Portabilität zu beeinträchtigen.

Datenorientiertes Framework für Systeminteroperabilität

Ein Funktionsprinzip der DDS ist ein gemeinsamer Satz benutzerdefinierter Datentypen, die alle Daten umfassen (u.a. Radarsignale, Fahrerkontrollen, Video-Feeds, Sensoren, Aktoren). Diese Datentypdefinitionen werden im gesamten System verwendet.

Ein weiteres Funktionsprinzip sind Publisher und Subscriber der Datentypen. Softwareanwendungen erstellen diese Daten zur Veröffentlichung oder abonnieren sie zur Nutzung. In beiden Fällen kommuniziert die Anwendung nur mit den Daten selbst, unabhängig von ihrer Quelle, ihrem Ziel oder ihrem Weg dorthin.

Das letzte Funktionsprinzip ist die Erkennung anderer DDS-Teilnehmer, um die Publisher und Subscriber aller im System verwendeten Datentypen zu lokalisieren und abzugleichen. Dadurch werden die Verbindungen für den Datenfluss hergestellt. Die Erkennung funktioniert über alle unterstützten Transportprotokolle hinweg. Somit sind bei einer Neukonfiguration des Systems keine Änderungen an den Anwendungen erforderlich.

Die DDS-Core-Bibliotheken erkennen andere DDS-Teilnehmer durch die QoS-Konfiguration und übernehmen die Sicherheit, sofern aktiviert. Letztere kann Authentifizierung, Verschlüsselung und Zugriffskontrolle für jeden einzelnen Datenfluss handhaben.

Der DDS-Core ist mit der Transportabstraktionsschicht verbunden, die es DDS ermöglicht, über nahezu jeden Übertragungsweg zu arbeiten.

Standardisierter, Software-konfigurierbarer Halbleiter

Secor hat sein SDV Concept erstmals in ein Serienfahrzeug integriert – mit einem standardisierten Chip, der die Fahrzeugarchitektur neu denkt. Erste messbare Ergebnisse zu Entwicklungszeit und Kosten zeigen eine klare Richtung.

Dies ist die letzte Schnittstelle zum von DDS geschaffenen Global Data Space. Es ist eine Abstraktion, in der alle Daten im System aktuell und verfügbar sind. Sie bietet die einzige verlässliche Informationsquelle für das, was im System geschieht.

Durch diese Anordnung in DDS ist es möglich, Softwarekomponenten zu entwickeln, ohne sich um die zugrunde liegende Hardware, das Betriebssystem, das Netzwerk oder die Programmiersprache kümmern zu müssen. Komplexe Systeme können von völlig unabhängigen Teams aufgebaut werden, wobei jedes Team seinen eigenen optimalen Ansatz verfolgt und gleichzeitig über eine standardbasierte Grundlage für Interoperabilität und Leistung verfügt.

Es gibt mehr als ein Dutzend Implementierungen von DDS, sowohl Open-Source- als auch kommerzielle, und diese standardkonformen Implementierungen sind vollständig miteinander kompatibel. DDS ist für die meisten gängigen Programmiersprachen und Betriebssysteme bzw. RTOS verfügbar und ist eines der beiden Kommunikationsframeworks des AUTOSAR-Standards.

DDS bietet die folgenden Funktionen:

• Extreme Leistung: DDS arbeitet über IP-Netzwerke und sogar noch schneller über gemeinsam genutzten Speicher.

• Erweiterte QoS-Funktionen zur Feinabstimmung der Datenflüsse.

• Standardbasierte Interoperabilität, um sicherzustellen, dass verschiedene Implementierungen von DDS zusammenarbeiten.

• Einfache Implementierung dank umfassender Plattformunterstützung: DDS läuft auf Desktop- und Echtzeit- sowie Automobil-Plattformen

• Einfach zu verstehen, da der Fokus auf den Daten selbst liegt.

• Einfach anzuwenden dank automatischer Erkennung, globalem Datenbereich und Datenzentriertheit.

• Einfach zu sichern aufgrund granularer Authentifizierung, Verschlüsselung und Zugriffskontrolle für jeden Datenfluss.

Welche Rolle spielt das COVESA VSS-Datenmodell?

In Kombination mit anderen Datentypen, wie dem COVESA VSS, kann DDS die Systemkomplexität reduzieren und die Entwicklung von SDVs sowie die Realisierung der Autonomiestufen SAE L2–L5 vereinfachen.

Und so funktioniert es:

Da die Daten selbst die Schnittstelle bilden, erfordern DDS-basierte Systeme keine enge Kopplung zwischen Anwendungen. Eine Wahrnehmungskomponente beispielsweise, die Kamera- und Radardaten importiert und eine Liste identifizierter Objekte exportiert, erfordert in der Regel einen erheblichen Programmier- und Testaufwand, um die Komponenten-API und die Datenformatierung an den Rest des Systems anzupassen. Beim Einsatz von DDS für die Middleware-Schicht entfällt ein Großteil dieser Arbeit. Der Integrationsaufwand zwischen DDS und einem gemeinsamen Satz von Datentypen wird minimiert, da jede Komponente genau den Datentyp erzeugt und erhält, den sie benötigt.

Diese lose gekoppelte, datenzentrierte Architektur eröffnet Komponentenlieferanten die volle Freiheit bei der Verwendung der jeweils am besten geeigneten Technologie. So lässt sich eine Herstellerabhängigkeit für OEMs vermeiden und zugleich erhalten Lieferanten die Möglichkeit, ihre bevorzugten Technologiekomponenten zu nutzen.

 DDS schafft einen „Globalen Datenraum“, in dem alle Daten für alle mit dem Netzwerk verbundenen Teilnehmer verfügbar sind. Das erleichtert die Verlagerung von Softwareanwendungen innerhalb des Systems z.B. bei der Weiterentwicklung von verteilten Steuereinheiten zu zentralisierten Hochleistungsrechnern.

 Ein Szenario: Es werden Komponenten für ein gemeinsames Datenmodell und DDS entwickelt. Das ermöglich eine Drop-in-Plug-and-Play-Interoperabilität von Komponenten, die unabhängig entstanden sind. Diese Komponenten könnten zwischen Lieferanten und Fahrzeugen ausgetauscht und aktualisiert werden, und zwar mit einfachen Integrationsmaßnahmen ohne kundenspezifische Entwicklung. Dadurch könnten Zulieferer diese Komponenten mit höherem Wert und zu geringeren Kosten herstellen. So schafft dieses Modell ein effizientes Ökosystem.

 Mit DDS ist dieses Szenario bereits heute realisierbar. Ein Beispiel dafür ist das ROS 2-Projekt. ROS 2 nutzt DDS als Kommunikationsframework und verfügt über einen sehr stabilen und schnell wachsenden Satz gemeinsamer Datentypen. Diese beiden Faktoren haben es ROS ermöglicht, ein dynamisches Ökosystem aufzubauen, das von Low-Level-Sensorik und -Aktuatorik bis hin zu Umfelderkennung, Wegplanung, SLAM und vielem mehr reicht.

SDV: Bremst Cybersecurity Innovationen aus?

Die Transformation hin zum Software-defined Vehicle hat Innovationen beschleunigt – und neue Schwachstellen offengelegt. Sicherheitsanforderungen und Regulierungen setzen die Branche unter Druck. Wie lässt sich Tempo halten, ohne Cyberrisiken zu übersehen?

Ein weiteres Beispiel ist AUTOSAR Adaptive: Hier wird die sprachunabhängige, dienstorientierte Semantik von ara::com über eine DDS-Netzverbindung auf das DDS-Standardtypsystem und die APIs abgebildet. Dadurch wird das umfangreiche Set an DDS-QoS-Richtlinien in die serviceorientierte Architektur von AUTOSAR integriert. Dieser Ansatz ermöglicht neue Interoperabilitätsszenarien, in denen AUTOSAR-Systeme durch die Nutzung des DDS-Datenbusses in größere System-of-Systems-Umgebungen (SoS) integriert werden können. Der DDS-Datenbus verteilt und verwaltet Echtzeitdaten in intelligenten Systemen.

 Die Nutzung von DDS und gängigen Datentypen wie COVESA VSS für die SDV-Entwicklung kann sich auf Kosten, Zeit und Wert der SDV-Entwicklung auswirken. COVESA VSS kann:

• Zeit einsparen, indem aufwändige Systemintegrationen reduziert werden.

• Mehrwert schaffen, indem Komponenten über verschiedene Marken, Modelle und Modelljahre hinweg wiederverwendet werden.

• Kosten senken, indem kurzlebige kundenspezifische Entwicklungsarbeiten während der Systementwicklung vermieden werden.

 Weitere Vorteile sind Effizienzsteigerungen durch geringere Komplexität sowie die Stärke eines gemeinsamen Ökosystems und einen größeren Talentpool.

COVESA VSS als Grundlage für einheitliche Datenmodelle

Ein gemeinsamer und klar definierter Satz von Datentypen ist für ein datenzentriertes System von entscheidender Bedeutung. Die COVESA Vehicle Signal Specification (VSS) ist eine von der Allianz entwickelte, unabhängige Referenz für die Datentypen und Signale innerhalb eines Fahrzeugs. Die aktuell verfügbare VSS umfasst mehr als 850 Datensignale in den Bereichen Karosserie, Fahrgastraum, Fahrwerk, ADAS, Antriebsstrang usw. Sie wird kontinuierlich erweitert, um weitere Fahrzeugtypen, fortschreitende Autonomie und V2X und mehr abzudecken.

Ein Teil dieser Erweiterungsarbeit erfolgt mit DDS. Die COVESA VSS ist außerordentlich gut auf DDS abgestimmt. Zusammen mit diesem führenden Kommunikationsframework bietet die VSS ein stabiles und umfassendes Datenmodell für SDVs. Es ist eine der ersten gemeinsamen Bemühungen zur Anwendung von DDS auf spezifische Automobilfunktionen in SDVs.

Rund um die VSS hat sich ein Ökosystem von Lösungen gebildet, das eine schnelle Prototypenentwicklung, eine verbesserte Wartung und ein verbessertes Nutzererlebnis im Fahrzeug ermöglicht – Dank der datenzentrierten Interoperabilität durch die Verwendung gemeinsamer Datentypen.

Das Rennen hat begonnen: Die Fahrzeugarchitektur entwickelt sich rasant weiter, und COVESA erweitert die VSS um diese neuen Funktionen, wobei es noch viel zu tun gibt. Als gemeinschaftlich entwickelter Standard unterstützt COVESA aktiv die Expansion in neue Bereiche. (bs)