In der industriellen Steuerungstechnik wächst die Komplexität von Applikationen stetig: Mehr Achsen, mehr Sensorik, mehr Kommunikationsschnittstellen und steigende Anforderungen an Diagnose und Sicherheit verlangen nach einer strukturierten Softwarearchitektur. Die Norm IEC 61131-3 definiert dafür fünf Programmiersprachen sowie ein Organisationseinheitenmodell, dessen Herzstück der Funktionsbaustein — englisch: Function Block, kurz FB — bildet. Obwohl das Konzept seit Jahrzehnten etabliert ist, werden die Möglichkeiten, die Funktionsbausteine bieten, in der Praxis häufig nicht vollständig ausgeschöpft.
Der folgende Artikel erläutert, wie Funktionsbausteine aufgebaut sind, wie sie sich von Funktionen und Programmen unterscheiden, welche Rolle Instanzen und Gedächtnis spielen, und warum das Konzept die Grundlage moderner, objektorientierter Erweiterungen in der SPS-Welt bildet.
Organisationseinheiten nach IEC 61131-3: Einordnung des Funktionsbausteins
Die IEC 61131-3 unterscheidet drei Arten von Programmorganisationseinheiten (POE): das Programm (PROGRAM), den Funktionsbaustein (FUNCTION_BLOCK) und die Funktion (FUNCTION). Jede POE besitzt einen Deklarationsteil für Variablen und einen Implementierungsteil mit dem eigentlichen Algorithmus. Der entscheidende Unterschied liegt im Zustandsverhalten: Eine Funktion ist zustandslos — bei identischen Eingaben liefert sie stets identische Ausgaben, ähnlich einer mathematischen Abbildung. Ein Programm ist die übergeordnete Ausführungseinheit und wird genau einmal instanziert. Der Funktionsbaustein hingegen verbindet Algorithmus und persistenten Zustand in einer wiederverwendbaren Einheit.
Diese Zustandspersistenz ist kein Nebeneffekt, sondern zentrales Entwurfsprinzip: Variablen, die innerhalb eines Funktionsbausteins als VAR deklariert sind, behalten ihren Wert über Zyklusgrenzen hinweg. Das erlaubt die Implementierung von Logiken, die über mehrere Programmzyklen laufen müssen — Rampen, Zähler, Zeitglieder, Zustandsautomaten oder Regelkreise sind klassische Anwendungsfälle.
Deklarationsstruktur: Eingangs-, Ausgangs- und interne Variablen
Ein Funktionsbaustein besteht aus einem Deklarations- und einem Implementierungsabschnitt. Im Deklarationsteil werden Variablen nach ihrer Rolle klassifiziert. VAR_INPUT definiert die Eingangsparameter, die der aufrufende Code übergibt. VAR_OUTPUT enthält die Rückgabewerte, die nach der Ausführung ausgelesen werden können. VAR_IN_OUT beschreibt Parameter, die bidirektional — also lesend und schreibend — genutzt werden, was insbesondere bei der Übergabe großer Datenstrukturen als Referenz sinnvoll ist. VAR schließlich umfasst die internen, persistenten Zustandsvariablen, die von außen nicht direkt zugreifbar sind.
Diese klare Schnittstellendefinition ist der Schlüssel zur Wiederverwendbarkeit: Der Anwender eines Funktionsbausteins muss nur die öffentliche Schnittstelle kennen, nicht die innere Implementierung. In modernen Entwicklungsumgebungen werden Funktionsbausteine in Bibliotheken paketiert und über grafische Bausteinboxen in Funktionsplanprogrammen oder über textuelle Aufrufnotation in strukturiertem Text eingebunden.
Instanzierung: Mehrfachverwendung ohne Datenkonflikte
Ein grundlegendes Konzept, das Funktionsbausteine von einfachen Unterprogrammen früherer Steuerungssysteme unterscheidet, ist die Instanzierung. Wenn ein Funktionsbaustein in einer übergeordneten Einheit deklariert wird, entsteht eine benannte Instanz — ein eigenständiges Datenobjekt, das seine eigene Kopie aller internen und Ausgangsvariablen hält. Zwei Instanzen desselben Funktionsbaustein-Typs teilen den Algorithmus, arbeiten aber vollständig getrennt auf ihren eigenen Daten.
Dieses Prinzip ermöglicht, einen einzigen, gut getesteten Antriebsregler-Baustein für zwanzig Achsen zu verwenden, ohne auch nur eine Codezeile zu duplizieren. Jede Achse bekommt ihre eigene Instanz mit eigenen Zustands- und Ausgangsvariablen. Änderungen am Baustein-Typ wirken sich bei der nächsten Kompilierung auf alle Instanzen aus, was zentrale Fehlerkorrekturen erheblich vereinfacht. Die Instanzdaten werden im Datenbereich der SPS gespeichert und sind über den Instanznamen adressierbar, was auch die Online-Diagnose erleichtert.
Implementierungssprachen und strukturierter Text als Standard
Der Implementierungsteil eines Funktionsbausteins kann in jeder der fünf IEC-61131-3-Sprachen geschrieben werden: Anweisungsliste (IL), Strukturierter Text (ST), Kontaktplan (KOP/LD), Funktionsplan (FUP/FBD) und Ablaufsprache (AS/SFC). In der Praxis hat Strukturierter Text — eine Pascal-ähnliche Hochsprache — in den letzten Jahren stark an Bedeutung gewonnen, weil er komplexe Algorithmen kompakt und lesbar ausdrücken kann und sich gut für Versionskontrollsysteme eignet, da er reiner Text ist.
Funktionsplan ist nach wie vor verbreitet für die grafische Darstellung von Signalflüssen, insbesondere wenn Nicht-Programmierer in der Inbetriebnahme mitarbeiten. Für sicherheitsrelevante Applikationen nach IEC 62061 oder IEC 61508 gelten zusätzliche Anforderungen an die Nachvollziehbarkeit und Testabdeckung der eingesetzten Bausteine, was den Einsatz formaler Verifikationswerkzeuge begünstigt.
Objektorientierte Erweiterungen: Von FB-Vererbung zu Interfaces
Die zweite Ausgabe der IEC 61131-3 sowie deren Erweiterungen, wie sie viele moderne Laufzeitsysteme (etwa IEC-61131-3-konforme Umgebungen mit OOP-Erweiterungen) implementieren, führen objektorientierte Konzepte ein. Funktionsbausteine können voneinander erben: Ein spezieller Servoachsen-Baustein kann von einem allgemeinen Achsen-Baustein abgeleitet werden und erhält dessen Schnittstellen und Implementierungen, die er überschreiben oder erweitern kann.
Interfaces — in Anlehnung an Konzepte aus Java oder C# — definieren abstrakte Schnittstellen, die verschiedene Funktionsbaustein-Typen implementieren können. Eine übergeordnete Steuerlogik kann so über ein Interface mit einem Antrieb kommunizieren, ohne zu wissen, ob dahinter ein Servo, ein Frequenzumrichter oder ein Linearmotor steckt. Diese Entkopplung ist ein wesentlicher Schritt hin zu plug-and-produce-fähigen Maschinenmodulen, wie sie im Kontext von Industrie 4.0 und PackML diskutiert werden.
Praxis: Bibliotheken, Tests und Versionierung
Für den industriellen Einsatz ist die Verwaltung von Funktionsbaustein-Bibliotheken eine organisatorische und technische Herausforderung. Bibliotheken sollten versioniert, dokumentiert und mit definierten Schnittstellen ausgeliefert werden. Unit-Tests für Funktionsbausteine — also isolierte Tests einzelner Bausteine mit definierten Eingangs- und erwarteten Ausgangswerten — sind in modernen Entwicklungsumgebungen zunehmend möglich und empfehlenswert, auch wenn die SPS-Welt hier gegenüber der klassischen Softwareentwicklung noch aufholt.
Die Integration in Git-basierte Versionskontrollsysteme, CI/CD-Pipelines und automatisierte Regressionstests entwickelt sich zur Best Practice in fortschrittlichen Automatisierungsabteilungen. Normen wie PLCopen definieren zudem standardisierte Funktionsbausteine für häufige Aufgaben — etwa Bewegungssteuerung (Motion Control), Kommunikation oder Safety —, was Portabilität und Interoperabilität zwischen verschiedenen Steuerungsplattformen verbessert. Wer Funktionsbausteine konsequent modular, gut dokumentiert und testgetrieben entwickelt, schafft die Softwarebasis für skalierbare, wartbare und zukunftssichere Automatisierungssysteme.
