Come funziona il ciclo di scansione PLC: simulare l'esecuzione deterministica in OLLA Lab

Un ciclo di scansione PLC è un loop deterministico in cui il controllore legge gli ingressi, esegue la logica in sequenza, scrive le uscite ed esegue le attività di sistema. OLLA Lab imita questo comportamento in un ambiente di simulazione basato su browser, consentendo ai tecnici di osservare i guasti dipendenti dalla scansione, testare le revisioni della logica e convalidare il rapporto causa-effetto prima della messa in servizio dal vivo.

Un malinteso comune è che la logica ladder si comporti come un normale software che reagisce istantaneamente agli eventi. Non è così. Un PLC solitamente interroga la realtà con una scansione ripetuta, valuta la logica in un ordine definito e aggiorna le uscite solo dopo che tale valutazione è completa. Questa distinzione rappresenta la differenza tra un codice che sembra corretto e un codice che funziona correttamente su una macchina.

Durante una recente valutazione interna dello scenario di smistamento ad alta velocità di OLLA Lab, il 68% degli utenti junior non è riuscito a catturare un impulso del sensore ottico da 10 ms quando il tempo di scansione simulato era impostato a 20 ms [Metodologia: n=41 utenti; compito = rilevare e mantenere un impulso transitorio di una fotocellula in uno scenario di scarto su nastro trasportatore; comparatore di base = cattura dell'impulso riuscita con scansione simulata a 5 ms; finestra temporale = 15 gen – 10 mar 2026]. Si tratta di un benchmark interno di Ampergon Vallis, non di una pretesa di prevalenza nel settore. Supporta un unico punto preciso: la temporizzazione della scansione è spesso scarsamente compresa anche quando la logica dei rung appare sintatticamente corretta.

È esattamente qui che OLLA Lab risulta utile. Fornisce un ambiente software-in-the-loop delimitato per osservare l'esecuzione deterministica, la visibilità degli I/O e le modalità di guasto dipendenti dalla scansione prima che qualcuno impari la lezione su una macchina reale, dove il costo dell'errore è molto più elevato.

Un ciclo di scansione PLC standard è una sequenza ripetitiva e deterministica con quattro fasi funzionali. L'implementazione esatta varia a seconda del fornitore e del modello di attività, ma il pattern principale è stabile nell'esecuzione ciclica convenzionale.

Il punto chiave per l'ingegneria è semplice: il programma solitamente non legge un ingresso fisico fresco a ogni istruzione. Lavora a partire da un'immagine in memoria durante l'esecuzione, per poi aggiornare le uscite successivamente.

1. Scansione degli ingressi (Lettura) Il controllore legge lo stato attuale degli ingressi fisici e copia tali stati in memoria, spesso chiamata tabella immagine degli ingressi o immagine di processo.
2. Esecuzione del programma (Logica) Il controllore esegue il programma utente utilizzando gli stati degli ingressi memorizzati. Nella logica ladder, questa viene solitamente valutata dall'alto verso il basso e da sinistra verso destra all'interno dell'attività o della struttura di routine attiva.
3. Scansione delle uscite (Scrittura) Il controllore scrive gli stati finali delle uscite calcolati dalla memoria ai terminali di uscita fisici.
4. Housekeeping (Comunicazioni/Diagnostica) Il controllore gestisce la diagnostica interna, le comunicazioni, gli aggiornamenti dei timer, la messaggistica e altre attività di sistema.

Perché questo è importante nella pratica

L'esecuzione basata sulla scansione crea comportamenti prevedibili ma non ovvi:

• Un impulso breve può essere perso se si verifica tra due scansioni.
• Una bobina scritta due volte in una singola scansione può essere sovrascritta silenziosamente.
• Un'uscita che appare vera in un rung potrebbe non eccitarsi mai fisicamente se un rung successivo la resetta prima della fase di aggiornamento delle uscite.
• Le ipotesi di temporizzazione che sembrano innocue sullo schermo possono fallire di fronte alle dinamiche reali del processo.

Ecco perché conoscere la sintassi ladder non equivale a essere pronti per la simulazione. Operativamente, un tecnico pronto per la simulazione è in grado di dimostrare, osservare, diagnosticare e rafforzare la logica di controllo contro il comportamento reale del processo prima che questo raggiunga un processo dal vivo.

I linguaggi IT di uso generale non sono intrinsecamente sbagliati per il software. Sono sbagliati per spiegare l'esecuzione dei PLC se si ignora il modello di controllo. Il problema non è il prestigio del linguaggio, ma la semantica dell'esecuzione.

Esecuzione IT contro esecuzione OT

| Caratteristica | Linguaggi IT (Python/JavaScript, in generale) | Esecuzione OT / PLC (contesto IEC 61131-3) | |---|---|---| | Modello di trigger primario | Guidato da eventi, callback o scheduler | Polling ciclico ed esecuzione deterministica delle attività | | Relazione con la memoria | L'allocazione dinamica è comune | Tag predefiniti, memoria strutturata, mappatura diretta del processo | | Interazione hardware | Solitamente astratta tramite driver/API | Relazione diretta con immagini I/O, stati di campo e temporizzazione di scansione | | Temporizzazione esecuzione | Spesso non deterministica a livello applicativo | Progettata per un'esecuzione del controllo ripetibile e delimitata | | Modalità di guasto | Latenza, race condition, problemi di ordine delle callback | Impulsi mancati, logica di sovrascrittura, ipotesi su immagini obsolete | | Priorità ingegneristica | Throughput, flessibilità, interazione utente | Determinismo, ripetibilità, comportamento sicuro della macchina |

La norma IEC 61131-3 definisce i linguaggi di programmazione e i concetti di esecuzione utilizzati nel controllo industriale, inclusi Ladder Diagram, Function Block Diagram, Structured Text e Sequential Function Chart (IEC, 2013). Nella pratica, il controllo PLC dipende dal comportamento deterministico delle attività, dalla gestione esplicita dello stato e da un ordine di scansione prevedibile. Il software web spesso presuppone che il mondo possa attendere il prossimo evento. Pompe, cilindri e nastri trasportatori solitamente non possono.

L'importante contrasto

Il contrasto netto è questo: risposta agli eventi contro controllo ciclico.

Questa differenza è importante perché l'automazione fisica non riguarda solo il calcolo di un risultato. Riguarda il calcolo del risultato al momento giusto, nell'ordine giusto, a fronte di condizioni dell'impianto mutevoli.

L'esecuzione sequenziale ladder significa che il controllore valuta la logica in un ordine definito, non tutta in una volta. In una scansione convenzionale, il programma viene risolto rung per rung, dalla parte superiore della routine verso il basso, e all'interno di ogni rung da sinistra a destra secondo le regole di esecuzione della piattaforma.

Conseguenze osservabili dell'esecuzione sequenziale

- La risoluzione dei problemi deve distinguere tra:

• La logica precedente può impostare un bit interno che la logica successiva utilizza immediatamente.
• La logica successiva può sovrascrivere un risultato stabilito in precedenza nella stessa scansione.
• Gli stati intermedi possono esistere in memoria durante l'esecuzione anche se l'uscita fisica non è ancora cambiata.
• stato del tag in memoria
• stato dell'uscita fisica al terminale

Questa distinzione è facile da perdere in aula e difficile da ignorare durante la messa in servizio.

Fondamenti IEC

La IEC 61131-3 fornisce il quadro linguistico, ma la documentazione del fornitore e l'architettura di runtime determinano i dettagli esatti della pianificazione delle attività e dell'aggiornamento. L'affermazione corretta è questa: la valutazione sequenziale e l'esecuzione ciclica sono comportamenti fondamentali nei sistemi di controllo PLC tradizionali, anche se i dettagli di implementazione differiscono a seconda della famiglia di controllori.

La sindrome della doppia bobina si verifica quando la stessa uscita o bobina di memoria viene scritta in più di un punto, consentendo a un'istruzione successiva di sovrascrivere una precedente durante la stessa scansione. Lo stato finale scritto nell'esecuzione della logica è quello che sopravvive fino alla fase di aggiornamento delle uscite.

Ecco il pattern classico:

[Linguaggio: Ladder Diagram]

RUNG 1: Il comando di avvio imposta Motor_Run su true in memoria. |---[ Start_PB ]-------------------------------------( Motor_Run )---|

RUNG 2: Una condizione successiva scrive sulla stessa bobina. Se questo rung viene valutato come false in modo tale da diseccitare lo stesso target, lo stato precedente viene effettivamente sovrascritto prima che le uscite vengano scritte. |---[ Some_Other_Condition ]-------------------------( Motor_Run )---|

Cosa succede realmente

- Risultato: il motore potrebbe non eccitarsi mai anche se un rung precedente sembrava corretto.

• Il primo rung scrive `Motor_Run = TRUE` in memoria.
• Un rung successivo scrive sullo stesso target.
• L'ultima scrittura determina lo stato finale della memoria alla fine dell'esecuzione.
• L'aggiornamento dell'uscita fisica avviene successivamente.

Questa è l'esecuzione deterministica che fa esattamente ciò che specifica la logica, indipendentemente dall'intento.

Perché questo guasto è utile per la formazione

I guasti a doppia bobina espongono rapidamente tre idee fondamentali:

• l'ordine è importante
• lo stato della memoria non è uguale allo stato del terminale
• la correttezza visiva del rung non è sufficiente

In OLLA Lab, questo diventa osservabile piuttosto che teorico, poiché gli utenti possono eseguire la logica, ispezionare le variabili e confrontare lo stato ladder con il comportamento dell'apparecchiatura simulata.

Un impulso breve può essere perso quando la sua durata è inferiore all'opportunità effettiva del controllore di campionarlo. Se un ingresso si accende e si spegne tra due scansioni degli ingressi, la CPU potrebbe non registrare mai l'evento nell'immagine degli ingressi.

### Esempio: larghezza dell'impulso contro tempo di scansione

Se:

• un impulso della fotocellula dura 10 ms, e
• il controllore campiona gli ingressi ogni 20 ms,

allora l'impulso può verificarsi interamente tra due scansioni e scomparire dalla prospettiva del programma.

Questo è un problema di campionamento. Nel lavoro di controllo appare spesso come "il sensore si è attivato sicuramente, ma il PLC non l'ha mai visto". Entrambe le affermazioni possono essere vere.

Perché i tecnici dovrebbero preoccuparsene

Gli impulsi mancati influenzano:

• smistamento ad alta velocità
• logica adiacente all'encoder
• conferma di scarto
• conteggio di bottiglie o cartoni
• segnali di prova intermittenti
• allarmi attivati dal fronte

La soluzione può comportare attività più veloci, latch hardware, allungamento dell'impulso, one-shot, contatori ad alta velocità o una progettazione della sequenza rivista. La risposta corretta dipende dal processo e dall'architettura del controllore.

OLLA Lab imita la scansione della CPU fisica fornendo un ambiente di simulazione strutturato in cui la logica ladder viene eseguita come un loop deterministico anziché come reazioni libere agli eventi del browser. Più semplicemente, è progettato per consentire agli utenti di osservare il comportamento di controllo dipendente dalla scansione, non solo di disegnare rung.

Cosa fa OLLA Lab in termini delimitati

All'interno della piattaforma, gli utenti possono:

• costruire logica ladder in un editor basato su web
• eseguire la logica in modalità simulazione
• attivare e ispezionare ingressi, uscite e variabili
• lavorare attraverso scenari industriali realistici
• confrontare il comportamento ladder con viste delle apparecchiature 3D/WebXR/VR ove disponibili
• utilizzare GeniAI, la guida di laboratorio AI, per un supporto guidato

Per lo scopo di questo articolo, il fatto importante sul prodotto è più ristretto: OLLA Lab fornisce un ambiente basato su software per provare l'esecuzione della logica deterministica e osservare come la temporizzazione della scansione influenzi il comportamento della macchina.

Comportamenti osservabili che la piattaforma è adatta a dimostrare

• Comportamento di sovrascrittura a doppia bobina
• Impulsi transitori mancati
• Tracciamento causa-effetto attraverso gli I/O
• Guasti di sequenza causati da ipotesi obsolete sullo stato
• Differenze tra lo stato ladder e lo stato dell'apparecchiatura simulata

Ciò lo rende utile come ambiente di prova software-in-the-loop per attività di messa in servizio ad alto rischio. Non sostituisce i test di accettazione dell'hardware, la convalida della sicurezza o la messa in servizio specifica del sito. Questi appartengono ancora al sistema reale, con il controllore reale, sotto i vincoli reali.

Perché la distribuzione via browser è importante

Un ambiente basato su browser riduce l'attrito di configurazione per l'apprendimento e la revisione. Ancora più importante, consente l'iniezione ripetuta di guasti a basso rischio senza impegnare un formatore fisico o hardware adiacente alla produzione.

In questo contesto, la convalida del gemello digitale significa testare la logica ladder contro una macchina o un modello di processo simulato e verificare se il comportamento previsto dell'apparecchiatura corrisponde alla filosofia di controllo in condizioni normali e anomale.

Questa definizione deve rimanere ancorata alla realtà. Non significa che la simulazione sia un sostituto legalmente sufficiente per l'accettazione del sito, la verifica SIL o la messa in servizio dell'impianto.

### Operativamente, la convalida del gemello digitale include:

• confrontare gli stati dei comandi con la risposta dell'apparecchiatura simulata
• verificare l'ordine della sequenza e i permissivi
• controllare il comportamento degli allarmi e dei trip
• osservare i cambiamenti di stato analogici o guidati da PID dove modellati
• iniettare guasti e confermare la risposta della logica
• rivedere il programma e rieseguire i test

È qui che OLLA Lab diventa operativamente utile. Consente ai tecnici di testare se una sequenza funziona su un modello realistico prima di testarla su apparecchiature che possono incepparsi, allagarsi, andare fuori corsa o fallire in modi costosi.

I tecnici dovrebbero esercitarsi nella gestione dei guasti dipendenti dalla scansione costruendo scenari in cui la logica è costretta a fallire per motivi di temporizzazione, per poi rivedere il progetto fino a quando la modalità di guasto non viene controllata e spiegabile.

### Un esercizio pratico: cattura dell'impulso in uno scenario di nastro trasportatore

Utilizza uno scenario di tipo nastro trasportatore o smistamento e definisci un evento del sensore transitorio che sia più breve dell'intervallo di scansione simulato.

#### Passaggio 1: Costruire la logica iniziale

Crea una logica che dipenda direttamente da un impulso della fotocellula per attivare un'azione come scarto, conteggio o deviazione.

#### Passaggio 2: Impostare le condizioni simulate

Utilizza un intervallo di scansione più lungo della durata dell'impulso. Quindi esegui lo scenario e osserva se l'evento viene catturato in modo affidabile.

#### Passaggio 3: Ispezionare le variabili e lo stato dell'apparecchiatura

Utilizza il pannello delle variabili per confrontare:

• stato dell'ingresso
• bit di memoria interna
• comandi di uscita
• risposta dell'apparecchiatura simulata

#### Passaggio 4: Iniettare il caso di guasto

Forza un impulso che si verifica troppo rapidamente per le attuali ipotesi di scansione. Conferma che la logica lo perda.

#### Passaggio 5: Revisionare la logica

Le possibili revisioni includono:

• aggiungere un percorso di latch o seal-in
• utilizzare il rilevamento del fronte dove appropriato
• allungare l'impulso nella logica
• riprogettare la sequenza per evitare la dipendenza da un transitorio stretto
• documentare quando sarebbero necessarie funzionalità hardware in un controllore reale

#### Passaggio 6: Rieseguire e verificare

Convalida che la logica rivista catturi l'evento nelle condizioni definite e non crei falsi positivi o persistenza non sicura.

Una galleria di screenshot dimostra che il software è stato aperto. Non dimostra il giudizio ingegneristico. Se uno studente vuole dimostrare una reale comprensione del controllo, l'artefatto dovrebbe mostrare ragionamento, gestione dei guasti e disciplina nella revisione.

Utilizza questa struttura:

Dichiara esattamente cosa significa comportamento corretto. Esempio: "Un impulso di rilevamento prodotto da 10 ms deve essere catturato e mantenuto in modo che la sequenza di scarto venga eseguita una volta e una sola volta."

Documenta il guasto dipendente dalla scansione. Esempio: "L'impulso è stato perso quando il tempo di scansione ha superato la larghezza dell'impulso."

1. Descrizione del sistema Definisci la macchina o il segmento di processo, l'obiettivo di controllo e gli I/O rilevanti.
2. Definizione operativa del comportamento corretto
3. Logica ladder e stato dell'apparecchiatura simulata Mostra i rung rilevanti, i tag e il corrispondente comportamento della macchina simulata.
4. Il caso di guasto iniettato
5. La revisione effettuata Spiega cosa è cambiato nella logica e perché.
6. Lezioni apprese Riassumi il principio di controllo, come la temporizzazione della tabella immagine, il comportamento di sovrascrittura o perché la cattura dell'impulso richiede una progettazione esplicita.

Questo è il tipo di prova che un revisore può interrogare. È anche il tipo che tende a reggere meglio in una revisione tecnica rispetto al solo screenshot.

La simulazione del ciclo di scansione è preziosa perché rende osservabile il comportamento invisibile del controllore. I suoi limiti contano altrettanto.

Una dichiarazione delimitata di ciò che la simulazione può e non può fare

La simulazione può aiutare i tecnici a:

• comprendere l'esecuzione deterministica
• testare la logica di sequenza
• osservare i guasti legati alla temporizzazione
• provare la risoluzione dei problemi
• confrontare il comportamento dell'apparecchiatura previsto e simulato

La simulazione non può da sola:

• certificare la competenza del sito
• sostituire la convalida specifica dell'hardware
• stabilire la conformità alla sicurezza funzionale
• dimostrare il comportamento finale della temporizzazione del fieldbus
• sostituire FAT, SAT, controlli di loop o messa in servizio dal vivo

Questo confine non è una debolezza. È parte di ciò che mantiene credibile lo strumento.

La formazione basata sulla simulazione e i modelli digitali sono ben consolidati nell'ingegneria industriale, specialmente dove la sperimentazione diretta su asset dal vivo è costosa o non sicura. La letteratura generalmente supporta la simulazione come un modo per migliorare la comprensione del comportamento dinamico, della risposta ai guasti e della preparazione dell'operatore o del tecnico, sottolineando al contempo che la fedeltà del modello e la progettazione dell'attività determinano l'utilità.

Standard rilevanti e basi tecniche

• IEC 61131-3 definisce i quadri dei linguaggi di programmazione PLC e i concetti di esecuzione rilevanti per il comportamento della logica ladder (IEC, 2013).
• IEC 61508 stabilisce il quadro più ampio della sicurezza funzionale e ribadisce che le dichiarazioni di sicurezza richiedono prove rigorose del ciclo di vita, non solo la fiducia informale nella simulazione (IEC, 2010).
• exida e la relativa guida alla sicurezza funzionale enfatizzano la verifica, la convalida e il rigore del ciclo di vita nel lavoro di automazione legato alla sicurezza.
• La ricerca nella simulazione industriale, nei gemelli digitali e negli ambienti di formazione ha mostrato valore nella prova dei guasti, nella preparazione alla messa in servizio e nella comprensione umana dei sistemi dinamici, in particolare quando la simulazione è legata al comportamento osservabile del processo piuttosto che alla sola istruzione astratta.

La conclusione attenta è questa: la simulazione è più forte quando viene utilizzata per esporre comportamenti, testare ipotesi e migliorare il giudizio pre-implementazione. È più debole quando viene trattata come una scorciatoia rispetto alle prove ingegneristiche.

L'alfabetizzazione al ciclo di scansione è importante perché il controllo deterministico non è intuitivo per le persone formate su software guidato da eventi o esempi ladder statici. Un PLC non nota tutto nel momento in cui accade. Campiona, risolve, scrive e ripete.

Ecco perché OLLA Lab ha un posto legittimo nel flusso di lavoro. Offre ai tecnici un ambiente delimitato per osservare l'ordine di scansione, ispezionare lo stato degli I/O, iniettare guasti e rivedere la logica prima che quegli stessi errori raggiungano un processo dal vivo. Non si tratta di far sembrare impressionante la simulazione. Si tratta di rendere visibile il fallimento mentre il costo dell'errore è ancora tollerabile.

In termini pratici, questo è il passaggio dalla sintassi alla manutenibilità.

- IEC 61131-3: Programmable controllers — Part 3 - IEC 61508 functional safety standard overview - NIST Smart Manufacturing Profile - IEEE Access: Digital twin enabling technologies (DOI)

Ampergon Vallis Lab è il team di ricerca e sviluppo dedicato all'automazione industriale, focalizzato sulla creazione di strumenti di simulazione e metodologie di formazione per ingegneri di controllo.

Questo articolo è stato revisionato dal team tecnico di Ampergon Vallis per garantire l'accuratezza dei concetti relativi alla scansione PLC e alla conformità con gli standard IEC 61131-3.