Es reicht nicht, wenn der Roboter auf dem Bildschirm erscheint
Eine dreidimensionale Darstellung eines Industrieroboterarms kann bei der Planung einer Zelle helfen, Reichweiten prüfen oder eine Bahn vorbereiten. Das allein weist jedoch nicht nach, dass ein digitaler Zwilling der in der Fabrik arbeitenden Anlage existiert. Die entscheidende Frage ist nicht, ob das Modell „echt aussieht“, sondern welche überprüfbare Beziehung es zu einem konkreten physischen Roboter unterhält und welche Informationen zwischen beiden ausgetauscht werden. Eine überzeugende Darstellung kann ein nützliches Entwurfswerkzeug sein, belegt aber weder eine aktive Verbindung noch eine genaue Repräsentation oder einen laufenden Informationsaustausch.
Es ist sinnvoll, drei Begriffe zu unterscheiden, die in kommerziellen Präsentationen oft vermischt werden. In diesem Leitfaden bezeichnet Simulation die Berechnung oder Darstellung des Verhaltens eines Systems unter Annahmen; ein digitales Modell beschreibt Elemente und Beziehungen; ein digitaler Zwilling ist eine Repräsentation, deren Beziehung zu einem physischen Objekt und deren Datenaustausch dokumentiert werden können. Das ist eine praktische Unterscheidung zur Bewertung von Angeboten, keine normative Definition. Der Umfang muss präzisiert werden: Was wird dargestellt, welche Informationen werden ausgetauscht und was bleibt außerhalb des Modells? Die bloße Verwendung des Begriffs durch einen Anbieter beantwortet diese Fragen nicht.
Die Unterscheidung hängt nicht von einer einzigen Datenmenge pro Sekunde ab. Eine nicht verbundene Simulation kann technisch anspruchsvoll und nützlich sein, erlaubt aber nicht die Aussage, dass sie den aktuellen Zustand einer Maschine verfolgt. Umgekehrt beweist auch eine sehr begrenzte Datenverbindung nicht, dass das Modell Bewegungen, Werkzeuge, Lasten oder Prozesse getreu abbildet. Der Umfang sollte konkret und überprüfbar beschrieben werden, statt sich auf die isolierte Verwendung des Ausdrucks „digitaler Zwilling“ zu stützen. Fragen Sie daher, welcher Zustand tatsächlich dargestellt wird, wie die entsprechenden Informationen gewonnen werden und welche Entscheidungen das Modell unterstützen soll. So wird visuelle Realitätsnähe nicht mit einer betrieblichen Verbindung verwechselt.
Der erste Nachweis: Anlage und Beziehung identifizieren
Bevor es um Synchronisierung geht, sollte ein Angebot angeben, welchen Roboter oder welche Baugruppe es darstellt. Handelt es sich um eine physische Einheit in einer bestimmten Zelle, eine Gerätefamilie oder einen generischen Katalogroboter? Außerdem sollte abgegrenzt werden, ob das digitale Objekt nur den Manipulator umfasst oder auch Steuerung, Werkzeug, Sensoren, Werkstück, Peripheriegeräte und Prozess. Ohne diese Grenze können zwei Parteien mit „Zwilling“ unterschiedliche Dinge meinen. Eine eindeutige Beschreibung der Anlage verhindert, dass eine attraktive Vorführung eines generischen Roboters mit einer Darstellung der tatsächlich installierten Maschine verwechselt wird.
Damit diese Definition praktisch nutzbar wird, sollte das Angebot die physische Anlage, die digitalen Komponenten, Datenquellen, Austauschpunkte und Verantwortlichen für jede Verbindung beschreiben. Ein Architekturdiagramm hilft zu verdeutlichen, welche Teile einbezogen sind und welche außerhalb des Umfangs liegen. Diese Dokumentation zertifiziert nicht, dass eine konkrete Implementierung verbunden oder validiert ist. Sie macht den Umfang explizit und ermöglicht konkrete, überprüfbare Fragen zur Beziehung zwischen Anlage und Darstellung. Das Diagramm sollte nachvollziehbar zeigen, wo relevante Informationen entstehen und wohin sie fließen, ohne den Eindruck zu erwecken, eine eingezeichnete Schnittstelle sei zwangsläufig bereits umgesetzt oder getestet.
Die Identifizierung sollte es ermöglichen, die Übereinstimmung zwischen Modell und Anlage über den gesamten Projektlebenszyklus hinweg nachzuverfolgen. Bei einer Vorführung kann der Anbieter zum Beispiel erläutern, ob Parameter aus der tatsächlichen Steuerungskonfiguration, einem anfänglichen Import oder einer Standardvorlage stammen. Das sind unterschiedliche Situationen: Eine kopierte Konfiguration kann ein guter Ausgangspunkt sein, belegt aber nicht, dass das Modell spätere Änderungen am Roboter oder seiner Umgebung nachvollzieht. Dieser Unterschied sollte dokumentiert werden. Klären Sie außerdem, wer Konfigurationsänderungen festhält und wie das Modell daran angepasst wird, statt anzunehmen, dass eine anfängliche Übereinstimmung dauerhaft bestehen bleibt.
Was Synchronisierung bedeutet: Daten, Richtung und Verzögerung
Der Begriff Synchronisierung braucht eine operative Definition. Für jedes relevante Datum sind Quelle, Ziel, Aktualisierungsrate oder -bedingung, Zeitstempel und Verhalten bei Kommunikationsverlust anzugeben. Achsposition, Ausführungsstatus, Alarme und aktive Aufgabe sind Beispiele für Informationen, die ausgetauscht werden könnten; es darf nicht vorausgesetzt werden, dass eine konkrete Implementierung alle diese Daten erhält. Die Nachweise sollten zeigen, welche Signale tatsächlich verwendet und wie sie mit Modellvariablen verknüpft werden. Eine Signalliste ist hilfreicher, wenn sie Einheiten nennt und klarstellt, ob ein Wert gemessen, berechnet oder lediglich konfiguriert ist. So lässt sich eine aktuelle Beobachtung von einem statischen, ins Modell kopierten Parameter unterscheiden.
Auch die Richtung des Datenflusses ist wichtig. Das Auslesen von Daten aus der Steuerung in das Modell kann eine Darstellung aktualisieren, ist aber nicht dasselbe wie das Zurücksenden von Befehlen an die Anlage. Kann das System Sollwerte schreiben oder Programme ändern, sollte das Angebot Berechtigungen, Grenzen und betriebliche Zuständigkeiten angeben. Überwachung, Szenarioberechnung und Steuerung dürfen nicht verwechselt werden: Es sind unterschiedliche Fähigkeiten, und mit jeder ändert sich das Risikoniveau. Die Vorführung sollte erläutern, ob Informationen in eine oder beide Richtungen fließen und ob die Schreibfunktion in der gezeigten Umgebung aktiviert ist.
Latenz lässt sich nicht mit der Aussage „Echtzeit“ zusammenfassen. Zu klären sind das gemessene Aktualisierungsintervall, die für jeden vorgesehenen Einsatz tolerierbare Verzögerung und die Art, wie das System erkennt, dass ein Bildschirm veraltete Informationen zeigt. Ein Protokoll mit Zeitstempeln, Paketverlusten oder Unterbrechungen und der Wiederherstellung der Verbindung ist aussagekräftiger als eine flüssige Animation. Technische Unterlagen können Hinweise darauf geben, welche Aspekte des Datenaustauschs zu prüfen sind; für sich genommen beweisen sie nicht, dass ein bestimmtes Produkt eine bestimmte Latenz einhält. Hängt der behauptete Nutzen von aktuellen Daten ab, sollten die Nachweise die beobachtete Verzögerung mit diesem Einsatz verknüpfen und nicht nur ein allgemeines Etikett wiederholen.
Was das Modell darstellen kann und wie es geprüft wird
Ein Modell kann Geometrie, Kinematik, Gelenkgrenzen, Werkzeug, Nutzlast, Arbeitsbereiche und Zellkomponenten beschreiben. Dass diese Daten in einer Szene erscheinen, zeigt jedoch nicht, ob sie gemessen, aus Dokumentation importiert oder geschätzt wurden. Für jedes relevante Element sollte die Vorführung Herkunft, Version und Aktualisierungsverfahren nennen. Ändern sich Werkzeug oder Werkstück, muss außerdem klar sein, ob das Modell angepasst wird und wer diese Änderung validiert. Ein Modell kann auch dann nützlich sein, wenn einzelne Elemente Näherungen sind, sofern diese Näherungen und ihre Auswirkungen offengelegt werden.
Zur Validierung muss das virtuelle Verhalten unter beschriebenen Bedingungen mit Beobachtungen des physischen Systems verglichen werden. Möglich sind Prüfungen von Bahnen, erreichbaren Positionen, Kollisionen oder Prozesszuständen; dabei ist jeweils anzugeben, welche Größe verglichen wird und welche Toleranz gilt. Die Schlussfolgerungen müssen auf die geprüften Bedingungen begrenzt bleiben: Die Übereinstimmung einer Bahn in einer Konfiguration belegt nicht automatisch Genauigkeit bei allen Geschwindigkeiten, Lasten, Werkzeugen und Betriebszuständen. Der Vergleich sollte die physische Referenz und die Modellversion nennen, damit das Ergebnis wiederholt oder später sinnvoll geprüft werden kann.
Ein aussagekräftiger Validierungsnachweis nennt die Versionen von Modell und Programm, die Roboterkonfiguration, Prüfbedingungen, Referenzdaten und beobachtete Fehler. Außerdem unterscheidet er geometrische Validierung von Prozessvalidierung. Eine synchronisierte Animation zu sehen ist nicht dasselbe wie Bewegungsgenauigkeit nachzuweisen, und ein simulierter Alarm belegt keine Vorhersagefähigkeit. Werden Vorhersagen präsentiert, fragen Sie nach Prognosehorizont, verwendeten Eingaben und einem Vergleich mit beobachteten Ergebnissen – nicht nur nach einer überzeugenden Visualisierung. Die Nachweise sollten zeigen, was geprüft wurde, in welcher Konfiguration und wie Abweichungen bewertet wurden. Ein Test mit nur einer Bahn darf nicht stillschweigend auf andere Bewegungen, Lasten oder Prozessbedingungen ausgeweitet werden.
Bewertbare Anwendungen und Grenzen, die nicht verschwiegen werden sollten
Ein verbundenes Modell kann Aufgaben wie die Zustandsüberwachung, die Untersuchung von Layoutänderungen oder das Erproben von Alternativen vor ihrer Umsetzung in der Fabrik unterstützen. Der Nutzen hängt von verfügbaren Daten und der für eine Entscheidung erforderlichen Genauigkeit ab. Für eine Zustandsanzeige können längere Aktualisierungsintervalle ausreichen als für eine Bahnanalyse; eine Entscheidung über einen Wartungseingriff erfordert konkrete Nachweise zur vorherzusagenden Größe. Keine dieser Anwendungen ist allein durch die Bezeichnung des Systems belegt. Der Anbieter sollte den behaupteten Nutzen mit den Daten, Modelleigenschaften und Prüfungen verknüpfen, die genau diese Aufgabe unterstützen.
Abweichungen zwischen Modell und Maschine können durch nicht berücksichtigte Änderungen, Kalibrierung, Spiel, Verformung, Verschleiß, Last, Werkzeug oder Prozessschwankungen entstehen. Ein Modell muss nicht jedes physikalische Phänomen enthalten, sollte aber seine Annahmen und den validierten Bereich angeben. Außerhalb dieses Bereichs können Ergebnisse lediglich hinweisend sein und sollten nicht als bestätigte Vorhersagen dargestellt werden. Grenzen klar zu benennen, ist Teil der Bewertung und bedeutet nicht, dass das Modell nutzlos ist. So lässt sich beurteilen, wann sich die Darstellung zur Untersuchung eignet und wann zusätzliche Messungen oder Validierungen nötig sind.
Zu den herangezogenen Quellen gehören eine Siemens-Seite über industrielle digitale Zwillinge und ein technischer NVIDIA-Blogartikel über Robotersimulation in digitalen Zwillingen industrieller Anlagen. Das verfügbare Material enthält keine Testergebnisse zu einer konkreten Implementierung eines Roboter-Digitalzwillings. Deshalb stellt dieser Text Kriterien zur Bewertung eines Angebots vor und keine Prüfergebnisse für ein bestimmtes System. Aus dieser Einschränkung des Umfangs folgt weder, dass alle Projekte scheitern, noch, dass alle verbundenen Modelle gleichwertig sind. Allgemeine Quellen können helfen, Fragen zu formulieren, ersetzen aber keine Nachweise zur tatsächlich bewerteten Implementierung.
Checkliste zur Prüfung einer Vorführung
Fragen Sie zunächst nach einer Definition der dargestellten Anlage und einem Architekturdiagramm: physische Ausrüstung, Modell, Informationsquellen, Schnittstellen und Systemgrenzen. Fordern Sie anschließend eine Signaltabelle mit Quelle, Ziel, Einheiten, Frequenz, Zeitstempeln und Fehlerbehandlung an. Spricht der Anbieter von kontinuierlicher Aktualisierung oder Echtzeit, bitten Sie um Zahlen und nachvollziehbare Protokolle, die diese Beschreibung stützen. Die Dokumentation sollte den Informationsfluss nachvollziehbar machen und zwischen nachgewiesenem Datenaustausch und lediglich geplantem Austausch unterscheiden.
Um die Übereinstimmung zwischen physischer und digitaler Seite zu bewerten, fragen Sie, welche Eigenschaften des Roboters und der Zelle übernommen wurden, woher sie stammen und wann sie zuletzt aktualisiert wurden. Fordern Sie einen reproduzierbaren Test an, der Steuerungsdaten mit dem Modell vergleicht, einschließlich Fehler, Bedingungen und genauer Konfiguration. Wird ein konkreter Anwendungsfall vorgeführt, sollten die Nachweise genau diesem Zweck zugeordnet sein: Eine geometrische Validierung reicht nicht, wenn es um vorausschauende Wartung oder Steuerung geht. Der Test muss zur Behauptung passen, damit die Ergebnisse nicht ohne Grundlage auf ungeprüfte Bedingungen übertragen werden.
Klären Sie schließlich, ob das System nur beobachtet oder auch auf die Anlage einwirken kann, welche Berechtigungen erforderlich sind und was bei einer Unterbrechung geschieht. Fragen Sie, wer das Modell bei Änderungen an Werkzeugen, Programmen oder Komponenten pflegt, wie Versionen dokumentiert werden und welche Ergebnisse außerhalb des validierten Umfangs liegen. Eine fundierte Antwort kann Grenzen anerkennen; eine vage Antwort, die solche Angaben durch realistische Bilder oder allgemeine Versprechen ersetzt, ermöglicht keine Unterscheidung zwischen einer nützlichen Simulation und einem verbundenen, überprüfbaren digitalen Zwilling. Eine Checkliste ist keine Zertifizierung, macht aus einer Präsentation aber konkrete Fragen und Anforderungen an Nachweise.