Der Latenz-Mythos: Wie die Cloud-Engine von OLLA Lab SPS-Zykluszeiten im Browser schützt

OLLA Lab reduziert die praktische Simulationslatenz durch die Trennung der browserseitigen Visualisierung von der serverseitigen Steuerungsausführung. Bei dieser Architektur bleibt das WebGL-Rendering lokal, während Kontaktplan-Logik, Tag-Zustandsauswertung und Simulationskoordination in der Cloud-Infrastruktur ausgeführt werden. Dies trägt dazu bei, den Determinismus der SPS-Zykluszeit vor lokaler CPU-Drosselung und Schwankungen der Workstation-Leistung zu schützen.

Latenz in der Automatisierungssimulation wird oft fälschlicherweise als Netzwerkproblem beschrieben. In der Praxis ist der schädlichere Fehlermodus meist eine lokale Timing-Verzerrung: Wenn ein Rechner gleichzeitig 3D-Szenen rendern, Zustandsänderungen verfolgen und Steuerungslogik nach Zeitplan ausführen soll, beginnt der Zyklus zu driften, sobald der Prozessor ausgelastet ist.

Diese Unterscheidung ist wichtig, denn ein verzögerter Frame ist ärgerlich; ein gestrecktes Steuerungsintervall kann den Test entwerten.

In einem internen Benchmark von Ampergon Vallis für eine Hochgeschwindigkeits-Verpackungssimulation zeigte eine lokale Workstation der i9-Klasse unter hoher Simulationslast eine Abweichung der Zykluszeit von 14 %, während OLLA Lab in derselben Testklasse ein stabiles Ausführungsintervall von 10 ms für ein Kontaktplan-Programm mit über 1.500 Sprossen aufrechterhielt. Methodik: n=12 wiederholte Durchläufe; Aufgabenstellung: Verpackungslinien-Sequenz mit aktiven Timern, Verriegelungen und dynamischen visuellen Szenen-Updates; Basis-Vergleich: lokale Workstation mit gemeinsam ausgeführter Logik und Visualisierung gegenüber OLLA Lab mit serverbasierter Logik und Browser-Visualisierung; Zeitfenster: März 2026. Dies stützt eine begrenzte Aussage über die Ausführungsstabilität unter diesem Benchmark-Design. Es beweist nicht per se eine universelle Überlegenheit über alle Hardwarekonfigurationen, Netzwerke oder Simulations-Stacks hinweg.

Lokale High-End-PCs haben Schwierigkeiten, weil SPS-Logikausführung und 3D-Simulation sich nicht wie die gleiche Art von Arbeitslast verhalten. SPS-Ausführung ist wertvoll, wenn sie deterministisch ist. Rendering und allgemeine Desktop-Aufgaben sind konstruktionsbedingt opportunistisch und variabel.

Ein lokaler Rechner, der alles gleichzeitig ausführt, wird zu einem schlechten Kompromiss gezwungen:

• Die Kontaktplan-Logik muss planmäßig ausgewertet werden,
• 3D- oder WebXR-Szenen erfordern stoßweise Grafik- und CPU-Ressourcen,
• Variablen-Tracking und UI-Updates erzeugen zusätzlichen Ereignisverkehr,
• das Betriebssystem plant weiterhin Hintergrundprozesse, ob erwünscht oder nicht.

Das Ergebnis ist nicht nur Langsamkeit. Der präzisere Begriff ist Zykluszeitverlängerung: Die Logikschleife benötigt länger als beabsichtigt, um abzuschließen, da Rechenressourcen zeitweise umkämpft sind.

Dies ist besonders relevant beim Testen von:

• schnellen Sequenzen,
• timerabhängigen Übergängen,
• Flankenerkennung,
• Race Conditions,
• analogem Antwortverhalten,
• PID-ähnlichem Regelverhalten,
• Fehlerbehandlung, die von Sequenz-Timings abhängt.

Eine Workstation kann auf dem Papier leistungsstark aussehen und dennoch der falsche Ort sein, um jede Rechenlast zu stapeln.

Was ist eine Verschlechterung der Zykluszeit (Scan-Cycle Degradation) operativ gesehen?

Die Verschlechterung der Zykluszeit ist die messbare Abweichung zwischen dem beabsichtigten Steuerungsausführungsintervall und dem tatsächlich erreichten Intervall während der Simulation.

Operativ ausgedrückt ist eine Simulation, die Logik alle 10 ms ausführen soll, verschlechtert, wenn:

• das Intervall wesentlich über den Zielwert driftet,
• der Drift von Zyklus zu Zyklus variiert,
• das Timer-Verhalten nicht mehr dem beabsichtigten Steuerungs-Timing entspricht,
• die Ereignisreihenfolge unter Last instabil wird,
• das Verhalten bei Fehlern oder Verriegelungen schwer konsistent zu reproduzieren ist.

Für die inbetriebnahmeorientierte Validierung ist Reproduzierbarkeit genauso wichtig wie Geschwindigkeit. Ein Test, der nicht unter denselben Timing-Bedingungen wiederholt werden kann, ist kein starker Beleg.

Warum ist thermische Drosselung bei der Steuerungsvalidierung wichtig?

Thermische Drosselung ist wichtig, weil lokale CPUs ihre Leistung reduzieren, wenn Hitze- oder Stromgrenzen erreicht werden, und diese Reduzierung das Timing-Verhalten der Simulation verändern kann.

Dies ist kein theoretischer Grenzfall bei Laptops und kompakten Desktops. Unter anhaltender gemischter Last – Grafik, Browser-Aktivität, Steuerungsausführung und physikähnliche Updates – takten Prozessoren oft herunter, um die Hardware zu schützen. Das ist sinnvolle Technik seitens des Geräts. Es ist weniger hilfreich, wenn Sie überprüfen möchten, ob ein Sequenzfehler aufgrund Ihrer Logik auftritt oder weil der Rechner, auf dem die Simulation läuft, warm geworden ist.

Für risikoreiche Validierungsaufgaben ist Timing-Rauschen keine kleine Unannehmlichkeit. Es ist eine Quelle für falsches Vertrauen.

OLLA Lab erreicht eine stabilere Ausführung durch die Entkopplung von Visualisierung und Steuerungsausführung. Der Browser übernimmt die Benutzeroberfläche und die visuelle Umgebung, während die Backend-Infrastruktur die Kontaktplan-Logik ausführt, den Zustand verwaltet und das Simulationsverhalten koordiniert.

Diese Architektur verändert das Problem. Anstatt einen lokalen Rechner gleichzeitig als SPS-Laufzeitumgebung, Grafik-Engine und Labor-Workstation zu fordern, verteilt OLLA Lab die Arbeit entsprechend der Art der Arbeitslast.

Was bedeutet „deterministisch“ in diesem Artikel?

In diesem Artikel bedeutet deterministisch nicht null Internet-Verzögerung und auch nicht eine perfekte Nachbildung jeder SPS-Laufzeitumgebung eines Herstellers.

Es bedeutet, dass die Steuerungslogik in ihrem definierten Intervall in einer verwalteten Backend-Umgebung ausgeführt wird, sodass:

• das Zyklus-Timing stabil genug für eine aussagekräftige Validierung bleibt,
• die Leistung des lokalen Geräts nur begrenzte Auswirkungen auf die Steuerungsausführung hat,
• das Logikverhalten unter konsistenten Bedingungen beobachtet und wiederholt werden kann,
• Sequenz-, Verriegelungs- und Fehlertests weniger wahrscheinlich durch die Rendering-Last des Browsers verzerrt werden.

Das ist der praktische Unterschied: Ping-Zeit versus Ausführungsintegrität. Sie hängen zusammen, sind aber nicht dasselbe Problem.

Die drei Schichten der Cloud-nativen Simulation in OLLA Lab

- Frontend-Schicht: Browser-Rendering und Interaktion

• Führt die Kontaktplan-Oberfläche, Variablenansichten und 3D/WebXR-Visualisierung im Browser aus.
• Nutzt lokale Grafikressourcen für Anzeige und Interaktion.
• Hält die benutzerseitige Erfahrung reaktionsfähig, ohne den Browser für die Steuerungs-Engine verantwortlich zu machen.

- Backend-Logikschicht: Kontaktplan-Ausführung und Tag-Zustandsverwaltung

• Führt die Kontaktplan-Logik remote aus.
• Verwaltet Tag-Wörterbücher, Zustandsübergänge und Anweisungsverhalten.
• Hilft, die Steuerungsausführung vor lokaler CPU-Konkurrenz und Gerätevariabilität zu schützen.

- Simulationskoordinationsschicht: Zustandssynchronisation

• Synchronisiert den Logikzustand mit dem simulierten Anlagenmodell und der Benutzeroberfläche.
• Unterstützt die Beobachtung von E/A-Änderungen, Analogwerten und Sequenzfortschritten.
• Ermöglicht es dem visuellen Modell, Zustandsänderungen der Steuerung widerzuspiegeln, ohne das lokale Gerät mit der gesamten Ausführungslast zu belasten.

Der praktische Vorteil ist die architektonische Trennung.

Ein „Simulation-Ready“-Ingenieur ist nicht einfach jemand, der Kontaktplan-Syntax schreiben kann. Ein „Simulation-Ready“-Ingenieur kann Steuerungslogik beweisen, beobachten, diagnostizieren und gegen realistisches Prozessverhalten absichern, bevor diese Logik einem Live-System ausgesetzt wird.

Operativ bedeutet das, dass der Ingenieur:

• definieren kann, was korrektes Maschinen- oder Prozessverhalten sein sollte,
• Kontaktplan-Zustände auf simulierte Anlagenzustände abbilden kann,
• E/A- und Tag-Übergänge während der Ausführung überwachen kann,
• anormale Bedingungen injizieren und die Reaktion beobachten kann,
• Logik nach einem Fehler oder einer Abweichung überarbeiten kann,
• verifizieren kann, dass das überarbeitete Verhalten der beabsichtigten Steuerungsphilosophie entspricht.

Dies ist die nützliche Unterscheidung: Syntax versus Einsatzfähigkeit.

OLLA Lab sollte innerhalb dieser Grenze verstanden werden. Es ist eine webbasierte Umgebung für Proben, Validierung und angeleitete Übungen in Kontaktplan-Logik, Simulation, Interaktion mit digitalen Zwillingen und Fehlerbehebung. Es ist keine Zertifizierung, keine SIL-Qualifizierung und kein Ersatz für beaufsichtigte Standortkompetenz.

Browserbasierte Simulation unterstützt die Validierung digitaler Zwillinge, wenn das Validierungsziel korrekt definiert ist. Das Ziel ist nicht, jede physikalische Nuance einer Anlage perfekt zu reproduzieren. Das Ziel ist zu testen, ob die Steuerungslogik korrekt gegenüber einem realistischen virtuellen Modell von Prozesszuständen, Sequenzen, Verriegelungen, Alarmen und bedienergesteuerten Änderungen reagiert.

Das ist eine engere und damit besser verteidigbare Behauptung.

In OLLA Lab ist die Validierung digitaler Zwillinge auf beobachtbare technische Verhaltensweisen begrenzt, wie zum Beispiel:

• Bestätigung, dass eine Startfreigabekette sich wie beabsichtigt verhält,
• Überprüfung, ob Rückmeldungen die korrekten Zustandsübergänge auslösen,
• Prüfung, ob ein Fehler den Neustart verhindert, bis Rücksetzbedingungen erfüllt sind,
• Beobachtung von analogen Schwellenwerten, Komparatorverhalten oder PID-bezogenen Reaktionen,
• Vergleich des Kontaktplan-Zustands mit dem simulierten Anlagenzustand während des normalen und anormalen Betriebs.

Dies ist besonders nützlich für Szenarien, die teuer, störend oder unsicher sind, um sie wiederholt an physischen Anlagen zu proben:

• Pumpen-Leit/Folge-Übergänge,
• Förder- oder Verpackungssequenzen,
• HLK-Anlagenzustände,
• Wasser- und Abwasserprozesslogik,
• Alarm- und Abschaltbehandlung,
• Not-Aus-Kettenreaktion,
• Neustart- und Wiederherstellungslogik.

Digitale Zwillinge sind dann am wertvollsten, wenn sie das technische Urteilsvermögen schärfen, nicht wenn sie als dekorativer Beweis für die Existenz eines 3D-Modells dienen.

Die JSON-Serialisierung verbessert die Benutzerfreundlichkeit des Simulators, indem sie den Projektzustand einfacher speicherbar, abrufbar, prüfbar und austauschbar macht als schwere binäre Projektformate.

Die Behauptung benötigt eine Grenze. JSON macht nicht auf magische Weise jedes System in jeder Hinsicht schneller. Es bietet jedoch praktische Vorteile für eine webbasierte Kontaktplan-Umgebung im Vergleich zur undurchsichtigen, binär-zentrierten Projekthandhabung.

Warum textbasierte Schemata in einer Browser-nativen Kontaktplan-Umgebung wichtig sind

Ein strukturiertes Textschema kann Folgendes unterstützen:

• schnellere Cloud-Speicher- und Abruf-Workflows,
• einfachere Zustandsübertragung zwischen Diensten,
• transparenteren Versionsvergleich,
• einfacheres Parsing für Plattformfunktionen,
• sauberere Integration mit KI-gestützten Leit- und Validierungswerkzeugen.

In einer Browser-nativen Umgebung sind diese Eigenschaften wichtig, da die Plattform ständig Folgendes koordiniert:

• Kontaktplan-Elemente,
• Tag-Metadaten,
• Variablenzustände,
• Szenario-Konfiguration,
• Analog-Bindungen,
• Anweisungskontext.

Klassische Desktop-IDE-Workflows wurden nicht für Cloud-Abruf, kollaborative Überprüfung oder KI-lesbare Strukturen entwickelt.

### Beispiel: ein einfacher Timer als strukturierte Daten

Ein einfacher Timer kann als strukturierte Daten mit Feldern für Sprossen-ID, Anweisungstyp, Tag-Name, Freigabebedingung, Zeitvorgabe und Ausgangszustände wie „Fertig“ und „abgelaufene Zeit“ dargestellt werden. Der Punkt ist nicht, dass JSON um seiner selbst willen elegant ist. Der Punkt ist, dass eine leichtgewichtige, strukturierte Darstellung einfacher durch ein Cloud-System zu bewegen ist als monolithische binäre Projektartefakte.

Cloud-Skalierbarkeit verbessert Proben, indem sie wiederholte, isolierte Testausführungen ermöglicht, ohne dass der lokale Rechner des Benutzers jede Rechenspitze abfangen muss.

Das ist am wichtigsten bei Tests unter anormalen Bedingungen, bei denen sich die Steuerungslogik bewähren muss.

In einer begrenzten Validierungsumgebung wie OLLA Lab können Benutzer Folgendes durcharbeiten:

• Verriegelungsfehler,
• Sensordiskrepanzen,
• Alarmschwellenwerte,
• Verlust von Rückmeldungen,
• Neustartsperren,
• Sequenzstillstände,
• analoge Ausreißer,
• Bediener-Rücksetzlogik.

Da die Steuerungsausführung nicht an das thermische und Planungsverhalten des lokalen Geräts gebunden ist, kann sich der Benutzer auf die technische Frage konzentrieren: Hat die Logik korrekt auf den anormalen Zustand reagiert?

Das ist die richtige Frage für die Inbetriebnahmeprobe.

Welche Arten von risikoreichen Aufgaben lohnen sich für Proben in OLLA Lab?

OLLA Lab ist am besten als Ort positioniert, um Aufgaben zu proben, die teuer oder riskant sind, um sie an Live-Anlagen zu erlernen:

• Validierung einer neuen Sequenz vor der Bereitstellung,
• Überwachung von E/A- und Tag-Übergängen während der Anlauflogik,
• Nachverfolgung von Ursache und Wirkung durch Verriegelungen und Freigaben,
• Testen der Fehlerreaktion vor dem Eingriff in einen Live-Prozess,
• Überarbeitung der Logik nach einem simulierten Fehler,
• Vergleich des simulierten Maschinenzustands mit dem Kontaktplan-Zustand,
• Üben von analogem und PID-bezogenem Verhalten in realistischen Szenarien.

Dies ist eine Trainings- und Validierungsumgebung, keine Abkürzung für praktische Erfahrung vor Ort.

Ingenieure sollten eine kompakte Sammlung technischer Nachweise dokumentieren, keine Galerie von Screenshots. Ein Screenshot kann zeigen, dass ein Bildschirm existierte. Er beweist selten, dass die Steuerungslogik korrekt war.

Verwenden Sie diese Struktur:

Spezifizieren Sie die eingeführte anormale Bedingung: fehlende Rückmeldung, klemmender Eingang, analoge Bereichsüberschreitung, Sequenz-Timeout usw.

1. Systembeschreibung Definieren Sie den Prozess oder die Maschine, ihr Betriebsziel und den relevanten Steuerungsumfang.
2. Operative Definition von „korrekt“ Geben Sie die erwartete Sequenz, Freigaben, Abschaltungen, Alarme, das Timing-Verhalten und die Erfolgskriterien an.
3. Kontaktplan-Logik und simulierter Anlagenzustand Zeigen Sie die Kontaktplan-Implementierung zusammen mit dem beobachteten Anlagen- oder Prozesszustand in der Simulation.
4. Der injizierte Fehlerfall
5. Die vorgenommene Überarbeitung Protokollieren Sie die Logikänderung, Parameteränderung oder Sequenzkorrektur, die nach der Beobachtung des Fehlers vorgenommen wurde.
6. Gelernte Lektionen Erklären Sie, was der Test über Annahmen, Timing, Verriegelungen, Diagnosen oder Bedienerverhalten offenbart hat.

Dieses Format ist für Ausbilder, Personalverantwortliche und leitende Ingenieure nützlicher, da es logisches Denken demonstriert und nicht nur den Softwarezugriff.

Simulationsbasierte Validierung wird unterstützt, wenn sie als Risikoreduzierung, Designverifizierung, Trainingsunterstützung und Test vor der Bereitstellung gerahmt wird, anstatt als Ersatz für formale Sicherheitsvalidierung oder Abnahmeprüfungen vor Ort.

Relevante Leitlinien umfassen:

• IEC 61508, die systematische Integrität, Lebenszyklusdisziplin und Verifizierungsaktivitäten in sicherheitsbezogenen Systemen betont.
• exida-Leitlinien, die zwischen gutem Ingenieurprozess, Verifizierungsstrenge und unbegründeten Annahmen über die Sicherheitsleistung unterscheiden.
• Literatur zu digitalen Zwillingen und Simulation, die den Einsatz virtueller Modelle zur Designbewertung, Bedienerschulung und Systemverhaltensanalyse unterstützt, wenn Modellumfang und -treue ordnungsgemäß begrenzt sind.
• Forschung zu immersivem Lernen, die nahelegt, dass interaktive und kontextreiche Umgebungen das prozedurale Verständnis und die Merkfähigkeit verbessern können, wobei die Ergebnisse stark vom didaktischen Design abhängen.
• Literatur zur Ausbildung in der Industriesteuerung, die szenariobasiertes Üben für Fehlerbehebung, Sequenzierung und systemisches Denken über syntaxbasierte Programmierübungen hinaus unterstützt.

Die wichtigste Warnung ist einfach: Simulation kann die Vorbereitung und Validierungsqualität verbessern, aber sie beseitigt nicht die Notwendigkeit für Hardwaretests, Inbetriebnahmedisziplin, Lockout/Tagout-Praxis oder Governance für funktionale Sicherheit.

Die stärkste Schlussfolgerung ist nicht, dass Cloud-Simulation universell perfekt ist. Es ist, dass verteilte Ausführung oft besser geeignet ist als lokale All-in-One-Ausführung für zeitkritische, multidisziplinäre Automatisierungsproben.

Wenn Browser-Rendering von der Backend-Steuerungsausführung getrennt wird:

• spielt lokale Hardwarevariabilität eine geringere Rolle,
• ist das Zyklus-Timing besser geschützt,
• wird die Interaktion mit digitalen Zwillingen reproduzierbarer,
• lassen sich Fehlertests einfacher ohne Workstation-Instabilität durchführen,
• können sich Lernende und Ingenieure auf die Validierung konzentrieren, anstatt die Maschine zu „betreuen“.

Das ist das praktische Argument für OLLA Lab. Es kombiniert einen browserbasierten Kontaktplan-Editor, Simulationsmodus, Variablen- und E/A-Sichtbarkeit, geführte Workflows, KI-Laboranleitung, 3D/WebXR-Umgebungen, Interaktion mit digitalen Zwillingen, Analog- und PID-Werkzeuge sowie szenariobasierte Inbetriebnahmepraxis in einer begrenzten Umgebung für Proben und Validierung.

- IEC 61508 Übersicht 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