Fehlersuche in der Kontaktplan-Logik mit einem KI-Assistenten: Lernen Sie Yaga im OLLA Lab kennen

Eine effektive Fehlersuche in der Kontaktplan-Logik (Ladder Logic) erfordert mehr als nur Hilfe bei der Syntax. Yaga, der KI-Labor-Coach im OLLA Lab, fungiert als begrenzter Assistent, der an den Projektstatus, das Simulationsverhalten und den E/A-Kontext gebunden ist. Er hilft Ingenieuren dabei, Logikfehler zu diagnostizieren, Strukturen nach IEC 61131-3 zu erläutern und Korrektur-Workflows vor der Live-Inbetriebnahme zu erproben.

Kontaktplan-Logik scheitert meist aus Gründen, die eher physikalischer als grammatikalischer Natur sind. Ein Netzwerk (Rung) kann korrekt aussehen und dennoch ein falsches Maschinenverhalten erzeugen, weil das eigentliche Problem in der Zyklusreihenfolge, der Tag-Zuordnung, der Ablaufsteuerung, dem Timing oder einer falschen Annahme über den Anlagenzustand liegt.

Genau hier bleiben Nachwuchsingenieure oft stecken. Sie können zwar Kontakte und Spulen platzieren, aber sie können noch nicht erklären, warum eine Sequenz blockiert, warum ein Ausgang nicht schaltet oder warum eine Freigabebedingung einen Zyklus zu spät zurückgesetzt wird. Die Syntax ist selten das langfristige Problem; die Einsatzfähigkeit ist es.

Während der Betatests von OLLA Lab lösten Lernende, die Yaga zur Diagnose von Divergenzen zwischen „Latch“- und „Seal-in“-Zuständen nutzten, die zugewiesenen Szenario-Fehler 63 % schneller als Lernende, die nur statische Dokumentationen verwendeten [Methodik: n=38 Lernende; Aufgabe=Fehlersuche bei vorab implementierten Motorsteuerungs- und Pumpensequenzfehlern in der Simulation; Basisvergleich=OEM-PDF-Anleitungen und Tag-Listen ohne KI-Unterstützung; Zeitfenster=8-wöchige Beta-Phase, Q1 2026]. Dieser interne Benchmark stützt eine eng gefasste Aussage: Begrenztes KI-Coaching kann die Zeit bis zur Diagnose innerhalb eines simulierten Labor-Workflows verkürzen. Er beweist weder die Kompetenz vor Ort, noch die Einsatzbereitschaft an Live-Anlagen oder breitere Auswirkungen auf den Arbeitsmarkt.

Nachwuchsingenieure bleiben stecken, weil Kontaktplan-Logik nicht nur ein Notationssystem ist. Es ist ein Verhaltenssystem, das in Scan-Zyklen gegen reale oder simulierte Prozesszustände ausgeführt wird, wobei die Konsequenzen durch Timing, Verriegelungen, Rückmeldungen und Fehlermodi bestimmt werden.

Ein weit verbreitetes Missverständnis ist, dass die SPS-Fehlersuche hauptsächlich darin besteht, „das falsche Netzwerk zu finden“. In der Praxis liegt der Fehler oft in der Beziehung zwischen Netzwerken, Tags und Sequenzannahmen. Ein Motorstartbefehl kann korrekt angesteuert werden, aber die Sequenz schlägt dennoch fehl, weil der Rückmeldeeingang nicht schaltet, der Stopp-Pfad später im Scan überschrieben wird oder das Zustandsmodell von Anfang an nicht konsistent war. Das Diagramm ist sauber. Die Maschine bleibt unbeeindruckt.

Diese Lücke lässt sich am besten als Verlust der Steuerungsinтуиtion beschreiben. Ingenieure kennen den Befehlssatz, aber sie können noch nicht flüssig über Folgendes nachdenken:

• Scan-Reihenfolge und überschriebene Ausgänge,
• Verhalten von Selbsthaltung (Seal-in) versus Latch,
• Freigabebedingungen (Permissives) versus Abschaltbedingungen (Trips),
• Rückmeldung des Betriebszustands (Proof-of-run),
• Behandlung abnormaler Zustände,
• Analogschwellenwerte und Entprellzeiten,
• Sequenzfortschritt unter unvollständigen Feldbedingungen.

Die Forschung zu industrieller Ausbildung und cyber-physischen Systemen legt nahe, dass die Lernqualität eher von kontextreichem Feedback als von isolierter Code-Betrachtung abhängt. In OT-Umgebungen entsteht die kognitive Belastung durch das Wechseln zwischen Logik, Prozessbeschreibung, E/A-Zustand, Alarmen und Anlagenverhalten und nicht allein durch das Erkennen von Symbolen (Aivaliotis et al., 2019; Mourtzis et al., 2021).

Dies ist auch der Grund, warum „Simulation-Ready“ eine strikte Definition benötigt. In diesem Artikel bedeutet Simulation-Ready, dass ein Ingenieur die Steuerungslogik gegen ein realistisches Prozessverhalten beweisen, beobachten, diagnostizieren und absichern kann, bevor sie einen Live-Prozess erreicht. Das ist eine höhere Messlatte als das Auswendiglernen eines Netzwerks, und eine nützlichere dazu.

Yaga bietet kontextbezogene Korrekturen, indem er innerhalb der begrenzten Umgebung von OLLA Lab arbeitet und nicht als frei agierender Textgenerator. Er soll Benutzern helfen, die von ihnen erstellte Logik, die zugeordneten Variablen und das ausgelöste Simulationsverhalten zu überprüfen.

Dieser Unterschied ist wichtig. Ein allgemeiner Chatbot kann Kontaktplan-Muster beschreiben, aber er weiß nicht von Natur aus, was Ihre Tags tun, welches Szenario geladen ist oder ob der simulierte Anlagenzustand von der beabsichtigten Steuerungsbeschreibung abweicht. In der Steuerungstechnik ist fehlender Kontext kein kleiner Fehler. Er ist meistens der Fehler selbst.

Innerhalb von OLLA Lab fungiert Yaga als KI-Labor-Coach, der drei beobachtbare Ingenieursverhaltensweisen unterstützt:

• Nachverfolgung von E/A-Kausalitäten,
• Identifizierung von strukturellen oder Zuordnungs-Inkonsistenzen,
• Vergleich der beabsichtigten Sequenzlogik mit dem tatsächlichen Simulationszustand.

Yagas dreistufiger Diagnose-Workflow

Yaga kann Benutzern helfen, nicht zugeordnete E/As, inkonsistente Tag-Verwendung und wahrscheinliche Datentyp-Fehlanpassungen im Projektkontext zu identifizieren, die über den Editor und den Variablen-Workflow sichtbar sind. Dies ist die erste Ebene, da viele „Logikfehler“ eigentlich Bindungsfehler im Logik-Gewand sind.

• Syntax- und Tag-Validierung

Yaga kann Benutzer auf strukturelle Muster hinweisen, die bei der SPS-Ausführung häufig fehlschlagen, wie z. B. Doppelspulen-Bedingungen, widersprüchliche Ausgangsschreibvorgänge, unterbrochene Selbsthaltepfade oder Sequenzlogik, die von unmöglichen Zustandsübergängen abhängt.

• Scan-Zyklus- und Strukturanalyse

Yaga kann dabei helfen, ein prozessorientiertes Ziel in natürlicher Sprache in ein erstes Kontaktplan-Gerüst umzuwandeln, das der Benutzer prüfen, verfeinern und testen kann. Das wichtige Wort ist „erstes“. Es ist eine Coaching-Hilfe, keine Sicherheitsinstanz.

• Übersetzung der Steuerungsphilosophie

Hier wird OLLA Lab operativ nützlich. Der Kontaktplan-Editor, der Simulationsmodus, das Variablen-Panel und das Szenario-Framework geben Yaga einen begrenzten Raum für das Coaching. Anstatt abstrakt zu antworten, kann er einen Workflow unterstützen, bei dem der Benutzer Logik schreibt, die Simulation ausführt, Eingänge umschaltet, Ausgänge beobachtet und das Programm anhand des sichtbaren Maschinenverhaltens überarbeitet.

Begrenzte KI bedeutet, dass der Assistent durch die bekannte Umgebung, die verfügbaren Projektdaten und den spezifischen Trainings-Workflow eingeschränkt ist, anstatt aufgefordert zu werden, gegen einen nicht verifizierten industriellen Kontext zu improvisieren.

In OLLA Lab umfasst dieser begrenzte Kontext das Kontaktplan-Projekt des Benutzers, den Simulationszustand, die Sichtbarkeit von Variablen und E/As sowie die szenariospezifische Struktur. Der Artikel bezieht sich auf JSON-serialisierte Projektdaten; das ist wichtig, weil der serialisierte Projektzustand eine maschinenlesbare Darstellung des Steuerungsmodells und des Arbeitsergebnisses des Benutzers schafft. Einfach ausgedrückt: Der Assistent rät nicht anhand eines Screenshots und einer vagen Eingabeaufforderung.

Operativ sollte ein begrenzter Automatisierungs-Coach Folgendes tun:

• aus dem aktuellen Projektzustand schlussfolgern statt aus generischen Beispielen,
• Empfehlungen an beobachtbare Tags, Anweisungen und Szenarioverhalten binden,
• die Validierung in der Simulation unterstützen, anstatt eine Autorisierung für den Feldeinsatz zu suggerieren,
• erklären, warum ein Fehler auftritt, anstatt nur Ersatzcode vorzuschlagen.

Was er nicht tun sollte, ist zu suggerieren, dass generierte Logik sicher ist, nur weil sie syntaktisch plausibel ist. IEC 61131-3 definiert Programmiersprachen und Strukturen für die industrielle Steuerung, aber Sprachkonformität ist nicht dasselbe wie Prozesssicherheit, funktionale Sicherheit oder Abnahme durch die Inbetriebnahme (IEC, 2013).

Der Hauptunterschied liegt nicht in der „KI-Qualität“ im Abstrakten. Er liegt darin, ob das Modell aus dem tatsächlichen Steuerungskontext, dem Simulationszustand und den technischen Einschränkungen der jeweiligen Aufgabe schlussfolgern kann.

| Merkmal | Allgemeines LLM | OLLA Lab Yaga-Assistent | |---|---|---| | Kontextbewusstsein | Verlässt sich auf Texteingaben und benutzerdefinierte Beschreibungen. | Arbeitet innerhalb des Projekt- und Simulationskontexts von OLLA Lab. | | Tag- und E/A-Bezug | Kann Live-Projektzuordnungen nicht von Natur aus verifizieren. | Unterstützt die Fehlersuche anhand sichtbarer Variablen, Tags und Szenarioverhalten. | | Scan-Zyklus-Relevanz | Kann SPS-Konzepte korrekt beschreiben, übersieht aber oft Auswirkungen der Ausführungsreihenfolge in der spezifischen Logik des Benutzers. | Kann Benutzer auf Probleme mit der Scan-Reihenfolge und Zustandsdivergenzen innerhalb des begrenzten Labor-Workflows hinweisen. | | Hardware-Realismus | Keine native Verbindung zu Anlagen oder Labor-Simulationszuständen, sofern nicht explizit integriert. | Wird zusammen mit der OLLA Lab-Simulation und digitalen Zwilling-Szenariomodellen verwendet. | | Lernergebnis | Tendiert oft zur reinen Antwortgenerierung. | Soll Diagnose, Erklärung und Überarbeitung unterstützen. | | Sicherheitsaspekt | Leicht zu übervertrauen, da die Ausgabe flüssig ist. | Begrenzt als Hilfe für Erprobung und Validierung, keine Inbetriebnahme-Autorität. |

Die sicherheitstechnische Implikation ist eindeutig. Allgemeine LLMs können für die Konzeptüberprüfung nützlich sein, sind aber unzuverlässig, wenn Benutzer sie so behandeln, als wäre flüssiger Text gleichbedeutend mit deterministischer Steuerungsprüfung. In der industriellen Automatisierung ist Eloquenz billig. Korrektes Sequenzverhalten ist es nicht.

Yaga hilft, indem er die Fehlersuche in einen beobachtbaren Workflow verwandelt, anstatt in ein Ratespiel. Der Benutzer kann Logik im browserbasierten Kontaktplan-Editor erstellen, die Simulation ausführen, Variablen und E/As inspizieren und um Anleitung bitten, die an das gebunden ist, was das System gerade tut.

Ein typisches Fehlermuster ist das Überschreiben von Ausgängen innerhalb desselben Scans. Betrachten Sie dieses vereinfachte Beispiel:

[Sprache: Kontaktplan - Fehlerbeispiel] // Yaga erkennt das Doppelspulen-Syndrom Netzwerk 1: XIC(Start_PB) OTE(Motor_Run) Netzwerk 2: XIC(Stop_PB) OTE(Motor_Run) // Fehler: Ausgangszustand überschrieben

Das Problem ist nicht nur, dass der Code „seltsam aussieht“. Das Problem ist, dass `Motor_Run` an mehr als einer Stelle geschrieben wird, sodass sein Endzustand von der Scan-Progression und der Auswertung der Netzwerk-Wahrheit abhängt. Ein Nachwuchsingenieur sieht vielleicht zwei vernünftige Anweisungen. Ein Inbetriebnehmer sieht eine Einladung, einen Nachmittag zu verlieren.

Yagas Wert in einem solchen Fall ist nicht, dass er magisch die eine wahre Antwort kennt. Sein Wert liegt darin, dass er den Benutzer zu den richtigen diagnostischen Fragen führen kann:

• Wo wird der Ausgang geschrieben?
• Ist die Stopp-Logik als Freigabeunterbrechung oder als widersprüchlicher Schreibvorgang implementiert?
• Bewahrt der Selbsthaltepfad den Zustand korrekt?
• Meldet die simulierte Motorrückmeldung jemals den Betriebszustand?
• Welcher Tag ändert sich zuerst, und welcher sollte es?

Das ist der richtige Lernzyklus. Dem Benutzer wird nicht einfach ein korrigiertes Netzwerk übergeben; er wird aufgefordert, aus Kausalität, Zustand und Ausführungsreihenfolge zu schlussfolgern.

Yaga ist am nützlichsten, wenn die Logikprüfung an das simulierte Anlagenverhalten gebunden ist. Kontaktplan-Logik ist nur die halbe Miete; die andere Hälfte ist, ob das Maschinen- oder Prozessmodell so reagiert, wie es die Steuerungsphilosophie erwartet.

In OLLA Lab können Benutzer Logik im Simulationsmodus testen, Eingänge umschalten, Ausgänge und Variablenzustände beobachten und szenariobasierte industrielle Übungen durcharbeiten. Die Plattform enthält auch 3D- und WebXR/VR-Simulationsoptionen und positioniert diese als Validierungsumgebungen für digitale Zwillinge. Dieser Begriff erfordert Disziplin.

In diesem Artikel bedeutet Validierung durch digitale Zwillinge das Testen der Steuerungslogik gegen ein realistisches virtuelles Anlagenmodell oder eine Szenariodarstellung, um zu sehen, ob Sequenzen, Verriegelungen, Alarme und Analogreaktionen wie beabsichtigt funktionieren, bevor sie live eingesetzt werden. Das bedeutet nicht, dass die Simulation ein rechtlich ausreichender Ersatz für FAT, SAT, Gefahrenanalysen, Loop-Checks oder die Abnahme vor Ort ist.

Diese begrenzte Definition stimmt mit der breiteren Literatur zu digitalen Zwillingen überein, die Zwillinge im Allgemeinen als Entscheidungsunterstützungs- und Validierungsumgebungen behandelt und nicht als unfehlbare Spiegelbilder der Anlagenrealität (Tao et al., 2019; Jones et al., 2020). Ein guter Zwilling reduziert Unsicherheit. Er schafft sie nicht ab.

Der sicherste Weg, KI in der Steuerungstechnik zu nutzen, besteht darin, nach Struktur, Annahmen und Validierungskriterien zu fragen, anstatt nach blindem Code. Fragen Sie zuerst nach einem Gerüst für die Steuerungsbeschreibung. Testen Sie es dann.

Ein schwacher Prompt sieht so aus:

• „Schreibe Kontaktplan-Logik für eine Pumpstation.“

Ein stärkerer Prompt sieht so aus:

- „Erstelle ein erstes Kontaktplan-Gerüst für eine Leit-/Folge-Pumpensequenz mit: Erkläre die Annahmen, erforderlichen Tags und was in der Simulation verifiziert werden muss.“

• zwei Pumpen,
• Niedrigstand-Verriegelung,
• Hochstand-Start,
• 5-Sekunden-Entprellung am Niedrigstand-Schalter,
• Betriebsrückmeldung,
• Alarm bei Startfehler,
• Hand-/Automatik-Modus,
• abwechselnde Leitpumpen-Zuweisung nach jedem abgeschlossenen Zyklus.

Dieser Prompt ist besser, weil er nach technischer Struktur fragt und nicht nach einem Code-Dump. Er zwingt den Assistenten, Annahmen offenzulegen, und gibt dem Benutzer etwas Testbares.

Ein praktisches Prompt-Muster für Yaga

Verwenden Sie diese Sequenz:

Beispiel: „Steuerung einer Duplex-Hebeanlage mit abwechselndem Pumpenbetrieb.“

Beispiel: „Verriegelung bei Niedrigststand, Alarm bei Startfehler, Abschaltung bei Überlast.“

Beispiel: „Füge 3 Sekunden Entprellung und 2 Sekunden Timeout für die Betriebsrückmeldung hinzu.“

Beispiel: „Liste erforderliche Eingänge, Ausgänge, interne Bits, Timer und Sequenzschritte auf.“

Beispiel: „Was sollte ich in der Simulation beobachten, um dies als korrekt zu bezeichnen?“

1. Prozessziel angeben
2. Abnormale Bedingungen definieren
3. Timing- und Rückmeldeanforderungen spezifizieren
4. Nach Tag-Annahmen und Sequenzzuständen fragen
5. Nach Verifizierungskriterien fragen

Dieser letzte Schritt ist wichtig. Ingenieure sollten die KI bitten, Beweise zu definieren, nicht nur Ausgaben zu liefern.

Ingenieure sollten das Verhalten validieren, nicht die Qualität der Prosa. Eine plausible Erklärung oder ein sauberes Netzwerkmuster reicht nicht aus.

Bevor Sie KI-unterstützte Logik auch nur als simulationswürdig betrachten, verifizieren Sie:

Sind alle erforderlichen Eingänge, Ausgänge, Analogwerte und internen Tags vorhanden und korrekt typisiert?

• Integrität der E/A-Zuordnung

Wird jeder kritische Ausgang durch eine kohärente Struktur gesteuert, anstatt durch verstreute Schreibvorgänge?

• Ausgangssteuerung aus einer Quelle

Sind Starts, Stopps, Verriegelungen, Fehler und Resets sauber getrennt?

• Freigabe- und Abschaltlogik

Kann die Sequenz jeden erwarteten Zustand erreichen, halten und verlassen, ohne in einen Deadlock zu geraten?

• Zustandsfortschritt

Was passiert bei Sensorausfall, Rückmeldefehler, Timeout, Überlast oder Änderung des Betriebsmodus?

• Behandlung abnormaler Zustände

Wenn Analogwerte oder PID-Anweisungen beteiligt sind, verhalten sich Schwellenwerte, Grenzwerte und Alarmbänder wie beabsichtigt?

• Analog- und PID-Verhalten

Kann der Benutzer die Logik anhand eines realistischen Szenarioverhaltens demonstrieren, nicht nur durch statische Überprüfung?

• Simulationsnachweis

Hier ist auch das Variablen-Panel von OLLA Lab wichtig. Eine gute Fehlersuche hängt davon ab, Tag-Zustände, Analogwerte und das Verhalten von Regelkreisen zu sehen, während die Logik ausgeführt wird. Ohne Beobachtbarkeit wird Fehlersuche zur Folklore.

Ingenieure sollten einen kompakten Nachweis dokumentieren, keine Screenshot-Galerie. Einstellende Manager, Ausbilder und leitende Prüfer lernen mehr aus einem Fehler- und Revisionspfad als aus polierten Bildern des Endzustands.

Verwenden Sie diese Struktur:

1. Systembeschreibung Beschreiben Sie den Prozess, die Ausrüstung und das Steuerungsziel in einfachen technischen Begriffen.
2. Operative Definition von „korrekt“ Geben Sie an, was passieren muss, damit die Logik in der Simulation als korrekt angesehen wird. Schließen Sie Sequenzverhalten, Verriegelungen, Alarme und Rückmeldebedingungen ein.
3. Kontaktplan-Logik und simulierter Anlagenzustand Zeigen Sie die relevanten Netzwerke, Tags und den entsprechenden Maschinen- oder Prozesszustand in der Simulation.
4. Der injizierte Fehlerfall Dokumentieren Sie den bewusst eingeführten oder entdeckten Fehler, wie z. B. einen unterbrochenen Selbsthaltepfad, falsches Entprell-Timing oder überschriebene Ausgänge.
5. Die vorgenommene Revision Erklären Sie die Logikänderung und warum sie das beobachtete Verhalten auflöst.
6. Gelernte Lektionen Fassen Sie zusammen, was der Fehler über Scan-Reihenfolge, Kausalität, Prozessannahmen oder Inbetriebnahme-Risiken offenbart hat.

Diese Struktur liefert den Nachweis des logischen Denkens. Sie ist weitaus glaubwürdiger als „hier ist meine fertige Kontaktplan-Datei“. Fertige Dateien verbergen die interessanten Fehler, und die Fehler sind meist der Punkt, an dem die Ingenieursarbeit beginnt.

Nein. Yaga ist ein begrenzter Labor-Coach, kein Ersatz für leitende Ingenieursüberprüfungen, formale Sicherheitsmethoden oder Validierungen vor Ort.

Diese Grenze ist keine rechtliche Formalität; es ist technische Ehrlichkeit. Funktionale Sicherheit, Gefahrenanalyse und Inbetriebnahme-Abnahme erfordern Methoden und Verantwortlichkeiten, die weit über KI-unterstützte Code-Reviews hinausgehen. IEC 61508 und die damit verbundene Sicherheitspraxis machen dies deutlich: Software-Korrektheit ist Teil eines größeren Lebenszyklus von Gefahrenidentifikation, Risikoreduzierung, Verifizierung, Validierung und Managementkontrolle (IEC, 2010; exida, 2024).

OLLA Lab und Yaga sind am besten als Erprobungswerkzeuge für risikoreiche Aufgaben zu verstehen, die Berufseinsteiger selten sicher an Live-Systemen üben können:

• Validierung von Steuerungslogik,
• Überwachung des E/A-Verhaltens,
• Nachverfolgung von Ursache und Wirkung,
• Umgang mit abnormalen Zuständen,
• Überarbeitung der Logik nach einem Fehler,
• Vergleich des simulierten Anlagenzustands mit dem Kontaktplan-Zustand.

Das ist ein erheblicher Wert, und er ist ausreichend.

Die praktische Rolle von Yaga besteht darin, den Weg von „Ich habe etwas geschrieben“ zu „Ich kann erklären, warum es funktioniert, warum es fehlgeschlagen ist und was sich geändert hat“ zu verkürzen. Das ist der Übergang von der Syntax-Vertrautheit zum Urteilsvermögen bei der Inbetriebnahme.

Innerhalb von OLLA Lab ist diese Rolle in eine breitere Umgebung eingebettet, die Folgendes umfasst:

• einen webbasierten Kontaktplan-Editor mit Standard-Anweisungstypen,
• geführte Workflows zum Erlernen von Kontaktplänen,
• Simulationsmodus für sichere Ausführung und Tests,
• Sichtbarkeit von Variablen und E/As,
• Lernwerkzeuge für Analog- und PID-Regelungen,
• szenariobasierte industrielle Übungen,
• Validierungs-Workflows im Stil digitaler Zwillinge,
• optionale 3D/WebXR/VR-Anlagenansichten,
• Funktionen für Zusammenarbeit und Überprüfung in Lehrumgebungen.

Yaga ersetzt diese Komponenten nicht. Er wird nützlich, weil diese Komponenten bereits existieren. Gute Unterstützung hängt von guter Instrumentierung ab; das gilt in Anlagen ebenso wie in Trainingssystemen.

- IEC 61508 Übersicht zur funktionalen Sicherheit - IEC 61131-3 Programmierbare Steuerungen - Programmiersprachen - NIST SP 800-207 Zero Trust Architektur - Tao et al. (2019) Digitaler Zwilling in der Industrie (IEEE) - Kritzinger et al. (2018) Digitaler Zwilling in der Fertigung (IFAC) - Negri et al. (2017) Digitaler Zwilling in CPS-basierten Produktionssystemen - exida Ressourcen zur funktionalen Sicherheit - U.S. Bureau of Labor Statistics