Handshaking tra PLC e Robot: come standardizzare i protocolli di interblocco

Per standardizzare l'handshaking tra PLC e robot, i tecnici devono definire scambi booleani deterministici per la prontezza (readiness), i permissivi di movimento, il reset dei guasti e la conferma della posizione. Lo scopo è impedire l'avanzamento della sequenza in presenza di stati ambigui o transitori. In pratica, gli interblocchi standardizzati riducono il rischio di collisione costringendo il PLC e il controllore del robot a concordare prima che il movimento prosegua.

Un malinteso comune è che l'handshaking del robot riguardi principalmente la mappatura corretta dei bit. Non è così. Il problema più complesso è far sì che due controllori concordino sulle transizioni di stato nonostante i diversi comportamenti di scansione, i tempi di rete e la perdita transitoria di feedback. Un bit mappato può comunque essere un bit errato.

Nella revisione di Ampergon Vallis su 500 integrazioni di celle robotiche simulate in OLLA Lab, il 68% dei guasti iniziali di collisione ha coinvolto cadute asincrone del feedback `In_Position` o di zona libera (zone-clear) inferiori a 50 ms. Metodologia: n=500 esecuzioni di validazione simulate di celle pick-and-place e di trasferimento, comparatore di base = logica utente di primo passaggio prima delle revisioni di debounce o di consolidamento dello stato, finestra temporale = 1 gennaio 2026 - 15 marzo 2026. Questa metrica supporta un unico punto limitato: l'instabilità del feedback di breve durata è una modalità di guasto frequente al primo passaggio nella messa in servizio simulata. Non pretende di rappresentare un tasso di collisione a livello industriale.

Un handshake scadente solitamente fallisce in modo poco elegante. Un morsetto si chiude in anticipo, un nastro trasportatore indicizza prima che il robot si sia spostato, o una pinza entra in una zona che il PLC riteneva vuota. La fisica raramente è impressionata da tempistiche ottimistiche.

I segnali essenziali in un handshake tra PLC e robot sono la prontezza, i permissivi di sicurezza, la conferma dello stato di movimento, la gestione dei guasti e i bit di esecuzione della sequenza. Se tali segnali non sono definiti esplicitamente e bloccati in un chiaro modello di sequenza, l'handshake non è standardizzato; è semplicemente collegato.

Segnali di handshake principali

Conferma che i prerequisiti lato PLC per il movimento sono soddisfatti. Le condizioni tipiche includono catena di sicurezza integra, protezioni chiuse dove richiesto, E-stop resettato, nessun guasto attivo nella cella e sequenza in una modalità consentita.

• `PLC_System_Ready`

Conferma che il controllore del robot è disponibile per partecipare al funzionamento automatico. Ciò può includere controllore integro, nessun guasto al programma attivo, nessun arresto di protezione e modalità operativa allineata con la sequenza della cella.

• `Robot_System_Ready`

Comando dal PLC che richiede l'abilitazione della potenza dei servo o dei drive, laddove l'architettura assegni tale autorità al PLC.

• `PLC_Request_Motors_On`

Feedback dal robot che conferma che la potenza dei drive è effettivamente abilitata. Comando e feedback non sono la stessa cosa. Gli impianti lo imparano a proprie spese in orari scomodi.

• `Robot_Motors_On`

Una richiesta di reset deliberata emessa solo quando le condizioni di reset sono valide.

• `PLC_Fault_Reset_Request`

Feedback che mostra che il robot non è più in uno stato di guasto.

• `Robot_Fault_Clear`

Indicazione di posizione completata o zona libera utilizzata per confermare che un movimento programmato o una condizione di spazio libero sicuro si è effettivamente verificata.

• `Robot_In_Position`

Un segnale derivato o diretto che conferma che il robot si trova al di fuori di una zona di interferenza protetta prima che un altro attuatore si muova.

• `Zone_Clear`

Trigger di sequenza emesso solo quando tutti i permissivi richiesti e le conferme di stato sono veri.

• `PLC_Cycle_Start`

Feedback che il robot ha completato l'attività comandata o ha raggiunto il checkpoint di sequenza previsto.

• `Robot_Cycle_Complete`

Definizione operativa di un handshake standardizzato

Un handshake standardizzato tra PLC e robot è uno scambio deterministico e bidirezionale di stati booleani con proprietà definita, transizioni valide, comportamento di timeout e risposta ai guasti. La standardizzazione è importante meno per l'eleganza che per la ripetibilità: ogni bit deve rispondere chiaramente a quattro domande:

1. Chi ne è il proprietario?
2. Quando può attivarsi?
3. Quando deve disattivarsi?
4. Cosa fa la sequenza se non arriva mai, arriva in ritardo o sfarfalla?

Se mancano queste risposte, l'interfaccia è solo ottimismo non documentato.

Contesto normativo

Gli standard e le linee guida pertinenti includono:

• ISO 10218-1 / ISO 10218-2 per i requisiti di sicurezza dei robot e dei sistemi robotici
• RIA TR R15.406 per le pratiche di salvaguardia nelle celle robotiche
• IEC 61508 come quadro di riferimento più ampio per la sicurezza funzionale dei sistemi elettrici/elettronici/programmabili

Questi standard non forniscono un elenco universale di bit per ogni cella. Richiedono però un trattamento disciplinato delle funzioni di sicurezza, delle modalità operative e della riduzione del rischio.

Le race condition causano collisioni quando il PLC fa avanzare la logica di sequenza basandosi su uno stato transitorio o non aggiornato che il controllore del robot non ha mantenuto in modo stabile. Il meccanismo abituale è semplice: il PLC vede un permissivo vero per una o due scansioni, fa avanzare un'azione a valle, e il robot è già uscito dallo stato presunto o non lo ha mai raggiunto completamente.

Perché la temporizzazione di PLC e robot non concorda

Un PLC e un controllore di robot non valutano necessariamente lo stato con la stessa cadenza.

• Un task PLC può essere eseguito ogni 2-10 ms
• Gli aggiornamenti I/O del robot possono aggiornarsi a intervalli diversi
• Il trasporto di rete aggiunge jitter
• Il blending del movimento può invalidare brevemente un bit di posizione
• La logica HMI o di supervisione può scrivere comandi di sequenza in modo asincrono

Quella discrepanza è sufficiente a creare un falso senso di certezza. I bug di sequenza vivono spesso nello spazio tra "vero una volta" e "vero abbastanza a lungo da fidarsi".

Pattern comuni di race condition

#### 1. Perdita transitoria di `In_Position` durante il movimento blended

Un robot raggiunge una regione programmata, imposta `In_Position`, quindi lo perde brevemente durante il blending della traiettoria o la transizione di zona. Il PLC vede il bit abbastanza a lungo da rilasciare un morsetto, avviare un indicizzatore o aprire un cancello. Il robot potrebbe essere ancora fisicamente all'interno dell'inviluppo di interferenza.

#### 2. Confusione tra comando e feedback

Il PLC eccita una `Motors_On_Request` e tratta immediatamente il robot come capace di movimento prima di ricevere il feedback verificato `Robot_Motors_On`. Questa è una logica di stato del comando che finge di essere una logica di stato dell'apparecchiatura.

#### 3. Comportamento a doppia bobina o bit fantasma

Lo stesso stato di sequenza viene scritto da più di un rung, task o percorso del controllore. Il risultato è un bit che appare valido nelle istantanee di trend ma non è posseduto in modo deterministico.

#### 4. Sostituzione del timer come prova

Un programmatore inserisce un ritardo fisso invece di attendere una conferma positiva come `Zone_Clear` o `Robot_In_Position_Stable`. I timer sono utili per il debounce e la supervisione dei timeout. Non sono la prova che il movimento sia stato completato in sicurezza.

Perché la logica standardizzata riduce questo rischio

La logica standardizzata riduce le race condition forzando l'avanzamento della sequenza a dipendere dallo stato verificato, non dal tempo trascorso presunto. La distinzione è compatta e importante: il tempo non è una prova; il feedback è una prova.

È qui che dovrebbe essere definita correttamente la "prontezza alla simulazione" (Simulation-Ready). Un ingegnere Simulation-Ready non è qualcuno che sa disegnare la sintassi ladder a memoria. È qualcuno che sa dimostrare, osservare, diagnosticare e consolidare la logica di controllo contro un comportamento di processo realistico prima che raggiunga una macchina reale.

Per programmare un interblocco sicuro, utilizzare la verifica in serie della prontezza, dello stato privo di guasti e del feedback stabile prima di bloccare (latch) il comando di sequenza successivo. L'obiettivo non è rendere il rung ordinato. L'obiettivo è rendere difficile il movimento prematuro.

### Esempio: struttura dell'interblocco `PLC_Cycle_Start`

Di seguito è riportato un esempio di ladder in forma testuale che mostra un pattern delimitato. La denominazione dei tag varia in base alla piattaforma; il principio logico no.

|----[XIC PLC_System_Ready]----[XIC Robot_Fault_Clear]----[XIC Robot_Motors_On]----[XIC Zone_Clear]----[TON T4:0 50ms]----| | | |----[XIC T4:0.DN]------------------------------------------------------------------------------------------------[OTE PLC_Cycle_Start]----|

Cosa sta facendo questo rung

• `PLC_System_Ready` verifica che la cella sia autorizzata a funzionare.
• `Robot_Fault_Clear` impedisce l'avanzamento della sequenza in uno stato anomalo noto.
• `Robot_Motors_On` conferma che il robot è effettivamente abilitato alla potenza.
• `Zone_Clear` conferma che il robot è fisicamente libero dall'area di interferenza.
• Il debounce `TON` richiede che la catena di permissivi rimanga vera per un periodo minimo di stabilità prima di emettere `PLC_Cycle_Start`.

Perché il timer di debounce è importante

Un timer di debounce filtra l'instabilità del segnale di breve durata causata da:

• jitter di rete,
• transizioni dello stato di movimento,
• logica di zona derivata rumorosa,
• chatter dei sensori,
• brevi cadute dello stato del controllore durante le transizioni di programma.

Usato correttamente, un timer di debounce convalida la stabilità del segnale. Usato pigramente, un timer diventa una superstizione con millisecondi allegati.

Regole di programmazione raccomandate

#### Definire la proprietà esplicitamente

Ogni bit di handshake dovrebbe avere una fonte autorevole. Se `Robot_In_Position` può essere sintetizzato in tre posti, non è un segnale; è un argomento.

#### Separare i bit di comando dai bit di feedback

Non usare `Request_Motors_On` come prova che i motori sono accesi. Mantenere comandi e prove distinti.

#### Aggiungere la supervisione dei timeout

Ogni feedback previsto dovrebbe avere un percorso di timeout:

• comando emesso,
• feedback atteso,
• timeout superato,
• guasto bloccato,
• percorso di recupero definito.

Una sequenza senza comportamento di timeout non è robusta. È solo paziente finché non fallisce.

#### Bloccare (latch) gli stati di sequenza, non le speranze momentanee

Utilizzare una logica di stato esplicita o passi di sequenziatore in modo che la progressione dipenda da transizioni convalidate. Questo è particolarmente importante quando il movimento del robot e gli attuatori ausiliari condividono lo stesso inviluppo di lavoro.

#### Progettare la risposta al guasto prima che il percorso "felice" sia terminato

Se `In_Position` cade a metà ciclo, definire se la cella:

• va in pausa,
• si ritrae,
• va in guasto e richiede l'intervento dell'operatore,
• o ritorna a un passo sicuro noto.

La macchina farà prima o poi quella domanda. Meglio rispondere prima dell'avvio.

OLLA Lab simula i guasti di temporizzazione asincroni consentendo ai tecnici di testare la logica ladder contro un digital twin, osservando i cambiamenti di stato I/O, il comportamento della sequenza e la risposta ai guasti in un ambiente a rischio contenuto. Ciò lo rende utile per le prove e la validazione, non come sostituto per l'accettazione formale in sito o la certificazione di sicurezza.

Definizione operativa di validazione tramite digital twin in questo contesto

In questo articolo, la validazione tramite digital twin significa testare se la logica ladder produce il comportamento della macchina previsto contro un modello di apparecchiatura virtuale realistico, sia in condizioni normali che anomale. I comportamenti osservabili includono:

• attivazione di ingressi discreti e verifica della risposta in uscita,
• monitoraggio delle transizioni di stato dei tag nella sequenza,
• iniezione di perdita di feedback transitoria,
• verifica se gli interblocchi bloccano movimenti non sicuri,
• confronto dello stato ladder con lo stato dell'apparecchiatura simulata,
• revisione della logica dopo un guasto e nuovo test.

Come appare il flusso di lavoro all'interno di OLLA Lab

Utilizzando OLLA Lab, un tecnico può:

• costruire la logica di handshake nell'editor ladder basato su web,
• eseguire il programma in modalità simulazione,
• ispezionare tag, I/O e valori analogici nel pannello delle variabili,
• osservare il comportamento della cella robotica o della macchina nella simulazione 3D/WebXR,
• iniettare condizioni anomale come un segnale `Robot_In_Position` caduto,
• confermare se la sequenza si arresta, va in guasto o si riprende come progettato.

È qui che OLLA Lab diventa operativamente utile. Offre ai tecnici un luogo dove provare l'esatta classe di errori che sono troppo costosi, troppo pericolosi o troppo dirompenti da praticare su hardware reale.

Un esercizio di validazione concreto

Un test di handshake pratico in OLLA Lab potrebbe apparire così:

1. Costruire una sequenza pick-and-place con `PLC_System_Ready`, `Robot_Motors_On`, `Zone_Clear` e `PLC_Cycle_Start`.
2. Eseguire la cella normalmente e confermare che il robot liberi la zona prima che il nastro trasportatore indicizzi.
3. Iniettare una breve caduta a metà ciclo su `Robot_In_Position` o `Zone_Clear`.
4. Osservare se la logica di debounce filtra correttamente il transitorio.
5. Aumentare la durata del guasto e verificare che il PLC arresti l'avanzamento della sequenza e blocchi un guasto.
6. Revisionare la logica del rung o dello stato, quindi rieseguire lo stesso test.

Quel ciclo — costruire, osservare, iniettare guasto, revisionare, rieseguire — è il vero valore formativo. La sola sintassi non insegna il giudizio di messa in servizio.

Cosa OLLA Lab dovrebbe e non dovrebbe essere chiamato a provare

OLLA Lab può aiutare i tecnici a validare la logica di sequenza, il comportamento I/O e la gestione dei guasti prima della distribuzione. Può supportare le prove di compiti di messa in servizio come la verifica degli interblocchi e i test di stato anomalo.

OLLA Lab non prova da solo:

• la correttezza del cablaggio sul campo,
• le prestazioni finali della funzione di sicurezza,
• il raggiungimento del SIL,
• la firma di conformità,
• o la competenza in sito secondo i vincoli specifici dell'impianto.

Un simulatore è uno spazio di prova disciplinato. Non è una deroga agli standard.

L'handshaking tra PLC e robot dovrebbe essere guidato da standard di sicurezza formali, una filosofia di controllo documentata e una progettazione dello stato deterministica. Gli standard stabiliscono il quadro di sicurezza; la progettazione della sequenza determina se la cella si comporta in modo coerente all'interno di tale quadro.

Standard e linee guida per ancorare il lavoro

Definiscono i requisiti di sicurezza per i robot industriali e i sistemi robotici, incluse le responsabilità di integrazione.

• ISO 10218-1 / ISO 10218-2

Fornisce una guida pratica alla salvaguardia per le applicazioni robotiche e la progettazione delle celle.

• RIA TR R15.406

Inquadra la disciplina più ampia della sicurezza funzionale per i sistemi programmabili.

• IEC 61508

Definiscono la semantica dei segnali specifica del controllore, i bit dello stato di movimento e il comportamento degli I/O di sicurezza.

• Manuali di interfaccia robot del fornitore

Pratiche ingegneristiche che contano più degli slogan

#### Scrivere una matrice di interfaccia

Documentare ogni bit di handshake con:

• origine,
• destinazione,
• stato normale,
• significato asserito,
• comportamento di reset,
• aspettativa di timeout,
• conseguenza del guasto.

#### Definire il comportamento "corretto" prima del test

Non iniziare la simulazione o la validazione in stile FAT senza una definizione operativa di successo. "Il robot funziona" non è una definizione. "Il nastro trasportatore indicizza solo dopo che `Zone_Clear` rimane vero per 50 ms e non esiste alcun guasto robot attivo" è una definizione.

#### Trattare gli stati anomali come requisiti di prima classe

Testare:

• robot in guasto all'avvio del ciclo,
• motori spenti durante la sequenza,
• `Cycle_Complete` non aggiornato,
• `In_Position` caduto,
• reset tentato in condizioni non valide.

#### Mantenere distinte la logica di sicurezza e quella di sequenza

Le funzioni classificate per la sicurezza devono essere progettate e validate secondo l'architettura e gli standard applicabili. I bit di sequenza standard non sostituiscono le funzioni di sicurezza. Mescolare questi ruoli con noncuranza è il modo in cui la documentazione diventa finzione.

I tecnici dovrebbero dimostrare le competenze di handshaking con un corpo compatto di prove ingegneristiche che mostri l'intento della sequenza, la gestione dei guasti e la disciplina di revisione. Una galleria di screenshot non è sufficiente. Chiunque può raccogliere bit verdi.

Utilizzare questa struttura:

1) Descrizione del sistema

Dichiarare chiaramente lo scopo della cella e le interfacce.

Esempio: "Cella di trasferimento a nastro trasportatore a due assi con un robot articolato che esegue pick-and-place tra l'ingresso e l'alloggiamento del dispositivo. Il PLC controlla il nastro, il morsetto e lo stato della sequenza. Il robot fornisce feedback di motori accesi, reset guasti, in posizione e ciclo completato."

2) Definizione operativa di "corretto"

Definire cosa significa corretto nel comportamento osservabile.

Esempio: "`PLC_Cycle_Start` può eccitarsi solo quando i permissivi di sicurezza sono integri, i motori del robot sono accesi e `Zone_Clear` è vero continuamente per 50 ms. Il movimento del nastro trasportatore è inibito mentre il robot si trova all'interno della zona di trasferimento."

3) Logica ladder e stato dell'apparecchiatura simulata

Mostrare la logica del rung o dello stato insieme alla risposta della macchina simulata.

Includere:

• snippet ladder,
• elenco tag,
• matrice di sequenza,
• prove 3D o dello stato di simulazione che mostrano il robot fuori dalla zona quando il nastro trasportatore si avvia.

4) Il caso di guasto iniettato

Introdurre deliberatamente una condizione anomala.

Esempio: "Caduta di 30 ms iniettata su `Robot_In_Position` durante il movimento di uscita blended."

5) La revisione effettuata

Spiegare la modifica logica e perché era necessaria.

Esempio: "Aggiunto debounce di 50 ms su `Zone_Clear`, separati i tag di comando e feedback, e bloccato uno stato di attesa sequenza al timeout."

6) Lezioni apprese

Dichiarare chiaramente la conclusione ingegneristica.

Esempio: "La logica iniziale trattava la prova di posizione transitoria come spazio libero stabile. La logica revisionata ha richiesto una conferma sostenuta e ha impedito il movimento prematuro del nastro trasportatore."

Quel tipo di artefatto è utile perché dimostra ragionamento, non solo familiarità con lo strumento.

Un handshake standardizzato è migliore perché rende il comportamento prevedibile tra celle, team e condizioni di guasto. La logica ad hoc può funzionare durante una demo e fallire comunque sotto deriva, latenza, modifiche di manutenzione o scenari di recupero.

Vantaggi pratici della standardizzazione

Tutti sanno cosa significa ogni bit e quando è valido.

• Ridotta ambiguità di messa in servizio

La proprietà chiara e la logica di timeout rendono i guasti tracciabili.

• Isolamento dei guasti più rapido

Il movimento dipende dalla prova, non dalle ipotesi.

• Comportamento della sequenza più sicuro

I template standard riducono la reinvenzione senza bloccare il giudizio ingegneristico.

• Migliore riutilizzo tra i progetti

Un handshake documentato è più facile da testare sistematicamente in un digital twin o in un ambiente di simulazione.

• Flusso di lavoro di simulazione e FAT migliorato

Il punto non è la precisione burocratica. Il punto è che le interfacce ripetute falliscono in modo meno misterioso.

- Portale delle specifiche OPC UA - Pagina degli standard ISO 10218 per robot e dispositivi robotici - Panoramica sulla sicurezza funzionale IEC 61508 - Revisione della messa in servizio virtuale e del digital twin (Journal of Manufacturing Systems) - Risorse del testbed NIST Smart Manufacturing