Software-Defined Vehicles Tesla schmeißt das Lenkrad raus – wer baut jetzt den Entwicklungsprozess um?

Tesla hat in Austin, Texas den begrenzten kommerziellen Betrieb mit Cybercabs, Fahrzeuge, die ohne Lenkrad und Pedale auskommen, aufgenommen. Noch am selben Tag eröffnete die US-Verkehrssicherheitsbehörde NHTSA eine Prüfung. Inzwischen verlangt sie per Special Order Auskunft darüber, auf welcher technischen und rechtlichen Grundlage Tesla die Einhaltung der Federal Motor Vehicle Safety Standards selbst zertifiziert hat.

Das Cybercab macht damit sichtbar, wie sich die Anforderungen an die Fahrzeugentwicklung verändern. Auch für den deutschen Markt wird das Thema konkret: Waymo bereitet einen vollautonomen Fahrdienst in München vor und strebt den kommerziellen Start gegen Ende 2027 an. Mit dem Holon urban entsteht hier zugleich ein autonomes Level-4-Fahrzeug auf Basis einer durchgängigen digitalen Produktentwicklung. Damit rückt auch für deutsche und europäische Automobilhersteller die Frage näher, wie sich Fahrzeuge nach der Fertigstellung effizient weiterentwickeln lassen.

Entwicklung nach dem Start of Production

Im klassischen Entwicklungsmodell arbeitet ein Hersteller auf einen festgelegten Produktstand hin. Nach der Definition, Umsetzung und Erprobung der Funktionen beginnt mit dem Start of Production die Fertigung einer definierten Fahrzeugkonfiguration. Beim Software-definiertem Fahrzeug (Software-Defined Vehicle, SDV) setzt sich die Entwicklung nach dem Start of Production fort. Funktionen können nach der Auslieferung per Over-the-Air-Update verändert, erweitert oder freigeschaltet werden. Jedes Update wird damit zu einem Entwicklungsgegenstand. Der Hersteller muss nachvollziehen können, warum eine Änderung vorgenommen wurde, welche Konfigurationen sie betrifft, wie sie getestet wurde und wer sie freigegeben hat.

Bei autonomen Fahrfunktionen ist diese Nachvollziehbarkeit sicherheitskritisch. Eine Änderung an der Objekterkennung kann beispielsweise nur bestimmte Kombinationen aus Sensorik, Rechnerplattform und Software-Stand betreffen. Hinzu kommen mögliche Auswirkungen auf Functional Safety oder Homologation. Baureihe und Modelljahr reichen als Identifikation deshalb nicht aus. Zwei äußerlich identische Fahrzeuge können unterschiedliche Softwarestände und Systemkonfigurationen aufweisen. Der Entwicklungsnachweis muss deshalb bis zum konkreten Fahrzeug reichen.

Die UNECE-Regelungen R155 und R156 bilden dafür einen regulatorischen Rahmen. Wie belastbar der zugrunde liegende Prozess ist, zeigt eine einfache Frage: Kann ein Autobauer kurzfristig benennen, welche Software-Version in einem bestimmten Fahrzeug aktiv ist, auf welcher Freigabe sie beruht und welche Tests dafür durchgeführt wurden? Müssen diese Informationen erst aus verschiedenen Systemen, Tabellen und manuellen Listen zusammengesucht werden, passt der Prozess nicht zu einer Flotte, deren Softwarestände sich laufend verändern.

Software wird zur zentralen Variantenebene

Plattformstrategien können die Zahl physischer Fahrzeugvarianten reduzieren, die Komplexität verschwindet dadurch jedoch nicht. Sie verlagert sich in Software-Stände, Funktionsfreigaben, Ländervarianten und Abhängigkeiten zwischen den Systemen. Eine autonome Fahrfunktion hängt aber von der gesamten Fahrzeugarchitektur ab. Änderungen an Sensorik oder zugehörigen Fahrzeugfunktionen können deshalb Auswirkungen auf die Gesamtfunktion haben.

Ein absolvierter Test gilt deshalb nicht automatisch für jede Kombination aus Hardware, Software und Marktanforderung. Automobilhersteller müssen Testabdeckung und Freigabe präzise einem definierten Konfigurationsstand zuordnen. Vor einer Änderung müssen Impact-Analysen zeigen, welche Anforderungen, Schnittstellen und Fahrzeugvarianten erneut geprüft werden müssen. Auch der Rollback gehört zu diesem Prozess. Schlägt ein Update fehl oder zeigt es im Feld unerwartete Auswirkungen, muss feststehen, welche Fahrzeuge betroffen sind und auf welchen sicheren Stand sie zurückgesetzt werden können.

Getrennte Systeme als Prozessgrenze

In vielen Entwicklungsorganisationen verteilen sich die für eine Änderung nötigen Informationen auf unterschiedliche Systeme. Einzelne Teams können mit lokalen Dateien und spezialisierten Werkzeugen effizient arbeiten. Kritisch werden jedoch die Übergänge. Werden Informationen manuell übertragen, entstehen unterschiedliche Versionsstände und Lücken in der Änderungshistorie. Das erschwert bereits innerhalb eines Unternehmens die Ursachenanalyse. Bei autonomen Fahrzeugen verschärft sich das Problem, weil mehrere Fachbereiche, Zulieferer und Softwarepartner an derselben Funktion beteiligt sind.

Eine Abweichung aus dem Feld muss sich bis zur betroffenen Funktion zurückverfolgen lassen. In der anderen Richtung muss erkennbar sein, welche konkreten Fahrzeuge eine Änderung aus dem Engineering erhalten dürfen. Entscheidend ist, dass die Beziehungen zwischen den Informationen eindeutig, versioniert und maschinell auswertbar bleiben.

ALM, PLM und MBSE im Zusammenspiel

Application Lifecycle Management (ALM), Product Lifecycle Management (PLM) und Model-Based Systems Engineering (MBSE) decken unterschiedliche Teile dieser Aufgabe ab. ALM verbindet Anforderungen mit Softwareentwicklung, Tests und Freigaben. PLM ordnet Änderungen den gültigen Produkt- und Fahrzeugkonfigurationen zu. MBSE beschreibt Funktionen, Systemarchitekturen, Schnittstellen und Abhängigkeiten.

Erst ihre Verknüpfung macht die Beziehungen zwischen Anforderungen, Systemen und Fahrzeugkonfigurationen jedoch nachvollziehbar und sichtbar. Wird beispielsweise eine Anforderung an eine autonome Funktion geändert, muss sich ermitteln lassen, welche Softwarekomponenten und Tests betroffen sind. Gleichzeitig muss klar sein, für welche Hardware-Konfigurationen, Märkte und Fahrzeuge die Änderung relevant ist. Der Intelligent Product Lifecycle (IPL) bildet dafür einen gemeinsamen Entwicklungsrahmen. Er verbindet die relevanten Informationen von der Anforderung über Architektur, Software-Stand und Test bis zur Fahrzeugkonfiguration im Feld. Das hilft OEMs, Änderungen schneller zu bewerten und die notwendigen Nachweise gezielter zu führen. Zugleich sinkt das Risiko, dass eine technisch korrekte Änderung auf eine dafür nicht freigegebene Konfiguration ausgerollt wird.

Verantwortung über den gesamten Prozess

Eine integrierte Werkzeugkette braucht klare Zuständigkeiten. Die beteiligten Engineering-Bereiche arbeiten mit unterschiedlichen Methoden, Zielen und Verantwortlichkeiten. Für ein SDV muss daher klar geregelt sein, wer eine Funktion über den gesamten Prozess hinweg verantwortet. Diese Ende-zu-Ende-Verantwortung beginnt bei der Anforderung und endet nicht mit der Freigabe für die Produktion. Sie umfasst auch den Betrieb. Dabei ist festzuhalten, welche Konfigurationen betroffen sind, welche Nachweise vorliegen, wer Updates freigibt und wie mit Annahmen umzugehen ist, die sich im Feld als falsch erweisen.

Automobilhersteller sollten zunächst den durchgängigen Prozess einer Funktion vom ersten Anforderungsentwurf bis zum Einsatz im Fahrzeug beschreiben. Erst danach lässt sich sinnvoll entscheiden, wie ALM, PLM, MBSE und weitere Systeme diesen Prozess unterstützen müssen.

Das Cybercab als Prüfstein

Das Cybercab ist für deutsche und europäische Hersteller keine Vorlage zum Kopieren. Sein Einsatz macht jedoch sichtbar, was ein Fahrzeug, das sich nach der Auslieferung weiterentwickelt, von der Entwicklungsorganisation verlangt. Für ein bestimmtes Fahrzeug muss ein OEM innerhalb kurzer Zeit den aktiven Software-Stand, die zugrunde liegenden Anforderungen, die Testergebnisse und die Freigabe nachweisen können.

Wenn diese Informationen manuell aus mehreren Systemen zusammengetragen werden müssen, fehlt ein durchgängiger Entwicklungsprozess für das Software-Defined Vehicle. Tesla hat beim Cybercab das Lenkrad ausgebaut. Für die übrige Automobilindustrie liegt die größere Aufgabe darin, Entwicklungsprozesse zu schaffen, in denen sich Fahrzeuge nach der Auslieferung sicher weiterentwickeln lassen und Geschwindigkeit, Sicherheit sowie regulatorische Nachweisbarkeit zusammenpassen.  (se)

(ID:50998339)