Come sostituire la fragile \"onion logic\" con macchine a stati PLC

Per sostituire la fragile "onion logic" nei programmi PLC, i progettisti dovrebbero utilizzare macchine a stati finiti esplicite. Un'architettura a macchina a stati può ridurre l'ambiguità nell'ordine di scansione, isolare la gestione dei guasti e rendere osservabile in simulazione il test delle condizioni anomale prima che la logica raggiunga un processo reale.

Un'idea errata comune è che la logica ladder diventi "avanzata" quando diventa densa. In pratica, la densità è spesso solo ambiguità che indossa un elmetto. Le macchine non falliscono perché un rung sembra sofisticato; falliscono perché la sequenza non era deterministica quando un input reale è cambiato nel momento sbagliato.

Durante un recente benchmark interno di 200 esercizi di sequenza di miscelazione inviati dagli utenti in OLLA Lab, l'82% dei programmi con "onion logic" profondamente annidata è entrato in un blocco di sequenza irrecuperabile quando sottoposto a un evento di perdita intermittente del sensore di 100 ms, mentre le versioni refattorizzate a stati espliciti si sono ripristinate in modo deterministico nel 100% degli stessi test di scenario [Metodologia: n=200 compiti di sequenza di miscelazione inviati, comparatore = implementazione originale a latch annidati contro implementazione refattorizzata a stati espliciti, finestra temporale = ciclo di revisione interna di Ampergon Vallis Lab completato nel Q1 2026]. Questo benchmark interno supporta un punto architettonico ristretto: i modelli a stati espliciti sono risultati più resilienti ai guasti nelle condizioni testate. Non supporta affermazioni generali su tutto il codice PLC, tutte le industrie o la competenza degli operatori.

La distinzione pratica è semplice: la sintassi non è dispiegabilità. Un programma che funziona sul percorso ideale ma si blocca su un permissivo intermittente non è pronto per la messa in servizio, per quanto ordinati possano sembrare i rung.

La "onion logic" (logica a cipolla) è un anti-pattern della logica ladder in cui il comportamento della macchina è controllato attraverso strati di booleani interdipendenti, latch sparsi e permissivi annidati il cui percorso di esecuzione combinato è difficile da comprendere in condizioni anomale.

Il nome è informale, ma la modalità di guasto è reale. Ogni nuova condizione si avvolge attorno alla precedente finché la sequenza non diventa dipendente da interazioni nascoste tra l'ordine dei rung, lo storico dei latch e gli input transitori. Di solito funziona durante le dimostrazioni. La messa in servizio è meno cortese.

I 3 sintomi della "onion logic"

L'avanzamento della sequenza dipende da molteplici istruzioni `(S)/(R)` o `(OTL)/(OTU)` distribuite su molti rung, spesso senza una singola fonte autorevole dello stato della macchina.

• Latch interdipendenti

Il comportamento del programma cambia a seconda dell'ordine dei rung, del timing di una singola scansione o del fatto che un permissivo cada prima o dopo che venga valutata una condizione di reset del latch.

• Vulnerabilità del ciclo di scansione

La sequenza viene eseguita correttamente quando ogni sensore si comporta in modo pulito, ma si blocca, presenta latch parziali o richiede un reset manuale dopo un'interruzione a metà ciclo.

• Bias del percorso ideale (Happy-path bias)

Perché la "onion logic" diventa fragile

La "onion logic" aumenta la complessità ciclomatica effettiva. In termini semplici, il numero di possibili percorsi di esecuzione cresce più velocemente di quanto un ingegnere junior possa tracciare in modo affidabile in condizioni di guasto, specialmente quando diversi booleani possono rimanere veri dalle scansioni precedenti.

Ciò è importante perché la risoluzione dei problemi PLC non avviene nel vuoto. Avviene mentre un nastro trasportatore è fermo, una pompa non è disponibile o una fase di lotto è in attesa di un permissivo che "dovrebbe essere vero". "Dovrebbe" non è un metodo diagnostico.

Le macchine a stati esplicite offrono un miglior ripristino dai guasti perché rendono l'intento della macchina singolare, osservabile e deterministico. In ogni momento, la macchina occupa uno stato definito e le transizioni avvengono solo quando vengono soddisfatte condizioni esplicite.

Questa è la differenza architettonica che conta. La "onion logic" chiede: "Quale insieme di bit implica attualmente dove mi trovo?". Una macchina a stati chiede: "In quale stato mi trovo e quale condizione permette il prossimo?". La seconda domanda è molto più facile a cui rispondere alle 3 del mattino.

### Definizione operativa: cos'è una macchina a stati esplicita nella logica ladder?

Una macchina a stati esplicita è un'architettura di controllo in cui:

• lo stato della sequenza di una macchina è rappresentato da una singola variabile di stato autorevole, spesso un intero;
• ogni stato è mutuamente esclusivo dagli altri;
• le transizioni sono esplicitamente definite da condizioni osservabili;
• le condizioni anomale indirizzano la macchina verso uno stato definito di guasto o attesa;
• le uscite fisiche sono derivate dallo stato attivo anziché sparse in rung di sequenza non correlati.

Un esempio semplice potrebbe utilizzare:

• `0 = Inattivo`
• `10 = Avvio`
• `20 = In funzione`
• `30 = Arresto`
• `99 = Guasto`

Questo approccio si allinea con i principi di strutturazione del software stabiliti dallo standard IEC 61131-3, che supporta l'organizzazione strutturata del programma, un comportamento di esecuzione chiaro e una logica di controllo manutenibile. Lo standard non prescrive un modello di sequenza universale per ogni macchina, ma la preferenza per un'architettura esplicita e leggibile non è controversa.

Stato esplicito vs. "onion logic"

| Aspetto ingegneristico | Macchina a stati esplicita | "Onion logic" | |---|---|---| | Rappresentazione dello stato | Una variabile di stato autorevole, tipicamente basata su interi | Molti booleani e latch sovrapposti | | Visibilità della sequenza | La fase attuale della macchina è direttamente osservabile | La posizione nella sequenza deve essere dedotta | | Gestione dei guasti | Salto esplicito a uno stato definito di guasto o attesa | Il ripristino dipende dallo sblocco delle giuste condizioni | | Mappatura delle uscite | Uscite derivate in una routine dedicata dallo stato attivo | Uscite spesso sparse tra i rung di sequenza | | Risoluzione problemi | Chiedere: "Perché lo stato X non è passato a Y?" | Chiedere: "Quale bit non è riuscito a impostarsi o resettarsi?" | | Sensibilità all'ordine di scansione | Ridotta quando le transizioni sono partizionate in modo pulito | Spesso altamente sensibile all'ordine dei rung | | Manutenibilità | Più facile da revisionare, testare e revisionare | Degrada rapidamente man mano che le condizioni si accumulano |

La "onion logic" fallisce con il comportamento reale del ciclo di scansione perché i PLC non valutano l'intento; valutano le istruzioni in ordine, una scansione alla volta, utilizzando lo stato attuale della memoria e degli input.

Sembra ovvio, ma molti bug di sequenza sono solo una tardiva comprensione di questo fatto. Un sensore può cadere per 50 ms. Un feedback può arrivare una scansione dopo il previsto. Un latch può rimanere impostato perché il rung di reset non è mai stato reso vero sotto l'esatta sequenza di eventi che si è verificata.

Meccanismi di guasto tipici

Un bit di transizione si imposta e si resetta nella logica adiacente, lasciando la logica di sequenza a valle in una condizione indeterminata.

• Gare di una singola scansione

Uno step di sequenza rimane vero perché il percorso di reset dipende da un permissivo che è scomparso durante il guasto.

• Persistenza della memoria latchata

Spostare un rung per leggibilità cambia il comportamento perché la logica faceva affidamento sull'ordine di esecuzione implicito anziché su transizioni di stato esplicite.

• Dipendenza dall'ordine dei rung

Un segnale di campo rumoroso o brevemente perso fa sì che la macchina avanzi parzialmente, per poi perdere le condizioni necessarie per continuare o per ripristinarsi.

• Rimbalzo del sensore o perdita intermittente

Questi non sono casi limite esotici. Sono normali eventi di impianto. L'hardware non ha alcun obbligo di assecondare il tuo design di sequenza.

Si costruisce una macchina a stati finiti nella logica ladder separando la logica di transizione di stato dalla logica di azione delle uscite. La routine di transizione decide quando la macchina cambia stato. La routine di uscita decide cosa fa la macchina mentre si trova in quello stato.

Questa separazione è la disciplina fondamentale. Se transizioni e uscite sono mescolate ovunque, l'architettura torna verso la "onion logic".

### Step 1: Definire gli stati della macchina

Inizia assegnando valori di stato mutuamente esclusivi.

• `0 = Inattivo`
• `10 = Richiesta_Avvio`
• `20 = Avvio`
• `30 = In funzione`
• `40 = Arresto`
• `99 = Guasto`

Usa una numerazione che lasci spazio per inserimenti futuri. Gli ingegneri che numerano ogni stato 1, 2, 3 di solito incontrano lo stato 2.5 prima o poi.

### Step 2: Definire le condizioni di transizione

Ogni transizione dovrebbe rispondere a una domanda specifica:

• Quale condizione permette l'ingresso nello stato successivo?
• Quale condizione blocca l'avanzamento?
• Quale condizione forza uno stato di guasto o attesa?
• Quale condizione permette il reset o il ripristino?

Le transizioni dovrebbero essere esplicite e testabili. Evita dipendenze nascoste da effetti collaterali di rung non correlati.

### Step 3: Scrivere prima la logica di transizione

Di seguito un esempio compatto in stile ladder per le transizioni di stato:

Linguaggio: Ladder Diagram - Logica di transizione di stato

Rung 1: Inattivo (0) -> Avvio (10) EQU(Stato_Macchina, 0) --- XIC(PB_Avvio) --- XIC(Sistema_Pronto) --- MOV(10, Stato_Macchina)

Rung 2: Avvio (10) -> In funzione (20) EQU(Stato_Macchina, 10) --- XIC(Feedback_Motore_Marcia) --- MOV(20, Stato_Macchina)

Rung 3: Qualsiasi stato attivo -> Guasto (99) su intervento NEQ(Stato_Macchina, 0) --- XIC(Intervento_Attivo) --- MOV(99, Stato_Macchina)

Rung 4: Guasto (99) -> Inattivo (0) dopo reset e condizioni di sicurezza EQU(Stato_Macchina, 99) --- XIC(PB_Reset) --- XIO(Intervento_Attivo) --- XIC(Sistema_Pronto) --- MOV(0, Stato_Macchina)

Il punto importante non è l'esatta sintassi. Il punto importante è che lo stato attuale e la condizione di transizione siano visibili, singolari e revisionabili.

### Step 4: Mappare le uscite dallo stato, non da frammenti di sequenza

Una routine separata dovrebbe derivare le uscite dallo stato attivo.

Ad esempio:

• Se `Stato_Macchina = 20`, comando `Motore_Marcia = 1`
• Se `Stato_Macchina = 40`, comando `Motore_Marcia = 0`
• Se `Stato_Macchina = 99`, diseccitare le uscite non sicure e asserire l'indicazione di guasto

Ciò riduce le bobine di uscita sparse e rende il comportamento della macchina più facile da controllare.

### Step 5: Definire deliberatamente il comportamento in caso di guasto

Uno stato di guasto non dovrebbe essere un vago contenitore di "qualcosa è andato storto". Dovrebbe definire:

• quali uscite si diseccitano,
• quali allarmi si attivano,
• se il riavvio è automatico o manuale,
• quali condizioni di reset sono richieste,
• e quali prove l'operatore o l'ingegnere possono osservare.

Il determinismo conta di più quando le cose vanno male. Il funzionamento normale maschera un'architettura debole.

"Pronto per la simulazione" significa che l'ingegnere può dimostrare, osservare, diagnosticare e rafforzare la logica di controllo contro un comportamento realistico del processo in un ambiente a rischio contenuto prima che tale logica raggiunga un processo reale.

Questa è una definizione operativa, non un complimento. Non significa "avere familiarità con la sintassi ladder", "pronto per la messa in servizio senza supervisione" o "automaticamente impiegabile". Significa che l'ingegnere può sottoporre una sequenza a condizioni anomale, ispezionare il comportamento risultante e revisionare la logica basandosi su prove.

Comportamenti osservabili di un ingegnere "pronto per la simulazione"

Un ingegnere pronto per la simulazione può:

• forzare e monitorare I/O discreti e analogici;
• confrontare il comportamento atteso della sequenza con la risposta osservata della macchina;
• iniettare un guasto, come la perdita intermittente di un sensore o un feedback mancante;
• verificare che la logica passi a uno stato sicuro e definito;
• revisionare i permissivi di transizione o la gestione dei guasti;
• rieseguire lo scenario e dimostrare un miglior comportamento deterministico.

Questa è la differenza tra scrivere codice e validare il comportamento di controllo. Il divario è costoso.

OLLA Lab simula i guasti di transizione di stato fornendo agli ingegneri un ambiente ladder basato su browser, controlli di simulazione, variabili e I/O visibili e gemelli digitali basati su scenari che consentono l'iniezione di guasti senza rischi per le apparecchiature reali.

È qui che il prodotto diventa operativamente utile. Il valore non sta nel fatto che disegna la logica ladder in un browser. Molti strumenti possono disegnare. Il valore sta nel fatto che la logica può essere esercitata contro il comportamento simulato dell'apparecchiatura e condizioni anomale in un ambiente contenuto.

Funzionalità rilevanti di OLLA Lab per la validazione di macchine a stati

Gli ingegneri possono costruire transizioni di stato utilizzando contatti, bobine, timer, contatori, comparatori, matematica, logica e istruzioni correlate ai PID.

• Editor di logica ladder basato sul web

La logica può essere eseguita, fermata e osservata senza hardware fisico.

• Modalità di simulazione

Tag, input, output, valori analogici e variabili di stato possono essere monitorati e regolati direttamente.

• Pannello delle variabili e visibilità I/O

La logica ladder può essere confrontata con il comportamento simulato dell'apparecchiatura in contesti realistici di macchina o processo.

• Simulazioni 3D / WebXR / VR

L'ingegnere può testare se la logica di sequenza produce il comportamento dell'apparecchiatura previsto prima di qualsiasi discussione sulla messa in servizio reale.

• Workflow di validazione del gemello digitale

Più di 50 preset nominati in produzione, acqua e acque reflue, HVAC, chimica, farmaceutica, magazzinaggio, alimenti e bevande e servizi pubblici forniscono sequenze, pericoli e interblocchi specifici per il contesto.

• Preset industriali basati su scenari

Un caso di test pratico in OLLA Lab

In uno scenario di blocco del nastro trasportatore, un ingegnere può:

Questo è un compito di prova credibile perché rispecchia una vera domanda di messa in servizio: cosa succede quando la macchina non riceve la sequenza di segnali puliti che l'autore originale aveva ipotizzato?

1. impostare `Stato_Macchina = 20` per rappresentare "In funzione";
2. osservare il nastro trasportatore del gemello digitale in funzione;
3. far cadere un input di permissivo o feedback a metà sequenza utilizzando il pannello delle variabili;
4. verificare se lo stato passa a `99 = Guasto` o si blocca in una condizione incoerente;
5. revisionare la logica di transizione;
6. rieseguire lo scenario per confermare il ripristino deterministico.

Gli ingegneri dovrebbero documentare le competenze sulle macchine a stati come un corpo compatto di prove ingegneristiche, non come una galleria di screenshot.

Uno screenshot prova che una schermata esisteva. Non prova che la logica fosse corretta, testata o revisionata dopo il guasto.

Struttura delle prove richiesta

Utilizza questa struttura in sei parti:

Dichiara cosa significa comportamento di successo in termini osservabili: condizioni di avvio, uscite, transizioni, allarmi, comportamento di arresto sicuro e requisiti di reset.

Identifica la condizione anomale introdotta: caduta del sensore, feedback fallito, escursione analogica, timeout, blocco, interruzione della catena di emergenza o simili.

Documenta l'esatta modifica logica: aggiunto timeout, revisionato permissivo, transizione di guasto esplicita, gestione del debounce, rimappatura delle uscite o condizione di reset.

1. Descrizione del sistema Definisci la macchina o il processo, il suo scopo e i confini della sua sequenza.
2. Definizione operativa di "corretto"
3. Logica ladder e stato dell'apparecchiatura simulata Mostra l'architettura degli stati, i tag chiave e la corrispondente risposta dell'apparecchiatura simulata.
4. Il caso di guasto iniettato
5. La revisione effettuata
6. Lezioni apprese Spiega cosa ha rivelato il guasto sull'architettura originale e perché la revisione ha migliorato il determinismo o la recuperabilità.

Questa struttura è utile perché rende il ragionamento ingegneristico ispezionabile. I datori di lavoro e i revisori senior non hanno bisogno di un portfolio di interfacce carine. Hanno bisogno di prove che tu possa riflettere sul fallimento.

L'architettura a stati espliciti è supportata indirettamente dai principi stabiliti di software di controllo e ingegneria della sicurezza, anche laddove gli standard non prescrivono un esatto modello ladder.

Standard rilevanti e basi tecniche

Supporta approcci di programmazione strutturata per il software di controllo industriale e una chiara organizzazione della logica, delle funzioni e del comportamento di esecuzione.

• IEC 61131-3

Enfatizza l'integrità sistematica, la risposta ai guasti e l'importanza di ridurre l'ambiguità di progettazione pericolosa nei sistemi relativi alla sicurezza.

• IEC 61508

Rafforzano la necessità di un comportamento deterministico, tracciabilità e gestione dei guasti testabile nella progettazione dei sistemi di controllo.

• Guida exida e pratica di sicurezza funzionale

La recente letteratura industriale supporta costantemente la simulazione come mezzo per validare il comportamento, ridurre il rischio di messa in servizio ed esporre i guasti di sequenza prima del dispiegamento, avvertendo al contempo che la qualità della simulazione dipende dalla fedeltà del modello e dal design del test.

• Letteratura su gemelli digitali e simulazione

La ricerca negli ambienti di formazione ingegneristica suggerisce che la simulazione interattiva può migliorare la comprensione procedurale e il riconoscimento dei guasti, in particolare quando gli studenti possono testare causa-effetto anziché leggere solo esempi statici.

• Letteratura sulla formazione immersiva e interattiva

La conclusione limitata è semplice: la simulazione non sostituisce l'esperienza sul campo, ma è un luogo difendibile per provare la logica di guasto che sarebbe insicura, costosa o impraticabile da testare su un processo reale.

Le macchine a stati non sono magiche. Possono ancora essere progettate male, essere troppo complicate o implementate senza sufficiente attenzione al comportamento dello stato sicuro, alla gestione delle modalità o al ripristino dell'operatore.

Errori comuni nelle macchine a stati

• troppi stati senza una gerarchia chiara;
• distinzione poco chiara tra modalità, stato e guasto;
• transizioni innescate da segnali rumorosi senza debounce o validazione;
• stati di guasto che non definiscono il comportamento delle uscite;
• percorsi di ripristino che consentono un riavvio non sicuro o non intenzionale;
• logica di uscita che reintroduce silenziosamente dipendenze sparse.

Una cattiva macchina a stati è comunque più facile da diagnosticare rispetto a una cattiva "onion logic", ma non è la stessa cosa che dire che è buona. L'architettura migliora le tue probabilità; non sospende la disciplina ingegneristica.

Il punto chiave pratico è che le macchine a stati esplicite sono solitamente l'architettura migliore quando contano la chiarezza della sequenza, il ripristino dai guasti e la visibilità della messa in servizio.

Se la macchina ha fasi multiple, interblocchi, condizioni anomale o requisiti di ripristino, un singolo modello di stato autorevole supererà generalmente la logica a latch stratificata in manutenibilità e diagnosticabilità. Ciò è particolarmente vero per gli ingegneri junior e intermedi che hanno bisogno di un'architettura su cui possano ragionare sotto pressione.

OLLA Lab si inserisce in questo workflow come ambiente di validazione limitato. Consente agli ingegneri di costruire logica ladder, osservare I/O, confrontare lo stato con il comportamento simulato dell'apparecchiatura, iniettare guasti e revisionare la sequenza prima che esista qualsiasi contesto di dispiegamento reale. Questo è un caso d'uso serio. Non servono fuochi d'artificio.

- Per un'analisi più approfondita del comportamento dei latch, rivedi "Seal-In" vs. "Latch": Perché gli ingegneri professionisti scelgono con cura. - Per vedere questa architettura applicata a un processo continuo, segui Step-by-Step Build: The Automated Mixer State Machine.

• Padroneggiare l'architettura degli stati è una competenza fondamentale nel nostro Ladder Logic Mastery Hub.
• Smetti di indovinare come la tua logica gestirà un guasto del sensore. Apri il Conveyor Jam Scenario in OLLA Lab.

- Su (Pillar Hub): Esplora la guida Pillar - Di lato: Articolo correlato 1 - Di lato: Articolo correlato 2 - Giù (Commerciale/CTA): Costruisci il tuo prossimo progetto in OLLA Lab

- IEC 61131-3 Programming Languages - Kritzinger et al. (2018) Digital twin in manufacturing - Tao et al. (2019) Digital twin in industry - IEC 61508 Functional Safety standard family