Verifica SIL Demistificata: Applicare la ISA-TR84.00.02 per le Safety Instrumented Functions nel settore Oil & Gas

Verifica SIL Demistificata: Applicare la ISA-TR84.00.02 per le Safety Instrumented Functions nel settore Oil & Gas

Una Safety Instrumented Function che sulla carta ha un obiettivo SIL 2, ma fallisce il calcolo di verifica, non è una funzione SIL 2: è una passività mascherata da documentazione. Eppure, in molti impianti operativi, la verifica SIL viene regolarmente trattata come un esercizio burocratico: si inseriscono i numeri in un software, appare un risultato verde e si chiude il file. Quando l'indagine su un incidente apre successivamente quel file, le lacune diventano costose. Questo articolo illustra la metodologia di verifica descritta nella ISA-TR84.00.02, spiega dove i professionisti sbagliano costantemente e fornisce una guida decisionale per ingegneri, responsabili della manutenzione e team di procurement che necessitano di risultati difendibili.

Cos'è realmente la verifica SIL e cosa non è

La selezione del SIL risponde alla domanda: quale riduzione del rischio deve fornire questa Safety Instrumented Function (SIF)? La verifica SIL risponde a una domanda diversa: la SIF così come progettata fornisce effettivamente tale riduzione del rischio, dati l'hardware, l'architettura, l'intervallo di proof-test e la copertura diagnostica selezionati?

La ISA-TR84.00.02 è il rapporto tecnico che supporta la IEC 61511, lo standard di sicurezza funzionale per i Safety Instrumented Systems (SIS) del settore di processo. Il rapporto tecnico fornisce metodi di calcolo elaborati (equazioni semplificate, analisi di Markov, Fault Tree Analysis e diagrammi a blocchi di affidabilità) che consentono agli ingegneri di calcolare la Probability of Failure on Demand (PFD) o la Probability of Failure per Hour (PFH) per una SIF e confrontare il risultato con l'obiettivo SIL stabilito durante la valutazione dei pericoli e dei rischi.

La distinzione è importante per i team di procurement: l'acquisto di un trasmettitore con certificato SIL 2 non rende la SIF SIL 2. Il certificato riguarda il dispositivo in isolamento. La verifica riguarda l'intero loop della SIF (sottosistema sensori, risolutore logico e sottosistema elementi finali) operante nelle condizioni specifiche del sito.

Il quadro di calcolo

PFD vs. PFH: Scegliere la metrica corretta

La ISA-TR84.00.02 indica agli ingegneri di utilizzare la PFD (probabilità media di guasto su richiesta) per le SIF in modalità demand e la PFH (probabilità di guasto pericoloso all'ora) per le SIF in modalità ad alta domanda o continua. La selezione della metrica errata per la modalità operativa è un errore fondamentale che invalida il risultato della verifica, indipendentemente dalla precisione dei calcoli aritmetici.

Un sistema di protezione della pressione ad alta integrità su una testa pozzo opera tipicamente in modalità low-demand: la SIF è richiesta raramente e la PFD è la metrica corretta. Un sistema di salvaguardia della fiamma di un sistema di gestione dei bruciatori che opera continuamente viene valutato utilizzando la PFH. Confermare la modalità operativa prima di aprire qualsiasi strumento di calcolo.

Decomposizione dei sottosistemi

La ISA-TR84.00.02 struttura la SIF in tre sottosistemi:

• Sottosistema sensori (elementi iniziatori, inclusi trasmettitori, interruttori e configurazioni di votazione)
• Sottosistema risolutore logico (PLC di sicurezza, logica a relè o logica pneumatica)
• Sottosistema elementi finali (valvole, attuatori, interruttori di posizione, solenoidi)

Ogni sottosistema contribuisce alla PFD complessiva della SIF. La PFD totale della SIF è la somma dei valori PFD dei tre sottosistemi. Questa proprietà additiva significa che un sottosistema di elementi finali debole può consumare l'intero budget SIL anche quando il sensore e il risolutore logico sono ben specificati.

Parametri di input chiave

Il calcolo richiede, per ogni componente:

Ognuno di questi input richiede giudizio ingegneristico e dati specifici del sito. I valori predefiniti o generici presi in prestito da database di riferimento senza verifica rispetto alle apparecchiature reali e agli intervalli di manutenzione effettivi sono una fonte comune di risultati non conservativi.

Dove i calcoli di verifica falliscono nella pratica

Ottimismo sull'intervallo di proof-test

L'intervallo di proof-test inserito nel calcolo deve riflettere l'intervallo effettivamente raggiunto sul campo, non quello scritto nella procedura di manutenzione. Se una procedura specifica test annuali ma i vincoli operativi estendono regolarmente l'intervallo, il risultato della PFD non è conservativo. La ISA-TR84.00.02 richiede che l'intervallo ipotizzato sia realizzabile in normali condizioni operative. I responsabili della manutenzione dovrebbero verificare i record effettivi di completamento dei test prima di confermare l'intervallo utilizzato nella verifica.

Copertura del proof-test incompleta

Un proof-test che non esercita l'intera SIF dal sensore all'elemento finale non ottiene il credito completo. Il test a corsa parziale di una valvola, ad esempio, rileva una parte dei guasti della valvola ma lascia i restanti non rilevati fino a un test a corsa completa. La ISA-TR84.00.02 fornisce indicazioni su come tenere conto della copertura parziale del proof-test nel calcolo della PFD. L'utilizzo di un credito per test completo quando viene eseguito solo un test parziale gonfia l'apparente riduzione del rischio.

Guasti per causa comune sottostimati

Il fattore beta tiene conto dei guasti che vanificano la ridondanza: un singolo evento che causa il guasto simultaneo di due canali indipendenti. I guasti per causa comune nelle SIF del settore oil & gas derivano da alimentazioni d'aria strumenti condivise, percorsi comuni delle linee di impulso attraverso una zona interessata dal calore, versioni software identiche con un bug comune o un singolo tecnico che calibra in modo errato più trasmettitori durante la stessa finestra di manutenzione. La ISA-TR84.00.02 fornisce un metodo strutturato di stima del fattore beta. L'applicazione di un beta predefinito minimo senza aver analizzato la checklist sottostima il rischio di causa comune in architetture in cui l'indipendenza fisica o procedurale non è stata rigorosamente implementata.

Guasti sistematici ignorati

I calcoli della PFD riguardano i guasti hardware casuali. La ISA-TR84.00.02, in linea con la IEC 61511, riconosce che i guasti sistematici (errori di specifica, progettazione, installazione o manutenzione) non sono catturati dall'aritmetica dell'affidabilità. Una SIF che supera il calcolo della PFD ma ha un setpoint di intervento errato nel risolutore logico, o una valvola che non si chiude a causa di un dimensionamento errato dell'attuatore, non funzionerà. La verifica deve essere accompagnata da una valutazione della sicurezza funzionale che esamini le specifiche della SIF, il diagramma causa-effetto e i record di messa in servizio.

Scenario illustrativo: SIF di sovrapressione del separatore ad alta pressione

(Questo scenario è illustrativo e non rappresenta un impianto o un incidente specifico.)

Si consideri un separatore ad alta pressione con una SIF progettata per chiudere la valvola di blocco in ingresso in caso di pressione molto alta. L'obiettivo SIL 2 richiede una PFD nell'intervallo definito dalla IEC 61511 per il SIL 2. L'architettura utilizza un singolo trasmettitore di pressione (sensore 1oo1), un risolutore logico PLC di sicurezza e una singola valvola a sfera azionata pneumaticamente con solenoide (elemento finale 1oo1).

Un calcolo preliminare della PFD utilizzando i dati del tasso di guasto pericoloso del produttore e l'intervallo di proof-test annuale pianificato produce un risultato che sembra soddisfare il SIL 1 ma non raggiunge il SIL 2. L'ingegnere ha tre opzioni: aumentare la ridondanza nel sottosistema sensori (ad esempio, passare alla votazione 1oo2 o 2oo3), aumentare la frequenza dei proof-test o migliorare la copertura diagnostica. L'aggiunta di un secondo trasmettitore in votazione 1oo2 riduce sostanzialmente la PFD del sottosistema sensori e la ripetizione del calcolo con input del fattore beta aggiornati porta la PFD totale della SIF all'interno della fascia SIL 2, a condizione che l'intervallo di proof-test sia mantenuto come pianificato e che le ipotesi del fattore beta sulla separazione fisica dei due trasmettitori siano rispettate durante l'installazione.

Questo scenario illustra perché la verifica deve essere completata prima che il procurement finalizzi la distinta base, non dopo. Scoprire una lacuna nell'architettura dopo che la valvola e l'attuatore sono stati ordinati è un problema di tempi e costi. Scoprirlo dopo l'installazione è un problema di sicurezza.

Checklist Pratica per la Verifica SIL

Utilizzare questa checklist prima di sottoporre una verifica SIF alla revisione della valutazione della sicurezza funzionale.

Scopo e Input

• [ ] Confermare la modalità operativa (bassa domanda vs. alta domanda/continua) e selezionare PFD o PFH di conseguenza
• [ ] Ottenere i valori λ_D e DC dai fogli dati SIL del produttore, non da database generici, a meno che non siano disponibili dati specifici del sito e la fonte generica sia documentata
• [ ] Confermare l'intervallo del proof-test rispetto al programma di manutenzione effettivo e ai record di completamento recenti
• [ ] Documentare la copertura del proof-test parziale separatamente dalla copertura del test completo e applicare il corretto credito nel calcolo
• [ ] Esaminare la checklist del fattore beta ISA-TR84.00.02 per ogni architettura ridondante; non applicare un valore predefinito senza giustificazione

Architettura e Progettazione

• [ ] Verificare che il confine della SIF corrisponda al diagramma causa-effetto: dal punto di prelievo del sensore alla sede dell'elemento finale
• [ ] Confermare che il risolutore logico sia valutato utilizzando i propri dati certificati sul tasso di guasto, non una cifra PLC generica
• [ ] Verificare che le valvole solenoidi, i pressostati di posizione e i finecorsa nel sottosistema dell'elemento finale siano inclusi nella PFD dell'elemento finale: questi vengono spesso omessi
• [ ] Revisionare la separazione fisica e i servizi comuni per i canali ridondanti; documentare eventuali utenze condivise come contributori di causa comune

Documentazione e Governance

• [ ] Confermare che l'obiettivo SIL sia tracciabile rispetto a una valutazione dei pericoli e dei rischi documentata (Layer of Protection Analysis o equivalente)
• [ ] Registrare tutte le ipotesi, le fonti dei dati e le deviazioni nel rapporto di verifica
• [ ] Programmare una revisione della valutazione della sicurezza funzionale della verifica completata prima che il design del SIS venga congelato
• [ ] Pianificare un trigger di ri-verifica per qualsiasi modifica che vari l'architettura, l'intervallo del proof-test o i dati del tasso di guasto dei componenti

Conclusione e Prossimi Passi

La verifica SIL è un'attività ingegneristica quantitativa con input, metodi e criteri di accettazione specifici definiti in ISA-TR84.00.02. Non è l'output di uno strumento software da accettare senza un esame critico delle ipotesi sottostanti. I fallimenti più comuni — intervalli di proof-test ottimistici, credito di copertura del test incompleto, fattori di causa comune sottostimati e componenti degli elementi finali mancanti — sono tutti prevenibili con una revisione disciplinata degli input prima dell'esecuzione del calcolo.

Per gli ingegneri che iniziano o aggiornano un programma di verifica SIL, i passi pratici successivi sono:

1. Ottenere l'edizione corrente di ISA-TR84.00.02 e allineare i modelli di calcolo ai suoi metodi e alla guida sul fattore beta.
2. Controllare i record di verifica SIF esistenti rispetto ai dati effettivi di completamento dei proof-test e confermare che gli intervalli ipotizzati siano rispettati.
3. Stabilire un trigger formale di gestione del cambiamento in modo che qualsiasi modifica a una SIF — hardware, software o procedura di manutenzione — avvii una revisione di ri-verifica prima che la modifica venga implementata.
4. Coinvolgere il valutatore della sicurezza funzionale all'inizio della fase di progettazione, non nella fase di documentazione.

Una SIF verificata non è una garanzia di zero incidenti. È una dimostrazione difendibile e quantificata che il design fornisce la riduzione del rischio richiesta dall'impianto. Tale distinzione vale il rigore applicato.