SPS-Geschichte Die Evolution der SPS-Programmierung: Vom Relaisersatz zur Software-Defined Automation

Anbieter zum Thema

Schneider Electric

Beckhoff Automation GmbH & Co. KG

Siemens AG

Rockwell Automation GmbH

MicroConsult Academy GmbH

mehr weniger

Heitec AG

ISH Ingenieursozietät GmbH

weniger

Wie wandelte sich der SPS-Programmierer im Laufe der Jahrzehnte vom „Digital-Elektriker“, der physische Schaltpläne in elektronischen Speicher übersetzte, zum Software-Ingenieur, der objektorientierte, verteilte und versionierte Architekturen entwirft? Eine Spurensuche in vier Phasen.

In der industriellen Automatisierung der 1960er Jahre dominierten elektromechanische Relaissteuerungen. Diese erforderten bei Änderungen der Steuerungslogik eine komplette Neuverdrahtung, die gut und gerne Wochen dauerte. In der Automobilindustrie führte das bei Modellwechseln zu entsprechenden Produktionsausfällen. Daher definierte im Jahr 1968 General Motors Spezifikationen für ein elektronisches Steuerungssystem, das Relaissteuerungen ersetzen sollte, also flexibler aber genauso zuverlässig und robust sein sollte.

1. Die Pionierphase: Die Geburt der digitalen Relaislogik (1960er – 1970er)

Aus dem 84. Projekt des Ingenieurbüros Bedford Associates um Richard „Dick“ Morley ging 1969 das Unternehmen Modicon (Modular Digital Controller) und der Modicon 084 hervor. Dieses System gilt weithin als erste kommerziell erfolgreiche SPS. Modicon gehört mittlerweile zum französischen Automatisierungskonzern Schneider Electric.

Bildergalerie

Ein wesentliches Merkmal der Modicon 084 war die Software-Abstraktion. Das Team wählte den Kontaktplan (Ladder Logic), der auf existierenden Relais-Schaltplänen basierte, als Programmierparadigma und übertrug ihn in die Elektronik. Die Sprache simulierte visuell Strompfade zwischen spannungsführenden Schienen. Diese Darstellung hatte die Akzeptanz bei Industrieelektrikern in den Werkhallen erleichtert. Ihnen war die textbasierte Boolesche Algebra unvertraut, die in anderen Systemen bereits zum Einsatz kam.

Diese visuelle Logik etablierte ein Ausführungsmodell, das die Steuerungsarchitektur bis heute prägt: Den zyklischen Hauptzyklus (Scan Cycle). Dabei liest die Steuerung die Eingänge in ein Prozessabbild ein, arbeitet die Logik ab und schreibt die Ergebnisse in das Prozessabbild der Ausgänge. Auch wenn moderne Steuerungen dieses Modell durch Multitasking und ereignisgesteuerte Tasks erweitert haben, bleibt der deterministische Zyklus ein historisches Fundament der SPS.

Parallel zur grafischen Ladder Logic entwickelten europäische Hersteller hardwarenahe, textbasierte Ansätze. Siemens bot für Systeme wie die Simatic S5 die Programmierumgebung STEP 5 mit der Anweisungsliste (AWL) an. Diese Assembler-ähnliche Sprache nutzte Mnemoniks wie U (Und), UN (Und Nicht), L (Laden, z. B. der einzelnen Bytes eines Datenwortes) und T (Transferieren). Sie war speichereffizient, aber hardwareabhängig.

Viele frühe Laufzeitsysteme verzichteten auf eine dynamische Speicherallokation. Um Vorhersagbarkeit zu gewährleisten, nutzten diese Systeme überwiegend statisch reservierten Speicher. Auch wenn moderne Plattformen wie Codesys (etwa über Konstrukte wie __NEW) oder Twincat (mit Bibliotheken wie Tc3_DynamicMemory) heute dynamischen Speicher als Herstellererweiterung erlauben, wird dessen Einsatz in zeitkritischen Tasks in der Automatisierungspraxis oft eingeschränkt, um Jitter zu vermeiden.

2. Standardisierung & Modularisierung (1980er – 1990er)

In den 1980er Jahren fehlten standardisierte Datentypen und kompatible Architekturen zwischen den verschiedenen Steuerungsherstellern, was die Portabilität von Code erschwerte.

Die IEC-Gremien erarbeiteten daraufhin die internationale Norm IEC 61131, deren dritter Teil (IEC 61131-3) 1993 veröffentlicht wurde. Die 1992 gegründete Organisation PLCopen unterstützte fortan die Verbreitung der Norm. IEC 61131-3 definierte ein Softwaremodell basierend auf Program Organization Units (POUs). Diese Kapselung von Logik ermöglichte den Übergang zu modularer Software.

Die Norm etablierte Funktionen (ohne internen Zustand) und Funktionsbausteine (FB). Funktionsbausteine besitzen persistente Instanzdaten (internen Speicher) und kapseln Zustände über mehrere Ausführungszyklen hinweg – ein Konzept, das für Timer, Zähler oder Regler verwendet wird. Die IEC 61131-3 definierte formal vier Programmiersprachen (Kontaktplan, Funktionsbausteinsprache, Strukturierter Text und Anweisungsliste) sowie die Ablaufsprache (SFC) als satzstrukturierendes Element, das in der Praxis oft als fünfte Sprache gehandhabt wird.

Im Laufe der Zeit verlor die Anweisungsliste (AWL) an Bedeutung. Mit sinkenden Hardwarekosten und steigender Applikationskomplexität (Arrays, Mathematik, Datenverarbeitung) wurde zunehmend Strukturierter Text (ST) eingesetzt. Die Instruction List (IL) wurde schließlich in der dritten Edition der IEC 61131-3 (2013) offiziell als veraltet (deprecated) gekennzeichnet und in der vierten Edition von 2025 aus der Norm gestrichen.

3. IT-OT-Konvergenz und Software-Engineering (2000er – 2010er)

Ab den 2000er Jahren näherten sich IT und OT (Operational Technology) weiter an. Die dritte Edition der IEC 61131-3 ergänzte im Jahr 2013 objektorientierte Sprachelemente (OOP). Klassen, Interfaces, Vererbung und Referenzen wurden in die Norm aufgenommen. Eigenschaften bzw. Properties waren zu dieser Zeit Herstellererweiterungen und wurden erst später mit Edition 4 normiert. Diese Werkzeuge ermöglichen es Entwicklungsteams, IT-Konzepte wie die SOLID-Prinzipien oder Design Patterns in der SPS-Programmierung anzuwenden, mit dem Ziel, den Code modularer und wartbarer zu gestalten.

Die Zeit nach der Jahrtausendwende wurde durch PC-basierte Steuerungstechnik geprägt. Werkzeuge wie Codesys entkoppelten das Engineering vom Laufzeitsystem. Beckhoff integrierte mit Twincat 3 das Engineering in Microsoft Visual Studio und ermöglicht die parallele Ausführung von IEC-61131-3-Code, C/C++-Modulen und Matlab/Simulink-Modellen. Parallel dazu professionalisierte sich die Software-Qualitätssicherung. Neben dem Testen an Hardware oder Anlagen-Simulationen etablierten sich automatisierte Unit-Tests. Open-Source-Frameworks wie TcUnit ermöglichen Test-Driven Development (TDD) in der Automatisierung und vereinfachen die systematische Überprüfung von Codebausteinen.

4. Gegenwart & Zukunft: Cloud, Container, Edge (2020er+)

Die aktuelle Entwicklung ist geprägt von Digitalisierung, der Trennung von Hardware- und Software-Lebenszyklen sowie Cybersecurity-Anforderungen. Die vierte Edition der IEC 61131-3 (2025) normierte Properties, führte Mechanismen zur Synchronisation bei Multithreading (Mutex, Semaphore) ein und ergänzte native UTF-8-Unterstützung (USTRING).

Zusätzlich bietet der Standard IEC 61499 ein alternatives Ausführungsmodell. Er ist für dezentrale, ereignisgesteuerte (event-driven) Anlagen gedacht. Die Ausführung eines Basic Function Blocks (BFB) wird durch ein Execution Control Chart (ECC) gesteuert. Während IEC 61499 den Standard IEC 61131-3 in der industriellen Breite bislang nicht abgelöst hat, wird der Ansatz durch Initiativen wie UniversalAutomation.org und den Open Process Automation Standard (O-PAS) gefördert.

Die vier Editionen der SPS-Standards IEC 61131-3

In der Automatisierungstechnik werden zunehmend Konzepte der sogenannten Software-Defined Automation beliebt. Damit ist gemeint, dass die SPS selbst nicht mehr eine dedizierte Hard- und Software-Einheit darstellt, sondern lediglich nur eine von vielen Anwendungen auf einem Edge-Controller oder Industrie-PC. Mehrere aktuelle Steuerungs- und Edge-Plattformen, wie Bosch Rexroth CtrlX OS, Phoenix Contact PLCnext, basieren auf echtzeitfähigem Linux und nutzen Containerisierung per OCI, Podman, Snaps oder Docker. In der Praxis verbleibt die harte Echtzeitlogik zum Schutz vor Jitter oft in dedizierten Laufzeiten, während Container Aufgaben wie IoT-Kommunikation, Edge-Analytics oder Node-RED übernehmen.

Ansätze wie Siemens Simatic AX etablieren DevOps-Workflows als Ergänzung zu Engineering-Tools wie dem TIA Portal. AX nutzt VS Code als Editor, verwaltet Pakete über Apax, führt Tests mit AxUnit aus und ermöglicht durch die rein textbasierte Ablage Git-Versionskontrolle. Hersteller integrieren zudem KI-gestützte Code-Generatoren in diese Umgebungen. Genauso wie LLMs die Software-Entwicklung auf den Kopf gestellt haben, werden auch SPS-Entwickler bereits von KI-Agenten beim Generieren von Algorithmen oder dem Refactoring unterstützt. Das macht den Programmierer bzw. Ingenieur aber noch lange nicht überflüssig. KI ist ein Tool, das Arbeit abnimmt, aber die Validierung und letztlich auch die Verantwortung bleibt beim Menschen.

Regulatorische Vorgaben beeinflussen die Softwareentwicklung, egal ob IT oder OT. Der Cyber Resilience Act (CRA) und die NIS2-Richtlinie fordern, gemeinsam mit Standards wie der IEC 62443, dass Änderungen, Zugriffsrechte und Softwarestände nachvollziehbar verwaltet werden. Versionsverwaltung, signierte Artefakte und kontrollierte Deployment-Prozesse werden von Experten empfohlen, um diese Vorgaben zur Nachvollziehbarkeit umzusetzen.

Noch ein Trend, der die IT-Konvergenz unterstreicht, ist die wachsende Open-Source-Bewegung. Laufzeitumgebungen und Editoren wie OpenPLC oder Beremiz ermöglichen hardwareunabhängiges Prototyping. Obwohl diese Projekte nicht offiziell PLCopen-zertifiziert sind, etablieren sie IT-typische Community-Konzepte zunehmend auch in der SPS-Welt.

Die Transformation zum Software-Ingenieur

Die Entwicklung der SPS-Programmierung zeigt eine stetige Adaption von IT-Paradigmen. Der moderne Automatisierer nutzt mittlerweile selbstverständlich Konzepte wie Objektorientierung, asynchrone Ereignisse und DevOps-Methoden. Und überall wo Code geschrieben wird, sind KI-Modelle nicht mehr wegzudenken.

Dennoch bestehen Unterschiede zur klassischen IT: Industrielle Automatisierung erfordert deterministisches Verhalten, funktionale Sicherheit und hohe Verfügbarkeit. Zeitkritische Echtzeitregelungen bleiben aufgrund von Latenzanforderungen auch künftig vorwiegend auf Edge-Geräten oder Industrie-PCs und wandern nicht unbedingt in die Cloud. (mc)

(ID:50922413)