Analisi e studio di un processo di sviluppo di sistemi safety-critical conformi allo standard RTCA DO-178B

Transcript

1 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 Relatore Ch.mo prof. Domenico Cotroneo Correlatore aziendale Ing. Christian Di Biagio candidato Giuseppe Trincia matr. 41/3804

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

3 Indice Introduzione 8 Capitolo 1. I sistemi safety-critical 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 34 Capitolo 2. Analisi e descrizione dello standard RTCA DO-178B Aspetti del sistema relativi allo sviluppo del software DER Condizioni d errore 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 48

4 2.7 Integral Process Software Verification Process Software Testing Process Software Configuration Management Process Software Quality Assurance Process Certification Liaison Process Documenti e software generati 56 Capitolo 3. Analisi di un progetto Open Source: TOPCASED TOPCASED TOPCASED: il progetto TOPCASED Quality Process 63 Capitolo 4. Lo sviluppo software conforme allo standard DO-178B Sviluppo di un nuovo plug-in di TOPCASED Quality Process Design Struttura delle pagine Processo di certificazione di un nuovo software Un caso d uso: la fase Verification Processo di certificazione di un Previously Developed Software 81 Conclusioni e sviluppi futuri 83 Bibliografia 85

5 Elenco delle figure Figura 1.1: Alcuni scenari critici 11 Figura 1.2: Dependability: attributi, impedimenti, mezzi 13 Figura 1.3: Propagazione delle minacce 15 Figura 1.4: Classificazione dei guasti 17 Figura 1.5: Classificazione dei failures 19 Figura 1.6: Il rischio 23 Figura 2.1: Overview del DO-178B 38 Figura 2.2: Flusso di informazioni tra il sistema e i software life cycle processes 39 Figura 2.3: Software Testing Process 51 Figura 3.1: Cabina di pilotaggio dell Airbus A Figura 3.2:TOPCASED Logo 60 Figura 3.3: TOPCASED partners 61 Figura 3.4: TOPCASED, sviluppo model driven 62 Figura 3.5: Modello di sviluppo a V 62 Figura 3.6: TOPCASED Quality Process 64 Figura 3.7: Ciclo di vita di un progetto TOPCASED 64 Figura 3.8: TOPCASED Quality Process Fase iniziale 65 Figura 3.9: L attività della scrittura dei Plan 65 Figura 3.10: TOPCASED Quality Process Software Development Plan 66 Figura 4.1: I tre cicli di vita del software disponibili 68 Figura 4.2: Livelli logici delle pagine 69 Figura 4.3: Pagina Description del DO-178B per un nuovo software 70

6 Figura 4.4: Pagina Work Breakdown Structure del DO-178B per un nuovo software 71 Figura 4.5: Work Breakdown Element del DO-178B per un nuovo software 72 Figura 4.6: Pagina Team Allocation del DO-178B per un nuovo software 73 Figura 4.7: Pagina Work Product Usage del DO-178B per un nuovo software 73 Figura 4.8: Pagina del PSAC 74 Figura 4.9:Pagina del DER 74 Figura 4.10: Ciclo di vita per software di nuova produzione 75 Figura 4.11:Gli standard ARP della SAE International 76 Figura 4.12: Verification phase 78 Figura 4.13: Integration and Test phase 78 Figura 4.14: Software Verification Process Activity 79 Figura 4.15: Review and Analysis of the High-Level Requirements 79 Figura 4.16: Il documento prodotto dal Software Verification Process 80 Figura 4.17: Software Verification Results 80 Figura 4.18: Ciclo di vita di un PDS 81

7 Elenco delle tabelle Tabella 1.1: Classificazione della gravità dei rischi 24 Tabella 1.2: Classificazione delle probabilità di occorrenza dei rischi 25 Tabella 1.3: La matrice HRI 25 Tabella 1.4: Classi di rischio 26 Tabella 2.1: Requisiti di copertura 53

8 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 all utilizzo 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 l acquisto da parte di aziende di sviluppo interessate ad utilizzarli nei loro progetti. L utilizzo 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. L interessamento ai vantaggi offerti dall utilizzo di componenti COTS sta aumentando anche da parte delle aziende che producono sistemi critici. Nell ambito 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 l affidabilità. Infatti, devono essere valutate tutte le condizioni

9 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à dell azienda MBDA ITALIA SPA di rendere certificabile il sistema operativo Finmeccanica Linux ( FNM Linux ). L intenzione è 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 l obiettivo 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 dell IT, e dell high 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 dall agenzia RTCA (Radio Technical Commission for Aeronautics) per soddisfare l esigenza dell industria 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 DO- 178B. E stato, quindi, realizzato un applicazione 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

10 rappresenta un azienda 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 dall esistenza 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 l importanza di una gestione della configurazione che riguarda soprattutto la sua efficienza.

11 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 sull ambiente 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 l uomo o per l ambiente. La sicurezza o meno per le persone derivata dall uso di un certo sistema tecnologico è strettamente collegata al concetto di rischio, dal momento che nessun evento nell universo 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.

12 Il Risk Management è un attività 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. L esito 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à, nell individuazione delle aree e delle fonti di rischio e infine nell analisi 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 l utente 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 all ambiente 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. L obiettivo 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.

13 Nell informatica, 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; l utente, 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

14 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 d uso, 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 l ambiente, 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.

15 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 dell hardware 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 è un indicazione 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: l attivazione 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 l interfaccia del sistema. Figura 1.3: Propagazione delle minacce

16 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. L origine dei guasti porta a distinguere tra: le cause fenomenologiche che implicano guasti fisici ( phisical faults), che sono dovuti a fenomeni fisici avversi; e guasti causati dall uomo ( human-made faults ), che sono dovuti all imperfezione umana. I confini del sistema che implicano guasti interni ( internal faults ), che sono parti dello stato del sistema che, quando richiamate dall attività di elaborazione, produrranno un errore; e guasti esterni ( external faults ), che derivano dall interferenza dell ambiente fisico nel sistema (perturbazioni elettromagnetiche, radiazioni, temperatura, vibrazioni, ) o dall interazione con l ambiente 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 l uso 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 dall uomo; questi guasti possono essere sia interni che esterni: per quanto riguarda quelli interni, un esempio è l inserimento 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 un intrusione 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.

17 Considerando la persistenza temporale, i guasti esterni temporali che originano dall ambiente 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 Gli impedimenti alla dependability: Gli errori Un errore è il responsabile dell evoluzione 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. Dall attività del sistema, cioè un errore può essere compensato prima di provocare un danno. Dalla definizione di un fallimento dal punto di vista dell utente, ciò che è un fallimento per un dato utente può essere una sopportabile noia per un altro. Un errore può essere latente o rilevato, è latente ( latent ) quando non è stato riconosciuto 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.

18 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 dell utente del sistema e conseguenze sull ambiente. L esperienza 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 l attività 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

19 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 sull ambiente 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 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

20 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 l utilizzo di componenti altamente affidabili che, pertanto, comportano un incremento dei costi. Sono tecniche relative alla fase di definizione delle specifiche, progettazione e codifica. 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 all individuazione degli errori e alla rimozione dei guasti durante lo sviluppo o in fase operativa; per ridurre l occorrenza (numero, gravità) dei guasti. Fault forecasting: si pone come obiettivo di stimare il numero, la frequenza di incidenza, presente e futura, e le conseguenze dei guasti. Può essere deterministico ( studio degli 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.

21 1.3 Safety Questo lavoro di tesi è incentrato intorno ad un particolare attributo della dependability: la safety. La safety può essere definita come l aspettativa che un certo sistema non comporti, in certe specifiche condizioni, rischi per la vita dell uomo o dell ambiente. Il punto di partenza per caratterizzare la safety di un sistema, è costituito dal concetto di mishap o incidente, definito come uno o più eventi non previsti che possono causare danni fisici a persone o compromettere l ambiente 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 System Safety Engineering La System Safety Engineering deriva dall ingegneria e dall analisi 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, l impulso 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

22 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 l esplosione 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: l Ingegnere/Manager della Safety. Questi è responsabile dell identificazione, del tracciamento, dell eliminazione e/o limitazione dei rischi di malfunzionamento e avarie del sistema che possono generarsi durante la progettazione, lo sviluppo, il testing e la produzione dell hardware 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 dell SSP 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 l uso 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 all interno del sistema.

23 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 dall impiego 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 l isolamento e la separazione fisica. Prevedere note e avvisi di sicurezza in nelle istruzioni di montaggio, impiego e riparazione e sui componenti potenzialmente pericolosi. Minimizzare l impatto di un guasto per le persone e gli altri dispositivi. Progettare dei sistemi di controllo, eventualmente anche software, per evitare quanto più possibile l insorgere 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à 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

24 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 dell impiego del sistema. Questa attività assume un ruolo importantissimo in quanto è la base, indispensabile, per l identificazione e la definizione dei requisiti di safety ai vari livelli (hardware, software). La combinazione della gravità dell evento e della sua probabilità di occorrenza determina l indice della corrispondente classe di rischio, ovvero una misura che indica il rischio associato all evento 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:

25 Tabella 1.2: Classificazione delle probabilità di occorrenza dei rischi L attività di valutazione dei rischi comporta la determinazione dell accettabilità/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 dell hazard. Tabella 1.3: La matrice HRI

26 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à all interno del team, individuando per ciascun livello l autorità organizzativa che dovrà occuparsi dei relativi hazard. lari servizi richiesti. È importante poter gestire l eliminazione e il controllo degli hazard secondo uno schema basato sulla priorità, in quanto il successo e l efficienza dell operazione dipende dalla capacità o meno di agire prima possibile durante la progettazione. Per questo motivo conviene intervenire durante la progettazione, cercando di eliminare l hazard o ridurne il rischio a livelli accettabili. Se l hazard 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. È

27 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 l individuazione, nell analisi iniziale, di una gerarchia di autorità ciascuna responsabile dell accettazione o meno dei rischi di un determinato livello e quindi gravità 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-STD- 882 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.

28 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. L implementazione, 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 è un altro dei fattori chiave per la pianificazione del processo. È necessario, partendo dall Hazard 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. Quest ultima 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 quest ultima fase può verificarsi la necessità di operare dei cambiamenti. Nei compiti dell attività 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 l analisi 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 l operato 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

29 team di safety, ovvero i suoi membri, risulti credibile. L esito 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 l acquisizione, 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 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,

30 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, l hardware, il sistema in generale e l interfaccia 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 all interno 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 l implementazione 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. L obiettivo è 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 Applicazione: Tutti i sistemi e progetti all interno 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 all interno 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à. L adozione 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.

31 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 all interno 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 all interno 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 RTCA La RTCA (Radio Technical Commission for Aeronautics) è il punto di riferimento tecnico per l industria aeronautica civile in tutto il mondo.

32 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 l avionica. Tale documento, nell ambito 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 dall utente; 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à.

33 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 l intero processo di sviluppo. Lo standard è affiancato dall ARP4761 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 l avionica. 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 dall entità 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 l architettura: Prevede ridondanza, cioè più implementazioni della stessa funzione. Prevede partizionamento, isola cioè gli effetti di un malfunzionamento. Prevede il controllo automatico e attivo dell elemento. 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 l SSA per produrre e valutare i tassi di malfunzionamento funzionale. L analisi deve verificare che i requisiti imposti dal livello di DAL siano stati soddisfatti. Per conseguire questo obiettivo, l SSA suggerisce di operare l Analisi delle Modalità di Malfunzionamento e dei loro effetti e l Analisi dell Albero dei Malfunzionamenti 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 (NASA Safety Standard )

34 NSS Nome completo: NASA Safety Standard (NSS) , 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 l intero 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 dall NSS 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 nell attenuare il danno in caso di incidente 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.

35 IEEE - Serie IEEE L IEEE ha pubblicato gli standard IEEE STD 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 all interno del processo di sviluppo. L applicazione 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 L EIA (Electronic Industries Association) ha pubblicato il Safety Engineering Bulletin 6B, System Safety Engineering in Software Development, nel 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 l analisi 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 L IEC (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). L Overall Safety Life Cycle è introdotto fin dall inizio ed è la colla che tiene unita i criteri che vengono man mano presentati.

36 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, sull uso 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.

37 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 dall agenzia RTCA (Radio Technical Commission for Aeronautics) per soddisfare l esigenza dell industria 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à.

38 Figura 2.1: Overview del DO-178B Analisi e studio di un processo di sviluppo di sistemi

39 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 Un attività 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, un analisi del design del sistema permette di definire requisiti relativi alla safety che specificano il livello di immunità ai malfunzionamenti desiderato e come il sistema deve rispondere nell eventualità che questi si verifichino. Questi requisiti vengono definiti sia per l hardware che per il software al fine di evitare o limitare gli effetti degli errori. Queste decisioni vengono prese durante le fasi di progettazione dell hardware 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 l impatto del design e dell implementazione del software sulla sicurezza del sistema, basandosi sulle informazioni fornite dai Software Life Cycle Processes. Queste informazioni

40 includono i margini in cui è possibile contenere gli errori, i requisiti software, l architettura del software e le fonti d errore che possono essere state individuate o eliminate attraverso l architettura software o mediante l uso 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, all intero ciclo di vita di sviluppo del software devono essere forniti: La descrizione del sistema e dell hardware. I requisiti di sistema allocati al software: Funzionali, di Performance e di Safety. Il livello di criticità del software e la documentazione sull analisi 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 dall inizio 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 dell intero processo di certificazione. Negli Stati Uniti la FAA (Federal Aviation Administration), l autorità che regolamenta l industria 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, l ente che si occupa degli aspetti di conformità e safety in campo aeronautico è l EASA (European Aviation Safety Agency). In Italia l ENAC (Ente Nazionale per l Aviazione Civile), membro dell EASA, si occupa di safety e sicurezza in ambito nazionale. Nonostante i DER abbiano l autorità 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

41 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 , 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 l esperienza sufficiente per ridurre il rischio di agire male. 2.3 Condizioni d errore e livelli software La classificazione delle condizioni d errore 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 l atterraggio, con gravi e fatali lesioni per le persone a bordo. b. Hazardous/Severe-Major: per i malfunzionamenti che ridurrebbero la capacità dell aeromobile 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à dell aeromobile 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.

42 o Significativo aumento del carico di lavoro per il personale di bordo che ne pregiudichi l efficienza. 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 dell aeromobile 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.

43 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 d errore 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 all hardware, al software o a loro combinazioni. Lo standard DO-178B fornisce linee guida anche per le modifiche software che possono essere apportate dall utente 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 l utilizzo 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, all interno 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

44 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.

45 Scelta dell ambiente 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 l avanzamento del progetto. I piani di sviluppo prodotti dal Software Planning Process sono: Plan for Software Aspect of Certification (PSAC): definisce e descrive all autorità 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 l ambiente 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 l analisi dei requisiti e dell architettura 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

46 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 all intero 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 sull architettura 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 Software Requirements Process Durante il Software Requirement Process vengono analizzati i requisiti e l architettura di sistema per generare i requisiti di alto livello. Questi includono requisiti funzionali, di performance, d interfacciamento 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.

47 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, l interfaccia hardware e l architettura 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 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 l architettura 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 l architettura 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. L output prodotto dal Software Design Process è il Design Description che include appunto l architettura 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.

48 2.6.3 Software Coding Process Nel Software Coding Process viene sviluppato Source Code partendo dall architettura del software e dai requisiti di basso livello. L obiettivo 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 l architettura 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 l architettura 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 l Object 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 Integration Process Le apparecchiature d utente (target computer), il Source Code e l Object Code prodotti dal Software Coding Process, il linking e il caricamento dei dati vengono usati nell Integration Process per sviluppare il sistema finito ( Integrated airborne system or equipment ). L obiettivo dell Integration Process è quello di caricare l Executable Object Code nelle apparecchiature d utente per l integrazione hardware/software. Gli input dell Integration Process sono l architettura del software dal Software Design Process, e il Source Code e l Object Code dal Software Coding Process. Gli input insufficienti o incorretti rilevati durante l Integral 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.

49 2.7 Integral Processes Gli Integral Processes garantiscono la correttezza, il controllo e l affidabilità 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 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 l assenza 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 nell architettura del software e che entrambi li soddisfino. L architettura del software e i requisiti di basso livello siano stati tradotti nel Source Code e che questo li soddisfi. L Executable Object Code soddisfi i requisiti software.

50 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, dell architettura del software e del Sourcs Code. Lo sviluppo dei casi di test può fornire ulteriori valutazioni sulla consistenza e la completezza dei requisiti. L esecuzione 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, l architettura del software, i dati sulla tracciabilità, il Source Code, l Executable 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. L analisi può esaminare in dettaglio le funzionalità, le prestazioni, la tracciabilità e la safety di un componente software, e il suo rapporto con altri componenti all interno 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 dell architettura di sistema: conformità ai requisiti di alto livello, consistenza, compatibilità col sistema, verificabilità, conformità agli standard, integrità del partizionamento.

51 Analisi e revisione del codice sorgente: conformità ai requisiti di basso livello e all architettura software, verificabilità, conformità agli standard, tracciabilità, accuratezza e consistenza. Analisi e revisione dell output 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 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

52 In figura si possono notare i tre tipi di test: Hardware/Software integration testing: per verificare il corretto funzionamento del software nelle apparecchiature d utente. Software integration testing: per verificare le interrelazioni tra i requisiti software e i componenti; e per verificare l implementazione dei requisiti e componenti software all interno dell architettura del software. Low-level testing: per verificare l implementazione 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 sull input 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 l abilità 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 all interno 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 l architettura 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:

53 Coverage Analysis basata sui requisiti: Verifica che il testing basato sui requisiti testi bene quanto l iplementazione 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 dell analisi del codice attraverso i casi di test.l entità 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 all interno 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 all interno 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 Copertura Requisiti di copertura Livello A MCDC Livello B + 100% Modified Condition Decision Coverage Livello B DC Livello C + 100% Decision Coverage Livello C SC Livello D + 100% Statement (Istruzione) Coverage Livello D 100% Copertura dei Requisiti Livello E Tabella 2.1: Requisiti di Copertura

54 L analisi 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 l eventualità Software Configuration Management Process Il Software Configuration Management Process si occupa di definire e monitorare tutta l infrastruttura 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 l Executable 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.

55 Il Software Configuration Management Process non si ferma quando il prodotto software viene certificato secondo lo standard dall autorità certificatrice ma continua per tutta la vita del sistema a bordo di aerei o equipaggiamenti 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 Certification Liaison Process Il Certification Liaison Process stabilisce la comunicazione e la comprensione tra il team di sviluppo e l autorità certificatrice durante tutto il ciclo di vita per curare il processo di certificazione. Il flusso di eventi che si susseguono, generalmente, è: 1. L impresa è responsabile del progetto, presenta il Plan for Software Aspects of Certification ed altri dati richiesti all autorità certificatrice. 2. L autorità certificatrice esamina ed eventualmente corregge il Plan for Software Aspects of Certification. 3. L autorità certificatrice approva il piano e il progetto entra nella fase di sviluppo. 4. L impresa, durante lo sviluppo, risolve i problemi riscontrati dall autorità certificatrice durante la revisione costante del materiale prodotto.

56 5. L impresa fornisce all ente 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. L ente 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 dall autorità 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.

57 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 dell architettura 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 l Object Code dal Source Code, il linkaggio e il caricamento dei dati. Dovrebbe, inoltre, includere anche l identificazione 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 dall unità centrale di elaborazione del computer dell utente ed è, pertanto, il software che è caricato nell hardware 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.

58 Software Life Cycle Environment Configuration Index: individua la configurazione dell ambiente del ciclo di vita del software. Questo indice è scritto per la riproduzione dell ambiente dell hardware 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.

59 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

60 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, è un eternità 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 è l acronimo 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

61 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. Anche altre aziende hanno manifestato il loro interesse a diventare partner del progetto. 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 (Ingénierie des Systèmes embarqués aéronautiques, 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.

62 3.2 TOPCASED: il progetto TOPCASED consiste di vari sotto-progetti ospitati sui server dell università francese ENSEEIHT (Ecole Nationale Supérieure d'electrotechnique, d'electronique, d'informatique, d'hydraulique et des Télécommunications). 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 l intero 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"

63 Tra gli strumenti, particolare rilievo, va dato agli editor grafici per diversi linguaggi di modellazione: l'object Management Group s Unified Modeling Language (UML), l Ecore metalinguaggio di modellazione per Eclipse, il SysML Sistems Modeling Language e l AADL (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. L utilizzo 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 l hardware e del sistema intero. 3.3 TOPCASED Quality Process TOPCASED Quality Process è un processo di TOPCASED che copre l intero 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.

64 Figura 7: TOPCASED Quality Process In questa prospettiva si possono definire alcuni obiettivi che con l utilizzo 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

65 Il ciclo di vita di un progetto TOPCASED contiene le fasi necessarie alla gestione e all implementazione degli strumenti. Quindi il Topcased Quality Process partendo dalla visuale d insieme 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

66 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

67 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 l utilizzo 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 DO- 178B. 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.

68 4.1.1 Design Questo strumento si occupa solo della sezione riguardante il ciclo di vita; l idea è 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.

69 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 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.

70 Vi è quindi una sezione, Description, puramente descrittiva; e infine la sezione, Properties, che mette in evidenza le proprietà dell entità 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 all entità in esame.

71 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 d insieme 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.

72 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 nell attività specifica con relativi collegamenti alle pagine descrittive di questi.

73 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 un intestazione 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

74 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 un intestazione 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

75 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

76 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 l attuazione 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 l attivazione 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.

77 Software Coding and Unit Test: è l ultima fase del processo di sviluppo (Development ) e realizza il Source Code e l Executable Object Code attraverso il Software Coding Process e l Integration Process. La fase di Verification è costituita anch essa da sotto-fasi: Integration and test: si occupa del processo di verifica, quindi, guida nell avanzamento 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.

78 4.2.1 Un caso d uso, 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 un ulteriore 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 è l attuazione 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.

79 Figura 4.14: Software Verification Process Activity Questo processo prevede sei macro-attività, ovvero le attività di revisione e analisi dei requisiti, dell architettura 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 un altra pagina di livello attività: Figura 4.15: Review and Analysis of the High-Level Requirements

80 Queste sono le attività effettive del processo, che portano alla visualizzazione della pagina: Figura 4.16: Il documento prodotto dal Software Verification Process Da quest ultima, si giunge, all ultima 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