Gian Luca Pozzato

AgentSpeak (L) & Jason AgentSpeak(L): linguaggio di programmazione per agenti BDI introdotto da Rao nel 1996 Si propone di colmare il gap tra specifica teorica ed implementazione di un agente BDI Jason è la prima significativa implementazione di AgentSpeak(L), realizzata in Java da Bordini e Hubner

Gli agenti BDI vengono da sempre trattati da due punti di vista: - specifica teorica; - implementazione. Il gap tra teoria e pratica resta eccessivo Causa principale: complessità del theorem proving e del model checking delle logiche usate per formalizzare i BDI agents AgentSpeak (L) & Jason

Le implementazioni esistenti utilizzano strutture dati per rappresentare Belief, Desires e Intentions, invece che gli operatori modali [Rao96] introduce una formalizzazione alternativa degli agenti BDI: AgentSpeak(L) AgentSpeak(L): architettura per agenti e linguaggio di programmazione AgentSpeak(L) come estensione della programmazione logica per supportare l’architettura BDI

IN QUESTA PRESENTAZIONE: Breve introduzione AgentSpeak(L): linguaggio e funzionamento dell’interprete col sussidio di un esempio Jason Conclusioni e alcuni riferimenti utili

Introduzione

Agenti BDI: sistemi collocati in un ambiente dinamico, che muta nel tempo; sistemi in grado di percepire informazioni provenienti dall’ambiente; sistemi in grado di compiere delle azioni (ed apportare modifiche all’ambiente) sulla base delle proprie attitudini mentali: beliefs, desires e intentions sono le principali attitudini.

Agente AgentSpeak(L)Ambiente esterno Percezione Azione

Beliefcomponente di informazione Desirecomponente motivazionale Intentioncomponente decisionale cattura Principali attitudini mentali di un agente BDI

Per formalizzare queste nozioni sono state impiegate logiche multi-modali, temporali, dinamiche e action logics. Tuttavia, la complessità del theorem proving e del model- checking di tali logiche non è ancora chiara ([Rao95] e [RaoGeo91]). Aspetto teorico

Sono state proposte molte implementazioni di agenti BDI; tali implementazioni sono state impiegate con successo in molti domini applicativi considerati critici; [BurSun92], [GeoLan86], [MulPisThi95] e [Sho93] sono alcuni esempi; in questi sistemi, piani e programmi scritti dagli utenti permettono di migliorare l’efficienza della computazione. Aspetto pratico (I)

Le implementazioni sono caratterizzate da assunzioni che semplificano le definizioni di belief, desire e intention, in modo da modellare tali attitudini con maggiore facilità; le basi teoriche che supportano tali sistemi sono deboli. Aspetto pratico (II)

PROBLEMA: grosso gap tra teoria e pratica. SOLUZIONE DI RAO: AgentSpeak(L).

Si parte da un sistema BDI implementato e si formalizza la sua semantica operazionale; il sistema considerato è il PRS (Procedural Reasoning System) e la sua evoluzione dMARS (Distributed Multi- Agent Reasoning System); AgentSpeak(L) può essere visto come una versione semplificata e testuale di PRS o dMARS (questi ultimi offrono semplicemente più costrutti per facilitare la programmazione di agenti, ma i linguaggi e le rispettive semantiche operazionali sono simili nei loro dettagli essenziali).

Linguaggio di programmazione basato su un linguaggio del primordine semplificato, con eventi e azioni; il comportamento di un agente (ossia, le sue interazioni con l’ambiente) è dettato dai programmi scritti in AgentSpeak(L); beliefs, desires ed intentions NON sono rappresentati esplicitamente con formule modali, bensì il progettista attribuisce tali nozioni all’agente usando il linguaggio AgentSpeak(L). AgentSpeak(L)

Current belief state dell’agente: modello di sé stesso, dell’ambiente e degli altri agenti; Desires: stati che l’agente vuole raggiungere (sulla base di stimoli interni o esterni); per la precisione, AgentSpeak(L) fa riferimento ai Goals, che si possono intendere come Desires adottati/scelti; Intentions: adozione di programmi per soddisfare certi stimoli. AgentSpeak(L)

Il linguaggio AgentSpeak(L)

Linguaggio testuale per scrivere programmi per agenti Nozioni di base beliefs (analoghi ai fatti della programmazione logica), piani, azioni, intentions, eventi, goals Piani:  Context sensitive  Possono essere invocati dall’utente  Consentono una decomposizione gerarchica dei goals  Sintatticamente simili alle clausole della programmazione logica (anche se con un diverso comportamento)

Variabili Costanti Simboli funzionali Simboli predicativi Simboli di azione Connettivi Quantificatori Simboli di punteggiatura Alfabeto del linguaggio formale

della logica del primordine: - & (congiunzione Λ) - not (negazione ¬) - <- (implicazione ←) ! Achievement ? Test ; Sequenza Connettivi

Termini Formule Le variabili del linguaggio sono caratterizzate dall’iniziale maiuscola Definizioni della logica del primordine

Il linguaggio AgentSpeak(L) Nozioni del linguaggio

Def 1 [Belief atom] : sia b un simbolo predicativo e siano t 1, …, t n termini. Allora: b(t 1, …, t n ) è un belief atom e si scrive anche b(t). Belief atom Un belief atom e la sua negazione sono detti belief literal Un belief atom ground (=senza variabili con occorrenze libere) è detto base belief

Belief Def 1b [Belief] : siano b(t) e c(s) belief atoms; allora b(t) Λ c(s) ¬ b(t) sono beliefs. Istanze ground di beliefs si dicono base beliefs.

Esempio Consideriamo la seguente simulazione: 4 corsie adiacenti Le corsie possono essere percorse da automobili In ciascuna corsia può essere presente della spazzatura Il robot deve raccogliere la spazzatura e depositarla nel cestino, posizionato in una delle 4 corsie Mentre pulisce, il robot NON deve trovarsi in una corsia in cui è presente un’auto, per evitare di essere distrutto Vogliamo scrivere il programma per l’agente che guida il robot nella sua attività.

abcd Agente AgentSpeak(L)Ambiente esterno Percezione Azione

I beliefs rappresentano informazioni su: Configurazione delle corsie Posizionamento del robot Posizione delle auto nelle corsie Posizione del cestino per la raccolta dei rifiuti Ad esempio: adjacent(X,Y) location(robot,X) location(car,X)

I base beliefs (=istanze ground di belief atoms) sono, ad esempio: adjacent(a,b) location(robot,c)

Goal E’ uno stato del sistema che l’agente vuole raggiungere 2 tipi di goal:  Achievement goal  Test goal

Achievement goal: Della forma: !g(t) L’agente vuole raggiungere uno stato in cui g(t) è un belief VERO Test goal: Della forma: ?g(t) L’agente vuole verificare se la formula g(t) è un belief VERO o FALSO

Def 2 [Goal] : sia g un simbolo predicativo e siano t 1, …, t n termini. Allora: !g(t 1, …, t n ) ( oppure !g(t) ) è un achievement goal; ?g(t 1, …, t n ) ( oppure ?g(t) ) è un test goal. Goal

Esempio: !cleared(b) : l’agente vuole pulire la corsia b ?location(car,b) : l’agente vuole verificare l’eventuale presenza di un’auto nella corsia b Goal

Triggering event Quando un agente acquisisce un nuovo goal oppure nota una modifica nell’ambiente, esso può far scattare aggiunte o cancellazioni di goals o beliefs Questi eventi vengono detti triggering events Possibili triggering events:  Aggiunta di un belief  Aggiunta di un goal  Rimozione di un belief  Rimozione di un goal

Triggering event L’aggiunta di un belief/goal è rappresentata dall’operatore + La rimozione di un belief/goal è rappresentata dall’operatore – Esempi di triggering events: Notare la presenza di spazzatura nella corsia X è denotato con il triggering event: +location(waste, X) Acquisire il goal di ripulire una certa corsia è denotato con il triggering event: +!cleared(X)

Def 3 [Triggering event] : sia b(t) un belief atom e siano !g(t) e ?g(t) goals. Allora: 1.+b(t) 2.-b(t) 3.+!g(t) 4.-!g(t) 5.+?g(t) 6.-?g(t) sono triggering events. Triggering event

Azione Scopo di un agente: Osservare l’ambiente e, sulla base di tali osservazioni e dei propri goals, eseguire determinate azioni Le azioni compiute dall’agente possono modificare lo stato dell’ambiente

Azione Esempio: Se move è un simbolo di azione, move(X,Y) è un’azione e rappresenta lo spostamento del robot da X a Y e ha l’effetto di modificare lo stato dell’ambiente. Il robot si trova nella corsia Y e non più nella corsia X

Def 4 [Azione] : sia a un simbolo di azione e siano t 1,…, t n termini. Allora a(t 1,…, t n ) è un’azione. Azione

Piano Un piano specifica il modo in cui un agente potrebbe raggiungere un determinato obiettivo := ← := : triggering event specifica perché il piano è stato attivato, ossia l’aggiunta/rimozione di un belief o di un goal che tale piano si propone di gestire context specifica quali beliefs dovrebbero essere soddisfatti nel set delle credenze dell’agente quando il piano è attivato (scatta)

Piano := ← := : body è una sequenza di goals o azioni e specifica:  i goals che l’agente vuole raggiungere (achievement goals) o testare (test goals);  le azioni che l’agente deve eseguire true rappresenta un componente vuoto (context o body)

Piano Esempio: piano che scatta quando la spazzatura si viene a trovare in una certa corsia; se il robot si trova in tale corsia: Raccoglie la spazzatura; Si pone l’obiettivo (achievement goal) di raggiungere il cestino; Getta via la spazzatura.

Piano Un possibile piano (P1): +location(waste, X): location(robot,X) & location(bin,Y) <- pick(waste); !location(robot, Y); drop(waste).

Piano Esempio: piano per consentire al robot di spostarsi fra le corsie. Il robot ha l’obiettivo di raggiungere la corsia X, senza dover fare altre operazioni. Se non si trova nella corsia X, il robot deve individuare una corsia Z che sia: Adiacente alla corsia in cui si trova attualmente Non percorsa da auto quindi, deve spostarsi in tale corsia.

Piano Piano (P2): +!location(robot,X): location(robot,X) <- true. Piano (P3): +!location(robot,X): location(robot,Y) & (not (X = Y)) & adjacent(Y,Z) & (not (location(car,Z))) <- move(Y,Z); +!location(robot,X).

Def 5 [Piano] : siano: e un triggering event; b 1,…,b m belief literals; h 1,…,h n goals o azioni allora e: b 1 Λ … Λ b m ← h 1 ; … ; h n è un piano. La parte a sinistra di ← è detta head, la parte a destra è detta body. La parte a destra dei : nella head è detta context. Un body vuoto viene riscritto per convenzione con true. Piano

Progetto di un agente Le nozioni introdotte finora completano la specifica di un agente; Il progettista specifica un agente scrivendo:  Un insieme di base beliefs;  Un insieme di piani. Il progetto di un agente è, pertanto, del tutto simile alla scrittura di un programma logico, con la definizione di:  Un insieme di fatti;  Un insieme di regole. (ma con differenze)

Il linguaggio AgentSpeak(L) La semantica operazionale

A run-time un agente può essere visto come costituito da:  Un set di beliefs B;  Un set di piani P;  Un set di intentions I;  Un set di eventi E;  Un set di azioni A;  Un set di funzioni di selezione: S ε, S O, S I Descriviamo informalmente il funzionamento di un agente AgentSpeak(L)…

abcd Agente AgentSpeak(L)Ambiente esterno Percezione Azione

Belief base location(robot,b). adjacent(a,b). Eventi Piani +!location(robot,X): location(robot,X)<- true. Unifica evento Unifica contesto Evento selezionato Piani rilevanti Piani applicabili SOSO Intended means Intentions SISI Esecuzione intention SεSε Evento esterno: nuova intention Evento interno: push Azione Achievement goal Test goal true abcd Interni o Esterni +!goal -!goal +belief -belief Belief Revision Function

Viene generato un triggering event quando un agente nota una modifica nell’ambiente circostante oppure quando un utente esterno chiede all’agente di raggiungere un goal Gli eventi possono essere:  Esterni (modifica dell’ambiente)  Interni (modifica dello stato dell’agente) Gli eventi vengono aggiunti al set E S ε seleziona in E un evento E 0 da processare E 0 viene rimosso da E e viene usato per unificare con i triggering events dei piani del set P

I piani i cui triggering events unificano con E 0 sono detti piani rilevanti; l’unificatore è detto unificatore rilevante L’unificatore rilevante è applicato al contesto dei piani rilevanti Una correct answer substitution è ottenuta dal contesto Per alcuni piani le condizioni dei contesti risultano essere conseguenze logiche del set dei base beliefs B: questi piani sono detti piani applicabili mediante un unificatore applicabile L’unificatore applicabile risulta dalla composizione della correct answer substitution con l’unificatore rilevante

Dato un evento E 0, diversi piani/opzioni risultano applicabili La funzione di selezione S O sceglie uno di questi piani/opzioni che chiamiamo P o Applicando l’unificatore applicabile a P o si ottiene l’intended means in risposta al triggering event Ogni intention è uno stack di piani parzialmente istanziati o intention frames

Evento esterno: l’intended means è usato per creare una NUOVA INTENTION, che viene aggiunta al set I Evento interno: l’intended means è inserito in cima all’intention ESISTENTE che ha “fatto scattare” (triggered) l’evento interno (per raggiungere un goal)

La funzione di selezione S I sceglie una intention da eseguire Quando l’agente esegue una intention, esegue il primo goal o azione del body del top del’intention:  Eseguire un achievement goal equivale a generare un evento interno per aggiungere il goal alla corrente intention;  Eseguire un test goal equivale a trovare una sostituzione per il goal che lo renda una conseguenza logica dei base beliefs; se viene trovata una sostituzione, il test goal è rimosso dal corpo del top dell’intention;  Eseguire un’azione equivale ad aggiungerla al set di azioni A e rimuoverla dal corpo del top dell’intention.

A questo punto, l’agente torna a valutare il set degli eventi E; il ciclo ricomincia, fino a quando:  il set degli eventi E è vuoto oppure  Non è possibile eseguire altre intentions.

Def 7 [Intention] : I è il set delle intentions; ogni intention è uno stack di piani parzialmente istanziati, ossia piani dove alcune variabili sono state istanziate. Un’intention è denotata con uno stack: [ p 1 ‡ p 2 ‡ … ‡ p z ] Intention stack bottom top

Una particolare intention è la true intention True intention: [ +!true: true <- true ] Per comodità, la denoteremo con T Intention

Def 8 [Evento] : il set E è il set degli eventi. Ogni evento è una coppia: dove: e è un triggering event i è una intention Se i è la true intention T, l’evento è un evento esterno, altrimenti si dice evento interno. Evento

Scelto un evento dal set E, il triggering event d viene unificato con i triggering event di tutti i piani contenuti nel set P Il most general unifier (mgu) che unifica i due eventi è detto relevant unifier L’intention i può essere:  La true intention T  Un’intention esistente che ha generato l’evento Ancora sul piano

Piano rilevante Torniamo all’esempio del traffico Supponiamo che il triggering event d di Є (ossia l’evento scelto in E dalla funzione di selezione) sia: +!location(robot,b). Ripresentiamo i piani introdotti in precedenza per il nostro agente

(P1) +location(waste, X): location(robot,X) & location(bin,Y) <- pick(waste); !location(robot, Y); drop(waste). (P2) +!location(robot,X): location(robot,X) <- true (P3) +!location(robot,X): location(robot,Y) & (not (X = Y)) & adjacent(Y,Z) & (not (location(car,Z))) <- move(Y,Z); +!location(robot,X).

Piano rilevante I piani P2 e P3 sono rilevanti L’unificatore rilevante è: σ = { X/b } (P2) +!location(robot,X): location(robot,X) <- true (P3) +!location(robot,X): location(robot,Y) & (not (X = Y)) & adjacent(Y,Z) & (not (location(car,Z))) <- move(Y,Z); +!location(robot,X).

Piano applicabile Un piano rilevante è anche applicabile se esiste una sostituzione che, composta con l’unificatore rilevante ed applicata al contesto, fa sì che quest’ultimo risulti una conseguenza logica dei base beliefs B In altre parole, la condizione del contesto di un piano rilevante DEVE essere conseguenza logica di B affinchè il piano sia applicabile

Piano applicabile Vediamo ancora l’esempio del traffico Supponiamo che i base beliefs del nostro agente siano: adjacent(a,b). adjacent(b,c). adjacent(c,d). location(robot,a). location(waste,b). location(bin,d). Il piano P3 è il solo applicabile mediante il seguente unificatore applicabile:   ={X/b, Y/a, Z/b}

abcd

(P3) +!location(robot,X): location(robot,Y) & (not (X = Y)) & adjacent(Y,Z) & (not (location(car,Z))) <- move(Y,Z); +!location(robot,X). adjacent(a,b). adjacent(b,c). adjacent(c,d). location(robot,a). location(waste,b). location(bin,d). Unificatore applicabile:   ={X/b, Y/a, Z/b}

Intended means Come detto, la funzione S ε seleziona un evento La natura di i determina il tipo di evento A seconda del tipo di evento (interno o esterno), l’agente esegue un opportuno intended means

adjacent(a,b). adjacent(b,c). adjacent(c,d). location(robot,a). location(waste,b). location(bin,d). (P1) +location(waste,X): location(robot,X) & location(bin,Y) <- pick(waste); !location(robot, Y); drop(waste). (P2) +!location(robot,X):location(robot,X) <- true (P3) +!location(robot,X):location(robot,Y) & (not (X = Y)) & adjacent(Y,Z) & (not (location(car,Z))) <- move(Y,Z); !location(robot,X). SεSε SOSO Unifica evento P2 e P3 rilevanti con { X/b } Unifica contesto P3 applicabile con { X/b,Y/a,Z/b } P3 [ +!location(robot,b):location(robot,a) & (not (b = a)) & adjacent(a,b) & (not (location(car,b))) <- move(a,b); !location(robot,b)]. SISI Esecuzione intention abcd [ +!location(robot,b): location(robot,a) & (not (b = a)) & adjacent(a,b) & (not (location(car,b))) <- move(a,b); !location(robot,b) ].

(P1) +location(waste,X): location(robot,X) & location(bin,Y) <- pick(waste); !location(robot, Y); drop(waste). (P2) +!location(robot,X):location(robot,X) <- true (P3) +!location(robot,X):location(robot,Y) & (not (X = Y)) & adjacent(Y,Z) & (not (location(car,Z))) <- move(Y,Z); !location(robot,X). SεSε SOSO Unifica evento P2 e P3 rilevanti con { X/b } Unifica contesto P3 applicabile con { X/b,Y/a,Z/b } P3 SISI Esecuzione intention abcd

(P1) +location(waste,X): location(robot,X) & location(bin,Y) <- pick(waste); !location(robot, Y); drop(waste). (P2) +!location(robot,X):location(robot,X) <- true (P3) +!location(robot,X):location(robot,Y) & (not (X = Y)) & adjacent(Y,Z) & (not (location(car,Z))) <- move(Y,Z); !location(robot,X). SεSε Unifica evento Nessun piano rilevante Unifica contesto Nessun piano applicabile SOSO - SISI Esecuzione intention adjacent(a,b). adjacent(b,c). adjacent(c,d). location(robot,b). location(waste,b). location(bin,d). [ +!location(robot,b):location(robot,a) & (not (b = a)) & adjacent(a,b) & (not (location(car,b))) <- !location(robot,b)]. abcd

(P1) +location(waste,X): location(robot,X) & location(bin,Y) <- pick(waste); !location(robot, Y); drop(waste). (P2) +!location(robot,X):location(robot,X) <- true (P3) +!location(robot,X):location(robot,Y) & (not (X = Y)) & adjacent(Y,Z) & (not (location(car,Z))) <- move(Y,Z); !location(robot,X). SεSε Unifica evento P2 e P3 rilevanti con { X/b } Unifica contesto P2 applicabile con { X/b } adjacent(a,b). adjacent(b,c). adjacent(c,d). location(robot,b). location(waste,b). location(bin,d). [ +!location(robot,b):location(robot,a) & (not (b = a)) & adjacent(a,b) & (not (location(car,b))) <- !location(robot,b)‡ +!location(robot,b):location(robot,b)<-true]. SOSO P2 SISI Esecuzione intention abcd

(P1) +location(waste,X): location(robot,X) & location(bin,Y) <- pick(waste); !location(robot, Y); drop(waste). (P2) +!location(robot,X):location(robot,X) <- true (P3) +!location(robot,X):location(robot,Y) & (not (X = Y)) & adjacent(Y,Z) & (not (location(car,Z))) <- move(Y,Z); !location(robot,X). SεSε Unifica evento P2 e P3 rilevanti con { X/b } Unifica contesto P2 applicabile con { X/b } SOSO P2 adjacent(a,b). adjacent(b,c). adjacent(c,d). location(robot,b). location(waste,b). location(bin,d). [ +!location(robot,b):location(robot,a) & (not (b = a)) & adjacent(a,b) & (not (location(car,b))) <- !location(robot,b)]. SISI Esecuzione intention abcd

(P1) +location(waste,X): location(robot,X) & location(bin,Y) <- pick(waste); !location(robot, Y); drop(waste). (P2) +!location(robot,X):location(robot,X) <- true (P3) +!location(robot,X):location(robot,Y) & (not (X = Y)) & adjacent(Y,Z) & (not (location(car,Z))) <- move(Y,Z); !location(robot,X). SεSε Unifica evento P2 e P3 rilevanti con { X/b } Unifica contesto P2 applicabile con { X/b } SOSO P2 adjacent(a,b). adjacent(b,c). adjacent(c,d). location(robot,b). location(waste,b). location(bin,d). SISI Esecuzione intention abcd

Ancora l’esempio Alla successiva iterazione del ciclo dell’agente, dopo che il robot si muove dalla corsia a alla corsia b, l’ambiente invia all’agente un evento di belief update per modificare la locazione del robot (che ora si troverà in b); in sostanza: - location(robot,b) viene aggiunto a B; - l’evento +location(robot,b) viene aggiunto ad E. A questo punto, non vi sono piani rilevanti; il sistema sceglie, pertanto, di ESEGUIRE l’intention mostrata nella slide precedente.

L’esecuzione dell’intention (caso a) porta ad aggiungere un evento al set E che diventa: { } dove i è l’intention considerata: [ +!location(robot,b): location(robot,a) & (not (b = a)) & adjacent(a,b) & (not (location(car,b))) <- +!location(robot,b) ] Ancora l’esempio

A questo punto, il piano P2 risulta applicabile con l’unificatore applicabile  = { X/b } +!location(robot,X): location(robot,X) <- true adjacent(a,b). adjacent(b,c). adjacent(c,d). location(robot,b). location(waste,b). location(bin,d). Ancora l’esempio

Il corpo del piano è true ; pertanto, l’intention è soddisfatta ed il set E è vuoto L’esecuzione dell’agente è sospesa e riprenderà nel momento in cui un nuovo evento verrà aggiunto all’insieme E Ancora l’esempio

Implementazioni di AgentSpeak(L) Jason

Java-based agentSpeak interpreter used with saci for multi-agent distribution over the net E’ la prima implementazione significativa di AgentSpeak(L), dovuta a Bordini e Hubner Implementato in Java Disponibile OpenSource Impiegando SACI, un’infrastruttura per la comunicazione fra agenti, è possibile distribuire un sistema multi-agente sulla rete

Jason Interpreta il linguaggio AgentSpeak(L) originale Aggiunge alcune importanti caratteristiche:  Gestione del fallimento dei piani  Supporto per lo sviluppo di ambienti da programmare in Java  Possibilità di eseguire un ambiente multi-agente utilizzando SACI  …

 Possibilità di personalizzare (in Java) funzioni di selezione, di belief-revision, di azione, di comunicazione fra agenti  Libreria di “azioni interne” di base  Possibilità di aggiungere “azioni interne” definite in Java dall’utente  Aggiunta della negazione forte Jason

Costruire un agente AgentSpeak(L) con Jason è molto semplice E’ sufficiente: 1. Inserire il nome dell’agente nel file di configurazione 2. Creare un file.asl contenente i piani che descrivono il comportamento dell’agente

Jason: differenze con AgentSpeak(L) Come accennato in precedenza, Jason presenta una serie di differenze rispetto al linguaggio AgentSpeak(L) originale ([Rao]) Illustriamo le principali differenze…

Jason: differenze con AgentSpeak(L) Possibile uso della negazione forte La negazione debole è usata nel contesto dei piani come in AgentSpeak(L), introdotta dal not Es.: not location(car,Y). La negazione forte è usata per negare un predicato/fatto: Es: ~location(waste,b).

Jason: differenze con AgentSpeak(L) Termini Possono essere:  Atomi  Strutture  Variabili  Liste (tipo Prolog)  Numeri (interi o floating point)  Stringhe (tra “”)

Jason: differenze con AgentSpeak(L) Predicati (atomi) annotati Possibilità di specificare annotazioni ai predicati nella base belief, per esempio per conservare l’origine di tale informazione Annotazione: lista di termini tra parentesi quadre associata ad un predicato Due annotazioni particolari:  [percept] : l’informazione è stata percepita dall’ambiente;  [self] : l’informazione è stata aggiunta dall’agente stesso durante l’esecuzione di un piano

Jason: differenze con AgentSpeak(L) Piani con labels E’ possibile associare una label a ciascun piano La label può essere un qualsiasi predicato (consigliata arietà zero), quindi anche un predicato con annotazione Utili per personalizzare le funzioni di selezione

Jason: differenze con AgentSpeak(L) Gestione del fallimento dei piani Sono previsti eventi per la gestione del fallimento dei piani Tale evento è generato se un’azione fallisce o non vi sono piani applicabili per un evento con aggiunta di un goal +!g In tali situazioni viene generato un evento interno per -!g associato alla stessa intention. Se il programmatore ha previsto un piano per -!g e questo risulta applicabile, verrà eseguito. Altrimenti, viene eliminata l’intera intention e segnalato un warning

Jason: differenze con AgentSpeak(L) Azioni interne Possono essere usate sia nel contesto che nel body di un piano Introdotte dal punto: Es:.send(…) Sono azioni interne, distinte dalle azioni che l’agente compie sull’ambiente mediante gli attuatori Azioni interne standard (directory src/stdlib ) e definite dall’utente in Java

Jason: differenze con AgentSpeak(L) Esempi di azioni interne standard:.send(receiver,illocutionary_force, propositional_content) Usata nella comunicazione tra agenti. Receiver è il nome del destinatario del messaggio; illocutionary_force descrive il tipo di messaggio (es. tell, achieve ); propositional_content è un predicato che rappresenta l’informazione trasmessa.

Jason: differenze con AgentSpeak(L) Esempi di azioni interne standard:.print(…) Scrive messaggi sulla console su cui l’agente o SACI è in esecuzione. Ha un numero qualsiasi di parametri, che possono essere stringhe così come termini AgentSpeak(L).

Jason Sistemi multi-agente

Jason: sistemi multi-agente L’utente può definire un sistema di multipli agenti AgentSpeak(L) Un sistema multi-agente prevede:  un ambiente in cui gli agenti AgentSpeak(L) vengono collocati, programmato in Java  Un set di istanze di agenti AgentSpeak(L) La configurazione dell’intero sistema multi-agente è data da un semplice file di testo

Jason: sistemi multi-agente File di configurazione di un sistema multi-agente: file con estensione.mas2j Nel file vengono indicati il nome attribuito alla società di agenti, gli agenti AgentSpeak(L) che ne fanno parte, l’ambiente in cui si collocano tali agenti (=la classe Java, eventualmente ridefinita dall’utente, per programmare l’ambiente) Jason offre una serie di script e un’interfaccia grafica che rendono immediate ed intuitive la compilazione e l’esecuzione di un sistema multi-agente

Jason Personalizzazione

Jason: personalizzazione Jason consente di personalizzare:  Alcuni elementi di base di un agente, tipo le funzioni di selezione;  I meccanismi di percezione, di azione, di comunicazione tra agenti e la belief revision function;  Le azioni interne;  L’ambiente in cui collocare un sistema multi- agente. Vediamo brevemente come fare…

Jason: personalizzazione Personalizzare un agente Jason offre la possibilità di modificare il codice di funzioni quali:  selectEvent  selectOption  selectIntention Il programmatore deve semplicemente definire una classe Java che estende la classe Agent, ridefinendo opportunamente i metodi da personalizzare Infine, basta segnalare il cambiamento nel file.mas2j

Jason: personalizzazione Personalizzare un agente Esempio: ridefiniamo la funzione S ε : import jason.*; import java.util.*; public class MyAgent extends Agent{ public Event selectEvent(List evList){ System.out.println(“Selezione di un evento”); return((Event)evList.remove(0)); } E’ sufficiente specificare agentClass MyAgent nella entry del dato agente nel file di configurazione.mas2j

Jason: personalizzazione Personalizzare l’architettura L’utente può creare l’architettura per l’agente, ossia è possibile modificare i metodi:  perceive  checkMail  brf  act Il codice di default è presente nelle classi SaciAgArch.java e CentralisedArch.java nella directory src/jason

Jason: personalizzazione Personalizzare l’architettura Esempio: ridefiniamo il meccanismo di percezione: import jason.*; public class MyAgArchitecture extends CentralisedAgArch{ public void perceive (){ /* per esempio, simulare un fallimento nella percezione modificando le liste “percepts” e “negPercepts” */ System.out.println(“Fase di percezione in corso”); super.perceive(); } Specificare agentArchClass MyAgArchitecture nella entry dell’agente nel file.mas2j

Jason: personalizzazione Personalizzare le azioni interne Come detto, le azioni interne standard si trovano nella directory src/stdlib Le azioni interne definite dall’utente in Java possono essere collocate in una directory predefinita ulib, eventualmente organizzate in librerie specifiche Per invocare un’azione personalizzata: nomeLibreria.nomeAzione

Jason: personalizzazione Personalizzare le azioni interne Il nome di un’azione deve iniziare con una lettera minuscola, il suo codice deve essere contenuto in un file con nome: nomeAzione.java La classe in questione deve ridefinire il metodo execute : package ; import jason.*; public class { public static boolean execute (…) throws Exception{ … }

Jason: personalizzazione Personalizzare l’ambiente Il programmatore può personalizzare l’ambiente in cui si collocano gli agenti AgentSpeak(L) In particolare, è possibile descrivere come si evolve l’ambiente in seguito all’esecuzione di un’azione da parte di un agente, modificando il codice del metodo executeAction Possibilità di simulare fallimenti nell’esecuzione delle azioni Possibilità di limitare ad un sottinsieme dell’ambiente la percezione di ciascun agente

Jason: personalizzazione Personalizzare l’ambiente Il file contenente la classe dell’ambiente personalizzato va specificato nel file di configurazione import java.util.*; import jason.*; public class extends Environment{ … public boolean executeAction (String ag, Term act){ … } ag è l’agente che esegue l’azione rappresentata dal termine act ; il metodo restituisce true se l’azione è stata eseguita con successo

Jason: riferimenti importanti Per scaricare gratuitamente l’ultima versione di Jason: Per scaricare gratuitamente SACI:

Conclusioni

Linguaggio di programmazione per agenti BDI Molti lavori per estendere il linguaggio di base, che non descrive, ad esempio, come gestire il fallimento dei piani Utilizzato solo di recente anche grazie a Jason AgentSpeak(L)

Jason Implementazione Java di AgentSpeak(L) esteso Semplice definizione di un ambiente multiagente con l’uso di SACI Molteplici possibilità di personalizzazione Ancora molto lavoro da fare:  Documentazione carente  Difficile osservare l’evoluzione del sistema: opportuna un’evoluzione dell’interfaccia e del supporto al programmatore  Gli autori lo hanno sviluppato a “tempo perso”

Bibliografia

BurSun92. B. Burmeister e K. Sundermeyer. Cooperative problem-solving guided by intentions and perception. In E. Werner and Y. Demazeau, editors, Decentralized A.I. 3, Amsterdam, Olanda, GeoLan86. M.P. Georgeff e A.L. Lansky. Procedural knowledge. In Proceedings of the IEEE Special Issue on Knowledge Representation, volume 74, , IngGeoRao92. F.F. Ingrand, M.P. Georgeff e A.S. Rao. An architecture for real-time reasoning and system control. IEEE Expert, 7(6), MulPisThi95. J.P. Muller, M. Pischel e M. Thiel. Modelling reacting behaviour in vertically layered agent architectures. In Intelligent Agents: Theories, Architectures, and Languages. LNAI 890, Heidelberg, Germania, 1995.

Rao95. A.S. Rao. Decision procedures for propositional linear- time belief-desire-intention logics. In Working notes of the IJCAI- 95 Workshop on Agent Theories, Architectures, and Languages, Montreal, Canada, Rao96. A.S. Rao. AgentSpeak(L): BDI Agents Speak Out in a Logical Computable Language. MAAMAW 1996: 42-55, RaoGeo91. A.S. Rao e M.P. Georgeff. Modeling rational agents within a BDI-architecture. In J. Allen, R. Fikes, and E. Sandewall, editors, Proceedings of the 2° International Conference on Principles of Knowledge Representation and Reasoning, RaoGeo93. A.S. Rao e M.P. Georgeff. A model-theoretic approach to the verification of situated reasoning systems. In Proc. Of the 13° Intern. Joint Conf. On Artificial Intelligence (IJCAI-93), Chambery, Francia, 1993.

Sho93. Y. Shoham. Agent-oriented programming. Artificial Intelligence, 60(1), 51-92, BorHub04. R.H. Bordini e J.F. Hubner. Jason: a Java-based agentSpeak interpreter used with saci for multi-agent distribution over the net. Disponibile all’indirizzo jason.sourceforge.net/Jason.pdf.