Software FMEA, tecniche e tools di...

Scuola di Scienze Matematiche, Fisiche e NaturaliCorso di Laurea in Informatica

Tesi di Laurea

Software FMEA: tecniche, tools di supporto esviluppi recenti

Software FMEA: techniques, supporting tools andrecent developments

Baldecchi Andrea

Relatore: Paolo LolliniCorrelatore: Leonardo Montecchi

Anno Accademico 2014/2015

Contents1 Failure modes and effect(s) analysis 5

1.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2 Scopo/Obbiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 Classificazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.4 Procedura e caratteristiche . . . . . . . . . . . . . . . . . . . . . . . . . 81.5 Guasto, errore e fallimento . . . . . . . . . . . . . . . . . . . . . . . . . 101.6 Applicazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.7 Aspetti temporali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.8 Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 Stato dell’arte 192.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2 Soluzioni ed approcci proposti . . . . . . . . . . . . . . . . . . . . . . . 192.3 Tabella riassuntiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Un recente approccio alla SFMEA 273.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2 Trasformazione del modello . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2.1 Input del processo di trasformazione . . . . . . . . . . . . . . . . 313.2.2 Algoritmo di trasformazione . . . . . . . . . . . . . . . . . . . . 33

3.3 Esecuzione dei modelli e tracce . . . . . . . . . . . . . . . . . . . . . . . 363.4 Iniezione Guasti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.4.1 Attività nella fase di Setup . . . . . . . . . . . . . . . . . . . . . 403.4.2 Attività nella fase di Run-time . . . . . . . . . . . . . . . . . . . 42

4 Esempio 434.1 Target dell’esempio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2 Trasformazione dei modelli . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2.1 Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2.2 Trasformazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2.3 Riscrittura delle operazioni . . . . . . . . . . . . . . . . . . . . . 534.2.4 Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.2.5 Versioni dei tools utilizzati . . . . . . . . . . . . . . . . . . . . . 55

4.3 Iniezione dei guasti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.3.1 Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.3.2 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . . 594.3.3 Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.4 Esecuzione dei modelli . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.4.1 Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.4.2 Procedura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.4.3 Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5 Conclusioni 65

1

CONTENTS 2

6 Bibliografia 69

Abstract

FMEA, acronimo di Failure Modes and Effects Analysis, è una tecnicad’analisi sviluppata dall’esercito statunitense nel 1949. Il suo obbiettivoè quello di determinare, in modo sistematico, in che modo i componentidel sistema possono fallire, individuando effetti e conseguenze. Originari-amente veniva utilizzata come tecnica di valutazione dell’affidabilità di sis-temi ed equipaggiamenti, per esempio fu adottata nel programma spazialeApollo con la quale si è asisistito al primo sbarco umano sulla luna. Nelcorso degli anni 60 l’applicazione di questa tecnica divenne sempre più fre-quente, seguendo di pari passo o quasi l’evoluzione tecnologica di queglianni. Fornisce quindi supporto al ciclo di produzione e sviluppo funzio-nando da linea guida, individuando e correggendo errori di progettazionequanto prima possibile. In questa tesi è stato effettuato un approfondimentosu questa tecnica di analisi. Dopo aver esaminato procedura, obbiettivi,classificazioni e caratteristiche della tecnica, si è approfondita la sua ap-plicazione a livello software. Si è effettuata quindi una disamina criticadegli approcci alla FMEA presenti in letteratura, ponendo particolare at-tenzione sugli aspetti di applicabilità e automazione. Si è inoltre evidenzi-ata la mancanza di un approccio d’esecuzione dell’analisi FMEA a livellosoftware semi-automatizzato ed integrabile in un apposito framework.La principale limitazione dell’analisi FMEA infatti risiede nella sua com-plessità: in genere la sua conduzione ha un costo elevato proporzionalealle dimensioni e alla complessità del sistema che viene analizzato. Con-siderando che tale analisi viene in buona parte effettuata manualmente,questo aspetto incide inevitabilmente sulla sua applicabilità. Per questomotivo è stato esaminato in modo approfondito un approccio in via disviluppo, che punta ad automatizzare la FMEA software. Questo approccioè attualmente oggetto di ricerca del Dipartimento di Matematica e Infor-matica dell’Università degli studi di Firenze e di altri gruppi vi collabo-rano. L’approccio in via di sviluppo ha come target d’analisi architetturesoftware component-based descritte in UML.

Si prevede di automatizzare questo tipo d’analisi trasformando il modellodescrittivo dell’architettura software in input in un modello eseguibile chene rappresenti il comportamento. Il modello eseguibile viene quindi sfrut-tato per simulare il comportamento del sistema. Iniettando i guasti inquesto particolare modello si prevede quindi di poter tracciare i gli effetti diquesti in modo automatico, diminuendo di conseguenza il costo dell’analisiintera.Dopo aver approfondito i passi che permettono di applicare questo approc-cio, si è quindi esaminato il livello di completezza e le limitazioni presentinel prototipo attualmente esistente. Si è cercato quindi di proporre plau-sibili estensioni, alternative e sviluppi futuri. L’applicazione di questo ap-proccio su una semplice architettura software è risultata molto utile ai finidi quest’attività, oltre che a facilitare la comprensione complessiva dellametodologia presentata.Riassumendo, i contributi principali di questa tesi consistono in:

• Approfondimento della tecnica FMEA, con particolare attenzione allaFMEA software.

• Analisi critica dello stato dell’arte su questa tecnica.

• Approfondimento di un approccio di ricerca che puntaall’automazione della FMEA software tramite modelli eseguibili.

• Analisi del prototipo esistente e individuazione di limitazioni e partiincomplete, tramite applicazione ad un semplice esempio.

La tesi è strutturata in cinque capitoli:

Il Capitolo 1 introduce la tecnica d’analisi FMEA descrivendone applica-bilità, procedure, classificazioni e caratteristiche principali. Il capitolo siconclude quindi con una contestualizzazione della analisi di tipo software.

Nel Capitolo 2 viene descritto lo stato dell’arte relativo alla FMEA, de-scrivendone storicamente l’evoluzione e confrontando i principali approcciper quanto riguarda la loro applicabilità e possibilità di automazione.

Il Capitolo 3 descrive ed illustra in dettaglio l’approccio studiato dalDipartimento di Informatica dell’Università degli studi di Firenze.

Nel Capitolo 4 viene descritto il prototipo esistente attraverso un semplicecase study, con cui inoltre si facilita la comprensione dell’approccio pre-sentato. Questa attività consente di evidenziare ciò che risulta sviluppatoin forma completa, parziale o solo ideale.

Per finire, nel Capitolo 5 si riassume lo stato d’avanzamento dell’attivitàdi ricerca in questo ambito mettendo in evidenza le parti mancanti ed ideeper sviluppi futuri.

1Failure modes and effect(s) analysis

Ogni sistema tecnologico impiegato dall’essere umano per soddisfare una propria neces-sità è inequivocabilmente soggetto a guasti. L’occorrenza di quest’ultimi può, in alcunicasi compromettere il servizio erogato dal sistema, con conseguenze più o meno impor-tanti sul contesto di funzionamento legato al sistema.Tuttavia la qualità del servizio erogatoda un determinato sistema tecnologico è legata ad un vasto numero di proprietà e concettiintrinsechi alla natura del sistema considerato. Proprio a causa della vastità di termini econcetti relativi ai sistemi tecnologici, nei primi anni 90 un team di lavoro dell’IFIP (Inter-national Federation for Informatio Processing) sottoscrisse un documento in cui venivanodefiniti con precisione gli aspetti, i termini, le proprietà e concetti relativi ai sistemi com-puterizzati, chiamato Dependability:Basic Concepts and Terminology.Venne quindi introdotto il concetto di Dependability ossia la proprietà di un sistema diessere adeguato a che un essere umano, o una collettività, possa dipendere da esso, senzacorrere rischi inaccettabili. Spesso per motivi di semplicità tale termine viene definitocome garanzia di funzionamento di un dato sistema. Il concetto di Dependability è tuttaviaun concetto composto, questa proprietà infatti è sostanzialmente una valutazione generaledi diversi attributi quali:

• Availability

• Reliability

• Safety

• Security

• Maintainability

Rispettivamente disponibilità, affidabilità, sicurezza, protezione e manutenibilità. La pro-prietà di un sistema di essere dependable è quindi direttamente collegata a questi cinqueattributi, i cui pesi nella stima varieranno a seconda della natura del sistema considerato.Tuttavia in linea generale quando si parla di Dependability ed in particolare di Safety iprincipali aspetti da studiare sono la pervasività, l’inevitabilità e la tolleranza di guasti.Proprio in questi aspetti si colloca FMEA, analizzando le plausibili modalità di fallimentoin funzione di determinati guasti ed identificandone gli effetti è possibile identificare equindi correggere eventuali inefficienze di un sistema.In questo capitolo forniamo una panoramica introduttiva sull’analisi FMEA. Trattandoinizialmente la sua applicabilità in termini storici e di contesto, descriviamo poi il suoobbiettivo, le sue caratteristiche procedurali e le sue classificazioni.

Failure modes and effect(s) analysis 6

Concludiamo illustrando una tipica strutturazione del contenuto informativo prodotto e dicome esso debba essere interpretato.

Dopo la sezione introduttiva, descriviamo in 1.2 lo scopo dell’analisi FMEA caratterizzan-done il contenuto informativo richiesto e prodotto. Nella sezione 1.3 si propone un clas-sificazione generale delle varianti di quest’analisi, in 1.4 si introduce la procedura carat-teristica alla conduzione della FMEA. Nella sezione 1.5 si introduce il concetto di catenaguasto-errore-fallimento. Nelle sezioni 1.6 e 1.7 si discute rispettivamente l’applicazionedella tecnica FMEA in diversi settori industriali e gli aspetti temporali relativi alla suaesecuzione, descrivendo come varia l’impatto dell’analisi in funzione del momento in cuiviene eseguita. Nella sezione 1.8 viene analizzata la principale tecnica di strutturazionedelle informazioni riguardanti l’analisi, andandole quindi a trattare in dettaglio singolar-mente.

1.1 IntroduzioneFMEA, acronimo di failure modes and effects analysis, è una tecnica d’analisi sviluppatadall’esercito statunitense nel 1949. Il suo obbiettivo è quello di classificare modalità difallimento in funzione degli effetti che queste possono causare.Originariamente veniva utilizzata come tecnica di valutazione dell’affidibilità di sistemied equipaggiamenti, per esempio fu adottata nel programma spaziale Apollo con il qualesi assistì al primo sbarco umano sulla luna. Nel corso degli anni 60 l’applicazione diquesta tecnica divenne sempre più frequente, seguendo di pari passo o quasi l’evoluzionetecnologica di quegli anni. Verso la fine degli anni 70 anche la Ford Motor Companyintrodusse l’analisi FMEA per valutare ed assicurare la sicurezza dei suoi prodotti. Adoggi l’evoluzione tecnologica prosegue, portandoci a dipendere sempre di più da sistemiautomatizzati di ogni tipo, per questo lo studio dell’affidabilità è stato ed è tutt’oggi unambito di ricerca in forte espansione in diversi settori.

7 Scopo/Obbiettivi

1.2 Scopo/ObbiettiviL’obbiettivo principale della FMEA è quello di fornire supporto a determinati cicli di pro-duzione e sviluppo di prodotti funzionando da linea guida, individuando e correggendoerrori di progettazione quanto prima possibile. Il suo utilizzo tipico prevede tre attiv-ità, l’identificazione e la comprensione delle potenziali modalità di fallimento e delle rel-ative cause ed effetti, la valutazione dei rischi associati a tali modalità di fallimento el’identificazione delle azioni correttive praticabili.Per comprendere meglio gli obbiettivi di questa tecnica consideriamo un generico sistemae descriviamo dal punto di vista informativo il suo input/output.

Figure 1.2.1: FMEA I/O

E’ molto importante osservare che la vera forza di questa tecnica non risiede nella suametodologia o nelle sue caratteristiche intrinseche, bensì nel interpretazione del contenutoinformativo prodotto.Ovviamente lo scopo delle FMEA è correlato, oltre che alla natura del target d’analisi, almomento in cui si va ad utilizzarla. Per esempio, differentemente da quanto già menzion-ato rispetto all’utilizzo dell’analisi come linea guida di un processo di produzione, questapuò servire da strumento di testing e validazione se applicata al termine di tale processo.

1.3 ClassificazioneNella letteratura a riguardo le classificazioni di FMEA proposte sono svariate. Qui pro-poniamo una classificazione in accordo con quanto esposto in [1], dove vengono proposti3 tipi principali di FMEA ed alcuni casi riscontrabili storicamente con minor frequenza. Itre tipi principali sono:

• System FMEA

E’ il tipo di analisi di livello più alto, pone il proprio focus su eventuali inefficienzedell’intero sistema riguardanti diversi aspetti come, Safety, integrazione, interazione consotto-sistemi e/o altri sistemi ecc. Proceduralmente questo tipo di analisi pone quindi en-fasi sui concetti riguardanti funzionalità ed interazioni.


• Design FMEA

Riguarda il design di un prodotto, inteso come la sua strutturazione. Viene tipicamenteeseguita ai livelli di sottosistema o componente, al fine di garantire affidabilità e sicurezzadelle funzionalità di un prodotto.

• Process FMEA

Differentemente dai tipi appena descritti, questa tipologia si concentra sul processo dicreazione e/o assemblaggio di un prodotto. L’obbiettivo è quello di garantire un’adeguatoed efficiente processo di creazione che rispetti i requisiti ad esso associati.

Come già menzionato in precedenza questi sono i tipi storicamente più comuni, tuttaviacon il passare degli anni e con il progresso tecnologico effettuato si è riscontrato un utilizzosempre più frequente della Software FMEA. Questo tipo d’analisi è adibita ad identificaredebolezze ed errori, valutando l’efficacia di una determinata architettura software. Si pos-sono inoltre individuare altri tipi di FMEA quali la Concept FMEA, versione abbreviataa supporto della scelta di alternative concettuali riguardanti il sistema, la MaintenanceFMEA associata alla capacità di manutenzione di un sistema. Generalmente la Concept,essendo una versione abbreviata dell’analisi “standard”, viene classificata come sotto-tipodella FMEA di sistema. Una variante della FMEA prende il nome di FMECA (failuremode, effetcs and critically analysis), è del tutto analoga alla sua forma standard ma essa,come si può intuire dal nome, aggiunge due aspetti relativi alle varie modalità di falli-mento, ossia la loro criticità e la capacità di rilevazione.

1.4 Procedura e caratteristicheInizialmente il sistema sotto analisi viene scomposto in più livelli, identificando cosi uninsieme di unità gerarchiche. Ogni unità viene a sua volta suddivisa in oggetti elementaridenominati item, questi possono rappresentare parti sistemi, sottosistemi, componenti oattività in relazione alla tipologia d’analisi. Ogni item viene isolato e valutato in dettaglioindividuando le varie modalità di fallimento plausibili. Successivamente, per ogni item ènecessario identificare le funzioni ad esso associate, in modo da poter individuare quantopiù completamente le possibili modalità di fallimento dell’item considerato. Una modalitàdi fallimento è sostanzialmente il modo in cui un item o un operazione fallisce discostan-dosi dal suo comportamento di default o che comunque il sistema si aspetta. In genere perogni item si identificano diverse modalità di fallimento che dipendono dalla sua natura edalla sua funzione.

9 Procedura e caratteristiche

Nella procedura d’analisi questo passo è di vitale importanza, in quanto eventuali di-menticanze in questa fase causano inevitabilmente l’incompletezza dell’intero processod’analisi. Inizialmente il focus viene posto sulle cause della modalità di fallimento, inquesto step è opportuno fare molta attenzione, è necessario identificare le cause rootdel fallimento. Successivamente viene valutata l’occorrenza della modalità di fallimento,questa proprietà insieme alla pericolosità degli effetti correlati permette di valutare e clas-sificare correttamente la gravità di una determinata modalità di fallimento. Gli effetti legatialle varie modalità di fallimento degli item possono essere semplicemente descritti a livellodi sistema oppure, la loro descrizione può essere formalizzata valutando gli effetti altri duelivelli quali locale e livello superiore. La pericolosità di un effetto è legata all’incidenzadi questo sulle prestazioni dell’intero sistema, sulle proprietà di Safety e sulle proprietà diSecurity. Per valutare un effetto si esegue una classificazione discreta creando un range divalori, ognuno associato ad un determinato livello di pericolosità. Diamo un esempio diuna scala di pericolosità nella figura 1.4.1 esposta in [1].

Figure 1.4.1: Scala di pericolosità


Possiamo riassumere quanto appena descritto nella seguente immagine [1] che offre unasequenzializzazione in step dell’intero processo.

Figure 1.4.2: FMEA in steps

1.5 Guasto, errore e fallimentoPrima di approfondire, trattiamo più in dettaglio i termini guasto, errore e fallimento. In unqualsiasi sistema possiamo definire un fallimento come una deviazione del servizio offertocausato dalla manifestazione di un determinato errore, ossia un discostamento dello statodel sistema dal suo stato nominale. Un errore è la diretta conseguenza di un guasto, èquindi evidente la correlazione fra questi tre concetti, per questo si parla comunemente dicatena guasto-errore-fallimento.

11 Guasto, errore e fallimento

Questi tre possono essere visti come diverse osservazioni dello stesso fenomeno. Unguasto viene generalmente classificato secondo natura, origine e persistenza temporale.Nella seguente figura(1.5.1) mostriamo una possibile tassonomia di classificazione guasti.

Figure 1.5.1: Classificazione guasti

Adottando la classificazione esposta in figura 1.5.1, l’interruzione di un collegamento suuna scheda viene classificato come guasto accidentale, fisico, interno, operativo e perma-nente. A differenza un mancato controllo sul valore di una variabile indice nel codiceviene classificato come accidentale, umano, interno, di progettazione e temporaneo.


1.6 ApplicazioniNel corso degli anni la FMEA ha trovato vasta applicazione in diversi contesti, in particolarmodo in tutte le discipline dove l’errore può avere conseguenze catastrofiche, in termini dirisorse o ancora peggio in termini di vite umane.I settori in cui questa tecnica d’analisi trova generalmente applicazione sono molti, percitarne alcuni:

• Settore spaziale

Come già citato questo è stato il primo settore in cui la FMEA ha trovato applicabilità, ilprimo caso d’applicazione risulta la missione Apollo, è stata tuttavia utilizzata successiva-mente in programmi come Viking, Voyager e Magellan. Al giorno d’oggi in questo settorel’utilizzo di sistemi tecnologici è enormemente diffuso, i compiti che questi sono adibitia svolgere sono frequentemente critici. Per questo la FMEA è e può essere ampiamenteutilizzata in questo contesto.

• Settore militare

Vista la tipologia di questo settore, potremmo fare considerazioni analoghe al caso prece-dente. In particolare MIL-STD-1629A è uno standard militare americano con il cui ven-gono descritte le procedure, tecniche ed approcci per eseguire un’analisi FMEA. Questostandard risale al 1980 ma l’ultima sua revisione è stata raffinata nel 1998, aspetto chedimostra la sua importanza.

• Settore sanitario

La delicatezza di questo settore potrebbe giustificare di per sé l’utilizzo tecniche d’analisiquali la FMEA. In [2] viene suggerita l’applicazione di questa tecnica per valutarel’efficacia di organizzazioni sanitarie. In [3] viene descritta una procedura d’analisi rel-ativa a dispositivi medici motivata da quanto esposto dal OSEL (Office of Science andEngineering Laboratories ):” nel 2011 in America più del 20% dei dispositivi medici sot-toposti a manutenzione erano affetti da guasti software”.Per quanto ci riguarda anche in questo settore la FMEA trova applicazione sia a livello dirisorse umane ed organizzazione dei processi che a livello di sistemi di supporto sanitari.

13 Aspetti temporali

• Settore avionico

L’utilizzo della FMEA in questo settore è conseguivo al suo impiego nel settore spaziale,a partire dal 1967 l’utilizzo della FMEA era fortemente e quasi singolarmente adottato,tuttavia al giorno d’oggi in questo settore è prediletta la combinazione fra FMEA e faulttree analysis in accordo con le raccomandazione esposte in ARP4761.

• Settore automobilistico

In questo settore lo standard ISO26262 rilasciato nel novembre 2011 fornisce una serie diprocedure per gestire la sicurezza funzionale e regolare lo sviluppo di un prodotto a livellodi sistema, hardware e software. Tale standard stabilisce inoltre la necessità di eseguireun analisi FMEA nei 3 livelli menzionati, senza però definire formalmente “come” questadebba essere eseguita.

1.7 Aspetti temporaliConsiderando le tipologie d’analisi appena descritte un importante osservazione riguardala loro applicabilità nel tempo. Infatti una FMEA design/sistema può essere eseguita sindalle prime fasi di sviluppo poiché si concentra sul design di quest’ultimo. Differente-mente una FMEA processo viene eseguita molto più ‘tardi’, in quanto per essere eseguitaè necessario predisporre informazioni sui vari processi di assemblaggio e rilascio la cuidefinizione avviene inevitabilmente nelle fasi finali di sviluppo.Possiamo quindi affermare che, nell’intero processo di sviluppo di un prodotto entrano ingioco diversi tipi di analisi a seconda delle necessità e della fase in cui troviamo.


Per un’analisi corretta e completa è opportuno condurre i diversi tipi di FMEA seguendopasso-passo le fasi di sviluppo, quanto detto può essere schematizzato nel seguente modo.

Figure 1.7.1: FMEA in un ciclo di vita software

Eventuali modifiche derivate da un processo d’analisi svolto nelle fasi iniziali avrannoun impatto maggiore rispetto alle altre, infatti in questo caso, si evita la propagazione dieventuali errori nelle fase di sviluppo successive. Per illustrare meglio questo concetto ciserviamo della seguente immagine.

Figure 1.7.2: Impatto della FMEA

15 Worksheet

1.8 WorksheetUn’analisi FMEA generalmente coinvolge un serie di figure professionali, più o meno spe-cializzate, per questo la coordinazione della “squadra” d’analisti rappresenta un aspetto divitale importanza a fini dell’analisi. Eventuali ambiguità e/o errate interpretazioni potreb-bero vanificare lo sforzo richiesto per l’analisi stessa, per questo i risultati e le informazioniriguardanti il processo d’analisi devono essere strutturate in un modo preciso e quanto piùdi facile interpretazione. Il worksheet si presenta nella maggioranza di casi come unatabella nella quale ogni riga fa riferimento ad una particolare modalità di fallimento di unitem. Un esempio di quest’ultimo è il seguente.

Figure 1.8.1: Esempio di Worksheet

Oltre ad essere un importante strumento per la strutturazione di determinate in formazioni,il worksheet ci risulta utile anche per la comprensione dell’analisi stessa.Per questo, procediamo con una panoramica sui parametri di questa tabella.

• Item

Come già accennato, l’item rappresenta un punto chiave dell’analisi, generalmente può es-sere definito come “l’unità elementare che viene analizzata”. Tuttavia la natura dell’item èstrettamente correlata al tipo d’analisi che si conduce. In una FMEA di tipo sistema, l’itemnon è altro che il sistema stesso, mentre per una design FMEA può essere un sottosistemao un componente. Nel caso di process FMEA il concetto di item cambia totalmente la pro-pria natura, in quanto non rappresenta più un unità nel senso strutturale, bensì funzionale,nello specifico contesto rappresenta un passo elementare di un determinato processo.


• Function

Questo parametro rappresenta generalmente tramite una descrizione testuale, la funzioneo il comportamento del relativo item.

• Potential Failure Mode

In relazione all’approccio FMEA utilizzato vengono identificate diverse modalità di fal-limento. Nel caso d’analisi con approccio strutturale un semplice insieme di potenzialimodalità di fallimento può essere il seguente:

1. Circuito aperto

2. Perdita dell’output

3. Corto circuito

4. Rotto (fisicamente)

Nel caso di una FMEA con approccio funzionale le modalità di fallimento risultano piùastratte. L’idea che sta alla base è di considerare, per ogni funzione, ogni stato avversopossibile. Un tipico insieme di modi di fallimento funzionale, che ovviamente può essereesteso, è il seguente:

1. Mancata esecuzione di una funzione

2. Esecuzione funzione prematura

3. Risultati forniti non corretti

Una notevole diversificazione si riscontra nella variante software di quest’analisi, non tantodipendente dell’approccio utilizzato ma dalla natura del sistema sotto analisi. Infatti adifferenza di un sistema elettrico o meccanico, dove le modalità di fallimento dei com-ponenti sono facilmente identificabili, in un sistema software i vari moduli non falliscononello stesso modo, in quanto essendo porzioni di codice non sono affetti da fattori comeusura, stress e quant’altro. I fallimenti di un modulo software vanno ricercati laddove talemodulo presenta un comportamento scorretto o uno stato interno erroneo.

17 Worksheet

In questo caso un potenziale insieme di modalità di fallimento è il seguente:

1. Funzione fornisce risultati scorretti

2. Funzione chiamata prematuramente

3. Mancato invio di messaggi

4. Crash o stop del software

• Potential Effect(s) of Failure

Una volta identificata la modalità di fallimento di un determinato item, sarà necessarioesaminarne gli effetti, questo campo può essere una semplice descrizione testuale deglieffetti sul sistema. Alternativamente si può formalizzare questa descrizione, descrivendogli effetti in 3 livelli d’astrazione. Il primo livello viene denominato locale ed ovviamentefa riferimento all’item stesso, dopodiché si tratteranno gli effetti a livello d’astrazione su-periore chiamato next higher level ossia il livello conseguivo in un’eventuale gerarchia diitem, infine avremo l’end level ovvero il livello a cui fa riferimento il primo caso illustrato,ovvero il livello di sistema.

• Severity (SEV)

Si tratta della gravità relativa all’effetto, in caso di più effetti è relativa al più pericoloso.Questo attributo è generalmente rappresentato da un numero, con il quale si identificail livello di gravità. Ovviamente è necessario definire una scala, in cui ogni numero èassociato ad una specifica gravità, genericamente la scala di valori va da 1 a 10, ma èpossibile anche riscontrare discretizzazioni su solo 5 valori.

• Potential Cause(s) of Failure

Identifica la causa di root associata alla modalità di fallimento prestabilita, è ben impor-tante ricordare che tali cause devono essere indipendenti fra loro e non riconducibili adaltre cause.

• Occurence (OCC)

Il campo OCC denota la probabilità di manifestazione della modalità di fallimento asso-ciata. Può essere rappresentato da un numero reale nel caso risulti possibile stabilire laprecisa frequenza del fallimento, oppure come nel caso dell’attributo Severity è possibileadottare una scala di valori discreta.

• Current Design Prevention/Detection Controls

In queste due colonne vengono descritti i controlli e le azioni correntemente utilizzati perprevenire e rilevare le modalità di fallimento associate.


• Detection (DET)

Anche questo attributo è sostanzialmente un ranking number che identifica la probabilitàdi rilevare un fallimento o le sue cause.

• Risk Priority Number (RPN)

E’ ottenuto dalla produttoria tra i ranking numbers:

SEVERITY X OCCURENCE X DETECTION

Ovviamente è anch’esso un ranking number discreto, identifica la criticità associata ad unparticolare fallimento. Tuttavia questa metodologia di valutazione della criticità è soggettaad alcune limitazioni che ne limitano fortemente l’uso. Innanzitutto non lavorando con val-ori continui si ha una “precisione” di valutazione spesso insufficiente, inoltre l’eventualevalutazione del RPN è per lo più soggettiva. Per concludere, è possibile che diversi valoridi S, O, D possano generare RPN identici, questo non rappresenta sicuramente un vantag-gio per un’eventuale classificazione.

• Raccomended Action(s)

Sotto questo campo verranno inserite le descrizioni testuali delle azioni raccomandate alfine di ridurre o addirittura eliminare il rischio associato alla modalità di fallimento con-siderata. Ovviamente stabilendo tali azioni è necessario tenere in considerazione diversiaspetti, fra cui gli eventuali controlli già presenti, la classificazione della relativa criticità,il costo delle azioni e la loro efficacia. Per ogni specifica causa di una determinata modal-ità di fallimento si possono individuare diverse soluzioni (azioni), ognuna avente i relativivantaggi e svantaggi rispetto alle altre, per questo spesso si predilige l’inclusione di unaulteriore colonna di worksheet denominata, actions taken con cui si specifica l’effettiva im-plementazione scelta fra le raccomandate. Sovente il worksheet è dotato anche di ulterioricolonne finali, queste sezioni sono le seconde occorrenze degli attributi SEV, OCC, DETed RPN, la cui funzione è quella di fornire una visione quantitativa dei suddetti aspettidopo le azioni correttive intraprese.

2Stato dell’arte

In questo capitolo si va ad esplorare la letteratura relativa alla Software FMEA, evi-denziandone il progresso temporale. Vengono introdotti diversi papers descrivendone ilcontenuto e riportando importanti considerazioni sulle metodologie proposte e sugli as-petti fondamentali. Nella sezione 2.1 vengono esposte alcune considerazioni in meritoall’applicazione storica della Software FMEA. Nella sezione 2.2 vengono presentati e dis-cussi criticamente diversi approcci relativi alla Software FMEA evidenziandone le carat-teristiche principali. Infine nella sezione 2.3 si propone una struttura tabellare che riassumequanto esposto nella sezione 2.2.

2.1 IntroduzioneDal momento della sua nascita per molti anni la tecnica d’analisi FMEA ha trovato appli-cazione principalmente su sistemi fisici e processi produttivi. L’evoluzione tecnologica hapermesso l’integrazione di componenti software in un numero sempre maggiore di sistemi,rendendo la funzione di questi sempre più importante. La necessità di adattare l’analisiFMEA a sistemi software deriva dal fatto che molti sistemi svolgono funzionalità relativa-mente importanti, dove un eventuale guasto potrebbe portare a conseguenze catastrofichesia dal punto di vista economico che dal punto di vista di umano. Il livello d’applicazionedi sistemi critici è attualmente elevato e con il passare del tempo è inevitabilmente desti-nato ad incrementare. Nel corso degli anni 70’, circa 20 anni dopo la sua nascita, l’analisiFMEA trova applicazione anche a sistemi software, seppur con molte differenze “con-cettuali” dalle versioni iniziali il processo d’analisi software segue le stesse linee guidadelle prime analisi, tuttavia la rilevante differenza nell’oggetto posto sotto analisi implicauna serie di importanti considerazioni.

2.2 Soluzioni ed approcci propostiIn letteratura un primo approccio alla software FMEA(SFMEA) risale al 1979, descrittoin [4] focalizzandosi sugli aspetti da considerare per poter applicarla su sistemi software.Questo lavoro si focalizza sulla definizione di un approccio per eseguire l’analisi FMEA alivello software durante la fase di analisi dei requisiti. La tecnica proposta individua dueattività essenziali alla conduzione dell’analisi, l’analisi dei rischi e lo studio di fattibilità.Nella letteratura a riguardo, l’attività d’analisi dei rischi risulta uno strumento di grandeimportanza in quanto viene utilizzata in numerosi approcci.

Stato dell’arte 20

A differenza dell’articolo appena discusso, in [5] viene proposto un approccio d’analisirelativo ad un determinato target. Il contenuto di questo paper estende quanto espostoin [4] adattando la tecnica descritta al contesto di un sistema di controllo embeddedreal-time. L’approccio sfrutta l’attività di software hazard analysis (analisi dei rischi)per effettuare una mappatura tra variabili e/o moduli in cui un guasto di propaga. Dalpunto di vista metodologico non vengono introdotte particolari osservazioni, di fattola metodologia proposta è analoga a quella relativa alla conduzione di analisi FMEA“classiche”.

Il paper [5] tratta la validazione di un sistema di controllo, suppone che il sistema siagià stato sviluppato nella sua completezza o quasi, a differenza del paper precedentedove si prediligeva un uso dell’analisi sin dalle primissime fasi di sviluppo software.L’approccio proposto prevede inizialmente un analisi dei rischi del sistema software,eseguita generalmente attraverso l’utilizzo di un fault tree che permette di realizzareuna mappatura tra cause ed effetti, rappresentati rispettivamente da rischi/pericoli evariabili/moduli software critici. La metodologia d’analisi risulta molto simile alla FMEAhardware, la distinzione più evidente riguarda le modalità di fallimento che, in un sistemasoftware le modalità di fallimento vengono individuate da stati logici anomali o dacomportamenti diversi da quelli previsti.

Un procedimento particolarmente utile per una corretta comprensione ed identificazionedelle modalità di fallimento è la suddivisione di quest’ultime in funzione del tipod’unità software considerata, per capire bene questo concetto basta pensare a due unitàsoftware ben distinte, per esempio una struttura dati ed una funzione; il concetto difallimento nel primo tipo deve essere ricercato in uno stato erroneo o eventualmenteinconsistente mentre nel secondo caso un fallimento si traduce in una computazioneinaspettata. Una prima limitazione di questo approccio è la sua completa manualità, incaso di sistemi di medie/grandi dimensioni condurre questo tipo d’analisi può essereun compito molto costoso e complesso. Inoltre è necessario considerare anche che lasingola analisi FMEA non garantisce una valutazione sufficiente di un sistema, general-mente deve essere “affiancata” dalla variante hardware oltre che agli adeguati test del caso.

Sulla stessa linea di questo paper, in [6] vengono illustrate e definite delle tecniched’analisi software su sistemi di controllo embedded real-time applicabili però in fase didesign. Una valida motivazione a questa pubblicazione può essere trovata in una citazionereferenziata in [4] dove si afferma che: ”più del 60% delle modifiche apportate durantel’attività di test sono causate da inefficienze ed incompletezze nella fase di design”. Unopportuna analisi effettuabile sin dalle prime fasi di sviluppo risulta quindi estremamenteutile. Le tecniche esposte in [6], system level FMEA e detailed FMEA differiscono fraloro per i relativi obbiettivi, punti d’applicazione ed anche per la natura dei loro approcci.

21 Soluzioni ed approcci proposti

La prima (system level) viene usata per valutare la capacità dell’architettura software digarantire un operato safe dal punto di vista computazionale, fa riferimento al livello più“alto” nella progettazione software e quindi può essere eseguita sin dalle prime fasi dellosviluppo in quanto oltre che ai requisiti degli elementi componenti il sistema è sufficientepredisporre dell’architettura software iniziale. Conducendo una detailed FMEA si va avalutare la capacita della architettura software implementata di rispettare i requisiti speci-ficati.Per eseguire questo tipo di analisi è necessario avere a disposizione almeno lo pseudo-codice delle varie operazioni/metodi, rispetto alla tecnica illustrata in precedenza ladetailed FMEA è molto più costosa in termini d’esecuzione. L’approccio è simile a quellodella FMEA a livello di componente, l’analista deve ipotizzare i modi di fallimento perogni variabile allocata in ogni algoritmo di ogni elemento software.

Una volta tracciati gli effetti di questi fallimenti nel codice lo stato del sistema vienecomparato con i risultati ottenuti dall’analisi dei rischi preliminare, cercando di identifi-care i potenziali fallimenti associati. Per far ciò è necessario eseguire in maniera manualeo automatica con supporto di specifici tools una mappatura delle variabili del software,che mostri per ogni algoritmo, l’insieme di variabili coinvolte ed i loro relativi ruoli(parametro, valore di ritorno ecc), in questo modo viene definita una sorta di correlazionefra algoritmi, basata sulle dipendenze di quest’ultimi dalle variabili utilizzate. Talecorrelazione sarà usata in seguito per tracciare la propagazione dei fallimenti indotticollegando l’origine del fallimento ad un determinato insieme di variabili di output in cuitale fallimento si manifesta. Sulla base di questa mappatura dovranno essere sviluppatidei threads, fondamentalmente ognuno di questi è una specifica mappatura che associaun insieme di variabili in input ad un insieme di variabili output del sistema in relazionead una computazione prestabilita. Più semplicemente, in riferimento ad un’elaborazioneprestabilita si va a identificare quali sono le variabili in input che determinano il valoredelle relativi variabili di output a livello sistema. Questo sistema di mappature permettedi tracciare fallimenti ed effetti rapidamente.

A questo punto si devono analizzare intrinsecamente gli algoritmi, per ogni tipo delle vari-abili locali, primitive o complesse che siano, dovrà essere definito un insieme di plausibilimodi di fallimento considerando anche aspetti legati al linguaggio d’implementazione edal compilatore utilizzato. A questo punto può essere effettuata l’analisi vera e propriain cui, in ogni modulo vengono indotti sequenzialmente i fallimenti prestabiliti dei varialgoritmi, tracciando gli effetti sull’output del modulo stesso e a sua volta sull’outputdell’intero sistema sfruttando i threads citati precedentemente. Gli effetti identificativengono quindi comparati con i dati forniti dalla software hazard analysis per stabilire see quali fallimenti possono condurre ad un system hazard.


La possibilità di automatizzare parzialmente di questo tipo di analisi costituisce sicura-mente un vantaggio, tuttavia la sua scrupolosità la rende comunque complessa e costosadal punto di vista di tempo e di risorse. Il suo impiego risulta quindi giustificato per sis-temi in cui l’integrità hardware è limitata o addirittura assente. E’ importante osservareche rispetto a tutti gli approcci proposti la limitazione comune è generalmente identificatanel costo dell’esecuzione dell’analisi, per questo l’automazione di questo processo è stataed è tutt’oggi oggetto di ricerca.Un primo studio sull’automazione del processo di FMEA venne proposto nel 1996 dallaFord Motor Company in [7], dove viene definito un preciso Data Flow per automatizzareil processo di analisi FMEA utilizzabile sin dalle prime fasi di sviluppo software. In figura2.2.1 immagine proponiamo il Data Flow esposto in quest’ultimo paper.

Figure 2.2.1: FMEA Data Flow

Con questo, oltre a definire una determinata sequenza di steps per eseguire l’analisi, siva a collocare la FMEA in un processo di software design. Anche se il target d’analisiconsiderato in questa ricerca non è un sistema software, ma in generale un sistema elet-trico/elettronico, l’approccio presentato rappresenta un punto di partenza per numerosericerche, fra le quali anche quella condotta dal nostro dipartimento con la collaborazionedel gruppo di ricerca RCL(Resilient Computing Lab).

23 Soluzioni ed approcci proposti

L’importanza dell’approccio presentato in [7] è collegata all’utilizzo di modelli eseguibiliper simulare il comportamento del sistema sott’analisi. In letteratura si è riscontrata la pre-senza di tecniche d’analisi FMEA che si basano su architettura software descritte tramitelinguaggi semi-formali quali UML. Nel documento [8] viene analizzato in dettaglio il col-locamento dell’analisi FMEA durante la fase di design di un sistema software ed i ruoli dialcuni costrutti UML in questa analisi, descrivendo per ognuno di essi il contenuto infor-mativo utilizzabile ai fini dell’analisi.Come noto, dalla seconda metà degli anni novanta UML rappresenta lo standard piùcomunemente utilizzato in fase di progettazione software, ciò ha indirizzato il lavorodi ricerca sull’applicazione della SFMEA in fase di design su architetture di targetdescritte tramite questo. Oltre ad [8] interessanti osservazioni vengono proposte in [9] e[10]. Il primo pone enfasi sulla costruzione di una valida metodologia d’analisi basatasu UML per software orientato agli oggetti, discutendo l’utilità dei vari costrutti a finidell’analisi in relazione a momenti diversi della fase di progettazione software. Il secondodocumento invece fornisce delle linee guida per la procedura di SFMEA durante duefasi, concept e design/implementation relative ad uno sviluppo software basato sui modelli.

Come abbiamo visto, la complessità del processo di FMEA rappresenta per questo lamaggiore limitazione alla sua applicazione. Negli ultimi anni infatti c’è stato un notevoleinteresse su questo aspetto, diversi lavori sono stati redatti in questo senso. L’automazionedel processo d’analisi può in effetti ridurre il suo costo notevolmente, ottimizzando tuttele fasi dello sviluppo software a cui essa viene combinata.

In [11] viene posta molta attenzione su questo aspetto, l’approccio qui proposto si basasull’utilizzo di due elementi principali.

1. Un modello funzionale espresso in UML e SysML, quest’ultimo è linguaggio dimodellazione general-purpose che supporta specifica, analisi, progettazione, veri-fica e validazione dei sistemi da esso descritti. Tale modello rappresenta il compor-tamento nominale del sistema.

2. Un database adibito alla memorizzazione dei comportamenti non-funzionali del sis-tema, con il quale viene simulato il concetto di fallimento.

Al che viene presentato un algoritmo che rappresenta la parte automatizzata del processo,che realizza la FMEA prendendo in input i sequence diagrams forniti. Tuttavia il lavoroesposto in [11] risulta ancora in fase di sviluppo, attualmente il limite di questa ricercaviene identificato nella costruzione di un apposito tool che integri tutte le fasi costituentiil processo d’analisi descritto.


Un approccio simile viene illustrato in [12] dove, nel contesto dei sistemi embedded safety-critical, si propone una metodologia di automazione della FMEA valida sia per linguaggidi programmazione a basso livello, come per esempio MISRA C, che per lo svilupposoftware Model-driven [25] .La metodologia viene suddivisa in 3 passi, che variano a seconda della specifica consider-ata:

1. Costruzione automatica di un modello eseguibile

2. Iniezione e propagazione dei guasti

3. Identificazione degli effetti

I vantaggi connessi a questa metodologia sono legati alle prime due fasi. Lacostruzione automatica di un modello eseguibile rappresenta un enorme vantaggio ai finidell’automazione del processo in quanto è possibile simulare il comportamento di un sis-tema in modo automatico. Una volta generato il modello eseguibile, che a tutti gli effettirappresenta il comportamento del sistema, possiamo quindi iniettare un guasto e sfruttarel’eseguibilità del modello per ottenere rapidamente informazioni sulla propagazione delguasto e dei relativi effetti. Inoltre anche la 3° fase viene teoricamente “alleggerita”, ilfatto che il modello possa essere eseguito ci dà la possibilità di ottenere determinate tracced’esecuzione.L’identificazione degli effetti può essere effettuata semplicemente confrontando duetracce, quella ottenuta dal modello “standard” e quella ottenuta dal modello affetto daguasti. In [12] viene fatta un’altra importante osservazione, la costruzione automatica delmodello eseguibile, rappresenta in questa procedura l’attività più complessa. Tuttavia nelcaso dello sviluppo software Model-driven questa attività risulta facilitata rispetto al casodi codice di basso livello. La motivazione di ciò sta nel fatto che la specifica di un sistemamediante modelli, per esempio basati su UML, rappresenta in modo migliore e soprat-tutto con meno ambiguità il comportamento del sistema e più nello specifico l’intento delprogrammatore.

25 Tabella riassuntiva

2.3 Tabella riassuntivaSintetizziamo quanto trattato nella sezione precedente in relazione ai papers introdotti inuna tabella riassuntiva. Per ogni paper elenchiamo quindi l’anno di pubblicazione, unadescrizione sintetica dell’approccio proposto, le relative limitazioni considerando aspetticome automazione ed applicabilità ed infine un campo “note”.

Table 2.1: Tabella riassuntiva dei papers citati

3Un recente approccio alla SFMEA

Dopo aver esaminato diversi approcci e descritto le metodologie adottate da questi, pas-siamo alla trattazione di un approccio in via di sviluppo proposto dal gruppo di ricercaRCL del Dipartimento di Matematica e Informatica dell’Università degli studi di Firenze.Questa attività di ricerca definisce un approccio metodologico per l’analisi di architet-ture software component-based descritte in UML. L’obbiettivo finale è di rendere possi-bile l’esecuzione di un analisi FMEA general-purpose, indipendente dal dominio e basatasull’iniezione di guasti in determinati modelli eseguibili, integrabile in un apposito frame-work. Iniziamo descrivendo ad alto livello il workflow generale di questo processo (sezione3.1) individuandone le attività principali. Nelle sezioni 3.2, 3.3 e 3.4 trattiamo queste,rispettivamente Trasformazione del modello, Esecuzione dei modelli e Iniezione di guasti;descrivendo le relative caratteristiche.

3.1 IntroduzioneAbbiamo visto che la software FMEA nel corso degli anni ha suscitato sempre più in-teresse in ambito di ricerca. Questo fatto è direttamente correlato al crescente utilizzo disistemi software, infatti con il passare del tempo si assiste ad una diffusione di questi sem-pre più rilevante. I domini d’applicazione di tali sistemi sono svariati, tecniche d’analisicome la FMEA vengono applicate nella maggioranza dei casi in contesti in cui i sistemisoftware giocano un ruolo critico. Per esempio, nel campo Aerospaziale i sistemi digitalitrovano facile applicazione e spesso sono adibiti allo svolgimento di compiti critici, comead esempio un sistema di pilotaggio automatico di un velivolo. Il fallimento di un sistemadi questo tipo potrebbe causare danni catastrofici in termini di vite umane. Recentemente èstato definito lo standard ISO26262 per la sicurezza funzionale di veicoli, tramite il qualeviene prevista l’attività di safety analysis ai livelli di sistema, hardware e software. Tut-tavia anche se questo standard prevede lo svolgimento di una analisi di questo tipo, inesso non vengono definite delle linee di guida in relazione a come quest’analisi debba es-sere effettuata. L’obbiettivo finale di questa attività è la definizione di un’analisi FMEAa livello software semi-automatizzata, cross-domain ed applicabile ad architetture soft-ware component-based descritte in UML. Questo approccio sfrutta l’iniezione di guastiin appositi modelli eseguibili in modo da evidenziare il discostamento comportamentaledel sistema affetto da guasti da quello di base, in cui non è presente nessun tipo di guasto.Come opportuno, l’attività d’analisi di un architettura software in accordo con ISO26262 èstata scomposta in sotto-attività fra loro correlate in modo da poter formalizzare un precisoflusso di lavoro in cui è possibile collocare l’attività di FMEA.

Un recente approccio alla SFMEA 28

Illustriamo questo flusso di lavoro servendoci del seguente diagramma di flusso.

Figure 3.1.1: Workflow analisi di Safety

L’attività di Safety Analysis Modeling, la prima nel flusso di lavoro, prende in input i req-uisiti di Safety del software, fornendo in uscita un insieme di proprietà che devono essererappresentate nel modello ed un apposito insieme di guasti che tratteremo nello specificonelle sezioni successive. L’attività di Software Model Definition and Refinement può esserevista come un adattamento dell’architettura software fornita dal committente al processod’analisi. Se questa viene fornita allora questa fase si limiterà trasformare quest’ultima inun apposito modello dell’architettura software, altrimenti tale modello dovrà essere creatobasandosi sui requisiti di Safety in input.L’attività successiva, denominata SW FMEA, consiste nell’esecuzione logicadell’omonima analisi a livello architetturale, valutando l’impatto dei guasti softwareindotti e conseguentemente la capacità del software di proteggersi dai relativi effetti.Possiamo quindi affermare che l’output di questa attività descrive sostanzialmentel’effetto di determinati guasti software sugli obbiettivi e sui requisiti assegnati al sistema.

29 Introduzione

Con quest’attività si ha il termine della fase valutativa di questo processo, le attività succes-sive riguardano la definizione e l’analisi delle performance dei meccanismi di protezionesoftware che si intendono introdurre nell’architettura. Nell’attività di Failure Mitigationsi propongono un insieme di meccanismi di protezione che possono essere utilizzati perridurre, prevenire o tollerare gli effetti di un determinato guasto.Safety Mechanism performance analysis è l’attività nella quale vengono valutate leprestazioni dei vari meccanismi di protezione proposti, in modo da poter effettuare unascelta ponderata in base alle esigenze del caso.Un importante osservazione, indirettamente inclusa nella rappresentazione grafica delflusso di lavoro, riguarda l’iteratività di questo processo. Nel caso in cui, vengano ap-portate modiche all’architettura software l’intero processo d’analisi dovrà essere reiteratopoiché in un sistema software, anche la più piccola modifica può avere un impatto tangi-bile nelle prestazioni del sistema e nelle proprietà di Safety e Security. Sostanzialmente ilcore del nostro workflow è costituito dalla prime tre attività.

Figure 3.1.2: Focus del workflow

Il processo evidenziato nell’area grigia può essere scomposto in 5 step fondamentali:

1. Trasformazione dell’architettura in un modello eseguibile

2. Esecuzione del modello senza guasti indotti

3. Iniezioni guasti nel modello eseguibile

4. Esecuzione del modello Faulty

5. Comparazione e/o analisi delle tracce d’esecuzione


Prima di andare a trattare singolarmente queste fasi (sez 3.2,3.3, 3.4) si propone in figura3.1.3 una rappresentazione grafica di questo processo iterativo automatizzato.

Figure 3.1.3: Software FMEA workflow

3.2 Trasformazione del modelloL’input di questa fase è costituito dalla descrizione di una architettura software in UML,component-based ed arricchita di informazioni sul comportamento dei vari componenti.Abbiamo scelto di utilizzare UML in quanto risulta uno dei linguaggi descrittivi più uti-lizzati in assoluto. Tuttavia le caratteristiche che nel nostro contesto risultano veramenterilevanti sono la sua generalità, l’elevata disponibilità di tools di supporto e la capacitàdi estensione grazie al meccanismo dei profili. UML è un linguaggio di modellazionedotato di un forte potere descrittivo, tuttavia non permette di eseguirne i relativi modelli.Per far ciò è necessario traslare verso un nuovo standard, chiamato fUML, definito dallaOMG(Object Management Group), ufficialmente esposto in [13]. fUML, o anche foun-dational UML, definisce una precisa semantica per l’esecuzione dei modelli UML costi-tuiti da un determinato sottoinsieme di costrutti inclusi nella versione standard di UML.Una limitazione di questo standard risiede nel fatto che un modello eseguibile deve esseredescritto con un livello di astrazione relativamente molto basso, questo causa inevitabil-mente un significativo aumento di complessità dei modelli, causando svantaggi nella loro

31 Trasformazione del modello

gestione e creazione. Per ovviare a questo problema individuiamo ALF, descritto in [14],acronimo di Action Language for fUML che è sostanzialmente la rappresentazione testualebasata su Java degli elementi di modellazione di fUML.

3.2.1 Input del processo di trasformazione

Lo scopo finale di questo processo è quello di produrre un modello eseguibile, rap-presentato da una collezione di files sorgente ALF, partendo da un modello descrit-tivo dell’architettura software considerata. Tale modello dovrà contenere informazioniriguardanti la struttura dell’architettura, il comportamento e le interazioni fra i compo-nenti costituenti. La struttura della architettura, come assunto inizialmente, viene descrittatramite approccio basato sui componenti utilizzando lo standard UML. L’architettura soft-ware sarà quindi costruita a partire da componenti riutilizzabili i quali interagiscono fraloro in due possibili modi: “scambio dati” e “chiamata a funzione”. L’interazione fracomponenti è resa possibile grazie al concetto di porta, due porte sono considerate com-patibili fra loro se sono dello stesso tipo e di direzione opposta (in/out). Le porte perlo scambio di dati saranno rappresentate dal costrutto FlowPort del profilo di estensioneMARTE[15].Similarmente le porte che rappresentano interazioni di “chiamata a funzione” saranno rap-presentate dall’elemento del profilo MARTE denominato ClientServerPort. In generale uncomponente dell’architettura sarà costituito da:

• Attributi interni (stato)

• Operazioni interne

• Operazioni da esporre (d’interfaccia)

• Porte di input ed output

Per definizione, la creazione di un modello eseguibile necessita la specifica delle oper-azioni di ogni componente; tale specifica verrà fornita mediante codice ALF, allegatoinizialmente al relativo componente sotto forma di commento, in accordo con le assun-zioni fatte nelle sezioni precedenti. Un altro aspetto da rappresentare nel modello inizialeè il concetto di tempo; la sua introduzione è legata ad una particolare classe di modal-ità di fallimenti, i cosidetti Timing Failures. Si pensi a operazioni la cui esecuzione deveavvenire con un certo periodo; in questi casi l’introduzione del tempo risulta fondamentaleper poter definire i vari periodi d’esecuzione e per verificare che essi vengano rispettati infase d’esecuzione. Ad ogni operazione possono essere associati periodo, fase e durata.


Questa associazione può essere implementata sfruttando nuovamente il profilo MARTE,in particolare:

• Stereotipo <<ResourceUsage>> e relativo attributo execTime per la durata.

• PeriodicPattern [16] e relativi attributi per modellare periodo e fase.

Prima di fornire una descrizione dettagliata sul modo in cui questi aspetti vengono propri-amente trattati in questo processo, definiamo una serie di requisiti che il modello architet-turale di input deve rispettare.Tali requisiti sono suddivisi in proprietà che devono essere supportate (PS) e vincoli dadover imporre (VI) ed inserite nella tabella sottostante(tabella 3.1).

Table 3.1: Requisiti del modello in input


3.2.2 Algoritmo di trasformazione

Per quanto è stato precedentemente affermato, l’algoritmo di trasformazione prende ininput un modello descrittivo costituito da elementi appartenenti a:

• UML-parte strutturale

• fUML-parte funzionale

• MARTE-periodicità d’esecuzione e distinzione fra tipologia di porte

E restituisce un modello eseguibile basato su fUML. Quest’ultimo è un noto sottoinsiemedi UML. Sarà quindi necessario adattare il contenuto informativo non direttamenterappresentabile in fUML eseguendo un apposita mappatura. Per comprendere meglio lametodologia di questo processo, effettuiamo una scomposizione in singoli step sequenzi-abili dei quali offriamo una descrizione.

1)Mappatura dei “Components” (UML)

Osserviamo inizialmente che di tutti i costrutti strutturali presenti in UML class è l’unicopresente in fUML. Rappresentiamo quindi un’istanza del costrutto Component tramite unALF public class. Per ogni proprietà inseriamo nella classe associata un campo privatoopportunamente tipizzato, mappiamo inoltre ogni operazione definita nell’istanza delcomponente con un attività (metodo) nella corrispondente classe ALF. La mappatura delleoperazione necessita un’ulteriore attività la cui trattazione verrà esposta in seguito.

2)Mappatura delle “FlowPorts”

Il procedimento si differenzia in base alla direzione della porta. Per ogni FlowPort condirezione output viene creata una proprietà pubblica(variabile) nella relativa ALF class. Ilvalore assunto dalla variabile creata rappresenterà il valore corrente disponibile sulla portamappata. Per ogni Flowport avente direzionalità input viene invece creata una proprietàpubblica (variabile) nella classe corrispondente avente lo stesso tipo della classe associataal componente connesso all’altra parte della porta.

3)Mappatura delle “ClientServerPorts” (CSP)

Anche in questo caso è necessaria la distinzione in funzione della direzionalità della porta.Una ClientServerPorts può avere direzione provided, in questo caso il componente for-nisce un set di una o più funzionalità della propria interfaccia verso l’esterno.


La mappatura prevede in questo caso la creazione di una operazione pubblica nel compo-nente associato (avente CSP di tipo required) per ogni operazione definita nell’interfacciadel componente che fornisce funzionalità. Le CSP con direzionalità required sono invecetrattate similmente alle FlowPorts, per ognuna viene aggiunto un riferimento alla classeche fornisce il servizio nella classe avente CSP con direzionalità required.

4)Mappatura dei Connettori

Gli step descritti fino a questo punto si occupano sostanzialmente di definire la strutturadelle varie classi, creando ed aggiungendo riferimenti, proprietà ed operazioni. Tuttavia,per stabilire univocamente una connessione fra due componenti è opportuno inizializzarepropriamente il valori delle proprietà e dei riferimenti, così da creare un effettiva associ-azione fra le istanze delle varie classi(componenti).

5)Riscrittura dei corpi delle operazioni

Come già affermato, l’implementazioni delle varie operazioni vengono fornite in input“allegate” alla relativa architettura software in formato testuale ALF. Queste sono fornitein termini di componenti e porte, che quindi dovranno essere sostituite con i relativiriferimenti mappati.

6) Rappresentazione del tempo

Il concetto di tempo non è supportato da ALF. Una possibile soluzione è quella di rappre-sentarlo basandosi su un meccanismo di indicizzazione sui cicli (indexed loops). Questomeccanismo prevede l’indicizzazione del loop relativo all’attività main che simula il com-portamento del sistema, utilizzando una variabile di conteggio che viene incrementata adogni iterazione del main loop. In questo modo è possibile gestire l’esecuzione periodicadelle operazioni tramite un semplice controllo sul valore dell’indice.Per esempio, supponendo che comp1 sia un componente di un sistema e che l’esecuzionedella sua operazione run() abbia periodo 100.


Una possibile implementazione del main loop del sistema è la seguente.

Figure 3.2.1: Gestione periodicità main loop

Tuttavia, in questo modo non si tiene conto della durata dell’esecuzione delle varieoperazioni. Per ovviare a questo problema teoricamente basterebbe incrementare l’indicedel loop di un valore pari alla durata dell’operazione eseguita al termine di quest’ultima.

Sfortunatamente a causa di alcuni vincoli di fUML questo non risulta possibile. Questorappresenta tutt’oggi un aspetto da approfondire in questa ricerca; in quanto lo standardfUML non fornisce indicazioni su come e se dev’essere implementato il concetto di tempo.Quindi al momento non è possibile affermare di più su questo concetto, anche se si pensa diovviare a questo problema introducendo variabili di supporto adibite a contenere il valorein tempo delle operazioni.


3.3 Esecuzione dei modelli e traccePer quanto riguarda l’esecuzione dei modelli, inizialmente sono stati presi in consider-azione diversi tool di supporto. Moliz [17] è un tool basato su piattaforma Eclipse, chefornisce supporto all’esecuzione di diversi tipi di modelli, fra i quali anche quelli basatisu fUML. Il motivo principale per cui quest’ultimo non è stato scelto come riferimento,risiede nella possibilità di riscontrare errori nel caso in cui vengano utilizzati elementinon inclusi in fUML. Una valida alternativa a Moliz è fUML Reference Implementation[13], che è il tool di riferimento per questo standard. Il framework fornisce un simulatorefUML implementato in Java, il quale richiede in input un file in formato XMI e forniscein output una determinata traccia d’esecuzione. Sfortunatamente questo tool disponedi vincoli sul file in input. Apparentemente l’unico modo per riuscire ad eseguire unasimulazione è quello di produrre il modello UML con l’editor Papyrus [18] e quindiandare a modificare manualmente il relativo file XMI, compito evidentemente complessoin caso di modelli di dimensioni considerevoli.

Per finire, presentiamo il tool di riferimento selezionato. ALF Reference Implementa-tion [14]è un implementazione dello standard ALF, open-source e basata su Java, capacedi interpretare e simulare una collezione di file sorgenti ALF. Il framework fornisce unsimulatore ALF basato su fUML Reference Implementation, oltre che alla funzionalità ditraduzione del codice ALF in diagrammi fUML, permettendo la simulazione di modellicostituiti da una combinazione di elementi fUML e ALF. Questo è il motivo principale percui abbiamo scelto questo come tool di riferimento. ALF Reference Implementation risultaadeguato anche per quanto riguarda la generazione di tracce d’esecuzione. La facilità dilettura e scrittura su file di testo permette di poter avviare simulazioni su un determinatoinsieme di dati, forniti sotto forma di file di testo. La produzione delle tracce d’esecuzionepuò essere implementata tramite l’esecuzione di semplici istruzioni per la scrittura su filedi testo, inserite in determinati punti del codice. La trattazione dei dettagli sull’esecuzionedei modelli e sulla produzione delle relative tracce d’esecuzione viene esposta nei capitolisuccessivi.

37 Iniezione Guasti

3.4 Iniezione GuastiL’approccio che proponiamo si basa su un’iniezione guasti a livello di codice ALF, ot-tenuto mediante il processo di trasformazione menzionato nelle sezioni precedenti. Perquanto riguarda la letteratura relativa a questo argomento si individuano diverse tec-niche, come ad esempio quelle trattate in [19] e [20]. In particolare, per quanto riguardal’iniezione di guasti model-level, la presenza di trattazioni rimane relativamente limitata,inoltre in queste non viene specificato né il modello di guasti iniettabili né le loro rapp-resentazioni. Abbiamo riscontrato la possibilità di effettuare l’iniezione di guasti durantedue diverse fasi del flusso di lavoro esposto in [16]: la prima possibilità è di iniettarei guasti direttamente nel modello ALF ottenuto dal processo di trasformazione; la sec-onda prevede l’inserimento della fase di iniezione nel processo di trasformazione dei mod-elli, cosi facendo è possibile utilizzare le informazioni del modello component-based perguidare l’applicazione dei guasti. Tuttavia la seconda è ancora una soluzione da esplorare,consideriamo quindi la prima possibilità. Un’altra osservazione fondamentale riguarda illivello della definizione dei guasti, ne abbiamo identificati due:

• Livello componente

• Livello di codice

Anche se la questione dell’iniezione guasti a livello di codice è stata già trattata più omeno esaustivamente, il livello più consono al nostro approccio risulta comunque il livellocomponente. Questa scelta è stata fatta in relazione a ciò che dobbiamo studiare e valutare,ovvero la propagazione dei guasti più che le relative cause. Per questo motivo abbiamoquindi scelto di iniettare i guasti nelle interfacce dei vari componenti.Un aspetto molto importante per questo argomento è la definizione di un’appropriata li-breria di guasti. Infatti questo step è inevitabilmente preliminare rispetto ad ogni altrostep definibile in questo processo. Questa dovrà tenere conto di tutti i possibili effettiche possono insorgere relativamente all’interfaccia dei componenti quando in questi è pre-sente un determinato guasto. Considerando i sistemi digitali, possiamo individuare duetipi principali di guasti, i guasti hardware ed i guasti software. I primi come si evincedal nome riguardano il funzionamento e la struttura dei componenti hardware, un esempiodi guasto di questo tipo è l’alterazione di un contenuto informativo dovuto alla presenzadi radiazioni. I guasti software invece sono sostanzialmente difetti in porzioni di codice.Tuttavia considerando quanto dimostrato in [21] i guasti software rappresentano la mag-giore causa di malfunzionamenti nei sistemi digitali, e ciò è dovuto principalmente allaloro crescente complessità. La libreria dei guasti adottata in questo processo è basata suimodelli esposti in [22] e [23], in cui i fallimenti vengono considerati come perturbazioninel servizio offerto da un sistema.


Per quanto riguarda il nostro obbiettivo abbiamo quindi individuato tre dimensioni dimodellazione di un guasto:

• Fornitura del servizio

• Istante di fornitura del servizio

• Output del servizio

Di seguito riportiamo una tabella che rappresenta il modello di guasti compatibile conil nostro approccio. In questa vengono riportati, per ogni tipologia di porta e proprietàpresenti nel modello, le modalità di fallimento associate, lo schema di simulazione diqueste e due campi trigger il cui utilizzo sarà illustrato in seguito.

Figure 3.4.1: Modello dei guasti

39 Iniezione Guasti

Dal punto di vista dei componenti, il processo in descrizione prevede l’iniezione di falli-menti nelle interfacce dei componenti e non dei relativi guasti. Il concetto risulta invertitose guardassimo il tutto da una prospettiva a livello di architettura del sistema.Per questo motivo i termini fault injection e failures injection sono intercambiabili inquesto contesto.

La volontà è di definire un framework composto da tre moduli principali:

1. Injector: inserisce i guasti durante il processo di trasformazione

2. Launcher: ha il compito di attivare i guasti

3. Checker: incaricato di controllare l’eventuale violazione dei requisiti di Safety

Prima di andare a trattare in dettaglio questi tre moduli, si fornisce una descrizione visualedel flusso di lavoro relativo all’esecuzione dei modelli con guasti iniettati e alla valutazionedei relativi effetti.

Figure 3.4.2: Workflow Iniezione guasti

Come si può vedere, il flusso di lavoro relativo a questi task prende in input i risultatiprodotti nella fase di design ovvero:

• Modello eseguibile ottenuto mediante l’algoritmo di trasformazione impiegatonell’attività Software Model Definition and Refinement.

• Un insieme di regole correlate ai requisiti di Safety specificati, prodotte durantel’attività di Safety Analysis Modeling.

• Modello di guasti (libreria).


3.4.1 Attività nella fase di Setup

Il modulo Fault Injector è il primo ad essere sfruttato: prende in input il modello eseguibileALF e la libreria di guasti producendo un’insieme triggers ed il modello eseguibile ALFaffetto da guasti. Generalmente l’insieme di triggers viene rappresentato in forma tabel-lare. La tabella 3.2 ne rappresenta un esempio.

Table 3.2: Tabella dei Triggers

Una tupla di questa tabella rappresenta una determinata modalità di fallimento identifi-cando la porta del componente in cui iniettare il guasto, il tipo di guasto da iniettare eil relativo trigger d’attivazione. Selezionando uno o più trigger di questa tabella si vaa definire un insieme di guasti ad essi associati, individuando un determinato faultload,l’insieme di guasti da iniettare nel modello. Per definire correttamente quest’ultimo è nec-essario associare ogni trigger ad un determinato componente, o meglio ad un determinatocostrutto ALF a cui il guasto risulta associabile. Di seguito viene esposto un esempio difaultload definito sulla base della tabella dei triggers illustrata in precedenza.

Table 3.3: Esempio Faultload

Una tupla di questa tabella identifica univocamente il guasto da iniettare nel codice (Trig-ger ID e TriggerType ID). I parametri Start, Duration e Value rappresentano rispettiva-mente istante d’attivazione, durata del guasto e l’eventuale valore da attribuire.

41 Iniezione Guasti

Come illustrato nelle sezioni precedenti, l’iniezione guasti viene effettuata a livellocomponente andando a modificarne il comportamento alterando determinate porzioni dicodice. In questa fase entra in gioco il trigger, il cui compito è quello di attivare unguasto. Dal punto di vista del codice l’attivazione di un determinato guasto coincide conl’esecuzione di una porzione di codice ‘alternativa’ a quella di default. Il trigger quindipuò essere implementato mediante il costrutto if(condition) e nel caso in cui conditionrisulti vera si procederà all’esecuzione del codice “portatore di guasto”. Per comprenderemeglio questo meccanismo forniamo qui un semplice esempio.

Figure 3.4.3: Guasto iniettato

Dall’esempio precedente è possibile fare un’importante osservazione. Il nostro approc-cio prevede l’iniezione di guasti direttamente nel codice ALF prodotto dal processo ditrasformazione e l’attivazione tramite l’utilizzo di appositi trigger. Con un tale approcciol’iniezione dei guasti della libreria viene effettua in una sola volta, tutti i guasti vengonoquindi iniettati nel codice nello stesso step. Grazie ai trigger possiamo quindi attivarli unoalla volta. Questo semplifica molto il processo, in quanto diversamente avremmo dovutoiniettare un guasto alla volta appesantimento così il processo di fault injection.La seconda attività in questa fase, in accordo con la figura 3.4.2, è l’identificazione deipunti di osservazione. Un esempio può essere una variabile il cui valore è strettamentecorrelato ad un determinato requisito di Safety. Le tracce d’esecuzione dei modelli affettida guasti sono quindi in funzione dei punti d’osservazione, che dovranno essere determi-nati effettuando una valutazione dei requisiti di Safety violabili a seguito dell’introduzionedel guasto.


3.4.2 Attività nella fase di Run-time

L’elaborazione nella fase di run-time richiede in input:

• Fault Triggers

• Requisiti di Safety

• Workload

Il primo contenuto informativo viene prodotto dal modulo Fault Injector, mentre i requisitidi Safety sono disponibili e ben definiti sin dalle prime fasi del processo d’analisi. Il work-load rappresenta un tipico profilo d’esecuzione nominale del sistema, come ad esempiouna prestabilita funzionalità che il sistema deve fornire.Il primo passo nella fase di run-time riguarda l’ottenimento di un determinato faultload apartire dall’insieme di trigger prodotto in fase di setup.Come possiamo vedere nella figura 3.4.2 questo passo non è considerato una vera e propriaattività relativa al framework in quanto viene effettuata manualmente, da un designer o daun team di questi. La prima attività che entra in gioco in questa fase è quindi l’attività ditriggers activation; sulla base del faultload selezionato e della attività main che simula ilsistema, quest’attività andrà a settare propriamente i valori dei trigger associati ai guastida iniettare. L’output di questa attività è un modello ALF eseguibile in cui sono statipropriamente definiti punti di osservazione ed iniettati i guasti preselezionati. A questopunto entra in gioco il secondo modulo principale del framework illustrato; il Launcher èresponsabile della parte puramente esecutiva di tutto il processo. Il suo compito è quellodi dare vita alla simulazione sfruttando il tool ALF Reference Implementation introdottonelle sezioni precedenti. La simulazione del sistema non affetto da guasti, che rappresentail comportamento nominale, viene chiamata golden execution la quale produrrà la tracciadi riferimento. Dualmente faulty execution sarà l’esecuzione della simulazione del sistemaaffetto da guasti. Nel caso della faulty execution il modulo Launcher prende in inputil modello ALF prodotto dall’attività di triggers activation e un determinato workloadproducendo una o più traccie d’esecuzione. Nel caso della golden execution l’input ècostituito solamente dal modello eseguibile prodotto dal processo di trasformazione e dalworkload.L’ultimo modulo che viene chiamato in causa è il Checker che prende in input l’insiemedi regole che rappresentano i requisiti di Safety del sistema, già prodotte durante la fasedi design. Oltre a queste l’input è formato anche da una o più tracce d’esecuzione dacomparare. Un importante osservazione riguarda l’utilità delle regole (rules) in questomodulo, queste possono servire per:

• Confrontare gli stessi elementi fra modelli diversi oppure direttamente con un valore.

• Confrontare due tracce d’esecuzione.

4Esempio

Nel capitolo precedente è stato introdotto un approccio all’esecuzione automatica dellasoftware FMEA, descrivendo il flusso di lavoro opportunamente scomposto in attività. Inquesto capitolo si va a testare, su un determinato input, le attività che fanno parte del work-flow, descrivendo e illustrando per ogni fase input, output ed il modo in cui l’attività vieneimplementata nella pratica. Ponendo particolare attenzione a ciò che risulta incompleto oaddirittura da sviluppare. Nella sezione 4.1 viene descritta e caratterizzata l’architetturasoftware target dell’esempio. Nella sezione 4.2 viene trattata l’attività di trasformazionedel modello descrivendone input, ouput, tools e la procedura nel dettaglio. Successiva-mente viene trattata, in modo analogo a quanto fatto per la sezione 4.2, la fase di iniezioneguasti (sez. 4.3). Infine nella sezione 4.4 si propone una descrizione dell’attività di ese-cuzione dei modelli.

4.1 Target dell’esempioPer motivi di spazio non trattiamo l’esecuzione del nostro approccio per un’architetturasoftware completa, ci limitiamo a considerare una porzione di quest’ultima. Andiamo atrattare l’architettura software di un semplice sistema di frenata appartenente ad un moto-ciclo. Tale sistema può essere visto come un semplice loop di controllo il quale periodica-mente rileva i dati provenienti da determinati sensori con lo scopo di trasmettere in uscitaun segnale che rappresenti la situazione correntemenete rilevata. Il sistema è implementatoutilizzando 3 componenti:

• Brake Control

Il suo compito è quello di leggere periodicamente lo stato delle leve di freno e fornireun appropriata uscita, calcolata in funzione dei dati provenienti dai sensori. Il valoredell’output sarà 1 (attuazione freni) se almeno una delle due leve risulta tirata, 0 altri-menti.

• Brake Plausibility

Questo componente svolge la funzione di meccanismo di protezione. Ipotizzando la pre-senza di un CAN bus ed assumendo che il messaggio trasmesso da questo sia 1 se almenouna delle due leve risulta premuta, è possibile realizzare un semplice meccanismo di rile-vazione di guasti. Brake Plausibility legge i dati provenienti dalle leve di freno e dal CANbus, nel caso in cui avvenga un bit flip in una di queste leve, è possibile rilevare il guastocontrollando la plausibilità dei valori forniti da queste semplicemente valutando il

Esempio 44

valore fornito dal CAN bus (canMessage). Nella tabella di verità(tabella 4.1) viene ripor-tata la logica interna di questo controllo, vengono rappresentati i casi di guasto, bit flip inparticolare.In verde abbiamo il valore reale mentre in rosso quello derivato dal guasto.

Table 4.1: Tabella di verità Brake Plausibility

Come possiamo vedere l’uscita fornita da questo componente rispecchia la reale con-dizione delle leve di freno, inoltre grazie al controllo di plausibilità è possibile rilevarela presenza del guasto.

• Brake Output

Il ruolo di questo componente è quello di servire da interfaccia fra il Brake Control e gliipotetici attuatori dei freni. Legge le uscite dei due componenti introdotti in precedenza,se l’uscita del componente Brake Plausibility è ’1’ allora fornisce in output il valore forni-togli da Brake Control, in caso contrario riscontra la presenza del guasto è restituisce ’-1’.Nella seguente tabella di verità riportiamo le combinazioni di valori logiche riportate nellatabella 2 estendendo il tutto considerando l’uscite di tutti e tre i componenti.

Table 4.2: Tabella di verità Sistema

Come possiamo vedere nella prima e terza riga, il bit flip incide sull’uscita del componenteBrake Control; senza controllo di plausibilità tale uscita sarebbe stata propagata da BrakeOutput, grazie al controllo di plausibilità viene rilevato il guasto.

45 Trasformazione dei modelli

4.2 Trasformazione dei modelliIn questa sezione viene illustrata la fase di trasformazione dei modelli sul target d’analisiesposto in 4.1. Nelle sottosezioni 4.2.1 e 4.2.4 si descrivono rispettivamente input e outputdi quest’attività. Nelle sottosezioni 4.2.2 e 4.2.3 vengono illustrate le principali sotto-attività costituenti questi fase. Si conclude la sezione in 4.2.5 elencando le versioni deitools utilizzati.

Figure 4.2.1: Step trasformazione modelli

4.2.1 Input

L’input di questa attività è un modello d’architettura software specificato, come già de-scritto, tramite costrutti UML, fUML e del profilo MARTE. Questo modello viene definitosfruttando l’editor di modellazione Papyrus. La trasformazione del modello è realizzatada due specifici plugin che tratteremo in seguito, in figura 4.2.2 vediamo i componentiUML costituenti l’architettura sotto analisi, le loro operazioni e i relativi parametri tem-porali. In figura 4.2.3 si mostra invece come le rappresentazioni testuali dell’operazionisiano allegate al modello dell’architettura.

Esempio 46

Figure 4.2.2: Input class diagram

Figure 4.2.3: Codice operazioni


4.2.2 Trasformazione

Query

Prima di attuare la vera e propria trasformazione del modello è necessario conoscere indettaglio gli elementi che lo compongono. Per far questo è stato implementato un sis-tema di query basato sul framework EMF-INCQuery. Quest’ultimo è un framework chesupporta query incrementali scritte in un apposito linguaggio dichiarativo. Permette ditrovare pattern su grafi in modo incrementale. Senza entrare troppo nei dettagli di questatecnologia, ne illustriamo il funzionamento illustrando le query implementate nei plugin,adattate ad interrogare architetture software specificate in UML con approccio component-based. Inizialmente, considerando che l’architettura è descritta basandosi sui componenti,sarà opportuno definire una query per ottenere la lista dei componenti che costituiscono ilsistema.

Figure 4.2.4: Query

La prima query si limita a produrre una lista di componenti, con la seconda nestedCom-ponents si associano fra loro componenti appartenenti al sistema logicamente connessida una relazione padre-figlio. Più precisamente le relazioni create sono due: si met-tono in relazione i componenti con le relative proprietà che specificano relazioni padrefiglio e quest’ultime vengono a loro volta associate ai relativi componenti “figlio” dellarelazione. Da qui si evidenzia l’aspetto incrementale di questo linguaggio dichiarativo,l’incrementalità delle query rappresenta un netto vantaggio nel momento in cui andiamoad utilizzare questo framework, sia per comodità e velocità di scrittura che per facilità dicomprensione.

Esempio 48

Un esempio interessante relativo alle query riguarda le connessioni fra componenti medi-ante porte. Vediamone due a riguardo.

Figure 4.2.5: Query connessioni

La prima delle due query in figura 4.2.5 mette in relazione i connettori alle relative end parte dunque queste ai relativi ruoli. In sintesi viene creata una correlazione connettori-parti-ruoli. La seconda, connectedComponents sfrutta la relazione creata dalla query precedenteper connettere fra loro le varie istanze dei componenti. Con precisione i connettori ven-gono logicamente collegati alle due istanze dei componenti ad esso connessi ed alle porteche ne permettono il collegamento. Una volta che questa query viene eseguita due volteper ogni connettore una relazione componente-porta-connettore-porta-componente vieneunivocamente stabilita. Gli stereotipi introdotti dall’utilizzo del meccanismo dei profiliUML vengono anch’essi gestiti tramite un insieme di query: nella figura 4.2.6 ne forni-amo un semplice esempio dove vengono connessi stereotipi, nomi e relativi namespace.

Figure 4.2.6: Query stereotipi


Trasformazione

Il processo di trasformazione vero e proprio è implementato mediante 4 classi scrittein linguaggio di programmazione Xtend. Questo è un linguaggio d’alto livello, generalpurpose ed orientato agli oggetti che affonda le proprie radici semantiche e sintattiche suJava e offre miglioramenti in diversi aspetti come ad esempio overloading ed espressionilambda. Vediamo adesso più in dettaglio i ruoli delle quattro classi che implementanoquesta trasformazione.

ComponentTrasformation

Questa classe definisce il flusso di lavoro principale della trasformazione, il metodotrasformModel ne rappresenta il punto d’entrata.

Figure 4.2.7: Metodo TrasformModel

L’input di questo metodo è la rappresentazione del sistema in forma di componente. Dopoaver inizializzato la classe di utility, per ogni componente che costituisce il sistema (nestedcomponents) viene trasformato singolarmente. L’output prodotto dal metodo di trasfor-mazione viene quindi aggiunto alla HashMap alfSources utilizzando come chiave il nomedel componente trasformato. Dopo aver trasformato ogni componente interno al sistemaanche il sistema stesso viene passato come parametro ad un metodo di trasformazioneadeguato.

Esempio 50

Il processo di trasformazione viene quindi suddiviso in tre diversi metodi, adibiti a trasfor-mare componenti, porte e sistema.

Figure 4.2.8: TrasformComponent/Port

Nella parte destra di quest’immagine possiamo vedere l’implementazione del metodo ditrasformazione dei componenti. In generale un componente viene trasformato creando unheader, trasformando tutte le sue porte, gestendo le sue operazioni e infine creando un ap-propriato footer. Le porte vengono trasformate sfruttando le funzionalità della classe Com-ponentPortSwitch e chiamando la funzione di trasformazione appropriata, com’è mostratonella parte sinistra dell’immagine. La trasformazione del sistema viene attuata creando unapposito header, preparando le istanze dei componenti, impostando i vari riferimenti perle interazioni, definendo il main loop ed infine creando il footer.

Figure 4.2.9: TrasformSystem


Nella costruzione del main loop è presente un’istruzione ancora non trattata, prepareHooksche è adibita all’inclusione degli aspetti temporali delle operazioni. Deve quindi inter-pretare i dati relativi a fase e periodo di un operazione reintroducendoli nel codice ALFsotto forma di costrutti if. La creazione e l’inclusione degli Hooks prevede inizialmentel’esecuzione di determinate query per ottenere i parametri di tempo delle operazioni. Suc-cessivamente viene attuata le vera e propria creazione di questi sfruttando la classe Timing-Information ed in particolare il suo metodo parseTimingInformation. Per motivi di spazionon approfondiamo ulteriormente questa classe e i suoi metodi, ma illustriamo semplice-mente il metodo PrepareHooks che rappresenta il punto d’entrata di questa attività.

Figure 4.2.10: Metodo PrepareHooks

Component2Alf non è altro che l’estensione di ComponentTrasformation, sovrascrivealcuni metodi dichiarati nella sua classe padre.

ComponentUtil

E’ una classe di utility, contiene metodi utilizzati frequentemente nella trasformazionecome per esempio metodi per il controllo del tipi di una porta. Incapsula inoltre alcunefunzioni di query.

Figure 4.2.11: Classe ComponentUtil

Esempio 52

Le prime due classi, aggiunte per estensione permettono l’accesso diretto verso i metodi daloro esposti. L’oggetto di tipo IncQueryEngine gestisce le query su un input prestabilito.Al momento dell’inizializzazione di questa classe viene fatto un accesso ai file contenentiil modelli in input specificati, le informazioni ottenute vengono quindi utilizzate perinizializzare il motore di query. Le query relative agli stereotipi FlowPortStereotypee ClientServerPortStereotype vengono quindi eseguite in questa fase mettendole adisposizione per un utilizzo successivo.

ComponentPortSwitch

In molti casi nel processo di trasformazione si riscontrano ripetizioni di alcuni percorsicomputazionali, sostanzialmente sequenze di decisioni logiche. Questa classe permette diriusare questi percorsi in quanto questi possono dipendere da determinati fattori come adesempio il tipo di porta riscontrato e la direzionalità di quest’ultima. Per capire meglio lasua funzione, vediamone alcuni dettagli implementativi.

Figure 4.2.12: Classe ComponentPortSwitch

La classe è astratta, l’implementazione della logica d’esecuzione viene quindi delegataalle sottoclassi.Un’importante osservazione riguarda i metodi, caseFlowPort incapsula la sequenza di de-cisioni logiche menzionati sopra. L’applicazione del pattern comportamentale templatepermette quindi di implementare le valutazioni logiche in modi differenti, definendo nellesottoclassi l’implementazioni dei metodi caseInputFlowPort caseoutputFlowPort. Infine


un metodo denominato switchPort viene eseguito per avviare questa sequenza di decisionilogiche.

4.2.3 Riscrittura delle operazioni

All’interno delle classi generate, la trasformazione crea proprietà denominate diversa-mente rispetto ai nomi delle porte che rappresentano. Per questo è necessaria un riscritturadel corpo delle operazioni. Una prima idea sarebbe quella di rimpiazzare ogni occorrenzadei nomi delle porte con i nuovi nominativi, questo però può creare degli errori nel casoin cui il nome di una porta sia propriamente contenuto nel nome di un altra. Si pensi peresempio a due porte rispettivamente denominate A e AB, rimpiazzando le occorrenza di’A’ con il nuovo nominativo andremmo a modificare in modo errato anche le porte denom-inate ’AB’. Per far ciò si sfrutta un grammatica sperimentale Alf-Xtext inclusa in Papyruscapace di convertire una porzione di codice ALF in un modello EMF. Prima di tutto ènecessario estrapolare dal modello i commenti di ogni operazione, che come abbiamo sta-bilito in precedenza contengono il codice di quest’ultime. A questo punto viene effettuatoun trim del testo rimuovendo tutti gli spazi vuoti. Dato che il modello è EMF possiamoottenere queste informazioni utilizzando query EMF. Vediamone i dettagli.

Figure 4.2.13: Query per riscrittura operazioni

La prima delle tre query associa gli oggetti NameExpression che rappresentano i puntidove la variabile denominata id viene usata agli id stessi. Con la seconda query si vaa mettere in relazione le espressioni di chiamata ad operazione con i nome delle oper-

Esempio 54

azioni. La terza query invece combine le due precedenti stabilendo un’associazione trainvocazioni delle operazioni e le variabili che le devono sostituire.

4.2.4 Output

L’output della trasformazione è costituito da una collezione di file .alf rappresentanti ivari componenti che formano il sistema. La locazione in cui viene memorizzato è settabileandando a modificare opportunamente il file Tester.java appartenente al plugin denomi-nato hu.bme.mit.swfmea.comp2alf.test. Questa classe è il vero e proprio punto d’ingressodi tutta l’attività di trasformazione. In essa è definito il metodo main che si occupasostanzialmente di inizializzare un oggetto di tipo Comp2AlfTest chiamando il suo metodoinvokeTransformationWithModelTest. Di seguito illustriamo input e output del processo ditrasformazione relativo al componente Brake Control.

Figure 4.2.14: Esempio Componente del modello in input

Nella figura 4.2.14 possiamo vedere la struttura del componente BrakeControl, formatoda tre porte ed una operazione, nelle due finestre nella parte destra abbiamo la rappresen-tazione testuale dell’operazione run del componente e i relativi valore di periodo e fase.


Vediamo adesso qual è l’output relativo a questo componente, il contenuto del file Brake-Control.ALF è il seguente.

Figure 4.2.15: Output BrakeControl

4.2.5 Versioni dei tools utilizzati

• Eclipse Modeling distribution -Version: 4.4 (Luna, released 2014.06.25)

• Eclipse Modeling Framework - Version: 2.10.0 (included in Modeling distribution)

• Xtext - Version: 2.6.2 (includes Xtend)

• UML2 Extender SDK - Version: 5.0.0

• Papyrus -Version: 1.0.0

• MARTE profile from Papyrus additional components - Version: 1.0.0

• EMF-IncQuery-Version: 0.8.0

Esempio 56

4.3 Iniezione dei guastiIn questa sezione viene tratta la fase di iniezione guasti. Nelle sottosezioni 4.3.1 e 4.3.3vengono descritti rispettivamente input e output di questa fase. Nella sottosezione 4.3.2,divisa in due parti, si descrivono i ruoli dei moduli software che vengono sfruttati.

Figure 4.3.1: Step Iniezione guasti

4.3.1 Input

L’input di questa della fase di iniezione guasti è costituito da:

• Modello dell’architettura software eseguibile

• Faultload e modello guasti

• Rules

Prima di caratterizzare il modello eseguibile in input descriviamo faultload e rules. Comeabbiamo già introdotto il modello viene generalmente strutturato in un’apposita tabellache ne riassume il contenuto. Questa struttura tabellare viene al momento modellato inexcel, nell’immagine seguente vediamo il modello guasti adottato.

Figure 4.3.2: Modello dei guasti

57 Iniezione dei guasti

In base all’approccio proposto la generazione di queste informazioni non viene delegata adalcun modulo software, l’idea è che sia sviluppata “manualmente” in quanto la definizionedel modello dei guasti rappresenta un punto critico nell’analisi FMEA, eventuali carenzee/o dimenticanze in queste fasi si propagano inevitabilmente sui risultati dell’analisi. Iguasti iniettati nel codice sono caratterizzati, oltre che dal proprio identificativo, da altritre parametri:

• Start: descrive il momento in cui è possibile iniettare il questo.

• Duration: descrive la persistenza temporale del guasto.

• Value: indica un potenziale valore da associare al guasto.

La tabella di faultload (tabella 4.3) riassume e struttura queste informazioni associandoleai tipi di guasto ed ai relativi triggerID.

Table 4.3: Tabella di faultload

Esempio 58

Le regole (rules) prodotte manualmente sulla base dei requisiti di Safety dell’architetturasoftware sono rappresentate mediante file testo.

Figure 4.3.3: File di testo delle regole

La notazione utilizzata prevede :

[istante d’attivazione osservazione]->(condizione da monitorare)

Dove la condizione è caratterizzata da un determinata proprietà, un operatore ed un valoreprestabilito.Come introdotto nei capitoli precedenti l’inclusione dell’attività di iniezione guasti nelprocesso di trasformazione ci darebbe la possibilità di utilizzare le informazioni del mod-ello component-based per guidare l’applicazione di guasti. Tale approccio non è ancorastato esplorato e sviluppato a dovere. Al momento l’attività di iniezione guasti non risultasviluppata, la direzione di ricerca su questo aspetto volge verso lo sviluppo di un iniezioneguasti inclusa nel processo di trasformazione. Per quanto ci riguarda questa fase al mo-mento viene eseguita “manualmente” e direttamente su codice ALF. Per illustrare i passirestanti supponiamo quindi di disporre di un modello ALF eseguibile dove sono stati ini-ettati i guasti alterando il codice in determinati punti. Vediamo quindi come si presentail codice con guasti iniettati che, visto la parziale implementazione di questa fase, rappre-senta il nostro input.


Per evidenziare la parte mancante di questa attività ci avvaliamo del codice del Brake-Control così da poter effettuare un confronto con il codice di figura 4.2.15, ovvero la suaimplementazione nominale.

Figure 4.3.4: BrakeControl con guasti

4.3.2 Implementazione

Le attività di attivazione trigger e di inserimento dei punti di osservazione vengono im-plementate in due moduli Python (.py), rispettivamente denominati TriggersCreator e Ob-serversCreator.

Esempio 60

TriggersCreator

Questo modulo Python prende in input il file relativo al faultload e il modello eseguibileaffetto da guasti e va quindi ad inserire nel main loop i valori dei parametri relativi altrigger in modo da rendere il guasto attivo. Attivare un guasto significa quindi creare unapposito main loop; per questo l’esecuzione di questo modulo crea un main loop e unTest_System (punto d’entrata simulazione) per ogni riga della tabella di faultload. Trigger-sCreator per far ciò crea, partendo dal main loop del modello in input, un secondo mainloop in cui va ad inserire opportunamente i parametri d’attivazione del guasto acquisitidal faultload. Nella figura seguente mostriamo il frammento di codice con cui il moduloacquisisce i parametri d’attivazione del guasto.

Figure 4.3.5: Acqusizione dati da faultload

Il primo ciclo while nel codice rappresenta il loop principale di questo modulo, infattila condizione del ciclo è dipendente da num_rows, il numero di righe della tabella difaultload.


Il secondo ciclo invece scorre tutte le celle di una riga del faultload memorizzando inapposite variabili i vari parametri.A questo punto è sufficiente creare il nuovo main loop alterando mediante l’inserimentodi questi parametri.

Figure 4.3.6: Scrittura Main Loop alterato

Il codice in figura 4.3.6 scrive il nuovo main loop copiando riga per riga il codice del filedi input. Dopo aver riscritto la firma dell’attività main, arresta momentaneamente la copiascrivendo le righe relative ai parametri d’attivazione del guasto. Giunto a fine scritturachiude il file, esce dal ciclo for ed effettua l’iterazione successiva relativa al prossimoguasto da iniettare.

ObserversCreator

Questo modulo legge le regole riportate nel file rules.txt, creando copie dei file ALF rice-vuti in input in cui sono stati inseriti determinati punti d’osservazione. L’implementazionedi questo modulo è al momento in via di sviluppo, disponiamo solo di una versione parzialedel codice che lo implementa. Non possiamo quindi mostrare tracce d’esecuzione permostrarne il funzionamento.

4.3.3 Output

In linea teorica l’output di questa fase dovrebbe essere il modello eseguibiledell’architettura software affetto da guasti e inclusivo dei punti d’osservazione. Ad oggisiamo in grado di fornire in modo semi-automatizzato l’output senza punti d’osservazione.

Esempio 62

4.4 Esecuzione dei modelli4.4.1 Input

Oltre alla collezione di modelli eseguibili rappresentanti il sistema considerato, questa faserichiede anche un insieme di dati di input su cui simulare il comportamento del sistema.Considerando il sistema d’esempio i dati di input fanno riferimento a:

• Leva freno anteriore

• Leva freno posteriore

• CAN Bus

La prima istruzione nel ciclo principale del main loop prevede la lettura di questi tre dati,di tipo intero. Il file contenente i dati di input viene quindi formattato opportunamente, ilformato è il seguente:

....Intero11,Intero12,Intero13;Intero21,Intero22,Intero23;....

4.4.2 Procedura

Per questo compito abbiamo scelto ALF Reference Implementation. Al momentol’esecuzione dei modelli viene fatta sfruttando questo tool attraverso chiamate da linea dicomando opportunamente parametrizzate. I dati di input su cui si appoggia la simulazionevengono acquisiti da un determinato file di input. Per quanto riguarda la produzione delletracce d’esecuzione si individuano due possibilità, adottabili in modalità singola oppurecombinate. La prima possibilità è quella di stampare a console le informazioni che ci in-teressano, mentre la seconda, in genere più utile, prevede il reindirizzamento dell’output suun determinato file di testo in modo da memorizzare le tracce d’esecuzione. La chiamatache avvia l’esecuzione dei modelli è la seguente:

Java -jar lib/alf.jar MainLoop < dati_input.txt > dati_output.txt

4.4.3 Output

L’output di questa procedura, come già menzionato tende ad essere memorizzato in unfile di testo. Il suo contenuto informativo è strettamente dipendente da tre fattori. Inprimis i punti di osservazione inseriti nel modello eseguibile, a seconda di questi verrannovisualizzati determinati parametri. Il secondo fattore è la durata della simulazione, cheovviamente ci porterà ad avere una quantità di dati più o meno ampia.

63 Esecuzione dei modelli

L’ultimo fattore è legato ai dati di input in quanto per definizione guidano la computazionedella simulazione del sistema. Si fornisce un esempio in cui direttamente dal MainLoopvengono stampati:

• Valore intero che rappresenta l’istante di tempo

• I tre interi in input

• L’eventuale operazione eseguita nel determinato istante di tempo.

Figure 4.4.1: Dati output

Una riga in figura 4.4.1 rappresenta la computazione in un determinato istante di tempo.Il primo valore stampato (j) rappresenta l’istante di tempo mentre i seguenti tre rappresen-tano gli input acquisiti nell’istante. Vengono inoltre stampati gli output delle operazionieseguite nell’istante. Per esempio all’istante di tempo 250, a seguito della lettura dei datidi input vengono eseguite le operazioni run dei componenti BrakePausibility e BrakeCon-trol, stampandone i relativi output in accordo con le relative logiche interne descritte insezione 4.1.

Esempio 64

5Conclusioni

Sono stati esaminati diversi approcci alla conduzione di una Software FMEA, descrivendoper ognuno di essi le relative caratteristiche procedurali ponendo particolare attenzionesugli aspetti di applicabilità e automazione. Tuttavia si è riscontrata la mancanza di unpreciso approccio automatizzato a supporto della conduzione di quest’analisi. È statoquindi esaminato in modo approfondito un approccio in via di sviluppo a cui attualmentepartecipano diversi gruppi di ricerca compreso quello del Dipartimento di Matematica eInformatica dell’Università degli Studi di Firenze. Tale approccio è stato propriamentedescritto nel capitolo 3, illustrando singolarmente le varie fasi da cui è composto.La metodologia alla base dell’approccio presentato comporta alcuni vantaggi. Innanzituttol’utilizzo di modelli eseguibili: utilizzando modelli eseguibili siamo infatti in grado di ef-fettuare simulazioni del comportamento del sistema in modo rapido, diminuendo il costocomplessivo dell’analisi in termini di tempo e risorse. L’approccio adottato all’iniezionedi guasti risulta anch’esso vantaggioso. Infatti come abbiamo visto nei capitoli prece-denti, l’attivazione dei guasti mediante l’uso di appositi trigger rende possibile effettuarel’iniezione di guasti nel modello eseguibile una sola volta, iniettando tutti i guasti. Ne con-segue una diminuzione del costo dell’intero processo. Tuttavia l’introduzione di modellieseguibili rappresenta un vincolo per quanto riguarda la specifica dell’architettura soft-ware in input. Infatti questa, come già visto, deve rispettare determinati requisiti in mododa rendere possibile la sua conversione in un appropriato modello eseguibile. Per com-prendere bene questo aspetto basta pensare al caso in cui un’architettura software includadei componenti composti; questo aspetto non è al momento trattato dal processo di trasfor-mazione e il suo utilizzo precluderebbe l’applicazione del processo di trasformazione e diconseguenza dell’analisi intera. Tuttavia un’ulteriore attività di ricerca potrebbe andare asviluppare un processo di trasformazione sempre più completo, riducendo i vincoli cheil modello in input deve rispettare. Un altro aspetto che al momento viene trattato inmodo “parziale” è la gestione del tempo. I problemi sorgono di conseguenza all’utilizzodi ALF Reference Implementation il quale impone stringenti vincoli sulla gestione di vari-abili condivise, con cui si pensa di risolvere la questione. In relazione al concetto di tempoun aspetto che non risulta gestito è il parallelismo. L’approccio presentato è tutt’ora infase di sviluppo, ad oggi siamo in grado eseguire solo singole attività costituenti il nos-tro workflow. Alcune di queste attività risultano da sviluppare parzialmente o addiritturainteramente.Lo stato d’avanzamento è stato messo in luce nel capitolo 4, nel quale è stato offerto un es-empio d’applicazione della metodologia d’analisi su un’architettura software prestabilita.

Conclusioni 66

Considerando il workflow relativo alla metodologia d’analisi presentata, si forniscono glistati di sviluppo delle singole attività:

• Trasformazione del modello

Attualmente è implementata tramite due plugin scritti in Xtend. Diversi aspetti riguardantiil concetto di tempo non risultano essere trattati, questo rappresenta il principale aspettoda approfondire su questa fase. Per esempio, la durata d’esecuzione delle operazioni nonviene considerata nel main loop supponendo che la loro esecuzione avvenga in un istantedi tempo. Eventuali sviluppi futuri potrebbero trattare, oltre agli aspetti legati al tempo,diversi concetti relativi alla strutturazione dell’architettura software in analisi come adesempio la possibile applicazione di componenti composti.

• Definizione delle regole

Per adesso quest’attività viene eseguita manualmente. Una plausibile direzione di ricercapuò essere : adottare una formalizzazione ben definita dei requisiti di Safety e Security chepermetta di poterne definire una semantica interpretabile in modo automatico.

• Iniezione dei guasti

Al momento l’implementazione di quest’attività non è disponibile. Si suppone di poterlaimplementare senza particolari difficoltà tramite moduli Python direttamente nel codiceALF relativo al modello eseguibile. Tuttavia una plausibile alternativa è di inserire questaattività nel processo di trasformazione dei modelli in modo da poter sfruttare determinateinformazioni del modello descrittivo sotto analisi. In questo modo, oltre a poter sfruttareun contenuto informativo maggiore, si eviterebbe di ricorrere all’utilizzo di Python inquanto l’iniezione verrebbe probabilmente implementata in modo analogo alla trasfor-mazione del modello (Xtend Plugin).

• Definizione dei punti di osservazione

E’ implementata parzialmente in un apposito modulo Python, non è in grado di inter-pretare ed elaborare alcune regole. Si basa sull’interpretazione delle regole formalizzatetestualmente come esposto in 4.3.1.

• Definizione del Faultload

Attualmente e probabilmente anche in futuro quest’attività verrà eseguita manualmente.Infatti, la definizione dell’insieme di guasti da iniettare e gli eventuali parametri associatirisulta un compito difficilmente automatizzabile in quanto, è necessario valutare diversiaspetti relativi al modello in input e ai requisiti di Safety e Security. Un intervento «umano»in quest’attività risulta al momento indispensabile.

• Attivazione triggers

67

Anche quest’attività è implementata in Python. Il suo stato di sviluppo risulta pressochécompleto, tuttavia la mancanza di ulteriori casi d’applicazione non ci permette di poteraffermare la completezza di questo modulo con certezza.

• Simulazione

Al momento la simulazione viene eseguita da linea di comando, sfruttando ALF ReferenceImplementation. Si è in grado di indirizzare input e output della simulazione, acquisendodati in input da determinati file e scrivendo l’output (tracce d’esecuzione) in un file ditesto per esempio. La limitazione attuale di quest’attività risiede nel fatto che non risultaintegrata nel framework, questo aspetto sarà sicuramente l’oggetto principale di ricerca perquest’attività nel futuro.

• Checking

Ad oggi quest’attività viene svolta manualmente, andando ad interpretare e/o compararediverse tracce d’esecuzione. E’ necessario trattare singolarmente questi due casi: nel casod’interpretazione delle tracce d’esecuzione, andando a formalizzare «ad hoc» le regolederivate dai requisiti di Safety del sistema, risulterebbe possibile implementare una logicadi verifica della soddisfazione di requisiti da parte del sistema; l’implementazione dellacomparazione di due tracce d’esecuzione risulta meno proibitiva rispetto al caso prece-dente, tuttavia un primo ostacolo da aggirare risiede nella necessità di produrre tracced’esecuzione omogenee fra loro.

Vista la parzialità di alcune implementazioni risulta molto difficile anche la sequen-zializzazione automatica delle attività correlate, forte limitazione per quanto riguardal’integrazione in un framework complessivo. L’integrazione in un apposito frameworkrappresenta l’obbiettivo finale di quest’attività di ricerca, in particolare si prevede di inte-grare questo approccio nel framework multi-purpose CHESS-CONCERTO [24] adibito asupportare progettazione e valutazione di sistemi complessi .Riassumiamo lo stato d’avanzamento delle attività in tabella 5.1

Table 5.1: Tabella conclusiva sulle attività

6Bibliografia[1]Understanding and Applying the Fundamentals of FMEAs;Carl S. Carlson; AnnualRELIABILITY and MAINTAINABILITY Symposium;2014

[2]Dossier 75: FMEA-FMECA ANALISI DEI MODI DI ERRORE/GUASTO E DEI LOROEFFETTI NELLE ORGANIZZAZIONI SANITARE-DOSSIER-Regione Emilia-RomagnaAgenzia sanitaria regionale

[3]Software Failure Modes and Effects Analysis; Jacob J. Stadler, General ElectricHealthcare Neal J. Seidl; General Electric Healthcare; 2013

[4] Software Failure Modes and Effects Analysis;Donald J. Reifer, Member IEEE;IEEETRANSACTIONS ON RELIABILITY, VOL. R-28, NO. 3;AUGUST 1979

[5] Validating The Safety Of Embedded Real-Time Control Systems Using FMEA;PeterL. Goddard; Hughes Aircraft, Fullerton-; PROCEEDINGS Annual RELIABILITY ANDMAINTAINABILITY Symposium ;1993

[6] Software FMEA Techniques-Peter L. Goddard; Raytheon ;Troy; PROCEEDINGSAnnual RELIABILITY and MAINTAINABILITY Symposium;2000

[7] FMEA Automation for the Complete Design Process;Thomas A. Montgomery FordMotor Company Dearborn; David Richard Pugh University of Wales Aberystwyth;SteveT. Leedham Ford Motor Company Basildon; Steve R. Twitchett Jaguar Cars Coven-try;PROCEEDINGS Annual RELIABILITY and MAINTAINABILITY Symposium;1996

[8] Failure Modes and Effects Analysis during Design of Computer Software-NathanielOzarin, The Omnicon Group, New York ;RAMS 2004

[9] FMEA for UML-based Software-Wang Wentao ,Zhang Hong-Dept. of System En-gineering of Engineering Technology Beihang University, Beijing, P. R. China; IEEE 2009

[10] Computer Aided Software FMEA for Unified Modeling Language Based Software-Herbert Hecht, SoHaR Incorporated, Culver City, California Xuegao An, SoHaRIncorporated, Culver City, California Myron Hecht, SoHaR Incorporated, Culver City,California.; RAMS 2004

[11]Towards a better interaction between design and dependability analysis:FMEA de-

69

Bibliografia 70

rived from UML/SysML models P. David, V. Idasiak & F. Kratz; Institut PRISME/LVR,ENSI de Bourges, Bourges, France;ESREL 2008 and 17th SRA-EUROPE annualconference;2008

[12] Model-driven Automated Software FMEA Neal Snooke, PhD, Aberystwyth Univer-sity Chris Price PhD, Aberystwyth University ; IEEE 2011

[13]Semantics of a Foundational Subset for Executable UML Models (fUML) Version1.1;]Object Management Group“;August 2013.

[14] Action Language for Foundational UML (Alf) Version 1.0.1;Object ManagementGroup; October 2013.

[15] Object Management Group, “UML Profile for MARTE: Modeling and Analysis ofReal-Time Embedded Systems,” Version 1.1, (2011)

[16] Executable Models to Support Automated Software FMEA;Bonfiglio; Montecchi;Rossi; Lollini; Pataricza; Bondavalli ; in IEEE 16th International Symposium on HighAssurance Systems Eng. (HASE’15), pp.189-196, 8-10 ;Jan. 2015

[17] Moliz: A Model Execution Framework for UML Models;T. Mayerhofer, P. Langer.-;Proceedings of the 2nd International Master Class on Model-Driven Engineering atMODELS 2012 (2012).

[18] A UML2 Tool for Domain-Specific Language Modeling;Gérard, S. at al. “Papyrus:;In Model-Based Engineering of Embedded Real-Time Systems, Springer, 6100, 361-368(2001).

[19]Fault injection techniques and tools; M. C. Hsueh, T. K. Tsai, and R. K. Iyer ;Computer, vol. 30, no. 4, pp. 75–82;1997.

[20]Emulation of software faults: A field data study and a practical approach, J. A. Duraesand H. S. Madeira; IEEE Trans. Softw. Eng., pp. 849–867, 2006.

[21]Software dependability in the Tandem GUARDIAN system;I. Lee and R. K. Iyer,;IEEE Trans. Softw. Eng., vol. 21, no. 5, pp. 455– 467, 1995.

[22]Failure classification with respect to detection; A. Bondavalli and L. Simoncini; IEEEComput. Soc. Press; 1990.

71

[23] A development of hazard analysis to aid software design;J.A. McDermid, D. J.Pumfrey;Proceedings of the Ninth Annual Conference on Computer Assurance, COM-PASS ’94 Safety, Reliability, Fault Tolerance, Concurrency and Real Time, Security; 1994.

[24]ARTEMIS-JU-333053 CONCERTO – Guaranteed Component Assembly withRound Trip Analysis for Energy Efficient High-integrity Multicore Systems.http://www.concerto-project.org/

[25]Guest Editor’s Introduction: Model-Driven Engineering;D. C. Schmidt; IEEE Com-puter, vol 39, n. 2, pp. 25-31;February 2006.

Software FMEA, tecniche e tools di...

Documents

Transcript of Software FMEA, tecniche e tools di...