So testen Sie SPS-Motorsteuerungslogik mobil und in VR mit OLLA Lab

Um im Jahr 2026 SPS-Motorsteuerungslogik über Mobilgeräte und VR hinweg zu testen, benötigen Ingenieure einen konsistenten Projektstatus über verschiedene Geräte hinweg sowie eine Möglichkeit, das Maschinenverhalten zu beobachten – nicht nur den Status der Strompfade. OLLA Lab nutzt in der Cloud gespeicherte JSON-Projektdaten, sodass Benutzer eine 3-Draht-Motorschaltung auf einem Mobilgerät erstellen und deren Verhalten in einer WebXR-Simulation validieren können.

Das Üben von SPS-Logik auf einem Smartphone ist nicht der schwierige Teil. Die Herausforderung besteht darin, nachzuweisen, dass die Logik korrekt funktioniert, wenn Maschinenverhalten, E/A-Signale, Zeitabläufe und Fehlerbedingungen einbezogen werden. Syntax ist billig; Bereitstellbarkeit ist es nicht.

Diese Unterscheidung ist wichtig, da Berufseinsteiger und Auszubildende selten genug sichere Wiederholungen an realen Anlagen erhalten, um Urteilsvermögen für die Inbetriebnahme zu entwickeln. Die Daten des U.S. Bureau of Labor Statistics zeigen weiterhin einen erheblichen Ersatzbedarf in der industriellen Instandhaltung und verwandten technischen Berufen, was jedoch nicht als einfache Knappheitsstatistik oder Garantie für Einsatzbereitschaft missverstanden werden sollte. Es bedeutet, dass das Zeitfenster für die Ausbildung komprimiert ist, nicht, dass das Prozessrisiko verhandelbar geworden wäre.

Während der jüngsten Betatests der Multi-Device-Handoff-Architektur von OLLA Lab beobachtete Ampergon Vallis, dass Auszubildende, die ein Motorsteuerungsprojekt von einem 6-Zoll-Mobilbildschirm in eine WebXR-Umgebung übertrugen, räumliche Verriegelungsfehler 22 % schneller identifizierten als Benutzer, die auf einen 2D-Desktop-Simulator beschränkt waren [Methodik: n=36 Benutzer; Aufgabe definiert als Erstellung und Validierung einer Förderband-Start-Stopp-Überlast-Sequenz mit einem injizierten räumlichen Sensor-Mismatch; Basis-Vergleichswert = Desktop-basierter 2D-Simulations-Workflow; Zeitfenster = 14-tägige Beta-Phase in Q1 2026]. Dies stützt eine eng gefasste Aussage über die Fehlererkennungsgeschwindigkeit bei diesem spezifischen Aufgabendesign. Es beweist keine allgemeine Überlegenheit gegenüber allen SPS-Schulungen oder der Inbetriebnahme vor Ort.

In diesem Artikel bedeutet „Simulation-Ready“ etwas Spezifisches: ein Ingenieur, der Steuerungslogik vor Erreichen eines Live-Prozesses beweisen, beobachten, diagnostizieren und gegen realistisches Prozessverhalten absichern kann. Das ist der nützliche Schwellenwert. Der Anlage ist es egal, ob der Strompfad elegant aussah.

Eine 3-Draht-Motorsteuerung ist ein praktischer Ausgangspunkt, da sie die Kernverhaltensweisen enthält, auf die es bei der echten Steuerungsarbeit ankommt: Selbsthaltung, Stopp-Dominanz, Überlast-Abschaltung und Neustart-Disziplin. Sie ist einfach genug zur Inspektion und reichhaltig genug, um auf lehrreiche Weise zu versagen.

Phase 1: 07:00 Uhr — Transit und Konstruktion auf dem Touchscreen

Der Auszubildende öffnet OLLA Lab auf einem Smartphone und erstellt eine Standard-Förderband-Motorsteuerungssequenz im browserbasierten Kontaktplan-Editor. Die Aufgabe ist nicht abstrakt: Erstellen Sie eine Start/Stopp-Schaltung mit Selbsthaltekontakt und Überlastschutz und bereiten Sie diese für die Simulation vor.

Eine minimale Darstellung sieht so aus:

Sprache: Kontaktplan (Ladder Diagram) - 3-Draht-Motorsteuerung

Strompfad 0: [Stopp-Taster (Öffner)] ---- [Überlast (Öffner)] ----+---- [Start-Taster (Schließer)] -------- (Motorschütz-Spule) | +---- [Motor-Hilfskontakt (Schließer)] -------|

Das Steuerungsziel ist eindeutig:

• Drücken Sie Start, um die Motorschütz-Spule zu erregen.
• Halten Sie die Spule über einen Hilfs-Selbsthaltekontakt, nachdem der Start-Taster losgelassen wurde.
• Schalten Sie die Spule sofort ab, wenn Stopp öffnet.
• Schalten Sie die Spule sofort ab, wenn Überlast öffnet.
• Führen Sie keinen automatischen Neustart durch, nur weil eine Überlast zurückgesetzt oder eine Stopp-Bedingung aufgehoben wurde.

Dieser letzte Punkt ist der Bereich, in dem Anfänger oft abweichen. Eine Schaltung, die sich nach einem Fehler-Reset von selbst neu startet, ist nicht „hilfreich“. Es ist in der Regel ein Inbetriebnahme-Problem mit einem ordentlichen Gesicht.

Mobile Gestensteuerung in OLLA Lab für Kontaktpläne

Auf Mobilgeräten muss die Schnittstelle die Kontaktplanstruktur bewahren, ohne so zu tun, als wäre ein Touchscreen eine Maus. Der mobile Workflow von OLLA Lab ist nützlich, da er die Bearbeitungsaktionen an die Semantik des Kontaktplans bindet und nicht an allgemeines Zeichenverhalten.

- Drag-to-place: Einfügen von Schließern, Öffnern, Spulen, Timern, Zählern, Vergleichern und anderen Anweisungen aus der Werkzeugleiste in den aktiven Strompfad. - Tap-to-branch: Erstellen des parallelen Selbsthaltepfads, der zur Überbrückung des tastenden Start-Tasters erforderlich ist. - Swipe-to-bind: Zuweisen von Tags und Variablen über das Variablen-Panel, sodass die Symbole mit tatsächlichen Eingängen, Ausgängen und internen Zuständen verbunden sind. - Run/Stop-Simulationssteuerung: Ausführen der Logik und Beobachten von Zustandsänderungen ohne physische Hardware. - Variableninspektion: Überwachen von Eingangsstatus, Ausgangsstatus und zugehörigen Werten während des Tests des Strompfads.

Der technische Wert liegt hier nicht im „Programmieren auf dem Telefon“. Es geht darum, die Sichtbarkeit von Ursache und Wirkung zu bewahren und gleichzeitig die Leerlaufzeit zwischen den Übungseinheiten zu reduzieren. Pendelzeiten sind keine idealen Labore, aber sie sind besser als tote Zeit.

Geräteübergreifende Simulation funktioniert nur, wenn die Projektdefinition und der laufzeitrelevante Status in einem portablen, wiederherstellbaren Format gespeichert werden können. In OLLA Lab erfolgt diese Übergabe über cloudbasierte JSON-Projektspeicherung anstelle eines gerätegebundenen Binärdatei-Workflows.

Phase 2: 08:00 bis 17:00 Uhr — pausieren, speichern, fortsetzen

Der Auszubildende erstellt die Motorschaltung auf dem Mobilgerät, führt eine kurze Simulation durch und geht dann zur Schicht oder zum Unterricht. Später wird dasselbe Projekt auf einem anderen Gerät wieder geöffnet, ohne den Kontaktplan von Grund auf neu erstellen zu müssen.

Der wichtige Unterschied ist mechanisch, nicht mystisch. Eine geräteübergreifende Übergabe erfordert, dass mindestens diese Elemente in strukturierter Form erhalten bleiben:

• Kontaktplan-Objekte und Strompfad-Topologie
• Anweisungstypen und Tag-Bindungen
• Variablennamen und aktuelle Werte, sofern die Plattform Statuspersistenz unterstützt
• Szenarioauswahl
• Relevante Analog- und Steuerparameter
• Simulationskontext, der erforderlich ist, um das Testen kohärent fortzusetzen

In der Praxis bedeutet das, dass ein Projekt nicht nur das Diagramm, sondern auch den Arbeitskontext darum herum bewahren kann. Wenn eine Timer-Anweisung einen Teil ihres abgelaufenen Wertes akkumuliert hat oder wenn ein Szenario einen ausgewählten Anlagenzustand aufweist, ist die Übergabe nur dann nützlich, wenn diese Bedingungen konsistent genug dargestellt werden, um eine sinnvolle Validierung fortzusetzen.

Ein textbasiertes Schema ist wichtig, da es asynchronen Cloud-Speicher, Geräteunabhängigkeit und wiederherstellbare Synchronisation unterstützt. Es macht die Architektur auch leichter nachvollziehbar als undurchsichtige Datei-Container. Undurchsichtige Systeme fühlen sich oft robust an, bis sie am falschen Tag um 18:10 Uhr versagen.

Dies bedeutet nicht, dass jede SPS-Laufzeitnuance identisch mit einer herstellerspezifischen Controller-Scan-Implementierung ist. OLLA Lab ist eine webbasierte Simulations- und Validierungsumgebung, kein Anspruch auf 1:1-Emulation für jede Hardwareplattform. Der begrenzte Anspruch ist enger und nützlicher: Er ermöglicht es Benutzern, einen Kontaktplan-Validierungs-Workflow geräteübergreifend fortzusetzen und dabei die Projektstruktur und den Simulationskontext zu bewahren, die für Proben und Fehlersuche erforderlich sind.

Die Validierung beginnt mit einer operativen Definition von „korrekt“. Für einen Motorsteuerungs-Strompfad bedeutet korrekt nicht „die Spule hat in der Simulation einmal eingeschaltet“. Es bedeutet, dass sich die Sequenz bei normalen Starts, normalen Stopps, Überlastauslösungen und Neustartbedingungen wie beabsichtigt verhält.

Phase 3: 18:30 Uhr — Validierung im Heimlabor

Der Auszubildende öffnet dasselbe Projekt in OLLA Lab, setzt das Szenario fort und testet die Schaltung gegen das erwartete Maschinenverhalten. Hier wird die Übung zu Ingenieursarbeit statt zu Diagrammerstellung.

Operative Definition von „korrekt“ für diese Motorsteuerungsaufgabe

Ein gültiges Ergebnis sollte alle der folgenden beobachtbaren Verhaltensweisen zeigen:

• Die Motorspule zieht nur an, wenn die Freigabebedingungen erfüllt sind.
• Der Selbsthaltepfad behält den Betriebszustand bei, nachdem der Start-Taster losgelassen wurde.
• Der Stopp-Taster hebt den Betriebszustand sofort auf.
• Der Überlastkontakt hebt den Betriebszustand sofort auf.
• Das bloße Zurücksetzen der Überlast führt nicht zu einem unbeabsichtigten Neustart.
• Eingangs- und Ausgangsänderungen bleiben im Variablen-Panel und im Simulationsstatus nachvollziehbar.

Das ist das Mindestmaß an Nachweisen. Wenn die Logik diese Prüfungen in der Simulation nicht übersteht, hat sie an einem Schütz, Frequenzumrichter oder Prozess-Skid nichts zu suchen.

Kontaktplan-Logik und simulierter Anlagenzustand

Der Simulationsmodus und das Variablen-Panel von OLLA Lab sind hier wichtig, da sie es dem Benutzer ermöglichen, beide Seiten des Steuerungsproblems zu beobachten:

- Kontaktplan-Status: Welche Kontakte sind wahr, welche Spule ist erregt und wie erfolgen Logikübergänge. - Anlagenzustand: Ob das simulierte Motor- oder Förderbandverhalten diesen Befehlszustand widerspiegelt. - E/A-Sichtbarkeit: Ob die Eingangs- und Ausgangs-Tags mit der beabsichtigten Steuerungsphilosophie übereinstimmen. - Szenario-Kontext: Ob das ausgewählte Maschinenmodell sich so verhält, dass Sequenzfehler aufgedeckt werden.

Hier wird OLLA Lab operativ nützlich. Der Benutzer fragt nicht nur, ob der Strompfad syntaktisch gültig ist. Der Benutzer fragt, ob das durch den Strompfad implizierte Maschinenverhalten kohärent, sicher und fehlerbewusst ist.

Ein digitaler Zwilling wird oft zu vage beschrieben. In diesem Artikel wird der Begriff in einem begrenzten Sinne verwendet: ein virtuelles Anlagenmodell und ein Szenario-Kontext, mit denen beobachtet wird, ob die Steuerungslogik das beabsichtigte Maschinenverhalten vor der Live-Bereitstellung erzeugt.

Phase 4: Immersive Validierung

Der Auszubildende öffnet das Förderband-Szenario in einer WebXR-fähigen Umgebung und prüft, ob sich die Motorlogik korrekt verhält, wenn sie als Anlagenbewegung, Sensorinteraktion und Fehlerreaktion betrachtet wird. Der Vorteil ist nicht die Neuheit. Der Vorteil ist die räumliche Verifizierung.

Ein 2D-Simulator kann zeigen, dass ein Ausgangsbit erregt wurde. Eine 3D-Umgebung kann zeigen, ob dieses erregte Bit einem glaubwürdigen Maschinenverhalten, einer Sensorplatzierung und einer Fehlerbehandlung entspricht. Das sind unterschiedliche Fragen. Die zweite kommt der Inbetriebnahme näher.

Visuelle Inbetriebnahmeschritte in VR

Diese Art der Validierung unterstützt das, was die Literatur zur simulationsbasierten Ingenieursausbildung wiederholt nahelegt: Immersive und szenariobasierte Umgebungen sind dann am nützlichsten, wenn sie die Fehlererkennung, das Sequenzurteil und den Transfer von prozeduralem Verständnis verbessern, nicht wenn sie als visuelle Dekoration behandelt werden. Das Headset ist nicht der Punkt. Die Veto-Macht, die es gegenüber falschen Annahmen gibt, ist der Punkt.

1. Aktor-Verifizierung Bestätigen Sie, dass das Erregen des Motorausgangs die erwartete Förderband- oder Motorbewegung im simulierten Anlagenmodell erzeugt.
2. Fehlerinjektion Lösen Sie eine Stopp- oder Fehlerbedingung aus und verifizieren Sie, dass der Selbsthaltepfad korrekt abfällt und keinen automatischen Neustart beim Reset erzeugt.
3. Überprüfung des räumlichen Kontexts Beobachten Sie, ob die physische Platzierung von Sensoren, Endschaltern oder Maschinenelementen in Bezug auf das programmierte Timing und Sequenzverhalten sinnvoll ist.
4. Ursache-Wirkungs-Verfolgung Vergleichen Sie Kontaktplan-Status, Variablen-Status und sichtbare Maschinenreaktion, um festzustellen, ob ein Fehler logisch, räumlich oder beides ist.
5. Überarbeitung und erneuter Test Ändern Sie die Kontaktplan-Logik, führen Sie das Szenario erneut aus und bestätigen Sie, dass das überarbeitete Verhalten das beobachtete Problem löst, ohne ein neues einzuführen.

Fehlerinjektion ist der kürzeste Weg von der Syntax-Vertrautheit zum Inbetriebnahme-Urteilsvermögen. Eine Steuerungssequenz, die nur im Idealfall funktioniert, ist unvollständig.

Für eine 3-Draht-Motorsteuerungsübung sind nützliche injizierte Fehler:

- Überlastauslösung während des Betriebs: Verifizierung der sofortigen Abschaltung und kein automatischer Neustart nach dem Reset. - Zustandsinversion des Stopp-Tasters: Bestätigung, dass die Logik die Eingangsabnormalität aufdeckt. - Fehlbindung des Hilfs-Selbsthaltekontakts: Verifizierung, dass der Motor nicht einrastet oder falsch einrastet. - Ausgang auf falschen Aktor gemappt: Vergleich des Kontaktplan-Status mit der simulierten Anlagenreaktion. - Räumlicher Mismatch von Sensor oder Endschalter: Verifizierung, dass das Sequenz-Timing nicht mehr mit dem Maschinenverhalten übereinstimmt. - Verzögerte oder inkonsistente Eingangsübergänge: Beobachtung, ob Timer oder Entprellungs-Annahmen einen Designfehler maskieren.

Dies sind kleine Fehler, aber sie lehren die richtige Gewohnheit: Vergleichen Sie die beabsichtigte Steuerungsphilosophie mit dem beobachteten Verhalten und überarbeiten Sie dann die Logik mit Beweisen. Das ist es, was „Simulation-Ready“ in der Praxis bedeutet.

Kontinuierlicher Zugang ist wichtig, weil risikoreiche Steuerungspraxis selten ist, nicht weil Mobilgeräte modisch sind. Arbeitgeber können unerfahrenes Personal nicht vernünftigerweise die Fehlerbehandlung an Live-Geräten üben lassen, die Produktions-, Sicherheits- oder Anlagenrisiken bergen.

Diese Einschränkung ist besonders bei Motorsteuerungen, Pumpensequenzierung, HLK, Wasseraufbereitung und Prozess-Skids sichtbar, wo ein scheinbar kleiner Logikfehler zu störenden Auslösungen, schlechtem Sequenzverhalten oder unsicheren Neustartbedingungen führen kann. Ein Simulator ersetzt nicht die Praxiserfahrung, aber er kann die Wiederholungen absorbieren, die das Feld nicht sicher subventionieren kann.

Dies ist die begrenzte Rolle für OLLA Lab. Es bietet eine webbasierte Umgebung, um Kontaktplan-Logik zu erstellen, Simulationen auszuführen, E/A-Signale zu inspizieren, industrielle Szenarien durchzuarbeiten und das Verhalten gegen 3D- oder VR-Modelle vor der Live-Bereitstellung zu validieren. Es ist ein Probenraum für risikoreiche Aufgaben. Es ist keine Zertifizierung, keine Standortfreigabe und kein Ersatz für Lockout-Tagout-Disziplin, Herstellerhandbücher oder beaufsichtigte Inbetriebnahme.

Diese Grenze sollte intakt bleiben. Gute Schulungswerkzeuge verlieren an Glaubwürdigkeit, wenn sie vorgeben, Pässe zu sein.

Eine Screenshot-Galerie ist ein schwacher Beweis. Ein kompaktes Ingenieursprotokoll ist stärker, weil es die Argumentation, den Fehlermodus und die Korrektur zeigt.

Verwenden Sie bei der Dokumentation einer Motorsteuerungs-Simulationsübung diese Struktur:

Definieren Sie die Ausrüstung, das Prozessziel, die E/A-Liste und die Steuerungsabsicht. Beispiel: Förderbandmotor mit Start, Stopp, Überlast und aufrechterhaltenem Betrieb durch Hilfsrückmeldung.

Geben Sie die erwarteten Verhaltensweisen in beobachtbaren Begriffen an: Start, Selbsthaltung, Stopp-Dominanz, Überlast-Abschaltung, kein automatischer Neustart nach Reset.

Dieses Format erzeugt Beweise, die ein Ausbilder, Prüfer oder Personalverantwortlicher tatsächlich prüfen kann. Es spiegelt auch wider, wie echte Fehlersuche kommuniziert werden sollte: System, erwartetes Verhalten, beobachteter Fehler, Korrektur, Ergebnis. Drama ist optional.

1. Systembeschreibung
2. Operative Definition von „korrekt“
3. Kontaktplan-Logik und simulierter Anlagenzustand Fügen Sie das Kontaktplan-Diagramm, die Tag-Zuordnung und das entsprechende simulierte Maschinenverhalten bei.
4. Der injizierte Fehlerfall Zeichnen Sie die spezifische abnormale Bedingung auf, die eingeführt wurde, wie z. B. ein falsch gebundener Hilfskontakt oder eine Stopp-Eingangsinversion.
5. Die vorgenommene Überarbeitung Zeigen Sie die Kontaktplan-Änderung, Parameteränderung oder Tag-Korrektur, die zur Lösung des Problems verwendet wurde.
6. Gelernte Lektionen Geben Sie an, was der Fehler über die Steuerungsphilosophie, Annahmen oder das Inbetriebnahmerisiko offenbart hat.

OLLA Lab passt am besten als Validierungs- und Proben-Ebene vor der Live-Exposition. Sein Wert ist am höchsten, wenn der Benutzer Gewohnheiten aufbaut, die sauber in die beaufsichtigte Ingenieursarbeit übergehen.

Ein glaubwürdiger Workflow sieht so aus:

• Erstellen der Kontaktplan-Logik im browserbasierten Editor
• Binden von Tags und Inspizieren von Variablen über das E/A- und Variablen-Panel
• Ausführen der Sequenz im Simulationsmodus
• Injizieren von Fehlern und Beobachten von Ursache und Wirkung
• Vergleichen des Kontaktplan-Status mit dem simulierten Anlagenverhalten
• Verwenden von 3D- oder WebXR-Szenarien zur Überprüfung räumlicher und operativer Annahmen
• Überarbeiten der Logik und Dokumentieren des Ergebnisses als Ingenieursnachweis

Dieser Workflow ist besonders nützlich für Auszubildende, Ausbilder und Junior-Automatisierungspersonal, da er die Lernschleife komprimiert, ohne vorzugeben, das Risiko aus der realen Welt zu entfernen. Er hilft Benutzern, von „Ich kann einen Strompfad zeichnen“ zu „Ich kann eine Sequenz validieren“ zu gelangen. Das ist ein ernsterer Anspruch, und im Gegensatz zu den meisten ernsten Ansprüchen altert er gut.

- IEC 61508 Überblick über den Standard zur funktionalen Sicherheit - IEC 61131-3 Programmierbare Steuerungen – Programmiersprachen - NIST SP 800-207 Zero Trust Architektur - ISO 9241-110 Ergonomie der Mensch-System-Interaktion - Tao et al. (2019) Digitaler Zwilling in der Industrie (IEEE) - Fuller et al. (2020) Technologien zur Ermöglichung digitaler Zwillinge (IEEE Access) - U.S. Bureau of Labor Statistics - Deloitte Manufacturing Industry Outlook