WIXLIB

Analisi e studio di un processo di sviluppo di sistemisafety-critical conformi allo standard RTCA DO-178BIl Risk Management è un’attività complessa e delicata che si occupa di “tenere sotto controllo” ilrischio totale, quindi la quantità di incertezza presente in tutto ciò che il sistema in qualche modocoinvolge. L’esito di questo processo chiaramente dipende da numerosi fattori. Non esiste uncriterio unico adottato universalmente, in linea di massima, comunque, consiste nel pianificare leattività, nell’individuazione delle aree e delle fonti di rischio e infine nell’analisi delle cause, delleconseguenze e della loro gravità, determinando la probabilità degli eventi “critici” e le strategie perridurre il livello totale di incertezza.Si parte comunque dal presupposto che è impossibile eliminare completamente tutti i rischi, che ilsolo individuarli e valutarli non li elimina.1.1 SistemaUn sistema è una qualsiasi entità in grado di interagire con altre entità, utenti umani o altri sistemi.E’ progettato per offrire un certo numero di servizi attraverso la propria interfaccia che, pertanto,delimita i confini del sistema stesso.Un servizio, è un comportamento del sistema che l’utente può percepire; esso viene definito correttose conforme alle proprie specifiche mentre in caso contrario si parlerà di failure. Un sistema si dicesafety-critical se un suo failure può causare danni fisici a persone o all’ambiente circostante.I sistemi safety-critical si distinguono dalle normali applicazioni informatiche per requisitiestremamente stringenti di qualità e affidabilità. Spesso tali sistemi hanno anche caratteristiche hardreal-time (controllo di impianti, sistemi di avionica, sistemi embedded). E anche i requisiti disicurezza sono diventati sempre più critici.L’obiettivo chiave della System Safety Engineering è quello di ridurre quanto più possibile i rischidi safety del sistema, iniziando con la loro individuazione e analisi. Chiaramente queste sono solo leprima fasi di un processo continuo portato avanti durante tutte le fasi del ciclo di vita del prodotto, eche in ciascuna di esse richiederà criteri e soluzioni tanto generali quanto ad-hoc.1.2 DependabilityLa Dependability consiste nella capacità di una persona o di un sistema di mostrarsi affidabile aglialtri per la sua integrità, per la sua veridicità e la sua affidabilità; queste caratteristiche possonoincoraggiare qualcuno a dipendere da tale persona o sistema.

Analisi e studio di un processo di sviluppo di sistemisafety-critical conformi allo standard RTCA DO-178BNell’informatica, la dependability può essere definita come:“[.] the trustworthiness of a computing system which allows reliance to be justifiablyplaced on the service it delivers [.]” [1]ovvero la proprietà di un sistema di essere adeguato alla dipendenza da parte di un essere umano, odi una collettività, senza il pericolo di rischi inaccettabili. Quindi la dependability può esseredefinita come la credibilità di un sistema di calcolo, ovvero il grado di fiducia che può essereragionevolmente riposto nei servizi che esso offre. Il servizio offerto da un sistema di calcolo èrappresentato dal suo comportamento così come viene percepito dagli utenti; l’utente, umano ofisico, rappresenta un sistema distinto che interagisce con il sistema di calcolo.Saranno, ora, introdotte delle nozioni che possono essere raggruppate nelle seguenti tre categorie:̵ Gli attributi della dependability.̵ Gli impedimenti alla dependability.̵ I mezzi per la dependability.Figura 1.2 Dependability: attributi, impedimenti, mezzi

Analisi e studio di un processo di sviluppo di sistemisafety-critical conformi allo standard RTCA DO-178B1.2.1 Attributi della dependabilityIn dipendenza dai servizi che il sistema è chiamato a svolgere, vengono messi in evidenza i variattributi che vanno a fondersi nel concetto di dependability, ovvero la garanzia di funzionamentopuò essere interpretata in relazione a proprietà distinte, ma complementari, richieste dal sistema.Gli attributi servono ad esprimere le caratteristiche attese del sistema ed a formalizzarne lespecifiche. Availability: in relazione alla rapidità di risposta, o prontezza d’uso, un sistema dependableè rapidamente disponibile. La availability è la misura di quanto un sistema è funzionante inun periodo in cui possono alternarsi periodi di guasto (fallimento) e periodi di correttofunzionamento. Reliability: in relazione alla continuità di un servizio corretto, un sistema dependable èaffidabile. La reliability di un sistema è la misura del tempo continuativo in cui viene fornitoun servizio corretto. Safety: in relazione alla garanzia di evitare situazioni catastrofiche che causano morte,ferite, malattie, danneggiamento o perdita di apparati, danni per l’ambiente, un sistemadependable è sicuro. Per aumentare la safety in caso di guasto, occorre rilevare il guasto eadottare le opportune misure per portare il sistema in uno stato fail-safe. Security: in relazione alla prevenzione di accessi non autorizzati e/o manipolazioni diinformazioni private, un sistema dependable è protetto. Performability: in relazione alle valutazioni delle prestazioni anche in caso di guasto. Maintainability: in relazione alla capacità di essere sottoposto a modifiche e/o riparazioni,un sistema dependable è mantenibile. E’ la probabilità M(t) che il sistema malfunzionantepossa essere riportato al suo corretto funzionamento entro il periodo t.

Analisi e studio di un processo di sviluppo di sistemisafety-critical conformi allo standard RTCA DO-178B1.2.2 Gli impedimenti alla dependabilityUn sistema può fallire per via di molteplici cause; sono circostanze indesiderabili ma, in linea diprincipio, non inaspettate, che sono cause/effetti di comportamenti non dependable del sistema. Icasi più comuni sono rappresentati da guasti hardware, errori di progettazione hardaware o softwaree, ancora, errati interventi di manutenzione.Di seguito, vengono illustrati i concetti di fault, error, e failure: Fault: stato improprio dell’hardware o del software del sistema, causato dal guasto di uncomponente, da fenomeni di interferenza o da errori di progettazione. Error: è quella parte dello stato del sistema esposta a provocare successivi fallimenti. Unerrore nel servizio è un’indicazione che un guasto è in atto, ovvero la causa ipotizzata di unerrore è un guasto. Uno stesso fault può generare più errori (multiple related error). Failure: evento in corrispondenza del quale i servizi offerti non corrispondono più allespecifiche preventivamente imposte al sistema.Le minacce che possono condurre al fallimento di un sistema, si propagano secondo uno schemaben preciso: l’attivazione di un guasto ( fault ) causa la transizione da uno stato di funzionamentocorretto ad uno improprio ( error ). Un error può generare un failure quando raggiunge l’interfacciadel sistema.Figura 1.3: Propagazione delle minacce

Analisi e studio di un processo di sviluppo di sistemisafety-critical conformi allo standard RTCA DO-178B1.2.2.1 Gli impedimenti alla dependability: I guastiI guasti e le loro cause possono essere molto diversi; vengono classificati secondo la loro natura,origine e persistenza.La natura dei guasti porta a distinguere tra guasti accidentali ( accidental faults ), che si verificanoo sono creati fortuitamente; e guasti intenzionali ( intentional faults ), che sono creatideliberatamente, eventualmente con scopi malevoli.L‟origine dei guasti porta a distinguere tra: le cause fenomenologiche che implicano guasti fisici (phisical faults), che sono dovuti a fenomeni fisici avversi; e guasti causati dall‟uomo ( human-madefaults ), che sono dovuti all’imperfezione umana. I confini del sistema che implicano guasti interni (internal faults ), che sono parti dello stato del sistema che, quando richiamate dall’attività dielaborazione, produrranno un errore; e guasti esterni ( external faults ), che derivanodall’interferenza dell’ambiente fisico nel sistema (perturbazioni elettromagnetiche, radiazioni,temperatura, vibrazioni, ) o dall’interazione con l’ambiente umano. La fase di creazione rispettoalla vita del sistema che implica guasti di progetto ( design faults), che derivano da imperfezioniche si verificano durante lo sviluppo del sistema o per modifiche successive; e guasti operativi (operational faults ), che si verificano durante l’uso del sistema.La persistenza dei guasti porta a distinguere tra guasti permanenti ( permanent faults ), la cuipresenza non è in relazione a condizioni temporali puntuali, siano esse interne (attività dielaborazione) o esterne (ambiente); e guasti temporanei ( temporary faults ), la cui presenza è inrelazione a condizioni temporali puntuali; sono pertanto rilevabili per un periodo limitato di tempo.Le violazioni alla protezione del sistema sono dovute (ma non limitate) a guasti intenzionali, chesono chiaramente causati dall’uomo; questi guasti possono essere sia interni che esterni: per quantoriguarda quelli interni, un esempio è l’inserimento di una logica maliziosa, che sono guasti diprogetto intenzionali. Per quel che riguarda i guasti esterni, un esempio è una intrusione, che è unguasto operativo esterno. I guasti intenzionali possono avvantaggiarsi dei guasti accidentali; comead esempio un’intrusione che sfrutta una crepa nella protezione causata da un guasto accidentale diprogetto.E’ possibile dare una definizione ricorsiva di guasto: un guasto al sistema la conseguenza di unfallimento di un altro sistema che ha fornito o sta fornendo un servizio al sistema in ogetto. Laricorsione termina alla causa che si intende prevenire o tollerare.

Analisi e studio di un processo di sviluppo di sistemisafety-critical conformi allo standard RTCA DO-178BConsiderando la persistenza temporale, i guasti esterni temporali che originano dall’ambiente fisicosono spesso chiamati guasti transitori ( transient faults ); i guasti interni temporanei, invece, sonospesso chiamati guasti intermittenti (intermittent faults); tali guasti derivano dalla presenza dicombinazioni di condizioni che si verificano raramente. I guasti transienti sono di fatto guastipermanenti la cui condizione di attivazione non può essere riprodotta, o può verificarsi solo moltoraramente.Figura 1.4: Classificazione dei guasti1.2.2.2 Gli impedimenti alla dependability: Gli erroriUn errore è il responsabile dell’evoluzione del sistema verso un fallimento successivo. Se un erroreporterà effettivamente ad un fallimento dipende da tre fattori principali: dalla composizione delsistema e la natura della ridondanza esistente, sia essa intenzionale ( introdotta per fornire tolleranzaal guasto) che è esplicitamente intesa per prevenire che un errore conduca ad un fallimento; oppurenon intenzionale (è difficile costruire un sistema che ne è privo) che può avere lo stesso risultato,non atteso, della ridondanza intenzionale. Dall’attività del sistema, cioè un errore può esserecompensato prima di provocare un danno. Dalla definizione di un fallimento dal punto di vistadell’utente, ciò che è un fallimento per un dato utente può essere una sopportabile noia per un altro.Un errore può essere latente o rilevato, è latente ( latent ) quando non è stato riconosciuto cometale; è rilevato ( detected ), invece, da un algoritmo o meccanismo di rilevamento.Gli errori possoni propagarsi e, in generale, si propagano e propagandosi creano altri errori.

Analisi e studio di un processo di sviluppo di sistemisafety-critical conformi allo standard RTCA DO-178B1.2.2.3 Gli impedimenti alla dependability: I fallimentiUn sistema non può fallire, e in generale non fallisce, sempre nello stesso modo. I modi in cui unsistema può fallire (failure modes) possono essere caratterizzati secondo tre punti di vista: dominio,percezione da parte dell’utente del sistema e conseguenze sull’ambiente.L’esperienza ha mostrato che il tasso di fallimento di un componente elettronico, evolve secondo lafigura a lato. Durante i primi annidi vita del componente, i fallimentioccorronofrequentemente,principalmente legati alla presenzadi componenti difettosi. La partedecrescentedellafunzioneèchiamata la regione della “infantmortality”. La parte finale dellacurva(la“wear-out”)regioneinvece rappresenta il verificarsi difallimenti dopo che il sistema èrimastofunzionantepermoltotempo. Nella regione intermedia, iltasso di fallimento è costante: è ilperiododivitautilediuncomponente (“useful life period”).Dal punto di vista del dominio di fallimento si possono distinguere i fallimenti nel valore, cioèquando il valore del servizio fornito non è conforme alla specifica; dai fallimenti nel tempo, cioèquando la temporizzazione della fornitura del servizio non è conforme alla specifica.Si può ulteriormente fare una distinzione più sottile riguardo ai modi di fallimento nel tempo, cheattesta quando un servizio è stato fornito troppo presto o troppo tardi: fallimento nel tempo peranticipo ( early timing failures ) e fallimento nel tempo per ritardo ( late timing failures ). Unaclasse di fallimenti riferita sia al dominio del valore che a quello del tempo è quella dei fallimenticon blocco ( stopping failures ) a causa dei quali l’attività del sistema non è più percepibile dagliutenti e viene fornito un servizio a valore costante. Un caso particolare di fallimento per blocco è ilfallimento per omissione (omission failures ) a seguito del quale non viene fornito nessun servizio;un fallimento per omissione è un caso limite comune sia per fallimenti nel valore (valore nullo), che

Analisi e studio di un processo di sviluppo di sistemisafety-critical conformi allo standard RTCA DO-178Bper fallimenti nel tempo (fallimento per ritardo infinito). Un fallimento per omissione persistente èun crash.Quando un sistema ha più utenti, dal punto di vista della percezione del fallimento, si possonodistinguere i fallimenti consistenti ( consistent failure ), quando tutti gli utenti del sistema hanno lastessa percezione dei fallimenti; e i fallimenti inconsistenti ( inconsistent failures ), ovvero quandogli utenti del sistema possono avere percezioni differenti di un dato fallimento.La gravità del fallimento risulta dalle conseguenze dei fallimenti sull’ambiente del sistema. Peralcuni sistemi i modi di fallimento possono essere raggruppati in due classi di gravitàconsiderevolmente differenti: Fallimenti minori: per cui le conseguenze sono dello stesso ordine di grandezza (in generein termini di costo) del beneficio prodotto dal servizio fornito in assenza di fallimento. Fallimenti catastrofici: per cui le conseguenze sono incommensurabilmente più grandi delbeneficio prodotto dal servizio fornito in assenza di fallimento.Un sistema i cui fallimenti possono essere soltanto minori è un sistema fail-safe. La criticità di unsistema è la gravità più elevata dei suoi possibili modi di fallimento.Figura 1.5: Classificazione dei failures1.2.3 Mezzi per la dependabilityCon il termine mezzi ( means ), vengono indicati una vasta categoria di metodi, tecniche, processicapaci di prevedere servizi degni di fiducia, quindi capaci di incrementare il grado di dependability

Analisi e studio di un processo di sviluppo di sistemisafety-critical conformi allo standard RTCA DO-178Bdi un sistema. La scelta del particolare approccio dipende dalla tipologia di sistema e dallo specificoattributo che si vuole migliorare. I principali means utilizzati nella pratica sono: Fault avoidance: tecniche orientate a minimizzare la probabilità di occorrenza deifallimenti. Tali tecniche, implicano l’utilizzo di componenti altamente affidabili che,pertanto, comportano un incremento dei costi. Sono tecnicherelativealla fase didefinizione delle specifiche, progettazione e codifica. Fault prevention: tecniche orientate ad eliminare i fault in fase di progettazione. Sioccupano di come possono essere prevenute le occorrenze dei guasti Fault tolerance: tecniche orientate alla minimizzazione delle conseguenze dei guasti e chetendono ad evitare che essi possano degenerare in un failure. Quindi si occupano di comegarantire un servizio che si mantenga conforme alle specifiche, nonostante i guasti.Tipicamente, esse si articolano in due fasi: error detection ed error treatment. Fault removal: tecniche orientate all’individuazione degli errori e alla rimozione dei guastidurante lo sviluppo o in fase operativa; per ridurre l’occorrenza (numero, gravità) dei guasti. Fault forecasting: si pone come obiettivo di stimare il numero, la frequenza di incidenza,presente e futura, e le conseguenze dei guasti. Può essere deterministico ( studio degli effettidei guasti sul sistema ) o probabilistico ( stima dei parametri di dependability ).Le tecniche di prevenzione e di tolleranza ai guasti garantiscono il conseguimento delladependability cioè come assicurare al sistema la capacità di fornire un servizio sempre fedele allespecifiche.Le tecniche per evitare/prevedere i guasti rappresentano invece la validazione della dependabilityovvero come essere ragionevolmente confidenti nella capacità del sistema di fornire un serviziosecondo specifiche. La fiducia ragionevolmente riposta nella stabilità di comportamento del sistemaè basata sulla valutazione del sistema, condotta primariamente in relazione agli attributi didependability che sono pertinenti ai particolari servizi richiesti.

Analisi e studio di un processo di sviluppo di sistemisafety-critical conformi allo standard RTCA DO-178B1.3 SafetyQuesto lavoro di tesi è incentrato intorno ad un particolare attributo della dependability: la safety.La safety può essere definita come “l’aspettativa che un certo sistema non comporti, in certespecifiche condizioni, rischi per la vita dell’uomo o dell’ambiente”.Il punto di partenza per caratterizzare la safety di un sistema, è costituito dal concetto di mishap oincidente, definito come „uno o più eventi non previsti che possono causare danni fisici a persone ocompromettere l‟ambiente circostante‟. La caratterizzazione di un mishap è legata alla stima di dueparametri: la severità e la probabilità di occorrenza. Basti pensare che un incidente aereo, anche sepiù grave (severo) di un incidente automobilistico è molto meno probabile che si verifichi. Taleesempio conduce a riflettere sul fatto che, nonostante esista una definizione di safety, èestremamente difficile costruire una caratterizzazione univoca e che, qualsiasi sistema, non può maiessere ritenuto totalmente sicuro.Il rischio (hazard) è quindi la combinazione di frequenza di un

1.4.2 RTCA 31 1.4.3 SAE - Serie ARP 33 1.4.4 NASA - Serie NSS 33 1.4.5 Standard commerciali 34 Capitolo 2. Analisi e descrizione dello standard RTCA DO-178B 37 2.1 Aspetti del sistema relativi allo sviluppo del software 39 2.2 DER 40 2.3 Condizioni d'errore e livelli software 41 2.4 Ciclo di vita del software 43