UNIVERSITÀ POLITECNICA DELLE MARCHE

Transcript

1 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 Tesi di: Andrea Baldini Correlatori: Dott. Gianluca Dolcini Dott. Luca Palazzo Anno Accademico 2011/2012

2

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

4

5 Indice 1. Introduzione Stato dell arte Obiettivi della tesi Struttura Ambiente di sviluppo Gli agenti software Sistemi Multi-Agente Architetture sistemi Multi-Agente Lo standard FIPA FIPA Request Interaction Protocol Specification FIPA Contract Net Interaction Protocol Specification FIPA Agent Management Specification FIPA-ACL FIPA Comunicative Act Library Specification FIPA SL Content Languages Specification FIPA Agent Message Transport Service Specification JADE: Java agent development environment Architettura JADE Message Transport Service IMTP ( Internal Message Transport Protocol ) Special agents JADE Packages Classe Agent Comportamenti degli agenti Protocolli di interazione Supporto alle ontologie v

6 2.7. Android Basi della programmazione Android JADE-LEAP Jade-Leap runtime environment Split execution JADE-based Android application Integrazione di JADE e Android in Eclipse Progettazione del sistema Software di partenza Analisi dei requisiti Architettura del sistema Agente Android Agente Manager L ontologia per il servizio di videosorveglianza Implementazione Implementazione ontologia Implementazione applicazione centrale Struttura applicazione videosorveglianza Avvio applicazione videosorveglianza Implementazione agente manager Implementazione applicazione Android File AndroidManifest.xml e struttura applicazione Creazione agente Android Implementazione agente Android Interazione agente e logica di elaborazione del video Test e risultati Test sulle prestazioni di analisi del video Test recovery del sistema di videosorveglianza Conclusioni e sviluppi futuri AppendiceA Software vi

7 Ringraziamenti Bibliografia vii

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

9 Figura 3-8 Ontologia del sistema di videosorveglianza Figura 4-1 Struttura applicazione Videosorveglianza Figura 4-2 Avvio applicazione videosorveglianza visto dalla GUI dell'rma Figura 4-3 Struttura applicazione Android Figura 5-1 Diagramma dei FPS ottenuto dall'estratto di 12 secondi dei test ix

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

11 Elenco dei listati Listato 3-1 Metodo run() di CvBaseView Listato 3-2 Metodo processframe() di FdView Listato 4-1 Concept Acknowledge Listato 4-2 AgentAction ConfermaFunzionamento Listato 4-3 Concept Immagine Listato 4-4 Concept Identita Listato 4-5 AgentAction Identifica Listato 4-6 Ontologia Videosorveglianza Listato 4-7 Avvio applicazione videosorveglianza Listato 4-8 Metodo setup() dell'agente manager Listato 4-9 Metodo register() dell'agente manager Listato 4-10 Metodo deregister() dell'agente manager Listato 4-11 Implementazione interfaccia dell'agente manager Listato 4-12 Behaviour DFRegistraManager Listato 4-13 behaviour ControllaAckcyclic Listato 4-14 Behaviour ControllaAck Listato 4-15 Behaviour RespondImage Listato 4-16 File AndoridManifest.xml Listato 4-17 Creazione agente Android Listato 4-18 Metodo oncreate() di FdActivity Listato 4-19 Metodo setup() dell'agente Android Listato 4-20 Interfaccia agente Android Listato 4-21 Behaviour DFRegistraCamera Listato 4-22 Behaviour RispondiAck Listato 4-23 Behaviour SendImage Listato 4-24 Metodo processframe() con interazione agente Android Listato 4-25 Thread di controllo risposta di identificazione volti Listato 5-1 Log dell'execution time xi

12 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

13 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

14

15 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

16 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

17 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

18 Introduzione 1.3. Struttura 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

19 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

20 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

21 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 Incapsula uno stato e lo controlla attraverso i metodi. Passivo, non ha controllo sull esecuzione dei metodi. Non autonomo. Agente Incapsula uno stato e lo controlla attraverso i metodi ed i suoi obiettivi. Attivo, decide quando e come agire. 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

22 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

23 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 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

24 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

25 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

26 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

27 Ambiente di sviluppo Application Abstract Architecture Agent Communication Agent Management Agent Message Transport Figura 2-4 Raggruppamenti delle specifiche FIPA Application 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

28 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

29 Ambiente di sviluppo AgentComunication 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 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 conversationid 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

30 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

31 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 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

32 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

33 Ambiente di sviluppo Figura 2-6 FIPA ContractNet Interaction Protocol 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

34 Ambiente di sviluppo AP - Agent Platform 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: Figura 2-7 Agent Platform Agent 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

35 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 Wait Resume SUSPENDED Wake up ACTIVE Suspend Destroy Unknown Move Invoke Quit Create TRANSIT Execute INITIATED Comportamento caratteristico degli agenti mobilitipo di Figura Ciclo di vita di un agente Agent Management System È 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 21

36 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

37 Ambiente di sviluppo Presenta delle sottosezioni: 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 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

38 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 Categorie dei Parametri performative Denotes the type of the communicative act of the ACL message Tipo di atto comunicativo sender Denotes the identity of the sender of the message, that is, the name of the agent of the communicative act. Participante alla communicazione receiver Denotes the identity of the intended recipients of the message. Participante alla communicazione reply-to 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. Participante alla communicazione Content 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. Contenuto del messaggio language Denotes the language in which the content parameter is expressed. Descrizione del contenuto encoding Denotes the specific encoding of the content language expression. Descrizione del contenuto ontology Denotes the ontology(s) used to give a meaning to the Descrizione del 24

39 Ambiente di sviluppo symbols in the content expression. contenuto protocol Denotes the interaction protocol that the sending agent is employing with this ACL message. Controllo della conversazione conversation-id 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 reply-with Introduces an expression that will be used by the responding Controllo della agent to identify this message. conversazione in-reply-to Denotes an expression that references an earlier action to which this message is a reply. Controllo della conversazione reply-by Denotes a time and/or date expression which indicates the latest time by which the sending agent would like to receive a reply. Controllo della conversazione Tabella 2-1 Parametri del messaggio FIPA-ACL FIPA Comunicative Act Library Specification 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

40 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 Agree Call for Proposal Failure Inform Not Understood Propose Refuse Reject Proposal Request Indica che si accetta una proposta precedentemente ricevuta di eseguire una certa azione Indica che si acconsente ad eseguire qualche azione eventualmente in futuro Indica che si attendono proposte per l esecuzione di una certa azione Comunica il fallimento del tentativo di eseguire una certa azione Il mittente informa il destinatario che una data proposizione è vera 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. Comunica una proposta di eseguire una certa azione sotto determinate condizioni Comunica il rifiuto ad eseguire un azione e la motivazione Indica il rifiuto di una proposta durante un processo di negoziazione Il mittente chiede al destinatario di compiere una certa azione Tabella 2-2 Atti comunicativi e significato 26

41 Ambiente di sviluppo 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

42 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 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

43 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 The names of the primary recipients of the message. If no intended-receiver to parameter is present, then the information in this parameter is used to generate intended-receiver field for the messages the ACC subsequently forwards. from comments 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. Text comments. acl-representation The syntax representation of the message payload. This information is intended for the final recipient of the message. payload-length The length in bytes of the message payload. The ACC may use this information to improve parsing efficiency. payload-encoding The language encoding of the message payload. This information is intended for the final recipient of the message. date intended-receiver 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

44 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 received transport-behaviour 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. 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

45 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

46 Ambiente di sviluppo 2.6. JADE: Java agent development environment 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

47 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

48 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 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

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

50 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 ) 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

51 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 Special agents RMA agent L RMA implementa l interfaccia del sistema per il management della piattaforma. Fornisce un interfaccia grafica per amministrare una piattaforma composta da più container e da più agenti; diversi RMA possono esser lanciati purchè abbiano nomi diversi. In fase di start-up questo agente si sottoscrive all AMS per esser notificato su tutti gli eventi della piattaforma. La figura 2.10 illustra l interfaccia grafica dell RMA. ([13]) Figura 2-10 GUI dell'agente RMA Dummy agent Questo agente permette di inviare stimoli ad un agente sottoforma di messaggi ACL e valutare il suo comportamento in base alle risposte che vengono ricevute. E possibile 37

52 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

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

54 Ambiente di sviluppo 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

55 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 <localname>@<platform-name>. 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

56 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); 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

57 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

58 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 subbehaviours 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 subbehaviours in accordo ad una macchina a stati finiti (Finite State Machine, FSM) definita dall utente. Ogni sub-behaviour rappresenta un attività dentro uno 44

59 Ambiente di sviluppo stato della FSM e l utente può definire le transizioni fra gli stati della FSM. Quando il figlio corrispondente allo stato S i termina, il suo valore di ritorno (restituito dal metodo onend() ) viene utilizzato per determinare la transizione ed un nuovo stato S j 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 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

60 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, FIPArecruiting, 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

61 Ambiente di sviluppo ContractNetInitiator: 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) 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

62 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

63 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

64 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

65 Ambiente di sviluppo 2.7. Android 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

66 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

67 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 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

68 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

69 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. <?xml version="1.0" encoding="utf-8"?> <resources> <!-- valori qui --> </resources> All interno del tag <resources>... </resources> è possibile dichiarare differenti tipi di valori. Ci sono numerosi tipi di dati supportati. Ecco un elenco completo: Stringhe, con il tag <string>. Colori, con il tag <color> Misure e dimensioni, con il tag <dimen> Stili e temi, con il tag <style> Rettangoli di colore, con il tag <drawable> Array di interi, con il tag <integer-array> Array di stringhe, con il tag <string-array> 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

70 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

71 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

72 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 <activity> all interno del tag <application>. 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 <manifest> sovrastante (ad esempio.myactivity). All interno della coppia di tag <activity>... </activity>, 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

73 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 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

74 Ambiente di sviluppo Mostra sullo schermo l oggetto View specificato, applicando una serie di parametri di visualizzazione ed organizzazione del componente (params) 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 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

75 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

76 Ambiente di sviluppo Figura 2-19 Architettura JADE Leap 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

77 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

78 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 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. <application... android:name="chatapplication"> <service android:name="jade.android.microruntimeservice" />... </application> 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

79 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<Void>() public void onsuccess(void thisisnull) { // Split container startup 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<Void>() public void onsuccess(void thisisnull) { // Agent successfully 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

80 Ambiente di sviluppo interfaccia introdotta nella versione 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 { public void onreceive(context context, Intent intent) { String action = intent.getaction(); if (action.equalsignorecase("jade.demo.chat.refresh_chat")) { 66

81 Ambiente di sviluppo TextView chatfield = (TextView) findviewbyid(r.id.chattextview); chatfield.append(intent.getextras().getstring("sentence")); scrolldown(); 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

82 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 <default_package> dà problemi con Jade, meglio rimuoverlo) - Cliccare con il tasto destro sulla cartella del progetto ed aprire la finestra Run Configurations: 68

83 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

84 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

85 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 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

86 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

87 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

88 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<=repeat_limit){ //on same dominant face, count time until re-send to server repeat++; else { //no dominant faces, reset variables dominantface=null; dominant=null; sendimg=false; waitresp=false; repeat=0; 74

89 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

90 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

91 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

92 Progettazione del sistema Requisiti non funzionali: Uso del framework Jade 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 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

93 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

94 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

95 Progettazione del sistema 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

96 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

97 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

98 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

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

100 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 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

101 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

102 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

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

104 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 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

105 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

106 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 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

107 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

108 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

109 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

110 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

111 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 Struttura applicazione videosorveglianza L applicazione videosorveglianza è suddivisa nei seguenti 4 package: Comportamenti Manager Ontology Startapp 97

112 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

113 Implementazione 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