Come programmare la logica a macchina a stati in un PLC per un motore trifase

Per programmare la logica a macchina a stati in un PLC, i tecnici dividono la sequenza di una macchina in stati mutuamente esclusivi, effettuando le transizioni tra di essi in modo esplicito. Per un motore trifase, ciò significa solitamente utilizzare stati basati su numeri interi come Off, Avvio, In marcia, Arresto e Guasto, che sono più facili da convalidare, risolvere e rendere robusti rispetto alla logica a autoritenuta annidata.

La logica a autoritenuta annidata non è "sufficientemente buona" solo perché funziona al primo test. Nel controllo sequenziale, la logica booleana che appare ordinata su uno schermo statico può comunque generare condizioni di race condition, percorsi di ripristino ambigui e comportamenti dipendenti dal ciclo di scansione quando gli ingressi oscillano o si verificano guasti a metà sequenza.

Durante i test interni del preset per motore trifase di Ampergon Vallis in OLLA Lab, la sostituzione dei contatti di autoritenuta annidati con una macchina a stati finiti esplicita basata su numeri interi ha ridotto gli eventi di guasto per race condition osservati dell'87% durante le prove di arresto anomalo simulate [Metodologia: n=30 cicli di simulazione della stessa attività su motore trifase, comparatore di base con autoritenuta annidata, finestra di test febbraio-marzo 2026]. Ciò supporta un'affermazione limitata su un preset di formazione interno sotto iniezione di guasti simulata. Non stabilisce un tasso universale di riduzione dei difetti per tutte le architetture PLC, impianti o applicazioni motoristiche.

Questa distinzione è importante. I fallimenti durante la messa in servizio nascono solitamente in condizioni limite, non nel percorso ideale.

La logica a macchina a stati finiti è superiore per il controllo sequenziale perché rende il comportamento della macchina esplicito, mutuamente esclusivo e deterministico. Una FSM (Finite State Machine) costruita correttamente consente al PLC di valutare le regole per lo stato corrente e di effettuare la transizione solo quando vengono soddisfatte le condizioni definite.

I rung a autoritenuta annidati fanno l'opposto. Spesso distribuiscono la memoria della sequenza su più bit, permissivi, latch e interblocchi che interagiscono indirettamente. Il risultato è una logica che può funzionare, ma solo finché il timing, la perdita di feedback o un arresto anomalo non espongono l'accoppiamento nascosto. La sintassi non è la stessa cosa della manutenibilità.

La norma IEC 61131-3 non impone un modello sequenziale universale, ma il suo modello di organizzazione del programma supporta fortemente una logica di controllo strutturata, leggibile e manutenibile per il sequenziamento basato su stati nelle applicazioni PLC (IEC, 2013). In pratica, le FSM sono diventate un'architettura comune per le sequenze macchina perché sono più facili da analizzare, testare e ripristinare dopo i guasti.

Una definizione operativa utile è la seguente:

- Macchina a stati finiti in logica ladder: un'architettura di controllo in cui una variabile di stato rappresenta l'attuale modalità della macchina, un solo stato valido è attivo alla volta e le transizioni avvengono tramite condizioni esplicite che assegnano lo stato successivo.

Quest'ultima clausola è il punto fondamentale. Se la transizione non è esplicita, la macchina si affida a effetti collaterali.

Logica "a cipolla" vs Architettura a macchina a stati

| Fattore ingegneristico | Autoritenuta annidata / "Logica a cipolla" | Macchina a stati finiti | |---|---|---| | Memoria di sequenza attiva | Distribuita tra bit e latch | Centralizzata in una variabile di stato | | Comportamento del ciclo di scansione | Può diventare sensibile all'ordine e ambigua | Deterministico quando le transizioni sono esplicite | | Ripristino guasti | Spesso dedotto da diverse condizioni | Stato di guasto esplicito, es. `99` | | Risoluzione dei problemi | Tracciare molti bit interagenti | Leggere prima l'intero dello stato corrente | | Espansione della sequenza | Fragile man mano che i rami crescono | Più facile inserire stati intermedi | | Convalida in simulazione | Più difficile isolare il percorso di errore | Test chiaro transizione per transizione |

I tecnici di controllo senior rifiutano la logica a cipolla per lo stesso motivo per cui rifiutano il cablaggio di campo non etichettato: il sistema potrebbe ancora funzionare, ma nessuno dovrebbe dover indovinare il perché.

Una sequenza per motore trifase richiede più di un semplice bit di On e Off, poiché le apparecchiature reali presentano comportamenti di transizione, tempi di feedback e gestione dei guasti. Anche un semplice avviatore motore richiede solitamente un trattamento esplicito di permissivi, conferma di avvio, comportamento di arresto e ripristino dopo un intervento.

Una FSM pratica per un motore trifase utilizza comunemente questi stati:

1. Stato 0 — Off / Pronto Il motore è diseccitato. I permissivi richiesti sono sani. La sequenza è in attesa di un comando di avvio valido.
2. Stato 10 — Avvio Il comando di avvio è stato emesso. La logica è in attesa del feedback previsto, come il contatto ausiliario, lo stato di marcia, la conferma di velocità o una finestra di avvio temporizzata.
3. Stato 20 — In marcia Il motore è in funzionamento a regime. La logica continua a monitorare i comandi di arresto, i sovraccarichi, la perdita di permissivi e feedback anomali.
4. Stato 30 — Arresto È stato avviato un comando di arresto o uno spegnimento controllato. La logica attende la conferma di diseccitazione, il feedback di velocità zero o il completamento del timeout.
5. Stato 99 — Guasto Si è verificato un intervento, un feedback fallito, un sovraccarico o una condizione di sequenza non valida. Le uscite vengono portate alla risposta sicura definita e la logica di reset viene gestita esplicitamente.

Utilizzare incrementi di 10 è un'abitudine ingegneristica pratica perché lascia spazio per l'inserimento successivo di stati come `15 = Verifica avvio` o `25 = Conferma arresto per inerzia` senza dover rinumerare l'intera sequenza.

Perché gli stati di transizione sono importanti nel controllo motore reale

Gli stati di transizione esistono perché i motori interagiscono con la realtà elettrica e meccanica, non solo con i simboli ladder. A seconda dell'applicazione, la sequenza di controllo potrebbe dover tenere conto di:

• tempo di chiusura del contattore
• tempi di trasferimento stella-triangolo
• accelerazione e decelerazione del VFD
• feedback di prova dai contatti ausiliari
• perdita di permissivi durante il funzionamento
• interventi del relè di sovraccarico
• interblocchi di processo a valle
• conferma di velocità zero o arresto

È qui che "pronto per la simulazione" necessita di una definizione precisa.

- Pronto per la simulazione: in grado di dimostrare, osservare, diagnosticare e rendere robusta la logica di controllo contro il comportamento realistico del processo prima che raggiunga un processo reale.

Ciò significa molto più che scrivere un rung che compila. Significa convalidare se lo stato ladder, lo stato I/O e lo stato dell'apparecchiatura simulata rimangono coerenti in condizioni normali e anomale.

Una FSM basata su ladder si costruisce leggendo lo stato corrente con un comparatore e scrivendo lo stato successivo con un comando di movimento (MOV) esplicito. In OLLA Lab, questo lavoro avviene nell'editor ladder, nel pannello delle variabili e nella modalità di simulazione.

OLLA Lab deve essere inteso qui come un ambiente di convalida e prova delimitato. È utile perché consente ai tecnici di esercitarsi in comportamenti di messa in servizio ad alto rischio, come la convalida della logica, l'osservazione degli I/O, l'iniezione di guasti e la revisione, senza utilizzare apparecchiature reali come ausilio didattico.

### Passaggio 1: Definire l'intero di stato

Creare un tag come:

- `Motor_State` : `INT`

Questo intero è l'unica fonte di verità per lo stato attuale della sequenza della macchina.

I tag di accompagnamento consigliati includono:

• `Start_PB`
• `Stop_PB`
• `OL_Trip`
• `Aux_Run_Proof`
• `Reset_PB`
• `Motor_Output`
• `Start_Timer.DN`
• `Stop_Timer.DN`

### Passaggio 2: Costruire la transizione da Off ad Avvio

La prima transizione solitamente sposta il motore dallo stato di pronto allo stato di avvio quando sono presenti i permissivi e una richiesta di avvio.

Esempio di concetto logico:

• Se `Motor_State = 0`
• e `Start_PB = TRUE`
• e nessun guasto è attivo
• e i permissivi richiesti sono sani
• allora `MOV 10` in `Motor_State`

Questo è il pattern di base:

• `EQU(Motor_State, 0)`
• `XIC(Start_PB)`
• `XIO(OL_Trip)`
• `XIC(Permissive_OK)`
• `MOV(10, Motor_State)`

### Passaggio 3: Costruire la transizione da Avvio a In marcia

Lo stato di avvio dovrebbe confermare che il motore abbia effettivamente raggiunto la condizione prevista. Tale conferma può essere un contatto ausiliario, un feedback di marcia, una prova di flusso, una prova di rotazione o una condizione di temporizzazione a seconda dell'applicazione.

Esempio di concetto logico:

• Se `Motor_State = 10`
• e `Aux_Run_Proof = TRUE`
• allora `MOV 20` in `Motor_State`

Se la prova non viene ricevuta entro il tempo consentito, passare invece allo stato di guasto.

• Se `Motor_State = 10`
• e `Start_Timer.DN = TRUE`
• e `Aux_Run_Proof = FALSE`
• allora `MOV 99` in `Motor_State`

### Passaggio 4: Costruire la transizione da In marcia ad Arresto

Lo stato di marcia dovrebbe monitorare sia gli arresti comandati che le condizioni anomale.

Esempio di concetto logico:

• Se `Motor_State = 20`
• e `Stop_PB = TRUE`
• allora `MOV 30` in `Motor_State`

Includere anche la gestione dell'intervento:

• Se `Motor_State = 20`
• e `OL_Trip = TRUE`
• allora `MOV 99` in `Motor_State`

### Passaggio 5: Costruire la transizione da Arresto a Off

Lo stato di arresto dovrebbe attendere che il motore raggiunga la condizione di arresto prevista.

Esempio di concetto logico:

• Se `Motor_State = 30`
• e la conferma di arresto è vera
• allora `MOV 0` in `Motor_State`

Laddove non esiste una prova fisica di arresto, è possibile utilizzare un timer delimitato, ma questa dovrebbe essere una scelta progettuale consapevole piuttosto che un'ipotesi spacciata per certezza.

### Passaggio 6: Costruire lo stato di guasto esplicito

Lo stato di guasto dovrebbe diseccitare le uscite e richiedere un percorso di ripristino definito. In molte applicazioni, ciò significa nessun riavvio automatico dopo un sovraccarico o una prova fallita, a meno che la filosofia di controllo non lo permetta esplicitamente.

Esempio di concetto logico:

• Se `Motor_State = 99`
• forzare `Motor_Output = FALSE`
• richiedere `Reset_PB = TRUE`
• richiedere il guasto rimosso
• allora `MOV 0` in `Motor_State`

Riepilogo del pattern ladder

Un pattern di rung FSM pulito in OLLA Lab segue solitamente questa sequenza:

• `EQU` per identificare lo stato corrente
• una o più condizioni `XIC` / `XIO` per convalidare la transizione
• `MOV` per scrivere lo stato successivo

Esempio di pattern ladder:

• `EQU Motor_State 10` e `XIC Aux_Run_Proof` allora `MOV 20 -> Motor_State`
• `EQU Motor_State 10` e `XIO Aux_Run_Proof` e `XIC Start_Timer.DN` allora `MOV 99 -> Motor_State`

Le uscite dovrebbero essere derivate dallo stato attivo, non utilizzate come memoria nascosta per la sequenza. Questa distinzione è facile da perdere e costosa da ignorare.

Un pattern comune è:

• eccitare `Motor_Output` quando `Motor_State = 10` o `Motor_State = 20`
• diseccitarla in `0`, `30` e `99` a meno che la filosofia di arresto non richieda un mantenimento controllato

Ciò fornisce una relazione diretta tra l'intento della sequenza e l'uscita comandata. Rende anche la simulazione e la risoluzione dei problemi più pulite, perché l'uscita diventa una conseguenza dello stato, non una seconda macchina a stati non documentata.

Esempio di logica di uscita

• Se `Motor_State = 10` O `Motor_State = 20`
• allora `Motor_Output = TRUE`

• Se `Motor_State = 0`, `30` o `99`
• allora `Motor_Output = FALSE`

Per sistemi motore più complessi, come avviatori reversibili, transizioni stella-triangolo o configurazioni di bypass VFD, ogni comando dell'attuatore dovrebbe comunque rimanere derivato dallo stato e interbloccato esplicitamente.

Il guasto FSM più comune è uno stato bloccato. Uno stato bloccato si verifica quando la macchina entra in uno stato valido ma non soddisfa mai le condizioni necessarie per uscirne.

Ecco perché la simulazione è importante. Ti permette di osservare la causalità prima che l'hardware, la meccanica e la pressione delle scadenze complichino la diagnosi.

In OLLA Lab, la risoluzione dei problemi di una FSM dovrebbe seguire una sequenza semplice:

1. Leggere prima l'intero dello stato corrente Controllare `Motor_State` nel pannello delle variabili. Non iniziare cercando di indovinare quale rung sembri sbagliato.
2. Verificare la condizione di transizione prevista Se il motore è nello `Stato 10`, confermare se `Aux_Run_Proof` cambia effettivamente, se il timer è in funzione e se i permissivi rimangono veri.
3. Controllare lo stato ladder rispetto allo stato dell'apparecchiatura simulata Il ladder potrebbe comandare un'uscita motore, ma l'apparecchiatura simulata potrebbe ancora mostrare una prova fallita, una risposta ritardata o un comportamento guasto.
4. Iniettare deliberatamente un guasto Attivare `OL_Trip` durante lo `Stato 20` e confermare che la sequenza transiti immediatamente allo `Stato 99`.
5. Verificare la risposta sicura Confermare che le uscite del motore si diseccitino come richiesto e che la macchina non possa riprendere il funzionamento finché non vengono soddisfatte le condizioni di ripristino.

È qui che OLLA Lab diventa operativamente utile. Consente allo studente di confrontare l'intero dello stato di controllo, le condizioni I/O e il comportamento dell'apparecchiatura in un unico posto, rispecchiando il lavoro che i tecnici di messa in servizio svolgono sotto pressione.

Un test pratico di iniezione guasti

Utilizzare questo caso di test delimitato:

• Iniziare dallo `Stato 0`
• Emettere un comando di avvio valido
• Confermare la transizione allo `Stato 10`
• Confermare il feedback di prova e la transizione allo `Stato 20`
• Forzare `OL_Trip = TRUE`
• Verificare la transizione immediata allo `Stato 99`
• Verificare `Motor_Output = FALSE`
• Rimuovere il guasto ed emettere il reset
• Verificare la transizione di ritorno allo `Stato 0`

Se uno di questi passaggi fallisce, il problema non è più astratto. Ora hai un caso di difetto riproducibile.

La convalida del gemello digitale, in questo articolo, significa testare la logica ladder contro un modello di macchina simulato realistico, in modo che il comportamento della sequenza possa essere osservato sia in condizioni normali che anomale prima della distribuzione. Non significa che la simulazione sia un sostituto legale per l'accettazione in sito, la verifica della sicurezza funzionale o la firma della messa in servizio.

Quel confine è importante. Un gemello digitale può migliorare la convalida della sequenza, il realismo della formazione e la prova dei guasti, ma non elimina la necessità di revisioni specifiche dell'impianto, verifica dei dispositivi e attività formali del ciclo di vita della sicurezza secondo standard come la IEC 61508 ove applicabile (IEC, 2010; exida, 2024).

In OLLA Lab, la convalida del gemello digitale è operativamente utile quando il tecnico può fare tutto quanto segue:

• confrontare lo stato ladder con il comportamento dell'apparecchiatura simulata
• osservare se le transizioni I/O avvengono come previsto
• iniettare guasti e verificare la risposta allo stato sicuro
• rivedere la logica dopo il fallimento
• rieseguire lo stesso scenario per confermare la correzione

Questa è la differenza tra pratica di sintassi e prova di messa in servizio.

Una galleria di screenshot non è una prova ingegneristica. È solo una registrazione parziale.

Se vuoi dimostrare una reale competenza di controllo, costruisci un corpo di prove compatto utilizzando questa struttura:

1. Descrizione del sistema Definire la macchina o l'unità di processo, il suo obiettivo e gli I/O rilevanti.
2. Definizione operativa del comportamento corretto Affermare cosa deve fare la sequenza, quale feedback deve ricevere e cosa costituisce una risposta sicura valida.
3. Logica ladder e stato dell'apparecchiatura simulata Mostrare la logica di stato, la logica di uscita e il corrispondente comportamento simulato.
4. Il caso di guasto iniettato Documentare la condizione anomala introdotta, come l'intervento per sovraccarico, la prova di avvio fallita o la perdita di permissivi.
5. La revisione effettuata Spiegare cosa è cambiato nella logica e perché.
6. Lezioni apprese Registrare ciò che il fallimento ha rivelato sulla progettazione della sequenza, sulle ipotesi o sugli interblocchi mancanti.

Questa struttura è più credibile perché mostra ragionamento, gestione dei guasti e disciplina di revisione. Un rung pulito da solo non mostra se la logica sopravvive a condizioni realistiche.

Il controllo sequenziale strutturato, la convalida basata sulla simulazione e i test consapevoli dei guasti sono ben allineati con la pratica ingegneristica consolidata, sebbene l'implementazione esatta vari in base al settore e alla classe di rischio.

Le basi rilevanti includono:

• IEC 61131-3 per i linguaggi di programmazione PLC e i principi di implementazione del controllo strutturato (IEC, 2013)
• IEC 61508 per il pensiero sul ciclo di vita della sicurezza funzionale, specialmente dove contano le condizioni anomale e il comportamento allo stato sicuro (IEC, 2010)
• Guida exida sulla disciplina del ciclo di vita della sicurezza, sul rigore della verifica e sulla differenza tra intento logico e comportamento convalidato nei sistemi industriali (exida, 2024)
• letteratura di ricerca sulla simulazione industriale, gemelli digitali e ambienti di formazione immersivi che dimostrano che gli ambienti simulati possono migliorare la comprensione procedurale, la prova dei guasti e l'apprendimento a livello di sistema quando sono legati alle prestazioni osservabili dell'attività piuttosto che alla sola novità (Tao et al., 2019; Jones et al., 2023; Villalonga et al., 2021)

La conclusione attenta non è che la simulazione sostituisca il lavoro in sito. È che la simulazione può spostare l'apprendimento costoso "a sinistra", dove gli errori sono più economici e visibili.

Questo articolo è stato redatto dal team tecnico di OLLA Lab, specializzato in metodologie di controllo industriale, simulazione di sistemi PLC e best practice per la messa in servizio.

Le metodologie descritte si basano sugli standard IEC 61131-3 e IEC 61508. I dati sulle prestazioni citati derivano da test interni condotti su preset di formazione Ampergon Vallis in ambiente OLLA Lab.

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