Presentazione di PowerPoint

1
Gian Luca Pozzato
AgentSpeak(L) e Jason
2
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

3
AgentSpeak (L) Jason

• 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

4

• 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
  larchitettura BDI

5

• IN QUESTA PRESENTAZIONE
• Breve introduzione
• AgentSpeak(L) linguaggio e funzionamento
  dellinterprete col sussidio di un esempio
• Proof theory di AgentSpeak(L)
• Jason
• Conclusioni e alcuni riferimenti utili

6
Introduzione
7

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

8
Agente AgentSpeak(L)
Ambiente esterno
Percezione
Azione
9
Principali attitudini mentali di un agente BDI

• Belief componente di informazione

cattura

• Desire componente motivazionale

cattura

• Intention componente decisionale

cattura
10
Aspetto teorico
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).
11
Aspetto pratico (I)

• 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
  lefficienza della computazione.

12
Aspetto pratico (II)

• 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.

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

• 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).

15
AgentSpeak(L)

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

16
AgentSpeak(L)

• Current belief state dellagente modello di sé
  stesso, dellambiente e degli altri agenti
• Desires stati che lagente 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.

17
Il linguaggio AgentSpeak(L)
18

• 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 dallutente
• Consentono una decomposizione gerarchica dei
  goals
• Sintatticamente simili alle clausole della
  programmazione logica (anche se con un diverso
  comportamento)

19
Alfabeto del linguaggio formale

• Variabili
• Costanti
• Simboli funzionali
• Simboli predicativi
• Simboli di azione
• Connettivi
• Quantificatori
• Simboli di punteggiatura

20
Connettivi

• della logica del primordine
• - (congiunzione ?)
• - not (negazione )
• - lt- (implicazione ?)
• ! Achievement
• ? Test
• Sequenza

21
Definizioni della logica del primordine

• Termini
• Formule
• Le variabili del linguaggio sono caratterizzate
  dalliniziale maiuscola

22
Il linguaggio AgentSpeak(L) Nozioni del linguaggio
23
Belief atom
Def 1 Belief atom sia b un simbolo
predicativo e siano t1, , tn termini.
Allora b(t1, , tn) è un belief atom e si
scrive anche b(t).

• Un belief atom e la sua negazione sono detti
  belief literal
• Un belief atom ground (senza variabili con
  occorrenze libere) è detto base belief

24
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.

25
Esempio

• Consideriamo la seguente simulazione di traffico
  urbano
• 4 corsie adiacenti
• Le corsie possono essere percorse da automobili
• In ciascuna corsi 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 unauto, per evitare di
  essere distrutto
• Vogliamo scrivere il programma per lagente che
  guida il robot nella sua attività.

26
Agente AgentSpeak(L)
Ambiente esterno
Percezione
Azione
27

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

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

• E uno stato del sistema che lagente vuole
  raggiungere
• 2 tipi di goal
• Achievement goal
• Test goal

30

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

31
Goal
Def 2 Goal sia g un simbolo predicativo e
siano t1, , tn termini. Allora !g(t1, , tn)
( oppure !g(t) ) è un achievement goal ?g(t1,
, tn) ( oppure ?g(t) ) è un test goal.
32
Goal

• Esempio
• !cleared(b) lagente vuole pulire la corsia b
• ?location(car,b) lagente vuole verificare
  leventuale presenza di unauto nella corsia b

33
Triggering event

• Quando un agente acquisisce un nuovo goal oppure
  nota una modifica nellambiente, 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

34
Triggering event

• Laggiunta di un belief/goal è rappresentata
  dalloperatore
• La rimozione di un belief/goal è rappresentata
  dalloperatore
• 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)

35
Triggering event

• Def 3 Triggering event sia b(t) un belief
  atom e siano !g(t) e ?g(t) goals. Allora
• b(t)
• -b(t)
• !g(t)
• -!g(t)
• ?g(t)
• -?g(t)
• sono triggering events.

36
Azione
Scopo di un agente Osservare lambiente e,
sulla base di tali osservazioni e dei propri
goals, eseguire determinate azioni Le azioni
compiute dallagente possono modificare lo stato
dellambiente
37
Azione
Esempio Se move è un simbolo di azione,
move(X,Y) è unazione e rappresenta lo
spostamento del robot da X a Y e ha leffetto di
modificare lo stato dellambiente. Il robot si
trova nella corsia Y e non più nella corsia X
38
Azione
Def 4 Azione sia a un simbolo di azione e
siano t1,, tn termini. Allora a(t1,, tn) è
unazione.
39
Piano

• Un piano specifica il modo in cui un agente
  potrebbe raggiungere un determinato obiettivo
• ltpianogt ltheadgt ? ltbodygt
• ltheadgt lttriggering eventgt ltcontextgt
• triggering event specifica perché il piano è
  stato attivato, ossia laggiunta/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 dellagente
  quando il piano è attivato (scatta)

40
Piano

• ltpianogt ltheadgt ? ltbodygt
• ltheadgt lttriggering eventgt ltcontextgt
• body è una sequenza di goals o azioni e
  specifica
• i goals che lagente vuole raggiungere
  (achievement goals) o testare (test goals)
• le azioni che lagente deve eseguire
• true rappresenta un componente vuoto (context o
  body)

41
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 lobiettivo (achievement goal) di
  raggiungere il cestino
• Getta via la spazzatura.

42
Piano
Un possibile piano (P1) location(waste, X)
location(robot,X) location(bin,Y) lt-
pick(waste) !location(robot, Y)
drop(waste).
43
Piano

• Esempio piano per consentire al robot di
  spostarsi fra le corsie. Il robot ha lobiettivo
  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.

44
Piano
Piano (P2) !location(robot,X)
location(robot,X) lt- true. Piano
(P3) !location(robot,X) location(robot,Y)
(not (X Y)) adjacent(Y,Z)
(not (location(car,Z))) lt-
move(Y,Z) !location(robot,X).
45
Piano

• Def 5 Piano siano
• e un triggering event
• b1,,bm belief literals
• h1,,hn goals o azioni
• allora
• e b1 ? ? bm ? h1 hn
• è 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.

46
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.
• Tuttavia, ci sono delle differenze

47
Programmazione logica vs progetto di un agente in
AgentSpeak(L)

• Regole vs Piani nella programmazione logica pura
  non cè differenza tra un goal nel body o nella
  head di una regola. In AgentSpeak(L), invece, la
  head è un triggering event, e non un goal.
• Ciò consente un invocazione dei piani più
  espressiva, in quanto sono entrambe permesse
• Invocazione data-directed (mediante
  laggiunta/rimozione di beliefs)
• Invocazione goal-directed (mediante
  laggiunta/rimozione di goals)

48
Programmazione logica vs progetto di un agente in
AgentSpeak(L) (2)

• Le regole non sono context-sensitive come i
  piani
• Le regole eseguite con successo ritornano un
  binding per le variabili non istanziate invece,
  lesecuzione di piani genera una sequenza di
  azioni ground che modificano lambiente
• La prova (dimostrazione) di un goal non può
  essere interrotta, mentre i piani di un programma
  per agenti possono essere interrotti.

49
Il linguaggio AgentSpeak(L) La semantica
operazionale
50

• 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 Se, SO, SI
• Descriviamo informalmente il funzionamento di un
  agente AgentSpeak(L)

51
Agente AgentSpeak(L)
Ambiente esterno
Percezione
Azione
52
Interni o Esterni
!goal -!goal belief -belief
Evento selezionato
Belief base location(robot,b). adjacent(a,b).
Piani rilevanti
Piani applicabili
Intended means
Evento interno push
Evento esterno nuova intention
53

• Viene generato un triggering event quando un
  agente nota una modifica nellambiente
  circostante oppure quando un utente esterno
  chiede allagente di raggiungere un goal
• Gli eventi possono essere
• Esterni (modifica dellambiente)
• Interni (modifica dello stato dellagente)
• Gli eventi vengono aggiunti al set E
• Se seleziona in E un evento E0 da processare
• E0 viene rimosso da E e viene usato per unificare
  con i triggering events dei piani del set P

54

• I piani i cui triggering events unificano con E0
  sono detti piani rilevanti lunificatore è detto
  unificatore rilevante
• Lunificatore 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
• Lunificatore applicabile risulta dalla
  composizione della correct answer substitution
  con lunificatore rilevante

55

• Dato un evento E0, diversi piani/opzioni
  risultano applicabili
• La funzione di selezione SO sceglie uno di
  questi piani/opzioni che chiamiamo Po
• Applicando lunificatore applicabile a Po si
  ottiene lintended means in risposta al
  triggering event
• Ogni intention è uno stack di piani parzialmente
  istanziati o intention frames

56

• Evento esterno lintended means è usato per
  creare una NUOVA INTENTION, che viene aggiunta al
  set I
• Evento interno lintended means è inserito in
  cima allintention ESISTENTE che ha fatto
  scattare (triggered) levento interno (per
  raggiungere un goal)

57

• La funzione di selezione SI sceglie una intention
  da eseguire
• Quando lagente esegue una intention, esegue il
  primo goal o azione del body del top
  delintention
• 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 dellintention
• Eseguire unazione equivale ad aggiungerla al set
  di azioni A e rimuoverla dal corpo del top
  dellintention.

58

• A questo punto, lagente 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.
• Formalizziamo il tutto

59
Stato di un agente in ogni istante di tempo

• Def 6 Stato dellagente un agente è definito
  come una tupla
• lt E,B,P,I,A,Se,SO,SI gt
• dove
• E è un set di eventi
• B è un set di base beliefs
• P è un set di piani
• I è un set di intentions

60
Stato di un agente in ogni istante di tempo

• Def 6 Stato dellagente un agente è definito
  come una tupla
• lt E,B,P,I,A,Se,SO,SI gt
• A è un set di azioni
• Se seleziona un evento da E
• SO seleziona unopzione/piano applicabile (vedi
  Def 10 in seguito) da un set di piani applicabili
• SI seleziona una intention dal set I

61
Intention
Def 7 Intention I è il set delle intentions
ogni intention è uno stack di piani parzialmente
istanziati, ossia piani dove alcune variabili
sono state istanziate. Unintention è denotata
con uno stack p1 p2 pz
bottom
top
stack
62
Intention

• Una particolare intention è la true intention
• True intention
• !true true lt- true
• Per comodità, la denoteremo con T

63
Evento

• Def 8 Evento il set E è il set degli eventi.
  Ogni evento è una coppia
• lt e, i gt
• dove
• e è un triggering event
• i è una intention
• Se i è la true intention T, levento è un evento
  esterno, altrimenti si dice evento interno.

64
Ancora sul piano

• Scelto un evento lt d, i gt 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
• Lintention i può essere
• La true intention T
• Unintention esistente che ha generato levento

65
Piano rilevante
Def 9 Piano rilevante sia Se (E) ? lt d,
i gt e sia p definito come e b1 ? ? bm ? h1
hn. p si definisce un piano rilevante
rispetto allevento ? se e solo se esiste un mgu
s tale che d s e s s è detto unificatore
rilevante per ?.
66
Piano rilevante

• Torniamo allesempio del traffico
• Supponiamo che il triggering event d di ? (ossia
  levento scelto in E dalla funzione di selezione)
  sia
• !location(robot,b).
• Ripresentiamo i piani introdotti in precedenza
  per il nostro agente

67
(P1) location(waste, X) location(robot,X)
location(bin,Y) lt- pick(waste)
!location(robot, Y) drop(waste).
(P2) !location(robot,X) location(robot,X)
lt- true (P3) !location(robot,X)
location(robot,Y) (not (X Y))
adjacent(Y,Z) (not (location(car,Z)))
lt- move(Y,Z) !location(robot,X).
68
Piano rilevante

• I piani P2 e P3 sono rilevanti
• Lunificatore rilevante è
• s X/b

(P2) !location(robot,X) location(robot,X)
lt- true (P3) !location(robot,X)
location(robot,Y) (not (X Y))
adjacent(Y,Z) (not (location(car,Z)))
lt- move(Y,Z) !location(robot,X).
69
Piano applicabile

• Un piano rilevante è anche applicabile se esiste
  una sostituzione che, composta con lunificatore
  rilevante ed applicata al contesto, fa sì che
  questultimo 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

70
Piano applicabile

• Def 10 Piano applicabile sia p il piano
• e b1 ? ? bm ? h1 hn
• p è un piano applicabile rispetto ad un evento ?
  se e solo se
• Esiste un unificatore rilevante ? per ? (ossia, p
  è rilevante per ?)
• Esiste una sostituzione ? tale che ?(b1 ? ? bm)
  ? ? è una conseguenza logica di B.
• La composizione ? ? si dice unificatore
  applicabile per ? e ? è la correct answer
  substitution.

71
Piano applicabile

• Vediamo ancora lesempio 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

72
(No Transcript)
73
adjacent(a,b). adjacent(b,c). adjacent(c,d). locat
ion(robot,a). location(waste,b). location(bin,d).
(P3) !location(robot,X) location(robot,Y)
(not (X Y)) adjacent(Y,Z)
(not (location(car,Z))) lt-
move(Y,Z) !location(robot,X).
Unificatore applicabile ? ? X/b, Y/a, Z/b
74
Intended means

• Come detto, la funzione Se seleziona un evento lt
  d, i gt
• La natura di i determina il tipo di evento
• A seconda del tipo di evento (interno o esterno),
  lagente esegue un opportuno intended means

75
Intended means evento ESTERNO

• Lintended means è ottenuto selezionando un piano
  applicabile per levento
• Si applica lunificatore applicabile al body del
  piano
• Lintended means è utilizzato per creare una
  nuova intention che viene aggiunta al set I
• Vediamo la definizione formale

76
Intended plan evento ESTERNO
Def 11 Intended plan evento ESTERNO sia SO
(O?)p, dove O? è il set di tutti i piani
applicabili per levento ?lt d, i gt e p è e
b1 ? ? bm ? h1 hn Il piano p è un intended
plan rispetto a ?, dove i è T (true intention) se
e solo se esiste un unificatore applicabile ?
tale che !true true ? true (e b1 ? ?
bm ? h1 hn)? ? I
77
Intended plan evento ESTERNO

• Proseguiamo lesempio
• Il piano applicabile P3 è un intended plan il
  set I diventa
• !location(robot,b) location(robot,a)
• (not (b a))
• adjacent(a,b)
• (not (location(car,b)))
• lt- move(a,b)
• !location(robot,b)

78
Intended means evento INTERNO

• Lintended means per lachievement goal è posto
  (push) sul top delintention esistente che ha
  generato (triggered) levento interno
• Vediamo la definizione formale

79
Intended plan evento INTERNO
Def 12 Intended plan evento INTERNO sia SO
(O?)p, dove O? è il set di tutti i piani
applicabili per levento ?lt d, i gt dove i è
p1 f c1 ? ... ? cy ? !g(t)h2hn e p
è !g(s) b1 ? ? bm ? k1 kj Il piano p
è un intended plan rispetto a ? se e solo se
esiste un unificatore applicabile ? tale che
p1 f c1 ? ... ? cy ? !g(t) h2 hn
(!g(s) b1 ? ? bm)? ? (k1 kj)?
(h2hn)? ? I
80
Esecuzione di intentions

• La funzione SI seleziona unintention da eseguire
• La prima formula nel body del top dellintention
  può essere
• Un achievement goal
• Un test goal
• Unazione
• True
• Vediamo, in ciascuno dei casi, cosa fa il nostro
  agente sia
• SI(I)i

81
Esecuzione di intentions

• Achievement goal il sistema esegue lachievement
  goal generando un evento. Formalmente
• i è p1 f c1 ? ? cy ? !g(t)h2hn
• Lintention i si dice eseguita se e solo se
• lt !g(t), i gt ? E

82
Esecuzione di intentions

• b) Test goal il sistema cerca un mgu che
  unifichi il goal con il set B e, se esiste, lo
  applica al resto dellintended means.
  Formalmente
• i è p1 f c1 ? ? cy ? ?g(t)h2hn
• Lintention i si dice eseguita se e solo se
  esiste una sostituzione ? tale che
• - ?g(t)? è conseguenza logica di B
• - i è rimpiazzato (in I) dallintention
• p1 (f c1 ? ? cy)? ? h2? hn?

83
Esecuzione di intentions

• c) Azione il sistema aggiunge lazione al set di
  azioni A. Formalmente
• i è p1 f c1 ? ? cy ? a(t)h2hn
• Lintention i si dice eseguita se e solo se
• - a(t) ? A
• - i è rimpiazzato (in I) dallintention
• p1 f c1 ? ? cy ? h2 hn

84
Esecuzione di intentions

• d) True il top dellintention e lachievement
  goal soddisfatto vengono rimossi e la
  sostituzione è applicata al resto del body
  dellintention. Formalmente
• i è p1 pz-1 !g(t) c1 ? ? cy ? true
• dove pz-1 è e b1 ? ? bx ? !g(s) h2 hn.
  Lintention i si dice eseguita se e solo se
• - esiste una sostituzione ? tale che g(t)?
  g(s)?
• - i è rimpiazzato (in I) dallintention
• p1 pz-2 (e b1 ? ? bx)? ? (h2 hn)?

85
lt!location(robot,b),Tgt
!location(robot,b) location(robot,a)
(not (b a)) adjacent(a,b) (not
(location(car,b))) lt- move(a,b)
!location(robot,b) .
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))) lt- move(a,b)
!location(robot,b).
86
P3 applicabile con X/b,Y/a,Z/b

P3
87
ltlocation(robot,b),Tgt

!location(robot,b)location(robot,a)
(not (b a)) adjacent(a,b) (not
(location(car,b))) lt- !location(robot,b).
88

89

!location(robot,b)location(robot,a)
(not (b a)) adjacent(a,b) (not
(location(car,b))) lt- !location(robot,b).
90

!location(robot,b)location(robot,a)
(not (b a)) adjacent(a,b) (not
(location(car,b))) lt-true.
91
Ancora lesempio

• Alla successiva iterazione del ciclo dellagente,
  dopo che il robot si muove dalla corsia a alla
  corsia b, lambiente invia allagente 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
• - levento location(robot,b) viene aggiunto ad
  E.
• A questo punto, non vi sono piani rilevanti il
  sistema sceglie, pertanto, di ESEGUIRE
  lintention mostrata nella slide precedente.

92
Ancora lesempio

• Lesecuzione dellintention (caso a) porta ad
  aggiungere un evento al set E che diventa
• lt !location(robot,b), i gt
• dove i è lintention considerata

!location(robot,b) location(robot,a)
(not (b a)) adjacent(a,b)
(not (location(car,b))) lt-
!location(robot,b)
93
Ancora lesempio
adjacent(a,b). adjacent(b,c). adjacent(c,d). locat
ion(robot,b). location(waste,b). location(bin,d).

• A questo punto, il piano P2
• risulta applicabile con lunificatore applicabile
  ? X/b

!location(robot,X) location(robot,X) lt- true
94
Ancora lesempio

• Il corpo del piano è true pertanto, lintention
  è soddisfatta ed il set E è vuoto
• Lesecuzione dellagente è sospesa e riprenderà
  nel momento in cui un nuovo evento verrà aggiunto
  allinsieme E

95
Proof theory
96
Proof theory

• Fornita come un sistema di transizione con
  etichette
• Le regole del metodo di prova definiscono la
  transizione dellagente da una configurazione
  alla successiva
• Le transizioni fra configurazioni sono in
  relazione diretta con la semantica operazionale
  del linguaggio
• Corrispondenza tra linterprete AgentSpeak(L) e
  la proof theory

97
Sistema di transizione BDI

• E una coppia
• lt , gt
• dove
• - è un set di configurazioni BDI
• - è una relazione di transizione
  binaria
• ?

98
Configurazione BDI

• E una tupla
• ltEi, Bi, Ii, Ai, igt
• dove
• Ei ? E
• Bi ? B
• Ii ? I
• Ai ? A
• i è la label della transizione
• Linsieme dei piani P è omesso in quanto costante

99
Regole di transizione

• Rao definisce delle regole di transizione che
  definiscono il passaggio di un agente da una
  configurazione alla successiva
• Esempio regola IntendEnd, che mostra la
  transizione per la scelta di un piano al top
  level (come muta linsieme I dellagente per la
  gestione di un evento esterno)

lt ,lt!g(t),Tgt,,Bi,Ii,Ai,i gt
(IntendEnd)
lt ,Bi, Ii ? ps? ,Ai,i1 gt
100
Regole di transizione
lt ,lt!g(t),Tgt,,Bi,Ii,Ai,i gt
(IntendEnd)
lt ,Bi, Ii ? ps? ,Ai,i1 gt

• p è !g(s) b1 ? ? bm ? h1 hn ? P
• Se(E)lt!g(t),Tgt
• g(t)sg(s)s
• ?(b1 ? ? bm)? è conseguenza logica di Bi

101
Derivazioni e refutazioni BDI

• Ci sono regole per lesecuzione delle intentions,
  per la gestione di eventi interni, ecc.
• Con queste regole è possibile definire
  formalmente derivazioni e refutazioni
• Una derivazione BDI è una sequenza finita o
  infinita di configurazioni BDI ?0, , ?i,
• Refutazione di intention la refutazione inizia
  con la scelta di unintention e si conclude
  quando lo stack di tale intention è vuoto
• Con tale refutazione BDI è possibile dimostrare
  alcune proprietà del comportamento di un agente
  RaoGeo93

102
Derivazioni e refutazioni BDI

• Corrispondenza uno-a-uno tra le regole di prova e
  la semantica operazionale
• Rao indica la possibilità di estendere la
  semantica operazionale e le regole di prova ad
  altri eventi interni, tipo successo o fallimento
  di piani, azioni, goals e intentions
• Il body dei piani considerati da Rao include
  esclusivamente sequenze di goals o azioni, ma
  sarebbe opportuno consentire operatori quali
• or non deterministico
• aggiunta/rimozione di beliefs
• iterazioni
• operatori paralleli

103
Implementazioni di AgentSpeak(L) Jason
104
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, uninfrastruttura per la
  comunicazione fra agenti, è possibile distribuire
  un sistema multi-agente sulla rete

105
Jason

• Interpreta il linguaggio AgentSpeak(L) originale
• Aggiunge alcune importanti caratteristiche
• Gestione del fallimento dei piani
• Annotazioni sulle labels dei piani, utilizzate
  per definire opportune funzioni di selezione
• Supporto per lo sviluppo di ambienti da
  programmare in Java
• Possibilità di eseguire un ambiente multi-agente
  utilizzando SACI

106
Jason

• 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 dallutente
• Aggiunta della negazione forte

107
Jason

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

108
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

109
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).

110
Jason differenze con AgentSpeak(L)

• Termini
• Possono essere
• Atomi
• Strutture
• Variabili
• Liste (tipo Prolog)
• Numeri (interi o floating point)
• Stringhe (tra )

111
Jason differenze con AgentSpeak(L)

• Predicati (atomi) annotati
• Possibilità di specificare annotazioni ai
  predicati nella base belief, per esempio per
  conservare lorigine di tale informazione
• Annotazione lista di termini tra parentesi
  quadre associata ad un predicato
• Due annotazioni particolari
• percept linformazione è stata percepita
  dallambiente
• self linformazione è stata aggiunta
  dallagente stesso durante lesecuzione di un
  piano

112
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

113
Jason differenze con AgentSpeak(L)

• Gestione del fallimento dei piani
• Sono previsti eventi per la gestione del
  fallimento dei piani
• Tale evento è generato se unazione 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 lintera intention e
  segnalato un warning

114
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
  lagente compie sullambiente mediante gli
  attuatori
• Azioni interne standard (directory src/stdlib) e
  definite dallutente in Java

115
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 linformazione
trasmessa.
116
Jason differenze con AgentSpeak(L)
Esempi di azioni interne standard .print() Scr
ive messaggi sulla console su cui lagente o SACI
è in esecuzione. Ha un numero qualsiasi di
parametri, che possono essere stringhe così come
termini AgentSpeak(L).
117
Jason Sistemi multi-agente
118
Jason sistemi multi-agente

• Lutente 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 dellintero sistema
  multi-agente è data da un semplice file di testo

119
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, lambiente in cui si collocano
  tali agenti (la classe Java, eventualmente
  ridefinita dallutente, per programmare
  lambiente)
• Jason offre una serie di script e uninterfaccia
  grafica che rendono immediate ed intuitive la
  compilazione e lesecuzione di un sistema
  multi-agente

120
Jason Personalizzazione
121
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
• Lambiente in cui collocare un sistema
  multi-agente.
• Vediamo brevemente come fare

122
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

123
Jason personalizzazione

• Personalizzare un agente
• Esempio ridefiniamo la funzione Se
• 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

124
Jason personalizzazione

• Personalizzare larchitettura
• Lutente può creare larchitettura per lagente,
  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

125
Jason personalizzazione

• Personalizzare larchitettura
• 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 dellagente nel file .mas2j

126
Jason personalizzazione

• Personalizzare le azioni interne
• Come detto, le azioni interne standard si trovano
  nella directory src/stdlib
• Le azioni interne definite dallutente in Java
  possono essere collocate in una directory
  predefinita ulib, eventualmente organizzate in
  librerie specifiche
• Per invocare unazione personalizzata
• nomeLibreria.nomeAzione

127
Jason personalizzazione

• Personalizzare le azioni interne
• Il nome di unazione 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 ltnomeLibreriagt
• import jason.
• public class ltnomeAzionegt
• public static boolean execute () throws
  Exception

128
Jason personalizzazione

• Personalizzare lambiente
• Il programmatore può personalizzare lambiente in
  cui si collocano gli agenti AgentSpeak(L)
• In particolare, è possibile descrivere come si
  evolve lambiente in seguito allesecuzione di
  unazione da parte di un agente, modificando il
  codice del metodo executeAction
• Possibilità di simulare fallimenti
  nellesecuzione delle azioni
• Possibilità di limitare ad un sottinsieme
  dellambiente la percezione di ciascun agente

129
Jason personalizzazione

• Personalizzare lambiente
• Il file contenente la classe dellambiente
  personalizzato va specificato nel file di
  configurazione
• import java.util.
• import jason.
• public class ltnomeAmbientegt extends
  Environment
• public boolean executeAction (String ag, Term
  act)
• ag è lagente che esegue lazione rappresentata
  dal termine act il metodo restituisce true se
  lazione è stata eseguita con successo

130
Jason riferimenti importanti

• Per scaricare gratuitamente lultima versione di
  Jason
• http//jason.sourceforge.net
• Per scaricare gratuitamente SACI
• http//www.lti.pcs.usp.br/saci/

131
Conclusioni
132
AgentSpeak(L)

• 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

133
Jason

• Implementazione Java di AgentSpeak(L) esteso
• Semplice definizione di un ambiente multiagente
  con luso di SACI
• Molteplici possibilità di personalizzazione
• Ancora molto lavoro da fare
• Documentazione carente
• Difficile osservare levoluzione del sistema
  opportuna unevoluzione dellinterfaccia e del
  supporto al programmatore
• Gli autori lo hanno sviluppato a tempo perso

134
Bibliografia
135
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, 1992. GeoLan86. M.P. Georgeff e A.L. Lansky. Procedural knowledge. In Proceedings of the IEEE Special Issue on Knowledge Representation, volume 74, 1383-1398, 1986. IngGeoRao92. F.F. Ingrand, M.P. Georgeff e A.S. Rao. An architecture for real-time reasoning and system control. IEEE Expert, 7(6), 1992. 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.
136
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, 1995. Rao96. A.S. Rao. AgentSpeak(L) BDI Agents Speak Out in a Logical Computable Language. MAAMAW 1996 42-55, 1996. 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, 1991. 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.
137
Sho93. Y. Shoham. Agent-oriented programming.
Artificial Intelligence, 60(1), 51-92,
1993. 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 allindirizzo jason.sourceforge.n
et/Jason.pdf.