Die 5 SPS-Programmiersprachen nach IEC 61131-3 im Vergleich

1.Was die IEC 61131-3 regelt

Die IEC 61131-3 ist der internationale Standard für die Programmierung speicherprogrammierbarer Steuerungen. Sie legt nicht nur Sprachen fest, sondern auch Datentypen, Bausteinarten (Funktion, Funktionsbaustein, Programm) und das Ausführungsmodell.

Der praktische Nutzen: Wer nach dem Standard programmiert, schreibt Code, den ein anderer Programmierer auf einer anderen Steuerung lesen und verstehen kann. Portabel im Sinne von „per Copy-Paste übertragbar" ist er dadurch nicht – die Hersteller-Dialekte unterscheiden sich zu stark. Aber die Konzepte sind dieselben, und das ist in der Praxis der wichtigere Teil.

2.Norm-Bezeichnung und Siemens-Bezeichnung

Hier entsteht die häufigste Verwirrung – auch in Fachartikeln. Die Norm kennt fünf Sprachen; Siemens verwendet für dieselben Sprachen eigene Namen:

Eine weitere Feinheit: SFC ist streng genommen keine Programmiersprache, sondern ein Strukturierungselement. In den Schritten und Transitionen eines SFC steht wiederum Code in einer der anderen Sprachen. In der Praxis wird SFC trotzdem als fünfte Sprache mitgezählt, und die Norm behandelt sie im selben Teil.

3.Die fünf Sprachen im Vergleich

3.1.KOP (Kontaktplan)

Der Kontaktplan bildet die Stromlaufplan-Logik nach: Kontakte in Reihe entsprechen einer UND-Verknüpfung, parallel einer ODER-Verknüpfung. Für Instandhalter mit elektrotechnischem Hintergrund ist das die Sprache mit der niedrigsten Einstiegshürde – ein unschätzbarer Vorteil, wenn nachts jemand ohne Programmierkenntnisse eine Verriegelung nachvollziehen muss.

Die Grenze zeigt sich bei Umfang und Rechnerei. Ein Netzwerk mit zwanzig Kontakten und drei Parallelzweigen ist gedruckt breiter als der Bildschirm, und eine Skalierung von Analogwerten wird in KOP zur Bausteinkette.

3.2.FUP (Funktionsplan)

FUP zeigt Signale als Blöcke mit Ein- und Ausgängen. Wo KOP den Strompfad betont, betont FUP den Datenfluss – das passt besser zu analoger Verarbeitung, Reglern und allem, was Werte transformiert statt schaltet.

3.3.AWL (Anweisungsliste)

AWL ist die maschinennächste Sprache, im Prinzip ein Assembler für die SPS. In der dritten Ausgabe der IEC 61131-3 (2013) wurde IL als veraltet (deprecated) eingestuft; für neue Projekte ist sie nicht mehr zu empfehlen.

Relevant bleibt sie aus einem Grund: Bestandsanlagen. Wer ein S5- oder S7-Classic-Programm übernimmt, trifft regelmäßig auf AWL – oft ohne Symbolik. Sie lesen zu können, ist bei Migrationen keine Nostalgie, sondern Handwerk.

3.4.SCL (Structured Text)

SCL ist die Sprache, in der sich alles ausdrücken lässt, was mit Grafik mühsam wird: Schleifen, Fallunterscheidungen, Berechnungen, Zeichenkettenverarbeitung, generische Bibliotheksbausteine.

// Beispiel: Analogwert skalieren mit Bereichsprüfung
FUNCTION FC_ScaleAnalog : REAL
VAR_INPUT
  iRaw        : INT;    // Rohwert 0…27648
  rMin, rMax  : REAL;   // Zielbereich in physikalischer Einheit
END_VAR

IF iRaw < 0 THEN
  FC_ScaleAnalog := rMin;          // Drahtbruch / Unterlauf
ELSIF iRaw > 27648 THEN
  FC_ScaleAnalog := rMax;          // Überlauf
ELSE
  FC_ScaleAnalog := rMin + (rMax - rMin) * INT_TO_REAL(iRaw) / 27648.0;
END_IF;

Derselbe Funktionsumfang in KOP wäre eine mehrzeilige Bausteinkette, deren Absicht man erst nach genauem Hinsehen erkennt.

Ein zweiter, oft unterschätzter Vorteil: SCL ist Text. Damit lässt er sich sinnvoll in Git versionieren, in Code-Reviews zeilenweise kommentieren und mit Werkzeugen durchsuchen. Grafische Sprachen liegen als Binärformat vor – ein Diff zeigt dort bestenfalls „Baustein geändert".

3.5.GRAPH (SFC)

GRAPH bildet Ablaufketten als Schritte und Transitionen ab. Der große Gewinn ist Sichtbarkeit: Der aktuelle Zustand der Anlage ist im Online-Modus direkt ablesbar, statt aus einem Dutzend Merkern rekonstruiert werden zu müssen.

Für Schrittketten – Chargenprozesse, Reinigungszyklen, Betriebsartenwechsel – ist das der entscheidende Vorteil bei der Fehlersuche. Für eine simple Verriegelung ist es Overhead.

4.Welche Sprache wofür: eine Entscheidungshilfe

Es gibt keine Sprache, die alles am besten kann. In der Praxis hat sich diese Aufteilung bewährt:

5.Mischen ist erlaubt – und sinnvoll

Ein verbreitetes Missverständnis: Man müsse sich für eine Sprache entscheiden. Das Gegenteil ist der Fall. Die Norm sieht ausdrücklich vor, dass jeder Baustein in der Sprache geschrieben wird, die zu seiner Aufgabe passt.

Ein typisches Projekt sieht dann so aus:

OB1 (Main)                         → KOP, nur Aufrufe
  ├── FB_ModeControl               → GRAPH (Betriebsarten als Schrittkette)
  ├── FB_ConveyorControl           → SCL (Logik + Timing)
  │     └── FC_ScaleAnalog         → SCL (Berechnung)
  ├── FC_SafetyInterlocks          → KOP (muss ohne Werkzeug lesbar sein)
  └── FB_AlarmHandler              → SCL (Bibliotheksbaustein)

Entscheidend ist nur, dass die Wahl begründet ist und im Projekt konsistent bleibt. Fünf Sprachen wahllos gemischt sind schlimmer als eine Sprache konsequent durchgezogen.

6.Fazit

• Die IEC 61131-3 definiert fünf Sprachen: LD, FBD, IL, ST und SFC. SCL ist Siemens' Name für ST, keine sechste Sprache.
• AWL/IL gilt seit 2013 als veraltet – lesen können ja, neu schreiben nein.
• SCL trägt den Großteil moderner Projekte, weil es Berechnungen, Bibliotheken und Versionierung erlaubt.
• KOP bleibt für sicherheitsrelevante und wartungskritische Logik, weil Lesbarkeit im Störfall über Stillstandszeit entscheidet.
• Sprachen zu mischen ist normkonform und sinnvoll – solange die Wahl begründet und konsistent ist.

7.Weiterführende Artikel

• SPS-Programmierung: 8 Best Practices für sauberen, wartbaren Code – wie die Sprachwahl in eine Gesamtstruktur passt
• SPS-Dokumentation: Was hineingehört, was bei der Übergabe zählt – welche Sprache welche Dokumentationslast erzeugt
• Fehlersuche in SPS-Programmen: systematisch eingrenzen – warum GRAPH die Diagnose beschleunigt