Come utilizzare l'IA per la programmazione PLC con le filosofie di controllo per Yaga

Un prompting efficace dell'IA per la programmazione PLC richiede filosofie di controllo strutturate, non richieste generiche. Quando gli ingegneri forniscono mappature I/O esplicite, permissivi, interblocchi, stati di sequenza e condizioni di guasto, Yaga può generare impalcature di logica ladder sostanzialmente più facili da convalidare all'interno dell'ambiente di simulazione di OLLA Lab.

L'IA non fallisce nel lavoro sui PLC perché è "scarsa nella programmazione". Fallisce perché la logica ladder non è solo generazione di codice; è un comportamento di controllo deterministico soggetto a vincoli, ordine di scansione e stati anomali. Questa distinzione viene spesso trascurata.

Durante una recente esercitazione beta interna dell'assistente Yaga di OLLA Lab, i prompt che includevano un dizionario dei tag, uno stato di sicurezza definito e almeno un interblocco esplicito hanno prodotto impalcature di primo passaggio utilizzabili per la simulazione in 22 casi su 24 (91,7%), mentre i prompt generici come "scrivi una sequenza per una pompa" hanno richiesto correzioni sostanziali in 17 casi su 24 (70,8%) prima di poter procedere con la simulazione. Metodologia: n=48 esecuzioni di prompt-task su esercizi relativi a pompe, miscelatori, nastri trasportatori e livelli di serbatoi; comparatore di base = prompt in linguaggio naturale generico rispetto a prompt basato su filosofia di controllo strutturata; finestra temporale = periodo beta interno, febbraio-marzo 2026. Ciò supporta un'unica conclusione limitata: la struttura del prompt influenza fortemente l'usabilità di primo passaggio nella simulazione. Non dimostra la dispiegabilità sul campo, la sufficienza della sicurezza o la prontezza per la produzione.

Nell'automazione, l'ingegneria dei prompt dovrebbe essere definita in modo ristretto: la traduzione sistematica di vincoli meccanici, mappatura I/O e interblocchi di sicurezza in parametri leggibili dalla macchina, affinché un agente IA possa generare impalcature sintatticamente corrette e testabili. Questo è uno strumento utile, non un sostituto del giudizio ingegneristico. OLLA Lab è importante qui come ciclo di convalida, non come autorizzazione automatica.

I modelli LLM generici falliscono nella logica ladder perché prevedono sequenze di token plausibili, mentre i PLC eseguono una logica di scansione deterministica basata su input e output con stato. Un modello linguistico vede la continuità del testo; un controllore vede l'ordine di valutazione, i bit di memoria, le condizioni di fronte (edge) e lo stato del dispositivo.

La logica ladder è anche spaziale. I rami paralleli, i percorsi di autoritenuta (seal-in), le catene di permissivi e gli stati mutuamente esclusivi trasmettono significato attraverso la struttura, non solo attraverso le parole. Un modello LLM generico tende a linearizzare tale struttura in testo e può perdere l'intento di esecuzione nel processo. Questo è uno dei motivi per cui una logica ladder generata dall'IA può sembrare competente pur comportandosi in modo errato.

Una seconda modalità di fallimento è la scarsa consapevolezza del ciclo di scansione. La logica PLC viene valutata ripetutamente e gli output possono essere scritti, resettati o sovrascritti all'interno della stessa scansione a seconda della struttura del programma. Senza vincoli espliciti, un LLM può generare:

• scritture duplicate sulla stessa bobina di output,
• comportamento "one-shot" mancante,
• condizioni di race condition tra modalità automatica e manuale,
• timer con condizioni di reset poco chiare,
• soglie analogiche senza banda morta (deadband) o gestione dei guasti,
• interblocchi che appaiono nei commenti ma non nella logica eseguibile.

Il risultato comune è noto ai professionisti: una logica che si legge bene ma che si comporta in modo errato non appena gli input cambiano. La sintassi è economica; il determinismo è più difficile.

Questa limitazione è ampiamente coerente con la letteratura sul ragionamento e sull'affidabilità del codice degli LLM. Le pubblicazioni nel campo del software e dei sistemi incorporati suggeriscono che la qualità dell'output degrada quando i compiti richiedono il tracciamento persistente dello stato, il ragionamento spaziale o l'esatta soddisfazione dei vincoli, piuttosto che il completamento fluido di pattern (Bubeck et al., 2023; Huang & Chang, 2023). La programmazione PLC è particolarmente implacabile su tutti e tre i fronti.

Un prompt IA di livello industriale è una specifica funzionale compatta. Deve comunicare al modello cos'è la macchina, cosa significa "sicuro", quali dispositivi esistono, quali condizioni devono essere vere prima che l'azione sia consentita e come gestire i guasti. Se il prompt non può supportare una revisione di base della Specifica di Progettazione Funzionale (FDS), è probabilmente troppo vago per una generazione affidabile della logica ladder.

In pratica, un buon prompt PLC si comporta meno come una query di ricerca e più come istruzioni per un ingegnere dei controlli junior. Gli ingegneri senior non dicono "fammi un programma per una pompa". Specificano il processo, i tag, la sequenza, i trip e lo stato di fallback previsto.

I 3 pilastri di un prompt di automazione

#### 1. Contesto e obiettivo

Definisci la macchina o l'unità di processo, l'obiettivo operativo e lo stato di sicurezza.

Includi:

• tipo di apparecchiatura,
• modalità operativa,
• obiettivo di avvio/arresto,
• condizione di arresto di sicurezza,
• aspettativa per lo stato anomalo.

Esempio:

• "Pompa di trasferimento singola per riempimento serbatoio giornaliero."
• "Lo stato di sicurezza è pompa spenta e valvola di uscita chiusa."
• "Se il trasmettitore di livello non è valido, inibire l'avvio automatico."

#### 2. I/O e dizionario dei tag

Definisci i tag in modo esplicito. L'IA ha prestazioni migliori quando la denominazione è univoca e tipizzata.

Includi:

• ingressi digitali,
• uscite digitali,
• ingressi analogici,
• uscite analogiche se rilevanti,
• bit di memoria interna,
• timer e contatori,
• bit di allarme o guasto.

Esempio:

• `DI_PB_Start`
• `DI_PB_Stop`
• `DI_EStop_OK`
• `AI_Tank_Level_Pct`
• `DO_Pump_Run`
• `M_Auto_Mode`
• `T_FillTimeout`

La disciplina nella denominazione non è estetica. È la differenza tra una logica tracciabile e un costo di debug elevato.

#### 3. Permissivi e interblocchi

Definisci cosa deve essere vero prima che un'azione possa verificarsi e cosa forza l'arresto dell'azione.

Includi:

• permissivi,
• trip,
• restrizioni di modalità,
• requisiti di feedback,
• comportamento in caso di timeout,
• condizioni di allarme.

Esempio:

• La pompa può avviarsi solo se `DI_EStop_OK = TRUE`
• La pompa può avviarsi solo se `AI_Tank_Level_Pct < 80`
• La pompa deve arrestarsi se `AI_Tank_Level_Pct >= 95`
• Generare allarme se il comando di marcia è attivo e non c'è feedback di marcia entro 3 secondi

È qui che molti prompt falliscono. Gli ingegneri spesso specificano il percorso ideale e omettono i motivi per cui la macchina deve rifiutarsi di muoversi. Gli impianti reali trascorrono molto tempo in condizioni non normali.

Per il prompting dell'IA, una filosofia di controllo dovrebbe essere definita come la specifica funzionale minima necessaria per generare un'impalcatura di controllo testabile. Non è una frase di marketing né una vaga narrazione progettuale. Operativamente, dovrebbe contenere gli stessi comportamenti fondamentali che un ingegnere dei controlli si aspetta in un documento in stile FDS:

• stato iniziale,
• modalità operative,
• sequenza delle operazioni,
• permissivi,
• interblocchi,
• allarmi e trip,
• risposte ai guasti,
• comportamento di reset,
• azioni dell'operatore,
• criteri di successo.

Tale definizione è limitata dagli osservabili ingegneristici. Se il prompt non dice al modello cosa deve fare il processo quando un sensore fallisce, un coperchio si apre, un livello supera la soglia o un feedback non arriva mai, allora il prompt non è una filosofia di controllo.

Questa impostazione si allinea con la pratica documentale industriale consolidata. La norma IEC 61131-3 disciplina i linguaggi di programmazione PLC, ma una buona logica ladder dipende comunque dalla chiarezza funzionale a monte. Gli standard non salvano intenzioni vaghe.

Un'utile idea sbagliata da abbandonare

L'ingegneria dei prompt nell'automazione non serve a rendere l'IA più creativa. Serve a rendere la specifica meno ambigua.

Il modo più efficace per sollecitare Yaga è fornire un modello vincolato e riutilizzabile. Al modello devono essere comunicati il ruolo, l'obiettivo del processo, i tag, la sequenza, i permissivi, gli interblocchi e il formato di output previsto. Se uno di questi elementi viene lasciato implicito, il modello potrebbe improvvisare.

Modello di prompt consigliato per Yaga

Agisci come un assistente per la logica ladder IEC 61131-3.

Obiettivo: Crea un'impalcatura di logica ladder per il seguente compito di controllo.

Descrizione del sistema: - Apparecchiatura: [macchina/unità di processo] - Obiettivo operativo: [cosa deve fare il sistema] - Stato di sicurezza: [quali output/stati devono essere veri quando è fermo o in guasto]

Dizionario I/O e Tag: Ingressi digitali: - [tag]: [descrizione] - [tag]: [descrizione]

Uscite digitali: - [tag]: [descrizione]

Ingressi analogici: - [tag]: [descrizione e unità ingegneristiche]

Bit interni / Timer / Contatori: - [tag]: [scopo]

Modalità operative:

• [Auto / Manuale / Manutenzione]
• [regole di modalità]

Sequenza delle operazioni:

Permissivi:

• [condizione richiesta prima dell'avvio]
• [condizione richiesta prima della transizione]

Interblocchi / Trip:

• [condizione che deve arrestare o inibire l'operazione]
• [condizione di guasto e risposta]

Allarmi:

• [condizione di allarme]
• [condizione di timeout]

Regole di Reset / Recupero:

• [requisito di reset manuale]
• [regola di reset automatico se consentito]

Requisiti di output:

• Usa una struttura ladder chiara rung-per-rung
• Non scrivere sulla stessa bobina di output in più posizioni in conflitto
• Usa bit interni nominati per gli stati di sequenza dove necessario
• Includi commenti per ogni rung
• Identifica esplicitamente le ipotesi

Questo modello non garantisce una logica corretta. Fa qualcosa di più utile: rende gli errori visibili prima.

1. [passaggio 1]
2. [passaggio 2]
3. [passaggio 3]

Prompt junior vs. prompt senior

| Stile del prompt | Esempio | Risultato probabile | |---|---|---| | Prompt junior | "Crea un diagramma ladder che accende un miscelatore per 10 secondi quando premo start." | Comportamento di arresto ambiguo, interblocco coperchio mancante, logica di reset poco chiara, struttura dei tag debole | | Prompt senior | "Agisci come un programmatore IEC 61131-3. Crea un'impalcatura ladder per un miscelatore. Ingressi: `PB_Start` (NO), `PB_Stop` (NC), `LS_LidClosed`, `EStop_OK`. Output: `MTR_Mixer`. Interblocco: il miscelatore non può funzionare se il coperchio non è chiuso e l'E-stop non è sano. Usa TON per un ciclo di marcia di 10 s. Arresta immediatamente all'apertura del coperchio o al comando di stop. Stato di sicurezza = motore spento. Fornisci commenti sui rung e identifica le ipotesi." | Baseline testabile con permissivi espliciti, comportamento di arresto più sicuro, percorso di simulazione più chiaro |

La differenza non è l'eloquenza. È la densità dei vincoli.

Un buon prompt PLC dovrebbe definire la macchina come un sistema con stato, non come un compito verbale. Prima che Yaga scriva qualsiasi rung, il prompt dovrebbe già rispondere a sei domande ingegneristiche.

1. Cos'è il sistema?

Definisci l'apparecchiatura, il confine del processo e l'operazione prevista.

Esempio:

• "Stazione di pompaggio duplex lead/lag con allarme di alto livello e alternanza."

2. Cos'è il comportamento "corretto"?

Definisci la condizione di successo operativo in termini osservabili.

Esempio:

• "In modalità auto, la pompa lead si avvia al 70% del livello del pozzetto e si arresta al 30%; la pompa lag si avvia al 90%; entrambe si arrestano su E-stop o sovraccarico motore."

Questo è importante perché "pronto per la simulazione" dovrebbe essere definito operativamente: un ingegnere è pronto per la simulazione quando può dimostrare, osservare, diagnosticare e rafforzare la logica di controllo contro un comportamento di processo realistico prima che raggiunga un processo reale. Questo è uno standard più rigoroso della semplice conoscenza della sintassi ladder.

3. Quali sono i tag e i tipi di segnale?

Elenca i tag, la direzione del segnale e le unità.

Esempio:

• `AI_WetWell_Level_Pct` = ingresso analogico, percentuale
• `DI_P1_OL_Trip` = ingresso digitale, trip di sovraccarico
• `DO_P1_RunCmd` = uscita digitale

4. Quali condizioni anomale esistono?

Definisci guasti, stati non validi e risposte ai guasti.

Esempio:

• qualità del trasmettitore di livello non valida,
• feedback di marcia assente dopo il comando,
• entrambi i sovraccarichi attivi,
• E-stop non sano,
• conflitto dell'interruttore HOA.

5. Cosa non deve mai accadere?

Dichiara esplicitamente il comportamento proibito.

Esempio:

• "Non comandare mai entrambe le pompe nella logica di alternanza manuale."
• "Non riavviare automaticamente dopo il reset del sovraccarico senza l'azione dell'operatore."
• "Non avviare il miscelatore con il coperchio aperto."

6. Quali ipotesi sono consentite?

Richiedi all'IA di dichiarare le ipotesi invece di nasconderle.

Esempio:

• "Assumi che il pulsante di stop sia NC sano se non diversamente specificato."
• "Assumi che la scalatura analogica sia già stata eseguita a monte."

Le ipotesi nascoste sono una fonte comune di logica ladder debole generata dall'IA.

OLLA Lab convalida la logica generata dall'IA inserendola in un ambiente di simulazione dove input, output, variabili e comportamento dell'apparecchiatura possono essere osservati e manipolati prima che venga presa in considerazione qualsiasi implementazione reale. Questo lo rende un ciclo di convalida a rischio contenuto, non un oracolo.

L'editor ladder fornisce la superficie logica. La modalità di simulazione fornisce l'esecuzione. Il pannello delle variabili fornisce l'osservabilità dei tag, degli stati I/O, dei valori analogici e delle variabili di controllo. Insieme, consentono a un ingegnere di testare se la logica generata si comporta come specificato quando le condizioni cambiano.

In termini pratici, questo significa che puoi:

• attivare/disattivare ingressi digitali,
• forzare condizioni di guasto,
• ispezionare la risposta dell'output,
• osservare il cambio di stato di timer e bit interni,
• confrontare lo stato ladder con il comportamento dell'apparecchiatura simulata,
• rivedere la logica dopo un test fallito.

La convalida non è uno screenshot di un rung che sembra corretto. La convalida è una sequenza di ipotesi smentite seguite da una logica più rigorosa.

Com'è fatto il ciclo genera-valida

1. Genera l'impalcatura con Yaga Usa un prompt basato su una filosofia di controllo strutturata.
2. Ispeziona la logica ladder generata Controlla i nomi dei tag, la proprietà dell'output, la struttura della sequenza e il posizionamento degli interblocchi.
3. Esegui la logica in simulazione Inizia con condizioni nominali.
4. Inietta condizioni anomale Forza la perdita del sensore, permissivi non validi, stati di coperchio aperto, trip di sovraccarico o casi di timeout.
5. Osserva se la logica fallisce in sicurezza Conferma l'arresto di sicurezza, il latch dell'allarme, l'inibizione del riavvio o il mantenimento dello stato come richiesto.
6. Revisiona e riesegui il test Rafforza il prompt o modifica direttamente il ladder.

È qui che OLLA Lab diventa operativamente utile. Offre agli ingegneri un luogo dove provare compiti ad alto rischio per i quali i sistemi reali sono cattivi insegnanti.

La testi definendo i casi di guasto prima di fidarti della sequenza nominale. Una routine ladder che funziona solo quando ogni segnale si comporta correttamente non è convalidata; è semplicemente incontestata.

Come minimo, testa queste categorie in simulazione.

Guasti all'integrità degli input

• sensore bloccato alto,
• sensore bloccato basso,
• trasmettitore fuori range,
• valore analogico errato,
• feedback assente dopo il comando.

Fallimenti degli interblocchi

• E-stop non sano,
• protezione o coperchio aperto,
• permissivo perso durante la marcia,
• trip di sovraccarico attivo,
• prova di valvola non effettuata.

Guasti di sequenza

• il timer non si resetta mai,
• il bit di stato rimane bloccato,
• sovrapposizione comando manuale e automatico,
• riavvio dopo trip senza reset,
• l'output rimane eccitato dopo il percorso di arresto.

Guasti analogici e legati al PID

• la variabile di processo supera la soglia di trip,
• banda morta analogica mancante,
• oscillazione dell'allarme vicino alla soglia,
• l'output del controllore satura,
• il trasferimento di modalità causa un salto (bump).

La presenza di strumenti analogici e dashboard PID in OLLA Lab è importante qui perché molti esempi di IA rimangono intrappolati nella logica discreta. Il controllo di processo reale solitamente non lo fa. Una stazione di pompaggio, una UTA (unità di trattamento aria), un loop termico o uno skid di dosaggio includono spesso soglie, ritardi, bande morte e comportamenti dipendenti dalla modalità.

Un esempio pratico dovrebbe mostrare la traduzione dall'intento di processo ai vincoli leggibili dalla macchina. Di seguito è riportato un esempio compatto di miscelatore adatto a Yaga.

Esempio di prompt strutturato

Agisci come un assistente per la logica ladder IEC 61131-3.

Descrizione del sistema: - Apparecchiatura: Miscelatore batch - Obiettivo operativo: Far funzionare il miscelatore per 10 secondi dopo il comando di avvio dell'operatore - Stato di sicurezza: Motore del miscelatore spento immediatamente su stop, perdita di E-stop o coperchio aperto

Dizionario I/O e Tag: Ingressi digitali: - DI_PB_Start: Pulsante di avvio, normalmente aperto - DI_PB_Stop: Pulsante di arresto, normalmente chiuso - DI_Lid_Closed: Prova di coperchio chiuso - DI_EStop_OK: Emergenza sana

Uscite digitali: - DO_Mixer_Run: Comando di marcia motore miscelatore

Bit interni / Timer: - M_Mix_Cycle_Active: Latch ciclo di miscelazione attivo - T_Mix_Run: Timer TON da 10 secondi

Sequenza delle operazioni:

Permissivi:

• DI_Lid_Closed = TRUE
• DI_EStop_OK = TRUE
• DI_PB_Stop sano

Interblocchi / Trip:

• Se il coperchio si apre durante la marcia, diseccita immediatamente DO_Mixer_Run
• Se l'E-stop non è sano, diseccita immediatamente DO_Mixer_Run

Requisiti di output:

• Fornisci un'impalcatura ladder rung-per-rung
• Usa un unico percorso di proprietà dell'output per DO_Mixer_Run
• Aggiungi commenti ai rung
• Dichiara eventuali ipotesi

1. Al comando di avvio, inizia il ciclo di miscelazione solo se il coperchio è chiuso e l'E-stop è sano
2. Fai funzionare il motore del miscelatore per 10 secondi
3. Arresta il motore quando il timer è terminato
4. Interrompi immediatamente se c'è un comando di stop, coperchio aperto o E-stop non sano

Cosa controllare dopo la generazione

Dopo che Yaga ha generato il ladder, ispeziona per verificare:

• un unico percorso di proprietà per `DO_Mixer_Run`,
• abilitazione del timer legata allo stato del ciclo attivo,
• caduta immediata all'apertura del coperchio o alla perdita di E-stop,
• nessun riavvio automatico nascosto,
• commenti che corrispondono al comportamento effettivo del rung,
• ipotesi esplicite.

Quindi eseguilo in simulazione e forza `DI_Lid_Closed` a falso durante la marcia temporizzata. Se il comando del motore persiste, il prompt o la logica sono errati.

Gli ingegneri dovrebbero documentare il lavoro PLC assistito dall'IA come prova ingegneristica, non come una galleria di screenshot dell'interfaccia. Un registro credibile mostra cosa avrebbe dovuto fare il sistema, come è stato testato, come ha fallito e come è stato corretto.

Usa questa struttura:

Registra l'esatto guasto introdotto: perdita del sensore, sovraccarico, caduta del permissivo, timeout, valore analogico non valido, ecc.

1. Descrizione del sistema Definisci l'apparecchiatura, l'obiettivo di processo, la modalità operativa e lo stato di sicurezza.
2. Definizione operativa di "corretto" Dichiara i criteri di successo osservabili, incluse le condizioni di arresto e il comportamento in stato anomalo.
3. Logica ladder e stato dell'apparecchiatura simulata Mostra il ladder generato o modificato insieme allo stato della macchina simulata o al comportamento della variabile pertinente.
4. Il caso di guasto iniettato
5. La revisione effettuata Documenta la modifica logica o il perfezionamento del prompt utilizzato per correggere il comportamento.
6. Lezioni apprese Dichiara cosa ha rivelato il fallimento riguardo alla filosofia di controllo originale, alle ipotesi o al design della sequenza.

Questo produce un corpo di prove compatto che è utile per revisori, istruttori o responsabili delle assunzioni.

Il prompting PLC assistito dall'IA è utile per l'impalcatura, la stesura e l'accelerazione della struttura logica di primo passaggio. Non è sufficiente per la convalida della sicurezza, la firma della messa in servizio o le decisioni di implementazione specifiche del sito.

Quel confine è importante sia per l'etica che per l'ingegneria. OLLA Lab è descritto qui come un simulatore web di logica ladder e digital-twin con supporto guidato tramite Yaga, simulazioni 3D/WebXR/VR, esercizi basati su scenari, strumenti analogici e PID e flussi di lavoro per istruttori. Tali funzionalità lo rendono utile come ambiente di prova e convalida. Non convertono la logica generata in logica d'impianto approvata per associazione.

Alcuni limiti dovrebbero rimanere espliciti:

• Il ladder generato dall'IA può essere sintatticamente plausibile e funzionalmente non sicuro.
• La simulazione può esporre molti difetti logici, ma non è identica alla messa in servizio in sito.
• La convalida del digital twin dipende dalla fedeltà del modello e dall'ambito dello scenario.
• Gli obblighi di sicurezza funzionale richiedono ancora metodi formali, revisione competente e disciplina del ciclo di vita basata sugli standard.

Ciò è coerente con la più ampia letteratura sulla sicurezza. La norma IEC 61508 e le linee guida correlate trattano i fallimenti sistematici, gli errori di specifica e la disciplina di verifica come preoccupazioni centrali. Un modello che produce codice rapidamente non rimuove tali doveri.

Questo approccio è più utile perché sposta il compito dalla generazione non vincolata all'ingegneria delimitata. Quando scrivi prima una filosofia di controllo, forzi le decisioni importanti allo scoperto: stato di sicurezza, permissivi, trip, proprietà della sequenza e risposta ai guasti.

Ciò ha tre vantaggi pratici:

• migliore impalcatura di primo passaggio,
• debug più rapido in simulazione,
• revisione più chiara da parte degli esseri umani.

Insegna anche l'abitudine giusta. La transizione professionale non è solo dal non conoscere il ladder al conoscerlo. È dallo scrivere rung al difendere il comportamento.

- Panoramica dello standard IEC 61131-3 (PLCopen) - NIST AI Risk Management Framework (AI RMF 1.0) - Panoramica delle Web Content Accessibility Guidelines (WCAG) 2 del W3C - Portale delle tassonomie e pubblicazioni IEEE - Pagina dello standard ISO/IEC 23894 per la gestione del rischio IA