Warum scheitern LLMs an Kontaktplan-Logik? Der grafische Vorteil in OLLA Lab

Große Sprachmodelle (LLMs) haben Schwierigkeiten mit Kontaktplan-Logik (Ladder Logic), da sie eindimensionalen Text vorhersagen, während Kontaktpläne (LD) und Ablaufsprachen (SFC) von zweidimensionalen räumlichen Beziehungen, paralleler Ausführung und der Reihenfolge des Scan-Zyklus abhängen. OLLA Lab bietet eine visuelle Simulationsumgebung, in der Ingenieure den Leistungsfluss, das E/A-Verhalten und Timing-Fehler validieren können, bevor die Logik einen realen Prozess erreicht.

KI scheitert bei Kontaktplan-Logik nicht primär deshalb, weil die Syntax unklar wäre. Sie scheitert, weil SPS-Steuerung nicht nur aus Syntax besteht; es ist eine räumliche Ausführung unter deterministischem Scan-Timing. Diese Unterscheidung ist wichtiger, als die meisten Ratschläge zum Prompt-Engineering vermuten lassen.

Während eines internen Benchmarks von 50 KI-generierten Motorsteuerkreisen, die in die Simulations-Engine von OLLA Lab importiert wurden, scheiterten 68 % der KI-vorgeschlagenen Sequenzen bereits im ersten virtuellen Scan-Zyklus – hauptsächlich aufgrund von Fehlern in der Netzwerkreihenfolge und Zustandsabhängigkeit, nicht aufgrund von Syntaxfehlern. Methodik: Stichprobengröße = 50 generierte Motorsteuerungsaufgaben; Aufgabenstellung = Import und Simulation von KI-generierten Start/Stopp-, Selbsthalte-, Freigabe- und Fehler-Reset-Mustern; Vergleichsbasis = manuell geprüfte Referenzimplementierungen, die vom Engineering-Review von Ampergon Vallis akzeptiert wurden; Zeitfenster = Q1 2026. Diese Metrik stützt eine spezifische Erkenntnis: KI-generierte Kontaktplan-Logik bricht oft zur Laufzeit zusammen, selbst wenn sie strukturell plausibel erscheint. Sie stützt nicht die allgemeine Behauptung, dass jegliche KI-generierte SPS-Logik unbrauchbar sei.

Das ist das eigentliche Problem: Textplausibilität versus einsatzfähiges Steuerungsverhalten. SPS bewerten keine Aufsätze.

Kontaktplan-Logik ist für LLMs schwierig, da das Modell serialisierten Text vorhersagt, während der Kontaktplan die Steuerungsabsicht durch eine zweidimensionale Topologie darstellt. Die Diskrepanz ist architektonisch, nicht kosmetisch.

IEC 61131-3 definiert den Kontaktplan (LD) und die Ablaufsprache (SFC) als grafische Sprachen, die verwendet werden, um Steuerungsbeziehungen auszudrücken, die visuell leichter nachvollziehbar sind als durch reinen Fließtext (IEC, 2013). Im LD sind die Zweigstruktur, der Leistungsfluss, die Netzwerkreihenfolge und parallele Bedingungen Teil der Bedeutung. In der SFC sind Divergenz, Konvergenz, aktive Schritte und die Zuständigkeit für Übergänge ebenfalls Teil der Bedeutung. Wenn diese Struktur in XML, JSON oder Prompt-Text abgeflacht wird, geht ein Teil des Ausführungskontexts leicht verloren oder wird falsch verknüpft.

Die Lücke zwischen 1D- und 2D-Ausführung

Serialisieren die Absicht primär in einer linearen Reihenfolge. Selbst wenn sie Verzweigungen oder Nebenläufigkeit ausdrücken, bleibt die Darstellung token-sequenziell und explizit.

• Textsprachen wie Python oder C

Kodiert Logik als ein Netzwerk im elektrischen Stil mit Leistungsfluss von links nach rechts und Auswertung von oben nach unten. Parallele Zweige sind nicht dekorativ; sie definieren Ausführungsbeziehungen.

• Kontaktplan (LD)

Kodiert den Zustandsfortschritt räumlich. Divergenz und Konvergenz zeigen gleichzeitige oder alternative Pfade an, die schwerer zu bewahren sind, wenn sie auf einfache Textstrukturen reduziert werden.

• Ablaufsprache (SFC)

Sagen wahrscheinliche nächste Token basierend auf Trainingsmustern voraus. Sie können Kontaktplan-Notation imitieren, aber Imitation ist nicht dasselbe wie die Aufrechterhaltung topologischer Invarianten über einen Steuerungs-Graphen hinweg.

• LLMs

Die Forschung zum logischen Schlussfolgern von LLMs hat wiederholt gezeigt, dass die Token-Vorhersage die räumliche oder topologische Struktur nicht zuverlässig bewahrt, insbesondere wenn die Aufgabe eine konsistente Abbildung über nicht-lineare Darstellungen hinweg erfordert (Bubeck et al., 2023; Bang et al., 2023). Die Details variieren je nach Benchmark, aber die Richtung ist stabil: Sequenzmodelle sind besser in der plausiblen Fortführung als in der deterministischen räumlichen Buchführung.

Eine nützliche Korrektur lautet: Kontaktplan-Logik ist nicht „einfach für KI, weil sie simpel ist“. Sie ist für KI oft gerade deshalb schwer, weil sie grafisch, zustandsbehaftet und an den Scan-Zyklus gebunden ist. Einfachheit auf dem Bildschirm kann schwieriges Timing darunter verbergen.

Was bedeutet „visuelle Logik beherrschen“ tatsächlich?

Visuelle Logik zu beherrschen bedeutet nicht, einen Kontakt und eine Spule in der richtigen Reihenfolge zu platzieren. Es bedeutet, beweisen zu können, wie der Leistungsfluss durch ein Programm mit mehreren Netzwerken unter der Ausführung des Scan-Zyklus fließt, einschließlich abnormaler Zustände.

Operativ bedeutet das, dass ein Ingenieur:

• den Leistungsfluss von links nach rechts durch verschachtelte Zweige verfolgen kann,
• Abhängigkeiten von Netzwerken von oben nach unten erklären kann,
• identifizieren kann, wo eine Freigabe ausgewertet wird, bevor sie aktualisiert wurde,
• zwischen gespeichertem Zustand und transientem Zustand unterscheiden kann,
• Fehler-, Auslöse- und Reset-Verhalten testen kann,
• den Kontaktplan-Zustand mit dem simulierten Anlagenzustand vergleichen kann,
• Logik nach der Beobachtung einer fehlerhaften Sequenz überarbeiten kann.

Das ist es, was Ampergon Vallis unter Simulation-Ready versteht: ein Ingenieur, der Steuerungslogik gegenüber realistischem Prozessverhalten beweisen, beobachten, diagnostizieren und absichern kann, bevor sie einen realen Prozess erreicht. Keine Syntax-Gewandtheit. Kein Lebenslauf-Theater. Beweise.

KI-generierte Kontaktplan-Logik scheitert oft, weil SPS in einem deterministischen Scan-Zyklus arbeiten und viele generierte Sequenzen diese Ausführungsreihenfolge ignorieren. Ein Netzwerk, das isoliert betrachtet vernünftig aussieht, kann dennoch scheitern, wenn die Steuerung Eingänge liest, Logik löst und Ausgänge nacheinander schreibt.

Der Standard-Scan-Zyklus umfasst: Eingänge lesen, Logik ausführen, Ausgänge aktualisieren. Dieser Zyklus mag in Millisekunden ablaufen, aber das Timing ist real genug, um Race Conditions, das Lesen veralteter Zustände und falsche Freigaben zu erzeugen, wenn die Logik schlecht geordnet ist.

Der „sieht korrekt aus“-Trugschluss

Der häufigste KI-Fehler ist keine ungültige Syntax. Es ist gültig aussehende Logik mit ungültigem Ausführungsverhalten.

Beispiele hierfür sind:

- Umgekehrte Netzwerkreihenfolge: Ein Freigabebit wird in Netzwerk 2 geprüft, aber die Logik, die es setzt, wird erst in Netzwerk 5 ausgeführt. - Vorzeitige Ausgangsabhängigkeit: Ein Zweig liest einen Ausgangszustand, als wäre er bereits aktualisiert, obwohl das relevante Netzwerk in diesem Scan noch nicht gelöst wurde. - Defekte Selbsthaltelogik: Das generierte Muster ähnelt einem Standard-Motorstarter, behält den Zustand jedoch nicht korrekt bei, wenn ein Stopp- oder Fehlerübergang auftritt. - Unsachgemäße Reset-Sequenzierung: Die Fehler-Reset-Logik löscht eine Auslösung, bevor die Nachweisbedingungen erneut validiert wurden.

Hier wird die visuelle Validierung operativ nützlich. Sie müssen den aktiven Pfad sehen, den Eingang umschalten, das Tag prüfen und zusehen, wie die Sequenz der Reihe nach scheitert.

KI hat Schwierigkeiten mit SFC, da SFC eine visuelle Zustandsmaschine ist, deren Bedeutung von der Zweigzugehörigkeit, der gleichzeitigen Schrittaktivierung und der Übergangsdisziplin abhängt. Flacht man das Diagramm unvorsichtig ab, wird die Maschinenlogik mehrdeutig.

SFC ist für LLMs oft schwieriger als einfache Kontaktpläne, da das Modell Folgendes bewahren muss: welche Schritte gleichzeitig aktiv sind, welcher Übergang zu welchem Zweig gehört, wo die Divergenz beginnt und wo die Konvergenz legal aufgelöst wird.

Grafische Darstellung ist wichtig, weil Korrektheit der Steuerung nicht nur logische Korrektheit bedeutet. Es ist auch die Korrektheit der beobachtbaren Sequenz unter realistischem Anlagenverhalten. In der industriellen Automatisierung lautet die Frage selten nur: „Kompiliert das Netzwerk?“ Die eigentliche Frage ist, ob die Pumpe nur bei Freigabe startet, ob die Rückmeldung innerhalb der Zeit erfolgt und ob das System sicher in einen Ausfallsicherheitszustand übergeht.

Simulation und auf digitalen Zwillingen basierende Validierung werden hier zunehmend relevant, da sie es Ingenieuren ermöglichen, das Verhalten vor der Standort-Exposition zu testen.

OLLA Lab überbrückt die KI-Lücke, indem es Ingenieuren eine begrenzte visuelle Umgebung bietet, um Steuerungslogik zu erstellen, zu simulieren, zu inspizieren und zu überarbeiten, bevor sie physische Geräte berührt.

Was OLLA Lab in diesem Workflow leistet

Im Rahmen des Produkts bietet OLLA Lab:

• einen webbasierten Kontaktplan-Editor,
• einen Simulationsmodus zum sicheren Ausführen von Logik,
• ein Variablen-Panel zur Überwachung von E/A-Zuständen,
• 3D/WebXR/VR-Anlagenansichten,
• szenariobasierte Labs, die Kontaktplan-Logik mit realistischem Prozessverhalten verbinden.

Richtig eingesetzt, unterstützt dies einen disziplinierten Workflow: KI-Vorschlag als Entwurf nehmen, in OLLA Lab nachbauen, Sequenz definieren, Eingänge umschalten, Fehler injizieren und Logik überarbeiten.

Ingenieure sollten KI-generierte Kontaktplan-Logik validieren, als wäre sie ein nicht vertrauenswürdiger Entwurf eines Junior-Mitarbeiters: nützlich zur Beschleunigung, unsicher als letzte Autorität und erst nach deterministischer Prüfung akzeptabel.

1. Definieren Sie die Steuerungsabsicht: Start-, Stopp-, Freigabe- und Fehlerregeln. 2. Prüfen Sie die Ausführungsreihenfolge: Netzwerkreihenfolge und Zustandsabhängigkeiten. 3. Simulieren Sie nominale und abnormale Fälle: Testen Sie Fehler und Sensordiskrepanzen.

1. Vergleichen Sie den Steuerungszustand mit dem Anlagenzustand.
2. Überarbeiten und erneut testen.

Ein glaubwürdiger Korpus an Engineering-Beweisen ist keine Screenshot-Galerie. Es ist ein kompakter Datensatz, der zeigt, dass der Ingenieur Korrektheit definiert, Fehler getestet, die Logik überarbeitet und etwas Spezifisches gelernt hat.

- Systembeschreibung: Was soll das System tun? - Operative Definition: Erfolgskriterien. - Logik und Anlagenzustand: Kontaktplan und simuliertes Verhalten. - Fehlerfall: Gezielte Injektion einer abnormalen Bedingung. - Überarbeitung: Dokumentation der Logikänderung. - Gelernte Lektionen: Was hat der Fehler gelehrt?

KI kann dennoch für die SPS-Programmierung nützlich sein, aber hauptsächlich als Entwurfs- und Unterstützungsebene und nicht als Ausführungsautorität. Sie ist gut in der Mustererinnerung, Boilerplate-Generierung, Erklärung und Übersetzungsunterstützung. Sie ist schwächer darin, deterministisches Verhalten über grafische Steuerungssemantiken hinweg zu bewahren.

Die aktuellen Beweise stützen eine enge, aber wichtige Schlussfolgerung: LLMs haben Schwierigkeiten mit Kontaktplan-Logik und SFC nicht deshalb, weil industrielle Steuerung zu nischenhaft wäre, um sie zu beschreiben, sondern weil diese Sprachen Bedeutung durch räumliche Struktur, parallele Beziehungen und Scan-Zyklus-Ausführung kodieren, die durch eindimensionale Token-Vorhersage nicht natürlich bewahrt werden.

Syntax ist billig. Determinismus ist der teure Teil.

Das Team von OLLA Lab und Ampergon Vallis Lab besteht aus Ingenieuren und Automatisierungsexperten, die sich auf die Validierung von Steuerungslogik und die Entwicklung von Simulationsumgebungen für die industrielle Automatisierung spezialisiert haben.

Dieser Artikel wurde durch interne Benchmarks von Ampergon Vallis (Q1 2026) und durch den Vergleich mit IEC 61131-3 Standards sowie gängigen Praktiken der funktionalen Sicherheit (IEC 61508) validiert.

- IEC 61131-3: Programmierbare Steuerungen — Teil 3: Programmiersprachen - IEC 61508 Familie der funktionalen Sicherheitsnormen - NIST AI Risk Management Framework (AI RMF 1.0) - EU Industrie 5.0 Politik-Hintergrund - Digitaler Zwilling Überblick (NIST)