Teil 1 von 2:

Automatisieren mit der IEC 61499

Die internationale Norm IEC 61499 beschreibt die Automatisierung von Geräten, Anlagen und Gebäuden mithilfe von verteilten Steuerungen. Sie ist damit ein Nachfolger des Automatisierungsstandards IEC 61131. In diesem Artikel werden die Unterschiede zwischen beiden Vorgehensweisen beschrieben und die Konzepte der IEC 61499 erläutert. Teil 2 beschreibt die Anwendung der Norm anhand von Beispielen.


Die internationale Norm IEC 61499 beschreibt die Automatisierung von Geräten, Anlagen und Gebäuden mithilfe von verteilten Steuerungen. Sie ist damit ein Nachfolger des Automatisierungsstandards IEC 61131. Basis der Automatisierung ist der Funktionsbaustein (Function Block), der nicht nur Dateneingänge und Ausgänge aufweist, sondern zusätzlich auch Eingänge und Ausgänge für sogenannte Events (Ereignisse, Triggersignale). Anders als bei einer SPS werden die Function Blocks nicht zyklisch abgearbeitet, sondern sie rufen sich gegenseitig mithilfe der Events auf. Ein Netz von Function Blocks steuert die Abläufe einer Anlage. Die Norm ermöglicht die nahezu freie Zuordnung von Teilen dieses Netzes zu den eingesetzten Steuerungen (in der Norm mit Device bezeichnet), die sämtlich miteinander kommunizieren (z.B. über Ethernet). Devices, für die das IEC 61499-Laufzeitsystem verfügbar ist, können in beliebiger Kombination zusammenarbeiten. Die neue Norm ist daher besonders für verteilte Automatisierungslösungen geeignet. Von den definierten Befehlsumfängen her ermöglicht die IEC 61499 einem entsprechend ausgestatteten Device sogar die Umprogrammierung anderer Devices, sodass selbstkonfigurierende Systeme erzeugt werden können. Systeme nach IEC 61499 werden in verschiedenen industriellen Bereichen (Fertigungstechnik, Verfahrenstechnik, Gepäckfördersysteme) und in der Gebäudeautomation eingesetzt.

Kapselung von Automatisierungsfunktionen in Function Blocks

In der bisher üblichen Industrienorm IEC 61131 wird die Funktionalität automatisierter Systeme in Programmen, Funktionsbausteinen und Funktionen (Programm-Organisationseinheiten, POEs) gekapselt, die in einer Aufrufhierarchie zueinander in Beziehung stehen. Sogenannte Tasks rufen die übergeordneten Programme meist zyklisch, aber auch zeit- und/oder ereignisgesteuert auf. Die weit überwiegende Anzahl von Anwendungen basiert auf einer zyklischen Abarbeitung des verwendeten Programmcodes, d.h. in einem Zyklus werden - laufend wiederholt - die Sensorsignale des gesteuerten Prozesses von der Steuerung eingelesen, der Programmcode der POEs damit bearbeitet sowie die Ausgangsvariablen dabei berechnet und anschließend diese Ausgangsvariablen auf die Hardwareausgänge der Steuerung ausgegeben. Hierbei wird in der Regel der gesamte Programmcode bearbeitet, obwohl sich in der gesteuerten Anlage möglicherweise überhaupt nichts geändert hat. Die IEC 61499 basiert auf einem hiervon abweichenden Konzept, das sogenannte Function Blocks nutzt. Mithilfe dieser Function Blocks können netzartige Programmstrukturen aufgebaut werden, in denen Automatisierungsanwendungen realisiert werden. Abweichend von den Funktionsbausteinen der IEC 61131 besitzen die verwendeten Function Blocks nicht nur Daten-Ein- und Ausgänge, sondern auch Eingänge und Ausgänge für Ereignissignale, die Events. Die Function Blocks können über einen Eventausgang die Ausführung eines anderen FBs veranlassen. Anders ausgedrückt: die Blocks laufen nicht zyklisch ab, sondern sie werden ereignisgesteuert ausgeführt. Die Bausteine, die in einem Device enthalten sind, werden nur dann bearbeitet, wenn entsprechende Events sie aufrufen. Das hat den Vorteil, dass der häufige Leerlauf der zyklischen Programmbearbeitung entfällt (wozu soll man ein Programm bearbeiten, wenn sich kein einziges Signal im Prozess geändert hat). Gleichzeitig vermindert es die Kommunikationslast zwischen mehreren verbundenen Steuerungen, da auch hier nur im Ereignisfall kommuniziert werden muss. Function Blocks können objektorientiert aufgebaut sein, d.h. sie bilden ein Objekt in einer Anlage mit seinem physischen und logischen Verhalten ab. Die verschiedenen Arten von Function Blocks und ihr Einsatz in Automatisierungsanwendungen sollen im folgenden Artikel näher beschrieben werden.

Anzeige

Das Event-Konzept des Function Blocks

Der Function Block der IEC 61499 kann sofort an seiner typischen Form erkannt werden: Ein eingeschnürtes Rechteck mit einem 'Kopf' für die Event- Ein- und Ausgänge und dem 'Rumpf', der die Daten-Ein-/Ausgänge enthält. Auf der linken Seite befinden sich jeweils die Eingänge, rechts die Ausgänge (1). Die Events sind Ereignisse, die zum Aufruf eines empfangenden Bausteins führen (Genauer: Beim Empfang eines Events wird eine Anforderung zum Aufruf des empfangenden Bausteins in eine Warteschlange eingetragen, die von einem Scheduler des Devices abgearbeitet wird.). Die Daten- EAs sind jeweils mit einem Datentyp versehen. Sie sind an mindestens ein Event gekoppelt und werden nur dann aktualisiert, wenn das zugeordnete Ereignis eintritt. Damit also der IN1-Dateneingang des gezeigten Blocks einen angelegten Real-Wert aufnehmen kann, muss das Event REQ (Anforderung) eintreffen. Umgekehrt kann der Datenausgang OUT1 nur dann einen String abgeben, wenn das Ausgangsevent CNF im Innern des Bausteins durch einen ablaufenden Algorithmus getriggert wird. Der Function Block enthält in seinem Inneren verschiedene Algorithmen sowie einen Zustandsautomaten zur Beschreibung seines Verhaltens, der deutliche Ähnlichkeit mit dem State Diagram (Zustandsdiagramm) der UML aufweist. Dieser Zustandsautomat heißt Execution Control Chart (ECC) und besteht aus Zuständen, Übergängen (Transitionen) zwischen diesen Zuständen sowie zugeordneten Übergangsbedingungen (2). In den Zuständen können Aktionen ausgeführt und Events erzeugt werden. Die Aktionen sind als Algorithmen in einer der Sprachen der SPS-Norm IEC 61131 programmiert (Das ist jedoch in der Norm nicht festgelegt. Die weiter unten beschriebene Entwicklungsumgebung FBDK arbeitet davon abweichend mit Java.). Wird der gezeigte Function Block durch ein von außen eintreffendes Event (z.B. Mode_Auto) aufgerufen, dann wird der im ECC programmierte Zustandsautomat bearbeitet. Befindet sich der Automat im Zustand Start, erfolgt wegen des Events Mode_Auto ein Übergang in den Zustand execMode (oben rechts); dort wird der in diesem Fall gleichnamige Algorithmus execMode ausgeführt und anschließend das Ausgangsevent CNF erzeugt. Danach kehrt der Automat wegen der Übergangsbedingung 1 wieder in den Zustand Start zurück. Der beschriebene Function Block ist ein sogenannter Basic Function Block (BFB), mit dem man die Schnittstellen und die Leistungen eines Automatisierungsobjektes (z.B. eines Motors) definieren und programmieren kann. Derartige BFBs kann man vernetzen, sodass sie größere Einheiten einer Anlage steuern, z.B. die Verschiebeeinheit einer Anlage mit Mechanik und mehreren Antrieben. Benötigt man solche Verschiebeeinheiten mehrfach, ist es sinnvoll, das Ganze in einem eigenen Function Block unterzubringen, dem Composite Function Block.

Composite Function Blocks: Zusammenfassung von komplexeren Funktionen

Der Composite Function Block fasst die Leistungen mehrerer Function Blocks zusammen, sodass man sie als Gesamtheit aufrufen kann (3). Nach außen hin erscheint er mit seinen Schnittstellen wie ein Basic Function Block, im Inneren enthält er jedoch ein Netz von mehreren anderen Function Blocks. Die nach außen hin benötigten Signale bilden das Interface des Composite FB. Ein Execution Control Chart gibt es nicht.

Empfehlungen der Redaktion

Service Function Blocks: Zugang zu den Leistungen des Devices

Die Service Function Blocks (SFB) bilden eine weitere Gruppe von Function Blocks. Sie dienen im Wesentlichen als Verbindung zu den Ressourcen des beherbergenden Devices. Die Sonderform Service Interface Function Block (SIFB) beispielsweise bietet Zugang zu den Eingängen und Ausgängen des Devices. Weiter ermöglichen die SFBs die Kommunikation über ein Netzwerk oder eine Verbindung zu grafischen Oberflächen (siehe Teil 2: Composite Automation Type). Während ein Basic Function Block reaktiv ist - er benötigt ein Eingangsevent, um seinerseits Ausgangsevents zu erzeugen - können Service Function Blocks eigenständig Ausgangsevents generieren. Das wird klar, wenn man an einen Block für die Eingangssignale des Devices denkt. Ändert sich ein Sensorsignal, soll das natürlich zu einem Ausgangsevent des zugehörigen SIFBs führen. Auch die Tastenbetätigung in einer Visualisierung soll zu einem Ausgangsevent des zugehörigen Service Function Block führen. Die Service Function Blocks werden normalerweise nicht vom Applikationsentwickler, sondern vom Hersteller des Devices erzeugt, da dieser über das Know-how der Steuerungshardware verfügt. Weitere Service Function Blocks sind bereits in der Norm festgelegt: Die Event Function Blocks. Sie bieten immer wieder benötigte Standardleistungen im Zusammenhang mit Events an. Hier sind als Auswahl zu nennen: Event-Split, Event-Merge (das Aufteilen eines Events und die Zusammenführung zweier Events), die Erzeugung zyklischer Events, die Auswahl aus mehreren Events und die Event-Verzögerung, Event-gesteuerte Flipflops, Event-Zähler, Event-gesteuerte Flankenerkennungen und weitere mehr. Die Norm legt fest, dass mithilfe von Management Function Blocks auch das Management von Anwendungen möglich ist. Das bedeutet, dass Anwendungen und Bausteine erzeugt, modifiziert, gelöscht oder in ihrem Betriebszustand verändert werden können. Mit diesen Mitteln ist sogar die Selbstorganisation eines Systems möglich. In der Literatur sind Untersuchungen zur Realisierung von Agenten-basierten Systemen mithilfe der IEC 61499 beschrieben (siehe HEGNY). Alle oben beschriebenen Function Block-Arten müssen als Typen verstanden werden. Sie werden in einer Automatisierungslösung als Function Block-Instanzen verwendet. Function Block-Typen können in einer Bibliothek gespeichert werden. Werden nachträglich Verbesserungen an einem FB-Typ durchgeführt, wirken sich diese auf alle Instanzen aus.

Quellen

[1] Christensen, J. et al.: The IEC 61499 Function Block Standard: Software Tools and Runtime Platforms, http://www.holobloc.com/ papers/iec61499/61499_SWT_RTP.pdf, Feb. 2014

[2] Hegny, I., et al.: Integrating software agents and IEC 61499 realtime control for reconfigurable distributed manufacturing systems, International Symposium on Industrial Embedded Systems, 2008

[3] Herkommer, G., Mayer, H.: Brückenschlag von IEC 61131 zu IEC 61499, Computer & Automation, 2013, www.computer-automation.de/steuerungsebene/steuern-regeln/artikel/93521

[4] Mayer, H.: Brücke gebaut, Computer & Automation, 2013, www.vyatkin.org/publ/NxtControl%20Paper%20Horst%20Mayer%20Brucke%20Gebaut.pdf

[5] Strasser, T., et al.: The IEC 61499 Function Block Standard: Launch and Takeoff, http://www.holobloc.com/papers/iec61499/61499_LTO.pdf, Feb. 2014

[6] Vyatkin, V.: IEC 61499 Function Blocks für den Entwurf von Eingebetteten und Verteilten Systemen, Research Triangle Park: International Society of Automation (ISA), 2014, www.isa.org

[7] Vyatkin, V.; Schemm, C.: IEC 61499 - Die neue IEC 61131?, Nürnberg: Vortrag Automation Day 2011, http://www.vyatkin.org/ talks/talk.pdf, Feb. 2014

[8] nxtControl GmbH,

Österreich: www.nxtcontrol.com

[9] ICS Triplex ISaGRAF:

www.isagraf.com

[10] IEC 61499 FAQ auf LinkedIn: www.linkedin.com/groups/IEC-61499-FAQ-4335830

Hinweis: Teil 2 folgt in unserer nächsten Ausgabe 5.

Anzeige