Pobierz artykuł

Wojciech PIEPRZYCA
WyŜsza Szkoła Informatyki i Zarządzania w Bielsku-Białej
Studium Doktoranckie Informatyki
Wydział Automatyki, Elektroniki i Informatyki
Politechnika Śląska
email: [email protected]
ANALIZA PROCESÓW KOMUNIKACYJNYCH W SYSTEMACH
WIELOAGENTOWYCH Z WYKORZYSTANIEM JĘZYKA KQML
Streszczenie: Artykuł omawia zagadnienia związane z moŜliwością wymiany informacji
w systemach wieloagentowych. W tym celu przedstawiono model kolorowanej sieci Petriego
stworzony do zobrazowania i symulacji procesów komunikacji agentów oraz przykładowe
diagramy określające sekwencje wymiany informacji pomiędzy agentami za pomocą
odpowiednich performatywów języka KQML.
Słowa kluczowe: komunikacja agentów, systemy wieloagentowe, język KQML, sieci Petriego
Summary: The article includes discussion on information exchange within multiagent
systems. For this purpose Petri net model was created to represent and simulate agent
communication processes. Exemplary data exchange sequences between agents using KQML
performatives were illustrated with sequence diagrams.
Keywords: agent communication, multiagent systems, KQML, Petri nets
1. Wprowadzenie
Systemy wieloagentowe duŜą część swojej efektywności opierają na odpowiedniej
kooperacji i koordynacji wykonywanych zadań. W tym celu konieczne jest udostępnienie
odpowiednich metod komunikacji agentów m.in. zdefiniowanie języka za pomocą którego
agenci będą mogli się komunikować oraz wymieniać wiadomości, a takŜe wiedzę. Jedną
z propozycji takiego języka jest KQML (Knowledge Query Manipulation Language).
Język KQML zaprojektowany został przez grupę Knowledge Sharing Effort działającą
pod auspicjami DARPA (Defense Advanced Research Projects Agency) [1]. W systemach
agentowych język ten wykorzystywany jest do wymiany komunikatów oraz wiedzy pomiędzy
autonomicznymi agentami. Zapytania i polecenia zadawane w języku KQML operują na
bazie wiedzy związanej z danym agentem. W szczególności nie musi to być baza wiedzy
w tradycyjnym znaczeniu, ale równieŜ tzw. wirtualna baza wiedzy, która zdefiniowana jest
jako zwykła struktura programu agentowego lub traktowana jako informacje zawarte
w standardowej bazie danych. Zapytania mogą umoŜliwiać sprawdzanie zawartości bazy
wiedzy, jej aktualizację, itp.
Wiadomość (jednostka wymiany informacji) w języku KQML określana jest jako
performatyw. Pojęcie to wywodzi się z teorii aktu mowy i jest definiowane w naukach
związanych z lingwistyką. Ogólnie performatywy moŜemy podzielić na:
• komunikaty asertoryczne (stwierdzenia),
• komunikaty dyrektywne (polecenia, pytania, sugestie),
• komunikaty deklaratywne (informacje o umiejętnościach nadawcy).
Język KQML posiada pewien predefiniowany zbiór performatywów, których działanie
jest określone i nie moŜe być zmieniane. Zbiór ten jest jednak rozszerzalny tzn. w zaleŜności
od potrzeb moŜna definiować własne performatywy o działaniu określonym w ramach
specyfikowanego systemu agentowego.
Performatyw w języku KQML jest ciągiem znaków ASCII, zgodnie ze zdefiniowaną dla
tego języka gramatyką opartą na prefiksowej notacji polskiej. KaŜda wiadomość oprócz swej
nazwy identyfikującej rodzaj performatywu, posiada zbiór parametrów w postaci
:nazwa wartość np. :sender agent1 (parametr określający nazwę nadawcy wiadomości).
Kolejność występowania parametrów jest dowolna. Najczęściej występujące parametry
wiadomości w języku KQML przedstawia tabela 1.
Tabela 1. Podstawowe parametry performatywów w języku KQML [2].
Parametr
Znaczenie
:sender
Nadawca wiadomości
:receiver
Odbiorca wiadomości
:reply-with
Jeśli parametr ten nie występuje lub ma wartość nil oznacza to, Ŝe
nadawca nie oczekuje odpowiedzi na tę wiadomość. W przeciwnym
przypadku pole zawiera identyfikator na który powoła się odbiorca
odpowiadając na tę wiadomość (wpisując ten identyfikator w pole :inreply-with).
:in-reply-to
Identyfikator określający na jaką wiadomość odpowiada agent
:language
Język w którym reprezentowana jest zawartość wiadomości (:content)
:ontology
Nazwa ontologii do której odnosi się zawartość wiadomości (:content)
:content
Zawartość wiadomości
:force
Określa czy nadawca w przyszłości moŜe zmienić znaczenie tego
performatywu.
Sama zawartość wiadomości jest transparentna dla KQML i moŜe być reprezentowana
w róŜnych językach, zarówno stosujących format znaków ASCII jak i kod binarny, nie jest to
przedmiotem standardu języka KQML. Niemniej jednak najczęściej stosowanymi językami
dla pola zawartości :content są języki umoŜliwiające reprezentowanie zawartości bazy wiedzy
np. KIF (Knowledge Interchange Format), Prolog, itp.
Język KIF oparty jest na logice pierwszego rzędu. Został opracowany przez grupę KSE
(Knowledge Sharing Effort) zajmującą się językami reprezentacji wiedzy ze szczególnym
uwzględnieniem problemu wymiany wiedzy pomiędzy heterogenicznymi systemami
informatycznymi.
Niektóre z najwaŜniejszych cech języka KIF to [3]:
- implementacja niezaleŜna od semantyki,
- ekspresyjność, moŜliwość tłumaczenia i reprezentacji większości systemów reprezentacji
wiedzy,
- język jest czytelny dla ludzi.
Przykłady wyraŜeń w języku KIF:
Temperatura m1 = 83 stopnie C
(= (temperature m1) (scalar 83 Celsius))
X jest kawalerem jeŜeli jest męŜczyzną i nie jest Ŝonaty
(=> (and (man ?x) (not (married ?x))) (bachelor (?x))
2. Wiadomość w języku KQML
Wiadomość w języku KQML składa się z listy elementów otoczonych przez parę
nawiasów i rozdzielonych spacjami. Pierwszy element wiadomości to określenie rodzaju
performatywu, wszystkie kolejne elementy występujące na liście to parametry.
(ask-one
:sender A
:receiver B
:reply-with 101
:language KIF
:ontology book
:content (price ISBN1-58053-605-0 ?x))
W powyŜszej przykładowej wiadomości, performatyw to ask-one. Nadawcą wiadomości
jest agent A, wiadomość przesyłana jest do odbiorcy o nazwie B. Dodatkowo określono
nazwę języka (KIF) i ontologii (book), w których wyraŜona jest zawartość wiadomości
(:content). Pole content zawiera zapytanie sformułowane w języku KIF dotyczące ceny
ksiąŜki o podanym numerze ISBN.
3. Model systemu agentowego
A
MBOX
Message
AgentA
Agent B
Agent
Agent
Message
A
Sender
1
AgentA
Name
AOut
AIn
Message
BOut
Message
Message
B
MBOX
BIn
B
Sender
1
AgentB
Name
Communication
Channel
Communication Channel
Message
FOut
FIn
Facilitator
Facilitator
COut
Message
Message
Message
F
MBOX
Message
Rys. 1. System wieloagentowy
C
MBOX
Agent C
Agent
Message
C
Sender
1
AgentC
Name
CIn
Message
Przedstawiony model został stworzony za pomocą kolorowanej sieci Petriego. Głównymi
składowymi modelu są 3 hierarchiczne strony: Agent – przedstawia działanie agenta,
Communication Channel – obrazuje sposób przesyłania wiadomości pomiędzy agentami oraz
Facilitator – reprezentuje sposób realizacji zadań przez agenta wspomagającego.
Dla uproszczenia przyjęto, Ŝe w systemie istnieje trzech agentów zwykłych (A,B,C) oraz
jeden agent wspomagający (Facilitator), Przesyłane wiadomości trafiają do skrzynek
poszczególnych agentów (A MBOX, B MBOX, itd.).
Message
AOut
Message
Message
m
TransmitA
In
send(#receiver m,F,m)
send(#receiver m,F,m)
FIn
TransmitF
m
send(#receiver m,A,m)
AIn
Out
FOut
In
Out
send(#receiver m,F,m)
Message
send(#receiver m,A,m)
send(#receiver m,A,m)
Messagesend(#receiver m,B,m)
send(#receiver m,B,m) Out
BIn
send(#receiver m,B,m)
send(#receiver m,C,m)
Message
BOut
send(#receiver m,C,m)
m
TransmitB
In
Out
send(#receiver m,C,m)
Message
CIn
Message
TransmitC
m
COut
In
Rys. 2. Kanał komunikacyjny
W kanale komunikacyjnym (rys.2) następuje transport wiadomości pomiędzy agentami.
Tranzycje Transmit powodują pobranie znacznika (wiadomości) z miejsca Out agentanadawcy i dodanie znacznika (wiadomości) do miejsca In agenta-odbiorcy. Wiadomość
przekazywana jest tylko wówczas, gdy funkcja send określi, iŜ agent jest odbiorcą określonej
wiadomości.
4. Model agenta
KaŜdy agent zwykły modelowany jest jako instancja strony Agent (rys. 3). W czasie
symulacji uŜytkownik wybiera jeden z dziewięciu performatywów, który ma zostać
utworzony. W zaleŜności od wybranego rodzaju wiadomości jej utworzenie następuje
w jednej z podstron: prepare msgToA (performatywy kierowane do innych agentów
zwykłych), prepare msgToF (performatywy obsługiwane przez agenta wspomagającego) lub
prepare standby (performatyw standby). Tak utworzona wiadomość przekazywana jest do
miejsca Message Ready skąd moŜe zostać przesłana do kanału komunikacyjnego poprzez
odpalenie tranzycji Send Performative.
Wiadomość przychodząca moŜe być odebrana poprzez uruchomienie tranzycji Receive
Performative powodującej dodanie znacznika (wiadomości) do skrzynki agenta (MBOX).
W zaleŜności od rodzaju nadesłanego performatywu załączonego w wiadomości dalsza
obsługa następuje w podstronie answerAsk, answerRecommend, answerStreamall lub
answerStandby. W stanie początkowym aktywna jest jedynie tranzycja Choose performative.
Message
Message
m
Out
Out
m
msgToA
prepare
msgToA
msgToF
prepare
msgToF
i
1`askone++
1`askall++
1`advertise++
1`recruitone++
1`brokerone++
1`recommendone++
1`streamall++
1`broadcast++
1`standby
m
Send
Performative
m
standby
prepare
standby
Message
Ready
m
answerAsk
answer
ask
answerRecommend
answer
recommend
i
i
m
m
Init
m
answerStreamall
answer
streamall
answerStandby
answer
standby
m
MBOX
Out
Message
Init
{perf=p,sender=se}
Choose
performative
m
Receive
Performative
se
p
m
m
m
m
m
pstart()
Performatives
9
Performative
Agent 1
I/O
Name
In
In
Message
Rys. 3. Model agenta
5. Podstawowe performatywy
Podstawowe performatywy umoŜliwiają tworzenie prostych zapytań do bazy wiedzy agenta
[2].
a) ask-one – nadawca prosi odbiorcę o odpowiedź na zapytanie zawarte w polu :content.
Odpowiedź tworzona jest na podstawie bazy wiedzy odbiorcy.
b) tell – wskazuje iŜ w bazie wiedzy agenta–nadawcy zapisana jest treść określona
w polu :content.
c) ask-all – działa podobnie jak ask-one, jednak w odpowiedzi przesyłana jest kolekcja
wszystkich twierdzeń znajdujących się w bazie wiedzy odbiorcy, które odpowiadają
zapytaniu przesłanemu przez nadawcę w polu :content.
d) stream-all – jego działanie jest porównywalne do ask-all, jednak w tym przypadku
agent nie przesyła kolekcji odpowiadających twierdzeń w całości, ale w postaci serii
kolejnych performatywów. Ostatnią wiadomością przesyłaną w ramach serii jest
performatyw eos (end of stream).
Rys. 4. Sekwencja wymiany wiadomości z uŜyciem performatywu stream-all
W modelu sieci Petriego za tworzenie powyŜszych wiadomości odpowiedzialna jest
podstrona prepare msgToA (rys. 5). Na stronie tej, tranzycja create messege uruchamiana jest
tylko dla wyŜej wymienionych performatywów dzięki ustaleniu odpowiedniego warunku
wzbudzenia tranzycji (tzw. dozór, na rysunku warunek dozoru objęty jest w nawiasy
kwadratowe).
Message
Ready
Out
Message
create(#perf i,#sender i,re,id,0,"x")
1
id
create
message
i
Init
In
id+1
ID
Fusion 1
1
INT
re
[(#perf i=askone
orelse #perf i=askall
orelse #perf i=streamall)
andalso re<>(#sender i)]
Init
rstart()
Receivers 3
Name
Rys. 5. Tworzenie wiadomości wychodzącej (ask-one, ask-all, stream-all)
Przy tworzeniu wiadomości wykorzystywane jest dodatkowo miejsce ID, słuŜące do
generowania unikalnych wartości id dla kaŜdej z wysyłanych wiadomości. Odbywa się to na
zasadzie autoinkrementacji tzn. kolejne wiadomości otrzymują numer id o jeden większy od
poprzedniego. Miejsce to jest współdzielone przez wszystkie instancje agentów (tzw. fusion
place), co oznacza, Ŝe numer ostatnio wygenerowanego id jest globalny i dostępny we
wszystkich instancjach agentów. Z miejsce Receivers pobierana jest z kolei informacja na
temat odbiorcy wiadomości. Uruchomienie tranzycji create message skutkuje wywołaniem
funkcji create, która na podstawie otrzymanych parametrów, tworzy finalną wiadomość.
Odpowiedzi na performatywy answer-one, answer-all oraz stream-all generowane są na
podstronach answerAsk oraz answerStreamall. W przypadku performatywu answer-all
wszystkie odpowiedzi odpowiadające zapytaniu są łączone i przesyłane w postaci jednej
wiadomości. Inaczej dzieje się w przypadku performatywu stream-all, dla którego kaŜda
odpowiedź przesyłana jest jako osobna wiadomość.
Message
Message
Ready
Out
if (#perf m=askone)
then create(tell,#receiver m,#sender m,
0, #replywith m,"P")
else
create(tell,#receiver m,#sender m,
0, #replywith m,"P1 P2 ... PN")
create
answer
[#perf m=askone
orelse #perf m=askall]
m
MBOX
In
Message
Rys. 6. Generowanie odpowiedzi dla performatywów answer-one i answer-all
mList
answers
m1::mList
Create
answer
MessageList
1`create(tell,#receiver m,#sender
0, #replywith m,"P1")++
1`create(tell,#receiver m,#sender
0, #replywith m,"P2")++
1`create(tell,#receiver m,#sender
0, #replywith m,"P3")++
1`create(tell,#receiver m,#sender
0, #replywith m,"eos")
MBOX
In
Message
m
m1
Message
Ready
Out
Message
m,
m,
m,
m,
Get
[#perf m=streamall]
message
Rys. 7. Generowanie odpowiedzi dla performatywu stream-all
5.1. Warunkowe strumieniowe generowanie odpowiedzi na zapytania
W niektórych przypadkach nadawca zapytania chce otrzymywać odpowiedzi
strumieniowo (tak jak w przypadku performatywu stream-all) oraz dodatkowo mieć wpływ na
moment otrzymywania kolejnych odpowiedzi. Jest to moŜliwe dzięki poniŜej
przedstawionym performatywom [2]:
a) standby – nadawca zwraca się z prośbą o przygotowanie odpowiedzi na performatyw
zawarty w polu :content. Odpowiedź nie jest generowana natychmiastowo, ale dopiero
po tym jak odbiorca ogłosi gotowość do udzielenia odpowiedzi (za pomocą
performatywu ready)
b) ready – nadawca stwierdza gotowość do udzielenie odpowiedzi na performatyw
identyfikowany przez zawartość pola :in-reply-to
c) next – nadawca wskazuje, iŜ oczekuje na kolejną odpowiedź, która została
przygotowana (na co wskazuje wcześniej otrzymany performatyw ready)
Rys. 8. Sekwencja wymiany wiadomości z uŜyciem performatywu standby
d) rest – nadawca wskazuje, iŜ oczekuje na pozostałe odpowiedzi w postaci serii
performatywów zawartych w ramach jednej wiadomości.
e) discard – nadawca porzuca pozostałe odpowiedzi wygenerowane na wcześniejsze
polecenie standby.
Na diagramie z rysunku 8 agent B po przygotowaniu kolekcji odpowiedzi nie wysyła ich
natychmiast, ale pojedynczo w reakcji na kolejno nadchodzące performatywy next.
Zakończenie przesyłania serii wiadomości komunikowane jest performatywem eos. JeŜeli
agent A chciałby otrzymać w którymś momencie wszystkie pozostałe odpowiedzi z serii,
w postaci jednej wiadomości, moŜe to uzyskać poprzez wysłanie performatywu rest. Agent A
moŜe takŜe zrezygnować z otrzymywania kolejnych odpowiedzi z serii poprzez przesłanie
performatywu discard.
6. Performatywy wykorzystujące agenta wspomagającego
Agent wspomagający (Facilitator) jest specjalnym rodzajem agenta, który posiada
informacje o wszystkich istniejących agentach w danym systemie, ich adresach oraz
umiejętnościach. Dzięki temu ma on szerokie zastosowanie w wyszukiwaniu agentów
posiadających określone umiejętności i zasoby oraz udostępniających wyspecyfikowane
usługi. Z agentem wspomagającym w języku KQML związane są następujące performatywy
[2]:
a) broadcast – nadawca prosi odbiorcę, aby wysłał nadany performatyw do wszystkich
agentów z którymi ma połączenie. W przypadku modelowanego systemu performatyw
ten otrzymuje agent wspomagający, który przekazuje wiadomość do wszystkich
agentów w systemie.
b) advertise – nadawca ogłasza iŜ jest gotów udzielać odpowiedzi na określony rodzaj
performatywów (określony w polu :content).
c) broker-one – nadawca prosi odbiorcę, aby przekazał do wykonania załączony
performatyw jednemu agentowi, który posiada odpowiednie umiejętności i zasoby
(zazwyczaj agent posiadający takie atrybuty przesłał wcześniej performatytw advertise
z odpowiednimi parametrami). Na rysunku 9 agent wspomagający przekazuje
wykonanie performatywu ask-one(x) do agenta A poniewaŜ wcześniej zgłosił on za
pomocą performatywu advertise umiejętność obsługi takich zapytań. Następnie
odpowiedź kierowana jest do agenta wspomagającego, który przekazuje ją do
nadawcy zapytania tj. agenta B.
Rys. 9. Sekwencja wymiany wiadomości z uŜyciem performatywu broker-one
d) recommend-one – nadawca prosi odbiorcę o przekazanie nazwy jednego agenta,
który jest w stanie wykonać załączony performatyw.
e) recruit-one – działa identycznie jak broker-one, z tą róŜnicą iŜ odpowiedź przesyłana
jest bezpośrednio od agenta posiadającego odpowiednie umiejętności do nadawcy
performatywu recruit-one.
ShortMessage1
getMessage1(m)
Advertised
true
Empty
advertised 1
BOOL
(p1,c1,se1)
emp
Process
advertise
false
[#perf m=advertise]
(p1,c1,se1)
emp
(p1,c1,se1)
(p1,c1,se1)
create(sorry,F,se2,0,id1,c2)
Sorry
(p,p2,c2,se2,id1,id2)
m
[emp=true]
create(sorry,F,se2,0,id1,c2)
Sorry2
create(p2,se2,se1,
id2,0,c2)
Create
answer
recruit
[p=recruitone
andalso
p1=p2
andalso
c1=c2]
m
(p,p2,c2,se2,id1,id2)
getMessage2(m)
Processed
Message
MBOX
Out
Message
ShortMessage2
Create
answer
createf(tell,F,se2,0,id2,
recommend
p2,0,se1,c2)
[p=recommendone
andalso
p1=p2
andalso
c1=c2]
create(p2,F,se1,
id2,0,c2)
Proces
message
[#perf m=recruitone
orelse #perf m=recommendone
orelse #perf m=brokerone]
[p1<>p2
orelse
c1<>c2]
Message
FOut
Out
(p,p2,c2,se2,id1,id2)
(p,p2,c2,se2,id1,id2)
m
Receive
Performative
m
Create
(p,p2,c2,se2,id1,id2)
answer
broker
[p=brokerone
andalso
(id2,se2)
p1=p2
Wait
andalso
For
c1=c2]
Broker
INTxName
m
m
Message
(id2,re)
Foward
tell
FIn
In
[#perf m=tell
andalso
#inreplyto m=id2]
create(tell,F,re,0,#inreplyto m,#content m)
answer
broadcast
answerbroadcast
[#perf m=broadcast
andalso
#sender m<>re]
Rys. 10. Model agenta wspomagającego (Facilitator)
Model agenta wspomagającego znajduje się na podstronie Facilitator i zawiera
mechanizmy umoŜliwiające udzielanie odpowiedzi i przetwarzanie powyŜej omówionych
performatywów. JeŜeli agent wspomagający nie znajdzie agenta posiadającego odpowiednią
umiejętność to generowany jest w odpowiedzi performatyw sorry. Informacje
o umiejętnościach agentów przechowywane są w miejscu Advertised.
7. Podsumowanie
Idea języków opartych na performatywach określających ich funkcjonalność jest
wykorzystywana do wymiany informacji i wiedzy pomiędzy inteligentnymi jednostkami
programowymi, których przykładem są agenci. Na podstawie języka KQML międzynarodowa
organizacja standaryzacyjna FIPA (Foundation for Inteligent Physical Agents) opracowała
język FIPA ACL, będący obecnie standardem komunikacji agentów w systemach
wieloagentowych.
Stworzony model prezentuje moŜliwość zaprojektowania systemu wieloagentowego
z wykorzystaniem performatywów języka KQML. Przeprowadzono szereg symulacji
przesyłania wiadomości z uŜyciem wszystkich performatywów, a takŜe określono przestrzeń
dostępnych stanów systemu. PowyŜsza analiza nie doprowadziła do wykrycia Ŝadnych
tranzycji (zdarzeń) nieaktywnych, ani niepoŜądanych stanów systemu. Analiza przestrzeni
stanów wykazała moŜliwość osiągnięcia wszystkich stanów wynikających z funkcjonalności
systemu. PowyŜszy model moŜe być zaimplementowany w dowolnym języku programowania
wysokiego poziomu. Do tej pory język KQML został z powodzeniem uŜyty w środowiskach
projektowania i programowania agentów, takich jak Saci, JATLite, Jackal i innych. WaŜnym
elementem przedstawionego systemu, oprócz samego języka, jest wyróŜnienie specjalnego
rodzaju agenta wspomagającego (Facilitator), który dzięki posiadanej wiedzy na temat
moŜliwości i pracy innych agentów, moŜe koordynować współpracę agentów w ramach
całego systemu agentowego.
Przedstawiony model systemu wieloagentowego wykorzystujący wiadomości języka
KQML w pełnej wersji dostępny jest pod adresem http://wojtek.wsi.edu.pl/petri1. Do jego
uruchomienia wymagane jest narzędzie CPN Tools w wersji 2.2.0 lub wyŜszej.
Literatura
[1] Bradshaw J.: Software Agents. MIT Press, Cambridge 1995.
[2] DARPA Knowledge Sharing Initiative External Interfaces Working Group: DRAFT
Specification of the KQML Agent-Communication Language. 1995.
[3] Finin T., Labrou Y.: Agent Communication Language, First International Symposium
on Agent Systems and Applications and the Third International Symposium on Mobile
Agents, 1999.
[4] Finin T., Fritzson R., McKay D., McEntire R.: Proceedings of the third international
conference on Information and knowledge management - KQML as an agent
communication language, ACM Press, 1994, s. 456-463.
[5] Jensen K., Kristensen K., Lectures on Coloured Petri Nets – Modelling and
Validation of Concurrent Systems, University of Aarhus – Departament of Computer
Sciences, Aarhus 2006.
[6] Jensen K., Coloured Petri Nets, Springer-Verlag, Berlin 1997.
[7] Luck M.M., Ashri R., D'Inverno M.: Agent-Based Software Development. Artech
House, 2004.
Adres
Wojciech Pieprzyca, ul. Fredry 51, 43-346 Bielsko-Biała
[email protected]