IEC 61131-3 Programmiersprachen: ST, KOP, FUP und AS richtig einsetzen

Die IEC 61131-3 Programmiersprachen sind seit der Ausgabe 2025 Structured Text (ST) als textuelle Sprache, Kontaktplan (KOP, englisch LD) und Funktionsbausteinsprache (FUP, englisch FBD) als grafische Sprachen sowie die Ablaufsprache (AS, englisch SFC) zur Strukturierung. Die Anweisungsliste (AWL, englisch IL) wird in der Beschreibung der neuen Ausgabe nicht mehr als Sprache geführt. Für die Praxis heißt das: Neuer Code gehört nicht mehr in AWL, Bestandscode sollte bei der nächsten Gelegenheit überführt werden.

Die IEC 61131-3:2025 ist am 22. Mai 2025 als Edition 4.0 erschienen und hat die Ausgabe von 2013 ersetzt. Laut IEC-Webstore listet ein Anhang alle Merkmale, die seit 2013 hinzugekommen, entfallen oder als veraltet markiert sind. Neu sind unter anderem Zeichenketten in UTF-8. Die Organisation PLCopen bezeichnet die IEC 61131-3 als einzigen globalen Standard für die Programmierung industrieller Steuerungen.

IEC 61131-3 Programmiersprachen im Vergleich

Welche Sprache wofür? Unsere Faustregeln

Es gibt keine beste Sprache, aber es gibt schlechte Kombinationen. Der häufigste Fehler in Bestandsanlagen ist eine komplexe Berechnung in KOP, die über drei Bildschirmseiten geht, oder eine einfache Verriegelung in ST, die der Instandhalter nachts nicht lesen kann. Unsere Faustregeln:

• Verriegelungen und Freigaben in KOP oder FUP. Der Elektriker an der Maschine muss sie online beobachten und verstehen können.
• Schrittketten in AS oder als sauber programmierte CASE-Struktur in ST. Wichtig ist, dass der aktive Schritt im HMI sichtbar ist.
• Berechnungen, Datenhandling, Kommunikation in ST. Schleifen über Arrays sind in grafischen Sprachen unleserlich.
• Bibliotheksbausteine in ST, mit klarer Schnittstelle und ausführlichem Kopfkommentar.
• Sicherheitsprogramme in KOP oder FUP mit zertifizierten Bausteinen. Je einfacher, desto leichter die Validierung.

Was mit AWL-Bestandscode passiert

In deutschen Werken steckt noch viel AWL, vor allem in S7-300- und S7-400-Anlagen. Siemens unterstützt AWL auf der S7-1500 weiterhin, auf der S7-1200 dagegen nicht, wie der Siemens-Migrationsleitfaden festhält. Im selben Dokument weist Siemens darauf hin, dass indirekte Adressierung und Slicing auch in KOP, FUP und SCL möglich sind, AWL also für diese Aufgaben nicht mehr nötig ist.

Unsere Empfehlung: Lassen Sie funktionierenden AWL-Code bei einer reinen Hardwaremigration zunächst stehen, wenn er getestet und stabil ist. Überführen Sie ihn dann schrittweise, beginnend mit den Bausteinen, an denen am häufigsten geändert wird. AWL-Code mit Sprungleisten und Registeroperationen ist für jüngere Techniker kaum zu warten, und dieses Problem wird jedes Jahr größer. Mehr zur Migration im Beitrag S7-300 Migration auf S7-1500.

Objektorientierung: Nutzen mit Maß

Seit der Ausgabe 2013 kennt die Norm objektorientierte Elemente wie Methoden, Interfaces und Vererbung. CODESYS und TwinCAT unterstützen sie umfassend, im TIA Portal ist der Umfang kleiner. Für Bibliotheken mit vielen ähnlichen Komponenten, etwa Antriebe verschiedener Hersteller hinter einer gemeinsamen Schnittstelle, ist das ein echter Gewinn.

Übertreiben Sie es nicht. Eine Vererbungshierarchie über vier Ebenen ist in der Online-Beobachtung an der Maschine schwer nachzuvollziehen. Wir setzen Interfaces gezielt ein, wo sie Austauschbarkeit bringen, und halten die Maschinenlogik bewusst flach. Wer später an der Maschine steht, sollte den Code ohne Entwicklungsumgebung mit Klassendiagramm verstehen können.

Ein Beispiel: dieselbe Funktion in drei Sprachen

Nehmen Sie eine Motorfreigabe: Der Motor darf laufen, wenn der Not-Halt-Kreis geschlossen ist, die Schutztür zu ist, kein Motorschutz ausgelöst hat und die Betriebsart Automatik oder Hand aktiv ist. In KOP ist das ein Netzwerk mit vier Kontakten in Reihe und einer Parallelschaltung für die Betriebsarten. Jeder Elektriker sieht online sofort, welcher Kontakt fehlt. In FUP sieht es ähnlich übersichtlich aus. In ST ist es eine einzige Zeile mit UND- und ODER-Verknüpfungen, kompakt, aber in der Online-Beobachtung weniger anschaulich.

Ganz anders bei einer Rezepturverwaltung mit 50 Parametern pro Produkt, die aus einem Array in eine Achssteuerung kopiert und auf Grenzwerte geprüft werden. In ST sind das wenige Zeilen mit einer Schleife. In KOP würde es Dutzende Netzwerke füllen, die niemand mehr überblickt. Die Wahl der Sprache folgt also der Aufgabe, nicht der Gewohnheit des Programmierers. Mischen innerhalb eines Projekts ist ausdrücklich erlaubt und sinnvoll, solange die Grenzen klar sind.

Weitere Teile der Normenreihe

Die IEC 61131-3 ist Teil einer Normenreihe. PLCopen nennt unter anderem Teil 6 zur funktionalen Sicherheit, Teil 8 als Leitfaden für Anwendung und Implementierung, Teil 9 zu IO-Link und Teil 10 mit dem XML-Austauschformat von PLCopen. Gerade das XML-Format ist praktisch, wenn Code zwischen Werkzeugen ausgetauscht oder automatisch erzeugt werden soll. Die Unterstützung ist je nach Hersteller unterschiedlich weit, ein Test mit Ihren eigenen Bausteinen lohnt sich vor jeder Entscheidung.

Für Teams, die Code automatisch erzeugen oder prüfen wollen, etwa aus einer E/A-Liste oder mit Werkzeugen für statische Codeanalyse, ist ein offenes Austauschformat ein wichtiges Kriterium bei der Plattformwahl.

Für das Thema Sicherheit spielt die Sprachwahl übrigens auch normativ eine Rolle. Die DIN EN ISO 13849-1:2023 ordnet Sprachen nach IEC 61131-3 als Sprachen mit eingeschränktem Sprachumfang ein, was die Anforderungen an sicherheitsbezogene Anwendersoftware beeinflusst. Mehr dazu im Beitrag Software als Sicherheitsbauteil.

Wartens programmiert nach IEC 61131-3 in TIA Portal, TwinCAT und CODESYS. In unseren SPS-Schulungen in Oberhaching üben Teilnehmende ST, KOP und FUP an realen Aufgaben. Nächster Schritt: Wenn Sie Bestandscode in AWL modernisieren möchten, schicken Sie uns ein Projektarchiv, wir schätzen den Aufwand ein. Kontakt.