Wie man Kontaktplan-Logik auf einem iPad mit dem Mobile Editor von OLLA Lab programmiert

Die Programmierung von Kontaktplan-Logik (Ladder Logic) auf einem iPad ist nur dann praktikabel, wenn die Benutzeroberfläche für Touch-Eingaben neu gestaltet wurde. Der Mobile Editor von OLLA Lab ersetzt mausabhängige Aktionen durch Touch-native Gesten wie die per Drag-and-Drop aktivierbare Befehlsauswahl, Pinch-to-Zoom für die Navigation in Strompfaden und direkte E/A-Manipulation in der Simulation, während die Cloud-Infrastruktur die rechenintensive Simulationslast übernimmt.

Die Programmierung von SPS-Logik auf einem iPad ist nicht gleichbedeutend mit dem Ersatz eines Inbetriebnahme-Laptops. Das ist die erste Klarstellung, die vorgenommen werden muss. Herkömmliche SPS-Umgebungen wurden für präzise Cursorsteuerung, dichte Menüs, Hover-Effekte und Tastaturkürzel entwickelt; diese auf ein Glasdisplay zu verkleinern, führt meist zu Fehlbedienungen, verborgenen Kontexten und allgemeinem Frust, der als Mobilität getarnt wird.

OLLA Lab geht einen anderen Weg: Es betrachtet mobiles Programmieren als touch-basiertes Erstellen von Kontaktplänen, Simulationssteuerung und E/A-Interaktion innerhalb einer browserbasierten Umgebung und nicht als Miniaturkopie einer Windows-IDE.

Ampergon Vallis Kennzahl: In internen Betatests der iPad Pro-Oberfläche von OLLA Lab erledigten Anwender eine Standardaufgabe zur Platzierung und Konfiguration eines Einschaltverzögerungs-Timers (TON) 18 % schneller mit der per Drag-and-Drop aktivierbaren radialen Auswahl als mit einem verschachtelten Menü-Workflow per Maus. Methodik: n=24 Anwender; Aufgabe definiert als Platzieren, Tagging und Parametrisieren eines TON-Befehls in einer kontrollierten Editor-Übung; Vergleichsbasis war ein verschachtelter Dropdown-Auswahlfluss im Desktop-Stil; Zeitfenster Februar–März 2026. Dies stützt eine eng gefasste Aussage über die Effizienz der Befehlszusammenstellung bei einer begrenzten Aufgabe. Es stützt nicht die pauschale Behauptung, dass Tablets Desktops bei allen Engineering-Arbeiten übertreffen.

Herkömmliche SPS-Editoren scheitern auf Mobilgeräten, weil sie für die Maus-Ergonomie und nicht für die Touch-Ergonomie entwickelt wurden. Das Problem ist nicht, dass Ingenieure keine Tablets mögen. Das Problem ist, dass Desktop-Interaktionsmodelle auf Präzision und Bedienkonzepten basieren, die Touchscreens nicht zuverlässig bieten.

Das „Dicke-Finger“-Problem ist ein Designproblem, kein Anwenderproblem

Touch-Interaktion erfordert größere und fehlerverzeihendere Ziele als die zeigerbasierte Interaktion. Dies steht im Einklang mit etablierten Richtlinien zur Mensch-System-Interaktion, einschließlich der Prinzipien nach ISO 9241-110 und den praktischen Auswirkungen des Fitts’schen Gesetzes: Auswahlzeit und Fehlerrate verschlechtern sich, wenn Ziele klein, dicht gedrängt oder in Bezug auf die Eingabemethode schwer erreichbar sind.

In SPS-Begriffen bedeutet das:

• winzige Kontakt- oder Spulensymbole werden auf einem Tablet fehleranfällig,
• verschachtelte Rechtsklick-Menüs werden bei Touch-Bedienung langsam und instabil,
• dichte Symbolleisten verbrauchen wertvollen Bildschirmplatz,
• versehentliche Platzierungsfehler werden wahrscheinlicher.

Ein Mauszeiger kann eine schmale UI-Lücke treffen. Eine Fingerspitze kann das nicht.

Touchscreens haben keinen echten Hover-Zustand

Viele Desktop-Engineering-Tools verlassen sich auf Hover-Verhalten, um Tag-Metadaten, Kommentare, Diagnosen oder Konfigurationshinweise anzuzeigen. Tablets bieten diese Interaktion nicht in gleicher Weise. Wenn kritische Informationen hinter einem Hover-Effekt verborgen sind, sind sie effektiv unsichtbar.

Das ist bei der Arbeit mit Kontaktplänen wichtig, da Ingenieure Folgendes sehen müssen:

• Tag-Namen und Zustände,
• Befehlsparameter,
• Analogwerte,
• Alarmschwellenwerte,
• Ausgangsverhalten während der Simulation.

Ein Touch-fähiger Editor muss daher Kontext permanent anzeigen oder durch explizite Gesten erreichbar machen. OLLA Lab löst dies, indem Variablen- und E/A-Sichtbarkeit direkt im Panel verfügbar gehalten werden, anstatt vorauszusetzen, dass ein Cursor über dem richtigen Pixel schwebt.

OLLA Lab übersetzt Desktop-Aktionen in eine kleine Anzahl von Touch-nativen Interaktionen. Das ist die zentrale UI-Entscheidung. Es verlangt vom Anwender nicht, Windows auf einem Tablet zu imitieren; es bildet gängige Aufgaben der Kontaktplanerstellung auf Gesten ab, die auf Mobilgeräten mechanisch sinnvoll sind.

Operativ bedeutet mobiles Programmieren in diesem Kontext:

• Platzieren von Kontaktplan-Befehlen durch Touch-Auswahl,
• Navigieren durch Strompfade mittels Pinch- und Pan-Gesten,
• Anpassen von Werten durch direkte Steuerelemente,
• Umschalten simulierter E/A-Zustände ohne Hardware.

Es bedeutet nicht, native SPS-Projektdateien auf dem iPad zu kompilieren oder herstellerspezifische Engineering-Workstations für den Einsatz zu ersetzen.

Drag-aktivierte Tortenmenüs ersetzen den Rechtsklick-Workflow

Radiale Menüs sind für Touch-Bedienung generell besser geeignet als tiefe lineare Menüs, da sie den Weg verkürzen und Optionen um den Kontaktpunkt herum präsentieren. Dies ist ein gut etabliertes UI-Muster für Stift- und Touch-Systeme, bei denen die richtungsabhängige Auswahl schneller und weniger fehleranfällig sein kann als die Suche in gestapelten Listen.

Im Mobile Editor von OLLA Lab ist die Logik einfach:

- Aktion: Langes Drücken auf einen leeren Strompfad oder Einfügepunkt. - Ergebnis: Ein radiales Tortenmenü erscheint in der Nähe des Daumens des Anwenders. - Auswahl: Ziehen Sie in eine Richtung, um einen Befehlstyp zu platzieren.

Eine typische Zuordnung könnte so aussehen:

- Oben: Schließer (Normally Open) - Links: Öffner (Normally Closed) - Rechts: Spule - Unten: Mathe- oder Funktionsbaustein - Sekundärer Zweig: Timer, Zähler, Komparator oder PID-bezogene Befehle

Der wichtige Punkt ist nicht die exakte Himmelsrichtung. Der wichtige Punkt ist, dass die Auswahl in der Nähe des Intentionspunktes erfolgt, ohne dass eine Reise durch eine komprimierte Symbolleiste erforderlich ist.

Multi-Touch-Zoom ersetzt das Scrollrad-Denken

Große Kontaktplan-Programme schaffen ein Skalierungsproblem auf mobilen Bildschirmen. Ingenieure benötigen sowohl architektonische Übersicht als auch lokale Details. Eine feste Zoomstufe reicht nicht aus.

Pinch-to-Zoom- und Pan-Gesten lösen dies auf eine Weise, die bereits von Karten- und CAD-Navigation bekannt ist:

• Herauszoomen, um die Sequenzstruktur über mehrere Strompfade hinweg zu prüfen,
• Hineinzoomen, um einen bestimmten Timer-Vorgabewert oder Komparator-Schwellenwert zu bearbeiten,
• Seitliches oder vertikales Schwenken durch die Logik, ohne auf winzige Bildlaufleisten angewiesen zu sein.

Das ist nicht nur eine Frage des Komforts. Es entscheidet darüber, ob ein mobiler Editor für echte Inspektionsarbeiten oder nur für Spielbeispiele nutzbar ist.

Wischen und direkte Manipulation ersetzen Force-Tag-Menüs in der Simulation

Simulation wird nützlich, wenn der Anwender Bedingungen schnell ändern und Ursache-Wirkungs-Zusammenhänge klar beobachten kann. Das Variablen-Panel von OLLA Lab unterstützt dies, indem es Tag-Zustände und Steuerelemente direkt offenlegt.

In der Praxis kann ein Anwender:

• boolesche Eingänge umschalten,
• die Ausgangsreaktion beobachten,
• Analogwerte anpassen,
• PID-bezogene Variablen prüfen,
• den Zustand des Strompfads mit dem simulierten Anlagenverhalten vergleichen.

Das ist die richtige operative Definition des Simulationsnutzens: nicht „der Strompfad sieht korrekt aus“, sondern „die Logik kann gegen sich ändernde Prozessbedingungen getestet werden“.

Ein iPad kann die Schnittstellen- und Rendering-Seite eines Simulations-Workflows bewältigen, aber der Anspruch benötigt klare Grenzen. Das Tablet fungiert nicht als physische SPS und ersetzt nicht die deterministische Controller-Ausführung in einem Live-Prozess.

Das iPad ist der Rendering-Client; die Cloud übernimmt die schwerere Simulationslast

OLLA Lab ist webbasiert. Auf einem Tablet ist das Gerät primär verantwortlich für:

• das Rendern der Editor-Oberfläche,
• die Anzeige von 3D- oder WebXR-Szenen, sofern verfügbar,
• die Verarbeitung von Touch-Eingaben,
• die Darstellung von Live-Zustandsänderungen für den Anwender.

Die schwerere Arbeit liegt an anderer Stelle in der Architektur, einschließlich:

• Simulationsausführung,
• Verarbeitung des Kontaktplan-Zustands innerhalb der Plattform,
• Synchronisation von Anwenderaktionen und Szenario-Zustand,
• Übermittlung aktualisierter Werte zurück an den Client.

Diese Unterscheidung ist wichtig, weil sie erklärt, warum die mobile Nutzung machbar ist. Vom iPad wird nicht verlangt, isoliert einen industriellen Controller zu imitieren. Es fungiert als Frontend für eine Cloud-basierte Simulationsumgebung.

Webbasiertes Rendering ist im industriellen Betrieb bereits normal

Tablet-basierte industrielle Schnittstellen sind nicht mehr ungewöhnlich. Bediener und Vorgesetzte nutzen bereits browserbasierte HMIs und Dashboards auf Mobilgeräten in vielen Anlagen, einschließlich Systemen, die mit modernen responsiven SCADA- und HMI-Frameworks erstellt wurden.

Dieser Präzedenzfall beweist nicht, dass jede Engineering-Aufgabe auf ein Tablet gehört. Er stützt jedoch eine engere Schlussfolgerung: Die Nutzung eines Tablets zur Beobachtung, Interaktion und Erprobung von industriellem Steuerungsverhalten ist konzeptionell nicht ungewöhnlich.

Simulationsbereit sollte operativ definiert werden, nicht dekorativ. Bei der Nutzung von Ampergon Vallis bedeutet es, dass ein Ingenieur Steuerungslogik gegen realistisches Prozessverhalten beweisen, beobachten, diagnostizieren und härten kann, bevor diese Logik einen Live-Prozess erreicht.

Dazu gehört die Fähigkeit:

• beabsichtigtes Sequenzverhalten zu verifizieren,
• E/A-Zustandsänderungen zu prüfen,
• Freigaben und Verriegelungen zu testen,
• anormale Bedingungen einzuspielen,
• Fehlerreaktionen zu beobachten,
• die Logik zu überarbeiten,
• zu bestätigen, dass der Kontaktplan-Zustand mit dem simulierten Anlagenzustand übereinstimmt.

Das ist ein weitaus stärkerer Standard als „kann einen Strompfad korrekt zeichnen“.

Digital-Twin-Validierung dreht sich um Verhaltenskorrespondenz

In diesem Artikel bedeutet Digital-Twin-Validierung, Kontaktplan-Logik gegen ein realistisches virtuelles Anlagenmodell zu testen und zu prüfen, ob sich die Steuerungssequenz unter normalen und anormalen Bedingungen wie beabsichtigt verhält.

Beobachtbare Verhaltensweisen umfassen:

• ein Förderband, das nur startet, wenn Freigaben wahr sind,
• eine korrekt rotierende Pumpensequenz (Lead-Lag),
• ein Alarm-Komparator, der beim definierten Schwellenwert auslöst,
• eine PID-gesteuerte Variable, die auf Sollwert- oder Störgrößenänderungen reagiert,
• eine Not-Aus-Kette, die Ausgänge in der Simulation in einen sicheren Zustand zwingt.

Die nützliche Unterscheidung ist diese: visueller Realismus ist zweitrangig; Verhaltenskorrespondenz ist primär.

Der Hauptvorteil für das Engineering ist nicht die Neuheit. Es ist die reduzierte Reibung für Proben, Überprüfungen und die wiederholte Auseinandersetzung mit Steuerungsverhalten. Das ist wichtig, weil Urteilsvermögen bei der Inbetriebnahme aus Wiederholungen von Ursache, Wirkung, Fehler und Korrektur entsteht.

Mobiler Zugriff erhöht die Übungshäufigkeit, nicht die formale Standortkompetenz

OLLA Lab sollte hier vorsichtig positioniert werden. Ein mobiler Editor kann die Anzahl der Male erhöhen, die ein Lernender oder Junior-Ingenieur mit Logik und simulierter Ausrüstung interagiert. Er schafft für sich allein keine Feldkompetenz, Zertifizierung oder Befugnis, ein Live-System zu modifizieren.

Was er glaubwürdig unterstützen kann, ist das Üben von Aufgaben, die Arbeitgeber oft ungern unerfahrenem Personal an echter Ausrüstung überlassen:

• Logikvalidierung,
• E/A-Verfolgung,
• Sequenzprüfung,
• Testen von anormalen Zuständen,
• Alarm- und Auslöseprüfung,
• Überarbeitung nach Fehlern.

Das ist ein begrenzter, aber wichtiger Anspruch.

Die Workstation-Barriere ist real, besonders bei wiederholten kurzen Sitzungen

Engineering-Laptops, lokale Installationen und Software-Stacks der Anbieter erzeugen Reibung. Manchmal ist diese Reibung gerechtfertigt. Manchmal verhindert sie einfach nützliche Wiederholungen.

Ein Tablet-basierter Workflow hilft in engeren, aber praktischen Situationen:

• Überprüfung einer Motorstartsequenz abseits der Workstation,
• Testen einer kleinen Logikänderung in der Simulation vor der Rückkehr in die Haupt-Engineering-Umgebung,
• Durchgehen eines Trainingsszenarios ohne Labor-PC,
• Nutzung von Leerlaufzeiten für strukturiertes Üben statt gar keiner Übung.

Kein ernsthafter Ingenieur denkt, dass ein iPad eine vollständige Inbetriebnahmestation ersetzt. Aber als Übungsoberfläche kann es deutlich besser sein, als auf ideale Bedingungen zu warten, die nie eintreten.

OLLA Lab wird operativ nützlich, wenn die mobile Schnittstelle mit szenariobasierter Validierung statt mit isolierter Strompfad-Bearbeitung verknüpft ist. Die Plattform umfasst realistische industrielle Szenarien, Simulationsmodus, Variablensichtbarkeit, Analog- und PID-Tools sowie Digital-Twin-orientierte Übungen, die es Anwendern ermöglichen, Steuerungsverhalten im Kontext zu testen.

Das ist wichtig, weil industrielle Automatisierung nicht nur aus Befehlssyntax besteht. Es ist Sequenzlogik unter Einschränkungen.

Szenariobasiertes Üben lehrt mehr als nur Befehlsplatzierung

Ein realistisches Szenario kann vom Anwender verlangen, mit Folgendem umzugehen:

• Freigaben,
• Rückmeldungen,
• Alarmschwellenwerten,
• Auslösebedingungen,
• Analogskalierung,
• PID-Reaktion,
• Schrittsequenzierung,
• Neustartverhalten nach einem Fehler.

Beispiele aus dem dokumentierten Szenariomodell von OLLA Lab umfassen Muster wie:

• Lead-Lag-Pumpensteuerung,
• Sequenzierung von Förderbändern oder Materialhandhabung,
• HVAC- oder Lüftungsverhalten,
• Prozesslogik für Wasser und Abwasser,
• Alarm-Komparatoren,
• Not-Aus-Ketten,
• Regelkreise mit Analogvariablen.

Hier wird der mobile Zugriff mehr als eine UI-Spielerei. Er wird zu einer praktischen Möglichkeit, Inbetriebnahmelogik in einer sicheren Umgebung zu proben.

Das Variablen-Panel ist ein Diagnose-Tool, kein bloßes Komfort-Panel

Das Variablen-Panel verbindet den Kontaktplan-Zustand mit dem Prozesszustand.

Eine nützliche mobile Simulationsschnittstelle sollte es dem Anwender ermöglichen, Folgendes zu prüfen:

• boolesche Eingänge und Ausgänge,
• Analogwerte,
• Tag-Details,
• PID-bezogene Variablen,
• Szenariobedingungen,
• Zustandsänderungen im Verlauf eines Tests.

Ohne diese Sichtbarkeit ist mobiles Editieren meist nur Diagramm-Anordnung. Mit ihr kann der Anwender diagnostizieren, warum eine Sequenz sich korrekt verhält oder eben nicht.

Eine Screenshot-Galerie ist ein schwacher Beweis. Engineering-Nachweise sollten Systemabsicht, Testbedingungen, Fehlerverhalten und Revisionslogik in einem kompakten, überprüfbaren Format zeigen.

Verwenden Sie diese Struktur:

Definieren Sie den Prozess oder die Maschine, die gesteuert wird. Beispiel: Duplex-Pumpstation mit Lead-Lag-Pumpenrotation, Hochalarm und manuellem Override.

Geben Sie an, was korrektes Verhalten in beobachtbaren Begriffen bedeutet. Beispiel: Pumpe A startet bei Schwellenwert 1, Pumpe B unterstützt bei Schwellenwert 2, beide stoppen bei niedrigem Pegel, Alarm löst bei Hoch-Hoch-Pegel aus und Not-Aus entfernt Ausgangsbefehle.

Führen Sie eine realistische anormale Bedingung ein. Beispiel: Rückmeldung schlägt fehl, Schwimmerschalter klemmt, Analogeingang driftet oder Ventil-Offen-Bestätigung kommt nie an.

Erklären Sie die Logikänderung, die als Reaktion vorgenommen wurde. Beispiel: Timeout-Logik hinzufügen, Freigabe-Handling überarbeiten, Alarm-Komparator einfügen oder Neustartsequenz härten.

1. Systembeschreibung
2. Operative Definition von „korrekt“
3. Kontaktplan-Logik und simulierter Anlagenzustand Zeigen Sie die relevanten Strompfade und den entsprechenden simulierten Maschinen- oder Prozesszustand. Der Punkt ist, Logik mit Verhalten zu verbinden, nicht den Strompfad isoliert zu bewundern.
4. Der eingespielte Fehlerfall
5. Die vorgenommene Revision
6. Gelernte Lektionen Halten Sie fest, was der Test über Sequenzannahmen, Fehlerbehandlung, Bedienersichtbarkeit oder Inbetriebnahmerisiken offenbart hat.

Dieses Format erzeugt etwas, das eher einem Engineering-Nachweis entspricht und weiter von dekorativen Screenshots entfernt ist.

Die mobile Interaktion kann als strukturiertes Ereignis zum Aufbau von Kontaktplänen dargestellt werden. Die exakte interne Implementierung ist plattformspezifisch, aber die konzeptionelle Abbildung ist klar: Eine Geste führt zu einer definierten Befehlsplatzierung, die mit einem Tag und Datentyp verknüpft ist.

Beispielstruktur:

- Strompfad: 1 - Gesteneingabe: Radial_Oben - Befehl platziert: XIC (Schließer) - Tag zugewiesen: Motor_Start_Taster - Datentyp: BOOL

Dieses Beispiel ist nützlich, weil es den eigentlichen Punkt der Schnittstelle zeigt: Touch-Gesten sind keine dekorativen UX-Spielereien; sie sind Eingabemethoden, die sich in formale Steuerungslogik-Objekte auflösen.

Die Grenzen sind wichtig, und sie klar zu benennen, verbessert die Glaubwürdigkeit.

Ein iPad-basierter Editor ist kein Ersatz für:

• herstellerspezifische Bereitstellungsumgebungen,
• Live-Online-Änderungen an Produktions-Controllern,
• vollständige Aufgaben zur Integration in Anlagennetzwerke,
• formale Aktivitäten im Sicherheitslebenszyklus,
• die Abnahme von Steuerungsänderungen vor Ort.

OLLA Lab ist am besten als Validierungs- und Probenumgebung zum Lernen, Testen und Üben von risikoreichen Steuerungsaufgaben in einer sicheren Umgebung zu verstehen. Das ist ein ernsthafter Anwendungsfall. Er benötigt keine übertriebenen Behauptungen.

Sie können Kontaktplan-Logik effektiv auf einem iPad programmieren, wenn der Editor von Anfang an für Touch konzipiert ist. Das bedeutet größere Interaktionsziele, direkte Gestenabbildung, permanente Zustandssichtbarkeit und Cloud-basierte Simulation statt eines beengten Desktop-Klons in einem Browser-Tab.

Der Mobile Editor von OLLA Lab ist glaubwürdig, weil er innerhalb dieser Grenzen bleibt. Er unterstützt visuelle Kontaktplanerstellung, Simulation, E/A-Interaktion und Digital-Twin-orientierte Validierung in einer webbasierten Umgebung, die geräteübergreifend funktioniert. Er erhebt nicht den Anspruch, ein Tablet in einen Inbetriebnahme-Laptop zu verwandeln, was eine vernünftige Grenze ist.

Weiterführende Lektüre

• Für einen breiteren Blick auf browserbasierte Automatisierungspraxis besuchen Sie unseren Cloud Native Training Hub.
• Für das Design von Workflows auf Befehlsebene lesen Sie „Mastering Timers and Counters on a Touch Interface“.
• Für die Infrastrukturseite des browserbasierten Engineerings lesen Sie „The End of the Workstation Requirement“.
• Bereit, den mobilen Workflow direkt zu testen? Melden Sie sich von Ihrem Tablet bei OLLA Lab an.

- IEC 61508 Functional safety standard overview - IEC 61131-3 Programmable controllers programming languages - NIST SP 800-207 Zero Trust Architecture - ISO 9241-110 Ergonomics of human-system interaction - Tao et al. (2019) Digital twin in industry (IEEE) - Fuller et al. (2020) Digital twin enabling technologies (IEEE Access) - U.S. Bureau of Labor Statistics - Deloitte Manufacturing Industry Outlook