AutomationML – die Architektur

Serie AutomationML Teil 2: Ein Standard für die Verbesserung des Datenaustauschs von Engineeringwerkzeugen
Durch die zunehmende Bedeutung der Software im Bereich der Industrie und speziell in der Automatisierungstechnik haben sich neue Schnittstellenprobleme gezeigt. Aktuell gibt es viele Systembrüche zwischen den unterschiedlichen Engineeringwerkzeugen. AutomationML hat zum Ziel, diesen Datenaustausch signifikant zu vereinfachen. Wir stellen AutomationML im Rahmen einer sechsteiligen Serie vor und fahren in Teil 2 fort mit der Architektur.

Der AutomationML e.V. betrachtet den Entwurfsprozess von Produktionssystemen. Dies geht vom Produktentwurf über den Anlagenentwurf und das \’Detailed Engineering\‘ bis hin zur virtuellen Inbetriebnahme und zur Anlagenstandardisierung. Er ist dabei bestrebt, ein Datenaustauschformat zu entwickeln, das für jede beliebige Paarung von Werkzeugen der Entwurfskette als Datenformat zur Weitergabe von Entwurfsergebnissen genutzt werden kann. Dies ist in Bild 1 beispielhaft dargestellt. AutomationML stellt dabei das reine Datenformat dar und befasst sich nicht mit der Übertragung der Inhalte oder Schnittstellen zu entsprechenden Werkzeugen.

Architektur von AutomationML

Ausgangspunkt für AutomationML bildet die Abbildung der Struktur bzw. Topologie eines Produktionssystems. Diese umfasst die hierarchische Strukturierung der Anlagenobjekte, die jeweils durch individuelle Datenobjekte repräsentiert werden. Dabei wird die Anlage bzw. Teilanlage bis zu einem spezifischen, den Notwendigkeiten der jeweiligen Anwendungsfälle angepassten Detaillierungsgrad untergliedert. Für jedes Anlagenobjekt werden die entsprechenden auszutauschenden Informationen als Objekteigenschaften abgebildet. Zusammenhänge zwischen Anlagenobjekten werden über Relationen repräsentiert. Zur Darstellung der Struktur- und Topologieinformationen wird auf das bereits international in der IEC62424 standardisierte Datenformat CAEX (Computer Aided Engineering Exchange) zurückgegriffen. Dieses bietet objektorientierte Grundkonzepte, die für die Darstellung von Anlagenstrukturen eingesetzt werden. Dazu spezifiziert AutomationML detailliert, wie welches Grundkonzept von CAEX einzusetzen ist und definiert darüber hinaus Einschränkungen und Regeln für den Einsatz von CAEX. Das erste der genutzten Grundkonzepte von CAEX ist die InstanceHierarchy. Sie ermöglicht die Abbildung der hierarchischen Anlagenstruktur eines Produktionssystems. Mithilfe der SystemUnitClassLibraries werden (herstellerspezifische) Bibliotheken von Anlagenkomponenten beschrieben. Die RoleClassLibraries ermöglichen die Definition und Nutzung von Semantiken für Anlagenkomponenten bzw. für ihre Beschreibungsmittel. Das vierte genutzte Grundkonzept sind die InterfaceClassLibraries. Sie umfassen die Definition verschiedener Schnittstellentypen, mit denen Zusammenhänge zwischen verschiedenen Anlagenkomponenten sowie Beziehungen zu extern abgespeicherten Informationen beschrieben werden können. Die Bibliothekskonzepte ermöglichen die Definition, Darstellung und Nutzung von Templates für einzelne Objekte. Über sie können allgemein verbindliche als auch anwenderspezifische Grundstrukturen beschrieben und ausgetauscht werden. Die InstanceHierarchy erfüllt für das eigentliche Engineering-Projekt den gleichen Zweck. Mittels des Konzeptes der Rollenbibliotheken (RoleClassLib) kann einzelnen Objekten sowohl in der SystemUnitClassLibrary als auch der InstanceHierarchy eine bestimmte Semantik zugeordnet werden. Dadurch wird den Objekten unabhängig von ihrer eigentlichen Benennung eine Bedeutung im Rahmen der Anlage zugewiesen. Das Konzept der Interfaces und Relationen ermöglicht es, Objekte über Hierarchiegrenzen hinweg in Beziehung zu setzen und schafft die Möglichkeit, auf Informationen außerhalb der CAEX-Beschreibung zu referenzieren. Dazu werden entsprechende InterfaceClass-Objekte im Rahmen einer InterfaceClassLibrary spezifiziert. Diese werden in der SystemUnitClassLibrary bzw. der InstanceHierarchy genutzt und mittels InternalLinks verbunden. Zudem ermöglichen Referenzen in den Objekten der InstanceHierarchy, die Instanziierung von Objekten der SystemUnitClassLibrary. Den einzelnen Objekten der Struktur- und Topologiebeschreibung können Geometrie- und Kinematikinformationen zugeordnet werden. Diese beschreiben die geometrischen Verhältnisse der einzelnen Objekte als Körper in beliebiger Detailliertheit sowie die Eigenschaften der Beweglichkeit dieser und ihren Zusammenhang.

XML-basiertes Datenformat als Grundlage

Grundlage der Geometrie- und Kinematikbeschreibung ist das aus der Computerspieleindustrie stammende, offene, XML-basierte Datenformat Collada in Version 1.4.1 und 1.5.0 (ISO/PAS 17506:2012). Dieses Format ermöglicht die Darstellung der geometrischen und kinematischen Eigenschaften von Körpern als geometrische und kinematische Szenen. Unter Nutzung von Referenzierungsmechanismen, die in CAEX in der InterfaceClassLibrary spezifiziert sind, werden die einzelnen Geometrie- und Kinematikbeschreibungen an die betreffenden Objekte der Struktur- und Topologiebeschreibung gebunden. In Analogie zu Geometrie- und Kinematikinformationen können den einzelnen Objekten der Struktur- und Topologiebeschreibung Logik- und Verhaltensinformationen zugeordnet werden. Dabei ist es möglich, die verschiedenen denkbaren Verhaltensweisen von Systemen, Komponenten und Geräten innerhalb eines Produktionssystems abzubilden. Die Logik- und Verhaltensbeschreibung basiert auf dem bekannten und praktisch weitreichend genutzten Datenformat PLCopen XML in Version 2.0 und 2.0.1, das initial für den Austausch von Steuerungsprojekten nach IEC61131-3 spezifiziert wurde. AutomationML definiert, wie mit diesem Format unterschiedlichste, in der Praxis verwendete Modelle für Logik- und Verhaltensinformationen modelliert werden. So können unter anderem Gantt Charts, PERT Charts, Impulsdiagramme, Sequential Function Charts, State Charts und Cause and Effect Matrizen konsistent und verlustfrei übertragen werden. Auch sie werden unter Nutzung von Referenzierungsmechanismen, die in CAEX in der InterfaceClassLibrary spezifiziert sind, mit den sie betreffenden Objekten der Struktur- und Topologiebeschreibung verbunden. AutomationML entwickelt derzeit weitere Anwendungsmöglichkeiten der genannten Formate und Strukturen z.B. für die Beschreibung von Kommunikationssystemen oder mechatronischen Einheiten.

Anwendungsbeispiele für AutomationML

Es wurden bereits einige Anwendungsmöglichkeiten durch die Mitglieder des AutomationML umgesetzt, von denen wiederum einige schon im produktiven Einsatz sind. So können z.B. die Konstruktionsdaten aus Catia V5 sowie die Bewegungsplanungen aus RobotStudio sicher und verlustfrei an Robcad über AutomationML übergeben werden, so dass die virtuelle Inbetriebnahme einer geplanten Roboterzelle ermöglicht wird. Dabei kommt das integrierte Format Collada zum Einsatz. Weiter können Ablaufbeschreibungen, die z.B. als Gantt Chart in Excel modelliert sind, oder Schrittketten, die in Delmia V5 erstellt wurden, direkt an Steuerungsprogrammierwerkzeuge wie Multiprog weitergegeben werden. Hierfür wird unter anderem das integrierte Format PLCopen XML genutzt. AutomationML bietet außerdem mit dem Austausch hierarchischer Anlagenstrukturen die Möglichkeit, die Anlagenstruktur, z.B. gemäß der Ortskennzeichen der Implementierung, weiterzugeben. Zudem kann für jedes Element innerhalb der Ortsstruktur die vollständige Dokumentation sowie die wichtigsten konstruktiven Daten als Parameter in der hierarchischen Struktur repräsentiert werden. Dadurch ist eine lückenlose und gut strukturierte Dokumentation der aktuellen Anlagenstruktur, z.B. für den Wartungstechniker, vorhanden. Ebenso ist ein gezielter Austausch von entsprechenden Informationen zwischen verschiedensten Werkzeugen bis hin zu ERP-Systemen möglich. Damit können z.B. Geräteinformationen zwischen Herstellern und Anwendern ausgetauscht und einfach in die Dokumentation integriert werden. In den folgenden SPS-Magazinen werden einige Anwendungsfälle, Einsatzmöglichkeiten und Technologien zur Nutzung von AutomationML beschrieben.

Seiten: 1 2Auf einer Seite lesen

AutomationML e.V. c/o IAF
http://www.automationml.org

Das könnte Sie auch Interessieren

Weitere Beiträge

Bild: Ceratizit Deutschland GmbH
Bild: Ceratizit Deutschland GmbH
Werkzeuge – immer passend

Werkzeuge – immer passend

Eine digitalisierte Fertigung hat viele Gesichter… und Recker Technik aus Eschweiler setzt ihr auf jeden Fall einen Smiley auf. Dort bringt die Produktion mit digitalen Zwillingen mehr Effizienz in den Alltag sowie gleichzeitig mehr Überblick über das Toolmanagement und die Werkzeugkosten. Mit dabei: Zwei Tool-O-Maten, die intelligenten Werkzeugausgabesysteme von Ceratizit – dank denen immer das passende Werkzeug für den Job zur Hand ist.

mehr lesen
Bild: Hainbuch GmbH
Bild: Hainbuch GmbH
„Wie passende Spanntechnik die Automation voranbringt“

„Wie passende Spanntechnik die Automation voranbringt“

Zunehmend individuellere Kundenanforderungen, mehr Schwankungen im Auftragseingang und weniger Fachkräfte – diese Faktoren beeinflussen die Fertigungsplanung zunehmend. Gerade bei kleinen Herstellungschargen mit Losgrößen unter 100 macht in diesem Spannungsfeld die Automatisierung, etwa von Hainbuch, den Unterschied. Ein entscheidender Ansatzpunkt in der Umsetzung ist neben Maschine, Roboter und Bediener der Rüst- und Spannprozess.

mehr lesen
Bild: Schunk SE & Co. KG Spanntechnik
Bild: Schunk SE & Co. KG Spanntechnik
Futter für die Ewigkeit

Futter für die Ewigkeit

Siemens Energy setzt für die Präzisionsbearbeitung an einer Horizontaldrehmaschine Magnos Elektropermanent-Magnetspannfutter von Schunk ein. Dank der gleichmäßig dauerhaft wirkenden Magnetspannkraft erfolgt das Spannen der Werkstücke deformations- und vibrationsarm – für eine ausgezeichnete Bearbeitungs- und Oberflächenqualität. Mit der zugehörigen App lässt sich die Spannsituation simulieren und sicher parametrieren.

mehr lesen