Digitaler Zwilling im Maschinenbau: Wie Simulationsmodell und Verwaltungsschale zusammenfinden

Der digitale Zwilling im Maschinenbau entsteht in vielen Unternehmen zweimal, ohne dass jemand es so plant. Einmal als Simulationsmodell für die virtuelle Inbetriebnahme in der Konstruktion, einmal als Informationsmodell in der Verwaltungsschale, das Typenschild, Dokumentation und technische Daten an den Kunden liefert. Interoperabel wird der Zwilling erst, wenn beide zusammenfinden. Dafür gibt es inzwischen ein eigenes Teilmodell der Verwaltungsschale.

Die Grundlagen der Verwaltungsschale haben wir im Beitrag Verwaltungsschale (Asset Administration Shell) erklärt. Hier geht es um die Frage, die Konstrukteure und Steuerungstechniker beschäftigt: Wie wird aus einem Modell, das für die eigene Inbetriebnahme gebaut wurde, ein Zwilling, den Kunden und Zulieferer weiterverwenden können?

Zwei Zwillinge, ein Asset

Beide beschreiben dieselbe Maschine, aber für unterschiedliche Leser. Das Problem entsteht, wenn sie nichts voneinander wissen. Dann baut der Betreiber für seinen Linienzwilling ein Modell Ihrer Maschine nach, das Sie längst besitzen, und Ihre Zulieferer schicken Simulationsmodelle per E-Mail in Formaten, die niemand dokumentiert hat.

Das Teilmodell für Simulationsmodelle

Die Industrial Digital Twin Association hat dafür das Teilmodell IDTA 02005 Provision of Simulation Models veröffentlicht, aktuell in Version 1.1 vom März 2026. Es erlaubt, Simulationsmodelle zu einem Asset interoperabel über die Verwaltungsschale bereitzustellen. Beschrieben werden die Art des Modells, seine Verwendung und seine Einsatzgebiete. Das Asset kann ein passives Bauteil sein, ein Gerät, eine Baugruppe, eine Maschine oder eine ganze Anlage.

Die Modelle selbst können in den Formaten eines bestimmten Simulationswerkzeugs vorliegen, als Quellcode oder in einem Austauschformat wie FMI. Ein Punkt ist für Maschinenbauer besonders praktisch: Das Teilmodell eignet sich laut IDTA auch dafür, bei einem Zulieferer gezielt ein Simulationsmodell für eine Komponente anzufragen. Als zugehörige Standards nennt das Dokument unter anderem FMI, AutomationML und ECLASS.

Austauschformate: FMI, AutomationML und OPC UA

• FMI (Functional Mock-up Interface): freier Standard für Austausch und Co-Simulation dynamischer Modelle. Ein Modell wird als FMU verpackt und läuft in jedem Werkzeug, das FMI unterstützt.
• AutomationML: Austauschformat für Engineering-Daten wie Anlagenstruktur, Geometrie, Kinematik und Steuerungsbezüge.
• OPC UA: die Laufzeitverbindung zwischen Steuerung und Zwilling, wenn das Modell mit Live-Daten arbeitet.

Der VDMA-Leitfaden Virtuelle Inbetriebnahme von 2020 empfiehlt, für eine aufwandsarme Modellierung möglichst viele vorhandene Engineering-Daten wie CAD-Geometrie und Schaltpläne zu nutzen, und nennt FMI als ersten Ansatz, Modelle aus anderen Simulationswerkzeugen zu übertragen und zu koppeln. Prüfen Sie bei der Werkzeugwahl deshalb zuerst die Schnittstellen, dann die Grafik. Ein Werkzeug, das kein FMU exportieren kann, schließt Ihre Modelle in genau dieses Werkzeug ein, egal wie gut die Darstellung ist.

Ein Beispiel: vom Antrieb bis zur Linie

Ein Hersteller von Bearbeitungszentren baut für die virtuelle Inbetriebnahme ein Modell seiner Maschine mit Achsen, Werkzeugwechsler, Spannvorrichtung und Türen. Für die Vorschubachsen fragt er beim Antriebslieferanten über das Teilmodell ein Simulationsmodell als FMU an, statt das Verhalten selbst nachzubauen. Die Maschine wird gegen das SPS-Programm getestet und ausgeliefert. Mit ihr geht eine Verwaltungsschale an den Kunden: digitales Typenschild, Dokumentation und, über dasselbe Teilmodell, ein vereinfachtes Verhaltensmodell der Maschine.

Der Betreiber setzt dieses Modell in seinen Linienzwilling ein und prüft, wie sich die neue Maschine in den Materialfluss einfügt. Niemand hat ein Modell zweimal gebaut. Für den Maschinenbauer ist das nicht nur Service: In Datenräumen wie Manufacturing-X wird die Verwaltungsschale zum Format, in dem Kunden solche Informationen erwarten.

Typ und Instanz: welcher Zwilling wohin gehört

Hilfreich ist die Unterscheidung zwischen Typ und Instanz. Der Typzwilling beschreibt eine Baureihe: Kinematik, Steuerungslogik, Kennwerte. Der Instanzzwilling beschreibt die eine Maschine mit Seriennummer beim Kunden, mit ihren Optionen, Parametern und Softwareständen. Für die virtuelle Inbetriebnahme arbeiten Sie meist mit dem Typ und ergänzen kundenspezifische Optionen. Beim Kunden zählt die Instanz. Wer beides von Anfang an trennt, kann Modelle über Jahre pflegen, statt für jede Auslieferung neu anzufangen. Auch Softwareänderungen nach der Auslieferung, die nach Maschinenverordnung und Cyber Resilience Act ohnehin nachvollziehbar sein müssen, lassen sich der richtigen Instanz zuordnen.

Pragmatischer Einstieg in fünf Schritten

1. Eine Maschine oder Baugruppe auswählen, für die ohnehin eine virtuelle Inbetriebnahme geplant ist.
2. Modell so strukturieren, dass Baugruppen getrennt austauschbar sind, etwa als einzelne FMUs.
3. Für Zukaufkomponenten bei den Lieferanten Simulationsmodelle anfragen, bevorzugt als FMU.
4. Digitales Typenschild und Dokumentation als erste Teilmodelle der Verwaltungsschale anlegen.
5. Ein vereinfachtes Verhaltensmodell über das Teilmodell für Simulationsmodelle bereitstellen und mit einem Pilotkunden testen.

Wie Wartens und iUNI unterstützen

Wartens baut über die Gruppenmarke iUNI Zwillinge von Maschinen und Linien, die mit Ihrem SPS-Programm laufen, und strukturiert sie auf Wunsch interoperabel, etwa mit Blick auf die Verwaltungsschale. Die Zwillinge binden SCADA, SPS und ERP an und lassen sich für die virtuelle Inbetriebnahme nutzen. Was im Lieferumfang steckt, lesen Sie im Produktüberblick zum digitalen Zwilling von iUNI, das Angebot finden Sie unter Digitale Zwillinge.

Nächster Schritt: Nennen Sie uns eine Maschine, für die eine virtuelle Inbetriebnahme ansteht, und die Formate Ihrer CAD- und Elektrodaten. Wir schlagen eine Modellstruktur vor, die später auch Ihre Kunden nutzen können. Kontakt aufnehmen.