Affidabilità e Sicurezza dei Sistemi e del Software

Capitolo 2° - I concetti base di affidabilità e sicurezza

di A. Autino e V. de Val

Introduzione

In questa seconda puntata getteremo le basi dei concetti di affidabilità e sicurezza.

Studieremo inoltre perché la progettazione software deve essere considerata una cosa a se stante, rispetto alle altre discipline dell'ingegneria, per quanto riguarda le problematiche di affidabilità.

Particolare attenzione sarà posta, e riteniamo essere questo un aspetto particolarmente innovativo della nostra ricerca, agli aspetti umani che intervengono in tutte le fasi del ciclo di vita di un sistema, dalla fase negoziale fino alla fase di utilizzo. Le osservazione inerenti questo filone di indagine compariranno, nel testo, in colore rosso.

Definizione di Affidabilità e Sicurezza

Tra le varie definizioni di affidabilità (in inglese Reliability) forse la più chiara è la seguente:

Dicesi affidabilità di un qualsiasi dispositivo (sistema o componente) la probabilità che esso funzioni correttamente, per un dato tempo, in certe condizioni.

Questa definizione contiene alcuni punti importanti:

• Il concetto di affidabilità può essere applicato a qualsiasi oggetto realizzato dall'uomo, sia esso un oggetto semplice (componente), o uno complesso, costituito dall'insieme di più componenti (sistema).

Un aspetto molto importante nello studio dell’affidabilità è proprio il calcolo dell'affidabilità di un sistema a partire dall'affidabilità dei suoi componenti.

L'affidabilità del sistema dipenderà dall'affidabilità dei singoli componenti (incluso ovviamente il software) e da come essi interagiscono tra di loro. Inoltre l'applicazione software, che fino ad ora abbiamo visto come componente del sistema di controllo, è a sua volta analizzabile come sistema composto da un certo numero di componenti (moduli) software. Anche per l'affidabilità si applica quindi la regola generale di decomposizione gerarchica di un sistema in sotto-sistemi.

• L'affidabilità è una probabilità ed, in quanto tale, è un numero, adimensionale, compreso tra 0 e 1.

• Per poter definire correttamente l'affidabilità di un qualsiasi oggetto (componente o sistema) è fondamentale definire precisamente le condizioni operative e la durata della sua attività. Questi due termini (condizioni e durata) sono inglobati nel concetto di missione, che risulta essere un concetto basilare nello studio dell'affidabilità.

La definizione data sopra può portarci ad una ulteriore analisi del concetto di affidabilità nel momento in cui cerchiamo di definire con maggior precisione la frase "funzioni correttamente". E' infatti evidente che non tutti i tipi di malfunzionamento sono ugualmente importanti. Tornando al nostro sistema di controllo industriale, possiamo ipotizzare che se si rompe la stampante su cui il computer stampava periodicamente i dati dell'impianto, probabilmente il guasto non è molto grave (bisognerà certamente ripararla, e questo ha degli impatti sulla manutenzione, ma il guasto non riduce le reali funzionalità del sistema, né crea dei rischi per la sicurezza). Al contrario, se si guasta il microprocessore del computer (supponendo che non ci siano ridondanze), il nostro sistema è completamente perso!

Pertanto, date le considerazioni fatte sopra, possiamo sostituire la nostra precedente definizione di affidabilità con la seguente:

Dicesi affidabilità di un qualsiasi dispositivo (sistema o componente) la probabilità che esso non abbia guasti di un certo tipo durante una certa missione.

I vari tipi di affidabilità vengono quindi classificati in base al tipo di guasto che considerano. Una classificazione abbastanza comune è la seguente:

• Affidabilità logistica - Probabilità che non capiti alcun guasto (di qualsiasi tipo).

• Affidabilità di missione - Probabilità che non capitino guasti con conseguenze maggiori, tali cioè da pregiudicare la funzionalità del sistema e quindi di impedirgli il completamento della sua missione. Se necessario, si distingue tra guasti significativi (che degradano significativamente le funzionalità del sistema, ma non impediscono il completamento della missione) e guasti maggiori (che invece impediscono il completamento della missione).

• Sicurezza - Probabilità che non capitino guasti con possibili conseguenze catastrofiche, tali cioè da produrre danni a persone, cose o al sistema stesso.

Vi è, inoltre, un altro tipo di affidabilità, meno quantificabile a priori: la probabilità che il sistema funzioni e possa venire usato, in modo sicuro, secondo le esigenze dell'utente, anche e soprattutto in situazioni critiche per l'utente stesso e/o per gli impianti controllati. La probabilità che le funzioni del sistema siano disponibili a svolgere il loro compito quando se ne manifesta la necessità, anche dopo lunghi periodi di inutilizzo. Definiamo per ora questo tipo di affidabilità, in mancanza di termini migliori, affidabilità di utilizzo. Essa ingloba tutte le categorie affidabilistiche inerenti aspetti umani, di utilizzo, di definizione dei requisiti e delle modalità di utilizzo del sistema, delle competenze necessarie, dell'interazione uomo-macchina, aspetti manageriali, sia di gestione del progetto, sia negoziali e di gestione del contratto.

In fase di progettazione di un sistema, si può definire che livello di affidabilità si vuole raggiungere. Dato che l'affidabilità è una probabilità, il requisito può essere espresso come un semplice numero. Chiaramente quando si progetta un sistema si pongono dei requisiti quantitativi diversi per i vari tipi di affidabilità. La tabella che segue fornisce un esempio:

• Affidabilità logistica Probabilità ~ 10^-3

• Affidabilità di missione 10^-7< Probabilità < 10^-5

• Sicurezza (in inglese, safety) Probabilità < 10^-9

In inglese, la protezione da guasti con possibili conseguenze catastrofiche viene chiamata safety, mentre con il termine security si individua la protezione da accessi non autorizzati e da possibili danneggiamenti volontari. Purtroppo entrambi i termini si traducono in italiano con il termine sicurezza, e questo a volte può generare confusione. Nel nostro caso, la parola sicurezza sarà sempre associato al concetto di affidabilità e quindi di safety.

Criteri di progettazione affidabilistica

Vediamo ora brevemente come si progetta l’affidabilità nel caso di un sistema generico, composto cioè sia da hardware che da software.

1. Fin dalla fase di contrattazione occorre prestare molta attenzione al problema delle competenze e skill necessari. Nel caso di progetti ad elevata esigenza di affidabilità e sicurezza occorre limitare molto, se non evitare completamente, la vendita di competenze allo scoperto, specie quando il fornitore non è ancora completamente al corrente di tutte le diverse competenze che occorrono per completare il progetto, ma pensa di approfondire le esigenze e procurarsi le competenze in seguito. Spesso il budget di commessa, definito senza tener conto di particolari competenze, risulta poi, in fase esecutiva, troppo esiguo, ed importanti aspetti affidabilistici finiranno con il restare scoperti. E' interesse del committente preoccuparsi di chiarire, ed il fornitore dovrebbe dichiarare con tutta sincerità, se possiede competenze affidabilistiche in generale, e se possiede competenze affidabilistiche specifiche, relative al processo da controllare ed alle tecnologie da usare nel progetto.

2. Il primo passo progettuale consiste ovviamente nel definire i requisiti di affidabilità dell’intero sistema (logistica, di missione, di sicurezza e di utilizzo). Questa attività è parte integrante della definizione dei requisiti del sistema. In particolare l'affidabilità di utilizzo dipende in modo determinante dalla definizione precisa dei requisiti affidabilistici. Per tale fase di definizione potrebbero essere necessari skill ed esperienze di diversa natura (ad es. meccanica, elettrica, elettronica, fluidodinamica, impiantistica, informatica): la fase di definizione dei requisiti affidabilistici deve coinvolgere, fin dal'inizio, progettisti esperti nelle diverse discipline implicate dal progetto. Non ultima, per importanza, è la presenza dell'utente finale, che dovrà, se necessario, essere aiutato in questa fase a definire il profilo professionale ed il numero delle persone che utilizzeranno il sistema. La progettazione affidabilistica deve infatti basarsi anche sulla logistica d'impianto, sulla quantità ed ubicazione delle stazioni di lavoro, sugli orari di presidio delle stazioni di lavoro, sui comportamenti ed esigenze delle persone che utilizzeranno il sistema (se si tratta di tecnologi, di ricercatori, di responsabili di produzione, di manutentori, o altro), sulla natura e sui flussi del processo produttivo, di esercizio o di ricerca. Se il sistema dovrà interagire con operatori ed utenti umani, se è prevista l'interazione umana in un ciclo critico o potenzialmente critico, si dovrà prestare attenzione alla sicurezza ed efficienza delle comunicazioni umani-macchina e macchina-umani, al fine di evitare. per esempio, fenomeni di ipo-attenzione o iper-attenzione. E' inoltre interesse sia del committente che del fornitore chiarire bene le differenze tra performance ed affidabilità del sistema, e definire, per ogni parte del sistema, precisi criteri di scelta e priorità tra gli aspetti prestazionali e gli aspetti affidabilistici. La fase di definizione dei requisiti, funzionali ed affidabilistici, del sistema deve anche definire i requisiti dei progettisti che disegneranno il sistema: ove siano rilevate delle mancanze, occorrerà ricercare gli skill necessari.

3. Terminata la definizione dei requisiti, si procede con la fase di disegno, in cui vengono individuate le parti principali del sistema: il sistema viene disegnato come un insieme di sotto-sistemi che interagiscono tra loro, viene definita la funzione di ciascun sotto-sistema e si stabiliscono le comunicazioni tra di essi. In questa fase, detta disegno dell’architettura di sistema, si esaminano i requisiti individuati nella fase precedente e si stabilisce quale sotto-sistema, o insieme di essi, li debbano soddisfare. Facendo così, si trasformano i requisiti di sistema in un insieme di requisiti specifici dei vari sotto-sistemi. Anche i requisiti di affidabilità vengono gestiti in questo modo: vengono cioè tradotti in una serie di requisiti specifici per ogni elemento.

4. Queste due fasi vengono iterate un numero sufficiente di volte (dipendente dalla complessità del sistema), fino a che è stato raggiunto il livello di dettaglio sufficiente affinché il progettista possa realizzare il singolo elemento. Tipicamente in un progetto complesso la fase di disegno di sistema termina quando sono state chiaramente individuate le parti puramente software, quelle hardware (quali sensori ed attuatori), quelle meccaniche, e così via.

5. Infine, per ogni tipo di elemento (meccanico, elettronico, software), inizia la progettazione specifica, che è chiaramente diversa da elemento ad elemento, seguita dalla sua fabbricazione. In questa fase, ogni progettista dovrà rispettare i requisiti di affidabilità che gli sono stati assegnati dal disegno di sistema.

6. A questo punto l’attività di progettazione affidabilistica si trasforma in un’attività di controllo della corrispondenza o meno di quanto elaborato dai progettisti rispetto agli obbiettivi. Si tratta di monitorare, ai vari stadi di avanzamento, l’affidabilità stimata del progetto e di intraprendere, se necessario, opportune modifiche migliorative. Tali modifiche possono essere:

• Scelta di materiali costruttivi di maggior qualità.
• Scelta di componenti più affidabili (o sovradimensionati, che risentono cioè meno delle sollecitazioni richieste).
• Introduzione di ridondanze.
• Revisioni di progetto.
• Revisioni dei criteri e delle modalità di utilizzo.

Lo strumento utilizzato per tenere sotto controllo lo sviluppo dell’affidabilità e per decidere se effettuare interventi migliorativi e quali tra quelli possibili, è la procedura nota come FMECA (Failure Mode Effect and Criticality Analysis): si tratta di un’analisi sistematica di come ogni componente possa venire meno al suo corretto funzionamento (considerando le differenti modalità di guasto) e di quali conseguenze questo abbia sull’intero sistema:

1. Vengono listati tutti i componenti del sistema (che possono essere componenti fisici, se la progettazione è già arrivata alle ultime fasi di dettaglio, oppure blocchi funzionali, se la progettazione è ancora in corso).
2. Per ogni componente vengono listati tutti i possibili modi di guasto.
3. Per ognuno di essi si valuta:

• La gravità del guasto sul funzionamento dell’intero sistema. Questa classificazione riflette le varie classi di affidabilità del sistema: logistica, di missione e sicurezza. Pertanto un guasto potrà essere minore se impatta solo sull’affidabilità logistica, significativo se ha impatti sulla missione, critico se ha impatti sulla sicurezza.
• La probabilità che il guasto accada. Questa misura quantitativa è possibile per componenti fisici (meccanici od elettronici), mentre lo è molto meno per il software. A titolo di esempio, nel campo della componentistica elettronica, esiste lo standard MIL (originato dal Ministero della Difesa Americano, ed attualmente lo standard più seguito) che per ogni tipo e classe dimensionale di componente elettronico fornisce direttamente o con formule il tasso di guasto in funzione di:

• Livello di qualità del componente.
• Tasso di utilizzo.
• Condizioni ambientali.

4. Una volta eseguita questa analisi per tutti i componenti, è possibile calcolare i valori di affidabilità (logistica, di missione, di sicurezza e di utilizzo) per tutto il sistema (o per i vari sotto-sistemi).

Le peculiarità dei Sistemi Software

Molte delle tecniche affidabilistiche sviluppate per il progetto di sistemi elettro-meccanici (brevemente introdotte nel capitolo precedente) non sono direttamente applicabili al software. Questo a causa della sostanziale differenza tra la progettazione software e le altre discipline ingegneristiche. Vediamo in dettaglio queste differenze:

• L’affidabilità tradizionale assume che il progetto sia stato fatto senza errori (o che, in ogni caso, questi errori siano identificati e rimossi prima della messa in esercizio dell’impianto).

• In questo caso, gli unici guasti possibili sono quelli di usura o quelli casuali, di cui si deve tenere conto nell’analisi affidabilistica.

La situazione del software è esattamente speculare: non esistono guasti casuali o di usura (il software non si deteriora con il tempo), ma esistono sempre errori di disegno. Per capirne il motivo, vediamo perché negli altri tipi di progettazione si può ragionevolmente assumere che gli errori di disegno siano stati rimossi e come queste ipotesi non siano valide nel caso del software:

1. Per i progetti non software esiste sempre un approccio sistematico al disegno del sistema, che garantisce l’assenza (o riduce al minimo) degli errori di disegno.

Questo era il caso, ad esempio, dei sistemi elettromeccanici usati per il controllo di processo prima dell’avvento dei microprocessori.

Nel caso delle applicazioni software attuali, il grado di complessità è cresciuto in modo impressionante, causando una crescita non lineare degli errori introdotti nella fase di progettazione. E proprio a causa di tale enorme aumento della complessità che risulta impossibile dimostrare l’assenza di errori di disegno.

Un approccio più rigoroso di questa indimostrabilità di correttezza si trova in [Parnas 1985]. In questo articolo, l’autore sostiene che i sistemi analogici sono costruiti con componenti che hanno, all’interno dell’intervallo operativo dell’impianto, un numero infinito di stati stabili, che permettono di descrivere il loro comportamento con funzioni continue e di costruire un modello matematico del sistema. Tale modello può essere studiato analiticamente e le caratteristiche del sistema (nel nostro caso, l’affidabilità) possono essere determinate in modo rigoroso. Nel caso di sistemi elettromeccanici digitali, essi sono generalmente costituiti con componenti aventi un insieme finito di stati stabili, ed il sistema risultante ha un numero relativamente piccolo di stati discreti, che può essere studiato e testato in modo esaustivo. Un’applicazione software, al contrario, è un sistema discreto con un numero estremamente elevato di stati (senza, tra l’altro, alcuna regolarità e ripetitività, quale si trova ad esempio nella componentisitica elettronica). Questa complessità fa si che sia oltremodo difficile analizzare matematicamente un sistema software, come pure testarlo in modo esaustivo.

Il problema della complessità è tale che la maggior parte dei malfunzionamenti di un’applicazione software è da imputare non ad errori di realizzazione, quanto a mancanze nelle specifiche dei requisiti dell’applicazione [Levenson 1995]. Torneremo più avanti su questo punto, che è molto importante nella progettazione di software affidabile.

2. Per i progetti non software si utilizzano moduli collaudati, il cui corretto funzionamento è stato verificato in passato.

L’hardware (inteso in senso generale) viene sempre prodotto in serie, ed i componenti standard sono utilizzati in molte applicazioni. Questo permette di accogliere dati sul suo funzionamento (e naturalmente di correggere i difetti riscontrati).

Un’applicazione software, al contrario, viene quasi sempre costruita specificamente per il sistema da controllare. Risulta pertanto un esemplare unico, la cui affidabilità non può essere valutata in fase di disegno.

Risposte parziali a questo problema possono essere:

1. Riusabilità del software (concetto su cui contano molto tutte le tecniche Object Oriented).
2. Utilizzo di piattaforme standard per le applicazioni di controllo di processo (SCADA), che vengono solo personalizzate per l’applicazione specifica.

3. Il collaudo rivela gli errori di progetto.

Si assume sempre che durante la fase di collaudo si possa esercitare il sistema realizzato e verificarne le caratteristiche, ed in particolare la sua affidabilità.

Nel caso di un’applicazione software, sempre a causa della sua elevata complessità, un test esaustivo del suo comportamento è praticamente impossibile. Infatti abbiamo detto che da un punto di vista matematico un’applicazione software è un sistema discreto con moltissimi stati e moltissime transizioni da uno stato all’altro. Verificarne il corretto funzionamento equivale ad esplorare tutti i suoi stati e le sue possibili transizioni. Tuttavia tale automa oltre ad essere enormemente complesso, non presenta alcuna struttura regolare (un circuito elettronico ha anch’esso moltissimi stati, ma possiede anche una struttura regolare che ne permette sia un’analisi teorica che un testing sistematico), che ne possa semplificare o automatizzare l’analisi, e pertanto una sua verifica esaustiva è sempre irrealizzabile dal punto di vista pratico.

Un altro limite della fase di test riguarda gli errori fatti a livello di definizione delle specifiche. Infatti un test serve a verificare che il sistema si comporti come descritto nelle sue specifiche. Se però le specifiche sono scorrette, il test non potrà certo risolvere il problema!

Per finire, bisogna notare che, per sistemi "safety critical", il test in condizioni realistiche è impossibile (pensate al software che controlla l’assetto di un aereo da combattimento). E’ necessario ricorrere a dei simulatori, la cui "fedeltà" all’ambiente operativo reale non può essere garantita completamente.

Da quanto esposto in questo capitolo, si può capire come le tecniche affidabilistiche per il software siano alquanto specifiche e debbano far fronte a problemi solitamente secondari in altre discipline.

Occorre inoltre tenere in considerazione quanto segue. L’avvento dell’elettronica e dell’informatica ha portato i sistemi automatici ad un grado di flessibilità molto elevato, inimmaginabile nella precedente era meccanica. Tale evoluzione ha determinato un notevole aumento del grado di libertà dei progettisti: poiché gli errori progettuali sono molto più correggibili, la mente del progettista è molto più libera di indirizzarsi agli aspetti concettuali, e ci si può permettere sempre di più il lusso di progettare il sistema in astratto, prescindendo dai tecnicismi e dai dettagli, che si confida possano essere poi risolti a livello procedurale, applicando sistematicamente le metodologie di progettazione affidabilistica e di qualità. Ora, il fatto che, grazie alle tecnologie informatiche, gli errori siano divenuti correggibili, non significa che siano certamente corretti. Sta ancora a noi umani correggerli, prendendo in considerazione tutto ciò che nessuna intelligenza elettronica, per quanto evoluta, non è (e non sarà mai) in grado di considerare. Per quanto potente e veloce, la macchina esegue infatti nulla più, e (se il sistema ha una buona affidabilità di utilizzo) anche nulla meno di quanto la nostra fantasia è stata capace di programmare in essa. Sul piano metodologico, il fatto che esistano ormai procedure standard e check list per ogni fase progettuale, non significa che tali procedure siano complete e corrette, né che siano sempre e certamente applicate per intero. E' un tragico errore, già pagato in molti casi con un inaccettabile prezzo di vite umane, riporre eccessiva fiducia nella tecnologia informatica e nelle procedure, tendere ad affidarsi di un'intelligenza "altra" rispetto a quella umana. L'altra intelligenza (quella elettronica), per essere affidabile deve essere comunque programmata e controllata, e gli errori effettivamente corretti, dall'intelligenza umana. Inoltre le procedure devono essere applicate sistematicamente e completamente, e continuamente controllate, riverificate ed aggiornate, dai progettisti, dai tecnologi processisti e dagli utenti, in una lavoro di riesame continuo che non può in alcun modo essere omesso.

Per riassumere, un sistema deve essere progettato nel modo più affidabile possibile, ma non dobbiamo mai affidarci completamente al sistema.

Bibliografia

[Levenson 1995] N. G. Levenson "Safeware: System safety and computers", Addison-Wesley, 1995

[Parnas 1985] Parnas, "Software aspects of strategic defence systems", Communication of ACM, 1985