SOME/IP und DDS im Auto: wie Dienste statt Signale die Fahrzeugelektronik steuern

Warum der klassische CAN-Bus an seine Grenzen stößt

In einem klassischen Auto ist jede Nachricht auf dem CAN-Bus fest definiert. Das passiert lange bevor das Fahrzeug vom Band läuft. Ingenieure legen in einer Kommunikationsmatrix fest, welches Steuergerät welche Kennung sendet. Sie legen auch fest, wie oft die Nachricht wiederholt wird und welche anderen Steuergeräte sie mitlesen. Diese Matrix ist der Bauplan des gesamten Bordnetzes. Sie wird beim Entwurf des Fahrzeugs eingefroren, nicht zur Laufzeit verändert. Für sicherheitsrelevante Funktionen wie Lenkwinkel, Raddrehzahl oder Bremsdruck ist genau das ein Vorteil, weil sich die Übertragungszeit jeder Nachricht vorab berechnen lässt und ein Steuergerät exakt weiß, was es wann empfängt.

Dieses starre Prinzip wird zum Problem, sobald sich die Software eines Fahrzeugs nach der Produktion noch ändern soll. Ein zusätzliches Steuergerät, eine verschobene Funktion oder ein nachgerüstetes Feature verlangt in einem signalbasierten Netz fast immer eine Anpassung der gesamten Matrix. Neue Kennungen, neue Empfängerlisten, neu berechnete Buslast – nichts davon lässt sich isoliert ändern. Genau das widerspricht dem Grundgedanken eines Software-defined Vehicle, in dem Funktionen über Jahre hinweg wandern, wachsen oder neu entstehen sollen, ohne dass jedes Mal die komplette Fahrzeugelektronik neu verdrahtet wird. Wer ein Auto so baut, dass es sich nach der Auslieferung weiterentwickelt, braucht ein Kommunikationsmodell, das nicht bei jeder Änderung neu gegossen werden muss.

Was „serviceorientiert“ in der Fahrzeugelektronik bedeutet

Der Unterschied zwischen einem Signal und einem Dienst klingt zunächst abstrakt. In der Praxis ist er aber entscheidend. Ein Signal ist ein roher Wert, der auf den Bus gelegt wird. Die sendende Komponente weiß dabei nicht, wer ihn gerade braucht. Ein Dienst dagegen hat eine Identität. Er bietet klar benannte Funktionen an, meldet, ob er gerade verfügbar ist, und lässt sich von jedem passenden Abnehmer gezielt ansprechen. Diese Verschiebung – weg vom bloßen Werteaustausch, hin zu einer angebotenen Fähigkeit mit eigenem Lebenszyklus – ist der Kern dessen, was Ingenieure als serviceorientierte Architektur bezeichnen.

Praktisch bedeutet das: Ein Steuergerät, das eine Funktion benötigt, muss vorher nicht wissen, welches andere Steuergerät sie anbietet. Es muss auch nicht wissen, unter welcher Adresse dieses Gerät erreichbar ist. Es fragt einfach das Netzwerk, wer diesen Dienst gerade bereitstellt, und verbindet sich mit der Antwort. Läuft dieselbe Funktion in einer neuen Fahrzeuggeneration auf einer anderen Recheneinheit, ändert sich für den Abnehmer nichts – solange der Dienst dieselbe Schnittstelle anbietet. Diese Entkopplung von Anbieter und Abnehmer ist genau die Eigenschaft, die eine feste Signalmatrix nicht besitzt, denn dort steht die Zuordnung von Sender und Empfänger von Anfang an fest.

SOME/IP: wie sich Fahrzeugdienste selbst finden

SOME/IP steht für Scalable service-Oriented MiddlewarE over IP. Es ist eine von AUTOSAR standardisierte Middleware für genau diese Art von Kommunikation. Das Protokoll setzt auf UDP oder TCP über Ethernet auf. Es wird sowohl in der klassischen als auch in der adaptiven AUTOSAR-Plattform eingesetzt, wenn auch mit unterschiedlichem Gewicht. In der klassischen Welt bildet es häufig weiterhin signalähnliche Inhalte ab. In der adaptiven Welt ist es eines von mehreren Netzwerkprotokollen, das der plattformeigene Kommunikationsdienst für ein fahrzeugweit einheitliches Serviceverfahren nutzen kann.

Der eigentliche Mechanismus heißt Service Discovery. Ein Steuergerät, das einen Dienst bereitstellt, meldet ihn über eine Dienst- und eine Instanzkennung im Netzwerk an. Das läuft meist per Mehrfachadressierung, damit nicht jeder mögliche Abnehmer einzeln angefragt werden muss. Ein Steuergerät, das diesen Dienst sucht, kann entweder auf diese Ankündigung warten oder selbst aktiv danach fragen. Erst nach diesem Fund wird die eigentliche Nutzverbindung aufgebaut. Dieses Verfahren macht registrierte Dienste zur Laufzeit auffindbar, ohne dass beim Systementwurf feststehen muss, welches physische Steuergerät später tatsächlich antwortet. Genau darin liegt der Unterschied zu einer Kennung, die auf dem CAN-Bus fest einem einzigen Sender zugeordnet ist.

Methods, Events und Fields: die Bausteine eines Diensts

Ein SOME/IP-Dienst setzt sich aus drei Elementtypen zusammen: Methods, Events und Fields. Eine Method funktioniert wie ein klassischer Funktionsaufruf. Ein Steuergerät stellt eine Anfrage, wartet auf eine Antwort und bekommt ein konkretes Ergebnis zurück, etwa den aktuellen Status einer Komponente. Ein Event dagegen ist eine einseitige Mitteilung. Der anbietende Dienst schickt eine Nachricht an alle Interessierten, entweder in festen Abständen oder immer dann, wenn sich ein Wert ändert, ohne dass der Empfänger aktiv nachfragen muss.

Ein Field kombiniert beide Prinzipien für einen einzelnen Wert. Es lässt sich lesen, unter bestimmten Bedingungen auch schreiben. Jede Änderung löst dabei automatisch eine Benachrichtigung an alle Abonnenten aus. Diese drei Bausteine decken zusammen fast jede Situation ab, die in einem Fahrzeug vorkommt, von der einmaligen Statusabfrage über den laufend aktualisierten Sensorwert bis zur Einstellung, die mehrere Systeme gleichzeitig beobachten sollen. Welche der drei Formen für eine Funktion gewählt wird, entscheidet der Entwickler des Diensts, nicht das Netzwerk selbst.

DDS: Daten verteilen, ohne einen festen Empfänger zu kennen

DDS, ausgeschrieben Data Distribution Service, verfolgt einen anderen Grundgedanken als SOME/IP. Der Standard wird seit 2004 von der Object Management Group gepflegt. Er ist datenzentriert statt dienstzentriert aufgebaut. Eine Anwendung veröffentlicht Werte unter einem benannten Thema. Jede andere Anwendung, die dieses Thema abonniert hat, erhält die Werte automatisch – ohne dass Sender und Empfänger sich gegenseitig kennen müssen und ohne eine zentrale Vermittlungsstelle, über die jede Nachricht laufen muss.

Die eigentliche Stärke von DDS liegt in der feinen Einstellbarkeit dieser Verteilung. Für jedes Thema lässt sich separat festlegen, ob wirklich jeder einzelne Wert ankommen muss. Ebenso einstellbar ist, wie viele zurückliegende Werte ein neu hinzukommender Abonnent nachgeliefert bekommt und innerhalb welcher Frist eine Aktualisierung spätestens erfolgen muss. Diese Kontrolle über Zuverlässigkeit, Historie und Fristen macht DDS zur bevorzugten Wahl dort, wo große, kontinuierliche Datenströme verteilt werden müssen. Ein Beispiel sind Objektlisten aus Kamera- und Radarsensorik in Fahrerassistenzsystemen, wo ein einzelner verlorener Messwert anders zu bewerten ist als eine verlorene Statusmeldung. Nicht zufällig ist DDS auch die Standard-Middleware von ROS 2, aus dessen Robotik-Umfeld viele Konzepte in die Fahrzeugentwicklung eingeflossen sind.

SOME/IP und DDS im Vergleich

Beide Protokolle ersetzen die feste Verdrahtung durch eine Form der Laufzeit-Entdeckung. Sie setzen dabei aber unterschiedliche Schwerpunkte. SOME/IP denkt in klar abgegrenzten Diensten mit Funktionsaufrufen, Ereignissen und Werten und stammt aus der AUTOSAR-Welt, in der ein Steuergerät eine bestimmte, genau umrissene Funktionalität anbietet. Das passt gut zu Komfort-, Karosserie- und zunehmend auch zu Gateway-Funktionen zwischen klassischer und adaptiver Plattform. DDS denkt in fortlaufenden Datenflüssen mit einstellbarer Übertragungsqualität. Es ist dort zu Hause, wo hohe Datenraten mit feiner Kontrolle über Zuverlässigkeit verteilt werden müssen, etwa in Hochleistungsrechnern für Fahrerassistenz und automatisiertes Fahren.

In der Praxis schließen sich beide Protokolle nicht aus. Die Kommunikationsverwaltung der AUTOSAR Adaptive Platform unterstützt SOME/IP, DDS und weitere Bindungen gleichzeitig als austauschbare Netzwerkanbindung unter derselben Anwendungsschnittstelle. Ein Softwaremodul kann also grundsätzlich denselben Dienst anbieten. Der Anwendungscode muss dabei nicht wissen, welches der beiden Protokolle die Daten am Ende tatsächlich transportiert. In vielen aktuellen E/E-Architekturen laufen deshalb beide Protokolle nebeneinander auf demselben physischen Ethernet-Rückgrat – jedes für die Domäne, für die es besser passt, statt in Konkurrenz zueinander zu stehen.

Warum das Software-defined Vehicle diese Flexibilität braucht

Moderne Fahrzeugarchitekturen bündeln Steuergeräte zunehmend in Zonen, statt sie über das ganze Fahrzeug zu verteilen. Diese Zonen übernehmen gleichzeitig Aufgaben der Datenverteilung und der Energieversorgung. Ein aktuelles Beispiel aus dem Jahr 2026 ist das Referenzsystem CoreRide Z248 von NXP. Es führt eine 48-Volt-Leistungsverteilung mit Netzwerkanbindung und Diagnosefunktion in einer vorvalidierten Zonensteuerung zusammen. Solche Systeme zeigen, warum Kommunikation und Energieverteilung in einem Software-defined Vehicle nicht getrennt betrachtet werden können. Fällt die Versorgung einer Zone aus, verschwinden mit ihr häufig mehrere scheinbar unabhängige Funktionen gleichzeitig, weil sie über denselben Zonencontroller laufen.

Für eine solche Architektur ist die serviceorientierte Kommunikation keine Spielerei, sondern eine Voraussetzung. Wandert eine Funktion in einer neuen Modellgeneration von einer zentralen Recheneinheit in einen Zonencontroller oder umgekehrt, ändert sich an der festen Signalmatrix eines klassischen Bordnetzes praktisch das gesamte Fahrzeug. Bei einem entdeckbaren Dienst dagegen bleibt die Schnittstelle gleich. Nur die Antwort kommt von einer anderen physischen Stelle, für den Abnehmer unsichtbar. Genau diese Beweglichkeit brauchen Hersteller, wenn Funktionen über Softwareupdates aktiviert, zwischen Hardwaregenerationen verschoben oder erst nach der Produktion freigeschaltet werden sollen.

Ethernet, CAN XL und die Übergangszeit im Bordnetz

SOME/IP wie DDS setzen normalerweise auf IP-Kommunikation über Ethernet auf. Ihre Verbreitung hängt deshalb eng damit zusammen, wie viel Automotive Ethernet tatsächlich im Fahrzeug verbaut ist. Nicht jedes Steuergerät bekommt aber schon in der aktuellen Fahrzeuggeneration einen eigenen Ethernet-Anschluss. Genau hier wird CAN XL relevant, die jüngste Weiterentwicklung der CAN-Busfamilie. Die AUTOSAR Adaptive Platform erlaubt CAN XL ausdrücklich als physikalische Schicht. Sie unterstützt dann aber ausschließlich das gemappte Tunneling von Ethernet-Rahmen durch das physische CAN-XL-Netz.

Für die Praxis bedeutet das: Ein Steuergerät, das nur an einem CAN-XL-Segment hängt, kann trotzdem an derselben serviceorientierten Kommunikation teilnehmen wie ein Gerät mit echtem Ethernet-Anschluss. Seine Ethernet-Rahmen werden einfach durch den CAN-XL-Kanal hindurchgereicht. Das erklärt, warum Hersteller ihre Fahrzeuge nicht in einem Schritt komplett neu verkabeln müssen, um von signalbasierter auf serviceorientierte Kommunikation umzustellen. Stattdessen wächst das Ethernet-Rückgrat schrittweise. Günstigere oder ältere Bus-Segmente bleiben über das Tunneling weiterhin eingebunden, bis eine spätere Fahrzeuggeneration sie ersetzt.

Wie Hersteller die Zusammenarbeit der Steuergeräte absichern

Eine serviceorientierte Architektur funktioniert nur, wenn sich jedes beteiligte Steuergerät exakt an dieselben Regeln für Ankündigung, Suche und Abonnement hält. Ein Anbieter, der sich nur ungefähr an die Spezifikation hält, kann die Dienstfindung im gesamten Fahrzeug stören. Dasselbe gilt für einen Abnehmer, der zu früh aufgibt – obwohl jedes einzelne Gerät für sich funktioniert. Genau deshalb existiert eine eigene Norm für Konformitätstests auf Anwendungs- und Sitzungsschicht des Fahrzeug-Ethernets. Sie legt Testfälle speziell für SOME/IP und für DHCPv4 fest und dient Herstellern als gemeinsamer Maßstab für die Qualitätssicherung.

Ergänzend pflegt AUTOSAR die SOME/IP-Protokollspezifikation selbst fortlaufend weiter. Dasselbe gilt für die Spezifikation der Adaptive Platform, deren jüngste Fassung Ende November 2025 veröffentlicht wurde. Diese Kombination aus Protokollspezifikation und unabhängigem Konformitätstest ist der Grund, warum ein Fahrzeughersteller die Dienstfindung nicht einfach dem jeweiligen Zulieferer überlassen kann. Ohne einen gemeinsamen, extern prüfbaren Maßstab müsste jede Kombination aus Steuergeräten unterschiedlicher Zulieferer im Fahrzeug einzeln neu erprobt werden, bevor sie zuverlässig zusammenarbeitet.

Was das für Diagnose und Nachrüstung bedeutet

Bei klassischer CAN-Kommunikation ist eine fehlende Nachricht mit einem Busanalysator vergleichsweise einfach zu erkennen. Die Kennung ist entweder auf dem Bus vorhanden oder nicht. Bei serviceorientierter Kommunikation kann dieselbe Beobachtung, eine ausbleibende Antwort, mehrere ganz unterschiedliche Ursachen haben, die auf verschiedenen Ebenen liegen. Ein Dienst wird in diesem Moment vielleicht schlicht noch nicht angeboten. Das anbietende Steuergerät läuft zwar, ist für diesen bestimmten Abnehmer aber gerade nicht autorisiert. Oder die reine Netzwerkverbindung ist in Ordnung, während der Dienst auf Anwendungsebene trotzdem nicht verfügbar ist.

Für eine saubere Diagnose bedeutet das, den Dienstzustand zusätzlich zur reinen Netzwerkerreichbarkeit mitzuschreiben, statt aus dem einen automatisch auf das andere zu schließen. Wo genau eine solche Kommunikation im Einzelfall tatsächlich abbricht, ist eine eigene, systematische Fehlersuche mit eigenen Werkzeugen und gehört nicht in diesen Beitrag. Wichtig ist hier nur die Grundannahme: Eine ausbleibende Antwort ist bei serviceorientierter Kommunikation nicht automatisch ein Kabel- oder Hardwarefehler. Auch bei der Nachrüstung gilt dieses Prinzip. Ein zusätzliches Gerät, das selbst Dienste anbietet oder bestehende abonniert, wird Teil desselben Entdeckungsmechanismus wie jedes werkseitig verbaute Steuergerät – mit eigener Anmeldezeit, eigenem Autorisierungsbedarf und zusätzlicher Netzlast, selbst wenn es technisch einwandfrei arbeitet.

Was ein Eingriff in diese Kommunikationsebene für die Zulassung bedeutet

Ein Nachrüstgerät kann sich in die serviceorientierte Kommunikation eines Fahrzeugs einklinken, etwa als zusätzliches Steuergerät, das eigene Dienste anmeldet oder bestehende abonniert. Das verändert unter Umständen die genehmigte Fahrzeugart oder das Sicherheitsverhalten, selbst wenn dafür keine einzige mechanische Schraube gelöst wird. Genau das unterscheidet moderne Fahrzeugelektronik von einem einfachen Zubehörteil: Die Änderung sitzt in der Software- und Kommunikationsschicht, ist von außen kaum sichtbar und trotzdem rechtlich relevant.

Umbauten am eigenen Fahrzeug. Ob ein Umbau auf öffentlichen Straßen betrieben werden darf, entscheidet der Genehmigungszustand des Fahrzeugs — die Genehmigung des Teils, der Einbau nach ihren Auflagen und, wo nötig, die Abnahme durch eine dafür zuständige Stelle. Solange diese Kette nicht vollständig ist, gehört der Umbau auf Privatgelände, Testflächen und in nicht öffentliche Bereiche.

Eine Herstellerfreigabe für ein Nachrüstgerät unterscheidet sich klar von einer eigenmächtigen Erweiterung. Im ersten Fall ist das Gerät über ein genehmigtes Diagnose- oder Gateway-Interface angebunden. Im zweiten Fall meldet es sich ungeprüft als zusätzlicher Dienstanbieter im Netzwerk an. Entscheidend ist, ob für das eingebaute Teil eine Betriebserlaubnis oder eine vergleichbare Genehmigung vorliegt und ob deren Einschränkungen und Einbauanweisungen tatsächlich eingehalten werden. Wird das versäumt, kann selbst ein an sich zulässiges Bauteil die Wirksamkeit der Betriebserlaubnis des ganzen Fahrzeugs kosten.

Häufige Fragen

Einordnung: wo die Regeln und Spezifikationen stehen

Die Fundstellen zu diesem Beitrag stehen hier gebündelt, damit der Lesetext ohne Spezifikationsnummern und Normzitate auskommt. Alle Quellen wurden am 18. September 2026 selbst geprüft, die wörtlichen Zitate aus der AUTOSAR-Spezifikation stammen aus dem selbst gelesenen Volltext desselben Tages.