Fertigungs- & Maschinenautomation

Heft 9/2010•

In den letzten Jahren wurden im Umfeld der automatisierten Ferti-gungstechnik große Anstrengun-gen unternommen, um die Metho-de der virtuellen Inbetriebnahme aus den Forschungseinrichtungen der Unternehmen in den produkti-ven Einsatz zu transferieren. Mitt-lerweile stellt sich nicht mehr die Frage, ob die virtuelle Inbetrieb-nahme eingesetzt werden soll, son-dern wie effektiv sie eingesetzt werden kann. Schließlich lassen sich die Vorteile, wie Verkürzung der Inbetriebnahmezeit und weni-ger Produktionsausfälle durch qua-

litativ höherwertige Steuerungsprogram-me, erreichen, wenn der zusätzliche Auf-wand für die virtuelle Inbetriebnahme im Rahmen bleibt bzw. idealerweise gar nicht entsteht.

Ziel und Architektur der virtuellen Inbetriebnahme

Das Ziel der virtuellen Inbetriebnahme – bezogen auf den automobilen Karosse-rierohbau – ist die „frühzeitige Absiche-rung und Optimierung des Zusammen-spiels von Anlagenmechanik und -elekt-rik sowie der Steuerungssoftware ohne das Vorhandensein der realen Ferti-gungsanlage“ [1]. Dabei kommt es beson-ders auf die Realitätsnähe des benötigten digitalen Modells der Fertigungsanlage sowie der zu testenden Steuerungspro-gramme an. Das heißt, dass sich die an-hand des digitalen Modells (Bild 1) abge-

sicherten Programme später 1:1 in die reale Anlage übertragen lassen müssen, damit durch die Simulation keine zusätz-lichen Fehlerquellen entstehen. Diese Re-alitätsnähe des Modells wird so definiert, dass „aus Sicht der angeschlossenen (und zu testenden) Steuerungen kein Unter-schied zwischen Modell und Realität be-steht“ [2].

Aufgaben und Bestandteile des mechatronischen Anlagenmodells

In der notwendigen Forderung nach „Realitätsnähe“ des benötigten digitalen

Modells (mechatronisches Anlagenmo-dell) liegt zurzeit die größte Herausforde-rung. Um zu klären, wie man das Modell mit möglichst geringem Aufwand „reali-tätsnah“ macht, sind vor allem die „Be-obachter“ des mechatronischen Anlagen-modells zu betrachten.

Wie in Bild 1 dargestellt sind es im automobilen Karosserierohbau vor allem SPS, Robotersteuerungen und HMI (Hu-man Machine Interface), deren Program-me im Rahmen der virtuellen Inbetrieb-nahme abzusichern sind. Diese Steuerun-gen beobachten bzw. beeinflussen den Fertigungsprozess mittels Sensoren und Aktoren, die über Signale mit den Steue-rungen kommunizieren. Für das mecha-tronische Anlagenmodell bedeutet dies, dass das logische und das zeitliche Sig-nalverhalten der Sensorik/Aktorik simu-liert werden muss. Dieser Bestandteil des

2

Dipl.-Ing. Lorenz Hundt,Otto-von-Guericke-Universität Magdeburg,

Magdeburg.

E-Mail: lorenz.hundt@ovgu.de

Dipl.-Ing. Stephan Höme, Otto-von-Guericke-Universität Magdeburg,

Magdeburg.

E-Mail: stephan.hoeme@ovgu.de

Dipl.-Ing. Martin Bergert, Otto-von-Guericke-Universität Magdeburg,

Magdeburg.

E-Mail: uni-magdeburg.bergert@daimler.com

Verhaltensmodellierung für die virtuelle Inbetriebnahme

Die virtuelle Inbetriebnahme erfordert ein mechatronisches Modell der realen Fertigungsanlage, das diese in allen untersuchungsrele­vanten Eigenschaften abbildet. Insbesondere gilt dies für das Ver­halten des Modells inklusive unterlagerter Aktorik und Sensorik gegenüber den angeschlossenen Steuerungen. Dieser Beitrag fasst die Grundlagen für die Verhaltenssimulation mit integrierten Bewe­gungsgleichungen zusammen und beschreibt die erforderliche Kopplung zwischen Verhalten und Kinematik für eine 3­D­Simulation. Als wesentliche Neuerung wird die Integration der Untersuchungser­gebnisse in das Datenaustauschformat „AutomationML“ beschrieben.

Martin Bergert • Stephan Höme • Lorenz Hundt

Bild 1. Die Architektur der virtuellen Inbetriebnahme (in Anlehnung an [1] und [3])

Bibliotheken

Mechatronisches Anlagenmodell

Roboterprogramm(e) SPS-Programm HMI-Code

HMISPSRobotersteuerung

Kommunikationsschnittstellen

VM KGM

VM: Verhaltensmodell KGM: Kinematik-Geometrie-Modell

Fertigungs- & Maschinenautomation

4 Heft 9/2010•

mechatronischen Anlagenmodells wird im Weiteren als Verhaltensmodell (VM) bezeichnet.

Mithilfe des Verhaltensmodells allein ließe sich eine virtuelle Inbetriebnahme bereits durchführen, da alle für den Ab-lauf der Steuerungsprogramme erforder-

lichen Signale vorhanden sind. Aller-dings fällt es dem menschlichen Beob-achter in der Regel schwer, den Ablauf eines Fertigungsprozesses nur anhand des Signalverlaufs zu beurteilen. Zur bes-seren Veranschaulichung ist also zusätz-lich ein visueller Bestandteil des mecha-

tronischen Anlagenmodells erforderlich, der die Bewegungen der Betriebsmittel und den Ablauf des Fertigungsprozesses für den Menschen erfassbar macht. Die-ser Modellbestandteil wird im Weiteren als Kinematik-Geometrie-Modell (KGM) bezeichnet. Zusammen bilden das Ver-haltens- und das Kinematik-Geometrie-Modell das mechatronische Anlagenmo-dell für die virtuelle Inbetriebnahme. Für das VM bedeutet dies, dass zusätzlich zu den Steuerungseingängen auch die not-wendigen Bewegungen für die Darstel-lung im KGM zu berechnen sind.

Die ModellerstellungDer Gesamtaufwand für die virtuelle

Inbetriebnahme hängt im Wesentlichen von dem Aufwand für die Erstellung der benötigten Modelle ab. Für das KGM ist dieser Aufwand vernachlässigbar, da im heutigen Planungsprozess von Ferti-gungsanlagen (speziell im automobilen Karosserierohbau) in der Regel bereits 3-D-Modelle erstellt werden. Diese ent-halten neben der reinen 3-D-Geometrie auch vermehrt Kinematikinformationen die zum Beispiel für Zugänglichkeitsun-tersuchungen oder die Roboter-Offline-Programmierung benötigt werden.

Das VM wird im heutigen Planungspro-zess jedoch in der Regel nicht benötigt und ist zusätzlich zu erstellen. Um den geforderten Detaillierungsgrad zu errei-chen, sind hier verschiedene Strategien denkbar. So verfolgt beispielsweise die Daimler AG den Ansatz, die Verhaltens-modelle gemäß ihrem Steuerungstechnik-

Standard „integra“ auf-zubauen [4].

Dazu wird zu jedem standardisierten SPS-Funktionsbaustein ein entsprechendes VM entwickelt. Dieser An-satz ist pragmatisch aber vielversprechend, da dadurch sicherge-stellt wird, dass alle von der SPS steuer- und überwachbaren Funkti-onen im VM nachgebil-det sind. Die entschei-denden Nachteile bei diesem Ansatz sind zum einen der hohe Auf-wand für die Erstellung und die Pflege der VM (Anpassung an neue/veränderte Funktions-bausteine) und zum an-deren die Übernahme eventuell vorhandener

Bild 2. Das Bewegungsmodell eines Drehtischs

Drehtisch-Geometrie & Kinematik

DrehenVor=1 DrehenRück=1DrehenVor

DrehenRück

DrehenVor=0 DrehenRück=0vSoll

a1

T10

Drehtisch-Verhalten

Ruhe

a1 = 0dtd

Rückwärts

a1 = -vSolldtd

Vorwärts

a1 = vSolldtd

Ref

G1(a1)

K00

K11

Bild 3. Das stark vereinfache Modell eines Spanners und seiner Verhaltensbeschreibung in Form eines State Charts mit „AutomationML“

Parameter: vZurück, vVorwärts

Signale: öffnenEndlagenschalter-OffenschließenEndlagenschalter-ZuWeg

langsam

schnell

Öffnen

Zu

Auf

Schließen_langsam

Schließen_schnell

öffnen = TRUE/vVorwärts = 10

Endlagenschalter-Offen = TRUE/ vVorwaerts = 0

schließen = TRUE/vZurück = 10

Weg = 45°/vZurück = 5

Endlagenschalter-Zu = TRUE/vZurück = 0

Fertigungs- & Maschinenautomation

5 • Heft 9/2010

Fehler von den Funktionsbausteinen in die VM. Diese würden sich dann erst in der realen Inbetriebnahme durch uner-wartete Reaktionen der realen Betriebs-mittel bemerkbar machen.

Ein anderer Ansatz zur Erstellung von VM ist die Bereitstellung der jeweiligen Betriebsmittel durch den Hersteller [1], [2]. Dies hätte den Vorteil, dass die VM in ihrer Funktion tatsächlich den realen Be-triebsmitteln entsprechen und beim An-wender kein Zusatzaufwand für die Mo-dellerstellung entsteht. Dazu ist es jedoch erforderlich, VM unabhängig von kon-kreten Softwarewerkzeugen zur virtuel-

len Inbetriebnahme beschreiben zu kön-nen, da sonst der Betriebsmittelhersteller unter Umständen für jeden seiner Kun-den ein separates Modell bereitstellen müsste. Untersuchungen haben ergeben, dass sich besonders hybride State Charts zur Verhaltensmodellierung eignen, da dort neben dem diskreten Verhalten auch kontinuierliche Gleichungen für die Be-wegungsdarstellung im KGM modelliert werden können [1]. Mit dem Ansatz der systemneutralen Verhaltensmodellierung lässt sich der Aufwand für die Modeller-stellung zur virtuellen Inbetriebnahme voraussichtlich signifikant verringern.

Kopplung von Verhaltensmodell und Kinematik­Geometrie­Modell

Im Planungsprozess von Karosse-rierohbauanlagen sind detaillierte 3-D-Geometriemodelle Stand der Technik. Zudem existieren verschiedene standar-disierte Datenformate für den Austausch von Geometrieinformationen, wie Step und VRML. Auch zum Austausch von Kinematikinformationen zwischen ver-schiedenen Softwarewerkzeugen laufen bereits Standardisierungsbemühungen. Ein Beispiel dafür ist die „AutomationML“-Initiative [5]. Um jedoch den Anforde-rungen der virtuellen Inbetriebnahme gerecht zu werden, muss zusätzlich zu der reinen Beschreibung der Geometrie und der Kinematik auch die Kopplung zum Verhaltensmodell integriert werden.

Gegenstand der Kinematik ist die Be-schreibung der Lagen und der Bewegun-gen von Punkten und Körpern mit Mit-teln der analytischen Geometrie. Dabei spielen weder physikalische Körpereigen-schaften noch Kräfte als Ursachen von Tabelle 1. Schnittstelle zwischen KGM und dem Verhaltensmodell [7]

Information Richtung HäufigkeitGelenkparameter VM -> KGM zyklischVerknüpfung von kinematischen Ketten VM -> KGM bei BedarfSensordaten (kollisionsbasiert) VM <- KGM zyklischGrenzwerte der Gelenke VM <- KGM einmalig

6 Heft 9/2010•

Fertigungs- & Maschinenautomation

Bewegungen eine Rolle [6]. Das Kinema-tikmodell eines Betriebsmittels beschreibt sämtliche Bewegungsmöglichkeiten, das heißt die Freiheitsgrade, sowie dabei auf-tretende Grenzwerte. Im Modell wird das Betriebsmittel dabei in der Regel als Ver-kettung von starren Körpern und Gelen-ken abgebildet.

Jedes Gelenk kann physikalisch bis zu sechs Freiheitsgrade besitzen (drei trans-latorische und drei rotatorische). Nach dem Superpositionsprinzip können diese aber als eine Aneinanderreihung von Ge-lenken mit je einem Freiheitsgrad be-trachtet werden. Somit sind nur zwei Gelenktypen notwendig: das Schubge-lenk und das Drehgelenk.

Jedes dieser Gelenke besitzt einen Gelenkparameter (Weg oder Winkel), welcher die momentane Auslenkung be-schreibt. Mit diesen Parametern lässt sich die aktuelle Lage der Teilkörper berech-nen, die zur 3-D-Darstellung notwendig ist. Zusätzlich sind im Kinematik-Geo-metrie-Modell Grenzwerte für die Aus-lenkung, die Geschwindigkeit und die Beschleunigung der Gelenke zu definie-ren [7].

Bewegungsgleichungen im Verhaltensmodell

Die Abbildung der Bewegungen eines Betriebsmittels im VM erfolgt in Form von Bewegungsgleichungen. Dadurch können in Abhängigkeit des jeweiligen Verhaltenszustands eines Betriebsmittels verschiedene Bewegungsgleichungen im-plementiert werden – zum Beispiel schnelle oder langsame Bewegung. Be-wegungsgleichungen sind im Allgemei-nen Differenzialgleichungen oder deren Systeme, welche die zeitliche Verände-rung der Gelenkparameter des Kinema-tikmodells beschreiben. Bild 2 zeigt bei-spielhaft das grundlegende VM eines Drehtischs mit den Bewegungsgleichun-gen für die Vorwärts- und die Rückwärts-drehung.

Durch die Verwendung der Bewe-gungsdifferenzialgleichungen in hybri-den State Charts können komplexe Bewe-gungsabläufe in Teilbewegungen zerlegt und einzeln beschrieben werden. So las-sen sich zum Beispiel Positioniervorgän-ge als Verkettung einer beschleunigten, einer gleichförmigen und einer verzöger-ten Bewegung abbilden.

Bild 4. Die Funktionsbeschreibung mit AutomationML

Weg

tt

Weg

Beschreibungsmöglichkeiten: Benötigte Beschreibungsmöglichkeiten fürdie virtuelle Inbetriebnahme:

Bild 5. Die Beschreibungsmittel für kontinuierliche Funktionen

a) Hybride State Chart b) Beispiel MathML

Z1

= 0dtdx

Z2

= 100 ·

1

a

b

dtdx

T∫ f (x)dx

<math> <apply> <int/> <bvar> <ci>x</ci> </bvar> <apply> <fn> <ci>f</ci> </fn> <ci>x</ci> </apply> </apply> </math>

Fertigungs- & Maschinenautomation

7 • Heft 9/2010

Schnittstelle zwischen beiden Modellen

Aus der oben beschriebenen Modelllie-rung der Bewegungsgleichungen im VM ergibt sich die Notwendigkeit, eine Schnittstelle zwischen diesem und dem KGM zu definieren. Die Gelenkparameter werden in den Bewegungsgleichungen des VM berechnet und zyklisch mit je-dem Simulationsschritt an das KGM übertragen. Die im KGM gespeicherten Grenzwerte der Gelenke sind zu Beginn der Simulation einmalig an das VM zu übermitteln, um hier für die Berechnung der Bewegungsabläufe genutzt werden zu können. Daneben müssen Daten über die Verknüpfung von kinematischen Ket-ten vom VM zum KGM übertragen wer-den, beispielsweise um den Greifvorgang eines Roboters abzubilden. Das KGM kann kollisionsbasierte Sensoren, wie Näherungsschalter oder Lichtschranken, enthalten [7]. Deren Daten sind nach je-dem Rechenschritt von KGM ins VM zu übermitteln. Eine Übersicht der zwischen

VM und KGM auszutauschenden Daten bietet Tabelle 1.

Mithilfe dieser definierten Schnittstelle ist es möglich, alle für die virtuelle Inbe-triebnahme benötigten Daten zwischen VM und KGM auszutauschen. Auf Seiten der Geometrie und der Kinematik sind bereits alle benötigten Inhalte in der Spe-zifikation des neutralen Datenaustausch-formats „AutomationML“ enthalten. Für die Berechnung der hier geforderten kon-tinuierlichen Bewegungsgleichungen im Verhaltensmodell fehlen stand heute je-doch wesentliche Elemente in „Automa-tionML“.

Notwendige Erweiterung Die „AutomationML“-Initiative ent-

stand unter der Zielsetzung, den Daten-austausch zwischen verschiedenen Pla-nungs- und Engineeringwerkzeugen zu vereinfachen. Die Entwicklung begann in einem von der Firma Daimler [8] initiier-ten Industriekonsortium gemeinsam mit Siemens [9], ABB [10], Rockwell [11],

Kuka [12], Netallied [13], Zühlke [14] sowie den Universitäten Magdeburg [15] und Karlsruhe [16]. Das Datenformat ver-steht sich als „Schritt in Richtung der Vision einer nahtlosen Wertschöpfungs-kette in einer heterogenen Werkzeug-landschaft“ [17]. In „AutomationML“ sollen die übergeordneten Zusammen-hänge zwischen Anlagentopologie, Ver-halten, Geometrie, Kinematik sowie Refe-renzen und Relationen durch ein „freies, herstellerneutrales, offenes und standar-disiertes Datenformat“ [17] beschrieben werden.

Das XML-basierte Datenaustauschfor-mat bietet eine umfassende Möglichkeit verschiedene Beschreibungsmittel bzw. -modelle zur Verhaltensbeschreibung ab-zubilden. Dabei werden im Datenformat zwei Arten von Verhalten unterschieden: • Das Sequencing genannte gesteuerte

Verhalten wird zum Beschreiben des gewünschten und durch Steuerungs-eingriffe beeinflussten Verhaltens einer Produktionsanlage oder eines Betriebs-

Fertigungs- & Maschinenautomation

8 Heft 9/2010•

mittels in dieser Anlage verwendet.

• Das Behaviour genannte ungesteuerte Verhalten ist die Beschreibung des bereitgestellten und von der unterlagerten Physik bewirkten Verhaltens [5]

Als Speicherformat für Ver-haltensbeschreibungen ver-wendet „AutomationML“ das Datenformat PLCopen XML [17]. Hierzu werden die Logikmodelle, welche zum Beispiel das ungesteu-erte Verhalten einer Kom-ponente spezifizieren, in die SFC-Repräsentation der PLCopen XML entspre-chend definierter Transfor-mationsregeln abgelegt. Durch die Nutzung von so-genannten „AddData“-Ele-menten können die Limi-tierungen, welche das PLCopen XML-Schema zur Speicherung einzelner Mo-delle aufweist, aufgehoben werden.

Der in Bild 3 dargestellte Spanner ist ein typisches Beispiel für Betriebsmittel, deren Verhalten für die virtuelle Inbetriebnahme modelliert und ausgetauscht werden muss. Mit der aktu-ellen Version ist dies in „AutomationML“ nur bedingt möglich, da man nur diskre-te Zustandsänderungen über das Setzen von Parametern beschreiben kann. Bisher gibt es keine definierten Möglichkeiten,

kontinuierliche Funktionen, die inner-halb eines Zustands ausgeführt werden, mit Mitteln der „AutomationML“ zu spei-chern. Auf der linken Seite von Bild 4 ist die Weg-Zeit-Funktion des Beispiel-Spanners abgebildet, wie sie bisher mit den Mitteln der „AutomationML“ abge-legt werden kann. Daneben steht eine kontinuierliche Weg-Zeit-Funktion, wie

sie für die virtuelle Inbetriebnahme erfor-derlich ist.

ErweiterungsansatzEin möglicher Ansatz, um diese Be-

schreibungsform in das Datenaustausch-format „AutomationML“ zu integrieren ist, eines der Modelle, für die bereits Transformationsregeln nach PLCopen

Bild 6. Der Ausschnitt eines PLCopen XML-Dokuments beschreibt einen Zustand (Step) mit dem Namen „Schliessen_schnell“

...<step globalId=“ID120410“ localId=“9“ width=“16“ height=“4“ name=“Schliessen_schnell“> <position x0“34“ y=“42“/> <connectionPointIn> <relPosition x=“7“ y=“-2“/> <connection refLocalId=“10“/> <connectionPointIn> <connectionPointOut formalParameter=“sfc“> <addData> <data handleUnknown=“Implemetation“ name=“AutomationML PLCopen_Schema.xsd“> <AutomationML> <MathMLDescription> <math> <apply> <int/> <bvar> <ci>x</ci>> <bvar> <apply> <fn> <ci>f</ci> </fn> <ci>x<7ci> </apply> </apply> </math> </MathMLDescription> </AutomationML> </data> </addData> <relPosition x=“7“ y=“6“/> </connectionPointOut></step>...

Neues Element im AutomationML AddData-Schema

Verweis auf das AutomationML AddData-Schema

MathML Ausdruck zur Funktionsbeschreibung

9 • Heft 9/2010

XML existierten, um ein XML-basiertes Austauschformat zur Beschreibung kontinuierlicher Funktionen zu erweitern. Hierfür bietet sich die Erweiterung der State Chart-Beschreibung zu den hybriden State Charts an (Bild 5a). Als mögliches XML-Format zur Beschreibung von kontinuierlichen Funktionen bietet sich die Verwendung von „MathML“ an (Bild 5b).

Die Nutzung des Mechanismus der State Chart-Erweiterung zeigt Bild 6. Laut der in „AutomationML“ definierten Transfor-mationsregel entspricht der Programmausschnitt einem State Chart-Zustand. In dem XML-Element „AddData“ wird dieser um die „AutomationML“-spezifischen Beschreibungen erweitert. Der hervorgehobene Kasten zeigt dabei die in „MathML“ hin-terlegte Funktion, welche in dem entsprechenden Zustand ausgeführt werden soll und somit zur virtuellen Inbetriebnahme genutzt werden kann. Durch diese Erweiterung lassen sich die Anforderungen aus der virtuellen Inbetriebnahme an die Ver-haltensbeschreibung in „AutomationML“ umsetzen. Das ermög-licht es ausreichend detaillierte Modelle in einem neutralen Datenformat zu beschreiben und auszutauschen.

Zusammenfassung und AusblickDer Beitrag zeigt, dass die Erstellung und der Austausch der

einzelnen Modellbestandteile in einem herstellerunabhängigen Datenformat den Aufwand für die virtuelle Inbetriebnahme deutlich reduzieren können. Als ein Beispiel wurde das Daten-format „AutomationML“ und die für die virtuelle Inbetriebnah-me erforderlichen Erweiterungen der bisherigen Spezifikation beschrieben. Als nächsten wichtigen Schritt sehen die Autoren die Einbeziehung der Betriebsmittelhersteller in den Gesamtpro-zess „Virtuelle Inbetriebnahme“ an. Denn nur wenn diese sich intensiv an der Bereitstellung der erforderlichen Modelle betei-ligen, wird sich die Technologie als digitale Absicherungsme-thode flächendeckend durchsetzen können.

Literatur

[1] Kiefer, J.; Ollinger, L.; Bergert, M.: Virtuelle Inbetriebnahme – Standardi-sierte Verhaltensmodellierung mechatronischer Betriebsmittel im automo-bilen Karosserierohbau. atp – Automatisierungstechnische Praxis (2009) H. 7

[2] Bergert, M.; Diedrich, C.: Durchgängige Verhaltensmodellierung von Be-triebsmitteln zur Erzeugung digitaler Simulationsmodell von Fertigungs-zellen. atp – Automatisierungstechnische Praxis (2008) H. 7

[3] Bergert, M.; Kiefer, J.; Höme, S.; Fedrowitz, C.: Einsatz der Virtuellen In-betriebnahme im automobilen Karosserierohbau – Ein Erfahrungsbericht. 9. Magdeburger Maschinenbau-Tage (2009), S. 388-397

[4] Bangerth, V.; Schäfer, K.: Digitale Produktionsentwicklung im Rohbau der Daimler Truck Group. Fachkongress Digitale Fabrik 2009, München

[5] Drath, R. (Hrsg.): Datenaustausch in der Anlagenplanung mit Automati-onML. Berlin: Springer-Verlag, 2009 (ISBN-10: 3642046738)

[6] Czichos, H.; Hennecke, M.: Hütte – Das Ingenieurwesen. Berlin: Springer Verlag, 2007 (ISBN-10: 3540203257)

[7] Höme, S.; Bergert, M.; Diedrich, Ch.: Integration von Kinematik- und Verhaltensmodellierung in mechatronischen Modellen für die Virtuelle In-betriebnahme. 11. Fachtagung „Entwurf komplexer Automatisierungssys-teme“, Magdeburg, 2010

[8] Daimler AG, Stuttgart: www.daimler.de[9] Siemens AG, München: www.siemens.de[10] ABB AG, Mannheim: www.abb.de[11] Rockwell Automation, Milwaukee, Wisconsin/USA:

www.rockwellautomation.com[12] Kuka AG, Augsburg: www.kuka-ag.de[13] Netallied Systems GmbH, Ravensburg: www.netallied.de[14] Zühlke Engineering AG, Schlieren/Schweiz: www.zuehlke.com[15] Otto-von-Guericke-Universität Magdeburg: www.uni-magdeburg.de[16] Universität Karlsruhe: www.uni-karlsruhe.de[17] Drath, R.; Miegel, V.: AutomationML verbindet Werkzeuge der Anlagen-

planung. atp – Automatisierungstechnische Praxis (2009) H. 7 n