Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
FACOLTÀ DI INGEGNERIA
CORSO DI LAUREA IN INGEGNERIA INFORMATICA
Tesi di Laurea Magistrale
Fault detection e isolation per sistemidomotici
Candidato Relatore
Mariano Leva Ing. Leonardo Querzoni
Correlatore
Dott. Adriano Cerocchi
Anno Accademico 2010/2011
Sacrificio, tenacia, leggerezza e passione.Alla mia famiglia.
i
Indice
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 Modello di un sistema domotico 43
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
Elenco delle figure
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.3 Un esempio di modello per la programmazione ad eventi. . 54
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
6.4 Il sequence diagram riguardante l’isolamento di un singolo
guasto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
vi
Elenco degli algoritmi
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
Abstract
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
1Introduzione
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 p2 non 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
CAPITOLO 1. INTRODUZIONE 3
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?
CAPITOLO 1. INTRODUZIONE 4
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
CAPITOLO 1. INTRODUZIONE 5
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
CAPITOLO 1. INTRODUZIONE 6
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.
2I 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
CAPITOLO 2. I CONCETTI FONDAMENTALI 8
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
CAPITOLO 2. I CONCETTI FONDAMENTALI 9
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.
CAPITOLO 2. I CONCETTI FONDAMENTALI 10
• 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
CAPITOLO 2. I CONCETTI FONDAMENTALI 11
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).
CAPITOLO 2. I CONCETTI FONDAMENTALI 12
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
CAPITOLO 2. I CONCETTI FONDAMENTALI 13
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.
CAPITOLO 2. I CONCETTI FONDAMENTALI 14
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.
CAPITOLO 2. I CONCETTI FONDAMENTALI 15
• 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
CAPITOLO 2. I CONCETTI FONDAMENTALI 16
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
CAPITOLO 2. I CONCETTI FONDAMENTALI 17
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.
3Stato 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
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 19
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
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 20
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
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 21
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
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 22
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
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 23
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
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 24
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
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 25
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.
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 26
• 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
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 27
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
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 28
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.
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 29
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 terminazione 2 (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.
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 30
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.
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 31
• È 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 debugging3 sono 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.
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 32
Quando si “testa in piccolo” dall’interesse per il singolo modulo (la visione
convenzionale) si passa a focalizzare l’attenzione sulla classe, che compren-
de attributi e operazioni, ed implica comunicazioni e collaborazioni. A mano
a mano che le classi vengono integrate in un architettura object-oriented,
vengono eseguiti una serie di regression test per individuare gli errori dovuti
alle comunicazioni e collaborazioni fra le classi ed i side effect provocati dal-
l’aggiunta di nuove classi. Infine l’intero sistema viene testato per garantire
l’individuazione degli errori rispetto ai requisiti.
Al termine dei test d’integrazione, una volta messi alla prova tutti i singoli
componenti, correggendo tutti gli errori d’interfacciamento, il software vie-
ne completamente assemblato in un pacchetto. Ora, inizia la validazione del
sistema e da questo punto in poi, la distinzione fra software convenzionale
e object-oriented scompare.
3.3.1 Le diverse tipologie di test
Segue, una breve panoramica sulle classi di test, enunciate precedente-
mente, che entrano in gioco durante il processo di testing di un’applicazione.
Unit testing. Ha come obiettivo la verifica della più piccola unità di proget-
tazione software: il componente o il modulo. Vengono collaudati i principali
cammini di controllo per rilevare gli errori interni al modulo stesso. Aspetto
cruciale è la selezione dei cammini di esecuzione.
I test case devono mirare a scoprire errori causati da calcoli e confronti
errati o da anomalie del flusso di controllo. Vengono percorsi tutti i cammini
indipendenti della struttura di controllo, per garantire che tutte le istruzione
contenute nel modulo siano eseguite almeno una volta. Vengono provati
tutti i cammini per la gestione degli errori, vengono esaminate le strutture
di dati locali e viene provato il flusso dei dati attraverso l’interfaccia del
modulo.
Uno dei più importanti compiti di tale testing è la verifica dei casi limiti
(boundary test) ([27]). Spesso, gli errori si verificano quando viene elaborato
l’n-esimo elemento di un array di dimensione n, o quando viene svolta
l’i-esima iterazione di un ciclo di i passi. In pratica quindi, questi test con-
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 33
trollano cosa accade quando vengono incontrati i valori minimi o massimi
consentiti.
Poiché un modulo non è un programma a se stante, per ciascun test dovran-
no essere sviluppati moduli driver e stub. Pressman offre un ottima visione
di tali concetti. Il driver non è altro che un “programma principale” che
accetta i dati dei test case, passa tali dati al modulo in esame e stampa i
risultati rilevanti. Gli stub costituiscono i moduli gerarchicamente inferiori
(ossia richiamati) al componente in esame. Uno stub utilizza l’interfaccia del
modulo gerarchicamente inferiore, stampa una verifica del punto d’ingresso
e restituisce il controllo al modulo che si sta testando.
Nel software object-oriented cambia il concetto delle unità. L’elemento
principale dello unit testing è la classe e le operazioni svolte all’interno
della classe sono le più piccole unità delle quali è possibile eseguire un
testing. Poiché una classe può contenere varie operazioni ed una particolare
operazione, grazie al concetto dell’ereditarietà, può esistere in più classi,
è necessario ripetere il test dell’operazione in ognuna delle sottoclassi. A
differenza dello unit testing del software convenzionale, che tende a concen-
trarsi sui dettagli algoritmici di un modulo e sui dati che né attraversano
l’interfaccia, il testing delle classi per il software object-oriented è guidato
dalle operazioni incapsulate dalla classe e dal comportamento della classe
in termini di stati ([27]).
Integration testing. L’obiettivo è quello di costruire la struttura del pro-
gramma stabilita in fase di progetto, partendo da moduli che sono stati
testati singolarmente. Come detto in precedenza, esistono due tipi di strate-
gie ([27]).
La strategia non incrementale prevede un integrazione del prodotto finale
fatta componendo in unico step tutti i moduli costituenti il sistema. Cor-
reggere gli errori in questo caso risulta un compito arduo a causa della
loro difficile localizzazione all’interno del programma (che avrà dimensioni
notevoli).
La strategia opposta, quella incrementale, è senza dubbio migliore per
quanto riguarda la localizzazione e la correzione degli errori. Esistono due
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 34
importanti strategie d’integrazione incrementale:
1. Top-down. L’integrazione viene realizzata partendo dal modulo princi-
pale di controllo e spostandosi verso il basso incorporando man mano
le strutture più annidate ossia gerarchicamente inferiori. Durante tale
aggregazione si può procedere in modo depth-first ovvero in profondità
oppure in modo breadth-first ovvero in ampiezza.
2. Bottom-up. L’integrazione inizia la costruzione e i test dai moduli
atomici e procede verso l’alto.
Vantaggi e svantaggi di queste due metodologie esulano dagli scopi di
tale trattazione e si invita pertanto il lettore interessato a consultare [27].
Ogni volta, che nel corso dei test di integrazione, si aggiunge un nuovo
modulo, il software cambia. Si formano nuovi cammini del flusso di da-
ti, nuove operazioni di input/output vengono aggiunte e si richiamano
nuovi blocchi logici di controllo. Queste modifiche possono far apparire
dei problemi nelle funzioni che in precedenza funzionavano correttamente.
Il regression testing consiste nell’eseguire alcuni test già condotti al fine di
garantire che le modifiche non abbiano prodotto effetti indesiderati. Esiste
la possibilità di poter effettuare i test manualmente, rieseguendo una parte
dei test oppure attraverso strumenti automatici. Tali strumenti permettono
di registrare test case e risultati e di riprodurli in seguito.
L’insieme di test da eseguire contiene tre classi diverse di test case ([27]):
• un campione rappresentativo di test che tocchino tutte le funzioni del
software;
• test supplementari mirati alle funzioni toccate dalla modifica;
• test mirati ai componenti modificati.
Siccome non è il massimo della praticità rieseguire i test ogni qual volta
che una funzione cambia, è opportuno svolgere tale attività solo per funzioni
principali del programma e con test che comprendono una o più classi di
errore.
Esiste anche un approccio di testing, chiamato smoke testing utile quando si
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 35
devono sviluppare prodotti software in “breve tempo”. Per non dilungarci
troppo su tale argomento si invita, chi fosse interessato, a consultare [27].
Per quanto riguarda i software object-oriented gli approcci top-down e
bottom-up risultano poco significativi a causa della mancanza di un struttura
di controllo gerarchica ben definita. In questo caso si usano due diverse
strategie([27])):
1. Testing basato su thread: integra l’insieme di classi necessarie per ri-
spondere ad un input o ad un evento del sistema. Ogni thread viene
integrato e testato singolarmente e per garantire che non si verifichino
side effect vengono applicati dei test di regressione.
2. Testing basato su uso: inizia con la costruzione del sistema testando
quelle classi (chiamate classe indipendenti) che usano poche (meglio
nessuna) classi server. Dopo aver testato le classi indipendenti viene
testato il livello di classi successivo (le classi dipendenti). Questa se-
quenza di testing di classi dipendenti procede fino a realizzare l’intero
sistema.
Validation testing. Come già preannuciato, una volta che il software
è stato completamente assemblato in un pacchetto non esiste più alcuna
distinzione tra i diversi paradigmi di programmazione.
La validazione deve assicurarsi che il sistema funzioni secondo le aspettative
del cliente. In altre parole, ha il compito di validare il sistema attestando che
quest’ultimo rispetti le Specifiche dei Requisiti Software.
È virtualmente impossibile per uno sviluppatore prevedere come il cliente
realmente utilizzerà l’applicativo. Le istruzioni per l’uso possono essere
fraintese, possono essere usate regolarmente strane combinazioni di dati,
risultati apparentemente chiari per chi ha eseguito il test possono risultare
incomprensibili al cliente ([27]). A tal fine, si conducono una serie di aceptance
test (test di accettazione) per consentire al cliente di validare tutti i requisiti.
Nel caso si abbia a che fare con un numero di clienti elevato, eseguire il
test di accettazione per ognuno di essi potrebbe essere impraticabile per
motivi di tempo oppure per problemi del cliente. La soluzione in questi casi
si chiama alfa e beta testing.
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 36
• Il testing alfa è condotto dal cliente ma presso il luogo di sviluppo.
Il software viene utilizzato dal cliente in modo normale, sotto il con-
trollo dello sviluppatore, e vengono annotati gli errori e gli eventuali
problemi d’uso riscontrati.
• Il testing beta è condotto presso gli utenti finali. In questo caso il test
è eseguito in un ambiente non “controllato”. Il cliente annota tutti i
problemi (reali o supposti) riscontrati e li comunica allo sviluppatore
a intervalli regolari.
System testing. Comprende un insieme di test ognuno dei quali è neces-
sario per verificare la correttezza del sistema software creato. Quest’ultimo
passo esce dai confini dell’ingegneria del software pur rimanendo nel più
ampio confine dei sistemi informatici. L’intento primario è quello di prova-
re l’intero sistema informatico, facendo interagire il software con gli altri
componenti quali ad esempio hardware e informazioni. Pressman in [27]
individua i seguenti tipi di test:
• Recovery testing: ha lo scopo d’indurre in errore il software per verifica-
re la correttezza del recupero.
• Security testing: cerca di verificare che i meccanismi di sicurezza co-
struiti all’interno del sistema lo proteggano da usi impropri. Durante
tale testing chi esegue il test gioca il ruolo dell’individuo che voglia
accedere al sistema.
• Stress testing: sono progettati per provare i programmi in situazioni di
eccessivo carico. Gli stress test forzano il sistema a richiedere risorse in
quantità, frequenza o volumi eccessivi. Fondamentalmente chi esegue
i test cerca di far cadere il programma. Una variante è la tecnica del
“sensivity test”in cui si cerca di rilevare quali sono le combinazioni di
dati che, pur essendo validi dati di input, possono causare instabilità
od elaborazioni non appropriate.
• Performance testing: ha lo scopo di provare le prestazioni del software.
Tale tipo di test viene eseguito in tutti i passi del processo di testing,
tuttavia, le vere prestazioni di un sistema possono essere accertate
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 37
soltanto quando tutti gli elementi del sistema sono stati integrati. I
performance test sono frequentemente associati agli stress test e spesso
richiedono strumentazione hardware e software ad hoc.
3.3.2 Le tecniche di test
Segue una breve trattazione delle tecniche di test che permettono di
realizzare le strategie prima introdotte. Per approfondimenti consultare [27]
cap.16. Possiamo suddividere le tecniche di test in due grandi classi: test
umano, ovvero che non fa uso del calcolatore e test al calcolatore. All’interno
della prima classe troviamo ispezioni e walkthrough.
Il prodotto oggetto di controllo viene esaminato da un gruppo di tre-cinque
persone, fra cui anche il programmatore. Quest’ultimo con il resto del team,
che tipicamente ha visionato il programma già in precedenza, commenta
linea per linea, la logica dell’applicativo e attraverso una lista degli errori
più comuni viene simulata l’esecuzione del prodotto con un insieme di dati
per esso significativi. Brykczynski propone, in [7] un’estesa panoramica su
le varie cheklist esistenti, una loro classificazione e un’analisi degli elementi
in esse contenute dando dei consigli su cosa evitare di inserire al loro interno.
L’altra classe di test può essere a sua volta suddivisa in test white-box e
test black-box.
Il testing white-box è un metodo che sfrutta la struttura del controllo definita
nel design a livello di componenti per ricavare i test case. I cammini logici
all’interno del software sono testati tramite test case che esercitano insiemi
specifici di condizioni e di cicli. Adottando metodi di questo tipo si possono
ricavare test case con le seguenti caratteristiche ([27]:
• garanzia che tutti i cammini indipendenti4 dentro un modulo siano
eseguiti almeno una volta
• esecuzione dei rami vero e falso per ogni decisione logica
4Un cammino è indipendente quando introduce una nuova condizione o un nuovo
insieme di istruzioni ovvero quando in un flow graph attraversiamo almeno un arco non
percorso prima di definire il cammino in questione
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 38
• esecuzione di tutti i cicli nei casi limite ed entro i confini operativi
• uso di tutte le strutture dati interne per garantirne la validità
I metodi black-box chiamati anche testing del behaviour, si concentrano
sui requisiti funzionali del software. Mirano cioè, a produrre un insieme di
condizioni di input tali da testare tutte le funzioni di cui il sistema è dotato.
Un testing black box rileva errori compresi nelle seguenti categorie ([27]):
• funzioni errate o mancanti
• errori d’interfaccia
• errori nelle strutture dei dati o negli accessi a database esterni
• errori di comportamento o prestazionali
• errori di inizializzazione e terminazione.
Nei riferimenti sopra citati vengono esposti nel dettaglio tutte le tecniche
utilizzate da queste due classi di test al calcolatore, che in tale lavoro non
vengono approfonditi. Troviamo, in particolare, test dei cammini di base,
testing per condizioni, data flow testing, testing dei cicli, tecnica di coper-
tura delle classi di equivalenza e delle funzionalità, tecnica di analisi dei
valori estremi, testing ad array ortogonale nonché i metodi di testing object-
oriented tra cui il testing fault-based e il testing delle strutture di superficie
e delle strutture profonde, il testing casuale per classi object-oriented e per
finire, il testing a partizionamento a livello della classe.
3.4 FDI nel settore domotico
La domotica è la scienza interdisciplinare che si occupa dello studio delle
tecnologie atte a migliorare la qualità della vita nella casa e più in generale
negli ambienti antropizzati. Il termine domotica fa la sua prima apparizione
in Francia attraverso la parola domotique. Questa deriva dal latino domus che
significa casa a cui va aggiunto il termine informatique (informatica).
La domotica è nata nel corso della terza rivoluzione industriale con lo scopo
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 39
di sfruttare tutta una serie di tecnologie, come ad esempio le interfacce
amichevoli e i dispositivi mobili/wireless, per garantire:
• maggiore comfort
• maggiore sicurezza
• risparmio energetico
• divertimento
• controllo remoto
• maggiore indipendenza, soprattutto per persone disabili e anziani.
Il progetto SM4LL, per cui è stato sviluppato tale lavoro di tesi si inseri-
sce in tale contesto.
Oggigiorno i sistemi embedded sono presenti ovunque (automobili, elet-
trodomestici, sistemi di comunicazione etc.) e tale pervasività è evidente
soprattutto in scenari “immersivi” dove interagiscono con utenti umani per
fornigli le informazioni acquisite e per reagire alle loro richieste di servizio.
Come si evince dal sito del progetto ([15]), questo ha lo scopo di studiare
e sviluppare una piattaforma middleware per la cooperazione di servizi
embedded intelligenti in scenari “immersivi” attraverso l’uso di tecniche
semantiche e di composability al fine di garantire requisiti di:
• dinamicità: sensori e servizi non sono più statici, come nelle reti classi-
che, ma hanno bisogno di adattarsi sulla base del contesto utente
• scalabilità: il sistema dovrà far fronte al numero sempre più elevato di
sensori, dispositivi e applicazioni esistenti.
• dependability: l’utente, al centro del sistema, deve potersi fidare del-
l’ambiente circostante e pertanto quest’ultimo deve essere altamente
affidabile.
• sicurezza e privacy: l’utente deve poter interagire con un ambiente sicuro
e la sua privacy deve essere protetta (questo è un aspetto cruciale
soprattutto per utenti disabili o che hanno qualche malattia).
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 40
Il sistema naturalmente deve poter essere usato da utenti con diverse
abilità e bisogni (normodotati, disabili, anziani).
La domotica è un settore molto recente la cui conseguenza si rispecchia
in una letteratura “povera” di soluzioni che affrontano il problema del rile-
vamento e dell’isolamento di guasti.
Nell’ambito del progetto SM4ALL una soluzione viene proposta da Degeler
e Lazovik in [10].
Gli autori hanno ideato un meccanismo, adatto a sistemi pervasivi context-
aware, per venire a conoscenza dei possibili stati dell’ambiente processando
le informazioni ottenute dai vari sensori. In particolare, viene usato un ap-
proccio probabilistico per ragionare circa la probabilità di ogni particolare
situazione e variabile (esempi di variabili in un contesto domotico sono la
luce, l’elettricità, la tv, il volume della tv etc..).
Le principali attività di un sistema pervasivo context-aware riguardano la
collezione di informazioni acquisite dai sensori, il trasferimento di tali dati
al sistema middleware, responsabile della loro analisi ovvero della creazio-
ne di una interpretazione consistente dell’ambiente e l’utilizzo di queste
informazioni da parte di applicazioni di alto livello.
Le inconsistenze all’interno dell’ambiente possono verificarsi perché i dati
provenienti dai sensori sono spesso affetti da rumore e quindi imprecisi.
Inoltre, a causa della natura asincrona del processo di lettura dei dati dei
sensori l’ordine di arrivo delle informazioni può essere diverso dall’ordine
di acquisizione. Ultimo, ma non meno importante, gli errori e quindi le
incosistenze possono essere introdotti dagli stessi algoritmi di ragionamento
sul contesto.
Il “context consistency diagrams” (CCD) è una struttura dati usata per otte-
nere la probabilità delle varie interpretazioni di contesto5 che può essere
efficientemente mantenuta e interrogata real-time.
La Fig. 3.6 mostra l’architettura utilizzata a tale scopo.
Al primo livello troviamo i dispositivi fisici, i sensori, che monitorano l’am-
biente circostante raccogliendo dati in continuazione. Tali dati, vengono
5valutazione di tutte le variabili dell’ambiente con un dominio non vuoto
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 41
Fig. 3.6: Architettura che utilizza i CCD per il ragionamento sui contesti
poi pre-processati attraverso una serie di regole. In figura, ad esempio, al
data acquisito TVsound=max viene applicata la regola TV sound = max→TV channel ∈ sports, shows. I dati così analizzati vengono passati al CCD,
responsabile del loro storage, di risolvere le inconsistenze, rispondere alle
query e attivare gli eventi delle applicazioni sottoscritte del livello superiore.
Le domande a cui il CCD è in grado di rispondere sono: la probabilità che
una particolare situazione sia vera, la probabilità che una variabile ha un
certo valore e la probabilità condizionale, ovvero la probabilità che una
variabile ha un certo valore condizionata al fatto che un’altra variabile ha
un valore conosciuto a priori.
Il CCD non è altro che una rappresentazione compatta di tutte le possibili
interpretazioni dell’ambiente; è un albero i cui nodi sono rappresentati dai
contesti con gli archi che stanno ad indicare una relazione d’inclusione. La
radice invece, rappresenta un contesto in cui ogni situazioni è possibile.
CAPITOLO 3. STATO DELL’ARTE NELLA FDI 42
Un CCD è inconsistente se non esiste un unica interpretazione6 confermata
da tutti i dati in possesso. Tale struttura opera assegnando una certa pro-
babilità di verità ad ogni blocco di dati in arrivo, compensando in questo
modo, anche gli effetti di informazioni errate dedotte da un sensore guasto.
Tralasciando il dettaglio del calcolo delle probabilità, anche se un parti-
colare contesto non supporta l’interpretazione “più popolare” esso viene
comunque memorizzato all’interno del context consistency diagrams poiché,
potrebbe divenire il più probabile con la successiva acquisizione di nuovi
dati.
6Si ha un’interpretazione quando tutte le varibili dell’ambiente sono assegnate a uno ed
un solo valore
4Modello di un sistema domotico
Tale capitolo tratterà la descrizione dei due principali modelli riguardan-
ti tale lavoro di tesi: il modello di sistema e il modello di guasto.
Nella caratterizzazione del primo, verranno definiti in modo formale,
tutti i componenti in gioco. Si partirà da un contesto specifico quale il settore
domotico, esibendo un opportuno modello per i suoi principali componenti
(le reti di sensori e attuatori), fino ad arrivare ad una sua generalizzazio-
ne applicabile anche in settori diversi. Verranno quindi definiti i concetti
di grafo azione-reazione, modulo, manager e semantica del linguaggio. Si
approfondirà successivamente lo studio del linguaggio, soffermandosi in
particolare sulle semantiche booleane. Verrà esposta, la semantica utilizzata
dal modello di sistema e i motivi che hanno condotto alla sua scelta met-
tendo in enfasi, per ognuna delle semantiche esistenti, gli elementi di unicità.
Durante la descrizione del secondo modello, verrà fornita una carat-
terizzazione del comportamento di un componente del sistema affetto da
guasto. Spiegheremo quindi le motivazioni a monte di tali assunzioni e
inquadreremo il tipo di guasto anche in riferimento allo schema proposto
da Laprie in [3] e già ampiamente discusso nel capitolo 2.
43
CAPITOLO 4. MODELLO DI UN SISTEMA DOMOTICO 44
4.1 Architettura dei sistemi domotici
Come anticipato, iniziamo la discussione dal nostro settore di riferimen-
to: la domotica. La prima cosa da fare è capire come sono organizzati i
sistemi domotici odierni così da modellarli nel miglior modo possibile.
Attualmente una casa moderna può incorporare diverse tipologie di
rete:
• Rete elettrica (prese, luci, interuttori)
• Rete telefonica
• Rete antenna TV terrestre
• Rete idrica (acqua calda e fredda)
• Rete fognaria (acqua bianche e scure)
• Rete del sistema di allarme
• Rete antenna TV satellitare
• Rete per la diffusione della musica
• Rete locale (calcolatori)
Tutto ciò può portare a numerose connessione cablate, numerosi tele-
comandi, eccessivo inquinamento da radio frequenze. In parole povere, il
sistema risulta di difficile controllo e manutenzione.
La domotica risolve il problema utilizzando un unico mezzo di comunica-
zione, denominato bus, “separato” dalla linea di alimentazione, che opera
a bassa tensione sul quale sono collegati in parallelo tutti i dispositivi (vd.
Fig. 4.1). In questo modo si ottiene una chiara semplificazione rispetto ai
collegamenti tradizionali “punto-punto” e si ha la possibilità di eseguire,
collegamenti tra i dispositivi, in modo dinamico, senza l’aggiunta di ulteriori
fili e senza che questi siano stati previsti in precedenza.
Al bus possono essere collegati vari dispositivi tra i quali sensori e attua-
tori, elettrodomestici, impianti audio-video anche se tutte le varie tipologie
CAPITOLO 4. MODELLO DI UN SISTEMA DOMOTICO 45
(a)
(b)
Fig. 4.1: La figura mostra la differenza tra il collegamento punto-punto (4.1(a))
e il collegamento a bus (4.1(b)) previsto da una soluzione domotica . Immagini
tratte da [4]
.
CAPITOLO 4. MODELLO DI UN SISTEMA DOMOTICO 46
esistenti che vi connettiamo possono ricadere in un comportamento attuati-
vo o percettivo.
Gli attuatori saranno in grado di comandare dispositivi come serrande, luci,
ventilatori. A loro volta gli attuatori possono essere comandati da pulsanti,
interruttori, sistemi ad infrarossi, fotocellule. Così un pulsante potrà dire ad
una lampadina di accendersi e l’attuatore associato comunicherà al disposi-
tivo di comando l’avvenuta accensione.
Quindi, un attuatore si può considerare come un relè dove ad esso arriva la
linea di potenza mentre il comando è quel circuito di bassa potenza che serve
a comandare il relè. Con questo tipo di impianto si semplifica notevolmente
il circuito soprattutto per il numero di fili conduttori.
Essenzialmente nel bus vengono trasmessi messaggi ovvero piccoli pac-
chetti di informazione di varia natura, per il controllo del sistema. Questi
possono essere distinti in comandi da eseguire, segnali di allarme, segnali
per il riconoscimento dei dispositivi (utili soprattutto nella fase di start-up
del sistema), segnali di conferma delle azioni eseguite o non eseguite (i co-
muni ACK e NACK), segnali di stato e così via. Questi sono solo i principali
ma dipendentemente dai protocolli di comunicazione utilizzati la lista può
diventare molto lunga.
Così come esistono vari protocolli di comunicazione si utilizzano anche
diversi tipi di mezzi trasmissivi. Tali concetti non saranno argomento di ap-
profondimento dato che non risultano essenziali ai fini della modellazione.
I più utilizzati sono:
• Onde Convogliate (PL-Power line). Onde trasmesse attraverso la rete
elettrica 220 volt.
• Doppino in rame (TP-Twisted pair). Cavo bipolare intrecciato
• Cavo coassiale (CX-Coaxial cable).
• Fibra ottica (OF-Optical Fiber).
• Radio frequenza (RF-Radio frequency).
• Raggi infrarossi (IR-Infra-red rays).
CAPITOLO 4. MODELLO DI UN SISTEMA DOMOTICO 47
Chiaramente un sistema a radiofrequenza o un sistema a raggi infrarossi
non utilizza un vero e proprio bus ma comunque possiamo ritenere che
abbia la sua stessa funzione ovvero quella di far transitare i messaggi.
Questa eterogeneità riguardante i numerosi standard di comunicazione
esistenti, sta di fatto alla base del mancato sviluppo della domotica.
4.2 Un modello di sistema specifico
Un’architettura del genere è stata modellata con un grafo azione-reazione,
detto anche ARG (acronimo inglese di action reaction graph), dove la com-
binazione di termini azione e reazione indica che nel sistema a fronte di
un’azione corrisponde sempre una determinata reazione.
La casa domotica, costituita da un insieme di stanze, verrà modellata da un
insieme di modelli, uno per ogni stanza. I principi alla base della costruzione
del modello sono identici qualunque sia la stanza. Per questo motivo, data
la mancanza di differenze, quando parleremo di modello del sistema ci rife-
riremo sempre alla stanza singola, certi di poter estendere il ragionamento
all’intera casa semplicemente attraverso una iterazione del procedimento,
applicata alle varie stanze.
Il nostro sistema pervasivo è costituito da un insieme Ω di dispositivi ω
(Ω =⋃
i ωi). Questi potranno essere di due sole tipologie: attuatori (ωa) e
sensori (ωs). Quindi, se esiste un qualche dispositivo complesso contenente
all’interno k attuatori e i sensori, esso verrà mappato nel sistema come k + i
dispositivi indipendenti.
Gli attuatori sono quei dispositivi in grado di compiere un’azione (accen-
dere luce, azionare tapparelle, chiudere porte). I sensori invece, sono quei
dispositivi che reagiscono a un’azione compiuta. Un sensore di luce rileverà
un incremento di intensità luminosa a seguito dell’accensione di una lam-
padina, un sensore di rumore rileverà una variazione di tale grandezza a
seguito dell’accensione dell’impianto stereo e così via.
Ogni dispositivo ωi può modificare o misurare una o più grandezze
CAPITOLO 4. MODELLO DI UN SISTEMA DOMOTICO 48
fisiche δi1. Attraverso lo studio dei principali dispositivi esistenti e dei
servizi offerti dalle maggiori aziende leader nel settore, abbiamo rilevato
una serie di grandezze fisiche δi d’interesse. Tale insieme, indicato con ∆,
contiene luce, temperatura, tempo, perimetro, rumore, flusso elettrico, flusso
d’aria, e flusso di gas.
Un altro modo con cui possiamo caratterizzare i dispositivi presenti nel
sistema è attraverso la nozione di domini di compatibilità. Ogni grandezza
ne possiederà uno così da poter elencare tutti i dispositivi presenti tramite
l’unione di tutti i domini di compatibilità esistenti.
Definizione 1 (Dominio di Compatibilità) Un dispositivo ω appartiene a un
dominio di compatibilità Ω(δi) se e solo se modifica o misura δi.
Indicando il dominio di compatibilità di una grandezza fisica δ con Ω(δ),
l’insieme totale dei dispositivi è pari a Ω =⋃
i Ω(δi) ∀i ∈ ∆.
Possiamo dividere ulteriormente un dominio di compatibilità in due insiemi
che vanno a partizionarlo: l’insieme degli attuatori e l’insieme dei sensori
che indicheremo rispettivamente come Ωa(δ) e Ωs(δ).
A sua volta avremo che l’insieme degli attuatori sarà formato da tutti quei
dispositivi di tipo attuativo che vanno a modificare la grandezza fisica
d’interesse (Ωa(δi) =⋃
k ωak(δi)) mentre l’insieme dei sensori conterrà tutti i
dispositivi che misurano tale grandezza (Ωs(δi) =⋃
k ωsk(δi)). Riassumendo
possiamo dire che:
Ω =⋃i
Ω(δi) =⋃i
(Ωa(δi) ∪ Ωs(δi)) =⋃i
[(⋃k
ωak(δi)) ∪ (
⋃k
ωsk(δi))] ∀i ∈ ∆
(4.1)
In un sistema, caratterizzato da dispositivi di così diversa natura, solo
una parte di essi potrebbe essere utile alla rilevazione e all’isolamento di
un particolare guasto. Un sensore di rumore, non sarà utile a diagnosticare
il funzionamento corretto di una lampadina mentre è utile a diagnosticare
guasti presenti negli altoparlanti responsabili del sistema audio della casa.
Diremo che il sensore di luce e la lampadina sono due dispositivi compatibili,
mentre il sensore di rumore e la lampadina sono due dispositivi incompatibili.1Gli attuatori le modificano e i sensori le misurano
CAPITOLO 4. MODELLO DI UN SISTEMA DOMOTICO 49
Dietro tale affermazione è celato un concetto che è bene iniziare ad esporre.
In questo lavoro, presenteremo un protocollo collaborativo, che tenendo
conto della eterogeneità dei dispositivi presenti, sarà in grado di rilevare ed
isolare i guasti interagendo con il solo sottoinsieme d’interesse.
É l’eterogeneità che complica il problema di FDI. Un approccio alla riso-
luzione di tali problemi in sistemi omogenei è presentato da Lamport et
all in [22]. L’articolo in questione affronta il problema dell’affidibilità dei
sistemi astraendolo alla decisione di attacco o ritirata fatta da un gruppo di
generali (alcuni dei quali disonesti) accampati attorno a una città nemica.
L’unico modo che hanno i generali di comunicare è attraverso lo scambio di
messaggi. Senza entrare nel dettaglio, vengono descritti vari algoritmi tra
cui uno che fa uso di messaggi orali e uno di messaggi firmati.
Definizione 2 (Dispositivi compatibili) Due dispositivi ω1 e ω2 sono compa-
tibili se modificano o misurano la stessa grandezza fisica δi ovvero se (ω1 ∧ ω2) ∈Ω(δi).
Il sistema in questione viene rappresentato tramite grafi azione-reazione
in modo da avere anche un adeguato supporto visivo.
Un ARG è un grafo diretto, in cui i nodi rappresentano i sensori e gli attuatori
del sistema mentre esiste un arco tra due nodi se questi saranno collegati
da una relazione azione-reazione. In tal caso l’arco sarà sempre diretto
dall’attuatore al sensore per indicare che il sensore è sempre in grado, a
meno di guasti, di rilevare l’azione eseguita dall’attuatore.
In modo formale, diremo che il sistema può essere descritto mediante un
grafo diretto G = (N,E) in cui N = Ω e l’arco diretto e1e2 ∈ E se e solo se
e1 è un attuatore e2 è un sensore ed e1, e2 sono compatibili (definizione 2).
4.2.1 La modellazione di uno scenario reale
Cerchiamo di rendere tutto più chiaro tramite degli esempi. Immaginia-
mo di avere nella stanza della nostra casa domotica i seguenti dispositivi:
• tre lampadine che indicheremo con le lettere L1, L2, L3
• un voltmetro V1 associato alla lampadina L1
CAPITOLO 4. MODELLO DI UN SISTEMA DOMOTICO 50
• un voltmetro V2 associato alla lampadina L3
• un sensore di luminosità SL1
• una serranda S1
• un sensore di rumore NS1
• un fine corsa FC1 associato alla serranda S1
Nel modellare la stanza avremo un grafo azione-reazione G = (N,E)
in cui l’insieme dei nodi sarà costituito da tutti i dispositivi esistenti. Gli
archi invece, verranno determinati suddividendo i dispositivi in attuatori e
sensori e stabilendo quali sensori reagiranno sempre alle azioni di un dato
attuatore.
Accendendo la lampadinaL1, in assenza di guasti il sensore di luce SL1 deve
rilevare la variazione d’intensità luminosa, mentre il voltmetro V1, in assenza
di altri dispositivi accesi ad esso connessi, deve rilevare una variazione di
tensione. Sulla base di tale osservazione inseriremo nel grafo gli archi L1SL1
e L1V1. Lo stesso discorso si può ripetere con la lampadina L3, il voltmetro
V2 e il sensore di luce formanti due ulteriori archi L3V2 e L3SL1. L’apertura
della serranda, produrrà rumore che verrà rilevato dal sensore di rumore
NS1 e azionerà il fine corsa FC1. Questo verrà rappresentato tramite gli
archi S1NS1 e S1FC1. Avremo quindi:
• N = (L1, L2, L3, V1, V2, SL1, S1, NS1, FC1)
• E = (L1SL1, L1V1, L2SL1, L3SL1, L3V2, S1NS1, S1FC1)
Il grafo risultante è mostrato in figura 4.2.
Otteniamo un grafo bipartito2, anche se orientato, e tale topologia caratte-
rizza tutti i sistemi di reti di sensori e attuatori. Il motivo si ritrova nell’unico
modo in cui si può orientare un arco, che per le regole di costruzione, sarà
sempre diretto da un attuatore a un sensore. Non possiamo quindi avere
2Grafo non orientato tale che l’insieme dei suoi vertici si può partizionare in due
sottoinsiemi in cui ogni vertice di una di queste due parti è collegato solo a vertici dell’altra.
CAPITOLO 4. MODELLO DI UN SISTEMA DOMOTICO 51
Fig. 4.2: Un esempio di modellazione di una stanza avente tre lampadine L1, L2,
L3, due voltmetri V1, V2, un sensore di rumore NS1, una serranda S1 e un fine
corsa FC1. Immagine creata con [21]
archi che collegano nodi appartenenti ad una stessa partizione.
Gli attuatori e i sensori costituiranno quindi i due insiemi in cui sarà parti-
zionato il grafo.
Se volessimo, invece caratterizzare il sistema attraverso i domini di
compatibilità avremmo un insieme ∆ formato da quattro grandezze fisi-
che fondamentali: luce, perimetro, flussi elettrici e rumore. I domini di
compatibilità contengono a loro volta:
• Ω(δluce) = Ωa(δluce) ∪ Ωs(δluce) = (L1, L2, L3, SL1)
• Ω(δperimetro) = Ωa(δperimetro) ∪ Ωs(δperimetro) = (S1, FC1)
• Ω(δrumore) = Ωa(δrumore) ∪ Ωs(δrumore) = (S1, NS1)
• Ω(δfl.elettrico) = Ωa(δfl.elettrico) ∪ Ωs(δfl.elettrico) = (L1, L2, L3, S1, V1, V2)
Come già detto in precedenza, l’unione di tutti i domini di compatibilità
così ottenuti dà l’insieme dei dispositivi presenti nella stanza.
4.3 Un modello di sistema generale
Amplieremo in questa sezione il modello di sistema introdotto preceden-
temente, andando ad abbandonare la nozione di domini di compatibilità,
troppo specifici dato il loro forte accoppiamento con il concetto di grandezza
CAPITOLO 4. MODELLO DI UN SISTEMA DOMOTICO 52
fisica. Gli attuatori e i sensori verranno sostituiti dal concetto più genera-
le di modulo e costituiranno i nodi del grafo azione-reazione. Gli archi tra
i moduli verranno stabiliti con identici criteri ma subiranno un ulteriore
arricchimento grazie all’accoppiamento con la nozione di semantica.
Si introdurrà il concetto di linguaggio utile per definire la relazione azione-
reazione esistente nel sistema. In questo modo, potremmo “potenzialmente”
costruire un nuovo linguaggio ogni qual volta ci troveremo di fronte alla
necessità di rappresentare nuove “regole” azione-reazione.
L’ultimo elemento costituente il sistema è il manager, il quale, mostrerà tutta
la sua utilità successivamente, durante lo studio degli approcci risolutivi al
problema del rilevamento e isolamento dei guasti.
Il tutto sarà riassunto per mezzo di esempi che riprenderanno quello domo-
tico fatto nel paragrafo precedente e abbracceranno anche altri campi.
Definizione 3 (Modulo) É un entità in grado di svolgere una qualche attività
osservabile dall’esterno indipendentemente dagli altri moduli. Il suo stato è descritto
da un’apposita variabile i cui valori ammissibili dipendono dalle “capacità” del
modulo stesso.
Un computer appartenete a una rete può essere visto come un modulo
del sistema complesso costituito dagli elementi della rete. Ma, anche una
scheda di rete o una scheda audio di un computer possono essere considerati
moduli del sistema complesso (in questo caso formato dal solo calcolatore).
Nel caso più generale possibile, pensando al mondo dei sistemi distribuiti,
un modulo può essere considerato come un processo generico in grado di
leggere e inviare messaggi da/su una rete di comunicazione. Il tutto dipende
dalla granularità dei guasti che vogliamo scoprire.
Se ripensiamo al settore domotico in cui le applicazioni sono costituite da reti
di sensori e attuatori, possiamo caratterizzare il modulo come un dispositivo
costituito da un componente fisico (il sensore ad esempio contiene al suo
interno un trasduttore) e da un software di controllo. Tutti i dispositivi sono
connessi da uno strato di rete (il bus o un diverso standard di comunicazione)
che permette ai vari moduli software di comunicare con il manager, il
componente centrale che si occupa di rilevare ed isolare i guasti.
CAPITOLO 4. MODELLO DI UN SISTEMA DOMOTICO 53
I moduli, rappresentano i nodi del grafo azione-reazione. Un arco diret-
to tra due moduli A e B, rappresenta la capacità che ha B, di riuscire ad
osservare e a reagire all’azione eseguita da A. Chiaramente, questo concetto
potrà dover essere adattato a seconda delle situazioni. Nel caso in cui A e
B fossero processi l’arco rappresenterebbe la capacità che ha B di ricevere
messaggi da A e così via.
Per ragioni di semplicità assumiamo che ogni modulo può eseguire e perce-
pire una sola azione 3.
Presentiamo un sistema, il cui modello è più generale rispetto a quello
ottenuto precedentemente ovvero ha un grafo azione-reazione diverso dal
grafo bipartito che caratterizza tutti gli scenari costituiti da reti di sensori e
attuatori.
Supponiamo di avere una rete di comunicazione su cui transitano messag-
gi prodotti dai processi A1, A2, B1, e B2. Il protocollo di comunicazione
che questi processi devono rispettare prevede le seguenti azioni: affinché
A1 possa inviare un messaggio ad A2, deve prima ricevere dei particolari
messaggi, contenenti specifici parametri di comunicazione, dai processi B1
e B2.
I due tipi di processi, quelli di classe B, che si occupano di configurare la
“chiamata” e quelli di classe A che invece la effettuano, rappresentano i
moduli del nostro sistema e quindi i nodi del grafo azione-reazione.
Avremo un arco tra il modulo B1 e A1 poiché ogni messaggio trasmesso
da B1 viene ricevuto da A1 ovvero, volendo eseguire un ragionamento
simmetrico alle reti di sensori e attuatori, ogni azione eseguita dall’attuatore
B1 viene percepita dal sensore A1. Per lo stesso motivo avremo archi tra B2
e A1 e tra A1 e A2. L’utlimo arco è così diretto perché abbiamo supposto
una comunicazione unidirezionale da A1 ad A2. Il grafo è rappresentato in
Fig. 4.3.
Definizione 4 (Manager) Rappresenta un punto di vista esterno al sistema. É
una entità in grado di (i) forzare un modulo ad eseguire un’azione ovvero far si che
3si noti che così facendo non si ha alcuna perdità di generalità dato che un nodo capace
di eseguire o “leggere” più azioni può essere mappato all’interno del grafo con più nodi.
CAPITOLO 4. MODELLO DI UN SISTEMA DOMOTICO 54
Fig. 4.3: Un esempio di modello per la programmazione ad eventi.
la variabile di stato assuma un certo valore e (ii) leggere il valore della variabile di
stato che il modulo espone.
In riferimento all’esempio precedente il manager dovrebbe essere in
grado di forzare i processi ad assumere un particolare stato (ad esempio
potrebbe forzare l’invio di uno specifico messaggio) e a leggere lo stato che
essi espongono (ad esempio possono richiedere ad un processo il contenuto
informativo dell’ultimo messaggio processato).
Il manager può interagire con i moduli attraverso due primitive e a seconda
della capacità di utilizzarne una o entrambe verrà detto attivo o passivo:
1. set(s,n): viene imposto lo stato s al nodo n che potrebbe essere il riferi-
mento ad un nodo singolo o a tutti i moduli del sistema, caso in cui n
verrebbe sostituito con la keyword all.
2. read(n): ritorna lo stato dichiarato dal nodo n.
Definizione 5 (Manager passivo e attivo) Un manager è detto passivo se è in
grado di utilizzare solo la primitiva read, altrimenti è detto attivo.
Il manager, proprio grazie a queste primitive, sarà l’entità in grado di
scoprire e isolare i guasti.
CAPITOLO 4. MODELLO DI UN SISTEMA DOMOTICO 55
L’ultimo elemento del modello è il linguaggio. Esso si occupa di definire
la semantica del grafo e più precisamente delle relazioni azione-reazione.
Un linguaggio ϕ viene definito andando a stabilire un dominio D e un
insieme di implicazioni I (ϕ = (D, I)):
1. L’insieme dei valori ammissibili per ogni modulo ovvero tutti i suoi
possibili stati rappresenta il dominio D.
2. L’insieme di implicazioni I caratterizza il corretto comportamento, in
termini di azione-reazione del sistema. Questo è definita mediante una
serie di relazioni che rappresentano le varie implicazioni possibili.
Per ogni sistema che andremo a modellare dovremmo enunciare il lin-
guaggio che lo caratterizza. A seconda dell’insieme dei valori ammessi per
le variabili di stato dei processi, possiamo suddividere i linguaggi in booleani
e non booleani.
Definizione 6 (Linguaggi booleani e non booleani) Un linguaggio e detto
booleano quando le variabili di stato dei moduli hanno un dominio rappresentato
dai soli valori 0,1 altrimenti è detto non booleano.
Per i linguaggi non booleani non esiste alcuna restrizione sul tipo di
dominio, che può essere vuoto, formato da un solo elemento o da più di
uno.
4.3.1 Una panoramica sulle semantiche booleane esistenti
Dato che una variabile booleana può implicare al più il valore 1, 0 o
entrambi, le relazioni booleane producibili e formanti un dato linguaggio
sono finite. Queste però non sono tutte interessanti dal punto di vista teorico;
alcune di esse infatti, sono banali, con soluzioni inerenti il problema della
fault detection and isolation triviali, altre invece risultano essere addirittura
impossibili poiché conducono, in particolari situazioni, a stati affetti sempre
da guasti.
Proponiamo un elenco composto dalle implicazioni booleane che è possibile
trovare all’interno di un linguaggio.
CAPITOLO 4. MODELLO DI UN SISTEMA DOMOTICO 56
• 0 → 0, 1 → 1: in questo caso gli unici due stati privi di guasto del
sistema sono quello in cui tutti i moduli valgono zero oppure quello
in cui tutti valgono uno. Il problema di FDI in tale contesto implica
soluzioni triviali e per tale motivo un linguaggio così fatto non viene
preso in considerazione. Per isolare f guasti basteranno 2f + 1 dispo-
sitivi corretti. Serviranno cioè, un numero di dispositivi dispari su
cui poter applicare una regola di maggioranza. Quindi, per isolare un
guasto serviranno tre moduli. Se lo stato corretto è fatto da tutti zero il
guasto sarà il componente che espone uno e viceversa. Per isolare due
guasti invece, serviranno cinque nodi e il ragionamento per rilevarli
è del tutto identico. Se la relazione non è rispettata possiamo andare
incontro a situazioni in cui non possiamo dire nulla su dove sono
localizzati gli elementi non funzionanti. Esempio: abbiamo due guasti
in un sistema di quattro nodi, con due di questi che hanno valore zero
e due che hanno valore uno. Ebbene, non possiamo capire se sono
guasti i due con valore zero o quelli con valore uno.
• 0→ 0|1, 1→ 0|1: anche questa rappresenta una soluzione triviale. In
tal caso di fatti, qualunque guasto occorra nel sistema un linguaggio
con questo tipo di implicazioni non sarà mai in grado di individuar-
lo. Essendo dotato di tutte le possibili implicazioni esistenti, in una
situazione del genere non verranno a crearsi mai delle inconsistenze
(concetto che verrà ampiamente trattato nel capitolo successivo), ov-
vero non si avranno mai istanti temporali in cui un’implicazione non
viene rispettata.
• 0|1 → 0, 0|1 → 1: questo insieme di implicazioni non viene trattato
perché non permettono un passaggio di stato nei moduli che hanno
almeno un arco entrante. Il passaggio di stato è un concetto fonda-
mentale e di primaria importanza per la rilevazione dei guasti nella
teoria di FDI che andremo a sviluppare. L’utilizzo di linguaggi che
non hanno la possibilità di avere tali comportamenti non risultano
essere d’interesse poiché non sono in grado di rilevare la tipologia di
guasto trattata.
Immaginiamo di avere un arco da A a B con un linguaggio di tipo
CAPITOLO 4. MODELLO DI UN SISTEMA DOMOTICO 57
0→ 0, 1→ 0. Se ad un certo istante di tempo il nodo B espone come
valore della variabile di stato 0, indipendentemente dal valore assunto
negli istanti di tempo successivi, dalla variabile di stato del nodo A, B
non cambierà più stato; non andrà mai a 1. Ciò, come verrà spiegato
nel capitolo su gli approcci risolutivi, inibisce la capacità di eseguire
rilevamento e isolamento dei guasti.
• 0→ 1, 1→ 0: un linguaggio con tali implicazioni, applicato a un grafo
avente un ciclo formato da un numero dispari di nodi, è tale da far
credere alla presenza di un guasto in qualsiasi istante di tempo.
Le uniche semantiche interessanti sono quindi, quelle “miste”, ovvero
quelle in cui a un dato valore di una variabile possono essere implicati più
valori. Sono le seguenti quattro:
1. 0→ 1, 1→ 0|1
2. 0→ 0, 1→ 0|1
3. 1→ 0, 0→ 0|1
4. 1→ 1, 0→ 0|1
Da tale insieme di implicazioni è stato estrapolato il linguaggio che me-
glio si adatta alla realtà sotto monitoraggio. Il linguaggio introdotto successi-
vamente attraverso degli esempi, sarà oggetto di numerosi approfondimenti
nei capitoli successivi.
4.3.2 Scenari rappresentati tramite modello generale
Riprendiamo l’esempio domotico della sezione 4.2 in cui avevamo tre
lampadine, indicate con L1, L2, L3, un sensore di luce SL1, due voltmetri
V1, V2, una serranda S1, un fine corsa FC1 e un sensore di rumore NS1, e
aggiungiamo al grafo azione-reazione risultante il nuovo concetto di lin-
guaggio.
Il grafo risultante ha la stessa struttura ma bisogna aggiungere una variabile
di stato per ogni sensore e attuatore (i moduli) e un insieme d’implicazioni
caratterizzanti il corretto comportamento del sistema.
CAPITOLO 4. MODELLO DI UN SISTEMA DOMOTICO 58
Ogni qual volta l’attuatore attua, il sensore o i sensori ad esso collegati
rilevano il cambiamento del valore di una grandezza fisica nell’ambiente
circostante. Solo a seguito di un’azione è possibile prevedere quale sarà
l’intensità della grandezza fisica percepita dal sensore. Se l’attuatore non va
in funzione la grandezza fisica non può essere conosciuta a priori.
Il linguaggio booleano bene si appresta a modellare tale comportamento.
Ogni modulo ha una variabile di stato i cui valori ammissibili sono 1 per
indicare azione eseguita o percepita e 0 per indicare che l’attuatore e il
sensore non si sono attivati.
Da tale premessa, le implicazioni che definiscono la semantica del sistema
sono:
• 0 → 1|0. Se non agisco su l’attuatore non so che valore i sensori
possono percepire. Se la lampadina non risulta accesa, nella stanza
può non esserci luce (valore 0) ma può anche esserci luce (valore 1)
proveniente da altre fonti.
• 1→ 1. Se l’attuatore esegue qualche azione i sensori devono rilevar-
la. Se accendo la lampadina il sensore deve rilevare una variazione
d’intensità luminosa.
A causa di tale semantica avremo un grafo i cui nodi assumeranno dei
valori in accordo a tali regole:
• un modulo che non ha archi entranti può memorizzare 0 o 1
• un modulo che non ha archi entranti da moduli le cui variabili di stato
sono pari a 1 possono valere 0 o 1
• un modulo che ha almeno un arco entrante da un modulo che memo-
rizza 1 deve avere la variabile di stato uguale a 1.
Tale modello sarà alla base dei nostri studi data la sua semplicità e la
sua applicabilità nel settore domotico. Possiamo a questo punto completare
il paragrafo introducendo anche un sistema modellato per mezzo di un
linguaggio non booleano.
CAPITOLO 4. MODELLO DI UN SISTEMA DOMOTICO 59
Fig. 4.4: Rappresenta un grafo azione reazione con un linguaggio non booleano
in un dato istante di tempo. I nodi con il colore rosso sono i capi, quelli con il
colore blu sono i technical manger mentre quelli con il colore verde sono gli
sviluppatori software.
Il sistema che andremo a esporre raramente verrà utilizzato nella vita
di tutti i giorni. Esso ha esclusivamente fini didattici volti a presentare i
principi alla base dei linguaggi non booleani.
Supponiamo di dover rappresentare la gerarchia piramidale presente all’in-
terno di un team di sviluppo di un progetto di notevoli dimensioni. Questa
è formata da tre livelli. Al livello più alto troviamo il capo progetto, al li-
vello più basso gli sviluppatori software e al livello intermedio il technical
manager. I capi sfogheranno le loro gioie e i loro dolori sui manager che a
loro volto faranno lo stesso con gli sviluppatori software.
Durante le normali giornate lavorative, vengono ad instaurarsi tra i tre
componenti, precisi modi comportamentali. L’obbedienza al capo porta i
technical manager ad assumere atteggiamenti benevoli nei suoi confronti.
Per cui quando il capo è in quiete i manager possono avere qualsiasi stato
d’animo mentre devono essere nervosi quando anche il capo è nervoso e
calmi quando il capo è arrabbiato. Gli impiegati invece, dovranno lavorare
duramente quando il manager sarà nervoso mentre, come nel caso prece-
dente, dovranno essere calmi se il manager è arrabbiato. Potranno avere
qualunque tipo di atteggiamento nel caso in cui il manager è calmo.
Un simile sistema viene modellato con il grafo di figura 4.4.
I moduli sono rappresentati dalle istanze di capo, manager e sviluppa-
tore software. Gli archi del grafo sono tracciati tenendo a mente come si
CAPITOLO 4. MODELLO DI UN SISTEMA DOMOTICO 60
instaurano i vari feedback comportamentali. Il linguaggio utilizzato è di tipo
non booleano ed è diverso per ogni tipo di modulo. Indicando con ϕc, ϕm,
ϕs rispettivamente i linguaggi del capo, del manager e dello sviluppatore
software avremo:
• Modulo Capo. Il dominio in cui varia la variabile di stato del modulo
è formato da D = calmo, nervoso, arrabbiato. Le implicazioni pos-
sibili sono I = calmo → x ∈ ϕm, nervoso → nervoso, arrabbiato →calmo.
• Modulo Technical Manager. Il dominio un cui varia la variabile di
stato del modulo è formato da D = calmo, nervoso, arrabbiato.Le implicazioni possibili sono I = calmo → x ∈ ϕs, nervoso →nervoso, arrabbiato→ calmo.
• Modulo Sviluppatore Software. Il dominio in cui varia la variabile di
stato del modulo è formato da D = calmo, lavoroduro. Le implica-
zioni sono date dall’insieme vuoto I = ∅ poiché gli sviluppatori
non sono in grado di imporre il proprio stato d’animo su nessun altro.
Sono l’ultimo anello della catena.
4.4 Il modello di guasto
In questo lavoro di tesi ci siamo interessati a una specifica classe di gua-
sti: i permanent value fault.
Nel caso più generale un modulo del sistema può avere archi sia entranti
che uscenti. La caratterizzazione del guasto deve quindi riguardare il com-
portamento del modulo in entrambe le attività possibili ovvero sia in fase di
osservazione che in fase di attuazione.
Definizione 7 (Permanent Value Fault) Un modulo è affetto da permanent va-
lue fault se fa credere di aver eseguito una data azione e se interrogato, risponde
entro corretti limiti di tempo, ma con un valore sempre identico ed errato.
Da ora in poi quando parleremo in modo generico di guasti staremo
indicando questa classe specifica.
CAPITOLO 4. MODELLO DI UN SISTEMA DOMOTICO 61
Una prima assunzione da fare è l’utilizzo di canali perfetti. Un link di comu-
nicazione che consegna messaggi corrotti nel tempo può essere affetto da
value fault permanente.
Il nostro obiettivo è trovare e isolare i guasti che occorrono nei moduli e
quindi considereremo i canali di comunicazione sincroni (i.e con ritardi
temporali conosciuti), affidabili, non soggetti a duplicazione e a creazione di
messaggi. Per i lettori più interessati si possono trovare tutti gli approfondi-
menti del caso sui canali perfetti nel libro scritto da Guerraoui e Rodrigues
([14]).
Qualunque messaggio scambiato tra i moduli e il manager arriverà a desti-
nazione nei giusti limiti di tempo senza modifiche o duplicati.
Altra caratteristica importante del nostro modello di guasto è la per-
manenza. Non siamo interessati a guasti transienti e/o intermittenti; un
modulo il cui guasto e scoperto in presenza dello stato Y , può essere sempre
rilevato imponendo tale stato. Chiaramente fin quando non lo si impone
il guasto è passivo. Un semplice esempio si può fare con una lampadina
fulminata. Fin tanto che la lampadina è spenta il guasto non si manifesta
ma appena la si accende esso diventa attivo.
Un utile esempio, particolarmente espressivo per quanto riguarda le ca-
ratteristiche dei guasti trattati, è un sensore di luce coperto da una maglietta
o occluso a causa della polvere. Un tale sensore, se interrogato, risponde
entro i limiti di tempo, ma produrrà sempre uno stesso valore errato. La
fotoresistenza interna vedrà sempre la stessa intensità luminosa e di conse-
guenza, lo stato non scatterà mai.
Stessa cosa accade se la fotoresistenza interna è rotta. Il sensore è in grado
di rispondere a ping4 o inviare messaggi di heartbeat ma non è in grado di
rilevare i cambiamenti d’intensità luminosa.
Per dare anche un esempio di value fault permanente che occorre in un
attuatore, consideriamo una porta motorizzata il cui motore interno è rotto.
In questo caso il software di controllo riceve i comandi esterni di apertura
4altra tecnica, insieme con i messaggi di heartbeat, attraverso la quale un perfect failure
detector è in grado di rilevare i moduli software affetti da guasti
CAPITOLO 4. MODELLO DI UN SISTEMA DOMOTICO 62
e chiusura ma essendo il motore rotto non è in grado di svolgere l’azione.
Scoprire un simile guasto tramite le tecniche classiche di fault detection,
quali ad esempio l’invio di messaggi di heartbeat, non è possibile. Tutte le
tecniche esistenti soffrono di qualche problema. Potremmo verificare le mi-
sure fornite dall’insieme di dispositivi omogenei e applicare su questi un
meccanismo di controllo dei limiti ma questo risulterebbe applicabile solo
a quei sistemi per cui si possiedono delle conoscenze. O ancora potremmo
eseguire tecniche di filtraggio. Eyal et all, in [11], ad esempio in base alla
conoscenza di opportuni dati statistici quali valor medio e distribuzione dei
campioni, filtrano, considerando non corretti, i dispositivi che propongono
valori fuori scala. Tale tecnica però richiede un numero elevato di dispositivi
ed è applicabile solo con sistemi omogenei.
Abbiamo bisogno di tecniche nuove, che cooperino con i vari dispositivi
del sistema e che siano in grado di decidere lo stato di salute dei vari com-
ponenti attraverso l’osservazione dei feedback prodotti e tenendo a mente
il modello di sistema sotto controllo. Questo lavoro di tesi indaga su tali
questioni proponendo una nuova metodologia di analisi.
Nel proseguo, quando mostreremo i vari esempi di sistema con il lin-
guaggio introdotto nel paragrafo 4.3.2, considereremo un modulo affetto
da permanent value fault un modulo che non agisce e che risponde sempre
zero. Il caso in cui risponde sempre uno, non viene trattato perché non può
essere rilevato non producendo un’inconsistenza.
Volendo posizionare la classe di guasti di tipo permanet value fault all’in-
terno della tassonomia fornita da Laprie in [3] e già discussa nel Capitolo 1
(vd. Fig.2.4) possiamo considerarli come facenti parte dei guasti di interazione
e dei guasti fisici.
Per ciò che è stato detto tale guasto si attiva nel momento in cui si transita
per un determinato stato ovvero durante il funzionamento del sistema. La
fase di occorrenza o di creazione è dunque quella operazionale.
Il guasto non si verifica all’interno dei componenti del sistema. Esso è lo-
calizzato esternamente manifestandosi attraverso la produzione di valori
errati.
CAPITOLO 4. MODELLO DI UN SISTEMA DOMOTICO 63
La fenomenologia del guasto è varia. Un sensore coperto da maglietta è tale
da ritenere la causa del guasto naturale (per rendere meglio l’idea è simile
ad una eccessiva interferenza elettromagnetica che causa una trasmissione
errata da parte di un qualsivoglia dispositivo elettronico/elettrico). Dall’al-
tro lato, un canale di comunicazione che trasmette messaggi corrotti a causa
dell’intrusione di utenti malintenzionati nel sistema, o di input errati inseriti
da parte di utenti ammessi al sistema, conduce a ritenere la causa del guasto
umana.
Le ultime caratteristiche del guasto da analizzare sono l’intento e la durata.
La prima, così come la fenomenologia, ha una duplice natura: accidentale e
dolosa. La seconda, è permanente.
Mappando tali caratteristiche nella nostra tassonomia di riferimento, possia-
mo includere il permanent value fault nella classi di guasti che vanno sotto
il nome di gusti fisici e guasti di interazione.
5Fault detection e fault isolation
La soluzione che proponiamo è leggermente diversa dall’approccio mo-
del based di cui abbiamo discusso nel capitolo 3. Diversamente dallo stan-
dard prevediamo la possibilità, oltre di osservare il sistema (modellato
attraverso l’ARG), anche di agire su di esso al fine di farlo transire per op-
portuni stati adatti a risolvere le inconsistenze che si presentano.
L’uso di grafi azione reazione sembra essere simile a molte tecniche di model
checking. La principale differenza è che il model checking è utilizzato per
verificare la correttezza di una procedura; Tsuchiya e Schiper ad esempio,
in [33], lo usano per provare l’algoritmo del consenso. Esso non permette
stati inconsistenti e di conseguenza il modello che viene utilizzato deve
prevedere tutti i possibili stati, cosa che nel nostro caso risulta di difficile
realizzazione.
Due sono le parti principali che costituiscono tale capitolo. La prima, ci
spiega il funzionamento della procedura di discovering con la quale indichia-
mo la sequenza di passi che ci porta a capire, dato un grafo con una generica
topologia, il numero massimo di permanent value fault che contempora-
neamente riusciamo a rilevare. La seconda, tratta i due approcci (passivo e
attivo) al problema dell’isolamento. Una volta stabilito che qualcosa non va
nel sistema bisogna capire chi o quali sono i dispositivi guasti. Tale procedu-
ra lavora sotto l’assunzione che nel sistema non vi siano più di V F guasti
dove tale valore è determinato dalla procedura di discovering.
64
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 65
Prima di affrontare l’algoritmo di discovering bisognerà costruire le fon-
damenta per la comprensione di tale teoria. Verranno sviluppati i concetti
di path e path con e senza oracoli, i criteri di fault isolation e dei casi favorevoli, i
corollari sul valore di V F nelle topologie a stella e nella clique, per terminare
con il teorema sul massimo valore di V F in un grafo qualunque. Tutta la
trattazione sarà costantemente affiancata da esempi che aiuteranno il lettore
durante il processo di apprendimento.
A conclusione di questa prima parte esibiremo, mettendole a confronto, le
performance dei due algoritmi sviluppati. Il primo utilizza la classica tecnica
a “forza bruta”, il secondo rappresenta una versione ottimizzata del primo.
Una volta calcolato il valore di V F il resto del capitolo prosegue con la
descrizione degli algoritmi di detection e isolation che di tale valore fanno
uso.
Abbiamo sviluppato due tecniche nell’esecuzione della procedura d’isola-
mento che sono direttamente correlate alle due tipologie di manager esisten-
te. L’isolamento passivo esegue la procedura osservando semplicemente lo
stato corrente del sistema. L’isolamento attivo invece è in grado di agire sul
sistema imponendo ai moduli di transitare per determinati stati.
Su entrambe le procedure faremo degli esempi e metteremo in luce la diffe-
renza di risultati a cui le due tecniche conducono durante la risoluzione del
problema.
5.1 La procedura di discovering
Riprendiamo brevemente la natura del problema per cui vogliamo tro-
vare una soluzione. Il primo passo da compiere è capire quanti guasti nel
sistema siamo in grado di isolare contemporaneamente.
Tutta la teoria che svilupperemo è stata fatta ragionando su grafi con lin-
guaggi booleani, data la loro capacità di modellare scenari domotici e data la
maggiore semplicità rispetto ai linguaggi non booleani. Questo, come vedre-
mo non comporta alcun tipo di perdita di generalità. Tutto ciò che diremo
sarà di fatti applicabile senza alcuna modifica ad ogni tipo di linguaggio.
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 66
Fig. 5.1: Le quattro possibili rappresentazioni di una path.
Siamo interessati a rispondere alla seguente domanda.
Dato un grafo azione reazione G = (N,E), con una topologia generica, i cui
nodi sono i moduli del sistema, caratterizzati da uno stato s rappresentato
tramite una variabile booleana e un linguaggio (o semantica) ϕ che descrive
il corretto comportamento azione-reazione di G, qual’è il numero massimo
V F di permanent value fault che riusciamo ad isolare?
Introduciamo una serie di concetti indispensabili per la comprensione
dell’algoritmo. L’elemento fondamentale di tutta la teoria è la path.
Definizione 8 (Path) Dato un ARG G = (N,E) definiamo una path un cammi-
no 1 di G costituito da tre diversi nodi connessi da due diversi archi.
Le immagini di Fig. 5.1 sono tutti esempi di path. L’orientazione tra i tre
nodi non ha importanza; ciò che conta è che siano legati da un cammino.
Ogni sistema è purtroppo soggetto a guasti. La loro rilevazione nel
nostro modello di riferimento è realizzata attraverso la scoperta di una o
più inconsistenze.
Definizione 9 (Inconsistenza) Uno stato del sistema è soggetto a inconsistenza
se esistono, all’interno del modello, una o più implicazioni non appartenenti al
linguaggio.
Quando si manifesta un guasto è possibile trovare effetti non desiderati.
Accendiamo la luce, ma il sensore di luminosità non rileva alcuna variazione
dell’intensità luminosa presente nella stanza, chiudiamo la porta e il fine
1sequenza alternante di nodi e archi, senza nodi interni ripetuti (tratto da [31])
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 67
corsa associato non scatta, accendiamo l’impianto audio ma i sensori di
rumore ad esso connessi, non percepiscono alcuna variazione e così via.
Ogni inconsistenza implica sempre almeno due dispositivi (uno attuativo
e uno percettivo) ma può coinvolgerne anche più di due (se ad esempio
avevamo più di un sensore di luce potevamo avere un’inconsistenza tra la
lampada e i vari sensori).
In ogni istante il sistema può andare incontro a diverse inconsistenze. Se
all’accensione della luce i sensori di luminosità non rilevano la variazione
attesa e contemporaneamente i voltmetri associati alla lampada non rilevano
differenza di potenziale avremo due insiemi di inconsistenze, una tra la
lampada e il voltmetro e l’altra, tra la lampada e i sensori di luce.
I due concetti introdotti di path e inconsistenza trovano applicazione nel
teorema di isolamento nella path.
Lo scopo è quello di trovare una qualche condizione che ci permetta di
determinare attraverso l’ispezione visiva del grafo, il numero massimo di
guasti contemporanei che riusciamo ad isolare. Per far questo, inizieremo
a presentare dei concetti, come quello del passaggio di stato, che verranno
ripresi quando descriveremo l’algoritmo di isolamento.
Un primo passo verso la determinazione della condizione di cui abbiamo
bisogno è rappresentato dal teorema di isolamento nella path.
Teorema 1 (Isolamento nella path) Nella path siamo sempre in grado di isolare
un guasto, purché in essa non né occorra più di uno.
Dimostrazione. La dimostrazione è fatta piazzando il guasto su ogni
nodo e mostrando, per ognuna delle posizioni che assume, che c’è una
procedura in grado di rilevarlo. La procedura è applicabile qualunque sia
l’orientazione degli archi all’interno della path. Consideriamo quindi, in
modo del tutto casuale, la path di Fig. 5.2.
Queste sono le assunzioni che facciamo all’interno del sistema.
Fig. 5.2: Una possibile path di un sistema.
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 68
• Il linguaggio utilizzato è quello descritto nella sezione 4.3.2.
• Il grafo che prenderemo in considerazione è invece un ARG formato
dalla sola path d’interesse.
• Tutte le variabili di stato dei moduli inizialmente espongono un valore
pari a zero.
• Ultima ma più importante, il singolo nodo affetto da value fault per-
manente, interrogato, risponde sempre con valore zero e ci fa credere
di aver realizzato l’azione richiesta.
Il comportamento assunto dal nodo guasto è quello più “interessante” ri-
spetto alle inconsistenze generate dal linguaggio utilizzato. In questo modo,
siamo sicuri che il componente produca, rispondendo sempre zero, l’unica
inconsistenza possibile (1→ 0). Se assumiamo una risposta con valore sem-
pre pari a 1 a fronte di un’azione il guasto non si attiva, poiché non viene
prodotta alcuna inconsistenza (implicazione del tipo 1→ 1).
Caso 1: guasto su nodo estremo. Dimostriamo come riusciamo ad isolare il
guasto che occorre su uno dei due nodi estremi (A o C nella figura 5.2). Se il
guasto occorre sul nodo A2 il manager attiva la seguente procedura:
1. set(1,A). Settiamo lo stato della variabile del nodo A a 1. Poiché A è
affetto da value fault non agisce e di conseguenza B, corretto, espone
il valore iniziale 0.
2. set(0,all). Imponiamo tutti i moduli ad assumere stato pari a 0.
3. set(1,B). Settiamo lo stato della variabile del nodo B a 1. Poiché C non
è affetto da value fault reagisce e rispettando la semantica del sistema
risponde 1.
A questo punto la procedura termina e viene rilevato il guasto sul nodo
A. Per capire come riusciamo a dire in maniera deterministica che il guasto
è occorso sul nodo A è indispensabile la nozione di passaggio di stato.
2se occorre sul nodo C basta cambiare in modo simmetrico i nodi su cui si va ad agire
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 69
Un modulo affetto da value fault, indipendentemente dalle azioni eseguite
sul sistema, assume un comportamento delineato dalla continua permanen-
za in un dato stato. Nel nostro caso, qualunque cosa accada, il nodo A in
fase di ricezione esibirà una variabile con valore zero.
Di conseguenza, nel momento in cui il manager a fronte di un’azione, os-
serva in un dato modulo una reazione, e quindi un passaggio di stato, può
concludere che la coppia di nodi funziona. Il nodo che cambia stato è passato
da zero a uno. La parte percettiva coinvolta dall’azione eseguita funziona e
quindi funziona anche il modulo che ha svolto l’azione3.
Tale ragionamento ci conduce a considerare corretti i nodi B e C e guasto il
nodo A terminata l’azione 3.
Caso 2: Guasto del nodo centrale della path. In tale situazione la procedura
per isolare il guasto, di cui B è affetto, è leggermente diversa.
1. set(1,A). Settiamo la variabile di stato del modulo A a 1. B, affetto da
value fault, risponde zero generando un’inconsistenza.
2. set(0,all). Imponiamo tutti i moduli ad assumere stato pari a 0.
3. set(1,B). Settiamo la variabile di stato del modulo B a 1. B, affetto da
value fault non agisce e conseguentementeC risponde zero, generando
un ulteriore inconsistenza.
La situazione sembra essere apparentemente più complessa essendo i
nodi tutti sospetti. In questo caso ci viene in aiuto l’ipotesi principale del
teorema che afferma la presenza di al più un guasto all’interno della path.
Riusciamo in questo modo a fare inferenza e a sancire il guasto sul nodo B.
Dalla prima azione eseguita, possiamo dedurre che seA fosse il nodo guasto,
allora anche uno tra B e C lo sarebbe, violando l’ipotesi del teorema. Stesso
discorso si può fare con la terza azione. In questo caso se fosse guasto C,
dovrebbe esserlo ancheA. Da ciò deriviamo, affinché non si violino le ipotesi
del teorema, che il guasto è sul nodo B.
3se il modulo non avesse attuato il nodo ad esso connesso non avrebbe potuto cambiare
stato
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 70
Il teorema è applicabile qualunque sia la path. Il ragionamento è identico;
ciò che cambia sono i dispositivi su cui verranno invocate le azioni, che
saranno scelti in base alla topologia della path.
Diamo ora, alcune definizioni che nascono dalla dimostrazione appena
effettuata.
Definizione 10 (Oracolo) Si definisce oracolo una coppia di nodi funzionante
cioè una coppia che ha effettuato una transizione per stati diversi.
Esempi di oracoli si sono trovati durante la dimostrazione del teorema 1.
Durante il caso 1 l’oracolo è formato dalla coppia di nodi (B,C).
Nel caso due invece, non abbiamo trovato nessun oracolo. Qui, la scoperta
del guasto è avvenuta per inferenza. Possiamo suddividere le due path,
formatesi da questi due casi in path con oracolo e path senza oracolo.
Definizione 11 (Path con oracolo) Si definisce una path con oracolo, una path
costituita da un oracolo.
Definizione 12 (Path senza oracolo) Si definisce path senza oracolo una path
in cui il guasto occorre sul suo nodo centrale.
5.1.1 I criteri di fault isolation
In questo paragrafo elencheremo i due criteri alla base della procedura
del calcolo di V F . Abbiamo visto, nella precedente sezione, come la rile-
vazione e l’isolamento di un guasto sia sempre possibile in una path con
oracolo. Tale risultato costituisce la base del primo dei due criteri riguardanti
la fault isolation.
Criterio 2 (Criterio di fault isolation) Dato un grafo azione reazioneG = (N,E)
avente una qualsiasi topologia, siamo in grado di isolare V F guasti, se per ogni pos-
sibile combinazione di guasti di taglia V F , esiste, per ogni nodo della combinazione,
almeno una path con oracolo.
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 71
Il criterio è una diretta conseguenza del teorema 1. Mostriamo degli
esempi in cui vediamo come metterlo in pratica.
La figura 5.5 mostra due topologie in cui viene applicato il criterio di fault
isolation sopra esposto. Analizziamole partendo dalla 5.3.
L’applicazione del criterio di fault isolation ad una topologia del genere
conduce a un valore di V F pari a due. Quindi, in un tale contesto, siamo
in grado di isolare al più due guasti contemporaneamente. La procedura
di fault isolation che verrà attivata durante il funzionamento del sistema
lavorerà sotto tale ipotesi, di cui farà utilizzo in particolar modo durante la
procedura d’isolamento passiva (maggiori dettagli nel proseguo).
Per maggiore chiarezza distingueremo la procedura d’isolamento utilizzata
durante il calcolo di VF da quella utilizzata a run time, ovvero durante il
funzionamento del sistema, definendo la prima fittizia e la seconda reale.
A partire da questo momento e fino a segnalazione contraria parleremo della
procedura fittizia. É stato scelto questo termine perché la procedura non
isola guasti reali occorsi nel sistema ma prova a piazzare una serie di guasti
sulla topologia del grafo e verifica se riesce a isolarli. Quando il sistema
entrerà in funzionamento e i guasti saranno veri, la procedura fittizia verrà
abbandonata per lasciare posto a quella reale.
Qualunque sia la combinazione di guasto di taglia due, esiste una coppia
di nodi funzionanti, un oracolo, che permette di rilevarli. Se fossero guasti i
nodi B e C, potremmo rilevarli attraverso la coppia di nodi funzionanti D
ed E. Se fossero guasti A e D invece, saremmo in grado di rilevarli mediante
l’oracolo costituito dai nodi (B,C).
Per V F = 3, il criterio non risulta più verificato poiché esiste almeno una
combinazione di guasti di taglia tre, formata dai nodi (A,B,C), in cui non
tutti i nodi (A in questo caso), sono inclusi in path con oracolo (i vicini di A
sono entrambi guasti).
La Fig. 5.4 ha un valore di V F pari a uno. Nonostante abbia a prima vista un
numero di archi maggiore e quindi una maggiore possibilità di creare oracoli
riesce a isolare meno guasti della precedente. Il problema in questo caso
è determinato dal minimo grado del grafo che è pari a uno. Ritorneremo
su tale concetto precisando come il grado di un grafo influenza il valore
finale di V F . Per il momento ci basta osservare che se si guastano entrambi
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 72
Fig. 5.3: Un esempio con
V F = 2
Fig. 5.4: Un esempio con
V F = 1
Fig. 5.5: Esempi di applicazione del criterio di isolamento dei guasti.
i nodi G e C, mentre C può essere rilevato dalla coppia di nodi funzionanti
(A,H) o (A,B), G non è più “raggiungibile”, essendo connesso solo a C che
è guasto.
Da tale criterio otteniamo, dei risultati “notevoli”, validi per particolari
topologie.
Corollario 1 (Criterio di fault isolation applicato su topologie a stella) Se
il grafo azione reazione G = (N,E) ha una topologia a stella il numero massimo di
permanent value fault isolabili simultaneamente è pari a uno.
Essendo, per definizione di topologia a stella, tutti i nodi connessi al
nodo centrale, basterà romperlo, per non avere più la possibilità di costruire
path con oracolo.
Corollario 2 (Criterio di fault isolation applicato a clique) Se il grafo azio-
ne reazione è una clique il massimo numero di permanent value fault isolabili
contemporaneamente è V F = |N | − 2.
Una clique è un grafo in cui ogni nodo è connesso a tutti gli altri nodi
del grafo. Per questo motivo abbiamo bisogno di due soli nodi corretti per
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 73
Fig. 5.6: L’esempio mostra la non usabilità delle path senza oracolo durante
l’applicazione del criterio di fault isolation.
avere un arco corretto e quindi una path con oracolo per ogni nodo.
Tale struttura verrà ripresa successivamente durante la determinazione del
lower bound del valore di V F ; in tale situazione dimostreremo la veridicità
di tale risultato anche da un punto di vista matematico.
Finora abbiamo parlato solo dell’utilità delle path con oracolo, ma l’espo-
sizione del teorema 1 ci aveva condotto all’introduzione anche delle path
senza oracolo. Esiste una ragione precisa per cui le path senza oracolo non
rientrano nel criterio della fault isolation (criterio 2) che mostriamo tramite
un semplice esempio.
Supponiamo di avere un grafo azione reazione avente la topologia mo-
strata in 5.6 e in cui i nodi A e D sono guasti.
Abbiamo provato, con il teorema 1 che in una path siamo sempre capaci di
isolare un guasto purché al suo interno non né occorra più di uno. A prima
vista e con tale teorema in mente potremmo dire che in tale situazione siamo
in grado di isolare entrambi i guasti; con la path formata dai nodi (B,A,C)
siamo in grado di isolare il guasto che è occorso su A, mentre con quella
formata dai nodi (B,D,C) possiamo isolare il guasto su D.
Sfortunatamente, questo non è vero. La procedura di isolamento, non trovan-
do oracoli, non è in grado di stabilire dove i guasti sono occorsi. Potremmo a
questo punto provare tutte le possibili path esistenti e osservare cosa accade
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 74
ma purtroppo la situazione non cambia. Otteniamo di fatti:
• Path (B,A,C)→ A è il nodo guasto
• Path (B,D,C)→ D è il nodo guasto
• Path (A,B,D)→ B è il nodo guasto
• Path (A,C,D)→ C è il nodo guasto
Tutti i nodi sono sospetti. Chiaramente questo accade perché quando
applichiamo la procedura d’isolamento, vista nel teorema 1, su path in cui
occorrono più di un guasto, deduciamo risultati errati dato che stiamo vio-
lando l’ipotesi del teorema.
Se nella path (A,B,D) entrambi i nodi A e D sono guasti, erroneamente
affermiamo che il guasto è sul nodo B perché è l’unico modo che abbiamo,
supponendo che è rotto sia in fase di attuazione che di percezione, di rispet-
tare l’assunzione del teorema.
Per la topologia in questione quindi non siamo in grado di isolare due guasti
occorsi simultaneamente. Il fatto che non abbiamo la possibilità di costruire
un oracolo per rilevare i nodi guasti limita le capacità di isolamento. I nodi
sono però inclusi in path senza oracoli.
Criterio 3 (Criterio dei casi favorevoli) Dato un grafo azione-reazione G =
(N,E) avente una qualunque topologia, se per V F = x con x numero intero, esiste
una sola combinazione di guasti di taglia x supportata da path senza oracolo mentre
tutte le altre (le rimanenti(|N |
x
)− 1) sono incluse in path con oracolo, allora siamo
in grado su tale topologia di isolare x permanent value faults.
Come con il criterio precedente, semplifichiamone l’apprendimento tra-
mite esempi chiarificatori.
La prima cosa che bisogna notare è che questo criterio può essere applicato
solo quando esiste una ed una sola combinazione di guasti supportata da
path senza oracolo altrimenti perde la sua validità. Nell’esempio di figura
5.6 abbiamo due combinazioni di guasti di taglia due ((A,D) e (B,C)) sup-
portate da path senza oracolo (rispettivamente (B,A,D) e (B,D,C) per la
combinazione di guasti (A,D) e (A,B,D) e (A,C,D) per la combinazione
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 75
Fig. 5.7: Un esempio di applicazione combinata del criterio di fault isolation e
di quello dei casi favorevoli. Il valore di VF passa da due a tre.
di guasti (B,C)) e quindi, il criterio non risulta applicabile e il valore di V F
rimane stabile a uno.
Esistono invece, casi più fortunati in cui l’applicazione di entrambi i criteri
enunciati in questo paragrafo fanno aumentare di un’unità il valore di V F .
Vediamo alcuni esempi in cui ciò accade.
In figura 5.7 il criterio di fault isolation termina settando il valore di
V F a due. Per ogni combinazione di taglia due tutti i moduli guasti della
combinazione sono inclusi in path con oracolo. Questo è vero anche per
le combinazioni di guasti di taglia tre ad eccezione della combinazione
(A,D,E).
Analizzando meglio la topologia ci accorgiamo che è una clique di grado
quattro priva della connessione tra il nodi (B,C). La combinazione sopra
citata è l’unica per la quale non si può costruire l’oracolo ed è quindi l’unica
i cui elementi sono inclusi in path senza oracolo. Tale osservazione permette
l’applicazione su tale grafo anche del criterio dei casi favorevoli e il conse-
guente aumento del valore di V F da due a tre.
Prima di passare alla presentazione dell’algoritmo vediamo un ultimo esem-
pio tratto da un parziale scenario domotico in cui si applicano entrambi i
criteri sopra esposti.
Il sistema presentato, verrà ripreso nel successivo capitolo dove andremo a
mettere in pratica tutto ciò che abbiamo detto a livello teorico.
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 76
Fig. 5.8: Un esempio di applicazione di entrambi i criteri di fault isolation e dei
casi favorevoli tratto da uno scenario domotico
.
Il sistema è formato da tre lampadine L1, L2 e L3 e da due sensori di lumi-
nosità S1 e S2. Seguendo le regole di costruzione del modello, esposte nel
capitolo 4, abbiamo un grafo azione-reazione bipartito con un linguaggio
del tipo ϕ = 1→ 1, 0→ 0|1. Il grafo è mostrato in figura 5.8.
Il criterio di fault isolation calcola per V F un valore pari a uno. La com-
binazione di guasti di taglia due formata dai moduli (S1, S2) infatti non è
supportata da una path con oracolo. Fortunatamente, questa rappresenta
l’unica combinazione di taglia due per cui si sviluppa una tale situazione.
Ragion per cui è possibile applicare anche il criterio dei casi favorevoli che
fa passare il valore di V F da uno a due.
La condizione che cercavamo, utile a determinare se una certa combina-
zione di guasti e isolabile semplicemente tramite ispezione visiva del grafo
riguarda la modalità di creazione degli oracoli.
Capire quando è possibile applicare il criterio dei casi favorevoli può essere
fatto solo tramite una procedura automatizzata ma la verifica se una data
combinazione di guasti è isolabile o meno può essere fatta attraverso sem-
plice ispezione visiva. Basterà che da ogni elemento della combinazione sia
possibile partire o arrivare per mezzo di due “hop” e senza passare per nodi
anch’essi guasti.
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 77
L’ultimo passo che ci separa dalla presentazione dell’algoritmo è un
ulteriore teorema, già accennato precedentemente, il cui risultato è stato
applicato durante l’implementazione della versione ottimizzata della proce-
dura di discovering.
In fase di analisi delle prestazioni ci siamo accorti che la versione “brute
force” dell’algoritmo di discovering era poco performante. Il passaggio alla
versione ottimizzata, come vedremo nel dettaglio nel paragrofo successivo,
ci ha permesso di avere un ulteriore incremento di performance, soprattutto
per quando riguarda i tempi di esecuzione.
I possibili valori di V F sono correlati al valore del minimo degree del grafo e
più precisamente oscillano tra il minimo degree meno uno (il valore minimo)
e il minimo degree (il valore massimo).
Teorema 4 (I possibili valori di V F ) Dato un grafo azione reazioneG = (N,E)
con d minimo degree è sempre possibile isolare un numero di guasti almeno pari a
d− 1 e al massimo pari a d.
Dimostrazione. La dimostrazione è fatta come segue: per prima cosa
proviamo che più di d non riusciamo ad isolare. Dopodiché, introduciamo
la topologia assimilabile al caso peggiore e facciamo vedere che in questo
caso riusciamo a isolare d − 1 guasti. Se ci riusciamo nel caso peggiore di
conseguenza ci riusciremo sempre.
La prima parte della dimostrazione è semplice. Qualunque sia la topolo-
gia del grafo, se n è il nodo con il minimo grado d (uscente o entrante non
fa differenza) di G “rompendo” i d nodi adiacenti ad n potremmo essere in
grado di fare isolation. Questo dipenderà dalla topologia e in particolare
dalla possibilità che avremo di creare per ognuno dei d nodi un oracolo in
grado di rilevarli.
Se però ai d nodi aggiungiamo anche il nodo n, portandoci ad un totale di
d+ 1 guasti possiamo dire con certezza di non essere più in grado di isolarli.
Il nodo n di fatti sarà circondato da nodi guasti e quindi non sarà possibile
includerlo in path con oracolo. Non sarà possibile nemmeno includerlo in
path senza oracolo dato che la path in questione sarà formata da due nodi
guasti. Il suo isolamento è quindi impossibile. Ne deriva che riusciamo ad
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 78
isolare, indipendentemente dalla topologia di G non più di d guasti.
La seconda parte della dimostrazione è leggermente più complessa.
Per verificare che siamo sempre in grado di isolare almeno d − 1 guasti
dobbiamo mostrarlo nel caso peggiore. La procedura d’isolamento, svolge la
sua funzione cercando di creare un oracolo. L’unico modo che abbiamo per
rendere impossibile l’isolamento è rompere tutti gli oracoli ovvero almeno
un nodo per ogni arco in E deve essere guasto. Considerando che più archi
abbiamo a parità di nodi, maggiori sono le possibilità di creare oracoli, il
caso peggiore, sarà il grafo regolare4 di grado d con il minor numero di archi
al variare del numero di nodi. Il grafo cercato è per definizione la clique.
Esso ci permette di invalidare5 il maggior numero di oracoli con il minor
numero di guasti.
Per una clique G = (N,E) con |N | = n e d il grado valgono le seguenti
affermazioni:
• d = n− 1
• n = d+ 1
Dalla teoria dei grafi (per approfondimenti [31, 2, 8]) sappiamo inoltre
che per una cricca il numero di archi è pari a:
|E| = n(n− 1)
2=d(d+ 1)
2(5.1)
In una clique quando rompiamo un nodo stiamo invalidando d oracoli,
quando ne rompiamo due ne invalidiamo d − 1, con tre d − 2 e così via.
Quindi dopo x guasti il numero di oracoli invalidati è:
x−1∑i=0
d− i (5.2)
Facciamo vedere a questo punto che V F = d non può essere soluzione
perché se rompo n − 1 nodi invalido tutti gli archi mentre ciò non accade4fissato il minimo degree d e il numero di nodi n qualunque altro grafo non regolare
avrebbe un numero di archi maggiore e di conseguenza una maggiore probabilità di creare
oracoli5intendiamo la rottura dell’arco con la conseguente impossibilità di creare un oracolo
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 79
con V F = d − 1 che quindi rappresenta una soluzione ammissibile per il
problema.
Mostriamo per prima cosa il caso con V F = d. Facciamo vedere cioè che
rompendo n-1 nodi non abbiamo più archi disponibili per creare oracoli.
n−1∑i=1
d− i < (d+ 1)d
2(5.3)
Risolvendola abbiamo:
(n− 1)d− (n− 2)(n− 1)
2<n(n− 1)
2⇒ (n− 1)(n− n
2) <
n(n− 1)
2
⇒ n(n− 1)
2<n(n− 1)
2
La disuguaglianza non è verificata e quindi V F = d non può essere
soluzione.
Lo stesso ragionamento si ripete con V F = d− 1.
n−2∑i=1
d− i < (d+ 1)d
2(5.4)
dalla cui risoluzione si ottiene:
(n− 2)d− (n− 2)(n− 1)
2<n(n− 1)
2
⇒ (n− 2)(n− 1)− (n− 2)(n− 1)
2<n(n− 1)
2
⇒ (n− 2)(n− 1)
2<n(n− 1)
2
La diseguaglianza in questo caso è verificata e quindi d − 1 = n − 2
guasti sono sempre isolabili, grazie alla possibilità di creare oracoli. Avremo
sempre almeno un arco a disposizione i cui nodi estremi formano un oracolo
con il quale scoprire tutti i nodi guasti.
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 80
5.1.2 L’algoritmo di discovering
Abbiamo visto sufficienti esempi che ci mostrano come e quando appli-
care i criteri di fault isolation e dei casi favorevoli a topologie generiche.
Abbiamo anche esplicitato il tutto con una semplice condizione (i due hop
senza incontrare nodi guasti) che ci aiuta a verificare se è possibile isolare
il guasto tramite ispezione visiva. Ora è arrivato il momento di presentare
l’algoritmo implementato (verrà mostrato lo pseudocodice) e le performance
ottenute testandolo.
Presenteremo la struttura generale dell’algoritmo evitando di andare nel
dettaglio. Ad esempio supporremo la presenza di funzioni, senza vederne
l’implementazione, come quella per il calcolo di tutte le possibili combi-
nazioni esistenti di una data classe, utile per determinare tutte le possibili
combinazioni di guasto, o quella del calcolo delle possibili path data la ma-
trice di rappresentazione del grafo o ancora quella che si occupa di verificare
la presenza di path con o senza oracolo.
I grafi sono stati rappresentati utilizzando la libreria Java JGraphT ([19]); un
insieme di classi Java open-source, che fornisce oggetti della teoria matema-
tica dei grafi, e algoritmi sui grafi. É stata progettata per essere ottimizzata
anche per grafi con molti nodi. Consente di attribuire ai nodi del grafo un
qualsiasi oggetto. Nel nostro caso i nodi sono stati rappresentati tramite
oggetti interi e il grafo, descrivente il modello di sistema, viene passato in
input tramite una rappresentazione testuale che consiste nell’elencare tutti
gli archi esistenti rappresentati per mezzo della coppia d’interi che formano
i suoi nodi estremi.
Siccome (vd. Teorema 1) l’orientazione all’interno di una path non ha im-
portanza, durante questa fase abbiamo utilizzato grafi semplici indiretti
ovvero grafi indiretti che non permettono cappi e archi multipli tra i nodi.
Naturalmente questa struttura è stata sostituita in fase di isolamento reale
con grafi semplici diretti.
Sono state sviluppate due versione dell’algoritmo:
1. Versione “brute force”. La classica versione a forza bruta che iterati-
vamente prova in modo crescente i valori di V F partendo da uno e
fermandosi quando non si riescono più a costruire path con oracolo.
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 81
2. Versione ottimizzata. Questa versione è stata implementata successi-
vamente alla scoperta del teorema 4 sui valori possibili di V F . In tal
caso si evita di iterare l’algoritmo su tutti i valori, considerando solo
quelli per cui esistono nodi del grafo con tale grado. In questo modo
otteniamo miglioramenti sostanziali sui tempi d’esecuzione (come
vedremo durante l’esposizione dei risultati dei test svolti).
L’analisi che effettuiamo riguarda la versione ottimizzata. La procedura
fa uso di due variabili denominate supported e noSupported per indicare il
numero di guasti supportato e non supportato. L’algoritmo inizia calcolando
e memorizzando tutte le possibili path presenti nel grafo. Per prima cosa, se
il grafo ha più di tre nodi supported viene settato a uno. Fatto ciò parte il cal-
colo di V F vero e proprio. Si comincia verificando se la topologia permette
di isolare contemporaneamente d guasti con d inizialmente pari a due. Il
controllo viene fatto provando a isolare il nodo avente grado d e tutte le pos-
sibili combinazione di classe d− 1 dei d nodi ad esso adiacenti. Se riusciamo
ad isolarli, settiamo supported a d e noSupported a d+1, e proviamo le restanti
combinazioni di taglia d, altrimenti settiamo la variabile noSupported a d.
Se l’isolamento va a buon fine iteriamo il procedimento incrementando il
valore di d finché o non riusciamo più a isolare o superiamo il massimo
grado del grafo.
Se si supera il massimo grado del grafo e supported è rimasto a uno senza
che esistono all’interno del grafo nodi con grado uno (ad esempio con la
cricca) allora bisogna, partendo dal valore di noSupported, andare a ritroso
verificando se l’isolamento, con tale valore va a buon fine. Quando ciò acca-
de settiamo supported pari al valore di noSupported e ritorniamo supported.
Se invece supported è diverso da uno non serve fare isolamento andando a
ritroso ma possiamo ritornare direttamente il valore.
L’osservatore più attento avrà notato che durante il calcolo di V F si potreb-
bero andare a verificare anche valori diversi dal minimo grado del grafo
e dal minimo meno uno. Questo di fatti è stata un ulteriore prova, dato il
numero notevole di test effettuati, che il teorema è corretto, non avendo mai
trovato un valore diverso da quelli ipotizzati.
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 82
Algoritmo 1 Calcolo di V F - Parte Prima
Input: graph G = (N,E)
Output: Il valore di V F .
1: int supported, noSupported = 0; int degree = 1;
2: boolean noFinish = true;
3: if |N | ≥ 3 then
4: Set possiblePath = creratePossiblePath(G); supported = 1;
5: while noFinish and degree ≤ maxDegree(G) do
6: degree+ +;
7: Set fixedDegreeNodes = getNodesDegree(G, degree);
8: if fixedDegreeNodes is not empty then
9: for all nodes n in fixedDegreeNodes do
10: Set adiacentNodes = adiacent(n,G);
11: if not tryDetection(degree, possiblePath, adiacentNodes, n, false)
then
12: noFinisch = false;
13: noSupported = degree;
14: break;
15: end if
16: end for
17: if noFinisch then
18: if not tryDetection(degree, possiblePath, adiacentNodes, n, true)
then
19: noFinisch = false;
20: noSupported = degree;
21: else
22: supported = degree;
23: noSupported = degree+ +;
24: break;
25: end if
26: end if
27: end if
28: end while
29: return calculateSupported(supported, noSupported);
30: end if
31: return 0;
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 83
Lo pseudo codice dell’algoritmo, è stato spezzato per ragioni esclusi-
vamente di formattazione in due parti. Diamo qualche aiuto per la sua
comprensione.
Come già detto, mostriamo solo la struttura generale dell’algoritmo senza
entrare nel particolare. Anche se i nomi delle funzioni sono abbastanza
chiari spendiamo comunque qualche breve riga per la loro spiegazione.
Algoritmo 2 Calcolo di V F - Parte seconda
Input: intsupported, intnoSupported
Output: Il valore di V F .
1: if supported 6= 1 then
2: noSupported = supported+ 1;
3: else if getNodesDegree(G, 1) 6= null then
4: noSupported = 2;
5: else
6: noSupported−−;
7: while noSupported > supported do
8: if tryDetection(degree, possiblePath, null, null, true) then
9: supported = noSupported;
10: else
11: noSupported−−;
12: end if
13: end while
14: end if
15: return supported;
La funzione createPossiblePath(...) prende in input il grafo e ritorna tutte
le possibili path in esso presente. getNodesDegree(..) prende in input il grafo
e un intero rappresentate il grado e ritorna tutti i nodi del grafo con quel
degree. L’ultima funzione utilizzata è stata tryDetection(...). Essa prende in
ingresso il numero di guasti che si vuole provare a isolare, l’insieme totale
di path del grafo che utilizzerà per fare isolamento, un nodo del grafo e i
suoi adiacenti (utilizzati durante la prima parte dell’algoritmo - riga 11) e
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 84
un valore booleano che serve per indicare se bisogna controllare anche tutte
le altre combinazioni oltre a quelle formate dal nodo e dai suoi vicini.
L’analisi delle performance
Le due versioni sviluppate dell’algoritmo sono state testate su due di-
verse topologie di grafo; la cricca e i grafi random. Su entrambe sono state
raccolte statistiche sui tempi d’esecuzione mentre con la seconda topologia
si è osservato anche l’andamento del valore di V F al variare del numero di
archi e la distribuzione del grado assunta dai vari nodi.
I test sono stati eseguiti su macchina virtuale installata all’interno di un ser-
ver di tipo IBM BladeCenter. La macchina virtuale è stata così equipaggiata:
• 4 Xeon a 2.8 GHz.
• bus di sistema a 1.666 GHz.
• 8 Gb di Ram.
Iniziamo con l’analisi della versione a forza bruta. Ogni test è stato
effettuato cento volte in modo da calcolare media e deviazione standard. Per
quanto riguarda i grafi random, questi sono stati creati sempre per mezzo
della libreria JGraphT ([19]) che offre utili funzioni a riguardo. In particolare,
sono stati utilizzati grafi random con 20 nodi in cui i vari test sono stati
ripetuti facendo variare il numero di archi. Per capirci, un grafo con 50 archi
non sarà costruito partendo dalla base degli archi che avevano costituito il
grafo con 25 archi.
I risultati dimostrano essere poco soddisfacenti soprattutto per quanto
riguarda i tempi d’esecuzione con le clique, che rappresentano i casi peggio-
ri, dove con appena 20 nodi otteniamo risultati non più accettabili. Il grafico
5.9 mostra con chiarezza l’andamento esponenziale che ne vien fuori. La
deviazione standard è molto bassa. Chiaramente non abbiamo eseguito test
sul valore di V F poiché le clique sono caratterizzati sempre dallo stesso
valore pari a d− 1 con d grado del grafo.
Le cose non cambiano con i grafi random. Anche qui (figura 5.10(a)) il tempo
d’esecuzione cresce in modo esponenziale al variare del numero di archi
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 85
Fig. 5.9: Tempi d’esecuzione dell’algoritmo a forza bruta e della sua versione
ottimizzata al variare del numero di nodi della clique
che compongono il grafo. Il valore di V F ha invece, un andamento quasi
lineare con una lieve crescita dai 100 ai 125 archi. La deviazione standard si
mantiene sempre al di sotto dell’unità (tranne per 100 archi dove è uguale a
1.2) conferendo ai test una maggiore attendibilità (figura 5.10(b)).
In figura 5.9 appaiano nette le differenze rispetto alla versione a forza
bruta. Se prima raggiungevamo i 1500 secondi con clique di 20 nodi ora
ne servono più di sessanta per ottenere gli stessi risultati. I progressi sono
notevoli. Con settanta nodi invece i tempi iniziano a farsi più elevati ma
ancora possono essere ritenuti accettabili considerando che tale procedura
va ripetuta solo una volta, prima che il sistema entri in funzione. Il problema,
in questo caso si ha con la memoria, che in alcuni casi termina, bloccando
l’esecuzione dell’algoritmo. Per quanto riguarda la deviazione standard i
valori si mantengono bassi fino a cricche di trenta nodi. Aumentano sensi-
bilmente con 50 e 70 nodi mentre raggiungono il picco di 120 secondi con 60
nodi.
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 86
(a)
(b)
Fig. 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.
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 87
Miglioramenti si hanno anche con i grafi random (figura 5.10). La metodo-
logia con cui sono stati eseguiti i test è sempre la stessa. Ogni punto sul
grafo è la media ottenuta dalla ripetizione di cento test. Il valore di V F
è identico. Ciò che si osserva è un andamento più lineare ma ciò non ha
nessuna motivazione precisa (figura 5.10(b)).
Miglioramenti ci sono anche nella curva dei tempi d’esecuzione (figura
5.10(a)) che sono notevolmente traslati verso il basso. Con 175 archi, ovve-
ro con l’avvicinarsi del grafo a una clique di venti nodi, il tempo invece
di continuare ad aumentare diminuisce sostanzialmente passando da 145
secondi a 24. Questo probabilmente è dovuto ad una dispersione meno
ampia dei valori del grado assunto dai vari nodi, come si può constatare
osservando figura 5.13, che comporta minori iterazioni durante l’esecuzione
dell’algoritmo.
Per completezza riportiamo anche le distribuzioni del grado assunte dai
vari grafi durante la costruzione dei test. Queste sono fondamentalmente
assimilabili a distribuzioni normali con la previsione che man mano aumenta
al crescere degli archi del grafo. Per approfondimenti su la distribuzione
normale è possibile consultare [32].
I grafici in figura 5.11, 5.12 e 5.13 sono stati ottenuti contando il numero di
nodi con un dato grado per ogni grafo costruito durante la ripetizione dei
test. Ad esempio considerando i grafi random con 25 archi la maggior parte
dei nodi aveva grado due. Su cento grafi random costruiti 678 nodi hanno
assunto tale valore.
5.2 La procedura di fault isolation
Terminiamo il capitolo discutendo della procedura d’isolamento che pre-
cedentemente abbiamo definito reale. Questa lavorerà sotto l’assunzione di
riuscire a tollerare V F guasti ed è suddivisibile in passiva e attiva a seconda
del tipo di manager che viene utilizzato.
Durante il funzionamento del sistema qualcosa può rompersi o qualche
dispositivo può non comportarsi secondo il suo corretto funzionamento. Ci
accorgiamo che qualcosa non va dalla presenza di uno stato inconsistente.
Abbiamo già definito tale concetto e quindi non ci soffermiamo oltre.
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 88
Fig. 5.11: Le distribuzioni assunte dal grado dei nodi durante la costruzione dei
grafi random con 25, 50 e 75 archi
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 89
Fig. 5.12: Le distribuzioni assunte dal grado dei nodi durante la costruzione dei
grafi random con 100, 125 e 150 archi
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 90
Fig. 5.13: La distribuzione assunta dal grado dei nodi durante la costruzione dei
grafi random con 175 archi
Il paragrafo ha lo scopo di spiegare la fault isolation passiva e attiva, di
mostrarla tramite esempi e di esporre lo pseudo codice di entrambi gli algo-
ritmi.
Ogni qual volta siamo di fronte a un’inconsistenza si cerca, sempre, di risol-
verla attraverso la fault isolation passiva, cioè osservando semplicemente lo
stato senza eseguire alcuna azione. Esiste una condizione ben precisa che ci
permette di capire quando possiamo comportarci in questo modo. Se non
siamo in tali condizioni, la procedura passiva fallisce e dobbiamo passare a
quella attiva che presuppone l’utilizzo di un manager attivo che come tale,
è in grado di agire sui dispositivi del sistema azionandoli e leggendone lo
stato.
In tutti gli esempi che faremo, per semplicità, supporremo di avere modelli
dotati di linguaggi booleani identici a quello presentato nella sezione 4.3.2.
In questo caso il manager, sia esso attivo o passivo, è in grado di scoprire
un’inconsistenza quando la regolo 1→ 1 è violata.
Un manager passivo dispone della sola primitiva read e dunque può solo
leggere lo stato dei nodi. Le sue capacità di isolamento quindi, dipendono
dallo stato corrente dei nodi.
Un’inconsistenza implica sempre due nodi e il manager prova a inferire
quale tra essi è guasto osservando lo stato dei loro vicini (quelli direttamente
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 91
connessi).
Vediamo qualche semplice esempio per capire come si comporta la fault
isolation passiva dopodiché diamo una regola generale che permette la sua
facile implementazione.
1 2 3 4
a
b
a
b
a
b
a
b
c c cd
e
Fig. 5.14: Applicazione della Fault isolation passiva su quattro diverse topologie
di ARG
Consideriamo i quattro diversi casi mostrati in figura 5.14 e facciamo
vedere come la procedura di isolamento passiva si comporta in ognuno di
essi.
• Caso 1. Avendo solo due nodi non abbiamo alcuna possibilità di isolare
il guasto. Se a = 1 e b = 0 c’è un’inconsistenza ma chi, tra a e b, è il
“colpevole”?
• Caso 2. Supponiamo di avere il seguente stato globale (a = 1, b =
1, c = 0). L’inconsistenza è presente sull’arco bc ed essendone l’arco ab
privo, potremmo essere tentati a sostenere che i nodi a e b funzionano
mentre il guasto è su c. Questo purtroppo non è vero. A causa del
modello di sistema di fatti, se non è possibile osservare la reazione di
b all’occorrenza del cambiamento di stato di a, non possiamo dedurre
nulla circa il loro stato di salute. Siamo sicuri che i nodi funzionano solo
quando osserviamo un passaggio di stato. Da ciò si potrebbe dedurre
che dalla semplice osservazione dello stato in un istante di tempo
qualsiasi, non si ricava nulla di buono e invece esistono situazioni in
cui, conoscendo il valore di V F è possibile fare inferenza.
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 92
• Caso 3. In questo caso in particolari stati è possibile dedurre il guasto
di b. Supponiamo di avere (a =?, b = 1, c = 0, d = 0) dove il punto
interrogativo sta ad indicare qualsiasi valore. V F per questa topologia
è uguale a uno. Siccome c e d non possono essere contemporaneamente
guasti, altrimenti violerebbero una delle assunzioni del sistema, deve
esserlo per forza b. Questo si può dire con certezza indipendentemente
dall’avere osservato il passaggio di stato.
• Caso 4. In questo caso è qualche volta possibile isolare il guasto o di
a o di b. Il guasto di b è isolabile come nel caso precedente, avendo
uno stato del tipo (a = 0, b = 1, c = 0, e =?) mentre il guasto di a è
isolabile quando le variabili di stato dei moduli del sistema assumono
valori (a = 0, b = 1, c =?, e = 1). Il ragionamento è del tutto identico;
indipendetemente dall’osservazione del cambiamento di stato, b e
c non possono essere simultaneamente guasti e quindi il colpevole
dell’inconsistenze generate è a.
I precedenti esempi mostrano come il successo di tale procedura è fun-
zione degli archi entranti e uscenti in un dato nodo, del loro stato e del
valore di V F . Più precisamente, sia n un nodo del grafo, sia V F = f , OUT
l’insieme di nodi implicati da n e IN l’insieme di nodi che implicano n.
Allora:
• Se nmemorizza 0 il suo guasto è rilevabile se e solo se esistono almeno
f + 1 nodi ∈ IN che memorizzano 1.
• Se nmemorizza 1 il guasto di n è rilevabile se e solo se esistono almeno
f + 1 nodi ∈ OUT che memorizzano 0.
La capacità di un grafo in cui è implementato un manager passivo
di isolare guasti è sempre relazionato alla stato corrente e quindi non è
conoscibile a priori.
Da quanto detto possiamo dedurre una regola generale, valida qualunque
sia il linguaggio associato al grafo azione reazione.
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 93
Criterio 5 (Fault isolation passiva) Se ho un numero di implicazioni inconsi-
stenti maggiore di V F allora il nodo coinvolto in tali implicazioni con in o out
degree maggiore, è guasto.
5.2.1 Fault isolation passiva in pseudo codice
L’algoritmo che attua la procedura di isolamento passivo è semplice
e computazionalmente efficace. Esso viene invocato a fronte di una o più
inconsistenze individuate. I nodi che le hanno generate vengono passati
all’algoritmo insieme con il valore di V F e il grafo.
La procedura a questo punto per ogni possibile nodo guasto n controlla se ci
sono nodi implicati da n o implicanti n e nel caso in cui sono presenti, inizia
a leggerne lo stato al fine di contare il numero di inconsistenze nel sistema.
Successivamente, viene verificato il criterio 5 e se il numero di inconsistenze
riscontrate è maggiore di V F si diagnostica il guasto di n.
I guasti così collezionati vengono memorizzati in una opportuna struttura
dati per poi essere passati alla procedura che si occupa della riconfigura-
zione dell’impianto. Senza mostrarla nel dettaglio, data la sua semplicità,
essa rimuoverà i nodi guasti dal grafo e, a seguito del cambiamento nella
topologia del grafo, ricalcolerà il nuovo valore di V F .
Durante la scrittura dello pseudo codice, oltre alla funzione che si occupa di
riconfigurare l’impianto ci sono altre procedure che non vengono dettagliate:
outcomingNodeFrom(...) e incomingNodeFrom(...) vengono invocate sul grafo
passandogli un suo nodo e servono rispettivamente per ottenere l’insieme
di nodi implicati e che implicano il nodo passatogli come parametro.
Questi metodi vengono implementati da opportune funzioni della libreria
JGraphT. I “nodi uscenti” vengono selezionati tramite un iteratore che ef-
fettua una ricerca in profondità del grafo a partire dal parametro che gli si
passa. I “nodi entranti” invece, vengono presi attraverso una funzione che
seleziona gli archi entranti nel nodo passato come parametro.
5.2.2 La fault isolation attiva
Nella precedente sezione abbiamo mostrato le limitate capacità di fault
isolation di un manager passivo. Un manager attivo, differisce dal passivo
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 94
Algoritmo 3 Fault isolation passiva
Input: int V F ; Set possibleFaults; Graph g;
Output: true if the procedure isolates the fault false else.
1: int inconsistencyCounter, found = 0; Set fault = newSet();
2: for all item ∈ possibleFaults do
3: inconsistencyCounter = 0;
4: Set outNode = g.outcomingNodeFrom(item);
5: if not outNode is empty then
6: for all vertex ∈ outNode do
7: if item and vertex are inconsistent then
8: inconsistencyCounter + +;
9: end if
10: end for
11: if inconsistencyCounter > V F then
12: found+ +; faults.add(item);
13: print FOUND A PERMANENT VALUE FAULT in item;
14: continue;
15: end if
16: end if
17: Set inNode = g.incomingNodeFrom(item);
18: if not inNode is empty then
19: for all vertex ∈ inNode do
20: if item and vertex are inconsistent then
21: inconsistencyCounter + +;
22: end if
23: end for
24: if inconsistencyCounter > V F then
25: found+ +; faults.add(item);
26: print FOUND A PERMANENT VALUE FAULT in item;
27: continue;
28: end if
29: end if
30: end for
31: if found 6= 0 then
32: plantReconfiguration(faults);
33: return true;
34: else
35: return false;
36: end if
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 95
per la primitiva set che gli permette di imporre precisi valori ai moduli. Il
modo migliore per vedere nel dettaglio come funziona è attraverso degli
esempi.
Nel paragrafo 5.1 abbiamo visto come la nozione di oracolo sia necessaria
per identificare un componente guasto. Questa a sua volta si basa sul con-
cetto di passaggio di stato. Per capire l’isolamento attivo bisogna partire da
qui.
Siano A,B due moduli del sistema con una implicazione diretta da A a B
(A → B). L’unico modo che abbiamo di diagnosticare il funzionamento
corretto dei due nodi, supponendo il nostro linguaggio booleano di riferi-
mento, è avere all’istante di tempo t, A = B = 0 e all’istante di tempo t+ 1
A = B = 1, cioè osservare su B una reazione a fronte di un’azione eseguita
da A. In questo modo i nodi, soggetti a passaggio di stato, funzionano.
Il manager attivo si basa su tale principio.
10
1
0
1
0
1
A
B
C
FE
D
G
Fig. 5.15: Un semplice ARG con un’inconsistenza su l’arco DE
Supponiamo di avere un modello di sistema con un ARG di figura 5.15.
La rappresentazione mostra i valori assunti da tutte le variabili di stato
dei moduli in un istante temporale. Il grafo è caratterizzato da una singola
inconsistenza su l’arco DE.
Il manager per prima cosa impone lo stato zero a tutti i nodi, dopodiché
prova a trovare un nodo corretto direttamente connesso a D e un altro (o lo
stesso) direttamente connesso aE, per esempio i nodiB eG. A questo punto
il manager impone uno sul nodo B e verifica se D cambia stato mettendo la
propria variabile a uno. Se avviene la transizione di stato B e D funzionano
altrimenti posso decretare il guasto di D solo se sono sicuro del corretto
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 96
funzionamento di B. La procedura verrà gestita in identico modo con G ed
E per capire se E funziona. Se E non funziona invece abbiamo bisogno di
un oracolo cioè di una coppia di nodi corretti che mi permettano di inferire
il guasto di E.
L’aspetto importante, volutamente tralasciato, è capire come trovare un
nodo corretto direttamente connesso a uno sospetto. A tal fine il manager
considererà tutti i nodi connessi ai sospetti (ad esempio per D terrà conto
di B,A,G) e per ognuno di essi proverà a costruire un oracolo con i nodi a
distanza uno che non sono sospetti. Proverà cioè a osservare un cambiamen-
to di stato sul nodo che osserva facendolo passare da zero a uno a seguito
dell’imposizione a uno sul nodo che attua. Nell’esempio in figura per il
nodo D l’oracolo sarà formato dalla coppia (B,C).
Quindi, per capire se un nodo è corretto, basta agire su uno ad esso inci-
dente (il funzionamento di D può essere capito agendo su A). Se un nodo è
guasto invece, bisogna avere a disposizione un oracolo (una coppia di nodi
su cui si è osservato il passaggio di stato) che significa fare due “hop” dal
nodo sospetto senza incontrare altri nodi sospetti (proprio come avevamo
enunciato durante la procedura di discovering).
Per dargli ancora maggiore risalto, mostriamo nel dettaglio i passi della
procedura d’isolamento che portano il manager attivo a risolvere l’incon-
sistenza DE sul grafo di figura 5.15 nel caso in cui entrambi i nodi siano
guasti. Mostriamo un caso fortunato poiché riusciamo a isolare due guasti
nonostante il valore di V F sia uguale a uno.
1. set(0,all). Settiamo tutti i nodi a zero.
2. Otteniamo i nodi non sospetti connessi a D = A,G,B.
3. Otteniamo i nodi non sospetti connessi a A = ∅.
4. Otteniamo i nodi non sospetti connessi a G = ∅.
5. Otteniamo i nodi non sospetti connessi a B = C
6. set(1,B).
7. Verifica il valore di C. Se è uno, C è corretto e B,C formano un oracolo
per D.
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 97
8. D, affetto da permanent value fault risponde zero e quindi è guasto.
9. set(0,all).
10. Otteniamo i nodi non sospetti connessi a E = G,F .
11. Otteniamo i nodi non sospetti connessi a G = ∅.
12. Otteniamo i nodi non sospetti connessi a F = C.
13. set(1,C).
14. Verifica il valore di F . Se è uno F è corretto e C,F formano un oracolo
per E.
15. set(0,all).
16. set(1,E).
17. F , che è corretto, risponde zero e quindi E è guasto.
L’algoritmo di isolamento attivo (algoritmo 4) prenderà in ingresso l’in-
sieme dei possibili guasti, e la struttura dati rappresentate la topologia del
grafo.
Esistono due modi per capire se un nodo n sospetto è guasto; attraverso
la costruzione di un oracolo per mezzo dei nodi che lo implicano o per
mezzo dei nodi che sono implicati.
Dato che un nodo è sospetto poiché ha generato un’inconsistenza, esso avrà
sicuramente almeno un arco entrante o uscente. Se non ci sono archi entranti
possiamo verificare se il nodo è guasto sollecitando un passaggio di stato
sul nodo n1 che implica. Per far ciò è necessario che il nodo implicato abbia
a sua volta dei nodi ad esso incidenti oppure abbia nodi ad esso adiacenti.
Una volta ottenuto il passaggio di stato su n1 possiamo concludere che tutti
i nodi che lo implicano e che sono sospetti (n e altri, se esistono) sono guasti.
Descriveremo l’algoritmo a un livello di astrazione elevata, per non ap-
pesantirne la lettura con troppi dettagli, supponendo di avere a disposizione
la funzione di creazione degli oracoli. Più precisamente, isOracoleFor(...)
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 98
Algoritmo 4 Fault isolation attiva
Input: graph g, Set possibleFaults
Output: print faults nodes
1: for all node ∈ possibleFault do
2: foundOracle = false; counter = 0;
3: if not node ∈ faults then
4: if |IN(node)| 6= ∅ then
5: for all in ∈ IN(node) do
6: if isOracleFor(in, node) then
7: foundOracle = true;
8: set(1, in);
9: if s(node) == 0 then
10: print FOUND A PVF in node;
11: faults.add(node); break
12: else
13: faults.addAll(foundFaultNeighbours(node, possibleFaults));
14: end if
15: end if
16: end for
17: else if |OUT (node)| 6= ∅ then
18: for all out ∈ OUT (node) do
19: if isOracleFor(out, node) then
20: foundOracle = true;
21: faults.addAll(foundFaultNeighbours(node, possibleFaults));
22: break;
23: end if
24: end for
25: else
26: print node cannot be detected;
27: end if
28: end if
29: if not foundOracle then
30: counter + +;
31: end if
32: end for
33: if counter == |possibleFault|andisCaseFavourableCriterion() then
34: apply criterio Casi Favorevoli
35: end if
CAPITOLO 5. FAULT DETECTION E FAULT ISOLATION 99
Algoritmo 5 Stabilimento dei guasti, vicini di un oracolo
Input: Node node, Set possibleFaults
Output: Faults modules set
1: Set result = newSet();
2: Set neighbour = nodes n s.t. n ∈ IN(node)orOUT (node);
3: for all item ∈ neighbour do
4: if item ∈ possibleFaults then
5: print FOUND A PVF in item;
6: result.add(item);
7: end if
8: end for
9: return result;
verificherà se il nodo passatogli come primo parametro è un oracolo per il
nodo passato come secondo parametro. Bisogna precisare che tale funzione
durante la costruzione dell’oracolo potrà incorrere in nuove inconsistenze
che andranno a incrementare la taglia dei possibili nodi sospetti.
Indicheremo con IN(n) e OUT(n) rispettivamente l’insieme di nodi che
implicano e che sono implicati da n mentre l’insieme faults servirà a me-
morizzare i componenti affetti da guasto scovati durante la procedura.
Anche se non inserito esplicitamente nello pseudo codice, se vengono trovati
dei guasti, bisognerà attivare la procedura di riconfigurazione dell’impianto.
L’algoritmo 4 si occupa di controllare chi tra i nodi sospetti sono real-
mente guasti. Una volta stabilito che un nodo è un oracolo ed è quindi
funzionante viene invocata la funzione foundFaultsNeighbour(...) (vedi Algo-
ritmo 5) la quale decreterà guasti tutti i vicini adiacenti o incidenti al nodo
funzionante, che sono sospetti (riga 33 algoritmo 4).
Se per ogni nodo sospetto, non riusciamo a trovare un oracolo, allora pos-
siamo, nel caso esista, decretare guasti i nodi coinvolti nel criterio dei casi
favorevoli. Esempi in cui ciò accade li abbiamo già discussi nel paragrafo
5.1.1.
6Dalla teoria alla pratica
Come conclusione a tale lavoro di tesi abbiamo deciso di realizzare un
impianto domotico, dove mettere in pratica tutta la teoria presentata nei
capitoli precedenti.
Questo capitolo si occupa di documentare tale processo di realizzazione.
Daremo per prima cosa un contributo all’azienda World Data Bus, che ci
ha fornito la centralina domotica per la realizzazione dell’impianto, descri-
vendone la struttura dei componenti e le modalità attraverso cui interagirci.
In particolare, presenteremo i moduli BMC e il bus EDS e mostreremo la
struttura che i messaggi devono possedere per poter transitare sul bus.
Passeremo quindi alla presentazione del programma, soffermandoci sulle
principali scelte implementative, come ad esempio la libreria utilizzata per
la comunicazione su porta seriale, e sulla sua architettura.
Il capitolo terminerà con la messa in funzione dell’impianto e l’esposizione
dettagliata dei principali casi d’uso d’interesse.
6.1 Il sistema EDS
Al fine di mettere in pratica anche su un sistema reale tutti i concetti
studiati, abbiamo realizzato un piccolo impianto domotico, costituito da tre
fari led e due sensori crepuscolari di luminosità (i tipici sensori utilizzati nei
condomini) il tutto opportunamente connesso alla centralina domotica di
World Data Bus.
100
CAPITOLO 6. DALLA TEORIA ALLA PRATICA 101
Costituita nel 2004 dopo aver rilevato l’intero know-how di un’azienda
che si è occupata per oltre un decennio di automazione, la World Data Bus
([1]) si occupa della produzione e della commercializzazione del sistema
EDS, coronamento di un progetto di ricerca che ha visto la creazione di una
soluzione tecnologica d’avanguardia, ideata con un preciso obiettivo: porta-
re i vantaggi di versatilità, economicità ed affidabilità dell’elettronica, sinora
riservati all’impiantistica elettrica di alto livello e al Building Automation,
anche nell’Home Automation e nell’installazione elettrica di base.
EDS ([1]) è un sistema a tecnologia Bus che si basa su moduli, detti BMC
(Blocchetti Monolitici Computerizzati), in grado di rilevare i cambiamenti di
stato in ingresso (ad esempio la pressione di un pulsante, la rilevazione di
una presenza, una fuga di gas, una perdita d’acqua o il variare di una soglia
di temperatura etc.) ed attivare una o più attuazioni (ad esempio accendere
una o più luci, attivare un’elettrovalvola, regolare un’intensità luminosa etc.)
a seconda della logica configurata.
La logica può essere modificata infinite volte con semplicità dall’installatore
o dal progettista senza la necessità di opere murarie. Ad ogni blocchetto
BMC possono essere collegati fino ad un massimo di otto dispositivi di
comando (o rilevazione) di qualsiasi tipo o marca sfruttando la semplicità e
la flessibilità dei contatti puliti; otto attuatori (relé o dimmer) configurabili
secondo personalizzabili modalità di funzionamento; un sensore infrarosso
per l’azionamento a distanza tramite un qualunque telecomando universale.
Qualunque comando impartito tramite un ingresso di un BMC, può rag-
giungere uno o più canali di uscita a piacere di un qualsiasi BMC presente
nell’impianto, azionando i relativi carichi tramite uscite transistor, relè, o
dimmer.
I BMC sono quindi in grado di svolgere autonomamente o in cooperazione
con altri BMC tramite un BUS, tutte le principali funzioni di Comando -
Attuazione tipiche di un impianto elettrico classico.
Gli impianti realizzati col sistema EDS possono supportare fino a 255
moduli collegati tra loro grazie ad un Bus proprietario (EDS) e disporre
quindi fino a 2040 punti di rilevazione o comando-attuazione. Ogni modulo
CAPITOLO 6. DALLA TEORIA ALLA PRATICA 102
viene identificato da un indirizzo univoco configurabile mediante un ap-
posito software (EDSConfig - EDS Configuration Software) e un’interfaccia
RS232 collegata ad un computer; grazie alla stessa interfaccia è prevista
la possibilità di gestione centralizzata e computerizzata dell’impianto, e
la conseguente implementazione di evolute funzionalità domotiche. Nel
nostro caso abbiamo implementato un modulo di rilevazione e isolamento
di guasti su un impianto, precedentemente configurato con EDSConfig, costi-
tuito da tre lampadine e due sensori di luminosità. Attraverso il software di
configurazione è stato possibile ad esempio mappare i bottoni responsabili
dell’accensione alle relative lampadine da accendere.
I moduli realizzano una separazione fisica tra i comandi (12 V) e l’attuazione
(220 V), azzerando i rischi di folgorazione ai comandi.
EDS è un sistema aperto. Prima di presentare le basi del protocollo di co-
municazione mostriamo alcuni vantaggi che si hanno con l’utilizzo di tale
sistema.
• Variare a piacimento tutte le funzionalità dell’impianto elettrico senza
la necessità di ulteriori modifiche del cablaggio.
• Impostare scenari gestionali e operativi.
• Ampliare con facilità l’impianto realizzato col sistema EDS grazie alla
sua forte modularità.
• Eliminare il rischio di folgorazioni ed esplosioni, il sistema EDS è
isolato dalla linea di esercizio 220 V.
6.1.1 Il protocollo di comunicazione EDS
Le seguenti informazioni sono tratte da [24]. É possibile trasmettere
messaggi sul Bus EDS tramite linterfaccia RS232 - EDS (int-PC). La confi-
gurazione della RS232 può essere con trasmissione asincrona a 1200 bps,
2400 bps, 9600 bps e 19200 bps, senza parità, 8 bit per carattere, 1 bit start e
1 bit stop. Nel nostro caso abbiamo usato i parametri di comunicazione di
default: 9600, 8, N, 1.
I messaggi di monitoraggio e controllo sono formati da 8 byte. La figura 6.1
né mostra i campi.
CAPITOLO 6. DALLA TEORIA ALLA PRATICA 103
Fig. 6.1: La composizione di un messaggio EDS
• STX - ETX (START - END TRANSMITION): Byte di inizio e fine tra-
smissione. Nella versione standard del protocollo tali campi valgono
STX = 2, ETX = 3.
• DESTINATARIO - MITTENTE: sono rispettivamente il nodo a cui è
destinato il messaggio e il mittente del messaggio inviato; nel caso di
messaggi di tipo broadcast questi due byte contengono il timestamp.
• TIPO MESSAGGIO: è l’identificativo del tipo di messaggio. Successi-
vamente vedremo una breve lista dei messaggi utilizzati.
• BYTE INFORMATIVO 1 - BYTE INFORMATIVO 2: contengono le
informazioni necessarie all’elaborazione da parte dei nodi EDS; ogni
messaggio utilizzerà informazioni differenti a seconda dell’esigenza.
• CHECKSUM: byte di controllo dell’integrità del messaggio. É calco-
lato facendo la somma di tutti i campi, esclusi i byte di inizio e fine
trasmissione, modulo 256.
Per informazioni più dettagliate sul bus EDS come ad esempio le prote-
zioni adottate sugli ingressi, sulle uscite, sull’alimentazione o per conoscere
le modalità e le tecniche di cablaggio, per avere dati più esaurienti riguar-
danti l’alimentazione o per venire a conoscenza dei problemi a cui si va
incontro con un alimentazione errata si invita il lettore a consultare [25].
6.2 La realizzazione dell’impianto
Abbiamo cercato di realizzare un impianto che ci permettesse di mettere
in pratica sia l’approccio di fault isolation passivo che quello attivo. La scelta
CAPITOLO 6. DALLA TEORIA ALLA PRATICA 104
è ricaduta in un possibile modello di stanza costituito da tre lampadine e
due sensori di luce.
Il modello, di cui si è già discusso durante il capitolo 4, permette la rileva-
zione e l’isolamento di due guasti; risultato che è stato ottenuto applicando
entrambi i criteri di fault isolation e dei casi favorevoli.
La figura 6.2 mostra le varie fasi di costruzione. L’impianto è dotato di:
1. Due sensori crepuscolari
2. Tre fari led
3. Un alimentatore barra din
4. Un interruttore differenziale
5. Un modulo BMC
6. Tre relays
7. Un trasformatore 220 V - 12 V (i comandi vengono impartiti con tale
livello di tensione)
8. Un programmatore USB
9. Un quadro elettrico
10. Tre pulsanti (per l’accensione) e tre interruttori (per la simulazione dei
guasti)
11. Frutti elettrici e una presa elettrica (utile per allacciare il computer alla
corrente di alimentazione)
12. Una valigia per gli attrezzi (per il packing)
Abbiamo scelto di far entrare tutto l’impianto in una valigetta così da
facilitarne il trasporto.
L’impianto ha una struttura molto semplice; sul bus EDS viene collegato un
solo modulo BMC mentre l’interfacciamento con il PC viene fatto per mezzo
del programmatore USB che ha il compito di adattare l’interfaccia USB con
quella seriale RS232.
CAPITOLO 6. DALLA TEORIA ALLA PRATICA 105
(a)
(b)
(c)
(d)
Fig. 6.2: Immagini scattate durante la realizzazione dell’impianto.
CAPITOLO 6. DALLA TEORIA ALLA PRATICA 106
Si sono impegnati cinque ingressi e tre uscite del BMC. I tre bottoni e i due
sensori sono stati collegati come ingressi del modulo mentre le tre lampadi-
ne occupano le uscite del BMC.
Ad ogni lampadina è stato collegato un relè, che verrà attivato a tempo
debito dal modulo BMC. Precisamente alla pressione del bottone il BMC si
accorge della variazione di un suo ingresso e grazie alla precedente configu-
razione eseguita via software, esegue l’attuazione stabilita, attivando il relè
corrispondente.
La simulazione dei guasti viene fatta da appositi interruttori che disattivano
il circuito di accensione. In questo modo viene prodotta un’inconsistenza del
tipo 1→ 0 poiché alla lettura dello stato dei dispositivi, eseguita attraverso
l’invio sul bus di un preciso tipo di messaggio, viene prodotta una rispo-
sta del tipo OUTi=1,IN3=IN4=0 dove abbiamo supposto di avere acceso la
lampadina collegata all’uscita i e i sensori agli ingressi tre e quattro.
6.3 La struttura dell’applicazione
In tale paragrafo ci occuperemo di mostrare l’architettura del program-
ma che implementa le funzionalità di detection e isolation. Mostreremo le
sequenze di azioni che coinvolgono gli scenari principali quali il guasto di
due lampadine, una lampadina e un sensore e due sensori.
L’interfacciamento a porta seriale è stato realizzato mediante la libreria
RxTx ([29]). Inzialmente la Sun (oggi è tutto in mano alla Oracle) forniva
un pacchetto chiamato javaxcomm ([26]). Gli utenti preferivano invece il
pacchetto RxTx (sviluppato altrove sotto licenza GNU) fino al punto che
Oracle non supporta più javaxcomm perché non c’era abbastanza interesse
da parte dell’utenza e quindi è finito nel dimenticatoio.
Descriverò i passi da compiere durante l’installazione solo sotto sistemi
Windows, poiché questo rappresenta il sistema operativo utilizzato. Per
l’installazione su altri sistemi si rimanda a [29].
Una volta scaricato il pacchetto ed aperto, all’interno troviamo la cartella
rxtx-2.1-7-bins-r2. Spostiamo quindi la cartella sul desktop e facciamo le
seguenti operazioni supponendo che Java sia installato (come fa in automa-
CAPITOLO 6. DALLA TEORIA ALLA PRATICA 107
tico il programma d’installazione) in c : \Programmi\Java\. La versione
di Java dipenderà da quella installata sul proprio computer; supponiamo di
avere la 1.6.0_23.
• Copiare rxtxSerial.dll che si trova nella cartella rxtx−2.1−7− bins−r2\windows\i368−mingw32 in c : \Programmi\Java\jre1.6.0_23\bin.
• Copiare RXTXcomm.jar che si trova nella cartella rxtx − 2.1 − 7 −bins− r2 in c : \Programmi\Java\jre1.6.0_23\lib\ext.
• Copiare rxtxSerial.dll che si trova nella cartella rxtx−2.1−7− bins−r2\windows\i368−mingw32 in c : \Programmi\Java\jdk1.6.0_23\jre\bin.
• Copiare RXTXcomm.jar che si trova nella cartella rxtx − 2.1 − 7 −bins− r2 in c : \ProgramFiles\Java\jdk1.6.0_23\jre\lib\ext.
Queste sono le principali classi dell’applicazione:
Gui.java. La classe responsabile della creazione dell’interfaccia grafica per
la creazione della quale vengono utilizzate le librerie Swing e Awt già
comprese nel Java Development Kit (JDK).
L’interfaccia usa una JTextArea all’interno della quale vengono caricati i
messaggi per l’utente e al lancio dell’applicazione mostra in una JCom-
boBox tutte le porte seriali disponibili sulla macchina. Queste vengono
caricate per mezzo di opportuni metodi di RxTx. Sarà compito dell’u-
tente conoscere quale porta seriale si utilizza per l’interfacciamento
con il bus EDS. La connessione avviene per mezzo di un apposito
bottone ed è gestita dalla classe SerialPortCommunication.java.
SerialPortCommunication.java. Rappresenta la classe responsabile della
gestione di tutta la comunicazione con la porta seriale. Le funzioni
principali riguardano l’attivazione e la disattivazione della connessio-
ne e la scrittura e la lettura su e da porta seriale.
La connessione viene eseguita dal metodo portInit(...) che in prima fase
si occupa di aprire la porta seriale e di settare i parametri di comuni-
cazione (la frequenza di trasmissione, il numero di bit di stop, il tipo
di parità e di controllo di flusso). Successivamente, vengono aperti
CAPITOLO 6. DALLA TEORIA ALLA PRATICA 108
gli streams per l’invio e la ricezione dei messaggi e viene installato
l’ascoltatore di eventi (RxTx è una libreria event-driven). Ogni qual
volta sulla porta seriale arrivano dei byte viene generato un evento
che viene gestito dal metodo SerialEvent(...).
L’invio di messaggi sulla porta seriale avviene interagendo con il clas-
sico metodo write(...) degli streams.
La chiusura della porta di comunicazione avviene attraverso il meto-
do portClose(...) che si occupa anche della rimozione dell’ascoltatore
installato e dell’interruzione, se esistono, di threads pendenti.
DetectionThread.java. Il thread svolge entrambe le funzioni di rilevazione
di un’inconsistenza e sua risoluzione. Viene attivato in base ad un flag
che permette di distinguere se si è in fase di isolamento o meno.
Rappresenta il cuore del programma. Alla sua prima attivazione il
thread si occuperà di verificare se è presente un’inconsistenza andan-
do a leggere lo stato dei dispositivi del sistema. Lo stato, così come
la topologia del grafo, viene gestita tramite una classe Singleton per
garantirne la presenza di un’unica istanza a run time. Tale manager
memorizza per ogni ingresso e uscita del sistema lo stato all’istante t e
t− 1 in modo da controllare con facilità la presenza di un passaggio di
stato.
Una volta verificata l’inconsistenza, se non la si riesce a risolvere “im-
mediatamente” (poiché c’è stato un passaggio di stato che ci permette
di capire qual’è il componente guasto) o con la procedura di isolamen-
to passiva, si visita il grafo alla ricerca degli elementi da attivare per la
creazione dell’oracolo che, una volta trovati, vengono passati al thread
TurnOnthread.
TurnOnThread.java. Il thread preposto all’attivazione degli elementi (in
questo caso si possono accendere le sole lampadine) per la creazione
di un oracolo. Questo viene fatto per mezzo dell’invocazione di un
opportuno metodo di SerialPortCommunication che si occupa di inviare
sul bus il tipo di messaggio voluto.
Segue la riattivazione del DetectionThread per capire dove si è verificato
il guasto. A questo punto sono attivi entrambi i thread dell’applicazio-
CAPITOLO 6. DALLA TEORIA ALLA PRATICA 109
ne e attraverso una loro coordinazione si riesce a risolvere il problema.
A ogni accensione si prova sempre prima a risolvere il problema con la
procedura passiva. Se non ci si riesce allora si passa all’attiva. Quindi,
se si trovano una coppia di nodi funzionanti vengono decretati i vicini
di tali nodi guasti, purché appartengano ai nodi sospetti, altrimenti
si riattiva il TurnOnThread che, se possibile, accenderà qualche altra
lampadina.
Il gioco si ripete finché non si trova un oracolo o finiscono le lampa-
dine da accendere. In quest’ultima situazione si applica il criterio dei
casi favorevoli e si decretano guasti i due sensori. In realtà però non
si arriva mai a ciò per il semplice fatto che il guasto rilevabile con il
criterio prima detto è rilevabile anche con la procedura passiva che
viene eseguita sempre per prima.
La comunicazione con la porta seriale avviene attraverso l’utilizzo di
messaggi. I tipi utilizzati sono stati i seguenti. Forniremo solo una breve
descrizione. Per maggiori dettagli inerenti i byte che né compongono la
struttura interna consultare [24].
• VARIAZIONE DI UN INGRESSO. Comunica la variazione di un
ingresso indicando il numero dell’uscita da comandare, l’attivazione o
la disattivazione e la modalità di variazione dell’ingresso. La modalità
di attuazione dell’uscita dipende dalla configurazione attribuitagli.
• ACKNOWLEDGE. Viene utilizzato dal sistema come risposta di av-
venuto comando; ad esempio, a fronte del messaggio inviato su varia-
zione di un ingresso digitale, ci sarà la successiva attuazione da parte
del modulo destinatario, il quale, a comando avvenuto, invierà un
ACK al mittente (quello su cui è variato l’ingresso); tale ACK, oltre a
fermare eventuali ritrasmissioni da parte del modulo mittente, garanti-
sce che i messaggi che transitano sul bus arrivino sempre e comunque
a destinazione.
• ATTIVAZIONE/DISATTIVAZIONE DI UN’USCITA. Utilizzato da
SW per la gestione ed il controllo. Permette di disattivare o attivare
un’uscita di un BMC o di un dimmer.
CAPITOLO 6. DALLA TEORIA ALLA PRATICA 110
Fig. 6.3: Il modello di sistema rappresentate l’impianto realizzato
.
• RICHIESTA LETTURA STATO DISPOSITIVO. Permette di leggere
lo stato di ingressi e uscite di un BMC o di un dimmer.
• RISPOSTA LETTURA STATO DISPOSITIVO. Risponde lo stato di
ingressi (aperto/chiuso) e di uscite di un BMC (on/off).
Altra caratteristica dell’applicazione è la possibilità di fare la restore di
un dispositivo scoperto precedentemente guasto. Tale funzionalità esegue
compiti esattamente inversi alla riconfigurazione dell’impianto invocata a
seguito di guasti. Se con la riconfigurazione andiamo a eliminare dal grafo i
moduli guasti e tutte le connessioni esistenti con i moduli funzionanti, con
il ripristino andiamo a riattivarli.
6.4 Possibili scenari
Concludiamo il capitolo con la presentazione di alcuni tra gli scenari più
importanti relazionati al funzionamento dell’impianto.
L’applicazione una volta inseriti il numero di lampadine e il numero di
sensori di cui è dotato il sistema attiva la procedura di discovering per il
calcolo di V F . Come sappiamo, tale procedura, applicata sul grafo di figura
6.3 conduce a un valore pari a due. L’immagine del tutto uguale a 5.8 viene
riportata esclusivamente per facilitare la lettura.
Iniziamo presentando il sequence diagram riguardante la rottura di una
lampadina. Supponiamo di rompere la lampadina uno. La figura 6.4 mostra
CAPITOLO 6. DALLA TEORIA ALLA PRATICA 111
Fig. 6.4: Il sequence diagram riguardante l’isolamento di un singolo guasto
CAPITOLO 6. DALLA TEORIA ALLA PRATICA 112
la sequenza di azioni generate dalla connessione a porta seriale fino all’isola-
mento del guasto. Dato la ripetitività delle azioni in figura ci siamo fermati
alla risoluzione del singolo guasto, ma ciò rappresenta un buon punto di
partenza per estendere il discorso anche a casi più complessi.
Una volta accesa la lampadina e fatto partire il thread di detection, per prima
cosa dobbiamo farlo attendere per un tempo necessario ai sensori di scattare
in presenza di luce. Nel nostro caso il tempo di attesa è pari a 25sec.
Trascorso il tempo di attesa viene invocato il metodo per la lettura dello
stato del BMC. Questo, altro non fa che inviare sul bus al BMC un messaggio
di tipo RICHIESTA LETTURA STATO DISPOSITIVO. Il thread va di nuovo
in attesa finché su l’interfaccia RS232 arriva la risposta. La classe SerialPort-
Comunication né effettua il parsing dopodiché riattiva il thread.
Il thread a questo punto si accorge dell’inconsistenza tra L1 e (S1, S2) e ese-
gue la procedura d’isolamento passiva. Questa non produce alcun risultato
e quindi viene attivato il thread turnOn che avrà il compito di creare oracoli
attraverso l’accensione delle restanti lampadine.
L’azione 11 di figura 6.4 ha lo scopo di accendere la lampadina L2. L’iter che
viene seguito è sempre lo stesso: viene invocato il metodo di SerialPortComu-
nication che a sua volta invia il messaggio ATTIVAZIONE DI UN’USCITA
sul bus EDS. Alla ricezione del messaggio ACK viene creato un nuovo Detec-
tionThread che nell’immagine abbiamo chiamato isolation per distinguerlo
dal precedente che eseguiva solo la detection.
Siccome la lampadina accesa non è rotta, i sensori trascorsi i 25sec scatte-
ranno. Il thread isolation in questo modo si accorgerà del passaggio di stato,
decreterà funzionanti i dispositivi (L2, S1, S2) e guasti i dispositivi sospetti
ad essi connessi (in questo caso L1). Risolta l’inconsistenza interromperà il
thread turnOn e terminerà la propria esecuzione.
L’oggetto, istanza delle classe SerialPortComunication terminerà la propria
esecuzione all’uscita dell’applicazione.
Avendo bene in mente questo schema è possibile mostrare anche i casi
più interessanti in cui si guastano due dispositivi simultaneamente. La
sequenza di azioni generata altro non è che un’estensione del diagramma di
sequenza descritto precedentemente.
CAPITOLO 6. DALLA TEORIA ALLA PRATICA 113
Guasto di due lampadine. Supponiamo che siano guaste (L1, L2). Il flusso
di azioni è identico fino alla numero 23. In tal caso la procedura di
isolamento attiva scopre un ulteriore inconsistenza tra la lampadina
L2 accesa e i sensori (S1, S2) e invece di interrompere il thread di ac-
censione lo riattiva. Questo a sua volte invoca l’accensione dell’ultima
lampadina rimasta L3. Segue la ripetizione del ciclo di azioni dalla 11
alla 23. La procedura passiva fallisce nuovamente poiché il numero di
implicazioni inconsistenti presenti su ogni sensore è uguale al valore
di V F e non maggiore, mentre la procedura attiva crea la coppia di
oracoli formata dai nodi (L3, S1) e (L3, S2) grazie alla quale decreta il
guasto delle lampadine (L1, L2).
Guasto dei due sensori. Una volta introdotto il caso dei guasti su due lam-
padine è facile mostrare cosa succede con il guasto dei due sensori.
Tornando al caso appena discusso, l’accensione della lampadina L3,
genera un ulteriore inconsistenza tra L3 e i sensori (S1, S2). Questa
volta però la procedura di isolamento passiva va a buon fine perché
trova un numero di inconsistenze su entrambi i sensori pari a tre
(maggiore di V F che vale due) e quindi può affermarli guasti.
Guasto di una lampadina e un sensore. Supponiamo che i guasti riguar-
dano, in modo del tutto casuale, (L1, S2). Rappresenta il caso più
semplice tra quelli analizzati. Per capire cosa succede in questo ca-
so basta osservare il sequence diagram di figura 6.4. Esso è del tutto
valido anche con il guasto di una lampadina e un sensore. Avremo
sempre l’accensione di una seconda lampadina. Ciò che cambia è
esclusivamente il risultato prodotto durante l’azione 23. In questo
caso all’accensione di L2, scatterà un solo sensore (il corretto). La cop-
pia (L2, S1), soggetta a passaggio di stato, funziona correttamente e
quindi i moduli guasti sono (L1, S2).
7Conclusioni
Scopo di questo lavoro è stata la creazione di una teoria atta a risolvere il
ben noto problema di rilevazione ed isolamento di guasti in ambienti domo-
tici, ovvero in sistemi rappresentabili come reti di sensori e attuatori dove le
tecniche classiche, quali le procedure basate sull’utilizzo di “heartbeat”, non
sono applicabili oppure risultano poco accurate.
Abbiamo sviluppato una procedura collaborativa basata sulla conoscenza
della topologia del sistema, a sua volta creata mediante un’oppurtuna rap-
presentazione per mezzo di grafi azione reazione.
Il presente lavoro rappresenta un ulteriore ricerca nel campo della fault
detection basata su modello. La crescente diffusione che stiamo osservando
nell’ambito della home automation rende l’ARG un importante tool per la
rilevazione di malfunzionamenti. In futuro si potrebbe cercare di estendere
l’uso di grafi azione reazione a contesti diversi dagli scenari domotici qui
affrontati.
Questi sono i contributi originali che emergono dal nostro lavoro:
• Studio delle tecniche esistenti nel campo dell’automatica e della com-
putazione distribuita inerenti il problema di fault detection e fault
isolation.
• Creazione di un nuovo modello di sistema domotico basato sul grafo
azione reazione.
114
CAPITOLO 7. CONCLUSIONI 115
• Identificazione di approcci per la risoluzione del problema di FDI. In
particolare abbiamo sviluppato l’approccio passivo e quello attivo.
• Sviluppo di algoritmi centralizzati rappresentanti gli approcci creati.
• Realizzazione di un piccolo impianto domotico su cui si sono imple-
mentati gli algoritmi sviluppati.
Inizialmente abbiamo presentato una panoramica sulla terminologia di
base, i concetti essenziali di fault detection e fault isolation, inquadrandoli
come elementi fondamentali dei sistemi dependable.
Il capitolo tre espone le tecniche oggi esistenti che si occupano del problema
di FDI e propone come queste vengono usate in differenti contesti. Ci siamo
focalizzati sulle applicazioni critiche (il settore automobilistico in particola-
re), sul settore software e per finire abbiamo proposto un recente approccio
sviluppato per il progetto SM4ALL.
Il capitolo quattro narra l’ideazione di un nuovo modello per la rappre-
sentazione di tali sistemi basato sull’utilizzo di grafi, da noi definiti azione
reazione, e vede la formalizzazione della tipologia di guasto, il permanent
value fault, a cui la teoria volge l’attenzione. Ci siamo occupati di problemi
reali, di situazione non risolvibili con le tecniche oggi esistenti come ad
esempio sensori di luce coperti da magliette o occlusi dalla polvere.
Il capitolo cinque rappresenta il cuore dell’intero lavoro. Qui spieghiamo
come viene risolto il problema, presentiamo la procedura di discovering e
la procedura d’isolamento attiva e passiva. I risultati sperimentali ottenuti
per mezzo dei test effettuati sulla procedura di discovering mostrano la
complessità del problema trattato, legato soprattutto alla sua natura deter-
ministica. Con la versione ottimizzata i risultati migliorano nettamente e
i tempi, anche se ancora elevati, risultano accettabili grazie al fatto che la
procedura viene eseguita una sola volta.
Per far fronte a tale inconveniente un lavoro futuro potrebbe essere quello
di affrontare il problema attraverso un approccio probabilistico e non più
deterministico. In questo modo si abbatterebbero di sicuro i tempi d’ese-
cuzione ma necessariamente va eseguita una riorganizzazione dell’intera
teoria.
CAPITOLO 7. CONCLUSIONI 116
Un altro possibile e interessante sviluppo, meno devastante rispetto al pre-
cedente, potrebbe essere quello di riformulare le procedure sviluppate senza
avere a disposizione il punto di vista globale, posseduto dal manager del
sistema sotto monitoraggio. La creazione di una soluzione distribuita, con
gli ovvi vantaggi del caso, si concluderebbe con l’analisi delle prestazioni
tra i due diversi approcci (con e senza manager).
L’ultimo capitolo vede la messa in pratica della teoria, su di un semplice
impianto domotico costituito da tre lampadine e due sensori di luce, in
grado di rilevare ed isolare, in maniera deterministica, fino a due guasti
contemporanei. Un ulteriore passo in questa direzione, non realizzato per
mancanza di tempo, potrebbe essere l’integrazione dell’impianto all’inter-
no della casa domotica, presente in fondazione Santa Lucia, progettata e
costruita per il progetto SM4ALL.
Bibliografia
[1] World data bus. http://www.worlddatabus.com. Sede operativa:Via
dell’Industria 28885 - Piedimulera (VB). Sede legale: Via Dei Platani
28803 - Premosello (VB).
[2] Luigia Carlucci Aiello and Fiora Pirri. Strutture, Logica, Linguaggi.
Pearson Addison Wesley, prima edition, 2005. Capitolo 2.
[3] Algirdas Avizienis, Jean-Claude Laprie, and Brian Randell. Funda-
mental concepts of dependability. LAAS Report no. 01-145, Aprile
2001.
[4] Rolando Bianchi Bandinelli. Gli elementi base della domotica. Mate-
riale didattico per il corso di domotica, Istituto di Scienza e Tecnologie
dell’Informazione Consiglio Nazionale delle Ricerche, 2005.
[5] R. Bettocchi, M. Pinelli, P. R. Spina, and M. Venturini. Tecniche per il
rilevamento e l’isolamento dei guasti ai sensori di misura. Associazio-
ne italiana di manutenzione XXI Congresso Nazionale. La Manutenzione:
Processi e Competenze, Milano 15-16 settembre 2004.
[6] Paul E. Braisted and Martin Beckmann. Fault detection and exclusion me-
thod for naavigation satellite receivers, September 15 1998. Patent Number
5,808,581.
117
BIBLIOGRAFIA 118
[7] Bill Brykczynski. A survey of software inspection checklists. ACM
SIGSOFT, 24(1):82–89, January 1999.
[8] Carlo Casolo. Appunti di teoria dei grafi. Technical report, 2004-2005.
[9] Bruno Ciciani and Francesco Quaglia. Sistemi affidabili ed in tempo
reale. Technical report, SAPIENZA Università di Roma, 2000.
[10] Viktoriya Degeler and Alexander Lazovik. Interpretation of incon-
sistencies via context consistency diagrams. PerCom, pages 20–27,
2011.
[11] I. Eyal, I. Keidar, and R. Rom. Distributed clustering for robust
aggregation in large networks. HotDep09. IEEE, 2009.
[12] Riccardo Ferrari. Distributed Fault Detection and Isolation of Large-scale
Nonlinear Systems: and Adaptive Approximation Approach. PhD thesis,
Department of Electrical, Electronic and Computer Engineering of the
University of Trieste, 2007/2008.
[13] P. Frank. Fault diagnosis in dynamic systems using analytical and kno-
wledge based redundancy a survey and some new results. Automatica
J. IFAC, 26(3):459–474, 1990.
[14] Rachid Guerraoui and Luis Rodrigues. Introduction to Reliable
Distributed Programming. Springer, 2006.
[15] http://www.sm4all project.eu/, Dicembre 2008. An EU STREP Project
FP7-224332.
[16] R. Isermann. Fault-Diagnosis Systems: An Introduction from Fault
Detection to Fault Tolerance. Springer, 2006.
[17] Rolf Isermann. Model-based fault detection and diagnosis: status and
applications. In In Proceedings of the 16th IFAC Symposium on Automatic
Control in Aerospace, St, pages 71–85, 2004.
[18] R.K. Iyer and Z. Kalbarczyk. Hardware and software error detection.
ECE 442/CS 436 - Design of Reliable Systems and Networks, 2003.
BIBLIOGRAFIA 119
[19] Libreria JGraphT. http://www.jgrapht.org/.
[20] David J. Klassen and Edward G. Anderson. Fault detection and isolation
in automotive wiring harness by time-domain reflectometry, December 7
1993. Patent Number: 5,268,644.
[21] AT&T Research Labs. Graph visualization software.
http://www.graphviz.org.
[22] Laslie Lamport, Robert Shostak, and Marshall Pease. The byzantine
generals problem. ACM Transactions on Programming Languages and
Systems, 4(3):382–401, July 1982.
[23] L. Magni, R. Scattolini, and C.Rossi. A fault detection and isolation
method for automotive engines. IEEE/ASME International Conference on
Advanced Intelligent Mechatronics, September 19-23 1999.
[24] Fisco Matteo. PROTOCOLLO DI COMUNICAZIONE BUS EDS. World
Data Bus.
[25] Fisco Matteo. SPECIFICHE SISTEMA EDS. World Data Bus.
[26] Oracle. Java communications api.
http://www.oracle.com/technetwork/java/index-jsp-141752.html.
[27] Roger S. Pressman. Principi di Ingegneria del Software. McGraw-Hill,
Ottobre 2007. Quinta edizione.
[28] B. Randell, Jean-Claude Laprie, H. Kopetz, and B. Littlewood.
Predictably Dependable Computing Systems. Springer-Verlag ed., 1995.
[29] Libreria RxTx. http://rxtx.qbang.org/wiki/index.php.
[30] T. I. Salsbury and Johnson Controls Inc. Implementation and testing of a
fault detection software tool for improving control system performance
in a large commercial building.
[31] Antonio Sassano. Modelli e Algoritmi della Ricerca Operativa. Scienze e
tecnologie informatiche. Franco Angeli, 1999. Capitolo 1.
BIBLIOGRAFIA 120
[32] Romano Scozzafava. Incertezza e probabilità. Zanichelli, marzo 2001.
Prima edizione.
[33] T. Tsuchiya and A. Schiper. Using bounded model checking to verify
consensus algorithms. Distributed Computing, pages 466–480, 2008.