SPS-Engineering findet nicht in einer sauberen, abgeschlossenen Softwareumgebung statt, sondern dort, wo Elektropläne, Prozessbeschreibungen, Mechanik, Bedienerwünsche und die Realität der Inbetriebnahme aufeinandertreffen. Ein Programm kann logisch einwandfrei sein und an der Maschine trotzdem scheitern: weil ein Sensor anders prellt als erwartet, weil eine Schrittkette mehrdeutig beschrieben war oder weil der Bediener die Anlage in einer Reihenfolge fährt, an die beim Entwurf niemand gedacht hat.
Ein vollständiges Lastenheft bekommt der Programmierer ohnehin selten. Es gibt Eplan-Zeichnungen, Funktionsbeschreibungen, IO-Listen, Sicherheitskonzepte und Mechanik-Unterlagen – und daneben Änderungen, die während der Montage entstehen, Absprachen aus dem Gespräch an der Anlage und viele kleine Entscheidungen, die nie in ein Dokument wandern. Mit diesem unvollständigen Bild umzugehen, gehört zur Qualifikation. Ist eine Anforderung unklar, fragt der Ingenieur nach. Verhält sich ein Signal in der Inbetriebnahme auffällig, prüft er zuerst Hardware, Verdrahtung, Mechanik und Prozess, bevor er die Software anfasst. Läuft eine Sequenz in der Simulation, an der Anlage aber nicht, weiß er, dass die Ursache außerhalb des Codes liegen kann.
Genau diesen Kontext hat ein KI-Modell nicht, solange wir ihn nicht ausdrücklich mitliefern. Erschwerend kommt hinzu, dass ein Sprachmodell auch dann eine Antwort produziert, wenn ihm Informationen fehlen. Das Ergebnis sieht technisch plausibel aus, lässt sich fehlerfrei übersetzen und ist für die konkrete Anlage dennoch falsch. In der Bürosoftware kostet ein solcher Vorschlag ein paar Minuten. In einem SPS-Projekt kann eine falsche Annahme die Produktion anhalten, Werkzeuge beschädigen oder eine sicherheitsrelevante Situation erzeugen. Dieser Unterschied prägt bei uns den gesamten Umgang mit dem Thema.
Wo wir KI heute einsetzen
Damit ist KI in der SPS-Programmierung keineswegs nutzlos – sie braucht nur eine klar umrissene Rolle. Bei Masterwerk arbeitet sie als Engineering-Assistenz, nicht als Eigentümerin der Steuerungsarchitektur. Den größten Hebel sieht das Unternehmen bei Wiederholarbeit. Große Anlagen bestehen aus Dutzenden gleichartiger Stationen, aus Hunderten Signalen und aus vielen Instanzen derselben Funktion mit unterschiedlichen Parametern. Diese Informationen von Hand zu schreiben, zu kopieren und gegenzuprüfen, kostet Tage und ist zugleich eine klassische Fehlerquelle: Ein Zahlendreher in einer Symboladresse fällt selten beim Übersetzen auf, sondern erst im Testlauf.
Hier lässt sich strukturiert arbeiten. Aus einer gepflegten Excel- oder IO-Liste erzeugt der Anbieter mit KI-Unterstützung SCL-Bausteine, Aufrufe und Parametrierungen für wiederkehrende Stationen; die Architektur, die Schnittstellen und das Namenskonzept legt vorher der Ingenieur fest. Ähnlich wird bei Datenkonvertierungen, Mappings, Diagnosetexten, Kommentierung und ersten Entwürfen einfacher Funktionsbausteine verfahren – also bei unkritischer Logik, deren Richtigkeit sich schnell nachvollziehen lässt.
Der zweite große Nutzen liegt beim Verstehen statt beim Schreiben. Wer eine bestehende Anlage übernimmt, verbringt oft Tage damit, fremden Code zu lesen, der über Jahre gewachsen ist. Eine KI kann ihn zusammenfassen, Abhängigkeiten aufzeigen und bei der Fehlersuche Hypothesen liefern, die man anschließend prüft. Auch die Recherche verkürzt sich: Statt drei Handbücher zu durchsuchen, holt man sich einen ersten Vorschlag und verifiziert ihn an der Dokumentation. Unterm Strich verschiebt sich dadurch die Zeitverteilung im Projekt. Die Routine schrumpft, für Architektur, Test und Inbetriebnahme bleibt mehr Raum. Entscheidend ist dabei die Regel: Die erste KI-Antwort ist ein Entwurf, kein Ergebnis.
Fehler und Halluzinationen verhindern
Die wichtigste Absicherung ist organisatorisch, nicht technisch: Die Verantwortung für die Logik bleibt beim Ingenieur. KI-generierter Code durchläuft dasselbe Review wie Code eines Kollegen. Geprüft wird, ob die Logik zum Maschinenkonzept passt, ob alle Zustände und Störfälle behandelt sind und ob sich der Baustein deterministisch verhält. Dazu gehört eine einfache Faustregel: Wer nicht erklären kann, was ein Baustein tut und warum er so umgesetzt ist, gibt ihn nicht frei.
Bestimmte Bereiche hält Masterwerk bewusst frei von generiertem Code. Sicherheitsfunktionen, zentrale Maschinensequenzen, Verriegelungen und die Architektur selbst entstehen von Hand. Der Aufwand, generierte Safety-Logik so weit zu durchdringen, dass man sie verantworten kann, ist ohnehin größer als der Aufwand, sie selbst zu schreiben.
Die zweite Absicherung ist strukturiertes Engineering – etwas, das sich schon ohne KI auszahlt und mit ihr unverzichtbar wird. Sauberer Code lässt sich prüfen, raffinierter Code nicht. Funktionen werden in überschaubare Bausteine geschnitten, für Abläufe werden Zustandsautomaten statt verschachtelter Bedingungen eingesetzt, magische Zahlen durch benannte Konstanten und Aufzählungen ersetzt, unnötige Sprünge vermieden und Schnittstellen eindeutig definiert. Ist die Struktur klar, dauert der Abgleich zwischen generierter Logik und beabsichtigtem Verhalten Minuten. Ist der Code unnötig komplex, findet man den Fehler spät – unabhängig davon, wer ihn geschrieben hat.
Die dritte Absicherung ist der Test im Kontext. Dass ein Programm fehlerfrei übersetzt, sagt über sein Verhalten an der Anlage nichts aus. Die Lösung testet Funktionen, Sequenzen und Fehlerzustände einzeln, nutzt wo möglich die virtuelle Inbetriebnahme und geht anschließend mit Simulation in den FAT. Die endgültige Validierung passiert trotzdem am realen Prozess, weil kein Modell jede mechanische Toleranz, jede Zeitstreuung und jede Bedienhandlung abbildet. Aus demselben Grund kann eine KI ihre eigene Arbeit nicht prüfen und für korrekt erklären: Wer validiert, muss Software und Maschine gleichzeitig verstehen.
Bild: Masterwerk GmbH 
Bild: Masterwerk GmbH
Die Arbeit verändert sich, die Verantwortung nicht
KI-Funktionen werden in den Engineering-Werkzeugen selbstverständlich werden, und die Modelle werden besser. Für SPS-Programmierer ist das kein Grund zur Sorge. Was sich heute beschleunigen lässt, ist genau die Arbeit, die ohnehin niemand gerne macht: Wiederholcode, Parametrierung, Dokumentation, Suchen. Der anspruchsvolle Teil bleibt unberührt. Den Prozess verstehen. Entscheiden, wenn die Spezifikation Lücken hat. Mechanisches Verhalten in belastbare Logik übersetzen. Die Ursache finden, wenn die Maschine sich anders verhält als das Modell. Diese Aufgaben leben von Kontext und Erfahrung, und beides entsteht auf der Baustelle, nicht im Datensatz.
