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

La sicurezza nucleare: il safety case - Giuseppe Quartieri -

La cultura della sicurezza in campo nucleare (così come altri campi quali l’aeronautica, le reti di trasporto e di telecomunicazioni ecc.) ha sempre avuto un posto primario dagli albori della nascita delle applicazioni nucleari. Tenendo sempre conto della distinzione fra “security” (ossia sicurezza sul lavoro oppure rispetto a intrusione e quindi perdita di proprietà ecc) e “safety” probabilità di esenzione di guasti critici che potrebbero produrre perdita di vita e/o di proprietà.

Recentemente, la cultura della sicurezza - in termini di security - in Italia ha subito un forte balzo in avanti con la emissione delle nuove leggi sulla sicurezza (security) sul lavoro con la Legge 626 e tutte le modifiche ed aggiornamenti vari. Più in generale in Europa e nel mondo, la cultura della sicurezza (safety) dei sistemi ha subito un grande scossone in avanti nell'ultima decade poiché è stata oggetto di intensi studi e ricerche, anche congiunte, da parte del mondo accademico e del mondo industriale. Prima di questo grande scossone, la cultura della sicurezza era solo cultura orale, trasmessa da interessato ad interessato, da praticante a praticante senza alcun testo codificato o regole giuridiche scritte e codificate. Nei due ultimi decenni la situazione è cambiata radicalmente. L'interesse per la sicurezza (safety) e la "security" è enormemente aumentato coinvolgendo larghi strati di studiosi, di ricercatori, di ingegneri e di giuristi. Nel passato prossimo, in Italia la "security" (sicurezza sui luoghi di lavoro) era stata regolamentata da leggi specifiche solo per pochi campi applicativi. La sicurezza (safety) dei sistemi era stata anch'essa trattata a fondo solo per alcuni sistemi molto critici (centrali nucleari a fissione, aerei, ferrovie, ecc.) senza che, tuttavia, fosse stata creata una consistente, coerente e completa teoria nonché una metodica ed una prassi. Ovviamente, la distinzione fra sicurezza nei luoghi di lavoro (security) e sicurezza (safety) dei sistemi è sostanziale. 

Per riprendere il discorso sulla evoluzione recente della cultura della sicurezza in Italia, si vuole ricordare che il campo più regolamentato era il nucleare con la Direttiva apparsa sul G.U.C.E. (Gazzetta Ufficiale della Comunità Europea) N.11 del 20 febbraio 1959 (Direttiva 2 febbraio 1959) e la N. 57 del 9 luglio 1962 (Direttiva 5 marzo 1962) e N. 216 del 26 novembre 1966 (Direttiva 27 ottobre 1966), successivamente modificata con la Direttiva EURATOM 66/45 (Rif. 11,12,13,14). Più recentemente, queste direttive sono state aggiornate per diventare la Direttiva del Consiglio Europeo del 1 giugno 1976 relative alla "protezione sanitaria della popolazione contro i pericoli derivanti dalle radiazioni ionizzanti". In campo aeronautico, bisognerebbe elencare tutta la normativa internazionale, militare e non militare, recepita in Italia dagli anni ‘50. Nelle altre nazioni europee e negli Stati Uniti la cultura della sicurezza – tenendo conto che non si parla in questo contesto di sicurezza di polizia - ha fatto certamente grandi balzi in avanti in termini tecnico scientifici, poiché il mondo industriale e quindi del lavoro in queste nazioni ha iniziato con un certo anticipo il discorso della formulazione della politica per lo sviluppo della analisi di criticità e di sicurezza dei sistemi e quindi della razionalizzazione scientifica della problematica della sicurezza. Infatti, il contributo della Health and Safety Executive alla prima edizione della norma CEI (IEC) 1508 è stato decisivo. Nel Regno Unito, dopo la discussione sul "Rapporto Robens", la legge che governa la salute e la sicurezza sul lavoro è stata varata nel 1974 con lo "Health and Safety at Work Act". I principi dell'analisi del rischio ed il principio "ALARP" (As Low As Reasonable Practicable ‘ più basso possibile per quanto razionalmente praticabile) vengono impiegati normalmente già dagli anni ‘70. Tuttavia, la problematica della sicurezza dei sistemi (aerei, treni, navi, satelliti, centrali energetiche termiche e/o nucleari ecc.) basati sui calcolatori e quindi la problematica della sicurezza del software è ancora in alto mare: non ci sono per esempio curricula universitari specifici e non ci sono metodologie standardizzate di miglioramento dei processi né tanto meno questi processi sono sotto controllo manageriale come già ripetuto. Nell'ultima decade in Inghilterra è sorto il "Club sui Sistemi Critici per la Sicurezza". Ogni anno, il CSR (Centre for Software Reliability = Centro per l'Affidabilità del Software) organizza il Congresso sulla Sicurezza dei Sistemi. In Italia, opera la divisione italiana del "Club" ENCRESS che tenta di fare opera d'acculturazione sugli aspetti più generali possibili della sicurezza (safety/security), ma non ancora riesce a decollare bene e rimane un "Club" molto ristretto di ricercatori, managers e tecnici. Sempre in Italia, le pubblicazioni tecnico-scientifiche sulla "sicurezza" - soprattutto in termini di safety - sono molto ridotte se si escludono alcune riviste tecnico - divulgative che preferiscono trattare solo e soltanto gli aspetti giuridici connessi agli effetti negativi di cattiva gestione della sicurezza. La sicurezza è imperativo etico e morale di un popolo e di chi lo governa, non imposizione giuridica di chi vuole ottenerla con la paura di forti sanzioni economiche penali (si veda legge 626 ricerca sulla sicurezza in termini di "safety"). In particolare, solo negli ultimi anni, si è fatto avanti un concetto fondamentalmente nuovo e scientificamente rigoroso, il concetto di Livello d'Integrità di Sicurezza: "SIL" (Safety Integrity Level).

Questo concetto è emerso da un considerevole sforzo d'investimenti di capitali e di risorse d'umane dedicate alla ricerca nelle ultime due decadi. Due fattori sostanziali hanno reso possibile il salto di qualità nella ricerca sulla sicurezza:

1. L'abbandono del concetto di natura binaria della sicurezza ossia l'abbandono del vecchio o antico concetto secondo cui la sicurezza o c'è oppure non c'è; come se la sicurezza potesse essere ridotta ad un variabile binaria: (1,0), (si, no), (vero, falso), (sicuro, insicuro) ecc.. In realtà, esiste tutto un mondo, un "continuum" fra zero ed uno, in altri termini esiste una scala continua di rischi compresi fra zero ed uno.

2. Il problema della sicurezza è problema di sistema complesso, anzi la sicurezza è essa stessa "sistema" e quindi va trattata con la applicazione della teoria dei sistemi complessi.

Bisogna ancora dire che non esiste un corpo ben preciso, rigoroso e maturo di trattamento della problematica della sicurezza dei sistemi critici con particolare riguardo ai sistemi basati su calcolatori e quindi sicurezza del software. Ci si affida alla tradizione ed all’insegnamento orale basato soprattutto sulla miriade di convegni e riunioni sull’argomento. La problematica della sicurezza sta vivendo quindi un momento di transizione verso una trattazione esauriente e completa che non ancora esiste. In questo periodo di transizione, sono stati elaborati vari tentativi di sistematizzazione della analisi di sicurezza e della relativa CERTIFICAZIONE convalidata anche da leggi già emesse, ma che dovranno essere prontamente riviste per includere tutti o almeno la maggiore parte del “corpo” di discipline sulla sicurezza. In altre parole, se si introducono innovazioni nei sistemi già esistenti, i problemi di sicurezza aumentano. Per esempio, aggiungere la capacità di programmazione ad un sistema già esistente che è già complesso di per sé, significa aumentare enormemente la complessità del sistema stesso. La necessità di programmazione aumenta la complessità del sistema. L’introduzione di sistemi elettronici programmabili (PES) consente di aumentare la potenza del sistema per esempio aumentando le interfacce dell’operatore oppure aumentandone le funzioni eseguibili. Tutto ciò si ottiene a discapito di un aumento di software che quindi richiede la progettazione e verifica di buon funzionamento ed affidabilità del software stesso. Tuttavia, questo aumento di software non è, a stretto rigore, un vero problema di software ma è un problema di aumento di complessità globale del sistema. Si tratta di problemi di sistema e quindi di garantire una adeguata sicurezza del sistema. A tale scopo, è necessaria un'alta dose di comprensione e di autocoscienza da parte del progettista e dell’analista per realizzare, con successo, lo sviluppo ed il dispiegamento di sistemi, critici per la sicurezza, che normalmente sono il risultato di un approccio multi disciplinare. Senza adeguata conoscenza ed affidabilità nelle prestazioni di sicurezza del sistema, i sistemi critici per la sicurezza sono proni al guasto e possono provocare disastri.

Tuttavia, questa posizione intellettuale equivale alla rinuncia al programma originario di ricerca e progettazione di sistemi sicuri al 100%, mentre purtroppo bisogna enfatizzare la problematica della sicurezza del software. Infatti, alcuni autori asseriscono (Redmill, ecc. Ref. 15, 17) che l’applicazione della teoria dell’affidabilità al calcolo della sicurezza di un sistema critico consente di potere includere solo e soltanto i guasti aleatori e non i guasti “sistematici” ossia i guasti di software. Infatti, gli errori di progetto oppure errori di specificazione tecnica del sistema sono errori sistematici che si propagano lungo il sistema sempre alla stessa maniera poiché, tra l’altro, il software non invecchia mai. L’errore software si propaga in modo sistematico lungo il sistema e così pure la propagazione delle conseguenze negative assume carattere sistematico.

Di parere opposto è Littlwood (Rif. 16) che sostiene che nonostante ciò, l’errore e quindi il guasto software può e deve essere trattato con le belle e classiche tecniche dell’affidabilità, per esempio aggregando, con un bel albero dei guasti (FTA), i tassi di guasto dei componenti in modo da caratterizzare la struttura della propagazione dell’errore sistematico, che deve essere sempre trattato con argomenti probabilistici. L’impiego dell’aggettivo “sistematico” si riferisce al meccanismo di guasto ossia al meccanismo per il tramite del quale lo stato di guasto (fault) si rivela sotto forma di vero e proprio guasto e non come un processo di guasto. Diviene quindi corretto asserire che se uno stato di guasto di questa classe (o meglio della classe procurato da un errore di software o di progetto più in generale) si presenta in certe circostanze, allora si può essere certi che si presenterà alla stessa maniera qualora le circostanze si riprodurranno in modo esattamente uguale a quelle prima verificate. Nel linguaggio del software, che normalmente viene considerato la maggiore sorgente di guasti sistematici, si può asserire che se il programma ha prodotto un errore (stato di guasto) in corrispondenza di un particolare “ingresso” allora si riprodurrà sempre lo stesso errore in corrispondenza dello stesso ingresso sino a quando non verrà eseguita la necessaria azione correttiva per eliminare l’errore di software. In questo senso, gli errori di software sono “deterministici” e da questa sorta di “determinismo” prende il nome il “guasto di software”. Tuttavia, l’interesse per la comprensione del fenomeno va focalizzato sul “processo di guasto”: la sequenza dei fenomeni (attività, azioni ecc.) che si osservano quando si osserva il funzionamento del sistema nelle condizioni ambientali operative. Nelle condizioni operative, il processo stesso presenta incertezze naturali procurate dalla natura dei fattori ambientali operativi che agiscono sul sistema. In modo più specifico, non si sa quando un certo insieme di ingressi che produce l’errore di software si verificherà la prossima volta. Non si sa quando il prossimo guasto del programma software accadrà. Quest’aspetto di “processo” rende inapplicabile l’approccio deterministico e, al contrario, impone l’applicabilità dell’approccio probabilistico. In altre parole, gli aspetti più importanti dei processi di guasto (hardware o software o paperware) non sono "deterministici" ma essenzialmente "probabilistici" sia che si tratti di guasti sistematici oppure aleatori.