Wissenschaftlicher Newsticker Mai 2016

AutomationML auf dem Sprung zur umfassenden Anwendung

Mai 2016 Im Jahre 2006 begann die Entwicklung des Datenaustauschformates AutomationML an der das IAF von Anfang an mit beteiligt war. In nur 10 Jahren konnte mit der Automation Markup Language (AutomationML) eine Datenaustauschtechnologie geschaffen werden, die vielfältige Fragen im Rahmen des Datenmanagements in Entwurfsorganisationen beim Entwurf von Produktionssystemen lösen kann.

Der Entwurf von Produktionssystemen ist ein komplexer Prozess, der verschiedene Ingenieure aus verschiedenen Entwurfsbereichen einbezieht, die verschiedene Entwurfsaktivitäten durchführen und verschiedene Entwurfsartefakte nutzen / entwerfen, die nötig sind, um letztendlich in der Lage zu sein, ein Produktionssystem zu erstellen, zu nutzen und zu warten.

Wie unterschiedliche Untersuchungen gezeigt haben, umfasst der Entwurf von Produktionssystemen einen großen Anteil manueller Tätigkeiten, in deren Rahmen jedoch Entwurfsschritte von unterschiedlichen Entwurfswerkzeugen wiederholt werden. Dies liegt im Fehlen geeigneter Instrumente für einen Datenaustausch zwischen diesen Werkzeugen begründet.

Um einen verlustfreien Datenaustausch zu gewährleisten, wurden verschiedene Herangehensweisen betrachtet, die von der Nutzung komplexer in sich geschlossener Werkzeugsysteme für die gesamte Entwurfskette bis zur Nutzung von über Datenaustauschformate gekoppelten Einzelwerkzeugen reichen. Sie besitzen jeweils ihre besonderen Vor- und Nachteile. Da jedoch Entwurfsorganisationen zunehmend agil zu gestalten sind, ist die Bedeutung der Werkzeugkopplung über Datenaustauschformate besonders hoch einzuschätzen.

Für ein Datenaustauschformat das im Kontext des Entwurfs von Produktionssystemen verwendet werden soll gibt es eine Reihe von (manchmal widersprüchlichen) Anforderungen, die erfüllt sein müssen:

Das Datenformat sollte für verschiedene Anwendungsfälle angepasst werden können und flexible in Bezug auf Erweiterungen und Verände-rungen sein.
Die Datendarstellung sollte effizient sein.
Die Datendarstellung sollte für Menschen lesbar sein.
Die Datendarstellung sollte auf internationalen Standards basieren.

Diese Voraussetzungen erfüllen XML basierte Datenformate problemlos.

Der Datenaustausch zwischen Entwurfswerkzeugen muss auf zwei unterschiedliche Standardisierungsniveaus betrachtet werden, der syntaktischen und der semantischen Ebene. Auf der syntaktischen Ebene wird die korrekte informationstechnische Darstellung der Datenobjekte innerhalb des Datenaustauschformats definiert. Dabei wird das Vokabular des Datenaustausches bereitgestellt. Im Gegensatz dazu wird auf der semantischen Ebene die Interpretation von Datenobjekten, d.h. ihre Bedeutung innerhalb der Konzeptualisierung von Objekten innerhalb der Entwurfswerkzeugketten, definiert.

Datenaustauschformate können die Umsetzung dieser zwei Ebenen auf zwei Arten angehen. Entweder werden Syntax und Semantik gemeinsam definiert wie es bei der Entwicklung von STEP umgesetzt wurde oder Syntax und Semantik werden getrennt definiert wie bei AutomationML realisiert. Da die getrennte Definition der Semantik größere Flexibilität und Anpassungsvermögen des Datenaustauschformates für den Anwendungsfall ermöglicht, erscheint dieser Ansatz zu bevorzugen zu sein.

Zum aktuellen Zeitpunkt stellt AutomationML sowohl Syntax als auch Semantik für den Austausch von Informationen bereit die in mindestens zwei Entwurfsaktivitäten des Produktionssystementwurfsprozesse relevant sind und damit in mindestens zwei Werkzeugen der Werkzeugketten verwendet werden:

Topologieinformationen: Diese Inforationsmenge beschreibt die hierarchische Strukturierung des Produktionssystems von der Produktionssystemebene, über die Zell- und Ressourcenebenen bis hinunter zu den Ebenen der Geräte und mechanischen Bauteile. Sie deckt dabei neben den einzelnen Hierarchieelementen auch deren Relationen und beschreibenden Eigenschaften ab.
Informationen bezogen auf die mechanischen Eigenschaften: Diese Informationsmenge beschreibt die mechanische Konstruktion des Produktionssystems einschließlich seiner geometrischen und kinematischen Eigenschaften. Üblicher Weise wird sie als technische Zeichnung eines MCAD Werkzeuges entwickelt. Zudem enthält diese Informationsmenge physikalische Eigenschaften des Produktionssystems und seiner Teile wie Kräfte, Geschwindigkeiten und Drehwinkel sowie chemische Eigenschaften wir Materialinformationen.
Informationen bezogen auf die elektrischen, pneumatischen und hydraulischen Eigenschaften: Diese Informationsmenge die elektrische und fluidische Konstruktion des Produktionssystems einschließlich der Verkabelung und Verrohrung wie sie mit ECAD und FCAD Werkzeugen erstellt werden können. Dazu umfasst sie zum einen die verbundenen Komponenten und zum anderen die Verbindungen zwischen ihnen mit ihren Schnittstellen und den jeweiligen Elektrik und Fludik bezogenen Eigenschaften.
Informationen bezogen auf die Funktionen des Produktionssystems: Diese Informationsmenge dient der Charakterisierung der Funktionen des Produktionssystems und seiner Komponenten. Dazu umfasst sie Verhaltensmodelle des ungesteuerten (physikalisch/chemisch/etc. möglichen) Verhalten sowie des gesteuerten Verhaltens. Zu diesen kommen die funktionalen Parameter und die technischen Parameter. in von dieser Informationsmenge betrachteten Funktionen beziehen sich dabei nicht nur auf die in der Produktion notwendigen Funktionen sondern auch auf alle notwendigen Hilf-, Diagnose, Wartungs-, etc. Funktionen.
Informationen bezogen auf die Steuerung des Produktionssystems: Diese Informationsmenge umfasst alle steuerungsgerätebezogenen Informationen. Dies sind insbesondere die Hardwarekonfiguration, Steuerungscode und Steuerungsparameter.
Weitere Informationen: Diese Informationsmenge subsumiert weitere notwendige Informationen wie betriebswirtschaftliche relevante Informationen wie Herstellerartikelnummern oder Preise, organisatorische Informationen wie Montage- und Wartungsanleitungen, Handbücher usw.

Abbildung 1: Abgebildete Informationsmengen

AutomationML folgt bei der Modellierung von Entwurfsinformationen einem objektorientierten Ansatz und ermöglicht die Beschreibung von physischen und logischen Anlagenkomponenten als Datenobjekte, die unterschiedliche Aspekte zusammenfassen. Objekte können dabei eine Hierarchiebilden, d.h. ein Objekt kann aus anderen Unterobjekten bestehen und kann selbst ein Teil einer größeren Komponente sein. Typische Objekte in der Fabrikautomatisierung enthalten Information über die Struktur (Topologie), Geometrie und Kinematik sowie das Verhalten.

Dabei folgt AutomationML einem modularen Aufbau und integriert und adaptiert verschiedene bereits existierende XML-basierenden Datenformate unter einem Dach, dem sogenannten Dachformat. Diese Datenformate werden „as-is“ genutzt und sind nicht für AutomationML Anforderungen verzweigt worden. Jedoch definiert AutomationML Anwendungsregeln.

Abbildung 2: Struktur eines AutomationML Projektes

Logisch unterteilt sich AutomationML in die Beschreibung der Anlagestruktur und der Kommunikationssysteme mithilfe von CAEX nach IEC 62424, die Beschreibung der Geometrie und der Kinematik mithilfe von COLLADA 1.4.1 und 1.5.0 (ISO/PAS 17506:2012), die Beschreibung der Steuerung in Bezug auf logische Daten mithilfe von PLCopen XML 2.0 und 2.0.1 und die Beschreibung der Beziehungen zwischen den AutomationML Objekten und Verweisen zu Informationen, die in Dokumenten außerhalb des Dachformats gespeichert sind.

AutomationML wird derzeit in der IEC 62714 Normenreihe standardisiert.

Das Fundament von AutomationML ist der Einsatz von CAEX als Dachformat und die Definition eines geeigneten CAEX Profils, das alle relevanten Anforderungen von AutomationML zur Modellierung von Entwurfsinformationen eines Produktionssystems, zur Integration der drei genannten Datenformate CAEX, COLLADA und PLCopen XML und zur Erweiterung, falls zukünftig erforderlich, erfüllt.

Abbildung 3: AutomationML Topologiebeschreibung

CAEX ermöglicht die oben beschriebene, objektorientierte Vorgehensweise. Es erlaubt die Festlegung von Semantiken der Systemobjekte unter Nutzung von Rollenklassen, die in RoleClassLibraries (Rollenklassenbibliotheken) definiert und erfasst sind, spezifiziert werden. Schnittstellen (Interfaces) zwischen Systemobjekten werden unter Nutzung von Interfaceklassen, die in InterfaceClassLibraries (Interfaceklassenbibliotheken) definiert und erfasst sind, spezifiziert. Auf Basis beider Typen von Klassen (und der entsprechenden Bibliotheken) werden Klassen von Systemobjekten unter Nutzung von SystemUnitKlassen (SUC), die in SystemUnitClassLibraries (SystemUnitKlassenbibliotheken) definiert und erfasst sind, modelliert. Letztlich dienen alle modellierten Klassen der semantisch eindeutigen Modellierung der eigentlichen Projektinformationen, d.h. der einzelnen Objekte der modellierten Produktionssystems, in einer (oder mehreren) InstanceHierarchies (IH) als eine Hierarchie von InternalElements (IE) unter Bezugnahme auf sowohl SystemUnitKlassen, von denen sie abgeleitet werden, als auch Rollenklassen, die ihre Semantiken bestimmen. Diese können zur Verknüpfung untereinander oder mit extern modellierten Informationen (bspw. COLLADA und PLCopen XML Dateien) Interfaces enthalten. Die spezifischen Eigenschaften von Objekten, SystemUnitKlassen, Rollen und Interfaces werden über Attribute abgebildet.

Für weitere Details sei noch einmal auf die AutomationML Whitepaper auf www.automationML.org sowie auf das „AutomationML in a Nutshell“ Dokument das IAF verwiesen.

Ansprechpartner: apl. Prof. Dr.-Ing. habil. Arndt Lüder