So verhindern Sie Fehler in KI-generiertem SPS-Code durch Small Batch Delivery

Große Mengen an KI-generiertem SPS-Code neigen zum Versagen, da sich selbst geringe Fehlerraten pro Netzwerk über die sequentielle Logik hinweg summieren, während verborgene Abhängigkeiten im Scan-Zyklus die Fehlerisolierung erschweren. Small Batch Delivery reduziert dieses Risiko, indem jede Iteration auf 1 bis 3 Netzwerke begrenzt wird, gefolgt von erzwungenen Zustandsänderungen und der Verifizierung der E/A-Kausalität, bevor weitere Logik hinzugefügt wird.

KI-generierte Kontaktplan-Logik (Ladder Logic) scheitert meist nicht an ungültiger Syntax. Sie scheitert, weil die Logik über ein deterministisches Ausführungsmodell hinweg nicht verifiziert wurde – und das sind zwei verschiedene Probleme. Syntaxfehler sind sichtbar; Fehler in der Scan-Reihenfolge sind oft so „höflich“, dass sie bis zur Inbetriebnahme warten.

Während interner Benchmarks von Yaga, unserem KI-Lab-Coach, beobachteten wir einen deutlichen Effekt der Chargengröße: Nutzer, die vollständige 15-Netzwerk-Sequenzen in einem Prompt generierten, produzierten 82 % mehr nicht verifizierte Scan-Abhängigkeitsfehler als Nutzer, die in 3-Netzwerk-Schritten arbeiteten. Methodik: n=96 geführte Laborversuche zu Motorsequenzierung und Pumpenfreigabe-Aufgaben, Basis-Vergleichswert = iterative Generierung von 1–3 Netzwerken mit Simulation nach jeder Charge, Zeitfenster = Januar–März 2026. Diese Metrik stützt eine begrenzte Aussage über die Fehlerkonzentration bei geführten Laboraufgaben innerhalb der Umgebung von Ampergon Vallis. Sie erhebt keinen Anspruch auf eine branchenweite Fehlerrate für alle KI-SPS-Tools.

Der ingenieurtechnische Punkt ist simpel. Bei der SPS-Programmierung häufen KI-Großchargen verborgene Annahmen schneller an, als ein menschlicher Prüfer sie validieren kann. Small Batch Delivery ist kein „Agile für die Steuerungstechnik“. Es ist eine Disziplin zur Risikominimierung in der Steuerung.

„Batch Size Gravity“ (Chargengrößen-Gravitation) ist die Tendenz, dass KI-generierte SPS-Logik mit zunehmender Anzahl generierter Netzwerke weniger vertrauenswürdig wird, da die Wahrscheinlichkeit für mindestens einen folgenschweren Fehler mit jeder hinzugefügten Abhängigkeit steigt.

Die zugrunde liegende Mathematik entspricht der Standard-Zuverlässigkeitsrechnung. Wenn jedes generierte Netzwerk eine Wahrscheinlichkeit p hat, im Kontext funktional korrekt zu sein, dann ist die Wahrscheinlichkeit, dass n abhängige Netzwerke alle korrekt sind:

P(Erfolg) = p^n

Wenn wir ein vereinfachtes Beispiel von 95 % Korrektheit pro Netzwerk annehmen, verschlechtert sich das Ergebnis auf Chargenebene rapide:

- Einzelnes Netzwerk: 0,95 = 95,0 % - 5-Netzwerk-Charge: 0,95^5 = 77,4 % - 10-Netzwerk-Charge: 0,95^10 = 59,9 % - 20-Netzwerk-Charge: 0,95^20 = 35,8 %

Die wichtige Einschränkung lautet „funktional korrekt im Kontext“. Ein Netzwerk kann syntaktisch gültig sein und dennoch falsch, weil die Freigabe, das Selbsthalteverhalten, der Rücksetzpfad, der Analogschwellenwert oder die Sequenzannahme für den Prozess nicht korrekt sind.

Deshalb sind große KI-Code-Dumps mathematisch fragil. Selbst eine optimistische lokale Genauigkeit überlebt keine langen Abhängigkeitsketten. In der industriellen Steuerungstechnik ist eine Erfolgswahrscheinlichkeit von 35,8 % kein Produktivitätsproblem. Es ist ein Haftungsrisiko bei der Inbetriebnahme.

Die Wahrscheinlichkeitsgleichung für KI-Code-Fehler

Die Gleichung ist deshalb wichtig, weil SPS-Logik kein Haufen unabhängiger Textfragmente ist. Es ist ein interagierendes Zustandsmodell, das wiederholt in einem Scan-Zyklus ausgeführt wird.

Drei Unterscheidungen sind wichtig:

Ein Netzwerk kann isoliert betrachtet vernünftig aussehen und dennoch die Sequenz unterbrechen, sobald vorgelagerte Zustandsübergänge eintreten.

• Lokale Validität ist nicht Systemvalidität.

Wenn Netzwerk 8 voraussetzt, dass ein Bit in Netzwerk 2 gesetzt wurde, kontaminiert ein früher Fehler das spätere Verhalten.

• Abhängige Logik kumuliert schneller als unabhängige Logik.

Echte Kontaktplan-Programme enthalten gemeinsame Tags, Selbsthaltungen, Rücksetzbedingungen, Analogschwellenwerte, Zeitglieder, Zähler und Fehlerzweige. Abhängigkeiten sind nicht zurückhaltend.

• Die effektive Fehlerrate ist oft schlechter als die nominale Rate.

Ein verbreitetes Missverständnis ist, dass die Prüfzeit linear mit der Codelänge skaliert. Das ist meist nicht der Fall. Sobald die Sequenz eine bestimmte Größe überschreitet, wird die Prüfung zur Zustandsrekonstruktion.

Große KI-Prompts verursachen kumulierende Scan-Zyklus-Fehler, weil große Sprachmodelle plausible Textmuster generieren, während SPSen deterministische Logik in einer festen Reihenfolge ausführen. Das Modell sagt Code-Token voraus; die Steuerung löst Zustandsübergänge auf.

Gemäß der Programmierpraxis nach IEC 61131-3 wird Kontaktplan-Logik innerhalb einer deterministischen Scan-Struktur interpretiert: Eingänge lesen, Programmlogik ausführen, Ausgänge aktualisieren, dann wiederholen. Herstellerimplementierungen unterscheiden sich in Details, Task-Verarbeitung und Optimierungsverhalten, aber die maßgebliche technische Realität bleibt die sequentielle Ausführung mit Zustandsabhängigkeit, nicht ein simultanes semantisches Verständnis.

Diese Diskrepanz erzeugt vorhersehbare Fehlermuster, wenn zu viel Logik auf einmal generiert wird:

Ein Bit, das früher im Scan gesetzt wurde, kann später im selben Zyklus konsumiert werden. Wenn die KI die Logik in der falschen Reihenfolge platziert, kann die Sequenz ohne offensichtliche Syntaxprobleme scheitern.

• Verborgene Reihenfolgeabhängigkeit

Mehrfache Schreibzugriffe auf denselben Ausgang oder dasselbe interne Bit können zu einem „Last-Rung-Wins“-Verhalten, mehrdeutiger Absicht oder steuerungsspezifischen Überraschungen führen.

• Doppelspulen- und Überschreibverhalten

Selbsthaltelogik sieht oft korrekt aus, bis ein anormaler Zustand eintritt und das Bit nie abfällt oder zu früh abfällt.

• Defekte Selbsthalte- und Rücksetzpfade

Streng genommen sind viele SPS-Probleme keine Software-Race-Conditions im Multithreading-Sinne. Es sind Fehler in der Scan-Reihenfolge und bei Zustandsübergängen. Die Unterscheidung sollte sauber gehalten werden.

• Rennähnliches Verhalten in sequentieller Logik

KI generiert oft zuerst den „Happy Path“ und spezifiziert Nachweis-Rückmeldungen, Fehlersperren und Neustartbedingungen nur unzureichend.

• Nicht übereinstimmende Freigaben und Verriegelungen

Ein kurzer Kontrast hilft hier: Textkohärenz versus Ausführungskohärenz. KI ist auf Ersteres optimiert. Die Inbetriebnahme bestraft Letzteres.

Die Diskrepanz zwischen LLMs und sequentieller Ausführung

Die praktische Diskrepanz lässt sich am besten in einem direkten Vergleich sehen.

| Perspektive | Behandlung der Logik | Typisches Fehlermuster | |---|---|---| | LLM-Ausgabegenerierung | Ein kohärenter Block zusammenhängenden Textes aus dem Prompt-Kontext | Plausible, aber unverifizierte Annahmen über viele Netzwerke hinweg | | SPS-CPU-Ausführung | Deterministische Auswertung der Logik in Scan-Reihenfolge mit persistentem Tag-Zustand | Reihenfolgeabhängige Fehler, überschriebene Bits, unterbrochene Sequenzen | | Menschlicher Prüfer unter Zeitdruck | Visuelle Inspektion eines großen Kontaktplan-Blocks | Übersehene Abhängigkeiten bis zur Simulation oder Live-Inbetriebnahme |

Deshalb ist „es sieht richtig aus“ ein so schwaches Akzeptanzkriterium. Kontaktplan-Logik wird nicht nach literarischer Flüssigkeit beurteilt.

Small Batch Delivery verbessert die SPS-Inbetriebnahme, indem die Anzahl der unverifizierten Annahmen reduziert wird, die in jeden Testzyklus einfließen. Es verwandelt die Fehlerisolierung von Archäologie in Inspektion.

Operativ bedeutet Small Batch Delivery Folgendes: Schreiben Sie 1 bis 3 Netzwerke, erzwingen Sie eine Zustandsänderung, beobachten Sie die spezifische E/A-Kausalität in einem Simulator und bestätigen Sie den erwarteten Ausgang, bevor Sie weitere Logik hinzufügen.

Diese Definition ist wichtig, da „iteratives Bauen“ oft vage verwendet wird. Hier bezieht es sich auf ein sehr spezifisches technisches Verhalten, nicht auf eine Stimmung.

Der 3-stufige iterative Verifizierungs-Loop

Verwenden Sie diesen Loop für diskrete und gemischte diskret/analoge Logik:

Beispiel: Eine Motor-Start/Stopp-Selbsthaltung mit einem Befehlspfad und einem Ausgang.

Dieser Ansatz verbessert die Inbetriebnahme in mehreren konkreten Punkten:

• Fehler werden näher an der Änderung isoliert, die sie verursacht hat
• Annahmen zur Scan-Reihenfolge werden früher aufgedeckt
• Anormale Zustände werden gezielt getestet, statt zufällig entdeckt zu werden
• Der Prüfaufwand bleibt proportional zur Charge
• Nacharbeitskosten sinken, da weniger nachgelagerte Netzwerke von einer unbewiesenen Prämisse abhängen

Die Idee deckt sich mit angrenzender Forschung zur Softwarebereitstellung, einschließlich der wiederholten Erkenntnis von DORA, dass kleinere Änderungen im Allgemeinen einfacher zu prüfen, zu testen und wiederherzustellen sind als größere (Forsgren et al., 2018). OT ist nicht IT, und dies sollte nicht als direkter SPS-spezifischer Beweis behandelt werden. Aber das zugrunde liegende Steuerungsprinzip überträgt sich in begrenzter Weise: Kleinere validierte Änderungen reduzieren meist die Last bei der Wiederherstellung.

### Beispiel: Erst Basis-Selbsthaltung, dann Freigabeschicht

Small Batch Schritt 1: Basis-Selbsthaltungs-Verifizierung

1. Basisfunktion schreiben Erstellen Sie das minimale Verhalten, das unter idealen Bedingungen funktionieren sollte.
2. Simulieren und E/A erzwingen Schalten Sie die relevanten Eingänge, beobachten Sie den Ausgang und verifizieren Sie die Zustandsbeibehaltung, das Abfallverhalten und die Tag-Übergänge. Wenn der Basispfad sich nicht korrekt verhält, verbessert das Hinzufügen von Verriegelungen nur die Verwirrung.
3. Freigaben und Logik für anormale Zustände schichten Fügen Sie Überlastschutz, Not-Aus-Bedingungen, Nachweis-Rückmeldungen, Alarmschwellen, Timeout-Logik und Neustartbedingungen erst hinzu, nachdem die Basisfunktion bewiesen ist.

| Start | Stopp | Motor | |---|---|---| | Schließer | Öffner | Ausgangsspule |

Small Batch Schritt 2: Hinzufügen der Freigabeschicht

| Start | Stopp | Kein_Fehler | Motor | |---|---|---|---| | Schließer | Öffner | Schließer | Ausgangsspule |

Das Beispiel ist absichtlich einfach. Der Punkt ist nicht, dass Motor-Selbsthaltungen schwierig sind. Der Punkt ist, dass Ingenieure, die die Basis-Zustandsverifizierung überspringen, am Ende meist drei Probleme gleichzeitig debuggen: Befehlslogik, Freigabelogik und Annahmen über den Gerätezustand.

Small-Batch-Validierung ist in der OT wichtiger, weil Steuerungslogik physische Anlagen, Prozesszustände und Bedienerreaktionen beeinflusst, nicht nur das Anwendungsverhalten.

In einer Webanwendung kann eine schlechte Feature-Charge die Benutzererfahrung verschlechtern oder einen Rollback auslösen. In einem laufenden Prozess kann eine schlechte Steuerungs-Charge zu störenden Abschaltungen, verborgenen Neustartpfaden, trockenlaufenden Pumpen, oszillierenden Ventilen oder irreführenden HMI-Zuständen führen. Der Prozess ist nicht dazu verpflichtet, nachsichtig zu sein.

Drei OT-spezifische Faktoren erhöhen den Einsatz:

Von SPSen wird erwartet, dass sie sich über wiederholte Scans und bekannte Zustandsübergänge hinweg vorhersehbar verhalten.

• Determinismus ist wichtig

Gute Steuerungslogik muss definieren, was bei Fehlern passiert, nicht nur im Normalbetrieb.

• Anormale Zustände sind Teil des Designraums

Jeder vermeidbare Debug-Zyklus vor Ort verbraucht Arbeitszeit, Zeitplan und Vertrauen.

• Inbetriebnahmefenster sind teuer

Dies ist auch der Punkt, an dem Simulation-Ready eine korrekte Definition benötigt. Ein Simulation-Ready-Ingenieur ist nicht jemand, der nur die Kontaktplan-Syntax kennt. Es ist ein Ingenieur, der Steuerungslogik beweisen, beobachten, diagnostizieren und gegen realistisches Prozessverhalten härten kann, bevor sie einen Live-Prozess erreicht.

Das ist die nützliche Unterscheidung: Syntax versus Einsatzfähigkeit.

OLLA Lab lehrt das iterative Aufbauen von Kontaktplan-Logik, indem es Lernenden eine begrenzte Umgebung bietet, in der sie Logik schreiben, Verhalten simulieren, E/As inspizieren und den Kontaktplan-Zustand gegen den virtuellen Gerätezustand vergleichen können, bevor ein Live-Einsatz stattfindet.

Hier wird das Produkt operativ nützlich. Der Wert liegt nicht darin, dass es das ingenieurtechnische Urteilsvermögen ersetzt. Der Wert liegt darin, dass es Ingenieuren einen Ort gibt, um Urteilsvermögen an Aufgaben zu üben, die zu riskant, zu teuer oder zu unpraktisch sind, um sie an echter Anlagenhardware zu üben.

Geführte Workflows für risikobegrenztes Üben

Der Workflow von OLLA Lab unterstützt die Small-Batch-Disziplin durch mehrere verknüpfte Verhaltensweisen:

Lernende bauen Netzwerke direkt im Browser unter Verwendung von Kontakten, Spulen, Zeitgliedern, Zählern, Komparatoren, Mathe-Funktionen, logischen Operationen und PID-Anweisungen.

• Webbasierter Kontaktplan-Editor

Nutzer können Logik ausführen, stoppen, Eingänge schalten und Ausgänge sowie Variablenzustände ohne physische Hardware beobachten.

• Simulationsmodus

Tag-Werte, Eingänge, Ausgänge, Analog-Tools, PID-Dashboards und Szenario-Variablen bleiben während des Tests sichtbar, was die Kausalität leichter nachvollziehbar macht.

• Variablen-Panel und E/A-Sichtbarkeit

Die Plattform strukturiert den Fortschritt von den Grundlagen des ersten Netzwerks bis zu fortgeschritteneren Funktionen, anstatt Nutzer in einen leeren Editor zu werfen und auf Disziplin zu hoffen.

• Geführter Workflow zum Erlernen von Kontaktplänen

Diese Umgebungen lassen Nutzer Steuerungslogik gegen Anlagenverhalten in realistischen Maschinenkontexten vergleichen.

• 3D-, WebXR- und VR-Simulationen, die mit digitalen Zwillingen verknüpft sind

Voreinstellungen aus Fertigung, Wasser, Abwasser, HLK, Chemie, Pharma, Lagerhaltung, Lebensmittel und Versorgungsunternehmen konfrontieren Lernende mit verschiedenen Verriegelungen, Gefahren und Steuerungsphilosophien.

• Szenariobasiertes Inbetriebnahme-Training

Begrenzte Produktbehauptung: OLLA Lab ist eine Validierungs- und Übungsumgebung für risikoreiche Inbetriebnahmetätigkeiten. Es ist keine Zertifizierung, kein SIL-Anspruch und kein Ersatz für beaufsichtigte Kompetenz vor Ort.

Was „Validierung durch digitalen Zwilling“ hier bedeutet

Validierung durch digitalen Zwilling sollte nicht als Prestige-Vokabular behandelt werden. In diesem Kontext bedeutet es: Testen der Kontaktplan-Logik gegen ein realistisches virtuelles Anlagenmodell und Überprüfung, ob befohlene Zustände, Rückmeldungen, Verriegelungen, Alarme und Sequenzübergänge wie beabsichtigt funktionieren, bevor die Bereitstellung erfolgt.

Dazu gehören beobachtbare ingenieurtechnische Verhaltensweisen wie:

• Vergleich des befohlenen Motorzustands mit der simulierten Anlagenreaktion,
• Testen des Verlusts von Nachweis-Rückmeldungen,
• Beobachten von Alarmschwellen und Abschaltverhalten,
• Validieren des Sequenzfortschritts,
• Prüfen, ob ein Neustartpfad unter definierten Bedingungen blockiert oder erlaubt ist.

Ein digitaler Zwilling, der keine Zustandsdiskrepanzen aufdecken kann, ist meist nur Kulisse.

Ingenieure sollten KI-gestützte SPS-Entwicklung praktizieren, indem sie KI als Entwurfsgenerator innerhalb eines Verifizierungs-Loops behandeln, nicht als Autorität für Prozesswahrheit.

Der sichere Workflow ist diszipliniert und ziemlich einfach:

• Eine kleine Logikeinheit generieren
• Tag-Namen, Zustandsannahmen und Ausgangsschreibzugriffe prüfen
• Die Einheit simulieren
• Normale und anormale Eingänge erzwingen
• Ausgangskausalität bestätigen
• Erst dann die Sequenz erweitern

Dies ist auch der richtige Ort, um explizit über KI-Unterstützung zu sprechen. Yaga, der KI-Lab-Guide von OLLA Lab, kann Nutzer bei der Einarbeitung, mit korrigierenden Vorschlägen und Anleitungen zur Kontaktplan-Logik unterstützen. Er sollte genutzt werden, um Lernhürden zu reduzieren, nicht um die Verifizierung zu umgehen. Die Entwurfserstellung ist nützlich. Das deterministische Veto bleibt die Aufgabe des Ingenieurs.

Ein praktisches Beweispaket schlägt eine Screenshot-Galerie

Wenn ein Ingenieur Kompetenz in KI-gestützter Steuerungstechnik demonstrieren möchte, ist das richtige Artefakt ein kompakter Körper an technischen Beweisen, kein Ordner mit polierten Screenshots.

Verwenden Sie diese Struktur:

1. Systembeschreibung Definieren Sie die Prozesseinheit, die Anlage, die E/As und das Steuerungsziel.
2. Operative Definition von „korrekt“ Geben Sie genau an, was erfolgreiches Verhalten unter normalen und anormalen Bedingungen bedeutet.
3. Kontaktplan-Logik und simulierter Anlagenzustand Zeigen Sie die implementierte Logik neben dem beobachteten Maschinen- oder Prozesszustand.
4. Der injizierte Fehlerfall Führen Sie gezielt einen realistischen Fehler ein, wie z. B. Nachweisverlust, Überlast, falscher Analogwert oder Sequenz-Timeout.
5. Die vorgenommene Revision Dokumentieren Sie die Logikänderung, die verwendet wurde, um das Verhalten zu korrigieren oder zu härten.
6. Gelernte Lektionen Erklären Sie, was der Fehler über Annahmen, Scan-Reihenfolge, Freigaben oder Bedienerinteraktion offenbart hat.

Diese Struktur ist weitaus informativer als „hier ist mein Kontaktplan-Diagramm“. Der meiste echte ingenieurtechnische Wert entsteht, wenn die erste Annahme scheitert.

Das Argument für kleine Chargen stützt sich auf drei Stützpfeiler: etablierte Wahrscheinlichkeitsmathematik, deterministische SPS-Ausführungspraxis und breitere Belege dafür, dass kleinere validierte Änderungen die Wiederherstellbarkeit verbessern.

Relevante Ankerpunkte sind:

• IEC 61131-3 für die Struktur der Programmiersprachen von speicherprogrammierbaren Steuerungen und den Ausführungskontext in der industriellen Automatisierungspraxis.
• IEC 61508 für die breitere Disziplin der funktionalen Sicherheit, einschließlich der Bedeutung von Verifizierung, Validierung und systematischer Fehlerbeherrschung.
• exida-Leitfäden und Literatur zum Sicherheitslebenszyklus für den praktischen Umgang mit systematischen Fehlern, Verifizierungsstrenge und Qualität von Steuerungssystemen.
• DORA-Forschung für die begrenzte, aber nützliche angrenzende Erkenntnis, dass kleinere Änderungen im Allgemeinen die Bereitstellungsstabilität und Wiederherstellungsleistung verbessern.
• Literatur zu digitalen Zwillingen und Simulation im Ingenieurwesen und in der Steuerungstechnik, die den Wert virtueller Inbetriebnahme, szenariobasierter Validierung und immersiver Trainingsumgebungen aufzeigt.

Die Übertragung von Forschung zur Softwarebereitstellung auf die OT sollte vorsichtig erfolgen. DORA beweist kein SPS-spezifisches Theorem. Es stützt eine begrenzte Schlussfolgerung: Wenn Änderungen kleiner sind und früher validiert werden, verbessern sich Prüfung und Wiederherstellung meist. Die OT fügt dann deterministische Ausführung und physische Prozesskonsequenzen hinzu, was den Fall strenger, nicht schwächer macht.

Die praktische Regel ist einfach: Wenn Sie den Zustandsübergang nicht erklären und die E/A-Kausalität für die aktuelle Charge nicht beweisen können, ist die Charge bereits zu groß.

Große KI-generierte SPS-Programme sind nicht gefährlich, weil KI einzigartig mysteriös ist. Sie sind gefährlich, weil deterministische Steuerungssysteme verborgene Annahmen bestrafen und große Chargen viele davon auf einmal verbergen.

Small Batch Delivery ist die sicherere Methode, weil sie damit übereinstimmt, wie SPSen tatsächlich funktionieren, wie sich Fehler tatsächlich ausbreiten und wie Inbetriebnahmeteams tatsächlich debuggen. Generieren Sie weniger, verifizieren Sie mehr und lassen Sie jede Annahme im Scan-Zyklus ihren Platz verdienen.

- IEC 61131-3: Speicherprogrammierbare Steuerungen — Teil 3: Programmiersprachen - IEC 61508 Übersicht (funktionale Sicherheit) - NIST AI Risk Management Framework (AI RMF 1.0) - Digital Twin in Manufacturing: A Categorical Literature Review and Classification (IFAC, DOI) - Digital Twin in Industry: State-of-the-Art (IEEE, DOI)

Dieses Dokument wurde vom OLLA Lab Engineering-Team erstellt, um Best Practices für die Integration von KI in industrielle Steuerungssysteme zu definieren.

Die in diesem Artikel genannten Benchmarks basieren auf internen Laborversuchen von Yaga (Januar–März 2026) und dienen der Veranschaulichung von Fehlermustern bei der SPS-Programmierung. Sie stellen keine allgemeingültige wissenschaftliche Studie dar.