SPS / PLC

Eine SPS arbeitet in einem festen Zyklus. Zu Beginn liest sie alle Eingänge ein und legt ihren Zustand in einem Speicherbereich ab, dem Prozessabbild. Dann arbeitet sie das Programm ab und rechnet dabei mit diesem Abbild statt mit Signalen, die sich während des Durchlaufs ändern könnten. Am Ende schreibt sie die Ergebnisse auf die Ausgänge, und der Zyklus beginnt von vorn, oft im einstelligen Millisekundenbereich. Weil jeder Durchlauf gleich abläuft und eine Zeitüberwachung (Watchdog) die Steuerung bei zu langem Zyklus in einen definierten Zustand bringt, reagiert eine SPS vorhersagbar. Das unterscheidet sie von einem Büro-PC, auf dem ein Update oder Virenscanner jederzeit Rechenzeit abziehen kann.

Wie ist eine SPS aufgebaut? Klassisch aus Netzteil, CPU mit Speicher für Programm und Daten, digitalen und analogen Ein- und Ausgabebaugruppen sowie einer Feldbus- oder Ethernet-Schnittstelle wie PROFINET, EtherCAT oder EtherNet/IP, über die Sensoren, Aktoren und dezentrale Peripherie angebunden sind. Modulare Systeme wie die Siemens S7-1500 oder die Beckhoff-Klemmen lassen sich baugruppenweise erweitern, kompakte Steuerungen wie die S7-1200 bringen I/O auf der CPU-Baugruppe mit. Daneben gibt es Soft-SPS, die als Software auf einem Industrie-PC laufen, TwinCAT ist das bekannteste Beispiel. Für sicherheitsgerichtete Funktionen wie Not-Halt oder Schutztürüberwachung gibt es Safety-SPS nach IEC 61508, deren Programm getrennt vom Standardprogramm gepflegt und freigegeben wird.

Welche Programmiersprachen gibt es für SPS? Die Norm IEC 61131-3 definierte lange fünf: Kontaktplan (KOP, englisch LD), Funktionsbausteinsprache oder Funktionsplan (FUP, englisch FBD), Strukturierter Text (ST), Ablaufsprache (AS, englisch SFC) und Anweisungsliste (AWL, englisch IL). Die vierte Ausgabe der Norm vom Mai 2025 hat die Anweisungsliste gestrichen, nachdem sie seit der dritten Ausgabe von 2013 als veraltet galt. Hersteller dürfen AWL weiter anbieten, sie ist nur nicht mehr Teil des Standards. Kontaktplan und Funktionsplan sind grafisch und stammen aus der Welt der Schaltpläne, der Elektriker an der Anlage liest sie ohne Einarbeitung. Strukturierter Text ist eine Hochsprache mit Pascal-Verwandtschaft und trägt heute die aufwendige Logik wie Rezepturen, Berechnungen und Kommunikation. Die Ablaufsprache gliedert Schrittketten, etwa den Ablauf einer Füllstation von „Behälter einfahren“ bis „Deckel schließen“.

Die Hersteller setzen die Norm mit eigenen Namen um. Siemens nennt Strukturierten Text im TIA Portal SCL (Structured Control Language). AWL gibt es dort noch für S7-300, S7-400 und S7-1500, die S7-1200 kennt sie nicht. Beckhoff TwinCAT und CODESYS-basierte Systeme folgen der Norm eng und nennen die Sprache ST. Rockwell Automation programmiert in Studio 5000 vor allem in Ladder Logic und Structured Text, dazu Function Block Diagram und Sequential Function Chart. Für Versionierung und CI ist die Sprachwahl wichtig. Strukturierter Text und SCL liegen als Klartext vor und lassen sich in Git zeilenweise diffen. Grafische Sprachen brauchen dafür einen Export in ein textbasiertes Format, etwa über das Version Control Interface (VCI) des TIA Portal oder als PLCopen XML.

Lange waren SPS-Programme von moderner Softwareentwicklung abgeschnitten. Projekte lagen in proprietären Binärformaten, ein Diff zeigte nichts Brauchbares, und einen Review-Prozess gab es nicht. Heute lässt sich der Code über das VCI und die Openness-API des TIA Portal textbasiert exportieren, in Git versionieren und in einer CI/CD-Pipeline prüfen. Getestet wird zuerst gegen eine simulierte Steuerung wie PLCSIM, danach am Prüfstand oder per Hardware-in-the-Loop. Die Zielumgebung bleibt trotzdem heikel, denn ein fehlerhaftes Programm kann Maschinen beschädigen oder Menschen gefährden. Deployments laufen deshalb nur im Wartungsfenster und über kontrollierte Wege wie OT-Proxy-Agents. Typische Stolpersteine sind Änderungen direkt an der Maschine ohne Versionierung, fehlende Tests und ein Sicherheitsprogramm, das mit dem Standardprogramm vermischt ist. Der Klassiker: Die einzige funktionierende Programmversion liegt auf dem Notebook des Inbetriebnehmers, oder gleich in der Steuerung selbst, aus der sie beim Defekt niemand mehr herausbekommt.