Code-Erzeugung für Industriesteuerungen (SPS, IEC 61131-3)

Speicherprogrammierbare Steuerungen (SPS) betreiben Maschinen und Anlagen, und ihre Programme werden weiterhin überwiegend von Hand in Hersteller-IDEs geschrieben. LLM-Assistenten sitzen inzwischen in diesen IDEs (Siemens TIA Portal, CODESYS, TwinCAT, Rockwell), und Forschungs-Agenten schließen die Schleife mit Compilern, Simulatoren und Model Checkern. Der realistische Nutzen sind schnellere erste Entwürfe, die Erläuterung von Altbausteinen und eine bessere Testabdeckung – nicht die unbeaufsichtigte Erzeugung sicherheitsrelevanter Steuerungslogik.

Problem & Nutzen

• Heute: Ingenieure übersetzen eine Funktionsspezifikation von Hand in Structured Text (ST), Kontaktplan (LD), Funktionsbausteinsprache (FBD) oder Ablaufsprache (SFC), und zwar in herstellerspezifischen Werkzeugen mit proprietären Dialekten und Bibliotheken. Das Wissen liegt bei wenigen erfahrenen Personen; qualifizierte Automatisierungsingenieure sind knapp; Altcode ist schlecht dokumentiert.
• KI-Nutzen: Standardcode entwerfen (Zustandsautomaten, Wrapper für Bewegung/Ventile/Antriebe, Alarmbehandlung), unbekannte Bausteine erklären, Handbücher in natürlicher Sprache durchsuchen, Tests und Dokumentation erzeugen und zwischen Dialekten übertragen. Siemens, CODESYS und Beckhoff positionieren diese Assistenten als Produktivitätshilfen für wiederkehrende Aufgaben [1][3][4].
• Die Beleglage ist dünn: Veröffentlichte Nutzenversprechen sind überwiegend Herstelleraussagen. Wissenschaftliche Arbeiten berichten von Teilerfolgen: Agents4PLC meldet bei 23 Aufgaben einen Erfolg der formalen Verifikation von bis zu rund 68,8 %, und ein Beitrag von 2025 stellt verbleibende Lücken zwischen Forschungsergebnissen und industriellen Anforderungen fest [5][6]. Messen Sie am eigenen Code, bevor Sie Zahlen versprechen.

Varianten

• IDE-Copilot (Engineering-Assistent): Chat/Vervollständigung in der Hersteller-IDE; die am häufigsten eingesetzte Form.
• Agent von der Spezifikation zum Code: Spezifikation hinein, ST heraus, mit Rückmeldungen von Compiler, Simulator und Model Checker (Muster LLM4PLC / Agents4PLC).
• Dialektübersetzung und Altmigration: z. B. Step 7 / Kontaktplan nach ST, Hersteller A zu Hersteller B oder zu CODESYS-basierten Laufzeitumgebungen (siehe CODE-005).
• Unterstützung bei Test und Inbetriebnahme: Testsequenzen und Szenarien für die virtuelle Inbetriebnahme gegen einen digitalen Zwilling erzeugen.
• Maschinenbauer (KMU): eine Bibliothek von Funktionsbausteinen je Kundenvariante parametrieren, statt frei zu generieren.
• Ausbildung/Hobby: ST auf Simulatoren lernen; keine Auswirkung auf die Sicherheit.

So funktioniert es

1. spec / I/O list / P&ID (+ company standard, vendor libraries via RAG)
2. LLM plans design (state machine, interfaces, tags)
3. LLM writes ST / function blocks
4. compile check (vendor compiler, or open-source MATIEC for IEC 61131-3 ST)
5. simulate / unit test (PLCSIM-class simulator, CODESYS Control Win, digital twin)
6. optional formal check (nuXmv, PLCverif) against requirements as temporal properties
7. errors fed back to LLM (loop, bounded)
8. engineer review + peer review + FAT/SAT commissioning
9. download to PLC

• Schlüsselkomponenten: ein Code-LLM mit Retrieval über Herstellerhandbücher und Ihre Funktionsbaustein-Bibliothek; deterministisches Werkzeug-Feedback (Compiler, Simulator, Model Checker) als wichtigster Qualitätshebel; das Model Context Protocol (MCP), um die IDE dem Modell zugänglich zu machen (CODESYS MCP Server) [4].
• Mensch-in-der-Schleife (Human-in-the-Loop): verpflichtend. Der Ingenieur prüft jede erzeugte Zeile, führt die Testsuite in der Simulation aus, und nur ein Mensch lädt Code auf eine echte Steuerung. Sicherheitscode (Sicherheits-SPS, Funktionen mit SIL-/PL-Einstufung) wird nie automatisch erzeugt; der Copilot von Rockwell kann ihn zum Beispiel erklären, aber nicht ändern [7].

Datenaufbereitung

Die KI braucht Ihren Engineering-Kontext: bestehende SPS-Projekte und Funktionsbaustein-Bibliotheken, Namens- und Programmierrichtlinien, E/A-Listen, R&I-Fließbilder und Funktionsbeschreibungen, Herstellerhandbücher und Inbetriebnahmenotizen. In einem KMU liegen diese in TIA-Portal- oder CODESYS-Projektdateien, auf Dateiablagen, auf Laptops einzelner Programmierer, in PDFs und auf Papierplänen.

Typische Lücken: keine gemeinsame Bibliothek oder Namenskonvention, Spezifikationen als Scan oder in Word, kein Simulationsmodell zum Testen erzeugten Codes, undokumentiertes Maschinenverhalten, Wissen in der Hand eines erfahrenen Programmierers und Projektdateien mit kundenvertraulichen Maschinendaten.

Schritte der Aufbereitung: - Referenzprojekte und freigegebene Funktionsbausteine in der Versionsverwaltung zusammenführen (PREP-009, PREP-010). - Die Programmierrichtlinie und die Tag-Namensregeln als kurzes Regelwerk aufschreiben (PREP-014, PREP-015). - E/A-Listen und Spezifikationen in saubere Tabellen überführen (PREP-011); alte Pläne nur bei Bedarf scannen und per OCR erfassen (PREP-006). - Handbücher und Normen als durchsuchbare Wissensbasis aufbereiten (PREP-013). - Eine SPS-Simulation oder einen Prüfstand als Bewertungsgrundlage einrichten (PREP-018).

Aufwandsanteil: gering bis mittel, etwa 15-25 %, überwiegend Bereinigung der Bibliothek. GUIDE-003 bietet eine Bestandsaufnahme-Vorlage.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A, weil die SPS-Hersteller (Siemens, CODESYS/WAGO, Beckhoff) Copilots in ihren Engineering-Werkzeugen mitliefern und der Maschinenbauer oder Integrator in einem unterstützten Ökosystem bleibt.
• Großunternehmen: Weg B, weil Anlagen- und Maschinen-Know-how ein Geschäftsgeheimnis ist, Normen und Bibliotheken unternehmensspezifisch sind und ein Gerüst mit Simulation und statischer Analyse herstellerübergreifend wiederverwendet werden kann.
• Entwickler: Weg B, weil Integratoren und Werkzeugbauer eine herstellerneutrale Erzeugung und Verifikation gegen ihre eigenen Funktionsbaustein-Bibliotheken brauchen; der Selbstbetrieb ist optional, wo der Code vor Ort bleiben muss.

Weg A — Kaufen (empfohlen)

• Siemens Industrial Copilot / Engineering Copilot TIA (EU): Chatbot, der mit einem lokalen TIA Portal verbunden ist, SCL für Simatic erzeugt, Bausteine erklärt und Handbücher durchsucht; auf Azure OpenAI aufgebaut; z. B. von Schaeffler genutzt [1][2].
• KI-gestütztes Engineering von CODESYS inkl. MCP Server (EU, Deutschland): verbindet Cloud- oder lokale LLMs mit dem CODESYS Development System; WAGO PLC Agent (EU) als Zusatz [4].
• Beckhoff TwinCAT Chat (EU): LLM-Chat in Visual Studio/TwinCAT 3 für Funktionsbausteine, Optimierung, Dokumentation [8].
• Rockwell FactoryTalk Design Studio Copilot: Codeerzeugung für berechtigte Projekte; Sicherheitscode ausgeschlossen [7].
• A wählen, wenn: Sie bereits auf ein Hersteller-Ökosystem standardisiert haben; Datenfluss und Support bleiben innerhalb der Bedingungen des Herstellers.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Führende Code-/Reasoning-Modelle (Claude, GPT, Gemini, Mistral/Codestral als EU-Anbieter) in EU-Regionen, gesteuert von einem Agenten, der Ihren Compiler, Simulator und Checker aufruft. Den MCP-Server der IDE nutzen, wo verfügbar.
• RAG über Handbücher, die unternehmensinterne SPS-Programmierrichtlinie (Namensgebung, PLCopen-Richtlinien) und eine freigegebene Funktionsbaustein-Bibliothek; Export/Import über PLCopen XML.
• B wählen, wenn: Umgebungen mit mehreren Herstellern oder eigene Abläufe (Spezifikationsprüfung, Testerzeugung) nötig sind.

Weg C — Selbst betreiben (Open Source)

• Code-Modelle mit offenen Gewichten (z. B. Qwen-Coder, DeepSeek-Coder, Codestral-Klasse, Granite Code), bereitgestellt über vLLM/Ollama; MATIEC (quelloffener IEC-61131-3-Compiler), nuXmv/PLCverif zur Prüfung, OpenPLC oder die CODESYS-Laufzeit zur Simulation; Forschungscode von LLM4PLC/Agents4PLC/AutoPLC als Ausgangspunkte [5][6][9].
• Anlagen mit strengen IP-Anforderungen oder abgeschotteten Engineering-Netzen verlangen dies oft. Hardware: HW3 für Code-Modelle der Klasse 30-120B; HW2 für kleine Modelle mit engen Bibliotheken. Der Betriebsaufwand ist mäßig bis hoch.

Weg D — Eigenes Training

Lohnt sich für die Genauigkeit bei Hersteller-Dialekten: ST ist in öffentlichen Trainingsdaten knapp und Dialekte unterscheiden sich, daher hilft herstellerbewusste Erzeugung im Stil von AutoPLC (Retrieval plus Feintuning auf dem eigenen kompilierbaren Code) [9]. Es braucht einige Tausend kompilierbare, geprüfte Programme mit Spezifikationen; Lizenz und geistiges Eigentum an Kundencode beachten.

Stand der Technik (2026)

• Die Copilots der Hersteller entwickelten sich vom Chat (Beckhoff 2023) zur IDE-integrierten Erzeugung (Siemens 2024) und zum MCP-basierten Agentenzugriff (CODESYS) [1][4][8].
• Die Forschung konvergierte auf erzeugen, dann verifizieren: Compiler und Model Checker in der Schleife schlagen reines Prompting [5][6]. Herstellerbewusstes Retrieval verbessert die Kompilierraten bei proprietären Dialekten; berichtete Werte schwanken je nach Benchmark und Version, daher mit Vorsicht behandeln [9].
• Grenzen und Fehlerbilder: erfundene Bibliotheksaufrufe oder nicht existierende Anweisungen; Vermischung von Dialekten; Code, der kompiliert, aber falsche Logik enthält; fehlende Berücksichtigung von Zeitverhalten, Zykluszeit und Verriegelungen; schwache Behandlung grafischer Sprachen (Kontaktplan/FBD) im Vergleich zu Text; unsichere Standardzustände bei Fehler oder Neustart; Benchmark-Erfolge bei kleinen Aufgaben lassen sich nicht auf Projekte im Anlagenmaßstab übertragen.

Gemeinsame Bausteine & Kombinationen

• Gleicher Code-LLM- und Agenten-Stack wie CODE-001/CODE-002; Testerzeugung CODE-004; Dokumentation CODE-006; Migration CODE-005; Praktiken für Embedded und sicherheitskritische Systeme CODE-020; Pipelines im Stil von Infrastructure as Code (Versionsverwaltung, CI mit Simulation) CODE-009.
• Nachgelagert oder angrenzend: ANOM-005 (Prozess-Anomalieerkennung auf denselben Anlagendaten), VIS-001 (Inspektionssysteme, die mit SPS gekoppelt sind). Ein gemeinsamer HW3-Inferenzserver kann diese bedienen.

Aufwand, Kosten & Kennzahlen

• A: Wochen bis zum Pilot (Lizenzen, IDE-Upgrade, Schulung). B/C: 3-9 Monate für eine verifizierte Pipeline inkl. Simulator-Integration. D: zusätzlich Datenkuratierung und Bewertung.
• Kostentreiber: Aufbau von Simulator und Prüfstand, Kuratierung der Bibliothek, Prüfzeit, Lizenzen.
• Kennzahlen: Quote der auf Anhieb kompilierenden Bausteine, Anteil unverändert akzeptierten erzeugten Codes, bei FAT/SAT gefundene Fehler, Engineering-Stunden je Projekt, Testabdeckung, Prüfzeit je Baustein.

Menschen & Veränderung

Einbinden: die Geschäftsleitung (Umfang und Verantwortung für die Sicherheit), die Leitung der Automatisierung als Prozessverantwortliche, die SPS-Programmierer als Anwender, IT und IT-Sicherheit (Trennung von OT und IT, keine direkte Verbindung des LLM mit laufenden Steuerungen), Recht/Compliance für Haftung, CE- und Maschinenrecht sowie Lieferanten oder Kunden, deren Code oder Spezifikationen verarbeitet werden. Eine bzw. ein Datenschutzbeauftragte(r) ist nur nötig, wenn Projekte personenbezogene Daten enthalten, was selten vorkommt.

Betriebsrat: in der Regel nein, weil das Werkzeug Maschinencode verarbeitet und nicht das Verhalten von Beschäftigten. Relevant wird es, wenn die Nutzung je Programmierer protokolliert oder zur Leistungsmessung verwendet wird (§ 87 Abs. 1 Nr. 6 BetrVG); außerdem verlangt § 90 Abs. 1 Nr. 3 die rechtzeitige Unterrichtung über KI-gestützte Arbeitsprozesse. Öffentlicher Dienst: Personalrat.

KI-Kompetenz: Programmierer mit Schulungen unterstützen, wie erzeugter IEC-61131-3-Code geprüft wird und wo die Grenzen der Modelle liegen (GUIDE-006). Sicherheitsrelevanter Code bleibt von der KI-Erzeugung ausgenommen.

Pilot und Kommunikation: mit nicht sicherheitsrelevanten Routinen wie Skalierung, Alarmbehandlung oder Dokumentation beginnen, auf einem Simulator laufen lassen und die eingesparte Zeit messen. Typische Sorgen sind die Haftung für Sicherheit und Kompetenzverlust; begegnen Sie ihnen durch verpflichtende Prüfung, Simulation und Freigabe durch eine qualifizierte Person, damit stets ein Mensch entscheidet, was auf der Maschine läuft (GUIDE-008, GUIDE-009, GUIDE-013).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Der Coding-Assistent selbst hat in der Regel ein minimales Risiko (KI-Kompetenz, Art. 4). SPS-Code bildet jedoch oft die Sicherheitsfunktion einer Maschine; KI-gestützte Entwicklung macht die Maschine nicht selbst zu einem KI-System, doch wenn KI als Sicherheitsbauteil in einem Produkt eingesetzt wird (Maschinen, Anhang I), können die Hochrisiko-Regeln greifen. Die Einstufung hängt vom Endprodukt ab, daher „depends“ [10].
• Maschinen und Sicherheit: Maschinenverordnung (EU) 2023/1230 (gilt ab Januar 2027); die Validierungspflichten nach IEC 61508 / ISO 13849 / IEC 62061 verbleiben beim Hersteller; Betreiber kritischer Infrastrukturen unterliegen NIS2- und Cyber-Resilience-Act-Pflichten für Software-Lieferkette und sichere Entwicklung [11].
• DSGVO: normalerweise keine personenbezogenen Daten; Bedienerdaten oder Schichtprotokolle in Prompts können jedoch dazu zählen.
• Cybersicherheit/IP: Steuerungslogik verrät Prozess-Know-how; nicht an nicht vertraglich gebundene APIs senden; den KI-Zugriff auf das Engineering-Netz beschränken (IEC-62443-Zonen).
• Gegenmaßnahmen: erzeugten Code als nicht vertrauenswürdige Eingabe behandeln, verpflichtendes Peer-Review, Simulation und FAT, Rückverfolgbarkeit von Anforderung über Code zu Test, Versionsverwaltung mit Herkunftsmarkierungen für KI-erzeugte Bausteine, keine KI in sicherheitsbewerteten Codepfaden.

Erste Schritte

1. Einen risikoarmen Umfang wählen: Hilfsbausteine, Alarmbehandlung, Dokumentation und Erläuterungen, kein Sicherheitscode.
2. Den Hersteller-Copilot (oder den CODESYS MCP Server) für 2-3 Ingenieure aktivieren und Zeit- und Fehlerdaten erfassen.
3. Ihre Programmierrichtlinie und Funktionsbaustein-Bibliothek als Retrieval-Material digitalisieren.
4. Einen simulationsbasierten Prüfstand aufbauen; vor dem Review Kompilierung plus Tests verlangen.
5. Eine Richtlinie festlegen: Prüfregeln, Kennzeichnung von KI-Code, Regeln zu IP und Netzwerk; eine Schulung zur KI-Kompetenz durchführen.

Quellen

1. Siemens — Engineering Copilot TIA — https://xcelerator.siemens.com/global/en/all-offerings/products/e/engineering-copilot-tia.html
2. Automation World — Schaeffler brings Siemens Industrial Copilot to its shop floor — https://automationworld.com/factory/digital-transformation/news/55235167/schaeffler-brings-siemens-industrial-copilot-to-its-shop-floor
3. Electropages — Generative AI and PLC coding — https://electropages.com/2024/09/generative-ai-and-plc-coding-automation-beyond-basics
4. CODESYS — AI-supported Engineering — https://www.codesys.com/products/engineering/ai-supported-engineering/
5. Agents4PLC (arXiv 2410.14209) — https://arxiv.org/pdf/2410.14209v1
6. LLM4PLC (arXiv 2401.05443) — https://arxiv.org/html/2401.05443v1
7. Rockwell — FactoryTalk Design Studio Copilot — https://www.rockwellautomation.com/en-ie/docs/factorytalk-design-studio/current/contents-ditamap/getting-started/factorytalk-design-studio-copilot.html
8. Beckhoff — TwinCAT Chat — https://www.beckhoff.com/en-au/company/press/twincat-chat-using-innovative-chatbot-technology-in-twincat-engineering-2023-04.html
9. AutoPLC (arXiv 2412.02410) — https://arxiv.org/html/2412.02410v2
10. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
11. Regulation (EU) 2023/1230 (Machinery Regulation) — https://eur-lex.europa.eu/eli/reg/2023/1230/oj