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.

Process Simulate

Für diese Untersuchungen soll das Simulationssystem Process Simulate beispielhaft herangezogen werden. Es ist ein Repräsentant einer Werkzeugklasse, für die nach Ansicht der Autoren die nachfolgenden Aussagen ebenso zutreffen. Für die Beschreibung einer Steuerung steht im Simulationssystem Process Simulate ein Editor zur Verfügung, mit dessen Hilfe sich Eingänge, Ausgänge und Parameter definieren lassen. Eingängen und Ausgängen können Datentypen zugewiesen werden. Parameter definieren Funktionen, die aus n Variablen ein Ergebnis ermitteln. Als Variablen dienen entweder die Eingänge oder die Ergebnisse von anderen Parametern. Als Funktionen stehen neben arithmetischen und booleschen Operationen auch einige vordefinierte Funktionen wie z.B. \’RisingEdge\‘, \’FallingEdge\‘ oder \’SetReset\‘ zur Verfügung. Diese stellen ein Subset der in der IEC61131-3 standardisierten FBD Bausteine zur Beschreibung von Steuerungsverhalten dar. Gespeichert wird das Verhalten in einer XML Datei. Ein Blick in die erzeugte Datei (siehe Bild 5) zeigt, dass hier die Eingänge und Ausgänge sowie die einzelnen Funktionsblöcke in Listen gespeichert und über ihre IDs miteinander verknüpft werden.

Beliebig austauschbar!

Im direkten Vergleich ist ein analoger Aufbau der beiden XML Formate zu erkennen.

• Die Daten werden in Eingänge, Ausgänge und Funktionen bzw. FBD Bausteinen gruppiert.
• Eingänge sind die Variablen der Funktionen.
• Das Ergebnis einer Funktion ist entweder eine Variable für eine folgende Funktion oder der Wert eines Ausgangs.
• Alle Funktionen entsprechen denen in der IEC61131-3 beschriebenen.

Der Informationsgehalt in beiden Formaten ist somit identisch. Da es sich bei beiden Formaten um XML Dokumente handelt, wäre eine Überführung im einfachsten Fall durch eine XML Transformation mittels XSLT möglich. Process Simulate bietet zwar nur ein Subset der in der IEC61131-3 beschriebenen Funktionen an, allerdings steht es dem Anwender frei über eine Plugin-Schnittstelle weitere Funktionen im Editor zur Verfügung zu stellen.

Aber sicher!

Dem Bestreben Daten herstellerneutral abzubilden steht auch immer der Wunsch gegenüber, den Inhalt vor dem Zugriff Unbefugter und vor nicht intendierter Veränderung abzusichern. In diesem Zusammenhang stellen sich im Wesentlichen zwei Fragen:

• Von wem sind die Daten und wurden sie auch nicht verändert?
• Wer darf die Daten sehen?

Die erste Frage beschäftigt sich also mit der Authentizität und der Integrität der Daten und die zweite mit dem Schutz vor Missbrauch. Beide Fragen sind so alt wie ihre Lösungsansätze. Authentizität und Integrität kann durch eine digitale Signatur gewährleistet und der Schutz vor Missbrauch kann durch Verschlüsselung erreicht werden. Welcher Standard dafür genutzt wird, sei es PKCS oder XML Signature/Encryption, ist reine Geschmackssache. Vielmehr sollte klar sein, welche Folgen die Nutzung von Verschlüsslungen bzw. Signaturen haben könnten. Eine digitale Signatur ist in jedem Fall sinnvoll. Die Daten sind lesbar, die Integrität kann jederzeit überprüft werden und die Entscheidung, ob der Signatur vertraut wird, kann frei getroffen werden. Sind die Daten hingegen (auch) verschlüsselt, so kann nur der vorgesehene Empfänger die Daten sehen. Wird eine Verschlüsselung als Transportsicherung für eine Übermittlung beispielsweise per Mail verwendet oder dient sie dem Wissensschutz bei einer Langzeitarchivierung, so ist dies mit Sicherheit sinnvoll. Hier muss jedoch für jeden Anwendungsfall genau überprüft werden, wer wann welche der verschlüsselten Informationen lesen bzw. verändern darf und wie ihm die dafür notwendigen Schlüssel zur Verfügung gestellt werden können. Insbesondere gilt dies, wenn der Empfänger ein Programm ist, das die Daten weiterverarbeitet. Hier muss durch alle Beteiligten sichergestellt sein, dass der Ansatz eines herstellerneutralen Datenformates nicht ad absurdum geführt wird. Für beide Anwendungsfälle, Verschlüsslungen und Signatur, sind für die Verarbeitung von XML Dateien entsprechende frei verfügbare Softwarekomponenten vorhanden, so dass ihre Anwendung nur vor organisatorischen, nicht jedoch vor technischen Herausforderungen steht.

Und nun?

Fasst man die beschriebenen Strukturen zusammen, so können herstellerunabhängige Bibliotheken wiederverwendbarer Systemkomponenten entstehen, die passend zu unterschiedlichen Anwendungsfällen Verhaltensmodelle enthalten. Diese Modelle können, wie erste Entwicklungsansätze zeigen, automatisch zur Erstellung von simulierbaren Anlagenmodellen kombiniert werden. Für deren Simulation könnte dann entweder auf bestehende Werkzeuge zurückgegriffen oder neue Simulationswerkzeuge unter Anwendung von IEC61131-3 basierten Soft-SPSen entwickelt werden. In beiden Fällen können insbesondere Komponentenlieferanten und Systemintegratoren profitieren. Erstere können sich durch die Bereitstellung von Simulationsmodellen einen Marktvorteil sichern und letztere können Wissen sichern und wiederverwenden und damit ihre Entwurfsqualität deutlich erhöhen.

((Kasten))