Wenn wir mit Unternehmen über digitale Zwillinge sprechen, haben die meisten zunächst ein recht klares Bild vor Augen. Häufig ist es ein 3D-Modell eines Lagers oder einer Produktionsumgebung, ergänzt um Live-Daten: den Status der Fördertechnik, aktuelle Durchsätze und Auslastungen oder die Position von Fahrzeugen.
Solche Anwendungen sind sinnvoll und geben einen guten Überblick über den laufenden Betrieb. In der häufig zitierten Klassifikation von Kritzinger et al. fallen sie allerdings eher in die Kategorie des digitalen Schattens als in die des digitalen Zwillings.
Modell, Schatten, Zwilling
Kritzinger et al. (2018) unterscheiden digitale Abbilder danach, wie Daten zwischen dem physischen und dem virtuellen System ausgetauscht werden. Bei einem digitalen Modell findet kein automatisierter Datenaustausch statt. Ein CAD-Layout, ein Laserscan oder ein 3D-Modell können Beispiele dafür sein.
Bei einem digitalen Schatten fließen Daten automatisiert aus der realen Welt in das digitale Modell. Ändert sich der Zustand des physischen Systems, wird diese Änderung auch digital sichtbar. Der Datenfluss endet jedoch dort. Erst wenn der Austausch automatisiert in beide Richtungen erfolgt, sprechen die Autoren von einem digitalen Zwilling. In ihrer Literaturübersicht waren Arbeiten zu dieser höchsten Integrationsstufe damals deutlich seltener als Arbeiten zu digitalen Modellen und Schatten.
Ein reines 3D-Modell steht damit am Anfang dieser Entwicklung. Es kann sehr genau sein und für Bauplanung, Layoutdiskussionen oder Dokumentation wertvolle Dienste leisten. Mit dem laufenden Betrieb ist es aber nicht verbunden. Es verändert sich nicht, wenn eine Gasse vollläuft oder eine Schicht später beginnt als geplant.
Live-Daten bringen das Modell einen Schritt weiter. Jetzt wird sichtbar, was im Moment passiert. Für viele Fragestellungen ist genau das ausreichend. Die Grenze zeigt sich dort, wo nicht mehr nur der aktuelle Zustand interessiert, sondern die Frage, was passieren würde, wenn man etwas verändert.
Warum Live-Daten nicht genügen
Nehmen wir ein Blocklager. Die Live-Daten zeigen, dass eine Gasse überlastet ist und sich Umlagerungen häufen. Sie zeigen aber nicht, ob die Ursache in der Gassentiefe liegt, in der Zuordnung der Artikel zu den Gassen oder in der Reihenfolge, in der die Aufträge eintreffen. Und sie beantworten auch nicht, welche dieser Stellschrauben man am sinnvollsten verändert.
Dafür braucht es ein Modell, das die Logik hinter dem Betrieb kennt und unterschiedliche Varianten berechnen kann.
Das Gleiche gilt in der Produktionslogistik. Live-Daten können zeigen, dass eine Linie auf Material wartet oder sich Puffer füllen. Ob die Ursache in der Nachschubsteuerung, der Sequenzierung, einer zu geringen Transportkapazität oder in der Produktionsplanung liegt, lässt sich daraus allein nicht ableiten.
Der zweite Teil ist die Rückwirkung auf den realen Betrieb. Ergebnisse aus dem Modell müssen dort ankommen, wo sie gebraucht werden: etwa als überarbeiteter Slotting-Plan, als neue Auftragsreihenfolge, als Transportauftrag an eine gemischte Flotte aus FTS und AMR über VDA 5050 oder als Buchung, die in ein WMS oder ERP zurückgeschrieben wird.
Läuft die Entscheidung noch über einen Menschen, wird dieser Regelkreis manuell geschlossen. Bei einer automatisierten Rückkopplung übernehmen angeschlossene Systeme diesen Schritt direkt. Für die Systemspezifikation ist dieser Unterschied wichtig, weil dafür ganz andere Schnittstellen erforderlich sind.
Wie W2MO den Regelkreis schließt
Bei W2MO läuft die Verbindung in die eine Richtung beispielsweise über kamerabasiertes Tracking. Positionen, Warenbewegungen und Bestände können damit ohne zusätzliche Scans aktuell gehalten werden. In die andere Richtung führen Schnittstellen zu SAP, WMS-Systemen oder REST-Endpunkten, über die Ergebnisse wieder in den operativen Betrieb gelangen.
Entscheidend ist dabei allerdings das Modell dazwischen. Ein digitaler Zwilling eines Lagers oder einer Produktion bildet nicht in erster Linie ab, wie die Umgebung aussieht, sondern wie sie funktioniert.
Für ein Lager bedeutet das beispielsweise: Welcher Artikel befindet sich wo? Welche Wege legt ein Kommissionierer zurück? Wie lange dauert ein Prozessschritt? Welche Ressourcen stehen in einer bestimmten Schicht zur Verfügung? Und wie verteilt sich das Auftragsvolumen über den Tag?
W2MO bildet diese Logik im Modell ab und erzeugt daraus auch die 3D-Darstellung. Visualisierung und Berechnung basieren damit auf derselben Struktur und müssen nicht als zwei getrennte Modelle gepflegt werden.
W2MO hat bewusst keine Physik-Engine. Es berechnet nicht, wann eine Palette kippt, wie sich eine Last während einer Bewegung verschiebt oder wie ein Greifer einen Karton verformt. Für solche Fragestellungen gibt es andere Werkzeuge.
Prozesszeiten basieren stattdessen auf Messwerten, zum Beispiel aus videobasierten Zeitstudien, aufgezeichneten Maschinendaten oder vergleichbaren Installationen. Für viele Fragestellungen in Lager- und Produktionslogistik ist das die relevantere Grundlage. Kosten und Durchsatz hängen dort meist weniger von der exakten Mechanik einer einzelnen Bewegung ab als davon, wie sich Tausende solcher Bewegungen über eine Schicht hinweg zusammensetzen.
Am Ende ist deshalb weniger entscheidend, welches Etikett auf einem System steht, sondern was es tatsächlich kann. Wenn in einer Ausschreibung ein digitaler Zwilling gefordert wird, lohnt sich ein genauer Blick auf die Rückfluss-Schnittstellen: Welche Ergebnisse soll das Modell an welches System übergeben? Und welche Entscheidungen sollen automatisch in den realen Betrieb zurückfließen?
Ein Modell, das lediglich Geometrie und Live-Status enthält, hat an dieser Stelle nur begrenzte Möglichkeiten – unabhängig davon, wie gut die Visualisierung aussieht.
Bei W2MO liegen Layout, Prozesse, Ressourcen und Materialflüsse in einem gemeinsamen Modell. Dadurch können Ergebnisse aus der Planung später weiterverwendet werden: Ein Slotting-Plan oder eine Auftragsreihenfolge, die zunächst für ein Planungsszenario berechnet wurde, kann anschließend in den operativen Betrieb überführt werden, ohne dafür ein zweites Modell aufzubauen.
Wenn Sie sehen möchten, wie das in der Praxis aussieht, zeigen wir gerne Beispiele aus W2MO-Projekten, in denen Planungsmodelle, Echtzeitdaten und operative Systeme miteinander verbunden wurden.
Quelle: Kritzinger, W.; Karner, M.; Traar, G.; Henjes, J.; Sihn, W. (2018): Digital Twin in manufacturing: A categorical literature review and classification. IFAC-PapersOnLine 51(11), S. 1016–1022. https://doi.org/10.1016/j.ifacol.2018.08.474