Red Hat Summit Special - Automotive im Spannungsfeld von KI, Edge und Cybersecurity

Und dann wird das Auto aus dem Verkehr gezogen, verschrottet oder was auch immer. Jetzt muss man sich vorstellen, je nachdem, was für ein Steuergerät das ist, gehen wir mal davon aus, das ist jetzt ein Infotainment-Steuergerät. Das heißt, das hat auch irgendwie eine Sichtbarkeit zu dem Endnutzer. Da hast du dann irgendwie bestimmte Apps, die du runterladen kannst oder du kannst verschiedene Online-Services dort anfragen. Dann brauchst du hierfür natürlich gewisse kryptografischen Keys, sag ich jetzt mal auch. Also wenn du zum Beispiel jetzt ein Fahrzeug hast von VW, einfach nur so als Beispiel, dann verbindet sich das Infotainment-System mit dem Backend-Service von VW. Das muss natürlich sich auch authentifizieren, dass es überhaupt ein valider Zugriff ist, dass der Nutzer auf die Inhalte von VW zugreifen kann und dass dann entsprechend auch die Inhalte sicher und verschlüsselt beispielsweise auf das Fahrzeug, auf das Infotainment-System kommen. Und Krypto ist jetzt ja nicht wie ein guter Wein, der beim Kunden nachreift und besser wird. Genau. Genau das Gegenteil. Ja, und da ist tatsächlich ein sehr, sehr großer organisatorischer Aspekt mit drin. Wie händelst du die ganzen Krypto-Keys? Wie kommen die auf das Steuergerät drauf? Und deswegen musst du tatsächlich Security ganz früh im Entwicklungsprozess schon berücksichtigen. Das heißt, was für Keys brauche ich dann dort? Wo kommen die her? Spätestens dann will ich dann auch noch Supplier mit drin habe, die zum Beispiel das Steuergerät zuliefern für den Hersteller, die das gar nicht selber bauen. Und da musst du diesen ganzen Cybersecurity-Prozess tatsächlich am Anfang im Requirements Engineering mit berücksichtigen. Dann in der Entwicklung musst du natürlich dann auch entsprechende Risikoanalysen machen. Wie schützt du die Keys dann später im Fahrzeug? Durch welche technischen Maßnahmen? Dann baust du das Steuergerät oder das Fahrzeug. Da werden natürlich dann die, ich bleibe jetzt mal bei deinem Beispiel der Keys, da werden die dann, man sagt sich, injected, teilweise im Produktionsprozess. Du machst das halt sehr nah am Steuergerät, tatsächlich physisch, um auch die Integrität und Vertraulichkeit dieser Keys zu gewährleisten. Dann hast du das Fahrzeug gebaut und das Fahrzeug ist ja dann unterwegs mit diesen Keys. Und das heißt, wenn jetzt irgendwie ein Angreifer Zugriff auf diese Keys bekäme, hätte er die Möglichkeit dann auch die Online-Services des Herstellers direkt, sagen wir mal, anzufragen. Und zum Beispiel die Inhalte, die dann von dem Backend zurückkommen, auf zum Beispiel ein anderes System umzuleiten. Also ganz typischer Beispiel, oder vielleicht irgendwie, um sich das zu versinnbildlichen. Es gab ja mal eine Zeit, da wurden explizit Navigationsgeräte aus Autos geklaut. Um die dann zum Beispiel in irgendwelchen anderen Fahrzeugen... Oder auch Radios, oder? Radios, Navigärte, um die dann zum Beispiel in irgendwelchen, ja, sagen wir mal, grauen Schwarzmarktsphären dann in andere Autos einzubauen. Und das wäre zum Beispiel durch diese Maßnahmen nicht mehr möglich, weil dann die Keys nicht mehr zu einem Fahrzeug passen, passen nicht mehr zu einem anderen Steuergerät verwund und sind teilweise auch gar nicht extrahierbar aus dem Device. Und Cybersecurity geht eben auch noch darüber hinaus, hätte er anfangs gesagt, das hört dann eigentlich auf, wenn das Fahrzeug verschrottet wird, weil man muss ja auch sicherstellen, wie ist denn dann die Dekommissionierung. Also wenn ich dann das Fahrzeug wirklich auf dem Schrottplatz habe, muss ich ja davon sicher ausgehen können, dass selbst wenn es auf dem Schrottplatz ist und zugreifbar ist für andere, dass dann davon keine, sagen wir mal, Gefahr für den Hersteller oder für den Betreiber der Flotte ausgeht. Und wie lange kann ein Autohersteller jetzt in der Pflicht sein, für die Cyber-Sicherheit von einem Auto zu sorgen, weil ich kriege vielleicht eine Herstellergarantie von fünf Jahren Abkauf, du sprichst aber von 20, 30 Jahren, die ein Auto unterwegs ist. Gibt es da dann eine Cybersecurity-Anschlussverpflichtung-Garantie? Ja, also hier ist das Gute, dass die Cybersecurity tatsächlich über die gesetzlichen zwei Jahre hinausgeht. Der Hersteller ist für den Betrieb und die Dekommissionierung des Fahrzeugs verantwortlich. Das heißt, solange das Fahrzeug auf der Straße ist, bewegt wird und nicht nur jetzt du als Besitzer des Fahrzeuges das Fahrzeug nützt, sondern auch der Nachfolger, solange wie es wirklich jetzt auf der Straße ist, muss der Hersteller sicherstellen können, dass auch später gefundene Vulnerabilities in den Komponenten, in seinen Fahrzeugen gefixt werden können. Dafür muss er geeignete Maßnahmen ergreifen können, dass er in der Lage ist, zum Beispiel jetzt, wir wissen ja noch nicht, was in fünf Jahren für Vulnerabilities offen gestellt werden, die bestimmte Fahrzeugtypen, Steuergeräte, sonstiges betreffen, aber er muss sozusagen jetzt schon die Vorkehrungen treffen, um dann darauf reagieren zu können, um sozusagen, bis das Fahrzeug wirklich dann dekomissioniert wird, auf dem Schrotplatz landet, dass dann davon keine Gefahr mehr ausgehen kann. Und wenn du heute in einem Steuergerät, in einem Chip auf hardwarebeschleunigte Verschlüsselung setzt, die zeitgemäß ist, wirst du ja gar nicht sicherstellen können, dass die in 10, 15 Jahren noch upgradebar ist auf eine dann zeitgemäße Verschlüsselung, oder? Richtig, ja. Das ist ein sehr großes Problem. Man spricht ja heutzutage auch von diesen sogenannten Post-Quantum Cryptography. Also die Quantencomputer werden ja immer, sagen wir mal, handhabbarer, immer praktikabler einsetzbar. Und das ist gerade ein ziemlich großes Thema, was eben auch schon wieder in dem Entwicklungsprozess direkt mit berücksichtigt werden muss, weil die Laufzeit von so einem Fahrzeug ist ja sehr lang, teilweise 20, 30 Jahre. Genau die Frage, die du gerade gestellt hast, stellt sich auch für die Hersteller, welche Algorithmen kann ich einsetzen, damit ich bis zu einem gewissen Datum eine ausreichend hohe Security habe? Weil, wie du schon sagst, wir sprechen hier von Steuergeräten, das ist jetzt nicht vergleichbar wie mit einem Windows-Betriebssystem, was dann einfach, sobald es im WLAN ist, automatisch Updates zieht, sondern wenn das Fahrzeug mehrere Monate in der Tiefgarage steht, empfängt das keine Updates. Und teilweise ist es ja auch so, dass die Hardware auch gar nicht mehr, die bleibt ja so wie sie ist und wenn die Softwareanforderungen stetig wachsen, dann kann irgendwann die Hardware nicht mehr mithalten. Aber in deinem Windows-Beispiel genauso, mein Rechner von 1995, da geht auch mangels TPM2-Modul kein Windows 11 drauf, ob ich das nicht wollen würde, aber genau, ist ja schwierig. Aber es ist spannend, weil es ja im Endeffekt ja auch bedeutet, so rein vom Softwareentwicklungsprozess, ihr müsst ja eine unglaubliche Bandbreite auch an, ich sag mal, API-Kompatibilität irgendwie bieten. Weil es ja durchaus auch sein kann, dass in fünf Jahren trotzdem noch mal irgendwo aus dem Keller eine Version 0.8 auftaucht, die sich dann irgendwie anmelden will, wo dann Dinge passieren müssen. Und das irgendwie so zu managen, dass da die Schnittstellen überhaupt über so einen langen Lebenszyklus kompatibel bleiben, ist auch eine Herausforderung, oder? Das ist eine riesengroße Herausforderung und die stellt sich insbesondere jetzt gerade, wo, sage ich mal, sehr viel Bewegung in dieser ganzen Automotive-Welt drin ist. Wir sehen jetzt immer mehr neue, sagen wir mal, Konkurrenten am Markt mit Tesla, einfach so als Paradebeispiel genannt, oder auch viele chinesische Hersteller, die ihre Fahrzeug auf komplett grüner Wiese gebaut haben. Das heißt, die konnten sozusagen ihre Architektur an die heutigen Gegebenheiten anpassen und direkt darauf designen. Hingegen, wenn du jetzt einen traditionellen Hersteller hast, der hat natürlich seine Legacy-Architektur. Ja, auch Fertigungsprozess. Da steht ja halt, da baut man jetzt sich alles neu. Genau. Und das ist ein riesen Thema. Wie machst du jetzt neue Entwicklungen, neue Steuergeräte kompatibel mit alter Hardware zum Beispiel und umgekehrt? Das ist eins der größten Probleme momentan. Was ich mich auch gefragt habe ist, könnt ihr in dem Feld eigentlich überhaupt Homeoffice machen? Weil das Testgerät ist ja dann wahrscheinlich, wie sieht so ein Pentester für so Fahrzeuggeschichten, wie sieht dein Homeoffice-Setup aus? Das ist wahrscheinlich nicht nur ein Laptop, sondern vielleicht auch noch andere Dinge drumherum, oder? Also ich selber teste nicht. Ich bin der Produktmanager für unser Testing-Portfolio global. Die ETHAS hat ja mehrere Standorte weltweit, nicht nur in Deutschland. Und meine Aufgabe ist es sicherzustellen, dass wir ein abgestimmtes, global verfügbares, wettbewerbsfähiges Portfolio haben. Und das eigentliche Testing geschieht dann durch unsere Tester-Teams. Wir haben zum Beispiel einen Testlab in München, wir haben einen in Yokohama, in Japan, in Korea und in den USA. Zurückkommend auf deine Frage, ja, also Homeoffice ist da tatsächlich begrenzt möglich, weil wenn du physische Hardware hast, brauchst du ein gewisses Setup. Und gerade im Automotive ist es nicht einfach nur, dass ich da einen Laptop stehen habe und auf den An-Knopf drücke und dann fährt der hoch. Teilweise brauche ich dann irgendwie noch eine gewisse Resbus-Simulation. Ich brauche noch andere Steuergeräte, die irgendwie bestimmte Kommunikationsnachrichten schicken, damit andere Steuergeräte wiederum aufwachen, also responsiv sind. Und das war zum Beispiel während Corona durchaus eine Herausforderung, während der Lockdowns. Und es gab dann verschiedene Setups, natürlich immer in Absprache mit den Kunden. Mit Kunden kann man gewisse Hardware nach Hause nehmen. Wenn der Kunde zugestimmt hat, konnte man das machen. Aber manchmal ging es eben nicht. Da musste man dann auch ein bisschen erfinderisch werden, wie irgendwie Zutrittsregelungen, dass sich da keine zwei Leute im selben Raum befinden. Also kann man in eurer Branche auch nicht mal einfach so einen Porsche Taycan mit nach Hause nehmen fürs Homeoffice und dann da in der Garage drinnen rumhacken oder schrauben? Kannste nicht. Willst du, glaube ich, auch gar nicht. Wir haben auch schon Fahrzeug-Tests durchgeführt. Wir gehen eher dazu, zu sagen, wir wollen das sogar bei den Herstellern vor Ort machen. Hintergrund ist einfach der, dass du den Zugriff auf zum Beispiel Ersatzteile sicherstellen möchtest und auch vor allem auf Dokumentation, auf das Ansprechpersonal vor Ort. Weil ein Fahrzeug ist super komplex und wenn du dann irgendwie Zugriff auf eine gewisse Schnittstelle brauchst, einen gewissen Bus und dann ist der Ansprechpartner da nicht da, dann stehst du erstmal da und dann kommst du nicht weiter. Ja, aber ist das so, dass es da dann, also wenn ich mir jetzt so ein Fahrzeug vorstelle, also ich habe schon mal an einem gesessen und da waren irgendwie mehrere Displays drin und dann kann ich mir vorstellen, gibt es irgendwie bestimmt so Dinge, die was mit dem Motor machen, dann hast du eben schon gesagt Entertainment System, da sind ja bestimmt auch noch irgendwie drei, vier andere Systeme mit drin, die dann wahrscheinlich, wenn man das so Security-seitig betrachtet, die ja irgendwie auch voneinander separiert und sowas. Wie viele, also in so einem neu modernen Fahrzeug, wie viele Computer stecken da drin und wie kommunizieren die miteinander oder ist das ein großes Ding und dann passiert da die ganze Magic? Also die gute Nachricht ist, es werden weniger Steuergeräte mit den neuen Fahrzeugen. Ich sag mal so in aktuell herumfahrenden Fahrzeugen, die jetzt so 2, 3, 4, 5 Jahre alt sind, kannst du von 120, 130 Steuergeräten ausgehen in einem Fahrzeug. Je nachdem, was für ein Fahrzeug das ist, welcher Ausstellungstyp und... Was sind da so die... also ich glaube, wenn ich mir jetzt aus meiner IT-Welt ein Fahrzeug vorstelle, nicht auf 120 Funktionen kommen, was sind so Beispiele dafür? Was sind so Steuergeräte? Ja, man versucht auch so eine relativ komplexe Architektur zu unterteilen. Man nennt das Domänen. Aktuell sind die Architekturen auch sehr domain-spezifisch aufgebaut. Das heißt, du hast eine Domäne Antrieb, Powertrain. Das heißt, da sind alle Steuergeräte drin, die irgendwie mit dem Motor zu tun haben, Einspritzverhalten, Getriebe, sonstiges. Genau, dann hast du eine Domäne Infotainment, alles, was der Nutzer sieht, Dashboard, Infotainment, Head-Up-Display, sonstiges. Dann hast du noch eine Domäne, die sich um das Chassis kümmert, also Zugriff, Zugang zum Fahrzeug, Lichter, Blinker. Du hast sogar Steuergeräte, die nur die Aufgabe haben, den Reifenfülldruck zu messen. Ist das dann ein eigenes, also ist der, ja gut, das ist dann der Sensor, der wahrscheinlich irgendwie Ventilkappe oder irgendwie eine Felge mit eingebaut ist. Und das Steuergerät ist dann das, was dann das Signal aufnimmt und mit verwertet. Genau, das ist dann das Steuergerät, nimmt das Signal vom Sensor auf, wandelt das in ein entsprechendes Format um und schickt das dann über den Fahrzeugbus, also das quasi das Rückgrat des Fahrzeuges, den Kommunikationsbus. Meistens ist das immer noch CAN, mittlerweile wird es immer mehr Automotive, Ethernet an andere Steuergeräte, die dann mit der Information irgendwas anfangen können. Ich hab auch gerade bei eBay kleinen zeigen, tatsächlich für mein Auto, Baujahr 2018, einen Spurhalte-Assist in Steuergerät gesehen. Das ist einfach eine kleine Box gewesen für einen Fofi-Volk, den ich auch überlegt habe. Der hat ja noch ein paar mehr Funktionen. Der kann ja Spurhalte, kann ja Abstand und so weiter, sind ja mehr autonome Fahrfunktionen. Dass das eine Feature eine eigene Steuerbox ist, wo wahrscheinlich der Videofeed reinkommt und dann Längssignale rausgehen, ist ja doch sehr modular. Zumindest, du sagst, es werden weniger Steuergeräte, also geht es vielleicht mehr zu einem Got Computer, wo alles zusammenläuft. Aber Baujahr 2018 scheint es noch zu sein, dass das eine einzelne Box ist. Genau. Das sind eben, wie ich schon sagte, momentan ist noch sehr stark dieser Domäne-spezifische Charakter mit drin. Das fließt jetzt immer mehr so ein bisschen zusammen. Man versucht das aufzubrechen, eben weil diese alten Architekturen sehr komplex sind, sehr kleinteilig. Das sind jetzt sogenannte HPCs, also ist da der Begriff diese High Performance Computing Cluster Geräte. Das sind, man kann sagen, Großrechner, auf denen verschiedene Funktionen laufen. Also zum Beispiel ein HPC für Autonomous Driving. Da ist dann wahrscheinlich genau die Box dann irgendwo mit integriert. Ich denke, das wird auch für die Innovationsfähigkeit notwendig sein, dass man das ein bisschen zentralisiert. Das ist auch zentralisiert, weil wenn du diese vielen kleinen Module hast, die kannst du ja auch nicht um neue Funktionen mal ebenso erweitern, wie das bei einem zentralen System, was ein bisschen mehr Puffer nach oben auch leistungstechnisch hat, möglich wäre. Und jetzt kommen wir nämlich auch genau in die Ecke DevOps. Ein großer Vorteil, wenn du diesen Weg gehst, ist, bzw. da geht auch jetzt die Automotive-Industrie immer mehr hin, ist, man möchte diese sehr heterogene Landschaft an Steuergeräten, verschiedene Mikrocontroller, Mikroprozessoren und so weiter, versuchen, so gut wie möglich zu vereinheitlichen. Das heißt, man möchte mehr den Anteil an Software erhöhen, der dann irgendwo die Hardware abstrahieren soll, dass man dann einheitliche Schnittstellen hat, APIs. Und das wiederum vereinfacht dann den kompletten Entwicklungsprozess der Applikationssoftware dann auch. Das heißt, das kann man sich eher so vorstellen wie, wir haben ein komplexes Auto, überall ist Elektronik drin, aber letztendlich laufen die Drähte irgendwo zusammen und da ist dann ein Rechner und ab da kannst du dann machen, was du möchtest in Software. Ist das so die Architektur der Zukunft? Ja, das ist die ganz große Vision. Ganz vermischen wirst du es nicht können, weil du hast trotzdem noch verschiedene Anforderungen in so einem Fahrzeug. Du hast da auch immer eine ganz große Safety-Komponente mit drin. Und das ist ja auch der Grund, warum man diese Domänen getrennt hat, weil man nicht möchte, dass jetzt ein Info-Themen-System, wo irgendwie der Nutzer ein USB-Stick reinsteckt, am selben Bus hängt wie das Motorsteuergerät oder die Bremse. Das heißt, du wirst immer noch irgendwo eine physische und auch logische Trennung zwischen den einzelnen, sage ich mal, fahrbezogenen Schichten haben. Man versucht es aber weitestgehend zu vereinheitlichen. Das ist, glaube ich, auch eine schwierige Sache. Ich meine, ich darf so ein Auto fahren, was irgendwie elektrisch ist und einigermaßen neu modern, wo dann natürlich auch irgendwie Features durchaus nur noch eine Freischaltung von Software gegen Geld sind und sowas kennt man ja irgendwie auch von, weiß ich nicht, Smartphones, wenn man da die Dinge mit Obst als Logo nimmt, dann könnte man auf die Idee kommen, hey, ich fände es eigentlich total toll, einen Spiele-Emulator für die Konsole, meine Lieblingskonsole aus den 90ern, da drauf zu bringen und dann geht das halt nicht, weil der Hersteller sagt, das finden wir irgendwie nicht so doof und der Spiele-Konsole-Hersteller sagt, das finden wir auch irgendwie doof und dann kannst du da hingehen und sagen, ja gut, dann mache ich jetzt halt einen Jailbreak und dann kriege ich mir das alles frei. Kann ich mich daraus, kann ich das irgendwie hacken und durch eine Sicherheitslücke übernehmen und dann vielleicht darüber freischalten? Gleichzeitig habe ich dann in dem Moment so überlegt, ey, so ein Auto, will ich das eigentlich Jailbreaken? Dann bin ich ganz schnell zu dem Schluss gekommen, nein, möchte ich eigentlich nicht, aber es ist ja natürlich für so Tuning-Szene und alles, was da so drumherum passiert, schon auch für manche offensichtlich schon sehr lange ein Grundbedürfnis irgendwie am Auto, Dinge anpassen zu können. Ich glaube, da kannst du irgendwie ein Bodykit dranbauen und dann ein bisschen Tuning machen, aber dann gibt es irgendwie Shiptuning und irgendwie andere Erweiterungen und so Sachen, was dann auch irgendwie ja mit schwieriger wird mit so was, weil du ja gar nicht, du brauchst ja eine ganz andere Kompetenz irgendwie, da schraubst du dich in einen anderen Auspuff ran, sondern da ist das schon schwieriger irgendwie ranzukommen. Definitiv. Also es gibt auch heute schon durch Fahrzeughersteller zugelassene Schnittstellen, für die es dann wiederum auch gewisse Apps gibt, auf die du dich dann theoretisch verbinden kannst. Da bewegst du dich aber immer in dem Raum, der dann auch offiziell zugelassen ist. Aber da passiert ja auch wirklich viel, dass da Schnittstellen möglich sind. Wenn ich mir so überlege, da gibt es auch die ersten Versionen, Apple Cardplay oder Android Auto und so, wo jetzt auch mehr Schnittstellen geschaffen werden, sodass die Navigations-App, die auf dem Smartphone läuft, was dann da gespiegelt wird, auch noch irgendwie Fahrzeuginformationen kriegt, um dann rauszukriegen, was muss ich zwischendurch irgendwie tun. Ich kann mir vorstellen, mit Elektromobilität. Da gibt es, ich habe da schon in einigen drin gesessen, wo ich mir gedacht habe, wie kann das eigentlich sein, dass ich eine 800 Kilometer-Strecke habe und das Auto nicht automatisch weiß, wo es irgendwo laden soll, was dann natürlich auch eine Nische sein kann, die dann die App-Hersteller irgendwie auch mitnutzen können oder nehmen wir mal Ambiente-Licht oder sowas, dass man das eben auch mitsteuern kann. Das sind dann wiederum weitere Zugriffe und ja auch irgendwo Standards, die dann da mit weiterentwickelt wird. Ich würde sagen, für mich als Verbraucher finde ich es eigentlich ganz schön, wenn offene Standards verwendet werden, die es mir dann auch erlauben, jetzt nicht ein Fahrzeug zu kaufen und da nur den Adapter fürs Nokia 3330 drin zu haben und nach 20 Jahren gibt es da halt keinen Adapter irgendwie mehr für, sondern irgendwie ein bisschen was Offenes zu haben. Ich habe so das Gefühl, dass das noch gar nicht so lange überhaupt, weiß nicht, ob es nicht bedacht wird oder zumindest kommt es mir so vor, dass das sehr schwer ist für die Hersteller, sich da zu öffnen und diese Sachen da voranzutreiben, weil es glaube ich ja auch immer was damit zu tun hat, dass die vielleicht eine eigene Domäne aufgeben. Also ich glaube, die haben ja alle irgendwie mal gesagt Radio und das nächste ist dann mal ein Entertainment-System und jeder hat da was angefangen, wo die wahrscheinlich dann auch alle einigermaßen stolz drauf sind, dass das so ist und eigentlich gar nicht wollen, dass da vielleicht jemand anderes das mit übernimmt oder denen da den Rang abläuft oder sowas, kann ich mir auch vorstellen. Definitiv. Da habe ich auch viel drüber gelesen in letzter Zeit, über was du sagst CarPlay oder Android Auto jetzt mal als Beispiel genannt. Die werden in kürzerer Zeit in der Lage sein, im Kombiinstrument, also im Tacho auch mit angezeigt zu werden, statt nur rechts in der Mitte, wo das Infotainment-System sitzt. Du wirst in nächster Zeit sowas wie Klimaanlage einschalten können über sowas funktionieren. Also das ist alles auf dem Weg und das ist ja auch dann für einen Autohersteller eben eine Abwägung. Bringe ich ein Auto auf den Markt, was CarPlay oder Android Auto Unterstützung hat oder eben nicht? Und manche Kunden, und da würde ich mich selber dazu ziehen, würden auf gar keinen Fall in ein Auto investieren, was sowas nicht kann. Andererseits, wenn du es als Autohersteller anbietest, dann hast du möglicherweise aber auch weniger Einfluss auf den Nutzer, weil dein Entertainment System ist eigentlich komplett obsolet, denn das machen jetzt Apple und Google Android. Ja, Thomas, dann hast du dir ja noch offensichtlich vorgenommen, einen Vortrag mitzuhalten. Auf der, was seid ihr glaube ich dran, am Mittwoch, Donnerstag? Morgen, genau, am Mittwoch. Ah, okay. Was ist da so das Thema, was du hier mit herbringst? Ja, also wir haben jetzt ganz lange über das Fahrzeug gesprochen, so wie es jetzt gerade ist. Ich hoffe, es kam so ein bisschen durch, dass so ein Fahrzeug durchaus sehr kompliziert sein kann, sehr viele Abhängigkeiten darin stecken und der bisherige Ansatz so ein bisschen an seine Grenzen stößt gerade. Also die ganze Automotive-Feld hat eigentlich verstanden, dass man mit diesen Entwicklungsprozessen, Organisationen, Abhängigkeiten zukünftig Fahrzeuge, Software Defined Vehicle, wie sie heißen, nicht wird entwickeln können. Um da einfach nur ein paar Beispiele zu nennen, das Thema Update Release Time, also Mean Time to Market für neue Features, Updates. Kann halt heutzutage mehrere Monate dauern. Wenn ich zum Beispiel eine Software entwickle, will die dann freigeben, auf die Autos bringen, muss ich die testen, ich muss sie homologisieren. Das nimmt aktuell sehr viel Zeit in Anspruch, man muss das definitiv kürzen. Und eine Möglichkeit, um früher Fahrzeuge konkret zu testen, also ich kümmere mich ja viel um das Thema Service Security Testing, stelle ich mir natürlich auch die Frage, wie kann man Testing beschleunigen? Und ein Ansatz ist zum Beispiel, von der physischen Welt in die virtuelle Welt zu gehen. Und wenn wir jetzt über den konkreten Fall sprechen, ich habe ein Steuergerät und habe ein gewisses Tool, mit dem ich das Steuergerät jetzt teste, muss man bisher immer warten, bis das Steuergerät zumindest als physikalisches Muster verfügbar ist, dass ich mich da auch wirklich anschließen konnte. Und worüber wir heute nachdenken und deswegen arbeiten wir auch mit Red Hat, insbesondere mit ihrem Produkt OpenShift, ist, dass man versucht, dieses ganze Thema nicht zu abstrahieren, aber früher in dem Entwicklungsprozess zu berücksichtigen, sodass ich die Funktionalität des Steuergerätes in einer virtuellen Umgebung abbilde, zum Beispiel auf OpenShift, dass ich da zum Beispiel einen Container habe, in dem das Binary der ECU-Software läuft. Das heißt, dieser Container stellt mir grundsätzlich dieselben Funktionalitäten zur Verfügung, hat dieselben Schnittstellen wie eine physische ECU, und ich kann dann auf diesem virtuellen Gegenstand, auf diesem Image, auf diesem Container, auf diesem Komponentes-Container, was auch immer, kann ich auch testen. Das heißt, ich kann dann viel früher testen, ich kann auch schneller testen. Und dadurch habe ich auf der einen Seite eine Zeitreduktion der Testaktivität an sich. Um nur mal einen Vergleich zu nennen, das werde ich zum Beispiel morgen dann auch in einem Vortrag bringen, wenn ich jetzt ein gewisses Testverfahren, aber für eine physische ECU durchführen möchte, kann ich mehrere Tage damit zubringen, nur um eine Schnittstelle zu testen, ausgiebig. Und das kann ich eben durch die Virtualisierung, da habe ich ja dann auch gleich die Skalierungsmöglichkeiten mit dabei, kann ich das auch wenige Stunden reduzieren. Ihr macht ja Fuzzing, das ist ja das, was deinen Titel des Vortrags auch schon aussagt. Und da beschäftigst du ja ein Programm mit unterschiedlichen Inputs, die du über eine Zeit da rein lieferst und dann guckt, okay, wann bricht das Programm, wann bricht es aus und verhält sich eigenartig. Und das ist ja wunderbar, dass du es eigentlich, wenn es ein langwieriger Prozess ist, so hoch skalieren kannst, wie es eben die Umgebung bereitstellt, die du hast. Das ist eigentlich total naheliegend, so etwas wie OpenShift zu arbeiten. Richtig. Also du wirst dadurch das physikalische Test nicht vollständig ersetzen können, weil ein physisches Steuergerät verhält sich in der Realität auch im Fahrzeug dann nochmal ganz anders, als dass es jetzt ein virtualisierter Prototyp ist. Aber ich kann einen durchaus relevanten Anteil des Entwicklungsprozesses oder des Reifegrades einer Steuergeräte Software bereits im virtuellen Stadium abtesten. Ist OpenShifter euer Driver für das Fuzzing, für die Tests? Ist es eure Ausführungsebene oder auch noch gleich Entwicklungsplattformen mit dazu? Das ist vorwiegend die Ausführungsebene. Natürlich bietet OpenShift auch Entwicklungsplattform Möglichkeiten. Es hängt aber immer letztendlich davon ab, was der Kunde bei sich einsetzt. Das heißt, wenn der Kunde schon das komplette Ecosystem von Red Hat hat und seine Steuergeräte Software dort entwickelt, macht es Sinn, das da natürlich rein zu integrieren. Wir betrachten jetzt hauptsächlich mal diesen Aspekt des Testens. Das heißt aber, deine Firma liefert eine Standardsoftware aus für Fuzzing, die dann auf OpenShift beim Kunden laufen wird, als Entwicklungsunterstützung? Genau. Die Software nennt sich Psychofuzz. Das ist ein Fuzzing-Tool. Wie du schon sagst, bietet das die E-Tas am Markt an. Momentan ist das eine Desktop-Variante. Wir bedienen damit den aktuellen Zustand, dass ich diese physischen Setups habe. Der Use-Case ist wie folgt. Der Testingenieur installiert den Fuzzer Psychofuzz oder irgendeine andere Software auf seinem LAP-PC, schließt sich dann an das Steuergerät an und führt die Tests durch. Der Use-Case ist, dass er das nicht auf einem Laptop installieren muss, sondern sich über einen Marketplace zusammen konfiguriert, sich den Entwicklungsprozess seiner Steuergeräte, der Software, virtuell zusammenbaut. Und dann sich dazu entschließt zu sagen, was mache ich denn für Cybersecurity Validation, da hätte ich gerne Fussing mit Psychofuzz zum Beispiel. Und dann zu dem jeweiligen Zeitpunkt, wenn dann die Pipeline diesen Test triggert, dass dann dort ein Container gestartet wird mit Psychofuzz darin, der dann entsprechend den Fusstest auf der virtuellen ECU ausführt. Das sind DevSecOps für Automobil-Applikationen. Genau. Cool. Ich finde das total spannend, weil das hat natürlich gerade die Zentralisierung der einzelnen Systeme, das neue Umgehen, unterschiedliche Technologien da jetzt einzuführen und in Richtung Software-Define zu gehen. Auch extreme Implikationen auf die Arbeitsweisen derjenigen Teams, die ja jetzt für einen, ich hätte gesagt geschlossenen Teilbereich zuständig waren. Wenn meine Aufgabe ist, wenn von hinten Licht kommt, dann mache ich den Spiegel dunkler, dann war das wahrscheinlich irgendwie ein Team, was sich darum gekümmert hat. Und jetzt dann hin zu auch standardisierteren Auslieferungsverfahren, dadurch wahrscheinlich auch mehr die Möglichkeit, auch mal in andere Teilbereiche schneller reinzukommen, schneller wechseln zu können. Vielleicht auch die Ressourcenplanung, die da irgendwo ist, etwas dynamischer machen zu können. Aber ich glaube auch, dass das bestimmt auch die Separierung der einzelnen Module dazu geführt hat oder sehr begünstigt hat, dass sich abgeschlossene kleine Silos irgendwo bilden. Und die könnten ja dann jetzt irgendwie aufgelöst werden. Oder das wäre eine Herausforderung, die da auf jeden Fall auch organisatorisch irgendwo mit sich kommt. Also es ist total spannend, was das ja doch rudimentär erklärte. Hey, wir zentralisieren das jetzt mal von, was hattest du gesagt, 120 Steuergeräten auf dann vielleicht fünf, sechs, später vielleicht eins. Das hat natürlich auch auf diesen gesamten Entwicklungsprozess und ich glaube gerade bei Automotive, wenn man sich anguckt, wie viele Software-Engineers haben da so diese OEMs, hast du gesagt, glaube ich dazu. Das ist ja enorm viel, was das auch an Strukturänderungen dann mit sich führt. Da ist natürlich klar, dass wenn ich jetzt heute auf einer grünen Wiese anfange und das mit neuen Methoden irgendwie entwickle, dass das dann einfacher ist, dass ich jetzt aber als Automobilhersteller jetzt schon echt da einen ganz schönen Change auch vorm herbe. Das ist für mich total spannend. Definitiv. Also ich glaube nicht, dass wir das Fahrzeug so aufbauen werden, dass wirklich nur ein Steuergerät da drin sein wird. Es werden schon ein paar mehr sein, aber deutlich weniger als wir es jetzt gerade haben. Und das, was du da ansprichst, ist absolut ein Punkt. Und man muss es, das ist halt historisch so bedingt. Früher hat man Steuergerät zentriert entwickelt. Das heißt, da gab es Abteilungen Teams, die hatten ein konkretes Steuergerät, haben das entwickelt von Anfang bis zum Ende. Und heute, wenn ich jetzt diese zentralen Plattformen habe, wie zum Beispiel OpenShift und dann noch den Developer-Anteil dazu, dann habe ich ja dann eine zentrale Instanz. Das heißt, ich werde jetzt nicht 20 verschiedene OpenShift-Cluster nebenher irgendwo laufen haben oder verschiedene Zwecke für OpenShift, sondern es wird irgendwie einige wenige zentrale OpenShift-Instanzen geben, wo halt der Großteil der Entwicklungen und des Testings drüber läuft. Und ja, das wird sicherlich den ein oder anderen auch von einer organisatorischen Herausforderung stellen. Mal so in die Zukunft geguckt, wie weit sind wir technologisch entfernt von Autos, die über die eigene Fahrgastzelle hinaus miteinander kommunizieren und so ein Entstehen eines Staus gar nicht mehr möglich machen? Ist das ein Ding? K2X? Also ist das so, also ist ja auch dann ein riesen Security-Ding. Wenn mir ein anderes Auto signalisiert, dass ich jetzt stark bremsen muss, dann hat das natürlich auch irgendwie einen Impact. Ist das was, wo irgendwie in der Richtung gerade was passiert oder ist das noch sehr, sehr, sehr weit in der Zukunft? Das ist auf jeden Fall ein Use-Case, der durch die einzuhaltende Konnektivität definitiv dann irgendwann auch realisiert werden wird. Ich kann dir aber gerade überhaupt nicht sagen. Also ich weiß, dass diverse Hersteller daran arbeiten, schon seit langem auch, aber wann das jetzt wirklich nutzbar ist, das kann ich dir nicht sagen. Ja, spannend. Ja, also ich finde das total interessant, da mal so ein bisschen in den Blick reingeworfen haben zu können. Also vielen Dank auch für die Erklärung. Ich glaube, ich habe jetzt einen etwas anderen Blick aufs Auto. Ich freue mich schon ehrlich gesagt darauf, dass ich Container mache, ja schon eine ganze Weile. Linux auch. Und ich habe so das Gefühl, dass auf absehbare Zeit, also mal so die nächsten zehn Jahre, das vielleicht gar nicht so unwahrscheinlich ist, dass dann auch in einem meiner Autos irgendwann Kubernetes mit Containern irgendwo läuft und ich dann mit meinem Cluster einfach auf Roadtrip gehen kann. Das ist schon irgendwie ein schönes Gefühl. Ja und du kannst beruhigt sein, dass irgendjemand vernünftiges Security-Testing macht für das Auto, in dem du fährst, mit Werkzeugen, die wir durchaus kennen und denen wir vertrauen. Und vielleicht können wir dann auch Mechatronikern den richtigen Umgang mit CubeCity beibringen. Es ist schon echt spannend, was da so auf uns wartet und wie die Sachen, die wir jetzt in der Softwareentwicklung schon die letzten zehn Jahre im Endeffekt machen, jetzt auch in diese Bereiche Einzug halten. Ich finde es total spannend. Ja, hat mich sehr gefreut auch mit euch das heute zu teilen, auch mal so ein bisschen eure Sichtweise hier zu hören. Ich denke, die Welten werden da einfach mehr zusammenwachsen müssen und das werden sie auch tun. Das finde ich auch super gut, weil man hier extrem viel voneinander lernen kann. Und wie du schon sagtest, die Berührungspunkte, die Schnittpunkte sind größer als man denkt. Auch ein großes Dank an die IT-Enterprise-Gemeinde, die da diesen DevOps-Ansatz schon voren entwickelt haben. Und auch wirklich nachgewiesen haben, das macht Sinn, das ist funktional. Ja, ich würde sagen, dann sind wir hier für diese Episode am Ende angekommen. Euch werden sicherlich die nächsten Episoden noch das eine oder andere an Zusammenfassung und an Trendthemen. Ich glaube, du hast die eine oder andere Ankündigung schon fast mit reingenommen. Ich bin gespannt, was uns da jetzt die nächsten zwei, drei Tage noch so erwartet. Und was wir da vor allem auch in den versprochenen Hands-on-Labs uns dann angucken können und daraus berichten können. Dafür müssen wir jetzt erstmal ausschwärmen und alles aufsorgen und dann treffen wir uns hier wieder. So machen wir das. Hat mir ganz viel Spaß gemacht. Vielen Dank, dass ihr dabei wart und bis zum nächsten Mal. Danke. Ciao. Ciao.