Tesi Giuseppe Trincia

Facolt di Ingegneria Corso di Studi in Ingegneria Informatica
tesi di laurea
Analisi e studio di un processo di sviluppo di sistemi safety-critical conformi allo standard RTCA DO-178B
Anno Accademico 2007-2008
Relatore Ch.mo prof. Domenico Cotroneo Correlatore aziendale Ing. Christian Di Biagio candidato Giuseppe Trincia matr. 41/3804
A tutti coloro che hanno sempre creduto in me: ... io.forse!!
Indice
Introduzione Capitolo 1. I sistemi safety-critical 1.1 1.2 1.2.1 1.2.2 1.2.2.1 1.2.2.2 1.2.2.3 1.2.3 1.3 1.3.1 1.3.2 1.3.3 1.4 1.4.1 1.4.2 1.4.3 1.4.4 1.4.5 Sistema Dependability Attributi della dependability Gli impedimenti alla dependability Gli impedimenti alla dependability: I guasti Gli impedimenti alla dependability: Gli errori Gli impedimenti alla dependability: I fallimenti Mezzi per la dependability Safety System Safety Engineering Safety Risk Management Software Safety Engineering Standard industriali per la Safety Standard militari RTCA SAE Serie ARP NASA Serie NSS Standard commerciali 8 11 12 12 14 15 16 17 18 19 21 21 23 27 29 29 31 33 33 34
Capitolo 2. Analisi e descrizione dello standard RTCA DO-178B 2.1 2.2 2.3 2.4 2.5 2.6 2.6.1 2.6.2 2.6.3 2.6.4 Aspetti del sistema relativi allo sviluppo del software DER Condizioni derrore e livelli software Ciclo di vita del software Software Planning Process Software Development Processes Software Requirements Process Software Design Process Software Coding Process Integration Process
37 39 40 41 43 44 45 46 47 48 48
2.7 2.7.1 2.7.1.1 2.7.2 2.7.3 2.7.4 2.8
Integral Process Software Verification Process Software Testing Process Software Configuration Management Process Software Quality Assurance Process Certification Liaison Process Documenti e software generati
49 49 51 54 55 55 56 59 60 62 63 67 67 68 69 75 78 81 83 85
Capitolo 3. Analisi di un progetto Open Source: TOPCASED 3.1 3.2 3.3 TOPCASED TOPCASED: il progetto TOPCASED Quality Process
Capitolo 4. Lo sviluppo software conforme allo standard DO-178B 4.1 4.1.1 4.1.2 4.2 4.2.1 4.3 Sviluppo di un nuovo plug-in di TOPCASED Quality Process Design Struttura delle pagine Processo di certificazione di un nuovo software Un caso duso: la fase Verification Processo di certificazione di un Previously Developed Software
Conclusioni e sviluppi futuri Bibliografia
Elenco delle figure
Figura 1.1: Alcuni scenari critici Figura 1.2: Dependability: attributi, impedimenti, mezzi Figura 1.3: Propagazione delle minacce Figura 1.4: Classificazione dei guasti Figura 1.5: Classificazione dei failures Figura 1.6: Il rischio Figura 2.1: Overview del DO-178B Figura 2.2: Flusso di informazioni tra il sistema e i software life cycle processes Figura 2.3: Software Testing Process Figura 3.1: Cabina di pilotaggio dellAirbus A380 Figura 3.2:TOPCASED Logo Figura 3.3: TOPCASED partners Figura 3.4: TOPCASED, sviluppo model driven Figura 3.5: Modello di sviluppo a V Figura 3.6: TOPCASED Quality Process Figura 3.7: Ciclo di vita di un progetto TOPCASED Figura 3.8: TOPCASED Quality Process Fase iniziale Figura 3.9: Lattivit della scrittura dei Plan Figura 3.10: TOPCASED Quality Process Software Development Plan Figura 4.1: I tre cicli di vita del software disponibili Figura 4.2: Livelli logici delle pagine Figura 4.3: Pagina Description del DO-178B per un nuovo software
11 13 15 17 19 23 38 39 51 59 60 61 62 62 64 64 65 65 66 68 69 70
Figura 4.4: Pagina Work Breakdown Structure del DO-178B per un nuovo software Figura 4.5: Work Breakdown Element del DO-178B per un nuovo software Figura 4.6: Pagina Team Allocation del DO-178B per un nuovo software Figura 4.7: Pagina Work Product Usage del DO-178B per un nuovo software Figura 4.8: Pagina del PSAC Figura 4.9:Pagina del DER Figura 4.10: Ciclo di vita per software di nuova produzione Figura 4.11:Gli standard ARP della SAE International Figura 4.12: Verification phase Figura 4.13: Integration and Test phase Figura 4.14: Software Verification Process Activity Figura 4.15: Review and Analysis of the High-Level Requirements Figura 4.16: Il documento prodotto dal Software Verification Process Figura 4.17: Software Verification Results Figura 4.18: Ciclo di vita di un PDS
71 72 73 73 74 74 75 76 78 78 79 79 80 80 81
Elenco delle tabelle
Tabella 1.1: Classificazione della gravit dei rischi Tabella 1.2: Classificazione delle probabilit di occorrenza dei rischi Tabella 1.3: La matrice HRI Tabella 1.4: Classi di rischio Tabella 2.1: Requisiti di copertura
24 25 25 26 53
Introduzione
Il costante progresso tecnologico ha contribuito alla generazione di numerosi apparati elettronici, di software e strumenti di sviluppo sempre pi evoluti. Questo sviluppo ha fatto s che aumentasse la complessit dei sistemi sviluppati e del loro software di gestione, creato ad hoc per riuscire a sfruttare al meglio le potenzialit e le funzionalit offerte dal sistema stesso. Pertanto, oggi, sono sempre pi rare le realt in cui si realizzano sistemi propri creati con componenti e software propri, ma c sempre una maggiore tendenza allutilizzo di prodotti gi esistenti presenti sul mercato. Infatti, sono sempre pi numerose le aziende che utilizzano Componenti software Off The Shelf (librerie, middleware e sistemi operativi) ovvero componenti hardware e software disponibili sul mercato, per lacquisto da parte di aziende di sviluppo interessate ad utilizzarli nei loro progetti. Lutilizzo di componenti COTS comporta evidenti vantaggi, soprattutto, utilizzare un componente esistente riduce notevolmente i tempi e i costi di sviluppo di un sistema; risaputo che i tempi e i costi, sono fattori fondamentali nei bilanci aziendali. Si produce in minor tempo a costi ridotti. Linteressamento ai vantaggi offerti dallutilizzo di componenti COTS sta aumentando anche da parte delle aziende che producono sistemi critici. Nellambito dei sistemi critici, per, particolare importanza assume la certificazione dei livelli di safety del software COTS. Questi sistemi, infatti, richiedono rigidi requisiti in materia di safety, basti pensare ai sistemi di bordo degli aerei, sistemi di navigazione o sistemi militari. Per questa tipologia di sistemi, i COTS non possono essere integrati immediatamente nel ciclo di sviluppo, ma devono prima essere sottoposti ad una revisione in materia di safety per certificarne laffidabilit. Infatti, devono essere valutate tutte le condizioni
critiche in cui pu trovarsi ad operare il componente e soprattutto come questo reagisce e nel caso di comportamenti indesiderati va attuato un processo di reverse engineering che permetta di rendere il componente affidabile e conforme ai requisiti di safety richiesti. Questo lavoro di tesi, nasce dalla volont dellazienda MBDA ITALIA SPA di rendere certificabile il sistema operativo Finmeccanica Linux ( FNM Linux ). Lintenzione quella di progettare e sviluppare un sistema operativo, appunto FNM Linux, che risponda ai bisogni delle aziende Finmeccanica (HRT, Distribution customization, Safety, Security...). Infatti, si mira a raggiungere lobiettivo di realizzare la distribuzione stessa cercando quanto pi possibile di prendere e riutilizzare quanto gi presente nel mondo Linux, inserendovi per i requisiti derivati da anni di lavoro svolto con successo nel settore dellIT, e dellhigh performance computing. Un progetto che si occupa di gestire il ciclo di vita del software e prospetta la conformit con gli standard di safety; per rendere i sistemi conformi ai requisiti di safety TOPCASED, un progetto Open Source realizzato dalla Airbus in collaborazione con numerose aziende aeronavali, universit, istituti di ricerca ed aziende produttrici di software. Nonostante le molte caratteristiche sviluppate in ambito industriale, riscontrate in TOPCASED, questo non compatibile con le esigenze della MBDA, in quanto in realt non riesce a produrre software certificabile secondo un importante standard, il DO-178B ( Software Considerations in Airborne Systems and Equipment Certification) un documento redatto dallagenzia RTCA (Radio Technical Commission for Aeronautics) per soddisfare lesigenza dellindustria aereonautica di avere una guida per la produzione di software per sistemi e apparecchiature di bordo il cui funzionamento abbia un livello di safety conforme con i requisiti di aereo navigabilit. Il presente lavoro di tesi incentrato sullo sviluppo di un nuovo plug-in di TOPCASED che guidi nella realizzazione di software per sistemi e strumentazione di bordo che sia certificabile per il DO178B. E stato, quindi, realizzato unapplicazione che fornisce specifiche indicazioni sul percorso da seguire per produrre la documentazione necessaria per rendere il software, sia esso di nuova generazione o precedentemente sviluppato (COTS), conforme alle direttive dello standard; guidando lo sviluppatore in tutti i processi che si susseguono durante il ciclo di vita del sistema. Il contesto aziendale in cui si sviluppato questo progetto la societ MBDA ITALIA SPA. Essa
rappresenta unazienda leader nella realizzazione di sistemi di difesa che con i suoi prodotti in grado di soddisfare buona parte della domanda del settore. E una multinazionale sostenuta da tre gruppi che corrispondono ai maggiori azionisti: BAE SYSTEMS (Inghilterra), EADS (Francia), Finmeccanica (Italia); opera nei principali mercati del mondo. Il gruppo offre ai clienti soluzioni altamente tecnologiche, qualit e professionalit nelle tecnologie riconosciute leader a livello mondiale, unendo ad esse le soluzioni imprenditoriali delle societ costituenti. La MBDA ITALIA SPA stimata al livello 2 (Livello Ripetibile) del CMM (Capability Maturity Model). Tale livello caratterizzato dallesistenza di una struttura di gestione dei progetti in grado di curare le commissioni, i costi, lo scheduling delle attivit ed i cambiamenti apportati. Si comprende dunque limportanza di una gestione della configurazione che riguarda soprattutto la sua efficienza.
Capitolo 1 I sistemi safety-critical
Il crescente impiego dei sistemi informatici in scenari fortemente critici, ha evidenziato la necessit di valutare molto attentamente le conseguenze che un malfunzionamento pu avere sulle persone o sullambiente operativo.
Figura 1.1: Alcuni scenari critici
Per Safety, in ingegneria, si intende la capacit di un sistema di non creare involontariamente situazioni di pericolo per luomo o per lambiente. La sicurezza o meno per le persone derivata dalluso di un certo sistema tecnologico strettamente collegata al concetto di rischio, dal momento che nessun evento nelluniverso pu essere previsto con assoluta certezza. Durante lo sviluppo di un progetto ingegneristico esistono rischi di vario tipo che possono comunque essere affrontati con gli stessi strumenti teorici.
Il Risk Management unattivit complessa e delicata che si occupa di tenere sotto controllo il rischio totale, quindi la quantit di incertezza presente in tutto ci che il sistema in qualche modo coinvolge. Lesito di questo processo chiaramente dipende da numerosi fattori. Non esiste un criterio unico adottato universalmente, in linea di massima, comunque, consiste nel pianificare le attivit, nellindividuazione delle aree e delle fonti di rischio e infine nellanalisi delle cause, delle conseguenze e della loro gravit, determinando la probabilit degli eventi critici e le strategie per ridurre il livello totale di incertezza. Si parte comunque dal presupposto che impossibile eliminare completamente tutti i rischi, che il solo individuarli e valutarli non li elimina.
1.1 Sistema
Un 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 lutente pu percepire; esso viene definito corretto se conforme alle proprie specifiche mentre in caso contrario si parler di failure. Un sistema si dice safety-critical se un suo failure pu causare danni fisici a persone o allambiente circostante. I sistemi safety-critical si distinguono dalle normali applicazioni informatiche per requisiti estremamente stringenti di qualit e affidabilit. Spesso tali sistemi hanno anche caratteristiche hard real-time (controllo di impianti, sistemi di avionica, sistemi embedded). E anche i requisiti di sicurezza sono diventati sempre pi critici. Lobiettivo chiave della System Safety Engineering quello di ridurre quanto pi possibile i rischi di safety del sistema, iniziando con la loro individuazione e analisi. Chiaramente queste sono solo le prima fasi di un processo continuo portato avanti durante tutte le fasi del ciclo di vita del prodotto, e che in ciascuna di esse richieder criteri e soluzioni tanto generali quanto ad-hoc.
1.2 Dependability
La Dependability consiste nella capacit di una persona o di un sistema di mostrarsi affidabile agli altri per la sua integrit, per la sua veridicit e la sua affidabilit; queste caratteristiche possono incoraggiare qualcuno a dipendere da tale persona o sistema.
Nellinformatica, la dependability pu essere definita come: [..] the trustworthiness of a computing system which allows reliance to be justifiably placed on the service it delivers [..] [1]
ovvero la propriet di un sistema di essere adeguato alla dipendenza da parte di un essere umano, o di una collettivit, senza il pericolo di rischi inaccettabili. Quindi la dependability pu essere definita come la credibilit di un sistema di calcolo, ovvero il grado di fiducia che pu essere ragionevolmente riposto nei servizi che esso offre. Il servizio offerto da un sistema di calcolo rappresentato dal suo comportamento cos come viene percepito dagli utenti; lutente, umano o fisico, 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
1.2.1 Attributi della dependability

In dipendenza dai servizi che il sistema chiamato a svolgere, vengono messi in evidenza i vari attributi che vanno a fondersi nel concetto di dependability, ovvero la garanzia di funzionamento pu 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 le specifiche.
Availability: in relazione alla rapidit di risposta, o prontezza duso, un sistema dependable rapidamente disponibile. La availability la misura di quanto un sistema funzionante in un periodo in cui possono alternarsi periodi di guasto (fallimento) e periodi di corretto funzionamento.
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 fornito un servizio corretto. Safety: in relazione alla garanzia di evitare situazioni catastrofiche che causano morte, ferite, malattie, danneggiamento o perdita di apparati, danni per lambiente, un sistema dependable sicuro. Per aumentare la safety in caso di guasto, occorre rilevare il guasto e adottare le opportune misure per portare il sistema in uno stato fail-safe.
Security: in relazione alla prevenzione di accessi non autorizzati e/o manipolazioni di informazioni 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 malfunzionante possa essere riportato al suo corretto funzionamento entro il periodo t.
1.2.2 Gli impedimenti alla dependability

Un sistema pu fallire per via di molteplici cause; sono circostanze indesiderabili ma, in linea di principio, non inaspettate, che sono cause/effetti di comportamenti non dependable del sistema. I casi pi comuni sono rappresentati da guasti hardware, errori di progettazione hardaware o software e, ancora, errati interventi di manutenzione. Di seguito, vengono illustrati i concetti di fault, error, e failure:
Fault: stato improprio dellhardware o del software del sistema, causato dal guasto di un componente, da fenomeni di interferenza o da errori di progettazione.
Error: quella parte dello stato del sistema esposta a provocare successivi fallimenti. Un errore nel servizio unindicazione che un guasto in atto, ovvero la causa ipotizzata di un errore un guasto. Uno stesso fault pu generare pi errori (multiple related error). Failure: evento in corrispondenza del quale i servizi offerti non corrispondono pi alle specifiche preventivamente imposte al sistema.
Le minacce che possono condurre al fallimento di un sistema, si propagano secondo uno schema ben preciso: lattivazione di un guasto ( fault ) causa la transizione da uno stato di funzionamento corretto ad uno improprio ( error ). Un error pu generare un failure quando raggiunge linterfaccia del sistema.
Figura 1.3: Propagazione delle minacce
1.2.2.1 Gli impedimenti alla dependability: I guasti

I 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 verificano o sono creati fortuitamente; e guasti intenzionali ( intentional faults ), che sono creati deliberatamente, eventualmente con scopi malevoli. Lorigine 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 dalluomo ( human-made faults ), che sono dovuti allimperfezione umana. I confini del sistema che implicano guasti interni ( internal faults ), che sono parti dello stato del sistema che, quando richiamate dallattivit di elaborazione, produrranno un errore; e guasti esterni ( external faults ), che derivano dallinterferenza dellambiente fisico nel sistema (perturbazioni elettromagnetiche, radiazioni, temperatura, vibrazioni,) o dallinterazione con lambiente umano. La fase di creazione rispetto alla vita del sistema che implica guasti di progetto ( design faults), che derivano da imperfezioni che si verificano durante lo sviluppo del sistema o per modifiche successive; e guasti operativi ( operational faults ), che si verificano durante luso del sistema. La persistenza dei guasti porta a distinguere tra guasti permanenti ( permanent faults ), la cui presenza non in relazione a condizioni temporali puntuali, siano esse interne (attivit di elaborazione) o esterne (ambiente); e guasti temporanei ( temporary faults ), la cui presenza in relazione 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, che sono chiaramente causati dalluomo; questi guasti possono essere sia interni che esterni: per quanto riguarda quelli interni, un esempio linserimento di una logica maliziosa, che sono guasti di progetto intenzionali. Per quel che riguarda i guasti esterni, un esempio una intrusione, che un guasto operativo esterno. I guasti intenzionali possono avvantaggiarsi dei guasti accidentali; come ad esempio unintrusione che sfrutta una crepa nella protezione causata da un guasto accidentale di progetto. E possibile dare una definizione ricorsiva di guasto: un guasto al sistema la conseguenza di un fallimento di un altro sistema che ha fornito o sta fornendo un servizio al sistema in ogetto. La ricorsione termina alla causa che si intende prevenire o tollerare.
Considerando la persistenza temporale, i guasti esterni temporali che originano dallambiente fisico sono spesso chiamati guasti transitori ( transient faults ); i guasti interni temporanei, invece, sono spesso chiamati guasti intermittenti (intermittent faults); tali guasti derivano dalla presenza di combinazioni di condizioni che si verificano raramente. I guasti transienti sono di fatto guasti permanenti la cui condizione di attivazione non pu essere riprodotta, o pu verificarsi solo molto raramente.
Figura 1.4: Classificazione dei guasti
1.2.2.2 Gli impedimenti alla dependability: Gli errori

Un errore il responsabile dellevoluzione del sistema verso un fallimento successivo. Se un errore porter effettivamente ad un fallimento dipende da tre fattori principali: dalla composizione del sistema e la natura della ridondanza esistente, sia essa intenzionale ( introdotta per fornire tolleranza al guasto) che esplicitamente intesa per prevenire che un errore conduca ad un fallimento; oppure non intenzionale ( difficile costruire un sistema che ne privo) che pu avere lo stesso risultato, non atteso, della ridondanza intenzionale. Dallattivit del sistema, cio un errore pu essere compensato prima di provocare un danno. Dalla definizione di un fallimento dal punto di vista dellutente, 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 come tale; rilevato ( detected ), invece, da un algoritmo o meccanismo di rilevamento. Gli errori possoni propagarsi e, in generale, si propagano e propagandosi creano altri errori.
1.2.2.3 Gli impedimenti alla dependability: I fallimenti

Un sistema non pu fallire, e in generale non fallisce, sempre nello stesso modo. I modi in cui un sistema pu fallire (failure modes) possono essere caratterizzati secondo tre punti di vista: dominio, percezione da parte dellutente del sistema e conseguenze sullambiente. Lesperienza ha mostrato che il tasso di fallimento di un componente elettronico, evolve secondo la figura a lato. Durante i primi anni di vita del componente, i fallimenti occorrono frequentemente,
principalmente legati alla presenza di componenti difettosi. La parte decrescente della funzione chiamata la regione della infant mortality. La parte finale della curva (la regione wear-out)
invece rappresenta il verificarsi di fallimenti dopo che il sistema rimasto funzionante per molto
tempo. Nella regione intermedia, il tasso di fallimento costante: il periodo di vita utile di un componente (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, che attesta quando un servizio stato fornito troppo presto o troppo tardi: fallimento nel tempo per anticipo ( early timing failures ) e fallimento nel tempo per ritardo ( late timing failures ). Una classe di fallimenti riferita sia al dominio del valore che a quello del tempo quella dei fallimenti con blocco ( stopping failures ) a causa dei quali lattivit del sistema non pi percepibile dagli utenti e viene fornito un servizio a valore costante. Un caso particolare di fallimento per blocco il fallimento 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
per 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 possono distinguere i fallimenti consistenti ( consistent failure ), quando tutti gli utenti del sistema hanno la stessa percezione dei fallimenti; e i fallimenti inconsistenti ( inconsistent failures ), ovvero quando gli utenti del sistema possono avere percezioni differenti di un dato fallimento. La gravit del fallimento risulta dalle conseguenze dei fallimenti sullambiente del sistema. Per alcuni 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 genere in termini di costo) del beneficio prodotto dal servizio fornito in assenza di fallimento.
Fallimenti catastrofici: per cui le conseguenze sono incommensurabilmente pi grandi del beneficio prodotto dal servizio fornito in assenza di fallimento. Un sistema i cui fallimenti possono essere soltanto minori un sistema fail-safe. La criticit di un sistema la gravit pi elevata dei suoi possibili modi di fallimento.
Figura 1.5: Classificazione dei failures
1.2.3 Mezzi per la dependability

Con il termine mezzi ( means ), vengono indicati una vasta categoria di metodi, tecniche, processi capaci di prevedere servizi degni di fiducia, quindi capaci di incrementare il grado di dependability
di un sistema. La scelta del particolare approccio dipende dalla tipologia di sistema e dallo specifico attributo che si vuole migliorare. I principali means utilizzati nella pratica sono: Fault avoidance: tecniche orientate a minimizzare la probabilit di occorrenza dei fallimenti. Tali tecniche, implicano lutilizzo di componenti altamente affidabili che, pertanto, comportano un incremento dei costi. Sono tecniche definizione delle specifiche, progettazione e codifica. relative alla fase di
Fault prevention: tecniche orientate ad eliminare i fault in fase di progettazione. Si occupano di come possono essere prevenute le occorrenze dei guasti
Fault tolerance: tecniche orientate alla minimizzazione delle conseguenze dei guasti e che tendono ad evitare che essi possano degenerare in un failure. Quindi si occupano di come garantire 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 allindividuazione degli errori e alla rimozione dei guasti durante lo sviluppo o in fase operativa; per ridurre loccorrenza (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 effetti dei guasti sul sistema ) o probabilistico ( stima dei parametri di dependability ).
Le tecniche di prevenzione e di tolleranza ai guasti garantiscono il conseguimento della dependability cio come assicurare al sistema la capacit di fornire un servizio sempre fedele alle specifiche. Le tecniche per evitare/prevedere i guasti rappresentano invece la validazione della dependability ovvero come essere ragionevolmente confidenti nella capacit del sistema di fornire un servizio secondo specifiche. La fiducia ragionevolmente riposta nella stabilit di comportamento del sistema basata sulla valutazione del sistema, condotta primariamente in relazione agli attributi di dependability che sono pertinenti ai particolari servizi richiesti.
1.3 Safety
Questo lavoro di tesi incentrato intorno ad un particolare attributo della dependability: la safety. La safety pu essere definita come laspettativa che un certo sistema non comporti, in certe specifiche condizioni, rischi per la vita delluomo o dellambiente. Il punto di partenza per caratterizzare la safety di un sistema, costituito dal concetto di mishap o incidente, definito come uno o pi eventi non previsti che possono causare danni fisici a persone o compromettere lambiente circostante. La caratterizzazione di un mishap legata alla stima di due parametri: la severit e la probabilit di occorrenza. Basti pensare che un incidente aereo, anche se pi grave (severo) di un incidente automobilistico molto meno probabile che si verifichi. Tale esempio conduce a riflettere sul fatto che, nonostante esista una definizione di safety, estremamente difficile costruire una caratterizzazione univoca e che, qualsiasi sistema, non pu mai essere ritenuto totalmente sicuro. Il rischio (hazard) quindi la combinazione di frequenza di un incidente e delle sue conseguenze; cio una situazione creatasi, tipicamente dovuta ad un evento, che pu portare ad un incidente. Nella pratica, le conoscenze finora acquisite nel progetto di sistemi safety-critical, portano a concludere che non possibile eliminare completamente il rischio di un incidente, ma che soltanto possibile ridurlo. La riduzione del rischio implica un aumento dei costi di sviluppo. La presenza di vincoli economici, implica quindi, la necessit di trovare un giusto compromesso tra i costi ed un livello accettabile di rischio; pertanto importante capire quali sono le condizioni per cui il livello di rischio possa ritenersi accettabile. In generale, i progettisti di sistemi critici non definiscono in modo arbitrario il livello di rischio voluto, ma fanno riferimento ad appositi standard ufficialmente riconosciuti.
1.3.1 System Safety Engineering

La System Safety Engineering deriva dallingegneria e dallanalisi dei Sistemi, discipline nate appena dopo la seconda guerra mondiale come risposta alla sempre maggiore complessit dei dispositivi tecnologici progettati e prodotti. Nonostante in termini di tempo, se paragonato ad altri campi, sia un insieme di tecniche e paradigmi relativamente giovane, limpulso e la velocit con le quali progredita sono state notevoli. Cronologicamente, si pu dire che sia stata ideata negli anni 40, divenuta popolare negli anni 50, affermatasi definitivamente negli anni 60 e inserita
formalmente e giuridicamente nei processi industriali negli anni 70. Uno dei fattori che ha contribuito maggiormente alla sua affermazione, purtroppo, stata la pressione politica generatasi in seguito ad alcuni gravi incidenti (come lesplosione dei missili Atlas e Titan, negli anni 50), le cui cause furono in gran parte attribuite ad errori di design, realizzazione e uso che sarebbe stato possibile correggere in fase di progettazione.
quindi nata una nuova figura professionale in ambito ingegneristico: lIngegnere/Manager della Safety. Questi responsabile dellidentificazione, del tracciamento, delleliminazione e/o limitazione dei rischi di malfunzionamento e avarie del sistema che possono generarsi durante la progettazione, lo sviluppo, il testing e la produzione dellhardware e, se presente, del software. Il System Safety Program (SSP) di un progetto un piano di produzione che accompagna tutto il suo ciclo di vita e che partendo da alcuni obiettivi definisce una serie di attivit da realizzare. Gli obiettivi dellSSP sono principalmente: La safety, in armonia con i requisiti del progetto, deve essere un aspetto del sistema realizzato in modo efficiente e in tempi adeguati, e per il suo raggiungimento devono essere considerati i dati forniti dalle esperienze precedenti. Gli stati potenzialmente rischiosi in cui pu trovarsi un sistema devono essere identificati, tracciati, valutati ed eliminati, o il loro rischio ridotto a un livello accettabile. Le scelte e le azioni intraprese per raggiungere questo obiettivo devono essere documentate. necessario evitare quanto pi possibile di introdurre meccanismi correttivi per rimediare a situazioni di rischio e migliorare la safety a sistema ultimato. Bisogna cercare invece di rendere adeguate le caratteristiche del sistema in fatto di safety durante la fase di progettazione. I cambiamenti nel design, nella configurazione o nei requisiti devono mantenere il livello di rischio accettabile. Deve essere ridotto al minimo luso di materiali pericolosi, per i quali devono essere comunque previste e definite le procedure di corretto smaltimento. Le considerazioni e i dati generati che risultano potenzialmente utili come riferimenti da impiegare in progetti futuri vanno inviati alle apposite banche dati specializzate. Assicurare la safety attraverso una corretta gestione dei cambiamenti allinterno del sistema.
Questi obiettivi generali vengono tipicamente raggiunti se vengono svolte, in merito al programma di safety, le giuste attivit. Tipicamente queste ultime sono: Eliminare le situazioni di rischio attraverso la progettazione. Isolare le sostanze e i componenti pericolosi dalle altre attivit e dal personale non adeguato. Minimizzare il rischio derivato dallimpiego in condizioni ambientali estreme (temperatura, pressione, vibrazioni, etc..). Valutare approcci alternativi per quelle situazioni di rischio che non possono essere eliminate, per esempio ridondanza, mutua esclusione, o fault-tolerance. Proteggere le fonti di alimentazione, i controllori, e gli altri componenti critici attraverso lisolamento e la separazione fisica. Prevedere note e avvisi di sicurezza in nelle istruzioni di montaggio, impiego e riparazione e sui componenti potenzialmente pericolosi. Minimizzare limpatto di un guasto per le persone e gli altri dispositivi. Progettare dei sistemi di controllo, eventualmente anche software, per evitare quanto pi possibile linsorgere di situazioni di rischio e di guasti. Controllare che i criteri di progettazione non prevedano requisiti inadeguati o eccessivi in merito alla safety. Quando ci avviene, proporne di nuovi dimostrandone la validit.
1.3.2 Safety Risk Management

Il rischio generalmente definito come la combinazione tra la gravit di un evento pericoloso e la probabilit della sua occorrenza.
Figura 1.6: Il rischio
Il compito del Safety Risk Management quello di individuare gli hazard e i possibili tipi di malfunzionamento identificandone le cause, valutandone la gravit e la probabilit di avvenimento. Si occupa inoltre di definire i requisiti necessari per la loro gestione e verificare quindi la loro implementazione. Si identifica e quantifica, infine, il rischio residuo appena prima dellimpiego del sistema. Questa attivit assume un ruolo importantissimo in quanto la base, indispensabile, per lidentificazione e la definizione dei requisiti di safety ai vari livelli (hardware, software).
La combinazione della gravit dellevento e della sua probabilit di occorrenza determina lindice della corrispondente classe di rischio, ovvero una misura che indica il rischio associato allevento pericoloso. Un esempio di classificazione della gravit dei rischi riportato nella tabella seguente:
Tabella 1: Classificazione della gravit dei rischi
La probabilit di un certo hazard pu essere invece stimata attraverso analisi statistiche basate sui dati forniti dal produttore dei vari componenti hardware. E quindi possibile effettuare una classificazione delle probabilit di occorrenza degli hazard, cos come mostrato nella tabella seguente:
Tabella 1.2: Classificazione delle probabilit di occorrenza dei rischi
Lattivit di valutazione dei rischi comporta la determinazione dellaccettabilit/inaccettabilit dei pericoli (e dei rischi associati), in modo tale da poter definire le azioni consigliate per eliminarli o controllarli. La classificazione del rischio viene effettuata combinando la frequenza di occorrenza di un evento che conduce ad un pericolo con la gravit della sua conseguenza in un unico strumento in grado di esprimere il peso assoluto di un hazard: la matrice HRI ( Hazard Risk Index). Ciascuna riga corrisponde a una certa probabilit mentre ciascuna colonna a una certa severit. Pu essere altres vista come una funzione a due variabili, in cui il valore di uscita l indice dellhazard.
Tabella 1.3: La matrice HRI
Il risultato di questa combinazione si traduce nella generazione di 24 classi di rischio ad ognuna delle quali viene associato un indice numerico compreso tra 1 e 4 ( con livelli di rischio crescenti) detto RCI (Risk Class Index). Ad ognuno dei 4 indici RCI viene assegnata una categoria di accettabilit, cio un attributo che determina il modo in cui il rischio dovr essere trattato durante tutte le fasi di sviluppo del progetto.
Tabella 1.4: Classi di rischio
Sulla base delle categorie anche possibile dividere la responsabilit allinterno del team, individuando per ciascun livello lautorit organizzativa che dovr occuparsi dei relativi hazard. lari servizi richiesti. importante poter gestire leliminazione e il controllo degli hazard secondo uno schema basato sulla priorit, in quanto il successo e lefficienza delloperazione dipende dalla capacit o meno di agire prima possibile durante la progettazione. Per questo motivo conviene intervenire durante la progettazione, cercando di eliminare lhazard o ridurne il rischio a livelli accettabili. Se lhazard non pu essere eliminato o il relativo rischio non viene ridotto, bisogna incorporare dei dispositivi di sicurezza e fare in modo che questi debbano essere periodicamente verificati. Se non si ancora raggiunto un livello accettabile, si possono incorporare dei dispositivi di segnalazione e fare in modo che il personale che ne a contatto reagisca in maniera corretta durante il loro funzionamento. Se per qualche motivo tutto questo non realizzabile, necessario progettare delle procedure di addestramento e qualifica del personale. Una volta completato il design e la verifica, quando quindi i requisiti sono stati implementati e verificati, necessario valutare il rischio residuo esaminando i dati relativi a ciascun hazard prodotti durante il design. I passi da seguire sono gli stessi della valutazione iniziale dei rischi.
necessario quindi, una volta compiuta la loro individuazione, generare una nuova tabella HRI e verificare che i livelli di tutti gli hazard siano tutti compatibili con gli obiettivi del Safety Program (ad esempio, che non esistano pi rischi di categoria Unacceptable); in caso ci non si verifichi, necessario eseguire un nuovo ciclo di Safety Engineering. Oltre a quantificare il rischio residuo del sistema, quando questo finalmente risultato accettabile, bisogna stimare il rischio residuo insito nelle interfacce tra sistema, sottosistemi, utenti, addetti alla manutenzione e collaudatori. Tutto ci che riguarda il rischio va quindi comunicato al Project Manager e documentato nella base di dati relativa agli hazard. Se il Project Manager ritiene che il rischio residuo non sia sufficientemente basso, bisogna realizzare dei nuovi cicli di ingegnerizzazione affinch lo diventi. In generale, comunque, la gestione del rischio residuo una questione amministrativa abbastanza delicata che prevede lindividuazione, nellanalisi iniziale, di una gerarchia di autorit ciascuna responsabile dellaccettazione o meno dei rischi di un determinato livello e quindi gravit.
1.3.3 Software Safety Engineering

La Software Safety Engineering nasce ufficialmente negli anni 80 quando la NASA, il Dipartimento della Difesa degli Stati Uniti e le istituzioni equivalenti in molti altri paesi del mondo cominciano a fare pesante uso, nei propri sistemi, di computer e software che realizzano funzionalit di sempre maggiore criticit. Storicamente, gli ingegneri del software avevano una visione limitata al particolare sottoproblema che gli competeva, e per questo motivo nei primi standard che si occuparono di safety (MIL-STD882 e derivati) la responsabilit e le attivit in merito a questo aspetto vennero assegnate alla fase di ingegnerizzazione di tutto il sistema. Solo successivamente (con il MIL-STD-498) agli ingegneri del software venne assegnato un ruolo definito e delle responsabilit ufficiali riguardo alla Software System Safety. Questo avvenne quando la complessit del software giunse a un punto tale da richiedere la loro competenza specifica per la valutazione e la gestione dei rischi associati al suo impiego. A prescindere da come sia gestita la responsabilit delle varie attivit in ciascun contesto industriale, comunque chiara la presenza, durante tutti i tipi di processo di cui costituito un progetto, di un gruppo di lavoro composto da Ingegneri della Safety che si occupa di valutare, di definire e di verificare i requisiti e le scelte di progettazione che hanno a che fare con la safety.
Questo gruppo viene comunemente denominato SSWG (System Safety Working Group) e include figure professionali le cui visioni del problema, sommate, ne riescono a considerare tutti i possibili aspetti. Limplementazione, in un progetto, della Software Safety Engineering comporta una serie di attivit eseguite in momenti e contesti diversi. Le prime attivit che vanno definite e di cui ci si occupa, quando parte un progetto che richiede la gestione della safety, sono la pianificazione (planning) e la gestione (management). La pianificazione delle attivit forse la fase pi importante per il successo di tutto il programma di safety, di cui inevitabilmente la prima fase. importante capire quali siano i requisiti di safety alla base di tutto il progetto. La loro assenza o cattiva formulazione pu comportare, quando il problema emerge, ritardi, aumenti di costo e risultati non ottimali. La valutazione del rischio massimo tollerabile unaltro dei fattori chiave per la pianificazione del processo. necessario, partendo dallHazard Risk Index del sistema, stabilire il livello di qualit del sistema in fatto di safety. La generazione degli HRI spesso una questione di abilit nello stimare le probabilit e le severit dei possibili malfunzionamenti. Tuttavia necessario capire dove mettere i confini dei vari livelli di rischio, ad esempio: minimo, serio, inaccettabile. Questultima valutazione viene in genere fatta dal cliente e dai vari anelli intermedi che ci sono fino allo sviluppatore. La gestione una attivit che va avanti lungo tutto il ciclo di sviluppo del sistema, durante il suo uso e il suo mantenimento. Infatti, anche in questultima fase pu verificarsi la necessit di operare dei cambiamenti. Nei compiti dellattivit di gestione c anche quello di occuparsi di monitorare il programma di Software Safety, identificare e risolvere gli hazard a cui il software contribuisce, interfacciarsi con gli altri team (assicurandosi che questi stiano operando correttamente), raccogliere e analizzare i risultati della varie analisi per poi realizzare lanalisi finale di safety del design del sistema. Man mano che lo sviluppo avanza il gruppo deve garantire che le analisi che servono come input per i vari sottoprocessi di sviluppo siano pronte nei tempi giusti. In tutti i casi il cammino sempre quello di identificare i possibili hazard e quindi, una volta allocate le funzionalit, capire quali di esse comportano funzioni safety-critical al livello software. A quel punto si valutano le analisi necessarie per assicurare la safety di ciascuna di esse, che possono per poi essere realizzate da un altro gruppo di lavoro. importante tenere sempre a mente che loperato degli altri gruppi pu subire profonde alterazioni a causa di slittamenti e contrattempi durante lo sviluppo. Bisogna quindi fare in modo che la fase di verifica e test non sia compromessa da tali circostanze. Dal momento che le varie attivit verranno svolte di volta in volta da team diversi, importante che questi capiscano e concordino i loro obiettivi. Condizione necessaria affinch ci avvenga che il
team di safety, ovvero i suoi membri, risulti credibile. Lesito dipende anche dalla capacit di questi di definire un processo realizzabile in maniera efficiente e con un dispendio di risorse limitato.
1.4 Standard industriali per la Safety

Esistono molte direttive, regolamenti, standard e linee guida che stabiliscono i requisiti di safety per lacquisizione, lo sviluppo e il mantenimento di sistemi elettronici che impiegano software. Ogni macro-settore industriale, come quello Militare, Aerospaziale o Aeronautico, presenta una serie di questi criteri che catturano una visione specifica del problema. Ciascuna famiglia di queste normative stata storicamente concepita da entit governative o agenzie diverse. Molti paesi hanno inoltre sviluppato una serie di regolamenti ad-hoc che, ispirandosi a, o adottando altri standard dello stesso contesto, impostano delle norme legislative relative a quel particolare settore. Esistono delle caratteristiche e dei criteri comuni a molti standard, che quindi costituiscono una forte base teorica e pratica per uno studio trasversale sulla Software Safety in generale. In questo capitolo verr effettuata una panoramica sui diversi standard.
1.4.1 Standard Militari

Molti di questi documenti appartengono alla famiglia di standard MIL, creata e mantenuta da organismi di standardizzazione Statunitensi.
MIL-STD-882B Nome completo: MIL-STD-882B, System Safety Program Requirements Organismo/Agenzia: Dipartimento della Difesa, USA. Data e Revisioni: 30/03/1984: Prima versione 01/07/1987: Notice 1 Applicazioni: Utilizzato in molti programmi governativi statunitensi creati durante gli anni 80, prima che fosse emesso il MIL-STD-882C. Descrizione: Lo scopo di questo standard stabilire un SSP (System Safety Program) che riguardi gli aspetti di safety, compatibili con i requisiti delle specifiche missioni, dei sistemi, sottosistemi,
apparecchiature, servizi e delle loro interfacce. Gli autori riconoscono e valutano i rischi presenti nei sistemi safety-critical. Lo standard fornisce linee guida e compiti specifici al team di sviluppo per ci che riguarda il software, lhardware, il sistema in generale e linterfaccia uomo-macchina.
MIL-STD-882C Nome completo: MIL-STD-882C, System Safety Program Requirements. Organismo/Agenzia: Dipartimento della Difesa, USA. Data e Revisioni: 19/01/1993: Prima Versione Applicazioni: Tutti i sistemi e progetti allinterno del Dipartimento della Difesa degli Stati Uniti sviluppati o iniziati prima di una certa data. Descrizione: Questo documento prevede requisiti uniformi per lo sviluppo e limplementazione di un System Safety Program sufficientemente completo per identificare gli hazard del sistema ed imporre requisiti di progettazione e controlli di gestione per prevenire incidenti. Lobiettivo quello di eliminare o ridurre i rischi o comunque ridurre i rischi ad un livello accettabile.
MIL-STD-882D Nome completo: MIL-STD 882D, Standard Practice of System Safety. Organismo/Agenzia: Dipartimento della Difesa, USA. Data e Revisioni: Entrato in vigore a Settembre 1999. Applicazione: Tutti i sistemi e progetti allinterno del Dipartimento della Difesa degli Stati Uniti sviluppati attualmente. Descrizione: Nonostante questo standard sia radicalmente diverso dai suoi predecessori, ne mantiene pienamente lo spirito. Richiede agli sviluppatori si sistema di documentare le loro attivit per soddisfare i requisiti imposti dallo standard; identificare i rischi allinterno del sistema attraverso una analisi sistematica; valutare la gravit dei rischi; identificare tecniche di contenimento dei rischi; ridurre la probabilit di rischi minori a livelli accettabili; verificare e validare la riduzione dei rischi minore; riportare i rischi residui al Project Manager. Questo processo uguale a quello dei due standard precedenti eccetto il fatto che non specifica la programmazione dettagliata delle attivit. Ladozione di questa versione, partendo dalle precedenti, non immediata n automatica, avendo importanti implicazioni sul modo di operare del team di safety e sui dati che esso deve produrre.
DOD-STD-2167A Nome completo: DOD-STD-2167A, Military Standard Defense System Software Development. Organismo/Agenzia: Dipartimento della Difesa, USA. Data e Revisioni: 29/02/1988 Applicazione: Rimane in numerosi contratti con il Dipartimento della Difesa USA. Descrizione: Stabilisce i requisiti per il processo di sviluppo del software, applicabili durante tutto il ciclo di vita dello stesso. I requisiti di questo standard entrano nel merito di come viene effettivamente sviluppato testato e valutato il software dal fornitore. La parte dello standard che si occupa degli aspetti di safety allinterno del processo di sviluppo, recita: Il fornitore/contraente deve operare una analisi atta ad assicurare che i requisiti software, il suo design e le relative procedure operative minimizzino il rischio di condizioni pericolose durante il funzionamento. Ogni condizione o operazione potenzialmente pericolosa deve essere definita e documentata con chiarezza.
MIL-STD-498 Nome completo: MIL-STD-498, Software Development and Documentation Organismo/Agenzia: Dipartimento della Difesa, USA. Data e Revisioni: 5/12/1994 Applicazione: Tutti i sistemi e progetti allinterno del Dipartimento della Difesa degli Stati Uniti sviluppati attualmente. Descrizione: Questo standard unifica il DOD-STD-2176A e il DOD-STD-7935A e definisce una serie di attivit da includere nel processo di sviluppo. impiegato per la produzione di armi e sistemi informativi automatizzati.
1.4.2 RTCA
La RTCA (Radio Technical Commission for Aeronautics) il punto di riferimento tecnico per lindustria aeronautica civile in tutto il mondo.
DO-178B Nome completo: (RTCA)/DO-178B, Software Considerations In Airborne Systems and Equipment Certification. Organismo/Agenzia: RTCA Data e Revisioni: (B) 01/12/1992 Applicazione: La FAA (Federal Aviation Administration) richiede questo standard per la certificazione del software da impiegare in un qualsiasi (sotto)sistema di un velivolo commerciale o di altra strumentazione aeroportuale. Descrizione: Lo standard RTCA DO-178B, dal titolo Software Considerations in Airborne Systems and Equipment Certification, stato sviluppato per stabilire dei criteri per sviluppatori, installatori e utenti di software in dispositivi a microprocessore per lavionica. Tale documento, nellambito del processo di produzione del software, si occupa degli aspetti di verifica e validazione dei requisiti; documentazione; gestione della configurazione del software; controllo di qualit; qualifica dei tool di sviluppo; riuso del software precedentemente sviluppato; software modificabile dallutente; caricamento del software a bordo; Software Multi Versione Diversificato; gestione e tracciamento dei cambiamenti. La versione europea equivalente al DO-178B si chiama ED-12B ed stata emessa dalla EUROCAE. importante capire che il DO-178B prevede la certificazione di un intero e ben specifico sistema hardware+software e non di un componente softwareisolato, come invece prevedono altri standard (ad esempio, lo IEC 61508). Il DO-178B prevede linee guida su come realizzare le fasi di: Progettazione Specifica Sviluppo Testing Deployment
Specifica, oltretutto, la composizione del ciclo (essenziale) di vita del software e i relativi sottoprocessi e altri aspetti inerenti alla creazione di software Safe per applicazioni avioniche. Per riassumere, il DO-178B una linea guida per determinare, in modo consistente e con un ragionevole livello di certezza, che gli aspetti software di un velivolo o di un suo componente rispettano i requisiti FAA di aero-navigabilit.
1.4.3 SAE Serie ARP

La Society of Automotive Engineers ha emesso due standard relativi alle Aerospace Reccomended Practice (ARP) per supervisionare lo sviluppo di sistemi avionici complessi. Il primo, ARP4754 pone particolare enfasi ai sistemi elettronici. Pur essendo la safety un aspetto fondamentale, il documento copre lintero processo di sviluppo. Lo standard affiancato dallARP4761 che contiene linee guida dettagliate ed esempi di procedure di verifica della safety. Nonostante gli standard si possano applicare in una moltitudine di domini diversi, alcuni aspetti sono specifici per lavionica. Il frame work di valutazione dei rischi prevede dei livelli chiamati DAL ( Development Assurance Level) simili ai SIL (Safety Integrity Levels). A ogni malfunzionamento viene assegnato un livello di DAL in base alla gravit delle conseguenze, identificate nel Functional Hazard Assessment. Tuttavia, la gravit del rischio dipende dal livello di controllabilit del velivolo e non dallentit dei danni producibili. Come conseguenza, la probabilit di incidenti non viene considerata nella valutazione iniziale dei rischi. Il livello DAL di un elemento pu essere ridotto se larchitettura: Prevede ridondanza, cio pi implementazioni della stessa funzione. Prevede partizionamento, isola cio gli effetti di un malfunzionamento. Prevede il controllo automatico e attivo dellelemento. Prevede il riconoscimento o correzione umani del malfunzionamento.
I livelli di DAL vengono definiti con il tasso di malfunzionamento equivalente cos da poter valutare il rischio in maniera quantitativa. Nonostante questo, spesso necessario affiancare comunque una valutazione qualitativa. Quando lo sviluppo sufficientemente maturo vengono stimati i tassi di malfunzionamento dei componenti hardware e combinati con lSSA per produrre e valutare i tassi di malfunzionamento funzionale. Lanalisi deve verificare che i requisiti imposti dal livello di DAL siano stati soddisfatti. Per conseguire questo obiettivo, l SSA suggerisce di operare lAnalisi delle Modalit di Malfunzionamento e dei loro effetti e lAnalisi dellAlbero dei Malfunzionamenti.
1.4.4 NASA Serie NSS

La NASA ha da sempre sviluppato sistemi safety-critical, tanto aerospaziali quanto aeronautici. Per supportare la pianificazione delle attivit relative alla safety nei suoi vari dipartimenti, ha pubblicato L NSS 1740.13 (NASA Safety Standard 1740.13)
NSS 1740.13 Nome completo: NASA Safety Standard (NSS) 1740.13, Interim, Software Safety Standard Organismo/Agenzia: NASA, USA Data e Revisioni: 06/1994 Applicazione: Interno alla NASA o presso i suoi fornitori. Descrizione: Lo scopo di questo standard fissare dei requisiti per un approccio sistematico alla safety del software come parte integrale dell SSP. Lo standard descrive le attivit necessarie per assicurarsi che la safety sia considerata nel software acquistato o sviluppato dalla NASA, e che sia supportata durante lintero ciclo di vita del software. Il documento stato creato secondo i principi di altri standard, quali il DOD-STD-2167A e il MIL-STD-882C. Gli obbiettivi definiti dallNSS 1740.13 sono: Garantire che il sistema non si trovi direttamente o indirettamente in uno stato pericoloso. Garantire che il sistema non possa non accorgersi di trovarsi in uno stato pericoloso e che prenda le opportune contromisure. Garantire che il sistema non fallisca nellattenuare il danno in caso di incidente.
1.4.5 Standard Commerciali

A meno che non sia specificato nel contratto tra il fornitore e il cliente, le compagnie private non sono obbligate a specificare e quantizzare il livello di rischio dei loro prodotti. Quando lo fanno per motivi economici, etici o di responsabilit legale. Per quelle aziende che sono motivate o vincolate ad eliminare i rischi di safety nel software esistono un certo numero di standard commerciali. Nonostante molti di questi siano economicamente abbordabili, pochi forniscono a chi li applica un protocollo preciso per la safety o delle linee guida empiriche su come implementare il processo di gestione della stessa.
IEEE - Serie IEEE
LIEEE ha pubblicato gli standard IEEE STD 1228-1994 per la pianificazione della safety nel software per fissare i requisiti minimi di Safety che devono essere contenuti nel piano di sicurezza software. Questi standard contengono quattro parti che parlano di come applicare il processo facendo anche riferimento ad altri standard, definendo il contenuto obbligatorio del piano di Safety relativo al software. Un allegato informativo discute quindi gli aspetti di analisi della stessa allinterno del processo di sviluppo. Lapplicazione di questo standard da intendere come interamente volontaria e il tutto diretto a chi in qualche modo incaricato di definire, pianificare, implementare o supportare il piano di Safety. Il processo segue la metodologia del MIL-STD-882B.
EIA
LEIA (Electronic Industries Association) ha pubblicato il Safety Engineering Bulletin 6B, System Safety Engineering in Software Development, nel 1990. Lo standard e la commissione che lo ha generato si focalizzano sulle procedure, le metodologie, e lo sviluppo di criteri per la gestione della safety nei sistemi, sottosistemi ed equipaggiamenti. Lo scopo del documento dare delle linee guida su come condurre lanalisi della safety sui sistemi controllati o monitorati da computer. Specifica le problematiche e le soluzioni associati a questa attivit, i processi da seguire, quali attivit vanno fatte, e i metodi da impiegare.
IEC - Serie IEC
LIEC (International Electrotechnical Commission) ha creato uno standard internazionale, denominato IEC-61508, che si occupa dei sistemi di controllo della safety nei sistemi elettronici Elettrici / Elettronici / Programmabili (E/E/PES). Fornisce inoltre una piattaforma per gestire il rischio a prescindere dal tipo di tecnologia su cui il sistema basato, sia essa meccanica, idraulica o pneumatica. Il documento include due concetti fondamentali nel campo della safety: il Safety Life Cycle e il SIL (Safety Integrity Level). LOverall Safety Life Cycle introdotto fin dallinizio ed la colla che tiene unita i criteri che vengono man mano presentati.
Il documento descrive tutte le fasi del Safety Life Cycle quando E/E/PES sono utilizzati per gestire la safety. Il tutto stato concepito con in mente il rapido evolversi della tecnologia. Tutto il framework viene considerato adatto ad essere successivamente espanso. Cos come il DO-178B, definisce una scala di livelli di sicurezza (SIL) da 1 a 4, in ordine crescente di criticit. Contrariamente al DO-178B, questo standard permette di certificare un singolo e isolato componente software. I documenti prodotti e richiesti durante il processo di sviluppo sono simili a quelli del DO-178B, ma sono focalizzati pi sulla progettazione, sulluso e sul mantenimento, visto che nascono da un approccio a componente. Uno dei pi importanti documenti tra questi il Safety Manual che contiene le istruzioni e le linee guida su come utilizzare il componente certificato in questione.
Capitolo 2 Analisi e descrizione dello standard RTCA DO-178B
Lo standard DO-178B Software Considerations in Airborne Systems and Equipment Certification un documento redatto dallagenzia RTCA (Radio Technical Commission for Aeronautics) per soddisfare lesigenza dellindustria aereonautica di avere una guida per la produzione di software per sistemi e apparecchiature di bordo il cui funzionamento abbia un livello di safety conforme con i requisiti di aereo navigabilit.
Figura 2.1: Overview del DO-178B
2.1 Aspetti del sistema relativi allo sviluppo del software

La prima operazione da svolgere quella di comprendere le relazioni tra il ciclo di vita del sistema e il ciclo di vita del software; come ad esempio lo scambio di dati tra il sistema e i processi del ciclo di vita del software.
Figura 2.2: Flusso di informazioni tra il sistema e i software life cycle processes
Unattivit trasversale a tutto lo sviluppo del sistema il System Safety Assesement Process che determina e categorizza le condizioni di malfunzionamento del sistema. Durante questo processo, unanalisi del design del sistema permette di definire requisiti relativi alla safety che specificano i l livello di immunit ai malfunzionamenti desiderato e come il sistema deve rispondere nelleventualit che questi si verifichino. Questi requisiti vengono definiti sia per lhardware che per il software al fine di evitare o limitare gli effetti degli errori. Queste decisioni vengono prese durante le fasi di progettazione dellhardware e di sviluppo del software, il System Safety Assesement Process analizza i risultati della progettazione del sistema per verificare se questi soddisfano le condizioni richieste dai requisiti di safety. Il System Safety Assesement Process determina limpatto del design e dellimplementazione del software sulla sicurezza del sistema, basandosi sulle informazioni fornite dai Software Life Cycle Processes. Queste informazioni
includono i margini in cui possibile contenere gli errori, i requisiti software, larchitettura del software e le fonti derrore che possono essere state individuate o eliminate attraverso larchitettura software o mediante luso di tool o di altri metodi usati nella progettazione. Le modifiche al software possono pregiudicare la safety del sistema, pertanto queste vanno sottoposte al System Safety Assesement Process per essere esaminate e valutarne la validit ai fini della safety. Affinch tutti i requisiti siano soddisfatti, allintero ciclo di vita di sviluppo del software devono essere forniti: La descrizione del sistema e dellhardware. I requisiti di sistema allocati al software: Funzionali, di Performance e di Safety. Il livello di criticit del software e la documentazione sullanalisi svolta per la sua determinazione determinazione, che includer le condizioni/categorie di failure e le funzioni allocate al software. Eventuali vincoli di progettazione e strategie da impiegare per migliorare la Safety, quali dissimilarit, partizionamento, ridondanza etc.
2.2 DER
E utile menzionare fin dallinizio che tutti i Sistemi o Software che vengono poi certificati tramite il DO-178B, sono normalmente supervisionati da una figura professionale che in molti casi determina il successo dellintero processo di certificazione. Negli Stati Uniti la FAA (Federal Aviation Administration), lautorit che regolamenta lindustria avionica e che utilizza lo standard per eccellenza, prevede in merito che un corpo di ingegneri esperti in avionica da lei nominati, chiamati DER (Designated Engineering Representatives), controllino on-site la consistenza e la qualit dello sviluppo del progetto man mano che esso viene portato avanti. Tutti i progetti FAA aperti devono avere un rappresentante della stessa assegnato e/o un DER che esamini tutti i dati da sottoporre durante la revisione. In europa accade lo stesso, lente che si occupa degli aspetti di conformit e safety in campo aeronautico lEASA (European Aviation Safety Agency). In Italia lENAC (Ente Nazionale per lAviazione Civile), membro dellEASA, si occupa di safety e sicurezza in ambito nazionale. Nonostante i DER abbiano lautorit per firmare e certificare i progetti, non si occupano di tutti gli aspetti legati al velivolo o alla componente che si sta sviluppando. Un DER software si limita infatti a supervisionare gli aspetti che lo competono. Ogni volta che il software viene aggiornato necessario un altro esame di certificazione. Dal momento che di questo si occuper il DER, importante che egli sia coinvolto in
tutte le fasi del processo di produzione, soprattutto in quelle iniziali. Il DER stesso pu insistere di assistere alle varie fasi, e oltretutto pu sempre rifiutarsi di firmare il progetto se non vengono compiute delle modifiche a suo parere opportune. Tutte queste ultime sono infatti molto pi facili ed economiche da attuarsi durante le fasi di progettazione e sviluppo, che a progetto ultimato. Un ulteriore documento emesso dalla FAA , cio la notifica 8110.97, definisce le linee guida per i DER per approvare software riutilizzato da precedenti progetti certificati (sempre con il DO-178B). Questo permette che progetti opportunamente sviluppati possano utilizzare parti di codice gi sviluppato e certificato. E quindi vitale consultare il DER prima di spendere risorse su parti di software pronto, soprattutto se non si ha lesperienza sufficiente per ridurre il rischio di agire male.
2.3 Condizioni derrore e livelli software

La classificazione delle condizioni derrore del sistema viene effettuata sulla base della gravit delle condizioni di pericolo cui vengono sottoposti il velivolo e i suoi occupanti. Le categorie sono: a. Catastrophic: per i malfunzionamenti che impedirebbero la continuazione sicura del volo e latterraggio, con gravi e fatali lesioni per le persone a bordo. b. Hazardous/Severe-Major: per i malfunzionamenti che ridurrebbero la capacit dellaeromobile o la capacit del personale di bordo di far fronte alle avverse condizioni di funzionamento nella misura in cui vi sarebbero: o Grande riduzione dei margini di sicurezza e di funzionamento. o Stress fisico o carichi di lavoro che il personale di bordo non pu garantire di svolgere in modo completo e accurato. o Ripercussioni negative sui passeggeri, comprese gravi o fatali lesioni ad un ristretto numero di questi. c. Major: per i malfunzionamenti che ridurrebbero la capacit dellaeromobile o la capacit del personale di bordo di far fronte alle avverse condizioni di funzionamento nella misura in cui vi sarebbero: o Significativa riduzione dei margini di sicurezza e di funzionamento.
o Significativo aumento del carico di lavoro per il personale di bordo che ne pregiudichi lefficienza. o Disagio per gli occupanti con possibilit di lesioni per questi. d. Minor: per i malfunzionamenti che non ridurrebbero in maniera significativa la sicurezza degli aeromobili o che comporterebbero al personale di bordo carichi di lavoro eccessivi. o Lieve riduzione dei margini di sicurezza e di funzionamento. o Leggero aumento del carico di lavoro per il personale di bordo (es. modifica del piano di volo) o Lievi disagi per gli occupanti. e. No effect: per i malfunzionamenti che non pregiudicherebbero la capacit operativa dellaeromobile e del personale di bordo.
I livelli software si basano sul contributo del software a potenziali condizioni di fallimento come determinato dal system safety assesement process. I livelli software implicano che il livello di sforzo richiesto per il rispetto dei requisiti di certificazione varia a seconda della categoria della condizione di fallimento. Le definizioni dei livelli software sono: LIVELLO A: software i cui malfunzionamenti, mostrati dal System Safety Assesement Process, appartengono alla categoria Catastrophic. LIVELLO B: software i cui malfunzionamenti, mostrati dal System Safety Assesement Process, appartengono alla categoria Hazardous/Severe-Major. LIVELLO C: software i cui malfunzionamenti, mostrati dal System Safety Assesement Process, appartengono alla categoria Major. LIVELLO D: software i cui malfunzionamenti, mostrati dal System Safety Assesement Process, appartengono alla categoria Minor. LIVELLO E: software i cui malfunzionamenti, mostrati dal System Safety Assesement Process, appartengono alla categoria No effect.
Se il software viene certificato ad un certo livello, lo diviene automaticamente per tutti i livelli di criticit inferiore; non vale, ovviamente, il contrario. Se il comportamento anomalo di un componente software causa pi malfunzionamenti, la categoria derrore a cui viene assegnato quella del malfunzionamento con livello di criticit maggiore. Il Safety Monitoring un mezzo di protezione contro i malfunzionamenti e consiste in un monitoraggio diretto delle funzioni che possono contribuire a generare malfunzionamenti. Le funzioni di monitoraggio possono essere applicate allhardware, al software o a loro combinazioni. Lo standard DO-178B fornisce linee guida anche per le modifiche software che possono essere apportate dallutente e che possono modificare il livello software di appartenenza. I requisiti di sistema includono le disposizioni che regolano le modifiche degli utenti e questi possono apportarle solo nel rispetto di tali regole. Esistono varie categorie di modifiche differenziate dalla potenziale minaccia alla sicurezza del sistema che comporterebbero; queste vanno da modifiche che rimanendo entro certi vincoli non hanno bisogno di una revisione della certificazione a modifiche che vengono totalmente impedite perch andrebbero a pregiudicare la sicurezza del sistema anche se sono correttamente implementate.
2.4 Ciclo di vita del software

Lo standard non prescrive lutilizzo di un preciso modello di sviluppo ma descrive processi separati che comprendono pi cicli di vita e la loro interazione. La sequenza di processi da impiegare dipende dalla particolare istanza di progetto e dalle sue caratteristiche; parti diverse dello stesso progetto possono prevedere cicli di vita diversi. I tipi di processo in un ciclo di vita classico sono generalmente quattro: Requisiti, Analisi, Design e Integrazione. Per il DO-178B, allinterno del ciclo di vita devono essere inclusi i seguenti processi: Software Planning Process: che definisce e coordina le attivit dei Software Development Processes e Integral Processes per il progetto. Software Development Processes: che producono il prodotto software; questi processi sono: Software Requirement Process Software Design Process Software Coding Process
Integration Process
Integral Processes: che garantiscono la correttezza, il controllo e la fiducia dei software life cycle processes e del loro output. Questi processi sono: Software Verification Process Software Configuration Management Process Software Quality Assurance Process Certification Liaison Process
Gli Integral Processes vengono eseguiti in concomitanza con i Software Development Processes durante tutto il ciclo di vita del software.
Un progetto definisce uno o pi cicli di vita del software scegliendo le attivit per ogni processo, specificando una sequenza per le attivit e assegnando le responsabilit per le attivit. Per un progetto specifico, la sequenza di questi processi determinata dalle caratteristiche del progetto stesso, come ad esempio funzionalit del sistema, e la loro complessit, le dimensioni del software, requisiti,risultati di preceddenti applicazioni, hardware. I processi del ciclo di vita del software possono essere iterativi. Il loro inizio o la loro ripetizione avviene quando sono soddisfatti i suoi criteri di transizione ( Transition criteria ), che sono un insieme di condizioni da verificare.
2.5 Software Planning Process

Questo processo produce i piani software e le norme per lo sviluppo dei Software Development Processes e Integral Processes. Il suo scopo quello di definire il metodo di sviluppo del software tale da soddisfare i requisiti di sistema e assicurare che sia conforme ai requisiti di aereonavigabilit. I suoi obiettivi specifici sono: Definizione delle attivit che consentano di rispettare i requisiti di sistema e il livello software. Definizione del ciclo di vita del software, inclusi le relazioni e lo scambio di informazioni tra i processi.
Scelta dellambiente e dei tool di sviluppo Verifica del software affinch rispetti gli obiettivi di sicurezza prefissati. Produzione dei piani di sviluppo software che devono poter essere modificati durante lavanzamento del progetto.
I piani di sviluppo prodotti dal Software Planning Process sono: Plan for Software Aspect of Certification (PSAC): definisce e descrive allautorit certificatrice tutti i metodi, i mezzi e i criteri utilizzati durante lo sviluppo del software per raggiungere gli obiettivi dello standard. Software Development Plan (SDP): definisce il ciclo di vita e lambiente di sviluppo.
Software Verification Plan (SVP): definisce i criteri di verifica da seguire per raggiungere gli obiettivi del Software Verification Process. Software Configuration Management Plan (SCMP): definisce i criteri per il raggiungimento degli obiettivi del Software Configuration Management Process. Software Quality Assurance Plan (SAP): definisce i criteri per il raggiungimento degli obiettivi del Software Quality Assurance Process.
2.6 Software Development Processes

I Software Development Processes vengono applicati in base alle disposizioni del Software Planning Process e sulle indicazioni fornite nel Software Development Plan. I Software Development Processes sono: Software Requirements Process Software Design Process Software Coding Process Integration Process
I Software Development Processes producono uno o pi livelli di requisiti software. I requisiti di pi alto livello vengono prodotti direttamente attraverso lanalisi dei requisiti e dellarchitettura di sistema. Solitamente i requisiti di pi alto livello vengono ulteriormente sviluppati nel corso del Software Design Process e vengono prodotti uno o pi successivi livelli inferiori di requisiti. Ogni
Software Development Process pu produrre dei requisiti derivati che non sono riconducibili direttamente a requisiti di pi alto livello e il loro impatto sui requisiti di safety deve essere valutato dal System Safety Assesement Process. Avendo un ruolo primario durante tutte le fasi di sviluppo software, utile una classificazione dei requisiti: Requisiti di Sistema: forniti direttamente come input allintero ciclo di vita. Specificano cosa il sistema deve fare a prescindere da come e dove. Requisiti Software di Alto Livello: Questi requisiti devono essere tracciabili sui quelli di sistema, cio tutti i requisiti di sistema devono essere coperti da requisiti software. Deve essere chiaramente specificata la natura degli eventuali Requisiti Derivati generati a partire da questi. Requisiti Software di Basso Livello: I requisiti software di basso livello devono essere tracciabili su quelli alto livello, questi ultimi devono tutti tradursi in requisiti di basso livello, e devono giustificare le scelte di progettazione e i requisiti derivati eventualmente emersi. Il codice sorgente deve essere direttamente tracciabile sui requisiti di basso livello e sullarchitettura software, per evitare che vi sia codice morto e che non vi siano requisiti non implementati. Requisiti Software Derivati: Possono essere prodotti ex-novo da ciascuno dei quattro processi in seguito a scelte architetturali e di design. Questi requisiti non sono direttamente tracciabili da requisiti di livello superiore. Il loro impatto sui requisiti di safety deve essere valutato dal System Safety Assesemnt Process.
2.6.1 Software Requirements Process

Durante il Software Requirement Process vengono analizzati i requisiti e larchitettura di sistema per generare i requisiti di alto livello. Questi includono requisiti funzionali, di performance, dinterfacciamento e di safety. I requisiti di alto livello devono essere conformi al Software Requirements Standards ed essere verificabili e consistenti. Ogni requisito di sistema deve essere riconducibile a uno o pi requisiti di alto livello ed ogni requisito di alto livello deve essere riconducibile a uno o pi requisiti di sistema, ad eccezione dei requisiti derivati. Questi ultimi vanno forniti al Sistem Safety Assesement Process.
Gli obiettivi del Software Requirements Process sono quindi quelli di sviluppare i requisiti di alto livello e di indicarli al System Safety Assesemnt Process per la loro valutazione. Gli input al Software Requirements Process includono i requisiti di sistema, linterfaccia hardware e larchitettura del sistema dal system life cycle process e il Software Development Plan e il Software Requirements Standards dal software planning process. Quando sono soddisfatte le condizioni dei Transition Criteria questi input vengono utilizzati per sviluppare i requisiti software di alto livello. Il prodotto principale di questo processo il Software Requirements Data. Il Software Requirements Process completo quando i suoi obiettivi e gli obiettivi degli Integral Processes ad esso associati, sono raggiunti.
2.6.2 Software Design Process

I requisiti software di alto livello vengono raffinati attraverso una o pi iterazioni nel Software Design Process per sviluppare la Design Description che include larchitettura software e i requisiti di basso livello che dovranno poi essere implementati nel Source Code. Gli input dei questo processo sono il Software Requirements Data, il Software Development Plan e il Software Design Standards. Quando sono soddisfatti i criteri di transizione, i requisiti di alto livello vengono utilizzati per produrre I requisiti di basso livello e larchitettura del software che devono essere conformi al Software Design Standards ed essere verificabili e consistenti. Ogni requisito di alto livello deve essere riconducibile ad uno o pi requisiti di basso livello ed ogni requisito di basso livello deve essere riconducibile a uno o pi requisiti di alto livello. I requisiti derivati generati devono essere definiti ed analizzati dal System Safety Assesement Process al fine di garantire che i requisiti di alto livello non vengano compromessi. Loutput prodotto dal Software Design Process il Design Description che include appunto larchitettura software e i requisiti di basso livello. Gli input insufficienti o incorretti rilevati durante il Software Design Process devono essere forniti in retroazione al system life cycle process, al Software Requirements Process, o al Software Planning Process, per chiarimenti o correzioni. Il Software Design Process completo quando i suoi obiettivi e gli obiettivi degli Integral Processes ad esso associati, sono raggiunti.
2.6.3 Software Coding Process

Nel Software Coding Process viene sviluppato Source Code partendo dallarchitettura del software e dai requisiti di basso livello. Lobiettivo di questo processo quello di produrre il Source Code e questo deve essere tracciabile, verificabile, consistente e deve implementare correttamente i requisiti di basso livello. Il Source Code prodotto deve essere conforme con larchitettura del software; deve essere conforme al Software Code Standards e deve essere riconducibile al Design Description. Gli input del Coding Process i requisiti di basso livello e larchitettura software dal Software Design Process, il Software Development Plan e il Software Code Standards. I principali risultati di questo processo sono il Source Code e lObject Code. Gli input inadeguati o errati rilevati durante il Software Coding Process devono essere forniti in retroazione al Software Requirements Process, al Software Design Process o al Software Planning Process per chiarimenti o correzioni. Il Software Coding Process completo quando i suoi obiettivi e gli obiettivi degli Integral Processes ad esso associati, sono raggiunti.
2.6.4 Integration Process

Le apparecchiature dutente (target computer), il Source Code e lObject Code prodotti dal Software Coding Process, il linking e il caricamento dei dati vengono usati nellIntegration Process per sviluppare il sistema finito ( Integrated airborne system or equipment ). Lobiettivo dellIntegration Process quello di caricare lExecutable Object Code nelle apparecchiature dutente per lintegrazione hardware/software. Gli input dellIntegration Process sono larchitettura del software dal Software Design Process, e il Source Code e lObject Code dal Software Coding Process. Gli input insufficienti o incorretti rilevati durante lIntegral Process devono essere forniti in retroazione al Software Requirements Process, al Software Design Process, al Software Coding Process o al Software Planning Process per chiarimenti o correzioni. L Integration Process completo quando i suoi obiettivi e gli obiettivi degli Integral Processes ad esso associati, sono raggiunti.
2.7 Integral Processes

Gli Integral Processes garantiscono la correttezza, il controllo e laffidabilit dei Software life cycle Processes e dei loro prodotti. Gli Integral Process sono: Software Verification Process Software Configuration Management Process Software Quality Assurance Process Certification Liaison Process
E importante considerare che gli Integral Process vengono eseguiti in concomitanza con i Software Development Processes durante tutto ilciclo di vita del software. isogno di una revisione della certificazione a modifiche che vengono totalmente impedite perch andrebbero a pregiudicare la sicurezza del sistema anche se sono correttamente implementate.
2.7.1 Software Verification Process

La verifica una valutazione tecnica dei risultati del Software Development Process e del Software Verification Process. Il Software Verification Process applicato come definito dal Software Planning Process e dal Software Verification Plan. La verifica non un semplice test, in quanto un test, in generale, non pu dimostrare lassenza di errori. Lo scopo del Software Verification Process quello di individuare e segnalare gli errori che possono essere stati introdotti durante i Software Development Processes e garantire che lo stesso processo di verifica sia esaustivo; la rimozione degli errori, invece, un compito che spetta ai Software Development Processes. Gli obiettivi di questo processo sono quelli di verificare che: I requisiti di sistema siano stati tradotti in requisiti di alto livello che li soddisfano. I requisiti di alto livello siano stati tradotti in requisiti di basso livello e nellarchitettura del software e che entrambi li soddisfino. Larchitettura del software e i requisiti di basso livello siano stati tradotti nel Source Code e che questo li soddisfi. LExecutable Object Code soddisfi i requisiti software.
I mezzi utilizzati per soddisfare questi obiettivi devono essere tecnicamente corretti e completi per il livello software.
Questi obiettivi vengono raggiunti attraverso una combinazione di rivisitazioni, analisi, sviluppo di casi di test e procedure di prova, e consecutive esecuzioni di tali procedure. Le revisioni e le analisi forniscono una valutazione sulla precisione, completezza e verificabilit dei requisiti software, dellarchitettura del software e del Sourcs Code. Lo sviluppo dei casi di test pu fornire ulteriori valutazioni sulla consistenza e la completezza dei requisiti. Lesecuzione delle procedure di prova fornisce, invece, una dimostrazione di rispetto dei requisiti. Gli input del Software Verification Process includono i requisiti di sistema e del software, larchitettura del software, i dati sulla tracciabilit, il Source Code, lExecutable Object Code e il Software Verification Plan. I risultati, invece, sono registrati nei due documenti: Software Verification Cases and Procedures e Software Verification Results. Il processo di verifica prevede che ci sia tracciabilit tra lo sviluppo dei requisiti software e la verifica di tali requisiti. In particolare la tracciabilit tra i requisiti software e i casi di test sono esplicitati nella Coverage Analysis basata sui requisiti; mentre quella tra il codice e i casi di test riporta tata nella Structural Coverage Analysis. Durante il Software Verification Process vengono effettuate pi analisi e revisioni dei risultati del Software Development Process e del Software Verification Process. Una distinzione tra revisioni e analisi che le analisi forniscono elementi di prova di correttezzae consistenza mentre le revisioni forniscono una valutazione qualitativa della correttezza. Una revisione pu consistere in un controllo del risultato di un processo guidato da una lista di parametri di controllo. Lanalisi pu esaminare in dettaglio le funzionalit, le prestazioni, la tracciabilit e la safety di un componente software, e il suo rapporto con altri componenti allinterno del sistema di bordo o di apparecchiature di bordo. Le attivit di revisione e analisi sono: Analisi e revisione dei requisiti di alto livello: conformit ai requisiti di sistema, accuratezza e consistenza, compatibilit col sistema, verificabilit, conformit agli standard, tracciabilit, validit degli algoritmi. Analisi e revisione dei requisiti di basso livello: conformit ai requisiti di alto livello. Le altre sottoattivit sono le stesse che per i requisiti di alto livello anche se con un significato diverso. Analisi e revisione dellarchitettura di sistema: conformit ai requisiti di alto livello, consistenza, compatibilit col sistema, verificabilit, conformit agli standard, integrit del partizionamento.
Analisi e revisione del codice sorgente: conformit ai requisiti di basso livello e allarchitettura software, verificabilit, conformit agli standard, tracciabilit, accuratezza e consistenza.
Analisi e revisione delloutput del Processo di Integrazione: Esame dettagliato di quanto linkato e caricato sul sistema, e della sua mappa di memoria. Analisi e revisione dei casi e procedure di test e dei loro risultati: I casi di test devono prevedere delle procedure e devono produrre dei risultati. Se questi ultimi differiscono da quando atteso, il motivo di questa eventualit deve essere opportunamente documentato.
2.7.1.1 Software Testing Process

Il test del software di bordo ha due obiettivi complementari; il primo quello di dimostrare che il software soddisfi tutti i suoi requisiti e il secondo quello di dimostrare, con un elevato grado di fiducia, che gli errori, che potrebbero portare ad inaccettabili condizioni di malfunzionamento, sono stati rimossi.
Figura 2.3: Software Testing Process
In figura si possono notare i tre tipi di test: Hardware/Software integration testing: per verificare il corretto funzionamento del software nelle apparecchiature dutente. Software integration testing: per verificare le interrelazioni tra i requisiti software e i componenti; e per verificare limplementazione dei requisiti e componenti software allinterno dellarchitettura del software. Low-level testing: per verificare limplementazione dei requisiti software di basso livello.
I test devono essere basati principalmente sui requisiti software. Devono essere sviluppati per verificare la correttezza delle funzionalit e per stabilire le condizioni per rilevare i potenziali errori. La Software Requirement Coverage Analysis determina quali requisiti software non sono stati testati mentre la Structural Coverage Analysis determina quali parti di codice non sono state testate. Un ambiente di test pu essere composto dal sistema reale, da un suo simulatore o da entrambi. Alcuni test per devono essere eseguiti sul sistema finale in quanto i loro risultati sono validi solamente in quel contesto. Pi tipi di test vengono svolti: Casi di Test sul Normal Range: viene testata la capacit del software di operare sullinput previsto, cio in condizioni normali. Casi di Test sul Range Anomalo: viene testata la capacit del software di operare su un input non previsto, cio in condizioni anormali. Test di Robustezza: viene dimostrata labilit del software di rispondere ad input e condizioni anormali. Metodi di testing basati sui requisiti: Testing di integrazione tra hardware e software: si incentra sulle possibili fonti di errore allinterno del sistema, e sulle funzionalit di alto livello. Testing di integrazione software: Si verifica che i componenti software interagiscano bene tra loro e soddisfino i requisiti e larchitettura software. E un tipo di test che pu procedere incrementalmente, aggiungendo man mano blocchi di codice e i requisiti relativi al caso di test. Testing di basso livello: Si verifica che ogni componente software soddisfa i suoi requisiti di basso livello. Test Coverage Analysis:
Coverage Analysis basata sui requisiti: Verifica che il testing basato sui requisiti testi bene quanto liplementazione copra i requisiti software. Questo avviene quando esiste un caso di test per ogni requisito e che questo copra il range normale e anomalo. Structural Coverage Analysis: Il testing strutturale si occupa materialmente dellanalisi del codice attraverso i casi di test .Lentit di questa attivit ha tre livelli: o SC - Statement Coverage: Ogni istruzione (statement) nel programma deve essere invocata e usata almeno una volta. Comunemente, il termine copertura del codice si riferisce a questo. o DC Decision Coverage: Ogni punto di entrata e uscita del programma deve essere stato invocato almeno una volta e ogni decisione allinterno del programma deve essere presa in tutti i modi possibili (nel caso di espressioni booleane complesse, conta il risultato: TRUE o FALSE). o MCDC - Modified Condition Decision Coverage: Ogni punto di entrata e uscita del programma deve essere stato invocato almeno una volta e ogni decisione allinterno del programma deve essere presa in tutti i modi possibili e deve essere calcolata la tabella di verit che mette in relazioni le variabili di tali espressioni complesse con il risultato booleano.
I requisiti di copertura del codice in base al livello di criticit sono i seguenti:
Livello
Livello A Livello B Livello C Livello D Livello E
Copertura
MCDC DC SC
Requisiti di copertura
Livello B + 100% Modified Condition Decision Coverage Livello C + 100% Decision Coverage Livello D + 100% Statement (Istruzione) Coverage 100% Copertura dei Requisiti
Tabella 2.1: Requisiti di Copertura
Lanalisi di copertura individua quindi quali parti di codice non sono state coperte dai test case, e verifica che sia stato raggiunto un livello di copertura compatibile con quello richiesto dal particolare livello di criticit. Questo tipo di analisi pu essere effettuata sul codice sorgente ma nel caso di livello di criticit A bisogna testare il codice oggetto per includere quelle parti non tracciabili direttamente al codice sorgente (per esempio codice inserito dal compilatore). Il requisito di Testare il codice oggetto (livello A) pu essere rilassato a testare il codice sorgente nel caso di utilizzo di compilatori certificati per il livello A. Nel caso in cui sia presente codice non coperto dai test bisogna operare ulteriori verifiche in base al motivo che ha generato leventualit.
2.7.2 Software Configuration Management Process

Il Software Configuration Management Process si occupa di definire e monitorare tutta linfrastruttura su cui lo sviluppo del progetto si basa e di coordinare la generazione e il mantenimento di tutti gli artefatti prodotti o utilizzati durante i vari altri processi. Questi devono essere controllati, immagazzinati e recuperati secondi i criteri imposti dal piano relativo a questo processo. Viene applicato come definito dal Software Planning Process e dal Software Configuration Management Plan. I suoi risultati vengono riportati nei Software Configuration Management Records. Il Software Configuration Management Process lavora in cooperazione con gli altri Software life cycle Processes fornendosi aiuto per soddisfare gli obiettivi di: Fornire, definire e controllare la configurazione del software durante tutto il ciclo di vita. Fornire la capacit di riprodurre lExecutable Object Code per la creazione del software o per la rigenerazione in caso di necessit per indagini o modifiche. Fornire il controllo dei processi di input e output durante il ciclo di vita del software per assicurare la coerenza e la ripetibilit delle attivit dei processi. Fornire la sufficiente attenzione ai problemi individuati durante tutto il processo di produzione. Garantire una sicura archiviazione, il recupero e il controllo della configurazione del software.
Il Software Configuration Management Process non si ferma quando il prodotto software viene certificato secondo lo standard dallautorit certificatrice ma continua per tutta la vita del sistema a bordo di aerei o equipaggiamenti.
2.7.3 Software Quality Assurance Process

Il Software Quality Assurance Process si occupa essenzialmente di verificare che tutti gli altri processi siano portati avanti in accordo con i relativi piani (plans). Viene applicato come definito dal Software Planning Process e dal Software Quality Assurance Plan e isuoi risultati sono riportati nei Software Quality Assurance Records. Il Software Quality Assurance Process valuta i software life cycle processes e i loro risultati per ottenere la sicurezza che gli obiettivi siano soddisfatti, che le carenze siano state riscontrate, valutate, monitorate e risolte; e che il software prodotto sia conforme ai requisiti di certificazione. Controlla inoltre che quando si passa da un processo ad un altro siano stati effettivamente soddisfatti i loro criteri di transizione.
2.7.4 Certification Liaison Process

Il Certification Liaison Process stabilisce la comunicazione e la comprensione tra il team di sviluppo e lautorit certificatrice durante tutto il ciclo di vita per curare il processo di certificazione. Il flusso di eventi che si susseguono, generalmente, : 1. Limpresa responsabile del progetto, presenta il Plan for Software Aspects of Certification ed altri dati richiesti allautorit certificatrice. 2. Lautorit certificatrice esamina ed eventualmente corregge il Plan for Software Aspects of Certification. 3. 4. Lautorit certificatrice approva il piano e il progetto entra nella fase di sviluppo. Limpresa, durante lo sviluppo, risolve i problemi riscontrati dallautorit certificatrice durante la revisione costante del materiale prodotto.
5.
Limpresa fornisce allente certificatore il Software Accomplishment Summary e il Software Configuration Index. Gli altri artefatti (Requisiti, Design, ..) possono comunque essere richiesti e devono pertanto essere completi e disponibili.
6.
Lente certificatore, una volta esaminati tutti i dati e la documentazione che ritiene opportuni, approva il progetto e rende il software certificato.
2.8 Documenti e software generati

I dati prodotti durante il ciclo di vita del software sono utilizzati per pianificare, dirigere, spiegare, definire, memorizzare, o fornire elementi di prova delle attivit svolte. Questi dati consentono di apportare modifiche ai processi del ciclo di vita del software, alle certificazioni del sistema o delle apparecchiature, alle post-certificazioni del software prodotto. I dati devono possedere precise caratteristiche, pertanto devono essere non ambigui, completi, verificabili, consistenti, modificabili, tracciabili. Importante il ruolo ricoperto dal Quality Manager che assiste il team di sviluppo durante la scrittura dei documenti.
Plan for Software Aspects of Certification: il principale strumento utilizzato dallautorit certificatrice per determinare se un richiedente propone un ciclo di vita del software, commisurato con il rigore necessario per il livello di criticit del software da sviluppare.
Software Development Plan: include gli obiettivi, le regole, e il ciclo o i cicli di vita da utilizzare nei Software Development Processes. Questo documento pu essere incluso nel Plan for Software Aspects of Certification.
Software Verification Plan: una descrizione delle procedure di verifica da utilizzare per soddisfare gli obiettivi del Software Verification Process.
Software Configuration Management Plan: stabilisce i metodi da utilizzare per il raggiungimento degli obiettivi del Software Configuration Management Process durante tutto il ciclo di vita del software.
Software Quality Assurance Plan: stabilisce i metodi da utilizzare per il raggiungimento degli obiettivi del Software Quality Assurance Process. Pu, inoltre, includere la descrizione dei processi di miglioramento, delle metriche, e dei metodi di gestione progressivi.
Software Requirements Standards: lo scopo di questo documento quello di produrre metodi, norme e strumenti da utilizzare per sviluppare i requisiti di alto livello. Software Design Standards: lo scopo di questo documento quello di produrre metodi, norme e strumenti da utilizzare per sviluppare i requisiti di basso livello.
Software Code Standards: la finalit di questo documento quello di definire i linguaggi di programmazione, i metodi, le norme e gli strumenti da utilizzare nella realizzazione del codice del software.
Software Requirements Data: la definizione dei requisiti di alto livello, inclusi i requisiti derivati.
Design Description: la definizione dellarchitettura software e dei requisiti di basso livello in grado di soddisfare i requisiti di alto livello.
Source Code: questo prodotto consiste nel codice scritto in linguaggio sorgente e le istruzioni del compilatore per generare lObject Code dal Source Code, il linkaggio e il caricamento dei dati. Dovrebbe, inoltre, includere anche lidentificazione del software, compresi il nome e la data di revisione e/o versione.
Executable Object Code: costituito da una forma di Source Code che direttamente utilizzabile dallunit centrale di elaborazione del computer dellutente ed , pertanto, il software che caricato nellhardware o sistema.
Software Verification Cases and Procedures: contiene i dettagli su come sono implementate le attivit del Software Verification Process.
Software Verification Results: contiene i risultati prodotti dalle attivit del Software Verification Process.
Software Life Cycle Environment Configuration Index: individua la configurazione dellambiente del ciclo di vita del software. Questo indice scritto per la riproduzione dellambiente dellhardware e del ciclo di vita del software, per la rigenerazione del codice, verifiche o modifiche software.
Software Configuration Index: individua la configurazione del software prodotto.
Problem Reports: un mezzo per identificare e memorizzare le soluzioni ai comportamenti anomali del software prodotto, ai processi che non rispettano i piani e le norme prescritte per essi e alle carenze dei dati prodotti durante il ciclo di vita del software.
Software Configuration Management Records : contiene i risultati delle attivit del Software Configuration Management Process, come ad esempio, le liste delle identificazioni delle configurazioni, le librerie software, i cambiamenti storici e i documenti archiviati.
Software Quality Assurance Records: contiene i risultati del Software Quality Assurance Process (SQA). Possono includere le recensioni del SQA, i rapporti delle riunioni, le relazioni sulle revisioni della certificabilit del software.
Software Accomplishment Summary: il documento principale per dimostrare il rispetto del Plan for Software Aspects of Certification.
Capitolo 3 Analisi di un progetto Open Source: TOPCASED
Quando i computer hanno un ruolo vitale nella produzione di aerei e automobili, ma anche di apparecchiature mediche o impianti elettrici di controllo, le richieste su hardware e software sono particolarmente esigenti in quanto i rispettivi strumenti di sviluppo devono soddisfare particolari requisiti che non possono essere soddisfatti dal mercato del software tradizionale.
Figura 3.1: Cabina di pilotaggio dell'Airbus A380
Il nuovo Airbus A380 attualmente tra i pi sofisticati, in termini di tecnologia, aereo commerciale: i loro piloti controllano il jet con un joystick (Sidestick Controller), e tutte le manovre di volo sono controllate dal computer. I pannelli LCD hanno sostituito gli strumenti tradizionali nella cabina di pilotaggio. Sono un insieme di singoli sistemi ma tutti strettamente collegati in rete. Un aeromobile Airbus ha una vita lavorativa fino a 30 anni. A bordo hardware e software hanno bisogno di manutenzione, di aggiornamenti e di essere adattati alle nuove specifiche per lo stesso lasso di tempo. Tuttavia, 30 anni, uneternit per l'industria del software; nessun fornitore di software pu garantire che i propri strumenti saranno ancora utilizzabili e soddisfare tutte le esigenze per un tempo cos lungo. E il percorso di produzione delle specifiche di sistema per testare i programmi di controllo e l'hardware su cui eseguirli richiede molti strumenti.
3.1 TOPCASED
Figura 3.2: TOPCASED Logo
Guidata dal costruttore di aeromobili Airbus, diverse societ appartenenti al polo francese Aerospace Valley vicino Tolosa hanno, pertanto, ha costituito un consorzio e ha avviato il TOPCASED, un progetto Open Source per creare il necessario sistema di strumenti di sviluppo. TOPCASED, che lacronimo di Toolkit in OPen source for Critical Applications & SystEms Development.; si propone quindi di fornire nuovi strumenti di sviluppo per i sistemi di sicurezza aerospaziale critici utilizzando principi Open Source. TOPCASED mira a fornire a fornire un kit completo che copra l'intero processo di sviluppo quindi anche di stabilire le specifiche per la gestione dei compiti per i vari livelli del progetto come la tracciabilit dei requisiti, il controllo delle versioni e dei cambiamenti. Creare uno strumento di qualit un obiettivo importante, dato che gli strumenti sono destinati, in particolare, per lo sviluppo di sistemi affidabili. Oltre ad Airbus, numerose imprese del settore aerospaziale e automobilistico, cos come produttori di hardware e software, le universit e gli istituti di ricerca sono coinvolti nel progetto. Tra i
partner, il costruttore di satelliti EADS Astrium, Siemens VDO Automotive , l'agenzia spaziale francese CNES, i produttori di elettronica di Rockwell Collins e Thales, i produttori software Adacore, Anyware Technologie, ELLIDISS Software e TNI Software, alcuni fornitori di servizi di comunicazione specializzata in avionica, nel settore automobilistico e sistemi embedded, la Carnegie Mellon University, nonch numerosi istituti di ricerca francesi e le migliori universit specializzate in tecnologia aerospaziale, informatica e elettronica. manifestato il loro interesse a diventare partner del progetto. Anche altre aziende hanno
Figura 3.3: TOPCASED partners
Il progetto organizzato con : un gruppo direttivo si occupa di considerazioni strategiche e organizzative e delega la parte tecnologica ad un comitato architetturale e il controllo della qualit del progetto ad un gruppo di controllo di qualit. Sotto-progetti di lavoro su singole famiglie di strumenti vengono sviluppati in collaborazione con partner che sono responsabili per la ricerca e lo sviluppo in ciascun settore. TOPCASED co-presieduto da un rappresentante di Airbus e da un rappresentante comune delle istituzioni accademiche partner. Il progetto finanziato tramite due fonti, pubblica e commerciale: TOPCASED parte del ISAURE (Ingnierie des Systmes embarqus aronautiques, de l'Automobile, des Radiocomunications et de l'Espace), programma di governo che sostiene lo sviluppo di sistemi embedded per l'industria aerospaziale, automobilistica e tecnologie radio.
3.2 TOPCASED: il progetto

TOPCASED consiste di vari sotto-progetti ospitati sui server dell universit francese ENSEEIHT (Ecole Nationale Suprieure d'Electrotechnique, d'Electronique, d'Informatique, d'Hydraulique et des Tlcommunications). Il progetto incentrato sugli strumenti di modellizzazione, in accordo con il concetto di Model Drive Engineering (MDE), dove un modello del sistema da sviluppare controlla lintero processo di sviluppo.
Figura 3.4: TOPCASED, sviluppo model driven
TOPCASED copre l'intero processo di sviluppo del sistema. Il suo obiettivo principale quello di fornire alla comunit Open Source una serie di strumenti e software per la produzione di sistemi, con particolare riferimento al modello di sviluppo a V e a tutte le attivit trasversali.
Figura 3.5: Modello di sviluppo a "V"
Tra gli strumenti, particolare rilievo, va dato agli editor grafici per diversi linguaggi di modellazione: l'Object Management Groups Unified Modeling Language (UML), lEcore metalinguaggio di modellazione per Eclipse, il SysML Sistems Modeling Language e lAADL (Architecture Analysis and Design Language), un linguaggio per descrivere le architetture di sistema e software per sistemi real-time. TOPCASED utilizza l'infrastruttura di Eclipse come piattaforma di sviluppo e coopera con Eclipse Modeling Project (EMP) e Eclipse Modeling Framework (EMF). I singoli sotto-progetti sono principalmente pubblicata sotto la Eclipse Public License 1.0 (EPL) che impone rigorosamente: i software sviluppati sulla base di TOPCASED devono essere pubblicati sotto licenza EPL. La licenza garantisce che i componenti sviluppati e i miglioramenti sviluppati restano Open Source, ma permette anche lo sviluppo di prodotti proprietari che utilizzano tali componenti. Il modello di consorzio di sviluppo Open Source, utilizzato dal progetto TOPCASED, offre diversi vantaggi per le imprese e le istituzioni membro. I membri possono controllare e contribuire fin dalle fasi iniziali del progetto in modo tale possono garantire che gli strumenti sviluppati siano conformi alle loro esigenze. Rispetto agli sviluppi in-house (in proprio) questo approccio permette di risparmiare denaro, in quanto i costi di sviluppo sono ripartiti nei vari membri. Lutilizzo di un modello di licenza Open Source garantisce che tutti i contribuenti possono utilizzare il codice corretto e ci particolarmente importante per un settore industriale che ragiona anche per i decenni successivi di sviluppo del prodotto: le imprese hanno il controllo completo sui loro strumenti e non dipendono da politiche di produzione di aziende esterne. Questi vantaggi dovrebbero garantire una approvvigionamento costante di potenziali membri futuri del consorzio; anche perch il progetto abbastanza completo. Gli strumenti di TOPCASED possono essere utilizzati per lo sviluppo non solo del software, ma anche di tutto lhardware e del sistema intero.
3.3 TOPCASED Quality Process

TOPCASED Quality Process un processo di TOPCASED che copre lintero ciclo di sviluppo di un sistema definendo le linee guida per la sequenza di operazioni da effettuare nella produzione dei processi di un progetto TOPCASED subordinati a vincoli sui requisiti.
Figura 7: TOPCASED Quality Process
In questa prospettiva si possono definire alcuni obiettivi che con lutilizzo di questo processo si cerca di raggiungere: La creazione di un set di processi e strumenti per lo sviluppo di sistemi software-based; Progettazione di sistemi critici ( avionici, spaziali, automobilistici); Il progetto deve rispettare gli standard come: DO-178B, ECSS, IEC 61508, ISO 26262; Il sistema prodotto deve essere un modello Open Source e avere un alto livello di qualit; Collaborazione tra industrie, universit e istituti di ricerca.
Figura 3.7: Ciclo di vita di un progetto TOPCASED
Il ciclo di vita di un progetto TOPCASED contiene le fasi necessarie alla gestione e allimplementazione degli strumenti. Quindi il Topcased Quality Process partendo dalla visuale dinsieme del progetto (Figura 15), guida lo sviluppatore attraverso tutte le fasi del progetto.
Figura 3.8: TOPCASED Quality Process - Fase iniziale
Definendo fase per fase, quali sono i processi da attuare, le attivit da svolgere, i documenti da produrre, le figure professionali richieste.
Figura 3.9: L'attivit della scrittura dei Plan
Fino ad arrivare ai documenti finali, completi di descrizioni, propriet e i team da impiegare per il loro sviluppo.
Figura 3.10: TopQuality - Software Development Plan
Capitolo 4 Lo sviluppo software conforme allo standard DO-178B
Un analisi approfondita di TOPCASED Qualiy Process ha evidenziato delle imperfezioni circa lo sviluppo di sistemi conformi alle direttive dello standard RTCA DO-178B. Infatti, in realt vi sono differenze tra i documenti prodotti da TOPCASED e quelli invece richieste dallo standard. Differenze che si riscontrano nella nomenclatura e nella tipologia dei documenti stessi, ma soprattutto nei cicli di sviluppo del software. Mentre TOPCASED vincolato ad un modello di sviluppo a V, lo standard DO-178B non prescrive lutilizzo di un preciso modello di sviluppo ma descrive processi separati che comprendono pi cicli di vita e la loro interazione. La sequenza di processi da impiegare dipende dalla particolare istanza di progetto e dalle sue caratteristiche; parti diverse dello stesso progetto possono prevedere cicli di vita diversi.
4.1 Sviluppo di un nuovo plug-in di TOPCASED Quality Process

Questo lavoro di tesi incentrato sulla realizzazione di un nuovo plug-in del TOPCASED Quality Process dedicato proprio allo sviluppo di sistemi safety-critical soddisfacenti le direttive del DO178B. In particolare, sviluppato per rendere il software certificabile al livello D, cio il livello per software i cui malfunzionamenti, mostrati dal System Safety Assesement Process, appartengono alla categoria Minor.
4.1.1 Design
Questo strumento si occupa solo della sezione riguardante il ciclo di vita; lidea quella di creare un percorso parallelo a quello gi esistente mantenendone per intatta la struttura e la forma. E strutturato fondamentalmente su due rami, uno per la certificazione di un software di nuova produzione e un altro per la certificazione di un software gi esistente (Previously Developed Software PSD). Questi due processi hanno separati cicli di vita, ognuno con diverse fasi ed attivit, ma conducono entrambi alla attivazione degli stessi processi e quindi alla generazione degli stessi documenti, cos come prescrive il DO-178B.
Figura 4.1: I tre cicli di vita del software disponibili
E strutturato in 340 pagine HTML opportunamente collegate tra loro che sono organizzate logicamente con una struttura ad albero che presenta una radice, la pagina iniziale, e quattro livelli, uno per le fasi, uno per i processi, uno per le attivit e uno per i prodotti. Pi pagine, concettualmente consecutive, possono per trovarsi allo stesso livello.
Figura 4.2: Livelli logici delle pagine
Inoltre sono concettualmente raggruppate in insiemi di quattro pagine ognuno, in quanto ogni sezione della guida formata da quattro componenti: Description, Work Breakdown Structure, Team Allocation e Work Product Usage.
4.1.2 Struttura delle pagine

Le quattro pagine relative ad uno stesso gruppo hanno una breve intestazione comune, ma sono strutturalmente differenti e vengono, di seguito, esaminate nel dettaglio. La pagina Description che appunto la descrizione di ci che si sta visualizzando, incluse le propriet e le relazioni con altre fasi del processo di sviluppo. La pagina visualizzata nella seguente figura, mostra come questa divisa in sezioni. Una prima sezione, Relationships, che indica il contesto e con quali altri elementi della struttura, questa entit ( phase, processo, attivit, documento) collegata.
Vi quindi una sezione, Description, puramente descrittiva; e infine la sezione, Properties, che mette in evidenza le propriet dellentit che si sta esaminando.
Figura 4.3: Pagina Description del DO-178B per un nuovo software
La pagina Work Breakdown Structure, rappresenta la pagina principale delle quattro relative alla stessa entit, quella che viene visualizzata per default ed composta, come mostrato nella figura successiva, da due sezioni. Una superiore, la Workflow, che mostra le informazioni sotto un aspetto grafico, dove semplice visualizzare il flusso di lavoro. Una inferiore, la Work Brekdown, che mostra, sottoforma di menu a cascata, tutte le fasi, i processi, le attivit relative allentit in esame.
Figura 4.4: Pagina Work Breakdown Structure del DO-178B per un nuovo software
Estendendo tutti i menu della Work Breakdown si ha quindi una veduta dinsieme e completa di tutto il percorso da seguire nello sviluppo del software. I colori blu e arancio che si notano in figura (Figura 22), stanno ad indicare quali voci, appartengono o meno al livello software D dello standard DO-178B per il quale questo lavoro stato sviluppato. Infatti i link in blu, che rappresentano ci che riguarda il livello software D, conducono alle pagine relative, mentre quelli in arancio non conducono in nessuna altra pagina.
Figura 4.5: Work Breakdown del DO-178B per un nuovo software
Visualizzando invece la pagina del Team Allocation si ricevono informazioni riguardanti le figure professionali coinvolte nellattivit specifica con relativi collegamenti alle pagine descrittive di questi.
Figura 4.6: Pagina Team Allocation del DO-178B per un nuovo software
Infine nella pagina Work Product Usage sono presentati tutti i prodotti, documenti e software, che vengono generati e/o utilizzati durante le varie fasi dello sviluppo del software.
Figura 4.7: Pagina Work Product Usage del DO-178B per un nuovo software
Di diversa struttura, invece, sono le pagine relative ai documenti prodotti e alle figure professionali coinvolte nello sviluppo. Le pagine relative ai vari documenti presentano unintestazione nella parte alta e due sottostanti sezioni. La prima, la Relationship, in cui si mettono in evidenza i rapporti del documento che si sta visualizzando con le altre entit del processo, vengono infatti mostrate le relazioni con i vari team di sviluppo che gestiscono o assistono alla stesura del documento ( sottosezione Roles). Le relazioni tra il documento e i processi dai quali riceve gli input e quindi viene prodotto (sottosezione Inputs). Un ultima sotto-sezione della Relationship, la Outputs, da invece una descrizione pi completa del documento. La seconda sezione invece la Properties che
descrive appunto le propriet del documento. In figura mostrata la pagina del PSAC Plan for Software Aspect of Certification.
Figura 4.8: Pagina del PSAC
Quelle invece relative ai team di sviluppo presentano unintestazione superiore e la descrizione del team stesso e due sottosezioni. La Relationship e la Main Description, la prima per la descrizione delle relazioni che il team ha con altre entit o parti del progetto e la seconda che offre una descrizione pi dettagliata del team visualizzato.
Figura 4.9: Pagina del DER
4.2 Processo di certificazione di un nuovo software

Questo paragrafo mostra come il plug-in di TopQuality creato fornisce le indicazioni per lo sviluppo di un processo di certificazione di un nuovo software, mostrando tutte le fasi da percorrere e fornendo per ciascuna di esse le direttive per le attivit da svolgere. Concludendo, naturalmente, il processo con la stesura dei documenti necessari per la certificazione. Sar mostrato lo sviluppo generale e successivamente sar sviluppato un processo per intero. Il ciclo di vita da considerare quello mostrato nella seguente figura:
Figura 4.10: Ciclo di vita per software di nuova produzione
In cui possibile distinguere le varie fasi: Planning phase Development phase Verification phase Software Quality Assurance Configuration Management
Ricevuti gli input necessari dal SystemDevelopment e dal Safety Assesement, cos come regolati dagli standard SAE International ARP4761 e ARP 4754:
Figura 8: Gli standard ARP della SAE International
Le varie fasi del processo si susseguono, anche in maniera retroattiva, per giungere alla realizzazione del prodotto finale conforme al DO-178B. La fase di Planning provvede alla definizione delle specifiche del progetto, attraverso lattuazione del Software Planning Process. Porta quindi alla formulazione dei vari piani di sviluppo ( PSAC, SDP, SVP, SQA) che dirigeranno le attivit di tutti gli altri processi. La fase di Development , invece, costituita da un insieme di sotto-fasi: Requirement Analysis: prevede lattivazione del Software Requirements Process e quindi attraverso le attivit da cui questo processo composto, guida lo sviluppatore nella scrittura del Software Requirements Data. Architectural Design: guida lo sviluppo del Software Design Process per definire il Design Description. Detailed Design: come la fase di Architectural Design attiva il Software Design Process e contribuisce, con attivit differenti, alla compilazione del Design Description.
Software Coding and Unit Test: lultima fase del processo di sviluppo (Development ) e realizza il Source Code e lExecutable Object Code attraverso il Software Coding Process e lIntegration Process.
La fase di Verification costituita anchessa da sotto-fasi: Integration and test: si occupa del processo di verifica, quindi, guida nellavanzamento del Software Verification Process che attraverso le attivit di revisione ed analisi da cui composto, produce il Software Verification Results. Acceptance test: la fase di test del sistema da realizzare, attiva il Software Testing Process, attraverso il quale si giunge alla stesura del Software Verification Results e del Software Verification Cases and Procedures.
La fase Software Quality Assurance avvia il Software Quality Assurance Process che occupandosi di garantire che i processi del ciclo di vita soddisfino gli obiettivi prefissati, guida nello sviluppo dei Software Quality Assurance Records.
La fase Configuration Management avvia il Software Configuration Management Process Software che gestendo i vari aspetti del software fornisce le direttive per la produzione dei seguenti documenti: Configuration Management Records, Software Configuration Index, Problem Reports, e il Software Life Cycle Environment Configuration Index.
4.2.1 Un caso duso, la fase Verification

Vengono ora mostrate nel dettaglio le pagine della fase Verification. Dallo schema generale (Figura 28), cio la radice, selezionando la Verification phase viene visualizzata la pagina seguente:
Figura 4.12: Verification phase
E una pagina di livello fase, e mostra la suddivisione nelle due sotto-fasi: Integration and test e Acceptance Test. Selezionando la prima di queste, si visualizza unulteriore pagina di livello fase, la Integration and Test phase, pagina che descrive tutte le propriet di questa fase e che mostra che il prossimo step lattuazione del Software Verification Process.
Figura 4.13: Integration and Test phase
Si giunge quindi in una pagina di livello attivit, le attivit del Software Verification Process.
Figura 4.14: Software Verification Process Activity
Questo processo prevede sei macro-attivit, ovvero le attivit di revisione e analisi dei requisiti, dellarchitettura del software, delle procedure e casi di prova, del Source Code e dei risultati dei processi.Selezionando la prima attivit visualizzata, Reviews and Analisys of the High-Level Requirements, si passa alla visualizzazione di unaltra pagina di livello attivit:
Figura 4.15: Review and Analysis of the High-Level Requirements
Queste sono le attivit effettive del processo, che portano alla visualizzazione della pagina:
Figura 4.16: Il documento prodotto dal Software Verification Process
Da questultima, si giunge, allultima pagina di questo percorso, ed quella di livello prodotto che permette di visualizzare le caratteristiche del documento da produrre, in questo caso il Software Verification Results:
Figura 4.17: Software Verification Results
Questo percorso ha mostrato come questo strumento guidi lo sviluppatore durante il suo lavoro, mostrandogli le varie fasi da percorrere, i relativi processi da realizzare, le attivit da svolgere e
come e quali documenti produrre per rendere il software sviluppato certificabile secondo le direttive del DO-178B.
4.3 Processo di certificazione per un Previously Developed Software

Lutilizzo di un software esistente prevede un analisi di questo, per stabilire quali siano le modifiche necessarie da apportare per renderlo certificabile secondo il DO-178B. Il ciclo di vita di questo processo diverso da quello visto per un software di nuova fattura ed mostrato nella seguente figura:
Figura 9: Ciclo di vita di un PDS
Le fasi presenti in questo schema sono: Planning phase Reverse Engineering phase Verification phase Release phase
Anche se le fasi di progetto presenti in questo caso, sono differenti dal caso visto per un software nuovo da produrre, importante evidenziare come questi due cicli differenti portino agli stessi risultati, ovvero alla produzione degli stessi documenti. Infatti: la fase di Planning, come gi visto, provvede alla definizione delle specifiche del progetto, attraverso lattuazione del Software Planning Process. Porta quindi alla formulazione dei vari piani di sviluppo ( PSAC, SDP, SVP, SQA) che dirigeranno le attivit di tutti gli altri processi. La fase di Reverse Engineering , invece, costituita da un insieme di sotto-fasi: Detailed Design: guida lo sviluppo del Software Design Process per definire il Design Description. Architectural Design: come la fase di Detailed Design attiva il Software Design Process e contribuisce, con attivit differenti, alla compilazione del Design Description. High-Level Requirements: prevede lattivazione del Software Requirements Process e quindi attraverso le attivit da cui questo processo composto, guida lo sviluppatore nella scrittura del Software Requirements Data.
La fase di Requirements Verification costituita anchessa da sotto-fasi: Requirements Verification & test: si occupa del processi di verifica e test, quindi, guida nellavanzamento del Software Verification Process e del Software Testing Process. Processi che attraverso le attivit di revisione, analisi e test da cui sono composti, producono il Software Verification Results e il Software Verification Cases and Procedures. Tool Qualification Plan: pi che una fase, la stesura di un piano, il Tool Qualification Plan appunto.
Ultima la fase di Release, che la fase conclusiva dove vengono perfezionati tutti i documenti. Infatti, dato che la fase di documentazione dei piani viene posta allinizio, verosimilmente, tali piani verranno modificati fase dopo fase e poi solo alla fine perfezionati. Nella release phase si trovano tutti i documenti da dare alla certification authority.
Conclusioni e sviluppi futuri

Il lavoro di tesi ha avuto, come obiettivo, la creazione di uno strumento che fornisca le linee guida, agli sviluppatori, per la produzione di software per sistemi safety-critical che sia certificabile secondo le direttive dello standard RTCA DO-178B Software Considerations in Airborne Systems and Equipment Certification.
Lo studio di questa tesi fornisce un contributo allattivit di ricerca dellazienda MBDA ITALIA SPA per rendere certificabile il sistema operativo Finmeccanica Linux ( FNM Linux ) per rispondere ai bisogni delle aziende Finmeccanica (HRT, Distribution customization, Safety, Security...). MBDA ha poi contribuito con la positiva valutazione del lavoro svolto.
Nel primo capitolo stato presentato lo scenario applicativo, ovvero i sistemi safety-critical. E stato analizzato il concetto di Dependability, i suoi attributi, gli impedimenti ad essa ed i mezzi per garantirla. Tra gli attributi particolare interesse stato posto sulla safety e sulle attivit ad essa relative: System Safety Engineering, Safety Risk Management, Software Safety Engineering.
Nel secondo capitolo stato descritto lo standard DO-178B e presentato il ruolo fondamentale del DER. Sono poi stati sviluppati il ciclo di vita dello standard ed i processi ad esso relativo, giungendo alla descrizione dei documenti prodotti.
Nel terzo capitolo stato presentato il progetto TOPCASED Toolkit in OPen source for Critical Applications & SystEms Development, e le esigenze della Airbus che hanno portato alla sua realizzazione. E stato quindi analizzato un suo sottoprocesso, ovvero il TOPCASED Quality Process.
Il quarto capitolo descrive il nuovo plug-in creato per TOPCASED Quality Process che permette di avere linee guida nello sviluppo di software certificabile secondo le norme imposte dal DO-178B per il livello software D. Sono state presentate le esigenze che hanno portato al suo sviluppo, le varie fasi di progettazione e la descrizione di come questo viene utilizzato nello sviluppo del processo di certificazione del software sia di nuova fattura, sia precedentemente realizzato e quindi da analizzare e modificare opportunamente.
Il plug-in sviluppato, come detto in precedenza, stato sviluppato solo per la certificabilit secondo il livello software D dello standard DO-178B. Quindi il primo sviluppo da poter attuare proprio quello di renderlo un prodotto completo dal punto di vista della certificabilit, che riguardi cio tutti il livelli software previsti dal DO-178B. E successivamente si potrebbe estenderlo a tutte le parti del TOPCASED Quality Process, la Roles, la Disciplines, e la Work Product.
Una volta sviluppato per intero il TOPCASED Quality Process, bisognerebbe integrarlo con TOPCASED, ovvero si dovrebbe far in modo che, ad esempio, la parte di analisi si agganci ai diagrammi UML, la parte di requisiti a tramway, la parte di design al SYS ML. Bisogna far in modo che TOPCASED sia un progetto Open Source per creare il necessario sistema di strumenti di sviluppo si un sistema safety-critical certificabile anche secondo il DO-178B.
Questo lavoro non fa altro che rimarcare la vastit delle problematiche legate allo studio dei sistemi safety-critical e dei risvolti pratici ad esse correlate.
Bibliografia
[1]
IFIP WG10.4 on Dependable Computing and Fault Tolerance, www.dependability.org
[2] K. Fowler, Mission Critical and Safety Critical Development, IEEE Instrumentation & Measurement Magazine [3] A. Avizienis, J.C. Laprie, B. Randell, Fundamental Concepts of Dependability, LAAS Technical Report No. 01-145, Apr. 2001 [4] J.C. Laprie, Dependability: Basic Concepts and Terminology, Dependable Computing and Fault-Tolerance, Springer-Verlag, Vienna, Austria, 1992 [5] J. Arlat, K. Kanoun, J.C. Laprie, Dependability Modeling and Evaluation of Software Fault-Tolerant System, IEEE TC, Vol. C-39, 1990 [6] RTCA SC-167 / EUROCAE WG-12: RTCA/DO-178B - Software Considerations in Airborne Systems And Equipment Certification, RTCA Inc. (1992). [7] Airlines Electronic Engineering Commitee, ARINC Specification 653-1 - Avionics Application Software Standard Interface, ARINC (2006) [8] UK Ministry of Defence: Defence Standard 00-56 Issue 2: Safety Management Requirements for Defence Systems, 1996. [9] European Organisation for the Safety of ANS, Safety Assessment Methodology, Eurocontrol, 2004 [10] W.R. Dunn, Designing Safety-Critical Computer Systems, IEEE Computer Society, 2003 [11] Joint Services Software Safety Commitee: Software System Safety Handbook, (1999) [12] Maurizio Catino: Da Chernobyl a Linate. Incidenti tecnologici o errori amministrativi?, Carocci (1999)
[13] Chip Downing: A Primer on Software Cerfication, (2002) [14] John A McDermid, David J Pumfrey: Assessing the Safety of Integrity Level Partitioning in Software, Department of Computer Science, University of York, UK. [15] TOPCASED, http://topcased.gforce.enseeiht.fr [16] TOPCASED Open Source Workshop, www.laas.fr/SPIP/spip-topcased/ [17] TOPCASED documents, www.topcased.org/index.php?id_project_pere=52&Itemid=59 [18] TOPCASED Modelling Tools, http://gforce.enseeiht.fr/frs/?group_id=7

Tesi Giuseppe Trincia

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tesi Giuseppe Trincia

Caricato da

Copyright:

Formati disponibili

Facolt di Ingegneria Corso di Studi in Ingegneria Informatica

A tutti coloro che hanno sempre creduto in me: ... io.forse!!

2.7 2.7.1 2.7.1.1 2.7.2 2.7.3 2.7.4 2.8

Conclusioni e sviluppi futuri Bibliografia

Elenco delle figure

Elenco delle tabelle

Capitolo 1 I sistemi safety-critical

Figura 1.1: Alcuni scenari critici

Figura 1.2 Dependability: attributi, impedimenti, mezzi

1.2.1 Attributi della dependability

1.2.2 Gli impedimenti alla dependability

Figura 1.3: Propagazione delle minacce

1.2.2.1 Gli impedimenti alla dependability: I guasti

Figura 1.4: Classificazione dei guasti

1.2.2.2 Gli impedimenti alla dependability: Gli errori

1.2.2.3 Gli impedimenti alla dependability: I fallimenti

Figura 1.5: Classificazione dei failures

1.2.3 Mezzi per la dependability

1.3.1 System Safety Engineering

1.3.2 Safety Risk Management

Figura 1.6: Il rischio

Tabella 1: Classificazione della gravit dei rischi

Tabella 1.2: Classificazione delle probabilit di occorrenza dei rischi

Tabella 1.3: La matrice HRI

Tabella 1.4: Classi di rischio

1.3.3 Software Safety Engineering

1.4 Standard industriali per la Safety

1.4.1 Standard Militari

1.4.3 SAE Serie ARP

1.4.4 NASA Serie NSS

1.4.5 Standard Commerciali

IEEE - Serie IEEE

IEC - Serie IEC

Capitolo 2 Analisi e descrizione dello standard RTCA DO-178B

Figura 2.1: Overview del DO-178B

2.1 Aspetti del sistema relativi allo sviluppo del software

2.3 Condizioni derrore e livelli software

2.4 Ciclo di vita del software

2.5 Software Planning Process

2.6 Software Development Processes

2.6.1 Software Requirements Process

2.6.2 Software Design Process

2.6.3 Software Coding Process

2.6.4 Integration Process

2.7 Integral Processes

2.7.1 Software Verification Process

2.7.1.1 Software Testing Process

Figura 2.3: Software Testing Process

I requisiti di copertura del codice in base al livello di criticit sono i seguenti:

Tabella 2.1: Requisiti di Copertura

2.7.2 Software Configuration Management Process

2.7.3 Software Quality Assurance Process

2.7.4 Certification Liaison Process

2.8 Documenti e software generati

Software Configuration Index: individua la configurazione del software prodotto.

Capitolo 3 Analisi di un progetto Open Source: TOPCASED

Figura 3.1: Cabina di pilotaggio dell'Airbus A380

Figura 3.2: TOPCASED Logo

Figura 3.3: TOPCASED partners

3.2 TOPCASED: il progetto

Figura 3.4: TOPCASED, sviluppo model driven

Figura 3.5: Modello di sviluppo a "V"

3.3 TOPCASED Quality Process

Figura 7: TOPCASED Quality Process