Programmiersprachen nach IEC 61131-3 (KOP, FUP, AWL, ST, AS)

In den Anfangsjahren der speicherprogrammierbaren Steuerung kochte jeder Hersteller sein eigenes Süppchen. Wer auf einer Siemens-Anlage programmieren konnte, stand vor einer fremden Steuerung eines anderen Herstellers oft wieder am Anfang. Das Wissen war an ein einzelnes System gebunden, nicht an die Sache selbst.

Genau hier setzt die IEC 61131 an – eine internationale Norm, die SPS-Systeme von der Hardware bis zur Programmierung beschreibt. Der für uns entscheidende Teil ist die IEC 61131-3: Sie legt fest, welche Programmiersprachen es gibt und wie ihre Sprachelemente aufgebaut sind. In Österreich gilt sie als ÖNORM EN 61131-3 und ist damit der verbindliche, herstellerübergreifende Bezugspunkt für die berufliche Praxis.

Wichtig ist das richtige Bild im Kopf: Die Norm definiert nicht eine einzige Sprache mit Varianten, sondern fünf gleichwertige Sprachen. Sie sind kein Entweder-oder. In einem realen Projekt darf – und soll – man sie mischen: ein Programmteil in der einen, ein anderer in der passenderen Sprache.

Die Sprachen laufen auf der SPS im immer gleichen Takt ab: Eingänge lesen, Programm verarbeiten, Ausgänge schreiben. Dieses zyklische Prinzip (EVA) und der grundsätzliche Aufbau einer SPS sind eigene Themen und werden hier vorausgesetzt. Für diesen Beitrag genügt: Egal in welcher der fünf Sprachen geschrieben, das Ergebnis wird intern in dieselbe abgearbeitete Logik übersetzt.

Die fünf Sprachen lassen sich in drei Gruppen einteilen:

Die beiden grafischen Sprachen zeigen die Logik als Bild – man sieht, wie Signale verknüpft sind, statt sie aus Textzeilen herauslesen zu müssen. Gerade beim Einstieg ist das ein großer Vorteil.

KOP – der Kontaktplan. KOP stammt direkt aus der klassischen Relais- und Schütztechnik. Eine Logik wird als Strompfad gezeichnet: links eine senkrechte Schiene, von der aus „Strom“ nach rechts durch Kontakte zu einer Spule fließt. Geschlossene Kontakte lassen das Signal durch, offene unterbrechen es. Wer schon einmal einen Stromlaufplan gelesen hat, findet sich sofort zurecht – der Kontaktplan sieht aus wie ein abstrahierter Schaltplan. Das macht KOP besonders bei Elektrikern und Mechatronikern beliebt, die aus der Verdrahtung kommen.

FUP – der Funktionsplan. FUP zeigt dieselbe Logik anders: als verschaltete Funktionsblöcke. Ein Block mit dem Symbol & ist eine UND-Verknüpfung, ein Block mit ≥1 eine ODER-Verknüpfung. Die Signale laufen von links als Eingänge in den Block und kommen rechts als Ergebnis heraus. Wer Logikgatter aus der Digitaltechnik kennt, erkennt FUP sofort wieder – es ist im Grunde die gleiche Denkweise.

Beide Sprachen beschreiben denselben Sachverhalt und lassen sich in den Engineering-Tools oft per Knopfdruck ineinander umwandeln. Welche man nimmt, ist häufig eine Frage der Herkunft und Gewohnheit: KOP für die „Relais-Denker“, FUP für die „Gatter-Denker“.

Wie eine Reihenschaltung zur UND-Bedingung wird, wie ODER-Verknüpfungen entstehen oder wie man eine Selbsthaltung aufbaut, behandeln eigene Beiträge ausführlich – hier wird das nicht vertieft. Für den Überblick reicht: KOP und FUP sind die erste Wahl für überschaubare bis mittlere Verknüpfungslogik – also dort, wo es um „Wenn diese Bedingungen erfüllt sind, dann schalte“ geht.

Ihre Grenze zeigt sich, sobald gerechnet werden muss. Sobald Formeln, viele Variablen oder verschachtelte Abl&aumlufe ins Spiel kommen, wird das Bild schnell unübersichtlich und zieht sich über viele Netzwerke. Dann sind die textuellen Sprachen klar im Vorteil.

Das folgende Schema zeigt dieselbe einfache Logik („Ausgang nur, wenn beide Bedingungen erfüllt“) einmal als KOP-Strompfad und einmal als FUP-Block:

Wo das Bild an seine Grenzen kommt, übernehmen die textuellen Sprachen. Hier wird Logik nicht gezeichnet, sondern als Folge von Zeilen geschrieben.

AWL – die Anweisungsliste. AWL ist die maschinennächste der fünf Sprachen. Das Programm besteht aus einzelnen Befehlszeilen, die nacheinander abgearbeitet werden: ein Signal laden, mit dem nächsten verknüpfen, das Ergebnis einem Ausgang zuweisen. Die Sprache ist sehr kompakt und liegt nah an dem, was die SPS intern wirklich tut. Der Preis dafür: AWL ist schwer zu lesen und zu warten. Schon bei mittlerem Umfang verliert man leicht den Überblick, weil man jede Zeile einzeln im Kopf nachvollziehen muss. In neuen Projekten ist AWL deshalb stark rückläufig und gilt vielerorts als Auslaufmodell – moderne Systeme setzen kaum noch darauf.

ST – der Strukturierte Text. ST ist eine echte Hochsprache und im Aufbau an Pascal angelehnt. Hier programmiert man mit Konstrukten, die aus der klassischen Softwareentwicklung vertraut sind: Bedingungen mit IF … THEN … ELSE, Fallunterscheidungen mit CASE, Schleifen mit FOR oder WHILE, dazu Variablen und Rechenoperationen. Das macht ST zur mächtigsten der fünf Sprachen, wenn es um komplexe Algorithmen, Berechnungen und Datenverarbeitung geht. Eine längere Formel, die in KOP über zig Netzwerke ginge, steht in ST in einer einzigen Zeile.

Eine Eigenheit von ST bringt Umsteiger aus Sprachen wie C oder Python regelmäßig ins Stolpern: Die Zuweisung wird mit := geschrieben, nicht mit =. Das einfache Gleichheitszeichen = ist in ST ein Vergleich. Wer also einer Variablen einen Wert geben will, schreibt x := 5;, und wer prüfen will, ob x gleich 5 ist, schreibt x = 5. Das ist genau die Pascal-Konvention, und gerade in der Praxis mit Systemen wie B&R oder Beckhoff führt die Verwechslung zu Fehlern, die man lange sucht.

Die Wahl zwischen grafisch und textuell läuft am Ende auf eine einfache Frage hinaus: Geht es um Verknüpfungslogik, sind KOP/FUP angenehmer; geht es um Rechnen und komplexe Strukturen, spielt ST seine Stärke aus. AWL kann zwar dasselbe wie ST, ist aber so unkomfortabel, dass es in neuen Anwendungen kaum noch eine Rolle spielt.

Die fünfte Sprache verfolgt eine ganz andere Idee als die übrigen vier. AS – die Ablaufsprache (auch SFC genannt) – beschreibt nicht eine einzelne Verknüpfung, sondern den zeitlichen Ablauf eines Prozesses: erst dieser Arbeitsschritt, dann jener, dann der nächste.

Das Grundgerüst besteht aus zwei Elementen: Schritten und Transitionen. Ein Schritt steht für einen Zustand, in dem eine bestimmte Aktion ausgeführt wird – etwa „Zylinder ausfahren“. Zwischen zwei Schritten liegt eine Transition, also eine Weiterschaltbedingung. Erst wenn diese Bedingung erfüllt ist (zum Beispiel „Endschalter erreicht“), wird der nächste Schritt aktiv und der vorige verlassen. So wandert die Aktivität Schritt für Schritt durch das Programm.

Damit eignet sich AS überall dort, wo ein Prozess in einer klaren Reihenfolge abläuft: Be- und Entladestationen, Verpackungsmaschinen, jede Art von Takt- oder Schrittprozess. Man sieht auf einen Blick, in welcher Phase die Anlage gerade steckt – ein großer Vorteil bei Inbetriebnahme und Fehlersuche.

Wichtig ist die Abgrenzung zu den anderen vier Sprachen: AS strukturiert nur den Ablauf. Was innerhalb eines Schrittes konkret passiert – die eigentliche Aktion und die Transitionsbedingungen – wird meist in einer der anderen Sprachen formuliert, oft in KOP, FUP oder ST. AS ist also weniger ein Konkurrent der übrigen Sprachen als eine Klammer, die sie ordnet.

Verwandt mit AS ist GRAFCET, das demselben Schritt-Transitions-Gedanken folgt. Der Unterschied ist wichtig: AS ist eine ausführbare Programmiersprache, die direkt auf der SPS läuft, während GRAFCET eine herstellerunabhängige Beschreibungs- und Dokumentationsform ist – man legt damit den Ablauf fest und entwickelt das Konzept, setzt es aber anschließend in einer ausführbaren Sprache um. Schrittketten und GRAFCET sind ein eigenes, ausführliches Thema und werden hier nur erwähnt.

Nachdem alle fünf Sprachen vorgestellt sind, lohnt der direkte Vergleich. Die folgende Tabelle stellt sie nach den Kriterien gegenüber, die in der Praxis über die Wahl entscheiden:

Daraus lassen sich ein paar einfache Faustregeln ableiten. Geht es um eine Verknüpfung – Bedingungen, die zusammen einen Ausgang schalten – greift man zu KOP oder FUP, je nach Gewohnheit. Steht eine Berechnung oder ein Algorithmus an, ist ST die beste Wahl. Beschreibt die Aufgabe einen Schritt-für-Schritt-Prozess, ordnet AS das Ganze. AWL nimmt man in neuen Projekten praktisch nur noch, wenn man bestehenden Altcode pflegen muss.