Trova le risposte!
Le centrali nucleari. L'energia che scaturisce dal bombardamento dell'uranio con neutroni. Il processo di 'fissione/fusione nucleare'. Il problema della radioattivitą e delle scorie.

Altri articoli della stanza Sicurezza

Creato da Giuseppe Quartieri « clicca sul nome per leggere il curriculum dell'autore

Garanzia di sicurezza adeguata di una centrale nucleare - Giuseppe Quartieri -

La comunità scientifica e quella professionale direttamente implicata nella progettazione di sistemi critici per la sicurezza riconoscono che non si può garantire al 100% la sicurezza dei sistemi. In particolare, non si può garantire al 100% la sicurezza di sistemi basati sull’impiego dei calcolatori e quindi sul software.
Tuttavia, si assiste ad un enorme aumento di sistemi basati su calcolatori con una storia relativamente priva di guasti critici che hanno condotto a veri e propri disastri e catastrofi. A riprova, si può accennare ad uno studio empirico -forse un po’ datato- sulle morti procurate da guasti critici di calcolatori eseguito da MacKenzie. Allo studio si stima che la percentuale di morti dovuta a guasti critici prodotti da errori di software nei calcolatori, entro la fine dell’anno 1992, rispetto al numero totale di morti nell’intero pianeta è pari solo al 3% del numero totale che ammonta a circa 1100 ± 1.
La degradazione entropica dei sistemi fisici, l’irreversibilità tipica dei processi e dei modi di guasto mostrano la tendenza tipica dei sistemi a degenerare nel caos. In tale ambito è valida l’idea (o legge) di Perow: gli "incidenti normali" (normal accidents) provocati da guasti dovuti alla complessità dei sistemi e dal forte accoppiamento dei vari sottosistemi influenzano la criticità dei sistemi. L’adeguatezza della garanzia della sicurezza rispetto a guasti procurati da errori di software rimane problematica anche se gli aspetti legali sono stati ormai affrontati con le varie direttive comunitarie e prime fra queste la Direttiva della Comunità Europea sulla Responsabilità del Prodotto datata anno 1985.
L'articolo 6 di questa direttiva definisce un prodotto difettoso “... quando non fornisce la sicurezza che una persona si aspetta…”. L'obiettivo prefissato quindi è l'analisi della garanzia dell'adeguatezza della sicurezza del sistema, mediante due argomentazioni:

1. Quale è il livello di sicurezza considerato adeguato.

2. Quale livello di garanzia viene considerato adeguato.

Queste domande sono direttamente connesse alle leggi giuridiche e direttive comunitarie (Rif. 1 delle Norme e Direttive EC-85) che regolano la responsabilità di chi immette sul mercato un prodotto non adeguatamente sicuro. Il requisito legale - almeno in UK - è il rispetto del principio che il rischio deve essere tanto piccolo quanto ragionevolmente praticabile (principio di ALARP). In pratica, tutto ciò significa che prima di tutto bisogna eliminare i rischi e quindi assumere che i rischi rimanenti siano tollerabili. Quindi bisogna spendere la maggiore energia possibile per rendere i rischi residui più piccoli possibile.
Quest'approccio conduce direttamente e facilmente all’introduzione del concetto di rapporto costi benefici (cost effectiveness) nell'analisi dei rischi e quindi nella progettazione e gestione del "safety case". Molte volte il lavoro d’analisi deve essere rinviato di anno in anno per problemi di bassa disponibilità finanziaria. Così diviene più semplice ridurre i rischi entro il "budget" previsto posto che sia ragionevolmente congruo potere sviluppare il massimo sforzo possibile d’analisi di riduzione dei rischi. La determinazione di ciò che è ragionevole in pratica per ogni circostanza non è possibile se non, forse, davanti al giudice. Quindi non si può assolutamente definire un criterio standard in materia di ragionevolezza pratica di riduzione del rischio al minimo. Il principio di cui si argomenta riconosce che la sicurezza assoluta è irraggiungibile. In realtà, quando si afferma che un certo software è sicuro, s’intende dire che esso non viene usato in un’applicazione correlata a problemi di sicurezza. Nel caso che il pacchetto di software in esame, viene impiegato in un sistema soggetto a problemi di sicurezza e che quindi può diventare critico per la sicurezza, allora è necessario quantificare la parola "sicuro" applicata al software. La quantificazione comporta anche implicazioni di costi da analizzare. Si può migliorare la sicurezza di un sistema spendendo più denaro per ridurre i rischi intrinseci al livello più piccolo possibile, ma la legge non può richiedere di spendere una somma infinita di denaro per raggiungere la sicurezza assoluta, posto che ci si riesca. Questo principio è riconosciuto dalla Legislazione Comunitaria e recepito in Italia.
Secondo le Direttive Comunitarie recepite dall'Italia in termini di Atto della Protezione del Consumatore si asserisce il principio della responsabilità stretta in certe circostanze. La Commissione Europea (CE), nell'ambito delle Direttive Europee per la Sicurezza, ha deciso che qualsiasi persona che venga, in qualche maniera, danneggiata fisicamente da parte di un prodotto difettoso, non deve trovarsi di fronte a difficoltà di perseguire giuridicamente il responsabile che sia sufficientemente ricco da potere pagare i danni. In altre parole, il problema della responsabilità giuridica del danno da prodotto difettoso diventa problema di politica sociale e non solo di giustizia. In ogni caso il danno deve essere precisamente identificato così come deve essere rigorosamente identificato il produttore del prodotto difettoso. Alla stessa stregua, (si veda anche la Lg. 626) il danneggiato deve dimostrare, per essere ricompensato, di non essersi comportato in modo negligente. L'unico problema aperto nella DIRETTIVA COMUNITARIA è dato dal fatto che se lo stato dell'arte della conoscenza scientifica non ha consentito di scoprire, durante tutto il periodo di produzione, il difetto o il guasto del prodotto, allora il produttore non è responsabile del danno. In questo contesto, il produttore deve fornire quindi una difesa del proprio operato. Una "difesa accettabile" contro un’azione prevista nelle suddette direttive è ciò che viene definito una "difesa allo stato dell'arte". In altre parole, questo tipo di difesa si basa sulla premessa della esistenza di un difetto che non può essere scoperto allo stato dell’arte della conoscenza scientifica e tecnica.
Come si nota, la problematica della responsabilità del danno da prodotto difettoso presenta ancora problemi aperti e rimane sempre un “bersaglio mobile” da inseguire nel tempo con l’evolversi della conoscenza scientifica. Inoltre, nell’ambito delle norme di riferimento nazionali ed internazionali che regolano questa materia, l’aderenza del software alle norme richieste durante lo sviluppo di un sistema critico per la sicurezza appare una strategia difensiva appropriata per il raggiungimento dell’obiettivo di adeguatezza della garanzia di sicurezza. In questo riferimento legislativo per la risoluzione della problematica della adeguatezza della garanzia, il concetto dei Livelli di Integrità del Sistema (SIL) si è affermato come uno dei concetti più significativi per la garanzia della sicurezza. Questo concetto viene riportato in modo basilare nella IEC 1508 ed in altre norme e documenti di specificazione usualmente applicabili. In particolare, la IEC 1508 definisce vari modi e metodi di calcolo dei SILs. La norma aiuta a dimensionare lo sforzo necessario per progettare il sistema accettabilmente sicuro valutando bene i rischi intrinseci, con particolare riguardo alla progettazione del software. Infatti, a seconda del tipo di sistema bisogna dimensionare opportunamente le risorse di ingegneria da dedicare alla analisi di sicurezza. Certamente, lo sforzo da compiere per un sistema il cui guasto critico può produrre centinaia di morti è completamente diverso da quello necessario per sistemi che tutt’al più possono, guastandosi, ammazzare una sola persona. Tuttavia, dal punto di vista dell’etica sociale (norma SA 8800) anche questo concetto è discutibile e non sempre accettabile. In ogni caso, se l’analisi di sicurezza consente di definire sin dall’inizio i Livelli di Integrità del Sistema - i SIL - allora la gestione della razionalità pratica della riduzione del rischio e relativa accettabilità diviene più realistica, concreta e pratica.
L’esperienza riportata dagli autori su menzionati asserisce che il passaggio da un SIL ad un altro SIL di minore intensità può risultare anche drammatico. Sempre muovendosi in questo tipo di riferimento ed in particolare nell’ambito della Garanzia in termini di Sistemi Qualità, i requisiti di sicurezza vengono alcune volte imposti dal Cliente in modo esplicito oppure facendo riferimento a requisiti giuridici standard. In tal caso, bisogna fare molta attenzione ai requisiti imposti dal Cliente, che tuttavia, certe volte dimostra di essere molto più attento agli aspetti sociali della sicurezza che ai propri problemi di responsabilità diretta o indiretta in caso di guasto critico che pone il sistema in situazione critica. Il suggerimento da dare in questi casi è di fare riferimento agli aspetti giuridici fondamentali e rispettarli in toto.
Dal punto di vista professionale, bisogna ammettere che, alcune volte, i requisiti di legge concernenti l’accettabilità del rischio e quindi la progettazione e produzione di prodotto sicuro sono molto difficili da realizzare e si corre il rischio di fare come lo struzzo, che infila la testa nella sabbia per non volersi rendere conto che non si è in grado di progettare e realizzare il sistema con i livelli di sicurezza richiesti dalla legge. Il progettista non si può rifugiare nell’asserire che la propria conoscenza dello stato dell’arte non consente niente di meglio. Esiste il codice di professionalità e di etica progettuale che impedisce di chiudere gli occhi e non affrontare il problema direttamente e chiaramente. Questo codice etico di professionalità non consente a qualsiasi progettista di fare atto di presunzione di conoscenza e competenza e quindi tentare di fare qualcosa di cui non si è competenti. In queste condizioni, non si può lavorare per tutti i Clienti possibili qualunque sia il costo e/o profitto previsto. Anzi, in caso di progetto con problemi di sicurezza, è necessario sapere usare bene le previsioni economiche previste (budget) per l’analisi della sicurezza stessa. In altre parole, il requisito di progettazione e sviluppo di un sistema sicuro il cui rischio residuo sia minimo rispetto il principio di ALARP, significa in termini pratici, che il fornitore deve spendere al meglio le risorse economiche associate all’analisi di sicurezza nel modo più efficace possibile entro i limiti ed i vincoli giuridici previsti.
Per citare un esempio pratico, se un fornitore vuole sviluppare del software con implicazioni di sicurezza senza applicare l’ormai richiesta metodologia dei linguaggi e specifiche formale (metodi formali), allora con molta probabilità, il fornitore si mette fuori legge, poiché non sceglie il miglior modo di procedere nella progettazione del software secondo lo stato dell’arte riconosciuto da tutta la comunità scientifica dei progettisti e programmatori di software. Tuttavia, tutti questi aspetti di costruzione della garanzia adeguata della sicurezza dei sistemi impongono ulteriori riflessioni ed il più elevato livello di competenza.
In altre parole, la garanzia di sicurezza si ottiene progettando la “garanzia” stessa nel sistema in questione. Non ha senso parlare dopo che il guasto critico è avvenuto e cercare di creare giustificazioni, più o meno razionali, dopo che l’evento critico è avvenuto ed i danni (agli uomini ed alla proprietà) sono già accaduti. Bisogna progettare per la garanzia di sicurezza sin dall’inizio del progetto, durante tutto il processo di sviluppo e verificarne l’attuazione nelle fasi produttive e di assistenza tecnica. Questa procedura richiede la CERTIFICAZIONE, possibilmente di terza parte, che è sostanzialmente una garanzia scritta basata su di una dimostrazione formale di un processo di conferma che “il sistema o i suoi componenti soddisfano i requisiti specificati ed è accettabile per l’impiego operativo”. Normalmente si verifica che il costo della CERTIFICAZIONE (di terza parte) di un prodotto “off-the-shelf” ossia di un prodotto maturo, che non necessariamente era stato progettato per soddisfare certi particolari requisiti di sicurezza, diviene di gran lunga superiore al costo della riprogettazione del sistema stesso. In particolare se si tratta di un sistema-software. Infatti nel campo del software, la CERTIFICAZIONE ottenuta applicando soltanto i metodi formali non garantisce assolutamente la sicurezza del sistema. Molte volte non esistono prove di assoluta correttezza del software. A tale riguardo, resta utile ricordare l’argomentazione di Fetzer, mutuata dalla filosofia, secondo cui il “softwarista” lavora con simboli matematici e non con la realtà vera del sistema immerso nel mondo reale. I modelli matematici sono solo dei “modelli” (ipotesi di funzionamento) del mondo reale. Alla stessa stregua, una prova matematica è soltanto una congettura forte valida sino a che non viene scoperta la successiva confutazione. La storia della matematica è piena di esempi di teorie e modelli matematici superati da teorie nuove e più ampie. Nel campo del software si può asserire che le prove sono soltanto verifiche convalide di coerenza interna ed intrinseca del software stesso. Se la specifica tecnica è sbagliata, anche se il software soddisfa i requisiti di specifica, non significa che il software è adeguato all’uso e soddisfa i requisiti del Cliente o di tutti gli “stakeholders”. In questo contesto, tra gli “stakeholders” possono essere inclusi i Politici, le Autorità Garanti, il Cliente, l’UTENTE, l’Acquirente, gli Azionisti Aziendali, la Direzione Aziendale (il management), il “Marketing”, il “Team” progettuale, tutte le unità operative addette al progetto, i sub fornitori, i valutatori, anche le compagnie di assicurazioni in senso classico, ossia in inglese le “insurance companies”, gli operatori dei sistemi, gli operatori o in genere le persone incidentate o le vittime, il pubblico ed infine, per ultimi ma non ultimi, le generazioni future.