Kostenlose DevOps-Analyse
Zurück zum Blog
SPS / PLC · KI · INDUSTRIAL DEVOPS·30. Mai 2026·15 min Lesezeit

KI in der SPS/PLC-
Programmierung.
Tools, Praxis, Grenzen.

Generative KI schreibt Structured Text aus natürlicher Sprache. Welche Tools 2026 produktiv sind, was sie leisten und wo der Mensch unverzichtbar bleibt.

Von Andreas Schönfeld, Geschäftsführer der Comquent GmbH. Er arbeitet seit 2006 mit Jenkins und CI/CD und nutzt KI-Assistenten in der täglichen Entwicklungsarbeit. Was ihn an diesem Thema umtreibt: Ein Werkzeug, das in Sekunden Code vorschlägt, trifft hier auf Anlagen, bei denen ein falscher Baustein Stillstand bedeutet. Die Frage ist deshalb nicht, ob KI in der SPS-Programmierung hilft, sondern unter welchen Bedingungen.

Comquent arbeitet seit Jahren mit KI im Kontext Industrial DevOps, in Kundenprojekten und in eigener Forschung. Wir testen Assistenten und Agenten an echtem Steuerungs- und Pipeline-Code und prüfen, wo sie tragen und wo sie erfinden. Was dabei herauskommt, fließt in Workshops und Projekte zurück.

Daraus entsteht die Arbeit an den Bedingungen: Versionsverwaltung mit Git als Grundlage, CI/CD-Pipelines, die generierten Code automatisch bauen und gegen die Simulation testen, und Review-Regeln, die festhalten, wer welchen Vorschlag verantwortet. Dazu kommen Einführungs- und Migrationsprojekte, in denen gewachsener Steuerungscode überhaupt erst prüfbar wird.

Comquent-Team in einer Fertigungshalle vor Werkzeugmaschinen, Automatisierungstechnik und Softwareentwicklung in einem ProjektAI
Siemens-S7-Steuerung im Schaltschrank neben einem Laptop mit Structured-Text-Code nach IEC 61131-3, KI-gestützte SPS-Programmierung in der PraxisAI
Siemens-S7-Steuerung · Structured Text (SCL) im Editor · die IT/OT-Brücke in der Praxis
Andreas Schönfeld

Andreas Schönfeld

Geschäftsführer & DevOps-Berater, Comquent GmbH

20 Jahre CI/CD- und Industrial-DevOps-Beratung mit Schwerpunkt SPS/PLC-Versionierung, IT/OT-Brücke und KI-gestützte Engineering-Workflows.

Veröffentlicht: 30. Mai 2026Zuletzt aktualisiert: 22. September 2026
// Direkte Antwort

KI in der SPS-Programmierung bedeutet 2026: Generative KI erzeugt SPS-Code aus natürlicher Sprache, vor allem Structured Text (ST/SCL), und kann ihn erklären und refaktorieren. Produktive Tools 2026: Siemens Industrial Copilot und der Eigen Engineering Agent im TIA Portal, Beckhoff TwinCAT Chat und Rockwell FactoryTalk Copilot, dazu generische GPT-Modelle wie ChatGPT für SCL-Entwürfe ohne Projektbindung. KI ersetzt aber nicht den SPS-Programmierer. Seine Rolle verschiebt sich vom Tippen zum Prüfen. Entwürfe müssen verifiziert und verantwortet werden, Safety-Logik bleibt manuell und zertifiziert.

Stand · September 2026Eigen Engineering Agent · TwinCAT Chat · FactoryTalk DSIEC 61131-3 (ST/SCL)
// Kurz gefragt1 Klick, anonym

Ist KI in der SPS-Programmierung bei Ihnen gerade ein Thema?

Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.

01
// 01Woran es hängt

Welche Probleme
löst KI in der SPS-
Programmierung?

KI löst in der SPS-Programmierung vier Probleme: Standardlogik von Hand zu tippen, gewachsenen Altcode nicht mehr zu verstehen, fehlende Dokumentation und Testfälle, die niemand schreibt. Sie löst kein einziges davon allein. Jedes der vier endet an derselben Stelle, nämlich bei der Frage, wer den Entwurf geprüft und freigegeben hat.

Die Sätze unten stammen fast wörtlich aus Erstgesprächen. Daneben steht, was der Zustand im Betrieb kostet und was ihn abstellt. Wenn Sie zwei davon wiedererkennen, ist die Frage nach dem Werkzeug nicht Ihre erste.

/01

Der Baustein kompiliert, aber niemand weiß, ob er stimmt

Was es kostet

Ein SCL-Entwurf sieht nach zwanzig Sekunden fertig aus. Ob die Verriegelung vollständig ist, steht ihm nicht an. Die Prüfzeit, die vorher im Schreiben steckte, verschwindet nicht, sie wandert nur nach hinten. Eingeplant hat sie meist niemand.

Was hilft

Prompts, die die KI ihre Annahmen auflisten lassen. Diese Liste ist Ihre Prüfreihenfolge, und sie kostet zwei Zeilen im Prompt. Sechs Prompts mit Prüfzeile

/02

Der Kollege hat den Schnipsel aus dem Browser ins Projekt kopiert

Was es kostet

Damit liegt ein Stück Anlagenlogik bei einem öffentlichen Endpunkt, und im Projekt liegt Code, den niemand als generiert erkennt. Beides fällt erst auf, wenn jemand fragt, woher der Baustein stammt.

Was hilft

Vor dem Rollout festlegen, welches Modell welche Daten sehen darf. Enterprise-Instanz, Hersteller-Assistent oder lokal betriebenes Modell, je nach Netz. Modell-Governance in fünf Schritten

/03

Die KI kennt unsere Variablennamen nicht

Was es kostet

Der Entwurf aus dem Browser-Fenster heißt „Motor_1“, Ihre Symbolik heißt anders. Was das Modell an Tippzeit spart, geht beim Umbenennen und Nachziehen der Datentypen wieder weg.

Was hilft

Entweder ein Assistent, der im Projekt sitzt, oder das generische Modell über die Openness-API und einen MCP-Server anbinden. Die Steuerung entscheidet, welcher Weg trägt. Welche KI zu welcher Steuerung

/04

An den Baustein von 2009 geht keiner mehr ran

Was es kostet

Neunhundert Zeilen AWL, letzter Kommentar von 2009, der Autor seit zwei Jahren in Rente. Jede Änderung wird außen herum gebaut. Nach ein paar Jahren ist die Umgehung selbst der Altbestand, den keiner anfasst.

Was hilft

Abschnittsweise erklären lassen, dann übersetzen, dann Alt und Neu in der Simulation gegen dieselben Eingänge laufen lassen. Drei Wege in den Altcode

/05

Seit die KI hilft, gibt es mehr Stände als vorher

Was es kostet

Der Durchsatz an Änderungen steigt, der Prüfpfad bleibt manuell. Damit steigt auch die Zahl der Stellen, an denen ein falscher Datentyp unbemerkt auf die Anlage kommt. Geschwindigkeit ohne Netz ist in der OT keine Tugend.

Was hilft

Jeder Entwurf wird textbasiert versioniert, automatisiert kompiliert, statisch geprüft und gegen eine virtuelle SPS getestet. Erst ein grünes Gate gibt ihn frei. Wie das Quality Gate aussieht

/06

Der Auditor fragt, wer den generierten Baustein freigegeben hat

Was es kostet

„Das hat die KI geschrieben“ ist auf diese Frage keine Antwort. Ohne Historie wird aus fünf Minuten eine Woche Rekonstruktion aus Mailverläufen. Für IEC 62443 und den Cyber Resilience Act ist das eine Lücke im Nachweis.

Was hilft

Der Commit trägt Autor, Zeitstempel und Begründung, das Review vor der Inbetriebnahme wird zur dokumentierten Freigabe. SPS-Code mit Git versionieren

Quelle der Auswahl: Erstgespräche und Einführungsprojekte bei Comquent, geordnet nach Häufigkeit.

Welcher dieser Punkte bei Ihnen der lauteste ist, entscheidet über die Reihenfolge. Geht es zuerst um neue Logik, springen Sie zu den sechs Prompts. Steht der Altbaustein im Weg, fangen Sie beim gewachsenen Code an. Und wer schon merkt, dass mehr Stände entstehen, als das Team prüfen kann, liest zuerst, was das Quality Gate leistet. Die Werkzeugfrage kommt als Nächstes, weil sie ohne diese Punkte nicht zu beantworten ist.

02
// 02Die Auswahl

Welche KI passt
zu welcher
Steuerung?

Die Steuerung entscheidet. Im TIA Portal sind die Siemens-eigenen Assistenten gesetzt, also Industrial Copilot und Eigen Engineering Agent. Bei Beckhoff ist es TwinCAT Chat, in gemischten Anlagen sind es die herstellerübergreifenden Agenten PLC Assist und PLCcode.ai, für Edge- und IT-Anteile ein generisches Modell wie Claude oder GPT. Weil alle nur Entwürfe liefern, entscheidet über den Nutzen am Ende nicht das Tool, sondern die Pipeline dahinter.

In Projekten kommt die Frage meist in dieser Reihenfolge: erst welches Tool, dann was es kostet, und erst viel später, wer den Vorschlag freigibt. Die Schmerzpunkte oben drehen sie um. Wer ohnehin im TIA Portal arbeitet, hat die Toolfrage fast schon beantwortet, denn nur ein Assistent im Projekt kennt die Variablennamen aus diesem Projekt. Das ist Schmerzpunkt /03, und er entscheidet die Auswahl. Interessant wird es erst danach.

/01

Siemens / TIA Portal

Industrial Copilot · Eigen Engineering Agent

Gesetzt, sobald das Projekt im TIA Portal liegt.

Beide erzeugen SCL-Logik, WinCC-Unified-Bilder und Testfälle im Engineering-Fenster. Dabei kennen sie Variablennamen, Datentypen und den SPS-Typ aus dem geöffneten Projekt. Der Unterschied liegt im Verhalten. Der Industrial Copilot schlägt vor, der seit April 2026 verfügbare Eigen Engineering Agent arbeitet eine Aufgabe eigenständig ab. Diesen Projektkontext hat kein generisches Modell, und genau daran hängt der dritte Schmerzpunkt aus der Liste oben. Schwächer werden beide bei reiner Sprachmigration von AWL nach SCL. Dafür sind die Multi-Vendor-Agenten zwei Zeilen weiter unten die bessere Wahl.

CI/CD für SPS mit TIA Portal & Jenkins
/02

Beckhoff / TwinCAT

Beckhoff TwinCAT Chat

In TwinCAT XAE integriert, ohne Kontextwechsel.

Der Chat sitzt in der Entwicklungsumgebung und ist auf TwinCAT-Anfragen trainiert. Er liefert Structured-Text-Beispiele, erklärt Bibliotheksfunktionen und hilft bei der Fehlersuche. Beckhoff-Projekte haben dabei einen Startvorteil gegenüber binären Projektformaten. Der TwinCAT-Quelltext liegt als Text vor und lässt sich ohne Umweg versionieren und automatisiert bauen, was den Weg zum Quality Gate deutlich verkürzt.

Industrial DevOps für die Steuerungstechnik
/03

Rockwell · CODESYS · gemischte Anlagen

PLC Assist · PLCcode.ai

Herstellerübergreifend, wenn im Werk mehrere Fabrikate stehen.

Die Multi-Vendor-Agenten schreiben und kompilieren ST/SCL, übersetzen zwischen den Dialekten und exportieren nach L5X und PLCopen-XML. Das macht sie zur ersten Wahl für Legacy-Migration und für Anlagen, in denen Siemens, Rockwell und CODESYS nebeneinander laufen. Rockwell selbst hat mit dem FactoryTalk Design Studio Copilot ein eigenes Werkzeug, das allerdings an die Cloud-Umgebung des Design Studio gebunden ist.

Anwendungsfall Maschinenbau & SPS/PLC
/04

IT- und Edge-nah

Claude · GPT-4-Klasse · GitHub Copilot

Für alles neben der Steuerung, und für ST-Entwürfe ohne Projektbindung.

Generische Modelle sind stark bei Edge- und Gateway-Code in C# oder Python, beim Erklären von Fremdcode und bei der Dokumentation. Für SCL taugen sie zum Prototyping; den Projektkontext bekommen sie erst über die Openness-API oder einen MCP-Server. Wer sie ernsthaft in der Steuerungstechnik einsetzt, braucht die Absicherung vorher, nicht hinterher.

Jenkins Pipeline Workshop & KI

Die Kurzdefinition zum Nachschlagen steht im Glossar unter KI in der SPS-Programmierung, dort stehen auch die Unterschiede zwischen Industrial Copilot und Eigen Engineering Agent im Detail. Hier geht es weiter mit dem, was die fünf Werkzeuge unterscheidet, und ab Abschnitt 03 mit den Prompts, die in unseren Projekten tatsächlich brauchbaren SCL-Code liefern.

Welche KI-Tools
für die SPS/PLC-
Programmierung
gibt es 2026?

Die großen SPS-Hersteller haben KI-Assistenten direkt in ihre Engineering-Umgebungen gebaut. Daneben stehen herstellerübergreifende Agenten und generische LLMs. Keines davon ersetzt den Programmierer, alle beschleunigen ihn.

/01

Siemens

Industrial Copilot · Eigen Engineering Agent

Umgebung

TIA Portal · Bezug als Abo über den Siemens Digital Exchange

Rolle

Erzeugt SCL- und KOP-Code, Testlogik und WinCC-Unified-Visualisierung aus natürlicher Sprache. Der Copilot schlägt vor, der Agent arbeitet eine Aufgabe eigenständig ab.

Stärken
  • SCL-Bausteine & Sequencer
  • Signal-Mapping
  • Testfall-Generierung
  • Code-Dokumentation
/02

Beckhoff

TwinCAT Chat

Umgebung

TwinCAT XAE (Visual Studio)

Rolle

In die IDE integrierter Chat, auf TwinCAT-Anfragen trainiert. Liefert Structured-Text-Beispiele und Erklärungen ohne Kontextwechsel.

Stärken
  • ST-Codeschnipsel
  • Refactoring
  • Fehlersuche
  • API-/Library-Fragen
/03

Rockwell

FactoryTalk Design Studio Copilot

Umgebung

FactoryTalk Design Studio (Cloud)

Rolle

In-line-Chat im Editor. Generiert Logix-Logik, schlägt Änderungen vor und führt durch den System-Design-Prozess.

Stärken
  • Projekt-Setup
  • Logix-Routinen
  • Produkt-Guidance
  • Review von Änderungen
/04

Multi-Vendor

PLC Assist · PLCcode.ai

Umgebung

TIA Portal · CODESYS · TwinCAT · Rockwell

Rolle

Hersteller-übergreifende KI-Agenten. Sie schreiben, kompilieren und übersetzen ST/SCL und exportieren nach L5X und PLCopen-XML.

Stärken
  • Cross-Vendor-Übersetzung
  • Legacy-Migration
  • PLCopen-XML-Export
  • Autonomes Kompilieren
/05

Generisch

GPT-4-Klasse · Claude · GitHub Copilot

Umgebung

IDE-Plugin · Web · API · lokal

Rolle

Universelle LLMs für ST-/SCL-Entwürfe, Edge- und IT-Anteile in C# oder Python, Kommentierung und Wissensfragen. Eine native SPS-Integration haben sie nicht, über MCP oder die Openness-API lassen sie sich aber kontextbewusst an das TIA Portal anbinden.

Stärken
  • ST-Prototyping
  • Edge-/Gateway-Code
  • Erklärung von Fremdcode
  • Doku & Kommentare
Berater erläutert am Bildschirm, wie KI-generierter SPS-Code über eine CI/CD-Pipeline geprüft und nachvollziehbar wirdAI
// In 2 Klicks: Welches Tool passt?Schritt 1 / 2

Welches KI-Tool passt zu Ihrer Steuerung?

Fünf KI-Assistenten buhlen um die SPS-Programmierung, und welcher zu Ihnen passt, hängt vor allem an Ihrer Steuerung. Zwei Klicks, und Sie sehen das Tool, das in Ihrer Umgebung am schnellsten trägt.

Mit welcher Steuerung arbeiten Sie überwiegend?

03
// 03Der erste Baustein

Wie erzeugt man einen
SCL-Baustein mit KI?

Sie beschreiben die Anforderung in natürlicher Sprache, also Ein- und Ausgänge, Bedingungen und Grenzwerte. Der Assistent liefert daraufhin einen SCL-Entwurf für einen Funktionsbaustein. Je präziser die Schnittstelle im Prompt steht und je konsequenter Sie die KI ihre Annahmen nennen lassen, desto weniger müssen Sie hinterher korrigieren. Geprüft, kompiliert und freigegeben wird der Entwurf trotzdem vom Menschen.

Das Beispiel rechts zeigt eine einfache Förderband-Verriegelung. Dieselben Prompts funktionieren im Industrial Copilot, in TwinCAT Chat und in einem generischen LLM wie ChatGPT oder Claude. Der Unterschied liegt nicht in der Sprachfähigkeit, sondern im Kontext. Der Hersteller-Assistent kennt Ihre Variablennamen, Datentypen und den SPS-Typ, das Browser-Fenster kennt sie nicht. Wer generisch arbeitet, muss die Schnittstelle im Prompt mitliefern.

Ein Kollege hat den ersten Prompt an einem Freitagnachmittag getippt, mehr aus Neugier als aus Plan. Der Baustein kompilierte im ersten Anlauf, und in PLCSim lief die Verriegelung genau so, wie sie sollte. Solche zwanzig Minuten überzeugen skeptische Kollegen gründlicher als jede Präsentation. Sie sind zugleich der ehrliche Startpunkt für die Frage, was danach kommt.

Was danach kommt, ist Industrial DevOps: generierter Code wird versioniert, getestet und durch eine CI/CD-Pipeline geschleust, bevor er auf die Anlage kommt.

Industrial Copilot · Prompt → SCL-Entwurf
> Prompt: "Erzeuge einen FB für ein Förderband: Start nur bei
  freigegebenem Not-Halt und geschlossener Schutztür."

// KI-Entwurf, vor Übernahme prüfen!
FUNCTION_BLOCK FB_Foerderband
VAR_INPUT
  startTaster   : BOOL;
  notHaltOk     : BOOL;  // TRUE = freigegeben
  schutztuerZu  : BOOL;
END_VAR
VAR_OUTPUT
  motorEin      : BOOL;
END_VAR

// Freigabe nur bei allen Sicherheitsbedingungen
IF startTaster AND notHaltOk AND schutztuerZu THEN
  motorEin := TRUE;
ELSIF NOT notHaltOk OR NOT schutztuerZu THEN
  motorEin := FALSE;
END_IF;

⚠ Funktionaler Entwurf, keine Safety-Funktion. Not-Halt-Sicherheit gehört in eine zertifizierte F-CPU oder Safety-SPS, nicht in Standard-SCL.

Sechs Prompts für
neue Logik und Bausteine.

Die folgenden Prompts decken die Arbeitsschritte ab, die in Steuerungsprojekten regelmäßig anfallen. Sie sind bewusst wortreich. Ein Prompt, der Schnittstelle, Randbedingungen und die Bitte um offengelegte Annahmen enthält, spart mehr Zeit, als er kostet. Jede Zeile darunter nennt, worauf Sie im Ergebnis zuerst schauen sollten. Das ist die Antwort auf Schmerzpunkt /01: Der Entwurf kommt in Sekunden, die Prüfreihenfolge liefert der Prompt gleich mit.

Der Prüfteil ist nicht optional. Er ist der Teil, für den Sie bezahlt werden.

/01

SCL-Funktionsbaustein aus einer Anforderung erzeugen

Erzeuge einen SCL-Funktionsbaustein FB_Dosierung für eine Dosierstation. Eingänge: Startbefehl, Sollmenge in kg (REAL), Istmenge vom Wägemodul. Ausgänge: Ventil auf, Fertigmeldung, Störung. Abschaltung bei Sollmenge abzüglich Nachlaufmenge. Kommentiere jede Variable und nenne am Ende alle Annahmen, die du getroffen hast.

PrüfenNennt die KI ihre Annahmen? Fehlt die Nachlaufkorrektur? Passt REAL zur Auflösung Ihres Wägemoduls?

/02

Schrittkette in SCL generieren lassen

Schreibe eine Schrittkette in SCL für einen Werkzeugwechsel in fünf Schritten: Entriegeln, Ausfahren, Wechseln, Einfahren, Verriegeln. Nutze eine CASE-Anweisung über eine Schrittvariable, gib jedem Schritt eine eigene Überwachungszeit und ergänze einen Störschritt. Keine Sprungbefehle.

PrüfenKommt die Kette aus jedem Schritt wieder heraus? Hat jeder Schritt eine eigene Zeit? Gibt es einen definierten Weg in den Grundzustand?

/03

Analogwert skalieren und Grenzwerte überwachen

Erzeuge einen SCL-Baustein, der einen Rohwert von 0…27648 auf 0…100 bar skaliert. Mit Über- und Unterlaufprüfung, Drahtbrucherkennung unterhalb 4 mA und 2 % Hysterese auf den Grenzwertmeldungen.

PrüfenRechnet der Baustein in REAL statt INT? Wirkt die Hysterese beidseitig? Was passiert bei einem Rohwert von 32767?

/04

Symbolliste in Datenbaustein und E/A-Mapping übersetzen

Hier ist ein Ausschnitt unserer Symbolliste als CSV. Erzeuge daraus einen SCL-Datenbaustein mit einer eigenen Struktur je Aggregat sowie das Mapping der E/A-Adressen. Übernimm die Kommentare aus der CSV unverändert und melde jede Doppelbelegung, statt sie zu überschreiben.

PrüfenSind alle Adressen unverändert übernommen? Wurden Doppelbelegungen gemeldet oder stillschweigend zusammengeführt?

/05

Testfälle für PLCSim aus dem Baustein ableiten

Leite aus diesem Funktionsbaustein eine Liste von Testfällen ab: Normalbetrieb, Grenzwerte, Fehlerfälle und Wiederanlauf nach Not-Halt. Gib je Testfall Vorbedingung, Eingangsbelegung und erwartetes Verhalten an, als Tabelle, die ich in ein Testskript übernehmen kann.

PrüfenSind Wiederanlauf und Störquittierung abgedeckt? Fehlt ein Fall, den Sie aus der letzten Inbetriebnahme kennen?

/06

Bestehenden Baustein refaktorieren, ohne das Verhalten zu ändern

Refaktoriere diesen SCL-Baustein: sprechende Namen, wiederkehrende Logik in Unterfunktionen, sonst keine Änderung am funktionalen Verhalten. Liste am Ende jede Stelle auf, an der du das Verhalten doch verändert hast oder dir unsicher bist.

PrüfenIst die Liste am Ende leer, und stimmt das auch? Ein Diff gegen den vorherigen Stand beantwortet die Frage schneller als jedes Durchlesen.

04
// 04Der alte Baustein

Wie hilft KI bei
gewachsenem Altcode?

KI liest Altcode schneller als jeder Mensch. Sie erklärt gewachsene Bausteine in Klartext, übersetzt AWL nach Structured Text und zieht fehlende Dokumentation nach. Was sie nicht kann, ist die Anlage kennen. Jede Übersetzung braucht deshalb eine Gegenprobe in der Simulation.

Das ist Schmerzpunkt /04, und meist geht es um genau einen Baustein. Neunhundert Zeilen AWL, der letzte Kommentar von 2009, und der Kollege, der ihn geschrieben hat, ist seit zwei Jahren in Rente. Angefasst wird er nur, wenn es sich nicht vermeiden lässt. In fast jedem Anlagenprojekt gibt es diesen einen Baustein. Er sieht so aus, weil fünfzehn Jahre Betrieb jede Änderung im laufenden Takt verlangt haben.

Genau hier liegt der zweite große Nutzen generativer KI, und kommerziell ist er oft der wertvollere. Es geht nicht darum, schneller neuen Code zu schreiben, sondern vorhandenen endlich wieder änderbar zu machen. Wie das in einem Migrationsprojekt bis zur durchgängigen Pipeline aussieht, zeigt der Anwendungsfall Maschinenbau & SPS/PLC.

/01

Gewachsenen Baustein in Klartext erklären lassen

Ein Baustein wird abschnittsweise in den Assistenten gegeben, mit der Bitte um eine Beschreibung in ganzen Sätzen: Was tut der Abschnitt, welche Bedingungen führen wohin, welche Variable hält welchen Zustand. Das Ergebnis ist kein Ersatz für Anlagenkenntnis, aber ein Einstieg, der Stunden statt Wochen dauert.

Erkläre diesen SCL-Abschnitt in ganzen Sätzen: Zweck, Bedingungen, Zustände. Markiere jede Stelle, an der du dir nicht sicher bist, und formuliere dazu eine Frage, die ich einem Kollegen stellen könnte.
/02

AWL-Altcode nach Structured Text heben

AWL-Bausteine lassen sich abschnittsweise nach SCL übersetzen. Verlässlich wird das erst mit Gegenprobe: Alt und Neu laufen in der Simulation gegen dieselben Eingangsbelegungen, die Ausgänge werden verglichen. Ohne diesen Vergleich ist eine Migration eine Vermutung.

Übersetze diesen AWL-Baustein nach SCL. Behalte Variablennamen und Adressen bei, ändere die Logik nicht. Nenne anschließend jede Konstruktion, die sich nicht eins zu eins übersetzen ließ, und begründe deine Entscheidung.
/03

Fehlende Dokumentation nachziehen

Aus dem Code entstehen Bausteinbeschreibungen, Variablenkommentare und eine Übersicht, welcher Baustein welchen Anlagenteil bedient. Das ist die Grundlage dafür, dass die nächste Änderung nicht wieder Archäologie erfordert. Und es ist der Punkt, an dem sich Versionsverwaltung endlich lohnt.

Erzeuge aus diesem Projektstand eine Übersicht: welcher Baustein bedient welchen Anlagenteil, welche Bausteine rufen einander auf, welche sind offenbar unbenutzt. Kennzeichne Vermutungen als solche.
05
// 05Was heute geht

Was kann KI in der
SPS-Programmierung
heute leisten?

Sechs Einsatzfelder, in denen KI in der SPS-Programmierung heute schon Zeit spart und die Qualität hebt.

Use-Case / 01

Boilerplate & Bausteine

Standard-Funktionsbausteine, Zustandsautomaten, Skalierungs- und Diagnosefunktionen entstehen aus einer kurzen Beschreibung. Das ist der Teil der Programmierung, der Zeit frisst und sich ständig wiederholt.

Use-Case / 02

Code erklären & einarbeiten

KI erklärt fremden oder gewachsenen Legacy-Code in Klartext. Neue Mitarbeiter verstehen ein 15 Jahre altes Anlagenprojekt in Stunden statt Wochen. Am besten, bevor der Kollege in Rente geht, der als Einziger noch weiß, warum FB_47 so aussieht, wie er aussieht.

Use-Case / 03

Refactoring & Migration

Strukturierung unübersichtlicher Bausteine, Übersetzung zwischen Vendor-Dialekten und Hebung von AWL/KOP-Altcode nach Structured Text.

Use-Case / 04

Dokumentation & Kommentare

Konsistente Kommentierung, Variablenbeschreibungen und Bedienungsanleitungen. Genau der Teil, der im Projektdruck zuerst liegen bleibt.

Use-Case / 05

Test & Simulation

Testfälle und Simulationsszenarien für PLCSim Advanced oder die TwinCAT-Runtime. Sie sind die Basis für jeden automatisierten Test in der Pipeline.

Use-Case / 06

Fehlersuche & Diagnose

Analyse von Fehlermeldungen, Plugin-Konflikten und Laufzeitproblemen mit konkreten Lösungsvorschlägen statt Forensuche.

06
// 06Wo es aufhört

Wo stößt KI in der
SPS-Programmierung
an ihre Grenzen?

KI ist kein Autopilot für die Steuerungstechnik. Diese Grenzen muss jeder kennen, der sie einsetzt.

Hürde / 01

Halluzinationen & Nicht-Determinismus

LLMs erzeugen plausibel klingenden, aber teils falschen Code. Erfundene Bausteine, fehlende Verriegelungen. Studien wie LLM4PLC zeigen, dass reine ST-Generierung ohne Verifikation nur teilweise kompiliert.

Hürde / 02

Safety & Zertifizierung

Sicherheitsgerichtete Logik nach IEC 61508/62061 und ISO 13849 (SIL/PL) braucht zertifizierte Toolchains und lückenlose Nachweise. KI-Vorschläge sind dort allenfalls Entwurf, niemals Freigabe.

Hürde / 03

Echtzeit & Determinismus

Harte Echtzeitregelung (Motion-Control, Lageregler unter 1 ms) toleriert keine probabilistisch generierten Pfade. Timing-Garantien muss der Programmierer verantworten.

Hürde / 04

Proprietäre, binäre Formate

Viele Projektformate sind binär und herstellergebunden. KI braucht eine textbasierte Quelle über Openness-API, TwinCAT-Quelltext oder PLCopen-XML. Sonst bleibt sie außen vor.

Hürde / 05

IP-Schutz & Datenschutz

Steuerungslogik ist geschäftskritisches Eigentum. Ein ungeprüfter Upload an öffentliche LLM-Endpunkte ist ein Compliance-Risiko. Enterprise-Instanz oder lokales Modell sind Pflicht.

Hürde / 06

Dünne Trainingsdaten

Für Nischen-Steuerungen und herstellerspezifische Libraries existiert kaum öffentliches Trainingsmaterial. Qualität und Halluzinationsrate hängen stark vom Vendor-Dialekt ab.

07
// 07Das Sicherheitsnetz

KI geht nicht ohne
Automatisierung.

Ein KI-Vorschlag, den niemand automatisiert prüft, baut und versioniert, ist ein Risiko und kein Fortschritt.

KI-generierter IEC-61131-3-Code wandert vom Laptop über eine CI/CD-Pipeline mit den Stationen Code-Analyse, Build und Test und einem grünen Quality Gate in eine Siemens-SPS im SchaltschrankAI
Der KI-Entwurf passiert Code-Analyse, Build & Test und das Quality Gate. Erst dann erreicht er die SPS.

Generative KI vervielfacht den Durchsatz an Codeänderungen. Genau das macht sie ohne Automatisierung gefährlich. Mehr Änderungen pro Tag heißt mehr Stellen, an denen eine Halluzination, eine fehlende Verriegelung oder ein Datentyp-Fehler unbemerkt auf die Anlage gelangt. Geschwindigkeit ohne Sicherheitsnetz ist in der OT keine Tugend. Der übliche Anfang ist ein SCL-Schnipsel aus dem Browser-Chat, kopiert ins Projekt. Das ist Schmerzpunkt /02, und kritisch wird er erst, wenn das Netz darunter nicht zügig folgt.

KI ist die vierte Stufe, die Intelligisierung, und sie setzt auf der dritten auf, der Automatisierung. Wer die dritte Stufe überspringt, bekommt die vierte nicht zum Laufen.

Das Sicherheitsnetz heißt CI/CD. Jeder KI-Entwurf wird textbasiert versioniert, automatisiert kompiliert, statisch analysiert und gegen eine virtuelle SPS getestet. Erst ein grünes Quality Gate gibt ihn frei. Dieselbe Pipeline, die DevOps-Teams schnell und sicher macht, zähmt auch die KI. Damit ist auch Schmerzpunkt /06 beantwortet, denn jeder Commit trägt Autor, Zeitstempel und Begründung. Wie das für Steuerungscode konkret aussieht, zeigt der Praxisartikel CI/CD für SPS mit TIA Portal & Jenkins.

In der industriellen Praxis trägt Jenkins diese Strecke. Er ist robust, läuft on-premise und ist air-gap-fähig, also auch im abgeschotteten OT-Netz einsetzbar. Wer KI und Jenkins zusammen denkt, lernt das am schnellsten im Jenkins Pipeline Workshop & KI und im Workshop Jenkins Administration & KI.

Jenkinsfile · KI-generierter SPS-Code im Quality Gate
pipeline {
  agent { label 'tia-windows' }
  stages {
    // KI-Entwurf kommt als Text aus dem TIA-VCI
    stage('Checkout')   { steps { git 'ssh://scm/sps.git' } }
    stage('Build')      { steps { bat 'openness compile' } }
    stage('Static-Analyse') { steps { bat 'plcopen-lint' } }
    stage('Test (PLCSim)') { steps { bat 'pytest --plcsim' } }
    // erst grün → Promotion auf reale Hardware
    stage('Quality Gate') {
      steps { waitForQualityGate abortPipeline: true }
    }
  }
}

Ohne dieses Gate landet KI-Code ungeprüft auf der Anlage. Jenkins · Openness-API · PLCSim Advanced · IEC 62443

08
// 08Wie Sie starten

KI in der
SPS-Programmierung
sicher einführen.

Fünf Leitplanken, mit denen KI Nutzen stiftet, ohne Sicherheit und Nachvollziehbarkeit zu gefährden. Wie Comquent Industrial DevOps für die Steuerungstechnik im Maschinenbau in realen Projekten umsetzt, zeigt der dazugehörige Anwendungsfall.

/01
Ebene

Governance

Anwendungsfall abgrenzen: neue Logik ja, Safety nein

Der häufigste Wunsch ist zugleich der sinnvollste Einstieg: neue Standardlogik, also Funktionsbausteine, Schrittketten, Skalierung und Diagnose. Dort trägt KI, weil sich jeder Entwurf gegen Compiler und Simulation prüfen lässt. Die Grenze verläuft nicht zwischen „neu“ und „harmlos“, sondern zwischen prüfbar und zertifiziert. Safety-relevante Logik (SIL/PL) und harte Echtzeitregelung bleiben manuell und zertifiziert. Schreiben Sie auf, was KI nicht anfassen darf.

/02
Ebene

Prozess

Human-in-the-Loop verankern

Jeder KI-Vorschlag wird von einem qualifizierten SPS-Programmierer gelesen, verstanden und verantwortet, bevor er ins Projekt wandert. KI liefert Entwürfe, die Freigabe trägt immer der Mensch. „Vibe Coding“ hat in der OT nichts zu suchen.

/03
Ebene

Qualität

Verifikation automatisieren

Generierten Code gegen Compiler, statische Analyse (PLCopen Coding Guidelines) und Simulation (PLCSim Advanced, TwinCAT-Runtime) prüfen. Formale Verifikation, wo möglich. Erst nach grünem Gate geht es weiter, analog zum LLM4PLC-Ansatz aus der Forschung.

/04
Ebene

Pipeline

Versionierung & CI/CD anschließen

KI-Code als Text in Git versionieren, Pull-Request-Review erzwingen, automatisiert bauen und testen. So entsteht ein lückenloser Audit-Trail, die Basis für IEC-62443- und CRA-Konformität. Wer KI ohne Versionskontrolle einsetzt, verliert die Nachvollziehbarkeit. Im Schadensfall steht dann die Frage im Raum, welcher Codestand zum Zeitpunkt des Vorfalls auf der Anlage lief. Diese Frage stellen Auditoren, und sie stellen Versicherer.

/05
Ebene

Compliance

Datenschutz & Modell-Governance klären

Vor dem Rollout festlegen: Cloud-Enterprise-Instanz (z. B. Azure OpenAI mit Datenisolierung) oder lokal/air-gapped gehostetes Modell. Proprietären Steuerungscode nicht an öffentliche Endpunkte senden. Prompt-Bibliothek mit geprüften, wiederverwendbaren Mustern aufbauen.

// 09Woher wir das wissen

Belege statt
Hype.

Die Forschung ist deutlich: LLMs allein liefern keinen zuverlässigen SPS-Code. Der LLM4PLC-Ansatz steigert die Erfolgsrate für Structured Text durch nachgeschaltete Compiler- und formale Verifikation von 47 % auf 72 %. Das ist exakt das Muster, das auch in der industriellen Praxis trägt.

Hersteller- und Forschungsquellen zum Weiterlesen, von Siemens, Beckhoff und Rockwell bis zu den einschlägigen wissenschaftlichen Arbeiten.

Whitepaper · 21 Seiten · PDF

Die ausführliche Fassung steht im Whitepaper „KI in der SPS-Entwicklung“. Es ordnet mehr als zwei Dutzend Werkzeuge, Studien und Praxisfälle ein und trennt Herstellerzahlen von Messwerten.

Der Befund, der die Zahl oben ergänzt, ist unbequem. Bei Agents4PLC übersetzte der Code von GPT-4o in allen Fällen, die formale Prüfung bestand er bei mittelschweren Aufgaben aber nur zu 28,6 Prozent. Wie Sie KI-generierten SPS-Code trotzdem sicher einsetzen, zeigen sieben Prüfstufen und eine Checkliste für die Werkzeugwahl.

Whitepaper kostenlos anfordern
// 10Was jetzt meist gefragt wird

FAQ zu KI in der
SPS-Programmierung.

/01
Kann KI eine SPS programmieren?
Generative KI kann SPS-Code in IEC-61131-3-Sprachen, vor allem Structured Text (ST/SCL), aus natürlicher Sprache erzeugen, erklären, refaktorieren und dokumentieren. Tools wie der Siemens Industrial Copilot, der Eigen Engineering Agent für das TIA Portal, Beckhoff TwinCAT Chat und Rockwell FactoryTalk Copilot sind 2026 produktiv. KI ersetzt aber nicht den Programmierer: Sie liefert Entwürfe, die ein qualifizierter Mensch prüfen und verantworten muss. Safety-Logik und harte Echtzeit bleiben manuell und zertifiziert.
/02
Welche KI ist die beste für die SPS-Programmierung im TIA Portal?
Im TIA Portal liefern die Siemens-eigenen Assistenten die verlässlichsten Ergebnisse, weil sie Projektkontext, Variablennamen und Datentypen kennen und SCL direkt im Engineering-Fenster erzeugen. Siemens führt dafür zwei Produkte: den Industrial Copilot, der vorschlägt, und seit April 2026 den Eigen Engineering Agent, der eine Aufgabe eigenständig abarbeitet. Beide decken neben SCL auch KOP, Testlogik und die WinCC-Unified-Visualisierung ab; bezogen werden sie als Abo über den Siemens Digital Exchange. Generische Modelle wie ChatGPT oder Claude entwerfen Standardlogik ähnlich gut, verlieren ohne Anbindung über die Openness-API oder MCP aber den Projektkontext. Für die Praxis entscheidet ohnehin weniger das Modell als das, was danach passiert: Ein Entwurf ist erst brauchbar, wenn er versioniert, kompiliert und gegen PLCSim getestet wurde.
/03
Wie kann man SPS-Programme mit KI programmieren?
In vier Schritten: die Anforderung samt Schnittstelle beschreiben, den Entwurf vom Assistenten erzeugen lassen, seine Annahmen prüfen, dann kompilieren und in der Simulation gegenrechnen. Über die Qualität entscheidet der Prompt. Wer Ein- und Ausgänge, Datentypen und Grenzwerte nennt und die KI ihre Annahmen auflisten lässt, korrigiert hinterher deutlich weniger. Ohne die Gegenprobe in PLCSim Advanced oder der TwinCAT-Runtime bleibt jeder generierte Baustein eine Vermutung, auch wenn er sauber aussieht.
/04
Ersetzt KI den SPS-Programmierer?
Nein, die Rolle des SPS-Programmierers verschiebt sich, sie verschwindet nicht. Generative KI übernimmt einen Großteil der Vorarbeit (in Praxisberichten 70–80 % der Codebasis: Boilerplate, Standardbausteine, Diagnose- und Dokumentationscode), doch Spezifikation, Validierung, Test und Freigabe bleiben beim qualifizierten Menschen. Der Arbeitsalltag verlagert sich vom Tippen zum Prüfen: Review und Verifikation von KI-Ergebnissen werden zur Kernkompetenz. Safety-gerichtete Logik (SIL/PL) und harte Echtzeitregelung verantwortet weiterhin der Programmierer.
/05
Was ist „SPS GPT“ und kann ich GPT für die SPS-Programmierung nutzen?
„SPS GPT“ ist keine eigene Software, sondern die verbreitete Kurzform dafür, GPT-Modelle wie ChatGPT für die SPS-Programmierung mit KI einzusetzen. Modelle der GPT-4-Klasse entwerfen Structured Text (ST/SCL) aus natürlicher Sprache und taugen für Prototypen und Standardlogik; bei herstellerspezifischen Bibliotheken und Projektkontext lassen sie nach. Den Kontext bekommt GPT erst über die Openness-API oder einen MCP-Server, der Variablennamen, Datentypen und SPS-Typ zugänglich macht. Vor der Anlage gehört jeder generierte Baustein durch Compiler, statische Analyse und einen Testlauf in PLCSim.
/06
Kann ich mit ChatGPT SPS-Code (SCL) für das TIA Portal generieren?
Ja. Generische LLMs wie ChatGPT (GPT-4-Klasse) oder Claude entwerfen Structured Text bzw. SCL für das TIA Portal, gut für Prototypen und Standardlogik, schwächer bei herstellerspezifischen Bibliotheken und Projektkontext. Zuverlässiger wird es mit kontextbewussten Integrationen, die das LLM über die Openness-API oder per MCP an das TIA Portal anbinden, sodass Variablennamen, Datentypen und SPS-Typ bekannt sind. In jedem Fall gilt: generierten SCL-Code kompilieren, statisch prüfen und gegen PLCSim testen, bevor er auf die Anlage kommt, und vorab per Governance klären, ob proprietärer Code an ein Cloud-LLM gesendet werden darf.
/07
Welche KI eignet sich für die TwinCAT-Programmierung bei Beckhoff?
Einen KI-Assistenten unter dem Namen „Beckhoff Copilot“ gibt es nicht; das Beckhoff-Pendant heißt TwinCAT Chat und ist die naheliegende Wahl, weil er in TwinCAT XAE sitzt und auf TwinCAT-Anfragen trainiert ist. Er liefert Structured-Text-Beispiele, erklärt Bibliotheksfunktionen und hilft bei der Fehlersuche, ohne dass Sie die Entwicklungsumgebung verlassen. Für alles außerhalb der Steuerung, also Edge-Dienste, Konfigurationswerkzeuge und Auswertung, greifen Teams meist zusätzlich zu einem generischen Modell. Ein Vorteil gegenüber binären Projektformaten: TwinCAT-Quelltext liegt als Text vor und lässt sich deshalb ohne Umweg versionieren und automatisiert bauen.
/08
Welche KI migriert AWL-Code nach SCL?
AWL nach SCL übersetzen sowohl generische Modelle als auch die herstellerübergreifenden Agenten PLC Assist und PLCcode.ai, die zusätzlich nach PLCopen-XML und L5X exportieren. Die Siemens-Assistenten spielen ihre Stärke bei neuer Logik im Projektkontext aus; für reine Sprachmigration greifen Teams eher zu den Multi-Vendor-Werkzeugen. Voraussetzung ist in beiden Fällen eine textbasierte Quelle über die Openness-API, denn an binäre Projektstände kommt kein Assistent heran. Und die Übersetzung bleibt eine Vermutung, solange Alt- und Neuverhalten nicht in der Simulation gegeneinander laufen.
/09
Welche KI-Tools gibt es 2026 für die SPS-Programmierung?
Hersteller-integriert: Siemens Industrial Copilot und Eigen Engineering Agent (beide für das TIA Portal), Beckhoff TwinCAT Chat (ST in TwinCAT XAE) und Rockwell FactoryTalk Design Studio Copilot. Hersteller-übergreifend: PLC Assist und PLCcode.ai für Multi-Vendor-Generierung und -Übersetzung. Dazu generische LLMs (GPT-4-Klasse, Claude) und GitHub Copilot für die umgebenden IT-/Edge-Anteile.
/10
Welche Sprache generiert KI in der SPS-Programmierung am besten?
Structured Text (ST) bzw. SCL, weil textbasiert, nah an Pascal/C und mit den meisten Trainingsdaten. Grafische Sprachen wie KOP (LD), FUP (FBD) und AS (SFC) sind schwieriger, da sie als Grafik vorliegen; Lösungen entstehen meist über PLCopen-XML als Zwischenformat.
/11
Ist von KI generierter SPS-Code sicher?
Nicht automatisch. LLMs können syntaktisch korrekten, aber logisch falschen Code erzeugen (Halluzinationen). Forschung wie LLM4PLC zeigt: erst Compiler- und formale Verifikation heben die Erfolgsrate deutlich an. Pflicht sind Human-in-the-Loop, automatisierte Verifikation (Compiler, statische Analyse, Simulation) und ein CI/CD-Gate. Safety-Funktionen verantwortet keine KI.
/12
Gibt es eine Open-Source-KI für die SPS-Programmierung?
Ein fertiges Open-Source-Modell, das ausschließlich für SPS-Code trainiert wurde, ist 2026 nicht am Markt. Was es gibt, sind offene Sprachmodelle mit frei verfügbaren Gewichten, die sich lokal betreiben und auf eigenem Steuerungscode nachtrainieren lassen. Für air-gapped OT-Netze ist das der einzige Weg, bei dem kein Quelltext das Werk verlässt. Die brauchbarste Vorlage dafür stammt aus der Forschung um LLM4PLC. Das Modell erzeugt, ein Compiler und eine formale Prüfung korrigieren, und erst dieser Kreislauf hebt die Trefferquote spürbar.
/13
Was sind die größten Herausforderungen bei KI in der SPS-Programmierung?
Halluzinationen und Nicht-Determinismus, funktionale Sicherheit und Zertifizierbarkeit (IEC 61508/62061, ISO 13849), harte Echtzeitanforderungen, proprietäre binäre Projektformate, IP-Schutz und Datenschutz bei Cloud-LLMs, dünne Trainingsdaten für Nischen-Steuerungen und die Integration in Test-, Versionierungs- und Freigabeprozesse.
/14
Wie integriere ich KI-generierten SPS-Code in CI/CD?
Wie jeden Quelltext: als Text in Git versionieren (Openness-API, TwinCAT-Quelltext, PLCopen-XML), Pull-Request-Review erzwingen, automatisiert kompilieren, statisch analysieren und gegen eine virtuelle SPS (PLCSim Advanced, TwinCAT-Runtime) testen. Promotion erst nach grünem Quality Gate. Das ergibt den Audit-Trail für IEC 62443 und den Cyber Resilience Act.
/15
Warum geht KI in der SPS-Programmierung nicht ohne Automatisierung?
Weil KI den Durchsatz an Codeänderungen vervielfacht und damit die Zahl der Stellen, an denen ein Fehler unbemerkt auf die Anlage gelangt. Ohne automatisiertes Sicherheitsnetz wird Geschwindigkeit zum Risiko. Erst eine CI/CD-Pipeline, die jeden KI-Entwurf versioniert, kompiliert, statisch prüft und gegen eine virtuelle SPS testet, macht KI in der OT verantwortbar. In der Praxis ist Jenkins das Rückgrat dieser Strecke: robust, on-premise und air-gap-fähig, also auch im abgeschotteten OT-Netz einsetzbar.
/16
Darf ich proprietären SPS-Code an ein Cloud-LLM senden?
Das ist eine Governance-Entscheidung vor dem Rollout. Öffentliche LLM-Endpunkte können Eingaben verarbeiten und speichern, Steuerungslogik ist meist geschäftskritisches IP. Hersteller-Copilots laufen über dedizierte Enterprise-Instanzen (z. B. Azure OpenAI mit Datenisolierung). Für air-gapped OT-Netze bieten sich lokal gehostete Open-Weight-Modelle an. Klare Richtlinien, welche Daten an welches Modell dürfen, sind Voraussetzung.
// Ihr nächster Schritt1 Klick, anonym

Wie geht es bei Ihnen mit KI in der SPS-Programmierung weiter?

Sagen Sie uns mit einem Klick, wie es bei Ihnen weitergeht. Passend dazu bekommen Sie direkt einen konkreten nächsten Schritt — ganz ohne Formular.

// KI in der OT, aber richtig

KI nutzen.
Sicherheit
behalten.

Wir helfen Ihnen, generative KI in Ihre SPS-Engineering-Workflows einzuführen, mit Human-in-the-Loop, automatisierter Verifikation und CI/CD-Gate. Nutzen ohne Risiko für Determinismus und Zertifizierbarkeit. Der Einstieg kostet nichts. In 30 Minuten schildern Sie Ihren Stand, und wir sagen ehrlich, wo KI bei Ihnen trägt und wo noch nicht.

// Nächster Schritt

Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.

Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.

Erstgespräch buchen
Seit 2006 · 47+ Projekte
Industrie · Automotive · Finance