A A A
| Sitemap | Kontakt | Impressum | Datenschutz
ETZ Logo VDE Verlag Logo

Verhaltensmodellierung für die virtuelle Inbetriebnahme

Bild 1. Die Architektur der virtuellen Inbetriebnahme

Bild 2. Das Bewegungsmodell eines Drehtischs

Tabelle 1. Schnittstelle zwischen KGM und dem Verhaltensmodell

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

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

In den letzten Jahren wurden im Umfeld der automatisierten Fertigungstechnik große Anstrengungen unternommen, um die Methode der virtuellen Inbetriebnahme aus den Forschungseinrichtungen der Unternehmen in den produktiven Einsatz zu transferieren. Mittlerweile stellt sich nicht mehr die Frage, ob die virtuelle Inbetriebnahme eingesetzt werden soll, sondern wie effektiv sie eingesetzt werden kann. Schließlich lassen sich die Vorteile, wie Verkürzung der Inbetriebnahmezeit und weniger Produktionsausfälle durch qualitativ höherwertige Steuerungsprogramme, erreichen, wenn der zusätzliche Aufwand 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 Karosserierohbau – ist die frühzeitige Absicherung und Optimierung des Zusammenspiels von Anlagenmechanik und -elektrik sowie der Steuerungssoftware ohne das Vorhandensein der realen Fertigungsanlage. Dabei kommt es besonders auf die Realitätsnähe des benötigten digitalen Modells der Fertigungsanlage sowie der zu testenden Steuerungsprogramme an. Das heißt, dass sich die anhand des digitalen Modells (Bild 1) abgesicherten Programme später 1:1 in die reale Anlage übertragen lassen müssen, damit durch die Simulation keine zusätzlichen Fehlerquellen entstehen. Diese Realitätsnähe des Modells wird so definiert, dass aus Sicht der angeschlossenen (und zu testenden) Steuerungen kein Unterschied zwischen Modell und Realität besteht.

Aufgaben und Bestandteile des mechatronischen Anlagenmodells
In der notwendigen Forderung nach „Realitätsnähe“ des benötigten digitalen Modells (mechatronisches Anlagenmodell) liegt zurzeit die größte Herausforderung. Um zu klären, wie man das Modell mit möglichst geringem Aufwand „realitätsnah“ macht, sind vor allem die „Beobachter“ des mechatronischen Anlagenmodells zu betrachten.
Wie in Bild 1 dargestellt sind es im automobilen Karosserierohbau vor allem SPS, Robotersteuerungen und HMI (Human Machine Interface), deren Programme im Rahmen der virtuellen Inbetriebnahme abzusichern sind. Diese Steuerungen beobachten bzw. beeinflussen den Fertigungsprozess mittels Sensoren und Aktoren, die über Signale mit den Steuerungen kommunizieren. Für das mechatronische Anlagenmodell bedeutet dies, dass das logische und das zeitliche Signalverhalten der Sensorik/Aktorik simuliert werden muss. Dieser Bestandteil des 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 Ablauf der Steuerungsprogramme erforderlichen Signale vorhanden sind. Allerdings fällt es dem menschlichen Beobachter in der Regel schwer, den Ablauf eines Fertigungsprozesses nur anhand des Signalverlaufs zu beurteilen. Zur besseren Veranschaulichung ist also zusätzlich ein visueller Bestandteil des mechatronischen Anlagenmodells erforderlich, der die Bewegungen der Betriebsmittel und den Ablauf des Fertigungsprozesses für den Menschen erfassbar macht. Dieser Modellbestandteil wird im Weiteren als Kinematik-Geometrie-Modell (KGM) bezeichnet. Zusammen bilden das Verhaltens- und das Kinematik-Geometrie-Modell das mechatronische Anlagenmodell für die virtuelle Inbetriebnahme. Für das VM bedeutet dies, dass zusätzlich zu den Steuerungseingängen auch die notwendigen Bewegungen für die Darstellung im KGM zu berechnen sind.

Die Modellerstellung
Der 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 Fertigungsanlagen (speziell im automobilen Karosserierohbau) in der Regel bereits 3-D-Modelle erstellt werden. Diese enthalten neben der reinen 3-D-Geometrie auch vermehrt Kinematikinformationen die zum Beispiel für Zugänglichkeitsuntersuchungen oder die Roboter-Offline-Programmierung benötigt werden.
Das VM wird im heutigen Planungsprozess jedoch in der Regel nicht benötigt und ist zusätzlich zu erstellen. Um den geforderten Detaillierungsgrad zu erreichen, sind hier verschiedene Strategien denkbar. So verfolgt beispielsweise die Daimler AG den Ansatz, die Verhaltensmodelle gemäß ihrem Steuerungstechnik-Standard „integra“ aufzubauen.

Dazu wird zu jedem standardisierten SPS-Funktionsbaustein ein entsprechendes VM entwickelt. Dieser Ansatz ist pragmatisch aber vielversprechend, da dadurch sichergestellt wird, dass alle von der SPS steuer- und überwachbaren Funktionen im VM nachgebildet sind. Die entscheidenden Nachteile bei diesem Ansatz sind zum einen der hohe Aufwand für die Erstellung und die Pflege der VM (Anpassung an neue/veränderte Funktionsbausteine) und zum anderen die Übernahme eventuell vorhandener Fehler von den Funktionsbausteinen in die VM. Diese würden sich dann erst in der realen Inbetriebnahme durch unerwartete Reaktionen der realen Betriebsmittel bemerkbar machen.

Ein anderer Ansatz zur Erstellung von VM ist die Bereitstellung der jeweiligen Betriebsmittel durch den Hersteller. Dies hätte den Vorteil, dass die VM in ihrer Funktion tatsächlich den realen Betriebsmitteln entsprechen und beim Anwender kein Zusatzaufwand für die Modellerstellung entsteht. Dazu ist es jedoch erforderlich, VM unabhängig von konkreten Softwarewerkzeugen zur virtuellen Inbetriebnahme beschreiben zu können, da sonst der Betriebsmittelhersteller unter Umständen für jeden seiner Kunden 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 Bewegungsdarstellung im KGM modelliert werden können [1]. Mit dem Ansatz der systemneutralen Verhaltensmodellierung lässt sich der Aufwand für die Modellerstellung zur virtuellen Inbetriebnahme voraussichtlich signifikant verringern.

Kopplung von Verhaltensmodell und Kinematik-Geometrie-Modell
Im Planungsprozess von Karosserierohbauanlagen sind detaillierte 3-D-Geometriemodelle Stand der Technik. Zudem existieren verschiedene standardisierte Datenformate für den Austausch von Geometrieinformationen, wie Step und VRML. Auch zum Austausch von Kinematikinformationen zwischen verschiedenen Softwarewerkzeugen laufen bereits Standardisierungsbemühungen. Ein Beispiel dafür ist die AutomationML-Initiative. Um jedoch den Anforderungen 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 Beschreibung der Lagen und der Bewegungen von Punkten und Körpern mit Mitteln der analytischen Geometrie. Dabei spielen weder physikalische Körpereigenschaften noch Kräfte als Ursachen von Bewegungen eine Rolle. Das Kinematikmodell eines Betriebsmittels beschreibt sämtliche Bewegungsmöglichkeiten, das heißt die Freiheitsgrade, sowie dabei auftretende Grenzwerte. Im Modell wird das Betriebsmittel dabei in der Regel als Verkettung von starren Körpern und Gelenken abgebildet.

Jedes Gelenk kann physikalisch bis zu sechs Freiheitsgrade besitzen (drei translatorische und drei rotatorische). Nach dem Superpositionsprinzip können diese aber als eine Aneinanderreihung von Gelenken mit je einem Freiheitsgrad betrachtet werden. Somit sind nur zwei Gelenktypen notwendig: das Schubgelenk und das Drehgelenk.
Jedes dieser Gelenke besitzt einen Gelenkparameter (Weg oder Winkel), welcher die momentane Auslenkung beschreibt. Mit diesen Parametern lässt sich die aktuelle Lage der Teilkörper berechnen, die zur 3-D-Darstellung notwendig ist. Zusätzlich sind im Kinematik-Geometrie-Modell Grenzwerte für die Auslenkung, die Geschwindigkeit und die Beschleunigung der Gelenke zu definieren.

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 implementiert werden – zum Beispiel schnelle oder langsame Bewegung. Bewegungsgleichungen sind im Allgemeinen Differenzialgleichungen oder deren Systeme, welche die zeitliche Veränderung der Gelenkparameter des Kinematikmodells beschreiben. Bild 2 zeigt beispielhaft das grundlegende VM eines Drehtischs mit den Bewegungsgleichungen für die Vorwärts- und die Rückwärtsdrehung.
Durch die Verwendung der Bewegungsdifferenzialgleichungen in hybriden State Charts können komplexe Bewegungsabläufe in Teilbewegungen zerlegt und einzeln beschrieben werden. So lassen sich zum Beispiel Positioniervorgänge als Verkettung einer beschleunigten, einer gleichförmigen und einer verzögerten Bewegung abbilden.

Schnittstelle zwischen beiden Modellen
Aus der oben beschriebenen Modelllierung 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 jedem 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 Ketten vom VM zum KGM übertragen werden, beispielsweise um den Greifvorgang eines Roboters abzubilden. Das KGM kann kollisionsbasierte Sensoren, wie Näherungsschalter oder Lichtschranken, enthalten. Deren Daten sind nach jedem 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 Inbetriebnahme benötigten Daten zwischen VM und KGM auszutauschen. Auf Seiten der Geometrie und der Kinematik sind bereits alle benötigten Inhalte in der Spezifikation des neutralen Datenaustauschformats „AutomationML“ enthalten. Für die Berechnung der hier geforderten kontinuierlichen Bewegungsgleichungen im Verhaltensmodell fehlen stand heute jedoch wesentliche Elemente in „AutomationML“.

Bild 4. Die Funktionsbeschreibung mit AutomationML

Bild 5. Die Beschreibungsmittel für kontinuierliche Funktionen

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

Notwendige Erweiterung
Die „AutomationML“-Initiative entstand unter der Zielsetzung, den Datenaustausch zwischen verschiedenen Planungs- und Engineeringwerkzeugen zu vereinfachen. Die Entwicklung begann in einem von der Firma Daimler initiierten Industriekonsortium gemeinsam mit Siemens, ABB, Rockwell, Kuka, Netallied, Zühlke sowie den Universitäten Magdeburg und Karlsruhe. Das Datenformat versteht sich als Schritt in Richtung der Vision einer nahtlosen Wertschöpfungskette in einer heterogenen Werkzeuglandschaft. In AutomationML sollen die übergeordneten Zusammenhänge zwischen Anlagentopologie, Verhalten, Geometrie, Kinematik sowie Referenzen und Relationen durch ein freies, herstellerneutrales, offenes und standardisiertes Datenformat beschrieben werden.

Das XML-basierte Datenaustauschformat bietet eine umfassende Möglichkeit verschiedene Beschreibungsmittel bzw. -modelle zur Verhaltensbeschreibung abzubilden. Dabei werden im Datenformat zwei Arten von Verhalten unterschieden:
• Das Sequencing genannte gesteuerte Verhalten wird zum Beschreiben des gewünschten und durch Steuerungseingriffe beeinflussten Verhaltens einer Produktionsanlage oder eines Betriebsmittels in dieser Anlage verwendet.
• Das Behaviour genannte ungesteuerte Verhalten ist die Beschreibung des bereitgestellten und von der unterlagerten Physik bewirkten Verhaltens
Als Speicherformat für Verhaltensbeschreibungen verwendet AutomationML das Datenformat PLCopen XML. Hierzu werden die Logikmodelle, welche zum Beispiel das ungesteuerte Verhalten einer Komponente spezifizieren, in die SFC-Repräsentation der PLCopen XML entsprechend definierter Transformationsregeln abgelegt. Durch die Nutzung von sogenannten „AddData“-Elementen können die Limitierungen, welche das PLCopen XML-Schema zur Speicherung einzelner Modelle 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 aktuellen Version ist dies in AutomationML nur bedingt möglich, da man nur diskrete Zustandsänderungen über das Setzen von Parametern beschreiben kann. Bisher gibt es keine definierten Möglichkeiten, kontinuierliche Funktionen, die innerhalb eines Zustands ausgeführt werden, mit Mitteln der AutomationML zu speichern. Auf der linken Seite von Bild 4 ist die Weg-Zeit-Funktion des Beispiel-Spanners abgebildet, wie sie bisher mit den Mitteln der AutomationML abgelegt werden kann. Daneben steht eine kontinuierliche Weg-Zeit-Funktion, wie sie für die virtuelle Inbetriebnahme erforderlich ist.

Erweiterungsansatz
Ein möglicher Ansatz, um diese Beschreibungsform in das Datenaustauschformat AutomationML zu integrieren ist, eines der Modelle, für die bereits Transformationsregeln nach PLCopen 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 Transformationsregel 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“ hinterlegte 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 Verhaltensbeschreibung in AutomationML umsetzen. Das ermöglicht es ausreichend detaillierte Modelle in einem neutralen Datenformat zu beschreiben und auszutauschen.

Zusammenfassung und Ausblick
Der 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 Datenformat „AutomationML“ und die für die virtuelle Inbetriebnahme erforderlichen Erweiterungen der bisherigen Spezifikation beschrieben. Als nächsten wichtigen Schritt sehen die Autoren die Einbeziehung der Betriebsmittelhersteller in den Gesamtprozess „Virtuelle Inbetriebnahme“ an. Denn nur wenn diese sich intensiv an der Bereitstellung der erforderlichen Modelle beteiligen, wird sich die Technologie als digitale Absicherungsmethode flächendeckend durchsetzen können.

Der Beitrag als pdf

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

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

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