Facoltà di Ingegneria Corso di Laurea Magistrale in Ingegneria ...

UNIVERSITÀ POLITECNICA DELLE MARCHE
Facoltà di Ingegneria
Corso di Laurea Magistrale in Ingegneria Informatica
Progetto di un sistema di videosorveglianza basato su
tecnologie multi-agente
Relatore:
Prof. Aldo Franco Dragoni
Correlatori:
Dott. Gianluca Dolcini
Dott. Luca Palazzo
Anno Accademico 2011/2012
Tesi di:
Andrea Baldini

“Un viaggio di mille miglia inizia con un solo passo”
Lao Tse

Indice
1. Introduzione .................................................................................................................... 1
1.1. Stato dell’arte ........................................................................................................... 2
1.2. Obiettivi della tesi ..................................................................................................... 3
1.3. Struttura ................................................................................................................... 4
2. Ambiente di sviluppo ....................................................................................................... 5
2.1. Gli agenti software .................................................................................................... 6
2.2. Sistemi Multi-Agente ................................................................................................ 8
2.3. Architetture sistemi Multi-Agente ............................................................................. 9
2.4. Lo standard FIPA ..................................................................................................... 12
2.4.1. FIPA Request Interaction Protocol Specification ............................................... 15
2.4.2. FIPA Contract Net Interaction Protocol Specification ....................................... 17
2.4.3. FIPA Agent Management Specification ............................................................ 19
2.5. FIPA-ACL ................................................................................................................. 23
2.5.1. FIPA Comunicative Act Library Specification .................................................... 25
2.5.2. FIPA SL Content Languages Specification ......................................................... 27
2.5.3. FIPA Agent Message Transport Service Specification ....................................... 28
2.6. JADE: Java agent development environment .......................................................... 32
2.6.2. Architettura JADE............................................................................................. 34
2.6.3. Message Transport Service .............................................................................. 35
2.6.4. IMTP ( Internal Message Transport Protocol ) .................................................. 36
2.6.5. Special agents .................................................................................................. 37
2.6.6. JADE Packages ................................................................................................. 40
2.6.7. Classe Agent .................................................................................................... 41
2.6.8. Comportamenti degli agenti ............................................................................ 42
2.6.9. Protocolli di interazione ................................................................................... 45
2.6.10. Supporto alle ontologie.................................................................................... 47
v

2.7. Android ................................................................................................................... 51
2.7.1. Basi della programmazione Android ................................................................ 53
2.8. JADE-LEAP ............................................................................................................... 60
2.8.1. Jade-Leap runtime environment ...................................................................... 60
2.8.2. Split execution ................................................................................................. 62
2.9. JADE-based Android application ............................................................................. 64
2.10. Integrazione di JADE e Android in Eclipse ............................................................ 67
3. Progettazione del sistema .............................................................................................. 71
3.1. Software di partenza ............................................................................................... 71
3.2. Analisi dei requisiti .................................................................................................. 77
3.3. Architettura del sistema .......................................................................................... 78
3.3.1. Agente Android................................................................................................ 81
3.3.2. Agente Manager .............................................................................................. 86
3.4. L’ontologia per il servizio di videosorveglianza ........................................................ 90
4. Implementazione ........................................................................................................... 92
4.1. Implementazione ontologia .................................................................................... 92
4.2. Implementazione applicazione centrale .................................................................. 97
4.2.1. Struttura applicazione videosorveglianza ......................................................... 97
4.2.2. Avvio applicazione “videosorveglianza” ........................................................... 99
4.2.3. Implementazione agente manager ................................................................ 100
4.3. Implementazione applicazione Android ................................................................ 111
4.3.1. File AndroidManifest.xml e struttura applicazione ......................................... 111
4.3.2. Creazione agente Android .............................................................................. 114
4.3.3. Implementazione agente Android .................................................................. 116
4.3.4. Interazione agente e logica di elaborazione del video .................................... 124
5. Test e risultati .............................................................................................................. 131
5.1. Test sulle prestazioni di analisi del video ............................................................... 131
5.2. Test recovery del sistema di videosorveglianza ..................................................... 133
6. Conclusioni e sviluppi futuri ......................................................................................... 136
AppendiceA Software..................................................................................................... 139
vi

Ringraziamenti .................................................................................................................... 140
Bibliografia .......................................................................................................................... 142
vii

Elenco delle figure
Figura 2-1 Modello architettura di tipo Reattiva .................................................................... 10
Figura 2-2 Schema architettura PRS ...................................................................................... 11
Figura 2-3 Architettura Layered di tipo orizzontale e verticale .............................................. 12
Figura 2-4 Raggruppamenti delle specifiche FIPA .................................................................. 13
Figura 2-5 FIPA Request Protocol .......................................................................................... 16
Figura 2-6 FIPA ContractNet Interaction Protocol .................................................................. 19
Figura 2-7 Agent Platform ..................................................................................................... 20
Figura 2-8 Ciclo di vita di un agente ....................................................................................... 21
Figura 2-9 Architettura JADE ................................................................................................. 35
Figura 2-10 GUI dell'Agente RMA .......................................................................................... 37
Figura 2-11 Diagramma delle classi di JADE tools .................................................................. 39
Figura 2-12 Contenuto comunicazione fra Agenti .................................................................. 48
Figura 2-13 Modello di riferimento per i Content .................................................................. 50
Figura 2-14 Architettura Android .......................................................................................... 52
Figura 2-15 Struttura applicazione Android ........................................................................... 54
Figura 2-16 Lettura file Manifest da Eclipse ........................................................................... 54
Figura 2-17 Ciclo di vita di una attività................................................................................... 57
Figura 2-18 Componenti schermo Android ............................................................................ 59
Figura 2-19 Architettura JADE Leap ....................................................................................... 62
Figura 2-20 Stand alone e Split execution mode .................................................................... 63
Figura 2-21 Android SDK manager ......................................................................................... 69
Figura 3-1 Architettura del sistema di videosorveglianza ....................................................... 79
Figura 3-2 Architettura sistema di videosorveglianza con piattaforma recovery .................... 80
Figura 3-3 Interfaccia agente Android ................................................................................... 82
Figura 3-4 Operazioni agente Andorid ................................................................................... 84
Figura 3-5 Componenti software dell'agente Android ........................................................... 85
Figura 3-6 Operazioni agente manager ................................................................................. 88
Figura 3-7 Componenti software agente manager ................................................................ 89
viii

Figura 3-8 Ontologia del sistema di videosorveglianza .......................................................... 91
Figura 4-1 Struttura applicazione Videosorveglianza ............................................................. 98
Figura 4-2 Avvio applicazione videosorveglianza visto dalla GUI dell'RMA ............................. 99
Figura 4-3 Struttura applicazione Android ........................................................................... 113
Figura 5-1 Diagramma dei FPS ottenuto dall'estratto di 12 secondi dei test ........................ 133
ix

Elenco delle tabelle
Tabella 2-1 Parametri del messaggio FIPA-ACL ...................................................................... 25
Tabella 2-2 Atti comunicativi e significato ............................................................................. 26
Tabella 2-3 Parametri messaggio .......................................................................................... 30
Tabella 2-4 Modalità esecuzione nei vari ambienti ................................................................ 62
Tabella 5-1Risultati prestazioni analisi video ....................................................................... 132
x

Elenco dei listati
Listato 3-1 Metodo run() di CvBaseView ............................................................................... 73
Listato 3-2 Metodo processFrame() di FdView ...................................................................... 75
Listato 4-1 Concept Acknowledge ......................................................................................... 93
Listato 4-2 AgentAction ConfermaFunzionamento ................................................................ 93
Listato 4-3 Concept Immagine ............................................................................................... 94
Listato 4-4 Concept Identita .................................................................................................. 94
Listato 4-5 AgentAction Identifica ......................................................................................... 95
Listato 4-6 Ontologia Videosorveglianza ............................................................................... 97
Listato 4-7 Avvio applicazione videosorveglianza .................................................................. 99
Listato 4-8 Metodo setup() dell'agente manager ................................................................. 101
Listato 4-9 Metodo register() dell'agente manager ............................................................. 102
Listato 4-10 Metodo deregister() dell'agente manager ....................................................... 102
Listato 4-11 Implementazione interfaccia dell'agente manager........................................... 103
Listato 4-12 Behaviour DFRegistraManager ........................................................................ 104
Listato 4-13 behaviour ControllaAckcyclic ........................................................................... 106
Listato 4-14 Behaviour ControllaAck ................................................................................... 107
Listato 4-15 Behaviour RespondImage ................................................................................ 110
Listato 4-16 File AndoridManifest.xml ................................................................................. 112
Listato 4-17 Creazione agente Android................................................................................ 116
Listato 4-18 Metodo oncreate() di FdActivity ...................................................................... 116
Listato 4-19 Metodo setup() dell'agente Android ................................................................ 117
Listato 4-20 Interfaccia agente Android............................................................................... 119
Listato 4-21 Behaviour DFRegistraCamera .......................................................................... 120
Listato 4-22 Behaviour RispondiAck .................................................................................... 121
Listato 4-23 Behaviour SendImage ...................................................................................... 123
Listato 4-24 Metodo processFrame() con interazione agente Android ................................ 128
Listato 4-25 Thread di controllo risposta di identificazione volti .......................................... 130
Listato 5-1 Log dell'execution time ...................................................................................... 131
xi

Sommario
In questo lavoro di tesi viene presentato un sistema di videosorveglianza basato su
tecnologia multi-agente. Come punto di partenza il Laboratorio di Intelligenza Artificiale e
Sistemi in Tempo Reale (AIRT Lab) mi ha fornito di un sistema in tempo reale di inseguimento
di volti, mediante un robot dotato di sistema operativo real time Erika Enterprise e
smartphone Android. L'architettura realizzata prevede la presenza di due distinti applicativi
ad agente. Un applicativo "centrale" in grado di gestire le telecamere che partecipano alla
videosorveglianza ed un applicativo su ogni dispositivo partecipante. L'architettura ad agenti
è stata creata utilizzando il framework JADE, in particolare l'applicativo "centrale" prevede la
creazione di una Jade Platform contenente un agente "manager" in grado di soddisfare le
richieste di identificazione di volti e mantenere una lista aggiornata dei dispositivi funzionanti
che partecipano alla videosorveglianza tramite un periodico acknowledgement. A tale
piattaforma si collegheranno gli agenti residenti nell'applicativo delle telecamere, il quale
individua i volti delle persone, ne seleziona uno da seguire e tramite l'agente richiede
l'identità del viso selezionato all'agente manager, il quale fornirà l'identità del volto nel caso
sia conosciuto o una risposta di identità sconosciuta. Le telecamere che partecipano al
sistema di videosorveglianza sviluppato sono smartphone Android, dato che con l’avanzare
delle tecnologie hardware è possibile prevedere che il sistema operativo Android sia presente
anche in dispositivi come telecamere. A prova di questo vi è la recente uscita della Samsung
Galaxy Camera, una fotocamera compatta dotata di Android. La comunicazione realizzata fra
l'applicativo centrale e l'applicativo su smartphone Android avviene sempre attraverso lo
scambio di messaggi ACL che rispettano i protocolli FIPA in modo da tenere aperta
l'opportunità di far partecipare alla videosorveglianza qualsiasi dispositivo dotato di
telecamera e in grado di rispettare la comunicazione usata. Il sistema così creato intende
soddisfare i requisiti richiesti da un servizio di videosorveglianza, aggiungendo al servizio i
vantaggi dell'uso degli agenti software, quale la tolleranza ai guasti richiesta dalle moderne
applicazioni operanti in rete. Infatti nel caso che la piattaforma ad agenti smetta di
xii

funzionare, l'applicativo presente nel dispositivo Android proverà a non cessare la sua attività
cercando la presenza di un'altra piattaforma in cui poter ricreare il suo agente e ripristinare il
servizio.
xiii

1. Introduzione
Il notevole sviluppo di Internet, la miniaturizzazione dei dispositivi hardware e la
proliferazione delle connessioni mobili hanno cambiato notevolmente le abitudini di vita
delle persone. L'aumento del numero di servizi offerti dalla rete hanno avuto come
conseguenza lo sviluppo dei sistemi distribuiti e la necessità di soddisfare livelli di tolleranza
ai guasti, sicurezza e scalabilità sempre maggiori. Un sistema distribuito, infatti, permette di
superare sia la programmazione tradizionale, in cui un programma gira su una macchina, sia
la programmazione con approccio client-server, in cui un'applicazione è suddivisa in due o
più moduli, che possono risiedere su macchine diverse e dialogano tra loro conservando però
una gerarchia ben definita. Infatti, avendo a disposizione un ambiente di rete, si possono
concepire applicazioni distribuite, formate da una comunità di componenti detti agenti che
non solo comunicano fra loro, ma possono anche essere in grado di spostarsi da un computer
a un'altro insieme con i propri dati. Un’altra possibilità offerta da questo paradigma di
programmazione è quella di eseguire agenti portatili anche su dispositivi mobili, dotati in
genere di risorse limitate, sia in termini di potenza di calcolo che di disponibilità di memoria.
Nasce quindi l’idea di sviluppare un sistema di videosorveglianza che faccia uso della
tecnologia multi-agente, dato che la videosorveglianza è un settore dove sicurezza,
modularità e distribuzione possono risultare caratteristiche fondamentali per la qualità del
servizio offerto. Inoltre la possibilità di eseguire agenti su dispositivi mobili permette
l'inserimento di agenti sulle eventuali telecamere che partecipano alla videosorveglianza. La
videosorveglianza è quindi un settore teoricamente idoneo all'uso di un sistema distribuito
che sia programmato ad agenti e questo lavoro di tesi si pone l’obiettivo di verificarlo.
1

1.1. Stato dell’arte
Introduzione
Gli impianti di videosorveglianza consentono il monitoraggio del territorio, delle abitazioni o
del proprio ufficio in maniera efficace e poco dispendiosa. Questi impianti sono tipicamente
realizzati da un insieme di telecamere opportunamente installate nei luoghi da controllare e
collegate ad un registratore di immagini (Digital Video Recorder) che ne consente
l’acquisizione e la conservazione per un certo tempo su hard disk.
Lo stato dell’arte attuale consente di realizzare impianti di videosorveglianza in tecnologia
analogica e su tecnologia IP. Le caratteristiche delle telecamere disponibili sul mercato
consentono poi di avere prestazioni particolari quali il brandeggio, ovvero telecamere tipo
Speed Dome con supporto motorizzato che possono essere teleguidate dall’operatore
tramite joystick con rotazione della visuale di 360°, oppure montare a bordo innovativi
processori dedicati (DSP) per l’elaborazione video quali il motion detection ovvero la
rilevazione di oggetti in movimento, o l’individuazione di oggetti statici particolari su uno
scenario quali borse o pacchi suscettibili di rischio attentati. Inoltre vi sono algoritmi di analisi
delle immagini che permettono di riprodurre i processi di osservazione proprio
dell'intelligenza umana in modo automatizzato e negli ultimi anni molti studi si sono
concentrati sul riconoscimento dei volti. Recentemente sono stati sviluppati sistemi che
prevedono l'utilizzo di telecamere wireless che inviano le immagini ad un PC, responsabile
dell'elaborazione video. Questo fà si che nelle sale di controllo ci siano generalmente poche
persone con il compito di osservare contemporaneamente un elevato numero di monitor che
mostrano le riprese del sistema di videosorveglianza, abbassando i costi del servizio. Una
architettura distribuita utilizzata dagli attuali sistemi di videosorveglianza è client/server web
based con ip-cam e server centralizzato per la gestione dello streaming e dell’archiviazione
video, dove il sistema è personalizzabile in relazione al numero delle videocamere ed alle
funzionalità richieste, è possibile dimensionare il sistema server per ottimizzare costi e
prestazioni. ([1])
2

Introduzione
1.2. Obiettivi della tesi
Questa tesi ha come obiettivo la progettazione di un sistema di videosorveglianza basato su
tecnologia multi-agente. Per realizzare l'obiettivo il Laboratorio di Intelligenza Artificiale e
Sistemi in Tempo Reale mi ha fornito di una applicazione Android per l'inseguimento di volti
sviluppata da Simone Saraceni ([12]) e una applicazione per il riconoscimento dei volti
sviluppata da Gianluca Dolcini ([15]). Il mio lavoro di tesi consiste nell'agentificare le
applicazioni date e creare un sistema di videosorveglianza ad agenti che rispetti i seguenti
punti:
1. Utilizzo del framework JADE per l'implementazione della struttura ad agenti.
2. Definizione di una ontologia per lo scambio dei messaggi in uno scenario di
videosorveglianza, per esempio per richieste e risposte:" identifica questo
soggetto...", "il soggetto identificato è...".
3. Riconoscimento dei dispositivi malfunzionanti collegati al servizio di videosorveglianza
tramite la richiesta di un periodico acknowledge.
4. Inserimento degli indirizzi e dei servizi offerti dai vari dispositivi collegati al sistema di
videosorveglianza nel DF della piattaforma ad agenti.
5. Creazione di un sistema di videosorveglianza resistente ad una distruzione accidentale
della piattaforma ad agenti su cui risiedono gli agenti rappresentanti le telecamere.
Il sistema risulterà composto da due applicativi ad agenti, un applicativo centrale per la
creazione della JADE Platform contenente un agente in grado di gestire gli agenti residenti
nelle telecamere (smartphone Android), un secondo applicativo presente in ogni dispositivo
Android che vuole partecipare alla videosorveglianza.
Tale sistema può apportare vantaggi nel settore della videosorveglianza, in particolare
l’utilizzo degli agenti permetterebbe la creazione di una reale applicazione distribuita, dove
sia immediato aggiungere o eliminare telecamere, e quindi in grado di soddisfare i requisiti di
scalabilità, oltre che alla già citata proprietà di tolleranza ai guasti.
Nel seguito della tesi verrà presentato il sistema sviluppato, mostrandone il funzionamento.
3

1.3. Struttura
Introduzione
Nel capitolo 2 viene fornita una panoramica dell’ambiente di sviluppo, nella quale vengono
presentati gli agenti software, le principali specifiche FIPA, il framework JADE, il sistema
Android, l’add-on di JADE per dispositivi mobili Jade-Leap e una piccola guida all’installazione
di Jade e Android nell’ambiente di sviluppo Eclipse.
Nel capitolo 3 sono descritte le prime fasi del lavoro, ossia l’analisi dei requisiti e la
progettazione del sistema.
La fase di implementazione è descritta nel capitolo 4; dove viene illustrato il lavoro svolto per
la realizzazione dell’applicativo ad agenti centrale e dell’applicativo ad agenti per il
dispositivo Android.
Nel capitolo 5 sono riportati i risultati ottenuti nei vari test effettuati sul sistema di
videosorveglianza realizzato.
Il capitolo 6 conclude la tesi con un riepilogo del lavoro svolto, contenente anche alcune
riflessioni sugli sviluppi futuri.
4

Ambiente di sviluppo
2. Ambiente di sviluppo
In questo lavoro di tesi si è fatto un approfondito studio dello standard FIPA e di quanto
presente in letteratura relativamente alle tecnologie ad Agenti ed agli strumenti di sviluppo.
La Foundation for Intelligent Physical Agents (FIPA) è un’associazione internazionale di
aziende creata nel 1996 con lo scopo di definire standards per agenti e per piattaforme di
supporto per agenti. L’obiettivo principale di FIPA è promuovere specifiche per
l’interoperabilità ed il riuso che facilitino la cooperazione e la gestione di sistemi di agenti
intelligenti sviluppati da diverse compagnie ed organizzazioni. A tale scopo FIPA sta
lavorando per produrre specifiche per la creazione e gestione di agenti, messaggi, linguaggi di
comunicazione fra agenti, protocolli di interazione, architetture di trasporto dei messaggi,
definizione di ontologie.
Per implementare il nostro sistema multiagente si è scelto, come framework, JADE ( “Java
Agent Development Framework” ) ([8]). Questo è stato sviluppato da TILab s.p.a ( Telecom
Italia Lab ) 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. In particolare, tramite
l’add-on Jade-Leap è stato possibile implementare l’agente mobile residente nello
smartphone Android, che viene impiegato come telecamera. In questo capitolo viene
presentato l’ambiente di sviluppo, fornendo una panoramica degli aspetti legati al software.
5

Ambiente di sviluppo
2.1. 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. Altri attributi comunemente associati agli agenti sono i seguenti :
• Mobilità: è la capacità di un agente di spostarsi all'interno dell'ambiente in cui opera, per
poter raggiungere le risorse di cui necessita o le informazioni di cui è alla ricerca. Per gli
agenti fisici il movimento avviene all'interno di un ambiente reale, mentre per gli agenti
software si intende il trasferimento da un nodo all'altro di una rete di computer. La mobilità
rappresenta un ulteriore aspetto di autonomia, in quanto la scelta del percorso da seguire o
del sito su cui fermarsi sono lasciate al giudizio dell'agente; si possono distinguere due livelli
di mobilità:
- Esecuzione Remota: l’Agente (programma + dati) viene spostato su un altro Host ed
eseguito interamente in remoto.
- Migrazione: durante la propria esecuzione un Agente è in grado di spostarsi di propria
iniziativa in un altro nodo. Quindi è capace di sospendere la propria esecuzione,
migrare ( programma + dati + stato di esecuzione ) e riattivarsi dal punto di
sospensione.
• Cooperazione: si ha invece quando più agenti sono impegnati nel conseguimento di un
obiettivo comune: questo implica sia aspetti di comunicazione che di coordinamento,
necessari per organizzare i partecipanti all'operazione seguendo una certa strategia, e per
permettere lo scambio dei risultati parziali raggiunti;
• Apprendimento: è un aspetto molto discusso perché legato al concetto di intelligenza; si
tratta della capacità di fare tesoro delle esperienze passate, per servirsene al momento di
dover prendere una determinata decisione. La conoscenza conservata da un agente può
essere di diverso genere, e spaziare da un singolo bit di stato ad un intero database.
• Adattamento: indica la proprietà dell'agente di modificare il proprio comportamento in
seguito alle mutate condizioni dell'ambiente circostante. L'agente si dice adattativo se è in
6

Ambiente di sviluppo
grado di cambiare autonomamente il proprio comportamento per adeguarsi alle situazioni in
cui si viene a trovare.
• Sincerità: incapacità di comunicare intenzionalmente false informazioni. Si tratta, cioè, di
supporre che l’Agente non sia in grado scegliere tra menzogna e verità.
• Benevolenza: questo significa che un Agente non può avere obiettivi da raggiungere
intrinsecamente in contrasto con quelli di altri Agenti .
• Razionalità: questo concetto si basa sull’assunzione che le azioni compiute da un Agente
siano volte al perseguimento di determinati obiettivi e che, in nessun caso, cerchino di
ostacolarne il raggiungimento.
In un certo senso un agente può esser visto come un oggetto ( OOP ) con un obiettivo, 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.
Un Agente non deve necessariamente possedere tutte le proprietà descritte
precedentemente ma ve ne sono alcune, come l’adattamento e l’apprendimento, che
risultano strettamente correlate tra loro e pertanto può risultare arduo distinguerle. In altri
casi si considerano sistemi composti da più agenti, ognuno caratterizzato da certi attributi, e
si parla di Sistema multi-Agente.
7

Ambiente di sviluppo
2.2. Sistemi Multi-Agente
Se è difficile dare una definizione universalmente riconosciuta di Agente, lo è altrettanto dare
quella di Sistema ad Agenti. Questa, infatti, si basa sui concetti di Agente e di Piattaforma o
Contenitore d’Agenti, per modellare una struttura software complessa costituita da processi
cooperanti per il raggiungimento di un obiettivo comune. La piattaforma ad agenti
rappresenta una macchina virtuale per l’esecuzione degli agenti, una sorta di contenitore
dove gli agenti possono vivere ed operare.
Nei Sistemi Multi-Agente (MAS) gli agenti possono interagire gli uni con gli altri sia
indirettamente (modificando l’ambiente), sia direttamente (attraverso la comunicazione),
allo scopo di soddisfare un certo insieme di compiti. Gli obiettivi di ogni agente possono
essere condivisi o conflittuali, nel primo caso gli agenti cercano di collaborare per
raggiungere il beneficio comune mentre nel secondo caso gli agenti competono per
perseguire i propri interessi. Nei Sistemi Multi-Agente si tende spesso a ridurre l’intelligenza
del singolo agente in favore dell’intelligenza collettiva, puntando l’attenzione verso il
coordinamento, la capacità/volontà di cooperazione, e la negoziazione.
Le caratteristiche principali di un MAS sono:
• Ogni agente ha informazione o capacità incompleta, quindi un punto di vista dell’ambiente
limitato;
• Non c’è un controllo globale del sistema;
• I dati sono decentralizzati;
• L’interazione è asincrona, dinamica e ad alto livello.
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à 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.
8

Ambiente di sviluppo
3. Intelligenza: i compiti che ci aspettiamo di poter delegare ai computer sono sempre più
complessi.
4. Delega: viene lasciato 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 sono quindi considerati un importante paradigma di programmazione perché
possono migliorare gli attuali metodi di concettualizzazione, disegno, implementazione dei
sistemi software e costituire una soluzione al problema di integrazione dei sistemi legacy.
2.3. Architetture sistemi Multi-Agente
Ci sono vari tipi di architetture per sistemi multi-agente, esse possono essere suddivise in
quattro gruppi fondamentali:
• Logic Based
• Reattivi
• BDI
• 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
9

Ambiente di sviluppo
decisioni sulla base di un meccanismo di tipo stimulus-response e si basano sul modello di
Brooks . 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. Questo modello può essere spiegato attraverso la figura 2.1, dove sono
rappresentati degli strati di una macchina a stati finiti, che sono connessi a sensori che
trasmettono informazioni in tempo reale:
Figura 2-1 Modello architettura di tipo Reattiva
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.
10

Ambiente di sviluppo
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. Uno schema rappresentativo
dell’architettura PRS è il seguente (figura 2.2):
Figura 2-2 Schema 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 (vedi
figura 2.3), 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. ([2])
11

Ambiente di sviluppo
Figura 2-3 Architettura Layered di tipo orizzontale e verticale
2.4. Lo standard FIPA
L’organizzazione internazionale FIPA ( Foundation for Intelligent Physical Agents), 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 ) ([3]). 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. La prima
documentazione rilasciata, denominata FIPA97 Specifications, risale al 1997 e delinea le
regole di base per la gestione di una comunità di Agenti, sottolineando gli aspetti relativi alla
loro collaborazione. Le specifiche FIPA possono essere raggruppate a seconda dell’oggetto in
analisi, ovvero del tema trattato all’interno del dominio degli agenti, vedi figura 2.4.
12

• Application
• Abstract Architecture
• Agent Communication
• Agent Management
• Agent Message Transport
Application
Ambiente di sviluppo
Figura 2-4 Raggruppamenti delle specifiche FIPA
Le specifiche FIPA che fanno parte della sezione Application contengono la descrizione di
alcune aree applicative di esempio, in cui gli agenti FIPA possono essere impiegati. Danno
direttive sull’ontologia e sulle descrizioni dei servizi per un particolare dominio. Alcuni
13

Ambiente di sviluppo
esempi di domini trattati sono l’assistenza ai viaggi (FIPA Personal Travel Assistance
Specification) e in specifiche per la trasmissione di contenuti audio/video (FIPA
Audio-Visual Entertainment Broadcasting Specification).
AbstractArchitecture
Fra gli obiettivi primari della FIPA c’è quello di promuovere l’interoperabilità, e, poiché i
sistemi reali fanno uso di tecnologie differenti per raggiungere scopi identici dal punto di
vista funzionale, si è creduta necessaria l’identificazione delle caratteristiche comuni ai
diversi approcci, arrivando ad una astrazione architetturale, applicabile a ciascuno di essi.
Descrivere i sistemi in maniera astratta permette di esplorare le relazioni fra gli elementi
fondamentali, evidenziare gli aspetti chiave ed i meccanismi più critici, fornire le indicazioni
su come i sistemi ad agenti concreti debbano essere costruiti per essere interoperabili. Alcuni
degli elementi fondamentali specificati dall’Architettura astratta FIPA sono:
• Agent messages - costituiscono la forma fondamentale di comunicazione fra agenti;
rappresentano atti linguistici e sono codificati in un linguaggio di comunicazione ad agenti
(ACL), mentre Il contenuto è espresso in un content language, come FIPA-SL o FIPA-KIF, e le
espressioni del contenuto possono essere basate su ontologie.
• Message transport service - definito come il mezzo per mandare e ricevere messaggi fra
agenti e considerato un elemento obbligatorio dei sistemi ad agenti FIPA.
• Agent directory service - definito come un archivio di informazione condivisa in cui gli
agenti possono pubblicare le loro registrazioni e nel quale possono cercare registrazioni di
interesse. Anche questo è considerato un elemento obbligatorio.
• Service directory service - definito come un archivio condiviso nel quale gli agenti possono
trovare servizi. I servizi includono, ad esempio, servizi di trasporto del messaggio, servizi di
directory di agenti, servizi di inoltro e buffering di messaggi. Un service directory service può
anche essere usato per mantenere le descrizioni dei servizi application oriented ed è
considerato un elemento obbligatorio.
14

AgentComunication
Ambiente di sviluppo
Le specifiche FIPA riguardanti la Communicazione degli Agenti possono essere
ulteriormente classificate a seconda che trattino:
• i messaggi ACL (Agent Communication Language),
• i protocolli di interazione per lo scambio di messaggi,
• gli atti comunicativi basati sulla teoria degli atti linguistici,
• la rappresentazione dei contenuti mediante dei “content languages”.
2.4.1. FIPA Request Interaction Protocol
Specification
Il FIPA Request Interaction Protocol (IP) permette ad un agente, l’iniziatore, di richiedere ad
un altro, il partecipante, di eseguire un’azione. Il partecipante elabora la richiesta e decide se
accettarla o meno.
Se le condizioni indicano che un accordo esplicito è richiesto, allora il partecipante comunica
un agree. Quest’accordo può essere dipendente dalle circostanze (per esempio, se l’azione
richiesta è molto rapida e può accadere prima di un certo istante, specificato nel parametro
reply-by). Una volta che si è d’accordo su una richiesta, il partecipante deve comunicare:
• Un failure se fallisce nel suo tentativo di soddisfare la richiesta,
• Un inform-done se completa con successo la richiesta e desidera solo indicare che il
lavoro è svolto,
• Un inform-result se desidera sia indicare che ha finito, sia comunicare il risultato
all’iniziatore.
Qualsiasi interazione che usa questo protocollo è identificata da un parametro conversation-
id globalmente univoco e non nullo, assegnato dall’iniziatore e collocato nella struttura del
messaggio ACL. Gli agenti coinvolti nell’interazione devono etichettare tutti i loro messaggi
15

Ambiente di sviluppo
ACL con questo identificatore di conversazione. Ciò permette ad ogni agente di gestire le
proprie strategie e attività di comunicazione (per esempio, permette ad un agente di
identificare singole conversazioni e di ragionare attraverso gli storici delle conversazioni). In
qualsiasi punto nell’IP, il destinatario di una comunicazione può informare il mittente che
non ha compreso quello che è stato comunicato. Ciò viene fatto restituendo un messaggio
not-understood. La comunicazione di un not-understood all’interno di un protocollo di
interazione può far terminare l’intero IP e la terminazione dell’interazione può implicare che
ogni impegno preso durante l’interazione divenga nullo e non valido.
Figura 2-5 FIPA Request Protocol
16

Ambiente di sviluppo
In ogni punto nell’IP, l’iniziatore può annullare l’interazione inizializzando il Cancel Meta-
Protocol. Il parametro conversation-id dell’interazione di cancellazione è identico al
parametro conversation-id dell’interazione che l’iniziatore intende cancellare. Semantica
della cancellazione: l’iniziatore non è più interessato nel continuare l’interazione ed essa
deve essere terminata in una maniera accettabile sia per l’iniziatore che per il partecipante. Il
partecipante informa l’iniziatore che l’interazione è conclusa usando un inform-done o indica
il fallimento della cancellazione usando un failure. Il protocollo è riassunto in figura 2.5.
2.4.2. FIPA Contract Net Interaction Protocol
Specification
La negoziazione è l'insieme di attività ed operazioni(processo) che permettono a due o più
soggetti (negoziatori), ognuno con un interesse economico privato da perseguire (funzione di
utilità), di scambiarsi opinioni (offerte e contro-offerte) nel rispetto di un insieme di regole
condivise (protocollo di negoziazione) con lo scopo di arrivare ad un accordo finale. Il
protocollo di negoziazione ha il compito di coordinare gli agenti e di controllare il rispetto
delle regole di negoziazione. In particolare rappresenta l’insieme delle regole che governano
l’interazione. Caratteristiche:
• il processo di negoziazione è locale
• non vi è un’unità centrale di controllo
• esistono due direzioni di scambio per le informazioni
• ogni nodo (agente) valuta le informazioni in modo soggettivo dalla propria prospettiva
• l’accordo è raggiunto attraverso una mutua selezione.
Due ruoli possibili per i negoziatori:
• Manager
• Contractor
17

Ambiente di sviluppo
La specifica FIPA descrive un protocollo di interazione leggemente più complesso. Esso si usa
nel caso in cui un agente (l’inziatore) desidera che qualche compito sia eseguito da uno o più
altri agenti (i partecipanti) ovvero vuole iniziare una qualche forma di negoziazione. Si parte
dal presupposto che l’agente operi cercando di ottimizzare una qualche funzione che
caratterizza il compito, comunemente espressa come costo, ma che può anche essere il più
breve tempo di completamento, un’equa distribuzione dei compiti, etc. Per un dato
compito, qualsiasi numero di partecipanti può rispondere con un’offerta; il resto rifiuta. Le
trattative poi continuano con i partecipanti che presentano una proposta. L’inziatore
sollecita m offerte dagli altri agenti emanando un CA detto call for proposal (cfp) che
specifica il compito e ogni condizione cui l’iniziatore sottopone l’esecuzione del lavoro. I
partecipanti ricevendo la chiamata sono considerati come potenziali contraenti e sono capaci
di generare n risposte. Di queste, j sono proposte di eseguire il compito, specificate come CA
di tipo propose. La proposta del partecipante include le precondizioni che il partecipante ha
stabilito per il lavoro, che possono essere il prezzo, il momento in cui il lavoro sarà eseguito,
etc. D’altra parte, i = n – j partecipanti possono rifiutare di fare un’offerta. È necessario che
l’iniziatore sappia quando ha ricevuto tutte le risposte, altrimenti, nel caso che un
partecipante fallisca nel rispondere con una proposta o con un rifiuto, l’iniziatore potrebbe
potenzialmente rimanere in un’attesa indefinita. Per prevenire ciò, il CA cfp include un
termine entro il quale le risposte dovrebbero essere ricevute dall’iniziatore. Le proposte
ricevute dopo il termine sono automaticamente rifiutate con la motivazione che la risposta è
arrivata in ritardo. Il termine è specificato dal parametro reply-by nel mesaggio ACL. Una
volta che si oltrepassa la scadenza, l’iniziatore valuta le j proposte ricevute e seleziona gli
agenti che eseguiranno il compito; possono essere scelti uno, diversi o nessun agente. Agli
agenti delle proposte selezionate sarà mandato un CA accept-proposal mentre i rimanenti
agenti riceveranno un CA reject-proposal. Una volta che l’iniziatore accetta una proposta il
rispettivo partecipante acquisisce l’incarico di eseguire il compito. Quando il partecipante ha
completato il lavoro, manda un messaggio di completamento all’iniziatore nella forma di un
inform-done o nella versione più esplicativa di un inform-result. In ogni caso, se il
partecipante fallisce nel completare il compito, viene mandato un messaggio di fallimento. Il
protocollo è descritto in figura 2.6:
18

Ambiente di sviluppo
Figura 2-6 FIPA ContractNet Interaction Protocol
2.4.3. FIPA Agent Management Specification
In aggiunta alla comunicazione, il secondo aspetto fondamentale di un sistema ad agenti
preso in considerazione fin dalle prime specifiche FIPA è la gestione dell’agente. Questo
gruppo di specifiche mira alla definizione di una struttura normativa:
• all’interno della quale gli agenti FIPA-compatibili possono esistere ed operare;
• che stabilisca il modello logico di riferimento per la creazione, la registrazione, la
collocazione, la comunicazione, la migrazione e il funzionamento degli agenti.
19

AP - Agent Platform
Ambiente di sviluppo
Fornisce l’infrastruttura fisica in cui gli agenti sono collocati. L’AP è composta dalle
macchine, dai sistemi operativi, dagli altri componenti FIPA di gestione degli agenti, dagli
agenti stessi e da ogni software aggiuntivo di supporto. Il progetto specifico interno di una
AP è lasciato agli sviluppatori dei sistemi ad agenti concreti, e non è soggetto alla
standardizzazione FIPA. Le uniche richieste per la conformità allo standard sono la presenza
dei componenti individuati come parti fondamentali dell’astrazione e il rispetto delle relative
competenze. Poiché una singola AP può essere distribuita attraverso diverse macchine,
anche gli agenti non devono essere necessariamente situati sullo stesso host. Una
schematizzazione di una piattaforma ad Agenti è illustrata in figura 2.7:
Agent
Figura 2-7 Agent Platform
Un agente è un processo computazionale che appartiene ad una AP e tipicamente offre uno
o più servizi che possono essere resi pubblici con una descrizione di servizio. Un agente deve
avere almeno un proprietario (gestore) e deve supportare almeno un concetto di identità, il
quale può essere descritto usando il FIPA Agent Identifier (AID), che etichetta un agente così
che esso possa essere distinto inequivocabilmente all’interno del sistema. Un agente può
20

Ambiente di sviluppo
essere registrato ad un certo numero di indirizzi di trasporto presso i quali può essere
contattato. Un agente può trovarsi in vari stati durante la sua esistenza, FIPA formalizza
questo concetto (figura 2.8):
WAITING
Wake up
TRANSIT
Comportamento
caratteristico degli
agenti mobiliTipo di
Atto Comunicativo
Move
Agent Management System
Wait
Execute
ACTIVE
Resume
Invoke
SUSPENDED
Suspend
INITIATED
Figura 2-8 1.8 Ciclo di vita di un agente
Destroy
Create
È un componente obbligatorio nell’AP e per ognuna può essercene soltanto uno.
Rappresenta una sorta di unità di controllo dell’AP e per questo si usa dire che fornisce un
servizio di “pagine bianche” per gli agenti della piattaforma. É responsabile delle funzioni di
creazione, registrazione, modifica, migrazione da un’AP ad un’altra e terminazione di agenti.
Questo agente mantiene una descrizione della piattaforma stessa e di tutti gli agenti in essa
contenuti. In particolare mantiene un tabella con una entry per ogni agente nella quale si
trovano informazioni sullo stato del ciclo di vita dell’agente e sui diversi protocolli di
trasporto che l’agente che si registra prevede. Ogni agente, per poter risiedere sull’AP, deve
pertanto registrarsi all’AMS indicando il proprio AID (Agent IDentifier). Solamente dopo la
Quit
Unknown
21

Ambiente di sviluppo
registrazione l’agente può utilizzare, previa autorizzazione, l’agente MTS per il trasporto di
messaggi. Il ciclo di vita di un agente termina invece quando viene deregistrato dall’AMS.
Directory Facilitator
È un altro componente obbligatorio dell’AP e fornisce un servizio di “pagine gialle” agli altri
agenti, restituisce infatti, su richiesta, informazioni sui servizi offerti dagli altri agenti nella
piattaforma. Mantiene una lista aggiornata e completa degli agenti afferenti alla AP e
fornisce informazioni a chi le richiede ed è autorizzato. In una AP possono essere presenti più
DF anche federati. Ogni agente che vuole rendere pubblico un servizio deve registrarlo al DF
più appropriato. L’agente che fornisce il servizio non ha nessun obbligo nei confronti del DF.
È proprio per questo che il DF non può garantire in merito alla validità dei risultati restituiti
dal servizio. Ogni agente può modificare in qualsiasi momento le informazioni relative ad un
servizio offerto.
Message Transport Service
É l’agente che si occupa della comunicazione fra agenti, in particolare del trasporto dei
messaggi intra/inter-piattaforma. Ha il compito di trasportare ogni messaggio da un agente
ad un altro attraverso il protocollo più adatto. Definisce uno standard di comunicazione per
diverse piattaforme FIPA-compliant. I messaggi scambiati, nella loro forma astratta, sono
composti da una “envelope” e da un “payload”.
• Il payload è rappresentato dal messaggio ACL che l’agente vuole inviare e l’MTS non
deve in nessun caso alterarlo.
• L’“envelope”, che comprende l’insieme dei parametri necessari al trasporto, è invece la
parte del messaggio utilizzata dagli MTS .
L’insieme di specifiche Agent Message Transport tratta il trasporto e la rappresentazione dei
messaggi attraverso reti eterogenee.
22

Presenta delle sottosezioni:
Ambiente di sviluppo
• FIPA ACL Message Representation specifications: che trattano le diverse forme di
rappresentazione per i messaggi ACL.
• FIPA Envelope Representation specifications: trattano le diverse forme di
rappresentazione per l’envelope del messaggio ACL.
• FIPA Agent Message Transport Protocol (MTP) specifications: trattano diversi protocolli
per il trasporto di rete in grado di trasportare messaggi ACL.
2.5. FIPA-ACL
Il FIPA-ACL (Agent Comunication Language) fornisce le specifiche fondamentali per
implementare un linguaggio di comunicazione fra agenti, che si basa sostanzialmente sulla
teoria degli atti linguistici. Tale teoria asserisce che i messaggi rappresentano azioni, o atti
comunicativi (anche conosciuti come atti linguistici o performativi), cioè che un messaggio ha
l’intento di trasferire le intenzioni e i desideri del mittente al destinatario. Il FIPA-ACL
presenta le seguenti proprietà:
è capace di esprime i diversi atti linguistici (informare, richiedere, ...);
è indipendente dal protocollo di comunicazione utilizzato;
è indifferente al contenuto e al formato dell’informazione;
è comprensibile da tutti gli altri agenti.
Un messaggio FIPA ACL contiene un insieme di parametri che varia in funzione della
situazione d’uso. L’unico parametro obbligatorio, che deve essere presente in tutti i
messaggi, è il performative o atto performativo, che indica il tipo di comunicazione che si
vuole effettuare. In una tipica comunicazione sono quasi sempre presenti anche il sender
(l’agente che invia il messaggio), il receiver (il destinatario del messaggio) ed il content (il
contenuto vero e proprio del messaggio). Non c’è l’obbligo di usare un linguaggio particolare
per esprimere il contenuto, all’interno della struttura di un messaggio, sebbene esistano
23

Ambiente di sviluppo
specifiche per diverse rappresentazioni fra cui FIPA-SL, FIPA-KIF e FIPA-RDF (solo quella
relativa a FIPA-SL, fra queste, è stata promossa allo stato di standard).
Parametri del messaggio FIPA-ACL
Parametro Descrizione
performative
sender
receiver
reply-to
Content
language
encoding
ontology
Denotes the type of the communicative act of the ACL
message
Denotes the identity of the sender of the message, that is,
the name of the agent of the communicative act.
Denotes the identity of the intended recipients of the
message.
This parameter indicates that subsequent messages in this
conversation thread are to be directed to the agent named
in the reply-to parameter, instead of to the agent named in
the sender parameter.
Denotes the content of the message; equivalently denotes
the object of the action. The meaning of the content of any
ACL message is intended to be interpreted by the receiver of
the message. This is particularly relevant for instance when
referring to referential expressions, whose interpretation
might be different for the sender and the receiver.
Denotes the language in which the content parameter is
expressed.
Denotes the specific encoding of the content language
expression.
Categorie dei
Parametri
Tipo di atto
comunicativo
Participante alla
communicazione
Participante alla
communicazione
Participante alla
communicazione
Contenuto del
messaggio
Descrizione del
contenuto
Descrizione del
contenuto
Denotes the ontology(s) used to give a meaning to the Descrizione del
24

protocol
conversation-id
reply-with
in-reply-to
reply-by
Ambiente di sviluppo
symbols in the content expression. contenuto
Denotes the interaction protocol that the sending agent is
employing with this ACL message.
introduces an expression (a conversation identifier) which is
used to identify the ongoing sequence of communicative
acts that together form a conversation.
Controllo della
conversazione
Controllo della
conversazione
Introduces an expression that will be used by the responding Controllo della
agent to identify this message.
Denotes an expression that references an earlier action to
which this message is a reply.
Denotes a time and/or date expression which indicates the
latest time by which the sending agent would like to receive
a reply.
Tabella 2-1 Parametri del messaggio FIPA-ACL
2.5.1. FIPA Comunicative Act Library
Specification
conversazione
Controllo della
conversazione
Controllo della
conversazione
Un agente che vuole inviare un messaggio ad un altro deve esprimere la sua intenzione.
Questo viene realizzato iniziando ogni messaggio con delle parole chiave che rappresentano
l’intenzione dell’agente che ha inviato il messaggio stesso. Tale parola chiave è il tipo di atto
comunicativo. Questo standard fornisce una libreria di tutti gli atti comunicativi riconosciuti
dalla FIPA, ed utilizzabili nel linguaggio FIPA-ACL. E’ stabilito negli standard che per essere
completamente compatibile un agente deve essere capace di ricevere qualsiasi atto
comunicativo FIPA-ACL e almeno rispondere, nel caso che il messaggio ricevuto non possa
25

Ambiente di sviluppo
essere processato, con un messaggio not-understood. Alcuni atti comunicativi e loro
significato:
Accept proposal Failure Propose Reject proposal
Agree Inform Proxy Request
Cancel Inform if Query if Request when
Call for proposal Inform ref Query ref Request whenever
Confirm Not-undeerstood Refuse Subscribe
Disconfirm Propagate
Accept proposal Indica che si accetta una proposta precedentemente ricevuta di eseguire una certa
azione
Agree Indica che si acconsente ad eseguire qualche azione eventualmente in futuro
Call for Proposal Indica che si attendono proposte per l’esecuzione di una certa azione
Failure Comunica il fallimento del tentativo di eseguire una certa azione
Inform Il mittente informa il destinatario che una data proposizione è vera
Not Understood Il mittente comunica al destinatario che ha percepito l’azione da lui compiuta ma non
è stato in grado di interpretarla. Il caso più semplice e comune è la non comprensione
di un certo messaggio ricevuto.
Propose Comunica una proposta di eseguire una certa azione sotto determinate condizioni
Refuse Comunica il rifiuto ad eseguire un’azione e la motivazione
Reject Proposal Indica il rifiuto di una proposta durante un processo di negoziazione
Request Il mittente chiede al destinatario di compiere una certa azione
Tabella 2-2 Atti comunicativi e significato
26

Ambiente di sviluppo
2.5.2. FIPA SL Content Languages Specification
Questa specifica definisce una sintassi concreta per il FIPA Semantic Language (SL) (la quale
può essere considerata una sotto-grammatica di una sintassi molto più generale che è quella
s-expression). Tale linguaggio può essere impiegato nell’espressione dei contenuti, in quanto
capace di definire la semantica intenzionale per gli atti comunicativi. Questa sintassi e la
semantica associata sono proposte per l’uso congiunto con il FIPA Agent Communication
Language. Un’espressione di contenuto, nella forma del FIPA-SL, usata come contenuto di un
messaggio ACL, può assumere tre forme:
1. Proposizione, che può avere assegnato un valore di verità in un dato contesto. Nel
dettaglio essa è una formula ben-formata (fbf) usando le opportune regole di
produzione. Una proposizione è usata nel CA inform e in altri CA derivati da esso.
2. Azione, che può essere eseguita. Si può trattare di una singola azione o di un’azione
composta, costruita usando operatori di sequenzializzazione (sequencing - ;) e di scelta
fra alternative (alternative - |). Un’azione è usata come espressione di contenuto quando
l’atto è request e altri CA derivati da esso.
3. Espressione di riferimento identificativo (IRE), che identifica un oggetto nel dominio. Si
ottiene con l’uso di un operatore referenziale (iota, any, all) ed è usata nel gruppo di
comandi inform-ref e negli altri CA derivati da esso.
Altre espressioni di contenuto valide si possono ottenere come composizione dei casi
precedenti. Ad esempio:
- Una coppia action-condition (rappresentata da un’azione seguita da una fbf) è usata
nell’atto comunicativo propose.
- Una terna action-condition-reason (rappresentata da una azione seguita da due fbf) è
usata nell’atto comunicativo reject-proposal.
L’esempio illustra un’interazione fra due agenti A e B che fanno uso dell’operatore iota, dove
si suppone che l’agente A abbia la seguente base di conoscenza
– KB = {P(A), Q(1, A), Q(1, B)}.
27

Ambiente di sviluppo
L’espressione (iota x (P x)) può essere letta come “la x tale che P *è vero+ di x”.
L’operatore iota definisce uno scope per l’espressione data, nel quale è definito
l’identificatore che altrimenti sarebbe libero; è un costruttore per termini che denotano
oggetti del dominio del discorso.
L’unico oggetto che soddisfa la proposizione P(x) è a; quindi, al messaggio query-ref inviato
da B viene mandato in risposta il messaggio inform come mostrato.
2.5.3. FIPA Agent Message Transport Service
Specification
Un FIPA Message Transport Service (MTS) fornisce il meccanismo per il trasferimento dei
messaggi FIPA-ACL fra agenti usando un Protocollo di Trasporto dei Messaggi (MTP). Gli
agenti coinvolti possono essere locali rispetto ad un unico AP o trovarsi su piattaforma
diverse. In ogni dato AP, l’MTS è fornito di un Agent Communication Channel (ACC) che è
responsabile dell’invio e della ricezione dei messaggi sull’AP: esso deve trasferire i messaggi
che riceve in conformità con le istruzioni di trasporto contenute nell’involucro del messaggio
e gli viene richiesto soltanto di leggere tale “envelope”; non gli è richiesto di analizzare il
payload del messaggio. Ogni MTP può usare una rappresentazione interna diversa per
28

Ambiente di sviluppo
descrivere l’envelope del messaggio, ma deve esprimere gli stessi termini, rappresentare la
stessa semantica ed eseguire le corrispondenti azioni. L’envelope di un messaggio
comprende una collezione di parametri ognuno dei quali è una coppia nome/valore con i
campi obbligatori to, from, date e acl-representation, ogni ACC che maneggia un messaggio
può aggiungere nuova informazione al “message envelope” stesso, ma non può mai
sovrascrivere l’informazione (payload) esistente. Il comportamento di un ACC nell’inoltrare i
messaggi è determinato dalle istruzioni per la consegna del messaggio che sono espresse nel
“message envelope”.
Parameter Description
to
from
The names of the primary recipients of the message. If no intended-receiver
parameter is present, then the information in this parameter is used to
generate intended-receiver field for the messages the ACC subsequently
forwards.
comments Text comments.
acl-representation
payload-length
payload-encoding
date
intended-receiver
The name of the agent that sent the message. If required, the ACC returns
error and confirmation messages to the agent specified in this parameter.
The syntax representation of the message payload. This information is
intended for the final recipient of the message.
The length in bytes of the message payload. The ACC may use this
information to improve parsing efficiency.
The language encoding of the message payload. This information is intended
for the final recipient of the message.
The creation date and time of the message envelope. This information is
intended for the final recipient of the message.
The name of the agents to whom this instance of a message is to be
delivered. An ACC uses this parameter to determine where this instance of a
29

eceived
Ambiente di sviluppo
message should be sent. If this parameter is not provided, then the first ACC
to receive the message should generate an intended-receiver parameter
using the to parameter.
A stamp indicating receipt of a message by an ACC. A new received
parameter is added to the envelope by each ACC that the message passes
through. Each ACC handling a message must add a completed received
parameter. If an ACC receives a message it has already stamped, it is free to
discard the message without any need to generate an error message.
transport-behaviour The transport requirements of the message. Reserved for future use.
Tabella 2-3 Parametri messaggio
I destinatari di un messaggio sono specificati nel parametro to e prendono la forma di AID. A
seconda della presenza del parametro intended-receiver, l’ACC inoltra i messaggi in uno dei
seguenti modi:
• Se un ACC riceve un envelope di messaggio senza il parametro intended-receiver, allora
esso genera un nuovo parametro intended-receiver dal parametro to. Esso può anche
generare più copie del messaggio con diversi parametri intended-receiver se sono
specificati più destinatari. In ogni caso, all’ACC è richiesto di elaborare tutti gli elementi
nel parametro to e di non aggiungere né di rimuovere alcun AID che sia contenuto nel
messaggio originale. Il parametro intended-receiver forma un percorso di consegna che
mostra il cammino che il messaggio ha intrapreso.
• Se un ACC riceve un envelope di messaggio con un parametro intended-receiver, questo
è usato per la consegna e il parametro to è ignorato.
• Se un ACC riceve un envelope di messaggio con più di un parametro intended-receiver,
viene usato il più recente.
Prima di inoltrare il messaggio l’ACC aggiunge un parametro received all’envelope. Una volta
che l’ACC ha inoltrato il messaggio non ha più bisogno di tenere alcuna traccia della sua
esistenza.
30

Ambiente di sviluppo
L’AID presente nel parametro to o intended-receiver del “message envelope” può contenere
più indirizzi di trasporto per un singolo agente destinatario.
L’ACC usa il seguente metodo per cercare di consegnare il messaggio:
• Prova a consegnare il messaggio al primo indirizzo di trasporto nel parametro addresses
(per riflettere il fatto che la lista degli indirizzi di trasporto in un AID è ordinata a seconda
della preferenza).
• Se fallisce (perché l’agente o l’AP non sono disponibili o perché l’ACC non supporta il
protocollo di trasporto del messaggio appropriato, etc.), allora l’ACC crea un nuovo
parametro intended-receiver che contiene l’AID senza l’indirizzo di trasporto che ha
portato al fallimento dell’operazione. L’ACC poi tenta di mandare il messaggio
all’indirizzo di trasporto successivo nell’AID della lista intended-receiver.
• Se la consegna ancora non ha successo quando sono stati provati tutti gli indirizzi di
trasporto (o se l’AID non contiene alcun indirizzo di trasporto), l’ACC può provare a
stabilire l’AID usando i servizi di risoluzione dei nomi elencati nel parametro resolvers
dell’AID. Nuovamente, i servizi di risoluzione dei nomi devono essere provati nell’ordine
in cui compaiono.
• Infine, se tutti i precedenti tentativi di consegna dei messaggi falliscono, viene mandato
indietro un appropriato messaggio per il fallimento finale all’agente mittente.
Un ACC usa le seguenti regole nel consegnare i messaggi a destinatari multipli:
• Se un ACC riceve un involucro di messaggio senza parametro intended-receiver e con un
parametro to che contiene più di un AID, esso può o meno dividerli per formare
messaggi separati. Ogni messaggio contiene un sottoinsieme degli agenti nominati nei
parametri to e intended-receiver.
• Se un ACC riceve un involucro di messaggio con un parametro intended-receiver
contenente più di un AID, esso può o meno dividerli per formare messaggi separati.
31

Ambiente di sviluppo
2.6. JADE: Java agent development
environment
2.6.1. JADE: caratteristiche generali
JADE (Java Agent DEvelopment Framework) è un ambiente di sviluppo di software ad agenti
interamente implementato in linguaggio Java ([8]). Esso semplifica l’implementazione di
sistemi multi-agente attraverso un middleware che soddisfa le specifiche FIPA e un set di
tools per il supporto alle fasi di debugging e sviluppo. È stato sviluppato grazie alla
collaborazione del CSELT (Centro Studi E Laboratori Telecomunicazioni) di Torino e del
dipartimento di Informatica dell’Università di Parma. É un software libero distribuito secondo
la licenza GNU LGPL (Lesser General Public Licencse). Tale licenza è meno restrittiva della
licenza GPL. Permette infatti di distribuire prodotti commerciali che contengano al loro
interno il codice in esame a patto che sia distinguibile dal resto dell’applicazione. Inoltre
qualsiasi modifica alla libreria soggetta alla licenza LGPL deve essere documentata. Infine
occorre sottolineare che nel caso le classi della libreria che sottostà alla licenza LGPL ed il
codice proprietario siano distinguibili, allora la licenza LGPL non si estende automaticamente
anche all’applicazione risultante che può essere quindi distribuita con la licenza desiderata.
JADE richiede come unico presupposto la presenza di una Java Virtual Machine (almeno ver.
1.2) per ogni host su cui viene installato.
Le caratteristiche principali di JADE sono:
- una piattaforma ad agenti conforme alle specifiche FIPA che include gli agenti obbligatori
quali: AMS (Agent Management System), DF (Directory Facilitator), MTS (Message
Transport System). In base alle specifiche FIPA 2000 l’MTS non è un agente ma è una
componente della piattaforma. Tutti e tre questi elementi vengono avviati
automaticamene all’avvio della piattaforma.
- una piattaforma ad agenti distribuiti su diversi host. È possibile anche avviare più di una
piattaforma (AP) sullo stesso host ma questa operazione viene sconsigliata dagli stessi
32

Ambiente di sviluppo
sviluppatori in quanto rallenta notevolmente la CPU che viene sovraccaricata, inoltre le
comunicazioni sono più lente e più complesse da realizzare in quanto occorre definire
nel protocollo anche la piattaforma che si vuole indirizzare.
- agenti implementati come threads Java che vivono all’interno di Agent Containers (AC) i
quali provvedono all’esecuzione run-time degli agenti. Ogni AP contiene uno o più AC. La
soluzione a threads consente agli agenti di eseguire più task concorrentemente e
permette una comunicazione leggera ed efficiente.
- più DFs FIPA-Compliants che possono essere avviati a run-time al fine di implementare
applicazioni multidominio, dove un dominio è un set logico di agenti i cui servizi sono
inseriti in un “facilitator” comune. Ogni DF eredita un’interfaccia GUI e tutte le capacità
standard definite dalle specifiche FIPA (es. capacità di registrare, deregistrare, modificare
e cercare agenti; capacità di “federating” in una rete di DFs). È da notare, inoltre, che
ogni agente della piattaforma può registrarsi a più DF della piattaforma in modo da
fornire il proprio servizio ad una comunità di agenti più vasta.
- una comunicazione basata sul trasporto di messaggi ACL che sono essi stessi oggetti
Java. Tale soluzione facilita il programmatore nella creazione di messaggi.
- un meccanismo di trasporto efficiente che utilizza i protocolli JAVA RMI, la notifica di
eventi ed il protocollo IIOP (Internet Inter-Orb Protocol). Il meccanismo è intelligente e
per ogni messaggio utilizza automaticamente il protocollo più appropriato.
- una libreria di protocolli di interazione per la comunicazione fra agenti conformi agli
standard definiti da FIPA.
- un servizio di nomi FIPA-compliant per cui all’atto della registrazione degli agenti presso
l’AMS, questi ottengono il loro AID dalla piattaforma.
- un supporto all’esecuzione di attività multiple, parallele o concorrenti degli agenti,
attraverso modelli di comportamento di quest’utlimi già predisposti di tipo: run once,
ciclico, sequenziale, parallelo, FSM (Finite State Machine). JADE provvede allo scheduling
degli agenti in modo non-preemptive.
33

Ambiente di sviluppo
- tools di debug per favorire lo sviluppo di applicazioni multiagente basate su JADE:
Remote Management Agent (RMA), Dummy Agent, Sniffer, DF GUI, Introspector Agent.
- il supporto a linguaggi ed ontologie che possono essere implementati, registrati con gli
agenti ed automaticamente utilizzati nel framework. A riguardo esiste il software
Protegè per la definizione di ontologie dotato di un plug-in chiamato BeanGenerator che
genera classi Java direttamente utilizzabili da JADE.
- un supporto alla mobilità intra-platform di agenti includendo stato, codice ed ontologie
dell’agente.
- un’interfaccia GUI per monitorare gli agenti della piattaforma e le comunicazioni fra di
essi da un host remoto.
2.6.2. 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. La figura 2.9 illustra l’architettura JADE:
34

Ambiente di sviluppo
Figura 2-9 Architettura JADE
2.6.3. 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. 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
35

Ambiente di sviluppo
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. I
container della stessa piattaforma comunicano, invece, grazie ad un altro protocollo
chiamato IMTP ( Internal Message Transport Protocol ).
2.6.4. IMTP ( Internal Message Transport
Protocol )
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
36

Ambiente di sviluppo
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.
RMA agent
2.6.5. Special agents
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. La figura 2.10 illustra l’interfaccia grafica dell’ RMA. ([13])
Dummy agent
Figura 2-10 GUI dell'Agente RMA
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
37

Ambiente di sviluppo
tramite interfaccia caricare e salvare messaggi standard. Più istanze di questo agente
possono essere lanciate.
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.
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.
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.
Uno schema riassuntivo è ilustrato in figura 2.11:
38

Ambiente di sviluppo
Figura 2-11 Diagramma delle classi di JADE tools
39

Ambiente di sviluppo
2.6.6. JADE Packages
la piattaforma Jade è organizzata a livelli gerarchici di pacchetti java e sottopacchetti, dove
ogni packages contiene un set di clssi e interface che implementano specifiche e funzionalità.
I Package principali sono:
Jade.core : rappresenta i cuore dell’intero package. Include un set di sotto packages dove
ognuno implementa uno specifico servizio
Jade.core.event : implementa il servizio di notifica degli eventi distribuiti nel sistema
Jade.core.management : implementa il ciclo di vita degli agenti
Jade.core.messaging : implementa il servizio di distribuzione dei messaggi
Jade.core.mobility : implementa il servizio di mobilità dell’agente, includendo il
trasferimento sia dello stato che del codice dell’agente.
Jade.core.behaviours : Contiene una gerarchia di comportamenti degli agenti
Jade.lang : contiene le classi riguardanti i linguaggi di comunicazione utilizzati tra cui ACL
Jade.domain : implementa le specifiche FIPA riguardanti i modelli, linguaggi, ontologie.
Contiene anche le implementazioni degli agenti ANS e DF, piu la loro estenzione in Jade.
Jade.proto : contiene le classi che implementano i protocolli FIPA per l’interazione tra
agenti (FIPA-REQUEST, FIPA-QUERY)
Jade.gui : set di classi generiche utili alla realizzazione di interfacce grafiche GUI
Jade.mtp : queste classi sono dedicate a tutti i metodi per il trasporto dei messaggi
(Message Transport Protocol)
Jade.tools : contiene una serie di tools utili alla gestione e al controllo della piattaforma
e/o degli agenti.
40

2.6.7. Classe Agent
Ambiente di sviluppo
La classe Agent rappresenta la classe base comune per la specifica di agenti definiti
dall’utente. Un agente JADE è dunque un’istanza di una classe che estende la classe base
Agent. Questo implica l’eredità dei metodi base di registrazione, configurazione, gestione
remota e dei metodi utilizzati per definire il comportamento dell’agente (es. send, receive di
messaggi o utilizzo di protocolli di interazione standard).
Il modello computazionale di un agente è multitask dove ogni task, detto anche
comportamento (behaviour), viene eseguito concorrentemente. Ogni servizio previsto
dell’agente dovrebbe essere implementato attraverso uno o più behaviours. All’interno
dell’agente base vi è uno scheduler nascosto al programmatore che esegue
automaticamente lo scheduling dei behaviours. Per creare un agente si estende la classe
jade.core.agent e si implementa il metodo setup(). Esempio:
import jade.core.Agent;
public class HelloWorldAgent extends Agent {
protected void setup() {
System.out.println("Hello World! My name is "+getLocalName());
doDelete();} }
Il metodo setup include l’inizializzazione dell’agente, tipiche operazioni come: mostrare gui,
aprire connessione a database, registrare dei servizi che l’agente fornisce al DF e far partire i
comportamenti iniziali. È buona pratica non definire alcun costruttore nella classe agente e di
fare tutte le inizializzazioni nel setup().Ogni istanza di un agente è identificato da un Agent
Identifier che applica le specifiche FIPA. In Jade un Agent Identifier è rappresentato come una
istanza di jade.core.AID. getAID() ritorna il suo AID, un oggetto AID include un nome
globalmente unico (GUID) piu un numero di indirizzo. Il nome in Jade ha la forma @. Per esempio se ho un agente chiamato Peter che vive su una
piattaforma chiamata foo-platform ha Peter@foo-platform come suo nome globale unico. Gli
indirizzi inclusi nell’AID sono gli indirizzi della piattaforma dove lui non abita, questi indirizzi
sono utilizzati solo quando l’agente vuole comunicare con un altro agente in una piattaforma
41

Ambiente di sviluppo
differente. L’AID classe fornisce metodi per ricevere il nome locale, il GUID e gli indirizzi,
rispettivamente con i metodi getLocalName() , getName() , getAllAddresses(). Esempio:
Protected void setup(){
}
System.out.println(“Hello World”);
System.out.println(“My local name is ”+ getAID().getLocalName());
System.out.println(“My GUID is ”+getAID().getName());
System.out.println(“My addresses are:”);
Iterator it = getAID().getAllAddresses();
While (it.hasNext()){
System.out.println(“_”+it.next());
}
Il nome locale di un agente è assegnato dal creatore ed è unico nella piattaforma.
Conoscendo il nome locale di un agente puoi ottenere l’AID con
String localname=”Peter”;
AID id= new AID(localname,AID.ISLOCALNAME);
Altrettanto conoscendo il GUID di un agente puoi ottenere l’AID con :
string guid=”Peter@foo-platform”;
AID id= new AID(guid,AID.ISGUID);
2.6.8. Comportamenti degli agenti
Un agente deve essere in grado di eseguire task concorrenti diversi in risposta ad eventi
esterni diversi. Per una gestione efficace dell’agente, ogni agente JADE è composto da un
singolo thread di esecuzione e tutti i suoi tasks sono modellati ed implementati come oggetti
Behaviour ([2]). Lo sviluppatore che vuole implementare un task di uno specifico agente
dovrebbe definire una o più sottoclassi di Behaviour, istanziarle ed aggiungere gli oggetti
42

Ambiente di sviluppo
behaviours alla lista dei tasks dell’agente. É possibile inserire o rimuovere behaviours dalla
lista dei tasks dell’agente, non solo all’interno del metodo setup(), ma in qualsiasi metodo del
codice dell’agente attraverso addBehaviour(behaviour) e removeBehaviour(behaviour). Uno
scheduler implementato dalla classe base Agent, nascosto al programmatore, si occupa dello
scheduling dei behaviours disponibili nella coda dei tasks, utilizzando un algoritmo di tipo
round-robin non-preemptive. Lo scheduler agisce invocando il metodo action() di ogni
Behaviour presente nella coda dei behaviours. Quando il metodo action() termina viene
controllato il metodo done() per verificare se il behaviour ha completato il task oppure no, e
in caso affermativo viene tolto dalla coda. Occorre sottolineare che quando il metodo
action() di un Behaviour di un agente è in esecuzione, nessun altro Behaviour della lista dei
comportamenti dell’agente può eseguire fino alla fine del metodo. Ciò vale in relazione ai
behaviours di uno stesso agente, mentre due comportamenti di due agenti diversi possono
eseguire il metodo action() concorrentemente. Ogni Behaviour può entrare in uno stato
bloccato; in particolare, il metodo block() lo pone in una lista di behaviours bloccati. Ogni
Behaviour viene poi rischedulato ogni qualvolta arriva un nuovo messaggio ACL, se termina
un timeout associato allo stato di bloccato oppure se viene invocato esplicitamente il metodo
restart(). JADE fornisce una discreta quantità di behaviours standard elencati di seguito.
- Behaviour: è una classe astratta per modellare i task degli agenti e pone le basi per lo
scheduling dei behaviours. Il metodo block() pone il Behaviour nella lista dei
comportamenti bloccati, tipicamente al fine di attendere un determinato messaggio
ACL in arrivo. Vi sono inoltre due metodi onStart() ed onEnd() attivati rispettivamente
prima e dopo l’esecuzione del behaviour. Il metodo onEnd() è chiamato dopo che il
behaviour è completato e rimosso dalla coda di comportamenti attivi.
- SimpleBehaviour: è una classe astratta che modella un comportamento semplice e
atomico. Il suo metodo reset() non fa niente ma può essere ridefinito dalle sottoclassi
definite dall’utente.
43

Ambiente di sviluppo
• OneShotBehaviour: è una sottoclasse astratta di SimpleBehaviour che modella un
comportamento atomico che deve essere eseguito solo una volta e non può
essere bloccato. Il suo metodo done() restituisce, quindi, sempre true.
• CyclicBehaviour: è una sottoclasse astratta di SimpleBehaviour che modella un
comportamento atomico che deve essere eseguito per sempre. Il suo metodo
done() restituisce, quindi, sempre false.
• TickerBehaviour: è una sottoclasse astratta di SimpleBehaviour che modella un
comportamento atomico che deve essere eseguito periodicamente. Per fare ciò
occorre ridefinire il metodo onTick(). Il periodo viene impostato attraverso un
parametro passato nel costruttore.
- CompositeBehaviour: è una classe astratta che modella un comportamento composto
da un certo numero di altri behaviours (figli). Le operazioni eseguite non sono definite
all’interno di questa classe, ma dentro i figli che compongono il CompositeBehaviour
che ha la sola responsabilità di schedularli. In realtà la classe CompositeBehaviour non
definisce nessuna regola di scheduling; risulta quindi conveniente per il programmatore
utilizzare una delle sue sottoclassi: SequentialBehaviour, ParallelBehaviour o
FSMBehaviour.
• SequentialBehaviour: è una sottoclasse di CompositeBehaviour che esegue i suoi
sub-behaviours in modo sequenziale e termina quando tutti i sub-behaviours
sono terminati.
• ParallelBehaviour: è una sottoclasse di CompositeBehaviour che esegue i suoi sub-
behaviours in modo concorrente e termina quando una particolare condizione
dei suoi sub-behaviours è verificata. Sono inoltre previste delle costanti da
passare al costruttore di ParallelBehaviour per terminare quando tutti i suoi figli
sono terminati, o quando uno particolare fra i suoi figli termina, o quando un
numero N - definito dall’utente - di suoi figli termina.
• FSMBehaviour: è una sottoclasse di CompositeBehaviour che esegue i suoi sub-
behaviours in accordo ad una macchina a stati finiti (Finite State Machine, FSM)
definita dall’utente. Ogni sub-behaviour rappresenta un’attività dentro uno
44

Ambiente di sviluppo
stato della FSM e l’utente può definire le transizioni fra gli stati della FSM.
Quando il figlio corrispondente allo stato Si termina, il suo valore di ritorno
(restituito dal metodo onEnd() ) viene utilizzato per determinare la transizione
ed un nuovo stato Sj viene raggiunto. Alcuni dei figli di un FSMBehaviour
possono essere registrati come possibili stati finali. Un FSMBehaviour termina
dopo la terminazione di uno di questi figli.
- SenderBehaviour: è una sottoclasse di OneShotBehaviour che realizza l’azione atomica
di send di un messaggio ACL passato nel costruttore e pertanto viene eseguita solo una
volta.
- ReceiverBehaviour: è una sottoclasse di Behaviour che realizza l’azione atomica di
receive di un messaggio ACL che viene copiato in uno specifico ACLMessage passato nel
costruttore. La sua action() termina non appena un messaggio viene ricevuto. Nel caso
la coda dei messaggi ricevuti sia vuota o nessun messaggio fa matching, il metodo
action() blocca il behaviour. Esistono anche due versioni del costruttore con cui è
possibile impostare un timeout entro il quale l’agente rimane in attesa del messaggio
da ricevere.
- WakerBehaviour: è una sottoclasse astratta di SimpleBehaviour che implementa un
task di tipo OneShot che deve essere eseguito solo una volta dopo che un certo
timeout è trascorso.
2.6.9. Protocolli di interazione
FIPA specifica un insieme di protocolli di interazione standard per costruire le conversazioni
fra gli agenti. Per ogni tipo di conversazione JADE distingue i ruoli di Initiator - l’agente che
inizia la conversazione - e di Responder - l’agente che risponde ad una conversazione dopo
essere stato contattato - . JADE prevede behaviours pronti all’uso per entrambi i ruoli della
maggior parte dei protocolli di interazione definiti da FIPA (package jade.proto). Tutti i
45

Ambiente di sviluppo
behaviours di tipo Initiator terminano e sono rimossi dalla coda dei tasks appena
raggiungono lo stato finale del protocollo di interazione. I Responders invece sono ciclici e
vengono rischedulati non appena giungono in uno stato finale dell’interazione. Questa
caratteristica consente di stabilire il numero massimo di conversazioni simultanee di un
Responder. FIPA ha definito un certo numero di protocolli di interazione con l’obiettivo di
effettuare una conversazione, permettendo il controllo - da parte del sender - che il receiver
abbia eseguito l’operazione richiesta. Le classi di JADE AchieveREInitiator e
AchieveREResponder servono a questo scopo e vanno bene per una serie di protocolli con la
medesima struttura: FIPA-request, FIPA-query, FIPA-propose, FIPA-Request-When, FIPA-
recruiting, FIPA-brokering. JADE provvede inoltre ad implementare il protocollo FIPA-
Contract-Net attraverso le classi Contract-Net-Initiator e ContractNetResponder.
AchieveREInitiator:
Questa classe è una sottoclasse di FSMBehaviour e rappresenta il ruolo dell’Initiator.
Un’istanza di questa classe può essere creata passando come argomento il messaggio da
inviare per iniziare il protocollo. Può essere facilmente estesa ridefinendo uno o più dei suoi
metodi handleXXX che provvedono a gestire tutti gli stati del protocollo. Per esempio, il
metodo handleRefuse viene chiamato quando un messaggio refuse viene ricevuto. Questa
implementazione gestisce la scadenza del timeout, come espresso nel campo reply-by del
messaggio ACL inviato.
AchieveReResponder:
Questa classe implementa il ruolo del Responder. Per il corretto funzionamento è molto
importante passare al costruttore l’esatto MessageTemplate per selezionare quale
messaggio deve essere servito. Può essere facilmente estesa ridefinendo uno o più dei suoi
metodi prepareXXX che provvedono a gestire gli stati del protocollo. Per esempio, il metodo
prepareResponse viene chiamato quando un messaggio dell’Initiator viene ricevuto e deve
essere preparata la prima risposta da spedire (es. Agree).
46

ContractNetInitiator:
Ambiente di sviluppo
Implementa il ruolo dell’Initiator nel protocollo cfp (call for proposal) tenendo conto anche
della gestione dei timeout di attesa delle risposte e fornendo, inoltre, la possibilità di
aspettare per un tempo indefinito. Vengono forniti un set di metodi callback per gestire ogni
stato del protocollo, i quali sono chiamati quando un certo tipo di messaggio viene ricevuto.
ContractNetResponder:
Implementa il ruolo del Responder nel protocollo cfp (call for proposal). Come nel caso
dell’AchieveReResponder, per il corretto funzionamento, è molto importante passare al
costruttore l’esatto MessageTemplate in modo da selezionare quale messaggio deve essere
servito. Può essere facilmente estesa ridefinendo uno o più dei suoi metodi prepareXXX che
provvedono a gestire gli stati del protocollo. Per esempio, il metodo prepareResponse viene
chiamato quando un messaggio dell’Initiator viene ricevuto e deve essere preparata la prima
risposta da spedire (es. Propose).
2.6.10. Supporto alle ontologie
Le ontologie specifiche delle applicazioni descrivono gli elementi che gli agenti utilizzano per
creare il contenuto dei messaggi (es. predicati ed azioni della specifica applicazione) ([2]).
JADE provvede alla specifica di ontology definite dall’utente attraverso il package
jade.content ed i suoi subpackages. Il codice che implementa le ontologie ed il codice che
invia/riceve i messaggi non dipende dal linguaggio dei contenuti utilizzato. Quando un agente
A comunica con un altro agente B, una certa informazione I viene trasferita da A a B
attraverso un messaggio ACL, in particolare, l’informazione I è trasferita sottoforma di
attributo content del messaggio, espressa in un certo linguaggio di contenuti (es. Semantic
Language) e codificato in un proprio formato (es. String). Entrambi gli agenti possono avere
una propria rappresentazione interna dell’informazione I che può essere diversa l’una
dall’altra. Occorre considerare poi che tipicamente le informazioni vengono rappresentate
internamente all’agente in modo diverso da come vengono trasferite nei messaggi ACL.
Internamente abbiamo solitamente delle istanze di oggetti Java che rappresentano
47

Ambiente di sviluppo
l’informazione; a livello di messaggi ACL, invece, abbiamo tipicamente una stringa che
sicuramente non sarebbe maneggevole da utilizzare come rappresentazione interna.
Per un corretto funzionamento del sistema quindi occorrono due passi:
1) l’agente A converte la sua rappresentazione interna di I nella corrispondente
rappresentazione dell’ACL content. Dalla parte opposta l’agente B, alla ricezione del
messaggio, deve effettuare la conversione inversa, dal content language alla sua
rappresentazione interna.
2) B deve provvedere ad una serie di controlli semantici per verificare che l’informazione I sia
un’informazione significativa, ossia sia conforme alle regole (es. età deve essere un intero)
dell’ontologia.
JADE fornisce un supporto alle ontologie ed ai linguaggi di contenuti, effettuando tutte le
conversioni e le operazioni di verifica della semantica in modo automatico. Questo permette
agli sviluppatori di manipolare le informazioni all’interno degli agenti attraverso oggetti Java.
Figura 2-12 Contenuto comunicazione fra Agenti
Le operazioni di conversione e di check semantici sono effettuate da un content manager.
Ogni agente JADE include al suo interno un content manager accessibile con il metodo
getContentManager() della classe Agent. La classe ContentManager contiene tutti i metodi
48

Ambiente di sviluppo
per trasformare oggetti Java in stringhe ed inserirli nell’attributo content dell’ACLMessage e
viceversa. In realtà le operazioni di conversione e di check vengono delegate all’ontology
(semantic check) ed ad un content language codec (conversione). Al fine di eseguire gli
adeguati check semantici di una data content expression, è necessario classificare tutti gli
elementi del dominio del discorso in accordo alle loro caratteristiche semantiche generiche.
Ad un primo livello di classificazione occorre distinguere fra predicati (predicates) e termini
(terms).
Predicates: sono espressioni che riferiscono qualcosa a proposito dello stato del
dominio e possono essere true o false.
Terms: sono espressioni che identificano entità che “esistono” nel dominio e su cui
l’agente deve ragionare. Sono ulteriormente classificati in concepts, agent actions,
primitives, aggregates, identifying referential expressions (IRE), variables:
Concepts: sono espressioni che rappresentano entità con una struttura complessa
che può essere definita in termini di slot .
Agent Actions: sono concetti speciali che indicano azioni che possono essere eseguite
da un agente.
Primitives: sono espressioni che identificano entità atomiche come stringhe o interi.
Aggregates: sono espressioni che rappresentano entità che raggruppano altre entità.
Identifying Referential Expressions (IRE): rappresentano una o più entità per cui un
certo predicato è true. Sono tipicamente utilizzate per effettuare queries.
Variables: indicano un generico elemento non conosciuto a priori. Sono utilizzate di
solito all’interno di queries.
Ogni classe che implementa il concetto di fipa-agent-management ontology è una semplice
collezione di attributi con metodi pubblici per leggerli e scriverli in accordo al modello basato
sulla rappresentazione specificata da FIPA. Per ogni attributo della classe chiamato attrName
del tipo attrType, sono possibili due casi:
- Il tipo è un valore singolo: può, quindi, essere letto con getAttrName() e scritto con
setAttrName(attrType a).
49

Ambiente di sviluppo
- Il tipo è un set o una sequenza di valori: ci sono, allora, i metodi addAttrName(attrType a)
per inserire un nuovo valore, clearAllAttrName() per rimuovere tutti i valori. Per la lettura
è possibile acquisire un Iterator mediante getAllAttrName(), attraverso il quale il
programmatore può scorrere la List effettuando il casting opportuno.
Figura 2-13 Modello di riferimento per i Content
50

2.7. Android
Ambiente di sviluppo
La rapida diffusione del sistema operativo Android, e il crescente interesse verso tale
tecnologia open-source, ha favorito lo sviluppo di un numero sempre maggiore di
applicazioni che implementano ed estendono le funzionalità di base di questo sistema.
Inoltre, l’elevato numero di funzionalità proprie dei dispositivi embedded Android, quali
smartphone e tablet, forniscono agli sviluppatori una piattaforma hardware molto
conveniente per l’implementazione e il test di nuove idee e soluzioni. Nel sistema di
videosorveglianza discusso in questa tesi, le telecamere che vogliono partecipare alla
videosorveglianza sono smartphone Android dotati di un agente in grado di comunicare con
l’agente manager gestore delle telecamere.
Android è un sistema operativo basato sul kernel Linux 2.6, appositamente realizzato per
dispositivi portatili ([4]). L’architettura è suddivisa in 5 componenti, come mostrato in Fig.
2.14; al di sopra del kernel Linux ci sono le librerie C/C++ utilizzabili dalle applicazioni; ad un
livello superiore si trova l’Application Framework, che fornisce le API e i servizi che possono
essere utilizzati dalle applicazioni (chiamate anche App); queste ultime si trovano in cima
all’architettura, nel livello Application e sono sviluppate usando il linguaggio di
programmazione Java.
51

Ambiente di sviluppo
Figura 2-14 Architettura Android
Il componente chiave del framework Android è l’Android Runtime, che contiene le librerie di
sistema e la Virtual Machine Dalvik, una macchina virtuale appositamente progettata e
ottimizzata da Google secondo le caratteristiche hardware dei dispositivi mobile.
La Virtual Machine Dalvik usa un proprio formato di byte-code (Dalvik executable, .dex),
verso il quale viene convertito il byte-code Java dopo la compilazione, grazie ad un apposito
tool. Una delle caratteristiche principali del formato .dex è quella di eliminare le informazioni
ridondanti nei file di classe del Java, riducendo così le dimensioni finali del byte-code; la VM
Dalvik può avere istanze multiple eseguite in uno stesso dispositivo, ed ognuna viene
eseguita in un processo separato di Linux; ogni applicazione Android viene eseguita in una
istanza della VM Dalvik.
Lo sviluppo delle applicazioni Android avviene utilizzando l’IDE Eclipse per Java ([9]), con
installato il plugin Android Develoment Tools (ADT) ([11]); in aggiunta, è necessario il
pacchetto Android SDK che contiene i vari strumenti di sviluppo e le librerie per le differenti
52

Ambiente di sviluppo
versioni di Android, necessari per compilare l’applicazione realizzata nel formato .apk
(Android Package file). L’Android ADT include anche un emulatore che può essere utilizzato
per testare sul PC l’applicazione sviluppata, mediante un dispositivo virtuale
opportunamente configurato per replicare alcune delle caratteristiche del dispositivo fisico
dove verrà eseguita l’applicazione. Tuttavia esistono delle limitazioni di questo strumento, ad
esempio non è possibile emulare la videocamera.
La configurazione tipica per lo sviluppo di applicazioni Android prevede la pre- senza del
dispositivo hardware fisicamente collegato via USB al PC di sviluppo, e attraverso un apposito
strumento di debug incluso nell’ADT, il Dalvik Debug Monitor Server (DDMS) si seguono le
opzioni di debug, utilizzando dei punti di controllo inseriti nel codice dell’applicazione tramite
apposite istruzioni.
2.7.1. Basi della programmazione Android
Android richiede che i progetti siano organizzati in una certa maniera. La corretta gestione
delle risorse in questa piattaforma, è importante tanto quanto la stesura del codice. Creando
un nuovo progetto Android, Eclipse ha predisposto un albero di cartelle, all’interno del quale
sono stati generati automaticamente diversi file. Tra i file generati automaticamente c’è
AndroidManifest.xml e il file default.properties. Ci sono poi delle directory: src, assets, res e
gen di cui la prima, src, è quella dove dobbiamo andare a realizzare i package e le classi della
nostra applicazione. Le cartelle res e assets servono per ospitare le risorse esterne necessarie
all’applicazione, come le immagini, i file audio e altro ancora ([5]) ([14]).
53

Ambiente di sviluppo
Figura 2-15 Struttura applicazione Android
Il file AndroidManifest.xml è un descrittore dell’applicazione. Al suo interno potete e dovete
dichiarare i componenti del vostro software.
Figura 2-16 Lettura file Manifest da Eclipse
54

Ambiente di sviluppo
Oltre a src, assets e res c’è infine la cartella gen, che contiene la speciale classe chiamata R,
probabile abbreviazione di Resources. Invocando questa classe, infatti, è possibile richiamare
via codice le risorse memorizzate sotto la directory res. il file strings.xml, pensato per
raccogliere le stringhe usate dall’applicazione che sarà sviluppata.
All’interno del tag ... è possibile dichiarare differenti tipi di valori.
Ci sono numerosi tipi di dati supportati. Ecco un elenco completo:
• Stringhe, con il tag .
• Colori, con il tag
• Misure e dimensioni, con il tag
• Stili e temi, con il tag
• Rettangoli di colore, con il tag
• Array di interi, con il tag
• Array di stringhe, con il tag
Le applicazioni Android si compongono di quattro mattoni fondamentali: le attività (activity),
i servizi (service), i broadcast receiver e i content provider. Ogni applicazione è formata da
uno o più di questi mattoni. Non è detto che li contenga tutti: ad esempio potrebbe essere
costituita da due attività e da un servizio, senza avere broadcast receiver né content
provider. Nella stragrande maggioranza dei casi, comunque, le applicazioni comprendono
almeno un’attività. Le attività, di conseguenza, sono il più fondamentale dei componenti di
base delle applicazioni Android.
• Attività: Le attività sono quei blocchi di un’applicazione che interagiscono con l’utente
utilizzando lo schermo e i dispositivi di input messi a disposizione dallo smartphone.
Comunemente fanno uso di componenti UI già pronti, come quelli presenti nel pacchetto
android.widget, ma questa non è necessariamente la regola. Le attività sono probabilmente il
modello più diffuso in Android, e si realizzano estendendo la classe base android.app.Activity.
55

Ambiente di sviluppo
• Servizio: Un servizio gira in sottofondo e non interagisce direttamente con l’utente. Ad
esempio può riprodurre un brano MP3, mentre l’utente utilizza delle attività per fare altro.
Un servizio si realizza estendendo la classe android.app.Service.
• Broadcast Receiver: Un Broadcast Receiver viene utilizzato quando si intende
intercettare un particolare evento, attraverso tutto il sistema. Ad esempio lo si può utilizzare
se si desidera compiere un’azione quando si scatta una foto o quando parte la segnalazione
di batteria scarica. La classe da estendere è android. content.BroadcastReceiver.
• Content Provider: I Content Provider sono utilizzati per esporre dati e informazioni.
Costituiscono un canale di comunicazione tra le differenti applicazioni installate nel sistema.
Si può creare un Content Provider estendendo la classe astratta
android.content.ContentProvider.
È possibile mandare in esecuzione più attività simultaneamente, ma soltanto un’attività alla
volta può occupare il display. L’attività che occupa il display è in esecuzione e interagisce
direttamente con l’utente. Le altre, invece, sono ibernate e tenute nascoste in sottofondo, in
modo da ridurre al minimo il consumo delle risorse di calcolo. L’utente, naturalmente, può
ripristinare un’attività ibernata e riprenderla da dove l’aveva interrotta, riportandola in primo
piano. I casi in cui un’attività può terminare sono due:
• L’attività è ibernata e il sistema, arbitrariamente, decide che non è più utile e perciò la
distrugge.
• Il sistema è a corto di memoria, e per recuperare spazio inizia a “uccidere” bruscamente le
attività in sottofondo.
56

Ambiente di sviluppo
Figura 2-17 Ciclo di vita di una attività
La Fig.2.17 illustra la sequenza di chiamate ai metodi di Activity eseguite durante i passaggi di
stato dell’attività. Nel dettaglio:
• protected void onCreate() Richiamato non appena l’attività viene creata. L’argomento
savedInstanceState serve per riportare un eventuale stato dell’attività salvato in precedenza
da un’altra istanza che è stata terminata. L’argomento è null nel caso in cui l’attività non
abbia uno stato salvato.
57

Ambiente di sviluppo
• protected void onRestart() Richiamato per segnalare che l’attività sta venendo riavviata
dopo essere stata precedentemente arrestata.
• protected void onStart() Richiamato per segnalare che l’attività sta per diventare visibile
sullo schermo.
• protectedvoidonResume() Richiamato per segnalare che l’attività sta per iniziare
l’interazione con l’utente.
• protected void onPause() Richiamato per segnalare che l’attività non sta più interagendo
con l’utente.
• protected void onStop() Richiamato per segnalare che l’attività non è più visibile sullo
schermo.
• protectedvoidonDestroy() Richiamato per segnalare che l’applicazione sta per essere
terminata.
Dopo che si è creata un’attività, la si deve registrare all’interno del descrittore
dell’applicazione (il file AndroidManifest.xml), questo affinché il sistema sappia della sua
esistenza. Per farlo si usa un tag all’interno del tag . Con l’attributo
android:name si specifica il nome della classe registrata come attività. Si può esprimere sia il
suo percorso completo (ad esempio mypackage.mysubpackage.MyActivity) sia il nome
relativo rispetto al package dichiarato nel tag sovrastante (ad esempio
.MyActivity). All’interno della coppia di tag ... , invece, possono essere
allacciate delle relazioni particolari fra l’attività e l’applicazione e fra l’attività ed il sistema.
Come spiegato in apertura, un’applicazione Android può contenere più di un’attività. In
questo caso una soltanto sarà marcata come attività principale di lancio. Le altre saranno,
invece, delle sotto-attività, che l’attività principale potrà
lanciare quando ce n’è bisogno. Realizzare una sotto-attività è semplice tanto quanto
realizzare l’attività principale: ancora una volta è sufficiente estendere android.app.Activity.
Le attività secondarie vanno poi registrate nel file AndroidManifest.xml, senza però applicare
l’intent-filter con l’azione e la categoria usate invece dall’attività principale. L’attività
principale può lanciare delle sotto-attività ricorrendo al metodo startActivity(). Questo
accetta come argomento un oggetto di tipo android.content.Intenet che, come è facile
58

Ambiente di sviluppo
intuire, rappresenta un intent. Con questo intento bisogna esprimere quale sotto-attività
deve essere avviata.
Per quanto riguarda l’interfaccia grafica i primi due concetti che dobbiamo assorbire si
chiamano View e ViewGroup, e corrispondono alla maniera di Android di classificare ed
organizzare ciò che è sullo schermo. I bottoni, i campi di testo, le icone e tutti gli altri
congegni di un’interfaccia grafica sono oggetti View. I ViewGroup, invece, sono dei
contenitori che possono mettere insieme più oggetti View. I ViewGroup, inoltre, sono a loro
volta degli oggetti View, e di conseguenza possono contenere altri ViewGroup. Grazie a
questa intuizione è possibile organizzare i componenti sullo schermo secondo uno schema ad
albero, come quello di Fig.2.18.
Figura 2-18 Componenti schermo Android
I componenti View estendono tutti la classe base android.view.View. Nella libreria standard
di Android ci sono già molti componenti di questo tipo, soprattutto nel pacchetto
android.widget.
Una volta che, combinando oggetti View e ViewGroup, si è ottenuta l’interfaccia utente che
si desidera, è necessario che questa venga mostrata sullo schermo. Le attività (cioè gli oggetti
android.app.Activity) mettono a disposizione un metodo setContentView(), disponibile nelle
seguenti forme:
• public void setContentView(View view): Mostra sullo schermo l’oggetto View specificato.
• public void setContentView(View view, ViewGroup.LayoutParams params):
59

Ambiente di sviluppo
Mostra sullo schermo l’oggetto View specificato, applicando una serie di parametri di
visualizzazione ed organizzazione del componente (params).
2.8. JADE-LEAP
Nel progetto di videosorveglianza discusso nella presente tesi, è stato necessario utilizzare un
particolare add-on del framework JADE per lo sviluppo dell’agente residente nello
smartphone Android. Nei seguenti paragrafi verrà spiegato il pacchetto Jade-Leap.
2.8.1. Jade-Leap runtime environment
Come conseguenza all'introduzione di dispositivi sempre collegati a reti wireless (GPRS,
UMTS, WLAN) e della continua crescita del potere e delle risorse di dispositivi portatili quali
PDA e telefoni cellulari, il wireless e wire-line si stanno progressivamente integrando insieme.
In questo scenario il bisogno di applicazioni distribuite in parte nella rete fissa e in parte su
dispositivi portatili sta diventando sempre più importante ([2]). JADE, purtroppo, non può
essere eseguito, come è, su piccoli dispositivi per le seguenti ragioni:
1. L'ambiente di runtime di JADE completa ha un ingombro di memoria di qualche Mbyte che
non possono rientrare nelle limitazioni dei dispositivi portatili.
2. JADE richiede Java 5 (o versione successiva), mentre la maggior parte dei dispositivi
portatili possono solo sostenere CDC, PersonalJava, o più tipicamente MIDP.
3. Collegamenti wireless hanno caratteristiche diverse rispetto a rete fissa, come alta latenza,
larghezza di banda bassa, connettività intermittente e l'assegnazione dinamica dell'indirizzo
IP che deve essere preso in considerazione correttamente.
Il LEAP add-on è stato creato per risolvere questi problemi e permette la distribuzione di
agenti JADE su dispositivi palmari ([6]).
60

Ambiente di sviluppo
Il LEAP add-on, quando combinato con JADE, sostituisce alcune parti del kernel JADE
formando un ambiente di runtime modificato che noi identifichiamo come JADE-LEAP e che
può essere distribuito su una vasta gamma di piccoli dispositivi. Al fine di raggiungere questo
obiettivo, JADE-LEAP può essere configurato in diversi modi corrispondenti alle due
configurazioni (CDC e CLDC) del Java Micro Edition e Android Dalvik Java Virtual Machine. Più
in dettaglio
pjava: per eseguire JADE-LEAP su dispositivi palmari che supportano J2ME CDC o
PersonalJava come la maggior parte dei PDA oggi. Si noti che nel 2003 la specifica
Personal Java è stata dichiarata obsoleta ed è stato sostituita dalla configurazione
CDC dell'edizione J2ME. Dal punto di vista dell’ esecuzione con JADE-LEAP tuttavia
non esistono differenze. Quindi con il termine "PersonalJava" si intende sia l'attuale
obsoleta specifica Personal Java e J2ME configurazione CDC.
MIDP: per eseguire JADE-LEAP su dispositivi palmari che supportano MIDP1.0 (o
successiva), come la maggior parte dei telefoni cellulari abilitati Java.
android: per eseguire JADE-LEAP su dispositivi che supportano Android 2.1 (o versioni
successive).
Inoltre, una versione dotnet di JADE-LEAP esiste per eseguire JADE-LEAP su PC e server della
rete fissa che esegue Microsoft. NET Framework versione 1.1 o successiva. Però diversa
internamente, le tre versioni di JADE-LEAP forniscono lo stesso insieme di API per
sviluppatori offrendo così uno strato omogeneo su una varietà di dispositivi e tipi di rete
come illustrato in Figura 2.19.
61

Ambiente di sviluppo
Figura 2-19 Architettura JADE Leap
2.8.2. Split execution
L'ambiente di runtime di JADE può essere eseguito in due modi diversi. La normale modalità
"stand-alone" in cui viene eseguito un container completo sul dispositivo / host in cui si attiva
il runtime JADE. La modalità "Split" in cui il container viene diviso in un FrontEnd
(effettivamente in esecuzione sul dispositivo / host in cui il runtime JADE è attivato) e un
back-end (in esecuzione su un server remoto), collegati tra loro per mezzo di una
connessione permanente. La seguente tabella riassume come le 2 modalità di esecuzione
sono supportate nei diversi ambienti destinatari JADE-LEAP.
Tabella 2-4 Modalità esecuzione nei vari ambienti
62

Ambiente di sviluppo
Si noti che la modalità di esecuzione split è obbligatoria in MIDP e fortemente suggerito
pjava. La modalità di esecuzione split è particolarmente adatto per dispositivi con risorse
limitate e wireless dato che è decisamente più leggero di un container completo.
- La fase di bootstrap è molto più veloce in quanto tutte le comunicazioni con il Main
container sono eseguite dal back-end e quindi non vengono effettuate tramite il
collegamento wireless.
- L'uso del collegamento wireless è ottimizzato.
E' importante sottolineare che gli sviluppatori degli agenti, in genere, non hanno bisogno di
prendersi cura in alcun modo per il fatto che l’agente sia eseguito su un stand-alone
container o sul FrontEnd di un container diviso.
Figura 2-20 Stand alone e Split execution mode
63

Ambiente di sviluppo
I seguenti problemi devono essere presi in considerazione:
- Quando si lancia uno split container, un container JADE (eventualmente, ma non
necessariamente il Main container) deve già essere attivo sull'host su cui il backend deve
essere creato. In seguito si farà riferimento a questo container come Mediatore.
- Un Main container non può essere diviso.
- Mobilità Agente e clonazione non è supportato su uno split container.
2.9. JADE-based Android application
In linea con l'architettura di Android, il runtime JADE è avvolto da un Android service. Più
specificamente, la libreria jadeAndroid.jar comprende due classi
jade.android.RuntimeService e jade.android.MicroRuntimeService che avvolge un full
container e uno split container, rispettivamente. Il MicroRuntimeService è dichiarato nel
manifest Android come di seguito.
...
La prima operazione per attivare il runtime JADE da un'attività Android è di associarsi al
MicroRuntimeService. ([7]) Come risultato un oggetto
jade.android.MicroRuntimeServiceBinder viene recuperato in modo tale che sia possibile
effettuare tutte le operazioni di gestione di JADE. Il codice qui sotto mostra come fare.
serviceConnection = new ServiceConnection() { public void
onServiceConnected(ComponentName className, IBinder service) {
};
// Bind successful
microRuntimeServiceBinder = (MicroRuntimeServiceBinder) service; ...
public void onServiceDisconnected(ComponentName className) { // Bind
unsuccessful
microRuntimeServiceBinder = null;
}
64

Ambiente di sviluppo
bindService(new Intent(getApplicationContext(), MicroRuntimeService.class),
serviceConnection,
Context.BIND_AUTO_CREATE);
Dopo aver recuperato l'oggetto MicroRuntimeServiceBinder è ora possibile avviare un
container JADE split, come illustrato nel codice sotto:
Properties pp = new Properties(); pp.setProperty(Profile.MAIN_HOST, host);
pp.setProperty(Profile.MAIN_PORT, port); pp.setProperty(Profile.JVM,
Profile.ANDROID); ... microRuntimeServiceBinder.startAgentContainer(pp,
new RuntimeCallback() { @Override
public void onSuccess(Void thisIsNull) { // Split container startup
successful
...
}
@Override
public void onFailure(Throwable throwable) {
// Split container startup error
}
} );
Come al solito l'host e la porta in cui il container principale è in funzione (così come altre
opzioni di configurazione) deve essere specificato in un oggetto Properties.
Secondo la filosofia di Android tutte le operazioni sono asincrone e il risultato è reso
disponibile per mezzo di un oggetto jade.android.RuntimeCallback. Una volta che il runtime
JADE è installato e funzionante, è possibile avviare l'agente su di esso, come illustrato nel
frammento di codice qui sotto:
microRuntimeServiceBinder.startAgent(nickname,
ChatClientAgent.class.getName(), new Object[] { getApplicationContext() },
new RuntimeCallback() {
@Override
public void onSuccess(Void thisIsNull) { // Agent successfully started ...
}
@Override
public void onFailure(Throwable throwable) { // Agent startup error
...
}} );
Il modo più pulito per implementare le interazioni tra i componenti GUI (soprattutto Attività
Android) e l'agente è quello di sfruttare l'object-to-Agent (O2A in breve), un meccanismo di
65

Ambiente di sviluppo
interfaccia introdotta nella versione 4.1.1 di JADE. Ciò consente a un agente di esporre una o
più interfacce che possono essere recuperate da componenti esterni. I componenti esterni
possono innescare i compiti dell’agente invocando i metodi di queste interfacce e quindi
recuperare informazioni dall’agente e così via a seconda delle esigenze dell'applicazione.
Esempio:
public interface ChatClientInterface {
public void handleSpoken(String s);
public String[] getParticipantNames();
}
Nell’esempio i metodi citati dovranno essere implementati dall’agente.
La riga seguente, mostra come l'agente espone l'interfaccia O2A sopra descritta.
registerO2AInterface(ChatClientInterface.class, this);
Quando si lavora con JADE, è spesso il caso che un agente deve mostrare alcune informazioni
in modo proattivo nella GUI. Il metodo suggerito per attuare questo tipo di interazione è
quello di sfruttare il meccanismo che Android offre per consentire diversi componenti di
interagire. Questo si basa sulla trasmissione di Intent che possono essere ricevuti dai
componenti interessati. Il frammento di codice seguente mostra come un agente crea e
trasmette l'intento di comunicare ad una interfaccia grafica.
Intent broadcast = new Intent();
broadcast.setAction("jade.demo.chat.REFRESH_CHAT");
broadcast.putExtra("sentence", speaker + ": " + sentence + "\n");
logger.info("Sending broadcast " + broadcast.getAction());
context.sendBroadcast(broadcast);
I frammenti di codice riportati di seguito mostrano come una activity si registra un ricevitore
per intercettare Intenti:
myReceiver = new (); IntentFilter refreshChatFilter = new IntentFilter();
refreshChatFilter.addAction("jade.demo.chat.REFRESH_CHAT");
registerReceiver(myReceiver, refreshChatFilter);
...
private class extends BroadcastReceiver {
MyReceiver
@Override
public void onReceive(Context context, Intent intent) {
String action = intent.getAction();
if (action.equalsIgnoreCase("jade.demo.chat.REFRESH_CHAT")) {
66

Ambiente di sviluppo
TextView chatField = (TextView) findViewById(R.id.chatTextView);
chatField.append(intent.getExtras().getString("sentence")); scrollDown();
}
}
}
2.10. Integrazione di JADE e Android in Eclipse
Per l’implementazione degli applicativi ad agenti è stato usato Eclipse Indigo ([9]),i seguenti
passi mostrano come integrare Jade in Eclipse.
- Scompattare l'archivio contenente i binari di Jade ([8])
- Aprire Eclipse e creare un nuovo Progetto Java:
- Inserire un nome e proseguire.
- Alla scermata successiva aprire la finestra Libraries e cliccare su Add External JARs:
67

Ambiente di sviluppo
- Selezionate dall'explorer l'archivio delle classi Jade (jade.jar), localizzato in “Jade-Dir”/lib/.
Ripetere l'operazione per il file commons-codec-1.3.jar ubicato in “Jade-
Dir”/lib/commons-codec/.
- Finish per creare il progetto.
- Creare un package per contenere le classi che definiscono gli agenti (il
dà problemi con Jade, meglio rimuoverlo)
- Cliccare con il tasto destro sulla cartella del progetto ed aprire la finestra Run
Configurations:
68

Ambiente di sviluppo
- Creare una nuova configurazione per una Java Application.
- Assegnare un nome alla configurazione, legare questa al progetto appena creato ed
inserire Jade.Boot come main class. ([10])
L’SDK Android su Eclipse:
Il prerequisito per l’installazione dell’Android SDK su Eclipse è l’avere sul proprio PC il JDK
(Java Developer Kit). Successivamente si passa all’installazione dell’Android SDK tramite
l’installer che però non contiene l’ambiente di sviluppo completo ma solo il nucleo dei tools
utili a scaricare il resto del package dell’SDK. ([11]) Nel momento in cui si installa il software è
utile prendere nota della directory di installazione che verrà richiesta durante l’installazione
dell’ADT, il plugin per Eclipse.
Figura 2-21 Android SDK manager
Una volta ottenuti tali file è possibile passare all’installazione dell’ADT per Eclipse che viene
installato tramite il menù Help > Install New Software di Eclipse e digitando nel campo “Work
69

Ambiente di sviluppo
with” l’URL https//dl-ssl.google.com/android/eclipse/. Dare invio dopo aver selezionato tutti
i plugin che compariranno nel repository.
La fase successiva è la configurazione dell’ADT tramite il menù Windows > Preferences e
selezionando Android dal pannello a sinistra. Inserire la locazione nel file system dell’Android
SDK precedentemente installato attraverso il tasto Browse e successivamente confermare le
modifiche
70

3. Progettazione del sistema
Il sistema di videosorveglianza da realizzare prevede la creazione di due applicativi ad agenti,
un applicativo “centrale” di gestione dei dispositivi mobili e un applicativo per ogni
dispositivo. In questo capitolo, per prima cosa vengono riportate delle informazioni
riguardanti l’applicativo Android per l’inseguimento dei volti fornitomi dal Dipartimento di
Ingegneria dell’Informazione da agentificare, in modo da rendere comprensibili le successive
scelte di progettazione. Viene poi riportata l’analisi dei requisiti, l’architettura del software
ad agenti e la comunicazione realizzata fra gli applicativi sviluppati.
3.1. Software di partenza
L’applicazione che mi è stata fornita per l’individuazione e inseguimento dei volti su
smartphone Android è stata sviluppata da Simone Saraceni ([12]) ed è composta
principalmente dai seguenti componenti: la classe FdActivity, che estende una Activity
Android, rappresenta il punto di accesso all’applicazione e dove vengono inizializzati i vari
componenti; la classe CvBaseView che si occupa della visualizzazione dell’interfaccia grafica;
ER1Direction che determina il comando di movimento che deve eseguire il robot collegato
allo smartphone; FpsMeter è una classe di utilità che calcola i FPS (frame per secondo);
FdView è la classe che contiene la logica del sistema di visione per l’individuazione e
selezione dei volti. La parte direttamente interessata dal mio lavoro di tesi riguarda la logica
del sistema di visione per l’individuazione e selezione dei volti contenuta prevalentemente in
FdView e CvBaseView, riporto quindi di seguito un riassunto del loro funzionamento:
L’applicazione individua i volti presenti in un flusso video ricevuto in ingresso:
analizzandolo individua la posizione di tutti i volti presenti nel frame corrente.
71

Progettazione del sistema
Il sistema sceglie un volto dominante, tra quelli individuati.
Una funzione riceve in ingresso l’elenco dei volti individuati nella scena e tra questi
ne sceglie opportunamente uno, secondo il criterio del tempo di permanenza
nell’inquadratura.
Utilizzando come ingresso la posizione del volto dominante nella scena, il sistema
determina la direzione di movimento del robot al fine di mantenere il volto
dominante al centro della scena.
Il sistema elabora l’immagine del volto dominante, utilizzata come input, e restituisce
un valore di tipo booleano. Tale elaborazione verrà eseguita da un software di terze
parti, che restituisce il valore vero se il soggetto è stato riconosciuto in un database di
soggetti noti, altrimenti restituisce il valore falso.
Utilizzando l’output generato dalla funzione di elaborazione del volto dominante, il
sistema opportunamente modifica il proprio comportamento. Qualora venga ricevuto
il valore booleano vero, il sistema deve continuare a seguire il volto dominante,
altrimenti inizia a seguire un altro soggetto, se presente nella scena. Se non viene
ricevuto alcun risultato dell’elaborazione, il robot continuerà a seguire il volto
dominante finché questo non esce dalla scena.
In particolare di seguito è riportato il codice riguardante il metodo run() della classe
CvBaseView:
public void run() {
Bitmap bmp=null;
Canvas canvas=null;
Log.i(TAG, "Starting processing thread run t="+System.currentTimeMillis());
//initialize FPS and ER1 image
mFps.init();
mER1.init(mFrameWidth,mFrameHeight);
while (true) {
bmp = null;
synchronized (this) {
if (mCamera == null)
break;
if (!mCamera.grab()) {
Log.e(TAG, "mCamera.grab() failed");
break;
}
//elaborate video, calculate FPS and ER1 direction
72

}
Progettazione del sistema
Log.i(TAG, "Starting processFrame t="+System.currentTimeMillis());
bmp = processFrame(mCamera);
mFps.measure();
//mER1.calc(getResults());
}
//draws elaborated images to surface holder
if (bmp != null) {
canvas = mHolder.lockCanvas();
if (canvas != null) {
appW=(canvas.getWidth() - bmp.getWidth()) / 2.0f;
appH=(canvas.getHeight() - bmp.getHeight()) / 2.0f;
canvas.drawBitmap(bmp, appW, appH, null);
mFps.draw(canvas, appW, 0);
mER1.calc(getResults(),appW,appH);
mER1.draw(canvas, appW, appH);
mHolder.unlockCanvasAndPost(canvas);
}
bmp.recycle();
}
}
Log.i(TAG, "Finishing processing thread");
Listato 3-1 Metodo run() di CvBaseView
Dal frammento riportato è possibile notare che tramite il ciclo while(true) sia ripetutamente
chiamato il metodo processFrame che elabora il video e restituisce una immagine bmp, di
seguito è riportato il codice relativo al metodo processFrame implementato dalla classe
FdView:
protected Bitmap processFrame(VideoCapture capture) {
capture.retrieve(mRgba, Highgui.CV_CAP_ANDROID_COLOR_FRAME_RGBA);
capture.retrieve(mGray, Highgui.CV_CAP_ANDROID_GREY_FRAME);
if (mCascade != null) {
//clear previous detected faces array
faces.clear();
//equalize gray image histogram
Imgproc.equalizeHist(mGray, mGray);
//invoke face detection algorithm, from a start face dimension of 90x90
mCascade.detectMultiScale(mGray, faces, 1.3, 3, 0, DEFSIZE);
//search each face on history face detected array
for (Rect r : faces){
add=true;
for (CFace a : hFaces){
if (a.updatePos(r)) {
add=false;
break;
}
}
if (add) hFaces.add(new CFace(r)); //face not found into history array, new face
if (develop) Core.rectangle(mRgba, r.tl(), r.br(), new Scalar(0, 0, 0, 127), 1); //print a green
rectangle around each face
}
73

Progettazione del sistema
//initialize array variables
newFace=null;
maxT=0;
hcopy.clear();
//for each faces into history faces array, removes old face (not yet detected) and search
dominant face (most time present)
for (CFace a:hFaces){
if (a.aging()){
hcopy.add(a);
} else if (a.findBest()) {
newFace=a;
}
}
hFaces.removeAll(hcopy);
//if a face was detected
if (newFace!=null){
if (develop) Core.rectangle(mRgba, newFace.pos.tl(), newFace.pos.br(), new
Scalar(255,0,0,255),2); //draws a red rectangle around face
//draw a blue line next to the left angle of the dominant face to visualize the set point on Z
(=140 px)
CFace temp = new CFace(newFace.pos);
Point bo=temp.pos.tl();
bo.y+=130;
if (develop) Core.line(mRgba, newFace.pos.tl(),bo, new Scalar(0,0,255,255), 4); //draws a red
rectangle around face
if (dominantFace==null || newFace.id!=dominantFace.id || repeat>REPEAT_LIMIT){
//send face to server when first one detected or new face or need to re-send
dominantFace=newFace;
repeat=0;
try{
//interrupt server response wait thread
waitResp=false;
//create bitmap image to send
dominant=Bitmap.createBitmap(mRgba.cols(),mRgba.rows(),Bitmap.Config.ARGB_8888);
Utils.matToBitmap(mRgba, dominant);
dominant=Bitmap.createBitmap(dominant, newFace.pos.x, newFace.pos.y,
newFace.pos.width, newFace.pos.height);
//if (count++>120) count=0;
//dominantFace.id=count; //update face ID
faceCheck="";
sendImg=true;
//Log.i(TAG, "BMP ok");
}catch (Exception e) {Log.e(TAG,"bitmap error "+e.toString());}
Log.i(TAG, "new Face ");
}else if (newFace.id==dominantFace.id && repeat

Progettazione del sistema
}
}
if (develop){
//create image to send back to caller
bmp = Bitmap.createBitmap(mRgba.cols(), mRgba.rows(), Bitmap.Config.ARGB_8888);
if (Utils.matToBitmap(mRgba, bmp))
return bmp;
bmp.recycle();
}
return null;
}
Listato 3-2 Metodo processFrame() di FdView
Il metodo processFrame si occupa di individuare i volti, selezionare il volto dominante e
preparare l’immagine da inviare al PC. Il video catturato viene elaborato equalizzandone
l’istogramma, quindi viene eseguito l’algoritmo di individuazione dei volti. La scansione
ricerca i volti con una dimensione minima di 90x90 pixel, ad ogni iterazione la dimensione
viene incrementata di un fattore 1,3 ([12]). La variabile faces contiene la lista delle posizioni
di tutti i volti individuati nel frame corrente; il passo successivo è quello di cercare ogni volto
individuato nei frame precedenti, aggiornandone le informazioni per mezzo del metodo
updatePos; il vettore hFaces contiene le informazioni relative ai volti individuati nel frame
attuale e in quelli precedenti. Il tipo di dati CFace è stato creato per memorizzare le
informazioni relative ai volti individuati, ovvero la posizione e il tempo di permanenza sulla
scena. Ogni volta che viene individuato un volto dominante diverso dal precedente, oppure è
trascorso un certo intervallo di tempo dall’ultimo invio al PC, viene creata l’immagine bitmap
del volto dominante, pronta per essere trasferita al PC. L’operazione di ricerca del volto
dominante si basa sul tempo di permanenza nella scena; ogni volto individuato viene
ricercato nello storico: se la posizione attuale del vertice superiore sinistro è in un intorno
della posizione precedente, i due volti confrontati sono marcati come identici. E’ presente
una funzione updatePos della classe CFace che si occupa di confrontare le posizioni dei due
volti, restituendo il valore false se non sono compatibili, altri- menti provvede ad aggiornare
la posizione corrente e il tempo di permanenza. La variabile noFace viene utilizzata per
eliminare, con il metodo aging, i volti non più presenti nella scena per un certo numero di
frame consecutivi. Nella selezione del volto dominante, con il metodo findBest si cerca il
volto con il valore massimo della variabile time.
75

Progettazione del sistema
L’applicativo Android per sapere se il volto selezionato sia conosciuto o no, comunica con un
altro applicativo realizzato a tale scopo, tramite WiFi. Il modulo responsabile della
comunicazione WiFi con il PC avente l’applicativo di riconoscimento del volto è implementato
attraverso l’utilizzo di tre thread contenuti in FdView. Il thread CommThread viene creato
all’avvio dell’applicazione, si occupa di iniziare la comunicazione con il PC e di avviare altri
due thread: uno per l’invio delle immagini e l’altro per la ricezione delle risposte.
Il SendThread per l’invio dell’immagine al PC, controlla periodicamente lo stato della variabile
sendImg, quando questa assume il valore vero, l’immagine del volto dominante viene inviata
al PC; impostando il flag waitResp al valore true, l’applicazione si mette in ascolto della
risposta.
Il RecvThread, deve elaborare la risposta inviata dal PC, il messaggio ricevuto è composto da
un solo byte, che può assumere il valore 1 nel caso in cui il volto precedentemente inviato è
stato riconosciuto, 0 altrimenti. L’utilizzo dei thread consente di gestire in modo
indipendente la comunicazione con il PC. ([12])
Per agentificare tale applicativo e ottenere un sistema di videosorveglianza ad agenti è quindi
necessario sostituire a la comunicazione esistente fra l’applicativo Andoid e l’applicativo di
riconoscimento del volto con una comunicazione fra agenti.
76

Progettazione del sistema
3.2. Analisi dei requisiti
Vi sono due diversi tipi di requisiti sul sistema, quelli funzionali e i requisiti aggiuntivi o non
funzionali, che forniscono vincoli addizionali, permettendo un ulteriore sviluppo del progetto
nel tempo.
I requisiti sono schematizzati qui di seguito.
Requisiti funzionali:
Elaborazione immagine del volto
Il sistema deve essere in grado di elaborare l’immagine del volto dominante, utilizzata
come input, e restituire un valore di tipo booleano. Tale elaborazione verrà eseguita
da un software di terze parti, che restituisce all’agente richiedente il valore vero se il
soggetto è stato riconosciuto in un database di soggetti noti, altrimenti restituisce il
valore falso.
Gestione output elaborazione del volto
Utilizzando l’output generato dalla funzione di elaborazione del volto dominante, il
sistema deve opportunamente modificare il proprio comportamento. Qualora venga
ricevuto dall’agente Android il valore booleano vero, il sistema deve continuare a
seguire il volto dominante, altrimenti inizia a seguire un altro soggetto, se presente
nella scena.
Definizione di una ontologia
Definizione di una ontologia per lo scambio dei messaggi fra agenti in uno scenario di
videosorveglianza, per esempio per richieste e risposte:" identifica questo
soggetto...", "il soggetto identificato è...",...
Gestione dispositivi mobili
Il sistema deve conoscere e tenersi aggiornato sugli attuali dispositivi mobili
partecipanti alla videosorveglianza e funzionanti correttamente.
77

Requisiti non funzionali:
Uso del framework Jade
Progettazione del sistema
Il sistema di videosorveglianza deve basarsi su tecnlogia ad agenti, in particolare
utilizzando il framework Jade ed il suo add-on Jade-Leap per lo sviluppo di agenti su
dispositivi mobili.
Il sistema deve essere tollerante ai guasti
Il sistema di videosorveglianza deve resistere ad un guasto della macchina avente la
piattaforma ad agenti che offre il servizio di videosorveglianza, gli agenti presenti nei
dispositivi mobili dovranno ripristinare il servizio utilizzando una piattaforma di
videosorveglianza di recovery.
Il sistema deve essere scalabile
Il sistema non deve porre limiti al numero di dispositivi mobili che vogliono
partecipare alla videosorveglianza, tenendo conto che per motivi di potenza di calcolo
disponibile, ad un numero maggiore di telecamere potrebbe essere necessario un
numero maggiore di macchine che offrono il servizio di videosorveglianza attraverso
più piattaforme federate fra loro.
3.3. Architettura del sistema
Il sistema di videosorveglianza ad agenti prevede la presenza di un applicativo centrale in
grado di gestire le richieste di identificazione dei volti provenienti dai dispositivi mobili e di
un applicativo ad agenti presente in ogni dispositivo. L’applicativo centrale di
videosorveglianza ha il compito di lanciare una piattaforma ad agenti Jade, al cui interno sia
presente un agente in grado di comunicare con gli agenti mobili e con l’applicazione per il
riconoscimento dei volti. L’applicativo ad agenti Android crea uno split container nella
piattaforma Jade creata dall’applicativo centrale ed un agente in grado di comunicare con
l’agente manager per fornire il servizio di videosorveglianza. E’ possibile collegare n
dispositivi Android alla piattaforma (stando ai limiti delle potenzialità di calcolo a disposizione
78

Progettazione del sistema
dell’applicativo centrale), come è possibile creare n piattaforme fra di loro federate e
distribuire i dispositivi mobili fra di esse per distribuire il carico. Una piattaforma Jade con il
servizio di videosorveglianza di recovery è presente in caso di distruzione della piattaforma
iniziale, la figura 3-1 mostra l’architettura realizzata:
Figura 3-1 Architettura del sistema di videosorveglianza
79

Progettazione del sistema
La figura 3.2 mostra l’architettura del sistema di videosorveglianza in presenza di una
piattaforma di recovery:
Figura 3-2 Architettura sistema di videosorveglianza con piattaforma recovery
Nel caso la piattaforma principale smetta di funzionare o venga distrutta, l’applicativo
Android ripristina il servizio di videosorveglianza ricreando il suo agente in un’altra
piattaforma di videosorveglianza (cioè con agente manager) disponibile.
80

Progettazione del sistema
3.3.1. Agente Android
L’agente Android è caratterizzato dai seguenti punti:
Recupero di un agente manager
L’agente Android viene creato al caricamento dell’Activity principale lanciata
dall’applicazione di videosorveglianza del dispositivo Android. Per prima cosa l’agente
Android deve conoscere l’AID dell’agente manager con cui comunicare e svolgere il
servizio di videosorveglianza, quindi chiede al DF della piattaforma le informazioni
riguardanti la presenza di un agente che offre il servizio di manager.
Interfaccia agente Android
L’agente Android, per interagire con l’applicazione che elabora il flusso video della
telecamera, offre una interfaccia con cui gestire 3 importanti elementi appartenenti
all’agente Android: l’immagine del volto in byte, una stringa rappresentante
l’identificativo del volto e una variabile booleana che indica l’arrivo di una risposta di
identificazione del volto da parte del manager agent. L’immagine del volto,
l’identificativo del volto e la variabile booleana sono elementi che interagiscono con
la logica di elaborazione video, quindi l’agente offre una interfaccia che consente di:
o Inviare la richiesta di identificazione di una immagine di un volto.
o Ricevere l’immagine del volto che ha attualmente memorizzato l’agente.
o Leggere l’identificativo del volto attualmente memorizzato nell’agente.
o Settare l’identificativo del volto attualmente memorizzato nell’agente.
o Leggere la variabile booleana di arrivo risposta di identificazione.
o Settare la variabile booleana di arrivo risposta di identificazione.
81

Progettazione del sistema
Figura 3-3 Interfaccia agente Android
Registrazione agente Andorid al DF della piattaforma
Per soddisfare il requisito funzionale richiesto al sistema di conoscere i dispositivi
collegati al servizio di videosorveglianza, ogni agente Android che si aggiunge ad una
Jade Platform si registra al DF della piattaforma con il servizio di “telecamera”. Per
realizzare questo, l’agente Android dopo la sua creazione attiva un suo behaviour di
tipo OneShotBehaviour che implementa la registrazione dell’agente Android al DF
della piattaforma.
Subscribe all’agente manager
Per rispondere al requisito di tenere aggiornata la lista dei dispositivi mobili che
partecipano alla videosorveglianza, l’agente Android tramite un secondo behaviuour
di tipo OneShotBehaviour, manda un messaggio ACL di tipo SUBSCRIBE all’agente
manager della piattaforma trovato precedentemente.
82

Progettazione del sistema
Gestione acknowledge da parte dell’agente Android
Per soddisfare il requisito richiesto al sistema di conoscere i dispositivi funzionanti
tramite un periodico acknowledge, l’agente Android implementa un behaviour di tipo
ContractNetResponder, ovvero implementa la parte di responder del protocollo FIPA
Contract-Net, il quale all’arrivo di un messaggio ACL di tipo CallForProposal, risponde
al sender di tale messaggio con un acknowledge, tramite l’ontologia usata dagli
agenti.
Richiesta identificazione volto
Altro behaviour implementato dall’agente Android, è il behaviour dedicato all’invio
della richiesta di identificazione del volto. Questo behaviour è di tipo
AchieveReInitiator, ovvero rispetta la parte di iniziator del protocollo FIPA Request.
Tale behaviour ha il compito di spedire all’agente manager un messagio contenente
l’immagine in byte del volto da identificare (volto che ha attualmente memorizzato
l’agente) e la richiesta di identificazione. All’eventuale arrivo della risposta di
identificazione da parte dell’agente manager, l’agente Android memorizza l’id del
volto che ha ricevuto nel caso il volto sia stato riconosciuto o un id equivalente al
concetto di volto sconosciuto. A questo punto l’agente Android modifica la sua
variabile booleana interna per far sapere alla logica di elaborazione video che è
arrivata una risposta di identificazione.
Il meccanismo di richiedere l’identificazione del volto tramite l’agente e memorizzare la
risposta in variabili dell’agente accessibili tramite la sua interfaccia, permette di
disaccoppiare l’invio di richieste di identificazione di volti effettuate dalla logica di
elaborazione del flusso di camera, dall’attesa della risposta a tali richieste. Questo perchè il
controllo delle risposte alle richieste di identificazione è rimandato ad un apposito Thread, il
quale controlla la variabile booleana di arrivo risposta tramite l’interfaccia dell’agente, e nel
caso sia arrivata una risposta, effettua le opportune operazioni per la logica di elaborazione
video.
83

Progettazione del sistema
La figura seguente mostra le operazioni svolte dall’agente Android:
Figura 3-4 Operazioni agente Andorid
Le operazioni citate precedentemente saranno implementate dalle seguenti classi:
84

Progettazione del sistema
Figura 3-5 Componenti software dell'agente Android
85

Progettazione del sistema
La classe ClientAgent estende la classe Agent implementando l’agente Android. Al suo avvio
si registra all’interfaccia ClientGUIInt e lancia i suoi behaviour:
- DFRegistraTelecamera, estende OneShotbehaviour ed è la classe implementata
per registrare l’agente al DF della piattaforma.
- ParticipantsManager, estende OneShotBehaviour per iscriversi alla lista dei
dispositivi attivi conosciuti dall’agente manager.
- RispondiAck, estende ContractNetResponder per rispondere alle richieste di
acknowledgement dell’agente manager.
Per la gestione degli acknowledge si è scelto il protocollo FIPA Contract-Net perché
l’implementazione gestisce automaticamente l’invio di n messaggi e la ricezione delle
risposte, mentre per richiedere una identificazione del volto si è scelto il protocollo FIPA
Request dato che si ratta della richiesta di un servizio.
3.3.2. Agente Manager
L’agente manager è l’agente che gestisce le richieste di identificazione dei volti da parte dei
dispositivi mobili e che tiene l’informazione relativa agli attuali dispositivi che partecipano
alla videosorveglianza.
L’agente manager è caratterizzato dai seguenti punti:
Conoscenza degli agenti mobili attualmente connessi al servizio di
videosorveglianza
Per avere l’indirizzo (AID degli agenti mobili) dei dispositivi attualmente connessi e
funzionanti sempre aggiornata, l’agente manager attiva il behaviour
SubscriptionResponder, il quale risponde ai messaggi ACL di tipo Subscription
provenienti dagli agenti Android. Inoltre per sapere automaticamente quando un
agente di un dispositivo Android si è scollegato dal servizio di videosorveglianza, il
manager agent implementa SubscriptionManager, il quale prevede l’implementazione
dei metodi register() e deregister() rispettivamente quando un nuovo agente si
86

Progettazione del sistema
aggiunge alla piattaforma o si elimina, questi eventi sono percepiti dal manager agent
grazie all’agente AMS della piattaforma.
Regisrazione al DF della piattaforma
Per soddisfare le richieste da parte degli agenti Android, il manager agent deve prima
registrarsi al DF della piattaforma col servizio di “manager”.
Controllo funzionamento dispositivi mobili
Per soddisfare il requisito di controllo dei dispositivi collegati alla videosorveglianza
tramite acknowledge, l’agente manager lancia un behaviour ControllaAckCyclic che
estende Tickerbehaviour. Tale behaviour ogni 10 secondi crea un behaviour
ControllaAck che estende ContractNetInitiator, il quale manda un messaggio ACL di
tipo CallForProposal a tutti gli agenti che l’agente manager ha in lista connessi e
funzionanti. Attraverso il metodo handleAllResponses() si gestisce automaticamente il
controllo delle risposte ed è sufficiente prendere nota di chi ha confermato l’ack e chi
no per aggiornare la lista degli agenti connessi.
Identificazione dei volti
Per rispondere alle richieste di identificazione dei volti da parte dei dispositivi
Android, il manager agent implementa il behaviour RespondImage che estende la
classe AchieveReResponder, ovvero interpreta la parte del responder del protocollo
FIPA Request. Tale behaviour risponde a messaggi ACL di tipo Request. Per rispondere
alle richieste di identificazione dei volti, l’immagine ricevuta in byte dai messaggi in
arrivo viene memorizzata in una locazione di memoria prestabilita in formato bmp,
dopodiché effettua una richiesta ad una applicazione sviluppata da Gianluca Dolcini
([15]) per il riconoscimento del volto, la quale risponde con un valore booleano di tipo
true se il volto è stato riconosciuto o false in caso contrario. Una volta ottenuto il
risultato, viene spedito il messaggio di risposta al dispositivo mobile richiedente.
Interfaccia agente manager
Anche l’agente manager implementa una interfaccia per permettere ai suoi behaviour
di leggere e scrivere la lista degli agenti mobili.
87

Progettazione del sistema
In figura 3.6 sono riassunte le operazioni svolte dall’agente manager:
Figura 3-6 Operazioni agente manager
Le operazioni citate precedentemente saranno implementate dalle seguenti classi:
88

Progettazione del sistema
Figura 3-7 Componenti software agente manager
89

Progettazione del sistema
La classe ManagerAgent implementa l’agente manager della piattaforma di
videosorveglianza e si registra all’interfaccia ManagerGUIImpl da cui è possibile leggere e
scrivere la lista degli agenti conosciuti dall’agente manager. I behaviour che appartengono
all’agente manager sono:
- DFRegistraManager, per registrare l’agente manager al df della piattaforma.
- ControllaAckCyclic, estende TickerBehaviour per richiedere periodicamente l’ack agli
agenti Android, lanciando periodicamente un behaviour di tipo OneShotBehaviour
chiamato ControllaAck, il quale interpreta la parte di initiator del protocollo Contract-
Net.
- Il behaviour RespondImage per rispondere alle richieste di riconoscimento del volto
estendendo la classe RequestResponder.
3.4. L’ontologia per il servizio di
videosorveglianza
I messaggi scambiati dagli agenti presenti nel sistema di videosorveglianza si distinguono per
due scopi:
Per richiedere/rispondere all’acknowledge
Per richiedere/rispondere ad un riconoscimento di identità
L’ontologia si compone quindi dei seguenti due schemi:
Ontologia per l’acknowledge
La richiesta di un acknowledge sarà rappresentata nell’ontologia da una AgentAction di nome
ConfermaFunzionamento contenente un oggetto Concept chiamato di tipo Acknowledge
appositamente definito. Il tipo di Concept Acknowledge ha al suo interno una variabile
booleana e la posibilità di leggerla e settarla.
Ontologia per il riconoscimento di identità
90

Progettazione del sistema
La richiesta di un riconoscimento di identità sarà rappresentata nell’ontologia da una
AgentAction di nome Identifica contenente un oggetto Concept di tipo Identita e un oggetto
Concept di tipo Immagine appositamente definiti. Il tipo Concept Identità è un Concept con
all’interno una stringa che rappresenterà l’id del volto se riconosciuto e la possibilità di
leggerla e modificarla. L’oggetto Immagine di tipo Concept ha invece al suo interno un array
di byte che rappresenta l’immagine del volto e i metodi per leggerlo e modificarlo.
Figura 3-8 Ontologia del sistema di videosorveglianza
91

4. Implementazione
Il capitolo riguardante l’implementazione è suddiviso nel seguente modo:
Implementazione ontologia
Implementazione applicazione centrale
Implementazione applicazione Android
Viene mostrata per prima l’implementazione dell’ontologia usata dagli agenti che
partecipano alla videosorveglianza, dato che è necessaria per comprendere i messaggi che
vengono scambiati da entrambi gli applicativi. Successivamente è presentata l’applicazione
centrale che si occupa dell’avvio di una piattaforma ad agenti contenente il manager agent in
grado di gestire i dispositivi mobili. Infine è presentato il funzionamento dell’applicazione
Android per il servizio di videosorveglianza ad agenti su smartphone Android.
4.1. Implementazione ontologia
L’ontologia usata dagli agenti manager e Android per scambiarsi i messaggi è implementata
per soddisfare i due tipi di interazione che avviene fra gli agenti:
Per richiedere/rispondere all’acknowledge
Per richiedere/rispondere ad un riconoscimento di identità
Implementazione ontologia per l’acknowledge:
Come detto in precedenza, la richiesta di un acknowledge avviene da parte dell’agente
manager a tutti gli agenti Android da lui conosciuti, i quali ricevendo il messaggio di richiesta
di acknowledge, rispondono con un ack positivo se funziona tutto correttamente o non
rispondono.
92

Implementazione
Per implementare tramite una ontologia la richiesta di un acknowledge si è implementata
una AgentAction di nome ConfermaFunzionamento contenente all’interno un oggetto
Concept di tipo Acknowledge definito nel seguente modo:
public class Acknowledge implements Concept {
}
private boolean ack;
public boolean getAck()
{
return ack;
}
public void setAck(boolean ack)
{
this.ack = ack;
}
Listato 4-1 Concept Acknowledge
L’oggetto Acknowledge ha una variabile booleana e i metodi per settarla e leggerla. Il
messaggio spedito dall’agente manager avrà quindi come contenuto un AgentAction di
questo tipo:
public class ConfermaFunzionamento implements AgentAction {
}
private Acknowledge acknowledge;
public Acknowledge getAcknowledge()
{
return acknowledge;
}
public void setAcknowledge(Acknowledge acknowledge)
{
this.acknowledge = acknowledge;
}
Listato 4-2 AgentAction ConfermaFunzionamento
All’agente Android che riceve il messaggio da parte dell’agente manager sarà sufficiente
estrarre l’oggetto Acknowledge dall’oggetto ConfermaFunzionamento e settare la variabile
booleana a true prima di rispedirglielo.
93

Implementazione
Implementazione ontologia per il riconoscimento di identità
Per effetturare richieste di riconoscimento di identità l’agente Android spedisce un
messaggio di richiesta all’agente manager. Tale messaggio deve contenere l’immagine del
volto da identificare e una variabile che l’agente manager modificherà in base ad un
riconoscimento avvenuto o no. In termini di ontologia fra agenti, è necessario implementare
due Concept rappresentanti l’immagine del volto da riconoscere e un Concept per l’id del
relativo volto (identità della persona). Questi Concept sono implementati dagli oggetti
Immagine e Identità seguente:
public class Immagine implements Concept{
private byte[] img;
}
public byte[] getImg()
{
return img;
}
public void setImg(byte[] img)
{
this.img = img;
}
Listato 4-3 Concept Immagine
public class Identita implements Concept {
private String id;
}
public String getId()
{
return id;
}
public void setId(String id)
{
this.id = id;
}
Listato 4-4 Concept Identita
L’immagine per essere serializzata e spedita nel contenuto di un messaggio ACL deve essere
trasformata in un array di byte, in seguito sarà mostrato come.
La richiesta di riconoscimento del volto è quindi formalizzata tramite l’ontologia in un
oggetto AgentAction di nome Identifica, contenente i due oggetti Immagine e Identita
appena mostrati:
94

Implementazione
public class Identifica implements AgentAction{
}
private Identita identita;
private Immagine immagine;
public Identita getIdentita()
{
return identita;
}
public void setIdentita(Identita identita)
{
this.identita = identita;
}
public Immagine getImmagine()
{
return immagine;
}
public void setImmagine(Immagine immagine)
{
this.immagine = immagine;
}
Listato 4-5 AgentAction Identifica
Quindi tramite questa ontologia, l’agente manager che riceve una richiesta di identificazione
dovrà semplicemente estrarre dal contenuto del messaggio l’oggetto Immagine da elaborare
e modificare l’oggetto Identità per spedire il messaggio di risposta all’agente Android.
L’ontologia usata dal sistema di videosorveglianza è infine rappresentata dalla seguente
classe Videosorveglianza:
public class Videosorveglianza extends Ontology{
public static final String NOME_ONTOLOGIA = "videosorveglianza";
private static Ontology istanza = new Videosorveglianza();
//Action Acknowledge
public static final String CONFERMA_FUNZIONAMENTO =
"ConfermaFunzionamento";
public static final String CONFERMA_FUNZIONAMENTO_ACK =
"Acknowledge";
public static final String ACKNOWLEDGE = "Acknowledge";
public static final String VALORE_ACKNOWLEDGE = "ack";
//Action Identifica
public static final String IDENTIFICA = "Identifica";
public static final String IDENTIFICA_IDENTITA = "identita";
95

Implementazione
public static final String IDENTIFICA_IMMAGINE = "immagine";
public static final String IDENTITA = "identita";
public static final String ID_IDENTITA = "id";
public static final String IMMAGINE = "immagine";
public static final String IMG_IDENTITA = "img";
private Videosorveglianza()
{
super(NOME_ONTOLOGIA,BasicOntology.getInstance());
//definisce la sintassi e la semantica degli elementi
dell'ontologia
try
{
add(new AgentActionSchema(CONFERMA_FUNZIONAMENTO),
ConfermaFunzionamento.class);
add(new ConceptSchema(ACKNOWLEDGE), Acknowledge.class);
AgentActionSchema as_actack = (AgentActionSchema)
getSchema(CONFERMA_FUNZIONAMENTO);
as_actack.add(CONFERMA_FUNZIONAMENTO_ACK, (ConceptSchema)
getSchema(ACKNOWLEDGE), ObjectSchema.OPTIONAL);
ConceptSchema cs_ack = (ConceptSchema)
getSchema(ACKNOWLEDGE);
cs_ack.add(VALORE_ACKNOWLEDGE, (PrimitiveSchema)
getSchema(BasicOntology.BOOLEAN));
add(new AgentActionSchema(IDENTIFICA), Identifica.class);
add(new ConceptSchema(IDENTITA), Identita.class);
add(new ConceptSchema(IMMAGINE), Immagine.class);
AgentActionSchema as_identifica = (AgentActionSchema)
getSchema(IDENTIFICA);
as_identifica.add(IDENTIFICA_IDENTITA, (ConceptSchema)
getSchema(IDENTITA), ObjectSchema.OPTIONAL);
as_identifica.add(IDENTIFICA_IMMAGINE, (ConceptSchema)
getSchema(IMMAGINE), ObjectSchema.OPTIONAL);
ConceptSchema cs_identita = (ConceptSchema)
getSchema(IDENTITA);
cs_identita.add(ID_IDENTITA, (PrimitiveSchema)
getSchema(BasicOntology.STRING));
ConceptSchema cs_immagine = (ConceptSchema)
getSchema(IMMAGINE);
cs_immagine.add(IMG_IDENTITA, (PrimitiveSchema)
getSchema(BasicOntology.BYTE_SEQUENCE));
}
catch (OntologyException e)
{
e.printStackTrace();
96

}
}
}
Implementazione
//singleton
public static Ontology getInstance()
{
return istanza;
}
Listato 4-6 Ontologia Videosorveglianza
4.2. Implementazione applicazione centrale
L’applicazione centrale è chiamata “videosorveglianza” ed ha il compito di creare una Jade
platform in cui è presente l’agente manager. L’agente manager come si è precedentemente
detto, ha il compito di conoscere i dispositivi collegati al servizio di videosorveglianza, sapere
quali sono i dispositivi funzionanti in maniera aggiornata e rispondere alle richieste di
riconoscimento del volto da parte dei dispositivi Android. L’agente manager però non è in
grado di risolvere i riconoscimenti del volto in modo indipendente, questo perché non
dispone della logica di riconoscimento del volto, quindi per soddisfare queste richieste
l’agente manager deve chiedere a sua volta l’identità del volto ad una applicazione in grado
di farlo.
4.2.1. Struttura applicazione videosorveglianza
L’applicazione videosorveglianza è suddivisa nei seguenti 4 package:
Comportamenti
Manager
Ontology
Startapp
97

Implementazione
Nel package comportamenti sono presenti le classi che implementano i comportamenti
dell’agente manager, nel package manager è presente la classe che implementa l’agente
manager e le classi per la sua interfaccia (la classe ParticipantsFrame è stata utilizzata
solamente in fase di sviluppo). Nel package ontology sono presenti le classi che
implementano l’ontologia usata dagli agenti della videosorveglianza, nel package startapp è
presente la classe che lancia la piattaforma Jade con l’agente manager.
Figura 4-1 Struttura applicazione Videosorveglianza
Ovviamente sono state importate fra le librerie dell’applicazione “videosorveglianza” i file .jar
di jade, ovvero jade.jar e commons-codec-1.3.jar.
98

Implementazione
4.2.2. Avvio applicazione “videosorveglianza”
L’avvio dell’applicazione “videosorveglianza” è implementata dalla classe Start, la quale
lancia una Jade platform contenente un agente manager;
public class Start{
public static void main(String args[]) throws StaleProxyException {
String[] IdVideo={"-gui",
"manager:videosorveglianza.manager.ManagerAgent" }; // Attivazione
Piattaforma:
Boot.main(IdVideo);
}
}
Listato 4-7 Avvio applicazione videosorveglianza
Eseguendo questa applicazione come Java Application si ottiene questo risultato:
Figura 4-2 Avvio applicazione videosorveglianza visto dalla GUI dell'RMA
99

Implementazione
4.2.3. Implementazione agente manager
L’agente manager per soddisfare il requisito di conoscenza degli agenti mobili attualmente
connessi al servizio di videosorveglianza, implementa l’interfaccia di SubscriptionManager. In
questo modo quando un agente Android entra a far parte della videosorveglianza, spedisce
all’agente manager un messaggio di Subscription per aggiungersi alla lista degli agenti
presenti. L’agente manager per sapere in modo automatico quando un agente collegato al
servizio di videosorveglianza muore, attiva un behaviour di tipo AMSSubriber. Tramite
l’implementazione dell’interfaccia SubscriptionManager e l’aggiunta del behaviour
AMSSubscriber, l’agente manager aggiorna la sua lista di dispositivi attualmente connessi in
modo tempestivo e incrementale, evitando un periodico messaggio di richiesta al DF di
richiesta di tutti i dispositivi attualmente connessi che aggiornerebbe periodicamente l’intera
lista, la quale inoltre non sarebbe sempre aggiornata, dato che l’aggiornamento sarebbe
pilotato periodicamente. Queste operazioni sono implementate nel metodo setup() della
classe dell’agente manager e nella definizione dei metodi dell’interfaccia
SubscriptionManager. La lista dei dispositivi collegati alla piattaforma di videosorveglianza
sono contenuti in un array di tipo AID. Prima di spiegare ulteriormente il funzionamento
dell’agente manager verrà mostrato il codice relativo al metodo setup() della classe
ManagerAgent e l’implementazione dei metodi register() e deregister() relativi all’interfaccia
SubscriptionManager:
protected void setup() {
myGui=new ManagerGUIImpl(this);
registerO2AInterface(ManagerGUIInt.class, myGui);
// Prepare to accept subscriptions from participants
getContentManager().registerLanguage(codec);
getContentManager().registerOntology(ontologia);
MessageTemplate sTemplate = MessageTemplate.and(
MessageTemplate.MatchPerformative(ACLMessage.SUBSCRIBE),
MessageTemplate.MatchLanguage(codec.getName()));
//aggiunge il behaviour di subscription responder con template
subscribe
//serve per sapere quando si iscrivono, non dall'ams ma dal
messaggio che gli inviano gli agenti Android
addBehaviour(new SubscriptionResponder(this, sTemplate, this));
// Register to the AMS to detect when participants suddenly die
myAMSSubscriber = new AMSSubscriber() {
@SuppressWarnings("unchecked")
100

Implementazione
protected void
installHandlers(@SuppressWarnings("rawtypes") Map handlersTable) {
// Fill the event handler table. We are only
interested in the
// DEADAGENT event
handlersTable.put(IntrospectionOntology.DEADAGENT,
new EventHandler() {
public void handle(Event ev) {
DeadAgent da = (DeadAgent)ev;
AID id = da.getAgent();
if (participants.containsKey(id)) {
try {
deregister((Subscription)
participants.get(id));
}
catch (Exception e) {
//Should never happen
e.printStackTrace();
}
}
}
});
}
};
addBehaviour(new DFRegistraManager(this));
//serve per sapere dall'ams quando gli agenti muoiono
addBehaviour(myAMSSubscriber);
addBehaviour(new ControllaAckCyclic(this, 10000));//
TickerBehaviuor che fà ContractNetIniziator
MessageTemplate template =
MessageTemplate.MatchPerformative(ACLMessage.REQUEST);
addBehaviour(new RespondImage(this, template));
}// FINE SETUP
Listato 4-8 Metodo setup() dell'agente manager
public boolean register(Subscription s) throws RefuseException,
NotUnderstoodException {
try {
AID newId = s.getMessage().getSender();
participants.put(newId, s);
keys = new AID[participants.size()];
nomi = new String[participants.size()];
// Add the new subscription
Object[] prova= participants.keySet().toArray();
for (int index=0;index

}
}
Implementazione
Listato 4-9 Metodo register() dell'agente manager
public boolean deregister(Subscription s) throws FailureException {
AID oldId = s.getMessage().getSender();
// Remove the subscription
participants.remove(oldId);
keys = new AID[participants.size()];
nomi = new String[participants.size()];
// Add the new subscription
Object[] prova= participants.keySet().toArray();
for (int index=0;index

}
}
Implementazione
La classe ManagerAgent implementa quindi i metodi setKeys e getKeys che scrive e legge il
vettore di AID di nome keys che contiene l’informazione relativa ai dispositivi attualmente
connessi.
public void setKeys(AID[] keys){
this.keys=keys;
nomi=new String[keys.length];
for (int index=0;index

}
Implementazione
@Override
public void onStart()
{
System.out.println(myAgent.getLocalName()+">> Mi sto
registrando per partecipare alla videosorveglianza");
}
@Override
public void action()
{
//definisce un servizio...
ServiceDescription sd = new ServiceDescription();
sd.setType("manager");
sd.setName(myAgent.getLocalName()+"-manager");
//...e lo aggiunge all'insieme dei servizi offerti da un agente
DFAgentDescription dfd = new DFAgentDescription();
dfd.addServices(sd);
dfd.setName(myAgent.getAID());
//l'agente si registra alle "pagine gialle"
try
{
DFService.register(myAgent, dfd);
}
catch (FIPAException e)
{
e.printStackTrace();
}
}
@Override
public int onEnd()
{
System.out.println(myAgent.getLocalName()+">> Partecipo alla
videosorveglianza");
return 0;
}
}
ControllaAckCyclic
Listato 4-12 Behaviour DFRegistraManager
Il behaviour ControllaAckCyclic è il behaviour responsabile del controllo dei dispositivi
funzionanti collegati al servizio di videosorveglianza. Nel caso vi sia un agente software
collegato alla piattaforma di videosorveglianza che per qualche malfunzionamento non
risponde alla richiesta di acknowledge, questo agente verrà ritenuto mal funzionante ed
eliminato dalla lista degli agenti presenti nella piattaforma dell’agente manager. Compito di
tale behaviour è quindi spedire un messaggio avente l’opportuno contenuto definito
104

Implementazione
dall’ontologia della videosorveglianza per richiedere un acknowledge, a tutti gli agenti
presenti nella lista degli agenti presenti e funzionanti ( l’array di nome “keys” di tipo AID
detto precedentemente) e controllare le risposte. Soltanto gli agenti che avranno risposto
all’acknowledge in maniera positiva faranno ancora parte della lista dell’agente manager. Per
implementare tale comportamento il behaviour ControllaAckCyclic è un behaviour che
estende la classe TickerBehaviour in modo tale che periodicamente, ogni 10 secondi, venga
aggiunto all’agente manager un behaviour chiamato ControllaAck, il quale estende la classe
ContractNetInitiator. Il behaviour ControllaAckCyclic ad ogni periodo prepara un messaggio
ACL di tipo CallForProposal con destinatari tutti gli agenti conosciuti dal manager agent e con
contenuto la richiesta di acknowledge definita tramite l’ontologia. Tale messaggio viene
passato come argomento al behaviour ControllaAck che spedisce il messaggio e tramite il
metodo handleAllResponces è sufficiente scorrere i messaggi di risposta corretti per
aggiornare la lista degli agenti funzionanti. Una volta controllate tutte le risposte di
acknowledge, si aggiorna il vettore degli agenti conosciuti dall’agente manager utilizzando
l’interfaccia e il metodo setKeys. Di seguito è mostrato il codice relativo al behaviour
ControllaAckCyclic definito all’interno della classe ManagerAgent:
class ControllaAckCyclic extends TickerBehaviour{
public ControllaAckCyclic(Agent a, long period) {
super(a, period);
// TODO Auto-generated constructor stub
}
@Override
protected void onTick() {
// TODO Auto-generated method stub
ACLMessage reply = new ACLMessage(ACLMessage.CFP);
if (keys!=null)
{
for(int i=0; i

}
}
}
Implementazione
cel.add(act);
ContentManager cm = myAgent.getContentManager();
reply.setLanguage(cm.getLanguageNames()[0]);
reply.setOntology(cm.getOntologyNames()[0]);
try {
cm.fillContent(reply, cel);
} catch (Exception e) {
e.printStackTrace();
}
addBehaviour(new ControllaAck(myAgent, reply));
Listato 4-13 behaviour ControllaAckcyclic
E questo il codice relativo al behaviour ControllaAck:
public class ControllaAck extends ContractNetInitiator{
ManagerGUIInt myGui; //interfaccia agente manager
//aggiunge alla lista gli AID di chi risponde all'ack
ArrayList lista=new ArrayList();
//CFP passato come argomento al costruttore
public ControllaAck(Agent a, ACLMessage cfp) {
super(a, cfp);
myGui=myAgent.getO2AInterface(ManagerGUIInt.class);
}
//Si attiva quando riceve tutte le risposte al CFP
@SuppressWarnings({ "rawtypes", "unchecked" })
@Override
protected void handleAllResponses(Vector responses, Vector
acceptances)
{
ContentManager cm = myAgent.getContentManager();
System.out.println(responses.size());
if (responses!=null)
{
for(int i=0; i

Implementazione
if(ack.getAck()==true)
{
lista.add(((ACLMessage)responses.get(i)).getSender());
}
}
catch (Exception e)
{
e.printStackTrace();
}
}
for(int i=0; i

Implementazione
che implementa la parte di Responder per il protocollo FIPA Resquest. Tale behaviour riceve
un messaggio ACL di tipo Request, il cui contenuto è formalizzato attraverso l’ontologia della
videosorveglianza, quindi contiene l’immagine in byte dell’ipotetico volto da riconoscere e
una stringa da riempire con la risposta. E’ stato annunciato che l’agente manager non ha la
logica di riconoscimento del volto al suo interno, quindi deve salvare l’immagine in byte
contenuta nel messaggio in una locazione di memoria prestabilita e in formato bitmap per
poter effettuare la richiesta di riconoscimento del volto ad una applicazione in grado di farlo.
Nel caso studiato l’applicazione di riconoscimento del volto è stata sviluppata da Gianluca
Dolcini ([15]). Dopo aver salvato l’immagine in una locazione prestabilita e con un nome
identificativo della richiesta, viene effettuata la richiesta tramite messaggio UDP.
L’applicazione riceve la richiesta di elaborazione dell’immagine e risponde con un
riconosciuto o non riconosciuto, quindi l’agente manager risponderà all’agente Android che
aveva richiesto l’identità del volto. Questo è il codice relativo al behaviour RespondImage :
public class RespondImage extends AchieveREResponder{
//nome immagine da salvare
int c=0;
/** Save directory for face images*/
static String saveDir = "/Users/andreabaldini/Desktop/condivisa/";
/** Message byte to/from application*/
private byte msg[]=new byte[]{0};
private boolean riconosciuto=false;
public RespondImage(Agent a, MessageTemplate mt) {
super(a, mt);
// TODO Auto-generated constructor stub
}
protected ACLMessage prepareResponse(ACLMessage request){
System.out.println("Responder has received the following message: " +
request + "in t= "+System.currentTimeMillis() + " da agente:
"+request.getSender().getName());
ACLMessage informDone = request.createReply();
ContentManager cm = myAgent.getContentManager();
riconosciuto=false;
Action act;
try {
act = (Action) cm.extractContent(request);
Identifica azione = (Identifica) act.getAction();
Immagine imgconc = azione.getImmagine();
Identita id=azione.getIdentita();
byte[] imgbyte=imgconc.getImg();
//id.setId("Andrea");
BufferedImage img = ImageIO.read(new
ByteArrayInputStream(imgbyte));
108

Implementazione
//CHIAMA FUNZIONE CHE RISPONDE CON CHI E ALLIMMAGINE QUINDI
SALVA SU IDENTITA
if (img!=null && img.getHeight()>0){
if (c++>100) c=0; //progressive counter to store more
images on disk
//mask alpha
BufferedImage imgsend=new BufferedImage(img.getWidth(),
img.getHeight(),BufferedImage.TYPE_BYTE_GRAY);
ColorConvertOp conv = new ColorConvertOp(null);
conv.filter(img, imgsend);
//save gray scale 8-bit image
ImageIO.write(imgsend, "bmp", new
File(saveDir+c+".bmp"));
try
{
msg[0]=(byte)c;
//ask face elaboration to other software
DatagramPacket p=new DatagramPacket(msg, 1,new
InetSocketAddress("10.211.55.4", Integer.parseInt("5000")));
DatagramSocket ds=new DatagramSocket();
ds.send(p); //send image ID message to other
application on port 5000
ds.close();
System.out.println("DOPO IL SEND");
//send ok
//receive socket
ds=new DatagramSocket(Integer.parseInt("5001"));
//wait response from application on port 5001
ds.setSoTimeout(20); //wait on receive for only
20ms
while (true){
try{
//Thread.sleep(10); //necessary for
interrupt thread when it's waiting response
ds.receive(p);
//Thread.sleep(2); //last interrupt
before send response
p.getData();
System.out.println("DOPO IL RECEIVE");
if((int)p.getData()[0]==1){
riconosciuto=true;
}
else{
riconosciuto=false;
}
System.out.println("received:
"+(int)p.getData()[0]+ " on ms: "+(System.currentTimeMillis()));
ds.close();
ds=null;
break; //receive ok, so rend response to
smartphone
}catch (SocketTimeoutException se){
//System.out.println("socket timeout
"+se.toString());
109

"+ee.toString());
}
}
Implementazione
//continue wait response
}catch (Exception ee){
System.out.println("error:
}
ee.printStackTrace();
ds.close();
ds=null;
//return; //generic error on receive
}
}catch (Exception e){
System.out.println("End Elaborate: "+e.toString());
e.printStackTrace();
}
}
if(riconosciuto==true){
id.setId("Andrea");
informDone.setPerformative(ACLMessage.INFORM);
informDone.setLanguage(cm.getLanguageNames()[0]);
informDone.setOntology(cm.getOntologyNames()[0]);
ContentElementList cel = new ContentElementList();
cel.add(act);
cm.fillContent(informDone, cel);
}
else{
id.setId("sconosciuto");
informDone.setPerformative(ACLMessage.INFORM);
informDone.setLanguage(cm.getLanguageNames()[0]);
informDone.setOntology(cm.getOntologyNames()[0]);
ContentElementList cel = new ContentElementList();
cel.add(act);
cm.fillContent(informDone, cel);
}
} catch (UngroundedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (CodecException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (OntologyException e) {
// TODO Auto-generated catch block
e.printStackTrace();
//} catch (IOException e) {
// TODO Auto-generated catch block
//e.printStackTrace();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return informDone;
Listato 4-15 Behaviour RespondImage
110

Implementazione
4.3. Implementazione applicazione Android
L’applicazione Android per l’inseguimento del volto mi è stata fornita dal Dipartimento di
Ingegneria dell’Informazione, di seguito un brevissimo riassunto del suo funzionamento
prima dell’agentificazione: L’Activity principale dell’applicazione è implementata dalla classe
FdActivity e rappresenta il punto di accesso all’applicazione, dove vengono inizializzati i vari
componenti; la CvBaseView si occupa della visualizzazione dell’interfaccia grafica; FpsMeter è
una classe di utilità che calcola i FPS; FdView contiene la logica del sistema di visione per
l’individuazione e selezione dei volti. A partire dall’applicazione data, per fornire il servizio di
videosorveglianza ad agenti è stato necessario modificare il modo in cui l’applicazione
effettua le richieste di identificazione dei volti, sostituendo la precedente comunicazione con
una comunicazione ad agenti che sia inserita nella logica del sistema di visione e
individuazione dei volti senza comprometterne la logica stessa o il funzionamento.
4.3.1. File AndroidManifest.xml e struttura
applicazione
L’applicazione Android ad agenti creata ha il seguente file AndroidManifest.xml e struttura:
111

Implementazione
Listato 4-16 File AndoridManifest.xml
E’ possibile notare la dichiarazione del jade.android.MicroRuntimeService per l’utilizzo di uno
split container nel tag service del tag application.
La struttura dell’applicazione:
112

Implementazione
Figura 4-3 Struttura applicazione Android
Per il funzionamento dell’applicazione è necessario importare la libreria jadeAndroid.jar per il
framework ad agenti e la libreria OpenCV-2.3.1.jar per la logica di elaborazione video.
113

Implementazione
4.3.2. Creazione agente Android
La creazione dell’agente Android è effettuata nella classe FdActivity, in particolare nel
metodo onCreate dove viene chiamato il metodo startSorveglianza. Tale metodo riceve in
ingresso l’indirizzo IP della piattaforma Jade in cui creare lo split container per l’agente della
classe ClientAgent, il numero di porta e un oggetto AgentController:
public boolean startSorveglianza(final String host,
final String port, final RuntimeCallback
agentStartupCallback) {
final Properties profile = new Properties();
profile.setProperty(Profile.MAIN_HOST, host);
profile.setProperty(Profile.MAIN_PORT,port);
profile.setProperty(Profile.MAIN, Boolean.FALSE.toString());
profile.setProperty(Profile.JVM, Profile.ANDROID);
if (AndroidHelper.isEmulator()) {
// Emulator: this is needed to work with emulated devices
profile.setProperty(Profile.LOCAL_HOST,
AndroidHelper.LOOPBACK);
} else {
profile.setProperty(Profile.LOCAL_HOST,
AndroidHelper.getLocalIPAddress());
}
// Emulator: this is not really needed on a real device
profile.setProperty(Profile.LOCAL_PORT, "1099");
microRuntimeServiceBinder=null;
serviceConnection=null;
if (microRuntimeServiceBinder == null) {
serviceConnection = new ServiceConnection() {
public void onServiceConnected(ComponentName
className,
IBinder service) {
microRuntimeServiceBinder =
(MicroRuntimeServiceBinder) service;
logger.log(Level.INFO, "Gateway successfully
bound to MicroRuntimeService");
startContainer(profile, agentStartupCallback);
};
public void onServiceDisconnected(ComponentName
className) {
logger.log(Level.INFO, "Gateway unbound from
MicroRuntimeService");
microRuntimeServiceBinder = null;
}
};
logger.log(Level.INFO, "Binding Gateway to
MicroRuntimeService...");
bindService(new Intent(getApplicationContext(),
114

Implementazione
MicroRuntimeService.class), serviceConnection,
Context.BIND_AUTO_CREATE);
//ritorno=true;
} else {
logger.log(Level.INFO, "MicroRumtimeGateway already
binded to service");
startContainer(profile, agentStartupCallback);
}
return true;
}
//"XXX%CYYY"
private boolean startContainer(Properties profile, final
RuntimeCallback agentStartupCallback) {
//if (!MicroRuntime.isRunning()) {
microRuntimeServiceBinder.startAgentContainer(profile,
new RuntimeCallback() {
@Override
public void onSuccess(Void thisIsNull) {
startAgent(agentStartupCallback);
}
@Override
public void onFailure(Throwable
throwable) {
}
});
//} else {
// startAgent(agentStartupCallback);
//}
return true;
}
private boolean startAgent(final RuntimeCallback
agentStartupCallback) {
microRuntimeServiceBinder.startAgent(nick,
it.univpm.dii.agent.ClientAgent.class.getName(),
new Object[] { getApplicationContext() }, new
RuntimeCallback() {
@Override
public void onSuccess(Void thisIsNull) {
logger.log(Level.INFO, "Successfully start of the "
+
it.univpm.dii.agent.ClientAgent.class.getName() + "...");
try {
agentStartupCallback.onSuccess(MicroRuntime
.getAgent(nick));
} catch (ControllerException e) {
// Should never happen
agentStartupCallback.onFailure(e);
}
}
@Override
public void onFailure(Throwable throwable) {
logger.log(Level.SEVERE, "Failed to start the "
+
it.univpm.dii.agent.ClientAgent.class.getName() + "...");
agentStartupCallback.onFailure(throwable);
115

}
}
});
return true;
Implementazione
Listato 4-17 Creazione agente Android
Quindi il metodo onCreate() della classe FdActivity è il seguente:
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
requestWindowFeature(Window.FEATURE_NO_TITLE);
try {
mServer = new Server(4568); // Use ADK port
mServer.start();
} catch (IOException e) {
Log.e(TAG, "Unable to start TCP server", e);
System.exit(-1);
}
// Restore preferences
SharedPreferences settings = getSharedPreferences(PREFS_NAME,
MODE_PRIVATE);
serverIP = settings.getString("IP","192.168.1.92");
startSorveglianza("192.168.1.92","1099",agentStartupCallback );
try{
view=new FdView(this, nick);
setContentView(view);
Log.i("FdActivity", "Finish create Jade Agent
t="+System.currentTimeMillis());
}
catch(Exception e){
System.out.println("errore");
}
Listato 4-18 Metodo oncreate() di FdActivity
Nel metodo onCreate() viene creata l’istanza della classe FdView contenente la logica di
elaborazione video per l’individuazione dei volti e aggiunta alla FdActivity.
4.3.3. Implementazione agente Android
L’agente Android per partecipare alla videosorveglianza ha bisogno della conoscenza
dell’indirizzo di un agente manager con cui comunicare. Dopo aver trovato la presenza di un
agente manager, l’agente Android spedisce un messaggio di subscription per aggiungersi alla
lista degli agenti partecipanti alla videosorveglianza dell’agente manager e successivamente
116

Implementazione
si registra al DF della piattaforma per pubblicare il suo servizio di “telecamera”. L’agente
Android implementa poi i behaviour per rispondere alle richieste di acknowledge provenienti
dall’agente manager e il comportamento per effettuare richieste di identificazione dei volti. Il
metodo setup() dell’agente Adroid è il seguente:
protected void setup() {
Object[] args = getArguments();
if (args != null && args.length > 0) {
if (args[0] instanceof Context) {
context = (Context) args[0];
}
}
// Register language and ontology
ContentManager cm = getContentManager();
cm.registerLanguage(codec);
cm.registerOntology(onto);
cm.setValidationMode(false);
//prendo AID manager
DFAgentDescription dfd = new DFAgentDescription();
ServiceDescription sd = new ServiceDescription();
sd.setType( "manager" );
dfd.addServices(sd);
DFAgentDescription[] result;
try {
result = DFService.search(this, dfd);
if (result.length>0)
manager=result[0].getName();
} catch (FIPAException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
//registro interfaccia
myGui=new ClientGUIImpl(this);
registerO2AInterface(ClientGUIInt.class, myGui);
// Add initial behaviours
addBehaviour(new DFRegistraCamera(this));
addBehaviour(new ParticipantsManager(this));
addBehaviour(new RispondiAck(this,
MessageTemplate.MatchPerformative(ACLMessage.CFP)));
}
Listato 4-19 Metodo setup() dell'agente Android
117

Implementazione
Nel setup l’agente Android recupera l’AID dell’agente manager della piattaforma, registra la
sua interfaccia e aggiunge i seguenti behaviour:
DFRegistraCamera per registrarsi al DF,
ParticipantsManager per aggiungersi alla lista degli agenti presenti alla
videosorveglianza del manager,
RispondiAck per rispondere alle richieste di acknowledge.
L’interfaccia dell’agente Android è necessaria per poter effettuare richieste di identificazioni
di volti attraverso la logica di elaborazione del video da parte della classe FdView. L’agente
Android possiede tre variabili, una per memorizzare l’attuale immagine del volto da
elaborare in un array di byte, una stringa per l’identità del volto dell’immagine e una variabile
booleana che userà la FdView per conoscere quando una risposta di identificazione è
arrivata. L’FdView per effettuare una richiesta di identificazione di un volto usa queste tre
variabili, a cui ha accesso grazie all’interfaccia dell’agente Android che gli permette di
leggerle e modificarle:
public class ClientGUIImpl implements ClientGUIInt{
private ClientAgent myAgent;
public ClientGUIImpl(ClientAgent a) {
myAgent = a;
}
public void sendImg(byte[] img) {
// TODO Auto-generated method stub
myAgent.sendImg(img);
}
public byte[] getImg() {
// TODO Auto-generated method stub
return myAgent.getImg();
}
public String getId() {
// TODO Auto-generated method stub
return myAgent.getId();
}
public void setId(String id) {
// TODO Auto-generated method stub
myAgent.setId(id);
}
118

}
Implementazione
public void setArrivata(boolean arrivata) {
// TODO Auto-generated method stub
myAgent.setArrivata(arrivata);
}
public boolean getArrivata() {
// TODO Auto-generated method stub
return myAgent.getArrivata();
}
Behaviour DFRegistraCamera
Listato 4-20 Interfaccia agente Android
Il behaviour DFRegistraCamera estende la classe oneShotBehaviour per registrare l’agente
Android al DF con il servizio di “telecamera”:
public class DFRegistraCamera extends OneShotBehaviour{
public DFRegistraCamera(Agent a) {
super(a);
}
@Override
public void onStart()
{
System.out.println(myAgent.getLocalName()+">> Mi sto
registrando per partecipare alla videosorveglianza");
}
@Override
public void action()
{
//definisce un servizio...
ServiceDescription sd = new ServiceDescription();
sd.setType("telecamera");
sd.setName(myAgent.getLocalName()+"-telecamera");
//...e lo aggiunge all'insieme dei servizi offerti da un agente
DFAgentDescription dfd = new DFAgentDescription();
dfd.addServices(sd);
dfd.setName(myAgent.getAID());
//l'agente si registra alle "pagine gialle"
try
{
DFService.register(myAgent, dfd);
}
119

}
Implementazione
catch (FIPAException e)
{
e.printStackTrace();
}
@Override
public int onEnd()
{
System.out.println(myAgent.getLocalName()+">> Partecipo alla
videosorveglianza");
return 0;
}
}
Listato 4-21 Behaviour DFRegistraCamera
Behaviour RispondiAck
Il behaviour RispondiAck permette all’agente Android di rispondere alle richieste di
acknowledge provenienti dall’agente manager. Il protocollo usato dall’agente manager per
richiedere l’ack è il FIPA Contract-Net quindi tale behaviour estende la classe
ContractNetResponder. Tale comportamento se riceve un messaggio di tipo Call-for-
Proposal, estrae dal contenuto del messaggio l’acknowledge formalizzato dall’ontologia, lo
modifica a vero per confemare l’ack e rispedisce il messaggio ACL di tipo Propose con
contenuto l’appropriato ack in modo da rispettare il protocollo e rispondere all’acknowledge.
Questa è l’implementazione:
public class RispondiAck extends ContractNetResponder{
public RispondiAck(Agent a, MessageTemplate mt) {
super(a, mt);
}
//si attiva quando viene ricevuto un CFP
@Override
protected ACLMessage handleCfp(ACLMessage msg)
{
ContentManager cm = myAgent.getContentManager();
ACLMessage reply = msg.createReply();
reply.setPerformative(ACLMessage.PROPOSE);
reply.setLanguage(cm.getLanguageNames()[0]);
reply.setOntology(cm.getOntologyNames()[0]);
//estrae il contenuto del CFP e prepara una proposta
try
{
Action act = (Action) cm.extractContent(msg);
120

Implementazione
ConfermaFunzionamento proponi =
(ConfermaFunzionamento) act.getAction();
Acknowledge ack = proponi.getAcknowledge();
ack.setAck(true);
}
ContentElementList cel = new ContentElementList();
cel.add(act);
cm.fillContent(reply, cel);
}
catch (Exception e)
{
e.printStackTrace();
}
return reply;
//si attiva quando viene accettata una proposta
@Override
protected ACLMessage handleAcceptProposal(ACLMessage cfp,
ACLMessage proposal, ACLMessage accept)
{
//informa l'"Initiator" circa l'esito della
contrattazione
proposal.setPerformative(ACLMessage.INFORM);
return proposal;
}
@Override
protected void handleRejectProposal(ACLMessage cfp, ACLMessage
proposal, ACLMessage accept)
{
System.out.println("Ha rifiutato");
}
}
Behaviour SendImage
Listato 4-22 Behaviour RispondiAck
Il behaviour SendImage è il behaviour responsabile dell’invio delle richieste di identificazione
di volti da parte dell’agente Andoroid. Tale behaviour usa il protocollo FIPA Request per
comunicare la richiesta all’agente manager, quindi estende la classe AchieveReInitiator, il
quale manda un messaggio all’agente manager contenente l’immagine del volto da
identificare tramite l’opportuna ontologia usata dalla videosorveglianza.
Questo è il codice relativo al metodo sendImg della classe ClientAgent e richiamabile
dall’interfaccia dell’agente Android, il cui obiettivo è di creare il messaggio con l’oppurtuno
121

Implementazione
contenuto (l’immagine del volto) per richiedere l’identità del volto e l’invio della richiesta
tramite il behaviour SendImage
public void sendImg(byte[] byteimg){
this.byteimg=byteimg;
//prepara messaggio con immagine e lancia il fipa request
protocol
ACLMessage msg = new ACLMessage(ACLMessage.REQUEST);
msg.addReceiver(manager);
Action act = new Action();
Identifica identifica = new Identifica();
Identita id = new Identita();
Immagine img = new Immagine();
img.setImg(byteimg);
id.setId("sconosciuto");
identifica.setIdentita(id);
identifica.setImmagine(img);
act.setAction(identifica);
act.setActor(this.getAID());
ContentElementList cel = new ContentElementList();
cel.add(act);
ContentManager cm = this.getContentManager();
msg.setLanguage(cm.getLanguageNames()[0]);
msg.setOntology(cm.getOntologyNames()[0]);
try {
cm.fillContent(msg, cel);
} catch (Exception e) {
e.printStackTrace();
}
Log.i("ClientAgent sendImg", "Immagine effettivamente inviata
t="+System.currentTimeMillis());
addBehaviour(new SendImage(this, msg));
}
Il codice del behaviour SendImage è il seguente:
public class SendImage extends AchieveREInitiator{
ClientAgent myAgent;
public SendImage(Agent a, ACLMessage msg) {
super(a, msg);
myAgent=(ClientAgent) a;
// TODO Auto-generated constructor stub
}
protected void handleInform(ACLMessage inform) {
System.out.println("Agent "+inform.getSender().getName()+"
successfully performed the requested action");
122

Implementazione
Log.i("SendImage", "Risposta effettivamente arrivata
t="+System.currentTimeMillis());
//leggo la risposta
ContentManager cm = myAgent.getContentManager();
Action act;
try {
act = (Action) cm.extractContent(inform);
Identifica identifica = (Identifica) act.getAction();
Identita id = identifica.getIdentita();
//inserisce la risposta nella variabile id e setta a true
il boolean arrivata
myAgent.setId(id.getId());//mette nella variabile id
dell'agente, l'id appena ricevuto
myAgent.setArrivata(true);
} catch (UngroundedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (CodecException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (OntologyException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
protected void handleRefuse(ACLMessage refuse) {
System.out.println("Agent "+refuse.getSender().getName()+"
refused to perform the requested action");
}
protected void handleFailure(ACLMessage failure) {
if (failure.getSender().equals(myAgent.getAMS())) {
// FAILURE notification from the JADE runtime: the
receiver
// does not exist
System.out.println("Responder does not exist");
}
else {
System.out.println("Agent
"+failure.getSender().getName()+" failed to perform the requested action");
}
}
protected void handleAllResultNotifications(Vector notifications) {
// Some responder didn't reply within the specified
timeout
System.out.println("Timeout expired: missing responses");
}
}
Listato 4-23 Behaviour SendImage
Tale behaviour attraverso il metodo handleInform gestisce il messaggio di risposta
dell’agente manager, estraendo dal contenuto l’identità del volto. Successivamente setta la
123

Implementazione
variabile booleana dell’agente Android a true in modo da far sapere alla logica di
elaborazione del video che è arrivata una risposta di identificazione.
4.3.4. Interazione agente e logica di
elaborazione del video
La logica di elaborazione video per l’individuazione dei volti è contenuta nella classe FdView,
la quale estende la classe CvBaseView. CvBaseView è una classe astratta che estende
SurfaceView e tramite il metodo run() effettua iterativamente l’analisi del video tramite il
metodo processFrame(). Quindi iterativamente viene elaborato il video, calcolati i frame per
secondo e altre informazioni. L’elaborazione del video è contenuta nel metodo
processFrame() implementato da FdView, che contiene gli algoritmi e le strutture dati
necessarie per elaborare il video e determinare il volto dominante da seguire. Le funzionalità
del sistema di visione sono rese disponibili dalla libreria OpenCV appositamente compilata
per il sistema operativo Android. La classe viene creata all’avvio dell’applicazione, si carica in
memoria il file di apprendimento per l’algoritmo di individuazione dei volti e viene avviato un
thread per la ricezione delle risposte di riconoscimento dei volti che arrivano all’agente. Il
metodo processFrame si occupa di individuare i volti, selezionare il volto dominante e
preparare l’immagine da inviare all’agente manager tramite l’agente Android. Prima di
analizzare l’interazione con l’agente Android, segue un riassunto del funzionamento
dell’elaborazione di individuazione dei volti e scelta del volto dominante implementata da
Simone Saraceni ([12]). Il video catturato, viene elaborato equalizzandone l’istogramma,
quindi viene eseguito l’algoritmo di individuazione dei volti. La scansione ricerca i volti con
una dimensione minima di 90x90 pixel, ad ogni iterazione la dimensione viene incrementata
di un fattore 1,3. La variabile faces contiene la lista delle posizioni di tutti i volti individuati
nel frame corrente; il passo successivo è quello di cercare ogni volto individuato nei frame
precedenti, aggiornandone le informazioni per mezzo del metodo updatePos; il vettore
hFaces contiene le informazioni relative ai volti individuati nel frame attuale e in quelli
precedenti. Il tipo di dati CFace è stato creato per memorizzare le informazioni relative ai
124

Implementazione
volti individuati, ovvero la posizione e il tempo di permanenza sulla scena. Dopo aver
aggiornato lo storico con i nuovi volti individuati, questo viene scansionato alla ricerca del
volto dominante, eliminando i volti non più presenti nella scena. Ogni volta che viene
individuato un volto dominante diverso dal precedente, oppure è trascorso un certo
intervallo di tempo dall’ultimo invio di una richiesta, viene creata l’immagine bitmap del
volto dominante, pronta per una richiesta. L’operazione di ricerca del volto dominante si
basa sul tempo di permanenza nella scena; ogni volto individuato viene ricercato nello
storico: se la posizione attuale del vertice superiore sinistro è in un intorno della posizione
precedente, i due volti confrontati sono marcati come identici.
s);
protected Bitmap processFrame(VideoCapture capture) {
try {
TENTATIVI
myAgent=MicroRuntime.getAgent(nick).getO2AInterface(ClientGUIInt.clas
} catch (StaleProxyException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (ControllerException e) {
//RECOVERY NEL CASO NON TROVA IL SUO AGENTE PER TROPPI
// TODO Auto-generated catch block
e.printStackTrace();
//imposta piattaforma dove effettuare il recovery
if(platform==0){
platform=1;
}
else{
platform=0;
}
Log.i("FdView", "Exception Platform Crash
t="+System.currentTimeMillis());
//caso platform 0
if (platform==0){
if(counterr++==4){
counterr=0;
RuntimeCallback
agentStartupCallback = new RuntimeCallback() {
@Override
public void onSuccess(AgentController
agent) {
}
throwable) {
}
};
@Override
public void onFailure(Throwable
125

Implementazione
//Piattaforma di recovery
((FdActivity)(getContext())).startSorveglianza("192.168.1.52","1099",
agentStartupCallback );
}
}
//caso platform 1
else{
if(counterr++==4){
counterr=0;
RuntimeCallback
agentStartupCallback = new RuntimeCallback() {
@Override
public void onSuccess(AgentController
agent) {
}
throwable) {
@Override
public void onFailure(Throwable
}
};
//Piattaforma di recovery
((FdActivity)(getContext())).startSorveglianza("192.168.1.192","1099"
,agentStartupCallback );
}
}
}//chiusa exception
capture.retrieve(mRgba, Highgui.CV_CAP_ANDROID_COLOR_FRAME_RGBA);
capture.retrieve(mGray, Highgui.CV_CAP_ANDROID_GREY_FRAME);
if (mCascade != null) {
//clear previous detected faces array
faces.clear();
//equalize gray image histogram
Imgproc.equalizeHist(mGray, mGray);
//invoke face detection algorithm, from a start face dimension
of 90x90
mCascade.detectMultiScale(mGray, faces, 1.3, 3, 0, DEFSIZE);
//search each face on history face detected array
for (Rect r : faces){
add=true;
for (CFace a : hFaces){
if (a.updatePos(r)) {
add=false;
break;
}
}
if (add) hFaces.add(new CFace(r)); //face not found into
history array, new face
if (develop) Core.rectangle(mRgba, r.tl(), r.br(), new
Scalar(0, 0, 0, 127), 1); //print a green rectangle around each face
}
//initialize array variables
newFace=null;
maxT=0;
126

Implementazione
hcopy.clear();
//for each faces into history faces array, removes old face
(not yet detected) and search dominant face (most time present)
for (CFace a:hFaces){
if (a.aging()){
hcopy.add(a);
} else if (a.findBest()) {
newFace=a;
}
}
hFaces.removeAll(hcopy);
//if a face was detected
if (newFace!=null){
if (develop) Core.rectangle(mRgba, newFace.pos.tl(),
newFace.pos.br(), new Scalar(255,0,0,255),2); //draws a red rectangle
around face
//draw a blue line next to the left angle of the dominant
face to visualize the set point on Z (=140 px)
CFace temp = new CFace(newFace.pos);
Point bo=temp.pos.tl();
bo.y+=130;
if (develop) Core.line(mRgba, newFace.pos.tl(),bo, new
Scalar(0,0,255,255), 4); //draws a red rectangle around face
if (dominantFace==null || newFace.id!=dominantFace.id ||
repeat>REPEAT_LIMIT){
//send face to server when first one detected or
new face or need to re-send
dominantFace=newFace;
repeat=0;
try{
waitResp=false;
//create bitmap image to send
dominant=Bitmap.createBitmap(mRgba.cols(),mRgba.rows(),Bitmap.Config.
ARGB_8888);
Utils.matToBitmap(mRgba, dominant);
dominant=Bitmap.createBitmap(dominant,
newFace.pos.x, newFace.pos.y, newFace.pos.width, newFace.pos.height);
//if (count++>120) count=0;
//dominantFace.id=count; //update face ID
ByteArrayOutputStream();
100, stream);
//trasforma immagine in byte
ByteArrayOutputStream stream = new
dominant.compress(Bitmap.CompressFormat.PNG,
byte[] bytes = stream.toByteArray();
//metto a false la variabile booleana
dell'agente e invio la richiesta
if(myAgent!=null){
myAgent.setArrivata(false);
//invia immagine
Log.i("FdView", "Calling agent method
Send Image t="+System.currentTimeMillis());
myAgent.sendImg(bytes);
127

Implementazione
}
sendImg=false;
REPEAT_LIMIT++;
waitResp=true;
faceCheck="";
}catch (Exception e) {Log.e(TAG,"bitmap error
"+e.toString());}
Log.i(TAG, "new Face ");
}else if (newFace.id==dominantFace.id &&
repeat

Implementazione
che la logica di analisi del video ha bisogno di inviare una richiesta, un nuovo behaviour
apposito per l’invio della richiesta viene creato in modo da non dover aspettare la risposta di
ogni richiesta e svincolare la logica di analisi dalle risposte alle richieste. Per il recupero delle
risposte che arrivano all’agente Android da parte della logica di elaborazione del video
necessarie alla FdView, è stato implementato un thread il cui compito è di controllare lo stato
della variabile booleana dell’agente Android che indica l’arrivo di una risposta di
identificazione e, tramite l’interfaccia dell’agente Adroid, recuperare la risposta:
class RecvThread extends Thread{
public void run(){
while (true){
try{
Thread.sleep(1);
if(myAgent!=null){
//caso è arrivata risposta di identificazione
if(myAgent.getArrivata()==true){
Thread.sleep(1);
Log.i("FdViewRecThread", "Risposta di
identificazione arrivata all'agente andorid e al receive thread
t="+System.currentTimeMillis());
String id=myAgent.getId();//recupero id
persona della risposta nell'agente
myAgent.setArrivata(false);//setto a false la
variabile arrivata dell'agente
if (REPEAT_LIMIT>15) REPEAT_LIMIT-=2;
if (id.equals("Andrea")){ //recognized
(wanted) face -> update current dominant face and show message
Log.i("FdViewRecThread", "Riconosciuto
t="+System.currentTimeMillis());
if (dominantFace!=null){
Log.i("FdViewRecThread",
"Riconosciuto dominantFace!=null t="+System.currentTimeMillis());
dominantFace.wanted();
faceCheck="WANTED";
}
}else{ //unknown face -> update current
dominant face
if (dominantFace!=null){
dominantFace.unknown();
faceCheck="";
Log.i("FdViewRecThread",
"Sconosciuto t="+System.currentTimeMillis());
}
}
}
}
}catch(Exception e){
//recovery nel caso sia distrutta la piattaforma
if(!MicroRuntime.isRunning()){
//System.out.println("Exception nel thread");
//prova a far ripartire l'agente nella
129

Implementazione
piattaforma di recovery
RuntimeCallback
agentStartupCallback = new RuntimeCallback() {
@Override
public void onSuccess(AgentController
agent) {
}
throwable) {
};
@Override
public void onFailure(Throwable
}
((FdActivity)(getContext())).startSorveglianza("192.168.1.92","1099",
agentStartupCallback );
}
else{
//System.out.println("Microruntime ancora
attivo");
}
}
}
Listato 4-25 Thread di controllo risposta di identificazione volti
Anche in questo caso, se il tentativo di recuperare l’informazione contenuta nell’agente
tramite l’interfaccia fallisce, la Jade Platform a cui era collegato l’agente viene ritenuta
guasta, quindi l’applicazione tenterà di ripristinare il servizio ricreando l’agente in un’altra
piattaforma di recovery.
130

5. Test e risultati
Per testare il sistema di videosorveglianza realizzato, sono stati effettuati due tipi di test, il
primo per misurare la variazione delle prestazioni di analisi del video rispetto l’applicazione
non agentificata, il secondo per misurare il tempo di latenza che l’applicativo Android
impiega per ripristinare il servizio in caso la piattaforma ad agenti smetta di funzionare.
5.1. Test sulle prestazioni di analisi del video
Per confrontare le prestazioni di analisi del video da parte dell’applicativo di
videosorveglianza agentificato con quelle dell’applicativo di inseguimento di volti fornitomi
dal Laboratorio di Intelligenza Artificiale e Sistemi in Tempo Reale non ad agenti, si è preso in
considerazione i frame per secondo (FPS) del flusso video analizzati dai due applicativi. I test
sono stati effettuati in simili condizioni di ambiente e stesso meccanismo di calcolo delle
prestazioni, ovvero:
public void measure() {
framesC++;
if (framesC % step == 0) {
time = Core.getTickCount();
fps = step * freq / (time - prevFrameTime);
prevFrameTime = time;
strfps = df.format(fps) + " FPS";
Log.i(TAG, strfps);
}
exTime=Core.getTickCount();
Log.i("ExecutionTime", ((exTime-prevExTime)/freq*1000)+ " ms");
prevExTime=exTime;
}
Listato 5-1 Log dell'execution time
Dall’analisi dei log è quindi possibile leggere il tempo di elaborazione dei frame e i FPS
elaborati, di seguito un estratto di 12 secondi dei risultati ottenuti:
131

11-06 11:36:42.065: I/ExecutionTime(6724):
152.86254799999998 ms
11-06 11:36:42.215: I/ExecutionTime(6724): 140.441896 ms
11-06 11:36:42.345: I/ExecutionTime(6724): 131.56128 ms
11-06 11:36:42.545: I/ExecutionTime(6724): 204.132078 ms
11-06 11:36:42.735: I/ExecutionTime(6724):
189.63623199999998 ms
11-06 11:36:42.835: I/ExecutionTime(6724): 95.550538 ms
11-06 11:36:42.905: I/ExecutionTime(6724): 74.310302 ms
11-06 11:36:43.025: I/ExecutionTime(6724): 121.490477 ms
11-06 11:36:43.126: I/ExecutionTime(6724): 98.846437 ms
11-06 11:36:43.216: I/ExecutionTime(6724):
89.96582000000001 ms
11-06 11:36:43.356: I/ExecutionTime(6724):
143.09692299999998 ms
11-06 11:36:43.466: I/ExecutionTime(6724): 103.790285 ms
11-06 11:36:43.566: I/ExecutionTime(6724):
105.95702999999999 ms
11-06 11:36:43.656: I/ExecutionTime(6724):
83.37402300000001 ms
11-06 11:36:44.006: I/ExecutionTime(6724): 350.433351 ms
11-06 11:36:44.077: I/ExecutionTime(6724):
75.04272300000001 ms
11-06 11:36:44.157: I/ExecutionTime(6724): 76.99585 ms
11-06 11:36:44.267: I/ExecutionTime(6724): 114.105226 ms
11-06 11:36:44.427: I/ExecutionTime(6724): 159.790039 ms
11-06 11:36:44.587: I/ExecutionTime(6724): 148.162839 ms
11-06 11:36:44.697: I/ExecutionTime(6724): 129.394532 ms
11-06 11:36:44.827: I/ExecutionTime(6724): 130.828858 ms
11-06 11:36:44.957: I/ExecutionTime(6724):
121.52099600000001 ms
11-06 11:36:45.017: I/ExecutionTime(6724): 69.610595 ms
11-06 11:36:45.118: I/ExecutionTime(6724): 93.048098 ms
11-06 11:36:45.198: I/ExecutionTime(6724):
80.81054499999999 ms
11-06 11:36:45.278: I/ExecutionTime(6724): 82.794189 ms
11-06 11:36:45.358: I/ExecutionTime(6724):
75.74463100000001 ms
11-06 11:36:45.458: I/ExecutionTime(6724): 91.735839 ms
11-06 11:36:45.538: I/ExecutionTime(6724):
90.91186499999999 ms
11-06 11:36:45.908: I/ExecutionTime(6724):
373.04687600000005 ms
11-06 11:36:46.048: I/ExecutionTime(6724): 129.913329 ms
11-06 11:36:46.209: I/ExecutionTime(6724): 164.337159 ms
11-06 11:36:46.309: I/ExecutionTime(6724): 95.306397 ms
11-06 11:36:46.449: I/ExecutionTime(6724):
138.73290899999998 ms
11-06 11:36:46.559: I/ExecutionTime(6724): 114.074708 ms
11-06 11:36:46.689: I/ExecutionTime(6724): 131.164551 ms
11-06 11:36:46.799: I/ExecutionTime(6724): 111.999511 ms
11-06 11:36:46.859: I/ExecutionTime(6724): 66.497802 ms
11-06 11:36:46.979: I/ExecutionTime(6724): 114.562988 ms
11-06 11:36:47.109: I/ExecutionTime(6724): 132.720947 ms
11-06 11:36:47.200: I/ExecutionTime(6724): 85.357668 ms
11-06 11:36:47.280: I/ExecutionTime(6724):
81.54296799999999 ms
11-06 11:36:47.360: I/ExecutionTime(6724): 85.29663 ms
11-06 11:36:47.440: I/ExecutionTime(6724):
76.20239199999999 ms
Test e risultati
11-06 11:36:47.530: I/ExecutionTime(6724):
97.07641699999999 ms
11-06 11:36:47.610: I/ExecutionTime(6724):
76.26342799999999 ms
11-06 11:36:48.010: I/ExecutionTime(6724):
399.78027199999997 ms
11-06 11:36:48.160: I/ExecutionTime(6724): 149.475099 ms
11-06 11:36:48.231: I/ExecutionTime(6724):
65.91796799999999 ms
11-06 11:36:48.341: I/ExecutionTime(6724): 107.940674 ms
11-06 11:36:48.501: I/ExecutionTime(6724): 164.947511 ms
11-06 11:36:48.601: I/ExecutionTime(6724): 95.642091 ms
11-06 11:36:48.751: I/ExecutionTime(6724): 151.275634 ms
11-06 11:36:48.841: I/ExecutionTime(6724): 94.726562 ms
11-06 11:36:48.991: I/ExecutionTime(6724):
151.70288100000002 ms
11-06 11:36:49.111: I/ExecutionTime(6724): 112.396239 ms
11-06 11:36:49.222: I/ExecutionTime(6724): 113.952638 ms
11-06 11:36:49.332: I/ExecutionTime(6724): 115.844726 ms
11-06 11:36:49.502: I/ExecutionTime(6724): 162.475586 ms
11-06 11:36:49.602: I/ExecutionTime(6724): 98.937988 ms
11-06 11:36:49.722: I/ExecutionTime(6724): 124.328614 ms
11-06 11:36:49.812: I/ExecutionTime(6724): 94.421386 ms
11-06 11:36:50.142: I/ExecutionTime(6724): 327.819824 ms
11-06 11:36:50.243: I/ExecutionTime(6724): 100.280761 ms
11-06 11:36:50.333: I/ExecutionTime(6724): 83.801271 ms
11-06 11:36:50.503: I/ExecutionTime(6724):
168.79272500000002 ms
11-06 11:36:50.693: I/ExecutionTime(6724): 195.159912 ms
11-06 11:36:50.953: I/ExecutionTime(6724):
257.69042800000005 ms
11-06 11:36:51.023: I/ExecutionTime(6724): 68.695069 ms
11-06 11:36:51.103: I/ExecutionTime(6724): 88.043213 ms
11-06 11:36:51.193: I/ExecutionTime(6724): 87.219238 ms
11-06 11:36:51.284: I/ExecutionTime(6724): 83.709717 ms
11-06 11:36:51.374: I/ExecutionTime(6724):
90.91186599999999 ms
11-06 11:36:51.454: I/ExecutionTime(6724):
87.34130800000001 ms
11-06 11:36:51.524: I/ExecutionTime(6724):
65.91796900000001 ms
11-06 11:36:51.664: I/ExecutionTime(6724):
138.27514599999998 ms
11-06 11:36:51.754: I/ExecutionTime(6724): 92.041015 ms
11-06 11:36:51.864: I/ExecutionTime(6724): 110.687257 ms
11-06 11:36:51.944: I/ExecutionTime(6724):
81.02417000000001 ms
11-06 11:36:52.254: I/ExecutionTime(6724): 301.971436 ms
11-06 11:36:52.325: I/ExecutionTime(6724):
78.03344600000001 ms
11-06 11:36:52.405: I/ExecutionTime(6724): 78.643799 ms
11-06 11:36:52.525: I/ExecutionTime(6724): 120.4834 ms
11-06 11:36:52.815: I/ExecutionTime(6724): 289.459227 ms
11-06 11:36:53.055: I/ExecutionTime(6724): 235.870362 ms
11-06 11:36:53.306: I/ExecutionTime(6724):
255.98144499999998 ms
11-06 11:36:53.426: I/ExecutionTime(6724):
116.24145499999999 ms
11-06 11:36:53.556: I/ExecutionTime(6724): 135.894776 ms
11-06 11:36:53.686: I/ExecutionTime(6724): 127.166747 ms
11-06 11:36:53.786: I/ExecutionTime(6724): 94.116212 ms
11-06 11:36:53.866: I/ExecutionTime(6724):
77.78930700000001 ms
11-06 11:36:53.996: I/ExecutionTime(6724):
134.82665899999998 ms
Tabella 5-1Risultati prestazioni analisi video
132

12
10
8
6
4
2
0
Test e risultati
1 2 3 4 5 6 7 8 9 10 11 12
Figura 5-1 Diagramma dei FPS ottenuto dall'estratto di 12 secondi dei test
Per chiarezza sono riportati solamente 12 secondi del test effettuato e in base ai risultati
ottenuti l’applicativo ad agenti di videosorveglianza effettua una analisi del video con una
media di 7,75 FPS. L’applicativo senza agenti ha un frame rate medio di 12 FPS, quindi
l’aggiunta del sistema ad agenti ha portato ad un rallentamento medio di 4,25 FPS all’analisi
del video. Un rallentamento dell’analisi video dovuta all’aggiunta del sistema ad agenti era
prevedibile, dato che l’applicativo è appesantito dal livello ad agenti aggiuntivo gestito dal
framework JADE, tuttavia un frame rate medio di 7,75 FPS è considerabile sufficiente per il
funzionamento dell’applicativo di videosorveglianza.
5.2. Test recovery del sistema di
videosorveglianza
Frame/s
Il vantaggio principale ottenuto dalla realizzazione del sistema di videosorveglianza
utilizzando la tecnologia ad agenti è il sistema di recovery. Tale sistema permette
all’applicativo Android di ripristinare il servizio di videosorveglianza nel caso di un
133

Test e risultati
malfunzionamento della macchina su cui è in esecuzione la piattaforma di videosorveglianza
ad agenti. Tale sistema prevede la presenza di più macchine in cui è in esecuzione
l’applicativo ad agenti di videosorveglianza, ma non prevede una gerarchia fra le piattaforme
ad agenti, dato che l’applicativo Android tenta di ripristinare il servizio di videosorveglianza
cercando di ricrearlo tramite una piattaforma fra quelle conosciute. Il dato che ci interessa
conoscere è il tempo che impiega l’applicativo Android a ripristinare il servizio in una seconda
piattaforma di videosorveglianza dopo che si è disattivata la piattaforma a cui era collegato.
Per ottenere questo dato è stato aggiunto un log nel catch dell’eccezione riguardante il
mancato recupero dell’agente Android ed effettuato spegnimenti delle piattaforme (anche
consecutive) contenenti gli agenti Android. Come risultato si ottiene una serie di catch delle
eccezioni che vengono lanciate nel frattempo che il servizio di videosorveglianza è sospeso,
quindi prendendo nota dell’istante in cui viene lanciata la prima e l’ultima eccezione si
ottiene il tempo di ripristino. Il risultato dei test è il seguente:
Ripristino1:
Istante del primo catch: 11-06 12:51:33.455
Istante ultimo catch: 11-06 12:51:33.716
Il primo ripristino è stato effettuato con successo in 261 ms.
Rispristino2:
Istante del primo catch: 11-06 13:13:40.200
Istante ultimo catch: 11-06 13:13:40.460
Il secondo ripristino è stato effettuato con successo in 260 ms.
Rispristino3:
Istante del primo catch: 11-06 13:28:23.482
Istante ultimo catch: 11-06 13:28:23.890
Il terzo ripristino è stato effettuato con successo in 408 ms.
Rispristino4:
134

Istante del primo catch: 11-06 13:30:46.081
Istante ultimo catch: 11-06 13:30:46.451
Test e risultati
Il quarto ripristino è stato effettuato con successo in 370 ms.
Rispristino5:
Istante del primo catch: 11-06 13:31:14.869
Istante ultimo catch: 11-06 13:31:15.199
Il quinto ripristino è stato effettuato con successo in 330 ms.
Rispristino6:
Istante del primo catch: 11-06 13:31:47.160
Istante ultimo catch: 11-06 13:31:47.531
Il sesto ripristino è stato effettuato con successo in 371 ms.
Quindi in media si è rilevata una sospensione dell’attività di videosorveglianza di soli 333 ms,
dopodiché il servizio è stato ripristinato nella prima piattaforma ad agenti di
videosorveglianza trovata disponibile.
135

6. Conclusioni e sviluppi futuri
Il sistema di videosorveglianza ad agenti che è stato sviluppato soddisfa i requisiti richiesti. L’
uso del framework JADE e dell’add-on JADE-LEAP si sono dimostrati un’ottima scelta per lo
sviluppo dell’architettura ad agenti, in quanto offre tutti gli strumenti di cui il sistema di
videosorveglianza ha bisogno ed è ben documentato. Anche l’uso dello smartphone Android
come simulazione di una più realistica telecamera di un sistema di videosorveglianza si è
dimostrato un ottimo strumento per testare idee innovative, dato che le proprietà raggiunte
dal sistema di videosorveglianza ad agenti che è stato sviluppato utilizzando uno smartphone
Android possono essere replicate in hardware più consoni all’obiettivo di videosorveglianza. I
risultati dei test suggeriscono un degrado delle prestazioni di analisi del video rispetto
all’applicazione non agentificata, degrado prevedibile dato dalla presenza di un livello
aggiuntivo rappresentato dall’architettura ad agenti e aggravato dal fatto che l’applicativo
Android di individuazione ed inseguimento dei volti non nasce con l’intento di utilizzare la
tecnologia ad agenti, quindi per il funzionamento del sistema di videosorveglianza ad agenti è
stato necessario accettare un compromesso fra l’applicativo Android e l’inserimento
dell’agente nel funzionamento. Molto buoni invece i risultati ottenuti dai test sul recovery del
sistema, l’architettura ad agenti e in particolare il framework JADE rende il sistema robusto a
guasti della macchina in cui è in esecuzione l’applicativo centrale, infatti l’applicativo Android
impiega poco più di 3 decimi di secondo per ricreare il suo agente in un’altra piattaforma di
videosorveglianza disponibile. Inoltre non vi è la necessità di imporre un ruolo di recovery a
nessuna piattaforma di videosorveglianza, l’applicativo Android nel caso rilevi
malfunzionamenti del suo agente, cerca di ricreare l’agente in una piattaforma di
videosorveglianza da lui conosciuta. Teoricamente nel caso in cui la piattaforma
precedentemente non funzionante riprendesse il corretto funzionamento, il servizio
potrebbe tornare operativo su tale piattaforma. Buona anche la scalabilità del sistema, dato
che aggiungere o rimuovere telecamere è immediato e non comporta alcuna modifica del
codice. Nel caso ci fossero molte telecamere da gestire e quindi maggiore capacità di calcolo
136

Conclusioni e sviluppi futuri
richiesta alla macchina su cui è in esecuzione l’applicativo, è sufficiente aggiungere
l’esecuzione dell’applicativo centrale su un’altra macchina e federare le piattaforme presenti,
in modo da poter permettere una comunicazione fra tutti gli agenti della videosorveglianza.
In conclusione, considerando una perdita accettabile del frame rate dell’applicativo Android
ad agenti, la quale è senza dubbio migliorabile programmando l’intera applicazione ad
agenti, si hanno grandi vantaggi dall’uso degli agenti software nell’ambito della
videosorveglianza, quali la robustezza, la scalabilità e una grande facilità nel gestire aggiunte
o eliminazioni di telecamere. Molto interessanti gli sviluppi che si possono effettuare in
futuro, in primo piano una riprogrammazione completamente ad agenti dell’applicativo
Android, il quale favorirà sicuramente sulle prestazioni del sistema. Inoltre si potrebbe
implementare un sistema intelligente di bilancio del carico di lavoro fra le macchine in cui è
in esecuzione l’applicativo centrale. Nel caso un agente Android rilevi un tempo di risposta
alto alle richieste di identificazione del volto, potrebbe decidere di effettuare le richieste ad
un’altro agente manager, decidendo quale sia il prossimo agente manager a cui inviare le
richieste attraverso il protocollo FIPA Contract-Net. Gli agenti manager presenti invieranno
come proposta il dato relativo al loro carico di lavoro, in modo tale che l’agente Android
possa poi decidere quale sia il migliore a cui inviare le richieste. Per stimare il carico di lavoro
attuale di un agente manager, si potrebbe utilizzare la differenza di tempo media fra le
ultime richieste di identificazione volti e il numero di telecamere gestite dall’agente
attualmente. Si potrebbe migliorare l’attuale applicativo di videosorveglianza
implementando una interfaccia grafica all’applicazione centrale, che permetta la visione di
ciò che le telecamere stanno al momento riprendendo e lo storico delle persone riconosciute
da una determinata telecamera, quindi la possibilità di ricercare una persona all’interno delle
informazioni registrate. Inoltre se ogni telecamera avesse l’informazione relativa al luogo in
cui è posizionata, possono essere possibili ricostruzioni sugli spostamenti delle persone
individuate. Infine, un’altra interessante idea per il futuro, sarebbe quella di utilizzare gli
agenti software per analisi del video più intelligente, ovvero in grado di comprendere cosa
succede nelle inquadrature delle videocamere di videosorveglianza e rilevare in autonomia
comportamenti sospetti. Per poter effettuare questa analisi non sarà più sufficiente spedire
l’immagine del volto all’applicazione centrale, ma bisognerà riconoscere ed inviare
137

Conclusioni e sviluppi futuri
l’immagine relativa all’intero corpo della persona, dopodiché l’applicativo centrale la dovrà
analizzare con un sistema di intelligenza artificiale in grado di dedurre un significato alle
azioni delle persone identificate.
138

AppendiceA Software
In questa Appendice vengono riportate le versioni dei software e librerie del framework JADE
utilizzati nello sviluppo del sistema di videosorveglianza ad agenti.
Programmazione dell’applicazione Android
• Eclipse IDE for Java Developers, INDIGO (v. 3.7.1)
• Android SDK r16;
• ADT Plugin per Eclipse;
• Android 2.3.3 (API 10) SDK Platform e Google APIs by Google Inc. (API 10), installati tramite
l’Android SDK Manager.
•JadeAndroid.jar
Programmazione del software per PC
• Eclipse IDE for Java Developers, INDIGO (v. 3.7.1); lo stesso usato per Android;
• Java JDK 1.6.0_27.
• jade.jar
• commons-codec-1.3.jar
139

Ringraziamenti
Ricordo come se fosse ieri il giorno in cui passai il mio primo esame, Fondamenti di
informatica. Quel giorno rappresentava un bivio, se non passavo l’esame di informatica non
mi sarei ritenuto all’altezza dell’università e non l’avrei mai fatta, se lo passavo sapevo che
sarebbe stato l’inizio di uno dei periodi più importanti della mia vita. Passai l’esame, uscii
dalla Facoltà e guardai la torre, le bandiere, l’emozione di quel momento me la ricorderò
sempre. Ora che è terminato questo periodo della mia vita, posso dire che sono fiero del
percorso di crescita personale che ho fatto durante questi anni, percorso che per me
rappresenta l’esame più difficile e bello che l’università mi ha offerto. Ho toccato punte di
felicità e tristezza indimenticabili, degno di un periodo che è stato vissuto. Cominciano quindi
i ringraziamenti verso le persone che hanno condiviso con me questi momenti. Per primo, un
ringraziamento speciale a me stesso, visto che non me lo dico mai. Ringrazio i miei genitori e
né approfitto per dire loro che gli voglio bene, visto che non glielo dico mai. Ringrazio mia
sorella Aurora, una delle persone che mi capisce più di tutte e a cui voglio bene in modo
particolare, anche se non glielo dico mai. Ringrazio Refo, voglio dirti che sono proprio
fortunato ad avere un amico come te, che poi per me ormai sei più di un amico, dal 1991 sei
Refo. Ringrazio Silvia, nel bene e nel male, sei stata sicuramente la persona più importante di
questo periodo. Ringrazio tutti i miei amici con cui ho trascorso questi anni di Università, in
modo particolare Rama e Marco, spero di non perdere mai il contatto con voi. Le giornate
all’università non sarebbero state le stesse senza Filippo, Giordi, Favo e Gigli, siete uno
spasso. Ringrazio Andrea, perché mi hai fatto passare una splendida estate, un’estate per me
fondamentale che non scorderò mai. Ringrazio tutti i miei amici storici, di sempre, che anche
se da tempo vedo molto poco, per me sono sempre importanti. Ringrazio Carla, perché ha
condiviso con me Frank e mi ha aiutato ad entrare in un mondo che non conoscevo. Ringrazio
il violino, la cosa che amo di più e con più certezza, che ultimamente mi ha anche permesso
di ritrovare belle persone come Maddalena e Giulia. Ringrazio ancora tutte le persone che
hanno condiviso con me questo bel periodo e che non ho specificato. Un pensiero particolare
và al Prof. Aldo Franco Dragoni, relatore di questa tesi, della tesi che feci alla triennale e
140

professore degli esami più belli che ho sostenuto in questa Università. Un pensiero anche ai
suoi assistenti Luca e Gianluca che mi hanno aiutato durante la realizzazione di questo lavoro
di tesi. Ora si apre un altro capitolo, ho bisogno di riprovare quell’emozione sentita quando
ho passato il primo esame, cercandola nel mondo del lavoro, cercandola accompagnato dalla
sinfonia “Dal Nuovo Mondo” di Dvořák.
141

Bibliografia
[1]. Tratto da http://www.videosorveglianza.eu.com/
[2]. Developing Multi-Agent Systems with JADE, Fabio Bellifemine, Telecom Italia, Italy
Giovanni Caire, Telecom Italia, Italy Dominic Greenwood, Whitestein Technologies AG,
Switzerland.
[3]. Tratto da FIPA, Foundation For Intelligent Physical Agents, “Specifications and
Documentation”: http://www.fipa.org/
[4]. Tratto da Il sistema operativo Android: http://www.android.com
[5]. Android Programming, PuntoInformatico EdizioniMaster.
[6]. LEAP USER GUIDE, Authors: Giovanni Caire (TILAB ex CSELT).
[7]. JADE TUTORIAL JADE PROGRAMMING FOR ANDROID, Authors: Giovanni Caire (Telecom
Italia S.p.A.) Giovanni Iavarone (Telecom Italia S.p.A.).
[8]. Tratto da Papers & resources : http://jade.tilab.com/
[9]. Tratto da The Eclipse Foundation open source community website.:
http://www.eclipse.org/
[10]. Integrazione di Jade in Eclipse, Luca Palazzo.
[11]. Tratto da ADT Plugin per Eclipse: http://developer.android.com/tools/sdk/eclipseadt.html
[12]. Progettazione e realizzazione di un sistema real-time per l’inseguimento di volti
mediante robot e smartphone Android, Simone Saraceni.
[13]. JADE ADMINISTRATOR’S GUIDE, Fabio Bellifemine, Giovanni Caire, Tiziana Trucco (TILAB
S.p.A., formerly CSELT) Giovanni Rimassa (FRAMeTech s.r.l.), Roland Mungenast (PROFACTOR
GmbH) .
[14]. Tratto da http://developer.android.com/training/basics/firstapp/creating-project.html
[15]. ESTRAZIONE E RICONOSCIMENTO DI VOLTI DA FILMATI, Gianluca Dolcini.
142