Implementazione di un algoritmo distribuito per l'assegnazione del traffico aereo

Universit`a degli Studi di Trieste
Dipartimento di matematica e geoscienze
Corso di Studi in Informatica
Tesi di Laurea Magistrale
Implementazione
di un algoritmo distribuito
per l’assegnazione del traffico aereo
Laureando:
Matteo Buriola
Relatore:
prof. Lorenzo Castelli
ANNO ACCADEMICO 2015 - 2016

Indice
1 Spiegazione dell’algoritmo 6
1.1 Modello teorico . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Modello matematico . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1 Assegnazione degli slot . . . . . . . . . . . . . . . . . . 7
1.2.2 Algoritmo FPFS . . . . . . . . . . . . . . . . . . . . . 10
1.2.3 Algoritmo distribuito di mercato . . . . . . . . . . . . 14
1.2.4 Calcolo dei prezzi . . . . . . . . . . . . . . . . . . . . . 15
2 Implementazione dell’algoritmo 18
2.1 Strumenti utlizzati . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Struttura delle classi . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.1 Classe Slot . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.2 Classe Sector . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.3 Classe Route . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.4 Classe Flight . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.5 Classe Utility . . . . . . . . . . . . . . . . . . . . . . . 25
2.3 Lettura e preparazione dei dati . . . . . . . . . . . . . . . . . 25
2.4 Esecuzione dell’algoritmo . . . . . . . . . . . . . . . . . . . . . 30
3 Risultati sperimentali 36
3.1 Test eﬀettuati . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2

Introduzione
La gestione del traffico aereo è un ambiente molto vasto e complesso che
presenta molteplici entità al suo interno.
Alcune hanno come obiettivo il profitto e sono in competizione tra loro,
altre invece hanno il compito di regolamentare e controllare i vari aspetti di
questo meccanismo garantendone la sicurezza e l’efficenza.
La presenza di ritardi è sempre stata un problema prioritario in quest’am-
bito, a causa della sua pesante influenza nelle prestazioni e nei costi del
servizio ed è quindi un argomento oggetto di numerosi studi e pubblicazioni.
Partendo da semplici modelli e situazioni ideali e, in seguito, analizzando
le sempre maggiori quantità di dati resi disponibili dalle autorità di controllo
si è notato che la maggior parte dei ritardi si verifica quando la richiesta di
traffico, per svariati motivi, eccede la disponibilità degli spazi aerei o degli
aereoporti.
Quando si verifica un tale sblianciamento le autorità di controllo del
traffico aereo (Air Traffic Control units, ATC) possono imporre una rego-
lamentazione per la gestione del flusso del traffico aereo (Air Traffic Flow
Management, ATFM).
Questa regolamentazione consiste nel mettere un tetto al traffico che tran-
sita nella zona interessata, forzando un ritardo nei decolli di alcuni aerei che
attenderanno cos`ı a terra per il tempo previsto.
Purtroppo gli sbilanciamenti non sono normalmente prevedibili e lasciano
un ristretto margine di tempo per provi rimedio; per facilitare le procedure
già in utlizzo, le compagnie aeree possono fornire una lista di priorità per i
loro voli in modo da ridurre le perdite.
In tali situazioni è facilmente intuibile come le compagnie aeree siano in-
teressate a pagare pur di poter ridurre questi ritardi o a ricevere dei compensi
in cambio di un aumento degli stessi.[Vossen and Ball, 2006a]
Di metodi per decidere quali e quanti voli devono subire un ritardo, e
l’ammontare dello stesso, ce ne sono svariati. Considerando che le varie com-
pagnie aeree sono in competizione tra loro l’utlizzo di una logica di mercato
per assegnare i pochi posti disponibili sembra una scelta naturale.
4

INDICE 5
In questa tesi verrà presentata l’implementazione di un particolare al-
goritmo distribuito, originariamente proposto da [Castelli et al., 2012], che
consente ai vari operatori aerei di partecipare, tramite un’asta, al processo
decisionale.
L’obiettivo è presentare un quadro completo dell’algoritmo, dalla sua for-
mulazione matematica alla sua implementazione fino al suo utlizzo in alcuni
test su dati reali.
Nel capitolo 1 saranno inizialmente spiegate le basi teoriche e le proprietà
su cui si basa, successivamente si andrà ad illustrare nel dettaglio il modello
matematico.
Nel capitolo 2 ne verrà presentata l’implementazione in ambiente Java e
Xpress-Mosel, con una spiegazione delle scelte fatte per la sua codifica.
Infine nel capitolo 3 verrano illustrati i test effettuati e i risultati speri-
mentali ottenuti.

Capitolo 1
Spiegazione dell’algoritmo
1.1 Modello teorico
Come accennato precedentemente, quando, per una qualunque causa, si ver-
ifica una riduzione della capacità dei settori aerei o degli aereporti di ge-
stire il traffico programmato le autorità di controllo impongono una regola-
mentazione del settore interessato fino alla risoluzione del problema che ha
causato questa riduzione di capacità.
Nella pratica ad ogni volo che attraversa un settore interessato dalla regola-
mentazione viene assegnata una finestra di tempo, detta slot o ATFM slot,
che si susseguono una dopo l’altra.
Questi slot vengono assegnati secondo una politica First Planned First Served
(FPFS), cioè gli slot vengono attribuiti nell’ordine in cui i voli dovrebbero
entrare nel settore; ciò potrebbe eventualmente causare un ritardo ad alcuni
voli, che verrebbe quindi scontato a terra, prima del decollo.
Per bilanciare la domanda e la disponibilità di slot e per migliorare le prestazioni
viene istituito un Network Manager, che propone e gestisce scambi di slot tra
le varie compagnie aeree, o all’interno di una stessa, col fine di minimizzare
il ritado totale causato dalla regolamentazione.
Cos`ı facendo si ottiene una gestione più flessibile delle emergenze e si in-
cludono le compagnie aeree nel processo decisionale, dando loro libertà di
scelta rispetto a quali voli privilegiare.
Siccome lo scopo delle compagnie aeree è di ottenere un profitto bisogna nec-
essariamente considerare i ritardi non come perdite di tempo ma come spese
economiche che le compagnie devono sostenere, cioè l’obbiettivo passa da
minimizzare il ritardo totale a minimizzare il costo totale causato dai ritardi.
Questo cambiamento è tutt’altro che secondario, in primo luogo perchè i costi
del ritardo sono una funzione non lineare di molte variabili: oltre al tempo
6

1.2. MODELLO MATEMATICO 7
abbiamo il tipo di aereomobile utilizzato, il numero di passeggeri, la desti-
nazione e le eventuali coincidenze, ecc. . . , che contribuiranno sicuramente a
modificare le assegnazioni finali.
In secondo luogo perchè molti di questi fattori sono noti solo alle rispettive
compagnie aeree, le quali sono a dir poco restie a rendere pubblici questi
parametri in un ambiente di mercato.
Si è quindi venuto a creare un mercato tra le varie compagnie aeree in cui
esse cercano di vendere gli slot a loro assegnati che causano un ritardo, e
quindi un costo, eccessivo e, nello stesso tempo, acquistare slot più vantag-
giosi per i loro voli, il tutto sotto la gestione del Network Manager che funge
da garante e intermediario, dopo aver generato l’assegnazione iniziale di slot
che è la base delle trattative. Per fare in modo che le compagnie aeree siano
interessate a partecipare a questi scambi è neccassario fornire delle garanzie
che vengono date sotto forma di proprietà possedute da questo meccanismo
di mercato.
• Razionalità Individuale (Individual Rationality, IR) : garantisce che
ogni partecipante agli scambi avrà un guadagno positivo o, al limite,
nullo rispetto a qualcuno che non partecipa.
• Budget Bilanciato (Budget Balanced, BB) : garantisce che il sistema
non ha bisogni di sussidi esterni per funzionare, ma genera soltanto una
redistribuzione della ricchezza interna.
Abbiamo quindi un meccanismo di mercato con le relative proprietà in
cui le compagnie aeree, per ogni loro volo, necessitano di risorse limitate, gli
slot, in un preciso periodo di tempo, determinato dalla rotta del volo; questo
tipo di problema può essere modellizzato tramite un algoritmo di scambio
combinatorio, la cui complessità è NP-Hard.
1.2 Modello matematico
1.2.1 Assegnazione degli slot
In questa sezione mostreremo come il problema dell’allocazione degli slot può
essere formulato matematicamente nel caso in cui venga risolto centralmente
dal Network Manager.
I modelli qui presentati verrano poi utlizzati successivamente come punto di
partenza per la spiegazione dell’algoritmo distribuito.

8 CAPITOLO 1. SPIEGAZIONE DELL’ALGORITMO
Siano F = {1,. . . ,F } un insieme di voli e S = {1,. . . ,S } un insieme di set-
tori ai quali è applicata la regolamentazione. Una rotta per il volo f è intesa
come una successione di elementi di S che f deve attraversare per giungere
a destinazione; formalmente si definisce Sf un sottoinsieme ordinato di S i
cui elementi s ∈ Sf sono caratterizzati dal tempo previsto di entrata Es
f di f
nel settore e sono tali che la differenza Es
f − Es’
f definisce il tempo di volo di
f attraverso s per ogni coppia consecutiva di elementi s, s ∈ Sf .
Ogni risorsa s ∈ S ha una capacità limitata a Ks entrate all’ora, dal mo-
mento di inizio della regolamentazione Is alla sua fine Us e possiede una lista
di assegnazione Ls composta da Ns = Ks
Us−Is
60
elementi; ognuno di questi
elementi è una finestra di tempo, o slot, e può essere assegnata solamente ad
un volo, l’insieme di tutti gli slot è indicato con L = s∈S Ls. Denotiamo
il generico js-esimo slot in Ls come l’intervallo di tempo [Ijs , Ujs ], indicando
con Ijs è l’orario di apertura dello slot e Ujs quello di chiusura con
Ijs = Is+ (js − 1) ·
60
Ks
(1.1)
Ujs = Ijs+1 − 1 (1.2)
dove INs+1 = Us + 1.
Una serie qf = [r1, . . . , r|Sf |] di slot deve essere assegnata ad ogni volo f,
dove ri è lo slot riferito all’ i-esimo elemento di Sf per permettere al volo f
di giungere a destinazione. Siccome assumiamo che i voli non possano essere
anticipati, uno slot ri può essere assegnato al volo f solo se termina dopo
Ei
f , cioè Ei
f ≤ Uri
, ∀ri ∈ qf , i ∈ Sf .
Una serie qf causa un ritardo d
qf
f , anche nullo, al volo f; tale ritardo è
strettamente positivo se e solo se Ei
f < Iri
per alcuni ri ∈ qf : nello specifico
d
fq
f = max
i∈Sf
{max(Iri
− Ei
f , 0)} (1.3)
Indichiamo con C(f, qf ) il costo non negativo causato dal ritardo d
qf
f .
Diciamo che una serie qf è accettabile per il volo f se è vuota, e in tal caso
il volo f è cancellato, o soddisfa le seguenti condizioni:
1. Esiste uno slot ri per ogni i ∈ Sf con Ei
f ≤ Uri
2. Gli orari di apertura e chiusura degli slot per ogni coppia i, j di settori
consecutivi in Sf sono compatibili con il tempo di volo Ej
f − Ei
f
3. Il ritardo d
qf
f è vincolato tra 0 e un valore massimo, indicato con
MaxDelf , oltre il quale il costo diventa eccessivo e il volo viene can-
cellato.

Per semplicità chiameremo rotta del volo f una serie qf accettabile per il
suddetto volo e indicheremo con Qf l’insieme di tutte le rotte di f.
Analogamente diciamo che un vettore di rotte { q1, . . . , qF } è accettabile se,
per ogni f ∈ F, qf è accettabile per f e, per tutti gli f e f ∈ F, qf ∩ qf = ∅,
cioè nessuno slot è utlizzato da più voli.
Possiamo quindi formulare il problema dell’assegnazione degli slot come segue:
ZIP = min
f∈F q∈Qf
C(f, q)x(f, q) (1.4a)
f∈F q∈Qf :q r
x(f, q) ≤ 1 ∀r ∈ L (1.4b)
q∈Qf
x(f, q) = 1 ∀f ∈ F (1.4c)
x(f, q) ∈ {0, 1} ∀f ∈ F, q ∈ Qf (1.4d)
Nel problema cos`ı formulato la generica variabile decisionale binaria x(f, q)
è uguale a uno se il volo f riceve la q-esima rotta del suo insieme Qf , zero
altrimenti.
L’obbiettivo è di minimizzare il costo totale delle assegnazioni; i vincoli im-
pongono che ogni slot sia assegnato al massimo ad un volo e che ogni volo
riceva una rotta tra quelle a sua disposizione.
Il problema dell’assegnazione degli slot cos`ı formulato è NP-Hard, per la di-
mostrazione vedere Castelli et al. (2012)
In questo contesto possiamo notare come il problema possa essere interpre-
tato come un’asta con offerte in busta chiusa, dove ogni volo comunica i suoi
costi C(f, q) al banditore, in questo caso il Network Manager, che risove il
problema centralmente calcolando i prezzi delle rotte P = {p(q∗
1), . . . , p(q∗
F )}
e poi li assegna ai voli.
Questo meccanismo tuttavia non soddisfa le proprietà precedentemente enun-
ciate che il nostro sistema di mercato deve avere; per ovviare a ciò si procede
in due passi:
1. si assegna, senza nessun costo, un insieme di rotte A = {a1, . . . , aF } ai
voli, seguendo lo standard FPFS
2. si permette ai voli di scambiare la propria rotta con altri voli o con rotte
non ancora assegnate finchè non si raggiunge un’assegnazione ottima
degli slot X∗
. A questo punto ogni volo per cui af = q∗
f paga il prezzo
p(q∗
f ) per la sua rotta ottimale e riceve p(af ) come rimborso per la
restituzione della rotta af .

Con questo procedimento ogni volo è potenzialmente un acquirente e un
venditore di slot che cerca di aumentare il suo profitto.
Infatti, alla fine del passo 1, ogni volo ha già una rotta che è una soluzione
accettabile per il problema ma non è detto che sia anche ottima.
Alla fine del passo 2, in seguito allo scambio e∗
di af con q∗
f , il profitto di ogni
volo subisce una variazione ∆u(f, e∗
) = [C(f, af )−C(f, q∗
f )]−[p(q∗
f )−p(af )] =
−C(f, e∗
f )−p(e∗
f ). Con queste modifiche soddisfiamo le proprietà di IR e BB
requisito del sistema di mercato senza modificare il risultato finale, per la
dimostrazione vedere ancora Castelli et al.(2012)
Infatti i due problemi sono equivalenti in termini di allocazione degli slot,
come si può vedere dalla seguente formulazione:
ZIP−E = max
f∈F q∈Qf
V (f, q)x(f, q) (1.5a)
f∈F q∈Qf :q r
x(f, q) ≤ 1 ∀r ∈ L (1.5b)
q∈Qf
x(f, q) = 1 ∀f ∈ F (1.5c)
x(f, q) ∈ {0, 1} ∀f ∈ F, q ∈ Qf (1.5d)
In questo problema la generica variabile decisionale binaria x(f, q) è
uguale a uno se il volo f ottiene la rotta q-esima in cambio della rotta af
assegnatagli inizialmente, zero altrimenti, e V (f, q) = C(f, af ) − C(f, q) il
guadagno ottenuto da f a seguito dello scambio.
I due problemi sono equivalenti in quanto condividono gli stessi vincoli e la
funzione obiettivo la stessa a meno di un termine costante.
1.2.2 Algoritmo FPFS
Prima di procedere con l’algoritmo distribuito è necessario fare una digres-
sione per spiegare in dettaglio il meccanismo di scelta delle rotte A = {a1, . . . , aF }
che vangono assegnate ai voli al passo 1. L’algoritmo Firs Planned First
Served (FPFS), letteralmente primo programmato primo servito, serve ad
avere un’assegnazione iniziale, cioè un punto di partenza, per effettuare gli
scambi; gli slot vengono cos`ı assegnati ai voli senza alcun costo per questi,
i quali possono comunque accontentarsi della rotta ricevuta senza dover per
forza effettuare degli scambi in quanto essa è accettabile per loro.
Prendiamo il caso più semplice della regolamentazione applicata a un solo
settore:

Volo Orario d’ingresso
ASL642-LYBE-LROP 11:45:00
ELB125-LGTS-UKLL 9:30:00
LOT6A-LBSF-EPWA 11:35:00
ROT422-LEBL-LROP 13:20:00
THY33-LTBA-KIAH 12:00:00
Slot Orario d’inizio
1 9:00:00
2 10:00:00
3 11:00:00
4 12:00:00
5 13:00:00
6 14:00:00
Gli slot verranno assegnati ai voli secondo il loro orario d’ingresso previsto
nel settore, quindi ogni volo otterrà il primo slot utile non ancora assegnato:
Slot Volo Ritardo
1 ELB125-LGTS-UKLL 0
2 - -
3 LOT6AK-LBSF-EPWA 0
4 ASL642-LYBE-LROP 15
5 THY33-LTBA-KIAH 60
6 ROT422-LEBL-LROP 40
Come si può notare lo slot 2 non è stato assegnato perchè non c’erano voli
che ne potevano usufruire, conseguanza del fatto che i voli non possono essere
anticipati ma solo ritardati. Nel caso in cui non ci siano slot sufficenti, i voli
esclusi attraverseranno il settore alla fine della regolamentazione o veranno
cancellati, a seconda di quale sia l’opzione più conveniente per la compagnia
aerea che lo gestisce.
Nel caso in cui ci siano più settori a cui si applica la regolamentazione si
procede in due passi:
1. Si esegue la procedura precedente per ogni settore indipendentemente
dagli altri.
2. Si decide un ordine di priorità per tutti i voli coinvolti.

3. Se un volo attraversa più settori si sceglie, tra tutti gli slot a lui asseg-
nati, quello che causa il ritardo maggiore, cioè viene presa la rotta più
penalizzante, e si modificano gli altri suoi slot per adeguarsi a questa
rotta.
4. Seguendo l’ordine del passo 2, ad ogni volo viene assegnata definiti-
vamente la rotta scelta al passo 3; se uno slot dovesse risultare già
occupato gli viene assegnato il migliore tra quelli successivi ed ancora
disponibili, con conseguente modifica della rotta e del ritardo.
Vediamo un esmpio: supponiamo di aver già eseguito il primo passo e
di avere già un’assegnazione parziale per ogni settore; osserviamo il volo
ELB125-LGTS-UKLL
Settore 1
Slot Volo Ritardo
4 - -
6 - -
Settore 2
Slot Volo Ritardo
1 PGT873-LTFJ-LFPO 0
2 BAW152-OLBA-EGLL 0
6 - -
Settore 3
Slot Volo Ritardo
1 THY33-LTBA-KIAH 0
2 SWR181T-LSZH-LROP 10
5 - -
Il caso peggiore si ha nel settore 2, dove gli è stato assegnato lo slot 5
con 45 minuti di ritardo, questa è dunque la rotta che più lo penalizza e che

viene quindi assegnatagli anche negli altri settori, facendolo quindi spostare
nello slot 5 anche dalle parti.
Supponendo che il volo in esame abbia priorità maggiore, ciò causa lo slitta-
mento, nel settore 1, del volo ROT422-LEBL-LROP allo slot 6 con eventuale
accumolo di ritardo.
L’ordine di priorità stabilito al passo 2 è necessario proprio per dirimere sim-
ili situazioni.
Settore 1
Slot Volo Ritardo
1 - -
2 - -
Settore 2
Slot Volo Ritardo
1 PGT873-LTFJ-LFPO 0
2 BAW152-OLBA-EGLL 0
6 - -
Settore 3
Slot Volo Ritardo
1 THY33-LTBA-KIAH 0
2 SWR181T-LSZH-LROP 10
3 - -

1.2.3 Algoritmo distribuito di mercato
La risoluzione del problema (1.5) può risultare impraticabile, principalmente
perchè richieda la disponibilità da parte delle compagnie aeree a rivelare in-
formazioni private riguardo i costi dei ritardi e perchè il peso computazionale
dell’algoritmo ricade completamente sul Network Manger che deve quindi ri-
solvere da solo un problema NP-Hard.
Per risolvere questi problemi viene proposto un algoritmo distribuito che al-
terna una fase di calcolo dei prezzi, in cui il Network Manager determina
il prezzo degli slot sulla base della domanda, a una fase di ottimizzazione
locale, in cui le compagnie aeree decidono quali rotte scambiare sulla base
dei loro costi e dei loro bisogni.
Per fare ciò si può rilassare il secondo vincolo (1.4b) ottenendo cos`ı la cor-
rispettiva formulazione Lagrangiana del problema (1.5)
ZLRLP−E(λ) = max
f∈F q∈Qf
V (f, q)x(f, q) + (1.6a)
r∈L
λr(1 −
f∈F q∈Qf :q r
x(f, q))
q∈Qf
x(f, q) = 1 ∀f ∈ F (1.6b)
x(f, q) ∈ {0, 1} ∀f ∈ F, q ∈ Qf (1.6c)
Il modello cos`ı formulato è separabile in F sottoproblemi, uno per ogni
volo.
Le rispettive compagnie aeree devono quindo risolvere localmente il seguente
problema lineare che richiede un tempo polinomiale, dati i valori λr.
ZLRLP−E(f, λ) = max
q∈Qf
[V (f, q) −
r∈q
λr +
r∈af
λr]x(f, q) (1.7a)
q∈Qf
x(f, q) = 1 (1.7b)
x(f, q) ≥ 0 ∀q ∈ Qf (1.7c)
Data la struttura del problema e delle variabili decisionali, la soluzione
ottima è facilmente indivuduabile per ispezione

ZLRLP−E(f, λ) = max
q∈Qf
[V (f, q) −
r∈q
λr +
r∈af
λr] (1.8)
Possiamo interpretare r∈q λr e r∈af
λr rispettivamente come il prezzo
della rotta q e della rotta af , essendo λr i prezzi dei singli slot.
Da questa prospettiva possiamo vedere la funzione obiettivo come la ricerca
di ogni volo f di massimizzare la differenza tra il guadagno nello scambiare
la rotta iniziale af con la rotta q e il costo di questa operazione; infatti il
volo deve pagare r∈q λr per ottenere q e riceve in cambio r∈af
λr per la
rotta af che libera.
Il Network Manager deve quindi cercare i prezzi λ che risolvono il seguente
problema duale:
ZLRLP−E = min
λ
ZLRLP−E(λ) (1.9a)
λ ≥ 0 (1.9b)
I prezzi λr sono calcolati dal Network Manager sulla base dell’eccesso di
domanda per il rispettivo slot e sono successivamente comunicati alle com-
pagnie aeree, le quali di conseguenza modificano la domada di slot in accordo
con i nuovi prezzi.
1.2.4 Calcolo dei prezzi
Vediamo ora un algorimo subgradiente per il calcoli dei prezzi λr, per ogni
r ∈ L
λt+1
r = max(0, λt
r − Φt
· SGt
r) (1.10)
SGt
r = 1 −
f∈F,q∈Qf :q r
xt
(f, q) (1.11)
dove xt
è il vettore soluzione al problema (1.6) all’iterazione t in accordo
con i prezzi λt
, SGt
r è un subgradiente di ZLRLP−E(λ) e Φt
è un passo
positivo scelto all’iterazione t. Come si nota della formula (1.11) il termine
SGt
r è calcolato sulla base della rotte scelte dai singli voli, quindi tante più
saranno le richieste per uno slot particolare tanto più SGt
r sarà grande, in
valore assoluto, causando un’aumento del prezzo, al contrario, un’assenza di
domanda causa la diminuzione del prezzo.
Scegliendo appropriatamente Φt
tale che Φt
→ 0 e t
i=1 Φt
→ ∞ per t → ∞,

la procedura converge a una soluzione che minimizza ZLRLP−E(λ).
Una formula per Φt
che si è rivelata efficace è la seguente:
Φt
=
θt
(ZLRLP−E(λt
) − Z∗
IP−E)
s∈S r∈Ls
(1 − f∈F q∈Qf :q r xt(f, q))2
(1.12)
dove θt
= 2 alla prima iterazione e viene successivamente dimezzato quando
ZLRLP−E(λt
) non diminuisce in un certo numero di passi, si veda, ad esem-
pio, Fisher (1985).
Nel nostro caso il Network Manager non conosce i valori di V (f, q) quindi
non può calcolare ne ZLRLP−E(λt
) ne Z∗
IP−E; modifichiamo quindi la formula
nella seguente:
Φt
=
θt
(UBZ∗
− ZLBIP−E)
s∈S r∈Ls
(1 − f∈F q∈Qf :q r xt(f, q))2
(1.13)
dove UBZ∗
è un limite superiore del valore ottimo degli scambi che è tenuto
costante durante tutte le iterazioni, ed è funzione della cardinalità degli in-
siemi F e S.
Al contrario ZLBIP−E è un limite inferiore del valore ottimo degli scambi
che viene perfezionato ad ogni iterazione.
Per ogni f ∈ F e q ∈ Qf , all’iterazione t il Network Manager può calcolare
per ogni rotta q richiesta dal volo f un limite inferiore LBt
(f, q) sull’esatto
valore V (f, q) per lo scambio; per fare ciò definiamo
p(q, af , λt
) = r∈q λt
r − r∈af
λt
r se xt
(f, q) = 1
−∞ altrimenti
(1.14)
dove p(q, af , λt
) rappresenta l’ammontare che il volo f accetta di pagare per
la rotta q ai prezzi fissati dal Network Manager all’itrerazione t; siccome
ZLRLP−E(f, λ) ≥ 0 segue che p(q, af , λt
) ≤ V (f, q).
Infine definiamo Qf (q) = {q ∈ Qf {q} : dq
f ≥ dq
f } l’insieme delle rotte che
inducono un ritardo al volo f non inferiore a quello causato da q.
In questo caso V (f, q) ≤ V (f, q); quindi il limite inferiore desiderato può
essere calcolato ricorsivamente come
LBt
(f, q) = max{p(q, af , λt
), LBt−1
(f, q), max
q∈Qf (q)
{LBt
(f, q)}} (1.15)

inizializzato con
LB0
(f, q) =
0 se q ∈ Q(af ) ∪ {af }
−∞ altrimenti
(1.16)
Si noti che LBt
(f, q) ≥ LBt
(f, q) per ogni q ∈ Q(q) in quanto assumiamo
che il costo del ritardo sia non negativo e non descrescente.
Il Network Manager può quindi risolvere il seguente problema
ZLBt
IP−E = max
f∈F q∈Qf
LBt
(f, q)x(f, q) (1.17a)
f∈F q∈Qf :q r
x(f, q) ≤ 1 ∀r ∈ L (1.17b)
q∈Qf
x(f, q) = 1 ∀f ∈ F (1.17c)
x(f, q) ∈ {0, 1} ∀f ∈ F, q ∈ Qf (1.17d)
Questo problema è ancora NP-Hard, tuttavia il carico computazionale
richiesto è minore di quello associato al problema iniziale in quanto possiede
alcune caratteristiche che permettono di ridurne il peso: per esempio si può
porre subito x(f, q) = 0 per tutti gli f ∈ F e per tutti le q ∈ Qf tali che
LBt
(f, q) = −∞.

Capitolo 2
Implementazione dell’algoritmo
2.1 Strumenti utlizzati
Dovendo scegliere in che modo implementare l’algoritmo era stato deciso, in
un primo tempo, di utilizzare una nuova libreria fornita da Google che offriva
un insieme di software per risolvere problemi di ottimizzazione.
La libreria si chiama Google Optimization Tools e contiene e contiene al-
goritmi per grafi, per ottimizzazioni lineari e risolutori per programmazione
intera.
L’obiettivo ideale era di utilizzare questa libreria per sfruttare, attraverso
la connessione internet, le risorse messe a disposizione da Google per la
risoluzione delle simulazioni dell’algoritmo.
Cos`ı facendo la quantità di dati elaborabili per ogni test sarebbe stata molto
superiore a quella di un computer personale.
Tuttavia si è notato che la documentazione non era particolarmente chiara
ma, anzi, faceva riferimento a diverse modalità di utlizzo, ognuna con la sue
particolari funzioni e sintassi.
Quella da noi esaminata prevedeva il download di una libreria per il solo
utlizzo locale, sfuttando le risorse della macchina su cui operava.
Tramite il servizio Google Apps, un’altra permetteva invece l’utilizzo delle
funzionalità on-line e, dietro pagamento, delle risorse di memoria e calcolo
di Google.
Avendo già a disposizione programmi per la risoluzione locale dei problemi e
non avendo una necessità di una tale potenza di calcolo si è deciso di utlizzare
altri strumenti.
Per quanto riguarda la parte di implementazione dei problemi di ottimiz-
zazione è stato quindi utilizzato il linguaggio di programmazione Mosel in
ambiente FICO R Xpress Optimization.
18

2.2. STRUTTURA DELLE CLASSI 19
Tra i diversi linguaggi di programmazione per cui sono disponibili le librerie
di interfaccia con Xpress si è scelto di utlizzare Java versione 7 nell’ambiente
di sviluppo Eclipse, per la maggiore conoscenza ed esperienza da me posse-
duta.
Si è inoltre utilizzato il programma pgAdmin III per recuperare dal database
dell’università tutti i dati necessari ai test.
2.2 Struttura delle classi
Sfuttando il paradigna della programmazione a oggetti da Java ho creato
delle classi per modellizzare tutte le entità che compaiono nell’algoritmo:
slot, settori, rotte e voli.
2.2.1 Classe Slot
La classe Slot serve a modellizzare le finestre di tempo che vengono assegnate
ai voli; è una semplice classe con pochi campi e metodi usata come primo
mattone per costruire la struttura della altre classi.
Campi della classe Slot:
• slotTime: orario di inizio dello slot
• number: numero dello slot
• isUsed: variabile booleana per indicare se lo slot è stato utlizzato
nell’assegnazione FPFS, inizializzata con false
Metodi della classe Slot:
• Costruttore: genera un nuovo oggetto della classe, ha come argomenti
l’orario d’inizio e il numero.
• setIsUsed: serve a modificare il campo isUsed.
• Metodi get: servono a leggere i campi della classe siccome questi sono
definiti privati.

20 CAPITOLO 2. IMPLEMENTAZIONE DELL’ALGORITMO
Listing 2.1: Estratto del codice per la classe Slot§
1 public class Slot {
2
3 private final GregorianCalendar slotTime;
4 private final int number;
5 private boolean isUsed;
6
7 // Costruttore
8 public Slot( GregorianCalendar startTime ,int number ){
9 this.slotTime = startTime;
10 this.number = number;
11 isUsed = false;
12 }
13 public void setIsUsed(boolean isUsed ){
14 this.isUsed = isUsed;
15 }
¦ ¥
2.2.2 Classe Sector
La classe Sector serve a modellizzare i settori in cui è diviso lo spazio aereo
e a cui viene applicata la regolamentazione; è un’altra semplice classe che
serve a generare gli slot disponibili per il settore che rappresenta.
Campi della classe Sector:
• flightPerHour: rappresenta la capacità oraria del settore imposta dalla
regolamentazione.
• slot: un vettore che contiene gli slot disponibili per questo settore.
• flightNumber: numero di voli che attraversano questo settore
Metodi della classe Sector:
• Costruttore: genera un nuovo oggetto della classe, ha come argomento
la capacità oraria del settore e il suo ID. Genera inoltre gli slot del
settore basandosi sulla suddetta capacità e la durata della regolamen-
tazione.
• addFlight: incrementa il numero di voli del settore
definiti privati.
• compareTo: serve per ordinare i vari settori sulla base del numero di
slot di ognuno

Listing 2.2: Estratto del codice per la classe Sector§
1 public class Sector implements Comparable <Sector >{
2
3 private final String sectorID;
4 private final double flightPerHour ;
5 private final Slot [] slot;
6 private int flightNumber ;
7
8 // Costruttore
9 public Sector(double sectorCapacity , String sectorID ){
10 flightPerHour = sectorCapacity ;
11 this.sectorID = sectorID;
12 int regulationTime = DURATION_M + DURATION_H *60;
13 int slotNumber = (int) Math.floor( flightPerHour * regulationTime /60);
14 double slotDurationM = (double) regulationTime /slotNumber;
15 int slotDurationS = (int) Math.round (60 * ( slotDurationM - (int) slotDurationM ));
16 slot = new Slot[slotNumber ];
17 slot [0]= new Slot(new GregorianCalendar (YEAR ,MOUNTH ,DAY ,HOUR ,MINUTE ,0) ,0);
18 for (int r=1; r<slotNumber; r++){
19 GregorianCalendar c = new GregorianCalendar (YEAR ,MOUNTH ,DAY ,HOUR ,MINUTE +
20 +( slotDurationM * r), slotDurationS * r);
21 slot[r] = new Slot(c,r);
22 }
23 }
24
25 public void addFlight (){
26 flightNumber ++;
27 }
28
29 // Funzione per l’ordinamento dei settori secondo il numero di slot
30 @Override
31 public int compareTo (Sector s){
32 if(s. getSlotNumber () > slot.length ){
33 return -1;
34 } else {
35 return 1;
36 }
37 }
¦ ¥
2.2.3 Classe Route
La classe Route serve a modellizzare le rotte che possono essere assegnate ai
voli; per facilitare l’implementazione esiste una corrispondenza univoca tra
rotte e voli, cio`e le rotte disponibili per un volo lo sono solo per quello e non
per altri voli.
Campi della classe Route:
• delay: il ritardo causato da questa rotta
• cost: il costo causato dal ritardo di questa rotta
• usedSlot: tabella che memorizza i settori attravarsati dalla rotta con i
rispettivi slot utlizzati
Metodi della classe Route:
il ritardo, il costo per minuto del volo e gli orari di ingresso del volo nei
vari settori; in funzione di questi parametri calcola il costo totale della
rotta e trova quali slot la rotta andr`a ad occupare nei vari settori.

deﬁniti privati.
• compareTo: serve per ordinare le varie rotte sulla base del loro ritardo.
Listing 2.3: Estratto del codice per la classe Route§
1 public class Route implements Comparable <Route >{
2
3 private final int delay;
4 private final double cost;
5 private final TreeMap <String ,Slot > usedSlot = new TreeMap <String ,Slot > ();
6
7 // Costruttore
8 public Route (int d, double c, TreeMap <String ,Calendar > entryTimes ){
9 delay=d;
10 if (delay == 0){
11 cost = 0;
12 }
13 else {
14 cost = delay*c;
15 }
16 Iterator <String > it = entryTimes.keySet (). iterator ();
17 while(it.hasNext ()){
18 String id = it.next ();
19 Calendar time = ( GregorianCalendar ) entryTimes.get(id). clone ();
20 time.add(Calendar.MINUTE , delay );
21 if (time.after(END_TIME )) continue;
22 for (int j=0; j<SECTOR.get(id). getSlotNumber (); j++ ){
23 Slot s = SECTOR.get(id). getSlot(j);
24 if(time.after(s. getSlotTime ()))
25 usedSlot.put(id , s);
26 }
27 }
28 }
29
30 // Costruttore
31 public Route (int d, double c){
32 delay = d;
33 if (delay == 0){
34 cost = 0;
35 }
36 else {
37 cost = delay*c;
38 }
39 }
40
41 // Funzione per l’ordinamento delle rotte secondo il ritardo
42 @Override
43 public int compareTo (Route r){
44 if(r.getDelay () > delay ){
45 return -1;
46 } else {
47 return 1;
48 }
49 }
¦ ¥

2.2.4 Classe Flight
La classe Flight serve a modellizzare i voli con tutte le loro proprietà, genera
inoltre le rotte disponibili per il volo stesso.
Campi della classe Flight:
• flightID: ID univoco del volo
• flightType: codice che rappresenta il tipo di aeromobile usato per il
volo, ad ogni tipo è associato un costo per il ritardo.
• cost: costo del ritardo fornito in al minuto
• startTime: orario di partenza del volo
• entryTimes: orari di entrata del volo nei vari settori
• lowerEntryTime: il minore tra gli orari di entrata nei settori, serve per
la generazione delle rotte
• routes: lista di tutte le rotte disponibili per il volo
• fpfs: rotta assegnata al volo dalla procedura FPFS
Metodi della classe Flight:
l’ID del volo, il suo tipo e l’orario di partenza, associa il tipo con il
costo del ritardo.
• addSector: aggiunge un settore, e il rispettivo orario di ingresso, a quelli
attraversati dall’aereo.
• createRoutes: genera le rotte per il volo.
• setFpfs: imposta la rotta fornita dall’algoritmo FPFS.
definiti privati.
• compareTo: serve per ordinare i vari voli sulla base dell’orario di parten-
za; l’ordinamento è necessario per evitare conflitti tra i voli durante
l’assegnazione FPFS.

Listing 2.4: Estratto del codice per la classe Flight§
1 public class Flight implements Comparable <Flight >{
2
3 private final String flightID;
4 private final String flightType;
5 private final Calendar startTime;
6 private final double cost;
7 private final TreeMap <String ,Calendar > entryTimes;
8 private final TreeSet <Route > routes;
9 private Calendar lowerEntryTime ;
10 private Route fpfs;
11
12 // Costruttore
13 public Flight (String flightID , String flightType , Calendar startTime ){
14 entryTimes = new TreeMap <String ,Calendar > ();
15 routes = new TreeSet <Route > ();
16 this.flightID = flightID;
17 this.flightType = flightType;
18 this.startTime = startTime;
19 switch(flightType ){
20 case "B733": cost = 12.5;
21 break;
22 .....
23 default: cost = 5.4;
24 break;
25 }
26 }
27
28 // Funzione per aggiungere un settore a quelli attraversati dal volo
29 public void addSector (String sectorId , Calendar entry ){
30 if (! entryTimes.containsKey(sectorId ))
31 entryTimes.put(sectorId , entry );
32 if (entry.before( lowerEntryTime ) || lowerEntryTime == null )
33 lowerEntryTime = entryTimes.get(sectorId );
34 }
35
36 // Funzione per creare le rotte del volo
37 public int createRoutes (){
38 int routeNumber = 0;
39 int delay = 0;
40 Calendar tempEntryTime = ( GregorianCalendar ) lowerEntryTime .clone ();
41 while (! tempEntryTime .after(END_TIME )){
42 Route route = new Route(delay , cost , entryTimes );
43 routes.add(route );
44 routeNumber ++;
45 delay = delay + DELAY_INCREMENT ;
46 tempEntryTime .add(Calendar.MINUTE , DELAY_INCREMENT );
47 }
48 int end = END_TIME.get(Calendar. HOUR_OF_DAY )*3600 +
49 + END_TIME.get(Calendar.MINUTE )*60 +
50 + END_TIME.get(Calendar.SECOND );
51 int start = lowerEntryTime .get(Calendar.HOUR_OF_DAY )*3600 +
52 + lowerEntryTime .get(Calendar.MINUTE )*60 +
53 + lowerEntryTime .get(Calendar.SECOND );
54 delay = (( end - start )/60 ) +1;
55 Route r = new Route(delay , cost );
56 routes.add(r);
57 routeNumber ++;
58 return routeNumber;
59 }
60
61 // Funzione per l’ordinamento dei voli
62 @Override
63 public int compareTo (Flight f){
64 if( f. getStartTime (). after(this. getStartTime ())){
65 return -1;
66 } else {
67 return 1;
68 }
69 }
¦ ¥

2.3. LETTURA E PREPARAZIONE DEI DATI 25
2.2.5 Classe Utility
Classe di supporto che contiene numerose funzioni di uso comune non com-
prese nelle librerie utlizzate; la descrizione dei metodi sarà presentata per
gruppi, per evitare ripetizioni.
Metodi della classe Utility:
• quickSort: efficente algoritmo per l’ordinamento di vettori.
• metodi maxValue: servono per la ricerca del valore massimo tra quelli
forniti in argomento.
• metodi initialize: servono per inizializzare con tutti zero le matrici o i
vettori.
• metodi show: servono per visualiizare a schermo le matrici o i vettori.
• metodi toLine: servono per trasformare le matrici in vettori ordinati,
necessari per la comunicazione di dati all’ambiente Xpress
2.3 Lettura e preparazione dei dati
Il programma inizia con la definizione di alcune costanti necessarie al suo
svolgimento, come la data e la durata della regolamentazione, il nome dei
settori e la loro capacità oraria Ks e i nomi dei file per l’input e l’output.
Vengono inoltre definite le strutture dati per la memorizzazione dei voli e dei
settori e le variabili globali.
Listing 2.5: Definizione delle costanti globali per uno dei test§
14 public static final String INPUT_FILE_NAME = "test.dat";
15 public static final String OUTPUT_FILE_NAME = "out.dat";
16 public static final int SECTOR_NUMBER = 4;
17 public static final String [] SECTOR_NAMES = {"LRBBARG1","LRBBARG2","LRBBARG6","LRBBARG7"};
18 public static final double [] SECTOR_CAPACITY = {5 ,5 ,5 ,5};
19 public static final int YEAR = 2014;
20 public static final int MOUNTH = Calendar.SEPTEMBER;
21 public static final int DAY = 12;
22 public static final int HOUR = 7;
23 public static final int MINUTE = 0;
24 public static final int DURATION_H = 2;
25 public static final int DURATION_M = 20;
26 public static final Calendar END_TIME = new GregorianCalendar (
27 YEAR ,MOUNTH ,DAY ,HOUR+DURATION_H ,MINUTE+DURATION_M ,0);
28 public static final int DELAY_INCREMENT = 15;
29 public static final int ITERATION_LIMIT = 100;
30 public static final double STEP_LIMIT = 0.3;
31 public static final TreeSet <Flight > FLIGHTS = new TreeSet <Flight > ();
32 public static final TreeMap <String ,Sector > SECTOR = new TreeMap <String ,Sector > ();
33 public static int totalRoutes;
34 public static int totalFlights ;
35 public static int maxSlots;
¦ ¥
Per ogni settore viene quindi creata un’istanza della classe apposita in-
sieme a tutti gli slot di quel settore, secondo l’equazione (1.1).

Siccome i settori possono avere una capacità oraria diversa tra loro, ne con-
segue che anche il numero di slot di ciascuno non sarà lo stesso.
Il maggiore tra questi numeri viene salvato nella variabile maxSlots, neces-
saria in seguito. Gli oggetti cos`ı creati vengono memorizzati in una struttura
dati definita dalla classe TreeMap, chiamata SECTORS, assimilabile ad una
tabella ordinata, che mette in relazione il nome del settore con l’oggetto che
lo rappresenta.
Si passa poi a leggere i dati dei voli, precedentemente recuperati dal database
tramite il programma pgAdmin III ed esportati in un file di testo.
Su ogni riga del file vengono riportati, nell’ordine: ID del volo, orario di
partenza, codice del tipo di aereomobile utlizzato, ID del settore e orario di
entrata in quest’ultimo.
Per ogni volo ci possono quindi essere più righe, una per ogni settore che
attraversa.
Listing 2.6: Estratto di un file di input§
1 FHY773 -LTAI -LRCL ;06:08:00; A320;LRBBARG6 ;07:14:00
2 THY1UM -LROP -LTBA ;07:24:00; B738;LRBBARG1 ;07:29:24
3 LLP8440 -LBBG -EPKK ;07:30:00; A320;LRBBARG2 ;07:47:00
6 TSO9446 -LBWN -ULLI ;08:10:00; B735;LRBBARG1 ;08:22:36
7 TSO9446 -LBWN -ULLI ;08:10:00; B735;LRBBARG2 ;08:24:30
8 RCH966 -UGTB -LROP ;05:10:00; C130;LRBBARG1 ;08:04:11
9 LOT7508 -LBBG -EPWR ;07:35:00; B738;LRBBARG6 ;07:51:47
10 LOT7508 -LBBG -EPWR ;07:35:00; B738;LRBBARG7 ;07:52:42
11 ELY574 -LROP -LLBG ;07:54:00; B739;LRBBARG1 ;08:01:18
12 BUC5675 -LBWN -EPKT ;08:20:00; MD82;LRBBARG1 ;08:33:00
15 .....
¦ ¥
Tramite la funzione readData viene letto il file ed effettuato il parsing di
ogni riga per estrarne i singoli valori.
Si genera quindi un’istanza della classe Flight ad ogni nuovo volo e si chiama
la funzione addSector per ogni settore attraversato dal volo, incrementando
inoltre la variabile flightNumber dello stesso.
Gli oggetti cos`ı creati vengono memorizzati in una struttura dati definita
dalla classe TreeSet, chiamata FLIGHTS, assimilabile a una lista ordinata.
Viene inolte memorizzato il numero totale dei voli nella variabile totalFlights.
Una volta letti tutti i dati viene eseguita, per ogni volo, la procedura createRoutes
che genera le rotte disponibili per ques’ultimo.
Non vengono tuttavia create tutte le rotte possibili per un volo, ciò risul-
terebbe complicato e aumenterebbe troppo il carico computazionale dell’al-
goritmo.
La generazione avviene partendo dalla rotta base, con ritardo nullo, incre-
mentando il ritardo di un valore fisso, la costante DELAY INCREMENT, e con-
trollando quali slot la rotta andrebbe ad occupare nei settori che attraversa.
Il processo viene ripetuto incremenentando dello stesso valore il ritardo della

nuova rotta finchè non si raggiunge l’orario in cui temina la regolamentazione.
Ogni rotta, al momento della sua creazione, memorizza nel campo usedSlot,
di tipo TreeMap, i settori attraversati e gli slot occuoati in essi.
Viene inolte conteggiato il numero totale delle rotte nella variabile totalRoutes.
É necessario tuttavia fare delle precisazioni sulla generazione delle rotte in
quanto si sono fatte alcune assunzioni a priori per semplificare l’implemen-
tazione.
• non viene preso in considerazione il rerouting, cioè la possibilità che il
volo venga deviato in altri settori in cui non è applicata la regolamen-
tazione.
• ogni rotta può essere usata da un solo volo, nell’ipotesi che due voli
possano avere la stessa rotta, questa sarà modellizzata con due istanze
diverse, una per volo.
• per garantire l’esistenza di una soluzione al problema, per ogni volo
si genera una rotta che non attraversa nessun settore con un ritardo
tale da sforare la durata della regolamentazione; questa può rappre-
sentare la cancellazione del volo o, più semplicemente, la possibilità che
non ci sia abbastanza capicità nei settori per tutti i voli programmati;
identificheremo questa rotta con q∗
Per usare efficacemente tutti queste informazioni è necessario disporle in
matrici e vettori in accordo col modello presentato al capitolo precedente,
perchè queste sono le strutture dati con cui lavora l’ottimizzatore di Xpress.
Terminata quindi la generazione delle rotte, si passa a compilare le matrici
con tutti i dati raccolti: cercando di rimanere coerenti con la denominazione
utlizzata nel modello matematico, vengono utilizzati i seguenti array.
• Q[totalFlights][totalRoutes]: matrice binaria per rappresentare l’as-
sociazione tra voli e rotte, l’elemento Q[f][q] sarà uguale a uno se il volo
f può usare la rotta q, zero altrimenti.
• C[totalRoutes]: matrice che fornisce il costo del ritardo di ogni rotta.
• LS[SECTOR NUMBER][maxSlots][totalRoutes]: matrice binaria per rap-
presentare l’associazione tra rotte e slot, l’elemento LS[s][r][q] sarà
uguale a uno se la rotta q usa lo slot r del settore s, zero altrimen-
ti. Siccome i settori possono avere un numero di slot diverso tra loro,
è possibile che alcune righe della matrice non contengano uno.

• A[totalFlights]: matrice che fornisce l’assegnazione FPFS, ogni ele-
mento A[f] contiene l’indice della rotta assegnata al volo f, in riferi-
mento alle matrici Q e C.
• P[SECTOR NUMBER][maxSlots]: matrice che fornisce il prezzo di ogni
slot, inizialmente zero.
• X[totalFlights][totalRoutes]: matrice binaria per memorizzare i
risultati parziali e finali dell’algoritmo, l’elemento X[f][q] sarà uguale a
uno se al volo f è stata assegnata la rotta q, zero altrimenti.
• LB[totalFlights][totalRoutes]: matrice per il calcolo della stima del
limite inferiore nell’algoritmo subgradiente (1.15).
La compilazione delle matrici Q,C,LS è semplice e diretta: dopo averle
inizializzate è sufficente leggere i dati raccolti finora per inserire i valori nelle
giuste posizioni, mantenendo l’ordinamento di voli e rotte precedentemente
stabilito.
L’assegnazione iniziale contenuta in A è invece più complicata in quanto im-
plica l’esecuzione dell’algoritmo FPFS, come spiegato nella sezione (1.2.2).
Innanzitutto si definscono delle strutture dati ausiliarie per l’esecuzione del-
l’algoritmo nei singoli settori; per ogni settore abbiamo una lista dei voli che
lo attraversano, ordinati secondo l’orario di ingresso. Si procede quindi es-
eguendo l’algoritmo FPFS per i singoli settori.
Analizzando i voli secondo l’ordinamento si assegna a ciascuno la migliore
rotta disponibile e si segnano come occupati, tramite la funzione setIsUsed,
gli slot usati da quella rotta.
Finiti i voli di un settore, prima di passare al successivo, si liberano tutti gli
slot.
Terminato questo passaggio abbiamo, per ogni settore, una lista di rotte tem-
poraneamente assegnate ai voli che lo attraversano.
Ora, per ogni volo, si sceglie la peggiore della rotte cos`ı assegnategli e la si
invoca il metodo setFpfs per memorizzarla.
A questo punto però alcuni slot potrebbero essere usati da più voli, quindi,
per evitare conflitti, si stabilisce un criterio di priorità tra i voli.
Nel nostro caso la priorità è data dall’orario di partenza ma è possibile
scegliere altri criteri di ordinamento.
Si esamina quindi ogni volo, seguendo l’ordine della lista FLIGHTS; se gli slot
usati dalla sua rotta fpfs sono disponibili vengono segnati come occupati,
questa volta in via definitiva.
Se non lo sono al volo viene assegnata la rotta successiva e il controllo ripetu-

to, finchè non ne viene trovata una disponibile. 1
Nel vettore A vengo quindi memorizzati gli indici delle rotte cos`ı trovate in-
crementati di 1 in quanto Xpress, per un vettore di n elementi, lavora con
gli indici da 1 a n mentre java da 0 a n − 1.
Le matrici P e X sono inizializzate a 0, mentre la matrice LB in accordo con
la formula (1.16).
Infine, come ultimo passaggio opzionale, le matrici vengono scritte in un file
di testo per permettere una verifica dell’utente sul risultato fin qui ottenuto.
Una volta terminata la compilazione di tutte le matrici si passa ad impostare
il collegamento con l’ambiente Xpress.
É necessario inizializzare Xpress istanzionado un oggetto della classe XPRM,
poi invocare il suo compilatore sul file sorgente e infine collegare il modello
compilato al programma Java.
Per fare ciò ci sono una serie di funzioni di semplice utilizzo fornite dalla
libreria proprio a questo scopo.
Una volta che il modello è stato compilato e caricato bisogna legare le matrice
precedenti alle rispettive variabili in ambiente Xpress in modo da permettere
il passaggio dei dati.
Questo procedimento avviene con l’uso della funzione XPRM.bind che accetta
come argomento solamente vettori unidimensionali, da qui la necessità dei
metodi toLine della classe Utility.
Ultima ma non meno importante è la definizione di una stringa che contiene
tutti i parametri di esecuzione del modello.
Listing 2.7: Inizializzazione dell’ambiente Xpress§
100 flightMos = new XPRM ();
101 flightMos.compile(" modellosingolivoli .mos");
102 flightMod = flightMos.loadModel(" modellosingolivoli .bim");
103 XPRM.bind("A", A);
104 XPRM.bind("Q", Utility.toLine(Q,totalFlights ,totalRoutes ));
105 XPRM.bind("C", C);
106 XPRM.bind("LS", Utility.toLine(LS ,SECTOR_NUMBER ,maxSlots , totalRoutes ));
107 XPRM.bind("sol", X);
108 XPRM.bind("P", Utility.toLine(P,SECTOR_NUMBER ,maxSlots ));
109 String PARAMS = "FPFS=’noindex ,A’,FlightRoute =’noindex ,Q’,RoutePrice=’noindex ,C’,"+
110 +"RouteSlot=’noindex ,LS ’,Price=’noindex ,P’,SOL=’noindex ,sol ’," +
111 +"SECTORS=" + SECTOR_NUMBER + ",SLOTS=" + maxSlots + ",FLIGHTS=" + totalFlights +
112 +",ROUTES=" + totalRoutes + ",f=0";
113 flightMod.execParams = PARAMS;
¦ ¥
1
Per un maggiore dettaglio sull’assegnazione fpfs si rimanda al manuale ATFCM di
Eurocontrol.

2.4 Esecuzione dell’algoritmo
Può quindi avere inizio l’esecuzione dell’algoritmo vero e proprio.
Trattandosi di un algorimo di mercato con più partecipanti, illustreremo pri-
ma la parte distribuita riguardante le compagnie aeree e successivamente
quella centrale del Network Manager, come se fossero effettivamente due
entità separate, per quanto poi facciano parte dello stesso programma e le
simulazioni vengano svolte sempre su un unica macchina.
La parte dell’algoritmo che spetta alle compagnie aeree è relativamente sem-
plice: per ogni volo, indipendentemente dagli altri, bisogna trovare qual’è la
sua rotta economicamente più efficace ai prezzi attuali.
Per fare ciò i parametri del volo vengono trasmessi dal programma all’ot-
timizzatore Xpress, che risolve il problema (1.7) e memorizza le rotte ottimali
nella matrice X. Come si può notare dal codice (2.8) il programma è lineare:
abbiamo la definizione dei parametri, la dichiarazione delle variabili, la loro
inizilizzazione coi dati ricevuti dal programma base e l’invio dei risultati.
Le equazioni nel codice ricalcano pari passo quelle della formulazione (1.7).
Listing 2.8: Codice Xpress per il problema (1.7)
§
1 model singolovolo
2 uses "mmxprs";
3
4 parameters
5 FPFS = ’’; FlightRoute = ’’ ; RoutePrice = ’’; RouteSlot = ’’; Price = ’’;
6 SOL = ’’;
7 SECTORS ; slot ; FLIGHTS ; ROUTES ; f ;
8 end -parameters
9
10 declarations
11 S=1.. SECTORS!SECTOR
12 L=1.. slot!SLOT
13 F=1.. FLIGHTS!FLIGHT
14 Q=1.. ROUTES!ROUTE
15 A: array (F) of integer
16 Qf : array (F,Q) of integer
17 C: array (Q) of real
18 LS: array (S,L,Q) of integer
19 P: array (S,L) of real
20 x: array (F,Q) of mpvar
21 soltake: array(Q) of real
22 end - declarations
23
24 initializations from ’jraw:’
25 A as FPFS Qf as FlightRoute C as RoutePrice LS as RouteSlot P as Price
26 end - initializations
27
28 cost := sum(q in Q | Qf(f,q)=1) ( ( (C(A(f)) - C(q)) +
29 - ( sum(s in S)(sum(l in L | LS(s,l,q) =1 )(P(s,l))) )+
30 + ( sum(s in S)(sum(l in L | LS(s,l,A(f))=1 )(P(s,l))) ) )*x(f,q) )
31
32 sum(q in Q | Qf(f,q)=1) x(f,q) = 1
33
34 forall (q in Q | Qf(f,q)=1) x(f,q) >= 0
35
36 maximize (cost)
37
38 forall(q in Q) soltake(q):= getsol(x(f,q))
39
40 initializations to ’jraw:’
41 soltake as SOL
43
44 writeln("Objective:", getobjval)
45 end -model
¦ ¥

2.4. ESECUZIONE DELL’ALGORITMO 31
Non è detto che la soluzione presente ora nella matrice X sia accettabile,
viene dunque effettuato un controllo sulle assegnazioni trovate in modo da
essere sicuri che nessuno slot sia usato da più di un volo.
Se la soluzione è effettivamente valida per il problema, essa viene salvata,
insieme ai prezzi che l’hanno causata, in una serie di variabili temporanee,
che saranno indicate come temp X e temp P.
Ad ogni iterazione, se la soluzione proposta dalle compagnie aeree è accetta-
bile e migiore di quella trovata precedentemente, queste variabili vengono
aggiornate con la soluzione migliore .
La parte dell’algoritmo relativa al Network Manager è più sostanziosa per
quanto si possa riassumere nello fissare i prezzi degli slot.
Per il calcolo dei prezzi, secondo la formula (1.10), è necessario conoscere
il passo Φt
, una stima del quale è data dalla formula (1.13), in quanto il
Network Manger non conosce i costi delle rotte; in questa parte dell’imple-
mentazione non si farà infatti uso del vettore C.
Richiamando quanto detto al capitolo 1.2.4, il valore UBZ∗
è un limite su-
periore che rimane fisso per tutte le iterazioni ed è funzione del numero di
voli e di slot.
Nei test si è visto che un valore troppo grande per questo parametro fa con-
vergere molto lentamente il passo Φt
, al contrario un valore eccessivamente
piccolo determina prezzi troppo bassi o fa risultare il passo Φt
negativo, il
che non è accettabile per l’esecuzione dell’algorimo.
Un valore che è stato ritenuto accettabile come via di mezzo tra queste situ-
azioni e che è facilmente calcolabile è il semplice prodotto tra la variabili,
poniamo quindi
UBZ∗
= SECTOR NUMBER · totalFlights · totalRoutes (2.1)
Il calcolo per il limite inferiore ZLBIP−E è invece più complicato e viene
eseguito tramite due funzioni apposite.
La prima è una funzione ricorsiva che serve per il calcolo di ogni singolo ele-
mento della matrice LB all’iterazione t, secondo la formula (1.15)
Per ogni volo f la funzione viene invocata solo se la rotta q è disponibile per
tale volo, altrimenti si pone LB[f][q]=−∞.
Per l’elemento corrente, si inizia con il calcolo di p(q, af , λt
) come da equazione
(1.14).
Se, durante la parte distribuita dell’algoritmo, per il volo f è stata scelta la
rotta q allora al valore p, inizialmente 0, si sommano i prezzi degli slot λt
r
usati dalla rotta q mentre si sottraggono i prezzi degli slot della rotta af .
Se, invece, la rotta non è stata scelta, si imposta p a −∞.
Si passa poi a definire l’insieme Qf (q) per il calcolo di maxq∈Qf (q){LBt
(f, q)}.
Ricordando che le rotte sono ordinate secondo il ritardo causato e che ogni

rotta può essere usata da un solo volo, è sufficente esaminare la riga f della
matrice Q e contare quanti 1 sono presenti a destra dell’elemento Q[f][q] per
trovare quali sono gli elementi di Qf (q).
A meno che questo insieme sia vuoto, e in tal caso si pone maxq∈Qf (q){LBt
(f, q)} =
−∞, è necessario calcolare LB[f][q] per ogni elemento e individuarne il mag-
giore.
Si può quindi iniziare la ricorsione invocando la stessa funzione sulla rotta
q + 1, considerando che Qf (q + 1) = Qf (q){q + 1}.
La ricorsione terminerà quando l’insieme Q sarà vuoto, cioè quando si ar-
riverà ad esaminare la rotta q∗, la funzione restituirà quindi il massimo tra
p(q∗, af , λt
) e LBt−1
(f, q∗), come da formula (1.15).
Ripercorrendo indietro la ricorsione si possono quindi utlizzare i valori già
calcolati per trovare il valore corrente e completare la riga della matrice LB
per il volo f.
Listing 2.9: Codice della funzione LB§
465 public static double LB(int flight , int route , int [][]Q, int[]A, int [][][]LS ,
466 double [][]P, int [][]X, double [][] LB ){
467 double p=0;
468 int delayedq =0;
469 double [] reducedLB ;
470 double maxLB;
471
472 if(X[flight ][ route] == 1){
473 for(int sec =0; sec < SECTOR_NUMBER ; sec ++){
474 for (int r=0; r<maxSlots; r++){
475 if(LS[sec ][r][ route] == 1) p = p + P[sec ][r];
476 if(LS[sec ][r][A[flight ]-1] == 1) p = p - P[sec ][r];
477 }
478 }
479 }
480 else p = Double. NEGATIVE_INFINITY ;
481
482 for (int q = route +1; q<totalRoutes; q++){
483 if (Q[flight ][q] == 1) delayedq ++;
484 else break;
485 }
486 if (delayedq != 0){
487 LB[flight ][ route +1] = LB(flight ,route +1,Q,A,LS ,P,X,LB);
488 Q_f = new double[delayedq ];
489 for (int q=0; q<delayedq; q++){
490 Q_f[q] = LB[flight ][ route+q+1];
491 }
492 maxLB = Utility.maxValue(Q_f );
493 }
494 else maxLB=Double. NEGATIVE_INFINITY ;
495
496 return Utility.maxValue(p,LB[flight ][ route],maxLB );
497 }
¦ ¥
Dopo il calcolo di tutti i valori di LB viene invocata la funzione lowerbound
per la risoluzione del problema (1.17).
Per inizializzare il collegamento con l’ambiente Xpress molte delle impostazioni
iniziali restano valide, è necessario comunque invocare il compilatore su un
modello diverso, si usa il file ZLB.mos, abbinare la matrice LB appena trova-
ta alla sua rispettiva in Xpress, chiamando la funzione XPRM.bind(LB) e
modificare la stringa dei parametri come segue:

Listing 2.10: Parametri per il problema (1.17)
§
447 String PARAMS = " FlightRoute =’noindex ,Q’,LowerBound=’noindex ,LB ’,RouteSlot=’noindex ,LS ’," +
448 +"SECTORS=" + SECTOR_NUMBER + ",SLOTS=" + maxSlots +
449 +",FLIGHTS=" + totalFlights + ",ROUTES"+totalRoutes;
¦ ¥
Una volta risolto il problema di ottimizzazione e trovato infine il valore
ZLBIP−E che stavamo cercando, bisogna chiamare la funzione XPRM.unbind(-
LB) per svincolare la matrice LB in quanto essa viene ricalcolata ad ogni
iterazione.
Similmente al programma distribuito per i singoli voli, anche qui il codice è
lineare e di facile comprensione, e le equazioni si rifanno alla formulazione
(1.17).
Listing 2.11: Codice Xpress per il problema (1.17)
§
1 model ZLB
2 uses "mmxprs";
3
4 parameters
5 FlightRoute = ’’ ; RouteSlot = ’’; LowerBound = ’’
6 SECTORS ; slot ; FLIGHTS ; ROUTES ;
7 end -parameters
8
9 declarations
10 S=1.. SECTORS!SECTOR
11 L=1.. slot!SLOT
12 F=1.. FLIGHTS!FLIGHT
13 Q=1.. ROUTES!ROUTE
14 Qf: array (F,Q) of integer
15 LB: array (F,Q) of real
16 LS: array (S,L,Q) of integer
17 x: array (F,Q) of mpvar
18 end - declarations
19
20 initializations from ’jraw:’
21 Qf as FlightRoute LB as LowerBound LS as RouteSlot
23
24 forall (q in Q,f in F) x(f,q) is_binary
25
26 forall (s in S,l in L) sum(f in F)(sum (q in Q | Qf(f,q)=1 and LS(s,l,q)=1) x(f,q)) <=1
27
28 forall (f in F) sum(q in Q | Qf(f,q)=1) x(f,q) =1
29
30 cost := sum(f in F)(sum(q in Q | Qf(f,q)=1) LB(f,q)*x(f,q))
31 maximize (cost)
32
33 writeln("Objective:", getobjval)
34 end -model
¦ ¥
Una volta calcolati entrambi i limiti si esegue il controllo sul parametro
θt
, questo viene dimezzato nel momento in cui il passo Φt
non descresce per
due o più iterazioni consecutive.
Trovati tutti i valori del numeratore della formula (1.13) il calcolo del de-
nominatore procede più facilmente, è sufficente esaminare le matrici Q,LS e
X e sommare quando opportuno.
Si calcola quindi il passo Φt
per l’iterazione corrente.
Prima di passare al calcolo dei prezzi degli slot vengono effettuati dei con-
trollo sul valore del passo e sul numero di iterazioni e, in caso, si termina
l’algoritmo.
Il normale flusso di esecuzione passa dalla ricerca delle rotte per i voli al

calcolo dei prezzi e viceversa.
Per quanto il passo Φt
sia globalmente decrescente e tenda a zero col susseguir-
si delle iterazioni non si hanno tuttavia garanzie sul tempo necessario.
Ci si accontenta quindi di una soluzione approssimata e si termina l’algorit-
mo nel caso in cui Φt
≤ 0.3 o si sono eseguite 100 iterazioni.
Questi sono i valori utlizzati nei test del capitolo 3 ma possono essere modi-
ficati se si desidera un’esecuzione più rapida o, al contrario, più precisa.
Se queste condizioni non sono verficate si procede al calcolo dei prezzi di ogni
slot, dopo avere tolto il collegamento all’ambiente Xpress, tramite la funzione
XPRM.unbind(P).
Questa operazione di associazione e dissociazione della matrice P è da es-
eguire ogni volta che vengono ricalcolati i pressi degli slot altrimenti Xpress
continuerebbe a lavorare con quelli dell’iterazione precedente.
Seguendo le formule (1.10) e (1.11) e utlizzando il valore di Φt
si calcola il
prezzo degli slot.
Per ognuno di essi, esaminando le matrici Q,LS e X, si trova il valore SG che
rappresenta il numero di voli interessati all’acquisto dello slot.
Il prezzo del quale viene quindi modificato a seconda della domanda molti-
plicata per il passo Φt
.
Trovati tutti questi valori si ricollega di nuovo la matrice P a Xpress con
XPRM.bind(P).
Con il calcolo dei nuovi prezzi termina un’iterazione dell’algoritmo, si ricom-
incia quindi con il calcolo delle rotte migliori per ogni volo da parte delle
compagnie aeree a cui sono stati forniti i nuovi prezzi.
Al termine dell’algortimo troviamo nella matrice temp X le associazioni
volo-rotta che cercavamo, possiamo quindi calcolare il guadagno ottenuto us-
ando queste assegnazioni rispetto a quelle dell’algoritmo FPFS presenti nel
vettore A.
Siccome nella formulazione (1.6) abbiamo di fatto spostato un vincolo nella
funzione obiettivo esiste la possiblità che nessuna delle soluzioni trovate du-
rante lo svolgimento sia valida, proprio perchè violano quel vincolo.
Se nessuna soluzione valida fosse stata trovata l’intero algoritmo viene ripetu-
to dopo aver incrementato il limite superiore UBZ∗
del 2 %; nella mag-
giornaza dei test effettutati il numero di incrementi prima di ottenere una
soluzione accettabile è stato inferiore a 5.
Per ottenere un riscontro delle prestazioni dell’algoritmo distribuito si usano
gli stessi dati di partenza per risolvere il problema (1.5), il quale fornisce
sicuramente una soluzione ottima del problema.
Viene quindi invocato il compilatore Xpress sul modello completo, si usa il
file modellocompleto.mos, e modificata la stringa dei parametri.

Si calcola anche qui il guadagno ottento scambiando l’assegnazione FPFS di
A con l’assegnazione ottima appena trovata.
Dal confronto tra i due valori di guadagno possiamo inﬁne calcolare di quanto
si discosta dall’ottimo la soluzione dell’algoritmo distribuito.
Dovrebbe inoltre essere possibile, nel caso di istanze del problema con un
quantitativo di dati particolarmente grande, apprezzare il minor tempo di
calcolo sulla singola iterazione dell’algoritmo distribuito rispetto al modello
completo.

Capitolo 3
Risultati sperimentali
Verrano ora presentati i risultati di alcuni test effettuati con l’algoritmo dis-
tribuito e messi a confronto con la soluzione ottima fornita dal problema
(1.5).
3.1 Test effettuati
Per i test sono stati scelti i settori codificati come LRBBARG1,LRBBARG2
e LRBBARG6 in quanto hanno in comune un numero sufficente di voli.
Prendere settori senza voli in comune non ha significato per l’algoritmo, è
come effettuare l’assegnazione un settore alla volta.
I dati utlizzati si riferiscono al traffico aereo del giorno 12 settembre 2014
dalle ore 7.00 del mattino alle ore 9.20, in questo periodo sono 24 i voli che
attraversano almeno uno dei settori.
Nei test effettuati si è variata di volta in volta la capacità oraria dei settori e,
quindi, il numero di slot disponibili; questo valore, indicato nella prima colon-
na delle tabelle, rappresenta il parametro Ks della formula (1.1). Si è inoltre
variato il numero di rotte disponibili, modificando l’intervallo di tempo tra
una rotta e l’altra, questo è il valore assunto dalla costante DELAY INCREMENT
per la generazione delle rotte, in riferimento alla sezione 2.3.
La differenza tra i due algoritmi è visuallizzata in forma di percentuale e
indica di quanto la soluzione dell’algoritmo distribuito si discosta da quella
ottima. Per ogni test è riportato inoltre il numero di tentativi fatti, cioè il
numero di incrementi di UBZ∗
, prima di trovare una soluzione accettabile.
Infine, nell’ultima riga, è presente il valore iniziale di UBZ∗
; essendo calcola-
to secondo la formula (2.1) esso non dipende dalla capacità oraria ed è quindi
lo stesso per tutti i test di una colonna.
36

3.1. TEST EFFETTUATI 37
Tabella 3.1: Test su 3 settori
Capacità Intervallo tra le rotte
oraria 15 18 20 22
27% 16.6% 46.2% 7.7%
4 1 1 1 3
32.6% 0% 0% 45%
5 3 1 1 1
85.6% 23.1% 11.8% 10%
6 102 1 1 1
0% 30.5% 3.8% 0.6%
7 1 9 1 1
11088 9648 8712 8424
UBZ∗
iniziale
Nella prossima tabella (3.2) è stato preso in considerazione un quarto
settore codificato come LRBBARG7, portando il numero di voli a 27.
oraria 15 18 20 22
19% 4.3% 0% 3.5%
4 18 1 1 1
31.2% 26.5% 0% 0%
5 2 9 1 1
90.9% 7.4% 0% 29.3%
6 56 1 1 1
0% 13.4% 3.8% 1.1%
7 1 31 2 1
19116 16416 14904 14364
UBZ∗
iniziale
Infine, nella tabella (3.3), è stato aggiunto anche un quinto settore, codi-
ficato come LRBBARG4, ora il numero di voli è 29.

38 CAPITOLO 3. RISULTATI SPERIMENTALI
oraria 15 18 20 22
88.6% 41% 0% 19.6%
4 67 1 1 1
27.5% 0% 14.% 0%
5 4 1 1 2
24.4% 2.7% 4.6 3.7%
6 14 1 1 1
3% 7% 12.3% 0.7%
7 1 5 16 1
27550 23925 21605 20880
UBZ iniziale
Come si può vedere i risultati ottenuti variano parecchio, benchè in al-
cuni casi la soluzione ottenuta coincida con quella ottima, in altri si ha una
differenza del 50% o anche più.
Si è notata una correlazione tra la grande diversità di risultati e il valore di
UBZ∗
.
Le differenze minori, e in particolari quelle nulle, sono state trovate con il
valore iniziale di UBZ∗
.
Più questo parametro veniva invece incrementato, a causa di mancanza di
soluzioni non accettabili, maggiore era la differenza con il valore ottimo.
Nel grafico (3.1) è invece riportata la differenza rispetto all’ottimo in fun-
zione della variazione di UBZ∗
, con maggiori test intorno al valore fornito
dalla (2.1).
Per la serie 1 è stata usata la configurazione a 3 settori, con 20 minuti di
intervallo tra le rotte e 6 slot per ogni ora.
Per la serie 2 invece, è stata usata la configurazione a 4 settori, con 20 minuti
di intervallo tra le rotte e 4 slot per ogni ora.
Per valori di UBZ∗
< 4000 i prezzi degli slot non erano abbastanza alti per
ottenere una soluzione, mentre oltre 105
i prezzi erano troppo alti rispetto al
costo delle singole rotte.
Da questo tipo di studio non si è riusciti a determinare qual’è il valore migliore
per UBZ∗
o un modo per calcolarlo, sembra solo che per alcune istanze di
dati sia più facile trovare la soluzione ottima anche variando UBZ∗
.

3.2. CONCLUSIONI 39
0,00%
10,00%
20,00%
30,00%
40,00%
50,00%
60,00%
70,00%
80,00%
90,00%
100,00%
0 10000 20000 30000 40000 50000 60000 70000 80000 90000
Serie 1
Serie 2
Figura 3.1: Grafico per lo studio di UBZ∗
Per quanto riguarda il tempo di esecuzione, l’overload per la trasmissione
dei dati a Xpress e la ripetizione dell’algoritmo per la mancanza di soluzioni
rendono il tutto più lungo della risoluzione del singolo problema (1.5).
É ipotizzabile che per istanze di dati più grandi l’algoritmo distribuito pre-
senti vantaggi in termini di tempo ma non è stato possibile effettuare test in
tal senso.
3.2 Conclusioni
I test riportati nella sezione precedente sono una piccola parte del totale, ma
sono gli unici fatti con dati reali non modificati.
La maggior parte delle prove è stata fatta con dati reali apportunamente
modificati per incrementare la competizione tra i voli o con dati creati arti-
ficialmente per meglio testare l’algoritmo.
Dai valori raccolti in tutti questi test si evince che è il valore UBZ∗
che fa

40 CAPITOLO 3. RISULTATI SPERIMENTALI
da discriminante tra i risultati, piuttosto che le condizioni per far terminare
l’algoritmo, su Φt
e sul numero di iterazioni.
Sono state provate diverse formule per il suo calcolo come anche valori nu-
merici fissati a priori.
La formula (2.1) è stata scelta in quanto mediamente trovava una soluzione
accettabile prima delle altre, perchè è funzione del numero di voli e di settori,
come suggerito nell’articolo (Castelli et al.,2012), e perchè era di semplice im-
plementazione.
Essa tuttavia non è sufficente per garantire un’adeguata affidabilità nei risul-
tati, in quanto non da garanzie sulla bontà della soluzione e sul tempo di
esecuzione.
Oltre alle percentuali prima riportate, anche il numero di tentativi da fare
risulta altalenante e un eccessivo aumento di UBZ∗
va a inficiare tutta la
procedura, aumentando irragionevolmente i prezzi degli slot.
L’algoritmo è potenzialmente capace di trovare una soluzione valida al prob-
lema, anche ottima a volte, ma il tutto dipende da come viene scelto questo
valore.
Si rende quindi necessario uno studio più approfondito sul calcolo di UBZ∗
che non mi è stato possibile fare per mancanza di competenze sull’argomento.
La necessità di ripetere l’algoritmo in mancanza di una soluzione e le piccole
istanze di dati su cui è stato testato rendono inoltre impossibile pronunciarsi
sull’eventuale riduzione del tempo di calcolo rispetto al problema completo.
In conclusione l’algoritmo raggiunge lo scopo di coinvolgere le compagnie
aeree nel processo decisionale ma, al momento, non si può dire altrettando
per quanto riguarda la riduzione del carico computazionale che ricade sul
Network Manager.

Bibliografia
[1] Thomas Vossen, Michael Ball, Optimization and Mediated Bartering
Models for Ground Delay Programs , 2005
[2] Lorenzo Castelli, Raffaele Pesenti, Andrea Ranieri, The design of a
market mechanism to allocate Air Traffic Flow Management slots , 2011
[3] Lorenzo Castelli, Raffaele Pesenti, Andrea Ranieri, Short-term allo-
cation of Time Windows to flights through a distributed market-based
mechanism , 2012
[4] Marshall L. Fisher, An Applications Oriented Guide to Lagrangian
Relaxation , 1985
[5] EUROCONTROL, ATFCM USERS MANUAL , Edizione 19.1, 2015
41

Implementazione di un algoritmo distribuito per l'assegnazione del traffico aereo

Recommended

Recommended

More Related Content

Similar to Implementazione di un algoritmo distribuito per l'assegnazione del traffico aereo

Similar to Implementazione di un algoritmo distribuito per l'assegnazione del traffico aereo (20)

Implementazione di un algoritmo distribuito per l'assegnazione del traffico aereo