Überwachung von Echtzeit-SPS-E/A mit Cloud-nativer Beobachtbarkeit in OLLA Lab

Die Echtzeit-Überwachung von SPS-E/A hängt von der synchronen Sichtbarkeit der Zustände ab, nicht nur von einem Ladder-Editor. In OLLA Lab zentralisiert das Variablen-Panel diskrete Tags, Analogwerte und PID-Zustände in einer browserbasierten Ansicht. Dadurch können Benutzer Kausalitäten nachverfolgen, Fehler injizieren und das Steuerungsverhalten validieren, ohne auf separate lokale Tag-Datenbanken oder temporäre HMIs angewiesen zu sein.

E/A-Beobachtbarkeit ist nicht dasselbe wie eine geöffnete Tag-Liste auf einem zweiten Bildschirm. Operativ bedeutet es, Zustandsänderungen, Variablenbeziehungen und Steuerungsreaktionen schnell genug zu sehen, um Kausalitäten während der laufenden Logik zu diagnostizieren.

Diese Unterscheidung ist wichtig, da viele Fehler in der Ladder-Logik keine Syntaxfehler sind. Es handelt sich um Fehler bei der Zustandssichtbarkeit: eine versteckte Freigabe, ein veralteter Analogwert, eine verpasste Verriegelung oder ein Fehlerbit, das sich änderte und verschwand, bevor die Bedieneransicht es erfassen konnte. Wenn Sie die Zustandsänderung nicht sehen können, können Sie den Fehler nicht diagnostizieren.

Während interner Benchmark-Tests bei Ampergon Vallis identifizierten Ingenieure, die das einheitliche Variablen-Panel von OLLA Lab nutzten, vordefinierte Race-Condition- und Freigabeketten-Fehler dreimal schneller als Benutzer, die zwischen einem lokalen VM-Simulator, einem separaten Tag-Monitor und einer temporären HMI-Ansicht wechselten. Die Zustandsdarstellung erfolgte dabei mit einem konsistenten UI-Aktualisierungsintervall von 16 ms im Browser. Methodik: n=18 Benutzer; Aufgabenstellung = Diagnose von vier vordefinierten Ladder-Logik-Fehlerfällen mit diskreten, analogen und Freigabezustandsfehlern; Basisvergleich = lokaler Workflow mit virtueller Maschine, separater Tag-Datenbank/HMI; Zeitfenster = interner Testzyklus Februar 2026. Dies stützt eine begrenzte Aussage über die Fehlerdiagnosegeschwindigkeit in diesem Versuchsaufbau. Es beweist keine universelle Überlegenheit über alle SPS-Software-Stacks oder Live-Anlagenbedingungen hinweg.

E/A-Beobachtbarkeit ist entscheidend, da die Korrektheit der Ladder-Logik eine Laufzeitfrage ist, nicht nur eine Frage der Diagrammerstellung. Ein Netzwerk kann vollkommen vernünftig aussehen und dennoch bei tatsächlichen Zustandsübergängen, Zeitabhängigkeiten, analogen Schwellenwerten oder Verriegelungsbedingungen versagen.

Dies ist der praktische Unterschied zwischen Syntax und Implementierbarkeit. Die Syntax sagt Ihnen, ob die Logik strukturell gültig ist. Die Beobachtbarkeit sagt Ihnen, ob sich die Maschine, der Prozess oder die Sequenz wie beabsichtigt verhält, wenn sich Eingänge bewegen, Timer ablaufen, Analogwerte driften und Fehler eingeführt werden.

Ein nützlicher operativer Begriff ist hier die Zustandsdivergenz. Zustandsdivergenz tritt auf, wenn das beabsichtigte Steuerungsverhalten und das beobachtete Systemverhalten nicht mehr übereinstimmen, weil eine oder mehrere relevante Variablen verborgen, veraltet oder nicht im Kontext überwacht werden. Eine Motorfreigabe kann falsch sein, während der Startbefehl wahr ist. Ein Regelkreis kann sättigen, während die diskrete Sequenz noch gesund erscheint. Eine Rückmeldung kommt möglicherweise nie an, aber die reine Netzwerkansicht verrät Ihnen nicht, warum.

IEC 61131-3 bietet das Programmiermodell für Variablen, Datentypen und Steuerungsstrukturen, die in industriellen Steuerungen verwendet werden, aber die Laufzeitvalidierung hängt immer noch davon ab, diese Variablen unter Ausführungsbedingungen zu beobachten, anstatt sie nur korrekt zu deklarieren (IEC, 2013). Der Standard gibt Ihnen die Sprache. Er beseitigt nicht die Notwendigkeit für Sichtbarkeit.

Dies ist auch der Punkt, an dem "Simulation-Ready" eine präzise Definition benötigt. In der Verwendung bei Ampergon Vallis ist ein "Simulation-Ready"-Ingenieur nicht einfach jemand, der Ladder-Syntax schreiben kann. Es bedeutet, dass jemand in der Lage ist, Steuerungslogik zu beweisen, zu beobachten, zu diagnostizieren und gegen realistisches Prozessverhalten abzusichern, bevor sie einen Live-Prozess erreicht. Das ist eine Definition für die Inbetriebnahme, kein Marketing-Adjektiv.

Das Variablen-Panel von OLLA Lab ersetzt die fragmentierte Tag-Überwachung, indem es Ladder-Ausführung, Variableninspektion und Eingabemanipulation in einem browserbasierten Arbeitsablauf zusammenführt. Der Punkt ist nicht die ästhetische Konsolidierung. Der Punkt ist eine schnellere kausale Diagnose.

In vielen herkömmlichen Schulungs- und Simulationsaufbauten müssen Benutzer zwischen folgenden Elementen wechseln:

• dem Ladder-Editor,
• einer separaten Tag-Datenbank oder einem Beobachtungsfenster,
• einem kompilierten oder temporären HMI,
• und manchmal einer zusätzlichen Trend- oder Analogansicht.

Dieser Arbeitsablauf ist vertraut, aber Vertrautheit ist nicht gleich Effizienz. Jeder Kontextwechsel erhöht die Wahrscheinlichkeit, dass ein transienter Zustand übersehen oder falsch interpretiert wird.

In OLLA Lab ist das Variablen-Panel als eine auf der rechten Seite angeordnete Laufzeit-Inspektionsebene konzipiert, die direkt mit dem Simulationsverhalten verknüpft ist. Es bietet Sichtbarkeit für:

• diskrete Eingänge und Ausgänge,
• Tag-Zustände,
• Analog-Tools und Vorgabewerte,
• PID-relevante Variablen,
• szenariospezifische Mappings,
• und wählbare Simulationsbedingungen.

Hier wird OLLA Lab operativ nützlich.

Kernfunktionen des OLLA Lab Variablen-Panels

Benutzer können diskrete Eingänge wie Drucktasten, Endschalter, Freigaben oder Not-Aus-Zustände im Simulationsmodus umschalten, ohne die zugrunde liegende Ladder-Logik neu schreiben zu müssen.

• Live-Boolean-Forcing

Benutzer können Analogwerte anpassen, um Skalierung, Komparatorverhalten, Alarmschwellen und Prozessreaktionen zu testen. Dies ist wichtig, da viele Steuerungsfehler eher als leicht falsches Analogverhalten beginnen und nicht als dramatische diskrete Fehler.

• Analogsignal-Injektion

Benutzer können Prozessvariable, Sollwert und steuerungsrelevante Werte inspizieren, während sie das Ladder-Verhalten beobachten. Das hält das Regelkreisverhalten und die Sequenzlogik im selben Diagnosefenster.

• PID-Dashboard-Sichtbarkeit

Das Panel ordnet Tags dem ausgewählten industriellen Szenario zu und hilft Benutzern, nicht nur den Variablennamen, sondern auch dessen Rolle im Prozessmodell zu verstehen.

• Szenario-Tag-Mapping

Benutzer können ein Netzwerk beobachten, einen Eingang forwing, den Ausgang beobachten und verwandte Variablen inspizieren, ohne eine separate HMI-Ebene aufbauen zu müssen, nur um eine grundlegende Diagnosefrage zu beantworten.

• Kausalitätsverfolgung in einer Ansicht

Ein kompiliertes HMI ist nützlich, wenn Sie eine Visualisierung im Bedienerkontext benötigen. Es ist ein schlechter Ersatz für die technische Diagnose während der frühen Validierung.

Cloud-native Beobachtbarkeit bedeutet nicht nur, dass die Software in einem Browser läuft. Operativ bedeutet es, dass die Simulation und die Benutzeroberfläche entkoppelt sind, sodass die Logikausführung serverseitig erfolgen kann, während der Client Zustandsaktualisierungen effizient genug empfängt, um eine nützliche Laufzeitsichtbarkeit zu gewährleisten.

Für diesen Artikel bedeutet Cloud-native Beobachtbarkeit:

• die Ladder-Logik-Simulation wird in einer Cloud-gehosteten Umgebung ausgeführt,
• Zustandsänderungen werden als leichtgewichtige Datenaktualisierungen an den Browser übertragen,
• und der Browser stellt diese Änderungen in einer einheitlichen Schnittstelle zur Überwachung und Interaktion dar.

Die relevante technische Unterscheidung ist entkoppelte Simulation versus lokaler Monolith. In einem lokalen monolithischen Aufbau konkurrieren Editor, Simulator, Beobachtungsfenster und oft die virtualisierte Betriebsumgebung um dieselben Workstation-Ressourcen. In einem entkoppelten Modell rendert und interagiert der Browser primär, während die schwerere Simulationsarbeit an anderer Stelle erledigt wird.

Der Quellentwurf verweist auf die Zustandsübermittlung im WebSocket-Stil und die Effizienz von JSON-Payloads als architektonische Grundlage für Echtzeit-Updates. Das ist ein plausibles und technisch kohärentes Modell für die latenzarme Zustandssynchronisation in browserbasierten Systemen. Die begrenzte Aussage hier ist architektonisch: effizienter Zustandstransport und Client-Rendering können die UI-Verzögerung und den Polling-Aufwand reduzieren, die oft in lokalen VM-basierten Schulungsumgebungen zu sehen sind.

Warum sich lokale VM-Workflows oft langsamer anfühlen

Lokale virtuelle Simulationsumgebungen fühlen sich oft langsamer an, weil sie mehrere Lasten auf eine Host-Maschine stapeln:

• IDE-Rendering,
• Simulationsausführung,
• Overhead des Gastbetriebssystems,
• Aktualisierung des Beobachtungsfensters,
• und manchmal HMI-Rendering.

Wenn die CPU- oder RAM-Zuweisung knapp ist, ist das erste Symptom oft kein Absturz. Es ist eine Zeitabweichung. Die Schnittstelle bewegt sich zwar noch, aber nicht im gleichen Tempo wie die zugrunde liegenden Zustandsänderungen.

### Technische Unterscheidung: Lokale VM-Emulation vs. browserbasiertes Modell von OLLA Lab

| Dimension | Lokale VM-Emulation | OLLA Lab Browser-Modell | |---|---|---| | Rechenlast | Geteilt mit Host-CPU/RAM und Gast-OS-Overhead | Simulationslast wird in Cloud-Umgebung verarbeitet | | UI-Verhalten | Anfälliger für Ruckeln bei hoher lokaler Last | Browser rendert Zustandsupdates in einem einheitlichen Panel | | Tag-Sichtbarkeits-Workflow | Oft aufgeteilt auf Beobachtungstabellen, Tag-Datenbanken oder temporäre HMIs | Zentralisiert in einem Variablen-Panel | | Zustandsupdate-Muster | Kann von lokalem Polling, Aktualisierungsverhalten oder VM-Reaktionsfähigkeit abhängen | Entwickelt für kontinuierliche Zustandsübermittlung an den Client | | Einrichtungsaufwand | Höher, besonders für Lernende oder verteilte Teams | Webbasierter Zugriff reduziert lokale Installation und VM-Abhängigkeit | | Diagnosefluss | Mehr Kontextwechsel | Direktere Ursache-Wirkungs-Verfolgung |

Dieser Vergleich ist eine Workflow-Unterscheidung, keine universelle Verurteilung von Desktop-Engineering-Tools. Ausgereifte lokale Plattformen haben nach wie vor ihre Berechtigung. Die Frage ist, ob sie effizient für das Lehren und Üben der Laufzeitdiagnose sind.

Sie überwachen sie effektiv, indem Sie sie im selben kausalen Rahmen halten. Separate Fenster erzeugen separate mentale Modelle, und genau dort beginnt die Qualität des Debuggings zu sinken.

In OLLA Lab soll das Variablen-Panel Benutzern ermöglichen, Folgendes zu inspizieren:

• Boolean-Zustände wie Freigaben, Befehle, Auslösungen und Rückmeldesignale,
• Analogwerte wie Füllstand, Druck, Durchfluss oder Temperatursurrogate,
• Komparatoren und Schwellenwerte, die mit Alarm- oder Sequenzentscheidungen verknüpft sind,
• PID-relevante Werte wie Sollwert, Prozessvariable und Steuerungsreaktion,
• und szenariospezifische Tags, die mit der aktiven simulierten Ausrüstung verbunden sind.

Das ist wichtig, da echte Fehler oft Kategoriegrenzen überschreiten. Eine Pumpe startet möglicherweise nicht, weil eine diskrete Freigabe falsch ist. Sie startet möglicherweise auch nicht, weil eine analoge Füllstandsbedingung die Freigabeschwelle nicht überschritten hat. Oder sie startet und löst dann aus, weil die erwartete Rückmeldung nicht zurückkehrt. Das Ladder-Diagramm allein erzählt selten die ganze Geschichte.

Eine kompakte Überwachungssequenz

Eine disziplinierte Überwachungssequenz sieht normalerweise so aus:

1. Befehlspfad bestätigen Überprüfen Sie, ob der initiierende Eingang oder das Sequenzbit tatsächlich wahr ist.
2. Freigaben und Verriegelungen prüfen Inspizieren Sie alle blockierenden Bedingungen, bevor Sie annehmen, dass die Ausgangslogik falsch ist.
3. Befehlsausgang beobachten Stellen Sie fest, ob die Steuerung den Ausgang überhaupt ausgibt.
4. Mit simuliertem Ausrüstungszustand vergleichen Prüfen Sie, ob die virtuelle Ausrüstung wie erwartet reagiert.
5. Analogen Kontext inspizieren Überprüfen Sie, ob Schwellenwerte, Skalierung oder Regelkreiswerte die Sequenz beeinflussen.
6. Fehler- und Alarmbits überprüfen Suchen Sie nach verriegelten Auslösungen, fehlgeschlagenen Rückmeldungen oder Flags für anormale Zustände.

Das ist grundlegende Inbetriebnahmedisziplin. Es sieht nur einfach aus, nachdem jemand den Fehler bereits gefunden hat.

Sie forcen Eingänge und simulieren Fehler, indem Sie Laufzeitvariablen im Simulationsmodus ändern und dann beobachten, wie die Ladder-Logik und die simulierte Ausrüstung reagieren. Der Zweck ist nicht, es zur Unterhaltung scheitern zu lassen. Der Zweck ist zu testen, ob die Steuerungsstrategie korrekt mit anormalen Bedingungen umgeht.

Ein einfaches Beispiel ist eine Motorverriegelung mit einer Not-Aus-Freigabe:

// Standard-Verriegelung mit Not-Aus-Freigabe |---[ E_STOP_OK ]---[ START_PB ]-------( MOTOR_RUN )---| | | |---[ MOTOR_RUN ]--------------------------------------|

Unter normalen Bedingungen:

• `E_STOP_OK = TRUE`
• `START_PB = TRUE` kurzzeitig
• `MOTOR_RUN` schaltet ein und hält sich selbst

Unter Fehlerinjektionsbedingungen:

• forcen Sie `E_STOP_OK = FALSE`
• beobachten Sie, ob `MOTOR_RUN` sofort abfällt
• bestätigen Sie, ob sich ein zugehöriger Alarm, Fehler oder Rücksetzzustand wie beabsichtigt verhält

Bild-Alt-Text: Screenshot des Simulators mit dem OLLA Lab Variablen-Panel. Das Boolean-Tag `E_STOP_OK` wird im rechten Menü manuell auf "false" gesetzt, wodurch die `MOTOR_RUN`-Spule im aktiven Ladder-Netzwerk sofort abfällt.

Was ein nützlicher Fehlertest verifizieren sollte

Ein nützlicher simulierter Fehlertest sollte mehr als nur ein Netzwerkergebnis verifizieren. Er sollte mindestens folgende Fragen beantworten:

• Ist der Ausgang abgefallen, als die Freigabe fehlte?
• Ist der Zustand der simulierten Ausrüstung dem Logikzustand gefolgt?
• Hat ein erwartetes Alarm- oder Auslösebit angesprochen?
• Hat die Sequenz korrekt angehalten, zurückgesetzt oder übergegangen?
• War das Wiederherstellungs- oder Rücksetzverhalten des Bedieners konsistent mit der Steuerungsphilosophie?

Das ist der Unterschied zwischen dem Forcen eines Tags und der Validierung einer Steuerungsreaktion. Das eine ist ein Klick. Das andere ist Ingenieursarbeit.

Realistische Szenarien verbessern die Überwachungsqualität, da Tags eine prozessuale Bedeutung erhalten. Eine Tag-Liste ohne Ausrüstungskontext lehrt Benennung. Ein Szenario lehrt Kausalität.

OLLA Lab enthält szenariobasierte Simulationen in Bereichen wie Fertigung, Wasser- und Abwasserwirtschaft, HLK, Chemie, Pharma, Lagerhaltung, Lebensmittel und Getränke sowie Versorgungsunternehmen. Der Wert dieser Breite ist keine dekorative Vielfalt. Verschiedene Szenarien legen unterschiedliche Steuerungsmuster offen:

• Leit-/Folge-Pumpenlogik,
• Förderbandsequenzierung,
• Lüftungsfreigabeketten,
• Alarmkomparatoren,
• Rückmeldeketten,
• Analogskalierung,
• und PID-abhängiges Prozessverhalten.

Ein Pumpwerk lehrt zum Beispiel füllstandsbasierte Starts, Leit-/Folge-Wechsel, Alarmschwellen und Pumpenrückmeldelogik. Ein Förderbandszenario lehrt Zoneneinteilung, Stauerkennung, Sequenzierung und Verriegelungen. Ein RLT-Szenario führt Freigabeketten, Sicherheitseinrichtungen und analoge Prozessreaktionen ein. Gleiche Sprachfamilie, unterschiedliche Fehlergewohnheiten.

Deshalb ist die Validierung mit digitalen Zwillingen in einem begrenzten Sinne wichtig. Hier bedeutet Validierung mit digitalen Zwillingen das Testen von Ladder-Logik gegen eine realistische virtuelle Maschine oder ein Prozessmodell, um das beabsichtigte Steuerungsverhalten mit der simulierten Ausrüstungsreaktion zu vergleichen, bevor eine Live-Implementierungsentscheidung getroffen wird. Es bedeutet nicht, dass der Simulator ein zertifizierter Ersatz für die Standortabnahmeprüfung (SAT), die funktionale Sicherheitsverifizierung oder die Anlageninbetriebnahme ist.

Das Variablen-Panel bereitet Ingenieure auf die Inbetriebnahme vor, indem es sie trainiert, in Systemen zu denken, nicht in isolierten Netzwerken. Inbetriebnahmearbeit hängt davon ab, Ursache und Wirkung über Logik, E/A, Ausrüstungsreaktion, Alarme und den Umgang mit anormalen Zuständen hinweg zu verfolgen.

Diese Denkweise ist erlernbar, benötigt aber die richtige Umgebung. Einsteigende Ingenieure dürfen aus offensichtlichen Gründen selten risikoreiche Fehler an Live-Systemen üben.

Richtig eingesetzt, bietet OLLA Lab Benutzern einen Ort, um Aufgaben zu üben, die an echter Ausrüstung teuer oder riskant sind:

• Validierung der Logik vor der Implementierung,
• Überwachung von E/A-Beziehungen,
• Verfolgung versteckter Freigaben,
• Injizieren von Fehlern,
• Überarbeitung der Logik nach anormalem Verhalten,
• Vergleich des Ladder-Zustands mit dem Zustand der simulierten Ausrüstung.

Das ist eine glaubwürdige Vorbereitung auf die Ingenieursarbeit. Es ist keine Abkürzung zur Kompetenz.

Wie man technische Nachweise statt einer Screenshot-Galerie erstellt

Wenn ein Lernender oder Junior-Ingenieur echtes Können demonstrieren möchte, sollte das Ergebnis ein kompakter technischer Nachweis sein. Verwenden Sie diese Struktur:

Geben Sie an, was korrektes Verhalten in beobachtbaren Begriffen bedeutet: Sequenzreihenfolge, Freigaben, Alarme, Timing, analoge Schwellenwerte und Wiederherstellungsverhalten.

Identifizieren Sie die eingeführte anormale Bedingung: fehlgeschlagene Freigabe, falsche Rückmeldung, analoge Abweichung, Not-Aus-Verlust, Sensorfehler oder Sequenzunterbrechung.

1. Systembeschreibung Definieren Sie den simulierten Prozess oder die Maschine, ihren Zweck und die relevanten E/A.
2. Operative Definition von "korrekt"
3. Ladder-Logik und Zustand der simulierten Ausrüstung Zeigen Sie die Ladder-Logik und die entsprechende Reaktion der simulierten Maschine oder des Prozesses.
4. Der injizierte Fehlerfall
5. Die vorgenommene Überarbeitung Dokumentieren Sie die Logikänderung, Schwellenwertanpassung, Verriegelungskorrektur oder Sequenzmodifikation, die als Reaktion vorgenommen wurde.
6. Gelernte Lektionen Erklären Sie, was das Versagen über die Steuerungsphilosophie, das E/A-Mapping, Timing-Annahmen oder die Fehlerbehandlung enthüllt hat.

Dieses Artefakt ist glaubwürdiger als ein Ordner voller Screenshots. Arbeitgeber und Prüfer benötigen Nachweise für das logische Denken, nicht nur Bilder.

Die stärkste Unterstützung für diesen Ansatz kommt aus einer Kombination von SPS-Programmierstandards, funktionaler Sicherheitspraxis und Literatur zu simulationsbasiertem Engineering und durch digitale Zwillinge unterstützter Validierung.

Relevante Standards und technische Anker

• IEC 61131-3 definiert weit verbreitete SPS-Programmiersprachen und Variablenstrukturen, was die Überwachung des Laufzeitzustands zentral für das Debugging und die Validierung macht (IEC, 2013).
• IEC 61508 rahmt funktionale Sicherheit um systematische Integrität, Verifizierung und Lebenszyklusdisziplin ein. Simulation ist in diesem Workflow nützlich, ersetzt aber nicht die formale Sicherheitsvalidierung oder Feldverifizierung (IEC, 2010).
• exida und verwandte Sicherheitsexperten betonen konsequent den Nachweis, die Verifizierungsdisziplin und die Unterscheidung zwischen Designabsicht und demonstriertem Verhalten in Automatisierungs- und Sicherheitssystemen.
• Literatur zu digitalen Zwillingen und Simulation in Fachzeitschriften wie Sensors, Manufacturing Letters und IFAC-PapersOnLine unterstützt den Wert modellbasierter Validierung, virtueller Inbetriebnahme und früherer Fehlererkennung, merkt aber auch an, dass Modelltreue und Umfangsgrenzen wichtig sind.

Das begrenzte Fazit ist einfach: simulationsbasierte Beobachtbarkeit kann die Validierungsqualität verbessern, wenn sie Ingenieuren ermöglicht, Laufzeitverhalten zu beobachten, Logik mit Prozessreaktionen zu vergleichen und anormale Bedingungen frühzeitig zu testen. Sie beseitigt nicht die Notwendigkeit für Hardware-Validierung, Standortinbetriebnahme oder Verpflichtungen im Sicherheitslebenszyklus.

- IEC 61508 Überblick über funktionale Sicherheit - IEC 61131-3 Programmiersprachen für speicherprogrammierbare Steuerungen - 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