Sicurezza ed affidabilità dei sistemi informatici Anno 2006/2007

Transcript

1 Anno 2006/2007 Questa dispensa è il frutto dello studio condotto durante il corso di Affidabilità e Sicurezza dei sistemi informatici, tenutosi nell'anno 2006/07, presso l'università Federico II di Napoli, tenuto dai docenti prof. A.Mazzeo e ing. L.Coppolino. I disegni, i grafici e le immagini utilizzate in questo testo sono proprietà dei rispettivi autori. Se si dovessero presentare violazioni del diritto di autore, si prega di segnalarlo tempestivamente tramite oltremago@gmail.com. I contenuti della dispensa prendono spunto dalle slide utilizzate a lezione, realizzate dall'ing. L. Coppolino, e sono il frutto dell'elaborazione degli appunti presi durante il corso, dello studio dagli articoli delle fonti segnalate a lezione e delle ricerche di approfondimento compiute. Questa dispensa non è esaustiva, e molto probabilmente, in alcune sue parti non è del tutto corretta. Tuttavia, potrebbe essere un aiuto nello studio di una materia vasta e complessa come quella trattata. Per maggiori informazioni sui docenti del corso L.Coppolino e A.Mazzeo si rimanda al sito Informazioni sull'autore della dispensa: Roberto Bifulco, oltremago@gmail.com, (sito in costruzione). 1

2 Indice generale Introduzione...5 Capitolo 1 Definitions and taxonomy Definizione di Sistema Ulteriori definizioni System Function System Behavior Delivered Service Correct Service Failure Service outage Degraded mode Dependability Threats Attributes Means Ciclo di vita di un sistema Faults Faults classification Natural faults Human made faults Non malicious development fault Malicious fault Interaction fault Exploit e Vulnerability Errors Failures Development failure Dependability e Securety failures Error propagation Fault: ulteriori definizioni Trust Means Fault prevention Fault tolerance Error detection Error handling Fault handling Implementazione della fault tolerance Fault tolerance e Securety Fault removal Fault removal durante il development Fault removal durante l'use Fault forecasting Capitolo 2 Fault characterization Fault classification Fault model Accelerating faults manifestation Qualitative Accelerated Testing Quantitative Accelerated Testing Lifetime of a population of products Standard based reliability prediction Fault prevention Capitolo 3 Introduction to reliability theory Statistical definition of dependability figures Hazard rate

3 3.1.2Availability Reliability Block Diagrams Series configuration Parallel configuration R-out-of-N configuration Complex configuration Tie-set Cut-set Fault Tree analysis Failure mode effect analysis Risk evaluation Risk priority number Criticality analysis Criticality analysis: quantitative Criticality analysis: qualitative Markov modeling...35 Capitolo 4 Dependability mean: Error detection Fault tolerance Error detection Ideal check Acceptability check Types of check Replication check Timing check Reversal check Coding check Reasonableness check Structural check Diagnostic check Self checking Control flow monitoring...44 Capitolo 5 Hardware fault tolerance Fault masking Voter design Masking logic Hardware dynamic redundancy techniques Reconfigurable NMR Self purging Sift out Backup sparing Graceful degradation Capitolo 6 Software fault tolerance Software fault tolerance techniques Structured software fault tolerance Error detection Error correction Distribution of executions Executions of variants Granularity of fault unit Alcuni problemi generali Software fault tolerance schemes N-version programming Recovery block N-self Checking Programming Self-Configuring Optimistic Programming (SCOP) Progettare la diversità Exception handling Software Rejuvination...60 Capitolo 7 3

4 Fault tolerance: assessment techniques Analytical Modelling Fault injection Fault injection campaign Input Domain Output domain Collegamenti fra modelli e misurazioni Attack injection Capitolo 8 Distribuited systems dependability Problematiche Distribuited agreement problem Non determinismo...67 Bibliografia

5 Introduzione I moderni sistemi informatici gestiscono attività molto diverse, alcune delle quali di grande importanza per la vita dell'uomo. Sistemi informatici gestiscono aerei, navi, treni, altri sistemi gestiscono le centrali elettriche, anche nucleari, altri ancora trattano e conservano i nostri soldi, come i sistemi bancari. Questa grande varietà di sistemi non richiede semplicemente delle soluzioni che funzionino, per la criticità delle applicazioni è necessario che si sviluppino sistemi che garantiscano i loro servizi sempre in modo corretto, a dispetto di guasti o inconvenienti anche imprevisti. La grande varietà di ambienti comporta che la progettazione di un sistema del genere, che viene definito solitamente dependable, non possa essere appannaggio di un solo tipo di professionista. Costruire questi sistemi comporta un'esperienza che coinvolge più discipline, dalla crittografia, alla conoscenza dei meccanismi di affidabilità dell'hardware. A questo si aggiunge la differenza di requisiti fra i vari sistemi, che, per ottenere lo stesso risultato, richiedono approcci totalmente differenti. Alla luce di queste prime considerazioni si comprende la necessità di un approccio sistematico e ingegneristico alla progettazione di sistemi dependable. Introduzione 5

6 Capitolo 1 Capitolo 1 Definitions and taxonomy Per trattare approfonditamente un argomento è importante definire innanzitutto una terminologia di base, che consenta di discutere di problemi e soluzioni senza possibilità di errore o ambiguità. Questo capitolo introduce la terminologia di base e i concetti fondamentali per la progettazione di sistemi dependable. 1.1 Definizione di Sistema La definizione di sistema è sottoposta continuamente a confusione, che è la causa della maggior parte degli errori commessi. Alla base di questa confusione c'è la questione che le definizioni di sistema possono essere differenti, a seconda di quello che si considera parte o non parte del sistema. Nel seguito ne specifichiamo alcune1: 1. Un prodotto o un componente (ex: una smartcard, un componente hardware di un PC). 2. Un insieme dei precedenti più un sistema operativo, di comunicazione, o altre entità che realizzano una infrastruttura di organizzazione. 3. La definizione precedente con in aggiunta una o più applicazioni. 4. Una delle precedenti definizioni con in aggiunta l'it staff. 5. Una delle precedenti definizioni con in aggiunta gli utenti interni e l'amministrazione del sistema. 6. Una delle precedenti definizioni con in aggiunta i clienti o altri utenti esterni. 7. Una delle precedenti definizioni con in aggiunta l'ambiente circostante, incluse le strutture sociali quali la politica, i media, o anche i concorrenti. Ognuna delle precedenti definizioni viene utilizzata in diversi ambiti. In questo testo faremo riferimento generalmente alle definizioni 6 o 7. Qualora fosse necessario l'utilizzo di un'altra definizione, sarà esplicitamente specificato. 1 Le definizioni sono prese da [2]. Definitions and taxonomy 6

7 Capitolo Ulteriori definizioni Alla definizione di sistema si affiancano alcune ulteriori definizioni, altrettanto importanti per la trattazione degli argomenti di questo testo System Function La system function è quello che si desidera che il sistema faccia. La funzione del sistema è generalmente descritta dalle specifiche funzionali in termini di funzionalità (servizi) e prestazioni. Le specifiche descrivono anche quel che il sistema non dovrebbe fare System Behavior Il system behavior è quello che il sistema fa per implementare la sua funzione. Un modo per descrivere il system behavior potrebbe essere una sequenza di stati Delivered Service Rappresenta il servizio che il sistema fornisce all'utente. Potrebbe anche essere definito come il system behavior percepito dall'utente Correct Service E' il servizio fornito quando il sistema implementa le funzionalità richieste dalle specifiche Failure E' l'evento che si presenta quando il sistema comincia a fornire un servizio diverso dal correct service. Questo generalmente avviene quando il sistema non rispetta le specifiche funzionali, ma potrebbe anche essere un problema dovuto alla cattiva descrizione di tali specifiche. Volendo rappresentare tramite un'illustrazione la relazione fra correct service, failure e incorrect service, possiamo far riferimento al diagramma a stati di Illustazione 1.1. Illustrazione Relazione fra correct e incorrect service Service outage E' il periodo di tempo in cui il servizio fornito è non corretto. Definitions and taxonomy 7

8 Capitolo Degraded mode Il sistema sta operando in degraded mode quando offre un sotto-insieme dei suoi servizi all'utente, questo sotto-insieme può riguardare tanto le funzionalità, quanto le prestazioni. Le specifiche possono anche individuare diversi degraded mode, quali potrebbero essere: emergency service, limited service, ecc. Se il sistema, in seguito ad un failure comincia a funzionare in degraded mode, il failure in questione, non avendo compromesso per intero il sistema, prende il nome di partial failure. 1.3 Dependability Il termine con cui si riassumono tutte le caratteristiche legate ai sistemi che ci proponiamo di progettare, è dependability. La definizione di dependability è particolarmente complessa poiché include una grande varietà di proprietà, tuttavia una definizione concisa è importante sia per riferirsi ad un sistema di questo tipo con chiarezza, sia per stabilire un criterio per valutare se un sistema è dependable. Una definizione che ha trovato particolare seguito è quella data in [1]: Dependability is the ability to deliver service that can justifiabily be trusted Secondo questa definizione, un sistema è dependable se è in grado di fornire un servizio di cui ci si può giustificatamente fidare. Questa definizione, per quanto concisa e fondamentalmente chiara nel fornire un'idea di dependability, non fornisce un metodo per definire se un sistema è dependable, a questo scopo, sempre in [1], viene data una ulteriore definizione: Dependability is the ability to avoid service failures that are more frequent and more severe than is acceptable Questa definizione ci permette di dire quando un sistema è dependable, anche se è necessario porre molta attenzione sulla definizione di servizio del sistema e di quando si può dire che il servizio non è corretto. La dependability è un concetto complesso, che non è definito da una sola caratteristica, ma a cui contribuiscono più aspetti che possiamo suddividere in tre categorie: attributes, means, threats. Nella Illustrazione 3.2 è mostrato il dependability tree che riassume questa suddivisione. Illustrazione Dependability tree Definitions and taxonomy 8

9 Capitolo Threats I threats sono circostanze non desiderate che causano o sono il risultato della undependability. Queste circostanze sono indesiderate, ma non sono inaspettate. Molte volte si conoscono i threats cui è sottoposto un sistema, ma non è possibile evitarli. I threats sono di tre tipologie: Failure: un evento che capita quando il delivered service è diverso dal correct service; Error: è la parte dello stato del sistema che può causare il conseguente service failure; Fault: è la causa reale o ipotizzata di un error Attributes Gli attributes sono le proprietà che un sistema dependable deve possedere attraverso le quali viene valutata la qualità dello stesso. Fra queste rientrano: Availability: disponibilità del correct service; Reliability: continuità del correct service; Safety: assenza di conseguenze catastrofiche sugli utenti o sull'ambiente; Integrity: assenza di alterazioni non consentite del sistema; Maintainability: possibilità di operare modifiche e riparazioni; Confidentiality: assenza di distribuzione non autorizzata di informazioni. E' importante notare come l'ultima voce rappresenti un attributo per la sicurezza (securety) del sistema. Su questo aspetto è bene spendere alcune parole. In passato dependability e securety sono sempre state trattate separatamente, nel corso degli anni però queste discipline si sono sempre più avvicinate, e, oggi, la tendenza è considerarle come l'una parte dell'altra. Questa caratteristica può risultare più chiaro se si considera che generalmente la securety tratta un sotto-insieme degli attributes che caratterizzano la dependability. Questi attributi sono in particolare: availability, confidentiality, integrity. Volendo comprendere appieno il perchè la securety comprende questi attributes, facciamo riferimento alla definizione solitamente data di securety: Securety è l'assenza di accessi non autorizzati allo stato del sistema, o della corruzione di tale stato La securety comporta la definizione di alcuni attributes secondari della dependability: Accountability: l'availability e l'integrity dell'identità della persona che compie una operazione; Authenticity: l'integrity del contenuto e dell'origine di un messaggio e, possibilmente, alcune ulteriori informazioni come la data di emissione; Nonrepudiability: l'availability e l'integrity dell'identità del mittente di un messaggio (non si può negare di aver inviato tale messaggio), o del destinatario (non si può negare di averlo ricevuto). Definitions and taxonomy 9

10 Capitolo Means I means sono metodi e tecniche per consentire di provvedere un servizio su cui può essere posta fiducia e per avere una stima della qualità di tale servizio. Sono quattro le pratiche individuate: Fault prevention: previene l'occorrenza o l'introduzione di un fault; Fault tolerance: evita i service failure in presenza di fault; Fault removal: riduce il numero e la gravità dei fault; Fault forecasting: stima il numero attuale, la futura incidenza e le possibili conseguenze dei fault. I primi due mean consentono di fornire un servizio su cui riporre fiducia, i restanti consentono di raggiungere una stima precisa della fiducia che può essere riposta su tale servizio. 1.4 Ciclo di vita di un sistema Il ciclo di vita di un sistema è composto di due principali macro-fasi: development e use. Il nome delle due fasi è autoesplicativo, la prima indica il processo di progettazione e implementazione del sistema, la seconda il processo di utilizzo dello stesso. Nella fase di use possiamo individuare diversi stati del sistema, legati al servizio fornito (Illustrazione 1.3). Illustrazione System lifecycle Development: è la fase che comincia con la presentazione dei concetti iniziali dell'utente ed ha termine con la messa in esercizio del sistema dopo tutti gli eventuali test di accettazione. In questa fase il sistema interagisce con l'ambiente in cui è sviluppato (development enviroment). E' possibile che in questa fase vengano introdotti develpment fault dal development enviroment nel sistema. Con development enviroment si identifica: Physical world: sono i fenomeni naturali. Human developers: le persone che operano alla realizzazione del sistema, che possono essere causa di guasti (per incompetenza, per cattive intenzioni) Development tools: software e hardware utilizzato dagli sviluppatori per realizzare il sistema. Definitions and taxonomy 10

11 Capitolo 1 Production and test facilities: le risorse di produzione e testing del sistema. Use: è la fase che comincia quando il sistema inizia a fornire il suo service agli utenti. Durante questa fase il sistema interagisce con lo use enviroment e potrebbe subire faults originati in questo ambiente. Con use enviroment si identifica: Physical world: sono i fenomeni naturali; Administrators: entità (persone o altri sistemi) che possono gestire, modificare, riparare il sistema (alcuni di questi potrebbero essere incompetenti o avere intenzioni maliziose); Users: entità (persone o altri sistemi) che ricevono il service offerto dal sistema, utilizzandolo tramite la sua interfaccia di utilizzo; Providers: entità (persone o altri sistemi) che forniscono un servizio al sistema tramite la sua interfaccia d'uso; Infrastructures: entità che forniscono servizi specializzati, quali fonti di informazioni, canali di comunicazione, fonti di energia, ecc. ; Intruders: entità maliziose che tentano di infiltrarsi nel sistema, violando le autorizzazioni, per fermare la fornitura del service, alterarlo nel servizio fornito o nelle prestazioni, o che tentano di accedere a dati confidenziali. Rimane da chiarire la pratica del maintenace visibile nell'illustrazione 2.1. Questo processo è una fase di development che può occorrere in qualsiasi degli stati della fase di use. Lo scopo del maintenance è non solo riparare il sistema per risolvere un guasto, ma anche adattarlo ai cambiamenti o migliorarlo. Definitions and taxonomy 11

12 Capitolo Faults I fault seguono una precisa classificazione, utile ad identificarli velocemente e a trattarli nel modo adeguato. In particolare si identificano otto categorie di fault, ciascuna delle quali si suddivide in due tipi di fault (Illustrazione 1.4). Da notare è che un fault può appartenere contemporaneamente a più tipi, in particolare sono 31 le combinazioni fino ad ora identificate, classificate in tre gruppi: develoment faults, physical faults, interaction faults (Illustrazione 1.5). Illustrazione Faults classification Illustrazione I 31 tipi di faults possibili Definitions and taxonomy 12

13 Capitolo 1 La definizione dei fualt è molto importante, in particolare le tre categorie indicano: Development faults: fault che si presentano durante la fase di development; Physical faults: fault che riguardano l'hardware; Interaction faults: fault che hanno tutti origini esterne. La definizione di tutti questi tipi consente all'utente di definire quali classi di fault devono essere inserite nelle dependability specification di un sistema Faults classification In questo paragrafo verranno esaminate alcune delle categorie di fault precedentemente individuate Natural faults Sono physical fault che sono causati da fenomeni naturali in cui non è intervenuto l'uomo. Possono avvenire sia in fase di development che di use. During development: difetti di produzione; During operation (internal): causati da processi naturali che causano deteriorazione dell'hardware; During operation (external): causati da processi naturali che avvengono all'esterno dei confini del sistema e che influenzano l'hardware di quest'ultimo superandone i confini (radiazioni, ecc.), o entrando tramite l'interfaccia di utilizzo del sistema (alimentazione elettrica, ecc.) Human made faults Sono fault causati da azioni umane, incluse le assenze di azioni che invece sarebbero dovute essere compiute (omission fault). Alcuni di questi fault possono essere introdotti in fase di development, ad esempio a causa di necessità di mantenere contenuti i costi o di rendere maggiori le prestazioni. Un altro esempio possono essere i deliberate, non malicious, interaction fault causati dall'utilizzo di una procedura errata compiuta da un utente del sistema, il quale ha operato senza comprendere la possibilità di generare un fault. In questi casi si pone spesso il problema di capire se l'utente ha agito in un modo per incompetenza, negligenza o deliberatamente con cattivi intenti, specialmente quando entrano in gioco responsabilità legali Non malicious development fault Questo tipo di fault è introdotto in modo non voluto durante la progettazione del sistema. Per l'hardware questi fault, rilevati dopo l'avvio della produzione, vengono documentati sotto il nome di errata e costantemente aggiornati nelle specifiche del componente. Nel software questa tipologia di fault procura generalmente il software aging, ossia sono fault dovuti al rilascio di risorse, che causano la necessità di resettare il sistema dopo un certo periodo di utilizzo. Anche l'utilizzo di tool OTS può introdurre questi fault, se il tool stesso presenta dei fault. Generalmente questo è un problema dovuto anche alla mancanza di adeguata documentazione riguardo le vulnerabilità e carenze del tool. Definitions and taxonomy 13

14 Capitolo Malicious fault I malicious fault hanno l'intento di distruggere o arrestare il servizio (denial of service), accedere a informazioni confidenziali, modificare lo stato del sistema impropriamente. Possiamo dividere in due categorie i malicious fault: malicious logic fault, intrusion attemp. I primi possono essere introdotti sia nella fase di development (Trojan, trap door, logic or timing bomb) che nella fase di use (virus, worm, zombie), i secondi sono invece tentativi di intrusione da parte di attori esterni nel sistema sfruttando le sue vulnerabilità. I tentativi di intrusione da parte di attori esterni includono anche i casi in cui chi tenta di forzare il sistema è anche una delle persone impegnate alla sua amministrazione o manutenzione Interaction fault Gli interaction fault sono causati dall'interazione del sistema con l'ambiente e con le persone. Possono avere cause fenomenologiche naturali, molte generate da persone, ma anche che avvengono senza l'intervento dell'uomo (raggi cosmici, ecc.). Una vasta categoria di questi fault è rappresentata dai configuration fault, ossia errori introdotti dall'uomo all'atto della configurazione del sistema, o riconfigurazione dopo un intervento di maintenance Exploit e Vulnerability Queste due definizioni non riguardano propriamente i fault, ma sono la principale causa per cui è possibile che insorgano alcuni di questi fault. La vulnerability è definibile come un fault, che, però, solo assieme all'intervento di un internal threat o external threat comporta un system failure. Un exploit è un'entità software o hardware che attiva una vulnerability del sistema e permette ad un intruder di accedere al sistema. Una vulnerability può essere deliberate perché, ad esempio, per quanto conosciuta non erano presenti le risorse economiche per risolverla. 1.6 Errors Un error è la parte dello stato totale del sistema che può condurre a un system failure. Le cause degli error sono i fault. Se un errore è indicato da un messaggio o da un altro tipo di segnale, si definisce detected, altrimenti latent. Non è detto che la dipendenza fra fault ed error sia di 1 ad 1. E' possibile che un solo fault causi più error nel sistema. Allo stesso modo non è detto che un error comporti un system failure. Questo è in particolare vero se nel sistema ci sono politiche di tolleranza ai guasti, ma potrebbe anche succedere che semplicemente la parte del sistema affetta dall'error non venga mai sollecitata o che l'error sia corretto senza interventi esterni per pura casualità prima che conduca al failure (è questo il caso di un errore in una memoria che viene sovrascritta, cancellando di fatto l'errore, prima di essere nuovamente letta). Definitions and taxonomy 14

15 Capitolo Failures Il failure è un evento che comporta il passaggio del servizio fornito dal sistema da corretto a incorretto (Illustrazione 1.2). E' possibile definire differenti modi di failure, caratterizzati da diversi modi di deviazione rispetto al correct service e da diverse gravità. Una caratterizzazione è possibile in base al dominio del failure, rilevabilità, consistenza, conseguenze sull'ambiente e sulle persone. La gravità del failure si può invece caratterizzare, relativamente alle di failure: in riferimento alla availability: durata del periodo di outage; in riferimento alla safety: conseguenze sulle vite umane; in riferimento alla confidentiality: la natura delle informazioni rubate; in riferimento alla integrity: l'estensione della corruzione dei dati e la possibilità di recuperarli. Un sistema può essere classificato in base alla tipologia di failure in cui può incorrere: Fail controlled: si verificano failure solo in accordo con le specifiche di dependability del sistema; Fail halt (Fail stop): si verificano solo halt failure; Fail passive: si verificano solo stuck-at failure; Fail silent: si verificano solo silent failure; Fail safe: si verificano solo failure di entità minore. A seguito di un failure, perchè il sistema torni a fornire il servizio corretto, è necessario che si operi una service restoration. Questa pratica consiste nel rendere di nuovo disponibile il servizio tramite un meccanismo automatico o assistito manualmente, di recupero, restart o reboot. E' possibile che ad un service restoration corrisponda una corrective maintenance, utile a risolvere fault che hanno causato il failure Development failure I development failure possono avere diverse conseguenze sul progetto del sistema, in particolare possono condurre al project termination o ad un partial fault: Project Termination: Budget: terminano i fondi per realizzare il sistema, prima di arrivare ai test di accettazione; Schedule: il sistema giunge al termine della sua realizzazione quando è ormai obsoleto o inadatto. Definitions and taxonomy 15

16 Capitolo 1 Partial failure: Overrun: il progetto è completato con una spesa di tempo o fondi superiore rispetto a quella prevista. Downgrading: Il sistema è realizzato con funzionalità mancanti, peggiori prestazioni o senza rispettare tutti i requisiti di dependability attesi. Le principali cause alla base dei development failure sono le specifiche incomplete o errate, o un eccessivo cambiamento delle stesse nel corso della progettazione. Allo stesso modo molto spesso potrebbe essere un problema di previsione dei costi di realizzazione o semplicemente il compimento di troppi development fault Dependability e Securety failures Le specifiche di dependability e securety descrivono: i tipi di fault previsti; lo use environment del sistema; controlli di sicurezza nel caso di alcune situazioni indesiderate o pericolose; inclusione di specifiche tecniche di fault prevention o foult tolerance; gli obiettivi per ogni attributo. Un dependability/securety failure avviene quando i failure si presentano più frequentemente e con maggior gravità di quanto previsto nelle specifiche di dependability del sistema. E' importante notare come alcune volte la definizione ingiustificata di requisiti troppo severi possa comportare un development failure. 1.8 Error propagation Gli errori all'interno di un sistema si propagano. Quando un fault diventa attivo produce un error (il fault può essere un dormant fault interno al sistema o un external fault). L'error generato comincia la sua propagazione all'interno del componente in cui si verifica, a causa del processo di computazione che potrebbe quindi generare, a partire dal primo, ulteriori error. Il componente vede quindi propagarsi l'errore fino all'output che potrebbe essere collegato all'interfaccia di un secondo componente, in cui verrebbe quindi innestato l'error. Iterativamente l'error può giungere all'output del sistema, causando un failure. Un particolare su cui porre l'attenzione è che alcuni dormant fault vengono attivati solo a seguito di particolari input (actiovation pattern). Chiaramente un fault interno ad un sistema è rilevabile solo quando genera un error che poi raggiunge l'interfaccia esterna del sistema, ossia un error che comporta un failure. Definitions and taxonomy 16

17 Capitolo Fault: ulteriori definizioni La fault activation reproducibility è l'abilità di riprodurre l'attivazione di un fault che ha causato uno o più error. In base a questo aspetto suddividiamo i fault in due categorie: Solid/Hard fault: l'attivazione del fault è riproducibile; Elusive/Soft fault: l'attivazione del fault non è sistematicamente riproducibile. La maggior parte dei fault presenti nei sistemi complessi appartengono alla seconda categoria. E' possibile anche che i fault si presentino non singolarmente, in particolare possiamo avere single fault e multiple faults. Questi ultimi in particolare possono presentarsi in modo concorrente o sequenziale e generare concorrentemente error nel sistema. I multiple faults possono essere fra loro indipendent o related, a seconda che la loro generazione sia avvenuta casualmente in contemporanea, o che sia avvenuto per una stessa motivazione. In caso di related, i fault generano error fra loro simili. Se questi error portano ad un failure, questo viene detto common-mode failure Trust Praticamente qualsiasi sistema interagisce con altri sistemi e, molto spesso, richiede servizi a quest'ultimi per fornire il proprio servizio. Si pone quindi il problema di come la dependability di un sistema possa essere influenzata da quella di un altro. In particolare un sistema viene definito total dependance di un altro se la sua dependability dipende da quest'ultimo, in caso contrario si definisce complete independance. La dependance di un sistema da un altro può essere accepted, in questo caso la accepted dependance del sistema A dal sistema B viene definita the trust of A on B. L'accettazione della dipendenza può essere wanted, explicit, implicit o anche unwilling, quando non ci sono alternative. Definitions and taxonomy 17

18 Capitolo Means Esaminiamo nel dettaglio i mean della dependability. Come detto in precedenza sono fondamentalmente quattro i mean, che possono essere raggruppati in due categorie: Dependability procurament (Fault prevention + fault tolerance): stabiliscono come premettere al sistema di soddisfare i requisiti presentati nelle specifiche; Dependability validation (Fault removal + fault forecasting): come assicurare con certezza che il sistema risolva i requisiti presentati nelle specifiche Fault prevention La fault prevention si ottiene tramite le buone pratiche di ingegneria, è infatti l'obiettivo ultimo delle metodologie di sviluppo. Chiaramente la fault prevention si raggiunge diversamente a seconda del sistema che stiamo realizzando, le pratiche utilizzate per i sistemi software sono: modularizzazione, information hiding, uso di linguaggi fortemente tipizzati, per i sistemi hardware possiamo invece utilizzare delle regole di progettazione, utilizzare componenti affidabili ecc. In sostanza la fault prevention si ottiene con un miglioramento del processo di sviluppo (development) Fault tolerance Le tecniche di fault tolerance sono presentate in Illustrazione 1.6. Illustrazione Tecniche di fault tolerance Definitions and taxonomy 18

19 Capitolo Error detection L'error detection è la tecnica che consente di individuare gli errori che si sono verificati nel sistema. Può essere realizzata mentre il sistema è in uso, prendendo il nome di concurrent detection, o mentre il sistema ha sospeso la fornitura del suo servizio per la ricerca di latent error e dormant fault, ed allora prende il nome di preemptive detection Error handling L'error handling ha lo scopo di eliminare gli errori dallo stato del sistema. Le tecniche utilizzate per questa attività sono principalmente tre: Rollback: durante la normale esecuzione del sistema vengono salvati degli stati corretti, detti checkpoint, quando si verifica un errore il sistema viene riportato nel più recente di questi stati. Rollforward: se si conosce almeno uno stato successivo in cui il sistema è privo di errori, quando si verifica un error, il sistema può essere immediatamente portato in tale stato. Compensation: l'error viene mascherato dal sistema, poiché lo stato contiene sufficienti ridondanze in modo da permettere al sistema di continuare a fornire il correct service. Le prime due tecniche possono avvenire anche su richiesta dell'utente, dopo che è avvenuta l'error detection. La compensation può invece applicarsi sia su richiesta che sistematicamente, in questo secondo caso si parla di fault masking Fault handling La pratiche di fault handling servono ad evitare che un fault che è stato attivato torni nuovamente ad attivarsi. Generalmente è quindi seguita da corrective maintenance (eseguita da agenti esterni) per eliminare il componente che porta il fault. Se si usa il fault masking c'è il rischio che la replicazione delle componenti vada via via riducendosi fino ad essere del tutto assente, quindi molto spesso a queste tecniche si accompagna l'error detection e possibilmente il fault handling. Le pratiche della fault handling sono quattro: Diagnosis: identifica e memorizza le cause degli errori in termini di locazione e tipo; Isolation: esegue un isolamento fisico o logico del componente guasto per evitare che possa contribuire alla fornitura del system service, in altre parole rende il fault dormant; Reconfiguration: riconfigura il sistema per ridistribuire i task fra i componenti non guasti; Reinitialization: controlla, aggiorna e memorizza la nuova configurazione e aggiorna il sistema. E' bene notare come gli errori intermittenti non richiedano isolation o reconfiguration del sistema, proprio per la loro natura casuale. La loro identificazione avviene tramite error handling ma anche con la fault diagnosis. La preemptive error detection e handling, possibilmente seguita da fault handling sono generalmente eseguite durante l'avvio del sistema. Definitions and taxonomy 19

20 Capitolo Implementazione della fault tolerance La misura della fault tolerance di un sistema prende il nome di coverage. Generalmente le imperfezioni nella fault tolerance sono dovute a fault che avvengono nei meccanismi di fault tolerance, ma anche in base ad assunzioni errate, come ad esempio il comportamento che ha il sistema in caso di fallimento mal previsto, o che si presentino common-mode failure quando invece si erano previsti independent failures. E' importante notare come l'implementazione della fault tolerance vari a seconda dell'estensione con cui si vuole applicarla. Ad esempio, nel caso di fault tolerance applicata a più componenti, questo si traduce in prevenzione della propagazione degli errori. Queste considerazione rendono chiaro come non sia possibile affermare che un meccanismo di fault tolerance sia in assoluto più efficiente di altri. Infatti, la scelta di uno dei metodi di fault tolerance (error detection, error handling, fault handling) è strettamente legata alle assunzioni fatte sui fault da parte degli analisti del sistema, che, come già detto in precedenza, potrebbero anche essere errate. Generalmente la fault tolerance si implementa con la ridondanza, tuttavia, non sempre questo è possibile. Un caso particolare in cui non si può fare affidamento sulla ridondanza, è quando si devono ricevere informazioni da un sensore. Il sensore appare come un componente che non può essere replicato, e quindi, nasce il problema di verificare la correttezza dei dati che fornisce agli altri componenti. Le altre componenti devono quindi raggiungere un accordo per decidere quando le informazioni fornite sono corrette. Questo problema va sotto il nome di consensus problem. Una mancanza nella fault tolerance molto spesso causa una pesante penalità nella dependability del sistema. Generalmente le mancanze sono causate da assunzioni errate sul modello dei fault. E' una pratica comune quella di fare delle assunzioni conservative su tale modello, come ad esempio considerare i fault bizantini. Questa pratica, per quanto incrementi la fault tolerance, potrebbe comportare un aumento consistente del costo del sistema in termini di ridondanza o di meccanismi di fault tolerance Fault tolerance e Securety Tutti gli approcci di fault tolerance possono essere applicati anche ad altre classi di problemi, ed in particolare a ciò che riguarda la securety. Tutti gli approcci possono essere infatti utilizzati su tutte le classi di fault precedentemente trattate. E' possibile dunque trattare gli intrusion e physical fault attraverso la dispersione e frammentazione delle informazioni, malicious logic o anche i virus, tramite flow control checking o tramite design diversity, e così via. Definitions and taxonomy 20

21 Capitolo Fault removal Le tecniche di fault removal possono applicarsi durante le fasi di development e di use Fault removal durante il development Sono tre le fasi che interessano il fault removal: verification, diagnosis, correction. La fase di verification è quella che richiede la maggior attenzione. In particolare la verification può essere di tipo static, se avviene quando il sistema non è in esercizio, o dynamic se viene effettuata provando il sistema in esercizio. La verification, in entrambi i casi, non fa altro che confrontare le caratteristiche del sistema siano in accordo con alcune date proprietà, in particolare se ci si riferisce alle specifiche del sistema stesse, il processo assume il nome di validation. La static verification corrisponde a ispezionare il sistema, tramite anche astrazioni e modelli, per individuare problemi, o inadeguatezza alle specifiche. La dynamic verification può essere fatta fornendo input simbolici al sistema, ed assume il nome di symbolic verification, o può fornire una serie di input reali, realizzando in questo modo il testing. Il testing, per la scelta dei suoi input, può assumere un un approccio fault-based, ossia, partendo dal modello dei guasti il test viene generato appositamente, o criteria-based, in cui si stabilisce un criterio di testing che potrebbe essere ad esempio un criterio di copertura di tutti i possibili input. In entrambi i casi la scelta degli input può essere fatta per vie deterministiche o statistiche. Il testing comporta poi la verifica degli output forniti dal sistema, in questo caso si presenta la necessità di confrontare gli output con dei risultati ritenuti corretti, in modo da giudicare il lavoro del sistema. Questo è un problema noto col nome di oracle problem. In alternativa è possibile confrontare gli output con quelli generati da un altro sistema che effettua le stesse operazioni e che viene considerato valido, il sistema in questione prende il nome di golden unit. Le tecniche appena presentate sono valide anche per il testing della fault tolerance del sistema, in questo caso gli input sono però dei fault, e il processo assume generalmente il nome di fault injection. Dopo la verification, si passa alla diagnosis dei fault che hanno causato il fallimento della verification ed in seguito alla correction degli stessi. A fine del ciclo, si deve provvedere ad una nuova verification per assicurare che il fault sia stato effettivamente eliminato e che non ne siano stati introdotti di ulteriori Fault removal durante l'use Durante la fase di utilizzo il fault removal si traduce con la manutenzione correttiva o preventiva del sistema. La prima si effettua per correggere errori che si sono verificati nel sistema, la seconda per evitare che fault individuati possano tradursi in errori. In entrambi i casi la manutenzione può essere fatta, a seconda delle caratteristiche del sistema, online o offline (causando in questo secondo caso un service outage). Definitions and taxonomy 21

22 Capitolo Fault forecasting Il fault forecasting consiste nel valutare il comportamento del sistema rispetto all'attivazione o all'occorrenza di fault. In particolare si possono operare due metodologie: qualitative evaluation: ha lo scopo di identificare e classificare i failure o la combinazione di eventi che porta ad un failure; quantitative evaluation: che ha lo scopo di valutare il limite in cui alcuni attributi sono soddisfatti. Molte tecniche sono utilizzate in entrambi i casi, altre sono invece specifiche. Dal punto di vista dell'approccio probabilistico (quantitative evaluation) le principali tecniche sono due: modeling e testing. Questi sono approcci complementari poiché il modellamento del sistema richiede la conoscenza di alcuni dati della realtà da modellare che possono essere ottenuti tramite testing o tramite lo studio dei casi di failure. Nel caso di uso di modelli si deve chiaramente prima costruire il modello e validarlo, in seconda istanza vanno effettuate le misurazioni di dependability su tale modello. Si può introdurre la nozione di dependability and securety benchmark che include una serie di pratiche di fault forecasting per valutare la dependability di un sistema in presenza di fault. Definitions and taxonomy 22

23 Capitolo 2 Capitolo 2 Fault characterization L'analisi della reliability di un sistema include certamente la modellazione della tipologia di fault di cui il sistema può essere vittima. Caratterizzare i fault suddividendoli in tipologie e creare modelli per trattarli in modo sistematico, è un lavoro fondamentale per riuscire a dominare la complessità del sistema. Chiaramente, il modello dei fault non è unico, ma è strettamente legato al sistema cui si fa riferimento ed al livello di astrazione con cui si osserva il sistema stesso. 2.1 Fault classification E' possibile suddividere i fault in alcune categorie in base al tempo ed alla periodicità con cui questi si manifestano. E' possibile anche individuare quale difetto è alla base di un fault di una determinata categoria (Illustrazione 2.1). Illustrazione 2.1: Fault Classification Alcune delle categorie individuate di fault possono essere riparate (Permanent, Intermittent fault) altre invece non possono avere rimedio (Transient fault). Fault characterization 23

24 Capitolo 2 Questo deriva dall'origine stessa dei fault. I permanent fault sono causati da difetti in fase di progettazione o da malfunzionamenti fisici, la riparazione consiste quindi nel migliorare il progetto, correggendo gli errori o nel riparare/sostituire la parte fisica non funzionante. Gli Intermittent fault sono anch'essi generati da difetti di progetto, o anche dall'utilizzo di hardware di cattiva qualità o ad ogni modo instabile. Anche in questo caso è dunque possibile intervenire opportunamente per riparare il fault. I Transient fault non possono essere riparati. A generare un transient fault è infatti una particolare e momentanea condizione dell'ambiente del sistema. Questa circostanza può generare, ad esempio, un malfunzionamento nell'hardware del sistema per un ristretto periodo di tempo, senza danneggiarlo. L'hardware è quindi integro, ma ha funzionato in modo anomalo per qualche tempo, causando il fault. Maggiori dettagli su Transient e Intermittent fault sono trattati in [3]. Le categorie di fault individuate differiscono anche per la frequenza con cui si presentano i fault. Gli studi condotti nel corso dei decenni hanno evidenziato come i fault più frequenti siano gli Intermittent fault e i transient fault. Decisamente rari sono invece i permanent fault. 2.2 Fault model Come anticipato, l'analisi della reliability di un sistema prevede al conoscenza dei fault che possono interessare tale sistema. A questo scopo è necessario specificare dei modelli per i fault che possono colpire il sistema. Sostanzialmente il modello dei fault non fa altro che specificare come i fault si manifestano. Se consideriamo un circuito elettronico, i fault possono presentarsi ad un livello fisico manifestandosi come rottura di un conduttore o in altro modo. E' possibile, tramite opportuni algoritmi o simulazioni, non considerare un modello fisico per i fault, ma ricondursi ad un modello logico. Nel caso di un circuito elettronico considerato ad un livello logico, possiamo idenficare 4 differenti fault model: 1. stuck-at: una ramo della rete ha valore fissato (1 oppure 0). La causa può provenire da multipli physical fault. La gestione del modello di stuck-at è semplice in quanto i fault stessi possono essere numerabili. 2. short (bridge): un ramo di un circuito è fisicamente collegato ad un altro ramo. A seconda del tipo di tecnologia, il risultato del fault può essere la predominanza di un 1 logico o di uno 0 logico. Sempre in base al tipo di tecnologia, alcune configurazioni della rete logica non permettono di rilevare un fault anche quando si è verificato. 3. stuck-on / stuck-open: fisicamente corrisponde ad un transistor sempre in conduzione o sempre interdetto. Fault characterization 24

25 Capitolo 2 4. delay fault: quando la logica della rete elettronica è priva di errori, possono comunque verificarsi dei fault dovuti al superamento di certi valori limite di ritardo nella propagazione dei segnali. Principalmente i modelli adottati per questa tipologia di fault sono due: Gate Delay e Path Delay, a seconda che si consideri il ritardo sulle porte logiche o sul conduttore di collegamento fra le porte. Il modello dei fault è altamente influenzato da fattori tecnologici, di ciclo di vita, e dal tipo di circuito. A conferma di quest'ultima affermazione, basti pensare al caso di uno short, che in una rete logica con tecnologia a predominanza di 1 comporta un risultato, differente da quello che si otterrebbe in una rete con tecnologia a predominanza di 0. I modelli di fault presentati sono solo una piccola parte. Generalmente si utilizzano modelli di fault specifici ad un determinato tipo di circuito, come ad esempio una memoria (Coupled values, Pattern sensitive faults, ecc). 2.3 Accelerating faults manifestation La valutazione delle caratteristiche di un sistema è molto complessa. Molto spesso è necessario osservare i failure mode di un sistema per comprendere meglio i problemi che lo affliggono ed il suo comportamento. Questa necessità si scontra con le caratteristiche di molti sistemi, che spesso presentano un tempo di vita molto lungo, che non consente di attendere un evento di failure. Anche quando questo fosse possibile, molto spesso si presentano necessità di natura economica che impongono la riduzione al minimo dei tempi fra progettazione e distribuzione del sistema. Queste necessità rendono necessario un approccio differente al testing dei sistemi, che viene solitamente indicato come Accelerated Life Testing. Sostanzialmente questo approccio forza il prodotto in modo da far comparire un failure più velocemente di quanto avverrebbe in condizioni normali d'uso. Sono due i tipi di Accelerated Life Testing: Qualitative Accelerated Testing, Quantitative Accelerated Testing (Illustrazione 2.2). Illustrazione 2.2: Accelerated Testing Fault characterization 25

26 Capitolo Qualitative Accelerated Testing Questa pratica si attua quando si è maggiormente interessati ad identificare i failure ed i failure mode senza intenzione di fare predizioni quali il tempo di vita del prodotto in condizioni d'uso normali Quantitative Accelerated Testing Questa pratica viene attuata quando si intende ottenere parametri indicativi delle caratteristiche del sistema quando è in condizioni normali d'uso. Sono due le tipologie di tecniche utilizzate: Usage rate acceleration: si accelera la frequenza di utilizzo del sistema (Ad esempio si utilizza per un giorno intero un sistema che prevede un tempo continuo di lavoro di massimo qualche ora). Stresses and Stress levels: accelera i failure modes ma non introduce failure mode che non potrebbero mai capitare in condizioni normali (Sostanzialmente si pone il sistema in condizioni di funzionamento limite). Quando si attua questa pratica di testing è fondamentale porre massima attenzione nel non introdurre failure modes che in condizioni normali d'uso non potrebbero mai presentarsi, ma che sono causati dalle particolari condizioni di testing create. 2.4 Lifetime of a population of products Illustrazione 2.3: The Bathtub curve In Illustrazione 2.3 è mostrata la curva del failure rate assunta dalla maggior parte delle popolazioni di prodotti. Nella fase di distribuzione iniziale, la possibilità di fallimento è massima. Fault characterization 26

27 Capitolo 2 A regime si riduce al minimo, mentre verso la fine della vita del prodotto, la probabilità di fallimento sale vertiginosamente. 2.5 Standard based reliability prediction Un metodo alternativo per la stima della reliability di un sistema è quello di affidarsi a modelli standard riferiti alla categoria di prodotti di cui è costituito il sistema. Per permettere questo tipo di stima si formula una ipotesi basilare: se i componenti sono fra loro indipendenti, i rispettivi failure rate sono costanti. Un esempio significativo è il Military Handbook 217F che riporta modelli per vari tipi di componenti elettronici, elettrici ed elettro-meccanici. Partendo da questo documento è possibile condurre due analisi: 1. Part count: si tiene conto della quantità di componenti, del livello di qualità e dell'ambiente in cui lavoreranno, per ottenere delle prime stime utili in fase di progetto. 2. Part stress analysis: si utilizzano informazioni più dettagliate sul prodotto e sul suo utilizzo per ottenere indicatori precisi dei parametri di affidabilità. 2.6 Fault prevention Tutti gli studi che analizzano i fault e i failure mode hanno come fine ultimo quello di garantire che il sistema possa evitare tali problematiche. Viene quindi condotto uno studio preliminare sui fault per poi attuare al sistema gli opportuni provvedimenti per l'eliminazione degli stessi. Questa pratica va generalmente sotto il nome di fault prevention, e come detto nel capitolo 1, è uno dei mean della dependability. La fault prevention, quindi, cerca di ottenere la reliability del sistema evitando in principio che si verifichino i fault. A tale scopo, in fase di progetto, si seguono una serie di pratiche per ridurre al minimo il rischio di fault: Forzare specifiche condizioni per garantire il failure rate desiderato ( temperatura, qualità, ecc.) Utilizzo di progettazione conservativa, come ad esempio l'uso di componenti ad alta reliability. La fault prevention comporta un grande sforzo in fase di progettazione per ridurre la possibilità di fault. Tuttavia, è praticamente impossibile evitare tutti i possibili fault che potrebbero occorrere, e, quindi, il sistema potrebbe comunque arrivare ad un failure. Per queste ragioni un sistema che applica solo la fault prevention, viene detto fault intolerance. Fault characterization 27

28 Capitolo 3 Capitolo 3 Introduction to reliability theory Per trattare della reliability di un sistema è necessario fare affidamento a nozioni probabilistiche e statistiche, in quanto, non è possibile prevedere in modo deterministico malfunzionamenti o difetti del sistema. In questo capitolo si introducono i concetti base legati all'uso della probabilità nella modellazione di sistemi di cui si vuole studiare la reliability. Per maggiori dettagli si consiglia di consultare [4]. Cenni sulla teoria della probabilità sono presenti in appendice a questo testo. 3.1 Statistical definition of dependability figures Una definizione di reliability è: continuità del servizio corretto. Questa definizione può essere alternativamente espressa come la probabilità che il sistema lavori senza failure in un certo periodo di tempo. Questa seconda definizione è più agevole per identificare dei concetti legati alla teoria della probabilità. In particolare si può descrivere il tempo di failure del sistema con una variabile aleatoria: T f =time to failure Da questa è possibile definire le funzioni di reliability e unreliability. In particolare queste due funzioni rappresentano, rispettivamente, la probabilità che il TTF (time to failure) sia maggiore del tempo t, e la probabilità che il TTF sia minore del tempo t. R t =P T f t =1 F t Reliability function F t =P T f t Unreliability function Si definisce inoltre il Mean Time to Failure, ossia il tempo medio di occorrenza di un failure come: E [T f ]=Mean Time to Failure (MTTF) Essendo le quantità appena definite delle probabilità, e considerando il significato logico che assumono, valgono le seguenti proprietà: R t F t =1 R 0 =1, F 0 =0 R =0, F =1 Introduction to reliability theory 28

29 Capitolo 3 Si può infine definire la funzione failure density function, che direttamente dalla teoria della probabilità risulta essere: f t = df dr = dt dt Hazard rate E' possibile definire un ulteriore parametro per caratterizzare il comportamento di un sistema, l'hazard rate. Tale parametro indica la frequenza con cui un sistema va incontro ad un failure (Espresso ad esempio in numero di fallimenti per anno). Definiamo il prodotto: f t t =P t T f t t L'hazard rate h(t) viene definito come: h t t=p t T f t t T f t h t t =P t T f t t T f t = P t T f t t f t t = P T f t R t da cui si ricava l'espressione per l'hazard rate: h t = f t R t si può inoltre facilmente verificare: h t = f t dr t 1 dr t = = h t dt R t dt R t R T Se consideriamo la distribuzione dei failure esponenziale, le funzioni di reliability e unreliability assumono la seguente espressione in dipendenza del hazard rate: t h x dx R t =e 0 t t h x dx F t = f x dx F t =1 e 0 0 t f t =h t e h x dx 0 Spesso si indica h t =. Introduction to reliability theory 29

30 Capitolo Availability Un sistema si può trovare sostanzialmente in due stati: Correct: il sistema sta fornendo il servizio corretto; Incorrect: il sistema non sta fornendo il servizio corretto. La transizione fra stato correct ed incorrect avviene all'occorrenza di un failure. Nel caso in cui il sistema sia riparabile, è possibile anche effettuare la transizione inversa tramite un system restoration (Illustrazione3.1). Illustrazione3.1: Stati di un sistema In questo caso è possibile definire una ulteriore caratteristica del sistema che va sotto il nome di availability, che indica la probabilità che il sistema fornisca il servizio corretto. Analogamente si possono definire parametri caratteristici quali: MTBF: Mean time between failure, ossia il tempo medio che intercorre fra due occorrenze di un failure. MDT: Mean down time, ossia il tempo medio di permanenza in uno stato di incorrect service. Generalmente si indica l'availability con: A t =P to be in t Solitamente si calcola il valore dell'availability nel seguente modo: A = MTBF MTBF MDT Se invece il sistema segue una degradazione parziale del servizio si utilizza il MTTSF (Mean Time To Service Failure): A = Introduction to reliability theory MTTSF MTTSF MDT 30

31 Capitolo Reliability Block Diagrams Il modello di reliability a blocchi immagina il sistema come suddiviso in un numero finito di entità (i blocchi) che possono essere messi in comunicazione fra loro secondo diverse configurazioni. Si suppone che l'uscita di un blocco sia l'ingresso del blocco successivo Series configuration La configurazione in serie prevede che i blocchi siano organizzati sequenzialmente uno dietro l'altro, con uscita del blocco i-esimo collegata all'ingresso del blocco i+1-esimo (Illustrazione 3.2). Illustrazione 3.2: Series configuration Definiamo le probabilità di successo e fallimento del sistema come le probabilità di fornire o meno il servizio corretto: R= P s=p x 1 x 2 x 3 x 4... x n =P x 1 P x 2 x 1 P x 3 P x 3 x 1 x 2... P x n P x n x 1 x 2... x n 1 Se i blocchi (anche detti units) sono fra loro indipendenti: P s =P x 1 P x 2 P x 3... P x n In una configurazione in serie, quindi, il failure di un singolo blocco comporta il fallimento dell'intero sistema. In questi casi si deve sempre intervenire per migliorare la reliability del blocco più debole Parallel configuration La configurazione in parallelo prevede che i blocchi siano organizzati in modo da ricevere gli ingressi in parallelo, con uscita del blocco i-esimo collegata a più ingressi dei blocchi successivi(illustrazione 3.3). Illustrazione 3.3: Parallel configuration In questo caso la probabilità di fallimento è data da: P f =P x1 x 2... x n Introduction to reliability theory 31

32 Capitolo 3 Da questa espressione ricaviamo: R=P s =1 P f P s =1 P x 1 P x 2 x 1 P x 3 P x 3 x 1 x 2... P x n P x n x 1 x 2... x n 1 In questo caso il failure del sistema è causato dal fallimento di tutti i blocchi in parallelo. Per queste configurazioni, per aumentare la reliability del sistema, è conveniente aumentare la reliability del blocco con maggiore reliability R-out-of-N configuration In questo tipo di configurazione, si effettua una ridondanza sui blocchi del sistema. Il sistema funziona correttamente fintanto che sono funzionanti almeno R degli N blocchi presenti nella configurazione (Illustrazione 3.4). Illustrazione 3.4: R-out-of-n configuration Nel caso di blocchi tutti uguali, la probabilità di successo si caratterizza tramite una distribuzione binomiale: n n P s = B k ; n = n p 1 p k=r k=r k k n k Nel caso generale in cui i blocchi non sono tutti uguali, è necessario procedere con una enumerazione: Illustrazione 3.5: R-out-of-n configuration, general case R= P s=p x 1, x 2 P x1, x 3 P x 2, x 3 Chiaramente da questa configurazione si ottengono i due casi limite di serie e parallelo, in particolare: R = N => Configurazione in serie R = 1 => Configurazione parallela Introduction to reliability theory 32

33 Capitolo Complex configuration Molto spesso è difficile individuare un sistema come aderente ad una delle precedenti configurazioni, per la complessità della struttura a blocchi che presenta. In questi casi si utilizzano dunque dei metodi di analisi del sistema. Questi metodi suddividono opportunamente il sistema per studiarne le caratteristiche di affidabilità Tie-set Il metodo del Tie-set individua un set di componenti il cui corretto funzionamento garantisce il corretto funzionamento del sistema. Illustrazione 3.6: Configurazione complessa d'esempio Nell'esempio di Illustrazione 3.6 i tie-set sono due e sono i cammini: x1, x3, x4 ed x2, x4. Generalmente si indica come tie-set minimo, il cammino che presenta meno elementi Cut-set Il metodo del Cut-set prevede che si individuino i set di componenti il cui fallimento causa il fallimento dell'intero sistema. Il cut-set minimo è quello che non contiene altri cut-set. In riferimento all'esempio di Illustrazione 3.6, i cut-set sono: x1, x2; x3, x2; x Fault Tree analysis Il Fault Tree Analysis (FTA) è una tecnica alternativa ai RBD, che considera gli eventi cui va incontro il sistema piuttosto che i blocchi che lo compongono. Il verificarsi di alcuni eventi può portare al verificarsi del top event, ossia ad un fallimento del sistema. Il modo in cui si combinano gli eventi che danno luogo al top event, è indicativo della configurazione del sistema. Di seguito sono presentati i casi di configurazione in serie (Illustrazione 3.7) ed in parallelo (Illustrazione 3.8) tramite FTA : Illustrazione 3.7: FTA series Introduction to reliability theory 33

34 Capitolo 3 Illustrazione 3.8: FTA parallel 3.4 Failure mode effect analysis La Failure Mode Effect Analysis (FMEA) è una procedura sistematica per identificare i modi di fallimento e per valutare le conseguenze di tali fallimenti. Percheè possa essere effettuata, richiede che siano identificate alcune entità: Items Functions Failures Effects of Failures Causes of Failures Current controls Recommended actions other relevant details Sostanzialmente la FMEA realizza delle schede in cui le suddette informazioni vengono catalogate, in modo da avere una trattazione schematica delle problematiche che può avere il sistema. 3.5 Risk evaluation Risk priority number Il Risk priority number è utilizzato per comparare le caratteristiche individuate all'interno dell'analisi FMEA e, quindi, per stabilire delle priorità per le azioni correttive. Chiaramente, l'utilizzo di questo parametro impone che il team di analisi dia una misura alle conseguenze di un failure, alla probabilità che si presenti un tipo di failure, alla probabilità di scoperta preventiva di ogni causa del failure. Per calcolare il Risk Priority Number (RPN) si usa poi la relazione: RPN = Severity x Occurrence x Detection Introduction to reliability theory 34

35 Capitolo Criticality analysis La Criticality analysis può essere condotta in due modi: quantitative, qualitative Criticality analysis: quantitative Viene definita la reliability/unreliability per ogni item, ad un prefissato tempo operativo. Si identifica poi la porzione dell'unreliability di un item che può essere attribuita ad ogni possibile failure mode. Successivamente si definisce una misura per la probabilità di danno causata da ogni failure mode che può verificarsi. Stabilite queste informazioni si procede a calcolare la failure mode criticality e la item criticality nel seguente modo: Mode criticality: Item unreliability x Mode Ratio of Unreliability x Probability of Loss Item criticality: SUM of Mode Criticalities Criticality analysis: qualitative L'analisi qualitativa misura la gravità dei potenziali effetti di un failure, misura la probabilità di occorrenza di ciascun failure mode. Vengono poi comparati i failure modes tramite una Criticality Matrix, che presenta sull'asse orizzontale le possibili gravità e le occorrenze dei failure modes sull'asse verticale. 3.6 Markov modeling Possiamo utilizzare due variabili aleatorie per indicare lo stato del sistema e il tempo di osservazione del sistema, rispettivamente x e t. Tali variabili possono essere entrambe continue o discrete. Viene definito processo di Markov l'esperimento che ha la variabile t continua e la variabile di stato x discreta. Il modello di Markov si applica ai processi di Markov ed è caratterizzato da: p ij che rappresentano la probabilità di transizione dallo stato i allo A: matrice formata dai stato j. Markov property: la probabilità p ij dipende da i e j, ma non dipende da nessuno stato passato (escluso chiaramente lo stesso i). Se per ipotesi consideriamo il sistema composto da una unità non riparabile x1, possiamo definire due stati: S0, S1, corrispondenti alle situazioni x1 funzionante ed x1 non funzionante. Lo stato in cui si trova il sistema al tempo iniziale (t=0) è detto stato iniziale. Gli stati che rappresentano uno stato finale o di equilibrio del sistema, si dicono stati finali. E' possibile definire una regola di probabilità della transizione fra stati. Introduction to reliability theory 35

36 Capitolo 3 Transition probabilites rule: La probabilità di transizione al tempo t è data da h t t, dove h(t) è l'hazard rate dello specifico stato. Qualora l'hazard rate fosse costante per ogni stato, il modello si dice omogeneo. Si considera la probabilità di avere più di una transizione al tempo t infinitesima. Tenendo conto della precedente regola e del sistema illustrato, possiamo esprimere la probabilità che il sistemi si trovi nello stato S0 al tempo t t : P S0 t t = 1 h t t P S0 t 0PS1 t La precedente formula, in parole, dice che la probabilità di trovarsi in S0, al tempo specificato, è data dalla probabilità del sistema di essere in S0 per la probabilità che non ci sia un failure a quel tempo ( 1 h t t ). La seconda parte della formula serve ad introdurre una variante per i sistemi riparabili, in questo caso però, non essendo tale il sistema considerato, la probabilità che venga riparato è posta a 0 e quindi la seconda parte della formula è nulla. La probabilità di essere in S1 è invece data da: P S1 t t = h t t P S0 t 1PS1 t Chiaramente la formula è analoga alla precedente a livello concettuale. Introduction to reliability theory 36

37 Capitolo 4 Capitolo 4 Dependability mean: Error detection Fra i dependability mean, individuati nel capitolo 1, rientra la pratica dell'error detection. Tale pratica è fondamentale per altri dependability mean quali la fault tolerance, poiché permette di identificare un tipo di errore e, di conseguenza, di agire nel modo opportuno. 4.1 Fault tolerance La pratica fondamentale in cui si richiede error detection è la fault tolerance. Per applicare la fault tolerance è necessario l'uso di ridondanza per ottenere informazioni sufficienti a negare gli effetti di un errore. Generalmente la ridondanza si traduce in tempo aggiuntivo nelle elaborazioni del sistema o in risorse aggiuntive. Il primo caso si ha specialmente nel software, poiché una elaborazione viene ripetuta più volte nel tempo, anche con algoritmi differenti, per verificarne la correttezza del risultato. Il secondo caso è invece applicato generalmente a livello hardware, con la replicazione di componenti, quali celle di memoria addizionali, utilizzo di porte logiche aggiuntive ecc. La fault tolerance contempla una serie di operazioni: Error confinement: limitazione degli effetti di un fault ad una sola area del sistema, prevenendo la contaminazione di altre aree. Error detection: riconoscimento dell'avvenimento di qualcosa di inatteso nel sistema. Diagnosis: necessaria se la error detection non fornisce informazioni sulla locazione e sulle proprietà dell'errore riscontrato. Reconfiguration: viene scoperto un fault e localizzato un permanent failure. Error processing: elimina gli effetti dei fault. Restart: riavvia il sistema dopo aver eliminato gli effetti del fault. Repair: un componente che ha causato il fault viene sostituito. Reintegration: il componente riparato può essere reintegrato nel sistema. Dependability mean: Error detection 37

38 Capitolo 4 In Illustrazione 4.1 viene mostrato un grafico temporale che illustra il susseguirsi delle precedenti operazioni. Illustrazione 4.1: Grafico temporale delle operazioni di fault tolerance In Illustrazione 4.2 è invece presentata la tassonomia delle operazioni precedentemente descritte. Illustrazione 4.2: Taxonomy of fault tolerance operations I sistemi non ridondanti, presenti in figura, sono quelli esaminati nel capitolo 2 come sistemi che effettuano la fault prevention. Dependability mean: Error detection 38

39 Capitolo Error detection A meno che non si applichi una fault prevention ideale, i fault, ed i conseguenti error, possono colpire il sistema. Per questo motivo è necessario identificare gli errori, ossia, è necessario praticare l'error detection. L'idea di base è che se tutti gli error sono individuati, e se sono applicate per ognuno opportune tecniche di recupero, non si potrà mai giungere ad un failure. Quindi, maggior error detection viene praticata, maggiore è la reliability del sistema. Nella pratica bisogna tener conto di alcuni limiti: Costi: l'error detection richiede ridondanza, e tale ridondanza potrebbe essere anche molto costosa; Tempo: eseguire dei controlli porta via del tempo, non sempre è possibile sacrificare del tempo di elaborazione; Risoluzione della diagnosi: non sempre si riesce a confinare un error nella regione del sistema desiderata Ideal check Un controllo esaustivo di errori è quello che consente di affermare: se nessun errore è rilevato dal controllo, allora non ci sono errori. Illustrazione 4.3: Ideal check Un controllo ideale segue alcuni criteri: Il check deriva esclusivamente dalle specifiche del sistema. Il check controlla l'intero comportamento del sistema. Il check è indipendente dal sistema Acceptability check Un check di accettabilità tenta di rilevare il maggior numero possibile di errori, cosi' da incrementare la confidenza nelle operazioni del sistema. Per progettare un acceptability check, è necessario fare alcune assunzioni su: comportamento del sistema; comportamento dell'ambiente in cui lavora il sistema; possibili fault che possono occorrere. Dependability mean: Error detection 39

40 Capitolo 4 Il successo del check dipende dalla correttezza di tali assunzioni. Tuttavia, poiché non stiamo più considerando un check ideale, si presenta la problematica di assicurarsi che il check stesso sia corretto. In altre parole si pone il quesito: chi controlla il controllo?. Generalmente queste problematiche trovano risposta nella particolare strategia adottata dal progettista. Anche il momento in cui viene eseguito un check ne caratterizza la tipologia, in particolare si definiscono due tipi di check: Last moment check: il controllo viene eseguito dopo la realizzazione dell'output, ma subito prima del rilascio di tale risultato all'utente; Early check (internal): il controllo viene eseguito il prima possibile, durante le operazioni del sistema che producono il risultato, in questo modo si minimizza il lavoro sprecato. Sarebbe preferibile prevedere entrambi i tipi di check in un sistema, per godere dei benifici propri dei due tipi, tuttavia non sempre questo è possibile Types of check I check possono essere di diversi tipi, nel seguito ne sono presentati schematicamente alcuni Replication check Nel replication check si utilizzano due copie identiche di un modulo del sistema, che lavorano in parallelo. I risultati dei due moduli vengono confrontati da un comparatore (Illustrazione 4.4), che rappresenta l'essenza del check stesso. Se il comparatore è corretto e i fault che colpiscono i moduli sono indipendenti, allora tutti gli error verranno rilevati (Escluso il caso limite in cui entrambi i moduli falliscono allo stesso modo, nello stesso tempo). Illustrazione 4.4: Replication check Il precedente schema può essere esteso con l'utilizzo di N copie anziché 2, chiaramente a fronte di un aumento dei costi, si ha un aumento della probabilità di rilevare tutti gli errori. E' possibile utilizzare questo tipo di check per valutare la presenza di errori nella fase di progettazione di un modulo. In questo caso, invece di copie del modulo, si utilizzano versioni differenti. Ad esempio, si utilizza la versione appena progettata in combinazione con la versione precedente e già testata. In questo modo vengono rilevati eventuali discrepanze della nuova versione rispetto al comportamento di quella precedente, che possono essere causate da errori di progetto. Non sempre il replication check è applicabile allo stesso modo, talvolta è necessario prendere opportuni accorgimenti a seconda del sistema o del modulo che bisogna controllare. Ad esempio, nel caso in cui si volesse applicare il replication check ad una memoria, si utilizza la tecnica del Swap and Compare. Tale tecnica prevede che i dati contenuti nella memoria vengano replicati, ma non nello stesso ordine con cui sono memorizzati. Infatti, i fault nella memoria tendono a colpire aree contigue, e, quindi, memorizzare dei dati replicati nella stessa area di quelli originali, non permetterebbe la rilevazione degli errori. Dependability mean: Error detection 40

41 Capitolo 4 In (Illustrazione 4.5) è presentata la tecnica come verrebbe applicata per la replicazione di due celle di memoria. Illustrazione 4.5: Replication check per due celle di memoria La replication check ha il grande vantaggio di rendere non necessario qualsiasi altro controllo, a livello più basso, per la rilevazione di errori nel sistema. Sono presenti, tuttavia, una serie di svantaggi che limitano l'utilizzo di questo controllo: Costo: il costo dell'unità replicata è più che raddoppiato; Prestazioni: le prestazioni del sistema subiscono una degradazione, dovuta a problemi di sincronia fra i moduli replicati e il comparatore ed al tempo aggiuntivo dovuto all'elaborazione che deve eseguire il comparatore stesso; Spreco di risorse: chiaramente, tutti i componenti usati per replicare, non possono essere utilizzati in altro modo, e, quindi, rappresentano pura ridondanza. Talvolta si utilizza anche una versione limitata del replication check, al solo scopo di rilevare i transient fault. In questo caso si adopera lo stesso modulo, sequenzialmente, e poi se ne comparano le uscite Timing check Il timing check si adopera per verificare che requisiti sul tempo, quando imposti dalle specifiche del sistema, siano rispettati. Qualora il check fallisse, verrebbe sollevata un'eccezione. Un controllo di questo tipo è in realtà limitato, poiché se non sono sollevate eccezioni, questo non è indice che il sistema stia effettivamente lavorando correttamente. D'altronde lo scopo del timing check non è individuare errori nel sistema, ma verificare che sia rispettata una specifica sul tempo. In ambito software, molto spesso, il timing check si traduce nei watchdog timer. In questi controlli, periodicamente, il software deve resettare un timer per indicare che sta lavorando correttamente. Qualora il timer dovesse superare un certo valore, viene sollevata un'eccezione Reversal check Il reversal check prevede che, a partire da un output, si effettui l'operazione inversa da quella eseguita dal modulo controllato, per risalire agli input. Si comparano poi gli input calcolati, con quelli ricevuti dal sistema inizialmente e che hanno generato l'output. Questo sistema, per quanto efficace, richiede che la relazione fra input e output sia di tipo uno a uno (come avviene nelle reti combinatorie) e che l'elaborazione inversa sia relativamente diretta. La realizzazione di questo controllo è semplice ed indipendente dal sistema, tuttavia è fortemente dipendente dalle specifiche del sistema, e, quindi, non è consigliata per realizzare controlli sui design fault. Dependability mean: Error detection 41

42 Capitolo Coding check I coding check utilizzano ridondanza nella rappresentazione dei dati, per verificare la correttezza degli stessi. Una informazione può infatti essere rappresentata utilizzando uno specifico codice, generalmente i codici sono formati da un certo numero di simboli. Si indica con word una possibile combinazione dei simboli utilizzati per la rappresentazione dei dati. Con code word si intende invece il sottoinsieme di word che hanno significato per lo specifico codice adottato. Come esempio si possono riportare le parole del vocabolario italiano. Una code word è una parola del vocabolario ( casa ), i simboli sono le lettere dell'alfabeto. Una generica word è abfdghe che è una combinazione di lettere dell'alfabeto, ma non rappresenta una word appartenente al codice del vocabolario italiano. Per studiare le possibilità di utilizzo di ridondanza nella codifica dell'informazione, per la error detection ( ma anche per altre applicazioni), è utilizzare la definizione di distanza di Hamming. Hamming distance: la distanza di Hamming fra due word è il numero di bit differenti fra le due word. Ad esempio, le word 110 e 111 hanno come distanza di Hamming 1, mentre 100 e 111, hanno distanza 2. La minima distanza d di un codice è la minima distanza fra due qualsiasi word di quel codice. Una distanza minima d consente di rilevare fino a t d errori. La teoria dei codici ridondanti è molto vasta e studia innumerevoli soluzioni per risolvere non solo la rilevazione dell'errore ma anche una sua eventuale correzione. Generalmente si usa dividere i codice in base al modo in cui si costruisce la ridondanza: Separable code: la word è costituita da una parte che contiene l'informazione originale, e da una che rappresenta la ridondanza di controllo. Linear separable code: sono separeble code dove la parte ridondante è ottenuta come combinazione lineare dei bit dell'informazione originale. Fra questi ultimi codici si possono segnalare i più comuni: M-of-N code: una word contiene esattamente M bit ad 1 su N totali; Parity: la word ha sempre un numero pari (oppure dispari) di bit 1, il bit aggiuntivo ridondante deve essere aggiunto per verificare la parità; Checksum: i bit dell'informazione vengono sommati fra loro (con modulo-n prestabilito) ed il risultato della somma viene aggiunto in coda ai bit dell'informazione; Arithmetic code: un codice aritmetico soddisfa la proprietà A b c = A b A c, dove b e c sono sono operandi non codificati, * è una operazione aritmetica e A(x) è una word di codice aritmetico. Oltre al modo in cui creare la ridondanza, si può anche decidere di adottare strategie differenti nell'applicarla. E' possibile infatti immaginare di aggiungere una ridondanza ad una word di un codice, o ad ogni byte di informazione, oppure ancora organizzare i dati in una matrice e assegnare ad ogni riga/colonna una ridondanza di controllo, o altro ancora. In riferimento all'organizzazione delle memorie, è possibile anche immaginare di assegnare una ridondanza al singolo chip o a combinazioni di questi. Dependability mean: Error detection 42

43 Capitolo Reasonableness check Un ulteriore categoria di check è quella basata sul controllo dello stato di un oggetto (astratto) del sistema, che deve rientrare entro un certo insieme di valori per avere un significato corretto. Ad esempio se nel sistema c'è un oggetto che tiene memoria del valore di un angolo, tale valore non potrà essere al di fuori dell'intervallo [0 ; 360 ]. Nei sistemi software si utilizzano le assertions, per indicare una espressione logica che rappresenta un reasonableness check Structural check Gli structural check sono controlli che si applicano alle strutture dati, e che verificano il contenuto dei dati nella struttura (Se sono consistenti con quanto dovrebbe contenere la struttura) e la consistenza della struttura stessa (se è rispettata la configurazione della struttura). Questi controlli sono indicati specialmente per strutture dati complesse, quali code, alberi, liste. Sono fondamentalmente tre le fonti di ridondanza su cui poter basare il controllo: conteggio del numero di elementi nella struttura; puntatori ridondanti; informazioni aggiuntive sullo stato (sul tipo) dell'informazione memorizzata nella struttura Diagnostic check Un diagnostic check sollecita il sistema con input di cui si conosce l'output, per poi verificarne l'effettivo output con quello atteso (solitamente l'output atteso va sotto il nome di problema dell'oracolo). Questo tipo di controllo può essere effettuato sia al sistema nella sua interezza che ad un singolo componente, e piuttosto che rivelare errori, il suo scopo è rivelare fault. L'applicazione di diagnostic check è comune per la preemtive maintenance. Principali vantaggi di questo controllo sono la riduzione dei tempi di fault detection e di latenza degli errori. Sono inoltre molto utili per confinare gli errori ad un singolo modulo. Sfortunatamente questi sono test che richiedono un consumo cospicuo di risorse (il sistema deve compiere le sue elaborazioni interamente) e quindi vengono solitamente eseguito periodicamente come misura di riconoscimento degli errori secondaria, spesso eseguita come lavoro di backgroud. Per la loro natura, questi check si adoperano in sistemi hardware che sono sottoposti a variazione per usura nel tempo. I sistemi software non fanno uso di diagnostic check, poiché il testing del sistema è eseguito una sola volta prima del rilascio Self checking Il sistema può supportare appositi sistemi in modo da garantire automaticamente il riconoscimento dell'occorrenza di un fault. Si suppone di utilizzare un sistema che per output ed input utilizza codifica. Un sistema self checking, per ogni fault genera al massimo una word non appartenente al codice. Un sistema totally self checking per ogni guasto non produce mai una parola di non codice. Dependability mean: Error detection 43

44 Capitolo Control flow monitoring Il controllo della sequenza di elaborazione è una tecnica utilizzata nel software per verificare le motivazioni alla base di salti incorretti del processore. Il programma viene suddiviso in blocchi e la sequenza che salta fra un blocco ad un altro viene disegnata con una apposita sintassi. Dependability mean: Error detection 44

45 Capitolo 5 Capitolo 5 Hardware fault tolerance I meccanismi di fault detection non assicurano alcuna fault tolerance, è quindi necessario progettare e sviluppare apposite soluzioni per garantire questa caratteristica. Nel seguito si esaminano le più comuni soluzioni adottate a livello hardware. 5.1 Fault masking Il fault masking utilizza la ridondanza sia isolando che correggendo gli errori, prima che raggiungano l'output del sistema. La ridondanza è di tipo statico, i componenti elettronici, ad esempio, presentano delle prefissate linee di interconnessione che creano tale ridondanza, e che rimarranno tali per tutta la vita del sistema. Quando tutte le parti ridondante saranno colpite da un fault, il sistema genererà un failure. Sistemi del genere non lanciano nessun allarme quando si verifica un fault, poiché questo viene mascherato e non genera risultati sull'output. Allo stesso modo, non si hanno conoscenze sullo stato di degrado del sistema, se non quando è così compromesso da causare l'arrivo di un error all'output. Inoltre, è necessario che il sistema abbia meccanismi per effettuare fault detection. E' possibile utilizzare una ridondanza multipla per garantire prestazioni migliori sotto il profilo della fault tolerance. Un esempio è il TMR Triple Modular Redundancy in cui un modulo viene replicato tre volte e l'uscita di ogni singola replica va in ingresso ad un voter. Il voter confronta le tre uscite e considera l'uscita corretta, quella che presenta un maggior numero di occorrenze. Quindi, se un modulo è mal funzionante, due delle tre uscite saranno uguali, ed una sola, quella del modulo mal funzionante, sarà diversa. Il voter, scegliendo a maggioranza, prenderà come uscita buona quella proveniente da i due moduli corretti. Illustrazione 5.1: Triple modular redundancy In Illustrazione 5.1 è mostrato lo schema per un TMR. Hardware fault tolerance 45

46 Capitolo 5 E' possibile estendere lo schema ad N copie del modulo anziché tre, chiaramente questo incrementa sia il la reliability che il costo. Solitamente il numero di copie è dispari per assicurare che non si verifichino eventi di indecisione per assenza di maggioranza. A quanto detto va aggiunto che si ha comunque un peggioramento delle prestazioni complessive, dovuto alla presenza del voter ed alla sincronizzazione dei moduli replicati. Illustrazione 5.2: TMR in cascata Per aumentare l'efficienza, e quindi la reliability, tramite questo meccanismo, invece di replicare l'intero sistema ed utilizzare un solo voter, è conveniente dividere il sistema in parti più piccole e replicare ciascuna di queste (Illustrazione 5.2). In questo modo si ha una migliore fault tolerance. E' bene prestare molta attenzione a questa operazione, non è infatti sempre conveniente dividere il sistema in molti sotto-sistemi. Se il numero di sotto sistemi è molto elevato, saranno necessari altrettanti voter, che rappresentano unità non replicate, comunque soggette a fault. Quindi, per quanto si aumenti la reliability dei sotto-sistemi, viene a mancare una sufficiente reliability sui voter (il grande numero di questi ultimi rende più alta la probabilità che uno di questi si guasti), e nel complesso il sistema risulterebbe meno affidabile. Per quanto internamente al sistema sia possibile prevedere meccanismi per la replicazione degli stessi voter, l'output del sistema deve rimanere un'uscita singola, quindi, in ogni caso sarà presente almeno un voter senza repliche. Questo evidenzia che il sistema presenta un single point of failure, e che quindi, per garantire reliability, deve adoperare meccanismi di fault avoidance. Dal punto di vista probabilistico, la massima probabilità si ha quando tutti i moduli replicati hanno la stessa reliability. E' tuttavia possibile definire una soglia probabilistica oltre la quale è più conveniente mantenere un modulo singolo, piuttosto che replicarlo. Alcune considerazioni aggiuntive possono essere fatte sul voting a maggioranza. In particolare si può notare come non ci sia alcuna detection dei fault, ma è necessario utilizzare appositi meccanismi, che lavorano in parallelo, per effettuarla. Questa operazione diviene una necessità in caso di sistemi riconfigurabili, che automaticamente sostituiscono o riparano la parte danneggiata, ma è comunque utile in sistemi statici, per aver un'informazione sullo stato di degrado del sistema. Un altra pratica utile è utilizzare modulo diversi che compiono la stessa operazione per rilevare errori di progettazione o inefficienza di un particolare componente. In ultima analisi, c'è da sottolineare la possibilità che si verifichino common mode transient fault, quando vengono colpiti ad esempio voter non replicati, o in riferimento al paragrafo successivo, quando viene colpito il clock utilizzato per la sincronizzazione Voter design In sistemi digitali il voter di un TMR è spesso realizzato con un semplice adder, in cui gli ingressi corrispondono ai due operandi ed al riporto entrante, ed il riporto uscente rappresenta il risultato in maggioranza. Questo metodo di realizzazione si usa poiché, nella maggior parte dei casi, l'esame degli output si effettua bit per bit. Hardware fault tolerance 46

47 Capitolo 5 Un problema fondamentale nella realizzazione del voter è stabilire la sincronizzazione fra i moduli. Il voter deve infatti calcolare il risultato quando tutti i moduli hanno fornito il loro output. Solitamente si fa riferimento ad un unico clock esterno che sincronizza tanto i moduli quanto il voter. Chiaramente in questo modo si crea un ulteriore single point of failure, rappresentato dal clock stesso. 5.2 Masking logic Il fault masking avviene con tecniche differenti a livello di progettazione della rete logica. La NMR (N Modular Redundancy) si adopera esclusivamente per incrementare la reliability di un modulo del sistema. Si utilizza invece la codifica delle informazioni laddove siano presenti strutture regolari quali memorie o bus. In entrambi i casi si adopera solitamente un singolo organo di ristoro del sistema, meno complesso e soggetto ai fault di quanto sia l'hardware che protegge. Nei moderni sistemi si fa largo uso di logica a PLA o micro-programmata, che da' larga possibilità di utilizzare tecniche di codifica per risolvere gli errori. E' presente, tuttavia, ancora una parte di logica che non può essere realizzata in questo modo, ma che richiede comunque un controllo. Il fault model che interessa le porte logiche è quello costituito da fault di tipo stuck-at-a dove a può essere il valore logico 1 oppure 0. Gli effetti di questi fault variano a seconda della logica e del valore di a. Ad esempio, in una logica con tutte NAND, uno stuck-at-0 comporta che l'uscita della NAND sia sempre 1, mentre uno stuck-at-1 potrebbe tanto causare un 1 in uscita quanto non causarlo. In riferimento agli effetti di un fault, si definiscono critical faults quelli che da soli forzano l'uscita di una porta ad un determinato valore, subcritical faults quelli che potrebbero influenzare l'uscita della porta in dipendenza delle altre variabili. Una rete logica propaga gli error generati dai faults in dipendenza della logica con cui è realizzata. Un critical fault, in una rete di AND si propagherà in tutti i livelli della rete successivi a quello del fault, viceversa, se si alternano livelli con tutte AND e livelli con tutte OR un critical fault per un livello non è tale per quello successivo, e, quindi, un fault arresterebbe il suo effetto al massimo entro due livelli. Similmente accade per reti di tutte NAND o NOR. Se si costruisce un sistema in grado di mascherare t fault in ogni livello della sua rete logica, si dice che tale sistema è t-fault tolerant. Per ottenere questo risultato si adoperano porte rindondate con ingressi ridondati. Le interconnessioni fra livelli assicurano che i fault siano mascherati nel livello successivo da opportune combinazioni di segnali replicati corretti ed errati. La precedente soluzione, come già anticipato, si applica a logiche combinatorie. Per le macchine a stati realizzate da sistemi micro-programmati, si adoperano invece codici ridondanti per correggere gli errori, considerando gli stati della macchina come word del codice. In Illustrazione 5.3 è mostrato un esempio di fault masking applicato ad una semplice rete combinatoria. E' chiara la grande complessità che raggiungono queste tecniche quando le reti da proteggere sono più grandi e complesse. Hardware fault tolerance 47

48 Capitolo 5 Illustrazione 5.3: Esempio di fault masking con interconnessione dei livelli in logica combinatoria 5.3 Hardware dynamic redundancy techniques E' possibile utilizzare tecniche di ridondanza dinamica dell'hardware. Tali tecniche prevedono la riconfigurazione (online oppure offline) dei componenti del sistema in risposta ad un fault. In questo modo si previene la possibilità che il fault propaghi i suoi effetti ad altri componenti. In molti casi, la riconfigurazione consiste nel disconnettere l'unità danneggiata dal sistema. E' anche possibile posticipare la riconfigurazione nel caso si adoperino tecniche di fault masking. La riconfigurazione, in questo caso, avverrebbe solo quando i fault accumulatisi sarebbero tali da non poter più essere mascherati. La riconfigurazione può avvenire su impulso dell'unità danneggiata che con meccanismi interni di rilevazione riesce ad individuare il fault, oppure da un'unità esterna che riconosce la presenza di errori nell'output. In entrambi i casi sono necessarie tecniche di fault detection se si vuole applicare la ridondanza dinamica. In particolare sono necessarie tre caratteristiche nella fault detection per un sistema dinamicamente ridondante: confinazione degli effetti del fault prima che causino un danno irreparabile; identificazione del fault; Hardware fault tolerance 48

49 Capitolo 5 corretta diagnosi della locazione del fault. La copertura dei fault e la loro rivelabilità sono fattori fondamentali nella scelta della tecnica di detection da adoperare. Esaminiamo ora con maggior dettaglio le caratteristiche di un sistema ridondato dinamicamente. Se consideriamo un sistema con configurazione statica in cui un elemento è semplicemente duplicato, quando una delle due unità si guasta, è possibile solo affermare che c'è un guasto, poiché le uscite delle unità sono differenti, ma non è possibile affermare quale delle due stia sbagliando. In sostanza il sistema così costruito non provvede meccanismi di fault tolerance. Per garantire la fault tolerance, il sistema deve determinare quale unità è guasta e disabilitarla (assieme al modulo che confronta le uscite delle due unità, che, a questo punto, non è più utile). Anche se non c'è più la ridondanza dopo la riconfigurazione, il sistema continua comunque a funzionare correttamente. Solitamente si mantengono le due unità a lavorare in parallelo, con continuo monitoraggio delle uscite tramite il comparatore che le confronta. L'output di entrambe le macchine va in uno switch che collega una sola unità all'effettiva uscita del sistema. Quando il comparatore segnala anomalia, viene individuata l'unità guasta e lo switch impostato di conseguenza (Illustrazione 5.4). Illustrazione 5.4: Hardware dynamic reconfiguration I principali metodi per effettuare la fault detection sono elencati nel seguito: Diagnostic program: è un'operazione che viene eseguita periodicamente o sotto certi stimoli, se fallisce, si isola l'unità guasta e si abilita quella che lavorava in stand-by. L'unità guasta può poi essere sottoposta ad offline maintenance. Self checking: ogni modulo ha la possibilità di verificare autonomamente il suo stato. Solitamente questo approccio si arricchisce con l'utilizzo di comparatori in aggiunta al self checking e con meccanismi interni di verifica in congiunzione con software diagnostico. Watchdog timer: un altro metodo utilizzato per determinare la presenza di fault è il watchdog timer, già illustrato precedentemente in questo testo. Outside arbiter: un elemento esterno controlla la configurazione del sistema. Le pratiche appena esposte consentono di giungere ad un modello di reliability nel caso della duplicazione di un singolo modulo, che si esprime con l'equazione: RSYS =[ R2m 2CR m 1 R m ] Rk dove Rk è la reliability del controllo, dello switch e della circuteria a questi collegati, C è il coverage factor che rappresenta la probabilità combinata di successo nella fault detection e riconfigurazione. Un aumento della reliability si ottiene quando è possibile riparare un modulo mentre il resto del sistema è funzionante, in questo caso la precedente equazione da' una stima pessimistica. Hardware fault tolerance 49

50 Capitolo Reconfigurable NMR Nei sistemi N-modular redundancy con voting, la possibilità di fare fault masking diviene sempre minore man mano che alcune copie si guastano, e, in alcuni casi, è anche possibile che il voto delle copie guaste superi in maggioranza quello delle copie corrette. Se le copie guaste fossero escluse dalla votazione il NMR potrebbe invece continuare a lavorare correttamente. Due sono gli approcci utilizzati a questo scopo: hybrid redundancy, che rimpiazza il modulo guasto con un modulo di riserva non utilizzato. Adaptive voting, che modifica dinamicamente il processo di voting quando il sistema si deteriora. Entrambi i metodi dipendono dalla rilevazione del disaccordo fra le unità e dalla diagnosi dell'unità guasta. In Illustrazione 5.5 è mostrato un esempio di hybrid redundancy. Illustrazione 5.5: NMR hybrid redundancy Nell'adaptive voting ogni modulo invia un voto al voter, che è pesato da uno specifico fattore. Questo fattore è modificato nel tempo dalla storia dei disaccordi fra le unità. Nella pratica i valori assunti sono 0 ed 1, anche se logiche più complesse si possono immaginare. Quindi nell'adaptive voting ad un modulo i corrisponde un ingresso al voter n i che è pesato da un fattore a i e la decisione del voter si basa su ai n i. L'hybrid redundancy può essere considerata un caso particolare di adaptive voting, in cui i fattori a i sono determinati dallo switch. Un'altra forma di adaptive voting, nota col nome di NMR/Simplex, è quella che prevede che ad ogni fault vengano tolte l'unità guasta ed un'altra unità in modo da mantenere dispari il numero totale di unità coinvolte nel voting. Al limite, questa pratica porta ad avere nessuna ridondanza nel sistema, quando è fallito un sufficiente numero di unità Self purging Una tecnica più efficiente per la realizzazione dello switch prevede che l'uscita del voter sia ricollegata ai moduli che partecipano alla votazione. Sono gli stessi moduli ad accorgersi che il loro output non corrisponde con quello fornito dal voter, e quindi, automaticamente si escludono dalla votazione. Chiaramente in questa soluzione vanno affrontati problemi di sincronia che solitamente Hardware fault tolerance 50

51 Capitolo 5 si risolvono tramite un delayed clock. Questa soluzione è generalmente più efficiente della hybrid redundancy Sift out Un'altra tecnica di voting prevede che le unità vengano comparate a coppie. Partendo da N moduli, questa configurazione può sopportare fino ad N-2 unità guaste. Questo approccio dovrebbe consentire una maggior semplicità di realizzazione del meccanismo di voting. Illustrazione 5.6: Sift out (Distribuited voting) In Illustrazione 5.6 è mostrato uno schema di principio per il sift out Backup sparing Alle configurazioni ridondanti costituite da N moduli, è possibile aggiungere ulteriori moduli che facciano da riserva e che possano essere sostituiti a quelli falliti in modo da non deteriorare il sistema. Chiaramente in queste situazioni gioca un ruolo fondamentale la corretta diagnosi dell'unità guasta, e, soprattuto, la complessità dello switch che deve eseguire l'operazione di scambio. I componenti che fanno largo uso di queste tecniche sono quelli che presentano un certo parallelismo in termini di bit o byte. Fra questi, ad esempio, ci sono memorie e ALU Graceful degradation La presenza di ridondanza garantisce che il sistema non fallisca in presenza di un guasto, ma che raggiunga stati di funzionamento via via più degradati. Questo comporta diverse prospettive. Talvolta è infatti conveniente che il sistema continui a lavorare anche se con prestazioni inferiori, altre volte si preferisce che se le prestazioni non sono mantenute oltre una certa soglia, il sistema è meglio che si fermi. In situazioni come quelle dei sistemi real time, in cui la degradazione delle prestazioni non è ammissibile, si agisce solitamente incrementando le potenzialità e le performance del sistema oltre i requisiti minimi. In questo modo le degradazioni successive potranno essere tollerate fin quando non si sforeranno tali requisiti. Hardware fault tolerance 51

52 Capitolo 6 Capitolo 6 Software fault tolerance La dependability dei sistemi computerizzati è largamente influenzata dalla dependability del software che tali sistemi adoperano. A questo scopo nel corso del tempo sono sorte discipline e metodi quali l'ingegneria del software. In questo capitolo si esamina il problema della software fault tolerance così come nel precedente si è esaminato quello della hardware fault tolerance. 6.1 Software fault tolerance techniques Le tecniche utilizzate per la SFT (Software fault tolerance) sono spesso simili a quelle utilizzate per l'hardware. Molto spesso le tecniche di HFT richiedono semplici modifiche per adattarsi ai problemi della SFT. In realtà si aggiungono oltre a difficoltà tecniche anche alcune difficoltà di carattere teorico, ad esempio, si complica la distinzione fra physical fault e design fault. Se si considera infatti un fault causato da un componente che si è trovato a lavorare oltre certi parametri prestabiliti, il fault in questione è da considerarsi di tipo physical perchè il componente si è guastato o di tipo progettuale, perchè si sono prefissati parametri non corretti? Indipendentemente da queste problematiche, la SFT si può semplicemente ricondurre alla HFT in molti casi, ad esempio, La HWT è realizzata tramite ridondanza di componenti indipendenti, per la SFT questo corrisponde ad una indipendenza logica del software o ad una diversità dello stesso fra moduli che eseguono la stessa funzione. La necessità di SFT nacque a metà degli anni '70, e si tradusse in proposte per strutturare codice ridondante nel software in modo semplice e coerente. Fondamentalmente gli approcci in questa pratica furono due, recovery blocks e N-version programming. Ulteriori proposte furono invece fatte per gestire adeguatamente l'error detection e il trattamento degli error in modi propriamente strutturati. In questo filone rientrano i supporti dei linguaggi di programmazione a costrutti per gestire eccezioni ed asserzioni. La SFT comporta notevoli vantaggi, fra cui, oltre all'aumento di reliability del prodotto, è possibile avere anche una riduzione dei tempi e dei costi della fase di testing del software, poiché la error detection viene eseguita online. Questo si può tradurre in un vantaggio per chi commissiona il software, poiché la produzione dello stesso è più veloce. Dal punto di vista dei costi aggiuntivi per realizzare la fault tolerance, bisogna considerare il costo a run-time del codice ridondante e il maggior tempo richiesto sia in fase di development che di supporto a run-time. Software fault tolerance 52

53 Capitolo Structured software fault tolerance Generalmente si considera il software suddiviso in una serie di blocchi individuali, fra loro interconnessi. Lo scopo della SFT è mascherare o rivelare gli errori interni a tali blocchi. E' possibile stabilire dei criteri per classificare le operazioni che si compiono sui blocchi: error detection error correction distribution of executions unconditional/on demand usage of redundancy granularity of fault units Error detection L'error detection si realizza principalmente in due modi. Un primo metodo è verificare che i risultati ottenuti sono concordi alle specifiche del software. Purtroppo per quanto questo sia un criterio estremamente valido, non sempre è applicabile perché non si può far appartenere un output ad uno specifico insieme, o perché l'insieme dei possibili output è troppo vasto per essere testato. Un secondo metodo è confrontare l'output con un altro risultato ottenuto in modo indipendente. In questo caso la error coverage dipende dalla possibilità che le versioni differenti falliscano allo stesso modo, ossia dalla loro diversità Error correction Anche nella error correction si possono adoperare vari approcci. La backward recovery, con rollback e riesecuzione dell'elaborazione fallita, consiste nel portare indietro il programma a prima del fault e nel fargli rieseguire la stessa elaborazione. Così come nell'hardware si può adoperare una tecnica di voting a cui si aggiunge la compensazione dello ridondanza stato del programma prodotto da possibili significati alternativi delle versioni differenti che hanno partecipato al voting. Infine è possibile anche utilizzare una tecnica di forward recovery che consiste nel portare il sistema ad uno stato successivo che si sa essere corretto, quando si verifica un fault Distribution of executions Riguardo al tempo un modulo software ridondante può essere eseguito in parallelo o sequenzialmente ad un altro. Riguardo alla distribuzione fisica, è possibili far eseguire il modulo ridondante sulla stessa macchina o su di un altro elaboratore. Chiaramente ciascun tipo di distribuzione ha suoi vantaggi e svantaggi e dipende sostanzialmente dal progettista e dal problema la soluzione che si sceglie di adottare. Software fault tolerance 53

54 Capitolo Executions of variants Il modo in cui vengono eseguite le versioni ridondanti dei moduli software è un altro importante parametro che caratterizza la SFT. Per l'error detection le copie ridondanti sono eseguite in ogni caso, e quindi, la loro esecuzione è incondizionata, mentre per la sola correzione degli errori può essere eseguito un modulo ridondato solo su richiesta, nel caso in cui si rilevi l'errore. Chiaramente una esecuzione incondizionata ed in parallelo di un modulo ridondante garantisce maggior velocità nel recupero di errori, ed è un'utile soluzione per applicazioni time critical, ma, ovviamente è più costosa Granularity of fault unit La fault unit è il più piccolo blocco software in cui si considera divisibile il software stesso. In altre parole la fault unit è una scatola nera che riceve degli input e i cui output sono testati per verificarne la correttezza. Mantenere la fault unit piccola ha diversi vantaggi: diminuisce la latenza degli error, ne riduce la propagazione e quindi avvantaggia il recupero di questi, aiuta nella diagnosi del fault. Purtroppo le dimensioni ridotte comportano anche alcuni svantaggi, fra cui l'aumento dei costi per l'error detection e la riduzione di possibilità di realizzare versioni diverse che facciano la stessa operazione Alcuni problemi generali La SFT pone alcuni problemi generali a tutti i meccanismi di fault tolerance che si desidera applicare. Riguardo all'error detection, ad esempio, nel voting, molto spesso diverse versioni del software producono output diversi. Come decidere se i risultati sono comunque in accordo e come scegliere un valore corretto fra i diversi forniti sono alcune delle problematiche presenti. A queste si aggiungono anche difficoltà su cosa fare quando si tenta di recuperare lo stato di un modulo ridondante che è fallito e che quindi si trova in uno stato corrotto. In questo caso è necessario adoperare un sistema per riportare il modulo colpito dal fault in uno stato consistente con le altre copie. 6.3 Software fault tolerance schemes Nel seguito sono presentati alcuni metodi utilizzati per garantire la SFT. Nel corso del tempo tali metodi sono stati applicati interamente, o talvolta combinati per ottenere soluzioni intermedie N-version programming Nella N-version programming si fa uso incondizionato di ridondanza al fine di ottenere un mascheramento degli errori, e in caso di errore, si adopera la forward recovery. Sostanzialmente, N copie identiche dal punto di vista funzionale, ma realizzate in modo differente, lavorano in parallelo. I risultati di queste copie sono confrontati e tramite voting si decide il risultato corretto. Software fault tolerance 54

55 Capitolo 6 In Illustrazione 6.1 è mostrato lo schema di principio per la N-version programming. Illustrazione 6.1: N-version programming Molto spesso allo schema precedente si aggiunge un watchdog timer per controllare che una versione guasta non impieghi troppo tempo a fornire il proprio risultato, bloccando l'intero sistema. In Illustrazione 6.2 è mostrato nuovamente lo schema della n-version programming, ma modellato secondo il formalismo delle reti di Petri. Illustrazione 6.2: N-version programming rappresentata con le reti di Petri Recovery block Un metodo alternativo per garantire la SFT è il recovery block, Una determinata elaborazione viene eseguita da un modulo software, al termine di tale modulo un acceptance test viene eseguito e, nel caso venga superato, il sistema procede regolarmente, in caso di errore, l'elaborazione viene ripetuta da un secondo blocco di codice che costituisce una versione differente del primo modulo, ossia, un modulo che pur offrendo la stessa funzione, è realizzato in modo differente. Al termine di questo ulteriore modulo si affronta un test di accettazione, se anche questo non viene superato si ripete l'operazione con un altro modulo aggiuntivo. Quando non ci sono altri moduli che possono eseguire l'elaborazione, il sistema subisce un catastrophic failure. In Illustrazione 6.3 è mostrato lo schema di principio di recovery block per due versioni di un modulo software. Software fault tolerance 55

56 Capitolo 6 Illustrazione 6.3: Recovery blocks Un problema da affrontare quando si adopera questa tecnica di SFT è la consistenza dello stato fra elaborazioni parallele che comunicano fra loro. Supponiamo ad esempio che un programma abbia due processi che lavorano in parallelo comunicando fra loro. Ciascun processo divide il suo codice in blocchi su cui è applicata la tecnica del recovery block. Qualora uno di questi blocchi fallisse, è necessario portare indietro il codice fino all'inizio di quel blocco e far eseguire una versione differente. Poiché i processi comunicano fra loro, anche il processo che non ha registrato il fallimento deve tornare indietro nella sua elaborazione per rimanere consistente con il processo che invece ha rilevato l'error. Se i due processi non sono in accordo su di un punto comune da cui far ripartire l'elaborazione, è necessario portare indietro l'esecuzione fino a quando tale accordo non si verifichi. A tale scopo si usa dare dei punti di checkpoint allo stesso tempo in tutti i processi paralleli (Illustrazione 6.4). Illustrazione 6.4: Nested conversation In Illustrazione 6.5 è mostrata la tecnica dei recovery blocks tramite il formalismo delle reti di Petri. Illustrazione 6.5: Recovery blocks rappresentata con le reti di Petri Software fault tolerance 56

57 Capitolo N-self Checking Programming Un ulteriore metodo consiste nel far lavorare contemporaneamente più moduli software di cui è verificato l'output. La verifica può essere fatta o da un modulo di accettazione o da una semplice comparazione fra le uscite di diverse versioni del modulo. Tutte le versioni ridondanti costituiscono dei moduli di riserva sempre operativi, quindi, quando si rileva un guasto sul modulo principale, l'output viene preso da uno dei moduli di riserva, che compiva in parallelo l'elaborazione. Quindi, la gestione dell'errore è fatta tramite error detection e successivo switch dell'output se possibile. In Illustrazione 6.6 è mostrato il metodo espresso tramite il formalismo delle reti di Petri. Illustrazione 6.6: N-self checking programming rappresentata tramite reti di Petri Self-Configuring Optimistic Programming (SCOP) In questo ulteriore metodo si prevede l'esistenza di alcuni componenti fondamentali: n varianti software; un meccanismo di aggiudicazione; un controllore che gestisce le operazioni dinamiche dell'architettura. Il sistema esegue sempre il numero minimo di varianti che servono a generare l'output. Dopo l'esecuzione, un adjudicator verifica che l'output sia conforme a quello atteso. Se questo non dovesse verificarsi, l'esecuzione verrebbe ripetuta da altre varianti, e il risultato nuovamente verificato. Il procedimento va avanti fino ad esaurimento delle varianti o al raggiungimento dell'output corretto. Software fault tolerance 57

58 Capitolo Progettare la diversità L'applicazione della fault tolerance interessa due aspetti fondamentali: A quale livello di dettaglio dovrebbe essere applicata la FT; A quale livello del sistema dovrebbe essere applicata. Ci si trova spesso a dover scegliere un compromesso. Nel primo caso, un livello molto profondo di dettaglio comporta notevoli vantaggi nella possibilità di mascherare un errore, tuttavia, diviene difficile riuscire a progettare una diversità consistente delle versioni. Nel secondo caso c'è da considerare che cambiamenti ad un determinato livello influenzano lo stato dei livelli inferiori, e solo nei punti di decisioni tali stati sono coincidenti. La progettazione della diversità appare quindi come un procedimento di compromesso fra diverse necessità. Il motivo per cui si sceglie di applicare tale soluzione per la FT si basa sulla considerazione ideale per cui versioni diverse mostrano failure indipendenti. Nella realtà questo non è del tutto vero, ma comunque si riduce la probabilità di failure coincidenti. Gli approcci per garantire la diversità sono molteplici: indipendenza dei team di sviluppo, metodi di specifica e di realizzazione diversi, controlli di gestione del lavoro. Nonostante questi differenti approcci, si presentano comunque molto spesso dei fault comuni alle differenti versioni. Nel seguito si ispezionano alcune delle motivazioni o delle soluzioni che portano a fault comuni o alla loro soluzione: La causa maggiore di fault comuni è nella specifica del software. Incompletezza ed ambiguità possono condurre i programmatori a compiere scelte di progetto errate, per quanto, differenti interpretazioni potrebbero mantenere la diversità; Linguaggi strettamente tipizzati riducono il numero di fault, tuttavia sembra che la scelta del linguaggio abbia un'incidenza sulla realizzazione di fault comuni legati al progetto o alla specifica. La comunicazione fra i team di sviluppo e i coordinatori di progetto consente di rimuovere fault comuni legati alla specifica. I programmatori tendono a fare gli stessi errori. Il problema risiede nel fatto che gli errori si compiono dove il codice si complica. La soluzione è quindi adoperare approcci differenti che distribuiscano in modo differente le difficoltà del progetto. L'utilizzo di error masking, per quanto permetta di evitare che un errore giunga all'esterno, porta a failure rate comuni fra differenti versioni. Una ulteriore fonte di fault comuni si presenta quando ad avere fault sono i test di accettazione o le golden unit. Questo comporta fault dello stesso tipo in tutte le differenti versioni. Se i comparatori che verificano la bontà dell'output sono inconsistenti, potrebbero aversi segnalazioni di errore semplicemente perché due versioni utilizzano differenti precisioni computazionali, o scelgono algoritmi differenti. Software fault tolerance 58

59 Capitolo 6 Infine, è importante citare un concetto molto interessante per risolvere i problemi di diversità: la diversità sui dati. In sostanza, si adoperano dati rappresentati diversamente, in un'unica versione del programma. Per quanto i vantaggi sarebbero consistenti, data la necessità di non replicare il software in differenti versioni, questo approccio non è sempre utilizzabile poiché non sono sempre presenti diversi modi di rappresentare lo stesso dato. Nella pratica, infatti, questo approccio non si utilizza. 6.5 Exception handling L'eccessiva complessità di un sistema ne riduce l'affidabilità. Molto spesso introdurre meccanismi di FT potrebbe aumentare a tal punto la complessità del sistema da vanificare gli sforzi per aumentarne l'affidabilità. E' quindi necessario un meccanismo per mantenere separate le attività normali da quelle eccezionali e compiute in casi particolari. Queste ultime attività andrebbero eseguite solo se effettivamente si presenta una anomalia nel sistema. Le anomalie in un sistema si possono presentare in due diversi modi: anomalie di interfaccia, anomalie di funzione. Le prime si presentano quando gli input in ingresso non corrispondono a quelli attesi dal sistema. Ossia quando vengono forniti input al di fuori dei vincoli che li definiscono. Il secondo tipo di anomalia si presenta quando c'è un errore nell'elaborazione dei dati, ad esempio se si rileva un errore nel bit di parità. Un modulo software dovrebbe essere progettato in modo da terminare correttamente la sua elaborazione se non si verificano situazioni anormali, altrimenti, deve essere presente un meccanismo per segnalare l'anomalia. I moderni linguaggi di programmazione prevedono il meccanismo delle eccezioni per far fronte a questa problematica. Ogni modulo software si presenta all'esterno con un'interfaccia che ammette dei particolari input, degli output, a cui si aggiungono eventuali eccezioni che possono essere sollevate. Consistentemente a quanto detto in precedenza, le eccezioni possono essere collegate all'interfaccia o all'elaborazione. Quando un modulo solleva un'eccezione, la passa al modulo che gli ha fornito gli input. L'eccezione si propaga ripercorrendo indietro tutta l'elaborazione, fin quando non viene gestita da uno dei moduli. Un modulo che gestisce l'eccezione non fa altro che definire un opportuno meccanismo per catturarla. In Illustrazione 6.7 è rappresentato il meccanismo delle eccezioni. Illustrazione 6.7: Exception framework Un buon esempio di realizzazione delle eccezioni è presente in [5]. Software fault tolerance 59

60 Capitolo Software Rejuvination Per molto tempo si è considerato il software non sottoposto ad usura. Questa assunzione si è rivelata nel tempo errata, almeno per alcune categorie di sistemi. In particolare, nei sistemi il cui tempo di funzionamento è continuo per lunghi periodi, il problema si presenta con una certa consistenza. Le cause dell'usura del software risiedono in alcuni fault minori che causano il non rilascio delle risorse di sistema (ad esempio la memoria). Questi fault a lungo andare riducono sensibilmente le risorse di sistema fino a causare una drastica riduzione delle prestazioni o un failure. La software rejuvination è quindi da considerarsi come una pratica preventiva per la risoluzione di alcune tipologie di failure. Sostanzialmente, ringiovanire il software significa riavviare il sistema, periodicamente, in modo da ricondurlo in uno stato iniziale in cui tutte le risorse sono propriamente sfruttate. Alcune problematiche sono connesse a questo riavvio, infatti, riavviare il sistema significa aggiungere un periodo di downtime. La pratica del SR è quindi da valutare in base ai costi che comporta il downtime, tenendo in considerazione, che tale downtime permette di evitare ulteriori downtime futuri. Procurare un downtime per evitarne un altro potrebbe sembrare una pratica senza senso. Tuttavia, il downtime realizzato per SR è programmabile ed avviene in un momento deciso dal progettista. Si suppone quindi che un downtime progettato correttamente abbia un costo minimo, rispetto ad un altro che avviene improvvisamente in qualsiasi momento. Software fault tolerance 60

61 Capitolo 7 Capitolo 7 Fault tolerance: assessment techniques Ci sono tre diversi approcci per valutare la fault tolerance di un sistema: Modellazione analitica: si realizza un modello analitico per supportare le decisioni di progetto e per valutare le misure di dependability del sistema. Generalmente si adoperano formalismi quali le reti di Petri. Fault injection: sono tecniche utilizzate per valutare un prototipo durante la validazione del sistema. Sono quindi utilizzabili quando il sistema già è almeno in parte funzionante. Field measurement: vengono realizzate prendendo i dati dal sistema già operativo. Nella fase di progettazione di un sistema, sono utili come informazioni provenienti da sistemi precedenti. Ciascuna delle tre tecniche presentate ha una diversa utilità nella valutazione della dependability ed un preciso contesto temporale della vita del sistema, in cui viene applicata. Nel seguito le tecniche sono trattate con maggior dettaglio. Per approfondire i contenuti di questo capitolo, si consiglia la lettura di [6]. 7.1 Analytical Modelling La modellazione analitica adopera come mezzi per la sua realizzazione gli argomenti esposti nel capitolo 3. Si fa dunque affidamento su di una descrizione del comportamento del sistema che tenga in conto la possibilità di failure e di riparazioni di componenti, sia hardware che software, e delle loro interazioni. Le dipendenze in termini probabilistici fra i componenti di un sistema vengono spesso descritte tramite l'utilizzo di modelli a spazio degli stati, che realizzano modelli di Markov, che consentono di eseguire misurazioni riguardanti diversi aspetti della dependability e delle performance del sistema. Data la complessità di questi modelli, e la difficoltà nel mantenerli di ridotte dimensioni, molto spesso si ricorre a formalismi per descriverli, quali le reti di Petri. Tuttavia, nonostante queste tecniche, è spesso evitare l'esplosione del numero degli stati del modello. A tal proposito, nel tempo, si sono sviluppate due tecniche principali per mantenere i modelli semplici: le largness avoidance techiniques cercano di suddividere i sistemi in in sotto-sistemi più semplici che vengono modellati indipendentemente e processati indipendentemente. I risultati dei sotto-modelli vengono poi utilizzati in un unico modello che realizza il comportamento dell'intero sistema. Fault tolerance: assessment techniques 61

62 Capitolo 7 Queste tecniche risultano utili quando i sotto-modelli sono fra loro accoppiati in modo lasco, quando invece le interazioni aumentano, sono di complesso utilizzo. Tecniche alternative sono quelle di largness tolerance techniques che utilizzano formalismi per creare specifiche concise del modello e meccanismi di generazione automatica dei modelli. Generalmente si adoperano le reti di Petri per generare un modello di un sistema modulare, come composizione dei modelli delle sue componenti. Chiaramente, la costruzione del modello, dal punto di vista degli eventi cui il sistema può essere sottoposto, è dettata dalla conoscenza del sistema stesso e dell'ambiente che lo circonda. Inoltre, talvolta sono necessarie informazioni ottenute da misurazioni pratiche, ad esempio provenienti da sistemi preesistenti. La costruzione del modello è sottoposta anche alla scelta delle misure che si vogliono effettuare. Se immaginiamo il comportamento del sistema come caratterizzato da due stati fondamentali di servizio corretto e incorretto, allora la misurazione può valutare il tempo di permanenza in questi stati. Chiaramente si possono considerare più stati per modellare, ad esempio, failure parziali, tuttavia, sono tutte soluzioni riconducibili alla presenza di due stati fondamentali. Ad esempio, si considerino 3 stati, 1 indicante un fallimento totale del sistema, gli altri due un servizio corretto e un servizio con prestazioni degradate. La valutazione del tempo di fallimento potrebbe considerare questi due ultimi stati entrambi come di non fallimento, poiché comunque un servizio, anche se degradato è fornito. Quindi, la misurazione si riconduce facilmente al modello in cui ci sono due soli stati. 7.2 Fault injection Le tecniche di fault injection introducono nel sistema reale dei fault per valutarne il comportamento. I benefici di una pratica del genere sono tre: Mostra gli effetti di un fault e il corrispondente comportamento del sistema; Rende possibili miglioramenti o correzioni al meccanismo di fault tolerance del sistema; Consente di prevedere il comportamento in presenza di guasti del sistema. Questa tecnica di valutazione della dependability, traendo le informazioni da esperimenti, è un utile strumento per valutare gli elementi del sistema che non sono stati sviluppati, i cosiddetti moduli COTS (Commercial off the shelf), fra cui rientrano librerie software utilizzate, sistemi operativi, middleware, ecc. Quando si realizza un esperimento è necessario deciderne attentamente le caratteristiche per eseguire delle operazioni effettivamente utili alla valutazione della dependability, senza inserire elementi di confusione. Per questo è necessario comprendere quali fault immettere nel sistema, come immetterli, quale attività del sistema coinvolgere. Inoltre, è anche necessario decidere quali misurazioni fare e come compierle. Per trattare in modo metodologico l'esecuzione di un esperimento, possiamo definire alcune grandezze che lo caratterizzano: Fault tolerance: assessment techniques 62

63 Capitolo 7 Input domain: costituito dall'insieme F dei fault iniettati nel sistema, e dall'insieme A che specifica il workload del sistema e quindi il profilo di attivazione del fault. Output domain: costituito dall'insieme R dei readout, ossia da degli indicatori che caratterizzano il comportamento del sistema, e da un insieme M di misure, derivate dall'analisi degli insiemi F A R Fault injection campaign Realizzare una sessione di esperimenti di fault injection comporta la decisione di una strategia con cui compiere l'intera verifica del sistema. Ogni esperimento si può considerare come un elemento dell'insieme {F x A x R}. Infatti, durante un esperimento, un fault preso dall'insieme F viene iniettato in un contesto operativo del sistema, preso dall'insieme A, Questo produrrà un insieme di risultati da verificare, preso da R. Perché un esperimento sia realmente significato, ossia, perché ci sia una certa confidenza sul risultato che si ottiene, è necessario ripetere più volte l'esperimento. Allo stesso modo, è consigliabile prelevare gli elementi di F ed A in base a campioni statistici. Chiaramente se si vuole valutare l'efficienza del meccanismo di fault tolerance, si tende a ridurre il numero di esperimenti, eliminando quelli che non lo sollecitano Input Domain Dal punto di vista dei possibili input all'esperimento, si possono selezionare, in riferimento ai fault: Physical faults: si presentano solitamente come transienti, l'approccio in questi casi può contare su svariate tecniche affermate. Design (software) faults: anche questi si presentano solitamente come transienti, e consistono solitamente nel mutare il software. Ancora è un argomento aperto di ricerca. Human-related faults: sono guasti che si presentano a causa dell'interazione con l'uomo. La seconda domanda che ci si è posti in precedenza, era come iniettare i fault nel sistema. Anche in questo caso si presentano diverse alternative. E' infatti possibile agire direttamente sull'hardware, effettuando operazioni come cambiare i parametri di alimentazione, bombardare con ioni pesanti il sistema, oppure, è possibile eseguire SWIFI (Software implemented fault injection) che sfrutta i meccanismi di controllo interni dell'hardware per eseguire l'iniezione del fault. Senza scendere nel dettaglio, un problema si pone anche nella semplice scelta di applicare il meccanismo ad un prototipo o ad un modello di simulazione. Nel primo caso il comportamento che si ottiene è molto vicino a quello del sistema, e proprio per queste ragioni, è più difficile eseguire valutazioni, nel secondo caso, si fa affidamento sulla bontà della simulazione, avendo il vantaggio di poter intervenire al suo interno senza difficoltà. Chiaramente, anche la scelta della parte del sistema in cui iniettare il fault è molto importante. Si può scegliere ad esempio il livello del processore, del microkernel, del sistema operativo, ecc. In conclusione, ogni operazione appare come un compromesso fra il livello di dettaglio e la complessità (e quindi costo anche in termini di tempo) della campagna. Sta al progettista effettuare la scelta opportuna in base ai suoi vincoli. Fault tolerance: assessment techniques 63

64 Capitolo 7 L'ultima considerazione riguarda l'insieme A, ossia, il workload del sistema al momento dell'iniezione del fault. E' molto importante caratterizzare questo parametro per evitare di creare situazioni non realistiche di funzionamento del sistema. Sostanzialmente la scelta del workload è dettata dal tipo di misurazione che si vuole effettuare. Se si vuole prevedere il comportamento del sistema in caso di fault, è necessario fornire un workload conforme a quello che sarà il carico di lavoro reale del sistema, in modo da riprodurre una situazione verosimile. Se, invece, si desidera migliorare il meccanismo di fault tolerance, eliminandone i difetti, il workload deve essere realizzato in modo da sollecitare i meccanismi di fault tolerance Output domain I risultati di un esperimento di fault injection consentono di valutare il comportamento del sistema in presenza di guasti e di valutare l'efficacia dei meccanismi di fault tolerance. A tale scopo, come caratteristica quantitativa principale della FT si adopera la nozione di coverage. Generalmente, la coverage si esprime come la probabilità condizionata che, dato un fault nel sistema, il sistema può tollerarlo. Gli elementi dell'insieme R consentono di caratterizzare lo stato del sistema sotto esame. Tuttavia, vanno anche considerate le dinamiche dei processi di fault/error. Infatti, non è detto che i readout dell'insieme R siano tutti indicativi dello stato del sistema, poiché, se un fault impiega un certo lasso di tempo per manifestarsi, potrebbe non essere ancora rilevabile nelle indicazioni fornite dai readout. Sostanzialmente sono due le problematiche principali da affrontare nella valutazione degli output: Un sistema difficilmente può essere valutato in corrispondenza di tutti i possibili input. E' necessario quindi adoperare misurazioni statistiche per estendere i risultati ottenuti da un insieme di esperimenti, a tutti i casi del sistema. Non sempre i risultati ottenuti sono facili da interpretare, e talvolta, è possibile che siano introdotte delle imprecisioni. Si delinea un problema di come rendere minima l'imprecisione. Riguardo quest'ultimo aspetto, sono tre le possibili fonti di imprecisione: Non rappresentatività dell'attività del sistema. L'esperimento eseguito non è rappresentativo di casi reali del sistema. Esperimenti non significativi. Quando un esperimento non attiva alcun errore, poiché causa un dormant fault o error, o perché l'errore viene mascherato dal meccanismo di FT. I fault iniettati non hanno la stessa probabilità di avvenire. La misurazione deve quindi tenere in qualche modo conto della frequenza con cui un dato fault potrebbe manifestarsi. Riguardo la prima problematica, si possono utilizzare degli stimatori per la parte testata da estendere all'intero sistema. Tuttavia, questo comporta un piccolo intervallo di confidenza su tutto il sistema, quindi nella pratica non si utilizza. Alternativamente si possono ridurre i test da effettuare, adoperando un testing a posteriori che introduca informazioni strutturali sul sistema. Alternativamente, è possibile ricondurre in un unico esperimento più test fault injection test singoli che comportano gli stessi readout. Fault tolerance: assessment techniques 64

65 Capitolo Collegamenti fra modelli e misurazioni Non deve meravigliare la stretta correlazione fra i modelli e le misurazioni che vengono compiute sul sistema nella fase operativa o in seguito ad un esperimento di fault injection. Illustrazione 7.1: Relazione fra modello e misurazioni In Illustrazione 7.1 è mostrata questa stretta relazione. Il ramo di sinistra della figura rappresenta misurazioni compiute sul modello, quello di destra quelle compiute in seguito ad un esperimento. C'è una doppia relazione che lega queste due pratiche: I risultati delle misure compiute a seguito di un esperimento, possono essere utilizzati per ricalibrare o convalidare il modello analitico. I dati presi dal modello possono essere usati per caratterizzare gli input dell'esperimento di test. 7.4 Attack injection Solo un accenno è fatto all'utilizzo della fault injection nell'ambito della valutazione della sicurezza di un sistema. In questo caso la pratica prende il nome di attack injection. Il legame fra queste due pratiche è lampante se si considera che, in base alle definizioni date nel capitolo 1, gli attacchi alla sicurezza rientrano fra i fault. Fault tolerance: assessment techniques 65