Datenaustausch in der Anlagenplanung mit AutomationML: Integration von CAEX, PLCopen XML und COLLADA [1 ed.] 3642046738, 9783642046735 [PDF]

Zitiervorschau

Datenaustausch in der Anlagenplanung mit A utomationML

Rainer Drath Herausgeber

Datenaustausch in der Anlagenplanung mit AutomationML Integration von CAEX, PLCopen XML und COLLADA

1  3

Herausgeber Dr.-Ing. Rainer Drath ABB Forschungszentrum Ladenburg Wallstadter Str. 59 68526 Ladenburg Deutschland [email protected]

ISBN 978-3-642-04673-5     e-ISBN 978-3-642-04674-2 DOI 10.1007/978-3-642-04674-2 Springer Heidelberg Dordrecht London New York Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. Alle Grafiken/Abbildungen, die unter Verwendung der Software XMLSpy, Copyright 2003-2009 Altova GMBH erstellt wurden, erscheinen mit freundlicher Genehmigung der Altova GmbH. © Springer-Verlag Berlin Heidelberg 2010 Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Einbandentwurf: WMXDesign GmbH, Heidelberg Gedruckt auf säurefreiem Papier Springer ist Teil der Fachverlagsgruppe Springer Science+Business Media (www.springer.com)

Vorwort

Vorwort von Prof. Alexander Fay Ingenieurwissenschaftliche Bücher behandeln im Allgemeinen technische Lösungen oder Methoden, um technische Lösungen zu erstellen. Das vorliegende Buch aber behandelt ein Beschreibungsmittel zum Austausch von Engineering-Daten. Ein ungewöhnliches Thema, aber ein wichtiges und lohnendes, nimmt doch der Anteil des Engineering-Aufwands bei der Konzeption und Realisierung von Maschinen und Anlagen stetig zu. Das Engineering als arbeitsteiliger und zunehmend regional verteilter Arbeitsprozess erfordert Mechanismen zur Sicherstellung einer konsistenten Datenbasis, auf die alle Projektbeteiligten Zugriff haben, idealerweise unabhängig davon, welche Engineering-Werkzeuge sie für die Bearbeitung ihres Anteils am Gesamtprojekt nutzen und in welcher Weise die Daten persistent gespeichert werden. Bislang dominieren noch proprietäre Datenformate bestimmter Engineering-Werkzeuge, aus denen heraus die Engineering-Daten nur verlustbehaftet in andere Werkzeuge übertragen werden können. An dieser Stelle setzt AutomationML an: es bietet einen definierten, strukturierten Rahmen und die informationstechnischen Mittel, um verschiedene Sichten auf eine zu automatisierende Anlage in einem konsistenten Modell zu beschreiben. Dieses Modell kann gewerke-übergreifend erstellt und genutzt werden. Insbesondere erlaubt es eine werkzeug-unabhängige Beschreibung der Dynamik einer Anlage, sowohl der möglichen Bewegungen aller geometrischen Elemente (Kinematik) als auch der gewollten Bewegungen, d. h. der gewünschten Bewegungsfolgen, die durch die Automatisierungstechnik zu realisieren und sicherzustellen sind. Aus automatisierungstechnischer Sicht sind damit alle Informationen gegeben, um die Automatisierungslösung zielgerichtet zu erstellen. Doch AutomationML nützt nicht darüber hinaus allen anderen am Anlagenprojekt Beteiligten, die sich einen Eindruck vom späteren Anlagenverhalten verschaffen wollen. Der große Vorteil von AutomationML liegt darin, dass hierin verschiedene bereits in ihrem Anwendungsgebiet bewährte aktuelle Standards miteinander kombiniert werden. Das Rückgrat bildet CAEX (Computer Aided Enginering eXchange) gemäß IEC 62424 als objektorientiertes statisches Anlagenmodell, in das Geometrie- und Kinematik-Beschreibungen nach COLLADA (COLLAborative Design 

vi

Vorwort

Activity) und Verhaltensbeschreibungen entsprechend PLCopen XML integriert und miteinander verknüpft werden. So konnte AutomationML durch ein engagiertes Team innerhalb erstaunlich kurzer Zeit zu beachtlicher Reife entwickelt werden. Auf dieser Basis haben die AutomationML-Partner bereits gezeigt, wie Beschreibungen roboterbasierter Fertigungszellen zwischen verschiedenen Software-Werkzeugen ausgetauscht werden können. AutomationML hat das Potential, den Datenaustausch im Anlagenbau signifikant zu vereinfachen, zum Nutzen von Engineering-Dienstleistern, Anlagenbauern, Anlagenbetreibern und Herstellern. Allen, die wissen wollen, wie sie an dieser Entwicklung partizipieren können, sei dieses Buch sehr empfohlen. Institut für Automatisierungstechnik Helmut-Schmidt-Universität Hamburg Hamburg, im Juli 2009

Prof. Dr.-Ing. Alexander Fay

Vorwort von Anton Hirzle Die Komplexität und der Kostendruck in der Automatisierungstechnik nehmen ständig zu. Ein wichtiges Mittel zur Beherrschung beider Herausforderungen ist die Standardisierung der Komponenten, Systeme und Prozesse. Das Engineering einer automatisierten Fertigungsanlage nimmt derzeit rund 40–50% des Investments im steuerungstechnischen Bereich in Anspruch. Deshalb erscheint es besonders lohnend, diesen kostenintensiven Prozess genauer zu untersuchen. Hierbei stellt man schnell fest, dass ein erheblicher Anteil des Aufwands auf das Übertragen der Inhalte von einem Tool zum anderen anfällt. So kann man beispielsweise als Projektingenieur der Steuerungstechnik nicht ohne weiteres auf die Inhalte der vorgelagerten Planungsphase der „Digitalen Fabrik“ zugreifen, um diese in den folgenden Engineering-Schritten weiter zu detaillieren. Die Übertragung von kinematisierten 3D-Daten ist mit bislang verfügbaren offenen Datenformaten gar nicht möglich – hier müssen die Ingenieure aufwändig Hand anlegen. Eine Untersuchung der verfügbaren Datenformate im Jahre 2006 zeigte, dass es zu dieser Zeit kein durchgängiges und gleichzeitig frei verfügbares Datenformat gab. Im selben Jahr initiierte Daimler die Bildung einer Arbeitsgruppe, bestehend aus namhaften Firmen der Fertigungsindustrie, die selbst Toolhersteller und Betroffene im Engineering-Prozess waren, mit dem Ziel ein durchgängiges, neutrales Datenformat zu entwickeln. Mittlerweile ist aus dieser einst geschlossenen Arbeitsgruppe ein Industrieverein entstanden, der jedem interessierten Unternehmen die Möglichkeit bietet, sich als Mitglied an der Weiterentwicklung des Formats zu beteiligen. AutomationML stellt dabei einen ganzheitlichen Ansatz dar. Das Besondere dabei ist die Kombination bewährter Datenformate, die frei zugänglich und etabliert sind – und nicht die Neuerfindung eines Datenformats. Da sich die Toolhersteller

Vorwort

vii

auf die Leistungsmerkmale ihrer Werkzeuge und nicht auf den Datenaustausch konzentrieren wollen, stellte es auch nie ein Problem dar, dass teilweise direkte Wettbewerber gemeinsam an einem Tisch saßen. Alle hatten die gleichen Probleme beim Datentransfer und -handling. AutomationML soll die enge Bindung von Engineering-Daten an ihre Werkzeuge lösen. Durch AutomationML wird dem Anwender die Möglichkeit eröffnet, stets das Tool zu nutzen, welches für seine Aufgabe am besten geeignet ist, anstatt für ihn fremde, kostenintensive Tools seiner Auftraggeber mittragen zu müssen. Das Ziel ist, keine Inhalte mehr von Tool zu Tool händisch zu übertragen. Vorarbeiten z. B. aus der Digitalen Fabrik sollen mit AutomationML nahtlos genutzt und weiter ausdetailliert werden können. AutomationML ermöglicht somit Ingenieurbüros, wettbewerbsfähig zu bleiben und weiterhin mit spezialisierten, kleinen aber leistungsfähigen Tools am Markt teilzuhaben. Für den Anlagenbauer bzw. den Anlagenbetreiber ist eine erhebliche Qualitätssteigerung möglich, da im Engineering-Prozess durch Automatismen und den Wegfall des händischen Übertragens der Inhalte nun viel weniger Fehler auftreten. Nicht zuletzt stellt AutomationML die Möglichkeit einer effizienten Darstellung der „Virtuellen Inbetriebnahme“ dar. AutomationML ist in der Fertigungsindustrie entstanden, aber nicht auf diese beschränkt. So ist der Einsatz in der Prozessindustrie, Luft- und Raumfahrt, Energieerzeugung und -verteilung ebenso denkbar. Alle Interessenten sind herzlich eingeladen, hier mitzuarbeiten. Das vorliegende Buch bietet sowohl Managern, Entwicklern als auch Anwendern einen Einblick in die Möglichkeiten und den Nutzen von AutomationML. Senior Manager  Automation Technology and Simulation Daimler AG

Anton Hirzle

Danksagung

Das vorliegende Buch entstand in der Zeit vom Sommer 2008 bis Sommer 2009 und wäre ohne die tatkräftige Arbeit aller Mitautoren nicht zustande gekommen - an dieser Stelle möchte ich mich herzlich bei ihnen bedanken. Eine Besonderheit von AutomationML färbt auch auf dieses Buch ab: Wettbewerber sitzen an einem Tisch, entwickeln gemeinsam ein offenes Datenformat und schreiben ein Buch darüber. Dieser Geist ist spürbar: die Schwerpunkte von AutomationML werden aus der Sicht verschiedener Firmen, Branchen und Anwendungen heraus offen beleuchtet. Dies bietet dem Leser eine Fülle von Ansatzpunkten. Besonders danken möchte ich Michael Lebrecht und Alexander Alonso Garcia, die das Thema AutomationML ins Leben gerufen haben und bis heute leiten. Eine wichtige Rolle spielte dabei Dirk Weidemann, der mit bemerkenswerter Professionalität und viel Humor das AutomationML-Projektmanagement unterstützte. Ich danke zudem ganz besonders Steffen Lips, der mit außergewöhnlichem Engagement in seiner Freizeit das Thema Geometrie und Kinematik bearbeitet, anschaulich niedergeschrieben und zudem mit einem Werkzeug zur Konvertierung von Geometrien und Kinematiken bereichert hat. Weiterhin möchte ich an dieser Stelle auch allen anderen danken, die durch fachliche Diskussionen einen Beitrag zum Gelingen dieser Arbeit geleistet haben. Besonders zu erwähnen sind dabei Volker Miegel, Sönke Kock, Christian Zeidler, Georg Gutermuth, Anton Hirzle, Christoph Winterhalter und Michael John, die das Thema AutomationML aus den verschiedenen Aspekten heraus zu beleuchten und voranzubringen verstanden und durch eine Vielzahl von Gesprächen und Ideen unterstützt und bereichert haben. Dies gilt ebenso für Josef Prinz von INPRO, der seine Arbeiten zur Bewertung von AutomationML und zur Kombination mit der NE 100 zur Verfügung gestellt hat. Speziell möchte ich mich bei Prof. Epple und Prof. Fay bedanken, die das drängende Thema des Datenaustausches zwischen den Phasen des Engineering bereits vor Jahren erkannt und das Thema vielfältig und fortwährend befruchtet haben. Von besonderem Wert für AutomationML sind die Softwarewerkzeuge und zugehörige Dokumentationen, die u. a. von Malte Pirsch, Sebastian Breithor, Steffen Lips und Michala Weisensee erstellt wurden – sie waren die Grundlage für die Entwicklung, Überprüfung und Vermittlung vieler AutomationML-Aspekte. Mit dem ix



Danksagung

kostenfrei zur Verfügung gestellten AutomationML-Editor, der AutomationML-Engine sowie Konverterwerkzeugen wird nicht nur die Tragfähigkeit von AutomationML untermauert, sondern zudem eine dokumentierte Referenzimplementierung vorgestellt, die Werkzeugherstellern beim Entwickeln von AutomationML-Schnittstellen helfen kann. Einen ganz persönlichen Dank möchte ich jedoch den Familien und Ehepartnern aller Mitautoren aussprechen, die an vielen Wochenenden und Abenden ihre Unterstützung gegeben und Freiräume für die Arbeit an diesem Buch geschaffen haben. Dies gilt insbesondere für Susanne Brzezinski, die zusätzlich als externe Reviewerin sowohl das Buch als auch den Herausgeber mit vielen wertvollen Hinweisen und ausgezeichnetem Gespür für Sprache sehr bereichert hat. Dr.-Ing. Rainer Drath, Herausgeber

Inhaltsverzeichnis

1  Einleitung ��������������������������������������������������������������������������������������������������     1 Dirk Weidemann und Rainer Drath 1.1 Lesefahrplan: welche Kapitel Sie nicht lesen müssen ����������������������     1 1.2 Motivation und Problembeschreibung ����������������������������������������������     2 1.2.1 Motivation ������������������������������������������������������������������������������     2 1.2.2 Problembeschreibung ������������������������������������������������������������     3 1.2.3 Ansätze ����������������������������������������������������������������������������������     6 1.3 Initiatoren ������������������������������������������������������������������������������������������    9 1.4 Ziele von AutomationML ������������������������������������������������������������������   10 1.4.1 Übersicht ��������������������������������������������������������������������������������   10 1.4.2 Offenheit ��������������������������������������������������������������������������������   12 1.4.3 Datenaustausch im Engineering ��������������������������������������������   12 1.4.4 Hoher Abdeckungsgrad ����������������������������������������������������������   13 1.4.5 Hohe Marktdurchdringung ����������������������������������������������������   14 1.4.6 Kombination bewährter Datenformate ����������������������������������   14 1.4.7 Erweiterbarkeit und Standardisierung ������������������������������������   15 1.4.8 Abgrenzung ����������������������������������������������������������������������������   15 1.5 Vergleich von Planungsprozessen ������������������������������������������������������   16 1.5.1 Ein typischer Planungsprozess in der Automobilindustrie ����   16 1.5.2 Ein typischer Planungsprozess in der Prozessindustrie ��������   19 1.5.3  Gemeinsamkeiten von Fertigungs- und Prozesstechnik ��������   22 1.5.4 Problematik heterogener CAE-Systeme ��������������������������������   23 1.6 AutomationML in a Nutshell: ein Architekturüberblick ��������������������   25 1.6.1 Architekturanforderungen und Architekturübersicht ������������   25 1.6.2 Beschreibung der Anlagentopologie ��������������������������������������   28 1.6.3 Geometrie- und Kinematikbeschreibung ������������������������������   30 1.6.4 Beschreibung von Abläufen und Verhalten ����������������������������   31 1.6.5 Schnittstellen- und Rollen-Bibliotheken ��������������������������������   33 1.6.6 Erweiterte AutomationML-Konzepte ������������������������������������   34 1.7 Anwendungen und Beispiele ��������������������������������������������������������������   35 1.8 Standardisierungsvorhaben ����������������������������������������������������������������   39 1.9 Möglichkeiten der Mitgestaltung ������������������������������������������������������   42 Literatur ������������������������������������������������������������������������������������������������������   43 xi

xii

Inhaltsverzeichnis

2  Grundarchitektur: das Objektmodell ����������������������������������������������������   Rainer Drath und Miriam Schleipen 2.1 Die Architektur von AutomationML ��������������������������������������������������   2.2  Ein Wort zur Objektorientierung in der Anlagenplanung ������������������   2.3 Einführung in CAEX ������������������������������������������������������������������������   2.3.1 Überblick über wesentliche CAEX-Elemente ����������������������   2.3.2 CAEX-Bibliotheken ��������������������������������������������������������������   2.3.3 Die Instanz-Hierarchie ����������������������������������������������������������   2.3.4 Das CAEX-Rollenkonzept ����������������������������������������������������   2.4 AutomationML-spezifische Festlegungen zu CAEX ������������������������   2.4.1 Drei Wege zum Umgang mit der Instanz-Hierarchie ������������   2.4.2 Objektidentifizierung ������������������������������������������������������������   2.4.3 Unterstützung mehrerer Rollen ����������������������������������������������   2.5 Beziehungen zwischen CAEX-Objekten ������������������������������������������   2.5.1 Überblick ��������������������������������������������������������������������������������   2.5.2 Vater-Kind-Relationen ����������������������������������������������������������   2.5.3 Vererbungsbeziehungen ��������������������������������������������������������   2.5.4 Klassen-Instanz-Relationen ��������������������������������������������������   2.5.5 Relationen zwischen Instanzen ����������������������������������������������   2.6 Referenzierung extern gespeicherter Informationen ��������������������������   2.6.1 Referenzierung von COLLADA- und PLCopen-XMLDaten ��������������������������������������������������������������������������������������   2.6.2 Relationen zwischen extern gespeicherten Informationen ����   2.7 AutomationML-Standardbibliotheken ����������������������������������������������   2.7.1 AutomationML-Schnittstellenbibliothek ������������������������������   2.7.2 AutomationML-Basis-Rollenbibliothek ��������������������������������   2.7.3 Fertigungstechnische Rollenbibliothek ����������������������������������   2.7.4 Leittechnische Rollenbibliothek ��������������������������������������������   2.8 Abbildung nutzerdefinierte Daten ������������������������������������������������������   2.8.1 Übersicht ��������������������������������������������������������������������������������   2.8.2 Nutzerdefinierte Attribute ������������������������������������������������������   2.8.3 Nutzerdefinierte SystemUnit-Klassen ����������������������������������   2.8.4 Nutzerdefinierte Rollenbibliotheken ��������������������������������������   2.8.5 Fazit ����������������������������������������������������������������������������������������   2.9 Erweiterte AutomationML-Konzepte ������������������������������������������������   2.9.1 Überblick ��������������������������������������������������������������������������������   2.9.2 AutomationML Port-Konzept ������������������������������������������������   2.9.3 AutomationML Facetten-Konzept ����������������������������������������   2.9.4 AutomationML Gruppen-Konzept ����������������������������������������   2.9.5 Kombination aus Gruppen- und Facetten-Konzept ������������     2.9.6 Ressource-Produkt-Prozess-Konzept ����������������������������������     2.10 Import und Export von AutomationML-Objekten ��������������������������     Literatur ����������������������������������������������������������������������������������������������������    

45 45 46 48 48 49 50 52 54 54 55 56 58 58 59 60 61 62 64 64 64 67 67 68 69 69 70 70 70 71 72 73 74 74 74 77 79 80 83 91 94

Inhaltsverzeichnis

xiii

3  Beschreibung von Geometrie und Kinematik mit COLLADA ����������     95 Steffen Lips 3.1  Übersicht zu COLLADA 1.5 ����������������������������������������������������������     95 3.2 Geometriebeschreibung ������������������������������������������������������������������     96 3.2.1 Einführung ��������������������������������������������������������������������������     96 3.2.2 Aufbau eines COLLADA-Dokuments ��������������������������������     97 3.2.3 Boundary Representation (BREP) ��������������������������������������    98 3.2.4 Tessellierte Geometrien ��������������������������������������������������������   103 3.2.5 Modellieren von Produktbäumen ����������������������������������������   107 3.2.6 Modellieren von Materialien ������������������������������������������������   108 3.2.7 Modellieren unterschiedlicher Detaillierungsgrade ������������   111 3.3 Kinematikbeschreibung ������������������������������������������������������������������   111 3.3.1 Anforderung an ein Kinematikbeschreibung ����������������������   111 3.3.2 Beschreibung von Gelenken ������������������������������������������������   112 3.3.3 Kinematische Modelle ��������������������������������������������������������   113 3.3.4 Abbildung von Formeln ������������������������������������������������������   115 3.3.5 Artikulierte Systeme ������������������������������������������������������������   116 3.3.6 Vereinen von Kinematik und Geometrie ������������������������������   121 3.3.7 Zusammengesetzte Kinematiken ����������������������������������������   123 3.3.8 Verknüpfung von CAEX und COLLADA ��������������������������   124 3.4 Beispiele ������������������������������������������������������������������������������������������   128 3.4.1 BREP: Flansch mit Loch ����������������������������������������������������   128 3.4.2 Dreieckmodell: Flansch mit Loch ����������������������������������������   130 3.4.3 Kinematik einer Schraube mit Formel ��������������������������������   133 3.5 Zusammenfassung ����������������������������������������������������������������������������   133 Literatur ����������������������������������������������������������������������������������������������������   134 4  Verhaltensbeschreibung mit PLCopen XML ��������������������������������������   Lorenz Hundt, Arndt Lüder, Rainer Drath und Björn Grimm 4.1  Überblick ������������������������������������������������������������������������������������������   4.2 Beschreibungsmittel zur Verhaltensmodellierung ��������������������������   4.2.1 Verhaltensinformationen einer Anlagenkomponente ����������   4.2.2 Beschreibungsmittel für Verhalten ��������������������������������������   4.2.3 Beschreibungsmittel im Engineering-Prozess ��������������������   4.2.4 Gantt Charts ������������������������������������������������������������������������   4.2.5 PERT Charts ������������������������������������������������������������������������   4.2.6 Impuls-Diagramme ��������������������������������������������������������������   4.2.7 Sequential Function Charts ��������������������������������������������������   4.2.8 Logiknetzwerke ��������������������������������������������������������������������   4.2.9 State Charts ��������������������������������������������������������������������������   4.3 PLCopen XML 2.0 ��������������������������������������������������������������������������   4.3.1 Überblick ������������������������������������������������������������������������������   4.3.2 Das AutomationML addData-Schema ��������������������������������  

135 135 139 139 140 141 143 144 145 147 149 150 153 153 156

xiv

Inhaltsverzeichnis

4.4 Der Intermediate Modelling Layer IML ������������������������������������������   4.4.1   Motivation ��������������������������������������������������������������������������   4.4.2   IML-Modellelemente ��������������������������������������������������������   4.4.3   IML-Definition und Klassendiagramm ������������������������������   4.4.4   Transformation von Gantt Charts nach IML ����������������������   4.4.5   Transformation von PERT Charts nach IML ��������������������   4.4.6   Transformation von Impuls-Diagrammen nach IML ��������   4.4.7    Transformation von State Charts nach IML ����������������������   4.4.8   Vergleich der Abbildungsvorschriften nach IML ��������������   4.4.9  Transformation von IML nach PLCopen XML ����������������   4.4.10  Vorgehensweise bei der Implementierung von IML ����������   4.5 Verriegelungslogik ��������������������������������������������������������������������������   4.5.1   Übersicht ����������������������������������������������������������������������������   4.5.2   Signal- und Komponentengruppen ������������������������������������   4.5.3   Beschreibung boolescher Verriegelungsbedingungen ������   4.5.4   Erweiterte Verriegelungskonzepte ������������������������������������   4.6 Integration von Verhaltensbeschreibung in CAEX ��������������������������   4.6.1  Referenzierung von PLCopen-XML-Daten ����������������������   4.6.2  Verknüpfung von Verhaltensbeschreibung ������������������������   4.7 Zusammenfassung ����������������������������������������������������������������������������   Literatur ����������������������������������������������������������������������������������������������������  

160 160 161 163 163 167 169 174 177 179 181 183 183 183 186 187 188 188 189 191 192

5  Ansatz zur integrierten Prozessbeschreibung ��������������������������������������   Andreas Keibel 5.1 Einleitung ����������������������������������������������������������������������������������������   5.2 Übersicht und Motivation ����������������������������������������������������������������   5.2.1  Problembeschreibung ��������������������������������������������������������   5.2.2  Anforderungen an AutomationML ������������������������������������   5.2.3  Vision ��������������������������������������������������������������������������������   5.2.4  Bestehende Datenformate zur Prozessdarstellung ������������   5.3 Modellierung von Bearbeitungsprozessen ��������������������������������������   5.3.1  Übersicht ����������������������������������������������������������������������������   5.3.2  Basisanforderungen an eine Prozessbeschreibung ������������   5.3.3  Die Eckpfeiler der Prozessbeschreibung ��������������������������   5.3.4  Von der Prozessbeschreibung zum Roboter-Code ������������   5.4 Datentechnische Inhalte der Objekte ����������������������������������������������   5.4.1  Übersicht ����������������������������������������������������������������������������   5.4.2   Modellierung des Bahn-Objektes ��������������������������������������   5.4.3  Modellierung des Werkzeug-Objektes ������������������������������   5.4.4  Modellierung des Prozess-Objektes ����������������������������������   5.5 Beispielmodellierung mit AutomationML ��������������������������������������   5.6 Zusammenfassung ����������������������������������������������������������������������������   Literatur ����������������������������������������������������������������������������������������������������  

195 195 196 196 198 200 201 201 201 202 202 204 205 205 206 208 213 214 220 220

Inhaltsverzeichnis

6  Praktische Anwendung ��������������������������������������������������������������������������   Rainer Drath, Dirk Weidemann, Steffen Lips, Lorenz Hundt, Arndt Lüder und Miriam Schleipen 6.1 Überblick ������������������������������������������������������������������������������������������   6.2 Referenzwerkzeuge ��������������������������������������������������������������������������   6.2.1 Editieren und Visualisieren mit dem AutomationML Editor ������������������������������������������������������������������������������������   6.2.2 AutomationML Logic Editor ����������������������������������������������   6.2.3 AutomationML Engine ��������������������������������������������������������   6.2.4 COLLADA Tools ����������������������������������������������������������������   6.3 Graphic Conditioner Pipeline Framework ��������������������������������������   6.3.1 Motivation ����������������������������������������������������������������������������   6.3.2 Anforderungen ��������������������������������������������������������������������   6.3.3 Umsetzung des Graphic CPF ����������������������������������������������   6.3.4 Fazit ��������������������������������������������������������������������������������������   6.4 Das Logic CPF ��������������������������������������������������������������������������������   6.4.1 Übersicht ������������������������������������������������������������������������������   6.4.2 Rahmenapplikation ��������������������������������������������������������������   6.4.3 IML-DOM ����������������������������������������������������������������������������   6.4.4 Plugins ���������������������������������������������������������������������������������   6.4.5 Beispiel ��������������������������������������������������������������������������������   6.4.6 Erweiterungsmöglichkeiten ������������������������������������������������   6.4.7 Aufbau der Pipeline-Konfigurationsdatei ����������������������������   6.4.8 Bearbeiten von Pipeline-Konfigurationsdateien ������������������   6.5 AutomationML-Beispiel „Philipp“ ��������������������������������������������������   6.5.1 Wer oder was ist Philipp ������������������������������������������������������   6.5.2 Vorgehen zur Abbildung von Philipp mit AutomationML ��������������������������������������������������������������   6.5.3 Aufbau der Objektstruktur von Philipp ��������������������������������   6.5.4 Definition und Implementierung der Objektschnittstellen ��������������������������������������������������������������   6.5.5 Integration externer Informationen ��������������������������������������   6.5.6 Verknüpfung der Objektschnittstellen ����������������������������������   6.5.7 Erstellen von Bibliotheksobjekten ��������������������������������������   6.6 OPC-Konfiguration ��������������������������������������������������������������������������   6.6.1 Übersicht ������������������������������������������������������������������������������   6.6.2 Beispiel ��������������������������������������������������������������������������������   6.7 Umgang mit großen CAEX-Dateien ������������������������������������������������   6.7.1 Auslagerung von Bibliotheken ��������������������������������������������   6.7.2 Aufteilung der Anlagenstruktur ��������������������������������������������   6.7.3 Verteilung von Daten in eine Hierarchie von Verzeichnissen ��������������������������������������������������������������   6.8 Umgang mit großen COLLADA-Dokumenten ������������������������������  

xv

221 221 224 224 229 233 239 239 239 240 243 247 247 247 249 250 253 254 256 257 259 259 259 260 262 264 266 267 271 273 273 275 278 279 280 282 283

xvi

Inhaltsverzeichnis

6.8.1 Verwendung eines Masterdokuments ����������������������������������   6.8.2 Auslagerung der verschiedenen Detaillierungsgrade ����������   6.8.3 Verteilung der Daten in einer Hierarchie von Verzeichnissen ��������������������������������������������������������������   6.9 Workflow-Empfehlungen ����������������������������������������������������������������   6.9.1 Übersicht ������������������������������������������������������������������������������   6.9.2   Vom manuellen zum voll automatisierten Datenaustausch ������������������������������������������������������������������   6.9.3   Randbedingungen zur Einführung von AutomationML ����   6.9.4   Unidirektionaler Datenaustausch zwischen zwei Werkzeugen ��������������������������������������������������������������   6.9.5   Bidirektionaler Datenaustausch zwischen zwei Werkzeugen ��������������������������������������������������������������   6.9.6   Sequentieller Workflow ����������������������������������������������������   6.9.7   Paralleler Workflow ����������������������������������������������������������   6.9.8   AutomationML als zentrale Planungsdatenbasis? ��������������   6.9.9  Zwischenfazit ��������������������������������������������������������������������   6.9.10 Empfehlungen zum Umgang mit Rollenbibliotheken ������   6.9.11 Empfehlungen zum Umgang mit SystemUnitBibliotheken ����������������������������������������������������������������������   6.9.12 Zusammenfassung der Empfehlungen ������������������������������   Literatur ����������������������������������������������������������������������������������������������������  

283 284

7  Bewertung und Ausblick ������������������������������������������������������������������������   Dirk Weidemann und Rainer Drath 7.1 Bewertung von AutomationML durch INPRO ��������������������������������   7.2 Nächste Schritte ������������������������������������������������������������������������������   7.2.1   Schwerpunkte ��������������������������������������������������������������������   7.2.2   Kommunikation und Gerätebeschreibung ������������������������   7.2.3   Elektroplanung ������������������������������������������������������������������   7.2.4   Safety-Aspekte ������������������������������������������������������������������   7.2.5   Simulation und virtuelle Inbetriebnahme ��������������������������   7.2.6   Compliance-Prüfung ����������������������������������������������������������   7.2.7   Projektierung und Konfiguration von MES mit AutomationML ������������������������������������������������������������   7.3 Zusammenfassung und Ausblick ����������������������������������������������������   Literatur ����������������������������������������������������������������������������������������������������  

307

285 287 287 287 290 291 292 294 295 296 297 298 299 302 304

307 309 309 311 311 313 313 314 314 316 318

Stichwortverzeichnis ������������������������������������������������������������������������������������   321

Autorenverzeichnis

Dr.-Ing. Rainer Drath Nach seiner Promotion als Automatisierungsingenieur an der technischen Universität Ilmenau und einem Stipendiumsaufenthalt in Japan ist Rainer Drath seit 2001 als wissenschaftlicher Mitarbeiter im Forschungszentrum der ABB AG in Ladenburg in Projekt- und Linienverantwortung tätig. Dort beschäftigt er sich u. a. mit dem Thema Engineering. Im AutomationML-Konsortium vertritt er die Themen AutomationML-Architektur, CAEX, Anlagentopologie, Bibliotheken sowie das Thema Logik.

Björn Grimm Björn Grimm studierte Elektrotechnik und Informationstechnik an der Universität Karlsruhe (TH). Seit dem Jahre 2004 ist er bei der Daimler AG mit dem Entwurf innovativer Produktionskonzepte und Technologien sowie der Entwicklung von Engineering-Werkzeugen für die Automatisierungstechnik beschäftigt. Im AutomationML-Konsortium vertritt er das Thema Logik.

xvii

xviii

Autorenverzeichnis

Lorenz Hundt Lorenz Hundt ist seit 2006 wissenschaftlicher Mitarbeiter am Center Verteilte Systeme der Otto-von-Guericke Universität Magdeburg. Dort leitet er das europäische Zertifizierungslabor für EtherNet/IP Geräte der ODVA. Seine Forschungsarbeiten betreffen den Bereichen industrielle Kommunikation und die Entwicklung von neuen Konzepten zum Austausch von EngineeringDaten. Im AutomationML-Konsortium vertritt der das Thema Logik.

Andreas Keibel Der 1967 gebürtige Hamburger war während und nach seinem Studium am Institut für Roboterforschung in Dortmund maßgeblich an der Entwicklung des Simulationssystems COSIMIR beteiligt. Nach seiner Promotion als Automatisierungsingenieur 2003 war er zunächst als Projektleiter für die Forschung-& Vorentwicklung der KUKA-Controls tätig und ist seit 2005 bei KUKA-Roboter verantwortlicher Projektleiter für die Applikationsentwicklung im Bereich digitales Engineering. Im AutomationML Konsortium vertritt er das Thema Robotik und Bearbeitungsprozesse.

Steffen Lips Steffen Lips studierte Bauingenieurwesen an der RuhrUniversität Bochum. Seit 2007 ist er Projektleiter bei der NetAllied Systems GmbH und u. a. verantwortlich für die technische Entwicklung von AutomationML im Bereich COLLADA. Im AutomationML-Konsortium vertritt er das Thema Geometrie und Kinematik.

Autorenverzeichnis

xix

Dr.-Ing. habil. Arndt Lüder Arndt Lüder leitet das Center Verteilte Systeme der Otto-von-Guericke Universität Magdeburg. Nach dem Studium der Mathematik und Wirtschaftsmathematik promovierte er an der Martin-Luther-Universität Halle-Wittenberg. Seit 2001 arbeitet Dr. Lüder im Center Verteilte Systeme der Otto-von-Guericke Universität Magdeburg, wo er 2007 im Fachgebiet Automation habilitierte. Im AutomationML-Konsortium vertritt der das Thema Logik.

Miriam Schleipen Miriam Schleipen studierte Informatik an der Universität Karlsruhe (TH). Seit 2005 ist sie am Fraunhofer IITB im Geschäftsfeld Leitsysteme beschäftigt. Ihre Tätigkeiten erstrecken sich unter anderem auf die Entwicklung von Konzepten und Methoden zur Verbesserung und Automatisierung des Engineerings von Leitsystemen/ Manufacturing Execution Systems (MES). Ihr wissenschaftlicher Schwerpunkt liegt auf der Adaptivität und Interoperabilität von Teilsystemen in Produktionsanlagen. Im AutomationML-Konsortium vertritt sie das Thema Dachformat und erweiterte Konzepte.

Dirk Weidemann Nach seinem Studium der Mathematik und Informatik entwickelte Dirk Weidemann zunächst CAD-Systeme und technische Applikationen. Schon bald übernahm er Projekt- und Linienverantwortung. Seit 2006 ist er Standortleiter der Zühlke Engineering GmbH in Hannover. Innerhalb der AutomationML ist er seit der Gründung Mitglied des Projektmanagement-Teams.

Abkürzungen

BREP CAD CAEX COLLADA CPF DCC-Tools DOM EAI FBD FPGA GSM GUID HMI LoD MES PLC PLM POU R&I-Fließbild SASA SASS SCADA SID SIGGRAPH SOA ST STO TCP URI USB UTC W3C WPF

Boundary Representation Computer Aided Design Computer Aided Engineering Exchange COLLAborative Design Activity Conditioner Pipeline Framework Digital Content Creation-Tools Dokumenten-Objekt-Modell Enterprise Application Integration Function Block Diagrams Field Programmable Gate Array Global System for Mobile communications Global Unique Identifier Human Machine Interface Level of Detail Manufacturing Execution System Programmable Logic Controller Product Lifecycle Management Program Organization Unit Rohrleitungsund Instrumentierungsfließbild, eine bevorzugte  grafische Darstellung einer verfahrenstechnischen Anlage Side-Angle-Side-Angle Side-Angle-Side-Side Supervisory Control and Data Aquisition scoped identifier Special Interest Group on Graphics and Interactive Techniques Service-orientierte Architektur Structured Text Safe Torque Off Tool Center Point Uniform Resource Identifier Universal Serial Bus Universal Time Coordinated World Wide Web Consortium Windows Presentation Foundation

xxi

Verwendete Markenbegriffe

In diesem Buch wurden eine Reihe von Wortmarken verwendet. Diese befinden sich im Besitz der hier aufgeführten Eigentümer. Wortmarke AutomationML Catia COLLADA Comos, ComosPT Cosimir Delmia Khronos Microsoft Excel Microsoft Project Microsoft Visio PROLIST RobCad W3C XMLSpy

Eigentümer Siemens AG Dassault Systémes Sony Computer Entertainment Inc. Innotec GmbH EF Robotertechnik GmbH Dassault Systémes Khronos Group, Inc. Microsoft Corp. Microsoft Corp. Microsoft Corp. Bayer AG Tecnomatix Technologies Ltd Massachusetts Institute of Technology (MIT), European Research Consortium of Informatics and Mathematics (ERCIM) or Keio University (Keio) Altova GmbH

xxiii

Abbildungsverzeichnis

Abb. 1.1   Eine typische Engineering-Prozesskette im Karosseriebau ����������    2 Abb. 1.2   Hohe Komplexität durch zahlreiche Software-Werkzeuge ����������    5 Abb. 1.3   Anzahl von Schnittstellen bei bilateralem Datenaustausch ����������    6 Abb. 1.4   Anzahl der Schnittstellen bei Nutzung offener Datenformate ������    7 Abb. 1.5   Initiale Ziele von AutomationML ������������������������������������������������   11 Abb. 1.6   Schematischer Planungsprozess im Automobilbau ����������������������   17 Abb. 1.7   Phase 1 – Fahrzeugentwicklung und digitale Fabrikplanung ������   17 Abb. 1.8   Phase 3 – Realisierung und Produktion ����������������������������������������   19 Abb. 1.9   Phasen bei der Planung verfahrenstechnischer Anlagen ��������������   20 Abb. 1.10  Bereiche innerhalb der Phase Verfahrensplanung ������������������������   20 Abb. 1.11  Schnittstelle zwischen Verfahrens- und Leittechnikplanung ��������   22 Abb. 1.12  Von der digitalen Fabrik zur Automatisierungstechnik ����������������   24 Abb. 1.13  AutomationML-Architektur ����������������������������������������������������������   26 Abb. 1.14  Kernkonzepte der AutomationML-Toplevel-Architektur ������������   28 Abb. 1.15  Beispiel für die Anlagenhierarchie einer Fertigungszelle ������������   29 Abb. 1.16  Planar- und Kugelgelenk als Beispiele für Kinematiken ��������������   30 Abb. 1.17  Referenzierung von COLLADA-Dokumenten ����������������������������   31 Abb. 1.18  Unterstützte Diagrammtypen für Logikbeschreibungen ��������������   32 Abb. 1.19  Referenzierung eines PLCopen-XML-Dokumentes ��������������������   32 Abb. 1.20  AutomationML-Schnittstellenbibliothek ��������������������������������������   33 Abb. 1.21  AutomationML-Basis-Rollenbibliothek ����������������������������������������   33 Abb. 1.22 AutomationML-Rollenbibliothek für die a) Fertigungstechnik und b) Leittechnik ������������������������������������������������������������������������   34 Abb. 1.23  Beispiel für Gruppenobjekte ��������������������������������������������������������   35 Abb. 1.24 Darstellung einer kinematisierten Zelle in verschiedenen Werkzeugen ����������������������������������������������������������������������������������   36 Abb. 1.25 Transformation einer Ablaufdarstellung von Gantt (Excel) über Impulsdiagramme in einen SFC der IEC 61131-3 ������������������������   37 Abb. 1.26 Komponentenkonzepte im Automation Designer (Siemens) und im AutomationML Editor (Zühlke) ����������������������������������������   38 Abb. 1.27  Geplante IEC-Normenreihe für AutomationML ��������������������������   41 Abb. 1.28  Messepräsentation von AutomationML ����������������������������������������   43 xxv

xxvi

Abbildungsverzeichnis

Abb. 2.1   Toplevel-Architektur von AutomationML ������������������������������������   Abb. 2.2   Ein Objektbaum in einem modernen Planungswerkzeug ������������   Abb. 2.3   Grundlegende CAEX-Elemente ����������������������������������������������������   Abb. 2.4   Beispiel einer Instanz-Hierarchie ��������������������������������������������������   Abb. 2.5   CAEX-Modellierung eines Objektbaumes ����������������������������������   Abb. 2.6   XML-Code des Objektbaumes ������������������������������������������������������   Abb. 2.7   Das CAEX-Rollenkonzept ������������������������������������������������������������   Abb. 2.8   XML-Beispiel für das Rollenkonzept ������������������������������������������   Abb. 2.9   Klassische Einzel-Rollen-Zuordnung nach IEC 62424 ����������������   Abb. 2.10  Zuordnung mehrerer Rollen mit AutomationML ��������������������������   Abb. 2.11  Relationsarten in CAEX ����������������������������������������������������������������   Abb. 2.12  XML-Beschreibung von Relationen ��������������������������������������������   Abb. 2.13  Relation zwischen zwei Instanzen ������������������������������������������������   Abb. 2.14  XML-Dokument für eine Relation zwischen Instanzen ��������������   Abb. 2.15  Beispiel für Referenzen ����������������������������������������������������������������   Abb. 2.16  XML-Text für das Referenzbeispiel ���������������������������������������������   Abb. 2.17  Publikation von COLLADA-Schnittstellen in CAEX ������������������   Abb. 2.18  Veröffentlichte COLLADA-Schnittstellen in CAEX ��������������������   Abb. 2.19  Publikation von PLCopen-XML-Schnittstellen in CAEX ������������   Abb. 2.20  Veröffentlichte PLCopen-XML-Schnittstellen in CAEX ������������   Abb. 2.21  AutomationML-Standard-Schnittstellenbibliothek ����������������������   Abb. 2.22  AutomationML-Standard-Rollenbibliothek ����������������������������������   Abb. 2.23  Fertigungstechnische Basis-Rollenbibliothek ������������������������������   Abb. 2.24  Leittechnische Basis-Rollenbibliothek ����������������������������������������   Abb. 2.25  Beispiel für nutzerdefinierte Attribute ������������������������������������������   Abb. 2.26  Nutzerdefinierte SystemUnit-Klassenbibliothek ��������������������������   Abb. 2.27  Erweiterte AutomationML-Rollenbibliothek ��������������������������������   Abb. 2.28  Port-Konzept ��������������������������������������������������������������������������������   Abb. 2.29  Beispiel für AutomationML-Ports ������������������������������������������������   Abb. 2.30  Beispiel für AutomationML-Ports mit CAEX ������������������������������   Abb. 2.31  Beispiel für AutomationML-Facetten ������������������������������������������   Abb. 2.32  Beispiel für AutomationML-Facetten mit CAEX ������������������������   Abb. 2.33  Beispiel für Gruppen ��������������������������������������������������������������������   Abb. 2.34  Umsetzung des Gruppenobjekt-Beispiels mit CAEX ������������������   Abb. 2.35  Kombination von Gruppen- und Facetten-Konzept ����������������������   Abb. 2.36 XML-Code zur Kombination von Gruppenund Facetten-Konzept ������������������������������������������������������������������   Abb. 2.37  HMI-Faceplate B ��������������������������������������������������������������������������   Abb. 2.38  Generiertes HMI ��������������������������������������������������������������������������   Abb. 2.39  Grundelemente des Dreisichten-Konzeptes ����������������������������������   Abb. 2.40  Beispielanlage für das PPR-Modell ����������������������������������������������   Abb. 2.41  Standard-Rollenklassen für das Drei-Sichtenkonzept ������������������   Abb. 2.42  Teilbäume des Anwendungsbeispiels ��������������������������������������������   Abb. 2.43  Standard-Schnittstellenklasse PPRConnector ������������������������������   Abb. 2.44  Verbindungen innerhalb der Beispielanlage ���������������������������������  

46 47 48 51 51 52 53 53 56 57 59 60 63 63 64 65 65 66 66 66 68 68 69 70 71 72 73 75 75 76 78 78 79 80 81 82 83 83 84 86 87 87 87 88

Abbildungsverzeichnis

Abb. 2.45  Abb. 2.46  Abb. 2.47  Abb. 2.48  Abb. 2.49  Abb. 2.50 

Ressourcenzentrierte Sicht auf die Beispielanlage ��������������������    InstanceHierarchy der Beispielanlage in AutomationML ����������    Interne Elemente der Beispielanlage ������������������������������������������    Verknüpfungen der Beispielanlage ��������������������������������������������    XML-Quelltext der Beispielanlage ��������������������������������������������    Import- und Export von AutomationML-Objekten ��������������������   

xxvii

88 89 90 90 92 93

Abb. 3.1   Die 3D-Geometrie einer Anlagenkomponente „Roboter“ ����������    97 Abb. 3.2   Allgemeiner Aufbau einer COLLADA-Datei ����������������������������    97 Abb. 3.3   BREP Modell einer Hülse ����������������������������������������������������������    98 Abb. 3.4   Orientierung von Edges ��������������������������������������������������������������   100 Abb. 3.5   Prinzipieller Aufbau des Elements ������������������������������   100 Abb. 3.6   Struktur der Begrenzungselemente ��������������������������������������������   102 Abb. 3.7   Tessellierte Darstellung einer Hülse ��������������������������������������������   103 Abb. 3.8   Aufbau einer polygon-basierten Geometrie in COLLADA ��������   104 Abb. 3.9   Das Element ��������������������������������������������������������������   105 Abb. 3.10  Das Element ��������������������������������������������������   105 Abb. 3.11  Das Element mit einem Loch ����������������������������   106 Abb. 3.12  Das Element ������������������������������������������������������   106 Abb. 3.13  Das Element ����������������������������������������������������   106 Abb. 3.14  Das Element ����������������������������������������������������   107 Abb. 3.15  Das Element ���������������������������������������������������������   107 Abb. 3.16  Geometrie einer Komponente „KR150-1“ ����������������������������������   108 Abb. 3.17  Visuelle Szene der Komponente „Roboter“ ��������������������������������   109 Abb. 3.18  Definition eines Effekts ��������������������������������������������������������������   110 Abb. 3.19  Definition eines Materials ����������������������������������������������������������   110 Abb. 3.20  Binden eines Materials ����������������������������������������������������������������   110 Abb. 3.21  Verschiedene Detaillierungsgrade bzw. „Level of Detail“ ����������   111 Abb. 3.22  Definition von Gelenken ������������������������������������������������������������   113 Abb. 3.23  Beispiel eines einfachen kinematischen Modells ������������������������   114 Abb. 3.24  Ein einfacher Zyklus ������������������������������������������������������������������   115 Abb. 3.25  Kinematische Modell mit Formeln ��������������������������������������������   117 Abb. 3.26  Vorabdefinierte Funktion ������������������������������������������������������������   118 Abb. 3.27  Verwendung einer Funktion ��������������������������������������������������������   118 Abb. 3.28  Artikuliertes System mit kinematischen Aspekten ����������������������   120 Abb. 3.29  Artikuliertes System mit dynamischen Aspekten ������������������������   121 Abb. 3.30  Kinematische Szene ��������������������������������������������������������������������   122 Abb. 3.31  Koppelung zwischen Kinematik und Geometrie ������������������������   123 Abb. 3.32  Artikuliertes System einer kombinierten Kinematik ������������������   124 Abb. 3.33  Referenz eines CAEX Objekts nach COLLADA ����������������������   125 Abb. 3.34  XML-Quellcode für ein COLLADAInterface in CAEX ������������   126 Abb. 3.35  Element für eine Komponente ����������������������������������   127 Abb. 3.36  Relation zwischen zwei COLLADAInterfaces ��������������������������   127 Abb. 3.37  Verlinkung zwischen Roboter und Greifer ����������������������������������   127 Abb. 3.38  Flansch mit Loch ������������������������������������������������������������������������   128

xxviii

Abb. 3.39  Abb. 3.40  Abb. 3.41  Abb. 3.42  Abb. 3.43  Abb. 3.44 

Abbildungsverzeichnis

Schematische Darstellung der Topologie ������������������������������������   Grundorientierung der Wires ������������������������������������������������������   Triangulierte Geometrie ��������������������������������������������������������������   Harter und weicher Kantenübergang ������������������������������������������   Schematische Darstellung einer Schraube ����������������������������������   Definition des kinematischen Modells ����������������������������������������  

Abb. 4.1  Beschreibungsmittel für Verhalten in den Phasen des Anlagen-Engineerings ����������������������������������������������������������   Abb. 4.2  Sequencing und Behaviour zur Verhaltensbeschreibung von Automatisierungsgeräten ������������������������������������������������������   Abb. 4.3   Beispiel für verschiedenen Logik-Informationsarten ����������������   Abb. 4.4  Nutzung einzelner Beschreibungsmittel während der Planung von Produktionssystemen ����������������������������������������������������������   Abb. 4.5   Beispiel für ein Gantt Chart ��������������������������������������������������������   Abb. 4.6   Beispiel für ein PERT Chart ��������������������������������������������������������   Abb. 4.7   Beispiel für ein Impuls-Diagramm ��������������������������������������������   Abb. 4.8   Beispiel eines SFCs nach IEC 61131-3 ��������������������������������������   Abb. 4.9   Beispiel für ein Logiknetzwerk ��������������������������������������������������   Abb. 4.10  Beispiel für ein State Chart ��������������������������������������������������������   Abb. 4.11  Anwendungsfälle zum Datenaustausch mit PLCopen XML ������   Abb. 4.12  PLCopen-XML-Darstellung von „MUX“ ����������������������������������   Abb. 4.13  addData XML-Schema für PLCopen XML ��������������������������������   Abb. 4.14 Deklaration des AutomationML addData-Schemas in einem PLCopen-XML-Dokument ��������������������������������������������������������   Abb. 4.15  Beispiel für addData-Schema ������������������������������������������������������   Abb. 4.16  Das Intermediate Modelling Layer IML ������������������������������������   Abb. 4.17  Ein einfaches IML-Modell ����������������������������������������������������������   Abb. 4.18  Datenmodell des IML ����������������������������������������������������������������   Abb. 4.19  Einfaches Beispiel eines IML-Systems ��������������������������������������   Abb. 4.20  Übersetzung eines Gantt-Chart-Balken nach IML ����������������������   Abb. 4.21 Übersetzung einer Vorgänger/Nachfolger-Beziehung nach IML ������������������������������������������������������������������������������������   Abb. 4.22  Übersetzung des Zeitverhaltens nach IML ��������������������������������   Abb. 4.23  Übersetzung des Endschritts nach IML ��������������������������������������   Abb. 4.24  Transformationsbeispiel Gantt Chart nach SFC ��������������������������   Abb. 4.25  Übersetzung einer PERT-Chart-Aktivität nach IML ������������������   Abb. 4.26  Transformationsbeispiel PERT Diagramm nach SFC ����������������   Abb. 4.27  Übersetzung eines Resource State Flow nach IML ��������������������   Abb. 4.28  Signale in Impuls-Diagrammen ��������������������������������������������������   Abb. 4.29  Darstellung eines Impuls-Diagramms in IML ����������������������������   Abb. 4.30  Transformation eines State Charts nach IML ������������������������������   Abb. 4.31  Transformation von IML nach PLCopen XML ��������������������������   Abb. 4.32  Transformation eines IML-Schrittes nach PLCopen XML ��������   Abb. 4.33  Transformation einer IML Aktivität nach PLCopen XML ��������  

129 130 131 131 131 132 136 137 140 141 143 144 146 148 150 151 153 155 158 159 160 161 161 164 165 166 166 166 167 168 169 170 171 172 173 176 180 181 182

Abbildungsverzeichnis

xxix

Abb. 4.34  Beispiel für eine Signal- und eine Komponentengruppe ������������   Abb. 4.35  Vereinfachtes CAEX-Modell ������������������������������������������������������   Abb. 4.36  Prinzip Verknüpfung von Signal- und Komponentengruppen ����   Abb. 4.37  Funktionsblocknetzwerk ������������������������������������������������������������   Abb. 4.38  Komplexe Verriegelungsbeschreibungen ������������������������������������   Abb. 4.39 Verknüpfen von AutomationML-Objekten mit PLCopen-XML-Dokumenten ����������������������������������������������������   Abb. 4.40 Veröffentlichungsmechanismus von PLCopen-XML-Variablen in CAEX ��������������������������������������������������������������������������������������   Abb. 4.41  CAEX-Beispiel zur Veröffentlichung von Signalen ������������������   Abb. 4.42 Verknüpfungsprinzip von Verriegelungs- und Verhaltensbeschreibung ��������������������������������������������������������������   Abb. 4.43 Beispielhafte Verknüpfung von Verriegelungs- und Verhaltensbeschreibung ��������������������������������������������������������������  

184 185 185 186 187

Abb. 5.1   Von der Aufgabenbeschreibung zur Bearbeitung ������������������������   Abb. 5.2  Beispiel für einen Bearbeitungsprozess: einfache Schweißnaht ��������������������������������������������������������������������������������   Abb. 5.3  Objekte und Relationen der BearbeitungsProzessbeschreibung ������������������������������������������������������������������   Abb. 5.4   Ausführungsdreieck ��������������������������������������������������������������������   Abb. 5.5   Beispiel: Pick & Place ����������������������������������������������������������������   Abb. 5.6   Prozessbeschreibungs-Bibliothek ����������������������������������������������   Abb. 5.7   AutomationML-Standardschnittstellenklassen ��������������������������   Abb. 5.8   Rollenbibliothek zur Prozessbeschreibung ��������������������������������   Abb. 5.9   Rumpf des CAEX-Objektmodells ����������������������������������������������   Abb. 5.10  Beispielprojekt Bahnschweißen ��������������������������������������������������   Abb. 5.11  Verknüpfungen zwischen den Objekten ��������������������������������������   Abb. 5.12  Prozessgrößenverläufe per SFC definieren ��������������������������������  

197

Abb. 6.1  Zusammenspiel verschiedener Werkzeuge für AutomationML ����������������������������������������������������������������������   Abb. 6.2   AutomationML Editor ����������������������������������������������������������������   Abb. 6.3   Eine Instanzhierarchie mit ihren Objekten ����������������������������������   Abb. 6.4   Ergebnisse der Konsistenzprüfung ����������������������������������������������   Abb. 6.5   AutomationML Logic Editor ������������������������������������������������������   Abb. 6.6   Gantt-View im Logic Editor ������������������������������������������������������   Abb. 6.7   Impulsdiagramm im Logic Editor ����������������������������������������������   Abb. 6.8   Ein komplexer SFC ��������������������������������������������������������������������   Abb. 6.9   Klassenmodell der AutomationML Engine bis CAEXObject ����   Abb. 6.10  Klassenmodell der AutomationML Engine ab CAEXObject ����   Abb. 6.11  XML-Beispiel für die AutomationML Engine ����������������������������   Abb. 6.12  Source-Code-Beispiel für die AutomationML Engine ����������������   Abb. 6.13  Informationsfragmente einer Komponente ��������������������������������   Abb. 6.14  Schematische Darstellung einer Konvertierung ��������������������������  

189 189 190 190 191

200 203 205 213 215 216 216 217 218 219 219 223 225 226 228 230 231 232 233 234 235 236 237 242 242

xxx

Abbildungsverzeichnis

Abb. 6.15  Kommando zum Konvertieren nach COLLADA ����������������������   Abb. 6.16  Roboter im Tool DELMIA V5 ����������������������������������������������������   Abb. 6.17  Kommando zum Konvertieren von COLLADA ������������������������   Abb. 6.18  Roboter im Tool eM-Engineer ����������������������������������������������������   Abb. 6.19  Kommando zum Konvertieren von COLLADA nach JT ����������   Abb. 6.20  Roboter im Tool JT2GO ��������������������������������������������������������������   Abb. 6.21  Prinzip des Logic CPF ����������������������������������������������������������������   Abb. 6.22  Plugin-Architektur des Logic CPF ����������������������������������������������   Abb. 6.23  Bedienoberfläche der Logic CPF Rahmenapplikation ����������������   Abb. 6.24  Klassendiagramm des IML-DOM ����������������������������������������������   Abb. 6.25 Ablaufdiagramm einer vereinfachten Waschmaschine in Excel ����������������������������������������������������������������������������������������   Abb. 6.26  GUI zum Aufruf des Logic CPFs ������������������������������������������������   Abb. 6.27  PLCopen-XML-Darstellung im Logic Editor ����������������������������   Abb. 6.28  Erweiterungsmöglichkeit des Logic CPFs ����������������������������������   Abb. 6.29  XML-Schema der Pipelinekonfigurationsdatei ��������������������������   Abb. 6.30  Beispiel einer Pipeline-Konfigurationsdatei ������������������������������   Abb. 6.31  3D-Darstellung von Philipp ��������������������������������������������������������   Abb. 6.32  Hierarchische Struktur des Philipp ��������������������������������������������   Abb. 6.33  Verhalten im Philipp-Beispiel ����������������������������������������������������   Abb. 6.34  Erstellung einer InstanceHierarchy ��������������������������������������������   Abb. 6.35  Erstellung eines ��������������������������������   Abb. 6.36  Festlegung von Objekt-Basiseigenschaften ��������������������������������   Abb. 6.37  Objektstruktur im Philipp-Beispiel ��������������������������������������������   Abb. 6.38  Aufbau und Signale einer Sensor-Aktor-Einheit des Philipp ������   Abb. 6.39  Verhalten der Sensor-Aktor-Einheit des Philipp ������������������������   Abb. 6.40  Integration von Schnittstellen im Philipp-Beispiel ��������������������   Abb. 6.41  Schnittstellen im Philipp-Beispiel ����������������������������������������������   Abb. 6.42 Ausschnitt der PLCopen-XML-Datei zum Behaviour der Sensor-Aktor-Einheit ������������������������������������������������������������   Abb. 6.43 Integration der PLCopen-XML-Datei der SensorAktor-Einheit ������������������������������������������������������������������������������   Abb. 6.44  Verknüpfung der Schnittstellen der Sensor-Aktor-Einheit ����������   Abb. 6.45  Beispiel eines InternalLink-Objekts ��������������������������������������������   Abb. 6.46  Erstellung einer neuen SystemUnitClassLib ������������������������������   Abb. 6.47  Erstellung der Inhalte einer neuen ����   Abb. 6.48  Struktur der Klasse SAE_Class ��������������������������������������������������   Abb. 6.49  Rollenklasse OPCServer ������������������������������������������������������������   Abb. 6.50  OPCTag-Schnittstelle ������������������������������������������������������������������   Abb. 6.51  Verbindungen in der OPC-Beispielanlage ����������������������������������   Abb. 6.52  InstanceHierarchy der OPC-Beispielanlage ��������������������������������   Abb. 6.53  XML-Quelltext der OPC-Beispielanlage ������������������������������������   Abb. 6.54  Beispiel für den Umgang mit großen CAEX-Dateien ����������������   Abb. 6.55  Beispiele für die Referenzierung externer CAEX-Dateien ��������   Abb. 6.56  Verteilung von Daten in mehrere CAEX-Dateien ����������������������  

243 244 244 245 246 246 248 249 250 251 254 255 256 257 258 258 259 260 261 263 263 263 264 265 266 268 268 269 269 270 270 271 272 272 273 274 275 276 277 278 278 279

Abbildungsverzeichnis

xxxi

Abb. 6.57  Auslagerung von Bibliotheken in eine separate CAEX-Datei ����   Abb. 6.58  Beispiel zur Referenzierung einer externen Bibliothek ��������������   Abb. 6.59  Zerlegung einer Instanz-Hierarchie in mehrere Dateien ������������   Abb. 6.60  Zentraldokument des Beispielprojektes ��������������������������������������   Abb. 6.61  Externes Dokument Firma01.aml des Beispielprojektes ������������   Abb. 6.62  Abbildung der Projektstruktur mittels Dateiordner ��������������������   Abb. 6.63  Aufbau des Masterdokuments ����������������������������������������������������   Abb. 6.64  Zerlegung eines COLLADA-Dokuments in mehrere Dateien ��   Abb. 6.65  Masterdokument mit LoD-Unterstützung ����������������������������������   Abb. 6.66 Vorschlag einer Dokumentenstruktur für COLLADA-Dokumente �����������������������������������������������������������������   Abb. 6.67 Unidirektionaler Datenaustausch zwischen benachbarten Phasen des Engineering-Workflows ������������������������������������������   Abb. 6.68  Bidirektionaler Datenaustausch mit AutomationML ������������������   Abb. 6.69  Sequentieller Workflow mit AutomationML ������������������������������   Abb. 6.70  Paralleler Workflow mit AutomationML ������������������������������������   Abb. 6.71  AutomationML als zentrale Datenbasis ��������������������������������������   Abb. 6.72  Austausch von Bibliotheken – Anwendungsfall 1 ����������������������   Abb. 6.73  Austausch von Bibliotheken – Anwendungsfall 2 ����������������������   Abb. 6.74  Austausch von Bibliotheken – Anwendungsfall 3 ����������������������  

279 280 281 281 282 282 284 285 286 287 292 293 294 295 297 300 301 302

Abb. 7.1  Systemübergreifender Datenaustausch mit AutomationML und INPRO Rollenbibliothek ������������������������������������������������������   308 Abb. 7.2   Vereinfachter Engineering-Prozess für Fertigungsanlagen ��������   310 Abb. 7.3   MES-Datenquelle AutomationML ����������������������������������������������   316

Formelverzeichnis

Formel 3.1  Formeln für ein Parallelogramm ����������������������������������������������   116 Formel 3.2  Schraubenformel������������������������������������������������������������������������   133

xxxiii

Tabellenverzeichnis

Tab. 2.1   Vater-Kind-Beziehung innerhalb einer Klassenbibliothek ����������    61 Tab. 2.2   Beispiel einer Vererbungsrelation zwischen Klassen ������������������    61 Tab. 2.3   Beispiel einer Klassen-Instanz-Relation ��������������������������������������    62 Tab. 2.4   AutomationML-Standard-Schnittstellenklassen ��������������������������    67 Tab. 2.5   AutomationML-Standard-Basis-Rollenbibliothek ����������������������    69 Tab. 2.6   Nutzerdefinierter AutomationML-Port als Klasse ����������������������    77 Tab. 3.1   Auflistung der geometrischen Elemente ��������������������������������������    99 Tab. 3.2  Auflistung der begrenzenden Elemente in der Reihenfolge ihrer Komplexität ������������������������������������������������������������������������    99 Tab. 3.3   Liste aller unterstützten Kurvenbeschreibungen ��������������������������   101 Tab. 3.4   Liste aller unterstützen Oberflächenbeschreibungen ������������������   101 Tab. 3.5   Liste der Transformationselemente ����������������������������������������������   108 Tab. 3.6   Liste der gängigen Gelenkarten, Abbildungen aus MW (2009) ������  112 Tab. 3.7   Kinematische Aspekte ������������������������������������������������������������������   119 Tab. 3.8   Dynamische Aspekte ��������������������������������������������������������������������   120 Tab. 3.9   Attribute des Attributs Frame ������������������������������������������������������   125 Tab. 3.10  Definition Vertizen ����������������������������������������������������������������������   129 Tab. 3.11  Definition Edges ��������������������������������������������������������������������������   129 Tab. 3.12  Definition Wires ��������������������������������������������������������������������������   130 Tab. 3.13  Definition Face ����������������������������������������������������������������������������   130 Tab. 4.1   Elemente des AutomationML addData-Schemata ����������������������   159 Tab. 4.2   Elemente von IML ����������������������������������������������������������������������   162 Tab. 4.3   Abbildung der einzelnen Modellelemente auf IML ��������������������   178 Tab. 4.4   Übertragungsregeln von IML nach SFC ��������������������������������������   179 Tab. 4.5  Beispiele zur Referenzierung von Logikinformationen aus CAEX����������������������������������������������������   188 Tab. 5.1   Das Bahn-Objekt und seine benötigten Parameter ����������������������   206 Tab. 5.2   Das Werkzeug-Objekt und seine benötigten Informationen ��������   208 Tab. 5.3   Prozessgrößen und ihre benötigten Informationen ����������������������   209 Tab. 5.4   Aktionen und ihre benötigten Informationen ������������������������������   209 Tab. 5.5  Modellierung von geometrischen Einschränkungen von Werkzeugen ��������������������������������������������������������������������������   210 xxxv

xxxvi

Tabellenverzeichnis

Tab. 5.6   Parameter zur Definition von Freiheitsgraden ����������������������������   Tab. 5.7   Beispiel – Prozessgrößen einer Lackierpistole ����������������������������   Tab. 5.8   Beispiel – Prozessmethoden einer Lackierpistole ������������������������   Tab. 5.9   Beispiel – Freiheitsgrade einer Lackierpistole ����������������������������   Tab. 5.10  Beispiel – Grunddaten für eine Schweißpistole ��������������������������   Tab. 5.11  Beispiel – Prozessgrößen für eine Schweißpistole ����������������������   Tab. 5.12  Beispiel – Aktionen und Methoden für eine Schweißpistole ������   Tab. 5.13  Beispieldefinition für eine Schweißpistole ����������������������������������   Tab. 5.14  Beispielklassen für die Prozessbeschreibung ������������������������������   Tab. 6.1   Unterstützte Eingabeformate �������������������������������������������������������   Tab. 6.2   Unterstützte Ausgabeformate ������������������������������������������������������   Tab. 6.3   Konvertierungsschrittfolge Teil 1 ������������������������������������������������   Tab. 6.4   Konvertierungsschrittfolge Teil 2 ������������������������������������������������   Tab. 6.5   Konvertierungsschrittfolge Teil 3 ������������������������������������������������   Tab. 6.6   Hauptkomponenten des Logic CPF ��������������������������������������������   Tab. 6.7   Methoden des IML-Systems ��������������������������������������������������������   Tab. 6.8   Plugin Schnittstelle ITask ������������������������������������������������������������   Tab. 6.9   Eigenschaften der Klasse PluginOption ��������������������������������������   Tab. 6.10  Schnittstellen für Teilobjekte von Philipp ������������������������������������   Tab. 6.11  Verhaltensbezogene Schnittstellen der linken Hand ��������������������   Tab. 6.12  Attribute der Rollenklasse OPCServer ����������������������������������������   Tab. 6.13  Attribute der Schnittstellenklasse OPCTag ����������������������������������   Tab. 6.14  Zuordnung von OPC- und XML-Datentypen ������������������������������  

210 211 211 211 211 212 212 212 215 240 240 244 245 246 248 252 253 254 265 267 274 274 274

Kapitel 1

Einleitung Dirk Weidemann und Rainer Drath

1.1  Lesefahrplan: welche Kapitel Sie nicht lesen müssen Dieses Buch gibt erstmalig einen umfassenden Überblick über AutomationML. Es richtet sich zum einen an Ingenieure und Entscheider der Prozess- und Fertigungsindustrie, die sich dem Thema Datenaustausch zwischen Engineering-Werkzeugen widmen möchten. Zum anderen finden Informatiker in diesem Buch viele hilfreiche Details und Beispiele für die Implementierung von AutomationML. Und gerade für Studenten, Lehrbeauftragte und Professoren in Hochschulen und Universitäten ist dieses Buch eine Fundgrube, da AutomationML zur Anwendung und Entwicklung neuer Methoden und Ansätze anregt, die mit heutigen Werkzeugen (noch) nicht realisierbar sind. AutomationML bietet Stoff für Diplom-, Master- und Doktorarbeiten und kann den Transfer neuer Technologien wie „Semantik Web“ oder „Automation of Automation“ in die Industrie beitragen. Die Literatur zeigt hierzu bereits vielversprechende Ansätze, vgl. beispielsweise Runde et al. (2009), Güttel et al. (2009), Mühlhause et al. (2009), Remmel u. Drumm (2009), Wollschläger et al. (2009) und Güttel et al. (2008). Welche positiven Effekte eine schrittweise industrielle Einführung neutraler Datenaustauschkonzepte haben kann belegen beispielsweise Kroll u. Still (2009) anhand der NE 100. • Kapitel 1 widmet sich der Motivation, den Initiatoren und den Zielen von Auto‑ mationML sowie den Möglichkeiten zur Mitgestaltung. Für einen schnellen Einstieg in AutomationML empfiehlt sich der Abschnitt 1.6 „AutomationML in a Nutshell – ein Architekturüberblick“. • Kapitel 2 gibt einen Überblick über die Architektur von AutomationML und erläutert, wie Anlagenhierarchien modelliert werden – sie bilden für AutomationML das objektorientierte Grundgerüst der Anlagenplanung.

D. Weidemann () Zühlke Engineering GmbH, Expo Plaza 3, 30539 Hannover, Deutschland e-mail: [email protected] R. Drath (Hrsg.), Datenaustausch in der Anlagenplanung mit AutomationML, DOI 10.1007/978-3-642-04674-2_1, © Springer-Verlag Berlin Heidelberg 2010





D. Weidemann und R. Drath

• Kapitel 3 ist dem Thema Geometrie und Kinematik gewidmet und beschreibt die Anwendung von COLLADA 1.5. • Kapitel 4 erläutert die Modellierung von Verhalten mittels PLCopen XML sowie die Transformation typischer Beschreibungsmittel nach AutomationML. • Kapitel 5 ist dem Thema Prozessbeschreibung gewidmet und erläutert, welche Herausforderungen die Modellierung von Aufgabenbeschreibungen stellt und wie sie mit AutomationML abgebildet werden können. Dieses Thema eröffnet neue Möglichkeiten zur automatischen Generierung von Roboterprogrammen. • Kapitel 6 umfasst praktische Anwendungen, verfügbare Werkzeuge und Beispiele. Für die Einführung von AutomationML empfiehlt sich der Abschnitt 6.9 „Workflowempfehlungen“. • Kapitel 7 gibt einen Ausblick auf die Zukunftspotentiale von AutomationML.

1.2  Motivation und Problembeschreibung 1.2.1  Motivation Hauptmotivation von AutomationML ist die Senkung von Kosten für die Planung von Anlagen. Die Planung von fertigungs- und prozesstechnischen Anlagen ist bekanntlich ein kostenintensiver und komplexer Vorgang und erfordert die Zusammenarbeit einer Vielfalt von Berufsgruppen. Sie ist durch eine historisch gewachsene starke Arbeitsteilung geprägt und wurde deshalb in der Vergangenheit in separate Phasen bzw. Gewerke unterteilt. Die Phasen lassen sich vereinfacht sequentiell wie in Abb. 1.1 dargestellt anordnen. Digitale Fabrik Standardplanung

Festlegung Werk Block Layout Flächenbedarf

Digitale Fabrik Realplanung

Festlegung Werkshalle Produktionsabläufe Ermittlung/ Validierung Erreichbarkeit Alternative Produktionskonzepte Vertragsvergabe

Konstruktion Fertigung

Mech. Konstruktion Mech. Simulation Mech. Fertigung Roboterprogrammierung Elektrische Planung SPS-Programmierung

Inbetriebnahme Produktion

Inbetriebnahme von SPS- und Roboterprog. Prozesskonfiguration Job #1 Qualitätsverbesserung Lessons learned

Anreicherungsgrad der Daten Abb. 1.1   Eine typische Engineering-Prozesskette im Karosseriebau

1  Einleitung



Zur Kostensenkung können zum einen die Abläufe innerhalb der einzelnen Phasen und zum anderen die Kopplungen zwischen den Phasen optimiert werden. Die Arbeit innerhalb der einzelnen Planungsphasen wird bereits seit Jahren durch spezialisierte, moderne und leistungsfähige Werkzeuge unterstützt und verbessert. Eine werkzeuggestützte durchgängige Planung über alle Planungsphasen hinweg ist hingegen bis heute nicht verfügbar – dies gilt als wichtiger Hebel für die Erhöhung der Engineering-Effizienz. Dass eine durchgängige Integration von Daten funktionieren kann, zeigen bereits seit Jahren etablierte kaufmännische Anwendungen, die ihre monolithischen Strukturen mit sogenannter Enterprise Application Integration (EAI) und Service-orientierten Architekturen (SOA) aufgebrochen haben. Der Engineering-Bereich ist noch weit davon entfernt, aber die Notwendigkeit steht außer Frage, vgl. Fay (2006). Hauptgründe für die nur sehr zögerliche Weiterentwicklung einer durchgängigen Werkzeugunterstützung in der Anlagenplanung sind die hohen Anforderungen an Stabilität, Anlagen- und Produktlaufzeit, Sicherheit und Qualität. Der Informationsfluss zwischen den Werkzeugen hat sich angesichts der zunehmenden Verzahnung der Phasen, des wachsenden Kosten- und Zeitdrucks und der wachsenden Zahl von Sub-Lieferanten jedoch als eigenständiger Wert herausstellt (Rauprich et al. 2002). Dem Trend zu großen und phasenübergreifenden Engineering-Werkzeugen stehen die kleinen Speziallösungen entgegen, die ihnen häufig im Detail überlegen sind. Der offene Datenaustausch zwischen den Planungsphasen gewinnt daher im Sinne des durchgängigen Engineerings zunehmend an Bedeutung.

1.2.2  Problembeschreibung Planungsdaten unterliegen im Laufe des Engineerings einer kontinuierlichen und iterativen Anreicherung und Veränderung. Häufig werden Anlagen nicht komplett neu konzipiert. Stattdessen werden vielmehr vorbereitete Standardanlagen oder Teilsysteme quasi als Blaupausen verwendet, um eine Anlage zur Herstellung eines konkreten Produktes zu planen, zum Beispiel die Rohkarosse eines Fahrzeugmodells. Die Wiederverwendung von Anlagendaten in verschiedenen Versionen und Konfigurationen ist somit eine sehr wichtige Anforderung und wesentliche Voraussetzung für effizientes Planen. Die Festlegung notwendiger Anlagenkomponenten oder Fertigungszellen ergibt sich aus der Beschreibung des Produktionsprozesses: diese werden zunächst häufig in einem sehr einfachen Beschreibungsmittel wie Gantt Charts mit Microsoft Excel oder einem Projektmanagement-Werkzeug spezifiziert. Dafür sind tiefe Kenntnisse über das zu fertigende Produkt erforderlich, insbesondere sogenannte Fügefolgen zur Produktion, die prinzipiell wie die Bauanleitung eines Lego-Modells funktionieren. Die Anlagenkomponenten müssen in geeigneten Hallen sinnvoll miteinander verbunden werden: mechanisch, hydraulisch, elektrisch und steuerungstechnisch. Viele Prüfungen wie Kollisionsberechnungen oder zur Anlagensicherheit sind durchzuführen. Roboter- und Anlagensteuerungen benötigen Bahnplanungen und Prozessbeschreibungen. Anschließend wird die Anlage errichtet, getestet und in Betrieb genommen.



D. Weidemann und R. Drath

Bei der Anlagenplanung müssen alle Daten zur Beschreibung des Produktes, der Anlage und des Produktionsprozesses beherrscht werden. Dies sind zunächst topologische Informationen wie Hierarchien oder Gruppierungen von Anlagenkomponenten; jede mit Typbeschreibungen, Anforderungsspezifikationen des Betreibers, Eigenschaften, Schnittstellen, Abhängigkeiten und Verbindungen zu anderen Komponenten. Zur Konstruktion und Visualisierung werden geometrische Informationen nicht nur der Komponenten sondern auch der Fabrikationshallen mit fixen Einrichtungen wie Pfeilern, Wänden und Türen, der Ver- und Entsorgungsperipherie wie Strom oder Druckluft sowie des Produktes selber benötigt, in diesem Beispiel die Rohkarosse eines Fahrzeugs. Für die Fabrikationsautomation ist Robotik kritisch. Dafür werden kinematische Zusammenhänge auf Bewegungsbahnen beschrieben und mit Prozessinformationen wie Schweißen oder Kleben angereichert. Zum Verständnis der Anlage, der Fertigungslinien und der Zellen bzw. Module werden Sequenzbeschreibungen verwendet, die mit Signalinformationen angereichert werden und Eingang in die Steuerungsprogrammierung finden. Die einzelnen Komponenten verfügen über ungesteuertes Verhalten, das mit Zustandsdiagrammen beschrieben und zum Beispiel für Simulationen verwendet werden kann. Eine Vielzahl von Geräten ist über Feldbusse verbunden und kommuniziert miteinander. Diese Aufzählung ist nicht abschließend; weitere Aspekte sind zum Beispiel die Versorgung mit Elektrik, Hydraulik und Pneumatik oder die Planung der Materialwege. Symptom und gleichzeitig drängendes Problem der Industrie ist die häufig verwendete „Papierschnittstelle“. „Get rid of the paper interface!“ ist dann auch ein Werbemotto, das dieses Ziel von AutomationML prägnant formuliert. Welche Vielfalt an möglichen Werkzeugketten besteht, verdeutlicht Abb. 1.2 mit einer Auswahl häufig verwendeter Werkzeuge. Für die Planung, Entwicklung und Beschreibung jeder dieser Datenarten stehen gute Werkzeuge zur Verfügung. Ein Hauptproblem dabei besteht jedoch darin, dass der durchgängige Datenaustausch zwischen diesen Werkzeugen heute nicht ausreichend möglich ist. So lässt sich die heutige Engineering-Prozesskette typischerweise nur gezielt innerhalb der Systemlandschaft eines Herstellers und oft nur für Teile der Prozesskette schließen. In der Praxis sieht sich die Fabrikations- wie auch die Prozessautomatisierung heute einer sehr heterogenen Landschaft von SoftwareWerkzeuge für unterschiedliche Engineering-Disziplinen und Projektphasen gegenüber. Dies fängt in der Fertigungsplanung beim mechanischen Design an und zieht sich über Elektroplanung, SPS- und Roboterprogrammierung bis hin zur Erstellung der Anlagenvisualisierung. Die Heterogenität der Software-Landschaft wird durch Inkompatibilität der erzeugten Daten massiv verschärft, und dies ist eine wesentliche Ursache für erheblichen Engineering-Aufwand. Werden beispielsweise Produktionsabläufe in frühen Engineering-Phasen mit Gantt-Charts in Microsoft-Excel-Tabellen oder Projektmanagement-Werkzeugen beschrieben, so finden diese Abläufe bestenfalls wieder in einer einfachen 3D-Simulation Eingang. Für alle späteren Phasen in der Roboter- oder Steuerungsprogrammierung werden diese Daten nicht weiter verwendet, sondern erneut erzeugt – häufig manuell in den speziell dafür vorgesehenen Entwicklungswerkzeugen. Dieses „Abtippen“ der Daten, führt nicht nur

1  Einleitung



Abb. 1.2   Hohe Komplexität durch zahlreiche Software-Werkzeuge

zu erheblichem Mehrfachaufwand, sondern ist konzeptionell fehleranfällig. Die Möglichkeit einer frühzeitigen Qualitätssicherung durch weitergehende Simulationen oder gar durch eine virtuelle Inbetriebnahme wird im Keim erstickt, weil in der heterogenen Umgebung keine ausreichende Versorgung mit grundlegenden Anlagendaten möglich ist. Ein durchgängiger digitaler Engineering-Workflow wird daher als erstrebenswertes Schlüssel-Konzept zum effizienten Planen angesehen. Eine wesentliche Voraussetzung dafür besteht in einer performanten Hardware und ausreichend Speicherkapazität – diese steht heute zu akzeptablen Preisen zur Verfügung. Eine weitere Voraussetzung ist die Verfügbarkeit einer plattformunabhängigen Datenstrukturierungsmethodik – diese ist mit XML ebenso verfügbar. Die softwaretechnische Umsetzung hinkt hingegen deutlich hinterher. Dies erstaunt, wenn man den



D. Weidemann und R. Drath

Blick von der Fertigungsindustrie weg in andere Bereiche lenkt, in denen bereits heute aufwändige virtuelle 3D-Welten intuitiv erstellt, simuliert und plattformübergreifend genutzt werden können: in der Spiele-Industrie. Auch der Wunsch nach vollständigen virtuellen Anlagen ist nicht neu. Die Idee der digitalen Fabrik zum durchgängigen Engineering und zur Simulation der Fertigung ist seit Jahrzehnten sowohl im universitären als auch industriellen Umfeld bekannt. Eine durchgängige computergestützte Planung von Fertigungszellen oder -linien, in der der gesamte geometrische Aufbau, aber auch die Ablauflogistik detailliert geplant, simuliert, geprüft und nahtlos in Betrieb genommen werden können, ist jedoch bis heute technisch nicht gelöst.

1.2.3  Ansätze Für die Realisierung eines durchgängigen Datenaustausches stehen verschiedene Ansätze zur Verfügung, vgl. Drath u. Gohr (2005). Ein gebräuchlicher Ansatz besteht darin, die einzelnen Werkzeuge mit bilateralen Schnittstellen zu versorgen. Dieser Ansatz führt schnell zu ersten Ergebnissen und wird deshalb in der Praxis gerne beschritten. Mit der Zahl der unterstützten Fremdformate steigt jedoch die Zahl der notwendigen Konverter schnell an. So müssten bei drei im Planungsprozess befindlichen Werkzeugen drei Konverter pro Datenaustauschrichtung programmiert werden, für sechs Werkzeuge werden hingegen bereits 15 Konverter benötigt, die stetig gepflegt und aktualisiert werden müssen, siehe Abb. 1.3. Der Wartungsaufwand wird durch die regelmäßig erscheinenden Software-Versionen der einzelnen Werkzeuge weiter verschärft. Dieser Ansatz wird deshalb trotz anfänglicher Attraktivität letztlich durch die hohe erforderliche Zahl der zu entwickelnden und zu pflegenden Schnittstellen vereitelt. Die kombinatorische Explosion versionsübergreifender Konverter vergrößert die erforderliche Komplexität zusätzlich. Abbildung 1.4 stellt dar, wie sich bei Einsatz eines offenen Datenformates die Zahl der Konverter zur Zahl der verwendeten Werkzeuge reduziert. Im Idealfall muss jedes Werkzeug neben seinem nativen Format lediglich das offene Format

Abb. 1.3   Anzahl von Schnittstellen bei bilateralem Datenaustausch

1  Einleitung



Abb. 1.4   Anzahl der Schnittstellen bei Nutzung offener Datenformate

unterstützen. Dies ist primär für Anwender attraktiv, da sie ihre Werkzeuglandschaft so selbst bestimmen und jederzeit optimieren können. Des Weiteren können Hersteller von „kleinen“ Spezialtools am Markt teilnehmen, ohne den immensen Aufwand für die Integration und Pflege proprietärer Formate bezahlen zu müssen. Dadurch sind alle notwendigen Informationen der Planungsprozesskette für den Anwender leicht zugänglich und innerhalb der heterogenen Systemlandschaften transportabel. Ist das verwendete Format ein offener Standard, so ist die Lesbarkeit der Daten über einen langen Zeitraum gesichert und von Einzelunternehmen und deren Werkzeugen unabhängig. Der Lebensdauer einer Planungswerkzeugversion von circa einem Jahr steht die erheblich längere Lebensdauer von typischen prozesstechnischen Anlagen mit 20 bis 30 Jahren gegenüber. Insofern ist die Lesbarkeit von Daten über den gesamten Zeitraum ein immenser Investitionsschutz für Hersteller und Anwender – denn der Wert der Planungsdaten steckt vorrangig in der Ingenieursleistung und nicht im Werkzeug. Diese Daten sind geistiges Eigentum der Planer und Betreiber. Deshalb sollte eine neutrale Speicherung und die Möglichkeit ihrer herstellerunabhängigen Weiterverwendung im Grunde selbstverständlich sein. Niemand würde es heute akzeptieren, wenn ein Foto- oder Office-Werkzeug die darin befindlichen Fotos bzw. Dokumente kapseln würde. Die Versprechen der Hersteller, ihre Daten zukunftskompatibel zu halten, haben sich in der Vergangenheit zu häufig nicht bewahrheitet. Dies ist insbesondere dann der Fall, wenn sich grundlegend neue Technologien durchsetzen, wie beispielsweise beim Übergang von auf geometrischen Grundelementen basierenden Grafiken in die moderne Objektwelt heutiger Planungswerkzeuge – was mit erheblichem manuellem Aufwand verbunden ist. Ein alternativer Ansatz zur Realisierung eines durchgängigen Datenaustausches ist die integrierte Tool-Suite. Unterschiedliche Engineering-Werkzeuge werden hier in ein übergreifendes, umfassendes und führendes Werkzeug bzw. in einer aufeinander abgestimmten Tool-Suite integriert. Auf einer gemeinsamen Datenbank liegen die Planungsdaten konsolidiert vor, womit sich die beschriebenen Datenaustauschprobleme elegant umgehen lassen.



D. Weidemann und R. Drath

Dieser Ansatz wird in der Praxis von einigen Herstellern verfolgt und hat beachtliche Werkzeuge hervorgebracht. Leider können solche Werkzeuge die Bedürfnisse der immer weiter fortschreitenden Spezialisierung der beteiligten Zulieferer im Detail häufig nicht erfüllen. Die Anpassung an individuelle Bedürfnisse oder die Integration weiterer Werkzeuge ist ein aufwändiges Unterfangen. Die Erweiterung von Funktionalität muss in Abstimmung mit den übrigen Werkzeugen und dem gemeinsamen Datenmodell erfolgen. Monolithische Werkzeuge bremsen aufgrund ihrer Komplexität und internen Abhängigkeiten ihre eigene Innovationsgeschwindigkeit im Vergleich zu spezialisierten Werkzeugherstellern ganz von selbst aus. Zudem gerät der Anwender derartiger Werkzeuge leider in unerwünschte und im Laufe der Zeit sogar wachsende Abhängigkeit von ihren Herstellen. Weitere Probleme bei der Einführung derartiger mächtiger, digitaler Planungswerkzeuge bestehen unter anderem sowohl für Betreiber als auch für Lieferanten industrieller Anlagen in der hochpreisigen Lizenzierungspolitik ihrer Hersteller und deren Bedarf nach äußerst leistungsfähiger Hardware, in der Regel teure Workstations, um akzeptable System-Performance zu erreichen. Die hohen Anforderungen an die Computer-Architektur und die damit verbundenen Kosten verhindern die Nutzung solcher Werkzeuge in der Produktion, beispielsweise als Kombination aus Visualisierungssystem und für den Anlagenbediener einfach zu bedienender Roboterprogrammierunterstützung. Wenn aber die Planungswerkzeuge im Feld nicht einsetzbar sind, werden dort andere Werkzeuge verwendet – was zu Dokumentationsdivergenzen führt. Auch hier ist die Datenintegration von großem Wert. Abhilfe könnten hier kleinere Werkzeuge anderer Hersteller schaffen, die sowohl auf die Bedürfnisse der Bediener – in der Regel keine hochspezialisierten Ingenieure – als auch auf die Aufgabe perfekt zugeschnitten sind, zum Beispiel die Parametrierung von Lackierprozessen. Aber auch die Integration solcher Werkzeuge in die genannte Werkzeug-Kette ist häufig nicht oder nur teilweise möglich. Dies wird durch sich derzeit ändernde globale Marktmechanismen verstärkt. Anlagenbetreiber müssen sich aus Effizienzgründen zunehmend für ein Set von Engineering-Werkzeugen entscheiden – und fordern von ihren Zulieferern und Anbietern, diese Werkzeuge ebenso vorzuhalten, damit deren Planungsergebnisse übergeben werden können. Dies führt zu Monopolisierungseffekten. Fremdwerkzeuge können nach Etablierung einer solchen Werkzeuglandschaft nur noch schwer einbezogen werden, selbst wenn diese leistungsfähiger wären. Die Werkzeugbindung lässt dies nicht zu. Für Anbieter wird das teuer. Für mehrere Kunden müssen dann nicht nur die vielfältigen Kundenwerkzeuge vorhalten, sondern auch jeweils Experten bereitstellen und unterschiedliche Bibliotheken pflegen. Angesichts der daraus resultierenden immensen Kosten führt dies zu einer Verdrängung kleiner Anbieter, die sich das nicht leisten können, sowie zur Verdrängung innovativer Softwarehersteller, die am Markt nicht mehr teilnehmen können. Es wird deutlich, dass die Notwendigkeit eines standardisierten, offenen Datenaustauschformats für Planungsdaten besteht und weiter zunimmt. Ein solches Datenformat stellt einen wichtigen Schritt auf dem Weg zur Vision einer durchgängigen Wertschöpfungskette mit einer heterogenen Werkzeuglandschaft dar und ist das Ziel von AutomationML. AutomationML versteht sich zudem als Wegbereiter

1  Einleitung



der virtuellen Inbetriebnahme, die erst durch die Zusammenführung der interdisziplinären Engineering-Ergebnisse möglich wird. Mit AutomationML stehen die Planungsdaten und nicht mehr die Werkzeuge im Vordergrund der Beziehungen zwischen Betreibern und Anbietern. Die Verbindung unterschiedlicher Werkzeuge durch elektronischen Datenaustausch ist für einzelne spezialisierte Aufgabenbereiche wie zum Beispiel für 3D-Daten im CAD-Umfeld schon heute möglich, im Office-Umfeld sogar selbstverständlich. Wer heute Fotos oder Abbildungen austauschen möchte, fragt natürlich nicht mehr nach dem Kameratyp oder Zeichenwerkzeug, mit dem die Bilder erstellt wurden. Das Foto wird einfach als JPG-Datei übermittelt. Man stelle sich nun vor, dass Planungsdaten oder Komponentenbibliotheken für eine neue Fertigungslinie mit Zulieferern ausgetauscht werden sollen, ohne nach dem verwendeten Engineering-Werkzeug zu fragen. Genau dies ist die Ambition von AutomationML.

1.3  Initiatoren Es war die Produktionsplanung von Daimler, die nach effizienteren Planungsmöglichkeiten suchte und dazu die Entwicklung von AutomationML initiierte. Bei der Untersuchung anderer Branchen fanden sich ganz ähnliche Problemstellungen bei der Entwicklung von Computerspielen. Dreidimensionale Figuren bewegen sich in Szenen, verfügen über Gelenke und Ablauflogik und können sogar virtuell miteinander kollidieren. Die komplexen, datenintensiven Visualisierungen erfordern keine teuren Workstations, sondern lassen sich schnell und bequem mit handelsüblichen PCs oder preiswerten Konsolen berechnen und darstellen. Die in dieser Branche verfügbaren Austauschformate genügten allerdings nicht den industriellen Anforderungen an einzuhaltende Toleranzen sowie an die Beschreibung von komplexen Abhängigkeiten in der Kinematik, beispielsweise für einen Sechs-Achs-Roboter. Im Karatespiel ist es egal, ob der Schlag zwei oder drei Zentimeter weiter oben oder unten trifft – im Automobilbau käme damit bestenfalls ein „Hundertwasser-Auto“ zustande. Die Darstellung facettenreicher und präziser Produktionsabläufe und idealerweise deren Weiterverwendung für industrielle Steuerungen sind damit nicht möglich. Nun ist es nicht die vordringliche Aufgabe eines Automobilherstellers, Datenaustauschformate zu entwickeln und zu pflegen und dies keinesfalls unabhängig von seinen Zulieferern. Deshalb lud Daimler im Jahr 2006 führende Hersteller und Anwender von Automatisierungstechnik ein, diese Aufgabe in einem Konsortium zur Entwicklung eines neutralen Datenaustauschformats gemeinsam zu lösen. Seitdem erarbeiten neben Daimler die Firmen ABB, Siemens, KUKA, NetAllied und Zühlke, das Fraunhofer IITB Karlsruhe sowie die Universitäten Karlsruhe und Magdeburg die technischen Konzepte von AutomationML® mit dem Ziel, die Vielzahl der Anforderungen an ein solches Datenformat auszuloten, technisch umzusetzen und praktisch zu erproben.

10

D. Weidemann und R. Drath

In dieses Industrieprojekt bringt jeder Teilnehmer seine Interessen und Erfahrungen ein. ABB, KUKA, NetAllied und die Universität Karlsruhe vertreten Anwendungsfälle der Robotik. Während der Austausch von CAD-Daten schon länger fest etabliert ist, trifft dies nur in Ansätzen auf kinematische Daten und keinesfalls auf Beschreibungen von Fertigungsprozessen zu. Für Hersteller von Anlagenkomponenten wäre es hilfreich, Planungsdaten in nur einem Format zur Verfügung stellen zu können, die effizienter mit eigenen spezialisierten Werkzeugen erstellt werden, um nicht mehr wie heute die kostenintensive Werkzeuglandschaft der Kunden mittragen zu müssen. Siemens, ABB und die Universität Magdeburg verbindet hier das Interesse, erste Ablaufbeschreibungen und Komponentenverhalten möglichst durchgängig mit Signalinformationen und Verschaltungsbedingungen anzureichern, um sie als bestmöglichen Eingang in der Entwicklung von Steuerungs-Code zu verwenden. Abläufe und Verhaltensinformationen helfen allen Teilnehmern, Simulationen künftig besser und realitätsnäher erstellen zu können. Darüber hinaus sind alle Parteien an einer ganzheitlichen Darstellung von Anlagen-Objektmodellen interessiert. Insbesondere das ABB Forschungszentrum und Siemens treiben die Entwicklung einer flexiblen Topologiebeschreibung voran, da diese für ihre weitere Geschäftsausrichtung von Bedeutung ist. NetAllied, das Fraunhofer IITB und Zühlke sehen als Dienstleister schließlich gute Möglichkeiten, mit der Entwicklung von AutomationML bei der Zusammenarbeit verschiedener Engineering-Disziplinen das eigene Profil für die technische Anbindung sowie Prozessverbesserung zu schärfen.

1.4  Ziele von AutomationML 1.4.1  Übersicht Die Zielstellungen der Teilnehmer im AutomationML-Konsortium waren zunächst vielfältig (siehe Abb. 1.5) – ein weiterer Indiz für den Bedarf nach einem neutralen Datenaustauschformat. Diese Ziele wurden systematisch ermittelt, priorisiert und nach ihrem Nutzwert zur Kosteneinsparung beurteilt. AutomationML soll zuerst auf diejenigen Anwendungsfälle fokussiert werden, in denen der Datenaustausch besonders benötigt wird. Umgekehrt sollen bereits funktionierende Datenaustauschszenarien nicht verdrängt werden. Folgende Hauptziele lassen sich formulieren und werden in den folgenden Abschnitten näher erläutert: • Offenheit: AutomationML soll keine Lizenzkosten verursachen, sondern für die Industrie und Forschung frei zur Verfügung stehen. • Datenaustausch im Engineering: AutomationML soll als Basis eines durchgängigen Engineering-Prozesses über alle Phasen und alle Disziplinen der Anla­

1  Einleitung

11

Abb. 1.5   Initiale Ziele von AutomationML

genplanung hinweg dienen. Dies umfasst auch den Datenaustausch zwischen vergleichbaren Werkzeugen innerhalb einer Phase. • Hoher Abdeckungsgrad: Mit AutomationML sollen sowohl einfache Anlagenkomponenten als auch vollständige digitale mechatronische Modelle beschrieben werden können, von der ersten Grobplanung bis zur Inbetriebnahme. • Hohe Marktdurchdringung: AutomationML soll für marktführende Werkzeuge attraktiv sein, soll aber nicht selbst Werkzeugfunktionalität bieten oder einen Planungsprozess vorgeben, sondern vor allem Lücken in heutigen Werkzeugketten schließen. • Aufgreifen bewährter Datenformate: Zur schnelleren und umfassenderen Umsetzung sowie zur Vermeidung unnötiger Wettbewerbssituationen sollen möglichst gute, bereits etablierte Austauschformate für einzelne Disziplinen eingebunden werden. • Erweiterbarkeit und Standardisierung: Mit Blick auf eine langfristig belastbare, industrielle und breit angelegte Nutzung soll AutomationML erweiterbar sein und zudem einem anerkannten Standardisierungsgremium zugeführt werden.

12

D. Weidemann und R. Drath

1.4.2  Offenheit Ein erklärtes Ziel für das AutomationML-Konsortium besteht darin, AutomationML als offenes, lizenzfreies, herstellerneutrales und standardisiertes Datenformat zum Austausch von Anlagendaten zu entwickeln und zur Verfügung zu stellen. Dies gilt als wesentliche Voraussetzung für die Verbreitung und Akzeptanz eines neuen Datenformates. Offenheit bedeutet dabei nicht nur freien Zugang zu den Ergebnissen für jeden Interessierten, sondern auch die Mitgestaltungsmöglichkeit für jede interessierte Partei durch Mitarbeit in einem Konsortium.

1.4.3  Datenaustausch im Engineering AutomationML soll Planungsdaten werkzeugübergreifend sowohl innerhalb von Planungsphasen als auch phasenübergreifend nutzbar machen. Dazu müssen die Planungsdaten standardisiert strukturiert und modelliert werden, damit sie Werkzeuge und Planungsphasen passieren können. Entwickler sprechen in diesem Zusammenhang gerne von Tool-Chains oder Werkzeugketten. In den aufeinander folgenden Phasen sollen bereits erreichte Engineering-Ergebnisse mit dem nächsten Werkzeug der Kette weiter angereichert und verfeinert werden. Bereits dieses Ziel wird heute vielfach nicht erreicht. Zu unterschiedlich sind die in den verschiedenen Unternehmen eingesetzten Werkzeugketten, zu komplex ist die Aufgabenstellung, für alle eingesetzten Werkzeugkombinationen jeweils passende Verbindungen zu programmieren. Beispiele für dieses Ziel liegen auf der Hand. Heute werden Ablaufbeschreibungen häufig in Tabellenkalkulationsprogrammen wie Microsoft Excel erstellt, aber kaum direkt weiter verwendet. Dabei könnten sie eine gute Informationsquelle für Simulationsprogramme dafür sein, wie die Anlage generell funktionieren soll. Sie könnten in Impuls-Diagramme umgewandelt und mit Signalinformation angereichert, beziehungsweise mit Rampen zur Darstellung von Zeitverhalten bei Statusübergängen verfeinert werden. Diese könnten um Schleifen oder bedingte Abläufe beispielsweise zur Fehlerbehandlung ergänzt werden, um als bereits realitätsnahe Vorgabe in die SPS-Programmierung einzufließen. Aus der Vielzahl denkbarer Szenarien ist schließlich der bidirektionale Datenaustausch ein besonders häufig gewünschter Anwendungsfall. 3D-Modelle können zwischen CAD-Werkzeugen und mechanischen Simulationswerkzeugen in unterschiedlichen Detailstufen transferiert werden, komplette virtuelle Fertigungszellen zwischen verschiedenen, mechanischen Simulationswerkzeugen sowie Fertigungsdaten zwischen Layout- und Elektroplanungswerkzeugen. Die Weiterverwendung kinematischer Informationen aus Simulationsprogrammen in den Roboterprogrammier-Werkzeugen der Hersteller ist ebenfalls von zentraler Bedeutung. Bei der Übertragung der Zellenbeschreibung müssen Kinematikdaten heute vielfach manuell übertragen werden – mit entsprechendem Engineering-Aufwand.

1  Einleitung

13

Der Datenaustausch innerhalb einer Phase betrifft die Verfügbarkeit und Verteilung von Daten in vergleichbaren Anwendungen, aber mit unterschiedlichen Werkzeugen. Wenn ein Komponentenhersteller seine Produkte verschiedenen Kunden anbieten möchte, erfolgt dies heute in der Regel individuell in der Welt der Werkzeuge, die von den Kunden vorgegeben werden. Idealerweise soll die angebotene Hardware-Komponente als vollständiges Software-Pendant zur Einbindung in elektronischen Komponentenbibliotheken zur Verfügung stehen und nur einmal in einer standardisierten Form beschrieben werden. Vollständigkeit wird vor allem mittels geometrischer Information, gegebenenfalls kinematischem Aufbau, mechanischen, elektrischen und hydraulischen Schnittstellen sowie deren Verhalten erreicht. Die umgekehrte Vorstellung, dass Komponentenbibliotheken in einem EngineeringWerkzeug zum Beispiel über einen Tree-View eingebunden werden, aus denen einzelne Elemente leicht mit Drag-and-Drop an der richtige Stelle in der Anlage positioniert und mit benachbarten Komponenten verknüpft werden können, ist zudem vielversprechend.

1.4.4  Hoher Abdeckungsgrad Mit AutomationML sollen sowohl einfache Anlagenkomponenten als auch vollständige digitale mechatronische Modelle beschrieben werden, von der ersten Grobplanung bis zur Inbetriebnahme. AutomationML ist als „Glue for Seamless Automation Engineering“ zu verstehen. Damit soll nicht nur eine bessere Simulation der Anlage, sondern längerfristig sogar die virtuelle Inbetriebnahme realisiert werden. Dazu können erstmalig alle relevanten Anlagendaten in einem frei zugänglichen Format gespeichert und geeigneten Applikationen zur Verfügung gestellt werden. Dies ist bisher nur durch aufwändiges Zusammenfügen und Interpretieren einer Vielzahl proprietärer Daten möglich und damit in der Konsequenz häufig unvollständig und nur bedingt aussagekräftig. Auch wenn die virtuelle Inbetriebnahme heute noch eine Vision ist, so ist ihre Motivation doch bestechend: die Anlage sehen, bevor sie gebaut wird; Fehler erkennen, bevor tonnenschwere Maschinen installiert werden; die Anlage ohne Gefahr für Mensch und Material testen; die extrem aufwändige und teure Vorinbetriebnahme verkürzen oder sogar ganz einsparen. Die zentrale Herausforderung beim Entwickeln eines solchen standardisierten Datenformates ist somit, seine Inhalte festzulegen und abzustimmen. So sollen beispielsweise komplette fertigungstechnische Komponenten vom Spanner bis zur kompletten Rohbauzelle mit einfachen Mitteln möglichst vollständig abgebildet werden können. Aufgrund der am Markt verfügbaren Datenformate ist festzulegen, welche dieser Datenformate von AutomationML aufgegriffen und in AutomationML integriert werden, bzw. ob sie als externe Dokumente auszulagern sind. Für solche Daten muss AutomationML individuell erweiterbar sein, da diese für den Anwender nur in speziellen Kontexten wichtig sind oder bei unterschiedlichen Nutzern verschieden verwendet werden. Beispielsweise verfügen alle Automobilhersteller über ihre eigenen Bezeichnungen für Anlagenkomponenten, die aufgrund

14

D. Weidemann und R. Drath

ihrer langen Bewährung einen hohen Wert darstellen und auch weiterhin für die Entwicklung und Prüfung genutzt werden sollen.

1.4.5  Hohe Marktdurchdringung AutomationML ist umso erfolgreicher, je mehr Export- und Import-Schnittstellen für marktführende Softwarehersteller angeboten werden. Das wichtigste ökonomische Ziel der Entwicklung ist daher die Erreichung einer hohen Marktdurchdringung. Herstellerneutralität unterstützt dieses Ziel. Um die Finanzierung der fortlaufenden Weiterentwicklung zu sichern, ist der produktive Einsatz von AutomationML von der ersten Version an vorgesehen und notwendig. Dies erfordert eine strikte Priorisierung der zu unterstützenden Anwendungsfälle. Ein sehr schneller Nutzen kann beispielsweise erzielt werden, wenn Anlagen oder Anlagenteile bereits auf einfachen PCs und Laptops statt auf komplexen Workstations mit teuren Einzelplatzlizenzen visualisiert werden können. Ein weiterer Aspekt für eine erfolgreiche Marktdurchdringung ist ein breites Fundament in der Ausbildung an Hochschulen. Dies ist ein wesentlicher Ausgangspunkt für Innovationen durch neue Applikationen oder Ausgründungen. Das AutomationML-Konsortium stellt für die Verbreitung von AutomationML eine Reihe von Dokumenten, Software und Anleitungen zur Verfügung (AutomationML 2009), vgl. Kap. 6. Da sich für Datenaustauschformate XML ohne echte Alternative durchgesetzt hat, basiert AutomationML darauf. Dieser Ansatz verspricht den meisten Erfolg im flächendeckenden Know-how-Aufbau.

1.4.6  Kombination bewährter Datenformate Zur schnelleren Umsetzung und zur Vermeidung unnötiger Neuerfindung soll sich AutomationML auf existierenden und etablierten Standards abstützen. Für einzelne Engineering-Disziplinen gibt es bereits gute Lösungen. Für die Strukturierung der Anlagenhierarchie wird das Datenformat CAEX gemäß IEC 62424 verwendet (IEC 62424 2008), Geometrie- und Kinematikinformationen mit COLLADA™ der Khronos Group abgebildet (Khronos 2009), Verhalten und Abläufe werden mit PLCopen XML (PLCopen 2009) auf der Basis der IEC 61131-3 beschrieben. AutomationML kann sich somit vor allem auf die Kombination und Weiterentwicklung erfolgreicher Standards konzentrieren. Der Mehrwert von AutomationML besteht technisch in der geschickten Referenzierung zwischen den Standards und organisatorisch in der Festlegung, wie diese konkret zur Beschreibung von greifbaren und interpretierbaren Anlagenkomponenten verwendet werden können. Darüber hinaus ist das Engagement aller Mitglieder der AutomationML-Gruppe durch deren Mitarbeit in den unterschiedlichen Gremien zur Weiterentwicklung der verwendeten Standards erforderlich.

1  Einleitung

15

Die Verwendung bereits verbreiteter und etablierter Standards ist somit eine sehr wichtige Anforderung der AutomationML-Gruppe. Idealerweise bedeutet dies in der praktischen Anwendung, dass Benutzer weiterhin ihre bewährten Standards zum Datenaustausch verwenden und diese zusätzlich leicht in größere Strukturen einbringen können. Die schon erbrachte Bewährung und der Investitionsschutz für den Anwender müssen allerdings durch einen gewissen Aufwand zur Vermeidung von Redundanzen sowie die Angleichung und den Austausch interner Kenntnisse der eingebundenen Standards erkauft werden. Die Auswahl der verwendbaren Datenformate ist kritisch, denn viele Standards sind mit kommerziell hinderlichen Randbedingungen versehen. Um die gewünschte Standardisierung und die angestrebte breite Marktakzeptanz zu erreichen, kommen nur lizenzfreie und offene Datenformate in Betracht. Das Format sollte sich nicht im Besitz eines einzelnen Unternehmens befinden und möglichst viele Teilbereiche der Prozesskette in der Anlagenplanung abdecken. Gleichzeitig sollte es nicht zu sehr spezialisiert sein und wie schon erwähnt bereits eine praktische Bewährung, Reife, Akzeptanz und Marktverbreitung erreicht haben.

1.4.7  Erweiterbarkeit und Standardisierung Mit Blick auf eine langfristig belastbare, industrielle und breit angelegte Nutzung soll AutomationML einem anerkannten Standardisierungsgremium zugeführt werden. Um sich ändernden Anforderungen des Marktes folgen zu können, soll AutomationML zudem konzeptionell erweiterbar gestaltet sein.

1.4.8  Abgrenzung In die Diskussion über die Ziele von AutomationML gehört jedoch auch der bewusste Ausschluss von Zielen. AutomationML ist kein Software-Werkzeug und kann keine softwarerelevanten Funktionen übernehmen. Über einfache Konsistenzregeln hinaus kann AutomationML beispielsweise nicht feststellen, ob die Zusammenstellung der Komponenten in einem Dokument sinnvoll ist. Die Verwendung von AutomationML ersetzt keine Überprüfung, ob Komponentenversionen vernünftig verwendet werden, Daten doppelt auftreten, nicht übereinstimmen, oder ob sie aus welchen Gründen auch immer veraltet sind. Die Konsistenz von Daten ist eine Werkzeug-Leistung, AutomationML kann lediglich die aus Werkzeugen stammenden Daten abbilden. Fehler in AutomationML-Daten entstehen somit prinzipiell zuvor im Werkzeug oder bei der Transformation nach AutomationML. Weiterhin trifft AutomationML keine Festlegung für einen Engineering-Prozess. Das zentrale Ziel ist das Schließen von wesentlichen Lücken in bereits existierenden Werkzeugketten mit ihren existierenden Workflows. Es gibt weder eine Aufforderung, bestimmte Werkzeuge in bestimmter Form anzuwenden, noch eine

16

D. Weidemann und R. Drath

Festlegung, welche Schritte mit welchen Voraussetzungen zu erbringen sind, um bestimmte Engineering-Ergebnisse zu erreichen. AutomationML soll etablierte Prozesse technisch besser unterstützen oder neue Prozesse ermöglichen. Nicht zuletzt liefert AutomationML kein Weltmodell des Engineering oder eine allumfassende Ontologie beziehungsweise Datenbankstruktur für alle EngineeringDisziplinen. Zu vielfältig sind die firmeneigenen, nationalen oder internationalen Standards, zu unterschiedlich die Semantiken zum Beispiel von Geräteeigenschaften. AutomationML kann jedoch vorhandene und künftige Standards abbilden. Diese festzulegen, zu kennen, zu interpretieren und auszutauschen obliegt allerdings den am Datenaustausch teilnehmenden Werkzeugen und Projektpartnern. Toolhersteller können AutomationML verwenden, um gemeinsame Daten mit anderen Werkzeugen auszutauschen, partiell zu verfeinern und sie dann erneut konsistent zusammen zu führen. Die dazu notwendigen Funktionen sind jedoch Werkzeugleistung und dürfen nicht mit AutomationML verwechselt werden.

1.5  Vergleich von Planungsprozessen Das Anlagen-Engineering für prozesstechnische und fertigungstechnische Anlagen wird in der Praxis üblicherweise strikt unterschieden. Dies ist historisch bedingt und spiegelt sich unter anderem in unterschiedlich spezialisierten Industrieunternehmen, aber auch in separaten Konferenzen, Lehrstühlen, Instituten und Fachzeitschriften wider. Bei näherer Betrachtung ist festzustellen, dass die auftretenden Probleme jedoch recht ähnlich sind und folglich auch mit ähnlichen Methoden gelöst werden können. Im Folgenden werden typische Planungsprozesse für fertigungsund prozesstechnische Anlagen erläutert und verglichen.

1.5.1  Ein typischer Planungsprozess in der Automobilindustrie Der heutige Anlagenbau im Automobilbau ist von unzähligen Herausforderungen getrieben. Der Markt fordert immer kürzere Entwicklungszyklen, die vor kurzem noch circa sieben Jahre und heute nur noch etwa fünf Jahre betragen. Das bedeutet weniger Zeit für die Produkt- und Produktionstechnologieentwicklung. Dies hat in der Regel beim Start der Inbetriebnahme einen niedrigeren Reifegrad der Produktionstechnologien zur Konsequenz, immer häufiger in Verbindung mit der sogenannten „Entwicklung auf der Baustelle“. Inbetriebnahmezeiten vor Ort werden weiter reduziert und gehen bei Nichteinhaltung des vertraglich vereinbarten Zeitrahmens mit deutlich höheren Konventionalstrafen für den Lieferanten einher. Für alle beteiligten Unternehmen ist der Koordinationsaufwand sehr hoch und steigt durch die Globalisierung weiter. Er wird durch die weit fortgeschrittenen Unterbeauftragungen an kleinste, ausländische Unternehmen mit entsprechendem babylonischem Sprachengewirr noch verstärkt. Schließlich erfolgen Produktänderungen

1  Einleitung

17

Abb. 1.6   Schematischer Planungsprozess im Automobilbau

in späten Phasen des Planungsprozesses, zum Beispiel durch erweiterte Crash-Anforderungen. In Abb. 1.6 wird der Planungsprozess im Automobilbau von der Entwicklung des Produkts bis zur Produktion schematisch dargestellt. Prinzipiell kann der Weg von der Skizze bis zum realen Fahrzeug in drei Phasen aufgeteilt werden. Zunächst erfolgt in Phase 1 die Produktentwicklung und digitale Fabrikplanung, in Phase 2 die Auftragsvergabe und schließlich in Phase 3 die Realisierung und Produktion. Phase 1 beinhaltet die Produktentwicklung, das Fahrzeugdesign und die digitale Vorplanung der Produktionsanlagen. Abbildung 1.7 gibt einen Einblick in ihre Abläufe und Tätigkeiten.

Abb. 1.7   Phase 1 – Fahrzeugentwicklung und digitale Fabrikplanung

18

D. Weidemann und R. Drath

So wird das Fahrzeug im ersten Schritt entwickelt und konstruiert, wobei vielfach die klassischen 3D-Konstruktionswerkzeuge eingesetzt werden. Neben der Produktform sind das Produktmaterial und die Fügefolge für die spätere Produktionsplanung wichtig. Die Fügefolge legt hierbei den Zusammenbau des Produktes und damit auch die Reihenfolge der Arbeitsschritte fest. Basierend auf den in der Fahrzeugentwicklung erzeugten Daten kann nun die digitale Fabrikplanung mit der Grobplanung der Produktionsanlagen beginnen. Die Ergebnisse der digitalen Fabrik sind vielfältig und beinhalten unter anderem die Hallenplanung, Zellen-Layouts, Erreichbarkeitsuntersuchungen, Produktionsabläufe, Materialflüsse, Taktzeituntersuchungen und Roboterbahnen sowie eventuell Roboterprogramme. Phase 2 stellt mit der Auftragsvergabe den nächsten Meilenstein dar, bei der ein oder mehrere Lieferanten für die Fertigung der Produktionsanlagen ausgewählt werden. Große Teile dieser Vorplanung dienen als Vorlage für Lieferanten, auf deren Basis einkommende Angebote gesichtet und bewertet werden. Dies ist kritisch, denn für die Angebotserstellung werden häufig die beim OEM verwendeten Werkzeuge vorgeschrieben. Die Ergebnisse der Vorplanung werden den Lieferanten zur Verfügung gestellt und deren Umsetzungsideen sind im selben proprietären Datenformat einzureichen. Teilweise wird sogar die Version des zu verwendenden Werkzeugs vorgeschrieben. Sobald ein Anlagenlieferant anbieten möchte, bedeutet dies für ihn die teure Anschaffung der entsprechenden Software sowie Ausbildung und Vorhaltung eines Teams. Wirklich problematisch wird es, wenn der Lieferant mehrere Kunden mit in der Regel unterschiedlichen Werkzeugen bedienen möchte. Die Anlagenlieferanten stehen somit vor der Wahl, alle vorhandenen und vom Kunden vorgegebenen Systemlandschaften mit ihren immensen Lizenz- und Schulungskosten vorzuhalten oder nicht anbieten zu können. Anlagenbetreiber verursachen und beteiligen sich damit indirekt an den daraus entstehenden Kosten. Nach der Auftragsvergabe erfolgt in der dritten Phase die Realisierung und Produktion, in der erneut in verteilten Prozessen gearbeitet wird (siehe Abb. 1.8). Nach der parallelen mechanischen und elektrischen Konstruktion folgt die jeweilige Fertigung. Sind sowohl die mechatronischen Komponenten als auch die Software vor Ort, kann der Inbetriebnahmeingenieur das Zusammenspiel der gesamten Produktionszelle testen und optimieren. Die Krux hierbei ist der erneute Einsatz einer Vielzahl verschiedener Werkzeuge, die aus unterschiedlichen Fachrichtungen wie der mechanischen und elektrischen Konstruktion stammen, ihre Ergebnisse aber auf den gleichen Basisinformationen aufbauen sollen, nämlich den Ergebnissen der digitalen Fabrikplanung. Schaut man sich den kompletten Planungsprozess an, so wird schnell klar, dass heutzutage nach wie vor in allen Prozessschritten viele Informationen mündlich, als individuelle E-Mail oder als Ausdruck auf Papier weitergegeben werden und somit nicht für das digitale „Informations-Recycling“ nutzbar sind. Der wichtigste Grund hierfür sind die von verschiedenen Werkzeugen erzeugten lokalen und proprietären Daten, die durch kein anderes Werkzeug interpretierbar sind. Selbst die von den Herstellern angepriesenen Qualitäten ihrer so bezeichneten durchgängigen

1  Einleitung

19

Abb. 1.8   Phase 3 – Realisierung und Produktion

Werkzeug-Plattformen können ihren eigenen Ansprüchen bezüglich Datenweitergabe meist nicht genügen. Eine wesentliche Voraussetzung, um die beschriebenen Probleme im modernen automobilen Anlagenbau in den Griff zu bekommen, ist die Austauschbarkeit der notwendigen Informationen über Werkzeuggrenzen hinweg. AutomationML setzt an diesem Punkt an.

1.5.2  Ein typischer Planungsprozess in der Prozessindustrie Die Planung prozesstechnischer Anlagen ist ebenfalls ein komplexer Prozess mit Beteiligung einer Vielzahl von Berufsgruppen und Werkzeugen. Wie in der Fertigungsplanung werden Anlagen typischerweise mit Hilfe mehrerer Unternehmen und Subunternehmen geplant, errichtet und in Betrieb genommen. Im zeitlichen Verlauf der Planung erfolgt eine zunehmende Anreicherung, Verdichtung und Verknüpfung von Informationen. Hinzu kommt eine zunehmende zeitliche Verzahnung der einzelnen Phasen, was angesichts des steigenden Kosten- und Qualitätsdrucks zu weiteren Schleifen im Engineering-Prozess führt. Abbildung 1.9 stellt ein vereinfachtes sequentielles Phasenmodell dar. Nach einer Angebotsphase erfolgt die Verfahrensplanung, in der Verfahrenstechniker die Anforderungen an den Anlagenaufbau spezifizieren. Ein wesentliches Ergebnis dieser Phase stellt das R&I-Fließbild dar, das als Eingangsdokument an die

20

D. Weidemann und R. Drath

Abb. 1.9   Phasen bei der Planung verfahrenstechnischer Anlagen

nächste Phase übergeben wird, in der Automatisierungstechniker die Planung der Automatisierungseinrichtungen und Leittechnik übernehmen. Im Anschluss daran erfolgen Installation und Inbetriebnahme. Abbildung 1.10 gibt einen Einblick in die Phase der Verfahrensplanung. Die hier aufgeführten Aktivitäten von der Simulation bis zu ersten Funktionsplänen sind

Abb. 1.10   Bereiche innerhalb der Phase Verfahrensplanung

1  Einleitung

21

wichtige Aufgaben von Verfahrensingenieuren. Das R&I-Fließbild ist das zentrale Dokument, um Informationen zur Verfahrenstechnik, Rohrleitungstechnik und Anforderungen an die Prozessleittechnik zusammenzuführen. Es bildet die Grundlage für die Abstimmung zwischen den Gewerken, sein wachsender Informationsgehalt wird anhand der fortschreitenden „Schwärzung“ der Grafik deutlich. Es ist bemerkenswert, dass innerhalb der einzelnen Phasen heute bereits eine Reihe leistungsfähiger Planungswerkzeuge zur Verfügung stehen, die Phasengrenzen jedoch kaum überschritten werden. Erste phasenübergreifende Werkzeuge sind zwar verfügbar, weisen aber Schwächen in der Funktionalität für einzelne Phasen gegenüber spezialisierten Expertenwerkzeugen auf. In Abb. 1.10 wird deutlich, dass während der Verfahrensplanung Planungstätigkeiten erfolgen, die klassischerweise der Leittechnik zugeordnet werden: es entstehen erste Funktionspläne. Für den nahe liegenden Gedanken, diese Pläne inklusive den im R&I-Fließbild niedergelegten Leittechnikanforderungen direkt in der Leittechnikplanungsphase weiter zu verwenden, existiert bis heute keine etablierte Datenaustauschlösung. Noch immer steht die ausgedruckte Grafik im Vordergrund (Felleisen 2001). Ein Großteil der R&I-Fließbilder wird mit Grafikwerkzeugen erstellt, die mit der Intention des Ausdrucks auf Papier entwickelt wurden – der bereits genannten „Papierschnittstelle“. Grafikinformation ist in einem elektronisch vernetzten Datenmodell, das andere Werkzeuge weiterverwenden könnten, aber nur von nachrangiger Bedeutung. Es ist äußerst schwierig, die einmal getroffene Ausrichtung in einem Software-Werkzeug nachträglich zu korrigieren. Trotz der Vielzahl von Einzelaktivitäten innerhalb dieser Phase haben sich Werkzeuge etabliert, die ihren gesamten Funktionsumfang umsetzen können. Dies verdeutlicht, dass die Werkzeugentwicklung ihren Ursprung in einzelnen Entwicklungsphasen hat und in ihrer Evolution durch eine Zunahme von Features und Funktionalität gekennzeichnet ist. Der Grund ist nahe liegend: die Differenzierung zu Konkurrenzprodukten erfolgt zunächst über Funktionsreichtum. Dies gilt ebenso für Werkzeuge der Leittechnikplanung. Die Integrierbarkeit und Offenheit solcher Werkzeuge mit andern Werkzeugen und anderen Phasen stellt für die Werkzeughersteller zunächst keinen Vorteil dar, sondern wird als Wettbewerbsnachteil verstanden. Deshalb ist der gewünschte durchgängige Datenaustausch über Phasengrenzen hinweg noch immer durch elektronisch nicht zu verarbeitende, grafische Beschreibungsmittel wie R&I-Fließbilder oder durch proprietäre Datenformate, „selbst gestrickte Einzellösungen“, Tabellen oder Listen geprägt. Gerade die Schnittstelle zwischen Verfahrens- und Leittechnikplanung verdeutlicht die Notwendigkeit von Datenaustauschlösungen. Selbst moderne Verfahrensplanungswerkzeuge, die seit Jahren mit Objektmodellen arbeiten, verfügen über keine etablierten Schnittstellen zum Datenaustausch. Das Dilemma wird in Abb. 1.11 deutlich: der Austausch von Objekthierarchien und Grafiken aus der Verfahrensplanung erfolgt mit denen der Leittechnikplanung nach wie vor über proprietäre „Hintertüren“, trotz ihrer Ähnlichkeit. Von einem durchgängigen Informationsfluss ist dies noch weit entfernt. Allerdings wächst der Druck der Anwender auf die Werkzeughersteller, denn der Datenaustausch erweist sich zunehmend als Flaschenhals in der Engineering-

22

D. Weidemann und R. Drath

Abb. 1.11   Schnittstelle zwischen Verfahrens- und Leittechnikplanung

Wertschöpfungskette. Die von den Betreibern geforderte Dokumentationsqualität ist mit derart verteilten, nicht austauschbaren Engineering-Informationen kaum wirtschaftlich realisierbar. Die Offenheit von Werkzeugen entwickelt sich deshalb zu einem Qualitätsmerkmal und ist eine wesentliche Motivation für Standardisierungsaktivitäten. Die Differenzierung von Werkzeugen wird nach Ansicht der Autoren in Zukunft weniger über den mittlerweile gereiften Funktionsreichtum, sondern vielmehr über ihre Integrationsfähigkeit und Offenheit innerhalb einer heterogenen Werkzeuglandschaft erfolgen.

1.5.3  Gemeinsamkeiten von Fertigungs- und Prozesstechnik Auch wenn sich Fertigungs- und Prozesstechnik in ihren technischen Lösungen unterscheiden, werden fachübergreifend viele Gemeinsamkeiten deutlich. In beiden Industriezweigen unterliegt die Anlagenplanung einer starken Phasenausprägung. Innerhalb jeder Phase existiert zwar eine starke Toolunterstützung, aber trotz wachsendem Engineering-Anteil und zunehmender Zahl von Sublieferanten stehen keine belastbaren Datenaustauschlösungen über Phasengrenzen hinweg zur Verfügung – erst recht nicht zwischen konkurrierenden Werkzeugen. Diese Gemeinsamkeiten bilden die Grundlage der branchenübergreifenden Herausforderungen der Anlagenplanung, sowohl in der Fertigungs- als auch in der Prozessindustrie. Mögliche und vielleicht zentrale Ursache für die unzureichenden Möglichkeiten zum Datenaustausch in beiden Industriezweigen ist die gleichartige evolutionäre Entwicklung der Phasenseparation. Mit der Spezialisierung der

1  Einleitung

23

unterschiedlichen Gewerke haben sich passende Werkzeuge entwickelt. Die Arbeit innerhalb der einzelnen Phasen wurde durch diese Werkzeuge zwar erheblich beschleunigt, mit reifendem Funktionsumfang sank jedoch zugleich die funktionelle Differenzierbarkeit der verschiedenen Werkzeuge innerhalb eines Gewerkes. Als Engpass verbleibt der Datenaustausch zwischen den Gewerken. Der Wert der Engineering-Daten liegt somit zunehmend in deren „Wiederverwendbarkeit“ im Sinne einer Wertschöpfungskette; der Datenaustausch wird zur funktionellen Basis für eine Reihe weiterer Zukunftstrends.

1.5.4  Problematik heterogener CAE-Systeme In den vorangegangenen Abschnitten wurde das komplexe Zusammenspiel der verschiedenen Gewerke beschrieben. Eine Vielzahl von Fachgebieten ist demnach mit eigenen Werkzeugen verknüpft. Könnten die Aufgaben im Bereich der Vorplanung der Digitalen Fabrik noch weitestgehend mit den Produkten eines einzelnen Softwareherstellers erledigen werden, so ist dies während der Realisierungsphase nicht mehr möglich, da hier verschiedene technische Disziplinen zu koordinieren sind. In der Elektrik und der Automatisierungstechnik werden vor allem elektrische Schaltpläne, SPS-Programmcode, Roboter-Programmcode sowie VisualisierungsProgrammcode erstellt und optimiert. Die in der Mechanik durchzuführenden Tätigkeiten beinhalten vor allem die Betriebsmittelkonstruktion. In beiden Disziplinen ist abschließend noch eine Dokumentation zu erstellen. Bei allen Aufgaben müssen Anlagenlieferanten Kundenstandards berücksichtigen, die in der Regel deutlich voneinander abweichen. Dies betrifft üblicherweise alle Planungsinhalte beginnend bei einheitlicher Bezeichnungssystematik bis hin zu Vorgaben hinsichtlich der einzusetzenden SPS-Programmbausteine. Anlagenbauer müssen deswegen einen hohen logistischen und koordinierenden Aufwand zur Erhaltung der Datenaktualität betreiben. Beim Übergang von Phase zu Phase können Planungsergebnisse bisher häufig nur in Papierform weiter gegeben werden, ihre Weiterverwendung ist de facto nicht effektiv. Hinzu kommt, dass sich die Automatisierungsplanung stetig weiter entwickelt. Jüngstes Beispiel ist das Funktionale Engineering. Diese Disziplin wird durch neue Werkzeuge repräsentiert, die auf einer elektrischen Komponentenbibliothek und einer groben Anlagenbeschreibung in Form eines 2D- oder 3D-Layouts basieren. Als Ergebnisse werden Schaltpläne, Visualisierungscode und sogar SPS-Programme zum großen Teil automatisiert erzeugt. Die Feinplanung erfolgt danach analog zur mechanischen Planung in spezialisierten Werkzeugen. Abbildung 1.12 zeigt den beschriebenen Prozess von der digitalen Fabrik zur Automatisierungstechnik. Dieser Prozess kann nur wirklich erfolgreich gelebt werden, wenn durch Informationsaustausch zwischen den Schritten unnötige Doppelarbeit vermieden wird – ausreichende Qualität der verfügbaren Software-Werkzeuge vorausgesetzt. Um Schaltpläne oder SPS-Programme mit möglichst kleiner Vorbereitung weitestgehend automatisiert erstellen zu können, muss die Struktur

24

D. Weidemann und R. Drath

Abb. 1.12   Von der digitalen Fabrik zur Automatisierungstechnik

der Produktionsanlagen digital übertragen werden, dabei sind zusätzliche Informationen wie 2D-Layout oder Ablaufbeschreibungen von Vorteil. Derzeit ist die bereits angesprochene Papierschnittstelle die wichtigste generell verfügbare Übertragungsmöglichkeit. Dies führt dazu, dass inhaltlich gleiche Daten doppelt und überwiegend manuell erfasst werden müssen. Dabei kann eine fehlerfreie Weitergabe der Daten nicht durchgängig sichergestellt werden. Der Traum einer durchgängigen Werkzeug-Landschaft, deren Umsetzung von führenden Herstellern schon länger angekündigt wird, hat sich bis heute nicht erfüllt. Er wird sich vermutlich auch nie gänzlich erfüllen, denn den Bestrebungen nach Differenzierung und Spezialisierung von Komponentenherstellern kann ein monolithisches und generisches Werkzeug kaum folgen. Außerdem kann die Austauschbarkeit der Werkzeuge für ihre Hersteller kaum von Interesse sein. Gerade bei den großen Automobilunternehmen und Herstellern prozesstechnischer Anlagen sind heterogene Werkzeuglandschaften auch deswegen Realität. Es gibt eine ganze Reihe von Produkten konkurrierender Werkzeughersteller, die kaum Möglichkeit zum Daten- beziehungsweise Informationsaustausch bieten. Die negativen Folgen sind für alle Beteiligten mit großem Aufwand und hohen Kosten verbunden. So entsteht beim Fahrzeughersteller vermeidbare Doppelarbeit, beispielsweise durch mehrfaches Planen von Roboterzellen in verschiedenen Werkzeugen, sowie eine erhöhte Fehlerhäufigkeit aufgrund mangelnder elektronischer Abgleichsfunktionalitäten. Daher sollten die Hersteller von Engineering-Werkzeugen zukünftig eine gewisse Kompatibilität zu anderen Werkzeugen gewährleisten, also auch zu

1  Einleitung

25

Konkurrenzprodukten, wenn sie an möglichst vielen Schritten des Planungsprozesses mitwirken wollen. Mit dem Aufbau aus offenen Datenstandards bietet AutomationML sehr gute Voraussetzungen für CAE-Hersteller und -Anwender, sowohl den eigenen Kundenkreis zu erweitern, als auch die eigenen Daten mit den am besten geeigneten Werkzeugen zu erstellen und zu verändern, ohne sich nur an den vorgegebenen zentralen Werkzeugen orientieren zu müssen.

1.6  AutomationML in a Nutshell: ein Architekturüberblick 1.6.1  Architekturanforderungen und Architekturübersicht Generelles Ziel von AutomationML ist die möglichst vollständige Beschreibung kompletter Anlagen mitsamt den dort enthaltenen Komponenten über alle Engineering-Disziplinen und -Phasen hinweg. Diese äußerst ambitionierte Zielsetzung lässt sich kaum ohne strikte Vorgaben an die Architektur erreichen. AutomationML muss wesentliche Anwendungsfälle möglichst frühzeitig unterstützen, da eine vollständige und valide Darstellung aller Anlagendetails kurzfristig kaum erreichbar ist. Die Motivation der Industriepartner ist es, zeitnah wirtschaftlich nutzbare Verbesserungen zu erzielen. AutomationML ist XML-basiert und bindet bereits etablierte, offene und kostenfreie XML-basierte Standards für einzelne Disziplinen ein. Beide Architekturvorgaben zielen auf hohe Akzeptanz und schnellere Entwicklung ab, da AutomationML somit am hohen Durchdringungsgrad des weltweit anerkannten XML-Standards partizipiert. Mit der Nutzung der W3C-Empfehlungen, wie zum Beispiel Zeitstempel gemäß UTC, sind viele Syntaxfragen bezüglich Datumsformaten von Vornherein gelöst und bedürfen keiner weiteren Spezifizierung. Die unterschiedlichen Dokumentarten können nun in erheblichem Umfang automatisch mit Hilfe von frei verfügbaren Werkzeugen auf Konformität geprüft werden. Diese Prüfung umfasst allerdings nur die Syntax – semantische und konzeptionelle Planungs-Fehler können auf der Basis einer Schemadefinition nicht automatisch erkannt werden; man kann beispielsweise grammatikalisch korrekt völlig sinnlose Anlagenbeschreibungen erstellen. Unvollständige oder sogar widersprüchliche Beschreibungen sind bewusst zugelassen, da AutomationML auch frühe Planungsphasen abdecken soll, in denen die Konsistenz der Daten noch unzureichend ist. Mit der Einbindung von existierenden Standarddatenformaten können im ersten Schritt Topologie-Information, Grafik, Kinematik und Verhalten beschrieben werden, wobei kein einzelner Standard alle Aspekte abdeckt. Die künftige Erweiterung um weitere Datenformate soll konzeptionell bereits in der Grundarchitektur vorgesehen sein, zum Beispiel zur Beschreibung von Geräten oder der Feldbuskommunikation.

26

D. Weidemann und R. Drath

Zentraler Mehrwert von AutomationML ist die Verknüpfung dieser Sub-Standards unter weitestgehender Vermeidung redundanter Information. Fast alle untersuchten Standard-Datenformate bringen bereits gewisse Möglichkeiten zur Darstellung topologischer Informationen mit – beispielsweise eine Hierarchie von Objekten. Da die einzelnen Hierarchien an verschiedenen Stellen redundant gespeichert werden könnten, muss mit AutomationML klar festgelegt werden, welche dieser Beschreibungen für das Projekt führend ist. Die Kernfunktion von AutomationML besteht somit technisch in der geschickten Referenzierung zwischen den vorhandenen Standards und organisatorisch in der Festlegung, wie die dort eingebundenen Sub-Standards zur Beschreibung von greifbaren und interpretierbaren Anlagenkomponenten konkret verwendet werden können. Die von AutomationML verwendeten Datenformate werden im Rahmen ihrer Spezifikation unverändert genutzt und stellen keine AutomationML-Spezialversionen dar. Erforderliche Erweiterungen an diesen Datenformaten werden im Rahmen der zugehörigen Gremienarbeit erarbeitet und dort nativ integriert. Im Rahmen der Zusammenarbeit des AutomationML-Konsortiums mit den jeweiligen Gremien wurde mittels der bereits im Jahr 2008 publizierten Versionen von COLLADA 1.5 und PLCopen XML 2.0 die industrielle Anpassung beider Datenformate erfolgreich unterstützt. Eine Architekturübersicht gibt Abb. 1.13. Das Objektmodell wird mit CAEX abgebildet, Geometrie und Kinematik mittels COLLADA und Verhalten mit Hilfe von PLCopen XML. Durch Wiederverwendung existierender Datenformate bleibt die eigentliche Spezifikation von AutomationML im Ergebnis bemerkenswert schlank. Weitere Datenformate lassen sich mit denselben Mechanismen referenzieren, sie sind dadurch universell einsetzbar. AutomationML ist somit auf künftige Erweiterungen vorbereitet.

Abb. 1.13   AutomationML-Architektur

1  Einleitung

27

Es wird deutlich, dass AutomationML eine inhärent verteilte Dateistruktur besitzt. Daten werden nicht in einem monolithischen XML-Dokument verpackt, sondern in Einzeldokumenten verteilt gespeichert. Die Vorteile dieser Vorgehensweise bestehen zum einen in der Wiederverwendung gereifter Datenformate. Dies reduziert den Spezifikationsaufwand für AutomationML erheblich und fördert die Markt-Akzeptanz. Des Weiteren wird die Handhabung von Massendaten oder Anlagenteilen durch die Verteilung von Daten in verschiedene Dateien deutlich vereinfacht. Zudem wird der Umgang mit umfangreichen Bibliotheken erleichtert. Die Bereitstellung von Komponentenbeschreibungen von Zulieferern ist ein wichtiger Anwendungsfall für AutomationML. Mit Hilfe von CAEX-Bibliotheken können beispielsweise Produktkataloge oder Komponentenbibliotheken neutral abgebildet und veröffentlicht werden. Aus solchen Bibliotheken können Anlagenplaner benötigte Komponenten auswählen und in ihre Planung einfügen. Dafür und zur einfachen Beherrschbarkeit von Massendaten wird die Speicherung in mehreren Dokumenten dringend benötigt. Diese Dokumentenarchitektur vereinfacht neben der Nutzung verschiedener, bewährter Datenformate unter einem gemeinsamen Dach auch die Verteilung von Daten in unterschiedliche Dateien, die Verwaltung von Masseninformationen sowie die geforderte Unterstützung von Bibliotheken. Weiterhin können auf diese Art zum Beispiel unterschiedliche Geometrievarianten oder -versionen eines Produktes in separaten Dateien gespeichert werden. AutomationML soll weiterhin Relationen zwischen Anlagenobjekten abbilden können. Diese drücken physikalische, elektrische, hydraulische, steuerungstechnische oder logische Beziehungen zwischen Objekten aus, beispielsweise die Verbindung zwischen zwei Signalen, die Gruppierungen von Sicherheitskreisen oder die Vorgänger/Nachfolgerbeziehung von Komponenten in der Fertigungslinie. Objektmodelle sind gut dafür geeignet. Eine wesentliche Fragestellung für das AutomationML-Design ist die Abwägung zwischen konkreten Datenbeschreibungen und abstrakten, übergeordneten Konzepten, sogenannten Meta-Konzepten. Der Versuch, alle denkbaren Planungsdaten zu sammeln und in ein großes Datenmodell zu gießen, würde im Ergebnis zu großer Komplexität und Unübersichtlichkeit führen. Ein solches „Weltmodell des Engineering“ würde bereits an der Vielzahl von Werksnormen, regionalen und nationalen Standards scheitern. Wird auf detaillierte, konkrete Beschreibungen zu viel Wert gelegt, dann ist die Gefahr sehr groß, sich „vom Hundertsten ins Tausendste“ zu verlieren. Man würde angesichts der Fülle an nutzerspezifischen Informationen und dem sich stetig weiterentwickelnden Bedarf an neuen Informationen keine Vollständigkeit erreichen. Bereits in dem Moment, in dem ein solcher Standard verabschiedet würde, könnten keine darüber hinausgehenden Informationen mehr abgebildet werden. Bliebe man umgekehrt nur abstrakt auf „Meta-Ebene“, würde die große Flexibilität viele Möglichkeiten für die Abbildung ein- und derselben Information eröffnen – man könnte eine konkrete Anlage nie so konkret beschreiben, dass sie werkzeugübergreifend austauschbar wäre. AutomationML geht einen Mittelweg, indem es bewährte Modellierungskonzepte wie Hierarchien, Bibliotheken, Schnittstellen und Attribute sowie etablierte

28

D. Weidemann und R. Drath

Datenmodelle mit flexiblen Meta-Konzepten zur Abbildung individueller Daten und Erweiterungen kombiniert. Das verwendete Rollenkonzept erlaubt es insbesondere, nutzerdefinierte Objekte mit detaillierten Anforderungsspezifikationen und Semantik zu hinterlegen. Weiterhin können Attribute mit einer semantischen Referenz ausgestattet werden, die ihre Bedeutung festlegt. Mit der herstellerunabhängigen Speicherung von Anlagendaten wird eine Wiederverwendung über Werkzeuggrenzen hinweg angestrebt. Damit können erprobte Anlagen-Entitäten mit signifikanten Vorteilen in Bezug auf Sicherheit, Entwicklungskosten und -zeit, Wartungsfreundlichkeit und Vergleichbarkeit weiter genutzt werden. Die Möglichkeit, wertvolle Engineering-Ergebnisse aus einem Werkzeug herauslösen, neutral speichern und übertragen zu können, verspricht zudem eine höhere Unabhängigkeit von dem Werkzeug. Dies könnte zukünftig sogar eine Lösung für die kostspielige Aufarbeitung alter Datenbestände bei Engineering-Werkzeugoder Leitsystemwechsel darstellen. Angesichts heterogener Leitsysteme entstünde auf diese Weise ein Investitionsschutz für bereits vorhandene Engineering-Ergebnisse, vgl. Drath u. Fedai (2004).

1.6.2  Beschreibung der Anlagentopologie Eine besondere Herausforderung besteht darin, komplex vernetzte Planungsinformation abbilden zu können. Ein bewährtes Konzept für die Beherrschung von Komplexität ist die Objektorientierung – zusammengehörige Daten werden hierbei in sogenannten Objekten gekapselt und in Form von Klassen einer Wiederverwendung zugeführt. Dieses Schlüsselkonzept wird mittlerweile von einer Vielzahl

Abb. 1.14   Kernkonzepte der AutomationML-Toplevel-Architektur

1  Einleitung

29

moderner Planungswerkzeuge unterstützt und orientiert sich beispielsweise an realen Anlagenobjekten: Roboter, Pumpen, Ventile oder Förderbänder werden als Datenobjekte modelliert und in Beziehung zueinander gesetzt. Diesen Gedanken greift AutomationML auf. Deshalb basieren Anlagenbeschreibungen auf AutomationML-Objekten, die sich aus weiteren Unterobjekten zusammensetzen oder Teil einer größeren Komposition sein können. Mit Hilfe von Objektbäumen lassen sich einfache Komponenten, Fertigungszellen und sogar komplexe Anlagen beschreiben, vgl. Fay u. Drath (2005). Aspekte wie Geometrie, Kinematik und Verhalten werden mit AutomationML in separaten Dokumenten ausgelagert. Die AutomationML-Grundarchitektur basiert auf dem Objekt-Datenformat CAEX gemäß IEC 62424, welches sowohl die hierarchische Anlagentopologie als auch benötigte Bibliotheken und Klassen modelliert. Die Anlagentopologie bildet die hierarchische Struktur eines konkreten Projektes, zum Beispiel eine Anlage oder Roboterzelle, in Form einer Objekthierarchie ab. Beispiele für Objekte sind ein Signal, eine SPS, ein Tank, ein Ventil, ein Roboter, eine Fertigungszelle, eine Linie oder eine komplette Anlage. Jedes Objekt ist dabei durch individuelle Attribute, Schnittstellen und Beziehungen zu anderen Objekten gekennzeichnet. Abbildung 1.15 zeigt ein Beispiel für die Objekthierarchie einer Fertigungszelle. CAEX wurde ursprünglich für den Datenaustausch von leittechnikrelevanten Informationen zwischen Werkzeugen der Verfahrenstechnik- und der Leittechnikplanung entwickelt (Epple 2003; Drath u. Fedai 2004), kann jedoch als flexibles Objektmodell ebenso uneingeschränkt in der Fertigungsplanung eingesetzt werden. Es unterstützt die Modellierung von statischen Objektstrukturen und verfügt über ein mächtiges Bibliothekskonzept, welches die Speicherung bewährter Komponenten, Schnittstellen, Anforderungen und Rollen erlaubt. Folgende Grundkonzepte stellt CAEX bereit (siehe Abb. 1.14): • Klassen und Bibliotheken erlauben die Modellierung wieder verwendbarer Vorlagen und können innerhalb der Klassenbibliotheken mit Hilfe von Vererbungs-Relationen verfeinert werden.

Abb. 1.15   Beispiel für die Anlagenhierarchie einer Fertigungszelle

30

D. Weidemann und R. Drath

• Die Instanz-Hierarchie beschreibt die Topologie einer konkreten Anlage oder Teilanlage. Dies umfasst die beteiligten Objekte, ihre Attribute, Schnittstellen und Relationen untereinander. • Schnittstellen, Relationen und Referenzen dienen der Beschreibung von Verbindungen zwischen CAEX-Objekten untereinander sowie von Verbindungen zwischen CAEX-Objekten und externen Dokumenten. • Rollen sind Klassen zur Modellierung abstrakter Funktionen. So kann beispielsweise einem konkreten Objekt 110RB_200 die Rolle Robot zugeordnet werden. Dies ermöglicht Teilnehmern des Datenaustausches, die grundsätzliche Funktion dieses Objektes zu identifizieren. Das CAEX-Rollenkonzept dient somit zur semantischen Identifikation von Objekten und hat eine besondere Bedeutung bei der Modellierung von Anforderungen und bei der Automatisierung von Planungsschritten, der so genannten „Automation of Automation“, vgl. Güttel (2008), Yim (2006) oder Schmitz (2007).

1.6.3  Geometrie- und Kinematikbeschreibung Detaillierte Informationen wie Geometrie, Kinematik und Ablauflogik werden nicht in CAEX gespeichert. Die Geometrie eines Anlagenobjektes umfasst dessen geometrische Repräsentation, während die Kinematik die physikalischen Verbindungen der 3D-Modelle und ihre Abhängigkeiten untereinander beschreibt (siehe Abb. 1.16). Beide Arten werden mit Hilfe des Dateiformates COLLADA der Khronos Group (Khronos 2009) abgebildet. Dieses Industriekonsortium wurde mit dem Ziel gegründet, offene Standards für Parallelprogrammierung, Beschleunigung von Grafikdarstellungen und dynamische Medien auf einer Vielzahl von Plattformen und Geräten zu entwickeln. Zudem ist die Khronos Group Träger für den weithin bekannten Standard OpenGL sowie den jüngsten Standard OpenCL. Das Datenformat COLLADA hat seine Wurzeln in der Computer-Spiele-Industrie, die als innovativer Vorreiter für grafische Anwendungen bekannt ist. COLLADA

Abb. 1.16   Planar- und Kugelgelenk als Beispiele für Kinematiken

1  Einleitung

31

Abb. 1.17   Referenzierung von COLLADA-Dokumenten

wird in bekannten Anwendungen wie Google Earth verwendet und ist als freies Datenformat kostenlos verfügbar. Von CAEX aus können COLLADA-Dokumente mit Hilfe von Referenzmechanismen verbunden werden (siehe Abb. 1.17). Abschnitte 2.6 und 3.3.8 erläutern, wie dies mit AutomationML erfolgt. Zur Zusammensetzung der einzelnen Geometriebeschreibungen für das gesamte Objekt, zum Beispiel der Zelle oder der ganzen Anlage, besitzt jedes einen so genannten Frame, der die geometrische Position relativ zum übergeordneten Objekt beschreibt. Mit dessen Hilfe kann ein Visualisierungsalgorithmus alle AutomationML-Objekte sehr einfach durchlaufen und deren COLLADA-Beschreibungen an der jeweils richtigen Position in der gesamten Szene einfügen. Die Zusammensetzung von Kinematiken erfolgt ebenfalls innerhalb von COLLADA.

1.6.4  Beschreibung von Abläufen und Verhalten Gesteuertes und ungesteuertes Verhalten von Anlagenobjekten wird mit Hilfe des Datenformates PLCopen XML beschrieben. PLCopen XML wurde als neutrales Datenaustauschformat für die in der IEC 61131-3 standardisierten Fachsprachen der SPS-Programmierung entwickelt und steht ebenfalls frei zur Verfügung. AutomationML verwendet die Möglichkeiten zur Modellierung der sehr implementierungsnahen Ablaufsprache mit Sequential Function Charts (SFC). Aufgrund der Mächtigkeit von SFCs lassen sich mit ihnen auch übliche Diagrammtypen aus vorgelagerten Engineering-Phasen abbilden. AutomationML macht sich diesen Umstand zunutze, um eine durchgängige Übertragung von einfachsten Gantt-Charts früher Planungsphasen über Impuls- und PERT Charts bis zu den implementierungsnahen SFCs späterer Engineering-Phasen zu ermöglichen. Ebenso können komplexe Zustandsdiagramme mit SFCs dargestellt werden. Die von AutomationML unterstützten Diagrammtypen werden in Abb. 1.18 beschrieben. Die Abschnitt 2.6 und 4.6 erläutern, wie SFCs in PLCopen-XML-Dateien mit AutomationML aus CAEX heraus referenziert werden können. Abbildung 1.19 zeigt

32

D. Weidemann und R. Drath

Abb. 1.18   Unterstützte Diagrammtypen für Logikbeschreibungen

zur Illustration eine Anlagenstruktur, bei der das Objekt 110RB_200 ein separates PLCopen-XML-Dokument referenziert. Die Verhaltensbeschreibung mit SFCs umfasst weiterhin Folgen von Aktionen einschließlich involvierter E/A-Verbindungen oder logischer Variablen. Mit Hilfe

Abb. 1.19   Referenzierung eines PLCopen-XML-Dokumentes

1  Einleitung

33

eines in Abschnitt 2.6.2 beschriebenen Mechanismus können Signale, die in verschiedenen PLCopen-XML-Dateien definiert sind, mittels CAEX querverbunden werden.

1.6.5  Schnittstellen- und Rollen-Bibliotheken AutomationML definiert eine Reihe von Standardbibliotheken. Standard-Schnittstellenklassen sind in der Schnittstellenbibliothek AutomationMLInterfaceClassLib zusammengefasst. Die oberste Basisklasse ist das AutomationMLBaseInterface, alle weiteren Standard-Schnittstellenklassen sind direkt oder indirekt von ihr abgeleitet. Abbildung 1.20 zeigt die Standard-Schnittstellenbibliothek als Baumstruktur. Darüber hinaus definiert AutomationML drei Rollenbibliotheken, deren Klassen ihre Schwerpunkte im Bereich Fertigungs-, Prozess- beziehungsweise Leittechnikindustrie haben. Die AutomationMLBaseRoleClassLib (Abb. 1.21) enthält übergreifend einsetzbare Basisrollen, die AutomationMLMIRoleClassLib (Abb. 1.22a) grundlegende Rollen der Fertigungsindustrie (MI steht für Manufacturing Industry) und die AutomationCSRoleClassLib (Abb. 1.22b) wesentliche Rollen der Leittechnikindustrie (CS steht für Control System). Umfangreiche herstellerspezifische Rollenbibliotheken sowie eine prozesstechnische Rollenbibliothek sind in der Entstehung begriffen. Die Bedeutung und Verwendung der beschriebenen Standardklassen werden in Kap. 2 näher erläutert. Abb. 1.20   AutomationMLSchnittstellenbibliothek

Abb. 1.21   AutomationMLBasis-Rollenbibliothek

34

D. Weidemann und R. Drath

Abb. 1.22   AutomationML-Rollenbibliothek für die a Fertigungstechnik und b Leittechnik

1.6.6  Erweiterte AutomationML-Konzepte Neben den erwähnten Konzepten definiert das AutomationML-Konsortium eine Reihe erweiterter Konzepte, die spezielle Aspekte der Anlagenplanung bedienen. Mit dem Port-Konzept können komplexe Schnittstellen abgebildet werden. PortObjekte werden durch Referenzierung der AutomationML-Rollenklasse Port modelliert und vereinen zusammengehörige Einzel-Schnittstellen zu einer Art „SuperSchnittstelle“. Ähnlich wie bei einem Stecker oder einer Buchse werden mehrere Signal- und Energieversorgungspins zusammengefasst und können als Ganzes miteinander verbunden werden, ohne die individuellen Verbindungen einzeln betrachten zu müssen. Eine nähere Beschreibung erfolgt in Abschnitt 2.9.2. Mit dem Facettenobjekt können abgrenzbare Sichten auf Attribute oder Schnittstellen eines Objektes abgebildet werden, beispielsweise die Sicht auf HMI-relevante Daten eines Förderbandes. Ein Facettenobjekt fungiert somit als Attribut- und Schnittstellenfilter für dessen Eigentümerobjekt. Bei dem genannten Förderband würde das Facetten-Objekt als dessen Kindobjekt modelliert, mit einem Namen wie HMI-Facette versehen und mit der AutomationML-Rollenklasse Facet assoziiert werden. Alle Attribute und Schnittstellen dieser HMI-Facette referenzieren diejenigen Attribute oder Schnittstellen des Förderband-Objektes, die für den HMIAspekt von Bedeutung sind. Anhand des Namens kann ein separater HMI-Generierungs-Algorithmus relevante Informationen dieses Facettenobjektes identifizieren und beispielsweise zugehörige HMI-Templates generieren und parametrieren. Auf dieselbe Weise könnte auch Steuerungscode erzeugt werden. Das Facetten-Konzept wird in Abschnitt 2.9.3 näher erläutert. Ein Gruppen-Objekt kann eine Menge von Objekten einer Hierarchie zusammenfassen, beispielsweise alle Förderbänder einer Station. Ein Gruppenobjekt fungiert somit als Objekt-Filter. Dazu wird in der Hierarchie ein Objekt angelegt und mit der AutomationML-Rollenklasse Group assoziiert. Anschließend wird der Gruppe für alle gewünschten Objekte je eine Objektrelation zugeordnet. Abbildung 1.23 zeigt dies anhand der Objekte Gruppe1 und Gruppe2. Eine nähere Beschreibung des Gruppen-Konzeptes nebst Beispielen erfolgt in Abschnitt 2.9.4.

1  Einleitung

35

Abb. 1.23   Beispiel für Gruppenobjekte

Das Gruppen- und das Facetten-Konzept lassen sich kombinieren. So definiert AutomationML für jedes Gruppenobjekt optional einen Verweis auf eine Facette. Dies erlaubt, beispielsweise für das Gruppenobjekt Gruppe1 einen Verweis auf die Facette HMI-Facet. Ein Engineering-Algorithmus kann nun anhand der Gruppe identifizieren, welcher Engineering-Aspekt behandelt werden soll. Im nächsten Schritt werden alle zugehörigen Objekte Förderband1 und Förderband2 aufgesucht und deren Facettenobjekte bearbeitet. Auf diese Weise gelingt die automatische Generierung der HMI für beide Förderbänder. Die Kombination des Gruppen- und Facetten-Konzepts wird in Abschnitt 2.9.5 näher erläutert. Mit dem Produkt-Prozess-Ressourcen-Konzept lassen sich drei wesentliche Sichtweisen auf eine Anlagenplanung unterscheiden und mittels CAEX abbilden: die Prozess-, die Produkt- und die Ressourcen-Sicht. Für jede dieser Kategorien definiert AutomationML eine eigene Rollenklasse. Die Beziehungen zwischen den Sichten lassen sich mit Hilfe von PPRInterfaces modellieren. So kann beispielsweise ein Prozess Transport der Ressource Förderband1 zugeordnet werden. Dieses Konzept wird in Abschnitt 2.9.6 näher beschrieben.

1.7  Anwendungen und Beispiele Ein wichtiger Anwendungsfall für AutomationML ist der Datenaustausch kinematisierter Geometrien bis hin zu ganzen Fertigungszellen. In Abb. 1.24 wird dies verdeutlicht. Kinematisierte Objekte umfassen die Kombination von Geometrieund Kinematikmodellen – hierfür steht am Markt keinerlei offenes Datenformat zur Verfügung. Wenn beispielsweise eine Zelle aus CATIA V5 in RobCAD oder RobotStudio weiter bearbeitet werden soll, war bisher ein Export nur unter Verlust aller Kinematikdaten möglich, zum Beispiel über das Datenformat Step. Folglich musste die ursprünglich bereits kinematisierte Zelle im Zielwerkzeug erneut und vollständig nachkinematisiert werden – mit erheblichem manuellen Aufwand und den üblichen potenziellen Fehlerquellen bei der Übertragung. Dieses Problem wurde gelöst, indem die AutomationML-Gruppe Vorschläge für die Weiterentwicklung von COLLADA zur Darstellung kinematischer Information erarbeitete und bei der Khronos Group einreichte. Diese fanden in die COLLADA

36

D. Weidemann und R. Drath

Abb. 1.24   Darstellung einer kinematisierten Zelle in verschiedenen Werkzeugen

Version 1.5 Eingang. Unter Nutzung von COLLADA können heute mit dem Graphic Conditioner Pipeline Framework ( CPF) von NetAllied (NetAllied 2009) umfangreiche Datenkonvertierungen zwischen verschiedenen Werkzeugen umgesetzt werden – dieses wird in Abschnitt 6.3 näher erläutert. Für die Werkzeuge RobotStudio der Firma ABB und KUKA.Sim der Firma KUKA Roboter ist die native Unterstützung von AutomationML bereits angekündigt. Ein weiterer, ähnlicher Anwendungsfall ist die Reduzierung von CAD-Daten, so dass umfangreiche Zellen oder Produktdaten auch mit günstigen Standardrechnern performant visualisiert werden können. AutomationML ermöglicht die Übertragung von 3D-CAD-Daten in Software-Werkzeuge zur Datenreduktion. Ein drittes Anwendungsbeispiel für AutomationML ist die Übertragung von Ablaufinformation als Grundlage für die Steuerungsprogrammierung oder für Simulationen. In vielen Fällen wird zu Beginn der Planung der „Geradeauslauf“ durch die Fertigungslinie mit einfachen Mitteln beschrieben – dies umfasst nur das Sollverhalten der Anlage. Zuerst fährt die Rohkarosse ein, dann wird sie ausgerichtet, anschließend werden die Seitenwände angebracht, danach die Rohkarosse ausgefördert, und so weiter. Dazu werden häufig Gantt-Charts in Microsoft Excel-Tabellen oder Projektplanungssoftware erstellt. Im nächsten Schritt wird die bisher nur zeitlich beschriebene Abhängigkeit präzisiert und mit logischen Variablen und Signalen angereichert. Office-Werkzeuge bieten diese Möglichkeit jedoch nicht an. Besser und intuitiv gelingt dies mit Impuls-Diagrammen, beispielsweise mit Werkzeugen wie jPlan von NetAllied oder Sequence Designer von Siemens. Dazu müssten die Abläufe direkt mit diesen Werkzeugen geplant werden – was eine tiefgreifende Änderung des Engineering-Prozesses mit anderer Werkzeugausstattung zur Konsequenz hätte. Mit AutomationML können solche Werkzeuge an den existierenden Engineering-Prozess angeschlossen werden, indem die Daten für diese Werkzeuge

1  Einleitung

37

Abb. 1.25   Transformation einer Ablaufdarstellung von Gantt (Excel) über Impulsdiagramme in einen SFC der IEC 61131-3

konvertiert werden. Die neutrale Speicherung von Planungsdaten entfaltet hier ihre Wirkung und erschließt neue Optimierungspotentiale. Wenn Signal- und Variableninformationen vorliegen, ist der Weg zur Steuerungsprogrammierung nicht mehr weit. Da alle von AutomationML unterstützten Beschreibungsmittel in SFCs der IEC 61131-3 mit PLCopen XML abgebildet werden, können Gantt-Charts und Impuls-Diagramme ohne Datenverlust vom Steuerungstechniker als SFCs aufgegriffen und genutzt werden. Diese Durchgängigkeit wird in Abb. 1.25 anhand existierender Software illustriert. Ein Gantt Chart in einer Microsoft Excel-Datei wird mit dem Logic CPF (Conditioner Pipeline Framework) der Universität Magdeburg ausgelesen und im ersten Schritt im Format der PLCopen XML 2.0 gespeichert. Daraus werden im zweiten Schritt Impulsdiagramme mittels jPlan der Firma NetAllied sowie im AutomationML Logic Editor der Firma Zühlke generiert. Vorgänger/Nachfolger-Beziehungen der Gantt-Balken werden als Signale weiter genutzt. Da der Logic Editor nativ auf PLCopen XML 2.0 arbeitet, kann das Impuls-Diagramm direkt als SFC dargestellt werden. Die frei verfügbaren Werkzeuge Logic Editor der Firma Zühlke und Logic CPF der Universität Magdeburg werden in Abschnitt 6.2 bzw. 6.4 näher erläutert. Ein vierter Anwendungsfall ist der Austausch von Komponentenbibliotheken. Diese werden idealerweise von den Komponentenherstellern mit Daten gefüllt. Dies bedeutet in einer heterogenen Softwarelandschaft allerdings, dass jeder Hersteller seine Bibliotheken für jedes relevante Werkzeug bereitstellen müsste – dieser hohe Aufwand wird verständlicherweise gescheut. AutomationML bietet die Möglichkeit, solche Bibliotheken standardisiert zu modellieren, zu speichern und zu verbreiten. Jede Klasse wird in einer CAEX-Bibliothek beschrieben und kann Verweise auf die zugehörige Geometrie, Kinematik und Logikbeschreibungen enthalten. Diese Bibliotheken könnten dann in Planungswerkzeugen wie Automation Designer, RobCAD, Delmia, Cosimir, Comos, ABB RobotStudio, KUKA.Sim oder

38

D. Weidemann und R. Drath

Abb. 1.26   Komponentenkonzepte im Automation Designer (Siemens) und im AutomationML Editor (Zühlke)

im kostenfrei verfügbaren AutomationML Editor der Firma Zühlke (siehe AutomationML (2009)) dargestellt und weiterverwendet werden, siehe Abb. 1.26. Es wird deutlich: je nach Produktportfolio kann AutomationML in unterschiedliche Firmen jeweils für individuelle Anwendungsfälle eingesetzt werden. Die folgenden Beispiele illustrieren dies: Daimler setzt AutomationML zum Informationsaustausch zwischen der Layout-Planung und den klassischen Konstruktionswerkzeugen ein. Eine Schlüsselfunktion erhält AutomationML im Bereich des funktionalen Engineering für die Automatisierungstechnik. Hierzu werden Informationen aus der Digitalen Fabrik über AutomationML dem Planungstool zur Verfügung gestellt, um Schaltpläne und SPS-Programme zu generieren. Der Einsatz von AutomationML soll weiter vorangetrieben werden, da eine Reduzierung der Planungskosten durch ein hohes Maß an Wiederverwendbarkeit der Informationen aus der Digitalen Fabrik zu erwarten ist, vgl. Gees et al. (2008). Siemens integriert eine AutomationML-Schnittstelle im Automation Designer. Dadurch ergibt sich mittels AutomationML die Möglichkeit des Datenaustausches zwischen Werkzeugen der Digitalen Fabrik und des Digital Engineerings. Für die weiterhin genutzten Datenformate JT und PLM XML zum Austausch von 3DDaten und PLM-Informationen plant Siemens die Anbindung an AutomationML durch bereits im AutomationML-Konsortium existierende Konverter, vgl. Gees et al. (2008).

1  Einleitung

39

ABB übernimmt Topologie-, Geometrie- und Kinematik-Daten in das Simulations- und Offline-Paket RobotStudio mit einer Importfunktion für AutomationML. Über den AutomationML-Import wird der Transfer der Anlagentopologie sowie geometrischer und kinematischer Komponenten in das System möglich sein. ABB Robotics verspricht sich sowohl zeitliche als auch qualitative Vorteile gegenüber den heute verfügbaren rein geometrisch ausgelegten CAD-Importern, da mögliche Fehlerquellen beim Reengineering von CAD-Komponenten zu einem AnlagenLayout besser ausgeschlossen werden können, vgl. Gees et al. (2008). Wichtige zukünftige Ziele der AutomationML-Gruppe sind die Unterstützung weiterer Anwendungsfälle, wie beispielsweise die Erstellung von Simulationen aus Topologie, Geometrie, Kinematik oder Verhalten, sowie eine daraus ableitbare virtuelle Inbetriebnahme.

1.8  Standardisierungsvorhaben Gemäß Wikipedia ist ein Standard „eine vergleichsweise einheitliche oder vereinheitlichte, weithin anerkannte und meist auch angewandte (oder zumindest angestrebte) Art und Weise, etwas herzustellen oder durchzuführen, die sich gegenüber anderen Arten und Weisen durchgesetzt hat.“ Es ist müßig, den genauen Wortlaut zu diskutieren, denn für verschiedene Standards gibt es unterschiedliche Entstehungshistorien. Ein viel genutztes Muster ist die Weiterentwicklung einer Grundlagentechnologie einer erfolgreichen Produktfamilie in einem Standardisierungsgremium. Diese wird dort mit zusätzlichen Anwenderanforderungen abgerundet und durch den Marktdruck des bereits erfolgreichen Produktes weiter durchgesetzt. Man könnte von einem Top-down-Ansatz sprechen. Solche Standards werden häufig mit dem Produktanbieter in Verbindung gebracht und sind als de-facto-Standard vor ihrer Normierung bereits bekannt. Wie in Schaudel (2009) dargestellt, geht die Praxis der Top-down-Standardisierung gelegentlich an den Anwendern vorbei – sie orientiert sich vor allem an den wirtschaftlichen Interessen des Produktherstellers. Andere Standards entstehen bottom-up: eine Gruppe benötigt eine Lösung für ein gemeinsames Problem, es gibt aber keinen herausragenden Ansatz, der verwendet werden könnte. Also wird gemeinsam eine Lösung spezifiziert und entwickelt, die dann vielleicht in so genannten Plug-Festen oder nach Möglichkeit gegen Compliance-Tester validiert wird. Anschließend kann das Ergebnis angewendet und einem Standardisierungsverfahren unterworfen werden. Wichtige Vertreter dieser Art von Standardisierung sind TCP/IP oder GSM. Das Risiko dieses Ansatzes ist es, zunächst eine gemeinsame Vorgehensweise und eine klare technischen Ausrichtung zu finden und diese auch strikt einzuhalten. Bei der Spezifikation von AutomationML ist bemerkenswert, dass das Datenformat weder top-down von Werkzeugherstellern noch bottom-up von einem Nutzerkreis vorangetrieben wird. Stattdessen kann von einem Middle-out-An‑ satz gesprochen werden. Mit CAEX, COLLADA und PLCopen XML gibt es bereits Lösungen für Teilaspekte. Wichtige Marktteilnehmer engagieren sich in

40

D. Weidemann und R. Drath

verschiedenen etablierten Gremien für die Erweiterung der verwendeten Teillösungen um neue Anforderungen und machen sie zusammen unter einem gemeinsamen Dach für ihre Aufgabenstellungen verfügbar. Wie bei den Zielen bereits erläutert, soll AutomationML als offener, kostenfreier Standard weiter etabliert werden. Offenheit bedeutet zunächst, dass jeder Interessierte unbehinderten Zugang zum Standard hat. Die Kostenfreiheit ist kein Selbstzweck der Initiatoren, sondern dient der schnelleren Verbreitung des Standards insbesondere an Universitäten und in innovativen Unternehmen. Die Nutzung von AutomationML zur Entwicklung neuer Methoden soll ohne Hemmnisse möglich sein, um dieses Know-how bewusst zu verbreiten. Wenn Anlagenplanungsdaten bereits möglichst vollständig in AutomationML vorliegen, können sie auch in kleineren effizienten Werkzeugen und Algorithmen für weitere Schritte genutzt werden, zum Beispiel für eine bessere Bahnplanung, leistungsfähigere Simulationen, automatische Plausibilitätsprüfung oder automatische Generierung von Roboter- oder SPSProgrammcode sowie von Bedienoberflächen. Die Kostenfreiheit des Standards dient damit auch der Förderung zur Entwicklung von effektiveren Werkzeugen, um Engineering-Kosten nachhaltig zu reduzieren. Ein offener Standard bedeutet nicht nur die ungehinderte Nutzung sondern auch die freie Mitarbeit bei der Standardisierung. Jedes Unternehmen kann sich durch Mitgliedschaft und Mitwirkung in den Arbeitskreisen für seine Interessen engagieren, solange diese nicht im Widerspruch zu den Zielen des Standards stehen. Beispielsweise wurde in der Anfangszeit sehr viel Wert auf Topologie, Geometrie, Kinematik und Logik gelegt. Andere Themen wurden zunächst geringer priorisiert und können jederzeit aufgegriffen werden. Die Mitglieder der AutomationML-Gruppe machen sich das Prinzip der offenen Standards selbst zunutze, indem sie sich in anderen Standardisierungsgremien engagieren, namentlich der Khronos Group und der PLCopen, um dort Vorschläge für die Weiterentwicklung einzubringen. Mit den in 2008 publizierten Versionen von COLLADA 1.5 und PLCopen XML 2.0 wurde die Zusammenarbeit des AutomationML-Konsortiums mit den jeweiligen Gremien bereits erfolgreich umgesetzt. Die Art des Standards, sei es ein Unternehmens-, ein Konsortialstandard oder eine Norm, ist unabhängig von Entstehung und Lizenzierung. Ein Unternehmensstandard kann erhebliche Marktbedeutung gewinnen, auch wenn er nur von einem einzigen Unternehmen definiert wurde. Beispielsweise hat der Integra-Standard der Daimler AG deutlichen Einfluss auf alle Zulieferer, und das sind für die Fertigungsanlagen viele namhafte, große und kleine Automatisierungsunternehmen. Ein Konsortialstandard entsteht als gemeinsames Ergebnis einer frei gebildeten Gruppe von Unternehmen. Er ist sehr gut geeignet, um schnell erste Spezifikationen nutzbar zu machen und flexibel weitere Anforderungen in kleinen Iterationsschritten zu integrieren. Entsprechend wurde AutomationML zunächst als Konsortialstandard auf der Hannover Messe 2008 vorgestellt und zur Nutzung freigegeben, siehe auch AutomationML (2009). Investitionen im industriellen Umfeld sind in der Regel langfristiger Natur, deswegen ist die Gratwanderung zwischen aktuellen Entwicklungen und bewährten Technologien stets kritisch. Was nutzt eine wunderschöne Software, wenn sie in

1  Einleitung

41

Abb. 1.27   Geplante IEC-Normenreihe für AutomationML

drei Jahren veraltet und der Hersteller in fünf Jahren nicht mehr am Markt ist, aber die zu steuernde Anlage für eine Laufzeit von 15 Jahren ausgelegt wird? Nach Einschätzung der AutomationML-Gruppe ist eine IEC-Standardisierung daher die beste Basis für langfristige Beständigkeit und Planbarkeit. Zur Standardisierung als IEC-Norm wurde der Arbeitskreis AK 941.0.2 „AutomationML“ in der DKE eingerichtet. Da AutomationML grundsätzlich erweiterbar konzipiert ist, ist eine Normenreihe geplant; sie wird in Abb. 1.27 veranschaulicht. Der erste Teil der geplanten Normenreihe beschreibt Definitionen und generelle Konzepte, die für alle Teile von AutomationML gelten – insbesondere auch für künftige Normteile, die zum Zeitpunkt der Standardisierung des ersten Teils noch nicht spezifiziert wurden und später hinzukommen sollen. Der zweite Teil adressiert branchenspezifische Basis-Bibliotheken, insbesondere Rollenbibliotheken. Diese Bibliotheken bergen einen hohen Mehrwert, da die Anlagenplanung so bereits in einem sehr frühen Stadium konkretisiert werden kann, ohne sich auf bestimmte Produkte und Versionen festlegen zu müssen. Durch eine Standardisierung können eingereichte Basis-Bibliotheken nicht mehr einfach geändert werden. Daher wurden sie vom ersten Teil getrennt, der sehr früh stabilisiert werden konnte. Die Erstellung und Weiterentwicklung nutzerdefinierter Bibliotheken ist jedoch ausdrücklich vorgesehen – hierbei ist vorgeschrieben, dass neue Klassen direkt oder indirekt von den Basis-Klassen abgeleitet sein müssen. Dies stellt die automatisierte Erkundbarkeit von neuen und unbekannten Rollen sicher. Die weiteren Teile der Normenreihe behandeln spezielle Aspekte. Inhaltlich werden sie durch existierende Standards wie COLLADA für Geometrie abgedeckt oder in der Nutzung wie bei PLCopen XML für Logikbeschreibungen erweitert. Der entsprechende Normierungsteil beschreibt die Nutzung des zugrunde liegenden Standards und dessen Einbindung in die Topologiebeschreibung mit CAEX durch geeignete Referenzierungsmechanismen. Je nach Notwendigkeit wird dies durch die Konzepte zur erweiterten Nutzung ergänzt, beispielsweise wird im Teil IV die

42

D. Weidemann und R. Drath

Modellierung von Gantt- oder Impuls-Charts beschrieben, für die PLCopen XML ursprünglich nicht vorgesehen war. Weitere Teile der Normenreihe werden auf dieselbe Weise entwickelt. Um zum Beispiel Gerätebeschreibungen in AutomationML aufzunehmen, müsste geprüft werden, welche offenen, kostenfreien und XML-basierten Austauschformate für diesen Aspekt bewährt sind, um daraus einen geeigneten Kandidaten auszuwählen. Dann müssen Mechanismen spezifiziert werden, um dieses Format aus CAEX zu referenzieren, so dass Redundanzen vermieden werden und Konsistenz gewährleistet ist. Erst nachdem mit dem neuen Aspekt entsprechende Erfahrungen gesammelt werden, wird die Nutzung formal beschrieben. Im allgemeinen Dachformat in Teil I wurde diese Form der Erweiterung bereits vorgesehen, so dass dort keine Änderungen notwendig sind. Stattdessen wird für die formale Beschreibung ein neuer Abschnitt begonnen. Erstes Ziel für jeden Teil des AutomationML-Standards ist eine sogenannte PAS, eine Publicly Available Specification. Sie dient als Frühstufe eines IEC-Standards, mit dem über mehrere Jahre Erfahrung gesammelt werden können, die dann noch vor der internationalen Standardisierung berücksichtigt werden können. Wie oben bereits erwähnt, ist diese Korrekturmöglichkeit im Sinne einer Reifung wichtig, denn die Natur eines fest geschriebenen Standards verbietet häufige Modifikationen. Dies führt zu einem guten Kompromiss zwischen Aktualität und Stabilität der verwendeten Technologien.

1.9  Möglichkeiten der Mitgestaltung Mit der Gründung eines AutomationML-Vereins hat sich das AutomationML-Konsortium im April 2009 für interessierte Mitglieder geöffnet. Ziel des Vereins ist die gemeinsame Weiterentwicklung und Verbreitung des Standards. Ein Verein ist die übliche Form, eine juristische Person als Eigentümer eines Datenformats zu benennen, die für die Regelung der Rechte an seiner Nutzung notwendig ist. Wichtiger für die Weiterentwicklung sind jedoch die Arbeitskreise, die als Plattform für die regelmäßige Zusammenarbeit dienen. Sie werden flexibel nach aktuellen Themen organisiert. Zum jetzigen Zeitpunkt (Stand 2009) werden die Top-Level-Architektur abgeschlossen, Arbeitsprozesse mit Bewegungsbahnen für Robotik beschrieben, verschiedene Ablauf- und Verhaltensbeschreibungen auf die neue Version 2.0 der PLCopen XML angepasst und außerdem, eher in der Art einer Liaison, Standardisierungsdokumente für die IEC mit der DKE fertig gestellt. Ein Verein ist für das Ziel eines offenen Standards essentiell. Offen heiß nicht nur offene Verteilung, sondern auch offene Mitwirkung. Jedes Unternehmen kann Mitglied werden, um seine Interessen am Austausch von Anlagenplanungsdaten einzubringen. Beispielsweise könnten sich Prozessautomatisierer und Verfahrenstechniker zusammenschließen, um eine Rollenbibliothek für die Prozessindustrie weiter zu entwickeln.

1  Einleitung

43

Abb. 1.28   Messepräsentation von AutomationML

Neben rechtlichen Fragen und der Organisation der Weiterentwicklung kümmert sich der AutomationML-Verein um die Verbreitung des Standards durch gemeinsame Messeauftritte (siehe auch Abb. 1.28), Schulungen, Präsentationen und einen Internetauftritt (http://www.automationml.org). Dort stehen Spezifikationen, Beispiel-Software und Anschauungsmaterial zum Herunterladen zur Verfügung. Die Webseite und das vorhandene Forum können außerdem zur Kontaktaufnahme mit den Mitgliedern von AutomationML, beispielsweise zur Beantwortung von Fragen, genutzt werden.

Literatur AutomationML (2009) http://www.automationml.org/ Drath R., Fedai M. (2004) CAEX – ein neutrales Datenaustauschformat für Anlagendaten. Teil 1: atp – Automatisierungstechnische Praxis 46 (2004), Heft 2, S. 52–56; Teil 2: atp – Automatisierungstechnische Praxis 46 (2004), Heft 3, S. 20–27, Oldenbourg-Verlag, 2004. Drath R., Gohr K. (2005) Datenaustauschkonzepte im Anlagenengineering. IT Solutions 2005. Epple U. (2003) Austausch von Anlagenplanungsdaten auf der Grundlage von Metamodellen. atp – Automatisierungstechnische Praxis 45 (2003), Heft 7, S. 2–11. Fay A. (2006) Reduzierung der Engineering-Kosten für Automatisierungssysteme. Industrie Management 22 (2006), Heft 2, S. 29–32, 2006.

44

D. Weidemann und R. Drath

Fay A., Drath R. (2005) Objektorientierte Beschreibung einer Chemieanlage: Möglichkeiten und Vorteile. DECHEMA Jahrestagung, Wiesbaden, 6.–8. September 2005. In: Chemie Ingenieur Technik CIT 2005, 77, No. 8, S. 1072. Felleisen M. (2001) Prozessleittechnik für die Verfahrensindustrie. Oldenbourg Industrieverlag, München, 2001. Gees A., Drath R., Hellmann K., Waldeck B., Simon R., Hirzle A., Lantermann T., Enhuber F., Schloegl W. (2008) Lösungsansatz mit beachtlicher Performance. In: Elektro Automation 09/2008, S. 26–29, Konradin Verlagsgruppe, Leinfelden-Echterdingen. Güttel K., Weber P., Fay A. (2008) Automatic generation of PLC code beyond the nominal sequence. In: Tagungsband der 13. Tagung „IEEE International Conference on Emerging Technologies and Factory Automation“ (ETFA), Hamburg, 15.–18. September 2008. ISBN 1-42441506-3. Güttel K., König A., Fay A., Weber P. (2009) Konzept zur Generierung von Steuerungscode unter Verwendung wissensbasierter Methoden in der Fertigungsautomatisierung. In: Tagungsband zum Automation 2009-Kongreß Baden-Baden, VDI-Berichte 2067, S. 309–312, VDI-Verlag, Düsseldorf. IEC 62424 (2008) Festlegung für die Darstellung von Aufgaben der Prozessleittechnik in Fließbildern und für den Datenaustausch zwischen EDV-Werkzeugen zur Fließbilderstellung und CAE-Systemen. Khronos (2009) http://de.wikipedia.org/wiki/Khronos_Group/ Kroll O., Still W. (2009) Prolist NE100 in der Praxis – Erfahrungsbericht eines Anlagenbetreibers und eines Herstellers. In: Tagungsband zum Automation 2009-Kongreß Baden-Baden, VDIBerichte 2067, S. 65–68, VDI-Verlag, Düsseldorf. Mühlhause M., Neumann M., Diedrich C., Wuwer D. (2009) Modellierung semantischer Beziehungen für unterschiedliche Informationsmodelle im automatisierungstechnischen Umfeld. In: Tagungsband zum Automation 2009-Kongreß Baden-Baden, VDI-Berichte 2067, S. 237–240, VDI-Verlag, Düsseldorf. NetAllied (2009) http://www.netallied.de/ PLCopen (2009) http://www.plcopen.org/ Rauprich G., Haus C., Ahrens W. (2002) PLT-CAE-Integration in gewerkeübergreifendes Engineering und Plant-Maintenance. atp – Automatisierungstechnische Praxis 44 (2002), Heft 2, S. 50–62, 2002. Remmel M., Drumm O. (2009) Anwendungen semantischer Technologien zur Erstellung von Schnittstellen. In: Tagungsband zum Automation 2009-Kongreß Baden-Baden, VDI-Berichte 2067, S. 171–174, VDI-Verlag, Düsseldorf. Runde S., Güttel K., Fay A. (2009) Transformation von CAEX-Anlagenplanungsdaten in OWL – Eine Anwendung von Technologien des Semantic Web in der Automatisierungstechnik. In: Tagungsband zum Automation 2009-Kongreß Baden-Baden, VDI-Berichte 2067, S. 175–178, VDI-Verlag, Düsseldorf. Schaudel D. (2009) Dieter Schaudel zum Thema „Standards“. In: Chemie Technik, 02/2009, S. 19, Hüthig Verlag, Heidelberg. Schmitz S., Epple U. (2007) Automatisierte Projektierung von HMI-Oberflächen. In: VDI-Berichte Nr. 1980, S. 127–137, 2007. Wollschläger M., Braune A., Runde S., Topp U., Mühlhause M., Drumm O., Thomalla C., Saboc A., Lindemann L. (2009) Semantische Integration im Lebenszyklus der Automation. In: Tagungsband zum Automation 2009-Kongreß Baden-Baden, VDI-Berichte 2067, S. 167–170, VDI-Verlag, Düsseldorf. Yim S.Y., Ananthakumar H.G., Benabbas L., Horch A., Drath R., Thornhill N.F. (2006) Using process topology in plant-wide control loop performance assessment, Computers & Chemical Engineering, 31, S. 86–99.

Kapitel 2

Grundarchitektur: das Objektmodell Rainer Drath und Miriam Schleipen

2.1  Die Architektur von AutomationML Die Architektur von AutomationML ist darauf ausgerichtet, verschiedene Aspekte des Anlagen-Engineerings abbilden und vernetzen zu können: Anlagenhierarchie, Geometrie, Kinematik, Ablaufplanung und Verhalten. Diese Daten werden üblicherweise in unterschiedlichen Werkzeugen aus verschiedenen Domänen erstellt. Folglich muss AutomationML komplexe und vernetzte Informationen abbilden können. Ein bewährtes Konzept für die Beherrschung von Komplexität ist die Objektorientierung – zusammengehörige Daten werden in sogenannten Objekten gekapselt und in Form von Klassen einer Wiederverwendung zugeführt. Dieses Schlüsselkonzept wird mittlerweile von einer Vielzahl von Planungswerkzeugen unterstützt und orientiert sich beispielsweise an realen Anlagenobjekten: Roboter, Pumpen, Ventile oder Förderbänder werden als Datenobjekte modelliert und in Beziehung zueinander gesetzt. Diesen Gedanken greift AutomationML auf und setzt ihn in einem Objektkonzept um. AutomationML basiert deshalb auf AutomationML-Objekten, die jeweils aus weiteren Unterobjekten bestehen oder selbst Teil einer größeren Komposition sein können. In Abb. 2.1 wird dies anhand eines Objektes Objekt A und einer Reihe von Kindobjekten verdeutlicht, die gemeinsam einen Objektbaum bilden. Auf diese Art lassen sich sowohl einfache Komponenten als auch Fertigungszellen oder komplexe Anlagen beschreiben. Aspekte wie Geometrie, Kinematik und Verhalten werden mit AutomationML in separaten Dokumenten ausgelagert. Zur Modellierung und Speicherung derartiger Objektbäume bedient sich AutomationML des Datenformates CAEX (Computer Aided Engineering Exchange), das als IEC 62424 standardisiert ist. Die Modellierung von Geometrie, Kinematik und Verhalten erfolgt mit Hilfe der Datenformate COLLADA und PLCopen XML.

R. Drath () ABB AG, Forschungszentrum, Wallstadter Str. 59, 68526 Ladenburg, Deutschland e-mail: [email protected] R. Drath (Hrsg.), Datenaustausch in der Anlagenplanung mit AutomationML, DOI 10.1007/978-3-642-04674-2_2, © Springer-Verlag Berlin Heidelberg 2010

45

46

R. Drath und M. Schleipen

Abb. 2.1   Toplevel-Architektur von AutomationML

Bevor die Verwendung dieser Datenformate näher beschrieben wird, geht der folgende Abschnitt zunächst auf einige Besonderheiten zum Verständnis des Begriffs der Objektorientierung in der Anlagenplanung ein.

2.2  Ein Wort zur Objektorientierung in der Anlagenplanung Die Objektorientierung ist eine in der Softwarebranche seit langem bewährte Methodik zur besseren Beherrschung von Komplexität. Das gilt für die interne Architektur der Software selbst, aber auch für die dem Nutzer der Software zur Verfügung gestellte Bedienphilosophie und Datenrepräsentation. In der Anlagenplanung hat die Objektorientierung als Hilfsmittel zur effizienten Planung hingegen erst seit wenigen Jahren praktische Relevanz erhalten. Das „Denken in Objekten“ ist in Planungswerkzeugen wie RobCAD, Cosimir, Comos oder Delmia inzwischen bewährt. Der Begriff der Objektorientierung wird hier aus der Sicht des Planers verwendet und adressiert objektorientierte Planungstechniken wie Datenspeicherung, -repräsentation und -manipulation, siehe Fay u. Drath (2006). Microsoft Visio ist ein bekanntes Beispiel für ein Zeichenwerkzeug mit objektorientierter Bedienphilosophie. Mit solchen Werkzeugen wird eine Zeichnung aus Objekten zusammengesetzt, deren Eigenschaften und Relationen konfiguriert werden können. Planungswerkzeuge wie ComosPT bieten zudem eine komfortable objektorientierte Datenrepräsentation in Form hierarchischer Objektbäume (Schüler 2002), siehe Abb. 2.2. Ein Objekt fungiert in AutomationML als „Stellvertreter“ einer realen oder logischen Planungsentität – beispielsweise für einen Roboter, eine Pumpe, ein Gebäude oder ein Funktionsbaustein. Er wird mit Hilfe des CAEX-Elements

2  Grundarchitektur: das Objektmodell

47

Abb. 2.2   Ein Objektbaum in einem modernen Planungswerkzeug

abgebildet. Ein Objekt kapselt Eigenschaften, Schnittstellen sowie seine innere Architektur und kann selbst Teil einer übergeordneten Struktur sein. Klassen werden anhand eines repräsentativen Objektes in einer Klassenbibliothek beschrieben. Deshalb ist die interne Architektur einer mit der einer Instanz vom Typ identisch. Eine Objektinstanz, im Folgenden auch als AutomationML-Objekt bezeichnet, repräsentiert ein konkretes Exemplar eines Objektes mit einem eigenen Namen und individuellen Eigenschaften, beispielsweise einen Roboter RB200_1. Dieser unterscheidet sich von allen anderen Objekten durch zumindest einen eindeutigen Namen oder Identifikator. Das Gegenstück zur Instanz ist die Klasse. Sie beschreibt ein vordefiniertes abstraktes Objekt, das als „Vorlage“ für die Erstellung von Objektinstanzen dient. Klassen werden in der Industrie auch als Objekttyp, Prototyp, Vorlage, Template oder Basisobjekt bezeichnet. Das Klassenkonzept hat seine Wurzeln im bewährten Modulkonzept (Parnas 1972) und verfolgt konsequent das Konzept der Wiederverwendung. So kann die Klasse Roboter mehrfach instanziiert werden und resultiert beispielsweise in den Objektinstanzen Rob1, Rob2 und Rob3. Klassen können zudem in Bibliotheken zusammengefasst werden. Der Begriff der Vererbung ist in der Anlagenplanung ein Schlüssel für effizientes Engineering. Neue Klassen lassen sich mit Hilfe einer Vererbungsrelation von einer anderen Klasse ableiten und erben sämtliche Eigenschaften, alle Schnittstellen und den inneren Aufbau dieser Eltern-Klasse. So kann eine Klasse SpezialRoboter von der Klasse Roboter abgeleitet sein und ihre „Innereien“ erben. AutomationML unterstützt die Vererbung zwischen Klassen. AutomationML setzt weiterhin das Konzept der Aggregation bzw. Komposition um: Sowohl Objektinstanzen als auch Klassen können aus Teilobjekten individuell aufgebaut werden. Relationen zwischen Objekten stellen ihre Beziehungen untereinander dar. AutomationML implementiert Vererbungsrelationen, Vater-Kind-Relationen, InstanzInstanz-Relationen und Klasse-Instanz-Relationen, siehe Abschnitt 2.5. Objekte und Objektstrukturen spielen in AutomationML eine zentrale Rolle. In den nachfolgenden Abschnitten wird CAEX als Dachformat für AutomationML näher erläutert.

48

R. Drath und M. Schleipen

2.3  Einführung in CAEX 2.3.1 Überblick über wesentliche CAEX-Elemente Die Datenmodellierung mit CAEX erfolgt auf Basis eines XML-Schemas, das in Form der XML-Datei „CAEX_ClassModel.xsd“ vorliegt (AutomationML 2009) und alle benötigten Datentypen definiert. Diese CAEX-Bausteine (im Folgenden als CAEX-Elemente bezeichnet) legen fest, wie Klassen, Schnittstellen, Attribute, Instanzen und alle weiteren Elemente syntaktisch aufgebaut werden müssen. Das CAEX-Schema fungiert als „Bauplan“ für CAEX-Dokumente und erlaubt eine automatische Konformitätsprüfung, ob ein vorliegendes CAEX-Dokument diesem Bauplan entspricht. Diese Vorgehensweise ist eine Grundfunktion von XML und findet weltweit breite und kostengünstige Werkzeugunterstützung. Der folgende Abschnitt stellt die wesentlichen CAEX-Elemente vor und erläutert ihre Anwendung. Zur vertieften Auseinandersetzung mit CAEX wird auf die IEC 62424 (IEC62424 2008) verwiesen, in diesem Buch wird vorrangig auf AutomationML-spezifische Anforderungen oder Vereinbarungen eingegangen. In Abb. 2.3 ist ein Ausschnitt aus einem CAEX-Dokument dargestellt, welches eine Bibliothek MySystemUnitLib sowie eine Objekthierarchie MyHierarchy

Abb. 2.3   Grundlegende CAEX-Elemente

2  Grundarchitektur: das Objektmodell

49

beinhaltet. Auf der rechten Seite des Bildes sind die zugehörigen CAEX-Elemente hervorgehoben. • Das CAEX-Element stellt den Wurzelknoten eines CAEX-Dokuments dar. Ein CAEX-Dokument kann nur einen Wurzelknoten besitzen. • Das CAEX-Element mit ihren Klassen vom Typ beschreibt eine Bibliothek vordefinierter Anlagenentitäten. Ein CAEX-Dokument kann beliebig viele Bibliotheken aufnehmen, die durch im Dokument eindeutige Namen unterschieden werden. Neben diesen Klassenbibliotheken unterstützt CAEX Schnittstellen- und Rollenbibliotheken, die in Abschnitt 2.3.2 erläutert werden. • Das CAEX-Element stellt den Wurzelknoten für einen Objektbaum dar. Es besteht aus einer beliebig tief verschachtelten Hierarchie von Objekten des Typs . Ein CAEX-Dokument kann beliebig viele Hierarchien speichern. • Das CAEX-Element beschreibt ein reales oder logisches Anlagenobjekt mit seinen Attributen und Schnittstellen. Die Architektur eines ist identisch mit dem einer . Dies erlaubt, Objekte im Instanzbaum durch Kopien von Klassen zu erzeugen oder umgekehrt Teile der Instanzhierarchie zurück in eine Klassenbibliothek zu transportieren.

2.3.2 CAEX-Bibliotheken Die Planung komplexer Anlagen ist sowohl in der Prozess-, als auch in der Fertigungsindustrie ohne die Wiederverwendung bewährter Vorlagen heute wirtschaftlich nicht mehr realisierbar. Bibliotheken mit ihren vordefinierten Klassen sind für die Effizienz und den Erfolg der Objektorientierung maßgeblich verantwortlich. Wesentlicher Vorteil von CAEX ist deshalb ein dreiteiliges Bibliothekskonzept. Bibliotheken verstehen sich als Objekt-Katalog. Sie erlauben die Modellierung von wiederverwendbaren Klassen. Diese können mit Hilfe von Relationen innerhalb der Klassenbibliotheken weiter verfeinert werden, zum Beispiel durch Vererbung oder Aggregation. Das CAEX-Bibliothekskonzept unterscheidet drei Bibliotheksarten: die , die und die mit ihren jeweiligen Klassen. CAEX kann beliebig viele dieser Bibliotheken aufnehmen, wobei sich die einzelnen Klassen innerhalb ihrer Bibliothek als Hierarchie abbilden lassen, um beispielsweise eine nutzerdefinierte Baumstruktur zu modellieren. Die Vater-Kind-Beziehung zwischen den Klassen hat jedoch keine weitergehende Semantik. Klassen gleichen Typs können demnach voneinander erben und so Klassenhierarchien bilden – auch quer über

50

R. Drath und M. Schleipen

Bibliotheken oder CAEX-Dokumente hinweg. Die unterschiedlichen Bibliotheksarten haben folgende Bedeutung: 1. Klassen vom Typ beschreiben konkrete physikalische oder logische Anlagenobjekte oder deren Kombination (sogenannte Units). Dies könnte ein konkreter Roboter sein, ein Ventil oder ein Tank. Sie beschreiben nicht nur das Objekt, sondern auch dessen technische Realisierung inklusive ihrer internen Architektur. Sie speichern zugehörige Attribute, Schnittstellen, verschachtelte interne Elemente und Verbindungen zwischen diesen. Ein internes Element kann folglich weitere Elemente enthalten – dies erlaubt die Beschreibung einer beliebig komplexen Objektstruktur durch Hierarchien. Die Rolle bzw. Funktion einer oder deren Instanzen wird durch eine Assoziation zu einer abstrakten definiert. SystemUnit-Klassen sind in Bibliotheken vom Typ zusammengefasst. Mit ihrer Hilfe könnten beispielsweise Produktkataloge modelliert und im Internet publiziert werden. 2. Eine Klasse vom Typ beschreibt ebenfalls physikalische oder logische Anlagenobjekte, jedoch auf abstrakter Ebene und unabhängig von einer konkreten technischen Realisierung. Rollen sind das semantische Gegenstück zu den System-Units. Während mittels in der Regel herstellerspezifische Objekte abgebildet werden, abstrahieren Rollen die Vielfalt technischer Realisierungen und bilden nur grundsätzliche Funktionalitäten einer Gruppe von Komponenten ab. Rollen können als Platzhalter in der Anlagenplanung verwendet werden und unterstützen eine implementierungsunabhängige Grobplanung. Beispiele für Rollen sind Resource, Robot oder PLC. Das Rollenkonzept wird in Abschnitt 2.3.4 näher erläutert. Rollenklassen werden in Bibliotheken vom Typ zusammengefasst.Wichtig für AutomationML: Jedes AutomationML-Objekt muss direkt oder indirekt mit einer Standard-AutomationML-Rolle assoziiert werden, die beim Datenaustausch Auskunft über die Bedeutung des Objektes gibt. 3. Eine Klasse vom Typ  beschreibt eine Schnittstellenart, beispielsweise einen Flansch, ein Signal oder einen Produktknoten. Schnittstellen werden verwendet, um Relationen zwischen Objekten abbilden zu können. Sie werden in Bibliotheken vom Typ zusammengefasst.

2.3.3 Die Instanz-Hierarchie Das CAEX-Element ist der Wurzelknoten für das Objektmodell eines konkreten Projektes und umfasst alle benötigten Hierarchieebenen und Objekte. AutomationML kann flexibel verschiedene Hierarchien abbilden.

2  Grundarchitektur: das Objektmodell

51

Abb. 2.4   Beispiel einer Instanz-Hierarchie

Die Objekte selbst können Attribute und Schnittstellen zu ihrer individuellen Parametrisierung besitzen. Im Ergebnis bildet die Instanz-Hierarchie die Anlagentopologie einer konkreten Anlage, Teilanlage oder von Sichten darauf ab und speichert zudem deren interne Relationen. In Abb. 2.4 wird beispielhaft die Instanz-Hierarchie einer Zelle dargestellt, allerdings ohne Abbildung der Attribute und Schnittstellen. Die konkrete Modellierung einer Objekthierarchie mit CAEX illustriert Abb. 2.5. Die Instanz-Hierarchie selbst wird durch ein CAEX-Element vom Typ InstanceHierarchy abgebildet. Deren Kindobjekte werden als ineinander verschachtelte Objekte vom Typ modelliert, die alle einen sogenannten Global Unique Identifier (GUID) besitzen müssen. Die Vater-Kind-Beziehung im Objektbaum wird in CAEX demnach direkt abgebildet. Zur besseren Lesbarkeit werden in diesem Buch die tatsächlichen GUIDs wie beispielsweise {AC76BA86-7AD7-1033-7B44-A70000000000} durch Platzhalter wie z. B. GUID1 ersetzt. Der vollständige XML-Quelltext für dieses Beispiel ist in Abb. 2.6 dargestellt.

Abb. 2.5   CAEX-Modellierung eines Objektbaumes

52

R. Drath und M. Schleipen

Abb. 2.6   XML-Code des Objektbaumes

2.3.4 Das CAEX-Rollenkonzept Das Rollenkonzept lässt sich anschaulich anhand der Komposition eines umfangreichen Musikwerkes erläutern, da dies mit der Planung einer komplexen Anlage vergleichbar ist. Der Komponist sieht beispielsweise in seiner Oper die Rolle einer Prinzessin vor (Phase 1), ohne eine konkrete Person – sprich „technische Realisierung“ – anzunehmen. Er formuliert dann (Phase 2) Anforderungen an diese Rolle, beispielsweise „soll hohes C singen können“, „soll lange blonde Haare haben“, „soll reiten können“. Diese Rollenanforderungen sind für spätere Regisseure die Grundlage zur Auswahl geeigneter Kandidaten, die diese Rolle auf der Bühne singen können – sie also „implementieren“ (Phase 3). Anlagenplaner gehen ähnlich vor. Ausgangspunkt des Rollenkonzeptes ist, dass der Anlagenplaner zu Beginn seiner Arbeit zunächst abstrakte technische Funktionen plant (Phase 1) und konkrete technische Realisierungen vorerst außer Acht lässt. Im nächsten Schritt definiert er zugehörige Anforderungen (Phase 2) und verfeinert diese zunehmend. Anhand dieser Anforderungen wird die Auswahl einer konkreten technischen Realisierung getroffen (Phase 3). Eine solche Vorgehensweise entspricht einer praktischen, iterativen, ingenieurmäßigen und menschlichen Denkweise. Das Rollenkonzept verfolgt somit eine bewährte Vorgehensweise zur Entkopplung der Spezifikations- von der Implementierungsphase. Alle drei Phasen werden in Abb. 2.7 verdeutlicht. Phase (1) wird mit CAEX abgebildet, indem der Instanz-Hierarchie zunächst bedeutungsfreie Objekte vom Typ  (Beispiel RB_100) zugeordnet werden. In Phase (2) ordnet der Planer eine geeignete (hier Robot) aus einer Rollenbibliothek zu. Hier können Anforderungen (z. B. „Maximallast < 2t“) festgehalten werden – sie bilden später die Basis für die Auswahl geeigneter Kandidaten. Sobald ein geeigneter Kandidat gefunden wurde, kann in Phase (3) die Referenzierung einer  durchgeführt werden. Die Instanz erfährt somit eine konkrete technische Implementierung. Ein AutomationML-Objekt besteht somit aus drei Elementen. Der zugehörige XML-Text ist in Abb. 2.8 dargestellt.

2  Grundarchitektur: das Objektmodell

Abb. 2.7   Das CAEX-Rollenkonzept

Abb. 2.8   XML-Beispiel für das Rollenkonzept

53

54

R. Drath und M. Schleipen

2.4  AutomationML-spezifische Festlegungen zu CAEX 2.4.1 Drei Wege zum Umgang mit der Instanz-Hierarchie Instanz-Hierarchien dienen als Wurzelknoten zur Speicherung konkreter Planungsdaten in CAEX. Im Umgang mit der Instanz-Hierarchie können verschiedene Wege beschritten werden, um unterschiedliche Anwendungsfälle zu bedienen. Weg 1 – Objektmodellierung ohne Klassen: Dieser Weg ignoriert das Bibliothekskonzept von CAEX. Die komplette Projekthierarchie wird ohne Verwendung von Klassen modelliert. Dazu werden alle benötigten Objekte direkt in der InstanzHierarchie als angelegt und mit jeweils individuellen Attributen, Schnittstellen und Relationen ausgestattet. Die Modellierung erfolgt somit vollständig auf Instanz-Ebene. Diese Form der Modellierung ist prinzipiell sinnvoll, wenn nur Projekt-Rohdaten ohne Berücksichtigung von Bibliotheken übertragen werden sollen. Solange die Objekte eine eindeutige ID besitzen, ist ein Datenaustausch auch in einer iterativen Engineering-Umgebung realisierbar. Allerdings wären solche Objekte im Rahmen von AutomationML semantisch nicht interpretierbar und nur für den Erzeuger verständlich. Deshalb schreibt AutomationML als Ergänzung zur IEC 62424 die Referenzierung einer Standard-AutomationML-Rolle vor. Das Rollenkonzept wird in Abschnitt 2.3.4 erläutert, Standardbibliotheken werden in Abschnitt 2.7 vorgestellt. In den nachfolgenden Beispielen wird die Referenzierung von Rollen zur besseren Lesbarkeit häufig weggelassen. Weg 2 – Objektmodellierung ausschließlich mit Klassen: Dieser Weg kennt keine individuellen Objekte. Die gewünschte Anlagenhierarchie oder ein Teil davon wird durch ein einziges repräsentiert. Dieses referenziert eine komplexe , welche dessen vollständige Systembeschreibung einschließlich der Anlagentopologie, Kindobjekte, Attribute, Schnittstellen und Relationen umfasst. Dieser Weg ist dann von Interesse, wenn die betreffende Anlage oder Teilanlage in Form einer Standardlösung als vordefinierte Klasse vorliegt und zur mehrfachen Benutzung vorgesehen ist. Beispiele sind standardisierte Fertigungszellen oder -linien, aber auch komplexe Komponenten. Dieser Weg ist AutomationML-konform. Allerdings ist in der Praxis üblicherweise eine Individualisierung von Anlagenkomponenten erforderlich – dies führt zu Weg 3. Weg 3 – Gemischte Modellierung: Dieser Weg ist typisch für den praktischen Einsatz. Zunächst wird das Anlagenobjektmodell mit Hilfe von zusammengestellt. Anschließend erfolgt für jedes AutomationML-Objekt die Zuordnung einer AutomationML-Rollenklasse, mit deren Hilfe die grundlegenden Funktionen und Anforderungen festgelegt werden können. Durch Referenzierung einer wird abschließend eine konkrete technische Implementierung des Objektes ausgewählt. Dies setzt entsprechende Bibliotheken voraus. AutomationML schränkt hierbei eine CAEX-Funktionalität ausdrücklich ein: Während in CAEX eine lebendige Vererbungsbeziehung zwischen einer Klasse

2  Grundarchitektur: das Objektmodell

55

und einer Instanz vorgesehen ist, wird dies derzeit für AutomationML nicht erlaubt: Die in CAEX vorgesehene Vererbungsbeziehung definiert, dass die Referenzierung einer eine automatische Vererbung aller darin enthaltenen Objekte bewirkt, ohne dass diese in der Instanz nochmals aufzuführen sind. Änderungen in der Klasse werden damit automatisch auf alle Instanzen weiter gegeben. In AutomationML hingegen fungiert eine Klasse als „Kopiervorlage“: Sie wird bei der Instanziierung unter Berücksichtigung aller Vererbungsbeziehungen mit ihrer gesamten internen Struktur in die Instanz-Hierarchie kopiert. Anschließend kann die Instanz frei verändert, parametriert, ergänzt oder angepasst werden. Dennoch darf die Instanz ihre Klasse referenzieren: Diese Referenz erlaubt einem Werkzeug oder Anwender, den Ursprung der Instanz nachzuvollziehen, bei Bedarf die Änderungen zu ermitteln und eine automatische Aktualisierung durchzuführen. Der in CAEX implizit vorgesehene Vererbungsautomatismus wird mit AutomationML ausdrücklich in die Verantwortung von Werkzeugen delegiert. Zusammenfassend die wichtigsten Regeln zum Verständnis des Klassenkonzeptes in CAEX: Klassen fungieren als „Kopiervorlagen“. Beim Instanziieren einer Klasse wird deren interne Struktur kopiert. Das resultierende Instanzobjekt referenziert optional seine Ursprungsklasse, kann aber frei verändert werden. Eine Änderung der Klasse wirkt sich nicht automatisch auf ihre Instanzen aus; dies wird als ToolLeistung betrachtet.

2.4.2 Objektidentifizierung Für den Datenaustausch ist die eindeutige Identifizierbarkeit von Objekten von großer Bedeutung. Während CAEX gemäß IEC 62424 dazu den vollständigen Pfad inklusive des Objektnamens verwendet und optional ein Feld ID zur Speicherung eines einheitlichen Identifikators vorsieht, schreibt AutomationML die Nutzung dieses CAEX-Tags ID zwingend vor. Hintergrund dieser Vorschrift ist, dass Planungswerkzeuge uneinheitliche Konzepte zur Objektidentifizierung verwenden, z. B. einheitliche Namen, eindeutige Identifikatoren oder eindeutige hierarchische Namenspfade. Manche Werkzeuge erlauben eine Modifikation des Identifikators während der Planungsphase, andere wiederum nicht. Innerhalb eines Werkzeuges funktioniert das hinreichend, aber ein Austausch von Daten über Werkzeuggrenzen hinweg ist technisch so nicht realisierbar, da das Zielwerkzeug beim gegenseitigen Datenaustausch keine Zuordnung der importierten Objekte zu bereits bestehenden durchführen kann. AutomationML schreibt deshalb zwingend GUIDs als Objektidentifizierungskonzept vor. Die werkzeugtechnische Umsetzung dieser Anforderungen bleibt dem Werkzeughersteller überlassen. Die GUID wird dem CAEX-Tag ID zugeordnet und bleibt über die gesamte Lebenszeit des Objektes in allen beteiligten Werkzeugen erhalten. Dies ist eine semantische Erweiterung der IEC 62424, erfordert jedoch keine Änderung am Datenformat CAEX. Klassen werden konform zur IEC 62424 durch ihren Namen (CAEX-Tag Name) sowie den vollständigen Pfad innerhalb ihrer Bibliothek identifiziert.

56

R. Drath und M. Schleipen

2.4.3 Unterstützung mehrerer Rollen Rollen sind eine praktische Möglichkeit, um die Bedeutung bzw. Semantik einer Komponente abstrakt und herstellerunabhängig zu beschreiben. Doch manchmal übernimmt eine Komponente mehrere Rollen. Während die IEC 62424 vorsieht, dass eine mehrere Rollen unterstützen kann, erlaubt sie pro Objektinstanz jedoch nur maximal eine Rolle. Um ein Gerät zu beschreiben, das mehrere Rollen unterstützt und beispielsweise sowohl Drucker, Fax als auch Scanners sein kann, muss deshalb gemäß IEC 62424 eine zusätzliche Rolle für das Kombi-Gerät erstellt werden. AutomationML geht hier weiter. Um der kombinatorischen Vielfalt möglicher Multifunktionsgeräte zu begegnen, sieht AutomationML in Ergänzung zur IEC 62424 die Zuordnung mehrerer Rollen explizit vor. Dies gelingt ohne Änderung von CAEX durch eine semantische Festlegung. Beide Konzepte werden in Abb. 2.9 und 2.10 anhand eines Beispieles gegenübergestellt. Dazu wird ein Multifunktionsgerät EinGerät betrachtet. Abbildung  2.9 zeigt, wie mit dem klassischen CAEX-Ansatz nach IEC 62424 vorgegangen wird. Das Objekt EinGerät unterstützt die Rollen Drucker, Fax,

Abb. 2.9   Klassische Einzel-Rollen-Zuordnung nach IEC 62424

2  Grundarchitektur: das Objektmodell

57

Abb. 2.10   Zuordnung mehrerer Rollen mit AutomationML

Scanner – modelliert durch das CAEX Element . Weiterhin besitzt es drei Attribute FaxDatenrate, Druckgeschwindigkeit und Scangeschwindigkeit sowie zwei Schnittstellen Stromanschluß und USB-Eingang. Da das Gerät alle drei Rollen zugleich spielen kann, muss in der entsprechenden Rollenbibliothek für diese Kombination eine zusätzliche Rolle Multifunktionsgerät vorgesehen werden, welche dann mit dem CAEX-Tag RefBaseRoleClassPath referenziert wird. Die Anforderungsspezifikation schreibt vor, dass gewisse Drucker-, Scan- und Faxgeschwindigkeiten erreicht werden sollen. Diese Anforderungen sind hier dem Element der neuen Rolle Multifunktionsgerät zugeordnet (hier z. B.: Multifunktionsgerät.ScanPerformance = 20). Im Mappingobjekt wird definiert, dass dieses Attribut der Scangeschwindigkeit von EinGerät entspricht. Die einzelnen Rollen können nicht referenziert werden. Die Aufgabe der multiplen Rollenzuordnung wird folglich in der Rollenbibliothek gelöst. Abbildung  2.10 zeigt, wie AutomationML dies erleichtert – ohne Änderung von CAEX.

58

R. Drath und M. Schleipen

Dazu werden alle per    zugeordneten Rollen lediglich anders als in der IEC 62424 beschrieben interpretiert: Dies sind nicht mehr die Rollen, die das Objekt spielen könnte, sondern diejenigen, welche die Instanz tatsächlich spielt. Um die Anforderungen an die unterschiedlichen Rollen korrekt zuordnen zu können, erfolgt die Zuordnung für alle benötigten Attribute und Schnittstellen unter     dadurch, indem ihnen der Rollenname vorangestellt wird: beispielsweise Drucker.Speed (Value = 20), Fax. Speed (Value = 54) und Scanner.Speed (Value = 1). Dies gilt auch für alle Einträge unter und . Nur für die unter RefBaseRoleClassPath angegebene bevorzugte Rolle (Hauptrolle) kann dies entfallen, die genannten Attribute und Schnittstellen beziehen sich auf die Haupt-Rolle. So muss unter RefBaseRoleClassPath statt Drucker. Speed nur noch Speed angegeben werden. Im Standardfall, dass ein Objekt nur eine Rolle spielen kann, sind beide Varianten identisch und gemäß IEC 62424 zu modellieren. Der nachfolgende Abschnitt beschäftigt sich mit Beziehungen zwischen Objekten und Klassen in CAEX.

2.5  Beziehungen zwischen CAEX-Objekten 2.5.1 Überblick Neben den eigentlichen Objekten sind auch deren Relationen untereinander von Interesse. Relationen drücken physikalische oder logische Beziehungen zwischen Objekten aus. AutomationML verwendet hierzu die von CAEX unterstützten Konzepte: • Vater-Kind-Relation: − zwischen Objektinstanzen, − zwischen Klassen gleichen Typs, • Vererbungsbeziehungen: − zwischen Klassen gleichen Typs, • Klassen-Instanz-Relation: − zwischen einer und einer Objektinstanz, − zwischen einer und einer Objektinstanz, − zwischen einer und einer Interface-Instanz, • Instanz-Instanz-Relation: − zwischen Objektinstanzen, − zwischen außerhalb von CAEX gespeicherten Daten.

2  Grundarchitektur: das Objektmodell

59

Abb. 2.11   Relationsarten in CAEX

Abbildung  2.11 illustriert diese Relationsarten anhand einer Beispielhierarchie, eine nähere Beschreibung erfolgt in den nachfolgenden Abschnitten. Die zugehörige XML-Beschreibung mit CAEX zeigt Abb. 2.12.

2.5.2 Vater-Kind-Relationen Vater-Kind-Beziehungen zwischen Objektinstanzen vom Typ werden benutzt, um eine „besteht-aus“-Beziehung abzubilden. So kann ein Objekt Schweißzelle untergeordnete Objekte Schweißroboter und Förderband enthalten. Kind-Objekte werden unterhalb ihres Vater-Objektes „eingehängt“ und können selbst wiederum Kind-Objekte enthalten. Auf diese Weise sind beliebig tiefe Objekthierarchien abbildbar. Das Löschen eines Objektes gilt auch für die Kinder. Abbildung  2.5 (siehe Abschnitt 2.3.3) zeigt eine Vater-Kind-Relation in der . Vater-Kind-Beziehungen finden sowohl in der Instanz-Hierarchie als auch in den Klassenbibliotheken Anwendung. Tabelle  2.1 illustriert diese Relationsart in einer Klassenbibliothek. Die ParentChildRelationExample­ ClassLib enthält eine Klasse ParentClass, die wiederum eine Klasse ChildClass enthält. Die Vater-Kind-Relation zwischen Klassen bildet entgegen der intuitiven Erwartung übrigens keine Vererbungsbeziehung ab, sondern dient lediglich der Abbildung nutzerdefinierter Bibliotheksstrukturen. Vererbungsbeziehungen werden mit Hilfe des CAEX-Tags RefBaseClassPath abgebildet und sind nicht limitiert auf die nächsthöhere Hierarchie-Ebene. Zusammenfassend gilt: Vater-Kind-Relationen zwischen Objektinstanzen bilden eine „besteht-aus“-Beziehung ab. Vater-KindBeziehungen zwischen Klassen haben keine semantische Bedeutung sondern dienen lediglich der Abbildung nutzerdefinierter Hierarchien.

60

R. Drath und M. Schleipen

Abb. 2.12   XML-Beschreibung von Relationen

2.5.3 Vererbungsbeziehungen Eine Vererbungsrelation dient dazu, eine neue Klasse auf Basis einer bereits vorhandenen zu definieren. In CAEX wird dazu der Pfad der Elternklasse im CAEX-Tag RefBaseClassPath referenziert. Die neue Klasse „erbt“ damit alle „Innereien“ der Elternklasse. Das ermöglicht eine Verfeinerung von Objekten unter Wiederverwendung bewährter Vorlagen. Tabelle 2.2 zeigt dies anhand eines Beispieles, in dem

2  Grundarchitektur: das Objektmodell

61

Tab. 2.1   Vater-Kind-Beziehung innerhalb einer Klassenbibliothek

Tab. 2.2   Beispiel einer Vererbungsrelation zwischen Klassen

eine Klasse SpecialRobot1234 von der Klasse Robot1234 erbt. Wie in Abschnitt 2.4.1 bereits erläutert, unterstützt CAEX die Vererbung zwischen zwei Klassen desselben Typs sowie zwischen einer Klasse und einer Instanz. AutomationML hingegen schränkt dies ausdrücklich ein und erlaubt nur die Vererbung zwischen Klassen.

2.5.4 Klassen-Instanz-Relationen Instanzen repräsentieren individuelle Objekte und sind durch einen eindeutigen Identifier sowie einen eigenen Satz von Parametern gekennzeichnet. Instanzen werden als in der oder als Teil einer abgebildet. Abschnitt 2.4.1 beschreibt drei Wege, um Instanzobjekte mit konkreten Inhalten zu versehen. AutomationML definiert ausdrücklich, dass die Klassen-Instanz-Relation keine Vererbungsbeziehung darstellt. Eine Instanz wird am einfachsten durch Kopieren einer erstellt, wobei ihr eine Referenz RefBaseSystem-

62

R. Drath und M. Schleipen

Tab. 2.3   Beispiel einer Klassen-Instanz-Relation

UnitPath zur Ursprungsklasse mit dem vollständigen Pfad und Namen der Klasse zugeordnet wird. Tabelle 2.3 zeigt dies anhand eines Objektes ObjectA, welches auf seine Ursprungsklasse generic_Valve aus der Bibliothek mySystemUnitClassLib verweist. Die Instanz selbst kann nach dem Kopiervorgang frei verändert werden. Wird eine Klasse verändert, zieht dies keine automatische Aktualisierung der Instanzen nach sich – dies wird als Tool-Leistung betrachtet. Allerdings wird empfohlen, dass dies in AutomationML stets in Form einer neuen Klasse erfolgt, die mittels dem CAEX-Tag OldVersion auf die alte Version verweist. Dies ermöglicht beim Datenaustausch das Nachvollziehen von Änderungen in Klassenbibliotheken. Der CAEX-Tag RefBaseSystemUnitPath muss nicht zwangsläufig eine Klasse referenzieren, sondern kann alternativ eine Instanz referenzieren. Dies ist CAEXkonform und Grundlage des „Mirror-Konzepts“ nach IEC 62424. Die referenzierte Instanz wird als „Master-Objekt“ bezeichnet, während das referenzierende Objekt nur als Spiegelbild des Originals fungiert und deshalb als „Mirror-Objekt“ bezeichnet wird. Beide Objekte werden als identisch betrachtet, Änderungen dürfen jedoch nur am Original vorgenommen werden – diese werden im Mirror-Objekt „gespiegelt“. Dies erlaubt, ein und dasselbe Objekt in mehreren Hierarchien zu platzieren. Somit können komplexe Objektnetzwerke mit verschränkten Strukturen abgebildet werden.

2.5.5 Relationen zwischen Instanzen Relationen zwischen Objektinstanzen werden durch das Verknüpfen von Objektschnittstellen abgebildet, indem sie mit ’s verbunden werden. Dabei gilt: Alle AutomationML-konformen Schnittstellen müssen direkt oder indirekt von einer AutomationML-StandardInterface-Klasse abgeleitet werden. Mit Hilfe von ’s erfolgt die Verknüpfung von Objektinstanzen wie in der IEC 62424 beschrieben. Abbildung 2.13 zeigt dies anhand einer Beispielstruktur, in der ein Startsignal von Roboter Rob1 mit dem Signaleingangs-

2  Grundarchitektur: das Objektmodell

63

Abb. 2.13   Relation zwischen zwei Instanzen

kanal Channel01 des IO-Boards Board01 verbunden wird. Der zugehörige XMLQuellcode ist in Abb. 2.14 dargestellt. Für die Verwaltung der Links wird empfohlen, diese zwischen Objekten am obersten gemeinsamen Elternobjekt zu speichern. Alternativ ist es sinnvoll, alle Links am obersten Objekt der gesamten Instanzhierarchie unterzubringen.

Abb. 2.14   XML-Dokument für eine Relation zwischen Instanzen

64

R. Drath und M. Schleipen

2.6  Referenzierung extern gespeicherter Informationen 2.6.1 Referenzierung von COLLADA- und PLCopen-XML-Daten Komplexe Informationen wie Geometrie, Kinematik und Ablauflogik werden außerhalb von CAEX gespeichert. Zur Modellierung dieser Engineering-Aspekte stehen bereits die Datenformate COLLADA und PLCopen XML zur Verfügung; weitere Datenformate können künftig mit den Konzepten von AutomationML ebenfalls integriert werden. Um eine Zuordnung zwischen CAEX-Objekten und den genannten externen Dokumenten zu modellieren, definiert AutomationML spezielle Referenzmechanismen. Eine Referenz auf extern gespeicherte Informationen zeigt dabei lediglich auf geeignete Einstiegspunkte im zugehörigen Dokument. AutomationML definiert zu diesem Zweck die AutomationML-Standard-Schnittstellen PLCopen­XMLInterface und COLLADAInterface. Ihre Anwendung wird in Abb. 2.15 und 2.16 gezeigt. Das Objekt Robot01 verweist hier auf ein COLLADADokument COLLADA1.dae sowie auf eine PLCopen-XML-Datei LogicFile.xml. Der XML-Text verdeutlicht die Referenzierung: Dazu wird dem Objekt Robot01 für jede Referenz je ein CAEX-Interface zugeordnet. Eine nähere Beschreibung für die Referenzmechanismen wird in den Kap. 3 und 4 gegeben.

2.6.2 Relationen zwischen extern gespeicherten Informationen AutomationML kann Relationen zwischen Informationen in externen Dokumenten abbilden – z. B. die Verbindung des Startsignals einer SPS-Steuerungslogik

Abb. 2.15   Beispiel für Referenzen

2  Grundarchitektur: das Objektmodell

65

Abb. 2.16   XML-Text für das Referenzbeispiel

mit dem Trigger einer Roboter-Ablaufbeschreibung. In den Abb. 2.17, 2.18, 2.19 und 2.20 wird das zugrunde liegende Konzept illustriert: Zunächst müssen alle benötigten Informationen in den externen Dokumenten identifiziert und im Objektmodell als CAEX- publiziert werden. Dies erfolgt unter Verwendung der Schnittstellenklassen COLLADAInterface bzw. PLCopen­ XMLInterface. Nach der Publikation können diese Schnittstellen innerhalb von CAEX wie gewohnt mit Hilfe von Instanz-Instanz-Relationen verbunden werden. Bei der Modifizierung externer Dokumente ist darauf zu achten, dass Schnittstellen darin weiterhin mit denen in CAEX übereinstimmen.

Abb. 2.17   Publikation von COLLADA-Schnittstellen in CAEX

66

Abb. 2.18   Veröffentlichte COLLADA-Schnittstellen in CAEX

Abb. 2.19   Publikation von PLCopen-XML-Schnittstellen in CAEX

Abb. 2.20   Veröffentlichte PLCopen-XML-Schnittstellen in CAEX

R. Drath und M. Schleipen

2  Grundarchitektur: das Objektmodell

67

2.7  AutomationML-Standardbibliotheken AutomationML definiert eine Reihe von Standard-Bibliotheken zur Modellierung von Planungsdaten. Die Basisbibliotheken werden in diesem Abschnitt vorgestellt.

2.7.1 AutomationML-Schnittstellenbibliothek Die Schnittstellenbibliothek AutomationMLInterfaceClassLib stellt grundlegende Basisklassen zur Modellierung von Schnittstellen zur Verfügung. Basis ist das AutomationMLBaseInterface, eine abstrakte Schnittstellenklasse. Alle weiteren Schnittstellenklassen werden von dieser abgeleitet, siehe Tab. 2.4. Jede AutomationML-konforme Objektschnittstelle muss direkt oder indirekt von einer der Standardschnittstellen abgeleitet werden. Weiterhin dürfen nur Schnittstellen gleichen Typs miteinander verbunden werden. Die Bibliothek ist in Abb. 2.21 als Baum dargestellt. Tab. 2.4   AutomationML-Standard-Schnittstellenklassen Schnittstellenklasse Kurzbeschreibung AutomationML_BaseInterface Order

PortConnector InterlockingConnector PPRConnector ExternalDataConnector COLLADAInterface

PLCopenXMLInterface Communication SignalInterface OPCTag

Abstrakte Basis-Schnittstellenklasse und Basisklasse aller AutomationML-Schnittstellenklassen Schnittstelle zur Beschreibung von Ordnungsprinzipien, beispielsweise der Reihenfolge von Förderbändern. Deren Attribut Direction beschreibt die Ordnungsrichtung und darf die Werte In, Out oder InOut einnehmen Schnittstelle zur Beschreibung von AutomationML-Ports Schnittstelle zur Verbindung von Signal- und Komponentengruppen (siehe Abschnitt 4.5) Schnittstelle zur Modellierung von Produkt-, Ressourcen- und Prozessverbindungen (siehe Abschnitt 2.9.6) Generische Schnittstelle zu externen Daten Schnittstelle zu COLLADA-Dokumenten (siehe Abschnitt 2.6.1). Dessen Attribut refURI speichert den Pfad zu einem geeigneten Einstiegspunkt im externen Dokument. Das Attribut refType legt fest, wie die referenzierte Geometrie bzw. Kinematik zu verwenden ist (siehe Abschnitt 3.3.8) Schnittstelle zu PLCopen-XML-Dokumenten (siehe Abschnitt 2.6.1). Dessen Attribut refURI speichert den Pfad zu einem geeigneten Einstiegspunkt im externen Dokument Generische Kommunikationsschnittstelle Generische Signalschnittstelle; die Attribute Type, Direction, BitCount, Orientation und Range dienen zur Beschreibung typischer Signaleigenschaften Schnittstelle zur Beschreibung von OPC-Tags (siehe Abschnitt 6.6); dessen Attribute TagName, DataType, OPCDataType, SignalPath und AccessPermissions dienen zur Beschreibung typischer OPC-Tag-Eigenschaften

68

R. Drath und M. Schleipen

Abb. 2.21   AutomationMLStandard-Schnittstellenbibliothek

2.7.2 AutomationML-Basis-Rollenbibliothek Jedes Planungsobjekt übernimmt innerhalb seiner Umgebung eine Funktion und spielt eine oder mehrere „Rollen“. Dies ist Ausgangspunkt des CAEX-Rollenkonzeptes, welches in Abschnitt 2.3.4 beschrieben wird. Eine Rolle gibt keine Auskunft über die technische Umsetzung einer Funktion, eines Gerätes oder Moduls, definiert aber die abstrakte Bedeutung eines Planungsobjektes. AutomationML gibt zu diesem Zweck eine Reihe von Rollenbibliotheken vor. Im Folgenden wird die AutomationML-Basisbibliothek AutomationMLBaseRoleClassLib vorgestellt (siehe Abb. 2.22 und Tab. 2.5). Darüber hinaus definiert das AutomationML-Konsortium erweiterte Rollenklassen für unterschiedliche Industrien. Die Erstellung nutzerdefinierter Rollenbibliotheken wird in Abschnitt 2.8 erläutert. Jede nutzerdefinierte Rollenklasse und jedes AutomationML-Objekt muss direkt oder indirekt eine dieser Basis-Rollenklassen referenzieren – das Zielwerkzeug kann auf diese Weise die Bedeutung des betreffenden Objektes automatisch in abstrakter Form erkennen.

Abb. 2.22   AutomationMLStandard-Rollenbibliothek

2  Grundarchitektur: das Objektmodell

69

Tab. 2.5   AutomationML-Standard-Basis-Rollenbibliothek Rollenklasse Kurzbeschreibung AutomationML BaseRole Group Facet Port Resource Product Process Structure

Abstrakte Basis-Rollenklasse und Basisklasse aller AutomationMLRollenklassen Rollentyp zur Umsetzung des Gruppen-Konzeptes, siehe Abschnitt 2.9.4 Rollentyp zur Umsetzung des Facetten-Konzeptes, siehe Abschnitt 2.9.3 Rollentyp zur Umsetzung des Port-Konzeptes, siehe Abschnitt 2.9.2 Rollentyp zur Beschreibung von Ressourcen, siehe Abschnitt 2.9.6 Rollentyp zur Beschreibung von Produkten, siehe Abschnitt 2.9.6 Rollentyp zur Beschreibung von Prozessen, siehe Abschnitt 2.9.6 Generischer Rollentyp zur Beschreibung abstrakter Struktur­elemente, beispielsweise Hierarchieebenen

2.7.3 Fertigungstechnische Rollenbibliothek Für die Planung fertigungstechnischer Anlagen liefert AutomationML eine Basisbibliothek AutomationMLMIRoleClassLib, wobei MI für Manufacturing Industry steht (siehe Abb. 2.23). Die Klasse ManufacturingEquipment ist von der Basisrollenklasse Resource abgeleitet und stellt eine abstrakte Rolle für fertigungstechnische Komponenten dar. Die Klassen Transport, Clamp, Gate, Robot, Tool, Crane, Drive, Skid, Machine und StaticObject verfeinern sie und erlauben somit bereits eine grobe Beschreibung fertigungstechnischer Zellen oder Anlagen.

2.7.4 Leittechnische Rollenbibliothek Für die Planung von Leittechnik liefert AutomationML eine Basisbibliothek AutomationMLCSRoleClassLib, wobei CS für Control System steht (siehe Abb. 2.24).

Abb. 2.23   Fertigungstechnische Basis-Rollenbibliothek

70

R. Drath und M. Schleipen

Abb. 2.24   Leittechnische Basis-Rollenbibliothek

Die Basisklasse ControlEquipment ist von der Basisklasse Resource abgeleitet und stellt eine Reihe typischer leittechnischer Rollen zur Verfügung. Die Klasse ControlEquipment ist ebenfalls von der Basisrollenklasse Resource abgeleitet und stellt eine abstrakte Rolle für leittechnische Komponenten dar. Deren Kindklassen beschreiben bereits konkrete und typische leittechnische Komponenten und ermöglichen eine grobe Beschreibung von Automatisierungssystemen. Im nächsten Abschnitt wird die Erstellung nutzerdefinierter Daten beschrieben.

2.8  Abbildung nutzerdefinierte Daten 2.8.1 Übersicht Die Speicherung und der Austausch nutzerdefinierter Daten ist Hauptziel von AutomationML, diese bilden die Majorität aller Daten. CAEX erlaubt flexibel, eigene Klassen zu definieren und sie mit eigenen Attributen und Schnittstellen zu versehen. CAEX ist ein Meta-Modell und damit gut in der Lage, individuelle Datenmodelle abzubilden. Gäbe es ein Weltmodell des Engineering, könnten alle Planungsdaten auf dieselbe Weise modelliert werden – die Inhalte der einzelnen Objekte sind in der Praxis jedoch meist individuell und können von Projekt zu Projekt variieren: Dazu gehören Attribute, SystemUnit-, Rollen- und Schnittstellenklassen. Diese müssen deshalb zunächst definiert werden. Die folgenden Abschnitte erläutern, wie dies mit AutomationML erfolgt.

2.8.2 Nutzerdefinierte Attribute Attribute speichern individuelle Eigenschaften von Objekten. Sie haben typischerweise einen Namen und einen Wert. Darüber hinaus ist häufig ihr Datentyp sowie ihre Einheit von Bedeutung.

2  Grundarchitektur: das Objektmodell

71

Abb. 2.25   Beispiel für nutzerdefinierte Attribute

Das Anlegen nutzerdefinierter Attribute erfolgt mit CAEX-Standardmechanismen, CAEX sieht hierfür den Datentyp vor. Attribute können jeder Art von Klassen und Instanzen zugeordnet werden, um individuelle Eigenschaften zu beschreiben. Das in Abb. 2.25 dargestellte Beispiel soll dies verdeutlichen: Hier wird ein Objekt mit drei nutzerdefinierten Attributen ausgestattet. Den Attributen können jeweils ein Datentyp, eine Einheit und ein Wert zugeordnet werden. Darüber hinaus kann jedes Attribut mit einer semantischen Referenz versehen werden, die seine Bedeutung erklärt, beispielsweise zu einem ProjektWörterbuch oder einer Norm. Die Zuordnung von Einschränkungen, sogenannten , oder Initialwerten ist ebenfalls vorgesehen. Attribute können zudem ineinander verschachtelt werden, um komplexe Datentypen abzubilden. Ihre Anwendungsmöglichkeiten sind vielfältig – beim Datenaustausch ist jedoch mit Hilfe von Vereinbarungen sicherzustellen, dass alle beteiligten Werkzeuge die Bedeutung der Attribute gleichermaßen kennen.

2.8.3 Nutzerdefinierte SystemUnit-Klassen SystemUnit-Klassen dienen zur Abbildung herstellerspezifischer Planungsobjekte. Dies können einzelne Automatisierungskomponenten, umfangreiche Produktkataloge oder anwendungsspezifische Bibliotheken für Leittechnik, Verfahrenstechnik oder Fertigungstechnik sein. Sie stellen das Gegenstück zu den Rollenklassen dar, weil sie deren konkrete technische Realisierung beschreiben können. Mittels sollte jeder zugeordnet werden, welche Rollen sie unterstützen können; auf diese Weise gelingt eine semantische Zuordnung zwischen nutzerdefinierten Klassen und AutomationMLStandardrollen. Nur Klassen mit einer solchen Zuordnung sind AutomationMLkonform. Jede Klasse kann mit Attributen, Schnittstellen, internen Objekten und Relationen ausgestattet sein, welche die jeweilige technische Realisierung näher beschreiben. Eine einfache Beispielbibliothek ist in Abb. 2.26 dargestellt.

72

R. Drath und M. Schleipen

Abb. 2.26   Nutzerdefinierte SystemUnit-Klassenbibliothek

2.8.4 Nutzerdefinierte Rollenbibliotheken Die Erstellung nutzerdefinierter Bibliotheken ist mit AutomationML ausdrücklich vorgesehen. Das AutomationML-Konsortium stellt hierzu eine Reihe von Beispielbibliotheken vor, beispielsweise die AutomationMLExtendedRoleLib (siehe Abb. 2.27). Jede der hier aufgeführten Rollen wird mit ihrer Elternklasse dargestellt. Dies verdeutlicht ein Grundkonzept von AutomationML: Jede neu definierte Rolle muss direkt oder indirekt von einer der Standardrollen abgeleitet werden. Ein anschauliches Beispiel für die Verfeinerung von Basisklassen stellen die Rollen Unit, Site, Hall, Line, Cell und FunctionGroup dar. Sie sind von der Basisklasse Structure abgeleitet, dienen der Modellierung von Strukturelementen in einem Objektbaum und können domänenübergreifend eingesetzt werden. Ein weiteres Beispiel sind die Klassen Turntable, Conveyor, LiftingTable, AGV, und Transposer, sie werden von Transport abgeleitet und verfeinern diese abstrakte Rolle bereits durch typische Arten von Transporteinrichtungen. Die Klasse Conveyor mit ihren Kindern verdeutlicht ebenfalls die Möglichkeit der fortwährenden Verfeinerung. Die aufgeführten Rollenklassen ermöglichen bereits eine recht breite Beschreibung typischer fertigungstechnischer Einrichtungen auf grober Planungsebene, ohne die technische Implementierung der benötigten Objekte zu kennen. Sie erschließt den beteiligten Werkzeugen beim Datenaustausch die grundlegende Bedeutung der modellierten Objekte. Dies ist zudem der Schlüssel für die Entwicklung von Plausibilitätsanalysen, Prüfmechanismen, Code-Generatoren oder Werkzeugen für die Durchführung automatischer Planungsschritte – eine unter dem Namen „Automation of Automation“ bekannte Forschungsrichtung.

2  Grundarchitektur: das Objektmodell

73

Abb. 2.27   Erweiterte AutomationML-Rollenbibliothek

Rollenbibliotheken lassen sich demnach als semantische Bibliothek fertigungstechnischer Grundkomponenten verstehen und erleichtern den Austausch von Planungsdaten erheblich. Die Erstellung weiterer domänenspezifischer Rollenbibliotheken wird vom AutomationML-Konsortium ausdrücklich unterstützt.

2.8.5 Fazit Bezüglich Geometrie, Kinematik und Logik ermöglicht AutomationML bereits „out of the box“ einen automatischen Datenaustausch von einfachen Objekten bis zu

74

R. Drath und M. Schleipen

komplexen Fertigungslinien. Dies gelingt auf Basis der semantisch und syntaktisch wohldefinierten Datenformate COLLADA und PLCopen XML. Auch die zugehörigen Anlagen-Objektmodellstrukturen können mit AutomationML standardmäßig übertragen werden. Durch den Bezug auf Standard-Rollenklassen gelingt zudem eine semantische Interpretation der Einzelobjekte als Grundlage für die automatische Erkundbarkeit der Anlagen-Strukturen. Für die Vielfalt der unstandardisierten Anlagenkomponenten und deren Eigenschaften ist AutomationML jedoch kein „out-of-the-box“-Datenformat. Zu vielfältig sind die Datenkonzepte, Semantiken und Modellierungsregeln der marktgängigen Werkzeuge – eine Konsequenz aus der Vielzahl an Werksnormen, historisch gewachsenen Semantiken, regionalen Unterschieden und existierenden Standards. Daher ist die Modellierung nutzerdefinierter Klassen, Attribute und Rollen explizit in AutomationML von großer Bedeutung und explizit vorgesehen. Heutige Werksnormen oder nutzerdefinierte Ontologien können bereits modelliert und vereinbart werden. Damit ist AutomationML jedoch auch für die Abbildung künftiger Standardisierungen vorbereitet. Abschnitt 6.9 fasst eine Reihe von Empfehlungen zusammen, die sich unter anderem auf den effizienten Umgang mit nutzerdefinierten Daten beziehen.

2.9  Erweiterte AutomationML-Konzepte 2.9.1 Überblick Für spezielle Engineering-Aspekte sieht AutomationML eine Reihe erweiterter Konzepte vor. Dazu gehören das Port-Konzept für die Modellierung komplexer Schnittstellen, das Facetten-Konzept zur Filterung von Attributen und Schnittstellen, das Gruppen-Konzept zur Auswahl von Objekten sowie ein Ressource-Produkt-Prozess-Konzept für die Abbildung unterschiedlicher Sichtweisen auf dieselbe Anlage.

2.9.2 AutomationML Port-Konzept Das AutomationML Port-Konzept wurde entwickelt, um komplexe „Superschnittstellen“ beschreiben zu können, die aus einer Vielzahl von Einzelschnittstellen bestehen (siehe Abb. 2.28). Man kann es sich bildlich wie einen Stecker für LKWAnhänger vorstellen, der viele einzelne Verbindungen bündelt. In AutomationML wird ein Port-Objekt als modelliert, welche die AutomationML-Rolle Port referenziert. Ein Port enthält alle benötigten Einzelschnittstellen vom Typ . Ähnlich wie bei einem Stecker oder einer Buchse können Ports als Ganzes miteinander verbunden werden, ohne die Einzelverbindungen betrachten zu müssen.

2  Grundarchitektur: das Objektmodell

75

Abb. 2.28   Port-Konzept

In Abb. 2.29 und Abb. 2.30 wird das Port-Konzept anhand eines Beispieles erläutert. Das abgebildete Objekt Station besteht aus den Unterobjekten Förderband1 und Förderband2. Beide Objekte besitzen je ein Port-Objekt. Diese umfassen zusätzlich zu ihren inhaltlichen Schnittstellen auch die Schnittstelle ConnectionPoint, die von der AutomationML-Interfaceklasse PortConnector abgeleitet wird. Das Port-Konzept vereinfacht die Verbindung dieser Schnittstellen: Nur die beiden ConnectionPoints müssen mit Hilfe eines verbunden werden. Ohne dieses Konzept müsste die Verbindung der Schnittstellen über separate ’s für jede einzelne Unterschnittstelle erfolgen.

Abb. 2.29   Beispiel für AutomationML-Ports

76

R. Drath und M. Schleipen

Abb. 2.30   Beispiel für AutomationML-Ports mit CAEX

Ports werden durch Attribute näher beschrieben: • Das Attribut Direction gibt Auskunft über die Schnittstellenrichtung. Es darf die Werte Out, In und InOut annehmen. • Das Attribut Category definiert die Kategorie des Ports; nur Ports mit gleicher Kategorie dürfen verbunden werden. Die Kategorie kann frei benannt werden,

2  Grundarchitektur: das Objektmodell

77

Tab. 2.6   Nutzerdefinierter AutomationML-Port als Klasse

im nachfolgenden Beispiel wird die Kategorie mit MaterialFlow bezeichnet. Dies ermöglicht eine spätere werkzeuggestützte Plausibilitätsanalyse. • Das Attribut Cardinality enthält die Subattribute MinOccur und MaxOccur, welche die minimale beziehungsweise maximale Anzahl von Verbindungen eines Port beschreiben. Das folgende Beispiel in Tab. 2.6 demonstriert, wie ein Port-Objekt als nutzerdefinierte myPortClass in einer nutzerdefinierten SystemUnit-Klassenbibliothek beschrieben werden kann.

2.9.3 AutomationML Facetten-Konzept Das AutomationML Facetten-Konzept wurde entwickelt, um spezielle Sichten auf Attribute oder Schnittstellen eines Objektes abbilden zu können, beispielsweise eine Sicht auf SPS- oder HMI-relevante Daten eines Förderbandes. Ein Facetten­ Objekt fungiert somit als Attribut- und Schnittstellenfilter für dessen Eigentümerobjekt. Bei dem in Abb. 2.31 beschriebenen Förderband wird ein Facetten-Objekt als modelliert, mit einem beliebigen Namen wie HMI-Facette versehen und mit der Standard-AutomationML-Rolle Facet verknüpft. Alle Attribute und Schnittstellen dieser HMI-Facette referenzieren auf diejenigen Attribute oder Schnittstellen des Förderband-Objektes, die für den SPS- oder HMI-Aspekt von Bedeutung sind. Ein separater SPS- oder HMI-Generierungs-Algorithmus kann

78

R. Drath und M. Schleipen

Abb. 2.31   Beispiel für AutomationML-Facetten

anhand des ihm bekannten Namens dieses Facetten-Objektes relevante Informationen identifizieren und beispielsweise zugehörige HMI-Templates oder SPS-Funktionsbausteine instanziieren und parametrieren. Eine Beispielanwendung für Facetten wird in Abb. 2.31 dargestellt. Das Objekt Förderband besitzt die Attribute A und B sowie die Schnittstellen X und Y. Die zugeordnete PLC-Facette referenziert das Attribut A und die Schnittstelle X, HMIFacette die Attribute A und B sowie die Schnittstelle Y. Beide Facetten liefern einen gefilterten Blick auf die für die SPS beziehungsweise HMI relevanten EngineeringDaten des Förderbandes. Die XML-Umsetzung mit CAEX wird in Abb. 2.32 dargestellt. Auch hier werden Referenzen mittels „/…/“ in verkürzter Darstellung gezeigt, in realen Dokumenten müssen die Pfade allerdings vollständig sein.

Abb. 2.32   Beispiel für AutomationML-Facetten mit CAEX

2  Grundarchitektur: das Objektmodell

79

Das folgende Anwendungsbeispiel verdeutlicht den Nutzen des Facetten-Konzepts. Das Attribut A repräsentiert den Namen eines herstellerspezifischen SPSFunktionsbausteins, welches die Funktionslogik des Förderbandes realisieren soll. Die Schnittstelle X ist im Beispiel der Name eines Stellsignals, welches in den SPSFunktionsbaustein eingeht. Ein SPS-Code-Generierungsalgorithmus kann nun aus allen Objekten des Anlagenmodells sämtliche Facetten mit dem Namen PLC-Facette heraussuchen. Die darin referenzierten Attribute und Schnittstellen sind dem Algorithmus bekannt; er kann daraus die zugehörigen Funktionsbausteine instanziieren und mit den vorgegebenen Signalen verschalten. Im Ergebnis kann dadurch eine automatische Code-Generierung für alle Förderbänder erreicht werden. Eine ähnliche Vorgehensweise ist für die Erstellung von Bedienoberflächen möglich. Ein HMI-Generierungsalgorithmus kann alle Facetten mit dem Namen HMI-Facette aus der Menge aller Objekte des Anlagenmodells auswählen. Die darin referenzierten Attribute und Schnittstellen sind auch hier dem Algorithmus bekannt, er kann wie oben beschrieben die zugehörigen Bedienelemente instanziieren und eine entsprechende Bedienoberfläche für alle Förderbänder generieren. Die hier erläuterten Anwendungsfälle verdeutlichen, dass der Engineering-Algorithmus interne Kenntnis über die herstellerspezifischen Module, Signale und Schnittstellen besitzen muss. AutomationML liefert diese Semantik nicht mit, ermöglicht aber die Anwendung intelligenter oder wissensbasierter Algorithmen.

2.9.4 AutomationML Gruppen-Konzept Das Gruppen-Konzept wurde entwickelt, um eine Separierung von Struktur- und Instanzinformationen zu ermöglichen. Da unterschiedliche Engineering-Werkzeuge verschiedene Sichten auf dieselben Daten benötigen, ist die separate Speicherung dieser Informationen sinnvoll. Das AutomationML-Gruppen-Konzept erlaubt dies durch Anordnung identischer Objekte in verschiedenen Hierarchien. In Abb. 2.33 wird dies anhand eines Beispieles erläutert. Das Objekt Station beinhaltet vier Kind-Objekte. Gruppe1 fasst Förderband1 und Förderband2 zusammen, während Gruppe2 nur SPS 1 enthält.

Abb. 2.33   Beispiel für Gruppen

80

R. Drath und M. Schleipen

Abb. 2.34   Umsetzung des Gruppenobjekt-Beispiels mit CAEX

Die Elemente der Gruppen werden als „Mirror-Objekte“ modelliert (siehe auch Abschnitt 2.5.4). Die Mirror-Objekte referenzieren über die GUID diejenigen Objekte, die in der Gruppe aufgeführt werden sollen. Eine Gruppe fasst eine Untermenge von Objekten einer Hierarchie zusammen, beispielsweise alle Förderbänder einer Station. Ein Gruppenobjekt kann somit als Objektfilter verstanden werden. Dazu wird in der Hierarchie ein neues mit der Rolle Group angelegt. Anschließend wird diesem Gruppenobjekt für alle gewünschten Objekte je eine Relation zugeordnet. In Abb. 2.34 wird die Umsetzung im XML-Code unter Verwendung des MirrorKonzeptes deutlich. Die abgebildeten Pfeile zeigen die Mirror-Objekte mit ihren Master-Objekten, diese Objektpaare sind als identisch zu betrachten. AutomationML-Gruppen können darüber hinaus mit dem Attribut AssociatedFacet versehen werden. Dessen Bedeutung wird im folgenden Abschnitt erläutert.

2.9.5 Kombination aus Gruppen- und Facetten-Konzept Das Gruppen- und das Facetten-Konzept lassen sich kombinieren. Mit Hilfe des Attributes AssociatedFacet kann eine Gruppe optional einer Facette zugeordnet werden, die dazu einen eindeutigen Namen besitzen muss. Dieser Name wird dem Attribut zugeordnet. Dies erlaubt beispielsweise, für das Gruppenobjekt Gruppe1 einen Verweis auf die Facette HMI-Facette abzubilden. Ein separater Engineering-Algorithmus kann nun anhand der Gruppe1 identifizieren, welcher Engineering-Aspekt behandelt werden soll. Im nächsten Schritt werden alle zugehörigen Objekte Förderband1 und Förderband2 aufgesucht und deren assoziierte Facettenobjekte identifiziert und verarbeitet. Auf diese Weise gelingt beispielsweise die automatische Generierung einer Bedien- und Beobachtoberfläche für beide Förderbänder. Abbildung  2.35 veranschaulicht dies anhand einer Anlagenstruktur mit zwei Förderbändern, die

2  Grundarchitektur: das Objektmodell

81

Abb. 2.35   Kombination von Gruppen- und Facetten-Konzept

jeweils zwei Facetten-Objekte besitzen. Gruppe1 stellt alle Förderbänder der Anlage zusammen und ist mit der Facette PLCFacet assoziiert. Gruppe2 stellt ebenfalls alle Förderbänder der Anlage zusammen, ist jedoch mit HMIFacet assoziiert. Ein Engineering-Algorithmus kann auf Basis dieser Informationen gezielt alle Gruppen aufsuchen, die eine Assoziation zur PLCFacet besitzen. Von Gruppe1 aus findet er die zugehörigen Förderbandobjekte und kann anhand der dort modellierten Facettenobjekte die Generierung von SPS-Code ausführen. Auch diese Vorgehensweise basiert auf der Kenntnis eines proprietären Engineering-Algorithmus über die verwendeten Attribute und Schnittstellen, ohne dass diese in AutomationML eingebettet sind. Abbildung  2.36 zeigt den zugehörigen XML-Quellcode.

82

R. Drath und M. Schleipen

Abb. 2.36   XML-Code zur Kombination von Gruppen- und Facetten-Konzept

2  Grundarchitektur: das Objektmodell

83

Abb 2.37   HMI-Faceplate B

Abb 2.38   Generiertes HMI

Basierend auf dem vorhergehenden Beispiel zeigt die folgende Anwendung, wie mit dem Facetten- und Gruppen-Konzept automatisch eine Anzeige- und Bedienoberfläche generiert werden kann. Im Beispiel beinhaltet das Attribut B den Namen eines HMI-Faceplates, welches als Basis zur Visualisierung des Förderbandes nebst gewünschter Prozessvariablen verwendet werden soll (siehe Abb. 2.37). Wie oben beschrieben, ermittelt ein Engineering-Algorithmus alle diejenigen Objekte, die in der Bedienoberfläche visualisiert werden sollen und findet Förderband1 und Förderband2. Basierend auf den individuellen Schnittstellen Y für beide Förderbänder instanziiert der Engineering-Algorithmus die Vorlage B zweimal stellvertretend für beide Förderbänder und verbindet die zugehörigen Instanz-Schnittstellen Y (siehe Abb. 2.38). Im Ergebnis entsteht ein Anzeige- und Bedienbild, welches für beide Förderbänder individuelle Abbildungen mit Zugriff auf die jeweiligen Prozesssignale enthält.

2.9.6 Ressource-Produkt-Prozess-Konzept Durch das Konzept der Digitalen Fabrik und die damit verbundene Notwendigkeit, alle am Produktionsprozess beteiligten Planungsdaten elektronisch zu beschreiben, hat sich in der Praxis eine Dreiteilung in Ressource-, Prozess- und Produktdaten bewährt und ist bereits in Softwarewerkzeugen der Digitalen Fabrik verfügbar. Ressourcen, Produkte und Prozesse stehen dabei in Beziehungen zueinander: Ein Produkt wird mit Ressourcen bearbeitet, die ihrerseits Prozesse ausführen. Dieses

84

R. Drath und M. Schleipen

Drei-Sichtenkonzept (siehe Abb. 2.39) wird auch in anderen Projekten und Bereichen verfolgt, beispielsweise im Bereich der Manufacturing Execution Systeme (MES) mit der ISA95, die diesem Modell ähnelt, siehe auch IEC62264 (2003) und Adams et al. (2007). Auch die Integrierte Unternehmensmodellierung (Wikipedia.de 2009) betrachtet diese Aufteilung. Im Forschungsprojekt Modale (Abecker et al. 2004), sowie im Forschungsprojekt ProduFlexil (Ebel et al. 2007; Schleipen et al. 2008) wurde ebenfalls zwischen Ressourcen, Produkten und Prozessen unterschieden. Ein Produkt ist beispielsweise eine Konsole oder eine Karosse, ein Prozess ein Schweißprozess oder Förderprozess und eine Ressource zum Beispiel ein Transportsystem oder ein Drehtisch. Auch Young et al. (2007), sowie Cutting-Decelle et al. (2007) beschäftigen sich mit der Aufteilung aller beteiligten Komponenten in Prozesse, Produkte und Ressourcen. Beispiele für geläufige Definitionen finden sich in Michel (2005). Soenen u. Olling (2002) behandelt die merkmalsbasierte Integration von Produkten, Prozessen und Ressourcen und referenziert weitere Quellen zu diesem Thema. In der Fertigungstechnik steht häufig das zu fertigende Produkt im Mittelpunkt. Dieses bestimmt, welche Prozesse auf die eingesetzten Materialien und Zwischenprodukte angewendet und welche Ressourcen beziehungsweise Maschinen, Anlagen oder Komponenten dafür benötigt werden. Ressourcen transportieren, be- und verarbeiten dort Teilprodukte zu einem diskreten Endprodukt. Das Ergebnis der Produktion wird beispielsweise an der produzierten Stückzahl gemessen. Diese Gliederung lässt sich auf die Verfahrenstechnik übertragen mit dem Unterschied, dass es dort zumeist keine diskreten Endprodukte beziehungsweise

Abb. 2.39   Grundelemente des Dreisichten-Konzeptes

2  Grundarchitektur: das Objektmodell

85

Stückgüter gibt. Dort verarbeiten Ressourcen wie Kessel, Pumpen oder Ventile, die beispielsweise über Rohrleitungen oder Schläuche miteinander verbunden sind, Ausgangsstoffe kontinuierlich oder diskontinuierlich in sogenannten Batches zu Endprodukten. Dies können flüssige oder feste Stoffe, beispielsweise Getränke, Nahrungsmittel oder Chemikalien sein, wobei die Produktion durch chemische oder biotechnologische Prozesse und Reaktionen geprägt ist. Die Endprodukte werden dann nicht in diskreten Stückzahlen gemessen, sondern beispielsweise in Volumina oder Masse. Eine Ressource bezeichnet in AutomationML eine an der Produktion beteiligte Einrichtung. Dazu gehören Anlagen, Roboter, Werkzeuge, Maschinen, Vorrichtungen, auch Software sowie deren Zustand, mögliche Meldungen etc. Dies entspricht der Verwendung und Bezeichnung von Ressourcen in der Digitalen Fabrik. Demnach können in der hier verstandenen Weise Ressourcen sowohl die Hardwarekomponenten eines Produktionssystems sein, zum Beispiel Maschinen oder Fördertechnik, aber auch die zugehörigen Softwaresysteme wie beispielsweise Prozessvisualisierung. Innerhalb von AutomationML werden die Ressourcen durch die Anlagentopologie repräsentiert, die als Objekthierarchie mit CAEX abgebildet wird. Unter einem Produkt wird in AutomationML ein produziertes Teil-, Zwischenoder Endprodukt verstanden. Dieses kann hierarchisch aufgebaut sein. Ein Beispiel hierfür ist ein Auto mit den Teilprodukten Karosse, Räder, Getriebe, Motor, etc. Zu den Produkten gehören Test- und Prüfergebnisse, sowie Produktdaten und entsprechende Dokumentationen. In AutomationML müssen Produkte keine Stückgüter sein, auch Flüssigkeiten sind Produkte und können klassifiziert und mit Rollen semantisch hinterlegt werden. Ein Prozess repräsentiert in AutomationML einen Produktionsprozess inklusive zugehöriger Teilprozesse. Er beschreibt also Handlungen, die von Ressourcen ausgeführt werden. Dazu gehören Prozessparameter, der Prozessablauf und die Prozessplanung. Im technischen Bereich bezeichnet (Brockhaus 2007) einen Prozess als Struktur verändernden Vorgang. Auch dies entspricht der Verwendung in AutomationML. In der Fertigungstechnik wird das Endprodukt aus verschiedenen Teilprodukten gefertigt, in der Verfahrenstechnik werden beispielsweise chemische Umsetzungen an Stoffen vorgenommen. In einer ressourcenzentrierten Sicht bilden die Ressourcen die zentralen Komponenten in einem Anlagenmodell, sie führen Prozesse aus und bearbeiten hierdurch Produkte. Das Produkt kann in einer produktzentrierten Sicht ebenfalls in den Mittelpunkt gestellt werden. Dann beschreibt das Modell Produkte, die mit Hilfe von ausgeführten Prozessen auf bzw. in Ressourcen entstehen. Gruppiert man in einer prozesszentrierten Sicht das Modell um die Prozesse, benötigen die Prozesse bestimmte Ressourcen, um die gewünschten Produkte zu verarbeiten. In jedem dieser Fälle werden Repräsentationen der Produkte, der Fertigungsressourcen wie Anlagen, Arbeiter und Software sowie der Produktionsprozesse miteinander verbunden. Eine sinnvolle Zuordnung eines Prozesses zu einer Ressource Transportband wäre demnach der Prozess transportiert. Eine Presse könnte

86

R. Drath und M. Schleipen

Abb. 2.40   Beispielanlage für das PPR-Modell

beispielsweise Schrottwürfel erzeugen. Und ein Schweißprozess schweißt zum Beispiel zwei Teilprodukte zusammen. Das Konzept wird anhand der in Abb. 2.40 abgebildeten, konkreten Beispielanlage erläutert. Sie besteht aus einem einführenden und einem ausführenden Förderband TB1 und TB2, sowie einem Drehtisch DT1 und einem Roboter RB1 als Ressourcen der Anlage. Der Roboter montiert Räder an die Karossen. Sowohl die Räder als auch die Karossen ohne und mit Rädern werden als Produkte abgebildet. Als Produktionsprozesse sind in diesem Beispiel Transportieren, Drehen und Montieren vorgesehen. In AutomationML wird das Produkt-Prozess-Ressourcen-Modell unter Anwendung des Rollenkonzepts (siehe Abschnitt 2.3.4) sowie mit Relationen zwischen den Elementen (siehe Abschnitt 2.5.5) abgebildet. Den Systemelementen wird hier eine zusätzliche abstrakte semantische Bedeutung – eine Rolle – zugeordnet: beispielsweise „ich bin ein Produkt“, „ich bin eine Ressource“ oder „ich bin ein Prozess“. Die Mengen der Elemente mit den Rollen Ressource, Product und Process sind paarweise disjunkt, das bedeutet insbesondere, dass ein Element nicht gleichzeitig Ressource, Produkt und Prozess sein kann. Entsprechende Rollenklassen sind Teil der AutomationML-Standardrollenbibliothek (siehe Abb. 2.41 und Abschnitt 2.7). In Abb. 2.42 wird den Förderbändern, dem Drehtisch und dem Roboter unseres Beispiels die Rolle Resource zugeordnet. Die Karosse mit Rädern und die Karosse ohne Räder sowie die Räder selbst erhalten die Rolle Product. Die Rolle Process entspricht den Vorgängen bzw. Abläufen Transportieren, Drehen und Montieren. Alle Elemente werden als eigenständige in entsprechenden Teilbäumen abgelegt, die in Abb. 2.42 zu sehen sind.

2  Grundarchitektur: das Objektmodell

87

Abb. 2.41   StandardRollenklassen für das Drei-Sichtenkonzept

Abb. 2.42   Teilbäume des Anwendungsbeispiels

Damit eine Verbindung zwischen den Elementen modelliert werden kann, erhalten alle Elemente eine PPRConnector-Schnittstelle (siehe Abb. 2.43). Über diese Schnittstelle können mit Hilfe von ’s Verbindungen zwischen den Elementen erzeugt werden und damit semantisch die Frage beantworten, wer mit wem in Beziehung steht. Dadurch werden beispielsweise Ressourcen mit den Produkten verbunden, die sie verarbeiten können, oder Prozesse beschrieben, die auf der Ressource durchgeführt werden können. Im Anwendungsbeispiel erhält jedes der Elemente eine solche PPRConnector-Schnittstelle. Die Links des Beispiels sind in Abb. 2.44 dargestellt. Daran wird deutlich, dass die Zahl

Abb. 2.43   Standard-Schnittstellenklasse PPRConnector

88

Abb. 2.44   Verbindungen innerhalb der Beispielanlage

Abb. 2.45   Ressourcenzentrierte Sicht auf die Beispielanlage

R. Drath und M. Schleipen

2  Grundarchitektur: das Objektmodell

89

der Links schnell unübersichtlich wird: Diese kann durch Weglassen redundanter Verbindungen reduziert werden. Abbildung  2.45 zeigt die ressourcenzentrierte Sicht auf das Beispiel. Hierfür sind nur zwölf statt neunzehn Links erforderlich. Das Förderband TB1 wird durch einen Link mit dem Produkt Karosse ohne Räder1 verbunden. Ebenso der Drehtisch DT1 und das Förderband TB2. Der Roboter RB1 ist mit der Karosse ohne Räder1, der Karosse mit Rädern1 und den Rädern1 verbunden, das Förderband TB2 hingegen mit der Karosse mit Rädern1, da der Roboter die Räder auf diesem Förderband an die Karosse montiert. Der Prozess Transportieren1 hat eine Verbindung zum Förderband TB1, Transportieren2 und Transportieren3 sind mit dem Förderband TB2 verbunden. Montieren1 ist dem Roboter RB1 zugeordnet und Drehen1 dem Drehtisch DT1. Die Verbindungen zwischen den Produkten und Prozessen (gepunktete Linien in Abb. 2.45) lassen sich basierend auf den bestehenden Verbindungen herleiten. Das Modell kann beliebig rotiert und angeordnet werden, um eine produktzentrierte oder prozesszentrierte Sicht zu erhalten. Abbildung  2.46 zeigt die Umsetzung des Drei-Sichtenkonzeptes mit AutomationML. Sowohl der Ressourcenbaum, der Prozessbaum als auch der Produktbaum

Abb. 2.46   InstanceHierarchy der Beispielanlage in AutomationML

90

R. Drath und M. Schleipen

Abb. 2.47   Interne Elemente der Beispielanlage

werden in unabhängigen Hierarchien abgebildet und anschließend verlinkt. Ab­ bildung   2.46 zeigt beispielhaft die Verbindung zwischen dem Förderband TB1 und dem Prozess Transportieren1. Die konkrete Umsetzung dieser AutomationML-Struktur mit XML wird im Folgenden dargestellt. Auf oberster Ebene der Beispielanlage befinden sich die drei Grundelemente Ressourcen, Prozesse und Produkte (siehe Abb. 2.47), die mit Hilfe   

Abb. 2.48   Verknüpfungen der Beispielanlage

2  Grundarchitektur: das Objektmodell

91

von je einem abgebildet werden. Unterhalb des Knotens Ressourcen befinden sich die vier Komponenten des Beispiels: die Förderbänder, der Drehtisch und der Roboter – sie sind ebenfalls als dargestellt. Alle Prozess-, Produkt- und Ressourcenobjekte besitzen jeweils ein PPRConnector (hier nicht abgebildet) und eine Zuordnung der jeweiligen Rolle Resource, Product und Process. Um die Elemente der Beispielanlage zu verbinden, werden sie mit Hilfe von ’s auf gleicher Ebene mit den Basiselementen des Modells modelliert – Abb. 2.48 zeigt die Umsetzung in XML. Ein vollständiger Überblick über das Beispiel ist in Abb. 2.49 dargestellt.

2.10  Import und Export von AutomationML-Objekten Der Datenaustausch zwischen Planungswerkzeugen lässt sich in Export- und Importvorgänge zerlegen. Generell gibt AutomationML hierfür keine Implementierungsvorschrift vor. Allerdings legt AutomationML fest, dass jedem neuen Objekt eine eindeutige GUID zugeordnet werden muss, die über den gesamten Lebenszyklus des Objektes über alle beteiligten Werkzeuge hinweg zu erhalten ist. Typische Anwendungsfälle beim Datenaustausch sind hierbei der erste Export von Planungsdaten in ein leeres AutomationML-Dokument, der erste Import von Daten in ein leeres Objektmodell im Zielwerkzeug, der wiederholte Export von Daten, die teilweise bereits exportiert wurden, sowie der iterativ wiederholte Import von modifizierten Planungsdaten in das Zielwerkzeug. Für die Praxis wird dazu folgende Vorgehensweise vorgeschlagen (siehe Abb. 2.50). Erster Export: Es soll erstmalig eine Objektstruktur aus Tool A nach Tool B übertragen werden. Aus Sicht von Tool A bedeutet dies, dass es beim Exportieren der AutomationML-Objekte neue GUIDs erzeugen muss, da es keine GUIDs für seine Objekte vorsieht, sondern eine eigene interne Identifikationsmethodik verfolgt. Zusätzlich „merkt“ es sich mit Hilfe einer persistenten Mapping-Tabelle, welches Objekt welche GUID besitzt. Alternativ könnte der Exporter diese GUID den Objekten innerhalb des Tools A direkt zuordnen. Im Ergebnis entsteht eine AutomationML-Datei, welche die genannten drei Objekte mit je einer eindeutigen GUID abbildet. Hinweis: Für AutomationML-Klassen sind keine GUIDs erforderlich, nur für die Objektinstanzen. Erster Import: Der Importer von Tool B soll diese AutomationML-Datei importieren. Dazu wird er zunächst die zugrundeliegenden Klassen einlesen. Anschließend wir er entweder neue Klassen innerhalb von Tool B anlegen oder aber manuell bzw. mit Hilfe des Rollenkonzeptes automatisch vorhandenen Bibliothekselementen zuordnen. Für jede Objektinstanz wird in Tool B anschließend eine korrespondierende Objektinstanz unter Erzeugung seiner proprietären Identifikatoren angelegt. Auch hier ist es sinnvoll, die importierten GUIDs mit den Identifikatoren der importierten Objekte in Form einer Mapping-Tabelle oder direkt an den pro-prie-tä-ren Objekten zu speichern.

92

Abb. 2.49   XML-Quelltext der Beispielanlage

R. Drath und M. Schleipen

2  Grundarchitektur: das Objektmodell

93

Abb. 2.50   Import- und Export von AutomationML-Objekten

Wiederholter Export: Im Zuge des iterativen Engineerings werden in Tool A neue Objekte erzeugt, Objekte verändert, gelöscht oder innerhalb der Objekthierarchie umpositioniert. Der Exporter muss unter Verwendung der Mapping-Tabelle diese geänderten Objektstrukturen und Klassen exportieren, wobei bereits exportierte Objekte wieder ihre alte GUID erhalten. Neue Objekte erhalten eine neue GUID und werden als „neu“ markiert. Gelöschte Objekte werden ebenfalls exportiert, jedoch als „gelöscht“ markiert. Im Sinne eines Delta-Managements ist es zudem sinnvoll, nur Änderungen zur vorigen bereits exportierten Version zu speichern und auszutauschen. CAEX unterstützt dies. Wiederholter Import: Der Importer muss zunächst einen Delta-Vergleich zu bereits vorhandenen Objektstrukturen innerhalb von Tool B durchführen. Anhand der GUIDs kann er die Objekte zuordnen, neue und gelöschte Objekte identifizieren und geänderte Attribute oder Schnittstellen erkennen. Die Entscheidung, welche der neuen, geänderten oder gelöschten Daten in Tool B einfließen, ist vom Anwendungsfall abhängig. Vollautomatische Importe sind denkbar, allerdings wird häufig die manuelle Entscheidung des Planers erforderlich sein. Konflikte bei Daten, die sowohl in Tool A als auch in Tool B geändert wurden, lassen sich anhand des Erstellungsdatums identifizieren. In der Praxis ist auch hier die Entscheidung des Planers erforderlich. Zusammenfassend ist festzustellen, dass der iterative Austausch von Planungsdaten kein einfacher Vorgang ist, sondern durch unterschiedliche Datenmodelle, Vergabe von Rechten, Versionierung und verschiedenen Semantikwelten der beteiligten Planungswerkzeuge geprägt ist. Dies erfordert Identifikationsmechanismen, Vergleichsoperationen, Deltavisualisierungen und zum Teil manuelle Entscheidungsprozesse. AutomationML wurde als neutrales Transportmedium für vernetzte Planungsdaten unterschiedlicher Anwendungsdomänen entwickelt; die entsprechenden Datenaustauschprozesse erfordern darüber hinaus jedoch deutliche Werkzeugunterstützung. Abschnitt 6.9 fasst eine Reihe von Empfehlungen für die Einführung von AutomationML in existierende oder neue Workflows zusammen.

94

R. Drath und M. Schleipen

Literatur Abecker A, Bauer M, Hefke M (2004) MODALE – Modellbasiertes Anlagen-Engineering, kundenorientierte Dienstleistungen für Anlagensteuerung und -kontrolle. Forschungsoffensive „Software Engineering 2006“ – Eröffnungskonferenz 01–03 July 2004, Berlin Adams M, Kühn W, Stör T, Zelm M (2007) DIN EN 62264. Die neue Norm zur Interoperabilität von Produktion und Unternehmensführung – Teil 1. Oldenburg Industrieverlag, atp – Automatisierungstechnische Praxis (49) 5.2007: 52–57 AutomationML (2009) http://www.automationml.org/ Brockhaus (2007) Brockhaus – Die Enzyklopädie: In 30 Bänden. 21., neu bearbeitete Auflage. Leipzig, Mannheim: F.A. Brockhaus 2005–2007 Cutting-Decelle A F, Young R I M, Michel J J, Grangel R, Le Cardinal J, Bourey J P (2007) ISO 15531 MANDATE: A Product-Process-Resource Based Approach for Managing Modularity in Production Management. Concurrent Engineering 2007, 15: 217–235 Drath R (2006) Bäumchen wechsle Dich – Tücken beim automatischen Abgleich hierarchischer Objektstrukturen. In: Softwaretechnik – Trends, Band 26, Heft 4, S. 14–19, ISSN 0720-8928, Fachausschuss Softwaretechnik und Programmiersprachen des FB Softwaretechnik der GI, Siegen Ebel M, Okon M, Baumann M (2007) „ProduFlexil“: Flexible Produktion mit SOA-Architektur und Plug-and-Work-Mechanismus. Tagungsband zum Stuttgarter Softwaretechnik Forum (Science meets business), S. 65–74, 20–23 November 2007 Fay A, Drath R (2005) Objektorientierte Beschreibung einer Chemieanlage: Möglichkeiten und Vorteile. DECHEMA Jahrestagung, Wiesbaden, 6–8 September 2005. In: Chemie Ingenieur Technik CIT 2005, 77, No. 8, S. 1072 IEC 62264 (2003) Enterprise-control system integration IEC 62424 (2008) Festlegung für die Darstellung von Aufgaben der Prozessleittechnik in Fließbildern und für den Datenaustausch zwischen EDV-Werkzeugen zur Fließbilderstellung und CAE-Systemen Michel J J (2005) Terminology Extracted from Some Manufacturing and Modelling Related Standards. CEN/TC 310 N1119R2 Parnas D L (1972) Communications of the ACM, Vol. 15, No. 12, December 1972, pp. 1053–1058 Schleipen M, Baumann M, Okon M, Neukäufer M, Fedrowitz F, Feike M, Popova N, Nick M, Schneickert S, Wessner M (2008) Veränderungen im Konzeptions- und Konstruktionsprozess durch modular aufgebaute Anlagen mittels Ambient Intelligence-Technologien. Stuttgarter Softwaretechnik Forum (Science meets business), S. 57–67, 25–28 November 2008 Schüler J (2002) Workflow/fachübergreifende Integration/eine Utopie? In VDI-Berichte Nr. 1684, S. 7–16, VDI-Verlag Düsseldorf Soenen R, Olling G (2002) Feature Based Product Life-Cycle Modelling: IFIP TC5/WG5.2 & WG5.3 Conference on Feature Modelling and Advanced Design-for-the-Life-Cycle Systems (FEATS 2001), 12–14 June 2001, Valenciennes, France, Springer-Verlag New York Wikipedia.de (2009) Integrierte Unternehmensmodellierung. http://de.wikipedia.org/wiki/IUM. Accessed 26 January 2009 Young R I M, Gunendran A G, Cutting-Decelle A F, Gruninger M (2007) Manufacturing Knowledge Sharing in PLM: A Progression Towards the Use of Heavy Weight Ontologies. International Journal of Production Research, Vol. 45, No. 7, 1 April 2007 pp. 1505–1519

Kapitel 3

Beschreibung von Geometrie und Kinematik mit COLLADA Steffen Lips

3.1  Übersicht zu COLLADA 1.5 In der Industrie hat die 3D-Modellierung von Produkten, Anlagenkomponenten, Maschinen oder Robotern in den letzten 10 Jahren einen erheblichen Aufschwung erhalten und wird mittlerweile von einer Vielzahl von Planungswerkzeugen für unterschiedliche Industrien angeboten. Der Austausch zwischen diesen Werkzeugen ist mit offenen Datenformaten bis heute problematisch und kostenintensiv, insbesondere wenn die Kombination von Geometrie und Kinematik auftritt. Für AutomationML ist dieses Gebiet deshalb von besonderer Bedeutung. Gerade bei diesem Anwendungsfall versagen bisherige Datenformate und es müssen erhebliche Aufwände betrieben werden, um geplante Fertigungszellen von einem Werkzeug in ein anderes zu überführen. Dieses Kapitel beschreibt den von AutomationML verwendeten offenen Industriestandard COLLADA. Nach einem kurzen Überblick über die Entstehungsgeschichte werden die Inhalte und Funktionalitäten der aktuellen Version von COLLADA vorgestellt. Das Hauptaugenmerk wird dabei auf die für AutomationML relevanten Aspekte gerichtet – die Beschreibung von Geometrie und Kinematik. Der grundsätzliche Aufbau eines COLLADA-Dokuments wird hier nur am Rande behandelt. Für weitere Erläuterungen der hier nicht näher aufgeführten Funktionen sei an dieser Stelle zur weiterführenden Lektüre auf COLLADA (2008) und Arnaud u. Barnes (2006) verwiesen. Ein Blick in die Kinderzimmer verrät, was für Potentiale künftig zu erwarten sind: die heutige Generation aufwachsender Kinder wächst wie selbstverständlich mit 3D-Spielen auf. Moderne Spielekonsolen berechnen atemberaubend realitätsgetreue und erstaunlich komplexe Umweltsimulationen. Anwendungen wie Google Earth liefern detaillierte geometrische Abbildungen unserer Welt. 3DAbbildungen sind mittlerweile normaler Bestandteil der heutigen Softwarelandschaft geworden und ermöglichen die Visualisierung virtueller Welten. Da die S. Lips () NetAllied Systems GmbH, Pfannenstiel 16, 88214 Ravensburg, Deutschland e-mail: [email protected] R. Drath (Hrsg.), Datenaustausch in der Anlagenplanung mit AutomationML, DOI 10.1007/978-3-642-04674-2_3, © Springer-Verlag Berlin Heidelberg 2010

95

96

S. Lips

Computerspieleindustrie sowohl in ihrer hardware-technischen Entwicklung als auch in ihrer software-technischen Integration immer ein paar Schritte im Vergleich zu industriellen Anwendungen der Prozess- oder Fertigungsindustrie voraus war, ist es nicht verwunderlich, dass sie auf genau die gleichen Probleme stieß wie heute die Automatisierungsindustrie: eine breite Palette an verschiedenen Werkzeuge, die alle auf ihrem eigenen Datenformat operieren. Aus diesem Grund wurde 2003 auf der SIGGRAPH in San Diego das Projekt COLLADA (COLLAborative Design Activity) – damals noch unter der Schirmherrschaft von Sony Computer Entertainment – ins Leben gerufen. Ausgehend von einer Analyse aller auf dem Markt befindlichen Datenformate aus dem Bereich Digital Content Creation (DCC) sollte ein Zwischenformat definiert werden, welches eine Weitergabe der notwendigen Informationen von einem Werkzeug zum nächsten gewährleisten soll. In den folgenden drei Jahren wurden immer pünktlich zur SIGGRAPH Neuerungen vorgestellt: • 2004 wurde die Version 1.0 in Grenoble angekündigt. • 2005 wurde in Dublin die Version 1.3.1 veröffentlicht. COLLADA unterstützte nun den Austausch von Geometrien, Materialien und Animationen. • 2006 wurde in Wien die Version 1.4.1 veröffentlicht, nachdem COLLADA in die Obhut der Khronos Organisation übergeben wurde. Wesentliche Neuerungen sind die Einführung eines Physikmodells sowie die Unterstützung von Shadersprachen. Diese Version blieb für die kommenden zwei Jahre stabil und wurde zunehmend von DCC-Tools implementiert. • 2007 traten die Mitglieder des AutomationML-Konsortiums der Khronos Organisation bei. Es wurde die Arbeitsgruppe „Automation“ gegründet. • 2008 wurde auf der SIGGRAPH in Kreta die Version 1.5 angekündigt. Inhaltlich wurde COLLADA um Modelle zur Beschreibung exakter Geometrien („Boundary Representation“) und Kinematiken erweitert. • Seit 2009 sind weitere für die Automatisierung relevante Themen in Planung.

3.2  Geometriebeschreibung 3.2.1  Einführung Die Geometrie von Anlagenkomponenten ist der „sichtbarste“ Teil von AutomationML. Komplexe Szenen lassen sich aus einzelnen Geometrien zusammensetzen. Jedem AutomationML-Objekt der Anlagenhierarchie (siehe Kap. 2) kann ein COLLADA-Dokument zugeordnet werden. Ein Beispiel einer Anlagenkomponente ist z. B. ein Roboter – siehe Abb. 3.1. Die Geometriebeschreibung erfolgt mittels XML-Dokumenten, deren Aufbau in einer COLLADA-Schemadatei definiert wurde, die unter Khronos (2009)

3  Beschreibung von Geometrie und Kinematik mit COLLADA

97

Abb. 3.1   Die 3D-Geometrie einer Anlagenkomponente „Roboter“

frei verfügbar ist. Zur Beschreibung einer komplexen Komponente mit COLLADA sind viele Details zu modellieren. Der folgende Abschnitt widmet sich dem grundsätzlichen Aufbau von COLLADA-Dokumenten und erläutert die Anwendung wesentlicher COLLADA-Elemente.

3.2.2  Aufbau eines COLLADA-Dokuments Das COLLADA-Element ist das Wurzelelement eines jeden COLLADA-Dokuments (siehe Abb. 3.2). Das Pflichtattribut version ist vom Typ xs:string und hat für COLLADA 1.5 den Wert 1.5.0. Ein COLLADA-Dokument unterteilt

Abb. 3.2   Allgemeiner Aufbau einer COLLADA-Datei

98

S. Lips

sich in vier Hauptabschnitte: Den ersten Abschnitt bildet das Pflichtelement . Hier wird das Erzeugungs- und das Änderungsdatum des COLLADA-Dokuments hinterlegt. Weiterhin können Angaben zur im Dokument verwendeten Maßeinheit oder zum Herausgeber des Dokuments gemacht werden. Im zweiten Abschnitt finden sich verschiedene Bibliothekselemente. In diesen können die unterschiedlichen Daten einer darzustellenden Komponente organisiert werden; z. B. werden in bzw. alle Einzelgeometrien bzw. alle verwendeten Materialien der modellierten Komponente definiert. Das Element bildet den dritten Abschnitt. Eine Szene definiert die grafisch dargestellten Elemente. Dazu wird in der Regel eine visuelle Szene instanziiert, die die verschiedenen Geometrien hierarchisch arrangiert und in hinterlegt ist. Im Element , welches den letzten Anschnitt bildet, bietet COLLADA die Möglichkeit, zusätzliche Daten in Form von XML abzulegen.

3.2.3  Boundary Representation (BREP) BREP-Modelle bieten die Möglichkeit, Geometrien exakt zu beschreiben – gegenüber Netzmodellen, die lediglich für die Visualisierung optimiert sind und nur die Hülle beschreiben – aber nicht, was sich womöglich darin befindet. BREP-Modelle beschreiben Formen einer Dimension durch Formen der nächst niedrigeren Dimension sowie ihrer Begrenzungen. Abbildung 3.3 zeigt dies anhand einer Hülse. Die gegebene Form ist eine Begrenzung des dreidimensionalen Raums. Sie beschreibt einen Solid oder – vereinfacht gesprochen – sie beschreibt, wo sich Materie befindet und wo nicht. Innerhalb der 3-dimensionalen Hülse gibt es mehrere Begrenzungen des zweidimensionalen Raums. Der Solid wird durch zwei Zylinder (innen und außen) und zwei Ebenen (oben und unten) begrenzt. Beide Ebenen werden wiederum durch zwei Kreise, also eindimensionale Elemente begrenzt. Wie zu erkennen ist, sind zwei unterschiedliche Klassen von Elementen notwendig. Die eine Klasse beschreibt die reine Geometrie – z. B. Oberflächen wie Zylinderflächen oder Linien wie Geraden oder Kreise – und die andere die Art der Begrenzung – z. B. Flächen (Faces) und Kanten (Edges). Auf diese Weise ist es möglich, Formen exakt zu beschreiben – Drahtgitternetze bieten beispielsweise nur

Abb. 3.3   BREP Modell einer Hülse

3  Beschreibung von Geometrie und Kinematik mit COLLADA Tab. 3.1   Auflistung der geometrischen Elemente

99

Element

Beschreibung

Punkt Kurve Oberfläche

Geometrisches Element der Dimension 0 Geometrisches Element der Dimension 1 Geometrisches Element der Dimension 2

eine Näherungsbeschreibung. Hochwertige Präzision ist eine Voraussetzung für den industriellen Einsatz. COLLADA 1.5 bietet ein vollständiges Modell zur Beschreibung von Geometrien mittels BREP. Obwohl sich jeder BREP-Kernel der verschieden CAD-Produkte zu den anderen leicht unterscheidet, ist eine verlustfreie Transformation nach und von COLLADA – und somit auch untereinander – möglich. Die geometrischen Grundelemente sind in Tab. 3.1 aufgeführt. Die begrenzenden Elemente definieren die Grenzen der geometrischen Elemente und sind in Tab. 3.2 aufgelistet. Wie zu erkennen ist, gibt es zu den begrenzenden Elementen Vertex, Edge und Face eine geometrische Entsprechung: Punkt, Kurve und Oberfläche. Die begrenzenden Elemente einer Klasse bilden zudem auch die Basis für die Elemente der nächsthöheren Klasse. Eine Edge wird folglich durch Vertizen (Punkte) begrenzt. Ein Wire wird durch Edges begrenzt etc. Begrenzende Elemente eines Typs bestehen folglich immer und ausschließlich aus begrenzenden Elementen des vorangegangen Typs, d. h. Edges bestehen immer aus Vertizen. Wires werden immer aus Edges zusammengesetzt, aus Wires werden immer Faces usw. Jedes begrenzende Element hat eine Richtung (Basisorientierung), das durch die mathematische Definition der Geometrie oder durch die Reihenfolge des Zusammenschlusses definiert ist. Diese kann für den Zusammenbau eines begrenzenden Elements der nächsthöheren Klasse entweder beibehalten oder umgedreht (reversiert) werden. Dies ist z. B. notwendig, wenn mehrere Edges (Kurven) zu einer Wire zusammengeschlossen werden. Im folgenden Beispiel sind die Edges E1, E2 und E3 durch die Vertizen (Punkte) V1, V2 und V3 begrenzt. Damit die 3 Edges zu einer Wire zusammengeschlossen werden können, müssen die 3 Edges gleichgerichtet werden. Dazu muss entweder die Edge E3 oder wie in Abb. 3.4 dargestellt die Edges E1 und E2 reversiert werden. Tab. 3.2   Auflistung der begrenzenden Elemente in der Reihenfolge ihrer Komplexität

Element

Beschreibung

Vertex Edge Wire

Begrenzungselement der Dimension 0 (Punkt) Begrenzungselement der Dimension 1 (Kante) Zusammenschluss von zueinander angrenzenden Edges Begrenzungselement der Dimension 2 (Oberfläche) Zusammenschluss von zueinander angrenzenden Faces Begrenzungselement der Dimension 3

Face Shell Solid

100

S. Lips

Abb. 3.4   Orientierung von Edges

V2

E1: V1 -> V2 E 2: V2 -> V3 y

E 3: V1 -> V3

V1

x

V3

Mit diesen Mitteln kann prinzipiell jede noch so komplexe Geometrie beschrieben werden. In den meisten CAD Formaten, die BREP Modelle abbilden können, werden jedoch zusätzlich häufig parametrische Informationen gespeichert. Parametrische Informationen sind begrenzende Informationen im parametrischen Raum des betrachteten Elements. So kann eine Edge, die durch zwei Vertizen begrenzt wird, zusätzlich auch noch durch zwei Parameter im Raum der korrespondierenden Kurve beschrieben werden. Eine Edge, die durch eine Gerade der Form (x|y|z) = λ(1|1|0) beschrieben ist, sei beispielsweise durch die Vertizen V1(0|0|0) und V2(2|2|0) begrenzt. Die beiden Vertizen sind im parametrischen Raum der Kurve durch die Parameter λ = 0 und λ = 2 definiert, d. h. die Edge kann auch über diese beiden Zahlenwerte beschreiben werden. Analog dazu können Faces durch 2D-Kurven in deren parametrischen Raum beschrieben werden. Die prinzipielle Struktur einer BREP Geometrie in COLLADA ist in Abb. 3.5 dargestellt. BREP Modelle werden durch das COLLADA-Element

Abb. 3.5   Prinzipieller Aufbau des Elements

3  Beschreibung von Geometrie und Kinematik mit COLLADA Tab. 3.3   Liste aller unterstützten Kurvenbeschreibungen

101

Element

Beschreibung





Gerade Kreis/Kreisbogen Ellipse/Ellipsenbogen Parabel Hyperbel Non-Uniform Rational B-Spline

eingeleitet. Die Elemente , und dienen als Container für die geometrischen Elemente, die in dem BREP Modell verwendet werden können. Das sind neben den Kurven und Oberflächen im 3DRaum auch die optionalen Kurven im 2D-Raum der betrachteten Oberfläche. Eine Liste der unterstützen Kurven bzw. Oberflächen in COLLADA ist in Tab. 3.3 bzw. 3.4 zu finden. In den folgenden Elementen sind alle Daten, auf die die begrenzenden Elemente verweisen, logisch zusammengefasst. Das sind neben den „scoped identifiern“ (SID) der zuvor beschriebenen Kurven und Oberflächen, die Koordinaten der Vertizenpunkte und die möglichen Orientierungen. Nun sind alle Informationen, die zum Erzeugen einer BREP Geometrie notwendig sind, vorhanden. Beginnend mit den Vertizen kann das Modell aufgebaut werden. Diese werden mit dem COLLADA-Element erzeugt. Durch das Element verweist es auf die zuvor definierten 3D Punkte. Die Indizierung der Vertizen ist durch die Reihenfolge der Punkte festgelegt. Der erste Vertex hat den Index 0 und ist der erste Punkt des referenzierten Elements. Das Element besitzt vier Elemente und ein

Element. Das Attribut offset der Elemente gibt an, wie die Indexliste des

Elements zu interpretieren ist. Wie in Abb. 3.6 dargestellt, bestimmen in diesem Beispiel jeweils 4 Indizes eine Edge. Der erste Index gibt an, welche geometrische Repräsentation diese Edge hat. Die zwei folgenden Indizes geben die Grenzen dieser Edge durch einen Start- und einen Endvertex an. Der letzte Index referenziert ein Parameterpaar, welches die Begrenzung der Edge im parametrischen Raum der Kurve bestimmt. Das Element besitzt zwei Elemente, ein und ein

Element. Das Element gibt an, aus wie vielen Edges die Tab. 3.4   Liste aller unterstützen Oberflächenbeschreibungen

Element

Beschreibung





Ebene Zylinder Kegel Torus Kugel Rotations- und Extrusionsflächen Non-Uniform Rational B-Spline Flächen

102

S. Lips

Abb. 3.6   Struktur der Begrenzungselemente

jeweilige Wire besteht. Im angegebenen Beispiel besteht die erste Wire aus vier Edges, d. h. die ersten acht Indizes des Elements

bilden diese Wire, wobei immer ein Paar an Indizes eine Edge referenziert und deren Orientierung angibt. Alle weiteren Elemente funktionieren analog. Ein komplettes Beispiel mit detaillierten Erklärungen ist in Abschnitt 3.4 beschrieben.

3  Beschreibung von Geometrie und Kinematik mit COLLADA

103

3.2.4  Tessellierte Geometrien Um Geometrien visualisieren zu können, müssen sie zuvor „tesselliert“ werden, d. h. sie werden in ein Format überführt, das für Grafikkarten geeignet ist. Diese Datenaufbereitung ist durchaus zeitaufwändig. Daher speichern die meisten Datenformate im CAD-Umfeld das Ergebnis einer Tessellierung mit ab. Ändert sich eine Geometrie, so wird nur der entsprechende Teil neu tesselliert. Abbildung 3.7 zeigt eine tesselierte Darstellung eines Geometrieobjektes „Hülse“. COLLADA stellt für die Tessellierung ein umfangreiches Set an polygonbasierten Geometriebeschreibungen zur Verfügung. Tessellierte Geometrien werden durch das Element eingeleitet. Es folgt eine ähnliche Aufteilung der Daten wie im BREP Modell. Zuerst werden alle Quelldaten, die zur Beschreibung notwendig sind, in Containern bereitgestellt, die dann durch Grafikprimitiven referenziert werden. Diese Quelldaten sind im wesentlichen Vertexdaten – also Punkte bzw. 3D-Positionen. Weitere Quelldaten können auch Normalenvektoren, Texturkoordinaten, Farbkoordinaten etc. sein. In Abb. 3.8 ist der grundsätzliche Aufbau einer polygon-basierten Geometrie in COLLADA dargestellt. Das Element (siehe Abb. 3.9) definiert einzelne Liniensegmente durch einen Start- und einen Endpunkt. Ein Element kann dabei mehr als eine Linie beinhalten. Immer zwei Vertizen modellieren eine individuelle Linie. Die Anzahl der Linien ist im Attribut count gespeichert. Zusammenhängende Linien können durch das Element kompakter als mit beschrieben werden (siehe Abb. 3.10). Dabei wird das erste Segment eines Strips durch die ersten zwei Vertizen definiert. Jeder weitere Vertex definiert eine weiteres Liniensegment, dessen Endpunkt dieser Vertex selbst und dessen Startpunkt der Endpunkt des vorangegangen Segments ist. Das Attribut count gibt die Anzahl der definierten Strips an. Ein Polygon ist durch seine Kanten definiert und im Wesentlichen ein geschlossener Linestrip, siehe Abb. 3.11. Polygone können sehr komplex sein und werden daher von vielen Visualisierungswerkzeuge nur bedingt oder gar nicht unterstützt, da es aus mehr als 3 Vertizen bestehen kann, und dadurch folgende Probleme auftreten können:

Abb. 3.7   Tessellierte Darstellung einer Hülse

104

• Das Polygon ist nicht planar. • Das Polygon ist konkav. • Das Polygon schneidet sich selbst. • Das Polygon definiert Löcher. Das Attribut count gibt die Anzahl der Polygone an.

Abb. 3.8   Aufbau einer polygon-basierten Geometrie in COLLADA

S. Lips

3  Beschreibung von Geometrie und Kinematik mit COLLADA V5

V2

V1

105

V3 V4 V6

Abb. 3.9   Das Element

V2

V4

V1 V3 V5

Abb. 3.10   Das Element

In einer komprimierteren Form werden Polygone durch das Element beschrieben, siehe Abb. 3.12. Durch das Element wird festgelegt, aus wie vielen Vertizen ein Polygon besteht. Das Attribut count gibt an wie viele Polygone insgesamt beschrieben sind. Die einfachste Form eines Polygons ist ein Dreieck. Diese Form eines Polygons ist immer planar, konvex und kann sich selbst nicht schneiden. Dreiecke werden durch das Element beschrieben, siehe Abb. 3.13. Das Attribut count gibt dabei die Anzahl der einzelnen Dreiecke an. Ein Dreieck-Strip ist ein Set von Dreiecken, die sich je eine Kante teilen. Es wird durch das Element beschrieben, siehe Abb. 3.14. Das erste Dreieck ist durch die ersten drei Vertizen definiert. Die Kante, die durch die beiden letzten Vertizen definiert wird, ist die erste Kante des nächsten Dreiecks, das durch den folgenden Vertex komplettiert wird.

106

S. Lips V1 V5

V6

V8

V2

V7 V4

V3

Abb. 3.11   Das Element mit einem Loch V1 V5 V2 V4

V3

Abb. 3.12   Das Element

V2

V1

V4 V3

V6 V5

Abb. 3.13   Das Element

3  Beschreibung von Geometrie und Kinematik mit COLLADA

107

V2

V1

V4 V3

V6 V5

Abb. 3.14   Das Element

V2

V1

V3

V5

V4

Abb. 3.15   Das Element

Eine Variation von Dreieck-Strips bildet das Dreieck-Fan. Auch hier wird das erste Dreieck durch die ersten drei Vertizen gebildet. Im Gegensatz zum DreieckStrip ist die erste Kante des Folgedreiecks jene, die durch den ersten und letzen Vertex des vorherigen Dreiecks gebildet wurde. Somit besitzen alle Dreiecke eines Dreieck-Fans einen gemeinsamen Vertex. Dreieck-Fans werden durch das Element beschrieben, siehe Abb. 3.15.

3.2.5  Modellieren von Produktbäumen In den vorangegangen Abschnitten wurde beschrieben, wie Geometrien erstellt werden. Eine vollständige Komponente (z. B. ein Roboter) würde allerdings nicht mit einer einzigen Geometrie beschreiben werden, sondern durch mehrere. Dies hat den Vorteil, dass die Einzelkomponenten in der Visualisierung ein- oder ausgeblendet oder für andere Komponenten wiederverwendet werden können, weil sie zum Beispiel in verschiedenen Bauarten der Komponente gleich sind. Es entsteht

108 Tab. 3.5   Liste der Transformationselemente

S. Lips Element

Beschreibung





4 × 4 Transformation Drehung um eine Achse Verschiebung entlang eines Vektors Skalierungsvektor Scherung

dadurch ein sogenannter Produktbaum, der Einzelgeometrien und Teilprodukte zu einem Gesamtprodukt zusammenfügt. In COLLADA wird ein solcher Produktbaum durch eine Hierarchie von Elementen beschrieben. Jedes Element kann als Kinder wiederum Elemente besitzen. Zusätzlich kann die geometrische Position eines solchen Elementes durch verschiedene Transformationen relativ zum Vater-Element festgelegt werden. Eine Liste der möglichen Transformationselemente ist in Tab. 3.5 dargestellt. Jede dieser Transformationen kann in willkürlicher Reihenfolge beliebig oft verwendet werden. Nach der Positionierung erfolgt dann die Instanziierung der gewünschten Geometrie. Dies geschieht durch das Element , welches über das Attribut url auf die zu instanziierende Geometrie verweist. Abbildung 3.16 und 3.17 zeigen eine Roboterkomponente und deren Produktbaum in der XML-Darstellung von COLLADA.

3.2.6  Modellieren von Materialien Materialien bestimmen das Erscheinungsbild einer Geometrie. Eine Geometrie kann mit verschiedenen Farben oder Texturen versehen werden. Die Art der Materialien wird allerdings nicht in der Geometriedefinition abgelegt, da sie sonst fest mit der Geometrie verbunden wäre. Das würde dazu führen, dass eine Geometrie mit einem anderen Material noch einmal von Grund auf beschrieben werden müsste. Daher werden in COLLADA Materialien erst dann mit einer Geometrie verknüpft, wenn diese instanziiert wird.

Abb. 3.16   Geometrie einer Komponente „KR150-1“

3  Beschreibung von Geometrie und Kinematik mit COLLADA

Abb. 3.17   Visuelle Szene der Komponente „Roboter“

109

110

S. Lips

Abb. 3.18   Definition eines Effekts

Um ein Material zu definieren, muss zunächst ein sogenannter Effekt beschrieben werden. Effekte werden durch das COLLADA-Element definiert, welche das Beleuchtungsverhalten einer Oberfläche wie z. B. Reflexion oder Transparenz abbildet. Eine einfache rote Oberfläche wird z. B. wie in Abb. 3.18 dargestellt beschrieben: Dieser Effekt kann nun von einer Materialdefinition verwendet werden. Dazu wird der Effekt wie in Abb. 3.19 dargestellt instanziiert. Nachdem das Material definiert ist, kann es von einer Geometrie verwendet werden. Dies erfolgt durch das Element . Hier wird die Materialdefinition an einen bestimmten Materialsymbolnamen der instanziierten Geometrie „gebunden“. Diese Symbolnamen sind in der Geometriedefinition durch die Attribute material der Grafikprimitiven (z. B. ) festgelegt (siehe Abb. 3.20).

Abb. 3.19   Definition eines Materials

Abb. 3.20   Binden eines Materials

3  Beschreibung von Geometrie und Kinematik mit COLLADA

111

Abb. 3.21   Verschiedene Detaillierungsgrade bzw. „Level of Detail“

3.2.7  Modellieren unterschiedlicher Detaillierungsgrade COLLADA 1.5 bietet die Möglichkeit, zu einer Komponente oder Teilkomponente verschiedene Detailstufen abzulegen (siehe Abb. 3.21). Über das Attribut proxy des COLLADA-Elements kann eine Anwendung durch die verschiedenen „Level of Detail“ durchlaufen und die für die entsprechende Aufgabe benötigte Darstellung verwenden. Die Aufteilung der Modelle unterschiedlicher Detaillierungsgrade in mehrere COLLADA-Dokumente ist möglich und vorteilhaft. Besitzt die Anwendung z. B. einen BREP-Modeller, so sucht sie sich die BREP Repräsentation des zu bearbeitenden Objekts. Will sie hingegen nur einige Platzhalter platzieren, sucht sie nach einer Meshbeschreibung, die – im einfachsten Fall – nur ein umgebenden Bounding Box darstellt.

3.3  Kinematikbeschreibung 3.3.1  Anforderung an ein Kinematikbeschreibung Die Kinematik von Anlagenkomponenten umfasst die physikalischen Wirkbeziehungen zwischen ihren Bestandteilen, die beispielsweise durch Gelenke gegeben ist. Bei der Entwicklung einer generischen Beschreibung von kinematischen Modellen mit COLLADA wurde darauf geachtet, dass sich das Datenmodell zukünftig weiterentwickeln lässt. Oberstes Gebot war die strikte Trennung von Geometrie und

112

S. Lips

Kinematik, da die Aufgabe eines kinematischen Modells die Bereitstellung aller notwendigen Informationen ist, die eine Applikation benötigt, um ein invers-kinematisches Problem zu lösen. Weiterhin sollten sich beide Zielgruppen von COLLADA – die Automatisierungsindustrie und die Spieleindustrie – im Design wiederfinden. D. h. es muss möglich sein, dass eine einfache Kinematik auch einfach modelliert werden kann, ohne es mit den notwendigen Informationen, die z. B. ein industrieller Roboterprogrammierer benötigt, zu überladen. Die folgenden Kapitel beleuchten alle Aspekte, die mit der aktuellen Version von COLLADA abbildbar sind.

3.3.2  Beschreibung von Gelenken COLLADA 1.5 stellt zwei Gelenkprimitiva zur Verfügung: Das rotatorische Basisgelenk definiert den Freiheitsgrad als Drehung um eine Achse. Das translatorische Basisgelenk definiert den Freiheitsgrad als Verschiebung entlang einer Achse. Tab. 3.6   Liste der gängigen Gelenkarten, Abbildungen aus MW (2009)

3  Beschreibung von Geometrie und Kinematik mit COLLADA

113

Abb. 3.22   Definition von Gelenken

Aus diesen zwei Basisgelenken lassen sich alle erdenklichen Gelenkarten ableiten. Tabelle 3.6 gibt einen Überblick über die gängigen Gelenkarten. Die Definition eines Gelenks erfolgt durch das COLLADA-Element . Dieses kann beliebig viele Elemente vom Typ oder , welches die Basisgelenke sind, beinhalten. Ein Basisgelenk selbst besteht aus dem Element , welches die Achse des Freiheitsgrads definiert. Optional kann der Wertebereich, in dem sich ein Basisgelenk bewegen darf, eingeschränkt werden. Die Einheit des Wertebereichs richtet sich nach dem Typ des Gelenks und ist für rotatorische Gelenke immer Grad (°) und für translatorische Gelenke immer die Einheit, die für die Komponente oder das Dokument festgelegt wurde (z. B. millimeter). Die Abb. 3.22 zeigt die Definition eines prismatischen Gelenks und die eines Universalgelenks.

3.3.3  Kinematische Modelle Kinematische Modelle stellen die Basis für die Berechnung und das Lösen von kinematischen Problemen dar – wie z. B. die Bahnplanung eines Schweißprozesses. Kinematische Modelle oder kinematische Ketten sind Systeme aus starren Körpern, sogenannten Links, die durch Gelenke verbunden sind. Kinematische Modelle werden durch das COLLADA-Element definiert. Zunächst werden alle Gelenke aufgelistet, die durch dieses kinematische Modell verwendet werden. Dabei können entweder Gelenke, die

114

S. Lips

40

40

Abb. 3.23   Beispiel eines einfachen kinematischen Modells

zuvor in definiert wurden, durch das Element instanziiert werden. Ebenso ist die Definition neuer Gelenke möglich. Danach wird die kinematische Kette definiert. Sie beginnt immer mit dem Element . An diesen Link können durch das Element weitere Links geknüpft werden. Durch die Transformationselemente und kann der nachfolgende Link entsprechend positioniert werden. Die folgende Abb. 3.23 zeigt, wie eine einfache 1-Gelenk Kinematik aufgebaut ist. Wie am Beispiel zu erkennen ist, wird das Gelenk durch das COLLADA-Element entlang des Koordinatensystems des übergeordneten Links positioniert. Eine kinematische Kette ist typischerweise eine Aneinanderreihung von Links und Gelenken. Das Auftreten von Zyklen ist durchaus möglich und sogar üblich. Diese Zyklen – oder auch „closed loops“ – werden in COLLADA durch die Elemente und abgebildet. Ein solcher Zyklus ist in Abb. 3.24 abgebildet. Wie zu erkennen ist, ist eine „Teilkette“ durch die Links l1 und l2 definiert und eine andere durch die Links l1, l3, l4 und l2. Beide Ketten sind unabhängig voneinander, bis sie durch das Gelenk j4 zusammengeführt werden. Die eine Kette verwendet dieses Gelenk durch das Element , die andere durch das Element . Beide Elemente müssen in einem gültigen kinematischen Modell immer als Paar auftreten. Allerdings ist die Reihenfolge der Verwendung unbedeutsam, d. h. die Elemente dürften vertauscht sein.

3  Beschreibung von Geometrie und Kinematik mit COLLADA j4

j2

l2 l4

j1 l1

115

30

l3 j3

30

40 40

Abb. 3.24   Ein einfacher Zyklus

3.3.4  Abbildung von Formeln Wie in den beiden vorangegangenen Kapiteln gezeigt, können durch die Verwendung der COLLADA-Elemente , , und beliebig komplexe Kinematiken aufgebaut werden. Allerdings sind Berechnungen mit Kinematiken, die Zyklen enthalten, aufwendig und werden folglich nicht durch alle Werkzeuge unterstützt. Trotzdem scheinen solche Werkzeuge diese Art von Kinematiken dennoch lösen zu können. Um dies zu bewerkstelligen, bedienen sie sich eines Tricks: Die ursprüngliche

116

S. Lips

kinematische Kette mit einem Zyklus wird in zwei separate Ketten aufgeteilt. Damit sich deren Gesamtkinematik genauso verhält wie die ursprüngliche, werden einige Gelenke durch eine vorgegebene Formel berechnet. Die zweite Teilkette ist durch Formeln mit der ersten Kette verbunden und liefert so bei der Simulation oder der Berechnung der Inversen das gleiche Ergebnis wie die Kinematik mit Zyklus. Für das obige Beispiel müsste folglich das Gelenk j2 mit einer Formel berechnet werden oder die Gelenke j1, j3 und j4. Da es sich hierbei um ein einfaches Parallelogramm handelt, lassen sich folgende Formeln für die Gelenke j1, j3 und j4 angeben: Formel 3.1    Formeln für ein Parallelogramm

j1( j2 ) = j2 j3( j2 ) = −j2 j4( j2 ) = −j2

COLLADA 1.5 verwendet zur Abbildung von Formeln den W3C Standard MathML (W3C 2003). Durch das COLLADA-Element wird eine Formel definiert. Als erstes wird durch das Element festgelegt, wohin das Ergebnis der Berechnung geschrieben werden soll. Danach folgt – eingebettet in das Element – die MathML-Beschreibung der zu verwendenden Formel. Abbildung 3.25 zeigt beispielhaft einen entsprechenden COLLADA Quelltext. Häufig verwenden Formeln vordefinierte Funktionen. Ein Beispiel dafür sind z. B. die trigonometrischen Funktionen wie SASA (Side-Angle-Side-Angle) oder SASS (Side-Angle-Side-Side). Diese wiederum verwenden die Funktion atan2, die nicht zum bekannten Funktionssatz von MathML gehört. Damit diese Funktionen nicht für jede Formel ausmultipliziert werden müssen, können sie in einer entsprechenden Bibliothek vorab definiert werden. Ein importierendes System kann dann, falls es diese Funktion selbst implementiert, darauf verzichten, diese einzulesen. Ein kleines Beispiel für eine solche Vorabdefinition ist in Abb. 3.26 gegeben. Hier wird eine einfache Funktion beschrieben, die zwei Zahlen miteinander addiert. Die Übergabeparameter werden jeweils durch das Element festgelegt und können dann mit ihrem symbolischen Namen verwendet werden. Der Codeausschnitt in Abb. 3.27 zeigt, wie diese Funktion innerhalb einer Formel verwendet werden kann.

3.3.5  Artikulierte Systeme Kinematische Modelle beschreiben lediglich die Freiheitsgrade eines Systems. Damit es für ein Simulationssystem tatsächlich nutzbar ist, muss es um weitere Informationen angereichert werden. Dabei unterscheidet COLLADA 1.5 die Anreicherung rein kinematischer Aspekte, die die Grundlage für das Lösen eines inversen Problems bilden, und rein dynamischer Aspekte, die das Verhalten der Kinematik beim Abfahren einer Bahn bestimmen. Um ein kinematisches Modell mit solchen Informationen anzureichern, werden „artikulierte Systeme“ verwendet.

3  Beschreibung von Geometrie und Kinematik mit COLLADA

Abb. 3.25   Kinematische Modell mit Formeln

117

118

S. Lips

Abb. 3.26   Vorabdefinierte Funktion

Ein artikuliertes System wird durch COLLADA-Element definiert. Es folgt die Festlegung, welche Aspekte des Modells beschrieben werden sollen. Dies geschieht durch das Element bzw. durch das Element . Eine Auflistung der kinematischen bzw. dynamischen Eigenschaften, die festgelegt werden können, ist in Tab. 3.7 bzw. 3.8 zu finden. Um kinematische Aspekte zu beschreiben, wird zunächst im Element ein Model instanziiert. Innerhalb der Instanz werden die Parameter des Modells durch das Element für den weiteren Gebrauch veröffentlicht. Diese Elemente sind: • die Referenz auf das instanziierte Modell, • die Referenzen auf die Gelenke des Modells, sowie • die Festlegung eines Achswerts des entsprechenden Gelenks. Im Element werden die kinematischen Aspekte eines Gelenks festgelegt, z. B. die Aktivität oder der Index im Gelenkvektor. Die Eigenschaften, die hier definiert werden, lassen sich auch wieder durch einen Parameter veröffentlichen. In Abb. 3.28 ist die Definition eines kinematischen Systems dargestellt, die auf einem kinematischen Modell mit zwei Gelenken basiert. Die Eigenschaft locked des zweiten Gelenks ist durch einen Parameter veröffentlicht.

Abb. 3.27   Verwendung einer Funktion

3  Beschreibung von Geometrie und Kinematik mit COLLADA

119

Tab. 3.7   Kinematische Aspekte Eigenschaft

Element

Beschreibung

Gelenkaktivität

Gelenksperren

Softlimits

Indizierung

Koordinatensysteme



In einem kinematischen System kann ein Gelenk aktiv oder passiv sein. Alle aktiven Gelenke müssen bei einer kinematischen Berechnung berücksichtigt werden Passive Gelenke werden in einem zweiten Schritt berechnet, da sie nicht für die Lösung des Problems maßgebend sind Es ist möglich, dass in einem kinematischen System für bestimmte Aufgaben einige Gelenke gesperrt werden. Bei einer Berechnung werden für diese Gelenke die entsprechenden Freiheitsgrade nicht berücksichtigt Bei der Definition von Gelenken konnten bereits deren Grenzen festgelegt werden. Diese Grenzen sind hart, d. h. sie können rein physikalisch nicht überwunden werden. In einem kinematischen System können zusätzlich zu diesen „harten“ Limits auch „weiche“ definiert werden. Diese sind sinnvoll um z. B. das Kollidieren von zwei Links miteinander von vornherein zu verhindern Jedes Gelenk in einem kinematischen System hat eine korrespondierende Position im Gleichungs­system des kinematischen Problems. Durch einen Index wird diese Position im sog. Gelenkvektor festgelegt Es können verschiedene Koordinatensysteme fe­s­t­gelegt werden, die für die Berechnung eines Problems notwendig sind. Im einzelnen sind dies folgende: – das Ursprungskoordinatensystem legt den Ur­ sprung für alle Berechnungen des kinematischen Systems fest. Dieses Koordinatensystem muss definiert werden – da Tippkoordinatensystem legt das K­o­or­dinatensystem am Ende der kinematischen Kette fest. Dieses Koordinatensystem muss definiert werden – das Objektkoordinatensystem kann dazu ver­wendet werden um einen Raum für ein Werkstück fest zu legen – das Toolkoordinatensystem kann dazu verwendet werden um den Raum eines Werkzeugs, das von dem kinematischen System verwendet wird, festzulegen

Das Element ist ähnlich aufgebaut wie das Element . Auch hier wird zunächst eine Instanz erzeugt, allerdings nicht die eines kinematischen Modells, sondern die eines artikulierten Systems. Innerhalb dieser Instanz können nun deren Parameter benutzt werden, die zuvor – wie weiter oben

120

S. Lips

Tab. 3.8   Dynamische Aspekte Eigenschaft

Element

Beschreibung

Geschwindigkeit Beschleunigung

Ruck

Für jedes Gelenk und für den Endeffektor kann eine Ge­ schwindigkeit festgelegt werden, die nicht überschritten werden darf Für jedes Gelenk und für den Endeffektor kann eine Beschleunigung festgelegt werden, die nicht überschritten werden darf. Dabei wird unterschieden ob es sich um eine positive oder um eine negative Beschleunigung handelt

Für jedes Gelenk und für den Endeffektor kann ein Ruck festgelegt werden, der nicht überschritten werden darf

Abb. 3.28   Artikuliertes System mit kinematischen Aspekten

beschrieben – veröffentlicht wurden. Es gibt zwei Möglichkeiten, einen Parameter zu verwenden. Zum einen kann mit dem Element ein Wert festgelegt werden. Oder aber der Parameter wird durch das Element wieder veröffentlicht. Auf diese Weise kann ein Parameter, der ursprünglich in einem

3  Beschreibung von Geometrie und Kinematik mit COLLADA

121

Abb. 3.29   Artikuliertes System mit dynamischen Aspekten

kinematischen Modell festgelegt wurde, durch eine ganze Kette von artikulierten Systemen weitergereicht werden, bis er mit einem konkreten Wert belegt wird. Und auch hier können über das Element dem entsprechenden Gelenk weitere Aspekte – in diesem Fall dynamische – hinzugefügt werden. Abbildung 3.29 zeigt, wie das oben erzeugte kinematische System zu einem dynamischen System erweitert wird. Für die Zukunft sind weitere Arten von artikulierten Systemen denkbar. Humanoide Roboter benötigen beispielsweise ein System, um das Balanceverhalten zu beschreiben, damit der Roboter bei seinen Bewegungen nicht umfällt. Das vorgegebene Design in COLLADA ermöglicht die Definition eines neuen Typs von artikulierten Systemen, der sich nahtlos einfügen könnte.

3.3.6  Vereinen von Kinematik und Geometrie In den vorangegangenen Abschnitten dieses Kapitels wurde gezeigt, wie ein kinematisches System erstellt und wie es um verschiedene Aspekte erweitert werden kann.

122

S. Lips

Abb. 3.30   Kinematische Szene

Nun soll ein Simulationswerkzeug seine Berechnungen und Ergebnisse auch visualisieren können, d. h. es soll die Bewegung einer Komponente visuell darstellen können. Folglich müssen die Ergebnisse der Kinematik in die Geometrie fließen. Zu diesem Zweck muss zunächst – analog zu einer visuellen Szene – eine kinematische Szene erstellt werden. Dies geschieht in der entsprechenden Bibliothek durch das COLLADA-Element . Innerhalb dieser Szene können beliebig viele kinematische Modelle oder artikulierte Systeme instanziiert werden. Über den bereits im vorangegangen Kapitel beschriebenen Mechanismus der Parametrisierung können auch hier wieder Parameter an die kinematische Szene vererbt werden. Ein Beispiel einer kinematischen Szene ist in Abb. 3.30 dargestellt. Hier wurde das bereits weiter oben definierte dynamische System instanziiert. In dieser Instanz werden die vererbten Parameter wieder veröffentlicht – bis auf einen. Der Parameter, der die Sperrung des zweiten Gelenks definiert, wird hier durch das Element mit einem neuen Wert überschrieben. D. h. in dieser kinematischen Szene ist das zweite Gelenk des ursprünglichen kinematischen Modells gesperrt. Wie in Abschnitt 3.2.2 beschrieben wurde, definiert das Element das, was dem Anwender später auf dem Display visualisiert wird. Und genau hier wird die Kombination zwischen der visuellen und der kinematischen Szene hergestellt. Beide Szenen müssen zunächst durch die Elemente und instanziiert werden. Innerhalb der Instanz der kinematischen Szene wird dann als erstes festgelegt, welches kinematische Modell an welche Komponente im Produktbaum gekoppelt wird. Dies erfolgt

3  Beschreibung von Geometrie und Kinematik mit COLLADA

123

Abb. 3.31   Koppelung zwischen Kinematik und Geometrie

durch das COLLADA-Element . Danach werden die Gelenke des kinematischen Modells an die entsprechenden Transformationen im Produktbaum gekoppelt. Dies geschieht durch das Element , dessen Attribut node auf das Transformationselement in der visuellen Szene referenziert, welches durch dieses Gelenk bewegt werden soll. Abbildung 3.31 zeigt die Verbindung der oben beschriebenen kinematischen Szene an eine Geometrie. Im Element referenziert das Gelenk des kinematischen Modells und das Element definiert den Gelenkwert, den es in dieser Szene haben soll.

3.3.7  Zusammengesetzte Kinematiken Kinematiken lassen sich auf verschiedene Weisen zusammensetzen – z. B. wenn eine Klebepistole, die eine einfache Kinematik darstellt, von einem Roboter verwendet werden soll. Die Klebepistole hat auf die Kinematik nur einen geringen Einfluss, da sie lediglich den „Tool center point“ (TCP) des Roboters verändert. Einen Roboter auf einer linearen Fahrachse zu platzieren ist eine andere Form einer zusammengesetzten Kinematik. Der Unterschied zwischen diesen beiden Formen der Zusammensetzung ist folgender: Im ersten Fall wird ein Werkzeug lediglich platziert. Fährt der Roboter eine Prozessbahn ab, so wird dieser ebenso wie das Werkzeug durch je einen Controller gesteuert. Die Kinematik des Werkzeugs hat keinen entscheidenden Einfluss auf die Art, wie der Roboter die Bahn abfährt. Diese Art der Zusammensetzung entspricht einem „Attachment“ und wird in AutomationML

124

S. Lips

Abb. 3.32   Artikuliertes System einer kombinierten Kinematik

durch ein COLLADAInterface im Dachformat CAEX beschrieben, womit sich der folgende Abschnitt 3.3.8 befasst. Die zweite beschriebene Art der Zusammensetzung hat entscheidenden Einfluss auf die Planung der Prozessbahn, da die lineare Fahreinheit eine zusätzliche Achse darstellt. Der Roboter und die Fahrachse bilden sozusagen eine kinematische Einheit. Und genau so werden sie auch in der Realität behandelt: sie werden durch einen gemeinsamen Controller gesteuert. Anders formuliert, die Definition eines artikulierten Systems ist die generische Beschreibung eines Robotercontrollers. Die Abb. 3.32 zeigt, wie eine solche Verbindung zwischen einem Roboter und einer Fahrachse aussehen könnte. In einem artikulierten System werden die beiden kinematischen Modelle instanziiert. Damit nun ein Programm dieses System steuern kann, muss es lediglich wissen, wie die Achsen nummeriert sind. Dies wird, wie weiter oben bereits beschrieben, durch das Element festgelegt. Für alle folgenden Schritte kann nun dieses System als eine Einheit betrachtet werden.

3.3.8  Verknüpfung von CAEX und COLLADA In den vorangegangenen Kapiteln wurde beschrieben, wie COLLADA 1.5.0 Geometrie- und Kinematikinformationen einer Anlagen-Komponente abbildet. Damit diese Informationen einem AutomationML-Objekt zugeordnet werden können, müssen sie von CAEX aus referenziert werden. In Abb. 3.33 wird dies dargestellt: das AutomationML-Objekt 110RB_200 referenziert ein COLLADA-Dokument. Dies erfolgt mit Hilfe einer durch AutomationML definierten CAEX-Schnittstelle

3  Beschreibung von Geometrie und Kinematik mit COLLADA

CAEX-Dokument

125

COLLADA-Dokument

Abb. 3.33   Referenz eines CAEX Objekts nach COLLADA

COLLADAInterface (siehe Abschnitt 2.6.1 und 2.7.1). Dessen Attribut refURI beinhaltet den Uniform Resource Identifier (URI) des COLLADA-Dokuments, welches die Geometrie und Kinematik dieses Objektes beinhaltet. Neben der Referenz auf das COLLADA-Dokument kann in CAEX zusätzlich die geometrische Positionierung des Objektes relativ zu seinem Elternobjekt angegeben werden. AutomationML definiert hierzu das Attribut Frame. Dieses spannt ein Koordinatensystem auf, das sich relativ zum Koordinatensystem des Elternobjekts in der Topologie positioniert. Es besteht aus weiteren Unterattributen, die in Tab. 3.9 beschrieben sind und die auch die Reihenfolge der Abarbeitung vorgibt. Ein Beispiel eines COLLADAInterface mit seinen Attribute refURI und Frame in CAEX ist in Abb. 3.34 gegeben. Allerdings ist die Referenzierung des Dokuments nicht ausreichend, da ein COLLADA-Dokument mehrere Objekte beschreiben kann. Die Vereinigung zwischen Geometrie und Kinematik findet aber – wie weiter oben gezeigt – in COLLADA im Element statt. Dieses Element hat allerdings kein von CAEX aus referenzierbares Attribut id. Es musste daher eine Möglichkeit gefunden werden, die Information, die im Element steckt, so zur Verfügung zu stellen, so dass es durch CAEX genutzt und referenziert werden kann. Daher definiert AutomationML eine entsprechende Erweiterung im Rahmen von COLLADA. COLLADA bietet dazu einen Mechanismus, um erweiterte Informationen abzulegen. Dieser Tab. 3.9   Attribute des Attributs Frame Attribut

Beschreibung

x y z rx ry rz

Translation entlang der X-Achse des Elternkoordinatensystems in Meter Translation entlang der Y-Achse des Elternkoordinatensystems in Meter Translation entlang der Z-Achse des Elternkoordinatensystems in Meter Rotation um die X-Achse des verschobenen Koordinatensystems in Grad (°) Rotation um die Y-Achse des verschobenen Koordinatensystems in Grad (°)  Rotation um die Z-Achse des verschobenen Koordinatensystems in Grad (°)

126

S. Lips

Abb. 3.34   XML-Quellcode für ein COLLADAInterface in CAEX

wird durch das Element eingeleitet. Innerhalb dieses Elements folgt das Element mit dem Attribut profile. Für AutomationML ist der Wert dieses Attributs profile = „AutomationML“. Innerhalb des Elements werden die Elemente verwendet, die für die Beschreibung des Elements verwendet würden. Ein Beispiel für ein solches Element ist in Abb. 3.35 gegeben. Das COLLADAInterface kann auch dazu genutzt werden, um eine Verbindung zwischen zwei AutomationML-Objekten herzustellen. Ein Beispiel für eine solche Verlinkung ist das „Anheften“ eines Greifers an einen Roboter. Dazu veröffentlichen der Roboter und der Greifer die entsprechenden Anheftpunkte als COLLADAInterface, die dann mit CAEX-Standardmechanismen miteinander verknüpft werden können. Dies ist in Abb. 3.36 schematisch dargestellt, Abb. 3.37 zeigt den zugehörigen XML-Code des CAEX-Dokuments. Es wird darauf hingewiesen, dass hier für Pfadangaben die verkürzte Schreibweise „/…/“ verwendet wird, in realen CAEX-Dokumenten ist der vollständige Pfad anzugeben. In diesem Fall wird vom AutomationML aus nicht die URI eines Elements eines COLLADA-Dokuments referenziert, sondern die URI eines Elements, das die Position des entsprechenden Anheftpunkts innerhalb des Produktbaums definiert. Ein weiteres Standard-Attribut der Schnittstelle COLLADAInterface namens refType legt fest, wie die referenzierte Ressource zu verwenden ist. Es kann die Werte Implicit und Explicit annehmen, wobei letztere den Standardwert bildet, falls kein

3  Beschreibung von Geometrie und Kinematik mit COLLADA

127

Abb. 3.35   Element für eine Komponente

InternalLink

Abb. 3.36   Relation zwischen zwei COLLADAInterfaces

Abb. 3.37   Verlinkung zwischen Roboter und Greifer

128

S. Lips

Wert angegeben ist. Wird ein COLLADA-Dokument explizit referenziert, so ist der Inhalt des Dokuments Bestandteil der Anlagentopologie. Dies bedeutet, dass die geometrische Repräsentation einer Komponente nur in diesem Dokument beschrieben ist. Eine implizite Referenz hingegen wird verwendet, um eine Komponente, die bereits beschrieben und in der Topologie platziert wurde, näher oder unter einem anderen Aspekt zu beschreiben. Dieses Dokument ist nicht zu verwenden, um die Gesamtszene aufzubauen, weil es ansonsten doppelt in die Szene eingefügt würde.

3.4  Beispiele 3.4.1  BREP: Flansch mit Loch Dieser Abschnitt soll anhand eines einfachen Beispiels die Anwendung des BREP Modells von COLLADA 1.5 erklären, welches in der folgenden Abb. 3.38 dargestellt ist. Dabei wird nicht auf das gesamte Modell eingegangen, sondern es wird lediglich die Beschreibung des Lochs auf der oberen Rechteckfläche näher beleuchtet. Die geometrischen Elemente sind folglich die in Abb. 3.39 dargestellten sechs 3D-Punkte, 6 Kurven und eine Oberfläche. Zur Modellierung dieses Beispiels werden zunächst die Vertizen definiert. Diese sind in Tab. 3.10 aufgelistet. Die folgende Tab. 3.11 listet die Definition der einzelnen Edges auf. Jede einzelne Edge besitzt eine Grundorientierung, die durch die Definition der korrespondierenden Kurve vorgegeben ist. Aus dieser Grundorientierung ergibt sich auch die Festlegung des Start- und des Endvertex. Als nächstes werden die Wires definiert. In diesem Beispiel ergeben sich genau zwei Wires, nämlich eine äußere und eine innere. Damit eine Wire korrekt definiert ist, müssen alle Edges, die zu einer Wire gehören, gleich orientiert sein. Kann dafür die Grundorientierung beibehalten werden, so ist die Orientierung der Edge FORWARD im anderen Fall REVERSED (siehe Tab. 3.12). Als letztes wird die Face definiert. Sie wird durch beide Wires begrenzt. Die eine umrandet sie, die andere schneidet ein Loch in sie hinein. Um genau diesen Unterschied zwischen „Umranden“ und „Herausschneiden“ festzustellen, wird wie-

Abb. 3.38   Flansch mit Loch

3  Beschreibung von Geometrie und Kinematik mit COLLADA Abb. 3.39   Schematische Darstellung der Topologie

129 E1 V5

V1

E3

V2

E5

E6

V6

V3

E4

V4

E2

Tab. 3.10   Definition Vertizen

Vertex

3D-Koordinate

V1 V2 V3 V4 V5 V6

−10, 7.5, 0 10, 7.5, 0 −10, −7.5, 0 10, −7.5, 0 0, 5, 0 0, −5, 0

Tab. 3.11   Definition Edges Edge

Startvertex

Endvertex

E1

V1

V2

E2

V3

V4

E3

V1

V3

E4

V2

V4

E5

V5

V6

E6

V6

V5

Kurve    x  y = z    x  y = z    x  y = z    x  y = z    x  y = z    x  y = z

   −10 1 7.5  + λ  0  0 0    −10 1 −7.5  + λ  0  0 0    −10 0 7.5  + λ  −1  0 0    10 0   7.5 + λ −1  0 0    0 cos ρ 0  + 5  sin ρ  0 0    0 cos ρ 0  + 5  sin ρ  0 0

130 Tab. 3.12   Definition Wires

S. Lips Wire

Edge

Orientierung

W1

E1 E4 E2 E3 E5 E6

FORWARD FORWARD REVERSED REVERSED FORWARD FORWARD

Face

Wire

Orientierung

F1

W1 W2

REVERSED FORWARD

W2

Tab. 3.13   Definition Face

Abb. 3.40   Grundorientierung der Wires

der die Orientierung herangezogen. Ist die Orientierung einer Wire gleichgerichtet mit der Normalen der Oberfläche, die begrenzt werden soll, so ist die Wire eine Umrandung. Im anderen Fall schneidet sie ein Loch in die Oberfläche. Wie in der obigen Tab.  3.13 zu sehen ist, muss die erste Wire mit entgegengesetzter Orientierung verwendet werden. Dies ergibt sich aus der Grundorientierung der Wires, die in Abb.  3.40 dargestellt ist. Die restlichen Faces werden analog beschrieben und können dann zu einer Shell und von dort aus zu einem Solid zusammengesetzt werden.

3.4.2  Dreieckmodell: Flansch mit Loch Die Geometrie aus dem obigen Beispiel wird im Folgenden als polygon-basierte Geometrie beschrieben. Dazu wurde das gegebene BREP Modell trianguliert. Das Ergebnis ist eine durch Dreiecke genäherte Darstellung der Geometrie wie in Abb. 3.41 abgebildet. Mit Hilfe von 336 Punkten werden 112 Dreiecke beschrieben. Die Rundung des Lochs wird mit einer überschaubaren Anzahl von Dreiecken genähert, trotzdem erscheinen die Übergänge zwischen zwei Dreiecken nicht kantig. Dies wird durch die zu jedem Dreieckspunkt gehörende Normale gewährleistet. Die folgende Abb. 3.42 soll dies verdeutlichen. In dem linken Beispiel ist der Übergang

3  Beschreibung von Geometrie und Kinematik mit COLLADA

131

Abb. 3.41   Triangulierte Geometrie

Abb. 3.42   Harter und weicher Kantenübergang

Separate Normale

Gemeinsame Normale

20

Abb. 3.43   Schematische Darstellung einer Schraube

132

S. Lips

zwischen den zwei Dreiecken hart ausgebildet, d. h. die Normalen zu jedem Dreieckspunkt stehen senkrecht zu ihrer zugehörigen Dreiecksfläche. In dem rechten Beispiel ist der Übergang weich ausgebildet. An der gemeinsamen Kante wurde für beide Dreiecke die Normale verwendet, die der Kreisbogen im BREP Modell an dieser Stelle besitzt.

Abb. 3.44   Definition des kinematischen Modells

3  Beschreibung von Geometrie und Kinematik mit COLLADA

133

3.4.3  Kinematik einer Schraube mit Formel Dieses Beispiel (siehe Abb. 3.43) beschreibt das kinematische Modell einer Schraube in einer Mutter. Das Modell ist sehr übersichtlich und beinhaltet trotzdem viele Aspekte, die in den vorangegangen Kapiteln beschrieben wurden. Die Kinematik besteht aus zwei Komponenten – einer Schraube und ihrer zugehörigen Mutter, die über ein Gelenk miteinander verbunden sind. Die Schaftlänge beträgt 20 mm. Eine Umdrehung legt einen Weg von 0.5 mm zurück, was in dem Parameter pitch definiert wird. Die Mutter kann am Gewinde 12 Umdrehungen durchführen, ehe sie den Schaft erreicht. Das Gelenk wird aus zwei Primitiven zusammengesetzt: einem translatorischen und einem rotatorischen Basisgelenk. In diesem Beispiel erfolgt die Gelenkdefinition innerhalb des kinematischen Modells. Der Zusammenhang zwischen Drehung und Senkung der Mutter wird durch folgende Formel definiert: Formel 3.2  Schraubenformel ρDrehung dSenkung = dGewinde · 360 Die Beschreibung in COLLADA ist in Abb. 3.44 als XML-Code dargestellt.

3.5  Zusammenfassung Die Kombination von Geometrie und Kinematik war bislang in keinem frei verfügbaren Datenformat abbildbar und wurde durch das AutomationML-Konsortium in der Khronos-Group für die COLLADA-Version 1.5 vorgeschlagen und gestaltet. Damit ist es erstmalig möglich, kinematisierte Geometrien herstellerneutral abzubilden und auszutauschen. Dies stellt ein wesentliches Ergebnis der AutomationML-Aktivitäten dar, COLLADA 1.5 kann somit bereits heute zum Austausch von kinematisierten Geometrien verwendet werden. Dies ermöglicht die Einsparung von kostenintensiven Aufwendungen beim manuellen Konvertieren und Nach-Kinematisieren von Objekten, die aus einem Fremdwerkzeug importiert werden müssen. Das Kapitel ist in vier Abschnitte aufgeteilt und gibt einen umfassenden ­Überblick über die Verwendung von COLLADA 1.5 in AutomationML. Nach einem Überblick über die Entstehungsgeschichte von COLLADA befasst sich das Kapitel zunächst mit den unterschiedlichen Arten der Geometriedefinition. Es wird erläutert wie Geometrien erstellt und schließlich zu einem Produkt ­zusammengefügt werden können. Die Verwendung von Materialien sowie die Verwaltung von unterschiedlichen Detaillierungsgraden bilden den Abschluss des ersten Teils. Der zweite Teil befasst sich mit der Modellierung von kinematischen Modellen beginnend mit der Definition von Gelenken bis hin zur Zusammensetzung von

134

S. Lips

verschiedenen Systemen zu einer Gesamtkinematik. Die Verbindung zwischen COLLADA und CAEX und deren möglichen Interaktionen bilden den dritten Teil. Eine Reihe von anschaulichen Beispielen schließt dieses Kapitel ab.

Literatur Rémi Arnaud, Mark C. Barnes (2006): COLLADA – Sailing the gulf of 3D Content Creation. A K Peters, Ltd., Wellesley, Massachusetts. COLLADA (2008): COLLADA – Digital Asset Schema Release 1.5.0. Khronos (2009): http://www.khronos.org/files/collada_schema_1_5 MW (2009): http://www.mathworks.com/access/helpdesk/help/toolbox/physmod/mech/index.html W3C (2003): http://www.w3.org/Math

Kapitel 4

Verhaltensbeschreibung mit PLCopen XML Lorenz Hundt, Arndt Lüder, Rainer Drath und Björn Grimm

4.1  Überblick Die vorangegangenen Kapitel erläutern die Modellierung rein statischer Objektstrukturen mit AutomationML – deren Hierarchie, Geometrie und Kinematik. Dieses Kapitel hingegen ist dem Verhalten von Anlagenkomponenten gewidmet, eine weitere wichtige Grundvoraussetzung für den Betrieb einer Anlage. Sinnvolles Anlagenverhalten muss bereits in den Planungsphasen festgelegt werden. Hierfür verwendet der Ingenieur verschiedene Beschreibungsmittel wie Gantt Charts, PERT Charts etc. In den einzelnen Phasen der Anlagenplanung wird das gewünschte Systemverhalten schrittweise mit zunehmendem Detaillierungsgrad modelliert. Somit ist Verhaltensplanung eine phasenübergreifende Ingenieursleistung und ein wesentlicher Aspekt in der Anlagenplanung. Die Verhaltensbeschreibung bezieht sich dabei auf einzelne Systembausteine, aber auch auf deren Interaktion. Je nachdem, in welcher Phase des Engineering-Prozesses man sich befindet, kann die Verhaltensbeschreibung für einen Systembaustein und seine Interaktion mit anderen stark differieren (Wagner et al. 2008). In frühen Engineering-Phasen wird das gewünschte Verhalten zunächst nur abstrakt beschrieben, während in den späten Engineering-Phasen eine deutlich stärkere Gewichtung zu detaillierten zyklischen Abläufen in den Steuerungen erfolgt. Dementsprechend werden in den frühen Phasen eher einfache und in den späten Phasen eher komplexe und implementierungsnahe Beschreibungsmittel genutzt. Ein typischer Planungsprozess mit allen Phasen und vielfältigen Beschreibungsmitteln vom einfachen Gantt Chart bis zu ablauffähigem Steuerungscode ist in Abb. 4.1 dargestellt. Eine durchgängige Weitergabe dieser Planungsdaten von Phase zu Phase erfolgt in der Praxis jedoch kaum. Dies führt zu Inkonsistenzen und aufwändigen Neuplanungen innerhalb der einzelnen Phasen. Hier setzt AutomationML an.

L. Hundt () Otto-von-Guericke-Universität Magdeburg, Universitätsplatz 2 39106 Magdeburg, Deutschland e-mail: [email protected] R. Drath (Hrsg.), Datenaustausch in der Anlagenplanung mit AutomationML, DOI 10.1007/978-3-642-04674-2_4, © Springer-Verlag Berlin Heidelberg 2010

135

136

L. Hundt et al.

Abb. 4.1   Beschreibungsmittel für Verhalten in den Phasen des Anlagen-Engineerings

In diesem Kapitel wird gezeigt, wie solche Verhaltensbeschreibungen mit AutomationML abgebildet und den zugehörigen AutomationML-Objekten im Dachformat CAEX zugeordnet werden können. Gegenstand der Verhaltensbeschreibung sind einzelne konkrete Geräte und mechanische Bauteile, aber auch komplexe Systemkomponenten wie Maschinen oder ganze Bearbeitungsstationen. Daher variieren die zu beschreibenden Verhaltensweisen von übergeordneten Prozessen in Bearbeitungsstationen bis hin zu realen physikalischen Prozessen, die von Aktoren bewirkt und von Sensoren gemessen werden können. Auch die Interaktion zwischen Systemeinheiten muss beschrieben werden. Dies kann eine einfache Beschreibung unerwünschter gemeinsamer Zustände oder die Beschreibung komplexer Kooperationsbeziehungen im Stile von Verhandlungsprotokollen sein. Hierbei lässt sich eine „innere“ und eine „äußere“ Sicht unterscheiden. In AutomationML werden diese Unterschiede durch die Betrachtung verschiedener Beschreibungsmittel und ihrer semantischen Bedeutung reflektiert. 1. Bei der „inneren Sichtweise“ wird die Interaktion innerhalb einer Systemeinheit als kooperatives Verhalten von Teilen derselben angesehen und damit dieser zugeordnet. 2. Die „äußere Sichtweise“ untersucht Interaktionen von Systemeinheiten als Protokolle zwischen diesen und ist somit stets mehreren Systemeinheiten zugeordnet. Bei der Verhaltensbeschreibung mit AutomationML werden insbesondere folgende Arten von Verhalten unterschieden – eine detailliertere Betrachtung erfolgt in Abschnitt 4.2.1: • Sequencing beschreibt das gewünschte und durch Steuerungseingriffe bewirkte Verhalten – das sogenannte gesteuerte Verhalten. • Behaviour beschreibt das bereitgestellte und von der unterlagerten Physik bewirkte Verhalten – das sogenannte ungesteuerte Verhalten.

4  Verhaltensbeschreibung mit PLCopen XML

137

Abb. 4.2   Sequencing und Behaviour zur Verhaltensbeschreibung von Automatisierungsgeräten

• Interlocking beschreibt das Interaktionsverhalten, bei dem das Verhalten von Komponenten oder Teilsystemen nur in bestimmten Systemzuständen ausgeführt werden kann. Das Verhalten eines Systembausteins kann je nach Sichtweise sowohl als Behaviour als auch als Sequencing aufgefasst werden. Dies wird in Abb. 4.2 verdeutlicht. Hier wird eine Station betrachtet, die einen Roboter mit einem Greifer enthält. Das Verhalten der gesamten Bearbeitungsstation kann als Sequencing aufgefasst werden. Das Verhalten des Greifers am Roboterarm ist ein typisches Beispiel für Behaviour. Das Roboterverhalten ist jedoch aus der Sicht der Bearbeitungsstation bereitgestelltes physikalisches Verhalten und damit Behaviour – aus der Sicht des Greifer jedoch ein bewirktes Verhalten, also Sequencing. Um das Verhalten der Roboterstation zu modellieren, müssen folglich beide Sichtweisen beschrieben werden. Mit Hilfe eines Sequencing-Dokuments wird das Sollverhalten des Roboters definiert und dessen Eigenverhalten gesteuert. Das Eigenverhalten des Roboters ist in einem eigenen Behaviour-Dokument niedergelegt. Der Roboter steuert das Eigenverhalten des Greifers. Dieses Verhalten wird dem Roboter als Sequencing zugeordnet. Der Roboter besitzt im Ergebnis sowohl eine Behaviour- als auch eine Sequencing-Beschreibung. Aus der abstrakten Sicht einer Fabrik ist das Verhalten der gesamten Station wiederum als Behaviour zu betrachten. Insofern gliedert sich die Station als Ausschnitt der Fabrik dort mit eigenem Behaviour ein. Die Beschreibung von Sequencing, Behaviour und Interlocking erfordert unterschiedliche Beschreibungsmittel. AutomationML unterstützt explizit Gantt Charts,

138

L. Hundt et al.

PERT Charts, Impuls-Diagramme und State Charts. Diese werden im Abschnitt 4.2 kurz vorgestellt. Zur Abbildung mit AutomationML müssen diese zunächst in ein geeignetes neutrales Datenformat überführt und anschließend den jeweiligen AutomationMLObjekten im Dachformat CAEX zugeordnet werden. Als gemeinsames Format für alle unterstützten Beschreibungsmittel nutzt AutomationML das frei verfügbare Datenformat PLCopen XML (PLCopenXML 2009), ein international akzeptiertes, herstellerneutrales Datenformat zum Austausch von IEC 61131-3 konformen Steuerungsprogrammen. PLCopen XML wird in seiner Version 2.0 in Abschnitt 4.3 kurz vorgestellt. Die zentrale Herausforderung dieses Kapitels ist die korrekte Überführung der verschiedenen Beschreibungsmittel nach PLCopen XML sowie die zukünftige Erweiterbarkeit um weitere Beschreibungsmittel. Die Überführung erfordert Konverter. Der naheliegende Weg, je einen Konverter für jede der genannten Beschreibungsmittel nach PLCopen XML zu erstellen, wird vom AutomationML-Konsortium aufgrund des beträchtlichen Aufwandes nicht empfohlen. PLCopen XML ist ein komplexes Datenformat, dessen Mächtigkeit von AutomationML nur eingeschränkt benötigt wird. Aus diesem Grund stellt Abschnitt 4.4 eine vereinfachte neutrale Zwischenschicht für die Abbildung der einzelnen Beschreibungsmittel vor: das Intermediate Modelling Layer (IML). Dies vereinfacht die Entwicklung von Konvertern erheblich. Für jedes der von AutomationML unterstützten Beschreibungsmittel werden in den Abschnitt 4.4.4 bis 4.4.7 feste Transformationsregeln für die Konvertierung nach IML aufgestellt und verglichen. Die Transformation von IML nach PLCopen XML erfolgt dann für alle bisher und zukünftig berücksichtigten Beschreibungsmittel gleichartig. Die dafür erforderlichen Transformationsregeln werden in Abschnitt 4.4.9 vorgestellt. Dieses Vorgehen hat drei grundlegende Vorteile: Erstens werden Analogien zwischen den Beschreibungsmitteln genutzt und in IML gleichartig modelliert. Dies vereinfacht zusätzlich ihre wechselseitige Konvertierbarkeit. Die Beschreibungsmittel können zwar nicht immer ohne Informationsverlust oder Verfälschungen ineinander überführt werden, IML verdeutlich jedoch, wann dies gelingt und wo Grenzen gesetzt sind. Zum Zweiten wird die künftige Integration von weiteren, bisher nicht betrachteten Beschreibungsmittel in AutomationML vereinfacht, da lediglich eine Darstellung in IML definiert werden muss. Die Mechanismen zur Konvertierung von IML nach PLCopen XML können wiederverwendet werden. Der dritte Vorteil besteht darin, dass das IML-Modell als Grundlage zur Speicherung der verschieden Beschreibungsmittel implementierungsnah beschrieben wird (siehe Abschnitt 4.4). Abschnitt 4.5 ist der Abbildung von Verriegelungslogik gewidmet und erläutert, wie mit AutomationML die logische Verknüpfung von Verhalten modelliert werden kann. Die Einbindung der in PLCopen XML gespeicherten Verhaltensbeschreibungen in das Dachformat CAEX wird in Abschnitt 4.6 erläutert. PLCopen-XML-Dokumente oder einzelne Teile der Verhaltensbeschreibung können mit Hilfe spezieller

4  Verhaltensbeschreibung mit PLCopen XML

139

Referenzmechanismen an die AutomationML-Objekte geknüpft werden. Dies erlaubt, beispielsweise Signale, Variablen oder ganze Verhaltensmodelle mit anderen Signalen, Variablen oder Verhaltensmodellen anderer Objekte zu verbinden.

4.2  Beschreibungsmittel zur Verhaltensmodellierung 4.2.1  Verhaltensinformationen einer Anlagenkomponente Bei der Verhaltensbeschreibung einer Anlagenkomponente wird zwischen ihrem ungesteuerten Eigenverhalten (Behaviour), dem gesteuerten Verhalten (Sequencing) sowie der Verriegelungslogik (Interlocking) unterschieden. Jede Anlagenkomponente kann prinzipiell alle drei Verhaltensaspekte zugleich aufweisen bzw. benötigen (Grimm et al. 2008). Behaviour stellt das von einer Anlagenkomponente bereitgestellte (Eigen-) Verhalten dar. Es kann als ungesteuertes bzw. physikalisches Eigenverhalten verstanden werden. Üblicherweise besitzt jede Anlagenkomponente ein solches Verhalten. Gemäß Lunze (2008) kann dieses Verhalten als kontinuierliches oder Ereignisdiskretes Verhalten aufgefasst werden. Das AutomationML-Konsortium betrachtet zunächst nur Ereignis-diskrete Verhaltensweisen, ohne jedoch eine zukünftige Erweiterung auszuschließen. Dementsprechend werden für die Beschreibung von Behaviour sowohl Zustands- als auch Zustandsübergangsinformationen mit ihren Bedingungen, Kausalitäten, Zeitverhalten etc. erfasst. Das Ziel einer Steuerung besteht nun darin, Eigenverhalten zielgerichtet zu beeinflussen. Sequencing umfasst das Verhalten einer zielgerichteten, schrittweisen Steuerung einschließlich Kausalitäten und Zeitverhalten der gewünschten einzelnen Aktivitäten. Es dient als Grundlage für die spätere Erstellung Ereignis-diskreter Steuerungsprogramme. Sequencing wird mit Hilfe einer Steuerungsspezifikation geplant und später technisch als Steuerungsprozess mit Hilfe von Steuerungs-Softund -Hardware realisiert. Die Beschreibung der Verriegelungslogik dient zur Spezifikation des Interaktionsverhaltens von Anlagenkomponenten. Einer Anlagenkomponente werden dabei Informationen über Zulässigkeit oder Unzulässigkeit von Komponentenzuständen in Beziehung zu anderen Anlagenkomponenten zugeordnet. Dies erfolgt durch Formulierung logischer Zusammenhänge zwischen Anlagenkomponenten und ihren Zuständen. AutomationML nutzt die Beschreibung der Verriegelungslogik jedoch nicht zur Darstellung komplexer Kooperationsbeziehungen – dazu sind Sequencing beziehungsweise Behaviour auf höheren Abstraktionsebenen sinnvoller. Beispiele für die unterschiedenen Verhaltensarten sind in Abb. 4.3 dargestellt und zeigen Sequencing, Behaviour und Interlocking am Beispiel eines Roboters. Der abgebildete Industrieroboter ist dort in einer komplexen Fertigungszelle integriert und führt dort verschiedene Produktionsprozesse in Kooperation mit anderen Industrierobotern aus. Er sei dabei so programmiert, dass er mehrere Bewegungsprozesse

140

L. Hundt et al.

Abb. 4.3   Beispiel für verschiedenen Logik-Informationsarten

durch Abfolge verschiedener Bewegungsbefehle ausführt. Jeder dieser Bewegungsprozesse kann durch Ansteuerung einer übergeordneten Steuerungsinstanz aufgerufen werden. Die Menge der Bewegungsprozesse, ihr Aufrufverhalten und gegebenenfalls ihre Nutzungsbedingungen können als Behaviour des Industrieroboters beschrieben und von der übergeordneten Steuerung genutzt werden. Die einzelnen Bewegungsprozesse wiederum können als Sequencing für die einzelnen Achsen und den Effektor des Industrieroboters betrachtet werden. Sie werden durch die Schrittkette der Bewegungsbefehle des Roboterprogramms gebildet. Verriegelungslogik ist in diesem Beispiel die Koordinierung mit den anderen Robotern der Fertigungszelle sowie den umgebenden sicherheitsrelevanten Sensoren und Aktoren. So werden die einzelnen Bewegungsprozesse der verschiedenen Roboter miteinander synchronisiert, um beispielsweise Kollisionen zu vermeiden und die Korrektheit des Produktionsprozesses zu gewährleisten. Dies soll ungewollte Systemzustände verhindern. Weiterhin werden Abschaltbedingungen definiert, um bei unerlaubten Systemzuständen in den sicheren Zustand zu wechseln.

4.2.2  Beschreibungsmittel für Verhalten In der Industrie werden für die problemorientierte Planung von Behaviour, Sequencing und Verriegelungslogik unterschiedliche Beschreibungsmittel eingesetzt, vgl. Hundt et al. (2008). Es ist aufgrund ihrer Vielzahl jedoch kaum möglich, alle zu unterstützen. Daher erfolgte im AutomationML-Konsortium eine priorisierte Auswahl, die insbesondere die Anforderungen aus dem Engineering-Prozess von Produktionssystemen und die darin enthaltenen Spezifikationen von Steuerungssystemen

4  Verhaltensbeschreibung mit PLCopen XML

141

berücksichtigt. AutomationML unterstützt explizit die Beschreibungssprachen Gantt Charts, PERT Charts, Sequential Function Charts, Impuls-Diagramme, Logiknetzwerke und State Charts. Mit diesen können wesentliche Anwendungsfälle für Objekt- und Systemverhalten in der Fertigungsplanung abgebildet werden. Diese Auswahl deckt die vom AutomationML-Konsortium als wesentlich erachteten Anwendungen ab. Der folgende Abschnitt zeigt, wie sich die genannten Beschreibungsmittel im Engineering-Prozess einordnen.

4.2.3  Beschreibungsmittel im Engineering-Prozess In Abb. 4.4 wird dargestellt, in welchen Planungsphasen die genannten Beschreibungsmittel häufig verwendet werden. Der Engineering-Prozess eines Produktionssystems beginnt mit der Entwicklung des Produktes, das auf dem Produktionssystem gefertigt werden soll. Neben der Betrachtung von Marktgängigkeit und Kosten ist die Festlegung des grundsätzlichen Fertigungsprozesses in seiner Abfolge von Produktionsschritten ein wichtiger Bestandteil der Produktentwicklung. In der Prozessindustrie wird dafür das Basisrezept festgelegt, in der Automobilindustrie der Fertigungsablauf als Bill of Operation. In der Regel sind dabei die Festlegungen nicht sehr detailliert, so dass in diesem Fall üblicherweise Gantt Charts zur Beschreibung eingesetzt werden.

Abb. 4.4   Nutzung einzelner Beschreibungsmittel während der Planung von Produktions­sys­ temen

142

L. Hundt et al.

Gantt Charts bieten wertvolle Eingangsinformation für den nächsten Engineering-Schritt, nämlich die Festlegung der generellen Struktur des Produktionssystems im Rahmen der Anlagenplanung. In diesem Schritt werden den einzelnen Produktionsschritten Maschinen beziehungsweise Anlagenteile für ihre Ausführung zugeordnet. Diese werden in eine sinnvolle, den technologischen Notwendigkeiten angepasste Reihenfolge gebracht. Im Ergebnis kann das bisherige Modell des Produktionsablaufs mittels eines PERT Charts um weitere Informationen ergänzt und verfeinert werden. Im nächsten Schritt, dem Functional Engineering, erfolgen Mechanik- und Elektroplanung der entsprechenden Anlagenteile. In beiden Schritten stellt das PERT Chart eine wichtige Eingangsinformation dar. Als deren Ergebnis kann ein Impuls-Diagramm entstehen, das den Produktionsablauf einer Maschine oder eines Anlagenteils verfeinert und um die notwendigen Signale zu ihrer Ansteuerung sowie deren Anhängigkeiten erweitert. Zudem werden in diesen beiden Schritten Sicherheitsanforderungen spezifiziert, die zum Beispiel mittels Logiknetzwerken beschrieben werden können. Im weiteren Verlauf des Functional Engineering werden Programme für die speicherprogrammierbaren Steuerungen (SPS) und die geplanten Roboter sowie die Mensch-Maschine-Interfaces (HMI) implementiert. Die in den Vorschritten entstandenen Impuls-Diagramme und Logiknetzwerke bilden wichtigen Eingangsinformationen für diese drei Arbeitsschritte, da sie alle Anforderungen an das Verhalten der gesamten Steuerungsarchitektur berücksichtigen können. So entwickelte Steuerungsprogramme können teilweise mit Sequential Function Charts (SFC) abgebildet werden. Im Anschluss an das Functional Engineering erfolgt die Inbetriebnahme der Anlage. Zur Sicherstellung einer höheren Qualität der Steuerungsprogramme und zur Fehlervermeidung kann eine virtuelle Inbetriebnahme vorgelagert werden. Hierzu werden Modelle der Steuerung und des ungesteuerten Verhaltens der Anlage als Eingangsinformation benötigt. Erstere können mittels der SFCs aus dem Functional Engineering gewonnen werden, wohingegen die zweite Modellmenge aus den Schritten der Anlagenplanung und der Mechanikplanung stammt, in dem die physikalischen Eigenschaften der Anlage definiert werden. Diese Beschreibungen könnten zum Beispiel mittels State Charts erfolgen. Natürlich beschränken sich die Nutzungsmöglichkeiten dieser Beschreibungsmittel nicht auf den genannten Prozess. Weitere Beispiele sind: • Beschreibung von gewünschtem, zyklischem Anlagenverhalten mittels State Charts und ihre Nutzung zur virtuellen Inbetriebnahme, • Beschreibung des Verhaltens von speicherprogrammierbaren Steuerungen mit Impuls-Diagrammen zur Nutzung in der Programmierung von Robotern und von Mensch-Maschine-Interfaces, • Beschreibung von Robotersteuerungsverhalten mit Impuls-Diagrammen zur Nutzung in der Programmierung von speicherprogrammierbaren Steuerungen und von Mensch-Maschine-Schnittstellen.

4  Verhaltensbeschreibung mit PLCopen XML

143

Da die einzelnen Beschreibungsmittel in der Literatur zum Teil widersprüchlich definiert werden, geben die folgenden Abschnitte eine kurze Übersicht, wie sie hier verstanden und verwendet werden.

4.2.4  Gantt Charts Gantt Charts sind eine einfache grafische Repräsentation Ereignis-diskreter Modelle mit Hilfe einer Sequenz von sogenannten „Balken“. Sie kommen insbesondere in frühen Phasen des Engineerings von Produktionssystemen zum Einsatz und werden zur Beschreibung der Reihenfolge und Ausführungszeiten einer Abfolge von Aktivitäten genutzt. Üblicherweise werden in Gantt Charts Produktionsprozesse im Sinne von Produktionsrezepten abgelegt, das heißt sie enthalten die Abfolge der einzelnen notwendigen Fertigungsschritte mit ihrer geplanten Dauer, die als Arbeitsfolgegraf oder Bill of Operation bezeichnet wird (Schnieder 1999). Die zwei wichtigsten gespeicherten Informationen in Gantt Charts sind der Start- und der Endzeitpunkt von Aktivitäten (Balken) sowie deren Vorgänger/Nachfolger-Beziehungen. • Balken beschreiben Aktivitäten mit ihrem individuellen Start- und Endzeitpunkt. Die Differenz beider Daten gibt die Dauer der Aktivität wieder. • Vorgänger/Nachfolger-Beziehungen zwischen Balken beschreiben ihre Ausführungsreihenfolge sowie die logische Abhängigkeit zwischen ihnen. Gantt Charts fokussieren auf die Beschreibung von Zeitpunkten und -dauern, die sich auf Start und Ende von Aktivitäten beziehen. Um den zeitlichen Verlauf aller Aktivitäten bestimmen zu können, verwendet AutomationML das Konzept einer globalen Uhr, die für das gesamte Diagramm gilt. Sie bildet den Ursprung des Zeitstrahls für alle Aktivitäten eindeutig ab. Dementsprechend müssen Modelle, die mit lokalen Uhren arbeiten, die beispielsweise nur innerhalb einer Aktivität gelten, vor der Speicherung in AutomationML auf ein Modell mit einer globalen Uhr abgebildet werden, was jedoch ohne Einschränkung möglich ist. Ein Beispiel für Gantt Charts ist in Abb. 4.5 dargestellt. Visuell eignen sich Gantt Charts besonders gut für die intuitive Beschreibung parallel ablaufender Aktivitäten. Dies entspricht der Modellierung von UND-Verzwei-

Abb. 4.5   Beispiel für ein Gantt Chart

144

L. Hundt et al.

gungen beziehungsweise UND-Vereinigungen im Kontrollfluss des betrachteten Prozesses. Einschränkend ist festzustellen, dass sie keine Möglichkeiten der Beschreibung von bedingten Abläufen oder Zyklen bzw. Schleifen bereitstellen.

4.2.5  PERT Charts PERT Charts sind eine Form der weit verbreiteten Netzplantechniken (Schnieder 1999). Sie werden vorrangig zur Beschreibung und Analyse zeitlicher Eigenschaften von Aktivitätssystemen genutzt. Analog zu Gantt Charts können PERT Charts gleichzeitige und damit nebenläufige Aktivitäten abbilden. Sie werden jedoch nicht als Balken, sondern als Knoten modelliert (siehe Abb. 4.6), was die Darstellbarkeit von UND-Verzweigungen sowie UND-Zusammenführungen ermöglicht. Es ist jedoch auch hier nicht möglich, Alternativen zu beschreiben. PERT Charts werden zumeist zur Beschreibung und Analyse der zeitlichen Bedingungen und kausalen Abfolgen einer Menge von unabhängigen Prozessschritten verwendet, die als Knoten bezeichnet werden. Üblicherweise finden sie in frühen Phasen des Engineering-Prozesses Anwendung, um das Zeitverhalten und die Abhängigkeiten von Fertigungsschritten in Produktionsprozessen zu spezifizieren. Sie werden auch bei der Sicherheitsanalyse genutzt, die sogenannte HAZOP. Dabei wird besonderen Wert auf die Darstellung von temporalen Bedingungen wie frühester und spätester Beginn beziehungsweise das Ende von Fertigungsschritten gelegt, um diese in der weiteren Anlagenplanung insbesondere für Auslastungs-, Kapazitäts-, Sicherheits- und Durchsatzanalysen nutzen zu können. Die zwei wichtigsten Sprachelemente der PERT Charts sind ähnlich wie bei Gantt Charts Knoten und Vorgänger/Nachfolger-Beziehungen:

Abb. 4.6   Beispiel für ein PERT Chart

4  Verhaltensbeschreibung mit PLCopen XML

145

• Knoten beschreiben Aktivitäten mit frühestem und spätestem Startzeitpunkt, frühestem und spätestem Endzeitpunkt, Dauer und Verzögerung. • Vorgänger/Nachfolger-Beziehungen zwischen Knoten beschreiben ihre Ausführungsreihenfolge sowie deren logische Abhängigkeiten. In den verschiedenen Ausprägungen von PERT Charts repräsentieren die Vorgänger/ Nachfolger-Beziehungen unterschiedliche Relationen zwischen den Start- und Endzeitpunkten der Knoten. So können u. a. folgende Beziehungen festgelegt werden: • Ende/Start-Beziehungen zur Beschreibung des Starts eines Knotens nach dem Ende eines anderen Knotens, • Start/Start-Beziehungen zur Beschreibung des Starts eines Knotens nach dem Start eines anderen Knotens, • Ende/Ende-Beziehungen zur Beschreibung des Endes eines Knotens nach dem Ende eines anderen Knotens, und • Start/Ende-Beziehungen zur Beschreibung des Endes eines Knotens nach dem Start eines anderen Knotens. Da die Ende/Start-Beziehungen die weitaus größte Verbreitung besitzen, wird in AutomationML nur dieser Typ von Vorgänger/Nachfolger-Beziehung unterstützt. Ähnlichkeiten zur Ablaufsprache (SFC) der IEC 61131 sind für die Modellierung mit PLCopen XML von Vorteil und führen zu ähnlichen Transformationsregeln.

4.2.6  Impuls-Diagramme Impuls-Diagramme sind eine Form der Signalfluss-Diagramme, die vorrangig der Abbildung von Signalverläufen innerhalb eines Systems dienen. Dabei bilden sie die kausalen und zeitlichen Abhängigkeiten von Signalen und lokalen Systemzuständen ab. Sie beschreiben, wie Veränderungen von Systemzuständen durch Signale beeinflusst und umgekehrt Signale von Zustandsübergängen erzeugt werden (Schnieder 1999). Ein Beispiel-Impuls-Diagramm und seine Elemente wird in Abb. 4.7 dargestellt. Impuls-Diagramme werden vorwiegend in späteren Phasen des Engineerings von Produktionssystemen verwendet, da sie besonders gut zur Beschreibung der Interaktion von Anlagenkomponenten und zur Beschreibung der Reaktion einer Anlagenkomponente auf externe Einflüsse geeignet sind. Im Gegensatz zu Gantt Charts und PERT Charts können mit Implus-Diagrammen auch Alternativen beschrieben werden. Dies resultiert aus der Möglichkeit, Signale logisch zu verknüpfen beziehungsweise an verschiedene Ziele zu senden. Impuls-Diagramme besitzen vielfältige in der Literatur beschriebene Ausprägungen, die sich insbesondere in der Begriffswahl unterscheiden und widersprechen können. Es werden daher folgende Begriffe definiert:

146

L. Hundt et al.

Abb. 4.7   Beispiel für ein Impuls-Diagramm

• Eine Resource ist ein Objekt, zum Beispiel ein Greifer. Es kann mehrere Zustände annehmen, die durch verschiedene Werte von Variablen oder Signalbelegungen repräsentiert sind, beispielsweise der Position des Greifers. • Eine Group bildet eine Zusammenfassung von Resources oder anderen Groups. Sie ermöglicht die Hierarchisierung von Resources. • Eine Resource kann verschiedene Resource States einnehmen – Zustände, die durch den Wert einer oder mehrerer Variablen charakterisiert sind. Jeder mögliche Zustand wird im Impuls-Diagramm durch eine separate Zeile dargestellt. • Übergänge zwischen den Resource States werden Resource State Changes genannt. • Eine Abfolge von Resource States und Resource State Changes wird in einem Impuls-Diagramm als Resource State Flow bezeichnet. Üblicherweise wird ein Resource State Flow durch zeilenübergreifende Linien abgebildet. Dabei beschreiben horizontale Linien konstante Zustände und schräge Linien Zustandsübergänge. Die Länge der einzelnen Linienabschnitte gibt Aufschluss über die Dauer von Zuständen und Zustandsübergängen. • Ein Signal in einem Impuls-Diagramm beschreibt die Abhängigkeit zwischen Resource State Flows. Sie werden zeitabhängig oder durch das Ende eines Resource State Changes ausgelöst. und können dadurch weitere Resource State Changes auslösen. Dabei verbinden Signals entweder Resource State Flows oder führen auf den sendenden Resource State Flow zurück. Neben diesem Signalaustausch besteht die Möglichkeit, Signals auch extern, das heißt außerhalb des Diagramms auszulösen. Signals können zwar nur von einem Resource State Flow ausgehen, jedoch mehrere Ziele – Resource State Flows – besitzen. Zudem ist

4  Verhaltensbeschreibung mit PLCopen XML

147

eine logische Verknüpfung von mehreren Signals als Bedingungen zum Auslösen eines Resource State Changes möglich. • Die Zeit wird wie in Gantt Charts mittels einer globalen Uhr abgebildet. Falls lokale Uhren vorkommen, müssen diese in eine gemeinsame globale Zeit transformiert werden. Die globale Uhr wird im Diagramm durch die so genannte Timeline repräsentiert. Sie beschreibt Zeitpunkte, an denen Signals zwischen Resource State Flows ausgetauscht werden können, d. h. Resource State Changes auftreten. Die Timeline kann auch als Ausgangpunkt der externen Signals angesehen werden. In Impuls-Diagrammen können drei Typen von Zeitinformationen hinterlegt werden: 1. die Dauer eines Resource State Change, die das Zeitintervall des Übergangs zwischen zwei Zuständen einer Resource beschreibt, 2. die Dauer eines Resource State zwischen zwei Resource State Changes, was der Dauer eines Zustandes entspricht, und 3. die Zeit zwischen zwei externen Signalen. In Impuls-Diagrammen können zudem Sensoreingänge und Aktorausgänge für die einzelnen Resource States vorgesehen werden. Diese dienen der Beschreibung der Interaktion des modellierten Systems mit seiner Umwelt.

4.2.7  Sequential Function Charts Sequential Function Charts (SFC) gehören zu den in der in der IEC 61131-3 spezifizierten Programmiersprachen für speicherprogrammierbare Steuerungen, im deutschen Sprachraum auch als Ablaufsprache bezeichnet (Schnieder 1999). Die Ablaufsprache wurde in die IEC 61131-3 aufgenommen, um dem Programmierer ein Mittel zur Darstellung von sequentiellen Abläufen in Form von Schrittketten und zugehörigen Aktivitäten zu bieten. Sie werden üblicherweise in den Detail-Phasen des Engineering-Prozesses genutzt, um übergeordnete Steuerungsabläufe zu spezifizieren beziehungsweise zu implementieren. Dabei wird auf die Darstellung von temporalen und kausalen Bedingungen der Abfolge von Zuständen und Zustandsübergängen besonderen Wert gelegt, an die wiederum Aktivitäten gebunden werden können. Dementsprechend dienen SFCs als Mittel der Darstellung von Sequenzen bei Steuerungseingriffen. SFCs besitzen wenige Sprachelemente und sind aufgrund ihrer einfachen Struktur weitgehend herstellerübergreifend wiederverwendbar. Die wesentlichen Modellierungsmittel der SFCs sind in Abb. 4.8 dargestellt. • Schritte beschreiben stabile Situationen bzw. Zustände in einem modellierten System. Sie erlauben die Ausführung von Steuerungsaktivitäten mit Hilfe von Aktionen, beispielsweise dem Ansteuern eines Aktors. Ein Schritt wird erst

148

L. Hundt et al.

Abb. 4.8   Beispiel eines SFCs nach IEC 61131-3

verlassen, wenn die Übergangsbedingung zum nächsten Schritt erfüllt ist. Zwischen zwei Schritten muss sich stets eine Transition befinden. • Transitionen beschreiben die Übergange zwischen Schritten und sind mit Übergangsbedingungen versehen, beispielsweise einem Binärsignal. • Aktionen definieren die Ausführung einer Steuerungsaktivität und sind an Schritte gebunden. Die Implementierung einer Aktion kann direkt im SFC oder in Form eines Unterprogramms erfolgen, das von mehreren Schritten aufgerufen werden kann. Es wird dann ausgeführt, wenn der zugehörige Schritt aktiv ist. Weiterhin können mehrere Aktionen an einen Schritt gebunden werden, die dann gemeinsam ausgeführt werden. Zudem können Aktionen zeitliche Bedingungen für ihre Ausführbarkeit oder Ausführungsdauer besitzen. • Konvergenzen beschreiben Zusammenführungen von Parallelzweigen, Divergenzen hingegen Verzweigungen. Beide bieten die Möglichkeit der Modellierung

4  Verhaltensbeschreibung mit PLCopen XML

149

von parallelen oder alternativen Kontrollflüssen im System. Entsprechend werden alternative und parallele Konvergenzen und Divergenzen unterschieden. • Sprünge (auch als Jump oder Step bezeichnet) erlauben, im Modellsystem von einem Schritt zu einer anderen Position im Programm zu springen. In SFCs können verschiedene zeitliche Bedingungen abgebildet werden. Diese werden insbesondere durch die zeitlichen Eigenschaften von Aktivitäten und ihre Relation zu Schritten kodiert. Aktivitäten können beispielsweise so lange dauern, wie ein ihnen zugeordneter Schritt aktiv ist, oder bis sie gezielt beendet werden. Sie können eine feste Zeit dauern oder alternativ nach einer definierten Zeitspanne nach Eintritt in einen Schritt begonnen oder beendet werden. Für eine tiefere Beschreibung von SFCs sei auf AutomationML.L (2009) verwiesen.

4.2.8  Logiknetzwerke Logiknetzwerke dienen zur anschaulichen Darstellung und Verschaltung von LogikBausteinen. Sie wurden ursprünglich zur Abbildung miniaturisierter elektronischer Schaltungen und Logikbausteine entwickelt und bieten eine abstrakte Symbolik für logische Grundfunktionen und komplexe Funktionen. Die Schaltzeichen für Logiknetzwerke werden in verschiedenen Standards betrachtet, zum Beispiel in der IEC 61131-3 (IEC 61131-3 2003) oder IEC 60848 (IEC 60848 2002). Maßgebend für die Nutzung von Logiknetzwerken in AutomationML ist ihre Definition im Rahmen der IEC 61131-3 und der dort spezifizierten Funktionsbausteinsprache (FBS). Ein Beispiel eines einfachen Logiknetzwerkes ist in Abb. 4.9 dargestellt. Basis der Logiknetzwerke und der aus ihnen entstandenen Sprache sind Logikund Funktionsbausteine. Diese repräsentieren eine bestimmte Funktionalität und werden über einen Bezeichner, eine Eingangssignal-Schnittstelle mit mehreren Eingangssignalen und eine Ausgangssignal-Schnittstelle mit mehreren Ausgangssignalen beschrieben. Neben den logischen Grundbausteinen UND, ODER und NICHT sowie anderen logischen Funktionsbausteinen, sind in der IEC 61131-3 unter anderem Funktionsbausteine für Speicher- oder Zeitverhalten definiert. Logiknetzwerke werden aus einer Menge von Funktionsbausteinen und der Verschaltung ihrer Ein- und Ausgangs-Interfaces gebildet. Die Verknüpfungen erlauben dabei die Modellierung komplexer zeitlicher und logischer Verhaltensweisen des modellierten Systems. Logiknetzwerke ermöglichen die Modellierung sowohl einfacher logischer Verknüpfungen als auch komplexer nebenläufiger Strukturen. Es können zudem komplexe Logikbausteine definiert werden. In der praktischen Anwendung sind Logiknetzwerke gerade im europäischen Raum weit verbreitet. Sie werden unter anderem gern zur Modellierung von Sicherheitsbedingungen für Steuerungssysteme wie Abschaltkreise und Notausbedingungen, zur Abbildung von Verhaltensmatrizen, zur Darstellung von Programmen für FPGA oder zur Beschreibung von Ablaufsteuerungen genutzt.

150

L. Hundt et al.

Abb. 4.9   Beispiel für ein Logiknetzwerk

4.2.9  State Charts State Charts sind eine Ereignis-diskrete Beschreibungssprache, die auf den Arbeiten von Harel (Harel 1988) basiert. Die Grundlage für State Charts bildet die Automatentheorie. Bei der Definition von State Charts wurden gebräuchliche flache monolithische Automaten von D. Harel um die Möglichkeiten zur Beschreibung von Nebenläufigkeiten und Hierarchien erweitert. State Charts beschreiben das Verhalten eines Systems durch Definition sämtlicher möglicher Systemzustände sowie den Übergangsbedingungen zwischen ihnen. In jedem Systemzustand werden alle relevanten Systemparameter mit ihrem aktuellen Wert festgelegt – die sogenannte Systemkonfiguration. State Charts haben in den letzten Jahren insbesondere durch ihre Integration in die Unified Modelling Language (UML) weite Verbreitung gefunden Österreich (2005). Sie dienen üblicherweise zur Beschreibung des internen Verhaltens von Systemen. Im Rahmen des Engineering-Prozesses von Produktionssystemen werden State Charts vielfältig eingesetzt. Hier dienen sie in frühen Phasen zum Beispiel zur Be-

4  Verhaltensbeschreibung mit PLCopen XML

151

schreibung von zyklischen Produktionsprozessen. In späten Phasen werden sie unter anderem zur Beschreibung des ungesteuerten Verhaltens von Anlagenkomponenten verwendet. Außerdem bieten sie eine gute Basis zur Nutzung innerhalb von Simulationen. Die wichtigsten Sprachelemente der State Charts sind Zustände, Zustandsübergänge und Aktivitäten, die ihnen zugeordnet sind. Sie bilden ein komplexes modulares und hierarchisches System zur Modellierung nebenläufiger parallel eintretender Teilzustände. Im Gegensatz zu allen anderen in diesem Kapitel betrachteten Beschreibungsmitteln besitzen State Charts keinen expliziten Zeitbegriff. Ein Beispiel eines State Charts ist in Abb. 4.10 dargestellt. Da verschiedene Dialekte von State Charts existieren, legt sich AutomationML auf die Betrachtung der folgenden Modellierungselemente fest. Mit diesen können die Merkmale der Harel- und UML-State-Charts vollständig erfasst und werden: • Ein State (Zustand) repräsentiert eine stabile, d. h. Zeit verbrauchende Situation im modellierten System, die die Ausführung von Operationen ermöglicht bzw. für diese notwendig ist. Es werden drei Arten von Zuständen unterschieden: normale Zustände, Startzustände und Endzustände. Dabei beschreibt ein Startzustand den Beginn und ein Endzustand den Endpunkt des Lebenszyklus eines Systems oder Teilsystems. • Eine State Transition (Zustandsübergang) repräsentiert den Übergang von einem Zustand in einen anderen und beschreibt somit eine Vorgänger/Nachfolger-Relation zwischen Zuständen. Dabei werden die Bedingungen für den Übergang durch notwendige Ereignisse und einen zu erfüllenden logischen Ausdruck angegeben – den sogenannten Guard. • Eine Action (Aktion) dient der Darstellung einer Operation. Sie kann dabei Zuständen und – im Gegensatz zu SFCs – auch Zustandsübergängen zugeordnet werden. Eine Aktion kann unterschiedliche Ausführungsmomente besitzen. Als Eintrittsaktion eines Zustandes wird sie einmalig bei Eintritt in diesen Zustand

Abb. 4.10   Beispiel für ein State Chart

152

L. Hundt et al.

ausgeführt. Als Austrittsaktion eines Zustandes erfolgt sie einmalig bei seinem Verlassen. Als interne Aktion eines Zustandes wird sie zyklisch ausgeführt, solange der Zustand aktiv ist. Die Aktion eines Zustandsüberganges erfolgt, wenn der Zustandsübergang stattfindet. • Ein Event (Ereignis) bildet ein Signal ab, welches das Verhalten des modellierten Systems durch Beeinflussung von Zustandsübergängen bestimmen bzw. beeinflussen kann. • Hierarchisierung: Zur Beschreibung hierarchischer Strukturen kann jeder Zustand einen oder mehrere parallele State Charts enthalten, d. h. ein Zustand kann Unterzustände, Unterzustandsübergänge und Unteraktivitäten beinhalten. Dies erlaubt, komplexe State Charts zu vereinfachen. Damit wird die Erstellung einer Zustandshierarchie ermöglicht, zudem kann Nebenläufigkeit von Zuständen beschrieben werden. Dabei wird jedes interne State Chart in einem Zustand als Region bezeichnet. • Ein Zustandsübergang kann Zustände auf verschiedenen Ebenen der Zustandshierarchie verbinden. Damit werden entsprechende Zustandsübergänge auf allen Ebenen der Zustandshierarchie ausgedrückt. • Connectors (Verbinder) werden zur Verringerung der Anzahl und Komplexität von Zustandsübergängen eingesetzt. Sie dienen der logischen Aufteilung beziehungsweise Vereinigung derselben und ermöglichen eine Abbildung verschiedener Übergänge aufeinander. Dabei werden zwei Arten von Verbindern unterschieden: History Connectors und Condition Connectors. Ein History Connector repräsentiert den letzten Zustand eines State Charts in der Zustandshierarchie, der beim Verlassen des zugehörigen übergeordneten Super-Zustandes gültig war. Der Super-Zustand von State 1.1 ist beispielsweise State 1, siehe Abb. 4.10. Er ersetzt damit alle Zustände eines State Charts und kann Endpunkt von Zustandsübergängen sein. Ein Condition Connector beschreibt die Aufteilung von Zustandsübergängen gemäß bestimmter an sie gekoppelter Bedingungen und beschreibt damit alternative Zustandsübergänge. Er kann sowohl Start als auch Ende von Zustandsübergängen sein. State Charts lassen sich mit Hilfe von Algorithmen analysieren – dieses Ziel wird von AutomationML jedoch nicht verfolgt, sondern als Werkzeugleistung betrachtet. AutomationML dient ausschließlich als Austauschformat und kann als solches lediglich die Strukturinformationen übertragen. Trotzdem muss AutomationML verhaltensrelevante Informationen repräsentieren, die nicht in der Struktur der State Charts kodiert sind. Ein Beispiel abzubildender Informationen ist die Definition von Subzuständen, die einzunehmen sind, bevor ein Zustand verlassen werden darf. Hierbei wird bei State Charts unterschieden, ob vor dem Verlassen eines Zustandes alle eingenommenen Subzustände dem Typ Endzustand entsprechen müssen oder nicht. Weiterhin ist die Lebensdauer von Ereignissen abzubilden. Hier wird zudem unterschieden, ob die Speicherung von Ereignissen über Zustandsübergänge hinweg notwenig ist oder nicht (Harel 1988).

4  Verhaltensbeschreibung mit PLCopen XML

153

4.3  PLCopen XML 2.0 4.3.1  Überblick Der Austausch von Engineering-Daten zwischen verschiedenen Entwicklungsumgebungen und Werkzeugen ist ein essentieller Wunsch von Betreibern und Zulieferern bei der Planung von Produktionssystemen. Im Bereich der Programmierung von Feldsteuerung war dies, schon aufgrund fehlender Standards zur Programmierung, lange nicht möglich. Mit der Veröffentlichung der IEC 61131-3 (IEC 61131-3 2003) eröffneten sich neue Möglichkeiten. Die IEC 61131-3 standardisiert Beschreibungsmittel zur Programmierung von Steuerungen. Dies allein reicht allerdings nicht aus, um einen herstellerneutralen Austausch von bereits implementierten Steuerungsprogrammen, Bibliotheken mit ihren Elementen oder gar kompletten Projekten zur Steuerungsprogrammierung zu ermöglichen. Diese Möglichkeit wurde von der unabhängigen Organisation PLCopen in der Arbeitsgruppe TC 6 (PLCopen 2009) mit der Definition des Datenaustauschformates PLCopen XML geschaffen. Bei der Entwicklung dieses Datenformats ging der Fokus sogar über den Datenaustausch zwischen verschiedenen Programmierumgebungen hinaus. Vielmehr ist das Datenformat PLCopen XML ebenso als Datenaustauschmedium für Netzwerkkonfigurations-, Debugging-, Simulations- oder auch Dokumentationswerkzeuge entwickelt worden (PLCopen XML 2009). Die vier folgenden Anwendungsfälle wurden dabei als maßgeblich betrachtet (siehe Abb. 4.11).

Abb. 4.11   Anwendungsfälle zum Datenaustausch mit PLCopen XML

154

L. Hundt et al.

Austausch von Programmen zwischen Programmierwerkzeugen für alle IEC 61131-3 Sprachen Die Umsetzung dieses Anwendungsfalls durch PLCopen XML soll den Austausch von Programmorganisationseinheiten (POUs) ermöglichen. Dies sind funktionale Teile von Steuerungsprogrammen oder ganzer Projekte zur Steuerungsprogrammierung. Dabei stehen vor allem der Export und Import von konsistenten und validen Programmen im Vordergrund, da hier der noch benötigte manuelle Aufwand am geringsten und somit der Nutzen am größten ist. Dieser Anwendungsfall adressiert weiterhin die Migration des Steuerungs-Codes von einer Plattform auf eine zweite oder das parallele Arbeiten auf unterschiedlichen Plattformen. Schnittstelle zu Erzeugern von grafischen und logischen Informationen Durch die Realisierung dieses Anwendungsfalls soll PLCopen XML eine Schnittstelle für Werkzeuge bilden, die grafische oder logische Informationen zunächst erzeugen und im Laufe des Engineerings weitergeben können. So können beispielsweise High-Level-Engineering-Werkzeuge PLCopen XML nutzen, um aus grafischen Informationen oder der logischen Verschaltung von Elementen Variablenlisten zu exportieren. Diese können einem Werkzeug zur Steuerungsprogram­ mierung zur Verfügung stehen oder der Erstellung von Templates für die Programmierung dienen. Schnittstelle zu Konsumenten von grafischen und logischen Informationen Die Schnittstelle, die durch die Realisierung dieses Anwendungsfalls von PLCopen geboten wird, ist das Gegenstück zum vorangegangen Anwendungsfall. So können beispielsweise Validierungswerkzeuge, SCADA-Systeme, Dokumentationswerkzeuge oder HMI-Werkzeuge die in PLCopen XML angebotenen Informationen konsumieren und im Engineering-Prozess weiter verwenden. Verteilung und Weitergabe von Funktionsbausteinbibliotheken Durch die Unterstützung dieses Anwendungsfalls ermöglicht PLCopen XML die Weitergabe und Verteilung von herstellerspezifischen Funktionen beziehungsweise Funktionsbausteinen zwischen unterschiedlichen Programmierwerkzeugen und Plattformen. Damit wird es dem Nutzer ermöglicht, eigene Funktions- und Funktionsbausteinbibliotheken zu kreieren und diese in verschiedenen Entwicklungsumgebungen zu nutzen. Technisch besitzt PLCopen XML folgende Eigenschaften: • PLCopen XML ist als XML-Schema (Vonhoegen 2009) spezifiziert. • Es unterstützt die Speicherung und Weitergabe alle der fünf Sprachen der IEC 61131-3: Funktionsblockdiagramme (FBD), Strukturierter Text (ST), Anweisungslisten (AWL), Ablaufsprache (AS) und Kontaktplan (KOP). • Es ermöglicht den Austausch von Steuerungsprogrammen auf Projekt-, POUoder Funktionsebene. • Durch PLCopen XML wird der Ex- und Import von vollständigen und unvollständigen Programmen, POUs oder Funktionen unterstützt.

4  Verhaltensbeschreibung mit PLCopen XML

155

• Bei der Speicherung von Programmen in den grafischen Sprachen der IEC 61131-3 kann neben den logischen Verknüpfungen der einzelnen Elemente auch ihr grafisches Layout gespeichert werden. So können zum Beispiel die Positionen von Objekten in den Arbeitsblättern oder Verbindungslinien zwischen Objekten gespeichert werden. Ein Beispiel für die Verwendung von PLCopen XML ist in Abb. 4.12 als FBDNetzwerk abgebildet, in dem ein Multiplexerbaustein MUX integriert ist. Es zeigt ein zugehöriges FBD-Netzwerk nebst PLCopen-XML-Code. Der Übersichtlichkeit halber sind im XML-Ausschnitt des Beispiels nur die logischen Informationen

Abb. 4.12   PLCopen-XML-Darstellung von „MUX“

156

L. Hundt et al.

des Bausteins MUX wiedergeben. Ausführlichere Beispiele sind in der Spezifikation enthalten oder können auf der Homepage der PLCopen entnommen werden (PLCopen 2009). Ziel von AutomationML ist die durchgängige Weiternutzung von Planungsdaten aus frühen Engineering-Phasen bis hin zum Steuerungsentwurf. AutomationML verwendet PLCopen XML als Mittel zur Speicherung und zum Austausch von Verhaltensbeschreibungen. PLCopen XML wurde als Datenformat zum Speichern und Austauschen von ablauffähigen Steuerungs-Programmen der IEC 61131-3 entwickelt. Im Rahmen von AutomationML ist diese Implementierungsnähe jedoch weniger von Bedeutung – AutomationML zielt vor allem auf die Abbildung grober Planungsdaten aus frühen Planungsphasen, die erst später verfeinert werden. Beschreibungsmittel wie Gantt Charts oder Impuls-Diagramme werden dabei in SFCs übersetzt, die jedoch noch weit von realem oder ablauffähigem Steuerungs-Code entfernt sein können. Sie sind Basis für den Steuerungstechniker, der diese SFCs automatisch in seine Steuerungssoftware importieren, dort um Signale anreichern und schrittweise in lauffähige Schrittketten im Zielsystem weiterentwickeln kann. Auf diese Weise wird mit AutomationML eine durchgängige Wiederverwendung von steuerungsrelevanten Planungsdaten über mehrere Planungsphasen hinweg möglich. Für die Abbildung von logischen Netzwerken werden zusätzlich FBDs verwendet. Diese lassen sich durch die Verwendung von PLCopen-XML-FBD als Grundlage zur Implementierung von Verriegelungs- und Weiterschaltbedingungen für die Anlagenprogrammierung verwenden, ohne die Sprache wechseln zu müssen. Die übrigen Sprachen der IEC 61131-3 werden von AutomationML derzeit nicht verwendet: der herstellerunabhängige Austausch von beliebigen Steuerungsprogrammen ist bislang kein Ziel von AutomationML. Der Hauptfokus von AutomationML liegt im Austausch der Daten, nicht in der Implementierungsnähe oder Ablauffähigkeit. Verhaltens- und Ablaufbeschreibungen aus frühen EngineeringPhasen sind aber bereits mit PLCopen XML als SFC abbildbar. AutomationML muss allerdings mehr Logik-Daten speichern, als mit dem Standardumfang von PLCopen XML abbildbar sind, beispielsweise komplexe Zeitinformationen. Diese benötigten Zusatzdaten, die als Erweiterungen in PLCopen XML eingebunden werden können. Ihre Modellierung wird im folgenden Abschnitt erläutert.

4.3.2  Das AutomationML addData-Schema Um eine verlustfreie Hin- und Rücktransformation zwischen einer der Beschreibungsmittel und PLCopen XML zu ermöglichen, müssen in PLCopen XML zusätzliche Daten gespeichert werden. Immerhin werden im Engineering-Prozess die verschiedenen Schritte des Anlagenablaufes mit Zusatzinformationen versehen, die sich im resultierenden SPS-Programm nicht immer beziehungsweise nur versteckt wiederfinden. Diese Informationen gehen in die Transformation nach PLCopen

4  Verhaltensbeschreibung mit PLCopen XML

157

XML zwar ein, werden allerdings dabei so reduziert, dass eine Rücktransformation nicht mehr eindeutig möglich ist. Beispiele hierfür sind komplexe Zeitinformationen, wie sie in PERT Charts verwendet werden, vordefinierte Zustandsübergänge in Impuls-Diagrammen oder Hierarchieinformationen in State Charts. Diese ZusatzDaten gehen über das ursprüngliche PLCopen-XML-Schema hinaus und müssen deshalb dort ergänzt werden. AutomationML greift an dieser Stelle auf einen Mechanismus zurück, den PLCopen XML ab der Version 2.0 für solche Fälle standardmäßig bereitstellt: Benutzerdefinierte Daten können mit dem Element ergänzt werden. Sie können als eigenes nutzerdefiniertes Schema formuliert und mittels innerhalb von PLCopen XML zugeordnet werden, ohne die Konformität zu PLCopen XML zu verlieren. Der Anwender muss allerdings selbst darauf achten, dass die zusätzlichen Daten zu den in PLCopen XML abgelegten konsistent sind. Für Werkzeuge, die diese Zusatzdaten nicht interpretieren können, stellt PLCopen XML drei prinzipielle Möglichkeiten zur Verfügung. • Das Werkzeug verwirft die Zusatzdaten. • Das Werkzeug lässt die Zusatzdaten unverändert und behält sie beim Export bei. • Dem Werkzeug wird freigestellt, ob die Zusatzdaten entsprechend der Konfiguration des Importes verworfen oder beibehalten werden. Im Folgenden wird das Prinzip zur Einbindung zusätzlicher Daten erläutert. Anschließend werden das im Rahmen von AutomationML entwickelte Schema und dessen Einbindung beschrieben. Zunächst muss das benötigte nutzerdefinierte Schema an zentraler Stelle deklariert werden. Hierzu ist über den Tag im Header der PLCopen-XML-Datei ein eindeutiger Name festzulegen und die Organisation oder Firma zu benennen, die das Schema bereitstellt. Zusätzlich besteht die Möglichkeit, eine Versionsnummer des Sub-Schemas anzugeben und über das Element eine zusätzliche Beschreibung abzulegen. Das konkrete Einbinden der zusätzlichen Daten ist dann an nahezu jeder Stelle des PLCopen-XML-Dokumentes über den Tag möglich. Über das Attribut name sind die zusätzlichen Daten mit dem Informationsdatum im Header verknüpft. Das Attribut handleUnknown gibt die oben erwähnte Verhaltensanweisung für den Fall an, dass ein Tool die Daten beziehungsweise das Schema nicht verarbeiten kann. Das Einbinden von wird in Abb. 4.15 anhand eines Beispieles erläutert. Das in Abb. 4.13 abgebildete AutomationML-addData-Schema für PLCopen XML modelliert die für AutomationML relevanten Zusatzinformationen als XMLElemente. Diese sind weitestgehend optional und bei Bedarf zu verwenden. Die Benutzung der einzelnen Elemente hängt von der jeweiligen Diagrammform und dem konkreten Anwendungsfall ab. Die folgende Tabelle (siehe Tab. 4.1) gibt einen Überblick über diese Elemente und beschreibt typische Anwendungsfälle. Das addData-Schema von AutomationML

158

L. Hundt et al.

Abb. 4.13   addData XML-Schema für PLCopen XML

für PLCopen XML kann von der AutomationML-Homepage bezogen werden (AutomationML 2009). Die Nutzung des AutomationML addData-Schemas soll im Folgenden anhand eines Beispiels erläutert werden. In diesem wird an eine Aktion eines in PLCopen XML gespeicherten SFCs die zusätzliche Information angefügt, ob diese bis zum Ende ausgeführt werden soll oder ob die Aktion beim Verlassen des zugeordneten Schrittes beendet wird. Die zusätzlichen Informationen werden dabei im Element an den entsprechenden Stellen der PLCopen-XML-Dateien abgelegt. Im Element wird spezifiziert, nach welchem XML-Schema diese strukturiert sein müssen. Es besitzt dazu das Attribut name, welche einen eindeutiger Bezeichner zur Identifizierung in Form einer URI angibt. Die URI muss hierbei den Domainnamen des Schema-Autors beinhalten beziehungsweise der Ort angeben, wo das Schema zu finden ist. Wie die Deklaration des addData-Schemas innerhalb eines PLCopen-XML-Dokumentes erfolgt, zeigt Abb. 4.14.

4  Verhaltensbeschreibung mit PLCopen XML

159

Tab. 4.1   Elemente des AutomationML addData-Schemata Element Anwendungsfall/ Beschreibung Elternelement Aktion Beschreibung erweiterter Zeitinformationen

Aktion Dauer einer Aktion

Aktion Frühester Start einer Aktion

Aktion Spätester Start einer Aktion

Aktion Frühestes Ende einer Aktion

Aktion Spätestes Ende einer Aktion

Aktion Wartezeit

(Initial-)Schritt Ursprünglicher Diagrammtyp;

Mögliche Werte sind: StateChart, impulseDiagram; sequencialFunctionChart, pertChart, ganttChart

Aktion Zeigt an ob eine Aktion unterbrochen wird,

wurde, oder bis zum Ende ausgeführt wird (run to completion) Schritt Definiert, aus welchen Zustandstypen im Zu­

Definiert, aus welchen Zustandstypen im Zu­

Schritt Definiert, welchen Status ein Zustand im Zu­

standsdiagramm hatte Aktion Definiert, welchen Status ein Aktion im Zu­

standsdiagramm hatte

Zur Beschreibung der Information, ob eine Aktion unterbrechbar ist, wird laut Spezifikation das Element genutzt, vergleiche auch Abb. 4.13. Im betrachteten Beispiel wird die zusätzliche Information an die Aktion mit dem Namen Interruptable angefügt. In dem in Abb. 4.15 illustrierten Beispiel ist die Aktion nicht unterbrechbar, da der Wert des Attributes false ist.

Abb. 4.14   Deklaration des AutomationML addData-Schemas in einem PLCopen-XMLDokument

160

L. Hundt et al.

Abb. 4.15   Beispiel für addData-Schema

4.4  Der Intermediate Modelling Layer IML 4.4.1  Motivation Während der Entwurfsphase von Produktionsanlagen wird eine Vielzahl unterschiedlicher Beschreibungsmittel zur Definition des gewünschten Verhaltens einer Anlage verwendet. Um diese während der Planung möglichst einfach nach PLCopen XML konvertieren zu können, ist die Definition einer Abstraktionsschicht sinnvoll. Diese wird in AutomationML als Intermediate Modelling Layer oder kurz IML eingeführt. Die Motivation für IML ist die Tatsache, dass AutomationML nur einen kleinen Ausschnitt von PLCopen XML benötigt. IML ist ein Datenmodell, welches genau diesen Ausschnitt umfasst. IML ist deshalb keine zusätzliche Modellierungssprache, sondern als vereinfachte Untermenge von PLCopen XML zu verstehen. Mit IML ist es nicht mehr nötig, für jedes einzelne Beschreibungsmittel die komplexen Übersetzungsregeln nach PLCopen XML zu implementieren; stattdessen müssen nur wenige Transformationsregeln umgesetzt werden. Die Transformation von Gantt Charts usw. nach IML ist deutlich einfacher zu implementieren als direkt nach PLCopen XML. Zugehörige Transformationsregeln werden in diesem Abschnitt vorgestellt. Die anschließende Konvertierung von IML nach PLCopen XML wird ebenfalls durch Transformationsregeln beschrieben und muss nur ein einziges Mal implementiert werden. Durch dieses Konzept wird die Konvertierung unterschiedlicher Beschreibungsmittel nach PLCopen XML insgesamt deutlich vereinfacht (siehe Abb. 4.16). IML erleichtert die Programmierung von Konvertern auch für neue Beschreibungsmittel, die künftig in die Logikbeschreibung von AutomationML aufgenommen werden. Ein weiterer Vorteil von IML ist die erhöhte Flexibilität bei Änderungen im Zielformat. Hierfür müssen dann nur die jeweiligen Abbildungsvorschriften zwischen IML und PLCopen XML angepasst werden. Ein zusätzlicher Vorteil besteht darin, dass auf Basis von IML eine erleichterte Konsistenzprüfung während

4  Verhaltensbeschreibung mit PLCopen XML

161

Abb. 4.16   Das Intermediate Modelling Layer IML

der Übersetzung zwischen den einzelnen Modellen erfolgen kann. Mit IML ist es zudem möglich, ähnliche Modellierungskonstrukte wie zum Beispiel Gantt Balken und PERT Knoten aufeinander abzubilden. Solche Ähnlichkeiten lassen sich somit identifizieren und ihre Relationen zueinander in beiden Modellarten überprüfen. Die Nutzung vom IML ist übrigens nur eine Implementierungs-Empfehlung, aber keine zwingende Voraussetzung für die Anwendung von PLCopen XML im Kontext von AutomationML. Eine direkte Konvertierung nach PLCopen XML führt ebenfalls zu konformen AutomationML-Daten.

4.4.2  IML-Modellelemente IML besteht aus einem Satz einfacher Modellelemente, mit deren Hilfe logische Abläufe generisch beschrieben werden können. Der Aufbau und die genutzten Element von IML ähneln der SFC Definition in der IEC 61131-3, sind jedoch erweitert, um alle in AutomationML betrachteten Anwendungsfälle abzudecken. Die drei zentralen IML-Elemente sind State, Activity und State Transition. Ein einfaches IML-Modellbeispiel ist Abb. 4.17 dargestellt. Hier wird eine Transition Transition_ 1 beschrieben, welche den Übergang vom Zustand State_1 nach State_2 beschreibt. Im Zustand State_2 wird eine Aktion Action_2 ausgeführt. Es wird deutlich, dass das Datenmodell IML eine direkte Abbildung von SFC Strukturen ermöglicht.

Abb. 4.17   Ein einfaches IML-Modell

162

L. Hundt et al.

Tab. 4.2   Elemente von IML IML Element Bedeutung Ein State beschreibt eine stabile Situation innerhalb eines Systems/Teilsystems, in der eine bestimmte Kombination aus Systemparametern gültig ist. Diese Parameter können durch die Ausführung von Aktivitäten, Events oder durch Werte der Systemvariablen ausgedrückt werden. States werden über state transitions erreicht und verlassen. Besondere states sind initial, current und terminal states State Transition Eine State Transition beschreibt den Übergang von einem oder mehreren states in einen oder mehre Folge-states unter Berücksichtigung ihrer Transitionsbedingungen Activity Eine Activity beschreibt eine oder mehrer Operationen, die einem bestimmten State zugeordnet sind. Sie wird durch benötigte und zu verändernde Variablenwerte charakterisiert, wie auch durch das „Feuern“ von Ereignissen nach ihrer Ausführung. Spezielle Activities sind initial, current und terminal activities. Analog zu SFCs dürfen auch in IML Activities nur States, nicht aber State Transitions zugeordnet werden Header Der Header dient zur Beschreibung eines IML-Systems. Er besitzt eine ID, einen Namen, welcher äquivalent zum Namen des IML-Systems ist und eine Relation zu allen Elementen, die im beschrieben System enthalten sind Jump Ein Jump ist eine zusätzliche Repräsentation eines States. Seine Aktivierung führt zur Einnahme des zugeordneten States Selection Divergence Eine Selection Divergence ist eine logische Verbindung zwischen einem Vorgänger-State beziehungsweise entsprechenden Verzweigungen und Zusammenführungen und zwei oder mehr nachfolgenden State Transitions. Dabei ist die Relation zwischen den Nachfolger-State-Transitions eine XOR-Relation zur Beschreibung alternativer Abläufe Simultaneous Diver- Eine Simultaneous Divergence ist eine logische Verbindung zwischen gence einer Vorgänger-State-Transition und zwei oder mehr nachfolgenden States beziehungsweise entsprechenden Verzweigungen und Zusammenführungen. Dabei ist die Relation zwischen den Nachfolger-States eine AND-Relation zur Beschreibung paralleler Abläufe Selection Convergence Eine Selection Convergence ist eine logische Verbindung zwischen zwei oder mehr Vorgänger-State-Transitions und einem Nachfolger-State beziehungsweise einer entsprechenden Verzweigung oder Zusammenführung. Dabei stehen die Vorgänger-State-Transition in einer XORRelation und somit in alternativen Abläufen Simultaneous Conver- Eine Simultaneous Convergence ist eine logische Verbindung zwischen gence zwei oder mehr Vorgänger-States beziehungsweise entsprechenden Verzweigungen und Zusammenführungen und einer Nachfolger-State-Transition. Dabei stehen die Vorgänger-States in einer AND-Relation und somit in parallelen Abläufen Event Ein Event wird von einer Activity gesendet, der es zugeordnet ist. Events können als Trigger für State Transitions genutzt werden Variable Eine Variable ist ein Modellelement, das States und Activities charakterisiert. Ihre Werte können durch Aktivitäten verändert werden. Sie können als Trigger für State Transition dienen oder als Systemeingang-bzw. -ausgang genutzt werden Comment Ein Comment wird zur Ergänzung von beschreibenden Informationen genutzt

State

4  Verhaltensbeschreibung mit PLCopen XML

163

Tab. 4.2  (Fortsetzung) IML Element Bedeutung addData

Additional Data erlaubt die Speicherung und Weitergabe von zusätzlichen Informationen, die über die SFC-Definitionen der IEC 61131-3 und deren Repräsentation im IML hinausgehen. Ein Beispiel hierfür sind komplexe Zeitinformationen. Die Syntax für Additional Data ist in AutomationML Logic Definition (2009) spezifiziert und wird in Abschnitt 4.3.2 näher erläutert

Neben den drei beschrieben Basis-Elementen beinhaltet IML weitere Elemente, die States, Activities und State Transitions in Relation zueinander setzen, beziehungsweise diese näher spezifizieren. Alle Elemente von IML werden dabei über Vorgänger – Nachfolgerrelationen miteinander verknüpft und können über eine eindeutige ID identifiziert werden. Ausnahmen sind Comments und Events, die keine ID benutzen, sondern Elementen zugeordnet werden. In Tab. 4.2 sind die IML-Elemente zusammenfassend dargestellt.

4.4.3  IML-Definition und Klassendiagramm Aus den in der Tab. 4.2 beschriebenen Daten-Elementen können IML-Systeme zur Beschreibung von Logikabläufen aufgebaut werden. Dementsprechend definiert AutomationML ein IML-System wie folgt: Ein IML-System ist ein Satz von IML-Elementen inklusive ihrer Relationen zueinander, die zur Beschreibung von Verhaltensinformationen genutzt werden. IML-Systeme müssen nicht vollständig definiert sein und können andere IML-Systeme referenzieren. Abbildung 4.18 zeigt das vollständige Datenmodell von IML als Klassendiagramm inklusive aller genannten IML-Elemente mit ihren Attributen und Beziehungen. Eine ausführlichere Beschreibung erfolgt in AutomationML.L (2009). Ein weiteres IML-Beispiel wird in Abb. 4.19 dargestellt, welches die wichtigsten IML-Elemente enthält und die genannten AutomationML spezifischen Zusatzinformationen abbildet.

4.4.4  Transformation von Gantt Charts nach IML Bei der Transformation von Gantt Charts nach IML wird das kausale und zeitliche Verhalten der Gantt-Elemente in IML-Modellelemente übertragen. Wie in Abschnitt 4.2.3 dargestellt, sind die wichtigsten Modellelemente von Gantt Charts Balken, die in einer Vorgänger/Nachfolger-Beziehung stehen können und die einen Startund Endzeitpunkt sowie eine Dauer besitzen. Diese müssen in entsprechende IMLElemente unter Beibehaltung der Strukturinformationen übersetzt werden. Grundsätzlich sind dabei folgende Schritte auszuführen: Jeder Balken eines Gantt Charts

164

L. Hundt et al.

Abb. 4.18   Datenmodell des IML

wird durch eine Activity im IML-System abgebildet. Vorgänger/Nachfolger-Beziehungen zwischen Balken werden durch eine State Transition im IML-System beschrieben. Temporalen Eigenschaften der Gantt Charts werden über den Aktivierungszeitpunkt der IML Activities und deren Zeitverhalten abgebildet. Im Ergebnis wird jedes Gantt Chart in ein eigenes IML-System übersetzt. Gemäß diesen Grundprinzipien wird aus jedem Gantt Chart ein Netzwerk von IML-States, zugehörigen IML-Activities und IML-State-Transitions gebildet. Eine Ausführung dieses Netzwerkes nach SFC-Regeln führt zur Beschreibung der kausalen und temporalen Abhängigkeiten der Gantt Balken. Im Einzelnen gelten die folgenden Detail-Übersetzungsregeln: 1. Jedes Gantt Chart wird in ein eigenes IML-System übersetzt, das einen eindeutigen Initial-State besitzt. Diesem folgt im Falle von mehr als einem Gantt Balken

4  Verhaltensbeschreibung mit PLCopen XML

165

Abb. 4.19   Einfaches Beispiel eines IML-Systems

ohne Vorgänger eine Simultaneous Divergence sowie für jeden Gantt Balken ohne Vorgänger eine State Transition mit der Schaltbedingung TRUE. 2. Jeder Gantt Balken wird in einen IML-State, eine IML-State-Transition und zwei Activities übersetzt (siehe Abb. 4.20). Eine der beiden Activities dient mit ihrem Aktivierungsverhalten der direkten Abbildung der zeitlichen Eigenschaften des Gantt Balken. Die zweite Activity dient als Aktivator der Weiterschaltbedingung für die State Transition, vgl. Abb. 4.20 und 4.21. 3. Jede Vorgänger/Nachfolger-Beziehung zwischen zwei Gantt-Balken wird durch eine Vorgänger/Nachfolger-Beziehung zwischen den durch Regel 2 gebildeten IML-Repräsentanten beider Balken übersetzt, siehe Abb. 4.21. Besitzt ein Gantt Balken keine Vorgänger, so wird als Vorgänger der Startschritt gemäß 1. festgelegt. Verzweigen sich Vorgänger/Nachfolger-Beziehungen, so wird dies im IMLSystem durch die Nutzung von Simultaneous Divergences und Simultaneous Convergences beschrieben. Besitzen zwei unterschiedliche Gantt Chart Balken einen gemeinsamen Nachfolger-Balken, wird die notwendige Synchronisation der beiden Vorgängerschritte durch je einen zusätzlichen Synchronisations-State ausgedrückt. 4. Die zeitlichen Eigenschaften von Gantt Balken werden über die zeitlichen Bedingungen der beiden IML-Activities repräsentiert. Dabei bildet eine der beiden

166

L. Hundt et al.

Abb. 4.20   Übersetzung eines Gantt-Chart-Balken nach IML

Abb. 4.21   Übersetzung einer Vorgänger/Nachfolger-Beziehung nach IML

Activities in ihrem Aktivierungsverhalten die zeitlichen Eigenschaften des Gantt Chart Balken ab. Sie besitzt eine Einschaltverzögerung gegenüber dem Aktivierungszeitpunkt des State. Die zweite Aktivität besitzt eine Dauer (duration), die zu einer Ausschaltverzögerung des State über die State Transition genutzt wird. Dabei wird die erste Aktivität deaktiviert. Dies ist in Abb. 4.22 dargestellt.

Abb. 4.22   Übersetzung des Zeitverhaltens nach IML

4  Verhaltensbeschreibung mit PLCopen XML

167

Abb. 4.23   Übersetzung des Endschritts nach IML

5. Jedes gültige IML-System, das ein Gantt Chart beschreibt, besitzt einen eindeutigen Endschritt. Dieser wird an die gemäß 2. entstandenen State Transitions der Schritte ohne Nachfolgerbalken angehängt (siehe Abb. 4.23). Sollte ein Gantt Chart mehr als einen Balken ohne Nachfolgerbalken besitzen, so ist dafür eine Simultaneous Convergence zu verwenden, der wiederum Synchronisationsschritte vorgelagert werden müssen. In Abb. 4.24 ist eine Beispieltransformation dargestellt. Eine detaillierte Definition der Transformationsregeln wird in AutomationML.L (2009) beschrieben.

4.4.5  Transformation von PERT Charts nach IML PERT Charts ähneln den Gantt Charts, daher erfolgt ihre Übersetzung in vergleichbarer Weise. Unter bestimmten Voraussetzungen ist zudem eine automatische Übersetzung von Gantt nach PERT und umgekehrt realisierbar. In Analogie zu Gantt Charts müssen zur Übersetzung von PERT Charts nach IML die PERT-Knoten sowie die Vorgänger/Nachfolger-Beziehung übersetzt werden. Dabei wird vorausgesetzt und bei der Übersetzung in ein IML-System geprüft, dass die angegebenen Zeitwerte ein sinnvolles Zeitsystem bilden. Dazu müssen: • die jeweiligen frühesten beziehungsweise spätesten Startzeitpunkte vor den entsprechenden Endzeitpunkten eines Knoten liegen, • die Dauer einer Aktivität kleiner als die Differenz zwischen End- und Startzeitpunkt sein, und • der Startzeitpunkt eines Folgeknotens größer als der Endzeitpunkt seiner Vorgängerknoten sein. Zur Transformation werden folgende grundsätzliche Schritte ausgeführt: jeder Knoten eines PERT Charts wird durch eine IML-Activity abgebildet. Vorgänger/Nachfolger-Beziehungen zwischen Knoten werden in eine State Transition überführt. Zeitinformationen der PERT Charts werden über die zeitlichen Eigenschaften der

168

Abb. 4.24   Transformationsbeispiel Gantt Chart nach SFC

L. Hundt et al.

4  Verhaltensbeschreibung mit PLCopen XML

169

Abb. 4.25   Übersetzung einer PERT-Chart-Aktivität nach IML

IML-Activities und zusätzlichen -Elementen an den Activities abgebildet. Im Ergebnis entsteht aus jedem PERT Chart ein eigenes IML-System. Damit entspricht das Übersetzungsergebnis weitestgehend der Struktur, die bei der Übersetzung von Gantt Charts entsteht. Auf eine detailliertere Beschreibung der Übersetzungsregeln soll an dieser Stelle verzichtet werden: bei den Transformationsregeln muss im Prinzip der Begriff Gantt-Balken lediglich durch PERT-Knoten ausgetauscht werden. Dies wird in Abb. 4.25 deutlich. Der einzige umfassende Unterschied zur Transformation von Gantt Charts ergibt sich aus der Notwendigkeit, die zusätzlichen Zeitinformationen der PERT Charts abzubilden. IML basiert auf Sequential Function Charts der IEC 61131-3, die gegenüber den PERT Charts nur eingeschränkte Möglichkeiten zur Beschreibung des Zeitverhaltens bieten. Es ist mit ihnen nur mit aufwändigen Strukturen möglich, das Zeitverhalten von PERT Charts direkt abzubilden. Das aus der Transformation von PERT Charts resultierende SFC entspricht in seinem Zeitverhalten folglich nicht dem des PERT Charts. Die fehlenden Informationen sind jedoch mittels vollständig repräsentiert. Im Einzelnen gelten für die Übersetzung von Zeitinformationen in PERT Charts folgende Regeln: • Die zeitlichen Eigenschaften von PERT-Knoten werden über die zeitlichen Bedingungen der beiden IML-Aktivitäten zum PERT-Knoten abgebildet. • Zusätzliche Zeitinformationen werden zum Teil über ein -Element repräsentiert. Dabei werden der früheste Anfangszeitpunkt eines Knoten und seine Dauer mittels der beiden in Abb. 4.25 dargestellten IML-Aktivitäten in Analogie zu Gantt Charts abgebildet. Die weiteren Zeitpunkte und Dauern des PERT-Knotens werden mit Hilfe eines -Elements übersetzt, welches an die erste Aktivität gebunden ist. Die hier beschriebenen Übersetzungsregeln sind in AutomationML.L (2009) detailliert zusammengestellt. In Abb. 4.26 wird anhand eines Beispieles gezeigt, wie die Transformation von PERT Charts nach IML erfolgt.

4.4.6  Transformation von Impuls-Diagrammen nach IML Auch die Transformation von Impuls-Diagrammen in IML-Systeme erfolgt auf Basis derselben Prinzipien wie bei der Übersetzung von Gantt oder PERT Charts. So

170

L. Hundt et al.

Abb. 4.26   Transformationsbeispiel PERT Diagramm nach SFC

wird die zeitliche Abfolge der Zustände (Resource States) und Zustandsübergänge (Resource State Changes) innerhalb eines Impuls-Diagramms durch eine Sequenz von IML-States mit dazugehörigen IML-Transitions und IML-Activities abgebildet. Die Begriffe sind in den Abschnitt 4.2.6 und 4.4.2 erläutert. Da Impuls-Diagramme zu den Signalfluss-Diagrammen gehören, muss neben der zeitlichen Abfolge der Zustände zusätzlich der Signalfluss in IML abgebildet

4  Verhaltensbeschreibung mit PLCopen XML

171

werden. Hierzu werden die Signalflüsse aus den Impuls-Diagrammen in IML-Activities transformiert. Eine weitere Herausforderung bei der Transformation von Impuls-Diagrammen ist die strukturelle Überführung in SFC-ähnliche IML-Systeme. Um eine einheitliche Überführung zu gewährleisten, ist ein fester Rahmen für die IML-Repräsentation der Impuls-Diagramme definiert. Prinzipiell werden hierfür folgende Schritte benötigt: Jedes Impuls-Diagramm wird in ein IML-System übersetzt. Dieses besitzt als Ausgangspunkt einen festen Rahmen aus einem initialen Zustand, einem initialen Zustandsübergang und einer darauf folgenden Simultanverzweigung. Der Simultanverzweigung folgen mehre parallele Zweige, die jeweils eine Folge aus Zuständen und Zustandsübergängen darstellen. Dabei repräsentiert ein Zweig die Timeline des Impuls-Diagramms. Alle weiteren Zweige repräsentieren jeweils den Resource State Flow einer Resource. Eine Simultankonvergenz, ein Zustandsübergang und ein Endzustand bilden den Abschluss jeder Impuls-DiagrammÜbersetzung. Im Detail gelten folgende Transformationsregeln:   1. Die Übersetzung eines Impuls-Diagramms nach IML erfordert einen initialen IML-State, eine darauf folgende IML-Transition und eine IML-SimultaneousDivergence als Ausgangspunkt des IML-Systems. Die Schaltbedingung für diese Transition ist dabei TRUE.   2. Die Timeline und alle im Impuls-Diagramm aufgeführten Resources werden durch einen Parallelzweig im IML-System abgebildet. Dabei beschreibt jeder dieser Zweige jeweils den Resource State Flow der zugehörigen Resource.   3. Ein Resource State Flow wird in eine Sequenz aus IML-States und IML-Transitions übersetzt.   4. Sowohl Resource States als auch Resource State Changes werden jeweils durch eine IML-Activity repräsentiert. Sie können IML-States in dem zur Resource gehörigen Zweig zugeordnet werden.   5. Vorgänger/Nachfolger-Beziehungen zwischen Resource States und Resource State Changes innerhalb eines Signalverlaufes werden in eine Folge von IMLStates und IML-Transitions überführt (siehe Abb. 4.27).

Abb. 4.27   Übersetzung eines Resource State Flow nach IML

172

L. Hundt et al.

  6. Die Zeitachse wird als eine Sequenz von IML-States im Zeitlinienzweig des IML-Systems abgebildet.   7. Jeder Resource State Change muss in der IML-Repräsentation durch ein Signal getriggert werden. Diese werden durch boolesche Werte innerhalb einer Transitionsbedingung ausgedrückt.   8. Resource State Changes besitzen eine bestimmte Dauer, die in der zugeordneten Activity abgebildet wird. Diese Dauer kann den Wert Null annehmen. Am Ende eines Resource State Changes wird immer ein Signal ausgelöst, welches als Übergangsbedingung zum Erreichen des nachfolgenden Resource States oder Resource State Changes im IML genutzt wird.   9. Signale können zu jedem Zeitpunkt ausgelöst werden. Typische Auslöser sind z. B. externe Signale, eine Resource, das Ende eines Resource State Changes oder die Beendigung der Verweildauer in einem Resource State (siehe Abb. 4.28). 10. Das Senden von Signalen nach einem Resource State Change wird durch eine IML-Activity abgebildet, die dem dazugehörigen IML-State zugeordnet ist. 11. Jedes Feuern eines Signals aus der Zeitlinie wird durch einen IML-State und eine zugehörige IML-Activity ausgedrückt. 12. Jedes IML-System eines Impuls-Diagramms enthält eine abschließende IMLSimultaneous-Convergence, eine abschließende IML-State-Transition und einen abschließenden IML-State. Dabei wird das Weiterschalten der IMLTransition immer durch ein externes Endsignal ausgelöst. In Abb. 4.29 ist ein Beispiel für die beschrieben Übersetzungsprinzipien von Impuls-Diagrammen dargestellt.

Abb. 4.28   Signale in Impuls-Diagrammen

4  Verhaltensbeschreibung mit PLCopen XML

Abb. 4.29   Darstellung eines Impuls-Diagramms in IML

173

174

L. Hundt et al.

Das abgebildete Signal kann zwei Zustände einnehmen, dies wird im IML-System in zwei parallele Zweige übersetzt. Änderungen innerhalb des Signalverlaufs werden jeweils durch ein externes Signal angestoßen. Für eine detaillierte Beschreibung der Übersetzungsprinzipien für Impuls-Diagramme sei an dieser Stelle auf AutomationML.L (2009) verwiesen. Diese enthalten neben einer formalen Spezifikation auch weiterführende Beispiele.

4.4.7  Transformation von State Charts nach IML State Charts werden gerne zur Beschreibung wiederkehrender Verhaltensweisen von Anlagen, Produktionsprozessen oder Automatisierungseinrichtungen verwendet. Dies erfolgt beispielsweise in frühen Engineering-Phasen, aber auch für die virtuelle Inbetriebnahme. Für AutomationML sind sie deshalb ein sinnvolles Mittel zur Darstellung zyklischen Verhaltens. Da auch Steuerungen zyklisches Verhalten aufweisen, lassen sich State Charts für die Entwicklung von lauffähigem und zyklischem Steuerungscode gut wiederverwenden. State Charts bestehen aus Zuständen und Zustandsübergängen und erlauben die Modellierung von kausalen Zusammenhängen zwischen den Zuständen. Zudem ermöglichen State Charts die Beschreibung hierarchischer Strukturen von Systemzuständen und von Nebenläufigkeiten von Zuständen und Zustandsübergängen. Bei der Transformation von State Charts nach IML führen diese grundlegenden Eigenschaften dazu, dass sie im Gegensatz zu den bisher beschriebenen Transformationen nicht ein einziges IML-System ergeben, sondern mehrere miteinander verknüpfte IML-Systeme. Damit werden Hierarchien und Nebenläufigkeiten von Zustandsmaschinen abbildbar. Die Transformation von State Charts in IML folgt dementsprechend folgenden Grundregeln: Zustände werden mit IML-States abgebildet. Zustandsübergänge werden mit IML-State-Transitions dargestellt. Aktivitäten entsprechen IML-Activities. Ein übergeordneter Zustand mit seinen Unterzuständen wird mit einem IML-State sowie je einem IML-System für jeden Sub-State-Chart abgebildet. Dabei referenzieren alle IML-Systeme der Sub-StateCharts auf den übergeordneten IML-State. Auf diese Weise können Hierarchien und Nebenläufigkeiten von State Charts ausgedrückt werden. Das Ergebnis einer solchen Transformation ist eine Menge von IML-Systemen aus IML-States, -State-Transitions und -Activities. Die Übersetzung der kausalen Zusammenhänge der Zustände und Zustandsübergänge des State Charts erfolgt durch die Vorgänger/Nachfolger-Beziehungen der IML-States und -State-Transitions innerhalb der einzelnen IML-Systeme. Die Übersetzung der hierarchischen Zusammenhänge zwischen IML-Zuständen dagegen erfolgt über Elemente, die eine Referenzierung zwischen IML-States und IML-Systemen ermöglichen. Im Gegensatz zu Gantt oder PERT Charts besitzen State Charts keinen expliziten Zeitbegriff, der demzufolge auch nicht übersetzt werden muss. Im Detail gelten folgende Transformationsregeln für die Abbildung flacher bzw. hierarchieloser State Charts:

4  Verhaltensbeschreibung mit PLCopen XML

175

1. Jeder Zustand wird in einen IML-State übersetzt. Ist ein Zustand ein initialer oder ein Endzustand, dann wird dies durch entsprechende Attribute des IMLState ausgedrückt. 2. Jede Aktivität eines Zustands wird als IML-Activity abgebildet, die dem zugehörigen IML-State zugeordnet ist. Ob eine Activity eine Eingangs-, Ausgangs- oder interne Aktion ist, wird über ein zugeordnetes -Element beschrieben. 3. Zustandsübergänge werden jeweils als IML-State-Transition abgebildet. Die enthaltene Übergangsbedingung wird dabei als Guard der IML-State-Transition zugeordnet. 4. Aktivitäten, welche einem Zustandsübergang zugeordnet sind, werden in IML durch Einfügen eines zusätzlichen IML-State, dem die entsprechende IML-Activity zugeordnet ist sowie einer zusätzliche IML-State-Transition abgebildet. 5. Ein Event wird als IML-Event abgebildet. 6. History und Condition Connectors werden in IML-States transformiert, die mit Hilfe eines -Elementes klassifiziert sind. Werden hierarchische State Charts verwendet, werden deren hierarchische Strukturen durch folgende Transformationsregeln überführt: 7. Jede zusammenhängende Menge von Zuständen und Zustandsübergängen eines State Charts, die derselben Stufe der Zustandshierarchie des State Charts angehört, wird als eigenes IML-System abgebildet. 8. Wenn ein State eines State Charts mehrere nebenläufige Unterzustände enthält, dann werden dieser und seine Unterzustände auf verschiedene IML-Systeme abgebildet. Ihre hierarchische Zusammengehörigkeit wird über Elemente ausgedrückt. 9. Zustandsübergänge, die Zustände verschiedener Hierarchieebenen verbinden, werden durch eine IML-State-Transition in beiden betroffenen IML-Systemen modelliert. Zusätzlich wird in dem IML-System, das die niedrigere Hierarchiestufe des State Charts repräsentiert, ein zusätzlicher IML-State eingeführt – er dient als Quelle beziehungsweise Ziel der dort enthaltenen State Transition. Ein Beispiel für die Anwendung dieser Transformationsregeln ist in Abb. 4.30 illustriert. Das abgebildete State Chart besteht aus drei Zuständen State 1, State 2 und State 3. State 1 ist hierarchisiert und besteht aus zwei Sub-State-Charts. Zur Transformation nach IML müssen alle drei State Charts durch ein eigenes IML-System beschrieben werden. Infolge der Hierarchien des State Charts besteht das Transformationsergebnis ebenfalls aus drei IML-Systemen. Die beiden grau hinterlegten IML-States sind durch die Transformationsregel 9 zur Abbildung von InterlevelTransitionen – das sind Transitionen zwischen Zuständen verschiedener Hierarchieebenen – entstanden.

176

Abb. 4.30   Transformation eines State Charts nach IML

L. Hundt et al.

4  Verhaltensbeschreibung mit PLCopen XML

177

4.4.8  Vergleich der Abbildungsvorschriften nach IML Die genannten Beschreibungsmittel verfolgen unterschiedliche Zwecke und decken verschiedene Informationen über das Anlagenverhalten ab. Dennoch können sie alle, wie in den vorstehenden Abschnitten erläutert, im gemeinsamen Datenmodell IML abgebildet werden. Eine vergleichende Betrachtung der Abbildungsvorschriften erfolgt in Tab. 4.3. Es wird ersichtlich, wie der grundsätzliche Transformationsweg von einer spezifischen Beschreibungssprache nach IML und zurück verläuft. Dies ist die Basis der anschließenden Transformation von IML nach PLCopen XML, die im nachfolgenden Abschnitt beschrieben wird. Ebenso wird aus der Tabelle deutlich, dass über den Umweg IML die Beschreibungsmittel teilweise ineinander überführt werden können. Dies hat jedoch Grenzen, die sich insbesondere aus der unterschiedlichen Modellierungsmächtigkeit der verschiedenen Beschreibungssprachen und die Menge der mit ihnen abbildbaren Informationen ergibt. Solange die zu speichernden Informationen in zwei Beschreibungssprachen gleichwertig abbildbar sind, ist eine Konversion zwischen beiden möglich. Im Folgenden einige Beispiele ohne Anspruch auf Vollständigkeit: • Jedes Gantt Chart kann in ein PERT Chart überführt werden. Dabei kann zum Beispiel jeder Gantt-Balken als PERT-Knoten aufgefasst werden. Die Zeiten der PERT-Knoten werden aus den Zeiten der Gantt-Balken berechnet. • Sind in einem PERT Chart die frühesten und spätesten Start- und Endzeiten eines Knotens jeweils gleich und entspricht ihre Differenz der Dauer des Knotens, so kann das PERT Chart in ein Gantt Chart überführt werden. • Jedes Impuls-Diagramm, das als externes Signal nur den Startzeitpunkt und keine logischen Verknüpfungen von Signalen besitzt, kann als Gantt oder PERT Chart dargestellt werden. • Gantt und Pert Charts können als Impuls-Diagramme dargestellt werden. Dazu müssen bei der Transformation lediglich das Ursprungsformat bekannt sein und strukturelle Unterschiede zwischen den Modellen beachtet werden. • Gemäß Definition können Gantt und Pert Charts, Impuls-Diagramme sowie State Charts direkt als SFCs weiter genutzt werden. Mit den Transformationen zwischen den Beschreibungssprachen ist damit insbesondere der wichtige Anwendungsfall möglich, dass Gantt-Charts zur Beschreibung des Grobablaufs aus ersten Planungsschritten in Impuls-Diagramme umgewandelt und mit detaillierteren Signal- und Ablaufinformationen angereichert werden, um dann selbst als SFCs zur Ergänzung um Schleifen und Fehlerbehandlung implementierungsnah verfügbar zu sein. Manche Transformationen können jedoch nur unter Informationsverlust ausgeführt werden. Beispiele dafür sind: • Jedes Gantt und PERT Chart kann als State Chart dargestellt werden. In State Charts sind Zeitinformationen allerdings nicht standardisiert und müssen als zusätzliche Information verfügbar gemacht werden.

Jump Variable Event Selection Divergence Simultaneous Divergences Selection Convergences Simultaneous Convergences Comment

State Transition Activity

PERT Charts

– – – Parallele Konten – – Kommentare

–

–

Kommentare

Knoten

– – – Parallele Balken

Gantt Charts

Balken

IML

State

Tab. 4.3   Abbildung der einzelnen Modellelemente auf IML Impuls Diagramm

Kommentare

–

–

Eingenommene Resource States; Ausgeführte Re­ source State Chan­ges Signals Resource States; Resource State Changes; Signals – – – Parallele Resource State Flows

State Charts

Kommentare

Connector

Connector

– Variable Event Parallele Subzustände

Zustandsübergang Aktivität

Zustand

Alternativ Zusammenfüh­ rung Kommentare

Alternativ Verzweigung

Sprung Variable – Parallel Verzweigung Parallel Zusammenführung

Transition Aktivität

Schritt

SFC nach IEC 61131

178 L. Hundt et al.

4  Verhaltensbeschreibung mit PLCopen XML

179

• Jedes Impuls-Diagramm kann als Gantt oder PERT Chart dargestellt werden. • Vorgänger/Nachfolgerbeziehungen lassen sich übertragen. Aufgrund der größeren Mächtigkeit von Impuls-Diagrammen können jedoch in Gantt Charts nicht abbildbare Informationen bei der Transformation verlorengehen, beispielsweise bedingte Abläufe • Jedes zyklenfreie State Chart kann als Gantt Chart dargestellt werden. Dabei gehen jedoch Schaltbedingungen der Übergänge und Aktionen verloren. Auch wenn eine Transformation zwischen den Beschreibungsmitteln nicht immer verlustfrei möglich ist, können die vorhandenen Transformationsmöglichkeiten sinnvoll im Engineering-Prozess genutzt werden.

4.4.9  Transformation von IML nach PLCopen XML Sind die Beschreibungsmittel erfolgreich mit IML abgebildet, müssen sie abschließend nach PLCopen XML transformiert werden. Dort werden sie als SFCs abgebildet. Dazu wird jedes einzelne Modellelement der IML so in Modellelemente von PLCopen-XML-SFC überführt, dass eine Rücktransformation eindeutig möglich ist. Dies kann jedoch nicht immer über eine Eins-zu-Eins Beziehung zwischen IMLund SFC-Elementen erfolgen. Ein gutes Beispiel dafür bildet die ID, die in jedem IML-Element enthalten ist. Sie wird auf die globale ID globalId jedes PLCopenXML-Elementes abgebildet. Die Verwendung der lokalen ID localID der einzelnen PLCopen-XML-Elemente wird hingegen bei der Transformation nicht festgelegt. Es wird nur gefordert, dass die in IML beschriebenen Vorgänger/Nachfolger-Beziehungen erhalten bleiben müssen. Alle nicht mit SFC-Konstrukten abbildbaren Teile werden über -Elemente gemäß Abschnitt 4.3.2 dargestellt. Die Übertragungsregeln sind durch die paarweisen Entsprechungen in Tab. 4.4 dargestellt: Tab. 4.4   Übertragungsregeln von IML nach SFC Regel IML   1.   2.   3.   4.   5.   6.   7.   8.   9. 10.

System mit Header State Transition Activity Jump Selection Divergence Simultaneous Divergence Selection Convergence Simultaneous Convergence Event Variable

11. 12.

Comment addData

SFC POU Transition Aktion im Aktionsblock Sprung Alternativ-Verzweigung Verzweigung Alternativ-Zusammenführung Simultan-Zusammenführung Variable des Datentyps Event Variable eines der IML Variable entsprechenden Datentyps Element Element

180

L. Hundt et al.

Abb. 4.31   Transformation von IML nach PLCopen XML

Die folgenden Abbildungen zeigen anhand mehrerer Beispiele, wie verschiedene IML-Elemente in PLCopen XML abgebildet werden. Die vollständigen Übersetzungsregeln für einzelne IML-Elemente und ihre Relationen zueinander werden in AutomationML.L (2009) beschrieben. Die Überführung der allgemeinen Struktur eines IML-Beispieles wird in Abb. 4.31 gezeigt. Die Übersetzung eines Schrittes erfolgt in Abb. 4.32.

4  Verhaltensbeschreibung mit PLCopen XML

181

Abb. 4.32   Transformation eines IML-Schrittes nach PLCopen XML

Die Transformation einer IML-Aktivität nach PLCopen XML wird in Abb. 4.33 dargestellt.

4.4.10  Vorgehensweise bei der Implementierung von IML Um die beschriebenen Transformationen zu implementieren, werden folgende Schritte empfohlen: 1. Zunächst muss das IML-Datenmodell gemäß Abb. 4.18 in einer Datenbank, einem XML-Schema oder einer anderen geeigneten Datenstruktur abgebildet werden. Die Implementierung des Datenmodells wird von AutomationML nicht vorgeschrieben, sondern dem Werkzeughersteller oder Anwender überlassen. 2. Für jedes einzelne Beschreibungsmittel muss je ein Konverter programmiert werden, der jeweils Gantt Charts, PERT Charts, Impuls-Diagramme, State Charts etc. nach IML übersetzt. Hierzu kommen die Transformationsregeln gemäß Abschnitt 4.4.4 bis 4.4.7. zur Anwendung.

182

L. Hundt et al.

Abb. 4.33   Transformation einer IML Aktivität nach PLCopen XML

3. Für die Transformation von IML nach PLCopen XML muss ein Transformator programmiert werden. Hierzu kommen die Transformationsregeln gemäß Abschnitt 4.4.9 zur Anwendung. Die genannten Schritte werden in Abschnitt 6.4 anhand einer Beispielimplementierung verdeutlicht.

4  Verhaltensbeschreibung mit PLCopen XML

183

4.5  Verriegelungslogik 4.5.1  Übersicht Neben der Beschreibung von sequentiellen Abläufen sind in Anlagensteuerungen auch Verriegelungen und Ausführungsbedingungen von Bedeutung. Hierunter versteht man logische Bedingungen, die Voraussetzungen für bestimmte Aktionen sind. Diese Bedingungen lassen sich als Netzwerk darstellen, beispielsweise als Funktionsplan. Ein klassisches Beispiel für Verriegelungslogik sind Arbeitsraumverriegelungen von Robotern; hier werden Arbeitsbereiche definiert, um Kollisionen zu vermeiden. So darf sich ein Roboter erst dann in einen Arbeitsbereich bewegen, wenn ein anderer Roboter den Bereich verlassen hat. Ein weiteres Beispiel sei aus dem Bereich der Fördertechnik angeführt: Ein Fördergut darf erst dann von einem Förderelement auf das nächste Element übergeben werden, wenn dieses nicht mehr belegt ist. Die Bedingungen Arbeitsbereich frei beziehungsweise Förderelement nicht belegt dienen hier als Verriegelungsbedingungen. In der Industrie dienen solche logischen Verknüpfungen nicht nur zur Sicherstellung des Arbeitsablaufes, sondern insbesondere auch der Personen- und Maschinensicherheit. Die Anlagenkomponenten dürfen nur dann laufen, wenn die geforderte Sicherheit gewährleistet ist. Im Gegenzug müssen die Anlagen in einen sicheren Zustand überführt werden, wenn die Sicherheits-Bedingungen verletzt werden. AutomationML bietet drei Detaillierungsstufen zur Beschreibung von Verriegelungsbedingungen, die aufeinander aufbauen können. • In der ersten Stufe erfolgt die Festlegung und Verschaltung von Signal- und Komponentengruppen: Verriegelungsbedingungen werden durch einen einfachen funktionalen Zusammenhang von Anlagenteilen festgelegt (siehe Abschnitt 4.5.2). • In einer zweiten Stufe kann diese Verschaltung um boolesche Logik erweitert werden (siehe Abschnitt 4.5.3). • In der dritten Stufe können die Logiknetzwerke zur Verriegelungsbeschreibung um komplexere Verrieglungsbedingungen ergänzt werden (siehe Abschnitt 4.5.4). Diese drei Stufen werden in den nachfolgenden Abschnitten näher erläutert.

4.5.2  Signal- und Komponentengruppen Für die Beschreibung von Verriegelungslogik wird zwischen den Auslösern und Empfängern von Verriegelungen unterschieden. Auslösende Komponenten müssen daher zunächst in sogenannte Signalgruppen und abhängige Komponenten in sogenannte Komponentengruppen gebündelt werden. Gibt eine Komponente der Signalgruppe ein Signal, werden alle Komponenten der Komponentengruppe abgeschaltet. Eine Komponente kann dabei sowohl mehreren Signal- als auch Komponentengruppen zugeordnet sein.

184

L. Hundt et al.

Abb. 4.34   Beispiel für eine Signal- und eine Komponentengruppe

Ein Beispiel für eine solche Gruppierung und Zuordnung wird in Abb. 4.34 gegeben. Hierbei wird eine Station betrachtet, die eine Reihe von Anlagenkomponenten beinhaltet. Wird hier der Not-Aus-Taster 1 betätigt, müssen die Komponenten Roboter 1, Schweißgerät 1, Rolltor 1 und Roboter 2 abgeschaltet werden. Die Abschaltung soll ebenso bei Betätigen des Not-Aus-Taster 2 oder des Lichtgitters 1 erfolgen. Im AutomationML-Modell werden zusammengehörige Komponenten in je einer Gruppe zusammengefasst. Die Modellierung solcher Gruppen in AutomationML erfolgt mit Hilfe des Group-Konzeptes (siehe Abschnitt 2.9.4 und AutomationML.A 2009). Dazu wird für jede Signal- oder Komponentengruppe im CAEX-Objektmodell je ein eingefügt und mit der Rolle SignalGroup bzw. ComponentGroup (siehe Abschnitt 2.8.4) assoziiert. Anschließend werden alle zugeordneten AutomationML-Objekte in dieses Gruppenobjekt „eingehängt“. Die jeweilige Schnittstelle Con der Signal- bzw. Komponentengruppe wird in AutomationML mit Hilfe je eines modelliert und von der Standardklasse InterlockingConnector abgeleitet. Die Relation zwischen den Schnittstellen wird durch einen abgebildet. Abbildung 4.35 zeigt einen vereinfachten XML-Quelltext des zugehörigen CAEX-Modelles. Für die verbesserte Lesbarkeit wurden die GUIDs und auch die Pfade zu AutomationML-Klassen in verkürzter Form dargestellt. Sind mehrere Signal- und Komponentengruppen vorhanden, können ihre Abhängigkeiten auf dieselbe Weise beschrieben werden (siehe Abb. 4.36). Jede Gruppe besitzt ihre eigene Interlocking-Schnittstelle und kann Beziehungen zu anderen Gruppen aufnehmen: auf diese Weise erfolgt die Zuordnung zwischen Signal- und Komponentengruppen. Die Zuordnung ist nicht auf 1:1-Zuordnungen beschränkt, eine Signalgruppe kann mit mehreren Komponentengruppen bzw. eine Komponentengruppe kann mit mehreren Signalgruppen verknüpft sein. In Abb. 4.36 sind solche Verknüpfungen dargestellt, wobei Signalgruppe A zur

4  Verhaltensbeschreibung mit PLCopen XML

Abb. 4.35   Vereinfachtes CAEX-Modell

Abb. 4.36   Prinzip Verknüpfung von Signal- und Komponentengruppen

185

186

L. Hundt et al.

Abschaltung der Komponentengruppen A und B, Signalgruppe B ausschließlich zur Abschaltung von Komponentengruppe B und Signalgruppe C zur Abschaltung der Komponentengruppen B und C führt.

4.5.3  Beschreibung boolescher Verriegelungsbedingungen Signal- und Komponentengruppen können untereinander auch komplexere Abhängigkeiten eingehen – diese müssen dann als logische Bedingungen beschrieben werden. Hierzu werden Logikvariablen eingeführt und den betroffenen Signalgruppen zugeordnet. Diese werden in einem Logik-Netzwerk verknüpft. Die Logik-Variable wird ebenso wie der Zustand der Komponenten in der Signalgruppe ausgewertet. So ist es zum Beispiel möglich, Signale von Nachbaranlagen mit einzubinden oder komplexere Bedingungen zu formulieren. Zur Beschreibung des booleschen Zusammenhangs zwischen den betroffenen Logikvariablen bedient sich AutomationML der Logiknetzwerke, die als Funktionsblockdiagramme bzw. FBDs Teil der IEC 61131 sind. Ein Beispiel ist in Abb. 4.37 dargestellt. Um einen herstellerunabhängigen Datenaustausch zu gewährleisten, beschränkt sich AutomationML ausschließlich auf die Verwendung von wenigen Gattern: NOT, AND und OR. Die Verwendung weiterer Gatter ist gemäß Definition von AutomationML (AutomationML.L 2009) nur für die erweiterten Verriegelungskonzepte erlaubt. Implizit ist durch die Verwendung der Gatter-Beschreibung auch eine Gruppierung von Elementen erlaubt. Bereits mit den drei erlaubten Gattern lässt sich ein großer Teil von Verriegelungsbedingungen abbilden, da sich jede Formel der binären Aussagenlogik mit Hilfe dieser Gatter nachbilden lässt (Kories u. SchmidtWalter 2008). So zeigt Abb. 4.37 ein Logiknetzwerk, das eine Äquivalenz-Funktion nachbildet. Mit dieser einfachen booleschen Logik zur Beschreibung der Verriegelung kann ein weiter Bereich logischer Funktionen abgedeckt werden. Die Überführung in eine solche Darstellung kann für gebräuchliche komplexe Gatter der Fachliteratur entnommen werden. Somit stellt diese Zwischenstufe eine Möglichkeit dar, wie Logik-Netzwerke ausgetauscht werden können.

Abb. 4.37   Funktions­blocknetzwerk

4  Verhaltensbeschreibung mit PLCopen XML

187

In PLCopen XML werden die Netzwerke in einzelnen POUs als FBD abgelegt. Die booleschen Variablen des Logik-Netzwerkes können bei Bedarf im Dachformat CAEX publiziert und den entsprechenden Signalgruppen über eine Standard-AutomationML-Schnittstelle PLCopenXMLInterface zugeordnet werden. Die Referenzierung dieser Variablen wird durch das Attribut SafeConditionEquals am PLCopenXMLInterface ergänzt. Dieses Attribut hängt von der Beschreibung im Ausgangsformat ab und zeigt an, ob der Wert TRUE oder FALSE einen sicheren Zustand der Verriegelungsbedingung darstellt.

4.5.4  Erweiterte Verriegelungskonzepte In der dritten Stufe zur Beschreibung von Verriegelungsbedingungen können mehrere FBD-Netzwerke untereinander kombiniert und auch mit der Verhaltensdefinition der Anlage oder ihrer Komponenten verknüpft werden. AutomationML sieht explizit auch den Austausch komplexer, als FBD dargestellte Logiknetzwerke zur Beschreibung von Verriegelungslogik vor. Um die Grundstruktur der Verriegelungslogik in AutomationML speichern zu können, wurde diese dritte Stufe zum Austausch komplexer Logiken definiert. Hierbei erfolgt die Speicherung von komplexen Netzwerken in separaten POUs. Jedes Netzwerk muss dabei in einer booleschen Variablen münden. Diese kann anschließend als Eingang in einem Netzwerk der zweiten Ausbaustufe genutzt werden, welches die Verriegelungsbedingung für eine Signalgruppe definiert. In Abb. 4.38 wird anhand eines Beispieles gezeigt, wie die dritte Stufe zur Logikbeschreibung verwendet wird. POU1 und POU2 seien komplexe Logiknetzwerke.

Abb. 4.38   Komplexe Verriegelungsbeschreibungen

188

L. Hundt et al.

In POU2 wird die Temperatur einer Messstelle auf die Einhaltung bestimmter Grenzen überprüft. Sofern dies gegeben ist, wird ein boolescher Ausgangswert Out_ POU2 auf TRUE gesetzt. Die Variable Out_POU2 wird dann in der POU3 weiterverwendet, welche den Konzepten der Stufe zwei entspricht. In dieser POU wird ein boolesches Verriegelungssignal definiert, das der entsprechenden Signalgruppe zugeordnet werden kann.

4.6  Integration von Verhaltensbeschreibung in CAEX Da die Logikinformationen in separaten PLCopen-XML-Dokumenten und nicht direkt im AutomationML-Dachformat CAEX gespeichert werden, ist ein Mechanismus zur Verknüpfung zwischen beiden Datenmodellen notwendig. AutomationML definiert hierzu eine standardisierte Schnittstelle zur Referenzierung externer PLCopen-XML-Dokumente. Diese ermöglicht, komplette Logikbeschreibungen zu referenzieren oder einzelne PLCopen-XML-Variablen im Dachformat CAEX zu publizieren, wo sie bei Bedarf miteinander verknüpft werden können.

4.6.1  Referenzierung von PLCopen-XML-Daten Soll ein AutomationML-Objekt ein PLCopen-XML-Dokument referenzieren, muss es mit einer Schnittstelle versehen werden, die von der AutomationML-Standardklasse PLCopenXMLInterface abgeleitet ist (vgl. Abschnitt 2.6). Diese Schnittstellenklasse erlaubt zudem die Veröffentlichung von Signalen oder Variablen, die in PLCopen-XML-Dokumenten modelliert wurden. Für die Abbildung der Referenz besitzt sie ein Attribut refURI, welche direkte auf externe Logikinformationen referenziert. Hierzu wird entweder der Pfad des Dokumentes oder zusätzlich die eindeutige globalID einer Variablen bzw. POU angegeben. Beispiele sind in Tab. 4.5 gegeben: Bei der Nutzung der Schnittstelle zur Integration von Logikinformationen in das Dachformat sind einige normative Vorgaben zu beachten: • Die Position des zu verknüpfenden externen Dokuments wird in dem standardisierten Attribute refURI gespeichert. Tab. 4.5   Beispiele zur Referenzierung von Logikinformationen aus CAEX Beispiele Erläuterung refURI = „file:///C:/PLCopenXMLFile1.xml“ refURI = „file:///C:/PLCopenXMLFile1.xml# mySignalID“ refURI = „file:///C:/PLCopenXMLFile1.xml# myPOUID“

Referenz auf eine PLCopen-XML-Datei Publizieren eines Signals Publizieren einer POU

4  Verhaltensbeschreibung mit PLCopen XML

189

Abb. 4.39   Verknüpfen von AutomationML-Objekten mit PLCopen-XMLDokumenten

• Die Referenzierung auf mehreren PLCopen-XML-Dokumente von einem AutomationML Objekt ist zulässig. Solche Mehrfachreferenzen werden durch die Nutzung mehrerer Schnittstellen des Typs PLCopenXMLInterface abgebildet. • Die Referenzierung von Daten und Objekten innerhalb eines PLCopen-XMLDokumentes erfolgt durch das Hinzufügen eines Separators # gefolgt von der ID des entsprechenden Objektes. • Wenn mehre Dokumente in verschieden Versionen oder Varianten derselben Logikinformation referenziert werden sollen, wird der CAEX der Schnittstelle genutzt, um dies auszudrücken. In Abb. 4.39 wird die Referenzierung einer PLCopen-XML-Datei anhand eines Beispieles gezeigt.

4.6.2  Verknüpfung von Verhaltensbeschreibung Die Variablen zweier PLCopen-XML-Dokumente können in CAEX miteinander verknüpft werden, ohne dass beide PLCopen-XML-Dokumente Kenntnis voneinander haben müssen. Dazu müssen sie in CAEX „publiziert“ und dort mit anderen Schnittstellen verbunden werden. In Abb. 4.40 wird dies gezeigt: zwei Signale „a“ und „b“ werden im Dachformat CAEX über die PLCopenXMLInterface-Schnitt-

Abb. 4.40   Veröffentlichungsmechanismus von PLCopen-XML-Variablen in CAEX

190

L. Hundt et al.

Abb. 4.41   CAEX-Beispiel zur Veröffentlichung von Signalen

stelle publiziert. Abbildung  4.41 zeigt den entsprechenden XML-Code. Die Verknüpfung derartiger Schnittstellen erfolgt innerhalb von CAEX mit Verbindungen vom Typ , siehe Abschnitt 2.5.5. Auf diese Weise lassen sich nicht nur Signale verbinden, sondern auch Verriegelungslogik und Sequencing. In der Verriegelungslogik wird das Ergebnis eines Logiknetzwerkes auf eine boolesche Variable abgebildet (siehe Abb. 4.42). Diese wird im CAEX-Modell wie oben beschrieben publiziert. Im Sequencing kann der Ablauf einer booleschen Variablen von einem Zustandsübergang abhängig gemacht werden. Auch diese Variable kann über den obigen Mechanismus im Dachformat publiziert werden. Beide Variablen werden anschließend in CAEX verknüpft. In Abb. 4.43 ist exemplarisch dargestellt, wie die Sicherheitsbedingung für Signalgruppe 1 mit der Verhaltensbeschreibung der Station verknüpft wird, die hier als Impuls-Diagramm gegeben ist.

Abb. 4.42   Verknüpfungsprinzip von Verriegelungsund Verhaltensbeschreibung

4  Verhaltensbeschreibung mit PLCopen XML

191

Abb. 4.43   Beispielhafte Verknüpfung von Verriegelungs- und Verhaltensbeschreibung

Dabei ist die Variable x die boolesche Variable, welche die Verriegelungsbedingung anzeigt. Diese wird über ein (siehe Abschnitt 2.5.5) innerhalb der Verhaltensbeschreibung mit einer Variable y verknüpft.

4.7  Zusammenfassung AutomationML ermöglicht in konsistenter Weise die Abbildung, Speicherung und den Austausch des gesteuerten und ungesteuerten Verhaltens von Anlagenobjekten sowie von logischen Bedingungen dieses Verhaltens. Als Beschreibungsmittel werden Gantt Charts, PERT Charts, Impuls-Diagramme und State Charts explizit unterstützt und empfohlen. Zur Speicherung wird das offene Datenformat PLCopen XML verwendet, wobei jedoch nur auf die Sprachen SFC und FBS zurückgegriffen wird. Dies ermöglicht sowohl einen herstellerunabhängigen Werkzeug- als auch einen phasenübergreifenden Datenaustausch. Die genannten vier Beschreibungsmittel werden für die Abbildung von Verhalten genutzt und über eine einheitliche Zwischenschicht IML auf PLCopen-XMLSFCs abgebildet. Logische Bedingungen werden als Verriegelungsinformationen interpretiert, mittels Logiknetzwerken beschrieben und als PLCopen-XML-FBD dargestellt. Zudem definiert AutomationML in transparenter Form die Anbindung von Logikinformationen an Objekte des Dachformates über ein speziell dafür vorgesehenes

192

L. Hundt et al.

CAEX-Interface. Damit wird es möglich, Objekten des Dachformates sowohl Verhaltensinformationen als auch logische Bedingungen zuzuordnen. Dies erfolgt zum einen über die Referenzierung der PLCopen-XML-Dokumente selbst und zum anderen durch Referenzierung von Inhalten innerhalb der PLCopen-XML-Dokumente. Mittels des CAEX-InternalLink-Mechanismus können diese Referenzen verknüpft und somit Beziehungen zwischen Verhaltensweisen unterschiedlicher Objekte hergestellt werden. Zusammenfassend kann unter Berücksichtigung der in Diedrich u. Bergert (2008) spezifizierten Informationsmengen festgestellt werden, dass die Kombination des AutomationML-Dachformates CAEX mit PLCopen XML den Austausch aller wesentlicher Logikinformationen ermöglicht, die für die Beschreibung von Verhalten Ereignis-diskreter Anlagenkomponenten notwendig sind.

Literatur AutomationML (2009) AutomationML.org. AutomationML Konsortium. AutomationML Homepage. http://www.AutomationML.org. letzter Zugriff April 2009. AutomationML.A (2009) AutomationML.A Specification Part 1 – Architecture and General Requirements. http://www.automationml.org/forum/viewforum.php?f=11. letzter Zugriff Mai 2009. AutomationML.L (2009) AutomationML Logic Definition Description of Logic Data Version 2. http://www.automationml.org/forum/viewforum.php?f=11. letzter Zugriff Mai 2009. Diedrich C, Bergert M (2008) Durchgängige Verhaltensmodellierung von Betriebsmitteln zur Erzeugung digitaler Simulationsmodelle von Fertigungssystemen. In: atp – Automatisierungstechnische Praxis, Jg. 50, H. 7, S. 61–66, Oldenbourg Verlag, München. Grimm B, Hundt L, Lüder A, Peschke J (2008) Universelles Datenaustauschformat – Mit Automation Markup Language sollen sich Engineeringwerkzeuge künftig besser verstehen – internationale Standardisierung angestrebt. In: A&D Kompendium, S. 266–268, publish-industry Verlag GmbH, München. Harel D (1988) On Visual Formalisms. In: Communications of the ACM, Jg. 31, Ausgabe 5, S. 514–529. Hundt L, Drath R, Lüder A, Peschke J (2008) Seamless Automation Engineering with AutomationML®. In: Proceedings of the 14th International Conference on Concurrent Enterprising IEC, S. 685–692, Lissabon. IEC 60848 (2002) GRAFCET – Spezifikationssprache für Funktionspläne der Ablaufsteuerung. IEC 61131-3 (2003) Programmable Controllers – Part 3, Ed. 2: Programming Languages. Kories R, Schmidt-Walter H (2008) Taschenbuch der Elektrotechnik Grundlagen und Elektronik, 8., erweiterte Aufl., Frankfurt am Main. Lunze J (2008) Automatisierungstechnik – Methoden für die Überwachung und Steuerung kontinuierlicher und ereignisdiskreter Systeme, Oldenbourg Verlag, München. Österreich B (2005) Die UML 2.0 Kurzreferenz für die Praxis, Aufl. 4, Oldenbourg Verlag, München. PLCopen (2009) PLCopen Konsortium. PLCopen Homepage. http://www.plcopen.org. letzter Zugriff April 2009. PLCopen XML (2009) PLCopen Konsortium. Technical Paper PLCopen Technical Committee 6 XML Formats for IEC 61131-3 Version 2. http://www.plcopen.org/pages/tc6_xml/forms/ before_downloading.htm. Stand Mai 2009.

4  Verhaltensbeschreibung mit PLCopen XML

193

Schnieder E (1999) Methoden der Automatisierungstechnik. Beschreibungsmittel, Modellkonzepte und Werkzeuge für Automatisierungssysteme, Vieweg, Friedr. & Sohn Verlagsgesellschaft mbH, Braunschweig. Vonhoegen H (2009) Einstieg in XML, 5 aktualisierte Aufl., Galileo Press (Galileo Computing), Bonn. Wagner T, Schertertel A, Elger J, Vollmar J (2008) Evaluation of Effectiveness and Impact of Decentralized Automation. In: Proceedings of the 13th IEEE International Conference on Emerging Technologies and Factory Automation, S. 1128–1135, Hamburg.

Kapitel 5

Ansatz zur integrierten Prozessbeschreibung Andreas Keibel

5.1  Einleitung Die moderne Fertigungstechnologie bedient sich in zunehmendem Maße der Automatisierungstechnik, bei der aufgrund sinkender Preise und technologischer Reifung immer häufiger Industrieroboter zum Einsatz kommen. Roboter werden für Bearbeitungsvorgänge insbesondere eingesetzt, um in der Produktion hohe und gleich bleibende Qualität bei deterministischer Geschwindigkeit zu realisieren und um bei steigendem Kostendruck wettbewerbsfähig zu bleiben. Dieses Kapitel widmet sich dem Thema, mit AutomationML eine elektronische und technologieneutrale Modellierung für die Aufgabenbeschreibung von Bearbeitungsvorgängen zu definieren. Beispiele für typische Bearbeitungsvorgänge sind Bahnschweißen, Punktschweißen, Kleben, Lackieren, Schleifen, Polieren oder Nieten. Die Motivation zur Beschreibung von Roboter-Arbeitsabläufen mit AutomationML resultiert aus dem Wunsch zum neutralen Speichern und Austauschen von Planungsdaten über den beabsichtigten Bearbeitungsprozess. In den vorangegangenen Kapiteln dieses Buches wurde beschrieben, wie Anlagentopologien als Objektmodell mit CAEX, Zellengeometrien und Kinematiken mittels COLLADA und logische Abläufe mit Hilfe von PLCopen XML abgebildet werden können. Mit Hilfe von COLLADA als Format für den Austausch von Geometriedaten, Kinematikdefinitionen und Pfaden, entlang denen sich etwas bewegen soll, kann ein virtuelles Szenario einer Automatisierungsanlage modelliert werden. CAEX als leistungsfähiges Trägerformat verbindet die virtuellen Modelle mit logischen Abläufen, die ihre Entsprechungen in PLCopen XML finden. Für eine Prozessbeschreibung müssen alle drei Welten miteinander verknüpft werden. Im Folgenden werden zunächst diesbezügliche Anforderungen an AutomationML formuliert, die benötigten Planungsdaten vorgestellt, das Modellierungskonzept erläutert und abschließend ein Modellierungsbeispiel mit AutomationML diskutiert. Dieses Kapitel ist als Vorstellung eines Ansatzes zu verstehen ohne A. Keibel () KUKA Roboter GmbH, Zugspitzstraße 140, 86165 Augsburg, Deutschland e-mail: [email protected] R. Drath (Hrsg.), Datenaustausch in der Anlagenplanung mit AutomationML, DOI 10.1007/978-3-642-04674-2_5, © Springer-Verlag Berlin Heidelberg 2010

195

196

A. Keibel

Anspruch auf Vollständigkeit. Ziel ist zu zeigen, wie AutomationML hierfür anwendbar ist.

5.2  Übersicht und Motivation 5.2.1  Problembeschreibung Heutzutage existieren verschiedene Möglichkeiten und Wege, einem Roboter seine Aufgabe „beizubringen“. Grundlage aller Planungsarbeit für einen Roboter ist eine Aufgabenbeschreibung, die eine Antwort auf folgende Frage gibt: Was muss getan werden?

Die Aufgabenbeschreibung ist die Eingangsinformation und Basis für den Roboterprogrammierer und kann in vielfältiger Weise erfolgen. Sie selbst ist unabhängig von der ausführenden Maschine. Wenn zum Zeitpunkt der Fragestellung noch kein Roboter zur Lösung der Aufgabe zur Verfügung steht, kann dennoch eine Prozessbeschreibung erfolgen. Der Einkauf kann unabhängig davon ein passendes Modell selektieren und beschaffen. Das Ziel des Roboterprogrammierers besteht darin, unter Verwendung seines Wissens und seiner Erfahrungen ein Roboterprogramm zu entwickeln, dass die formulierte Aufgabenstellung funktionsfähig umsetzt. Sein resultierendes Programm steuert den Roboter, die verwendete Prozesstechnologie und damit letztlich das Werkzeug. Dazu muss der Roboterprogrammierer die ihm vorgelegte Aufgabenbeschreibung in eine anweisungsorientierte Sprache übersetzen. Diese wird dann elektronisch in der Maschine abgelegt und dort abgearbeitet, so dass der Bearbeitungsprozess automatisch abgearbeitet wird. Der Roboterprogrammierer kann auch stellvertretend für Unternehmen stehen, die mit der Inbetriebnahme der Anlage betraut sind. Diese müssen die Aufgabenstellung zunächst verstehen, um daraus Roboter- und Steuerungsprogramme generieren zu können, welche die Aufgabe bewältigen. Das komplexe Umfeld des Programmierers wird in Abb. 5.1 verdeutlicht. In vielen Fällen besteht die Entwicklungsarbeit darin, mit Hilfe des Roboters durch Teach-In und textuelle Eingaben am Roboter-Bedienteil Programmcode zu generieren. Ist das Programmieren direkt am Roboter nicht möglich, etwa weil die Produktion unterbrechungsfrei in Betrieb sein soll, dann werden dem direkten Teachen an der Maschine Entwicklungsschritte vorgeschaltet, in denen detaillierte Simulationsmechanismen und 3D-Darstellungsformen mittlerweile eine große Bedeutung erlangt haben. Mit derartigen Softwarewerkzeugen zur realitätsnahen Simulation realer Szenarien ist es heute möglich, sich schrittweise der realen Inbetriebnahme zu nähern, wobei Steuerungskomponenten nicht nur für die Simulation zuständig sind, sondern auch den realen Roboter ansteuern können Keibel (2002). Ebenfalls können mit virtuellen Engineering-Werkzeugen Bearbeitungsprozesse simuliert und grafisch dargestellt werden Rokossa (1999). Hierbei helfen besonders

5  Ansatz zur integrierten Prozessbeschreibung

197

Abb. 5.1   Von der Aufgabenbeschreibung zur Bearbeitung

Falschfarbendarstellungen, mit denen sich kleinste Istgrößenunterschiede in der virtuellen Welt markanter darstellen lassen als in der realen Welt. Aber unabhängig davon, ob das Engineering in der virtuellen Welt beginnt, oder gleich mit dem Roboter, in beiden Verfahren wird die Aufgabenstellung unmittelbar im Robotersteuerungscode abgebildet. Um diese „Übersetzung“ der Aufgabenbeschreibung in eine maschinenverständliche Form zu übertragen, benötigt der Programmierer verschiedene Kenntnisse und Fertigkeiten: • Der Programmierer muss die Aufgabenstellung verstehen und mit den Auftraggebern kommunizieren, falls Klärungsbedarf herrscht. • Der Programmierer muss eine Vielzahl an Dokumenten, Emails, Tabellen und Telefonaten verwalten, geistig durchdringen und zum Aufbau einer vollständigen Beschreibung zusammenführen. Die Aufgabenstellung ist in der Praxis von großer Heterogenität ihrer Quellen geprägt. • Der Programmierer muss genaue Kenntnis von der Programmierung der Roboter sowie über bewährte Vorgehensweisen, Bibliotheken und Programmier-Richtlinien besitzen, damit er sie zielgerichtet programmieren kann. Hierzu gibt beispielsweise das Benutzerhandbuch der Maschine Auskunft über Funktionalitäten, Syntax, Parametrierung und Bedienung. • Der Programmierer muss wissen, wie er ein gegebenenfalls erforderliches steuerbares Werkzeug ansteuern muss, damit der Bearbeitungsprozess parallel zu den

198

A. Keibel

Roboterbewegungen ausgeführt werden kann. Das kann sehr komplex oder auch sehr einfach sein. Im einfachen Fall ist es beispielsweise ein Greifer, der mit einem einzigen Bit auf einer Signalleitung angesteuert wird. In komplizierten Fällen könnte es eine Klebesteuerung mit hunderten von Einstellparametern sein, die hochsynchron zur Bahnbewegung gesetzt werden müssen. • Der Programmierer muss wissen, wie er Bewegungsanweisungen mit denen zur Steuerung des Bearbeitungswerkzeuges kombinieren kann.

5.2.2  Anforderungen an AutomationML Zur Bewältigung dieser Aufgaben steht dem Programmierer eine Reihe von Dokumentationen zur Verfügung. Die Dokumentation des Tools, z. B. ein Lichtbogenschweißgerät, liefert Informationen über digitale, analoge oder andere Hardware – Ein-/Ausgangssignale und ihre Verwendung zur Steuerung der zugrundeliegenden Technologie. Unter Technologie werden hier sowohl die angestrebten Vorgänge, die verwendeten konkreten Techniken sowie die benötigten Prozessparameter verstanden. Die Dokumentation der Zielmaschine liefert Informationen darüber, wie die Ein- und Ausgänge beeinflusst werden müssen, um ihre Funktionen auszulösen. Der Verdrahtungsplan der Anlage spiegelt wider, wie die Peripherie an die Steuerungen angeschlossen wird und welche Kommunikationskanäle vorhanden sind. Dies verdeutlicht, dass der Aufbau und die Inbetriebnahme einer Roboter-Arbeitszelle komplexe Vorgänge darstellen. Gefordert ist der Roboterprogrammierer, der sowohl die Aufgabe verstehen, die Robotersteuerung kennen und auch die Prozesstechnologie in seinen Programmen berücksichtigen können muss. AutomationML soll diese Komplexität für den Anwender und den Programmierer vereinfachen. Erst eine konsolidierte gemeinsame Prozessbeschreibung schafft Raum für Automatismen auf dem Weg zur funktionalen Arbeitszelle. Die Anforderungen an AutomationML sind daher: 1. Mit AutomationML soll die Prozessbeschreibung technologieneutral modelliert werden können. 2. AutomationML soll einen Beschreibungsrahmen vorgeben, ohne den Anwender mit herstellerabhängigen Randbedingungen einzuschränken. 3. AutomationML soll markante Vorgänge und Prozessführungsgrößen abstrakt abbilden können. 4. AutomationML soll die Weiterverwendung dieser Größen innerhalb von Ausfühungseinheiten/Steuerungen erlauben. 5. AutomationML soll die Synchronisation von Maschinen-Variablen und abstrakten AutomationML-Prozessführungsgrößen wie etwa Schweißstrom zwischen Offline-Engineering-Werkzeugen und realen Anlagen ermöglichen.

5  Ansatz zur integrierten Prozessbeschreibung

199

6. AutomationML soll eine datentechnische Definition wiederverwendbarer Werkzeuge zur Verwendung in heterogenen Tool-Landschaften zulassen. Die folgenden Szenarien belegen den Bedarf, Prozessbeschreibungen mit einem Datenformat wie AutomationML neutral abbilden zu können: 1. Es existiert heute keine standardisierte Möglichkeit, die Aufgabenbeschreibung „was muss getan werden?“ zu formulieren. Der Mensch, der mit der Aufgabe betraut ist, die Anwendung umzusetzen, bekommt verschiedenartig aufbereitete Daten, mit denen die Aufgabe mehr oder minder präzise definiert ist: Excel oder Word-Tabellen mit Positionsdaten und Parametergrößen, Word-Tabellen oder Emails mit gescannten technischen Zeichnungen, angereichert mit handschriftlichen Zeichen, verschiedene proprietäre Dateiformate, Faxe etc. 2. Es existiert heute keine maschinenlesbare und generische Möglichkeit abzubilden oder abzuspeichern, welche Funktionen und Parameter ein Bearbeitungswerkzeug bereitstellt: zum Beispiel Abstand regeln, Vorschubgeschwindigkeit, Lichtbogen zünden, Klebstoff-Swirl aktivieren, Laserleistung einstellen, Pendelamplitude einstellen, Druck, usw. 3. Es existiert heute keine anschauliche Methodik zur Modellierung des Prozesses. Der Entwicklungsaufwand zur Realisierung der Aufgabenbeschreibung – wenn sie erst einmal kommuniziert und verstanden ist – besteht darin, diese Aufgabe direkt in Maschinenanweisungen zu codieren. Der Programmierer muss dazu Roboter- und Prozess-Wissen verbinden. Der resultierende Programmcode reflektiert jedoch nicht anschaulich, was passiert, und er ist nur scshwer verständlich. Zum Beispiel haben IO Anweisungen auf numerisch angegebenen IOPorts wie

AnOut [53 + io offset1] = bias + 23.7;

keine transparente Bedeutung. Selbst eine datentechnische Analyse der Funktionalität der Zeile ist nicht möglich, da es keinen datentechnischen Bezug zur Aufgabenstellung gibt, zudem es noch nicht mal eine datentechnische Definition einer Aufgabenstellung gibt. Diese Anweisung könnte bedeuten: Gebe auf dem Kanal der Roll-Falzsteuerung, der zur Justage des Druckes vorgesehen ist, den Vordruck, inkrementiert um 23,7 kN, aus. Oder noch abstrakter ausgedrückt: Setze auf dieser Bahn für das Roll-Falzwerkzeug die Andruckkraft 23,7 kN höher als den voreingestellten Druckwert. Im Allgemeinen ist jedoch nicht ersichtlich, was mit einer Codezeile des Steuerungscodes erreicht werden soll. Die zugehörigen Informationen sind durch Informationsverdichtung verloren gegangen, eine Abstraktion bzw. Rekonstruktion der ursprünglichen Absichten des Planers ist nicht mehr möglich. In Abb. 5.2 wird ein typischer Prozess zum Erstellen einer einfachen Schweißnaht dargestellt: Dieser besteht aus dem geometrischen Verlauf einer Bahn, die durch die Stützpunkte und andere Parameter gegeben ist.

200

A. Keibel *DVGUXFN 6FKZHLVVVWURP

'UDKWDEVFKQHLGHQ

P ]X LY LO DW XWH %D

O UH

7

6FKZHL‰QDKW

7

7

7

7

7

7

7

7

7

%DKQSRVLWLRQHQ

7

6WURPHLQ 7

7 %DXWHLO

%H]XJVNRRUGLQDWHQ V\VWHPGHV%DXWHLOV

Abb. 5.2   Beispiel für einen Bearbeitungsprozess: einfache Schweißnaht

Während der Roboter mit seinem Schweißwerkzeug diese Bahn abfährt, wird an bestimmten Positionen eine Aktion ausgeführt, damit geschweißt werden kann. Zunächst wird das Schutzgas eingeschaltet, dann der Schweißstrom vorgewählt, der Lichtbogen wird gezündet und während des Schweißens wird an einer bestimmten Stelle der Strom reduziert. Nach dem Löschen des Lichtbogens wird der Wert für den Strom zurückgesetzt und das Gas ausgeschaltet. Am Ende soll der Draht durch Abknipsen an einer speziellen Station in seiner Länge justiert werden. Die Übersetzung von „was muss getan werden“ in den resultierenden maschinenverständlichen Code bedeutet, dass proprietäre Informationen aus verschiedenen Quellen kombiniert werden müssen. Der Roboterprogrammierer muss sich daraus ein abstraktes Bild von der Aufgabe machen, um diese umsetzen zu können. Beim Codieren wird dieses Verständnis jedoch wieder vernichtet, indem es in maschinenspezifische Codes abgebildet und verdichtet wird. Dabei geht die eigentliche Definition der Aufgabenbeschreibung wieder verloren, da eine Art Verschlüsselung stattfindet, während sie in die steuerungsspezifischen Sprachen transformiert wird. Der Programmierer macht sich allenfalls Notizen über seinen Lösungsweg: Abb. 5.1 veranschaulicht diesen Vorgang.

5.2.3  Vision Mit Hilfe einer neutralen Modellierung der Aufgabenstellung würden die genannten Nachteile behoben. Stattdessen kommen eine Reihe von Vorteilen zum Tragen. Der Schritt zur Programmgenerierung könnte erheblich qualifizierter ablaufen und es könnten Informationen erhalten werden, die auch auf Ausführungsebene bereitstehen. Dieser Ansatz erlaubt es, Steuerungen und Steuerungscode zu entwickeln, welcher abstrakte und anschauliche Operationen ausführt, weil eine Abstraktion der

5  Ansatz zur integrierten Prozessbeschreibung

201

eigentlichen Aufgabenstellung erhalten bleibt. Der Roboterprogrammierer müsste nicht unbedingt auch ein Prozessexperte sein, bzw. die Bahnprogrammierung kann von der Prozessprogrammierung entkoppelt betrachtet werden. Engineering-Schritte könnten mit Hilfe einer neutralen Aufgabenbeschreibung automatisiert werden, insbesondere mit Hinblick auf Code-Generatoren, welche automatisch die Kombination aus geometrischer Bewegung des Werkzeuges und Werkzeugansteuerung in Programmcode überführen. Mit einer solchen Aufgabenbeschreibung könnte eine Software eine Beschreibung des Prozesses einlesen und den Programmierer entlasten. Er müsste „nur noch“ dafür sorgen, dass eine performante Abarbeitung ohne Schäden, beispielsweise durch Kollisionen, im Kontext der Anwendung realisiert wird. Die datentechnische Definition einer „Bearbeitungs-Prozess-Beschreibung“ unterstützt das Ziel von AutomationML, den Gesamt-Engineeringaufwand zu reduzieren, um letztlich eine Kostenreduktion und einen schnelleren Produktionsanlauf zu erreichen, denn: dann existiert eine Darstellung über „Was muss getan werden“ und diese Information ist speicher- und transportierbar vom Anforderer zum Programmierer oder vom Anforderer zum Applikationsingenieur, der mit Hilfe von Softwaretools eine teilautomatische Programmgenerierung durchführen kann. Die Syntax des Datenformats wäre herstellerneutral und maschinenunabhängig zugänglich.

5.2.4  Bestehende Datenformate zur Prozessdarstellung Im Rahmen der Bestrebungen von STEP-NC (STEP 2009) wird der ISO Standard 10303 erweitert (ISO 2009a). In der gleichen Domäne bewegt sich ISO 14649-10 (ISO 2009b). Diese Standards fokussieren primär den Bereich Werkzeugmaschinen und spanende Verarbeitung. Bemerkenswert ist, dass auch hierbei die Aufgabendefinition mit Hilfe von Werkzeugdefinitionen erfolgt, jedoch beschränkt auf spanende Werkzeuge (ISO 2009c). Das Datenformat ist nicht XML basiert und kostenpflichtig. Die Process Specification Language PSL (PSL 2009) fokussiert auf die Abbildung von Arbeitsabläufen im Produktionsprozess und ist nicht XML-basiert. Ähnlich wie bei BPML (BPML 2009) werden mit PSL Sequenzdiagramme modelliert, mit denen Vorgänge abgelegt werden können. In diesem Kapitel soll jedoch die Darstellung von Bearbeitungsprozessen in Form von XML beschrieben werden.

5.3  Modellierung von Bearbeitungsprozessen 5.3.1  Übersicht Um Bearbeitungsprozesse in einer neutralen Prozessbeschreibung datentechnisch erfassen zu können, müssen die zugrundeliegenden Prozesselemente benannt, formuliert und strukturiert werden, also Objekte, die mit der Aufgabenstellung in

202

A. Keibel

Verbindung stehen, sowie die Relationen zwischen ihnen. Dieser Abschnitt erläutert Basisanforderungen an eine Prozessbeschreibung und die daraus abgeleiteten Modellelemente.

5.3.2  Basisanforderungen an eine Prozessbeschreibung Ein Bearbeitungsprozess ist die praktische Ausführung von Handlungen von Werkzeugen an oder auf Bauteilen, die durch diese Handlungen beeinflusst werden. Typische Bearbeitungsvorgänge sind: Kleben, Bahnschweißen, Punktschweißen, Remote-Laserschweißen, Plasmaschneiden, Wasserstrahlschneiden, Nieten, Bohren, Besäumen, Falzen, Entgraten, Schleifen, Polieren oder Lackieren. Diese Bearbeitungsvorgänge werden an einem Werkstück unter Verwendung von Werkzeugen durchgeführt, die Bewegungen vollziehen und werkzeugspezifische Technologien bereitstellen. In einem Bearbeitungsprozess wird ein Prozesswerkzeug auf einer geometrischen Bahn bewegt, die auf einem Bauteil liegt und dabei Aktionen ausführt. Daraus ergeben sich folgende Anforderungen an die Prozessbeschreibung: • Es wird eine generische und einfache Bahnbeschreibung für Werkzeug- und Bauteilebahnen benötigt, unabhängig von Robotern. • Die benötigten Prozesswerkzeuge sowie ihre zugehörigen Funktionen und Technologien müssen definiert werden. Dies umfasst auch die Identifikation ihrer zugehörigen spezifischen Prozessgrößen und Methoden, mit denen der Bearbeitungsprozess gesteuert werden kann. • Der Bearbeitungsprozess muss definiert und dem Bauteil respektive Produkt zugeordnet werden können. Für die geometrische Beschreibung eines Bauteils existiert mittlerweile eine Vielzahl an Möglichkeiten. Im Rahmen von AutomationML wird dies mit COLLADA realisiert. Es fehlt jedoch die Modellierung der Bahn, die Modellierung der einzelnen Bearbeitungsschritte sowie die Modellierung die Relationen zwischen den Bearbeitungsschritten und den werkzeugspezifischen Prozessparametern.

5.3.3  Die Eckpfeiler der Prozessbeschreibung Die Eckpfeiler einer Prozessbeschreibung umfassen somit drei Arten von Informationen. Das Werkzeug mit seiner Technologie, die Bewegungsbahn relativ zum Bauteil sowie die Prozessanweisungen für das Werkzeug lassen sich wie in Abb. 5.3 dargestellt als Dreieck abbilden. Die Werkzeugbewegungen orientieren sich hierbei an dem Bauteil, das bearbeitet werden soll. Sowohl Bauteil als auch Werkzeug können bewegt werden, um den Prozess durchzuführen. Innerhalb des Dreiecks sind jene Basiselemente und deren Relationen dargestellt, mit denen definiert werden soll, was die Aufgabenbeschreibung eines

5  Ansatz zur integrierten Prozessbeschreibung

203

Abb. 5.3   Objekte und Relationen der BearbeitungsProzessbeschreibung

Bearbeitungsprozesses ausmacht. Die genannten drei Basiselemente der Prozessbeschreibung lassen sich wie folgt grob beschreiben. In den folgenden Abschnitten wird diese Beschreibung weiter detailliert: • Bahn: Das Basiselement Bahn beschreibt den rein geometrisch verlaufenden Anteil des Bearbeitungsprozesses. Die Bahndefinition setzt sich aus Abschnitten zusammen, die in ihrer Gesamtheit die Bewegungen definieren, welche zur Ausführung des Bearbeitungsvorganges erforderlich sind. Hier sind noch keinerlei Informationen zur Steuerung eines Bearbeitungsprozesses enthalten. Ein Werkzeug bewegt sich ohne Prozessinformationen lediglich „blind“ über diese Bahn. Das Datenobjekt Bahn stellt weiterhin einen eindeutigen Indizierungsmechanismus bereit, mit dem beliebige Positionen auf der Bahn exakt referenziert werden können, den so genannten Targets. Dies ist erforderlich, um exakte Positionen für jeweils benötigte Aktivitäten definieren zu können. • Werkzeug/Technologie: Das Basiselement Werkzeug enthält ggf. Informationen über die geometrische Ausprägung des Werkzeuges, damit dieses in einer 3D-Szene visualisiert werden kann. Es enthält weiterhin Informationen über die Möglichkeiten und Funktionalitäten, welche vom Werkzeug bereitgestellt werden und es enthält geometrische Einschränkungen und Freiheitsgrade des Werkzeuges bzw. des Prozesses, für den es bereitgestellt wird. Von Bedeutung ist hier der so genannte TCP (tool center point), das ist derjenige geometrische Punkt des Werkzeuges, der auf der Bahn entlangfahren soll. In AutomationML wird davon ausgegangen, dass eine Technologie zur Bearbeitung durch die Definition eines Werkzeugs bereitgestellt wird. Ohne ein Werkzeug kann keine Bearbeitung definiert und durchgeführt werden. Die damit erforderliche Disziplin bei der Modellierung von Bearbeitungsvorgängen erleichtert und beschleunigt den gesamten Entwicklungsprozess erheblich und schafft die Möglichkeit von Synergien, womit Parallel- oder Doppelentwicklungen reduziert werden können. • Prozess: Das Basiselement Prozess enthält Informationen über die Ansteuerung eines Prozesswerkzeuges auf Bewegungsbahnen. Dies ist prinzipiell eine chronologische Liste mit Einträgen zur Steuerung des Werkzeugs parallel zur Bewegung. Mit ihr werden die Möglichkeiten, die das Werkzeug bereitstellt, auf der Bahn verteilt genutzt und parametriert. Der Indizierungsmechanismus

204

A. Keibel

der Prozessbahn dient dabei dem exakten Platzieren von werkzeugspezifischen Funktionen oder Unterprogrammen auf der Bahn. Mit diesen drei Basiselementen der Prozessdefinition (Bahn, Werkzeug, Prozess) wird bisher der Bearbeitungsprozess unabhängig vom Roboter definiert, der den Prozess später ausführen soll. Diese maschinenunabhängige Betrachtung ist beabsichtigt, denn die Aufgabenbeschreibung soll per Definition keine Angaben darüber enthalten, mit welchen kinematischen Maschinen der Prozess ausgeführt werden soll. Genaugenommen bleibt sogar offen, ob die Bearbeitung von einer Maschine ausgeführt werden soll oder von einem Menschen.

5.3.4  Von der Prozessbeschreibung zum Roboter-Code Ziel des in diesem Kapitel vorgestellten Ansatzes zur elektronischen Prozessbeschreibung ist nicht nur die Speicherung und der Austausch, sondern insbesondere ihre elektronische Weiterverarbeitung. Dies könnte die algorithmische Prüfung der Beschreibung auf Korrektheit, Widerspruchsfreiheit oder Konfliktfreiheit bedeuten, aber auch die automatische Generierung oder Verifizierung von Roboter-Code. Ohne eine computerlesbare Formulierung der Aufgabenstellung ist ein algorithmischer Zugang zu diesen Planungsdaten nicht möglich. Hier wird mit AutomationML ein neuer Weg beschritten, der die Transportabilität von Nutzdaten über Softwarewerkzeuge und heutige Anwendungen hinaus unterstützt. Für die spätere Code-Generierung sind eine Reihe von weiteren Informationen zu formulieren. So müssen die verwendeten Werkzeuge einem Roboterarm zugeordnet werden. Montiert der Entwickler das Werkzeug, welches laut Prozessbeschreibung auf der Bahn bewegt und angesteuert werden soll, an einen (virtuellen) Roboter, so muss dieser Roboter so angesteuert werden, dass er die Bahn des Werkzeugs möglichst genau abfährt. In AutomationML ist bereits vorgesehen, dass ein Werkzeugobjekt an den Flansch eines Roboterobjektes montiert werden kann. Damit ist definiert, welcher Roboter diese Bahn ausführen soll. Weiterhin muss die Werkzeugsteuerung mit der Robotersteuerung verbunden werden. Über die mechanische Montage des Werkzeuges am Roboter hinaus kann mit AutomationML auch definiert werden, welche Steuerung das Werkzeug ansteuert. Damit ist auch eine „elektronische“ Verbindung gegeben. Die damit mögliche Code-Generierung für einen Bearbeitungsprozess hat die Aufgabe, lauffähige Programme zur Werkzeugführung und Werkzeugsteuerung zu erzeugen. Wird das Werkzeug von einem Roboter geführt, dann ist es häufig auch die Aufgabe des Roboters, das Werkzeug anzusteuern. Dabei werden innerhalb des Roboterprogramms Anweisungen zur Bewegung der Kinematik mit Anweisungen zur Ansteuerung des Werkzeuges kombiniert. Das Ziel dabei ist es, eine synchrone Kopplung von Werkzeugsteuerung und Roboterbewegung zu erhalten. RoboterCode, der diese Aufgabe erfüllt, wird bisher meistens von Roboterprogrammierern manuell erzeugt. Dabei ist ein ausgezeichnetes Fachwissen erforderlich, es muss die Aufgabe verstanden werden, die Robotersteuerung muss programmiert werden,

5  Ansatz zur integrierten Prozessbeschreibung

205

Abb. 5.4   Ausführungsdreieck

so dass die Bewegungen den Anforderungen entsprechen, der Programmierer muss über detaillierte Kenntnisse der Prozesstechnologie verfügen, er muss das Werkzeug einrichten und verschalten und er muss das Werkzeug bahnsynchron ansteuern. In Abb. 5.4 ist der Ausführungsteil auf Steuerungsebene aus Abb. 5.1 nochmals dargestellt: ein Roboterprogramm für Bahnbewegung und Prozesssteuerung und seine Aufgaben. Zusammenfassend ist festzustellen, dass eine formalisierte und datentechnische Aufgabenbeschreibung, wie sie mit AutomationML angestrebt wird, erstmals die Möglichkeit schafft, die Konsistenz zwischen den Daten der Aufgabenbeschreibung und der Umsetzung auf Steuerungsniveau herzustellen und zu bewahren. Bisher war es lediglich möglich, Positionsdaten konsistent zu halten, da in der Offline-Programmier-Welt keine einheitliche Prozessbeschreibung implementiert ist. Mit der datentechnischen Beschreibung der Aufgabenstellung wäre es möglich, Mechanismen zu etablieren, bei denen Änderungen im Shopfloor direkt in die Aufgabenstellung zurückgepflegt werden können. Der folgende Abschnitt erläutert, welche Objekte und Eigenschaften mit AutomationML modelliert werden müssen, um eine Prozessbeschreibung zu realisieren.

5.4  Datentechnische Inhalte der Objekte 5.4.1  Übersicht In diesem Abschnitt werden die benötigten Datenobjekte beschrieben und mit AutomationML exemplarisch modelliert. Die hier gezeigten AutomationML-Modelle sind als Ansätze zu verstehen ohne Anspruch auf Vollständigkeit. Sie sollen

206

A. Keibel

konzeptionell zeigen, wie Mechanismen von AutomationML genutzt werden können, um benötigte Elemente der Prozessbeschreibung zu modellieren.

5.4.2  Modellierung des Bahn-Objektes Mit dem Bahn-Objekt wird eine einheitliche und geräteunabhängige Darstellung einer Bewegung definiert. Ziel der Modellierung ist zum einen die Darstellung einer vollständigen kartesischen Kontur einer Bewegung im Raum, relativ zu Weltkoordinaten oder relativ zu anderen Objekten. Zum anderen müssen Bahnfortschrittsparameter abgebildet werden, mit denen gezielt Punkte auf der Kurve eindeutig indiziert werden können. Mittels dieser Punkte kann geometrisch genau definiert werden, wo ein verwendetes Werkzeug zum Einsatz kommen soll. Die Verwendung dieser Werte findet in Verbindung mit den Prozessgrößen statt, die angeben, welche Werte den Prozesssteuergrößen an dieser Stelle zugewiesen werden sollen. In Tab. 5.1 werden die benötigten Anforderungen an die datentechnische Abbildungen im Dachformat CAEX dargestellt und definiert. Eine zugehörige CAEXModellierung erfolgt anschließend. Es ist zu beachten, dass die Trajektorie der Bahn selbst nicht in CAEX, sondern in COLLADA abgelegt wird. Für die Weiterverwendung der gegebenen Bahndarstellung ist es erforderlich, einen universellen Mechanismus bereitzustellen, mit dem auf einfache Weise eine exakte Position auf der Bahn bezeichnet werden kann. Dazu werden so genannte Targets festgelegt. Ein Target ist ein Stützpunkt in einer Trajektorie. Er umfasst zum einen den translatorische Anteil, der sich durch einen Vektor x,y,z ausdrücken lässt, und zum anderen eine Richtungsangabe, in die das Werkzeug an dieser Position zeigen soll. Diese lässt sich mit drei Rotationswinkeln rotx, roty und rotz ausdrücken. Auf der Bahn wird eine Anzahl von Targets festgelegt. Diese lassen sich mit Hilfe des Bahnindex durchnummerieren. Der Bahnindex erhöht sich von Target zu Tab. 5.1   Das Bahn-Objekt und seine benötigten Parameter Name Bedeutung Symbolname Symbolischer Name der Bahn ID Eindeutige Referenznummer der Bahn im gesamten AutomationMLProjektbaum Parentobject Ein Bezugsobjekt. Im Allgemeinen das Produkt, auf dem die Bahn liegt. Wird das Produkt bewegt, bewegt sich die Bahn mit Trajectory Referenz auf die Bahn in COLLADA Quality mm Radius der garantierten Genauigkeit: Dieser Wert kann von Bahngeneratoren gesetzt werden und aus den zugrundeliegenden Genauigkeiten der Geometrien ermittelt werden NormalVect Optionaler Vektor, der angibt, in welche Richtung in die Oberfläche eines Bauteils eingetaucht wird, falls der Pfad auf der Oberfläche eines Bauteils liegt. Der Vektor ist relativ zu den Positionen, durch welche die Trajektorie gegeben ist StartPos Startposition des Pfades auf der COLLADA Trajektorie (Trajektorien können mehrfach verwendet werden) EndPos Endposition des Pfades auf der referenzierten Trajektorie

Typ String UUID Referenz Referenz Real Vector

Real Real

5  Ansatz zur integrierten Prozessbeschreibung

207

Target immer um exakt 1.0. Die Position, die mit dem ersten Target übereinstimmt, hat den Index „0.0“. Zwischen den Targets wird der kartesische Raum vom Ausgangstarget zum nächsten Target im Intervall]0…1[interpoliert. Ein Bahnindex 2.5 bedeutet folglich, dass der Punkt in der Mitte zwischen dem zweiten und dritten Target anvisiert wird. Die Länge des Bahnabschnittes zwischen beiden Targets ist dabei ohne Belang, sie wird auf 1.0 normiert. Dies ist ähnlich zu Uhrzeitangaben wie „halb fünf“ – dies bezeichnet ebenso die Hälfte zwischen den Zeiten 4:00 und 5:00 Uhr. Ist der translatorische „Bogen“ kleiner als der Drehwinkel zwischen den Targets, dann dient der Drehvektor als das Maß, das zwischen 0.0 und 1.0 normiert wird. Je nachdem, ob sich also translatorisch oder rotatorisch zwischen zwei Targets mehr Bewegung ergibt, wird die dominierende Änderung herangezogen. Diese Darstellung ist invariant gegenüber der zwischen den Targets eingestellten Interpolationsart. Ein Target hat die kartesische Darstellung (x,y,z, rotx, roty, rotz), mit • y,y und z, als translatorische Positionsangabe in mm und • rotx, roty und rotz, den nacheinander um die Einheitsvektor-Achsen ex, ey und ez ausgeführten Rotationen in Grad. Beispiel: Eine Bahn sei gegeben durch die Positionen     Target0 = (0,0,0, 0,0,0);      Target1 = (0,0,0, 40,0,0);   Target2 = (100,0,0, 0,0,0); Dann endet diese Bahn mit dem Bahnindex 2.0. Ist als Bewegungstyp „Linearinterpolation“ gewählt, dann bezeichnet der Bahnindex 0.5 die Stellung genau zwischen der Startposition und dem zweiten Target, demnach: (0,0,0, 20,0,0). Der Bahnindex 1.5 bezeichnet die Stellung (50,0,0, 20,0,0). Der Bahnindex ist invariant gegenüber Ausführungszeit und Geschwindigkeit. Er bezeichnet nur eine geometrische Position auf der Bahn, unabhängig von dem Geschwindigkeitsprofil, mit dem die Bahn später ausgeführt werden soll. Der hier definierte Bahnindex ist demnach eine abstrakte dimensionslose Größe, die ausschließlich den Zweck verfolgt, eine beliebige Position zwischen Targets auf der Bahn eindeutig bezeichnen zu können. Diese Darstellung wurde gewählt, weil sie für den Planer intuitiv zu verstehen und datentechnisch gut zu verarbeiten ist. Es wird davon ausgegangen, dass diese Bahndarstellung mit Softwarewerkzeugen zur Roboterprogrammgenerierung weiterverarbeitet und dort entsprechend dem Zielsystem optimiert auf Roboterbewegungen abgebildet wird. Wie auch bei anderen Datenobjekten in AutomationML besteht die Prozessbahn aus zwei Teilen: 1. Einem AutomationML-Objekt für die Bahn im CAEX-Objektmodell 2. Einer geometrischen Bahnbeschreibung in COLLADA (hier die Trajektorie bzw. Animation)

208

A. Keibel

Das Bahnobjekt zur Beschreibung von geometrischen Konturen verbindet das Bauteil mit einer Trajektoriendefinition. Es wird im Dachformat CAEX abgebildet und ermöglicht mit der eindeutigen Definition eines Bahnindexes und den Referenzen auf relevante Objekte in COLLADA die Verwendbarkeit als Prozessbahn.

5.4.3  Modellierung des Werkzeug-Objektes Das Werkzeug-Objekt bildet das Bearbeitungswerkzeug ab mit dem Ziel, seine bereitgestellten Technologien bzw. Funktionen auf den Bahnen anwenden zu können. Damit definiert es nicht den Bearbeitungsprozess selbst, sondern stellt Prozessgrößen, Parameter und Möglichkeiten bereit, mit denen die Durchführung eines Bearbeitungsprozesses datentechnisch abgebildet werden kann. Die zugrundeliegenden Planungsdaten umfassen zum einen den Bezeichner, eine Identifikationsnummer bzw. symbolischer Name des Werkzeuges bzw. der Technologie. Diese werden mit AutomationML als CAEX-Attribut modelliert. Weiterhin muss die Klasse der Technologie abgebildet werden, die Auskunft über die Funktion des Werkzeuges gibt. Dazu gehören beispielsweise punktorientierte Prozesse wie Punktschweißen, Nieten und Bohren oder Bahnprozesse wie Bahnschweißen, Kleben oder Rollfalzen. Diese Klassifizierung wird mit Hilfe des CAEX RollenKonzeptes durchgeführt. Ein weiterer Bestandsteil der Planungsdaten des Werkzeugobjektes ist seine Geometrie. Diese umfasst seine datentechnische Abbildung der geometrischen und kinematischen Erscheinung der Technologie, sofern vorhanden, beispielsweise das Geometriemodell eines Greifers. Die Geometrie kann verschiedene Objekte enthalten, falls die Technologie aus mehreren Komponenten besteht, beispielsweise einen Applikationskopf, Steuerschrank oder Leitungen. Sie kann weiterhin die aktivierbaren Tool-Center-Points enthalten – so kann ein Applikationskopf an verschiedenen geometrischen Positionen Tool-Center-Points enthalten, die einzeln aktivierbar sind. Daraus ergeben sich folgende abzubildende Informationen im AutomationMLObjektmodell (siehe Tab. 5.2). Weiterhin müssen die Prozess-Veränderlichen definiert werden, die in ihrer Gesamtheit den für die Aufgabendefinition relevanten Konfigurationsraum der Technologie ausmachen. Prozessgrößen sind durchgehend definiert, d. h. sie weisen keine Definitionslücken auf. Ihre initialen Werte sind vorgegeben und sie müssen bei Produktionsbeginn initialisiert werden. Prozessgrößen sind entweder feste Größen, Tab. 5.2   Das Werkzeug-Objekt und seine benötigten Informationen ID

Bedeutung

ToolName Symbolischer Name des Werkzeugs ID UUID Kennziffer ToolType Klasse des Werkzeugs nach DIN 8580, z. B. „DIN8580.3.3.1“: Schleifen mit rotierendem Werkzeug (DIN 8580) Shape Verweis auf die COLLADA-Geometrie des Werkzeugs

Typ String UUID String Referenz

5  Ansatz zur integrierten Prozessbeschreibung

209

Tab. 5.3   Prozessgrößen und ihre benötigten Informationen ID Gruppe von Prozessgrößen skalare Größen, die den Prozess charakterisieren Name Name der Prozessgröße Unit Einheit der Prozessgröße Default Standardwert der Prozessgröße Range Definitionsbereich der Prozessgröße AllowedError Zulässige Genauigkeit in % UsedOnPath Flag, das anzeigt, ob der Wert in Echtzeit auf der Bahn geändert werden kann, oder ob es sich einen „Konfigurationswert“ handelt, der nur selten modifiziert wird und der Konfiguration des Werkzeuges dient Latency Latenzzeit, die angibt, wie lange es von der Auslösung bis zum Effekt auf dem Bauteil in Sekunden dauert

Typ String String Je nach Typ Je nach Typ Real Bool

Real

die sich nicht während der Bearbeitung ändern, beispielsweise die Versorgungsspannungshöhe (230 oder 380 V), oder dynamische skalare Größen, die sich hochdynamisch auf der Bahn ändern können, beispielsweise eine Andruckkraft, ein Schweißstrom oder die Steuergröße für die Düse einer Klebesteuerung. Auch die Prozess-Sollgeschwindigkeiten und Beschleunigungen auf der Bahn können hier als Prozessgrößen eingetragen werden. Folgende Eigenschaften von Prozessgrößen sollen mit AutomationML abgebildet werden (siehe Tab. 5.3): Innerhalb einer Technologie stellen Werkzeuge unterschiedliche Methoden zur Verfügung, die zudem Unterprogramme mit komplexeren Abläufen einschließen können, beispielsweise das Kappenfräsen beim Punktschweißen, die Kalibrierung eines Sensors, das Vermessen eines Bauteiles oder das maßhaltige Kürzen eines Schweißdrahtes an einer Station. Deshalb müssen mit AutomationML Aktionen mit folgenden Eigenschaften abgebildet werden können (siehe Tab. 5.4). Ein weiterer Aspekt der Modellierung des Werkzeug-Objektes sind Einschränkungen: Prozesse unterwerfen den Roboter einer Einschränkung an Freiheitsgeraden. Das Werkzeug darf sich nicht mehr frei bewegen, um den Prozess ausführen zu können. Diese Einschränkungen sollen mathematisch festgehalten werden, mit dem Ziel, dass automatische Bahngeneratoren diese Werte heranziehen, um prozess-spezifische Bahnen erzeugen zu können, beispielsweise der Winkel zur Bauteiloberfläche oder die Ausrichtung bezüglich der Schwerkraft (siehe Tab. 5.5). Wenn auch die Beweglichkeit des Roboters bei der Ausführung eines Prozesses auf eine Bahn gezwungen und damit eingeschränkt wird, so verbleibt im Allgemei­ nen dieser eine Freiheitsgrad entlang der Bahn, ansonsten würde sich der Roboter gar nicht mehr bewegen. Die per AutomationML definierten Freiheiten sollen die Tab. 5.4   Aktionen und ihre benötigten Informationen ID

Gruppen von Aktionen

Typ

Name Name der Aktion String Parameter Liste der Parameter der Aktion, gegeben durch Prozessgrößen Liste von Links auf Prozessgrößen Latency Latenzzeit, die angibt, wie lange es von der Auslösung bis zum Real Effekt auf dem Bauteil in Sekunden dauert

210

A. Keibel

Tab. 5.5   Modellierung von geometrischen Einschränkungen von Werkzeugen ID

Bedeutung

Typ

GravityAngle

Gibt den Winkel an, den das Werkzeug relativ zur Gravitation haben soll. 0° gibt an, dass es genau nach unten zeigen soll. 180° bedeutet, dass der Prozess nach oben gerichtet sein sollte Erlaubte Abweichung von der Vorgabe der Wirkungsrichtung bzgl. Gravitation. 180° bedeutet, dass die Gravitationsrichtung nicht relevant ist. 5° bedeutet, der Bearbeitungswinkel darf auch noch ±5° von der Schwerkraft abweichen Gibt den Winkel an, den das Werkzeug relativ zur Normalen der Bauteiloberfläche haben soll Erlaubte Abweichung von der Vorgabe der Wirkungsrichtung bzgl. Bauteiloberfläche. 180° bedeutet, dass die Bauteiloberfläche nicht relevant ist. 5° bedeutet, der Bearbeitungswinkel darf auch noch ±5° von der Flächennormalen abweichen Gibt den Winkel an, den das Werkzeug in Fahrtrichtung geneigt werden soll, so dass der TCP „hinterhergeschleppt“ wird. Null bedeutet, dass die Ausrichtung Fahrtrichtungsunabhängig ist. Ist der Winkel Negativ, dann „sticht“ das Werkzeug in die Bahn und wird über die Bahn „geschoben“

Real

GravityFreedom

NormalAngle NormalFreedom

PullAngle

Real

Real Real

Real

Räumlichkeiten mathematisch benennen, in denen das Werkzeug während des Prozesses bewegt werden kann, mit denen also der Bewegungsraum über die Bahnvorgaben hinaus erweitert wird. Als Beispiel sei eine Bohrmaschine genannt, deren Bohrer um die Bohrerachse gedreht werden kann, während der Vorschub den Bohrprozess in Bohrerrichtung bewegt. Diese Freiheitsgrade werden wie in Tab. 5.6 dargestellt in Toolkoordinaten angegeben, in dem für jede Dimension ein Intervall beschrieben wird. Beispiel elektrostatische Lackierpistole: Die Anwendung der hier beschriebenen datentechnischen Beschreibung soll anhand eines Beispiels erläutert werden. Hierzu wird eine elektrostatische Lackierpistole betrachtet. Die Prozessgrößen sind in Tab. 5.7 zusammengefasst. Die Prozessmethoden (Aktionen) sind vereinfacht in Tab. 5.8 dargestellt. Das Werkzeug soll nicht starr in Bahnrichtung geneigt werden. Die Freiheitsgrade und Beschränkungen des Prozesses sind (vereinfacht) in Tab. 5.9 aufgeführt. Alle diese Größen müssen mit Hilfe der AutomationML-Prozesswerkzeug-Definition elektronisch abgebildet werden und stehen damit einer weiteren elektronischen Datenverarbeitung zur Verfügung. Tab. 5.6   Parameter zur Definition von Freiheitsgraden ID

Bedeutung

Typ

XMin, XMax, YMin, YMax, ZMin, ZMax, RMin, RMax, PMin, PMax, YMin, YMax

Freiheitsgrade relativ zum Tool, ausgedrückt als Intervall der zugelassenen Translation und ZYX Euler-Darstellung (Euler 2009)

Real, Real, Real, Real, Real, Real, Real, Real, Real, Real, Real, Real

5  Ansatz zur integrierten Prozessbeschreibung

211

Tab. 5.7   Beispiel – Prozessgrößen einer Lackierpistole Prozessgrößen

Beschreibung

Paint Voltage HornAir Rotation Throughput Medium Cleaningtime

Steuergröße für den Hauptmedienstrom (Lack an/aus), auf der Bahn wählbar Elektrostatische Spannung (z. B. 30–80 kV), Preset Lenkvolumenstrom (z. B. 50–400 Nl/min), auf der Bahn wählbar Rotation Zerstäuber (an/aus), Preset Lackvolumenstrom (z. B. 20–200 ml/min), auf der Bahn wählbar Medium (1–4), auf der Bahn wählbar Reinigungsdauer (sek), auf der Bahn wählbar

Tab. 5.8   Beispiel – Prozess­methoden einer Lackierpistole

Prozessmethoden

Beschreibung

Selbstreinigung Medienwechsel

Dauer in Sek (Medium, Farbe)

Beispiel Schweißpistole: In einem weiteren Beispiel wird die Definition der benötigten Planungsdaten tabellarisch dargestellt. Dazu wird eine Schweißpistole betrachtet, die eine Schweißnaht durchführen soll. Dieses Beispiel soll als Basis für die weitere Modellierung eines Schweißwerkzeuges dienen. Die Daten für das beispielhafte Werkzeug werden in der folgenden Tabelle konform zur bisherigen Definition zusammengefasst (Tab. 5.10, 5.11, 5.12 und 5.13). Mit diesen Daten können mit AutomationML Werkzeugobjekte definiert werden. Diese Modellierung ermöglicht es, Werkzeuge auf Bahnen qualifiziert anwenden zu können und den Verlauf der Prozessgrößen zu beschreiben. Damit kann ein qualifiziertes Prozess-Engineering auf Prozessbahnen stattfinden, indem die Aufgabenstellung definiert wird, unabhängig von dem konkreten System, das diese Aufgabe letztendlich bewältigt. Im folgenden Abschnitt soll das Prozess-Objekt erläutert werden, das die Anwendung dieses Werkzeuges auf der Bahn beschreibt. Tab. 5.9   Beispiel – Freiheitsgrade einer Lackierpistole Freiheitsgrade

Beschreibung, Beispiel

Normal MaxRot MaxSpeed

Normal zur Bauteiloberfläche, mit ±10° Schwankungsbreite Zugelassene Rotation um Sprühstrahlachse um ±180° Maximale Prozessgeschwindigkeit = 0,5 m/s

Tab. 5.10   Beispiel – Grunddaten für eine Schweißpistole Grunddaten ToolName ID ToolType Shape

SIMPLE_ARC_GUN {9E3A86D9-854E-4692-B740-59460874FA38} „DIN8583.4.6“ COLLADA-REF.ARC.Gun

212 Tab. 5.11   Beispiel – Prozessgrößen für eine Schweißpistole

Tab. 5.12   Beispiel – Aktionen und Methoden für eine Schweißpistole

A. Keibel Prozessgrößen 1. Name Unit Default Range AllowedError UsedOnPath Latency 2. Name Unit Default Range AllowedError UsedOnPath Latency 3. Name Unit Default Range AllowedError UsedOnPath Latency 4. Name Unit Default Range AllowedError UsedOnPath Latency Aktionen und Methoden Name Parameter Latency

„Gasdruck“ N/m² 0,2 0.0–2.0 20% FALSE 0.5 s „Schweißstrom“ A 100 [25; 250] 8% TRUE 0.1 s „Lichtbogen“ – FALSE [FALSE, TRUE] 0% TRUE 0.02 s „Länge“ mm 28 [20, 40] 10% FALSE 0

„DrahtKürzen“ Länge (siehe Prozessgröße) 1.0

Tab. 5.13   Beispieldefinition für eine Schweißpistole Prozessspezifische Einschränkungen 0° GravityAngle 20° GravityFreedom 0° NormalAngle 30° NormalFreedom PullAngle −15° Prozessspezifische Freiheitsgrade Freedoms

[0.0,0.0; 0.0,0.0; 0.0,0.0; −180.0,180.0; −5.0,5.0; −5.0,5.0]

5  Ansatz zur integrierten Prozessbeschreibung

213

5.4.4  Modellierung des Prozess-Objektes Das Prozessobjekt verbindet die mit dem Werkzeug-Objekt definierten Methoden und Prozessgrößen mit der Definition einer kartesischen Bahn. Diese Verbindung wird hergestellt durch Verbindung/Referenzierung der Bahn, auf welcher der Prozess stattfinden soll, der Werkzeuge, die auf der Bahn angewendet werden sollen und Sequenzen mit Anweisungen zur Steuerung der Möglichkeiten (Prozessgrößen und Methoden) der Werkzeuge. Eine Prozessgröße hat auf einer Bahn stets einen definierten Wert ohne Definitionslücken, der sich zu jeder Zeit ändern kann. Es ist bemerkenswert, dass diese Form der Prozessdefinition rückwärts interpretiert werden kann, ohne dass die Prozessdefinition unsinnig wird. In Abb. 5.5 wird dies anhand eines Beispieles erläutert. Die Prozessbahn führe über die Targets A, B, C, D, E, F. Ein Werkstück soll von Position B nach Position E bewegt werden. Das abgebildete Werkzeug sei ein Greifer, die Prozessgröße heiße ClosedGripper und sei vom Typ Boolean. Die Anweisung zum Schließen oder Öffnen des Greifers in den Punkten B bzw. E wird typischerweise innerhalb des Roboterprogrammes oder in einer Schrittkette gegeben. Die Anweisungskette hierfür lautet dann: fahre zu A, fahre zu B, schließe Greifer, fahre zu C, fahre zu D, fahre zu E, öffne Greifer, fahre zu F Diese Anweisungskette ist nicht reversibel: wird sie rückwärts ausgeführt, ergibt sich nachfolgende Anweisungskette. Hierbei würde der Greifer in E geöffnet und das Bauteil an Ort und Stelle verbleiben.

Abb. 5.5   Beispiel: Pick & Place

214

A. Keibel

fahre zu F, fahre zu E, öffne Greifer, fahre zu D, fahre zu c, fahre zu B, schließe Greifer, fahre zu A Mit der in diesem Kapitel vorgeschlagenen Vorgehensweise ist die Prozessbeschreibung in ihrer Ausführungsrichtung umkehrbar. Da der Prozessparameter ClosedGripper mit seinem Prozesswert abgelegt wird, würde der Greifer im Punkt E schließen und nicht öffnen. Der Gegenstand würde korrekt zurückbewegt werden. Dies gilt auch für Klebe- oder Schweißprozesse: die Klebebahn oder Schweißnaht kann mit Hilfe dieser Vorgehensweise auch in umgekehrter Richtung korrekt ausgeführt werden. Diese Darstellungsform hat auch Vorteile bei vielen weiteren Bearbeitungsprozessen wie z. B. beim Bahnschweißen nach Abb. 5.2. Der Kerngedanke ist, mit Profilverläufen zu definieren, an welchen Stellen auf einer Bahn die Prozessparameter welche Werte annehmen, ganz gleich, ob die Bahn vorwärts oder rückwärts ausgeführt werden soll. Das Interessante daran ist, dass beim Rückwärtsfahren ein Montageprozess automatisch zu einem Demontageprozess wird, und dass bei Bearbeitungsvorgängen die Aufgabendefinition richtungsunabhängig erfolgen kann. Profile von Prozessgrößen sind kontinuierlich verlaufende Größen, wohingegen die Methoden des Werkzeuges an ausgezeichneten Punkten ausgeführt werden. Sie entsprechen Unterprogrammaufrufen, an denen bestimmte Funktionen des Werkzeugs aktiviert werden, z. B. Spülen beim Lackieren oder Kleben oder Draht-Abschneiden in unserem Schweiß-Beispiel. Mit Hilfe von Action-Nodes können im AutomationML-Objektmodell Aktionen definiert werden, die genau an einem Punkt auf der Bahn geschehen sollen, wie etwa: bohre ein Loch, fahre zum Kappenfräsen, Aktiviere einen Vorgang. Diese Actions sind Methoden, die von dem Werkzeug bereitgestellt werden. Sie werden genau wie Profile-Nodes behandelt, jedoch können diese erweiterte Datentypen beinhalten und für jeden Action-Node individuell sein. Ein Action-Node erbt die Default-Daten, die von dem Werkzeug bereitgestellt werden. Diese Default-Daten können dann an jeder Position der Verwendung eingestellt werden. Eine Action kann auch auf andere Pfade verweisen. Dies bedeutet, dass die aktuelle Bewegung an dieser Stelle unterbrochen und die verlinkte Bahn ausgeführt werden soll. Eine Action kann auch auf logische Elemente verweisen, die per PLCopen XML abgelegt sind. Ein Prozess verweist auf PLCopen XML als Actions auf Bahnen. Eine Prozessbahn verweist entweder auf Targets innerhalb von COLLADA oder auf vollständige Animationspfade in COLLADA.

5.5  Beispielmodellierung mit AutomationML Im Folgenden soll anhand konkreter Beispiele gezeigt werden, wie die hier vorgestellte Prozessbeschreibung mit Hilfe von AutomationML modelliert werden kann. Dazu wird der beschriebene Schweißprozess unter Verwendung des RoboterWerkzeuges mit Hilfe des frei verfügbaren AutomationML-Editors abgebildet (vgl. Abschnitt 5.4.3 ab Tab. 5.10).

5  Ansatz zur integrierten Prozessbeschreibung

215

Abb. 5.6   Prozessbeschreibungs-Bibliothek

Im ersten Schritt müssen die benötigten SystemUnit-Klassen in CAEX modelliert werden. Dazu wird in der eine Bibliothek Prozessbeschreibungsbibliothek angelegt (siehe Abb. 5.6). Hier werden der Klassen Werkzeug, Prozessgröße, Prozessaktion, Prozessbahn und Prozessabschnitt inklusive der benötigten Attribute modelliert. Diese Klassen können im Projekt beliebig oft instanziiert und mit individuellen Werten parametrisiert werden. Die Klassen zur Prozessbeschreibung werden in Tab. 5.14 erläutert. Die benötigten Schnittstellenklassen werden von der AutomationML-Standardschnittstellenbibliothek AutomationMLBaseInterfaceClassLib (siehe Abb. 5.7) zur Verfügung gestellt. Für die Prozessbeschreibung mit AutomationML sind dabei die Kinder der Klasse ExternalDataConnector relevant, mit denen die Geometrie Tab. 5.14   Beispielklassen für die Prozessbeschreibung Klasse Beschreibung Werkzeug Prozessführungsgröße Aktion Prozessbahn Prozessabschnitt

Klassenbeschreibung für das Werkzeug-Objekt. Dieses enthält eine Schnittstelle refGeo vom Typ COLLADAInterface. Diese referenziert die Geometrie des Werkzeuges Klassenbeschreibung für Prozessführungs-Objekte, z. B. einen Schweißstrom Klassenbeschreibung für eine Aktion, beispielsweise DrahtAbschneiden Klassenbeschreibung für die Prozessbahn. Diese Klasse dient zur Definition und Verlinkung mit den Objekten zur geometrischen Definition der Trajektorie Klassenbeschreibung für einen Prozessabschnitt. Die Schnittstelle refSFC vom Typ PLCopenXMLInterface dient zur Verknüpfung mit den PLCopen-XML-Dokumenten zur Darstellung von Prozessgrößenverläufen und Aktionsaufrufen. Der Verlauf einer Prozessgröße bezieht sich auf eine Bahn, die auf einem Bauteil liegt und die Prozessgröße wird von einem Werkzeug bereitgestellt. Diese Zusammenhänge werden über Verknüpfungen zwischen den Schnittstellen PPR vom Typ PPRConnector in AutomationML abgebildet. Jedes relevante Objekt muss deshalb über eine solche Schnittstelle verfügen

216

A. Keibel

Abb. 5.7   AutomationML-Standardschnittstellenklassen

des Werkzeuges bzw. der Bahn und die Prozessgrößenverläufe referenziert werden können. Die Schnittstellenklasse COLLADAInterface wird daher wie in Kap. 3 beschrieben zur Referenzierung von Geometrien der Werkzeuge und des Bauteile verwendet. Das PLCopenXMLInterface wird wie in Kap. 4 beschrieben verwendet, um die Verbindung zwischen Prozessgrößen und deren Verläufen herzustellen, die per SFCs wie in Abb. 5.12 abgebildet werden. Die Schnittstellenklasse PPRConnector wird benötigt, um die Relationen zwischen den benötigten Objekten abzubilden. Neben der System-Unit-Bibliothek wird hier eine eigene abstrakte Rollenbibliothek eingeführt – die ProcessRoleClassLib (siehe Abb. 5.8). Im Sinne der Aufgabenstellung zur Darstellung von Bearbeitungsprozessen werden hier die Rollenklassen ProcessVariable, ProcessAction, ProcessTrajectory und ProcessVariableChart definiert. Diese Rollen ermöglichen, zwischen den unterschiedlichen Objekttypen unterscheiden zu können. Auf diese Wiese wird die Interpretation von Objekten durch die verarbeitenden Software-Tools erleichtert und die im folgenden erzeugten

Abb. 5.8   Rollenbibliothek zur Prozessbeschreibung

5  Ansatz zur integrierten Prozessbeschreibung

217

Abb. 5.9   Rumpf des CAEX-Objektmodells

nutzerdefinierten AutomationML-Objekte mit einer „erkundbaren“ Semantik versehen. Mit Hilfe dieser Klassendefinitionen lassen sich die für eine Prozessbeschreibung benötigten Bahnobjekte, Werkzeugobjekte und Prozessobjekte beschreiben. Im nachfolgenden Beispiel wird dies verdeutlicht. Die Aufgabenstellung lautet: Eine Ressource Schweißpistole soll auf der Prozessbahn2 des Produktes Autokarosse den Prozess SchweißenUnterbodenRechts durchführen. Zur Modellierung in AutomationML kommt das Ressource-ProduktProzess-Konzept zur Anwendung, das in Abschnitt 2.9.6 erläutert wurde. Zu Beginn der Modellierung wird in AutomationML eine Anlagenhierarchie angelegt und mit einem Namen – hier Beispielprojekt – versehen. In dieser wird das Objekt Anlage als eingehängt. Unterhalb dieses Objektes werden nun drei weitere AutomationML-Objekte angelegt: Ressource, Process und Product. Ihnen werden jeweils die entsprechenden o. g. Rollenklassen zugeordnet, um ihre spätere automatische Identifizierbarkeit zu gewährleisten. Diese drei Objekte stellen die Anfangsknoten von drei Substrukturen dar und bilden den Rumpf des CAEX-Objektmodells. Das Zwischenergebnis ist in Abb. 5.9 abgebildet. Diese Substrukturen werden nun weiter verfeinert, indem die Objekte Ressource, Process und Product mit weiteren Objekten ausmodelliert wird (siehe Abb. 5.10). Substruktur Ressource: In dieser Struktur werden die benötigten Werkzeugobjekte definiert. In diesem Beispiel wird die Klasse Werkzeug instanziiert und somit ein AutomationML-Objekt Schweißpistole erzeugt und mit der Basis-Rolle Resource assoziiert. Um die Aktionen und Prozessgrößen dieser Pistole zu modellieren, werden weitere Kindobjekte an das Objekt Schweißpistole angehängt. Das Objekt DrahtKürzen beschreibt eine Methode der Pistole. Dessen Kindobjekt Länge beschreibt die Solllänge des Drahtes – diese Größe wird beim Aufrufen der Aktion DrahtKürzen ausgelesen und entsprechend berücksichtigt. Das Objekt Lichtbogen ist eine digitale Prozessführungsgröße, die anzeigt, wo auf der Bahn eine Schweißnaht liegen soll. Gasdruck und Schweißstrom sind weitere analoge Prozessgrößen, die mit Hilfe eines Prozessabschnittes auf einer Prozessbahn gesetzt werden können. Mit der Schnittstelle PPRSchweißPistole wird die Verknüpfung mit den Objekten Produkt und Process hergestellt. Die Schnittstelle refGeo referenziert die Geometrie und Kinematik der Schweißpistole. Substruktur Process: In dieser Struktur werden die Abschnitte des Prozesses definiert. Der einzige hier betrachtete Prozessabschnitt wird als AutomationMLObjekt modelliert und heißt hier SchweißenUnterbodenRechts1. Dieser repräsentiert den Verlauf der verwendeten Prozessvariablen über die Bahn. Der tatsächliche Ver-

218

A. Keibel

Abb. 5.10   Beispielprojekt Bahnschweißen

lauf wird allerdings nicht in CAEX, sondern in einem PLCopen-XML-Dokument als SFC modelliert. Das AutomationML-Objekt benötigt folglich eine Referenz zu diesem SFC: dies erfolgt mit Hilfe der Schnittstelle refSFC. Ein solches BeispielSFC ist in Abb. 5.12 dargestellt. Substruktur Product: In dieser Struktur wird das zu bearbeitende Produkt modelliert – in diesem Fall repräsentiert durch das AutomationML-Objekt AutoKarosse. Diesem Bauteil sind über PPR-Connectoren mehrere Prozessbahnen zugeordnet. Nur eine davon soll später verwendet werden. Alle drei Substrukturen sind in Abb. 5.10 inklusive der Verknüpfung zwischen den in der Aufgabenstellung definierten Ressourcen, Produkten und Prozessen dargestellt. Verknüpfung zwischen Prozess, Produkt und Ressource: In diesem Beispiel soll die Schweißpistole auf der Prozessbahn1 einen Prozess SchweißenUnterbodenRechts1 durchführen. Dazu werden drei Verbindungen vom Typ benötigt und die zugehörigen Schnittstellen vom Typ PPRConnector verknüpft. Alle drei Links sind in Abb. 5.10 durch Pfeile dargestellt, ihre Modellierung mit AutomationML wird in Abb. 5.11 abgebildet.

5 Ansatz zur integrierten Prozessbeschreibung

219

Abb. 5.11   Verknüpfungen zwischen den Objekten

Bezüglich der Relationen gelten folgende Regeln: eine Ressource darf mehrere Bahnen referenzieren. Ein Prozessabschnitt darf mehrere SFCs referenzieren. Aber ein Prozessabschnitt darf nur eine Bahn referenzieren, damit eindeutig ist, wo der Prozess stattfinden soll. Der Prozessgrößenverlauf wird mittels PLCopen XML als SFC abgebildet. Dies ermöglicht zum einen die Definition der benötigten Datentypen und zum anderen die zielgerichtete Veränderung der verwendeten Prozessgrößen an diskreten Punkten. Jede Prozessgröße wird als hier in einem eigenen SFC abgebildet. In Abb. 5.12 sind vier SFCs exemplarisch dargestellt. Es ist vorgesehen, dass jedes SFC den Verlauf einer Prozessgröße beim Abfahren der Bahn beschreibt. Der Bahnindex erhöht sich während des Fahrens auf der Bahn monoton. Die Schritte sind den einzelnen Bahnabschnitten zugeordnet: die Transitionen bestimmen den jeweils erforderlichen Bahnindex. Sobald ein definierter Bahnindex erreicht ist, erfolgt der Übergang von einem Schritt zum nächsten. In den zugehörigen Aktionen wird die SFC Schweissen start Bahnpar ≥ 2,2 step1

s StromEin

SFC Schweisstrom start Bahnpar ≥ 1,92

step2

r StromEin

Bahnpar ≥ 2,6 Bahnpar ≥ 2,8 Bahnpar ≥ 10

SFC Schutzgas start Bahnpar ≥ 1,6 s GasEin Bahnpar ≥ 3,6 r GasEin Bahnpar ≥ 10 end

s Schweissstrom = 0A

step2

end

step2

s Schweisstrom = 80A

step2

Bahnpar ≥ 10

step1

s Schweisstrom = 100A

step1

Bahnpar ≥ 2,8

end SFC Draht start Bahnpar ≥ 4,0 step1

n Aktion:DrahtAbschneiden Bahnpar ≥ 10

end

Abb. 5.12   Prozessgrößenverläufe per SFC definieren

220

A. Keibel

Prozessgröße entsprechend dem Bahnabschnitt verändert. Im Ergebnis wird für die Prozessgröße ein durchgängiger Verlauf der Prozessgrößen auf der Bahn definiert. Details zu dieser Abbildung werden in Beispielen auf der AutomationML-Internetseite gegeben (AutomationML 2009).

5.6  Zusammenfassung In diesem Kapitel wird ein Konzept vorgeschlagen, wie Aufgabenbeschreibungen für Prozesse technologieneutral abgebildet werden können. Dabei werden keine engen Grenzen gesetzt. Bestehende und neue Technologien können auf einem Abstraktionsniveau datentechnisch erfasst werden, wodurch sich eine Aufgabenstellung zwischen verschiedenen Softwarewerkzeugen bewegen lässt. Die detaillierte Ausformulierung und konkrete Abbildung verschiedener Bearbeitungstechnologien bleibt uneingeschränkt der Kreativität der Anwender überlassen. Die Übertragbarkeit und Anpassung an hardwaretechnische Gegebenheiten wird nicht vorweggenommen, so dass trotz eines neuen Abstraktionsniveaus die erforderliche Flexibilität uneingeschränkt erhalten bleibt. Ein neutrale Prozessbeschreibung eröffnet eine Reihe neuer Möglichkeiten und Vorteile: Roboterprogramme könnten automatisch generiert werden. Roboterprogramme würden künftig leichter wartbar, weil sie einen Bezug zur Aufgabenstellung erhalten. Technologien können ausgetauscht werden, ohne die Gültigkeit der Prozessbeschreibung zu verlieren. Roboterprogramme könnten automatisch geprüft werden, indem die zugrundeliegende neutrale Prozessbeschreibung auf Plausibilität geprüft wird.

Literatur AutomationML (2009), http://www.automationml.org BPML (2009), Business Process Modelling Language, http://de.wikipedia.org/wiki/Business_ Process_Modeling_Language DIN (8580), http://de.wikipedia.org/wiki/Fertigungsverfahren Euler (2009), http://de.wikipedia.org/wiki/Eulerwinkel ISO (2009a), 10303, http://en.wikipedia.org/wiki/ISO_10303 ISO (2009b), TC 184/SC 1/WG 7, http://www.iso.org/iso/catalogue_detail.htm?csnumber=40895 ISO (2009c), 13399, http://en.wikipedia.org/wiki/ISO_13399 Keibel A (2002), Konzeption und Realisierung eines integrierten Moduls zur Simulation und Steuerung von Kinematiksystemen. Elektronische Ressource der Deutschen Nationalbibliothek, http://d-nb.info/968909442 PSL (2009), Process Specification Language, http://www.aaai.org/ojs/index.php/aimagazine/ article/view/1719/1617 Rokossa D (1999), Prozessorientierte Offline-Programmierung von Industrierobotern. ISBN-10: 3826569458, Shaker Verlag GmbH (24. Januar 2000)

Kapitel 6

Praktische Anwendung Rainer Drath, Dirk Weidemann, Steffen Lips, Lorenz Hundt,   Arndt Lüder und Miriam Schleipen

6.1  Überblick „Bubbles don’t crash!“ – mit diesem unter Software-Entwicklern beliebten Leitsatz wird die Problematik von Präsentationen, Architekturbeschreibungen und Spezifikationen prägnant zusammengefasst. Papier ist geduldig; für den nächsten Schritt zum Nachweis der Korrektheit wird lauffähige Software benötigt. Beides, Papier und Software, sind jedoch nur Vorarbeiten für die Lösung realer Probleme. Ziel dieses Kapitels ist, verfügbare Software vorzustellen und Ansätze, Beispiele sowie Empfehlungen für die Verwendung von AutomationML aufzuzeigen. Inhaltlich ist das Kapitel dazu in verschiedene Themen aufgeteilt, die wie folgt aufeinander ­aufbauen: • Vorstellung von Referenzwerkzeugen, die von der AutomationML-Gruppe zur Verfügung gestellt werden, • Vorstellung von Konvertern zum Datenaustausch zwischen AutomationML und anderen Standards oder proprietären Datenformaten, • Vorstellung von „Philipp“ – einem durchgängig mit AutomationML modellierten Beispiel, das kinematisierte Komponenten in Kombination mit Ablaufbeschreibungen umfasst, • Beispiel zur Modellierung von OPC-Konfigurationen mit AutomationML, • Handlungsempfehlungen zum Umgang mit großen CAEX- und COLLADADateien, • Empfehlungen zur Einführung von AutomationML im Engineering-Workflow. Im Abschnitt 6.2 werden Referenzwerkzeuge für AutomationML beschrieben. Mitglieder der AutomationML-Gruppe haben zum Testen und zur Veranschaulichung neuer Konzepte eine Reihe von Software-Werkzeugen entwickelt und stellen sie R. Drath () ABB AG, Forschungszentrum,Wallstadter Str. 59, 68526 Ladenburg, Deutschland E-mail: [email protected] R. Drath (Hrsg.), Datenaustausch in der Anlagenplanung mit AutomationML, DOI 10.1007/978-3-642-04674-2_6, © Springer-Verlag Berlin Heidelberg 2010

221

222

R. Drath et al.

als Open Source oder als Freeware zum Download zur Verfügung (AutomationML 2009). Interessenten können sich mit ihnen leicht und effizient in AutomationML „hands-on“ einarbeiten. Damit ist zugleich der Hinweis verbunden, dass diese Software-Werkzeuge nicht für den produktiven Einsatz vorgesehen und getestet wurden. Eine produktive Nutzung wird bereits durch die Lizenz der Freeware untersagt. • Mit dem AutomationML Editor der Zühlke Engineering GmbH können AutomationML-Dateien geöffnet, visualisiert, manipuliert und gespeichert werden. AutomationML-Objekte, Klassen, Rollen und Schnittstellen sowie ihren Beziehungen werden mit wenigen Mausklicks erzeugt. Dieses Werkzeug ermöglicht einen didaktisch wirkungsvollen Einstieg in die Objektwelt und die Bibliothekskonzepte von AutomationML bzw. CAEX und ist daher insbesondere als Einstiegswerkzeug geeignet (Pirsch u. Weidemann 2008a). • Zur Darstellung von COLLADA-Dateien für Geometrie wird im AutomationML Editor der Open Scene Graph (OSG) genutzt, der als Open-Source-Tool im Internet zur Verfügung steht. • Mit dem AutomationMLLogic Editor der Zühlke Engineering GmbH können Abläufe und Verhalten mittels PLCopen XML visualisiert und editiert werden (Breithor u. Weidemann 2009) • Die AutomationML Engine ist eine Software-Komponente, die von interessierten Unternehmen für Demonstrationen und Evaluierungen in ihre Werkzeuge eingebettet werden kann. Mit ihr können AutomationML-Dateien erstellt, eingelesen, verändert und gespeichert werden. Diese Softwarekomponente wurde zusammen mit dem AutomationML Editor von Zühlke entwickelt und wird von diesem bereits genutzt (Pirsch u. Weidemann 2008b). • Zur Bearbeitung und Visualisierung von COLLADA-Dateien stehen einige Tools als Open Source im Internet zur Verfügung. Dazu gehören das ­COLLADA DOM zum Lesen und Schreiben von COLLADA-Dokumenten, der ­COLLADA StreamWriter zum schnellen, Stream-basierten Schreiben von COLLADADokumenten, COLLADA Sax Loader zum Sax-basierten, schnellen Lesen von COLLADA-Dokumenten, der MathMLSolver als Bibliothek zum Lesen und Evaluieren von MathML-Dokumenten sowie der NVSG Viewer als leistungsfähiger Viewer zum Betrachten von COLLADA-Dokumenten. Abschnitt 6.3 und 6.4 stellen erste Konverter vor, die Daten vielfältiger Quellen nach AutomationML und zurück transformieren. Im Rahmen der Standardisierung konnte nicht erwartet werden, dass etablierte Werkzeuge der Anlagenplanung bereits AutomationML-Schnittstellen zur Verfügung stellen. Um frühzeitig eine Überprüfung der Tragfähigkeit von AutomationML durchführen zu können und möglichst schnell erste Geschäftsfälle produktiv zu unterstützen, waren daher eigene Konvertierungswerkzeuge notwendig. Im Rahmen von AutomationML wurden das „Graphic Conditioner Pipeline Framework“ (CPF) der NetAllied Systems GmbH und das Logic CPF der Universität Magdeburg entwickelt. Wie die Namen andeuten, handelt es sich bei beiden

6  Praktische Anwendung

223

Konvertern jeweils um eine Sammlung von Werkzeugen (Framework). Jedes dieser Werkzeuge implementiert entweder einen bestimmten Konverter von einem Drittformat zu AutomationML, COLLADA oder PLCopen XML beziehungsweise in die Gegenrichtung, oder es bietet eine bestimmte Aufbereitung (Conditioning) der Daten. Durch Kombinieren von Konvertern und Conditionern können sogenannte „Pipelines“ definiert werden. Der typische Anwendungsfall ist für beide Frameworks, dass Daten von einem Werkzeug A zu einem anderen Werkzeug B transportiert werden sollen, wobei beide Werkzeuge noch spezielle Anforderungen an Daten stellen. Ein CPF importiert die Daten dann von A nach AutomationML, bereitet sie eventuell durch einen oder mehrere Conditioner innerhalb der „Pipeline“ auf und exportiert sie dann als Datei im Datenformat des Tools B. Während das Graphic CPF Topologien, Geometrien und Kinematiken mit CAEX und COLLADA behandelt, wird das Logic CPF für die Transformation von Logikdaten von und nach PLCopen XML verwendet. In Abb. 6.1 werden die Beziehungen der AutomationML-Werkzeuge und -Komponenten mit externen Komponenten verdeutlicht. Abschnitt 6.5 erläutert Schritt für Schritt, wie ein mechatronisches System mit Hilfe des AutomationML Editors in einer AutomationML-Datei abgebildet werden kann. Nachdem wesentliche Konzepte für Topologie, Einbindung von Geometrie und Kinematik sowie Ablauf- und Verhaltensbeschreibungen entwickelt waren und jedes für sich gute Bewährungen erfahren hatte, sollten diese Bestandteile erstmalig in einem gemeinsamen Modell zusammengeführt werden, um die ganzheitliche Anwendbarkeit von AutomationML an einem konkreten Beispiel zu prüfen. Dazu wurde ein einfaches mechatronisches System konzipiert. Ein simpler geometrischer Körper mit Armen und Gelenken würde genügen. Wichtig war, dass dieses Modell „zappeln“ sollte, also eine Kombination von geometrischen, kinematischen und verhaltensbezogenen Daten beinhalten musste – „Philipp“ war geboren. read/write

Logic Editor

read/write

Logic

PLCopen XML

read/write

_____ _____ _____

Logic CPF*)

references

read/write

Logic

AutomationML Editor





read/write

AutomationML Engine

Topology

_____ _____ _____ _____ _____ _____

read/write

read/write

External _____ Formats _____ _____ _____ _____ _____



Graphic CPF*)

references

read/write

Topology Geometry

Open Scene Graph

read/write

Geometry G e om e try

COLLADA _____ _____ _____

read/write

read/write *) CPF = Conditioner Pipeline Framework

Abb. 6.1   Zusammenspiel verschiedener Werkzeuge für AutomationML

read/write

External Tools Plant Engineering

224

R. Drath et al.

Abschnitt 6.6 widmet sich der Abbildung von OPC-Konfigurationen mit AutomationML. OPC wurde 1996 spezifiziert, um einen einheitlichen Zugriff für Beobachtungs- und Steuerungssysteme auf Geräte unabhängig von den vielen verschiedenen industriellen Feldbussystemen zu erreichen. Als mittlerweile weit verbreiteter Kommunikationsstandard für Client/Server-Anwendungen hat OPC eine besondere Bedeutung für die Digitale Fabrik. So werden bereits auf Simulationsebene teilweise umfangreiche OPC-Konfigurationen erstellt, deren Weitergabe in die Phase der Steuerungsplanung erhebliche Einsparungen ermöglicht. Nachdem die ersten Abschnitte herausarbeiten, wie und mit welchen Mitteln Anlagendaten mit AutomationML beschrieben werden können, sollen in den abschließenden Unterkapiteln 6.7 bis 6.9 Handlungsempfehlungen zum Umgang mit den Daten im Engineering beschreiben. Dies ist notwendig, da AutomationML nur ein Datenformat ist und somit keine Funktionalität zur Wahrung der Datenkonsistenz über mehrere Engineering-Schritte oder bei paralleler Entwicklung bietet. Hierzu gehört die Verwaltung von in der Praxis vorkommenden, teilweise immensen Datenmengen, die bei der Beschreibung von Komponenten, Zellen, Teilanlagen oder ganzer Fertigungslinien anfallen. Dies betrifft zunächst topologische Daten. Eine Auftrennung beispielsweise entlang von Zellengrenzen bietet sich an, ist aber wegen gegenseitiger Abhängigkeiten nicht trivial. Darüber hinaus ist das Volumen von Geometriedaten typischerweise um ein Vielfaches größer, gerade wenn unterschiedliche Detaillierungsgrade zur selben Geometrie verwaltet werden. Sowohl CAEX wie auch COLLADA unterstützen die Referenzierung zwischen Dokumenten, so dass eine Multidokumentenarchitektur in beiden Fällen nahe liegend ist und auch empfohlen wird. Ein weitere Aspekt ist die Betrachtung von Workflows: was passiert, wenn mehrere Ingenieure gleichzeitig eine Anlagenbeschreibung lesen und verändern? Nach welchen Regeln können sie ihre Änderungen zurück schreiben? In der Software-Entwicklung nutzt man für diese Problemstellung Konfigurationsmanagement-Tools, bei denen modifizierte Teile nach dem Einchecken regelmäßig wieder in das Gesamtsystem integriert werden. Wie kann diese bewährte kontinuierliche Integration für die Anlagenplanung in einer heterogenen Werkzeuglandschaft mit verteilten Teams implementiert werden? Eine unüberlegte Einführung oder ein falsches Verständnis von AutomationML kann zu hohem und teurem Aufwand führen. Abschnitt 6.9 fasst Empfehlungen zur Einführung von AutomationML zusammen.

6.2  Referenzwerkzeuge 6.2.1  Editieren und Visualisieren mit dem AutomationML Editor Mit der Auswahl von CAEX als AutomationML-Dachformat wurde ein Werkzeug benötigt, das sowohl CAEX selbst als auch alle AutomationML-spezifischen Zusatzfestlegungen beherrscht. Mit ihm sollte die Modellierung und herstellerunab-

6  Praktische Anwendung

225

hängige Speicherung von Anlagenstrukturen zugänglich, verständlich und nutzbar gemacht werden. Dieses Werkzeug sollte einen schnellen Einstieg in die Objektwelt und die Bibliothekskonzepte von AutomationML ermöglichen und insbesondere auch als Einstiegswerkzeug geeignet sein. Da ein solches Werkzeug zum Zeitpunkt der AutomationML-Entwicklung nicht verfügbar war, wurde der AutomationML Editor entwickelt, der zusammen mit Beispielen und Dokumentation auf der AutomationML-Internetseite kostenfrei verfügbar ist (AutomationML 2009). Der AutomationML Editor dient vorrangig zum Editieren, Visualisieren und Manipulieren der Anlagentopologie sowie aller von CAEX unterstützten Bibliotheken. Die Benutzer des Werkzeuges können eigene Komponenten, Rollen oder Schnittstellen per Mausklick erzeugen, Bibliotheken erstellen und Objekte in der Instanzhierarchie zusammensetzen. Neben diesen Objektstrukturen werden auch COLLADA- und PLCopen-XML-Dateien visualisiert. Wie Abb. 6.2 zeigt, stehen dem Anwender nach dem Start des Werkzeuges zwei Geometrie-Ansichten, vier Tree-Views sowie Formularfelder für Header-, Revision- und Element-Attribute-Information zur Verfügung. Header-Informationen beinhalten Versionsnummern, Copyright-Hinweise, Beschreibungen und zusätzliche Informationen zu dem gerade selektierten Objekt. Revisions-Informationen sind essentiell für eine Nachverfolgung der Anlagenplanung. Sie beinhalten Datum und Autor der Revision, Hinweise auf Vorgänger- und Nachfolgerversionen sowie Kommentare zur Revision. Element-Attribute dienen zur Speicherung von Objekteigenschaften. Für den Einstieg in AutomationML sind die vier Tree-Views von zentraler Bedeutung. Sie bilden die Instanzhierarchie sowie die Klassen-, Rollen- und Schnittstellenbibliotheken in sehr enger Anlehnung an die Architektur von CAEX nach IEC 62424 ab. Neue Elemente der Instanzhierarchie werden beispielsweise erzeugt,

Abb. 6.2   AutomationML Editor

226

R. Drath et al.

indem sie entweder per Maus angelegt oder aber per Drag&Drop aus einer Klasse der SystemUnitClassLib instanziiert werden. Darüber hinaus können diese Hierarchien mit den üblichen Mechanismen editiert und gelöscht werden, am einfachsten mit dem kontextsensitiven Menü über die rechte Maustaste oder mit Copy&Paste bzw. Drag&Drop. Umgekehrt ist es auch möglich, aus einzelnen Instanzen Klassen zu erzeugen. Dies ist ein Vorteil der identischen Architektur von SystemUnit-Klassen und Objektinstanzen. CAEX ermöglicht zwar eine Typisierung, erzwingt sie aber nicht (siehe Abschnitt 2.4.1). So können Objekte in der Instanzhierarchie ohne Klassenzuordnung angelegt und mit gewünschten Attributen versehen werden. Die Nutzung des Werkzeuges wird in Abschnitt 6.5 schrittweise erläutert. Der AutomationML Editor kann als reiner CAEX-Editor verwendet werden, da AutomationML das Dateiformat CAEX unmodifiziert verwendet. AutomationML legt jedoch mit Hilfe von Bibliotheken und Vereinbarungen zusätzlich fest, in welcher Form CAEX für die Darstellung von Informationen zu verwenden ist. Dies erleichtert später eine semantische Interpretierbarkeit dieser Informationen. Der Editor dient der AutomationML-Gruppe zum Testen unterschiedlicher Ideen und Modellierungsansätze. Soll ein neues Engineering-Konzept wie das GruppenKonzept mit AutomationML abgebildet werden, so werden Lösungsansätze dazu mit CAEX-Mitteln entworfen, verglichen und getestet. Das Ergebnis wird im Anschluss als Vereinbarung festgelegt. Die Mitglieder der AutomationML-Gruppe konnten auf diese Weise frühzeitig ihre Ideen verifizieren. Wie auch für das Verständnis der AutomationML-Architektur hilft es für die Arbeit mit dem Automati­ onML Editor, wenn man sich vorab ein Grundverständnis von CAEX erarbeitet und zusätzlich die semantischen Festlegungen von AutomationML kennt. Mit diesem Vorwissen erschließt sich die Navigation im Editor schnell. CAEX erlaubt, mehrere Instanzhierarchien und Klassenbibliotheken gleichzeitig abzubilden. Diese Hierarchiesichten folgen im Wesentlichen den Regeln von CAEX, doch in der Ansicht für die Instanzhierarchie werden für InternalElements unterschiedliche Icons verwendet – je nachdem, ob sie eine Geometrie besitzen oder nicht. Im Beispiel von Abb. 6.3 besitzen die einzelnen Pulte und Schalt-

Abb. 6.3   Eine Instanzhierarchie mit ihren Objekten

6  Praktische Anwendung

227

schränke neben Topologie-Informationen auch Geometriebeschreibungen in separaten COLLADA-Dateien, die über in AutomationML definierten Schnittstellen COLLADAInterface verknüpft sind. Für jedes Objekt können dessen durch CAEX vordefinierte AdditionalProperties sowie die Liste der zugehörigen nutzerdefinierten Attribute editiert werden. CAEX selbst macht hier keine Vorgaben, AutomationML schreibt hingegen einige Attribute vor. Ein Beispiel dafür ist das Attribut Frame, welches die Positionierung einer Komponente relativ zum nächsthöheren Objekt in der Komponentenhierarchie festlegt. Weitere nutzerdefinierte Attribute können beliebig angelegt und mit Werten belegt werden. Dieser Erweiterungsmechanismus von CAEX ist sehr hilfreich zum Erstellen nutzerdefinierter Bibliotheken oder Produktkataloge. Allerdings ist dann die Semantik der Eigenschaften nicht standardisiert. Dies birgt die nicht zu unterschätzende Gefahr, dass jeder Anwender mit diesem Metakonzept seine Komponenten anders definiert und deren Austausch damit behindert. Datenerzeuger und -anwender können dieses Problem entweder durch Vereinbarungen über eine gemeinsam genutzte SystemUnit-Bibliothek oder über die Verwendung gemeinsamer Rollenbibliotheken lösen. Für beide Bibliotheken bietet der AutomationML Editor einen eigenen Tree-View an, in dem mit den üblichen Mitteln editiert werden kann. Wegen der herausragenden Bedeutung von Rollen und natürlich auch der Klassenzugehörigkeit werden diese an jeder Instanz der Instanzhierarchie wie in Abb. 6.3 visualisiert. Schnittstellen bzw. Interfaces sind ein wesentliches Mittel, um Objekte miteinander in Relation zu setzen. Neben dem Referenzmechanismus bilden sie einen wichtigen Teil des Glue for Seamless Automation Engineering, den AutomationML für sich beansprucht. Verbindungen zwischen Objekten werden ausschließlich durch Links zwischen ihren Schnittstellen abgebildet – diese sind naturgemäß sehr unterschiedlich. Typische Schnittstellen sind Materialflussknoten, Signalschnittstellen, Energieversorgungsschnittstellen, Analogverbindungen mit einem bestimmten Spannungsintervall, Anschlusspunkte für Hydraulik- oder Pneumatik, Stutzen usw. Entsprechend werden unterschiedliche Schnittstellentypen benötigt. Um zwei oder mehr AutomationML-Objekte in der Instanzhierarchie zu verknüpfen, muss folglich zuerst allen beteiligten Komponenten eine geeignete Schnittstelle zugeordnet werden. Diese werden anschließend mit einem InternalLink einander zugeordnet. Der AutomationML Editor bietet für die Interface-Bibliotheken einen eigenen TreeView, in dem sie angelegt und gepflegt werden können. Die Verlinkung erfolgt am einfachsten, indem per Drag&Drop eine der beiden Schnittstellen auf die andere gezogen wird. Auch ein manuelles Eintragen und Editieren ist möglich, aber naturgemäß fehleranfällig. Neben den vier Säulen von CAEX für die Anlagentopologie stützt sich AutomationML auf COLLADA und PLCopen XML für Geometrien und Kinematiken beziehungsweise für Logikdarstellungen ab. Der AutomationML Editor kann COLLADAGeometrien der einzelnen Komponenten zu einer gesamten Szene oder zu Teilszenen zusammenfügen und in zwei eigenen Fenstern darstellen, für die der Editor das Freeware-Tool Open Scene Graph einbindet. Eines der Fenster zeigt die erstellte Szene, das andere die gerade selektierte Komponente. Zur Berechnung der Szene untersucht der Editor die Anlagentopologie rekursiv und wertet die Eigenschaft Frame sowie die referenzierte Geometriedatei jeder Komponente aus. Nach der Berechnung der

228

R. Drath et al.

Gesamtszene wird daraus eine neue COLLADA-Datei erstellt. Weil die Berechnung komplexer Szenen häufig sehr aufwändig ist, wird dies im Hintergrund als eigener Thread ausgeführt, so dass der Nutzer weiterarbeiten kann. Die Verknüpfung zu COLLADA-Dateien birgt prinzipielle Probleme, vor Allem ihr Auffinden auf einem Speichermedium oder in einem Netzwerk. Im einfachen Fall werden diese Dateien zusammen mit Topologiebeschreibungen von einem anderen Rechner in ein eigenes Verzeichnis kopiert – nur stimmen dann in der Regel die Pfade nicht mehr. Einstellungen zum Umgang mit COLLADA-Dateien können entsprechend im AutomationML Editor direkt vorgenommen werden. Eine weitere Darstellung bietet der AutomationML Editor für Abläufe oder Verhaltensbeschreibungen aus PLCopen-XML-Dateien. AutomationML-Objekte referenzieren diese Dateien über eine Schnittstelle vom Typ PLCopenXMLInterface. Für die Visualisierung wird der AutomationMLLogic Editor in eigenen Fenstern eingebunden. Da der Logic Editor auch als eigene Applikation lauffähig ist, wird er später detailliert beschrieben. In diesem Buch wurde mehrfach dargestellt, dass Planungsdaten unvollständig oder sogar inkonsistent sein können. Unerwünschte Fehler sind beispielsweise das Referenzieren nicht existenter Klassen, fehlerhafte Links oder fehlende Dateien. Diese Fehler sind manuell nur aufwändig zu finden – der AutomationML Editor nimmt daher beim Öffnen, Speichern oder durch eine Nutzerinteraktion automatisch einen gewissen Umfang an Syntaxprüfungen vor. Das Ergebnis wird in der Status Bar im Editor unten angezeigt. Manuell kann dies mit Perform all Checks angestoßen werden. Fehler werden in einem eigenen Fenster angezeigt, siehe Abb. 6.4.

Abb. 6.4   Ergebnisse der Konsistenzprüfung

6  Praktische Anwendung

229

Zur Bedienung des AutomationML Editors abschließend noch eine kurze Bemerkung: der Editor ist auf der Basis des Microsoft .NET 3.5 Frameworks mit Nutzung der Windows Presentation Foundation (WPF) entwickelt, um eine moderne Benutzeroberfläche zur Verfügung zu stellen. Es ist jedem Anwender damit möglich, sich leicht mit standardisierten Mechanismen seine bevorzugte Arbeitsumgebung zu konfigurieren. Beispielsweise können sich mehrere Views mit Tabs ein gemeinsames Fenster teilen, Fenster können angedockt oder mit Pins fixiert bzw. frei beweglich gehalten werden. Die verfügbaren Optionen für die Ansicht können in einem Drop-down-Menü im Fenster aktiviert werden. Nicht benötigte Fenster wie beispielsweise für die Ergebnisse der Konsistenzprüfung oder für die internen Links sind anfänglich am linken Rand der Applikation verborgen. Sie werden sichtbar, wenn man mit der Maus über sie fährt. Ähnliches gilt für die zusätzlichen Eingabefenster für Attribute und Additional Properties. Wenn sie nicht mit Pins fixiert sind, verschwinden sie bei Nichtbenutzung am unteren Rand der Applikation und werden erst sichtbar, wenn man mit der Maus über diesen Rand fährt. Der Nachteil dieser an sich wünschenswerten hohen Flexibilität ist die mögliche Verwirrung, wenn Anwender ihre Einstellungen zu komplex wählen, bis sie bestimmte Ansichten eventuell selbst nicht mehr wieder finden. Dafür steht als Ausweg eine Funktion Restore Default Layout zur Verfügung. Eine detailliertere Beschreibung des AutomationML Editor erfolgt in (Pirsch u. Weidemann 2008a).

6.2.2  AutomationML Logic Editor Auch für den Logikteil von AutomationML standen zu Beginn der Spezifikation keine frei verfügbaren Werkzeuge zur Verfügung. Das Datenformat PLCopen XML wurde für die Sprachen der IEC 61131-3 entwickelt, nicht aber für die Abbildung von Gantt-Charts oder Impulsdiagrammen. Zur Überprüfung der AutomationMLKonzepte musste daher ein eigenes Werkzeug entwickelt werden, welches wie der AutomationML Editor unter (AutomationML 2009) frei verfügbar ist, siehe Abb. 6.5. Prinzipielles Ziel des Logic Editors ist die Visualisierung aller Ablauf- und Sequenzbeschreibungsmittel, die im Rahmen von AutomationML mit PLCopen XML unterstützt werden (siehe Kap. 4). Bisher ist dies für Gantt Charts, Impulsdiagramme und SFCs erreicht; die Implementierung einer Funktionsblock-Ansicht für Verriegelungsbedingungen ist geplant. Die Darstellung selbst birgt Fallstricke. Beispielsweise können die Elemente von SFCs im Diagramm frei positioniert werden, es gibt keine Festlegung, wo und wie Schritte oder Aktionen anzuordnen sind. PLCopen XML speichert die geometrischen Informationen der einzelnen Diagramm-Elemente so, wie sie gezeichnet wurden. Wird aber ein SFC automatisch aus einem Gantt Chart generiert, stehen diese geometrischen Informationen nicht zur Verfügung und es kann grafisch nicht sinnvoll dargestellt werden. Daher ist für SFCs ein Auto-Layouting notwendig.

230

R. Drath et al.

Abb. 6.5   AutomationML Logic Editor

Eine wesentliche Anforderung besteht darin, dass auch unvollständige oder sogar inkonsistente Diagramme abbildbar sind, die sich zum Beispiel bei der Weitergabe von Zwischenergebnissen aus einem anderen Format zwangsläufig ergeben. Zur besseren Bedienerführung sollte deshalb eine Verifizierung durchführbar sein, mit der an problematische Stellen in den Diagrammen gesprungen werden kann. Weitere Anforderungen kamen schnell hinzu. So ist die Editierbarkeit in allen Ansichten wichtig, um komplexe Konstrukte nachstellen zu können, für die es eventuell keine andere Datenquelle gibt. Dies trifft bereits auf das sehr weitgehende

6  Praktische Anwendung

231

AutomationML-Konzept für Impulsdiagramme zu, das in dieser Reichweite auch unabhängig vom Datenformat zurzeit in keinem frei verfügbaren Werkzeug implementiert ist. Weiterhin ist die Editierfähigkeit sehr hilfreich, um die korrekte Konvertierung von Logikdaten mit neuen Import- und Exportschnittstellen in beiden Richtungen zu testen. Nicht zuletzt soll der Logic Editor auch zur Einarbeitung für Interessenten dienen; insofern sollen auch eigene Abläufe erstellt und mit PLCopen XML abgespeichert werden können. Der AutomationMLLogic Editor ist eine .NET-Anwendung, die alleinstehend oder als Komponente einer anderen Anwendung, zum Beispiel dem AutomationML Editor, lauffähig ist. Um ihn möglichst einfach integrieren zu können, besitzt er eine modulare Architektur. Beispielsweise werden alle notwendigen Klassen und Routinen zur Darstellung einer PLCopen-XML-Datei als Gantt Chart in einem eigenen Namespace geführt, zur Darstellung derselben Information als Impulsdiagramm werden Klassen und Routinen eines anderen Namespaces verwendet. Eine Abhängigkeit besteht allerdings für alle Views – die Daten, auf die gemeinsam zugegriffen werden muss. Hierfür wurde der Namespace POU implementiert, wobei eine POU (Program Organisation Unit) eine Einheit in der IEC 61131-3 bildet. Ein PLCopen-XML-Dokument kann mehrere POUs beinhalten. Gantt Charts sind aus Projektmanagement-Werkzeugen wie Microsoft Project bekannt. In der Anlagenplanung werden sie vor Allem in frühen EngineeringPhasen eingesetzt, um Abläufe auf einfache Weise zu beschreiben. Ein Ziel von AutomationML besteht darin, diese frühen Abläufe zu erfassen und in weiterführende Formate zu transformieren. Mit dem in Abb. 6.6 dargestellten Gantt-View im Logic Editor kann leicht überprüft werden, ob die Übertragung aus dem Ursprungsformat nach PLCopen XML erfolgreich war, bevor andere Darstellungen verwendet werden. Die Interpretation eines SFC als Gantt Chart erfolgt, indem entsprechende Aktivitäten im zugrunde liegenden SFC als Beginn und Ende oder Dauer eines Gantt-Balkens auswertet und außerdem Vorgänger/Nachfolger-Beziehungen visualisiert werden. Zusätzlich können die Ansichten in ihrer Größe angepasst werden. Impuls-Diagramme sind in ihrer Logik ähnlich zu Gantt Charts. Statt zwei erlaubten Zuständen aktiv oder nicht aktiv, die im Gantt Chart als Balken dargestellt werden, sind hier beliebig viele Zustände möglich. Zustandsübergänge haben eine Dauer und erscheinen im Diagramm als Rampen. Vorgänger/Nachfolger-

Abb. 6.6   Gantt-View im Logic Editor

232

R. Drath et al.

Abb. 6.7   Impulsdiagramm im Logic Editor

Beziehungen werden durch Signale ersetzt, die am Ende eines Zustandsüberganges oder von der Timeline ausgelöst werden und bei anderen Objekten zu weiteren Zustandsübergängen führen können. Signale werden dann durch Variablen oder reale I/O-Signale abgebildet. Im Logic Editor sind die Objekte hierarchisch organisiert und werden als Tree-View dargestellt (siehe Abb. 6.7). Durch Auf- und Zuklappen von Knoten kann weniger interessante Information versteckt beziehungsweise wichtige Information hervorgehoben werden. Sequential Function Charts (SFCs), auch Schrittketten genannt, sind eine grafische Beschreibungssprache für Kontrollflüsse. Sie unterstützen parallele und alternative Verzweigungen, Schleifen und Synchronisierungen sowie Sprünge. Jedem Schritt können beliebig viele Aktionen zugeordnet werden. Im Ergebnis können SFCs schnell sehr komplex werden, so dass dem Layout ein besonderes Augenmerk gewidmet wurde. In Abb. 6.5 wird ein SFC einer praktischen Anwendung gezeigt, während Abb. 6.8 eine bewusst komplexe Schrittkette zum Test des Layout-Algorithmus abbildet. SFCs können in diesem Werkzeug editiert werden. Dies erfolgt mit der üblichen Bedienerführung zum Einfügen oder Löschen neuer Elemente sowie einer Undo/ Redo-Funktion. Alternativ können die Schrittketten in einer Tabellen-Ansicht editiert und dann im SFC-View übersichtlich angeordnet werden, beispielsweise mit der Auto-Layout-Funktion. Der Auto-Layout-Algorithmus versucht, verschiedene Zweige im gleichmäßigen Abstand anzuordnen – und zwar auch dann, wenn der SFC unvollständig ist. An dieser Stelle muss bemerkt werden, dass dieser Ansatz nicht unkritisch ist. Einige SPSProgrammierwerkzeuge nutzen die geometrische Anordnung paralleler Zweige, um daran die Reihenfolge der Auswertung bei alternativen Verzweigungen festzulegen.

6  Praktische Anwendung

233

Abb. 6.8   Ein komplexer SFC

Wenn beispielsweise zwei Zweige alternativ ablaufen können und beide Ablaufbedingungen gleichzeitig zutreffen, dann ergeben sich bei unterschiedlicher geometrischer Anordnung der Zweige verschiedene Abläufe der Steuerungs-Software. PLCopen XML sieht hierfür optional eine Priorisierung vor. Um das Zufallsprinzip auszuschließen, wird eine derartige Priorisierung dringend empfohlen. Die Software besitzt zudem eine Validierungsfunktion: der Logic Editor bietet Hinweise auf Fehler, die bei der Datenprüfung festgestellt wurden. Detaillierte Informationen zum Fehler erhält der Anwender durch Anklicken des Hinweises. Der AutomationML Logic Viewer wird in (Breithor u. Weidemann 2009) weitergehend beschrieben.

6.2.3  AutomationML Engine Um AutomationML in eigenen Applikationen nutzen zu können, muss eine AutomationML-Schnittstelle programmiert werden. Da dies für jedes Werkzeug neu erfolgen müsste, ist eine wieder verwendbare Softwarekomponente sinnvoller. Dies ist Ziel der AutomationML Engine. Mit ihr können AutomationML-Dateien aus der Applikation heraus angelegt, geöffnet, gelesen und geschrieben werden, ohne das zugrunde liegende XML-Schema kennen zu müssen. Mit einem vordefinierten Befehlssatz können neue AutomationML-Dateien erstellt und gespeichert werden, Objekte und Klassen lassen sich einfach erzeugen, ändern oder löschen. Diese Software bildet derzeit ausschließlich den Topologieteil von AutomationML ab, der auf CAEX basiert. Für COLLADA werden geeignete Mittel im Abschnitt 6.2.4 beschrieben, für PLCopen XML ist eine entsprechende Engine noch nicht frei gegeben.

234

R. Drath et al.

In der ersten Version ist die Engine als Microsoft .NET-Bibliothek für C#-Applikationen implementiert, sie basiert auf .NET 2.0. Die Erstellung in C++ und für Java ist geplant, um die Einbindung in Bestands-Software zu erleichtern. Als Ausgangspunkt für die Engine wurden mit Hilfe der Software XMLSpy von Altova aus dem CAEX-Schema automatisch Klassenbibliotheken generiert. Diese initialen Bibliotheken mussten vor Allem aus zwei Gründen weiter entwickelt werden. Zunächst wurden für identische Attribute zweier verschiedener Tags initial zwei Klassen generiert. Wünschenswert ist natürlich nur eine Klasse zur Abbildung dieses Attributs. Für die effiziente Nutzung von AutomationML ist es aber noch wichtiger, dass die über CAEX hinaus festgelegten Semantiken und Anwendungsregeln direkt unterstützt werden. Insgesamt besteht die Engine aus den drei Bibliotheken Altova.dll, AltovaXML. dll und CAEX_ClassModel.dll. Altova.dll und AltovaXML.dll sind proprietärer Code von Altova und setzen eine Lizenz von XMLSpy voraus. Die Datei CAEX_ ClassModel.dll enthält schließlich alle spezifischen Klassen für den Topologieteil von AutomationML. In einem Visual-Studio-Projekt müssen diese Bibliotheken lediglich über Referenzen eingebunden werden, sie sind danach sofort einsetzbar. Die Klassenstruktur ist in den Diagrammen in Abb. 6.9 und 6.10 abgebildet. Die Klassenhierarchie folgt dabei dem CAEX-Schema, das durch ein Document Object «metaclass» CAEXBasicObject

SupportedRole ClassType

CAEXFile Type

Mapping Type

RoleRequirements Type

AttributeValue RequirementType

Revision Type

InterfaceName MappingType

ExternalReference Type

AttributeName MappingType

RefSemantic Type «metaclass» CAEXObject

Abb. 6.9   Klassenmodell der AutomationML Engine bis CAEXObject

6  Praktische Anwendung

235 «metaclass» CAEXObject

InternalLink Type

SystemUnit ClassType

SystemUnit FamilyType

InterfaceHierarchy Type

SystemUnit ClassLibType

InternalElement Type

COLLADAReference AttributeType

InterfaceClass LibType

Attribute Type

RoleClass LibType

InterfaceClass Type

ExternalInter faceType

LogicReference AttributeType

RoleClass Type

InterfaceFamily Type

RoleFamily Type

FrameAttribute Type

Frame Values

Abb. 6.10   Klassenmodell der AutomationML Engine ab CAEXObject

Model (DOM) repräsentiert wird. Die Engine enthält für jeden CAEX-Typ eine eigene Klasse. Wenn ein Typ A in CAEX mehrere Instanzen eines anderen Typs B als Unterknoten zulässt, dann wird in der Engine in der Klasse A eine Collection für Objekte der Klasse B angelegt. Beispielsweise repräsentiert die C#-Klasse CAEXFileType den XML-Typ CAEXFile, das gemäß CAEX-Schema mehrere InstanceHierarchy-Elemente als Unterknoten besitzen kann. Entsprechend enthält die Klasse CAEXFileType ein Property InstanceHierarchy, die eine Collection von Objekten der Klasse InstanceHierarchyType ist. Zusätzlich besitzt jede Klasse ein Property Node, um direkt an die XML-Unterknoten im DOM zu gelangen. Auch wenn man auf diese Art sehr frei durch das Dokument navigieren kann, so bieten die Engine-Klassen mit ihrer Typsicherheit einen großen Vorteil gegenüber reinen DOM-Klassen. Die Verbindung zwischen den meisten Engine-Klassen und den CAEX-Typen geschieht durch eine einfache Namenskonvention, indem an den CAEX-Typenname bei der C#-Klasse das Wort „Type“ angehängt wird. Dem CAEX-Typ InternalEle­ ment entspricht beispielsweise die C#-Klasse InternalElementType. Für jedes Attribut eines CAEX-Typs wird ebenfalls eine C#-Klasse mit speziellen Methoden angelegt. Für ein Attribut Name des Typs InstanceElement bekommt zum Beispiel die entsprechende C#-Klasse den Property Value. Als Beispiel erhält man den Namen eines Objekts element der Klasse InstanceElementType somit mit der Zuweisung: string instanceName = element.Name.Value; Das Klassenmodell der AutomationML Engine ist in Abb. 6.9 und 6.10 dargestellt. Alle Engine-Klassen sind direkt oder indirekt von der Basisklasse CAEXBasic­

236

R. Drath et al.

Abb. 6.11   XML-Beispiel für die AutomationML Engine

Object abgeleitet, die selbst wieder von der Altova-Klasse TypeBase erbt. TypeBase ist bereits Teil der beiden proprietären Altova-Bibliotheken, die mit der Code-Generierungsfunktionalität des XMLSpy lizensiert werden müssen. Viele weitere gemeinsame Eigenschaften werden in der Klasse CAEXObject unterhalb von CAEX­ BasicObject gesammelt.

6  Praktische Anwendung

Abb. 6.12   Source-Code-Beispiel für die AutomationML Engine

237

238

R. Drath et al.

Abb. 6.12   (Fortsetzung)

Für das Anlegen neuer Objekte in der Hierarchie sieht die AutomationML En­ gine eigene Methoden mit dem Namen New_CAEX-type vor, wobei CAEXtype jeweils den CAEX-Typ meint. Hintergrund dieser ungewöhnlichen Art, neue Objekte anzulegen, ist deren Verwaltung im späteren XML-Dokument. In XML kann eine bestimmte Reihenfolge von Unterknoten unterschiedlicher Typen vorgegeben werden. Die Methode New_CAEX-type sorgt dafür, dass diese Reihenfolge schemakonform eingehalten wird. Von der Nutzung der ebenfalls verfügbaren Methode Append wird dringend abgeraten. Sie hängt einen neuen Unterknoten einfach an die Reihe von Unterknoten, ohne die eventuell einzuhaltende Reihenfolge zu beachten. Eine Ausnahme bildet die Klasse SystemUnitClassType, für die es keine direkte Entsprechung im CAEX-Schema gibt. Sie wurde als Basisklasse für SystemUnitFamilyType und InternalElementType eingeführt. SystemUnitFami­ lyType repräsentiert den CAEX-Typ SystemUnitType, InternalElementType steht für InternalElements von CAEX. Diese beiden Typen sind sehr ähnlich und können ineinander überführt werden. Bei Ergänzungen des AutomationML-Konzeptes sind entsprechend schnell beide Typen gleichermaßen betroffen. Mit der gemeinsamen Basisklasse wird dann die doppelte Implementierung und langfristige Wartung in diesen beiden zentralen Klassen vermieden. Das abschließende Beispiel zeigt die Nutzung der AutomationML Engine. Die in Abb. 6.11 dargestellte XML-Datei wird mit dem in Abb. 6.12 dargestellten C#Code erzeugt. Es zeigt alle wesentlichen Operationen vom Anlegen und Öffnen

6  Praktische Anwendung

239

einer Datei über das Erzeugen einer Instanzhierarchie und den Instanzen mit Attributen bis zum Schreiben der Daten. Eine umfassende Beschreibung von AutomationML erfolgt in der Automati­ onML Engine Developer Guideline (Pirsch u. Weidemann 2008b).

6.2.4  COLLADA Tools Da COLLADA selbst bereits auf eine fünfjährige Erfolgsgeschichte zurück blicken kann, sind in diesem Umfeld bereits einige Projekte und Softwarebausteine entstanden, die den Entwickler unterstützen. Im Folgenden ist eine Auswahl an freien Tools und Frameworks zusammengestellt, die den Einstieg in Hinsicht auf AutomationML erleichtern. Eines der ältesten Projekte um COLLADA ist das COLLADA Document Ob­ ject Model ( COLLADA DOM). Hierbei handelt es sich um eine C++-Bibliothek, die das dokumentenbasierte Lesen und Schreiben von COLLADA-Dateien ermöglicht. Ein weiteres Projekt, das sich mit dem Lesen und Schreiben von COLLADA-Dokumenten auseinandersetzt, ist das OpenCOLLADA Framework (OpenCOLLADA). Es beinhaltet zwei C++-Bibliotheken ( COLLADAStreamWri­ ter und COLLADASaxFrameworkLoader), die im Gegensatz zum COLLADA DOM einen Stream-basierten Ansatz zum Lesen und Schreiben von COLLADADateien verfolgen. Für die Bearbeitung von MathML-Daten wird das Projekt MathMLSolver empfohlen. Diese C++-Bibliothek unterstützt den Entwickler beim Parsen, Validieren und Lösen von in MathML abgebildeten Formeln. Abschließend sei noch auf das nVidia Scenegraph SDK (nVidia NVSG) verwiesen, das einen leistungsfähigen Viewer beinhaltet, der auch große COLLADADokumente visualisieren kann.

6.3  Graphic Conditioner Pipeline Framework 6.3.1  Motivation Schon in einer frühen Entwicklungsphase von AutomationML stand fest, dass COLLADA – damals noch in der Version 1.4.1 – als Grafikformat verwendet wird. Um diese Entscheidung untermauern zu können, wurde ein Demonstrator benötigt. Dieser sollte zum einen die Belastbarkeit von COLLADA im Speziellen und AutomationML im Allgemeinen prüfen und die erarbeiteten Konzepte zum anderen auf Konferenzen, Messen und anderen Veranstaltung präsentieren. Weiterhin sollten konkrete Anforderungen für die Aufbereitung von CAD-Daten seitens der

240 Tab. 6.1   Unterstützte Eingabeformate

Tab. 6.2   Unterstützte Ausgabeformate

R. Drath et al. Format

Topologie

Geometrie

Kinematik

CATIA/DELMIA V5 Robcad JT DWG STEP IGES COLLADA Sketchup PRC

X X X X X X X X X

X X X X X X X X X

X X – – – – X – –

Format

Topologie

Geometrie

Kinematik

CATIA/DELMIA V5 Robcad JT U3D/PDF Sketchup COLLADA VGR TIFF

X X X X X X X X

X X X X X X X X

X X – – – X – –

Initiatoren z. B. für Simulationswerkzeuge umgesetzt werden. Ebenso wird eine Referenzimplementierung benötigt, um neue Funktionen validieren zu können, die für die seinerzeit in Arbeit befindliche Version 1.5 des COLLADA-Standards erarbeitet wurden. Im ersten Schritt wurde die Konvertierung tessellierter Daten von einem Quellsystem nach COLLADA und dann von COLLADA in das Zielsystem umgesetzt. Es folgten die BREP-Informationen und schließlich die Implementierung des Kinematikmodells. Eine Übersicht über die validierten Formate und den Austausch der Informationen wird in Tab. 6.1 und 6.2 gegeben.

6.3.2  Anforderungen Bei der Entwicklung wurde schnell deutlich, dass eine einfache Konvertierung über COLLADA allein nicht ausreichend ist. So unterstützt z. B. das System A die Grafikprimitiven Triangles, Trifans und Tristrips, das System B hingegen nur Tristrips. Dies machte die zielsystemspezifische Konditionierung bzw. Aufbereitung der Daten während der Konvertierung nötig. Dazu werden sogenannte Conditioner benötigt. Weiterhin müssen unterschiedliche Conditioner in der richtigen Reihenfolge aufgerufen werden. Um beispielsweise aus Trifans Tristrips zu erzeugen, muss zuerst ein Conditioner Detrifanner, der Triangles erzeugt, und anschließend ein weiterer

6  Praktische Anwendung

241

Conditioner Tristripper, der aus Triangles Tristrips erzeugt, aufgerufen werden. Somit ergaben sich für das zu entwickelnde Werkzeug drei Hauptaufgaben: • Es muss für weitere Datenformate erweiterbar sein. • Es muss die Daten transformieren (konditionieren) können, um sie für verschiedene Zielsysteme aufzubereiten. • Es muss die einzelnen Teilschritte in der richtigen Reihenfolge durchführen, um das gewünschte Ergebnis zu erreichen. Aus diesen Anforderungen wurde der Name des Projekts abgeleitet: Graphic Con­ ditioner Pipeline Framework oder kurz Graphic CPF. Eine Pipeline wird durch die Kombination mehrerer Einzelkomponenten des Frameworks gebildet, die Daten fließen durch diese Pipeline hindurch. Damit ein Konvertierungswerkzeug mit vielen unterschiedlichen Datenformaten arbeiten kann, war ein generischer Ansatz notwendig, der eine Architektur aus mehreren unabhängigen Modulen besitzt. Weiterhin war und ist mit großen Datenmengen zu rechnen, die es zu konvertieren gilt. Eine statische Konvertierung der Form „Daten laden, Daten konvertieren, Daten schreiben“ stößt dabei schnell an ihre Grenzen, da sie bei dieser Vorgehensweise im ungünstigsten Fall die zu konvertierenden Daten dreimal im Speicher vorhalten muss. Neben den drei Hauptaufgaben wurden deshalb folgende weitere Anforderungen an das Framework gestellt: • Die Entwicklung weiterer Module soll unabhängig von den übrigen Modulen erfolgen können. • Das Framework soll die Reihenfolge der abzuarbeitenden Softwaremodule automatisch erkennen und keine Nutzeroberfläche besitzen. • Der Umgang mit Massendaten sollte effizient stattfinden. Damit das CPF mit Massendaten umgehen kann, muss eine Möglichkeit gefunden werden, die Daten in kleinere, voneinander unabhängige Fragmente zu übertragen. Diese können dann in beliebiger Reihenfolge konvertiert und konditioniert werden. So lassen sich Materialinformationen oder Grafikbestandteile separieren. Für eine Tristripping-Funktion ist es beispielsweise unerheblich, ob die Dreiecke einer Geometrie grün oder blau sind, oder wo die Geometrie im Produktbaum zu finden ist. Ebenso unterstützt das Zielformat eventuell keine Kinematik, dann besteht kein Grund, diese Daten zu laden oder zu verarbeiten. Im folgenden Beispiel beschreibt eine Grafikdatei einen Roboter. Wenn die Kinematik einmal unbeachtet bleibt, so kann der Inhalt dieser Datei in drei Fragmentklassen aufgeteilt werden (siehe Abb. 6.13): • Einzelgeometrien, • Materialinformationen, • Produktbaum.

242

R. Drath et al.

Komponente

Struktur

Geometrien

Materialien

Robot Part 1 Part 2 Part 3 Part 4 Part 5 Part 6 Part 7 Part 8 Part 9

Abb. 6.13   Informationsfragmente einer Komponente

Ein weiterer Vorteil von unabhängigen Datenfragmenten ist die mögliche Parallelisierung. So lässt sich die Kapazität von Multi-Core-Rechnern besser ausschöpfen, wenn z. B. zwei Geometrien gleichzeitig verarbeitet werden. Das Graphic CPF muss folglich verschiedene Datencontainer zur Verfügung stellen, in dem ein Modul seine Informationen ablegen kann. Um an das obige Beispiel anzuschließen, muss es je einen Container für einzelne Geometrien und Materialien sowie einen weiteren für die Strukturinformation geben. Der Letztgenannte verweist dann auf die anderen Datencontainer. Damit das Graphic CPF um weitere Datenformate erweitert werden kann, wurden spezielle Schnittstellen definiert, sogenannte Extension points, die von einem Modul implementiert werden müssen. Prinzipiell werden drei Extension points unterschieden: Loader, Conditioner und Writer (siehe Abb. 6.14).

Loader Triangles

Conditioner Triangles -> Tristrips

Abb. 6.14   Schematische Darstellung einer Konvertierung

Writer Tristrips

6  Praktische Anwendung

243

• Ein Loader definiert die Schnittstelle zum Laden von Daten. Es befüllt die Datencontainer mit den entsprechenden Informationen. • Ein Writer definiert die Schnittstelle zum Schreiben von Daten und bildet somit das Gegenstück zum Loader. Er fragt die Datenfragmente, die er verarbeiten soll, selbstständig an. Das Framework stellt sicher, dass der Writer die Daten in der von ihm verarbeitbaren Form erhält. • Ein Conditioner dient zur Umformung, Aufbereitung und Konditionierung der Daten als Vorbereitung des Exportes. Das Zusammenspiel zwischen Loader, Conditioner und Writer wird in Abb. 6.14 dargestellt. Damit das Framework in der Lage ist, alle notwendigen Conditioner zum richtigen Zeitpunkt zu laden, müssen alle Extension points Metainformationen bereitstellen, ein sogenanntes Manifest. Anhand dessen kann das Framework feststellen, welche Module benötigt werden und ob eine Konvertierung überhaupt möglich ist. Ein Beispiel soll dies verdeutlichen. In einem einfachen Datenformat A seien Geometrien in Dreiecken (Triangles) gespeichert. Im Manifest des entsprechenden Loaders ist als Metainformation OUTPUT: TRIANGLES hinterlegt. Die Daten sollen nun in das Datenformat B überführt werden. Die Metainformation im Manifest des entsprechenden Writers lautet INPUT: TRISTRIPS. Dies bedeutet, dass der Writer Geometrien verarbeiten kann, die als Tristrips vorliegen. Um die Daten von A nach B überführen zu können, prüft das Framework, ob es einen Conditioner findet, welcher Triangles in Tristrips transformieren kann, also in dessen Manifest die folgenden Informationen zu finden sind: INPUT: TRIANGLES und OUTPUT: TRISTRIPS. Wird ein solcher Conditioner gefunden, ist die Konvertierung möglich.

6.3.3  Umsetzung des Graphic CPF Das Conditioner Pipeline Framework selbst ist eine Sammlung von Softwaremodulen, das zur Verwendung in Dritt-Applikationen gedacht ist. Eine mögliche Drittapplikation des CPF ist das Kommandozeilenwerkzeug CPCMD, dem je ein Eingabe- und ein Ausgabeparameter übergeben wird. Die Abarbeitung erfolgt im Hintergrund automatisch. Anhand der Datei-Endungen stellt die Software automatisch fest, welcher Loader bzw. Writer und folglich welche Conditioner vom Framework benötigt werden – dies erzeugt automatisch die benötigte Pipeline. Um einen Roboter aus DELMIA V5 (siehe Abb. 6.16) nach eM-Engineer zu konvertieren, wird zunächst folgendes Kommando (siehe Abb. 6.15) zur Erzeugung eines entsprechenden COLLADA-Dokuments benötigt:

Abb. 6.15   Kommando zum Konvertieren nach COLLADA

244

R. Drath et al.

Abb. 6.16   Roboter im Tool DELMIA V5

Der Ablauf der Konvertierung erfolgt in fünf Schritten gemäß Tab. 6.3: Tab. 6.3   Konvertierungsschrittfolge Teil 1

Schritt

Ergebnis

1. Suche Loader, der die Endung CATProduct kennt 2. Stelle die vorhandenen Inputinformationen fest

DELMIALoader

3. Suche Writer, der die Endung dae kennt 4. Stelle die geforderten Outputinformationen fest

5. Führe Konvertierung durch

GEOMETRIE – TRIANGLES – TRISTRIPS – TRIFANS KINEMATIK COLLADAWriter GEOMETRIE – TRIANGLES – TRISTRIPS – TRIFANS – POLYGONS –… KINEMATIK Die Datei kr150.dae

In einem weiteren Schritt wird dann das erzeugte COLLADA-Dokument in das Zielsystem eM-Engineer konvertiert (siehe Abb. 6.17):

Abb. 6.17   Kommando zum Konvertieren von COLLADA

6  Praktische Anwendung

245

Abb. 6.18   Roboter im Tool eM-Engineer

Das Ergebnis ist in Abb. 6.18 dargestellt. Der Ablauf der Konvertierung erfolgt in den Schritten gemäß Tab. 6.4: Tab. 6.4   Konvertierungsschrittfolge Teil 2

Schritt

Ergebnis

COLLADALoader 1. Suche Loader, der die Endung dae kennt 2. Stelle die vorhandenen Inputinformationen GEOMETRIE fest – TRIANGLES – TRISTRIPS – TRIFANS – POLYGONS –… KINEMATIK ROBCADWriter 3. Suche Writer, der die Endung co kennt 4. Stelle die geforderten Outputinformationen GEOMETRIE fest – TRIANGLES KINEMATIK 5. Suche benötigte Conditioner TRIFANS – > TRIANGLES TRISTRIPS – > TRIANGLES 6. Führe Konvertierung durch Die Datei kr150.co

Ebenso kann aus dem COLLADA-Dokument auch eine Datei im JT-Format erzeugt werden. Dies erfolgt wie in Abb.  6.19 dargestellt. Der Ablauf der Konvertierung erfolgt in den Schritten gemäß Tab. 6.5. Das Ergebnis ist in Abb. 6.20 dargestellt.

246

R. Drath et al.

Abb. 6.19   Kommando zum Konvertieren von COLLADA nach JT

Tab. 6.5   Konvertierungsschrittfolge Teil 3 Schritt

Ergebnis

1. Suche Loader, der die Endung dae kennt 2. Stelle die vorhandenen Inputinformationen fest

COLLADALoader GEOMETRIE – TRIANGLES – TRISTRIPS – TRIFANS – POLYGONS –… KINEMATIK JTWriter GEOMETRIE – TRISTRIPS TRIFANS – > TRIANGLES TRIANGLES – > TRISTRIPS Die Datei kr150.jt

3. Suche Writer, der die Endung jt kennt 4. Stelle die geforderten Outputinformationen fest 5. Suche benötigte Conditioner 6. Führe Konvertierung durch

Abb. 6.20   Roboter im Tool JT2GO

6  Praktische Anwendung

247

6.3.4  Fazit Die Entwicklung des Graphic Conditioner Pipeline Frameworks hat gezeigt, dass eine Konvertierung von Grafik- und Kinematikinformationen über COLLADA 1.5.0 in ein anderes Datenformat möglich ist. Alle wichtigen Informationen konnten von einem Werkzeug in andere überführt werden. Die Leistungsfähigkeit des Datenformats und des Graphic CPF wurden darüber hinaus im produktiven Einsatz für Automobilhersteller nachgewiesen. Weitere Informationen zum Conditioner Pipeline Framework sind unter NetAllied (2009) erhältlich.

6.4  Das Logic CPF 6.4.1  Übersicht Dieser Abschnitt beschreibt ein Werkzeug zur Transformation von Logikbeschreibungsmitteln. Mit diesem Werkzeug soll beispielsweise ein Gantt Chart, das in einem proprietären Datenformat vorliegt, nach AutomationML und zurück konvertiert werden können. Gleichzeitig soll es ermöglichen, unterschiedliche Beschreibungsmittel ineinander zu transformieren, zum Beispiel Logikmodelle der frühen Engineering-Phasen in Modelle späterer Phasen. Weiterhin soll es das Bearbeiten, Ergänzen, Erweitern oder Reduzieren von Logikdaten ermöglichen, etwa das einfache Ersetzen von Sonderzeichen, das Hinzufügen von Positionsinformationen innerhalb von PLCopen-XML-Dateien oder das Durchführen komplexer Änderungen am Modell. Damit lassen sich drei wesentliche Anwendungsfälle unterscheiden: 1. Konvertierung von Logikdatenformaten von und nach AutomationML, 2. Transformation von einem Logikmodell in ein anderes entsprechend der AutomationML Transformationsregeln, 3. Verarbeiten von Logikdaten. Die hier vorgestellte Software adressiert diese Anwendungsfälle und stellt eine Beispiel-Implementierung der in Kap. 4 dargestellten Regeln dar. Die Transformation von Beschreibungsmitteln wie z. B. Gantt Charts oder Impulsdiagrammen nach AutomationML und zurück lässt sich in eine Abfolge von Einzelschritten zerlegen. Die Umsetzung in Software legt deshalb eine Architektur nahe, in der die Einzelschritte als Plugins implementiert sind. Das AutomationMLKonsortium hat solche Plugins erstellt und in einem Framework zusammengeführt – dem Logic Conditioner Pipeline Framework (Logic CPF). Dieses steht unter AutomationML (2009) zum Download zur Verfügung. In Abb. 6.21 ist dessen Prinzip dargestellt, es zeigt schematisch eine sogenannte Pipeline, die aus drei Plugins besteht, nämlich einem Reader, einem Conditioner und einem Writer.

248

R. Drath et al.

5HDGHU

&RQGLWLRQHU

:ULWHU

'DWHQEDVLV

Abb. 6.21   Prinzip des Logic CPF

Das Logic CPF besitzt Plugins für das Lesen, Transformieren, Editieren und Speichern einer Auswahl von Logikdaten. Durch Zusammensetzen geeigneter Plugins können Pipelines gebildet werden, durch die die Daten „hindurchfließen“ und dabei schrittweise manipuliert werden. Während der Ausführung einer Pipeline benutzen alle in der Pipeline enthalten Plugins die gleiche Datenbasis. Zu Beginn liest ein Reader die Logikdaten aus einer Datei in die gemeinsame Datenbasis ein. Weitere Plugins können Datenmanipulationen oder Modelltransformationen ausführen und so für das Zielwerkzeug konditionieren. Sie werden als Conditioner bezeichnet. Zuletzt schreibt ein Writer die Ergebnisse der Modelltransformation in das Zielformat. Das Logic CPF ist somit ein erweiterbares Software-Framework und besteht aus folgenden Hauptkomponenten (siehe Tab. 6.6). Derzeit bietet das Logic CPF eine Referenzimplementierung für das Lesen, Verarbeiten und Schreiben von Gantt Charts. Alle internen Verarbeitungsschritte werden auf dem internen Datenmodell IML durchgeführt. Daraus ergibt sich die in Abb. 6.22 dargestellte Plugin-Architektur. Im Folgenden werden die einzelnen Komponenten des Frameworks näher erläutert und deren Zusammenspiel anhand eines Beispiels erklärt.

Tab. 6.6   Hauptkom‑ ponenten des Logic CPF

Komponente

Beschreibung

Frame Application

Die Rahmenapplikation dient der Ausführung von Plugins sowie der Initialisierung des IML-DOMs Das IML-DOM dient der Datenhaltung während der Lese-, Transformations-, Editier- und Schreiboperationen Die Pipeline bildet eine vom Nutzer vorgegebene Abfolge von Plugins ab, die zum Einlesen von Daten ( Reader), zum Bearbeiten von Daten im IML-DOM ( Conditioner) und den Schreiben von Daten ( Writer) dienen

IML-DOM Pipeline

6  Praktische Anwendung

249 Logic CPF

Frame Application

Plugins

IML DOM

Reader

Conditioner

Writer

GanttExcelReader

GanttPostprozessor

PLCopenWriter20

GanttMSProjectReader

PLCopenWriter11

ImpulsJPlanReader

Abb. 6.22   Plugin-Architektur des Logic CPF

6.4.2  Rahmenapplikation Die Rahmenapplikation ist die Hauptkomponente des Logic CPF, sie integriert die einzelnen Komponenten. Mit ihrer Hilfe werden die verschiedenen Plugins konfiguriert, Pipelines ausgeführt und der Zugriff auf das IML-DOM gesteuert. Eine Pipeline ist eine einfache Sequenz von verschieden Plugins, die durch die Rahmenapplikation ausgeführt werden und Daten verarbeitet. Alle dabei aufgerufenen Plugins arbeiten auf den Inhalten des beim Start der Pipeline erzeugten IML-DOMs. Neben der Konfiguration und Ausführung kann die Rahmenapplikation auch zum Erstellen neuer Pipelines verwendet werden. Dazu wählt der Nutzer die gewünschten Plugins aus, legt ihre Reihenfolge und Parameter fest und speichert die Pipeline in einer Konfigurationsdatei (siehe Abschnitt 6.4.7). Diese kann später erneut geladen werden. Bei der Implementierung des Logic CPF handelt es sich um eine Windows-Anwendung, die auf dem Microsoft .NET Framework 3.5 aufsetzt. Der Nutzer kann über eine grafische Oberfläche Konfigurationsdateien einer Pipeline laden, Parametern von Plugins ändern oder eine Pipeline starten. Die Nutzeroberfläche und ihre Bestandteile sind in Abb. 6.23 dargestellt. Die Anwendung des Logic CPF erfolgt im einfachsten Falle durch das Laden einer Pipeline-Konfigurationsdatei sowie dem Starten der Pipeline. Das erforderliche Datei-Management wird von den Plugins übernommen. Die Plugins der Pipeline werden in einer Pipeline-Listbox dargestellt und in einer Konfigurationsdatei gespeichert; ihr Format wird in Abschnitt 6.4.7 beschrieben. Die einzelnen Parameter der angegebenen Plugins werden dann im Formularbereich der grafischen Oberfläche angezeigt und können dort angepasst und mit Werten für die Parameter belegt werden.

250

R. Drath et al.

Abb. 6.23   Bedienoberfläche der Logic CPF Rahmenapplikation

6.4.3  IML-DOM Das IML-DOM ist eine Klassenbibliothek, welche das in Kap. 4 definierte IMLModell implementiert. Im ersten Schritt einer Pipeline werden die Quelldaten eingelesen, nach IML transformiert und im IML-DOM abgelegt. Alle weiteren Schritte arbeiten ausschließlich darauf. Die einzelnen Klassen der Bibliothek bilden die IML-Modellelemente ab. Das Klassendiagramm des IML-DOM ist in Abb. 6.24 dargestellt und zeigt die Zusammenhänge zwischen den einzelnen Klassen. Es besteht aus zwei Hauptklassen: zum einen die Klasse IMLSystem, welche ein gesamtes IML-System abbildet und zum anderen die abstrakte Klasse IMLSystemElement, welche die Elemente eines IML-System repräsentiert und von denen die einzelnen Klassen zu Repräsentation der jeweiligen IML-Elemente abgeleitet sind. Die einzelnen Instanzen von IMLSystemElement werden dabei jeweils von einer Instanz der Klasse IMLSystem verwaltet. Die Struktur der von der Klasse IMLS­ ystemElement abgeleiteten Klassen orientiert sich am Aufbau des IML-Modells. Dementsprechend wurde zu jedem IML-Element eine eigene Klasse definiert. Attribute und Unterelemente der einzelnen IML-Elemente werden über Klassenattribute beziehungsweise Unterklassen abgebildet. Wie in Abb. 6.24 dargestellt, ist jede Repräsentation eines IML-Elements direkt oder indirekt von der abstrakten Klasse IMLSystemElement abgeleitet. Diese abs-

6  Praktische Anwendung

251

IMLSystemElement

IMLSystem

IPredecessor

IPredecessor

IPredecessor

TopLevelElement

AdditionalData

Activity

IPredecessor

Comment

Time

IPredecessor

Event

IPredecessor

Header

IPredecessor

IMLSate

IPredecessor

Selection Convergence

Jump

IPredecessor Simultaneous Convergence

IPredecessor

Selection Divergence

IPredecessor

Simultaneous Divergence

IPredecessor

StateTransition

Guard

Variable

BooleanGuard

ValueGuard

Abb. 6.24   Klassendiagramm des IML-DOM

trakte Klasse stellt Metaeigenschaften zur Strukturierung der IML-Systeme bereit. So wird beispielsweise über das Attribut Owner das IML-System festgelegt, zu welchem ein Element gehört. Da das IML-DOM nicht nur zur Aufnahme und Ablage von IML-Systemen dient, sondern auch die Basis für die Logiktransformationen darstellt, wurden zu-

252

R. Drath et al.

sätzlich zur reinen Klassenimplementierung der einzelnen IML-Elemente auch Methoden zur Abfrage und zur Modifikation der Objekte implementiert. Die Klasse ­IMLSystem besitzt hierzu zusätzliche Methoden zur Abfrage von Systemeigenschaften oder zu ihrer Änderung. Ein Beispiel hierfür ist die Methode ContainsKey, mit der das Vorhandensein von IDs im IML-System abgefragt werden kann. Eine Übersicht über die Methoden, die durch die Klasse IMLSystem des IML-DOMs bereitgestellt werden, wird in Tab. 6.7 gegeben. Tab. 6.7    Methoden des IML-Systems Methode

Erklärung

Bool ContainsKey (String id)

Die Methode ermittelt, ob eine bestimmte ID bereits im IML-System vergeben ist. Dabei bedeutet: true: ID ist vergeben, false: ID ist nicht vergeben Mit dieser Methode kann ermittelt werden, ob ein bestimmter Variablenname bereits vergeben ist. Dabei bedeutet: true:Name ist vergeben, false: Name ist nicht vergeben Diese Methode gibt das Toplevel-Element mit der angegebenen ID zurück. Wenn kein ToplevelElement mit der angegebenen ID existiert, ist der Rückgabewert null Gibt alle Toplevel-Elemente eines bestimmten Typs als Array zurück, z. B. alle IML State-Elemente. Es wird ein leeres Array zurückgegeben, wenn keine Elemente des entsprechenden Typs im DOM existieren Diese Funktion gibt alle Nachfolger eines bestimmten IML-Elements als Array zurück, welche einen bestimmten Typ besitzen. Das Array ist leer, wenn keine Elemente des entsprechenden Typs gefunden wurden Erzeugt eine gültige ID, welche noch nicht im IML System vergeben ist und liefert diese zurück. Wenn keine gültige ID erzeugt werden konnte, wird null zurück geliefert Erzeugt einen gültigen Variablennamen, welcher noch nicht im IML-System vergeben ist, und liefert diesen zurück. Wenn kein gültiger Name erzeugt werden konnte, wird null zurück geliefert Gibt eine Variable mit dem angegebenen Namen als Toplevel-Element zurück. Wenn keine Variable mit dem angegebenen Namen vorhanden ist, wird null zurück gegeben Entfernt das Toplevel-Element aus dem System. Gibt true zurück, wenn das Element erfolgreich entfernt werden konnte, und false, falls das Entfernen fehlgeschlagen ist, zum Beispiel beim Versuch, das Header Element zu entfernen

Bool ContainsName (String name)

TopLevelElement GetMemberByID (String id)

TopLevelElement[ ] GetMembersByType(Type type)

TopLevelElement[ ] GetSuccessorsByType (TopLevelElement refElement, Type type) String GetValidID( )

String GetValidName( )

TopLevelElement GetVariableByName (String name) Bool RemoveMember (TopLevelElement element)

6  Praktische Anwendung

253

Eine weitere Komponente, welche zur Abfrage und für Modifikationszwecke definiert ist, ist das Interface IPredecessor. Diese Schnittstelle dient der einfacheren Handhabung der Vorgänger/Nachfolger-Beziehungen innerhalb eines IML-Systems und muss von allen Toplevel-Klassen implementiert sein, die einen oder mehrere Vorgänger besitzen können.

6.4.4  Plugins Plugins sind die Komponenten des Logic CPFs, welche die Funktionalität und Algorithmen zum Lesen, Verändern und Schreiben von Daten implementieren. Sie werden als Microsoft .NET-Assembly erstellt und besitzen eine fest definierte Schnittstelle, über die die Rahmenapplikation auf die Funktionalität des Plugin zugreifen kann. Wichtig ist, dass das Logic CPF nur genau eine Funktion pro Plugin zulässt, das heißt jedes Plugin ist entweder ein Reader, ein Conditioner oder ein Writer. Weiterhin ist im Konzept des Logic CPF vorgesehen, dass jede .NET-Assembly nur ein Plugin enthält. Die Schnittstelle der Assemblies ist durch das Interface ITask realisiert. Eine Übersicht der ITask-Methoden gibt Tab. 6.8. Für den Aufruf durch die Rahmenapplikation innerhalb des Logic CPFs sind die genannten drei Methoden ausreichend. Das Verhalten jedes Plugins kann über Parameter beeinflusst werden. Diese werden im Kontext des Logic CPF als Optionen bezeichnet und als Key/Value-Wertepaare angegeben. Key ist dabei der Name des Parameters und Value sein Wert. Beide Informationen müssen bei der Übergabe als String angegeben werden. Da die Parameter für ein Plugin jeweils spezifisch sind, werden sie mit Hilfe von Attributen der Klasse PluginOption direkt bei der Klassenimplementierung der Plugin-Assembly definiert. Dadurch bleibt die Einheit des Plugins mit seinen Parametern erhalten und muss nicht separat gespeichert bzw. übergeben werden. Die Klasse PluginOption besitzt dabei vier Attribute. Eine Übersicht über die Attribute ist in Tab. 6.9 zu finden. Das Attribut Name ist die einzige Eigenschaft, welche zwingend angegeben werden muss. Alle anderen Eigenschaften sind zusätzliche Informationen, welche von der Rahmenapplikation bei der Ausführung ausgewertet werden. Tab. 6.8   Plugin Schnittstelle ITask Interface: ITask Funktion

Beschreibung

Void Execute(ref AML.ImlSystem. ImlSystem imlSystem)

Diese Methode wird aufgerufen, um das Plugin auszuführen. Als Parameter wird eine Referenz auf das IML-DOM übergeben, welches das interne Datenmodel für alle Plugins bildet Mit dieser Methode können Parameter des Plugins gesetzt werden (siehe Plugin-Optionen) Mit dieser Methode können Parameterwerte abgerufen werden

Void SetProperty(String key, String value) String GetProperty(String key)

254

R. Drath et al.

Tab. 6.9   Eigenschaften der Klasse PluginOption Attribute

Typ

Bedeutung

Name Required

String Bool

ShortDescription

String

Type

OptionType

Gibt den Namen der Option an Gibt an, ob diese Option optional oder notwendig für die Ausführung des Plugins ist. Der Defaultwert ist „false“ Eine kurze Beschreibung der Option. Der Defaultwert ist „String.Empty“ Der Typ der Option. OptionType ist eine Auflistung von erlaubten Typen. Der De­ faultwert ist „String“

6.4.5  Beispiel Nachdem der Aufbau des Logic CPF erklärt wurde, soll im Folgenden ein Anwendungsbeispiel erläutert werden. Dazu wird eine vereinfachte Ablaufbeschreibung zur Steuerung einer Waschmaschine betrachtet, die in Form eines Gantt Charts vorliegt. Dieses wird in ein SFC transformiert und als PLCopen-XML-Dokument abgespeichert (siehe Abb. 6.25). Die Beschreibung ist dabei ursprünglich als Microsoft-EXCEL-Datei abgelegt und enthält alle wichtigen Sprachelemente: • Vorgänger/Nachfolger-Beziehungen von Balken, • Verzweigungen, • Zusammenführungen und • Zeitinformationen zu den einzelnen Balken. Der hier definierte Ablauf des Waschprogramms besteht aus acht Schritten, von denen alle bis auf die Schritte Trommel und WaschmittelEinfuehren als Sequenz ausgeführt werden. Die beiden genannten Schritte hingegen werden parallel nach dem Schritt WasserErhitzen ausgeführt. Um dieses Gantt Chart nach PLCopen

Abb. 6.25   Ablaufdiagramm einer vereinfachten Waschmaschine in Excel

6  Praktische Anwendung

255

XML zu transformieren, muss mit dem Logic CPF eine Pipeline angelegt werden. Dazu werden folgende Plugins ausgewählt: • ExcelGanttReader: liest die Excel-Datei ein und überführt sie in das IMLDatenmodell. • GanttPostprozessor: führt Operationen zur Transformation von IML nach PLCopen XML aus (Transformationsregeln siehe Abschnitt 4.4.9). • PLCopenWriter20: schreibt die IML-Daten als SFC in ein PLCopen-XMLDokument. Die Abbildung der beschriebenen Pipeline in der grafischen Nutzeroberfläche des Logic CPF zeigt Abb. 6.26 Das dargestellte Beispiel zeigt die Festlegung der Parameter für das Plugin ExcelGanttReader. Die Speicherung dieser Parameter in der Konfigurationsdatei wird in Abschnitt 6.4.7 erläutert. Als Resultat des Logic CPF-Aufrufs mit der beschrieben Konfiguration wird eine PLCopen-XML-Datei generiert, die einen SFC enthält. Diese Datei kann von allen SPS-Programmierumgebungen, die PLCopen XML ab der Version 2.0 unterstützen, eingelesen und als Grundlage zur weiteren Implementierung des Steuerungsablaufes genutzt werden.

Abb. 6.26   GUI zum Aufruf des Logic CPFs

256

R. Drath et al.

Abb. 6.27   PLCopen-XML-Darstellung im Logic Editor

In Abb. 6.27 ist der resultierenden SFC im AutomationML Logic Editor dargestellt, der unter AutomationML (2009) zum freien Download zur Verfügung steht. Dieser enthält wie das ursprüngliche Gantt-Diagramm acht Schritte, die den Ablauf beschreiben, sowie je einen zusätzlichen Initial- und Endschritt, die aus den Übersetzungsregeln von Gantt-Diagrammen zu IML-Systemen resultieren.

6.4.6  Erweiterungsmöglichkeiten Durch den Aufbau als Plugin-basiertes Framework mit fest definierten Schnittstellen ist eine Erweiterung des Logic CPF möglich. Eine Übersicht bereits existierender Plugins und sinnvoller möglicher Erweiterungen ist in Abb. 6.28 dargestellt.

6  Praktische Anwendung

257 Logic CPF

Frame Application

Plugins

IML DOM

Reader

Conditioner

Writer

GanttExcelReader

GanttPostprozessor

PLCopenWriter20

GanttMSProject Reader

PLCopenGraphic Conditioner PLCopenString Conditioner

ImpulsJPlanReader ImpulsADReader

IDConditioner

PLCopenWriter11 SFC_DelmiaWriter IMLWriter

SFCDelmiaReader PLCopenReader20 PLCopenReader11 IMLReader

Existierende Komponenten Mögliche Erweiterungen

PERTMSProjektReader

Abb. 6.28   Erweiterungsmöglichkeit des Logic CPFs

Als Reader sind zusätzliche Plugins zum Lesen von PLCopen-XML-Dateien, PERT Charts usw. sinnvoll, um die in der Praxis verwendeten Beschreibungsmittel anbinden zu können. Entsprechend groß ist auch die Vielfalt an möglichen Erweiterungen im Bereich der Conditioner und Writer. Conditioner zur Konsistenzprüfung der eingelesen Modelle sind hierbei genauso empfehlenswert wie solche, die die Namen von eingelesen Objekten auf unerlaubte Sonderzeichen prüfen oder grafische Informationen ergänzen können.

6.4.7  Aufbau der Pipeline-Konfigurationsdatei Der Ablauf der Pipeline wird durch eine XML-Konfigurationsdatei festgelegt, die einem XML-Schema gemäß Abb. 6.29 folgt. Das Element ist der Wurzelknoten jeder Konfigurationsdatei. Es besitzt beliebig viele Kindelemente des Typs , welche die einzelnen Plugins der Pipeline benennen. Die Reihenfolge der Ausführung wird durch die Reihenfolge der Plugin-Elemente in der XML-Konfigurationsdatei vorgegeben.

258

R. Drath et al. Path

Pipeline Pipeline Root

Plugin 0..∞

Options

Option 0..∞

Abb. 6.29   XML-Schema der Pipelinekonfigurationsdatei

Jedes -Element definiert einen Reader, Conditioner oder Writer in der Pipeline. Das Element beinhaltet den Pfad zur .NET-Komponente des Plugins als relative oder absolute URI. Um eine möglichst flexible Nutzung des Logic CPFs zu gewährleisten, müssen in vielen Fällen Parameter für die einzelnen Conditioner übergeben werden. Um diese in der Konfigurationsdatei zu definieren, besitzt das Element ein zweites Kindelement , in dem beliebig viele -Elemente angelegt werden können. Jede beinhaltet den Namen und den Wert des jeweiligen Parameters. In Abb. 6.30 ist die Konfigurationsdatei der oben angeführten Beispiel-Pipeline dargestellt. In diesem Beispiel werden drei Plugins in der Pipeline aufgerufen: ExcelGantt­ Reader, GanttPostprozessor und PLCopenWriter20. In allen Fällen wird der Pfad zur Komponente relativ zur Rahmenapplikation angegeben. Für ExcelGanttReader sind in diesem Beispiel acht Parameter angeben, wie StartTimeColumNumber für die Spalte der EXCEL Tabelle, die die Startzeit der einzelnen Balken angibt, oder ExcelFile, der die einzulesende Datei bestimmt. Das Plugin GanttPreprozessor

Abb. 6.30   Beispiel einer Pipeline-Konfigurationsdatei

6

Praktische Anwendung

259

besitzt hingegen keine Parameter, und für den PLCopen-Writer20 wird nur die Zieldatei definiert. Die Optionen der Plugins werden ebenfalls in der XML-Konfigurationsdatei gespeichert.

 6.4.8    Bearbeiten von Pipeline-Konfigurationsdateien   Die Rahmenapplikation bietet die Möglichkeit, Pipeline-Konfigurationsdateien zu laden, zu bearbeiten und gegebenenfalls zu speichern. Dabei können die Buttons Load zum Laden und Save zum Speichern verwendet werden. Hier werden beim Laden die XML-basierte Konfigurationsdatei über einen XML-Reader, der durch das .NET-Framework in die Applikation integriert ist, eingelesen und beim Speichern über einen XML-Writer Konfigurationsdateien erzeugt. Jedes Plugin, das in der Konfigurationsdatei definiert ist, wird in der Pipeline Listbox dargestellt. Die einzelnen Parameter der angegebenen Plugins werden dann im Formularbereich der grafischen Oberfläche angezeigt und können manuell angepasst und mit Werten belegt werden.

 6.5    AutomationML-Beispiel „Philipp“    6.5.1    Wer oder was ist Philipp   In diesem Abschnitt wird anhand eines Beispiels Schritt für Schritt erläutert, wie ein mechatronisches System aus mehreren Komponenten in einer AutomationMLDatei abgebildet werden kann. Die Modellierung erfolgt mit Hilfe des Werkzeuges AutomationML Editor, welches in Abschnitt 6.2 bereits vorgestellt wurde. Das betrachtete Beispiel Philipp ist ein mechatronisches System in Anlehnung an den bekannten „Zappelphilipp“ von Wilhelm Busch bzw. „Hampelmann“ aus dem Schulsport (siehe Abb. 6.31). Er besteht aus einem Rumpf, an dem zwei Arme

Abb. 6.31   3D-Darstellung von Philipp

260

R. Drath et al. 3KLOLSS

OL$UP

5XPSI

OL2EHUDUP

OL8QWHUDUP

OL+DQG

6$(

6$(

6$(

6$(

UH$UP UH2EHUDUP

UH8QWHUDUP

UH+DQG

6$(

6$(

Abb. 6.32   Hierarchische Struktur des Philipp

mit je drei Gliedern montiert sind. Jedes Armglied besteht aus der segmentspezifischen Geometrie und einer Sensor-Aktor-Einheit mit Positionssensoren und Motoren zur Bewegung des Armsegments. Die Sensor-Aktor-Einheiten besitzen keine geometrische Ausprägung und sind deshalb in der Abbildung nicht sichtbar. Im Folgenden werden zunächst die Objektstruktur des Beispiels mit AutomationML modelliert und anschließend das Verhalten, die Geometrie und die Kinematik mit den Objekten im Dachformat verbunden. Abschließend wird erläutert, wie Bibliothekselemente in CAEX erstellt und instanziiert werden. Der Aufbau der AutomationML-Datei erfolgt hier schrittweise manuell und soll den Entstehungsprozess einer AutomationML-Datei verdeutlichen. Die vorgeschriebene Verwendung des Rollenkonzeptes wird der Übersichtlichkeit halber vernachlässigt. Zur Demonstration unterschiedlicher Konzepte sind die für die vollständige Beweglichkeit der Arme notwendigen Sensor-Aktor-Einheiten für beide Arme nicht gleichmäßig verteilt. Der für die Bewegung, des rechten Oberarms nötige SensorAktor ist als Kindelement des Rumpfes modelliert, die für den linken Oberarm hingegen direkt diesem Oberarm zugeordnet. Daher ergibt sich für den Philipp die in Abb. 6.32 dargestellte hierarchische Struktur. Das Verhalten von Philipp wird als Sequencing beschrieben – er vollführt eine Abfolge von Hand- und Armbewegungen. Die Sensor-Aktor-Einheiten der einzelnen Glieder ermöglichen jedem Armsegment eine Bewegung zwischen drei Punkten, die jeweils um 90 Grad versetzt sind (siehe Abb. 6.33). Daraus resultiert ein Gesamtablauf, bei der Philipp aus der Ausgangsposition (1.) seine Arme und Hände ausstreckt, dann in (2.) die Hände anwinkelt, in (3.) die Arme zusammenführt, dann in (4.) bis (6.) zwei mal mit den Händen klatscht und abschließend in (7.) die Arme wieder in die Ausgangsposition bewegt. Die Bewegungsabfolge ist in Abb. 6.33 grafisch wiedergegeben.

6.5.2  Vorgehen zur Abbildung von Philipp mit AutomationML Für die Modellierung von Philipp wird hier exemplarisch der AutomationML Editor verwendet. Bei entsprechender AutomationML-Unterstützung kann natürlich jedes andere Werkzeug analog verwendet werden.

6  Praktische Anwendung Abb. 6.33   Verhalten im Philipp-Beispiel

261 













Weiterhin liegen hier die Geometrie- und Kinematikbeschreibungen mittels COLLADA bereits vor, ebenso die Verhaltensbeschreibung mittels PLCopen XML. Vordefinierte Bibliothekselemente sind nicht vorhanden, diese werden zu einem späteren Zeitpunkt betrachtet. Der Modellierungsprozess gliedert sich in fünf Schritte. 1. Erzeugen der Objekthierarchie im Dachformat Im ersten Schritt wird die Objektstruktur von Philipp erzeugt. Dazu wird im Auto­ mationML Editor eine InstanceHierarchy angelegt. Die Einzelkomponenten von Philipp werden als Kindobjekte vom Typ InternalElement eingehängt. Dieser Schritt wird in Abschnitt 6.5.3 im Einzelnen erläutert. Bei einer realen Anlage entspricht diese Struktur der Anlagenhierarchie. 2. Definition und Implementierung der Objektschnittstellen im Dachformat Im zweiten Schritt werden für die einzelnen Objekte Schnittstellen definiert. ­Diese werden den Objekten als ExternalInterface zugeordnet und von AutomationML­ BaseInterface abgeleitet. Sie beschreiben Anknüpfungspunkte für logische oder physikalische Beziehungen zwischen den Einzelobjekten oder dienen als Referenz auf extern gespeicherte Informationen. Abschnitt 6.5.4 erläutert diesen Schritt im Detail. Bei der Beschreibung einer realen Anlage kann dieser Arbeitschritt mit der Definition von Hardware und Softwareschnittstellen wie I/O-Punkten, Variablen oder Anschlusspunkten für Hydraulikverbindungen verglichen werden. 3. Verknüpfung der Objekthierarchie mit den externen Dokumenten Im dritten Schritt werden die externen COLLADA- und PLCopen-XML-­Dokumente mit dem erzeugten Objektmodell verknüpft. Auf diese Weise erhält das beschrie­-

262

R. Drath et al.

bene System seine geometrische Visualisierung und sein Verhalten. Geometrie, Kinematik und Verhalten kann sowohl an das Gesamtsystem als auch an einzelne Objekte geknüpft werden. Die betreffenden Objekte werden dazu mit einer Schnittstelle ExternalInterface versehen, die von PLCopenXMLInterface bzw. COLLA­ DAInterface abgeleitet sind. Abschnitt 6.5.5 erläutert die Vorgehensweise im Detail. In einer realen Anlagenbeschreibung könnten auf diese Weise den Anlagenkomponenten Steuerungsprogramme, Zustandsbeschreibungen oder CAD-Daten zugeordnet werden. 4. Verknüpfung der Objektschnittstellen Der vierte Schritt dient zur „Verschaltung“ von Objekten. Die Referenzierung der externen PLCopen-XML-Dokumente alleine reicht nicht aus, um ein System hinreichend zu beschreiben. Auch die Verknüpfung der steuerungstechnischen Schnittstellen untereinander muss erfolgen. Dies geschieht durch die Referenzierung auf Signal- oder Variablen-Objekte innerhalb der Verhaltensbeschreibung über das PLCopenXMLInterface. Diese Schnittstellen können in CAEX verbunden werden, was mit Hilfe von Verknüpfungsobjekten vom Typ InternalLink erfolgt. Abschnitt 6.5.6 erläutert die Vorgehensweise mit dem AutomationML Editor im Detail. In einer realen Anlagenplanung ist dieser Arbeitschritt vergleichbar mit der Verschaltung von Anlagenkomponenten. 5. Optional: Erzeugung von Bibliothekselementen aus der Objekthierarchie zur Weiterverwendung in späteren Projekten Der letzte Arbeitschritt in diesem Beispiel ist optional und dient der Erzeugung einer Klassenbibliothek aus Objekten der InstanceHierarchy. Hierzu wird ein Element des beschriebenen Systems in eine Bibliothek überführt, um es als Klasse einer künftigen Wiederverwendung zuzuführen. Die Architektur-Symmetrie zwischen Instanzen und Klassen innerhalb von CAEX erlaubt dies auf einfache Wiese. Diese Klassen stehen damit für weitere Projekte zur Verfügung. Abschnitt 6.5.7 erläutert die Vorgehensweise mit dem AutomationML Editor. In einer realen Anlagenplanung entspricht dies dem Aufbau einer Bibliothek.

6.5.3  Aufbau der Objektstruktur von Philipp Um die Objektstruktur mit dem AutomationML Editor zu beschreiben, muss zunächst ein neues und leeres AutomationML-Dokument erzeugt werden. Dies erfolgt durch den Menüpunkt File/New. Anschließend wird mit dem Menüpunkt Edit/Add/ Instance Hierarchy eine neue Objektstruktur erzeugt (siehe Abb. 6.34). Anschließend werden alle benötigten Komponenten von Philipp als Kindobjekte eingehängt. Kindobjekte werden erzeugt, indem das Vaterobjekt mit der rechten Maustaste angeklickt und im sich öffnenden Kontextmenü der Punkt Add/New In­ ternalElement ausgewählt wird (siehe Abb. 6.35). Eigenschaften des Objektes wie Name und ID werden im Dialogfeld Additional Properties definiert (siehe Abb. 6.36).

6  Praktische Anwendung

Abb. 6.34   Erstellung einer InstanceHierarchy

Abb. 6.35   Erstellung eines

Abb. 6.36   Festlegung von Objekt-Basiseigenschaften

263

264

R. Drath et al.

Abb. 6.37   Objektstruktur im Philipp-Beispiel

Sind alle Objekte modelliert, führt dies zu einem Objektbaum wie in Abb. 6.37 dargestellt. Die entwickelte Objektstruktur stellt alle wesentlichen und für das Engineering relevanten Informationen dar. Die wichtigste Information ist die hierarchische Struktur der Komponenten. Die Strukturierungsprinzipien sind von AutomationML nicht vorgegeben und orientieren sich hier intuitiv an den Abhängigkeiten zwischen den Einzelobjekten. Andere Strukturierungskonzepte sind ebenfalls denkbar und gültig. Eine solche Anlagenstruktur kann vorteilhaft als Basis für die gesamte Kommunikation innerhalb eines Teams eines Engineering-Projektes genutzt werden. So legt sie für die am Engineering-Prozess beteiligten Ökonomen und Ingenieure unterschiedlicher Fachrichtungen klare Begrifflichkeiten bezüglich der Teile eines Engineering-Projektes fest.

6.5.4  Definition und Implementierung der Objektschnittstellen Für Philipp werden nun die steuerungstechnischen und geometrischen sowie kinematischen Zusammenhänge beschrieben und verknüpft. Dazu müssen die benötigten Objektschnittstellen zunächst benannt werden; dies erfolgt für jedes Einzelobjekt in Tab. 6.10. Ein wichtiger Teil der Komponentenhierarchie sind die verschiedenen SensorAktor-Einheiten (SAE), die an den Gliedern beider Arme und am Rumpf montiert sind. Sie sind jeweils gleich aufgebaut und zeigen das gleiche Verhalten. Jede Sensor-Aktor-Einheit besteht aus drei Sensoren für die drei möglichen Positionen P1, P2 und P3 – siehe Abb. 6.38a). Weiterhin besitzt sie zwei Motoren für die Bewegungsrichtungen und drei Signale zur Ansteuerung der Bewegung in die drei

6  Praktische Anwendung

265

Tab. 6.10   Schnittstellen für Teilobjekte von Philipp Element

Informationstypen

Philipp Rumpf Rechter Arm Linker Arm Rechter Oberarm Rechter Unterarm Rechte Hand Linker Oberarm Linker Unterarm Linke Hand Sensor-Aktor-Einheiten

Geometrie

Kinematik

Sequencing

Behaviour

X X X X X X X X X X –

– X X X X X X X X X –

X – – – – – – – – – –

– – X X X X X X X X X

möglichen Positionen. Für eine Sensor-Aktor-Einheit sind somit acht Signale vorzusehen, siehe Abb. 6.38b). Das Verhalten der Sensor-Aktor-Einheit ist in Abb. 6.39 mit Hilfe eines State Chart abgebildet. Entweder sind beide Motoren ausgeschaltet oder jeweils einer der beiden Motoren ist aktiv. In der Objektstruktur werden die Sensor-Aktor-Einheiten nicht weiter in ihre Bestandteile unterteilt, lediglich ihre acht steuerungstechnischen Schnittstellen sind von Bedeutung. Diese werden in CAEX mit Elementen vom Typ COLLADAInterface bzw. PLCopenXMLInterface abgebildet. Eine Schnittstelle vom Typ PLCopenXMLInter­ face ermöglicht das „Publizieren“ von Variablen oder Signalen in einem PLCopenXML-Dokument. Diese können anschließend im CAEX-Objektmodell außerhalb der PLCopen-XML-Dokumente verknüpft werden. Dies erfolgt in Abschnitt 6.5.6. Allein die sechs benötigten Sensor-Aktor-Einheiten führen zu 48 Schnittstellen, die zur Beschreibung seines Verhaltens relevant sind. Im Folgenden werden der Übersichtlichkeit halber nur die Schnittstellen der linken Hand beschrieben.

Sensor-Aktor-Einheit (SAE) SAE

Behaviour

SAE

P1

Boolean:EIN:zuP1 Boolean:EIN:zuP2 Boolean:EIN:zuP3 Boolean:AUS:zuP1

P2

Boolean:AUS:zuP2 Boolean:AUS:zuP3 Boolean:AUS:motorD1

P3

a

Boolean:EIN:motorD2

b

Abb. 6.38a, b   Aufbau und Signale einer Sensor-Aktor-Einheit des Philipp

266

R. Drath et al.

stm SAE

Bewegung Motor1

IF zuP2 = true AND inP3 = true THEN motorD1 = true

IF zuP1 = true AND (inP3 = true or inP2 = true) THEN motorD1 = true

IF inP1 = true AND zuP1 = true THEN motorD1 =false

IF inP2 = true AND zuP2 = true THEN motorD1 =false

OFF IF inP3 = true IF zuP3 = true AND zuP3 = true AND (inP1 = true OR inP2= true) THEN motorD2 = false THEN motorD2 = true IF inP2 =true AND zuP2 =true THEN motorD2 =false

Bewegung Motor2

IF zuP2 = true AND inP1 = true THEN motorD2 = true

Abb. 6.39   Verhalten der Sensor-Aktor-Einheit des Philipp

Für jede der in Tab. 6.11 genannten Schnittstellen muss nun im AutomationML Editor je eine Schnittstelle vom Typ PLCopenXMLInterface eingefügt werden. Dies erfolgt, indem per Drag&Drop die Standard-AutomationML-Schnittstellenklasse PLCopenXMLInterface auf die jeweilige Sensor-Aktor-Einheit gezogen wird, wie Abb. 6.40 illustriert. Im Ergebnis entsteht für die Sensor-Aktor-Einheit SAE_LinkeHand eine in Abb. 6.41 dargestellte Struktur.

6.5.5  Integration externer Informationen Die Referenzierung externer Dokumente ist derzeit für COLLADA und PLCopen-XML-Dokumente definiert. Für Philipp muss jeder Sensor-Aktor-Einheit ein PLCopen-XML-Dokument zugeordnet werden, welches deren Verhalten gemäß Abb. 6.39 beschreibt. Das Steuerungsverhalten wird hingegen dem obersten Objekt Philipp zugeordnet. Die Beschreibung des als State Chart dargestellten Verhaltens der Sensor-Aktor-Einheit der linken Hand erfolgt über das PLCopen-XML-Dokument, das auszugsweise in Abb. 6.42 wiedergegeben ist (siehe dazu auch Kap. 4). Wichtige Teile dieser Verhaltensbeschreibung sind die einzelnen Ein- und Ausgangsschnittstellen der Sensor-Aktor-Einheit, die als Variablen ausgeprägt sind. Diese müssen nun mit den vorbereiteten Schnittstellen des AutomationML-Objektes SAE_LinkeHand verknüpft werden. Eine solche „Publikation“ in CAEX erfolgt in jeder erstellten Schnittstelle durch die Eingabe des eindeutigen Pfades zur jeweiligen Variable in das Standardattribut Path. Dieser Pfad umfasst den Dateipfad sowie die globale ID der entsprechenden Variablen. Für die Schnittstelle

6  Praktische Anwendung

267

Tab. 6.11   Verhaltensbezogene Schnittstellen der linken Hand Element

Schnittstelle

Datentyp

Richtung

Beschreibung

Philipp

SAE_Linke-Hand _zuP1 SAE_Linke-Hand _zuP2 SAE_Linke-Hand _zuP3 SAE_Linke-Hand _inP1 SAE_Linke-Hand _inP2 SAE_Linke-Hand _inP3 SAE_LinkeHand _zuP1

Boolean

Ausgang

Boolean

Ausgang

Boolean

Ausgang

Boolean

Eingang

Linke Hand bewegt sich in Richtung P1 Linke Hand bewegt sich in Richtung P2 Linke Hand bewegt sich in Richtung P3 Linke Hand ist in P1

Boolean

Eingang

Linke Hand ist in P2

Boolean

Eingang

Linke Hand ist in P3

Boolean

Eingang

SAE_LinkeHand _zuP2

Boolean

Eingang

SAE_LinkeHand _zuP3

Boolean

Eingang

SAE_LinkeHand _inP1 SAE_LinkeHand _inP2 SAE_LinkeHand _inP3 SAE_LinkeHand _MotorD1

Boolean

Ausgang

Boolean

Ausgang

Boolean

Ausgang

Boolean

Ausgang

SAE_LinkeHand _MotorD2

Boolean

Ausgang

Anforderung zur Bewegung der SAE in Richtung P1 Anforderung zur Bewegung der SAE in Richtung P2 Anforderung zur Bewegung der SAE in Richtung P3 Signalisiert, dass SEA P1 erreicht hat Signalisiert, das SEA P2 erreicht hat Signalisiert, das SEA P3 erreicht hat Steuert Motor 1 an zur Drehbewegung in Richtung 1 Steuert Motor 2 an zur Drehbewegung in Richtung 2

Sensor-AktorEinheit der linken Hand

SAE_LinkeHand_zuP1 muss entsprechend die eindeutige Adresse der Datei SAE_ Behaviour.xml sowie die globale ID der Variablen toP1 eingefügt werden. Dies ist in Abb. 6.43 dargestellt. Das Attribut Path erhält somit den Wert: Path=file:///C:/Temp/SAE_Behaviour.xml#XSID_of_toP1

6.5.6  Verknüpfung der Objektschnittstellen Den abschließenden Schritt bildet die Verknüpfung der Schnittstellen innerhalb der Objekthierarchie. So müssen die Signal-Ein- und -Ausgänge der Sensor-Aktor-Ein-

268

Abb. 6.40   Integration von Schnittstellen im Philipp-Beispiel

Abb. 6.41   Schnittstellen im Philipp-Beispiel

R. Drath et al.

Abb. 6.42   Ausschnitt der PLCopen-XML-Datei zum Behaviour der Sensor-Aktor-Einheit

Abb. 6.43   Integration der PLCopen-XML-Datei der Sensor-Aktor-Einheit

270

R. Drath et al.

Abb. 6.44   Verknüpfung der Schnittstellen der Sensor-Aktor-Einheit

heiten mit denen der Gesamtsteuerung verknüpft werden. Für jede Verknüpfung wird entsprechend Abschnitt 2.5.5 ein Element des Typs InternalLink erzeugt, welches zwei Schnittstellen unter Nutzung ihrer globalen ID in CAEX untereinander verbindet. Hierfür wird im AutomationML Editor per Drag&Drop eine der beiden zu verlinkenden Schnittstellen auf die andere gezogen. Dies erzeugt nach einer Bestätigungsabfrage einen solchen InternalLink, siehe Abb. 6.44. Abschließend wird der Link manuell mit dem Namen SAE_LinkeHand_zuP3 versehen. Der hier erzeugte InternalLink wird in Abb. 6.45 als XML-Code dargestellt.

Abb. 6.45   Beispiel eines InternalLink-Objekts

6  Praktische Anwendung

271

Sind alle Schnittstellen erzeugt, die entsprechenden externen Information referenziert und untereinander verknüpft, ist das AutomationML-Dokument vollständig und kann gespeichert werden.

6.5.7  Erstellen von Bibliotheksobjekten Das Beispiel der mehrfach verwendeten Sensor-Aktor-Einheit verdeutlicht, dass es sinnvoll ist, Teile eines Projektes in eine Bibliothek zu überführen und damit später wieder verwenden zu können. In AutomationML wird dazu eine CAEXBibliothek vom Typ SystemUnitClassLib erzeugt und eine Klasse vom Typ SystemUnitClass eingehängt. Das Erzeugen einer neuen Bibliothek erfolgt im AutomationML Editor mit dem Menüpunkt Edit/Add/SystemUnitClassLib, siehe Abb. 6.46. In dieser neuen SystemUnitClassLib kann eine neue Klasse erstellt werden. Hierzu wird mit der rechten Maustaste auf die Bibliothek geklickt und aus dem erscheinenden Kontextmenü der Punkt Add/New SystemUnitClass selektiert. Es erscheint eine neue Klasse, sie wird hier mit dem Namen SAE_Class versehen. Im nächsten Schritte müssen alle Schnittstellen der bereits modellierten SensorAktor-Einheit an der Klasse modelliert werden – dies kann manuell erfolgen oder

Abb. 6.46   Erstellung einer neuen SystemUnitClassLib

272

R. Drath et al.

Abb. 6.47   Erstellung der Inhalte einer neuen

durch Kopieren der bereits definierten Schnittstellen. Dies ist möglich, weil das Datenmodell einer SystemUnitClass identisch zu dem eines InternalElements ist. Die manuelle Erzeugung der Schnittstellen erfolgt analog zu den Abschnitt 6.5.4 und 6.5.5. Das Kopieren der bereits definierten Schnittstellen erfolgt per Drag&Drop wie in Abb. 6.47 dargestellt. Dabei werden alle Attribute der Unterstrukturen mit kopiert. Dies gilt zum Beispiel auch für die Verlinkungen auf PLCopen-XML-Dokumente. Die einzelnen Attribute der neuen SystemUnitClass müssen hier manuell eingetragen werden – diese Funktion wird vom AutomationML Editor derzeit nicht bereitgestellt. Ist dieses erfolgt, so ergibt sich eine Klassenstruktur für die SensorAktor-Einheit wie in Abb. 6.48 abgebildet. Diese Klasse kann beliebig oft instanziiert und in verschiedenen Projekten wiederverwendet werden. Es wird nochmals darauf hingewiesen, dass die hier beschriebene Modellierung das von AutomationML vorgeschriebene Rollenkonzept aus Gründen der Übersicht

Abb. 6.48   Struktur der Klasse SAE_Class

6  Praktische Anwendung

273

vernachlässigt. In der Praxis müssen alle AutomationML-Objekte eine Rollenklasse referenzieren, um mit den semantischen Regeln von AutomationML ausgewertet werden zu können (siehe Abschnitt 2.7.2). Dies erfolgt mit dem AutomationML Editor, indem die Rollenklasse per Drag&Drop auf ein AutomationML-Objekt gezogen wird.

6.6  OPC-Konfiguration 6.6.1  Übersicht OPC (OPCFoundation 2009) – ursprünglich Abkürzung für OLE for Process Control – ist ein häufig verwendeter Kommunikationsstandard in der industriellen Automatisierungstechnik. Insbesondere weil die OPC-Konfiguration bereits in frühen Engineering-Phasen von einigen Werkzeugen der Digitalen Fabrik umfangreich durchgeführt werden kann, ist die Übertragung dieser Informationen in spätere Engineering-Phasen von Interesse. Daher sieht AutomationML Mechanismen und Konzepte vor, um die Elemente der OPC-Kommunikation zu beschreiben. OPC liegt ein software-basiertes Client-Server-Konzept zu Grunde, bei dem ein Server den Clients verschiedene Signalvariablen und deren Werte zur Verfügung stellt, die er von Hardwareseite erhält. Wird die Schnittstelle auf Client- oder Server-Seite spezifikationskonform implementiert, können Server und Clients unterschiedlicher Hersteller miteinander kommunizieren. Dabei ist es wichtig, dass OPC nicht nur zur Beobachtung von Signalen verwendet werden kann, sondern auch für den schreibenden Zugriff auf die Signale. Im Anwendungsumfeld bedeutet dies einen steuernden Eingriff in die Anlagenhardware. Um die OPC-Technologie in AutomationML modellieren zu können, wurde die Rolle OPCServer (siehe Abschnitt 2.7.4) in der Bibliothek AutomationMLCSRo­ leClassLibrary definiert, siehe Abb. 6.49. Die Attribute der Rollenklasse OPCServer (siehe Abb. 6.49) werden in Tab. 6.12 dargestellt. Darüber hinaus wurde zur Modellierung der einzelnen OPC-Signale die Schnittstellenklasse OPCTag definiert, siehe Abb. 6.50. Ein OPCTag wird durch die Attribute in Tab. 6.13 beschrieben.

Abb. 6.49   Rollenklasse OPCServer

274 Tab. 6.12   Attribute der Rollenklasse OPCServer

R. Drath et al. Attributname

Erläuterung

ProgID

Eindeutige Bezeichnung des Servers auf einem Rechner IP-Adresse des Rechners Beispielsweise OPC Data Access V3.0 Synchroner oder asynchroner Zugriff

AccessPath OPCVersion AccessType

Abb. 6.50   OPCTag-Schnittstelle Tab. 6.13   Attribute der Schnittstellenklasse OPCTag

Attributname

Erläuterung

TagName DataType

Name des OPCTags XML-Datentyp der OPC-Variablen, wie beispielsweise xs:int OPC-Datentyp der OPC-Variablen, wie beispielsweise I1, BSTR Pfad zur OPC-Quelle, z. B. „Gruppe. Variablenname“ oder „Variablenname“ Mögliche Zugriffsrichtungen. Mögliche Werte sind: Read, Write und ReadWrite

OPCDataType SignalPath AccessPermissions

Tab. 6.14   Zuordnung von OPC- und XML-Datentypen

OPC-Datentypen

XML-Datentypen

„I1“, „I2“ „UI1“, „UI2“, „UI4“ „R4“, „R8“ „CY“, „BSTR“, „Variant“ „Date“

„xs:int“ „xs:unsignedInt“ „xs:float“ „xs:string“ „xs:date“

Die Unterscheidung der Datentypen in den Attributen OPCDataType und Da­ taType wurde vorgesehen, um sowohl die nativen OPC-Datentypen als auch die neutralen XML-Datentypen abbilden und übertragen zu können (siehe Tab. 6.14) Verbindungen zwischen Signalen der SPS und Variablen des OPC-Servers werden mit CAEX-InternalLinks (siehe Abschnitt 2.5.5) abgebildet.

6  Praktische Anwendung

275

6.6.2  Beispiel Abbildung 6.51 erläutert das Konzept anhand eines Beispiels. Es besteht aus einem ein- und einem ausführenden Förderband sowie einem Drehtisch und einem Roboter. Sie alle sind mit einer SPS verbunden, die ihrerseits wiederum mit einem softwareseitigen OPC-Server kommunizieren kann. Jede der Einzelkomponenten besitzt mindestens ein Prozesssignal. Diese werden alle von der SPS über eine analoge und eine digitale Baugruppe gelesen bzw. geschrieben. Auch der OPC-Server verwaltet alle diese Signale als OPC-Variablen. Die Modellierung mit AutomationML wird in Abb. 6.52 dargestellt. Die zu modellierende OPC-Kommunikation wird in Abb. 6.51 verdeutlicht. Die Modellierung in AutomationML beginnt mit dem Objekt Beispielanlage und dessen Kind Ressourcen (siehe Abb. 6.52). Als Kinder eingehängt finden sich hier die einzelnen Anlagenkomponenten Förderband1, Drehtisch, Roboter, Förder­ band2, SPS und OPCServer. Das SPS-Objekt beinhaltet zwei verschiedene Baugruppen mit ihren Signalen. Auch den übrigen Anlagenobjekten sind Signale zugeordnet, sie sind als ExternalInterface modelliert.

Abb. 6.51   Verbindungen in der OPC-Beispielanlage

276

R. Drath et al.

Abb. 6.52   InstanceHierarchy der OPC-Beispielanlage

Die Schnittstelle Signal1 in Abb. 6.52 ist die Repräsentation eines hardwareseitigen digitalen Eingangssignals des Objekts Förderband1. Es wird durch einen InternalLink (gestrichelt dargestellt) mit einem digitalen Ausgang der Baugruppe1 der SPS namens Signal1 verbunden. Diese Verknüpfung erhält in diesem Beispiel den Namen HWLink1 (siehe Abb. 6.51 und 6.53). Das Signal1 der Baugruppe1 soll nun auch per OPC kommuniziert werden. Daher wird es durch einen InternalLink namens OPCLink1 (gepunktet dargestellt) mit dem OPCSignal1 des OPC-Servers verbunden. Das OPCSignal1 ist eine Variable vom DataType=I4, mit der Eigenschaft AccessPermission=Write, da es modifiziert werden kann. So werden nun alle Signale der Anlage mit der SPS und schließlich mit dem OPC-Server verknüpft. Die Gesamtübersicht der Verknüpfungen ist in grafischer Form in Abb. 6.51 dargestellt. Abbildung 6.53 zeigt den XML-Quelltext für das Beispiel, wobei hier der Übersichtlichkeit halber eine Reihe von Attributen ausgeblendet wurden. Durch die Belegung der einzelnen Attribute wird es Anwendungen wie SCADA-Systemen ermöglicht, automatisch komplette OPC-Konfigurationen vorzunehmen.

6  Praktische Anwendung

Abb. 6.53   XML-Quelltext der OPC-Beispielanlage

277

278

R. Drath et al.

6.7  Umgang mit großen CAEX-Dateien Bei der Planung industrieller Anlagen entstehen typischerweise große Mengen an Planungsdaten. Die Verwendung von COLLADA und PLCopen XML erlaubt bereits eine gewisse Verteilung dieser Daten, dennoch kann das zentrale CAEX-Dokument schwer handhabbare Größenordnungen erreichen. Große CAEX-Dateien entstehen typischerweise durch große Bibliotheken oder durch vielfaches Instanziieren komplexer Bibliothekselemente. Dies wird in Abb. 6.54 vereinfacht dargestellt. Um große CAEX-Dateien besser handhaben zu können, wird eine Verteilung der Strukturen in mehrere Dateien empfohlen. Dieses Konzept wird von CAEX explizit unterstützt. Mit Hilfe des CAEX-Elementes ExternalReference erfolgt die Referenzierung externer Dateien. Beispiele von Referenzen sind in Abb. 6.55 angegeben. Im Ergebnis entsteht ein CAEX-Masterdokument sowie eine Anzahl von SubDokumenten. Ausgelagerte Substrukturen der Anlagentopologie können beim Navigieren im Zentraldokument bei Bedarf geöffnet werden (vgl. Abb. 6.56).

Abb. 6.54   Beispiel für den Umgang mit großen CAEXDateien

Abb. 6.55   Beispiele für die Referenzierung externer CAEX-Dateien

6  Praktische Anwendung

279

Abb. 6.56   Verteilung von Daten in mehrere CAEX-Dateien

CAEX-Dokument

CAEX Sub-Dokument 1

CAEX Sub-Dokument 2

CAEX Sub-Dokument 3

6.7.1  Auslagerung von Bibliotheken Das Auslagern von Bibliotheken ist ein naheliegender Anwendungsfall zur Reduktion von CAEX-Dateien und ist beim Datenaustausch prinzipiell empfehlenswert. Im Ergebnis werden nur noch die Projekt-Rohdaten ausgetauscht (vgl. Abb. 6.57). Dies reduziert nicht nur die Dateigröße, sondern ist zudem ein geeignetes Mittel für den Schutz von geistigem Eigentum, wenn Bibliotheken oder Teile davon nicht am Datenaustausch teilnehmen sollen. Um dies zu erreichen, wird im ersten Schritt die Bibliothek in einer separaten CAEX-Datei gespeichert, beispielsweise in einer Datei meineBibliothek.aml (vgl. Abb. 6.57). Im Zentraldokument wird nur noch die Instanzhierarchie gespeichert. Um auf Bibliothekselemente der externen Datei zugreifen zu können, wird im Zentraldokument zunächst ein Alias definiert. Dies erfolgt mit Hilfe einer CAEX

&$(;'RNXPHQW

Abb. 6.57   Auslagerung von Bibliotheken in eine separate CAEX-Datei

PHLQH%LEOLRWKHNDPO

280

R. Drath et al.

Abb. 6.58   Beispiel zur Referenzierung einer externen Bibliothek

. Abbildung 6.58 verdeutlicht zudem, wie die referenzierte externe Datei mit dem Alias Datei01 versehen wird. Die einzelnen Objekte referenzieren mit Hilfe dieses Alias direkt in die externe Bibliothek. Zum Verständnis von AutomationML ist wichtig, dass dieser Mechanismus keine ursprüngliche XML-Funktionalität darstellt, sondern eine CAEX-Definition ist. Sie muss von einem Werkzeug explizit unterstützt werden. CAEX stellt die dafür benötigten Informationen zur Verfügung, kann aber die Konsistenz dieser Angaben nicht sicherstellen.

6.7.2  Aufteilung der Anlagenstruktur Die Anlagentopologie selbst kann ebenfalls zerlegt werden. Dies ist empfehlenswert, wenn die Projekthierarchie trotz Auslagerung der Bibliotheken zu groß wird. Es ist ebenso dann sinnvoll, wenn die Planung von mehreren Planern, Abteilungen oder unterschiedlichen Firmen durchgeführt wird und einzelne Substrukturen getrennt geplant werden. In diesem Fall kann innerhalb der CAEX-Datei an beliebigen Stellen ein „Schnitt“ durchgeführt werden. Dies wird in Abb. 6.59 verdeutlicht, die einzelnen Zellen des Beispieles werden in eigene Dateien ausgelagert. Dazu müssen im ersten Schritt die Zellenobjekte in separaten CAEX-Dateien Firma01. aml, Firma02.aml und Firma03.aml gespeichert werden. Im zweiten Schritt müssen

6  Praktische Anwendung

281

Abb. 6.59   Zerlegung einer Instanz-Hierarchie in mehrere Dateien

)LUPDDP )LUPDDPO O

%HLVSLHOSURMHNWDPO

)LUPDDP )LUPDDPO O

)LUPDDP )LUPDDPO O

im Zentraldokument Referenzen und Aliase mit dem Datentyp ExternalReference zu diesen externen Dateien abgebildet werden. Das Zentraldokument speichert die Anlagenhierarchie nur noch bis zu denjenigen Objekten, an denen der Schnitt erfolgen soll. Diese Objekte referenzieren mit Hilfe der Aliase die korrespondierenden Objekte in den externen Dateien anhand ihrer ID. Dies bedeutet, dass im Zentraldokument die Objekte Zelle01, Zelle02 und Zelle03 nur noch als „Mirror-Objekte“ fungieren und auf ihr Original verweisen. Das „Mirror-Konzept“ wird in Abschnitt 2.5.5 erläutert.

Abb. 6.60   Zentraldokument des Beispielprojektes

282

R. Drath et al.

Abb. 6.61   Externes Dokument Firma01.aml des Beispielprojektes

Der zugehörige XML-Quelltext für das Zentraldokument ist in Abb. 6.60 abgebildet. Es zeigt die Referenzierung der Fremddokumente mit und verdeutlicht, dass die Objekte Zelle01, Zelle02 und Zelle03 mit ihrem jeweilige Attribut RefBaseSystemUnitPath nicht mehr ihre ursprünglichen Klassen referenzieren, sondern die zugehörigen Original-Objektinstanzen in den externen Dateien. Ein Beispiel für eine externe Datei ist in Abb. 6.61 dargestellt. Dieses Dokument besitzt keinerlei Kenntnis von seinem Zentraldokument, sondern modelliert seine Substruktur unabhängig und eigenständig. Von hier können wie gewohnt externe Bibliotheken referenziert werden, vergleiche dazu Abschnitt 6.7.1.

6.7.3  Verteilung  von Daten in eine Hierarchie   von Verzeichnissen Ein weiteres empfehlenswertes Konzept zur Beherrschung von Komplexität besteht darin, zusammengehörige Dokumente in einem eigenen Dateiordner zu speichern. Dies wird in Abb. 6.62 verdeutlicht: das Zentraldokument ist im Ordner Beispiel­ projekt gespeichert, wohingegen die Sub-Dokumente in jeweils eigenen Ordnern liegen. Hier können neben den CAEX-Dateien auch zugehörige PLCopen XMLoder COLLADA-Dokumente gespeichert werden. Dies erleichtert das Auffinden und Wiederverwenden von Substrukturen oder Objekten. Auf diese Weise kann die Projekthierarchie ganz oder in Teilen durch eine korrespondierende Verzeichnisstruktur nachgebildet werden. Die Navigation in diesen Verzeichnishierarchien fällt leicht, weil sie der Projektanlagenstruktur entspricht.

Abb. 6.62   Abbildung der Projektstruktur mittels Dateiordner

6  Praktische Anwendung

283

6.8  Umgang mit großen COLLADA-Dokumenten Geometrie-Informationen, die durch COLLADA beschrieben werden, beinhalten häufig umfangreiche Datenmengen. Daher empfiehlt es sich, nicht alle geometrischen und kinematischen Daten in einem großen COLLADA-Dokument zu speichern, sondern für jede Einzelkomponente ein eigenes Dokument anzulegen. Aber selbst die Datenmenge einer einzigen Komponente kann immens sein. Da COLLADA wie CAEX multidokumentenfähig ist, können die Daten grundsätzlich beliebig verteilt werden, jedoch sollte eine gewisse Ordnung eingehalten werden, um eine Redundanz von Teildaten zu vermeiden. Im Folgenden wird ein Konzept vorgestellt, das sich in der Praxis bewährt hat.

6.8.1  Verwendung eines Masterdokuments Durch die Verwendung von URIs besitzt COLLADA einen sehr mächtigen Mechanismus zur Referenzierung anderer Dokumente. Dieser Mechanismus funktioniert, solange die referenzierten Daten autark sind. Beispielsweise ist die Beschreibung einer Geometrie durch das XML-Element vollkommen unabhängig von seiner Verwendung in einer Produkthierarchie () oder seiner Farbgebung (). Daher kann eine Geometrie ohne Bedenken in ein anderes COLLADA-Dokument ausgelagert werden. Allgemein gesagt, können alle COLLADA-Elemente, die das Attribut id besitzen, ausgelagert werden. Anders sieht es bei Elementen aus, deren Kindelemente über eine SID referenziert werden. Da SIDs nur in einem Dokument eindeutig sind, müssen beide Partner im selben Dokument sein, damit die Referenzierung aufgelöst werden kann. In einem Masterdokument sind alle COLLADA-Elemente einer Komponente vereint, die auf diese Weise miteinander verbunden sind. Es bildet den zentralen Einstiegspunkt für ein CAEX-Dokument. Folgende Inhalte sollten in diesem Masterdokument vollständig beschrieben sein: • Produktbaum der visuellen Szene • Kinematische Beschreibung inkl. Gelenke, Modell, Systeme usw. • Einstiegspunkt für CAEX-Dokumente mit einem -Element Daraus ergibt sich für das Masterdokument die in Abb. 6.63 dargestellte Struktur. Wie zu sehen ist, sind hier keine Geometrien definiert. Diese sollten in einem oder mehreren separaten COLLADA-Dokumenten abgelegt werden. Um sie in das COLLADA-Masterdokument einzubinden, können diese durch das Element referenziert werden.

284

R. Drath et al.

Abb. 6.63   Aufbau des Masterdokuments

6.8.2  Auslagerung der verschiedenen Detaillierungsgrade Wenn zu einer Komponente verschiedene Detaillierungsgrade abgelegt werden sollen, so sind dies geeignete Kandidaten zur Auslagerung. Zunächst bietet es sich

6  Praktische Anwendung

285

Abb. 6.64   Zerlegung eines COLLADADokuments in mehrere Dateien

Part1.dae

Robot_master.dae

Part2.dae

Materials.dae

an, alle Einzelgeometrien desselben Detaillierungsgrades in einem eigenen COLLADA-Dokument abzulegen, z. B. ein Dokument für alle BREP-Beschreibungen und ein anderes Dokument für alle Mesh-Geometrien. Das Masterdokument verweist auf diese Geometrien über den internen Level-of-Detail-Mechanismus (siehe Abschnitt 3.2.7). Der prinzipielle Aufbau der Verteilung ist in Abb. 6.64 und 6.65 dargestellt. Durch diese Vorgehensweise der Verteilung ist sichergestellt, dass z. B. die Kinematik nur einmal definiert werden muss. Sie funktioniert mit jeder Detaillierungstiefe, da sie im Masterdokument mit dem Produktbaum verbunden ist.

6.8.3  V  erteilung der Daten in einer Hierarchie von Verzeichnissen Wie in Abschnitt 6.7 bereits begründet, bietet sich auch hier die Zusammenfassung von COLLADA-Dokumenten in einem Verzeichnis an. Es sollte zu jeder Komponente, die eine Beschreibung durch COLLADA besitzt, ein Verzeichnis mit dessen Namen existieren. In diesem Verzeichnis sollten alle COLLADA-Dokumente, die diese Komponente beschreiben, zusammengefasst sein. Eine beispielhafte Dokumentenstruktur wird in Abb. 6.66 dargestellt.

286

Abb. 6.65   Masterdokument mit LoD-Unterstützung

R. Drath et al.

6  Praktische Anwendung

287

Abb. 6.66   Vorschlag einer Dokumentenstruktur für COLLADA-Dokumente

6.9  Workflow-Empfehlungen 6.9.1  Übersicht Der Workflow bei der Anlagenplanung ist üblicherweise ein gewachsener Prozess, der idealerweise mit einer klaren Aufgabenteilung, Werkzeugspezialisierung und geordneten Organisationsstruktur einhergeht – und somit nur aufwändig änderbar ist. AutomationML erfordert nicht, dass bestehende Workflows verändert werden müssen, sondern kann schrittweise in vorhandene Workflows eingeführt werden. Dies schützt den Anwender vor den Kosten und Risiken einer umfassenden Prozessänderung; etablierte Organisationsstrukturen können bei der Einführung von AutomationML erhalten bleiben. Darüber hinaus ermöglicht AutomationML ebenfalls große Veränderungen bestehender Prozesse mit deutlichen Verbesserungen bis hin zur Definition neuer Prozesse. Dieser Abschnitt stellt eine Reihe von Empfehlungen zusammen, die für den Umgang mit AutomationML im Speziellen, aber auch für die Einführung von automatischem Datenaustausch im Allgemeinen gelten. Die wichtigste Empfehlung gleich vorweg: AutomationML ist kein Zaubermittel, der Datenaustausch zwischen komplexen Planungswerkzeugen sollte schrittweise und Bedacht eingeführt werden.

6.9.2  V  om manuellen zum voll automatisierten Datenaustausch Der Datenaustausch zwischen Werkzeugen kann manuell, semi-automatisch oder vollautomatisch erfolgen. Jede dieser Methoden hat ihre Vor- und Nachteile. Grundsätzlich ist dabei zwischen dem „ersten Datenaustausch“ ohne Berücksichtigung

288

R. Drath et al.

bereits importierter Daten und dem „wiederholten Datenaustausch“ zu unterscheiden, bei dem bereits importierte Daten vorliegen und aktualisiert werden sollen. Manueller Datenaustausch: Der manuelle Datenaustausch ist ein noch immer gebräuchliches Mittel. Der Verfahrenstechniker, E-Techniker oder Mechaniker dokumentiert die Ergebnisse seiner Arbeit in Form gedruckter Dokumente. Die Empfänger sichten die Dokumente, korrigieren sie händisch und übertragen benötigte Teile davon in ihre Werkzeuge. Manueller Datenaustausch besitzt den Vorteil, dass die Daten nochmals durch die Hände eines Fachmanns gehen und auf Konsistenz und Korrektheit geprüft und gefiltert werden. Weiterhin sind die Verantwortlichkeiten und Eigentumsverhältnisse der Daten geklärt, der Datenaustausch ist ein bewusster und durch Menschen initiierter Akt – und findet u. a. auch deshalb hohe Akzeptanz, weil er die menschliche Entscheidungskraft erfordert. Fehler und Verantwortlichkeiten lassen sich aufgrund abgehefteter Dokumentation leicht nachweisen. Leider ist der manuelle Datenaustausch mit hohem Zeitaufwand und Kosten verbunden. Zudem ist mit Fehlern des Planers zu rechnen. Der „wiederholte Datenaustausch“ ist prinzipbedingt problematisch, weil dazu zunächst die Änderungen manuell ermittelt werden müssen – ein umständlicher und bei großen Datenmengen aufwändiger Vorgang. Semi-automatischer Datenaustausch: Der semi-automatische Datenaustausch erfolgt ähnlich, allerdings werden statt Papier nunmehr elektronische Dokumente wie Excel-Listen oder ASCII-Dateien übergeben. Die Dateiformate sind typischerweise nicht standardisiert und können sich von Kunde zu Kunde, von Projekt zu Projekt und sogar von Datei zu Datei unterscheiden. Der Charakter dieser Vorgehensweise entspricht weitestgehend dem des manuellen Datenaustausches, denn der Mensch steht als Prüfinstanz und Entscheider noch immer darüber. Die Vorteile dieser Vorgehensweise sind offensichtlich: es geht deutlich schneller, große Datenmengen fehlerfrei zu importieren. Aufgrund der Veränderlichkeit der Datenformate und dem fehlenden Bezug zwischen Eingangs- und Ausgangsdaten treten beim „wiederholten Datenaustausch“ allerdings häufig Probleme beim Ermitteln der Änderungen auf. Daher erfolgt ein wiederholter Datenaustausch häufig schneller durch Löschen der Daten im Zielwerkzeug und Re-Import der Quelldaten. Vollautomatischer Datenaustausch: Hinter dem Wunsch nach einem voll automatisierten Datenaustausch steckt die Absicht, Konsistenz zwischen den Daten einer Werkzeugkette kostengünstig, schnell, fehlerfrei und wiederholt auf Knopfdruck oder sogar ohne jede Interaktion herstellen zu können. Insbesondere sollen die Probleme des im iterativen Engineering erforderlichen „wiederholten Datenaustausches“ endlich gelöst werden, beispielsweise die aufwändige Ermittlung der Änderungen. Allerdings verbergen sich dahinter häufig unerwünschte Konsequenzen, denn die oben genannten menschlichen Filter- und Prüfmechanismen fehlen. Diese lassen sich in rechtlich/organisatorische und technische Konsequenzen unterscheiden und müssen vorab geklärt werden. Die rechtlich/organisatorischen Konsequenzen des vollautomatischen Datenaustausches ergeben sich aus der Tatsache, dass Engineering-Daten offenen oder

6  Praktische Anwendung

289

verdeckten Eigentumsverhältnissen unterliegen. Insbesondere der bidirektionale automatische Datenaustausch führt zu einer Vermischung dieser Eigentums- und somit Verantwortungsverhältnisse. Warum? Die Phasenseparation im Workflow und die damit einhergehenden Werkzeug-Inseln rühren daher, dass einzelne Planungsschritte häufig von unterschiedlichen Abteilungen oder Firmen durchgeführt werden. Dies ist eine Konsequenz der Arbeitsteilung. Jede beteiligte Gruppe ist verantwortlich für ihre Planungsergebnisse und besitzt möglicherweise schützenswerte Kernkompetenzen. Ein automatischer Datenaustausch würde diese Daten evtl. unautorisiert verändern oder ungewollt offenlegen – wer ist dann verantwortlich für sie und wem gehören sie? Ein Beispiel: Der Verfahrenstechniker ist verantwortlich für die korrekte Planung der Anlage, somit geistiger Urheber des R&I-Fließbildes und verantwortlich für den zugrundeliegenden Verfahrensplan. Die auf einem R&I-Fließbild eingezeichneten leittechnischen Informationen stellen aus Sicht des Verfahrenstechnikers hingegen „nur“ Anforderungen an die Leittechnik dar. Die Verantwortung für deren Umsetzung liegt jedoch nicht beim Verfahrenstechniker, stattdessen erfolgt die Überführung in funktionierende Automatisierungstechnik durch Leittechniker. R&I-Fließbilder sind somit ein Paradebeispiel für Planungsdaten, die in der Verantwortung mehrerer Planungsgruppen liegen. Ein automatischer bidirektionaler Datenaustausch zwischen den Werkzeugen der Verfahrenstechnik und der Leittechnik würde zu einer Vermischung der Eigentumsverhältnisse und Verantwortlichkeiten führen. Wenn ein Leittechniker neue Sensorik oder Aktorik einführen möchte, dürfen diese Objekte dann automatisch aus der Leittechnikplanung in das R&I-Fließbild des Verfahrenstechnikers zurückfließen? Darf der Verfahrenstechniker seinerseits Manipulationen am Funktionsplan des Leittechnikers durchführen? Dies sind Herausforderungen an das Änderungsmanagement, die nicht durch einen simplen Knopfdruck gelöst werden können. Ein vollautomatischer bidirektionaler Datenabgleich kann folglich gefährliche Änderungen in abgestimmten Teil-Planungen mit weit reichenden Konsequenzen auf die gesamte Planung hervorrufen. Ein neuer Sensor beispielsweise erfordert nicht nur die Berücksichtigung des neuen Sensorsignals in der Leittechnik, sondern auch die Beurteilung des Verfahrenstechnikers bezüglich des Prozesses und des Einbauortes. Der Konstrukteur oder Anlagenbauer muss die Einbaugröße, Robustheit, Zugänglichkeit und Wartbarkeit sicherstellen, der Elektriker muss den neuen Sensor in der Spannungsversorgungs- und Kabelplanung berücksichtigen usw. Eine kleine Änderung im Plan kann folglich weitreichende Konsequenzen für alle Phasen der Anlagenplanung haben, weshalb der automatische Datenabgleich in einer heterogenen Werkzeuglandschaft mit großen Risiken verbunden ist. Neben diesen Workflow-Konsequenzen sind auch informationstechnische Probleme zu lösen. So kann bei der Überführung von Objektstrukturen von einem Werkzeug in ein anderes Informationsverlust auftreten, weil nur eine Teilmenge der Daten im Zielwerkzeug benötigt wird oder weil beim Import eine Anreicherung erfolgt. Werden Attribute, Strukturen, Verknüpfungen oder Hierarchien beim Datenimport reduziert, restrukturiert, angereichert oder auch nur teilweise verworfen, ist

290

R. Drath et al.

ein automatischer Rücktransport dieser Daten in das Ursprungswerkzeug erschwert oder gar nicht mehr möglich. Ein weiteres Problemfeld sind die in verschiedenen Werkzeugen geltenden unterschiedlichen Regelwerke zur Strukturierung von Daten. Dies umfasst beispielsweise Angaben über erlaubte Objektrelationen, Mengenbegrenzungen oder Namenskonventionen. Die unterschiedlichen Regeln können für einen vollautomatischen Datenaustausch schwierig werden. Beispielsweise akzeptieren einige Logikwerkzeuge nur gültige SFCs. Andere Werkzeuge und auch PLCopen XML als Teil von AutomationML lassen hingegen unvollständige SFCs zu, um das Editieren und frühe Visualisieren von Abläufen zu erleichtern. Werden aus letzteren Werkzeugen SFCs in die ersten Werkzeuge exportiert, so wird ein automatischer Datenabgleich häufig fehlschlagen.

6.9.3  Randbedingungen zur Einführung von AutomationML Je unterschiedlicher die Objektstrukturen der beteiligten Werkzeuge sind, desto schwieriger wird die automatische Herstellung von Datenkonsistenz, siehe Drath (2006). AutomationML als Datenformat kann nur die Einhaltung der zugrunde liegenden XML-Schemata prüfen, aber nicht eine semantische Sinnhaftigkeit der Daten. Zur Einführung eines Datenaustausches mit AutomationML sollten daher folgende Randbedingungen beachtet werden: • Die auszutauschenden Daten müssen konkret benannt und mit AutomationML modellierbar sein. • Die beteiligten Parteien sollten über die weitere Nutzung ihrer Daten informiert werden, damit die Datenerzeugung bereits darauf abgestimmt werden kann. Dies ist eine Konsequenz aus dem Wunsch, Daten über mehrere Phasen bis hin zur Inbetriebnahme weiter nutzen zu wollen und stellt höhere Anforderungen an die abgestimmte Strukturierung der Daten. • Objekthierarchien, Objektbibliotheken, Objekteigenschaften und Regelwerke der Objekte müssen miteinander abgestimmt und sowohl syntaktisch als auch semantisch bekannt sein. Dazu gehört die Einigung auf einen gemeinsam genutzten Satz von Rollen- und Schnittstellenbibliotheken. AutomationML liefert hierzu eine Reihe von Vorlagen. • Beim Import von Daten ist eine Prüfinstanz empfehlenswert, die die zu importierenden Daten und ihre Auswirkung im Gesamtplan beurteilen kann. Diese Prüfinstanz kann der Planer selbst sein oder mit Hilfe von Software erfolgen und fungiert als autorisierte Anforderungsschnittstelle zwischen den Werkzeugen. Die Eigentumsverhältnisse und Verantwortlichkeiten von Planungsdaten müssen dazu im Detail geklärt sein.

6  Praktische Anwendung

291

• Beim Import der Daten muss die korrekte Reihenfolge der zu importierenden Daten sowie die Einhaltung der im Zielwerkzeug geltenden Strukturierungsregeln sichergestellt werden. • Die Anwender müssen über geeignete Exporter und Importer verfügen, die die o.g. Rahmenbedingungen berücksichtigen. Idealerweise werden diese von den Werkzeugen selbst zur Verfügung gestellt, alternativ sind Drittprodukte sinnvoll. Diese Empfehlungen lassen sich in einfachen Szenarien teilweise sehr schnell erfüllen – so müssen beim Import von kinematisierten Geometrien aus der Teileplanung in die Zellenplanung keine komplex vernetzten Planungsdaten aus unterschiedlichen Planungsphasen oder überlappende Verantwortlichkeiten und Eigentumsverhältnisse berücksichtigt werden. In komplexen Szenarien sind vor dem Datenaustausch hingegen etliche Vorbereitungen zu treffen. Im Folgenden werden typische Anwendungsszenarien für AutomationML vorgestellt.

6.9.4  U  nidirektionaler Datenaustausch zwischen   zwei Werkzeugen Der einfachste Anwendungsfall für AutomationML ist die Nutzung als flüchtiges Austauschformat zwischen zwei Werkzeugen, die in der Wertschöpfungskette aneinandergrenzen. Dies können Werkzeuge benachbarter Engineering-Phasen sein, zwischen denen Daten ausgetauscht werden müssen, oder auch Werkzeuge voneinander entfernter Phasen, deren Daten nur bei gewissen Iterationen des Engineerings in Berührung kommen sollen. Dies ist ein workflowunabhängiges Grundelement des Datenaustausches in einer heterogenen Werkzeuglandschaft. Ergebnisse des einen Werkzeuges dienen hier als Eingangsinformationen des anderen Werkzeuges. Bei dieser Form der Nutzung wird die herkömmliche manuelle bzw. semi-automatische Datenübertragung ersetzt oder vereinfacht. Beispielsweise können Anlagenteile, deren Geometrie und Kinematik in der Teileplanung erstellt wurde, auf diese Weise in ein Linienlayoutwerkzeug übertragen und dort nach Freigabe durch eine Prüfinstanz unmittelbar weiterverwendet werden (siehe Abb. 6.67). Dafür steht heute kein anderes offenes Datenaustauschformat zur Verfügung. AutomationML hingegen leistet dies und kann somit für diesen Anwendungsfall unmittelbar Aufwände reduzieren und Fehler vermeiden. Ein anderes Beispiel für diesen Anwendungsfall ist die Übergabe von Gantt Charts mit der Beschreibung des Sollverhaltens einer Teilanlage an den Steuerungstechniker, der daraus Steuerungscode generiert (siehe Abschnitt 4.2.4). Diese strikt sequentielle Vorgehensweise ist der Schlüssel für eine einfache und schrittweise Einführbarkeit von AutomationML in beliebige Anlagenplanungsprozesse. Dazu müssen für die beteiligten Werkzeuge entsprechende Export- und Importwerkzeuge programmiert werden, die den bisherigen manuellen oder semiautomatischen Datenaustausch zwischen Nachbarwerkzeugen ersetzen. Dabei ist es heute üblich, dass die Übertragung der Daten durch eine menschliche Interak-

292

R. Drath et al. Prüfinstanz AutomationML

AutomationML

3D-Teileplanung

Liniensimulationswerkzeug

Topologie Geometrie

Abb. 6.67   Unidirektionaler Datenaustausch zwischen benachbarten Phasen des EngineeringWorkflows

tion angestoßen wird und einen ebenso flüchtigen Charakter wie die rein manuelle Datenübertragung besitzt. Dahinter steht der Wunsch nach menschlicher Autorisierung des Datenaustausches. Ein Dilemma in diesem Verfahren besteht jedoch darin, dass die Daten anschließend redundant in beiden Werkzeugen vorliegen. Die Gefahr besteht in der möglichen Divergenz der Daten, ihre Vermeidung erfordert besondere Vorkehrungen. Eine Vorkehrung könnte darin bestehen, dass geänderte Daten eine neue Versionsnummer erhalten und die Partner über diese Änderungen informiert werden. Im Gegensatz zur manuellen Datenübertragung lässt sich diese Divergenz allerdings mit Hilfe von Werkzeugen auf Basis von AutomationML automatisiert finden und beheben. Durch den von AutomationML vorgeschriebenen Objektidentifizierungsmechanismus lässt sich bei einem erneuten Export und Import der Daten feststellen, welche Daten gelöscht, hinzugefügt oder geändert wurden. Daraus lässt sich eine Differenzansicht berechnen und mit Hilfe der o.g. Prüfinstanz eine detaillierte Synchronisierung anstoßen. Dies ist mit den bisherigen manuellen oder semi-automatischen Methoden nicht oder nur mit erheblichem Aufwand möglich.

6.9.5  Bidirektionaler Datenaustausch zwischen zwei Werkzeugen Der bidirektionale Datenaustausch mit AutomationML kann erfolgen, indem ein zweiter – diesmal rückwärts gerichteter – unidirektionaler Datenaustausch eingeführt wird (siehe Abb. 6.68). Hierbei sind die in Abschnitt 6.9.4 getroffenen Feststellungen zu berücksichtigen. Es ist dabei zu beachten, dass im Zielwerkzeug nicht alle Daten des Quellwerkzeuges benötigt werden, insofern können beim Datentransport Informationsverdichtungen oder sogar -verluste stattfinden. Dies wird in Abb. 6.68 exemplarisch anhand der Kinematikdaten verdeutlicht, die im 3D-Teileplanungswerkzeug

6  Praktische Anwendung

$XWRPDWLRQ0/ 7RSRORJLH *HRPHWULH

293 3UILQVWDQ] $XWRPDWLRQ0/

.LQHPDWLN0RWLRQ '7HLOHSODQXQJ

/LQLHQVLPXODWLRQV ZHUN]HXJ

$XWRPDWLRQ0/ 3UILQVWDQ]

Abb. 6.68   Bidirektionaler Datenaustausch mit AutomationML

der Betriebsmittelkonstruktion nicht benötigt werden. Diese Informationen gehen beim wiederholten Transfer in das Simulationswerkzeug verloren, wenn kein Mechanismus für die Handhabung von nicht verwendeten Daten vorgesehen ist. Dies führt allerdings zu den klassischen Datensynchronisierungsproblemen. Eine typische Herausforderung der Datensynchronisierung ist die Auflösung von Widersprüchen, wenn dieselben Daten in beiden beteiligten Werkzeugen geändert wurden. Weiterhin können zirkulare Situationen eintreten, wenn eine Änderung im Quellwerkzeug nach Übertragung ins Zielwerkzeug dort eine weitere Änderung bewirkt, die beim Rücktransport ins Quellwerkzeug wiederum eine Änderung hervorruft usw. Beim bidirektionalen Austausch treten die in Drath (2006) beschriebenen Probleme mit hierarchischen Objektstrukturen besonders zum Vorschein. Ein Rücktransport von Daten ist nur erschwert oder gar nicht möglich, wenn sie beim Hintransport reduziert, zusammengefasst, restrukturiert oder verteilt wurden. Weiterhin muss die Identifikation des Ursprungs der Daten beim Rücktransport sichergestellt werden. Der bidirektionale Datenaustausch stellt somit höhere Anforderungen an die Klärung der Verantwortlichkeiten und Eigentümer von Engineering-Daten, die oben genannte Prüfinstanz gewinnt an Bedeutung und Ähnlichkeiten zwischen Objektstrukturen vereinfachen den Datenaustausch. In der Praxis ist es empfehlenswert, dass das Erzeugen und Löschen von Objekten nur im Eigentümerwerkzeug erfolgen darf. Der rückwärts gerichtete Datenfluss sollte dazu vorrangig im Sinne einer „Anforderungsmeldung“ verstanden werden, dies vermeidet die genannten Konflikte. Änderungen auf Parameterebene sind hingegen oft weniger problematisch und können dem Eigentümer nach Prüfung direkt zurück übermittelt werden.

294

R. Drath et al.

6.9.6  Sequentieller Workflow Der sequentielle Workflow ergibt sich durch eine Aneinanderreihung von paarweisen Datenaustausch-Schritten (siehe Abb. 6.69). Die Herausforderung hierbei ist, dass Teile der Planungsdaten die gesamte Planungskette durchlaufen können und somit mehrfach in unterschiedlichen Werkzeugen repräsentiert sind. Ändert sich ein solches Datum zum Beispiel im letzten Glied einer Planungskette, müsste das Datum selbst oder zumindest die Anforderung danach gegebenenfalls durch die gesamte Kette zurück bis zum Urheber bzw. Verantwortlichen übertragen werden. Zieht bei vollautomatischem Rückfluss der Daten das Regelwerk der einzelnen Werkzeuge automatisch weitere Änderungen nach sich, muss dieser Vorgang gegebenenfalls mehrfach wiederholt werden. Die Synchronisierung von Daten in der gesamten Werkzeugkette kann folglich eine unerwünschte Vielzahl von Datenaustauschprozessen erforderlich machen. Dies wird umso mehr erschwert, wenn Strukturierungsrichtlinien der beteiligten Werkzeuge oder Eigentumsverhältnisse verletzt werden. Dies unterstreicht die oben genannte Empfehlung, rückwärts gerichtete Datenflüsse vorrangig als „Anforderungsmeldung“ vorzusehen. Weiterhin ist empfehlenswert, rückwärts gerichtete Datenflüsse nicht unbedingt von Glied zu Glied der Engineering-Kette zurückzugeben, sondern Änderungsanforderungen direkt an den Eigentümer zu senden, auch wenn dabei EngineeringSchritte übersprungen werden. Die Engineering-Kette muss dann vom Eigentümer mit dem Ziel der Gesamtkonsolidierung aufgerollt werden. Es kann weiterhin sinnvoll sein, konkrete Planungsdaten beispielsweise aus der Inbetriebnahme an einen weiter vorne liegenden Planungsschritt zu übertragen, zum Beispiel der Angebotserstellung. Diese kann darauf aufbauend für künftige Projekte bessere Angebote

Prüfinstanz

Prüfinstanz

AutomationML

AutomationML

AutomationML

3D3D-Teileplanung

Topologie Geometrie Kinematik/Motion

Liniensimulations werkzeug

VerhaltensplanungsVerhaltensplanungswerkzeug

AutomationML

AutomationML

Prüfinstanz

Prüfinstanz

PLCOpen XML

Abb. 6.69   Sequentieller Workflow mit AutomationML

6  Praktische Anwendung

295

erstellen, die dann direkt in den anschließenden Engineering-Prozess eingelastet werden. Es ist daher empfehlenswert, den von AutomationML vorgeschriebenen Identifikationsmechanismus von Objekten sorgfältig auszuführen, um die passenden Objekte zu finden und den Datentransfer korrekt zu vollziehen. Es ist weiterhin empfehlenswert, dass das Erzeugen und Löschen von Objekten nur in einem einzigen Eigentümerwerkzeug erfolgen darf.

6.9.7  Paralleler Workflow Eine wesentliche Quelle von Effizienz ist die Parallelisierung von Arbeitsschritten. Der Aufwand wird durch Parallelisierung von Arbeit zwar nicht verringert, sondern durch zusätzlich notwendige Abstimmungen eher erhöht, aber die Gesamtdurchlaufzeit kann erheblich verkürzt werden. Paralleles Arbeiten in Multi-Nutzer-Umgebungen gelingt, wenn beispielsweise eine gemeinsame zentrale Datenbank mit einer aufeinander abgestimmten Tool-Suite verwendet wird, welche die Konsistenz der Planungsdaten sicherstellt und in Benutzung befindliche Daten vor dem Zugriff weiterer Personen schützt. In einer heterogenen Werkzeuglandschaft ohne derartige zentrale Instanz ist dies aber nicht gegeben. Bei einem parallelen Workflow ohne zentrale Datenbank fehlt die fortwährende Konsolidierung der Daten. AutomationML selbst bietet als Datenformat keine Konsolidierungsfunktionalität. Sobald mehrere Parallelzweige von einem gemeinsamen Ausgangsdatenbestand starten, ändern sich die entkoppelten Planungsdaten unabhängig voneinander. In diesem Fall werden in regelmäßigen Abständen Konso­ lidierungsschritte empfohlen (siehe Abb. 6.70), die die Rolle der Prüfinstanz übernehmen. Ein Beispiel: zu Beginn einer Parallelverzweigung des Workflows steht ein Anlagentopologieentwurf mit zusätzlichen geometrischen Informationen zur Verfü-

Abb. 6.70   Paralleler Workflow mit AutomationML

296

R. Drath et al.

gung. Auf diesen aufbauend wird nun die Planung der Steuerungstechnik gestartet, parallel dazu wird die Robotersimulation vorgenommen. Beide Planungsschritte entwickeln die Anlagentopologie und Geometrie weiter. Die Steuerungsplaner reichern die Anlagenstruktur um eine Hardwarestruktur an, wählen dazu I/O-Geräte aus, konfigurieren Signale und programmieren die logischen Verknüpfungen von Signalen und Funktionsbausteinen. Der Robotersimulationsexperte entwickelt das Roboterprogramm, reichert die Anlagenstruktur um Werkzeuge und Flansche an, programmiert und testet Bewegungsabläufe, definiert und korrigiert Bahnverläufe und erstellt das Roboterprogamm. Aus beiden Tätigkeiten ergeben sich Ergänzungen zum ursprünglichen Anlagen-Objektmodell. Im Konsolidierungsschritt müssen die Änderungen der Ausgangsdaten für jede Phase miteinander verglichen werden. Unabhängige Änderungen auf beiden Seiten lassen sich zusammenfügen. Abhängige Änderungen hingegen müssen im Team geklärt werden – dies ist ein kreativer Akt und lässt sich nur schwer automatisieren. Mit Hilfe von AutomationML lassen sich solche Datenkonflikte ermitteln, allerdings kann AutomationML die autorisierte Konsolidierung dieser Daten nicht leisten; dies muss durch eine Prüfinstanz erfolgen. Am Ende der Konsolidierungsschritte entsteht ein in den parallelen Phasen angereicherter konsistenter Planungsstand, der als Ausgangspunkt der weiteren Planung verwendet werden kann. Diese stellen neue Serialisierungspunkte im Projekt dar. Wird ein gemischt parallel-bidirektionaler Datenaustausch gewünscht, dann ist es empfehlenswert, diesen vorrangig zwischen diesen Serialisierungspunkten durchzuführen (siehe Abschnitt 6.9.5).

6.9.8  AutomationML als zentrale Planungsdatenbasis? Die Idee ist verlockend, AutomationML als neutrale Datenbasis für alle EngineeringDaten zu verwenden. Sie würde von Werkzeug zu Werkzeug wandern und schrittweise angereichert, bis die vollständige Planung vorliegt. Jedes Werkzeug würde nur auf die ihm zugehörigen Daten zugreifen und Anreicherungen vornehmen. In der Realität ist dies jedoch mit AutomationML allein nicht praktikabel. Hauptgrund hierfür ist die Tatsache, dass Planungsdaten miteinander vernetzt sind und die Vernetzungen sich außerhalb des Fokusses eines Werkzeuges fortsetzen können. Ändert ein Werkzeug seine Daten, kann dies Änderungen in anderen Teilen der Planungsdatenbasis erfordern oder bewirken, von denen das Werkzeug keine Kenntnis besitzt. Das Beispiel des eingeführten zusätzlichen Sensors aus Abschnitt 6.9.2 zeigt, welch weitreichende Auswirkungen die Änderung von Planungsdaten haben kann. Hierfür wäre ein Koordinierungswerkzeug erforderlich, dessen Funktionalität AutomationML allein nicht bieten kann. Ein weiteres Hindernis für die Anwendung von AutomationML als zentrale Planungsdatenbasis besteht darin, dass AutomationML selbst keinerlei Datenbankfunktionalität bietet. Zugriffsrechte, Zugriffsschutz etc. sind keine XMLFunktionen.

6  Praktische Anwendung

Tool A

AutomationML

297

Tool B

AutomationML

Tool C

AutomationML

Tool D

AutomationML

Engineering-Master-Tool AutomationML

AutomationML

Abb. 6.71   AutomationML als zentrale Datenbasis

Wird die Nutzung von AutomationML als zentrale Datenbasis gewünscht, ist die Überführung der zugehörigen XML-Schemata in eine Datenbankstruktur empfehlenswert. Diese erlaubt die Festlegung von Dateneigentümern, Zugriffsrechten, den Schutz von in Bearbeitung befindlichen Daten sowie die Verschlüsselung von sensiblen Daten. Der Austausch solcher Datenbanken könnte leicht mit AutomationML erfolgen. Alternativ zur Datenbank würde eine zentrale Konsolidierungs-Software benötigt, die die genannten Funktionen zum koordinierten Zugriff auf AutomationML bietet. Weiterhin wird eine Benachrichtigungsfunktionalität benötigt, die vorgenommene Änderungen in der teilnehmenden Werkzeuglandschaft bekannt gibt und die zugehörigen Werkzeuge auffordert, die Änderung der Planungsdaten zu akzeptieren und mit den eigenen Daten zu konsolidieren. Eine solche Architektur wird in Abb. 6.71 dargestellt. Hier werden vier Werkzeuge dargestellt, die verschiedene Aspekte der Anlagenplanung übernehmen. Der Austausch von Daten für die jeweiligen Teile erfolgt nicht direkt über eine zentrale AutomationML-Datenbasis, sondern über ein zentrales Konsolidierungs- und Prüfwerkzeug.

6.9.9  Zwischenfazit Die vorangegangenen Szenarien verdeutlichen, dass eine unüberlegte Einführung und ein falsches Verständnis von AutomationML zu einem hohen und teuren Aufwand führen kann. Daher wird für die erste Einführung empfohlen, AutomationML zunächst als ein flüchtiges Medium für den unidirektionalen Datenaustausch zu verwenden. AutomationML wird dadurch nicht zu einem „weiteren Datenformat“

298

R. Drath et al.

degradiert, da kein offenes Datenformat existiert, das die Vielzahl der Aspekte von AutomationML abdeckt. Alle weiteren Szenarien lassen sich anschließend schrittweise darauf aufbauen, da AutomationML alle notwendigen Kriterien dafür erfüllt. Der Einsatz als direktes und dynamisches Zugriffsmedium für die gesamte Planung sollte nur über eine vermittelnde Zwischensoftware erfolgen.

6.9.10  Empfehlungen zum Umgang mit Rollenbibliotheken Rollen sind ein geeignetes Mittel, um bereits in frühen Phasen des Workflows mit abstrakten „Platzhalterobjekten“ zu planen, ohne bereits zu diesem Zeitpunkt genaue Kenntnis über die später eingesetzten, konkreten Objekte zu besitzen. Ihre Verwendung ist von AutomationML vorgeschrieben – jede Instanz eines AutomationML-Objektes muss eine Referenz zu einer AutomationML-Rolle besitzen. Im einfachsten Falle ist dies eine Referenz zur Basisrolle AutomationMLBaseRole (siehe Abschnitt 2.7.2). Die assoziierte Rollenklasse soll Auskunft darüber geben, welche Funktion ein Objekt besitzt. Auch mehrere Rollen können zugeordnet werden. Eine assoziierte Rolle bietet somit eine semantische Erklärung, welche Bedeutung ein Objekt besitzt. Je detaillierter die verwendeten Rollenklassen sind, desto genauer können die teilnehmenden Werkzeuge die Objekte interpretieren. Auf diese Weise können generische Algorithmen beliebige CAEX-Objektstrukturen untersuchen und beispielsweise die Anzahl aller Rohre oder Roboter ermitteln. Selbst Objekte von Herstellern, die der Algorithmus nicht kennt, werden von ihm erkannt, weil sie eine Zuordnung zu einer Rolle wie z. B. „Roboter“ oder einer ihrer Ableitungen besitzen. Das Rollenkonzept macht Planungsdaten automatisch „erkundbar“ – eine wesentliche Voraussetzung für die maschinelle Interpretation von Daten. Dies eröffnet neue Möglichkeiten und Funktionen zur automatischen Einordnung und Konsistenzprüfung von Daten sowie vielfältige Automatisierung von Planungsschritten. Das funktioniert natürlich nur, wenn alle teilnehmenden Werkzeuge dieselben Rollen kennen und verwenden. Dies kann nicht a priori vorausgesetzt werden, sondern erfordert aufgrund der Fülle verfügbarer Bibliotheken zu Beginn des Datenaustausches eine Festlegung für das Projektteam. Die von AutomationML gelieferten Standardbibliotheken sind ein guter Ausgangspunkt und werden in Zukunft eine Reihe von Erweiterungen erfahren. Allerdings ist die Vielzahl verschiedener Industrien und benötigter Funktionen sehr divers. Deshalb wird empfohlen, dass sich alle beteiligten Projektpartner zu Beginn der Planung auf einen gemeinsamen Satz von Rollenklassen einigen. Dies können herstellerspezifische Bibliotheken oder Standards oder aber von Standardisierungsgremien für spezifische Industrien und Themenbereiche zur Verfügung gestellte Bibliotheken sein. Auch die Eigenentwicklung von Rollenbibliotheken kann sinnvoll sein. Zur Sicherstellung der konsistenten Nutzung der Rollenbibliotheken zwischen den beteiligten Projektpartnern und zur gleichzeitigen Reduktion des Datenaustausch-Volumens wird empfohlen, diese Bibliotheken aus den AutomationML-

6  Praktische Anwendung

299

Dokumenten zu entfernen und stattdessen an einer für alle Beteiligte zugänglichen Stelle verfügbar zu machen, beispielsweise in einem gemeinsamen Netzwerk oder auf einem FTP-Server. Änderungen oder Ergänzungen an Rollen-Bibliotheken im laufenden Projekt sollten weitgehend vermieden oder zumindest allen Projektpartnern rechtzeitig mitgeteilt werden. Die Disziplin beim Umgang mit den Rollenbibliotheken zahlt sich im iterativen Engineering aus. Dies bedeutet jedoch nicht, dass Rollenbibliotheken starre Gebilde sind, sie werden sich im Laufe der Zeit weiterentwickeln und reifen. Allerdings sollte die Parallelentwicklung von Bibliotheken bzw. Klassen mit gleicher Bedeutung vermieden werden. Stößt ein Werkzeug auf eine ihm unbekannte Rolle, so endet hier die Erkundbarkeit der Daten. Allerdings schreibt AutomationML zwingend vor, dass jede Rollenklasse direkt oder indirekt von der AutomationMLBaseRole abgeleitet ist, auch um eine durchgängige Vererbungsbeziehung zu erzwingen. Tritt eine neue Rolle auf, so kommt als nächstliegender Verwandter dessen Elternklasse in Betracht. Dieser Vorgang wird solange wiederholt, bis eine bekannte Rolle erscheint. Ist der Klassenbaum nicht vollständig rekonstruierbar, ist dies als Fehler zu betrachten – der zugehörige Klassenbaum muss dann beschafft werden.

6.9.11  E  mpfehlungen zum Umgang mit SystemUnit-Bibliotheken SystemUnit-Bibliotheken verkörpern nutzerdefinierte, herstellerspezifische und konkrete Anlagenkomponenten oder vordefinierte Anlagenstrukturen. Bibliotheken sind bekanntlich der Schlüssel zur effizienten Wiederverwendung von Planungsdaten. Der Datenaustausch in einer heterogeneren Werkzeuglandschaft kann jedoch unterschiedlich komplexe Szenarien im Umgang mit Systembibliotheken erfordern. Anwendungsfall 1: Ein grundlegender Anwendungsfall im Umgang mit Bibliotheken ist die erstmalige Erzeugung eines Bibliothekelementes. Dies kann innerhalb eines Werkzeuges oder durch Import von Daten aus einem Quellwerkzeug erfolgen. Dies wird in Abb. 6.72 erläutert. Die Geometrie eines Objektes soll von einem 3D-Werkzeug in ein Liniensimulationswerkzeug übertragen werden, beispielsweise das 3D-Modell eines Greifers. Diese Daten werden nach AutomationML konvertiert (1) und in das Liniensimulationswerkzeug importiert (2). Hier wird die Geometrie an eine Bibliotheksklasse als Referenz angefügt (3) und steht nun als wieder verwendbares Element zur Verfügung. Im Zielwerkzeug kann die Klasse im Projekt beliebig häufig instanziiert werden (4). In der Praxis unterliegen Planungsdaten jedoch Änderungen: Bibliothekselemente werden im Zielwerkzeug z. B. um Signale, Schnittstellen und Dokumentationen angereichert, im Quellwerkzeug werden die Planungsdaten jedoch eventuell korrigiert. Wird die Geometrie im ersten Werkzeug aktualisiert, muss das Bibliothekselement aus dem Zielwerkzeug ebenfalls aktualisiert werden. Mit Hilfe des Identifikationskonzeptes können zusammengehörige Daten zugeordnet werden.

300

R. Drath et al.

/LQLHQ 6LPXODWLRQV 7RRO

'7RRO 

%LEOLRWKHN

' =HLFKQXQJ

3URMHNW ,QVWDQ]

.ODVVH



'



$XWRPDWLRQ0/



Abb. 6.72   Austausch von Bibliotheken – Anwendungsfall 1

Die Änderungen auf beiden Seiten müssen durch die o.g. Prüfinstanz übernommen, korrigiert oder ggf. verworfen werden. Dies ist Grundlage eines iterativen Engineering. Beim ersten Datenaustausch stellt die Identifikationsmethodik zwar einen Mehraufwand dar, sie lohnt sich jedoch für alle wiederholten Datenaustauschvorgänge im iterativen Engineering. Anwendungsfall 2: Ein weiteres Grundelement im Umgang mit Bibliotheken besteht darin, dass existente Bibliotheken und daraus abgeleitete Projektdaten eines Quellwerkzeuges in ein Zielwerkzeug übertragen werden sollen, in denen noch keine Klassen oder Instanzen verfügbar sind. Dies ist ein Standardfall beim Datenaustausch zwischen objektorientierten Planungswerkzeugen und wird in Abb. 6.73 illustriert. In der Praxis kommt dies vor, wenn beispielsweise eine Zellenplanung von einem Liniensimulationswerkzeug in ein anderes übertragen werden soll. Dazu werden die Bibliothek und das Objektmodell des Projektes im ersten Liniensimulationstool (1) nach AutomationML konvertiert und in das Zielwerkzeug importiert. Beim ersten Import dieser Daten in das Zielwerkzeug müssen zunächst die Bibliothekselemente in die Bibliothek des Zielwerkzeuges übertragen werden (2). Hier können diese modifiziert oder angereichert werden. Anschließend ist die Instanziierung dieser neuen Klassen durchzuführen. Im dritten Schritt müssen instanzspezifische Informationen aus der ersten Liniensimulation (1) in die neuen Instanzen des zweiten Liniensimulationstools (3) übertragen werden. Im Zielwerkzeug können nun weitere Planungsschritte erfolgen, was hier durch die Bildung einer neuen Instanz Instanz2 dargestellt ist. Werden Bibliothekselemente oder Instanzdaten im Quellwerkzeug verändert, können diese durch einen aufwändigen Vergleich der im Zielwerkzeug vorhandenen Daten ermittelt werden. Eine Prüfinstanz führt anschließend den Import dieser Änderungen durch. Die Identifizierung zusammengehöriger Daten ist über AutomationML sicher zu stellen. In der Praxis ist es empfehlenswert, dass Änderungen im Quellwerkzeug zu einer neuen Version dieser Daten führen, die dann als neue Version im Zielwerkzeug

6  Praktische Anwendung

301

LinienSimulationsTool 1

3D Tool

3D Zeichnung

Bibliothek

Projekt Instanz

Klasse

1

AutomationML Linien SimulationsTool 2 Bibliothek Klasse

Projekt

2

3

Instanz1 Instanz2

Abb. 6.73   Austausch von Bibliotheken – Anwendungsfall 2

importiert wird. Dies ist eine zentrale Empfehlung für die Einführung eines durchgängigen Datenaustausches und vereinfacht das Änderungsmanagement. Anwendungsfall 3: Ein weiteres Grundelement im Umgang mit Bibliotheken besteht darin, dass Bibliotheken eines Quellwerkzeuges auf Bibliotheken im Zielwerkzeug stoßen. Dieser Fall wird in Abb. 6.74 dargestellt. Die Bibliothekselemente (1) des zweiten Liniensimulationswerkzeuges sollen in ein Roboterprogrammierwerkzeug übertragen werden. Dies könnte beispielsweise ein Roboter sein, der in der Bibliothek des Zielwerkzeugs als spezialisierte Klasse bereits vorliegt. Gerade herstellerspezifische Roboterprogrammierwerkzeuge verfügen häufig über genauere Modelle als Liniensimulationswerkzeuge, so dass der reine Import der Bibliothekselemente aus einem Liniensimulationswerkzeug nicht erwünscht wäre. Doch welcher Klasse im Roboterprogrammiertool (2) soll die Klasse (1) der Liniensimulation zugeordnet werden? Würden die Klassen im Robotersimulationstool (2) noch nicht existieren, könnten sie aus dem zweiten Liniensimulationstool (1) importiert und so neu erzeugt werden und wären über das Identifikationssystem zuordenbar. Dies entspricht Anwendungsfall 2. Sind die Klassen (2) jedoch bereits vorhanden, lässt sich eine passende Zuordnung zwischen den zugehörigen Klassen ohne vorherige Abstimmung nur aus AutomationML heraus nicht direkt ableiten. In diesem Falle bedarf es einer Zuordnung dieser Klassen durch eine Prüfinstanz. Dieser Entscheidungsprozess lässt sich mit AutomationML erheblich vereinfachen oder sogar automatisieren, wenn die Planungsdaten hinreichend „automatisch erkundbar“ sind. Hier kommt das Rollenkonzept zum Tragen.

302

R. Drath et al.

/LQLHQ 6LPXODWLRQV 7RRO

'7RRO

%LEOLRWKHN

' =HLFKQXQJ

3URMHNW ,QVWDQ]

.ODVVH

$XWRPDWLRQ0/ 5RERWHU 3URJUDPPLHU 7RRO %LEOLRWKHN 5RERWHU



/LQLHQ 6LPXODWLRQV 7RRO

"

%LEOLRWKHN

)|UGHUE

.ODVVH

*UHLIHU

3URMHNW



,QVWDQ] ,QVWDQ]

Abb. 6.74   Austausch von Bibliotheken – Anwendungsfall 3

Sind alle betrachteten Klassen genügend detaillierten AutomationML-Rollen zugeordnet, lassen sich passende Zuordnungen automatisch finden oder zumindest erheblich eingrenzen, so dass das manuelle Mapping erleichtert wird. Um das Mapping zu vermeiden, ist in der Praxis empfehlenswert, dass die verwendeten Klassen zwischen den Projektpartnern vorab abgestimmt wurden.

6.9.12  Zusammenfassung der Empfehlungen Im Folgenden werden die in den vorangegangenen Abschnitten dargelegten Anforderungen und Empfehlungen zur Einführung und im Umgang mit AutomationML zusammengefasst: • Der Datenaustausch zwischen komplexen Planungswerkzeugen sollte schrittweise und bedacht eingeführt werden. • Bei der ersten Einführung wird AutomationML als flüchtiges Datenaustauschmedium im Sinne des klassischen dateibasierten semi-automatischen Datenaustausches empfohlen.

6  Praktische Anwendung

303

• Die von AutomationML verfolgten Objektidentifizierungsmechanismen sollten vor einem Datenaustausch zur automatischen Ermittlung von Änderungen zwischen Ziel- und Quellwerkzeugen verwendet werden. • Wenn Werkzeuge nicht selbst über ausreichende Export- und Importschnittstellen verfügen, kann ein drittes, unabhängiges Tool für den Datentransport diese Rolle übernehmen. Ein solches Werkzeug kann während des Datenaustausches zudem unterschiedliche Datenstrukturen der beiden Werkzeuge mit sogenannten Conditionern korrigieren, wie für das Graphic CPF und Logic CPF in den Abschnitt 6.3 und 6.4 erläutert wird. • Die auszutauschenden Daten müssen konkret bekannt und mit AutomationML modellierbar sein. • Die beteiligten Parteien sollten über die weitere Nutzung ihrer Daten informiert werden, damit die Datenerzeugung bereits darauf abgestimmt werden kann. Dies ist eine Konsequenz aus dem Wunsch, Daten über mehrere Phasen bis hin zur Inbetriebnahme weiter nutzen zu wollen, und stellt höhere Anforderungen an die abgestimmte Strukturierung der Daten. • Beim Import von Daten ist eine Prüfinstanz vorzusehen, die zu importierende Daten und ihre Auswirkung im Gesamtplan beurteilen kann. Diese Prüfinstanz kann der Planer selbst sein oder mit Hilfe von Software erfolgen und fungiert als autorisierte Anforderungsschnittstelle zwischen den Werkzeugen. • Vollautomatischer Datenaustausch ist aufgrund der erläuterten Risiken nur unter Nutzung geeigneter automatischer Prüfinstanzen empfehlenswert. Dies ist beim ersten unidirektionalen Import am einfachsten zu erreichen, später erhöhen sich die Risiken durch die dann notwendige Konsolidierung der Daten. • Die Eigentumsverhältnisse und Verantwortlichkeiten von Planungsdaten müssen im Detail geklärt sein. • Die Objektidentifizierungskonzepte von AutomationML sollten insbesondere bei iterativem Engineering sorgfältig befolgt werden. Sie können bei Integration modifizierter Daten gut verwendet werden, um Unterschiede zwischen den unterschiedlichen Datenbeständen leicht zu ermitteln und zu visualisieren. • Die Notwendigkeit von Bidirektionalität sollte kritisch hinterfragt und auf tatsächlich benötigte Daten beschränkt werden. Gerade bei Bidirektionalität müssen klare Eigentumsverhältnisse und Verantwortlichkeiten sorgfältig berücksichtigt werden. • Es ist empfehlenswert, den Rückfluss von Daten vorrangig als „Änderungsmeldung an den Verantwortlichen“ zu realisieren. Dies vermeidet Datenkonflikte und reduziert den erforderlichen Konsolidierungsaufwand. • Das Erzeugen und Löschen von Objekten sollte nur im Eigentümerwerkzeug erfolgen.

304

R. Drath et al.

• Bei parallelen Workflows wird zur Vermeidung von widersprüchlichen Divergenzen in den Planungsdaten die Einführung regelmäßiger Konsolidierungsschritte empfohlen, in denen die beteiligten Projektpartner ihre Änderungen zusammenführen. • Bei parallelen Workflows sollte der phasenübergreifende bidirektionale Datenaustausch nur zwischen konsolidierten Datenbeständen durchgeführt werden. • Objekthierarchien, Objektbibliotheken, Objekteigenschaften und Strukturierungsrichtlinien der beteiligten Werkzeuge für die Objekte sollten miteinander abgestimmt und sowohl syntaktisch als auch semantisch bekannt sein. Dazu gehört die Einigung auf einen gemeinsam genutzten Satz von Rollen- und Schnittstellenbibliotheken. AutomationML liefert hierzu eine Reihe von Vorlagen. • Bibliotheken gemeinsam verwendeter Anlagenkomponenten sollten von ihren Herstellern zur Verfügung gestellt und gemeinsam genutzt werden. • Gemeinsam verwendete Bibliotheken sollten zentral an einer allen Projektpartnern zugänglichen Stelle zur Verfügung gestellt werden. Dies stellt sicher, dass ein gemeinsamer Satz von Rollenklassen verwendet wird, und es reduziert nebenbei das Datenvolumen. • Rollenbibliotheken sollten im laufenden Projekt möglichst wenig verändert werden. Änderungen sind allen Projektpartnern explizit mitzuteilen. • AutomationML bietet als Austauschformat keine Datenbankfunktionalitäten und ist als zentrale Datenbasis allein nicht geeignet. Falls dies angestrebt wird, ist entweder die Einführung einer AutomationML-Datenbank oder die Entwicklung einer gemeinsamen Zugriffs-Schnittstelle zu AutomationML empfehlenswert, die alle benötigten Funktionen bereitstellt. • Beim Import der Daten muss die korrekte Reihenfolge der zu importierenden Daten sowie die Einhaltung der im Zielwerkzeug geltenden Geschäfts-Logik sichergestellt werden. • In der Praxis ist es empfehlenswert, dass Änderungen im Quellwerkzeug zu einer neuen Version dieser Daten führen, die dann als neue Version im Zielwerkzeug importiert wird. Dies ist eine zentrale Empfehlung für die durchgängige Nutzung eines durchgängigen Datenaustausches. • Die Anwender müssen über geeignete Exporter und Importer verfügen, die die o.g. Rahmenbedingungen berücksichtigen.

Literatur AutomationML (2009) http://www.automationml.org. Breithor S, Weidemann D (2009) AutomationML Logic Editor User Guideline, Version 1.0, angekündigt für 2009, www.automationml.org.

6  Praktische Anwendung

305

Drath R (2006) Bäumchen wechsle Dich – Tücken beim automatischen Abgleich hierarchischer Objektstrukturen. In: Softwaretechnik – Trends, Band 26, Heft 4, S. 14–19, ISSN 0720-8928, Fachausschuss Softwaretechnik und Programmiersprachen des FB Softwaretechnik der GI, Siegen. NetAllied (2009) http://www.netallied.de. OPCFoundation (2009) OPC http://www.opcfoundation.org. Accessed 28 January 2009. Pirsch M, Weidemann D (2008a) AutomationML Editor User Guideline, Version 1.0, April 2008, www.automationml.org. Pirsch M, Weidemann D (2008b) AutomationML Engine Developer Guideline, Version 1.0, April 2008, www.automationml.org.

Kapitel 7

Bewertung und Ausblick Dirk Weidemann und Rainer Drath

7.1  Bewertung von AutomationML durch INPRO Bei einem neuen Austauschformat ist der Praxisnachweis durch eine Feldbewährung besonders wichtig. Dazu gehört die Anwendung und Produktentwicklung durch Mitglieder der Standardisierungsorganisation, deren Erfahrungen unmittelbar wieder in das Format einfließen (siehe Abschnitt 1.7). Darüber hinaus ist jedoch eine unabhängige Evaluation durch eine neutrale Partei wertvoll, die unbefangen prüft und konzeptionelle Schwächen schonungslos aufzeigt. Wenn sich die Tester nicht schnell in der neuen Technologie zurechtfinden und wesentliche Anwendungsfälle nicht damit lösen können, wird diese Unzufriedenheit schnell dokumentiert. Eine besondere Bedeutung für die AutomationML-Gruppe hat deshalb die Bewertung von AutomationML in der praktischen Anwendung durch INPRO, eine Innovationsgesellschaft für die Automobilproduktion, deren Gesellschafter BASF, ThyssenKrupp, Siemens, Daimler, Volkswagen sowie das Land Berlin einen breiten Domänenbereich vertreten. Dazu wurde AutomationML für verschiedene Anwendungsszenarien untersucht (Prinz et al. 2009). Ziel dieser Evaluierung war die Übertragung eines modularen Modellierungskonzepts aus hierarchischen Bausteinen und Modulen für Standardkomponenten durchgängig auf alle Planungsphasen (siehe Abb. 7.1). Die Bausteine sollten den Datenaustausch zwischen den beteiligten Systemen, Fachbereichen und Unternehmen flexibel unterstützen. Darüber hinaus mussten Regeln für die Struktur, Auswahl und Konfiguration der Bausteine spezifiziert werden. Grundlegende Probleme waren die Zusammenführung von Daten aus verschiedenen Systemen sowie die Modellierung von Referenz-Datenstrukturen. Als Grundlage wird ein Datenmodell mit den drei Haupt-Objektklassen PRODUKT, PROZESS und RESSOURCE verwendet, wie sie aus den etablierten Systemen Tecnomatix ProcessDesigner® (ehemals eM-Planner®) bzw. DELMIA Process Engineer® bekannt sind und auch von AutomationML unterstützt werden, vgl. Abschnitt 2.9.6. D. Weidemann () Zühlke Engineering GmbH, Expo Plaza 3, 30539 Hannover, Deutschland e-mail: [email protected] R. Drath (Hrsg.), Datenaustausch in der Anlagenplanung mit AutomationML, DOI 10.1007/978-3-642-04674-2_7, © Springer-Verlag Berlin Heidelberg 2010

307

308

D. Weidemann und R. Drath

Abb. 7.1   Systemübergreifender Datenaustausch mit AutomationML und INPRO Rollenbibliothek

Spezifische Baustein-Klassen werden davon abgeleitet und miteinander verknüpft. Als Ansatz für einen durchgängigen modularen Anlagenprozess werden die Einzelkomponenten durch ein semantisches Netz bzw. eine Ontologie verbunden und eindeutig klassifiziert. Dafür wurde AutomationML verwendet. Zunächst stellte INPRO in einer Ist-Aufnahme für die Karosseriebauplanung die grundsätzliche Eignung von AutomationML für die Modellierung von herstellerunabhängigen Objektbibliotheken fest. Fehlende Aspekte wurden durch Hinzufügen von speziellen AutomationML-Klassenbibliotheken ergänzt – diese Möglichkeit wurde als sehr guter Weg eingeschätzt. Auf diesem Ansatz wurden mehrere Anwendungsszenarien definiert. Das Basisszenario sieht den möglichst verlustfreien Informationsaustausch in drei Schichten von der Systemebene über das neutrale CAEX bis hin zur Ontologie durch Rollenbibliotheken vor. Die verfügbaren AutomationML-BasisRollenbibliotheken wurden hierbei durch spezielle Erweiterungen von INPRO für die Rohbauplanung ergänzt. Über diese Rollenklasse können Objekte später leicht und automatisiert identifiziert werden. Im zweiten Szenario wird die Lieferantenintegration unterstützt. Dies ist ebenfalls ein Datenaustauschszenario, allerdings ergänzt um die Möglichkeit, bestimmte Attribute und Attributgruppen gezielt vom Austausch auszuschließen. Dafür erweitert INPRO die Ontologie um eine Attributbibliothek gemäß den Merkmalslisten der PROList®, siehe Ahrens et al. (2005). Diese wurden für die Prozesstechnik entworfen und von INPRO um Klassen für die Anlagenplanung ergänzt. Im dritten Szenario wird die Integration zwischen Planungsphasen untersucht. Die Problematik ist hier die fortschreitende Detaillierung der Daten. Dies wurde von INPRO gelöst, indem unterschiedlich granulare Klassen zur Beschreibung einer Komponente derselben AutomationML-Rolle zugeordnet werden und damit leichter abgeglichen werden können.

7  Bewertung und Ausblick

309

Im letzten Anwendungsszenario wird die Rekonfiguration von Anlagenmodellen durch die Austauschbarkeit von Modulen ermöglicht. Dazu werden klassifizierende Merkmale der Produktionsanlage sowie auftragsbezogene oder produktbezogene Merkmale herangezogen und als weitere AutomationML-Klassenbibliothek in die Ontologie integriert. Alle Aufgaben konnten mit den Modellierungs- und insbesondere Erweiterungsmitteln von AutomationML gelöst werden. Als sehr wichtige Erweiterung wurden eigene Rollenbibliotheken analog zu PROList® entwickelt und eingesetzt, die die sprachlichen Möglichkeiten von AutomationML durch die Ontologie mit Semantik vervollständigt. Das Problem umfangreicher Betriebsmittelkataloge und der daraus resultierenden zeitaufwändigen Suche und Auswahl der richtigen Komponente konnte durch Eingabe geeigneter Merkmale sowie von Beziehungen zwischen Merkmalen vereinfacht werden. Auch die Standardisierung von SystemUnit-Klassenbibliotheken wird als möglichen Weg durch INPRO untersucht – so wird derzeit geprüft, ob man komplexere Objektstrukturen aus einem Quellsystem auf eine Standardstruktur abbilden kann, um den Transformationsaufwand weiter reduzieren zu können. Das AutomationMLModell besteht daher derzeit aus folgenden Komponenten: • AutomationML-Rollenbibliothek (Basis), • INPRO-Rollenbibliothek (enthält Hauptgruppen und Gruppenstruktur der Merkmalsleisten aufbauend auf PROList bzw. künftig EClass, aber nicht die Attribute), • INPRO-SystemUnitClassLib (Standard-Merkmalsleisten aufbauend auf den PROList/EClass-Merkmalsleisten) mit den Einzelattributen. Geplant ist darüber hinaus noch eine INPRO-SystemUnitClassLib für StandardBetriebsmittel, hierzu sind Untersuchungen vorgesehen. Diese Ergebnisse wurden unabhängig vom AutomationML-Konsortium erarbeitet und anschließend der AutomationML-Arbeitsgruppe vorgestellt. Sie zeigen die gute Nutzbarkeit der flexiblen, sprachlichen Mittel der AutomationML, aber auch die hohe Bedeutung konkreter Rollenbibliotheken zur Festlegung der semantischen Bedeutung von Komponenten. Als eine wichtige Aufgabe für die Weiterentwicklung von AutomationML wird daher die weitere Ausarbeitung von Empfehlungen für Rollen- und Schnittstellenbibliothek angesehen, die im zweiten Teil der IECNormenreihe für AutomationML geplant ist.

7.2  Nächste Schritte 7.2.1  Schwerpunkte Die Weiterentwicklung von AutomationML umfasst sowohl das Dateiformat selbst als auch die Ausarbeitung spezifischer Standardbibliotheken. Bezüglich des Dateiformates wurde bereits mit Version 1.1 eine gute Stabilität erreicht. Die inhaltliche

310

D. Weidemann und R. Drath

Abb. 7.2   Vereinfachter Engineering-Prozess für Fertigungsanlagen

Arbeit an Bibliotheken hingegen wird evolutionär weiter verfolgt. Wie bei vielen anderen Standards auch wünscht die Industrie stetig die Umsetzung neuer Aspekten für ihre Geschäftsfälle. Abbildung 7.2 beschreibt einen vereinfachten Engineering-Prozess, der von der AutomationML als Referenzprozess genutzt wird. Ein Grundelement des Datenaustausches – unabhängig vom Gesamt-Workflow – ist die Beziehungen zwischen zwei Engineering-Schritten. Dazu gehören die Eingangsdaten, die ein Engineering-Schritt von seinen jeweiligen Vorgängern erwartet. Der Referenzprozess in Abb. 7.2 zeigt viele solche Paarverbindungen auf; hinter jeder stecken potentielle Anwendungsfälle. Diese wurden von der AutomationML-Gruppe beschrieben und priorisiert. Der Pfad, der von den Teilnehmern für ihre Anwendungsfälle am Wichtigsten gesehen wurde, beginnt beim Mechanical Design. Die Anlagenplanung beginnt „mit dem Metall“, das im Raum verteilt wird. Erst dann folgen die Phasen der Elektroplanung, SPS- und Roboterprogrammierung mit Simulation sowie HMI-Entwicklung, gefolgt von Vorinbetriebnahme und Inbetriebnahme. Deshalb ist AutomationML mit den Schwerpunkten Topologie und Geometrie gestartet. In den folgenden Abschnitten wird eine Auswahl von Anwendungsfällen und Ansätzen beschrieben, die bei der weiteren Entwicklung von AutomationML betrachtet werden. So muss die Anlagenbeschreibung mit Elektroplanungsdaten, Geräte- und Kommunikationsbeschreibung sowie Safety-Konfigurationen weiter

7  Bewertung und Ausblick

311

vervollständigt werden. Weiterhin sind Lücken zur realistischeren Simulation bis hin zur virtuellen Inbetriebnahme zu schließen. Nicht zuletzt ist die automatische Prüfung auf Einhaltung von Spezifikationen sowie die Ankopplung an überlagerte IT-Systeme wie beispielsweise MES von hohem Interesse. Gerade komplexe Themenfelder wie MES, Kommunikation, Elektroplanung oder die in Kap. 4 untersuchte Prozessbeschreibung können von der Vernetzung der Planungsdaten partizipieren, was aus einzelnen Datenformaten heraus heute nicht gelingt.

7.2.2  Kommunikation und Gerätebeschreibung Geräte sind wichtige Anlagenbestandteile und müssen in einer Anlagenbeschreibung entsprechend berücksichtigt werden. Wegen ihrer hohen Bedeutung stehen bereits eine Reihe von Standards zu deren Beschreibung zur Verfügung, beispielsweise GSDML, FDCML als ISO 15475-3 (FDCML 2002), IO-Link, EDDL, NE100/PROList oder FDT. Da AutomationML bevorzugt existierende und bewährte Standards integriert, muss für die Kommunikation und Gerätebeschreibung ein geeigneter Kandidat ausgewählt werden. Die Bewertung und Auswahl folgt den üblichen Kriterien. Wie AutomationML selbst muss jedes verwendete Datenformat ein kostenfreier, offener Standard sein. Bei der Integration ist der funktionale Umfang zu beachten. Welche Kommunikationsarten über die verschiedenen Feldbusse oder Ethernet werden bereits beschrieben oder müssten von AutomationML selbst abgebildet werden? Nach einer Vorauswahl muss weiter überprüft werden, wie gut sich die Beschreibungen über zusätzliche Komponenten-, Rollen oder Schnittstellenklassen in AutomationML einbinden lassen. Die Einbindung von Kommunikations- und Gerätebeschreibungen ist in der Toplevel-Architektur bereits vorgedacht. Beispielsweise können für Komponenten leicht zusätzliche Interface-Klassen für Feldbusse oder Ethernet-Kommunikation angelegt und über CAEX-InternalLinks miteinander verbunden werden. Master/Slave-Konzepte lassen sich schnell mit entsprechenden Rollen umsetzen: ein Controller übernimmt eine Master-Rolle, Slaves verbinden sich mit ihm. Die Herausforderung ist somit weniger, einen Ansatz zu finden, als vielmehr die verschiedenen, im Markt bewährten Konzepte sinnvoll und durchgängig umzusetzen.

7.2.3  Elektroplanung Elektro- und Mechanikplanung erfolgen heute häufig stark getrennt voneinander. Die Übergabe von Anlagendaten ist zwischen diesen Planungsschritten mit proprietären Schnittstellen stellenweise möglich, der Rückweg von der Elektroplanung zu einer gemeinsamen Datenplattform aber kaum. Dabei würde ein Single-Source-Konzept für die Daten erhebliche Möglichkeiten erschließen. Zuerst würde es die parallele Planung von Mechanik und Elektrik vereinfachen,

312

D. Weidemann und R. Drath

idealerweise sogar bis zu einem Round-Trip-Engineering. Im Elektroplan könnte leicht die umgebende Anlage geometrisch dargestellt werden. Von Komponenten ließe sich schnell zu den zugehörigen Elektroplanungen navigieren. Alleine die Vermeidung redundanter Datenhaltung durch die beiden Planungsdisziplinen verspricht eine erhebliche Qualitätssteigerung. Die verbesserten Eingabemöglichkeiten durch stärkere Nutzung von Grafiken würden eine weitere Verbesserung mit sich bringen. Die Berücksichtigung der Elektroplanung ist entsprechend wichtig für die AutomationML. In der Regel erfolgt die Elektroplanung zeitlich nach der Mechanikplanung. Wenn die wesentlichen mechanischen Komponenten der Fertigungslinie oder Zelle festgelegt sind, werden die elektrischen Teile hinzugefügt und verschaltet. Dazu werden zuerst die Namen und Identifikatoren der Anlagenkomponenten ausgewertet und erste Bereiche identifiziert. Für mechanische, pneumatische und hydraulische Anlagenteile werden elektrische Komponenten vorgeschlagen und in einem Review gemeinsam mit Mechanikdesignern und Kunden bewertet. Um diese Schritte zu realisieren, müssen umfangreiche Planungsdaten zur Verfügung stehen, wie beispielsweise das Zellen-Layout, Standardplänen und Stücklisten sowie Bezeichnungssystematiken und Projektierungsrichtlinien. Für alle Komponenten müssen Default-Positionen für elektrische Teile und Anschlüsse bekannt sein, für jede Komponente werden detaillierte Ablaufbeschreibungen benötigt, Zuordnungslisten und Belegungslisten sollten erstellt sein. Als Ergebnis liefert die Elektroplanung eine Anlagenübersicht, Stromlaufpläne, Installationspläne, eine PE/Erdungsschema, Schaltschrankaufbau und -übersicht, Pultaufbau, Klemmenpläne, Steckerpläne, SPS-Anschlusspläne, Kabellisten, Gerätelisten, Bestelllisten, Prüfprotokolle, Endschalterlagepläne, Pläne für Fluidtechnik, Feldbusübersicht und Sicherheitsbusübersicht sowie Zoneneinteilungen, z. B. Notstoppbereiche. Zusätzlich sind CE-Dokumentation und Inspektionschecklisten zu erstellen. AutomationML bringt bereits sehr gute Voraussetzungen für die Abbildung der Elektroplanung mit. Scheinbar kleine Dinge werden bereits berücksichtigt, beispielsweise können Komponenten mehrere Identifikatoren für elektrische oder pneumatische Kreise besitzen. Namenskonventionen können durch beliebige zusätzliche Attribute dargestellt werden. Besonders wichtig sind die vielfältigen Möglichkeiten zur Beschreibung von Relationen. So ist es zum Beispiel sehr einfach, die Beziehung von einem elektrischen Teil zu seiner mechanischen Komponente zu beschreiben oder die Abhängigkeiten zwischen verschiedenen Anlagenbereichen festzuhalten. Das Gruppen- und Facettenkonzept von AutomationML ist gut für Zoneneinteilungen geeignet. Mit den verschiedenen Arten von Bibliotheken können elektrische Komponenten, Rollen oder Schnittstellenklassen zusammengefasst und wiederverwendbar zur Verfügung gestellt werden. Bisher fehlt jedoch die Abbildung von 2D-Plänen und 2.5D-Grafiken. Beschriftungen im Klartext sowie vor allem Bemaßungen sind mit COLLADA nur schwer beschreibbar. Als Voraussetzung für die Elektroplanung ist daher die Identifikation und Einbindung von Austauschformaten für 2D-Pläne eine wichtige Aufgabe für AutomationML.

7  Bewertung und Ausblick

313

7.2.4  Safety-Aspekte Produktionsplaner, Mechanik-Designer und SPS-Programmierer müssen in ihrer Planung auch Safety-Aspekte berücksichtigen. Dies bedeutet beispielsweise die Aufteilung von Räumen und Begrenzungen gemäß der im Anlagen- oder ZellenLayout definierten Zonen. Sicherheitsbereiche sind aufzuteilen, zu konfigurieren und zu validieren. Dann müssen sichere Funktionen von SPSn oder Antrieben überprüft und gegen nicht autorisierten Zugriff geschützt werden. Zur räumlichen Festlegung für Sicherheitsbereiche müssen in AutomationML kartesische Volumendefinitionen beschreibbar sein; für gemeinsame Grenzen werden Joint-Spaces-Definitionen benötigt. Wenn Sicherheitsbereiche betreten oder verlassen werden, dann sind entsprechende Aktionen mit eventuellen Restriktionen und weiteren Aspekten abzubilden, ebenso die Behandlung von Sicherheitsereignissen. Verschiedene Sicherheitsereignisse müssen mit den Operatoren AND, OR und NOT logisch kombiniert werden können. Eine sehr nützliche Anwendung bietet eine Implementierung für Sicherheitsbeschreibungen durch die Nutzung der DIN EN 61800 zur Standardisierung von sicheren Funktionen, beispielsweise Safe Torque Off (STO). Mit Bezug auf diese Norm könnten bereits Anforderungen an Sicherheitsbereiche schnell erstellt und mit AutomationML herstellerneutral an Zulieferer verteilt werden. Die Beschreibung von Sicherheitsbereichen und zugeordneten Sicherheitsfunktionen erscheint mit AutomationML gut machbar. Zur Verfügung stehen bereits die Gruppen- und Facettenkonzepte zur Abgrenzung, die Erfassung von Räumen mit COLLADA sowie Function Blocks, mit denen wichtige Aspekte für Verriegelungslogik durch logische Ausdrücke beschrieben werden (siehe Abschnitt 4.5). Die hohe Anzahl relevanter Normen für sicherheitsgerichtete Systeme erschwert eine Implementierung, zum Beispiel die IEC 61508 als „oberste“ Norm, die EN 62061 oder IEC 61800-5-2 als Sektornormen für elektrische Maschinen bzw. Antriebe sowie die die ISO 13849, die die bekannte und weit verbreitete EN 954 (Sicherheitsnorm für Maschinensteuerungen) ablösen soll. Ein AutomationMLArbeitskreis muss alle zugehörigen Normen durchdringen und eine Strategie festlegen, wie sie in AutomationML abgebildet werden.

7.2.5  Simulation und virtuelle Inbetriebnahme Realistischere Simulationen als Voraussetzung für die virtuelle Inbetriebnahme benötigen präzise Anlagenplanungsdaten. Dies betrifft Geometrie, Kinematik, Ablaufpfade, Sequenz- und Verhaltensbeschreibungen sowie die Verschaltung der beteiligten Komponenten durch Signale, die in einer Simulation ebenfalls berücksichtigt werden sollen. Ziel ist es, vorhandene Anlagenbeschreibungen in der Simulationsumgebung nicht neu erstellen zu müssen. Im Idealfall werden daher Bibliotheken und individuelle Komponenten in das Simulationswerkzeug übertragen

314

D. Weidemann und R. Drath

und so zwischen den Werkzeugen synchronisiert. Eine Synchronisierung von Bibliotheken verschiedener Hersteller ist heute jedoch noch nicht im Markt verfügbar. AutomationML erfüllt bereits die meisten Voraussetzungen dafür. Eine wichtige Lücke ist die Standardisierung von Ablaufpfadbeschreibungen (siehe Abschnitt 5.4.2.). Nach Vervollständigung muss die Machbarkeit und Anwendbarkeit in den Fachabteilungen geprüft werden, die dafür von der AutomationML-Gruppe Unterstützung bekommen.

7.2.6  Compliance-Prüfung Bei der Spezifikation einer neuen Anlage werden Regeln festgelegt, deren Einhaltung in der Planung heute weitgehend manuell geprüft wird. Dies erfolgt aus Kapazitäts- und Kostengründen überwiegend nur für Teile und nicht für die ganze Anlage. Ziel ist es, stattdessen oder ergänzend automatisiert zu prüfen, um nicht nur Aufwand zu reduzieren, sondern vor Allem weniger Fehler und eine höhere Qualität zu erreichen. Idealweise können bereits Zwischenstände überprüft werden, um durch frühere Fehlererkennung den Nacharbeitungsaufwand zu reduzieren. Weitere Prüfungen umfassen die Vollständigkeit der Anlagenbeschreibung, die Validierung von Schaltplänen zum Beispiel auf nicht verbundene Steckverbindungen oder die Einhaltung von Namenskonventionen. Ebenso sind Prüfungen zur Einhaltung von Projektierungsrichtlinien und Konfigurationsregeln sinnvoll, z. B. dass eine SPS nur eine bestimmte Anzahl von Robotern ansteuern kann, oder dass nur frei gegebene Gerätetypen verwendet werden dürfen. Das Ergebnis der Prüfung ist die Feststellung, ob und an welcher Stelle Verstöße gegen die Spezifikation vorliegen oder, im positiven Fall, dass keine Fehler aufgetreten sind. Für AutomationML bedeutet dies, dass Beschreibungen für Standards, Anforderungen, Materiallisten, Programmieranweisungen und Projektierungsrichtlinien entwickelt werden müssen. Komponenten wie SPSn oder Roboter müssen auf Basis von Standardbibliotheken automatisch erkennbar sein. Ein geeigneter Ansatz ist das erweiterbare CAEX-Rollenkonzept.

7.2.7  P  rojektierung und Konfiguration von MES mit AutomationML Unter dem Schlagwort CIM (Computer Integrated Manufacturing) wurde in den 1980er Jahren die durchgängig rechnerunterstützte Produktion propagiert. Aufgrund der damals vorhandenen Hardware setzte sich diese Vision nicht in der Praxis durch, obwohl die Ansätze aus heutiger Sicht richtig waren und viele gute Forschungsergebnisse erarbeitet wurden. Inzwischen haben sich die Wettbewerbsbedingungen für Produktionsunternehmen in Deutschland drastisch verschärft – sie stehen im globalen Wettbewerb mit Standorten, die teilweise zu völlig anderen Faktorkosten produzieren. Darum sind Innovationen wichtige Erfolgsfaktoren für die Produktion in Deutschland. Innovative

7  Bewertung und Ausblick

315

Produktionsprozesse zeichnen sich nach einhelliger Meinung von Experten durch drei Faktoren aus: • Wandlungsfähigkeit, • Realzeitfähigkeit und • Netzwerkfähigkeit. Alle drei Erfolgsfaktoren sind ohne moderne, produktionsnahe IT-Systeme nicht zu erreichen. Heute etabliert sich mit Manufacturing Execution Systemen (MES) eine neue Generation produktionsnaher IT-Systeme, die die Vorstellung der computerintegrierten Fertigung Realität werden lassen. Als Informationsdrehscheiben in der Fabrik erlauben sie den Zugriff auf Informationen in den weltweiten Produktionsstätten in Echtzeit, sie verbinden Hersteller sowie ihre Zulieferer und sie befähigen die Betreiber komplexer Produktionssysteme dabei, sich permanent auf die wandelnden Bedürfnisse ihrer Kunden einzustellen. Nach der VDI-Richtlinie VDI 5600 (VDI 5600) sind Aufgaben von MES: Betriebsmittel-, Material-, Personal-, Informations- und Qualitätsmanagement, Datenerfassung, sowie Feinplanung und -steuerung und Leistungsanalyse. IT-Systeme, die diese vielschichtigen Aufgaben lösen, gibt es nicht „von der Stange“, d. h. es sind bei jeder Produktion Konfigurations- und Projektierungsarbeiten zu erledigen, die zeit- und kostenintensiv sind. Die Konfiguration oder Projektierung des MES findet meist am Ende des Planungsprozesses statt, kurz vor oder während der Inbetriebnahme der Produktionsanlagen. Heute ist sie zum großen Teil manuell, so dass bei der Komplexität auch Fehler auftreten, die vom Projektierer verursacht werden. Während der Projektierung müssen dem MES alle wichtigen Informationen über das Produktionssystem mitgeteilt werden; im Folgenden dazu einige Beispiele: • Zunächst muss die Topologie der Anlage bekannt gemacht werden, z. B. welche Komponenten in den Anlagen enthalten sind und wie sie miteinander verbunden sind. • Um auf reale Signalwerte aus dem Produktionsprozess lesend und schreibend zugreifen zu können, müssen im nächsten Schritt die Kommunikation zwischen dem Produktionsprozess – meist ist die Anlagensteuerung der Kommunikationspartner – und dem MES konfiguriert und die einzelnen Signale mit den internen Strukturen des MES verknüpft werden. • Schließlich wird eine eindeutige Visualisierung für den Anlagenbediener benötigt, die ebenso erstellt werden muss. Diese muss an die Signale gekoppelt und in den meisten Fällen entsprechend dynamisiert werden. Beispielsweise sollen bei Fehlern bestimmter Anlagenkomponenten die zugehörigen Bildelemente einen Farbumschlag erhalten. Um die angesprochenen für MES nötigen Daten vollständig zu erlangen, benötigt man Informationen aus mehreren Quellen. Dies sind beispielsweise Informationen über die Signale des Prozesses aus den jeweiligen Feldgeräten und Steuerungen, ebenso Visualisierungsdaten der Anlage und Topologieinformationen aus der Anlagenplanung beziehungsweise Topografieinformationen aus der Layout-Planung.

316

D. Weidemann und R. Drath

Abb. 7.3   MES-Datenquelle AutomationML

Dazu wird folglich ein Datenformat benötigt, in dem alle Informationen von verschiedenen Stellen gesammelt und je nach Bedarf wieder herausgefiltert werden können. Genau an dieser Stelle setzt AutomationML an. Sämtliche mit AutomationML beschriebenen Informationen des Produktionssystems müssen zur Nutzung im MES-System über eine eigene MES-Sicht (Abb. 7.3) quasi ‚herausgezoomt‘ werden. Durch die Bereitstellung dieser Daten wird eine automatische Konfiguration und Projektierung von MES bis hin zur automatischen Visualisierungsgenerierung möglich, die sowohl den Projektierungsprozess zeitlich entzerrt, die daraus resultierenden Ergebnisse qualitativ steigert und letztlich neue Möglichkeiten eröffnet, Qualitäts- und Auswertedaten aus den MES in AutomationML zurückzuführen und dadurch neue Anwendungsmöglichkeiten und -potenziale auszuschöpfen. So kann der Regelkreis zwischen Planung und Betrieb geschlossen werden. Der Einsatz von Informationstechnik in der Produktion ist also noch längst nicht ausgereizt – es gibt noch Potenzial. Vor allem in der Integration heutiger Insellösungen stecken noch viele Chancen. Die horizontale Integration auf der Leitebene sowie die vertikale Integration von der Feldebene über die Leitebene in die Unternehmensleitebene bieten noch viele Möglichkeiten zur Verbesserung. Die Interoperabilität zwischen Systemen oder zwischen Anlagen und überlagernden IT-Systemen ist noch lange nicht gelöst – dazu benötigen die beteiligten Systeme ein gemeinsames Verständnis ihrer Daten auf semantischer Ebene.

7.3  Zusammenfassung und Ausblick In diesem Buch wird erstmalig ein umfassender Überblick über AutomationML gegeben. Es beschreibt die Hintergründe und vielfältigen Motivationen des AutomationML-Konsortiums und belegt die Notwendigkeit eines universellen Datenaustauschformats für unterschiedliche Anwendungsgebiete. AutomationML wurde ursprünglich aus der Domäne der Fertigungstechnik heraus initiiert. Beim Vergleich mit aktuellen Herausforderungen der Planung prozesstechnischer Anlagen stellt sich jedoch heraus, dass das Engineering beider Bereiche

7  Bewertung und Ausblick

317

gleichermaßen und fachübergreifend durch fehlende Datenaustauschlösungen gekennzeichnet ist. Diese Gemeinsamkeit lässt auf Synergien in gemeinsamen Aktivitäten schließen, denn ähnliche Probleme lassen sich häufig mit ähnlichen Ansätzen lösen – AutomationML ist deshalb ebenso für das Engineering prozesstechnischer Anlagen geeignet. Ursache für diese Gemeinsamkeit ist die gleichartige Evolution der Phasenseparation. Mit der Spezialisierung der unterschiedlichen Gewerke haben sich passende spezialisierte Werkzeuge entwickelt. Die Arbeit innerhalb der einzelnen Phasen wurde durch diese Werkzeuge zwar erheblich beschleunigt, zugleich sank jedoch die funktionelle Differenzierbarkeit der unterschiedlichen Werkzeuge innerhalb eines Gewerkes. Als Engpass verbleibt der Datenaustausch zwischen den Gewerken. Wesentliche Zukunftstechnologien erfordern den Zugriff auf gemeinsame und konsistente Planungsdaten Drath (2008). Diese liegen heute in einer heterogenen Werkzeuglandschaft verstreut vor, insofern stellt sich der Datenaustausch zwischen Werkzeugen als ein Hauptbedürfnis in der Industrie heraus, insbesondere unter dem Gesichtspunkt, dass sich viele der verfügbaren Werkzeuge gegenseitig nicht kennen oder unterstützen. Dies wiederum erklärt sich aus dem Differenzierungswunsch der Werkzeughersteller, erfordert jedoch künftig ein deutliches Umdenken. Der Wert der Engineering-Daten liegt daher zunehmend weniger im Werkzeug, sondern vielmehr im Austausch der Daten im Sinne einer Wertschöpfungskette. Mit AutomationML stehen die Planungsdaten und nicht mehr die Werkzeuge im Vordergrund der Beziehungen zwischen Betreibern und Anbietern, und deren Austausch ist die funktionelle Basis für eine Reihe weiterer Zukunftstrends. Die Architektur von AutomationML ist im Vergleich zu anderen Ansätzen darauf ausgerichtet, etabliertes Wissen und vorhandene Standard-Datenformate miteinander zu verbinden, statt durch Eigenentwicklungen mit ihnen in Konkurrenz zu treten. Der Fokus auf frei verfügbare Datenformate sowie die Abstützung auf XML werden als Schlüssel für eine breite Akzeptanz im Markt betrachtet. Durch Wiederverwendung vorhandener Datenformate bleibt die Definition von AutomationML selbst bemerkenswert schlank. Sobald Planungsdaten algorithmisch zugänglich sind, erschließen sich eine Reihe neuer Technologien und Ansätze, um Engineeringkosten weiter zu senken. Hierzu sind in der Literatur neben den oben bereits genannten Anwendungsbeispielen eine Reihe weiterer interessanter Arbeiten finden: • Güttel et al. (2008) beschreibt beispielsweise, wie auf Basis von in CAEX vorliegenden Anlagenplanungsdaten Steuerungscode automatisch generiert werden kann. • Schmidberger et al. (2005b) und Drath et al. (2006) erläutern, wie mit Hilfe wissensbasierter Methoden Verriegelungslogik erzeugt werden kann. Dies erfolgt durch Aufstellen von Regeln wie: „Wenn der Füllstand eines Tankes bekannt ist, der einen Ablaufstutzen mit einer Pumpe besitzt, dann soll die Pumpe automatisch abgeschaltet werden, sobald der Tank leer ist“. Derartige Regeln lassen sich anlagenweit anwenden und sorgen für eine vollständige Abdeckung der in den Regeln beschriebenen Logik.

318

D. Weidemann und R. Drath

• Runde et al. (2009) widmet sich dem Thema OWL. Hier werden CAEX-Anlagendaten nach OWL transformiert und erschließen sich somit den OWL-fähigen Inferenzmaschinen. • Schmidberger et al. (2005a) beschreibt, wie basierend auf CAEX ein automatisiertes Engineering von Prozessleitsystem-Funktionen erfolgen kann. • Beez et al. (2008) beschäftigt sich mit der automatischen Erzeugung von „Bond Graph Models“ für prozesstechnische Anlagen. • Yim et al. (2006) führt mittels CAEX eine sogenannte „Plant Disturbance Analysis“ durch. Basierend auf gemessenen Prozesswerten wird hier gezielt nach Schwingungen im Regelverhalten und ihren Ursachen gesucht. Sind mehrere Schwingungen gefunden, die aufgrund ihres zeitlichen Erscheinungsbildes voneinander abhängen könnten, ermöglicht die Untersuchung des Anlagenmodells, ob sich ein physikalischer Wirkzusammenhang zwischen beiden Messpunkten befindet. Auf diese Weise können vermeintliche Korrelationen automatisch verworfen oder erhärtet werden. • Schmitz u. Epple (2007) untersucht, wie basierend auf CAEX HMI-Oberflächen automatisch generiert werden können. • Ebel et al. (2008) definiert eine CAEX-Schnittstelle für die Projektierung eines Produktionsleitsystems und ihrer Bedienoberflächen. • Remmel u. Drumm (2009) verwendet semantische Modelle zum Datenimport von CAEX-Daten in die Engineering-Werkzeuge von Siemens. • Runde u. Fay (2008) und Runde et al. (2008) beschreiben die Anwendung von CAEX in der Gebäudeautomatisierung. • Schleipen u. Schick (2008) und Schleipen (2009) verwenden CAEX/AutomationML zur Generierung von Prozessführungsbildern unter z. B. ergonomischen Gesichtspunkten. Allein die Fülle der wissenschaftlichen und industriellen Arbeiten verdeutlicht die Potentiale rund um das Thema des neutralen Datenaustausches, der Datenintegration und der damit möglichen algorithmischen Zugänglichkeit vernetzter Planungsdaten. Der offene Zugang zu Planungsdaten gilt als Schlüssel für die Automatisierung von Engineering-Schritten – der „Automation of Automation“. Interessenten aus Wirtschaft und Forschung sind deshalb eingeladen, das Thema mit zu gestalten. Die Zu­kunft des Engineering bleibt spannend.

Literatur Ahrens W et al (2005) Standardisierte Merkmale als Schlüssel für den unternehmensweiten Datenaustausch im Engineering-Umfeld, http://www.namur.de/fileadmin/media/PROLIST/ EKA206_01.pdf.

7  Bewertung und Ausblick

319

Beez S, Fay A, Thornhill N (2008) Automatic Generation of Bond Graph Models of Process Plants. In: Tagungsband der 13. Tagung „IEEE International Conference on Emerging Technologies and Factory Automation“ (ETFA), Hamburg, 15.–18. September 2008. ISBN 1-4244-1506-3. Drath R (2008) Die Zukunft des Engineering. Herausforderungen an das Engineering von fertigungs- und verfahrenstechnischen Anlagen. In: Tagungsband Karlsruher leittechnisches Kolloquium 2008, S. 33–40, Fraunhofer IRB Verlag, Karlsruhe. Drath R, Fay A, Schmidberger T (2006) Computer-Aided Design and Implementation of Interlocking Control Code. In: 2006 „IEEE International Symposium on Computer-Aided Control Systems Design“ (CACSD06), Munich, 04.–06. Oktober 2006, Catalog number 06TH8902, pp. 2653–2658. ISBN 0-7803-9797-5. Ebel M, Drath R, Sauer O (2008) Automatische Projektierung eines Produktionsleitsystems der Fertigungstechnik mit Hilfe des Datenaustauschformates CAEX. In: atp 5/2008, S. 40–47, Oldenbourg-Verlag. FDCML (2002) FDCML 2.0 Specification, www.fdcml.org. Güttel I, Weber P, Fay A (2008) Automatic generation of PLC code beyond the nominal sequence. In: Tagungsband der 13. Tagung „IEEE International Conference on Emerging Technologies and Factory Automation“ (ETFA), Hamburg, 15.–18. September 2008. ISBN 1-4244-1506-3. Prinz J, Dreher S, Eßer G (2009) Verteilte und Modulare Anlagenplanung. Erscheint in ZwF-08 2009 (Zeitschrift für wirtschaftlichen Fabrikbetrieb), Carl Hanser Verlag, München. Remmel M, Drumm O (2009) Anwendungen semantischer Technologien zur Erstellung von Schnittstellen. In: Tagungsband zum Automation 2009-Kongreß Baden-Baden, VDI-Berichte 2067, S. 171–174, VDI-Verlag, Düsseldorf. Runde S, Fay A (2008) A Data Exchange Format for the Engineering of Building Automation Systems. In: Tagungsband der 13. Tagung „IEEE International Conference on Emerging Technologies and Factory Automation“ (ETFA), Hamburg, 15.–18. September 2008. ISBN 1-4244-1506-3. Runde S, Güttel K, Fay A (2008) Modellierung mit CAEX in der Fertigungs- und Gebäudeautomatisierungstechnik. In: Tagungsband „Automatisierung 2008“, Baden-Baden, 3.–4. Juni 2008. ISBN 978-3-18-092032-0. Runde S, Güttel K, Fay A (2009) Transformation von CAEX-Anlagenplanungsdaten in OWL – Eine Anwendung von Technologien des Semantic Web. Tagungsband „Automation 2009“, Baden-Baden, 16.–17. Juni 2009. Schleipen M (2009) Usage of Dynamic Product and Process Information in a Production Moni­ toring and Control System by Means of CAEX and OPC-UA. Accepted contribution to: 3rd International Conference on Changeable, Agile, Reconfigurable and Virtual Production (CARV), 5.–7. Oktober 2009, Munich, Germany. Schleipen M, Schick K (2008) Self-Configuring Visualization of a Production Monitoring and Control System. CIRP International Conference on Intelligent Computation in Manufacturing Engineering – CIRP ICME ‘08, Naples, Italy, 23.–25. Juli 2008. ISBN 978-88-900948-7-3. Schmidberger T, Fay A, Drath R (2005a) Automatisiertes Engineering von ProzessleitsystemFunktionen. Automatisierungstechnische Praxis, Heft 2/2005, S. 46–51. Schmidberger T, Fay A, Drath R (2005b) Automatische Generierung von Verriegelungssteuerungen aus der Anlagenbeschreibung. GMA-Kongress 2005, Baden-Baden, 7.–8. Juni 2005, VDIBericht 1883, S. 117–124. Schmitz S, Epple U (2007) Automatisierte Projektierung von HMI-Oberflächen. In: VDI-Berichte Nr. 1980, S. 127–137. VDI 5600 Blatt 1 2007 „Fertigungsmanagementsysteme“. Yim SY, Ananthakumar HG, Benabbas L, Horch A, Drath R, Thornhill NF (2006) Using Process Topology in Plant-Wide Control Loop Performance Assessment. Computers & Chemical Engi­ neering, 31, S. 86–99.

Stichwortverzeichnis

A Abdeckungsgrad, 13 Ablauflogik, 64 Action-Nodes, 214 addData-Schema, 156f Beispiel, 158 Elemente, 159 Aggregation, 47 Aktion, 202 Anlagenkomponente, 96 Anlagentopologie, 28 Ansätze zum Datenaustausch, 6 Anwendungen und Beispiele, 35 Artikulierte Systeme, 116 dynamische Aspekte, 120 kinematische Aspekte, 119 Artikuliertes System, einer kombinierten Kinematik, 124 Aufgabenbeschreibung, 195 Automation of Automation, 318 AutomationML, 1, 9, 25, 198, 214, 287 Abgrenzung, 15 als zentrale Planungsdatenbasis, 296 Anwendungsfälle, 36 Anwendungsszenarien, 307 Architektur, 45 Architekturanforderungen, 25 Architekturüberblick, 25 Aspekte, 29, 45 AutomationCSRoleClassLib, 33 AutomationMLBaseRoleClassLib, 33 AutomationMLMIRoleClassLib, 33 Erweiterte -Konzepte, 34 Initiatoren, 9 Mehrwert von, 14 Mitgliedschaft, 40 Mitwirkung, 40 Modellierungsprozess am Beispiel, 261

Motivation, 2 Offenheit von, 12, 40 Rollenbibliotheken, 33 Standardisierung, 40 verteilte Dateistruktur, 27 Ziele, 10, 25 AutomationML Editor, 222, 224, 259, 262 AutomationML Engine, 222, 233 AutomationML Logic Editor, 229 AutomationML-Konsortium Teilnehmer, 10 AutomationML-Objekt, 45, 47 AutomationML-Ziele, Automation of Automation, 72 Code-Generatoren, 72 Code-Generierung, 79 Durchführung automatischer Planungsschritte, 72 Erstellung von Bedienoberflächen, 79 Plausibilitätsanalysen, 72 Prüfmechanismen, 72 Autorisierung des Datenaustausches, 292 B Bahnbeschreibung, 202 Bahnindex, 206f Bearbeitungsprozess, 202 Bearbeitungsvorgänge, 195 Beispiele, 195 Beschreibungsmittel, 137–141 Bibliotheken, 27 Bidirektionaler Datenaustausch, 292 BREP, 98, 285 Beispiele, 128 prinzipielle Struktur, 100 BREP-Begrenzungen Edge, 99 Face, 99

321

322 Shell, 99 Solid, 99 Vertex, 99 Wire, 99 BREP-Elemente Kurve, 99 Oberfläche, 99 Punkt, 99 C CAEX, 26, 29, 45, 124 Attribute, 29 Beziehungen, 29 Bibliotheken auslagern, 279 Bibliotheken, 29, 49 Bibliothekskonzept, 49 große Dateien, 278 Grundkonzepte, 29 Instanz-Hierarchie, 30 Kernkonzepte, 28 Klassen, 29 Masterdokument, 278 Modellierung, 54 Objekte, 29 Objektmodellierung ausschließlich mit Klassen, 54 Objektmodellierung ohne Klassen, 54 Referenzen, 30 referenzieren, 124 Relationen, 30 Rollen, 30 Rollen-Bibliotheken, 33 Rollenkonzept, 52 Schnittstelle, 124 Schnittstellen, 29f Schnittstellen-Bibliotheken, 33 Zentraldokument, 281 CAEX-Elemente, 48 , 58 , 71 , 49 , 71 , 62, 65 , 278 , 49f, 86 , 50 , 50 , 58 , 49, 52, 90 , 62, 75, 87, 189, 191 , 50, 52 , 50 , 57f 56, 58, 71

Stichwortverzeichnis , 50, 52 , 49f CAEX-Tag ID, 55 Name, 55 OldVersion, 62 RefBaseClassPath, 59f RefBaseRoleClassPath, 57f RefBaseSystemUnitPath, 61, 62, 282 Code-Generierung, 204 COLLADA, 26, 30, 35, 95, 97, 107, 195, 202, 206, 214, 278 Entstehungsgeschichte, 95 große Dateien, 283 Masterdokument, 283 Produktbaum, 108, 283 Referenzieren von, 124 Referenzierung von, 31 Transformationselemente, 108 vier Hauptabschnitte, 98 Wurzeln, 30 Zerlegung, 285 COLLADA DOM, 222 COLLADA Sax Loader, 222 COLLADA StreamWriter, 222 COLLADA Tools, 239 COLLADA-Dokument, 96 COLLADA-Elemente, 97, 100, 123 , 118 , 97 , 114 , 113 , 113, 122 , 118, 121, 124 , 119 , 122 , 122 , 110 , 100 , 97 , 100 , 101 , 110 , 98, 125 , 116 , 101 , 122 , 108 , 113 , 122 , 122 , 111

Stichwortverzeichnis , 122 , 113 , 118f , 113 , 122 , 98 , 113 , 98 , 98 , 103 , 103 , 113 , 103 , 118f , 116, 118 , 108

, 101 , 106 , 105f , 113 , 113 , 113 , 98, 122, 125 , 119, 122 , 101 , 100 , 100 , 116 , 125 , 116 , 113f , 105 , 107 , 107 , 122 , 101, 105 , 101 , 101 COLLADAInterface, 64f, 125f, 216 Attribut Frame, 125 Attribut ref  Type, 126 Attribut ref  URI, 125 COLLADASaxFrameworkLoader, 239 COLLADAStreamWriter, 239 Computerspieleindustrie, 96 D Datenkonsistenz, 290 DCC, 96 Detaillierungsgrade, 111, 284 Vorgehensweise, 285 Domänen, 45 Dreieck-Fan, 107 Dreieck-Strip, 105 Drei-Sichtenkonzept, 84

323 E Eckpfeiler der Prozessbeschreibung Bahn, 202f Prozessanweisungen, 202f Werkzeug, 202f, 208 Einführung, 96 Elektroplanung, 311 Engineering-Prozess, 141 Erweiterte AutomationML-Konzepte, 74 F Facetten-Konzept, 34, 77 Formeln, 115 für ein Parallelogramm, 116 vordefinierte Funktionen, 116 Funktionales Engineering, 23 G Gantt Charts, 3, 143 Elemente, 145 Transformation nach IML, 163 Geometrie, 29, 64, 95f Graphic CPF, 222, 239 Anforderungen, 240 CPCMD, 243 Extension points, 242 Manifest, 243 Pipeline, 241 Unterstützte Ausgabeformate, 240 Unterstützte Eingabeformate, 240 Gruppen-Konzept, 34, 79 GUID, 51 I IEC 61131-3, 31 IEC 62424, 28 IML, 138, 160 Elemente, 161f IPredecessor, 253 Klassendiagramm, 163 Motivation, 160 Transformation nach PLCopen XML, 179 Vergleich der Abbildungsvorschriften, 177 Vorgehensweise bei der Implementierung, 181 Vorteile, 138 Import und Export, 91 Impuls-Diagramme, 145 Elemente, 145 Transformation nach IML, 169 Instanzen Erstellung mittels Kopiervorlagen, 54 Instanz-Hierarchie, 50

324 K Kinematik, 29, 64, 95 Anforderungen, 111 Beschreibung, 111 Gelenke, 112 Modelle, 113 Kinematische Kette, 114 Kinematische Szene, 122 Klasse, 47 Komple Szene, 96 Komponentengruppen, 183 Komposition, 47 Konsolidierungsschritte, 295 Konverter, 138, 222 L Logic CPF, 37, 222, 247 Beispiel, 254 Conditioner, 247 IML-DOM, 250 ITask, 253 Konfigurationsdatei, 249, 257 Pipeline, 247 Plugin-Architektur, 248 Plugins, 247, 253 Rahmenapplikation, 249 Reader, 247 Writer, 247 Logic Editor, 222 Logiknetzwerke, 149 M Manueller Datenaustausch, 288 Marktdurchdringung, 14 Massendaten, 27 Materialien, 108 definieren, 110 Farben, 108 Texturen, 108 MathML, 116 MathMLSolver, 222, 239 MES, 311 Meta-Konzepte, 27 Mirror-Konzept, 62, 281 Master-Objekt, 62 Mirror-Objekt, 62, 80 Modellierung nutzerdefinierter Attribute, 71 nutzerdefinierter Bibliotheken, 72 nutzerdefinierter Daten, 70 nutzerdefinierter SystemUnit-Klassen, 71

Stichwortverzeichnis N Normenreihe, 41 nVidia Scenegraph SDK, 239 NVSG Viewer, 222 O Objekt, 46 Objektidentifizierung, 55 Konzepte zur, 55 Objektinstanz, 47 Objektorientierung, 45f OPC-Datentypen, 274 OPC-Konfiguration, 273 OPCServer, 273 Attribute, 274 OPCTag, 273 Attribute, 273 Open Scene Graph, 222, 227 OpenCOLLADA Framework, 239 P Papierschnittstelle, 21 PERT Charts, 144 Elemente, 144 Transformation nach IML, 167 Unterschied zu Gantt Charts, 169 Philipp 5 Modellierungsschritte, 261 Beispielübersicht, 259 Erstellen von Bibliotheksobjekten, 271 Objektschnittstellen, 264 Struktur, 260 Verhaltensbeschreibung, 266 Vorgehen zur Abbildung, 260 Planungsphasen, 3 Planungsprozess, 135 in der Automobilindustrie, 16 in der Prozessindustrie, 19 PLCopen XML, 26, 31, 135, 138, 153, 191, 193, 214, 278 Anwendungsfälle, 153 Referenzierung von, 32, 188 Überblick, 153 PLCopenXMLInterface, 64 PluginOption, 253 Polygon, 103, 105 Port-Konzept, 34, 74 PPRConnector, 87 Produkt, 85 Produktbäume, 107 Produktkataloge, 50 Produkt-Prozess-Ressourcen-Konzept, 35

Stichwortverzeichnis Profile-Nodes, 214 PROLIST, 309 Prozess, 85 Prozessbeschreibung, 196, 198 Aktion, 200 Aktionen modellieren, 209 Anforderungen, 195, 198, 202 Aufgabenbeschreibung, 197, 199, 201 Ausführungsdreieck, 205 Bahn-Objekt modellieren, 206 Bahn-Objekt, 206 Basiselemente, 204 Beispiel Lackierpistole, 210 Beispiel Schweißnaht, 199 Beispiel Schweißpistole, 211 Beispielmodellierung mit AutomationML, 214 Bewegungsanweisungen, 198 Eckpfeiler, 202 Einschränkungen modellieren, 209 Freiheitsgrade modellieren, 210 Modellierungsbeispiel, 195 Motivation, 195f Objekte und Relationen, 203 Planungsdaten, 195 Problembeschreibung, 196 Prozessgrößen modellieren, 209, 214 Prozess-Objekt modellieren, 213 Prozessparameter modellieren, 202 Stützpunkte einer Bahn, 199 Szenarien, 199 Übersicht, 201 Verknüpfungen modellieren, 218 Verlauf einer Bahn, 199 Vorteile, 200, 220 Prozessbeschreibungs-Bibliothek, 215 Prozessdefinition, 204 Prozesselemente, 201 Prozesswerkzeug, 202 Prüfinstanz, 291 R R&I-Fließbild, 21, 289 Referenzen, 278 Referenzierung, 283 extern gespeicherter Informationen, 64 von COLLADA-Dokumenten, 64 von PLCopen XML-Dokumenten, 64 Referenzmechanismen, 64 Referenzwerkzeuge, 224 Relationen, 47 Instanz-Instanz-Relationen, 58

325 Klassen-Instanz-Relationen, 58, 61 Vater-Kind-Relationen, 58f Vererbungsbeziehungen, 58, 60 zwischen Instanzen, 62 Relationen zwischen Anlagenobjekten, 27 Ressource, 83, 85–87 Ressource-Produkt-Prozess-Konzept, 83, 217 produktzentrierte Sicht, 85 prozesszentrierte Sicht, 85 ressourcenzentrierte Sicht, 85 Roboterprogramm, 196, 204 Rollenbibliothek zur Prozessbeschreibung, 216 Rollenbibliotheken, 73 Rollenkonzept, 52 Ausgangspunkt, 52 Unterstützung mehrerer Rollen, 56 Vorgehensweise, 52 S Safety-Aspekte, 313 Schnittstellen, 67 Publikation von, 65 Semi-automatischer Datenaustausch, 288 Sequential Function Charts, 147 Elemente, 147 SFC, 31 Signalgruppen, 183 Standardbibliotheken, 67 AutomationMLBaseRoleClassLib, 68 AutomationMLCSRoleClassLib, 69 AutomationMLCSRoleClassLibrary, 273 AutomationMLInterfaceClassLib, 67 AutomationMLMIRoleClassLib, 69 Erweiterte AutomationMLRollenbibliothek, 73 Standardisierungsvorhaben, 39 State Charts, 150 Elemente, 151 Transformation nach IML, 174 Systembaustein, 135 T Target, 203, 206f TCP, 203 Tesselierung, 103 polygon-basierte, 103 Transformationsregeln, 138, 160 U Unidirektionaler Datenaustausch, 291 Units, 50

Stichwortverzeichnis

326 V Vererbung, 47 Verhalten, 29 Verhaltensbeschreibung, 31, 193 Behaviour, 136, 139 Detaillierungsgrad, 135 Gegenstand, 136 Herausforderung, 138 innere versus äußere Sichtweise, 136 Interlocking, 137 Sequencing, 136, 139 Verriegelungslogik, 139 Verriegelungslogik, 183 Erweiterte Verriegelungskonzepte, 187 Signal- und Komponentengruppen, 183

Vertizen, 105 virtuelle Inbetriebnahme, 313 Visuelle Szene, 109 Vollautomatischer Datenaustausch, 288 W Weltmodell des Engineering, 27 Wiederverwendung, 3, 23, 28 Workflow, 287 Empfehlungen, 287, 298 paralleler, 295 sequentieller, 294 Z Zyklen, 114