SPS / PLC

Eine SPS (Speicherprogrammierbare Steuerung, englisch PLC für Programmable Logic Controller) ist ein industrietaugliches Steuergerät, das Maschinen und Anlagen in Echtzeit steuert. Sie arbeitet nach einem zyklischen Grundprinzip: Eingänge einlesen, Programm abarbeiten, Ausgänge setzen — und das deterministisch in fest definierten Zykluszeiten, oft im einstelligen Millisekundenbereich. Diese Echtzeitfähigkeit unterscheidet sie fundamental von einem normalen Computer und macht sie zum Rückgrat der Maschinensteuerung. Programmiert wird typischerweise in den Sprachen der IEC 61131-3: Kontaktplan (KOP), Funktionsbausteinsprache (FBS), Strukturierter Text (ST), Anweisungsliste (AWL) und Ablaufsprache (AS) — bei Siemens-Steuerungen im TIA Portal.

Welche Programmiersprachen gibt es für SPS? Die Norm IEC 61131-3 definiert fünf: Anweisungsliste (AWL, englisch IL), Kontaktplan (KOP, LD), Funktionsplan beziehungsweise Funktionsbausteinsprache (FUP, FBD), Strukturierter Text (ST) und Ablaufsprache (AS, SFC). Kontaktplan und Funktionsplan sind grafisch und stammen aus der Welt der Relaisschaltpläne — der Elektriker an der Anlage liest sie ohne Einarbeitung. Strukturierter Text ist eine Hochsprache mit Pascal-Verwandtschaft und trägt heute die komplexe Logik: Rezepturen, Berechnungen, Kommunikation. Die Hersteller setzen die Norm mit eigenen Dialekten und Namen um: Siemens nennt Strukturierten Text im TIA Portal SCL (Structured Control Language) und hat die klassische AWL für die S7-1200/1500 ausgemustert; Beckhoff TwinCAT und CODESYS-basierte Systeme (etwa WAGO, Schneider Electric) 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 nicht egal: 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 Austauschformat wie den TIA-VCI-Export oder PLCopen XML.

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 (PROFINET, EtherCAT, 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 — und Safety-SPS für sicherheitsgerichtete Funktionen nach IEC 61508, deren Programm getrennt vom Standardprogramm gepflegt und freigegeben wird.

Lange Zeit waren SPS-Programme von moderner Softwareentwicklung abgeschnitten: proprietäre Projektformate, binäre Stände ohne sinnvolle Diffs, kein Versionierungs- oder Review-Prozess. Genau hier setzt Industrial DevOps an. Über Schnittstellen wie das Version Control Interface (VCI) und die Openness-API des Siemens TIA Portal lässt sich der Code in textbasierter Form exportieren, mit Git versionieren und in CI/CD-Pipelines einbinden — inklusive automatisierter Prüfungen und reproduzierbarer Builds.

Die Herausforderung bleibt die Zielumgebung: Eine SPS steuert physische Anlagen, ein fehlerhaftes Programm kann Maschinen beschädigen oder Menschen gefährden. Deployments erfolgen deshalb nur in Wartungsfenstern, nach Test — idealerweise per Hardware-in-the-Loop — und über kontrollierte Pfade wie OT-Proxy-Agents. Stolpersteine sind manuelles Programmieren direkt an der Maschine ohne Versionierung, fehlende Tests und die Vermischung von Steuerungs- und Sicherheitsfunktionen, die nach Norm getrennt gehören. 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.