Fault isolation esperta per sistemi domotici

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?


Il seguente lavoro ha lo scopo di proporre una tecnica nuova capace di imple-

mentare un modulo per la rilevazione e l’isolamento di guasti in un sistema

distribuito dinamico e più precisamente all’interno di sistemi caratterizzati

da scenari domotici. Il nostro approccio si basa sull’analisi, eseguita a run-

time, di grafi. Introduciamo il grafo azione reazione, un grafo orientato in

cui vengono mappate le inter-dipendenze esistenti tra i differenti dispositivi

del sistema al fine di rilevare i value faults e possibilmente isolarli. Abbiamo

investigato su due possibili modalità di isolamento del guasto che abbiamo

definito passiva (osservando semplicemente lo stato) e attiva (modificando

lo stato corrente). Il resto del documento è organizzato come segue.

Il secondo capitolo tratterà i concetti fondamentali di tale lavoro, la termino-

logia di base necessaria alla comprensione del problema in generale. Verrà

proposta una introduzione sui motivi che hanno condotto allo studio della

fault detection e isolation. Verranno quindi presentati i sistemi dependable e

verranno messi in mostra le caratteristiche che devono possedere per essere

considerati tali. Descriveremo gli aspetti fondamentali della dependability,

le sue proprietà, le minacce e gli strumenti. In particolare, mostreremo le

diverse tipologie di guasti esistenti, utilizzando la classificazione fornita

da Laprie et all in [3], e discuteremo dei due diversi modi che la letteratura

utilizza per riferirsi alle due fasi della fault tolerance, di cui la rilevazione e

l’isolamento dei guasti fanno parte.

Nel terzo capitolo presenteremo lo stato dell’arte nella FDI (fault detection

and isolation). Inizieremo descrivendone la storia, le diverse tecniche che

si sono susseguite nel corso degli anni, proponendo per ognuna di esse,

interessanti casi di studio.

Focalizzeremo la nostra attenzione nel settore delle applicazioni critiche

(quello automobilistico in particolare) dove analizzeremo nel dettaglio una

tecnica di FDI basata su composizione sincrona di macchine a stati e una

basata sull’utilizzo del TDR.

Altro settore analizzato è il software dove andremo ad esporre le strategie

di testing esistenti in letteratura e i passi di cui si compongono, differenzian-

doli in base ai due principali paradigmi di programmazione. Effettueremo

un’ampia descrizione delle classi di test esistenti e concluderemo il para-

grafo con una sommaria presentazione delle tecniche utilizzate per la loro


realizzazione.

Il capitolo termina con un esempio di applicazione di FDI sviluppato an-

ch’esso nell’ambito del progetto SM4ALL. Viene proposta una soluzione

adatta a sistemi pervasivi context-aware in cui si sviluppa una particolare

struttura dati, che raccogliendo le varie informazioni ottenute dai sensori, è

in grado di calcolare la probabilità dei possibili stati dell’ambiente.

Il capitolo quattro narra i principali modelli sottesi alla teoria sviluppata;

il modello di sistema e il modello di guasto. Inizialmente caratterizzeremo

l’architettura dei sistemi domotici cosi da capire cosa modellare. Sviluppe-

remo un primo modello molto specifico che abbandoneremo per far posto

ad uno più completo e generale. É qui che nasce il grafo azione reazione.

Presenteremo tutti i suoi componenti; i moduli, il manager e il linguaggio

del sistema.

Nel secondo verrà definito il concetto di permanent value fault; descrivere-

mo il comportamento di un modulo affetto da guasto e ne inquadreremo la

classe di appartenenza in base alla classificazione proposta nel capitolo due.

Il capitolo cinque tratta la soluzione che abbiamo ideato. É qui che spieghia-

mo le due fasi in cui risolviamo il problema.

La prima consiste nel calcolo del numero massimo di permanent value

fault isolabili simultaneamente dal sistema. Questo è fatto per mezzo della

procedura di discovering. L’algoritmo alla base verrà descritto nel dettaglio,

faremo numerosi esempi e porremo in luce i risultati notevoli raggiunti,

che ci permetteranno di sviluppare due versioni dell’algoritmo sulle quali

confronteremo le performance.

La seconda parte è costituita dalla procedura di fault isolation. La fault iso-

lation passiva cercherà di capire chi è il componente guasto semplicemente

osservando lo stato del sistema e utilizzando l’informazione calcolata dall’al-

goritmo di discovering, mentre la fault isolation attiva potrà, in aggiunta,

imporre la transizione del sistema per particolari stati. Mostreremo entrambi

gli algoritmi e chiariremo il tutto con vari esempi.

L’ultimo capitolo prima delle conclusioni, tratta la realizzazione di un picco-

lo impianto domotico su cui è stata implementata tutta la teoria sviluppata.

Viene svolta una presentazione del sistema EDS, sviluppato da World Data

Bus, rappresentante le “fondamenta” di tutto l’impianto, descrivendone


l’architettura e il protocollo di comunicazione. Successivamente documen-

tiamo la struttura dell’impianto, costituito da tre lampadine e due sensori di

luminosità, e quella dell’applicazione. Il capitolo termina mostrando alcuni

scenari possibili e la sequenza d’azioni, da essi generati, che conducono

all’isolamento dei componenti guasti.

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


Fig. 2.1: Gli attributi fondamentali della dependability

troppo nel dettaglio, rimandando i lettori interessati a [9, 3, 28], gli attributi

di riferimento, come si può notare guardando la Fig. 2.1 sono:

• Disponibilità (availability). Definita come la probabilità che il sistema

non mostri malfunzionamenti nell’istante in cui gli è richiesto di ope-

rare. Offre quindi, una misura del corretto funzionamento del sistema

ad un dato istante temporale.

• Affidabilità (reliability). Definita come la probabilità che il sistema non

mostri malfunzionamenti in un intervallo temporale a condizione

che nessun malfunzionamento esisteva all’inizio dell’intervallo. In

parole più semplici, l’affidabilità è la probabilità che il sistema funzioni

correttamente in un dato intervallo temporale.

• Sicurezza (safety). Definita come la probabilità che il sistema non mostri

malfunzionamenti nell’istante in cui gli è richiesto di operare, oppure

nel caso in cui esistano, questi non compromettano la sicurezza di

persone o impianti relazionati al sistema stesso.

• Confidenzialità (confidentiality). Assenza di diffusione non autorizzata

di informazioni.

• Integrità (integrity). Assenza di alterazioni improprie dello stato del

sistema.


• Manutenibilità (maintainability). Rappresenta una misura della facilità

con la quale un sistema può essere riparato una volta manifestatosi il

malfunzionamento.

Questi gli attributi principali. Esistono poi anche degli attributi “secon-

dari” che possono essere visti come la combinazione o una specializzazione

degli attributi elencati in precedenza.

Laprie et all in [3] citano ad esempio la security (protezione) definita come

l’assenza sia di accessi non autorizzati al sistema, sia di gestioni (sempre

non autorizzate) del suo stato. Può essere vista quindi, come racchiudente

in se le nozioni di integrity, confidentiality e availability.

2.2.2 Le minacce

I tre termini comunemente usati nella descrizione degli ostacoli per la

dependability sono: guasto, errore e malfunzionamento (detto anche fallimento),

rispettivamente traduzione di fault, error, e failure. I guasti sono l’origine

degli errori i quali poi possono dar luogo ai malfunzionamenti.

• Guasto (fault). Tipicamente, un guasto è una imperfezione in qualche

componente hardware o software che può derivare da malfunziona-

menti di componenti, interferenze ambientali di natura fisica, sbagli

dell’operatore o da una progettazione fallace. Esso può o meno, dare

luogo ad un errore.

• Errore (error). Viene comunemente definito come una deviazione dello

stato del sistema dai possibili stati previsti. La presenza di un errore

non necessariamente fa si che il sistema esegua qualche sua funzione

in maniera non corretta. In ogni caso, se questo accade allora siamo in

presenza di un malfunzionamento.

• Malfunzionamento (failure). Viene definito come una transizione, cau-

sata da errori, da uno stato di “servizio corretto” a uno stato di “servi-

zio non corretto”. Il malfunzionamento può essere visto come la non

corretta esecuzione di una funzione sia in termini quantitativi che in

termini qualitativi. Nel primo caso il sistema garantisce l’esecuzione


della funzionalità per cui è stato progettato ma a regime ridotto, nel

secondo caso non la garantisce.

Nel seguito diremo che un guasto è attivo nel momento in cui produce un

errore, altrimenti lo indicheremo come dormiente.

Diremo inoltre, che un errore è rilevato se la sua presenza è rilevata dal siste-

ma (per esempio tramite un messaggio di errore), altrimenti lo indicheremo

come latente.

Il nesso logico esistente tra guasto, errore e malfunzionamento, chia-

ramente deducibile dalle definizioni di tali termini viene chiamato catena

guasto-errore-fallimento. Poiché il fallimento di un componente, dovuto alla

propagazione dell’errore dai componenti interni del sistema all’interfaccia di

quest’ultimo, può rappresentare un guasto esterno per un altro componente,

la catena è ricorsiva (Fig. 2.2).

Fig. 2.2: Catena guasto - errore - fallimento

Laprie et all in [3, 28] propongono anche una dettagliata classificazione

di questi tre tipi di impedimenti.

Cominciamo dai fault. Vengono classificati tenendo conto delle cause che li

hanno generati. Troviamo sei diverse voci(Fig. 2.3)

• Fase di occorrenza. Specifica se il guasto è originato durante la realizza-

zione (progettazione ed implementazione) del sistema, oppure occorre

durante il normale funzionamento.

• Fenomenologia. Distinzione tra guasti fisici, ovvero originati da con-

dizioni fisiche estreme, quali per esempio eccessive interferenze elet-

tromagnetiche, e guasti “umani”, originati invece da “imperfezioni”

dell’uomo (esempio un comando errato impartito da un operatore

umano).


Fig. 2.3: Le diverse modalità di guasto esistenti

• Natura del guasto (dominio). Specifica il tipo (guasto hardware o soft-

ware oppure è un guasto che riguarda la parte analogica o digitale?).

• Estensione (Confini del sistema). Se i guasti sono localizzati dentro al

sistema si parla di internal faults, altrimenti di external faults.

• Intento. Comportamenti non corretti delle persone possono causare

guasti colposi (accidental faults), o dolosi (deliberately malicious faults).

• Durata (persistenza). Identifica l’intervallo temporale in cui un guasto

si manifesta. Possiamo suddividere ulteriormente tale caratteristica in:

1. Transiente. Il guasto si manifesterà ad un dato istante temporale e

scomparirà autonomamente senza che alcuna azione correttiva

esterna venga effettuata.

2. Permanente. Il guasto si manifesterà per sempre a meno che

un’azione correttiva non venga apportata.

3. Intermittente. Il guasto appare e scompare autonomamente in

maniera ripetuta.

Questo permette di definire una tassonomia dei guasti, che possono

essere categorizzati e suddivisi in design faults, phisical faults e interaction


Fig. 2.4: Tassonomia dei guasti

faults (Fig. 2.4).

All’interno di questo lavoro tratteremo solo i guasti permanenti, ma di que-

sto discuteremo ampiamente nei capitoli successivi.

Per quanto riguarda gli errori invece, non esiste una classificazione preci-

sa come per i guasti e i malfunzionamenti. Quest’ultimi vengono classificati

sulla base di quattro aspetti ([3, 28]) (vd. Fig. 2.5):

1. Dominio: divide i malfunzionamenti in base al valore e agli effetti

temporali. L’erogazione di un servizio dal sistema può rappresentare

un value failure, se il valore del servizio erogato dal sistema non si

conforma alla specifica, o un timing failure, se invece è il tempo in cui

tale servizio è fornito che non soddisfa la specifica.

2. Consistenza: indica la percezione, consistente o inconsistente, del mal-

funzionamento esistente tra gli utenti del sistema.


Fig. 2.5: La classificazione dei malfunzionamenti

3. Controllabilità: riguarda l’esistenza o meno di precise modalità di falli-

mento ovvero la presenza di regole di comportamento da rispettare in

caso di tale evento.

4. Conseguenze: banalmente, indica gli effetti che il malfunzionamento ha

sulla popolazione. Possono essere benigni o catastrofici.

Tale lavoro, si focalizza sui value failure che verranno ripresi e trattati

nei capitoli successivi.

2.2.3 Gli strumenti

L’ultima proprietà che caratterizza la dependability riguarda le tecniche

e le metodologie progettuali che né garantiscono l’esistenza. Lo sviluppo

di un sistema dependable prevede infatti l’impiego combinato di quattro

tecniche:

• Prevenzione dei guasti (fault prevention): come prevenire l’occorrenza o

l’introduzione di guasti.

• Tolleranza ai guasti (fault tolerance): come fornire un servizio corretto

anche in presenza di guasti.

• Eliminazione dei guasti (fault removal): come ridurre il numero o la

gravità dei guasti.


• Previsione dei guasti (fault forecasting): come stimare il numero attuale,

l’incidenza futura e le probabili conseguenze dei guasti.

Dato che tali tecniche vengono svolte dall’uomo, la cui natura è imper-

fetta, gli obiettivi prefissati non vengono mai raggiunti. Motivo per cui,

nel progetto di applicazioni “dependable”, queste vengono combinate e

utilizzate insieme. La sequenza di utilizzo può essere cosi descritta: la fault

prevention, purtroppo non è in grado di evitare tutte le occorrenze di gua-

sto possibili e per questo è necessario utilizzare tecniche di fault removal.

Queste, essendo imperfette, portano alla necessità di introdurre tecniche di

fault tolerance. Infine, la crescente importanza delle applicazioni fa sorgere

il bisogno di opportune stime e previsioni future (fault forecasting), le quali,

a loro volta, richiedono l’applicazione di regole ovvero di fault prevention e

cosi via.

Il tema principale su cui verte questa tesi è la fault detection and isolation

(FDI), ragion per cui, andremo ad approfondire la fault tolerance evitando

di entrare nel dettaglio delle tre rimanenti tecniche di progettazione.

Fault tolerance

Il suo conseguimento passa attraverso due fasi principali, che la letteratu-

ra suddivide logicamente in modi diversi (ma sostanzialmente equivalenti).

In alcuni testi (vd. [9]) si adotta uno schema composto da:

1. Error processing

• error detection

• error diagnosis

• error recovery

2. Fault treatment

• fault diagnosis

• fault passivation

• reconfiguration


Fig. 2.6: Le fasi che compongono la fault tolerance

Laprie, R.K. Iyer et all in [3, 18] invece, ritengono che la fault tolerance si

ottenga attraverso:

1. Error detection

2. System recovery

• error handling

• fault handling

Indipendentemente dalla modalità di suddivisione, la tolleranza dei

guasti ha due obiettivi fondamentali. In primo luogo quello di scoprire la

presenza di eventuali errori e cercare di rimuoverne gli effetti prima che

questi diano poi luogo effettivamente ad un malfunzionamento. In secondo

luogo, di impedire che i guasti possano originare altri errori. Lo schema di

tale suddivisione è presentato in Fig. 2.6.

Dal punto di vista cronologico l’error detection è la prima fase che viene

attivata ed ha il fondamentale compito di rilevare la presenza di uno o più

guasti/errori e, nel caso in cui siano rilevati, di generare un segnale di errore

o un messaggio all’interno del sistema.

L’operazione di system recovery consiste nel trasformare uno stato di sistema


contenente uno o più errori - precedentemente rilevati - in uno stato che

ne è privo, evitando inoltre che i guasti da cui derivano tali errori possano

essere attivati nuovamente; tutto ciò è reso possibile tramite le fasi di error

handling e fault handling.

L’error handling, che ha il compito di eliminare gli errori dal sistema, può

essere eseguito con tre diverse modalità:

1. Rollback: tecnica utile con i guasti transienti. Consiste nel riportare

il sistema in uno stato precedente alla manifestazione dell’errore, e

quindi di corretto funzionamento. Chiaramente questo può essere fatto

solo se precedentemente si sono creati opportuni punti di recupero

(checkpoint).

2. Compensation: consiste nella trasformazione immediata dello stato

affetto da errore in uno stato “error free”.

3. Rollforward: consiste nella ricerca di un nuovo stato caratterizzato da

assenza di errore a partire dallo stato corrente erroneo.

Il fault handling, che previene la possibilità che un guasto possa essere

nuovamente attivato si ottiene attraverso quattro passi successivi:

1. Fault diagnosis: identifica e memorizza la causa dell’errore, in termini

di locazione e tipo.

2. Fault Isolation: esclude logicamente o fisicamente il componente guasto

dalle successive operazioni mirate a fornire il servizio

3. System reconfiguration: si attivano componenti di riserva o si riassegna-

no i task tra quelli non guasti.

4. System reinitialization: controlla, aggiorna e memorizza la nuova confi-

gurazione del sistema.

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


Fig. 3.1: I possibili effetti a seguito di un guasto in un sistema fault tolerant (a

sinistra) e in un sistema non fault-tolerant (a destra)

guasto sono contrastati tramite la fault accomodation (Fig. 3.1). In tale situa-

zione il sistema non viene più riconfigurato per contrastare l’occorrenza del

guasto; è il controllore del sistema a dover cambiare per ospitare il guasto.

Riccardo Ferrari proprone un ottimo esempio in [12].

Supponiamo di avere un sistema costituito da una macchina e da un

controllore, (il guidatore della macchina) e supponiamo che il guasto possa

occorrere solo alla macchina considerando (caso ottimistico!) il guidatore

un buon pilota. Alla foratura di un pneumatico (occorrenza del guasto), il

guidatore avendo un modello mentale del corretto funzionamento della

macchina, riesce ad accorgersi che qualcosa non sta funzionando a dovere

e cambia, di conseguenza, il suo stile di guida per mettersi in condizioni

di sicurezza. La fault accomodation verrà compiuta andando a limitare la

velocità.

Il modello presente nella mente del guidatore, viene utilizzato non solo per

scoprire e isolare il guasto, ma anche per escogitare un modo per guidare la


macchina mentre si è in situazione di emergenza.

I metodi di diagnosi dei guasti basati su modelli del sistema sotto os-

servazione sono relativamente recenti. Storicamente, il primo approccio

conosciuto per la diagnosi di guasti in sistemi ingegneristici, non faceva

affidamento su l’uso di modelli del sistema sotto controllo, ma contava su la

conoscenza dell’insieme dei valori ammissibili per ogni variabile misurata

[12].

Questo approccio, chiamato limit checking, fu utilizzato a partire dal di-

ciannovesimo secolo per la strumentazione delle macchine dell’epoca [16].

Il metodo scovava l’errore (eseguiva la detection) nel momento in cui una

variabile oltrepassava il limite dei valori per essa ammissibili, mentre l’isola-

mento del guasto era effettuato andando a verificare quale, tra le variabili

esistenti, aveva assunto un valore inammissibile.

Successivamente, intorno alla prima metà del ventesimo secolo, grazie alla

disponibilità di filtri passa-banda e oscilloscopi, fu possibile compiere una

procedura di diagnosi più accurata.

Nascono le cosiddette tecniche signal-based, basate sul processamento del

segnale, nel dominio del tempo e/o nel dominio delle frequenze. Il principio

di fatti è simile al limit checking ma in questo caso, avendo a disposizione

una strumentazione migliore si riescono a fare analisi più precise. Pertanto i

guasti vengono diagnosticati e isolati dal confronto delle componenti spet-

trali e delle caratteristiche transienti dei segnali, con appropriati valori di

riferimento.

Durante il 1970, grazie all’uso dei calcolatori nei processi ingegneristici, fu

finalmente possibile usare anche l’approccio basato su modelli. Tale tecnica

prevede un modello matematico rappresentate il funzionamento corretto

del processo sotto controllo. L’idea fondamentale è che, usando le stime for-

nite dal modello sulle variabili misurate e confrontandole con i valori reali

forniti dalle misure compiute, è possibile, valutando la differenza di valore

riscontrata, fare detection e isolation del guasto (Fig. 3.2). L’output della

procedura di confronto da luogo a un numero di segnali chiamati residui, che

idealmente dovrebbero essere uguali a zero nel caso in cui nessun guasto

occorra. In realtà, al fine di evitare la produzione di falsi positivi, le soglie


di errore utilizzate sono maggiori di zero. Questo è dovuto ai disturbi fisici

presenti nel sistema e alle incertezze insite nel processo di modellazione.

Fig. 3.2: I tre stadi della fault detection

Una delle prime applicazioni di model-based FDI si è avuta nell’indu-

stria chimica attraverso l’uso delle equazioni di parità (parity relations) [16].

Un tale pattern usa modelli input-output del sistema per calcolare i residui

tra i valori calcolati e misurati della stessa grandezza.

Un altro approccio appartenente a tale categoria prevede l’uso di osservatori

diagnostici. In tali casi, viene creato un modello dello spazio degli stati del

sistema sotto controllo, dal quale vengono prodotte delle stime sugli stati e

le uscite del sistema. Gli errori di stima, sono quindi usati come residui e

confrontati con delle opportune soglie per scopi di rilevamento e isolamento

(Fig. 3.3).

Bettocchi et all propongono, in [5], un interessante esempio di applica-

zione di queste due ultime tecniche.

Senza entrare troppo nel dettaglio, in questo lavoro vengono presentate

e confrontate alcune tecniche di ridondanza analitica per il rilevamento e

l’isolamento dei guasti ai sensori di misura inseriti negli impianti e nelle

Fig. 3.3: Schema base per la model-based fault detection


macchine industriali al fine di effettuarne il controllo e il monitoraggio. Il

tutto è applicato alle misure rilevate su un turbogas industriale monoalbero

per poterne valutare le potenzialità in applicazioni di particolare rilevanza.

L’ultima tecnica da analizzare, (vedi [16, 13]), è la parameter estimation.

Tale metodologia utilizza un modello parametrico del sistema sotto con-

trollo, in cui si cerca di adattare, durante il monitoraggio, i parametri alle

misure osservate. Se i parametri escono fuori dalle loro regioni ammissibili,

che stanno ad identificare un sistema correttamente funzionante, viene dia-

gnosticato un problema.

Un esempio si ha con il metodo dei minimi quadrati (in inglese OLS: Ordi-

nary Least Squares), che insieme ai metodi di ottimizzazione numerici, più

precisi sotto l’influenza dei disturbi di processo, sono quelli maggiormente

utilizzati nella stima di parametri.

La tecnica dei minimi quadrati consiste nel trovare una funzione che si

avvicini il più possibile ad un’interpolazione di un insieme di dati (tipica-

mente punti del piano). In particolare la funzione trovata deve essere quella

che minimizza la somma dei quadrati delle distanze dai punti dati. Questo

metodo va distinto da quelli per l’interpolazione dove si richiede che la

funzione calcolata passi esattamente per i punti dati.

Riassumendo, la fault detection and isolation, sotto-campo dell’ingegne-

ria del controllo che si occupa del monitoraggio di un sistema con lo scopo

di rilevare i guasti e di capirne il tipo e la locazione può essere distinta in

due approcci: un pattern diretto di riconoscimento dei guasti attraverso la

lettura di determinati valori, rilevati ad esempio, da un sensore, e un’analisi

delle discrepanze tra i valori letti e i valori attesi derivati da un qualche

modello. In quest’ultimo caso, è tipico dire che un guasto è stato scoperto se

la discrepanza, o residuo va sopra una certa soglia. Sarà compito del task di

fault isolation caratterizzare il tipo di guasto e la locazione nel sistema.

Le tecniche di cui l’FDI fa uso possono quindi, essere classificate in due

categorie:

• basata su modello (model-based): per decidere se un guasto è occorso


viene usato un modello, che può essere matematico o può essere basato

su qualche conoscenza del sistema.

• basata su segnale (signal-based): consiste nell’effettuare delle ope-

razioni statistiche o matematiche sulle misure acquisite. Un classi-

co esempio appartenente a questa tecnica è il TDR (time-domain-

reflectometry) che verrà discusso nel proseguo del capitolo.

Inoltre, all’interno della tecnica model-based è possibile compiere un

ulteriore distinzione in:

• Metodo basato su osservatori

• Metodo basato su equazioni di parità

• Metodo basato su stima di parametri

Tali tecniche vengono utilizzate nei campi più disparati e maggiormen-

te con applicazioni critiche. Nella sezione successiva presenteremo alcuni

esempi tratti dal settore automobilistico che di tali tecniche fa ampio utiliz-

zo.

Ma anche i sistemi satellitari e quelli automatici godono di tali benefici.

Esempi si trovano in [6, 30].

Nel primo, Braisted e Beckmann espongono l’architettura di un ricevitore

GPS, che attraverso l’analisi del segnale emesso dai satelliti in orbita, è in

grado di diagnosticare il guasto e escludere il componente non in salute

dalle successive computazioni.

Nel secondo invece, Salsbury e Controls, presentano un sistema di controllo

per l’impianto di condizionamento di un edificio di grandi dimensioni situa-

to a San Francisco. I guasti vengono rilevati tramite il livello di discrepanza

esistente tra i valori calcolati dal modello e quelli del processo controllato.

Vengono quindi generate opportune azioni volte a migliorare le prestazioni

dei generici controllori PID1.

1Sono controllori tipici nel mondo dell’automatica e più precisamente negli impianti di

condizionamento che utilizzano leggi di controllo proporzionali, integrative e derivative


3.2 FDI in applicazioni critiche

La letteratura in questione è molto vasta e una trattazione esaustiva

sarebbe alquanto complessa e devierebbe dagli scopi di tale tesi. Ciò nono-

stante, porremo l’attenzione soprattutto su come il problema viene affrontato

con i motori delle automobili presentando a grandi linee alcuni esempi tratti

da applicazioni concrete. Entreremo poi, maggiormente nel dettaglio per ciò

che concerne l’utlizzo di metodologie di composizione sincrona di macchine

a stati e tecnologie quali la riflettometria nel dominio del tempo.

Lo sviluppo di sistemi di diagnostica per i motori delle macchine ha

recentemente raggiunto grande interesse per due principali motivi. Primo,

i requisiti di mercato spingono sempre più verso proprietà del veicolo

quali, maintainability e repairability. Secondo, e più importante, riguarda la

creazione di norme sempre più volte alla sicurezza e al rispetto ambientale.

Qualunque procedura industriale di rilevamento e isolamento di guasti, che

voglia essere efficiente, deve soddisfare i seguenti requisiti (tratti da [23]):

• Modularità. Qualunque elemento del processo e dell’ambiente diagno-

stico dev’essere descritto da un proprio modello, in modo tale da poter

essere ulteriormente usato nella progettazione del modello composto

del sistema globale.

• Progetto gerarchico. Bisogna poter realizzare il progetto del sistema di

diagnostica a differenti livelli di astrazione. Il modello di un singolo

sottosistema a basso livello deve essere completamente definito in

modo tale da essere visto a un livello di astrazione più alto, come un

singolo componente da comporre con altri componenti.

• Fusione dei dati. Il sistema di diagnostica deve essere capace di estrarre

informazioni da diverse sorgenti quali analisi di segnali locali, ridon-

danze hardware e analitiche, condizioni logiche e conoscenze empiri-

che. In altre parole deve saper interagire con tutte le diverse tecniche

usate durante lo sviluppo del sistema.


• Semplicità. In molti casi, gli algoritmi diagnostici vengono implemen-

tati in microprocessori con capacità di computazione limitate.

• Analisi temporale. Nella maggior parte dei casi, viene a mancare una co-

noscenza precisa riguardante i tempi di propagazione tra l’occorrenza

del guasto e l’attivazione del corrispettivo allarme. Una procedura d’in-

ferenza accurata, deve tener conto anche di tale situazione, contando

su una qualche sorta di analisi temporale.

• Compatibilità con standard industriali. ogni ulteriore spiegazione è su-

perflua.

• Integrazione del controllo e degli ambienti diagnostici. C’è bisogno di una

compatibilità tra la definizione del sistema di controllo usata durante la

fase di progetto e quella adottata durante la definizione del diagnoser.

• Compatibilità con gli ambienti software disponibili in commercio. Dato il

crescente accoppiamento che il settore automobilistico ha con le simu-

lazioni, una condizione necessaria per l’effettiva applicabilità delle

metodologie di diagnosi è la disponibilità commerciale di ambienti

software affidabili per lo sviluppo di simulatori che descrivono le

dinamiche del sistema (incluso l’occorrenza dei gusti), il sistema di

controllo e le procedure diagnostiche.

Oggigiorno, gli approcci più utilizzati per la rilevazione e l’isolamento

dei guasti in contesto automobilistico, riguardano entrambe le tecniche,

prima esposte, di signal processising e model based.

Isermann in [17] propone due interessati applicazioni di rilevamento dei

guasti che fanno uso di tecniche basate su modello. La prima, è un sistema

che supervisiona il comportamento del conducente durante la guida in cur-

va. In particolare, viene considerata la velocità caratteristica del veicolo come

parametro che determina il tipo di “sterzata” (controsterzo o sovrasterzo).

Tale parametro è usato per classificare il comportamento di guida, e quindi,

anche per indicare situazioni di comportamenti errati come l’instabilità.

Naturalmente il parametro è confrontato, come previsto da approcci model

based, con dei valori ricavati da opportuni modelli e indicanti i possibili


comportamenti di guida (siano essi corretti o critici).

La seconda applicazione invece, descrive una parte del sistema di controllo

di un motore di combustione Diesel. Il motore è partizionato in tre grandi

sottosistemi: il sistema di aspirazione, il sistema albero motore e il sistema

di scarico. Per ognuno di questi sottosistemi sono stati sviluppati adeguati

metodi di rilevamento e isolamento dei guasti che utilizzano ambo le tec-

niche esposte in precedenza. Più precisamente, l’articolo propone solo lo

studio del sistema di aspirazione. In tal caso, le variabili d’ingresso, quali

velocità dell’aria, pressione atmosferica e temperatura e le variabili d’uscita

quali pressione e temperatura, vengono utilizzate per la generazione dei

residui, a loro volta creati attraverso equazioni di parità. Successivamente,

dal confronto di tali residui con i valori di riferimento, indicanti il corretto

funzionamento del sistema, vengono rilevati e isolati i guasti.

Molto spesso però, le tecniche classiche di rilevamento e isolamento dei

guasti possono mancare di uno o più requisiti fondamentali. Ad esempio, le

tecniche basate su modello, sono molto sensibili agli errori di modellazione

e ai disturbi non conosciuti; inoltre mancano di modularità, flessibilità e

semplicità. Le tecniche basate sul processamento dei segnali invece, sebbene

delle volte necessarie per ragioni di sicurezza (si pensi al principio di ridon-

danza fisica utilizzato all’interno di sistemi critici), mancano della maggior

parte dei requisiti esposti a inizio paragrafo.

Sono queste le motivazioni che hanno spinto la letteratura a cercare nuo-

ve metodologie oltre a quelle già elencate. Magni et all in [23] sviluppano

un nuovo metodo di modellazione del sistema, basato su composizione

sincrona di macchine a stati finiti. Viene inoltre descritto un algoritmo in

grado di eseguire rilevamento e isolamento di guasti a partire dal modello

così costruito, e da un’analisi temporale che tiene conto dei tempi minimi

e massimi che intercorrano tra l’occorrenza del guasto e l’attivazione del

corrispettivo allarme. L’algoritmo sviluppato quindi, oltre ad identificare

univocamente il guasto, ci dirà anche l’istante di tempo in cui ciò accadrà

ovvero quanto tempo passerà dal guasto alla sua identificazione.

L’articolo presenta tali risultati partendo dalla modellazione del movimento

di una valvola che costituisce un importante problema nello sviluppo delle


Fig. 3.4: Matrice dei residui del movimento di una valvola in un motore di un

automobile tratto da [23]. Le righe rappresentano le uscite dei 5 sotto-modelli

utilizzati, mentre le colonne rappresentano le fault signature dei guasti che

possono occorrere nel sistema.

procedure di sicurezza per i motori delle macchine. Su tale sistema vengono

calcolate due misure (da altrettanti sensori) inerenti la posizione angolare

della valvola, in accordo ad un principio di ridondanza fisica. Inoltre, viene

stabilita un’equazione di bilanciamento della massa, su ognuna di queste

due misure, calcolata a partire dalla valutazione di ulteriori variabili, che si

assumono per semplicità corrette, in accordo ad un principio di ridondanza

analitica.

L’intero sistema viene, quindi, modellato tramite la composizione di sei

sotto-modelli: una macchina a stati finiti (FSM) per la valvola, due FSM per i

sensori, due FSM per il principio di ridondanza analitica applicato su le due

misure calcolate dai sensori e l’ultima FSM per il principio di ridondanza

fisica.

Tralasciando i dettagli della composizione, rimandando il lettore interessato

all’articolo sopra citato, un importante risultato è ottenuto andando a vi-

sionare la matrice dei residui, una matrice contenente tutte le firme dei guasti

ovvero i codici di errori che permettono la rilevazione e l’identificazione

del guasto (Fig. 3.4). Quello che si scopre è che basta comporre solo cinque

dei sei sotto-modelli totali per ottenere una matrice dei residui con tutte

colonne diverse e quindi per isolare senza ambiguità tutti i tipi di occorrenze

di guasto riscontrabili nel sistema.


Fig. 3.5: Schema di testing tratto da [20]. Il TDR (135) viene utilizzato per inviare

un impulso sulla linea di test 115 al fine di testare il sistema di cablaggio 118 e

verificare se qualche connettore di espansione (120) o di terminazione (125) è

connesso impropriamente.

3.2.1 Un esempio di processamento di segnali: il TDR

Più comunemente conosciuto come riflettometro nel dominio del tempo,

un TDR è uno strumento elettronico usato per caratterizzare e localizzare i

guasti in cavi metallici, come ad esempio, cavi coassiali o doppini telefonici.

Può anche essere usato per localizzare discontinuità nei connettori o in

qualunque cammino elettrico.

La Riflettometria nel Dominio del Tempo è una tecnica basata sull’analisi del

segnale viaggiante lungo una linea di trasmissione e riflesso da un generico

carico.

Nell’esempio proposto, tratto da [20], Klassen e Anderson usano il TDR

per testare il sistema elettrico di un automobile costituito da un sistema di

cablaggio e da dispositivi elettrici connessi per mezzo di opportuni con-

nettori di 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.


della presenza di un connettore non propriamente connesso, permette di

capire la locazione del guasto (eccetto naturalmente la pulsazione riflessa

a causa della terminazione della linea di test). Questo poiché la velocità di

propagazione nel mezzo è pressoché costante e quindi la pulsazione rifles-

sa può essere analizzata anziché in funzione del tempo, in funzione della

lunghezza del mezzo.

3.3 FDI nel settore del software

Focalizzeremo l’attenzione sulle strategie di testing esistenti in lettera-

tura. Queste di fatti, hanno da sempre costituito il principale metodo di

detection e isolation degli errori commessi dai programmatori. In parti-

colare, verranno esposti i principi alla base delle strategie di testing più

utilizzate, i passi di cui tale strategie si compongono, comprese le differenze

esistenti tra i due principali paradigmi di programmazione, e le tecniche

maggiormente usate durante tali passi.

Il software dev’essere testato per individuare gli errori che sono stati

commessi inavvertitamente durante la fase di progettazione e realizzazione.

Qualunque strategia di testing deve incorporare la pianificazione, la pro-

gettazione dei test case, la loro esecuzione e la raccolta e valutazione dei

risultati.

Sono state proposte numerose strategie; tutte forniscono allo sviluppatore

uno schema per il testing e tutte condividono le seguenti caratteristiche

generali ([27]).

• Al fine di svolgere un efficace testing, un team di sviluppo software

deve condurre un’efficace revisione tecnica formale. In questo modo

è possibile eliminare molti errori prima ancora di iniziare la fase di

testing.

• Il testing inizia a livello di componente e prosegue “verso l’esterno”

fino all’integrazione dell’intero sistema informatico.


• È opportuno adottare diverse tecniche di testing a seconda del mo-

mento in cui ci si trova nel processo di sviluppo.

• Il testing viene condotto dallo sviluppatore e, per grandi progetti, da

un gruppo indipendente.

• Il testing e il 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.


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-


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


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


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.


• 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


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


• 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


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


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


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.


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


(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]

.


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


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


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


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


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


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


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.


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.


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.


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.


• 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


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.


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.


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


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.


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


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.


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.


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])


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.


• 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


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


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.


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


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


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


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


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.


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.


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


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


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.


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.


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.


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;


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


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


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.


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


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.


Fig. 5.11: Le distribuzioni assunte dal grado dei nodi durante la costruzione dei

grafi random con 25, 50 e 75 archi


Fig. 5.12: Le distribuzioni assunte dal grado dei nodi durante la costruzione dei

grafi random con 100, 125 e 150 archi


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


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.


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


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


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


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


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.


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(...)


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


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


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.


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


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


(a)

(b)

(c)

(d)

Fig. 6.2: Immagini scattate durante la realizzazione dell’impianto.


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-


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


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-


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.


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


Fig. 6.4: Il sequence diagram riguardante l’isolamento di un singolo guasto


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.


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.

Documents

Fault isolation esperta per sistemi domotici