Welche Programmiersprachen werden für SPS verwendet?

Speicherprogrammierbare Steuerungen werden in der Praxis überwiegend mit den fünf Sprachen der Norm IEC 61131-3 programmiert: Kontaktplan (KOP/LD), Funktionsplan (FUP/FBD), Ablaufsprache (AS/SFC), Strukturierter Text (ST, bei Siemens SCL) und Anweisungsliste (AWL/IL). Dazu kommen herstellerspezifische Ausprägungen und Erweiterungen, etwa in TIA Portal, CODESYS, TwinCAT oder Studio 5000, sowie in Sonderfällen Hochsprachen wie C/C++ für rechenintensive Aufgaben oder Bildverarbeitung.

Diese Aufzählung allein hilft im Projektalltag jedoch wenig. Entscheidend ist, welche Sprache für welche Aufgabe trägt: Eine Verriegelungslogik lässt sich im Kontaktplan von der Nachtschicht in Minuten nachvollziehen, ein Rezeptverwaltungsalgorithmus dagegen kaum. Umgekehrt wird ein PID-Regler in Strukturiertem Text kompakt und nachvollziehbar, während grafische Darstellungen dabei schnell unübersichtlich werden.

Die tragfähigste Sprachwahl ergibt sich weniger aus der technischen Leistungsfähigkeit als aus der Frage, wer den Code später liest, ändert und im Störungsfall diagnostizieren muss. Genau darauf gehen die folgenden Abschnitte ein: Grundlagen, Normrahmen, Sprachvergleich, Werkzeuglandschaft, Auswahlkriterien und die organisatorischen Konsequenzen für Wartung und Qualifikation.

Das Wichtigste in Kürze: Die IEC 61131-3 definiert fünf Standardsprachen, die Hersteller jedoch unterschiedlich benennen und umsetzen. Grafische Sprachen punkten bei Diagnose und Verriegelungen, textbasierte Sprachen bei Algorithmen und Datenverarbeitung. Lesbarkeit im Schichtbetrieb, Änderungsmanagement und Qualifikation der Mitarbeitenden entscheiden über die Betriebsfähigkeit einer Anlage mit.

Eine SPS ist ein industrietauglicher Kleinrechner, der Sensorsignale einliest, sie nach einer festgelegten Logik verarbeitet und Aktoren ansteuert. Dieser Ablauf wiederholt sich zyklisch, typischerweise im Bereich von wenigen Millisekunden. Programme werden also nicht einmal durchlaufen, sondern permanent neu abgearbeitet. Das prägt die Denkweise: Zustände müssen aktiv gehalten oder zurückgesetzt werden, und eine Zeile Code wirkt anders als in einer klassischen Anwendungsentwicklung.

Aus dieser Zyklusarbeitsweise folgen drei praktische Konsequenzen. Erstens spielt die Zykluszeit eine Rolle: Aufwendige Berechnungen in jedem Zyklus können die Steuerung ausbremsen. Zweitens ist die Programmstruktur wichtiger als sprachliche Eleganz, weil Programme in Funktionsbausteine, Funktionen und Datenbausteine aufgeteilt werden und diese Bausteine über Jahre wiederverwendet werden. Drittens erfolgt die Fehlersuche fast immer im laufenden Betrieb, per Beobachtung von Signalzuständen an der Anlage.

Die Programmiersprache ist deshalb nur ein Teil des Bildes. Ebenso relevant sind Variablendeklaration und Symbolik, eine saubere Adressvergabe für Ein- und Ausgänge, Bausteinbibliotheken und die Dokumentation. In Projekten, in denen Anlagen später erweitert oder verlagert wurden, hat sich regelmäßig gezeigt: Nicht die Sprachwahl bremste, sondern kryptische Symbolnamen, fehlende Kommentare und Bausteine ohne klare Schnittstellenbeschreibung. Eine gute Vorarbeit an dieser Stelle zahlt sich stärker aus als jede Sprachdiskussion.

IEC 61131-3 als zentraler Standard

Die Norm IEC 61131-3, in Deutschland als DIN EN 61131-3 geführt, beschreibt nicht nur Sprachen, sondern auch Datentypen, Variablenkonzepte und den Aufbau von Programmorganisationseinheiten. Sie schafft damit eine gemeinsame Grundlage über Herstellergrenzen hinweg. Fünf Sprachen sind spezifiziert, davon drei grafische (KOP, FUP, AS) und zwei textbasierte (ST, AWL).

Ein realistischer Blick auf die Praxis gehört dazu: Die Norm bringt konzeptionelle, nicht buchstäbliche Portierbarkeit. Ein CODESYS-Projekt lässt sich nicht ohne Weiteres in ein TIA-Portal-Projekt übertragen. Bausteinbibliotheken, Adressierung, Systemfunktionen und Ausnahmebehandlung unterscheiden sich. Auch die Bezeichnungen weichen ab, was Einsteiger regelmäßig verunsichert.

IEC-Bezeichnung	Deutsche Bezeichnung	Typische Siemens-Bezeichnung	Typ
LD (Ladder Diagram)	Kontaktplan	KOP	grafisch
FBD (Function Block Diagram)	Funktionsplan	FUP	grafisch
SFC (Sequential Function Chart)	Ablaufsprache	S7-GRAPH	grafisch
ST (Structured Text)	Strukturierter Text	SCL	textbasiert
IL (Instruction List)	Anweisungsliste	AWL	textbasiert

Was die Norm tatsächlich zuverlässig liefert, sind übertragbare Konzepte: strukturierte Datentypen, klar definierte Bausteinschnittstellen, wiederverwendbare Funktionsbausteine und ein Denkmodell, das Ingenieurinnen und Ingenieure beim Wechsel der Plattform behalten. Die Anweisungsliste wird von mehreren Herstellern nicht mehr weiterentwickelt oder gilt als abgekündigt, was bei Neuprojekten berücksichtigt werden sollte.

Die fünf klassischen SPS-Sprachen im Vergleich

Jede der fünf Sprachen hat ein Feld, in dem sie klar überlegen ist, und eines, in dem sie zur Belastung wird. Die folgende Übersicht ordnet sie nach typischen Aufgaben, Diagnosefähigkeit und Qualifikationsbedarf.

Kontaktplan (KOP/LD) stammt direkt aus dem Stromlaufplan. Kontakte und Spulen, Signalfluss von links nach rechts. Für Verriegelungen, Start-Stopp-Logik, Freigaben und Sicherheitsquittierungen ist er das naheliegende Werkzeug, und für Elektrofachkräfte im Schichtbetrieb die zugänglichste Darstellung. Bei Berechnungen, Schleifen oder Datenstrukturen wird KOP schnell unleserlich.

Funktionsplan (FUP/FBD) arbeitet mit Blöcken und Verbindungen nach dem Datenflussprinzip. Er eignet sich für Regelungsstrecken, Signalverarbeitung und modulare Bausteine, die mehrfach eingesetzt werden. Im Bereich der Sicherheitstechnik ist FUP verbreitet, weil sich Sicherheitsbausteine sauber verschalten und prüfen lassen.

Ablaufsprache (AS/SFC) beschreibt Schritte und Weiterschaltbedingungen. Für Taktstraßen, Reinigungsprogramme, Chargenprozesse oder Anfahr- und Abfahrsequenzen ist sie unschlagbar transparent: Man sieht auf dem Bildschirm, in welchem Schritt die Anlage steht und welche Bedingung fehlt. Für rein kombinatorische Logik ist sie überdimensioniert.

Strukturierter Text (ST/SCL) ist eine Hochsprache mit Pascal-ähnlicher Syntax, mit IF-THEN-ELSE, CASE, FOR und WHILE. Sie ist die erste Wahl für Rezeptverwaltung, Datenauswertung, Kommunikationsroutinen, Skalierungen, Statistik und eigene Funktionsbausteine. Der Preis: Wer sie nicht liest, kann bei einer Störung nicht eingreifen.

Anweisungsliste (AWL/IL) ist maschinennah und assemblerähnlich. Sie erlaubt maximale Optimierung, verlangt aber tiefes Wissen über die Steuerungsarchitektur. In Bestandsanlagen trifft man sie noch, für Neuprojekte spricht wenig dafür.

Sprache	Stärke	Grenze	Diagnose im Störfall	Einstiegshürde
KOP	Verriegelungen, Freigaben	Rechnen, Datenverarbeitung	sehr gut	niedrig
FUP	Regelung, Sicherheitsbausteine	verzweigte Sequenzen	gut	niedrig bis mittel
AS	Ablaufsteuerung, Schrittketten	einfache Logik	sehr gut	mittel
ST/SCL	Algorithmen, Rezepte, Daten	schnelle Sichtprüfung	mittel	höher
AWL	Optimierung, Altsysteme	Lesbarkeit, Pflege	schwach	hoch

In der Praxis wird selten eine Sprache allein genutzt. Bewährt hat sich eine bewusste Mischung: Schrittketten in AS, Verriegelungen in KOP, Berechnungen und Kommunikationsbausteine in ST.

Herstellerspezifische und moderne Entwicklungsumgebungen

Die Norm beschreibt Sprachen, die Entwicklungsumgebung entscheidet über den Arbeitsalltag. Siemens TIA Portal deckt KOP, FUP, SCL, S7-GRAPH und in Grenzen AWL ab, mit S7-PLCSIM zur Simulation. CODESYS dient als plattformübergreifende Basis für viele Steuerungshersteller und unterstützt alle fünf Sprachen samt CFC. Beckhoff TwinCAT setzt auf CODESYS-Wurzeln und integriert die Steuerung in Visual Studio, was C++-Module und Messtechnikanbindung erleichtert. Rockwell Studio 5000 ist stark im Kontaktplan geprägt, mit Function Block, Structured Text und Sequential Function Chart als Ergänzung.

Diese Unterschiede sind keine Details. Sie bestimmen, wie Bibliotheken verwaltet werden, wie Online-Änderungen ablaufen, ob Versionsvergleiche brauchbar sind und wie gut sich Projekte in eine Versionsverwaltung einbinden lassen. Bei textbasiertem Code ist der Vergleich zweier Programmstände deutlich einfacher als bei grafischen Bausteinen, ein Punkt, der im Änderungsmanagement oft unterschätzt wird.

Über die klassische SPS hinaus rücken weitere Ansätze in den Blick:

• C/C++ für Bildverarbeitung, aufwendige Mathematik oder Kopplung an Fremdsysteme, meist auf Industrie-PCs
• Python auf Edge-Geräten für Datenaufbereitung, Auswertung und Anbindung an MES- oder CAQ-Systeme
• Motion-Control- und Roboterprogrammierung mit eigenen Sprachen, die neben der SPS koordiniert werden müssen
• IEC 61499 für verteilte, ereignisorientierte Systeme, bislang eher in Forschung und Sonderprojekten
• OPC UA nicht als Sprache, aber als Schnittstellenstandard, der Datenmodelle bereits im Steuerungsprogramm sauber strukturieren verlangt

Wer papierlose Qualitätssicherung oder MES-Anbindungen umsetzt, merkt schnell: Die Datenstruktur in der Steuerung entscheidet über den Aufwand auf der IT-Seite. In Projekten zur Prozessdigitalisierung begleiten wir bei Kontor Gruppe genau diese Schnittstelle zwischen Automatisierung, Qualitätsdaten und Fertigungssteuerung.

Auswahlkriterien für Sprache und Steuerungsprojekt

Die Sprachwahl ist eine Betriebsentscheidung, nicht nur eine technische. Fünf Fragen führen in der Praxis zu einer belastbaren Festlegung.

1. Welche Aufgabe liegt vor? Verriegelung, Schrittkette, Regelung oder Datenverarbeitung führen zu unterschiedlichen Antworten. Eine ehrliche Aufgabenanalyse vor der Sprachdiskussion erspart spätere Umbauten.

2. Wer arbeitet später am Code? Wenn die Instandhaltung nachts allein an der Anlage steht, muss der Code für dieses Team lesbar sein. Ein perfekt gekapselter ST-Baustein ohne Diagnoseoberfläche verlängert die Stillstandszeit.

3. Welche Vorgaben gelten? Kundenspezifische Programmierrichtlinien, Konzernstandards, Anforderungen aus der Sicherheitstechnik oder aus regulierten Bereichen wie Medizintechnik und Pharma schränken die Freiheit teils erheblich ein. Bei validierungspflichtigen Anlagen zählt Nachvollziehbarkeit mehr als Eleganz.

4. Wie ist die Bestandslandschaft? Eine gewachsene Anlage mit AWL-Altcode lässt sich nicht in einem Schritt umstellen. Sinnvoll ist eine Grenzziehung: Bestand bleibt, Neuentwicklungen folgen dem neuen Standard.

5. Wie sieht der Lebenszyklus aus? Bei einer Anlage mit fünfzehn Jahren Laufzeit wiegen Wartbarkeit, Ersatzteilverfügbarkeit und Verfügbarkeit qualifizierter Dienstleister schwerer als eine kurze Erstinbetriebnahme.

Praktisch bewährt hat sich eine schriftliche Programmierrichtlinie mit wenigen klaren Festlegungen: welche Sprache für welche Aufgabenklasse, Namenskonventionen, Kommentarpflicht, Bausteinbibliothek und Freigabeprozess für Änderungen. Zwei Seiten genügen oft, sofern sie eingehalten und bei Lieferantenanfragen mitgeschickt werden.

Praxis: Wartbarkeit, Sicherheit und Mitarbeiterqualifikation

Der teuerste Fehler in SPS-Projekten ist selten eine falsche Sprache. Er entsteht, wenn niemand im Haus den Code versteht. Anlagen, deren Programm ausschließlich vom Maschinenlieferanten beherrscht wird, verursachen bei jeder Störung Wartezeit und bei jeder Anpassung Verhandlungsaufwand. Eine schrittweise Verlagerung von Kompetenz in das eigene Team senkt dieses Risiko messbar.

Bewährte Punkte aus der Umsetzung:

• Quellcode und Projektstände sichern: vollständiges Projekt inklusive Bibliotheken, Versionsstand dokumentiert, Zugriff nicht an eine Einzelperson gebunden.
• Diagnose mitentwickeln: Störmeldungen mit Klartext, Schrittanzeige der Ablaufketten, Freigabebedingungen sichtbar auf dem Bedienpanel. Das reduziert Stillstandszeiten stärker als jede Codeoptimierung.
• Änderungen nachvollziehbar halten: Änderungsprotokoll, Versionierung, Freigabe durch eine zweite Person. Online-Änderungen im laufenden Betrieb sollten die Ausnahme mit klarer Regel sein.
• Sicherheitstechnik trennen: Sicherheitsfunktionen gehören in eine dafür zugelassene Sicherheitssteuerung mit geprüften Bausteinen, klar abgegrenzt von der Standardlogik. Sicherheitsprogramme unterliegen eigenen Abnahme- und Dokumentationsanforderungen.
• Qualifikation gestaffelt aufbauen: Instandhaltung braucht Leseverständnis und Diagnosefähigkeit, technische Projektleitung braucht Bewertungskompetenz für Lieferantencode, ein kleiner Kreis braucht volle Programmierkompetenz einschließlich ST.

Für kleine und mittlere Unternehmen ist der Aufbau in Stufen realistischer als eine breite Schulungsoffensive. Ein Einstieg mit Lesen und Diagnose an der eigenen Anlage, gefolgt von einfachen Änderungen unter Begleitung, bringt schneller Wirkung als ein Standardkurs ohne Anlagenbezug. Genau an dieser Verbindung von Automatisierung, stabilen Prozessen und Mitarbeiterqualifizierung setzen unsere Projekte an, weil ein SPS-Programm erst dann verlässlich ist, wenn Menschen im Betrieb damit arbeiten können.