.svg)
Warum Digital-Twin-Datenmodellierung entscheidet, ob ein Twin funktioniert
Die meiste Aufmerksamkeit bei Digital Twins gilt dem Modell selbst: der 3D-Ansicht, der Analytik, dem Dashboard. Dort geht selten etwas schief. Ein Twin auf guter Simulationssoftware liefert trotzdem falsche Antworten, wenn die Daten, die ihn speisen, unvollständig oder veraltet sind.
Ein Twin schöpft aus drei Systemarten zugleich. Er bezieht Konstruktionsdaten, etwa Teile und Stückliste, aus dem PLM. Er bezieht Auftrags-, Kosten- und Bestandsdaten aus dem ERP. Und er bezieht Live-Messwerte, etwa Temperatur oder Vibration, von den Sensoren an den Maschinen. Jedes dieser Systeme wurde für seine eigene Aufgabe gebaut, mit eigenen Datenformaten und eigenem Aktualisierungstempo.
All das zu einem genauen, aktuellen Bild zusammenzuführen ist der schwierige Teil, und es ist ein Datenproblem, bevor es ein Simulationsproblem ist. Wie die Daten des Twins strukturiert sind, woher sie kommen und wie frisch sie bleiben, entscheidet, ob das Modell der Realität entspricht oder langsam von ihr wegdriftet. Das beginnt mit einer Unterscheidung, die oft verwischt wird.
Was ist der Unterschied zwischen Digital Twin und Digital Thread?
Der Digital Thread ist die verknüpfte Datenaufzeichnung eines Produkts über sein gesamtes Leben, und der Digital Twin ist das lebende Modell, das auf dieser Aufzeichnung aufsetzt und sie zum Simulieren und Vorhersagen nutzt. Die beiden werden üblicherweise verwechselt, doch sie erledigen unterschiedliche Aufgaben, und der Unterschied zählt hier.
Das eine speist das andere. Ein Twin ohne soliden Thread ist ein Modell, das auf Mutmaßungen läuft, weil es keine verlässliche Historie und keinen aktuellen Zustand hat, mit dem es arbeiten könnte. Für die meisten Hersteller ist die erste Aufgabe deshalb, PLM, ERP und MES zu verbinden, um diesen Thread zu bilden, und der Twin ist das, was die verbundenen Daten in etwas Nützliches verwandelt. Den Twin als Bildschirm zu behandeln, der am Ende angeschraubt wird, statt als etwas, das von gut organisierten Daten abhängt, ist der Weg, auf dem teure Twin-Projekte am Ende das Falsche modellieren.
Was heißt es eigentlich, die Daten eines Digital Twins zu modellieren?
Es heißt, sich auf eine Struktur zu einigen, in die jedes Quellsystem einspeist, sodass der Twin eine einzige, konsistente Beschreibung eines Assets liest statt eines Dutzends, das nicht zusammenpasst. Die Formatfrage kommt vor der Simulationsfrage.
Hier ist die Asset Administration Shell, kurz AAS, zur gängigen Referenz geworden. AAS ist eine vereinbarte, standardisierte Art, ein industrielles Asset als Digital Twin zu beschreiben. Sie wird von der Industrial Digital Twin Association gepflegt und ist als internationaler Standard veröffentlicht, also an keinen einzelnen Anbieter gebunden. Ein Asset wird über Submodelle beschrieben, wobei jedes Submodell einen Teil des Bildes abdeckt: das Typenschild, die Dokumente, die Sensorhistorie oder die Stückliste.
Einen Twin auf einem Standard wie AAS aufzubauen gibt all diesen Daten einen Ort zum Landen. Eine Konstruktionsdatei aus dem PLM, ein Arbeitsauftrag aus dem ERP und ein Sensormesswert lassen sich jeweils auf ein definiertes Submodell mit vereinbarter Bedeutung mappen, statt für jede neue Maschine von Hand verdrahtet zu werden. Genau das lässt einen Twin über einen einzelnen Versuch hinauswachsen, denn das hundertste Asset wird genauso beschrieben wie das erste. AAS reift noch, und nicht jedes Asset braucht einen vollständigen Live-Twin, deshalb ist der vernünftige erste Schritt, die wenigen Submodelle zu modellieren, die echte Entscheidungen tragen.
Aktuelle Daten sind es, die einen Twin genau halten
Ein gemeinsames Datenmodell gibt dem Twin seine Struktur. Dieses Modell aktuell zu halten ist es, was das Abdriften stoppt. Ein Twin ist nützlich, weil er das Asset so zeigt, wie es jetzt ist, nicht wie beim Datenexport von gestern Abend. In dem Moment, in dem seine Daten hinter der echten Linie zurückbleiben, basiert jede seiner Vorhersagen auf einer Version der Fabrik, die sich bereits verändert hat.
Das ist das stille Scheitern hinter vielen Twin-Projekten. Ein Twin, der von geplanten nächtlichen Exporten gespeist wird, wirkt in der Demo überzeugend und wird im Alltag unzuverlässiger, weil die Lücke zwischen Modell und Maschine stündlich wächst. Event-getriebene Updates schließen diese Lücke, sodass eine Änderung auf dem Shopfloor den Twin in Sekunden oder Minuten erreicht statt am nächsten Tag. Echtzeit-Simulationsdaten sind auch das, was verwandte Anwendungen wie Predictive Maintenance funktionieren lässt, denn ein Modell, das einen Teileausfall vorhersagt, ist nur so gut wie die Frische der Sensordaten dahinter.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
