AutomationML – Fachexperten erklären das FormatWhitepaper

2

AutomationML – Fachexperten erklären das FormatDieses Whitepaper umfasst Beiträge, die den Aufbau desAutomationML Datenaustauschformats selbst beschrei-ben und die Möglichkeiten, die es durch seinen Aufbaubietet. Es werden tiefere Einblicke in die Möglichkeitenund Notwendigkeiten zur Implementierung von Auto-mationML Schnittstellen gegeben, um die Anwendungin Software-Werkzeugen zu erleichtern. ExemplarischeAnwendungsbeispiele zeigen auf, wo AutomationMLbereits eingesetzt wird bzw. werden kann.

Teil 01: ein Überblick ..................................................................................Seite 03

Teil 02: die Architektur ...............................................................................Seite 06

Teil 03: Programmierung ............................................................................Seite 09

Teil 04: Datenaustausch ..............................................................................Seite 12

Teil 05: Effizienz für den Engineeringprozess ...........................................Seite 16

Teil 06: Umgebung für das Multi-User-Engineering .................................Seite 19

Teil 07: Kommunikation .............................................................................Seite 22

Teil 08: Integration MES-Wissen.................................................................Seite 26

Teil 09: Verhältnismäßig gut! .....................................................................Seite 29

Teil 10: Warum ein Engineering-Weltmodell bisher nicht gelang...........Seite 34

Teil 11: Engineering Workflow...................................................................Seite 37

Teil 12: AutomationML verbindet Software-Werkzeuge .........................Seite 40

Teil 13: Erreichtes und Zukünftiges............................................................Seite 43

3

D ie AIDA-Gruppe (Automatisierungsinitiative Deutscher-Automobilhersteller) stellte im Jahre 2005 in einer ge-meinsamen Untersuchung fest, dass alleine über 50%

der Kosten der gesamten Anlagensteuerungstechnik auf dasEngineering entfielen (Bild 2). Daraufhin startete Daimler einProjekt, mit dem Ziel, diese Engineeringkosten mindestens zuhalbieren. Bald war klar, dass einen erheblichen Anteil des En-gineeringaufwandes das Übertragen der Engineering-Datenvon einem Tool zum anderen verursacht. Nach ersten Evaluie-rungen von Austauschformaten initiierte Daimler im Oktober2006 die Entwicklung und Standardisierung der Automati-onML als Zwischenformat der Digitalen Fabrik, zusammen mitden Firmen ABB, Kuka, Rockwell Automation, Siemens, netAl-lied und Zühlke sowie den Universitäten Karlsruhe und Mag-

Durch die zunehmende Bedeutung der Software im Be-reich der Industrie, und speziell in der Automatisierungs-technik, haben sich neue Schnittstellenproblemegezeigt. Wenn man sich den ganzen Prozess von der Pro-duktentwicklung bis hin zur Qualitätssicherung betrach-tet, dann gibt es immer dieselben Daten, die durch dengesamten Prozess hindurch benötigt und geschleustwerden. Aktuell gibt es viele Systembrüche der unter-schiedlichen Engineeringwerkzeuge. AutomationML hatzum Ziel, diesen Datenaustausch signifikant zu vereinfa-chen. Wir stellen AutomationML im Rahmen einer sechs-teiligen Serie vor und beginnen mit einem Überblick.

AutomationML – ein ÜberblickEin Standard für die Verbesserung des Datenaustauschs von Engineeringwerkzeugen

Bild 1: Aktuell von AutomationML abgedeckte Aspekte

4

deburg. Im Frühjahr 2009 öffnete sich das bis dahin geschlos-sene Industriekonsortium durch die Gründung eines Vereins.

Motivation und Zielsetzung

Wie in Bild 2 zu sehen ist, stellt in der Automatisierungstech-nik die Planung der Anlagen einen großen Kostenfaktor dar.Für die verschiedenen Aufgaben wie z.B. Hardwaredesign,Software-Projektierung oder die virtuelle Inbetriebnahme,werden unterschiedliche Engineering-Werkzeuge benötigtund eingesetzt. Teilweise kommen Werkzeuge in speziellenNischen zum Einsatz und auch Hersteller-Tools zur Parame-trierung und Programmierung von Komponenten sind am

Prozess beteiligt. Des Weiteren wird jeder Planer das ihm ver-traute, also sein spezielles ‘Best in Class-Tool’ einsetzen wol-len. Aufgrund dieser heterogenen Toollandschaft stellt derDatenaustausch zwischen den Werkzeugen einen wichtigenAspekt dar. Aktuell werden die Daten oft in proprietären Da-tenformaten übertragen und gespeichert, die sich nur miteinem sehr begrenzten Kreis an Werkzeugen, oft nur firmen-spezifischen Tools, einlesen lassen. Stehen keine Schnittstellenzur Verfügung, müssen Daten in den verschiedenen Werkzeu-gen manuell eingegeben und nachgepflegt werden. Insge-samt führt dies zu einem sehr ineffizienten undfehleranfälligen Planungsprozess. Der AutomationML e.V. hatsich zum Ziel gesetzt, diesen Datenaustausch zwischen den

Engineeringwerkzeugen zu verbessern und zu vereinheitli-chen. Dabei wurde von Anfang an konsequent darauf geach-tet, dass kein neues Datenformat entwickelt, sondern, dassauf bereits existierende Formate zurückgegriffen wird. DieseFormate sollten bzw. müssen folgenden Kriterien genügen:

• Sie müssen für jeden Anwender absolut frei zugänglich und kostenlos sein.• Die Formate sollten nach ISO oder IEC standardisiert sein, bzw. dieses istanzustreben.

• Die Formate sollten XML-basiert sein.• Die Formate müssen noch gepflegt werden und der Besitzer des Formatsmuss für Weiterentwicklungsvorschläge unsererseits offen sein.

Mithilfe von AutomationML sollen mechatronische Objekte bis

Projekt-Management 3%

Vorinbetriebnahme 2%

Montage 11%

Kaufteile 28%

Geometrie-Simulation 1%

Programmierung Roboter Off-/Online 5%

Projektierung (SW/H/V) [incl. IBN] 51%

Bild 2: Kostenstruktur der Steuerungstechnik im Anlagenbau aus dem Jahre 2005

5

hin zu ganzen Fertigungsanlagen in den für den Engineering-prozess relevanten Aspekten beschrieben werden. Automati-onML umfasst aktuell folgende Bereiche (Bild 1):

• Topologie zur Abbildung von Strukturen, Attributen, Schnittstellen, Rela-tionen, Geometrie und Kinematik,• Logik und Verhalten, • Semantik und Ontologien von Objekten auf Basis von Bibliotheken.

Weitere Bereiche wie z.B. Kommunikation und Mechatronik be-finden sich in der Vorbereitung. AutomationML kombiniert exis-tierende XML-Datenformate zur Abdeckung dieser Bereiche.CAEX, standardisiert über IEC62424, bildet das Dachformat zurAbbildung der Topologie. Aus diesem Format heraus wird aufdas Format Collada verlinkt, in dem Geometrie und Kinematikabgebildet werden. Für die Umfänge Logik und Verhalten stehtPLCopen XML zur Verfügung. Das Konzept von Rollenbibliothe-ken ermöglicht die Darstellung von Semantiken.

Einige Beispielapplikationen

Daimler hat als erster Nutzer des Formats sehr früh begonnenAutomationML in seine Planungsprozesse zu integrieren. Soentstanden in den letzten Jahren u.a. folgende Anwendungen,die mittlerweile alle im industriellen Umfeld eingesetzt sind:

• Automatische Bahnplanung ‘Pathfinder’ für Roboter• Visualisierung der Fabrikplanung mit VEO:factory• Virtuelle Inbetriebnahme

Im Rahmen dieser Realisierungen wurden Topologieinformatio-nen inklusive Rollen, Geometrie- und Kinematikinhalte sowieanwendungsspezifische Daten erfolgreich zwischen den Werk-

zeugen ausgetauscht. Die Anwendungen haben nachgewiesen,dass der Datenaustausch mit AutomationML funktioniert, auchwenn noch nicht alle Teile komplett integriert sind.

Ein kurzer Blick voraus

AutomationML erweitert seine AkzeptanzAutomationML wird ein etablierter Standard für den Austauschvon Engineering – Daten im Anlagen und Maschinenbau wer-den. Dazu stellt der Verein umfassende Dokumentationen undInformationsmaterial zur Nutzung von AutomationML sowie dieverschiedensten Beispielprojekte aus den unterschiedlichen in-dustriellen Anwendungsfeldern auf seiner Homepage www.au-tomationml.org bereit.

AutomationML ist standardisiertDer AutomationML e.V. hat in den vergangenen Jahren be-reits viel Energie in die Standardisierung der zentralen Be-standteile von AutomationML gelegt. So erwarten wir in 2013den Abschluss des ersten Teils des Standards IEC62714 -1 ‘En-gineering data exchange format for use in industrial automa-tion systems engineering – Part 1: Architecture and GeneralRequirements’. Die anderen Teile werden momentan parallelin den Gremien der IEC und DKE Arbeitsgruppe vorangetrie-ben.

AutomationML e.V. ist innovativDer AutomationML e.V. hat sich zur Aufgabe gemacht, in be-stimmten Zyklen die momentanen Lösungen zu überprüfen undgegebenenfalls anzupassen.

AutomationML e.V. bietet technologische UnterstützungDer AutomationML e.V. bietet zur technologischen Unterstüt-

zung und Qualitätssicherung bei der Anwendung und der Umsetzung des Datenformats Konformitätstests und Referenz-werkzeuge an. Die AutomationML Engine und auch der Editorwerden technologisch weitergeführt und weiterentwickelt.

AutomationML e.V. ist eine offene CommunityDer AutomationML e.V. ist offen für Firmen, Institute und Hoch-schulen. Der Mitgliederbeitrag ist überschaubar. Mitglieder kön-nen ihre Ideen direkt in das Format einbringen. �

www.automationml.org

Autor: Anton Hirzle, SeniorManager, Daimler AG

6

Bild 1: Angestrebte Nutzung von AutomationML im Entwurfsprozess

Der AutomationML e.V. betrachtet den Entwurfsprozessvon Produktionssystemen. Dies geht vom Produktent-wurf über den Anlagenentwurf und das ‘Detailed En-

gineering’ bis hin zur virtuellen Inbetriebnahme und zurAnlagenstandardisierung. Er ist dabei bestrebt, ein Datenaus-tauschformat zu entwickeln, das für jede beliebige Paarungvon Werkzeugen der Entwurfskette als Datenformat zur Wei-tergabe von Entwurfsergebnissen genutzt werden kann. Diesist in Bild 1 beispielhaft dargestellt. AutomationML stellt dabeidas reine Datenformat dar und befasst sich nicht mit derÜbertragung der Inhalte oder Schnittstellen zu entsprechen-den Werkzeugen.

Architektur von AutomationML

Ausgangspunkt für AutomationML bildet die Abbildung derStruktur bzw. Topologie eines Produktionssystems. Diese um-fasst die hierarchische Strukturierung der Anlagenobjekte, diejeweils durch individuelle Datenobjekte repräsentiert werden.Dabei wird die Anlage bzw. Teilanlage bis zu einem spezifischen,den Notwendigkeiten der jeweiligen Anwendungsfälle ange-passten Detaillierungsgrad untergliedert. Für jedes Anlagenob-jekt werden die entsprechenden auszutauschendenInformationen als Objekteigenschaften abgebildet. Zusammen-hänge zwischen Anlagenobjekten werden über Relationen re-präsentiert. Zur Darstellung der Struktur- undTopologieinformationen wird auf das bereits international in derIEC62424 standardisierte Datenformat CAEX (Computer Aided

Durch die zunehmende Bedeutung der Software im Bereich der Industrie und speziell in der Automatisierungs-technik haben sich neue Schnittstellenprobleme gezeigt. Aktuell gibt es viele Systembrüche zwischen den unter-schiedlichen Engineeringwerkzeugen. AutomationML hat zum Ziel, diesen Datenaustausch signifikant zuvereinfachen. Wir stellen AutomationML im Rahmen einer sechsteiligen Serie vor und fahren in Teil 2 fort mitder Architektur.

Serie AutomationML Teil 2: Ein Standard für die Verbesserung desDatenaustauschs von Engineeringwerkzeugen

AutomationML - die Architektur

7

Engineering Exchange) zurückgegriffen. Dieses bietet objektori-entierte Grundkonzepte, die für die Darstellung von Anlagen-strukturen eingesetzt werden. Dazu spezifiziert AutomationMLdetailliert, wie welches Grundkonzept von CAEX einzusetzenist und definiert darüber hinaus Einschränkungen und Regeln

für den Einsatz von CAEX. Das erste der genutzten Grundkon-zepte von CAEX ist die InstanceHierarchy. Sie ermöglicht die Ab-bildung der hierarchischen Anlagenstruktur einesProduktionssystems. Mithilfe der SystemUnitClassLibraries wer-den (herstellerspezifische) Bibliotheken von Anlagenkomponen-

ten beschrieben. Die RoleClassLibraries ermöglichen die Defini-tion und Nutzung von Semantiken für Anlagenkomponentenbzw. für ihre Beschreibungsmittel. Das vierte genutzte Grund-konzept sind die InterfaceClassLibraries. Sie umfassen die Defi-nition verschiedener Schnittstellentypen, mit denenZusammenhänge zwischen verschiedenen Anlagenkomponen-ten sowie Beziehungen zu extern abgespeicherten Informatio-nen beschrieben werden können. Die Bibliothekskonzepteermöglichen die Definition, Darstellung und Nutzung von Tem-plates für einzelne Objekte. Über sie können allgemein verbind-liche als auch anwenderspezifische Grundstrukturenbeschrieben und ausgetauscht werden. Die InstanceHierarchyerfüllt für das eigentliche Engineering-Projekt den gleichenZweck. Mittels des Konzeptes der Rollenbibliotheken (RoleClass-Lib) kann einzelnen Objekten sowohl in der SystemUnitClassLi-brary als auch der InstanceHierarchy eine bestimmte Semantikzugeordnet werden. Dadurch wird den Objekten unabhängigvon ihrer eigentlichen Benennung eine Bedeutung im Rahmender Anlage zugewiesen. Das Konzept der Interfaces und Rela-tionen ermöglicht es, Objekte über Hierarchiegrenzen hinwegin Beziehung zu setzen und schafft die Möglichkeit, auf Infor-mationen außerhalb der CAEX-Beschreibung zu referenzieren.Dazu werden entsprechende InterfaceClass-Objekte im Rahmeneiner InterfaceClassLibrary spezifiziert. Diese werden in der Sys-temUnitClassLibrary bzw. der InstanceHierarchy genutzt undmittels InternalLinks verbunden. Zudem ermöglichen Referen-zen in den Objekten der InstanceHierarchy, die Instanziierungvon Objekten der SystemUnitClassLibrary. Den einzelnen Objek-ten der Struktur- und Topologiebeschreibung können Geome-trie- und Kinematikinformationen zugeordnet werden. Diesebeschreiben die geometrischen Verhältnisse der einzelnen Ob-jekte als Körper in beliebiger Detailliertheit sowie die Eigen-schaften der Beweglichkeit dieser und ihren Zusammenhang.

Bild 2: Toplevel-Architektur von AutomationML

8

XML-basiertes Datenformat als Grundlage

Grundlage der Geometrie- und Kinematikbeschreibung ist dasaus 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 Darstel-lung der geometrischen und kinematischen Eigenschaftenvon Körpern als geometrische und kinematische Szenen.Unter Nutzung von Referenzierungsmechanismen, die inCAEX in der InterfaceClassLibrary spezifiziert sind, werden dieeinzelnen Geometrie- und Kinematikbeschreibungen an diebetreffenden Objekte der Struktur- und Topologiebeschrei-bung gebunden. In Analogie zu Geometrie- und Kinematik-informationen können den einzelnen Objekten der Struktur-und Topologiebeschreibung Logik- und Verhaltensinformatio-nen zugeordnet werden. Dabei ist es möglich, die verschie-denen denkbaren Verhaltensweisen von Systemen,Komponenten und Geräten innerhalb eines Produktionssys-tems abzubilden. Die Logik- und Verhaltensbeschreibung ba-siert auf dem bekannten und praktisch weitreichendgenutzten Datenformat PLCopen XML in Version 2.0 und2.0.1, das initial für den Austausch von Steuerungsprojektennach IEC61131-3 spezifiziert wurde. AutomationML definiert,wie mit diesem Format unterschiedlichste, in der Praxis ver-wendete Modelle für Logik- und Verhaltensinformationenmodelliert werden. So können unter anderem Gantt Charts,PERT Charts, Impulsdiagramme, Sequential Function Charts,State Charts und Cause and Effect Matrizen konsistent undverlustfrei übertragen werden. Auch sie werden unter Nut-zung von Referenzierungsmechanismen, die in CAEX in derInterfaceClassLibrary spezifiziert sind, mit den sie betreffen-den Objekten der Struktur- und Topologiebeschreibung ver-bunden. AutomationML entwickelt derzeit weitere

Anwendungsmöglichkeiten der genannten Formate undStrukturen z.B. für die Beschreibung von Kommunikationssys-temen oder mechatronischen Einheiten.

Anwendungsbeispiele für AutomationML

Es wurden bereits einige Anwendungsmöglichkeiten durchdie Mitglieder des AutomationML umgesetzt, von denen wie-derum einige schon im produktiven Einsatz sind. So könnenz.B. die Konstruktionsdaten aus Catia V5 sowie die Bewe-gungsplanungen aus RobotStudio sicher und verlustfrei anRobcad über AutomationML übergeben werden, so dass dievirtuelle Inbetriebnahme einer geplanten Roboterzelle ermög-licht wird. Dabei kommt das integrierte Format Collada zumEinsatz. Weiter können Ablaufbeschreibungen, die z.B. alsGantt Chart in Excel modelliert sind, oder Schrittketten, diein Delmia V5 erstellt wurden, direkt an Steuerungsprogram-mierwerkzeuge wie Multiprog weitergegeben werden. Hier-für wird unter anderem das integrierte Format PLCopen XML genutzt. AutomationML bietet außerdem mitdem Austausch hierarchischer Anlagenstrukturen die Mög-lichkeit, die Anlagenstruktur, z.B. gemäß der Ortskennzeichender Implementierung, weiterzugeben. Zudem kann für jedesElement innerhalb der Ortsstruktur die vollständige Dokumen-tation sowie die wichtigsten konstruktiven Daten als Parame-ter in der hierarchischen Struktur repräsentiert werden.Dadurch ist eine lückenlose und gut strukturierte Dokumen-tation der aktuellen Anlagenstruktur, z.B. für den Wartungs-techniker, vorhanden. Ebenso ist ein gezielter Austausch vonentsprechenden Informationen zwischen verschiedenstenWerkzeugen bis hin zu ERP-Systemen möglich. Damit könnenz.B. Geräteinformationen zwischen Herstellern und Anwen-dern ausgetauscht und einfach in die Dokumentation inte-

griert werden. In den folgenden SPS-Magazinen werden ei-nige Anwendungsfälle, Einsatzmöglichkeiten und Technolo-gien zur Nutzung von AutomationML beschrieben. �

www.automationml.org

Autor: apl. Prof. Dr.-Ing.habil. Arndt Lüder, LeiterCenter Verteilte Systeme(CVS), Otto-von-GuerickeUniversität Magdeburg

Autor: Lorenz Hundt, Wis-senschaftlicher MitarbeiterCVS, Otto-von-GuerickeUniversität Magdeburg

Autor: Nicole Schmidt, Wis-senschaftliche Mitarbeite-rin CVS, Otto-von-GuerickeUniversität Magdeburg

Autor: Miriam Schleipen,Fraunhofer Institut IOSB,Gruppenleiterin Leitsys-teme und Anlagenmodel-lierung

9

Parallel zu AutomationML entwickelte der AutomationMLe.V. eine freie Software für Entwickler – die Automati-onML-Engine [3]. Sie spiegelt das CAEX-Datenmodell in

Form einer C#-Klassenstruktur exakt wider und enthält alle Klas-sen und Methoden, um CAEX-Objekte (Klassen und Instanzen)manipulieren zu können. Der Softwareentwickler wird durchdiese Software befreit, die Einhaltung des CAEX-Schemas zuüberwachen. Stattdessen operiert er auf Klassenebene, wäh-rend die Engine im Hintergrund konforme CAEX-Dateien er-zeugt oder liest. Entwicklungsvoraussetzung zur Nutzung derAutomationML-Engine ist das Betriebssystem WindowsXP oderhöher sowie Visual Studio Version 2008 oder höher. Die Einbin-dung der Engine in eigene Projekte erfolgt über die Referenzie-rung der Engine-dlls.

AutomationML-Programmierung

Bild 1 zeigt das Basisszenario: Der Datenaustausch zwischenzwei Werkzeugen benötigt einen Exporter und einen Importer.Sowohl Exporter als auch Importer müssen AutomationML-Da-teien erzeugen, lesen und manipulieren können. Daraus lassensich Basisfunktionen und erweiterte Funktionen ableiten, die imFolgenden schrittweise beleuchtet werden.

Bild 1: Realer Datenaustausch mit CAEX

Ziel von AutomationML [1] ist der Datenaustausch zwischen Werkzeugen der Anlagenplanung. Als herstellerneu-trales, standardisiertes und XML-basiertes Datenformat kann es derzeit Planungsinformationen bezüglich Anla-gentopologie/Struktur, Geometrie/Kinematik sowie Logik/Verhalten abbilden. Dabei bildet CAEX [2] dasObjektmodell der Engineeringdaten ab. Die Integration von AutomationML in die Schnittstellen von Werkzeugenwirft jedoch immer wieder die Frage auf: Wie aufwändig ist die Programmierung von Ex- und Importern? DieserBeitrag beleuchtet dies anhand verschiedener Programmierszenarien.

Serie AutomationML Teil 3: Effizientes Programmieren mit der AutomationML-Engine

AutomationML-Programmierung

10

CAEX-Basisprogrammierung

1. Erzeugen eines CAEX-DokumentesFür das Erzeugen eines leeren CAEX-Dokumentes genügt eineZeile Quelltext (siehe Bild 2). Im Hintergrund, für den Anwenderverborgen, erzeugt die AutomationML-Engine alle benötigtenXML-Knoten [4].

2. Öffnen/Speichern einer CAEX-DateiDas Öffnen und Speichern eines CAEX-Dokumentes erfordertebenfalls jeweils nur eine einzige Zeile Quelltext (siehe Bild 3und Bild 4). Dies funktioniert mit beliebig komplexen CAEX-Dateien.

3. Erzeugen von CAEX-HierarchienCAEX unterstützt vier Arten von Hierarchien: eine Instanz-Hie-rarchie für die eigentlichen Projektdaten sowie drei Bibliotheks-arten. Im AutomationML-Editor [3] kann jede dieser Hierarchienmit einem einzigen Mausklick erzeugt werden (siehe Bild 5). Bild6 zeigt den zugehörigen C#-Quelltext, um alle vier Hierarchienzu erzeugen. Dieses Beispiel unterstreicht eine Erfahrung desAutors: Das Pro grammieren eines einfachen CAEX-Browsers ge -lingt innerhalb von 30min.

4. Erzeugen von Hierarchie-ElementenIm nächsten Schritt wird die Instanz-Hierarchie mit Objektengefüllt. Ihre Architektur ermöglicht das Modellieren beliebigtiefer Objektstrukturen. Bild 7 zeigt dies beispielhaft anhandvon zwei Objekten Tank und Nozzle im AutomationML-Editorsowie drei Attributen des Tanks. Bild 8 zeigt den zugehörigenC#-Code: Zunächst werden Variablen IE1 und IE2 deklariert.Anschlie ßend werden beide Objekte Tank und Nozzle er zeugt,der Tank wird mit Attributen ver sehen.

Zwischenfazit Der Aufwand für die grundlegenden Schritte beim Programmie-ren von AutomationML/CAEX ist tatsächlich gering. Dies istnicht auf die beschriebenen Basisanforderungen beschränkt,auch komplexere Funktionen wie das Löschen von Objekten,das Ändern von Attributen, das Referenzieren von Objekten,Funktionen zum Kopieren und Klonen ganzer Teilhierarchienzwischen verschiedenen CAEX-Dokumenten gelingen ähnlicheinfach.

Erweiterte Techniken

1. Umgang mit semantischer Viel-faltAutomationML führte 2011 ein neues Konzept zur Beherrschungsemantischer Vielfalt ein. Dies ermöglicht die Realisierung vonDatenaustausch zwischen Planungswerkzeugen, ohne dasshierzu ein standardisiertes Datenmodell existieren muss. DasBild 7: CAEX-InternalElements und Attribute

Bild 3: Beispielcode zum Speichern eines CAEX-Dokumentes

Bild 6: Beispielcode zum Erzeugen der Hierarchien

Bild 4: Beispielcode zum Laden eines CAEX-Dokumentes

Bild 8: Beispielcode zum Erzeugen von CAEX-Objekten

Bild 9: Beispielcode zum Etikettieren von CAEX-Dateien

Bild 5: Hierarchien im AutomationML-Editor

Bild 2: Beispielcode zum Erzeugen eines leeren CAEX-Dokumentes

11

3. Lesen von CAEX-EtikettenBild 10 illustriert, wie das vorhandene Etikett einer CAEX-Dateiausgewertet werden kann. Die Intellisense-Funktion von VisualStudio hilft, die relevanten Properties zu sichten.

Fehlersuche in CAEX-DateienAutomationML-Dokumente sollen fehlerfrei sein. Fehler sindstets auf das Quellwerkzeug oder den Exporter zurückzuführen.Beim Entwickeln von Exportern treten typische Fehler auf: ID’swerden doppelt vergeben, referenzierte Klassen oder externeDateien existieren nicht. Die AutomationML-Engine bietet Funk-tionen, um solche Fehler leicht zu finden. Bild 11 zeigt, wiediese Fehlerprüfroutinen aufgerufen werden können. Die Fehlerwerden in Listen gespeichert, deren Einträge jeweils eine men-schenlesbare Fehlerbeschreibung sowie einen Pointer auf dasfehlerhafte Objekt enthalten.

Weitere FunktionenBasierend auf der praktischen Nutzung der AutomationML-En-gine wurde diese in 2011 um eine Vielzahl weiterer Funktionenerweitert. Dazu gehören Funktionen zum Importieren von CAEX-Daten aus anderen CAEX-Dateien, Funktionen für das Klonen,Ersetzen und Kopieren von CAEX-Daten, Fest legen von Meta-Daten sowie erweiterte Funktionen zum Splitten und Zusammen-führen von CAEX-Dateien.

ZusammenfassungDie AutomationML-Engine vereinfacht die Arbeit mit CAEX-Da-teien erheblich und wird beispielsweise vom AutomationML-Edi-tor bereits verwendet [7]. Der realistische Aufwand zumProgrammieren eines AutomationML-Exporters wird auf wenigeTage reduziert, der Hauptaufwand liegt in der Kommunikationmit dem Engineeringwerkzeug. Das Programmieren von Impor-

tern ist aufwändiger und erfordert das Mappen der empfange-nen Daten mit dem Datenmodell des Zielwerkzeuges. Diese Funk-tionalität liegt jedoch außerhalb der AutomationML-Programmierung und wird in einem weiteren Beitrag dieser AutomationML-Serie beleuchtet.

Literaturhinweise[1] IEC 62714-1 CD norm draft AutomationML Architecture,www.iec.ch, 2011. [2] IEC 62424:2008, Representation of process control enginee-ring – Requests in P&I diagrams and data exchange betweenP&ID tools and PCE-CAE tools[3] www.automationml.org [4] W3C: Extensible Markup Language (XML), URL:http://www.w3.org/XML/ (last access: 19.04.2010).[5] Drath R., Barth M: Beherrschung von Semantikvielfalt mit Au-tomationML, Vorgehensmodell für die semantische Standardisie-rung heterogener Datenmodelle – wie der Umgang mitunterschiedlichen Datenmodellen beim Datenaustausch im he-terogenen Werkzeugumfeld gelingt. In atp 12/2012. Olden-bourgverlag 2012.[6] Drath R., Barth M., Fay A.: Offenheitsmetrik für Engineering-Werkzeuge. In: atp 09/2012, S 46-55. Olden bourgverlag, 2012. [7] www.youtube.com/AutomationML �

www.automationml.org

Autor: Dr.-Ing. RainerDrath, Senior PrincipalScientist, ABB AG ForschungszentrumDeutschland

Bild 10: Beispielcode zum Lesen von Etiketten

Bild 11: Beispielcode zum Validieren von CAEX-Dateien

Konzept basiert auf der Idee, proprietäre Daten-Teilmodelle inihrer ursprünglichen Semantik in CAEX abzubilden. Dazu wirddie AutomationML-Datei mit einem Etikett versehen, das Aus-kunft über den Urspung der Datei gibt. Importer können dieseInformationen nutzen, um quelltoolspezifische Sub-Routinenzum Import aufzurufen. Das Konzept wird in [5] im Detail be-schrieben, im Folgenden soll die Programmierung erläutert wer-den. Einzige Voraussetzung für die Anwendung dieses Konzeptesist die Offenheit der adressierten Planungswerkzeuge [6].

2. Etikettierung von CAEX-DateienBild 9 zeigt, wie das Etikettieren erfolgt: Zunächst wird exem-plarisch ein Objekt m vom Typ Metainformation erzeugt.Dann werden die von AutomationML definierten Informatio-nen festgelegt und abschließend wird das Objekt m im CAEX-Dokument eingebunden.

12

Wenn Systeme über AutomationML gekoppelt wer-den, muss jedes System einen entsprechenden Ex-porter bzw. Importer besitzen, der dessen

spezifische Datenobjekte auf die standardisierten Automati-onML-Objekte abbildet. Dieser Zuordnungs- und Transforma-tionsprozess wird von AutomationML durch Rollenbibliothekenunterstützt. Rollen sind semantische Definitionen für Automa-tionML-Objekte und sorgen beim Datenaustausch dafür, dassdie Objektdefinition von einem importierenden System korrektverarbeitet wird. Hierzu definiert AutomationML Bibliothekenmit abstrakten Rollen. Spezifische System-Datenobjekte kön-nen aber oftmals auf der angebotenen Abstraktionsebenenicht ausreichend genau beschrieben werden. Aus diesemGrund werden für bestimmte Anwendungsdomänen detaillier-tere Rollenbibliotheken entwickelt. Eine eindeutige Zuordnungzu einem Datenobjekt des Zielsystems kann dadurch verbes-sert, aber nicht garantiert werden. In einigen Fällen benötigtder Importer daher eine Zuordnungsstrategie und eine Abbil-dungsvorschrift für die semantisch eindeutige Transformationdes Automa tion ML-Objektes in das Zielsystem, um eine ver-lustfreie Datenübertragung zu gewährleisten.

Bild 1: Phasen der Zuordnung

Ein wichtiges Problem beim Datenaustausch zwischen zwei Entwurfswerkzeugen ist die korrekte Übertragungder Datenstrukturen des sendenden Werkzeuges auf die Datenstrukturen des empfangenden Werkzeuges. Esmuss möglich sein, für jedes zu übertragende Datenobjekt ein passendes Datenobjekt im empfangenden Tool zufinden und zu nutzen. In diesem Beitrag wird ein Implementierungskonzept für den Datenaustausch mit demstandardisierten Format AutomationML vorgestellt. Das Konzept definiert verschiedene Zuordnungsstrategien,mit deren Hilfe AutomationML-Objekte auf spezifische Datenobjekte der gekoppelten Systeme abgebildet werdenkönnen, die damit helfen, das obige Problem zu lösen.

Serie AutomationML Teil 4: Implementierung von Zuordnungsstrategien für den Datenaustausch mit AutomationML

AutomationML − Datenaustausch

13

Externalisierung der Systemdatenmodelle

Wie wird ein Datenobjekt eines spezifischen Systems zu einemAutoma tion ML-Objekt und umgekehrt? Eine Möglichkeit be-steht in der Externalisierung der systemeigenen Klassen inForm einer AutomationML-System Unit-Klassenbibliothek. Vondiesen systemeigenen Klassen leiten sich in der Regel die ex-portierbaren Datenobjekte, welche ausgetauscht werden sol-len, ab. Ein Export- bzw. Importprozess müsste mit einerentsprechenden Externalisierung starten (Phase 1, vgl. Bild 1).Das Ergebnis ist eine systemspezifische AutomationML-Datei,die den austauschrelevanten Ausschnitt des Systemdatenmo-dells abbildet. Anschließend kann diese systembeschreibendeAutomationML-Datei zukünftig bei jedem Datenimport undDatenexport (Phase 2) wieder Verwendung finden.

Datentransformation und Datenaustausch

Die Transformation eines System-Datenobjektes in ein Auto-mationML-Objekt beim Import und Export erfolgt nach un-terschiedlichen Strategien, wobei die Zuordnungsstrategieneines Importers in der Regel komplexer sind als die eines Ex-porters, da der Importer gegebenfalls auf Objekte, für die eskeine eins zu eins Entsprechungen gibt, interpretieren und aufdas Systemobjektmodell abbilden muss. Sowohl Exporter alsauch Importer nutzen das für ihr System externalisierte Sys-temdatenmodell und stellen Zuordnungen zwischen den Da-tenobjekten und den SystemUnit-Klassen her. Der Exporterrealisiert dies für die zu exportierenden Datenobjekte und er-zeugt anhand der zugeordneten SystemUnit-Klasse ein Auto-mationML-Objekt (ein CAEX − ‘InternalElement’). Beim

Importer verhalten sich die Dinge genau umgekehrt. Er stellteine Zuordnung zwischen den vom Quellsystem geliefertenAutomationML-Objekten und den eigenen SystemUnit-Klas-sen her und erzeugt anhand der zugeordneten SystemUnit-Klasse ein Datenobjekt im Zielsystem.

Zuordnungsstrategien − Zuordnungen anhand von Rollen

Rollen werden dazu verwendet, die Semantik von Automati-onML-Objekten zu definieren. Im konkreten Fall muss ein Ex-porter jedem erzeugten AutomationML-Objekt mindestenseine Rolle zuordnen. Die SystemUnit-Klassen des Quellsys-tems, die vom Exporter für die Generierung der Automati-onML-Objekte verwendet werden, definieren die Menge derzulässigen Rollen für das jeweils generierte AutomationML-Objekt. Wenn ein Importer ein AutomationML-Objekt voneinem Quellsystem erhält, interpretiert er die zugeordnetenRollen und versucht seinerseits nun unter den SystemUnit-Klassen des Zielsystems diejenigen zu finden, die diese Rollenunterstützen (Bild 2). Er kann diesen Schritt nur ausführen,wenn sowohl die SystemUnit-Klassen des Quellsystems alsauch die SystemUnit-Klassen des Zielsystems dieselben Rol-lenbibliotheken benutzen bzw. Rollenbibliotheken mit dem-selben ‘Stammbaum’ (Rollen können inVererbungsbeziehungen stehen). Findet der Importer mehr alseine passende SystemUnit-Klasse, benötigt er eine Strategie,um den Konflikt zu lösen. Eine Möglichkeit besteht darin,dass der Exporter bereits im Vorfeld bei der Zuordnung einerRolle zu einem AutomationML-Objekt zusätzliche Bedingun-gen definiert. In diesen können bestimmte Werte oder Wer-tebereiche für spezielle Objekteigenschaften gefordert sein,die der Importer dann zur Interpretation nutzen kann. Wenn

Bild 2: Zuordnung über Rollen

14

die Interpretation auch damit noch nicht möglich ist, müssenzusätzliche Regeln und Strategien definiert werden.

Zuordnung mithilfe von Klassen-Relationen

Bei der Zuordnung von Daten-Objekten des Quell- und Ziel-systems mithilfe von Klassen-Relationen ist der erste Schrittwiederum die Externalisierung der AutomationML-System-Unit-Klassenbibliotheken aus beiden Systemen (1), vergleicheBild 3. Im Anschluss erfolgt der Export der Daten aus demQuellsystem in die Daten der AutomationML-Datei (2). Diesekann durch den Importer des Zielsystems eingelesen werden.Dabei sind dem Importer sowohl beide System-Unit-Klassen-bibliotheken, als auch die Vorschriften, wie die einzelnen Klas-

sen aufeinander zu mappen sind, bekannt. So kann zuerst einKlassen-Mapping erfolgen (3) und in einem weiteren Schrittder Import der AutomationML-Daten inklusive der semantischeindeutigen Zuordnung auf das eigene Objektmodell (4). EineErweiterung des Klassen-Mappings stellte die Zuordnung überRegeln dar. Dabei werden nicht nur die Klassen einander zu-geordnet, sondern zusätzlich Regeln für z.B. Attributwert-transformationen erzeugt. Solche Regeln können in einerTransformationssprache wie beispielsweise XSLT formuliertwerden.

Beispiel und Mappingwerkzeug

Ein typisches Anwendungsbeispiel für die Notwendigkeiteines Mappings ist die unterschiedliche Struktur in der Klas-

sendefinition auf Basis unterschiedlicher Rollen in den Syste-men, die Daten austauschen. In Bild 4 ist dies exemplarischdargestellt. Hier baut sich im System A die Klassenstrukturentsprechend der konkreten Automatisierungsfunktionalitätbzw. der Geräteklassifizierung, die in den Rollen abgebildetist, auf. System B hingegen unterscheidet zwischen passivenund aktiven Objekten. Entsprechend des oben erläutertenMappings von Rollen, müssen für einen Datenaustausch dieRollen ‘Robot’, ‘Tool’ und ‘Fence’ auf die in System B verwen-deten Klassen abgebildet werden. Für die im Beispiel darge-stellte Exportdatei ‘ExportA.aml’ heißt dies, dass die sechsexportierten Objekte auf fünf ‘ActiveObjects’ und ein ‘Passi-veObject’ abgebildet werden. Zur Definition und Validierungsolcher Zuordnungsstrategien wurde bei inpro ein prototypi-sches Werkzeug ‘AutomationML Mapper’ entwickelt. Mit die-

Bild 3: Zuordnung über Klassen

Bild 4: Beispiel Zuordnung über Rollen

15

sem ist es möglich, unterschiedliche Objektmodelle via Auto-mationML miteinander zu verknüpfen und so eine semantischeindeutige Schnittstelle zwischen unterschiedlichen Werkzeu-gen zu erstellen. Bild 5 zeigt einen Ausschnitt der Werkzeug-oberfläche. In diesem können die benötigten Zuordnungenbequem definiert und getestet werden.

Fazit

Der Austausch von Daten über eine syntaktisch eindeutigeSchnittstelle ist ein erster bedeutender Schritt zur vollständi-gen Interoperabilität zwischen am Planungsprozess beteilig-ten Werkzeugen. Um das volle Potenzial dieser Schnittstellen

auszuschöpfen, ist ein weiter Schritt notwendig, der die his-torisch gewachsenen Objektmodelle auch semantisch ver-knüpft. Um diese Herausforderung zu lösen, gab es in derVergangenheit eine Reihe von Ansätzen, welche ein ‘alles be-schreibendes Weltmodell’ nutzten, was sich in der Praxis oftals nicht tauglich erwiesen hat. In diesem Beitrag wurde eineMöglichkeit vorgestellt, die dieses Problem löst, indem es Vor-teile des Austauschformates AutomationML mit einfach zudefinierenden Zuordnungsstrategien kombiniert und somiteinen sowohl syntaktisch als auch semantisch eindeutigen Da-tenaustausch ermöglicht. �

www.automationml.org

Bild 5: Oberfläche 'AutomationML Mapper' Autor: Dr.-Ing. LorenzHundt, ProjektingenieurProduktionssysteme und In-formationsprozesse, inproGmbH

Autor: Josef Prinz, Senior-Experte Digitale Fabrik,inpro Innovationsgesell-schaft für fortgeschritteneProduktionssysteme mbH

16

Als Systemlieferant für Antriebs- und Automatisierungs-lösungen hat sich Lenze zum Ziel gesetzt, das Enginee-ring einer Maschine deutlich zu vereinfachen, um die

Kosten und den Zeitaufwand zu reduzieren. Es gilt, einen opti-malen Support über die gesamte Wertschöpfungskette herzu-stellen. Hierfür ist einerseits ein breites, auf die Bedürfnisse desMaschinenbaus abgestimmtes Produktportfolio erforderlich, dasauch unterschiedliche Automatisierungstopologien unterstützt.Andererseits ist ein methodisches Vorgehen im Entwicklungs-prozess nötig, das neben den richtigen Werkzeugen auch Stan-dards beinhaltet. Diese Standards ermöglichen es, Know-howzur Verfügung zu stellen, die Komplexität zu verringern und In-

Bei der Entwicklung von Maschinen ist eine interdiszip-linäre Zusammenarbeit gefordert: sowohl zwischen denKonstrukteuren, Elektronikern und Software-Entwick-lern des Maschinen- oder Anlagenbauers als auch zwi-schen dem Auftraggeber und den Applikations-ingenieuren der Komponentenlieferanten. Bisher muss-ten viele Informationen manuell zwischen den einzel-nen Domänen ausgetauscht werden. Dabei bestehtimmer das Risiko, dass Wissen und Daten verlorengehen, zudem hat dieses Vorgehen einen enormen Ein-fluss auf die Entwicklungszeiten von Maschinen undAnlagen. Für ein durchgängiges Engineering von derPlanungsphase über die Programmierung bis zur Be-triebsphase kann AutomationML als Verbindung zwi-schen individuellen, anwender- und aufgaben-orientierten SW-Werkzeugen für mehr Transparenz undEffizienz beim Austausch von Daten sorgen.

Serie AutomationML Teil 5: Engineering-Effizienz für Antriebs- undAutomatisierungslösungen

AutomationML − Effizienz für denEngineeringprozess

Bild 1: Zwölf typische Maschinenaufgaben

17

formationen wiederzuverwenden. Diesem Anforderungsprofilwird mit der Modularisierung von Maschinen und der damit ver-bundenen Bildung von mechatronischen Einheiten begegnet.Bild 1 zeigt zwölf typische Maschinenaufgaben, für die Stan-dards definiert werden können, bestehend aus geeigneter Au-tomatisierungstopologie, erforderlichen Antriebskomponentenund vor allem aus vorgedachter Applikations-Software. Zusam-

mengefasst ergibt dies eine Maschinenlösung, an der sich derMaschinenbauer und der Systemlieferant innerhalb des Entste-hungsprozesses orientieren können. Bei Betrachtung des Pro-duktentstehungsprozesses im Maschinenbau können folgendefünf Phasen herausgebildet werden (Bild 2, oberer Teil):1. Idee: Formulierung der Idee und Erstellung eines Grobkon-zepts.2. Konzepterstellung: Definition der Maschinenmodule undderen Funktion sowie Festlegung der grundlegenden Automa-tisierungsarchitektur.3. Entwicklung: Ausarbeitung der Lösung, inklusive der Ausle-gung des Antriebsstrangs und der Auswahl der Antriebs- undSteuerungskomponenten. Auch die Softwaremodule werdenvorbereitet.4. Produktion: Bau der Maschine. Parallele bzw. zeitversetzteFertigstellung der Maschinen-Software.5. Betrieb: Inbetriebnahme und Betrieb der Maschine beim End-kunden. Die Maschinenverfügbarkeit muss gesichert werden.Wichtige Aufgaben sind hierbei die Zustandsüberwachung oderauch die (vorbeugende) Wartung. Effizienz durch Kette von Engineering-Werkzeugen Die Firma Lenze kann die Kunden über alle fünf Phasen des Ent-wicklungsprozesses begleiten. Wichtig dabei sind immer wiederneue und intelligente Engineering-Werkzeuge, die bei der Ent-wicklung unterstützen. Ein entscheidender Ansatzpunkt zurVerbesserung der Engineering-Produktivität ist die Beseitigungder noch in weiten Teilen existierenden Brüche bzw. Lücken inder gesamten Werkzeugkette. Eine Werkzeugkette soll denzuvor beschriebenen Lebenszyklus komplett abdecken. Aller-dings ist es nicht zielführend, für den gesamten Prozess nur eineinziges Werkzeug vorzusehen. Wesentlich effektiver und siche-

Bild 2: Fünf Phasen bei der Erstellung einer Maschinenlösung mit er-forderlicher Tool-Unterstützung.

Bild 3: Engineering-Werkzeuge für die Erstellung von Antriebs- undAutomatisierungslösungen

Bild 4: Beispielhafte AML-Struktur für einen Rollenförderer

rer ist es, wenn für die verschiedenen Projektierungsphasenmaßgeschneiderte Tools zur Verfügung stehen. Tools, die aufdie Aufgabenstellung, das Wissen und die Arbeitsweise des je-weiligen Projektbeteiligten (Konstrukteur, Steuerungsprogram-mierer, Visualisierungsprogrammierer, Wartungstechniker)zugeschnitten sind und ihn damit optimal und effizient in seinerArbeit unterstützen. Ist der Engineering-Prozess auf mehrereWerkzeuge aufgeteilt, ist eine durchgängige Datenhaltung si-

18

cherzustellen. AutomationML bietet hierzu die Möglichkeit, dieÜbergänge von einem Werkzeug zum nächsten nahtlos zu ge-stalten. Die Mehrfacheingabe von Daten entfällt und die Zu-sammenarbeit zwischen den Konstrukteuren (Mechanik undElektronik) und den Softwareentwicklern vereinfacht sich. Ge-rade hier ist der Informationsaustausch besonders wichtig, dadiese Domänen in der Regel nicht nur organisatorisch getrenntsind, sondern auch eine individuelle Sichtweise auf das Projekthaben. Bild 3 zeigt in einer Übersicht, wie eine solche durch-gängige Werkzeug-Landschaft aussehen kann und welche Ziel-gruppen diese Werkzeuge einsetzen.

Anwendungsbeispiel DSD Ein beispielhaftes Element einer solchen Werkzeuglandschaft bil-det das Antriebsauslegungswerkzeug Drive Solution Designer

(DSD). Durch ihn werden dem Konstrukteur die physikalischenZusammenhänge und das Lösungswissen für die vordefiniertenMaschinenmodule zur Verfügung gestellt. Anhand dieser Mo-dule kann der Anwender deren Bewegung beschreiben und an-schließend den kompletten Antriebsstrang auslegen, dierichtigen Antriebskomponenten auswählen und die Lösung op-timieren. Dabei ist es möglich, zahlreiche physikalische Parameterzu ermitteln bzw. deren Einhaltung zu prüfen. Dazu gehörenu.a. die Kombinierbarkeit der einzelnen Produkte, deren thermi-sche und mechanische Auslastung, die Lebensdauer und derEnergieverbrauch der Antriebskomponenten. Der DSD wurdeum eine AutomationML-Schnittstelle ergänzt, das heißt, er kannstrukturierte Daten zu einer Anwendung, z.B. einem Rollenför-derer, importieren. Es handelt sich dabei sowohl um Prozessda-ten, wie Durchmesser, Trägheitsmomente, Massen, Reibung, etc.als auch um Bewegungsinformationen, Netz- und Umgebungs-bedingungen. Das sind Informationen, die in der Planungsphasebeispielsweise in CAD-Werkzeugen bereits zuvor eingegebenbzw. ermittelt wurden. Nach dem Import werden diese Werteim DSD direkt verwendet, sodass der Anwender weniger Zeit beider Ermittlung und Eingabe der Daten benötigt und direkt dieAuslegung durchführen kann. Das Ergebnis der Auslegung (be-nötigte Antriebsprodukte, Einstellungen der Umrichter, Energie-bedarf, etc.) kann er dann durch die Export-Funktion in dasAML-Format zurückschreiben und somit seinen Beitrag am ge-samten Engineeringprozess leisten. Ist die Auslegung abge-schlossen, liegen die erforderlichen konkretenAntriebskomponenten vor und es kann mit der eigentlichen Pro-jektierung, also der Ausarbeitung der Bewegungs- und Ablauf-programme sowie der Visualisierung, fortgefahren werden. Hierkommt unter anderem der PLC Designer zum Einsatz, mit demdie Programmerstellung und Inbetriebnahme nach IEC61131-3erfolgt. Er beinhaltet sechs Editoren, Debugger und Monitoring-

Bild 5: Antriebsauslegung mit DSD

Autor: Olaf Götz, Produkt-manager Engineering Tools,Lenze Hameln

funktionen und basiert auf Codesys3. Der Clou: Mit Hilfe vonStandard-Software-Bausteinen für die unterschiedlichen Maschi-nenmodule kann die Produktivität der Programmierer gesteigertwerden. Eine zukünftige AutomationML- Schnittstelle bietet dieMöglichkeit, die bereits zuvor mit dem DSD erstellten Informa-tionen für das Maschinenmodul im PLC Designer noch schnellerund vollständiger zur Verfügung zu stellen. Fazit Mit AutomationML lässt sich Durchgängigkeit und Effizienz beigleichzeitiger Modularisierung für den Entwicklungsprozesseiner Maschine oder Anlage erreichen. Mechanik-, Elektronik-und Software-Informationen können für eine Antriebs- undAutomatisierungslösung gebündelt werden und stehen der in-dividuellen Toolkette des Maschinenbauers und des Systemlie-feranten zur Verfügung. Dies verbessert neben der Effizienzund Qualität des Engineerings auch die Wissenssicherung imMaschinen- und Anlagenbau. �

www.automationml.org

19

Der Prozess der Fabrik- und Anlagenplanung ist kom-plex und besteht aus vielen, meist sequenziellen Pla-nungsschritten mit vielen verschiedenen Beteiligten,

z.B. Fabrik- und Gebäudeplaner, Prozess- und Anlagenplaner.Diese Disziplinen arbeiten heute mit vielen, oft nicht integrier-ten IT-Werkzeugen, deren Interoperabilität verbessert werdenmuss. Die Ingenieure und Planer arbeiten größtenteils räum-lich und technisch voneinander getrennt und setzen konven-tionelle Medien ein, z.B. Pläne auf Papier. Obwohl dieDisziplinen das gleiche Planungsobjekt, das Produktionssys-tem, bearbeiten, werden zwischen den Tools Informationennur teilweise oder gar nicht ausgetauscht. Die Personen stim-men sich meist − falls und wenn nötig − mündlich ab. DieserBruch macht den interdisziplinären Abstimmungsprozess in-effizient, aufwändig und fehleranfällig.

Ziele

Um Kommunikation und Planung an einem gemeinsamen Me-dium zu verbessern, hat das Fraunhofer IOSB den Digitalen En-gineering-Tisch (DigET) [1] entwickelt (Bild 2). Am DigETkönnen die Planer mithilfe einer interaktiven Umgebung Pla-nungsszenarien für alle Disziplinen konsistent beleuchten undzudem intuitiv mit den IT-Werkzeugen interagieren (siehe [2]).Die Interaktion mit dem DigET über Gesten ist dabei so einfach,dass sich die Planer voll auf den Planungsgegenstand konzen-

Bild 1: Logo des Projekts Digitaler Engineering-Tisch (DigET)

Der Digitale Engineering-Tisch (Bild 1) bietet Planern von Produktionsanlagen die Möglichkeit, Planungsszenarienfür alle Disziplinen konsistent zu beleuchten und zudem intuitiv mit den IT-Werkzeugen zu inter-agieren (beispielsweise per Gesten). Er kombiniert hierfür die Standards AutomationML und OPC-UA mit Assis-tenzmechanismen und einer interaktiven Umgebung.

Serie AutomationML Teil 6: Digitaler Engineering-Tisch (DigET) kombiniert OPC-UA und AutomationML

AutomationML: Umgebung fürdas Multi-User-Engineering

20

trieren können und die Interaktion mit den IT-Werkzeugen inden Hintergrund tritt. Er kombiniert hierfür das durchgängigeund standardisierte Datenformat AutomationML mit Assistenz-mechanismen und einer interaktiven Umgebung. So wird diedomänenübergreifende Zusammenarbeit gefördert und derelektronische Informationsaustausch- und Änderungsprozesswird mithilfe der verbesserten menschlichen Kollaboration un-terstützt. Verbesserungen beim Einsatz des DigET sind:

Konsistente Daten für alle an einer Fabrik- und Anlagenplanung be-•teiligten Ingenieure,Verbesserter Datenaustausch zwischen verschiedenen IT-Tools bei An-•lagenherstellern und -betreibern,Verbesserte Zusammenarbeit der einzelnen Disziplinen / Gewerke,•Benutzer-Assistenz im Engineering,•Erleichterung von Produktionsumstellungen und -inbetriebnahmen,•Durchgängige computerunterstützte Planung von Fertigungszellen•oder -linien undLückenschluss zwischen individuellen domänenspezifischen Planungs-•schritten auf Datenebene und der interpersonellen Kommunikation.

Angewendet werden kann der DigET beispielsweise zur Team-basierten Anlagen-Umplanung. Die Umplanung ist ein beson-ders herausforderndes Szenario, weil hier neue Anlagen in

bestehende Linien oder Hallen eingefügt werden müssen. BeiVeränderungen in den Planungsständen aufgrund von Umpla-nungen zeigt sich die Stärke der neuartigen Umgebung. DerDigET dient dabei als Arbeitsplatz zur Diskussion von Änderun-gen und unterstützt bei der Lösung der dabeientstehenden/auftretenden Konflikte. Er ist aber nicht der Ar-beitsplatz der Disziplinen zur Planung, sondern stellt einen ge-meinsamen Abstimmungsraum dar. Jede Disziplin arbeitet dabeiweiterhin mit dem Tool ihrer Wahl, der DigET unterstützt beider effektiven Koordination und Fusionierung aller Änderungenauf dem Datenbestand.

Hardware

Der DigET (Bild 3) ist ein Multi-Display-System mit verteilten Dis-plays (horizontal und vertikal angeordnet) sowie verschiedenenmobilen Endgeräten, die in die Umgebung eingebunden wer-den. Die komplette Umgebung kann mithilfe Display-übergrei-fender Handgesten-Interaktion im 3D-Arbeitsraum bedientwerden. Dabei werden Tablet-PCs und SmartPhones als mobileArbeitsplätze eingesetzt und durch persönliche Identifikations-möglichkeiten über Marken-Tracking mit dem Tisch gekoppelt.

Software

Das Multi-User-System DigET setzt auf Standards. Als integriertesund durchgängiges Standard-Datenaustauschformat zur Anla-genbeschreibung wird AutomationML eingesetzt, wobei die inder Umgebung verwendeten Tools lediglich eine AutomationML-Schnittstelle bereitstellen müssen. AutomationML befindet sichaktuell auf dem Weg der IEC-Normierung und wird bereits vonToolherstellern als Austauschformat unterstützt. Als Standard zurKommunikation und dem Datenaustausch zwischen allen Kom-

ponenten wird OPC-UA verwendet. An diese Kommunikationkönnen sich potenzielle Nutzer mithilfe eines OPC-UA-Clientseinfach 'andocken'. Dabei wird AutomationML in den Kommu-nikationsstandard OPC-UA als Informationsmodell integriert.Dies schafft die notwendige Transparenz. Der DigET setzt keineeinheitliche Software voraus, sondern ermöglicht es den Nut-zern, die für sie beste Software einzusetzen und diese mit demTisch zu koppeln. Jeder Nutzer behält seinen eigenen Datenbe-stand und seine gewerkespezifische Sicht. So können bspw.Elektronik- und Mechanikplanung sich über die gemeinsameUmgebung verständigen, behalten aber weiterhin ihre proprie-tären Datenbestände. Durch das gemeinsame Modell im FormatAutomationML können die Nutzer Änderungsvorschläge an denTisch melden, die dann verarbeitet werden. Die Änderungspro-pagation erfolgt von der dafür entwickelten Middleware (siehe[3]) in Form eines OPC-UA-Servers mit speziellen Methoden. Än-derungen werden also an die entsprechenden Beteiligten wei-tergeleitet. Die Bedienung der Tools durch die Gesten-Interaktion

Bild 2: DigET – interaktive Arbeitsumgebung für dasMulti-User-Engineering

Bild 3: Hardware-Komponenten der DigET-Umgebung und deren Anordnung

21

(Bild 4) erfolgt am DigET über ein transparentes Overlay, das zurKommunikation mit der entsprechenden Standard-Softwaredient. Daher sind für die Gesten-Bedienung keine zusätzlichenSchnittstellen in den Tools nötig.

Interaktion/Assistenz

In unserem täglichen Leben werden wir durch entsprechendetechnische Systeme und intelligente Umgebungen bereits unter-stützt. Warum also nicht auch bei komplexen Prozessen wie derProduktionsplanung? Der DigET unterstützt als IT-System die Ko-

operation der Beteiligten und führt und begleitet die zugehörigenEntscheidungsprozesse. Für die direkte Multi-Display-Interaktionwurden verschiedene Handgesten definiert, die die Multi-User-Interaktion im Team unterstützen. Änderungen werden als Vor-schlag einer Disziplin eingebracht, andere Disziplinen könnenKonflikt-behafteten Veränderungen zustimmen oder diese ab-lehnen. Mithilfe ergebnisorientierter Konfliktlösungsunterstüt-zung in Form entsprechender Assistenzfunktionalitäten in derUmgebung werden konfliktfreie Änderungen übernommen,Konflikte aufgelöst und Abstimmungsprozesse begleitet. Ände-rungsprozesse können so überwacht und dokumentiert werden.So können gemeinsame, koinzidente Modelländerungen vorge-nommen werden. Darüber hinaus wurden verschiedene Assis-tenzmechanismen zur Verbesserung der interpersonellen undinterdisziplinären Zusammenarbeit in die Umgebung integriert.

Vorteile

Die durchgängige Kommunikation und Datenhaltung über Nut-zer und Tools hinweg, unter Verwendung und Kombination derStandards AutomationML und OPC-UA, ermöglicht die Adap-tion und Integration weiterer Tools und nutzt die Vorteile dereinzelnen Standards optimal aus. Durch den DigET könnendaher verschiedene Vorteile geltend gemacht werden: Rei-bungsverluste, Missverständnisse und der Abstimmungsauf-wand zwischen den Beteiligten werden reduziert. Ebenso wirddie Eigendynamik in Gruppen implizit genutzt und durch dieSysteme entsprechend unterstützt. Die enge Zusammenarbeitund verbesserten Kommunikationsmöglichkeiten erhöhen dasgegenseitige Verständnis für die anderen Disziplinen, verbessernden Systemüberblick für die einzelnen Beteiligten und die Arbeitim Team steigert die Motivation. Durch mögliche Dokumenta-tions- und Abstimmungsmechanismen sowie die Archivierbar-

keit werden Ergebnisse besser nachvollziehbar und der Entwick-lungszyklus transparenter. Darüber hinaus wird im besten Falldie Planungsqualität verbessert. �

www.automationml.org

[1] Fraunhofer IOSB: DigET, www.dig-et.de, Stand 15.05.2012.[2] Miriam Schleipen, Thomas Bader: A concept for interactive assistant systems formulti-user engineering based on AutomationML. Proceedings of CAPE Conference2010, Edinburgh, 13.-14.4.2010, Paper 014.[3] Miriam Schleipen, Manfred Schenk: Intelligent environment for mechatronic, cross-discipline plant engineering. IEEE conference on Emerging Technologies and Factory Au-tomation ETFA 2011, September 5-9, 2011, Toulouse, France, 2011.

Literatur

Bild 4: Interaktion der Nutzer mit dem DigET, z.B. über Smartphone Autorin: Dr.-Ing. MiriamSchleipen, GruppenleiterinLeitsysteme und Anlagen-modellierung, FraunhoferIOSB

Autor: Manfred Schenk,Wissenschaftlicher Mitar-beiter, Fraunhofer IOSB

Autor: Sebastian Maier,Wissenschaftlicher Mitar-beiter, Fraunhofer IOSB

Autorin: Dr.-Ing. ElisabethPeinsipp-Byma, Abteilungs-leiterin Interaktive Analyseund Diagnose, FraunhoferIOSB

Autor: Jan Hendrik Ham-mer, Wissenschaftlicher Mit-arbeiter, Karlsruher Institutfür Technologie (KIT)

22

Auf den ersten Blick erscheint ein Kommunikationssys-tem als ein einfaches Netzwerk physikalischer Geräte.Bei näherer Betrachtung wird jedoch deutlich, dass Ge-

räte auch dann miteinander kommunizieren können, wenn siephysikalisch nicht direkt miteinander verbunden sind. Darüberhinaus kann ein Kabel oder Gerät durchaus mehrere Protokolleverarbeiten. Diese Überlegungen führen zur Unterscheidungzwischen physischen und logischen Geräten und Verbindungen(Bild 1). Eine logische Topologie betrachtet die Steuerungsapp-likation aus Sicht der zwischen Applikationsteilen ausgetausch-

Bild 1: Kommunikationsnetzwerk mit logischen und physischen Geräten und Verbindungen

Bild: A

utom

ationM

L e.V. c/o IAF

Automatisierung erfordert die Kommunikation zwi-schen Geräten. Die Planung solcher Kommunikations-systeme erfolgt meist in mehreren Phasen, in denenPlanungsergebnisse aus früher gelegenen Phasen im-portiert und neue Daten für den Kommunikationssys-tementwurf erzeugt werden. Die nahtlose Weitergabederartiger Planungsstände von Werkzeug zu Werkzeugist jedoch bis heute problematisch, da kein passendesDatenaustauschformat für eine konsistente und verlust-freie Informationsweitergabe zwischen Entwurfswerk-zeugen existiert. Dieser Beitrag schlägt eine im Rahmendes AutomationML e.V. erarbeitete Methodik vor, mitder Kommunikationssysteme mit AutomationML mo-delliert und ausgetauscht werden können.

Serie AutomationML Teil 7: Modellierung und Austausch von Entwurfsdaten für Kommunikationssysteme

AutomationML − Kommunikation

23

ten Variablen und ignoriert die tatsächlichen physikalischen Ver-bindungen. Hierbei können die Anforderungen an den Daten-austausch hinsichtlich der Kommunikationseigenschaften sowieEigenschaften der Steuerungsapplikationsteile wie Abarbei-tungszeiten oder Eigenschaften der logischen Schnittstellen wieeine Portnummer modelliert werden. Die physikalische Topolo-gie bildet die realen Kommunikationsgeräte und die zwischenihnen aufgebauten Kommunikationsverbindungen mit Daten-paketaustausch ab. Hier sind neben den eigentlichen kommu-nizierenden Steuerungsgeräten auch aktive und passiveInfrastrukturkomponenten, ihre Eigenschaften (wie Adressen,Schutzklassen oder Durchgangsraten) und die Anforderungenan die Kommunikation (wie Laufzeiten und Auslastungen) vonBedeutung. Beide Topologien stehen zueinander in Beziehung:die physikalische Topologie implementiert eine oder mehrere lo-gische. Dieses Konzept ist flexibel auch für komplexe Systemeverwendbar.

Technologieunabhängige Basis-Bibliotheken

Zur Modellierung solcher Strukturen mit AutomationML wurdenim AutomationML e.V. technologieunabhängige Bibliothekenerstellt, die alle notwendigen Basisklassen für eine Beschreibungvon Kommunikationssystemen enthalten. Die entstandenen Bi-bliotheken sind in Bild 2 dargestellt.

Die <CommunicationRoleClassLib> beinhaltet acht Basisrollenklassen•für physikalische Netzwerke, physikalische Geräte und physikalischeVerbindungen sowie für logische Netzwerke, logische Geräte und lo-gische Verbindungen. Diese Klassen sind gemäß den Regeln von Au-tomationML von der Basisrolle <AutomationMLBaseRole> abgeleitet. Die Interface-Klassenbibliothek <CommunicationInterfaceClassLib>•stellt zwei Basis-Interface-Klassen für die Modellierung bereit. Die dortenthaltenen Interface-Klassen werden für die Beschreibung der physi-schen und logischen Schnittstellen verwendet.

Anwendungsbeispiel

Für eine bessere Erklärung des Vorgehens soll an dieser Stelleein Teil der Lemgoer Lernfabrik des Anwendungszentrums In-dustrial Automation (INA) des Fraunhofer IOSB modelliert wer-den. Im Beispiel ist eine Steuerung über dieKommunikationstechnologie XY (z.B. ethernetbasiertes Profi-net) mit zwei E/A Geräten verbunden (Bild 3). Dabei dienen dieE/A Geräte zum Anschließen der Sensoren und Aktoren an dasSteuerungssystem.

Modellierung in fünf Schritten

Schritt 1: Im ersten Schritt wird für jede der o.g. acht technolo-gieunabhängigen Rollenklassen jeweils eine technologiespezi-fische Rollenklasse abgeleitet − diese Bibliothek kann späterwiederverwendet werden. Im Beispiel wären dies die Commu-

Bild: A

utom

ationM

L e.V. c/o IAF

Bild 2: Rollen- und Interface-Klassen für die Kommunikationsmodellierung

Bild: A

utom

ationM

L e.V. c/o IAF

Bild 3: Kommunikationssystembeispiel

24

ILC350PN. Dabei wird die Bedeutung der einzelnen Elementedurch Verknüpfung zu den Klassen aus Schritt 2 festgelegt. Auchdiese Bibliothek ist später wiederverwendbar. Da für verschiedeneGeräte im Bereich der Steuerungstechnik zumeist schon Geräte-beschreibungen existieren, ist hier kein großer Aufwand zur Er-stellung der Bibliotheken zu erwarten. Im Anwendungsbeispielergeben sich vier physikalische Geräte (drei Steuerungsgeräte mitjeweils einer physikalischen Schnittstelle sowie den Switch als phy-sikalisches Gerät mit sechs Schnittstellen) sowie drei logische Ge-räte. Ebenso entstehen Klassen für die Verbindungen, die im Falleder physikalischen Verbindungen den Kabeln oder auch Funkstre-cken entsprechen. Die sich für das Beispiel ergebenden <Syste-mUnitClassLib>s sind in Bild 6 dargestellt. Spezielle Eigenschaftender physikalischen und logischen Geräte und Verbindungen sowieder in ihnen befindlichen Schnittstellen werden in AutomationMLdurch entsprechende Attribute an den <InternalElement>s, den<SystemUnitClass>es und den <InterfaceClass>es modelliert. ImErgebnis sind alle Voraussetzungen für die Netzwerkmodellierunggegeben. Im vierten und fünften Schritt wird jetzt das eigentlicheNetzwerkmodell erstellt.

Schritt 4: Im vierten Schritt wird mit der Gerätemodellierung be-gonnen. Dazu werden zuerst alle physischen Geräte als neue<InternalElement>s in einer entsprechenden <InstanceHierar-chy> von den passenden <SystemUnitClass>es instanziiert. Ent-hält ein physisches Gerät logische Geräte, werden diese alsKinder eingefügt. Dann werden alle relevanten Parameter mitkonkreten Werten belegt.

Schritt 5: Abschließend werden die Geräte verbunden. Dazuwerden zunächst in der <InstanceHierarchy> <InternalEle-ment>s erzeugt, die von den Rollen <PhysicalNetwork> und<LogicalNetwork> abgeleitete Rollen besitzen. Sie dienen als

Container für alle physikalischen bzw. logischen Verbindungen.Diese werden als nächstes durch Instanziierung der entspre-chenden <SystemUnitClass>es erstellt und mit entsprechendenParametern belegt. Zur Darstellung des Zusammenhangs zwi-schen Geräten und Verbindungen werden als Letztes die ent-sprechenden Interfaces der Geräte und Verbindungen über<InternalLink>s miteinander identifiziert. Das Modellierungser-gebnis für das Anlagenbeispiel ist in Bild 7 gezeigt.

Fazit

In fünf Schritten zeigt dieser Beitrag auf, wie Kommunikations-netzwerke mit AutomationML abgebildet werden können. Dievorgestellte Methode ist universell und sowohl für einfache alsauch für komplexe und verschachtelte Kommunikationsnetz-werke geeignet. Sie basiert auf vorgefertigten technologieun-abhängigen Basisklassen, auf deren Basis sichwiederverwendbare technologiespezifische Rollen- und Schnitt-stellenbibliotheken erstellen lassen. Die beschriebene Methodikermöglicht ein praxisnahes und iteratives Vorgehen: Logischeund physikalische Netzwerke können (müssen aber nicht) zurgleichen Zeit entstehen oder gemeinsam genutzt werden.Ebenso ermöglicht dieses Vorgehen eine stufenweise Daten-weitergabe. Bei der Übertragung der Entwurfsdaten könnenentweder die <RoleClassLib>s, <InterfaceClassLib>s und <Sys-temUnitClassLib>s weitergegeben werden, alternativ könntensie sogar im Internet veröffentlicht werden. Sind sie dem Emp-fänger bereits bekannt, können sie referenziert werden undmüssen nicht mit übertragen werden. Derzeit beginnen ersteArbeiten an der Umsetzung von Pilotanwendungen zur Nut-zung der Darstellungsmethode. Die Ergebnisse dieser Arbeitsollen im Rahmen der Standardisierung von AutomationML indie IEC62714 einfließen. Feldbusorganisationen sind eingela-

nicationTechnologyXY und die ApplicationXY stellvertretend fürbeispielsweise Profinet, EthernetIP, Interbus oder Sercos sowiefür gebräuchliche Applikationen wie die Steuerung von Senso-ren und Aktoren oder die Webserver basierte Konfiguration [1].Daraus entsteht eine technologieabhängige Rollenbibliothekmit acht Rollenklassen (Bild 4).

Schritt 2: Im sich daran anschließenden zweiten Schritt werdenvon den generischen Interface-Klassen entsprechende techno-logie- und applikationsbezogene Klassen abgeleitet (Bild 5).

Schritt 3: Im dritten Schritt wird eine <SystemUnitClassLib> erstellt,die alle physikalischen und logischen Geräte und Verbindungenals <SystemUnitClass> modelliert, beispielsweise die Steuerung

Bild 4: Technologieabhängige Rollenklassen für das Anwendungsbeispiel

Bild: Autom

ationM

L e.V. c/o IAF

Bild 5: Technologieabhängige Interface-Klassen für das Anwendungsbeispiel

25

Bild 6: <SystemUnitClassLib>s für das Anwendungsbeispiel

Bild: A

utom

ationM

L e.V. c/o IAF

Autor: Dr.-Ing. Matthias Riedl, Be-reichsleiter Integrierte Kom. , Institutf. Automation und Kommunikatione.V., Magdeburg

Autor: apl. Prof. Dr.-Ing. habil. ArndtLüder, Leiter Center Verteilte Systeme(CVS), Otto-von-Guericke UniversitätMagdeburg

Autorin: Nicole Schmidt, Wissen-schaftliche Mitarbeiterin CVS, Otto-von-Guericke Universität Magdeburg;Inst. für Arbeitswissenschaft, Fabrik-autom. und Fabrikbetrieb

Autor: Dr.-Ing. Rainer Drath, SeniorPrincipal Scientist, ABB AG For-schungszentrum Deutschland

Autor: Benno Heines, GruppenleiterResearch & Development ControlSystems, Phoenix Contact ElectronicsGmbH, Bad Pyrmont

[1]F. Klasen, V. Oestreich, M. Volz: Industrielle Kommunikation mit Feld-bus und Ethernet, VDE-Verlag, 2010.

Literatur

den, die beschriebene Vorgehensweise aufzugreifen und fürdie von Ihnen unterstützten Kommunikationstechnologien ent-sprechende <RoleClassLib>s, <InterfaceClassLib>s und <Syste-mUnitClassLib>s bereitzustellen. Dies würde sicherstellen, dassbisherige Entwicklungen in die Gerätemodellierung nahtlosübernommen werden können (insbesondere Parameterbenen-nungen, Geräteprofile, etc.) und eine breite Akzeptanz des Vor-gehens erreichbar ist. �

www.automationml.org

Bild 7: Netzwerkbeschreibung für das Anwendungsbeispiel

Bild: A

utom

ationM

L e.V. c/o IAF

26

MES (Manufacturing Execution Systems) [VDI5600-1] sindIT-/Software-Systeme für das Fertigungsmanagementmit direktem Zugang zur Steuerungsebene, z.B. zu den

SPSen. Sie überwachen den aktuellen Produktionszustand und ag-gregieren Informationen über diesen beispielsweise in sogenann-ten Kennzahlen (engl. KPI in sogenannte Kennzahlen (engl. KPI(Key Performance Indicator), siehe [ISO22400-2]). Für MES alsüberwachendes und steuerndes System ist es wichtig, Informa-tionen aus verschiedenen heterogenen Quellen zu sammeln undzu fusionieren. Dabei wäre ein einheitliches Datenaustauschformatstatt der in der Praxis anzutreffenden großen Anzahl an unter-schiedlichen Schnittstellen ideal. Ontologien [Onto] versuchen dieVerwendung von domänenspezifischen Terminologien zu verein-fachen und zu vereinheitlichen. Sie integrieren Semantik in diemodellierten Daten und formalisieren Zusammenhänge zwischenden definierten Konzepten, sodass diese auch maschinenbearbeit-bar und -auswertbar werden. Die MES-Ontologie [VDI5600-3] be-schreibt eine einheitliche Terminologie in einer Domäne, nämlichspezifisch für Daten und Informationen, die zwischen MES undMaschinen-/Anlagensteuerungsebene ausgetauscht werden. Fir-menspezifische Daten und Informationen werden auf die einheit-liche Terminologie abgebildet (siehe [ETFASch]). DieMES-Ontologie wurde zwischen 2008 und 2010 vom VDI GPP-Fachausschuss ‘Manufacturing Execution Systems (MES) − Arbeits-gruppe MES-Logische Schnittstellen’ erarbeitet. Innerhalb der

Bild 1: MES-Systeme sind fester Bestandteil moderner Produktionen. AutomationML bietet die Möglichkeit, MES-Wissen zu integrieren.

Bild: Fotolia/itestro

In der Produktionsanlagenplanung sind das Wissen und die damit erzeugten Informationen das wertvollste Gut.Dabei kann zwischen domänenunabhängigem Wissen und domänenspezifischem Wissen unterschieden werden.Domänenspezifisches Wissen ist beispielsweise MES-spezifisches Wissen. Domänenunabhängig kann Wissen z.B.im XML-basierten Datenaustauschformat AutomationML abgelegt werden. Beide Ansätze zur Modellierung undFormalisierung von Wissen können verbunden werden, indem etwa MES-spezifisches Wissen mithilfe des Rollen-konzepts in AutomationML integriert wird.

Serie AutomationML Teil 8: Integration domänenspezifischen MES-Wissens in AutomationML

AutomationML − IntegrationMES-Wissen

27

Ontologie, die sowohl in Textform als auch in der Web OntologyLanguage (OWL) vorliegt, wird unterschieden zwischen Daten-punkten und Ordnern. Für jeden Datenpunkt wird festgelegt, obes sich um einen mandatorischen oder einen optionalen Daten-punkt handelt. Ebenso werden die Datenformate vorgegeben.

Domänenunabhängiges Wissen in AutomationML

AutomationML bietet als offenes und in der Standardisierung be-findliches Datenaustauschformat (IEC62714) die Möglichkeit, se-mantische Informationen in den Anlagenmodellen zu hinterlegen.Dies kann genutzt werden, um einheitliche Terminologien undStandards aus spezifischen Domänen, wie z.B. MES, zu integrie-ren. Jedes Objekt innerhalb des AutomationML-Modells [AML2]übernimmt innerhalb seiner Umgebung eine Funktion und spieltdabei eine oder mehrere ‘Rollen’. Diese Rollen werden mithilfe desAutomationML-Rollenkonzepts im Dachdatenformat CAEX[CAEX] umgesetzt. Das CAEX-Bibliothekskonzept unterscheidet

drei Bibliotheksarten: die System-UnitClassLibraries, die Interface-ClassLibraries und die RoleClassLibraries. Darüber hinaus existiertdie konkrete Anlagenhierarchie, die in der InstanceHier-archy re-präsentiert wird. Eine Rolle beschreibt unabhängig von einer kon-kreten technischen Realisierung die Funktionen der physikalischenoder logischen Anlagenobjekte. Die konkrete technische Imple-mentierung wird in der SystemUnitClass oder in InternalElementsbeschrieben. Die Rolle/RoleClass stellt also eine Möglichkeit dar,die Bedeutung eines Objekts abstrakt und herstellerunabhängigzu beschreiben. Die Definition bzw. Typisierung der Rollen erfolgthierarchisch in RoleClassLibraries. Durch die Zuordnung einer Rol-lenklasse zu einem Objekt in der InstanceHierarchy des CAEX-Da-tenmodells werden diesem Objekt seine grundlegendenFunktionen und Anforderungen zugeteilt. Für AutomationMLwerden im Part 2 (IEC62714-2) der Spezifikation verschiedene Rol-lenklassenbibliotheken definiert. Diese können unterschieden wer-den in normative Rollenklassenbibliotheken, informative Rollenklassenbibliotheken sowie nutzerdefinierte Rollenklassenbi-bliotheken. Normativ existieren eine Basis-Rollenklassenbibliothek(AutomationMLBaseRoleClassLib), eine Rollenklassenbibliothek fürdie diskrete Fertigungsindustrie (discrete manufacturing industry− AutomationMLDMIRoleClassLib, siehe Bild 2), eine Rollenklas-senbibliothek für die kontinuierliche Fertigungsindustrie (continu-ous manufacturing industry − AutomationMLCMIRoleClassLib),eine Rollenklassenbibliothek für die Chargen-verarbeitende Ferti-gungsindustrie (batch manufacturing industry − AutomationMLB-MIRoleClassLib) sowie eine Rollenklassenbibliothek fürSteuerungssysteme (control systems − AutomationMLCSRole-ClassLib). Informativ ist die erweiterte Rollenklassenbibliothek (Au-tomationMLExtendedRoleClassLibrary) gegeben. Sie beschreibtmögliche Erweiterungen der normativen Rollenklassenbibliothe-ken. Beispielsweise werden für hierarchische Strukturen Rollen(z.B. Site, Area, ProductionLine) definiert, deren Definition an die

Bild 2: AutomationMLDMIRoleClassLib

Bild: IEC 62714-2

Bild 3: MES-Ontologie (oberste Hierarchieebene) [VDI5600-3]

Bild: Fraunhofer IOSB

28

(siehe Bild 3) der MES-Ontologie [CIRPSch] unterteilen sich dieInformationen in Produkt, Prozess, Ressource, Produktionsauf-trag, Zeitsynchronisation und einem allgemeinen Datenpunkt.Dies passt ideal zu den erweiterten Konzepten in Automati-onML, die ebenfalls zwischen Prozess, Produkt und Ressourceunterscheiden. Daher bietet sich eine Integration der VDI 5600-3 in AutomationML als eigene Rollenklassenbibliothek an. �

www.automationml.org

Spezifikation der ISA95 (IEC62264-1:2003) angelehnt ist. Darüberhinaus gibt es die Möglichkeit der Integration nutzerspezifischerInhalte, indem neue Bibliotheken von Nutzern definiert werden,die die bestehenden Basis-Bibliotheken erweitern. Diese nutzer-spezifischen Rollen müssen von den Basisrollen abgeleitet werden.So wird sichergestellt, dass diese auf einen definierten Ursprungzurückgeführt werden können. Beispiele für nutzerspezifische Rol-lenklassenbibliotheken könnten sein: branchenspezifische Biblio-theken (z.B. Lebensmittel), domänenspezifische Bibliotheken (z.B.MES), organisationsspezifische Bibliotheken (z.B. rotes Buch desVDMA und VDW) oder auch firmenspezifische oder toolspezifi-sche Bibliotheken.

Integration domänenspezifischen Wissens in AutomationML

Die Möglichkeit der Integration domänenspezifischen Wissensin AutomationML [AML] soll nun anhand der VDI 5600-Blatt 3[Automation] gezeigt werden. Diese Integration birgt den Vor-teil, dass die dort bereitgestellten Terminologien und das Voka-bular, inklusive deren Definition und Vererbungsrelationen, inAutomationML genutzt werden können. Dabei werden die inder Ontologie hinterlegten Begrifflichkeiten und Definitionenals Rollenbibliothek in AutomationML verwendet. So kann dieSemantik der Domäne MES direkt innerhalb von AutomationMLeingesetzt werden. Eine solche Integration erhöht die Akzep-tanz und baut die Anfangsbarrieren ab. Die Integration kannmanuell oder basierend auf den XML-Datenformaten undStrukturen von OWL und AutomationML automatisch (siehebeispielsweise Projekt SemMES [SemMES]) mit manueller Nach-bearbeitung erfolgen. Wichtig hierbei sind vor allem die Mög-lichkeiten, die durch die Integration der Definitionen für dieeinzelnen Rollen entstehen. Auf oberster Organisationsebene

[AML] Miriam Schleipen, Rainer Drath: Three-View-Concept for modelingprocess or manufacturing plants with AutomationML. 13th IEEE Internatio-nal Conference on Emerging Technologies and Factory Automation (ETFA).22.-25.9.2009, Palma de Mallorca, Spain.[AML2] AutomationML. http://www.automationml.org/, Juni 2013.[Automation] Miriam Schleipen, Olaf Sauer, Lidmilla Fuskova: MES-Ontolo-gie − Semantische Schnittstelle zwischen Maschine und MES. Automation2010, Baden-Baden.[CAEX] IEC 62424. Representation of process control engineer ing − Re-quests in P&I diagrams and data exchange bet ween P&ID tools and PCE-CAE tools, 2008.[CIRPSch] Miriam Schleipen, Olaf Sauer, Lidmilla Fuskova, ‘Logical interfacebetween MES and machine − semantic integration by means of ontologies’,Proceedings of: CIRP ICME ‘10 − 7th CIRP International Conference on IN-TELLIGENT COMPUTATION IN MANUFACTURING ENGINEERING, Innovativeand Cognitive Production Technology and Systems, 978-88-95028-65-1.23 − 25 June 2010, Capri (Gulf of Naples), Italy, 2010.][ETFASch] Miriam Schleipen, Dirk Gutting, Franziska Sauerwein: Domain de-pendant matching of MES knowledge and domain independent mappingof AutomationML models. IEEE conference on Emerging Technologies andFactory Automation ETFA 2012, September 17-21, Krakow, Poland, 2012.[ISO22400-2] DRAFT INTERNATIONAL STANDARD ISO/DIS 22400-2, ISO/TC184/SC 5 Secretariat: ANSI, Automation systems and integration − Key per-formance indicators for manufacturing operations management − Part 2:Definitions and descriptions.[Onto] Mike Uschold, Michael Grüninger, ‘Ontologies: Principles, Methodsand Applications’, Knowledge Engineering Review 11(2) (1996), pp. 93-155, 1996.[SemMES] Christoph Thomalla, Miriam Schleipen, Olaf Sauer: Standardi-sierte semantische Schnittstelle MES - Maschinenebene (SemMES). Ab-schlussbericht. Förderkennzeichen: 01FS10013. Standardized semanticinterface MES − machine level (SemMES). Report. Elektronische Publikation,Fraunhofer Publica, http://publica.fraunhofer.de/dokumente/N-226473.html, 2013.[VDI5600-1] VDI 5600-1, Manufacturing Execution Systems (MES), BeuthVerlag, 2007.[VDI5600-3] VDI 5600-3, Manufacturing Execution Systems (MES) − Logi-sche Schnittstelle Maschinen- und Anlagensteuerung, Beuth Verlag, 2013.

Literatur

Autorin: Dr.-Ing. MiriamSchleipen, GruppenleiterinLeitsysteme und Anlagen-modellierung, FraunhoferIOSB

29

Voraussetzung für die Simulation ist das Vorhandenseinentsprechender simulierbarer Modelle, die neben derGeometrie und Kinematik auch das Verhalten der Sys-

temkomponenten beschreiben. Die Anbieter von Systemkom-ponenten geben derzeit das Verhalten ihrer Komponenten ineinem Handbuch mit oder sie bieten spezifische Module fürdie einzelnen Simulationswerkzeuge an. Die Möglichkeit, dasVerhalten in einer neutralen Sprache zu beschreiben, würdesie unabhängig von dem vom Auftraggeber genutzten Simu-lationswerkzeug machen, vorausgesetzt eine Überführung indieses Werkzeug ist möglich. Zudem können Bibliotheken vonSystemkomponenten entstehen, die für verschiedene Simula-tionsziele unterschiedliche Modelle der Systemkomponentenbereitstellen, die der Wissenssicherung dienen und die Wieder-verwendbarkeit dieser Systemkomponenten vereinfachen. Der-artige Bibliotheken könnten aus unterschiedlichen Quellengespeist werden. Kandidaten dafür sind neben den Systemin-

Die virtuelle Planung von Fertigungsanlagen gewinntimmer mehr an Bedeutung. Die Logik einzelner Kom-ponenten sowie vollständige Anlagenabläufe inklusivealler möglichen Sonderfunktionen sollen im Vorfeldausgiebig getestet werden können, noch vor der Instal-lation auf der Baustelle. Dazu gehört beispielsweiseauch das Verhalten von Antrieben für Förderer, welchesdann mithilfe von gängigen Werkzeugen, für die Win-MOD von Mewes & Partner oder Tecnomatix Process Si-mulate von Siemens PLM als Beispiele genannt werdenkönnten, simuliert werden kann.

Serie AutomationML Teil 9: Eignet sich AutomationML als neutraleSprache zur Beschreibung von Verhalten?

AutomationML: Verhältnismäßig gut!

Bild 1: Steuerung des Antriebs im Funktionsblockdiagramm nach IEC61131-3

Bild: A

utom

ationM

L e.V. c/o IAF

30

tegratoren auch Komponenten- und Gerätelieferanten. DieserArtikel soll zeigen, dass AutomationML sowohl zum neutralenAustausch von Verhaltensinformationen geeignet ist als auchdie Voraussetzung für eine Bibliotheksbildung erfüllt.

Ein Beispiel

Für ein besseres Verständnis soll an dieser Stelle ein Antriebs-strang betrachtet werden, wie er in Teil 5 dieser Artikelseriebereits vorgestellt wurde. Dieser soll einen Antrieb mit einervereinfachten Antriebssteuerung enthalten. Dieser Antriebkann sowohl im Rechts- als auch im Linkslauf betrieben wer-den und unterstützt zwei Geschwindigkeiten. Dabei darf er

aus dem Stillstand in den Links- oder Rechtslauf gestartet wer-den. Zwischen den beiden Geschwindigkeiten darf innerhalbderselben Laufrichtung jederzeit gewechselt werden. Um denAntrieb allerdings aus der einen Laufrichtung in die andere zuschalten, muss er zunächst angehalten werden. Wird versuchtden Antrieb vom Rechts- direkt in den Linkslauf zu schalten(oder umgekehrt), wird dies ignoriert und ein Fehlerstatus ge-setzt, der zurückgesetzt werden kann. Hieraus ergeben sichdie Eingänge der Steuerung, wie sie in Bild 6 zusammenge-fasst sind. Während des Betriebs sollen von der Antriebssteue-rung zwei Informationen abgefragt werden können. Zumeinen soll die aktuelle Geschwindigkeit und zum anderen deraktuelle Fehlerstatus ausgelesen werden können. Die sich da-raus ergebenden Ausgänge der Steuerung sind in Bild 7 zu-sammengefasst. Das Verhalten dieser Steuerung lässt sichnach IEC61131-3 als Funktionsblockdiagramm (FBD) beschrei-ben und ist in Bild 1 zu sehen.

Herstellerunabhängige Komponentenbeschreibung

Für eine hersteller- und technologieunabhängige Beschrei-bung des Antriebstrangs kann AutomationML eingesetzt wer-den. Dazu werden CAEX zur Beschreibung derKomponentenstruktur und dazugehörige Schnittstellen undPLCopen XML zur Beschreibung des Komponentenverhaltensverwendet. In CAEX werden, wie in Bild 2 zu sehen, die ein-zelnen Geräte zu einer Gerätestruktur als Hierarchie von In-ternalElements zusammengefasst und bilden damit eineKomponente. In Bild 2 sind beispielhaft die AntriebssträngeSimpleDriveControl und AdvancedDriveControl gezeigt, diejeweils eine Komponente bilden und einen Antrieb, eine An-triebssteuerung und die Applikationsbeschreibung enthalten.Die einzelnen InternalElements der Hierarchie können not-wendige Eigenschaften als Attribute enthalten. Zudem wirdaus CAEX heraus auf PLCopen XML Dateien verwiesen, um

Bild 2: Komponentenbeispiel

Bild: A

utom

ationM

L e.V. c/o IAF

Bild 3: Beispielreferenzen auf PLCopen XML-Dateien

Bild: AutomationML e.V. c/o IAF

31

darüber die Verhaltensbeschreibungen einzubinden. Wie Bild3 verdeutlicht, dienen dazu entsprechende ExternalInterfaceElemente, die auf Objekte (ganze POEs oder einzelne Varia-blen) in den PLCopen XML Dateien verweisen.

PLCopen XML

Das FBD ist eine der fünf in der IEC61131-3 definierten Spra-chen zur Programmierung von Speicherprogrammierbaren

Steuerungen (SPS). PLCopen XML wurde entwickelt, um dieSteuerungslogik gemäß IEC61131-3 in einem herstellerun-abhängigen Format abbilden zu können. Ähnlich wie in dergrafischen Repräsentation in Bild 1 wird in PLCopen XMLjeder einzelne Funktionsbaustein als eigenes Element be-schrieben. Die Eingangs- bzw. Ausgangsvariablen werdendurch die Elemente <inVariable> und <outVariable> model-liert und die einzelnen Funktionsblöcke, die nach IEC61131-3 standardisiert sind, durch die Elemente <block> dargestellt.Die einzelnen Funktionsblöcke und Variablen werden nunüber sogenannte Konnektoren miteinander verbunden, wo-durch sich die Antriebssteuerung vollständig in der neutralenSprache PLCopen XML modellieren lässt. Ein Ausschnitt ausder resultierenden Beschreibung ist in Bild 4 zu sehen. Umfestzustellen, ob diese Darstellung auch für den herstellerun-abhängigen Datenaustausch geeignet ist, muss untersuchtwerden, wie die gleiche Steuerung in einem Simulationssys-

tem zu modellieren und ob eine automatische Überführungder Darstellungen möglich ist.

Process Simulate

Für diese Untersuchungen soll das Simulationssystem ProcessSimulate beispielhaft herangezogen werden. Es ist ein Reprä-sentant einer Werkzeugklasse, für die nach Ansicht der Auto-ren die nachfolgenden Aussagen ebenso zutreffen. Für dieBeschreibung einer Steuerung steht im Simulationssystem Pro-cess Simulate ein Editor zur Verfügung, mit dessen Hilfe sichEingänge, Ausgänge und Parameter definieren lassen. Eingän-gen und Ausgängen können Datentypen zugewiesen werden.Parameter definieren Funktionen, die aus n Variablen ein Er-gebnis ermitteln. Als Variablen dienen entweder die Eingängeoder die Ergebnisse von anderen Parametern. Als Funktionenstehen neben arithmetischen und booleschen Operationen

Bild 4: FDB in PLCopen XML

Bild: A

utom

ationM

L e.V. c/o IAF

Bild 5: Analogie zwischen PLCopen XML und Process Simulate

Bild: A

utom

ationM

L e.V. c/o IAF

32

auch einige vordefinierte Funktionen wie z.B. ‘RisingEdge’, ‘Fal-lingEdge’ oder ‘SetReset’ zur Verfügung. Diese stellen ein Sub-set der in der IEC61131-3 standardisierten FBD Bausteine zurBeschreibung von Steuerungsverhalten dar. Gespeichert wirddas Verhalten in einer XML Datei. Ein Blick in die erzeugte Datei(siehe Bild 5) zeigt, dass hier die Eingänge und Ausgänge sowiedie einzelnen Funktionsblöcke in Listen gespeichert und überihre IDs miteinander verknüpft werden.

Beliebig austauschbar!

Im direkten Vergleich ist ein analoger Aufbau der beiden XMLFormate zu erkennen.

Die Daten werden in Eingänge, Ausgänge und Funktionen bzw. FBD•Bausteinen gruppiert. Eingänge sind die Variablen der Funktionen.•Das Ergebnis einer Funktion ist entweder eine Variable für eine fol-•gende Funktion oder der Wert eines Ausgangs.Alle Funktionen entsprechen denen in der IEC61131-3 beschriebenen.•

Der Informationsgehalt in beiden Formaten ist somit iden-tisch. Da es sich bei beiden Formaten um XML Dokumentehandelt, wäre eine Überführung im einfachsten Fall durcheine XML Transformation mittels XSLT möglich. Process Simu-late bietet zwar nur ein Subset der in der IEC61131-3 be-schriebenen Funktionen an, allerdings steht es demAnwender frei über eine Plugin-Schnittstelle weitere Funktio-nen im Editor zur Verfügung zu stellen.

Aber sicher!

Dem Bestreben Daten herstellerneutral abzubilden steht auchimmer der Wunsch gegenüber, den Inhalt vor dem Zugriff Un-

Bild 7: Ausgänge der Antriebssteuerung

Bild 6: Eingänge der Antriebssteuerung

Bild: A

utom

ationM

L e.V. c/o IAF

Bild: A

utom

ationM

L e.V. c/o IAF

33

arbeitung von XML Dateien entsprechende frei verfügbareSoftwarekomponenten vorhanden, so dass ihre Anwendungnur vor organisatorischen, nicht jedoch vor technischen He-rausforderungen steht.

Und nun?

Fasst man die beschriebenen Strukturen zusammen, so kön-nen herstellerunabhängige Bibliotheken wiederverwendbarerSystemkomponenten entstehen, die passend zu unterschied-lichen Anwendungsfällen Verhaltensmodelle enthalten. DieseModelle können, wie erste Entwicklungsansätze zeigen, au-tomatisch zur Erstellung von simulierbaren Anlagenmodellenkombiniert werden. Für deren Simulation könnte dann ent-weder auf bestehende Werkzeuge zurückgegriffen oder neueSimulationswerkzeuge unter Anwendung von IEC61131-3basierten Soft-SPSen entwickelt werden. In beiden Fällen kön-nen insbesondere Komponentenlieferanten und Systeminte-gratoren profitieren. Erstere können sich durch dieBereitstellung von Simulationsmodellen einen Marktvorteil si-chern und letztere können Wissen sichern und wiederverwen-den und damit ihre Entwurfsqualität deutlich erhöhen. �

www.automationml.org

befugter und vor nicht intendierter Veränderung abzusichern.In diesem Zusammenhang stellen sich im Wesentlichen zweiFragen:

Von wem sind die Daten und wurden sie auch nicht verändert?•Wer darf die Daten sehen?•

Die erste Frage beschäftigt sich also mit der Authentizität undder Integrität der Daten und die zweite mit dem Schutz vorMissbrauch. Beide Fragen sind so alt wie ihre Lösungsansätze.Authentizität und Integrität kann durch eine digitale Signaturgewährleistet und der Schutz vor Missbrauch kann durch Ver-schlüsselung erreicht werden. Welcher Standard dafür genutztwird, sei es PKCS oder XML Signature/Encryption, ist reine Ge-schmackssache. Vielmehr sollte klar sein, welche Folgen dieNutzung von Verschlüsslungen bzw. Signaturen haben könn-ten. Eine digitale Signatur ist in jedem Fall sinnvoll. Die Datensind lesbar, die Integrität kann jederzeit überprüft werden unddie Entscheidung, ob der Signatur vertraut wird, kann frei ge-troffen werden. Sind die Daten hingegen (auch) verschlüsselt,so kann nur der vorgesehene Empfänger die Daten sehen. Wirdeine Verschlüsselung als Transportsicherung für eine Übermitt-lung beispielsweise per Mail verwendet oder dient sie dem Wis-sensschutz bei einer Langzeitarchivierung, so ist dies mitSicherheit sinnvoll. Hier muss jedoch für jeden Anwendungsfallgenau überprüft werden, wer wann welche der verschlüsseltenInformationen lesen bzw. verändern darf und wie ihm die dafürnotwendigen Schlüssel zur Verfügung gestellt werden können.Insbesondere gilt dies, wenn der Empfänger ein Programm ist,das die Daten weiterverarbeitet. Hier muss durch alle Beteilig-ten sichergestellt sein, dass der Ansatz eines herstellerneutralenDatenformates nicht ad absurdum geführt wird. Für beide An-wendungsfälle, Verschlüsslungen und Signatur, sind für die Ver-

Autor: Steffen Lips, Projektleiter,NetAllied Systems GmbH

34

D ie Idee des ‘Super-Datenmodells’ ist die treibende Kraftaller entsprechenden Standardisierungsaktivitäten, z.B.NE100 [1], STEP [2], ISO15926 [3] u.v.m. Dazu müssen

sie stets folgende Schritte durchlaufen:

a) Experten sammeln für beteiligte Gewerke bzw. Werkzeuge sinnvolle•Datenmodelle und Konzepte.b) Experten einigen sich auf die gemeinsam benötigten Grundkon-•zepte.c) Experten einigen sich auf ein neutrales, semantisches Datenmo-•dell, das alle Grundkonzepte berücksichtigt, z.B. mit UML.d) Experten einigen sich auf eine neutrale Syntax, z.B. basierend auf•XML.e) Alle gesammelten Konzepte, das semantische Datenmodell und die•Umsetzung in einer gemeinsamen Syntax, werden dokumentiert.f) Die Industrie und Akademia schafft die Voraussetzungen dafür, dass•genügend Experten zur Verfügung stehen, die den Standard beurteilenund implementieren können. g) Anwender und Werkzeughersteller implementieren und nutzen den•Standardentwurf in ihren Werkzeugen.h) Erfahrungen aus der praktischen Nutzung des Standards fließen in•(a) zurück und tragen zur Reifung bei.

Bis heute ist dies nicht gelungen. Bild 1 erklärt den Konflikt:Standardisierung reift nur durch Rückfluss von Erfahrungen ausder praktischen Anwendung. Werkzeughersteller warten jedochaus Kostengründen typischerweise erst auf einen gereiftenStandard, bevor sie ihre Software mit Ex- und Importern aus-statten. Die Rückführungen der praktischen Erfahrungen in dieStandardisierung (h) sowie die notwendigen Implementierun-gen der Hersteller (g) sind gestört, die Standardisierung befindetsich in einem Deadlock. Die Idee: Ein gemischtes Datenmodell Ein Weltmodell des Engineering ist offensichtlich nicht ineinem Schritt erreichbar. AutomationML [4] verfolgt daher

Bild 1: Die Rückführungen im Standardisierungsregelkreis sind gestört.

Bild: ABB AG Forschungszentrum Deutschland

Es klingt plausibel: Für ein neutrales Datenaustauschformat für das Engineering benötigt man eine standardisierteSyntax und Semantik. Es müsste ein ‘Super-Datenmodell’ entwickelt werden, das die wichtigsten Datenmodelledes Engineering vereint und eine eindeutige und verlustlose Abbildung aller Daten ermöglicht.

Serie AutomationML Teil 10: Austausch von Daten zwischen unter-schiedlichen Datenmodellen im heterogenen Werkzeugumfeld

Warum ein Engineering-Weltmodell bisher nicht gelang

35

einen anderen Ansatz. Anstatt auf eine Standardisierung zuwarten, lässt es die Speicherung proprietärer Semantiken ex-plizit zu [5]. Beim Export aus einem Engineeringwerkzeugwerden die Daten syntaktisch neutralisiert, die Semantikbleibt jedoch proprietär (‘privat’). Ein Signal würde beispiels-weise alle Eigenschaften inklusive seines Namens aus dem Ur-sprungswerkzeug behalten. Auch wenn das Zielwerkzeug dieseDaten zunächst nicht interpretieren kann (gerade zu Beginn),stellt dies bereits einen erheblichen Gewinn dar: Erstmalig wer-den proprietäre Datenmodelle aus ihrem Werkzeug herausge-löst, syntaktisch neutralisiert und untersuchbar. Dies erleichtertdie beiden Schritte (a) und (b) der beschriebenen Standardisie-rungskette erheblich. Ziel-Engineering-Werkzeuge können dieDatei öffnen, durchsuchen und darstellen. Funktionen wie Na-vigation, Änderungsberechnungen und Versions-Managementsind unabhängig vom Datenmodell und lassen sich generischentwickeln und wiederverwenden. Es fehlen nur noch dieTransformationsroutinen, die für die proprietären Datenmodelledes Quellwerkzeuges zugeschnitten sind. Doch woher kom-men sie und wie kann ein Importer erkennen, welche davonaufgerufen werden müssen? Die Idee: Identifikation des Quellwerkzeuges AutomationML führt dazu erstmalig einen standardisierten Eti-kettiermechanismus ein. Die CAEX-Datei bekommt ein Etikett

(siehe Bild 2), welches während des Exports in die Automati-onML-Datei eingebettet wird und Informationen über das Quell-werkzeug enthält. Ein Importer kann dieses Etikett auswertenund private Transformationsroutinen anstoßen. Dieses Konzeptwird von der frei verfügbaren Software AutomationML Engine[6] unterstützt. Diese Vorgehensweise bedeutet keineswegs,dass jedes Werkzeug seine Daten dann auch gleich in seinemeigenen proprietären Datenformat exportieren könnte. Bereitsdie syntaktische Neutralisierung bringt entscheidende Vorteile:

Der Hauptaufwand eines Importers liegt in Operationen wie Versions-•management oder Änderungsberechnungen. Diese Operationen sindunabhängig vom Datenmodell. Derartige Funktionalität müsste fürjedes proprietäre Datenformat erneut entwickelt werden. Basierendauf einem neutralen Datenformat genügt eine einzige Implementie-rung. Ein Großteil des Importers kann daher − unabhängig vom jewei-ligen Quellwerkzeug − wiederverwendet werden.Das Etikettierkonzept erlaubt die automatische Absendererkennung.•Proprietäre Datenformate wie z.B. Excel-Sheets etc. verfügen überkeine standardisierte Methodik dafür.

Und dann? Die quellwerkzeugspezifischen Subroutinen für die Interpreta-tion und den Import müssen erst entwickelt werden. Die Erken-nung des Quellwerkzeuges ist der Schlüssel. Der ‘Trick’ bestehtdarin, dass der Importer ‘unbekannte private Datenmodelle’ er-kennen und in einer separaten CAEX-Bibliothek speichern kann.Mit anderen Worten: Der Importer weiß, was er nicht weiß. EineBibliothek unbekannter Datentypen bzw. Klassen enthält alleDatenmodell-Kandidaten, sozusagen ein Lastenheft für die Soft-wareentwicklung. Anhand von Häufigkeitsuntersuchungen las-sen sie die Kandidaten sogar priorisieren. PrivateTransformationsroutinen können damit ohne Warten auf einenStandard in lokaler Verantwortung entwickelt werden. Das geht

schneller als jede Standardisierung. Das Ziel ist zunächst der ge-lebte praktische Einsatz und die Reifung unter realen Bedingun-gen. Nach der Entwicklung erster Transformationsroutinenwerden aus ‘unbekannten’ somit ‘bekannte’ Datenmodelle. Sielassen sich für jeden weiteren Datenaustausch mit demselbenQuellwerkzeug wiederverwenden. Das beschriebene Szenarioist unmittelbar einführbar. Zwei Werkzeughersteller oder -nut-zer können beliebig Export-Import-Partnerschaften eingehen.Ein dritter Teilnehmer kann sich (auch später) einbinden. DiesesSzenario stellt zugleich Reifegrad 1 eines evolutionären Reifeg-radmodells dar: (siehe Bild 3). Dieser ist ein erster Meilensteinin der Evolution eines Standardisierungsprozesses: Er erleichtertdie Schritte (a) und (b) und belebt die Rückführung von Erfah-rungen (h) aus der praktischen Anwendung. Der Deadlock ausBild 1 wird durchbrochen. Dieser Reifegrad ist für Werkzeugegeeignet und möglicherweise sogar ausreichend, die nur we-nige Datenaustauschpartner besitzen. Die Entwicklung privaterTransformationsroutinen benötigt deutlich weniger Aufwandals eine Standardisierung. Reifegrad 1 ist weiterhin ideal fürWerkzeuge, die lediglich ihre eigenen Daten archivieren bzw.extern manipulieren und anschließend wieder einlesen möch-ten. Mit einer wachsender Zahl von Teilnehmern wird eine Bi-bliothek aus Transformationsroutinen entstehen. Dies ist ein

Bild 2: AutomationML-Beispiel-EtikettBild: ABB AG Forschungszentrum Deutschland

Bild: A

BB AG Forschungszentrum

Deutschland

Bild 3: Reifegradmodell

36

geeigneter Indikator für den Start einer Konsolidierung des Ent-wicklungsaufwandes und somit ein geeigneter Übergangspunktzu Reifegrad 2, denn ähnliche Datenmodelle sind Kandidatenfür eine erste Standardisierung. Reifegrad 2 entsteht aus derKonsolidierung der Standardisierungskandidaten aus Reifegrad1. Ähnliche Datenmodelle führen zu Mehrfachentwicklung vonähnlichen Transformationsroutinen und erhöhen unnötig dieEntwicklungskosten. Dies fördert die Standardisierungsbereit-schaft und führt zu ersten neutralen ‘Mini’-Datenmodellen. Fürjedes neutralisierte ‘Mini’-Datenmodell kann in jedem Importerdie Zahl n der privaten Transformationsroutinen für n Quell-werkzeuge auf eine einzige Transformationsroutine reduziertwerden. Auf diese Weise entsteht ein Pool an neutralen Daten-modellen, während der Pool privater Transformationsroutinenabnimmt. Der Evolutionsprozess hin zu Reifegrad 2 wird somitaus praktischen Projektbedürfnissen getrieben. Dies stellt einennatürlichen und evolutionären Prozess dar. Unter Verwendungerster neutraler Daten-Teilmodelle erzeugt ein Exporter in Rei-

fegrad 2 ein gemischt standardisiert/privates CAEX-Datenmo-dell. Reifegrad 3 wird erreicht, wenn alle benötigten Daten-Teil-modelle durch neutrale Datenmodelle abgebildet werden. Erbildet das Gegenstück zu Reifegrad 1, da hierbei der Anteil anprivaten Datenmodellen 0% beträgt. Seine Reife erlangt erdurch Erfahrungen im praktischen Einsatz. Reifegrad 3 ist nichtan internationale Standards gebunden. Es könnte ebenso einStandard eines einzelnen Projektes oder eines Konsortiums sein.Dieser Reifegrad kommt der eigentlichen Idee eines neutralenDatenaustauschformates bereits nahe: Private Transformations-routinen sind nicht mehr notwendig − das Datenmodell ist ausErfahrungen der Reifegrade 1-2 gewachsen und gereift. Reife-grad 4 wird erreicht, wenn mehrere ‘Reifegrad 3 Standards’ zueinem übergeordneten Standard kombiniert werden. Die Da-tenmodelle aus Reifegrad 3 bilden aufgrund praktischer Erfah-rungen eine belastbare Basis für die Schritte (a) und (b) einesübergreifenden Standardisierungsvorhabens, z.B. für einen in-ternationalen Standard. Dieser Reifegrad ist als langfristiges Zielzu verstehen und ein evolutionäres Ergebnis des Durchlaufensder vorigen Reifegrade. Diskussion und Zusammenfassung Standardisierungsgremien und Softwarehersteller haben früh-zeitig den Wert eines gemeinsamen Datenmodelles erkannt,verfolgen jedoch mehrheitlich Reifegrad 3 bzw. 4. Für die Praxismacht es jedoch keinen Sinn, sofort mit Reifegrad 3 oder 4 zubeginnen. Eine Evolution beginnt stets mit dem ersten Schritt(Reifegrad 1). Mit dem vorgestellten Konzept wird semantischeVielfalt beherrschbar. Die Mischung privater und neutralerDaten eliminiert den Bedarf nach einem umfassenden und ge-reiften Engineering-Weltmodell: Der Schwerpunkt verlagertsich stattdessen auf kleine und flexible ‘Mini’-Datenmodelle.

Diese ‘Mikro-Standardisierung’ zwischen zwei Werkzeugen istein agiler und pragmatischer Weg mit iterativen Standardisie-rungs-Sprints. Der praktische Einsatz steht in jedem Reifegradim Vordergrund, die Standardisierung folgt der Nutzung, nichtumgekehrt. Erstmalig lässt sich Standardisierungsbedarf inklu-sive Priorisierung automatisch ableiten. Mit diesem Ansatz ver-sucht AutomationML nicht, die bestehende Heterogenität vonEngineering-Werkzeugen und Datenmodellen durch Verein-heitlichung zu überwinden; Das Konzept verfolgt vielmehr dasAnliegen, den Datenaustausch in einem heterogenen Werk-zeugumfeld auch ohne bzw. nur mit teilweiser Standardisie-rung durchführen zu können. Anwender könnenDatenaustauschlösungen deutlich leichter und schneller als bis-her entwickeln. Gerade für das Umsetzen von Werkzeugkettenmit nur wenigen Datenaustauschpartnern ist der Entwicklungs-aufwand deutlich geringer als das Standardisieren eines Welt-modells. Das Warten auf einen Standard ist nicht mehr nötig.Zugleich ebnet diese Vorgehensweise den Weg zu einer evolu-tionären Standardisierung, entkoppelt jedoch dessen Zeitbedarfvom Projektdruck in der Industrie. Erste Verbände (z.B. VDAund VDMA) haben dies erkannt und verfolgen statt breiterStandardisierung die zügige Entwicklung leichtgewichtigerSchnittstellen für begrenzte Bereiche. �

www.automationml.org

Autor: Dr.-Ing. Rainer Drath,Senior Principal Scientist,ABB AG ForschungszentrumDeutschland

[1] Namur Empfehlung 100: Merkmalleisten zur Erstellung von PLT-Gerätespezifikatio-nen. 2003.[2] ISO10303: Automation systems and integration - Product data representation andexchange, formerly known as STEP, Standard for the Exchange of Product model data.[3] ISO15926. Industrial automation systems and integration - Integration of life-cycledata for process plants in-cluding oil and gas production facilities.[4] IEC62714-1 CD norm draft AutomationML Architectu-re, www.iec.ch, 2011.[5] Drath R., Barth M.: Wie der Umgang mit unterschiedlichen Datenmodellen beim Da-tenaustausch im heterogenen Werkzeugumfeld gelingt. In: Tagungsband Automation2013, Baden-Baden, VDI-Berichte 2209, ISBN 978-3-18-092209-6, 2013.[6] www.automationml.org

Literatur

37

Beim iterativen Engineering (Bild 1) werden Daten zwi-schen zwei Engineering-Werkzeugen während eines Ent-wicklungsprojektes wiederholt ausgetauscht. Der

Datenaustausch ist unidirektional vom Quell- zum Zielsystem or-ganisiert. Bei einem wiederholten Datenexport werden dabeivom Engineeringsystem, das die Datenquelle repräsentiert, zujedem geänderten AutomationML-Objekt die entsprechendenÄnderungsinformationen (mit) in die AutomationML-Datei ge-schrieben. Diese Informationen werden auf der Empfängerseiteinterpretiert, sodass eine Selektion und Integration der Datenin das Zielsystem erfolgen kann. Zur Kennzeichnung von Ände-rungen der Daten innerhalb eines Projektes bietet Automati-onML folgende Konzepte an:

ChangeMode − Attribute für jedes CAEX-Objekt•Revision/Version − Information für jedes CAEX-Objekt•Globally Unique Identifier (GUID) für alle AutomationML-Objekte•Projekt Identifikation im ‘Writer-Header’•

Das ‘ChangeMode’-Attribut erlaubt dem Versender, ein Objektals neu (‘create’), geändert (‘change’), unverändert (‘state’) odergelöscht (‘delete’) zu kennzeichnen. Soll das ursprüngliche Ob-jekt auch bei Änderungen noch in der AutomationML Datei er-halten bleiben, besteht die Möglichkeit, das geänderte Objektneu anzulegen und bei diesem und bei dem ursprünglichen Ori-ginalobjekt entsprechende Versionsinformationen zu hinterle-gen. Der Versender der Daten muss bei einem wiederholtenDatenexport auf die ursprünglich erzeugten AutomationML-Do-kumente (bzw. auf die zuletzt versendete Datei) zugreifen kön-

Bild 1: Iteratives Engineering

Bild: inpro Innovationsgesellschaft m

bH

Der Datenaustausch zwischen zwei Entwurfswerkzeugen während eines Entwicklungsprojektes ist oft keine ein-malige Angelegenheit, sondern findet wiederholt statt. Objekte werden auch nach einem Datenaustausch beimDatenversender und beim Datenempfänger geändert, spezifiziert oder möglicherweise neu definiert. Bei einemwiederholten Datenaustausch in einem Entwicklungsprojekt sollten möglichst alle Änderungen als solche kennt-lich gemacht werden, sodass das Zielwerkzeug einen selektiven Import der Daten durchführen kann und Ände-rungen mit dem eigenen Datenbestand vergleichen und in diesen sinnvoll integrieren kann. Ein Änderungs- undVersionsmanagement ist bei lose gekoppelten Werkzeugen, die lediglich über eine Datei-Schnittstelle und nichtüber eine gemeinsame Datenbank verknüpft sind, in der Regel nicht möglich. Dieser Beitrag zeigt, wie auch fürdie dateibasierte Kopplung − mit Hilfe des AutomationML Austauschformates − ein Änderungs- und Versionsma-nagement implementiert und damit komplexere Workflows unterstützt werden können, die über den einmaligenDatenaustausch weit hinausgehen.

Serie AutomationML Teil 11: Unterstützung von Engineering WorkflowsAutomationML − Engineering Workflow

38

nen, um Änderungsinformationen generieren zu können. Eineeinfache Möglichkeit dies zu realisieren, ist die Verwendungeines projektspezifischen Dateiablageorts für die Versionskon-trolle der versendeten AutomationML-Dateien durch den Ver-sender. In diesem Verzeichnis können auch die nötigenZuordnungsdateien (Endung .iaml in Bild 2) abgelegt werden,über die die Zuordnung der AutomationML-Objekte zu den ur-sprünglichen Systemobjekten erfolgen kann (Bild 2). Eine Vo-raussetzung zur effektiven Nutzung der beschriebenenKonzepte besteht darin, dass jedes AutomationML-Objekt eineeindeutige globale ID (GUID) erhält. Diese ID bleibt über dengesamten Lebenszyklus des Objektes erhalten. So behält ein Au-tomationML-Objekt, das bei einem wiederholten Datenaus-tausch als geändertes Objekt gekennzeichnet wird, dieursprüngliche GUID, die es bei seiner ‘Geburt’ erhalten hat. Ineiner Zuordnungstabelle kann diese GUID mit einem systemei-genen Identifizierungsschlüssel assoziiert werden, sodass ein Ex-porter die Änderungsinformationen für jedes Objekt anhand

der Zuordnungstabelle undeinem Vergleich mit der zu-letzt erzeugten Automati-onML-Datei generieren kann.Das Empfängerwerkzeug derDaten kann erkennen, ob einAutomationML-Objekt zumersten Mal gesendet wird, daes in diesem Fall den Change-Mode ‘create’ besitzt. In allennachfolgenden Sendungenbesitzt dasselbe Objekt einenanderen der möglichen Chan-geMode-Werte (‘change’,‘state’, ‘delete’). Bei einem se-

lektiven Import müssen Objekte mit einem ChangeMode-Wertvon ‘change’ oder ‘delete’ besonders behandelt werden, da inder Regel die eingelesenen Daten seit dem letzten Import imZielsystem weiter bearbeitet wurden. Bei geänderten Objekten(ChangeMode=’change’) muss darauf geach-tet werden, dass keine Änderungen über-schrieben werden und dadurchPlanungsergebnisse verloren gehen. Auch beigelöschten Objekten (ChangeMode=’delete’)ist Vorsicht geboten, wenn diese inzwischenmit Planungsdaten verknüpft wurden, dienicht automatisch mit gelöscht werden dür-fen. Der Empfänger der Daten muss für dieWiedererkennung von importierten Objektenaus vorherigen Iterationen auf jeden Fall dieID-Zuordnungstabelle aufheben, welche alleZuordnungen zwischen AutomationML-Ob-jekt IDs (GUID) und System-Objekt IDs enthält.

Es kann vorteilhaft sein, für den Vergleich von Änderungen dasschon existierende Systemobjekt zunächst in ein Automati-onML-Objekt zu transformieren, um den Vergleich auf Basiseines einheitlichen Formats durchführen zu können. Bild 3 zeigteinen Lebenszyklus eines AutomationML-Objektes über meh-rere Iterationsstufen. Im Beitrag zum Thema Datenkonsistenz[1] skizzieren die Autoren ein Systemkonzept für ein systemun-abhängiges Werkzeug, das auf Grundlage der AutomationML-Dokumente und der enthaltenen Absender- undÄnderungsinformationen die Datenkonsistenz in solchen Engi-neering Workflows überwachen und unterstützen kann. Roundtrip Engineering Der Workflow des Roundtrip Engineer-ing stellt eine Erweite-rung des Iterativen-Engineerings dar und erlaubt das Ändernund Zurücksenden von importierten Daten an das Ursprungs-werkzeug. Im Engineering tritt der Fall häufig auf, beispiels-weise wenn ein generisches Objekt oder generische Merkmale

Bild 2: Organisation der Dateiverwaltung

Bild: inpro Innovationsgesellschaft m

bH

Bild: inpro Innovationsgesellschaft m

bH

Bild 3: Lebenszyklus eines AutomationML-Objektes im iterativen Engineering

39

eines Objektes spezifiziert werden, um den spezifizierten Wertdanach in allen weiteren Planungsschritten benutzen zu kön-nen. Ein Beispiel hierfür wäre die Kalkulation eines Zeit- oderKostendatums durch ein spezifisches Kalkulationstool. Auchin diesem Fall kann der Datenaustausch zwischen den Werk-zeugen wiederholt stattfinden (Bild 4). In diesem Fall besitztjedes der beteiligten Systeme sowohl Export- als auch Import-Funktionen und eine Möglichkeit zur Verwaltung der AutomationML-Dokumente und Zuordnungstabellen. Der Da-tenexport, den das Zielsystem durchführt, ist aber restriktiverals der Datenexport des Quellsystems. Das Zielsystem generiertbeim Export AutomationML-Objekte, die an vorher eingele-sene AutomationML-Objekte angefügt werden. Das generierteAutomationML-Dokument enthält daher immer Automati-onML-Objekte, die auch in der zuerst importierten Automati-onML-Datei enthalten waren. Idealerweise wird dafür dasselbeAutomationML-Dokument, das vorher empfangen wurde, ge-nutzt. Nur so kann der ursprüngliche Sender erkennen, welche

Objekte in der zurückkommenden Datei geändert/erweitertwurden. Zur Gewährleistung der Datenkonsistenz kann es bes-ser sein, die Originalobjekte nicht direkt zu verändern, sondernKopien zu erzeugen, zu verändern und als Revisionen bzw.Versionen des Originalobjektes zu versenden. AutomationMLenthält mehrere Konzepte für das Roundtrip Engineering. DerDatenerzeuger und Versender kann einem Empfänger Vorga-ben für die Spezifikation mitgeben, indem er AutomationML-Objekte mit ‘RoleRequirements’ und ‘Attribute-Constraints’assoziiert. Der Empfänger kann Spezifikationen durch ‘Verfei-nerungen’ und ‘Klassen-Instanz-Relationen’ mit entsprechen-den spezifischen Klassenbibliotheken definieren. Für dieÄnderung von Objekten durch den Empfänger sind das ‘Chan-geMode’-Attribut und das ‘Versions- und Revisionskonzept’nutzbar. Das Integrieren der zurückkommenden Daten erfolgtin ähnlicher Weise, wie im unidirektionalen iterativen Enginee-ring. Für die Integration wird die Änderungsinformation, dieentweder direkt durch das Setzen des ‘ChangeMode’-Attribu-tes oder durch ‘Versions-’ und ‘Revisionsobjekte’ angegebenist, ausgewertet, mit den vorhandenen Daten verglichen undin den vorhandenen Datenbestand eingefügt. Fazit Mit den ausdrucksstarken Beschreibungskonzepten von Auto-mationML ist es möglich, auch für lose gekoppelte Systeme einÄnderungs- und Versionsmanagement für definierte Enginee-ring-Workflows zu implementieren. Die in diesem Beitrag dar-gestellten Konzepte und Workflows können auch für einenVerbund von mehreren Werkzeugen einzeln oder in Kombina-tion verwendet werden. Weiterhin hat der Beitrag verdeutlicht,dass mit AutomationML-Dokumenten die Realisierung eineszentralen Datenpools für die redundanzfreie Verwaltung von

Engineering-Daten möglich ist. Für diesen Fall müssen die be-schriebenen Modellierungskonzepte des Formates zur Ände-rungs- und Versionskontrolle genutzt und darüber hinaus musslediglich eine wechselseitige Zugriffskontrolle für die genutztenAutomationML-Dokumente implementiert werden. �

Literatur [1] R. Drath, B. Schröter, M. Hoernicke, Datenkonsistenz im Um-feld heterogener Engineering-Werkzeuge in VDI Automation2011.

www.automationml.orgBild 4: Roundtrip Engineer-ing

Bild: inpro Innovationsgesellschaft m

bH

Autor: Dr.-Ing. LorenzHundt, Projektingenieur Produktionssyst. und Infor-mationsprozesse, inpro Innovationsgesellschaft mbH

Autor: Josef Prinz, Senior-Experte Digitale Fabrik,inpro Innovationsgesell-schaft mbH

40

Analyse Fabrik-planung

Funkti- onales Engineer- ing

Instal-lation

Inbetrieb-nahme

Betrieb

Bild 1: Allgemeiner Anlagenentwurfsprozess

Bild: Otto-von-Guericke-Universität Magdeburg

Die Planung, das 'Engineeren', einer Anlage für die Fertigungsindustrie oder die Prozessindustrie ist ein ressour-cenintensiver und komplexer Prozess, an dem unterschiedliche ingenieurstechnische Disziplinen beteiligt sind.Dabei erfolgt die Planung anfangs recht grob und wird mit Fortschritt im Entwurfsprozess stetig detaillierter. DasAnlagenverhalten zum Beispiel wird anfangs mittels einfacher Aktivitäten modelliert, welche final in den Steue-rungscode gipfeln. Bei diesem Prozess der kontinuierlichen Informationsanreicherung setzen Ingenieure ein ge-wisses Vertrauen in die Korrektheit der an sie übergebenen Daten − diese werden nicht noch einmal bis ins Detailüberprüft. Irren ist jedoch menschlich.

Serie AutomationML Teil 12: Validierung von Verhalten in unterschiedlichen Phasen des Anlagenentwurfs

AutomationML verbindet Software-Werkzeuge

Fehler sollten früh gefunden werden. Es gilt: Je früher einFehler gefunden wird, desto geringer ist der Aufwandfür dessen Behebung. Ist es da nicht sinnvoll, die Daten

zu überprüfen, bevor sie weitergegeben werden? Bezogenauf das Anlagenverhalten: ob das modellierte Verhalten demBeabsichtigten entspricht?

Welche Informationen werden benötigt?

Um das Anlagenverhalten simulativ überprüfen zu können, be-darf es grundsätzlich folgender Informationen:

Die Anlagenstruktur: Welche Produktionsressourcen werden verwen-•det 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 ausder Geometrie und Mechanik der einzelnen Produktionsres-sourcen zusammen, deren Anordnung mit der Anlagenstruk-tur beschrieben wird. Um nun das Verhalten dieserKomposition der Produktionsressourcen simulieren zu kön-nen, muss jede Produktionsressource selbst mit modulspezi-fischem Verhalten versehen werden.

41

Wo ist das einsetzbar?

Die Planung einer Anlage kann im Allgemeinen in sechs Phaseneingeteilt werden (siehe Bild 1). In welcher Phase bietet sicheine simulative Überprüfung des Verhaltens an? Und was kannda konkret überprüft werden? In der Fabrikplanungsphase wirddas Anlagenverhalten grob beschrieben − meist mithilfe einfa-cher Modelle, wie Gantt oder PERT Charts. An dieser Stellekann überprüft werden, ob sich das Produkt mit den festge-legten Fertigungsschritten mit den gewählten Produktionsres-sourcen fertigen lässt. Innerhalb des funktionalen Engineeringsliegen bereits detailliertere Verhaltensbeschreibungen vor, z.B.in Form von Impulsdiagrammen: Werden bei Eingang bestimm-ter Sensorsignale die richtigen Aktoren angesteuert? Es lässtsich damit überprüfen, ob die Signalabfolgen überhaupt reali-sierbar sind. Während der virtuellen Inbetriebnahme (Teil desfunktionalen Engineerings), die sich kurz vor dem eigentlichenAufbau der Anlage befindet, also zu einem Zeitpunkt, in demdie Anlage komplett spezifiziert vorliegt, kann der Steuerung-scode auf Fehlerfreiheit geprüft werden.

Was ist dazu nötig?

Innerhalb des Anlagenentwurfsprozesses sind verschiedene in-genieurstechnische Disziplinen beteiligt, die jeweils ihre eigenen,an den Bereich optimierten Software-Werkzeuge verwenden.Aus diesem Grund macht es wenig Sinn, ein neues Werkzeugzu entwickeln, das eine Verhaltensvalidierung zu unterschiedli-chen Zeitpunkten der Planung zulässt. Innerhalb der Forschungs-anstrengungen der Otto-von-Guericke-Universität Magdeburgfiel deshalb die Wahl auf die Entwicklung eines Simulations-Fra-meworks, das die Einbindung dieser bereichsspezifischen Werk-zeuge erlaubt. Um die zuvor genannten InformationsmengenBild 2: Schematische Darstellung des Simulations-Frameworks

Bild: Otto-von-Guericke-Universität Magdeburg

42

Anlegen oder Aufbereiten der mechatronischen Produktions-ressourcen ist erstmal ein Mehraufwand, der sich jedoch durchdie ermöglichte Wiederverwendung der Komponenten schnellamortisieren kann. Unternehmen können sich ‘hausinterne’ Si-mulations-Frameworks erstellen und somit ihre Engineering-Qualität und auch ihre Engineering-Effizienz steigern. �

Literatur

[1] R. Drath (Editor): Datenaustausch in der Anlagenplanungmit AutomationML, Springer Verlag, 2010.

www.automationml.org

Autor: apl. Prof. Dr.-Ing. habil.Arndt Lüder, Leiter Center Ver-teilte Systeme (CVS), Otto-von-Guericke Universität Magdeburg

Autorin: Nicole Schmidt, Wissen-schaftliche Mitarbeiterin CenterVerteilte Systeme (CVS), Otto-von-Guericke Universität Magdeburg

erzeugen bzw. verarbeiten zu können, werden folgende Werk-zeuge bzw. Werkzeugfunktionen benötigt:

3D-Visualisierung•Verhaltensdesign•3D-Simulation•Verhaltenssimulation•

Mittels einer zuvor erstellten mechatronisch orientierten Kom-ponentenbibliothek, in der zu jeder Produktionsressource so-wohl die Geometrie und Mechanik als auch das Verhalten desModuls hinterlegt ist, kann in der Software zur 3D-Visualisie-rung die Anlagenstruktur durch Komposition der Produktions-ressourcen modelliert werden. Das modulspezifischeVerhalten (modelliert in dem Werkzeug zum Verhaltensde-sign) ist jedoch so erstellt, dass es entsprechend der drei identifizierten Anwendungsfälle Einstiegs- bzw. Ansteuer-möglichkeiten für das Anlagenverhalten gibt. Es ergeben sichdrei Ebenen, auf denen die Produktionsressourcen angesteu-ert werden können. Somit können sie je nach Detaillierungs-grad des Anlagenverhaltens, das durch den Ingenieur mit derSoftware zum Verhaltensdesign erstellt wird, angesteuertwerden. Das modulspezifische Verhalten, egal auf welcherEbene, braucht allerdings auch auf der Seite der digitalen 3D-Repräsentation Anknüpfungspunkte (modelliert im Werkzeugzur 3D-Visualisierung), so dass sich die Produktionsressourcebei deren Ansteuerung entsprechend ‘bewegt’. Damit sindalle notwenigen Informationen vorhanden, um das Anlagen-verhalten in den Werkzeugen zur 3D- und Verhaltenssimula-tion simulieren zu können. Bild 2 zeigt schematisch dasentwickelte Simulations-Framework. Um für die simulativeVerhaltensvalidierung eine konsistente Informationsweiter-gabe zwischen den beteiligten Werkzeugen sicherzustellen,ist AutomationML als Datenaustauschformat sehr gut geeig-

net. Neben der mechatronisch orientierten Komponentenbi-bliothek kann in AutomationML auch die Projektdatei mitdem Anlagenverhalten und der Anlagenstruktur, die die ver-wendeten mechatronischen Produktionsressourcen beinhal-tet, konsistent geführt werden. Dabei werden die Strukturenmittels CAEX abgebildet: die Komponentenbibliothek als ‘Sys-temUniClassLib’ und die Projektdatei in der ‘InstanceHierar-chy’. Das Anlagenverhalten sowie das jeweiligemodulspezifische Verhalten werden mithilfe von PLCopenXML abgebildet und die Geometrie- und Mechanikinforma-tionen in Collada abgelegt, wie es in [1] beschrieben ist.PLCopen XML und Collada werden dabei als externe Dateienaus dem AutomationML Dachformat CAEX heraus referen-ziert. Besitzen die Werkzeuge jedoch selbst keine Automati-onML- Schnittstelle, müssen entsprechende Konverter zurVerfügung stehen. Innerhalb der Forschungsarbeiten wurdedas Simulations-Framework prototypisch mit Software vonKW-Software (Multiprog für das Verhaltensdesign, Proconosfür die Verhaltenssimulation) und tarakos (taraVRbuilder fürdie 3D-Visualisierung, taraVRcontrol für die 3D-Simulation)umgesetzt.

Fazit

Das Datenaustauschformat AutomationML ist gut dafür geeig-net, das modulare, erweiter- und anpassbare Simulations-Fra-mework zu realisieren, mit dem Anlagenverhalten in denverschiedenen Phasen des Planungsprozesses von Anlagen aufseine Fehlerfreiheit überprüft werden kann. So kann der Inge-nieur vor Weitergabe seiner Daten noch einmal überprüfen, obdas modellierte Verhalten dem beabsichtigten Verhalten ent-spricht oder auch dazu nutzen, anderen Mitarbeitern das inten-dierte Anlagenverhalten zu veranschaulichen. Das einmalige

43

Bild 1: In AutomationML bisher abgebildete Informationsmengen

Bild: O

vG-Universität M

agdeburg

Im Jahre 2006 startete die AutomationML-Initiative mit dem Ziel, ein Datenaustauschformat zu schaffen, das dieEntwurfswerkzeuge des Lebenszyklus eines Produktionssystems verbinden kann. Damit sollte dem Bedarf nachverlustfreiem Datenaustausch und damit der Reduzierung von wiederholten Entwurfsschritten in verschiedenenWerkzeugen und von Fehlern nachgekommen werden. Jetzt, acht Jahre später und durch den 2009 gegründetenAutomationML e.V. gepflegt, hat sich AutomationML als Technologie für den Datenaustauschprozess etabliertund weitere Anwendungen kommen stetig hinzu.

Serie AutomationML Teil 13: Der Stand dessen, was erreicht wurde,und die weiteren Entwicklungsschritte

AutomationML − Erreichtes und Zukünftiges

In den letzten zwölf Beiträgen dieser Serie wurden nebentechnologischen Grundlagen auch Anwendungen und Nut-zungshinweise beschrieben. In diesem Artikel sollen nun der

Stand des Erreichten zusammengefasst und die nächsten Ent-wicklungsschritte angedeutet werden.

Abgedeckte Informationsmengen

Grundidee der Automation Markup Language, oder kurz derAutomationML, ist die synergetische Kombinierbarkeit aller In-formationsinhalte, die im Entwurfsprozess von Produktionssys-temen relevant sind und zwischen Entwurfswerkzeugenausgetauscht werden sollen. Dabei wurden anfänglich vorran-gig Informationen zur Anlagentopologie, zur Geometrie und Ki-nematik und zu steuerungstechnischem Verhalten untersucht.In der Zwischenzeit ist die abbildbare Informationsmenge starkangestiegen, was Bild 1 verdeutlicht. Neben den klassischen In-formationsmengen der Mechanikkonstruktion (Anlagentopolo-gie, Geometrie, Kinematik), der Roboterprogrammierung(Anlagentopologie, Geometrie und Kinematik, steuerungstech-nisches Verhalten) und der Steuerungsprogrammierung (Anla-gentopologie, steuerungstechnisches Verhalten) kamen in den

44

letzten Jahren Informationen für die Beschreibung von Netz-werken sowohl für die Beschreibung von Kommunikationsnet-zen als auch für elektrische, hydraulische oder pneumatischeNetze, die konsistente Beschreibung von Anlagenbausteinen fürden mechatronischen Entwurf und die virtuelle Inbetriebnahmeund die Beschreibbarkeit von grundlegenden betriebswirtschaft-lich relevanten Eigenschaften (z.B. für den Einkauf) hinzu. Damitkann AutomationML prinzipiell die gesamte grundlegende In-formationsmenge, die im Entwurfsprozess eines Produktions-systems relevant ist, abbilden.

Bestehende Anwendungen

Für die meisten der Entwurfsschritte im Entwurfsprozess konnteder Nachweis der Nutzbarkeit von AutomationML bereits in Pi-lotanwendungen erbracht werden. In einigen Anwendungsbe-reichen ist bereits die ‘Serienreife’ erreicht, das heißt, dasDatenformat hat den produktiven Einsatz erreicht. Bild 2 gibt

das anschaulich wieder. Je grüner hier der Entwurfsschritt dar-gestellt ist, desto weiter ist die Anwendung von AutomationMLfortgeschritten. Einige der Anwendungshighlights sind die fol-genden:

Bei den Firmen Daimler und Audi wurden im Jahre 2013 umfassende•Teile neuer Anlagen zur Produktion von PKW-Karosserien virtuell inBetrieb genommen. Dazu hat z.B. die Firma Rücker EKS eine entspre-chende, auf AutomationML basierte Werkzeugkette entwickelt, dieproduktiv im Einsatz ist. Die Firma Lenze nutzt AutomationML zum Datenaustausch beim Ent-•wurf von Antriebssträngen und hat es dazu in den Drive Solution De-signer integriert.ABB nutzt AutomationML im Rahmen seines Werkzeuges ‘RobotStu-•dio’. Hier werden notwendige Geometrie- und Kinematikinformatio-nen für die Roboterprogrammierung und -simulation ausgetauscht.

Neben diesen produktiven Anwendungen sind bereits in Pilo-ten beim Fraunhofer IOSB, bei der tarakos GmbH, der Univer-sität Magdeburg und der Cenit AG (um nur einige zu nennen)nachgewiesen worden, dass die Layoutplanung, die Mecha-

nikkonstruktion, die Erreichbarkeitssimulation und der Leitsys-tementwurf entsprechend unterstützt werden können. Fürden Netzwerkentwurf, die Elektrokonstruktion und die Steue-rungsprogrammierung sind entsprechende Pilotanwendungenderzeit in der Umsetzung.

Besondere Vorteile

In den verschiedenen Anwendungen und Piloten kommt eineder wichtigsten Eigenschaften des AutomationML-Datenforma-tes zum Tragen: die semantische Flexibilität und Erweiterbarkeit.Dazu nutzt AutomationML eine Struktur mit drei Bibliotheksty-pen. Insbesondere die Rollenklassenbibliotheken (RoleClassLib)und die Komponentenbibliotheken (SystemUnitClassLib) er-möglichen eine anwendungsfallspezifische Erweiterung der aus-tauschbaren Semantiken. Hier können standardisierte und nochnicht standardisierte/ private Inhalte koexistieren und gemein-sam eindeutig ausgetauscht werden. Dazu können Werkzeug-schnittstellen anwendungsfallspezifisch konfiguriert und deraktuelle Anwendungsfall über globale Projektattribute erkanntwerden. Bild 3 zeigt dazu eine übliche Projektstruktur. Damitlöst AutomationML eines der wichtigsten Probleme der Stan-dardisierung: das wechselseitige Warten von Werkzeugentwick-lern und Anwendern. Es muss nicht mehr die ‘großestandardisierte Lösung’ abgewartet werden. Bereits mit kleinenstandardisierten Bausteinen, die wichtige Probleme lösen kön-nen, kann produktiv gearbeitet werden. Diese ‘kleinen Lösun-gen’ können bei Erfolg erweitert und standardisiert werden.

Standardisierung

Einen wichtigen Teil der Arbeiten des AutomationML e.V. bil-det neben der eigentlichen Weiterentwicklung und Verbrei-

Bild 2: Entwicklungsstand von AutomationML

Bild: OvG-Universität Magdeburg

45

tung des AutomationML-Datenformates auch dessen interna-tionale Standardisierung. Diese erfolgt in sehr enger Zusam-menarbeit mit der Arbeitsgruppe ‘Engineering’ der DeutscheKommission Elektrotechnik Elektronik Informationstechnik(DKE) und der Workgroup 9 des SC 65 E der InternationalElectrotechnical Commission (IEC). Um eine schnelle Standar-disierung zu erreichen, wird dabei eine Normenreihe entwi-ckelt, die unter dem Titel ‘Engineering data exchange formatfor use in industrial automation systems engineering − Auto-mation Markup Language’ steht und die ProjektnummerIEC62714 besitzt. Bisher sind mit den Teilen für die Beschrei-bung der grundlegenden Architektur, die Nutzung von Biblio-theken, die Geometrie- und Kinematikbeschreibung, die

Verhaltensbeschreibung und die Beschreibung von Kommuni-kationsnetzwerken fünf Teile geplant. Es wird aber mit Sicher-heit weitere Teile geben. Bild 4 zeigt den derzeit erreichtenEntwicklungsstand. Dabei kann stolz vermeldet werden, dassnach nur acht Jahren Entwicklungszeit der erste Teil der IEC-Reihe den Status einer internationalen Norm erreicht hat. Dieanderen werden in schneller Abfolge folgen.

Kooperationen

Von Anfang an wurde an die Entwicklung des AutomationML-Datenformates der Anspruch gestellt, das Rad nicht noch ein-mal zu erfinden. Bestehende und erprobte Technologien zu

erkennen und passend zu kombinieren machten es möglich, dieEntwicklung schnell voranzutreiben. Dazu waren und sind Ko-operationen mit anderen Organisationen sinnvoll, die bereitsTechnologien entwickelt haben, die für AutomationML von Nut-zen sein können. Begonnen hat dieses Modell mit den erfolg-reichen Kooperationen mit der Khronos Group zur Anpassungund Integration des Collada-Datenformates für die Geometrieund Kinematikbeschreibung sowie mit der PLCopen zur Nutz-barmachung des PLCopen XML- Datenformates für die Verhal-tensbeschreibung. Im Jahre 2013 kamen drei weitereKooperationen hinzu. Gemeinsam mit dem eCl@ss e.V. wird diesemantische Eindeutigkeit von beschriebenen Anlagenobjektenverbessert. Dazu werden entsprechende Methoden zur Rollen-klassendefinition aus eCl@ss-Katalogen entwickelt. In Koope-ration mit der OPC Foundation wird die Übertragung vonAutomationML-Projekten mittels OPC UA untersucht. Ein wei-terer Blick auf die Beschreibung von Geometrie und Kinematikerfolgt gemeinsam mit dem ProStep iViP e.V.

Aktuelle Arbeiten

Neben den genannten Arbeitsgebieten zur semantischen Ein-deutigkeit von beschriebenen Anlagenobjekten, zur Nutzungvon OPC UA und zu anderen Mitteln für die Beschreibung vonGeometrie und Kinematik werden im AutomationML e.V. der-zeit noch weitere wichtige Themenstellungen bearbeitet.Diese betreffen z.B. die Sicherstellung von Datensicherheitbeim Datenaustausch (insbesondere über Mittel der Ver-schlüsselung und Authentifizierung), die Erweiterung derNutzbarkeit für die virtuelle Inbetriebnahme, die Beschreibungvon Produktionsprozessen, die konsistente Modellierung (me-chatronischer) Komponenten für den Anlagenbau und die Er-weiterung der Möglichkeiten zur Verhaltensbeschreibung

Bild: O

vG-Universität M

agdeburg

Bild 3: Grundlegende Struktur des AutomationML-Datenformates visualisiert im AutomationML Editor

46

über mathematische Formelsätze und Funktionsblocknetz-werke. In diesem Rahmen gibt es auch lose Zusammenarbei-ten mit dem VDA, der NAMUR und dem VDMA. Jedochkönnen interessierte Unternehmen jederzeit neue, für siewichtige Themenfelder initiieren oder sich in der Arbeit derbestehenden Themenfelder mit ihren speziellen Anwendungs-problemen engagieren. Sie sind sogar dazu aufgerufen, umdie Schlagkraft der Entwicklungen und ihre bereits hohe Ge-schwindigkeit weiter zu erhöhen. Informationen zur Mitarbeitfinden sich auf der Homepage des AutomationML e.V. unterwww.automationml.org/o.red.c/mitgliedschaft.html.

Nutzersupport

Da die Anwendung des AutomationML-Datenformates starkvon der Verbreitung entsprechender Export- und Import-schnittstellen in Entwurfswerkzeugen abhängt, bietet der Au-tomationML e.V. eine breite Palette von fachlicher undtechnischer Unterstützung für interessierte Anwender an.Neben dem in Bild 3 bereits gezeigten AutomationML-Editor,einem Werkzeug zur einfachen Erstellung von AutomationML-Beispielen, zum Erlernen des Datenformates und zum Testenvon Schnittstellen, stehen softwareseitig eine freie Bibliothek

für das Erstellen, Verändern und Speichern von Automati-onML-Projekten (die AutomationML Engine) und ein Testcen-ter zur Prüfung der Standardkonformität vonAutomationML-Projekten zur Verfügung. Beide können füreine schnelle und fehlerfreie Entwicklung von Schnittstellenverwendet werden. Um entsprechendes Wissen über die Nutz-barkeit von AutomationML in spezifischen Anwendungen unddas Aussehen entsprechender Strukturen zu verbreiten, hatder AutomationML e.V. eine Reihe von Veröffentlichungensowie von Anwendungsbeispielen bereitgestellt. Beides, dieverfügbare Software und die Veröffentlichungen und Beispielestehen unter www.automationml.org/o.red.c/dateien.htmlzum Download bereit. �

www.automationml.org

Bild 4: Stand der Standardisierung des AutomationML-Datenformates

Bild: O

vG-Universität M

agdeburg

Autor: apl. Prof. Dr.-Ing. habil.Arndt Lüder, Leiter Center Ver-teilte Systeme (CVS), Otto-von-Guericke- UniversitätMagdeburg

Autorin: Nicole Schmidt, Wis-senschaftliche MitarbeiterinCenter Verteilte Systeme (CVS)Otto-von-Guericke-UniversitätMagdeburg