Funktionsbausteine und strukturiertes Programmieren

Stell dir ein Programm vor, in dem die komplette Steuerung einer Förderanlage in einem einzigen Block steht: Bandsteuerung, Störungsauswertung, Zählung der Teile, Ansteuerung von drei Antrieben – alles hintereinander. Solange alles funktioniert, fällt das nicht weiter auf. Problematisch wird es, sobald jemand etwas ändern, einen Fehler finden oder die Anlage um ein viertes Band erweitern soll.

Ein soche monolithisches Programm – also ein Programm „aus einem Guss“ ohne innere Gliederung – hat drei typische Schwächen. Die Wartung ist mühsam, weil zusammengehörige Logik über das ganze Programm verstreut sein kann. Die Fehlersuche dauert, weil man nicht eingrenzen kann, in welchem Teil das Problem steckt. Und die Teamarbeit leidet, weil zwei Personen kaum gleichzeitig am selben großen Block arbeiten können.

Die Lösung heißt Modularisierung: Die Gesamtaufgabe wird in kleinere, in sich abgeschlossene Einheiten aufgeteilt. Jede Einheit erledigt genau eine klar umrissene Teilaufgabe und lässt sich für sich allein verstehen, testen und wiederverwenden.

Eine gute Analogie ist der Werkzeugkasten. Niemand baut ein Universalwerkzeug, das gleichzeitig schraubt, schneidet und misst. Stattdessen hat man für jede Aufgabe ein passendes, spezialisiertes Werkzeug. Genauso ist es beim Programmieren: Statt eines Blocks, der alles kann, baut man viele kleine Bausteine, die jeweils eine Sache richtig gut können. Wer schon einmal mathematische Funktionen genutzt hat, kennt das Prinzip – man gibt Werte hinein, bekommt ein Ergebnis heraus und muss nicht wissen, was innen genau passiert.

Beim Entwurf gibt es zwei Denkrichtungen. Beim Top-Down-Ansatz beginnt man bei der Gesamtaufgabe und zerlegt sie schrittweise in immer kleinere Teilaufgaben. Beim Bottom-Up-Ansatz baut man zuerst die kleinen, allgemein nutzbaren Bausteine und setzt daraus die größere Lösung zusammen. In der Praxis mischt man beides: grob von oben planen, bewährte Bausteine von unten einsetzen.

Die Programmiernorm für SPS unterscheidet mehrere Bausteinarten, die sich in ihrer Aufgabe und in ihrem Umgang mit Daten unterscheiden. Vier davon trifft man ständig.

Der Organisationsbaustein (OB) ist der Einstiegspunkt des Programms. Das Betriebssystem der SPS ruft ihn auf, und von dort aus werden die anderen Bausteine gestartet. Der zyklische Hauptbaustein (oft OB1) bildet den Einstieg in den normalen Programmlauf – wie dieser Zyklus im Detail abläuft, ist im Vorwissen-Beitrag zum zyklischen Programmablauf beschrieben. Für uns reicht hier: Der OB ist der Aufrufer ganz oben, der die eigentliche Arbeit an die nachfolgenden Bausteine verteilt.

Die Funktion (FC) ist ein Baustein ohne Gedächtnis. Sie bekommt Werte übergeben, verarbeitet sie und liefert ein Ergebnis zurück. Nach dem Durchlauf behält sie nichts. Ruft man dieselbe FC im nächsten Zyklus wieder auf, beginnt sie wieder bei null. Typisch für reine Berechnungen oder Umrechnungen.

Der Funktionsbaustein (FB) ist ein Baustein mit Gedächtnis. Er kann sich Werte über den Zyklus hinaus merken. Das ist nötig, sobald ein Baustein einen Zustand halten muss – etwa eine Selbsthaltung, einen Zählerstand oder eine laufende Zeit. Dieses Gedächtnis liegt nicht im FB selbst, sondern in einem zugeordneten Datenbaustein.

Der Datenbaustein (DB) speichert Daten, enthält aber keine Logik. Man unterscheidet zwei Arten. Ein globaler DB steht allen Bausteinen offen und dient als gemeinsamer Datenspeicher, etwa für Rezepturen oder Anlagenparameter. Ein Instanz-DB gehört fest zu einem bestimmten FB-Aufruf und enthält dessen gemerkte Werte.

Bausteine rufen einander auf, und das auch verschachtelt: Der OB ruft einen FB, dieser ruft eine FC, die wiederum eine weitere FC nutzt. So entsteht eine Aufrufhierarchie, in der jede Ebene eine klar abgegrenzte Aufgabe übernimmt.

Die folgende Darstellung zeigt diese Hierarchie und ordnet jedem FB seinen Instanz-DB zu.

Der wichtigsten Unterschied zwischen Funktion und Funktionsbaustein lässt sich auf ein Wort bringen: Gedächtnis. Um zu verstehen, was das konkret bedeutet, lohnt ein Blick auf die Arten von lokalen Variablen, die ein Baustein verwenden kann.

Statische Variablen behalten ihren Wert über den Zyklus hinaus. Schreibt der Baustein in einem Zyklus eine 5 hinein, steht im nächsten Zyklus immer noch die 5 da – solange, bis sie überschrieben wird. Temporäre Variablen dagegen sind flüchtig. Sie existieren nur während des aktuellen Durchlaufs und sind beim nächsten Aufruf wieder undefiniert. Sie dienen als Zwischenspeicher für Werte, die man nur kurz innerhalb einer Berechnung braucht.

Eine FC kennt nur temporäre lokale Variablen. Sie hat keinen Platz für statische Werte und damit kein Gedächtnis. Ein FB dagegen kann statische Variablen führen – und genau dafür braucht er den Instanz-DB. Dort werden die statischen Werte zwischen den Zyklen aufgewahrt. Ohne diesen zugeordneten Datenbaustein gäbe es keinen Ort, an dem der FB sich etwas merken könnte.

Wann nimmt man was? Die Faustregel ist einfach. Sobald ein Baustein sich etwas über den Zyklus hinaus merken muss, wird es ein FB. Geht es nur um eine Berechnung, deren Ergebnis sofort weitergereicht wird, genügt eine FC.

Typische FC-Aufgaben sind reine Berechnungen und Umrechnungen: eine Skalierung von Rohwerten, eine Einheitenumrechnung, eine mathematische Formel. Typische FB-Aufgaben sind alle Funktionen mit Zustand: eine Selbsthaltung, ein Zähler, der seinen Stand behält, eine Zeitfunktion, die mitläuft, oder eine Ablaufsteuerung, die sich ihren aktuellen Schritt merkt.

Ein FB lässt sich übrigens mehrfach verwenden. Ruft man denselben FB an mehreren Stellen auf, bekommt jeder Aufruf seinen eigenen Instanz-DB. Man spricht von Mehrfachinstanz oder mehreren Instanzen desselben Bausteins. So steuert ein einziger FB „Antrieb“ gleichzeitig drei verschiedene Motoren – jeder Motor hat dank eigenem Instanz-DB sein eigenes, unabhängiges Gedächtnis.

Jeder Baustein wird über seine Schnittstelle mit der Außenwelt verbunden. Die Schnittstelle ist der Deklarationsteil, in dem festgelegt wird, welche Werte hineingehen, welche herauskommen und welche lokalen Daten der Baustein intern verwendet. Eine saubere Schnittstelle ist der eigentliche Schlüssel zur Wiederverwendbarkeit – wer den Baustein nutzt, muss nur wissen, was vorne hinein- und hinten herauskommt, nicht aber, was innen passiert.

Die Schnittstelle gliedert sich in mehrere Abschnitte:

• IN – Eingangsparameter. Werte, die der Baustein von außen erhält und nur liest. Beispiel: ein Startsignal, ein Sollwert.
• OUT – Ausgangsparameter. Werte, die der Baustein berechnet und nach außen zurückgibt. Beispiel: ein Ansteuersignal, ein Statusbit.
• IN_OUT – Durchgangsparameter. Werte, die der Baustein hineinbekommt, verändert und wieder zurückgibt. Sinnvoll bei größeren Datenmengen, die nicht kopiert, sondern direkt bearbeitet werden sollen.
• STAT – statische lokale Variablen. Sie bilden das Gedächtnis des Bausteins und behalten ihren Wert über den Zyklus hinaus. Genau diese STAT-Variablen sind die Datenbasis des Instanz-DB: Was hier deklariert wird, belegt dauerhaft Platz im zugeordneten Datenbaustein und bleibt zwischen den Zyklen erhalten. STAT gibt es nur beim FB, nicht bei der FC.
• TEMP – temporäre lokale Variablen. Sie liegen flüchtig im Lokaldatenbereich und werden mit jedem Aufruf neu angelegt. Im Gegensatz zu den STAT-Variablen belegen sie keinen Platz im Instanz-DB; ihr Inhalt geht am Ende des Durchlaufs verloren und ist beim nächsten Aufruf undefiniert.

Damit wird der Zusammenhang aus Kapitel 3 greifbar: Das „Gedächtnis“ eines FB sind genau seine STAT-Variablen, die im Instanz-DB dauerhaft abgelegt werden. Die TEMP-Variablen dagegen dienen nur als kurzlebiger Zwischenspeicher und überdauern den Zyklus nicht.

Beim Aufruf eines Bausteins unterscheidet man zwei Begriffe. Die formalen Parameter sind die Platzhalter, die in der Schnittstelle deklariert wurden – etwa ein Eingang mit Namen „Startsignal“. Die aktuellen Parameter sind die konkreten Werte oder Adressen, die man beim Aufruf an diese Platzhalter übergibt – etwa der Eingang E0.0. Der formale Parameter ist also die Beschriftung der Klemme, der aktuelle Parameter das Kabel, das man tatsächlich anschließt.

Für die Datentypen genügt fürs Erste ein grober Überblick. BOOL ist ein einzelnes Bit, also wahr oder falsch – typisch für Signale und Zustände. INT ist eine Ganzzahl, etwa für Stückzahlen. REAL ist eine Gleitkommazahl für Messwerte mit Nachkommastellen. TIME ist ein Zeitwert für Dauern und Verzögerungen. Welcher Datentyp an einen Parameter passt, legt die Schnittstelle fest.

Die folgende Darstellung zeigt einen Baustein als Symbol: Eingänge links, Ausgänge rechts, die lokalen Daten im Inneren.

Der eigentliche Gewinn des strukturierten Programmierens zeigt sich bei der Wiederverwendung. Ein gut geschriebener FB wird einmal erstellt, getestet und freigegeben – und danach beliebig oft eingesetzt. Jeder weitere Einsatz bekommt nur einen neuen Instanz-DB; die Logik bleibt dieselbe.

Solche bewährten Bausteine sammelt man in Bibliotheken. Eine Bibliothek ist ein Vorrat geprüfter Bausteine, aus dem man sich für neue Projekte bedient. Das spart nicht nur Zeit, sondern erhöht auch die Zuverlässigkeit: Ein Baustein, der sich in zehn Anlagen bewährt hat, enthält erfahrungsgemäß weniger Fehler als frisch geschriebener Code. Wer Bausteine an Kunden weitergibt, kann sie zudem schützen, sodass die Funktion nutzbar ist, der innere Aufbau aber nicht eingesehen werden kann.

Das durchziehende Beispiel ist ein FB Förderband-Steuerung. Seine Aufgabe: ein Band starten und stoppen, eine Selbsthaltung für das Startsignal führen und eine Störung melden, wenn der Antrieb nicht anläuft. Die Schnittstelle könnte so aussehen:

IN: Start (BOOL), Stopp (BOOL), Antrieb_laeuft (BOOL, Rückmeldung)
OUT: Band_ein (BOOL), Stoerung (BOOL)
STAT: Selbsthaltung (BOOL), Anlaufzeit (TIME)

Geschrieben wird dieser FB genau einmal. Hat eine Anlage drei Förderbänder, ruft man den FB dreimal auf – mit drei Instanz-DBs, etwa iDB_Band1, iDB_Band2 und iDB_Band3. Jedes Band führt damit seine eigene Selbsthaltung und seinen eigenen Störungszustand, völlig unabhängig von den anderen. Würde man stattdessen die Logik dreimal von Hand kopieren, hätte man dreifachen Pflegeaufwand: Jede Änderung müsste an drei Stellen nachgezogen werden, und jede Stelle wäre eine neue Fehlerquelle.

Die Grundlage für diese Wiederverwendbarkeit ist die herstellerübergreifende Programmiernorm ÖNORM EN 61131-3, die den Aufbau von Bausteinen, die Datentypen und die Programmiersprachen einheitlich festlegt. Dadurch lässt sich das Prinzip des strukturierten Programmierens unabhängig vom konkreten Fabrikat anwenden, auch wenn die Bedienoberflächen der Programmierwerkzeuge verschieden aussehen.

Die folgende Darstellung zeigt, wie der eine FB „Förderband-Steuerung“ dreimal aufgerufen wird und jeder Aufruf seinen eigenen Instanz-DB ansteuert.