Strumenti automatici per la correlazione di eventi a scopo ...

Universita degli Studi di Firenze

Facolta di Scienze Matematiche Fisiche e Naturali

Corso di Laurea in Scienze e Tecnologie dell’Informazione

Strumenti automatici per lacorrelazione di eventi a scopo

diagnostico in infrastrutture critiche

Anno Accademico 2008-2009

Relatore: Prof. A. Bondavalli Correlatore: Dott. A. Daidone

Vania Guarnieri

Prefazione

I sistemi informatici, sempre piu complessi e critici, sono ormai entrati a

fare parte della vita quotidiana di ognuno di noi. Il buon funzionamento

di tali sistemi e pressoche determinante per gli ingenti danni che altrimenti

potrebbero verificarsi. Nasce dunque l’esigenza di poter riporre nei confronti

di questi sistemi una fiducia giustificata.

Alcune tecniche, che consentono di creare un sistema affidabile, inter-

vengono durante la fase di progettazione, altre durante quella di realizzazio-

ne, altre ancora durante la vita operazionale del sistema. Logicamente una

buona progettazione e una buona realizzazione garantiscono una maggiore

affidabilita, ma non privano tali sistemi da malfunzionamenti. Scaturisce

pertanto la necessita di dotare tali infrastrutture critiche con una sorta di

meccanismo di autocontrollo capace di diagnosticare lo stato di salute del

sistema e di suggerire le eventuali ed opportune azioni da intraprendere.

L’attivita di diagnosi, nell’ambito di un sistema informatico, consiste

nell’interpretazione di una serie di informazioni raccolte al fine di scoprire

malfunzionamenti che possono colpire i componenti del sistema stesso e che

conducono all’inaffidabilita. Pertanto diviene indispensabile introdurre nel-

la fase di progettazione di un sistema un meccanismo per la rilevazione dei

guasti.

Questa tesi si pone l’obiettivo di sviluppare un modello di diagnosi che,

iii

iv PREFAZIONE

mediante l’uso di strumenti automatici, effettui una correlazione degli eventi

raccolti con l’intento di incrementare l’affidabilita in infrastrutture critiche.

Il primo capitolo introduce la terminologia ed i concetti utili per la de-

scrizione del problema diagnostico. Dopo aver presentato il concetto di de-

pendability ed aver discusso dei suoi impedimenti, dei suoi attributi e dei

mezzi per ottenerla, si giunge alla definizione del punto centrale della tesi: la

diagnosi.

Il secondo capitolo e interamente dedicato ad un’analisi degli strumenti

messi a disposizione per compiere diagnosi. Vengono dapprima descritti due

meccanismi che sono punti di riferimento nella letteratura della diagnosi ri-

volta alla discriminazione fra guasti transienti e permanenti: α-count [13] e

la diagnosi Bayesiana [44]. Successivamente si descrive un ulteriore mecca-

nismo basato sulle catene di Markov nascoste [16]. Dopodiche s’introduce

il concetto di event correlation e si effettua una panoramica sulle princi-

pali tecniche. Infine, dopo un’attenta analisi dei vari strumenti automatici

attualmente disponibili che permettono l’event correlation e descrivendo il

contesto di riferimento, si sceglie lo strumento ritenuto piu conforme alle

nostre esigenze: SEC [55].

Nel terzo capitolo si mostra come gli strumenti automatici presentati

nel secondo capitolo si propongono come validi meccanismi per l’implemen-

tazione di euristiche, come α-count, o tecniche piu sofisticate, come il modello

di diagnosi basato sulle catene di Markov nascoste.

Nel quarto capitolo si sviluppa il modello di diagnosi proposto nella tesi

che fa uso degli strumenti automatici. Viene presentata l’architettura di

tale modello composta dalle fasi di event categorization, event filtering e

association rule mining e viene descritta minuziosamente la costruzione di

ciascuna fase del modello.

v

Il quinto capitolo, oltre a descrivere in dettaglio il contesto per cui il

modello di diagnosi proposto e stato realizzato, ovvero i sistemi SCADA,

presenta il generatore di logfile appositamente realizzato per simulare tracce

di messaggi scambiati in tali sistemi in base al protocollo PROFIBUS. Il

generatore sviluppato offre la possibilita di personalizzare l’intero sistema

(simulato) da analizzare, di generare eventi nel sistema e di fare fault injection

sui componenti.

Con l’ausilio del generatore sviluppato, il sesto ed il settimo capitolo

illustrano un caso di studio con i relativi esperimenti svolti, al fine di testare

il modello di diagnosi proposto.

L’ultimo capitolo e dedicato alle considerazioni conclusive sul lavoro svolto

e sui possibili sviluppi futuri.

vi PREFAZIONE

Indice

Prefazione iii

1 Introduzione 1

1.1 La dependability . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Impedimenti alla dependability . . . . . . . . . . . . . 3

1.1.2 Mezzi per ottenere la dependability . . . . . . . . . . . 8

1.1.3 Attributi della dependability . . . . . . . . . . . . . . . 11

1.2 Diagnosi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Strumenti per la diagnosi 17

2.1 α-count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 Diagnosi Bayesiana . . . . . . . . . . . . . . . . . . . . . . . . 25

2.3 Meccanismo di diagnosi basato sulle HMM . . . . . . . . . . . 26

2.3.1 Definizione di catena di Markov nascosta . . . . . . . . 27

2.3.2 Il modello di diagnosi dei guasti . . . . . . . . . . . . . 29

2.4 Event correlation . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.4.1 Tecniche di event correlation . . . . . . . . . . . . . . . 34

2.4.2 Confronto tra gli approcci disponibili . . . . . . . . . . 38

2.5 Strumenti automatici per osservare eventi . . . . . . . . . . . 39

vii

viii INDICE

2.5.1 Logsurfer+ . . . . . . . . . . . . . . . . . . . . . . . . 40

2.5.2 Swatch . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.5.3 SEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.5.4 LoGS . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.5.5 Scelta del tool . . . . . . . . . . . . . . . . . . . . . . . 47

3 Strumenti automatici per fare diagnosi 51

3.1 α-count implementato mediante regole . . . . . . . . . . . . . 52

3.2 Modello di diagnosi con HMM mediante regole . . . . . . . . . 57

4 Diagnosi con strumenti automatici 65

4.1 Architettura del modello di diagnosi . . . . . . . . . . . . . . . 66

4.2 Il Modello di diagnosi . . . . . . . . . . . . . . . . . . . . . . . 68

4.2.1 Event categorization . . . . . . . . . . . . . . . . . . . 68

4.2.2 Event filtering . . . . . . . . . . . . . . . . . . . . . . . 71

4.2.3 Association rule mining . . . . . . . . . . . . . . . . . . 75

5 Generatore di LogFile per sistemi SCADA 79

5.1 I sistemi SCADA . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.2 PROFIBUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.3 Generatore di LogFile PROFIBUS . . . . . . . . . . . . . . . 89

5.3.1 Architettura del generatore . . . . . . . . . . . . . . . 91

5.3.2 Funzionamento del generatore . . . . . . . . . . . . . . 91

6 Caso di studio 101

6.1 Analisi del sistema . . . . . . . . . . . . . . . . . . . . . . . . 102

6.1.1 Aumento della temperatura . . . . . . . . . . . . . . . 103

6.1.2 Diminuzione della temperatura . . . . . . . . . . . . . 104

6.1.3 Variazione della fornitura di energia elettrica . . . . . . 105

INDICE ix

6.1.4 Altri eventi . . . . . . . . . . . . . . . . . . . . . . . . 106

6.1.5 Guasti ai singoli sensori . . . . . . . . . . . . . . . . . 107

6.2 Applicare il modello di diagnosi . . . . . . . . . . . . . . . . . 109

6.2.1 Event categorization . . . . . . . . . . . . . . . . . . . 109

6.2.2 Event filtering . . . . . . . . . . . . . . . . . . . . . . . 112

6.2.3 Association rule mining . . . . . . . . . . . . . . . . . . 116

7 Esperimenti 125

7.1 Stima della temperatura . . . . . . . . . . . . . . . . . . . . . 126

7.2 Aumento lieve della temperatura . . . . . . . . . . . . . . . . 128

7.3 Aumento e diminuzione della temperatura . . . . . . . . . . . 130

7.4 Aumento e diminuzione della temperatura . . . . . . . . . . . 132

7.5 Variazione nella fornitura di energia elettrica . . . . . . . . . . 134

7.6 Fault injection: sottovoltaggio . . . . . . . . . . . . . . . . . . 135

7.7 Fault injection: overload . . . . . . . . . . . . . . . . . . . . . 138

7.8 Fault injection: stato healthy con rilevazioni errate . . . . . . 140

8 Conclusioni 143

A SEC 145

x INDICE

Capitolo 1Introduzione

1.1 La dependability

Oggigiorno il rapporto fra l’uomo e la macchina e diventato sempre piu stretto

ed importante in quanto i compiti affidati ai sistemi informatici sono sempre

piu delicati e critici. Il buon funzionamento di tali sistemi e ormai determi-

nante per la vita di milioni di persone. Proprio per questo motivo si richiede

da questi sistemi un livello di affidabilita che compensi un tale investimento.

Quindi e compito degli sviluppatori fornire sistemi sui quali gli utenti pos-

sono poter riporre fiducia.

La dependability e “una misura che indica quanta fiducia, in maniera

giustificata, possiamo riporre sul servizio fornito da un sistema” [30]. Questa

proprieta e anche definita come “l’abilita di un sistema di soddisfare specifi-

cati servizi, dove per servizio s’intende il comportamento di un sistema cosı

come viene percepito dai suoi utenti” [49]. Un utente di un sistema e un altro

sistema che interagisce attraverso l’interfaccia del servizio. Il comportamento

atteso dal sistema e invece rappresentato dalla funzione la cui descrizione e

1

2 CAPITOLO 1. INTRODUZIONE

fornita dalla specifica funzionale [30]. Non e pero semplice fornire una speci-

fica completa e non ambigua poiche il comportamento di un sistema spesso

deve essere ricavato a partire dai requisiti degli utenti che solitamente sono

impliciti e confusi. E inoltre necessario per produrre una specifica comple-

ta del sistema, specificare quali sono le condizioni sotto cui il sistema deve

fornire il servizio richiesto ed indicare, oltre a cosa il sistema deve fare, cio

che il sistema non deve fare.

Il servizio di un sistema si distingue in proprio, se rispetta le specifiche funzio-

nali stabilite, e improprio altrimenti. Nel momento in cui il sistema fornisce

un servizio proprio si dice che esso si trova in uno stato corretto, altrimenti

lo stato e non corretto. La transizione da stato proprio a stato improprio e

detta fallimento, mentre quella da stato improprio a stato proprio e detta

ripristino. La figura 1.1 mostra gli stati di servizio del sistema e le relativa

transizioni.

Figura 1.1: Servizio proprio, servizio improprio e transizioni.

In definitiva si puo dire che un sistema e dependable se possiede un’alta proba-

bilita di comportarsi come definito nella sua specifica funzionale [56]. Questo

comporta in primis che sia disponibile una definizione del comportamento del

sistema e successivamente che venga chiarito cosa s’intende per “alta pro-

babilita”. Infatti questa probabilita dipende dalla funzione del sistema in

1.1. LA DEPENDABILITY 3

questione e varia a seconda delle conseguenze che il sistema ha sull’ambiente

(ad esempio la probabilita sara piu alta per sistemi informatici di control-

lo aerei rispetto a sistemi informatici per distributori automatici di bevande).

Per costruire sistemi dependable e necessario definire quali sono gli impe-

dimenti alla dependability, ovvero le potenziali cause di comportamenti non

previsti, i mezzi per ottenere la dependability, cioe le tecniche che permettono

di ottenere comportamenti corretti nonostante il verificarsi degli impedimen-

ti, ed i suoi attributi che permettono di esprimere e verificare il livello di

dependability richiesto.

1.1.1 Impedimenti alla dependability

Gli impedimenti alla dependability sono di tre tipi: guasti, errori e fallimenti

[30][56]. In seguito saranno descritti in dettaglio e sara fornita una definizione

per la catena guasti-errori-fallimenti.

Guasti

Un guasto puo essere classificato in base ad alcuni parametri che riguardano

la fase di vita del sistema in cui si verificano (fase di sviluppo o fase d’uso),

la posizione nel sistema (interni o esterni), la causa fenomenologica (natu-

rale o umana), il dominio (hardware o software), l’obiettivo (maligno o non

maligno), l’eventuale intenzione (premeditato o non premeditato), l’even-

tuale competenza dell’utenza (accidentali o per incompetenza) ed infine per

la natura della loro persistenza (transiente o permanente).

Non tutte le combinazioni dei parametri elencati sono possibili. La figura 1.2

mostra la classificazione dei guasti e tutte le possibili combinazioni.


Figura 1.2: Classificazione dei guasti e possibili combinazioni.

Un’altra possibile distinzione puo essere invece basata sull’origine fenomeno-

logica suddividendo i guasti in:

- guasto fisico generato da cause fisiche che possono affliggere l’hardware,

sia in fase di sviluppo che in fase d’uso;

- guasto di design introdotto durante la fase di progettazione del sistema;

- guasto d’interazione che si verifica nell’interfaccia fra i componenti del

sistema o nell’interfaccia con il mondo esterno.

Errori

Un errore e definito come la deviazione del sistema dallo stato di servizio

corretto. Si parla di errore rilevato se un messaggio d’errore ne testimonia

la presenza, errore latente altrimenti.


In un sistema composto da un insieme di componenti che interagiscono tra

loro, un errore interno, di uno o piu componenti, non porta necessariamente

ad un fallimento del sistema. Perche questo accada e infatti necessario che

le conseguenze dell’errore giungano all’interfaccia di servizio.

Se un errore conduce effettivamente ad un fallimento dipende da tre fattori

principali:

1. la composizione del sistema e la natura della ridondanza esistente:

- Ridondanza intenzionale, introdotta per fornire tolleranza al gua-

sto, e esplicitamente intesa per prevenire che un errore conduca

ad un fallimento;

- Ridondanza non intenzionale puo avere lo stesso risultato, non at-

teso, della ridondanza intenzionale (e difficile costruire un sistema

che ne e privo).

2. l’attivita del sistema: un errore puo essere compensato prima di provo-

care un danno;

3. la definizione di un fallimento dal punto di vista dell’utente: cio che e

un fallimento per un utente puo essere un malfunzionamento tollerabile

per un altro.

Fallimenti

Un fallimento e un evento che si verifica quando il servizio fornito dal sistema

devıa rispetto al servizio corretto. Un sistema non puo fallire, e generalmente

non fallisce, sempre nello stesso modo. I modi in cui un sistema puo fallire

sono i failure modes e possono essere caratterizzati secondo tre punti di vista.

- Dal punto di vista del dominio di fallimento possono essere distinti:


- fallimenti di valore: il servizio fornito non e conforme alla speci-

fica;

- fallimenti nel tempo: il tempo della fornitura del servizio non e

conforme alla specifica. Inoltre e possibile fare ulteriori distinzioni

riguardo a questo tipo di fallimento che attestano quando un

servizio e stato fornito troppo presto o troppo tardi, distinguendo

tra:

- fallimento nel tempo per anticipo (early timing failures);

- fallimento nel tempo per ritardo (late timing failures ).

Una classe di fallimenti, che si riferisce sia al dominio del valore che

del tempo, sono i fallimenti con blocco (stopping failures). In questo

tipo di fallimenti l’attivita del sistema non e piu percepibile dagli utenti

e viene fornito un servizio a valore costante (l’ultimo valore corretto,

un valore predeterminato, etc.). Un caso particolare di fallimento per

blocco e il fallimento per omissione (omission failure) in cui non viene

fornito alcun servizio. Questo fallimento e un caso limite comune sia

per i fallimenti di valore (valore nullo), che per fallimenti nel tempo

(fallimento per ritardo infinito).

Un sistema i cui fallimenti possono essere solamente fallimenti per bloc-

co e un sistema fail-stop. Un sistema i cui fallimenti possono essere

solamente fallimenti per omissione persistente e un sistema fail-silent.

- Quando un sistema ha molteplici utenti, dal punto di vista della per-

cezione del fallimento, si possono distinguere:

- fallimenti consistenti : tutti gli utenti del sistema hanno la stessa

percezione dei fallimenti;


- fallimenti inconsistenti o bizantini : gli utenti del sistema possono

avere percezioni differenti di uno stesso fallimento.

- La gravita (o severita) del fallimento risulta dalle conseguenze dei falli-

menti sull’ambiente del sistema. Esistono sistemi i cui modi di fallimen-

to possono essere raggruppati in due classi di gravita considerevolmente

differenti:

- fallimenti benigni per cui le conseguenze sono dello stesso ordine

di grandezza (in genere in termini di costo) del beneficio prodotto

dal servizio fornito in assenza di fallimento;

- fallimenti catastrofici per cui le conseguenze sono incommensura-

bilmente piu grandi del beneficio prodotto dal servizio fornito in

assenza di fallimento.

Un sistema i cui fallimenti possono essere soltanto benigni e un sistema

fail-safe.

Catena guasto-errore-fallimento

Per descrivere come si arriva al fallimento dei sistemi, spesso composti da

vari componenti, si puo utilizzare la catena guasto-errore-fallimento rappre-

sentata dalla figura 1.3.

Figura 1.3: Catena guasto-errore-fallimento.


Questa figura puo essere utilizzata sia per descrivere il fallimento del si-

stema che di ogni singola componente. Il fallimento di un componente si

verifica quando il servizio fornito si discosta dalla sua specifica funzionale

e questo accade a causa di uno o piu errori. Il fallimento del componente

rappresenta un guasto rispetto al sistema. Il guasto puo quindi portare a

successivi guasti, cosı come un errore, attraverso la propagazione, puo solle-

vare ulteriori errori; un fallimento del sistema si trova spesso al termine di

una catena di errori propagati.

1.1.2 Mezzi per ottenere la dependability

I mezzi per ottenere la dependability sono tutti quei metodi che agiscono in

vari punti della catena guasto-errore-fallimento e che permettono di inter-

romperla. La maggior parte di questi metodi si concentrano sui guasti.

E possibile classificare i mezzi in quattro categorie:

- Rimozione dei guasti (fault removal): tecnica che si basa sul rilevamen-

to dei guasti e la successiva rimozione, prima della loro attivazione sia

in fase di sviluppo che in fase operativa. Quello che si tenta di fare con

questi metodi e di individuare e rimuovere bug software o hardware con

difetti.

Nella fase di sviluppo la rimozione dei guasti passa attraverso tre fasi:

verifica, diagnosi e correzione. Durante la verifica si controlla che il

sistema aderisca alle proprieta specificate, se cosı non e si passa alla

diagnosi ed alla correzione dei guasti che hanno fatto fallire la verifi-

ca. Oltre alla verifica e opportuno effettuare la validazione del sistema,

ovvero capire se il sistema che stiamo costruendo e corretto. E possibile

distinguere le tecniche di verifica in statiche e dinamiche. Le verifiche

statiche si incentrano sull’analisi del sistema senza che questo venga


realmente eseguito (es. model-checking, analisi statica del codice),

mentre le verifiche dinamiche si basano sull’osservazione del sistema

in esecuzione (es. testing, fault injection).

Nella fase operativa del sistema la rimozione dei guasti e detta manuten-

zione del sistema e puo essere di tipo correttivo o di tipo preventivo.

La prima riguarda la rimozione di guasti che hanno gia prodotto errori

nel sistema, mentre la seconda cerca di rimuovere i guasti prima che

questi possano causare errori durante l’esecuzione del sistema stesso.

- Prevenzione dei guasti (fault prevention): metodo che si occupa, come

il nome stesso dice, di prevenire le cause dei possibili errori eliminando

le condizioni che rendono l’occorrenza dei guasti piu probabile. Questo

scopo lo si ottiene mediante l’impiego di tecniche di controllo della

qualita tra cui la programmazione strutturata, l’information hiding e

la modularizzazione per il software e l’uso di rigorose regole di proget-

tazione per l’hardware.

Combinando tecniche di rimozione con tecniche di prevenzione dei

guasti si ottiene l’eliminazione dei guasti il cui scopo e costruire sistemi

privi di guasti.

- Tolleranza ai guasti (fault tolerance): metodi che si occupano di preser-

vare la correttezza del servizio nonostante la presenza di guasti. Queste

tecniche vengono adottate poiche i metodi precedentemente visti non

permettono di eliminare totalmente i guasti del sistema e sono solita-

mente composte da due fasi: il rilevamento dell’errore attivato durante

il verificarsi dell’errore e il ripristino dell’errore effettuato attraverso la

gestione dell’errore e la gestione del guasto.

Durante la fase di rilevamento dell’errore viene creato un messaggio


d’errore all’interno del sistema: tutti gli errori presenti ma non rilevati

si dicono errori latenti. Il rilevamento, a seconda del momento in cui

viene effettuato si distingue in concorrente e preventivo, quest’ultimo

fatto in periodi in cui la fornitura del servizio e sospesa.

Nella fase di ripristino dell’errore ed in particolare con la gestione del-

l’errore, si tenta di eliminare gli errori dallo stato del sistema. Le princi-

pali tecniche adottate sono il rollback, la compensazione e il rollforward.

Con il rollback si ripristina uno stato del sistema precedentemente sal-

vato; con la compensazione si cerca di ricavare dallo stato erroneo, se

contenente informazioni ridondanti sufficienti ad eliminare gli errori,

uno stato privo di errori; infine con il rollforward si calcola uno stato

successivo del sistema, senza errori, a partire dall’attuale stato erroneo.

Oltre alla gestione dell’errore e possibile utilizzare tecniche di gestione

del guasto che hanno come scopo la disattivazione dei guasti in modo

che non possano essere attivati nuovamente.

Infine e possibile effettuare tramite l’uso di un agente esterno al sistema

e successivamente alla gestione dei guasti, un mantenimento correttivo

in cui si rimuovono i guasti identificati.

- Previsione dei guasti (fault forecasting): tecniche in cui si tenta di

prevedere il comportamento del sistema rispetto all’occorrenza o all’at-

tivazione dei possibili guasti residui. Questi metodi vengono utilizzati

poiche difficilmente qualunque insieme di tecniche utilizzate possono

portare alla costruzione di un sistema totalmente privo da guasti. Le

valutazioni che vengono fatte sono di due tipi: qualitative, che hanno

come obiettivo l’identificazione e la classificazione dei possibili falli-

menti del sistema e quantitative, che stimano, in termini probabilistici,

i valori per i quali alcune metriche di dependability sono soddisfatte.


I metodi di previsione sono spesso utilizzati congiuntamente ai meto-

di di eliminazione per prevedere la quantita di guasti rimanenti nel

sistema dopo la fase di eliminazione.

1.1.3 Attributi della dependability

Per stimare il grado di dependability di un sistema e necessario, prima di

tutto, definire delle misure. Le principali misure di dependability utilizzate

sono le seguenti [11,12]:

- affidabilita (reliability): misura la continuita del sistema nel fornire un

servizio corretto;

- manutenibilita (maintainability): misura il tempo necessario per ripri-

stinare un servizio corretto dopo un fallimento;

- disponibilita (availability): misura la disponibilita nella fornitura di un

servizio corretto, rispetto all’alternanza fra servizio proprio ed impro-

prio;

- sicurezza (safety): misura l’assenza di conseguenze catastrofiche nell’u-

so del sistema sugli utenti e sull’ambiente;

- confidenzialita (confidentiality): misura l’assenza di divulgazione non

autorizzata d’informazione;

- integrita (integrity): misura l’assenza d’alterazioni improprie dello sta-

to del sistema, sia involontarie che intenzionali.

In generale, per ogni sistema saranno solo alcune le misure d’interesse ed i

singoli attributi potranno essere piu o meno importanti in base alle funzioni


che il sistema dovra svolgere. Oltre agli attributi appena citati se ne pos-

sono definire altri, come combinazioni o specificazioni dei precedenti come ad

esempio la security che indica l’assenza di accessi non autorizzati ed e data

dalla simultanea presenza di disponibilita, confidenzialita ed integrita.

Ulteriori attributi fondamentali per la caratterizzazione di sistemi informatici

sono la performance, il costo e la performability. Per performance s’intende

le misure che indicano come un sistema fornisce un servizio, in termini di

efficacia (es. ritardo o throughput) e di efficienza (es. utilizzo delle risorse).

La performability e invece un attributo che quantifica la capacita del sistema

di fornire un servizio degradato in seguito a fallimenti. E dunque una metrica

che unisce performance e dependability [13].

I concetti di performance, dependability e performability vengono inoltre

utilizzati come concetti base per definire sia la specifica che il rispetto della

specifica da parte del sistema.

Dunque, per poter valutare se un sistema, gia costruito o in fase di rea-

lizzazione, rispetta in maniera soddisfacente la specifica funzionale definita,

e importante attuare un processo di validazione.

Uno degli aspetti per realizzare la validazione e la capacita di poter valuta-

re caratteristiche sia quantitative che qualitative del sistema in esame. Le

tecniche utilizzabili per la valutazione di dependability, performance e per-

formability dei sistemi sono molteplici, ma possono essere classificate in due

categorie principali: le tecniche basate su modelli e quelle basate su misure.

1.2. DIAGNOSI 13

1.2 Diagnosi

L’attivita di diagnosi, nell’ambito di un sistema informatico, consiste nell’in-

terpretazione di una serie di informazioni raccolte al fine di ottenere un’indi-

cazione sulla presenza ed assenza di guasti nel sistema, la loro natura e la

loro localizzazione [30].

Esistono due approcci su cui e possibile basarsi per fare la diagnosi del

fallimento di un sistema [51]:

- diagnosi basata sulle specifiche, in cui e possibile progettare dei test

diagnostici mirati alla verifica di informazioni fornite in fase di sviluppo,

per determinare il corretto comportamento del sistema in particolari

condizioni.

Il sistema viene quindi sottoposto ad un test per controllare se rispetta

le specifiche. Il risultato del test e positivo se, in base all’input fornito,

la risposta ottenuta concorda con quella attesa, negativa altrimenti. I

test possono essere svolti in qualsiasi fase della vita del sistema ed a

qualsiasi livello tenendo pero in considerazione che, sia ogni fase sia

ogni livello, ammettono alcuni tipi di test e non ne consentono altri.

Ovviamente, piu il sistema e complesso e la funzione svolta da esso e

complicata, piu diventa difficile costruire un test efficace;

- diagnosi basata sui sintomi, la quale cerca di identificare un guasto in

base alla deviazione rispetto alla specifica, sfruttando sia i meccanismi

di log, contenenti gli eventi del sistema, che i dati rilevanti in tempo

reale.

Nei livelli di astrazione piu bassi, durante le fasi iniziali di sviluppo del siste-

ma, la diagnosi basata sulle specifiche e piu adatta, al contrario che nei livelli

piu alti, durante la fase d’uso del sistema. Infatti, i problemi che si verificano


in fase d’uso saranno meglio diagnosticati basandosi sui sintomi, piuttosto

che effettuando test i quali stressano il sistema in modo diverso rispetto al

normale carico di lavoro.

I meccanismi di diagnosi utilizzano due differenti strategie di funziona-

mento:

1. meccanismi off-line: operano mentre il sistema non sta lavorando e si

occupano di esaminare i report relativi ai messaggi di errore che sono

stati raccolti durante la fase di uso del sistema, in modo da fare fault

diagnosis;

2. meccanismi on-line: operano mentre il sistema sta lavorando e quindi

hanno la possibilita di influenzarne il comportamento. Esistono tec-

niche on-line che si basano sul conteggio degli errori e sul superamento

di una certa soglia [11][12] ed altre che invece verificano asserzioni [43].

I criteri in base ai quali si giudicano le prestazioni di un meccanismo di

diagnosi sono [47]:

- completezza: tutte i componenti guasti vengono diagnosticati come tali;

- accuratezza: un meccanismo di diagnosi e tanto piu accurato quanto

meno rileva falsi positivi, ovvero non considera come guasti componenti

che in realta funzionano perfettamente. In certe applicazioni o contesti,

privare il sistema di risorse che possono ancora fornire servizi corretti

puo risultare maggiormente deleterio che utilizzare gli stessi in modalita

degradata;

- prontezza: la diagnosi dello stato di un componente deve essere fatta

nel minor tempo possibile.

1.2. DIAGNOSI 15

Le caratteristiche che dovra avere il meccanismo di diagnosi sono dettate

dalle caratteristiche del sistema in cui si vuol fare diagnosi. Una prima

indicazione sull’approccio diagnostico da adottare e dunque data dal tipo di

sistema sul quale si dovra operare:

- sistemi tradizionali: sono sistemi costituiti da un insieme di componen-

ti omogenei dei quali si dispone di una profonda conoscenza. In questi

sistemi la diagnosi puo essere fatta con una granularita molto fine, per

cui la semantica della diagnosi risulta molto semplice [47]. L’obietti-

vo della diagnosi e l’identificazione dei componenti che mostrano un

comportamento “strano”, al di fuori della specifica e questa puo essere

fatta non appena si osserva un sintomo. La diagnosi si occupa dunque

di dare un giudizio oggettivo dello stato di un componente, in modo

tale da poter prendere decisioni su come trattarlo;

- sistemi contenenti componenti COTS o legacy: sono sistemi in cui ven-

gono utilizzati componenti generici (COTS1) invece di componenti pro-

gettati e realizzati ad-hoc, oppure componenti preesistenti (legacy2)

non modificabili o sostituibili con altri. Rispetto alla diagnosi in siste-

mi tradizionali, la granularita diventa piu grezza e la semantica della

diagnosi si complica a causa dei guasti di interazione causati dall’inte-

grazione tra componenti disomogenei. L’obiettivo della diagnosi cam-

bia: per evitare di sostituire prematuramente componenti, e necessario

1Un componente COTS (Commercial Off-The-Shelf) e un componente hardware o soft-

ware disponibile sul mercato. Un prodotto COTS e un componente generico, facilmente

reperibile ed a basso costo che, se paragonato a sistemi progettati e realizzati ad-hoc per

una certa esigenza, risulta relativamente instabile ed inaffidabile.2Un sistema legacy e un sistema o un’applicazione che continua ad essere usata poiche

l’utente non vuole o non puo rimpiazzarla o farla riprogettare soprattutto per i costi

d’implementazione e i costi da sostenere per la migrazione a nuovi sistemi.


sfruttare le poche informazioni a disposizione per decidere la politica

di recovery piu adatta;

- infrastrutture critiche di grandi dimensioni: sono sistemi connessi tra

loro in una rete molto complessa in cui le interdipendenze tra i vari sot-

tosistemi hanno un ruolo rilevante nella qualita del servizio fornito. In

questo genere d’infrastrutture, il fallimento di un nodo potrebbe provo-

care la saturazione di altri o un effetto “a cascata” che potrebbe mettere

fuori uso altre parti dell’infrastruttura. L’architettura del sistema deve

essere quindi in grado di adattarsi ai cambiamenti, talvolta imprevedi-

bili, che possono verificarsi, sia in termini di tipi di guasto che possono

colpire il sistema, che in termini di cambiamenti nei requisiti di de-

pendability. Per poter gestire questa imprevedibilita, la diagnosi deve

operare on-line per stabilire il livello di Quality of Service (QoS) offer-

to da un sottosistema e decidere se continuare a beneficiare dei servizi

che e in grado di offrire, oppure se e piu conveniente riconfigurare le

richieste ed inoltrarle altrove;

- sistemi futuristici: sono i sistemi del futuro in cui si avranno disposi-

tivi ovunque che interagiscono con infrastrutture molto estese, per cui

si prevede che si porranno problemi di interazione e di incremento del-

la complessita sia dei servizi sia delle infrastrutture stesse. Le infor-

mazioni si muoveranno su canali di comunicazione gestiti da infrastrut-

ture molto grandi, quindi saranno soggette a minacce. Il concetto di de-

pendability deve dunque essere esteso a quello di ambient dependability

[52] e la diagnosi dovra adattarsi alle nuove richieste.

Capitolo 2Strumenti per la diagnosi

La diagnosi e un passo essenziale per la definizione di strategie di fault to-

lerance, al fine di stabilire la causa degli errori, sia localizzandoli che de-

terminandone la natura. Malgrado i continui progressi nell’hardware e nel

software, gli utenti incontrano frequentemente problemi nell’uso di sistemi.

Quando si verifica un problema, uno strumento dovrebbe ricercarne la causa

esaminando lo stato ed il comportamento del sistema. Idealmente questo pro-

cesso dovrebbe avvenire senza alcuna interazione da parte dell’utente [46].

A causa della crescente complessita dei moderni sistemi, soggetti a requisiti

di dependability, e delle caratteristiche intrinseche di tali infrastrutture, che

spesso includono componenti COTS o legacy, la diagnosi e un’attivita com-

plessa e delicata, che richiede un’attenta valutazione dello stato o dell’entita

del danno dei singoli componenti. Le questioni da affrontare e che rendono

la diagnosi un compito critico, includono:

- la limitata conoscenza e l’altrettanto limitato controllo sul sistema nel

suo complesso, cosı come sui singoli componenti soprattutto se COTS

o legacy;

17

18 CAPITOLO 2. STRUMENTI PER LA DIAGNOSI

- l’eterogeneita dei componenti sotto analisi, al contrario dell’omogeneita

dei tradizionali componenti che venivano diagnosticati.

In una prospettiva piu ampia, la diagnosi deve valutare l’idoneita del com-

ponente (o sottosistema o infrastruttura) a fornire servizi con un’adeguata

qualita che puo cambiare dinamicamente. Da questo punto di vista, la vali-

dita di un componente non e strettamente legata all’assenza o alla presenza

di un guasto che puo comprometterne le funzionalita. Piu facilmente, e la

qualita del servizio globale che determina se tale componente e utile e con-

tribuisce alle attivita di sistema o se e meglio escluderlo.

Nella diagnosi tradizionale le assunzioni di base fatte derivano da contesti

dove tutte le anomalie sono riconducibili a guasti. Nei sistemi odierni che,

come gia detto, includono spesso componenti COTS o legacy, non tutti i mal-

funzionamenti sono riconducibili a guasti di singoli componenti, ma piuttosto

ad interazioni tra questi. Risulta quindi necessario allargare il contesto per

migliorare il sistema tramite interventi (automatici o umani) che non impli-

cano esclusivamente la riconfigurazione o la sostituzione di un componente,

ma, ad esempio, il cambiamento di servizio.

In letteratura sono stati proposti diversi metodi di diagnosi. Alcune

soluzioni comportano principalmente l’analisi di file di log di grandi dimen-

sioni per mezzo, eventualmente, di tool non automatici d’analisi statistica

che richiedono la supervisione umana, come ad esempio MieLog [7]. Sebbene

siano in grado di diagnosticare un ampio range di problemi, sono imprecisi e

richiedono un costo elevato soprattutto in termini di tempo [46]. Inoltre la

complessita dei sistemi impiegati eccede le capacita umane di diagnosticare

e rispondere rapidamente e correttamente ai problemi [26].

In altre soluzioni si preferisce utilizzare un approccio che mira all’identi-

ficazione di un fallimento, sfruttando sia le informazioni scritte nei log conte-

2.1. α-COUNT 19

nenti gli eventi di sistema, sia i dati rilevati in tempo reale. Tutto cio aiuta a

ricostruire le circostanze nelle quali si e verificato un errore oppure un evento

degno di nota, per cui la diagnosi esprime i propri giudizi valutando il com-

portamento del sistema.

Sono proposte anche molte metodologie di diagnosi basate sull’osservazione

del componente. Le euristiche, ad esempio, derivano da un ragionamen-

to intuitivo e riescono a fare discriminazione on-line tra guasti transienti e

permanenti. Tra le euristiche principali spicca α-count [13], mentre tra le

tecniche piu sofisticate suscita interesse il modello di diagnosi presentato in

[16] basato sulle catene di Markov nascoste, un’evoluzione del modello di di-

agnosi Bayesiana [44].

Inoltre sono stati impiegati strumenti automatici per l’osservazione degli

eventi. Questi strumenti sono in grado di fare diagnosi e quindi interpretare

dati raccolti al fine di identificare malfunzionamenti, svolgere monitoraggio

e dunque eseguire analisi periodiche e tenere sotto controllo l’intero operato

del sistema, compiere operazioni di filtraggio rendendo noti solo gli eventi

considerati rilevanti.

In questo capitolo si analizzano alcune tecniche basate su meccanismi auto-

matici e in particolare si descrivera l’euristica α-count, modelli piu sofisticati

come quello di diagnosi Bayesiana e quello basato sulle catene di Markov

nascoste ed infine saranno analizzati alcuni tool automatici per l’osservazione

di eventi.

2.1 α-count

α-count [13] e un meccanismo basato su uno schema count-and-threshold,

progettato per discriminare tra guasti transienti e guasti intermittenti, basan-


dosi sulle informazioni fornite dal meccanismo di rilevazione degli errori. Si

supponga dunque di avere un sistema costituito da un certo numero di com-

ponenti e dotato di sistemi di rilevazione degli errori.

Si supponga inoltre che i guasti a cui i componenti sono soggetti siano

classificabili in:

- guasti permanenti : generano errori ogni volta che il componente viene

utilizzato;

- guasti temporanei suddivisibili in

- guasti intermittenti : causati da parti interne al componente che

non rispettano le proprie specifiche funzionali. Tendono a di-

ventare guasti permanenti poiche, dopo essere apparsi la prima

volta, si ripresentano con frequenza;

- guasti transienti : non sono riconducibili ad un difetto del compo-

nente e, solitamente, scompaiono velocemente.

Il meccanismo α-count consiste nel contare gli errori manifestati da un

componente e nel diagnosticarlo guasto, in modo permanente, nel momento

in cui il valore del contatore supera una soglia prefissata. Se, con il passare

del tempo, non viene rilevata la presenza di errori, il valore del contatore

viene diminuito, in modo tale che la soglia venga superata solo con l’accu-

mularsi di errori ravvicinati nel tempo.

L’idea e quella di tollerare errori isolati considerandoli come manifestazione

di guasti transienti e di interpretare sequenze di errori ravvicinati come ma-

nifestazione di guasti permanenti.

Si mostra adesso in dettaglio il funzionamento del meccanismo alpha-count

2.1. α-COUNT 21

descritto in [13].

Si suppone che tutti gli eventi relativi ai guasti si verifichino ad istanti di

tempo discreti, descritti mediante la variabile L; due istanti di tempo succes-

sivi differiscono di un’unita di tempo costante. Per ogni componente, viene

emesso un segnale binario J (L) al passo L cosı definito:

- J (L) = 0 se non viene rilevato alcun errore;

- J (L) = 1 altrimenti.

Si suppone che il sistema di rilevazione non sia ideale e quindi fornisca se-

gnalazioni corrette con probabilita c, il che implica che un segnale puo essere

sbagliato con probabilita 1 − c. Con questa assunzione falsi positivi e falsi

negativi si presentano con la stessa probabilita.

Si assume che durante un intervallo di tempo il componente sotto esame

possa essere colpito al massimo da un singolo guasto transiente e/o da un

singolo guasto interno (intermittente o permanente in modo esclusivo). La

distribuzione dei guasti si suppone esponenziale in tutti i casi. Quando viene

rilevato un errore in un componente, si suppone che l’effetto di quell’errore

venga rimosso prima che il componente venga usato nuovamente.

Si suppone che il sistema di discriminazione non sia soggetto a guasti di alcun

tipo e che giudichi il componente in esame faulty (FC) se supposto affetto

da guasti permanenti o intermittenti, healthy (HC) altrimenti.

Il meccanismo α-count consiste nel raccogliere le segnalazioni d’errore

J (L) per calcolare, ad ogni istante L, il valore del contatore α come segue:

α(0) = 0

α(L) =

α(L−1) ·K se J (L) = 0

α(L−1) + 1 se J (L) = 1

dove 0 ≤ K ≤ 1 rappresenta la velocita con la quale il valore del contatore

α(L) viene fatto decrescere. Per come e definito α(L), se viene rilevato un

errore (J (L) = 1) il valore del contatore viene incrementato, mentre se non

viene rilevato alcun errore (J (L) = 0) tale valore viene fatto diminuire.

Ad ogni istante il valore del contatore α(L) viene confrontato con una soglia

αT :

- se α(L) < αT , il componente e da considerarsi sano, healthy ;

- se α(L) ≥ αT , il componente e da considerarsi guasto, faulty.

In pratica il parametro K determina con quale velocita il valore del contatore

α(L) “dimentica” le vecchie segnalazioni d’errore, mentre il valore della soglia

αT determina quante segnalazioni d’errore ravvicinate sono sufficienti per

considerare il componente “malato”.

Il meccanismo α-count deve dunque cercare di:

- segnalare il piu velocemente possibile tutti i componenti faulty ;

- evitare di fare false segnalazioni, ovvero non considerare faulty compo-

nenti che non lo sono.

Per bilanciare queste due richieste e raggiungere il comportamento desidera-

to del sistema, e necessario effettuare la giusta scelta dei valori assegnati ai

parametri K e αT , i quali sono parametri interni al meccanismo. La scelta di

tali valori ottimali dipende anche da altri fattori, come la bonta del meccani-

smo di rilevazione degli errori (correttezza, copertura) e le frequenze previste

per i guasti (transienti, intermittenti e permanenti)

2.1. α-COUNT 23

La definizione proposta precedentemente non e l’unica possibile: in [13]

viene presentata anche una funzione filtro definita come segue:

α(0) = 0

α(L) =

α(L−1) + 1 se J (L) = 1

α(L−1) − dec se J (L) = 0 e α(L−1) − dec > 0, dec ≥ 0

0 se J (L) = 0 e α(L−1) − dec ≤ 0

(2.1)

Con questa formulazione, il tempo di decadimento del valore del conta-

tore e proporzionale al valore stesso, mentre, nella prima formulazione, esso

dipende, a grandi linee, solo dal parametro K. Questo si traduce in una

diversa impostazione ottimale dei parametri interni del meccanismo (αT e

dec) ed anche in differenze nel comportamento stesso della funzione filtro.

Sempre in [13] e stata proposta un’ulteriore variante di α-count nella quale

s’impiega una funzione filtro che sfrutta due soglie αL e αH , con αL < αH .

Fintanto il valore del contatore α e minore della prima soglia αL, il compo-

nente viene considerato healthy e pertanto completamente utilizzato. Invece,

quando supera la soglia αL, il componente verra impiegato solo per scopi

diagnostici, cioe il suo comportamento sara solo monitorato dal sistema di

rilevazione degli errori. In altre parole, il componente e considerato come

“sospetto” ed i suoi risultati non verranno consegnati all’utente e non sara

fatto affidamento su di essi. Se il contatore α continuasse a crescere ed even-

tualmente oltrepassasse la seconda soglia αH , allora il componente sarebbe

diagnosticato come faulty e dunque affetto da un guasto permanente/inter-

mittente. Invece, quando il contatore α, dopo essere stato nel “limbo” tra αL

e αH , scende sotto la soglia αL, il componente sospettato viene ripristinato

in modo da tornare a fornire il pieno servizio.

Con questo schema, e possibile mantenere bassa la prima soglia αL per li-

mitare il ritardo di rilevazione e per aumentare la probabilita di escludere


componenti colpiti da una raffica di guasti, cercando di evitare tuttavia di

eliminarli del tutto gestendo la seconda soglia αH .

Uno svantaggio di questo approccio e l’esigenza di dover gestire anche gli

errori che si verificano in componenti confinati nel limbo: in realta, per con-

tinuare ad osservare il loro comportamento, hanno bisogno di essere trattati

esattamente come componenti on-line e dunque sani, aumentando cosı il

carico di lavoro del sottosistema di error-processing.

Infine in [13] vengono presentate le analisi di sensitivita del meccanismo di

α-count al variare dei parametriK e αT . Per queste analisi sono stati costruiti

dei modelli mediante l’utilizzo di SAN (Stochastic Activity Networks) e risolti

facendo uso di un tool (UltraSAN ) [50] nel quale sono state definite le misure

d’interesse quantificate successivamente per simulazione o per valutazione

analitica. Dall’analisi e risultato che:

- all’aumentare di K i tempi necessari per identificare un guasto si ac-

corciano, ma al tempo stesso aumenta il tempo durante il quale un

componente healthy non viene utilizzato poiche considerato faulty ;

- al diminuire di K, invece, aumenta il tempo necessario per l’identifi-

cazione di un guasto, ma diminuisce la quantita di tempo in cui un

componente healthy non viene utilizzato perche supposto faulty ;

- abbassando la soglia αT si diminuisce il tempo necessario all’identifi-

cazione dei guasti, ma si commettono piu errori nel riconoscimento dei

componenti faulty.

Dunque la scelta piu appropriata dipende da un’eventuale predominanza di

un parametro sull’altro ed e comunque appropriato cercare un compromesso

tra accuratezza e rapidita.

2.2. DIAGNOSI BAYESIANA 25

2.2 Diagnosi Bayesiana

Il meccanismo di diagnosi Bayesiana, descritto in [44], affronta dal punto

di vista probabilistico il problema della discriminazione in tempo reale tra

guasti transienti e permanenti, osservando il comportamento del componente.

Dopo ogni osservazione, il meccanismo aggiorna il valore della probabi-

lita che il componente sia affetto da un guasto permanente. Avendo una

stima della probabilita che un guasto permanente si sia verificato, e possibile

prendere una decisione sulle eventuali contromisure da intraprendere, con-

siderando le conseguenze che potrebbe avere ogni azione sia nel caso in cui

la stima sia giusta, che nel caso in cui sia sbagliata.

Si supponga di voler controllare il comportamento di un componente ef-

fettuando periodicamente un test su di esso. Il tempo viene suddiviso in

round, ciascuno costituito da due fasi: una fase di osservazione, nella quale

vengono raccolti una serie di dati ed una fase di aggiudicazione in cui ven-

gono analizzati i dati raccolti nella fase precedente per stabilire se sussistono

o meno degli errori. Mediante l’osservazione periodica dei risultati dei test

effettuati nei vari round, e possibile valutare lo stato di salute del componente

sfruttando, in questo caso, l’inferenza Bayesiana.

Sia x una congettura della quale si e incerti e P (x) la probabilita che

tale congettura sia vera. Dopo aver osservato nuova e rilevante evidenza,

si vuole aggiornare l’opinione su x in modo razionale. Sia l’evidenza che la

congettura sono descritte come eventi, cioe sottoinsiemi dell’insieme di tutti

i possibili risultati di un esperimento. Usando la definizione di probabilita

condizionale e possibile scrivere, in generale, che

P (x|evidenza)P (evidenza) = P (evidenza|x)P (x) (2.2)

Interpretando il termine piu a sinistra dell’equazione precedente come la pro-


babilita a posteriori della congettura x e il termine piu a destra come la

probabilita a priori, si ottiene:

Ppost (x|evidenza) =Ppri (x)P (evidenza|x)

P (evidenza)

Dato un insieme C di congetture mutuamente esclusive tale che la loro

unione ha probabilita 1, e possibile scrivere diversamente il membro a destra

dell’equazione precedente ed ottenere dunque la seguente equazione:

Ppost (x|evidenza) =Ppri (x)P (evidenza|x)∑

Conj∈C Ppri (Conj)P (evidenza|Conj)(2.3)

Il risultato di un test, in termini di inferenza Bayesiana, rappresenta l’evi-

denza nell’equazione 2.2. Si puo osservare che la probabilita a priori di una

qualsiasi congettura durante il round i si puo ottenere a partire dalle proba-

bilita a posteriori del round i − 1, corrette con le probabilita dei guasti che

si verificano nel frattempo (l’evidenza).

2.3 Meccanismo di diagnosi basato sulle catene

di Markov nascoste

Il modello descritto in [16] e [17] ha il duplice scopo di proporre un mec-

canismo di diagnosi dei guasti che sfrutti le caratteristiche delle catene di

Markov nascoste (HMM) e di presentare un modello matematico adatto alla

rappresentazione del problema diagnostico. Questo modello considera entita

separate il componente da diagnosticare, il sistema di rilevazione degli errori

che ne osserva il comportamento e il sistema di diagnosi dei guasti che deve

emettere sentenze diagnostiche sullo stato di salute del componente. L’in-

troduzione di questo tipo di modularizzazione porta benefici durante le fasi

di progettazione di un sistema, perche consente al progettista di valutare di-

2.3. MECCANISMO DI DIAGNOSI BASATO SULLE HMM 27

verse alternative di uno stesso modulo mantenendo inalterato lo scenario in

cui quel modulo deve operare.

2.3.1 Definizione di catena di Markov nascosta

Una catena di Markov nascosta e un insieme di variabili aleatorie cosı fatto:

- T variabili a tempo discreto Q1, . . . , QT che assumono valori nell’in-

sieme Ω = 1, . . . , N e che modellano il cambio di stato; le variabili Qt

costituiscono una catena di Markov del primo ordine a valori discreti

ed a tempo discreto;

- T variabili a tempo discreto X1, . . . , XT che assumono valori nell’in-

sieme Σ = σ1, . . . , σM e che modellano l’emissione dei simboli; le

variabili Xt costituiscono un processo stocastico a valori discreti ed a

tempo discreto.

Formalmente una catena di Markov nascosta MH puo essere rappresen-

tata con una quintupla MH =< Ω, ~π (1) , A,Σ, E > dove:

- Ω = 1, . . . , N e l’insieme degli stati in cui si puo trovare il modello;

- ~π (1) e il vettore delle probabilita di occupare gli stati nell’istante

iniziale:

~π (1) = (π1 (1) , . . . , πN (1))T

= (P (Q1 = 1) , . . . , P (Q1 = N))T

Il vettore deve essere inizializzato rispettando la seguente proprieta:

N∑i=1

πi (1) = 1


- A e la matrice delle transizioni, per cui si tratta della matrice di dimen-

sione N × N il cui generico elemento (i, j) rappresenta la probabilita

di transire dallo stato i allo stato j al tempo t:

A = [aij](i,j) = [P (Qt = j|Qt−1 = i)](i,j)

al variare di i e j in Ω. La matrice deve essere inizializzata rispettando

la seguente proprieta:

N∑j=1

aij = 1 ∀i = 1, . . . , N

- Σ = σ1, . . . , σM e l’insieme dei simboli osservabili, detto anche alfa-

beto;

- E e la matrice delle emissioni, ovvero la matrice che raccoglie le proba-

bilita di emettere i simboli appartenenti all’alfabeto Σ a partire dagli

stati appartenenti a Ω.

Si definisce ek (σ) la probabilita di emettere il simbolo σ nell’istante t

dato che il modello si trova nello stato k:

ek (σ) = P (Xt = σ|Qt = k)

La matrice E, di dimensione N ×M , risulta cosı definita:

E =

e1 (σ1) . . . e1 (σj) . . . e1 (σM)...

......

ei (σ1) . . . ei (σj) . . . ei (σM)...

......

eN (σ1) . . . eN (σj) . . . eN (σM)

2.3. MECCANISMO DI DIAGNOSI BASATO SULLE HMM 29

La matrice viene definita rispettando la seguente proprieta:

∑σ∈Σ

ek (σ) = 1 ∀k = 1, . . . , N

Il modello viene osservato dall’esterno mediante i simboli emessi dal sistema

stesso. Si assume che la catena sia time-homogeneous. I simboli vengono

emessi esclusivamente in base allo stato corrente il quale dipendente solo

dallo stato precedente.

Inoltre l’evoluzione nel tempo di una catena di Markov nascosta prevede la

definizione dei concetti di:

- cammino C come insieme ordinato di stati ω1, . . . , ωL ∈ Ω che vengono

percorsi in sequenza:

C , (ω1, . . . , ωL)

- osservazione O come insieme ordinato di simboli o1, . . . , oL ∈ Σ che

vengono emessi in sequenza:

O , (o1, . . . , oL)

2.3.2 Il modello di diagnosi dei guasti

Lo scopo del meccanismo di diagnosi dei guasti e fare una stima della situa-

zione in cui si trova il componente, in modo da sollevare un allarme quan-

do tale situazione viene ritenuta pericolosa. Il meccanismo di diagnosi dei

guasti basa il proprio lavoro sulle informazioni e sulla sequenza dei simboli

provenienti dal sistema di rilevazione degli errori.

La teoria delle catene di Markov nascoste permette di fare delle stime

sulle probabilita che il modello del componente possa trovarsi nei vari stati

(guasti), basandosi sulle osservazione dei simboli (messaggi di errore) che il


modello emette. le informazioni necessarie per stimare la situazione nell’i-

stante t sono costituite dall’osservazione di un certo numero di simboli (L)

fino all’istante t e dalla situazione in cui si trovava il modello quando ha co-

minciato ad emettere i simboli di tale osservazione (la stima relativa all’istan-

te t−L). Nel caso del modello della diagnosi dei guasti si ha quindi bisogno

della situazione iniziale del modello (~π(1)) e della sequenza dei simboli emessi

fino all’istante del quale si sta cercando di fare la stima.

Si supponga che l’insieme degli stati in cui si puo trovare il modello del

componente sia Ω = 1, . . . , k, . . . , N e che la sequenza dei simboli emessi dal

modello del sistema di rilevazione degli errori fino all’istante t sia o1, . . . , ot.

Sia fk(t) la probabilita che nell’istante t lo stato in cui si trova il modello del

componente sia k e che la sequenza di simboli osservata fino all’istante t sia

proprio o1, . . . , ot. Allora il vettore normalizzato~f(t) di N componenti del

tipo fk(t) e definito nel seguente modo:

~f (1) =

1

S1

· Do1 × ~π(1)

~f (t+ 1) =

1

St+1

· Dot+1 × AT ×~f (t) t ≥ 1

Dove St e il valore normalizzante definito come:

S1 =∑ω∈Ω

eω (o1) · πω (1)

St+1 =∑ω∈Ω

eω (ot+1) · ~aTω ×~f (t) t ≥ 1

Doke la matrice diagonale costruita a partire dai valori e1 (ok) , . . . , eN (ok)

della matrice delle osservazioni, la quale fornisce la probabilita di osservare

un preciso simbolo dato che il modello si trova in un dato stato.

Il modello di diagnosi dei guasti calcola~f al tempo (t + 1) basandosi su

~f al tempo t e sul simbolo osservato ot+1. Quindi ad ogni istante di tempo

2.4. EVENT CORRELATION 31

il meccanismo calcola la probabilita che il modello si trovi in ciascun stato,

inteso come stato, previsto in Ω, basandosi sulle sequenze di simboli, intesi

come messaggi d’errore, osservati.

Il costo computazionale per il calcolo di~f(t+1) a partire da

~f(t) e dell’or-

dine di O(N2), per cui non dipende dal particolare istante temporale t. La

quantita di informazioni necessaria per il calcolo e costante rispetto al tempo.

Non serve infatti conservare altre informazioni se non il vettore~f relativo al

passo precedente e l’ultimo simbolo emesso dal sistema di rilevazione degli

errori.

2.4 Event correlation

Con i ristretti budget IT odierni, si cerca sempre di fare il piu possibile

con meno risorse. Uno dei compiti che richiede molto tempo e quindi viene

trascurato, e il monitoraggio del sistema per il rilevamento dei problemi.

Non individuare e dunque non risolvere questi problemi porta rapidamente

all’inattivita ed alla perdita di produttivita. Uno dei principali obiettivi af-

frontati nella gestione di un sistema e il monitoraggio automatico.

I cambiamenti di stato importanti vengono chiamati eventi (es. la perdita di

un link su un router, la rottura della connessione TCP tra due applicazioni,

ecc.). Questi eventi vengono riportati agli operatori umani (amministratori

di sistema) tipicamente mediante event message. Pero la quantita di questi

event message spesso diviene eccessiva per essere gestita da un essere umano.

Infatti, gli effetti dei guasti sono frequentemente rilevati da piu componenti

simultaneamente che notificano i sintomi del problema causando lo sgrade-

vole fenomeno detto event message storm. Inoltre trovare errori tra tutti gli

eventi di routine per un essere umano, puo essere difficile, noioso e costoso


in termini di tempo.

Molte soluzioni di monitoraggio riassumono quotidianamente i file di log in

cui vengono riportati i vari eventi e li analizzano off-line il giorno seguente.

Questo puo essere utile per la raccolta statistica e il rendiconto degli eventi,

ma se l’obiettivo e individuare i problemi in tempo reale (on-line) e risolverli,

la riesamina degli eventi, il giorno dopo, non e molto vantaggiosa!

Gli amministratori di sistema non possono risolvere in modo proattivo o

reagire velocemente ai problemi, a meno che essi non siano consapevoli del-

l’esistenza di tale problema. Non e utile scoprire nella sintesi del mattino

seguente che il server primario ha segnalato un problema pochi minuti prima

di fallire. E dunque necessario scoprire questi problemi in tempo per risolverli

evitando cosı una perdita catastrofica di servizio.

Per ridurre l’ammontare degli event message mostrati all’amministratore

ed affrontare il problema dell’event message storm, s’impiega l’event corre-

lation. L’event correlation e un processo dove eventi irrilevanti sono filtrati,

quindi non presentati all’utente e vengono derivati nuovi eventi da quelli gia

esistenti. Ad esempio gli eventi “temperatura interna troppo alta” e “dispo-

sitivo irraggiungibile” potrebbero essere sostituiti dal singolo evento “dispo-

sitivo bloccato a causa di temperatura interna troppo alta”. In [25] l’event

correlation viene definita come una procedura d’interpretazione concettuale,

nel senso che viene assegnato un nuovo significato all’insieme di eventi che si

verificano in un certo intervallo di tempo.

E possibile distinguere tre aspetti per l’event correlation:

- aspetto funzionale: la correlazione e incentrata sulle funzioni fornite da

ciascun elemento del sistema;

- aspetto topologico: la correlazione tiene conto di come i componenti del

sistema sono collegati gli uni con gli altri e in che modo interagiscono;


- aspetto temporale: quando ci sono vincoli temporali devono essere

definiti esplicitamente un tempo d’inizio e di fine per ogni evento. La

correlazione puo usare queste relazioni temporali tra gli eventi.

In [25] viene fornita una classificazione delle operazioni che possono essere

eseguite sugli eventi durante il processo di correlazione (questa classificazione

e stata adottata in varie ricerche come [38][27]):

- Compression: sostituisce l’evento ripetuto A con una singola occorren-

za dell’evento A;

- Suppression: sopprime un evento A se e presente un certo contesto

operazionale;

- Filtering : sopprime un evento A se uno dei parametri assume un certo

valore;

- Counting : conta il ripetersi di un evento A e se il numero raggiunge

una determinata soglia lo sostituisce con il singolo evento B;

- Scaling : in presenza di un certo contesto operazionale, sostituisce un

evento A con un evento B, dove uno dei parametri di B assume un

valore piu alto;

- Generalization: sostituisce un evento A con un evento piu generale B

se e presente un certo contesto operazionale;

- Specialization: sostituisce un evento A con un evento piu specifico B

se e presente un certo contesto operazionale;

- Temporal relationship: mette in relazione gli eventi in base all’ordine

di arrivo e/o al tempo della loro generazione;


- Clustering : genera un evento A se sono rilevati pattern di correlazione

piu complessi. L’operazione di clustering puo prendere in considerazio-

ne il risultato di test esterni o una combinazione di alcune operazioni

di correlazione precedentemente elencante.

Si fornisce adesso una panoramica sulle tecniche di event correlation

presentando i principali approcci esistenti in letteratura.

2.4.1 Tecniche di event correlation

Negli ultimi venti anni sono state introdotte molte tecniche di event correla-

tion basate su vari tipi di approcci. In [38] e fornita una suddivisione di tali

tecniche.

Rule-based correlation

La rule-based correlation (RBR) utilizza un insieme di regole per l’event cor-

relation. Le regole sono della forma “IF condition THEN action”. La con-

dizione condition usa gli eventi ricevuti e le informazioni sul sistema, mentre

action contiene le azioni che possono portare a cambiamenti di sistema o

all’utilizzo di parametri per la scelta della regola successiva.

Un vantaggio di questo approccio e che le regole sono facilmente leggibili

dall’utente e quindi il loro effetto e intuitivo. La correlazione e fornita molto

velocemente mediante l’utilizzo dell’algoritmo Rete [19]. La rule-based corre-

lation e adatta per i casi in cui le relazioni tra gli eventi sono ben note e pos-

sono essere formulate chiaramente. Inoltre in questo approccio il processo di

event correlation e completamente determinato da regole personalizzate dal-

l’utente. Poiche permette all’utente il pieno controllo dell’event correlation,

l’approccio rule-based e il piu adottato [35][25].


Malgrado i vantaggi dei sistemi rule-base, sono presenti alcune limitazioni

riguardo ai frequenti cambiamenti che potrebbero esserci nell’ambiente model-

lato. Questi costringerebbero l’utente ad apportare aggiornamenti alle regole.

In altre parole, se il sistema cambia rapidamente, risulterebbe difficile man-

tenere un accurato insieme di regole. Per ovviare a questo inconveniente sono

state utilizzate, con successo, tecniche di data mining [27].

Model-based reasoning

Il model-based reasoning (MBR) [24][32][58] rappresenta un sistema model-

lando ogni suo componente. Un modello puo rappresentare un’entita fisica o

un’entita logica. I modelli per l’entita fisiche sono chiamati modelli funziona-

li, mentre i modelli per tutte l’entita logiche sono chiamati modelli logici. La

descrizione di ogni modello contiene tre categorie di informazioni: attributi,

relazioni con gli altri modelli e comportamento. L’event correlation e il risul-

tato della collaborazione tra modelli.

Una volta rappresentate tutti i componenti del sistema con il loro compor-

tamento, e possibile eseguire simulazioni per predire il comportamento del

sistema.

In [58] e mostrato che in un grande sistema MBR non e facile fare

manutenzione. Puo essere difficile modellare appropriatamente il compor-

tamento di tutti i componenti e le loro interazioni correttamente e completa-

mente. Infatti questi modelli non catturano tutti gli aspetti del sistema ma

identificano solo quegli aspetti che aiutano ad identificare i malfunzionamenti

del sistema e li modellano appropriatamente[42]. Il sistema NetExpert [2] e

un esempio di sistema MBR.


Codebook approach

Il codebook o coding approach [29][28] ha similarita con il rule-based corre-

lation, ma fa un ulteriore passo avanti e codifica le regole in una matrice di

correlazione.

L’approccio inizia usando un grafo delle dipendenze con due tipi di nodi per

la modellazione. Il primo tipo di nodi sono i guasti (chiamati, negli arti-

coli citati, problemi) rilevati, mentre il secondo tipo di nodi sono gli eventi

osservabili (chiamati, negli articoli citati, sintomi) i quali sono la causa dei

guasti o di altri eventi. Le dipendenze tra i nodi sono rappresentate con archi

orientati. E possibile anche assegnare un peso agli archi, ad esempio un peso

associato alla probabilita che un guasto/evento A causi un evento B.

Dopodiche il grafo viene trasformato in una matrice di correlazione dove le

colonne contengono i guasti e le righe gli eventi. Se c’e una dipendenza nel

grafo, la cella appropriata della matrice e impostata con il peso dell’arco

corrispondente. Nel caso in cui non siano usati archi pesati, le celle della

matrice contengono 1 se esiste una corrispondenza, 0 altrimenti.

Successivamente puo essere fatta una semplificazione in cui gli eventi, che

non aiutano a discriminare i guasti, vengono eliminati. La correlazione e fat-

ta attraverso la scelta del guasto piu vicino all’evento, in termini di distanza

di Hamming. Il numero di righe (eventi) che possono essere eliminati dalla

matrice possono differire molto in base alle relazioni [32].

L’approccio codebook ha il vantaggio di utilizzare grafi e codifiche di

cui c’e grande esperienza. Questa esperienza e impiegata soprattutto per

minimizzare il grafo delle dipendenze e selezionare il gruppo ottimale di eventi

per quanto riguarda il tempo di processazione e la robustezza.

Uno svantaggio di questo approccio e che frequenti cambiamenti nell’am-

biente rendono necessarie frequenti modifiche nel grafo delle dipendenze.


SMARTS InCharge [29][5] e un esempio di sistema di correlazione che

utilizza il codebook approach.

Case-based reasoning

Come alternativa all’approccio di rule-based correlation, e stata proposta una

tecnica denominata case-based reasoning (CBR) [31][32] [53] [57]. A differen-

za degli altri approcci, i sistemi CBR non utilizzano alcuna conoscenza sulla

struttura del sistema.

L’unita base non e piu la regola ma il case. I case sono dei registri contenenti

gli aspetti piu rilevanti degli episodi passati e sono memorizzati, recuperati,

adattati ed utilizzati nelle soluzioni di nuovi problemi. Se si verifica un

nuovo case, il sistema CBR confronta i parametri correnti del sistema con

quelli precedenti e cerca di trovarne uno simile. Per identificare un match

deve essere definito per quali parametri il case puo differire o meno. Se non

viene rilevato alcun match, puo essere eseguita automaticamente un’azione

d’apprendimento oppure l’utente puo esserne informato.

Un vantaggio di questo approccio e la capacita di apprendimento: pro-

prieta importante per ambienti che subiscono rapidi cambiamenti.

Sono presenti pero alcune difficolta nel CBR [32]. I campi usati per

trovare i case simili e la loro importanza devono essere definiti appropria-

tamente. Se vi e un match con un case simile, deve essere trovato un

adeguamento della soluzione precedente con quella corrente.

Originariamente il CBR non era destinato ad applicazioni real-time su

larga scala. A causa della relativa complessita dei case, le procedure di

matching tra case nella maggior parte delle applicazioni CBR sono piu de-

boli di quelle implementate nei sistemi codebook o nei sistemi RBR. Alcuni


miglioramenti delle performance potrebbero essere realizzati semplificando la

struttura dei case [37].

Un esempio di sistema per il CBR e SpectroRx dal Cabletron Systems.

La parte di Cabletron che ha sviluppato SpectroRx e diventata nel 2002 una

compagnia di software indipendente sotto il nome di Aprisma Management

Technologies e dal 2005 si e trasformata in Concord Communications [6].

2.4.2 Confronto tra gli approcci disponibili

Non e possibile stabilire quale tecnica sia la migliore in termini di precisione

e/o complessita per risolvere il problema dell’event correlation. Il confronto

tra i metodi e gli algoritmi presentati e un processo difficile e deve prendere

in considerazione vari fattori. In generale, e necessario trovare una relazione

di compromesso tra:

- la facilita di costruzione di un modello teorico;

- la complessita d’implementazione;

- la facilita di adattare i cambiamenti negli oggetti del sistema;

- le performance;

- la precisione.

Solitamente gli approcci basati sulle regole sono indicati per la corre-

lazione di sistemi in cui la configurazione non viene modificata frequente-

mente. Altri approcci, come quelli case-based, sono poco suscettibili ai cam-

biamenti, ma manca una base teorica la quale permette il loro utilizzo in

sistemi di grandi dimensioni. Approcci come il model-based reasoning pre-

sentano una struttura aggiuntiva la quale facilita lo sviluppo di applicazioni

ma non li rende allettanti a causa delle scarse performance.

2.5. STRUMENTI AUTOMATICI PER OSSERVARE EVENTI 39

Nell’ottica di analizzare infrastrutture critiche non soggette a frequenti

cambiamenti, in cui si necessita di risposte rapide, per non dire immediate e

di un modello di diagnosi facilmente personalizzabile ed intuitivo, si e deciso

di sfruttare un approccio basato sulle regole.

2.5 Strumenti automatici per l’osservazione

di eventi

Gli event correlator sono strumenti che cercano di condensare molti eventi in

poche e significative informazioni sottoforma di eventi. Un event correlator

affronta tre tipi di problemi:

1. Riduce il numero degli eventi soprattutto per eliminare il problema del-

l’event storm. Questo riduce sia il carico di lavoro degli amministratori

che il periodo di tempo tra il rilevamento e la riparazione di un guasto.

2. Gli eventi devono indicare la causa di un problema invece dei sintomi.

Dedurre la causa di un guasto da un insieme di sintomi richiede notevole

esperienza e competenza degli amministratori.

3. Gli eventi talvolta sono riferiti alle persone sbagliate e questo causa un

doppio lavoro. Gli eventi trasmessi da un event correlator dovrebbero

contenere le informazioni necessarie da notificare alle persone esperte.

Questi tre problemi sono collegati tra loro: tutti possono essere risolti se

l’event correlator e in grado di dedurre la causa del problema dai sintomi

riportati di componenti del sistema. In questa sezione si analizzeranno alcuni

strumenti di analisi automatici dei file di log: Logsurfer+ [1], Swatch [23],

SEC [55] e LoGS [45].


2.5.1 Logsurfer+

Logsurfer+ [1] e un tool real-time per il monitoraggio dei file di log. E scritto

in C ed e estremamente efficiente anche nel gestire un grosso carico di lavoro.

Logsurfer+ e un semplice, piccolo ed efficiente programma che puo moni-

torare in real-time i file di log ed inviare allarmi intelligentemente quando si

verificano delle anomalie. A differenza di altri sistemi di monitoraggio, come

Swatch (sezione 2.5.2), Logsurfer+ puo essere ottimizzato e sintonizzato per

inviare un solo allarme contenente tutte le informazioni rilevanti invece di

inviare una raffica di notifiche.

Logsurfer+ lavora su una singola linea di testo di un file di log. Esso

confronta ogni linea con un’espressione regolare facente parte di un insieme

di regole ed esegue alcune azioni definite appositamente per questo match.

Logsurfer+ usa regole per definire azioni per i messaggi (singole linee) i quali

possono essere raccolti in context. Inizialmente e necessario definire un in-

sieme di regole nel file di configurazione. Mentre viene processato un mes-

saggio di log, Logsurfer+ e capace dinamicamente di aggiungere o eliminare

regole, creare o distruggere context, invocare programmi esterni per avvisare

chi di dovere o eseguire automaticamente ulteriori azioni.

Una regola e un insieme di espressioni regolari. Se una linea di messag-

gio soddisfa una regole, allora viene eseguita l’azione associata. Le possibili

azioni sono: ignorare il messaggio, eseguire un programma esterno, passare

una linea di messaggio come standard input ad un programma esterno, creare

o eliminare un context, generare un report o aggiungere una nuova regola

dinamicamente. In aggiunta a queste azioni, le regole possono avere una

configurazione per auto-eliminarsi se un altro messaggio (specificato sem-

pre mediante espressioni regolari) viene processato oppure se e scaduto un

timeout.


Vantaggi e svantaggi

Logsurfer+ e in grado di cambiare dinamicamente le sue regole basandosi su

eventi o sul tempo. Questo fornisce gran parte della flessibilita necessaria a

correlare gli eventi. Tuttavia, ha una sintassi difficile da utilizzare ed e molto

complicato ottenere correlazioni complesse tra piu applicazioni. Anche il de-

bugging e piuttosto difficoltoso a causa della natura dinamica di Logsurfer+.

Inoltre il programma potrebbe aver bisogno di molta memoria ed e necessario

che il sistema operativo controlli le risorse.

2.5.2 Swatch

I principali obiettivi di Swatch [23] sono quattro:

1. configurare il programma in modo tale che qualsiasi amministratore

possa apprendere il suo funzionamento in poco tempo;

2. avere un semplice insieme di azioni che possono essere eseguite dopo

aver ricevuto certi tipi d’informazioni;

3. permettere agli utenti di Swatch di definire proprie azioni e consentire

di usare parte dell’input come argomento delle azioni;

4. avere la possibilita di riconfigurare Swatch, su richiesta o dopo un in-

tervallo di tempo specificato, durante la sua esecuzione senza doverlo

arrestare o riavviare manualmente.

Swatch puo essere eseguito in tre differenti modi:

- passandogli come argomento un file;

- guardando i messaggi che vengono aggiunti al file in corso d’aggiorna-

mento;


- esaminando lo standard output di un programma.

La piu potente funzionalita di Swatch e poter esaminare le informazioni che

vengono aggiunte al file di log avvisando immediatamente degli eventuali

problemi che si verificano. Ricevere le notifiche tempestivamente, ad esempio

sugli utenti loggati, e spesso utile sia per le indagini che per scoprire eventuali

attacchi da parte di hackers o account compromessi. Inoltre Swatch puo

leggere ed esaminare un intero file (ad esempio un vecchio file di log o un

comune file di testo) passatogli in input. Questa funzionalita puo essere

utile per “mettersi in pari” con il monitoraggio dopo essere stati lontani dal

computer ed avere quindi del lavoro arretrato. Infine Swatch puo esaminare

l’output di un programma per poter analizzare informazioni che non vengono

mantenute in un file di testo o che richiedono un particolare processo di

lettura.

Swatch si basa sul matching tra espressioni, e scritto in Perl e si suddivide

in tre parti:

- Configuration file. Ogni linea in un configuration file di Swatch e

composta da quattro campi separati: una pattern expression, un in-

sieme di azioni che devono essere svolte se l’espressione e soddisfatta,

un intervallo di tempo opzionale ed eventualmente la posizione di un

timestamp. Il pattern deve essere un’espressione regolare accettata

dal Perl. Ogni stringa viene confrontata con l’espressione nel file di

configurazione e se tale match e soddisfatto vengono eseguite le azioni

corrispondenti. L’intervallo di tempo puo essere usato per eliminare

i messaggi ridondanti. La posizione del timestamp e opzionale e puo

essere utilizzata solo quando e specificato un intervallo di tempo ed e

spesso confrontato con il timestamp di altri messaggi.


- Libreria delle azioni. Swatch ammette alcune azioni per visualizzare sul

terminale di controllo i messaggi, inviare un segnale, ignorare gli eventi

e permettere di utilizzare delle linee che soddisfano un’espressione come

input di un particolare comando.

- Controlling program. Il controlling program e Swatch stesso, ma il vero

lavoro e svolto da un processo osservatore. Il primo compito di Swatch

e tradurre il file di configurazione in uno script Perl. L’osservatore

contiene due gestori di segnali: se viene ricevuto un segnale d’allarme

o di sospensione, Swatch terminera il processo osservatore, rileggera il

file di configurazione ed iniziera un nuovo processo osservatore; se viene

ricevuto un segnale d’uscita, di terminazione o d’interruzione, Swatch

concludera la sua esecuzione.


Swatch ha dimostrato di essere un prezioso tool per il monitoraggio di una

grande collezione di dati. Fornisce il supporto per ignorare gli eventi ridon-

danti e per modificare le regole sulla base del tempo d’arrivo. Tuttavia il

linguaggio di configurazione di Swatch non fornisce la capacita di correlare

eventi arbitrari nel tempo. Inoltre manca la capacita di attivare/disattivare

le regole in base all’esistenza di altri eventi.

2.5.3 SEC

SEC (Simple Event Correlator) ([55] [48]) e un tool scritto in Perl progettato

per eseguire l’analisi dei file di log. SEC legge un input stream da un file, da

una pipe o dallo standard input ed applica operazioni di pattern matching


all’input cercando il pattern specificato mediante regole che si trovano nei

file di configurazione.

Quando una regola e soddisfatta, viene eseguita una certa azione. SEC

ammette vari tipi di regole per la correlazione degli eventi.

- Single: se l’input event soddisfa il match esegue l’azione immediata-

mente;

- SingleWithScript : integra script esterni con il pattern matching. Se

il match e soddisfatto e il valore di ritorno dello script e valido, viene

eseguita immediatamente l’azione;

- SingleWithSuppress : effettua un’azione di compressione. Istanze mul-

tiple di un evento, all’interno di una finestra temporale, sono ridotte a

un singolo evento;

- Pair : combina due o piu eventi in un singolo evento all’interno di

una data finestra temporale. Se l’input event soddisfa il match, ese-

gue immediatamente un’azione, ignorando tutti gli eventi successivi

fino all’arrivo di un altro input event che soddisfa un ulteriore match.

All’arrivo del secondo input event esegue un’altra azione;

- PairWithWindow : se l’input event soddisfa il match attende per t

secondi l’arrivo di un altro input event. Se l’input event non viene

osservato nel tempo stabilito esegue un’azione, altrimenti ne esegue

un’altra;

- SingleWithThreshold : conta i match che si verificano all’interno di una

finestra temporale. Quando questi raggiungono una soglia prefissata

viene eseguita un’azione e tutti gli ulteriori match vengono ignorati

fino allo scadere della finestra temporale;


- SingleWith2Threshold : conta i match durante t1 secondi e se viene

superata una soglia prefissata, esegue un’azione. Dopodiche azzera

il contatore e continua a contare i match per altri t2 secondi. Se il

contatore resta al di sotto di una seconda soglia esegue un’altra azione;

- Suppress : se l’input event soddisfa il match viene soppresso. Questa

regola non compie azioni;

- Calendar : esegue un’azione ad un tempo specificato.

I pattern supportati da SEC sono sottostringhe, espressioni regolari e

funzioni Perl. Inoltre ammette l’uso dei context.

Le principali azioni messe a disposizione da SEC permettono di scrivere sullo

standard output o su file, eseguire comandi di shell e mini-programmi Perl e

definire variabili locali interne a SEC.

Nell’appendice A sono presentati maggiori dettagli del tool.


SEC e un tool molto flessibile che permette di specificare correlazioni com-

plesse le quali possono essere usate per modellare sequenze di eventi.

SEC fornisce anche un meccanismo di aggregazione di eventi e di modifica

delle regole in base agli eventi. Anche se non crea dinamicamente regole

come Logsurfer+, vi e comunque la possibilita di generare facilmente regole

che forniscono le stesse funzionalita.

La scelta di Perl come linguaggio d’implementazione e un vantaggio poiche

e un linguaggio ampiamente conosciuto, indipendente dalla piattaforma e di

rapido sviluppo. Tuttavia, l’utilizzo di un linguaggio interpretato causa un

rallentamento nella velocita di esecuzione e richiede piu memoria in fase di

esecuzione rispetto a un linguaggio compilato.


Infine un problema puo essere dovuto al fatto che SEC non analizza i

timestamp degli eventi, ma si basa sull’ordine di arrivo di questi.

2.5.4 LoGS

LoGS [45] ha un insieme di regole (ruleset) dinamico, e capace di cercare

uno o piu messaggi prima di innescare un’azione e ha un potente linguaggio

di programmazione utilizzato per la configurazione e le successive estensioni.

LoGS e un motore d’analisi programmabile, scritto interamente in Common

Lisp1 ed utilizza il sistema di oggetti CLOS2.

LoGS e composto da cinque differenti componenti: messaggi, regole, in-

sieme di regole (ruleset), azioni e context. Questi componenti sono simili alle

loro equivalenti in Logsurfer+ con l’aggiunta del ruleset.

I messaggi sono singoli pezzi di input da una sorgente dati (ad esempio una

linea di un file di log). Se i messaggi soddisfano le regole, s’innescano le azioni

relative ai messaggi soddisfatti. I context raccolgono i messaggi entranti e

si comportano in modo simile alle regole, ad eccezione del fatto che questi

possono essere soddisfatti da messaggi multipli. Le azioni sono usate per

rispondere a un evento e sono innescate quando una regola o un context sono

soddisfatti.

Le regole soddisfatte dai messaggi innescano azioni. Una regola consiste

di sette componenti opzionali: una funzione di match, una funzione di no-

match, una funzione di delete-rule, una funzione di no-delete-rule, un timeout

1Il Common Lisp (CL) e un dialetto del linguaggio di programmazione Lisp, sviluppato

per porre uno standard fra le altre divergenti varianti del Lisp. E un linguaggio multi-

paradigma, dinamico che facilita lo sviluppo rapido di applicazioni complesse, con un

compilatore che permette la creazione di programmi efficienti.2Sistema ad oggetti che supporta metodi multipli, la loro combinazione e l’ereditarieta

multipla.


assoluto, un valore di continuita e una lista di azioni. Si osservi che, anche

se tutti e sette questi campi sono opzionali, e solito indicare sempre almeno

una funzione di match.

La funzione di match e utilizzata per determinare quali messaggi sod-

disfano le regole; la funzione di no-match determina invece quali sono le

eccezioni. La funzione di delete-rule e utilizzata per determinare se una re-

gola, una volta stabilito il match con un messaggio, deve essere cancellata

dopo la sua esecuzione; la funzione di no-delete-rule specifica le eccezioni a

questo. Il valore di timeout indica il tempo assoluto, in secondi, dopo il quale

una regola deve essere cancellata. Il valore di continuita indica se testare le

successive regole nel ruleset. Infine la lista delle azioni e una lista di funzioni

di Common Lisp.


LoGS e un tool per l’analisi dei log potente, dinamico ed estendibile. Per-

mette anche di esprimere regole molto complesse e, al contrario di altri pro-

grammi, non ha un proprio linguaggio di configurazione, ma le sue regole

sono scritte in Lisp. Se da una parte questo fornisce molta flessibilita nella

progettazione delle regole, dall’altra richiede moltissima esperienza da parte

degli utilizzatori riducendone notevolmente il suo impiego.

2.5.5 Scelta del tool

I sistemi e i metodi di monitoraggio presuppongono sistemi e metodi di pro-

grammazione con i quali si predispongono i valori di soglia o gli indicatori o

i valori desiderati che, in continuo o ad intervalli regolari, vengono utilizzati

per analizzare l’andamento del sistema che viene monitorato.

Per scegliere il tool con cui effettuare monitoraggio, cioe vigilare un sistema,


e necessario considerare vari aspetti. Innanzitutto bisogna valutare il tipo di

monitoraggio che il sistema richiede, ovvero:

- monitoraggio continuo: il sistema deve essere perennemente sotto os-

servazione. Nei sistemi piu semplici si effettua con uno strumento che

rileva un segnale/valore, tracciandone l’andamento (esempi tipici sono

i sismografi, i tracciatori di temperatura, pressione, ecc.). Esistono

sistemi complessi, ma inseriti in un contesto non critico, che vanno co-

munque monitorati, come ad esempio i sistemi di monitoraggio nelle

telecomunicazioni e nella gestione di reti informatiche. In questo caso

vengono rilevate soprattutto presenze/assenze di dati o connessioni, e

tali eventi fanno scattare procedure automatiche di backup o diverso in-

stradamento, o procedure di salvataggio, ecc. Infine e d’obbligo vigilare

sistemi complessi ed oltretutto inseriti in un contesto critico. Questi

sono veri e propri sistemi informatici dove vi e una strumentazione e un

software specializzato (tipici esempi sono la complessa strumentazione

in sala di rianimazione o di terapia intensiva nei pronti soccorsi dove gli

strumenti di monitoraggio rilevano in continuo pressione, temperatura

ed altri valori critici; i sistemi di controllo delle centrali elettriche e

delle centrali termonucleari, ecc.);

- monitoraggio ad alta frequenza: si parla di monitoraggio anche quando

la rilevazione non e esattamente continua, ma a frequenza sufficiente-

mente alta rispetto al processo monitorato, tale da rendere significative

e tempestive le eventuali correzioni al processo stesso (ad esempio le

centraline che raccolgono i valori di gas come l’anidride carbonica e

particelle sospese che raccolgono a cadenze regolari alcuni campioni);

- monitoraggio a medio-bassa frequenza: in questi casi le variabili in gioco


sono generalmente molto numerose, mentre le rilevazioni hanno una

cadenza che puo essere giornaliera, mensile, trimestrale. Il tempo tra

una rilevazione e l’altra e anche necessario a normalizzare, ordinare,

correlare, interpolare, rapportare i dati e convertirli in informazioni

fruibili e di semplice diffusione attraverso canali istituzionali o i media.

Questo monitoraggio e tipico, ad esempio, delle rilevazioni statistiche

continue, sul territorio, sull’ambiente, sulla popolazione, sul mercato.

E necessario anche decidere se fare:

- monitoraggio off-line: effettuato a intervalli di tempo regolari per ana-

lizzare i log. I tool che effettuano questo tipo di monitoraggio sono

utili per isolare eventi per ulteriori analisi e per effettuare statistiche.

Tuttavia, tali tool non permettono di reagire automaticamente ed i-

stantaneamente ai problemi;

- monitoraggio on-line: effettuato ininterrottamente analizzando uno o

piu file di log o ricevendo input da qualche altro programma.

Inoltre e doveroso considerare aspetti come la portabilita del tool, la facilita

con cui e possibile definire le regole, la semplicita di apprendimento di tale

strumento, la flessibilita nel gestire differenti problemi la quale dipende dalla

sua capacita di osservare il problema [46]. Nella tabella 2.1 sono riportati i

principali vantaggi e svantaggi dei tool analizzati.

Per i vantaggi offerti, come la facilita nel definire regole anche complesse,

la semplicita di apprendimento, il meccanismo di aggregazione degli even-

ti messo a disposizione, la portabilita, il linguaggio di facile sviluppo, una

completa ed esaustiva lista di azioni disponibili, la flessibilita e l’opportu-

nita di correlazione di eventi anche complessi, lo strumento che si e scelto


Tool Vantaggi Svantaggi

Mielog - Rappresentazione visiva - Non automatizzato.

delle informazioni;

- Individuazione degli errori

facile e rapida;

- Interazione diretta.

Logsurfer+ - Supporta il cambiamento - Sintassi molto difficile;

dinamico delle regole; - Difficolta nell’ottenere

- Flessibile. correlazioni complesse;

- Debugging difficoltoso;

Swatch - Eliminazione di eventi - Non supporta la correlazione

ridondanti; tra eventi;

- Modifica delle regole - Non supporta l’attivazione/

in base ai tempi d’arrivo. disattivazione di regole in

base agli eventi.

LoGS - Dinamico, estendibile - Linguaggio di programmazione

efficiente e flessibile; complesso che richiede

- Permette di esprimere notevole esperienza.

regole molto complesse.

SEC - Supporta la correlazione - Si basa sul tempo d’arrivo degli

tra eventi complessi; eventi e non sul timestamp.

- Flessibile;

- Meccanismo di aggregazione

di eventi;

- Utilizza il Perl: linguaggio

noto e di rapido sviluppo.

Tabella 2.1: Tabella riassuntiva dei vantaggi e degli svantaggi dei tool.

per implementare le regole necessarie allo sviluppo del modello di diagnosi e

SEC.

Capitolo 3Uso degli strumenti automatici basati

sulle regole per fare diagnosi

Gli strumenti automatici basati sulle regole per l’osservazione degli eventi si

propongono anche come validi meccanismi per l’implementazione di euristi-

che, come α-count, o tecniche piu sofisticate, come il modello diagnosi presen-

tato in [16]. Infatti le informazioni necessarie per la definizione delle regole

sono esattamente le stesse utilizzate per la definizione delle varie metodologie

di diagnosi per cui ne segue che la proposta e sufficientemente generica da

porsi come possibile alternativa.

Si mostra adesso come, utilizzando uno strumento automatico basato

sulle regole, sia possibile per un progettista implementare in un sistema le

funzioni filtro quali α-count e il modello di diagnosi basato sulle catene di

Markov nascoste. Si supponga per semplicita di trattazione che il sistema

in questione sia costituito da un componente e da un sistema di rilevazione

degli errori e che il progettista conosca le specifiche di dependability che il

sistema dovra garantire.

51

52 CAPITOLO 3. STRUMENTI AUTOMATICI PER FARE DIAGNOSI

3.1 α-count implementato mediante regole

Gli strumenti automatici basati sulle regole usano un insieme di regole per

l’event correlation. Le regole sono della forma “IF condition THEN action”

dove condition usa gli eventi ricevuti e le informazioni sul sistema, mentre

action contiene le azioni che possono portare a cambiamenti di sistema o

all’utilizzo di parametri per la scelta della successiva regola.

Volendo implementare α-count con tali strumenti e necessario identificare

gli elementi base dell’euristica e trovare i corrispettivi nei tool:

- α-count assume la presenza di un sistema di rilevazione di errori che

fornisce il segnale 0 nel caso di componente sano, 1 altrimenti. Tali

segnali possono essere presi in input dallo strumento automatico basato

sulle regole;

- l’euristica costruisce un punteggio α in base al segnale ricevuto. Lo

stesso punteggio puo essere calcolato usufruendo delle azioni messe a

disposizione dagli strumenti. Infatti il valore di questo contatore puo

essere implementato mediante una variabile locale denominata rank.

Tale variabile sara incrementata di uno se il segnale in input e 1; men-

tre sara decrementata moltiplicando per il parametro K, se il segnale

in input e 0. Anche il parametro K e una variabile locale al tool e cor-

risponde al parametro interno di α-count. Eventualmente, a run-time,

lo strumento automatico basato sulle regole ha la possibilita di modifi-

care il valore di K in base al comportamento del sistema: si aumenta

K se si desidera accorciare i tempi necessari per identificare il guasto,

lo si decrementa nel caso contrario.

3.1. α-COUNT IMPLEMENTATO MEDIANTE REGOLE 53

IF input=1THEN rank=rank+1

IF input=0THEN rank=rank*K

- α-count definisce una soglia per discriminare se un componente e guasto

o meno. Anche con questi strumenti e possibile verificare se il punteggio

raggiunge una soglia thres prestabilita ed avvisare di tale situazione.

IF rank>=thresTHEN ’’Componente Guasta’’

Entrando nel dettaglio si riportano le regole SEC che implementano tale

euristica. L’euristica α-count fa delle assunzioni riguardo al tempo, ovvero

suppone che tutti gli eventi legati ai guasti si verifichino in istanti temporali

discreti e che due istanti successivi differiscano di una quantita di tempo

costante. Dunque si suppone che la fonte di informazione da cui legge SEC

soddisfa tale requisito.

Se viene rilevato un errore nel componente e quindi il sistema di rilevamento

di errori invia il segnale 1, la prima regola riconosce tale pattern e, tramite

l’azione eval, incrementa il contatore $count. Dopodiche informa, mediante

l’azione spawn, che esegue il semplice comando di shell echo, di tale aumento.

Se invece il sistema di rilevazione invia il segnale 0 e quindi non vi sono errori

nel componente, la seconda regola decrementa il contatore $count in base

al parametro K prestabilito. La terza ed ultima regola, ricevuta la notifica

dell’incremento del contatore, controlla se questo ha raggiunto la soglia thres

prestabilita ed informa dello stato del componente: componente OK se il

contatore e inferiore alla soglia, componente KO altrimenti.

α-count in SEC - Prima versione

#Se viene rilevato un errore nel componente#incrementa il contatore ed avvisa dell’aggiornamento#type=Singleptype=substrpattern=1desc=Rilevato errore nel componenteaction=eval %countPre ($count=%countPre+1; return $count;);\

spawn echo stepup

#Se non viene rilevato alcun errore nel componente#decrementa il contatore#type=Singleptype=substrpattern=0desc=Nessun errore nel componenteaction=eval %countPre ($count=%countPre*K; return $count;)

#Quando il contatore viene incrementato#controlla se la soglia e raggiunta#type=Singleptype=substrpattern=stepupdesc=Controlla se la soglia e raggiuntaaction=eval %err (if(%countPre>=thres)return KO;elsereturn OK;);\

write - componente %err

Sfruttando la capacita di SEC di poter eseguire un qualsiasi comando

di shell, e possibile semplificare ulteriormente le regole facendo in modo di

eseguire un mini-programma scritto in C. In particolare il mini-programma C,

denominato alphaC, presi in input il segnale emesso dal sistema di rilevazione

di errori e il valore del contatore aggiornato, incrementa o decrementa il

contatore count e controlla se quest’ultimo ha raggiunto la soglia thres

prestabilita stampando un messaggio: KO se la soglia e raggiunta, OK <count>

altrimenti. Questo messaggio sara preso in input da SEC. Questa potenzialita

offerta da SEC di poter eseguire comandi di shell, in particolare programmi,

e molto utile se si vuole cambiare implementazione di α-count, utilizzando

ad esempio la formulazione che prevede l’uso della variabile dec (vedi 2.1).

3.1. α-COUNT IMPLEMENTATO MEDIANTE REGOLE 55

α-count in SEC - Seconda Versione

#Rivece il segnale //Mini-programma alphaC#ed esegue alphaC #include <stdio.h># #include <stdlib.h>type=Singleptype=regexp main (int argc, char* argv[])pattern= ([0|1])$desc=$0 int val = atoi(argv[1]);action=spawn .\alphaC $1 %count double count = atof(argv[2]);

#Se il componente e sano if(val==1)#aggiorna il valore del contatore# count = count+1;type=Singleptype=regexp else if(val==0)pattern=OK (([0-9]+\.[0-9]*|[0-9]+))desc=Aggiorna il valore del contatore count = count*K;action=assign %count $1

#Se il componente e guasto if(count>=thres)#lo notifica# printf(’’KO’’);type=Single return;ptype=substrpattern=KO elsedesc=Componente guastoaction=write - COMPONENTE GUASTO printf(’’OK %f’’, count);

return;

Passando al file di configurazione di SEC si hanno tre regole. La pri-

ma regola, ricevuto il segnale dal sistema di rilevazione, lancia l’esecuzione

del programma alphaC mediante l’azione spawn, passando come argomenti

il segnale ricevuto $1 e il valore del contatore %count. La seconda regola, ri-

conosciuto il messaggio OK <count>, aggiorna il valore del contatore %count.

La terza ed ultima regola notifica che il componente e guasto nel caso in cui

riconosca il pattern KO.

Dando in input a SEC una sequenza di segnali d’errore e possibile vedere

come il risultato atteso coincida esattamente con il risultato ottenuto dal-

l’esecuzione delle regole impostate. Questo e un risultato ovvio dato che la

teoria dell’euristica α-count e stata esattamente implementata in SEC.


Figura 3.1: Analisi del comportamento di α-count implementata mediante

regole di SEC.

L’immagine 3.1 mostra l’aderenza dei valori teorici dell’euristica α-count

con quelli sperimentali ottenuti tramite l’applicazione delle regole SEC. Come

input e stata fornita una sequenza artificiale di segnale. Sull’asse delle ascisse

e riportato un valore numerico in corrispondenza delle segnalazioni relative

alla rilevazione di un errore. Il numero indica quante segnalazioni di assen-

za di errore (0) precedono l’errore in questione (1). Sull’asse delle ordinate

di sinistra vengono riportati i valori che assume il contatore α definito del-

l’euristica. Sull’asse delle ordinate di destra vengono invece riportati i valori

che assume la variabile rank definita nelle regole SEC. Come risulta evi-

dente, i due valori coincidono esattamente e cio e a dimostrazione del fatto

che le regole SEC create ricalcano alla perfezione il comportamento atteso

dall’euristica α-count. L’esecuzione e stata eseguita per tre valori differenti

di K: la curva azzurra corrisponde a K = 0, 99, la curva rossa corrisponde a

K = 0, 94 e la curva verde corrisponde a K = 0, 9.

3.2. MODELLO DI DIAGNOSI CON HMM MEDIANTE REGOLE 57

3.2 Modello di diagnosi basato sulle HMM

implementato mediante regole

Con le catene di Markov nascoste e possibile fare delle stime sulle probabilita

che un componente possa trovarsi in un determinato stato del modello basan-

dosi sulle osservazioni dei simboli emessi dal modello. In particolare, sulla

base della sezione 2.3.2 cio corrisponde a stimare la presenza di un guasto

in base ai messaggi di errori emessi dal sistema. Le informazioni necessarie

per stimare tale situazione nell’istante t sono costituite dall’osservazione di

un certo numero di simboli L fino a quell’istante e dalla situazione in cui

si trovava il sistema quando ha iniziato ad emettere la suddetta sequenza

di simboli. Si ha dunque bisogno della situazione iniziale del modello ~π(1)

e della sequenza di simboli emessi fino all’istante del quale si sta cercando

di fare la stima. In questo modo e possibile calcolare il vettore~f(t) i cui

componenti fk(t) rappresentano la probabilita che nell’istante t lo stato in

cui si trova il componente sia k e che la sequenza di simboli osservata fino

all’istante t sia esattamente quella emessa.

Come fatto per α-count, volendo implementare il modello di diagnosi

basato sulle HMM con gli strumenti automatici basati sulle regole, e ne-

cessario trovare una corrispondenza tra elementi base e funzionalita messe a

disposizione da tali tool. La maggior parte di questi strumenti offrono la pos-

sibilita di eseguire applicazioni esterne. Sfruttando questa opportunita per

eseguire i prodotti matrice-vettore richiesti dal modello di diagnosi basato

sulle HMM, e possibile implementare delle semplici regole che ricevono/ri-

conoscono il simbolo emesso dal componente e lanciano l’esecuzione dell’ap-

plicazione esterna, che prende in input tale osservazione, per aggiornare le

probabilita di stato.


IF simbEmesso=otTHEN CalcolaProbabilita ot

Entrando nei dettagli di SEC e possibile costruire una regola che prende in

input il simbolo emesso dal componente e, ad esempio esegue uno script Perl o

un mini-programma in C che effettua i prodotti matrice-vettore, aggiornando

il vettore delle probabilita.

Modello di diagnosi basato sulle HMM in SEC

type=singlecontinue=DontContptype=regexppattern= ([0|1])$desc=HMM $0action=shellcmd perl ./calcolaProdotto.pl $1

Nella regola SEC riportata si e supposto che i simboli emessi siano 0 oppure

1. La regola non fa altro che riconoscere tali simboli ed eseguire il comando

di shell che lancia l’esecuzione dello script Perl calcolaProdotto.pl il quale

effettua il calcolo matrice-vettore ed aggiorna il valore del vettore~f(t).

Per testare la regola SEC che implementa il modello di diagnosi basato

sulle HMM, definiamo la seguente catena di Markov nascosta che discrimina

tra guasti transienti e guasti permanenti:

- Insieme degli stati: Ω = OK, TR, PERM, INT, INT + TR in cui

- OK e lo stato in cui il componente non e affetto da alcun guasto;

- TR e lo stato in cui il componente e affetto soltanto da un guasto

transiente;

- PERM e lo stato in cui il componente e affetto soltanto da un

guasto permanente;

- INT e lo stato in cui il componente e affetto soltanto da un guasto

intermittente;


- INT + TR e lo stato in cui il componente e affetto contempo-

raneamente da un guasto transiente e da uno intermittente;

- Vettore delle probabilita di occupare gli stati nell’istante iniziale: si

suppone che all’inizio il componente sia sano, per cui la catena parte

dallo stato OK. Il vettore delle probabilita di occupare gli stati nell’i-

stante iniziale e pertanto ~π (1) = (1, 0, 0, 0, 0)T ;

- Matrice delle transizioni: la matrice delle transizioni A utilizzata nell’e-

sempio e presentata sotto forma di tabella per maggiore espressivita in

tabella 3.1. I valori qt, qp e qi rappresentano rispettivamente la probabi-

lita che un componente sia colpito da un guasto transiente, permanente

o intermittente.

OK TR PERM INT INT+TR

OK 1− qt − qp − qi − qtqi qt qp qi qiqt

TR 1− qt − qp − qi − qtqi qt qp qi qiqt

PERM 0 0 1 0 0

INT 0 0 qp 1− qp − qt qt

INT+TR 0 0 qp 1− qp − qt qt

Tabella 3.1: Tabella relativa alla matrice delle transizioni A.

- Insieme dei simboli: il sistema di rilevazione emette due tipi di segnali:

0 per segnalare l’assenza di errori, 1 per segnalare la presenza di errori.

Dunque Σ = 0, 1;

- Matrice delle emissioni: la matrice delle transizioni E e presentata

sotto forma di tabella per maggiore espressivita in tabella 3.2. Il valore

q rappresenta la probabilita che lo stato INT emetta un segnale di

errore.


0 1

OK 1 0

TR 0 1

PERM 0 1

INT 1− q q

INT+TR 0 1

Tabella 3.2: Tabella relativa alla matrice delle emissioni E.

Per semplificare la descrizione della catena di Markov si ricorre alla rappre-

sentazione grafica (figura 3.2) che rappresenta l’evolvere degli stati in cui puo

trovarsi il componente sotto esame.

Figura 3.2: Catena di Markov associata agli stati in cui puo trovarsi il

componente in esame.

Il sistema di rilevazione degli errori ha copertura c: tale valore rappresenta

la probabilita che la presenza o l’assenza di un errore vengano correttamente


rilevate. Cio implica che con probabilita 1− c il sistema non si accorge della

presenza di un errore (mancata rilevazione) e con la stessa probabilita segnala

la presenza di un errore inesistente (falsa rilevazione).

Il modello e stato realizzato utilizzando la matrice delle traduzioniG. Tale

matrice contiene i valori di probabilita che permettono di tradurre i simboli

ricevuti dal modello del componente nei simboli restituiti al modello della

discriminazione dei guasti. Ogni volta che il modello del componente emette

il simbolo σin ∈ Σ, il modello del sistema di rilevazione degli errori emette un

simbolo σout ∈ Σ scelto in base ai valori di probabilita riportati nella riga di

G associata a σin. Per maggiore leggibilita la matrice G e rappresentata sotto

forma di tabella in tabella 3.3. Volendo discriminare tra componente sana

0 1

0 c 1− c

1 1− c c

Tabella 3.3: Tabella relativa alla matrice delle traduzioni G.

(healthy) e componente guasta (faulty), e necessario partizionare l’insieme

degli stati Ω in due parti:

ΩHC = OK, TR associata alla situazione healthy;

ΩFC = PERM, INT, INT + TR associata alla situazione faulty;

Si supponga di inizializzare i parametri secondo i valori riportati in tabella

3.4

L’immagine 3.3 mostra che i valori teorici del modello di diagnosi basato

sulle catene di Markov nascoste sono gli stessi dei valori ottenuti utilizzando

le regole SEC realizzate. Come nel grafico 3.1, sull’asse delle ascisse e ri-

portato un valore numerico in corrispondenza delle segnalazioni relative alla

rilevazione di un errore. Il valore indica quante segnalazioni di assenza di


Parametro Valore

qt 1 · 10−5

qp 1 · 10−6

qi 1 · 10−6

q 0, 1

c 1− ·10−5

Tabella 3.4: Valori assegnati ai parametri interni.

errore precedono l’errore in questione. Sull’asse delle ordinate di sinistra vi

sono i valori di probabilita relativi alla giacenza del modello in uno degli

stati appartenenti alla partizione ΩFC calcolati come definito dal modello,

si chiami questa probabilita P (ΩFC)HMM . Sull’asse delle ordinate di destra

vi sono i valori di probabilita relativi alla giacenza del modello in uno degli

stati appartenenti alla partizione ΩFC calcolati pero mediante l’utilizzo delle

regole SEC, chiamiamo questa probabilita P (ΩFC)SEC . Anche in questo caso

risulta evidente che le regole SEC seguono alla perfezione il comportamento

del modello di diagnosi.

Figura 3.3: Analisi del comportamento del modello di diagnosi basato sulle

HMM implementato mediante regole di SEC.

Dando in input a SEC una sequenza di segnali d’errore si osserva che il


risultato ottenuto dall’esecuzione delle regole coincide esattamente con quello

atteso. Anche in questo caso, come lo e stato per α-count, il risultato e ovvio

poiche il modello di diagnosi basato sulle catene di Markov nascoste e stato

esattamente implementato con le regole SEC.

Capitolo 4Modello di diagnosi incentrato sugli

strumenti automatici basati sulle

regole

In questo capitolo si presenta un modello di diagnosi che fa uso degli strumen-

ti automatici basati sulle regole. Lo scenario in cui si immagina di utilizzare

tale modello prevede sistemi distribuiti, real-time ed embedded basati su

componenti COTS o legacy il cui utilizzo e fortemente cresciuto negli ultimi

anni incrementando l’esigenza di considerare nuovi obiettivi ed aspetti legati

alla progettazione. I componenti COTS e legacy rendono piu complesse le at-

tivita di valutazione ed incremento della dependability poiche vi e una scarsa

conoscenza ed un limitato controllo su di essi ed inoltre i malfunzionamenti

sul sistema non sono sempre riconducibili a guasti di singoli componenti, ma

piuttosto ad una interazione tra questi.

Fermo restando la necessita e l’importanza di testare i componenti, alcuni

guasti, come quelli derivanti dall’interazione tra diversi componenti COTS e

legacy, non sono rilevabili attraverso le attivita di testing classiche data la

65

66 CAPITOLO 4. DIAGNOSI CON STRUMENTI AUTOMATICI

loro natura dinamica e non riproducibile.

Diventa dunque inequivocabile la necessita di un sistema di diagnosi

capace di fornire una diagnosi nel piu breve tempo possibile e pertanto

on-line.

4.1 Architettura del modello di diagnosi

Un qualsiasi modello di diagnosi opera in base alle manifestazioni del si-

stema osservato. In questo modello di diagnosi si assumono come fonte di

informazione i file di log prodotti dal sistema da diagnosticare. Cosı facendo

il modello risulta adattabile a qualsiasi sistema e non invasivo.

Il modello di diagnosi proposto puo essere visto come un blocco che ac-

cetta ingresso le informazioni di sistema contenute nei file di log e fornisce in

uscita un insieme di ipotesi riguardo alla presenza di guasti, la tipologia ed

altre informazioni (figura 4.1).

Figura 4.1: Architettura del modello di diagnosi proposto.

Trovare guasti tra tutti gli eventi di routine risulta essere un arduo com-

4.1. ARCHITETTURA DEL MODELLO DI DIAGNOSI 67

pito a causa dell’eccessiva mole di tali eventi. I file di log, come gia detto,

sono una ricca fonte d’informazioni per individuare malfunzionamenti nei

sistemi. Questi pero non possono essere usati direttamente dai vari metodi,

poiche contengono troppe informazioni, ridondanti e spesso non strutturate

per l’analisi dei dati. Nasce quindi l’esigenza di estrarre intelligentemente

le informazioni utili dai file di log ed effettuare una pre-processazione degli

eventi.

La pre-processazione dei file di log (log pre-processing) e un processo attuato

prima di applicare un qualsiasi metodo di monitoraggio. L’implementazione

di tale attivita e di fondamentale importanza per migliorare la diagnosi. Il

log pre-processing, oltre a filtrare e formalizzare i dati, estrae gli eventi neces-

sari per fare fault forecasting. Le principali tecniche esistenti si concentrano

soprattutto sul tasso di compressione (compression rate) dei dati da filtrare.

Per rimuovere gli event message ridondanti nei file di log sono comunemente

usati i metodi di filtraggio basati sullo spazio (spatial filtering) e sul tempo

(temporal filtering) [33]. Queste tecniche hanno un buon compression rate,

ma rischiano di rimuovere pattern importanti per il rilevamento di malfun-

zionamenti, come ad esempio dei lunghi stream di avvertimento che spesso

precedono un fallimento [39]. Inoltre lo spatial filtering potrebbe rimuovere

tracce di eventi che si verificano in locazioni diverse. Poiche lo spatial filtering

mantiene solo un evento, questo puo provenire da una locazione che e diversa

dalla sorgente di fallimento e cio potrebbe condurre ad un’analisi sbagliata.

Infine e bene considerare che un fallimento puo essere riportato da molteplici

sottosistemi caratterizzando vari aspetti del fallimento. Molto spesso questo

fatto viene ignorato e processare indipendentemente questi event message

potrebbe portare a risultati incorretti.


4.2 Il Modello di diagnosi

Il modello di diagnosi presentato fa uso degli strumenti automatici basati

sulle regole. Questi strumenti sono di facile applicazione, hanno trasparenza

nelle logiche che ne stanno alla base e sono in grado di fornire spiegazioni

sulla diagnosi effettuata poiche poggiano su relazioni causa-effetto.

La costruzione del modello di diagnosi proposto si compone di tre fasi

(figura 4.2):

1. Event Categorization: i vari eventi vengono classificati in un insieme

gerarchico di categorie di eventi. Principalmente vengono suddivisi in

eventi rilevanti ed eventi non rilevanti ai fini dell’identificazione dei

guasti.

2. Event Filtering: agli eventi vengono applicati dei filtri temporali e

spaziali per rimuovere le ridondanze, mantenendo comunque le infor-

mazioni principali.

3. Association Rule Mining: sulla base delle informazioni derivanti dalle

fasi precedenti e da un’accurata analisi del sistema si creano regole di

associazione tra i vari eventi.

4.2.1 Event categorization

Come precedentemente detto, e utile effettuare innanzitutto una classifi-

cazione degli eventi, che molto spesso viene fatta usando espressioni rego-

lari [33][34][20]. Analizzando la sintassi degli event message, le espressioni

regolari, estraggono le parole chiave dagli event message, le quali possono es-

sere utilizzate per creare la classificazione richiesta. Tale classificazione puo

4.2. IL MODELLO DI DIAGNOSI 69

Figura 4.2: Fasi dei creazione del modello di diagnosi proposto.

essere fatta inizialmente ad alto livello e successivamente raffinata in sotto-

categorie. Per fornire una migliore classificazione si distinguono gli eventi

in due categorie principali: rilevanti, indicanti gli eventi utili al rilevamento

di guasti che possono condurre ad un fallimento e non-rilevanti indicanti gli

avvisi, le informazioni di sistema e gli eventi di routine. Tra gli eventi rilevan-

ti rientrano, oltre agli eventi critici ed a particolari notifiche, anche i messaggi

relativi ai dati rilevati nel sistema. Infatti basandosi su queste informazioni

e possibile accorgersi se ci sono malfunzionamenti che non vengono messi in

mostra da espliciti avvisi.

Eventualmente e possibile, in base ai messaggi del sistema in analisi, creare

dei sottogruppi degli eventi ritenuti rilevanti (figura 4.3). Alcuni di questi

sottogruppi sono:

- Memory : eventi relativi alla memoria di tutti i componenti del sistema;

- Network : eventi relativi alla rete e quindi allo scambio di messaggi tra


i componenti del sistema;

- Service: eventi relativi al servizio offerto dal sistema e dai singoli

componenti;

- I/O : eventi relativi alle procedure e alle applicazioni di I/O;

- Altri : eventi che non rientrano nelle precedenti categorie ma sono

comunque ritenuti rilevanti.

Figura 4.3: Event Categorization.

Event categorization con gli strumenti automatici basati sulle re-

gole

Usando gli strumenti automatici basati sulle regole e possibile effettuare que-

sta classificazione creando dei context, uno per ogni categoria, ed inserendo

al loro interno i vari eventi ricevuti e riconosciuti mediante espressioni rego-

lari.

Supponiamo, per semplicita di trattazione, che gli eventi rilevanti siano i

messaggi contenenti la stringa error, mentre tutti gli altri sono da conside-

rarsi non rilevanti.

Come mostrato qui di seguito, se viene ricevuto un avviso di sistema che non

contiene la stringa error, tale evento viene classificato come non rilevante e

quindi aggiunto al context NON RILEV.


Classificazione eventi

IF messaggio=(!error)THEN add messaggio context NON RILEV

IF messaggio=errorTHEN add messaggio context RILEV

Se invece l’event message ricevuto indica un evento che puo condurre ad un

fallimento e, come ipotizzato, contiene la stringa error, allora viene classifi-

cato come rilevante ed aggiunto al context RILEV.

Entrando nei dettagli implementativi di SEC e possibile costruire le due

regole che permettono di classificare gli eventi in rilevanti e non rilevanti.

Classificazione eventi in SEC

type=Singleptype=regExppattern=(!error) (.*)desc=Evento non rilevanteaction= add NON RILEV $2

type=Singleptype=regExppattern=error (.*)desc=Evento rilevanteaction=add RILEV $1

Come precedentemente detto, questo e possibile farlo sfruttando i context.

Infatti nel momento in cui si riceve un messaggio che non soddisfa il pat-

tern specificato, questo viene memorizzato nella variabile $2 ed aggiunto al

context NON RILEV. Invece quando il messaggio ricevuto e un messaggio con-

siderato rilevante e contenente dunque la stringa error, viene memorizzato

nella variabile $1 e successivamente aggiunto al context RILEV.

4.2.2 Event filtering

La fase successiva di event filtering consente di filtrare le informazioni e

rimuovere gli eventi ridondanti cercando comunque di mantenere i dati im-


portanti, come il numero di occorrenze di un evento, il timestamp e la lo-

cazione. Un filtro ottimale non dovrebbe soltanto avere un alto compres-

sion rate, ma anche una bassa perdita di informazioni. Diviene dunque im-

portante capire quali event message sono ridondanti [33][34][20][40] e quali

informazioni devono essere mantenute. Generalmente ci sono due tipi di

ridondanza:

1. relativa al tempo: quando un sistema rileva un’anomalia invia avvisi

fintanto non si verifica un fallimento o l’anomalia cessa di esistere. Il

temporal filtering puo aiutare a rimuovere questa ridondanza eliminan-

do gli stessi tipi di eventi riportati dalla stessa locazione all’interno di

una finestra temporale.

2. relativa allo spazio: quando un’applicazione e eseguita in parallelo su

molteplici nodi, alcuni eventi di avviso o di fallimento possono es-

sere generati da molteplici locazioni. Lo spatial filtering puo aiutare a

rimuovere questa ridondanza eliminando gli eventi simili che vengono

riportati a differenti locazioni all’interno di una finestra temporale.

Riguardo a quali informazioni devono essere mantenute durante l’opera-

zione di filtraggio, i metodi esistenti dipendono principalmente da tecniche

ad hoc. Quando un evento viene continuamente riportato, alcun metodi di

filtraggio tipicamente conservano il primo record e rimuovono i successivi.

Ma questo meccanismo potrebbe eliminare informazioni cruciali per l’analisi

della causal correlation tra gli eventi. Il giusto compromesso tra mantenere

il piu possibile le informazioni importanti e filtrare con un buon compression

rate, sta nell’aggiungere all’event message in questione alcune informazioni

come il tempo d’arrivo della prima occorrenza dell’evento, il tempo d’arrivo

dell’ultima occorrenza dell’evento, il numero di occorrenze ricevute e le lo-

cazioni in cui si e verificato l’evento.

Come decidere la soglia ottimale (intesa come finestra temporale) per il

filtraggio e ancora una questione aperta. Alcune tecniche suggeriscono di

adottare un approccio iterativo [22][14] in cui inizialmente si imposta una

soglia molto bassa e gradualmente questa viene incrementata fintantoche

non vi sono cambiamenti insignificanti rispetto al compression rate.

Event filtering con gli strumenti automatici basati sulle regole

Con gli strumenti automatici basati sulle regole l’operazione di filtraggio risul-

ta piuttosto naturale. L’importante e riuscire a mantenere le informazioni

di cui si necessita. Per far questo si deve distinguere il verificarsi della pri-

ma occorrenza dell’evento in questione dalle successive e memorizzare il suo

timestamp. Quando eventualmente si presentano le successive occorrenze del

medesimo evento si ignorano, ma si memorizzano comunque le informazioni

relative al loro timestamp e alla locazione in cui l’evento si e verificato. In

questo modo, allo scadere della finestra temporale, e possibile fornire tutte

le informazioni richieste.

Quindi, come mostrato di seguito, la prima regola riconosce l’evento d’in-

teresse “<ts> componente <comp>: Errore” e controlla se questo e la prima

occorrenza (occ=0). In tal caso memorizza il suo timestamp <ts> nella va-

riabile timeStart, aggiorna il numero delle occorrenze occ ed aggiunge la

locazione <comp> al context LOCAZIONI. La seconda regola vale per le occor-

renze successive dell’evento (occ6=0) e simile alla prima, ma ogni volta che

l’evento e ricevuto il timestamp timeEnd viene sovrascritto per memorizzare

quello dell’ultima occorrenza. Infine la terza regola, quando la finestra tem-

porale timeout scade, notifica l’evento indicando le informazioni richieste

ovvero il timestamp della prima occorrenze timeStart, il timestamp dell’ul-

tima occorrenza timeEnd, il numero delle occorrenze occ ricevute all’inter-

no della finestra temporale e tutte le locazioni che hanno generato l’evento

memorizzate nel context LOCAZIONI.

Filtraggio eventi

IF (messaggio=<ts> componente <comp>: Errore)&&(occ=0)THEN timeStart=<ts>; occ=1; add <comp> context LOCAZIONI

IF (messaggio=<ts> componente <comp>: Errore)&&(occ 6=0)THEN timeEnd=<ts>; occ=occ+1; add <comp> context LOCAZIONI

IF timeout=0THEN notifica ’’timeStart timeEnd Errore occ LOCAZIONI’’

Sviluppando tali regole con SEC si ottiene quanto in seguito riportato. La

prima regola riconosce il pattern in questione e, se esiste il context PRIMA e

quindi e la prima occorrenza dell’evento:

- assegna alla variabile %timeStart il timestamp di tale evento che SEC

automaticamente memorizza in %t;

- elimina il context PRIMA poiche la prima occorrenza dell’evento si e gia

manifestata;

- crea di conseguenza il context SUCC per attivare la regola per il ri-

conoscimento delle occorenze successive dell’evento;

- inserisce nel context LOC, dopo averlo svuotato, la locazione della com-

ponente che ha generato l’evento memorizzata nella variabile $1;

- assegna alla variabile %occ, che contera le occorrenze dell’evento, il

valore 1.

La seconda regola, gestisce le successive occorrenze dell’evento d’interesse.

Se esiste il context SUCC la regola si occupa di:

- assegnare il timestamp dell’evento ricevuto alla variabili %timeEnd;


- aggiungere al context LOC la locazione della componente che ha generato

l’evento;

- aggiornare il numero delle occorrenze %occ.

Filtraggio eventi in SEC

type=Singleptype=regExppattern=componente ([0-9]+): Errorecontext=PRIMAdesc=Prima occorrenza dell’eventoaction=assign %timeStart %t; delete PRIMA;\

create SUCC; fill LOC $1; assign %occ 1

type=Singleptype=regExppattern=componente ([0-9]+): Errorecontext=SUCCdesc=Successive occorrenze dell’eventoaction=assign %timeEnd %t; add LOC $1;\eval %occ ($count=%occ+1; return $count)

type=Calendartime=* * * * *desc=Finestra temporale impostata ad ogni minutoaction=write - START TIME %timeStart\

END TIME %timeEnd OCCORRENZE %occ;\report LOC; delete SUCC; create PRIMA; create LOC

Infine la terza regola gestisce la finestra temporale, che in questo caso e

impostata ad un minuto. Ogni minuto questa regola scrive sullo standard

output un messaggio contenente il timestamp della prima e dell’ultima oc-

correnza dell’evento in questione, il numero di occorrenze ricevute in tale

finestra temporale e tutte le locazioni che hanno generato tale evento. Inol-

tre elimina il context SUCC e crea il context PRIMA per disattivare la seconda

regola ed attivare la prima.

4.2.3 Association rule mining

La fase di association rule mining e la fase piu delicata del modello di di-

agnosi poiche, sulla base delle informazioni derivanti dalle fasi precedenti


e da un’accurata analisi del sistema, si creano le regole d’associazione che

forniranno le ipotesi sui guasti.

Le regole d’associazione vengono dedotte dall’analisi effettuata sul sistema

studiandone sia il normale e corretto funzionamento sia i protocolli che vigono

su di esso. I messaggi che le varie entita di un sistema si scambiano sono una

ricca fonte d’informazione per capire cosa sta accadendo nel sistema. Questa

tanto fondamentale quanto delicata fase e affidata ad operatori che hanno

ampia conoscenza del sistema in questione.

Inoltre per raffinare il modello e trovare correlazioni tra i vari eventi e

possibile creare delle regole d’associazione applicando tecniche di association

rule mining. Questa tecnica e stata introdotta per la prima volta in [9]. Lo

scopo di queste tecniche e quello di estrarre interessanti correlazioni, pattern

frequenti o associazioni tra un insieme di items (in questo caso eventi) di un

database di transazioni (in questo caso file log).

L’association rule mining consiste nel trovare regole d’associazione che

soddisfano una soglia minima di supporto (minimum support) e di confidenza

(minimum confidence) di un dato database. AIS [9] e stato il primo algoritmo

proposto per l’association rule mining, ma presentando alcuni inconvenienti

come l’esigenza di compiere numerose scansioni dell’intero database, e stato

presto sostituito con altri algoritmi, primo fra tutti l’algoritmo Apriori.

L’algoritmo Apriori [10], il cui processo e piu efficiente, tuttavia ha due

svantaggi:

- il complesso processo di generazione di candidati, che utilizza la mag-

gior parte del tempi, dello spazio e della memoria;

- la scansione multipla del database.


Nei successivi anni sono stati proposti numerosi algoritmi e tecniche che

permettono di migliorare l’efficienza dell’associatin rule:

- riducendo il numero di scansioni del database (FP-Tree [21], TreePro-

jection [8]);

- campionando il database (Sampling [54], Progressive Sampling [41]);

- attraverso la parallelizzazione (FDM [15], DAA [36]);

- aggiungendo vincoli extra sulla struttura dei pattern (RARM [18]).

Tuttavia, l’uso di queste tecniche puo talvolta non essere sufficiente per

correlare tra loro gli eventi di un sistema. E compito dello sviluppatore del

modello di diagnosi dedurre da un’accurata analisi del sistema le varie corre-

lazioni tra gli eventi. L’analisi del sistema prevede lo studio approfondito dei

protocolli su cui il sistema pone le fondamenta ed un’attenta osservazione del

funzionamento del sistema, sia durante il normale e corretto funzionamento

che nel corso di eventi “particolari” o malfunzionamenti causati da guasti dei

componenti o interazioni fra questi.

Capitolo 5Generatore di LogFile per sistemi

SCADA basati su PROFIBUS

5.1 I sistemi SCADA

Il significato dell’acronimo SCADA, che sta per Supervisory Control And

Data Acquisition (acquisizione dati, supervisione e controllo), sintetizza le

tre funzioni fondamentali svolte da questo genere di sistema. In uno SCADA

l’acquisizione dati e funzionale allo svolgimento delle funzioni di supervisione,

osservazione dell’evoluzione del processo controllato e di controllo, attuazione

di azioni volte alla gestione degli stati nei quali in processo controllato si trova

e delle transizioni tra gli stati nei quali il processo puo venire a trovarsi.

Un largo uso di sistemi di supervisione e controllo e fatto nell’ambito

del controllo del traffico (aereo, ferroviario, automobilistico), della gestione

dei sistemi di trasporto dei fluidi (acquedotti, gasdotti, oleodotti,...), del-

la distribuzione dell’energia (reti di trasmissione dell’energia elettrica), del-

la gestione delle linee di produzione che realizzano i processi industriali,

del telerilevamento ambientale (studio di fenomeni fisici, chimici, geologici,

79

80 CAPITOLO 5. GENERATORE DI LOGFILE PER SISTEMI SCADA

biologici,...).

Come precedentemente detto, i sistemi SCADA svolgono tre funzioni

fondamentali:

- acquisizione dati. L’acquisizione dati e una funzione che nella maggior

parte dei casi ha un ruolo di supporto alle funzioni di supervisione e

controllo poiche mette in relazione il sistema con il processo control-

lato consentendo la conoscenza dello stato in cui si trova il processo e

l’azione di controllo esercitata per mezzo della variazione di parametri

caratteristici del processo. In questo senso “acquisizione dati” significa

scambio dati in entrambe le direzioni: dal processo verso il sistema e

viceversa. Generalmente in questa funzione e assente qualsiasi processo

decisionale;

- supervisione. La supervisione e la funzione per mezzo della quale un

sistema SCADA rende possibile l’osservazione dello stato e l’evoluzione

degli stati di un processo controllato. La visualizzazione delle infor-

mazioni relative allo stato attuale del processo, la gestione delle prece-

denti informazioni e degli stati anomali rispetto alla normale evoluzione

del processo controllato, rientrano fra i compiti della supervisione;

- Ccontrollo. La funzione di controllo rappresenta la capacita di un si-

stema di prendere decisioni relative all’evoluzione dello stato del pro-

cesso controllato in funzione dell’evoluzione del processo medesimo. La

modalita con la quale le procedure di controllo vengono realizzate nel-

l’ambito dell’intera architettura del sistema dipende fortemente dal tipo

di processo, essendo questo in grado imporre scelte architetturali sia

hardware che software. Le attivita di controllo sono concentrate nel

sistema di elaborazione.

5.1. I SISTEMI SCADA 81

Tipicamente i sistemi SCADA sono composti da:

- Sensori/Attuatori che misurano lo stato di specifici parametri del si-

stema e controllano il processo industriale;

- RTU (Remote Terminal Units) i quali convertono i segnali dei sen-

sori in dati digitali e li inviano alla Supervisory Station. Forniscono

informazioni sui dispositivi connessi (sensori e attuatori);

- Supervisory Station (chiamata anche Control Room o Operating Con-

trol Center OCC) nella quale vengono raccolti i dati ed inviati i comandi

che dovranno essere processati dagli attuatori;

- Infrastrutture di comunicazione.

La supervisione umana e eseguita da operatori che monitorano il compor-

tamento del sistema ed impartiscono compiti attraverso una Human-Machine

Interface (HMI), in cui lo stato del sistema e rappresentato graficamente, in

maniera intuitiva, solitamente mediante diagrammi interattivi.

I sistemi SCADA solitamente hanno, da un punto di vista logico, una

struttura gerarchica ad albero, i cui nodi prendono il nome di isole e sono

messe in comunicazione mediante una WAN che utilizza una connessione DSL

a internet o simile. Dipendentemente dal fatto che un’isola sia un nodo in-

terno o una foglia dell’albero, avremo una struttura diversa. Un’isola foglia,

che rappresenta anche il minimo sistema SCADA, e composta da sensori/at-

tuatori, RTU e supervisor. La connessione tra sensori/attuatori e RTU e in

fase di cambio tecnologico e prevede l’uso di COTS e legacy come Ethernet,

TCP/IP, wireless, ecc. Mentre la connessione tra RTU e supervisor avviene

su una LAN basata principalmente su Ethernet. La figura 5.1 mostra un

esempio di architettura di un sistema SCADA.

I flussi dei dati nei sistemi SCADA sono di due tipi:


- Informazioni e alert in upstream dai sensori ai supervisor mediante gli

RTU;

- Comandi in downstream dai supervisor agli RTU e dagli RTU agli

attuatori.

In aggiunta, il supervisor e gli RTU si scambiano anche messaggi neces-

sari per il controllo e la supervisione del sistema relativi al corretto funziona-

mento (messaggi di configurazione, di keep-alive e housekeeping data). Tale

scambio di messaggi puo essere utilizzato come fonte d’informazione per il

monitoraggio del sistema.

Figura 5.1: Esempio di architettura SCADA.

In particolare e possibile analizzare il sistema suddividendolo in tre livelli:

5.1. I SISTEMI SCADA 83

1. isola padre-isola figlio

Nella figura a lato l’isola A e padre dell’iso-

la B che a sua volta e padre delle isole C e

D. L’isola figlia invia informazioni all’isola

padre utilizzando, ad esempio, il protocollo

ICCP (Inter-control Center Communications

Protocol o IEC 60870-6/TASE.2).

2. supervisor-RTU

A questo livello le informazioni viaggiano

dall’RTU al supervisor mentre i coman-

di dal supervisor all’RTU utilizzando pro-

tocolli come il DNP3 o il MODBUS dai

quali e possibile attingere informazioni per

il monitoraggio.

3. sensore/attuatore-RTU

In questo livello gli RTU inviano i comandi

agli attuatori e ricevono le informazioni dai

sensori utilizzando, ad esempio, il protocollo

PROFIBUS.

Raccogliendo informazioni ad ogni livello e possibile dunque effettuare il

monitoraggio dell’intero sistema SCADA e procedere con la diagnosi per

capire la natura di eventuali guasti e semmai innescare, successivamente,

meccanismi di recovery/repair/reconfiguration.


5.2 PROFIBUS

Al livello sensore/attuatore-RTU, gli RTU inviano comandi agli attuatori e

ricevono informazioni dai sensori (figura 5.2).

Figura 5.2: Gli RTU inviano comandi agli attuatori e ricevono informazioni

dai sensori.

Un protocollo utilizzato spesso in questo livello dei sistemi SCADA e il

PROFIBUS (PROcess FIeld BUS) [4]. Ci sono tre varianti di PROFIBUS, la

piu utilizzata e sviluppata prevalentemente per estendere il campo applica-

tivo nell’ambito dei sensori/attuatori, e la PROFIBUS-DP (Decentralized

Peripherals). La principale caratteristica di PROFIBUS-DP e la velocita

nello scambio ciclico di dati tra un Master (RTU) e vari Slave (sensori/at-

tuatori).

Un sistema dove viene utilizzato PROFIBUS-DP e costituito da varie unita

di comunicazione suddivise logicamente in:

- DP-Master (class 1): in accordo con algoritmi ben definiti, il DP-

Master (class 1) controlla i vari DP-Slave. Scambia ciclicamente dati

ed informazioni diagnostiche con quest’ultimi e, attraverso le funzioni di

5.2. PROFIBUS 85

protocollo, esegue compiti di configurazione e parametrizzazione degli

Slave nella fase di avvio;

- DP-Master (class 2): oltre ai compiti del DP-Master (class 1) definisce

quali operazioni devono essere svolte in base al tipo di servizio richiesto;

- DP-Slave: colleziona informazioni in ingresso ed invia informazioni in

uscita al DP-Master che in precedenza lo ha configurato e parametriz-

zato.

La comunicazione puo essere uno-a-uno o uno-a-molti (multicast) tra DP-

Master e DP-Slave oppure tra DP-Master (class 2) e DP-Master (class 1).

La comunicazione Master-Slave e iniziata sempre da un Master, mentre quel-

la Master-Master e iniziata dal DP-Master (class 2). Non sono definite

comunicazioni tra DP-Master della stessa classe.

Esistono due tipi di sistema:

- Mono-Master : solo un DP-Master e attivo durante le normali operazio-

ni. In tali sistemi si hanno tempi scambio ciclico di messaggi piu brevi

e vengono percio utilizzati nei sistemi ad alte prestazioni o di controllo

semplici (figura 5.3);

Figura 5.3: Architettura mono-Master.


- Multi-Master : piu di un DP-Master e connesso al bus, ma tali Master

sono ognuno facente parte di un sottosistema indipendente costituito

da un DP-Master (class 1) e dagli DP-Slave ad esso associati. Inoltre

possono essere presenti DP-Master (class 2) per la configurazione e

la diagnostica. Rispetto ai sistemi Mono-Master questi sistemi hanno

tempi di scambio ciclico di messaggi piu lunghi (figura 5.4).

Figura 5.4: Architettura multi-Master.

Le funzioni messe a disposizione da PROFIBUS-DP sono riportate in

tabella 5.1.

Tra le varie funzioni messe a disposizione, vi sono due importanti funzioni

diagnostiche:

- Read DP-Slave diagnostic information: permette ad un’applica-

zione posta sul DP-Master di leggere le informazioni diagnostiche da

un DP-Slave;

- Read DP-Master diagnostic information: permette di leggere da

un DP-Master (class 1) le informazioni diagnostiche di un DP-Slave ad

esso associato.

5.2. PROFIBUS 87Fu

nzi

one

Nom

eD

escr

izio

ne

Mas

ter-

Dia

gnos

tic

read

DDLMGetMaster

Diag

Scam

bio

diin

form

azio

nidi

agno

stic

hesu

iD

P-S

lave

asso

ciat

itr

aD

P-M

aste

r.

Par

amet

erU

p-/

Dow

nlo

adDDLMDownload

DDLMUpload

Tra

sfer

imen

todi

unin

siem

edi

para

met

ritr

aD

P-M

aste

r.

Act

ivat

eb

us

par

amet

erDDLMActParaBrct

Att

iva

unin

siem

edi

para

met

risu

ibu

spr

eced

ente

men

teca

rica

ti.

Act

ivat

e/D

eact

ivat

eD

P-

Sla

ve

DDLMActParam

Forz

ail

polli

ngde

lD

P-S

lave

adar

rest

arsi

oa

rico

min

ciar

e.

DP

-Sla

ve-D

iagn

osti

c

info

rmat

ion

read

DDLMSlaveDiag

Leg

gele

info

rmaz

ioni

diag

nost

iche

diun

DP

-Sla

ve.

Dat

aex

chan

geDDLMDataExchange

Scam

bio

cicl

ico

dida

titr

aD

P-M

aste

r(c

lass

1)ed

iD

P-S

lave

asso

ciat

i.

Set

par

amet

ers

DDLMSetPrm

Impo

sta

ipa

ram

etri

del

DP

-Sla

veal

l’avv

iode

lsi

stem

ae

dopo

unre

star

t.

Ch

eck

con

figu

rati

onDDLMChkCfg

Con

trol

lode

llaco

nfigu

razi

one

diun

DP

-Sla

veda

part

edi

unD

P-M

aste

r.

Sen

dco

ntr

olco

mm

and

sDDLMGlobal

Control

Invi

odi

spec

iali

com

andi

dico

ntro

lloa

uno

(sin

gle)

oa

vari

(mul

tica

st)

DP

-

Slav

e.

Rea

dco

nfi

gura

tion

dat

aDDLMGetCfg

Ric

hies

taal

DP

-Mas

ter

della

confi

gura

zion

eda

part

edi

unD

P-S

lave

.

Rea

din

pu

tsan

dou

tpu

tsDDLMRDInp

DDLMRDOut

Abi

lita

tutt

iiD

P-M

aste

ra

legg

ere

glii

nput

egl

iout

put

diun

DP

-Sla

vem

entr

e

ques

toe

sott

oil

cont

rollo

diun

osp

ecifi

coM

aste

r.

Ch

ange

stat

ion

add

ress

DDLMSetSlave

Add

Dur

ante

l’ini

zial

izza

zion

e,co

nsen

tea

unD

P-M

aste

r(c

lass

2)di

cam

biar

e

l’ind

iriz

zodi

unD

P-S

lave

.

Tab

ella

5.1:

Funzi

oni

di

PR

OF

IBU

S-D

P.


Queste funzioni permettono una localizzazione dei guasti per mezzo di mes-

saggi. Il master puo decidere di svolgere la funzione di diagnostica in tre

differenti formati o livelli a seconda del dispositivo che svolge la funzione di

slave:

- Station o device related: messaggi concernenti lo stato generale del

dispositivo;

- Module o identifier related: messaggi indicanti errori in uno specifico

range di I/O;

- Channel related: messaggi indicanti errori in un singolo bit di I/O.

Device-related diagnostic

Queste informazioni riguardano lo stato globale del device e possono essere

codificate in qualunque forma descritta nelle specifiche di costruzione. Pos-

sono essere usate per indicare informazioni diagnostiche generali come il sur-

riscaldamento, il sottovoltaggio, il sovravoltaggio, ecc. La struttura di queste

informazioni e una struttura a blocchi, in cui vi e un’intestazione (header

byte), dove e indicata la lunghezza dell’intero blocco, ed ulteriori blocchi

contenenti le informazioni diagnosticate (field byte).

Device-Related Diagnostic - Header Byte

7 6 5 4 3 2 1 0

0 0 X X X X X X

Di default Lunghezza dell’intero blocco espressa in byte

Device-Related Diagnostic - Field Byte

7 6 5 4 3 2 1 0

X X X X X X X X

Codifica delle informazioni come definito nella specifica.

5.3. GENERATORE DI LOGFILE PROFIBUS 89

Identifier-related diagnostic

Questa struttura diagnostica e basata su un sistema modulare, dove ogni

modulo ha un identificatore. Cosı, un modulo guasto puo essere facilmente

rilevato senza bisogno di descrizioni aggiuntive. Anche qui vi e una struttura

a blocchi, con un’intestazione (header byte) dove vi e indicata la lunghez-

za dell’intero blocco e gli ulteriori blocchi contenenti un insieme di bit che

indicano l’identificatore del modulo diagnosticato (field byte).

Identifier-Related Diagnostic - Header Byte

7 6 5 4 3 2 1 0

0 1 X X X X X X

Di default Lunghezza dell’intero blocco espressa in byte

Identifier-Related Diagnostic - Field Byte

7 6 5 4 3 2 1 0

X X X X X X X X

Identificatore del modulo diagnosticato.

Channel-related diagnostic

In questo blocco sono poste in sequenza le informazioni diagnostiche ed in

particolare i tipi di errori che possono essere diagnosticati.

5.3 Generatore di LogFile per Sistemi SCADA

basati su PROFIBUS

Con lo scopo di simulare tracce di messaggi scambiati al livello sensore/attua-

tore-RTU di un sistema SCADA e testare il modello di diagnosi proposto, si e

creato un Generatore di LogFile per sistemi SCADA basati su PROFIBUS.


Channel-Related Diagnostic

7 6 5 4 3 2 1 0

X X X X X X X X

Channel Type: Error Type:

000 = Riservato 0 = Riservato

001 = Bit 1 = Cortocircuito

010 = 2 Bit 2 = Sottovoltaggio

011 = 4 Bit 3 = Sovravoltaggio

100 = Byte 4 = Overload

101 = Word 5 = Surriscaldamento

110 = 2 Word 6 = Line/wire interrotta

111 = Riservato 7 = Upper limit value exceeded

8 = Lower limit value exceeded

9 = Error

10..15 = Riservati

16..31 = Relativi alle specifiche del costruttore

Il compito di questo generatore e quello di creare un file di log generato

da un DP-Master durante la comunicazione con i suoi DP-Slave secondo il

protocollo PROFIBUS.

L’obiettivo del generatore e creare un file di log contenente tutti gli even-

ti inerenti al traffico di messaggi tra un DP-Master (RTU) ed i suoi DP-

Slave (sensori) associati posizionati in un sistema predefinito. Il generatore

sviluppato offre la possibilita all’utente di personalizzare l’intero sistema

che vuole analizzare, di generare eventi nell’ambiente e di fare fault injec-

tion sui DP-Slave per simulare il comportamento del protocollo in specifiche

circostanze.


5.3.1 Architettura del generatore

In fase di progettazione si e cercato di rendere il piu indipendente possibile

l’implementazione del sistema da quella del protocollo PROFIBUS in modo

tale da poter usufruire del generatore per simulare molteplici sistemi. Per

far questo sono state suddivise le entita coinvolte e per ognuna esse e stata

generata una classe che mette a disposizione le relative funzionalita.

Le principali classi implementate sono dunque:

- Master: classe che simula le tracce dei messaggi inviati da un DP-

Master ai suoi DP-Slave in base al protocollo PROFIBUS;

- Slave: classe che simula le tracce dei messaggi inviati da un DP-Slave

al DP-Master in risposta a quelli ricevuti da esso;

- Sistema: classe che simula il comportamento del sistema che si vuole

porre sotto analisi fornendo informazioni relative ai valori a cui si e

interessati.

5.3.2 Funzionamento del generatore

Il generatore sviluppato simula lo scambio di messaggi tra un DP-Master e i

suoi DP-Slave seguendo le specifiche del protocollo PROFIBUS e crea il file

di log generato dal DP-Master relativo a tale scambio di messaggi.

Come da protocollo, si hanno quattro fasi:

1. Fase iniziale: il DP-Master svolge le funzioni di parametrizzazione e

di configurazione dei DP-Slave inviandogli, rispettivamente, i messaggi

DDLM Set Prm e DDLM Chk Cfg.

2. Fase di scambio ciclico: il DP-Master richiede ai DP-Slave i dati che essi

rilevano ed informazioni relative alla diagnostica mediante i messaggi


DDLM Data Exchange e DDLM Slave Diag. Ogni DP-Slave risponde

al DP-Master fornendo le informazioni richieste. Questo scambio di

messaggi avviene ciclicamente.

3. Fase di invio dei comandi : in base alle informazioni ricevute e alle

proprie specifiche, il DP-Master invia (in broacast o in multicast) dei

comandi di controllo ai DP-Slave. Il messaggio inviato e DDLM Glo-

bal Control.

4. Fase di controllo della configurazione: in base alle proprie specifiche

i DP-Slave possono inviare al DP-Master il messaggio DDLM Get Cfg

per richiedere la propria configurazione.

I DP-Slave rispondono al messaggio ricevuto dal DP-Master, inviando o un

ack o le informazioni richieste. Se la richiesta non va a buon fine, l’invio

viene ripetuto fintanto non si raggiunge il buon esisto.

Prima di dare avvio alla fase iniziale, il generatore sviluppato chiede di

inserire dei parametri di input:

- il numero di DP-Slave che devono essere associati al DP-Master;

- il tasso con cui le richieste effettuate non vanno a buon fine e pertanto

devono essere ripetute;

- il massimo ritardo di trasmissione dei messaggi.

La schermata che ci si presenta all’avvio dell’applicazione e quella mostra-

ta in figura 5.5.

Dopodiche, impostati i parametri, istanziato il DP-Master e il numero di

DP-Slave inserito, viene avviata la simulazione.


>>Inserisci il numero di DP-Slave:

>>...

>>Il numero di DP-Slave inserito e’ ...

>>Inserisci il tasso di fallimento delle richieste (0-100):

>>...

>>Il tasso di fallimento delle richieste inserito e’ ...

>>Inserisci il massimo ritardo di trasmissione:

>>...

>>Il massimo ritardo di trasmissione inserito e’ ...

Figura 5.5: Schermata di avvio dell’applicazione.

Generare eventi nel sistema

Il generatore sviluppato offre la possibilita di originare, durante la sua e-

secuzione, eventi nel sistema sotto analisi. Questa funzionalita e di fonda-

mentale importanza per esaminare il comportamento dei DP-Slave in caso di

alterazioni nel sistema.

Nel corso della propria esecuzione, il generatore resta in attesa che l’u-

tente richieda la generazione di eventi nel sistema; tra l’altro questo e l’unico

modo per poter scatenare eventi, infatti, se non viene specificato dall’utente,

il generatore creato a regime normale svolge correttamente le sue funzionalita

e non altera in alcun modo lo stato del sistema. Quando si parla di regime

normale s’intende dire che tutti i parametri osservati nell’ambiente (es. tem-

peratura, pressione,...) sono all’interno dei rispettivi intervalli previsti.

Facendo fuoriuscire dai propri ranghi alcuni parametri del sistema, si cre-

ano dei “particolari eventi” nel sistema. Questi particolari eventi che si

vogliono scatenare nel sistema devono essere definiti nell’implementazione

della classe Sistema. Dopodiche saranno i DP-Slave, in base a cio che ri-

levano, a comportarsi di conseguenza e a fornire le giuste informazioni al

DP-Master.


Anche quando nel sistema si sta verificando un particolare evento, i DP-

Slave si comportano correttamente inviando al DP-Master le giuste infor-

mazioni.

La schermata che durante l’esecuzione dell’applicazione offre la possibilita

di generare eventi nel sistema e quella mostrata in figura 5.6. Una volta che

si e scelto di generare un evento nel sistema, digitando A, viene chiesto di

specificare il tipo di evento che si desidera originare (evento 1, evento 2,...,

evento n); questi eventi devono essere definiti ed implementati nella classe

rappresentante il sistema. Quando si desidera far cessare l’evento e tornare

a regime normale e sufficiente digitare N.

>>Digita A per generare un evento nell’ambiente

>>Digita F per compiere fault injection sui DP-Slave

>>Digita N per tornare a regime normale

>>A

>>Digita 1 per innescare l’evento 1

>>Digita 2 per innescare l’evento 2

.....

>>Digita n per innescare l’evento n

>>...

Figura 5.6: Schermata di generazione degli eventi nel sistema.

Dunque e l’utente che determina l’inizio (generando l’evento) e la fine

(tornando a regime normale) di un particolare evento. E possibile gestire

anche piu eventi concorrentemente, sempre che questi non siano in contrasto

tra loro, altrimenti il secondo evento generato ha il sopravvento. Ad esempio,

se inizialmente si provoca un aumento della temperatura (oltre i limiti del

regime normale) e successivamente una diminuzione di questa (sotto i limiti

del regime normale), i due eventi non sono gestibili concorrentemente poiche

l’uno esclude l’altro. In questo caso il secondo evento ha la meglio e quindi,


diminuendo la temperatura, fa terminare il primo evento. Se invece di far

scendere la temperatura sotto il limite previsto, viene generato un evento che

non altera la temperatura, come ad esempio un problema alla connessione

tra DP-Master e DP-Slave, questi due eventi sono gestibili concorrentemente

poiche l’uno non esclude l’altro. Pertanto la temperatura del sistema restera

comunque al di sopra del limite massimo ed inoltre si avranno nel sistema

problemi di comunicazione tra le entita coinvolte. Quindi i DP-Slave che

eventualmente riusciranno a comunicare con il DP-Master, trasmetteranno

l’elevato valore della temperatura.

Quando si decide di tornare a regime normale tutti gli eventi generati termi-

nano e i parametri di sistema assumono valori all’interno dei limiti prestabi-

liti.

Compiere fault injection

Tramite fault injection e possibile fare in modo che i DP-Slave presentino

malfunzionamenti. Il generatore fornisce la possibilita di iniettare guasti

nei DP-Slave alterandone il corretto funzionamento. Quest’opportunita e

disponibile in qualsiasi momento: sia quando il sistema e a regime normale,

sia quando e soggetto a particolari eventi.

Una volta comunicato al generatore l’intenzione di effettuare fault in-

jection, il generatore chiede di specificare il numero di DP-Slave in cui si

vuole iniettare un guasto e, per ognuno di questi, la tipologia di guasto.

Oltre che sulle informazioni diagnostiche fornite al DP-Master, tale guasto,

si ripercuotera anche sui dati rilevati in base al tipo di malfunzionamento

iniettato.

I possibili stati che un DP-Slave in tale circostanza puo assumere, sono

quelli definiti dal protocollo PROFIBUS ovvero: cortocircuito, sottovoltag-


gio, sovravoltaggio, overload (eccessivo carico di lavoro), surriscaldamento

(del DP-Slave), line/wire interrotta, upper limit value exceeded (rilevamento

di dati al di sopra delle capacita del DP-Slave), lower limit value exceeded

(rilevamento di dati al di sotto delle capacita del DP-Slave) ed error (altri

errori non specificatamente definiti).

La schermata che durante l’esecuzione del programma mette a disposizione

la possibilita di compiere fault injection sui DP-Slave e mostrata in figura

5.7.

>>Digita A per generare un evento nell’ambiente

>>Digita F per compiere fault injection sui DP-Slave

>>Digita N per tornare a regime normale

>>F

>>Quanti DP-Slave devono essere coinvolti?

>>m

>>DP-Slave 1:

>>Digita 1 per cortocircuito

>>Digita 2 per sottovoltaggio

.....

>>Digita 9 per altri errori

>>...

>>DP-Slave 2:

.....

.....

>>DP-Slave m:

.....

>>...

Figura 5.7: Schermata per effettuare fault injection.

Digitando F si permette all’utente di fare fault injection chiedendogli di

specificare il numero di DP-Slave che si vuole coinvolgere e per ognuno di

essi che tipo d’informazione allegare al messaggio di diagnostica da inviare al

DP-Master. La scelta effettuata avra ripercussioni anche sui dati rilevati dal

DP-Slave, in quanto un DP-Slave colpito da malfunzionamenti puo o rilevare

comunque i dati corretti, o rilevarli sbagliati o non rilevarli affatto.

Digitando N, si torna ad un corretto funzionamento dell’intero siste-

ma, ovvero il sistema tornera a regime normale e i DP-Slave malfunzionanti

torneranno tutti ad essere fault free.

Output dell’applicazione

L’output del generatore e un file di log chiamato Logfile generato dal DP-

Master. Gli eventi registrati nel file di log sono di due tipi a seconda che si

tratti di una richiesta del DP-Master stesso o di una risposta ricevuta da uno

dei suoi DP-Slave.

La forma dell’evento relativo ad una richiesta e la seguente:

Source:DP-Master - Destination:< dps >-< date >Req< fun >

La destinazione < dps > indica il DP-Slave al quale viene inoltrata la ri-

chiesta < fun >. La data < date > rappresenta il timestamp relativo al

momento in cui il DP-Master ha inviato la richiesta al DP-Slave.

La forma dell’evento relativo ad una risposta del DP-Slave e invece la seguente:

Source:< dps >- Destination:DP-Master -< date >Res< fun >< ret > [data]

Il mittente < dps > indica il DP-Slave che ha inviato la risposta < ret >

[data] ad una richiesta < fun > precedentemente fatta. La data < date >

in questo caso non e relativa al momento in cui e stata inviato il messaggio

dal DP-Slave, ma al momento in cui il DP-Master l’ha ricevuto.

La tabella 5.2 mostra per ogni funzione richiesta le possibili risposte. La

funzione si considera andata a buon fine solo se la risposta e OK, altrimenti

l’applicazione, come da protocollo, continua ad inviare la richiesta. Allegati

alla risposta di richiesta dati, DDLM Data Exchange, se questa e positiva, vi

sono i dati rilevati dal DP-Slave; mentre in allegato alla risposta positiva

di richiesta d’informazioni diagnostiche, DDLM Slave Diag, vi e lo stato di

salute del relativo DP-Slave.

Funzione Richiesta Risposta Descrizione Risposta

DDLM Set Prm, OK ack positivo.

DDLM Chk Cfg, DS disconnesso dalla linea.

DDLM Get Cfg NA nessuna reazione dalla stazione remota.

DDLM Data Exchange OK <data> ack positivo con allegati i dati rilevati.

DS disconnesso dalla linea.

NA nessuna reazione dalla stazione remota.

DDLM Slave Diag OK <data> ack positivo con allegato lo stato del DP-Slave.


NA nessuna reazione dalla stazione remota.

DDLM Global Control OK ack positivo.


Tabella 5.2: Funzioni richieste con relative risposte e descrizione.

Una funzione richiesta dal DP-Master puo non andare a buon fine (con il

tasso di fallimento inserito all’avvio dell’applicazione dall’utente) perche vi e

una perdita della connessione con i DP-Slave. Questa e una perdita transiente

dovuta, ad esempio, al fatto che i DP-Slave se wireless possono muoversi

nell’ambiente oppure a mancanza di segnale per qualche interferenza.

La figura 5.8 mostra un esempio del Logfile ottenuto dall’esecuzione del-

l’applicazione. In questo caso e stato istanziato un sistema SCADA con tre

DP-Slave. E possibile osservare che la richiesta di parametrizzazione del

DP-Slave 2 non va a buon fine, infatti la sua risposta e Res DDLM Data Ex-

change DS, ovvero e momentaneamente disconnesso dalla linea; pertanto


il DP-Master gli invia una nuova richiesta di parametrizzazione al quale il

DP-Slave risponde positivamente.

Source:DP-Master - Destination:DP-Slave 1 - Thu May 21 16:57:07 CEST 2009 Req DDLM Set Prm



Source:DP-Slave 1 - Destination:DP-Master - Thu May 21 16:57:10 CEST 2009 Res DDLM Set Prm OK

Source:DP-Master - Destination:DP-Slave 1 - Thu May 21 16:57:11 CEST 2009 Req DDLM Chk Cfg



Source:DP-Slave 2 - Destination:DP-Master - Thu May 21 16:57:13 CEST 2009 Res DDLM Set Prm DS


Source:DP-Slave 3 - Destination:DP-Master - Thu May 21 16:57:14 CEST 2009 Res DDLM Chk Cfg OK

Source:DP-Master - Destination:DP-Slave 3 - Thu May 21 16:57:16 CEST 2009 Req DDLM Data Exchange

Source:DP-Slave 1 - Destination:DP-Master - Thu May 21 16:57:16 CEST 2009 Res DDLM Chk Cfg OK

Source:DP-Master - Destination:DP-Slave 1 - Thu May 21 16:57:16 CEST 2009 Req DDLM Data Exchange



.........................

Figura 5.8: Esempio di Logfile fornito in output dal generatore sviluppato.

100CAPITOLO 5. GENERATORE DI LOGFILE PER SISTEMI SCADA

Capitolo 6Caso di studio

Nei sistemi SCADA il protocollo PROFIBUS e impiegato per lo scambio di

messaggi tra RTU e sensori/attuatori. In [3] e possibile trovare alcuni casi di

reale impiego del protocollo PROFIBUS nei sistemi SCADA. Si osserva come

tale protocollo e utilizzato nelle situazioni piu disparate come nelle stazioni

petrolifere, nei processi industriali, nella fornitura di servizi energetici, nel

rilevamento di fenomeni ambientali, ecc.

Gli RTU svolgono le funzioni dei DP-MASTER, mentre i sensori/attua-

tori quella dei DP-Slave. Infatti gli RTU inviano i comandi agli attuatori e

ricevono informazioni dai sensori (figura 6.1).

I sensori/attuatori possono essere impiegati sul terreno, in aria, nei ve-

icoli, sotto l’acqua, all’interno di edifici, ecc. Ogni sensore/attuatore e dotato

di un’unita di rilevamento che serve per catturare gli eventi d’interesse, e di

un trasmettitore che viene utilizzato per spedire informazioni sugli eventi

catturati all’RTU.

Questi sensori/attuatori ovviamente sono inclini al fallimento a causa di

guasti hardware, errori di collegamento, attacchi, esaurimento di energia,

ostilita ambientali dovute a fattori fisici, chimici e biologici, ecc.

101

102 CAPITOLO 6. CASO DI STUDIO

Figura 6.1: PROFIBUS-DP nei sistemi SCADA.

Con lo scopo di validare il modello di diagnosi proposto incentrato su-

gli strumenti automatici per l’osservazione degli eventi basati sulle regole, si

sviluppa un caso di studio inerente ad un sistema SCADA che utilizza il pro-

tocollo PROFIBUS. Lo scambio di messaggi tra DP-Master e DP-Slave viene

simulato mediante il file di log prodotto dal generatore di logfile sviluppato.

6.1 Analisi del sistema

Il sistema consiste in un RTU (DP-Master class 1) e in N sensori (DP-Slave).

Questi sensori possono essere wireless o alimentati da corrente elettrica, ma

comunque sia omogenei per prestazioni e funzionalita. I sensori, se wireless,

sono liberi di muoversi e sono posizionati in un dato ambiente del quale

siamo interessati a rilevarne la temperatura atmosferica. Si e a conoscenza

del fatto che a regime normale tale ambiente si trovi in uno stato denominato

HEALTHY e la temperatura oscilli tra [tmin, tmax]. I sensori sono in grado di

rilevare temperature che variano nell’intervallo [tinf , tsup]. Come facilmente

deducibile tinf < tmin < tmax < tsup (figura 6.2).

6.1. ANALISI DEL SISTEMA 103

Figura 6.2: Schema delle temperature coinvolte nel sistema.

Gli eventi che possono verificarsi nel sistema e che si e scelto di im-

plementare riguardano l’aumento e la diminuzione della temperatura, la

variazione della fornitura di energia elettrica all’entita coinvolte ed altri

avvenimenti che non rientrano nei casi precedenti.

6.1.1 Aumento della temperatura

Con aumento della temperatura nel sistema s’intende che questa oltrepassi

il valore della soglia tmax. I sensori, se correttamente funzionanti, riportano

all’RTU il corrente valore della temperatura del sistema. L’aumento della

temperatura, oltre a ripercuotersi sul valore rilevato dal sensore, puo ma-

nifestarsi anche sullo stato diagnosticato del sensore stesso. In particolare

supponiamo che la temperatura del sistema venga fatta salire a T > tmax.

Ogni sensore, non guasto, rileva il valore della temperatura dell’ambiente t

in un intorno di T . Se T rientra nelle capacita del sensore, ovvero T ≤ tsup,

il valore rilevato t viene comunicato all’RTU; altrimenti se T > tsup e quindi

il sensore non e in grado di rilevare la temperatura il sensore avvisa l’RTU

del mancato rilevamento inviando t = NaN .

Per quanto riguarda lo stato funzionale del sensore, se la temperatura rilevata

eccede le sue capacita, il sensore lo comunica all’RTU tramite il messaggio

diagnostico, impostando il suo stato a UPPER LIMIT VALUE EXCEEDED. Se

l’aumento resta al di sotto delle capacita del sensore tmax < T ≤ tsup, ma e

comunque tale da far surriscaldare il sensore, quest’ultimo informera l’RTU

impostando il suo stato a SURRISCALDAMENTO, altrimenti lo stato del sensore

resta invariato.

La tabella 6.1 riassume tutte le possibili situazioni che si possono verificare

in caso di aumento della temperatura del sistema.

Temp. Sistema Temp. Comunicata Stato Sensore

tmax < T ≤ tsup t ' T HEALTHY

SURRISCALDAMENTO

T > tsup t = NaN UPPER LIMIT VALUE EXCEEDED

Tabella 6.1: Comportamento dei sensori dovuto all’aumento di temperatura.

6.1.2 Diminuzione della temperatura

Supponiamo che la temperatura del sistema venga diminuita a T < tmin.

Ogni sensore, se correttamente funzionante, rilevera una temperatura t in un

intorno di T . Se tinf ≤ T < tmin il sensore comunichera il valore t rilevato

all’RTU mantenendosi invariato il suo stato di diagnostica. Altrimenti se la

temperatura T scende al di sotto delle capacita minime del sensore tinf , cioe

T < tinf , il sensore non sara in grado di rilevare la temperatura e quindi

l’informazione ricevuta dall’RTU sara t = NaN e lo stato un cui verra a

trovarsi il sensore sara LOWER LIMIT VALUE EXCEEDED.


in caso di diminuzione della temperatura del sistema.


tinf ≤ T < tmin t ' T HEALTHY

T < tinf t = NaN LOWER LIMIT VALUE EXCEEDED

Tabella 6.2: Comportamento dei sensori dovuto alla diminuzione di

temperatura.


La figura 6.3 mostra le variazioni degli stati funzionali dei sensori in

base alle temperature assunte dal sistema, con un automa a stati finiti

non deterministico descritto per mezzo di un grafo. I nodi rappresentano

gli stati funzionali assunti dai sensori in caso di variazione della tempera-

tura ovvero HEALTHY, SURRISCALDAMENTO, UPPER LIMIT VALUE EXCEEDED e

LOWER LIMIT VALUE EXCEEDED, mentre le trasizioni indicano le variazioni di

temperatura del sistema. Si osservi come non sia possibile stabilire l’esatto

stato funzionale dei sensori in base al valore della temperatura del sistema, ad

esempio se la temperatura del sistema T appartiene all’intervallo [tmax, tsup]

il sensore puo comunicare all’RTU sia di trovarsi nello stato HEALTHY che in

uno stato di SURRISCADAMENTO.

Figura 6.3: Automa a stati finiti per gli stati funzionali del sensore.

6.1.3 Variazione della fornitura di energia elettrica

Quando si genera nel sistema un evento di variazione della fornitura di ener-

gia elettrica s’intende simulare un problema causato dal gestore di energia


e che riguarda o la scarsa o l’eccessiva fornitura di energia. In quest’ultimo

caso si considerano i sensori che sono alimentati da corrente elettrica e non

quelli wireless che dispongono di una propria batteria. Quando un sensore

constata una variazione dell’energia fornitagli lo comunica all’RTU tramite

il messaggio di diagnostica, impostando il suo stato a SOVRAVOLTAGGIO o

SOTTOVOLTAGGIO a seconda che si tratti rispettivamente di un’eccessiva o di

una scarsa fornitura di energia elettrica.

Quando si verifica uno di questi casi la temperatura t rilevata da un sensore

puo essere la temperatura effettiva del sistema T e quindi t ' T , puo non

essere corretta t T oppure un sensore puo non essere in grado di rilevare

alcuna temperatura t = NaN .


in caso di diminuzione della temperatura del sistema.


T t ' T ∨ t T ∨ t = NaN SOTTOVOLTAGGIO

T t ' T ∨ t = NaN SOVRAVOLTAGGIO

Tabella 6.3: Comportamento dei sensori dovuto alla variazione della fornitura

di energia.

6.1.4 Altri eventi

Con “altri eventi” s’intende calamita, naturali e non, che possono avvenire

nell’ambiente e che non rientrano nei casi precedenti. Quando viene generato

questo tipo di evento i sensori riportano all’RTU che si e in presenza di

uno stato non corretto specificando nel messaggio di diagnostica LINE/WIRE

INTERROTTA oppure ERROR. Com’e facile intuire, in questo caso, non viene

rilevata alcuna temperatura dai sensori, per cui t = NaN .



in questi casi.


T t = NaN LINE/WIRE INTERROTTA

ERROR

Tabella 6.4: Comportamento dei sensori dovuto ad altri eventi non rientranti

nei precedenti casi.

6.1.5 Guasti ai singoli sensori

Generando eventi nel sistema i sensori, se correttamente funzionanti, si com-

porteranno tutti nel medesimo modo. Pero, come gia detto, i sensori sono

inclini al fallimento a causa di guasti hardware, errori di collegamento, at-

tacchi, esaurimento di energia, ostilita ambientali, ecc. Quando un sensore

e sottoposto ad un malfunzionamento e possibile o che il sensore stesso si

accorga di tale circostanza e lo comunichi all’RTU attraverso il messaggio di

diagnostica, oppure non avverta tale malfunzionamento a livello diagnostico

e, pur essendo guasto, nello scambio di messaggi diagnostici con l’RTU non

emerge che il sensore e malfunzionante. Ovviamente oltre che sui messaggi

diagnostici, i malfunzionamenti avranno ripercussioni anche sui valori rilevati

dai sensori stessi.

La tabella 6.5 mostra tutti i possibili messaggi diagnostici che un sensore

puo inviare all’RTU con i corrispettivi valori di temperatura rilevati. Si os-

serva che in caso di cortocircuito, linea interrotta, superamento delle capacita

di rilevamento e generici errori non riconosciuti, il sensore non e in grado di

fornire un valore della temperatura e pertanto t = NaN . Il fatto che un

sensore sia soggetto a surriscaldamento non influisce sulle sue funzionalita di


rilevamento, percio t ' T . Quando un sensore e sovraccaricato (eccessivo

carico di lavoro) il rilevamento o meno della temperatura dipende dal mo-

mento in cui viene effettuata la richiesta e quindi t ' T se la richiesta viene

soddisfatta, t = NaN altrimenti.

Stato Sensore Comunicato Temp. Comunicata

CORTOCIRCUITO t = NaN

SOTTOVOLTAGGIO t ' T ∨ t T ∨ t = NaN

SOVRAVOLTAGGIO t ' T ∨ t = NaN

OVERLOAD t ' T ∨ t = NaN

SURRISCALDAMENTO t ' T

LINE/WIRE INTERROTTA t = NaN

UPPER LIMIT VALUE EXCEEDED t = NaN

LOWER LIMIT VALUE EXCEEDED t = NaN

ERROR t = NaN

HEALTHY t T

Tabella 6.5: Comportamento dei sensori in caso di malfunzionamento.

Se vi sono dei problemi di sottovoltaggio e quindi viene fornita una ten-

sione non sufficiente al sensore, il rilevamento dei dati e molto variabile, nel

senso che e possibile che il sensore rilevi comunque il corretto valore del-

la temperatura t ' T , ma anche che lo rilevi sbagliato t o non lo rilevi

affatto t = NaN . In caso di sovravoltaggio, se questo non e eccessivo da

compromettere le funzionalita del sensore, la temperatura viene rilevata cor-

rettamente t ' T , altrimenti t = NaN . Infine, se il sensore non riesce,

auto-diagnosticandosi, ad accorgersi di un suo malfunzionamento e possibile

che, pur comunicando all’RTU di essere in perfette condizioni, rilevi un valore

errato e dunque t T .

6.2. APPLICARE IL MODELLO DI DIAGNOSI 109

6.2 Applicare il modello di diagnosi

Si applica adesso sul sistema precedentemente analizzato il modello di dia-

gnosi incentrato sugli strumenti automatici basati sulle regole. Come fonte di

informazione si utilizza un file di log prodotto tramite il generatore di logfile

per sistemi SCADA basati su PROFIBUS.

Si procede adesso alla costruzione del modello di diagnosi proposto ana-

lizzando ognuna delle tre fasi delle quali si compone:

1. event categorization: suddivisione gerarchica degli eventi;

2. event filtering : filtraggio spaziale e temporale degli eventi;

3. association rule mining : creazione delle regole d’associazione tra eventi.

6.2.1 Event categorization

Nella fase di event categorization viene effettuata una classificazione gerar-

chica degli eventi. Nel sistema qui considerato la suddivisione effettuata e ad

alto livello e si limita a distinguere gli eventi rilevanti da quelli non rilevanti.

Inizialmente il protocollo PROFIBUS prevede uno scambio di messag-

gi tra RTU e sensori che permette la parametrizzazione (DDLM Set Prm) e

la configurazione (DDLM Chk Cfg) di quest’ultimi. Queste funzioni, poiche

vengono svolte solamente in fase iniziale e non forniscono significative infor-

mazioni, sono considerate non rilevanti.

Anche la funzione che richiede l’esecuzione di speciali comandi ai vari sensori

(DDLM Global Control), in broadcast o in multicast, con la relativa rispo-

sta, possono essere considerate non rilevanti perche tali comandi non sono

influenzati dal corretto, o meno, funzionamento del sistema.

Infine la funzione per la richiesta di configurazione da parte di un sensore


(DDLM Get Cfg) e la sua risposta da parte dell’RTU, possono essere ritenute

non rilevanti in quanto prive di salienti informazioni.

Le restanti funzioni che riguardano lo scambio di dati (DDLM Data Exchange)

e di informazioni diagnostiche (DDLM Slave Diag) sono invece da conside-

rarsi rilevanti. La tabella 6.6 riassume quanto finora detto.

Funzione Rilevante Non Rilevante

DDLM Set Prm %

DDLM Chk Cfg %

DDLM Global Control %

DDLM Get Cfg %

DDLM Data Exchange %

DDLM Slave Diag %

Tabella 6.6: Event categorization delle funzioni di PROFIBUS.

Usando gli strumenti automatici basati sulle regole si effettua questa clas-

sificazione creando per entrambe le categorie un context ed inserendo al loro

interno i vari eventi.

Event categorization

IF messaggio=(DDLM Set Prm |DDLM Chk Cfg |DDLM Global Control |DDLM Get Cfg)

THEN add messaggio context NON RILEV

IF messaggio=(DDLM Data Exchange |)DDLM Slave Diag |

THEN add messaggio context RILEV

La prima regola riconosce i messaggi di parametrizzazione, configurazione,

comandi speciali e richiesta di configurazione e, non essendo rilevanti, li

aggiunge al context NON RILEV. La seconda regola, riconosciuti i messag-


gi ritenuti rilevanti, ovvero di scambio dati ed informazioni diagnostiche, li

aggiunge al context RILEV.

Passando all’implementazione con SEC si ottengono le regole di seguito

riportate.

Event categorization con SEC - Eventi NON RILEVANTI

#Informazioni di parametrizzazione#non rilevanti.#type=Singleptype=RegExppattern=Source:(RTU|Sensore [0-9]+)-Destination:([0-9]+|RTU)-\

(\w+\s\w+\s\d+\s\d+:\d+:\d+\sCEST\s\d+)(Req|Res)\DDLM Set Prm ([OK|DS|NA]?)

desc=$0action=add NON RILEV $0

#Informazioni di configurazione#non rilevanti.#type=Singleptype=RegExppattern=Source:(RTU|Sensore [0-9]+)-Destination:([0-9]+|RTU)-\

(\w+\s\w+\s\d+\s\d+:\d+:\d+\sCEST\s\d+)(Req|Res)\DDLM Chk Cfg ([OK|DS|NA]?)


#Informazioni sui comandi speciali#non rilevanti.#type=Singleptype=RegExppattern=Source:(RTU|Sensore [0-9]+)-Destination:(Sensori [0-9]+|RTU|\

BROADCAST)-(\w+\s\w+\s\d+\s\d+:\d+:\d+\sCEST\s\d+)(Req|Res)\DDLM Global Control ([OK|DS|\w+]?)


#Informazioni di richiesta configurazione#non rilevanti.#type=Singleptype=RegExppattern=Source:(RTU|Sensore [0-9]+)-Destination:([0-9]+|RTU)-\

(\w+\s\w+\s\d+\s\d+:\d+:\d+\sCEST\s\d+)(Req|Res)\DDLM Get Cfg ([OK|DS|NA]?)


Per maggior chiarezza si e deciso di creare una regola per ogni funzione. Le

regole create riconoscono i messaggi che gli RTU e i sensori si scambiano in

base al protocollo PROFIBUS i quali sono della forma:

Source:RTU - Destination: < num > - < date > Req < fun >

Source:Sensore < num > - Destination:RTU - < date > Res < fun >< ret > [data]

dove < num > e il numero identificativo dei sensori, < date > e il timestamp

relativo all’evento in questione, < fun > e la funzione richiesta o della quale

si sta dando risposta, < ret > e, in caso di risposta, il valore di ritorno della

funzione con eventualmente delle informazioni allegate [data].

Event categorization con SEC - Eventi RILEVANTI

#Informazioni sullo scambio dati#rilevanti.#type=Singleptype=RegExppattern=Source:(RTU|Sensore [0-9]+)-Destination:([0-9]+|RTU)-\

(\w+\s\w+\s\d+\s\d+:\d+:\d+\sCEST\s\d+)\Res DDLM Data Exchange (-?[0-9]+.[0-9]+|NaN) ([OK|DS|NA]?)

desc=$0action=add RILEV $0

#Informazioni di diagnostica#rilevanti.#type=Singleptype=RegExppattern=Source:(RTU|Sensore [0-9]+)-Destination:([0-9]+|RTU)-\

(\w+\s\w+\s\d+\s\d+:\d+:\d+\sCEST\s\d+)\Res DDLM Slave Diag ([\w+|\s|\/]+)([OK|DS|NA]?)

desc=$0action=add RILEV $0

Se non si ritiene necessario memorizzare tutti gli eventi, soprattutto quelli

non rilevanti, e possibile ignorarli, sostituendo l’inserimento nel context con

nessuna azione, ovvero none o non implementando alcuna regola per tale

messaggio.

6.2.2 Event filtering

L’event filtering consente di filtrare le informazioni rimuovendo gli eventi da

considerarsi ridondanti, ma mantenendo comunque i dati importanti.


Si supponga che in questo caso di studio si ritenga opportuno analizza-

re soltanto i messaggi considerati rilevanti e di applicare a questi un filtro

sintattico. A questi messaggi si applica dunque un filtro temporale per elimi-

nare la ridondanza fra gli stessi tipi di eventi riportati dalla stessa locazione

(RTU o sensore) all’interno di una finestra temporale. Inoltre si applica un

filtro spaziale per rimuovere la ridondanza tra gli eventi simili che vengono

riportati da differenti locazioni (RTU o sensori) all’interno di una finestra

temporale.

Rispettando tali filtri, fra tutti i messaggi scambiati tra RTU e sensori

relativi allo scambio dati, interessa memorizzare il timestamp in cui l’RTU ha

ricevuto queste informazioni dal sensore, i sensori che hanno inviato il mes-

saggio e i rispettivi valori misurati da essi. Per cui di tutti i messaggi Res

DDLM Data Exchange che arrivano all’RTU all’interno di una data finestra

temporale, del tipo:

Source:Sensore num1 - Destination:RTU - data1 Res DDLM Data Exchange val1 OK



.........................

Source:Sensore numn - Destination:RTU - datan Res DDLM Data Exchange valn OK

si memorizzano il timestamp del primo e dell’ultimo evento verificatosi al-

l’interno della finestra temporale, il numero di occorrenze e i sensori da cui

proviene tale messaggio con i rispettivi valori.

In sostanza le informazioni che vengono estratte sono:

data1 num1 val1num2 val2num3 val3. . . . . .

datan numn valn

Totale occorrenze n

Anche per quanto riguarda i messaggi inerenti alla diagnostica, ovvero DDLM -

Slave Diag del tipo:

Source:Sensore num1 - Destination:RTU - data1 Res DDLM Slave Diag stato1 OK



.........................

Source:Sensore numm - Destination:RTU - datam Res DDLM Slave Diag statom OK

le informazioni da memorizzare sono le stesse, cioe timestamp della prima e

dell’ultima occorrenza, numero di occorrenze e sensori da cui proviene l’in-

formazione con il relativo stato:

data1 num1 stato1num2 stato2num3 stato3. . . . . .

datam numm valm

Totale occorrenze m

Usando gli strumenti automatici basati sulle regole si applicano questi

due filtri e si recuperano le informazioni di cui si e interessati. Le regole di

cui si necessita per svolgere queste operazioni sono mostrate di seguito.

Event categorization - Scambio dati

IF (messaggio=< data >Sensore< num >DDLM Data Exchange< val >)&&(occDE=0)

THEN timeStart=< data >; occDE=1; add < num >< val > VALORISENSORI

IF (messaggio=< data >Sensore< num >DDLM Data Exchange< val >)&&(occDE6=0)

THEN timeEnd=< data >; occDE=occDE+1; add < num >< val > VALORISENSORI

IF timeout=0THEN notifica ’’timeStart timeEnd DDLM Data Exchange

occDE VALORISENSORI’’

Come precedentemente detto si deve distinguere il verificarsi della prima

occorrenza dell’evento in questione dalle successive e memorizzarne il time-

stamp. Nell’arco di tempo restante della finestra temporale si memorizzano

solo i sensori di provenienza del messaggio e i valori contenuti nel messaggio.

Allo scadere della finestra temporale vengono fornite tutte le informazioni

pervenute, compreso il timestamp dell’ultimo messaggio ricevuto e il numero

di occorrenze.

Event categorization - Informazioni diagnostiche

IF (messaggio=< data >Sensore< num >DDLM Slave Diag< stato >)&&(occSD=0)

THEN timeStart=< data >; occSD=1; add < num >< stato > STATOSENSORI

IF (messaggio=< data >Sensore< num >DDLM Slave Diag< stato >)&&(occSD6=0)

THEN timeEnd=< data >; occSD=occSD+1; add < num >< stato > STATOSENSORI

IF timeout=0THEN notifica ’’timeStart timeEnd DDLM Slave Diag

occSD STATOSENSORI’’

Entrando nei dettagli implementativi di SEC le regole che si sono imple-

mentate, sia per lo scambio dati che per le informazioni diagnostiche, sono

riportate di seguito.

Filtraggio eventi in SEC - Scambio dati

type=Singleptype=RegExppattern=Source:Sensore([0-9]+)-Destination:RTU-\

(\w+\s\w+\s\d+\s\d+:\d+:\d+\sCEST\s\d+)\Res DDLM Data Exchange (-?[0-9]+.[0-9]+|NaN) OK

context=PRIMA DEdesc=Prima occorrenza dell’evento di scambio datiaction=assign %timeStartDE %t; delete PRIMA DE;\

create SUCC DE; fill VALORISENSORI $1-$3; assign %occDE 1


(\w+\s\w+\s\d+\s\d+:\d+:\d+\sCEST\s\d+)\Res DDLM Data Exchange (-?[0-9]+.[0-9]+|NaN) OK

context=SUCC DEdesc=Successive occorrenze dell’evento di scambio datiaction=assign %timeEndDE %t; add VALORISENSORI $1-$3;\

eval %occDE ($count=%occDE+1; return $count)

type=Calendartime=* * * * *desc=Finestra temporale impostata ad ogni minutoaction=write - START TIME %timeStartDE\

END TIME %timeEndDE OCCORRENZE %occDE;\report VALORISENSORI; delete SUCC DE;\create PRIMA DE; create VALORISENSORI


Filtraggio eventi in SEC - Informazioni diagnostiche


(\w+\s\w+\s\d+\s\d+:\d+:\d+\sCEST\s\d+)\Res DDLM Slave Diag ([\w+|\s|\/]+) OK

context=PRIMA SDdesc=Prima occorrenza dell’evento d’informazione diagnosticaaction=assign %timeStartSD %t; delete PRIMA SD;\

create SUCC SD; fill STATOSENSORI $1-$3; assign %occSD 1


(\w+\s\w+\s\d+\s\d+:\d+:\d+\sCEST\s\d+)\Res DDLM Slave Diag ([\w+|\s|\/]+) OK

context=SUCC SDdesc=Successive occorrenze dell’evento d’informazioni diagnosticheaction=assign %timeEndSD %t; add STATOSENSORI $1-$3;\

eval %occSD ($count=%occSD+1; return $count)

type=Calendartime=* * * * *desc=Finestra temporale impostata ad ogni minutoaction=write - START TIME %timeStartSD\

END TIME %timeEndSD OCCORRENZE %occSD;\report STATOSENSORI; delete SUCC SD;\create PRIMA SD; create STATOSENSORI

6.2.3 Association rule mining

La fase di association rule mining richiede di stipulare regole che, in base

alle informazioni raccolte nelle precedenti fasi, formulano ipotesi sui guasti

del sistema. Nel caso di studio l’RTU riceve le informazioni diagnostiche

da tutti i sensori associati e ha dunque la visione completa dell’intero livel-

lo sensore/attuatore-RTU. In questo modo l’RTU puo mettere insieme tutte

queste informazioni e capire se i problemi che si verificano sono relativi ai sin-

goli componenti, all’interazione di alcuni di questi o all’ambiente circostante.

Ad esempio, se un messaggio proveniente da un sensore indica surriscalda-

mento si puo pensare che questo sia dovuto alla rottura della ventola del

componente, oppure ad un virus che provoca il surriscaldamento della CPU

mediante overclocking oppure fermando la ventola di raffreddamento. Ma

se all’RTU arrivano piu messaggi, provenienti da piu sensori, che indicano


un surriscaldamento e piu facile pensare che il problema non sia dovuto ai

singoli sensori, ma ad esempio alla rottura dell’impianto di condizionamento

o ad un elevato innalzamento della temperatura dell’ambiente provocato, per

esempio, da un incendio.

Inoltre le misurazioni che i sensori effettuano sono tra loro spazialmente

correlate. Cio sta a significare che sensori vicini hanno probabilmente letture

simili. Poiche l’esaurimento di energia, ad esempio, e una causa di letture

errate da parte dei sensori, e possibile sfruttare le letture di tutti i sensori

per capire se vi e qualche sensore che sta effettuando misurazioni sbagliate e

dunque sta per esaurire la sua batteria o e comunque soggetto a un guasto.

L’algoritmo proposto per correlare spazialmente le misurazioni dei sen-

sori propone un metodo basato sull’osservazione che i guasti dei sensori sono

suscettibili ad essere stocasticamente incorrelati, mentre le misurazioni sono

probabilmente spazialmente correlate. In altre parole, sensori “vicini” de-

vono avere misurazioni simili.

In questo caso di studio si suppone che tutti i sensori del sistema siano tra

loro vicini e quindi il valore della temperatura da essi rilevato in uno stesso

intervallo di tempo deve essere simile.

Sia S = s1, s2, . . . , sn l’insieme dei sensori del sistema. L’RTU suddivide

il tempo in intervalli regolari Ik, con k = 1, 2, . . ., di dimensione ε. Nell’ar-

co di ogni intervallo Ik l’RTU puo ricevere al piu una misurazione da parte

di ciascun sensore. Sia valj,k l’eventuale misurazione del sensore j ricevuta

dall’RTU nell’intervallo k e sia V ALk l’insieme che contiene tutte e sole le

misurazioni ricevute in Ik.

Per ogni intervallo di tempo Ik, dopo aver ordinato i valori di V ALk in mo-

do crescente, si verifica che questi si differenzino, a due a due, al piu di un

valore prestabilito δ. Ovvero, dati due elementi vali,k e valh,k, adiacenti nel-

l’ordinamento, |vali,k − valh,k| < δ. I valori che non rispettano tale proprieta

non sono presi in considerazione. Con i valori restanti si calcola la media

aritmetica valk della temperatura nell’intervallo Ik. Dopodiche se il numero

di tali valori e strettamente maggiore di n/2 si accetta valk come misura di

riferimento del sistema nell’intervallo Ik. Altrimenti si confronta valk con

valk−1: solo se∣∣valk − valk−1

∣∣ < ∆ + δ si accetta valk, dove ∆ e un valore

prestabilito e rappresenta la massima variazione di temperatura che si puo

avere tra un intervallo e un altro.

Si consideri l’esempio riportato in figura 6.4 in cui si mostra il funziona-

mento dell’algoritmo applicato a un insieme di tre sensori S = s1, s2, s3. I

primi tre grafici a partire dall’alto mostrano le rilevazioni ricevute dall’RTU

da parte di ciascun sensore nei vari intervalli Ik. Si osservi che non neces-

sariamente l’RTU riceve le misurazioni di tutti i sensori in ogni intervallo.

Ad esempio, nell’intervallo I3 non riceve la misurazione dei sensori s1 e s3.

Il grafico piu in basso mostra l’andamento della temperatura che si suppone

abbia il sistema in base alla correlazione delle rilevazioni dei sensori. Allo

scadere di ogni intervallo si calcola il presunto valore di tale intervallo come

media aritmetica delle misurazioni ricevute che rispettano la condizione im-

posta dal parametro δ. Se il numero di valori utilizzati nel calcolo della media

e almeno due, si considera il valor medio ottenuto come temperatura del si-

stema dell’intervallo Ik (nell’esempio questo accade per gli intervalli I1, I2

e I4). Altrimenti si confronta la media ottenuta con quella del passo prece-

dente: se vi e una variazione inferiore a ∆ + δ, si accetta il valor medio come

temperatura del sistema relativamente a quell’intervallo (nell’esempio questo

accade nell’intervallo I5); in caso contrario non viene attribuito alcun valore

della temperatura per l’intervallo in questione (nell’esempio questo accade

per l’intervallo I3).

Figura 6.4: Esempio sul funzionamento dell’algoritmo per la correlazione

delle misurazioni.

Relativamente al caso di studio, da questo algoritmo, e possibile dedurre

informazioni sia sullo stato del sistema che sullo stato dei singoli sensori.

Stato del sistema. Allo scadere di ogni intervallo di tempo Ik l’algo-

ritmo comunica o il valore della temperatura del sistema valk oppure

che non e stato possibile rilevare una temperatura. Nel primo caso, oltre

a mettere a conoscenza l’utente di tale valore, lo si puo confrontare con

le varie soglie coinvolte nel sistema e dedurne che:

- se tinf ≤ valk < tmin la temperatura del sistema ha subito una

diminuzione ed e scesa al di sotto della soglia minima;

- se tmin ≤ valk ≤ tmax la temperatura del sistema risiede nell’in-

tervallo consentito e quindi il sistema e a regime normale;

- se tmax < valk ≤ tsup la temperatura del sistema ha subito un

aumento ed ha oltrepassato la soglia massima.

Invece se l’algoritmo non fornisce alcun valore della temperatura del

sistema, e utile esaminare lo stato dei sensori per scoprirne la causa.

Dall’analisi degli stati funzionali dei sensori si deduce se:

- la temperatura del sistema ha oltrepassato i limiti di capacita dei

sensori (superiormente o inferiormente);

- la connessione tra i sensori e l’RTU si e interrotta;

- il problema riguarda la fornitura di energia;

- il problema e riconducibile a cause sconosciute.

Stato dei singoli sensori. Se fra le misurazioni dell’insieme V ALk

ricevute dall’RTU nell’intervallo Ik, ve ne sono alcune che non rispet-

tano la condizione imposta da δ o corrispondono a NaN, al contrario

della maggioranza dei valori ricevuti, si analizza lo stato funzionale di

tali sensori. In questo modo e possibile riscontrare eventuali problemi

del sensore come l’esaurimento di energia, il surriscaldamento, un cor-

tocircuito, uno stato di overload, ecc.

Particolare attenzione va posta nel caso in cui la temperatura rilevata

da un sensore e ricevuta dall’RTU si discosta dalla maggioranza delle al-

tre misurazioni e lo stato funzionale di tale sensore ne indica comunque

un corretto funzionamento. Questo puo accadere per due motivi:

1. La temperatura dell’ambiente e variata all’interno dell’intervallo

temporale, per cui e possibile che il sensore abbia rilevato la tempe-

ratura dopo tale cambiamento, al contrario degli altri. La figura

6.5 mostra un esempio di tale situazione. L’algoritmo proposto


non accetta la rilevazione di s6 nell’intervallo Ik−1 per calcolare

valk−1 ed esaminandone lo stato funzionale, ovviamente non tro-

va alcun malfunzionamento. Nell’intervallo Ik la rilevazione del

sensore s6 viene accettata poiche conforme a quella degli altri.

Quindi il sensore s6 non e soggetto a guasti.

Figura 6.5: Esempio di variazione della temperatura all’interno di uno stesso

intervallo temporale.

2. Un sensore, col passare del tempo, puo “perdere di precisione”

pur mantenendosi in uno stato funzionale corretto. Quando que-

sta perdita di precisione fa discostare la misurazione del sensore

oltre la soglia d’incertezza δ consentita, il sensore deve essere

considerato malfunzionante.

Diviene dunque necessario impostare una soglia oltre la quale notificare

il malfunzionamento del sensore. Sia γ tale soglia, se un sensore non

rispetta il vincolo imposto da δ e quindi il suo valore non e accetta-

bile per γ volte consecutive, si notifica che tale sensore ha subito una

perdita di precisione nel rilevamento della temperatura e quindi e da

considerarsi malfunzionante. In alternativa, per stabilire se un sensore

e malfunzionante, si potrebbe usare l’euristica α-count.

Si mostra adesso come sia possibile, mediante gli strumenti automatici

basati sulle regole, svolgere questo tipo di correlazione.

Allo scadere di ogni intervallo Ik e necessario eseguire il Decision Scheme,

ovvero l’algoritmo proposto per la correlazione delle misurazioni. Questo al-

goritmo, come mostrato in figura 6.6, prende in input l’insieme delle misura-

zioni V ALk ricevute dall’RTU nell’intervallo Ik e il valore della temperatura

valk−1 stimato al passo precedente. Come output restituisce informazioni

relative alla temperatura dell’ambiente (Temperatura ambiente < T >,

Temperatura ambiente NON rilevata) ed eventualmente informazioni sui

sensori che, pur avendo inviato una misurazione all’RTU nell’intervallo Ik,

non hanno contribuito alla stima della temperatura (Dati sensore 

NON ACCETTATI, Dati sensore NON PERVENUTI).

Figura 6.6: Schema del DecisionScheme.

Conoscendo il valore stimato della temperatura < T > e possibile, tramite

l’algoritmo ControlThresholds, confrontarlo con le varie soglie imposte

dal sistema. Da questo confronto si stabilisce se la temperatura del si-

stema < T > si trova nell’intervallo [tinf , tmin) (Temperatura sotto la

soglia minima), nell’intervallo (tmax, tsup] (Temperatura sopra la soglia

massima) o nell’intervallo [tmin, tmax] (Temperatura a regime normale) (fi-

gura 6.7).

Se non viene fornita una stima del valore della temperatura e doveroso

scoprirne la causa. Questo e possibile farlo analizzando lo stato funzionale dei

Figura 6.7: Schema del ControlThresholds.

sensori mediante l’algoritmo SensorsStateAnalysis il quale informera se il

non rilevamento e dovuto alla temperatura che ha oltrepassato il limite supe-

riore o inferiore (Temperatura oltre il limite (superiore o inferio-

re)), ad un’interruzione della connessione fra RTU e sensori (Connessione

interrotta), ad un problema nella fornitura di energia elettrica (Problema

nella fornitura di energia) o ad una causa non ben definita (Causa

sconosciuta) (figura 6.8).

Figura 6.8: Schema del SensorsStateAnalysis.

Come precedentemente detto, il DecisionScheme eventualmente fornisce

informazioni sui sensori che non hanno contribuito alla stima della tempera-

tura o perche il valore riportato non era valido o perche, a differenza degli altri

sensori, non ha riportato alcun valore. In questo caso e necessario controllare

lo stato funzionale dei sensori indicati riferito dell’algoritmo SensorControl

(Stato sensore : < stato >) (figura 6.9).

Figura 6.9: Schema del SensorControl.

Le regole necessarie a svolgere questo tipo di compito sono le seguenti.

IF timeout=0THEN notifica DecisionScheme(V ALk, valk−1)

IF messaggio=Temperatura ambiente < T >THEN notifica ControlThresholds(< T >); valk−1=< T >

IF messaggio=Temperatura ambiente NON rilevataTHEN notifica SensorsStateAnalysis()

IF messaggio=Dati sensore NON (ACCETTATI|PERVENUTI)THEN notifica SensorControl()

IF messaggio=Stato sensore :HEALTHYTHEN count=count+1;

IF count=γTHEN notifica ’’Sensore malfunzionante’’

Con la prima regola, allo scadere della finestra temporale impostata, si

chiama l’esecuzione dell’algoritmo DecisioneScheme notificandone l’output.

Se viene riportata una temperatura dell’ambiente, la seconda regola la con-

fronta con le varie soglie e notifica il valore di ritorno dell’opportuno algo-

ritmo ControlThresholds. Se invece non e possibile stimare una tempera-

tura dell’ambiente, la terza regola informa del perche eseguendo l’algoritmo

SensorsStateAnalysis. Se la prima regola ha notificato che la lettura di

un sensore o non e valida (NON ACCETTATI) o, al contrario delle altre, non e

stata rilevata (NON PERVENUTI), la terza regola ne scova le cause eseguendo

l’algoritmo SensorControl. Puo comunque accadere, come precedentemente

detto, che lo stato funzionale di tale sensore sia corretto (HEALTHY). Allora e

necessario capire, aggiornando e confrontando la soglia γ se si tratta o meno

di una perdita di precisione del sensore e, in caso affermativo, notificarlo

(Sensore malfunzionante).

Capitolo 7Esperimenti

Al fine di testare il modello di diagnosi proposto si effettuano alcuni espe-

rimenti. Gli esperimenti sono stati svolti, mettendo in comunicazione il ge-

neratore di logfile per sistemi SCADA basati su PROFIBUS e le regole che

compongono il modello di diagnosi implementante con SEC. Il sistema creato

si compone di cinque sensori e un RTU e rispecchia le caratteristiche del

sistema per il rilevamento della temperatura precedentemente descritto.

Inizialmente si mostra il funzionamento dell’algoritmo e come sia possi-

bile, grazie a questo, ricostruire l’andamento della temperatura nel tempo.

Dopodiche si effettuano alcune prove, generando eventi di aumento e diminu-

zione della temperatura del sistema e di variazione della fornitura di energia,

al fine di dimostrare come le regole create, interagendo fra loro e correlando

i vari messaggi ricevuti dall’RTU, riconoscono e notificano la situazione glo-

bale del sistema. Infine si propongono alcuni esperimenti in cui viene fatta

fault injection nei sensori. In particolare si vuol mostrare l’importanza d’im-

postare la dimensione dell’intervallo temporale e della soglia per il giudizio

sul funzionamento di un sensore e come, anche in presenza di un particolare

evento nel sistema, e possibile diagnosticare problemi dei sensori.

125

126 CAPITOLO 7. ESPERIMENTI

7.1 Stima della temperatura

Per prima cosa si e cercato di ricostruire l’andamento della temperatura di

un arco di tempo suddiviso in intervalli Ik, con i = 1, 2, . . . , 19. Non e

stato fatto alcun tipo di fault injection sui sensori, ma sono stati generati

soltanto eventi ej, con j = 1, . . . , 5, di aumento e diminuzione della tem-

peratura del sistema. I primi cinque grafici a partire dall’alto della figura

7.1 mostrano rispettivamente i rilevamenti dei cinque sensori dell’insieme

S = s1, s2, s3, s4, s5. Il grafico piu in basso rappresenta invece l’anda-

mento della temperatura stimato attraverso l’algoritmo per la fusione delle

misurazioni.

Si osservi l’intervallo I5:

- le temperature pervenute sono tre e provengono dai sensori s1, s2 e s4;

- all’interno di tale intervallo e stato generato l’evento e1 che provoca un

aumento della temperatura del sistema;

- i sensori s1 e s2 rilevano la temperatura del sistema prima dell’evento

e1, al contrario del sensore s4;

- la temperatura rilevata da s4 non rispetta il vincolo imposto da δ poiche

val1,5 < val2,5 < val4,5, |val1,5 − val2,5| < δ ma |val2,5 − val4,5| > δ. Per

questo motivo la rilevazione di s4 viene scartata (nella figura si contrad-

distingue tale fatto marcando di un colore piu scuro la rilevazione di

s4);

- la stima della temperatura val5 nell’intervallo I5 viene calcolata me-

diante la media aritmetica delle misurazioni di s1 e s2;

- si confronta val5 con la stima della temperatura al passo precedente

7.1. STIMA DELLA TEMPERATURA 127

Figura 7.1: Stima della temperatura

val4 poiche il numero dei sensori impiegati nel calcolo della media e

inferiore alla meta del numero totale dei sensori;

- si accetta val5 come stima della temperatura dell’intervallo I5 poiche

rispetta il vincolo imposto da ∆, ovvero∣∣val4 − val5∣∣ < ∆ + δ.

Nell’intervallo I8 viene generato l’evento e2 il quale provoca una dimi-

nuzione della temperatura. Anche in questo caso accade che il sensore s1


rilevi la temperatura prima del verificarsi dell’evento e2, al contrario di tutti

gli altri sensori che rilevano la temperatura in tale intervallo. Sempre per

il vincolo imposto da δ, il valore val1,8 viene scartato, ma poiche i restanti

valori sono in maggioranza, non vi e la necessita di effettuare il confronto

con la stima della temperatura del passo precedente. Stessa cosa accade per

l’intervallo I15 in concomitanza dell’evento e5.

Puo accadere, come nel caso del sensore s1, che il verificarsi di due even-

ti ravvicinati, e3 ed e4, inducano a scartare le rilevazioni, se pur corrette,

del sensore e persino a considerare il sensore malfunzionante. E quindi di

fondamentale importanza per evitare una situazione del genere, impostare

un’adeguata dimensione ε della finestra temporale e un’opportuna soglia γ

per il giudizio sul corretto o meno funzionamento di un sensore.

7.2 Aumento lieve della temperatura

La figura 7.2 mostra il comportamento delle regole SEC sviluppate in caso di

lieve aumento della temperatura del sistema. Una prima esecuzione dell’al-

goritmo di DecisionScheme stima una temperatura dell’ambiente di 18.0875

gradi e pertanto il ControlThresholds informa che il sistema e a regime

normale.

Si genera l’evento aumentando lievemente la temperatura del sistema:

il sensore s1 rileva la temperatura prima dell’evento dunque il dato invia-

to all’RTU, non rispettando il vincolo imposto da δ, non viene accettato e

quindi:

- la stima della temperatura viene fatta sulla base delle rilevazioni effet-

tuate dai restanti sensori e valutata a regime normale dall’algoritmo

ControlThresholds;

7.2. AUMENTO LIEVE DELLA TEMPERATURA 129

- l’algoritmo di SensorControl verifica lo stato funzionale del sensore s1

che risulta essere HEALTHY.

Nell’intervallo successivo si puo notare che la temperatura rilevata dal

sensore s1 viene accettata poiche e conforme alle altre.

Figura 7.2: Aumento lieve della temperatura del sistema.

Il grafico di figura 7.3 mostra l’andamento della temperatura stimata in

base ai rilevamenti dei cinque sensori, evidenziando il momento in cui viene

generato l’evento. Si puo trovare conferma di quanto espresso dal modello di

diagnosi per quanto riguarda la rilevazione del sensore s1 nell’intervallo I2.

Figura 7.3: Rilevazioni dei sensori e stima della temperatura in relazione alla

figura 7.2.


7.3 Aumento e diminuzione intensi della tem-

peratura

Dopo aver stimato, in base alle rilevazioni dei sensori, una temperatura di

sistema a regime normale, si genera un evento il quale provoca un brusco

aumento della temperatura del sistema. L’algoritmo di ControlThresholds

si accorge che la temperatura stimata e superiore alla soglia imposta da tmax

e lo rende noto (figura 7.4).

Figura 7.4: Aumento intenso della temperatura del sistema.

Nel grafico di figura 7.5 e mostrato il momento in cui viene generato

l’evento che alza la temperatura dell’ambiente.


figura 7.4.

7.3. AUMENTO E DIMINUZIONE DELLA TEMPERATURA 131

Si osserva che tutte le rilevazioni dei sensori nell’intervallo I2 avvengono

dopo che l’evento e stato generato e pertanto contribuiscono tutte nella sti-

ma della temperatura val2. Si evidenzia inoltre il fatto che la temperatura

dell’ambiente supera la soglia massima, uscendo dalla temperatura a regime

normale contrassegnata dalla zona colorata.

Un ulteriore esperimento e stato fatto diminuendo la temperatura del

sistema.

Figura 7.6: Diminuzione intensa della temperatura.

Dopo aver stimato una temperatura a regime normale, si genera un evento

che provoca la diminuzione della temperatura al di sotto della soglia imposta

da tmin.


figura 7.6.


Infatti, come si osserva dalla figura 7.6, l’algoritmo di ControlThresholds,

in base alla temperatura stimata dall’algoritmo di DecisionScheme, notifi-

ca che la temperatura di sistema e scesa al di sotto della soglia minima

consentita.

Dal grafico di figura 7.7 si nota l’andamento della temperatura di sistema

nei vari intervalli e le rilevazioni dei sensori in base ai quali tale stima e stata

effettuata.

7.4 Aumento e diminuzione della temperatu-

ra oltre i limiti superiore ed inferiore

La figura 7.8 mostra un caso in cui la temperatura stimata inizialmente e

a regime normale, dopodiche viene generato un evento che la fa aumentare

eccessivamente, facendole oltrepassare la soglia tsup che rappresenta il limite

di capacita di rilevamento dei sensori impiegati nel sistema.

Figura 7.8: Aumento della temperatura oltre il limite superiore.

7.4. AUMENTO E DIMINUZIONE DELLA TEMPERATURA 133

Si osservi come, quando l’algoritmo di DecisionScheme indica che non

e stato possibile stimare alcun valore della temperatura, l’algoritmo di Sen-

sorsStateAnalysis notifichi lo stato del sistema, ovvero TEMPERATURA ol-

tre il LIMITE SUPERIORE.

Il grafico di figura 7.9 mostra l’aumento della temperatura nell’intero arco

temporale e le varie rilevazioni dei sensori. Si nota che nell’intervallo I4 non vi

e alcuna rilevazione poiche la temperatura ha oltrepassato il limite superiore.


figura 7.8.

La figura 7.10 mostra il caso in cui l’evento generato fa scendere la tempe-

ratura dell’ambiente al di sotto della soglia tinf , ovvero sotto il limite inferiore

di capacita di rilevamento dei sensori.

Figura 7.10: Diminuzione della temperatura oltre il limite inferiore.


7.5 Variazione nella fornitura di energia elet-

trica

La figura 7.11 mostra il comportamento del modello di diagnosi proposto

implementato con SEC quando viene generato un evento che fa variare la

fornitura di energia elettrica, in particolare quando si ha un sovravoltaggio.

Figura 7.11: Variazione nella fornitura di energia elettrica: sovravoltaggio.

Si osserva che nell’intervallo I2 i sensori s3, s4 e s5 rilevano la temperatura

dell’ambiente o prima che venga generato l’evento o comunque sia riescono

anche in caso di sovravoltaggio a rilevare un valore. Il sensore s2 invece rileva

la misura della temperatura sicuramente dopo che la creazione dell’evento e

non e in grado di fornirne una valore riportando all’RTU NaN. L’algoritmo di

DecisionScheme riesce, con i dati pervenuti a stimare la temperatura del-

l’ambiente, ma notifica che i dati del sensore s2 non sono pervenuti. Le regole

SEC riconoscono tale notifica ed eseguono l’algoritmo di SensorControl il

quale, analizzando lo stato funzionale del sensore in questione comunica che

il sensore s2 ha diagnosticato un sovravoltaggio. Per informare che l’intero

7.6. FAULT INJECTION: SOTTOVOLTAGGIO 135

sistema e soggetto a problemi di fornitura di energia elettrica si ha bisogno

di analizzare i dati pervenuti nell’intervallo I3. In tale intervallo i sensori

s1, s3 e s5 non sono in grado di rilevare una misura della temperatura e co-

municano all’RTU il valore NaN. Anche se il sensore s4 riesce a rilevare un

valore della temperatura dell’ambiente, questo non e accettabile, poiche la

maggioranza dei sensori ha informato l’RTU di non essere stato in grado di

rilevare una misurazione. Pertanto, l’algoritmo SensorControl analizza lo

stato funzionale del sensore s4 dichiarando che si trova in sovravoltaggio e

l’algoritmo SensorsStateAnalysis dichiara che l’intero sistema e soggetto

ad un problema di fornitura di energia elettrica.

7.6 Fault injection: sottovoltaggio

In questo esperimento si mantiene la temperatura di sistema a regime nor-

male non generando alcun evento. Si decide invece di effettuare fault injec-

tion provocando un sottovoltaggio nel sensore s1. Infatti si nota (figura 7.12)

come nell’intervallo I2, il sensore s1 riporti all’RTU una temperatura che non

viene accettata dall’algoritmo di DecisionScheme.

Come richiesto dal modello di diagnosi, l’algoritmo SensorControl ana-

lizza lo stato funzionale del sensore s1 trovandolo pero nello stato HEALTHY.

Questo avviene perche la fault injection e stata effettuata prima del rileva-

mento della temperatura da parte del sensore, ma dopo che questo ha inviato

l’ultimo messaggio diagnostico all’RTU, quello dell’intervallo I1. Nella figura

7.13 il grafico piu in basso rappresenta i cambiamenti di stato del sensore s1

percepiti dall’RTU in base ai messaggi ricevuti. Il colore della barra indica

lo stato comunicato dal sensore s1, con un messaggio diagnostico, all’RTU;

il momento in cui l’RTU riceve il messaggio diagnostico da parte del sensore


Figura 7.12: Fault injection: sottovoltaggio.

ed aggiorna quindi lo stato funzionale di questo e segnalato da una linea

verticale sulla barra. Quindi non vi e la possibilita in questo intervallo di

accorgersi che il sensore s1 e in stato di sottovoltaggio.

Figura 7.13: Stima della temperatura e rilevazioni del sensore s1 con

cambiamento di stato funzionale, relativo alla figura 7.12.

Questo non accade neppure nell’intervallo I3 poiche il sensore s1 non invia

7.6. FAULT INJECTION: SOTTOVOLTAGGIO 137

all’RTU nessuna temperatura. Solo nell’intervallo I4, dopo che il sensore s1

non essendo in grado di rilevare un valore della temperatura e comunicandolo

all’RTU (NaN) e dopo che il suo stato funzionale e stato analizzato, si e in

grado di affermare che il sensore s1 si trova in sottovoltaggio.

Questo esempio mostra come sia importante scegliere la dimensione ε

dell’intervallo temporale. La dimensione ε scelta e troppo piccola rispetto

al tempo di ricezione dei messaggi. In altre parole, la finestra temporale si

conclude prima che l’RTU abbia ricevuto sia i messaggi diagnostici che quelli

inerenti ai dati da parte di un sensore.

Figura 7.14: Fault injection: sottovoltaggio.

Si ripete adesso lo stesso esperimento aumentando la dimensione dell’in-

tervallo temporale. Come si osserva dalla figura 7.14 nell’intervallo I2 la tem-

peratura del sensore s1 non viene accettata dall’algoritmo di decisione poiche

discordante con le altre rilevazioni. Cosı, analizzando lo stato del sensore s1,

l’algoritmo SensorControl rileva immediatamente uno stato funzionale di

sottovoltaggio del sensore stesso.

Questo e possibile perche all’interno dell’intervallo I2 l’RTU riceve sia il


messaggio relativo ai dati misurati che allo stato diagnostico del sensore s1

(figura 7.15).



7.7 Diminuzione della temperatura e fault in-

jection: overload

Con questo esperimento s’intende mostrare la capacita del modello di dia-

gnosi proposto nello scovare malfunzionamenti dei sensori anche in caso di

eventi particolari che si verificano nel sistema. Come mostrato in figura 7.16

e stato generato un evento nell’intervallo I2 che provoca la diminuzione della

temperatura al di sotto della soglia imposta da tmin. Nonostante che i sensori

s1 e s2 rilevino la temperatura del sistema prima della creazione dell’evento e

la comunichino all’RTU in tale intervallo, il modello di diagnosi si accorge che

la temperatura e scesa al di sotto della soglia minima consentita ed analizza

inoltre lo stato funzionale dei due sensori i cui dati non sono stati accettati,

notificando giustamente che il loro stato di salute e buono.

7.7. FAULT INJECTION: OVERLOAD 139

Figura 7.16: Diminuzione della temperatura e fault injection: overload.



Successivamente e stata effettuata fault injection sul sensore s1 facendolo

andare in overload. Nell’intervallo I3 il modello di diagnosi non si accorge

dello stato funzionale del sensore s1 poiche non e rilevante. Infatti il sensore,


pur essendo in overload svolge correttamente le sue mansioni, comunicando

all’RTU una misurazione della temperatura accettabile.

Nell’intervallo seguente, quando invece il sensore s1 comunica all’RTU che

non ha rilevato alcuna temperatura, l’algoritmo SensorControl analizza il

suo stato funzionale notificando che si trova in overload.

La figura 7.17 mostra con il grafico in alto le rilevazioni dei vari sensori e

la stima calcolata della temperatura in base a queste. Con il grafico in basso i

cambiamenti di stato percepiti dall’RTU in funzione dei messaggi diagnostici

ricevuti dal sensore s1.

7.8 Fault injection: stato healthy con rile-

vazioni errate

Un caso particolare da prendere in considerazione riguarda quando un sensore

fornisce dati discordanti rispetto agli altri sensori e nonostante cio il suo

stato funzionale risulta essere HEALTHY. Come si e precedentemente visto,

questo puo influire dalla dimensione ε della finestra temporale impostata. Ma

quando tale situazione si verifica per piu intervalli di tempo, questa situazione

non dipende da ε, bensı da un malfunzionamento del sensore stesso.

La figura 7.18 mostra la simulazione di questo scenario impostando una

soglia γ di tollerabilita per il sensore pari a due.

E facile osservare che nell’intervallo I2 la misurazione del sensore s1 non

viene accettata dall’algoritmo di DecisionScheme e pertanto si controlla il

suo stato funzionale che risulta essere HEALTHY. Nell’intervallo seguente, si

verifica la stessa situazione: la misurazione pervenuta dal sensore s1 non e

accettata poiche discordante dalle altre e dunque, raggiunta la soglia γ, il

7.8. FAULT INJECTION: STATO HEALTHY CON RILEVAZIONI ERRATE141

modello di diagnosi notifica che il sensore s1 e malfunzionante e pertanto

escluso dalle successive stime della temperatura del sistema.

Figura 7.18: Fault injection: Stato Healthy con Rilevazioni Errate.

Capitolo 8Conclusioni

In questo lavoro di tesi si e progettato, implementato e valutato un modello

di diagnosi basato sugli strumenti automatici per la correlazione di eventi in

infrastrutture critiche.

La progettazione ha richiesto inizialmente un accurato studio della lette-

ratura in merito agli strumenti di diagnosi, facendo ricadere la scelta sulle tec-

niche basate sui sintomi e in particolare sull’impiego di strumenti automatici

per la correlazione di eventi.

Si e successivamente mostrato come questi strumenti possono essere dei

validi meccanismi per l’implementazione di euristiche e di tecniche piu sofisti-

cate e come ricalcano esattamente il loro comportamento.

La soluzione proposta, descritta in ognuna delle sue tre fasi, e facil-

mente personalizzabile, intuitiva ed e indicata per infrastrutture critiche non

soggette a frequenti cambiamenti, in cui si necessita di rapide risposte.

Successivamente, dopo aver descritto in dettaglio il contesto in cui questo

modello e stato pensato, e stato realizzato un generatore di logfile per si-

mulare possibili tracce di messaggi scambiati tra le varie entita coinvolte

nel sistema. Questo generatore offre la possibilita di personalizzare l’intero

143

144 CAPITOLO 8. CONCLUSIONI

sistema, di generare eventi “particolari” e di fare fault injection nel sistema.

Con l’ausilio del generatore sviluppato, a dimostrazione dell’efficienza del

modello di diagnosi proposto si e illustrato un caso di studio effettuando

numerosi esperimenti di vario tipo. Questi esperimenti hanno confermato le

aspettative sul modello di diagnosi, validando l’ipotesi che esso, sfruttando le

potenzialita offerte dagli strumenti automatici per la correlazione degli even-

ti, e un efficace ed efficiente mezzo per effettuare diagnosi in infrastrutture

critiche.

Un lavoro interessante da svolgere partendo da questa tesi potrebbe essere

quello di testare il modello di diagnosi proposto su una vera infrastruttura

critica e confrontare i risultati che si otterrebbero con quelli qui presentati.

Appendice ASEC

In questa appendice si mostra piu in dettaglio il funzionamento di SEC. Si

descrivono i pattern accettati, l’uso dei context, le azioni consentite e per

ogni tipo di regola si riportano uno o piu esempi.

Il comando per avviare SEC e il seguente:

sec.pl -input=<inputfile> -conf=<conf file> [opzioni]

-input=<inputfile> rappresenta l’input stream. <inputfile> e utilizzato

come sorgente degli eventi e puo essere un file, una pipe o uno standard input

specificato.

-conf=<conf file> rappresenta il file di configurazione. <conf file> e

il file da cui vengono lette le regole di correlazione degli eventi. Le opzioni

piu comunemente usate sono:

- -log=<logfile>: specifica la posizione di un file che SEC usa per

monitorare le su operazioni, come pattern match, azioni, etc;

- -debug=<debuglevel>: gestisce il livello di informazioni in fase di

debug. <debuglevel> puo assumere i valori:

145

146 APPENDICE A. SEC

1 messaggi critici (seri guasti che causano la terminazione si SEC);

2 messaggi d’errore (guasti che necessitano attenzione ma non

fanno terminare l’esecuzione);

3 warning (possibili guasti);

4 notifiche (normali eventi di sistema ed interruzioni);

5 messaggi informativi (informazioni su comandi esterni a SEC);

6 messaggi di debug (informazioni dettagliate su tutte le attivita).

- -dump=<dumpfile>: fornisce la locazione di un file dump dove SEC

puo riversare le strutture dati interne. Le variabili ed altre informazioni

sulla ricezione di segnali USR1;

- -detach: specificando quest’opzione SEC si separa dal terminale di

controllo e continua la sua esecuzione come un processo daemon. Di

default e -nodetach;

- -testonly: opzione utilizzata per verificare errori di sintassi nei file di

configurazione senza lanciare l’esecuzione di SEC.

Nel file di configurazione di SEC vengono definite le regole (separate tra

loro da linee vuote e commenti). La definizione di ogni regola e composta

da coppie keyword=valore. Il simbolo \puo essere usato alla fine di una

linea per continuare la coppia keyword=valore nella linea successiva. Le

linee che cominciano con il carattere # sono ignorate poiche considerate

commenti. Una linea di commento, una linea vuota o la fine del file terminano

la definizione della regola.

Prima di descrivere in dettaglio ogni tipo di regola, si discutono i pattern

e i tipi di pattern, i context e le azioni, poiche questi sono parti importanti

nella definizione delle regole.

147

Pattern e tipi di pattern

SEC supporta i seguenti tipi di pattern:

- SubStr[<number>]: assume che il pattern e una sotto stringa da ricer-

care nelle ultime <number> linee di input L1, L2, . . . L<number>. Se la

sottostringa viene trovata, il match e soddisfatto. Nek pattern possono

essere usati anche i costrutti \t, \n, \r, \s e \0 per indicare rispet-

tivamente una tabulazione, una nuova linea, un carriage return, uno

spazio o una stringa vuota.

Come esempio consideriamo la seguente definizione di pattern:

ptype=substr

pattern=Backup done:\t success.

Le linee contenenti “Backup done: success.” soddisfano il match.

- RegExp[<number>]: assume che il pattern e un’espressione regolare da

confrontare con le ultime <number> linee di input L1, L2, . . . L<number>.

Se il pattern soddisfa il match, i valori dei backreference vengono as-

segnati alle variabili speciali $1, $2,..., mentre alla variabile speciale $0

viene assegnato L1\nL2\n, . . .\nL<number>. Queste variabili speciali

possono essere usate in altre regole. Sono ammesse tutte le espressioni

regolari del Perl.

Consideriamo il seguente esempio:

ptype=regexp2

pattern=^AAA\BBB$

Produce un match se le ultime due linee di input sono “AAA” e

“BBB”, ed imposta la variabile $0 a “AAA\nBBB”.

- PerlFunc[<number>]: assume che il pattern e una funzione Perl da

sottomettere alle ultime <number> linee di input L1, L2, . . . L<number>.

La funzione Perl viene compilata all’avvio di SEC mediante la chiamata

alla funzione Perl eval(), la quale ritorna un codice di riferimento per

il pattern. Per controllare se il pattern soddisfa il match, SEC chiamera

la funzione passandogli le linee L1, L2, . . . L<number> e il nome della

sorgente di input S1, S2, . . . S<number> come parametri. Se la funzione

ritorna un qualche valore o il valore TRUE in un contesto booleano, il

pattern soddisfa il match e in questo caso, i valori di ritorno saranno

assegnati alle variabili speciali $1, $2,...Tali variabili possono essere

successivamente utilizzate in altre regole.

Come esempio consideriamo il seguente:

ptype=perlfunc2

pattern=subreturn($ [0] cmp $ [1]);

Il pattern confronta le ultime due linee di input in maniera string-

wise ($ [1] contiene l’ultima linea, mentre $ [0] la penultima),

se le linee sono diverse il match e soddisfatto. Il risultato del

confronto e assegnato alla variabile $1, mentre le due linee con-

catenate sono assegnate alla variabile $0.

- NSubStr[<number>]: assume lo stesso comportamento di SubStr, ma

il risultato del match viene negato.

- NRegExp[<number>]: assume lo stesso comportamento di RegExp, ma

il risultato del match viene negato.

- NPerlFunc[<number>]: assume lo stesso comportamento di PerlFunc,

ma il risultato del match viene negato.

149

- TValue: il pattern assume come valori legittimi TRUE e FALSE. TRUE

soddisfa il match con qualsiasi linea di input, mentre FALSE non lo

soddisfa mai.

Poiche le regole Pair e PairWithWindow hanno due definizioni di pattern,

per accedere, nel secondo pattern, alle variabili speciali $<number> impostate

dal primo pattern, e necessario rivolgersi come %<number> (es. invece di $1

si utilizza %1).

Espressioni di context

Un’espressione di context e un’espressione logica contenente i nomi dei con-

text, mini-programmi Perl e funzioni Perl come operandi. Gli operandi sono

combinati mediante gli operatori ! (NOT logico), && (AND logico), || (OR

logico) e parentesi. Le espressioni di context sono impiegate per attivare o

disattivare regole: la regola processera le linee di input sono se l’espressione

viene valutata TRUE.

Se l’operando contiene la freccia (->), il testo seguente viene considerato una

funzione Perl. Prima della freccia e possibile inserire una lista di parametri

per la funzione. I parametri sono separati da uno spazio e possono contenere

le variabili speciali $<number> e %<number>.

($1 $2)->(subreturn($ [0]!=$ [1]);)

Se l’operando comincia con il simbolo =, il testo che segue e considerato un

mini-programma Perl. Anche qui e possibile utilizzare le variabili speciali.

=(my($temp)=0; return !$temp;)

Se l’operando non e ne una funzione Perl ne un mini-programma, allora viene

considerato come il nome di un context. Se il nome del context si riferisce a

un context gia esistente, il valore dell’operando e TRUE, altrimenti FALSE.

Se l’intera espressione di context e racchiusa tra le parentesi quadre [] (ad es.

[CONTEXT1 && !CONTEXT2]), SEC valutera l’espressione prima di effettuare

l’operazione di pattern matching (normalmente il pattern e confrontato con

le linee di input prima, in modo che le variabili $<number> e %<number>

nell’espressione di context possono essere sostituite con i loro valori).

Si riporta qui di seguito alcuni esempi di espressioni di context:

->(sub my(@stat)=stat(’’/var/log/messages’’);\

return (!scalar(@stat) || time() - $stat[9]>3600);)

($1 $2)->(sub return ($ [0]!=$ [1]);)&& C1

!(C1||C2)&&=(’’$1’’ eq ’’myhost.mydomain’’)

La prima espressione e TRUE quando il file /var/log/messages non esiste o

l’ultima modifica risale a piu di un’ora antecedente. La seconda espressione

e TRUE quando le variabili $1 e $2 non sono numericamente uguali ed esiste

il context C1. La terza espressione e TRUE quando non esistono i context C1

e C2 e la variabile $1 contiene la stringa ’’myhost.mydomain’’.

Lista di azioni

Una lista di azioni consiste nella definizione di varie azioni separate un punto

e virgola (;). Ogni definizione di azione comincia con una parola chiave che

specifica il tipo d’azione, seguita da parametri aggiuntivi. Questi parametri

aggiuntivi possono contenere, oltre che alle variabili speciali $<number> e

%<number>, anche i seguenti:

%s stringa di descrizione dell’evento (impostata mediante i parametri

desc o desc2 della definizione della regola);

151

%t timestamp testuale;

%u timestamp numerico;

%<alnum name> variabili definite dall’utente che possono essere im-

postate a runtime con alcune azioni tipo assign o eval. Per evitare

equivoci, alnum name deve essere racchiuso tra parentesi graffe.

Le azioni supportate da SEC sono:

- none nessuna azione;

- logonly [<event text>] scrive sullo standard output la stringa <event

text>, se esiste, o %s in caso contrario;

- write <filename> [<event text>] scrive nel file filename (<file-

name> non deve contenere spazi) la stringa <event text>, se esiste, o

%s in caso contrario. Il file puo essere un regular file, una named pipe

o lo standard output, se specificato. Se il file non esiste, viene creato;

- shellcmd <shellcmd> esegue il comando di shell <shellcmd>;

- spawn <shellcmd> e identico al comando shellcmd pero ogni linea

dello standard output di <shellcmd> viene considerata da SEC come

una nuova linea di input e quindi viene controllato un eventuale match

con qualche regola;

- pipe ’<event text>’ [<shellcmd>] passa allo standard input del

comando di shell <shellcmd> la stringa <event text> (gli apostrofi

sono usati per marcare l’inizio e la fine di <event text> per evitare

fraintendimenti con <shellcmd>). Se <event text> e omesso e non

c’e niente tra gli apostrofi, si assume come stringa %s. Se e omesso

<shellcmd>, allora l’<event text> e scritto sullo standard output;

- create [<name> [<time> [<action list>]]] crea un context con

nome <name> e lifetime <time>. Se <name> e omesso si prende come

valore %s. Specificando come <time> 0 o omettendo tale opzione, il

lifetime viene considerato infinito. Se e specificata un <action list>,

questa sara eseguita allo scadere del context. Se il context e gia esi-

stente, il suo lifetime e prolungato per <time> secondi;

- delete [<name>] cancella il context <name>, se specificato, altrimenti

assume per tale valore %s. Se non esiste un context con questo nome,

non esegue alcuna azione;

- obsolete [<name>] ha lo stesso comportamento di delete, ad ec-

cezione del fatto che, prima dell’eliminazione, esegue l’<action list>

del context in questione;

- set <name> <time> [<action list>] effettua dei cambiamenti al con-

text <name>. Il nuovo lifetime del context sara di <time> secondi e

l’eventuale <action list> sara eseguita allo scadere del context;

- alias <name> [<alias>] crea un alias di nome <alias> per il context

<name>. Dopodiche sara possibile far riferimento al context usando sia

<name> che <alias>. Se il context <name> non esiste, o il nome <alias>

e gia esistente, l’alias non sara creato;

- unalias [<alias>] rimuove l’alias <alias> del context dalla lista dei

nomi del context, in modo che non e piu possibile far riferimento al

context a cui era precedentemente associato. Se tale alias non esiste,

l’azione non viene eseguita;

- add <name> [<event text>] aggiunge la stringa <event text> al con-

153

text <name>. Gli eventi in memoria sono ordinati in base al tempo in

cui sono stati aggiunti, e l’azione add aggiunge l’evento in fondo;

- fill <name> [<event text>] ha lo stesso comportamento di add,

pero viene prima svuotata la memoria del context <name>.

- report <name> [<shellcmd>] riporta tutti gli eventi del context <name>

sullo standard output del comando di shell <shellcmd>, in ordine di

immagazzinamento;

- copy <name> %<alnum name> assegna tutti gli eventi del context <name>

alla variabile definita dall’utente %<alnum name>;

- empty <name> [%<alnum name>] ha lo stesso comportamento di copy,

pero, dopo che ha effettuato l’assegnamento alla variabile %<alnum name>

svuota il context <name>. Se %<alnum name> e omesso, rimuove sem-

plicemente tutti gli eventi dal context;

- event [<time>] [<event text>] dopo <time> secondi viene creato

l’evento <event text>. SEC tratta tale evento come una linea di input

e la confronta con le regole. Se <event text> e omesso, si considera

linea di input %s. Se <time> e 0 o viene omesso, l’azione e immediata;

- tevent <time> [<event text>] si comporta come event, pero <time>

puo contenere variabili;

- reset [<rule number>] [<event text>] annulla le operazioni di cor-

relazioni che hanno <event text> nelle loro chiavi come stringa di

descrizione dell’evento. Se <event text> e omesso si prende come va-

lore %s. Poiche le operazioni di correlazione, avviate da regole diverse,

possono rilevare eventi compositi che hanno stinghe di descrizione iden-

tiche, e possibile specificare il numero della regola (1 indica la prima

regola del file di configurazione, 2 la seconda regola,ect.; 0 indica la re-

gola corrente). Se davanti a rule number si pone un + o un - si vuole

indicare rispettivamente la regola successiva o quella precedente;

- assign %<alnum name> [<text>] assegna il testo <text> alla varia-

bile definita dall’utente %<alnum name>. Se <text> e omesso, assegna

%s;

- eval %<alnum name> <code> assume che il parametro <code> sia un

mini-programma Perl e sara eseguito chiamando la funzione Perl eval().

Eventuali valori di ritorno saranno assegnati alla variabile %<alnum name>;

- call %<alnum name1> %<alnum name2> [<parameter list>] assume

che i parametri %<alnum name1 e %<alnum name2 sono funzioni Perl

create precedentemente mediante l’azione eval. La funzione sara richia-

mata passandogli i parametri opzionali <parameter list>. Eventuali

valori di ritorno saranno assegnati alla variabile %<alnum name1>.

Tipi di regole

Regola Single. Esegue immediatamente un’azione se il match e sod-

disfatto. La struttura di questa regola e la seguente:

type=singlecontinue=...(opzionale)ptype=...pattern=...context=...(opzionale)desc=...action=...

155

Esempio 1

#Scrive sullo std output#ogni stringa in input.#type=singleptype=regexppattern=(.*)desc=$0action=write - $1

Esempio 2

#Riconosce un pattern e,#se il context esiste,#ne effettua il log.#type=singlecontinue=takenextptype=regexppattern=Errore (.*)context=ERRdesc=$0action=add ERR $1; logonly

Il campo continue puo assumere i valori takeNext o dontCont. Nel

primo caso si specifica che la ricerca delle regole di matching continuera

anche dopo aver soddisfatto il match. Nel secondo caso la ricerca ter-

minera. Se il campo continue viene omesso, si assume che il suo valore

sia dontCont.

La regola dell’esempio 1 scrive sullo standard output ogni stringa rice-

vuta in ingresso, che, di volta in volta, viene memorizzata nella variabile

$1. La regola nell’esempio 2, riconosce le linee di input che contengono

la stringa “Errore” e, se il context ERR esiste, aggiunge l’errore a tale

context e ne effettua il log.

Regola SingleWithScript. Combina il matching di un pattern con

l’esecuzione di un programma separato, per determinare se un match e

soddisfatto. La sua struttura e simile alla regola single, ad eccezione

del campo script:

type=singleWithScritpcontinue=...(opzionale)ptype=...pattern=...context=...(opzionale)script=...desc=...action=action2=...(opzionale)

Poiche il tempo d’esecuzione dello script non e limitato in alcun modo,

SEC non attende che esso sia completato, piuttosto continua il suo

lavoro. Quando verra restituito il valore d’uscita dello script, in base a

tale valore, SEC eseguira o action o, eventualmente, action2.

Esempio 3

#!/usr/bin/perl #Passa un indirizzo IP allo# #script per la validazione#Script S1.pl - #Se e valido esegue#Verifica la presenza #action, altrimenti action2.#di un indirizzo IP ##in una lista. type=singleWithScript# ptype=regexp@matchList = (’192.168.2.1’, pattern=(\d+).(\d+).(\d+).(\d+)\

’192.168.2.2’); script=/usr/bin/perl home/../S1.pl $0$ipAddr = $ARGV[0]; desc=$0foreach $ip (@matchList) action=write - IP $0 match. action2=write - IP $0 NO match.

exit(0) if $ipAddr eq $ip;exit 1;

Lo script nell’esempio 3 controlla se l’indirizzo IP, passatogli come ar-

gomento, e presente nella breve lista di indirizzi che ha a disposizione.

Se in tale lista vi compare, allora il valore di ritorno e 0, altrimenti 1.

La regola di tipo singleWithScript viene eseguita quando la stringa

ricevuta soddisfa il match con il pattern. In tal caso, lancia l’esecuzione

dello script e, se il valore di ritorno e 0 (e quindi il match e soddisfatto),

esegue action, altrimenti action2.

Esempio 4

#Alla ricezione del pattern effettua un ping verso#l’indirizzo IP presente nel pattern.#Se il valore di ritorno e 0 esegue lo script notify.sh,#altrimenti non esegue alcuna azione.#type=singleWithScriptptype=regexppattern=interface (\S+) downscript=/usr/local/script/ping.sh $1desc=Interface $1 downaction=shellcmd /usr/local/script/notify.sh ’’%s’’

Con la regola mostrata nell’esempio 4, quando una linea di input con-

tiene il pattern “interface <ipaddress> down”, viene eseguito lo script

157

ping.sh e se il valore di ritorno e 0, la regola effettua la chiamata a

notify.sh passandogli come argomento desc.

Regola SingleWithSuppress. Effettua un’azione di compressione

degli eventi in caso di istanze multiple. La sua struttura e simile alla

regola Single, ad eccezione del parametro aggiuntivo window:

type=singleWithSuppresscontinue=...(opzionale)ptype=...pattern=...context=...(opzionale)desc=...action=...window=...

Il parametro window, espresso in secondi, rappresenta la finestra tempo-

rale in cui ogni occorrenza del pattern viene ignorata, poiche compressa

in un’unica istanza.

Esempio 5

#Comprime multiple istanze del pattern,#nell’arco di 5 minuti, in un’unica occorrenza.#type=singleWithSuppressptype=regexppattern=[fF]iledesc=$0action=write - $0 suppress for 5 minutes at %twindow=300

La regola dell’esempio 5, riconosciuto il pattern “File” o “file”, ignora,

per i successivi cinque minuti, tutte le occorrenze di tale stringa.

Regola Pair. Progettata per implementare una delle forme base delle

relazioni temporali nelle operazioni di correlazione degli eventi, in cui

due o piu eventi sono ridotte a una coppia di eventi all’interno di una

data finestra temporale. La struttura di questa regola e la seguente:

type=paircontinue=...(opzionale)ptype=...pattern=...context=...(opzionale)desc=...action=continue2=...(opzionale)ptype2=...pattern2=...context2=...(opzionale)desc2=...action2=...window=...(opzionale)

Si osserva che la regola pair gestisce due eventi diversi, che soddisfano il

match di due pattern diversi. La finestra temporale e impostata sulla

prima occorrenza del primo evento. Se il secondo evento si verifica

all’interno di tale finestra temporale, i due eventi vengono considerati

correlati e l’intera regola soddisfa il match. Altrimenti, l’operazione di

correlazione per la coppia termina.

Esempio 6

#Riconosce il pattern ed effettua una notifica.#Se entro un’ora riceve un ulteriore pattern,#invia una successiva notifica.#type=pairptype=regexppattern=NFS server (\S+) not respondingdesc=$1 is not respondingaction=shellcmd /usr/local/script/notify.sh ’’%s’’ptype2=substrpattern2=NFS server $1 okdesc2=$1 OKaction2=shellcmd /usr/local/script/notify.sh ’’%s’’window=3600

Nella regola dell’esempio 6, quando viene ricevuta come linea di input

“NFS server <fserv> is not responding”, l’operazione di correlazione

avviata, effettua la chiamata a notify.sh passandogli come argomen-

to la stringa “<fserv> is not responding”. Dopodiche attende l’even-

tuale arrivo della linea di input “NFS server <fserv> ok” entro un’ora,

ignorando tutte le stringhe “NFS server <fserv> is not responding”.

159

Se si verifica l’occorrenza attesa, l’operazione di correlazione esegue il

comando di shell notify.sh con argomento “<fserv> OK” e termina.

Altrimenti, passata un’ora, l’operazione di correlazione terminera senza

fare alcuna azione.

Regola PairWithWindow. Questa regola e un’altra variante della

relazione temporale di correlazione di eventi che controlla se due eventi

sono consecutivi nell’arco di una finestra temporale data. La struttura

della regola pairWithWindow e la seguente:

type=pairWithWindowcontinue=...(opzionale)ptype=...pattern=...context=...(opzionale)desc=...action=continue2=...(opzionale)ptype2=...pattern2=...context2=...(opzionale)desc2=...action2=...window=...

La differenza con la regola pair e che, in questo caso, l’azione action2

viene eseguita solo se entrambi gli eventi si verificano all’interno della

finestra temporale. Se si verifica solo il primo evento, la regola esegue

solo action.

Esempio 7

#Riconosce il pattern ed attende per 10 minuti#l’arrivo del secondo pattern.#Se questo si verifica crea un evento,#altrimenti effettua una notifica.#type=pairWithWindowptype=regexppattern=node (\S+) interface (\S+) downdesc=$1 if $2 is downaction=shellcmd /usr/local/script/notify.sh ’’%s’’ptype2=substrpattern2=node $1 interface $1 updesc2=$1 if $2 short outageaction2=eventwindow=600

Quando viene ricevuto l’input “node <fserv> interface <inter> down”,

la regola dell’esempio 7 inizia l’operazione di correlazione la quale at-

tende per dieci minuti il pattern “node <fserv> interface <inter> up”.

Se questa stringa non arriva nell’arco di tempo previsto, l’operazione

di correlazione esegue il comando si shell notify.sh passandogli come

argomento “node <fserv> interface <inter> down” e termina. Altri-

menti viene eseguita l’azione action2 e dunque creato l’evento “node

<fserv> interface <inter> up” e termina.

Regola SingleWithThreshold. Questa regola e stata progettata

effettuare il conteggio di un evento. Vengono contate le occorrenze di

un evento in un data finestra temporale e confrontate con una soglia

per rilevare un evento composto. La sua struttura e la seguente:

type=singleWithThresholdcontinue=...(opzionale)ptype=...pattern=...context=...(opzionale)desc=...action=...action2=...(opzionale)window=...thresh=...

Se all’interno della finestra temporale il numero di match raggiunge la

soglia, viene eseguita l’azione action. Altrimenti la finestra temporale

viene “slittata” alla seconda occorrenza del pattern. Questo processo

viene ripetuto fino allo scadere del tempo senza nuovi match.

161

Esempio 8

#Conta le occorrenze del pattern.#Se viene raggiunta la soglia di 3 occorrenze,#entro un minuto, scrive un messaggio sul std output.#type=singleWithThresholdptype=regexppattern=user (\S+) login failure on (\S+)desc=repeated login failures for user $1 on $2action=write - ‘‘%s’’window=60thresh=3

Quando viene osservata la linea “user <us> login failure on <ser>, la

regola dell’esempio 8 avvia l’operazione di correlazione che scrive sullo

standard output la stringa “repeated login failures for user <us> on

<ser> se tale input occorre per altre due volte, all’interno di un arco

temporale di un minuto. Le eventuali successive linee di input “user

<us> login failure on <ser> saranno ignorate da questa regola fino a

che non saranno trascorsi 60 secondi dall’arrivo della prima occorrenza.

Altrimenti, scaduta la finestra temporale, non viene eseguita alcuna

azione.

Regola SingleWith2Threshold. Questa regola e un’altra variante

per il conteggio di un evento. Le occorrenze di un dato evento vengono

conteggiate due volte: la prima volta per controllare se raggiungono una

prima soglia prestabilita; la seconda volta per controllare se restano al

di sotto di un’ulteriore soglia (maggiore rispetto alla precedente). La

struttura di tale regola e la seguente:


type=singleWith2Thresholdcontinue=...(opzionale)ptype=...pattern=...context=...(opzionale)desc=...action=...window=...thresh=...desc2=...action2=...(opzionale)window2=...thresh2=...

Questa regola e molto simile alla singleWithThreshold, ad eccezione

del fatto che in questo caso e possibile determinare fermare gli eventi,

mediante l’uso della seconda soglia e della seconda finestra temporale.

singleWith2Threshold conta il numero di match soddisfatti ed esegue

l’azione action quando le occorrenze eccedono la soglia thresh. Una

volta raggiunta questa soglia inferiore, SEC avvia la finestra temporale

window2 e conta le occorrenze aggiuntive dell’evento. Se il numero delle

occorrenze resta al di sotto della soglia superiore thresh2 all’interno

dell’arco temporale window2, SEC esegue l’azione action2. Anche in

questo caso entrambe le finestre temporali subiscono slittamenti.

Esempio 9

#Se si verificano 3 occorrenze#del pattern scrive sullo std#output un primo avviso.#Se le occorrenze restano al#di sotto di 5, scrive un#secondo avviso.#type=singleWith2Thresholdptype=regexppattern=warning (\S+)desc=$0action=write - $0 at time %twindow=10thresh=3desc2=under high thresholdaction2=write - $0window2=20thresh2=5

Esempio 10

#Se, in 5 minuti, riceve 2#messaggi di CPU,#notifica un overload.#Se, nell’arco di un’ora,#non riceve piu messaggi di CPU,#notifica il ritorno alla normalita.#type=singleWith2Thresholdptype=regexppattern=(\S+):%SYS-CPUdesc=route $1 CPU overloadaction=shell notify.sh ‘‘%s’’window=300thresh=2desc2=router $1 CPU load normalaction2=shellcmd notify.sh ‘‘%s’’window2=3600thresh2=0

163

La regola dell’esempio 9 conta le occorrenze di un messaggio di “warn-

ing” nell’arco di dieci secondi. Se queste raggiungono una prima soglia

di tre, viene scritto un messaggio sullo standard output. Dopodiche

inizia una seconda finestra temporale di venti secondi, in cui vengono

ancora conteggiate le occorrenza del messaggio. Se queste restano al di

sotto della seconda soglia (impostata a cinque), viene eseguita l’azione

action2 e quindi scritto un ulteriore messaggio sullo standard output.

Nell’esempio 10, vengono contati i messaggi relativi alla CPU. Se nel-

l’arco di cinque minuti, se ne ricevono due, viene effettuata una notifica

di overload. Se nell’ora a seguire, non vengono piu ricevuti messaggi di

CPU si notifica il ritorno alla normalita tramite il messaggio “router

<rou> CPU load normal.

Regola Suppress. Svolge il compito di filtraggio o soppressione di un

evento. La sua struttura e la seguente:

type=Suppressptype=...pattern=...context=...(opzionale)desc=...(opzionale)

Il suo funzionamento e molto intuitivo: se il match con pattern e

soddisfatto, l’evento viene soppresso senza compiere alcuna azione.

Esempio 11

#Sopprime tutti i messaggi#che soddisfano il pattern.#type=suppressptype=regexppattern=[fF]ile system fullcontext=Sys

Se e presente il context Sys, la regola dell’esempio 11, sopprime tutti

gli eventi del tipo “file system full”.


Regola Calendar. Esegue un’azione al tempo specificato. Diversa-

mente da tutte le altre, questa regola reagisce solo al clock si sistema,

ignorando l’input. La struttura della regola calendar e la seguente:

type=calendartime=...context=...(opzionale)desc=...action=...

Il tempo e espresso secondo lo stile crontab. La specifica del tempo

consiste di cinque campi separati da uno spazio: minuti (0-59), ore

(0-23), giorno (0-31), mese (1-12) e giorno della settimana (0-7, 0 e 7

rappresentano la domenica).

Esempio 12

#Ogni giorno alle 23pm crea un#context con lifetime 9 ore.#type=calendartime=0 23 * * *desc=nightContextaction=create %s 32400

La regola dell’esempio 12 crea il context nightContext, con un lifetime

di nove ore, ogni giorno alle ore 23pm.

E possibile specificare valori multipli di un campo time utilizzando:

- l’operatore virgola (,) che specifica una lista di valori; ad esempio

1,3,6,8;

- l’operatore trattino (-) che specifica un intervallo di valori; ad

esempio 1-4 equivale a 1,2,3,4;

- l’operatore asterisco (*) che specifica tutti i possibili valori di un

campo; ad esempio un asterisco nel campo dell’ora e equivalente

a ogni ora.

Ringraziamenti

Un primo “Grazie” va, senza ombra di dubbio, alla mia famiglia: babbo,

mamma, nonno Ferrando e nonna Carla. Dopodiche un ringraziamento spe-

ciale vorrei farlo a Sacha che mi e stato vicino ascoltando in silenzio tutte

le mie lamentele. Ringrazio la Marty, amica da una vita, perche insieme

abbiamo condiviso tutti questi anni universitari (e non solo), giorno dopo

giorno, esame dopo esame. Ringrazio le amiche di sempre - Marghe e Silvia

- e la “new entry” - Alice - per essere presenti in ogni momento e per avermi

dato una scrollata quando ce n’e stato bisogno...ma senno a cosa servono le

amiche??

Ringrazio Sergio che si e rivelato essere un Amico con la A maiuscola e che

insieme ad Alessio e Nicola, i quali ringrazio, mi hanno sopportato in tutto

questo periodo...non so proprio come hanno fatto!!

Desidero inoltre ringraziare coloro che sono stati comunque presenti in quella

che e stata mia vita quotidiana al Dini: i’Testori, i’Piwi, i’Belli, lo Sdel-

ci, Roberto, l’Ilaria e Duccio, lo Zibe, Cristiano, i’Monte, Andrea...avro

dimenticato qualcuno? Spero di no..in ogni caso lo ringrazio!

Infine ringrazio il Prof. Bondavalli e il Dr. Daidone per la loro disponi-

bilita e per l’aiuto che mi hanno dato.

165

Bibliografia

[1] Logsurfer+. http://www.crypt.gen.nz/logsurfer/.

[2] NETeXPERT. http://www.agilent.com/comms/OSS. Agilent Technolo-

gies.

[3] PROFIBUS. http://www.profibus.com/pb/applications/casestudies/.

[4] PROFIBUS Specification. Normative Parts of PROFIBUS -FMS, -DP,

-PA according to the European Standard EN 50 170 Volume 2.1998.

[5] SMART InCharge. http://www.nsai.net/. Network System Architects.

[6] SpectrumRx. http://www.ca.com. Aprisma Corporation.

[7] MieLog: A Highly Interactive Visual Log Browser Using Information Vi-

sualization and Statistical Analysis. In LISA ’02: Proceedings of the 16th

USENIX conference on System administration, pages 133–144, 2002.

[8] R. C. Agarwal, C. C. Aggarwal, and V. V. V. Prasad. A Tree Projec-

tion Algorithm for Generation of Frequent Itemsets. In J. Parallel and

Distributed Computing, 2000.

167

168 BIBLIOGRAFIA

[9] R. Agrawal, T. Imielinski, and A. Swami. Mining Association Rules

between Sets of Items in Large Database. Proceedings of SIGMOD,

1993.

[10] R. Agrawal and R. Srikant. Fast algorithms for mining association rules.

In VLDB ’94: Proceedings of the 20th International Conference on Very

Large Data Bases, pages 487–499, 1994.

[11] A. Bondavalli, S. Chiaradonna, D. Cotroneo, and L. Romano. A

fault-tolerant distributed legacy-based system and its evaluation.

In LADC2003 - First Latin-American Symposium on Dependable

Computing, San Paolo, pages 303–320, 2003.

[12] A. Bondavalli, S. Chiaradonna, D. Cotroneo, and L. Romano. Effective

fault treatment for improving the dependability of COTS and legacy-

based applications. IEEE Transactions on Parallel and Distributed

Systems, pages 223–237, 2004.

[13] A. Bondavalli, S. Chiaradonna, F. Di Giandomenico, and F. Grandoni.

Threshold-Based Mechanisms to Discriminate Transient from In-

termittent Faults. IEEE Transactions on Computers, 49:230–245,

2000.

[14] M. Buckley and D. Siewiorek. Comparative Analysis of Event Tupling

Schemes. Proceedings of FTCS, 1996.

[15] D. W. Cheung, J. Han, V. T. Ng, A. W. Fu, and Y. Fu. A Fast Distribut-

ed Algorithm for Mining Association Rules. Conference on Parallel and

Distributer Information Systems, 1996.

BIBLIOGRAFIA 169

[16] A. Daidone. Le catene di Markov nascoste come supporto alla forma-

lizzazione del problema della diagnosi nei sistemi affidabili. Universita

degli studi di Firenze, 2005. Tesi di Laurea, Corso di Informatica.

[17] A. Daidone, F. Di Giandomenico, S. Chiaradonna, and A. Bondavalli.

Hidden Markov models as a support for diagnosis: Formalization of the

problem and synthesis of the solution. In Proc. of the 25th IEEE Symp.

on Reliable Distributed Systems (SRDS), pages 245–256, 2006.

[18] A. Das, W. K. Ng, and Y. K. Woon. Rapid Association Rule Mining.

In Proceedings of the tenth international conference in Information and

knowledge management ACM Press, 2001.

[19] C. L. Forgy. Rete: a fast algorithm for the many pattern/many object

pattern match problem. In Expert systems: a software methodology for

modern applications, pages 324–341, 1990.

[20] P. Gujrati, Y. Li, Z. Lan, R. Thakur, and J. White. A Meta-Learning

Predictor for Blue Gene/L Systems. Proceedings of ICPP, 2007.

[21] J. Han and J. Pei. Mining Frequent Patterns by Pattern-Growth:

Methodology and Implications. In ACM SIGKDD Explorations

Newsletter, pages 14–20, 2000.

[22] J. Hansen and D. Siewiorek. Models for Time Coalescence in Event

Logs. Proceedings of FTCS, 1992.

[23] S. E. Hansen and E. T. Atkins. Automated system monitoring and

notification with Swatch. In In Proceedings of LISA, pages 145–155,

1993.

170 BIBLIOGRAFIA

[24] G. Jakobson and M. Weissman. Alarm Correlation. In IEEE Network,

pages 52–59, 1993.

[25] G. Jakobson and M. Weissman. Real-time telecommunication network

management: extending event correlation with temporal constraints. In

Proceedings of the fourth international symposium on Integrated network

management IV, pages 290–301, 1995.

[26] J. O. Kephart and D. M. Chess. The Vision of Autonomic Computing.

In IEEE Computer Society Press, pages 41–50, Los Alamitos, CA, USA,

2003.

[27] M. Klemettinen. A knowledge discovery methodology for telecommuni-

cation network alarm database. In PhD Thesis, University og Helsinki,

Finland, 1999.

[28] S. Klinger, S. Yemini, Y. Yemini, D. Ohsie, and E. Mozes. High speed

and robust event correlation. In IEEE communications magazine, 1996.

[29] S. Klinger, S. Yemini, Y. Yemini, D. Ohsie, and S. Stolfo. A coding

approach to event correlation. In Proceedings of the fourth international

symposium on Integrated network management IV, pages 266–277, 1995.

[30] J. C. Laprie and B. Randell. Basic Concepts and Taxonomy of Depend-

able and Secure Computing. IEEE Trans. Dependable Secur. Comput.,

1(1):11–33, 2004.

[31] L. Lewis. A case-based reasoning approach for the resolution of faults

in communication networks. In Proceedings of the third IFIP/IEEE

international symposium on Integrated network management, 1993.

BIBLIOGRAFIA 171

[32] L. Lewis. Service level management for enterprise networks. In Artch

House, 1999.

[33] Y. Liang, Y. Zhang, A. Sivasubramanium, R. Sahoo, J. Moreia,

and M. Gupta. Filtering Failure Logs for Blue Gene/L Prototype.

Proceedings of DSN, 2005.

[34] Y. Liang, Y. Zhang, H. Xiong, and R. Sahoo. An Adaptive Semantic

Filter for Blue Gene/L Failure Log Analysis. In Parallel and Distributed

Processing Symposium. IEEE International, 2007.

[35] G. Liu, A. K. Mok, and E.J. Yang. Composite Events for Network

Event Correlation. In Proceedings of th 6th IFIP/IEEE International

Symposium on Integrated Network Management, pages 247–260, 1999.

[36] A. M. Manning and J. A. Keane. Data Allocation Algorithm for Parallel

Association Rule Discovery. Lecture Notes in Computer Science, 2001.

[37] J. P. Martin-Flatin, G. Jakobson, and L. Lewis. Event Correlation in

Integrated Management: Lessons Learned and Outlook. J. Netw. Syst.

Manage., 15(4):481–502, 2007.

[38] D. M. Meira. A model for alarm correlation in telecommunications

networks, 1997. PhD Thesis.

[39] A. Oliner and J. Stearley. What Supercomputers Say: A Study of Five

System Logs. In Proceedings of the International Conference on DSN,

pages 575–584, 2007.

[40] A. Oliner and J. Stearly. What Supercomputers Say: a Study of Five

System Logs. Proceedings of DSN, 2007.

172 BIBLIOGRAFIA

[41] S. Parthasarathy. Efficient Progressive Sampling for Association Rules.

ICDM, pages 354–361, 2002.

[42] B. Peischl and F. Wotawa. Model-Based Diagnosis or Reasoning from

First Principles. IEEE Intelligent Systems, 18(3):32–37, 2003.

[43] P. Peti, R. Obermaisser, and H. Kopetz. Out-of-Norm Assertions.

In RTAS ’05: Proceedings of the 11th IEEE Real Time on Embedded

Technology and Applications Symposium, pages 280–291, 2005.

[44] M. Pizza, L. Strigini, A. Bondavalli, and F. Di Giandomenico. Optimal

discrimination between transient and permanent faults. In Third IEEE

International High-Assurance Systems Engineering Symposium, pages

214–223, 1998.

[45] J. E. Prewett. Listening to your Cluster with LoGS. The Center for

High Performance Computing at UNM, 2004.

[46] J. A. Redstone, M. M. Swift, and B. N. Bershad. Using computers

to diagnose computer problems. In HOTOS’03: Proceedings of the 9th

conference on Hot Topics in Operating Systems, pages 16–16, 2003.

[47] L. Romano, A. Bondavalli, S. Chiaradonna, and D. Cotroneo. Imple-

mentation of Threshold-based Diagnostic Mechanisms for COTS-Based

Applications. In SRDS ’02: Proceedings of the 21st IEEE Symposium

on Reliable Distributed Systems (SRDS’02), page 296, 2002.

[48] J. P. Rouillard. Real-time Log File Analysis Using the Simple Event

Correlator (SEC). In 18th Large Installation System Administration

Conference, 2004.

BIBLIOGRAFIA 173

[49] W. H. Sanders. Introduction to Computer System and Network

Validation. Materiale Didattico, 2006.

[50] W. H. Sanders, W. D. Oball, M. A. Qureshi, and F. K. Widjanarko.

The UltraSAN modeling environment. Perform. Eval., 24(1-2):89–115,

1995.

[51] D. P. Siewiorek and R. S. Swarz. Reliable computer systems (3rd ed.):

design and evaluation. 1998.

[52] L. Simoncini, F. Di Giandomenico, A. Bondavalli, and S. Chiaradonna.

Architectural Challenges for a Dependable Information Society. In Fault

Tolerance for Trustworthy and Dependable Information Infrastructures.

Topical Days Track, WCC 18th IFIP World Computer Congress, 2004.

[53] S. Slade. Case-based reasoning: a research paradigm. In AI Magazine,

pages 42–55, 1991. Vol. 12, num. 1.

[54] H. Toivonen. Sampling Large Database for Association Rules. In The

VLDB Journal, pages 134–145, 1996.

[55] R. Vaarandi. SEC - a lightweight event correlation tool. Washington,

DC, USA, 2002. Proceedings of IEEE workshop on IP operation and

management.

[56] P. Verissimo and L. Rodrigues. Distributed Systems for System

Architects. Kluwer Academic Publishers, Norwell, MA, USA, 2001.

[57] A. J. Weiner, D. A. Thurman, and C. M. Mitchell. Applying case-

based reasoning to aid fault management in supervisory control. In

Proceedings of the 1995 IEEE international conference on systems, man

and cybernetics, pages 4213–4218, 1995.

174 BIBLIOGRAFIA

[58] H. Wietgrefe, K. Tuchs, and G. Carls. Using neural networks for alarm

correlation in cellular phone networks. In Proc. International Workshop

on Applications of Neural Networks in Telecommunications, 1997.

Strumenti automatici per la correlazione di eventi a scopo ...

Documents

Transcript of Strumenti automatici per la correlazione di eventi a scopo ...