Fehlerbehebung bei KI-generiertem Ladder-Logic-„Workslop“ mittels Simulation

KI-generierter SPS-„Workslop“ ist syntaktisch gültige, aber betrieblich unsichere Logik, die vor jeder physischen Implementierung in einer deterministischen Simulationsumgebung getestet werden sollte. Der Simulationsmodus und das Variablen-Panel von OLLA Lab helfen Ingenieuren dabei, Scan-Zyklus-Fehler, widersprüchliche Zustandszuweisungen und Timing-Fehler sicher aufzudecken.

KI scheitert bei SPS-Aufgaben meist nicht daran, Unsinn zu produzieren. Sie scheitert oft daran, Code zu erzeugen, der plausibel aussieht, sauber kompiliert, aber schlecht reagiert, sobald Scan-Reihenfolge, E/A-Timing und Maschinenzustand eine Rolle spielen. Syntax ist billig; deterministisches Verhalten ist es nicht.

Ein aktueller interner Benchmark von Ampergon Vallis stützt diese Unterscheidung. In einem Benchmark von 500 KI-generierten Motorstarter-Sequenzen wiesen 68 % implizite Race Conditions oder Zustands-Konflikte während der simulierten Ausführung auf, am häufigsten Doppelspulen-Zuweisungen und Fehler bei Latch/Unlatch-Befehlen [Methodik: n=500 generierte Motorstarter-Aufgaben, verglichen mit einer Baseline durch erfahrene Ingenieure, evaluiert in Tests von Ampergon Vallis Lab im 1. Quartal 2026]. Diese Kennzahl stützt eine eng gefasste Aussage: KI-generierte Ladder-Logic besteht häufig den textbasierten Plausibilitätstest, versagt aber bei der Ausführung. Sie stützt keine breitere Aussage über alle SPS-Aufgaben, alle Modelle oder alle Anbieter.

KI-„Workslop“ in der industriellen Automatisierung ist syntaktisch gültige, aber betrieblich gefährliche Steuerungslogik. Das entscheidende Problem ist nicht die Formatierungsqualität. Das Problem ist, dass die Logik den Determinismus des Scan-Zyklus, das physikalische E/A-Verhalten oder die Konsistenz des Steuerungszustands nicht zuverlässig einhält.

In der SPS-Programmierung ist diese Unterscheidung entscheidend. Ein Netzwerk kann der IEC 61131-3 Ladder-Syntax entsprechen und dennoch für den Einsatz ungeeignet sein, weil es widersprüchliche Ausgänge, instabile Sequenzen oder eine Fehlerbehandlung erzeugt, die unter anormalen Bedingungen zusammenbricht. „Sieht korrekt aus“ ist kein technisches Kriterium.

Betrieblich tritt KI-Workslop meist in einigen wiederkehrenden Formen auf:

- Der „Sieht korrekt aus“-Trugschluss: Die Logik liest sich gut und verwendet bekannte Befehlsmuster, ignoriert aber Maschinenbeschränkungen, Freigaben oder ausfallsicheres Verhalten. - Zustandsmaschinen-Amnesie: Das Modell behält kein kohärentes Konzept des aktiven Maschinenzustands über mehrere Netzwerke, Übergänge und Rücksetzbedingungen hinweg bei. - Wortreiche Routenführung: Das Modell bläht einfache Verriegelungslogik auf viele Netzwerke mit redundanten Bedingungen auf, was die Überprüfung erschwert und Fehlerpfade weniger offensichtlich macht. - Widersprüchliche Zustandszuweisungen: Derselbe Ausgang oder interne Bit wird an mehreren Stellen ohne klares Eigentümer-Muster beschrieben. - Kein Entprellen oder Signalaufbereitung: Mechanische Eingänge, verrauschte Übergänge und asynchrone Rückmeldungen werden behandelt, als wären sie ideale Boolesche Werte. - Schwache Behandlung anormaler Zustände: Auslösungen, fehlende Rückmeldungen, Timeout-Bedingungen und Neustartverhalten fehlen entweder oder wurden nachträglich hinzugefügt.

Deshalb verbringen erfahrene Ingenieure zunehmend mehr Zeit mit der Überprüfung von KI-Ausgaben, als die Logik selbst im ersten Durchgang zu erstellen. Der Engpass hat sich vom Entwurf zur Prüfung verlagert.

LLMs haben Schwierigkeiten mit SPS-Scan-Zyklen, weil sie asynchrone Textvorhersagemodelle sind, während SPSen synchrone Ausführungsmaschinen sind. Ein Sprachmodell sagt das nächste Token basierend auf statistischen Mustern in Trainingsdaten voraus. Eine SPS führt Logik in einer festen Reihenfolge aus: typischerweise Eingänge lesen, Logik von oben nach unten und links nach rechts lösen, dann Ausgänge schreiben.

Dieser Unterschied ist operativ.

Ein SPS-Scan-Zyklus erzeugt ein deterministisches Überschreibverhalten. Wenn ein KI-generiertes Programm eine Ausgangsspule in einem Netzwerk aktiviert und dieselbe adressierte Spule später im Scan wieder deaktiviert, wird der Endzustand am Ausgangsbild durch die Ausführungsreihenfolge bestimmt, nicht durch das Netzwerk, das im Text plausibler aussah.

Ein kompaktes Beispiel verdeutlicht dies:

|----[ XIC Start_PB ]----[ XIO Stop_PB ]----------------( OTE Motor_Run )----|

|----[ XIC Fault_Active ]--------------------------------( OTU Motor_Run )----|

Wenn die Tag-Struktur und die Plattform-Semantik dieses Muster zulassen, mag die beabsichtigte Funktion für einen menschlichen Prüfer offensichtlich sein: Motor starten, sofern kein Stopp-Befehl vorliegt, und den Laufzustand bei Fehler löschen. Das Ausführungsverhalten kann jedoch falsch oder plattforminkonsistent sein, abhängig vom Befehlstyp, der Tag-Verwendung, den Erwartungen an Remanenz und davon, wo andere Zustandslogik in `Motor_Run` schreibt. KI vermischt oft Stile der Ausgangsverwaltung, ohne dies zu bemerken.

Die Simulation erkennt Race Conditions, indem sie die Logik zwingt, gegen sich ändernde Zustände ausgeführt zu werden, anstatt sie als statisches Textartefakt zu belassen. Eine statische Überprüfung kann einige strukturelle Fehler finden, ist aber schlecht darin, dynamische Timing-Fehler, Überschreibverhalten und Sequenzierung in Grenzfällen aufzudecken.

Hier wird OLLA Lab operativ nützlich. Sein Simulationsmodus ermöglicht es Ingenieuren, Logik auszuführen, anzuhalten, Eingänge umzuschalten und Ausgänge sowie Variablenzustände zu beobachten, ohne physische Hardware zu berühren. Das ist wichtig, weil KI-generierte Logik oft nur dann versagt, wenn sich Bedingungen in einer bestimmten Reihenfolge ändern: Startbefehl vor Rückmeldung, Rückmeldung vor Freigabe, Oszillation des analogen Schwellenwerts nahe einem Auslösepunkt oder Betätigung des Resets während eines Timeout-Zweigs.

Das Variablen-Panel dient als Diagnoseebene. Es macht Tag-Zustände, E/A-Werte, analoge Signale und Steuerungsvariablen während der Ausführung sichtbar, sodass der Ingenieur das beabsichtigte Verhalten mit den tatsächlichen Zustandsübergängen vergleichen kann.

In der praktischen Fehlerbehebung hilft die Simulation, mindestens vier häufige KI-Fehlermodi aufzudecken:

• Race Conditions
• Latch-Fehler
• Lücken in der Verriegelung
• Timing-Instabilität

Eine Umgebung mit begrenztem digitalen Zwilling stärkt diesen Workflow zusätzlich. Hier sollte die Validierung durch digitale Zwillinge operativ verstanden werden: Der Ingenieur vergleicht das Ladder-Verhalten mit einem realistischen virtuellen Anlagenmodell, um festzustellen, ob die Steuerungssequenz den erwarteten Maschinenzustand, die Fehlerreaktion und den Wiederanlaufpfad vor der Inbetriebnahme erzeugt. Es ist nicht die Behauptung, dass jedes Modell das Anlagenverhalten perfekt reproduziert.

Dieser Simulations-zuerst-Ansatz entspricht auch der Logik der funktionalen Sicherheit. Die IEC 61508 ist umfassender als das SPS-Debugging, unterstreicht aber die Notwendigkeit von Verifizierung, Validierung und Risikoreduzierung, bevor gefährliches Verhalten das Feld erreicht (IEC, 2010).

Sie sollten zuerst auf Fehler bei der Ausgangsverwaltung, fehlende Zustandsdisziplin und unrealistische E/A-Annahmen achten. Diese Fehler verursachen einen hohen Anteil an frühen Ausfällen und sind meist schneller zu erkennen als subtile Optimierungsprobleme.

Eine praktische Checkliste für den ersten Durchgang finden Sie hier:

• Doppelspulen oder Ausgänge mit mehreren Schreibern
• Gemischtes remanentes und nicht-remanentes Verhalten
• Fehlende Freigaben und Rückmeldungen
• Kein Timeout-Pfad
• Kein Entprellen oder Flankenauswertung
• Alarmlogik in Sequenzlogik integriert
• Komparator-Flattern nahe Schwellenwerten
• Unsicheres Neustartverhalten

Dies sind keine fortgeschrittenen Grenzfälle. Sie bilden die erste Ebene der technischen Überprüfung für Maschinenlogik.

Refaktorieren Sie Workslop nicht Zeile für Zeile. Reduzieren Sie ihn auf das Kern-Zustandsmodell, verifizieren Sie die Sequenz und bauen Sie dann Verriegelungen, Alarme und analoges Verhalten um diesen verifizierten Kern herum neu auf. Das Bearbeiten jedes dekorativen Netzwerks, das die KI erfunden hat, ist meist langsamer als die Wiederherstellung der Architektur.

Eine praktische Drei-Schritte-Methode funktioniert gut.

1. Isolieren Sie die Kernsequenz

Reduzieren Sie die Logik auf die minimale Menge an Zuständen und Übergängen, die für die Funktion der Maschine oder des Prozesses erforderlich sind. Für einen Motorstarter kann dies so einfach sein wie Befehl, Freigaben, Rückmeldung, Stopp und Fehlerrücksetzung.

Verwenden Sie die Simulationsumgebung von OLLA Lab, um zuerst diese reduzierte Sequenz zu testen. Wenn die Kernsequenz nicht hält, ist die umgebende Alarmlogik nur Tarnung.

Definieren Sie in diesem Stadium das operativ korrekte Verhalten in beobachtbaren Begriffen:

• welcher Eingang startet die Sequenz,
• welche Bedingungen müssen bereits wahr sein,
• welcher Ausgang sollte aktiviert werden,
• welche Rückmeldung muss zurückkehren,
• welcher Fehler sollte auftreten, wenn die Rückmeldung nicht rechtzeitig zurückkehrt,
• und welcher Rücksetzpfad ist akzeptabel.

2. Konsolidieren Sie Verriegelungen und ausfallsicheres Verhalten

Verschieben Sie verstreute Freigaben in eine klare Verriegelungsstruktur. Not-Aus-Ketten, Zustandsbedingungen, sicherheitsrelevante Sperren und Auslösebedingungen sollten nicht über unabhängige Netzwerke verteilt sein.

Ein saubereres Muster beinhaltet meist:

• ein einzelnes Bit für die Lauf-Freigabe oder einen äquivalenten Verriegelungsausdruck,
• explizite Fehler-Sammellogik,
• klare Rückmeldungs- und Timeout-Behandlung,
• und eine dokumentierte Philosophie für das Rücksetzen.

Wenn die Sequenz Sicherheitsfunktionen berührt, kann eine Schulungs- oder Validierungsumgebung Ingenieuren helfen, fehlerbewusste Logik zu proben und Verhalten zu beobachten, aber dies stellt für sich genommen keine SIL-Qualifizierung, Sicherheitsvalidierung oder Abnahme vor Ort dar.

3. Injizieren Sie analoges Rauschen und anormale Bedingungen

KI-generierte Logik verhält sich unter Nennbedingungen oft akzeptabel und versagt, sobald die Realität unordentlich wird. Deshalb ist das Testen anormaler Zustände wichtig.

Verwenden Sie analoge Werkzeuge und Variablensteuerungen, um Folgendes zu simulieren:

• Sensordrift,
• Schwellenwert-Flattern,
• verzögerte Rückmeldungen,
• ausgefallene Rückmeldesignale,
• klemmende Eingänge,
• Zustandsänderungen während des Betriebs,
• und Neustart nach Fehler.

In OLLA Lab können die analogen und PID-Lernwerkzeuge diese Art von begrenztem Testen unterstützen, indem sie analoge Werte, Komparatorverhalten und schleifenbezogene Variablen während der Ausführung sichtbar machen. Dies ermöglicht es dem Ingenieur zu sehen, ob die Steuerungslogik oszilliert, wiederholt auslöst oder auf kontrollierte Weise wieder anläuft.

Ingenieure sollten einen kompakten Beleg technischer Nachweise dokumentieren, keine Screenshot-Galerie. Der Zweck besteht darin zu zeigen, dass die Logik definiert, getestet, belastet, überarbeitet und verstanden wurde.

Verwenden Sie diese Struktur:

Spezifizieren Sie die beobachtbaren Erfolgskriterien: erforderliche Freigaben, erwartete Sequenzreihenfolge, Rückmelde-Timing, Auslöseverhalten und Rücksetzverhalten.

Geben Sie genau an, welche anormale Bedingung eingeführt wurde: ausgefallene Rückmeldung, verrauschter Füllstandsschalter, verzögerte Ventilrückmeldung, Oszillation des analogen Schwellenwerts usw.

Halten Sie die technische Erkenntnis fest: Eigentümerschaft von Ausgängen, Timeout-Disziplin, Hysterese-Anforderung, Klarheit der Sequenzzustände oder Trennung von Alarmen.

1. Systembeschreibung Definieren Sie die Maschine, den Skid oder die Prozesszelle, die gesteuert wird. Geben Sie das Steuerungsziel und die beteiligten Haupt-E/As an.
2. Operative Definition von „korrekt“
3. Ladder-Logic und simulierter Maschinenzustand Fügen Sie den relevanten Ladder-Abschnitt zusammen mit dem entsprechenden simulierten Maschinenzustand oder dem Zustand des digitalen Zwillings bei.
4. Der injizierte Fehlerfall
5. Die vorgenommene Überarbeitung Zeigen Sie, was sich in der Logik geändert hat und warum.
6. Gelernte Lektionen

Die Validierung durch digitale Zwillinge ist sicherer, da sie Fehler eindämmt und gleichzeitig die Beobachtbarkeit bewahrt. Das Testen ungeprüfter KI-generierter Logik an Live-Anlagen setzt Personal, Vermögenswerte und Prozesskontinuität einem Verhalten aus, das noch nicht unter realistischen Übergängen bewiesen wurde.

In diesem Artikel bedeutet die Validierung durch digitale Zwillinge das Validieren von Ladder-Logic gegen eine realistische virtuelle Maschine oder ein Prozessmodell, sodass der Ingenieur das erwartete Anlagenverhalten mit dem tatsächlichen Steuerungszustand vor der Inbetriebnahme vergleichen kann. Es ist nicht die Behauptung, dass das Modell jede Nuance der Anlage perfekt reproduziert.

Dies ist sowohl wirtschaftlich als auch technisch wichtig. Die Inbetriebnahmezeit ist teuer, und die Fehlerentdeckung spät im Lebenszyklus ist meist teurer als eine frühe Korrektur in einer Software-in-the-Loop-Umgebung. Dieses allgemeine Prinzip wird über Ingenieursdisziplinen hinweg weithin unterstützt, auch wenn die genauen Kostenmultiplikatoren je nach Quelle und Kontext variieren.

Der praktische Punkt ist einfacher: Wenn Sie die Logik in der Simulation sicher zum Scheitern bringen können, sollten Sie das tun.

OLLA Lab sollte als Umgebung für begrenzte Validierung und Proben verwendet werden, nicht als automatischer Korrektor für KI-generierten SPS-Code. Sein Wert liegt darin, dass es Ingenieuren ermöglicht, Ladder-Logic zu erstellen, in der Simulation auszuführen, Live-Variablen und E/As zu inspizieren und das Logikverhalten gegen realistische Szenarien und virtuelle Maschinenzustände zu vergleichen, bevor physische Anlagen berührt werden.

In diesem Workflow unterstützt OLLA Lab drei konkrete Aufgaben:

• Validierung auf Ausführungsebene
• Diagnose-Sichtbarkeit
• Szenariobasierte Proben

Diese Positionierung ist bewusst gewählt. OLLA Lab macht KI-Code nicht von Natur aus vertrauenswürdig. Es gibt Ingenieuren einen Ort, an dem sie beobachten können, wie er sicher scheitert, Kausalitäten nachverfolgen und die Logik zu einer Architektur härten können, die eher einsatzbereit ist.

- IEC 61131-3: Programmierbare Steuerungen — Teil 3 - IEC 61508 Normenfamilie für funktionale Sicherheit - NIST AI Risk Management Framework (AI RMF 1.0) - EU AI Act: regulatorischer Rahmen - ISA/IEC 62443 Überblick zur industriellen Cybersicherheit