Maschinenbauer, die speicherprogrammierbare Steuerungen für die Automatisierung programmieren, griffen bislang in der Regel auf die internationale Norm IEC 61131 zurück. Im Umfeld der Prozessindustrie verwenden Programmierer für verteilte Systeme schon seit längerem die Norm IEC 61499. Mehr und mehr kommt – bedingt auch durch die zunehmende Vernetzung der Komponenten – die Frage auf, ob sich diese Norm nicht auch für den Maschinenbau eignet.

Da CANopen auf dem multimasterfähigen CAN basiert, ist es selbstverständlich, dass damit prinzipiell „verteilte“ Steuerungen realisierbar sind. Bereits bei der Entwicklung von CAN­open haben die „Väter“ – insbesondere die Ingenieure von Baldor – darauf geachtet, dass in CAN-open alle für IEC 61499 notwendigen Funktionen zur Verfügung stehen.

Verteilte Steuerung, bei der die Steuerungsfunktionen auf mehrere, über ein serielles Netzwerk – wie zum Beispiel CANopen – angeschlossene Geräte verteilt sind.

© Epis Automation

In der Vergangenheit wurde jedoch wegen mangelndem Interesse keine konkrete Abbildung definiert. Jetzt allerdings gibt es bei den ersten Steuerungsherstellern den Bedarf, „verteilte“ Steuerungen zu realisieren.

Einige CiA-Mitglieder, darunter auch die Firma Epis Automation, haben daher den CANopen-Arbeitskreis IEC 61499 ins Leben gerufen. Sie wollen ähnlich wie für IEC 61131-3 eine Rahmenrichtlinie spezifizieren, die beschreibt, wie Steuerungen nach IEC 61499 in einem CANopen-Netzwerk kommunizieren.

Die CiA-Organisation selbst ist bezüglich der Steuerungsnormen neutral und arbeitet daher auch mit PLCopen, der Nutzerorganisation rund um die IEC 61131-3, an einer Erweiterung der IEC 61131 bezüglich der Unterstützung von „verteilten“ Steuerungen. Das erste Treffen des gemeinsamen CiA/PLCopen-Arbeitskreises fand im Februar statt.

IEC 61131 versus IEC 61499

IEC 61131 versus IEC 61499

© Epis Automation

Da dezentrale Strukturen im Maschinenbau deutlich zunehmen, ist es nur folgerichtig, dass hier auch die IEC 61499 zum Tragen kommt. Allerdings sind einige spezifische Anforderungen zu berücksichtigen, die sich anders als in der Prozess- und Gebäudeautomatisierung darstellen. Dem tragen spezielle Funktionsbibliotheken, zum Beispiel für Positionieraufgaben, Rechnung. Auch die Echtzeit-Anforderungen sind im Vergleich zur Prozessindustrie deutlich verschärft.

Verteilte Steuerungen unterscheiden sich von dezentralen Steuerungen dadurch, dass es keinen dedizierten Hostcontroller gibt. Wo die einzelnen Programmteile real ausgeführt werden, ist nicht festgelegt. Dies ist bei Geräten mit einem IEC-61131-kompatiblen Laufzeitsystem theoretisch möglich; leider ist die Koordination und Ressourcen-verwaltung bis dato nicht standardisiert. Hier kommt die IEC 61499 ins Spiel: Diese bereits Mitte der 90er Jahre entwickelte und 2005 veröffentlichte Normenreihe spezifiziert die fehlenden Teile für verteilte Steuerungen. Zudem wurde mit der Norm ein Paradigmenwechsel vollzogen: Die Abarbeitung der Funktionsblöcke erfolgt nicht mehr wie in der IEC 61131 zyklisch, sondern ereignisgesteuert.

Diese Event-Steuerung hat den Vorteil, dass Programme geschrieben werden, bei denen die Funktionen in sich gekapselt sind und der Datenfluss genau definiert ist. Dadurch ist jeder Funktionsblock auf jeder beliebig zur Verfügung stehenden intelligenten Systemkomponente lauffähig, ohne die Programmierung zu verändern. Der Grund: Der Datenaustausch erfolgt außerhalb des Funktionsblocks. Das Hinzufügen von neuen Funktionen beeinflusst bereits getestete und zertifizierte Funktionsblöcke nicht mehr. Deshalb lassen sich zum Beispiel sicherheitsrelevante Funktionen immer wieder verwenden, ohne dass das gesamte Laufzeitverhalten getestet werden muss.

Stößt der Programmierer an die Leistungsgrenzen des Systems, so kann die Architektur durch Hinzunahme weiterer intelligenter CPUs angepasst werden. Lediglich die Zuordnung, welche Funktion auf welcher CPU laufen soll, ist neu durchzuführen. Diese Flexibilität bietet selbst bei einem relativ geringen Verteilungsgrad Vorteile, da sich generell ein sehr hoher Grad der Wiederverwendung in der Software-Projektierung ergibt.

Bei der zyklischen Programmierung dagegen sind die Auswirkungen auf das Laufzeitsystem bei Programmänderungen neu auszutesten. Besonders bei Verwendung globaler Variablen ist auch bei kleinen Änderungen des Programms Vorsicht geboten. Falls die Aufgaben dann auf mehrere intelligente Systemkomponenten zu verteilen sind, muss die Kommunikation zwischen den CPUs individuell dazu programmiert werden und ist Bestandteil des Programms. Dies führt zu zusätzlichem Testaufwand.

In der IEC 61499 hingegen hat der Programmierer den Zeitpunkt, zu dem einzelne Funktionen ausgeführt werden, im Griff  und kann so das System wesentlich besser optimieren als in der IEC 61131. Mit anderen Worten: Der Zeitpunkt, wann eine Funktion zur Ausführung kommt, wird nicht mehr durch die Zykluszeit und die Zykluszeitdauer vorgegeben, sondern durch physikalische Ereignisse der Maschine. Wird zum Beispiel ein digitaler Eingang geschaltet, erzeugt dies ein Event, woraufhin im Programm ein Baustein abgearbeitet wird.

IEC 61499: Die Abbildung auf CANopen-Netzwerke

Typisches Beispiel der grafischen Darstellung eines IEC-61499-Funktionsblocks. Im oberen Teil sind die Eingangs- und Ausgangs-Events, im unteren Teil die Eingangs- und Ausgangsparameter dargestellt.

© Epis Automation

Eine IEC-61499-Anwendung lässt sich auf mehrere CANopen-Geräte verteilen. Jede Anwendung ist durch mehrere Funktionsblöcke beschreibbar, die jeweils auf einem Gerät implementiert werden. Selbstverständlich kann ein Gerät auch mehrere Funktionsblöcke besitzen, sodass die Anwendung auf einem Gerät implementiert ist. Funktionsblöcke sind sozusagen die elementaren Programmierbausteine für verteilte Steuerungen.

Eine Besonderheit stellen die „Service Interface Function Blocks“ (SFIB) dar. Diese realisieren die Schnittstelle zwischen der Anwendung und der Hardware, wie zum Beispiel Eingänge und Ausgänge, aber auch zu Kommunikationskanälen. Das Besondere daran ist, dass einmal erstellte und getestete Funktionsblöcke ohne Änderung und Neutest wieder verwendbar sind.

Durch den Verzicht von globalen Variablen werden Seiteneffekte verhindert. Wie bereits erwähnt, hat sich eine Arbeitsgruppe der CiA zum Ziel gesetzt, ein CANopen-Profil DSxxx für die IEC 61499 zu erstellen. Dadurch ist eine Inter-operabilität auch zwischen IEC-61131- und IEC-61499-Systemen realisierbar.

Am Ende stellt sich die Frage, ob die IEC 61131 aus der Automatisierung verschwindet? Das wird sicherlich nicht der Fall sein. Für strikt zyklisch arbeitende Systeme mit einer zentralen Intelligenz ist die IEC 61131 die einfachere Lösung und nicht wegzudenken. Für verteilte Systeme kam die IEC 61131 häufig nur für die Programmierung der lokalen SPS-Funktionen zum Einsatz; die verteilten Funktionen wurden über Schnittstellen nach außen verlagert. Die Verteilung haben dann häufig SCADA-Systeme oder andere Software-Erweiterungen übernommen, deren Programmierung in Hochsprachen erfolgte. Mit der IEC 61499 wurde ein Werkzeug geschaffen, das diese Welten miteinander verbindet und somit Standardisierung und Austauschbarkeit vorantreibt. Die Lösung beinhaltet jedoch den Preis, sich von der zyklischen Programmierung zu lösen und zu eventgesteuerter Programmierung überzugehen.

Autor: Reinhard Bosch ist Produktmanager bei der Firma Epis Automation.

Erste Lösungen sind vorhanden

LibertyPro von Epis Automation ist ein Beispiel für eine Branchenlösung für den Maschinenbau, die bewusst entsprechend der IEC 61499 entwickelt wurde. Das Entwicklungs-Tool ergänzt die IEC-61499-Funktionsblöcke um HMI-Elemente und Dokumentationsfunktionen direkt im Funktionsblock. Dabei widersprechen diese Erweiterungen nicht der Norm, sondern sind sinnvolle Ergänzungen, die das Konzept der IEC 61499 fortführen. Der Programm-Editor beinhaltet die grafische Programmieroberfläche für die Funktionen und eine State-Machine für die Definition der Übergänge (Transitionen) von einem Zustand in einen anderen. Der Programmcode wird entweder durch Verbindung weiterer IEC-61499-Funktionsblöcke erzeugt oder in Strukturiertem Text (ST) programmiert, der in der IEC 61131 definiert ist.

Verteilt steuern im Roboter-Umfeld

Neben der IEC hat sich die 1989 gegründete Vereinigung OMG (Object Management Group) mit der Standardisierung von verteilten Steuerungen beschäftigt. Die 2008 veröffentlichte RTC-Spezifikation (Roboter Technology Component) beschreibt ein verteiltes Steuerungssystem für Roboter. Die „Väter“ dieser Spezifikation sind vor allem japanische und koreanische Wissenschaftler.

Bei CiA spezifiziert die CANopen-Special-Interest-Group für Serviceroboter derzeit eine Implementierungsrichtlinie für RTC (CiA317). Diese Richtlinie beschreibt das Mapping der RTC-Datentypen auf die CANopen-Datentypen und ein Mapping der RTC-Statusmaschine auf die CANopen-Statusmaschine. So lassen sich CANopen-Netzwerke einfach in heterogene vernetzte Systeme einbinden. Vor dem Programmierer werden die CANopen-Spezifika dabei sozusagen versteckt.