Schwierige Realisierung
Softwaredefinierte Fahrzeuge: Warum scheitern viele OEMs?
Woran scheitern viele OEMs, wenn es um die Realisierung von softwaredefinierten Fahrzeugen (SDV) geht? Yu Fang, CTO, Chief Product Officer und Mitgründer, und Dr. John Heinlein, Chief Marketing Officer, beide Sonatus, liefern einige Anhaltspunkte.
Markt&Technik: Woran liegt es, dass manche OEMs SDVs bereits auf der Straße haben und andere wiederum richtig viel Geld in die Hand nehmen und trotzdem scheitern?
Yu Fang: Neueinsteiger im Automotive-Segment haben heute die Chance, unbeschwert von Altlasten wie alten Organisationsstrukturen oder bestehenden Modulen vollkommen neu zu starten. Sie können von Null anfangen. Sie müssen keine bestehenden Infrastrukturen oder Technologien wiederverwenden, die vielleicht nicht mehr zeitgemäß sind. Das gibt ihnen eine große Flexibilität und eröffnet viele Möglichkeiten.
Dazu muss man aber anmerken: Diese Neueinsteiger stehen natürlich vor ganz anderen Herausforderungen. Sie haben aber zumindest die Freiheit, vollkommen neue Wege zu beschreiten, und das ist in Hinblick auf SDVs sehr wertvoll.
Aber kommt nicht noch erschwerend hinzu, dass manche OEMs eine gewisse Ignoranz aufweisen?
Fang: Früher vielleicht, aber ich denke, dass die meisten OEMs ihren Ansatz neu bewerten. Die frühere Strategie, alles intern machen zu wollen, verliert an Bedeutung. Aber das lag nicht etwa an einer möglichen arroganten Haltung, sondern an dem Wunsch, die vollständige Kontrolle über alle Prozesse zu haben. Die OEMs hatten verschiedene Fähigkeiten im Sinn, die ihre Fahrzeuge haben sollten. Und dann haben sie sich umgeschaut, was auf dem Markt verfügbar ist. Es gab aber nicht viel, was sie nutzen konnten, also waren sie gezwungen, selbst zu entwickeln.
Doch wie gesagt, diese Denkweise hat sich verändert. Die OEMs erkennen zunehmend, dass es vorteilhafter ist, das zu kaufen, was sinnvoll und machbar ist, und sich auf ihre Kernkompetenzen zu konzentrieren. Dieser Ansatz wird ihnen sicherlich dabei helfen, ihre Ziele zu erreichen.
Aber auch wenn es heute deutlich einfacher ist, sich am Markt zu bedienen, die Newcomer haben es ja auch ohne geschafft.
Dr. John Heinlein: Es ist natürlich auch eine bestimmte Denkweise oder Einstellung beim OEM notwendig. In dem einen Fall wird das Fahrzeug als System mit zahlreichen Funktionen und mehreren ECUs betrachtet. In dem anderen Fall wird das gesamte Fahrzeug als Computer betrachtet, der in der Lage ist, die spezifischen Funktionen auszuführen, die der OEM wünscht.
Schon klar, diese Denkweise ist im Vergleich zu vor zehn Jahren radikal anders, aber ohne geht es nicht.
Es ist aber nun mal eine Tatsache, dass in den bisherigen Fahrzeugen Funktionen mithilfe von ECUs realisiert wurden.
Fang: Ja, genau das ist ein Problem. Das Fahrzeug war in der Vergangenheit in Subsysteme aufgeteilt, die aus Hardware und Software bestanden und isoliert von verschiedenen Tier-Ones geliefert wurden. Die OEMs haben damals auch nicht darauf bestanden, Einblick in die Software zu haben, weil es ging ja nicht darum, diese Software im Nachhinein noch einmal zu verändern.
Und heute ist genau das ein Problem, denn die OEMs müssen mit vielen verschiedenen Steuergeräten und deren Blackbox-Software arbeiten, was die Flexibilität und Aufrüstbarkeit behindert.
Was ist Ihrer Meinung nach also notwendig?
Fang: Der Umstieg braucht mehrere Ansätze. Zum einen ist Flexibilität natürlich immer schwierig, wenn alles fest verdrahtet ist. Funktioniert etwas nicht, dann lässt sich das Problem mit diesem Ansatz nicht so einfach lösen.
Deshalb empfehle ich immer, zuerst über die gewünschte Funktion nachzudenken und dann darüber, wie diese Funktion im Fahrzeug bereitgestellt werden kann.
Es geht also weniger darum, wie viele ECUs ein OEM in seinem Fahrzeug hat, sondern es geht mehr darum, wie der OEM sein gesamtes Fahrzeug sieht. Es geht darum, ob er jedes seiner Steuergeräte isoliert betrachtet oder ob er das gesamte Fahrzeug als System betrachtet.
Das ändert aber nichts an der Tatsache, dass nun mal viele Fahrzeuge mit über hundert ECUs ausgestattet sind.
Heinlein: Sie müssen es anders betrachten: Mit Ihrer Aussage setzen Sie voraus, dass ein Steuergerät die richtige Antwort ist; das stimmt aber nicht, denn ein Steuergerät ist nur der richtige Ansatzpunkt. Es geht darum, dass ein OEM in seinem Fahrzeug hundert und mehr Funktionen bzw. Bedürfnisse umsetzen/befriedigen muss, wie Klimaanlage oder Fensterheber. Für diese Funktionen/Bedürfnisse sind aber keine eigenen Steuergeräte notwendig.
Ja, aber wenn die Funktionen nur noch mit Software umgesetzt werden, hat das ja enorme Veränderungen zur Folge.
Stimmt, aber es funktioniert. Sonatus kann auf viel Know-how aus Rechenzentren zurückgreifen. In diesem Bereich, aber auch bei Telefonen und Computern werden 20 Anwendungen gleichzeitig ausgeführt. Es gibt keine eigene Hardware, mit der E-Mails bearbeitet werden.
Und genau dieser Ansatz muss in Fahrzeuge übertragen werden. Das machen ja auch führende Unternehmen so: Sie haben ein Modul, das viele Aufgaben übernimmt, inklusive Software-Isolierung, die diese verschiedenen Module voneinander trennt.
Das heißt, dass das Softwaremodul, das für die Fenster zuständig ist, isoliert von dem Softwaremodul arbeitet, das für die funktionale Sicherheit zuständig ist etc.; das läuft vielleicht zufällig auf derselben Hardware, aber dank bekannter und gut etablierter Softwaretechniken aus dem Computer-Bereich ist das überhaupt kein Problem. Was ich damit sagen will: Mit diesem Ansatz werden aus hundert Steuergeräten hundert Funktionen, die auf einer deutlich kleineren Anzahl von Steuergeräten laufen kann.
Klingt einleuchtend, aber wie es scheint, ist ein radikaler Umstieg auf diesen Ansatz für die etablierten OEMs alles andere als trivial.
Fang: Ja, natürlich muss ein etablierter OEM schrittweise vorgehen, eine binäre Denkweise ist hier nicht effektiv. Das heißt, dass die OEMs zunächst einmal Bereiche identifizieren müssen, die sie verbessern und vereinfachen können.
Ein effektiver Ansatz hierfür sind zonale Architekturen, und ich denke, dass dieser Ansatz in der Branche als vielversprechende Richtung weithin anerkannt ist. Die Herausforderung liegt in der unterschiedlichen Geschwindigkeit, mit der dieser Fortschritt umgesetzt wird.
Warum?
Ein Problem vieler etablierter OEMs ist sicherlich die Vernetzung. Schauen Sie sich heutige Ansätze an. Sitzt eine Kamera im hinteren Teil des Fahrzeugs, gibt es bei einer klassischen Architektur ein Kabel, das speziell für diese Kamera bestimmt ist und durch die ganze Karosserie bis zum IVI-System führt. Dort wird die Kamera eingeschaltet, wenn man die Rückfahrkamera einschaltet. Um es ganz offen zu sagen: Das funktioniert nicht. Wir empfehlen stattdessen eine Zonenarchitektur.
Dann gibt es drei oder vier dieser Recheneinheiten, je nach Fahrzeug. Diese zonalen Steuergeräte stellen eine Verbindung zu den lokalen Subsystemen her und konvertieren die Signale in einen anderen Kommunikationsstandard wie zum Beispiel Automotive Ethernet. Mit diesem Ansatz ist ein schrittweiser Übergang möglich.
BMW ist der absolute Befürworter von Automotive Ethernet, aber auch für etablierte OEMs ist der Übergang von einer verteilten Architektur auf eine zonale Architektur nicht einfach. Ist es ein Problem der Hardware?
Automotive Ethernet kann im Vergleich zu CAN viel mehr Daten übertragen, das sollte also kein Problem darstellen, ich glaube also nicht, dass es an der Hardware liegt. Es geht vielmehr darum, wie man die Technologie so einsetzt.
Wenn man sich Ethernet anschaut, dann wird diese Technologie heute so gut wie überall eingesetzt. Aber klar, das hat auch 20 Jahre gedauert, bis es soweit war.
Automotive Ethernet ist ein einziges physisches Netz, über das viele verschiedene Arten von Informationen übertragen werden. Einige Informationen sind zeitkritisch, beispielsweise beim Bremsen. Andere Informationen sind wiederum weniger zeitkritisch, dafür sehr datenintensiv, nehmen Sie als Beispiel das Streamen von Videos. So oder so: All diese Dinge müssen über dasselbe physische Netzwerk laufen.
Heinlein: Es ist wichtig, das gesamte System zu betrachten und die Konnektivität zu verbessern, um Kosten zu senken und die Flexibilität zu erhöhen. Die Frage ist, wie der OEM es schafft, die verschiedenen Anforderungen im selben Netzwerk zu erfüllen. Dies erfordert Fachwissen.
Noch ein Punkt: Wir sprechen über softwaredefinierte Fahrzeuge, das heißt, dass die Funktionalität des Fahrzeugs leicht zu ändern sein soll, und damit muss das Netzwerk diese Funktionsänderungen auch unterstützen, sprich: bestimmte Informationen im Fahrzeug müssen umgeleitet werden. Es geht also nicht nur darum, die Software zu aktualisieren. Es geht auch darum, wie Sie die Informationen in Ihrem Fahrzeug an die richtige Stelle weiterleiten.
Fang: Und wie macht man das? Gibt es eine Möglichkeit, dies zusammen mit der Software-Aktualisierung schnell und einfach zu tun? Ich würde jedem OEM empfehlen, von Anfang an an das Netzwerk im Fahrzeug zu denken. Denn das ist kein Problem einer Domäne, sondern ein fahrzeugweites Problem.
Heinlein: Und genau diesen Punkt adressieren wir, hier können wir unser Know-how aus den Rechenzentren einbringen. Dort wandert die Arbeitslast von einem Computer zum anderen, ebenso die Daten, das heißt, das Netzwerk muss dynamisch angepasst werden.
Um es nochmals zu betonen: Ein Subsystem allein zu betrachten ist der falsche Ansatz, denn damit wird es unmöglich, eine neue Anwendung hinzufügen.
Sie halten also Automotive Ethernet neben einer zonalen Architektur für entscheidend?
Fang: Ja, Automotive Ethernet als Backbone hat viele Vorteile, ohne dass die OEMs alles, was bereits vorhanden ist, wegwerfen zu müssen. Selbst moderne Fahrzeuge nutzen heute noch CAN, auch deshalb, weil es unnötig, aber auch unpraktisch ist, Ethernet bis zum Endknoten zu verwenden.
Automotive Ethernet reduziert den Verkabelungsaufwand erheblich. Rivian beispielsweise konnte zwischen der ersten Generation R1 und der zweiten Generation 20 Kilogramm Gewicht einsparen, und das war möglich, weil sie in der zweiten Generation eine zonale Architektur verwendet haben, die die Verkabelung reduzierte und die Steuergeräte konsolidierte.
Sie erklären, dass Sonatus den Vorteil hat, dass es Know-how aus dem Bereich Data-Center nutzen kann, sodass OEMs einfacher zum SDV gelangen. Aber lassen sich diese beiden Anwendungen ernsthaft vergleichen, beispielsweise in Hinblick auf die funktionale Sicherheit? Das spielt wahrscheinlich in Rechenzentren eher eine untergeordnete Rolle.
Heinlein: Ja, das stimmt natürlich. Aber es wäre falsch, daraus zu schließen, dass die Techniken aus den Datenzentren im Fahrzeug nicht nutzbar sind. Dinge wie z. B. zeitkritische Netzwerke sind eine Erweiterung des traditionellen Ethernets, mit dem auch sicherheitskritische Funktionen realisiert werden können, wobei die gleiche zugrunde liegende Bereitstellung, die gleiche zugrunde liegende Servicequalität erhalten bleibt.
Fang: Darüber hinaus möchte ich folgendes betonen: Was heißt »funktionale Sicherheit«, welche tatsächlichen Fähigkeiten sind hier gefordert.
Wenn man es auf die einzelnen Fähigkeiten herunterbricht, glaube ich, dass die Technologien aus den Rechenzentren auch bei den einzelnen funktional sicheren Funktionen helfen können. Wichtige Anwendungen wie zum Beispiel Zahlungen werden in Rechenzentren ausgeführt. Diese sind geschäftskritisch und müssen funktionieren. Die funktionale Sicherheit stellt natürlich andere Anforderungen, aber der Punkt ist, dass es bekannte Lösungen wie Time Sensitive Networking gibt, die auf Fahrzeuge angewendet werden können, um diese Anforderungen zu erfüllen.
Aber es gibt immer wieder Ausfälle. Erst vor Kurzem war in Deutschland die Zahlung mit Giro-, Kredit- und Debitkarte bundesweit gestört. So etwas sollte tunlichst in einem Fahrzeug nicht passieren. Dazu kommen noch die immer wieder auftretenden Hacker-Angriffe.
Fang: In diesem Zusammenhang ist es wichtig zu wissen, dass Software immer Fehler enthalten wird. Der Rückschluss, dass man deshalb keine Software in Fahrzeugen nutzen möchte, ist schlichtweg falsch, denn die heutigen Fahrzeuge sind bereits stark von Software abhängig.
Und die meisten OEMs kämpfen heute mit Schwierigkeiten, dass sie Softwareprobleme nicht beheben können. Und das muss sich ändern. Die OEMs müssen in der Lage sein, ein Problem sehr schnell zu beheben und zu korrigieren.
Dabei möchte ich noch folgenden Punkt betonen: Niemand möchte, dass seine Software ausfällt. Daher sind Entwickler bei der Erstellung und gründlichen Prüfung sehr sorgfältig, um die Zuverlässigkeit und Leistung der Software sicherzustellen.
Deshalb ist die Überlegung, für eine höhere Sicherheit lieber keine neue Software ins Fahrzeug zu bringen, fragwürdig. Es gibt viele Möglichkeiten, die Software zu testen, sei es mithilfe von Cloud-basiertem Prototyping, Cloud-basierter Simulation oder in Form von digitalen Zwillingen.
Jeder sollte sich klarmachen: Dank Software sind wir überhaupt in der Lage, mehr Simulationen in der Cloud durchzuführen, sodass Software ausführlich getestet und verifiziert werden kann, bevor sie in realen Szenarien angewendet wird.
Die Hardwarehersteller haben jahrelang daran gearbeitet, ihre Hardware zuverlässig zu machen. Kann man das auch für Software sagen?
Heinlein: In diesem Zusammenhang halte ich es für erwähnenswert, dass Rückrufe in der Automobilindustrie trotz aller bisherigen Bemühungen 40 Mrd. Dollar pro Jahr kosten.
Auch wenn sich nicht alle dieser Rückrufe mit Software-Updates verhindern ließen, ist es schon ein überzeugendes Argument, selbst, wenn nur ein Bruchteil der Probleme durch Software-Updates gelöst werden könnte.
Klar, je mehr Rückrufe in die Werkstatt wegfallen und ein Problem über ein Software-Update behoben werden kann, desto besser für den OEM.
Das ist aber nicht alles, denn das Versprechen von Software-Defined Vehicles besteht auch darin, dass die Subsysteme nicht nur repariert werden können, sondern auch aufrüstbar sind.
Fang: Dazu müssen die Subsysteme rekonfigurierbar sein. Der OEM muss sich also überlegen, wie jedes Teil des Subsystems so gestaltet werden kann, dass es leicht rekonfigurierbar ist. Und bei dieser Überlegung geht es definitiv nicht nur um Hardware, sondern auch um Software. Wie können Softwaremodule so gestaltet werden, dass sie leicht umkonfiguriert werden können? Beide Punkte sind die Grundlage, um das Verhalten eines Fahrzeugs leicht zu ändern.
Nur Grundlage?
Fang: Ja, denn der OEM muss sich auch fragen, wie er all die Konfigurationsmöglichkeiten, die er im Fahrzeug hat, nutzen kann, um schnelle Änderungen vorzunehmen. Und genau hier kommen wir mit unseren Softwareprodukten ins Spiel.
Ein Beispiel?
Fang: Ein Fahrzeug generiert immens viele Daten. Wir helfen mit Sonatus Collector den OEMs quasi dabei, die Nadel im Heuhaufen zu finden, sprich: das Maximum aus den im Fahrzeug gesammelten Daten herauszuholen. Denn Sonatus Collector ermöglicht es dem OEM, sehr präzise Fragen an das Fahrzeug zu stellen. Damit können wichtige von unwichtigen Daten getrennt werden, das spart Kosten, denn nur wichtige Daten werden über das fahrzeuginterne Netz versendet, in die Cloud geschickt und dort analysiert.
Können Sie das bitte konkretisieren?
Fang: Ja klar. Die meisten der heutigen Neufahrzeuge sind mit einer adaptiven Geschwindigkeitsregelung ausgestattet. Sie sollte meistens sehr gut funktionieren, aber wenn der Fahrer das Gefühl hat, dass das Auto nicht das tut, was er will, dann übernimmt er die Kontrolle. Und diese Übernahme ist normalerweise ein ganz klares Zeichen dafür, dass etwas nicht perfekt funktioniert. Und hier hat der OEM mit unserer Software die Möglichkeit, herauszufinden, ob ein Problem besteht und, wenn ja, welches.
Ein weiteres Beispiel, von der letzten CES: Damals haben wir gezeigt, dass wir mithilfe unserer Software »Sonatus Collector« LG Innotek detaillierte Informationen über ihre Komponenten geben konnten, sodass das Unternehmen Optimierungen durchführen konnte, und zwar feinmaschig. Mit unserer Software ist es beispielsweise möglich, die Einstellungen für einen Motor bei hohen Temperaturen zu verändern, wenn er eine gewisse Ineffizienz aufweist, die bei niedrigen Temperaturen nicht auftritt, und das dynamisch.
Ein weiteres Beispiel aus dem Bereich Sicherheit: OPmobility hat ein dynamisches Rücklicht entwickelt. Mit unserer Software »Sonatus Automator« können Fahrzeugsensoren automatisch animierte Informations- oder Warnmeldungen ohne Zutun des Fahrers auf dem Mini-LED-Display von OPmobility in der Rückleuchte des Fahrzeugs auslösen. Das heißt, dass in einer Fahrsituation, in der der Fahrer beispielsweise einen Fußgänger in einer gewissen Entfernung sieht, der die Straße überqueren will, das Fahrzeug auf der Rückseite eine visuelle Animation »Fußgängerüberweg« anzeigt, sodass das nachfolgende Fahrzeug gewarnt wird, noch bevor der Fahrer zu bremsen beginnt.
Das wäre in Deutschland verboten.
Fang: Die EU hat bereits einige digital gemusterte Frontscheinwerfer genehmigt, um den Fahrer über Gefahren im Voraus zu informieren. Während Rücklichtmuster in der EU noch nicht genehmigt sind, können Sie dieses Beispiel aus einem anderen Grund verwenden, warum OEMs an einem SDV interessiert sein sollten: Gesetze ändern sich ständig. Dies erfordert die Fähigkeit der OEMs, Fahrzeuge dynamisch anzupassen, und Software-Updates sind eine sehr effektive Möglichkeit, dies zu erreichen. Wie diese Beispiele zeigen, bieten SDVs einen erheblichen Mehrwert, sodass sich der Aufwand lohnt.
Jobangebote+ passend zum Thema
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Sonatus
Den langen Weg zum SDV abkürzen
Software-Update sorgt für Ruhe
Nächtliche Robotaxi-Hupkonzerte gestoppt
Mehr Sicherheit und Komfort
Radar im Software-Defined Vehicle
