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 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.
