This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
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 <wires> Element besitzt zwei Elemente, ein Element. Das Element 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.
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
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 <mesh> 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
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
V2
V4
V1 V3 V5
Abb. 3.10 Das
In einer komprimierteren Form werden Polygone durch das Element <polylist> beschrieben, siehe Abb. 3.12. Durch das Element
106
S. Lips V1 V5
V6
V8
V2
V7 V4
V3
Abb. 3.11 Das <polygons> Element mit einem Loch V1 V5 V2 V4
V3
Abb. 3.12 Das <polylist> Element
V2
V1
V4 V3
V6 V5
Abb. 3.13 Das
3 Beschreibung von Geometrie und Kinematik mit COLLADA
107
V2
V1
V4 V3
V6 V5
Abb. 3.14 Das
V2
V1
V3
V5
V4
Abb. 3.15 Das
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
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
<matrix>
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 <node> Elementen beschrieben. Jedes <node> Element kann als Kinder wiederum <node> 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
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 <effect> 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
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
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 <joint>. Dieses kann beliebig viele Elemente vom Typ <prismatic> oder
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
114
S. Lips
40
40
Abb. 3.23 Beispiel eines einfachen kinematischen Modells
zuvor in
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 ,
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
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 <articulated_ system> definiert. Es folgt die Festlegung, welche Aspekte des Modells beschrieben werden sollen. Dies geschieht durch das Element
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 Gleichungssystem des kinematischen Problems. Durch einen Index wird diese Position im sog. Gelenkvektor festgelegt Es können verschiedene Koordinatensysteme festgelegt 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 Koordinatensystem am Ende der kinematischen Kette fest. Dieses Koordinatensystem muss definiert werden – das Objektkoordinatensystem kann dazu verwendet 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 <motion> ist ähnlich aufgebaut wie das Element
120
S. Lips
Tab. 3.8 Dynamische Aspekte Eigenschaft
Element
Beschreibung
Geschwindigkeit <speed> Beschleunigung
Ruck
Für jedes Gelenk und für den Endeffektor kann eine Ge schwindigkeit festgelegt werden, die 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 <setparam> ein Wert festgelegt werden. Oder aber der Parameter wird durch das Element
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
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
3 Beschreibung von Geometrie und Kinematik mit COLLADA
123
Abb. 3.31 Koppelung zwischen Kinematik und Geometrie
durch das COLLADA-Element
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
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 <scene> statt. Dieses Element hat allerdings kein von CAEX aus referenzierbares Attribut id. Es musste daher eine Möglichkeit gefunden werden, die Information, die im <scene> 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 <extra> eingeleitet. Innerhalb dieses Elements folgt das Element
3 Beschreibung von Geometrie und Kinematik mit COLLADA
127
Abb. 3.35 <extra> 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 Produktionssys 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
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
4 Verhaltensbeschreibung mit PLCopen XML
159
Tab. 4.1 Elemente des AutomationML addData-Schemata Element Anwendungsfall/ Beschreibung Elternelement Aktion Beschreibung erweiterter Zeitinformationen <Time> Aktion Dauer einer Aktion
Zur Beschreibung der Information, ob eine Aktion unterbrechbar ist, wird laut Spezifikation das Element
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
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
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
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 Changes 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
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 <documentation> 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
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 Funktionsblocknetzwerk
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
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
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
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
6FKZHLQDKW
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 – Prozessmethoden 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 <SystemUnitClassLib> 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
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
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
<
<
<<uses>>
<
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
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
258
R. Drath et al. Path
Pipeline Pipeline Root
Plugin 0..∞
Options
Option 0..∞
Abb. 6.29 XML-Schema der Pipelinekonfigurationsdatei
Jedes