Speicherprogrammierbare Steuerungen stammen aus einer Zeit, in der jeder Hersteller seine eigene Programmierumgebung, eigene Mnemoniken und eigene Datentypen mitbrachte. Code war nicht portierbar, Wartungstechniker mussten für jede Plattform neu geschult werden, und das Wissen um eine bestimmte Steuerung blieb oft an einzelne Personen gebunden. Die Normierungsarbeit, die 1993 mit der ersten Veröffentlichung von IEC 61131-3 abgeschlossen wurde und zuletzt 2013 in ihrer dritten Edition vorliegt, hat diese Situation grundlegend verändert.
IEC 61131-3 ist der dritte Teil der übergeordneten Normenreihe IEC 61131, die sich mit speicherprogrammierbaren Steuerungen in ihrer Gesamtheit befasst. Während Teil 1 Begriffe und Anforderungen an die Hardware definiert und Teil 2 Prüfanforderungen festlegt, regelt Teil 3 ausschließlich die Softwarestruktur und die zulässigen Programmiersprachen. Genau dieser Teil hat in der Praxis die größte Wirkung entfaltet.
Das Softwaremodell: POUs, Ressourcen und Tasks
Bevor die einzelnen Sprachen betrachtet werden, ist das Softwaremodell der Norm zu verstehen. IEC 61131-3 strukturiert ein SPS-Programm in sogenannte Program Organization Units (POUs). Es gibt drei Arten: das Programm (PROGRAM), den Funktionsbaustein (FUNCTION_BLOCK) und die Funktion (FUNCTION). Programme stellen die oberste Ausführungsebene dar und werden einer Ressource zugewiesen. Ressourcen entsprechen im Wesentlichen einem Prozessor oder einer CPU innerhalb der Steuerungskonfiguration.
Funktionsbausteine sind das zentrale Wiederverwendungskonzept der Norm. Sie besitzen einen internen Zustand, der zwischen zwei Aufrufen erhalten bleibt, und können instanziiert werden – ähnlich wie Objekte in objektorientierten Sprachen. Funktionen hingegen sind zustandslos: Gleiche Eingabe führt stets zur gleichen Ausgabe, ein Verhalten, das sie besonders für mathematische Operationen und Signalverarbeitung geeignet macht. Tasks steuern den zeitlichen Ablauf der Programme und Funktionsbausteine; sie können zyklisch, ereignisgesteuert oder einmalig ausgeführt werden.
Die fünf Programmiersprachen im Überblick
IEC 61131-3 definiert fünf Sprachen, die in zwei Gruppen fallen: textuelle Sprachen und grafische Sprachen. Zu den textuellen Sprachen zählen Instruction List (IL) und Structured Text (ST). IL orientiert sich an Assembler-Mnemoniken und ist maschinennahe, jedoch wenig lesbar; in der dritten Edition der Norm wird IL als veraltet eingestuft und soll in zukünftigen Revisionen entfernt werden. ST hingegen ähnelt Pascal oder C und erlaubt komplexe Algorithmen, Schleifen, Bedingungen und Typkonvertierungen. ST hat sich als die leistungsfähigste Textsprache der Norm etabliert und gewinnt gerade in datenintensiven Anwendungen kontinuierlich an Bedeutung.
Zu den grafischen Sprachen gehören Ladder Diagram (LD), Function Block Diagram (FBD) und Sequential Function Chart (SFC). LD bildet die Relaistechnik grafisch nach: Kontakte und Spulen werden in Leiterstufen angeordnet, was den Einstieg für Elektrotechniker mit Schaltplankenntnis erleichtert. FBD verbindet normierte und benutzerdefinierte Funktionsbausteine durch Signalflüsse und eignet sich besonders gut für regelungstechnische Strukturen. SFC schließlich beschreibt sequenzielle Abläufe in Schritten und Transitionen und ist der einzige echte Zustandsautomat unter den fünf Sprachen – unverzichtbar für komplexe Maschinenprogramme mit klaren Zustandsübergängen.
Sprachauswahl nach Aufgabentyp
In der Praxis werden die Sprachen nicht exklusiv, sondern gemischt eingesetzt. Die Norm erlaubt ausdrücklich, dass verschiedene POUs in unterschiedlichen Sprachen geschrieben und dann gemeinsam in einem Projekt verwendet werden. Für die Auswahl gelten pragmatische Kriterien: Sicherheitsverriegelungen und einfache Binärlogik werden häufig in LD abgebildet, da die grafische Darstellung die Prüfung durch externe Stellen erleichtert. Regelkreise und Berechnungen landen typischerweise in ST oder FBD. Maschinenprogramme mit klaren Betriebszuständen – Einrichten, Automatikbetrieb, Störung, Referenzfahrt – profitieren von SFC als übergeordneter Strukturierungsebene, die dann einzelne ST- oder LD-Aktionen aufruft.
Ein verbreiteter Ansatz in der industriellen Praxis ist die hierarchische Kombination: SFC auf Programmebene steuert den Ablauf, Funktionsbausteine in ST oder FBD kapseln die Technologiefunktionen, und LD-Bausteine dokumentieren sicherheitsrelevante Verriegelungslogik. Diese Schichtung trennt Ablauflogik, Technologiefunktionen und Sicherheitsfunktionen sauber voneinander und vereinfacht sowohl Inbetriebnahme als auch spätere Änderungen.
Datentypen, Variablen und Typsicherheit
IEC 61131-3 definiert ein umfassendes Typsystem mit elementaren Datentypen – BOOL, INT, DINT, REAL, TIME, DATE, STRING und weitere – sowie abgeleiteten Typen wie Enumerationen, Strukturen (STRUCT) und Arrays. Die starke Typisierung ist bewusst gewählt: Der Compiler soll Typfehler bereits zur Übersetzungszeit erkennen, nicht erst zur Laufzeit. Das erhöht die Softwarequalität deutlich gegenüber typunsicheren Lösungen, wie sie in frühen proprietären Umgebungen üblich waren.
Variablen werden explizit in Deklarationsabschnitten eingeführt, getrennt vom ausführbaren Code. Die Norm unterscheidet Eingangs-, Ausgangs-, Eingangs-Ausgangs-, lokale und externe Variablen. Besonders wichtig ist die Unterscheidung zwischen VAR_INPUT und VAR_IN_OUT: Während Eingangsvariablen kopiert übergeben werden, arbeitet VAR_IN_OUT auf der Originaladresse – eine Quelle für Seiteneffekte, die in Codereview-Prozessen besondere Beachtung verdient.
Objektorientierte Erweiterungen seit der dritten Edition
Mit der dritten Edition aus dem Jahr 2013 hat IEC 61131-3 objektorientierte Konzepte eingeführt: Vererbung für Funktionsbausteine, Interfaces, Methoden und Properties. Funktionsbausteine können nun voneinander erben und polymorphes Verhalten zeigen. Ein Basisklassen-Funktionsbaustein für einen generischen Antrieb kann durch spezialisierte Bausteine für Servo, Frequenzumrichter oder Schrittmotor erweitert werden, ohne den aufrufenden Code zu ändern. Diese Mechanismen ermöglichen eine sauberere Bibliotheksstruktur und reduzieren Codeduplizierung in großen Projekten erheblich.
Allerdings variiert die Unterstützung dieser Erweiterungen unter den Laufzeitumgebungen verschiedener Hersteller noch. Wer plattformübergreifende Portierbarkeit anstrebt, sollte den Einsatz objektorientierter Konstrukte vorab gegen die Ziellaufzeit prüfen und im Projektstandardwerk dokumentieren, welche Sprachkonstrukte freigegeben sind.
Praxis: Portierbarkeit, Testbarkeit und Ausblick
IEC 61131-3 verspricht Portierbarkeit, garantiert sie aber nicht vollständig. Herstellerspezifische Bibliotheken, proprietäre Datentypen und abweichende Sprachdialekte schränken die reale Übertragbarkeit ein. Dennoch hat die Norm das Fundament für einen Markt an herstellerunabhängigen Engineeringwerkzeugen gelegt. Tools wie CODESYS fungieren als normkonforme Laufzeit- und Entwicklungsplattform, auf der zahlreiche Steuerungshersteller ihre Produkte aufbauen – das reduziert Einarbeitungszeiten und erleichtert den Wechsel zwischen Projekten auf unterschiedlicher Hardware.
Die wachsende Bedeutung von Unit-Tests in der SPS-Entwicklung zeigt, wie reif die Disziplin geworden ist. Frameworks für automatisierte Tests von Funktionsbausteinen, die auf IEC-61131-3-Konventionen aufsetzen, ermöglichen kontinuierliche Integration auch in der Steuerungsentwicklung. Kombiniert mit dem Trend zu softwaredefinierten Steuerungen und virtuellen SPS-Instanzen gewinnt eine solide Kenntnis des Normenwerks weiter an Bedeutung – nicht als historisches Artefakt, sondern als aktive Grundlage moderner, wartbarer und skalierbarer Automatisierungssoftware.
