Integration von SPS-Logik und browserbasierten HMIs in einem einzigen Workflow

Einheitliche SPS- und HMI-Workflows reduzieren eine der ältesten Reibungsquellen bei der Inbetriebnahme: die manuelle Tag-Synchronisation zwischen Steuerungslogik und Visualisierung. In einer browserbasierten Umgebung können Variablen, der Zustand simulierter Anlagen und Schnittstellenelemente ein gemeinsames Live-Zustandsmodell nutzen. Dies ermöglicht es Ingenieuren, Bindungen, Alarme und Bedienerfeedback zu validieren, ohne separate Export-/Import-Schritte für Datenbanken durchführen zu müssen.

Ein browserbasiertes HMI ist nicht einfach nur ein HMI, das zufällig in Chrome geöffnet wird. Der entscheidende Unterschied ist architektonischer Natur: Die Visualisierungsschicht, der Variablenzustand und der Test-Workflow sind so weit vereinheitlicht, dass Ingenieure das Verhalten verifizieren können, ohne Tags zwischen getrennten Tools hin- und herschieben zu müssen.

Ampergon Vallis Metrik: Während einer kürzlich durchgeführten internen Evaluierung von simulierten Inbetriebnahmesitzungen in OLLA Lab lösten Anwender, die mit dem einheitlichen Logik- und Schnittstellen-Workflow arbeiteten, Aufgaben zur Behebung von Tag-Fehlanpassungen 42 % schneller als Anwender, die einem getrennten Export/Import-Workflow folgten. Methodik: n=24 Lernende; Aufgabe definiert als Diagnose und Korrektur fehlerhafter Bindungen zwischen Steuerung und Schnittstelle in voreingestellten Simulationsübungen; Vergleichsbasis war ein gestufter, klassischer Tag-Sync-Workflow in zwei Schritten; Beobachtungszeitraum: Januar–März 2026. Dies stützt eine begrenzte Aussage über die Effizienz von Trainingsaufgaben innerhalb von OLLA Lab. Es beweist nicht gleichwertige Gewinne auf jeder Anlagenplattform oder bei jedem Live-Inbetriebnahmeprojekt.

In diesem Artikel wird Systemintegration operativ als die verifizierte Bindung einer diskreten oder analogen SPS-Variablen an ein grafisches Schnittstellenelement definiert, sodass eine Änderung des Logikzustands korrekt und beobachtbar auf der Visualisierungsschicht reflektiert wird. Das klingt weniger glamourös als die Konferenzversion des Begriffs, ist aber wesentlich nützlicher.

Klassische SPS- und HMI-Workflows sind getrennt, da sie historisch als separate Produktkategorien entstanden sind – oft von unterschiedlichen Anbietern, Teams oder Software-Linien. Das Ergebnis ist bekannt: eine Umgebung für die Steuerungslogik, eine andere für die Grafik und eine manuelle Brücke dazwischen.

Der traditionelle Workflow sieht meist so aus:

• Erstellen von Tags oder Adressen in der SPS-Entwicklungsumgebung
• Export einer Tag-Datenbank, oft als CSV oder herstellerspezifische Metadaten
• Import dieser Datenbank in das HMI-Paket
• Binden von Grafiken, Schaltflächen, Indikatoren, Alarmen und Trends an importierte Variablen
• Feststellung während des Tests, dass einige Namen, Gültigkeitsbereiche oder Datentypen den Transfer nicht intakt überstanden haben

Das Fehlermuster ist banal, aber teuer. Eine Schaltfläche, die an `Pump_1_Start` gebunden ist, bewirkt nichts, weil der SPS-Tag eigentlich `Pump1_Start` heißt. Ein Alarmobjekt verweist auf einen veralteten Alias. Ein REAL-Wert wird wie ein Integer behandelt. Nichts davon ist intellektuell schwierig. Es ist lediglich die Art von administrativem Aufwand, der Inbetriebnahmestunden verschlingt, während er als Engineering getarnt wird.

Das tiefere Problem ist nicht nur die Unannehmlichkeit. Getrennte Workflows fragmentieren die Sichtbarkeit von Ursache und Wirkung. Wenn Logik, Tags und Schnittstellenbindungen in verschiedenen Tools leben, verbringen Ingenieure mehr Zeit damit zu beweisen, dass der Software-Stack mit sich selbst übereinstimmt, und weniger Zeit damit, das Prozessverhalten zu validieren.

Der wesentliche technische Vorteil eines browserbasierten HMIs besteht darin, dass es die Schnittstellenschicht von einem schwerfälligen, gerätespezifischen Client-Stack entkoppelt. In modernen Automatisierungsarchitekturen ist das wichtig, da Visualisierungen zunehmend portabel, zentral verwaltet und geräteübergreifend einfacher zu validieren sein müssen.

Dieser Wandel ist in der gesamten Industriesoftware sichtbar. HTML5-basierte und webnative HMI/SCADA-Plattformen haben an Bedeutung gewonnen, da sie Thin-Client-Bereitstellung, responsives Rendering und zentrales Anwendungsmanagement unterstützen, anstatt eine Installation Arbeitsplatz für Arbeitsplatz zu erfordern. Es geht nicht um Trends, sondern um Wartungsaufwand, Flexibilität beim Zugriff und architektonische Sauberkeit.

Wichtige Vorteile webnativer HMIs

- Zero-Install-Zugriff: Die Schnittstelle läuft in einem Browser, ohne dass jeder Lernende oder Prüfer eine lokale Runtime installieren muss. - Responsives Skalieren: Eine webbasierte Schnittstelle kann sich sauberer an Desktop-, Tablet- und Mobilformate anpassen als viele klassische Clients mit festem Layout. - Zentralisierte Zustandsdarstellung: Variablen und Schnittstellenelemente können gegen einen gemeinsamen Anwendungszustand verwaltet werden, anstatt sie über getrennte Dateien zu duplizieren. - Schnellere Iteration: Ingenieure können Logik ändern, Variablen inspizieren und das Schnittstellenverhalten in einer Sitzung testen, ohne wiederholte Bereitstellungsschritte. - Bessere Portabilität des Trainings: Der Browserzugriff senkt die Hürden für instruktorengeführte Labore, Fernprüfungen und szenariobasierte Übungen.

Ein browserbasiertes HMI ist nicht in jedem industriellen Kontext automatisch besser. Der Live-Anlageneinsatz hängt weiterhin von der Sicherheitsarchitektur, Protokollunterstützung, Determinisierungsanforderungen, Netzwerktopologie und betrieblicher Governance ab. Die Bequemlichkeit eines Thin-Clients hebt die technische Realität nicht auf. Sie beseitigt lediglich unnötige Belastungen.

In diesem Kontext bedeutet Systemintegration, den Nachweis zu erbringen, dass Steuerungslogik, Variablen und die für den Bediener sichtbare Visualisierung unter normalen und abnormalen Bedingungen als ein kohärentes System agieren. Es ist kein Synonym für „wir haben etwas Software verbunden“.

Eine nützliche operative Definition besteht aus drei Teilen:

- Bindung: Ein diskretes Bit, ein Analogwert, ein Timer-Zustand, ein Zähler oder eine Regelkreisvariable ist korrekt mit einem Schnittstellenelement verknüpft. - Beobachtung: Der Ingenieur kann die Zustandsänderung auf der Visualisierungsschicht sehen, wenn sich die Logik ändert. - Verifizierung: Die Reaktion wird unter erwarteten Betriebs-, Fehler- und Wiederherstellungsbedingungen getestet.

Diese Definition ist wichtig, weil sie einen häufigen Fehler verhindert: die Verwechslung von Bildschirmdesign mit Integrationskompetenz. Ein poliertes Abbild mit schlechter Tag-Disziplin bleibt ein Inbetriebnahmeproblem. Farbe ist kein Beweis.

OLLA Lab vereinheitlicht Kontaktplan-Logik und Schnittstellenverhalten, indem der Kontaktplan-Editor, das Variablen-Panel, der Simulationszustand, PID-Tools und die 3D-Szenarioansicht in einer einzigen browserbasierten Umgebung zusammengeführt werden. Praktisch bedeutet dies, dass der Lernende keine Tag-Datenbank aus einer Anwendung exportieren und in eine andere importieren muss, bevor er testet, ob das System korrekt reagiert.

Hier wird OLLA Lab operativ nützlich.

Der Kontaktplan-Editor ermöglicht es Anwendern, Programme mit Kontakten, Spulen, Timern, Zählern, Komparatoren, mathematischen Funktionen, Logikoperationen und PID-Anweisungen zu erstellen. Das Variablen-Panel zeigt Live-Tag-Zustände, E/A, Analogwerte, PID-relevante Variablen und Szenariosteuerungen an. Der Simulationsmodus erlaubt es Anwendern, Logik auszuführen, zu stoppen, Eingänge zu schalten und Ausgänge zu beobachten, ohne physische Hardware. Die 3D- und WebXR-fähigen Simulationen bieten eine visuelle Anlagenebene, die denselben Steuerungszustand widerspiegelt.

Der wichtige Anspruch ist nicht, dass OLLA Lab ein Ersatz für HMI-Suiten in Anlagen ist. So ist es nicht positioniert. Der Anspruch ist enger und stärker: Es bietet eine einheitliche Validierungsumgebung, in der Lernende die Bindung zwischen Logikzustand und Schnittstellenzustand ohne die übliche Reibung an Softwaregrenzen üben können.

### Beispiel: Timer-Zustand und Schnittstellensichtbarkeit

Betrachten Sie eine einfache `TON`-Anweisung, die verwendet wird, um den Pumpenstart zu verzögern, nachdem eine Freigabe erteilt wurde.

In einem getrennten Workflow muss der Ingenieur möglicherweise:

• die Timer-Logik in der SPS-IDE erstellen,
• den akkumulierten Wert des Timers definieren oder freigeben,
• den Tag-Satz exportieren,
• ihn in das HMI-Paket importieren,
• einen Fortschrittsbalken oder eine numerische Anzeige binden,
• und dann testen, ob das HMI-Objekt tatsächlich `.ACC` widerspiegelt.

In OLLA Lab kann dieselbe Übung in einer einzigen Sitzung beobachtet werden:

• Erstellen der `TON`-Sprosse im Kontaktplan-Editor,
• Ausführen der Simulation,
• Beobachten des Timer-Zustands und der zugehörigen Variablen im Variablen-Panel,
• Reflektieren des Verhaltens durch das Dashboard oder die Szenariovisualisierung,
• Bestätigen, ob die verzögerte Aktion der beabsichtigten Sequenz entspricht.

Das ist keine Magie. Es sind einfach weniger Gelegenheiten, eigene Fehler zu erzeugen.

Das einheitliche Tag-Verzeichnis

| Workflow-Schritt | Klassische getrennte Methode | OLLA Lab einheitliche Methode | | :--- | :--- | :--- | | Tag-Erstellung | Definition in SPS-IDE, Zuweisung Speicheradresse. | Definition im Kontaktplan-Editor und Freigabe in der Live-Simulationsumgebung. | | Datenbank-Sync | Export aus SPS-Tool und Import in HMI-Software. | Kein separater Export/Import-Schritt innerhalb des Trainings-Workflows. | | Visuelle Bindung | Mapping von Grafiken auf importierte Tag-Namen oder Aliase. | Beobachtung und Arbeit mit Live-Variablen über den geteilten Simulationszustand und Schnittstellen-Tools. | | Testen | Download, Start der Runtime und Fehlersuche bei defekten Bindungen über Tools hinweg. | Ausführen der Simulation im Browser und gemeinsame Inspektion von Logik, Variablen und Anlagenreaktion. |

Die genaue interne Implementierung sollte sorgfältig beschrieben werden. Basierend auf der Produktdokumentation präsentiert OLLA Lab eine geteilte browserbasierte Umgebung, in der Variablen, Simulationssteuerungen und visuelle Tools zusammen verfügbar sind. Der praktische Effekt ist ein einheitlicher Workflow; der Artikel sollte keine undokumentierten Interna über diese belegte Tatsache hinaus überbewerten.

Innerhalb von OLLA Lab ist die browserbasierte Schnittstellenfunktion über das Variablen-Panel, PID-Dashboards und 3D-Simulationsansichten verteilt, anstatt als separates, traditionelles HMI-Paket präsentiert zu werden. Diese Unterscheidung ist wichtig, da das Trainingsziel nicht allein Grafikdesign ist; es geht um die Sichtbarkeit und Validierung des Steuerungszustands.

Das Variablen-Panel fungiert als Live-Diagnoseschnittstelle

Das Variablen-Panel bietet Sichtbarkeit für:

• Eingangs- und Ausgangszustände,
• Tag-Werte,
• Analog-Tools und Voreinstellungen,
• PID-relevante Variablen,
• Szenarioauswahl und Zustandsänderungen.

Für das Training verhält sich dies wie ein kompaktes Diagnose-HMI. Lernende können prüfen, ob eine Freigabe wahr ist, ob eine Verriegelung einen Startbefehl blockiert, ob ein Analogwert eine Alarmschwelle überschritten hat und ob ein Ausgang als Reaktion darauf geschaltet hat.

PID-Dashboards bieten prozessnahe Sichtbarkeit

PID-relevante Anzeigen sind wichtig, da Prozessautomatisierung nicht auf diskrete Start/Stopp-Logik beschränkt ist. Die PID-Tools und Dashboards von OLLA Lab ermöglichen es Lernenden, das Regelkreisverhalten, Sollwertbeziehungen und analoge Reaktionen auf eine Weise zu beobachten, die der prozessnahen Arbeit näherkommt.

Das ist eine nützliche Korrektur für das Anfängertraining. Viele SPS-Übungen enden bei Motorstartern und erreichen nie den Teil, in dem eine falsche analoge Annahme den Tag ruiniert.

3D-Simulationen bieten Bestätigung des Anlagenzustands

Die 3D- und WebXR-fähigen Simulationen bieten eine visuelle Maschinen- oder Prozessebene, die das Steuerungsverhalten widerspiegelt. In Trainingsbegriffen ist dies eine browserbasierte Schnittstelle zum Anlagenzustand. Ein Lernender kann Kontaktplan-Zustand, Variablen-Zustand und simulierte Anlagenreaktion vergleichen, anstatt das Programm als einen Stapel isolierter Sprossen zu behandeln.

Dieser Vergleich ist der Beginn von Urteilsvermögen bei der Inbetriebnahme.

Ein illustratives Bindungsbeispiel könnte so aussehen:

- HMI-Element: `Tank_Level_Bar` - Gebundener Tag: `Tank_1_Level_PV` - Datentyp: `REAL` - Aktualisierungsrate: `50 ms`

Dieser technische Punkt ist die Beziehung: Ein Schnittstellenelement muss mit einer definierten Variablen, dem korrekten Datentyp und dem richtigen Aktualisierungsverhalten verknüpft sein, sonst ist die Visualisierung eher dekorativ als diagnostisch.

Einheitliche Workflows verbessern die virtuelle Inbetriebnahme, weil sie die Schleife zwischen Hypothese, Test, Beobachtung und Revision verkürzen. Das ist der eigentliche Gewinn. Nicht Bequemlichkeit um ihrer selbst willen, sondern schnellere Beweisführung.

In einer Übung zur virtuellen Inbetriebnahme sollte der Ingenieur in der Lage sein, Folgendes zu tun, ohne die Umgebung zu verlassen:

• einen Eingangs- oder Prozesszustand ändern,
• die Reaktion im Kontaktplan beobachten,
• Ausgangs- und Alarmverhalten bestätigen,
• die Reaktion des Anlagenzustands vergleichen,
• den Fehlerpfad identifizieren,
• die Logik überarbeiten,
• das Szenario erneut testen.

OLLA Lab unterstützt dieses Muster durch den Simulationsmodus, die Sichtbarkeit von Variablen, szenariobasierte Voreinstellungen, Analog-Tools, PID-Funktionen und 3D-Anlagensimulationen. Die Produktdokumentation listet mehr als 50 Szenario-Voreinstellungen in den Bereichen Fertigung, Wasser- und Abwasserwirtschaft, HLK, Chemie, Pharma, Lagerhaltung, Lebensmittel und Getränke sowie Versorgungsunternehmen auf. Diese Breite ist wichtig, da Steuerungsphilosophie kontextabhängig ist. Ein Pumpwerk, ein Lüftungsgerät, eine Verpackungslinie und eine Membrananlage fallen nicht auf die gleiche Weise aus, und das Training sollte aufhören, das Gegenteil vorzutäuschen.

### Beispiel: Fehlerinjektion in einem Prozessszenario

Angenommen, ein Lernender arbeitet an einem Szenario mit Tank, Pumpe oder Prozessanlage.

Er kann:

• einen abnormalen Analogwert oder einen simulierten Sensorfehler injizieren,
• beobachten, ob die Kontaktplan-Logik auslöst, alarmiert oder in ein Fallback-Verhalten geht,
• verifizieren, ob der visuelle Prozesszustand den abnormalen Zustand widerspiegelt,
• die Verriegelung, den Komparator oder die Alarmlogik überarbeiten,
• das Szenario erneut ausführen, um das Wiederherstellungsverhalten zu bestätigen.

Das ist es, was Simulation-Ready operativ bedeuten sollte: Der Ingenieur kann Steuerungslogik beweisen, beobachten, diagnostizieren und gegen realistisches Prozessverhalten härten, bevor sie einen Live-Prozess erreicht.

Ein einheitlicher Workflow hilft Junior-Ingenieuren, schneller zu lernen, weil er administrativen Aufwand beseitigt, während technische Konsequenzen erhalten bleiben. Der Lernende muss weiterhin über Freigaben, Sequenzierung, analoge Schwellenwerte, Fehlerbehandlung und Bedienerfeedback nachdenken. Sie verbringen lediglich weniger Zeit damit, sich mit getrennter Software-Installation herumzuschlagen.

Dies ist wichtig, da Automatisierungstraining zu Beginn der Karriere oft Syntax überbelohnt und Validierung untertrainiert. Ein Lernender weiß vielleicht, wie man Kontakte, Spulen, Timer und Zähler platziert, kämpft aber dennoch damit, wichtigere Fragen zu beantworten:

• Was sollte der Bediener sehen, wenn eine Freigabe fehlschlägt?
• Welcher Alarm sollte gespeichert werden und wann sollte er gelöscht werden?
• Entspricht der simulierte Anlagenzustand dem Kontaktplan-Zustand?
• Welche Beweise belegen, dass die Sequenz korrekt ist?
• Wie verhält sich die Logik, wenn ein Analogwert driftet, einfriert oder ausschlägt?

Einheitliche Umgebungen sind nützlich, wenn sie diese Fragen in denselben Workflow zwingen. Der Standard sollte hoch bleiben. Der Weg, ihn zu testen, sollte weniger absurd sein.

Lernende sollten einen kompakten Korpus an technischen Nachweisen erbringen, keine Galerie polierter Schnittstellenbilder. Screenshots beweisen, dass ein Bildschirm existierte. Sie beweisen nicht, dass sich das Steuerungssystem korrekt verhalten hat.

Verwenden Sie diese Struktur:

Dokumentieren Sie den eingeführten abnormalen Zustand: fehlgeschlagene Rückmeldung, hängender Eingang, Analogwert hoch-hoch, Surrogat für Kommunikationsverlust oder Sequenz-Timeout.

1. Systembeschreibung Definieren Sie den Prozess oder die Maschine, das Hauptsteuerungsziel und die relevanten E/A.
2. Operative Definition von „korrekt“ Geben Sie die erwartete Sequenz, Freigaben, Auslösungen, Alarme, Zeitverhalten und Wiederherstellungsbedingungen an.
3. Kontaktplan-Logik und simulierter Anlagenzustand Zeigen Sie die implementierte Logik und das entsprechende simulierte Maschinen- oder Prozessverhalten.
4. Der injizierte Fehlerfall
5. Die vorgenommene Revision Erklären Sie die Logikänderung, Schwellenwertanpassung, Hinzufügung von Verriegelungen, Alarmmodifikation oder Sequenzkorrektur.
6. Gelernte Lektionen Geben Sie an, was der Fehler aufgedeckt hat und welches Designprinzip sich infolgedessen geändert hat.

Diese Struktur ist stärker als ein aus Screenshots zusammengestelltes Portfolio, da sie logisches Denken, Verifizierung und Revision demonstriert.

Simulationsbasierte Validierung ist als Ingenieurspraxis gut unterstützt. Standards und Literatur besagen nicht, dass ein digitaler Zwilling oder ein virtuelles Labor jemanden von sich aus vor Ort kompetent macht. Sie unterstützen jedoch den Einsatz von Simulation, modellbasiertem Testen und Validierung vor der Bereitstellung, um Risiken zu reduzieren, das Verständnis zu verbessern und Fehler früher im Lebenszyklus aufzudecken.

Relevante Grundlagen

• IEC 61508 betont Lebenszyklusdisziplin, Verifizierung, Validierung und die systematische Reduzierung des Risikos gefährlicher Ausfälle in sicherheitsbezogenen Systemen.
• Literatur zu digitalen Zwillingen und virtueller Inbetriebnahme in Fachzeitschriften wie IFAC-PapersOnLine, Sensors und Fertigungstechnik-Publikationen unterstützt den Einsatz virtueller Modelle für eine frühere Validierung von Steuerungsverhalten und Inbetriebnahmelogik.
• Industrielle Trainingsliteratur unterstützt im Allgemeinen interaktives und simulationsbasiertes Lernen zur Verbesserung des prozeduralen Verständnisses und der Fehlererkennung.

OLLA Lab passt als webbasierte Trainings- und Übungsumgebung für risikoreiche Inbetriebnahmeaufgaben, die teuer, unpraktisch oder unsicher sind, um sie Anfängern an Live-Geräten zu überlassen. Das ist die glaubwürdige Position.

Es hilft Lernenden und Teams dabei:

• Kontaktplan-Logik zu validieren,
• E/A- und Tag-Verhalten zu überwachen,
• Ursache und Wirkung nachzuvollziehen,
• mit abnormalen Bedingungen umzugehen,
• Logik nach einem Fehler zu überarbeiten,
• simulierten Anlagenzustand mit Kontaktplan-Zustand zu vergleichen,
• realistische industrielle Szenarien mit Analog- und PID-Verhalten durchzuarbeiten.

Der Wert eines browserbasierten HMI-Workflows liegt nicht darin, dass er sich modern anfühlt. Der Wert liegt darin, dass er unnötige Softwaregrenzen zwischen Steuerungslogik, Variablensichtbarkeit und Schnittstellenvalidierung einreißt.

Wenn SPS-Logik und der für den Bediener sichtbare Zustand in einer Umgebung getestet werden, können Ingenieure mehr Zeit mit dem Beweis des Verhaltens verbringen und weniger Zeit mit der Reparatur defekter Tag-Übergaben. Für das Training macht das den Workflow realistischer. Für die Praxis der virtuellen Inbetriebnahme macht es die Beweisführung präziser. Und für Junior-Ingenieure verschiebt es den Schwerpunkt vom Zeichnen von Sprossen hin zur Validierung von Systemen.

Das Team von Ampergon Vallis Lab entwickelt Werkzeuge für die industrielle Ausbildung und virtuelle Inbetriebnahme.

Dieser Artikel wurde auf technische Konsistenz mit den OLLA Lab-Spezifikationen und gängigen Industriestandards für die SPS-Programmierung und virtuelle Inbetriebnahme geprüft.

- IEC 61131-3: Programmierbare Steuerungen — Teil 3 - Übersicht zum Standard für funktionale Sicherheit IEC 61508 - NIST Smart Manufacturing Profile - IEEE Access: Digital twin enabling technologies (DOI)