JSON Serialization for PLCs in OLLA Lab

OLLA Lab serializes ladder logic into structured JSON rather than opaque binary files. This text-based representation enables cloud synchronization, version-aware change tracking, and machine parsing for validation workflows, while keeping PLC practice inside a bounded simulation environment rather than a live control system.

Proprietary PLC project files are not "secure" simply because they are hard to read. In practice, opacity often weakens collaboration, auditability, and recovery because the logic is trapped inside vendor-specific binary formats.

In OLLA Lab, ladder diagrams are stored as structured JSON schemas that can be transmitted, parsed, and reconstructed in a browser-based environment. During Ampergon Vallis's Q3 2025 internal cloud benchmarking, serializing 25 OLLA Lab projects ranging from 20 to 100 rungs produced a median payload reduction of 82% against the platform's binary-equivalent internal baseline, while full-project schema parsing by the Yaga assistant completed in under 400 ms for the 100-rung test case [Methodology: n=25 project exports; task definition = serialize and transmit complete ladder project state; baseline comparator = Ampergon Vallis internal binary-equivalent storage object used for architecture testing; time window = Q3 2025]. This supports a claim about transport efficiency and parse speed inside OLLA Lab's own architecture. It does not support a universal claim about all PLC software.

The larger point is straightforward: text-based logic is easier to version, inspect, recover, and validate. Binary blobs are excellent at being blobs. That is not the same thing.

Proprietary binary files limit version control because they store control logic as opaque machine-oriented data rather than line-addressable text. Standard source-control systems such as Git work best when they can compare discrete textual changes, not when an entire file appears to change at once.

In many legacy PLC environments, a project file is effectively a compiled container. If one engineer changes a timer preset and another changes a permissive contact, Git often cannot identify those edits as separate logical deltas. It sees one altered binary artifact. Merge quality drops immediately.

This creates several practical constraints:

- Poor diff visibility: standard text diff tools cannot show what changed at rung or instruction level. - Weak merge behavior: concurrent edits are harder to reconcile without vendor-specific tooling. - Limited auditability: reviewers may know that a file changed, but not exactly how. - Reduced portability: the project becomes dependent on a specific IDE and file parser. - Fragile AI usability: large language models and rule-based validators cannot natively inspect proprietary binary structures.

A useful distinction is file integrity versus engineering intelligibility. A binary file may open correctly and still be operationally unhelpful for review.

Binary blobs vs. JSON serialization in automation

| Property | Proprietary Binary File | JSON-Serialized Logic | |---|---|---| | Human readability | Minimal to none | Readable with structure awareness | | Standard Git diffing | Poor | Strong | | Branch/merge support | Limited | Stronger, depending on schema discipline | | AI parsing | Typically indirect or unavailable | Directly parseable | | Vendor independence | Low | Higher at data-structure level | | Corruption diagnosis | Harder to isolate | Easier to inspect and recover selectively | | Cloud transport | Often heavier and tool-dependent | Stateless and web-friendly |

This does not mean binary storage is illegitimate. It means binary storage is poorly aligned with modern software review workflows. OT has lived with that mismatch for years because it had to.

OLLA Lab translates ladder logic by storing the diagram as structured data objects rather than as a flat image or opaque project blob. A rung is represented through nested entities such as instructions, tag bindings, states, parameters, and layout metadata.

When a user places an instruction in the browser editor, the platform records observable properties, including:

• instruction type,
• tag reference,
• address or identifier,
• parameter values,
• rung position,
• execution-relevant state,
• and associated scenario context where applicable.

That matters because the saved object is not merely a drawing. It is a machine-readable representation of control intent.

### Example: instruction-level JSON representation

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

A more complete project schema would typically include additional objects for:

• rung ordering,
• branch relationships,
• output instructions,
• timer or counter presets,
• analog values,
• PID parameters,
• scenario bindings,
• and simulation state snapshots.

What this means in practice

If a learner builds a motor starter seal-in rung, OLLA Lab can store both the logic structure and the related simulation context. That allows the platform to reconstruct the project in the editor, run it in simulation mode, and expose the same state to the variables panel and AI assistant.

This is where OLLA Lab becomes operationally useful. The platform is not preserving a screenshot of logic; it is preserving a data model that other system components can interrogate.

In this article, cloud-native ladder logic storage means that the logic can be serialized into text-based schemas, transmitted statelessly to remote services, stored independently of a local engineering workstation, and reconstructed on demand in a browser-accessible environment.

That definition is narrower than the marketing version that usually wanders into the room. We are discussing storage and transport architecture, not a mystical property of software virtue.

A cloud-native storage model for ladder logic typically includes:

- stateless transmission: the project state is sent as data, not as workstation memory context; - remote persistence: project files live in managed cloud storage rather than only on a local machine; - browser reconstruction: the editor can rebuild the diagram from serialized objects; - service interoperability: AI, grading, sharing, and simulation services can consume the same schema; - device flexibility: users can access the same project across desktop, tablet, mobile, or supported XR environments.

In OLLA Lab, this architecture supports a web-based ladder editor, simulation workflows, scenario-based training, and guided assistance without requiring the learner to manage local vendor runtime stacks just to practice logic behavior.

That is a training and validation advantage, not a claim that browser tools replace every vendor engineering suite. The distinction matters.

Text-based PLC storage enables software-style review and collaboration practices that are difficult to apply to opaque project files. The main advantages are diffing, branching, recoverability, and machine-assisted validation.

1. Diffing

A diff is a line-level comparison between two versions of a file. In a JSON-backed ladder project, a reviewer can identify whether the change involved:

• a timer preset,
• a contact type,
• a tag binding,
• an analog threshold,
• or a sequence parameter.

That is materially better than "the file changed." Engineering review needs more than a shrug.

2. Branching

Branching allows a user or team to test alternate control strategies without overwriting the current working version. In training and digital-twin rehearsal, this is especially useful for comparing:

• alternate permissive logic,
• fault-handling revisions,
• alarm deadband settings,
• lead/lag sequencing options,
• or PID tuning experiments.

3. Recoverability

Text-based schemas are easier to inspect and partially recover when something goes wrong. If a project object is malformed, the failure can often be isolated to a specific section of the schema rather than rendering the entire file unreadable.

4. Collaboration without rigid file locking

A structured cloud workflow can support multi-user review and instructor feedback more cleanly than local file handoffs. OLLA Lab's sharing and grading features sit on top of this architectural benefit.

5. Better validation workflows

A machine-readable schema can be checked for consistency before deployment or before simulation execution. Examples include:

• missing tag references,
• duplicate bindings,
• invalid parameter ranges,
• incomplete rung structures,
• or scenario mismatches.

This is adjacent to the broader Infrastructure as Code idea: treat system configuration as inspectable, versioned data. In OT, the principle is useful, but the implementation must remain disciplined. A plant trip caused by elegant Git hygiene would still be a plant trip.

JSON serialization makes OLLA Lab AI-ready because AI systems require structured text inputs, not proprietary binary project containers. A language model, rules engine, or validation service can parse JSON keys, relationships, and values directly.

When a user asks Yaga why a pump is not starting, the assistant does not infer control state from pixels on a screen. It can be given the serialized project structure, current tag states, and scenario context. That is the difference between image interpretation and schema-aware reasoning.

AI-ready, defined operationally

In this context, AI-ready means:

• the control logic exists in a structured text format,
• the relevant tags and instruction types are explicitly represented,
• the current simulation state can be attached to the logic schema,
• and the resulting package can be parsed quickly enough to support interactive feedback.

That supports several bounded use cases:

• identifying a blocking `XIO` or false permissive,
• detecting an unlatched seal-in path,
• flagging inconsistent tag use,
• explaining timer behavior,
• reviewing analog threshold logic,
• or guiding a learner through likely fault causes.

It does not mean the AI is a certifying authority, a safety validator, or a substitute for design review. AI can accelerate inspection. It does not inherit accountability.

Why this matters for learning

A learner who only writes ladder syntax is not yet Simulation-Ready. In Ampergon Vallis usage, Simulation-Ready means being able to prove, observe, diagnose, and harden control logic against realistic process behavior before it reaches a live process.

That includes the ability to:

• monitor I/O state,
• compare ladder state against simulated equipment behavior,
• inject faults,
• revise logic after abnormal conditions,
• and explain why the revised logic is more correct.

Syntax is necessary. Deployability is the harder test.

JSON serialization supports digital twin validation by giving the simulator and the logic engine a shared, machine-readable description of the control system state. The ladder program, tag values, analog bindings, and scenario parameters can all be exchanged as structured data.

A digital twin validation workflow, used carefully, is not just "run the code in a nice 3D scene." Operationally, it means checking whether the control logic produces the expected equipment behavior under defined normal and abnormal conditions.

In OLLA Lab, that can include:

• toggling discrete inputs and observing output response,
• monitoring analog values and comparator behavior,
• testing timers and counters against sequence expectations,
• validating interlocks and permissives,
• and comparing machine-state transitions to the intended control philosophy.

This matters because many ladder exercises stop at rung correctness. Real commissioning does not. The logic has to survive contact with process behavior, and process behavior is usually less polite than the whiteboard version.

Standards context

The value of simulation and model-based validation in industrial control is consistent with broader engineering literature on digital twins, virtual commissioning, and pre-deployment testing. Standards and guidance in functional safety and control-system lifecycle practice, including IEC 61508, emphasize systematic validation, traceability, and risk reduction through disciplined verification activities rather than informal confidence alone. A simulator is not a SIL certificate, but it is often a much better place to discover a bad assumption than a live skid.

Text-based project schemas improve export and recovery because they are portable, inspectable, and easier to archive in standard software repositories. In OLLA Lab, the practical value is not just backup. It is evidence preservation.

A learner or engineer should export projects in a way that preserves both the logic and the validation story around it.

Recommended engineering evidence package

If you want a project to demonstrate skill credibly, do not build a screenshot gallery. Build a compact body of engineering evidence:

State what successful behavior means in observable terms: start conditions, stop conditions, interlocks, alarm thresholds, timing windows, and fault response.

Document the abnormal condition introduced: failed proof, stuck input, low level, overload trip, analog out-of-range condition, or sequence timeout.

Record exactly what logic changed and why: added permissive, corrected contact polarity, revised timer preset, improved alarm handling, or hardened restart behavior.

1. System Description Define the process or machine being controlled, including major inputs, outputs, sequences, and operating constraints.
2. Operational definition of "correct"
3. Ladder logic and simulated equipment state Preserve the ladder logic version together with the relevant simulated states, tag values, and scenario conditions.
4. The injected fault case
5. The revision made
6. Lessons learned Summarize what the fault revealed about the original design and what the revised logic now handles correctly.

That structure is more persuasive than polished visuals alone because it shows engineering judgment. Anyone can export a file. Fewer people can explain why a fault case changed the control philosophy.

Practical recovery benefits

A text-based export also supports:

• personal archive storage,
• repository-based version history,
• instructor review,
• peer comparison,
• and selective re-import into a new practice session.

Again, this is a bounded advantage inside a training and simulation environment. It does not imply direct deployment equivalence to vendor-specific runtime packages.

JSON-based ladder storage is valuable because it turns ladder logic into inspectable engineering data rather than an opaque project artifact. That enables version control, cloud workflows, AI-assisted parsing, and more resilient recovery.

For OLLA Lab specifically, the architectural point is narrower and stronger than a broad software-revolution claim. OLLA Lab gives engineers a web-based environment to practice treating control logic as structured, testable data while validating behavior in simulation, digital twin scenarios, and guided troubleshooting workflows.

That is the right level of ambition. It teaches the habits that modern automation teams increasingly need: traceability, reviewability, fault-aware testing, and evidence-backed revision. Not glamour. Just better engineering hygiene, which is usually what survives commissioning.

- IEC 61508 Functional safety overview - IEC 61131-3 Programmable controllers programming languages - NIST SP 800-207 Zero Trust Architecture - Tao et al. (2019) Digital twin in industry (IEEE) - Kritzinger et al. (2018) Digital twin in manufacturing (IFAC) - Negri et al. (2017) Digital twin in CPS-based production systems - exida Functional Safety resources - U.S. Bureau of Labor Statistics