FACOLTÀ DI I NGEGNERIA CORSO DI LAUREA IN I NGEGNERIA I NFORMATICA Tesi di Laurea Magistrale Fault detection e isolation per sistemi domotici Candidato Relatore Mariano Leva Ing. Leonardo Querzoni Correlatore Dott. Adriano Cerocchi Anno Accademico 2010/2011
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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.
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)