Betriebssysteme werden Systems Engineering stärken
OS-basierte Produktarchitektur
Die erhöhte Komplexität durch neue service- und lösungsbasierte Angebote erfordert die Einführung neuer Betriebssysteme. Es soll verhindert werden, dass diese Komplexität direkt auf das mechatronische System durchschlägt, welches unter dieser zusätzlichen Last zusammenbrechen würde. Technisch gesehen muss eine Zwischenschicht als Vermittler zwischen der Welt der Software und der Welt der Mechatronik fungieren. Dies ist entscheidend, weil sie eine Entkopplung der Mechatronikwelt von der Service- und Lösungswelt ermöglicht. Sie entlastet die Mechatronikwelt von der Komplexität der Dienste, indem sie eine abstrakte Betriebssystemschicht mit wohldefinierten, softwarebasierten Systemschnittstellen einführt, die sich mit den Mechatronikkomponenten verbinden. Im gleichen Zuge findet eine Vereinfachung der Mechatronikwelt statt. Ähnlich wie das Betriebssystem eines Computers ist ein Kfz-Betriebssystem ein Softwaresystem, das die Computer-Hardware und die Software-Ressourcen verwaltet und gemeinsame Dienste für Computerprogramme bereitstellt, die in einem Fahrzeug verwendet werden. Und genau dafür sind zentrale Betriebssysteme, wie wir sie von Computern und mobilen Geräten kennen, gut geeignet. Das OS reorganisiert die Funktionalität der heute vielfältigen Kommunikationsbuskomponenten und Bordelektroniksysteme, so dass auch ein einheitliches Management der Mechatronikwelt einfacher wird.
Die Entwicklung der Produktarchitektur im Laufe der Zeit ist in Abbildung 1 dargestellt. Der Einfachheit halber unterscheide ich nur drei historische Phasen: Gestern benötigte der Kunde ein mechatronisches System plus Anwendungen (z. B. verschiedene festverdrahtete Fahrmodi, eingebauter Navigationsdienst). Der Kunde musste sich selbst um die Mobilitätsdienste kümmern (z. B. neue Karten herunterladen, um das Navigationssystem zu aktualisieren, das Auto zur Inspektion in die Werkstatt bringen). Heute haben wir ein hybrides System, der Kunde benötigt Services und der OEM stellt spezifische Dienstleistungen zur Verfügung (z.B. Finanzierung oder blinkende Services für On-Board-Entertainment), während der Kunde sich immer noch um die meisten seiner Mobilitätsservices kümmern muss (z.B. die Organisation von Fahrten). Zukünftig benötigt der Kunde High-End-Services und -Lösungen wie autonomes Fahren oder ausgelagertes Flottenmanagement für Firmenkunden und der OEM könnte als Service- und Lösungsanbieter auftreten (z.B. "reach now", ehemals [1] "moovel", [2] daimler lkw).
Technologie-Stack vs. Geschäftsmodelle
Es ist jedoch wichtig, die technologischen Aspekte der Systemdisziplinen nicht mit den geschäftlichen Aspekten der Angebote zu verwechseln. Die Technologie wird verwendet, um die Geschäftsmodelle zu realisieren. Abbildung 2 stellt die beiden System- und Servicedisziplinen entlang einer Zeitskala gegenüber. Eine zukünftige Entwicklung wird die Integration von Mobilitätslösungen in Smart Cities sein. Corwin und Pankratz [3] von Deloitte sowie Guo und Hai [4] haben eine interessante Darstellung der zukünftigen Stadtentwicklung gegeben. Sie beschreiben ein Mobilitätsbetriebssystem als eine Plattform, die auf drei Dimensionen der Reife basiert: Geographie, Transportmittel und -modi sowie Fähigkeiten. [5] Keupp et.al. der Boston Consulting Group beschreiben, wie Mobilitätsplattformen Endnutzer mit verschiedenen Verkehrsbetrieben verbinden.
Fokus auf Business Service Portfolios erfordert kohärente Geschäftsdaten entlang des Produktlebenszyklus und darüber hinaus
Die wichtigste Auswirkung dieser Entwicklung ist die Ausrichtung der OEM-Entwicklungsstrategien auf ein kundenzentriertes Dienstleistungsportfolio. Das macht die Softwareentwicklung viel wichtiger als früher und lässt sie scheinbar sogar zur vorherrschenden Disziplin werden. Welchen Einfluss haben die Business-Services auf den Produktlebenszyklus? Wie oben skizziert, wird die Komplexität durch die Serviceebene bestimmt und geht über das hinaus, was wir bisher gesehen haben - auch wenn die Elektrifizierung das technische System unterhalb des Betriebssystems weniger komplex macht. Daher werden Systems Engineering und intelligentes Frontloading noch wichtiger. Hinzu kommt, dass neue Business-Services wie das autonome Fahren dem OEM die Haftung und Beweislast auferlegen. Daher werden leistungsfähige Traceability-Funktionen benötigt, die nicht nur den Produktlebenszyklus, sondern auch die Lieferkette abdecken. Die Interdependenzen zwischen diesen drei Dimensionen (siehe Abbildung 3) lassen sich auf natürliche Weise durch einen Knowledge Graph darstellen. In einem einer existierenden Datenlandschaft muss dieser aus den im Autorensystem befindlichen Daten berechnet werden. Dies wiederum erfordert den Einsatz von ausgefeilten Data Analytics-Methoden. Matthias Ahrens zitiert einen Artikel von Peter Louis und Ralf Russ von Siemens, die Data Analytics als ein Vehikel sehen, um Data Science und Engineering zu verbinden
Eine erfolgreiche Implementierung erfordert systematische Vorgehensweisen für das Management und die Analyse von Daten, aber heute sind solche Vorgehensweisen nicht in den PLM-Prozessen enthalten.
Da unser Verständnis des Digitalen Zwillings ganzheitlich ist, müssen wir sogar über die Disziplinen hinausgehen. Wir behaupten, dass das gesamte Potenzial des Digitalen Zwillings nur dann ausgeschöpft werden kann, wenn wir neben der Systemdimension auch den Produktlebenszyklus und die Lieferkette vernetzen. Nur dann ist es möglich, neue Geschäftsmodelle auf Basis von Dienstleistungen (Connected Use Cases) zu realisieren und sowohl die Qualität als auch die Effektivität und Effizienz zu steigern. Im Falle von existierenden IT-Landschaften kann Datenvernetzung sogar ein sehr intelligentes Werkzeug sein, um von der Welt von heute in die Welt von morgen zu migrieren, da man zwei Fliegen mit einer Klappe schlagen kann. Verbessern Sie heute Ihre Geschäftsprozesse und seien Sie bereit für das serviceorientierte Geschäft von morgen.
Fazit
Zusammenfassend lässt sich sagen, dass das Systems Engineering vor nie dagewesenen Herausforderungen steht, die es in der Vergangenheit nicht gab. Systems Engineering als ganzheitliche, interdisziplinäre Managementmethode braucht leistungsfähige Werkzeuge, um diese Herausforderungen zu bewältigen. Eine wichtige bezieht sich auf die effiziente Informationsbereitstellung für alle beteiligten Rollen entlang der Lebenszyklen, um die Informationsketten entlang der Systeme auf und ab gehen zu können - sei es durch Menschen oder Maschinen. Diese Sichtweise des Digitalen Zwillings als ganzheitliche Einheit, die sich über interne Prozesse und sogar darüber hinaus erstreckt, kann nur durch die Verwendung der natürlichsten Art der Darstellung von Konnektivität entlang der Lebenszyklen erreicht werden: den Knowledge Graphs. Sie sind die technologische Antwort auf die ganzheitliche Herausforderung, mit der das Systems Engineering konfrontiert ist. Knowledge Graphen garantieren auf diese Weise verknüpfte Daten über den Lebenszyklus hinweg und liefern den notwendigen Geschäftskontext. Ausgehend vom von einer existierenden Datenlandschaft könnten OEMs mit Knowledge Graphen zwei Fliegen mit einer Klappe schlagen: die Verknüpfung von mechatronischen Datenbeständen zur Verbesserung der Geschäftsprozesse während der Übergangszeit (von der aktuellen Systemarchitektur zur neuen) und die Nutzung der resultierenden Knowledge Graphen zur Verbindung mit den Service- und Applikationsdaten oberhalb des Betriebssystems.
Siehe auch:
- New OEMs Business Models Change Product Development from Head to Toe
- Does conceptional confusion lead to a search for a new label for PLM?
- Linked Data Connectivity – Graphs are the Crux of the Biscuit
