Perché la tolleranza ai guasti richiede più del semplice hardware ridondante

Ogni sistema industriale prima o poi subirà dei guasti. I sensori vanno fuori taratura, le alimentazioni si deteriorano, i collegamenti di comunicazione diventano instabili e i componenti meccanici si usurano sotto carichi ripetuti. Lo scopo dell'ingegneria della tolleranza ai guasti non è quindi creare apparecchiature che non possano mai guastarsi. Il suo scopo è garantire che i guasti prevedibili non si trasformino immediatamente in guasti incontrollati del sistema.

Un sistema tollerante ai guasti può continuare a fornire una funzione accettabile dopo che uno o più componenti sono diventati indisponibili. In alcune applicazioni, il sistema deve mantenere la produzione completa. In altre, una capacità ridotta è accettabile fino a quando la manutenzione non ripristina il canale guasto. I sistemi critici per la sicurezza possono invece passare a uno stato sicuro controllato quando il funzionamento continuato creerebbe un rischio inaccettabile.

I componenti ridondanti fanno spesso parte di questa strategia, ma la sola duplicazione non dimostra la tolleranza ai guasti. Due controllori possono dipendere comunque da un'unica alimentazione, da un unico switch di rete o da un'unica configurazione software. Due trasmettitori possono condividere la stessa linea di impulso e guastarsi a causa della stessa ostruzione. L'analisi dell'affidabilità deve quindi esaminare l'architettura completa, comprese le dipendenze non immediatamente visibili in un elenco delle apparecchiature.

Cinque metodi sono particolarmente utili per questo lavoro. L'analisi dell'albero dei guasti esamina come combinazioni di guasti possano produrre un evento principale definito. L'analisi dei modi e degli effetti dei guasti studia come possano guastarsi i singoli componenti e come tali guasti influenzino il sistema nel suo complesso. La simulazione Monte Carlo esplora l'incertezza in molti possibili scenari operativi e di guasto, mentre l'analisi delle cause principali indaga perché si sia verificato un evento reale. I modelli di Markov descrivono come i sistemi riparabili passino nel tempo tra stati integri, degradati, guasti e ripristinati.

Figura 1. I sistemi industriali non possono evitare ogni guasto, ma un'ingegneria dell'affidabilità rigorosa può impedire che molti guasti si trasformino in guasti completi.

Affidabilità, disponibilità, sicurezza e manutenibilità non sono la stessa cosa

La terminologia dell'affidabilità viene spesso usata in modo impreciso, causando confusione durante le revisioni di progettazione. L'affidabilità descrive la probabilità che un'apparecchiatura svolga la funzione richiesta per un periodo definito. La disponibilità descrive se l'apparecchiatura è pronta quando il processo ne ha bisogno. Un sistema può guastarsi occasionalmente e mantenere comunque un'elevata disponibilità quando le riparazioni sono rapide e i pezzi di ricambio sono immediatamente accessibili.

La manutenibilità descrive l'efficacia con cui un sistema guasto può essere diagnosticato e ripristinato. La sicurezza descrive se i guasti rimangono entro limiti di rischio accettabili per il personale, l'ambiente e le apparecchiature. Queste proprietà si influenzano a vicenda, ma il miglioramento di una non migliora automaticamente tutte le altre. Un arresto protettivo può ridurre la disponibilità produttiva, migliorando al contempo in modo significativo la sicurezza dell'impianto.

La tolleranza ai guasti si colloca trasversalmente a queste discipline. Dipende dalla ridondanza, dalla diagnostica, dall'isolamento, dalla capacità di riparazione e dal degrado controllato. Dipende inoltre da una definizione chiara della funzione richiesta. Gli ingegneri non possono determinare se un sistema è tollerante ai guasti finché non sanno quali prestazioni devono rimanere dopo ciascun guasto credibile.

Un sistema di protezione del compressore, ad esempio, potrebbe dover mantenere la capacità di sgancio di emergenza dopo il guasto di un sensore. Un sistema di controllo del processo potrebbe dover mantenere soltanto un funzionamento stabile mentre un controllore viene sostituito. Uno schema di protezione elettrica potrebbe richiedere canali indipendenti, in modo che un singolo guasto comune non possa disabilitare sia la protezione primaria sia quella di riserva. Le tecniche di affidabilità aiutano gli ingegneri a tradurre questi requisiti in progetti verificabili.

Scegliere un metodo in base alla domanda ingegneristica

Le cinque tecniche di affidabilità affrontano parti diverse dello stesso problema. L'FTA inizia con un evento indesiderato del sistema e procede a ritroso verso i guasti che potrebbero causarlo. L'FMEA inizia dai componenti o dalle funzioni e procede in avanti attraverso le conseguenze di ciascuna modalità di guasto. La simulazione Monte Carlo studia l'effetto dell'incertezza ripetendo il modello del sistema in molte condizioni generate casualmente.

L'RCA inizia normalmente dopo un incidente reale, utilizzando le evidenze per distinguere i sintomi visibili dalle cause tecniche e organizzative sottostanti. La modellazione di Markov si concentra sugli stati del sistema e sui tassi con cui il sistema passa dall'uno all'altro. È particolarmente utile quando la riparazione, il funzionamento in standby, le prestazioni degradate e la copertura diagnostica influenzano fortemente la disponibilità.

La scelta corretta dipende dalla domanda a cui si deve rispondere. Un team che indaga su come potrebbe verificarsi una perdita totale del raffreddamento inizierà generalmente con l'FTA. Un team di progettazione che esamina ogni possibile guasto di trasmettitori, controllori e valvole trarrà maggior beneficio dall'FMEA. Un responsabile degli asset che confronta intervalli di manutenzione incerti può utilizzare una simulazione Monte Carlo, mentre un ingegnere dell'affidabilità che calcola la disponibilità a lungo termine di una coppia ridondante di controllori potrebbe preferire un modello di Markov.

Questi metodi sono complementari, non intercambiabili. Un'FMEA può identificare modalità di guasto che in seguito diventano eventi di base all'interno di un albero dei guasti. I risultati di un'RCA possono correggere ipotesi di guasto irrealistiche in un modello di Markov. Una simulazione Monte Carlo può verificare in che modo probabilità incerte influenzino le conclusioni tratte dall'FTA o dalla pianificazione della manutenzione.

L'analisi dell'albero dei guasti inizia dalla conseguenza

L'analisi dell'albero dei guasti è un metodo deduttivo che inizia con un evento indesiderato chiaramente definito. Questo evento è chiamato evento superiore. Esempi appropriati includono la perdita totale dell'acqua di alimentazione della caldaia, il mancato funzionamento della funzione di sgancio della turbina, la perdita completa della comunicazione con il controllore o un aumento incontrollato della pressione all'interno di un reattore. La definizione deve essere sufficientemente specifica da consentire un'analisi significativa.

Un evento principale descritto semplicemente come «guasto del sistema» è solitamente troppo vago. Non definisce quale funzione sia venuta meno, quanto sia durato il guasto né quale stato operativo fosse applicabile. Una definizione migliore potrebbe essere «perdita di tutta la portata dell'acqua di raffreddamento per più di sessanta secondi durante la produzione normale». Questa formulazione fornisce un confine chiaro per l'analisi.

Una volta definito l'evento principale, il team identifica le condizioni immediate che potrebbero produrlo. Tali condizioni vengono scomposte in eventi di livello inferiore finché l'analisi non raggiunge guasti di base dei componenti, disturbi esterni o azioni umane. Le porte logiche collegano gli eventi e descrivono come si combinano. Le porte OR indicano che uno qualsiasi degli eventi elencati può produrre l'evento di livello superiore, mentre le porte AND richiedono che si verifichino contemporaneamente diversi eventi.

L'albero completato fornisce una rappresentazione visiva della logica dei guasti. Consente agli specialisti elettrici, meccanici, della strumentazione, di processo, della manutenzione e della sicurezza di esaminare lo stesso sistema da una prospettiva comune. Questo modello condiviso è uno dei maggiori punti di forza pratici dell'FTA. Rende più facile mettere in discussione le ipotesi nascoste prima che vengano incorporate nella progettazione.

Figura 2. Un albero dei guasti procede a ritroso da un evento principale definito e identifica le combinazioni di guasti di livello inferiore che possono produrlo.

Sviluppare un albero dei guasti passo dopo passo

Il primo compito pratico consiste nello stabilire i confini del sistema. Gli ingegneri devono decidere quali apparecchiature, utenze, software, operatori e servizi esterni rientrano nell'analisi. Uno studio del sistema di raffreddamento può includere pompe, valvole, distribuzione dell'alimentazione, strumentazione e logica di controllo. Potrebbe inoltre essere necessario includere la fonte d'acqua, le condizioni ambientali e la risposta dell'operatore quando questi fattori possono influenzare l'evento principale.

Il team identifica quindi le cause immediate. La perdita totale del raffreddamento può verificarsi perché tutte le pompe diventano indisponibili, perché il collettore di alimentazione comune si ostruisce oppure perché le valvole di isolamento si chiudono in modo errato. Ogni causa immediata viene ulteriormente scomposta. L'indisponibilità di una pompa può derivare da un guasto del motore, dal grippaggio di un cuscinetto, dalla perdita di aspirazione, dal guasto del controller o dalla perdita dell'alimentazione elettrica.

Il processo continua finché un'ulteriore scomposizione non migliorerebbe la decisione. Gli eventi di livello più basso sono trattati come eventi di base e possono ricevere probabilità o tassi di guasto. La struttura logica può quindi essere valutata qualitativamente o quantitativamente. Anche quando non sono disponibili dati numerici accurati, l'albero può comunque rivelare singoli punti di guasto e dipendenze condivise impreviste.

Un'FTA quantitativa combina le probabilità degli eventi in base alla struttura delle porte logiche. Il calcolo può sembrare semplice, ma le ipotesi di indipendenza richiedono un'attenta revisione. Due eventi che condividono la stessa fonte di alimentazione, lo stesso ambiente, la stessa attività di manutenzione o lo stesso difetto software non sono pienamente indipendenti. Ignorare queste relazioni può far apparire un progetto ridondante significativamente più sicuro di quanto non sia in realtà.

Gli insiemi di taglio minimi mostrano le combinazioni più pericolose

Un insieme di taglio è una combinazione di eventi di base che produce l'evento apicale. Un insieme di taglio minimo non contiene eventi superflui, il che significa che la rimozione di un evento qualsiasi impedirebbe il verificarsi dell'evento apicale. Queste combinazioni aiutano gli ingegneri a identificare i percorsi di guasto più brevi e importanti. Sono particolarmente utili quando un grande albero dei guasti contiene centinaia di eventi.

Un insieme di taglio minimo costituito da un singolo evento indica che un guasto può causare direttamente l'evento apicale. Tali risultati meritano normalmente un'attenzione immediata nella progettazione. Il team può aggiungere ridondanza, migliorare l'isolamento, fornire un'alimentazione separata o introdurre un ulteriore livello di protezione. Gli insiemi di taglio composti da due o tre eventi rappresentano spesso guasti all'interno di architetture ridondanti.

Non tutti gli insiemi di taglio brevi comportano lo stesso rischio. Una combinazione di due eventi che coinvolge guasti frequenti può essere più significativa di un singolo evento esterno estremamente raro. Anche il tempo di rilevamento e riparazione influisce sull'importanza. Un guasto latente che rimane non rilevato per mesi crea un periodo di esposizione molto più lungo rispetto a un guasto rilevato e riparato immediatamente.

Il software FTA può classificare gli insiemi di taglio in base al contributo calcolato. Tuttavia, gli ingegneri dovrebbero comunque esaminare il significato fisico alla base dei numeri. Una probabilità matematicamente bassa potrebbe basarsi su ipotesi deboli o dati generici che non riflettono l'installazione effettiva. Il giudizio ingegneristico resta necessario per tutta l'analisi.

Esempio: ridondanza delle pompe di alimento delle caldaie che non è realmente indipendente

Si consideri una centrale elettrica che utilizza due pompe di alimento delle caldaie. Ciascuna pompa può mantenere la portata minima richiesta, quindi il sistema sembra in grado di tollerare il guasto di una pompa. Un semplice conteggio delle apparecchiature suggerisce una ridondanza completa. L'albero dei guasti può rivelare una realtà diversa una volta incluse le dipendenze condivise.

Entrambi i motori delle pompe possono ricevere alimentazione dallo stesso bus elettrico. Entrambe le pompe possono aspirare da un unico collettore di aspirazione, dipendere dallo stesso sistema di controllo o ricevere comandi da una sola misura di livello. Un singolo guasto del bus, l'ostruzione del collettore di aspirazione o un segnale comune errato potrebbero quindi disabilitare entrambe le pompe contemporaneamente. L'apparente ridondanza delle due pompe non proteggerebbe da questi guasti comuni.

L’analisi può portare a diversi miglioramenti pratici. Alimentazioni elettriche separate possono ridurre la perdita comune di alimentazione. Misure di livello basate su tecnologie diverse possono ridurre la dipendenza da un’unica tecnologia di trasmettitori. Percorsi di controllo indipendenti, una migliore gestione manuale e un monitoraggio più efficace dell’aspirazione possono rafforzare l’architettura senza aggiungere necessariamente un’altra pompa completa.

Questo esempio mostra perché l’FTA è più utile del semplice conteggio dei dispositivi ridondanti. Valuta se i dispositivi rimangono indipendenti nelle reali condizioni operative. Identifica inoltre dove una maggiore complessità offre una protezione effettiva e dove crea soltanto l’apparenza di una protezione.

Dove l’Analisi dell’Albero dei Guasti Funziona Bene e Dove No

L’FTA è particolarmente efficace per le funzioni di sicurezza, i sistemi di protezione, le reti di distribuzione elettrica, le reti di comunicazione e altre applicazioni con un evento indesiderato chiaramente definito. La sua struttura visiva supporta le revisioni della progettazione e le discussioni normative. Può essere utilizzata qualitativamente per individuare le debolezze o quantitativamente per stimare la probabilità dell’evento principale.

Il metodo diventa meno efficace quando l’evento principale è definito in modo inadeguato. Può inoltre diventare difficile da mantenere quando l’albero si amplia fino a comprendere migliaia di eventi. Le sequenze dinamiche, le attività di manutenzione e le variazioni delle condizioni operative possono richiedere porte specializzate o tecniche di modellazione aggiuntive. Un albero dei guasti statico non descrive naturalmente ogni relazione dipendente dal tempo.

Anche le azioni umane richiedono un’attenta valutazione. La probabilità di una risposta dell’operatore dipende dalla qualità degli allarmi, dalla progettazione delle procedure, dalla formazione, dal carico di lavoro, dal tempo disponibile e dalle condizioni dell’interfaccia. Assegnare un’unica probabilità generica di errore umano può nascondere queste differenze. Le analisi importanti dovrebbero coinvolgere specialisti di fattori umani quando l’azione dell’operatore è determinante per l’esito.

L’FTA è quindi più efficace quando viene utilizzata nell’ambito di un programma di affidabilità più ampio. L’FMEA può fornire i modi di guasto dettagliati dei componenti, mentre i metodi di Markov o Monte Carlo possono gestire riparazioni, sequenze e incertezza. Nessun singolo albero dovrebbe essere considerato una rappresentazione completa di ogni comportamento del sistema.

L’Analisi dei Modi e degli Effetti dei Guasti Inizia dal Componente

L’Analisi dei Modi e degli Effetti dei Guasti adotta un approccio induttivo. Invece di partire da un evento principale, il team inizia da un componente, una funzione o una fase del processo. Quindi si chiede in che modo quel componente potrebbe guastarsi e quale effetto avrebbe ogni guasto, localmente e sull’intero sistema. Questo approccio rende l’FMEA particolarmente utile durante la progettazione e la revisione delle apparecchiature.

Un trasmettitore di pressione può guastarsi in diversi modi. Il suo segnale può variare verso l’alto, variare verso il basso, bloccarsi su un valore, diventare instabile o scomparire completamente. Ogni modalità produce una conseguenza operativa diversa. Una lettura alta può causare un arresto non necessario, mentre una lettura bassa può nascondere una condizione di pressione pericolosa.

L’FMEA obbliga il team a descrivere queste differenze invece di registrare soltanto “guasto del trasmettitore”. Esamina inoltre i controlli di prevenzione e rilevamento esistenti. L’analisi può individuare sistemi diagnostici, logiche di confronto, test di verifica, allarmi, bypass o controlli da parte dell’operatore che riducono la conseguenza. Una rilevazione debole diventa spesso importante quanto la modalità di guasto originaria.

Figura 3. L’FMEA valuta le singole modalità di guasto, i relativi effetti, la loro gravità e i controlli disponibili per prevenirle o rilevarle.

Cosa dovrebbe contenere un foglio di lavoro FMEA efficace

Un utile foglio di lavoro FMEA parte dall’elemento e dalla sua funzione richiesta. La modalità di guasto descrive come la funzione possa perdersi, degradarsi o essere eseguita in modo errato. L’effetto locale descrive ciò che accade a livello del componente, mentre l’effetto sul sistema descrive la conseguenza operativa o di sicurezza più ampia. Le cause e i meccanismi vengono registrati separatamente dagli effetti.

Il foglio di lavoro documenta anche i controlli esistenti. I controlli preventivi riducono la probabilità che si verifichi il guasto. I controlli di rilevamento individuano il guasto prima che produca una conseguenza inaccettabile. Tra gli esempi rientrano l’autodiagnostica, il confronto tra segnali ridondanti, le soglie di allarme, i test di verifica, le ispezioni e la manutenzione predittiva.

Molte organizzazioni assegnano valori di gravità, probabilità di accadimento e rilevabilità. Talvolta questi valori vengono moltiplicati per ottenere un numero di priorità del rischio. Il numero può aiutare a stabilire le priorità, ma non dovrebbe mai sostituire il giudizio tecnico. Combinazioni diverse possono produrre lo stesso punteggio anche quando le conseguenze sono fondamentalmente diverse.

Un guasto catastrofico raro può meritare più attenzione di un inconveniente minore frequente, anche quando i punteggi calcolati appaiono simili. La gravità dovrebbe quindi essere esaminata separatamente. I team dovrebbero inoltre dare priorità alle azioni che eliminano il meccanismo di guasto o ne riducono la conseguenza, invece di affidarsi soltanto a ulteriori ispezioni.

Esempio: ingressi PLC ridondanti con una debolezza condivisa

Si considerino due canali di ingresso digitali che monitorano un unico interruttore di campo di emergenza. L’architettura appare ridondante perché due ingressi PLC ricevono il segnale. Un’FMEA verifica se l’intero percorso del segnale sia realmente indipendente. Prende in considerazione il contatto di campo, il cablaggio, l’alimentazione degli ingressi, i gruppi morsettiera, i moduli, la logica e il comportamento diagnostico.

Le possibili modalità di guasto includono un circuito aperto, un cortocircuito, un contatto saldato, un canale bloccato a livello alto, un canale bloccato a livello basso o la perdita dell’alimentazione condivisa degli ingressi. L’analisi valuta inoltre se viene rilevato il disaccordo tra i canali. Se entrambi i canali condividono un contatto di campo e un cavo, molti guasti credibili interessano entrambi i canali simultaneamente.

La revisione può mostrare che i moduli di ingresso duplicati offrono una protezione aggiuntiva limitata. Potrebbero essere necessari contatti separati, circuiti di campo monitorati, percorsi di alimentazione indipendenti o principi di rilevamento diversi. La procedura di prova periodica deve inoltre verificare l’intera catena del segnale, anziché testare solo il modulo PLC.

Per le architetture di protezione, gli ingegneri possono anche valutare moduli di sicurezza industriali idonei, progettati per la copertura diagnostica, la ridondanza e un comportamento controllato in caso di guasto. La selezione dell’hardware deve comunque seguire l’intero ciclo di vita della sicurezza e non può sostituire un’analisi specifica dell’applicazione.

La FMEA di progetto e la FMEA di processo affrontano rischi diversi

La FMEA di progetto studia il prodotto o il sistema progettato. Esamina se l’architettura, i componenti, i materiali e le funzioni di controllo selezionati possano funzionare come previsto. Il metodo viene comunemente applicato durante lo sviluppo del concept, la progettazione dettagliata e le modifiche al progetto. È più utile prima che il progetto diventi costoso da modificare.

La FMEA di processo studia le attività di produzione, assemblaggio, installazione, messa in servizio o manutenzione. Un quadro elettrico può avere una progettazione elettrica corretta, ma il processo di installazione può comunque introdurre morsetti allentati, polarità invertite, valori nominali dei fusibili errati o un’identificazione errata dei cavi. Le attività di manutenzione possono introdurre firmware non corretto, parti di ricambio inadatte, allarmi disattivati o bypass lasciati attivi.

Queste due forme di FMEA dovrebbero supportarsi a vicenda. I controlli di progettazione possono ridurre la sensibilità all’installazione, mentre i controlli di processo possono prevenire errori di esecuzione che la progettazione non è in grado di eliminare. Esaminare solo la progettazione dell’apparecchiatura lascia senza risposta molti rischi del ciclo di vita. Esaminare solo il processo di lavoro può nascondere debolezze integrate nell’architettura originale.

Per i sistemi di automazione critici, entrambe le analisi dovrebbero essere aggiornate dopo modifiche significative. La sostituzione di un controllore, la migrazione della rete, l’aggiornamento del software o una modifica della procedura di prova periodica possono introdurre nuovi modi di guasto. I fogli di lavoro storici non dovrebbero rimanere congelati mentre l’impianto si evolve intorno a essi.

La FMECA aggiunge una valutazione della criticità più formale

L’Analisi dei Modi, degli Effetti e della Criticità dei Guasti amplia la struttura dell’FMEA aggiungendo calcoli formali della criticità. Il metodo può utilizzare tassi di guasto dei componenti, esposizione operativa, fasi della missione, categorie di gravità e probabilità condizionate. È utile quando un sistema di grandi dimensioni presenta numerosi modi di guasto e le risorse ingegneristiche devono essere indirizzate verso i fattori più significativi.

I calcoli di criticità dipendono fortemente dalla qualità dei dati. I database generici dei tassi di guasto forniscono un punto di partenza, ma potrebbero non riflettere l’installazione reale. Temperatura, vibrazioni, contaminazione, stress elettrico, qualità della manutenzione e ciclo di funzionamento influenzano tutti le prestazioni effettive. Quando è disponibile una cronologia operativa sufficiente, le evidenze specifiche dell’impianto dovrebbero sostituire le ipotesi generiche.

L'analisi dovrebbe inoltre distinguere tra i guasti rilevati immediatamente e quelli che rimangono nascosti. Un guasto latente di un sistema in standby potrebbe non influire sulla produzione finché non si guasta un altro componente o finché non si verifica una richiesta. La lunga esposizione nascosta può rendere molto importante un guasto relativamente poco frequente. È pertanto necessario includere gli intervalli di rilevamento e l'efficacia dei test di verifica.

L'FMECA è più utile quando i suoi risultati portano ad azioni di progettazione o manutenzione. Una tabella di classificazione complessa ha poco valore se non influenza l'architettura, i ricambi, la diagnostica, i test o le procedure operative. Lo scopo rimane la riduzione pratica del rischio, non il calcolo fine a se stesso.

Dove l'FMEA funziona bene e dove può trarre in inganno

L'FMEA fornisce una revisione disciplinata, componente per componente. È relativamente facile da spiegare e favorisce la partecipazione del personale di ingegneria, operativo, di manutenzione, qualità e sicurezza. Il registro delle azioni risultante può essere collegato direttamente a modifiche progettuali, ispezioni, diagnostica e miglioramenti della manutenzione.

Il metodo può diventare ripetitivo quando viene applicato a sistemi molto grandi. I team possono dedicare tempo eccessivo a documentare modalità di guasto di scarso valore, trascurando al contempo le interazioni del sistema. L'FMEA tradizionale tende inoltre a esaminare un guasto alla volta. I guasti multipli simultanei e gli eventi dipendenti dalla sequenza potrebbero non emergere chiaramente.

I sistemi di valutazione creano un altro rischio. I team possono modificare i punteggi per ottenere una priorità desiderata o trattare il numero finale come più obiettivo del giudizio sottostante. Un punteggio basso non dimostra che un guasto sia accettabile. Gli eventi ad alta gravità, i guasti per causa comune e i requisiti normativi dovrebbero essere sottoposti a una revisione separata.

La qualità dell'FMEA dipende dalle persone che la eseguono. Un foglio di lavoro preparato da un progettista può non considerare aspetti della realtà operativa noti agli operatori e ai tecnici. Gli studi più solidi combinano le conoscenze progettuali con la storia effettiva della manutenzione e l'esperienza operativa.

La simulazione Monte Carlo trasforma l'incertezza in una distribuzione

I calcoli di affidabilità industriale spesso includono dati di ingresso incerti. La durata dei componenti varia, la durata delle riparazioni cambia, i tempi di consegna dei ricambi sono imprevedibili e le sollecitazioni ambientali influenzano il comportamento dei guasti. Un singolo valore medio non può sempre rappresentare queste variazioni. La simulazione Monte Carlo affronta questo problema attraverso campionamenti casuali ripetuti.

L'ingegnere costruisce innanzitutto un modello del sistema e assegna distribuzioni di probabilità alle variabili incerte. La simulazione genera quindi molte combinazioni possibili. Un'esecuzione può ipotizzare che una pompa si guasti dopo 8.000 ore e venga riparata entro quattro ore. Un'altra può produrre un guasto più tardivo, ma una riparazione molto più lunga perché il ricambio necessario non è disponibile.

Dopo migliaia o milioni di esecuzioni, i risultati formano una distribuzione. Il modello può stimare i tempi di inattività attesi, la perdita di produzione, la disponibilità del sistema, la probabilità di successo della missione, la domanda di parti di ricambio o i costi di manutenzione. Può inoltre mostrare la probabilità di risultati estremi che scomparirebbero all'interno di un unico valore medio.

Figura 4. La simulazione Monte Carlo valuta numerosi scenari di guasto e riparazione generati casualmente per stimare un intervallo di possibili risultati.

Costruzione di un modello Monte Carlo affidabile per l'analisi dell'affidabilità

La qualità della simulazione dipende dal modello del sistema. Il modello deve rappresentare componenti, regole operative, distribuzioni dei guasti, comportamento delle riparazioni, dipendenze, logica di standby e risorse per la manutenzione. Può includere anche condizioni meteorologiche, domanda di produzione, ritardi logistici e risposta umana quando questi fattori influenzano le prestazioni del sistema.

Ogni esecuzione simulata segue il sistema nel tempo. I componenti si guastano secondo distribuzioni campionate, le riparazioni iniziano quando le risorse diventano disponibili e il modello registra se il sistema rimane operativo, degradato o indisponibile. La ripetizione del processo produce stime per diverse misure delle prestazioni.

La convalida è essenziale. Il team dovrebbe confrontare il modello con calcoli semplificati, casi operativi noti e risultati storici dell'impianto. Un risultato inatteso dovrebbe essere esaminato, anziché accettato solo perché proviene da un software. Una simulazione visivamente impressionante può comunque essere errata quando la logica sottostante è incompleta.

L'analisi di sensibilità aiuta a identificare quali ipotesi determinano il risultato. Se il tempo di riparazione ha un effetto molto maggiore rispetto al tasso di guasto, la gestione potrebbe ottenere maggiori vantaggi migliorando la disponibilità dei ricambi e la rapidità della diagnostica. Se domina la probabilità di causa comune, l'aggiunta di altri componenti identici potrebbe offrire pochi benefici.

Selezione delle distribuzioni di probabilità corrispondenti al meccanismo di guasto

Una distribuzione esponenziale presuppone un tasso di guasto costante. Può essere appropriata per alcuni componenti elettronici durante la loro vita utile. Una distribuzione di Weibull è più flessibile e può rappresentare guasti iniziali, guasti casuali o fenomeni di usura. Le distribuzioni lognormali sono spesso utili per le durate delle riparazioni e per i processi influenzati da diversi fattori moltiplicativi.

La scelta dovrebbe riflettere il meccanismo fisico, non la praticità del software. Un guasto del cuscinetto dovuto all'usura non segue naturalmente lo stesso comportamento di un errore di comunicazione casuale. Utilizzare un tasso di guasto costante per entrambi può distorcere le previsioni a lungo termine. Prima di selezionare la distribuzione, gli ingegneri dell'affidabilità dovrebbero esaminare lo storico operativo e i meccanismi di guasto.

I dati storici richiedono spesso una fase di pulizia. I sistemi di manutenzione possono confondere una sostituzione programmata con un guasto funzionale. Le date dei guasti possono essere registrate quando è stato aperto l’ordine di lavoro anziché quando si è verificato il problema. Anche i nomi degli asset, le ore di funzionamento e i codici dei guasti possono essere incoerenti tra i diversi siti.

La disponibilità limitata di dati non impedisce l’analisi, ma l’incertezza dovrebbe rimanere visibile. Il giudizio degli esperti, le informazioni dei fornitori e i database di settore possono supportare le stime iniziali. Il modello dovrebbe testare un intervallo realistico invece di presentare un’unica ipotesi incerta come un fatto preciso.

Esempio: disponibilità di una stazione con tre compressori

Si consideri una stazione con tre compressori per gas. Due unità sono necessarie per la produzione a pieno regime, mentre la terza fornisce capacità di riserva. Ogni macchina ha ore di funzionamento, storico della manutenzione e prestazioni di raffreddamento differenti. È possibile eseguire una sola riparazione importante alla volta perché la stazione dispone di un’unica squadra specializzata di manutenzione.

La consegna dei cuscinetti di ricambio richiede diversi giorni e i guasti del sistema di raffreddamento diventano più frequenti durante i periodi di temperatura ambiente elevata. Queste interazioni sono difficili da rappresentare con una sola semplice equazione di disponibilità. Un modello Monte Carlo può simulare guasti dei compressori, durate delle riparazioni, periodi meteorologici, disponibilità dei tecnici e ritardi logistici.

I risultati possono mostrare la disponibilità a piena capacità, il funzionamento a capacità ridotta e il fermo completo della stazione. La direzione può confrontare investimenti alternativi. Tenere a magazzino cuscinetti aggiuntivi può ridurre i tempi di fermo estremi in modo più efficace rispetto all’aggiunta di un altro tecnico di manutenzione generico. Migliorare l’affidabilità del raffreddamento può offrire un valore maggiore rispetto alla sostituzione di un compressore ancora in buone condizioni.

Il modello può anche testare gli intervalli di manutenzione. Intervalli preventivi più brevi possono ridurre i guasti, ma aumentare i tempi di fermo programmati e gli errori indotti dalla manutenzione. La simulazione consente di valutare entrambi gli effetti all’interno dello stesso modello operativo.

Dove la simulazione Monte Carlo funziona bene e dove fallisce

I metodi Monte Carlo sono potenti quando interagiscono molte variabili incerte. Possono rappresentare logistica complessa, code di riparazione, effetti meteorologici, domanda produttiva e decisioni di manutenzione. La distribuzione risultante fornisce più informazioni di una singola media. Supporta inoltre decisioni basate sul rischio mostrando la probabilità di risultati gravi ma poco frequenti.

Il principale punto debole è la credibilità del modello. Una simulazione complessa può creare un falso senso di sicurezza perché i suoi risultati sembrano numericamente precisi. Il programma calcola solo le conseguenze delle ipotesi inserite dall’analista. Dipendenze mancanti o distribuzioni irrealistiche possono produrre risultati fuorvianti.

La simulazione richiede inoltre un numero sufficiente di esecuzioni per ottenere stime stabili. Le probabilità di eventi rari possono richiedere tecniche di campionamento specializzate, poiché una simulazione casuale ordinaria richiederebbe un numero di esecuzioni impraticabilmente elevato. Dovrebbero essere riportati gli intervalli di confidenza, affinché gli utenti comprendano l'incertezza statistica.

Il metodo è quindi più efficace quando la logica del modello, le fonti dei dati e i limiti rimangono trasparenti. Le decisioni sull'affidabilità non dovrebbero basarsi su un grafico le cui ipotesi non possano essere spiegate al personale operativo e tecnico.

L'analisi delle cause radice inizia dopo l'evento

L'analisi delle cause radice indaga perché si sia verificato un guasto effettivo, un problema di qualità o un evento di sicurezza. Va oltre l'identificazione del componente danneggiato. Un motore può arrestarsi perché un cuscinetto si è grippato, ma la sostituzione del cuscinetto ripristina soltanto il funzionamento. L'indagine deve determinare perché il cuscinetto sia arrivato a quella condizione.

Le cause più profonde possono includere contaminazione, lubrificazione errata, stoccaggio inadeguato, danni di installazione, carico di processo eccessivo o ispezioni omesse. Anche le condizioni organizzative possono contribuire. Le attività di manutenzione potrebbero essere state eliminate, i pezzi di ricambio potrebbero non essere stati idonei oppure la pressione produttiva potrebbe aver ritardato gli interventi correttivi.

L'RCA separa quindi i sintomi, le cause fisiche dirette, le condizioni contribuenti e le debolezze sistemiche sottostanti. Questa distinzione impedisce all'organizzazione di considerare ogni riparazione una soluzione permanente. Produce inoltre evidenze utili a migliorare future FMEA, FTA, la pianificazione della manutenzione e le procedure operative.

Figura 5. L'RCA segue un guasto oltre il sintomo visibile e identifica le condizioni tecniche e organizzative che ne hanno consentito il verificarsi.

Le prove devono essere preservate prima che l'impianto torni alla normalità

Le prove industriali possono scomparire rapidamente. Gli operatori possono reimpostare gli allarmi, i tecnici possono sostituire i moduli e le condizioni di processo possono cambiare. I registri del controllore possono sovrascrivere gli eventi precedenti, mentre i componenti danneggiati possono essere scartati prima dell'esame. Un processo RCA disciplinato inizia quindi dalla conservazione delle prove.

Il team dovrebbe raccogliere trend dello storico, elenchi degli allarmi, registri degli eventi del controllore, registrazioni dei relè, ordini di lavoro, fotografie, parti danneggiate, versioni del software, file di configurazione e osservazioni degli operatori. Ogni elemento dovrebbe essere identificato in base alla fonte e all'orario. Le prove fisiche dovrebbero rimanere sotto controllo finché l'indagine non stabilisce se sia necessario un ulteriore esame.

La sincronizzazione temporale merita particolare attenzione. Un controllore, uno storico, un relè di protezione, un server e un sistema di manutenzione possono registrare timestamp diversi. Gli investigatori devono correggere queste differenze prima di ricostruire la sequenza degli eventi. In caso contrario, un allarme successivo potrebbe erroneamente apparire come l'evento iniziale.

Le interviste agli operatori dovrebbero essere completate tempestivamente, ma con attenzione. Le persone possono ricordare sequenze e contesti che i sistemi automatizzati non hanno registrato. Le loro dichiarazioni dovrebbero essere trattate come evidenze, non come accuse. L’obiettivo è comprendere l’ambiente operativo in cui sono state prese le decisioni.

Costruire la cronologia degli eventi prima di chiedersi perché

Una cronologia solida separa i fatti verificati dall’interpretazione. Registra ciò che è accaduto prima, durante e dopo il guasto. Ogni evento dovrebbe essere collegato a una fonte, come un valore dello storico, una registrazione degli allarmi, un intervento di manutenzione, una fotografia o una dichiarazione di un testimone. Lacune e incoerenze dovrebbero rimanere visibili.

Il primo allarme visualizzato all’operatore non è sempre il primo evento fisico. Le raffiche di allarmi possono nascondere la condizione iniziale sotto centinaia di messaggi secondari. I dati ad alta risoluzione della sequenza degli eventi possono mostrare che l’instabilità della pressione, un disturbo dell’alimentazione o una perdita di comunicazione sono iniziati prima. La cronologia aiuta a distinguere la causa dalla conseguenza.

Una volta compresa la sequenza, il team può utilizzare strumenti come i cinque perché, i diagrammi a lisca di pesce, l’analisi delle barriere, l’analisi dei cambiamenti o i diagrammi dei fattori causali. Gli eventi semplici possono essere spiegati attraverso una breve catena causale. Gli incidenti complessi di solito coinvolgono diverse condizioni tecniche e organizzative interagenti.

L’indagine non dovrebbe fermarsi dopo aver individuato una spiegazione plausibile. Le ipotesi alternative dovrebbero essere verificate sulla base delle evidenze. Le supposizioni non supportate dovrebbero rimanere identificate come tali, invece di essere presentate come cause confermate.

Esempio: guasti ripetuti di un azionamento a velocità variabile

In uno stabilimento si verificano guasti ripetuti di un azionamento a velocità variabile che controlla un trasportatore. Dopo ogni evento, la manutenzione sostituisce l’azionamento e la produzione torna alla normalità. Diversi mesi dopo, un altro azionamento si guasta. La sostituzione ripetuta suggerisce che il problema potrebbe non risiedere esclusivamente nell’azionamento.

Il team RCA confronta le date dei guasti con i dati ambientali e di manutenzione. La maggior parte dei guasti si è verificata durante i periodi estivi più caldi. Le tendenze della temperatura dell’armadio mostrano un funzionamento prolungato al di sopra dell’intervallo preferito. L’ispezione rivela filtri intasati, flusso d’aria limitato e un forte accumulo di polvere intorno al percorso di raffreddamento.

La cronologia della manutenzione mostra che la pulizia regolare dei filtri è stata rimossa dal programma di manutenzione preventiva dopo una variazione dell’organico. L’azionamento è il componente guasto, ma la temperatura eccessiva dell’armadio è la causa fisica diretta. La ventilazione limitata e l’assenza dell’attività di manutenzione sono cause contribuenti e organizzative.

L’azione correttiva dovrebbe quindi andare oltre la semplice sostituzione di un altro azionamento. Lo stabilimento può ripristinare la manutenzione dei filtri, installare allarmi di temperatura, migliorare il raffreddamento dell’armadio e riesaminare la progettazione dell’involucro. L’efficacia dovrebbe essere verificata durante il prossimo periodo di temperature elevate.

Le azioni correttive devono essere collegate a cause verificate

Molti rapporti RCA diventano deboli durante la pianificazione delle azioni correttive. I team possono raccomandare ulteriore formazione senza dimostrare che le conoscenze fossero insufficienti. Possono rivedere le procedure quando il problema reale è una progettazione inadeguata delle apparecchiature. Possono aggiungere ispezioni incapaci di rilevare l’effettivo meccanismo di guasto.

Ogni azione dovrebbe affrontare una causa o una condizione contributiva verificata. Dovrebbe avere un responsabile, una data di completamento e un metodo di verifica definito. L’organizzazione dovrebbe distinguere tra contenimento temporaneo, azione correttiva e azione preventiva a lungo termine. Ripristinare la produzione non equivale a prevenire il ripetersi dell’evento.

L’efficacia deve essere verificata dopo l’implementazione. Un’azione completata non è automaticamente un’azione riuscita. Lo stabilimento dovrebbe verificare se la probabilità di guasto è diminuita, se il nuovo controllo viene utilizzato e se ha introdotto un altro rischio. Questo feedback completa il ciclo di miglioramento dell’affidabilità.

Le indagini più importanti possono richiedere una revisione indipendente. I team strettamente coinvolti nell’evento possono essere influenzati da assunzioni precedenti o da pressioni organizzative. Una revisione esterna o interfunzionale può mettere in discussione l’analisi prima che vengano accettate le conclusioni finali.

L’errore umano raramente è una causa profonda completa

«Errore dell’operatore» ed «errore di manutenzione» compaiono spesso nelle indagini superficiali. Queste etichette descrivono chi ha eseguito l’azione finale, ma non spiegano perché quell’azione sia diventata probabile. Le persone lavorano all’interno di interfacce, procedure, livelli di organico, esigenze produttive, sistemi di formazione e configurazioni delle apparecchiature. L’indagine dovrebbe esaminare tutte queste condizioni.

Un operatore può selezionare il comando sbagliato perché due oggetti sullo schermo appaiono quasi identici. Un tecnico può installare il componente sbagliato perché l’identificazione non è coerente. Un supervisore può rimandare la manutenzione perché l’organizzazione premia la produzione ininterrotta senza prevedere una finestra di fermo realistica.

Comprendere queste condizioni non elimina la responsabilità individuale. Impedisce che lo stesso sistema induca un’altra persona a commettere lo stesso errore. Un’indagine incentrata sulle colpe può soddisfare un’immediata esigenza di responsabilità, lasciando però intatta la debolezza sottostante.

Un’RCA efficace esamina il modo in cui il sistema ha influenzato la decisione. Si chiede se gli allarmi fossero comprensibili, se le procedure fossero pratiche, se il carico di lavoro fosse ragionevole e se gli strumenti necessari fossero disponibili. Queste domande producono azioni correttive più efficaci del semplice invito a prestare maggiore attenzione.

Dove l’analisi delle cause profonde funziona bene e dove no

L’RCA trasforma l’esperienza operativa reale in conoscenza preventiva. Può rivelare debolezze di progettazione, lacune nella manutenzione, problemi procedurali e pressioni organizzative che gli studi predittivi non avevano individuato. I suoi risultati possono migliorare i modelli di affidabilità e gli standard dei progetti futuri.

Il metodo è reattivo perché inizia dopo un evento. I settori ad alta criticità non possono basarsi esclusivamente sull'apprendimento dai guasti. Sono ancora necessari metodi proattivi come FMEA e FTA. L'RCA dovrebbe integrarli aggiornando le ipotesi con le prove ricavate dal funzionamento reale.

Le indagini possono inoltre diventare soggettive. Il bias di conferma può indurre i team a favorire la prima spiegazione plausibile. La mancanza di prove può costringere a mantenere incerte le conclusioni. I rapporti solidi distinguono chiaramente tra cause confermate, fattori contribuenti, ipotesi e questioni irrisolte.

Il valore dell'RCA dipende dal seguito dato alle azioni. Un'indagine tecnicamente solida produce pochi benefici quando le azioni vengono ritardate, indebolite o non verificate. L'impegno della direzione è quindi importante quanto la competenza analitica.

I modelli di Markov seguono il sistema attraverso stati mutevoli

La modellazione di Markov rappresenta un sistema attraverso stati operativi definiti. Un sistema semplice può contenere solo uno stato operativo e uno stato di guasto. Un sistema tollerante ai guasti richiede generalmente stati aggiuntivi, come pienamente ridondante, degradato, guasto, in riparazione o in attesa di un ricambio. Le transizioni collegano questi stati.

Un tasso di guasto può portare il sistema dallo stato pienamente operativo a quello degradato. Un altro guasto può farlo passare dallo stato degradato a quello non disponibile. Un tasso di riparazione può riportarlo alla piena operatività. Il modello calcola la probabilità che il sistema si trovi in ciascuno stato nel tempo.

Questa struttura è particolarmente utile per i sistemi riparabili. Può rappresentare la ridondanza, le apparecchiature in standby, la copertura diagnostica, la risposta alla manutenzione e la capacità produttiva parziale. A differenza di una semplice formula di affidabilità, mostra per quanto tempo il sistema può rimanere vulnerabile dopo il primo guasto.

Figura 6. I modelli di Markov descrivono come i sistemi passano tra stati integro, degradato, guasto e riparato.

Un modello a due stati fornisce il principio di base

Il modello di Markov più semplice contiene uno stato operativo e uno stato di guasto. Il tasso di guasto controlla il passaggio dallo stato operativo a quello di guasto. Il tasso di riparazione controlla il ritorno allo stato operativo. Da queste transizioni, il modello può stimare la disponibilità durante un periodo definito o in condizioni stazionarie.

Questo modello è utile per apparecchiature semplici riparabili, ma non descrive pienamente la maggior parte dei sistemi di automazione ridondanti. Un controllore a doppio canale può continuare a funzionare dopo il guasto di un canale. Il sistema rimane funzionale, ma perde la ridondanza. Si trova ora in uno stato degradato, con una maggiore esposizione a un secondo guasto.

L'aggiunta dello stato degradato consente al modello di calcolare con quale frequenza e per quanto tempo il sistema opera senza protezione completa. La rapidità di riparazione diventa fondamentale. Un sistema con componenti affidabili può comunque rimanere in stato degradato per un tempo eccessivo se la diagnosi dei guasti, la consegna dei ricambi o l'approvazione della manutenzione sono lenti.

Il modello può anche distinguere tra guasti rilevati e non rilevati. Un guasto rilevato del canale può attivare una riparazione immediata. Un guasto non rilevato può rimanere nascosto finché non si verifica una richiesta o un altro guasto. La copertura diagnostica modifica la struttura delle transizioni e quindi cambia la disponibilità e il rischio calcolati.

Esempio: una coppia di controller a doppia ridondanza

Si considerino due controller disposti in una coppia ridondante. Lo stato uno rappresenta entrambi i controller funzionanti. Lo stato due rappresenta un controller guasto mentre il secondo mantiene il controllo. Lo stato tre rappresenta la perdita di entrambi i controller e la completa indisponibilità del controllo.

Il modello include il tasso di guasto di ciascun controller e il tasso di riparazione dopo il rilevamento. Può includere anche il guasto della commutazione, la perdita comune di alimentazione e un difetto software comune. Queste transizioni aggiuntive impediscono all’analisi di presumere un’indipendenza perfetta.

I risultati possono distinguere tra disponibilità con ridondanza completa e disponibilità funzionale. Il sistema può rimanere in grado di controllare il processo per gran parte dell’anno, pur trascorrendo un numero significativo di ore con un solo controller funzionante. Questa esposizione al funzionamento degradato potrebbe essere inaccettabile per un’applicazione critica.

Il modello può confrontare le strategie di miglioramento. Una sostituzione più rapida delle parti di ricambio può ridurre l’esposizione al funzionamento degradato in modo più efficace rispetto all’aggiunta di un terzo controller. Una diagnostica migliore può offrire un beneficio maggiore di una piccola riduzione del tasso di guasto dell’hardware. L’analisi di Markov rende misurabili questi compromessi.

Le apparecchiature in standby richiedono più di uno stato di guasto attivo

La ridondanza in standby introduce comportamenti aggiuntivi. Una pompa in standby può rimanere ferma finché la pompa in funzione non si guasta. L’unità in standby può contenere un guasto latente, non avviarsi o riscontrare un problema nella logica di trasferimento. Anche le valvole di isolamento possono non portarsi nella posizione richiesta.

Un modello di Markov può includere stati relativi ad apparecchiatura attiva funzionante, apparecchiatura in standby non disponibile, errore di trasferimento, capacità ridotta e perdita totale del sistema. Le prove di verifica spostano il sistema da una condizione dormiente sconosciuta verso una condizione nota. L’intervallo tra le prove influisce sulla durata durante la quale possono verificarsi guasti latenti.

Le politiche di manutenzione possono essere valutate all’interno della stessa struttura. Intervalli di prova più brevi migliorano il rilevamento dei guasti latenti, ma aumentano il carico di manutenzione e possono introdurre ulteriori errori. Il modello può confrontare questi effetti contrapposti invece di presumere che eseguire prove più frequenti sia sempre meglio.

L’analisi del funzionamento in standby dovrebbe includere anche la logistica delle riparazioni. Un componente in standby guasto potrebbe non interrompere immediatamente la produzione, quindi la riparazione può essere posticipata. Questo ritardo lascia il sistema senza protezione quando in seguito si guasta l’unità attiva. Le priorità operative influenzano quindi l’affidabilità tanto quanto le caratteristiche dell’hardware.

L’ipotesi di Markov offre sia semplicità sia limitazioni

Un modello di Markov di base presuppone che il comportamento futuro delle transizioni dipenda dallo stato corrente e non dall’intera cronologia. Questa ipotesi semplifica la matematica e spesso richiede tassi di transizione costanti. Alcune apparecchiature industriali rispettano ragionevolmente questa approssimazione per un periodo limitato.

L’invecchiamento e il danno cumulativo possono violare questa ipotesi. Un cuscinetto fortemente usurato non presenta lo stesso comportamento futuro in termini di guasto di un cuscinetto nuovo, anche se entrambi sono attualmente operativi. Stati aggiuntivi di degradazione possono approssimare l’invecchiamento, mentre per una rappresentazione più accurata potrebbero essere necessari modelli semi-Markoviani o di altro tipo.

L’esplosione degli stati è un’altra difficoltà. Ogni condizione dei componenti può moltiplicare il numero di stati possibili del sistema. Un impianto ridondante complesso può produrre rapidamente migliaia o milioni di combinazioni. Potrebbero essere necessari la riduzione del modello, il raggruppamento o la simulazione per mantenere gestibile l’analisi.

Il modello dovrebbe contenere dettagli sufficienti a supportare la decisione, senza rappresentare ogni variazione fisica. Una complessità eccessiva crea problemi di manutenzione e convalida. Un modello troppo semplice nasconde comportamenti importanti, mentre un modello troppo dettagliato diventa impossibile da spiegare.

Dove la modellazione di Markov funziona bene e dove no

La modellazione di Markov è particolarmente adatta ai sistemi ridondanti riparabili, alle apparecchiature in standby, alle modalità operative degradate e alla copertura diagnostica. Supporta l’analisi della disponibilità e mostra come la risposta di manutenzione modifichi l’esposizione del sistema. È particolarmente utile quando è importante la sequenza degli stati di guasto e riparazione.

Il metodo dipende dalla corretta definizione degli stati e dei tassi di transizione. Le ipotesi di tasso costante potrebbero non riflettere l’invecchiamento, le variazioni ambientali o la qualità della manutenzione. I guasti per causa comune devono essere rappresentati esplicitamente, anziché essere nascosti all’interno dei tassi di guasto dei componenti indipendenti.

I risultati dovrebbero essere supportati da un’analisi di sensibilità. Il team dovrebbe verificare come cambiano le conclusioni al variare dei tassi di guasto, dei tempi di riparazione, della copertura diagnostica e delle ipotesi sui guasti per causa comune. Un progetto che appare accettabile sulla base di un’unica ipotesi ottimistica non è robusto.

I modelli di Markov sono strumenti analitici, non prove fisiche. I test, le evidenze operative, l’FMEA e l’FTA restano necessari. Il modello aiuta a confrontare le strategie, ma non può sostituire la verifica dell’architettura effettiva.

Utilizzare i cinque metodi come un unico sistema di affidabilità

Le cinque tecniche offrono il massimo valore quando sono collegate. L’FMEA può identificare le modalità dettagliate di guasto dei componenti durante la progettazione. L’FTA può quindi determinare quali combinazioni contribuiscono a un evento critico del sistema. La modellazione di Markov può descrivere il comportamento del sistema dopo il primo guasto e durante la riparazione.

La simulazione Monte Carlo può verificare input incerti, come la durata delle riparazioni, i tempi di consegna dei ricambi, le condizioni meteorologiche e il carico di lavoro della manutenzione. L’RCA fornisce evidenze dopo i guasti reali e può mettere in luce ipotesi che i modelli originali non avevano considerato. I modelli devono quindi essere aggiornati, anziché conservati come documenti storici.

Supponiamo che un’FTA tratti due guasti dei controller come indipendenti. Una RCA successiva mostra che entrambi i controller si sono guastati dopo che un tecnico della manutenzione aveva caricato la stessa configurazione errata. L’albero dei guasti deve aggiungere un evento di manutenzione comune. Anche i modelli di Markov e Monte Carlo devono includere la nuova dipendenza.

Questo processo di feedback crea un programma di affidabilità dinamico. L’analisi predittiva orienta la progettazione, i dati operativi verificano le ipotesi e i risultati delle indagini migliorano la generazione successiva di modelli. Il lavoro sull’affidabilità diventa parte del ciclo di vita del sistema, invece di essere un requisito progettuale una tantum.

I guasti per causa comune possono compromettere un’intera architettura ridondante

I guasti per causa comune interessano più canali attraverso un’unica condizione sottostante. Alimentazione condivisa, raffreddamento, infrastruttura di rete, software, esposizione ambientale e pratiche di manutenzione sono esempi frequenti. Questi guasti sono particolarmente pericolosi perché possono annullare una ridondanza che sulla carta appare solida.

La separazione fisica riduce alcune cause comuni. Apparecchiature o software diversi possono ridurne altre. La verifica indipendente può ridurre gli errori di manutenzione e configurazione. Tuttavia, la diversificazione aumenta anche la complessità della formazione, dei pezzi di ricambio, dei test e dell’integrazione.

La soluzione corretta dipende dal rischio. Installare tecnologie di controller diverse può ridurre i guasti software comuni, ma creare nuove difficoltà di comunicazione e manutenzione. Alimentazioni separate possono offrire scarsi vantaggi quando entrambe rimangono nello stesso armadio soggetto ad allagamento. I metodi di affidabilità aiutano a individuare quali misure di diversificazione affrontano meccanismi di guasto credibili.

Le ipotesi sui guasti per causa comune devono essere esplicitate in ogni modello quantitativo. Trattare i canali ridondanti come perfettamente indipendenti produce quasi sempre un risultato ottimistico. L’esperienza dell’impianto e i risultati delle RCA forniscono prove preziose per stimare queste dipendenze.

La copertura diagnostica determina per quanto tempo il sistema rimane vulnerabile

Un sistema ridondante non può essere gestito efficacemente quando i guasti rimangono nascosti. La copertura diagnostica descrive la proporzione dei guasti rilevanti rilevati dai controlli automatici o manuali. Un’elevata copertura riduce il tempo trascorso in condizioni di degrado senza che ciò venga riconosciuto. Consente inoltre alla manutenzione di ripristinare la ridondanza prima che si verifichi un altro guasto.

Le affermazioni diagnostiche devono essere esaminate attentamente. Un controller può rilevare guasti interni al processore, ma non ogni guasto del cablaggio di campo. Un modulo di comunicazione può rilevare la perdita totale del collegamento, ma non riconoscere una mappatura errata dei dati. Un alimentatore può generare un allarme dopo la perdita completa dell’uscita, ma non fornire alcun avviso in caso di degrado graduale.

I test di verifica coprono i guasti che la diagnostica continua non rileva. L'intervallo di test influisce sull'esposizione al rischio. Intervalli più lunghi consentono ai guasti latenti di rimanere più a lungo, mentre intervalli molto brevi aumentano il carico di manutenzione e il rischio introdotto dai test. FMEA, analisi di Markov e dati operativi possono supportare la definizione di un intervallo equilibrato.

I test devono coprire l'intera funzione. L'attivazione di un ingresso PLC non dimostra che l'interruttore di campo, il cablaggio, la logica, l'uscita e l'elemento finale funzionino tutti correttamente. L'analisi dell'affidabilità dovrebbe definire esattamente quali guasti ogni diagnostica o test di verifica è in grado di rilevare.

Il tempo di riparazione è spesso importante quanto il tasso di guasto

I programmi di affidabilità si concentrano spesso sulla riduzione della frequenza di guasto dei componenti. Nei sistemi tolleranti ai guasti, il tempo di riparazione può essere altrettanto importante. Dopo il guasto del primo canale, il sistema può continuare a funzionare, ma rimanere vulnerabile. Lunghi ritardi nella riparazione aumentano la probabilità che un secondo guasto provochi una perdita completa.

La diagnosi, le approvazioni, la disponibilità dei tecnici, i pezzi di ricambio, i permessi di accesso e le condizioni di produzione influenzano tutti il tempo di ripristino. Un componente può richiedere quindici minuti per essere sostituito dopo che il ricambio corretto è arrivato nell'armadio. Il fermo effettivo può comunque protrarsi per giorni quando il ricambio deve essere reperito a livello internazionale.

Una diagnostica migliorata può ridurre il tempo necessario per localizzare il guasto. Moduli standardizzati e ricambi preconfigurati possono ridurre il tempo di sostituzione. Scorte locali, procedure di escalation chiare e supporto tecnico remoto possono ridurre i ritardi logistici. I modelli di Markov e Monte Carlo possono quantificare il valore di questi miglioramenti.

Il miglior investimento nell'affidabilità non consiste sempre nell'utilizzare hardware più robusto. In alcuni sistemi, ridurre il tempo di riparazione offre una maggiore riduzione del rischio rispetto a un modesto miglioramento del tasso di guasto dei componenti. L'analisi dovrebbe confrontare entrambe le opzioni.

Applicazione dell'analisi dell'affidabilità alle architetture DCS e PLC

L'affidabilità del sistema di controllo dipende da più elementi del solo processore centrale. Gli ingegneri dovrebbero esaminare controllori, moduli I/O, reti di comunicazione, alimentatori, server, stazioni operatore, sincronizzazione temporale, interfacce di campo e servizi ausiliari. Ogni elemento condiviso può diventare una dipendenza comune.

I controllori ridondanti possono condividere un unico rack I/O. I server ridondanti possono dipendere da un unico switch di rete o da un unico sistema di archiviazione. Le reti I/O remote possono utilizzare canali di comunicazione separati che attraversano lo stesso percorso fisico. Un'analisi completa deve seguire la funzione dal dispositivo di campo fino all'azione di controllo finale.

Il comportamento richiesto dopo un guasto deve essere definito chiaramente. Il processo può continuare sotto il controllore rimanente, trasferirsi al funzionamento manuale oppure entrare in un arresto controllato. Il personale addetto alla manutenzione deve sapere come identificare il canale guasto e ripristinare il sistema senza compromettere il canale integro.

Le organizzazioni che pianificano aggiornamenti dei sistemi di controllo possono anche esaminare i tipici componenti dei sistemi di controllo DCS utilizzati nelle architetture di automazione dei processi. La scelta dei componenti dovrebbe sempre seguire i requisiti di affidabilità dell’applicazione completa, anziché basarsi sulle caratteristiche di prodotti isolati.

I modelli affidabili dipendono da dati di manutenzione affidabili

L’analisi quantitativa dell’affidabilità è solida solo quanto i dati sottostanti. I registri di manutenzione dovrebbero distinguere tra guasto funzionale, sostituzione pianificata, ispezione e modifica. La data del guasto dovrebbe rappresentare il momento in cui la funzione è stata persa, mentre la data di ripristino dovrebbe rappresentare il momento in cui il funzionamento è stato nuovamente realmente disponibile.

Le identità degli asset devono rimanere coerenti nello storico dei dati, nel sistema di manutenzione, nei disegni e nel database dei ricambi. I codici di guasto dovrebbero descrivere i meccanismi, anziché sintomi vaghi. “Arresto” offre poco valore analitico, mentre “grippaggio del cuscinetto a seguito di contaminazione del lubrificante” supporta la modellazione e la prevenzione future.

È necessario includere anche l’esposizione operativa. Una pompa in funzionamento continuo non può essere confrontata direttamente con una pompa di riserva che entra in funzione solo durante i test. Temperatura, umidità, contaminazione, vibrazioni, sollecitazioni elettriche e carico di processo possono spiegare le differenze tra componenti altrimenti identici.

La pulizia dei dati dovrebbe essere considerata un’attività ingegneristica, non una semplice preparazione amministrativa. Classificazioni errate possono alterare i tassi di guasto, le distribuzioni dei tempi di riparazione e le conclusioni del modello. Prima di accettare risultati insoliti, gli analisti dovrebbero esaminarli con il personale della manutenzione e delle operations.

Un flusso di lavoro pratico per il miglioramento dell’affidabilità

Un progetto di affidabilità dovrebbe iniziare definendo la funzione richiesta e i confini del sistema. Il team deve dichiarare quali prestazioni sono necessarie durante il funzionamento normale e dopo ogni guasto credibile. Dovrebbe raccogliere disegni, manuali, storico della manutenzione, procedure operative, registri degli allarmi e rapporti sugli incidenti precedenti.

L’FMEA può quindi identificare i modi di guasto a livello di componente e i controlli di rilevamento deboli. L’FTA può esaminare gli eventi principali critici e le dipendenze condivise. La modellazione di Markov può valutare gli stati degradati e la risposta alle riparazioni, mentre la simulazione Monte Carlo può rappresentare l’incertezza relativa a guasti, manutenzione e logistica.

Gli incidenti storici dovrebbero essere riesaminati mediante RCA. I risultati dovrebbero essere utilizzati per aggiornare le analisi progettuali e le ipotesi quantitative. Le azioni dovrebbero essere prioritizzate in base a conseguenze, probabilità, rilevabilità, esposizione, tempo di riparazione e costi.

Ogni azione deve avere un responsabile, una data di completamento e una verifica dell’efficacia. Le analisi devono essere aggiornate dopo modifiche importanti alle apparecchiature, aggiornamenti software, modifiche dei processi o cambiamenti nella strategia di manutenzione. L’affidabilità è una disciplina ingegneristica continua, non un rapporto completato una volta e poi archiviato.

Le domande che smascherano le affermazioni deboli sulla tolleranza ai guasti

Una revisione approfondita si chiede quale funzione debba rimanere disponibile e quali guasti il sistema sia in grado di tollerare. Verifica se i canali ridondanti siano fisicamente, elettricamente e logicamente indipendenti. Si chiede inoltre come vengano rilevati i guasti latenti e per quanto tempo il sistema possa rimanere degradato prima della riparazione.

Il team dovrebbe identificare i componenti con tempi di approvvigionamento lunghi e determinare se un singolo errore di manutenzione possa influire su più canali. Le dipendenze software e di configurazione dovrebbero ricevere la stessa attenzione dell’hardware. Gli operatori devono comprendere come si comporta il sistema dopo un guasto e quali azioni manuali restano disponibili.

Quando possibile, le ipotesi relative a guasti e riparazioni dovrebbero essere supportate da dati provenienti dall’impianto. Le azioni correttive dovrebbero essere verificate al termine. I test di prova dovrebbero dimostrare il funzionamento dell’intera funzione protettiva, anziché la risposta di apparecchiature isolate.

Queste domande sono più utili di una generica affermazione secondo cui il sistema è ridondante. Collegano la tolleranza ai guasti all’architettura reale, all’ambiente operativo e alle capacità di manutenzione.

Considerazioni finali

La tolleranza ai guasti è essenziale quando non si possono accettare tempi di inattività, comportamenti non sicuri o perdita di controllo. Tuttavia, la sola ridondanza non rende affidabile un sistema. Gli ingegneri devono comprendere le modalità di guasto, le dipendenze condivise, la copertura diagnostica, il funzionamento degradato, il comportamento durante la riparazione e le conseguenze operative.

L’analisi dell’albero dei guasti mostra come combinazioni di guasti possano produrre un evento critico. L’FMEA fornisce una revisione sistematica delle singole modalità di guasto e dei loro effetti. La simulazione Monte Carlo valuta scenari incerti, mentre l’RCA trasforma i guasti reali in conoscenze preventive. La modellazione di Markov spiega come i sistemi riparabili passino tra stati di funzionamento normale, degradato, guasto e ripristinato.

Ogni metodo presenta dei limiti, ma insieme forniscono un solido quadro di affidabilità. Gli studi di progettazione dovrebbero essere aggiornati con i dati operativi, e i risultati delle analisi degli incidenti dovrebbero migliorare i modelli futuri. I risultati devono influenzare l’architettura, la manutenzione, i pezzi di ricambio, i test, la formazione e le procedure.

L’obiettivo non è creare un sistema che non subisca mai un guasto. L’obiettivo è rilevare i guasti tempestivamente, contenerne le conseguenze, preservare la funzione richiesta e ripristinare l’operatività completa in modo prevedibile. Questo è il significato pratico della tolleranza ai guasti industriale.