Bild 1. Die Abbildung aus dem nxtControl-Engineering-Werkzeug zeigt die Execution-Control-Chart, also die Zustandsmaschine eines Gerätes im Testmodus. Der rote Punkt ganz links im Bild stellt einen Breakpoint dar.

© nxtControl

Die Objektorientierung der IEC 61499 hat ebenfalls ein Interface, welches für die Verteilbarkeit um Events erweitert wurde. Methoden werden hier als Algorithmen bezeichnet, die durch ein grafisches Zustandsdiagramm (ECC = Execution Control Chart) den Zusammenhang zwischen den Events und den auszuführenden Algorithmen beschreiben. Dies verbessert die Lesbarkeit von solchen Bausteinen erheblich. Ableitung und Vererbung in der Form der IEC 61131 sind hingegen nicht vorhanden. Stattdessen wird dem Anwender die Möglichkeit der Typ-in-Typ-Verschachtelung (Composite FunctionBlock) geboten.

Objektorientierung wie sie schließlich bei nxtControl umgesetzt wurde, besteht aus einem Objektmodell, das die Kapselung von Daten (IEC-61499-Variable) und Methoden (Algorithmen, Funktionsblock-Netzwerke) über ein definiertes Interface – das Event-Daten-Interface – erweitert, um zusätzliche Aspekte der Automation zu integrieren. Das heißt: Neben der Steuerungslogik werden hier die Visualisierung HMI/SCADA (Symbole, Faceplates, Scripting, Alarme und Trends), die Anbindung der I/Os an die reale Welt, eine automatisierte Dokumentation und selbst eine IEC-61131-Programmierung nahtlos integriert.

Bild 2. Zwei Ansichten desselben Gerätes: Oben die visuelle Darstellungsform und unten die Steuerungslogik .

© nxtControl

Dabei entspricht die Steuerungslogik selbst vollständig der IEC 61499. Die Visualisierung ist in .Net/C# umgesetzt und lässt sich zum Großteil per Drag&Drop automatisch erzeugen. Die I/O-Anbindung erfolgt ebenfalls mit Bibliotheksfunk­tionen der IEC 61499. Der vierte Aspekt, die Hardware-Konfiguration, wird mit C#-Mitteln erfüllt. Damit werden antei­lige I/O-Hardware-Konfigurationsdaten erstellt (Hardware-Abstraktion). Die anteilige Dokumentation schließlich ist im DocBook-Standard umgesetzt und lässt sich damit automatisch in ein zentrales Gesamtdokument überführen.

Das so erweiterte Objektmodell wird benutzt, um reale Geräte (mechatronische Komponenten, Teilapplikationen oder Automatisierungshardware) als Software-Objekte abzubilden. Diese Objekt- und Aspektorientierung ist nicht zu verwechseln mit der semantischen Objektorientierung, beschrieben in der Norm IEC 61131-3:2003!

Trennung von Soft- und Hardware

Ein weiteres grundlegendes Konzept der IEC 61499 ist die Hardware-Abstrak­tion. Diese trennt die Software-Applikation von den eingesetzten Automatisierungsgeräten. Das führt zu weitreichender Wiederverwendbarkeit von einmal realisierten Lösungen. Im Engineering-Werkzeug wird dazu eine Applikation erstellt und in normkonformen XML gespeichert. Erst beim Laden der Applikation in die Steuerung(en) wird die Applikation mittels eines Just-in-time-Compilers in maschinenlesbaren Code umgesetzt.

Das erwähnte Objektmodell wird auch auf die Steuerungshardware angewendet. Mit anderen Worten: Steuerungen werden ebenso als Software-Objekte dar­gestellt wie andere Geräte. Diese Möglichkeit dient dazu, hersteller- oder feldbusspezifische I/O-Anschalttechnologien in eine standardisierte Softwareschnittstelle zu konvertieren. Ein Beispiel hierfür ist die Umwandlung von elektrischen Signalen in ingenieurmäßige Einheiten – zum Beispiel 4 bis 20 mA auf 0 bis 100 % des Drucks oder der Temperatur. Auch komplexere Schnittstellen wie etwa für Mo­tion-Control (Position, Geschwindigkeit) sind damit realisierbar. Die Anbindung an das I/O-System erfolgt über herstellerspe­zifische Rückwandbusse oder Feldbusse wie Ethercat, Profibus oder auch Modbus.

Komplexität beherrschbar gemacht

Wie schon erwähnt, reduziert das Objektmodell die Komplexität auf ein Minimum. Daneben kommen andere technische Kniffe zum Einsatz, um das Engineering im verteilten System einfach zu halten. So werden die Kommunikationspfade zwischen den einzelnen Steuerungen komplett automatisiert hergestellt, ohne Eingriff eines Programmierers. Dasselbe passiert bei den Kommunikationspfaden zwischen den einzelnen Steuerungen und den einzelnen Visualisierung-Clients. Es gibt somit keine „Tag“-Listen, die zu verknüpfen sind. Einfaches Engineering in Vollendung stellt schließlich das Single-Line-Engineering dar: Einzelne Software-Objekte werden hier nur noch mit einfachen, aber „intelligenten“ Linien verbunden.

Das Konzept der Interoperabilitäts-Schnittstelle der IEC 61499 basiert auf Publish-Subscriber-Funktionsblöcken, welche in einer Peer-to-Peer-Beziehung den Datenaustausch zwischen den Devices ermöglichen. Diese Prozedur ist sehr komplex, arbeitsintensiv und erfordert viel Know-how. Hier haken die Kritiker ein und bezeichnen diese Prozedur als für den Anwender unzumutbar. Sie übersehen dabei aber, dass es dafür durchaus kreative Lösungen gibt – und zwar eben die vollautomatische Erstellung der Kommunikationsanwendung im FunctionBlock-Netzwerk. Eine solche Lösung entlastet nicht nur den Anwender, sondern beseitig auch viele Fehlerquellen.

Unter anderem zeigen sich in diesem Punkt die Vorteile der IEC 61499. Mit der IEC 61131 sind solche Automatismen wegen der Aliasing-Effekte durch Unsynchronität zwischen Datenübertragung und Programmbearbeitung nicht umsetzbar.

Das Neue mit dem Alten verbunden

Wenn auch mittlerweile viele Hersteller und Anwender ausgesprochen positiv auf die neuartigen Möglichkeiten der IEC 61499 reagieren, so kommt in den Diskussionen so sicher wie das „Amen in der Kirche“ das Argument, dass die vielen bestehenden IEC-61131-Lösungen nicht einfach aufgegeben werden können. Zu Recht: Denn was an IEC-61131-Lösungen existiert, repräsentiert eine Unmenge an Programm-Code. Der wichtigere Aspekt ist jedoch das Know-how über die Anwendung – hier verteidigt man aber das Buch und nicht den Buchinhalt.

Bild 3. Der „gemeinsame Nenner“ beider Normen ist ein IEC-61499-Basic-FunctionBlock (BasicFB), welcher als Algorithmussprache die IEC-61131-Sprachmittel nutzen kann.

© nxtControl

Die Lösung dieses „Zwiespalts“ besteht darin, mit einem einzigen Engineer­ing-Werkzeug Applikationen sowohl in IEC 61499 als auch in IEC 61131 zu entwickeln. So geschehen bei nxtControl: Nachdem hier zuerst eine reine IEC-61499-Lösung geschaffen wurde, um deren Stärken zur vollen Wirkung zu bringen, folgte im zweiten Schritt der Entwurf einer IEC-61131-Integrationstechnologie. Ein grundsätzliches Problem dabei: Die Portabilität von Programmen ist in der IEC 61499 wie auch in der IEC 61131 sehr herstellerabhängig. nxtControl wirkt dem entgegen, indem Namespaces, die Speicherung der Programm-Sources und der Metadaten (Attribute, grafische Bausteinkoordinaten etc.) in normkonformem XML-Format umgesetzt wurden. Die Hardware-Abstraktion ist ein weiteres geeignetes Mittel, um die Portabilität zu erhöhen. Darüber hinaus gibt es den Vorschlag einer Bibliothekserweiterung für den gesamten Standard, um die Portabilität weiter zu unterstützen.

Nochmals in Erinnerung gerufen: Die IEC 61499 baut auf der IEC 61131 auf und verwendet die gleichen Programmiersprachen. Sie bedient sich aber eines anderen Ausführungsmodells, um eine Verteilung der Applikation auf mehrere Steuerungen zu ermöglichen. Als gemeinsamer Nenner dient ein IEC-61499-Basic-FunctionBlock, welcher als Algorithmussprache die IEC-61131-Sprachmittel nutzen kann. Dieser Baustein wird zur IEC-61131-Integrationsschnittstelle erweitert. Diese Erweiterung betrifft die Möglichkeit, weitere FunctionBlocks aus dem IEC-61131-Raum zu adressieren, wie zum Beispiel FunctionBlock-POU oder Function-POU. Die Program-POU ist somit auf der IEC-61499-Ebene ein BasicFB mit einem automatisch angelegten Eingangs-Event (TASKI) und einem Ausgangs-Event (TASKO). Das Innenleben entspricht dem einer Program-POU der IEC 61131, mit dem gleichen Input- und Output-Variablen-Interface.

Bild 4. Der E_Cycle-Baustein (FB1) erzeugt den zyklischen Event. Die Programm-Instanzen (die Zwitterbausteine PROGINST1 und PROGINST2) werden in dieser Reihenfolge zyklisch bearbeitet.

© nxtControl

Eine andere Erweiterung betrifft die Sprachmittel und die dazu notwenigen Editoren für ST, SFC, CFC, FBD, LD. Der Variablen-Editor integriert sich in seiner Haptik in ähnlicher Art und Weise wie die IEC-61499-Editoren, jedoch ohne Events. Obwohl jederzeit klar ist, in welcher Umgebung man sich gerade befindet, „fühlen“ sich die Editoren gleichartig an.

Im Detail lässt sich in Bild 3 folgendes veranschaulichen:

Punkt 1: Die im gemeinsamen Variablen-Editor erstellten INPUT_VAR, OUTPUT_VAR und VAR sind in den IEC-61131-Editoren anwendbar. INPUT_VAR und OUTPUT_VAR sind zudem am äußeren IEC-61499-Interface verfügbar und werden automatisch mit den TASKI- und TASKO-Events assoziiert. Dieser FunctionBlock-Zwitter – einerseits IEC-61499-BasicFB ande­rerseits IEC-61131-Program-POU – ist somit eine vollständige Integration einer hierarchischen IEC-61131-Struktur. Instanzen dieses Zwitter-Bausteins sind beliebig anwendbar und verteilbar. Die IEC 61131 wird so um die Funktionalität der Verteilung erweitert.

Punkt 2: Globale Variable sind in allen untergeordneten FunctionBlock-POUs (aus den genannten Verteilungsgründen) innerhalb dieses Zwitterbausteins sichtbar.

Punkt 3: Im Gegensatz zu einem BasicFB in der IEC 61499, hat der Zwitterbaustein die Sichtbarkeit/Referenz auf FunctionBlock-POU, Function-POU und auch auf System-Funktionsbausteine (IEC-61131-Laufzeitsystem-Bibliotheken). Die Editoren dieser FunctionBlock-POU und Function-POU verhalten sich wie übliche IEC-61131-Editoren.

Als Fazit bleibt festzuhalten: Die IEC 61499 bietet für verteilte Steuerungssysteme nachweisbare Vorteile. Manche neuartigen Lösungen werden mit dieser Norm überhaupt erst möglich. Mit dem Zusammenführen der IEC 61131 und der IEC 61499 in einem System lassen sich zudem „Berührungsängste“ abbauen. Mehr noch: Was ursprünglich aus der Not heraus geboren wurde – und zwar die geschilderte Migrationslösung – stellt sich am Ende als effiziente Gesamtlösung heraus.

Autor: Horst Mayer ist Gründer und geschäftsführender Gesellschafter der Firma nxtControl.