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, 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
[4] Mayer, H.: Brücke gebaut, Computer & Automation, 2013, www.vyatkin.org
[5] Strasser, T., et al.: The IEC 61499 Function Block Standard: Launch and Takeoff, www.holobloc.com, 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, 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
Hinweis: Teil 2 folgt in unserer nächsten Ausgabe 5.
