Revolutionäre Innovationen in der Automobilbranche: Die Software Defined Vehicle Group

Die Zukunft der Mobilität wird maßgeblich von Software gestaltet und renommierte Unternehmen wie die ZF-Gruppe, Continental, Microsoft, Karakun und Toyota haben sich zusammengeschlossen, um die Open Technology Platform für Software Defined Vehicles (SDV) der Zukunft zu gestalten. Ihr Ziel: Die Entwicklung von Software, die die Fahrzeuge von morgen antreiben wird.

Dabei geht ihr Fokus weit über das bloße Endprodukt Software hinaus – sie engagieren sich auch stark in der Entwicklung von Software, die den Entwicklungsprozess und das Prototyping unterstützt. Wie geht die Software Defined Vehicle Group dabei vor und welche Projekte wurden bisher schon umgesetzt? Hier im Blogbeitrag erfahrt ihr es!

Vision, Ziele und Maßnahmen der Software Defined Vehicle Group

Die Software Defined Vehicle Group hat die Vision, Open Source Software als effiziente Komponenten und Frameworks für unterschiedliche Hardware bereitzustellen. Sie setzt auf offene Standards und einen starken Community-Gedanken, um Experten aus verschiedenen Bereichen zusammenzubringen. Das Ziel ist es, diese Fragmente zu vereinen und daraus das Ökosystem des Software Defined Vehicles in einem „Code-First“-Ansatz zu errichten.

Ein besonderes Augenmerk liegt dabei auf:

• Mikrokontroller Frameworks
• Betriebssysteme
• Middleware
• Cloudbasierte Lösungen, um Fahrzeuge und deren Software zu verwalten

Zusammen haben sie verschiedene Maßnahmen definiert, um ihre Ziele zu erreichen, darunter die Bereitstellung von Open-Source-Lösungen, Unterstützung des „Code-First“-Ansatzes und Festlegung von Kompatibilitätsregeln und Branding-Prozessen. Auch die Förderung der Integration in verschiedene Entwickler-Toolchains und Community-Unterstützung, Erstellung einer benutzerfreundlichen Plattform, Markenstärkung und Kommunikation mit anderen Open-Source-Gemeinschaften spielen dabei eine zentrale Rolle.

Die Software Defined Vehicle Group hat bereits einige Projekte gestartet, die sich aber alle noch in einer Alpha-Phase befinden bzw. noch kein offizielles Release haben. Doch welche Ziele haben die Projekte und wie sehen diese genau aus? Fünf Projekte davon stellen wir euch im Folgenden vor:

ADAAA – ZF

ZF möchte mit diesem Projekt Erfahrungen über die Integration eines Adaptive Cruise Control über AUTOSAR Schnittstelle teilen. Aus ihrer Sicht ist die Integration einer Anwendung über AUTOSAR sehr mühselig und anstrengend, weshalb sie in der Zukunft mehrere Beispielanwendungen veröffentlichen möchten.

Mit dem ADAAA haben sie eine Demo erstellt, wie sie die Geschwindigkeit eines Fahrzeugs über die Schnittstelle manipulieren können und zeichnen diese Ergebnisse danach auf.

Hier geht’s zum Vorstellungsvideo

Chariott – Microsoft

Eclipse Chariott ist ein Projekt von Microsoft, das darauf abzielt, die Effizienz von Softwareentwicklern in der Automobilindustrie zu steigern. Es bietet eine metadatengesteuerte Middleware und Abstraktionsebene, die den Zugriff auf Fahrzeughardware und -sensoren über moderne Anwendungsprogrammiermodelle ermöglicht.

Dieser innovative Ansatz ermöglicht Automobilherstellern, Partnern und Softwareanbietern, kontinuierlich neue Softwarefunktionen, Features und Dienste für Fahrzeuge zu entwickeln und bereitzustellen, ohne eine umfangreiche Neuarchitektur durchführen zu müssen. Das Metadaten-gesteuerte Middleware/Abstraktionsmodell schafft einen gemeinsamen Weg für den Zugriff auf Fahrzeugressourcen und wird von der gesamten Branche angenommen, um die Entwicklungsarbeit zu optimieren. Es bietet eine benutzerfreundliche Serviceschnittstelle für Drittanbieter-Softwareentwickler, um auf Fahrzeugdienste und -funktionen zuzugreifen.

Hier geht’s zum Vorstellungsvideo

eCAL – Continental

eCAL ist eine hoch performante publish-subscribe Middleware, die den interprozeduralen sowie auch hostübergreifenden Datenaustausch unterstützt. Es verfügt über eine übersichtliche GUI sowie auch einer CLI.

Das Prinzip dahinter ist sehr einfach. Es gibt den eCAL Process (oder eCAL node), der Nachrichten empfängt oder konsumiert, was entweder ein Executable oder ein Script ist. Die Nachrichten werden von dem eCAL Process nicht direkt zu den Empfängern gesendet, sondern stattdessen als eCAL Topic veröffentlicht. Ein eCAL Topic ist, wie es im Messaging üblich ist, durch einen eindeutigen Namen definiert und wird dann an alle Subscriber Prozesse ausgestellt. Die Publisher und Subscriber wissen dabei nichts voneinander.

Im Bild kann man das Verhalten sehr gut erkennen: Proc 1 sendet ein Topic A, das von Proc 2 auf derselben Maschine und von Proc 3 auf einer anderen Maschine abonniert wird. Proc 2 veröffentlicht ein Topic B, das Proc 3 abonniert hat und Proc 3 veröffentlicht ein Topic C, das von Proc 2 abonniert wird.

Anders als bei MQTT-Brokern ist eCAL dezentral und benötigt für das Messaging keine zentrale Komponente.

eCAL verfügt außerdem über einen Recorder und Player. Der Recorder kann alle Topics aufnehmen, die während der Aufnahme erzeugt werden und speichert diese in einer Datei ab. Der Player kann dann die aufgezeichneten Topics erneut abspielen, sodass im Debugging jede Message erneut durchgegangen werden kann. Über den Monitor können die Messages angesehen werden. Der Player erlaubt es auch anzuhalten und schrittweise weiterzugehen. So können z. B. veröffentlichte Bilder aus der Kamera im Fahrzeug schrittweise angesehen werden.

Die Entwickler geben jedoch an, dass dieses Tool nur in prototypischen Fahrzeugen verbaut ist und im Endprodukt nicht eingesetzt wird.

Hier geht’s zum Vorstellungsvideo

KUKSA

Eines der Hauptmerkmale von KUKSA ist die Abstraktion von Fahrzeugdaten und Schnittstellen auf ein gemeinsames Format, das beispielsweise auf der Fahrzeugsignalspezifikation basiert.
Auf diese Weise können alle Funktionen, die auf KUKSA aufsetzen, auf allen freigegebenen Fahrzeugen ausgeführt werden. KUKSA konzentriert sich auf die Anpassung verschiedener Fahrzeugschnittstellen in eine grundlegende Basisschnittstelle unter Verwendung einfacher APIs. Dies ermöglicht es, einen unabhängigen Onboard- oder Offboard-Techstack zu neuen Fahrzeugarchitekturen leichter hinzuzufügen.

Hier geht’s zum Vorstellungsvideo

SommR

Eclipse SommR bietet eine Automotive-taugliche Implementierung der someIP-Spezifikation für eingebettete Linux-Systeme zusammen mit den erforderlichen Tools zur Unterstützung von Entwicklern.
Eclipse SommR fördert die Interoperabilität zwischen EUCs (Electronic Control Units) und hilft Entwicklern, sich in kürzerer Zeit auf die Anwendungsentwicklung zu konzentrieren. Im Gegensatz zu bestehenden Lösungen ist Eclipse SommR sprachunabhängig.

Die Software Defined Vehicle Group ist gerade dabei, gute Standards zu setzen und entwickelt für die Community sehr hilfreiche Tools. Bekannte Namen sowie auch Autohersteller sind in der Gruppe vertreten und sind dabei etwas Großes zu erstellen.

Die Gruppe bietet interessante Felder und ist dabei auch für doubleSlash interessant – wir behalten sie weiterhin im Auge. Möglicherweise bieten sich zukünftig auch Möglichkeiten zu einer Kollaboration an, falls wir in ähnlichen Bereichen agieren oder sogar eigene Software bereitstellen möchten.