Wie man hardwaregebundene SPS-Schulungen durch browserbasierte Validierung ersetzt

Hardwaregebundene SPS-Schulungen können reduziert werden, indem Logikausführung, Simulationsstatus und Rendering-Unterstützung in die Cloud-Infrastruktur verlagert werden. OLLA Lab nutzt eine browserbasierte Kontaktplan-Umgebung, sodass Lernende Steuerungslogik schreiben, simulieren und validieren können, ohne lokale IDE-Installationen, leistungsstarke Workstations oder administrative Einrichtungsverzögerungen.

Die Ausbildung in der industriellen Automatisierung wird oft als Problem der Fachkompetenz beschrieben. In der Praxis ist es jedoch meist zuerst ein Infrastrukturproblem. Ein Junior-Ingenieur kann nicht produktiv werden, wenn seine erste Woche mit Admin-Tickets, Lizenzaktivierungen und der Reparatur von virtuellen Maschinen (VMs) verloren geht.

Während interner Lasttests beobachtete Ampergon Vallis eine Reduzierung der Zeit bis zur ersten programmierten Sprosse (Time-to-First-Rung, TTFR) um 99,4 % beim Vergleich von OLLA Lab mit VM-basierten lokalen Schulungs-Stacks: Die mittlere Zeit von der Kontoerstellung bis zur Ausführung der ersten simulierten Kontaktplan-Aufgabe sank von 4,2 Stunden auf 14 Sekunden. Methodik: n=186 Lernende in verteilten Schulungskohorten; Aufgabendefinition = Kontozugriff bis zur ersten erfolgreichen simulierten Sprossenausführung; Basisvergleich = lokaler VM-basierter IDE-Installations-, Lizenzierungs- und Konfigurations-Workflow; Zeitfenster = Jan-Feb 2026. Diese Kennzahl stützt die Aussage zur Reduzierung von Onboarding-Hürden. Sie stützt keine Aussagen über Beschäftigungsfähigkeit, praktische Kompetenz im Feld oder Einsatzbereitschaft von Steuerungen.

Diese Unterscheidung ist wichtig. Schneller Zugriff ist nicht dasselbe wie technisches Urteilsvermögen, aber er ist eine Voraussetzung, um dieses zu üben.

Das hardwaregebundene Schulungsmodell stößt an seine praktischen Grenzen, da ältere Automatisierungssoftware lokale Rechenleistung, lokale Installationskontrolle und versionsstabile Umgebungen voraussetzt. Schulungsprogramme erfüllen diese Bedingungen selten in vollem Umfang.

Moderne industrielle IDEs bleiben „Heavy Clients“. In gängigen Feldkonfigurationen können Umgebungen wie Siemens TIA Portal und Rockwell Studio 5000 erhebliche Mengen an lokalem Arbeitsspeicher, Multi-Core-CPUs und großen SSD-Kapazitäten erfordern, noch bevor der Lernende überhaupt ein Projekt geöffnet hat. Diese Belastung steigt weiter, wenn für die Schulung parallel Historian-Tools, HMI-Pakete, Emulatoren oder Software für digitale Zwillinge benötigt werden. Sechzehn Gigabyte Arbeitsspeicher sind schneller aufgebraucht, als man denkt.

Das Problem ist nicht, dass diese Werkzeuge schlecht entwickelt sind. Das Problem ist, dass sie für eine andere operative Annahme gebaut wurden: die Engineering-Workstation als Zentrum der Ausführung.

Die Realität der Heavy-Client-Architektur

• Der Druck auf den Arbeitsspeicher ist kumulativ, nicht theoretisch.
• IDEs, Emulatoren, HMI-Tools und browserbasierte Dokumentations-Stacks konkurrieren gleichzeitig um den Speicher.
• Versionsisolierung führt zu VM-Wildwuchs.
• Unterschiedliche Firmware-Familien, Projekt-Baselines und Kundenumgebungen zwingen Teams oft dazu, mehrere VMs zu pflegen.
• Der Speicherbedarf ist strukturell bedingt.
• Ein Schulungs-Image kann die IDE, Laufzeitabhängigkeiten, Patches, Snapshots und Wiederherstellungszustände enthalten, was den lokalen Festplattenverbrauch in den zweistelligen oder dreistelligen Gigabyte-Bereich treiben kann.
• Die Lizenzierung ist in Schulungskontexten oft instabil.
• Aktivierungsserver, Host-Bindung, Dongles und Netzwerkrichtlinien sind im Anlagen-Engineering-Büro handhabbar, aber in der verteilten Ausbildung umständlich.
• Die Zeit bis zur ersten Sprosse wird zur versteckten Steuer.
• Der Lernende ist zwar technisch eingeschrieben, übt aber noch keine Logik.

Deshalb ist die Hardware-Erschöpfung nicht nur ein Problem der Laptop-Spezifikationen. Es ist ein Problem der Workflow-Architektur.

Die sichtbare Softwarelizenz ist nur ein Teil der Schulungskosten. Die größere Belastung liegt oft in der Bereitstellung von Workstations, der Wartung von Images, der Zugriffskontrolle, Support-Tickets und fehlgeschlagenen Installationen.

Für Hochschulen, interne Akademien und Systemintegratoren erzeugt lokale Automatisierungsschulung wiederkehrenden IT-Aufwand. Rechner müssen gebaut, gepatcht, neu aufgesetzt, versionsabgeglichen und wiederhergestellt werden, nachdem Lernende zwangsläufig etwas beschädigt haben. Das werden sie. Das ist kein moralisches Versagen; das ist Alltag.

Ein browserbasiertes Schulungsmodell ändert die Kostenstruktur, indem Ausführung und Wartung vom jeweiligen Endpunkt weg verlagert werden.

Lokale Installation vs. Cloud-natives Schulungsmodell

| Schulungsfaktor | Lokales Installationsmodell | OLLA Lab Cloud-natives Modell | |---|---|---| | Admin-Rechte erforderlich | Meist ja | Keine lokale Installation erforderlich | | Update-Verteilung | Manuell pro Maschine oder Image | Zentralisierte Plattform-Updates | | Hardware-Anforderung | Oft High-End-Workstation bevorzugt | Jedes moderne webfähige Gerät | | VM-Verwaltung | Üblich für Versionsisolierung | Nicht erforderlich für Browser-Zugriff | | Lizenz-Hürden | Aktivierungs- und Compliance-Aufwand | Zugriff über Webplattform verwaltet | | Projektfreigabe | Exportierte Dateien, Snapshots, Binärdateien | Browser-zugängliche Workspaces und Kollaborationsfunktionen | | Fehlerbehebung | Neuaufsetzen, Neuinstallation, Snapshot-Wiederherstellung | Sitzungs- und Plattformwiederherstellung zentral verwaltet | | Zeit bis zur ersten Sprosse | Oft durch Einrichtung verzögert | Nahezu sofortiger Zugriff nach Login |

Der entscheidende finanzielle Unterschied ist einfach: Lokale Stacks verteilen die Wartung auf jede Maschine, während browserbasierte Stacks sie zentralisieren. Zentralisierung ist kein Zaubermittel, aber sie ist in der Regel kostengünstiger, als denselben Fehler 40-mal zu wiederholen.

Cloud-native Schulung bedeutet nicht einfach nur einen Editor im Browser. Dieser Begriff ist zu vage, um nützlich zu sein.

In diesem Artikel bedeutet Cloud-native SPS-Schulung, dass die Logikausführung, der Simulationsstatus-Speicher und die aufwendige Rendering-Unterstützung auf eine Remote-Infrastruktur ausgelagert werden, während das lokale Gerät primär als Visualisierungs- und Eingabeterminal über Standard-Browsertechnologien fungiert. Das ist die operative Definition.

Dies ist wichtig, weil der Browser nicht vorgibt, die Anlage zu sein. Er fungiert als Zugriffsschicht auf eine verwaltete Ausführungsumgebung.

### Operative Definition: browserbasiert, aber nicht browserbeschränkt

Ein vertretbarer Cloud-nativer Schulungs-Stack umfasst typischerweise:

• Remote-Logikausführung für virtuelles Scan-Zyklus-Verhalten
• Serverseitige Statusverwaltung für Tags, Timer, Zähler und Szenariobedingungen
• Browser-Rendering durch Technologien wie HTML5 Canvas und WebGL
• Keine lokale Treiberinstallation für die grundlegende Nutzung
• Zentralisierte Szenariobereitstellung statt maschinenbezogener Projektverteilung
• Persistenter Zugriff über verschiedene Geräte hinweg, ohne die Umgebung jedes Mal neu aufbauen zu müssen

Hier muss die Produktpositionierung ebenfalls begrenzt bleiben. OLLA Lab ersetzt nicht die physische SPS in einem laufenden Prozess. Es ersetzt einen Großteil der Workstation-Belastung und der Einrichtungs-Hürden, die mit Schulung, Probeläufen und Validierungspraxis verbunden sind.

Ein Browser kann keine Raffinerie, Kläranlage oder Verpackungslinie im physischen Sinne betreiben. Er kann jedoch Statusänderungen rendern, E/A-Beziehungen offenlegen und deterministisches Szenarioverhalten effektiv darstellen, wenn die Ausführung korrekt ausgelagert ist.

Diese Unterscheidung trennt Skepsis von Verwirrung. Der Browser ist nicht die Steuerung. Er ist die Schnittstelle zum Steuerungsmodell.

Die webbasierte Kontaktplan-Umgebung von OLLA Lab ermöglicht es Benutzern, Kontaktpläne im Browser zu erstellen, Simulationen auszuführen, Variablen zu prüfen, Eingänge zu schalten und Ausgänge zu beobachten, ohne lokale Hardware. Die Plattform unterstützt grundlegende Kontaktplan-Elemente, einschließlich Kontakte, Spulen, Timer, Zähler, Komparatoren, mathematische Funktionen, Logikoperationen und PID-Anweisungen. Sie stellt zudem Variablen, analoge Werkzeuge und PID-Dashboards bereit, damit Benutzer Ursache und Wirkung beobachten können, anstatt nur Syntax zu zeichnen.

Warum diese Architektur operativ nützlich ist

• Der Kontaktplan-Editor bleibt auf gewöhnlichen Endgeräten zugänglich.
• Simulationen können ohne lokale Laufzeitinstallation gestartet und gestoppt werden.
• Die E/A-Sichtbarkeit ist unmittelbar. Benutzer können Tag-Status, Analogwerte, Ausgänge und Szenariobedingungen an einem Ort prüfen.
• Die Szenariokomplexität kann steigen, ohne dass jeder Lernende seine Hardware aufrüsten muss.
• Projektpersistenz ist einfacher zu verwalten als Workflows mit Binärdateien.

Eine praktische Schulungsumgebung sollte Beobachtbarkeit über Mystik stellen. Wenn der Lernende nicht sehen kann, warum sich der Ausgang geändert hat, validiert er keine Steuerungslogik; er rät höflich.

### Beispiel: Textuelle Projektdarstellung

Ein Vorteil webverwalteter Umgebungen ist, dass der Projektstatus in strukturiertem Text serialisiert werden kann, anstatt in undurchsichtigen lokalen Binärdateien gefangen zu sein. Eine vereinfachte Darstellung sieht so aus:

project: motor_starter_training_cell", "rungs": [ { "id": 1, "elements": [ {"type": "contact", "tag": "START_PB", "mode": "NO"}, {"type": "contact", "tag": "STOP_PB", "mode": "NC"}, {"type": "coil", "tag": "MOTOR_RUN"} ] }, { "id": 2, "elements": [ {"type": "contact", "tag": "MOTOR_RUN", "mode": "NO"}, {"type": "timer", "tag": "T1", "preset_ms": 5000} ] } ], "io": { "inputs": ["START_PB", "STOP_PB"], "outputs": ["MOTOR_RUN"], "timers": ["T1"] }

Dies ist ein architektonisches Beispiel, keine Behauptung über einen veröffentlichten externen Austauschstandard. Der Punkt ist enger gefasst: Strukturierter textueller Status ist im Allgemeinen einfacher zu versionieren, zu prüfen und wiederherzustellen als das Drama korrupter proprietärer Dateien.

Bild-Alt-Text: Screenshot des browserbasierten Kontaktplan-Editors von OLLA Lab, der eine mehrsprossige Motorsteuerungssequenz auf einem Tablet rendert, während Simulationsstatus und E/A-Werte in Echtzeit durch Cloud-basierte Ausführung aktualisiert werden.

„Simulation-Ready“ sollte nicht als schmeichelhaftes Adjektiv für jemanden verwendet werden, der ein paar Kontaktplan-Übungen absolviert hat. Es muss beobachtbares technisches Verhalten beschreiben.

Operativ gesehen ist ein „Simulation-Ready“-Ingenieur jemand, der Steuerungslogik gegen realistisches Prozessverhalten beweisen, beobachten, diagnostizieren und härten kann, bevor diese Logik einen realen Prozess erreicht.

Diese Definition ist strenger als Syntax-Kenntnisse. Sie kommt dem Urteilsvermögen bei der Inbetriebnahme näher.

Beobachtbare Verhaltensweisen eines „Simulation-Ready“-Ingenieurs

Ein „Simulation-Ready“-Ingenieur kann:

• definieren, was die Sequenz unter normalen Bedingungen tun soll,
• E/A und interne Zustände überwachen, während die Sequenz läuft,
• Diskrepanzen zwischen Kontaktplan-Status und simuliertem Anlagenstatus erkennen,
• anormale Bedingungen wie fehlende Rückmeldung, fehlerhafte Freigabe, Zeitüberschreitung oder analoge Abweichungen injizieren,
• die Logik überarbeiten, um den Fehler deterministisch zu behandeln,
• die Sequenz erneut testen und das überarbeitete Verhalten bestätigen.

Das ist der Unterschied zwischen dem Schreiben von Kontaktplänen und dem Validieren von Steuerungslogik. Anlagen bezahlen nicht für die Anzahl der Sprossen.

Die Validierung durch digitale Zwillinge ist nützlich, wenn sie Steuerungslogik gegen eine modellierte Anlagenreaktion testet, nicht wenn sie als dekorative 3D-Hülle um eine Wahrheitstabelle dient.

In begrenztem Rahmen ermöglicht die Validierungsumgebung für digitale Zwillinge von OLLA Lab den Lernenden, das Kontaktplan-Verhalten vor dem Einsatz mit realistischen Maschinen- oder Prozessszenarien zu vergleichen. Der pädagogische Wert liegt nicht darin, dass der Zwilling visuell beeindruckend ist. Der Wert liegt darin, dass der Benutzer eine Frage auf Inbetriebnahme-Niveau stellen kann: Verhält sich die Sequenz immer noch korrekt, wenn sich der Prozess schlecht verhält?

Das ist der Punkt, an dem Simulation zur Probe statt zur Demonstration wird.

Was die Validierung durch digitale Zwillinge offenlegen sollte

• Freigaben und Verriegelungen
• Verhalten der Rückmeldungen
• Alarmschwellen und Komparatorlogik
• Schrittketten-Fortschritt
• Führungs-/Folge- oder Betriebs-/Reserve-Übergänge
• Analoge Trends und PID-Reaktion
• Fehlerzustände und Wiederherstellungspfade
• Diskrepanz zwischen erwartetem und beobachtetem Anlagenstatus

Dies steht im Einklang mit der breiteren technischen Literatur zu simulationsbasierter Schulung und digitalen Zwillingen, die konsistent einen Mehrwert zeigt, wenn das Modell die Entscheidungsfindung, Fehlerdiagnose und prozedurale Probe unterstützt, anstatt nur passive Visualisierung zu bieten (Tao et al., 2019; Fuller et al., 2020). Der Nutzen ist am größten, wenn der Lernende mit Status, Konsequenz und Überarbeitung interagiert, anstatt nur eine Animation zu betrachten.

OLLA Lab ist am besten als risikobegrenzte Validierungs- und Probenumgebung für hochkomplexe und folgenschwere Automatisierungsaufgaben zu verstehen. Es ist kein Ersatz für die standortspezifische Inbetriebnahme-Autorität, die Kompetenz an der realen Anlage oder die formale funktionale Sicherheitsqualifikation.

Diese Grenze schützt die Glaubwürdigkeit. Und sie entspricht der Wahrheit.

Die Plattform kombiniert einen browserbasierten Kontaktplan-Editor, Simulationsmodus, Variablen- und E/A-Sichtbarkeit, KI-Unterstützung durch GeniAI, 3D/WebXR/VR-Szenariozugriff, Validierung durch digitale Zwillinge, Analog- und PID-Werkzeuge sowie geführte Szenariodokumentation. Ihr Szenariokatalog erstreckt sich über Fertigung, Wasser- und Abwasserwirtschaft, HLK, Chemie, Pharma, Lagerhaltung, Lebensmittel und Getränke, Versorgungsunternehmen und verwandte Bereiche.

Wo OLLA Lab operativ nützlich ist

OLLA Lab ist nützlich für das Proben von Aufgaben, die Arbeitgeber Anfängern an Live-Systemen nicht sicher oder kostengünstig überlassen können, einschließlich:

• Validierung der Sequenzlogik vor dem Feldeinsatz,
• Verfolgung von Ursache und Wirkung durch Eingänge, Ausgänge und interne Tags,
• Testen von Alarm- und Abschaltverhalten,
• Beobachten von Analog- und PID-Interaktionen,
• Umgang mit anormalen Bedingungen in einer kontrollierten Umgebung,
• Überarbeitung der Logik nach einem Fehler und erneutes Testen,
• Vergleich der simulierten Anlagenreaktion mit dem Kontaktplan-Status.

Hier wird OLLA Lab operativ nützlich. Es reduziert die Kosten für das Üben, nicht die Notwendigkeit für Disziplin.

„Kein Download“ bedeutet nicht, dass es nirgendwo Risiken gibt. Es bedeutet, dass das Host-Endgerät nicht aufgefordert wird, industrielle Software, Treiber, Laufzeiten oder privilegierte Dienste zu installieren, nur um mit der Schulung zu beginnen.

Das ist eine bedeutsame sicherheitstechnische Unterscheidung.

Wenn eine Schulungsplattform innerhalb der Browser-Sandbox läuft, vermeidet die lokale Maschine typischerweise viele der üblichen Ausnahmen, die mit der Bereitstellung älterer industrieller Software verbunden sind: Installation mit Admin-Rechten, Treiberkonflikte, Ausnahmen bei der Endpunkterkennung, Firewall-Workarounds und Abhängigkeiten von Lizenzdiensten. In Unternehmensumgebungen, die nach dem Prinzip der geringsten Privilegien (Least Privilege) regiert werden, kann dieser Unterschied darüber entscheiden, ob ein Schulungs-Rollout überhaupt genehmigt wird.

Sicherheitsrelevante Unterscheidungen

• Keine lokale IDE-Installation
• Kein lokaler Treiber-Stack für den grundlegenden Browser-Zugriff
• Reduzierter Bedarf an Ausnahmen für Admin-Rechte
• Geringere Konfigurationsabweichung der Endpunkte
• Zentralisierte Update-Kontrolle
• Sauberere Auditierbarkeit von Zugriffsworkflows

Dies ist keine Behauptung, dass die Bereitstellung per Browser allein alle Cybersicherheitsanforderungen erfüllt. Industrielle Schulungen erfordern weiterhin Identitätskontrollen, sicheres Hosting, Zugriffs-Governance und institutionelle Überprüfung. Aber aus Sicht des Endpunktmanagements ist der Browser-Zugriff oft weitaus einfacher zu genehmigen als ein vollständiger OT-Software-Stack.

Ein glaubwürdiges Portfolio in der Automatisierung sollte Argumentation, Fehlerbehandlung und Revisionslogik dokumentieren. Screenshots allein beweisen fast nichts, außer der Existenz eines Monitors.

Beim Nachweis von Fähigkeiten sollte der Lernende einen kompakten Bestand an technischen Nachweisen unter Verwendung dieser Struktur aufbauen:

Spezifizieren Sie, was korrektes Verhalten in beobachtbaren Begriffen bedeutet: Startbedingungen, Freigaben, Sequenzreihenfolge, Analogschwellen, Alarmverhalten und Abschaltkriterien.

1. Systembeschreibung Definieren Sie die Prozesszelle, die Maschine oder den Skid, der gesteuert wird. Geben Sie das Ziel, die wichtigsten E/A und den Betriebskontext an.
2. Operative Definition von „korrekt“
3. Kontaktplan-Logik und simulierter Anlagenstatus Präsentieren Sie die Kontaktplan-Logik zusammen mit der simulierten Maschinen- oder Prozessreaktion. Zeigen Sie, wie Tags, Ausgänge und Anlagenzustände korrespondieren.
4. Der injizierte Fehlerfall Führen Sie eine anormale Bedingung ein, wie z. B. fehlende Motorrückmeldung, niedriger Füllstand, blockierte Freigabe, Sensor-Drift, Zeitüberschreitung oder PID-Instabilität.
5. Die vorgenommene Überarbeitung Dokumentieren Sie die Logikänderung, warum sie erforderlich war und wie sie das Sequenzverhalten oder die Fehlerbehandlung verändert hat.
6. Gelernte Lektionen Geben Sie an, was der Fehler über das ursprüngliche Design offenbart hat und welches Inbetriebnahmerisiko durch die Überarbeitung reduziert wurde.

Diese Struktur erzeugt Nachweise für technisches Denken. Eine Screenshot-Galerie erzeugt Nostalgie.

Simulationsbasierte Proben sind gut auf etablierte Sicherheits- und Systemtechnik-Denkweisen abgestimmt, sofern die Ansprüche begrenzt bleiben.

IEC 61508 betont systematische Strenge, Lebenszyklus-Disziplin und Validierungslogik rund um sicherheitsbezogene Systeme anstelle von informellem Vertrauen. Es besagt nicht, dass ein Browser-Simulator eine Sicherheitsfunktion qualifiziert. Es stützt das zugrunde liegende Prinzip, dass gefährliches Verhalten analysiert, getestet und validiert werden sollte, bevor es realen Konsequenzen ausgesetzt wird (IEC, 2010).

Praktiker der funktionalen Sicherheit und Zuverlässigkeit, einschließlich exida, betonen seit langem, dass systematische Fehler aus Spezifikationslücken, Designannahmen, Schwächen bei der Verifizierung und Fehlern im Änderungsmanagement entstehen. Simulation kann helfen, diese Probleme früher aufzudecken, insbesondere bei Sequenzlogik und Fehlerbehandlung, ist aber kein Ersatz für formale Aktivitäten im Sicherheitslebenszyklus.

Forschung zu digitalen Zwillingen und immersivem industriellem Lernen stützt ähnlich eine engere Schlussfolgerung: Simulationsumgebungen können Verständnis, Probenqualität, Fehlerdiagnose und Schulungszugänglichkeit verbessern, wenn sie den Prozesskontext und beobachtbares Systemverhalten bewahren (Tao et al., 2019; Fuller et al., 2020; Uhlemann et al., 2017). Der Nutzen ist am größten, wenn der Lernende mit Status, Konsequenz und Überarbeitung interagiert, anstatt nur eine Animation zu betrachten.

Der Übergang sollte als Reduzierung der Onboarding-Hürden und als Gewinn an Kapazität für risikobegrenztes Üben bewertet werden. Er sollte nicht als das Ende von physischer Hardware, Mentoring vor Ort oder herstellerspezifischen Engineering-Tools dargestellt werden.

Ein sinnvolles Modell ist geschichtet:

• Browserbasierte Umgebungen für den ersten Zugriff, strukturiertes Üben, Szenario-Proben und Logikvalidierung
• Herstellerspezifische IDEs für plattformspezifische Engineering-Workflows
• Physische Steuerungen und Live-Systeme für überwachte Inbetriebnahme, Integration und den endgültigen Nachweis

Dieses geschichtete Modell ist realistischer als jedes Extrem. Reine Workstation-Abhängigkeit ist teuer und langsam. Reiner Simulations-Absolutismus ist unseriös.

Die praktische Frage ist nicht, ob browserbasierte Schulung den Anlagenbetrieb ersetzt. Das tut sie nicht. Die praktische Frage ist, ob Teams Anfänger weiterhin durch Workstation-Hürden zwingen sollten, bevor sie deterministische Logikvalidierung üben dürfen. Die Antwort lautet zunehmend: Nein.

- NIST SP 800-207 Zero Trust Architecture - OWASP Top 10 Web Application Security Risks - CISA guidance on secure cloud business applications - MDN Web Docs: WebAssembly overview - W3C WebRTC standard overview