JSON-Serialisierung für SPS in OLLA Lab

OLLA Lab serialisiert Kontaktplan-Logik (Ladder Logic) in strukturiertes JSON anstatt in undurchsichtige Binärdateien. Diese textbasierte Darstellung ermöglicht Cloud-Synchronisierung, versionsbewusste Änderungsverfolgung und maschinelles Parsing für Validierungs-Workflows, während die SPS-Praxis innerhalb einer begrenzten Simulationsumgebung und nicht in einem aktiven Steuerungssystem bleibt.

Proprietäre SPS-Projektdateien sind nicht allein deshalb „sicher“, weil sie schwer zu lesen sind. In der Praxis schwächt Intransparenz häufig die Zusammenarbeit, die Revisionsfähigkeit und die Wiederherstellung, da die Logik in herstellerspezifischen Binärformaten gefangen ist.

In OLLA Lab werden Kontaktpläne als strukturierte JSON-Schemata gespeichert, die in einer browserbasierten Umgebung übertragen, geparst und rekonstruiert werden können. Während des internen Cloud-Benchmarkings von Ampergon Vallis im 3. Quartal 2025 führte die Serialisierung von 25 OLLA Lab-Projekten mit einem Umfang von 20 bis 100 Sprossen zu einer mittleren Nutzlastreduzierung von 82 % gegenüber der binären internen Referenzbasis der Plattform. Gleichzeitig wurde das vollständige Schema-Parsing durch den Yaga-Assistenten für den Testfall mit 100 Sprossen in unter 400 ms abgeschlossen [Methodik: n=25 Projektexporte; Aufgabenstellung = Serialisierung und Übertragung des vollständigen Kontaktplan-Projektzustands; Basis-Vergleichswert = internes, binär-äquivalentes Speicherobjekt von Ampergon Vallis für Architekturtests; Zeitfenster = Q3 2025]. Dies stützt eine Aussage über Transporteffizienz und Parsing-Geschwindigkeit innerhalb der eigenen Architektur von OLLA Lab. Es stützt keine allgemeingültige Aussage über sämtliche SPS-Software.

Der wichtigere Punkt ist einfach: Textbasierte Logik ist leichter zu versionieren, zu inspizieren, wiederherzustellen und zu validieren. Binär-Blobs sind hervorragend darin, Blobs zu sein. Das ist nicht dasselbe.

Proprietäre Binärdateien begrenzen die Versionskontrolle, da sie Steuerungslogik als undurchsichtige, maschinenorientierte Daten und nicht als zeilenadressierbaren Text speichern. Standard-Versionsverwaltungssysteme wie Git funktionieren am besten, wenn sie diskrete textuelle Änderungen vergleichen können, und nicht, wenn eine gesamte Datei auf einmal als geändert erscheint.

In vielen SPS-Legacy-Umgebungen ist eine Projektdatei effektiv ein kompilierter Container. Wenn ein Ingenieur einen Zeitgeber-Sollwert ändert und ein anderer einen Freigabekontakt, kann Git diese Bearbeitungen oft nicht als separate logische Deltas identifizieren. Es sieht ein einziges geändertes Binär-Artefakt. Die Qualität der Zusammenführung (Merge) sinkt sofort.

Dies führt zu mehreren praktischen Einschränkungen:

- Schlechte Diff-Sichtbarkeit: Standard-Text-Diff-Tools können nicht anzeigen, was sich auf Sprossen- oder Befehlsebene geändert hat. - Schwaches Merge-Verhalten: Gleichzeitige Bearbeitungen sind ohne herstellerspezifische Werkzeuge schwerer abzugleichen. - Eingeschränkte Revisionsfähigkeit: Prüfer wissen möglicherweise, dass sich eine Datei geändert hat, aber nicht genau wie. - Reduzierte Portabilität: Das Projekt wird von einer spezifischen IDE und einem Dateiparser abhängig. - Fragile KI-Nutzbarkeit: Große Sprachmodelle und regelbasierte Validatoren können proprietäre Binärstrukturen nicht nativ untersuchen.

Eine nützliche Unterscheidung ist Dateiintegrität versus technische Verständlichkeit. Eine Binärdatei lässt sich möglicherweise korrekt öffnen und ist dennoch für die Überprüfung operativ wenig hilfreich.

Binär-Blobs vs. JSON-Serialisierung in der Automatisierung

| Eigenschaft | Proprietäre Binärdatei | JSON-serialisierte Logik | |---|---|---| | Menschliche Lesbarkeit | Minimal bis nicht vorhanden | Lesbar mit Strukturverständnis | | Standard-Git-Diffing | Schlecht | Stark | | Branch/Merge-Unterstützung | Begrenzt | Stärker, abhängig von Schema-Disziplin | | KI-Parsing | Typischerweise indirekt oder nicht verfügbar | Direkt parstbar | | Herstellerunabhängigkeit | Niedrig | Höher auf Datenstrukturebene | | Fehlerdiagnose | Schwerer zu isolieren | Einfacher selektiv zu prüfen und wiederherzustellen | | Cloud-Transport | Oft schwerer und toolabhängig | Zustandsfrei und Web-freundlich |

Dies bedeutet nicht, dass binäre Speicherung illegitim ist. Es bedeutet, dass binäre Speicherung schlecht auf moderne Software-Review-Workflows abgestimmt ist. Die OT hat jahrelang mit diesem Missverhältnis gelebt, weil sie musste.

OLLA Lab übersetzt Kontaktplan-Logik, indem das Diagramm als strukturierte Datenobjekte gespeichert wird und nicht als flaches Bild oder undurchsichtiger Projekt-Blob. Eine Sprosse wird durch verschachtelte Entitäten wie Befehle, Tag-Bindungen, Zustände, Parameter und Layout-Metadaten dargestellt.

Wenn ein Benutzer einen Befehl im Browser-Editor platziert, zeichnet die Plattform beobachtbare Eigenschaften auf, darunter:

• Befehlstyp,
• Tag-Referenz,
• Adresse oder Kennung,
• Parameterwerte,
• Sprossenposition,
• ausführungsrelevanter Zustand,
• und zugehöriger Szenariokontext, falls zutreffend.

Das ist wichtig, weil das gespeicherte Objekt nicht nur eine Zeichnung ist. Es ist eine maschinenlesbare Darstellung der Steuerungsabsicht.

### Beispiel: JSON-Darstellung auf Befehlsebene

instruction: { "type": "XIC", "tag": "Pump_Start_PB", "address": "I:0/1", "state": false }

Ein vollständigeres Projektschema würde typischerweise zusätzliche Objekte enthalten für:

• Sprossenreihenfolge,
• Verzweigungsbeziehungen,
• Ausgangsbefehle,
• Zeitgeber- oder Zähler-Sollwerte,
• Analogwerte,
• PID-Parameter,
• Szenario-Bindungen,
• und Snapshots des Simulationszustands.

Was das in der Praxis bedeutet

Wenn ein Lernender eine Selbsthaltung für einen Motorstarter baut, kann OLLA Lab sowohl die Logikstruktur als auch den zugehörigen Simulationskontext speichern. Das ermöglicht es der Plattform, das Projekt im Editor zu rekonstruieren, im Simulationsmodus auszuführen und denselben Zustand für das Variablen-Panel und den KI-Assistenten bereitzustellen.

Hier wird OLLA Lab operativ nützlich. Die Plattform speichert keinen Screenshot der Logik; sie speichert ein Datenmodell, das andere Systemkomponenten abfragen können.

In diesem Artikel bedeutet Cloud-native Speicherung von Kontaktplan-Logik, dass die Logik in textbasierte Schemata serialisiert, zustandsfrei an entfernte Dienste übertragen, unabhängig von einer lokalen Engineering-Workstation gespeichert und bei Bedarf in einer Browser-zugänglichen Umgebung rekonstruiert werden kann.

Diese Definition ist enger gefasst als die Marketing-Version, die normalerweise kursiert. Wir diskutieren über Speicher- und Transportarchitektur, nicht über eine mystische Eigenschaft von Software-Tugend.

Ein Cloud-natives Speichermodell für Kontaktplan-Logik umfasst typischerweise:

- zustandsfreie Übertragung: der Projektzustand wird als Daten gesendet, nicht als Kontext des Arbeitsspeichers der Workstation; - Remote-Persistenz: Projektdateien liegen in einem verwalteten Cloud-Speicher und nicht nur auf einem lokalen Rechner; - Browser-Rekonstruktion: der Editor kann das Diagramm aus serialisierten Objekten neu aufbauen; - Dienst-Interoperabilität: KI-, Bewertungs-, Freigabe- und Simulationsdienste können dasselbe Schema nutzen; - Geräteflexibilität: Benutzer können auf dasselbe Projekt über Desktop, Tablet, Mobilgerät oder unterstützte XR-Umgebungen zugreifen.

In OLLA Lab unterstützt diese Architektur einen webbasierten Kontaktplan-Editor, Simulations-Workflows, szenariobasiertes Training und geführte Unterstützung, ohne dass der Lernende lokale Laufzeit-Stacks der Hersteller verwalten muss, nur um Logikverhalten zu üben.

Das ist ein Trainings- und Validierungsvorteil, keine Behauptung, dass Browser-Tools jede Engineering-Suite eines Herstellers ersetzen. Die Unterscheidung ist wichtig.

Textbasierte SPS-Speicherung ermöglicht Review- und Zusammenarbeitsmethoden im Software-Stil, die auf undurchsichtige Projektdateien nur schwer anwendbar sind. Die Hauptvorteile sind Diffing, Branching, Wiederherstellbarkeit und maschinell unterstützte Validierung.

1. Diffing

Ein Diff ist ein zeilenweiser Vergleich zwischen zwei Versionen einer Datei. In einem JSON-basierten Kontaktplan-Projekt kann ein Prüfer feststellen, ob die Änderung Folgendes betraf:

• einen Zeitgeber-Sollwert,
• einen Kontakttyp,
• eine Tag-Bindung,
• einen Analogschwellenwert,
• oder einen Sequenzparameter.

Das ist wesentlich besser als „die Datei hat sich geändert“. Engineering-Reviews benötigen mehr als ein Schulterzucken.

2. Branching

Branching ermöglicht es einem Benutzer oder Team, alternative Steuerungsstrategien zu testen, ohne die aktuelle Arbeitsversion zu überschreiben. Beim Training und bei Digital-Twin-Proben ist dies besonders nützlich für den Vergleich von:

• alternativer Freigabelogik,
• Fehlerbehandlungs-Revisionen,
• Einstellungen für Alarm-Totbänder,
• Optionen für die Lead/Lag-Sequenzierung,
• oder PID-Tuning-Experimenten.

3. Wiederherstellbarkeit

Textbasierte Schemata sind leichter zu inspizieren und teilweise wiederherzustellen, wenn etwas schiefgeht. Wenn ein Projektobjekt fehlerhaft ist, kann der Fehler oft auf einen bestimmten Abschnitt des Schemas isoliert werden, anstatt die gesamte Datei unlesbar zu machen.

4. Zusammenarbeit ohne starre Dateisperren

Ein strukturierter Cloud-Workflow kann die Überprüfung durch mehrere Benutzer und das Feedback von Ausbildern sauberer unterstützen als lokale Dateiübergaben. Die Freigabe- und Bewertungsfunktionen von OLLA Lab basieren auf diesem architektonischen Vorteil.

5. Bessere Validierungs-Workflows

Ein maschinenlesbares Schema kann vor der Bereitstellung oder vor der Simulationsausführung auf Konsistenz geprüft werden. Beispiele sind:

• fehlende Tag-Referenzen,
• doppelte Bindungen,
• ungültige Parameterbereiche,
• unvollständige Sprossenstrukturen,
• oder Szenario-Fehlanpassungen.

Dies ist eng mit der breiteren Idee von Infrastructure as Code verwandt: Systemkonfiguration als inspizierbare, versionierte Daten behandeln. In der OT ist das Prinzip nützlich, aber die Implementierung muss diszipliniert bleiben. Ein Anlagenstillstand, der durch elegante Git-Hygiene verursacht wurde, wäre immer noch ein Anlagenstillstand.

JSON-Serialisierung macht OLLA Lab KI-bereit, da KI-Systeme strukturierte Texteingaben benötigen, keine proprietären binären Projektcontainer. Ein Sprachmodell, eine Regel-Engine oder ein Validierungsdienst kann JSON-Schlüssel, Beziehungen und Werte direkt parsen.

Wenn ein Benutzer Yaga fragt, warum eine Pumpe nicht startet, leitet der Assistent den Steuerungszustand nicht aus Pixeln auf einem Bildschirm ab. Ihm kann die serialisierte Projektstruktur, die aktuellen Tag-Zustände und der Szenariokontext gegeben werden. Das ist der Unterschied zwischen Bildinterpretation und schema-bewusstem Schlussfolgern.

KI-bereit, operativ definiert

In diesem Kontext bedeutet KI-bereit:

• die Steuerungslogik liegt in einem strukturierten Textformat vor,
• die relevanten Tags und Befehlstypen sind explizit dargestellt,
• der aktuelle Simulationszustand kann an das Logikschema angehängt werden,
• und das resultierende Paket kann schnell genug geparst werden, um interaktives Feedback zu unterstützen.

Dies unterstützt mehrere begrenzte Anwendungsfälle:

• Identifizierung eines blockierenden `XIO` oder einer falschen Freigabe,
• Erkennung eines nicht verriegelten Selbsthaltepfads,
• Markierung inkonsistenter Tag-Verwendung,
• Erläuterung des Zeitgeberverhaltens,
• Überprüfung der Logik für analoge Schwellenwerte,
• oder Anleitung eines Lernenden durch wahrscheinliche Fehlerursachen.

Es bedeutet nicht, dass die KI eine Zertifizierungsstelle, ein Sicherheitsvalidator oder ein Ersatz für Design-Reviews ist. KI kann die Inspektion beschleunigen. Sie erbt keine Verantwortung.

Warum das für das Lernen wichtig ist

Ein Lernender, der nur Kontaktplan-Syntax schreibt, ist noch nicht Simulationsbereit. Bei Ampergon Vallis bedeutet Simulationsbereit, in der Lage zu sein, Steuerungslogik gegen realistisches Prozessverhalten zu beweisen, zu beobachten, zu diagnostizieren und zu härten, bevor sie einen aktiven Prozess erreicht.

Dazu gehört die Fähigkeit:

• E/A-Zustände zu überwachen,
• Kontaktplan-Zustände mit dem Verhalten simulierter Geräte zu vergleichen,
• Fehler einzuspeisen,
• Logik nach anormalen Bedingungen zu überarbeiten,
• und zu erklären, warum die überarbeitete Logik korrekter ist.

Syntax ist notwendig. Die Einsatzfähigkeit ist der härtere Test.

JSON-Serialisierung unterstützt die Digital-Twin-Validierung, indem sie dem Simulator und der Logik-Engine eine gemeinsame, maschinenlesbare Beschreibung des Zustands des Steuerungssystems gibt. Das Kontaktplan-Programm, Tag-Werte, analoge Bindungen und Szenarioparameter können alle als strukturierte Daten ausgetauscht werden.

Ein Digital-Twin-Validierungs-Workflow, der sorgfältig eingesetzt wird, ist nicht nur „den Code in einer schönen 3D-Szene ausführen“. Operativ bedeutet es zu prüfen, ob die Steuerungslogik unter definierten normalen und anormalen Bedingungen das erwartete Geräteverhalten erzeugt.

In OLLA Lab kann das beinhalten:

• Umschalten diskreter Eingänge und Beobachten der Ausgangsreaktion,
• Überwachung von Analogwerten und Komparatorverhalten,
• Testen von Zeitgebern und Zählern gegen Sequenzerwartungen,
• Validierung von Verriegelungen und Freigaben,
• und Vergleich von Maschinen-Zustandsübergängen mit der beabsichtigten Steuerungsphilosophie.

Das ist wichtig, weil viele Kontaktplan-Übungen bei der Sprossen-Korrektheit aufhören. Die echte Inbetriebnahme tut das nicht. Die Logik muss den Kontakt mit dem Prozessverhalten überleben, und Prozessverhalten ist normalerweise weniger höflich als die Whiteboard-Version.

Normativer Kontext

Der Wert von Simulation und modellbasierter Validierung in der industriellen Steuerungstechnik steht im Einklang mit der breiteren Engineering-Literatur zu digitalen Zwillingen, virtueller Inbetriebnahme und Tests vor der Bereitstellung. Normen und Leitlinien in der funktionalen Sicherheit und der Lebenszykluspraxis von Steuerungssystemen, einschließlich IEC 61508, betonen systematische Validierung, Rückverfolgbarkeit und Risikoreduzierung durch disziplinierte Verifizierungsaktivitäten anstelle von informellem Vertrauen allein. Ein Simulator ist kein SIL-Zertifikat, aber er ist oft ein viel besserer Ort, um eine falsche Annahme zu entdecken, als ein aktives System.

Textbasierte Projektschemata verbessern Export und Wiederherstellung, da sie portabel, inspizierbar und einfacher in Standard-Software-Repositories zu archivieren sind. In OLLA Lab ist der praktische Wert nicht nur das Backup. Es ist die Beweissicherung.

Ein Lernender oder Ingenieur sollte Projekte so exportieren, dass sowohl die Logik als auch die Validierungsgeschichte darum herum erhalten bleibt.

Empfohlenes Engineering-Beweispaket

Wenn Sie ein Projekt erstellen möchten, um Fähigkeiten glaubwürdig zu demonstrieren, bauen Sie keine Screenshot-Galerie. Bauen Sie einen kompakten Bestand an Engineering-Beweisen auf:

Geben Sie an, was erfolgreiches Verhalten in beobachtbaren Begriffen bedeutet: Startbedingungen, Stoppbedingungen, Verriegelungen, Alarm-Schwellenwerte, Zeitfenster und Fehlerreaktion.

Dokumentieren Sie die eingeführte anormale Bedingung: fehlgeschlagener Nachweis, klemmender Eingang, niedriger Füllstand, Überlastauslösung, analoger Bereichsüberschreitungszustand oder Sequenz-Timeout.

Zeichnen Sie genau auf, welche Logik sich geändert hat und warum: Freigabe hinzugefügt, Kontaktpolarität korrigiert, Zeitgeber-Sollwert überarbeitet, Alarmbehandlung verbessert oder Neustartverhalten gehärtet.

1. Systembeschreibung Definieren Sie den Prozess oder die Maschine, die gesteuert wird, einschließlich der wichtigsten Eingänge, Ausgänge, Sequenzen und Betriebsbeschränkungen.
2. Operative Definition von „korrekt“
3. Kontaktplan-Logik und simulierter Gerätezustand Bewahren Sie die Version der Kontaktplan-Logik zusammen mit den relevanten simulierten Zuständen, Tag-Werten und Szenariobedingungen auf.
4. Der eingespeiste Fehlerfall
5. Die vorgenommene Revision
6. Gelernte Lektionen Fassen Sie zusammen, was der Fehler über das ursprüngliche Design offenbart hat und was die überarbeitete Logik jetzt korrekt handhabt.

Diese Struktur ist überzeugender als polierte Visualisierungen allein, weil sie technisches Urteilsvermögen zeigt. Jeder kann eine Datei exportieren. Weniger Leute können erklären, warum ein Fehlerfall die Steuerungsphilosophie verändert hat.

Praktische Vorteile bei der Wiederherstellung

Ein textbasierter Export unterstützt auch:

• persönliche Archivspeicherung,
• repository-basierte Versionshistorie,
• Überprüfung durch Ausbilder,
• Peer-Vergleich,
• und selektiven Re-Import in eine neue Übungssitzung.

Auch hier gilt: Dies ist ein begrenzter Vorteil innerhalb einer Trainings- und Simulationsumgebung. Es impliziert keine direkte Bereitstellungsäquivalenz zu herstellerspezifischen Laufzeitpaketen.

JSON-basierte Kontaktplan-Speicherung ist wertvoll, weil sie Kontaktplan-Logik in inspizierbare Engineering-Daten verwandelt, anstatt in ein undurchsichtiges Projekt-Artefakt. Das ermöglicht Versionskontrolle, Cloud-Workflows, KI-gestütztes Parsing und eine robustere Wiederherstellung.

Speziell für OLLA Lab ist der architektonische Punkt enger und stärker als eine breite Behauptung einer Software-Revolution. OLLA Lab gibt Ingenieuren eine webbasierte Umgebung, um zu üben, Steuerungslogik als strukturierte, testbare Daten zu behandeln, während das Verhalten in Simulationen, Digital-Twin-Szenarien und geführten Fehlerbehebungs-Workflows validiert wird.

Das ist das richtige Maß an Ambition. Es lehrt die Gewohnheiten, die moderne Automatisierungsteams zunehmend benötigen: Rückverfolgbarkeit, Überprüfbarkeit, fehlerbewusstes Testen und evidenzbasierte Revision. Kein Glamour. Nur bessere Engineering-Hygiene, die normalerweise das ist, was eine Inbetriebnahme überlebt.

- IEC 61508 Übersicht 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