1 Einleitung

Das Anlagenengineering wurde in den letzten Jahren immer komplexer. Die Gründe hierfür sind einerseits die immer anspruchsvolleren Produktionsprozesse welche eine Vielzahl verschiedener Technologien miteinander verbinden. Andererseits bringen die geänderten Rahmenbedingungen in den Märkten, welche eine deutlich höhere Variantenvielfalt aufweisen, kürzere Produkt- und Prozesslebenszyklen mit sich [1]. Um die steigende Komplexität beherrschbar zu machen wurde der Fokus auf die Modularisierung der Automationsanlagen gelegt. Die Hardware (HW)-Komponenten wurden hierfür in wiederverwendbare Subgruppen gegliedert und über Feldbusse verbunden. Diese Art der Systemarchitektur wird auch als Cyber-Physical Production System (CPPS) bezeichnet, welche eine Modularisierung und Verteilbarkeit von Automations-HW und Software (SW) fordert. Die Steuerungsprogramme selbst jedoch werden meist weiterhin zentral monolithisch entwickelt und umgesetzt. Der Hauptgrund dafür ist das Abarbeitungsmodell der IEC 61131, der dominante Standard zur Programmierung von Speicherprogrammierbare Steuerungen (SPSen) [2, 3]. Die IEC 61131 nutzt ein zyklisches Abarbeitungsmodell, welches einen eindeutigen Systemzustand während der Programmabarbeitung garantiert. Dieses regelmäßige „Einfrieren“ der realen Welt erleichtert die Programmierung und ist für den Nutzer leicht verständlich. Gleichzeitig ist es jedoch ein Hindernis für die Modularisierung der SW und Aufteilung des Programms über mehrere SPSen, da über mehrere SPSen ein einheitlicher Systemzustand nicht trivial garantiert werden kann. Selbst wenn für alle SPSen die gleiche Zykluszeit gewählt wird, müssen die einzelnen SPS-Zyklen nicht notwendigerweise isochron laufen. Die SPSen können dadurch unterschiedliche Momentaufnahmen der zu steuernden Anlage haben, was zu Fehlern in der Gesamtapplikation führen kann [4].

Um dieses Problem zu lösen wurde die IEC 61499 entwickelt, welche auch die Modularisierung der SW forciert [5]. Die IEC 61499 nutzt als grundlegendes Programmierelement den Funktionsbaustein (FB), der prinzipiell dem IEC 61131 FB ähnelt, jedoch die datengetriebene Aktivierung der FBs durch eine Eventsteuerung ersetzt. Das bedeutet, dass IEC 61499 FBs nur dann aktiv werden, wenn sie ein Event erhalten haben. Dadurch wird auch das Problem der Synchronisation der Teilsysteme, wie es in IEC 61131 Systemen auftreten kann, vermieden. Dieses Abarbeitungsmodell ist jedoch einerseits ungewohnt für Entwickler die von der IEC 61131 wechseln und andererseits ist die Reihenfolge der FB-Abarbeitung schwieriger nachvollziehbar.

Ein effizientes Anlagenengieering muss daher die Modularisierung und Verteilung ebenso auf der SW-Ebene und gleichzeitig die Weiternutzung des vorhandenen Wissens ermöglichen [6]. Diese Arbeit präsentiert einen Hierarchisierungsansatz in Abschn. 2, welcher zu einer möglichst geringen Abhängigkeit der Module untereinander führt, sowie in Abschn. 3 ein neues Konzept zur Integration von IEC 61131 Systemen in das IEC 61499 Modell.

2 Hierarchische Strukturierung von Applikationen

Modularisierung und Hierarchisierung erlaubt die einfache Wiederverwendung von Automationskomponenten in verschiedenen Anlagenteilen und Applikationen. Dazu muss jedoch jede Automationskomponente für sich autark und vollständig sind [7, 8]. Zusätzlich ist es wichtig, dass die Komponenten keinerlei Anforderungen an eine spezifische HW-Implementierung an ihren Schnittstellen weitergeben oder erwarten [8, 9]. Als Beispiel dient die Widerstandssortieranlage in Abb. 1. In die Anlage werden Widerstandsplättchen als Schüttgut in den Rüttelförderer eingebracht. Die Widerstände werden vereinzelt, der Widerstandswert gemessen und basierend auf dem Messergebnis in eine der beiden Ablagepaletten eingelegt. Folgt man gängigen Methoden zur Hierarchisierung von Automationssystemen [10–12] kann die Anlage in drei Subkomponenten geteilt werden: der Messstation, dem Rüttelförderer und Vereinzelner, und dem Portalroboter mit Vakuumgreifer. Die einzelnen Subkomponenten können nochmals in Subkomponenten auftgeteilt werden. Für die Portalroboter-Komponente wären das die drei Achsen bzw. Achsantriebe für \(x\), \(y\) und \(z\), und das Greifwerkzeug. HW-seitig sind diese drei Komponenten vollständig entkoppelt da es keinerlei Abhängigkeiten zwischen den einzelnen Komponenten gibt.

Abb. 1.
figure 1

In die Widerstandssortieranlage werden Widerstandsplättchen als Schüttgut in den Rüttelförderer eingebracht. Sie werden vereinzelt und von einem Portalroboter in eine Messstation eingelegt, wo sie mit einem Referenzwiderstand verglichen werden. Basierend auf dem Vergleichsergebnis wird der Widerstand in eine der beiden Ablagepaletten eingelegt

Full size image

Betrachtet man jedoch die SW-Komponenten so erkennt man, dass die Komponenten aufgrund von Erwartungen an die Prozessparameter miteinander streng gekoppelt sind. Als Beispiel dient die Achsantriebsteuerung einzelner Achsen des Portalroboters (siehe Abb. 2). Der Servomotor-Achsantrieb erwartet als Eingabe die anzufahrende Position in kartesischen Koordinaten (\(x\), \(y\) oder \(z\) für jede einzelne Achse), sichtbar als Ausgang Position des FBs rechts in Abb. 2, was aufgrund des Portalroboteraufbaus nachvollziehbar ist. Diese Annahme wird jedoch an die nächsthöhere Hierarchieebene über die Schnittstelle Controller_Interface weitergereicht, die einen konkreten Positionswert (Final_Position) erwartet. Die nächsthöhere Komponente wird also gezwungen diese Schnittstelle zu implementieren und bindet sich dadurch stark an Subkomponenten die Koordinaten als Eingabe erwarten.

Abb. 2.
figure 2

Softwarekomponenten eines Servomotors als Achsantrieb. Der grau hinterlegte Teil repräsentiert die Schnittstelle zur nächsthöheren Ebene

Full size image

Das Problem wird evident, wenn man versucht eine Komponente zu verwenden, die eine andere interne Darstellung der Achsposition verwendet, beispielsweise wenn ein pneumatischer Zylinder anstatt des elektrischen Antriebs eingefügt wird. Pneumatische Zylinder werden üblicherweise in die Endanschläge gesteuert da eine genaue Positionsregelung aufwändig ist. Die Fahrweise in die Endanschläge ist für die gewählte Anwendung ausreichend und stellt eine günstigere Variante für den Portalroboter dar. Wenn man nun wieder nach den gängigen Methoden die Modularisierung durchführt, so bekommt man eine SW-Komponente wie in Abb. 3 gezeigt. Wieder sieht man am FB rechts die Ausgänge zur Ansteuerung der HW, welche in diesem Fall den Zylinder entweder einfahren oder ausfahren soll. Links sieht man das neue Controller_Interface, welches nun gänzlich anders aussieht als das in Abb. 2 und mit diesem inkompatibel ist. Vervollständigt man das notwendige Automationsprogramm, so sieht man, dass sich diese Schnittstellen bis in die oberste Hierarchieebene ziehen und somit alle SW-Komponente abhängig von den HW-Schnittstellen werden und damit nur beschränkt wiederverwendbar sind.

Abb. 3.
figure 3

Softwarekomponenten eines pneumatischer Zylinders als Achsantrieb. Der grau hinterlegte Teil repräsentiert die Schnittstelle zur nächsthöheren Ebene

Full size image

Um das Problem der Abhängigkeit zur konkreten HW-Implementierung zu lösen müssen die Prozessparameter generalisiert werden. Dies kann dadurch erreicht werden, indem die konkreten Werte, wie sie bisher verwendet wurden, durch symbolische Namen für die Parameterwerte ersetzt werden. Für das konkrete Beispiel der Positionieraufgabe werden Namen für die Positionen über der Entnahmeposition des Rüttelförderers, der Palettenpositionen und der Einlegeposition der Messstation definiert. Dadurch ergibt sich die SW-Komponente für die gesamte Portalrobotereinheit wie in Abb. 4 gezeigt. Die definierten Namen werden von den Steuerungsprogrammen der höheren Hierarchieebenen genutzt um den Programmablauf zu beschreiben. Die symbolischen Positionen werden nun als STRINGs an die unterlagerten HW-Steuerungen über die AAxisLogic Schnittstelle (siehe Abb. 4) weitergegeben. Diese Schnittstelle beschreibt also nicht wie wie der Aktuator verfahren werden soll (z. B. Schaltstellungen oder kartesische Koordinaten), sondern nur wohin er verfahren werden soll.

Abb. 4.
figure 4

Die Softwarekomponente der Portalrobotersteuerung (Manipulator). Der grau hinterlegte Teil repräsentiert die Schnittstelle zur nächsthöheren Ebene

Full size image

Die Namen sind für die konkrete HW-Steuerungskomponente bedeutungslos da entweder Koordinaten oder Zylinderstellungen erwartet werden. Die Namen werden in einem Model Driven Architecture (MDA)-Ansatz entsprechend zur aktuell verwendeten HW-Komponente gemäß einer vorab definierten Tabelle übersetzt (siehe Abb. 5).

Abb. 5.
figure 5

Nach dem MDA-Ansatz werden die HW-spezifischen Codefragmente erst bei der Wahl der endgültigen HW hinzugefügt. Dadurch wird der Quellcode von der HW entkoppelt

Full size image

Durch diese Methode können die überlagerten Komponenten, welche meist nur allgemeine Abläufe modellieren, von den spezifischen HW-Komponenten entkoppelt werden und somit die Wiederverwendbarkeit der beteiligen HW- und SW-Komponenten erhöhen.

3 Integration von IEC 61131-3 in IEC 61499

Die bisherigen Ansätze einer kombinierte Laufzeitumgebung für IEC 61131 und IEC 61499, mit dem Ziel jegliche Steuerungslogik zu unterstützen, können grob in drei Klassen eingeteilt werden [2]:

  1. (a)

    Getrennte IEC 61131 und IEC 61499 Laufzeitumgebungen verbunden über Kommunikationsschnittstellen.

  2. (b)

    Erweiterte IEC 61131 Laufzeitumgebung mit der Fähigkeit eventbasierte IEC 61499 Logik auszuführen.

  3. (c)

    Erweiterte IEC 61499 Laufzeitumgebung mit der Fähigkeit zyklische IEC 61131 Logik auszuführen.

Die erste Klasse beschreibt ein lose gekoppeltes System, in dem zwei separate Laufzeitumgebungen implementiert sind, welche über eine Kommunikationsschnittstelle interagieren. Dies ermöglicht die Ausführung von IEC 61131-3 und IEC 61499 Applikationen in einem Gerät, erhöht jedoch den Entwicklungsaufwand und unterstützt keine Wiederverwendung von Elementen zwischen den Standards.

Ein Vertreter der zweiten Klasse stellt ISaGRAF [13] von Rockwell Automation dar. Hierbei werden in einer RESOURCE IEC 61499 FB in einer vorbestimmten Reihenfolge zyklisch aufgerufen. Während der Aktivierung können eintreffende Events verarbeitet werden. Obwohl mit dieser Implementierung IEC 61131-3 und IEC 61499 Applikationen nebeneinander verwendet werden können, sind einige Nachteile, wie der Abarbeitungs-Overhead durch das zyklische Aufrufen, die Berechnung der Abarbeitungsreihenfolge, sowie nicht konforme Implementierung von IEC 61499 Konzepten gegenwärtig [14].

Das dritte Konzept erscheint als das flexibelste und damit vorteilhafteste der vorgestellten Konzepte [2]. Neben der Wiederverwendung von existierendem IEC 61131-3 Code, erlaubt diese Methode auch die enge Kopplung zu IEC 61499 Steuerungslogik und ermöglicht die Verteilung auf verschiedenen Ressourcen. Eine bereits bestehende Implementierung liegt bereits von nxtControl [15] vor. Ein Dienstschnittstellen-FB koppelt den zyklischen Teil mit dem eventgetriebenen Teil der Anwendung. Jedoch führt der Kopplungs-FB zum Entstehen gravierender Nachteile, wie instabile Zykluszeiten und Dateninkonsistenzen [16].

3.1 Integrationskonzept

Wie die Analyse der verschiedenen Implementierungsoptionen zeigt, stellt die IEC 61499 die bessere Wahl als Basis für die Erstellung eines gemeinsamen Systemmodellierungskonzeptes dar. Zum einen bietet die IEC 61499 native Unterstützung von Verteilung der Steuerungslogik, zum anderen erscheint ihr das Abarbeitungsmodell besser geeignet zur Beherbergung einer IEC 61131 Laufzeitumgebung. Diese Argumente motivieren die Entwicklung eines neuen kombinierten Ansatzes basierend auf der IEC 61499, welcher schematisch in Abb. 6 dargestellt ist.

Abb. 6.
figure 6

Schematische Repräsentation des Integrationsansatzes: Die vorgeschlagene Entwicklungsumgebung unterstützt das Engineering von IEC 61131-3 und IEC 61499 Applikationen. Darüber hinaus kann der EFB bzw. der IEC-61131 FB als gemeinsames SW-Element verwendet werden. Die adaptierte IEC 61499 Laufzeitumgebung ermöglicht die Verwendung von IEC 61499 EMB_RES RESOURCEen, und in IEC 61499 RESOURCEen eingebettete IEC 61131-3 TASKs. Alle Aspekte des IEC 61499 Gerätemodells [17] können von beiden RESOURCEentypen verwendet werden

Full size image

3.1.1 Zuordnung der Modellelemente

Basierend auf einer Analyse der Korrespondenzen zwischen IEC 61131-3 und IEC 61499 [6], erscheint die abarbeitungsorienterte Zuordnung als die naheliegendere Wahl hinsichtlich des Integrationskonzeptes.

Da ein IEC 61131-3 TASK mit einer IEC 61499 RESOURCE korrespondiert, wird ein spezieller Ressourcentyp erstellt, der als Abarbeitungscontainer für IEC 61131-3 Programm-Organisationseinheiten (POEs) dient und die beinhalteten IEC 61131 POEs zyklisch aufruft. Die geforderte Zykluszeit wird dieser speziellen die RESOURCE als Parameter bekannt gemacht. Die IEC 61499 definiert die RESOURCE als eine von anderen RESOURCEen unabhängige Abarbeitungseinheit. Unter der Annahme, dass die Echtzeitbedingungen für alle Ressourcen erfüllt werden können, kann eine korrekte zyklische Abarbeitung garantiert werden. Dies kann beispielsweise dadurch erreicht werden, dass jede RESOURCE als Echtzeit-Thread mit Round-Robin Scheduling gestartet wird. Um die zyklische Abarbeitung von IEC 61131 POEs in das eventbasierte Abarbeitungsmodell der IEC 61499 zu integrieren, wird die Aufrufreihenfolge als lineare Liste in die Event-Aufrufliste eingetragen (siehe Abb. 7). Im Gegensatz zu IEC 61499 Funktionsbausteinnetzwerken, deren Abarbeitungsreihenfolge dynamisch erzeugt werden muss, kann die Aufrufreihenfolge einer Funktionsbaustein-Sprache (FBS) Applikation statisch berechnet werden (siehe Abschn. 3.1.2). Bei jedem zyklischen Aufruf der IEC 61131 RESOURCE wird die Abarbeitung am Anfang der Liste gestartet und endet mit der Abarbeitung des letzten eingetragenen FB. Danach wird bis zum nächsten Aufruf des IEC 61131 RESOURCE zum Start des nächsten Zyklus gewartet. Hiermit ist eine parallele Abarbeitung von zyklischer IEC 61131-3 und eventgetriebener IEC 61499 Steuerungslogik möglich.

Abb. 7.
figure 7

Abarbeitungsprinzip der (a) IEC 61499 Eventliste und (b) des IEC 61131-3 Abarbeitungsmodells basierend auf der Eventliste

Full size image

Ein weiterer wichtiger Punkt einer kombinierten Programmierumgebung ist Code-Sharing zwischen den beiden Welten um Wartungs- und Entwicklungsaufwand zu reduzieren. Der einfache FB (EFB) erweist sich als geeignetes eventgetriebenes Analogon zum IEC 61131-3 FB. Daher wird liegt in dieser Arbeit der Fokus auf der Integration der IEC 61131-3 FBS. Die IEC 61499 beschreibt den EFB als einen Dienstschnittstellen-FB, bei dem jedes verfügbare Eingangsevent jeweils die Abarbeitung eines assoziierten Algorithmus startet. Für das vorliegende Integrationskonzept [16] wird diese Definition adaptiert: Ein EFB gilt als vereinfachte Version eines Basis-FB mit nur einem Algorithmus, nur einem Eingangsevent REQ, und einem Ausgangsevent CNF. Wird nun schlussendlich der Eventkopf des IEC 61499 FB entfernt, so kann ein IEC 61499 EFB auch als IEC 61131-3 FB verwendet werden. Ein FB der abgearbeitet werden soll, wird durch das REQ Event des dualen EFB aktiviert (siehe Abb. 8). Damit werden die Datenwerte, welche an den Eingängen des FB anliegen, übernommen und die Abarbeitung des FB gestartet. Das CNF Event wird in der Abarbeitung nur zur Bestimmung des Endes der Abarbeitung und der damit einhergehenden Aktualisierung der Ausgänge verwendet. Algorithmen, welche Sprachen verwenden deren Abarbeitungsreihenfolge im zyklischen Abarbeitungsmodell der IEC 61131 inhärent wohldefiniert sind (z. B. Structured Text (ST), Kontaktplan (KOP), FBS), können trivial übernommen werden. Algorithmen die als IEC 61499 FB-Netzwerk (FBN) definiert sind, müssen gesondert betrachtet werden. Sie ähneln in ihren Eigenschaften den zusammengesetzten FB der IEC 61499. Diese können als atomare Abarbeitungseinheiten gesehen werden [18], was es erlaubt jeden dieser FBN Algorithmen gesondert zu betrachten. Eine Möglichkeit eventbasierte FBNs in das zyklische Abarbeitungsmodell der IEC 61131 zu übertragen wurde von Lastra et al. [19] präsentiert. Eine Einschränkung des Code-Sharing ist, dass VAR_IN_OUT, ACCESS_PATH und GLOBAL Variablen nicht genutzt werden können, da diese im Sprachgebrauch der IEC 61499 nicht existieren. FBs die in der IEC 61499 über ein INIT Event initialisiert werden müssen, können ebenfalls verwendet werden. Die INIT Events werden beim Starten der RESOURCE vor dem ersten Zyklus aktiviert und die entsprechenden Initialisierungsalgorithmen ausgeführt. Herstellerspezifische- und Kommunikations- FBs können ebenfalls über die Abarbeitungsmodelle geteilt werden, solange die oben genannten Einschränkungen nicht verletzt werden.

Abb. 8.
figure 8

Der adaptierte EFB kann als IEC 61131-3 FB verwendet werden, womit der Entwicklungsaufwand für ein gemeinsames System reduziert wird. Hier wird als Beispiel der F_AND FB in seiner dualen Repräsentation gezeigt

Full size image

Mit dem vorgestellten Zuordnungskonzept der SW-Elemente ist eine Koexistenz von IEC 61499 und IEC 61131-3 bereits möglich, jedoch noch keine Interaktion. Da die IEC 61499 die Datentypen der IEC 61131-3 direkt übernommen hat kann der Datenaustausch mit den IEC 61499 Kommunikations-FBs ermöglicht werden. Hierbei sind zwei Kommunikationsmodelle präsent: Unidirektionale Interaktion mit den PUBLISH/SUBSCRIBE FBs und bidirektionale Interaktion mit den CLIENT/SERVER FBs. Diese FBs werden in die IEC 61131-3 übertragen und ermöglichen so Code-Sharing und Interaktion zwischen den beiden Subsystemen.

3.1.2 Abarbeitungsverhalten

Schlussendlich wird das Abarbeitungsverhalten von IEC 61131-3 FBS Programmen in dem kombinierten Laufzeitsystem definiert. Dieses Verhalten soll dem in der IEC 61131-3 definierten Abarbeitungsverhalten entsprechen. Dieses ist wie folgt definiert [20, Kapitel 8.1.5.1]:

  1. 1.

    Kein Element eines Netwerks darf ausgewertet werden, bevor die Zustände all seiner Eingänge bekannt sind.

  2. 2.

    Die Auswertung eines Netzwerkelements ist erst dann abgeschlossen, wenn alle Ausgänge des Elements ermittelt wurden.

  3. 3.

    Die Auswertung eines Netzwerks ist erst dann abgeschlossen, wenn alle Ausgänge aller Netzwerkelemente ermittelt wurden.

Für die weitere Analyse wird diese informelle Beschreibung in ein formales Modell überführt. Ein FBs wird hierfür als 2-Tupel \(F = (I, O)\) beschrieben, mit \(I\) als FB-Eingänge und als \(O\) die FB-Ausgänge. In dieser Darstellung werden Eingänge der POE welche das FBS beinhaltet als \((\emptyset, O_{m})\) und POE-Ausgang als \((I_{n}, \emptyset)\) dargestellt. POEs können in diesem Zusammenhang IEC 61131-3 PROGRAMs, FBs, oder FUNCTIONs sein. Das Netzwerk lässt sich als 4-Tupel \(P = (\Sigma_{I}, \Sigma_{O}, \Sigma_{F}, C)\) beschrieben werden, wobei

  • \(\Sigma_{I}\) die Menge aller FB-Eingänge und POE-Ausgänge \(I_{n}\),

  • \(\Sigma_{O}\) die Menge aller FB-Ausgänge und POE-Eingänge \(O_{m}\),

  • \(\Sigma_{F}\) die Menge aller FBs \(F_{j}\),

  • \(C\) die \(\lvert\Sigma_{I}\rvert\times\lvert\Sigma_{O}\rvert\) ungewichtete Verbindungsmatrix aller Verbindungen zwischen den Elementen aus \(\Sigma_{I}\) und \(\Sigma_{O}\)

darstellt. Die Berechnung der statischen Abarbeitungsreihenfolge einer in FBS geschriebenen POE lässt sich als Suchproblem auf dem 4-Tupel \(P\) (vgl. Algorithmus 1) formulieren. Im Falle von impliziten oder expliziten Rückkopplungen im FBS Netzwerk müssen Initialwerte für Rückkopplungspfads angegeben werden, um die Berechnung einer Abarbeitungsreihenfolge zu ermöglichen [20, Kapitel 8.1.5.2] [21]. Dadurch wird das zirkuläre Problem des Rückkoppelpfads aufgelöst und ermöglicht die Berechnung einer korrekten, jedoch nicht unbedingt eindeutigen, Abarbeitungsreihenfolge in allen Fällen. Als Beispiel hierfür dient das FBS Netzwerk in Abb. 9. Die Eingänge IN1, IN2 und IN3 sind am Anfang des Programmablaufs durch das Prozessabbild der Eingänge (PAE) bekannt. Da IN1 und IN2 die Zustände der Eingänge von FB1 definieren, kann FB1 ausgewertet werden. Ähnliches gilt für FB2, dessen einziger Eingang durch IN2 eindeutig definiert wird und deshalb ebenfalls abgearbeitet werden kann. Der Eingang IN3 führt zu FB3 und definiert damit den Zustand von Eingang 1 von FB3. Eingang 2 von FB3 ist in einem expliziten Rückkoppelpfad mit Ausgang 3 von FB3. Ohne Initialwert könnte FB3 daher nie ausgeführt werden, da die Ausgänge von FB3 nur ermittelt werden, wenn alle Eingänge wohldefiniert sind, was jedoch ohne den Wert von Ausgang 3 nicht möglich ist. Durch die Angabe eines Initialwerts an Eingang 2 sind jedoch alle Eingänge von FB3 wohldefiniert und FB3 kann ausgewertet werden. Das aktuelle Ergebnis von Ausgang 3 wird im nächsten Abarbeitungszyklus als Wert für Eingang 2 wieder herangezogen. Nun da alle FBs die direkt mit Eingängen verbunden sind ausgewertet wurden, wird ermittelt welche nachfolgenden FBs ausgewertet werden können. Die Ausgänge von FB1 und FB2 sind nun bekannt und definieren die Eingänge von FB4 welcher nun ebenfalls ausgewertet werden kann, womit nun auch alle Eingänge von FB5 über die Ausgänge von FB3 und FB4 bekannt sind, und damit ausgewertet werden kann. Damit sind nun die Ausgänge der POE bekannt und das FBS Netzwerk vollkommen ausgewertet. Wie eingangs erwähnt gibt es im Allgemeinen keine eindeutige Abarbeitungsreihenfolge. Die Abarbeitung von FB1, FB2 und FB3 kann beliebig vertauscht werden. Auch FB4 kann vor FB3 ausgewertet werden, solange die Auswertung von FB1 und FB2 vor FB4 passiert.

Abb. 9.
figure 9

Statische Berechnung der FBS Abarbeitungsreihenfolge gemäß der IEC 61131-3 [22]. In diesem Beispiel wird die ermittelte Abarbeitungsreihenfolge des Netzwerks durch römische Zahlen dargestellt. Bei Rückkopplungen muss ein Initialwert vorgegeben werden

Full size image
Algorithmus 1
figure 10

Berechnung der Abarbeitungsreihenfolge

Full size image

3.2 Zusammenfassung der Integration von IEC 61131-3 in IEC 61499

Mit dem vorgestellten Integrationskonzept [16] ist eine gemeinsame Entwicklungs- und Laufzeitumgebung für die kombinierte Verwendung von IEC 61131-3 und IEC 61499 geschaffen. Die beschriebene Zuordnung der SW-Elemente ermöglicht die Erstellung eines Steuerungsgerätes, das sowohl die Integration von bestehenden IEC 61131-3 Systemen als auch die Verteilungsaspekte der IEC 61499 unterstützt. Darüber hinaus kann der EFB als gemeinsames SW-Element von beiden Subsystemen verwendet werden, und so den Entwicklungs- und Ausführungsaufwand reduziert.

4 Zusammenfassung

Dieser Artikel präsentiert neuartige Ansätze zur Hierarchisierung von Automatisierungssystemen und zur Integration von IEC 61131 Applikationen in IEC 61499 Systeme. Der vorgestellte Hierarchisierungsansatz erlaubt es die Ablaufsteuerung von der HW-Ansteuerung weitestgehend zu entkoppeln, was eine effektive Wiederverwendung von Automations-SW ermöglicht. Der Integrationsansatz ermöglicht es zyklische Programme nach IEC 61131 in die IEC 61499 Systemarchitektur einzugliedern und dadurch die zyklischen Teilsysteme über den Eventmechanismus der IEC 61499 voneinander zu entkoppeln. So können verteilte IEC 61131 Anwendungen einfach realisiert und das vorhandene Expertenwissen auch in der IEC 61499 weiter genutzt werden. Beide Methoden verringern den Engineeringaufwand für zukünftige Automatisierungsprojekte durch die verbesserte Wiederverwendbarkeit und Modularisierung.