Neue PLM-Anforderungen für die Fahrzeuge von morgen

Immer mehr Fahrzeugfunktionen werden über Software definiert. Welche Anforderungen das Software-Defined Vehicle (SDV) an Entwicklungsprozesse und -werkzeuge stellt, erläutern Daniel Baldus, Principal und PLM-Berater bei der UNITY AG, und Dr. Patrick Müller, Chief Customer Officer bei CONTACT. Beide Unternehmen arbeiten in der Prozess- und Methodenberatung Hand in Hand.

Software im Fahrzeug gibt es schon lange. Was macht ein Fahrzeug zum Software-Defined Vehicle?

Baldus: Über 100 Jahre lang wurde der Automobilbau aus einer mechanischen Denkweise getrieben und die Software-Entwicklung dem untergeordnet. Jetzt wandelt sich die Philosophie grundlegend. Hersteller gehen davon aus, dass es schneller und kostengünstiger ist, das gesamte Fahrzeug so zu entwickeln wie Software.

Müller: Software kommt nicht mehr nur auf Komponentenebene, sondern als ganzheitliche Architektur zum Einsatz. Dazu kommt ein Prozess, der ein kontinuierliches Deployment ermöglicht, und die Notwendigkeit, jederzeit den Fahrzeugzustand inklusive der Software zu kennen oder erkennen zu können.

Was bedeutet das für die PLM-Systemlandschaft?

Müller: Zur klassischen Schichten-Architektur mit ERP-, PDM/PLM-, TDM- und Autorensystemen kommt womöglich eine weitere, explizite Schicht für das Konfigurations- und Change-Management. Daneben wird es ein Application Lifecycle Management (ALM) und Source Code Management (SCM) für die Verwaltung von Requirements und Software-Code geben, die zu gewissen Anteilen auch im PLM verankert werden. Wichtig ist ein System, das den übergreifenden Reifegradprozess mit dem DevOps-Prozess für die Software-Entwicklung verbindet.

Baldus: PLM-Systeme werden sich weiterentwickeln müssen, um Daten aus Silos zu verknüpfen und vorausschauend auszuwerten. Sie werden sich viel stärker in Richtung End-to-End-Prozesse bewegen, um das Produkt auch in nachgelagerten Prozessen zu verfolgen. Dieses Produkt-Tracking gibt Aufschluss darüber, welche Software ich aufspielen und welche Services ich anbieten kann.

 

Welchen Stellenwert hat das durchgängige Datenmanagement für das Thema SDV?

Baldus: Auf der grünen Wiese würde sich das Thema Datendurchgängigkeit einigermaßen einfach darstellen. Das Problem sind die Altdaten, die sich über 30 Jahre in verschiedenen Silos aufgebaut haben und deren Stände untereinander inkonsistent sind.

Müller: Um das „aufzuräumen“, braucht es PLM-Technologie mit flexiblen Datenmodellen und Automatismen, die klassische PLM-Automation und Datenintegrität mit neuen Möglichkeiten der KI-Unterstützung verbinden. PLM-Technologie kann sich aufgrund ihrer Vorzüge im Datenmodell im Kontext des SDV immer mehr zum zentralen Tool für die Datenorchestrierung entwickeln.

Wodurch unterscheiden sich Ansätze der verschiedenen PLM-Anbieter beim Thema SDV?

Baldus: Viele PLM-Anbieter versuchen, ihr Angebot in diese Richtung mit dem Zukauf von Autoren-Systemen zu erweitern – können diese dann aber nur mühsam in eine durchgängige Toolchain integrieren. Außerdem haben die wenigsten PLM-Hersteller flexible Architekturen, die es erlauben, Software anders zu handhaben als Hardware. Das ist aber eine entscheidende Voraussetzung für das SDV.

Müller: Im Grunde sind diverse PDM-Systeme nicht ideal für die Verwaltung von Software-Kompatibilitäten ausgelegt. Allerdings eignen sich manche Systeme besser als andere. Unser Ziel ist es, Standard-Funktionen zu entwickeln, mit denen sich mechatronische Komponenten wie aus einem Baukasten in Baureihen integrieren und mit den entsprechenden Software-Ständen und Kompatibilitäten verbinden lassen. CONTACT Elements tritt dabei als PLM-Herausforderer an. Wir sind uns unserer Fähigkeiten und Differenzierungsmerkmale sicher.

Inwieweit lassen sich die Veränderungen im Zusammenhang mit dem SDV auch auf andere Branchen übertragen?

Baldus: Nicht die Branche ist entscheidend, sondern die Art der Produkte. Produkte mit Software-Anteil gibt es inzwischen in vielen Industrien – überall dort machen Lösungen wie in der Automobilindustrie Sinn. Eine große Chance für Unternehmen liegt auch darin, dass sich mechatronische Produkte viel standardisierter entwickeln und herstellen lassen als die rein mechanischen Produkte der Vergangenheit.

Unterscheidet sich das nicht vom CONTACT-Ansatz mit den industriellen Blaupausen für verschiedene Branchen?

Müller: Tatsächlich nicht. Bei den industriellen Blueprints geht es vielmehr um branchenspezifische Prozesse, etwa mit Blick auf spezielle Richtlinien. Gemeinsamkeiten ergeben sich aber in der Zusammenführung der Disziplinen. Da bin ich mit Daniel völlig einer Meinung: Die Denkweise des Software Defined Products gilt für die gesamte Fertigungsindustrie, auch wenn die Ausprägung für einen Fahrzeugbauer eine andere ist als für einen Anlagenbauer.