Wie man PLC-Was-wäre-wenn-Szenarien in VR für die Fehleranalyse testet

Hochinteraktive Fehleranalyse ist das gezielte Einbringen realistischer Steuerungsfehler – wie verlorenes Sensor-Feedback, negative Sollwerte und fehlgeschlagene Prüfungen – in die PLC-Logik, um defensive Reaktionen zu verifizieren. WebXR und VR-Digital-Twins machen diese Tests beobachtbar und wiederholbar, ohne reale Anlagen, Bediener oder Produktionsmittel unnötigen Risiken auszusetzen.

Das Testen des reinen Soll-Ablaufs ist keine Validierung. Es ist eine Generalprobe für eine Welt, in der nichts schiefgeht – doch so sieht der Anlagenbetrieb nicht aus.

Sowohl IEC 61508 als auch IEC 61511 drängen Ingenieurteams dazu, den Lebenszyklus unter anormalen und fehlerhaften Bedingungen zu validieren, nicht nur das Nominalverhalten. Die Schwierigkeit ist praktischer Natur: Viele der Fehlerzustände, die es wert wären, getestet zu werden, sind genau jene, die man an einer laufenden Anlage nicht provozieren darf. Nur wenige Betriebsleiter sind begeistert, wenn man kurzzeitig ein fehlerhaftes Analogsignal in eine laufende Anlage einspeist.

Während des internen Benchmarkings der 3D-Prozess-Szenarien von OLLA Lab identifizierten Ingenieure, die das Einbringen von Fehlern bei verlorenem Feedback übten, ein instabiles PID-Verhalten um 62 % schneller als eine Vergleichsgruppe, die nur mit 2D-Diagrammen arbeitete [Methodik: n=26 Lernende und Junior-Ingenieure; Aufgabe definiert als Diagnose und Korrektur eines simulierten Füllstandsregelungs-Runaways durch Signalverlust; Basisvergleich war Training nur mit Ladder-Editor ohne 3D/WebXR-Interaktion; gemessen über einen 14-tägigen Laborzeitraum]. Dies stützt die begrenzte Aussage: Die visuelle Darstellung von Fehlerfolgen kann die Diagnosegeschwindigkeit in diesem Trainingskontext verbessern. Dies beweist keine universelle Feldleistung über alle Anlagen, Teams oder Prozesstypen hinweg.

Hochinteraktive Fehleranalyse ist die Praxis, realistische Fehler in die Steuerungslogik einzubringen und anschließend zu beobachten, ob das System sicher, deterministisch und diagnostisch reagiert. Es geht nicht nur darum, zu sehen, ob der Code kompiliert. Es geht darum, zu sehen, ob die Steuerungsstrategie den Kontakt mit fehlerhaften Eingaben, fehlendem Feedback, verzögerten Bewegungen und Bedienerfehlern übersteht.

Operativ gesehen ist dies die Lücke zwischen der Programmierung des „Happy Path“ und der Validierung auf Inbetriebnahmeklasse. Die Happy-Path-Logik geht davon aus, dass Sensoren funktionieren, Bediener vernünftige Werte eingeben, Aktoren bei Befehlsausgabe reagieren und Sequenzen planmäßig ablaufen. Anlagen sind weniger höflich.

Ein nützlicher Rahmen hierfür ist das Denken im FMEDA-Stil. Fehlermodi sind kein abstraktes Papierkram; sie sind Aufforderungen für testbare Fragen:

• Was passiert, wenn ein 4–20 mA-Signal unter seinen gültigen Bereich fällt?
• Was passiert, wenn ein Ventilbefehl ansteht, aber die Rückmeldung (Proof) nie eintrifft?
• Was passiert, wenn eine HMI-Eingabe sichere Grenzwerte überschreitet?
• Was passiert, wenn das Feedback eines Sequenzschritts in falscher Reihenfolge eintrifft?
• Welcher Alarm erscheint zuerst, und ist dieser Alarm diagnostisch nützlich?

Hier wird die hochinteraktive Analyse wertvoll. Sie zwingt die Logik dazu, Permissive, Trips, Watchdogs, Begrenzungen (Clamps), First-Out-Alarme, Timeout-Handling und Zustandsinkonsistenzen zu berücksichtigen. Syntax ist wichtig. Die Einsatzfähigkeit ist wichtiger.

Die Grenzen von Hardware-Tests

Physische Tests haben harte Grenzen. An einem laufenden oder produktionsnahen System sind einige anormale Bedingungen zu riskant, zu destruktiv oder betrieblich zu störend, um sie absichtlich herbeizuführen.

Beispiele sind Routine:

• Das Erzwingen eines falschen Low-Level-Signals an einer Pumpengruppe kann zu Trockenlauf oder Kavitation führen.
• Die Simulation eines klemmenden, offenen Chemiedosierventils kann echte Prozessstörungen verursachen.
• Die Eingabe eines negativen Drehzahl- oder Drucksollwerts kann gegen Ausrüstungsgrenzen oder Betriebsverfahren verstoßen.
• Das Unterbrechen eines Feedback-Pfads während einer aktiven Sequenz kann einen unsicheren Maschinenzustand erzeugen.

Dies ist keine Vorsicht um ihrer selbst willen. Es ist eine Einschränkung durch Sicherheit, Anlagenschutz, Umweltschutz und Produktionskontinuität. IEC 61508 und IEC 61511 fordern keine Rücksichtslosigkeit; sie fordern eine disziplinierte Validierung.

Wie verhält sich dies zu FAT, SAT und virtueller Inbetriebnahme?

Die virtuelle Inbetriebnahme erweitert die Validierung auf Fehlerzustände, die physisch nur schwer oder gar nicht induzierbar sind. Sie ersetzt nicht FAT oder SAT. Sie ändert jedoch, was getestet werden kann, bevor diese Phasen teuer werden.

Eine praktische Unterscheidung:

• FAT verifiziert, dass das gebaute System in einer kontrollierten Umgebung generell dem Design entspricht.
• SAT verifiziert, dass das installierte System in seinem tatsächlichen Standortkontext korrekt funktioniert.
• Virtuelle Inbetriebnahme verifiziert Logik, Sequenzierung und den Umgang mit anormalen Zuständen anhand von simuliertem Anlagenverhalten vor der Standortexposition.

Hier wird OLLA Lab operativ nützlich. Sein browserbasierter Ladder-Editor, der Simulationsmodus, das Variablen-Panel und die 3D/WebXR-Digital-Twin-Umgebung ermöglichen es Ingenieuren, Fehler einzubringen, die Reaktion der Anlage zu beobachten und die Logik zu überarbeiten, bevor ein realer Prozess die Lektion lernen muss.

Man testet sie, indem man die Bedienereingabe als Fehlerquelle betrachtet, nicht als vertrauenswürdige Wahrheit. HMI-Eingaben sind eine der gewöhnlichsten Arten, außergewöhnliche Probleme zu schaffen.

Ein negativer Sollwert, ein unplausibel hoher Drehzahlbefehl oder ein Wert außerhalb der Prozessauslegungsgrenzen sollte ein explizites Steuerungsverhalten auslösen. Die Mindesterwartung ist eine begründete Ablehnung oder Korrektur. Bessere Systeme bieten zudem einen klaren Alarm und bewahren die Rückverfolgbarkeit dessen, was versucht wurde.

In der Ladder-Logik basiert das defensive Muster meist auf einer kleinen Menge bekannter Anweisungen:

- LIM (Limit Test): prüft, ob ein eingegebener Wert innerhalb eines akzeptablen Betriebsbands liegt - MOV (Move): überschreibt einen ungültigen Wert mit einem sicheren Fallback-, Minimum- oder Maximumwert - GRT / LES (Greater Than / Less Than): erkennt Bereichsüberschreitungen - Alarm-Spule / Status-Bit: macht den Zustand der ungültigen Eingabe für HMI oder Sequenzlogik sichtbar - Interlock-Bit: verhindert die Ausführung, bis der Wert korrigiert oder bestätigt wurde

Eine kompakte Steuerungsstrategie könnte so aussehen:

• Wenn der Bediener einen Drehzahlbefehl unter 0 U/min eingibt, lehne ihn ab.
• Wenn der Bediener einen Drehzahlbefehl über dem zulässigen Maximum des Motors eingibt, begrenze ihn (Clamp).
• Löse einen Alarm „Ungültige Eingabe“ aus.
• Verhindere die Startfreigabe, bis der Befehl gültig ist.

In OLLA Lab kann dies direkt über das Variablen-Panel geübt werden, indem ein fehlerhafter Befehlswert in den simulierten Tag-Satz erzwungen wird und anschließend sowohl die Reaktion des Ladder-Zustands als auch das Verhalten des Digital-Twins beobachtet wird. Das ist wichtig, weil die Behandlung ungültiger Eingaben nicht abgeschlossen ist, wenn der Code sauber aussieht. Sie ist abgeschlossen, wenn der Maschinenzustand sicher bleibt.

Implementierung von Clamp-Logik in OLLA Lab

Eine praktische Validierungssequenz für das Testen von unzulässigen Eingaben ist:

1. Erstellen Sie einen Befehls-Tag wie `Motor_Speed_SP`.
2. Definieren Sie das gültige Band, zum Beispiel `0` bis `1800`.
3. Verwenden Sie `LIM`, um zu prüfen, ob der Sollwert akzeptabel ist.
4. Verwenden Sie `MOV`, um einen Fallback-Wert zu erzwingen, falls der Sollwert außerhalb der Grenzen liegt.
5. Lösen Sie ein Alarm-Bit aus, wenn die Eingabe ungültig ist.
6. Bestätigen Sie in der Simulation, dass das Ausgabeverhalten dem korrigierten Wert folgt, nicht dem fehlerhaften.
7. Beobachten Sie den 3D- oder WebXR-Anlagenzustand, um zu verifizieren, dass die Maschine den unsicheren Befehl nicht ausführt.

Diese Sequenz lehrt mehr als nur Syntax. Sie lehrt defensive Programmierung unter Unsicherheit durch den Bediener, was der realen Inbetriebnahme-Arbeit näherkommt.

WebXR ist hier nützlich, weil es unsichtbare Steuerungsfehler in beobachtbare Anlagenkonsequenzen verwandelt. In diesem Artikel ist das die operative Definition, nicht bloße Neuheit.

Ein verlorenes Sensorsignal ist oft leicht zu beschreiben, aber unter Druck überraschend schwer zu durchschauen. Betrachten Sie eine laufende Pumpe, die über einen Füllstands- oder Druckregelkreis gesteuert wird. Wenn das analoge Feedback aufgrund eines Kabelbruchs, eines defekten Transmitters, einer schlechten Klemme oder eines Skalierungsfehlers auf 0 mA abfällt, muss die PLC entscheiden, ob dieser Wert plausibel ist, ob der Regelkreis fortgesetzt werden soll und ob der Zustand einen Trip, Alarm oder Failover auslösen soll.

Auf einem 2D-Bildschirm sieht der Fehler vielleicht aus wie eine Zahl, die sich ändert. In einem Digital-Twin kann derselbe Fehler zeigen:

• einen Tankfüllstand, der weiter steigt,
• eine Pumpe, die trocken läuft,
• ein Ventil, das entgegen der Erwartung offen bleibt,
• einen PID-Ausgang, der sättigt,
• oder eine Prozesssequenz, die an einer Stelle hängen bleibt.

Diese visuelle Kopplung ist wichtig, weil sie den Tag-Fehler mit der Prozesskonsequenz verknüpft. Ingenieure nehmen keine Tags isoliert in Betrieb. Sie nehmen Systeme in Betrieb.

Warum nicht einfach an der Hardware testen?

Weil Hardware teuer und endlich ist und meist an etwas angeschlossen ist, das der Eigentümer nicht beschädigen möchte.

Ein WebXR- oder VR-Digital-Twin ist hier am besten als eine risikofreie Fehler-Injektionsumgebung zu verstehen:

• Null Risiko für Personal durch induzierte anormale Zustände
• Null Risiko für die Produktionskontinuität während des Trainings oder der Generalprobe
• Null Risiko für die Ausrüstung durch wiederholtes Testen von Fehlerzuständen
• Kostengünstige Wiederholung desselben Fehlerfalls, bis die Logik gehärtet ist

Das bedeutet nicht, dass Simulation in jeder Hinsicht besser ist als die Realität. Es bedeutet, dass sie besser für die wiederholte Generalprobe von anormalen Zuständen geeignet ist.

Programmierung des First-Out-Alarms

Verlorenes Feedback sollte keine vage Alarmflut erzeugen. Es sollte eine diagnostisch nützliche First-Out-Anzeige erzeugen, die dem Bediener oder Ingenieur mitteilt, was zuerst ausgefallen ist und was das Steuerungssystem als Nächstes getan hat.

Ein praktisches First-Out-Muster beinhaltet:

• Signalvaliditätsprüfung,
• Ausfall-Timer oder Entprellung,
• Trip- oder Fallback-Zustand,
• verriegeltes First-Out-Alarm-Bit,
• und eine bedienerorientierte Meldung, die mit dem ursprünglichen Fehler verknüpft ist.

Im Simulationsmodus von OLLA Lab können Benutzer einen Eingabefehler mitten im Zyklus umschalten oder erzwingen und dann verifizieren, ob die Ladder-Logik:

• den Signalverlust erkennt,
• eine unsichere Fortsetzung verhindert,
• den korrekten Alarm verriegelt,
• und das Anlagenmodell in einen sicheren Zustand überführt.

Wenn der Digital-Twin Überlauf, Kavitation oder unkontrollierte Fortsetzung zeigt, ist die Logik noch nicht defensiv. Die Maschine ist ehrlich bezüglich des Codes.

Man programmiert sie, indem man auf Diskrepanzen zwischen befohlenem Zustand und nachgewiesenem Zustand prüft. Mechanisches Haften, Klemmen oder Nicht-Bewegen ist ein klassisches Problem bei der Inbetriebnahme, da die PLC glauben könnte, der Befehl sei erfolgreich gewesen, während die Maschine physisch feststeckt.

Hier zahlt sich die Proof-Logik aus. Wenn ein Ausgang angesteuert wird und das erwartete Feedback nicht innerhalb eines definierten Zeitfensters eintrifft, sollte das System einen Alarm auslösen, die weitere Sequenzfortschaltung verhindern und in einen sicheren oder bekannten Zustand übergehen.

Ein Standardmuster ist der Bewegungsprüfungs-Timer (Proof-of-Movement Timer).

Der Bewegungsprüfungs-Timer

Das folgende Ladder-Beispiel drückt eine einfache, aber wichtige Regel aus:

• Befehle das Ventil,
• erlaube ein angemessenes Bewegungsfenster,
• und wenn das Feedback nie eintrifft, erkläre einen Fehler.

Eine repräsentative Implementierung ist:

• Aktiviere `Valve_Command`
• Starte `TON Valve_Feedback_Timer` mit einem Preset von `5000 ms`
• Wenn `Valve_Feedback_Timer.DN` wahr ist und `Valve_Open_Limit_Switch` immer noch falsch ist, verriegele `Valve_Stuck_Alarm`

In OLLA Lab kann der Ingenieur den Befehl simulieren, das erwartete Feedback zurückhalten oder deaktivieren und sowohl den Übergang des Ladder-Zustands als auch die Reaktion der 3D-Anlage beobachten. Das ist materiell etwas anderes, als den Code zu lesen und anzunehmen, er sei ausreichend.

Was sollte die defensive Logik nach dem Prüffehler tun?

Der Timer-Alarm allein reicht nicht aus. Eine Reaktion auf Inbetriebnahmeklasse beinhaltet normalerweise eine Kombination aus:

• Stoppen des Sequenzfortschritts,
• Abschalten abhängiger Ausgänge,
• Verriegeln eines Fehlerzustands,
• Anzeigen einer klaren Alarmmeldung,
• und Erfordernis eines Eingreifens durch Bediener oder Wartung vor dem Reset.

Die genaue Reaktion hängt von der Prozessgefahr, dem mechanischen Design und der Steuerungsphilosophie ab. Eine klemmende Klappe in der HLK ist kein fehlgeschlagenes Absperrventil an einer Chemieanlage. Ähnliches Muster, unterschiedliche Konsequenzen.

„Simulationsbereit“ sollte nicht als vages Kompliment verwendet werden. Operativ bedeutet es, dass ein Ingenieur Steuerungslogik gegen realistisches Anlagenverhalten beweisen, beobachten, diagnostizieren und härten kann, bevor sie einen realen Prozess erreicht.

Diese Definition hat beobachtbare Komponenten. Ein simulationsbereiter Ingenieur kann:

• Ladder-Tags auf simuliertes Anlagenverhalten mappen,
• anormale Bedingungen gezielt einbringen,
• erklären, was „korrekt“ bedeutet, bevor getestet wird,
• Diskrepanzen zwischen Befehl und Nachweis identifizieren,
• Logik nach einem Fehler überarbeiten,
• und verifizieren, dass die überarbeitete Logik sowohl die Tag-Zustände als auch die Anlagen-Zustände ändert.

Dies ist der Unterschied zwischen dem Wissen um Ladder-Syntax und der Fähigkeit, einsatzfähiges Steuerungsverhalten zu validieren. Das eine ist notwendig. Das andere ist das, was bei der Inbetriebnahme zählt.

In OLLA Lab wird diese operative Bereitschaft unterstützt durch:

• einen webbasierten Ladder-Logik-Editor mit Standard-Anweisungstypen,
• einen Simulationsmodus zum sicheren Ausführen und Stoppen von Logik,
• ein Variablen-Panel für I/O-Sichtbarkeit, Analogwerte und erzwungene Bedingungen,
• 3D/WebXR/VR-Anlagenmodelle zur Zustandsbeobachtung,
• szenariobasierte Übungen mit Gefahren, Interlocks und Inbetriebnahme-Notizen,
• und geführte Unterstützung durch GeniAI, den KI-Laborassistenten, für Onboarding und Korrekturhilfe.

Der Produktanspruch sollte begrenzt bleiben: OLLA Lab ist eine Proben- und Validierungsumgebung für risikoreiche Inbetriebnahmetätigkeiten. Es ist kein Ersatz für Standortverfahren, formale Kompetenzbewertung, SIL-Verifizierung oder anlagenspezifische Autorisierung.

Sie sollten einen kompakten Korpus an technischem Nachweis dokumentieren, keine Galerie von Screenshots. Ein Screenshot kann zeigen, dass ein Simulator existierte. Er kann nicht zeigen, dass der Ingenieur verstand, was validiert wurde.

Verwenden Sie diese Struktur:

Spezifizieren Sie, was korrektes Verhalten in beobachtbaren Begriffen bedeutet: erfüllte Permissive, Ausgangsübergänge, Alarmbedingungen, Trip-Schwellenwerte, Sequenz-Timing und Verhalten im sicheren Zustand.

Geben Sie genau an, was erzwungen wurde: verlorenes analoges Feedback, negativer Sollwert, fehlgeschlagener Prüfschalter, verzögerte Bewegung oder Sequenz-Fehlanpassung.

Dokumentieren Sie die Logikänderung: Watchdog-Timer, Clamp, First-Out-Verriegelung, Permissive, Komparator, Timeout oder Reset-Bedingung.

1. Systembeschreibung Definieren Sie die Prozesseinheit, Maschine oder Anlage, die gesteuert wird. Geben Sie die wichtigsten I/O, den Zweck der Sequenz und den Betriebskontext an.
2. Operative Definition von „korrekt“
3. Ladder-Logik und simulierter Anlagenzustand Präsentieren Sie den relevanten Ladder-Abschnitt und das entsprechende Anlagenverhalten in der Simulation. Zeigen Sie die Beziehung zwischen Tag-Zustand und physischem Zustand.
4. Der eingebrachte Fehlerfall
5. Die vorgenommene Überarbeitung
6. Gelernte Lektionen Erklären Sie, was die ursprüngliche Logik übersah, was die überarbeitete Logik nun abfängt und welche restlichen Annahmen bestehen bleiben.

Dieses Format ist stärker, weil es technisches Denken unter Fehlerbedingungen demonstriert. Arbeitgeber und Prüfer benötigen Beweise, dass der Kandidat klar denken kann, wenn der Prozess aufhört, sich normal zu verhalten.

Die Basis der Standards ist unkompliziert: Funktionale Sicherheit und Lebenszyklus-Validierung erfordern Aufmerksamkeit für anormale Bedingungen, Fehlerreaktion und diagnostisches Verhalten, nicht nur für den beabsichtigten Betrieb.

Relevante Ankerpunkte sind:

• IEC 61508 für Konzepte des Lebenszyklus funktionaler Sicherheit über elektrische, elektronische und programmierbare Systeme hinweg
• IEC 61511 für sicherheitstechnische Systeme in der Prozessindustrie
• FMEDA-Praxis, wie sie in der Zuverlässigkeits- und Diagnoseanalyse verwendet wird, um über Fehlermodi und Erkennungsabdeckung nachzudenken
• Literatur zu Digital-Twins, virtueller Inbetriebnahme und simulationsbasiertem Training zur Verbesserung der Validierungseffizienz und der Vorbereitung von Bedienern oder Ingenieuren

Die begrenzte Schlussfolgerung ist, dass Simulation und Digital-Twins besonders nützlich sind, wo physische Fehlerinduktion unsicher, unpraktisch oder zu teuer zu wiederholen ist. Das ist ein starker technischer Anwendungsfall. Er erfordert keine übertriebenen Behauptungen über Immersion.

OLLA Lab passt an den Punkt, an dem Ingenieure Ladder-Logik gegen realistisches Anlagenverhalten bauen, testen, beobachten und überarbeiten müssen, bevor die reale Inbetriebnahme die Kosten eines vermeidbaren Fehlers absorbiert.

Operativ unterstützt die Plattform:

• das Erstellen von Ladder-Logik in einem browserbasierten Editor,
• das Simulieren der Logikausführung ohne physische Hardware,
• das Überwachen von I/O, Variablen, Analogwerten und PID-bezogenem Verhalten,
• das Validieren von Logik gegen 3D- oder WebXR-Digital-Twins,
• und das Durcharbeiten realistischer industrieller Szenarien in den Bereichen Wasser, HLK, Fertigung, Versorgung und Prozesssysteme.

Das macht es geeignet für das Üben von Aufgaben, die teuer sind, wenn man sie zum ersten Mal auf einer realen Anlage lernt:

• Umgang mit verlorenem Feedback,
• Ablehnung von Befehlen außerhalb des Bereichs,
• Fehler bei der Bewegungsprüfung,
• Interlock-Validierung,
• Alarm-Sequenzierung,
• und defensive Überarbeitung nach einem Fehler.

Das ist das glaubwürdige Wertversprechen. Keine Magie. Keine sofortige Expertise. Wiederholung unter kontrollierten Fehlerbedingungen ist meist weniger glamourös als Marketing-Texte, aber sie kommt dem näher, wie Kompetenz aufgebaut wird.

Hochinteraktive Fehleranalyse ist das disziplinierte Testen, wie sich PLC-Logik verhält, wenn der Prozess aufhört zu kooperieren. Dazu gehören fehlerhafte Eingaben, fehlendes Feedback, nicht bewegliche Aktoren und Sequenzfehler, die in sauberen Demo-Fällen nicht vorkommen.

WebXR- und VR-Digital-Twins sind in diesem Kontext nützlich, weil sie eine risikofreie Fehler-Injektionsumgebung bieten, in der Ingenieure die physische Konsequenz fehlerhafter Logik beobachten, diese überarbeiten und erneut testen können. Die entscheidende Unterscheidung ist einfach: Logik zeichnen versus Verhalten validieren.

Ein simulationsbereiter Ingenieur ist nicht die Person, die erklären kann, was ein Timer tut. Es ist die Person, die zeigen kann, was passiert, wenn der Timer das Einzige ist, was zwischen einem Befehl und einem Fehler steht.

- WebXR Device API (W3C Candidate Recommendation Draft) - NIST AI Risk Management Framework (AI RMF 1.0) - IEC 61508 Functional safety overview - IFAC-PapersOnLine journal homepage - MDPI Sensors journal homepage