Der Digitale Zwilling einer Anlage setzt sich grundsätzlich aus verschiedenen Komponenten zusammen, die jeweils ein eigenes Simulationsmodell besitzen. Diese Simulationsmodelle werden in der Regel von den Herstellern der Anlagenkomponenten geliefert und manuell in ein Gesamtmodell integriert. Dieser Prozess ist Zeit- und Kostenintensiv. Aus diesem Grund sollen Verwaltungsschalen eingesetzt werden, die die benötigten Informationen der Konfigurierung mit sich bringen. Mithilfe einer Verwaltungsschalenschnittstelle können dadurch neue Simulationsmodelle vom Komponentenhersteller direkt in das Gesamtmodell integriert werden. Dies optimiert den gesamten Prozess der Anlagenkonfiguration des Digitalen Zwillings. Mit dieser Idee der automatischen Rekonfiguration des Digitalen Zwillings mithilfe von Verwaltungsschalen beschäftigt sich aktuell eine Themengruppe im Verbundprojekt SDM4FZI.
Aus der aktuellen Sicht eines kleinen Mittelständers, stellt es eine große Herausforderung dar, überhaupt einen Digitalen Zwilling einzuführen. Ein einfacher Weg in die Digitalisierung und Einführung von Digitalen Zwillingen zu bezwecken ist die virtuelle Inbetriebnahme, in der schon in der Engineering-Phase ein virtuelles Abbild der realen Produktionsanlage erstellt wird. Wenn ein Digitaler Zwilling sich im Unternehmen etabliert hat kommt die nächste Hürde. Durch immer häufigeres Umkonfigurieren der Produktionsanlage, verursacht von wachsender Individualisierung, benötigt es nicht nur ein flexibles Produktionssystem, sondern auch einen Digitalen Zwilling, der sich bei einer realen Konfiguration anpasst. Im Verbundprojekt Software-defined Manufacturing für die Fahrzeug und Zulieferindustrie (SDM4FZI) beschäftigt sich eine Teilgruppe genau mit diesem Thema, wie ein Digitaler Zwilling auf Komponentenebene einfach und automatisiert bei Änderungen umkonfiguriert werden kann.
Verwaltungsschale als Digitaler Zwilling
Es gibt viele verschiedene Definitionen von Digitalen Zwillingen. Für manche ist ein Simulationsmodell schon ein Digitaler Zwilling, für andere die Datenaufzeichnung einer realen Anlage. Um eine Durchgängigkeit und den Umgang mit dem Digitalen Zwilling zu erleichtern, gibt es Verwaltungsschalen. Diese beschreiben etwa Informationen über eine reale Anlage in einer strukturierten Form. Diese strukturierte Form ist in verschiedenen standardisierten Teilmodellen definiert, die von der IDTA (Industrial Digital Twin Association) vorgegeben werden. Als Beispiel gibt es etwa ein Teilmodell ‚Nameplate‘ welches Informationen wie Typnummer oder Herstellernummer enthält. Im Anwendungsbeispiel soll der Digitale Zwilling jedoch nicht nur auf Informationsebene umkonfiguriert werden, sondern das wirkliche Simulationsmodell, welches die reale Maschine abbildet. Dafür gibt es zwar das Teilmodell ‚SimulationModels‘, das Informationen über das vorliegende Simulationsmodell in der Verwaltungsschale bereitstellt. Jedoch kann die Verwaltungsschale selbst nicht das Simulationsmodell umkonfigurieren, da es nur als Informationsmodell vorliegt.
Von der Theorie in die Praxis
Um zu testen, ob Verwaltungsschalen sinnvoll sind für das Rekonfigurieren von Simulationsmodellen auf Komponentenebene, wird im ersten Schritt ein realer Anwendungsfall beschrieben. Dieser umfasst einen Werkzeugwechsler von der Firma Homag, der mit Bosch Rexroth Antrieben bestückt ist. Dabei existiert im Anwendungsfall ein Simulationsmodell des Werkzeugwechslers, der auch die Simulationsmodelle des Antriebs mit sich bringt. Zudem benötigt es die Verwaltungsschalen des Werkzeugwechsels und des Antriebs, welche in Abbildung 1 dargestellt sind. Dabei haben sich folgende zwei Anwendungsfälle herauskristallisiert. Im Zuge einer Smart-Factory-Potenzialanalyse für ihren Kunden KSB identifizierte die Managementberatung NEONEX Opti mierungschancen bei der Beschaffung der Lieferantendokumentation sowie der Erstellung von Unterlagen zur Qualitätsprüfung entlang der Supply-Chain. ‣ weiterlesen
Signifikante Ressourceneinsparung bei Pumpenhersteller KSB
NEONEX, Fabasoft Approve & KSB: „Win-win-win-Situation“ durch starke Partnerschaft
Signifikante Ressourceneinsparung bei Pumpenhersteller KSB
Im Fall A kann es sein, dass sich ein Antriebsmodell auf Seiten von Bosch Rexroth ändert, beispielsweise durch ein Firmwareupdate. In diesem Fall muss sich aktuell ein Inbetriebnehmer das Modell manuell von Bosch Rexroth herunterladen und aufwändig in das Gesamtmodell hinzufügen. Der andere Fall kann auch ein Parameterupdate sein, das im Antriebsmodell hinterlegt ist. Auch ein solches Updateverhalten soll durch ein automatisches Rekonfigurieren mithilfe von Verwaltungsschalen ermöglicht werden. Zusammengefasst geht es um die Anwendungsfälle Firmwareupdate und Parametersatzänderung.
Wo geht die Reise hin?
Abbildung 2 verdeutlicht die Implementierung. Auf einem Server gehostet vom Maschinenintegrator, soll ein Verwaltungsschalenserver initialisiert werden. Die Verwaltungsschalen selbst werden mit dem Package Explorer nach der Spezifikation der IDTA erstellt. Dabei handelt es sich um folgende Teilmodelle: ‚Nameplate‘, ‚Bills of Material‘ und ‚SimulationModel‘.
Damit ein automatischer Austausch von Simulationsmodellen überhaupt möglich ist, muss sich darauf geeinigt werden, welche Simulationsplattform verwenden werden soll. Für den vorliegenden Anwendungsfall wird Virtuos von der Firma ISG benutzt, da diese beim Maschineintegrator als auch vom Komponentenhersteller in Benutzung sind. Der Vorteil von Virtuos ist die Integrationsmöglichkeit von Verwaltungs-schalen in die Simulationsumgebung. Das Simulationsmodell welches in der Verwaltungsschale abliegt, muss in einer standardisierten Form vorliegen. Dafür kann bspw. auf den Function Mock Up Interface (FMI) Standard gesetzt werden. Aus funktionalen Gründen wird in diesem Anwendungsfall jedoch eine Virtuos-spezifisches Bibliotheksformat verwendet.
Das allgemeine Konzept der Konfigurierung besteht aus verschiedenen Clients, die auf einen Hauptserver (dem Verwaltungsschalenserver) zugreifen. Ein Client (Bosch Rexroth) hat einen Zugriff auf den Server, um neue Antriebsmodelle hinzuzufügen. Wenn dies geschehen ist, soll auf Seiten des Maschinenintegrators (Homag/ISG) ein Event getriggert werden, dass eine Änderung stattgefunden hat. Zu erwähnen ist, dass auch ein zyklisches Abfragen der Informationen möglich ist, um Änderungen zu detektieren. Wenn eine Änderung detektiert ist, wird nun zwischen den beiden Anwendungsfällen unterschieden.
Für den Anwendungsfall der Firmware Änderung eines Antriebs soll das komplette Simulationsmodell des Antriebs ausgetauscht werden. Durch das Bereitstellen der aasx-Datei kann das neue Antriebsmodell mithilfe einer Remoteschnittstelle in Virtuos automatisiert integriert werden bzw. ausgetauscht werden.
Ein anderer Anwendungsfall ist eine Parameteränderungen im Antriebsmodell. In diesem Fall müssen schon in der Verwaltungsschale die zu ändernden Parameter abgelegt sein, die das Simulationsmodell beeinflussen. Wenn sich diese Parameter ändern, kann das Simulationsmodell wieder über die Remoteschnittstelle angepasst werden.
Fazit
Aktuell ist es noch schwer ein Simulationsmodell automatisiert zu rekonfigurieren, da es viele Hürden gibt. Durch Verwaltungsschalen und der möglichen Updatefunktion im Simulationsmodell selbst, können erste Änderungen automatisiert vorgenommen werden. In der Arbeitsgruppe wurde ein Konzept entwickelt, um die Nutzung der Verwaltungsschale in Hinsicht auf Simulationsmodelle zu vereinfachen und aufzuzeigen, ob die aktuellen Verwaltungsschalen ausreichend sind, um Konfigurationen zu ermöglichen. Eine weitere Herausforderung ist die Integration eines neuen Simulationsmodells in eine Gesamtmodell, wenn sich beispielsweise Eingangs-/Ausgangsinformationen ändern. Bisher gibt es dafür noch keine voll automatisierbare Lösung.
