AutomationML: Verhältnismäßig gut!

Voraussetzung für die Simulation ist das Vorhandensein entsprechender simulierbarer Modelle, die neben der Geometrie und Kinematik auch das Verhalten der Systemkomponenten beschreiben. Die Anbieter von Systemkomponenten geben derzeit das Verhalten ihrer Komponenten in einem Handbuch mit oder sie bieten spezifische Module für die einzelnen Simulationswerkzeuge an. Die Möglichkeit, das Verhalten in einer neutralen Sprache zu beschreiben, würde sie unabhängig von dem vom Auftraggeber genutzten Simulationswerkzeug machen, vorausgesetzt eine Überführung in dieses Werkzeug ist möglich. Zudem können Bibliotheken von Systemkomponenten entstehen, die für verschiedene Simulationsziele unterschiedliche Modelle der Systemkomponenten bereitstellen, die der Wissenssicherung dienen und die Wiederverwendbarkeit dieser Systemkomponenten vereinfachen. Derartige Bibliotheken könnten aus unterschiedlichen Quellen gespeist werden. Kandidaten dafür sind neben den Systemintegratoren auch Komponenten- und Gerätelieferanten. Dieser Artikel soll zeigen, dass AutomationML sowohl zum neutralen Austausch von Verhaltensinformationen geeignet ist als auch die Voraussetzung für eine Bibliotheksbildung erfüllt.

Ein Beispiel

Für ein besseres Verständnis soll an dieser Stelle ein Antriebsstrang betrachtet werden, wie er in Teil 5 dieser Artikelserie bereits vorgestellt wurde. Dieser soll einen Antrieb mit einer vereinfachten Antriebssteuerung enthalten. Dieser Antrieb kann sowohl im Rechts- als auch im Linkslauf betrieben werden und unterstützt zwei Geschwindigkeiten. Dabei darf er aus dem Stillstand in den Links- oder Rechtslauf gestartet werden. Zwischen den beiden Geschwindigkeiten darf innerhalb derselben Laufrichtung jederzeit gewechselt werden. Um den Antrieb allerdings aus der einen Laufrichtung in die andere zu schalten, muss er zunächst angehalten werden. Wird versucht den Antrieb vom Rechts- direkt in den Linkslauf zu schalten (oder umgekehrt), wird dies ignoriert und ein Fehlerstatus gesetzt, der zurückgesetzt werden kann. Hieraus ergeben sich die Eingänge der Steuerung, wie sie in Bild 6 zusammengefasst sind. Während des Betriebs sollen von der Antriebssteuerung zwei Informationen abgefragt werden können. Zum einen soll die aktuelle Geschwindigkeit und zum anderen der aktuelle Fehlerstatus ausgelesen werden können. Die sich daraus ergebenden Ausgänge der Steuerung sind in Bild 7 zusammengefasst. Das Verhalten dieser Steuerung lässt sich nach IEC61131-3 als Funktionsblockdiagramm (FBD) beschreiben und ist in Bild 1 zu sehen.

Herstellerunabhängige Komponentenbeschreibung

Für eine hersteller- und technologieunabhängige Beschreibung des Antriebstrangs kann AutomationML eingesetzt werden. Dazu werden CAEX zur Beschreibung der Komponentenstruktur und dazugehörige Schnittstellen und PLCopen XML zur Beschreibung des Komponentenverhaltens verwendet. In CAEX werden, wie in Bild 2 zu sehen, die einzelnen Geräte zu einer Gerätestruktur als Hierarchie von InternalElements zusammengefasst und bilden damit eine Komponente. In Bild 2 sind beispielhaft die Antriebsstränge SimpleDriveControl und AdvancedDriveControl gezeigt, die jeweils eine Komponente bilden und einen Antrieb, eine Antriebssteuerung und die Applikationsbeschreibung enthalten. Die einzelnen InternalElements der Hierarchie können notwendige Eigenschaften als Attribute enthalten. Zudem wird aus CAEX heraus auf PLCopen XML Dateien verwiesen, um darüber die Verhaltensbeschreibungen einzubinden. Wie Bild 3 verdeutlicht, dienen dazu entsprechende ExternalInterface Elemente, die auf Objekte (ganze POEs oder einzelne Variablen) in den PLCopen XML Dateien verweisen.

PLCopen XML

Das FBD ist eine der fünf in der IEC61131-3 definierten Sprachen zur Programmierung von Speicherprogrammierbaren Steuerungen (SPS). PLCopen XML wurde entwickelt, um die Steuerungslogik gemäß IEC61131-3 in einem herstellerunabhängigen Format abbilden zu können. Ähnlich wie in der grafischen Repräsentation in Bild 1 wird in PLCopen XML jeder einzelne Funktionsbaustein als eigenes Element beschrieben. Die Eingangs- bzw. Ausgangsvariablen werden durch die Elemente und modelliert und die einzelnen Funktionsblöcke, die nach IEC61131-3 standardisiert sind, durch die Elemente dargestellt. Die einzelnen Funktionsblöcke und Variablen werden nun über sogenannte Konnektoren miteinander verbunden, wodurch sich die Antriebssteuerung vollständig in der neutralen Sprache PLCopen XML modellieren lässt. Ein Ausschnitt aus der resultierenden Beschreibung ist in Bild 4 zu sehen. Um festzustellen, ob diese Darstellung auch für den herstellerunabhängigen Datenaustausch geeignet ist, muss untersucht werden, wie die gleiche Steuerung in einem Simulationssystem zu modellieren und ob eine automatische Überführung der Darstellungen möglich ist.

Seiten: 1 2 3Auf einer Seite lesen