Führt konzeptionelle Unschärfe zu einer Suche nach einem neuen Label für PLM?
Entwicklung von Graph-basierten Anwendungsfällen
Da unsere Kunden eine existierende Datenlandschaft besitzen, liegt der Schwerpunkt für uns auf der automatisierten Berechnung von Graphen, die aus diesen Daten abgeleitet und in vorgegebenen Autorensystemen gespeichert werden. Ein Projekt beginnt in der Regel mit der Implementierung einer Reihe Graph-basierter Anwendungsfälle. Solche Anwendungsfälle werden typischerweise durch den Informationsbedarf einer oder mehrerer Benutzerrollen getrieben. Zum Beispiel benötigt ein Bauteilverantwortlicher - eine Engineering-Rolle, die für eine technische Komponente innerhalb des gesamten V-Modells verantwortlich ist - natürlich Daten aus verschiedenen Datensystemen, um seinen Geschäftskontext zu bilden: z.B. die Anforderungen an die Komponente aus dem Anforderungsmanagementsystem, die Komponenten, zu denen sie gehört, aus der Stückliste, den Freigabestatus aus einem Business Warehouse, usw. Der Bauteilknoten des Graphen stellt dann den Kern eines Teilgraphen des Digitalen Zwillings dar, für den dieser Ingenieur verantwortlich ist. Wir stellen dem Ingenieur dann ein Dashboard zur Verfügung, anhand dessen er die Komponenten, für die er verantwortlich ist, verwalten kann.
Unsere Erfahrung zeigt, dass der anfängliche Knowledge Graph aus diesem ersten Satz von Anwendungsfällen gleichzeitig der Beginn einer Reise ist, die unsere Kunden dazu führt, neue Graph-Anwendungsfälle für weitere Geschäftsrollen zu entdecken und hinzuzufügen. In vielen Fällen bedeutet dies das Hinzufügen neuer Datenquellen, die vom Graphen abgedeckt werden sollen. Sogar ganz andere Unternehmensfunktionen können mit ihren Anforderungen aufwarten; z.B. verlangte die Beschaffung eines Kunden Benachrichtigungsfunktionen bei Konstruktionsänderungen, um den Ausschuss von Teilen zu reduzieren und so die Kosten erheblich zu senken und die Produktion mit dem richtigen Nachschub zu versorgen. Wichtige Erfolgsfaktoren für ein solches inkrementelles Modell sind:
- Bottom-up-Design: von einem gegebenen Satz von Anwendungsfällen ausgehen und inkrementell erweitern
- Geschwindigkeit: Konfiguration von Graphen-Anwendungsfällen in nur wenigen Wochen
- Befähigte Kunden und Servicepartner: Schulung des Kunden und seiner Servicepartner, damit sie die Konfiguration selbst vornehmen können
Als diese Anforderungen erfüllt waren, konnten wir in kürzester Zeit mehrere Dutzend Anwendungen auf den bestehenden Graphen aufsetzen. Aber das ist nur die Hälfte der Geschichte. Man könnte sagen, dass dies den Kunden bereits dabei hilft, Investitionen in ihre Dateninfrastruktur zu nutzen, da der Graph-Ansatz hilft, das Potenzial zur Wiederverwendung von Entwicklungsleistungen zu heben.
Betrachten wir jedoch die Benutzerrollen im Unternehmen, die innerhalb von Kernprozessen arbeiten (z. B. Ingenieurstypen), so benötigen diese vielleicht nur hin und wieder bestimmte Kontextinformationen aus anderen Datensystemen. Ein Beispiel könnte ein Benutzer sein, der vor seiner After-Sales-Produktdatenbank sitzt und sich auf eine bestimmte Glasscheibe konzentriert. Er benötigt vielleicht Daten aus Drittanwendungen wie "wo verwendet", "Erscheinungsdatum", "wo produziert" usw. In diesem Fall wäre es praktisch, wenn die benötigten Daten den Benutzer finden würden, anstatt dass der Benutzer nach den Daten sucht. Idealerweise sollte kontextbasiertes Wissen von Dritten durch das Autorensystem zur Verfügung gestellt werden, wenn es benötigt wird. Für den Benutzer sollte es sich so nahtlos anfühlen, als ob das hinzugefügte Kontextwissen vom System selbst bereitgestellt wurde. Dies setzt voraus, dass der Graph leicht in die gegebenen Autorensysteme eingebettet werden kann. Ob eine Anwendung auf dem Graphen oder als ein in ein Autorensystem eingebetteter Dienst entworfen werden muss, kann davon abhängen, in welchem Umfang vernetzte Daten vom Benutzer grundsätzlich benötigt werden. Es kann aber auch von der Notwendigkeit der Vereinfachung der IT-Landschaft getrieben sein. Eine logische Konsequenz aus dieser vielfältigen Nutzung des Geschäftskontextes ist es daher, eine Graph-as-a-Service-Schnittstelle anzubieten, durch die jede Art von Anwendung oder auch Maschinen von dem im Graphen gespeicherten Geschäftskontextwissen profitieren können. Wesentlich für dieses Design ist, dass der Graph eine verknüpfte Datenschicht darstellt, die von den eigentlichen Daten abstrahiert und entkoppelt ist.
Wie können wir Digital Twins und Digital Threads definieren?
Das Konzept des Digitalen Zwillings stammt ursprünglich aus der Luft- und Raumfahrtindustrie (erfunden von Michael Grieves in 2002). Alan Bachan, VVizepräsident bei ICF, definiert es wie folgt:
Ein Digitaler Zwilling ist die virtuelle Repräsentation eines Produkts, einer Anlage oder eines Systems, die das physische Objekt mit aktuellen Bestands- und Betriebsdaten exakt nachbildet,
während der Digital Thread
sich auf ein Kommunikations- und Datenfluss-Frameworkbezieht, das eine integrierte Sicht auf die Daten eines Produkts oder einerAnlage während des gesamten Lebenszyklus ermöglicht.
Rainer Stark vom Fraunhofer IPK erklärt dazu
Ein Digitaler Zwilling ist eine digitale Repräsentation eines aktiven, einzigartigen Produkts (reales Gerät, Objekt, Maschine, Dienstleistung oder immaterieller Vermögenswert) oder eines einzigartigen Produkt-Service-Systems (ein System, das aus einem Produkt und einer zugehörigen Dienstleistung besteht), das seine ausgewählten Merkmale, Eigenschaften, Bedingungen und Verhaltensweisen mittels Modellen, Informationen und Daten innerhalb einer einzigen oder sogar über mehrere Lebenszyklusphasen hinweg umfasst.
Wenn wir diese Aussagen in Graphen-Sprache übersetzen und mit dem inkrementellen, konstruktiven Ansatz zur Generierung eines Enterprise Knowledge Graphen kombinieren, dann können wir feststellen, dass ein Digital Thread das Graphdatenmodell eines Digital Twin darstellt. Warum ist das so? Wir könnten argumentieren, dass die Erstellung des Graphen nichts anderes ist als der Versuch, Konnektivität aus unverbundenen Daten zu rekonstruieren, die aus einem komplexen Produktlebenszyklusprozess resultieren. Dies setzt voraus, dass Konnektivität implizit bereits existiert, aber nicht explizit erfasst wird.
Ein konkreter Digitaler Zwilling könnte sich dann auf jede Art von materiellem oder immateriellem Objekt beziehen. Dies hängt vom Interesse der gewünschten Erkenntnis ab. Im Falle von Flugzeugen oder Autos könnte es sich um das gesamte Auto oder Flugzeug, eine Komponente oder einen Service handeln. Im Falle einer Pandemie könnte es die Darstellung der Welt, eines Landes, einer Region oder eines Ortes zusammen mit Krankheitssymptomen und Personendaten sein (denken Sie an Infektionsketten). In Bezug auf Graphen kann es durch einen Satz semantischer Relationen wie "part-of", "used-in", "belongs-to" oder jede Art von Regel definiert werden, die angibt, wie ein Objekt den Mittelpunkt eines Satzes von Relationen darstellt, die für den Beobachter sinnvoll sind. Es gibt also eine gewisse Relativität in der Definition dessen, was ein Digitaler Zwilling sein könnte, und dementsprechend wird sich dies auf sein definierendes Graphenmodell auswirken. Dieser Logik folgend, nutzen konkrete Graph-Anwendungsfälle wie die oben genannten Digital Twins (Graphinstanzen eines Digital Threads). Wenn der Begriff des Digital Threads, wie er von vielen Autoren zu Recht definiert wird, über den gesamten Lebenszyklus von der Idee über das Design (bzw. die Konstruktion), die Fertigung (bzw. Produktion), den Betrieb, die Wartung (bzw. den Service) und die Ausmusterung reicht, dann dient jede Graph-basierte Anwendung oder jeder eingebettete Dienst im Wesentlichen dem Management des Produktlebenszyklus. Der evolutionäre Prozess der Graphkonstruktion kann somit als Konvergenz zum Knowledge Graph des Produktlebenszyklus interpretiert werden. Basierend auf einem solchen Knowledge Graph kann ABB’s Vision einer
Möglichkeit, von einem gemeinsamen Digitalen Zwillingsverzeichnis aus auf Daten zuzugreifen, die an verschiedenen Orten gespeichert sind, was Simulation, Diagnose, Vorhersage und andere fortgeschrittene Anwendungsfälle ermöglicht
schnell zu einer Lösung werden, wenn die oben genannten Erfolgsvoraussetzungen erfüllt sind. Das Verzeichnis wird dann zu einem vollständigen Graphen.
Wie kann PLM von einerGraph-basierten Definition von Digital Thread/Twin profitieren?
In seinem Blog: “Digital Thread and Digital Twins - are those new names to replace PLM?” hat Oleg die Diskussion aufgegriffen, ob PLM durch solche neuen Konzepte ersetzt werden sollte. Ich denke, dies spiegelt wider, dass es in der Fachwelt eine ziemliche Begriffsverwirrung zu Themen wie "Digital Twin", "Digital Thread", "Systems Engineering/MBSE" und "PLM" gibt. Aber wenn wir eine prägnante Definition dessen haben, was ein Digital Thread und ein Digital Twin wie oben angegeben sind, oder bedeuten, dann ist die Anwendung der Graphtechnologie der natürliche und angemessene Weg, und PLM macht einfach Gebrauch von einer ganzheitlichen Form der Datenrepräsentation. Und dies zollt dem ursprünglich beabsichtigten Anwendungsbereich von PLM als Integrationsmethode für Menschen, Daten, Prozesse und Geschäftssysteme als auch als Anbieter eines Produktinformations-Backbones Tribut. Wie passt das Systems Engineering in diesen Rahmen? Sehr gut, denn es handelt sich um eine Konstruktionsmethodik, bei der Daten aus Domänen über den gesamten Lebenszyklus eine entscheidende Rolle spielen. Die domänenübergreifende Bereitstellung von Daten entlang des Lebenszyklus ist wiederum die wesentliche Aufgabe von PLM und erst recht des [8] SysLM-Ansatzes. Der oben erwähnte evolutionäre Graphkonstruktionsprozess unterstützt den inkrementellen Aufbau des ganzheitlichen Informationsrückgrats, wie er von PLM gefordert wird. Das Systems Engineering ist oft der Ausgangspunkt dieser PLM-Reise. In einem deutschen PLM-Blog habe ich einen Artikel von Markus Ripping von Sartorius gefunden, der den Rat gibt, die Erfindung neuer Buzz-Words zu reduzieren.
Er hat Recht, das ist nicht nötig!
