SommR kommt

Im ersten Teil dieser (sehr kurzen) Serie haben wir uns mit der Semantik und Syntax der Kommunikation befasst und was diese beiden Aspekte im Zusammenhang mit softwaredefinierten Fahrzeugen (SDVs) bedeuten können. Wir haben einen ersten Blick auf die Herausforderungen geworfen, die mit der Entwicklung tatsächlicher Produkte in einer Welt verbunden sind, in der die Landschaft potenzieller Lösungsoptionen riesig ist und weiter wächst, gepaart mit einer ebenso großen Vielfalt an Ingenieurskulturen innerhalb des Fahrzeugproduktbereichs. Abschließend haben wir uns das Eclipse-uProtocol-Projekt angesehen und wie es in diesem Zusammenhang einen Mehrwert schaffen will.

Nun werden wir uns etwas ausführlicher mit den Erfolgsfaktoren für die Vision von uProtocol befassen. Wir werden eine Möglichkeit etwas genauer untersuchen und einen Ausblick darauf geben, was in diesem Jahr passieren könnte, wenn einige Faktoren wie erwartet zusammenkommen.

uProtocol allein ist keine umfassende Lösung für alle Kommunikationsprobleme in der Fahrzeugwelt. Vielmehr könnte man es als „Meta-Middleware“ bezeichnen, die als Bindeglied und gemeinsame Grundlage dient, um die Kommunikation zwischen den verschiedenen Diensten zu ermöglichen, die in modernen Fahrzeug-Cloud-App-Szenarien mit unterschiedlichen Technologien zum Einsatz kommen.

Damit eine Software-Infrastruktur wie diese wirklich erfolgreich sein kann, müssen viele Faktoren zusammenkommen. Wie wir im ersten Artikel angedeutet haben, sind die meisten davon nicht technischer Natur. Lassen Sie uns einige Erfolgsfaktoren definieren, die als Hintergrund für den weiteren Verlauf dieser Diskussion dienen sollen.

Technologischer Erfolg ist die Achse, auf der etwas ein bestimmtes technologisches Problem löst und dies so gut tut, dass es als zweckmäßig angesehen werden kann, gemessen an den technischen KPIs, die in einem bestimmten Szenario relevant sind.

Der Erfolg der Reife hängt davon ab, dass „nicht-technische” Anforderungen erfüllt werden, die über den reinen Code hinausgehen: Ist es das Ziel und die Denkweise der Entwicklergemeinschaft, produktionsreife Software zu erstellen und zu warten? Führt dies zur Erstellung und Weiterentwicklung von Nicht-Code-Artefakten, die sich auf die Einhaltung von Qualitätsprozesskennzahlen beziehen und dazu beitragen?

Der Erfolg einer Übernahme ist im Wesentlichen der Mehrwertmultiplikator eines Projekts, wobei die Frage lautet: „Wird dieser Code von mehr als einer Organisation produktiv genutzt?“ Dieses Merkmal hat tatsächlich einen zweiten, eher impliziten Effekt, der dennoch sehr wünschenswert ist: Jeder aktive Nutzer und Mitwirkende einer Codebasis weiß per Definition, „wie die Dinge funktionieren“, sie sprechen dieselbe Sprache. Dies ist ein großer Vorteil für jede kommerzielle Zusammenarbeit, da die beteiligten Parteien die konzeptionelle und technische Abstimmung überspringen und direkt zum wertschöpfenden Teil ihrer Arbeit übergehen können.

Ein erfolgreiches Ökosystem entsteht , wenn alle oben genannten Faktoren zusammenkommen und die Kerntechnologie Erweiterbarkeit ermöglicht und Beiträge aller Art fördert. Ein erfolgreiches Ökosystem ermöglicht es den Teilnehmern, den Erfolg der Kernelemente für ihre eigenen Erweiterungen und Beiträge zu nutzen – sowohl für offene als auch für kommerzielle Modelle. Ökosysteme können unglaublich erfolgreiche Toolboxen zur Lösung spezifischer Problembereiche schaffen – als äußerst erfolgreiches Beispiel sei hier das Ökosystem der Cloud Native Compute Foundation genannt, das sich um die Kernkonzepte (und die Implementierung) von Kubernetes (k8s) herum entwickelt hat.

Ich wäre zwar (freudig) überrascht, wenn uProtocol auf den Umfang von k8s anwachsen würde, aber wir können uns dennoch die oben genannten Erfolgsschritte für dieses kleinere Projekt vorstellen und Ideen diskutieren, die uns auf diesem Weg helfen könnten.

Damit uProtocol als Automotive Service Mesh nützlich ist, muss es eine Verbindung zu Automobilprotokollen herstellen, d. h. zu den Kommunikationsnetzwerken der Mechatronik-Domänen im Fahrzeug. Hier wird es in der Regel kompliziert, aus Gründen, die einen eigenen Artikel füllen würden. In diesem Text werden wir daher ein Szenario beschreiben, das auf konzeptioneller und Ökosystemebene nützlich ist, auch wenn eine tatsächliche Implementierung zum Zeitpunkt der^Erstellung dieses Artikels nicht öffentlich verfügbar gemacht werden kann1.

In Übereinstimmung mit dem oben dargelegten Thema wäre ein guter erster Schritt von uProtocol in den Bereich der eingebetteten Automobiltechnik die Verbindung von Pub/Sub-Netzwerken an beiden Enden des Spektrums. Auf der Automobilseite ist ein relevantes Kandidatenprotokoll AUTOSAR® SOME/IP, eine Spezifikation für die Pub/Sub-Kommunikation auf Basis der Automobilnetzwerkinfrastruktur. Durch die Erstellung einer SOME/IP-uPClient-Implementierung können wir SOME/IP-Netzwerksegmente zu einem Teil des größeren uProtocol-Service-Mesh machen. Dies würde den oben beschriebenen Anwendungsfall ermöglichen, bei dem ein Geschwindigkeitsdatagramm von einer Entität innerhalb eines fahrzeuginternen SOME/IP-Netzwerks ² veröffentlicht und dann über uProtocol-Mechanismen an andere Segmente der Netzwerk-/Protokollinfrastruktur weitergeleitet wird.

Die größte Herausforderung bei diesem Konzept ist wiederum nicht technischer Natur: SOME/IP ist eine AUTOSAR®-Spezifikation, was bedeutet, dass Open-Source-Implementierungen der aktuellen Spezifikationsversion gemäß der AUTOSAR-IP-Lizenz ³ verboten sind und daher keine Implementierung einer uProtocol-SOME/IP-Verbindung in einem Open-Source-Projekt möglich ist.

Derzeit warten wir in der Eclipse SDV-Arbeitsgruppe auf SommR. SommR ist eine von Grund auf neu entwickelte Implementierung von SOME/IP in Rust, die sich perfekt für den Aufbau einer uProtocol-Brücke eignen würde. Seit der Projektankündigung Mitte 2022 arbeitet der Projektmitwirkende daran, die AUTOSAR®-IP-Richtlinien zu klären. Dies ist zwar noch nicht abgeschlossen, aber die Chancen für ein positives Ergebnis innerhalb dieses Jahres stehen gut.

Sobald SommR verfügbar ist, wird es einen uPClient geben, der eine Verbindung dazu herstellt und somit die Integration von SOME/IP in uProtocol-Service-Meshes ermöglicht. Damit können wir das oben beschriebene Szenario für Begleit-Apps sowie ähnliche Konfigurationen mit SOME/IP-Steuergeräten realisieren. Wir hoffen, damit eine erste Brücke zwischen der Open-Source-Welt und der traditionellen Automobilwelt schlagen zu können.

Eine weitere interessante Tatsache in diesem Zusammenhang: Sowohl das SommR- als auch das uProtocol-Projekt zielen darauf ab, produktionsreifen Code für den Einsatz in Automobilprodukten bereitzustellen und zu pflegen. Details und Umfang sind noch in der Entwicklung, aber es ist davon auszugehen, dass Themen wie Prozessdefinition (über den Eclipse Foundation Development Process), Projektanforderungsspezifikation, Dokumentation, Testabdeckung und zugehörige KPIs usw. umfassend behandelt werden. Diese Projekte werden wahrscheinlich zu den ersten Anwendern des (ebenfalls noch in der Entwicklung befindlichen) Eclipse SDV-Qualitäts-/Reifegradprogramms gehören, das die Grundlagen für den Einsatz dieser Software in kommerziellen Automobil-Produktentwicklungsprozessen schaffen soll.

Zusammenfassend lässt sich sagen, dass Eclipse uProtocol und das bevorstehende Eclipse SommR-Projekt ein Beispiel dafür sein können, wie Open Source ein wichtiger Faktor für den Aufbau einer Software-Infrastruktur für die Automobilindustrie sein kann. Dieses Beispiel umfasst:

Nahtlose Integration bewährter Automobiltechnologie mit IT-ähnlichen Netzwerkstacks, um ein größeres Ganzes zu schaffen.

Praktisches Beispiel dafür, wie offene Entwicklungsmodelle und Open-Source-Foundations eine erstklassige Zusammenarbeit mit geringem Aufwand zwischen Partnern in der Automobil-Wertschöpfungskette ermöglichen können.

ein Inkubator und Testfeld dafür, wie OSS-Projekte Softwarequalität auf Automobilniveau bieten können, und damit vielleicht sogar eine Vorstellung davon, was das eigentlich bedeutet...

Wenn irgendetwas von dem, was hier erwähnt wurde, für Sie relevant klingt, würden wir uns freuen, Sie im Eclipse SDV Slack Space, bei unseren uProtocol-Projekttreffen, in der Mailingliste oder bei einer unserer Community-Veranstaltungen begrüßen zu dürfen (weitere Informationen dazu finden Sie auf dieser Eclipse SDV-Infoseite).

¹: Siehe jedoch den letzten Abschnitt des Artikels.

^2: Nein, ein uProtocol-Netzwerk würde keine dedizierte Lösung ersetzen, die für Echtzeitkommunikation mit hohem Durchsatz und geringster Latenz optimiert ist. Ja, es gibt immer noch viele Anwendungsszenarien, die für Kunden relevant sind und von ihnen erwartet werden (tatsächlich sind diese für Kunden in der Regel viel sichtbarer). Nein, uProtocol als Ganzes ist wahrscheinlich kein nützliches Objekt für die Diskussion über die Sicherheitszertifizierung von Kraftfahrzeugen – obwohl Teilkomponenten und dedizierte Adapter sehr wohl geeignet sein könnten.

³: Wir kennen das vsomeip-Projekt. Angesichts der anhaltenden Kontroverse über jede offene Implementierung bestehender AUTOSAR®-Spezifikationen sind wir uns jedoch nicht ganz sicher, wie wir dazu stehen sollen.