Fehler sollten früh gefunden werden. Es gilt: Je früher ein Fehler gefunden wird, desto geringer ist der Aufwand für dessen Behebung. Ist es da nicht sinnvoll, die Daten zu überprüfen, bevor sie weitergegeben werden? Bezogen auf das Anlagenverhalten: ob das modellierte Verhalten dem Beabsichtigten entspricht?
Welche Informationen werden benötigt?
Um das Anlagenverhalten simulativ überprüfen zu können, bedarf es grundsätzlich folgender Informationen:
- Die Anlagenstruktur: Welche Produktionsressourcen werden verwendet und wie sind diese untereinander angeordnet?
- Die Geometrie und Mechanik der Anlage: Wie sind deren Gestalt und die Bewegungsmöglichkeiten?
- Das Anlagenverhalten: In welcher Reihenfolge werden welche Schritte bzw. Aktivitäten auf den Produktionsressourcen ausgeführt?
Dabei setzt sich die Geometrie und Mechanik der Anlage aus der Geometrie und Mechanik der einzelnen Produktionsressourcen zusammen, deren Anordnung mit der Anlagenstruktur beschrieben wird. Um nun das Verhalten dieser Komposition der Produktionsressourcen simulieren zu können, muss jede Produktionsressource selbst mit modulspezifischem Verhalten versehen werden.
Wo ist das einsetzbar?
Die Planung einer Anlage kann im Allgemeinen in sechs Phasen eingeteilt werden (siehe Bild 1). In welcher Phase bietet sich eine simulative Überprüfung des Verhaltens an? Und was kann da konkret überprüft werden? In der Fabrikplanungsphase wird das Anlagenverhalten grob beschrieben – meist mithilfe einfacher Modelle, wie Gantt oder PERT Charts. An dieser Stelle kann überprüft werden, ob sich das Produkt mit den festgelegten Fertigungsschritten mit den gewählten Produktionsressourcen fertigen lässt. Innerhalb des funktionalen Engineerings liegen bereits detailliertere Verhaltensbeschreibungen vor, z.B. in Form von Impulsdiagrammen: Werden bei Eingang bestimmter Sensorsignale die richtigen Aktoren angesteuert? Es lässt sich damit überprüfen, ob die Signalabfolgen überhaupt realisierbar sind. Während der virtuellen Inbetriebnahme (Teil des funktionalen Engineerings), die sich kurz vor dem eigentlichen Aufbau der Anlage befindet, also zu einem Zeitpunkt, in dem die Anlage komplett spezifiziert vorliegt, kann der Steuerungscode auf Fehlerfreiheit geprüft werden.
Was ist dazu nötig?
Innerhalb des Anlagenentwurfsprozesses sind verschiedene ingenieurstechnische Disziplinen beteiligt, die jeweils ihre eigenen, an den Bereich optimierten Software-Werkzeuge verwenden. Aus diesem Grund macht es wenig Sinn, ein neues Werkzeug zu entwickeln, das eine Verhaltensvalidierung zu unterschiedlichen Zeitpunkten der Planung zulässt. Innerhalb der Forschungsanstrengungen der Otto-von-Guericke-Universität Magdeburg fiel deshalb die Wahl auf die Entwicklung eines Simulations-Frameworks, das die Einbindung dieser bereichsspezifischen Werkzeuge erlaubt. Um die zuvor genannten Informationsmengen erzeugen bzw. verarbeiten zu können, werden folgende Werkzeuge bzw. Werkzeugfunktionen benötigt:
- 3D-Visualisierung
- Verhaltensdesign
- 3D-Simulation
- Verhaltenssimulation
Mittels einer zuvor erstellten mechatronisch orientierten Komponentenbibliothek, in der zu jeder Produktionsressource sowohl die Geometrie und Mechanik als auch das Verhalten des Moduls hinterlegt ist, kann in der Software zur 3D-Visualisierung die Anlagenstruktur durch Komposition der Produktionsressourcen modelliert werden. Das modulspezifische Verhalten (modelliert in dem Werkzeug zum Verhaltensdesign) ist jedoch so erstellt, dass es entsprechend der drei identifizierten Anwendungsfälle Einstiegs- bzw. Ansteuermöglichkeiten für das Anlagenverhalten gibt. Es ergeben sich drei Ebenen, auf denen die Produktionsressourcen angesteuert werden können. Somit können sie je nach Detaillierungsgrad des Anlagenverhaltens, das durch den Ingenieur mit der Software zum Verhaltensdesign erstellt wird, angesteuert werden. Das modulspezifische Verhalten, egal auf welcher Ebene, braucht allerdings auch auf der Seite der digitalen 3D-Repräsentation Anknüpfungspunkte (modelliert im Werkzeug zur 3D-Visualisierung), so dass sich die Produktionsressource bei deren Ansteuerung entsprechend \’bewegt\‘. Damit sind alle notwenigen Informationen vorhanden, um das Anlagenverhalten in den Werkzeugen zur 3D- und Verhaltenssimulation simulieren zu können. Bild 2 zeigt schematisch das entwickelte Simulations-Framework. Um für die simulative Verhaltensvalidierung eine konsistente Informationsweitergabe zwischen den beteiligten Werkzeugen sicherzustellen, ist AutomationML als Datenaustauschformat sehr gut geeignet. Neben der mechatronisch orientierten Komponentenbibliothek kann in AutomationML auch die Projektdatei mit dem Anlagenverhalten und der Anlagenstruktur, die die verwendeten mechatronischen Produktionsressourcen beinhaltet, konsistent geführt werden. Dabei werden die Strukturen mittels CAEX abgebildet: die Komponentenbibliothek als \’SystemUniClassLib\‘ und die Projektdatei in der \’InstanceHierarchy\‘. Das Anlagenverhalten sowie das jeweilige modulspezifische Verhalten werden mithilfe von PLCopen XML abgebildet und die Geometrie- und Mechanikinformationen in Collada abgelegt, wie es in [1] beschrieben ist. PLCopen XML und Collada werden dabei als externe Dateien aus dem AutomationML Dachformat CAEX heraus referenziert. Besitzen die Werkzeuge jedoch selbst keine AutomationML- Schnittstelle, müssen entsprechende Konverter zur Verfügung stehen. Innerhalb der Forschungsarbeiten wurde das Simulations-Framework prototypisch mit Software von KW-Software (Multiprog für das Verhaltensdesign, Proconos für die Verhaltenssimulation) und tarakos (taraVRbuilder für die 3D-Visualisierung, taraVRcontrol für die 3D-Simulation) umgesetzt.
Fazit
Das Datenaustauschformat AutomationML ist gut dafür geeignet, das modulare, erweiter- und anpassbare Simulations-Framework zu realisieren, mit dem Anlagenverhalten in den verschiedenen Phasen des Planungsprozesses von Anlagen auf seine Fehlerfreiheit überprüft werden kann. So kann der Ingenieur vor Weitergabe seiner Daten noch einmal überprüfen, ob das modellierte Verhalten dem beabsichtigten Verhalten entspricht oder auch dazu nutzen, anderen Mitarbeitern das intendierte Anlagenverhalten zu veranschaulichen. Das einmalige Anlegen oder Aufbereiten der mechatronischen Produktionsressourcen ist erstmal ein Mehraufwand, der sich jedoch durch die ermöglichte Wiederverwendung der Komponenten schnell amortisieren kann. Unternehmen können sich \’hausinterne\‘ Simulations-Frameworks erstellen und somit ihre Engineering-Qualität und auch ihre Engineering-Effizienz steigern.
Literatur
[1] R. Drath (Editor): Datenaustausch in der Anlagenplanung mit AutomationML, Springer Verlag, 2010.
