Beim Software-Defined Vehicle endet die Produktverantwortung nicht mit dem SOP (Start of Production). Für OEMs und Zulieferer entsteht eine längere Phase, in der Softwarefunktionen weiterentwickelt, freigegeben und wirtschaftlich genutzt werden. Damit verändern sich neben den Geschäftsmodellen auch die Anforderungen an Prozesse, Verantwortlichkeiten und Produktinformationen.

Ein Software-Defined Vehicle (SDV) verlässt das Werk mit einer Konfiguration, die sich später verändern kann. Der Kunde kann Funktionen aktivieren, ein Update erhalten oder einen erweiterten Service buchen, ohne dass sich die Hardware des Fahrzeugs ändert. Für OEMs und Zulieferer beginnt damit nach der Auslieferung eine neue Phase im Produktlebenszyklus.

Diese Verschiebung geht weit über neue Geschäftsmodelle hinaus. Denn wenn sich ein Fahrzeug nach der Auslieferung weiterentwickelt, müssen auch die Prozesse dahinter Schritt halten. Entwicklung, Freigabe und Produktpflege sind nicht mehr allein auf den SOP ausgerichtet. Wie lässt sich also ein Produkt zuverlässig beherrschen, dessen Funktionsumfang sich über Jahre hinweg verändert?

Wertschöpfung nach der Auslieferung

Im klassischen Fahrzeugprojekt lag der Schwerpunkt der Wertschöpfung vor der Auslieferung. Anforderungen wurden umgesetzt, das Fahrzeug wurde getestet und für die Produktion freigegeben. Beim SDV reicht die Wertschöpfung zunehmend über die Auslieferung hinaus. Denn auch nach der Auslieferung werden Funktionen angepasst, Fehler behoben und neue Angebote für bereits verkaufte Fahrzeuge entwickelt. Produktmanagement und die beteiligten Engineering-Teams müssen dabei immer auf denselben Funktionsstand blicken können.

Diese Veränderung beginnt bereits in der Entwicklung. Eine Funktion, die später aktiviert werden soll, muss so angelegt sein, dass ihre Abhängigkeiten und Freigaben nachvollziehbar bleiben. Sonst lässt sich aus einer technisch möglichen Funktion kein zuverlässig betreibbares Angebot machen. Die Grundlage für zusätzliche Softwareerlöse entsteht damit lange vor der eigentlichen Aktivierung.

Eine Flotte mit vielen Softwarezuständen

Für den OEM verändert sich mit dem Software-Defined Vehicle der Blick auf das Fahrzeug. Eine Baureihe bildet weiterhin die gemeinsame Basis. Im Feld entstehen jedoch unterschiedliche Zustände, sobald Kunden Funktionen aktivieren oder Softwareupdates erhalten. Zwei Fahrzeuge mit identischer Hardware können dadurch verschiedene Softwarestände und Funktionsumfänge aufweisen. Bei einer Änderung muss der OEM deshalb schnell erkennen können, welche Fahrzeuge betroffen sind, welcher freigegebene Stand zu ihnen gehört und wie die Änderung ausgerollt wird.

Diese Aufgabe endet nicht an der Unternehmensgrenze. OEMs, Zulieferer, Softwareanbieter und Engineering-Dienstleister arbeiten gemeinsam an Fahrzeugfunktionen und müssen auch nach dem SOP Informationen über Softwarestände, Abhängigkeiten und Freigaben austauschen. Aus der Übergabe eines Entwicklungsstands wird damit zunehmend eine längerfristige Betreuungsbeziehung. Für die beteiligten Unternehmen braucht es klare Zuständigkeiten und belastbare Abläufe, damit Änderungen auch über die Auslieferung hinaus nachvollziehbar in den Kontext des Gesamtfahrzeugs eingeordnet werden können.

Wo Informationen verloren gehen

Die Herausforderung liegt dabei häufig weniger in einzelnen Engineering-Bereichen als in den Übergaben zwischen ihnen. Informationen verteilen sich auf unterschiedliche Systeme und Teams. Ändert beispielsweise ein Zulieferer eine Softwarekomponente, reicht die Versionsnummer für die Bewertung beim OEM nicht aus. Sie muss mit der betroffenen Fahrzeugfunktion, den relevanten Konfigurationen und dem gültigen Freigabestand in Zusammenhang gebracht werden. Fehlen diese Verbindungen, beginnt die Suche nach dem Kontext häufig in Tabellen, E-Mails oder lokalen Dokumenten.

Mit wachsender Zahl an Funktionen, Varianten und Softwareständen stoßen solche Abläufe an Grenzen. Der Engpass entsteht dann nicht unbedingt bei der Entwicklung einer Änderung, sondern bei der Bewertung ihrer Auswirkungen. Die Zusammenhänge zwischen Softwareständen, Funktionen, Konfigurationen und Freigaben müssen erhalten bleiben, damit Änderungen schnell bewertet werden können, ohne den benötigten Kontext bei jedem Prozessschritt neu zusammensuchen zu müssen.

IPL als technische Grundlage

Der Intelligent Product Lifecycle (IPL) kann die technische Grundlage dafür schaffen, Informationen aus Produktentwicklung, Softwareentwicklung und Fahrzeugbetrieb miteinander zu verbinden. Änderungen lassen sich dadurch im Kontext der betroffenen Funktionen, Konfigurationen und Freigaben betrachten, statt einzelne Datenpunkte in unterschiedlichen Systemen zusammensuchen zu müssen. Dafür müssen OEMs und Zulieferer ihre bestehenden Systeme nicht zwangsläufig ersetzen. Relevante Informationen müssen vielmehr über System- und Unternehmensgrenzen hinweg in ihrem Zusammenhang nutzbar bleiben. So können Daten aus unterschiedlichen Engineering-Bereichen miteinander verknüpft werden, ohne dass alle Beteiligten in derselben Systemlandschaft arbeiten müssen.

Der Intelligent Product Lifecycle ersetzt dabei weder klare Prozesse und Zuständigkeiten noch vertragliche Regelungen zwischen den beteiligten Unternehmen. Eine neue Softwarelösung allein löst das Problem verteilter Informationen nicht. Die technische Grundlage kann jedoch dafür sorgen, dass der benötigte Kontext verfügbar ist, wenn eine Änderung bewertet, freigegeben oder in die Flotte gebracht werden soll. Damit wird die Verfügbarkeit zusammenhängender Produktinformationen auch zu einem Geschwindigkeitsfaktor. Je weniger Zeit OEMs und Zulieferer darauf verwenden müssen, Abhängigkeiten und Auswirkungen einer Änderung zusammenzusuchen, desto schneller können sie Entscheidungen absichern und Softwareänderungen kontrolliert in die Fahrzeuge bringen.

Verantwortung bis ins Feld

Der SOP bleibt der Start der Produktion. Für ein Software-Defined Vehicle markiert er zugleich den Beginn einer Phase, in der Funktionen weiterentwickelt, aktiviert und betreut werden. Produktverantwortung endet damit nicht mit der Auslieferung, sondern erstreckt sich zunehmend über die gesamte Nutzungsdauer des Fahrzeugs.

Die wirtschaftliche Perspektive des Software-Defined Vehicle hängt deshalb eng mit der technischen und organisatorischen Umsetzung zusammen. Softwarefunktionen können langfristig zum Geschäft beitragen, wenn ihre Entwicklung, Freigabe und Pflege auch nach dem SOP beherrschbar bleiben. Für OEMs und Zulieferer kommt es damit darauf an, Verantwortung und Produktinformationen über den gesamten Produktlebenszyklus zusammenzuführen.

Text und Bild: PTC

Über den Autor

Michele Del Mondo startete seine Karriere nach dem Maschinenbaustudium 1994 am Steinbeis-Transferzentrum in Karlsruhe. 1997 wechselte er zu Webasto und leitete die Einführung eines unternehmensweiten PLM-Systems. Später übernahm er als Director Sales die Verantwortung für den globalen Vertrieb für die Mercedes Car Group. Seit 2011 ist er bei PTC tätig und verantwortet als Global