Serializzazione JSON per PLC in OLLA Lab

OLLA Lab serializza la logica ladder in JSON strutturato anziché in file binari opachi. Questa rappresentazione basata su testo abilita la sincronizzazione cloud, il tracciamento delle modifiche basato sulle versioni e l'analisi automatizzata per i flussi di lavoro di validazione, mantenendo al contempo la pratica sui PLC all'interno di un ambiente di simulazione delimitato, anziché in un sistema di controllo attivo.

I file di progetto proprietari dei PLC non sono "sicuri" semplicemente perché sono difficili da leggere. In pratica, l'opacità spesso indebolisce la collaborazione, la verificabilità e il ripristino, poiché la logica rimane intrappolata all'interno di formati binari specifici del fornitore.

In OLLA Lab, i diagrammi ladder sono archiviati come schemi JSON strutturati che possono essere trasmessi, analizzati e ricostruiti in un ambiente basato su browser. Durante il benchmarking cloud interno di Ampergon Vallis del terzo trimestre 2025, la serializzazione di 25 progetti OLLA Lab, composti da un numero di rung variabile tra 20 e 100, ha prodotto una riduzione mediana del payload dell'82% rispetto alla baseline interna equivalente binaria della piattaforma, mentre l'analisi dello schema dell'intero progetto da parte dell'assistente Yaga è stata completata in meno di 400 ms per il caso di test da 100 rung [Metodologia: n=25 esportazioni di progetto; definizione dell'attività = serializzare e trasmettere lo stato completo del progetto ladder; comparatore di baseline = oggetto di archiviazione binario equivalente interno di Ampergon Vallis utilizzato per i test di architettura; finestra temporale = Q3 2025]. Ciò supporta un'affermazione sull'efficienza di trasporto e sulla velocità di analisi all'interno dell'architettura di OLLA Lab. Non supporta un'affermazione universale su tutti i software PLC.

Il punto fondamentale è semplice: la logica basata su testo è più facile da sottoporre a controllo versione, ispezionare, ripristinare e validare. I blob binari sono eccellenti nell'essere blob. Non è la stessa cosa.

I file binari proprietari limitano il controllo versione perché archiviano la logica di controllo come dati opachi orientati alla macchina anziché come testo indirizzabile per riga. I sistemi di controllo versione standard come Git funzionano al meglio quando possono confrontare modifiche testuali discrete, non quando un intero file sembra cambiare simultaneamente.

In molti ambienti PLC legacy, un file di progetto è effettivamente un contenitore compilato. Se un ingegnere modifica il preset di un timer e un altro modifica un contatto di consenso, Git spesso non è in grado di identificare tali modifiche come delta logici separati. Vede un unico artefatto binario alterato. La qualità del merge diminuisce immediatamente.

Ciò crea diversi vincoli pratici:

- Scarsa visibilità delle differenze (diff): gli strumenti standard di confronto testuale non possono mostrare cosa è cambiato a livello di rung o di istruzione. - Debolezza nel merge: le modifiche simultanee sono più difficili da conciliare senza strumenti specifici del fornitore. - Verificabilità limitata: i revisori possono sapere che un file è cambiato, ma non esattamente come. - Portabilità ridotta: il progetto diventa dipendente da un IDE e da un parser di file specifici. - Fragilità nell'usabilità dell'IA: i modelli linguistici di grandi dimensioni e i validatori basati su regole non possono ispezionare nativamente le strutture binarie proprietarie.

Una distinzione utile è quella tra integrità del file e intelligibilità ingegneristica. Un file binario può aprirsi correttamente e rimanere operativamente inutile per la revisione.

Blob binari vs. serializzazione JSON nell'automazione

| Proprietà | File binario proprietario | Logica serializzata in JSON | |---|---|---| | Leggibilità umana | Minima o nulla | Leggibile con consapevolezza della struttura | | Diff Git standard | Scarsa | Forte | | Supporto branch/merge | Limitato | Più forte, a seconda della disciplina dello schema | | Analisi IA | Tipicamente indiretta o non disponibile | Direttamente analizzabile | | Indipendenza dal fornitore | Bassa | Più alta a livello di struttura dati | | Diagnosi corruzione | Più difficile da isolare | Più facile da ispezionare e ripristinare selettivamente | | Trasporto cloud | Spesso più pesante e dipendente dallo strumento | Stateless e web-friendly |

Ciò non significa che l'archiviazione binaria sia illegittima. Significa che l'archiviazione binaria è scarsamente allineata con i moderni flussi di lavoro di revisione del software. L'OT ha convissuto con questo disallineamento per anni perché era necessario.

OLLA Lab traduce la logica ladder archiviando il diagramma come oggetti dati strutturati anziché come immagine piatta o blob di progetto opaco. Un rung viene rappresentato attraverso entità nidificate come istruzioni, associazioni di tag, stati, parametri e metadati di layout.

Quando un utente inserisce un'istruzione nell'editor del browser, la piattaforma registra le proprietà osservabili, tra cui:

• tipo di istruzione,
• riferimento al tag,
• indirizzo o identificatore,
• valori dei parametri,
• posizione del rung,
• stato rilevante per l'esecuzione,
• e contesto dello scenario associato, ove applicabile.

Ciò è importante perché l'oggetto salvato non è semplicemente un disegno. È una rappresentazione leggibile dalla macchina dell'intento di controllo.

### Esempio: rappresentazione JSON a livello di istruzione

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

Uno schema di progetto più completo includerebbe tipicamente oggetti aggiuntivi per:

• ordinamento dei rung,
• relazioni tra rami,
• istruzioni di uscita,
• preset di timer o contatori,
• valori analogici,
• parametri PID,
• associazioni di scenario,
• e snapshot dello stato di simulazione.

Cosa significa questo nella pratica

Se uno studente costruisce un rung di autoritenuta per l'avviamento di un motore, OLLA Lab può archiviare sia la struttura logica che il contesto di simulazione correlato. Ciò consente alla piattaforma di ricostruire il progetto nell'editor, eseguirlo in modalità simulazione ed esporre lo stesso stato al pannello delle variabili e all'assistente IA.

È qui che OLLA Lab diventa operativamente utile. La piattaforma non sta preservando uno screenshot della logica; sta preservando un modello di dati che altri componenti di sistema possono interrogare.

In questo articolo, archiviazione della logica ladder cloud-native significa che la logica può essere serializzata in schemi basati su testo, trasmessa in modo stateless a servizi remoti, archiviata indipendentemente da una workstation ingegneristica locale e ricostruita su richiesta in un ambiente accessibile via browser.

Questa definizione è più ristretta della versione di marketing che solitamente vaga per la stanza. Stiamo discutendo di architettura di archiviazione e trasporto, non di una proprietà mistica della virtù del software.

Un modello di archiviazione cloud-native per la logica ladder include tipicamente:

- trasmissione stateless: lo stato del progetto viene inviato come dati, non come contesto di memoria della workstation; - persistenza remota: i file di progetto risiedono in un archivio cloud gestito anziché solo su una macchina locale; - ricostruzione nel browser: l'editor può ricostruire il diagramma dagli oggetti serializzati; - interoperabilità dei servizi: IA, valutazione, condivisione e servizi di simulazione possono consumare lo stesso schema; - flessibilità del dispositivo: gli utenti possono accedere allo stesso progetto tramite desktop, tablet, mobile o ambienti XR supportati.

In OLLA Lab, questa architettura supporta un editor ladder basato sul web, flussi di lavoro di simulazione, formazione basata su scenari e assistenza guidata senza richiedere allo studente di gestire stack di runtime locali del fornitore solo per esercitarsi sul comportamento della logica.

Questo è un vantaggio per la formazione e la validazione, non un'affermazione che gli strumenti browser sostituiscano ogni suite ingegneristica dei fornitori. La distinzione è importante.

L'archiviazione PLC basata su testo abilita pratiche di revisione e collaborazione in stile software, difficili da applicare ai file di progetto opachi. I vantaggi principali sono il confronto (diffing), il branching, la recuperabilità e la validazione assistita dalla macchina.

1. Diffing

Un diff è un confronto a livello di riga tra due versioni di un file. In un progetto ladder basato su JSON, un revisore può identificare se la modifica ha riguardato:

• un preset del timer,
• un tipo di contatto,
• un'associazione di tag,
• una soglia analogica,
• o un parametro di sequenza.

Questo è materialmente migliore di "il file è cambiato". La revisione ingegneristica ha bisogno di qualcosa di più di una scrollata di spalle.

2. Branching

Il branching consente a un utente o a un team di testare strategie di controllo alternative senza sovrascrivere la versione di lavoro corrente. Nella formazione e nelle prove con gemelli digitali (digital twin), questo è particolarmente utile per confrontare:

• logiche di consenso alternative,
• revisioni per la gestione dei guasti,
• impostazioni di banda morta degli allarmi,
• opzioni di sequenziamento lead/lag,
• o esperimenti di tuning PID.

3. Recuperabilità

Gli schemi basati su testo sono più facili da ispezionare e parzialmente recuperare quando qualcosa va storto. Se un oggetto di progetto è malformato, il guasto può spesso essere isolato in una sezione specifica dello schema anziché rendere l'intero file illeggibile.

4. Collaborazione senza rigidi blocchi dei file

Un flusso di lavoro cloud strutturato può supportare la revisione multi-utente e il feedback dell'istruttore in modo più pulito rispetto ai passaggi di file locali. Le funzionalità di condivisione e valutazione di OLLA Lab si basano su questo vantaggio architettonico.

5. Migliori flussi di lavoro di validazione

Uno schema leggibile dalla macchina può essere controllato per verificarne la coerenza prima della distribuzione o dell'esecuzione della simulazione. Esempi includono:

• riferimenti ai tag mancanti,
• associazioni duplicate,
• intervalli di parametri non validi,
• strutture di rung incomplete,
• o discrepanze negli scenari.

Questo è adiacente alla più ampia idea di Infrastructure as Code: trattare la configurazione del sistema come dati ispezionabili e versionati. Nell'OT, il principio è utile, ma l'implementazione deve rimanere disciplinata. Un blocco dell'impianto causato da un'elegante igiene Git rimarrebbe comunque un blocco dell'impianto.

La serializzazione JSON rende OLLA Lab pronto per l'IA perché i sistemi di IA richiedono input di testo strutturato, non contenitori di progetti binari proprietari. Un modello linguistico, un motore di regole o un servizio di validazione possono analizzare direttamente chiavi, relazioni e valori JSON.

Quando un utente chiede a Yaga perché una pompa non si avvia, l'assistente non deduce lo stato di controllo dai pixel su uno schermo. Gli può essere fornita la struttura del progetto serializzata, gli stati attuali dei tag e il contesto dello scenario. Questa è la differenza tra interpretazione delle immagini e ragionamento consapevole dello schema.

Pronto per l'IA, definito operativamente

In questo contesto, pronto per l'IA significa:

• la logica di controllo esiste in un formato di testo strutturato,
• i tag rilevanti e i tipi di istruzione sono rappresentati esplicitamente,
• lo stato attuale della simulazione può essere allegato allo schema logico,
• e il pacchetto risultante può essere analizzato abbastanza velocemente da supportare un feedback interattivo.

Ciò supporta diversi casi d'uso delimitati:

• identificare un `XIO` bloccante o un consenso falso,
• rilevare un percorso di autoritenuta non agganciato,
• segnalare un uso incoerente dei tag,
• spiegare il comportamento del timer,
• rivedere la logica della soglia analogica,
• o guidare uno studente attraverso le probabili cause di guasto.

Ciò non significa che l'IA sia un'autorità di certificazione, un validatore di sicurezza o un sostituto per la revisione del progetto. L'IA può accelerare l'ispezione. Non eredita la responsabilità.

Perché questo è importante per l'apprendimento

Uno studente che scrive solo sintassi ladder non è ancora pronto per la simulazione (Simulation-Ready). Nell'utilizzo di Ampergon Vallis, Simulation-Ready significa essere in grado di dimostrare, osservare, diagnosticare e rafforzare la logica di controllo contro il comportamento realistico del processo prima che raggiunga un processo attivo.

Ciò include la capacità di:

• monitorare lo stato di I/O,
• confrontare lo stato ladder con il comportamento dell'apparecchiatura simulata,
• iniettare guasti,
• rivedere la logica dopo condizioni anomale,
• e spiegare perché la logica rivista è più corretta.

La sintassi è necessaria. La distribuibilità è la prova più difficile.

La serializzazione JSON supporta la validazione del gemello digitale fornendo al simulatore e al motore logico una descrizione condivisa e leggibile dalla macchina dello stato del sistema di controllo. Il programma ladder, i valori dei tag, le associazioni analogiche e i parametri dello scenario possono essere tutti scambiati come dati strutturati.

Un flusso di lavoro di validazione del gemello digitale, utilizzato con attenzione, non è solo "eseguire il codice in una bella scena 3D". Operativamente, significa verificare se la logica di controllo produce il comportamento dell'apparecchiatura previsto in condizioni normali e anomale definite.

In OLLA Lab, ciò può includere:

• attivare ingressi discreti e osservare la risposta in uscita,
• monitorare i valori analogici e il comportamento del comparatore,
• testare timer e contatori rispetto alle aspettative di sequenza,
• validare interblocchi e consensi,
• e confrontare le transizioni di stato della macchina con la filosofia di controllo prevista.

Questo è importante perché molti esercizi ladder si fermano alla correttezza del rung. La messa in servizio reale no. La logica deve sopravvivere al contatto con il comportamento del processo, e il comportamento del processo è solitamente meno educato della versione su lavagna.

Contesto degli standard

Il valore della simulazione e della validazione basata su modelli nel controllo industriale è coerente con la più ampia letteratura ingegneristica sui gemelli digitali, la messa in servizio virtuale e i test pre-distribuzione. Gli standard e le linee guida nella sicurezza funzionale e nella pratica del ciclo di vita dei sistemi di controllo, inclusa la IEC 61508, enfatizzano la validazione sistematica, la tracciabilità e la riduzione del rischio attraverso attività di verifica disciplinate piuttosto che la sola fiducia informale. Un simulatore non è un certificato SIL, ma è spesso un posto molto migliore per scoprire un'ipotesi errata rispetto a uno skid attivo.

Gli schemi di progetto basati su testo migliorano l'esportazione e il recupero perché sono portabili, ispezionabili e più facili da archiviare in repository software standard. In OLLA Lab, il valore pratico non è solo il backup. È la conservazione delle prove.

Uno studente o un ingegnere dovrebbe esportare i progetti in modo da preservare sia la logica che la storia della validazione attorno ad essa.

Pacchetto di prove ingegneristiche raccomandato

Se vuoi che un progetto dimostri le tue competenze in modo credibile, non creare una galleria di screenshot. Costruisci un corpo compatto di prove ingegneristiche:

Dichiara cosa significa un comportamento di successo in termini osservabili: condizioni di avvio, condizioni di arresto, interblocchi, soglie di allarme, finestre temporali e risposta ai guasti.

Documenta la condizione anomala introdotta: prova fallita, ingresso bloccato, livello basso, scatto per sovraccarico, condizione analogica fuori intervallo o timeout della sequenza.

Registra esattamente cosa è cambiato nella logica e perché: aggiunto consenso, corretta polarità del contatto, rivisto preset del timer, migliorata gestione degli allarmi o rafforzato il comportamento di riavvio.

1. Descrizione del sistema Definisci il processo o la macchina controllata, inclusi i principali ingressi, uscite, sequenze e vincoli operativi.
2. Definizione operativa di "corretto"
3. Logica ladder e stato dell'apparecchiatura simulata Preserva la versione della logica ladder insieme agli stati simulati rilevanti, ai valori dei tag e alle condizioni dello scenario.
4. Il caso di guasto iniettato
5. La revisione effettuata
6. Lezioni apprese Riassumi cosa ha rivelato il guasto sul progetto originale e cosa la logica rivista gestisce ora correttamente.

Quella struttura è più persuasiva dei soli elementi visivi rifiniti perché mostra il giudizio ingegneristico. Chiunque può esportare un file. Poche persone sanno spiegare perché un caso di guasto ha cambiato la filosofia di controllo.

Vantaggi pratici di recupero

Un'esportazione basata su testo supporta anche:

• archiviazione personale,
• cronologia delle versioni basata su repository,
• revisione dell'istruttore,
• confronto tra pari,
• e re-importazione selettiva in una nuova sessione di pratica.

Anche in questo caso, si tratta di un vantaggio delimitato all'interno di un ambiente di formazione e simulazione. Non implica un'equivalenza di distribuzione diretta ai pacchetti di runtime specifici del fornitore.

L'archiviazione ladder basata su JSON è preziosa perché trasforma la logica ladder in dati ingegneristici ispezionabili anziché in un artefatto di progetto opaco. Ciò abilita il controllo versione, i flussi di lavoro cloud, l'analisi assistita dall'IA e un ripristino più resiliente.

Per OLLA Lab nello specifico, il punto architettonico è più ristretto e forte di una generica affermazione di rivoluzione del software. OLLA Lab offre agli ingegneri un ambiente basato sul web per esercitarsi a trattare la logica di controllo come dati strutturati e testabili, validando al contempo il comportamento in simulazione, scenari di gemelli digitali e flussi di lavoro di risoluzione dei problemi guidata.

Questo è il giusto livello di ambizione. Insegna le abitudini di cui i team di automazione moderni hanno sempre più bisogno: tracciabilità, verificabilità, test consapevoli dei guasti e revisione basata su prove. Non glamour. Solo una migliore igiene ingegneristica, che è solitamente ciò che sopravvive alla messa in servizio.

- 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