Eclipse uProtocol

Kommunikation hat zwei wichtige Dimensionen, unabhängig davon, ob es sich um Lebewesen oder technische Systeme handelt: die Botschaft und das Medium. Oder, in einer sehr groben Analogie, Semantik und Syntax.

Die Botschaft/Semantik betrifft das, was kommuniziert wird : Zwei Personen, die sich auf dieselben Wörter und Konzepte einigen, können ein Gespräch führen, unabhängig davon, ob sie Sprache, Text, Gebärdensprache, Morsecode usw. verwenden. Dies ist der Inhalt.

Bei Medium/Semantik geht es darum , wie gewünschte Informationen übertragen werden können : Jede beliebige Folge von Symbolen („Nachrichten“) kann zwischen Kommunikationspartnern übertragen werden, solange sie sich auf den zu verwendenden Mechanismus einigen und damit arbeiten können. Das ist die „Rohrleitung“ ¹.

Im Zusammenhang mit technischen Systemen bestimmt der Umfang der Angleichung von Nachrichten/Semantik in der Regel die Skalierbarkeit einer Ressource: Solange der Inhalt der Nachrichten klar definiert ist, kann die Anzahl der Kommunikationspartner wachsen und sogar Änderungen in der Infrastruktur im Laufe der Zeit berücksichtigen. Die Komponenten eines solchen Systems werden austauschbar und können sich unabhängig voneinander weiterentwickeln. Auf diese Weise lässt sich Stabilität in der Geschäftslogik erreichen und der adressierbare Markt für domänenspezifische Angebote wird vergrößert (auch bekannt als „Ökosystem“).

In Softwaresystemen ist die spezifische Infrastruktur sowohl äußerst kritisch als auch überraschend formbar: Wenn sie nicht funktioniert, läuft nichts, es gibt viel davon, und die Dinge ändern sich ständig und entwickeln sich weiter. Ein Großteil der Zeit in der Softwareproduktentwicklung wird für die Anpassung und Integration verschiedener Infrastrukturen aufgewendet, und es scheint, als würde fast bei jeder Gelegenheit links und rechts neue Middleware auftauchen ².

Während sich der Rest dieses Artikels mit den technischen Aspekten befasst, ist es wichtig, auf die bestehenden offenen Community-Bemühungen zur Standardisierung von Inhalten hinzuweisen: die Projekte COVESA Vehicle Signal Specification (VSS) und Vehicle Service Definition (uService). In Kombination mit der Arbeit der SDV-Arbeitsgruppe der Eclipse Foundation unternehmen diese Gruppen einen ernsthaften Versuch, ein gemeinsam entwickeltes, von der Community getragenes Angebot in diesem Bereich zu etablieren.

Dies gilt auch im Zusammenhang mit Fahrzeugsystemen und softwaredefiniertem Fahrzeug (SDV)-Architekturen, wenn auch mit einigen zusätzlichen Schwierigkeiten. Ein SDV-System umfasst die Kommunikation zwischen sehr unterschiedlichen Parteien: Auf der einen Seite steht der Bereich Mechatronik mit tief in Fahrzeugen eingebetteten Mikrocontrollern, die dafür sorgen, dass das Auto bremst, wenn Sie bremsen. Auf der anderen Seite gibt es benutzerorientierte Cloud-Dienste und mobile Anwendungen, mit denen Fahrzeugfunktionen online gesteuert, Fahrerprofile verwaltet und vieles mehr werden können.

Diese beiden Enden des technologischen Spektrums bringen eine ebenso große Bandbreite an Anforderungen an die verwendete Infrastruktur mit sich und entspringen äußerst unterschiedlichen Bereichen der Ingenieurskultur. Eine Echtzeit-CAN-Kommunikationsleitung mit minimaler Latenz im Fahrzeug unterscheidet sich erheblich von einem Cloud-to-App-Protokollstack, und zwischen diesen beiden Extremen gibt es eine Reihe von Graustufen – jede davon verbunden mit einer bestimmten Entwicklungskultur und entsprechenden Auswirkungen auf die umgebende Organisation.

Kurz gesagt: Die Technik hinter SDVs ist nicht nur auf technologischer Ebene kompliziert.

Alle beteiligten Technologiebereiche haben sich weiterentwickelt und eigene Lösungen entwickelt, um ihren Anforderungen gerecht zu werden. Es gibt eine Reihe von Optionen für physische und Transportprotokolle im Fahrzeug, der IoT-Bereich bringt seinen Anteil an Messaging- und Kommunikationsinfrastruktur mit, und die Cloud hat in den letzten 10 bis 20 Jahren eine Vielzahl von Optionen hervorgebracht ³. Dennoch wird von modernen Fahrzeugen und den sie unterstützenden IT-Systemen erwartet, dass sie daraus einen sinnvollen Nutzen ziehen und darauf aufbauend einen nachhaltigen Kundennutzen schaffen ⁴.

Eine häufige Reaktion auf neue Anforderungen und sich verändernde Technologieakteure ist die Erfindung „einer neuen Sache“, die diese neue Herausforderung löst, vielleicht sogar in Form eines Standards, der alle potenziell relevanten Bedürfnisse aller Beteiligten sorgfältig erfasst und berücksichtigt ⁵. Es gibt Szenarien, in denen dies ein sinnvoller Ansatz ist. Angesichts der zunehmenden Vielfalt an Lösungen löst dies jedoch nicht das Kernproblem, sondern verschärft es sogar noch: Es gibt eine Vielzahl von Technologieoptionen, die zusammenwirken müssen, um etwas zu schaffen, das für die Kunden von Wert ist.

Die SDV-Arbeitsgruppe der Eclipse Foundation hat es sich zur Aufgabe gemacht, relevante Beiträge zum SDV-Ökosystem zu leisten, und daher stehen die bisher aufgeworfenen Fragen im Mittelpunkt der Arbeitsgruppe. Während das Portfolio der Arbeitsgruppe immer mehr hervorragende Middleware-Lösungen von eCal bis zenoh umfasst, hat sich ein aktuelles Projekt zum Ziel gesetzt, einen integrativen Ansatz anzubieten, der eine systematische und ökosystemweite Kombination spezifischer Komponenten zu größeren Lösungen ermöglicht. Dieses Projekt heißt Eclipse uProtocol und hat seit seiner ersten Veröffentlichung durch GM in der zweiten Hälfte des Jahres 2023 erhebliche Beiträge erhalten. Der uProtocol-Ansatz zielt darauf ab, zwei Dinge anders zu machen:

• Es handelt sich nicht um eine weitere Middleware-Implementierung.
• Vielmehr bietet es Konzepte und Abstraktionen, die die Zusammenarbeit in bestehenden, komplexen Organisationen (die das gesamte Technologiespektrum abdecken, wie oben dargelegt) erleichtern können.

Das uProtocol-Projekt hat eine der am schnellsten wachsenden Entwickler-Communities in der Eclipse SDV-Arbeitsgruppe angezogen. Innerhalb weniger Monate sind vielfältige Beiträge eingegangen, die bereits sichtbar die Grundlagen eines potenziellen uProtocol-fähigen Ökosystems formen und erweitern. uProtocol zeigt bereits sein Potenzial, eine integrierende Kraft und ein Sammelpunkt für viele Open-Source-SDV-Komponenten zu sein.

Insbesondere werden die Kernspezifikationen und API-Definitionen weiterentwickelt und verbessert, eine Reihe neuer Programmiersprachenbibliotheken (SDKs) erstellt (derzeit gibt es uProtocol-Unterstützung für Java, C++, Rust, Python und Kotlin) und die erste Welle von Protokolladaptern entwickelt, die Android Binder, Eclipse Zenoh und MQTT-Broker miteinander verbinden. Wenn sich die Entwicklung in diesem Tempo fortsetzt, wird die uProtocol-Service-Fabric 2024 als öffentlich sichtbarer Beweis und Vorzeigeprojekt in eines oder mehrere der Eclipse SDV Blueprint-Projekte eingeführt werden.

Derzeit ist uProtocol ein zentraler Wegbereiter für die Ultifi-Plattform von GM und verleiht dem gesamten Projekt Glaubwürdigkeit und Dynamik. Der wahre Wert eines Open-Source-Projekts liegt jedoch in seiner Fähigkeit, Mehrwert für mehr als einen Anwender zu schaffen und möglicherweise die Grundlage für eine Vielzahl von offenen und kommerziellen Angeboten zu bilden, die im gemeinsamen Technologiebereich wachsen. Daher ist die zusätzliche Einführung von uProtocol in realen Produkten und operativen Infrastrukturen ein wichtiger Erfolgsfaktor für die kommenden Jahre.

¹: Natürlich beeinflussen sich diese beiden Dimensionen gegenseitig: Die Einschränkungen des Mediums bestimmen, wie Botschaften formuliert und verwendet werden, während die Anforderungen an die Botschaften entscheiden, welches Medium sinnvoll ist.
²: Softwareentwickler teilen McLuhans Ansicht, dass „das Medium die Botschaft ist“, was bedeutet, dass „[...] das Kommunikationsmedium selbst und nicht die darin enthaltenen Botschaften im Mittelpunkt der Untersuchung stehen sollte“.
³: Auch wenn wir es damals vielleicht noch nicht „die Cloud“ genannt haben.
⁴: „Nachhaltig“ ist hier das entscheidende Wort. Man kann versuchen, ein Produkt zu entwickeln, das für einen kurzen Moment perfekt ist – aber diese Leistung muss für 10 andere Produktlinien parallel wiederholt werden und dann für alle diese 2 Jahre lang, bis die nächste Produktgeneration fällig ist. Und dann muss diese ganze Vielfalt für mehr als 10 Jahre Betrieb aufrechterhalten werden, mit potenziell vielen Millionen verkauften Einheiten...
⁵: Deshalb haben wir so viele Standards.
⁶: Bei diesem Umfang sollte klar sein, dass uProtocol nicht versucht, die Antwort auf jeden speziellen Anwendungsfall zu sein – bestimmte Dinge (zum Beispiel kritische Echtzeitkommunikation innerhalb einer Subdomain eines Fahrzeugs) lassen sich besser mit bestehenden, spezialisierten und lokalisierten Ansätzen lösen.