Ogni anno però si registra una crescita del volume del traffico aereo,
delle simulazioni di Eurocontrol, l’ente europeo preposto alla gestione del
traffico aereo, intravedono l’inadeguatezza delle strutture di controllo at-
tuali per soddisfare i futuri scenari. Da qui l’esigenza di promuovere un
nuovo programma di sviluppo denominato Link2000+ che prevede di in-
tegrare nuovi servizi su di una architettura distribuita. Mentre l’attuale
sistema è quasi per intero basato su trasmissioni analogiche (vocali), la
nuova architettura utilizzerà invece la rete ATN (Aeronautical Telecom-
munications Network) basata su trasmissione digitale. Come sottolineato
il nuovo sistema non potrà sostituire immediatamente quello esistente.
In quest’ottica si pone il nuovo servizio CPDLC (Controller Pilot Data
Link Communication) che affiancandosi alla tradizionale comunicazione
vocale, consentirà l’automatizzazione di certe procedure di controllo e lo
scambio messaggi tra controllore e pilota attraverso la trasmissione digi-
tale.
La scelta di introdurre un nuovo sistema in un contesto critico, compor-
ta tra le altre, anche una valutazione quantitativa per stabilire se il sis-
tema raggiunge o meno i livelli attesi di qualità del servizio. Questa tesi
svolta in collaborazione con l’azienda OTE di Firenze, ha come obiettivo
primario la valutazione quantitativa di un sistema CPDLC per riuscire a
stimare i tempi di risposta del sistema percepiti dall’utente.
Le tecniche possibili per un’analisi quantitativa sono tre: analitiche, simu-
lative e sperimentali. Le prime due tecniche si basano su un modello del
sistema, mentre l’ultima utilizza direttamente il sistema reale. La scelta di
una tecnica rispetto ad un’altra, dipende dalla fase del sistema in cui tale
tecnica viene impiegata.
iv
Mentre le funzionalità del servizio CPDLC sono già state ben specificate,
ancora non è disponibile un sistema CPDLC in versione definitiva, eccetto
qualche prototipo come quello utilizzato da Eurocontrol nell’area di Maas-
tricht. Perciò l’impiego di una tecnica puramente sperimentale è pressoché
impossibile, così come l’utilizzo di una tecnica analitica basata su un mod-
ello matematico molto astratto non è utilizzabile in quanto si rischia di
trascurare troppi dettagli del sistema. Così anche l’impiego di una tecnica
completamente simulativa non è ritenuta la scelta più appropriata, perché
richiede di modellizzare oltre all’applicazione CPDLC anche il compor-
tamento dei protocolli di comunicazione della rete ATN. In definitiva, in
questa tesi è stato seguito un approccio misto che si colloca tra la simu-
lazione e le misure sperimentali, allo scopo di realizzare un prototipo di
applicazione CPDLC usando componenti reali della rete ATN, quest’ul-
timi forniti dall’azienda irlandese Airtel (partner OTE) specializzata in
router ATN. Questo approccio ha il vantaggio di essere ancora basato su
un modello facilitando la rappresentazione di diverse configurazioni del
sistema.
La tesi è strutturata nel modo seguente:
Nel primo capitolo sono introdotti i concetti di sistema distribuito, de-
pendability e performance, ed inoltre sono presentate le tecniche e gli stru-
menti utilizzabili per la valutazione quantitativa. Nel secondo ed nel ter-
zo capitolo sono descritte in maniera specifica l’architettura di rete ATN
e l’applicazione CPDLC. Nel quarto capitolo sono ripresi i concetti e le
metodologie presentate nel primo capitolo, per applicarle al contesto speci-
fico della valutazione quantitativa del servizio CPDLC. In particolare, sono
v
definiti l’obiettivo di studio, le quantità di interesse e la tecnica di valu-
tazione utilizzata; è anche presentato lo strumento Neko per l’analisi e la
prototipizzazione di algoritmi distribuiti. Nel quinto capitolo è descrit-
to il modello del sistema CPDLC formato dall’applicazione realizzata in
Neko e dalla rete ATN di test. Infine, nell’ultimo capitolo sono descritti
gli esperimenti per la valutazione delle quantità di interesse, analizzati e
commentati i risultati ottenuti.
vi
Capitolo 1
Valutazione di sistemi distribuiti
1.1 Sistemi distribuiti
Esistono in letteratura diverse definizioni di sistema distribuito, ognuna
delle quali è influenzata in modo più o meno forte dalla area di ricerca
di provenienza. Tanembaum, esperto di sistemi operativi, definisce un
sistema distribuito come una collezione di computers indipendenti che
appaiono agli utenti del sistema come un singolo computer [1]. Una stu-
diosa di algoritmi distribuiti come Lynch, fornisce una definizione ancora
più specifica di quella di Tanembaum, introducendo il concetto di corret-
tezza [2]. Altro esperto come Coulouris, enfatizza l’aspetto che i computer
siano collegati tra loro attraverso una rete di comunicazione [3]. Mentre
Lamport fornisce la seguente definizione:
Un sistema distribuito è quello che ti impedisce di lavorare a causa
del guasto di una macchina di cui non avevi mai sentito parlare.
Lo sviluppo del software di un sistema distribuito è un compito non
banale ed è facile commettere errori. Ad esempio, i malfunzionamen-
1
Valutazione di sistemi distribuiti
ti sono difficili da prevedere perché possono manifestarsi durante par-
ticolari interazioni tra le componenti del sistema dovute alla sovrappo-
sizione (interleaving) degli eventi. Ciò non accade in sistemi centralizzati,
dove gli eventi seguono un ordine sequenziale e una logica deterministica.
Questo problema del comportamento dei sistemi distribuiti, talvolta non
deterministico, ha portato nel corso degli ultimi anni ad un’intensa attiv-
ità di ricerca con lo scopo di fornire delle metodologie e degli strumenti
per la verifica della correttezza di questi sistemi. Nelle prime fasi dello
sviluppo di un sistema, cioé quando vengono definite le sue funzionalità,
l’aspetto della correttezza gioca un ruolo fondamentale. Successivamente,
si pongono altri interrogativi per capire quanto il sistema funziona bene
sia in situazioni normali che in presenza di guasti. Infatti, in tanti con-
testi, in particolare quelli critici, i sistemi hanno il requisito di garantire il
loro funzionamento anche in presenza di guasti. In linea generale si può
dire che i sistemi sono caratterizzati da quattro proprietà fondamentali:
Funzionalità, Dependability, Performance e Costo.
1.2 Dependability
La dependability è definita come la capacità di fornire un servizio su cui si
può fare affidamento in maniera giustificata [4]. La dependability è un propri-
età dei sistemi che comprende altri concetti importanti come l’affidabilità,
la disponibilità, la safety, etc. Questo termine nonostante sia sinonimo di
affidabilità non è da confondersi con la reliability che ha invece un preciso
significato matematico; inoltre, esso aggiunge la nozione di dipendenza
per evidenziare la crescente dipendenza della nostra società dai sistemi
informatici.
2
Valutazione di sistemi distribuiti
Il servizio fornito è una caratteristica dinamica che rappresenta il compor-
tamento del sistema percepito dall’utente tramite l’interfaccia del servizio,
ed è diverso dalla funzione, caratteristica statica, descritta invece nella
specifica del sistema.
Una trattazione sistematica della dependability consiste di tre parti fonda-
mentali: gli impedimenti, gli attributi e i mezzi per ottenerla [5].
1.2.1 Impedimenti
Un servizio è proprio quando il servizio implementa la specifica funzionale
del sistema. Un fallimento del sistema è un evento che occorre quando
il servizio fornito devia dal servizio proprio, diventando così improprio.
Un sistema può fallire sia perché non corrisponde alla sua specifica, sia
perché la sua funzione non è adeguatamente descritta. Ad alto livello,
cioé dal punto di vista dell’utente, il servizio di un sistema può essere
rappresentato attraverso un semplice diagramma di stato:
servizio
proprio
servizio
improprio
fallimento
ripristino
Figura 1.1: Gli stati di un servizio
La transizione da servizio proprio a servizio improprio indica un falli-
mento, l’altra, da servizio improprio a servizio proprio, indica il ripristino
3
Valutazione di sistemi distribuiti
del servizio. L’intervallo di tempo durante il quale il sistema è improprio
è chiamato periodo di outage del servizio. In realtà, un fallimento è la con-
seguenza percepita dall’utente di altri eventi come i guasti e gli errori.
Un guasto rimane nascosto fino alla sua attivazione, dopo di che, genera
un errore coinvolgendo una o più componenti del sistema. Successiva-
mente, l’errore può propagarsi e generare nuovi errori. Quando questi er-
rori arrivano fino all’interfaccia del servizio e provocano effetti sul servizio
offerto, in quel momento si verifica un fallimento.
Una possibile classificazione dei guasti è in base alla loro causa fenomeno-
logica. Si hanno allora guasti fisici oppure umani. Un guasto fisico è dovuto
a cause interne come i cortocircuiti, oppure esterne come le perturbazioni
elettromagnetiche e le temperature. Un guasto umano è provocato da un
sbaglio nel design del sistema, sia in fase iniziale, cioé passando dai requi-
siti all’implementazione, sia durante la definizione di procedure operative
e di manutenzione. Un guasto umano è anche causato da un’ interazione
dell’utente che viola le modalità di funzionamento previste dal sistema.
In base alla loro natura i guasti possono essere accidentali, di intento mal-
izioso e non malizioso.
I guasti sono anche classificati in base alla loro persistenza. Quando es-
si sono continui e stabili sono detti permanenti e sono provocati da difetti
fisici del sistema o da design inadeguato. Oppure sono intermittenti se si
presentano occasionalmente, ad esempio per colpa di hardware instabile.
Infine, sono chiamati transienti quei guasti dovuti a temporanee condizioni
ambientali.
In generale, un sistema non fallisce mai allo stesso modo. Anche i fal-
limenti sono classificati in base a diversi criteri. Uno dei più importanti
4
Valutazione di sistemi distribuiti
è quello rispetto alla conseguenza provocata dal fallimento. I fallimen-
ti sono così distinti in benigni, se la loro conseguenza ha lo stesso ordine
di grandezza, spesso inteso in termini di costo, del servizio offerto in as-
senza di fallimento; e in catastrofici se la loro conseguenza non è ritenuta
accettabile perché può comportare gravi danni a persone e ambiente, op-
pure avere costi troppo elevati.
Sbaglio neldesign
Difetto fisico
Hardware
instabile
Ambiente
instabile
Sbagliodellutente
Guastopermanente
Guasto
intermittente
Guasto
transiente
Errore Fallimento
Figura 1.2: La catena di impedimenti
5
Valutazione di sistemi distribuiti
1.2.2 Attributi
Gli attributi che compongono il concetto generale di dependability sono i
seguenti:
• Affidabilità (Reliability): indica la continuità del servizio offerto.
• Disponibilità (Availability): esprime la capacità di fornire un servizio
proprio.
• Manutenibilità: indica la capacità di ripristino del servizio.
• Safety: garantisce l’assenza di conseguenze catastrofiche per l’utente
e l’ambiente.
• Confidenzialità: garantisce l’assenza di diffusione non autorizzata
di informazioni.
• Integrità: garantisce l’assenza di alterazione impropria dello stato
del sistema.
L’interpretazione del significato di questi attribuiti deve essere in senso
relativo e probabilistico, e non in senso assoluto e deterministico. Quindi
a questi attributi in particolare ad affidabilità e disponibilità, si associano
delle misure in termini di probabilità [9]. L’affidabilità (Reliability) di un
sistema è la capacità di funzionare correttamente durante un intervallo di
tempo [0, t]. In altre parole, sia X la variabile casuale che rappresenta il
tempo di vita di un sistema (tempo al fallimento) e sia F la funzione di
distribuzione (CDF) della variabile X , allora l’affidabilità del sistema al
tempo t è definita dalla probabilità che il sistema sopravviva fino al tempo
t, dunque R(t) = P (X > t) = 1 − F (t) assumendo che al tempo t = 0 il
6