CORSO DILAUREA ININGEGNERIAINFORMATICA
Tesi di Laurea Magistrale
Fault detection e isolation per sistemi domotici
Candidato Relatore
Mariano Leva Ing. Leonardo Querzoni
Correlatore
Dott. Adriano Cerocchi
Anno Accademico 2010/2011
Alla mia famiglia.
i
Elenco delle figure vi
Elenco degli algoritmi vii
Abstract 1
1 Introduzione 2
2 I concetti fondamentali 7
2.1 I sistemi dependable . . . . 7
2.2 Gli aspetti della dependability . . . . 8
2.2.1 Le proprietà . . . . 8
2.2.2 Le minacce . . . . 10
2.2.3 Gli strumenti . . . . 14
3 Stato dell’arte nella FDI 18 3.1 Gli approcci esistenti per la FDI . . . . 19
3.2 FDI in applicazioni critiche . . . . 25
3.2.1 Un esempio di processamento di segnali: il TDR . . . 29
3.3 FDI nel settore del software . . . . 30
3.3.1 Le diverse tipologie di test . . . . 32
3.3.2 Le tecniche di test . . . . 37
3.4 FDI nel settore domotico . . . . 38
ii
4.1 Architettura dei sistemi domotici . . . . 44
4.2 Un modello di sistema specifico . . . . 47
4.2.1 La modellazione di uno scenario reale . . . . 49
4.3 Un modello di sistema generale . . . . 51
4.3.1 Una panoramica sulle semantiche booleane esistenti 55 4.3.2 Scenari rappresentati tramite modello generale . . . . 57
4.4 Il modello di guasto . . . . 60
5 Fault detection e fault isolation 64 5.1 La procedura di discovering . . . . 65
5.1.1 I criteri di fault isolation . . . . 70
5.1.2 L’algoritmo di discovering . . . . 80
5.2 La procedura di fault isolation . . . . 87
5.2.1 Fault isolation passiva in pseudo codice . . . . 93
5.2.2 La fault isolation attiva . . . . 93
6 Dalla teoria alla pratica 100 6.1 Il sistema EDS . . . 100
6.1.1 Il protocollo di comunicazione EDS . . . 102
6.2 La realizzazione dell’impianto . . . 103
6.3 La struttura dell’applicazione . . . 106
6.4 Possibili scenari . . . 110
7 Conclusioni 114
Bibliografia 120
iii
2.1 Gli attributi fondamentali della dependability . . . . 9
2.2 Catena guasto - errore - fallimento . . . . 11
2.3 Le diverse modalità di guasto esistenti . . . . 12
2.4 Tassonomia dei guasti . . . . 13
2.5 La classificazione dei malfunzionamenti . . . . 14
2.6 Le fasi che compongono la fault tolerance . . . . 16
3.1 I possibili effetti a seguito di un guasto in un sistema fault tolerant (a sinistra) e in un sistema non fault-tolerant (a destra) 20 3.2 I tre stadi della fault detection . . . . 22
3.3 Schema base per la model-based fault detection . . . . 22
3.4 Matrice dei residui del movimento di una valvola in un motore di un automobile . . . . 28
3.5 Schema di testing per verificare il corretto funzionamento del sistema di cablaggio di un automobile . . . . 29
3.6 Architettura che utilizza i CCD per il ragionamento sui contesti 41 4.1 Differenze tra collegamento punto-punto e collegamento a bus in un’architettura domotica. . . . 45
4.2 Un esempio di modellazione di una stanza avente tre lampa- dine L1, L2, L3, due voltmetri V1, V2, un sensore di rumore NS1, una serranda S1 e un fine corsa FC1. . . . 51
iv
4.4 Rappresentazione di un grafo azione reazione con un linguag-
gio non booleano in un dato istante di tempo. . . . 59
5.1 Le quattro possibili rappresentazioni di una path. . . . 66
5.2 Una possibile path di un sistema. . . . 67
5.3 Un esempio con V F = 2 . . . . 72
5.4 Un esempio con V F = 1 . . . . 72
5.5 Esempi di applicazione del criterio di isolamento dei guasti. 72 5.6 L’esempio mostra la non usabilità delle path senza oracolo durante l’applicazione del criterio di fault isolation. . . . 73
5.7 Un esempio di applicazione combinata del criterio di fault isolation e di quello dei casi favorevoli. . . . 75
5.8 Un esempio di applicazione di entrambi i criteri di fault isolation e dei casi favorevoli tratto da uno scenario domotico 76 5.9 Tempi d’esecuzione dell’algoritmo a forza bruta e della sua versione ottimizzata al variare del numero di nodi della clique 85 5.10 Confronto tra i tempi d’esecuzione 5.10(a) e valore di VF (5.10(b)) al variare del numero degli archi in un grafo random di 20 nodi. . . . 86
5.11 Le distribuzioni assunte dal grado dei nodi durante la costru- zione dei grafi random con 25, 50 e 75 archi . . . . 88
5.12 Le distribuzioni assunte dal grado dei nodi durante la costru- zione dei grafi random con 100, 125 e 150 archi . . . . 89
5.13 La distribuzione assunta dal grado dei nodi durante la costru- zione dei grafi random con 175 archi . . . . 90
5.14 Applicazione della Fault isolation passiva su quattro diverse topologie di ARG . . . . 91
5.15 Un semplice ARG con un’inconsistenza su l’arco DE . . . . 95
6.1 La composizione di un messaggio EDS . . . 103
6.2 Immagini scattate durante la realizzazione dell’impianto. . . 105
6.3 Il modello di sistema rappresentate l’impianto realizzato . . 110
v
guasto . . . 111
vi
1 Calcolo di V F - Parte Prima . . . . 82
2 Calcolo di V F - Parte seconda . . . . 83
3 Fault isolation passiva . . . . 94
4 Fault isolation attiva . . . . 98
5 Stabilimento dei guasti, vicini di un oracolo . . . . 99
vii
Da molto tempo la procedura di individuazione dei guasti è mascherata dietro l’astrazione del “Perfect Failure Detector [FD]”. Questa, è di solito implementata attraverso protocolli che fanno utilizzo di “heartbeat”; una tecnica indipendente dall’architettura sottostante e che di conseguenza non sfrutta i potenziali benefici ottenibili da essa in fase di isolamento dei guasti. Nei sistemi embedded un numero elevato di azioni produce feedback osservabili che comunemente vengono ignorati.
La massiccia presenza di sensori presenti in tali ambienti permette la produzione di numerose controreazioni che potrebbero rappresentare l’elemento chiave per le procedure di rilevamento e isolamento dei guasti. In tale lavoro di tesi viene introdotto un nuovo approccio che fa uso dell’insieme di feddback osservabili per permettere al manager del sistema, attraverso una procedura collaborativa che tenga conto dell’eterogeneità dei dispositivi presenti e della topologia esistente, di scoprire e isolare i guasti senza aver bisogno di protocolli che fanno uso di heartbeat.
L’approccio è quindi capace di realizzare l’isolamento dei guasti dentro un sistema costituito da una rete di sensori e di attuatori semplicemente osservando i feedback prodotti.
1
1
Introduzione
Un guasto è un comportamento inatteso del sistema sotto controllo.
Qualche volta può essere scoperto e gestito, altre volte invece può condurre ad un’interruzione o al blocco dell’intero sistema.
La fault detection e la fault tolerance sono problemi ampiamente conosciuti nella computazione distribuita; in quest’area la fault detection è trattata per mezzo dell’astrazione del Failure Detector, un modulo software che si occupa di rilevare i guasti attraverso l’invio di heartbeat (messaggi aventi la funzione di indicare se un dato processo è in vita oppure no).
Altro problema, importante quanto la fault detection, è la fault isolation:
una volta scoperto il guasto è importante capire cosa o chi è responsabile della sua attivazione.
Oggigiorno, nell’ambito della computazione distribuita, il problema di ri- levazione dei guasti è trattato sempre da un punto di vista generale, senza tener conto dell’architettura sottostante.
L’invio di heartbeats consiste essenzialmente in uno scambio di messaggi punto-punto: il processo p2, per indicare che è ancora in funzione invia pe- riodicamente tale messaggio al processo p1 il quale si comporta in identico modo. Se p2non riceve il messaggio entro un tempo prefissato, dipendente dalle caratteristiche del sistema, può ritenere p1 guasto e quindi non più facente parte del sistema.
Si noti che p2 decide autonomamente sullo stato di salute di p1; non c’è alcuna interazione tra i processi per ottenere una decisione più affidabile.
Tale tecnica funziona bene in sistemi non omogenei ma non è molto effi- 2
ciente dato che non sfrutta i potenziali benefici che si potrebbero trarre da architetture costituite da un gran numero di componenti.
Questa metodologia è utile per rilevare possibili guasti software ma esistono classi di guasti sulle quali non ha effetto. Una di queste sono i value fault ([3]).
Tale lavoro di tesi è stato sviluppato all’interno del progetto europeo SM4ALL (Smart Home for all [15]), avente lo scopo di studiare e sviluppare una piatta- forma middleware per la cooperazione di servizi embedded intelligenti in scenari “immersivi” attraverso l’uso di tecniche semantiche e di composa- bility al fine di garantire requisiti di dinamicità, scalabilità e dependability mentre si preserva la sicurezza e la privacy delle persone che ne fanno uso (normodotati, disabili, anziani). Nell’ambito di tale contesto è nata la neces- sità di sviluppare un modulo per la FDI che volgesse la sua attenzione ai value fault.
Nei sistemi embedded, un value fault occorre quando la parte hardware di un dispositivo è rotta e la sua parte software non se né accorge. Un sensore con un trasduttore non funzionante è ancora capace di inviare heartbeat ma non è più in grado di percepire le variazioni di intensità luminosa. Una porta motorizzata con il motore guasto è in grado di ricevere i comandi per mezzo del software di controllo ma non è in grado di eseguirli.
Non è facile scoprire un simile comportamento. Bisogna conoscere le altre entità omogenee presenti nel sistema e/o bisogna conoscere il modello del sistema. Nel primo caso possiamo confrontare i valori omogenei ottenuti in modo da filtrare quelli corrotti, nel secondo caso, conoscendo le caratteri- stiche del sistema (ad esempio i valori di temperatura oscillano tra uno e dieci gradi), potremmo applicare un filtraggio “a priori” sui dati acquisiti.
Entrambi gli approcci però presentano delle limitazioni: il primo funziona solo in ambienti omogenei, il secondo impone un modello fisso che né limita l’applicabilità. Molti campi di ricerca quali il settore automobilistico e quello aerospaziale hanno cercato di sviluppare procedure per rilevare e isolare i guasti; ad oggi esistono tecniche di diagnosi in grado di rilevare guasti del motore di un’automobile semplicemente connettendo il pc all’unità di controllo della macchina. Potremmo fare qualcosa di simile in un sistema embedded composto da sensori e attuatori?
Il seguente lavoro ha lo scopo di proporre una tecnica nuova capace di imple- mentare un modulo per la rilevazione e l’isolamento di guasti in un sistema distribuito dinamico e più precisamente all’interno di sistemi caratterizzati da scenari domotici. Il nostro approccio si basa sull’analisi, eseguita a run- time, di grafi. Introduciamo il grafo azione reazione, un grafo orientato in cui vengono mappate le inter-dipendenze esistenti tra i differenti dispositivi del sistema al fine di rilevare i value faults e possibilmente isolarli. Abbiamo investigato su due possibili modalità di isolamento del guasto che abbiamo definito passiva (osservando semplicemente lo stato) e attiva (modificando lo stato corrente). Il resto del documento è organizzato come segue.
Il secondo capitolo tratterà i concetti fondamentali di tale lavoro, la termino- logia di base necessaria alla comprensione del problema in generale. Verrà proposta una introduzione sui motivi che hanno condotto allo studio della fault detection e isolation. Verranno quindi presentati i sistemi dependable e verranno messi in mostra le caratteristiche che devono possedere per essere considerati tali. Descriveremo gli aspetti fondamentali della dependability, le sue proprietà, le minacce e gli strumenti. In particolare, mostreremo le diverse tipologie di guasti esistenti, utilizzando la classificazione fornita da Laprie et all in [3], e discuteremo dei due diversi modi che la letteratura utilizza per riferirsi alle due fasi della fault tolerance, di cui la rilevazione e l’isolamento dei guasti fanno parte.
Nel terzo capitolo presenteremo lo stato dell’arte nella FDI (fault detection and isolation). Inizieremo descrivendone la storia, le diverse tecniche che si sono susseguite nel corso degli anni, proponendo per ognuna di esse, interessanti casi di studio.
Focalizzeremo la nostra attenzione nel settore delle applicazioni critiche (quello automobilistico in particolare) dove analizzeremo nel dettaglio una tecnica di FDI basata su composizione sincrona di macchine a stati e una basata sull’utilizzo del TDR.
Altro settore analizzato è il software dove andremo ad esporre le strategie di testing esistenti in letteratura e i passi di cui si compongono, differenzian- doli in base ai due principali paradigmi di programmazione. Effettueremo un’ampia descrizione delle classi di test esistenti e concluderemo il para- grafo con una sommaria presentazione delle tecniche utilizzate per la loro
realizzazione.
Il capitolo termina con un esempio di applicazione di FDI sviluppato an- ch’esso nell’ambito del progetto SM4ALL. Viene proposta una soluzione adatta a sistemi pervasivi context-aware in cui si sviluppa una particolare struttura dati, che raccogliendo le varie informazioni ottenute dai sensori, è in grado di calcolare la probabilità dei possibili stati dell’ambiente.
Il capitolo quattro narra i principali modelli sottesi alla teoria sviluppata;
il modello di sistema e il modello di guasto. Inizialmente caratterizzeremo l’architettura dei sistemi domotici cosi da capire cosa modellare. Sviluppe- remo un primo modello molto specifico che abbandoneremo per far posto ad uno più completo e generale. É qui che nasce il grafo azione reazione.
Presenteremo tutti i suoi componenti; i moduli, il manager e il linguaggio del sistema.
Nel secondo verrà definito il concetto di permanent value fault; descrivere- mo il comportamento di un modulo affetto da guasto e ne inquadreremo la classe di appartenenza in base alla classificazione proposta nel capitolo due.
Il capitolo cinque tratta la soluzione che abbiamo ideato. É qui che spieghia- mo le due fasi in cui risolviamo il problema.
La prima consiste nel calcolo del numero massimo di permanent value fault isolabili simultaneamente dal sistema. Questo è fatto per mezzo della procedura di discovering. L’algoritmo alla base verrà descritto nel dettaglio, faremo numerosi esempi e porremo in luce i risultati notevoli raggiunti, che ci permetteranno di sviluppare due versioni dell’algoritmo sulle quali confronteremo le performance.
La seconda parte è costituita dalla procedura di fault isolation. La fault iso- lation passiva cercherà di capire chi è il componente guasto semplicemente osservando lo stato del sistema e utilizzando l’informazione calcolata dall’al- goritmo di discovering, mentre la fault isolation attiva potrà, in aggiunta, imporre la transizione del sistema per particolari stati. Mostreremo entrambi gli algoritmi e chiariremo il tutto con vari esempi.
L’ultimo capitolo prima delle conclusioni, tratta la realizzazione di un picco- lo impianto domotico su cui è stata implementata tutta la teoria sviluppata.
Viene svolta una presentazione del sistema EDS, sviluppato da World Data Bus, rappresentante le “fondamenta” di tutto l’impianto, descrivendone
l’architettura e il protocollo di comunicazione. Successivamente documen- tiamo la struttura dell’impianto, costituito da tre lampadine e due sensori di luminosità, e quella dell’applicazione. Il capitolo termina mostrando alcuni scenari possibili e la sequenza d’azioni, da essi generati, che conducono all’isolamento dei componenti guasti.
2
I concetti fondamentali
Nel seguente capitolo vengono proposti concetti e definizioni di base riguardanti i principali argomenti trattati nel resto del documento. Fault Detection and Isolation saranno l’insieme di parole che ci accompagneranno da qui alla fine. Iniziamo, soffermandoci sui motivi che hanno portato alla nascita di tale problema.
2.1 I sistemi dependable
Oggigiorno la nostra società dipende in maniera crescente dall’appro- priato comportamento dei sistemi di calcolo, la cui importanza è palese- mente confermata dalla frequenza di utilizzo e dalla miriade di compiti complessi a cui devono dare soluzione. A conferma di ciò, troviamo vari esempi [9] tra i quali:
• Applicazioni di lunga durata. Sono applicazioni per le quali o è richiesta una grande quantità di tempo di calcolo, al fine di ottenere i risultati desiderati, oppure è richiesto che rimangano attivi per intervalli tem- porali molto lunghi, anche decine di anni. All’interno di tale categoria possiamo inserire i voli spaziali e i sistemi satellitari.
• Applicazioni critiche. Esempi sono dati dal controllo del volo di ae- roplani, applicazioni militari, applicazioni di controllo di processi industriali, come ad esempio le applicazioni per il controllo di centrali
7
nucleari. Ricadono in questa classe quindi, tutte quelle funzionalità in cui i malfunzionamenti possono provocare gravi conseguenze sulla sicurezza delle persone, dell’ambiente o degli impianti.
• Applicazioni poco mantenibili. L’unicità in questo caso è data dalla dif- ficoltà o dai costi elevati delle operazioni di manutenzione. Clas- sici esempi sono le applicazioni di calcolo su sistemi remoti e le applicazioni spaziali.
• Applicazioni disponibili. Fanno parte di tale classe quelle applicazioni per le quali gli utenti richiedenti il servizio si aspettano con alta pro- babilità che il servizio venga realmente fornito all’atto della richiesta.
Esempi classici, sono le applicazioni di gestione di transazioni bancarie oppure i sistemi per la gestione dei servizi anagrafici.
Lo sviluppo economico e tecnologico a cui abbiamo assistito nell’ultimo ventennio ha inevitabilmente reso tali sistemi ancora più sofisticati e di conseguenza complessi, richiedendo allo stesso tempo requisiti e garanzie di buon funzionamento sempre più marcati ed articolati. Sulla base di tali motivazioni si sono concentrati buona parte degli sforzi e delle risorse in fase di ricerca e progettazione, le quali hanno portato alla nascita del termine di dependability dei sistemi di computazione.
2.2 Gli aspetti della dependability
Il concetto in questione è vasto e articolato in vari aspetti riguardanti, le proprietà, gli strumenti a disposizione per progettare un sistema dependable e le minacce che possono portare l’utente finale a non fare più affidamento sui servizi offerti dal sistema sotto utilizzo (Fig. 2.1).
2.2.1 Le proprietà
La dependability è un termine generico la cui definizione deriva dalla sintesi di un insieme di attributi del sistema. Può essere tradotto in italiano come “fiducia nel corretto funzionamento del sistema” [9]. Senza entrare
Fig. 2.1: Gli attributi fondamentali della dependability
troppo nel dettaglio, rimandando i lettori interessati a [9, 3, 28], gli attributi di riferimento, come si può notare guardando la Fig. 2.1 sono:
• Disponibilità (availability). Definita come la probabilità che il sistema non mostri malfunzionamenti nell’istante in cui gli è richiesto di ope- rare. Offre quindi, una misura del corretto funzionamento del sistema ad un dato istante temporale.
• Affidabilità (reliability). Definita come la probabilità che il sistema non mostri malfunzionamenti in un intervallo temporale a condizione che nessun malfunzionamento esisteva all’inizio dell’intervallo. In parole più semplici, l’affidabilità è la probabilità che il sistema funzioni correttamente in un dato intervallo temporale.
• Sicurezza (safety). Definita come la probabilità che il sistema non mostri malfunzionamenti nell’istante in cui gli è richiesto di operare, oppure nel caso in cui esistano, questi non compromettano la sicurezza di persone o impianti relazionati al sistema stesso.
• Confidenzialità (confidentiality). Assenza di diffusione non autorizzata di informazioni.
• Integrità (integrity). Assenza di alterazioni improprie dello stato del sistema.
• Manutenibilità (maintainability). Rappresenta una misura della facilità con la quale un sistema può essere riparato una volta manifestatosi il malfunzionamento.
Questi gli attributi principali. Esistono poi anche degli attributi “secon- dari” che possono essere visti come la combinazione o una specializzazione degli attributi elencati in precedenza.
Laprie et all in [3] citano ad esempio la security (protezione) definita come l’assenza sia di accessi non autorizzati al sistema, sia di gestioni (sempre non autorizzate) del suo stato. Può essere vista quindi, come racchiudente in se le nozioni di integrity, confidentiality e availability.
2.2.2 Le minacce
I tre termini comunemente usati nella descrizione degli ostacoli per la dependability sono: guasto, errore e malfunzionamento (detto anche fallimento), rispettivamente traduzione di fault, error, e failure. I guasti sono l’origine degli errori i quali poi possono dar luogo ai malfunzionamenti.
• Guasto (fault). Tipicamente, un guasto è una imperfezione in qualche componente hardware o software che può derivare da malfunziona- menti di componenti, interferenze ambientali di natura fisica, sbagli dell’operatore o da una progettazione fallace. Esso può o meno, dare luogo ad un errore.
• Errore (error). Viene comunemente definito come una deviazione dello stato del sistema dai possibili stati previsti. La presenza di un errore non necessariamente fa si che il sistema esegua qualche sua funzione in maniera non corretta. In ogni caso, se questo accade allora siamo in presenza di un malfunzionamento.
• Malfunzionamento (failure). Viene definito come una transizione, cau- sata da errori, da uno stato di “servizio corretto” a uno stato di “servi- zio non corretto”. Il malfunzionamento può essere visto come la non corretta esecuzione di una funzione sia in termini quantitativi che in termini qualitativi. Nel primo caso il sistema garantisce l’esecuzione
della funzionalità per cui è stato progettato ma a regime ridotto, nel secondo caso non la garantisce.
Nel seguito diremo che un guasto è attivo nel momento in cui produce un errore, altrimenti lo indicheremo come dormiente.
Diremo inoltre, che un errore è rilevato se la sua presenza è rilevata dal siste- ma (per esempio tramite un messaggio di errore), altrimenti lo indicheremo come latente.
Il nesso logico esistente tra guasto, errore e malfunzionamento, chia- ramente deducibile dalle definizioni di tali termini viene chiamato catena guasto-errore-fallimento. Poiché il fallimento di un componente, dovuto alla propagazione dell’errore dai componenti interni del sistema all’interfaccia di quest’ultimo, può rappresentare un guasto esterno per un altro componente, la catena è ricorsiva (Fig. 2.2).
Fig. 2.2: Catena guasto - errore - fallimento
Laprie et all in [3, 28] propongono anche una dettagliata classificazione di questi tre tipi di impedimenti.
Cominciamo dai fault. Vengono classificati tenendo conto delle cause che li hanno generati. Troviamo sei diverse voci(Fig. 2.3)
• Fase di occorrenza. Specifica se il guasto è originato durante la realizza- zione (progettazione ed implementazione) del sistema, oppure occorre durante il normale funzionamento.
• Fenomenologia. Distinzione tra guasti fisici, ovvero originati da con- dizioni fisiche estreme, quali per esempio eccessive interferenze elet- tromagnetiche, e guasti “umani”, originati invece da “imperfezioni”
dell’uomo (esempio un comando errato impartito da un operatore umano).
Fig. 2.3: Le diverse modalità di guasto esistenti
• Natura del guasto (dominio). Specifica il tipo (guasto hardware o soft- ware oppure è un guasto che riguarda la parte analogica o digitale?).
• Estensione (Confini del sistema). Se i guasti sono localizzati dentro al sistema si parla di internal faults, altrimenti di external faults.
• Intento. Comportamenti non corretti delle persone possono causare guasti colposi (accidental faults), o dolosi (deliberately malicious faults).
• Durata (persistenza). Identifica l’intervallo temporale in cui un guasto si manifesta. Possiamo suddividere ulteriormente tale caratteristica in:
1. Transiente. Il guasto si manifesterà ad un dato istante temporale e scomparirà autonomamente senza che alcuna azione correttiva esterna venga effettuata.
2. Permanente. Il guasto si manifesterà per sempre a meno che un’azione correttiva non venga apportata.
3. Intermittente. Il guasto appare e scompare autonomamente in maniera ripetuta.
Questo permette di definire una tassonomia dei guasti, che possono essere categorizzati e suddivisi in design faults, phisical faults e interaction
Fig. 2.4: Tassonomia dei guasti
faults (Fig. 2.4).
All’interno di questo lavoro tratteremo solo i guasti permanenti, ma di que- sto discuteremo ampiamente nei capitoli successivi.
Per quanto riguarda gli errori invece, non esiste una classificazione preci- sa come per i guasti e i malfunzionamenti. Quest’ultimi vengono classificati sulla base di quattro aspetti ([3, 28]) (vd. Fig. 2.5):
1. Dominio: divide i malfunzionamenti in base al valore e agli effetti temporali. L’erogazione di un servizio dal sistema può rappresentare un value failure, se il valore del servizio erogato dal sistema non si conforma alla specifica, o un timing failure, se invece è il tempo in cui tale servizio è fornito che non soddisfa la specifica.
2. Consistenza: indica la percezione, consistente o inconsistente, del mal- funzionamento esistente tra gli utenti del sistema.
Fig. 2.5: La classificazione dei malfunzionamenti
3. Controllabilità: riguarda l’esistenza o meno di precise modalità di falli- mento ovvero la presenza di regole di comportamento da rispettare in caso di tale evento.
4. Conseguenze: banalmente, indica gli effetti che il malfunzionamento ha sulla popolazione. Possono essere benigni o catastrofici.
Tale lavoro, si focalizza sui value failure che verranno ripresi e trattati nei capitoli successivi.
2.2.3 Gli strumenti
L’ultima proprietà che caratterizza la dependability riguarda le tecniche e le metodologie progettuali che né garantiscono l’esistenza. Lo sviluppo di un sistema dependable prevede infatti l’impiego combinato di quattro tecniche:
• Prevenzione dei guasti (fault prevention): come prevenire l’occorrenza o l’introduzione di guasti.
• Tolleranza ai guasti (fault tolerance): come fornire un servizio corretto anche in presenza di guasti.
• Eliminazione dei guasti (fault removal): come ridurre il numero o la gravità dei guasti.
• Previsione dei guasti (fault forecasting): come stimare il numero attuale, l’incidenza futura e le probabili conseguenze dei guasti.
Dato che tali tecniche vengono svolte dall’uomo, la cui natura è imper- fetta, gli obiettivi prefissati non vengono mai raggiunti. Motivo per cui, nel progetto di applicazioni “dependable”, queste vengono combinate e utilizzate insieme. La sequenza di utilizzo può essere cosi descritta: la fault prevention, purtroppo non è in grado di evitare tutte le occorrenze di gua- sto possibili e per questo è necessario utilizzare tecniche di fault removal.
Queste, essendo imperfette, portano alla necessità di introdurre tecniche di fault tolerance. Infine, la crescente importanza delle applicazioni fa sorgere il bisogno di opportune stime e previsioni future (fault forecasting), le quali, a loro volta, richiedono l’applicazione di regole ovvero di fault prevention e cosi via.
Il tema principale su cui verte questa tesi è la fault detection and isolation (FDI), ragion per cui, andremo ad approfondire la fault tolerance evitando di entrare nel dettaglio delle tre rimanenti tecniche di progettazione.
Fault tolerance
Il suo conseguimento passa attraverso due fasi principali, che la letteratu- ra suddivide logicamente in modi diversi (ma sostanzialmente equivalenti).
In alcuni testi (vd. [9]) si adotta uno schema composto da:
1. Error processing
• error detection
• error diagnosis
• error recovery 2. Fault treatment
• fault diagnosis
• fault passivation
• reconfiguration
Fig. 2.6: Le fasi che compongono la fault tolerance
Laprie, R.K. Iyer et all in [3, 18] invece, ritengono che la fault tolerance si ottenga attraverso:
1. Error detection 2. System recovery
• error handling
• fault handling
Indipendentemente dalla modalità di suddivisione, la tolleranza dei guasti ha due obiettivi fondamentali. In primo luogo quello di scoprire la presenza di eventuali errori e cercare di rimuoverne gli effetti prima che questi diano poi luogo effettivamente ad un malfunzionamento. In secondo luogo, di impedire che i guasti possano originare altri errori. Lo schema di tale suddivisione è presentato in Fig. 2.6.
Dal punto di vista cronologico l’error detection è la prima fase che viene attivata ed ha il fondamentale compito di rilevare la presenza di uno o più guasti/errori e, nel caso in cui siano rilevati, di generare un segnale di errore o un messaggio all’interno del sistema.
L’operazione di system recovery consiste nel trasformare uno stato di sistema
contenente uno o più errori - precedentemente rilevati - in uno stato che ne è privo, evitando inoltre che i guasti da cui derivano tali errori possano essere attivati nuovamente; tutto ciò è reso possibile tramite le fasi di error handling e fault handling.
L’error handling, che ha il compito di eliminare gli errori dal sistema, può essere eseguito con tre diverse modalità:
1. Rollback: tecnica utile con i guasti transienti. Consiste nel riportare il sistema in uno stato precedente alla manifestazione dell’errore, e quindi di corretto funzionamento. Chiaramente questo può essere fatto solo se precedentemente si sono creati opportuni punti di recupero (checkpoint).
2. Compensation: consiste nella trasformazione immediata dello stato affetto da errore in uno stato “error free”.
3. Rollforward: consiste nella ricerca di un nuovo stato caratterizzato da assenza di errore a partire dallo stato corrente erroneo.
Il fault handling, che previene la possibilità che un guasto possa essere nuovamente attivato si ottiene attraverso quattro passi successivi:
1. Fault diagnosis: identifica e memorizza la causa dell’errore, in termini di locazione e tipo.
2. Fault Isolation: esclude logicamente o fisicamente il componente guasto dalle successive operazioni mirate a fornire il servizio
3. System reconfiguration: si attivano componenti di riserva o si riassegna- no i task tra quelli non guasti.
4. System reinitialization: controlla, aggiorna e memorizza la nuova confi- gurazione del sistema.
3
Stato dell’arte nella FDI
Come facilmente deducibile dal titolo, questo capitolo si occuperà di esporre le tecniche esistenti nella letteratura per risolvere il problema della rilevazione e dell’isolamento di un guasto.
I termini fault ed error detection risultano interscambiabili poiché per ar- rivare a un malfunzionamento abbiamo bisogno che il guasto si attivi e produca un errore che propagandosi arrivi fino all’interfaccia del sistema.
Quindi rilevare un guasto (attivo) significa di fatto scovare l’errore. Per tale ragione, da questo momento in poi i due termini verrano utilizzati con lo stesso significato.
Verrà proposta una breve storia della FDI, presentando quindi una pano- ramica delle tecniche esistenti in letteratura (nel settore dell’automatica), per poi osservare come queste vengano utilizzate nei più disparati contesti scientifici. Saranno introdotte le metodologie signal e model based, presen- tando man mano applicazioni concrete. Alcune di queste saranno trattate con maggiore dettaglio tra cui la detection e l’isolation dei guasti nel sistema di cablaggio di un automobile e delle valvole di un motore.
Il capitolo proseguirà con un’ampia trattazione dell’argomento nel settore software in cui i metodi basati su processamento dei segnali e su la costru- zione di modelli, verranno sostituiti dalle strategie di testing.
La conclusione vedrà una breve presentazione di una tecnica FDI sviluppata per il progetto SM4LL (Smart home for all).
18
3.1 Gli approcci esistenti per la FDI
L’esperienza insegna che non sempre un guasto conduce a un malfun- zionamento, poiché di solito i sistemi sono abbastanza robusti da prestare il loro servizio a pieno regime o con un degrado di prestazioni, nonostante l’occorrenza di un qualche guasto. Tali sistemi vengono definiti sistemi fault tolerant.
Talvolta la tolleranza ai guasti può essere una proprietà intrinseca di alcuni sistemi ridondanti. Prendiamo in considerazione un ponte avente un certo numero di pilastri ([12]). Se, a causa dell’occorrenza di un guasto, un pila- stro perde la propria capacità di supportare una parte del carico, gli altri pilastri automaticamente si distribuiranno l’extra carico evitando il collasso dell’intero sistema.
Ciò che rende il sistema fault tolerant è la presenza di una ridondanza fisica, cioè il fatto che un componente critico del sistema (il pilastro) è presente in numero maggiore rispetto allo stretto necessario. Potremmo essere indotti a pensare di aver trovato la soluzione ai nostri problemi ma purtroppo non è cosi. L’eccessivo costo di fatti, la rende applicabile solo in presenza di sistemi critici.
La ridondanza fisica può apparire come una prima tecnica utile al rileva- mento di guasti o meglio al loro mascheramento. Ciò significa che il guasto occorre ma non viene percepito dall’utente finale. Il sistema rileva la presen- za del guasto e nello stesso tempo cerca di prevenire la nascita dell’errore. Ci troviamo quindi di fronte a una fase di isolamento particolare, che si svolge lasciando il componente affetto da fault attivo.
Una soluzione più abbordabile consiste nell’uso della ridondanza analitica in cui la ridondanza non conta sul disporre più copie di uno stesso compo- nente critico, ma fa affidamento a un modello di corretto funzionamento del sistema, grazie al quale, attraverso il confronto tra le misure reali e le misure predette dal modello, si riesce a scoprire e rilevare il guasto.
Prima di entrare nel dettaglio delle tecniche di FDI basate su modello è opportuno introdurre un processo parallelo alla riconfigurazione.
A differenza di tale fase, che avviene a seguito della scoperta di un guasto, nei sistemi che usano un principio di ridondanza analitica, gli effetti del
Fig. 3.1: I possibili effetti a seguito di un guasto in un sistema fault tolerant (a sinistra) e in un sistema non fault-tolerant (a destra)
guasto sono contrastati tramite la fault accomodation (Fig. 3.1). In tale situa- zione il sistema non viene più riconfigurato per contrastare l’occorrenza del guasto; è il controllore del sistema a dover cambiare per ospitare il guasto.
Riccardo Ferrari proprone un ottimo esempio in [12].
Supponiamo di avere un sistema costituito da una macchina e da un controllore, (il guidatore della macchina) e supponiamo che il guasto possa occorrere solo alla macchina considerando (caso ottimistico!) il guidatore un buon pilota. Alla foratura di un pneumatico (occorrenza del guasto), il guidatore avendo un modello mentale del corretto funzionamento della macchina, riesce ad accorgersi che qualcosa non sta funzionando a dovere e cambia, di conseguenza, il suo stile di guida per mettersi in condizioni di sicurezza. La fault accomodation verrà compiuta andando a limitare la velocità.
Il modello presente nella mente del guidatore, viene utilizzato non solo per scoprire e isolare il guasto, ma anche per escogitare un modo per guidare la
macchina mentre si è in situazione di emergenza.
I metodi di diagnosi dei guasti basati su modelli del sistema sotto os- servazione sono relativamente recenti. Storicamente, il primo approccio conosciuto per la diagnosi di guasti in sistemi ingegneristici, non faceva affidamento su l’uso di modelli del sistema sotto controllo, ma contava su la conoscenza dell’insieme dei valori ammissibili per ogni variabile misurata [12].
Questo approccio, chiamato limit checking, fu utilizzato a partire dal di- ciannovesimo secolo per la strumentazione delle macchine dell’epoca [16].
Il metodo scovava l’errore (eseguiva la detection) nel momento in cui una variabile oltrepassava il limite dei valori per essa ammissibili, mentre l’isola- mento del guasto era effettuato andando a verificare quale, tra le variabili esistenti, aveva assunto un valore inammissibile.
Successivamente, intorno alla prima metà del ventesimo secolo, grazie alla disponibilità di filtri passa-banda e oscilloscopi, fu possibile compiere una procedura di diagnosi più accurata.
Nascono le cosiddette tecniche signal-based, basate sul processamento del segnale, nel dominio del tempo e/o nel dominio delle frequenze. Il principio di fatti è simile al limit checking ma in questo caso, avendo a disposizione una strumentazione migliore si riescono a fare analisi più precise. Pertanto i guasti vengono diagnosticati e isolati dal confronto delle componenti spet- trali e delle caratteristiche transienti dei segnali, con appropriati valori di riferimento.
Durante il 1970, grazie all’uso dei calcolatori nei processi ingegneristici, fu finalmente possibile usare anche l’approccio basato su modelli. Tale tecnica prevede un modello matematico rappresentate il funzionamento corretto del processo sotto controllo. L’idea fondamentale è che, usando le stime for- nite dal modello sulle variabili misurate e confrontandole con i valori reali forniti dalle misure compiute, è possibile, valutando la differenza di valore riscontrata, fare detection e isolation del guasto (Fig. 3.2). L’output della procedura di confronto da luogo a un numero di segnali chiamati residui, che idealmente dovrebbero essere uguali a zero nel caso in cui nessun guasto occorra. In realtà, al fine di evitare la produzione di falsi positivi, le soglie
di errore utilizzate sono maggiori di zero. Questo è dovuto ai disturbi fisici presenti nel sistema e alle incertezze insite nel processo di modellazione.
Fig. 3.2: I tre stadi della fault detection
Una delle prime applicazioni di model-based FDI si è avuta nell’indu- stria chimica attraverso l’uso delle equazioni di parità (parity relations) [16].
Un tale pattern usa modelli input-output del sistema per calcolare i residui tra i valori calcolati e misurati della stessa grandezza.
Un altro approccio appartenente a tale categoria prevede l’uso di osservatori diagnostici. In tali casi, viene creato un modello dello spazio degli stati del sistema sotto controllo, dal quale vengono prodotte delle stime sugli stati e le uscite del sistema. Gli errori di stima, sono quindi usati come residui e confrontati con delle opportune soglie per scopi di rilevamento e isolamento (Fig. 3.3).
Bettocchi et all propongono, in [5], un interessante esempio di applica- zione di queste due ultime tecniche.
Senza entrare troppo nel dettaglio, in questo lavoro vengono presentate e confrontate alcune tecniche di ridondanza analitica per il rilevamento e l’isolamento dei guasti ai sensori di misura inseriti negli impianti e nelle
Fig. 3.3: Schema base per la model-based fault detection
macchine industriali al fine di effettuarne il controllo e il monitoraggio. Il tutto è applicato alle misure rilevate su un turbogas industriale monoalbero per poterne valutare le potenzialità in applicazioni di particolare rilevanza.
L’ultima tecnica da analizzare, (vedi [16, 13]), è la parameter estimation.
Tale metodologia utilizza un modello parametrico del sistema sotto con- trollo, in cui si cerca di adattare, durante il monitoraggio, i parametri alle misure osservate. Se i parametri escono fuori dalle loro regioni ammissibili, che stanno ad identificare un sistema correttamente funzionante, viene dia- gnosticato un problema.
Un esempio si ha con il metodo dei minimi quadrati (in inglese OLS: Ordi- nary Least Squares), che insieme ai metodi di ottimizzazione numerici, più precisi sotto l’influenza dei disturbi di processo, sono quelli maggiormente utilizzati nella stima di parametri.
La tecnica dei minimi quadrati consiste nel trovare una funzione che si avvicini il più possibile ad un’interpolazione di un insieme di dati (tipica- mente punti del piano). In particolare la funzione trovata deve essere quella che minimizza la somma dei quadrati delle distanze dai punti dati. Questo metodo va distinto da quelli per l’interpolazione dove si richiede che la funzione calcolata passi esattamente per i punti dati.
Riassumendo, la fault detection and isolation, sotto-campo dell’ingegne- ria del controllo che si occupa del monitoraggio di un sistema con lo scopo di rilevare i guasti e di capirne il tipo e la locazione può essere distinta in due approcci: un pattern diretto di riconoscimento dei guasti attraverso la lettura di determinati valori, rilevati ad esempio, da un sensore, e un’analisi delle discrepanze tra i valori letti e i valori attesi derivati da un qualche modello. In quest’ultimo caso, è tipico dire che un guasto è stato scoperto se la discrepanza, o residuo va sopra una certa soglia. Sarà compito del task di fault isolation caratterizzare il tipo di guasto e la locazione nel sistema.
Le tecniche di cui l’FDI fa uso possono quindi, essere classificate in due categorie:
• basata su modello (model-based): per decidere se un guasto è occorso
viene usato un modello, che può essere matematico o può essere basato su qualche conoscenza del sistema.
• basata su segnale (signal-based): consiste nell’effettuare delle ope- razioni statistiche o matematiche sulle misure acquisite. Un classi- co esempio appartenente a questa tecnica è il TDR (time-domain- reflectometry) che verrà discusso nel proseguo del capitolo.
Inoltre, all’interno della tecnica model-based è possibile compiere un ulteriore distinzione in:
• Metodo basato su osservatori
• Metodo basato su equazioni di parità
• Metodo basato su stima di parametri
Tali tecniche vengono utilizzate nei campi più disparati e maggiormen- te con applicazioni critiche. Nella sezione successiva presenteremo alcuni esempi tratti dal settore automobilistico che di tali tecniche fa ampio utiliz- zo.
Ma anche i sistemi satellitari e quelli automatici godono di tali benefici.
Esempi si trovano in [6, 30].
Nel primo, Braisted e Beckmann espongono l’architettura di un ricevitore GPS, che attraverso l’analisi del segnale emesso dai satelliti in orbita, è in grado di diagnosticare il guasto e escludere il componente non in salute dalle successive computazioni.
Nel secondo invece, Salsbury e Controls, presentano un sistema di controllo per l’impianto di condizionamento di un edificio di grandi dimensioni situa- to a San Francisco. I guasti vengono rilevati tramite il livello di discrepanza esistente tra i valori calcolati dal modello e quelli del processo controllato.
Vengono quindi generate opportune azioni volte a migliorare le prestazioni dei generici controllori PID1.
1Sono controllori tipici nel mondo dell’automatica e più precisamente negli impianti di condizionamento che utilizzano leggi di controllo proporzionali, integrative e derivative
3.2 FDI in applicazioni critiche
La letteratura in questione è molto vasta e una trattazione esaustiva sarebbe alquanto complessa e devierebbe dagli scopi di tale tesi. Ciò nono- stante, porremo l’attenzione soprattutto su come il problema viene affrontato con i motori delle automobili presentando a grandi linee alcuni esempi tratti da applicazioni concrete. Entreremo poi, maggiormente nel dettaglio per ciò che concerne l’utlizzo di metodologie di composizione sincrona di macchine a stati e tecnologie quali la riflettometria nel dominio del tempo.
Lo sviluppo di sistemi di diagnostica per i motori delle macchine ha recentemente raggiunto grande interesse per due principali motivi. Primo, i requisiti di mercato spingono sempre più verso proprietà del veicolo quali, maintainability e repairability. Secondo, e più importante, riguarda la creazione di norme sempre più volte alla sicurezza e al rispetto ambientale.
Qualunque procedura industriale di rilevamento e isolamento di guasti, che voglia essere efficiente, deve soddisfare i seguenti requisiti (tratti da [23]):
• Modularità. Qualunque elemento del processo e dell’ambiente diagno- stico dev’essere descritto da un proprio modello, in modo tale da poter essere ulteriormente usato nella progettazione del modello composto del sistema globale.
• Progetto gerarchico. Bisogna poter realizzare il progetto del sistema di diagnostica a differenti livelli di astrazione. Il modello di un singolo sottosistema a basso livello deve essere completamente definito in modo tale da essere visto a un livello di astrazione più alto, come un singolo componente da comporre con altri componenti.
• Fusione dei dati. Il sistema di diagnostica deve essere capace di estrarre informazioni da diverse sorgenti quali analisi di segnali locali, ridon- danze hardware e analitiche, condizioni logiche e conoscenze empiri- che. In altre parole deve saper interagire con tutte le diverse tecniche usate durante lo sviluppo del sistema.
• Semplicità. In molti casi, gli algoritmi diagnostici vengono implemen- tati in microprocessori con capacità di computazione limitate.
• Analisi temporale. Nella maggior parte dei casi, viene a mancare una co- noscenza precisa riguardante i tempi di propagazione tra l’occorrenza del guasto e l’attivazione del corrispettivo allarme. Una procedura d’in- ferenza accurata, deve tener conto anche di tale situazione, contando su una qualche sorta di analisi temporale.
• Compatibilità con standard industriali. ogni ulteriore spiegazione è su- perflua.
• Integrazione del controllo e degli ambienti diagnostici. C’è bisogno di una compatibilità tra la definizione del sistema di controllo usata durante la fase di progetto e quella adottata durante la definizione del diagnoser.
• Compatibilità con gli ambienti software disponibili in commercio. Dato il crescente accoppiamento che il settore automobilistico ha con le simu- lazioni, una condizione necessaria per l’effettiva applicabilità delle metodologie di diagnosi è la disponibilità commerciale di ambienti software affidabili per lo sviluppo di simulatori che descrivono le dinamiche del sistema (incluso l’occorrenza dei gusti), il sistema di controllo e le procedure diagnostiche.
Oggigiorno, gli approcci più utilizzati per la rilevazione e l’isolamento dei guasti in contesto automobilistico, riguardano entrambe le tecniche, prima esposte, di signal processising e model based.
Isermann in [17] propone due interessati applicazioni di rilevamento dei guasti che fanno uso di tecniche basate su modello. La prima, è un sistema che supervisiona il comportamento del conducente durante la guida in cur- va. In particolare, viene considerata la velocità caratteristica del veicolo come parametro che determina il tipo di “sterzata” (controsterzo o sovrasterzo).
Tale parametro è usato per classificare il comportamento di guida, e quindi, anche per indicare situazioni di comportamenti errati come l’instabilità.
Naturalmente il parametro è confrontato, come previsto da approcci model based, con dei valori ricavati da opportuni modelli e indicanti i possibili
comportamenti di guida (siano essi corretti o critici).
La seconda applicazione invece, descrive una parte del sistema di controllo di un motore di combustione Diesel. Il motore è partizionato in tre grandi sottosistemi: il sistema di aspirazione, il sistema albero motore e il sistema di scarico. Per ognuno di questi sottosistemi sono stati sviluppati adeguati metodi di rilevamento e isolamento dei guasti che utilizzano ambo le tec- niche esposte in precedenza. Più precisamente, l’articolo propone solo lo studio del sistema di aspirazione. In tal caso, le variabili d’ingresso, quali velocità dell’aria, pressione atmosferica e temperatura e le variabili d’uscita quali pressione e temperatura, vengono utilizzate per la generazione dei residui, a loro volta creati attraverso equazioni di parità. Successivamente, dal confronto di tali residui con i valori di riferimento, indicanti il corretto funzionamento del sistema, vengono rilevati e isolati i guasti.
Molto spesso però, le tecniche classiche di rilevamento e isolamento dei guasti possono mancare di uno o più requisiti fondamentali. Ad esempio, le tecniche basate su modello, sono molto sensibili agli errori di modellazione e ai disturbi non conosciuti; inoltre mancano di modularità, flessibilità e semplicità. Le tecniche basate sul processamento dei segnali invece, sebbene delle volte necessarie per ragioni di sicurezza (si pensi al principio di ridon- danza fisica utilizzato all’interno di sistemi critici), mancano della maggior parte dei requisiti esposti a inizio paragrafo.
Sono queste le motivazioni che hanno spinto la letteratura a cercare nuo- ve metodologie oltre a quelle già elencate. Magni et all in [23] sviluppano un nuovo metodo di modellazione del sistema, basato su composizione sincrona di macchine a stati finiti. Viene inoltre descritto un algoritmo in grado di eseguire rilevamento e isolamento di guasti a partire dal modello così costruito, e da un’analisi temporale che tiene conto dei tempi minimi e massimi che intercorrano tra l’occorrenza del guasto e l’attivazione del corrispettivo allarme. L’algoritmo sviluppato quindi, oltre ad identificare univocamente il guasto, ci dirà anche l’istante di tempo in cui ciò accadrà ovvero quanto tempo passerà dal guasto alla sua identificazione.
L’articolo presenta tali risultati partendo dalla modellazione del movimento di una valvola che costituisce un importante problema nello sviluppo delle
Fig. 3.4: Matrice dei residui del movimento di una valvola in un motore di un automobile tratto da [23]. Le righe rappresentano le uscite dei 5 sotto-modelli utilizzati, mentre le colonne rappresentano le fault signature dei guasti che possono occorrere nel sistema.
procedure di sicurezza per i motori delle macchine. Su tale sistema vengono calcolate due misure (da altrettanti sensori) inerenti la posizione angolare della valvola, in accordo ad un principio di ridondanza fisica. Inoltre, viene stabilita un’equazione di bilanciamento della massa, su ognuna di queste due misure, calcolata a partire dalla valutazione di ulteriori variabili, che si assumono per semplicità corrette, in accordo ad un principio di ridondanza analitica.
L’intero sistema viene, quindi, modellato tramite la composizione di sei sotto-modelli: una macchina a stati finiti (FSM) per la valvola, due FSM per i sensori, due FSM per il principio di ridondanza analitica applicato su le due misure calcolate dai sensori e l’ultima FSM per il principio di ridondanza fisica.
Tralasciando i dettagli della composizione, rimandando il lettore interessato all’articolo sopra citato, un importante risultato è ottenuto andando a vi- sionare la matrice dei residui, una matrice contenente tutte le firme dei guasti ovvero i codici di errori che permettono la rilevazione e l’identificazione del guasto (Fig. 3.4). Quello che si scopre è che basta comporre solo cinque dei sei sotto-modelli totali per ottenere una matrice dei residui con tutte colonne diverse e quindi per isolare senza ambiguità tutti i tipi di occorrenze di guasto riscontrabili nel sistema.
Fig. 3.5: Schema di testing tratto da [20]. Il TDR (135) viene utilizzato per inviare un impulso sulla linea di test 115 al fine di testare il sistema di cablaggio 118 e verificare se qualche connettore di espansione (120) o di terminazione (125) è connesso impropriamente.
3.2.1 Un esempio di processamento di segnali: il TDR
Più comunemente conosciuto come riflettometro nel dominio del tempo, un TDR è uno strumento elettronico usato per caratterizzare e localizzare i guasti in cavi metallici, come ad esempio, cavi coassiali o doppini telefonici.
Può anche essere usato per localizzare discontinuità nei connettori o in qualunque cammino elettrico.
La Riflettometria nel Dominio del Tempo è una tecnica basata sull’analisi del segnale viaggiante lungo una linea di trasmissione e riflesso da un generico carico.
Nell’esempio proposto, tratto da [20], Klassen e Anderson usano il TDR per testare il sistema elettrico di un automobile costituito da un sistema di cablaggio e da dispositivi elettrici connessi per mezzo di opportuni con- nettori di terminazione2(Fig. 3.5) Più precisamente, l’applicazione di un impulso su una linea di test dedicata inclusa nel sistema di cablaggio e il monitoraggio del segnale riflesso, causa impedenze ovvero connettori connessi impropriamente, permette di rilevare l’esistenza e la locazione del guasto.
L’istante di tempo in cui si osserva la ricezione del segnale riflesso, sinonimo
2Esempi di dispositivi elettrici possono essere l’autoradio, le luci e così via.
della presenza di un connettore non propriamente connesso, permette di capire la locazione del guasto (eccetto naturalmente la pulsazione riflessa a causa della terminazione della linea di test). Questo poiché la velocità di propagazione nel mezzo è pressoché costante e quindi la pulsazione rifles- sa può essere analizzata anziché in funzione del tempo, in funzione della lunghezza del mezzo.
3.3 FDI nel settore del software
Focalizzeremo l’attenzione sulle strategie di testing esistenti in lettera- tura. Queste di fatti, hanno da sempre costituito il principale metodo di detection e isolation degli errori commessi dai programmatori. In parti- colare, verranno esposti i principi alla base delle strategie di testing più utilizzate, i passi di cui tale strategie si compongono, comprese le differenze esistenti tra i due principali paradigmi di programmazione, e le tecniche maggiormente usate durante tali passi.
Il software dev’essere testato per individuare gli errori che sono stati commessi inavvertitamente durante la fase di progettazione e realizzazione.
Qualunque strategia di testing deve incorporare la pianificazione, la pro- gettazione dei test case, la loro esecuzione e la raccolta e valutazione dei risultati.
Sono state proposte numerose strategie; tutte forniscono allo sviluppatore uno schema per il testing e tutte condividono le seguenti caratteristiche generali ([27]).
• Al fine di svolgere un efficace testing, un team di sviluppo software deve condurre un’efficace revisione tecnica formale. In questo modo è possibile eliminare molti errori prima ancora di iniziare la fase di testing.
• Il testing inizia a livello di componente e prosegue “verso l’esterno”
fino all’integrazione dell’intero sistema informatico.
• È opportuno adottare diverse tecniche di testing a seconda del mo- mento in cui ci si trova nel processo di sviluppo.
• Il testing viene condotto dallo sviluppatore e, per grandi progetti, da un gruppo indipendente.
• Il testing e il debugging3sono due attività diverse, ma quest’ultimo deve essere presente in qualunque strategia di testing.
Considerando il processo da un punto di vista procedurale nel contesto dell’ingegneria del software, il testing è in realtà una serie di quattro passi eseguiti in sequenza.
1. Unit testing: prima fase del processo di testing volta a verificare la presenza di errori nei singoli moduli del sistema.
2. Integration testing: i vari moduli, una volta testati, vanno integrati e as- semblati tra di loro. Tale procedura può essere fatta attraverso due me- todologie chiamate strategia incrementale e strategia non incrementale di cui discuteremo nel proseguo.
3. Validation testing: ha l’obiettivo di valutare i criteri di validazione stabiliti durante la fase di analisi dei requisiti fornendo quindi, la garanzia che il software rispetti tutte le specifiche funzionali, operative e prestazionali.
4. System testing: il suo scopo è quello di provare il sistema nel comples- so ovvero di far combinare il software, visto a tale livello come un unico pacchetto, con gli altri elementi del sistema, quali hardware, persone, database. Si verifica in questo modo il soddisfacimento delle prestazioni e delle funzionalità globali del sistema.
Con l’avvento dell’object-oriented alla stessa strategia di test vennero applicati approcci diversi. Pressman (vedi [27]) propone la seguente proce- dura.
3Ha come obiettivo primario quello di correggere gli errori scovati durante la fase di test.
Può essere visto quindi come una conseguenza di tale fase.
