Su un asse automatico l’encoder può già svolgere senza problemi il controllo ordinario della posizione. La situazione cambia quando, durante l’accesso a una zona pericolosa, la macchina deve garantire l’assenza di movimento, controllare una decelerazione oppure consentire il moto soltanto entro condizioni prestabilite. In quel momento non basta più chiedersi se la misura sia precisa: occorre stabilire se il segnale possa sostenere la funzione che riduce il rischio.
Il discrimine non è quindi la risoluzione dell’encoder, né il nome del protocollo usato per trasmetterne i dati. Conta ciò che accadrebbe in caso di segnale assente, errato, incoerente o non aggiornato: se uno di questi guasti può impedire il comportamento sicuro richiesto, il feedback e il suo intero percorso diventano parte del problema safety.
Dal pericolo alla funzione, prima di scegliere il componente
La ISO 13849-1:2023 riguarda le parti dei sistemi di comando legate alla sicurezza, considerate a partire dagli ingressi rilevanti fino alle uscite che determinano la reazione della macchina. Il riferimento non è dunque il componente isolato, ma la funzione impiegata per ridurre un rischio individuato attraverso la valutazione della macchina.
La sequenza progettuale parte dalla gravità del possibile danno, dalla frequenza o durata dell’esposizione e dalla possibilità di evitare il pericolo. Da questa stima deriva il PLr, cioè il livello di prestazione richiesto alla specifica funzione. Solo dopo si può stabilire quale architettura sia adeguata e quale ruolo debba avere il feedback.
La stessa macchina può richiedere risposte differenti nei diversi modi operativi. In un caso lo stato sicuro può essere raggiunto senza conoscere la posizione dell’asse; in un altro occorre rilevare il movimento residuo prima di autorizzare un accesso; durante una regolazione può invece essere necessario sorvegliare la velocità mentre il moto rimane consentito. Sono condizioni diverse e non autorizzano a scegliere lo stesso schema soltanto perché l’encoder installato è molto preciso.
La specifica della funzione dovrebbe chiarire almeno:
- quale pericolo deve essere ridotto e in quale modo operativo;
- quale variabile deve essere rilevata: posizione, velocità, direzione, arresto o presenza di movimento;
- quale reazione deve produrre il superamento della condizione ammessa;
- quale PLr è richiesto;
- quali guasti del segnale e della catena devono essere rilevati;
- come sarà verificato il comportamento durante le prove di accettazione.
Quando il feedback entra davvero nella funzione di sicurezza
Un encoder usato esclusivamente dal controllo di processo può restare fuori dalla funzione safety se la reazione sicura non dipende dalla sua misura. In questa configurazione il controllore ordinario può utilizzare posizione e velocità per governare il ciclo produttivo, mentre il percorso di sicurezza raggiunge il proprio stato finale senza affidarsi a quei dati.
Il feedback diventa invece rilevante per la sicurezza quando la logica deve usarlo per decidere se consentire il movimento, avviare una reazione, confermare l’arresto o verificare il rispetto di una condizione ammessa. A quel punto l’ingresso non può essere valutato separatamente dalla logica che lo interpreta e dalle uscite che comandano gli attuatori. La funzione è una catena: misura, trasmissione, elaborazione e reazione devono concorrere insieme al livello richiesto.
Questo criterio permette di distinguere tre configurazioni progettuali senza trasformarle in prescrizioni universali.
| Configurazione | Condizione progettuale | Verifica decisiva |
|---|---|---|
| Encoder standard esterno alla funzione safety | Posizione e velocità servono al controllo ordinario, ma la funzione di riduzione del rischio non usa questi dati. | Dimostrare che un guasto del feedback ordinario non comprometta la reazione di sicurezza. |
| Encoder con caratteristiche safety incluso nella catena | La decisione di sicurezza dipende dalla misura del movimento. | Controllare campo d’impiego dichiarato, dati di affidabilità, diagnostica, integrazione e compatibilità con l’architettura completa. |
| Doppio canale o sensore indipendente | L’architettura scelta richiede confronto, ridondanza o capacità diagnostiche ulteriori. | Valutare l’effettiva indipendenza dei canali, la logica di confronto, i guasti rilevabili e la reazione alle incoerenze. |
Un doppio encoder non produce automaticamente una funzione a due canali efficace. Se i due segnali condividono elementi critici, se la logica non individua le discrepanze oppure se la reazione finale rimane esposta a un singolo guasto non controllato, il semplice conteggio dei sensori dice poco. Per la stessa ragione, un dispositivo certificato può essere adatto a una determinata architettura senza dimostrare da solo il PL raggiunto dalla macchina.
Risoluzione e protocollo non dimostrano l’integrità del segnale
La risoluzione indica la granularità con cui viene rappresentata una posizione o un movimento. Non descrive, da sola, la capacità del sistema di riconoscere un guasto pericoloso. Un valore molto dettagliato può essere perfettamente utile al processo e, nello stesso tempo, insufficiente come prova dell’affidabilità richiesta alla funzione safety.
Anche il protocollo risponde a una domanda differente: stabilisce come viaggiano i dati e come i dispositivi comunicano. Per la sicurezza occorre inoltre sapere come vengono trattati perdita del segnale, ritardi, incoerenze, errori e condizioni fuori campo, e quale reazione produca ciascuna anomalia. La compatibilità di comunicazione non sostituisce la valutazione dell’architettura.
La scelta dell’interfaccia resta importante per tempi, varianti e compatibilità del progetto; l’impatto dei protocolli sull’integrazione della macchina va però tenuto distinto dalla dimostrazione della funzione safety.
Dal sensore agli attuatori: dove si costruisce il PL raggiunto
Il PLr è il risultato richiesto dalla valutazione del rischio; il PL raggiunto dipende invece dalla soluzione concretamente realizzata. Come mostra una sintesi tecnica dell’applicazione della ISO 13849-1, entrano nella valutazione l’architettura, l’affidabilità hardware, il PFHD, il MTTFd e la copertura diagnostica. Questi elementi non possono essere sostituiti con la semplice presenza della parola “safety” nella scheda di un dispositivo.
La ricostruzione della catena deve attraversare almeno cinque passaggi.
- Acquisizione della misura. Occorre verificare che il dispositivo sia documentato per l’impiego previsto e che le ipotesi dichiarate dal produttore corrispondano a montaggio, ambiente e sollecitazioni reali.
- Trasmissione del segnale. Vanno considerate le interfacce attraversate dal dato, le conversioni e il comportamento adottato quando l’informazione manca o diventa incoerente.
- Logica safety. Il controllore deve elaborare il feedback secondo la funzione definita, gestendo le anomalie previste e comandando una reazione appropriata.
- Uscite e controllo della potenza. La decisione della logica deve arrivare ai dispositivi che modificano realmente lo stato degli attuatori. Una misura affidabile non compensa un’uscita incapace di produrre la reazione richiesta.
- Diagnostica e validazione. Le verifiche devono riguardare sensori, logica e dispositivi di controllo della potenza, includendo le condizioni di guasto pertinenti alla funzione.
La copertura diagnostica può quindi estendersi lungo l’intero percorso. Un controllo di plausibilità interno all’encoder è utile soltanto entro il proprio perimetro; non documenta che il dato arrivi correttamente al controllore, che la logica reagisca come previsto o che l’attuatore raggiunga lo stato richiesto.
Come decidere tra encoder safety e architettura ridondante
La decisione diventa più solida quando viene formulata come confronto tra architetture, non come confronto tra cataloghi. Per ogni soluzione candidata bisogna chiedere quali guasti riesca a rilevare, quali restino non diagnosticati e quale effetto producano sulla funzione.
Un encoder con caratteristiche safety è un candidato naturale quando posizione o velocità alimentano direttamente la decisione di sicurezza e la sua documentazione è coerente con il PLr e con l’architettura prevista. Rimane però un elemento della catena: certificato, dati dichiarati e manuale di sicurezza servono a integrarlo correttamente, non a trasferire la conformità del componente all’intera macchina.
Il doppio canale o il sensore indipendente diventano opzioni da esaminare quando il livello richiesto e la strategia diagnostica rendono necessario confrontare informazioni o ridurre la dipendenza da un singolo percorso. Non esiste una soglia generale, basata sulla sola applicazione o sulla risoluzione, che renda automaticamente obbligatoria una di queste configurazioni. La scelta dipende dalla funzione, dal rischio e dal modo in cui l’intera architettura individua i guasti e raggiunge lo stato sicuro.
Prima dell’acquisto, la distinta del componente dovrebbe quindi essere accompagnata da una specifica che indichi funzione safety, PLr, architettura prevista, dati richiesti al produttore, diagnostica, condizioni di accettazione e criteri per le future sostituzioni. Questa documentazione evita che una decisione strutturale venga rinviata al collaudo, quando interfacce e componenti sono già stati congelati.
Domande e risposte
Quali dati tecnici e documenti chiedere al produttore prima di integrare un encoder in una funzione safety?
Servono l’identificazione esatta del modello e delle varianti, il certificato con il relativo campo di applicazione, il manuale di sicurezza, i dati di affidabilità dichiarati e le eventuali limitazioni architetturali. Devono inoltre essere disponibili le condizioni ambientali e di montaggio, le interfacce ammesse, il comportamento in caso di guasto, le diagnostiche supportate e le prescrizioni per configurazione e messa in servizio. Il certificato va letto insieme a questi documenti: da solo non stabilisce che l’integrazione raggiunga il PL richiesto.
Quando la sostituzione di un encoder richiede una nuova verifica o validazione della funzione?
La sostituzione richiede almeno un’analisi d’impatto ogni volta che il feedback appartiene alla funzione di sicurezza. Se cambiano modello, revisione, dati di affidabilità, interfaccia, configurazione, diagnostica, montaggio o modalità di elaborazione del segnale, devono essere ripetute le verifiche interessate e validato nuovamente il comportamento della funzione. Anche quando il ricambio è dichiarato equivalente, l’equivalenza va documentata e devono essere eseguite le prove di accettazione previste dalla procedura della macchina.
Qual è la differenza operativa tra STO, arresto controllato e monitoraggio sicuro della velocità?
Lo STO porta il sistema nella condizione in cui non viene mantenuta la capacità di generare coppia, ma non realizza di per sé una rampa di decelerazione controllata. Nell’arresto controllato il movimento viene prima ridotto secondo una sequenza definita e solo successivamente si raggiunge lo stato finale previsto: la documentazione Siemens relativa a SINAMICS, per esempio, descrive SS1 come una frenatura in rampa seguita dall’attivazione dello STO. Il monitoraggio sicuro della velocità risponde a un’altra esigenza: sorveglia il moto rispetto alla condizione ammessa e deve provocare la reazione definita quando questa viene superata. Le tre funzioni non sono intercambiabili e possono richiedere ruoli differenti per il feedback.
Finché la specifica domanda soltanto quale encoder montare, la decisione è prematura. La domanda utile è quale comportamento sicuro debba essere dimostrato in ciascuna condizione prevista e attraverso quali ingressi, logiche, uscite e diagnostiche. Solo a quel punto il componente può essere scelto come parte di un percorso verificabile, con prove di accettazione e regole di sostituzione già definite.
