INGEGNERIA DELLE TELECOMUNICAZIONI

Transcript

UNIVERSITÀ DEGLI STUDI DI NAPOLI FEDERICO II
FACOLTÀ DI INGEGNERIA
CORSO DI LAUREA IN
INGEGNERIA DELLE TELECOMUNICAZIONI
(CLASSE DELLE LAUREE SPECIALISTICHE IN INGEGNERIA DELLE TELECOMUNICAZIONI CLASSE N°30/S)
DIPARTIMENTO DI INFORMATICA E SISTEMISTICA
ELABORATO DI LAUREA
Progettazione ed implementazione di un sistema per il Ramp
Management basato su architettura multiagente
RELATORE
CH. MO PROF.
DOMENICO COTRONEO
CANDIDATO
ANGELO DAVIDE FRAGLIASSO
MATR. 887/000216
CORRELATORE
ING. LUIGI BATTAGLIA
ING. GABRIELLA CARROZZA
ANNO ACCADEMICO 2007/2008
Ringrazio la mia famiglia…
In particolare mia Mamma, mio Padre e mia Sorella
sempre vicini in qualsiasi momento, vi adoro.
Ringrazio Nina, sei importantissima, e tutti i miei Amici per tutti i
bellissimi momenti trascorsi insieme.
Ringrazio il Prof. Cotroneo, Gabriella e Luigi che mi hanno seguito in
questo lavoro.
Infine, ma non meno importante, ringrazio me stesso per tutto l’impegno.
“ L’importante è andare fino in fondo e non voltarsi troppo indietro”
Indice
Indice…………………………………………………………………………………………..1
Indice delle figure……………………………………………………………………………...3
Introduzione……………………………………………………………………………………6
Capitolo 1: Ramp management………………………………………………………………..8
1.1 Scenario di riferimento…………………………………………………………………….8
1.2 Gestione aeroportuale……………………………………………………………………..10
1.3 Entità aeroportuali………………………………………………………………………...11
1.3.1 Sistema informativo di scalo………………………………………………………….12
1.4 Servizi di handling………………………………………………………………………..14
1.4.1 Servizi di rampa………………………………………………………………………14
1.4.2 Funzionalità…………………………………………………………………………...18
1.4.3 Schematizzazione funzionalità del sistema…………………………………………...24
1.4.4 Requisiti non funzionali……………………………………………………………....34
1.4.5 Architettura del sistema……………………………………………………………....35
Capitolo 2: Sistemi multi-agente e JADE……………………………………………………37
2.1 Motivi della scelta………………………………………………………………………..37
2.2 Gli agenti software……………………………………………………………………….38
2.3 Architetture sistemi multi-agente………………………………………………………...40
2.4 Comunicazione e coordinamento………………………………………………………...43
2.5 Lo standard FIPA………………………………………………………………………...46
2.5.1 Agent management…………………………………………………………………...46
2.5.2 Linguaggio FIPA-ACL……………………………………………………………….49
2.6 La piattaforma JADE……………………………………………………………………..51
2.6.1 Architettura JADE……………………………………………………………………53
2.6.2 Message Transport Service…………………………………………………………...55
2.6.3 IMTP………………………………………………………………………………….56
2.6.4 Special agents………………………………………………………………………..57
2.6.5 Fault tolerant platform……………………………………………………………….63
2.6.6 Security in JADE…………………………………………………………………….67
2.6.7 Add-on per dispositivi mobili………………………………………………………..70
Capitolo 3: Implementazione del prototipo..………………………………………………..82
3.1 Procedura di handling “prova motori”…………………………………………………..82
3.2 Prototipo in modalità stand-alone……………………………………………………….84
3.3 Scheduling ed esecuzione di behaviour…………………………………………………88
3.4 Agent communication…………………………………………………………………...90
3.5 Classi utilizzate………………………………………………………………………….91
3.6 Prototipo in ambiente wireless…………………………………………………………..98
3.7 Classi utilizzate………………………………………………………………………….101
3.8 Procedura di handling de-icing / de-snowing…………………………………………...102
Conclusioni e sviluppi futuri…………………………………………………………………106
Bibliografia…………………………………………………………………………………...108
Indice delle figure
Figura 1: schema aree aeroportuali ……………………………………………..9
Figura 2: esempio di posizionamento handling…………………………………17
Figura 3: servizio di follow me………………………………………………….19
Figura 4: servizio di push back…………………………………………………..21
Figura 5: operazioni di rifornimento……………………………………………..22
Figura 6: de-icing………………………………………………………………...23
Figura 7: esempio di architetture di agenti reattivi……………………………....41
Figura 8: architettura PRS……………………………………………………….42
Figura 9: architettura a strati……………………………………………………..43
Figura 10: contract net…………………………………………………………...45
Figura 11: modello di riferimento FIPA………………………………………....47
Figura 12: formato dei messaggi………………………………………………....48
Figura 13: parametri di un messaggio FIPA compliant…………………………..49
Figura 14: FIPA communicative act……………………………………………...50
Figura 15: architettura con un insieme di piattaforme…………………………....54
Figura 16: message transport protocols…………………………………………..56
Figura 17: interfaccia Dummy Agent………………………………………….....58
Figura 18: interfaccia Introspector Agent………………………………………...59
Figura 19: interfaccia Sniffer Agent……………………………………………...60
Figura 20: diagramma delle classi degli agenti in JADE………………………...62
Figura 21: main-container replication……………………………………………64
Figura 22: parametri di configurazione accesso DB……………………………..65
Figura 23: JADE-LEAP run time environment………………………………….73
Figura 24: LEAP IMTP………………………………………………………….75
Figura 25: split execution mode…………………………………………………76
Figura 26: modalità di esecuzione JADE-LEAP………………………………...77
Figura 27: il mediatore……………………………………………………….......78
Figura 28: procedura di start up di uno split container………………………......80
Figura 29: procedura di riconnessione…………………………………………...81
Figura 30: accompagnamento in prova motori con traino………………………83
Figura 31: schema accompagnamento in prova motori senza traino…………….84
Figura 32: interfaccia dell'RMA con due main-container………………………..86
Figura 33: finestra di dialogo JADE-S…………………………………………...87
Figura 34: path di esecuzione del thread di un agente……………………………89
Figura 35: jade “asynchronous message passing”………………………………..90
Figura 36: interfaccia duty manager……………………………………………...93
Figura 37: finestra relativa alla procedura attivata……………………………….93
Figura 38: interfaccia di un handling agent………………………………………95
Figura 39: PDA Hp IPAQ………………………………………………………...99
Diagrammi e schemi
Schema 1.1: duty manager………………………………………………………...25
Schema 1.1.1: duty manager……………………………………………………26-27
Schema 1.2: follow me…………………………………………………………….29
Schema 1.3: tecnici dell’aeroporto………………………………………………...30
Schema 1.4: push back…………………………………………………………….31
Schema 1.5: De-icer……………………………………………………………….32
Schema 1.6: ulteriori funzionalità…………………………………………………33
Schema 1.7: architettura sistema…………………………………………………..35
Diagramma 3.1: sequence diagram comunicazione topic-based…………………97
Diagramma 3.2: class diagram prototipo stand-alone…………………………….98
Diagramma 3.3: sequence diagram comunicazione non topic-based……………104
Diagramma 3.4: class diagram prototipo in ambiente wireless………………….105
Introduzione
Questo lavoro di tesi riguarda la progettazione e l’implementazione di un sistema di supporto
per la fornitura di servizi in ambito aeroportuale.
La maggior parte del lavoro è stato svolto presso lo stabilimento di SELEX s.p.a.,
sito in Giugliano (NA), una restante parte è stata svolta al D.I.S. (Dipartimento di Informatica e
Sistemistica) dell’Università di Napoli Federico II.
Dopo una fase iniziale di studio di documenti relativi allo scenario di riferimento e delle
tecnologie presenti si è passati alla progettazione e all’implementazione di un prototipo.
Dato che l’obiettivo era creare un sistema di supporto al “ramp management”, cioè alla
gestione dei mezzi di rampa, sono state analizzati in dettaglio i mezzi e le procedure di
handling.
Quest’analisi ha portato ad un insieme di requisiti e di diagrammi UML che hanno aiutato la
scelta della tecnologia e lo sviluppo dell’applicazione.
I requisiti più importanti sono la necessità di attuare procedure in modo automatico e il
supporto che il sistema deve offrire in ambiente mobile.
In base a questi requisiti è stata fatta una ricerca delle tecnologie presenti e come soluzione si è
pensato ai sistemi multiagente.
Questi rispettano i requisiti di progetto e si adattano bene allo scenario di riferimento, sono una
tecnologia che permette l’interazione e la cooperazione tra i vari attori del sistema, in modo da
poter creare un “ autonomous system”.
In particolare per implementare il nostro sistema multiagente si è scelto, come framework,
JADE ( “Java Agent Development Framework” ).
Questo è stato sviluppato da TILab s.p.a ( Telecom Italia Lab ) in collaborazione con
l’Università di Parma, ed è scaricabile gratuitamente dal suo sito internet.
Esso gode di buone caratteristiche: è open source, è scritto completamente in java, fornisce un
ottimo supporto in fase “run time” , e dispone di una serie di agenti, già implementati, che
permettono di monitorare lo stato della piattaforma e degli agenti ad essa connessi.
E’ stato poi sviluppato un prototipo, che permette di attivare varie procedure di handling in
modo automatico.
Tra le procedure studiate sono state considerate quella di accompagnamento in posizione prova
motori e quella di de-icing / de-snowing.
Queste due erano spiegate abbastanza dettagliatamente, la prima inoltre implicava l’utilizzo di
più mezzi di rampa e quindi di più agenti.
Sono state sviluppate delle interfacce che permettono di avviare le procedure, di visualizzare i
messaggi inviati da altri agenti e lo stato degli agenti connessi al sistema.
Andrebbero comunque implementate altre procedure ed andrebbero effettuate delle simulazioni
che permettono la valutazione delle prestazioni del prototipo in uno scenario più complesso e
con un maggior numero di nodi.
Capitolo 1 - Ramp management
Capitolo 1
Ramp Management
Questo elaborato di tesi ha come obiettivo lo sviluppo di un sistema di supporto alle decisioni per il
ramp management. In questo capitolo verrà illustrato dapprima lo scenario di riferimento,
l’aeroporto, e poi la funzione del ramp management.
1.1 Scenario di riferimento
Per aeroporto si intende: ogni località destinata anche in via temporanea all’approdo ed allo
stazionamento degli aeromobili.
E’ utile fare una classificazione delle aree di un aeroporto che possono essere suddivise in base alle
operazioni che avvengono in esse:
1. Area di atterraggio
2. Area di movimento
3. Area di manovra
L’area di atterraggio è l’area destinata alle manovre di atterraggio e decollo. Si potrebbe tendere ad
associare l’Area di atterraggio alla pista di decollo, in realtà ciò è restrittivo perché possono esistere
anche altre aree di decollo destinate ad esempio agli elicotteri o agli aeromobili VTOL ( Vertical
Take-off and Landing ).
L’area di manovra è definita come quella parte dell’aeroporto usata per il decollo, atterraggio e per
il rullaggio degli aeromobili escludendo i piazzali.
Per via di rullaggio, su di un aerodromo terrestre, si intende un percorso adibito al rullaggio degli
aeromobili, che intende garantire un collegamento tra due parti dell’aerodromo stesso.
Pertanto fanno parte dell’area di manovra le piste e le aree di atterraggio nonché tutte le vie di
circolazione che conducono a tali zone.
Non fanno parte di tale area la zona di manutenzione, gli hangars, e i piazzali di parcheggio.
8
L’area di movimento per definizione è quella parte di un aerodromo che dev’essere utilizzata per il
decollo, l’atterraggio ed il rullaggio degli aeromobili comprendente l’area di manovra ed i piazzali,
ossia qualsiasi area pavimentata o non, sulla quale un aeromobile può transitare.
Tale area comprende quindi oltre alle aree di atterraggio e alle taxiways ( vie di rullaggio), anche i
piazzali di parcheggio, le piazzole prova motore e i piazzali della zona di manutenzione.
I piazzali ( aprons ) sono previsti ovunque sia necessario permettere l’imbarco e lo sbarco dei
passeggeri, il carico e lo scarico di merci e di posta, le operazioni di servizio degli aeromobili
associate con il rifornimento, le pulizie, il carico di vettovaglie, lo scarico di rifiuti, i controlli e la
piccola manutenzione, senza interferire con il traffico dell’aerodromo.
Un esempio di suddivisone dell’area aeroportuale è quello in figura:
Figura 1: Schema aree aeroportuali
9
Nella figura in blu viene evidenziata l’area di manovra, in verde l’area dell’apron ed in rosso l’area
destinata alla circolazione dei veicoli interna all’aeroporto. L’area di movimento comprende tutte e
tre le aree mentre l’area di atterraggio comprende l’area blu escluse le vie di rullaggio.
1.2 Gestione aeroportuale
Le infrastrutture degli aeroporti statali per il traffico commerciale sono per la massima parte di
proprietà demaniale.
La loro gestione però molte volte è affidata a società esterne, soggetti pubblici o privati o a
partecipazione mista a cui è affidata la gestione dell’opera e di qualunque sua parte.
La procedura di affidamento consente allo stato di mantenere la proprietà delle strutture ed al
gestore di occuparsi della manutenzione, della costruzione di nuove strutture e della gestione
economica dell’opera per un determinato periodo di tempo.
La gestione aeroportuale può essere sostanzialmente di tre tipi:
1. Gestione totale
2. Gestione parziale
3. Gestione diretta
Gestione totale: l’intero aeroporto, incluse le infrastrutture di volo, è affidato ad un unico
concessionario. Di questa tipologia sono gli aeroporti di Malpensa, Linate, Fiumicino, Ciampino,
quelli di Genova e di Torino.
In questo caso le attività affidate alle società di gestione riguardano:
•
Manutenzione ordinaria e straordinaria delle infrastrutture.
•
Predisposizione di servizi ( fornitura di energia, di illuminazione, di acqua, riscaldamento, il
condizionamento, la depurazione, lo smaltimento rifiuti, la pulizia ed il sistema informativo
).
Nel caso di gestione parziale le infrastrutture di volo rimangono dello stato ( ENAC [1]), mentre
l’affidamento in concessione riguarda le aerostazioni e le relative pertinenze.
Nella gestione diretta invece è l’ENAC che provvede direttamente alla realizzazione e alla
manutenzione dei beni aeroportuali, mentre l’assistenza a terra è di norma effettuata in
10
auto-produzione dalle stesse compagnie aeree.
1.3 Entità aeroportuali
All’interno di un aeroporto sono presenti vari enti che hanno una funzione di supervisione e di
coordinamento.
•
Gestore aeroportuale
•
Operatore aeroportuale
Il gestore aeroportuale, già in precedenza citato, è il soggetto cui spetta il compito di amministrare
e gestire le infrastrutture di scalo, e di controllare le attività dei vari operatori presenti all’interno
dell’aeroporto. Ad esempio nel caso del sistema aeroportuale milanese tale ruolo è svolto da SEA
[2], secondo una convenzione stipulata con ENAC.
Per operatore aeroportuale si intende: gli handlers cioè i servizi di assistenza aeroportuale (
biglietteria, rifornimento aeromobili, guida al parcheggio etc ), gli enti o società che prestano servizi
di assistenza a terra all’interno dell’aeroporto e gli operatori commerciali coinvolti nell’attività
operativa di scalo.
Gli operatori che prestano assistenza devono essere in possesso dell’attestazione di idoneità
rilasciata da ENAC.
Tutti gli operatori presenti nello scalo devono prevedere una struttura di coordinamento operativo,
che garantisca la gestione e il controllo delle operazioni di propria competenza. Tale struttura deve
operare in modo integrato con le attività di supervisione e coordinamento dello scalo, svolte dal
gestore aeroportuale attraverso la sua funzione di Coordinamento Scali.
In particolare per ogni problematica che abbia conseguenze sulla normale operatività dello scalo, gli
operatori, devono fare riferimento al Duty Manager.
Questa entità scambia informazioni con gli operatori aeroportuali e con gli enti di stato interessati
per definire congiuntamente la risoluzione di criticità operative o emergenze che possono limitare la
capacità operativa dello scalo.
La funzione di supervisione e di coordinamento sul complesso aeroportuale dev’essere continuativa
per tutte le 24 ore.
11
Il coordinamento scali deve ricevere dagli operatori aeroportuali e dagli enti di stato le informazioni
relative all’operatività dei voli e alla capacità operativa disponibile per l’erogazione dei servizi
aeronautici diretti ed indiretti.
Le informazioni raccolte vengono utilizzate dal Duty Manager per valutare se necessario un
intervento specifico o per valutare l’operatività dello scalo, infatti il Duty Manager utilizza
strumenti di analisi statistica per analizzare i principali parametri utilizzati per misurare il livello di
servizio dello scalo.
Esso provvede a trasferire queste informazioni opportunamente elaborate agli enti responsabili ed
alle diverse linee di attività.
Il coordinamento scali effettua il monitoraggio ed il controllo dell’andamento delle diverse linee
operative di competenza al fine di garantire il massimo rispetto dei criteri gestionali definiti per le
risorse di scalo.
Allo scopo di risolvere situazioni di criticità operativa, il coordinamento scali si avvarrà del diritto
di richiedere particolari prestazioni di assistenza da parte degli operatori presenti sullo scalo, anche
per voli non di diretta competenza. L’operatore compatibilmente con le risorse al momento
disponibili, dovrà in tal caso garantire l’assistenza ai soggetti che pur non essendo suoi clienti, la
richiedano. In particolare dovrà fornire la propria collaborazione per le operazioni di soccorso, in
conformità alle disposizioni impartite dagli enti competenti.
1.3.1
Sistema informativo di scalo
Il sistema informativo di scalo è denominato Base Dati Voli ( BDV ). Esso permette la gestione
dell’archivio degli orari dei voli e il monitoraggio operativo; ha il compito di gestire in modo
centralizzato le fasi di generazione, aggiornamento e diffusione delle informazioni operative di
scalo.
Le informazioni principali, aggregate e organizzate, sono identificate essenzialmente dal seguente
insieme di dati:
•
Scalo di origine
•
Orari di arrivo
•
Numero di volo in arrivo
•
Tipo aeromobile
12
•
Numero volo in partenza
•
Orari di partenza
•
Scalo di destinazione
Principali funzioni del sistema BDV:
•
Mantiene memorizzati gli orari stagionali delle compagnie aeree operanti sullo scalo,
rendendoli disponibili in lettura e per i periodici aggiornamenti.
•
Produce, a partire dai precedenti, gli orari operativi giornalieri, acquisendo in essi, eventuali
modifiche, ignote all’orario stagionale e provenienti direttamente dalle compagnie ( voli
cancellati, voli charter, voli sostitutivi, ecc ), rendendole disponibili in lettura a qualunque
sistema ne abbia necessità
•
Mantiene aggiornati i dati di monitoraggio operativo provenienti dai diversi sistemi
permettendo di archiviarli in un’apposita base dati di raccolta storica.
Il sistema informativo mette a disposizione i sottosistemi e i dati a tutti gli operatori aeroportuali, al
fine di garantire il corretto scambio delle informazioni sulle attività operative dello scalo.
Il scalo gestisce e distribuisce, attraverso il sistema BDV, in modalità standard le seguenti
informazioni:
•
Identificatori del volo e dati di orario operativi
•
Identificatori di movimento, dati di orario e di operatività programmati
•
Stato operativo del volo
•
Risorse di scalo associate al volo
Mentre gestisce e distribuisce a richiesta, i seguenti dati:
•
Dati di carico finalizzati all’handling del volo
•
Specifiche di servizio
•
Risorse di handling associate al volo
•
Parametri di scalo
13
1.4 Servizi di handling
Una parte fondamentale dei servizi forniti all’utenza sono i servizi di handling, cioè tutti i servizi di
assistenza a terra agli aeromobili, passeggeri, bagagli, merci e posta, ed alle operazioni in pista.
Con il termine handling si è soliti indicare tutti i servizi di assistenza aeroportuale:
•
Prestazioni rese ai passeggeri: biglietteria, accettazione, informazioni.
•
Prestazioni inerenti ai velivoli: carico e scarico, pulizie, rifornimenti, guida al parcheggio.
•
Prestazioni inerenti le merci: carico e scarico, stoccaggio, documentazione.
L’ENAC, per ragioni inerenti la sicurezza, alla capacità o allo spazio disponibile nell’aeroporto, può
limitare il numero di prestatori di alcune categorie di servizi ( assistenza bagagli, assistenza
operazioni in pista, assistenza merci e posta, etc.); questi servizi hanno, quindi, una infrastruttura di
controllo centralizzata.
1.4.1 Servizi di rampa
Il termine mezzi di rampa sta ad indicare tutti quei mezzi che sull’airside sono adibiti ai servizi di
handling, per tutti i velivoli in fase di stazionamento o di movimento sull’apron.
Questi veicoli, semoventi e non, sono utilizzati dagli operatori del settore per le seguenti funzioni:
•
Assistenza al parcheggio del velivolo;
•
Assistenza bagagli, merci, posta, carico e scarico aereo;
•
Trasporto dell’equipaggio;
•
Pulizie di bordo;
•
Climatizzazione della cabina;
•
Rimozione neve o ghiaccio o sbrinamento del velivolo;
•
Assistenza all’avviamento del velivolo;
•
Assistenza al parcheggio del velivolo;
•
Assistenza ai passeggeri in partenza, in arrivo o in transito;
•
Guida dell’aereo all’arrivo o alla partenza negli spostamenti sull’apron;
•
Rifornimento del velivolo di carburante e di acqua potabile;
14
•
Servizi di catering;
•
Eventuale manutenzione del velivolo;
Tali servizi sono svolti da un insieme di mezzi che sono l’oggetto del ramp management.
Infatti il ramp management è un servizio che si occupa della gestione dei di rampa, che
costituiscono l’handling aeroportuale. I mezzi di rampa sono:
I follow me: mezzi che si occupano di accompagnare l’aeromobile dall’area di manovra alla
piazzola di sosta cui è assegnato e viceversa.
In particolare prendono in consegna dalla torre di controllo ( dal controllore ENAV [3] ) l’aereo, in
corrispondenza dell’area di manovra e lo guidano lungo il piazzale di parcheggio precedendolo.
Sono i soli mezzi ad avere la precedenza assoluta ed a non dover obbligatoriamente rispettare la
segnaletica orizzontale del piazzale se ciò garantisce il rispetto dei livelli di sicurezza delle
operazioni a terra.
Tale mezzi inoltre accompagnano anche i mezzi esterni sul sedime aeroportuale.
Gli interpista: autobus di diverse grandezze, utilizzati per il trasporto dei passeggeri e di equipaggi
tra terminal ed aeromobili, qualora il layout aeroportuale non garantisca la presenza dei loading
bridge atti a tale funzione.
I loading bridge: ponti mobili di carico su ruote o su binari. Fanno parte delle strutture centralizzate
sotto il diretto controllo del gestore aeroportuale e provvedono alla sostituzione dei servizi di: GPU,
condizionamento della cabina, rifornimento acqua potabile e di carburante.
Le scale passeggeri: scale semoventi o non che consentono ai passeggeri e all’equipaggio di
scendere o di salire su aeromobili in scalo, qualora non siano raggiunti da loading bridge.
Gli elevatori per passeggeri disabili: mezzi semoventi utilizzati per consentire l’imbarco e lo sbarco
di passeggeri portatori di handicap, a cui sia impedita la normale deambulazione. La procedura
impone che tali passeggeri siano imbarcati prima degli altri e sbarcati dopo che gli altri abbiano
lasciato il velivolo.
I baggage dolly: carrelli da traino adoperati per il trasporto dei bagagli e/o merci sia in arrivo che in
partenza. Hanno una capacità di 2500 Kg e possono raggiungere una velocità massima di 30 Km/h,
sono presenti due tipologie: coperti e scoperti, primi possono essere utilizzati in qualsiasi
condizione climatica, in modo da garantire un trasporto sicuro dei bagagli e merci.
15
I trattori leggeri: sono trattori piccoli e maneggevoli utilizzati per la movimentazione dei convogli
di baggage dolly, di container e di cargo dolly sulla superficie dell’apron. Sono efficienti in
qualsiasi condizione climatica ed hanno mediamente una capacità di carico di 80 tonnellate.
I conveyor belt loader : nastri trasportatori utilizzati dagli operatori di rampa per velocizzare le
operazioni di carico e scarico bagagli e merci dai velivoli. Hanno una capacità di carico di 120
kg/metro di nastro.
I push back: sono trattori pesanti utilizzati per spostare un aereo in fase di decollo, quando questo
deve lasciare la piazzola, dove si trova in “stallo”, per recarsi nell’area di manovra e decollare,
senza effettuare tale operazione in “self manoeuvering”.
Hanno una grande capacità di carico, infatti sono in grado di spostare anche aerei di grosse
dimensioni.
Elevatori per servizio di catering: mezzi utilizzati per il trasporto e lo stivaggio di cibo e bevande a
bordo dei velivoli.
I GPU ( Ground Power Unit ): sono generatori di potenza utilizzati da velivoli sprovvisi di
APU ( Auxiliary Power Unit ). Tale unità genera energia sia elettrica che sottoforma di aria
compressa, utilizzate per l’alimentazione degli impianti elettrici e dei sistemi pneumatici di bordo.
Possono anche supplire al fabbisogno di energia elettrica del velivolo a motori spenti, quando
staziona sull’apron per lunghi periodi di tempo.
I cargo loader: sono utilizzati per le operazioni di carico e scarico di velivoli che trasportano merci.
Hanno una capacità di carico di circa 7300 Kg ed una velocità massima di 10 Km/h. Le dimensioni
della piattaforma di carico sono standardizzate in funzione del numero e del tipo di unità di carico
da spostare. Le unità di carico adibite al trasporto merci hanno dimensioni specifiche prestabilite
dalla IATA [4] ed identificate tramite un codice alfanumerico.
I cargo dolly: sono piattaforme per il carico dei container, aventi capacità di carico di 7300 Kg,
trainate da trattori leggeri.
Gli ASU ( Aircraft Starter Unit ): veicoli semoventi o a rimorchio utilizzati per agevolare
l’accensione di un velivolo in partenza. Inviano aria ad una determinata pressione, al sistema
pneumatico dei compressori dei turboreattori.
I veicoli per il rifornimento di carburante: autobotti utilizzate per il rifornimento dei velivoli. Sono
equipaggiati con una scala a rimorchio utilizzata dagli operatori per raggiungere i bocchettoni sotto
le ali del velivolo. Visti i rischi di elevate infiammabilità del combustibile utilizzato dai velivoli, le
operazioni di rifornimento devono avvenire sempre nel massimo rispetto delle norme di sicurezza.
Ogni piazzola che ospita un velivolo viene sempre comunque dotata di particolari tipi di estintori
utilizzabili nel caso si verifichino situazioni pericolose.
16
I veicoli di servizio toilette: vengono utilizzati a richiesta, durante lo stazionamento dei velivoli, con
l’ausilio di mezzi, dotati di una piccola cisterna, può essere effettuato il servizio di evacuazione
delle toilette di bordo.
I veicoli di rifornimento acqua potabile: piccole autobotti che permettono il rifornimento dei
serbatoi idrici dei velivoli rimasti sprovvisti di acqua potabile, durante lo stazionamento. La
procedura impone che, ogni volta che viene effettuato il rifornimento di un velivolo, l’intera
cisterna debba essere scaricata e rifornita nuovamente.
In figura 2 riportiamo un esempio del posizionamento di questi mezzi di rampa:
Figura 2: esempio di posizionamento handling
17
I veicoli vengono posizionati radialmente, così che il posizionamento di uno di essi non ostacoli il
movimento degli altri. Inoltre durante il rifornimento di un velivolo, tutti i vari mezzi di rampa sono
provvisti di un’opportuna via di fuga, che velocizza le operazioni di sgombero della piazzola, ad
esempio in caso di incidente.
1.4.2 Funzionalità
In questo paragrafo vengono esposte, in modo più preciso, le funzionalità di alcuni elementi
descritti in precedenza, alfine di individuarne i compiti precisi.
Ognuno di questi viene coordinato e supervisionato dal coordinamento scali ( Sala di controllo ),
che definisce la procedura operativa da attivare.
I primi i servizi di cui si parla sono quelli che costituiscono l’apron management. Questi servizi
erogati congiuntamente dalla società di gestione ed ENAV, hanno lo scopo di garantire il
movimento di aeromobili sul piazzale in condizioni di sicurezza ed efficienza operativa.
L’apron management opera un coordinamento informativo tra i soggetti responsabili dei servizi di
ground handling e le funzioni ENAV che amministrano l’accesso alle infrastrutture dello scalo.
La sala apron è situata all’interno della torre di controllo, a norma della regolamentazione I.C.A.O.
[5] e nel rispetto delle competenze, il servizio ha l’obiettivo di:
•
Ridurre al minimo il rischio di conflitti tra aeromobili e veicoli;
•
Ridurre al minimo il rischio di conflitti tra veicoli e veicoli;
•
Migliorare la sicurezza degli operatori che si muovono sull’apron senza l’ausilio di mezzi
semoventi;
•
Raggiungere un’efficace gestione del flusso di traffico;
Il coordinamento scali fornisce il servizio di follow me agli operatori nelle seguenti condizioni
operative:

Guida degli aeromobili sul piazzale e sulle vie di rullaggio in condizioni di scarsa
visibilità ( su richiesta della compagnia aerea o della torre );

Movimento degli aeromobili per motivi tecnici od operativi, non inerenti le
operazioni di atterraggio e decollo, sulle vie di rullaggio in aree coordinate dalla
torre di controllo: rientrano in questa casistica i decentramenti per prova motori o
18
riposizionamento tra i due terminal. Per questa classe di eventi il servizio è
obbligatorio;

Guida degli aeromobili al parcheggio, in condizioni particolare e/o su richiesta della
compagnia;

Accompagnamento di mezzi esterni sul sedime aeroportuale, che vengono autorizzati
alla circolazione all’interno del sedime a condizione che siano guidati dal mezzo
follow me. Il servizio in tale situazione è obbligatorio;

Guida degli aeromobili in condizioni particolari di limitazioni del movimento sul
piazzale per lavori in corso. Il servizio è reso obbligatorio da NOTAM [6];

Guida degli aeromobili a fronte di manovre errate compiute dagli stessi o situazioni
di conflitto nell’accesso alle taxi-ways e link. Il servizio è richiesto dalla torre o dal
coordinamento scali, cioè anche quando non richiesto dalla compagnia aerea è
comunque obbligatorio usufruire del servizio;
Figura 3: Servizio di follow me
19
Traino aeromobili:
Il servizio comporta l’utilizzo di un push back ed è fornito nelle seguenti situazioni:

Richiesta inoltrata dalla compagnia: la richiesta di movimentazione di un aeromobile da
parte di una compagnia dev’essere inoltrata al coordinamento scali.
Le richieste saranno soddisfatte in base alla disponibilità di risorse ed alle implicazioni
operative connesse alle operazioni di push-back ed ai rullaggi.
In caso di traino alla posizione prova motori la compagnia dovrà fornire un orario stimato
per il rientro.

Richiesta effettuata dal coordinamento scali: in questo caso è il coordinamento scali ad
inoltrare la richiesta alla compagnia aerea.

Riposizionamento da arrivo per partenza e viceversa, il coordinamento scali provvederà, il
giorno precedente il programma di massima di tali operazioni, ad inoltrare la richiesta alla
compagnia aerea.
20
Figura 4: Servizio di push back
Operazioni di rifornimento:
Il rifornimento di carburante agli aeromobili deve essere effettuato nel rispetto delle norme di
sicurezza.
Le operazioni di rifornimento si intendono eseguite a cura e sotto la responsabilità dell’esercente
dell’aeromobile, indipendentemente dalle misure di sorveglianza e di controllo adottate dalle
autorità aeroportuali.
L’esercente dell’aeromobile deve assicurare la presenza di una persona competente, responsabile
del rifornimento, che garantisca l’osservanza delle procedure e sia in contatto con il responsabile
del servizio della società petrolifera. L’esercente e la compagnia petrolifera possono concordare che
le funzioni di rifornimento vengano effettuate dallo stesso responsabile della compagnia petrolifera.
21
Figura 5: operazioni di rifornimento
De-icing / De-snowing:
Le procedure di de-icing e de-snowing, anti-icing e de-snowing vengono svolte sotto responsabilità
del vettore aeroportuale, che deve farne prima richiesta al Coordinamento Scali.
Lo stoccaggio del liquido utilizzato per le operazioni di de-icing e di de-snowing è a carico del
Coordinamento Scali che è responsabile di renderlo in quantità adeguata al volume degli interventi
prevedibili per le caratteristiche ambientali dello scalo e per la tipologia ed i volumi di traffico
programmati. Il mezzo che permette l’operazione di de-icing è il de-icer presente in figura 5.
22
Figura 6: de-icing
Dopo aver esposto dettagliatamente le funzioni di alcuni dei servizi di apron management, parliamo
dei Loading bridge:
Il coordinamento scali definisce un programma stagionale, sulla base del traffico programmato, di
pre-assegnazione delle posizioni di stazionamento aeromobili.
I dati di pre-assegnazione sono distribuiti attraverso i sistemi di scalo agli operatori interessati (
handling agent, compagnia aerea, etc ).
Il coordinamento scali definisce nella giornata precedente a quella operativa, il programma di
assegnazione giornaliero, sulla base delle reali condizioni di traffico sullo scalo e della possibilità di
impiego delle strutture ( es. presenza guasti, attività di manutenzione programmata ).
Tra le unità preposte all’attività di assegnazione dei bridge e gli operatori aeroportuali coinvolti,
devono essere scambiate informazioni che possono interessare l’operatività dello scalo, relative a:
23
•
Variazioni dell’attività operativa a terra ( aggiornate dall’handling );
•
Variazioni dell’orario dei voli ( aggiornate dalle compagnie aeree);
•
Malfunzionamenti o guasti delle infrastrutture o della strumentazione: la persona che rileva
l’anomalia o il malfunzionamento tecnico deve darne comunicazione, per quegli impianti
con impatto diretto sulla capacità aeronautica, al proprietario
dell’impianto/sistema/attrezzatura e quindi alla sala controllo del coordinamento scali che
successivamente informerà i reparti manutentivi; mentre per quegli impianti che non hanno
un diretto impatto sulla capacità operativa dovrà darne comunicazione ai reparti manutentivi
che successivamente informeranno la sala controllo del coordinamento scali.
Per ulteriori dettagli si rimanda a [7];
1.4.3 Schematizzazione funzionalità del sistema
Riportiamo adesso un insieme di schemi che permette di comprendere la funzione del ramp
management ed analizzare il sistema che permette questo tipo di funzione. Si procederà poi ad
un’analisi dei requisiti. Gli attori considerati in questo insieme di grafici sono: il duty manager ed i
servizi di follow me, push back, Tecnici dell’aeroporto, de-icer.
Quelli non considerati hanno all’incirca funzioni analoghe.
Il primo schema riporta il duty manager, che è l’attore che effettua una pianificazione e prende
decisioni sulle azioni da compiere.
Esso per gestire i mezzi di rampa compie tre azioni principali:
comunicare con i servizi di ramp management, assegnare loro compiti, fare un monitoring del
sistema. Nello schema 1.1 sono riportate le sue funzioni.
Quindi i requisiti di questo attore saranno:
•
Un sistema che permette di comunicare; tale sistema deve avere un accesso ristretto e sicuro,
inoltre deve garantire una trasmissione dati efficiente;
•
Capacità di assegnare compiti;
•
Servizio che permette il monitoraggio del sistema in modo tale da controllare tutti i mezzi
presenti ed attivi all’interno dell’aeroporto;
24
Schema 1.1: duty manager
Una vista più completa della funzione del duty manager è data dallo schema 1.1.1, dove gli attori
del ramp management sono indicati con il termine “operatore generico”.
Nello schema sostanzialmente ci sono questi due attori, duty manager ed un operatore generico, che
scambiano messaggi; questo tipo di comportamento è comune a tutti gli attori del ramp
management, che lo ereditano per specializzazione.
25
System
Assegna i compiti ai mezzi di "ramp management"
Operatore generico
Duty manager
Comunica con i mezzi di "ramp management"
Effettua un monitoring del sistema
Schema 1.1.1: duty manager
Di seguito è riportata la descrizione in forma testuale dei casi d’uso del duty manager, in tutti i casi
d’uso il prerequisito è la possibilità di scambiare messaggi e quindi che ci sia un sistema atto a tale
funzione. Ci sono due tipi di estensioni: una è quella che si verifica quando un operatore non è
disponibile ( non connesso al sistema ), l’altra riguarda il caso d’uso “ effettua un monitoring del
sistema” che non può essere portato a termine se il sistema è inattivo.
26
Nome caso d'uso: comunica con i mezzi di "ramp management"
Attori partecipanti: operatore generico, duty manager
Flusso di eventi:
1.Invia un messaggio
2.Riceve un messaggio
Prerequisiti:
1.Sistema che permette lo scambio messaggi
Extends:
1.L'operatore non è disponibile
Nome caso d'uso: effettua un monitoring del sistema
Attori partecipanti: duty manager
Flusso di eventi:
1.Il duty manager visualizza gli operatori connessi
2.Determina i piani relativi ad ogni operatore
Extends:
1.Sistema inattivo
Nome caso d' uso: assegna compiti ai mezzi di "ramp management"
Attori partecipanti: operatore generico, duty manager
Flusso di eventi:
1.Il duty manager decide quale task assegnare
2.Invia il task
3.Verifica la risposta
Prerequisiti:
1.Sistema che permette lo scambio messaggi
2.Conoscenza del task da assegnare
Extends:
1.L'operatore non è disponibile
Schema 1.1.1: duty manager
27
Lo schema 1.2 è quello del servizio di follow me.
Questo operatore ha due casi d’uso propri e due ereditati dall’operatore generico prima esposto.
I casi d’uso quindi sono quattro: Comunica con gli altri mezzi, comunica con il duty manager,
accompagna mezzi esterni sul sedime aeroportuale, accompagna gli aeromobili sul piazzale e sulle
vie di rullaggio.
Quindi l’insieme dei requisiti di questo attore sono:
•
Un sistema per comunicare; questa volta, tale sistema, oltre a rispettare i requisiti precedenti
deve anche permettere al follow me di comunicare con gli altri mezzi di rampa per ottenere
da essi un attegiamento cooperativo.
Nello schema 1.2 inoltre viene riportata una specifica dei casi d’uso propri di questo attore:
“accompagna i mezzi esterni sul sedime aeroportuale” e “accompagna gli aeromobili sul piazzale e
sulle vie di rullaggio”.
L’estensione dei due casi d’uso è la stessa ed è quella che riguarda il guasto del sistema o una
situazione di allerta generica.
28
Operatore generico
Accompagna i mezzi sul sedime aeroportuale
Follow me
Accompagna gli aeromobili sul piazzale e sulle vie di rullaggio
Nome caso d'uso: Accompagna i mezzi sul sedime aeroportuale
Attori partecipanti: Follow me
Flusso di eventi:
1.Il duty manager inoltra una richiesta
2.L'operatore richiede la posizione del mezzo
3.Il duty manager fornisce la posizione attuale
4.L'operatore richiede dove accompagnare il mezzo
5.Il duty manager fornisce la posizione e il percorso
5.L'operatore fornisce il risultato dell'operazione
Extends: Guasto generico o situazione di allerta
Prerequisiti: L'operatore è connesso ad un sistema
Nome caso d'uso: Accompagna aeromobili sul piazzale e sulle vie di rullaggio
Attori partecipanti:Follow me
Flusso di eventi:
1.Il duty manager inoltra una richiesta
2.L'operatore richiede la posizione del velivolo
3.Il duty manager fornisce la posizione attuale
4.L'operatore richiede dove accompagnare il velivolo
5.Il duty manager fornisce la posizione ed il percorso
Schema 1.2: follow me
29
Lo schema 1.3 riguarda il servizio di Tecnici dell’aeroporto.
Questo operatore ha un caso d’uso specifico e due ereditati dall’operatore generico
I casi d’uso quindi sono: comunica con gli altri mezzi, comunica con il duty manager, conosce la
posizione del velivolo.
I requisiti per questo servizio sono:
•
Un sistema per comunicare analogo al caso del follow me
.
Schema 1.3: tecnici dell’aeroporto
30
Lo schema 1.4 riguarda il servizio di push back.
Oltre ad ereditare i casi d’uso dell’operatore generico ne ha uno specifico: “traino aeromobili”.
I casi d’uso quindi sono: comunica con gli altri mezzi, comunica con il duty manager traina gli
aeromobili.
Quindi l’insieme dei requisiti di questo attore sono:
•
Un sistema per comunicare analogo al precendente
Nome caso d'uso: traina gli aeromobili
Attori coinvolti: Push back
Operatore generico
Flusso di eventi:
1.Il duty manager inoltra la richiesta
2.L'operatore richiede la posizione del velivolo
4.Il duty manager risponde
Traina gli aeromobili
Push back
Schema 1.4: push back
31
Lo schema 1.5 riguarda il servizio di de-icer.
Questo oltre ad ereditare i casi d’uso dell’operatore generico ne possiede uno specifico: “De-icing /
De-snowing”.
I casi d’uso dunque sono: comunica con gli altri mezzi, comunica con il duty manager, De-icing /
De-snowing.
Quindi i requisiti di questo attore sono:
•
Un sistema di comunicazione con il duty manager.
Nome caso d'uso : De-icing / De-snowing
Attori coinvolti: De-icer
Operatore Aeroportuale
Flusso di eventi:
1.Il duty manager inoltra la richiesta
2.Il duty manager inoltra la posizione del velivolo
3.L'operatore risponde se disponibile
Extends: guasto generico o situazione di allerta
De-icing / De-snowing
Prerequisiti: l'operatore è connesso ad un sistema
De-icer
Schema 1.5: De-icer
32
Infine riportiamo una funzione che può esser comune a tutti i mezzi di rampa cioè il caso d’uso
“comunica con gli altri mezzi di rampa“.
In questo modo si pensa di avere un attegiamento cooperativo di tutti i mezzi di rampa presenti, in
caso di allerta o di guasti.
Una delle due estensioni del caso d’uso riguarda il caso di un operatore malizioso che potrebbe
attentare alla sicurezza del sistema aeroportuale.
Operatore aeroportuale 1
Comunica con i mezzi di rampa
Nome caso d'uso: Comunica con i mezzi di rampa
Attori coinvolti: Operatore aeroportuale 1, Operatore aeroportuale 2, Operatore aeroportuale 3
Flusso di eventi:
1.Un operatore invia un messaggio ad un altro
Extends:
1.Guasto al sistema
2.Operatore malizioso
Prerequisiti:
1.Gli operatori sono connessi ad un sistema
2.L'operatore è stato autorizzato dal duty manager a comunicare
Schema 1.6: ulteriori funzionalità
33
1.4.4 Requisiti non funzionali
:
1)Discovery degli attori presenti: deve essere presente un servizio che indica la disponibilità di un
attore ed eventualmente di ottenere un riferimento ad esso.
2)Utilizzo di tecnologie open source: si vogliono utilizzare le tecnologie open source presenti sul
mercato in particolare per la realizzazione dei servizi che il sistema deve fornire.
3)Portabilità dei servizi: capacità dei singoli servizi ed attori di poter migrare su piattaforme
diverse.
4)Tolleranza ai guasti: il sistema sviluppato deve essere tollerante ai guasti.
5)Fronteggiare la scarsa capacità dei dispositivi: le prestazioni devono essere adeguate anche in
ambiente mobile in cui bisogna far fronte alla scarsa disponibilità di risorse.
6)Cooperazione: si vuole fornire agli attori del sistema la capacità di cooperare.
7)Trasparenza dal sistema operativo: indipendenza da un particolare sistema operativo che può
essere disponibile su un dispositivo mobile su cui installare il sistema di supporto al ramp
management.
8)Scalabilità: deve essere possibile aggiungere nuovi componenti e funzionalità al sistema
34
1.4.5 Architettura del sistema
Dopo aver illustrato gli attori, le loro funzionalità e requisiti possiamo dire che c’è una parte del
sistema comune a tutti gli attori. Questa parte è quella che garantisce la comunicazione che può
essere implementata grazie ad un framework che garantisca i servizi di cui il sistema ha bisogno: la
connessione ad un sistema, la comunicazione con altri utenti del sistema e quindi l’invio e la
ricezione di messaggi.
Questi servizi costituiscono i core services di questa applicazione.
Poi ci sono un insieme di procedure che costituiscono i casi d’uso di ogni specifico attore che
costituiscono servizi aggiuntivi che il sistema dovrebbe fornire.
Schema 1.7: architettura sistema
35
Il sistema di ramp management così come deriva dalla trattazione precedente viene illustrato nello
schema 1.7.
I componenti di colore celeste rappresentano i servizi offerti dal sistema, questi sono suddivisi in
core services ed altri servizi.
I core services sono la registrazione di un utente, l’invio e la ricezione di un messaggio, il discovery
di nuovi utenti e tutta la parte di comunicazione che è comune a tutti gli utenti del sistema.
Gli altri servizi sono quelli propri di ciascun attore del sistema e dovranno essere implementati
seguendo i diagrammi in precedenza esposti.
36
Capitolo 2 – Sistemi multi-agente e JADE
Capitolo 2
Sistemi multi-agente e JADE
2.1 Motivi della scelta
Nel primo capitolo sono state messe in luce le caratteristiche che il framework di nostro interesse
deve offrire e i requisiti di cui abbiamo bisogno.
Dopo aver studiato le tecnologie presenti sul mercato è stata proposta l’architettura multi-agente ed
in particolare JADE.
I motivi di questa scelta sono:
1) Agenti autonomi e cooperativi: ogni attore del nostro sistema può essere un agente e quindi
agire autonomamente, ciò è molto importante in quanto il sistema che si vuole andare a
creare è un sistema autonomo.
In particolare verranno implementate delle procedure che richiedono esecuzioni automatiche
svolte dagli agenti. Inoltre gli agenti possono agire in modo cooperativo tra loro.
2) Gli agenti possono manifestare un comportamento di tipo “goal oriented” cioè può essere
assegnato un obiettivo comune a più agenti.
3) Un agente può essere reattivo, cioè percepisce l’ambiente e risponde ai suoi cambiamenti
4) Un agente può essere proattivo, cioè non agisce soltanto percepisce in relazione ai
cambiamenti dell’ambiente circostante,ma può anche prendere iniziativa mostrando un
comportamento “goal directed”.
5) Supporto in ambiente mobile: JADE fornisce un supporto in ambiente mobile con
un’implementazione per dispositivi mobili. Inoltre grazie ad un algoritmo di bilanciamento
del carico evita l’eccessivo consumo di risorse.
37
6) Supporto alla security: è presente in JADE un supporto alla sicurezza con autenticazione
degli utenti e criptazione dei messaggi.
7) Licenza di tipo open source: JADE è distribuito sotto licenza open source ( LGPL )
In questo capitolo viene illustrato il concetto di agente software di sistema multi-agente e le
principali caratteristiche di entrambi.
Viene poi posta l’attenzione su un particolare sistema, JADE ( Java Agent Development
Framework ), sviluppato da TILab di Torino in collaborazione con l’Università di Parma [8].
2.2 Gli Agenti Software
Un agente è un’entità software presente in ambienti vari ed eterogenei, capace di agire
autonomamente in questo ambiente, in modo da poter portare a termine gli obiettivi per i quali è
stato progettato.
La ragione dell’esistenza e della diffusione degli agenti va ricercata nel fatto che l’informatica si è
mossa sempre più verso cinque concetti:
1) Ubiquità: ubiquità delle risorse intesa nel senso di elaborazione mobile e di pervasive
computing.
2) Interconnessione: non si pensa più ai computer isolati ma interconnessi in sistemi distribuiti.
3) Intelligenza: i compiti che ci aspettiamo di poter delegare ai computer siano sempre più
complessi.
4) Delega: lasciare il controllo ai computer anche in situazioni critiche.
5) Human orientation: si tende sempre di più a ragionare sulle macchine in termini di concetti
e di metafore simili al modo in cui noi percepiamo il mondo.
Gli agenti siano utilizzati in molti ambiti, quali la robotica, sistemi di controllo, sistemi di
automazione e nel caso degli agenti assistenti.
Esempi di sistemi di controllo che utilizzano gli agenti software sono quelli della “ROCKWELL”
azienda che ha deciso di implementare gli agenti software sui suoi PLC, invece un esempio di
agenti assistenti sono quelli implementati dalla “MICROSOFT” che ha introdotto nella suite di office
38
degli Agenti Assistenti, con il compito di dare suggerimenti agli utenti per utilizzare al meglio i
prodotti.
Le caratteristiche degli agenti possono essere espresse attraverso degli aggettivi che ne descrivono
anche il funzionamento e l’utilità:
1) Autonomo: agisce senza un intervento esterno, ed ha il controllo delle sue azioni e del suo
stato interno.
2) Sociale: collabora con l’ambiente esterno e con altri agenti per il raggiungimento di un
obiettivo.
3) Reattivo: percepisce l’ambiente in cui si trova e risponde ai cambiamenti che avvengono in
esso.
4) Proattivo: agisce non soltanto in risposta ai cambiamenti dell’ambiente in cui si trova, ma
può anche prendere iniziativa mostrando comportamenti “goal-directed”.
5) Mobile: può migrare attraverso diversi nodi presenti nella rete.
6) Veritiero: non fornisce deliberatamente false informazioni
Inoltre altri aggettivi di un agente sono: persistenza, benevolenza, versatilità.
In un certo senso un agente può esser visto come un oggetto ( OOP ) con un obbiettivo, ma ci sono
alcune sostanziali differenze tra i due elementi:
Oggetto
•
•
•
Agente
Incapsula uno stato e lo controlla
Incapsula uno stato e lo controlla
attraverso i metodi.
attraverso i metodi ed i suoi obiettivi.
Passivo, non ha controllo sull’esecuzione
Attivo, decide quando e come
dei metodi.
agire.
Non autonomo.
Autonomo.
Il termine agente appartiene anche all’intelligenza artificiale, il cui compito è quello di replicare
l’intelligenza umana. Tipicamente però lo scopo dei sistemi multi-agente è più limitato, volendo
intendere sistemi capaci di fare qualcosa di utile in un ambiente spesso circoscritto.
39
Nonostante, questo i sistemi di agenti sono spesso considerati la più importante espressione della
DAI – Distributed Artificial Intelligence.
Ne sistemi multi-agente si tende spesso a ridurre l’intelligenza del singolo agente in favore
dell’intelligenza collettiva, infatti spesso l’attenzione è nel coordinamento più che nelle capacità del
singolo.
Nei MAS ( Multi-Agent System ) infatti gli obiettivi principali sono: il coordinamento, la
capacità/volontà di cooperazione, la negoziazione.
2.3 Architetture sistemi multi-agente
Ci sono vari tipi di architetture per sistemi multi-agente, esse possono essere suddivise in quattro
gruppi fondamentali:
1) Logic Based
2) Reattivi
3) BDI
4) Layered
Nel primo caso l’architettura è di tipo knowledge based, cioè l’ambiente è rappresentato in modo
simbolico, e gli obiettivi, per i quali l’agente è stato progettato, sono raggiunti attraverso tecniche di
ragionamento simboliche.
Il vantaggio di usare questo approccio è che la conoscenza umana, molte volte è di tipo simbolico,
e quindi codificarla, e trasmetterla ad un sistema è molto semplice. Inoltre una volta trasmessa
all’agente tale conoscenza, ad esempio dell’ambiente circostante, può essere semplice da
comprendere nel caso si voglia capire che tipo di ragionamento fa un agente.
Lo svantaggio è che la conoscenza può essere molto complessa, e la sua manipolazione può
rallentare molto il processo di esecuzione, di un agente, con tempi di risposta troppo lenti per essere
utilizzati.
La seconda architettura, basata su agenti di tipo reattivo, che prendono decisioni sulla base di un
meccanismo di tipo stimulus-response e si basano sul modello di Brooks [9].
Diversamente dalle architetture di tipo logic based, queste non hanno un modello di riferimento
simbolico dell’ambiente esterno, e perciò non utilizzano meccanismi complessi di ragionamento.
40
Questo modello può essere spiegato attraverso la figura 7, dove sono rappresentati degli strati di una
macchina a stati finiti, che sono connessi a sensori che trasmettono informazioni in tempo reale:
Figura 7: esempio di architetture di agenti reattivi
Questi strati formano una gerarchia di comportamenti, dei quali, quelli più bassi hanno meno
controllo rispetto a quelli più alti. In base a questo esempio si capisce che gli agenti, che rispettano
questo modello, percepiscono le condizioni ed agiscono ma non fanno una pianificazione.
Il vantaggio di questo approccio è che in scenari che cambiano rapidamente, abbiamo tempi di
risposta più brevi, lo svantaggio è che i dati provenienti dai sensori possono non essere sufficienti a
determinare l’azione da compiere.
Il terzo tipo di architettura è quella BDI (Belief Desire Intention) che trae origine dalla filosofia ed
offre una logica per definire gli stati mentali, di convinzione, desiderio, intenzione.
Le convinzioni sono le aspettative dell’agente rispetto all’ambiente esterno, i desideri di un agente
sono le preferenze rispetto ai cambiamenti dell’ambiente circostante e la sua linea d’azione, le
intenzioni sono il set di obiettivi per i quali l’agente è stato progettato.
Un’implementazione del modello BDI è PRS ( Procedural Reasoning System ) che si basa su
cinque concetti chiave: convinzioni, desideri, intenzioni, pianificazione, ed un interprete.
Rispetto ad un’architettura BDI sono stati aggiunti due elementi.
Il primo, la pianificazione, che rappresenta la linea d’azione, che un agente deve seguire per portare
a termine i suoi obiettivi ed il secondo, un interprete che seleziona l’azione da compiere in base alle
intenzioni correnti dell’agente.
41
Uno schema rappresentativo dell’architettura PRS è il seguente:
Figura 8: architettura PRS
L’ultima architettura considerata è quella stratificata che permette sia agenti di tipo reattivo che di
tipo deliberativo. Per ottenere questa flessibilità l’architettura è organizzata in strati di tipo
gerarchico. Ci sono due tipi di stratificazioni, quella orizzontale e quella verticale, nella prima tutti
gli strati sono direttamente connessi con l’input dato dai sensori e l’output è l’azione da compiere,
nella seconda l’informazione è passata solo ad uno strato alla volta.
Il vantaggio di un’architettura di tipo orizzontale è che se si necessita di n tipi di comportamenti c’è
bisogno soltanto di n strati, il principale svantaggio è che ciascuno strato rappresenta un agente e le
loro azioni possono essere inconsistenti, dando origine a conflitti.
Nel caso di un’architettura di tipo verticale il vantaggio è che l’interazione tra i diversi strati è molto
ridotta rispetto al caso orizzontale, lo svantaggio è che se c’è un guasto in uno strato l’intero sistema
viene bloccato, quindi è un’architettura intollerante ai guasti.
Uno schema di riferimento è quello in figura 9.
42
Figura 9: architettura a strati
2.4 Comunicazione e coordinamento
La comunicazione è una delle componenti più importanti in un sistema multi-agente, infatti gli
agenti per cooperare e coordonarsi tra loro hanno bisogno di scambiare messaggi.
Gli agenti comunicano tra loro usando speciali linguaggi di comunicazione che si basano sulla
teoria Speech act [9] [10], che prevedono una separazione tra il contenuto del messaggio ed il tipo
di messaggio ( performatives ), cioè l’intenzione che il messaggio vuole trasmettere.
Uno dei primi linguaggi di comunicazione tra agenti è stato il KQML [11], attualmente il
linguaggio per lo scambio messaggi tra agenti più utilizzato è FIPA ACL che deriva dallo stesso
KQML.
Gli aspetti principali di FIPA ACL, sono la possibilità di scelta tra diversi linguaggi per i contenuti
e tra vari tipi di protocolli di interazione.
Il coordinamento è un processo molto importante, tramite il quale gli agenti riescono a cooperare.
Ci sono diverse ragioni del perché gli agenti debbono cooperare:
1) Le azioni che gli agenti svolgono per il raggiungimento degli obiettivi possono creare
conflitti.
2) Gli obiettivi degli agenti possono essere comuni.
43
3)Gli agenti possono avere diverse capacità e conoscenze.
4)Gli obiettivi comuni possono essere raggiunti più rapidamente se più agenti lavorano su di
essi.
Ci sono diversi approcci al coordinamento tra gli agenti: Struttura organizzata, contract net, multiagent planning, negoziazione.
Nel primo tipo di approccio [12] il sistema multi-agente ha una struttura predefinita con dei ruoli e
path per comunicare e c’è un agente che ha una larga visione del sistema e forma una struttura
gerarchica.
Il paradigma di comunicazione tra gli agenti è di tipo master/slave o client/server, infatti è il
master che assegna i task e le risorse ai vari slave, riceve inoltre i messaggi che si scambiano i vari
agenti e crea dei piani.
Comunque un approccio di questo tipo con una struttura così centralizzata in molti casi è
inapplicabile, data la natura distribuita dei sistemi multi-agente.
Un altro approccio è quello della contract net [13] in questo caso abbiamo una struttura
decentralizzata e un agente può assumere due ruoli: manager e contraente.
Il concetto alla base di questo tipo di approccio è che se un agente non è in grado di svolgere un
determinato compito, in base alle proprie risorse, lo scompone in più sottoproblemi.
La risoluzione di questi problemi è assegnata agli agenti seguendo questi passi: il manager
annuncia il contratto, uno o più agenti rispondono all’offerta, il manager decide qual’è l’offerta
migliore e lo comunica. In figura 10 vengono rappresentati questi passi che portano alla
sottomissione del task.
44
Figura 10: contract net
Nell’approccio multi-agent planning [14] viene fatta una pianificazione che esprime in modo
dettagliato tutte le azioni che gli agenti compieranno, tutte le interazioni che ci saranno tra di loro
per compiere il set di obiettivi. Il planning può essere sia centralizzato che distribuito.
In quello di tipo centralizzato c’è un agente principale che riceve tutti i piani locali e parziali degli
agenti, analizza questi per rilevare contrasti e inconsistenze, dopodichè fa una modifica eliminando
tutte le possibili situazioni di conflitto che potrebbero sorgere e crea un piano generale che non
presenta conflitti.
Nel caso distribuito ciascun agente ha un modello del piano degli altri agenti, essi quindi
comunicano e migliorano i loro piani individuali eliminando i conflitti.
L’approccio negoziazione [15] consiste nel raggiungere un accordo sui problemi che si presentano,
può essere di due tipi, cooperativo o competitivo, in dipendenza dal comportamento degli agenti
coinvolti.
La negoziazione competitiva è usata in situazioni nelle quali gli agenti hanno degli obiettivi che
possono creare conflitti e non c’è un atteggiamento cooperativo. La negoziazione cooperativa è
utilizzata in situazioni in cui gli agenti hanno un obiettivo comune o un singolo task da eseguire.
In questo caso il sistema è pensato per portare a termine un solo obiettivo.
Inoltre c’è un ultimo approccio, Partial global planning [16], che unisce i punti di forza di altri tre:
struttura organizzativa, contract net e planning.
45
2.5 Lo standard FIPA
L’organizzazione internazionale FIPA ( Foundation for Intelligent Physical Agents [17] ), nata nel
1996, è un’associazione no-profit, che ha come scopo quello di fornire standards utili per le
industrie nella realizzazione di applicazioni commerciali.
In particolare ha studiato il problema dell’interoperabilità tra agenti formulando standards per vari
livelli: trasporto dei messaggi, semantica del linguaggio di comunicazione fra agenti intelligenti e
servizi di gestione di base ( pagine bianche e pagine gialle ).
FIPA fornisce un modello di riferimento ma nessuna implementazione fisica, i dettagli
dell’implementazione e le varie caratteristiche degli agenti dipendono dalle scelte progettuali degli
sviluppatori.
2.5.1 Agent management
FIPA ha creato un modello logico di riferimento per la creazione, registrazione, locazione,
comunicazione, migrazione e operazioni di agenti, questo modello consiste dei componenti presenti
nella figura 11.
46
:
Figura 11: modello di riferimento FIPA
Descrizione dei componenti:
Agent Platform ( AP ): un’infrastruttura fisica nella quale sono sviluppati i componenti. Essa
consiste di macchine, sistemi operativi e componenti FIPA per il management degli agenti ( che
vengono descritti di seguito). Il design interno della piattaforma è lasciato agli sviluppatori e non fa
parte dello standard, inoltre una singola piattaforma può risiedere su più host di conseguenza anche
gli agenti possono essere collocati su diverse macchine.
Agent: un agente è un processo che risiede all’interno di una piattaforma e tipicamente offre uno o
più servizi che possono essere pubblicati per renderli visibili ad altri agenti, la struttura di tali
servizi non è stata standardizzata. Esso deve avere almeno un gestore e deve essere identificato da
un proprio AID ( Agent Identifier ). L’AID è un’etichetta che viene utilizzata all’interno del sistema
per identificare in maniera univoca e non ambigua un determinato agente, inoltre un agente ha un
indirizzo di livello trasporto al quale può essere contattato.
Directory Facilitator ( DF ): è un componente che fornisce un servizio di pagine gialle. Gli agenti
possono registrare i proprio servizi nel DF oppure interrogarlo per conoscere i servizi messi a
disposizione dagli altri agenti. Un AP può supportare qualsiasi numero di DF, che registrandosi ad
altri possono formare federazioni. Non ci sono obblighi da parte degli agenti, essi possono
registrarsi e deregistrarsi quando preferiscono e possono modificare la propria descrizione.
47
Il DF può restringere l’accesso alle informazioni presenti nella sua directory e verificare i permessi
degli agenti che accedono allo stesso DF.
Agent Management System ( AMS ): è un componente che esercita una funzione di controllo
sull’accesso e sull’uso di tutto il sistema: creazione e cancellazione di agenti, supervisiona la
migrazione degli agenti da una piattaforma all’altra.
Per ogni piattaforma esiste un solo AMS che inoltre fornisce un servizio di pagine bianche, infatti
un agente si registra all’AMS e ottiene un AID. Questi AID vengono poi salvati all’interno di una
directory in modo da conoscere il numero di agenti presenti nella piattaforma ed il loro stato.
La descrizione degli agenti, tenuta dall’AMS, può essere modificata e gli agenti possono cercarsi
grazie a questo servizio.
Quando un agente termina la sua esecuzione il suo AID viene cancellato ed è disponibile ad altri
agenti.
L’AMS può provocare lo shut-down di un agente ed ha l’autorità di richiedere l’esecuzione di
operazioni che sono state ignorate.
Message Transport Service ( MTS ): è un servizio che permette la comunicazione fra agenti
localizzati sulla stessa o su diverse piattaforme, i messaggi scambiati hanno un formato che
contiene un insieme di parametri la cui struttra è mostrata in figura 12.
Figura 12: formato dei messaggi
48
2.5.2 Linguaggio FIPA-ACL
Lo standard FIPA specifica in maniera completa e precisa il linguaggio che viene utilizzato nella
comunicazione fra agenti. Questo linguaggio, chiamato ACL ( Agent Communication Language []
), definisce la sintassi e la semantica della comunicazione fra agenti che necessitano di relazioni
complesse per collaborare, competere e negoziare.
Le radici di questo linguaggio sono nella teoria speech act [18], che dice che i messaggi trasmessi
rappresentano delle azioni, anche detti communicative acts, cioè un messaggio ha un intento che è
quello di trasferire le intenzioni e i desideri del mittente al destinatario.
Il linguaggio FIPA-ACL, si basa su 22 communicative acts, un agente per essere FIPA-compliant
deve esser in grado di ricevere uno qualsiasi di questi.
Lo standard FIPA non definisce il linguaggio di espressione dei contenuti.
Un messaggio FIPA-ACL, contiene un insieme di parametri ma l’unico parametro obbligatorio è il
performative, la tabella in figura 13 riporta tutti questi parametri:
Figura 13: parametri di un messaggio FIPA compliant
L’insieme di tutti i communicative acts sono contenuti nella specifica FIPA [17] e sono riportati in
figura 14:
49
Figura 14: FIPA communicative act
50
2.6 La piattaforma JADE
JADE ( Java Agent Development Framework [8]) è un framework per lo sviluppo di applicazioni di
agenti, fornendo servizi conformi allo standard FIPA ed interoperabili con altre piattaforme
conformi allo stesso standard.
JADE è stato sviluppato da TILab s.p.a di Torino, in collaborazione con il Dipartimento di
Ingegneria dell’Informazione dell’Università di Parma.
Esso è distribuito da TILab come software open source, sotto licenza LGPL [19] ( Lesser General
Public License ).
Tale licenza permette di fare copie del software, di distribuire queste copie, di avere accesso al
codice sorgente, di apportare modifiche e miglioramenti ad esso. Nel caso vengano fatti dei lavori
derivati da JADE o dei lavori basati su esso devono essere distribuito sotto la stessa licenza.
JADE è stato interamente scritto in linguaggio JAVA, in particolare l’architettura del sottosistema
di comunicazione sfrutta la moderna tecnologia ad oggetti distribuiti che permette di scegliere a
tempo d’esecuzione il miglior protocollo di comunicazione.
Ci sono alcune scelte di progetto che influenzano il modello di agente e di applicazione:
•
Agenti autonomi e proattivi: un agente ha un proprio thread di esecuzione che usa per
controllare il suo ciclo di vita; decide autonomamente quando compiere un’azione.
•
Sistema peer to peer: ogni agente è identificato da un nome unico ( AID ), può aggiungersi
ad una piattaforma e può lasciarla quando preferisce, può cercare altri agenti attraverso il
servizio di pagine bianche e il servizio di pagine gialle. Un agente può iniziare e terminare
una comunicazione quando preferisce.
La comunicazione è di tipo asincrono, infatti un agente che vuole comunicare manda un messaggio
ad una destinazione ( o ad un set di destinazioni ), e non c’è dipendenza temporale tra il mittente ed
il destinatario, quest’ultimo può anche essere non disponibile al momento dell’invio del messaggio.
Non c’è bisogno di ottenere l’object reference del destinatario, ad esempio per inviare un
messaggio, ma può bastare il nome, infatti è il livello trasporto a risolvere la corrispondenza nomeindirizzo.
51
Elenco delle caratteristiche e dei servizi di JADE:
•
Runtime environment: ambiente dove gli agenti vivono, che dev’essere attivo su un host
prima che uno o più agenti vengono eseguiti.
•
Librerie: una libreria di classi che i programmatori hanno a disposizione per sviluppare i
loro agenti.
•
Tools grafici: una suite di tools grafici che permettono di amministrare e monitorare
l’attività degli agenti. E’ possibile ascoltare le comunicazioni degli agenti, e controllare da
remoto la attività.
•
Un ambiente totalmente distribuito dove gli agenti sono in esecuzione con un proprio
thread, potenzialmente presente su macchine remote. La piattaforma fornisce API che
astraggono l’infrastruttura di comunicazione.
•
Una totale conformità con gli standard FIPA. Inoltre il team di JADE partecipa al processo
di standardizzazione FIPA.
•
Trasporto efficiente ed asincrono di messaggi. La piattaforma evita il marshalling ed
unmarshalling dei dati, infatti quando vengono attraversati i confini di una piattaforma la
sintassi, la codifica e il protocollo di livello trasporto dei messaggi viene trasformato
automaticamente, in modo da rispettare gli standard FIPA.
•
Servizi di pagine bianche e pagine gialle, possono inoltre essere formarte federazioni di
questi.
•
Gestione del ciclo di vita degli agenti semplice. Quando vengono creati gli viene assegnato
automaticamente un identificativo unico e un indirizzo di livello trasporto, che poi viene
utilizzato per il servizio di pagine bianche. Inoltre vengono fornite APIs e tools grafici, in
modo da poter controllare da remoto il ciclo di vita degli agenti; tramite interfaccia è
possibile effettuare le seguenti funzioni: freeze, resume, create, suspend, thaw, migrate,
clone, kill.
•
Supporto alla mobilità. Sia lo stato che il codice di un agente possono migrare da una
macchina all’altra in modo trasparente rispetto alla comunicazione, cioè un agente può
continuare ad interagire anche durante il processo di migrazione.
•
Meccanismo di sottoscrizione. Tramite questo meccanismo gli agenti ed eventualmente
applicazioni esterne possono essere notificati di tutti gli avvenimenti che ci sono all’interno
della piattaforma.
52
•
Supporto per le ontologie e ai linguaggi di contenuti. Il controllo sulle ontologie e sui
linguaggi di contenuti è fatto automaticamente dalla piattaforma, i programmatori possono
scegliere, in base alle loro preferenze, oppure possono crearne nuovi.
•
Integrazione con varie tecnologie Web based: JSP, servlet, applets e web services.
•
Supporto alla piattaforma J2ME e all’ambiente wireless.
•
Un kernel estensibile. Questo permette di estendere le funzionalità attraverso l’aggiunta di
servizi distribuiti di livello kernel.
2.6.1 Architettura JADE
La piattaforma è composta da container, ogni istanza del JADE run time è un container, che
fornisce il JADE run time e tutti i servizi per ospitare ed eseguire gli agenti.
C’è un container speciale, il main-container, che fa da bootstrap per la piattaforma, infatti è il primo
container ad esser lanciato e tutti gli altri container devono unirsi e registrarsi ad esso.
Le principali funzioni del main-container sono:
1. Management del Container Table ( CT ), cioè il registro degli object reference e degli
indirizzi di livello trasporto di tutti i container che compongono la piattaforma.
2. Management del Global Agent Description Table ( GADT ), il registro di tutti gli agenti
presenti nella piattaforma che contiene il loro stato e la loro locazione.
3. Ospitare l’AMS e il DF, che sono gli agenti che provvedono al servizio di pagine bianche e
pagine gialle rispettivamente.
Un esempio dell’architettura è in figura 15, dove è stata inserita anche un’altra piattaforma con il
proprio main-container:
53
Figura 15: architettura con un insieme di piattaforme
Si potrebbe pensare che il main-container è un bottleneck, in realtà è possibile fare delle cache
locali ad ogni container che contengono un Local Agent Description Table ( LADT ), in questo
modo ogni volte che un agente vuole un riferimento ad un altro agente va a cercare prima nella
cache locale, se non lo trova contatta il main-container ed effettua un refresh della sua cache.
Il main-container è comunque unico quindi se subisce un guasto, la piattaforma non può più
funzionare. Per questo motivo sono state pensate tecniche di replicazione del main-container [20],
in modo da ottenere piattaforme fault tolerant.
Come abbiamo già detto l’identità di un agente è contenuta nel suo AID, che è composto da una
serie di slot, in accordo con la semantica definita da FIPA. Il nome dell’agente è creato dalla
piattaforma concatenando il nickname, dello stesso agente, al nome della piattaforma.
Gli agenti speciali, presenti di default, in ogni piattaforma, così come in figura 15, sono il DF e
l’AMS.
54
2.6.2 Message Transport Service
Questo servizio gestisce lo scambio messaggi all’interno della piattaforma e tra le piattaforme.
Per ottenere l’interoperabilità tra i vari tipi di piattaforme ( non JADE ) JADE supporta tutti gli
MTP definiti dallo standard FIPA, dove ognuno di questi include la definizione di un protocollo di
livello trasporto e di una codifica standard dei messaggi.
In figura 16 viene riportata la tabella dei protocolli disponibili, ciascuno contenuto all’interno di un
file jar.
Di default JADE quando viene avviato utilizza il protocollo http che crea una server socket sull’host
del main-container.
Dalla linea di comando tramite opzioni è possibile utilizzare più MTP sullo stesso container.
Tale opzione può essere attivata anche dalla GUI creata dall’agente RMA.
Grazie a questa opzione, si possono individuare agenti, che hanno connessioni aperte verso reti
esterne, aumentando il livello di sicurezza della rete.
Quando su un container, viene attivata una nuova MTP, l’intera piattaforma ottiene un nuovo
indirizzo di livello trasporto, che è un nuovo end-point dove i messaggi possono essere ricevuti.
Infatti questo indirizzo viene aggiunto alle seguenti strutture dati:
•
Platform profile, ottenibile dall’AMS grazie all’azione get-description.
•
Al local AID, che ogni agente su ogni container può ottenere grazie al metodo getAID();
•
All’oggetto ams-agent-description, contenuto nell’AMS repository, ottenibile grazie ad una
operazione di ricerca.
Con la distribuzione principale di JADE, sono dispobili i protocolli IIOP ed HTTP, tutti gli altri
protocolli possono essere scaricati dal sito come add-on.
Grazie alla console JADE RMA è possibile attivare e disattivare gli MTP installati, mentre la
piattaforma è in esecuzione, tramite le opzioni della GUI install a new MTP e uninstall a new MTP.
Tramire un’altra opzione a linea di comando, è possibile disattivare l’MTP che di default è attivo
sul main-container; questo isola la piattaforma dalle comunicazioni con piattaforme remote.
55
Figura 16: message transport protocols
I container della stessa piattaforma comunicano, invece, grazie ad un altro protocollo chiamato
IMTP ( Internal Message Transport Protocol ).
2.6.3 IMTP
IMTP è il protocollo di tipo proprietario, usato per lo scambio dei messaggi tra gli agenti che
vivono in container differenti della stessa piattaforma.
E’ di tipo proprietario perché operando all’interno della stessa piattaforma, può anche non essere
compatibile con gli altri standardizzati dalla FIPA, non è usato soltanto per lo scambio dei messaggi
ma anche per trasferire comandi, come ad esempio lo shut-down di un container.
Esistono due tipi di IMTP uno, attivo di default, che si basa su JAVA RMI [21] ed un altro
utilizzato per i dispositivi mobili, data l’assenza di supporto per JAVA RMI, che può esser aggiunto
come add-on.
Per entrambi i protocolli ci sono opzioni che permettono un fine-tuning, per particolari reti e
particolari dispositivi.
Il protocollo RMI-IMTP è implementato dal package jade.imtp.rmi e stabilisce che quando il maincontainer viene avviato cerca l’RMI registry, se non lo trova ne crea uno nuovo.
Invece quando un container viene avviato cerca l’RMI registry e richiede l’object reference del
main-container, dopodichè invoca il metodo addnode(), dello stesso main-container, e registra il suo
object reference.
56
Sono disponibili opzioni attraverso le quali è possibile specificare l’host e ,attraverso questo, il
main-container al quale agganciarsi oppure specificare il porto dove l’RMI registry riceve rischieste
di look-up e di bind.
2.6.4 Special agents
RMA agent
L’RMA implementa l’interfaccia del sistema per il management della piattaforma.
Fornisce un’interfaccia grafica per amministrare una piattaforma composta da più container e da più
agenti; diversi RMA possono esser lanciati purchè abbiano nomi diversi.
In fase di start-up questo agente si sottoscrive all’AMS per esser notificato su tutti gli eventi della
piattaforma.
Dummy agent
Questo agente permette di inviare stimoli ad un agente sottoforma di messaggi ACL e valutare il
suo comportamento in base alle risposte che vengono ricevute.
E’ possibile tramite interfaccia caricare e salvare messaggi standard.
La figura 17 mostra tale interfaccia, nella parte destra vengono visualizzati i messaggi e nella parte
sinistra possono essere scritti i messaggi.
Più istanze di questo agente possono essere lanciate.
57
Figura 17: interfaccia Dummy Agent
Introspector agent
Questo agente è usato per fare il debug del comportamento di un singolo agente.
Infatti osserva la coda dei messaggi inviati e ricevuti, i comportamenti eseguiti e quelli mandati in
sleeping.
In figura 18 è riportata la sua GUI.
58
Figura 18: interfaccia Introspector Agent
Sniffer agent
Questo tool permette di fare il debug e di documentare, le conversazioni tra gli agenti di una
piattaforma.
Lo sniffer si sottoscrive all’AMS, per esser notificato di tutti i messaggi scambiati da un certo
numero di agenti.
In figura 19 è riportata l’interfaccia di questo agente, la parte destra del pannello permette di
visualizzare lo scambio messaggi la parte sinistra permette di aggiungere agenti al set di quelli da
ascoltare.
59
Figura 19: interfaccia Sniffer Agent
Log manager agent
Permette la creazione e la gestione dei file di Log.
Grazie all’interfaccia grafica può esser scelto il livello di log e del log handler che si vuole
utilizzare, per ciascun componente della piattaforma, tale valori possono anche esser cambiati a
run-time.
60
Event Notification Service
Questo servizio gestisce le notifiche degli eventi generati da ogni nodo della piattaforma.
Ogni volta che un evento viene generato da un container è intercettato dall’ENS ( Event
Notification Service ) e reinviato a tutti gli agenti che si sono sottoscritti per ricevere quel tipo di
notifica.
Questo agente sovracarico molto la piattaforma nel caso in molti nodi siano sottoscritti, è comunque
possibile attivarlo e disattivarlo quando necessario.
I tipi di eventi gestiti sono principalmente quattro:
1) Eventi relativi al ciclo di vita degli agenti e dei container.
2) Eventi relativi agli MTP, cioè quando vengo attivati e deattivati.
3) Eventi relativi ai messaggi, quando vengono ricevuti, inviati.
4) Eventi relativi ai cambiamenti nel comportamento di un agente.
Per illustrare meglio questi agenti viene riportato il diagramma delle classi di figura 20.
Ogni tool, eccetto il Dummy Agent, è implementato come un agente che estende la classe
jade.core.Agent, la classe base di tutti gli agenti.
Tale cosa comporta un insieme di vantaggi:
1) Il ciclo di vita di ogni tool può essere gestito come quello di un qualsiasi agente.
2) La capacità di un agente di poter scambiare messaggi può anche essere sfruttata per la
comunicazione tra tools ed AMS.
3) Diverse istanze dello stesso tool possono coesistere anche all’interno dello stesso container
61
Figura 20: diagramma delle classi degli agenti in JADE
62
2.6.5 Fault-tolerant platform
La tolleranza ai guasti è un requisito molto importante di un sistema, JADE è una piattaforma
distribuita che si poggia sostanzialmente su tre componenti: un main container, l’AMS, ed il DF.
Questi sono chiaramente dei singoli punti di failure e per questo devono essere opportunamente
replicati per assicurare l’esecuzione della piattaforma anche in caso di un guasto.
Questo può essere ottenuto grazie a due espedienti [20]:
•
Main container replication: replicazione del main-container e dell’AMS e
sincronizzazione di tutte le repliche in modo che se un main-container si guasta un
altro prende subito il suo posto.
•
DF persistence: salvare il DF su un Database esterno. In caso di guasto del maincontainer un nuovo DF agent viene avviato ed il suo catalogo viene caricato dal
database.
Main Replication Service
Questo servizio permette la replicazione del main-container di JADE ed è implementato dalla
classe: jade.core.replication.Main-ReplicationService.
Possono essere lanciati un numero qualsiasi di main-container in una piattaforma, di cui uno solo
può essere il master, gli altri sono logici e servono come repliche di backup.
I “non main-container” possono essere eseguiti agganciandosi ad una di queste repliche che sono
sincronizzate tra loro attraverso un servizio di notifica.
Attraverso questo servizio l’amministratore della piattaforma può controllare il livello di scalabilità
della piattaforma ed il livello di tolleranza ai guasti.
Diverse istanze di un main-container possono essere configurate per effettuare un bootstrap
distribuito del sistema.
Nella figura 21 tre main-container sono collegati in un anello unidirezionale nel quale ogni nodo
osserva il comportamento del suo vicino.
Se il main-container-1 subisce un guasto il main-container-2 informa tutti gli altri del guasto.
Viene poi ricomposto un anello più piccolo nel quale sono stati eliminati i nodi guasti.
63
Figura 21: main-container replication
Quando un main-container termina la sua esecuzione per un guasto, tutti i container direttamente
connessi, diventano orfani e si registrano ad un altro main-container.
Questo implica che ciascun container deve avere una lista di tutti i main-container attivi su una
piattaforma.
Ciò può essere fatto in due modi:
1) Per ciascun container la lista dei main-container può essere specificata dalla linea di
comando. Tale metodo può essere applicato quando la lista di main-container è fissata e
nota a priori.
2) Tramite un servizio chiamato Address-Notification Service ( ANS ) di livello kernel che può
essere aggiunto ad entrambri main-containers e non main-containers. Questo servizio
automaticamente rileva l’aggiunta o la rimozione di main-containers e permette la
conoscenza degli indirizzi di tutti i nodi della piattaforma. L’ANS è particolarmente
consigliato in una rete che varia molto rapidamente la sua topologia ed il suo numero di
containers.
64
DFPersistence
Questo servizio permette la replicazione del directory facilitator.
Di default il DF salva il suo catalogo nella memoria principale, garantendo tempi di accesso brevi
ma comportando un incremento lineare del consumo della memoria e problemi di scalabilità
in applicazioni con un gran numero di agenti.
Per ovviare a questi problemi è possibile configurare il DF in modo che salvi in un relativo database
il suo catalogo.
Questo implica il vantaggio di avere un incremento costante del consumo della memoria e inoltre
assicura la tolleranza ai guasti del DF, che combinata con il main-replication service permette di
ottenere una piattaforma completamente fault tolerant.
Lo svantaggio è che salvare il catalogo in un database comporta un incremento dei tempi di accesso,
soprattutto quando si trasferiscono grandi quantità di dati dal database al DF.
JADE mette a disposizione più implementazioni della DF persistence, quella di default è basata
sull’interfaccia Java DataBase Connectivity ( JDBC ) compatibile con la maggior parte dei motori
di ricerca per database.
L’accesso al database può esser configurato con i parametri presenti in figura 22:
Figura 22: parametri di configurazione accesso DB
65
Un’altra implementazione si basa su HSQL [22],un motore per database molto leggero e scritto in
interamente in JAVA.
Tale implementazione non è disponibile con la versione di jade disponibile sul sito, ma dev’essere
scaricata dall’homepage del progetto HSQL [22].
Nei casi in cui nessuna delle due implementazioni soddisfa i requisiti dell’amministratore della
piattaforma, è possibile farne altre ereditando dalle classi:
jade.domain.DFDBKB, jade.domain.DFHSQLKB e dalla classe astratta jade.domain.DBKB.
66
2.6.6 Security in JADE
La sicurezza nei sistemi multi-agente, basati sull’autonomia e sulla mobilità degli agenti, richiede
grande attenzione ed è fornito dall’add-on JADE-S.
Infatti, grazie a JADE-S, tutti i componenti ( agenti e containers ) hanno un proprietario che è un
utente autenticato autorizzato dall’amministratore della piattaforma a compiere solo alcune azioni.
Ogni agente ha a disposizione un chiave pubblica ed una privata con le quali firma e cripta i
messaggi. Di seguito viene spiegato il funzionamento di JADE-S
Autenticazione
Grazie all’autenticazione un utente che vuole avere accesso alla piattaforma, generare containers ed
agenti, ottiene user name e password e può essere considerato un utente sicuro.
In generale un sistema di autenticazione è composto da due elementi: un CallBackHandler, che
fornisce all’utente user name e password, ed un LoginModule che ne verifica la validità.
Il servizio di autenticazione in JADE è basato sulle API JAAS [21] ( Java Authentication and
Autorization Service ), che forniscono un set di LoginModule che sono: Unix, NT, Kerberos e
Simple.
I primi due estraggono l’identità dell’utente dalla sessione corrente del sistema operativo, per questo
motivo dipendono da questo.
Kerberos è indipendente dal sistema operativo ma richiede alcune configurazioni specifiche del
sistema primo dell’uso.
Simple permette un’autenticazione controllata tramite un testo contenuto all’interno di un file che
risiede in una cartella di sistema.
Inoltre la versione attuale di JADE-S fornisce diversi Callbackmodule:
o Cmdline: Username e password sono parametri di configurazione di JADE, possono essere
inseriti sia da linea di comando, o in un file di configurazione.
o Text: Quando il container va in esecuzione richiede l’inserimento di username e password
67
o Dialog: Quando il container va in esecuzione mostra una finestra di dialogo dove possono
essere inseriti username e password
Se vengono riscontrati problemi durante l’autenticazione oppure l’utente fallisce l’autenticazione il
sistema termina l’esecuzione del container e genera un messaggio di errore.
Permessi
Grazie al meccanismo descritto in precedenza tutti i containers e gli agenti sono posseduti da utenti
autenticati.
Tutte le azioni che gli utenti possono fare nella piattaforma possono essere concesse o negate in
accordo a delle regole stabilite. In questo modo è possibile selezionare l’accesso ad alcuni servizi
della piattaforma o a risorse dell’applicazione.
Il set di regole stabilite solitamente sono contenute all’interno di un file chiamato “policy.txt”, che
sedue la sintassi JAVA/JAAS.
Esistono due tipi di file che corrispondono a due tipi di politiche che possono essere stabilite nel
caso dei permessi:
Main-container policy: concede ad ogni agente il permesso di fare qualsiasi azione
Peripheral container policy: che permette agli agenti di compiere azioni nei confronti degli altri
agenti solo all’interno dello stesso container.
Queste politiche, contenute in tali files, riguardano anche l’accesso a risorse ( JVM, FileSystem,
Network ) .
Integrità e riservatezza dei messaggi
La criptazione e la firma garantiscono un certo livello di sicurezza quando viene inviato un
messaggio ACL tra agenti della stessa piattaforma o di piattaforme remote.
La firma fornisce l’identità del mittente la criptazione protegge i messaggi dagli ascoltatori non
autorizzati.
Con JADE-S, sia la Signature che la criptazione è applicata a tutto il payload del messaggio in
modo da proteggere l’informazione contenuta all’interno del messaggio.
68
La firma, l’algoritmo o la chiave di criptazione sono inserite nei parametri del messaggio.
Grazie a tale soluzione l’utente non deve interagire con i meccanismi di criptazione e firma del
messaggio, ma deve soltanto firmare i messaggi e vedere se un messaggio ricevuto è stato firmato.
Qualora si verifichino problemi riguardanti la firma o la criptazione con un messaggio, questo viene
scartato e viene inviato al mittente un messaggio di fallimento dell’invio.
Il supporto alla sicurezza è implementato sotto forma di un set di servizi che possono essere caricati
da linea di comando, essi sono:
jade.core.security.SecurityService: questo servizio è incaricato del meccanismo di
autenticazione, del management della coppia di chiavi e della crittografia.
jade.core.security.permission.PermissionService: questo servizio è incaricato di verificare se
agli utenti è concesso fare determinate azioni, ad esempio inviare messaggi, richiedere all’AMS di
creare o eliminare agenti.
jade.core.security.signature.SignatureService: questo servizio permette di firmare i messaggi e
verificare se quelli ricevuti sono stati firmati.
jade.core.security.encryption.EncryptionService: questo servizio si occupa della criptazione dei
messaggi quando richiesto dal mittente, e della decriptazione dei messaggi ricevuti.
Le limitazioni principali per questo add-on sono:
1. Non sono presenti permessi relativi alla mobilità degli agenti. Quindi una piattaforma, per
garantire un buon livello di sicurezza, deve avere l’Agent Mobility Service disattivato.
2. Le informazioni scambiate tra contenitori della stessa piattaforma sono trasmessi su un
canale SSL ( Standard Secure Channel ) ma non sono firmate. Quindi un utente malizioso
può inviare informazioni errate influenzando il comportamento di altri agenti.
3. Molte delle caratteristiche di questo add-on non sono accessibili da MIDP ( Mobile
Information Device Profile [23]).
Per installare questo JADE-S, è sufficiente effettuare il download ed avere apache ant [24].
69
2.6.7 Add-on per i dispositivi mobili
Quando si sviluppano applicazioni ad agenti su dispositivi mobili, come PDA e cellulari, ci sono un
insieme di constraints (limitazioni) da dover portare in conto.
Queste constraints sono relative a: limitate caratteristiche della JVM ( Java Virtual Machine ) di
questi dispositivi e alla natura delle reti wireless usate come GPRS o UMTS. Di seguito
specifichiamo queste limitazioni.
1)Limitazioni dell’Hardware
I dispositivi mobili hanno dei processori con delle capacità molto modeste, in generale infatti si
parla di frequenza di clock minore di 200MHz e di processori a 16 bit.
Inoltre hanno delle memorie con scarsa capacità, abbiamo memorie di 16 MB per i cellulari e 64
MB per i PDA.
Anche altre limitazioni sono presenti per quanto riguarda l’hardware: batteria di breve durata e
memoria non persistente.
2)Limitazioni relative a Java
La JVM dei dispositivi mobili non fornisce tutte le caratteristiche disponibili nei laptop e desktop
computers. In particolare le specifiche MIDP ( Mobile Information Device Profile disponibili per la
maggior parte dei dispositivi mobili ), quelle CDC [25] o quella più obsoleta Personal Java [25],
non forniscono alcuni supporti per la grafica e le user interfaces.
In MIDP inoltre non c’è supporto per Java reflection [26] e Java Serialization [27].
3)Limitazioni dovute alla rete
JADE assume che i containers tra di loro sono continuamente connessi tramite una rete.
70
Ciascun container deve essere in grado di aprire e accettare una connessione con gli altri containers
in qualsiasi momento.
E tutte le interazioni container-to-container avvengono attraverso il protocollo RMI, che non è
particolarmente efficiente in termini di numero byte trasmessi sulla rete.
Sfortunatamente le reti wireless, come GPRS e UMTS, non rispettano queste supposizioni poiché
sono caratterizzate da:
1. Connessione intermittente: in alcune aree la copertura può essere molto ridotta oppure i
dispositivi possono essere spenti per limitare il consumo della batteria.
2. IP volatile: dopo una temporanea disconnessione l’indirizzo IP del dispositivo potrebbe non
restare lo stesso.
3. Latency e low bandwith: le reti wireless hanno un bit/rate non molto elevato ( 9.6 kbps
GSM 128 kbps GPRS e 1 Mbps HSDPA )
JADE Leap Add-on
Verso la fine del 1999 un gruppo di aziende leader del settore delle telecomunicazioni decisero di
sviluppare una piattaforma per supportare l’implementazione di applicazioni basate su architettura
multi-agente sui dispositivi mobili. Il gruppo era composto da Motorola, Siemens, Ericsonn, British
Telecommunication e Telecom Italia.
Il progetto ha dato luogo ad un add-on per JADE chiamato LEAP ( Lightweight Extensible Agent
Platform ).
Lo scopo principale di LEAP è di fornire un middleware sufficientemente leggero per eseguire
applicazioni su dispositivi con potenza e risorse molto limitate come i telefoni cellulari; è un
sistema estensibile e scalabile, funzionalità molto importante per essere in esecuzione su un gran
numero di dispositivi.
I progettisti di LEAP hanno sviluppato questa piattaforma prendendone una preesistente ( JADE ) e
modificandola per rispettare i requisiti di progetto. Questa scelta è motivata da varie ragioni:
1. JADE è scritto completamente in JAVA
2. JADE è distribuito sotto licenza open source e quindi è possibile avere accesso a tutto il
codice sorgente e modificarlo.
71
3. JADE esegue più tasks in maniera concorrente (behaviours) in un singolo thread JAVA e
ciò è molto importante per i dispositivi con risorse limitate.
4. Infine JADE è stato sviluppato da Telecom Italia un membro del progetto LEAP.
L’implementazione prodotta di LEAP è configurata come un add-on di JADE; questa sostituisce
alcune parti del kernel di JADE fornendo un ambiente di run time modificato.
Per aumentare la scalabilità LEAP è disponibile in tre ambienti JAVA, corrispondenti a tre
differenti versioni :
J2SE: per eseguire JADE-LEAP su PCs e servers, in una rete cablata, che hanno a disposizione la
jdk 1.4 [21].
PJAVA: per eseguire JADE-LEAP sui dispositivi hand-held supportando J2ME CDC e Personal
JAVA.
MIDP: per eseguire JADE-LEAP sui dispositivi hand-held supportando MIDP 1.0 ( e versioni
precedenti ), disponibile sulla maggior parte dei telefoni cellulari JAVA-enabled.
Queste tre versioni forniscono lo stesso insieme di API in modo da offrire uno strato omogeneo al
di sopra dei dispositivi e della rete, come in figura 23.
72
Figura 23: JADE-LEAP run time environment
Solo alcune caratteristiche disponibili per JADE-LEAP in J2SE e pjava non sono disponibili in
JADE-LEAP per MIDP e sono relative alle java classes.
La versione pjava rimuove tutti i tools grafici ma conserva le APIs della versione per J2SE.
Le tre versioni sono direttamente scaribili dalla download area del sito di JADE sia in versione
binaria sia sottoforma di codice sorgente, quest’ultima contiene anche alcuni tools per effetuare il
packaging delle applicazioni JADE-LEAP.
.
Differenze tra JADE e JADE-LEAP
Dal punto di vista degli sviluppatori e degli utenti JADE-LEAP appare identico a JADE in termini
di APIs.
Gli sviluppatori possono implementare i loro agenti JADE in JADE-LEAP e viceversa senza
cambiare una sola linea di codice.
L’unica limitazione è che i containers JADE e quelli JADE-LEAP non possono essere mischiati
all’interno di un’applicazione, questa è la ragione principale per la quale JADE-LEAP è stato
73
sviluppato anche per J2SE in modo da poter avere una singola piattaforma che opera in ambiente
cablato e wireless.
Inoltre come mostrato in figura 22 le diverse piattaforme JADE-LEAP possono comunicare tra loro
utilizzando il protocollo http.
La differenza più grande tra questi due framework è nell’IMTP ( Internal Message Transport
Protocol ), cioè la parte del framework che si occupa dell’interazione container-to-container.
Infatti l’IMTP di JADE è basato su JAVA RMI che non è disponibile per i dispositivi mobili.
Per questo JADE-LEAP utilizza un IMTP differente, un protocollo di tipo proprietario, JICP ( Jade
Inter Container Protocol ), il fatto che i protocolli siano di tipo differente è la ragione per la quale i
container JADE-LEAP non possono registrarsi con container JADE e viceversa.
LEAP IMTP
L’architettura protocollare è composta da un command dispatcher ed uno o più ICPs ( Internal
Communication Peers ). Il primo è condiviso da tutti i container che utilizzano la stessa JVM ed è
responsabile di:
•
Serializzare e deserializzare i comandi scambiati tra containers.
•
Trasmettere messaggi e comandi dal container locale all’ICP opportuno ( specificato
nell’indirizzo di destinazione ) attraverso la rete.
•
Passare i comandi ricevuti dallo strato sottostante (ICP) al container locale.
La figura 24 mostra l’architettura del protocollo.
74
Figura 24: LEAP IMTP
LEAP add-on include tre tipi di implementazioni dell’ICP: quella di default implementata dalla
classe jade.imtp.leap.JICP.JICPPeer, la versione SSL del protocollo JICP ICP implementata dalla
classe jade.imtp.leap.JICP.JICPSPeer, e la versione basata su http implementata dalla classe
jade.imtp.leap.http.HTTPPeer.
Questo indica che una piattaforma JADE-LEAP può usare JICP su SSL o JICP su http come
protocolli di comunicazione container to container.
Notiamo che più di un ICP può essere attivato su un nodo e quindi più container possono
condividere lo stesso command dispatcher e la stessa JVM, ma possono essere raggiungibili sotto
indirizzi diversi.
Come in figura 24 abbiamo un indirizzo http e uno jicp.
75
Split Container
Gli agenti JADE come già detto in precedenza necessitano di un ambiente di run time per essere
eseguiti e per comunicare, questo ambiente in JADE viene fornito dai container
In JADE-LEAP si utilizzano sempre containers ma è possibile scegliere una modalità di esecuzione
differente chiamata split execution mode, pensata ad-hoc per i dispositivi mobili.
Quando lanciamo un container, in questa modalità, ne viene creato uno molto leggero chiamato
front end che mette a disposizione lo stesso insieme di funzionalità di un normale container ma ne
implementa solo una parte direttamente, la restante parte viene delegata ad un processo remoto
chiamato back-end.
Dal punto di vista degli agenti un front end appare come un normale container,mentre dal punto di
vista degli altri container e del main-container il back end appare come un normale container, il
risultato è che assieme formano un normale container.
Front end e back end comunicano attraverso un canale dedicato come mostrato in figura 25.
Figura 25: split execution mode
76
La modalità split execution è particolarmente adeguata per i dispositivi con poche risorse e per i
dispositivi wireless poiché:
1. Un front end in esecuzione su un dispositivo è molto più “leggero” di un container intero.
2. La fase di bootstrap è più rapida poiché le comunicazioni con il main-container, richieste per
unirsi alla piattaforma, sono effettuate dal back end e quindi tramite un rete cablata.
3. L’uso del link wireless è ottimizzato.
4. Entrambi il front end ed il back end realizzano un meccanismo di tipo store and forward che
permette di rendere la potenziale perdita di connessione trasparente all’applicazione.
Se la connessione cade infatti i messaggi diretti agli agenti o che devono essere inviati
vengono memorizzati sia nel back end che nel front end. Quando poi la connessione viene
ristabilita i messaggi memorizzati vengono reinviati ai ricevitori interessati.
5. L’indirizzo IP del front end non viene mai visto dagli altri containers che interagiscono
soltanto con il back end. Quindi questo può anche cambiare senza avere impatto
sull’applicazione.
In figura 26 viene esposta una tabella con le due modalità di esecuzione supportate nei differenti
ambienti di esecuzione.
Si può vedere come la split execution è obbligatoria nel caso dell’MIDP e fortemente suggerita nel
caso di pjava.
Inoltre è importante notare che gli sviluppatori di agenti non devono preoccuparsi se il codice verrà
eseguito su un container in modalità stand-alone o split poiché le APIs sono le stesse.
Figura 26: modalità di esecuzione JADE-LEAP
77
Quando si opera in modalità split però ci sono alcuni problemi ai quali gli sviluppatori vanno in
contro:
1. Il main container non può essere eseguito in modalità split.
2. La mobilità e la clonazione degli agenti non sono disponibili su di un container in modalità
split.
Il Mediatore
In un’applicazione reale quando ci sono diversi agenti che vengono eseguiti su diversi dispositivi
mobili, c’è bisogno di un meccanismo che gestisce automaticamente tutti i back ends di tutti i front
ends attivi.
Questo meccanismo è implementato, nell’architettura JADE-LEAP, da un elemento chiamato
mediator, figura 27.
Figura 27: il mediatore
78
Funzione del mediatore:
Il mediatore dev’essere in esecuzione con un indirizzo fissato e visibile prima che i front end
possano venire eseguiti su un dispositivo.
Quando l’utente attiva JADE-LEAP usando la modalità split, sul proprio dispositivo mobile,
il front end relativo viene inizializzato e si connette al mediatore chiedendo la creazione di un back
end.
Questa richiesta viene effettuata inviando una CREATE-MEDIATOR request, sulla nuova
connessione aperta utilizzando il protocollo JICP.
Dopo ciò il mediatore instanzia il back end e lo connette al front end, tale connessione verrà
utilizzata per tutte le interazioni successive.
A questo punto il back end si registra al main container ed il mediatore invia un messaggio al front
end contenente: il nome assegnato al container, il nome e l’indirizzo ( o gli indirizzi se ci sono )
della piattaforma.
Il diagramma di sequenza presente in figura 28 descrive tutti i passi necessari in fase di
inizializzazione.
Dopo questa procedura di start up tutte le successive interazioni non coinvolgono il mediatore, che
comunque ha una tabella con tutte le associazioni container name – back end.
79
Figura 28: procedura di start up di uno split container
Se c’è una perdita di connessione tra il front end ed il suo back end, il primo periodicamente tenta di
ristabilirla attraverso il mediatore, così come mostrato dal diagramma di sequenza in figura 29.
80
Figura 29: procedura di riconnessione
In questo caso viene inviata una CONNECT_MEDIATOR request.
La richiesta contiene il nome del container in modo che il mediatore possa passare la connessione al
back end corretto.
Si può notare che sia nella procedura di start up che in quella di riconnessione l’unico elemento che
accetta connessioni è il mediatore, che quindi implementa una server socket.
Per questo se il mediatore, il main container e gli altri container sono in esecuzione in una rete in
cui è presente un firewall, basta sbloccare il porto del mediatore.
Ci sono due tipi di implementazioni del mediatore:
•
Quella ICPs di LEAP IMTP. Per questa basta attivare un normale JADE-LEAP container su
un nodo; se c’è bisogno di un porto differente da quello di default è disponibile l’opzione
local-port.
•
Quella BEManagementService inclusa nel LEAP add-on [8].
81
Capitolo 3 - Implementazione del prototipo
Capitolo 3
Implementazione del prototipo
In questo capitolo viene illustrata l’implementazione di un prototipo.
Si partirà con l’illustrazione delle procedure di handling considerata per poi passare alle classi
dell’implementazione.
E’ stato poi considerato uno scenario mobile e l’esecuzione di uno degli agenti su un PDA di
proprietà del DIS ( Dipartimento di Informatica e Sistemistica ) dell’Università di Napoli Federico
II.
3.1 Procedura di handling “prova motori”
La procedura di handling considerata è quella che riguarda l’accompagnamento di un velivolo in
posizione di prova motori.
Infatti le prove a qualsiasi regime al di sopra del minimo dei motori dovranno essere effettuate dopo
aver decentrato l’aeromobile presso la piazzola prova motori e previa autorizzazione dell’U.C.T. (
Ufficio Controllo del Traffico).
La richiesta di attivazione della procedura viene effettuata dal comandante o dall’operatore della
compagnia aerea, specificando se l’aeromobile può muoversi autonomamente o dovrà essere
trainato.
In entrambi i casi sarà accompagnato da un follow me responsabile del corretto posizionamento
all’interno della piazzola prova motori.
Nel caso in cui il velivolo venga trainato in prova motori la compagnia dovrà fornire un orario
previsto per il rientro.
Le piazzole di prova motori, ad esempio a Malpensa ( MI ) è presente presso la holding bay del
raccordo G, in altri aeroporti come quello di Capodichino (NA) è presente in vicinanza delle
piazzole di sosta.
In ogni caso comunque è prevista una procedura di accompagnamento seguita dalla torre di
controllo e quindi da un operatore.
82
Nel prototipo è stato supposto che ci sia un Duty Manager cioè un operatore aeroportuale atto
all’attivazione di una determinata procedura.
La decisione della procedura da attivare si suppone sia già stata presa da un sottosistema presente
all’interno della torre di controllo.
Oltre al Duty Manager i mezzi coinvolti sono il follow me, i tecnici presenti nella piazzola di prova
motori ed il push back che traina l’aereo sotto richiesta della compagnia aerea.
E’ stata considerata questa procedura poiché descritta in documenti di scalo in modo abbastanza
accurato e perché coinvolge più mezzi di handling.
Altre procedure possono essere considerate simili a questa anche con meno mezzi coinvolti, ad
esempio come nel caso di accompagnamento di un mezzo esterno sul sedime aeroportuale, soltanto
il follow me deve essere informato dell’azione da compiere e della posizione del mezzo.
In figura 30 è illustrato uno schema del prototipo, nel caso di procedura di accompagnamento in
prova motori con traino, è quindi coinvolto anche l’operatore push back..
Il Duty Manager dopo aver ricevuto la richiesta della procedura da compiere invia dei messaggi agli
operatori coinvolti, contenenti il tipo di procedura attivata, un identificativo del velivolo, il tipo di
aereo coinvolto e la sua posizione.
Dopo un breve intervallo di tempo gli operatori coinvolti devono comunicare se sono disponibili ad
effettuare la procedura oppure no.
Figura 30: accompagnamento in prova motori con traino
83
La procedura di accompagnamento in prova motori invece non prevede l’invio di un push back e
quindi sarà rappresentata dal diagramma in figura 31.
Figura 31: accompagnamento in prova motori senza traino
3.2 Prototipo in modalità stand-alone
Per lo sviluppo e l’esecuzione del prototipo in modalità stand alone è stato stato utilizzato un
computer portatile Toshiba modello Satellite, con processore Pentium Intel 1.73 Ghz, RAM da 1
GB, con sistema operativo Windows XP Home Edition 2002 Service Pack 2.
Come tool di sviluppo Java, è stato utilizzato Eclipse [28], utilizzando una JDK 1.6.
La versione di Jade installata è la 3.6.1, attualmente scaricabile dal sito.
Gli operatori aeroportuali considerati in precendenza rappresentano degli agenti, infatti sono state
implementate le classi java: DutyManager, FollowMe, Tecnici e PushBack.
Inoltre grazie al tool di sviluppo java NetBeans, sono state progettate ed implementate le interfacce
degli agenti.
84
Fase di inizializzazione
Ogni container dell’applicazione viene lanciato attraverso un file di batch.
Inserendo opportunamente l’opzione “-conf” di jade, viene permesso di caricare un file di
configurazione, contenente tutte le opzioni necessarie.
Nel file di configurazione da noi utilizzato vengono specificate le seguenti opzioni:
•
Nome della piattaforma
•
Servizi della piattaforma utilizzati
•
Opzione “-nomtp ” posizionata al valore true.
•
Modulo per il login di tipo Simple
L’opzione “nomtp”, settata al valore true, serve per indicare se disponibile un MTP oppure no, e
quindi se verranno accettate connessioni con altre piattaforme oppure no.
I servizi utilizzati per venire in contro ai requisiti di progetto sono: security service, main replication
service, address notification service, notification service, topic management service.
Il primo servizio è stato, descritto nel secondo capitolo, fornisce il supporto alla sicurezza facendo
accedere alla piattaforma soltanto utenti autenticati.
Questo supporto, chiamato JADE-S, è stato scaricato dal sito di jade, ed installato caricando le
librerie sulla macchina utilizzata.
L’autenticazione viene effettuata attraverso una finestra di dialogo che permette di inserire
UserName e Password all’utente.
Questi ultimi vengono confrontati con quelli presenti all’interno di un file di testo, se sono corretti
l’utente viene autenticato e può far partire l’agente ed il relativo container.
Non sono state specificate politiche di sicurezza relative ai container.
Il secondo servizio considerato è quello di replicazione del main-container, anche questo descritto
nel secondo capitolo.
85
E’ stato mandato in esecuzione quindi un altro main-container di backup in modo tale da attivare il
servizio di replication. Questo secondo main-container si aggancia al primo ottenendo un suo
riferimento.
Tramite l’interfaccia grafica fornita dall’agente RMA ( Remote Monitoring Agent ) è possibile
monitorare la presenza dei due main-container e come rapidamente nel caso venga eliminato il
master main ( quello avviato per primo ), il secondo ne prende il posto e tutti gli altri container si
agganciano a questo nuovo master.
In figura 32 è riportata l’interfaccia dell’RMA dove sono presenti due main-container.
Figura 32: interfaccia dell'RMA con due main-container
Il servizio di topic management viene attivato poiché le classi inviano messaggi e ricevono
messaggi soltanto di un determinato topic, questo è un meccanismo di tipo publish/subscribe [29].
Cioè quando dev’essere inviato un messaggio viene creato un nuovo topic, che viene indicato come
destinatario del messaggio, dopodichè si invia il messaggio che viene ricevuto solo dagli utenti che
si sono sottoscritti al topic.
86
Attraverso il servizio AddressNotificationService se un main container termina la sua esecuzione, il
main di backup ottiene gli indirizzi di tutti i nodi presenti nella piattaforma in modo da inviargli una
notifica e farli riagganciare ad esso.
L’ultimo servizio utilizzato è il notification service.
Questo servizio è installato di default ma nel caso utilizziamo il security service potrebbe essere
necessario installarlo manualmente.
Questo servizio permette l’invio di notifiche agli utenti che si sottoscrivono ad un determinato
evento e viene utilizzato dal security service.
Per lanciare l’applicazione bisogna innanzitutto far partire il main-container di Jade.
Tutti gli altri container con i relativi agenti vengono lanciati con le stesse opzioni, tranne per
l’autenticazione che nel caso dei container normali viene eseguita da una finestra di dialogo
presente in figura 32 mentre nel main viene eseguita da linea di comando.
Figura 13: finestra di dialogo JADE-S
87
3.3 Scheduling ed esecuzione di behaviour
Prima di passare alle classi e quindi agli agenti implementati facciamo un passo indietro e
descriviamo come vengono eseguiti i behaviour all’interno di un unico thread java [30].
Diciamo subito che all’interno del codice di ogni agente c’è un metodo setup() che manda in
esecuzione il thread dell’agente ed inizia lo scheduling delle behaviour, aggiunte all’interno del
codice del relativo agente.
Un agente può eseguire diverse behaviour in maniera concorrente, ma è importante notare che lo
scheduling di queste in jade non è di tipo pre-emptive ( come per i thread java ) ma è di tipo
cooperativo.
Questo ci fa capire che quando un behaviour viene schedulata ed il suo metodo action() viene
richiamato, esso viene eseguito fino a che non termina.
Per questo è il programmatore che definisce quando un agente fa lo “switch” dell’esecuzione di una
behaviour ad un’altra.
Sebbene comporti degli sforzi questo approccio ha dei vantaggi:
•
C’è un singolo thread java per agente, cosa molto importante in scenari dove sono presenti
dispositivi con risorse limitate come i PDA.
•
Miglioramento delle performance, poiché lo “switching” dei behavior è più veloce di quello
dei thread java.
•
Elimina tutte le sincronizzazioni tra behaviour che accedono alle stesse risorse, poiché
eseguite in un singolo thread java.
•
Quando viene effettuato lo switch di una behaviour, lo status dell’agente non contiene
nessuna informazione relativa allo stack. Questo implica che è possibile salvare lo stato
dell’agente o trasferire l’agente su di un altro container per un’esecuzione remota.
Il path di esecuzione del thread java di un agente è presente in figura 34.
88
Figura 34: path di esecuzione del thread di un agente
89
3.4 Agent Communication
La comunicazione tra agenti è probabilmente la caratteristica più importante di jade ed è
implementata in accordo alle specifiche FIPA [17].
Il paradigma di comunicazione è basato sul concetto di asynchronous message passing.
Con questo ciascun agente ha una “mailbox” ( la coda dei messaggi ricevuti da un agente ) dove il
jade run-time deposita i messaggi inviati dagli altri agenti.
Quando un messaggio viene depositato in questa “mailbox” l’agente viene notificato, ma comunque
quando, o se, il messaggio dev’essere prelevato, dalla coda, e processato è una scelta progettuale del
programmatore.
Questo tipo di procedimento è illustrato in figura 35.
Figura 35: jade “asynchronous message passing”
Il formato del messaggio è in accordo con le specifiche FIPA [17], e contiene i seguenti campi:
•
Mittente del messaggio
•
Lista dei destinatari
•
Il communicative act ( cosa intende ottenere il mittente dal messaggio )
•
Il “content language”, cioè la sintassi usata nel messaggio per esprimere i contenuti.
90
•
L’ontologia
•
Alcuni campi addizionali
Ogni messaggio in jade è implementato come un oggetto che eredita dalla classe
jade.lang.acl.ACLMessage che dispone dei metodi get () e set() per manipolare tutti i parametri
esposti in precedenza.
Di seguito verranno descritti gli agenti utilizzati all’interno del prototipo e quindi per la procedura
di accompagnamento in prova motori.
In generale diciamo che un agente è una classe java, sviluppata in Eclipse , che eredita dalla classe
jade.core.Agent.
3.5 Classi utilizzate
Classe DutyManager
L’agente DutyManager ( codice sorgente DutyManager.java ) implementa parte delle funzioni
dell’operatore aeroportuale duty manager.
La classe java relativa eredita dalla classe jade.core.Agent.
La prima operazione svolta da questo agente è l’iscrizione al DF, specificando il nome dell’agente,
il nome ed il tipo di servizio effettuato.
All’interno del metodo setup() è presente una sola behaviour per essere schedulata, “Risposte”, che
eredita dalla classe jade.core.behaviours.CyclicBehaviour.
Questo behaviour, come suggerisce il nome “CyclicBehaviour”, on termina mai la sua esecuzione
ma la ripete, effettuando sempre la stessa o le stesse operazioni.
Essa permette all’agente di ricevere i messaggi in modalità asincrona.
Infatti attraverso il metodo block(), dei CyclicBehaviour, il behaviour viene segnato come bloccato
ed il thread dell’agente va in sleep ( si ricorda figura 34 ), evitando consumi inutili di CPU.
91
Qualora viene ricevuto un nuovo messaggio viene inserito nella coda dei messaggi il behaviour
“Risposte” viene schedulato di nuovo e quindi c’è possibilità di processare il messaggio ricevuto.
In questo modo vengono ricevuti i messaggi in modo asincrono, evitando sprechi di risorse.
All’interno del setup() sono presenti anche due metodi:
•
ProvaMotori();
•
ProvaMotoriS();
La differenza tra i due metodi è che uno prevede l’invio dei messaggi anche al o ai push back,
richiedendo il traino dell’aeromobile, l’altro no attivando una procedura di accompagnamento in
prova motori senza traino.
Entrambi permettono l’attivazione della procedura di handling, inviando informazioni agli
opportuni agenti, attraverso creazione di un topic e l’invio dei messaggi a con questo topic.
Inoltre questi metodi hanno all’interno un behaviour che eredita dalla classe
jade.core.behaviours.OneShotBehaviour.
Questo viene eseguita una sola volta e termina la sua esecuzione.
L’interfaccia di questo agente è stata sviluppata grazie al tool NetBeans.
Da questa è possibile lanciare la procedura di prova motori sia con traino sia senza traino, inoltre è
stata prevista la presenza di altre funzionalità da aggiungere in futuro, a valle di una conoscenza più
dettagliata della funzionalità di questo operatore.
La figura 36 mostra tale interfaccia.
Premendo sul menu procedure sarà possibile lanciare la procedura di handling desiderata.
Inoltre è presente un menù che permette di monitorare lo stato dei mezzi presenti sul sedime
aeroportuale.
Premendo su una delle procedure si aprirà un’altra finestra nella quale è possibile visualizzare
l’azione effettuata e le risposte dei mezzi coinvolti.
Questa finestra è mostrata in figura 37.
92
Figura 36: interfaccia duty manager
Figura 37: finestra relativa alla procedura attivata
93
Classe FollowMe
L’agente FollowMe ( codice sorgente FollowMe.java ) implementa parte delle funzionalità
dell’operatore aeroportuale follow me.
La classe java relativa eredita dalla classe MyAgent ( codice sorgente MyAgent.java ) che è un
agente che implementa funzionalità comuni a tutti gli altri ( FollowMe, PushBach,Tecnici ).
Questo agente infatti ha tre metodi:
setup()
takedown()
InvioRisposta()
Il primo metodo effettua una registrazione al servizio DF con nome e tipo del servizio, il secondo
effettua la de-registrazione dell’agente e la sua eliminazione.
Il terzo metodo, InvioRisposta(), ha al suo interno un behaviour di tipo “OneShotBehaviour “,
eredita dalla classe jade.core.behaviours.OneShotBehaviour, questa crea un topic “stato procedura”
al quale si registra ed invia messaggi, che saranno destinati poi al duty manager.
Come detto in precedenza l’agente FollowMe eredita da MyAgent, e quindi può utilizzare anche
tutti i suoi metodi, inoltre ha un behaviour proprio di tipo ciclico.
Quest’ultimo permette di ricevere i messaggi di un topic, “FollowMe”, viene usato il metodo
block(), in modo che il thread dell’agente va in sleep quando non ci sono messaggi da ricevere.
L’interfaccia di questo agente è stata sviluppata sempre con NetBeans, ed è la stessa di quella degli
agenti PushBack e Tecnici.
La mostriamo in figura 38.
94
Figura 38: interfaccia di un handling agent
I due bottoni presenti permettono di accettare o no una procedura inviata dal duty manager che
viene stampata nella parte testo dell’interfaccia.
Alla pressione di un bottone automaticamente viene inviato il messaggio relativo, di accettazione o
di non disponibilità.
Classe PushBack
L’agente PushBack ( codice sorgente PushBack.java ) implementa parte delle funzionalità
dell’operatore aeroportuale push back.
Questo sostanzialmente è simile all’agente FollowMe, poiché anch’esso eredita dall’agente
MyAgent ed implementa una behaviour per la ricezione dei messaggi, soltanto che si iscrive ad un
topic differente: “PushBack”.
In questo modo riceve solo i messaggi che lo riguardano, infatti anche i messaggi stampati a video
nell’interfaccia sono diversi.
95
Classe Tecnici
L’agente Tecnici ( codice sorgente sorgente Tecnici.java ) implementa parte delle funzionalità
dell’operatore aeroportuale tecnici, che sarebbero i tecnici presenti in posizione prova motori.
Questo analogamente al precedente è simile all’agente FollowMe, infatti anch’esso deriva da
Myagent e permette la ricezione di messaggi stampandoli a video tramite un’interfaccia.
Il topic al quale si iscrive per la ricezione dei messaggi è: “Tecnici”.
Infine sono stati riportati i diagrammi di sequenza e di collaborazione.
Il diagramma 3.1 è un diagramma di sequenza relativo alla comunicazione basata sui topic, che
comprende due attori il primo è il duty manager che si suppone abbia già fatto l’iscrizione al
servizio DF, il secondo è un operatore già registrato anch’esso.
Si suppone inoltre che l’operatore possa svolgere le procedure che gli vengono proposte.
Il diagramma 3.2 mostra la dipendenza tra la classe MyAgent e le altre classi del prototipo.
Nelle classi che ereditano viene ridefinito il metodo setup() degli agenti.
96
Diagramma 3.1: sequence diagram comunicazione topic-based
97
Diagramma 3.2: class diagram prototipo stand-alone
3.6 Prototipo in ambiente wireless
Il prototipo in precedenza illustrato è stato successivamente eseguito in ambiente wireless grazie al
supporto fornito dall’add-on Jade-Leap e all’utilizzo di un palmare del DIS ( Dipartimento di
Informatica e Sistemistica ) dell’Università di Napoli Federico II.
Il palmare utilizzato è un HP IPAQ PocketPc, figura 38, con sistema operativo windows mobile
2003, processore TI OMAP 1510, memoria 55.03 MB, su cui è stata installata la JVM: WebSphere
Everyplace Micro Environment 5.7.2 - Personal Profile 1.0 for Windows Mobile 2003 2nd Ed.
Dopo aver installato e configurato la JVM, sono stati seguiti i passi presenti nella
LEAPUserGuide[8] e grazie al software Microsoft Active Sync [31] è stato copiato il file di jade
98
per l’installazione su dispositivo mobile, scaricabile direttamente dal sito jade, sotto il nome di
JadeLeapPjava.zip.
Inoltre è stato utilizzato anche un computer portatile Toshiba modello Satellite, con processore
Pentium Intel 1.73 Ghz, RAM da 1 GB, con sistema operativo Windows XP Home Edition 2002
Service Pack 2, sul quale è stato installato Jade-Leap per ambiente J2SE , sempre disponibile sul
sito jade.
Questo pc era in rete “mobilab.unina” cablata, mentre sul palmare è stata configurata una rete
wireless “mobilab” presente al DIS, collegata alla rete mobilab.unina.
In questo modo il palmare ed il portatile hanno potuto scambiarsi informazioni attraverso il
framework jade.
Figura 32: PDA Hp IPAQ
99
Anche in questo caso ogni container dell’applicazione, sul laptop, viene lanciato attraverso un file
di batch che con l’opzione “-conf” di jade permette di caricare un file di configurazione, contenente
tutte le opzioni necessarie.
Nel file di configurazione da noi utilizzato per il main container non viene specificata nessuna
opzione mentre nei file di configurazione relativi agli agenti vengono impostate le seguenti opzioni:
•
Servizi
•
Opzione container settata al valore true
I servizi attivato sui container del laptop sono: notification service, address notification service,
topic management service. Questi servizi sono già stati spiegati in precedenza.
L’opzione container al valore true permette di indicare che si vuole lanciare un container di tipo non
main.
Per quanto riguarda la configurazione del palmare è stato creato un link, su di esso, che permetteva
di lanciare Jade-Leap con le seguenti opzioni:
•
Comando di esecuzione di tipo jade.MicroBoot
•
Opzione container
•
Opzione host
Il comando di esecuzione jade.MicroBoot permette di lanciare un container in modalità split, infatti
quando viene lanciata l’applicazione verrà creato un back end sul laptop ed un front end sul
palmare.
L’opzione container permette di lanciare un container di tipo non main.
L’opzione host permette di inserire l’indirizzo IP dell’host al quale connettersi, ovviamente questo
IP dev’essere accessibile dalla rete, ciò nel nostro caso è possibile poiché i dispositivi considerati
sono sulle stessa rete.
100
3.7 Classi utilizzate
Le classi utilizzate per il prototipo in ambiente wireless, mandate in esecuzione sul laptop, sono le
stesse utilizzate in precedenza tranne la classe PushBack che viene eseguita sul PDA.
Questa classe è abbastanza differente dalla precedente poiché come accennato in precedenza su di
un PDA non c’è lo stesso supporto java presente per un laptop.
Classe PushBack
L’agente PushBack ( codice sorgente PushBack.java ) è una classe java che eredita dalla classe
MyAgent1.
Quest’ultima eredita dalla classe jade.core.Agent e dispone di tre metodi:
setup()
takedown()
InvioRisposta()
Il primo metodo iscrive l’agente al servizio DF, fornendo il tipo ed il nome del servizio.
Il metodo takedown() serve per deregistrare l’agente dal DF e per eliminarlo invocando il metodo
doDelete() della classe jade.core.Agent.
L’ultimo metodo permette di inviare messaggi al duty manager, che prima viene cercato attraverso
il DF e poi gli vengono inviati i messaggi.
Inoltre l’interfaccia è stata cambiata rispetto a quella precedente data l’assenza della classe
javax.swing di java.
La nuova interfaccia eredita dalla classe java.awt.Frame, che è disponibile anche su palmare e
permette all’agente di dare una risposta di sottomissione ad una procedura oppure di non
disponibilità.
101
3.8 Procedura di handling de-icing / de-snowing
Un’altra procedura di handling che è stata considerata è quella di de-icing, aggiunta in secondo
momento all’interno del prototipo.
Questa procedura consiste nel processo di sghiacciamento degli aeromobili, ed è svolta da due
operatori: il duty manager, che invia il comando di esecuzione della procedura ed il deicer, che
sarebbe il mezzo di rampa che esegue effettivamente l’operazione.
Quest’ultimo per effettuare tale operazione deve rifornirsi del liquido sghiacciante e poi procedere.
Nell’interfaccia del duty manager sarà possibile lanciare la procedura ce ne saranno di due tipi, one
step e two step, corrispondenti a due tipologie di deicing differenti.
La fase di inizalizzazione sostanzialmente è analoga a quella precedente, ma non vengono lanciato
il servizio di topic management non disponibile su PDA.
Classi utilizzate
Le classi utilizzate in questa procedura sono: DutyManager e DeIcer.
Diversamente rispetto ai casi precendenti l’agente DutyManager per inviare messaggi al deicer fa
una ricerca nel DF dell’operatore ottiene il suo AID ed invia i messaggi.
102
Duty Manager
Sostanzialmente questa classe è analoga a quella illustrata in precedenza, anche in termini di
intefaccia, dispone però di due metodi in più, che sono:
Deicing1();
Deicing2();
Questi due metodi sono corrispondenti rispettivamente alle procedure di de-icing one step e two
step.
Essi ricercano l’AID dell’agente DeIcer nel DF e inviano messaggi relativi alla tipologia
dell’aeromobile e all’operazione da compiere.
Deicer
Questa classe ( codice sorgente DeIcer.java ) dispone di un metodo e di un behaviour: il metodo
setup() che iscrive l’agente al servizio DF, e la CyclicBehaviour per la ricezione dei messaggi, che
preleva un messaggio dalla coda e poi ritorna in stato blocked..
L’interfaccia estende dalla classe java.awt.Frame ed è analoga al caso del push back, permettendo
all’agente di dare una risposta di sottomissione alla procedura, o di non disponibilità.
Il diagramma 3.3 è un diagramma di sequenza relativo alla comunicazione in ambiente wireless non
basata sul concetto di topic.
Questo diagramma comprende due agenti il duty manager e un operatore non ancora registrato,
anche in questo caso viene supposto che l’operatore possa svolgere le procedure che gli vengono
proposte.
Nel diagramma 3.4 viene mostrata la dipendenza tra le classi del prototipo in ambiente wireless,
nella classe MyAgent1 ci sono due metodi per inviare messaggi al duty manager invocati
rispettivamente per inviare un messaggio di disponibilità o di non disponibilità dell’operatore.
103
Diagramma 3.3: sequence diagram comunicazione non topic-based
104
Diagramma 3.4: class diagram prototipo in ambiente wireless
105
Conclusioni e sviluppi futuri
Questo lavoro di tesi ha mostrato alcune delle caratteristiche di un sistema multiagente, esse
rispettano i requisiti di progetto, si adattano pienamente allo scenario considerato, e permettono di
sviluppare un sistema autonomo.
La documentazione presente per quanto riguarda l’aerodromo ed i mezzi di rampa è risultata
abbastanza completa, mentre per quanto riguarda le procedure di handling è risultata un pò
mancante.
Il servizio di autenticazione permette di impostare politiche di sicurezza molto spinte, il servizio di
replicazione del main-container pemette la sostituzione del main-container master con la sua
replica, in caso di “kill”, in modo molto rapido.
Il servizio di topic management ha permesso lo sviluppo di un applicazione, dotata di molti agenti,
senza alcun conflitto nelle informazioni trasmesse.
L’add-on LEAP fornisce un supporto in ambiente mobile molto valido, infatti la riconnessione al
back end è molto rapida senza perdita di alcun pacchetto grazie ad un meccanismo di tipo store &
forward.
La simulazione in ambiente wireless ha portato a buoni risultati, jade è stato correttamente installato
sul PDA e sono state lanciate diverse procedure di handling.
Il risultato è stato soddisfacente il laptop ed il PDA comunicavano correttamente, la connessione era
molto stabile e in caso di perdita di connessione veniva subito inviata di nuovo la richiesta dal front
end al back end.
In ambiente mobile non è presente la classe javax.swing, implicando l’utilizzo di interfacce
utilizzando la classe java.awt.
Inoltre per i dispositivi PDA non è presente il servizio di topic management e quindi si è dovuto
implementare un meccanismo differente per ricevere ed inviare messaggi.
L’implementazione del prototipo ha permesso di mettere in luce tutte le caratteristiche menzionate
in precedenza, ed ha evidenziato la natura distribuita di questa architettura.
106
In futuro può esser desiderabile fare dei test e delle simulazioni su di numero maggiore di nodi
valutando così le prestazioni di JADE.
Si potrebbero anche migliorare le GUI, soprattutto per l’ambiente mobile.
Sarebbe anche necessario ottenere maggiore documentazione per quel che riguarda le procedure di
handling.
Il prototipo implementato è comunque possibile ampliarlo con ulteriori funzioni e procedure.
107
Bibliografia
[1] Sito internet ENAC ( ente nazionale aviazione civile ) : http://www.enac-italia.it
[2] Sito internet SEA: http://www.sea-aeroportimilano.it
[3] Sito internet ENAV ( ente nazionale assistenza al volo ) : http://www.enav.it
[4] IATA ( International Air Transport Association ) : http://www.iata.org
[5] ICAO ( International Civil Aviation Organization ) : http://www.icao.int
[6] NOTAM ( NOtice To AirMen ) : http://it.wikipedia.org/wiki/NOTAM
[7] Gestione Aeroportuale Prof. Luigi LaFranca.
[8] Jade website: http://jade.tilab.com/
[9] Wooldridge, M., An introduction to multiagent systems, John Wiley Ed.
[10] How to Do Things with Words, Austin 1962
[11] Mayfield, J., Labrou, Y. and Finin, T. Evaluating KQML as an Agent Communication
Language.
[12] Durfee, E. Distributed Problem Solving and Planning.
[13] Smith, R. and Davis, R. The Contract Net protocol: High Level Communication and Control
in a Distributed Problem Solver, 1980
[14] Georgeff, M., Communication and Interaction in Multi-Agent Planning,1983.
[15] Bussmann, S. and Muller, J. A Negotiation Framework for Co-operating Agents, 1992.
108
[16] Durfee, E. and Victor, L. Using Partial Global Plans to Coordinate Distributed Problem
Solvers, 1987.
[17] FIPA website: www.fipa.org
[18] Searle, J. Speech Acts, Cambridge, MA, Cambridge University Press, 1969
[19] http://www.gnu.org/licenses/
[20] Developing Multi-Agent Systems with JADE, Fabio Bellifemine, Giovanni Caire, Dominic
Greenwood
[21] http://java.sun.com/javase/technologies
[22] http://hsqldb.org/
[23] http://java.sun.com/products/midp
[24] http://ant.apache.org/
[25] http://java.sun.com/products/personaljava/
[26] http://java.sun.com/docs/books/tutorial/
[27] http://java.sun.com/developer/technicalArticles/Programming/serialization/
[28] Eclipse website: www.eclipse.org
[29] “Distributed Event-based Systems“, 2007 by Gero Muehl, Ludger Fiege, and Peter R. Pietzuch,
Springer-Verlag, Germany
[30] Thinking in Java, B.Eckel Prentice Hall
109
[31] http://www.microsoft.com/downloads/
Testi
-Developing Multi-Agent Systems with JADE, Fabio Bellifemine, Giovanni Caire, Dominic
Greenwood
-Wooldridge, M., An introduction to multiagent systems, John Wiley Ed.
-Thinking in Java, B.Eckel Prentice Hall
Altre pubblicazioni
- Fault Tolerance in Autonomous Systems:How and How Much?, Benjamin Lussier, Alexandre
Lampe, Raja Chatila, Jérémie Guiochet, Félix Ingrand, Marc-Olivier Killijian, David Powell
- Una Piattaforma per lo Sviluppo di Applicazioni Multi-Agente, A. Grosso, A. Gozzi, A. Boccalatte
- JADE – A FIPA-compliant agent framework, Fabio Bellifemine, Agostino Poggi, Giovanni
Rimassa
110