Wie man Kontaktplan-Logik simultan gemeinsam entwirft: Echtzeit-SPS-Kollaboration in OLLA Lab

Echtzeit-SPS-Kollaboration bedeutet nicht den Austausch von Live-Code an einer laufenden Anlage. In OLLA Lab bedeutet es gleichzeitiges, virtuelles Co-Design und Review: Mehrere authentifizierte Benutzer betrachten dieselbe Kontaktplan-Sitzung, synchronisierte E/A-Zustände und Simulationsverhalten über eine Cloud-native Browserumgebung unter Verwendung von JSON-Serialisierung und WebSocket-Updates.

Traditionelle SPS-Kollaboration ist meist gar keine Kollaboration. Es ist eine serialisierte Dateiverwaltung: Ein Ingenieur bearbeitet ein lokales Projekt, exportiert eine proprietäre Datei, und jemand anderes öffnet sie später, sofern Softwareversion, Firmware-Ziel und Lizenzierung zufällig übereinstimmen. Der Dateiname wird dabei oft zum eigenen Vorfallbericht.

OLLA Lab adressiert ein engeres und nützlicheres Problem: das gleichzeitige virtuelle Co-Design und die Überprüfung von Kontaktplan-Logik innerhalb einer simulierten Umgebung. In internen Benchmarks von Ampergon Vallis schlossen Teams, die OLLA Lab mit synchronisierten Browsersitzungen nutzten, Überprüfungs- und Korrekturzyklen 68 % schneller ab als Teams, die lokale SPS-Projektdateien asynchron austauschten [Methodik: n=24 Fernmentoring- und Dozenten-Review-Workflows; Aufgabendefinition = Identifizierung, Erklärung und Korrektur von Kontaktplan-Logikfehlern während Simulationsübungen; Basisvergleich = asynchroner Austausch lokaler Projektdateien und schriftliches Feedback; Zeitfenster = Januar–März 2026]. Diese Metrik stützt eine Workflow-Aussage zur Review-Geschwindigkeit. Sie stützt keine Aussagen zur Anlagenreife, Zertifizierung oder Feldkompetenz.

Diese Unterscheidung ist wichtig. Syntax ist nicht gleich Einsatzfähigkeit, und Kollaboration ist nicht das Hot-Swapping von Live-Logik in einen laufenden Prozess.

Klassische SPS-IDEs scheitern an Concurrent Engineering, weil die meisten auf lokalem Projektbesitz basieren und nicht auf einem geteilten Status. Die Projektdatei ist typischerweise ein monolithisches Artefakt, das an eine Desktop-Anwendung, eine Steuerungsfamilie und oft an einen spezifischen Hersteller-Workflow gebunden ist.

In der Praxis führt dies zu vier wiederkehrenden Einschränkungen:

• Projektlogik wird in proprietären Formaten gespeichert. Dateien wie `.ACD` oder `.zap16` sind nicht für transparentes, browsernatives Diffing oder die für Menschen lesbare Änderungshistorie konzipiert.
• Der Simulationsstatus ist lokal. Zeitgeber-Akkumulatoren, Zählerwerte, erzwungene Bits (Forced Bits), Analogwerte und Zwischenlogikzustände existieren während einer Sitzung nur auf einem Rechner.
• Die Überprüfung wird durch Dateitransfer verzögert. Ein Junior-Ingenieur sendet eine Datei, ein Senior-Ingenieur öffnet sie später, und die Erklärung trifft erst ein, wenn der Moment der Verwirrung bereits vergangen ist.
• Versionskonflikte häufen sich schnell. Software-Revisionen, Firmware-Diskrepanzen, Add-on-Abhängigkeiten und Lizenzbeschränkungen machen aus einer einfachen Überprüfung administrative Arbeit.

Die Kernbeschränkung ist architektonisch, nicht kulturell. Desktop-SPS-Tools wurden für die Geräteprogrammierung und Herstellerintegration gebaut, nicht für pädagogische Echtzeit-Kopräsenz. Das ist eine andere Aufgabe.

Was dies für Ausbildung und Mentoring bedeutet

Die Qualität des Mentorings sinkt, wenn die Sichtbarkeit des Status verschwindet. Ein markierter Screenshot kann eine Sprosse zeigen, aber er kann nicht zeigen, was der Zeitgeber tat, als die Freigabebedingung abfiel, oder warum der Ausgang einen Scan-Zyklus zu früh setzte.

Diese Lücke verlangsamt die Ausbildung des Urteilsvermögens in der Steuerungstechnik. Ingenieure lernen schneller, wenn sie Kausalität beobachten können, nicht nur Syntax. Eine Sprosse, die „gut aussieht“, hat schon viele ruhige Nachmittage beendet.

OLLA Lab synchronisiert Kontaktplan-Logik für mehrere Benutzer, indem Logik und Status in einer Cloud-nativen Form dargestellt werden, die inkrementell an verbundene Browser übertragen werden kann. Der wichtige Wechsel erfolgt von der lokalen binären Projektverwaltung hin zum geteilten, serialisierten Sitzungsstatus.

Operativ bedeutet Echtzeit-SPS-Kollaboration in OLLA Lab: Mehrere authentifizierte Benutzer können dieselbe aktive Kontaktplan-Sitzung betreten, dieselbe Logik einsehen, synchronisierte Variablen- und E/A-Änderungen beobachten und an simulationsbasierten Reviews teilnehmen, ohne Dateien hin und her zu schicken.

Der OLLA Lab-Synchronisations-Stack

#### 1. JSON-Serialisierung

OLLA Lab speichert Kontaktplan-Strukturen in einem leichtgewichtigen, serialisierten Format anstelle eines herstellerspezifischen Desktop-Binärformats. Das ist wichtig, da textstrukturierte Daten mit weitaus weniger Reibung inspiziert, übertragen und aktualisiert werden können als undurchsichtige kompilierte Dateien.

Ein vereinfachtes Beispiel sieht so aus:

rung: 2, "elements": [ { "type": "contact", "tag": "Start_PB", "mode": "NO" }, { "type": "contact", "tag": "Motor_OL", "mode": "NC" }, { "type": "coil", "tag": "Motor_Run" } ]

Dieses Beispiel dient der Veranschaulichung, nicht als vollständiges Plattform-Schema. Sein Zweck ist einfach: zu zeigen, warum Cloud-Synchronisation machbar ist, wenn das Logikmodell lesbar, strukturiert und update-freundlich ist.

#### 2. WebSocket-Protokoll

OLLA Lab nutzt eine persistente bidirektionale Kommunikation zwischen Browser-Clients und dem Server, sodass Änderungen sofort propagiert werden können. WebSockets eignen sich gut für dieses Problem, da sie die Latenz und den Overhead wiederholter Request-Response-Abfragen vermeiden.

Einfach ausgedrückt: Die Sitzung bleibt offen und der Status bewegt sich kontinuierlich.

#### 3. Differenzielle Updates

OLLA Lab muss nicht das gesamte Projekt erneut senden, wenn sich ein einzelnes Bit ändert. Es kann nur die geänderte Logik oder das geänderte Statuselement – wie einen Tag-Übergang, eine Sprossenbearbeitung oder ein Zeitgeber-Update – an verbundene Benutzer übertragen.

Das reduziert die Bandbreitenlast und verbessert die Reaktionsfähigkeit. Kleine Änderungen sollten als kleine Änderungen übertragen werden. Ingenieurssysteme profitieren selten von theatralischem Übermaß.

Was Benutzer tatsächlich beobachten

Die Architektur ist wichtig, weil sie beobachtbare Verhaltensweisen erzeugt, nicht weil „Cloud-native“ modern klingt.

In einer synchronisierten OLLA Lab-Sitzung können Benutzer:

• dasselbe aktive Kontaktplan-Projekt im Browser betrachten,
• geteilte Simulationsstatusänderungen beobachten,
• Variablen, Tags und E/A aus demselben Sitzungskontext überwachen,
• Ursache und Wirkung gemeinsam überprüfen, während die Logik in der Simulation läuft,
• Dozenten-geführte oder teambasierte Workflows durch Sharing- und Review-Funktionen unterstützen.

Die Produktdokumentation unterstützt den geteilten Zugriff, Projektfreigaben, Studentenverwaltung und Benotungs-Workflows. Sie rechtfertigt nicht die Behauptung eines unsicheren, gleichzeitigen Live-Anlageneinsatzes oder einer Controller-Hot-Edit-Kollaboration an physischer Ausrüstung. Diese Grenze sollte intakt bleiben.

In OLLA Lab bedeutet Kollaboration gleichzeitiges virtuelles Co-Design und Review in einer simulierten Umgebung. Es bedeutet nicht, dass mehrere Ingenieure über das öffentliche Internet Live-Produktionslogik an einer laufenden Maschine bearbeiten. Das eine ist ein Trainings- und Validierungs-Workflow; das andere ist der Weg zu einem Inbetriebnahmetreffen, das niemand genießt.

Diese operative Definition hat drei Teile:

- Gleichzeitig: Mehr als ein authentifizierter Benutzer kann an derselben aktiven Sitzung teilnehmen. - Virtuelles Co-Design und Review: Benutzer inspizieren, diskutieren und verfeinern Kontaktplan-Logik gemeinsam innerhalb der Plattform. - Geteilte Simulationssichtbarkeit: Benutzer beobachten synchronisiertes Logikverhalten, Variablenstatus und Gerätereaktion im selben Sitzungskontext.

Diese Definition ist bewusst eng gefasst. Enge Definitionen sind meist nützlicher als breite Versprechen.

Live-Co-Design verbessert das Lernen, da es das Intervall zwischen Fehler, Beobachtung, Erklärung und Korrektur verkürzt. In der Steuerungstechnik ist dieses Intervall wichtiger, als die meisten zugeben.

Ein Junior-Ingenieur baut keine Intuition auf, indem er drei Tage später eine korrigierte Datei erhält. Er baut sie auf, indem er im Moment sieht, warum eine Verriegelung versagte, warum ein Selbsthaltekreis unerwartet hielt oder warum eine zeitbasierte Sequenz den falschen Übergang erzeugte.

Wie Dozenten und Senior-Ingenieure es nutzen

In OLLA Lab kann ein Dozent oder Senior-Reviewer in derselben browserbasierten Umgebung wie der Lernende arbeiten und die Logik anhand des aktiven Simulationsverhaltens bewerten, anstatt nur statische Screenshots zu nutzen.

Dies unterstützt mehrere hochwertige Lehrmethoden:

- Live-Sprossen-Review: Inspizieren Sie genau die Sprosse, die der Lernende gerade bearbeitet. - Geteilte E/A-Verfolgung: Verfolgen Sie, wie sich ein Eingangssignal durch Freigaben, Zeitgeber, Komparatoren und Ausgänge ausbreitet. - Sofortige Fehlersuche: Stoppen, starten, Eingänge umschalten und resultierende Statusänderungen ohne Hardware beobachten. - Kontextuelle Korrektur: Erklären Sie nicht nur, was falsch ist, sondern warum sich das System so verhalten hat.

Der Unterschied ist nicht kosmetisch. Es ist der Unterschied zwischen der Benotung eines Diagramms und der Überprüfung eines Steuerungssystems in Bewegung.

Wo Yaga passt

GeniAI, der OLLA Lab KI-Laborassistent, ist am besten als unmittelbare Unterstützungsebene innerhalb des Lern-Workflows zu verstehen. Er kann Hilfe beim Onboarding, Korrekturvorschläge, Konzepterklärungen und Kontaktplan-Anleitungen bieten, wenn kein Dozent verfügbar ist oder ein Lernender feststeckt.

Das ist nützlich, weil Dynamik in der technischen Ausbildung zählt. Es ist jedoch begrenzt: KI-Anleitung ist kein Ersatz für technisches Review, Inbetriebnahmeverantwortung oder formale Sicherheitsvalidierung.

Aktuelle Literatur zu KI-gestützter Ingenieursarbeit stützt im Allgemeinen die engere Behauptung, dass KI Geschwindigkeit und Zugänglichkeit verbessern kann, während sie dennoch eine strukturierte Aufsicht erfordert, insbesondere in sicherheitsrelevanten Bereichen (Kaswan et al., 2025; Sandborn, 2024). Schnelle Unterstützung ist nicht dasselbe wie deterministische Korrektheit.

Teams validieren digitale Zwillinge kollaborativ, indem sie das Kontaktplan-Verhalten gegen das simulierte Geräteverhalten in derselben Review-Schleife vergleichen. Das verlagert die Übung von „kompiliert die Sprosse?“ zu „verhält sich das System unter realistischen Bedingungen korrekt?“.

Hier wird OLLA Lab operativ nützlich.

Die Plattform umfasst 3D/WebXR/VR-Industriesimulationen, Szenarioauswahl, Live-Variablen, Analog-Tools und PID-bezogene Steuerungen. In dieser Umgebung kann ein Benutzer Logik oder Parameter anpassen, während ein anderer die resultierende Gerätereaktion im digitalen Zwilling beobachtet.

### Ein praktisches Beispiel: Überprüfung einer Pumpenstation

Betrachten Sie ein Szenario einer Pumpenstation mit Haupt-/Reserve-Pumpensteuerung, niveaubasierten Starts, Alarmschwellen und Rückmeldungen.

Eine kollaborative Validierungssitzung könnte so aussehen:

- Die Sitzung verifiziert, ob die Logik:

• Benutzer A überprüft die Kontaktplan-Sequenzierung für die Pumpenwechsel- und Hochalarm-Logik.
• Benutzer B überwacht das simulierte Stationsverhalten und Variablenänderungen.
• Das Team injiziert einen anormalen Zustand wie eine fehlende Rückmeldung, verzögerten Niveauabfall oder einen oszillierenden Analogeingang.
• die korrekte Pumpe startet,
• bei der richtigen Schwelle auf Reservebetrieb eskaliert,
• bei fehlender Antwort alarmiert,
• Flattern oder instabile Übergänge vermeidet,
• sauber in den Normalzustand zurückkehrt.

Das ist eine bessere Annäherung an das Urteilsvermögen bei der Inbetriebnahme als reine Syntax-Übungen. Es ist immer noch keine Anlagenkompetenz, aber es trainiert die richtige Art des Denkens.

### Operative Definition: „Simulation-Ready“

Ein Simulation-Ready-Ingenieur ist nicht einfach jemand, der Kontaktplan-Syntax schreiben kann. In der Verwendung bei Ampergon Vallis bedeutet der Begriff einen Ingenieur, der Steuerungslogik gegen realistisches Prozessverhalten beweisen, beobachten, diagnostizieren und härten kann, bevor sie einen Live-Prozess erreicht.

Diese Definition ist operativ, nicht aspirativ. Sie beinhaltet die Fähigkeit:

• zu definieren, wie korrektes Verhalten aussieht,
• E/A und internen Status während der Ausführung zu überwachen,
• anormale Bedingungen zu injizieren,
• den Kontaktplan-Status mit dem simulierten Gerätestatus zu vergleichen,
• Logik nach einem Fehler zu überarbeiten,
• zu verifizieren, dass die Überarbeitung den beobachteten Fehler behebt, ohne neue zu schaffen.

Das ist die nützliche Schwelle. Syntax ohne Validierung ist nur saubere Handschrift.

Kollaborative Simulation reduziert einige Risiken vor dem Einsatz, indem sie das Logikverhalten vor der Hardware-Interaktion offenlegt, ersetzt aber keine formalen Lebenszyklusverpflichtungen. Diese Unterscheidung ist in jeder ernsthaften Diskussion über Automatisierungstraining wesentlich.

Normen wie IEC 61508 betonen Lebenszyklusdisziplin, Gefahrenanalyse, Verifizierung, Validierung und Kompetenzmanagement in sicherheitsbezogenen Systemen (IEC, 2010). Eine simulierte Umgebung kann Teile dieses Denkens unterstützen – insbesondere frühe Verifizierung, Fehlerproben und Design-Reviews –, verleiht aber keine SIL-Qualifizierung, Abnahme vor Ort oder Konformität mit funktionaler Sicherheit durch Assoziation.

Eine begrenzte Aussage ist die glaubwürdige:

- Unterstützt: Simulation kann Beobachtbarkeit, Wiederholbarkeit und frühzeitige Logiküberprüfung verbessern. - Vernünftige Schlussfolgerung: Kollaborative Simulation kann Ingenieuren helfen, das Denken bei anormalen Zuständen zu üben und einige vermeidbare Designfehler vor dem Feldeinsatz zu reduzieren. - Nicht unterstützt: Simulation allein beweist Einsatzreife, Sicherheitskonformität oder operative Kompetenz an einer Live-Anlage.

Die Industrie hat dies wiederholt gelernt, meist auf die teure Art.

Warum Review digitaler Zwillinge dennoch wichtig ist

Digitale Zwillinge sind wertvoll, weil sie es Teams ermöglichen, Interaktionen zwischen Steuerungslogik und Prozessverhalten unter Bedingungen zu testen, die auf physischen Systemen schwer, unsicher oder kostspielig wiederholt zu inszenieren sind. Aktuelle Industrieliteratur unterstützt ihren Einsatz für Validierung, Training und operative Analyse, wenn der Modellumfang klar definiert ist und die Grenzen verstanden werden (Tao et al., 2019; Jones et al., 2020; Boschert & Rosen, 2016).

Der entscheidende Ausdruck ist klar definiert. Ein digitaler Zwilling ist nur so nützlich wie seine Treue zu der Entscheidung, die Sie testen möchten.

OLLA Lab verwaltet Trainings-Workflows durch Sharing, Studentenverwaltung, Einladungs-Flows sowie Benotungs- oder Review-Funktionen, die in die Plattform integriert sind. Das ist wichtig, da viele Trainingsengpässe administrativ sind, bevor sie technisch werden.

Eine webbasierte Umgebung ändert das Bereitstellungsmodell:

| Workflow-Bereich | Klassisches Labor-Modell | OLLA Lab-Workflow | |---|---|---| | Bereitstellung | IT installiert Software auf mehreren Rechnern oder VMs | Benutzer greifen über Browser und Einladungs-/Sharing-Workflows zu | | Projekteinreichung | Studenten laden Dateien, Exporte oder gezippte Projekte hoch | Lernende teilen Projekte/Sitzungen über Plattform-Workflows | | Überprüfung | Dozent öffnet lokale Dateien und löst Kompatibilitätsprobleme | Dozent überprüft innerhalb der Browserumgebung | | Simulationszugriff | Oft an einen Rechner und einen Software-Stack gebunden | Verfügbar innerhalb derselben webbasierten Trainingsumgebung | | Benotungsunterstützung | Externes LMS plus manuelle Dateiverwaltung | Plattform beinhaltet Benotungs-/Review-Workflows |

Das ist nicht glamourös, aber operativ wichtig. Trainingsprogramme scheitern oft an der Logistik, lange bevor sie an der Pädagogik scheitern.

Ingenieure sollten kollaborative Simulationsarbeit als kompakten Korpus an Ingenieursnachweisen dokumentieren, nicht als Screenshot-Galerie. Screenshots beweisen, dass ein Bildschirm existierte. Sie beweisen nicht, dass ein Steuerungsproblem verstanden wurde.

Verwenden Sie diese Struktur:

Geben Sie das erwartete Verhalten in testbaren Begriffen an: Startbedingungen, Stoppbedingungen, Alarmschwellen, Freigaben, Triplogik, Sequenzreihenfolge, analoge Stabilität oder PID-Antwortkriterien.

Beschreiben Sie die eingeführte anormale Bedingung: fehlende Rückmeldung, klemmender Eingang, verrauschtes Analogsignal, verzögerte Aktuatorreaktion, verlorene Freigabe oder inkorrekter Sequenzübergang.

1. Systembeschreibung Definieren Sie den Prozess oder die Maschine, die gesteuert wird, die wichtigsten E/A, das Betriebsziel und die relevante Sequenz oder den Regelkreis.
2. Operative Definition von „korrekt“
3. Kontaktplan-Logik und simulierter Gerätestatus Zeigen Sie die implementierte Logik und das entsprechende simulierte Maschinen- oder Prozessverhalten im Normalbetrieb.
4. Der injizierte Fehlerfall
5. Die vorgenommene Überarbeitung Protokollieren Sie die Logikänderung, Parameteranpassung oder Verriegelungsüberarbeitung, die zur Behebung des beobachteten Problems verwendet wurde.
6. Gelernte Lektionen Erklären Sie, was der Fehler über Sequenzierung, Beobachtbarkeit, Fehlerbehandlung oder Annahmen bei der Inbetriebnahme offenbart hat.

Diese Struktur erzeugt Nachweise über das Denken, nicht nur über die Aktivität. Arbeitgeber und Dozenten interessieren sich meist für Ersteres, auch wenn sie gelegentlich gezwungen sind, Letzteres zu überprüfen.

Browserbasierte Kollaboration verbessert die Zugänglichkeit und Review-Geschwindigkeit, eliminiert aber nicht die schwierigen Teile der Automatisierungstechnik. Sie ändert nur, wo die Reibung liegt.

Die Hauptgrenzen sind eindeutig:

• Eine Trainingsumgebung ist keine Anlage. Physische Instrumentierungsfehler, Verdrahtungsfehler, Netzwerktopologieprobleme, Erdungsprobleme und mechanischer Verschleiß gehören weiterhin zum Feld.
• Die Treue des digitalen Zwillings ist begrenzt. Ein Modell kann wichtige Verhaltensweisen darstellen, ohne jede Nuance der Anlage zu reproduzieren.
• Geteilte Simulation ist kein Controller-Deployment. Die Validierung in OLLA Lab unterstützt Proben und Reviews; sie ersetzt keine herstellerspezifische Implementierung, FAT, SAT oder MOC-Prozesse.
• KI-Anleitung erfordert Aufsicht. Generierte Vorschläge können den Fortschritt beschleunigen, benötigen aber dennoch technisches Urteilsvermögen und Verifizierung.
• Latenz und Synchronisationsqualität hängen von Architektur und Verbindungsbedingungen ab. Cloud-Systeme sind keine Magie; sie sind oft nur besser für geteilten Status konstruiert als klassische Desktop-Tools.

Eine ernsthafte Plattform sollte ihre Grenzen zugeben. Die Glaubwürdigkeit steigt meist, wenn das Produkt aufhört, eine Religion sein zu wollen.

OLLA Lab ist das richtige Werkzeug, wenn das Ziel geteiltes Lernen, Review, simulationsbasierte Fehlersuche oder die Validierung digitaler Zwillinge in einer browserzugänglichen Umgebung ist. Es eignet sich besonders gut für Situationen, in denen mehrere Benutzer dieselbe Logik und dasselbe Verhalten inspizieren müssen, ohne proprietäre lokale Dateien auszutauschen.

Dazu gehören:

• Dozenten-geführte SPS-Labore,
• Fernmentoring für Junior-Steuerungsingenieure,
• teambasierte Fehlersuchübungen,
• szenariobasierte Inbetriebnahmeproben,
• kollaborative Überprüfung von Sequenzierung, Verriegelungen, Alarmen, analogem Verhalten und PID-Konzepten.

Es sollte enger positioniert werden als „vollständige industrielle Bereitstellungsplattform“, da die Produktdokumentation eine Trainings- und Validierungsumgebung mit Simulation, geführten Workflows, KI-Unterstützung und kollaborativen Review-Funktionen unterstützt. Das ist bereits wertvoll. Die Behauptung aufzublähen, würde sie nur schwächen.

- 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