Data Distribution Service für die Interoperabilität von SDVs

Ein softwaredefiniertes Vehicle (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. 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 hat 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.

Datenorientierter Ansatz 

Wir ergänzen das Ideal eines datengesteuerten SDVs um drei Punkte:

1. Alle Daten verwenden 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.
2. Die Daten selbst bilden 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.
3. Im Fahrzeug gibt es einen „globalen Datenraum”. Jede ECU und jeder Verarbeitungsknoten im Fahrzeug hat vollen Zugriff auf alle Daten im globalen Datenraum.

Save the date: 30. Automobil-Elektronik Kongress

Am 16. und 17. Juni 2026 findet zum 30. Mal der Internationale Automobil-Elektronik Kongress (AEK) statt. Dieser Netzwerkkongress ist bereits seit vielen Jahren der Treffpunkt für die Top-Entscheider der Elektro-/Elektronik-Branche und bringt nun zusätzlich die Automotive-Verantwortlichen und die relevanten High-Level-Manager der Tech-Industrie zusammen, um gemeinsam das ganzheitliche Kundenerlebnis zu ermöglichen, das für die Fahrzeuge der Zukunft benötigt wird. Trotz dieser stark zunehmenden Internationalisierung wird der Automobil-Elektronik Kongress von den Teilnehmern immer noch als eine Art "automobiles Familientreffen" bezeichnet.

Sichern Sie sich Ihr(e) Konferenzticket(s) für den 30. Automobil-Elektronik Kongress (AEK) im Jahr 2026! Folgen Sie außerdem dem LinkedIn-Kanal des AEK und #AEK_live.

Im Channel zum Automobil-Elektronik Kongress finden Sie Rück- und Vorberichterstattungen sowie relevanten Themen rund um die Veranstaltung.

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.
• 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.

Ein solches System wird aktuell aktiv entwickelt. Mit COVESA und DDS sind diese datenzentrierten Systeme bereits auf dem Weg, erstellt, getestet und eingesetzt zu werden. 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.

Abwehr unerlaubter Netzwerkzugriffe mit Automotive Firewalls

SDVs eröffnen neue Möglichkeiten – aber auch neue Cyberrisiken. Hybride Automotive-Firewalls nutzen smarte Hardware- und Softwarefilterung, um Angriffe auf Fahrzeugnetzwerke effizient abzuwehren. Warum das die Zukunft der Fahrzeugsicherheit ist.

Was sind COVESA und DDS?

COVESA (Connected Vehicle Systems Alliance) ist eine Technologieallianz, die weltweit Organisationen zusammenbringt, um innovative 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.

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 

Die Funktionsprinzipien von DDS sind: 

• Ein gemeinsamer Satz benutzerdefinierter Datentypen, die alle Daten umfassen (u.a. Radarsignale, Fahrerkontrollen, Video-Feeds, Sensoren, Aktoren). Diese Datentypdefinitionen werden im gesamten System verwendet.
• 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.
• 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.

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.

Teleoperation mit DDS: Der erste Schritt zur Autonomie

Autonomie, die sich bereits seit Jahren in Drohnen, Robotern und Unterwasserfahrzeugen entwickelt, nutzt die „Teleoperation“. So kann auch die Automobilindustrie hochautonome Autos früher realisieren.

Welche Funktionen bietet DDS?

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.

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.

Einfache Integration über Daten als gemeinsame Schnittstelle

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.

Anwendungsportabilität

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.

Mehr Sicherheit und Zuverlässigkeit für Automotive-Software

In der Automobilwelt zählt jede Codezeile – Leben könnten auf dem Spiel stehen. Fehlererkennung ist kein Luxus, sondern eine Notwendigkeit. TrustInSoft Analyzer weist die Korrektheit des Codes mathematisch nach und integriert sich nahtlos in Autosar.

Interoperabilität und das Automotive-Ökosystem

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.

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.

Geringere Kosten und schnellere Markteinführung

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.

Das Vehicle OS als ein Enabler für das Software Defined Vehicle

Was bedeutet eigentlich Software-defined Vehicle, SDV, und welche Rolle spielt das Vehicle OS genannte Betriebssystem? Welche Rolle spielt die Middleware? Warum ist gerade jetzt der richtige Zeitpunkt für eine Vereinheitlichung dieser Software?

COVESA VSS: Definition des SDV-Datenmodells

Ein gemeinsamer und klar definierter Satz von Datentypen ist für ein datenzentriertes System ist 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.

Fazit

Der Wandel hin zu softwaredefinierten Fahrzeugen bietet OEMs einige Vorteile (u.a. beispiellose Flexibilität, verbesserte Nutzungserfahrung), aber die anfänglichen Versprechungen haben sich nicht erfüllt. Grund dafür ist die Komplexität der Datenintegration zwischen allen Subsystemen. Durch die datenzentrierte Architektur, die DDS ermöglicht, können Automobilhersteller die Markteinführungszeit verkürzen und gleichzeitig die Systemsicherheit, Flexibilität und Skalierbarkeit gewährleisten. COVESA stellt Automobilherstellern interoperable Datentypen zur Verfügung, die durch getesteten, einsatzbereiten Quellcode unterstützt werden. (na)

https://content.rti.com/the-data-backbone-of-sdv-interoperability