SPS-Programmierung mit KI: Entwurf, Test und Freigabe

SPS-Programmierung mit KI unterstützt beim Entwerfen, Erklären und Prüfen von Steuerungscode. Ein lauffähiger Entwurf braucht den konkreten Projektkontext und muss vor dem Einsatz kompiliert, getestet und fachlich freigegeben werden.

Seit einiger Zeit bieten Steuerungshersteller und Drittanbieter KI-Assistenten an, die Code vorschlagen, erklären und testen sollen. Für den Betrieb zählt der Weg vom Vorschlag zum geprüften Baustein. Ohne Funktionsbeschreibung, passende Bibliotheken und vereinbarte Tests bleibt der Zeitgewinn durch die schnelle Codeausgabe unklar.

Was SPS-Programmierung ausmacht

Eine speicherprogrammierbare Steuerung liest zyklisch Eingänge ein, verarbeitet sie nach dem Programm und schreibt Ausgänge. Die IEC 61131-3:2025, Edition 4.0 vom 22. Mai 2025, definiert eine Sprachensuite mit Strukturiertem Text (ST, bei Siemens SCL), Kontaktplan (KOP, englisch LD) und Funktionsbausteinsprache (FBS, englisch FBD, bei Siemens FUP). Zusätzlich beschreibt sie Sequential Function Chart (SFC), oft Ablaufsprache (AS) genannt, als Mittel zur Strukturierung von Programmen und Funktionsbausteinen. Hinzu kommen herstellerspezifische Erweiterungen und Bibliotheken.

Anders als bei Büro-Software läuft der Code nicht in einer isolierten Umgebung, sondern bewegt Antriebe, Ventile und Achsen. Ein Fehler kann eine Maschine beschädigen oder Menschen gefährden. Deshalb gehört zum Schreiben die Prüfung in der Simulation, am virtuellen Abbild der Anlage und bei der Inbetriebnahme vor Ort.

Sprachen, Ablauf und Werkzeuge ohne KI erklärt der Grundlagenbeitrag Programmierung einer SPS.

Wo KI bei der SPS-Programmierung heute hilft

Große Sprachmodelle sind gut darin, Text in einer bekannten Struktur zu erzeugen, und Strukturierter Text ähnelt klassischen Programmiersprachen. Daraus ergeben sich typische Einsatzfelder:

• Code-Vorschläge in Strukturiertem Text: Aus einer Beschreibung wie „Förderband startet, wenn Sensor A belegt und Not-Halt quittiert ist“ entsteht ein Bausteingerüst mit Variablen und Logik.
• Code erklären: Übernommene Altprogramme, deren Autor nicht mehr im Haus ist, werden Baustein für Baustein in verständlicher Sprache beschrieben.
• Umwandeln und Aufräumen: Logik aus einer Sprache in eine andere übertragen, Namenskonventionen vereinheitlichen, Kommentare ergänzen.
• Testfälle entwerfen: Aus der Funktionsbeschreibung werden Testfälle für Grenzwerte, Fehlerzustände und Betriebsarten abgeleitet.
• Dokumentation: Variablenlisten, Bausteinbeschreibungen und Änderungsprotokolle entstehen schneller.
• Vorarbeiten aus Unterlagen: E/A-Listen aus Schaltplan-PDFs auslesen, statt Belegungen abzutippen.

Ein Beispiel aus dem Markt: Siemens stellte im April 2024 einen Industrial Copilot für das TIA Portal vor, der Code in der Sprache SCL erzeugt, den das TIA Portal direkt übernehmen kann, der SCL-Bausteine erklärt und beim Erstellen einer ersten Visualisierung hilft. Andere Steuerungshersteller und unabhängige Anbieter haben vergleichbare Assistenten angekündigt oder im Angebot. Lassen Sie sich für die Auswahl zeigen, welche Bibliotheken der Assistent kennt und welche Tests er mit Ihrem Projekt ausführen kann.

Merksatz: KI schreibt bei der SPS-Programmierung vor allem den ersten Entwurf und die Fleißarbeit. Die Verantwortung für Logik, Sicherheit und Freigabe bleibt beim Programmierer.

Wo KI scheitert

Die Grenzen sind in der Steuerungstechnik deutlicher als in der allgemeinen Software-Entwicklung:

• Anlagenwissen fehlt: Das Modell kennt weder die Mechanik noch die Signalreihenfolge der realen Maschine. Was plausibel aussieht, kann im Zusammenspiel mit Sensoren und Antrieben falsch sein.
• Herstellerspezifika: Bibliotheken, Systembausteine und Eigenheiten einzelner Steuerungsfamilien sind in allgemeinen Modellen oft unvollständig oder veraltet abgebildet.
• Grafische Sprachen: Kontaktplan und Funktionsbausteinsprache lassen sich schwerer als Text erzeugen und prüfen; viele Assistenten arbeiten deshalb vor allem mit Strukturiertem Text.
• Zeitverhalten: Zykluszeiten, Flanken, Timer und Nebenläufigkeit sind fehleranfällig und werden in Vorschlägen leicht vereinfacht.
• Sicherheitsprogramme: Sicherheitsgerichtete Teile mit Not-Halt, Schutztüren oder Zweihandschaltung unterliegen eigenen Normen und Validierungen. Sie gehören nicht in einen ungeprüften KI-Entwurf.

Hinzu kommt die Geheimhaltung. Steuerungsprogramme enthalten Fertigungs-Know-how und sind oft durch Verträge mit Kunden geschützt. Wer Code in einen Cloud-Dienst lädt, sollte wissen, wo die Daten verarbeitet werden, ob sie zum Training genutzt werden und ob eine lokale Variante möglich ist.

Testen und Freigeben: der wichtigste Teil

Je schneller Code entsteht, desto wichtiger wird der Test. Ein bewährtes Vorgehen für KI-gestützte Steuerungsprogrammierung:

• Funktionsbeschreibung zuerst: Ohne klare Beschreibung der Abläufe, Betriebsarten und Fehlerfälle erzeugt auch die beste KI nur Vermutungen.
• Kleine Bausteine: Lieber einzelne, klar abgegrenzte Funktionen erzeugen lassen als ganze Programme.
• Statische Prüfung: Programmierrichtlinien, Namenskonventionen und Code-Analyse automatisch prüfen lassen.
• Simulation: Bausteine gegen eine simulierte Steuerung und, wo vorhanden, gegen ein virtuelles Abbild der Anlage testen, bevor sie auf die echte Maschine kommen.
• Vier-Augen-Prinzip: Jeder KI-Vorschlag wird von einem Menschen gelesen und freigegeben, Änderungen sind in der Versionsverwaltung nachvollziehbar.
• Inbetriebnahme mit Protokoll: Tests an der Maschine dokumentieren, insbesondere Fehlerfälle und Wiederanlauf.

Praxis-Hinweis: Legen Sie fest, welche Bausteine KI-Vorschläge enthalten dürfen und welche nicht. Sicherheitsprogramme, Bewegungssteuerung mit Personengefährdung und Kundenspezifika mit Geheimhaltungspflicht gehören in der Regel auf die Ausschlussliste.

Agenten statt Assistenten

Die nächste Stufe sind Agenten, die nicht nur einen Vorschlag machen, sondern mehrere Schritte selbst ausführen: Bausteine anlegen, kompilieren, Tests starten, Fehler auswerten und den Code nachbessern. In der allgemeinen Software-Entwicklung ist dieses Arbeiten unter dem Begriff Agentic Coding verbreitet. Für die Steuerungstechnik gilt: Je mehr ein Agent selbst ausführt, desto wichtiger sind klare Grenzen. Ein Agent sollte in einer Testumgebung arbeiten, nicht auf einer laufenden Anlage, und jede Übernahme in das Produktivprojekt braucht eine menschliche Freigabe.

Wie sich ähnliche Werkzeuge bei der Bahnprogrammierung von Robotern einsetzen lassen, beschreibt der Beitrag Teach-in und Offline-Programmierung. Einen Überblick über Roboterzellen, deren Steuerung meist mit einer SPS zusammenspielt, gibt Industrieroboter: Bauarten, Aufbau und Arbeitsraum.

Wie Engineering-Teams solche Agenten geordnet einführen, beschreibt der Beitrag Agentic Coding in der Automatisierungstechnik.

Recht und Verantwortung

Rechtlich ändert ein KI-Assistent nichts an der Verantwortung. Wer eine Maschine in Verkehr bringt, ist für ihre Sicherheit verantwortlich, unabhängig davon, wie der Code entstanden ist. Mit der EU-Maschinenverordnung, die ab dem 20. Januar 2027 gilt, wird Software ausdrücklicher erfasst: Software, die Sicherheitsfunktionen erfüllt und separat in Verkehr gebracht wird, kann selbst ein Sicherheitsbauteil sein, und Steuerungen müssen gegen Manipulation geschützt werden. Details erklärt der Beitrag Maschinenverordnung 2023/1230: Folgen für Roboterzellen.

Ein Code-Assistent für die Entwicklung ist dagegen in der Regel kein Sicherheitsbauteil der Maschine, denn er läuft nicht in der Anlage. Anders kann es aussehen, wenn ein lernendes System im Betrieb Sicherheitsfunktionen übernimmt. Dann greifen die strengeren Regeln der Maschinenverordnung. Für die Hochrisiko-Einstufung nach Artikel 6 Absatz 1 der KI-Verordnung muss zusätzlich eine Konformitätsbewertung durch Dritte vorgeschrieben sein. Seit dem Digital Omnibus werden die Hochrisiko-Anforderungen für Maschinen über die Maschinenverordnung umgesetzt; die entsprechenden delegierten Rechtsakte sollen bis zum 2. August 2028 gelten.

Einführung im Team

Ob KI in der Steuerungsprogrammierung hilft, entscheidet sich weniger am Werkzeug als an der Arbeitsweise. Ein häufiges Muster: Einzelne probieren Werkzeuge aus, jeder arbeitet anders, und niemand weiß, welcher Code woher stammt. Besser ist ein geordneter Start:

• Ein Pilotprojekt mit wiederkehrenden Standardbausteinen wählen, etwa Antriebs- oder Ventilbausteine.
• Regeln schriftlich festlegen: erlaubte Werkzeuge, Datenschutz, Ausschlussliste, Freigabeprozess.
• Programmierrichtlinien und Bibliotheken als Vorlage hinterlegen, damit Vorschläge zum Hausstil passen.
• Zeit messen: Wie lange dauerten vergleichbare Bausteine bisher, wie lange mit Assistent und Test?
• Das Team gemeinsam schulen, nicht nur einzelne Interessierte.

Wer Programmierer und Automatisierer gemeinsam befähigt, verhindert, dass das Wissen an einer Person hängt. Das ist in kleinen Automatisierungsbetrieben, in denen jede Position oft nur einmal besetzt ist, besonders wichtig.

Wo KI im Steuerungsprojekt Zeit spart

Der Nutzen zeigt sich weniger beim einzelnen Baustein als über das ganze Projekt. Ein typisches Automatisierungsprojekt durchläuft Phasen, in denen sich Fleißarbeit sammelt:

• Angebot und Machbarkeit: Lastenhefte und Anfragen zusammenfassen, offene Punkte und Widersprüche markieren, vergleichbare Altprojekte finden.
• Elektrokonstruktion und Belegung: Ein- und Ausgänge aus Schaltplänen auslesen, Symbolnamen vorschlagen, Belegungslisten abgleichen.
• Programmierung: Standardbausteine für Antriebe, Ventile, Förderstrecken und Betriebsarten entwerfen, bestehende Bibliotheken richtig einbinden.
• Visualisierung: Meldetexte, Bedienbilder und Übersetzungen der Bedienoberfläche vorbereiten.
• Inbetriebnahme: Checklisten aus der Funktionsbeschreibung ableiten, Fehlermeldungen und Diagnosepuffer verständlich erklären.
• Übergabe und Service: Dokumentation, Änderungsprotokolle und Hinweise für die Instandhaltung des Kunden erstellen.

Gerade in kleinen Automatisierungsbetrieben, in denen dieselben Leute anbieten, programmieren und in Betrieb nehmen, summieren sich diese Schritte. Wer jede Phase einzeln betrachtet, findet meist mehrere Stellen, an denen ein Assistent Stunden spart, ohne an die sicherheitskritische Logik heranzugehen.

E/A-Listen aus dem Schaltplan

Ein Beispiel, das viele Steuerungstechniker kennen: Vor der Programmierung muss die Belegung der Ein- und Ausgänge aus dem Schaltplan in eine Liste oder direkt in die Variablentabelle übertragen werden. Bei großen Anlagen sind das Hunderte Zeilen Abtipparbeit, und jeder Übertragungsfehler zeigt sich erst bei der Inbetriebnahme. Sprachmodelle mit Bildverständnis können Schaltplan-PDFs lesen und daraus einen Entwurf der E/A-Liste mit Adresse, Betriebsmittelkennzeichen und Beschreibung erzeugen.

Auch hier gilt: Der Entwurf wird gegen den Schaltplan geprüft, am besten stichprobenartig durch eine zweite Person und vollständig bei sicherheitsrelevanten Signalen. Wo das Elektro-CAD die Daten strukturiert exportieren kann, ist dieser Weg oft verlässlicher als das Auslesen eines PDFs.

Lokal oder in der Cloud?

Viele Assistenten laufen als Cloud-Dienst. Das ist bequem, wirft aber in der Steuerungstechnik Fragen auf, die vor dem Einsatz geklärt sein sollten:

• Wo werden Code, Schaltpläne und Projektdaten verarbeitet und gespeichert?
• Werden Eingaben zum Training des Modells verwendet, und lässt sich das vertraglich ausschließen?
• Erlauben die Verträge mit Kunden, deren Projektdaten an Dritte weiterzugeben?
• Gibt es eine Variante, die im eigenen Netz oder auf einem eigenen Server läuft?
• Funktioniert der Assistent auch auf der Baustelle ohne stabile Internetverbindung?

Lokale Modelle, die auf eigener Hardware laufen, sind meist kleiner als die größten Cloud-Modelle. Ob sie für Aufgaben wie Erklären, Dokumentieren und Standardbausteine reichen, lässt sich am eigenen Code testen. Eine mögliche Aufteilung: unkritische Aufgaben in der Cloud, Kundenprojekte mit Geheimhaltungspflicht lokal.

Woran man einen brauchbaren Assistenten erkennt

• Er arbeitet in der Entwicklungsumgebung, die das Team ohnehin nutzt, statt Code über die Zwischenablage hin und her zu kopieren.
• Er kennt die Bibliotheken und Systembausteine der eingesetzten Steuerungsfamilie.
• Er erzeugt Code, der sich kompilieren, simulieren und testen lässt, und kennzeichnet seine Vorschläge nachvollziehbar.
• Er lässt sich an die eigenen Programmierrichtlinien anpassen.
• Datenverarbeitung, Speicherort und Trainingsnutzung sind dokumentiert und vertraglich geregelt.

Altcode verstehen und migrieren

Ein unterschätztes Einsatzfeld ist der Bestand. Viele Anlagen laufen seit Jahren mit Programmen, die mehrfach erweitert wurden, deren Autoren den Betrieb verlassen haben und deren Dokumentation lückenhaft ist. Steht ein Umbau, eine Erweiterung oder der Wechsel auf eine neue Steuerungsgeneration an, beginnt die Arbeit mit dem Verstehen: Was macht dieser Baustein, wo wird jene Variable beschrieben, welche Schrittkette gehört zu welchem Anlagenteil?

Hier sind Sprachmodelle stark. Sie fassen Bausteine in verständlicher Sprache zusammen, zeichnen Aufrufstrukturen nach, finden doppelte oder tote Programmteile und schlagen eine Übertragung in die Sprache der neuen Steuerung vor. Gerade bei Migrationen gilt aber: Das Verhalten der alten Anlage ist der Maßstab. Jeder migrierte Baustein muss gegen das bisherige Verhalten getestet werden, idealerweise mit aufgezeichneten Signalen aus dem laufenden Betrieb.

Was Programmierrichtlinien regeln sollten

Damit KI-Vorschläge zum eigenen Stil passen und prüfbar bleiben, lohnt sich eine kurze, verbindliche Richtlinie, die dem Assistenten als Vorlage mitgegeben wird:

• Namenskonventionen für Bausteine, Variablen und Instanzen.
• Struktur von Schrittketten, Betriebsarten und Fehlerbehandlung.
• Welche Bibliotheksbausteine verwendet werden müssen und welche verboten sind.
• Kommentarpflicht und Kennzeichnung von KI-generierten Abschnitten.
• Mindestumfang der Tests vor jeder Freigabe.

Eine solche Richtlinie hilft nicht nur der KI. Sie erleichtert auch neuen Kolleginnen und Kollegen den Einstieg, macht Code verschiedener Programmierer vergleichbar und verkürzt die Störungssuche beim Kunden, weil Programme überall gleich aufgebaut sind. Viele Betriebe haben solche Regeln ohnehin im Kopf, aber nicht auf Papier. Die Einführung eines Assistenten ist ein guter Anlass, sie aufzuschreiben.

Den Stand lernender Roboter im Werk ordnet Humanoide Roboter in der Produktion ein.

Was mit den Daten passiert

SPS-Code, Symbolnamen, E/A-Zuordnungen und Bibliotheksinformationen können als Kontext an einen KI-Assistenten gelangen. Ob diese Daten auf dem Engineering-Rechner bleiben oder extern verarbeitet werden, hängt vom konkreten Werkzeug ab. Prüfen Sie den Übertragungsweg und die vertragliche Nutzung vor dem ersten produktiven Projekt. Zugangsdaten und unnötige Anlagenkennungen gehören nicht in Prompts oder exportierte Beispieldateien.

Den ersten Baustein vollständig vergleichen

Wählen Sie einen wiederkehrenden Baustein ohne Sicherheitsfunktion und geben Sie dem Assistenten die freigegebene Funktionsbeschreibung. Messen Sie die Zeit bis zum geprüften und freigegebenen Stand einschließlich Nacharbeit. Übernehmen Sie den Ablauf erst dauerhaft, wenn dieser Vergleich für das Team einen nachvollziehbaren Nutzen zeigt.