IEC 61131-3 gehört zu den Normen, die in der industriellen Automatisierung als selbstverständlich gelten. Konstrukteure berufen sich darauf, Systemintegratoren führen sie in der Dokumentation auf, und Kunden gehen davon aus, dass ein „normkonformes“ System automatisch korrekt und leicht zu warten ist. In der Praxis ist das sehr oft nicht der Fall. Die Norm ordnet zwar die formale Darstellung eines PLC-Programms, schützt aber nicht vor Architekturfehlern. Und genau die Architektur entscheidet darüber, ob sich ein System nach der Inbetriebnahme dauerhaft beherrschen und wirtschaftlich betreiben lässt.
Was regelt IEC 61131-3 tatsächlich?
IEC 61131-3 definiert ein formales Programmiermodell für speicherprogrammierbare Steuerungen. Sie legt fest, was unter Ressource, Task und Program Organization Unit zu verstehen ist, und führt eine einheitliche Aufteilung in Program, Function Block und Function ein. Außerdem standardisiert sie die Programmiersprachen und deren semantisches Verhalten. Dadurch lassen sich Projekte zwischen unterschiedlichen Plattformen und Engineering-Umgebungen besser lesen und übertragen, und Ingenieure müssen nicht jedes Mal ein komplett neues Grundmodell lernen.
Gleichzeitig schreibt die Norm keine logische Programmstruktur vor. Sie sagt nicht, wie Verantwortlichkeiten zu schneiden sind, wo der Prozesszustand liegen soll, wie Fehlerbehandlung zu organisieren ist oder wie man sequenzielle Logik sauber entwirft. Sie lässt sowohl sinnvolle Lösungen zu als auch solche, die nur deshalb „funktionieren“, weil sie bisher niemand angefasst hat. Aus Sicht der Norm sind beide Varianten formal korrekt.
Program, Function Block und Function in realen Projekten
Die theoretische POU-Aufteilung kennt jeder Automatisierer, in der Praxis wird sie jedoch häufig zweckentfremdet. Sehr oft wird das Program zu einem einzigen großen Container für die komplette Logik, Function Blocks werden wie prozedurale Makros missbraucht, und der Prozesszustand verteilt sich über globale Variablen. So ein Aufbau funktioniert meist bei der Inbetriebnahme, macht aber schnell Probleme bei Änderungen und in der Diagnose.
In Projekten, die im Betrieb gut bestehen, übernimmt der Function Block die Rolle einer echten Repräsentation eines Prozessobjekts. Ein Ventil, ein Antrieb, eine Achse oder ein Sequenzbaustein hat einen eigenen Zustand, eigene Übergangsbedingungen und ein klar definiertes Interface. Das Program ist dann nicht mehr der Ort für Detail-Logik, sondern eine koordinierende Ebene. Die Function bleibt ein Werkzeug für Berechnungen und einfache, zustandslose Operationen. Diese Trennung folgt nicht direkt aus der Norm, aber ohne sie verliert ein PLC-System sehr schnell an Klarheit.
Programmiersprache und Wartbarkeit des Codes
IEC 61131-3 erlaubt mehrere Programmiersprachen und auch deren Mischung innerhalb eines Projekts. In der Praxis entstehen Probleme selten dadurch, ob LD, FBD oder ST verwendet wurde. Kritisch wird es dann, wenn keine klaren Regeln existieren, wo und wofür eine Sprache eingesetzt werden soll. Sequenzlogik in Ladder-Plänen, Algorithmen-Fragmente über verschiedene POUs verteilt und fehlende Konsequenz in der Benennung führen dazu, dass Code schwer zu analysieren ist.
Im Störfall oder bei einer Modernisierung muss man in solchen Projekten die Absicht des Autors erraten, statt technisch sauber zu analysieren. Die Norm lässt solche Lösungen zu, schützt aber nicht vor deren Folgen. Das ist ein weiteres Beispiel dafür, dass Konformität zu IEC 61131-3 nicht gleichbedeutend ist mit guter ingenieurmäßiger Praxis.
Wo die Norm hilft – und wo sie ein trügerisches Sicherheitsgefühl erzeugt
IEC 61131-3 ist als gemeinsames Fundament für die industrielle Automatisierung sehr nützlich. Sie erleichtert die Kommunikation zwischen Teams, standardisiert Grundbegriffe und macht es möglich, fremde Projekte zu lesen, ohne ständig über Intentionen spekulieren zu müssen. In diesem Rahmen erfüllt sie ihre Aufgabe sehr gut.
Das Problem beginnt, wenn die Norm als Qualitätsgarantie verstanden wird. Sie bewertet keine Programmarchitektur, erzwingt keine Einschränkung globaler Variablen und schreibt keine Regeln für die Fehlerbehandlung vor. Sie erlaubt Projekte, die formal korrekt sind, in der Praxis aber hohe Wartungskosten verursachen. Ohne zusätzliche Projektregeln liefert die Norm vor allem ein Gefühl von Ordnung, das nach der ersten größeren Änderung am System schnell verschwindet.
Zusammenfassung
IEC 61131-3 ist eine solide Grundlage für die PLC-Programmierung, aber kein Rezept für ein gutes Automatisierungsprojekt. Die Norm definiert Sprache und formales Modell, die Qualität eines Systems entsteht jedoch durch die Programmstruktur und den Umgang mit den verfügbaren Mechanismen. In der industriellen Praxis entscheidet die Code-Architektur – nicht die Wahl der Sprache – darüber, ob sich ein System über Jahre sicher warten und weiterentwickeln lässt. Ist die Struktur schlecht, rettet Normkonformität das Projekt nicht. Ist die Struktur sauber, wird die Norm zu einem passenden Werkzeug – und nicht zu einer Belastung.
