Come convalidare la logica PLC utilizzando il Software-in-the-Loop (SITL) e i gemelli digitali di OLLA Lab

Il test Software-in-the-Loop (SITL) nell'automazione industriale consiste nell'esecuzione della logica di controllo PLC su un modello software del comportamento dell'apparecchiatura anziché su hardware fisico. In OLLA Lab, la logica ladder può essere testata su gemelli digitali 3D per verificare la temporizzazione delle sequenze, gli interblocchi, il comportamento in stati anomali e il ripristino dai guasti prima della messa in servizio dal vivo.

Una logica ladder sintatticamente corretta non è la stessa cosa di una logica di controllo pronta per l'implementazione. Un compilatore può confermare la validità delle istruzioni, la coerenza dei tag e l'ordine di esecuzione di base; non può dirti se un nastro trasportatore si indicizza verso un cilindro esteso, se una sequenza di riavvio riattiva un movimento pericoloso o se un sensore arriva troppo tardi per proteggere il meccanismo. La sintassi costa poco. Gli errori di messa in servizio no.

Una definizione utile di "pronto per la simulazione" è operativa, non aspirazionale: un ingegnere è pronto per la simulazione quando può dimostrare, osservare, diagnosticare e consolidare la logica di controllo contro un comportamento di processo realistico prima che raggiunga un processo reale.

In un'analisi interna di Ampergon Vallis su 1.200 scenari di messa in servizio simulati in OLLA Lab, gli utenti che hanno convalidato la logica su un gemello digitale 3D hanno identificato l'84% delle condizioni di race condition meccaniche modellate prima della prima esecuzione fisica. Metodologia: dimensione del campione = 1.200 esecuzioni di scenari in laboratori preimpostati e personalizzati; definizione del compito = rilevamento di race condition modellate come sovrapposizione di attuazione e conflitti di indicizzazione; comparatore di base = revisione della logica e stato di validità della compilazione senza esecuzione su gemello digitale; finestra temporale = gennaio 2025 - febbraio 2026. Ciò supporta l'affermazione che la simulazione può esporre classi di guasti che i normali controlli di sintassi non rilevano. Non dimostra l'affidabilità sul campo, la competenza dell'operatore o la certificazione di sicurezza.

SITL, HIL e la messa in servizio fisica rispondono a diverse domande di convalida. Trattarli come intercambiabili è un modo sicuro per trascurare i rischi.

Secondo il framework di messa in servizio virtuale descritto nella VDI 3693, il Software-in-the-Loop (SITL) significa che la logica del controllore e il comportamento dell'impianto sono entrambi rappresentati nel software, senza che sia necessaria la presenza del PLC fisico, del cablaggio di campo o dell'hardware della macchina. Lo scopo è convalidare il comportamento del controllo rispetto alla risposta simulata del processo in un ambiente a rischio contenuto.

L'Hardware-in-the-Loop (HIL) si avvicina di un livello alla realtà. L'impianto rimane simulato, ma viene introdotto l'hardware del controllore reale. Questo testa la temporizzazione dell'hardware, la gestione degli I/O e alcuni comportamenti specifici della piattaforma che il SITL non può riprodurre completamente.

La messa in servizio fisica è lo stack completo: logica di controllo, PLC fisico, cablaggio, strumentazione, attuatori, dinamica della macchina e le sorprese che appaiono quando tutto ciò si incontra durante l'avvio.

### Confronto: SITL vs HIL vs messa in servizio fisica

| Modalità di convalida | Cosa è reale | Cosa è simulato | Scopo principale | Livello di rischio | |---|---|---|---|---| | SITL | Ambiente di esecuzione della logica di controllo | Comportamento dell'impianto/attrezzatura | Convalidare logica di sequenza, interblocchi, ipotesi di temporizzazione, transizioni di stato, gestione guasti | Basso | | HIL | Hardware PLC/controllore fisico | Comportamento dell'impianto/attrezzatura | Convalidare esecuzione specifica del controllore, comportamento I/O, temporizzazione hardware, ipotesi di integrazione | Medio | | Messa in servizio fisica | PLC, cablaggio, sensori, attuatori, macchina/processo | Poco o nulla | Convalidare il sistema implementato in condizioni operative reali | Alto |

In cosa eccelle il SITL

• Verifica dell'ordine delle sequenze e della logica di permesso
• Test del comportamento di allarme e trip
• Esercitazione della logica di riavvio e ripristino
• Esposizione di race condition tra comandi e feedback
• Prove di stati anomali senza rischiare l'attrezzatura

Cosa non sostituisce il SITL

• Test di accettazione in sito (SAT)
• Loop check e verifica del cablaggio
• Convalida della sicurezza funzionale
• Determinazione SIL o dimostrazione di conformità
• Formazione dell'operatore sull'asset installato esatto, a meno che l'ambito del modello non lo supporti

Quel confine è importante. Un gemello digitale è utile perché restringe l'incertezza, non perché la elimina.

La logica ladder fallisce sul campo perché i sistemi fisici non sono diagrammi booleani. Hanno ritardi, inerzia, attrito, deriva e modalità di guasto che un compilatore non modella.

Un rung valido per la compilazione può comunque comandare una sequenza impossibile. Può anche comandare una sequenza possibile al momento sbagliato, il che è spesso peggio perché fallisce in modo intermittente.

Le tre realtà fisiche che i compilatori ignorano

1. Inerzia meccanica Un comando di arresto non produce un arresto istantaneo. I motori procedono per inerzia, i nastri trasportatori superano la corsa e i carichi sospesi continuano a muoversi. La logica può essere corretta a livello di scansione e comunque errata a livello di macchina.
2. Latenza dei sensori I sensori reali hanno tempi di risposta, tolleranze di montaggio, rimbalzi e filtraggio. Una fotocellula o un finecorsa che cambia stato con qualche millisecondo di ritardo rispetto al previsto può invalidare una sequenza altrimenti elegante.
3. Stiction (attrito di primo distacco) dell'attuatore e ritardo di processo I cilindri pneumatici necessitano di accumulo di pressione. Le valvole possono bloccarsi prima di muoversi. Le pompe non creano un flusso stabile nell'istante in cui si attiva un bit del motore. Al diagramma ladder non importa; al processo sì.

La fallacia del "sembra giusto"

"Sembra giusto" solitamente significa "supera una revisione visiva sotto ipotesi ideali". Non è la stessa cosa che dimostrare che la sequenza sopravvive a temporizzazioni realistiche e condizioni di guasto.

Si consideri un nastro trasportatore di smistamento con un cilindro spintore:

• La logica comanda l'arresto del nastro.
• La logica comanda l'estensione del cilindro.
• La logica attende la conferma di estensione.
• La logica riavvia il nastro dopo la deviazione del prodotto.

Sulla carta, è ordinato. In una macchina simulata, il nastro potrebbe ancora essere in fase di arresto per inerzia quando il cilindro entra nella corsia. Se la sequenza dipende dall'arresto istantaneo, il meccanismo collide anche se ogni rung è legale e ogni nome di tag è corretto. Il compilatore non obietterà. La fisica solitamente sì.

In questo articolo, un gemello digitale non è un sinonimo di marketing per la grafica 3D. È un modello software che scambia lo stato con la logica di controllo in un loop di convalida deterministico.

Operativamente, un gemello digitale per la convalida PLC è:

> Un modello software cinematico e a eventi discreti che consuma gli output del PLC, applica vincoli fisici simulati come ritardo di movimento, gravità, attrito e temporizzazione dipendente dallo stato, e restituisce input deterministici di sensori e processi alla logica di controllo.

Quella definizione è intenzionalmente ristretta. Esclude la visualizzazione decorativa che non partecipa allo scambio dello stato di controllo.

Un gemello digitale utile per il lavoro di controllo deve fare quattro cose

Esempio: comandi di marcia motore, comandi di apertura valvola, bit di estensione cilindro, setpoint analogici.

• Consumare gli output del controllore

Esempio: accelerazione, decelerazione, tempo di sosta, tempo di percorrenza, ritardo di pressione, variazione di livello o ritardo di processo.

• Applicare il comportamento modellato dell'attrezzatura

Esempio: finecorsa, fotocellule, sensori di prossimità, PV analogici, stati di allarme, feedback di prova.

• Restituire input simulati alla logica

Lo stesso caso di test dovrebbe essere riproducibile a sufficienza per diagnosticare modifiche alla logica e confrontare le revisioni.

• Preservare condizioni di test deterministiche

Questa è la differenza tra un video e un ambiente di convalida. Uno è illustrativo. L'altro può porre il veto a una logica di controllo errata.

OLLA Lab diventa operativamente utile quando il programma ladder e l'attrezzatura simulata condividono uno stato osservabile. La piattaforma non è solo un editor ladder con una scena accanto; il valore sta nel collegare le variabili logiche al comportamento della macchina e poi osservare la chiusura del loop.

In OLLA Lab, gli utenti costruiscono la logica ladder in un editor basato su web, la eseguono in modalità simulazione e ispezionano o manipolano le variabili attraverso il pannello delle variabili. La piattaforma supporta flussi di lavoro di apprendimento orientati a booleani, analogici, timer, comparatori, matematica e PID, insieme a scenari di simulazione 3D/WebXR. All'interno di quel flusso di lavoro, i tag possono essere associati agli stati dell'attrezzatura simulata in modo che i bit di comando guidino il modello e gli eventi del modello restituiscano feedback nella logica.

Flusso di lavoro pratico di associazione dei tag in OLLA Lab

Una configurazione di convalida tipica appare così:

• Definire i tag di comando nella logica ladder
• `Conveyor_Run_CMD`
• `Cylinder_Extend_CMD`
• `Reset_Fault_CMD`

• Definire i tag di feedback e sensore
• `Conveyor_At_Speed`
• `Cylinder_Extended_LS`
• `Photoeye_PE1`
• `Jam_Fault`

• Associare i tag di comando ai comportamenti del gemello digitale
• `Conveyor_Run_CMD` guida lo stato di movimento del nastro
• `Cylinder_Extend_CMD` guida la sequenza di estensione dell'attuatore

• Associare le risposte dell'attrezzatura simulata ai tag
• Il movimento del nastro aggiorna `Conveyor_At_Speed`
• Il finecorsa virtuale aggiorna `Cylinder_Extended_LS`
• Il raycast virtuale o il rilevamento oggetti aggiorna `Photoeye_PE1`

• Eseguire la sequenza e ispezionare le transizioni di stato
• Attivare/disattivare gli input
• Mettere in pausa, eseguire o arrestare la simulazione
• Osservare i cambiamenti dei tag, i timer, i valori analogici e gli stati di guasto

Cosa offre questo all'ingegnere

• Una catena visibile di causa-effetto tra la logica dei rung e la risposta della macchina
• Un luogo dove testare se gli interblocchi sono effettivamente sufficienti
• Un modo per ispezionare le discrepanze di temporizzazione tra comando e prova
• Un ambiente sicuro per iniettare guasti che sarebbero costosi o pericolosi su attrezzature reali

È qui che OLLA Lab si inserisce in modo credibile: come ambiente di prova a rischio contenuto per la convalida e la pratica di risoluzione dei problemi. Non sostituisce la messa in servizio sul campo, ma può consentire agli ingegneri di provare parti della messa in servizio che sono troppo distruttive, troppo costose o troppo dirompenti per essere apprese su una linea attiva.

I test SITL più preziosi non sono le sequenze nominali. Sono i test di stato anomalo. Quasi ogni strategia di controllo sembra competente quando ogni sensore si comporta bene e ogni attuatore arriva in tempo.

Casi di test SITL obbligatori

Attivare un arresto di emergenza mentre il movimento è attivo e il meccanismo sta trasportando o spingendo materiale. Verificare:

• che il movimento pericoloso venga disattivato come previsto,
• che la memoria di stato si comporti in modo prevedibile,
• che il riavvio richieda un'azione deliberata dell'operatore,
• che non esista alcun percorso di ripresa automatica nascosto.

Forzare un dispositivo di finecorsa normalmente chiuso o normalmente aperto nello stato di guasto durante il movimento. Verificare:

• che il rilevamento del guasto avvenga entro la finestra prevista,
• che il movimento venga inibito o arrestato in sicurezza,
• che il testo dell'allarme e i bit di guasto siano inequivocabili,
• che le condizioni di ripristino siano deliberate e limitate.

Simulare la perdita di alimentazione di controllo o l'interruzione dell'esecuzione. Verificare:

• che gli output tornino ai valori predefiniti di sicurezza,
• che la logica di avvio non riavvii automaticamente il movimento pericoloso,
• che gli stati conservati non creino ipotesi di sequenza impossibili,
• che sia richiesta la conferma dell'operatore ove appropriato.

Comandare un movimento e non ricevere il feedback previsto. Verificare:

• che la logica di timeout scatti,
• che il guasto venga bloccato correttamente,
• che il movimento a valle venga bloccato,
• che il percorso di ripristino sia esplicito.

Introdurre una sovrapposizione di temporizzazione tra stati adiacenti della macchina. Verificare:

• che le azioni mutuamente esclusive rimangano tali,
• che uno stato non possa prevaricare un altro senza la prova richiesta,
• che le ipotesi sull'ordine di scansione non mascherino un difetto di sequenziamento.

Iniettare disturbi di processo o valori del sensore non realistici. Verificare:

• che gli allarmi si attivino alle soglie definite,
• che l'output di controllo si comporti entro i limiti previsti,
• che il trasferimento senza urti o i cambi di modalità siano gestiti correttamente,
• che i trip e i permessi rimangano coerenti in caso di disturbo analogico.

1. E-stop asincrono sotto carico
2. Guasto del sensore e verifica del failsafe
3. Ripristino dopo interruzione di corrente
4. Timeout meccanico e condizioni di assenza di prova
5. Race condition di sequenza
6. Escursione analogica e disturbo PID

Un'idea sbagliata pratica che vale la pena correggere

Testare solo il percorso ideale non è convalida. È dimostrazione. Il rischio reale della messa in servizio risiede nelle transizioni, nei ritardi e nei guasti.

Un pattern di timeout è una delle strutture difensive più semplici che acquisisce valore reale nel SITL. Converte "l'attuatore avrebbe dovuto muoversi ormai" in una condizione di guasto osservabile.

Di seguito è riportato un esempio compatto per un timeout di estensione cilindro. La sintassi esatta varia a seconda della piattaforma, ma l'intento di controllo è standard.

Linguaggio: Ladder Diagram

// Logica di guasto per timeout attuazione cilindro |---[ ]-----------[/]-----------[/]-----------------(TON)---| CMD_Extend Limit_Retract Limit_Extend Fault_Delay

|---[ ]---------------------------------------------( )-----| Fault_Delay.DN Fault_Cyl_Ext_Timeout

Cosa sta facendo questo rung

• `CMD_Extend` avvia la condizione di temporizzazione quando viene comandata l'estensione.
• `Limit_Retract` non attivo indica che il cilindro non è più in posizione di riposo sicura, a seconda della filosofia del dispositivo.
• `Limit_Extend` non attivo significa che la prova di estensione non è ancora arrivata.
• `Fault_Delay` temporizza la finestra di corsa consentita.
• Quando il timer completa senza prova di estensione, viene impostato `Fault_Cyl_Ext_Timeout`.

Perché il SITL è importante qui

In una revisione statica della logica, questo rung appare semplice. In un gemello digitale, puoi testare se il timeout è:

• troppo breve per una corsa realistica dell'attuatore,
• troppo lungo per proteggere il meccanismo,
• ripristinato in modo errato dalle transizioni di sequenza,
• cieco a movimenti parziali o condizioni di inceppamento.

Questa è la differenza tra scrivere un timeout e convalidarne uno.

Le prove ingegneristiche dovrebbero mostrare il ragionamento, non solo la familiarità con l'interfaccia. Una galleria di screenshot dimostra che il software è stato aperto. Dimostra ben poco altro.

Se l'obiettivo è dimostrare un serio lavoro di controllo, documenta ogni esercizio simulato utilizzando questa struttura:

Struttura delle prove richiesta

Esempio: "Il nastro trasportatore non deve riavviarsi finché il cilindro deviatore non è completamente retratto e la presenza del prodotto è stata eliminata."

Esempio: "Comando di estensione cilindro emesso mentre il tempo di arresto per inerzia del nastro era di 1,8 s."

Esempio: "Aggiunto permesso di velocità zero del nastro e guasto di timeout estensione."

1. Descrizione del sistema Definisci la macchina o la cella di processo, i principali attuatori, i sensori e l'obiettivo operativo.
2. Definizione operativa di "corretto" Dichiara cosa deve essere vero affinché la sequenza sia considerata corretta.
3. Logica ladder e stato dell'attrezzatura simulata Mostra i rung rilevanti, le definizioni dei tag e i corrispondenti stati o feedback del gemello digitale.
4. Il caso di guasto iniettato Dichiara esattamente cosa è stato forzato o disturbato.
5. La revisione apportata Documenta la modifica alla logica.
6. Lezioni apprese Spiega quale ipotesi è fallita e come la logica rivista consolida la sequenza.

Questa struttura è utile perché cattura l'intento di controllo, il modello di guasto e il ragionamento correttivo. Questo è il materiale che i datori di lavoro e i revisori possono effettivamente interrogare. Gli screenshot da soli sono per lo più decorativi.

OLLA Lab supporta un flusso di lavoro pronto per la simulazione combinando la creazione ladder, la simulazione, l'ispezione delle variabili, il contesto dello scenario e l'interazione con il gemello digitale in un unico ambiente basato su web. Il vantaggio non è la comodità fine a se stessa; è la riduzione del cambio di contesto durante la convalida.

All'interno dei fatti di prodotto limitati forniti, OLLA Lab offre:

• Un editor di logica ladder basato su web con contatti, bobine, timer, contatori, comparatori, funzioni matematiche, operazioni logiche e istruzioni PID
• Modalità di simulazione per eseguire la logica, attivare input e osservare output senza hardware fisico
• Un pannello delle variabili per monitorare tag, I/O, valori analogici, variabili correlate al PID e stato dello scenario
• Simulazioni 3D/WebXR/VR che collegano la logica di controllo al comportamento dell'attrezzatura
• Flussi di lavoro di convalida con gemelli digitali per testare la logica contro modelli di macchine realistici
• Laboratori basati su scenari in produzione, acqua/acque reflue, HVAC, chimica, farmaceutica, magazzinaggio, alimenti e bevande e servizi pubblici
• Istruzioni di costruzione guidate con obiettivi, mappatura I/O, filosofia di controllo, interblocchi e passaggi di verifica
• Guida AI tramite GeniAI, posizionata come coaching di laboratorio e supporto correttivo all'interno del flusso di lavoro di apprendimento

L'affermazione limitata

OLLA Lab può aiutare gli ingegneri a provare compiti di convalida che sono difficili da organizzare in sicurezza su sistemi reali:

• tracciare la causa-effetto degli I/O,
• testare gli interblocchi,
• osservare il comportamento dei guasti,
• rivedere la logica dopo un fallimento di stato anomalo,
• confrontare lo stato ladder con lo stato dell'attrezzatura simulata.

Non dovrebbe essere inquadrato come un sostituto dell'esperienza sul campo, del lavoro formale di sicurezza funzionale o dell'autorità di messa in servizio specifica del sito. Un simulatore può esporre ipotesi errate in anticipo. Non può firmare un impianto.

Il SITL può migliorare la qualità della messa in servizio spostando la scoperta dei difetti in una fase precedente, ma non stabilisce di per sé la conformità alla sicurezza. Tale distinzione è centrale.

Cosa può supportare il SITL

• Scoperta precoce dei difetti di sequenziamento
• Migliore copertura dei test degli stati anomali
• Prova più sicura della gestione dei guasti
• Preparazione alla messa in servizio più disciplinata
• Migliore comunicazione tra i team di controllo, meccanici e di processo

Cosa richiede ancora un trattamento separato

• Attività del ciclo di vita della sicurezza funzionale secondo IEC 61508
• Progettazione e verifica delle funzioni di sicurezza strumentate
• Valutazione del rischio specifica del sito
• Analisi della tolleranza ai guasti hardware
• Test di prova e convalida del sistema installato

La letteratura di settore sulla messa in servizio virtuale e sulla simulazione cyber-fisica supporta generalmente il valore della convalida precoce del comportamento, specialmente per i sistemi meccatronici e ad alta intensità di sequenza. Il risultato ricorrente non è che la simulazione rimuove il rischio di messa in servizio. È che la simulazione sposta una parte significativa della scoperta dei difetti in una fase più economica e sicura del progetto. Questa è un'affermazione più modesta, e anche la più credibile.

Inizia con una sequenza compatta che contenga movimento, feedback e un ramo di stato anomalo. Se il primo esercizio è troppo semplice, insegna la sintassi ma non il giudizio.

Un buon caso iniziale in OLLA Lab è uno scenario di nastro trasportatore e deviatore o pompa lead/lag con:

• un percorso di comando,
• un feedback di prova,
• un timeout,
• un allarme,
• una condizione di riavvio,
• un guasto iniettato.

Ciò fornisce una struttura sufficiente per testare la causalità senza perdersi nell'architettura. Il punto è imparare se la logica sopravvive al contatto con un processo modellato, non costruire un grande sistema il primo giorno.

- IEC 61131-3: Controllori programmabili — Parte 3 - Panoramica dello standard di sicurezza funzionale IEC 61508 - Profilo NIST Smart Manufacturing - IEEE Access: Tecnologie abilitanti per gemelli digitali (DOI)

Questo articolo è stato redatto dal team tecnico di OLLA Lab in collaborazione con gli esperti di automazione di Ampergon Vallis Lab, focalizzandosi sulle migliori pratiche per la convalida della logica di controllo industriale.

Il contenuto è stato verificato rispetto agli standard VDI 3693 per la messa in servizio virtuale e alle metodologie di test SITL standard del settore. I dati sulle prestazioni citati si basano su analisi interne di Ampergon Vallis condotte tra il 2025 e il 2026.