Die Rolle der Cloud in modernen Fahrzeugen (Teil 2)

Übersicht

JOHN: Heute präsentieren wir in „ The Garage “ den zweiten Teil unserer zweiteiligen Sonderserie zum Thema Cloud Computing für die Automobilbranche mit unserem besonderen Gast Stefano Marzani von AWS. Im ersten Teil unseres Gesprächs haben wir über Daten- und Rechenaspekte des Cloud Computing gesprochen. In der heutigen Folge setzen wir das Gespräch fort und sprechen über Prototyping, Datenanalyse und „ AI “ sowie über ADAS- und autonome Anwendungen der Cloud. Setzen wir unser Gespräch mit Stefano Marzani von AWS fort. Los geht’s!

Thema 3: Prototypenentwicklung in der Cloud und „Umweltparität“

JOHN: Das ist eigentlich ein perfekter Übergang zu unserem dritten Thema, nämlich dem Prototyping. Wie ich bereits erwähnt habe, haben wir uns kürzlich mit Robert Day unterhalten, und Arm beobachtet, dass die Arm-Architektur in einer Vielzahl von Subsystemen im Auto zum Einsatz kommt. Und, wissen Sie, ich bin stolz darauf, seit 14 Jahren bei Arm zu arbeiten. Das liegt mir also ein wenig am Herzen. Aber Robert hat viel darüber gesprochen. Ich denke aber, das bedeutet auch – und ich glaube, das ist einer Ihrer Punkte –, dass die Tatsache, dass Graviton in der Cloud ist und es sowohl Arm-basierte Instanzen in der Cloud als auch Arm-basierte Instanzen im Auto gibt, einige wirklich interessante Möglichkeiten für das Prototyping eröffnet.

STEFANO: Auf jeden Fall, ja. Wir nennen das „Environmental Parity“, richtig? Wir haben diesen Begriff erstmals auf der Dev Summit Conference 2021 verwendet – genauer gesagt in einem Workshop auf der Arm Dev Summit Conference, der eine recht große Reichweite und Bekanntheit erlangt hat. Da wir dieses Konzept damals zum ersten Mal vorstellten: Warum sollten wir Arm-Architekturen nicht in der Cloud nutzen, um dieselbe Software auszuführen, die – wenn man so will – auf derselben Arm-Architektur in den Autos läuft, oder? Dieselbe Arm-Architektur, nicht dieselben Prozessoren – wir haben keine Ahnung und auch nicht die Absicht, den Graviton in ein Auto einzubauen, oder? Es sind tatsächlich die Steuergeräte (ECUs) in Autos, die von verschiedenen Anbietern wie Qualcomm, Nvidia oder NXP stammen; all diese basieren auf Arm-Kernen. Und noch einmal: Der Arm-Kern – es ist genau derselbe Kern, den wir im Graviton haben. Richtig? Was Arm 64 betrifft, handelt es sich natürlich nicht wirklich um dieselbe CPU, denn unser Graviton basiert auf der Neoverse-Architektur, während in Fahrzeugen häufig Cortex zum Einsatz kommt – aber der Großteil des Befehlssatzes ist identisch.

Ausführung auf Arm in der Cloud und im Fahrzeug

STEFANO: Das ist der Grund, warum wir das laden können, und nachdem wir diese Idee hatten, haben wir sie umgesetzt. Jetzt verfügen wir also über eine riesige Vielfalt an eingebetteten Betriebssystemen, die traditionell nur in emulierten Umgebungen oder auf physischer Hardware funktionierten, die nun nativ in der AWS-Cloud auf Graviton laufen. Systeme wie QNX, VxWorks, Yocto Linux, AGL. Und für Embedded-Entwickler ist das eine neue Art der Entwicklung – wir erleben eine unglaubliche Resonanz, weißt du, sogar eine Überraschung, wenn man so will, wenn man sagt: „Moment mal, das wird gerade erst in der Cloud gestartet“, und schon haben sie eine QNX-Eingabeaufforderung vor sich, als würden sie eine Art Steuergerät verwenden. Ja, genau das meinen wir mit „Umgebungsparität“. Man kann dort direkt mit der Arbeit beginnen. Man braucht zwar trotzdem Hardware, aber nicht, um mit der Entwicklung zu starten.

Starten Sie die Softwareentwicklung in der Cloud

STEFANO: Das ist derzeit ein riesiger Engpass für die Branche und aus deiner Sicht als Prototypenentwickler von großer Bedeutung, oder? Man kann nur begrenzt innovativ sein, wenn man ständig Entwickler – und zwar immer bessere – benötigt, die über die nötige Hardware verfügen, um arbeiten zu können, denn es gibt keine Hardware, die den Bedarf decken könnte.

JOHN: Klar. Und was das Testen angeht: Regressionstests. Wir haben in einer früheren Folge bereits erwähnt, dass wir begonnen haben, unsere eigenen Tests auch cloudbasiert durchzuführen. Anstatt also ein Rack nach dem anderen voller Systeme zu haben, die man sozusagen aus der Ferne ein- und ausschaltet, kann man virtuelle Instanzen und EC2 nutzen. Das machen wir also auch. Und wir sehen diesen Vorteil, und wir nutzen das intensiv.

Schwierigkeiten bei der Validierung im Automobilbereich

STEFANO: Ja. Ja, auf jeden Fall. Das ist, das ist wiederum ein riesiger Vorteil für Entwickler und für die Validierungsphase, oder? Denkt mal darüber nach. Dennoch ist das Auto heutzutage buchstäblich ein System, das, wie ihr wisst, nicht gründlich getestet wird. Das liegt an historischen Gründen. Wie wir bereits zu Beginn der Folge gesagt haben, durchläuft das Auto gerade einen tiefgreifenden Wandel: von einem System, das in einem modernen Fahrzeug mit Verbrennungsmotor aus über 150 Steuergeräten besteht, hin zu deutlich weniger – sagen wir 30 oder 40 – mit konsolidierten Rechnern. Es wird zwar weiterhin mikrocontrollerbasierte Peripheriegeräte für die Sensorik oder die Ansteuerung geben. Aber die Hauptrechenleistung wird von konsolidierten Architekturen übernommen, die über zahlreiche Arm-Kerne verfügen – 8, 12, 16 oder 40 –, und zwar in extrem konsolidierten Architekturen. Und das ist extrem wichtig, nicht wahr? Es ist ein äußerst wichtiger Trend.

Entwickler über die Cloud unterstützen

STEFANO: Und man kann nicht erwarten, dass Entwickler diese Geräte auf ihrem Schreibtisch haben, um damit zu arbeiten – man muss ihnen aus den bereits genannten Gründen eine Umgebung bieten, eine Cloud-native Umgebung. Denn dort haben wir die Daten. Dort haben wir Rechenkapazitäten. Dort haben wir Graviton. Das ist also die natürliche Umgebung, in der Entwickler ihre Tools finden, arbeiten, auf der Hardware bereitstellen und weiterhin auf der Hardware testen können – aber nicht umgekehrt.

Die Fahrzeugsoftware wird sich in den nächsten fünf Jahren verdreifachen

STEFANO: Denn wenn man bei der Hardware ansetzt, erstickt man die Innovation im Keim. Weißt du, im Bereich SDV wird laut einigen Analysten erwartet, dass sich die Code-Menge in den nächsten fünf Jahren verdreifachen wird – von 100 Millionen auf 300 Millionen. Wie soll man das schaffen, wenn man weiterhin erwartet, dass Entwickler über Hardware verfügen müssen, um zu arbeiten und Code für Fahrzeuge zu entwickeln?

JOHN: Wow, das ist eine unglaubliche Zahl. Diese Statistik kannte ich noch nicht: eine Verdreifachung in den nächsten drei Jahren?

STEFANO: Fünf Jahre.

JOHN: Das ist unglaublich. Weißt du, ich habe mir überlegt, dass es meiner Meinung nach auch einen positiven Kreislauf gibt, denn wir haben in einer früheren Folge über die Konsolidierung von Workloads gesprochen, und du hast das gerade eben auch erwähnt. Und ich denke – wir haben auch über die Bedeutung der Virtualisierung gesprochen und darüber, dass man diese Anwendungen nebeneinander ausführen kann, ohne dass sie sich gegenseitig stören. Für mich fühlt sich das so an, als gäbe es hier auch eine ziemliche Synergie zwischen diesem Cloud-Prototyping-Ansatz und der Virtualisierung, denn man kann genau dieselben Workloads, die man dort getestet hat, nun nebeneinander laufen lassen. Und es ähnelt, wie du gesagt hast, sehr stark dem Ansatz der „Umgebungsparität“, von dem du gerne sprichst.

STEFANO: Ja, auf jeden Fall. Auf jeden Fall. Und wenn man mal darüber nachdenkt: Wenn man 12 oder 16 Kerne hat, nutzt man nicht alle für ein einziges Betriebssystem – das bedeutet, dass man diese Kerne aufteilen und mehrere Betriebssysteme ausführen muss. Aber genau das machen wir in der Cloud: Wir haben einen Hypervisor, der auf 64 Kernen eines Graviton-Prozessors mehrere Betriebssysteme verwaltet – genau so ist es. Natürlich gibt es Unterschiede hinsichtlich der elektronischen Qualifizierung und vieler, vieler anderer Aspekte. Aber aus Sicht der Softwareentwicklung können wir die Dinge so gestalten, dass die beiden Umgebungen einander sehr ähnlich sind.

JOHN: In der Prototyping- und Testphase lässt sich also schon fast nachweisen, wie es in der endgültigen Umsetzung aussehen wird – das ist sehr interessant. Das finde ich sehr faszinierend, technisch gesehen faszinierend, und ich halte es auch für ein sehr leistungsfähiges Werkzeug in der Entwicklung.

„Shift Left“, um den Entwicklungszyklus zu beschleunigen

JOHN: Und, wissen Sie, wir beobachten – und wir haben bereits vor Jahren darüber gesprochen –, den Ansatz des „Shift Left“, also wie wir virtuelles Prototyping, die Cloud und so weiter nutzen können, um den Entwicklungszyklus zu beschleunigen. Und wir sehen – und darüber haben wir auch in einer unserer jüngsten Folgen gesprochen –, dass der Druck auf den Entwicklungszyklus wächst, schneller zu entwickeln, und ich denke, das Wettbewerbsumfeld für OEMs und Tier-1-Zulieferer wird immer härter. Und wenn diese Maßnahmen den Entwicklungszyklus verkürzen können, kann das die Wettbewerbsfähigkeit steigern, Kosten einsparen und – wie du bereits angesprochen hast – die enorme Komplexität bewältigen, die durch die steigende Anzahl an Software-Zeilen entsteht; das muss man im Griff haben. Und ich denke, man muss das Ganze in Teilbereiche aufteilen, um das zu schaffen. Andernfalls, wenn man es als ein riesiges, monolithisches System betrachtet, ist es unmöglich, es zu verifizieren.

40–50 Milliarden Dollar Verlust durch Rückrufaktionen in der Automobilbranche

STEFANO: Auf jeden Fall. Und es gibt noch weitere Vorteile. „Shift Left“ ist also definitiv sinnvoll. Die Codequalität steigt, weil man die Tests stärker ausweiten kann. Das ist also absolut sehr, sehr wichtig. Denken Sie mal an die Automobilindustrie. Auch heute noch entstehen jedes Jahr Verluste in Höhe von 40 bis 50 Milliarden Dollar durch Rückrufaktionen. 70 % davon sind auf Softwarefehler zurückzuführen. 70 % der erfassten Fälle. Denken Sie mal darüber nach. Das ist schlechte Qualität. Können wir das so sagen?

JOHN: Ja.

STEFANO: Mangelhafte Tests.

JOHN: Auf jeden Fall.

STEFANO: Nicht nach links verschieben.

JOHN: Ja.

STEFANO: Stimmt’s? Also: nach links verschieben, Kosten senken, Qualität steigern. Aber ich möchte auch an die Endnutzer denken. Denn wir sehen: Wenn man diese Steuergeräte nicht zur Entwicklung herumschicken muss, kann man die Zusammenarbeit in der Cloud ermöglichen. Und das ist extrem wichtig. Tatsächlich ist das eine überraschende Sache am SDV. Wir haben über ADAS-/AV-Dienste gesprochen, die auf Telematik basieren, also Telematikdienste.

Entwicklung von Fahrzeug-HMI mithilfe der Cloud

STEFANO: Wir beobachten einen enormen Anstieg bei der HMI-Entwicklung in der Cloud – also bei der Mensch-Maschine-Interaktion, der Benutzeroberfläche und der Benutzererfahrung. Und das finde ich einfach fantastisch. Und man versteht sofort, warum. Man versteht es, weil man zum ersten Mal eine virtuelle ECU in der Cloud hat, die eine Benutzeroberfläche im Browser anzeigt. Ich kann sie sofort meinem gesamten Kooperationsnetzwerk rund um den Globus zeigen, da die Cloud weltweit verfügbar ist. So kann ich einen Kollegen in Japan oder einen Kollegen in Südafrika fragen: Was hältst du von meiner neuen Benutzeroberfläche, entsprechend deinem lokalen Geschmack? Oder kannst du sie anpassen? Oder kannst du daran arbeiten?

JOHN: Und Lokalisierung, Sprache.

STEFANO: Es ist buchstäblich eine Revolution in der Art und Weise, wie man HMI-Systeme umsetzt, wenn man bedenkt, dass man nicht mehr diese Hardware überall installieren muss. Stattdessen verfolgt man einen – wie wir sagen – „Cloud-native“- und „Cloud-first“-Ansatz bei der HMI-Entwicklung. Und wir haben bereits einen Kunden, der versucht, diesen Ansatz umzusetzen. Außerdem haben wir kürzlich gemeinsam mit BMW auf dem letzten AWS-Summit in Berlin eine sehr interessante Präsentation über deren Entwicklungspraktiken für HMI in der Cloud veröffentlicht – den Link dazu können wir natürlich bereitstellen. Es ist eine schöne Demonstration. Aber es geht nicht nur darum, immer nur über BMW zu sprechen; ich kann zum Beispiel auch über die Demo sprechen, die wir auf der CES gemeinsam mit Marelli durchgeführt haben. Marelli ist ein Tier-1-Zulieferer. Und sie haben dort an unserem Stand das erste cloudnative HMI-System vorgestellt. Das ist wirklich beeindruckend, denn dort sieht man, dass wir eine HMI-Anwendung in der Cloud entwickelt haben. Und diese dann in Mailand, in Italien, bereitgestellt haben. Das hat ein Ingenieur in der Cloud erledigt und anschließend am Stand in Las Vegas bereitgestellt, richtig? Auch hier beginnt man mit der Cloud-Entwicklung und stellt die Anwendung dann auf einer bestimmten Hardware-Lösung bereit und passt sie an, richtig? Und das ist wirklich, wirklich leistungsstark, wenn man darüber nachdenkt. Es ist nicht nur leistungsstark. Es ist SDV, richtig? Es ist softwaredefiniert. Andernfalls wäre es hardwaredefiniert – wenn man mit der Hardware beginnt, ist es hardwaredefiniert. Wenn es wirklich softwaredefiniert ist, muss man mit der Software beginnen und sie später bereitstellen.

SDV kann die Kosten für Rückrufaktionen senken

JOHN: Genau, genau. Du hast da gerade so viele Aspekte angesprochen. Und ich möchte den Punkt, den du bezüglich Rückrufaktionen erwähnt hast, nicht aus den Augen verlieren. Wir hören oft Bedenken von Erstausrüstern, die eine große Belastung durch die Softwareentwicklung haben – was ja stimmt –, die sagen: „Oh, es ist zu schwierig, diese softwaredefinierte Fahrzeugfunktion zu integrieren.“ Aber wenn man an eine Zahl denkt, wie du gesagt hast, 40 oder 50 Milliarden Dollar, von denen ein Großteil softwarebezogen ist, wäre es verrückt, keine Funktionen zu integrieren, um dieses Problem anzugehen, denn es erfordert keine großen Investitionen, um möglicherweise Milliarden von Dollar einzusparen.

STEFANO: Ja, wir hatten eine sehr schöne Folge von „All Things Automotive“ mit Martin Stamm von Conti.

JOHN: Ja, ich habe diese Folge gesehen.

STEFANO: Ja, hast du das gesehen? Wo er erklärt, warum das so ist, oder?

Zusammenlegung von Steuergeräten

STEFANO: Traditionell hatten Hersteller, also OEMs, den Bedarf, neue Funktionen zu integrieren. Das heißt: Okay, wir müssen noch eine Steuereinheit integrieren, und noch eine, und noch eine, bis man bei 150 angelangt ist. Wenn man sich jedoch die kombinatorischen Auswirkungen vor Augen führt, wird man niemals alle möglichen Fälle testen können, in denen sich all diese Aspekte miteinander kombinieren lassen. Deshalb – und das ist gut für die Branche – treibt die Elektrifizierung und andere Trends diese Entwicklung voran. Das berühmte CASE, richtig: Connected, Autonomous, Shared und Electrified, plus User Experience. Diese Konsolidierung findet gerade statt.

Software effektiv konsolidieren, ohne sie zu überfrachten

STEFANO: Und es ist, ehrlich gesagt, ein Segen für die Branche, dass das Problem darin besteht, die Software, die sich in diesem gesamten verteilten System befindet, umzugestalten und in diesen konsolidierten Einheiten zusammenzufassen. Aber – und hier gibt es ein „aber“ –, denn es ist sehr wichtig, nicht einfach zu sagen: „Okay, wisst ihr was, jetzt haben wir die Software in dieser ECU, ich nehme sie einfach und packe sie in meine konsolidierte Einheit.“ Das ist Bloatware. Das ist sozusagen eine Zeitbombe. Man muss das System neu architektonisieren, denn die konsolidierte Einheit unterscheidet sich grundlegend von einer einzelnen, kostenoptimierten ECU. Und was die Ressourcen angeht, wurde die Software dort wirklich speziell für diese fast maßgeschneiderte Hardware entwickelt. Deshalb sehen wir das so oft – und du weißt ja Bescheid –, zum Beispiel bei unserer Arbeit mit der Autoware Foundation am Open AD Kit: Dabei geht es darum, die Software – in diesem Fall für das autonome Fahren, die klassisch monolithisch ist, wie wir sagen, ein „Monolith“ – in Microservices aufzuteilen, um sie neu zu strukturieren, damit sie von einer Hardware- und Softwareplattform unterstützt wird, die wirklich mehr Modularität und Flexibilität erfordert. Differenzielle Updates, richtig? Standardisierung der Schnittstellen. Und all das sind äußerst wichtige Konzepte, um die gesamte Automobilbranche neu zu gestalten.

SOAFEE und Standards für die Automobilindustrie

JOHN: Weißt du, was du gerade angesprochen hast, passt sehr gut zu dem Gespräch, das wir kürzlich mit Robert Day über SOAFEE geführt haben. Und was SOAFEE angeht – ich weiß, dass Amazon ein Gründungsmitglied von SOAFEE war, du bist also ein großer Befürworter dieser Initiative. Ein Großteil dessen, was SOAFEE anstrebt, besteht darin, einige dieser Standards und einheitliche Schnittstellen bereitzustellen, die du erwähnt hast. Aber vielleicht ist das ein Thema für ein anderes Mal.

STEFANO: Ja, auf jeden Fall, das ist übrigens ein wirklich bereicherndes Gespräch. Ich finde, SOAFEE ist eine fantastische Initiative. Und wenn man sich das genauer ansieht: SOAFEE soll eine Referenzimplementierung auf Basis offener Standards und Open Source bereitstellen. Oh Mann, wir brauchen doch so viele offene Standards und Open Source in der Automobilbranche, oder? Deshalb sind Initiativen wie Yocto, COVESA, Eclipse SDV und AUTOSAR auch so unglaublich wichtig. Und eines der wirklich positiven Zeichen, die wir bei SOAFEE beobachten, ist, dass wir anfangen, zusammenzuarbeiten, oder? Und darauf müssen wir bestehen, oder? Wirklich, denn offene Standards sind entscheidend – man konkurriert nicht um Standards. Das geht gar nicht, richtig? Man konkurriert erst – wenn die Standards definiert sind –, dann kann man anfangen, Innovationen zu entwickeln, und zwar für die Dinge, die der Kunde wirklich, wirklich braucht und will – und das ist nicht der Standard. Wer auch immer sagt: „Ah, ja, ich kaufe dieses Auto, weil dieser Standard perfekt umgesetzt ist.“ Das ergibt keinen Sinn. Richtig?

JOHN: Genau. Es geht darum, über die Standards hinaus eine Differenzierung durch Mehrwert zu ermöglichen, dabei aber die Standards als Grundlage zu nutzen.

STEFANO: Als Grundlage. Klar, auch das ist wieder eine Möglichkeit, Kosten zu sparen und zu optimieren. Warum sollte man Zeit und Geld darauf verwenden, sich bei einer Standardfunktion von der Konkurrenz abzuheben, oder?

JOHN: Wenn euch die Folge bis hierhin gefällt, würde ich euch gerne dazu ermutigen, sie mit „Gefällt mir“ zu markieren und unseren Kanal unter The Garage zu abonnieren, um weitere Inhalte von uns zu sehen. Wir drehen etwa alle zwei Wochen eine neue Folge und würden uns freuen, euch bei der nächsten Folge wieder hier begrüßen zu dürfen.

Thema 4: Maschinelles Lernen und Analytik

JOHN: Also, Stefano, wir haben über so viele verschiedene Bereiche gesprochen. Als Nächstes würde ich gerne über künstliche Intelligenz, maschinelles Lernen und ganz allgemein über Datenanalyse sprechen, denn wir haben über diesen unglaublichen Data Lake gesprochen, den wir zusammenstellen, wir haben über die Rechenkapazitäten in den Spezialdiensten gesprochen, die ihr bei den speziellen Rechentypen anbietet, und so weiter. Und über die Bedeutung von Prototyping und so weiter. Aber dieser gesamte Bereich des maschinellen Lernens und der Analytik ist vielleicht einer der faszinierendsten – eine Kombination aus all diesen Dingen, die etwas leisten kann, was zuvor noch nie möglich war.

STEFANO: Auf jeden Fall. Und das immer im Hinblick auf das, was wir den „Big Loop“ nennen, oder? Das ist extrem wichtig, denn man hört ja oft, dass Wissenschaftler betonen, der Datensatz sei das Wichtigste, um die Modellierung richtig aufzubauen, nicht wahr? Das nehmen wir also immer als Maßstab. Es geht also darum, die richtigen Daten auszuwählen, die in der Cloud gespeichert werden sollen.

Datenerfassung und Annotation mit SageMaker

STEFANO: Also brauchen wir ein bisschen künstliche Intelligenz in Autos, um je nach Situation zu unterscheiden, was relevant ist, oder? Vielleicht hast du eine Vollbremsung gemacht. Warum also, oder es gibt eine Kombination von Faktoren. Oder es gibt Tests im Fahrzeug – über diese superwichtige Funktion werden wir gleich sprechen. Aber wie auch immer: Wenn die Daten ausgewählt sind, braucht es dort ein wenig maschinelles Lernen, das aktualisiert werden muss, oder? Wir senden die Daten, sammeln sie, bereinigen sie, organisieren sie im Data Lake – perfekt. Dann nutzen wir einen Teil dieser Daten, um einen Teil davon zu annotieren, richtig. Unsere Kunden annotieren die Daten also für ihre eigenen Zwecke – wir haben dafür Tools, die sich „SageMaker Ground Truth“ nennen. Und sobald die Daten annotiert sind, nutzen wir sie, um die Modelle zu trainieren und zu validieren. Hier stehen uns verschiedene Optionen zur Verfügung. SageMaker ist unsere Plattform dafür.

Weitere Frameworks für maschinelles Lernen in AWS

STEFANO: Wenn man sich wirklich intensiv mit maschinellem Lernen auskennt, kann man grundlegende Frameworks wie beispielsweise PyTorch nutzen und sich dort wirklich auf der tiefsten Ebene bewegen – oder man kann andererseits sogenannte „ AI “-Dienste nutzen. Das sind Dienste wie beispielsweise die Objekterkennung, bei denen man einfach ein Bild hochlädt und eine Liste der darin enthaltenen Objekte erhält. Genau, also Transkriptions- AI -Dienste. Wir haben also diese drei Ebenen.

Validierung neuer Modelle im Fahrzeug

STEFANO: Wenn man sein Modell über SageMaker trainiert, stellt man es in der Regel am Edge bereit, aber auch hier handelt es sich um einen großen Kreislauf. Es ist also bereitgestellt, aber noch nicht in der Produktion. Es dient zum Testen im Fahrzeug. Es gibt eine weitere Version dieser Software, die derzeit in Produktion ist. In der ersten Phase geht es also darum, zu analysieren, ob dieses Modell im Vergleich zu dem in Produktion befindlichen eine schlechtere oder bessere Leistung erbringt, indem man es realen Bedingungen aussetzt – möglicherweise in einer großen Anzahl von Fahrzeugen da draußen –, da wir durch den Rechner eingeschränkt sind. Wir haben also etwas mehr Rechenleistung zur Verfügung, sodass man dort zusätzliche Berechnungen durchführen kann.

Randfälle aufspüren

STEFANO: Genau, wie du schon gesagt hast: Um die Sonderfälle da draußen zu finden – die sogenannten „Edge Cases“ –, ist es unmöglich, sie im Vorfeld abstrakt zu erdenken. Man braucht wirklich die Autos, und zwar viele davon, um die Leistung eines Machine-Learning-Modells zu validieren. Und wenn man das bewertet und feststellt, dass das Modell besser ist und es keine Regression gibt, stellt man darauf um, setzt es in der Produktion ein, und der Kreislauf geht weiter, oder? Und zwar bei einer immer größeren Anzahl von Fahrzeugen, richtig? Man sieht also, dass maschinelles Lernen nicht einfach nur eine Art Zaubermethode zum Trainieren ist. Es ist vielmehr dieser intelligente Kreislauf. Und es ist sehr wichtig, die Arbeitsabläufe zu definieren. Wir verfügen über zahlreiche Tools, um diese Arbeitsabläufe zu verwalten. Einige davon sind bereits in SageMaker selbst enthalten.

Tools zur Verwaltung von ML-Workflows

STEFANO: Was andere Bereiche betrifft, zum Beispiel das Datenmanagement: Wir verfügen über eine Implementierung und eine verwaltete Implementierung von Airflow, die als „Managed Workflow with Apache Airflow“ bezeichnet wird. Und damit stellen wir all diese Workflows zusammen, richtig? Ich habe Airflow bereits in meinem vorherigen Job genutzt – es ist ein sehr leistungsstarkes Tool, um solche Pipelines zu erstellen. Richtig? Und das ist ein sehr, sehr wichtiger Teil davon. All dies nutzen unsere Kunden häufig in sogenannten Workbenches. Immer mehr Kunden bitten uns, ihnen einen Bereich im Browser bereitzustellen, in dem sie ihre Tools finden können. Diese Tools können Datenpipelines sein, Workflows, Daten im Zusammenhang mit maschinellem Lernen, Zugriff auf den Data Lake oder auf branchenspezifische Tools. Erst kürzlich haben wir beispielsweise auf der dSPACE-Veranstaltung eine Zusammenarbeit mit MathWorks vorgestellt, bei der diese Workbench-Umgebung zum Einsatz kam. Sie finden diese Tools also dort in diesem Bereich. Und damit haben Sie die Möglichkeit, sehr fokussiert zu arbeiten, eine einheitliche Umgebung zu schaffen, diese Umgebung global bereitzustellen, globalen Zugriff auf diese Umgebungen zu ermöglichen sowie Integrationen und Automatisierungen zu erstellen. Kürzlich hat unser CEO auf LinkedIn gepostet, dass Toyota durch diesen Ansatz jährlich 10 Millionen Dollar eingespart hat. Das ist doch nicht schlecht, oder? Einfach nur die Tools zu organisieren und über eine gemeinsame Schnittstelle bereitzustellen, mit der Möglichkeit, daraus Automatisierungen zu erstellen.

JOHN: Was ich an dem, was du gesagt hast, interessant finde, ist, dass es verschiedene Aspekte gibt: Da ist zunächst einmal der Ausgangspunkt – die Daten, die Rohdaten –, dann die Fähigkeit, Modelle zu erstellen, zu optimieren und zu verbessern. Und sobald man das hat, stehen in der Cloud all diese verschiedenen Tools und Module zur Verfügung, die miteinander verknüpft werden können, um die Nachbearbeitung und Nachanalyse durchzuführen. Und davon gibt es viele verschiedene Arten. Dieser gesamte Kreislauf ist meiner Meinung nach wirklich wichtig.

STEFANO: Auf jeden Fall, ja. Und deshalb haben wir das beispielsweise organisiert und über unser Daten-Framework für autonomes Fahren veröffentlicht – eine Open-Source-Initiative, mit der wir versuchen, unseren Kunden Open-Source-Referenzmaterial an die Hand zu geben, um solche Konstrukte und Workflows zu erstellen. Und ja, unsere Kunden nutzen den Großteil dieses Tools tatsächlich genau auf diese Weise im Rahmen eines Workflows – Kunden wie Toyota beispielsweise, die unsere P-Instanzen nutzen, um sich mit unserer Rechenumgebung zu verbinden und das Modell in AWS zu trainieren. Aber noch einmal: Es handelt sich nicht um eine einzelne, isolierte Aktivität. Das ist nur ein Teil eines Workflows. Und das muss unbedingt berücksichtigt werden.

Thema 5: ADAS und autonomes Fahren

JOHN: Und vielleicht ist jetzt der perfekte Zeitpunkt, um zum letzten unserer Themen überzugehen, nämlich ADAS und autonomes Fahren – ein Bereich, an dem wir mehrere Jahre lang gemeinsam gearbeitet haben und in dem wir über umfangreiche Erfahrung verfügen. Lassen Sie uns darüber sprechen, wie wichtig – ich würde sogar sagen: unverzichtbar – die Cloud für die Weiterentwicklung von ADAS ist und welches Potenzial dieser Weg birgt, den wir alle gemeinsam in Richtung autonomes Fahren beschreiten – ein ziemlich langer Weg, auf dem wir jedoch große Fortschritte machen.

STEFANO: Auf jeden Fall. Und noch einmal: Das ist mir ein großes Anliegen – wir haben ja bereits darüber gesprochen –, mir liegt sehr viel daran, einen schrittweisen Ansatz für autonomes Fahren, autonome Funktionen und Autonomie in Fahrzeugen im Allgemeinen zu verfolgen, nicht wahr?

Kurzfristige Vorteile von ADAS

STEFANO: Denn ADAS-Systeme – sagen wir mal L2 und L3, wie sie als Level 2 und Level 3 bezeichnet werden – bieten heute einen enormen Mehrwert. Und das ist sehr wichtig, denn vor allem retten sie Leben. So einfach ist das. Stimmt’s? Wir haben das Auto kürzlich mit ADAS der neuesten Generation getestet, und es ist fantastisch. Es ist ein Auto, das wirklich über Systeme für die automatische Notbremsung verfügt. Wenn man zum Beispiel abgelenkt ist und ein Hindernis auftaucht, bremst das Auto. Ganz einfach, aber wenn es funktioniert, rettet es Leben. Das ist für mich also ein extrem wichtiger Aspekt. Und ich bin immer mehr davon überzeugt, dass Autonomie eine Sammlung dieser Funktionen sein wird, die nach und nach automatisiert werden, oder? Daher ist es wichtig, zusätzlich über schrittweise Funktionen nachzudenken, die in den Fahrzeugen automatisiert werden. Das ist meine Sichtweise dazu. Und die Art und Weise, wie wir die Cloud nutzen – wiederum unter Einbeziehung all dessen, was wir besprochen haben, also im Wesentlichen die Vielfalt der Rechenoptionen, die Möglichkeit dieser Data Lakes, die Konstrukte von Data Lakes und die Machine-Learning-Tools –, das sind die grundlegenden Dinge, die für ADAS und die Entwicklung autonomer Fahrzeuge benötigt werden. Es gibt noch einen weiteren Aspekt der Rechenoptionen, der aus zwei für ADAS spezifischen Gründen sehr, sehr wichtig ist: Man sammelt häufig Daten aus dem Feld und speichert sie in S3 im Data Lake. Und dann nutzt man sie zur Validierung, richtig? Man spielt also typischerweise die aus den Fahrzeugen gesammelten Daten in den in der Entwicklung befindlichen Algorithmen ab, um zu beurteilen, ob sie besser oder schlechter sind als die der vorherigen Generation. Oder man nutzt Rechenleistung, um auf der anderen Seite synthetische Simulationen durchzuführen. Wir haben einen wunderbaren Anwendungsfall mit Valeo, den wir leider auf der wegen COVID ausgefallenen CES vorgestellt haben, zu der niemand gekommen ist. Wir hatten jedoch diese großartige Demo vorbereitet – es gibt ein Video dazu auf YouTube, den Link können wir natürlich einfügen –, in der man sieht, wie Valeo zwei Technologien einsetzt: zum einen IPG CarMaker und zum anderen Foretellix, um, wie Sie wissen, die Anzahl der Szenarien durch synthetische Simulation zu vervielfachen und diese auf Tausende verschiedener Szenariovarianten auf AWS zu erweitern, da man dort über Skalierbarkeit, Rechenelastizität und Rechenverfügbarkeit verfügt, um dann wirklich alle diese Randfälle abzudecken und im Grunde zu untersuchen, ob in unserer Analyse etwas fehlt, richtig?

Suche nach Randfällen

STEFANO: Und wir versuchen, sozusagen „nach links zu verschieben“ – genau wie wir es besprochen haben –, die Lösung dieses Problems zu finden, bevor die Software in die Fahrzeuge selbst gelangt, richtig? Es geht also wiederum darum, diese Arbeitsabläufe neu zu gestalten, und bei AWS verfügen wir über alle Tools, die es unseren Kunden ermöglichen, dies zu tun. Und falls nicht, arbeiten wir gerne mit unseren Kunden zusammen, um sie zu entwickeln.

Das autonome Fahren in seine Bestandteile zerlegen

JOHN: Auf jeden Fall. Und ich glaube, viele Leute denken vielleicht, dass das autonome Fahren eine monolithische Aufgabe ist. Tatsächlich gibt es aber sehr, sehr viele Teilaufgaben. Ich scherze gerne, dass es zum Beispiel die Erkennung von Fahrrädern und die Spurhaltung gibt. Aber Spaß beiseite – es gibt viele verschiedene Aufgaben. Man muss das Ganze wirklich zerlegen, weißt du, so wie wir fahren: Wir fahren einfach und das war’s. Tatsächlich zerlegen maschinelles Lernen und künstliche Intelligenz das Ganze jedoch in verschiedene Teile. Und was du vor einer Minute erwähnt hast, finde ich sehr interessant. Denn wenn man über das Training nachdenkt – wenn man das Fahren aus der Perspektive eines Menschen betrachtet –, ist es die meiste Zeit ziemlich langweilig: Man fährt einfach immer geradeaus, und das ist langweilig. Das Schwierige an den Dingen, die man üben muss, ist also nicht so sehr, dass es vielleicht eine scharfe Kurve oder ein Hindernis gibt, sondern – wie du so treffend gesagt hast – dass man die Randfälle beschleunigen kann, um mir unzählige Randfälle zu liefern, damit das Modell viel schneller lernt, als es in einer realen Fahrsituation möglich wäre.

STEFANO: Auf jeden Fall, auf jeden Fall. Das stimmt absolut. Und deshalb sind beispielsweise, wie wir bereits besprochen haben, Microservices aus dieser Perspektive wichtig, denn vielleicht möchte man ja nur das Wahrnehmungsmodell austauschen, den Rest aber so lassen, wie er ist, richtig? Es geht also darum, dass verschiedene Teams mit unterschiedlichen Kompetenzen an ihrem kleinen Teil arbeiten, richtig. Das ist also ein äußerst wichtiger Aspekt: die unterschiedlichen Rollen zu erkennen, die bei der Entwicklung von ADAS oder autonomen Fahrzeugen eine Rolle spielen. Ein äußerst wichtiger Aspekt, nicht wahr? Es ist also in der Tat ein komplexes Szenario. Aber auch hier haben wir gute Referenzen vorzuweisen. Der Fall, den ich im Zusammenhang mit Continental beschrieben habe, betraf die ADAS-Entwicklung, und man sieht wirklich, welche Vorteile sie in Bezug auf Zeitersparnis, Kosteneinsparungen und Agilität erzielt haben. Bei der Einführung eines Cloud-nativen Ansatzes, nicht wahr? Das war die Absicht dieser CAEDGE-Übung, die wir gemeinsam mit ihnen entwickelt haben. Das geschah übrigens ebenfalls im Rahmen eines Software-Defined-Vehicle-Projekts. Das ist also ein großartiges Referenzbeispiel. Unsere Zusammenarbeit mit Continental war wirklich der Ausgangspunkt, an dem wir begonnen haben, über die meisten dieser Konzepte nachzudenken. Eine wirklich großartige Zusammenarbeit.

Zusammenarbeit zwischen AWS und Sonatus

JOHN: Zum Abschluss unseres Gesprächs dachte ich, wir könnten uns einen Moment Zeit nehmen, um über einige Bereiche zu sprechen, in denen „ Sonatus “ und AWS zusammenarbeiten.

STEFANO: Ja, sehr gerne, denn ich habe ja bei „ the garage “ einige beeindruckende Demos gesehen – vielen Dank übrigens, dass du sie mir gezeigt hast. Und es ist einfach unglaublich, oder? Einige der Funktionen, die ich gesehen habe – zum Beispiel die Steuerung der Fahrzeuglogik und die Bereitstellung neuer Logik entsprechend der jeweiligen Situation – entsprechen genau dem, was wir im Zusammenhang mit SDV und „Big-Loop-Updates“ besprochen haben. Man sieht also wirklich, wie das in die Praxis umgesetzt wird. Das ist wirklich fantastisch zu sehen. Und ja, es ist eine großartige Zusammenarbeit. Und es ist ein perfektes Beispiel. Man sieht: Es geht nicht nur darum, Daten zu senden oder zu sammeln, sondern man beginnt, diese Sichtweise einer Datenebene umzusetzen – ja, wir müssen Daten sammeln, aber auch für die Steuerungsebene. Die Möglichkeit also, diese Mikrologik zu verwalten – von der Cloud zum Edge und zurück –, erfordert, dass man über einige dieser Mikrologiken verfügt, vielleicht etwas maschinelles Lernen am Edge, und man muss einige dieser Mikrologiken oder maschinellen Lernverfahren in der Cloud anwenden. Und wenn man an Konsolidierung denkt, wenn man an Arm-Kerne denkt – wissen Sie, es ist ein System, von dem wir sagen, dass es ein Kontinuum zwischen der Cloud und dem Edge darstellt. Und ich finde, Sie leisten wirklich hervorragende Arbeit bei der Umsetzung dieser Vision mit Ihrer Produktreihe.

JOHN: Weißt du, vielen Dank. Wir haben vorhin über Daten gesprochen, und wie du weißt, ist unser Collector-Produkt sehr gut optimiert: Es sammelt, filtert und wählt sorgfältig Daten aus – hochwertige Daten – und sendet sie in die Cloud, und daran arbeiten wir gemeinsam mit euch. Und dann gibt es da noch das Automator-Produkt, das du gerade erwähnt hast und das wir kürzlich auf den Markt gebracht haben. Damit können wir das Konzept der intelligenten Daten nutzen, um dann Maßnahmen zu ergreifen – sei es innerhalb des Fahrzeugs oder außerhalb des Fahrzeugs. Wir sind noch nicht wirklich auf das Thema Fahrzeugtests eingegangen, aber auch das Problem der Fahrzeugtests wird immer komplexer. Daher freuen wir uns darauf, dies auf neue Weise nutzen zu können, um beispielsweise den Produktionsablauf zu verbessern und bessere nachgelagerte Dienste anzubieten. Sie haben zuvor vernetzte Fahrzeuge im Zusammenhang mit nachgelagerten Funktionen für den Nutzer und sogar für Anbieter von Mehrwertdiensten in der Branche erwähnt.

Die Bedeutung der Verwendung echter Steuergeräte

STEFANO: Ja, und das ist wirklich interessant. Und das ist ein weiterer super guter Punkt, der mir aufgefallen ist, weil ihr das an echten Steuergeräten macht. Und glaub mir, das ist ein riesiger Unterschied, denn ich sage immer: Man muss bedenken, dass bei der Entwicklung neuer Software- oder Hardwarekomponenten für die Automobilindustrie 50 % auf die Entwicklung entfallen. 50 % entfallen auf V und V [Verifikation und Validierung]. Nehmen wir im Fall von ADAS und AV einmal einige Annahmen vor. Bei ADAS liegt das Verhältnis meiner Meinung nach wahrscheinlich bei 20 zu 80. Bei autonomen Fahrzeugen (AV) liegt das Verhältnis bei 1 zu 99. Richtig? Denn V und V spielen wirklich eine große Rolle, und das merkt man, wenn der Code tatsächlich auf echten CPUs läuft – das ist etwas ganz anderes, oder? Es handelt sich nicht mehr nur um einen Prototyp auf dem Schreibtisch, der auf einem Evaluierungskit basiert. Sondern um etwas, das in einer Million, zwei Millionen oder zehn Millionen Fahrzeugen zum Einsatz kommt. Das macht den entscheidenden Unterschied aus.

JOHN: Du hast recht. Und wir freuen uns riesig, dass wir – wie du weißt – bis dieses Jahr in Dutzenden von Modellen vertreten sein werden und bis Ende nächsten Jahres in Millionen von Fahrzeugen. Es ist also spannend zu sehen, dass es sich hier nicht um einen Prototyp oder ein Forschungsprojekt handelt, sondern um echte Serienproduktion. Und aus der echten Serienproduktion lernt man viel – dort, wo es sozusagen auf die Probe kommt. Das macht es um einiges schwieriger.

STEFANO: Ja. Und jeder, der in der Automobilbranche tätig ist, weiß, wie viel Aufwand es kostet, die Vorschriften einzuhalten. Das ist ein wesentlicher Bestandteil dieser Branche, oder? Man kann also nicht einfach Code bereitstellen, wie man es bei Smartphones tut. Richtig? Es handelt sich nicht um ein Verbrauchergerät, sondern um ein reguliertes Produkt, bei dem funktionale Sicherheit und Cybersicherheit eine Rolle spielen. Und das sind Aspekte, die von größter Bedeutung sind. Und für uns wirklich wichtig. Das hat oberste Priorität, Priorität Null.

Zusammenfassung

JOHN: Ja, wir haben heute so viele Themen angeschnitten, dass wir zu jedem einzelnen der angesprochenen Unterthemen noch viele weitere einstündige Gespräche führen könnten, aber für heute müssen wir nun zum Schluss kommen. Zunächst einmal möchte ich dir ganz herzlich dafür danken, dass du heute hier warst, Stefano. Es war mir eine Freude, dich zu Gast zu haben. Ich habe in unserem heutigen Gespräch so viel gelernt, und ich unterhalte mich immer sehr gerne mit dir. Ich hoffe, du kommst wieder einmal bei uns vorbei.

STEFANO: Gleichfalls, danke für die Einladung. Es ist mir immer eine Freude. Ich habe selbst viel gelernt. Einfach fantastisch.

JOHN: Danke, Stefano. In der heutigen Folge haben wir also alle Aspekte der Cloud besprochen, insbesondere im Zusammenhang mit AWS, und darüber gesprochen, wie die Cloud den Automobilsektor und die Arbeitsabläufe im Fahrzeugbereich bereichern und verbessern kann – angefangen bei den Daten und ihrer Bedeutung bis hin zu den vielfältigen Möglichkeiten, Daten zu nutzen. Wir haben über „Compute“ gesprochen und den Bedarf an verschiedenen Arten von Rechen-Services zur Lösung unterschiedlicher Problemstellungen. Wir haben über Prototyping gesprochen, insbesondere über die Möglichkeit, Fahrzeugfunktionen in der Cloud zu prototypisieren und in ein echtes Fahrzeug zu implementieren – was sehr überzeugend ist. Wir haben über maschinelles Lernen und Analytik gesprochen und darüber, wie Datenanalytik genutzt werden kann, um auf vielfältige Weise einen Mehrwert zu schaffen. Und schließlich haben wir ganz kurz das autonome Fahren und ADAS angesprochen und darüber, wie wichtig es ist, diese Bereiche zu verbessern und den Ablauf zu optimieren. Das war ein sehr breit gefächertes Gespräch. Ich hoffe, es hat Ihnen gefallen, und wir freuen uns darauf, Sie schon bald in einer weiteren Folge von „ The Garage “ wiederzusehen. Vielen Dank.