Arm: SDVs werden Realität

Übersicht

SANJAY: Wir haben eine weitere Sonderfolge des „ Driving Innovation “-Podcasts direkt von der CES 2024 in Las Vegas. In der heutigen Folge ist Robert Day zu Gast, Leiter des Bereichs „Automotive Go-to-Market“ bei Arm. Robert wird über das Engagement von Arm im Automobilbereich sprechen sowie über die SOAFEE-Initiative, mit der das Unternehmen die Entwicklung von Cloud-nativer Software vorantreibt. Ich wünsche euch viel Spaß bei der Sendung.

Tagesordnung

ROBERT: Vielen Dank. Ich möchte mich bei „ Sonatus “ dafür bedanken, dass wir an ihrem großartigen Stand auf der CES 2024 zu Gast sein dürfen und ein wenig darüber sprechen können, wie wir bei Arm die Verwirklichung des softwaredefinierten Fahrzeugs angehen. Es wird viel über softwaredefinierte Fahrzeuge diskutiert. Viele Menschen haben nach verschiedenen Wegen gesucht, um dies tatsächlich in die Realität umzusetzen. Und genau darüber werden wir heute sprechen. Wenn wir uns also die Tagesordnung ansehen: Wir werden zunächst kurz darüber sprechen, wer Arm ist und welche Rolle Arm in der Automobilbranche spielt. Anschließend werden wir darauf eingehen, was ein softwaredefiniertes Fahrzeug ist und warum es softwaredefiniert ist. Und schließlich werden wir einige unserer Initiativen vorstellen, die unserer Überzeugung nach dazu beitragen werden, das softwaredefinierte Fahrzeug Wirklichkeit werden zu lassen. Also kurz dazu, wer Arm ist. Nun, wir sind ein Technologieunternehmen, das im Wesentlichen IP für den Einsatz in Halbleiterprodukten entwickelt. Und wir waren in unserer 30-jährigen Unternehmensgeschichte ziemlich erfolgreich. Wie Sie sehen können, wurden bereits sehr viele Arm-basierte Chips ausgeliefert. Und wir schätzen, dass 70 % der Weltbevölkerung Produkte nutzen, in denen Arm-Technologie steckt. Interessanterweise habe ich angefangen, die Anzahl der Arm-Produkte in meinem Haushalt zu zählen, und dann irgendwie aufgehört, weil es etwas schwierig wurde. Und wir beobachten, dass sich dieser Trend gewissermaßen beschleunigt, da Arm sich von der Präsenz in Verbrauchergeräten auf der Consumer Electronics Show nun in den Automobilbereich ausweitet. Und genau darüber werden wir heute sprechen.

Arm in der Automobilindustrie

ROBERT: Arm ist also schon seit 25 Jahren in der Automobilbranche tätig. Okay. Wir haben uns so ziemlich unser ganzes Leben lang mit Fahrzeugsystemen beschäftigt. Aber wir waren in der Regel eher unter der Haube tätig, wenn Sie verstehen, was ich meine. Und wenn man sich einige dieser Zahlen hier ansieht, laufen über 85 % der IVI-Systeme auf Arm, was irgendwie naheliegend ist, da IVI-Systeme wie Verbrauchergeräte sind. Sie befinden sich nur zufällig in Ihrem Fahrzeug. Aber auch jetzt, da neue ADAS-Funktionen und Autonomie Einzug halten, basieren viele der Anwendungsprozesse ebenfalls auf der Arm-Technologie. Was wir bei Arm getan haben, ist, dass wir spezielle Produkte für den Automobilbereich entwickelt haben. Wir verfügen also über CPUs, GPUs und ISPs – die ich euch gleich zeigen werde –, bei denen funktionale Sicherheit ein wesentliches Merkmal ist. Außerdem haben wir ein fantastisches Ökosystem für den Automobilbereich, zu dessen Partnern unter anderem Sonatus gehört.

Warum „Software-Defined Vehicle“?

ROBERT: Warum ist ein softwaredefiniertes Fahrzeug also wichtig? Zunächst einmal ermöglicht es den OEMs aus ihrer Perspektive, neue Geschäftsmodelle, neue Erlösmodelle und neue Beziehungen zu ihren Kunden zu erschließen. Das Besondere an softwaredefinierten Fahrzeugen ist, wie der Name schon sagt, dass die frühzeitige Softwareentwicklung entscheidend ist. In einem Auto wird es so viel Software geben, dass man das nicht auf einen Schlag schaffen kann. Okay? Wir sehen jedoch, dass softwaredefinierte Fahrzeuge für die Automobilindustrie überlebenswichtig sind. Interessanterweise ist diese Entwicklung bereits in vollem Gange. Hier ein Zitat von Gartner aus dem letzten Jahr, das besagt, dass im Jahr 2023 50 % der zehn führenden Automobilhersteller neue Funktionen über Software-Updates anbieten werden. Und genau das ist der springende Punkt beim softwaredefinierten Fahrzeug: Man kann diese Funktionen als Software einbinden, sie aktualisieren, upgraden und neue Funktionen hinzufügen. Und das ist einer der zentralen Aspekte dabei.

Sind wir bereit für SDV?

ROBERT: Die nächste Frage lautet: Sind wir als Verbraucher bereit für ein softwaredefiniertes Fahrzeug? Und sind wir bereit, dafür zu bezahlen? Aurora Labs und Strategy Analytics haben, glaube ich, im Jahr 2022 eine Studie durchgeführt, in der sie Verbraucher fragten, ob sie bereit wären, für softwaredefinierte Funktionen und Dienste zu bezahlen. Und wie Sie sehen können, gaben fast 50 % der Befragten an, dass sie 20 Dollar pro Monat für zusätzliche Dienste in ihrem Fahrzeug zahlen würden. Das ist jährlich eine ganze Menge. Und über die gesamte Lebensdauer des Fahrzeugs hinweg. Manche würden sogar bis zu 50 Dollar zahlen, was wirklich ziemlich unglaublich ist. Ich werde gar nicht erst ausrechnen, wie viel das im Jahr ausmacht.

Neue Anforderungen an SDV

ROBERT: Das Besondere an softwaredefinierten Fahrzeugen ist, dass sie neue Anforderungen an die traditionelle Automobilindustrie stellen. Wir müssen also in der Lage sein, die softwaredefinierten Funktionen als fortschrittliche Features bereitzustellen. Wir müssen Innovationen ermöglichen, aber gleichzeitig auch agil sein. Es ähnelt also eher der traditionellen Softwarewelt als unbedingt der Automobilwelt. Diese Funktionen müssen aktualisierbar und aufrüstbar sein. Sie müssen sicher sein. Und sie müssen sicherheitsrelevant sein. Schließlich müssen sie skalierbar sein. Einer der wichtigsten Aspekte eines softwaredefinierten Fahrzeugs ist, dass man diese Features und Funktionen auf verschiedene Modelle des eigenen Fahrzeugs ausweiten kann. Es wird also wirklich interessant sein zu beobachten, wie sich diese Dynamik entwickelt, wenn wir in das Zeitalter der Softwaredefinition eintreten.

Automobilprodukte von Arm

ROBERT: Wie ich bereits erwähnt habe, bieten wir bei Arm Produkte für den Automobilbereich an. Wir verfügen über eine Reihe von sogenannten AE- oder „Automotive Enhanced“-Produkten von Arm. Dazu gehört beispielsweise ein leistungsstarkes CPU-Produkt namens Cortex-A78AE. Dieses verfügt über eine interessante Funktion namens „Split-Lock“, mit der man Kernpaare miteinander verriegeln kann, um ein höheres Sicherheitsniveau zu erreichen. Wenn man jedoch hohe Leistung benötigt, kann man diese Verriegelung aufheben. Dann hat man im Grunde zwei Kerne. Diese Funktion ist in unseren AE-CPUs integriert. Wir haben außerdem eine funktional sichere GPU, die Mali-G78AE, die über einen interessanten Partitionierungsmechanismus für sicheres Rendering verfügt. Außerdem verfügen wir über einen Bildsignalprozessor (ISP) namens Mali-C78AE. All diese Produkte sind also äußerst wichtig für die Ausführung softwaredefinierter Funktionen sowie für die Ausführung grafischer Anwendungen im Fahrzeug, die Teil dieser softwaredefinierten Funktionen sein werden. Und dank des ISP lassen sich Kamerabilder mit sehr hoher Wiedergabetreue ins Fahrzeug übertragen – für alle ADAS-Funktionen und ähnliche Anwendungen. Kommen wir nun zum SDV.

Vier Säulen für SDV

ROBERT: Im Laufe unserer Gespräche mit der Branche haben wir erkannt, dass es sozusagen vier Säulen gibt, auf denen die Verwirklichung und die Umsetzung des SDV beruhen. Da sind zum einen die obersten und zum anderen die untersten Säulen – natürlich Sicherheit und Schutz –, und man braucht Echtzeitfähigkeit. Das sind Dinge, die die Automobilbranche ohnehin benötigt, und auch das softwaregesteuerte Fahrzeug braucht sie. Wir brauchen einige Standards, die über die traditionellen Automobilstandards hinausgehen. Für die softwaredefinierten Funktionen muss es APIs und Standards geben, auf denen wir diese Funktionen aufbauen können. Wir brauchen neue Software-Methoden. Darauf werde ich heute näher eingehen, denn das ist ein interessanter Weg, wie wir diese Software-Methoden aus anderen Branchen tatsächlich in die Automobilindustrie einbringen können. Nun, was ganz entscheidend ist – und auch darauf werde ich gleich noch eingehen –, ist die Fähigkeit, die Software auszuführen, wenn das Fahrzeug und die Fahrzeug-Rechenleistung noch nicht verfügbar sind. Man muss frühzeitig beginnen können und Dinge wie Simulationen durchführen. Und der wichtigste Punkt, auf den ich am Ende noch eingehen werde, ist die Zusammenarbeit innerhalb der Branche. Wir können uns solche Silos nicht mehr leisten. Die Menschen müssen zusammenarbeiten. Das Problem ist zu groß, als dass ein Unternehmen es alleine bewältigen könnte. Schauen wir uns also einige dieser Punkte kurz an. Einer der Schlüssel, über den wir gerade gesprochen haben, waren neue Software-Methoden.

Moderne Entwicklungsprozesse

ROBERT: Was wir also jetzt in der Automobilbranche tun müssen, ist, moderne Entwicklungsprozesse einzuführen, um im Grunde die Entwicklungs- und Bereitstellungszeit von Software zu verkürzen. Außerdem brauchen wir die sogenannte „Umgebungsparität“: Wenn man in der Cloud entwickelt und am Edge bereitstellt, ist es wirklich gut, wenn diese beiden Umgebungen denselben Befehlssatz verwenden, damit man die Software erst in der Cloud und dann im Auto ausführen kann. Darauf werden wir noch etwas näher eingehen. Eine einfache Bereitstellbarkeit über eine Reihe von Halbleiteranbietern hinweg ist ebenfalls sehr wichtig. Das gewährleistet die Portabilität Ihrer Software, wenn Sie von einer Fahrzeuggeneration zur nächsten oder von einem Fahrzeugmodell zum nächsten wechseln. Und was dies darüber hinaus ermöglicht, ist eine „Shift-Left“-Strategie. Das werde ich auf der nächsten Folie erläutern.

„Shift-Left“-Strategie in der Automobilindustrie

ROBERT: Die traditionelle Automobilentwicklung hier oben ist also ziemlich sequenziell aufgebaut. Im Grunde entwirft man zuerst die Software und den SoC, dann folgt die Entwicklung der Steuergeräte (ECU) und ganz am Ende die Anwendungsentwicklung. Es handelt sich also um einen sequenziellen Prozess. Man kann mit der Anwendungsentwicklung nicht wirklich in großem Umfang beginnen, solange diese Komponenten noch nicht bereitstehen. Wenn wir auf Cloud-Native setzen, führen wir die Cloud ein. Und wenn man frühzeitig mit der Anwendungsentwicklung in der Cloud beginnen kann – also hier oben –, dann kann man hier bereits mit der Entwicklung starten, während diese anderen Schritte noch laufen. So haben wir hier einen parallelen Ablauf. Und sobald die Systemintegration abgeschlossen ist, kann man das System ins Fahrzeug bringen und dort testen. Was wir tatsächlich tun, ist, es zuerst hier oben zu testen und weiterzuentwickeln. Wenn das Fahrzeug bereit ist – oder die Fahrzeugelektronik bereit ist –, bringt man es ins Fahrzeug. Was dies außerdem ermöglicht – und hier kommt der zeitliche „Shift-Left“-Ansatz ins Spiel –, sind kontinuierliche Updates und Upgrades, was ein wichtiger Faktor für das softwaredefinierte Fahrzeug ist. Man ist also ständig in der Lage, den Nutzern des Fahrzeugs entweder neue oder aktualisierte Dienste anzubieten. Dies birgt eine wirklich interessante, mögliche dynamische Veränderung in der Beziehung zwischen den Fahrzeugherstellern und den Menschen, die ihre Autos fahren, denn wenn man derzeit ein Auto kauft, fährt man es gewissermaßen vom Hof. Man hat nicht wirklich eine nennenswerte Beziehung zu dem Unternehmen, das das Auto gebaut hat. Wenn sie nun aber Updates und Dienste bereitstellen, entsteht eine solche Beziehung. Und so beginnt sich die Beziehung zwischen den Menschen, die die Autos fahren, und denen, die sie bauen, zu verändern. Wie erreichen wir das also?

SOAFEE-Initiative

ROBERT: Vor ein paar Jahren haben wir also eine Initiative namens SOAFEE ins Leben gerufen. Es handelt sich um eine Brancheninitiative, die darauf abzielt, Erfahrungen aus der Cloud-nativen Softwareentwicklung für softwaredefinierte Fahrzeuge in der Automobilbranche nutzbar zu machen. Okay? Dazu haben wir die SOAFEE-Interessengruppe gegründet. Als Erstes wollten wir damit versuchen, eine Softwarearchitektur zu definieren, die dies ermöglicht. SOAFEE definiert also in erster Linie eine Architektur und nicht etwa Code. Damit die Leute jedoch wirklich mit SOAFEE loslegen können, war uns klar, dass wir eine Referenz-Software-Implementierung benötigen, damit sie damit beginnen können, diese neuen Methoden für Workloads im Automobilbereich zu entwickeln und auszuprobieren. Und wie Sie sehen können, kommen die Gründungsmitglieder und die Mitglieder des Lenkungsausschusses von SOAFEE wirklich aus dem gesamten Automobil-Ökosystem. Wir haben also OEMs, wir haben Tier-1-Zulieferer, wir haben Cloud-Experten, wir sind selbst dabei, und dann haben wir noch einige Software-Experten. So sind Red Hat und SUSE mit an Bord, die sich wirklich gut mit Softwareentwicklung auskennen und wissen, wie alles zusammenpasst. Wir sind daher überzeugt, dass wir allein schon in den Leitungsgremien einen guten Überblick darüber haben, was wir erreichen wollen. Ich werde Ihnen gleich noch ein wenig mehr über die Mitglieder von SOAFEE zeigen.

Cloud-native Architektur

ROBERT: Aber ich habe dir ja gesagt, dass wir wirklich versuchen, eine Architektur zu definieren. Und wie du hier sehen kannst, haben wir diese Architektur, bei der es einige Cloud-Komponenten und einige Komponenten im Fahrzeug gibt. Der Kern der Idee sind jedoch die eigentlichen Anwendungen, und vieles davon wird konstant bleiben bzw. zwischen der Cloud und dem Edge konsistent sein. Das bedeutet also: Wenn ihr beispielsweise eure Anwendungen oder Dienste in der Cloud entwickelt und bereit seid, sie an den Edge zu bringen, sollten diese einfach funktionieren. Und genau hier setzen wir Technologien wie Container ein und nutzen Verfahren wie Orchestrierung. Diese sind gewissermaßen aus der Cloud-Welt übernommen. Sie sind also bereits gut etabliert. Die Menschen sind bereits damit vertraut. Was wir tun müssen, ist, sie für den Automobilbereich anzupassen. Und das bedeutet konkret, dass wir Aspekte wie funktionale Sicherheit, Echtzeitfähigkeit und heterogene Rechenumgebungen berücksichtigen müssen, die in der Cloud nicht unbedingt gegeben sind. Das ist also eine der Herausforderungen, denen sich SOAFEE stellen wird.

SOAFEE-Mitgliedschaft

ROBERT: In den letzten Jahren hatten wir also tatsächlich eine recht gute Zusammensetzung an Mitgliedern. Ihr könnt euch die Mitglieder des Vorstands noch einmal ansehen. Wir sind mittlerweile bei – ich glaube, es sind sogar eher 115 Mitglieder. Und hier drüben seht ihr – wahrscheinlich ist es nicht gut zu erkennen –, das Logo von „ Sonatus “. „ Sonatus “ ist Mitglied bei SOAFEE. Das macht absolut Sinn, denn ein Großteil dessen, womit sich „ Sonatus “ beschäftigt, dreht sich um das softwaredefinierte Fahrzeug. Es geht um „Cloud-to-Vehicle“. Sie sind also echte Experten auf diesem Gebiet, mit denen wir zusammenarbeiten können.

SOAFEE-Arbeitsgruppen

ROBERT: Also, ein paar Worte zur Struktur von SOAFEE. Ich bin mir wieder einmal nicht ganz sicher, wie verständlich das rüberkommt. Wir haben also ein Leitungsgremium, dessen Vorsitz Bill von AWS innehat. Wir haben einen technischen Lenkungsausschuss und einen Marketing-Lenkungsausschuss. Der technische Lenkungsausschuss betreut im Wesentlichen alle Arbeitsgruppen, die die eigentliche Arbeit leisten, und die Bereiche, mit denen sie sich beschäftigen, umfassen die Systemarchitektur. Wir befassen uns mit Cloud-Native. Wir beschäftigen uns mit Mixed-Criticality und mit Technologien wie Hypervisor-Technologien, die unserer Meinung nach entscheidend sein werden. Und all diese Erkenntnisse fließen dann in diese Referenzimplementierung ein, die wir als Open-Source-Projekt veröffentlichen, um SOAFEE frühzeitig nutzbar zu machen. Was wir sonst noch gemacht haben: Wenn wir etwas zurückgehen, seht ihr hier, dass wir noch ein weiteres Tiger-Team haben, nämlich das Blueprints-Tiger-Team.

SOAFEE-Entwürfe

ROBERT: Es ist zwar gut, einfach eine Open-Source-Referenzimplementierung zu veröffentlichen, aber das setzt irgendwie voraus, dass die Leute sagen: „Okay, jetzt müssen wir etwas tun.“ Verstehst du? Wir haben uns daher entschieden, diese SOAFEE-Blueprints zu entwickeln – das sind Referenzanwendungen, im Wesentlichen für Anwendungsfälle in der Automobilindustrie, die in einer SOAFEE-Umgebung laufen. Das kann Open Source sein, es kann aber auch Closed Source sein. Unser Ziel war es also, Beispielanwendungen in die SOAFEE-Welt zu bringen, damit die Leute sie nutzen können und damit auch OEMs mit den vorhandenen Beispielen schnell loslegen können. Ich werde etwas genauer darauf eingehen, was diese Blueprints eigentlich leisten. Ein SOAFEE-Blueprint nutzt im Wesentlichen einen Teil der Zeit, die die Referenzimplementierung benötigt, um auf der Firmware und der Hardware zu laufen. Und dann haben wir diese Container. Wie ich bereits sagte, ist ein wesentlicher Bestandteil der SOAFEE-Architektur die Containerisierung von Workloads – also eine Art Microservices-Ansatz. Wir haben also verschiedene Workloads, die in verschiedenen Containern laufen. Und Sie sehen hier die verschiedenen Software-Elemente: Wir haben anwendungsspezifische Workloads, wir haben den Basis-Stack, der Container, Orchestrierung, möglicherweise Hypervisoren, Werkzeuge und alles andere umfasst. Und ganz unten die Rechenplattform. So sieht also ein generischer Blueprint aus. Nun möchte ich Ihnen ein Beispiel geben.

Open AD Kit

ROBERT: Das erste Beispiel war also das sogenannte OpenAD Kit. Dabei arbeiten wir mit einem Open-Source-Unternehmen für autonome Fahrsoftware namens Autoware zusammen. Im Rahmen dieses Projekts haben wir im Grunde den Autoware-Stack für autonomes Fahren genommen und ihn in verschiedene Container aufgeteilt. Diese verschiedenen Container kommunizieren dann über ein virtuelles Netzwerk miteinander. Wie Sie sehen können, befinden sich in jedem der Container verschiedene Funktionen: Kartierung, Wahrnehmung, Planung und Fahrzeugschnittstelle. Am Anfang haben wir ein bisschen geschummelt, um sicherzugehen, dass das Ganze überhaupt funktioniert. Tatsächlich lassen wir vier vollständige Kopien von Autoware in einem Container laufen, nutzen darin aber nur die Kartierungsfunktion. Um zu einer eher auf Microservices ausgerichteten Architektur zu gelangen, mussten wir Folgendes tun: Wir haben im Grunde jede dieser Funktionen in einen eigenen Container ausgelagert, sodass hier nicht mehr der gesamte autonome Stack läuft, sondern jede der Funktionen einzeln. Und genau das tun wir derzeit mit diesem OpenAD-Kit-Blueprint. Das Interessante an den Blueprints – und das war auch der Grund, warum wir sie entwickelt haben – ist, dass wir wollten, dass die Branche sie aufgreift und nutzt: entweder als Beispiele dafür, was man als OEM damit erreichen kann, oder als Grundlage für andere Technologieunternehmen, die ihre eigene Technologie einbringen, um das Ganze noch interessanter zu gestalten. Und so kam letztes Jahr ein Unternehmen namens Kern Concept auf uns zu und sagte: „Okay, ich werde mich noch einmal mit diesen containerisierten Lösungen beschäftigen.“ Und ich weiß, dass eine der Funktionen hier, die Fahrzeugschnittstelle, eine Sicherheitsfunktion ist. Wenn die nicht funktioniert, funktioniert das Fahrzeug nicht. Okay? Das sollte also in einem Sicherheitssystem laufen. Was sie also gemacht haben – wenn ich hierher gehe –, ist, dass sie zwei Systeme hatten. Sie hatten eines hier drüben, auf dem der Großteil der Autoware-Komponenten läuft, und dann eines hier drüben, das die Sicherheitsfunktion übernimmt, also im Wesentlichen die Fahrzeugschnittstelle, und dazwischen gibt es ein Ethernet, ein echtes physisches Ethernet, statt eines virtuellen Ethernets. Das ist also dasselbe Konzept wie bei containerisierten Microservices, nur dass wir es hier in einem heterogenen Netzwerk – einem heterogenen System – umsetzen. Wie Sie sehen können, befindet sich der Sicherheitsteil hier drüben, der dann auf einem Sicherheitsmikroprozessor, in diesem Fall einem von NXP, laufen kann. Und hier drüben befinden sich Anwendungsprozesse, die nicht unbedingt das gleiche Sicherheitsniveau aufweisen müssen.

SOAFEE-Zielplattformen

ROBERT: Apropos Plattformen: Ein weiterer wichtiger Schritt war die Bereitstellung einer Hardware-Plattform – das war auf der Karte zwar nicht zu sehen, aber viele unserer Halbleiterpartner sind Mitglieder von SOAFEE. Und was wir jetzt wirklich anstreben, ist, dass sie ihre Plattformen einbringen. SOAFEE, also die SOAFEE-Referenzimplementierung, auf diesen Plattformen zu installieren. Wie ihr seht, sind Unternehmen wie Renesas, NXP und Marvell dabei. Außerdem haben wir eine native Cloud-Instanz von AWS. Das bedeutet, dass man SOAFEE „Bare-Metal“ in der Cloud auf einem „Graviton“ ausführen kann, einem Arm-basierten Prozessor. Und dann wollten wir auch einige interessante Entwicklerplattformen haben, die nicht aus dem Automobilbereich stammen. Deshalb haben wir den Turing Pi und den Raspberry Pi. Tatsächlich war der Raspberry Pi bei der COVESA-Veranstaltung gestern Abend eines der Systeme, auf denen SOAFEE lief. Okay, das ist also SOAFEE.

So können Sie sich engagieren

ROBERT: Wenn ihr Interesse habt und mitmachen möchtet, findet ihr auf SOAFEE.io jede Menge Informationen. Es gibt einen Slack-Kanal, und SOAFEE ist auf LinkedIn vertreten. Und wenn ihr beitreten möchtet, ist es wahrscheinlich am besten, wenn ihr euch direkt an mich wendet: Robert.Day@arm.com. Dann werde ich euch dabei helfen, Mitglied zu werden. Das ist also SOAFEE. Wir glauben, dass dies ein wirklich interessanter Aspekt ist, um das softwaredefinierte Fahrzeug Wirklichkeit werden zu lassen. Wenn einige von euch aufmerksam zugehört haben, ist euch sicher aufgefallen, dass es noch andere Konsortien gibt, die ebenfalls dazu beitragen, das softwaredefinierte Fahrzeug Wirklichkeit werden zu lassen. Aber jeder von uns bewegt sich gewissermaßen in seiner eigenen Welt, in der er seinen eigenen Teil dazu beiträgt. Und so ist es nicht immer offensichtlich. Wie fügen sich all diese Dinge nun zusammen? Im vergangenen März haben wir beschlossen, auch dabei zu helfen.

SDV-Allianz

ROBERT: Wir haben also eine neue Allianz gegründet. Diese Allianz wurde gestern ins Leben gerufen. Es handelt sich um eine Zusammenarbeit – ich würde sagen, eine erste Zusammenarbeit – zwischen vier Organisationen, die alle darauf hinarbeiten, SDV zu verwirklichen. Da wäre zum einen AUTOSAR, das wohl älteste … nein, das ausgereifteste der Konsortien. Wir haben COVESA, das früher GENIVI oder GEN IVI hieß. Wir haben Eclipse SDV und wir haben SOAFEE. Und was wir also tun, ist, eine Zusammenarbeit zwischen diesen verschiedenen Konsortien zu fördern. Es ist also so etwas wie ein Konsortium der Konsortien oder, wenn man so will, eine Zusammenarbeit der Kooperationen. Und allein in diesen vier Organisationen sind über 500 Unternehmen aus dem Automobil-Ökosystem an diesen verschiedenen Konsortien beteiligt. Was dies außerdem bewirkt – und was wir als Allianz tun werden –, ist, ganz klar zu machen, wie diese Dinge zusammenpassen. Tatsächlich hatten wir bei der Auftaktveranstaltung gestern Abend eine Demo, bei der Teile aus jedem dieser Konsortien zusammenliefen – einfach als Anschauungsbeispiel, um zu zeigen, dass dies möglich ist. Was dies jedoch bewirkt, ist, dass es Cloud-to-Edge, vernetzte Fahrzeuge, Open Source, offene Standards sowie Echtzeit- und Sicherheitsaspekte gewissermaßen in einem Paket vereint. Das Ziel ist: Wenn wir das tatsächlich richtig hinbekommen, sollte dies den OEMs die Arbeit erheblich erleichtern – sowohl bei der Entwicklung als auch bei der Einführung des softwaredefinierten Fahrzeugs. Aber es wird auch die Zusammenarbeit fördern – mehr Zusammenarbeit. Keine isolierte Zusammenarbeit im Rahmen eines Konsortiums, sondern echtes Miteinander. Und es war eine wirklich interessante Reise in den letzten neun Monaten, an dieser Allianz zu arbeiten und die Zusammenarbeit voranzutreiben. Jetzt, da wir den Startschuss gegeben haben, beginnt die eigentliche Arbeit. Ich würde also sagen: Behalten Sie einfach im Auge, was aus dieser Allianz hervorgeht. Und noch einmal: Wenn Sie sich an der Allianz beteiligen möchten, können Sie sich an jede dieser anderen Organisationen wenden. Abschließend möchte ich noch sagen, dass es sich um eine offene Allianz handelt. Wir gehen davon aus, dass sich weitere Konsortien daran beteiligen werden. Es sind nicht nur wir vier. Wir wollten den Startschuss geben, ermutigen aber andere Konsortien, sich dieser Allianz und dieser gemeinsamen Brancheninitiative anzuschließen. Und wir sind fest davon überzeugt – das habe ich gestern Abend im Gespräch mit zwei Erstausrüstern gehört –, dass dies etwas ist, das sie zu schätzen wissen. Wir hoffen also, dass dies ein wirklich guter Start wird – tatsächlich der Beginn der Reise hin zum softwaredefinierten Fahrzeug. Ich habe gesagt, dass sie bereits im Gange ist, aber nun müssen wir sie in großem Stil in die Tat umsetzen. Und wir hoffen, dass alle diese Konsortiumsmitglieder zusammenkommen und zusammenarbeiten, um dies wirklich zu verwirklichen. Lassen wir diese Folie überspringen.

Fazit

ROBERT: Damit möchte ich mich nun bedanken. Nochmals vielen Dank an Sonatus , dass sie uns die Gelegenheit gegeben haben, hierher zu kommen und über diese coolen Dinge rund um softwaredefinierte Fahrzeuge zu sprechen. Und ich hoffe, euch gefällt die Online-Übertragung. Vielen Dank.