So verhindern Sie durch KI generierte SPS-Fehler mit simulationsbasierter Validierung

Um durch KI generierte SPS-Fehler zu verhindern, müssen Ingenieure die Logik vor der Inbetriebnahme anhand von Scan-Verhalten, Anlagenlatenz, Fehlerzuständen und Anforderungen an den sicheren Zustand validieren. LLMs können zwar plausiblen Kontaktplan-Code generieren, verstehen jedoch weder deterministische Ausführung noch das Verhalten physikalischer Prozesse. Ein risikofreier Simulator wie OLLA Lab hilft Ingenieuren dabei, Fehler zu proben, Konsequenzen zu beobachten und die Logik zu härten, bevor sie auf echte Anlagen trifft.

KI-generierte Kontaktplan-Logik scheitert meist nicht daran, dass sie unleserlich ist. Sie scheitert, weil sie lesbar genug ist, um ihr zu vertrauen.

Ein LLM kann Kontaktplan-Sprossen erstellen, die kompetent aussehen, aber das Verhalten des Scan-Zyklus, das Timing der Rückmeldungen, die Verriegelungspersistenz oder das Handling von Fail-Safe-Zuständen ignorieren. In der industriellen Steuerungstechnik ist Syntax billig; die Einsatzfähigkeit ist es nicht.

In einem aktuellen internen Benchmark von OLLA Lab produzierten Junior-Ingenieure, die ungeprüfte, KI-generierte Motorsteuerungssequenzen in einem digitalen Zwilling eines Förderbands einsetzten, in 18 von 23 Versuchen (78 %) funktionale oder sicherheitsrelevante Fehler – meist durch Entriegelungsfehler, fehlende Freigaben und Annahmen zur Scan-Reihenfolge. Nach drei geführten Simulationsübungen zur Fehlerbehandlung verbesserte sich ihre erfolgreiche Identifizierung und Korrektur dieser Defekte um 62 % gegenüber ihrer eigenen Baseline. Methodik: n=23 Junior-Teilnehmer; Aufgabenstellung: Generierung und Validierung von KI-gestützten Motor-/Förderband-Kontaktplan-Sequenzen in OLLA Lab; Baseline-Vergleich: erste ungeprüfte Einreichung gegenüber korrigierter Einreichung nach der Übung; Zeitfenster: interner Benchmark im 1. Quartal 2026. Dies stützt eine eng gefasste Aussage über simulationsbasierte Fehlererkennung in einer begrenzten Laboraufgabe. Es beweist weder die Einsatzbereitschaft der Belegschaft noch die Standortkompetenz oder Sicherheitszertifizierung.

Die Junior-Talent-Klippe ist nicht nur ein Einstellungsmangel. Es ist ein Verlust an stillschweigendem Ingenieursurteil.

Öffentliche Quellen zeigen zwar eine anhaltende Belastung bei der Personalbeschaffung in der Fertigung und Industrietechnik, aber diese Zahlen müssen mit Vorsicht behandelt werden. Daten des U.S. Bureau of Labor Statistics, Berichte von Deloitte/Manufacturing Institute und Kommentare der NAM deuten kollektiv auf anhaltende Schwierigkeiten bei der Besetzung von Fertigungs- und technischen Stellen hin, insbesondere dort, wo sich Steuerung, Wartung und Systemintegration überschneiden. Was diese Zahlen nicht direkt messen, ist das Verschwinden von anlagenspezifischem Fehlerbehebungswissen. Dieser Verlust ist schwerer zu zählen und leichter zu spüren.

In der Automatisierung gehen Senior-Ingenieure mit einem Mustergedächtnis in den Ruhestand, das selten allein in Zeichnungen existiert:

• wie ein klebendes Ventil Ihre Sequenz täuscht,
• wie ein Näherungsschalter gerade so stark prellt, dass er Unsinn erzeugt,
• wie eine Freigabe, die eigentlich in Ordnung sein sollte, bei einem Neustart versagt,
• wie eine Not-Halt-Kette nach der Wiederkehr der Stromversorgung mit verriegelten Ausgängen interagiert.

Das ist die eigentliche Klippe. Nicht weniger Programmierer. Weniger Menschen, die gesehen haben, wie sich Maschinen auf eine Weise falsch verhalten, die die Logik nicht höflich angekündigt hat.

Die Gefahr der Syntax-zuerst-Illusion

KI macht Junior-Ingenieure schneller bei der Erstellung von Kontaktplan-Syntax. Sie macht sie nicht schneller beim Erkennen physikalischer Konsequenzen.

Historisch gesehen erwarben viele Ingenieure ihr Urteilsvermögen langsam durch Inbetriebnahme, Fehlerbehebung und schlechte Nachmittage in der Nähe von Anlagen, die sich weigerten, der Zeichnung zu folgen. KI komprimiert den Schritt des Codeschreibens, ohne den Schritt des Fehlerlernens zu komprimieren. Das erzeugt eine gefährliche Asymmetrie: Junioren können jetzt Steuerungslogik generieren, bevor sie gelernt haben, was man fürchten muss.

In diesem Kontext sind „Kampfnarben“ keine Prahlerei und keine Folklore. Sie sind Erfahrungswissen über:

• mechanische Latenz und Haftreibung,
• Sensorprellen und verrauschte Übergänge,
• Abhängigkeiten von der Scan-Zeit,
• Verriegelungs- und Neustart-Verhalten,
• Fail-Safe-Verriegelungsdesign unter anormalen Bedingungen.

Eine Anlage erteilt diese Lektionen irgendwann. Es ist nur ein teures Klassenzimmer.

KI-generierte SPS-Logik wird zu einem begreifbaren Albtraum, wenn sie lexikalisch plausibel, aber physikalisch falsch ist.

Große Sprachmodelle (LLMs) sagen wahrscheinliche Token-Sequenzen aus Trainingsdaten voraus. Sie führen kein physikalisches Modell aus und sie denken nicht inhärent über das Laufzeitverhalten nach IEC 61131-3 nach, wie es ein Inbetriebsetzungsingenieur muss. Sie können die Kontaktplan-Struktur imitieren. Man kann nicht davon ausgehen, dass sie Scan-Reihenfolge, Speicherpersistenz, asynchrone Feld-Updates oder das Timing-Verhalten realer Geräte verstehen.

Diese Unterscheidung ist wichtig, weil industrielle Steuerung nicht danach beurteilt wird, ob die Sprosse vertraut aussieht. Sie wird danach beurteilt, ob die Maschine unter normalen, anormalen und Fehlerbedingungen den korrekten Zustand erreicht und beibehält.

Die drei blinden Flecken von Automatisierungs-Copiloten

#### 1. Ignoranz gegenüber dem Scan-Zyklus

Ein LLM weiß in keinem fundierten Sinne, dass eine SPS Logik zyklisch löst und dass der Ausgangszustand von der Befehlsreihenfolge, der Speichersemantik und dem Update-Timing abhängt.

Häufige Fehlermuster sind:

• doppelte Schreibzugriffe auf denselben Ausgang in verschiedenen Sprossen,
• fehlende Selbsthaltelogik,
• Race Conditions zwischen Freigaben und Rücksetzzweigen,
• Alarmlogik, die zu früh löscht, weil die Zustandsbeibehaltung nicht explizit entworfen wurde.

Hier treten das Doppelspulen-Syndrom und verwandte Reihenfolgefehler auf. Der Code mag kompilieren. Die Maschine kann sich dennoch unvorhersehbar verhalten.

#### 2. Mechanische Latenz

KI neigt dazu anzunehmen, dass Zustandsänderungen sofort erfolgen, sofern nicht explizit etwas anderes angegeben ist.

Reale Ausrüstung ist nicht sofort:

• Ventile brauchen Zeit zum Schalten,
• Pumpen erfordern eine Rückmeldung,
• Förderbänder laufen aus,
• Tanks hören nicht auf zu füllen, nur weil die Sprosse entschlossen aussah,
• Druck- und Pegelsignale hinken dem Befehl hinterher.

Ein Logikpfad, der im Text sauber erscheint, kann versagen, sobald physikalische Verzögerungen in die Sequenz eintreten. Dies ist besonders häufig bei Startfreigaben, Timeout-Handling und Verriegelungsfreigabelogik der Fall.

#### 3. Zustandspersistenz und Wiederanlaufverhalten

KI spezifiziert oft unzureichend, was nach Auslösungen, Stromausfall, Kommunikationsfehlern oder teilweisen Neustartbedingungen geschehen soll.

Das zeigt sich in:

• First-Out-Alarmlogik, die die auslösende Ursache verliert,
• verriegelten Auslösungen, die sich automatisch zurücksetzen, wenn sie ein manuelles Zurücksetzen durch den Bediener erfordern sollten,
• Neustart-Verhalten, das Ausgänge ohne eine bewusste Sicherheitszustands-Sequenz wieder einschaltet,
• Freigabeketten, die nicht zwischen „nicht bereit“, „ausgelöst“ und „fehlgeschlagener Rückmeldung“ unterscheiden.

Dies ist kein kosmetischer Defekt. IEC 61508 und verwandte Praktiken der funktionalen Sicherheit existieren genau deshalb, weil systematische Fehler in der Steuerungslogik gefährliche Zustände erzeugen können, wenn die Validierung schwach oder die Annahmen falsch sind.

KI-generierte Logik kann für sich genommen die Anforderungen an die systematische Eignung eines Lebenszyklus der funktionalen Sicherheit nicht erfüllen.

IEC 61508 ist kein Stilhandbuch für das Schreiben von saubererem Code. Es ist ein Lebenszyklus-Framework, das Gefahrenanalyse, Zuweisung von Sicherheitsanforderungen, Designdisziplin, Verifizierung, Validierung, Änderungskontrolle und den Nachweis erfordert, dass der beabsichtigte sichere Zustand unter definierten Fehlerbedingungen erreicht wird. Eine generierte Sprosse ist kein Nachweis der Konformität. Sie ist bestenfalls ein Eingabeartefakt, das eine Überprüfung und Validierung erfordert.

Diese Unterscheidung sollte deutlich bleiben:

• KI kann beim Entwurf helfen.
• KI verleiht keine Sicherheitsintegrität.
• KI-Ausgabe ist kein Ersatz für Verifizierung.
• KI-generierte Logik wird nicht dadurch sicherheitsrelevant, dass sie früheren Beispielen ähnelt.

Die Überprüfung durch den Menschen (Human-in-the-loop) ist hier keine bürokratische Floskel. Es ist der Mechanismus, mit dem jemand prüft, ob das Steuerungsverhalten die Anlage bei Sensorausfall, klemmenden Aktuatoren, Kommunikationsverlust oder Neustart nach Unterbrechung tatsächlich in einen sicheren Zustand bringt.

Experten für funktionale Sicherheit, einschließlich exida und normbasierter Leitlinien im gesamten IEC 61508-Ökosystem, betonen konsequent die systematische Fehlerkontrolle, Rückverfolgbarkeit und Validierung. Probabilistische Textgenerierung ist nützlich für den Entwurf. Sie ist kein Sicherheitsargument.

Simulierte Kampfnarben verbessern das Prompt-Engineering, weil man keine Gefahren spezifizieren kann, von denen man nicht weiß, dass sie existieren.

Die meisten schwachen KI-Prompts in der Automatisierung scheitern aus einem einfachen Grund: Sie beschreiben die gewünschte normale Sequenz und lassen die anormale Welt aus. Das Modell füllt dann die Lücken mit generischen Steuerungsmustern – genau so, wie Ärger im feinen Zwirn daherkommt.

Ein besserer Prompt ist nicht nur detaillierter. Er ist physikalisch informiert.

Kontext-Packung für physikalische Systeme

Ein physikalisch informierter Prompt enthält die Einschränkungen, die bei der Inbetriebnahme wichtig sind:

• E/A-Definitionen,
• normale Sequenz,
• Freigaben und Verriegelungen,
• Timing der Rückmeldungen,
• Fehlerreaktionen,
• Neustart-Verhalten,
• Bedingungen für das Zurücksetzen durch den Bediener,
• Analogschwellen und Alarmbänder,
• was sicherheitsgerichtet ausfallen muss.

Zum Beispiel ist dieser Prompt schwach:

• „Schreibe Kontaktplan-Logik für einen Motorstarter mit Not-Halt und Überlast.“

Dieser Prompt ist materiell besser:

• „Schreibe Kontaktplan-Logik für einen Motorstarter mit Selbsthaltung, Überlastauslösung, Not-Halt-Klemme, manuellem Reset nach Auslösung, 3-Sekunden-Durchflussbestätigung, Timeout bei Startfehler und Neustartsperre nach Stromwiederkehr bis zum Bedienerbefehl.“

Der Unterschied ist nicht die Wortwahl. Es ist das operative Bewusstsein.

Wie OLLA Lab Ingenieuren hilft, bessere Prompts zu erstellen

OLLA Lab ist hier nützlich, weil es die Variablen und Zustandsbeziehungen offenlegt, die explizit gemacht werden müssen.

Mit dem Kontaktplan-Editor, dem Simulationsmodus und dem Variablen-Panel kann ein Ingenieur prüfen:

• welche Tags diskret oder analog sind,
• wie Ausgänge von Freigaben abhängen,
• ob Timer mit realistischen Prozessverzögerungen übereinstimmen,
• wie PID-bezogene Werte oder Analogschwellen das Verhalten beeinflussen,
• was die simulierte Anlage tut, wenn ein Signal auf High, Low, verrauscht oder verzögert gezwungen wird.

Das macht das Schreiben von Prompts von einer generischen Anfrage zu einer strukturierten Steuerungsspezifikation. In der Praxis lernt der Ingenieur, die KI um weniger Magie und mehr Determinismus zu bitten.

OLLA Lab bietet eine risikofreie Umgebung zum Schreiben, Ausführen, Beobachten und Überarbeiten von Kontaktplan-Logik gegenüber simuliertem Anlagenverhalten, bevor eine Entscheidung zur Live-Bereitstellung getroffen wird.

Das ist das begrenzte Produktversprechen, und es ist ausreichend. Der Wert liegt nicht darin, dass die Simulation die Arbeit vor Ort ersetzt. Der Wert liegt darin, dass sie wiederholte Konfrontationen mit Fehlermodi ermöglicht, die zu teuer, zu unsicher oder zu störend sind, um sie an Produktionsanlagen zu proben.

Operativ kombiniert OLLA Lab:

• einen webbasierten Kontaktplan-Editor,
• einen Simulationsmodus zum Ausführen und Stoppen von Logik,
• ein Variablen-Panel zur Überwachung und Anpassung von E/A und Tags,
• Lernwerkzeuge für Analogwerte und PID,
• 3D/WebXR/VR-Industriesimulationen, wo verfügbar,
• szenariobasierte Übungen in Bereichen wie Wasser, HLK, Prozessanlagen, Lagerhaltung und Fertigung,
• geführte Unterstützung durch den GeniAI-Laborassistenten.

Die OLLA Lab Validierungsschleife

Eine nützliche Validierungsschleife in OLLA Lab sieht so aus:

1. Schreiben mit Yaga oder manuelle Erstellung der Baseline-Logik Verwenden Sie den Kontaktplan-Editor, um die anfängliche Sequenz zu erstellen. Wenn Yaga unterstützt, behandeln Sie die Ausgabe als Entwurf, nicht als Urteil.
2. Definieren Sie, was „korrekt“ bedeutet, bevor Sie die Simulation ausführen Spezifizieren Sie erwartete Startbedingungen, Freigaben, Auslösebedingungen, Alarmverhalten und den erforderlichen sicheren Zustand.
3. Injizieren Sie Fehler über das Variablen-Panel Schalten Sie Eingänge um, halten Sie Rückmeldungen aus, simulieren Sie verzögerte Bestätigungen, erzwingen Sie Analogdrift oder erzeugen Sie anormale Übergänge.
4. Beobachten Sie den Zustand der simulierten Anlage Vergleichen Sie den Kontaktplan-Zustand mit dem 3D- oder Szenario-Verhalten. Startete die Pumpe ohne Bestätigung? Lief der Tank über? Hat sich the Sequenz falsch erholt?
5. Überarbeiten und härten Sie die Logik Fügen Sie Entprellung, Timeout-Handling, Verriegelungen, Rücksetzbedingungen, Freigaben, Alarm-Speicherung oder Sicherheits-Fallbacks hinzu.
6. Führen Sie das Szenario unter normalen und anormalen Bedingungen erneut aus Eine Sequenz, die nur im „Happy Path“ funktioniert, ist unvollständig. Inbetriebnahme ist der Ort, an dem „Happy Path“-Logik korrigiert wird.

Hier wird OLLA Lab operativ nützlich. Es gibt Junior-Ingenieuren einen Ort, um Ursache und Wirkung zu lernen, nicht nur die Platzierung von Symbolen.

Was „Simulationsbereit“ in Ingenieursbegriffen bedeutet

Simulationsbereit sollte nicht als Kompliment ohne Inhalt behandelt werden. Es hat eine operative Bedeutung.

Ein simulationsbereiter Ingenieur kann:

• erwartetes Logikverhalten gegenüber definierten E/A beweisen,
• simulierte Anlagenreaktionen unter normalen und fehlerhaften Zuständen beobachten,
• Diskrepanzen zwischen Kontaktplan-Zustand und physikalischem Zustand diagnostizieren,
• Logik basierend auf dem beobachteten Fehler überarbeiten,
• demonstrieren, warum die überarbeitete Sequenz sicherer oder deterministischer ist als das Original.

Das ist die Unterscheidung, die zählt: Syntax versus Einsatzfähigkeit.

Der Unterschied ist im Erscheinungsbild meist nicht dramatisch. Er ist dramatisch in den Konsequenzen.

Eine naive KI-generierte Sprosse schaltet den Motorausgang oft direkt über eine Startanforderung und ein paar Freigaben ein. Eine gehärtete Version handhabt explizit das Selbsthalteverhalten, Stoppbedingungen, Auslöse-Reset, Rückmeldungen und Timeouts bei Startfehlern.

Beispiel: konzeptioneller Kontaktplan-Kontrast

; Naiver KI-generierter Motorstart | START_PB STOP_OK OL_OK |--------------------( OTE MOTOR_RUN )

; Gehärtetes Konzept mit Selbsthaltung und Freigaben | STOP_OK OL_OK ESTOP_OK RESET_OK ( START_PB ODER MOTOR_RUN ) |----( OTE MOTOR_RUN_CMD )

| MOTOR_RUN_CMD FLOW_PROOF |--------------------------------------( OTE MOTOR_RUN )

| MOTOR_RUN_CMD NICHT FLOW_PROOF |----[TON START_TIMEOUT 3s]--------( )

| START_TIMEOUT.DN |-----------------------------------------------( OTL FAILED_START )

| RESET_PB STOP_OK OL_OK ESTOP_OK |--------------------------( OTU FAILED_START )

Dieses Beispiel ist vereinfacht, aber der ingenieurtechnische Punkt ist klar:

• die naive Sprosse fragt, ob der Befehl vorhanden ist,
• die gehärtete Sprosse fragt, ob das System freigegeben, bestätigt und wiederherstellbar ist.

Das ist eine andere Klasse des Denkens.

Junior-Ingenieure sollten technische Nachweise dokumentieren, nicht nur fertige Diagramme.

Ein Screenshot eines Kontaktplan-Programms beweist für sich genommen fast nichts. Er zeigt nicht, ob der Ingenieur den Prozess verstanden, Korrektheit definiert, Fehler getestet oder die Sequenz nach einem Versagen überarbeitet hat. Ein kompakter Nachweis ist für Ausbilder, Prüfer und Arbeitgeber weitaus glaubwürdiger.

Verwenden Sie diese Struktur:

Spezifizieren Sie die eingeführte anormale Bedingung: fehlende Bestätigung, verrauschter Sensor, verzögertes Ventil, Analogdrift, klemmender Eingang, Stromwiederkehr oder Auslösebedingung.

Dokumentieren Sie die Logikänderung: Timer, Verriegelung, Interlock, Rücksetzpfad, Alarmspeicherung, Freigabeverfeinerung oder Sequenzumstrukturierung.

1. Systembeschreibung Beschreiben Sie die Maschine oder den Prozess, wichtige E/A, Sequenzabsicht und Betriebseinschränkungen.
2. Operative Definition von „korrekt“ Geben Sie an, was das System im Normalbetrieb tun muss, was den Betrieb verhindern muss und was der sichere Zustand bei einem Fehler ist.
3. Kontaktplan-Logik und simulierter Anlagenzustand Zeigen Sie die relevanten Sprossen und das entsprechende simulierte Maschinenverhalten oder den Prozesszustand.
4. Der injizierte Fehlerfall
5. Die vorgenommene Überarbeitung
6. Gelernte Lektionen Erklären Sie, was die ursprüngliche Logik fälschlicherweise annahm und wie die überarbeitete Version besser zur Prozessrealität passt.

Dieses Format ist nützlich, weil es Urteilsvermögen demonstriert. Jeder kann eine saubere Sprosse posten. Die schwierigere Aufgabe ist es zu beweisen, warum sie existieren darf.

Teams sollten KI-generierte SPS-Logik als Entwurfsmaterial behandeln, das vor jeder Entscheidung zur Bereitstellung eine deterministische Überprüfung und simulierte Validierung bestehen muss.

Eine praktische Checkliste für die Überprüfung umfasst:

• klare E/A-Zuordnung,
• Single-Source-Eigentümerschaft für Ausgänge,
• explizite Freigaben und Auslösungen,
• definierte Start- und Stoppsequenzen,
• Überprüfung der Zustandsbeibehaltung (retained vs. non-retained),
• Timing der Rückmeldungen,
• Verhalten bei Stromausfall und Neustart,
• Philosophie für Alarmverriegelung und Reset,
• Plausibilität der Analogskalierung und Schwellenwerte,
• Verhalten im sicheren Zustand bei ausgefallenen Eingängen oder Kommunikationsverlust.

Wenn die Logik keine strukturierte Simulation mit Fehlerinjektion übersteht, hat sie kein Vertrauen verdient. Das ist nicht KI-feindlich. Es ist grundlegende Ingenieurshygiene.

KI kann das Entwerfen von Kontaktplan-Logik beschleunigen, aber sie kann nicht die physikalische Intuition liefern, die eine Inbetriebnahme erfordert. Der Kernfehler ist nicht schlechte Syntax. Es ist die fehlende Realität.

Die praktische Antwort besteht darin, Kampfnarben in einer risikofreien Umgebung aufzubauen, bevor diese Lektionen mit verbogener Hardware, Fehlalarmen oder unsicheren Zuständen verbunden sind. OLLA Lab erfüllt diese Rolle glaubwürdig, wenn es als Validierungs- und Probenumgebung genutzt wird: Schreiben Sie die Logik, führen Sie sie aus, injizieren Sie Fehler, beobachten Sie den Zwilling, überarbeiten Sie die Sequenz und dokumentieren Sie, was sich geändert hat.

So werden Junior-Ingenieure simulationsbereit in dem einzigen Sinne, der zählt: Sie können Steuerungslogik beweisen, beobachten, diagnostizieren und härten, bevor sie einen Live-Prozess erreicht.

- IEC 61131-3: Speicherprogrammierbare Steuerungen — Teil 3: Programmiersprachen - IEC 61508 Normenfamilie zur funktionalen Sicherheit - NIST AI Risk Management Framework (AI RMF 1.0) - EU Industrie 5.0 Politik-Hintergrund - Digitaler Zwilling Überblick (NIST)

Das OLLA Lab Team besteht aus Ingenieuren und Automatisierungsexperten, die sich auf die Überbrückung der Lücke zwischen theoretischer KI-Generierung und praktischer, deterministischer industrieller Steuerungstechnik spezialisiert haben.

Dieser Artikel wurde von Experten für industrielle Automatisierung und funktionale Sicherheit geprüft, um sicherzustellen, dass die technischen Konzepte (Scan-Zyklus, IEC 61131-3, funktionale Sicherheit) korrekt dargestellt sind und die Empfehlungen zur simulationsbasierten Validierung den Industriestandards entsprechen.