Cobot e saldatura: rischi reali, sicurezza e cosa dice la normativa ISO 10218

Nel mondo dell’automazione industriale c’è una frase che continua a circolare, soprattutto quando si parla di saldatura robotizzata:

“Il cobot è sicuro perché è collaborativo.”

È una semplificazione comoda, ma tecnicamente sbagliata. Chi progetta, integra o utilizza realmente sistemi robotici sa che la sicurezza non è mai una proprietà del robot. È il risultato di un equilibrio più complesso, che coinvolge processo, layout, operatore, logiche di controllo e architettura complessiva. Le norme più recenti – in particolare la ISO 10218-2:2025 e, a livello concettuale più evoluto, IEC 127:2026 – vanno tutte nella stessa direzione: la sicurezza è una proprietà del sistema, non del componente. E questo, nella saldatura, diventa ancora più evidente. Questo approccio è tipico delle moderne soluzioni con robot collaborativi, in cui integrazione, sicurezza e controllo del processo sono progettati come un sistema unico.

Cosa dice la normativa: ISO 10218 e sicurezza nelle applicazioni robotiche

ISO 10218-2 è molto chiara su un aspetto spesso ignorato: non si parla di robot, ma di robot application.

Una applicazione robotica di saldatura automatizzata comprende:

• il robot
• l’end-effector (nel nostro caso la torcia di saldatura)
• il pezzo e le attrezzature
• il programma
• il layout
• l’interazione con l’operatore

Questo significa che il rischio non nasce dal movimento del braccio in sé, ma da come tutto questo sistema interagisce. IEC 127 rafforza ulteriormente questo approccio: introduce una visione in cui la sicurezza non è più solo “protezione da un pericolo”, ma gestione coerente delle funzioni, degli stati e delle interazioni di sistema.

Tradotto in pratica:

puoi avere un robot “collaborativo” e un sistema non sicuro
puoi avere un robot industriale tradizionale e un sistema perfettamente sicuro

La differenza non è nel robot. È nel progetto.

Richiedi una valutazione preliminare dell’applicazione

Applicazioni collaborative: cosa significa davvero “cobot”

Un altro equivoco diffuso: il termine “cobot”.

Dal punto di vista normativo, il cobot non esiste. Esistono invece le applicazioni collaborative.

Una applicazione è collaborativa quando:

• operatore e robot condividono lo stesso spazio
• durante specifiche fasi operative

E questo può avvenire con:

• un cobot
• oppure un robot industriale tradizionale

La ISO 10218-2 identifica chiaramente le modalità collaborative:

• arresto monitorato
• controllo distanza e velocità (SSM)
• limitazione di potenza e forza (PFL)
• guida manuale

Ma qui c’è il punto chiave:

queste non sono “feature del robot”
sono funzioni di sicurezza da progettare, parametrizzare e validare

IEC 127 aggiunge un livello ulteriore: queste funzioni devono essere coerenti tra loro, integrate nel sistema e gestite nei diversi stati operativi.

Non basta che funzionino. Devono funzionare insieme.

Caso pratico: tavolo di saldatura cobot assistita

Per capire davvero cosa significa tutto questo, ha senso uscire dalla teoria e guardare un sistema reale.

Nel caso del tavolo di saldatura cobot assistita , il progetto non nasce per “mettere un cobot a saldare”, ma per costruire un equilibrio tra:

• ripetibilità del processo
• controllo da parte del saldatore
• gestione dei rischi tipici della saldatura

Il cobot esegue i cordoni programmati.
Il saldatore rimane centrale: definisce parametri, traiettorie, qualità.

Questo è già un primo punto normativamente corretto:
il sistema non è autonomo
è assistito e supervisionato

Rischi reali nella saldatura robotizzata (oltre il robot)

Nella saldatura, i rischi principali non sono legati al robot:

• arco elettrico (radiazioni UV/IR)
• fumi e particolato
• spruzzi di metallo
• superfici calde
• energia elettrica

Questi rischi esistono anche se il robot si muove lentamente o ha PFL attivo.

Ed è qui che molti sistemi “cobotizzati” mostrano il loro limite:
si concentra tutto sull’interazione uomo-robot, ma si dimentica il processo.

Nel tavolo cobot assistito, invece, il progetto tiene conto di questo.

Come progettare un sistema sicuro: approccio corretto

Prendiamo alcuni elementi concreti del sistema e leggiamoli con occhi normativi.

Tavolo aspirato

Non è un accessorio.

È una misura tecnica che:

• intercetta i fumi vicino alla sorgente
• stabilizza l’ambiente di processo
• riduce l’esposizione dell’operatore

Dal punto di vista ISO 10218-2:
→ è una misura di riduzione del rischio legata al processo

Dal punto di vista IEC 127:
→ è parte dell’architettura funzionale del sistema, non un elemento isolato

Struttura scorrevole e volume semi-confinato

La struttura superiore:

• delimita la zona di lavoro durante la saldatura
• migliora la captazione dei fumi
• riduce l’esposizione all’arco

Qui si vede un concetto importante:

non è una “gabbia classica”
ma nemmeno una collaborazione libera, quando si collabora il layout agevola

È una soluzione ibrida progettata sulla funzione

IEC 127 aiuta a leggere questo tipo di scelte:
la sicurezza non è binaria (recinto sì/no), ma dipendente dallo stato operativo del sistema.

Finestra di ispezione

Permette:

• controllo visivo continuo
• distanza di sicurezza
• intervento consapevole

Questo è un esempio perfetto di integrazione tra:

• ergonomia
• sicurezza
• controllo operativo

Simulazione ad arco spento

Prima dell’arco:

• verifica traiettorie
• evita collisioni
• valida il ciclo

ISO 10218-2 lo richiede come parte della verifica del programma (variabile)

IEC 127 lo rafforza:
è una fase di validazione del comportamento del sistema, non solo del robot.

La matrice reale dei rischi (senza chiamarla matrice)

Se si guarda questo sistema nel suo insieme, emerge chiaramente una logica strutturata:

• il rischio viene identificato (fumi, arco, movimento)
• viene affrontato con una soluzione tecnica specifica
• questa soluzione è integrata nel ciclo operativo
• viene verificata attraverso l’uso (dry-run, monitoraggio, supervisione)

Questo è esattamente ciò che ISO 10218-2 richiede:

• analisi
• riduzione del rischio
• verifica
• validazione

E ciò che IEC 127 porta a un livello più evoluto:

• coerenza tra funzioni
• gestione degli stati
• integrazione tra sottosistemi

Quando il cobot aiuta davvero (e quando no)

Il cobot in questo contesto è utile, ma per motivi precisi:

• Facilita il processo di riduzione dei rischi
• Facilita programmazione (teach by hand)
• Riduce carico fisico per l’operatore
• Migliora ripetibilità del processo

Ma non elimina:

• rischi di processo
• necessità di protezioni
• ruolo del saldatore

Infatti, il sistema descritto chiarisce esplicitamente:

non è una cella autonoma
non sostituisce la competenza
non elimina la responsabilità

Questo è perfettamente coerente con l’approccio normativo.

Il punto più sottovalutato: gli stati del sistema

Uno degli aspetti più interessanti (e spesso ignorati) riguarda gli stati operativi:

• setup
• programmazione
• prova a secco
• saldatura
• scarico pezzo

Ogni stato ha:

• rischi diversi
• requisiti diversi
• protezioni diverse

IEC 127 introduce proprio questa visione:

la sicurezza non è statica
è legata al comportamento del sistema nel tempo

Ed è qui che si gioca la vera differenza tra un sistema “che funziona” e uno progettato bene.

Conclusione: il vero salto di qualità

Se c’è un messaggio da portare a casa, è questo:

il passaggio da robot → cobot non è il vero salto
il vero salto è da componente → sistema

ISO 10218-2 ci dice come progettare applicazioni sicure.
IEC 127 ci spinge a fare un passo oltre: progettare sistemi coerenti, integrati, robusti.

Nel caso della saldatura cobot assistita, questo significa:

• progettare condizioni controllate
• valorizzarne il ruolo del saldatore
• gestire i rischi in modo strutturato

Ed è proprio qui che nasce la differenza tra chi installa cobot e chi progetta applicazioni di automazione ibride cobot assistite.