Vor 15 Jahren wurden die Grundlagen für die Scalable service-Oriented MiddlewarE over IP (SOME/IP) geschaffen. Heute setzen viele Autohersteller auf SOME/IP, um Kontrolldaten zuverlässig über Automotive Ethernet zu übertragen. Das Ergebnis: Mehrere zehn Millionen Fahrzeuge weltweit nutzen SOME/IP.
Als Automotive Ethernet eingeführt wurde, war schnell klar, dass man nicht nur die klassischen Kommunikationsparadigmen – wie auf CAN – verfolgen wollte. Fahrzeughersteller und Zulieferer suchten intensiv nach einer modernen Kommunikationslösung, die sowohl die CAN- als auch die MOST-Kommunikation ablösen konnte (siehe auch BMBF-Projekt SEIS). Die Kommunikation sollte nicht länger signal-, sondern dienstorientiert erfolgen, um so mit den Komplexitätszuwächsen besser umgehen zu können. Für die effiziente, skalierbare Nutzung von Ethernet wurden nicht nur Publish/Subscribe-Fähigkeiten benötigt, sondern man wünschte sich auch die Fähigkeit, Dienste im Fahrzeugnetz zu verschieben. Diese Flexibilität erforderte eine Service Discovery. Wie für jede Automobiltechnologie ist eine schnelle Startfähigkeit essenziell. Für Teilnetzfähigkeit und Robustheit musste die Lösung darüber hinaus vollständig verteilt und ohne zentrale Rollen funktionieren.
Bei einem solchen Anforderungskatalog war schnell klar, dass existierende Kommunikationslösungen, wie zum Beispiel MQTT, DDS, Google Protocol Buffers, REST, CORBA, Apache Etch und Bonjour die Anforderungen nur teilweise erfüllen. Betrachtet man nun zudem die wichtigste Softwareplattform zu dieser Zeit (AUTOSAR) und deren Lizenzbedingungen, war offensichtlich, dass nur eine neue Lösung das Problem hinreichend lösen konnte.
SOME/IP wurde als Lösung für die moderne Kontrollkommunikation im Fahrzeug entwickelt und bereits 2011 die erste Version von SOME/IP öffentlich vorgestellt und diskutiert. Weitere Verfeinerung folgte im Jahr 2012, so dass SOME/IP in ISO, GENIVI/COVESA und AUTOSAR eingebracht werden konnte, was zu veröffentlichten Standards in den Jahren 2013 und 2014 führte. Bis zum Jahr 2016 wurden noch einige Funktionen hinzugefügt, die ebenfalls in die Standardisierung überführt wurden. Die letzte große Funktionserweiterung hierbei war SOME/IP-TP, ein Minimal-Transportprotokoll für große Nachrichten auf UDP.
Seit 2016 ist der SOME/IP-Funktionsumfang damit im Wesentlichen stabil und wird durch immer mehr Fahrzeughersteller genutzt. Vor allem die in AUTOSAR veröffentlichten SOME/IP-Standards haben zu einer sehr weiten Verbreitung geführt.
SOME/IP ist eine für Fahrzeuge maßgeschneiderte Kommunikationslösung für Automotive Ethernet. Bild 1 stellt SOME/IP im Kontext der Fahrzeugkommunikation dar: SOME/IP überspannt als Middleware die Automotive-Ethernet-Kommunikation im Fahrzeug, für welche Protokolle des TCP/IP-Stacks genutzt werden. Hiermit bietet SOME/IP den Anwendungen Schnittstellen (Service Interfaces) an, die die Aspekte der unterliegenden Kommunikation geschickt abstrahieren, um den Aufwand für die Anwendungsentwickler zu minimieren.
SOME/IP zeichnet sich durch folgende Merkmale aus:
Der große Funktionsumfang von SOME/IP erlaubt es problemlos, die komplette Kontrollkommunikation im modernen Fahrzeug abzuwickeln und begründet den Erfolg von SOME/IP.
SOME/IP passt hervorragend zu dem Entwicklungsmodell der letzten Jahre, das das durch klar definierte Zuständigkeiten zwischen Fahrzeugherstellern und Zulieferern gekennzeichnet ist: Die Fahrzeughersteller kümmern sich in erster Linie um die Spezifikationen, indem sie Anforderungen und Konfigurationen bereitstellen, während die Zulieferer die Software auf der Grundlage von Standards wie AUTOSAR implementieren.
Derzeit stellen drei Trends das etablierte Entwicklungsmodell und damit auch die Ausprägung des aktuellen SOME/IP-Ökosystems in Frage:
Die steigende Entwicklungsgeschwindigkeit erfordert in erster Linie eine Optimierung der Entwicklungsprozesse. Betrachtet man exemplarisch die Prozesskette, die zur Definition und Konfiguration eines SOME/IP-Services führt, so sind insbesondere Verbesserungen oder Alternativen zum etablierten Prozess erforderlich.
Das resultierende AUTOSAR-Konfigurationsformat ARXML kann heute als De-Facto-Standard gesehen werden, das vom Fahrzeughersteller bereitgestellt werden muss. Das ARXML-Format ist allerdings nicht problemfrei: einerseits ist es für Fahrzeughersteller äußerst schwierig, schnell genug diese umfangreichen ARXML-Dateien in ausreichender Qualität zu erzeugen, andererseits können die Zulieferer nicht automatisiert Änderungen in der ARXML-Konfiguration in die Software übernehmen. Diese strukturellen Probleme betreffen vor allem AUTOSAR und das ARXML-Format. Da allerdings SOME/IP oft mittels ARXML konfiguriert werden soll, sind hierbei auch SOME/IP-Implementierungen betroffen.
Die Unterstützung von Open Source hingegen ist ein Trend, der als Gegenbewegung zu AUTOSAR gesehen werden kann, da die AUTOSAR-Lizenzen nicht kompatibel zu Open Source sind. Auch wenn bereits seit einigen Jahren nach einer Lösung hierfür gesucht wird, ist diese noch nicht absehbar. Für SOME/IP wird dies nun zu einem Problem, da die neuesten SOME/IP-Spezifikationen vor allem durch AUTOSAR veröffentlicht werden. ISO hat bislang keine vollständige SOME/IP-Spezifikation veröffentlicht. COVESA hat mit vsomeip zumindest einen SOME/IP-Stack als Open-Source veröffentlicht, aber keine Spezifikation für SOME/IP.
Für den Einsatz von SOME/IP in kommerziellen Fahrzeugen stellt sich vor allem die Verfügbarkeit akzeptabler Standards als Problem dar. Während in Autos die Kommunikation auf das Fahrzeug begrenzt ist, wird bei kommerziellen Fahrzeugen mit Anhängern oder anderen Anbauteilen kommuniziert. Ein belastbarer Standard ist daher essenziell.
Diese Standards werden in der Regel von der ISO herausgegeben. Die fehlende vollständige SOME/IP-Spezifikation der ISO oder einer kompatiblen Standardisierungsorganisation stellt hierbei das größte Hindernis dar.
Bild 2 fasst die aktuellen Trends und deren Auswirkungen zusammen.
Was muss geschehen, um den Erfolg von SOME/IP weiterhin zu gewährleisten? Für die bessere Unterstützung von Open Source und den Einsatz in kommerziellen Fahrzeugen ist es notwendig, dass eine offene SOME/IP-Spezifikation existiert, die frei verwendet werden kann. Für kommerzielle Fahrzeuge könnte eine solche offene SOME/IP-Spezifikation als ISO-Standard veröffentlicht werden.
Es ist allerdings von zentraler Bedeutung, dass die Kompatibilität verschiedener SOME/IP-Implementierungen weiterhin erreicht wird, auch wenn diese auf Basis unterschiedlicher Spezifikationen entstanden sind.
Für die Nutzung in Open-Source-Projekten ist es zudem sinnvoll, dass eine solche Spezifikation bereits modernere Formate und Prozesse unterstützt. Ein aktueller Trend ist die Behandlung von Anforderungen und Spezifikationen nach dem »as-code«-Prinzip. Durch die gemeinsame Nutzung von Quellcodewerkzeugen wie Git und automatisierten CI/CD-Prozessen wird eine Verknüpfung von Quellcode, Anforderungen und Testfällen ohne Medienbruch ermöglicht. Hierdurch können Anforderungen, Quellcode sowie Testfälle parallel bearbeitet werden und gleichzeitig zeitnah Auswirkungen auf andere Artefakte erkannt werden – ein erheblicher Vorteil für die Geschwindigkeit der oft sehr formale Fahrzeugentwicklung. Ein Beispiel für diesen Ansatz ist Sphinx-Needs, eine Lösung für die modellbasierte Dokumentation und Verknüpfung technischer Artefakte.
Aktuell arbeitet ein Team an einer offenen SOME/IP-Spezifikation im Sphinx-Needs-Format, um die genannten Ziele und Vorteile zu erreichen. Diese Spezifikation soll zeitnah bereitgestellt werden, um Open-Source-Projekte wie z.B. Eclipse S-CORE und Eclipse OpenBSW zu unterstützen und eine Grundlage für die ISO-Standardisierung darzustellen.
Die Erstveröffentlichung der offenen SOME/IP-Spezifikation ist für Ende 2025 vorgesehen und wird auf https://some-ip.com bekanntgegeben. Diese Veröffentlichung umfasst die SOME/IP-Kernumfänge, die bereits seit 2016 bekannt sind, sowie Verbesserungen und Verfeinerungen.
Da aus Lizenzgründen nicht einfach alle Umfänge aus AUTOSAR übernommen werden können, werden einige »AUTOSAR-Erweiterungen« nicht Teil dieser ersten offenen SOME/IP-Spezifikation sein. Damit sie in die offene SOME/IP-Spezifikation einfließen können, müssen sie durch ihre ursprünglichen Autoren und damit Rechteinhaber bereitgestellt werden. Die bekannteste dieser Erweiterungen ist die TLV-Serialisierung, die jedoch heute nur durch einen großen Fahrzeughersteller genutzt wird. Andere Erweiterungen werden noch weniger genutzt, sind also für die Allgemeinheit nicht entscheidend.
Für 2026 wird bereits an einer Security-Spezifikation für SOME/IP gearbeitet. In dieser werden verschiedene Integrationen von Security-Lösungen mit SOME/IP erstmalig umfassend dokumentiert. Zudem werden auch weitere Security-Features wie ein SOME/IP-basierter Schlüsselaustausch enthalten sein.
Ein weiterer wichtiger Aspekt ist die Entwicklung einer freien und offenen Konfigurationssprache für SOME/IP und damit verbundenen Umfängen. Auch hierfür wurde ein »as-code-Ansatz« gewählt. Die Konfiguration kann also wie Quellcode behandelt werden. Eine erste Veröffentlichung dieser Lösung – FLYNC genannt – ist für Anfang 2026 geplant, um Entwicklern einer offenen SOME/IP-Lösung auch ein Angebot für eine offene, moderne Konfigurationssprache machen zu können. Weitere Protokolle und Umfänge befinden sich bereits in der Diskussion.