Wykład10, 11. ACL - język komunikacji między agentami. ACL - Agent Communication Language

Transkrypt

1 Wykład10, 11 ACL - język komunikacji między agentami ACL - Agent Communication Language (na podstawie specyfikacji FIPA Publication date: 23rd October, th November, 1997 Copyright 1997,1998 by FIPA - Foundation for Intelligent Physical Agents Geneva, Switzerland) SPECYFIKACJE FIPA KOMUNIKACJA MIĘDZY AGENTAMI MECHANIZM TRANSPORTU WIADOMOŚCI STRUKTURA WIADOMOŚCI - FIPA ACL PROSTE I ZŁOŻONE AKTY KOMUNIKACYJNE SYNTAKTYKA ACL FORMALNE PODSTAWY SEMANTYKI ACL KATALOG AKTÓW KOMUNIKACYJNYCH OPIS FORMALNY I NARRACYJNY PROTOKOŁY INTERAKCJI Zofia Kruczkiewicz 1 Systemy wieloagentowe, Wykład 10-11

2 SPECYFIKACJE FIPA 1.1. normy- specyfikują zewnętrzne zachowania agenta i jego współpracę z innymi podsystemami ujętymi w specyfikacji FIPA 1.2. informacje o aplikacjach określające sposób użycia technologii FIPA Specyfikacje FIPA 97 składają się z siedmiu części: trzy części typu normy dotyczące podstawowych technologii agentowych: zarządzanie agentami, język komunikacji między agentami oraz integrację między agentami i nieagentowymi programami cztery zawierające informacje o aplikacjach prezentujących użycie specyfikacji typu normy: asystent podróżującego, asystent osoby, aplikacje audio-wizulne oraz transmisje, zarządzanie i pośredniczenie w sieci Zofia Kruczkiewicz 2 Systemy wieloagentowe, Wykład 10-11

3 Część 1 Agent Management Część ta opisuje normy dotyczące: istnieniem agentów operacyjnością agentów zarządzaniem agentami Deinicja platfomy agenta, pojęcie białej i żółtej ksiegi, przysyłaniem wiadomości oraz zarządzaniemcyklami życia agenta, akty komunikacyjne agenta wyrażaj.ace jego inteligentne zachowanie oraz odpowiadająca ontologia oraz język zawartości wiadomości Częśc 2 Język komunikacji agenta The FIPA Agent Communication Language (ACL) jest oparty na teorii aktów mowy: wiadomości są akcjami lub akty komuniakcyjne. Specyfikacja składa się : ze zbioru typów wiadomości, które zawierają opis pragmatyki tych wiadomości wyrażające stosunek typu BDI agenta do innego agenta/agentów. Opis jest przedstawiony w formie narracyjnej i formalnej opartej na lopgice modalnej. Ze zbioru opisów protokołów komunikacji Część 3 Integracja Agent/Software Część ta opisuje sposób integrowania oprogramowania nieagentowego z oprogramowaniem agentowym: Systemy baz danych Oprogramowanie sieciowe Oprogramowanie narzędziowe Zofia Kruczkiewicz 3 Systemy wieloagentowe, Wykład 10-11

4 Część 4 Osobisty Asystent Podróży Turystyka obejmuje następujące komponenty: Zaopatrzeniowiec Pośrednik Usługi osobiste Role te pełni agent typu PTA - Personal Travel Agent Zofia Kruczkiewicz 4 Systemy wieloagentowe, Wykład 10-11

5 Część 5 Osobisty Asystent Jest nim półautonomiczny agent typu PA (Personal Assistant) o nastepujących cechach: Realizuje usługi zaopatrzeniowe Informuje Zarządza podstawowymi danymi Organizuje rozrywkę Planuje czas przeznaczony na pracę i odpoczynek Organizuje spotkania Częśćt 6 - Przedsięwzięcia Audio/Video i transmisje Wybór właściwych programów uwzględniając preferencje użytkownika Negocjuje zmiany w programach Część 7 Zarządzanie i zabezpieczanie sieci Dostarczanie usług końcowym użytkownikom zgodnie z zasadą jakości usług i kosztu usług Idea VPN (Virtual Private Network) połączenia z wybranymi użytkownika na ich życzenie Zapewniają te usługi trzy typy agentów: The Personal Communications Agent (PCA) reprezentuje interes użytkownika The Service Provider Agent (SPA) - reprezentuje interes zaopatrzeniowca w zakresie usług The Network Provider Agent (NPA) reprezentuje interesy zaopatrzeniowca sieci Zofia Kruczkiewicz 5 Systemy wieloagentowe, Wykład 10-11

6 KOMUNIKACJA MIĘDZY AGENTAMI Cechy komunikacji: Komunikację rozważa się na poziomie aplikacji w zakresie spełnianiej misji przez agenta operując jego mentalnymi atrybutami: Belief (stosunek typu wiara) oznacza zbiór propozycji, które agent akceptuje i zbiór propozycji, które agent nie akceptuje podczas negocjacji (stan wiary i niewiary w odniesieniu do propozycji) Uncertainty (stosunek typu niepewność) oznacza zbiór propozycji, które agent akceptuje lub nie akceptuje z pewnym poziomem niepewności, czy są prawdziwe lub fałszywe. Oznacza to, że agent przyjmuje model negocjacji, gdy przedmiotem jest niepewna informacji bez uciekania się do modeli statystycznych Intention (stosunek typu intencja) oznaczają wybór lub właściwość lub zbiór właściwości, które agent życzy sobie, aby były prawdziwe i te, w ktore agent nie wierzy. Intencje są przedstawiane w postaci planu akcji (np. Mapy stanów ), wyznaczonych przez wybór agenta, które wynikają ze stanu świata rzeczywistego Np. W odniesieniu do danych propozycji p, stan wiary p, stan niewiary p, stan niepewności p i stan pewności p wykluczają się wzajemnie. Dodatkowo, agents wie i jest zdolny do wykonania pewnych akcji. W rozproszonych systemach agent jest jedynie zdolny do spełnienia swoich intencji za pomocą wpływu wywieranego na innych agentów do wykonania akcji. Wpływ wywierany na innych agentów osiąga się za pomocą specjalnej klasy akcji zwanych aktami komunikacyjnymi (communicative acts). Polega to na wysyłaniu komunikatów zawierających zakodowany ak przez nadawcę do odbiorcy. Ważną rolę odgrywa budowa wiadomości oraz posiadanie tej samej wiedzy na temat BUI Np. Agent i wierzy, że lepiej jest czytać książki niż oglądać TV i uważa, że agent j będzie uważał podobnie. Agent i w ACL inform informuje j swojej o wierze typu prawda. Agent j na podstawie semantyki inform wie, że agent i chce wpłynąć na jego intencje dotyczące wiary w wartość czytania książek, ale dla agenta j przyjęcie wiary agenta i może stanowić pewien problem. Zofia Kruczkiewicz 6 Systemy wieloagentowe, Wykład 10-11

7 Stąd ważnymi problemami są: transport wiadomości między agentami struktura wiadomości syntaktyka transporu wiadomości ACL w strumieniu bajtów katalog standardowych aktów komunikacyjanych zbiór i definicja podstawowych protokołów komunikacji zawierających zbiór wiadmości definicja modelu komunkacji MECHANIZM TRANSPORTU WIADOMOŚCI Usługę transportu wiadomości spełnia system zarządzania agentami Wymagania usług transportu wiadomości (niezbędne): a) przesyłanie zakodowanej wiadomości w postaci sekwencji bajtów b) usługi transportu powinny być niezawodne, dokładne, uporządkowane (kolejność) c) nie spełnienie tych własności powinno być sygnalizowane d) agent ma opcję wyboru sposobu odebrania wiadomości: uśpienie lub oczekiwania na wiadomość (tryb synchroniczny) lub wykonywanie innych czynności podczas oczekiwania na odpowiedź e) czas przeterminowania nie jest parametrem aktu komunikacyjnego, tylko systemu usług transporu wiadomości f) po wykryciu błędów, system może wysłać informację o tym fakcie do nadawcy w postaci wiadomości o błędzie g) system zapewnia wybór poprawnego mechanizmu transportu (TCP/IP, SMTP, http, etc) Kodowanie wiadomości : 7-bitowy odpowidający standardowi ISO/IEC 2022 oraz wykorzystuje inne sposoby kodowania znaków specjalnych: ISO/IEC 646 (US ASCII) jest zastosowane do G0; ISO/IEC 6429 jest zastosowane do C0 ; G0 jest wyrażone w GL; C0 jest wyrażone w CL; SPACE w 2/0 (0x20) oraz DELETE w 7/15 (0x7f) Zofia Kruczkiewicz 7 Systemy wieloagentowe, Wykład 10-11

8 STRUKTURA WIADOMOŚCI - FIPA ACL Typ wiadomości jest zgodny z typem zawartości wiadomości, którą powinna charakteryzować: kompletność prostota zwięzłość. Wiadomość reprezentuje akt komunikacyjny, jest jego synonimem Semantyka języka komunikacji pownien być oparta na precyzyjnym formaliźmie, pozbawionym sprzeczności. W praktyce podstawy formalne są zrealizowane w postaci protokołów komunikacji (w postaci narracyjnej), a nie w postaci formalnej semantyki (semantyki operacyjnej) Wymagania wobec agentów Wymaganie 1: Agenty mogą wysłać not-understood, jeśli otrzymają wiadomość, której nie rozpoznają lub nie są w stanie odczytać zawartości wiadomości. Agenty muszą odebrać i obsłużyć taką wiadomość Wymaganie 2: Agent powinien posiadać pre-definiowany zbiór typów wiadomości i protokołów, zgodnych z definicją aktów semantycznych. Wymaganie 3: Nie należy przedefiniować znaczenia istniejących predefiniowanych aktów komunikacyjnych Requirement 4: Agenty mogą wprowadzać nowe akty komunikacyjne zrozumiałe przez odbiorcę, jednak nie wolno im nadawać znaczenia istniejących aktów komunikacyjnych. Requirement 5: Agent powinien poprawnie formułować zawartość generowanej wiadomości oraz z taką samą poprawnością odczytywac wiadomości. Zofia Kruczkiewicz 8 Systemy wieloagentowe, Wykład 10-11

9 Struktura wiadomości s-wyrażenie Akt komunikacyjny wiadomości odpowiada aktowi KQML zwanym performative Zofia Kruczkiewicz 9 Systemy wieloagentowe, Wykład 10-11

10 Parametry wiadomości Obowiazujacym parametrem jest receiver, ale wiadomość jest sensowana wtedy, gdy ma więcej parametrów Tab. 1 Pre-definiowane parametry wiadomości :Parametry wiadomości :sender :receiver :content :reply-with :in-reply-to :envelope :language :ontology :reply-by :protocol :conversation-id Znaczenie: Nazwa agenta nadającego akt komunimacyjny. Nazwa agenta, do którego wysylana jest wiadomość. Może to być pojedyncza nazwa lub zbiór nazw agentów - multicasting Zawartość wiadomości, czyli treść akcji Wprowadza wyrażenie, które identyfikuje oryginalną wiadomość. Może być używane w wątku konwersacji, jeśli jednocześnie prowadzi się kilka dialogów jednocześnie Np. Jeśli agent i wysyła wiadomość do agenta j wiadomość, która zawiera :reply-with query1, agent j powinien odpowiedzieć :in-reply-to query1. Oznacza wyrażenie, które odpowiada wcześniejszej akcji, dla której stanowi odpowiedź. Oznacza wyrażenie, które jest użyteczne dla systemu usług transportowych i zawiera czas wysłania, czas odbioru, trasę itp. Struktura koperty jest listą par słów kluczowych, które oznaczają pewne aspekty usług wiadomości Oznacza schemat kodowania zawartości wiadomości. Oznacza ontologię, która jest używana do podania znaczenia symboli używanych w wyrażeniu. Oznacza czas i/lub datę wyrażenia, ktora oznacza ostatni czas, kiedy wysyłający agent wystapił w roli odpowiadajacego Wprowadza identyfikator, który oznacza protokół, który zastosował wysyłajacy agent. Protokół dodatkowo podaje kontekst wiadomości. Wprowadza wyrażenie, które jest używane do identyfikacji sekwencji wychodzących wiadomości, które tworzą konwersację. Konwersacja może być użyta do zarządzania strategią komunikacji i aktywności agenta oraz do dodatkowej interpretacji znaczenia wiadomości Zofia Kruczkiewicz 10 Systemy wieloagentowe, Wykład 10-11

11 Zawartość wiadomości Zawartość wiadomości odpowiada przeznaczeniu aktu komunikacyjnego. Wiadomość czyli akt komunikacyjny jest zdaniem, natomiast zawartość jest gramatycznym obiektem zdania. Zawartość jest zapisana w języku podanym w parametrze :language. Wymaganie 6: Ogólnie, język zawartości wiadomości musi wyrażać propozycje, obiekty i akcje. Język ten nie musi wyrażać nic więcej, jedynie typy akcji: propozycje informowanie, żądania itp. Stany propozycji - true lub false Obiekty rzeczy abstrakcyjne lub konkretne Akcje agent staje sie aktywny (iota <variable> <term>) np. iota x(p x) oznacza, że x taki, że P [jest prawdziwe] dla x. Słowo iota jest konstruktorem dla termów. Definicja 1: Język zawartości wiadomości FIPA jest oparty na gramatyce s-wyrażeń lub jej podgramatyce i umożliwia wyrażanie propozycji, obiektów i akcji odpowiadających cyklowi życia agenta. Wymaganie 7: Agent jest zobowiązany do wyrażania swoich możliwości wymieniając wiadomości napisane za pomocą języka zawartości wiadomości i stosując określoną ontologię-oznaczone jako fipa-agent-management Reprezentowanie zawartości wiadomości Zagnieżdzony łańcuch \"Ian\" zawiera znaki \" w zawartości wiadomości ograniczonej znakami " " (inform :content "owner( agent1, \"Ian\" ) " :language Prolog ) lub podanie długości łańcucha do zawartości wiadomości (przez zdaniem reprezentującym wiadomość) (inform :content #22"owner( agent1, "Ian" ) :language Prolog ) Użycie MIME do wyrażania dodatkowej zawartości wiadomości Wyrażanie wiadomości zawierającej informację o błędzie w języku angielskim na język japoński może okazać się bardzo niewygodne < English tekst> na < Japanese tekst> The Multipurpose Internet Mail Extensions (MIME) standard jest przeznaczony do wyrażania kontekstu internetowych wiadomości [Freed & Borenstein 96]. Syntaktyka wiadomości MIME jest odmienna od gramatyki ACL, jednak może stanowić rozszerzenie informacji zawartej w podstawowym wyrażeniu ACL (rozszerzenie syntaktyki ACL) Zofia Kruczkiewicz 11 Systemy wieloagentowe, Wykład 10-11

12 PROSTE I ZŁOŻONE AKTY KOMUNIKACYJNE SYNTAKTYKA ACL Proste akty komunikacyjne są atomowe. Złożone akty komunkacyje są budowane z prostych aktów komunikacyjnych w następujący sposób (w języku SL, ktory spełnia wymagania dotyczące gramatyki s-wyrażeń): tworząc jeden akt komunikacyjny jako obiekt innego aktu komunikacyjnego np. "I request you to inform me whether it is raining" - jako akt komunikacyjny typu query-if. Używając composition operator ; np. a ; b (b po a) Używając composition operator do niedeterministycznego wyboru akcji a b (albo a, albo b) Syntaktyka wiadomości - format standardu EBNF Prawa gramatyki Przykłady Końcowy znak "(" Wyrażenie nieterminalne zapisane kapitalikami Expression Opcjonalna konstrukcja ["," OptionalArg ] Alternatywa (pionowa kreska) Integer Real Gwiazdka oznacza zero lub więcej powtórzeń Digit * poprzedzającego wyrażenia Plus oznacza jeden lub więcej powtórzeń Alpha + poprzedzającego Nawiasy służą do grupowania ekspansji ( A B ) * Produkcje są zapisane za pomocą ANonTerminal = "an nieterminalnych nazw z prawej strony, expansion". ekspansji z prawej strony, końcowych jako końcowa postać zapisu produkcji Reguły gramatyczne dla znaków leksykalnych są podobne, jednak są jeszcze dodatkowe reguły leksykalne: Reguły leksykalne Zbiór znaków Zakres znaków Tylda oznacza uzupełnienie w postaci zbioru znaków, jeśli jest pierwszy znak Post-fiksowy znak zapytania oznacza, że poprzedzające wyrażenie leksykalne jest opcjonale (może pojawic się zero lub jeden raz) Example ["a", "b", "c"] ["a" - "z"] [ ~ "(", ")"] ["0" - "9"]? ["0" - "9"] Zofia Kruczkiewicz 12 Systemy wieloagentowe, Wykład 10-11

13 Reguły gramatyczne syntaktyki wiadomości ACL ACLCommunicativeAct = Message. Message = "(" MessageType MessageParameter* ")". MessageType = "accept-proposal" "agree" "cancel" "cfp" "confirm" "disconfirm" "failure" "inform" "inform-if" "inform-ref" "not-understood" "propose" "query-if" "query-ref" "refuse" "reject-proposal" "request" "request-when" "request-whenever" "subscribe". MessageParameter = ":sender" AgentName ":receiver" RecipientExpr ":content" ( Expression MIMEEnhancedExpression ) ":reply-with" Expression ":reply-by" DateTimeToken ":in-reply-to" Expression ":envelope" KeyValuePairList ":language" Expression ":ontology" Expression ":protocol" Word ":conversation-id" Expression. Expression = Word String Number "(" Expression * ")". Zofia Kruczkiewicz 13 Systemy wieloagentowe, Wykład 10-11

14 MIMEEnhancedExpression optional extension. See Annex D. KeyValuePairList = "(" KeyValuePair * ")". KeyValuePair = "(" Word Expression ")". RecipientExpr = AgentName "(" AgentName + ")". AgentName = Word Word "@" URL. URL = Word. Lexical rules Word String = [~ "\0x00" - "\0x20", "(", ")", "#", "0"-"9", "-", "@"] [~ "\0x00" - "\0x20", "(", ")"] *. = StringLiteral ByteLengthEncodedString. StringLiteral = "\"" ( [~ "\"" ] "\\\"" )* "\"". ByteLengthEncodedString = "#" ["0" - "9"]+ "\"" <byte sequence>. Number = Integer Float. DateTimeToken = "+"? Year Month Day "T" Hour Minute Second MilliSecond (TypeDesignator?). Year Month Day Hour Minute Second MilliSecond TypeDesignator = Digit Digit Digit Digit. = Digit Digit. = Digit Digit. = Digit Digit. = Digit Digit. = Digit Digit. = Digit Digit Digit. = AlphaCharacter. Digit = ["0" "9"]. Zofia Kruczkiewicz 14 Systemy wieloagentowe, Wykład 10-11

15 Wyjaśnienia a) przyjęto standardową definicje typów całkowitych i zmiennoprzecinkowych b) słowa kluczowe są niezależne c) długość łańcucha wynika kontekstu nagłówka # liczba całkowita" i zakłada się, że znaki są 8-bitowe d) wiadomość powinna być sformułowana zgodnie z zasadami gramatyki SL e) łańcuchy powinny być zapisane w gramatyce ISO/IEC 2022 wyrażonej w notacji EBNF, znaki w kodach ESC (0x1B), SO (0x0E) oraz SI (0x0F f) Znaki czasu są oparte na formacie ISO8601 rozszerzone do czasu absolutego i względnego i opóźnień milisekundowych. Czas względny jest wyróżniany za pomocą znaku +. Desygnator UTC jest znakiem Z i jest stosowany przy niejednoznacznym określaniu czasu Np. 8 :30 am on April 15th 1996 czasu lokalnego jest zapisany : lub w UTC T T Z lecz 1 godzina, 15 minut i 35 milisekund jest zapisane jako T g) nazwy agentów są wyrażane w standardzie FIPA 97 ; poprawnie sformułowany adres URL jest następujący : AccessTypeSpecifier "://" InternetAddress ":" PortNumber "/" Identifier Zofia Kruczkiewicz 15 Systemy wieloagentowe, Wykład 10-11

16 FORMALNE PODSTAWY SEMANTYKI ACL Wprowadzenie Model przedstawiany jedynie prezentuje znaczenie pewnych elementów komunikacji między agentami w odniesieniu do zastosowanego języka. Wymiana informacji między dwoma agentami SL JĘZYK SEMANTYKI ACL Podstawy języka: p, p1,... formuły zamknięte reprezentujące propozycje φ i ψ są schematami formuł i i j są zmiennymi reprezentującymi agentów =φ oznacza, że φ jest prawidłowy. Mentalny model agenta oparty jest na trzech postawach : belief, uncertainty and choice i czasem na goal). Są one reprezentowane przez operatory B, U, i C. Formuły oparte na tych operatorach są odczytywane następująco: B ip i (bezwarunkowo) wierzy (że) p U ip i jest niepewny, czy co do p, ale myśli, że p jest pewniejszy niż p C ip i oczekuje, że p obecnie działa Mówiąc o złożonych planach, zdarzeniach lub akcjach używa sie następujących wyrażeń: a 1 ; a 2 is a sequence w której a 2 wystąpi po a 1 a 1 a 2 is a nondeterministic choice, w której albo wydarzy się a 1 lub a 2, ale nie razem. Zofia Kruczkiewicz 16 Systemy wieloagentowe, Wykład 10-11

17 Operatory Feasible, Done i Agent, Single są wprowadzone w celu wnioskowania o akcjach: Feasible( a, p ) znaczy, że a może się wydarzyć, i jeśli a wydarzy się, p będzie prawdziwe zaraz po zakończeniu a Done( a, p ) znaczy, że a już sie wydarzyło i p było prawdziwe tuż przed wykonaniem a Agent( i, a ) znaczy, że i oznacza tylko działanie agenta, lub działanie, które dopiero się wykona podczas zdarzenia a. Single( a ) oznacza, że a oznacza wyrażenie akcji, które niejest sekwencją. Każda indywidualna akcja jest Single. Złożona akcja a ; b nie jest Single. Złożona akcja a b jest Single, jeśli a i b obie są Single. Formuła dotycząca celu PGi p oraz Iip oznacza, że i ma p jako trwały (P) cel (G) i i ma intencję (I) podjęcia p Formuły można zagnieżdżać: Ui Bj Ii Done(a, Bi p ) oznacza, że agent i prawdopodobnie uważa, że agent j wierzy, że i ma intencję, że akcja a bedzie wykonana, kiedy i będzie wierzyć w p Podstawową własnością logiki jest modelowanie agenta zgodnie z jego mentalną postawą - czyli z tego, że prawdziwy jest schemat formuły φ wynika, że agent bezwarukowo wierzy w schemat formuły φ, i z tego, że agent bezwarunkowo wierzy w schemat formuły φ, wynika że jest ona prawdziwa. =φ Bi φ, gdzie φ jest schematem formuły, w którą bezwarunkowo wierzy agent i Skróty i) Feasible( a ) Feasible( a, True ) ii) Done( a ) Done( a, True ) iii) Possible( φ ) ( a)feasible( a, φ ) po wykonaniu akcji a możliwe jest, że schemat formuły φ jest prawdziwy iv) Bifiφ Biφ Bi φ albo agent i wierzy w schemat formuły φ lub nie wierzy w schemat formuły φ v) Brefiδ(x) ( y)bi (ιx)δ(x) = y gdzie ι jest operatorem definiującym opis i (ιx)δ(x) są czytane (x który jest) δ. Brefiδ(x) oznacza, że agent i wierzy, że wiadomo że (x który jest) δ, jest równy y. vi) Uifiφ Uiφ Ui φ Uifiφ oznacza, że gent i is niepewny (w sensie podanym wyżej), czy schemat formuły φ jest prawdziwy lub jest niepewny, czy schemat formuły jest nieprawdziwy φ. vii) Urefiδ(x) ( y)ui (ιx)δ(x) = y Urefiδ(x) oznacza to samo co Brefiδ(x), za wyjątkiem, jeśli i ma niepewny stosunek do δ(x) równego y zamiast wiary viii) ABn,i,jφ BiBjBi φ wprowadza koncepcję o alterantywnej wierze, n (dodatnia liczba całkowita) jest liczbą operatorów B występujących naprzemian między i oraz j. Zofia Kruczkiewicz 17 Systemy wieloagentowe, Wykład 10-11

18 Termin "knowledge" jest używany w sensie "wierzy lub jest niepewny". Semantyka Modelu Własność 1 Jeśli agent ma intencje otrzymania odpowiedzi, to w celu wyrażenia jego możliwości planowania, agent musi spełniać nastepujące własności: Niech ak jest takim aktem, że: i) ( x) Bi ak = x, //agent i wierzy, że dla danego x formuła ak jest spelniona przez x ii) p is the RE of ak and // p jest racjomalnym efektem aktu ak iii) Ci Possible( Done(ak) ); //agent i wybiera jedynie możliwy akt ak do wykonania wtedy zachodzi formuła: Ii p Ii Done(a 1... a n ) gdzie a 1,...,a n są aktami typu ak. Własność ta mówi, że jeśli agent ma intencję osiągnięcia celu p, generuje intencję realizacji tego celu. Czyli, jeśli racjonalny efekt jakiegoś aktu spełnia cel agenta, agent nie ma powodów, aby nie zrealizować tego aktu. Zbiór warunków przed dla aktu komunikacyjnego składa się z dwóch zbiorów: warunki zdolności wykonania oraz warunki wynikające z kontekstu. Własność 2 Własność wyrażająca intencje agenta, że po wykonaniu akcji a będzie on wierzył lub będzie wierzył i miał intencję. = Ii Done(a) Bi Feasible(a) IiBi Feasible(a) Własność 3 Z tego, że agent ma intencję wykonania akcji a, wynika, że agent ma intencje uzyskania racjonalnego efektu związanej z akcją a. = Ii Done(a) Ii RE(a) gdzie RE(a) to racjonalny efekt akcji a. Własność 4 Komplementarny efekt planowania aktu komunikacyjengo Agent i wierzy, że z tego że akt a może być wykonany i że uczestniczy w nim agent j wynika, że agent j ma intencję otrzymania racjonalnego efektu tego aktu efekt intencyjny: = Bi( Done(a) Agent( j, a ) Ij RE(a) ) Zofia Kruczkiewicz 18 Systemy wieloagentowe, Wykład 10-11

19 Inna, pełna postać własności 4: Agent i wierzy, że z tego że akt a może być wykonany i że uczestniczy w nim agent j wynika, że agent j ma intencję, że agent i wierzy, że agent j ma intencję otrzymania racjonalnego efektu tego aktu. = Bi( Done(a) Agent( j, a ) Ij Bi Ij RE(a) ) Własność 5 Niektóre skutki wykonania FP (Persistent Feasibility) ujawniają się po wykonaniu aktu komunikacyjnego, stąd formuła ta określa własności dla FP. Agent i wierzy, że z tego że wykonany został akt a wynika, że pojawią się możliwe skutki jego działania = Bi( Done(a) FP(a) ) Notacje Akt komunikacyjy jest reprezentowany nastepująco: <i, Act( j, C )> FP: φ 1 RE: φ 2 gdzie i jest inicjatorem akcji, j jest uczestnikiem, Act jest nazwą aktu, C reprezentuje semantyczny kontekst lub proponowany kontekst i φ 1 and φ 2 są propozycjami, FP jest możliwym skutkiem działania Act, RE jest racjonalnym efektem działania Act. Przykład ( Act :sender i :receiver j :content C ) Zofia Kruczkiewicz 19 Systemy wieloagentowe, Wykład 10-11

20 Uwagi osymbolach używanych w formule Symbol : A act φ P Użycie: Oznacza akcję Np a = <i, inform(j, p)> Oznacza typ akcji Np. act = inform(j, p) Stąd, jeśli i wtedy Oznacza schemat formuły Konkretna formuła a = <i, inform(j, p)> act = inform(j, p) a =<i, act> φ jest schematem formuły, czyli zmienną oznaczającą formułę, p jest gotową formułą Pomocnicze definicje a) Możliwe jest wystąpienie aktu e, gdy prawdziwa jest formuła φ, co oznacza, że przed wykonaniem aktu e formuła była nieprawdziwa, natomiast po wykonaniu aktu e formuła stała się prawdziwą Enables(e, φ ) = Done( e, φ ) φ b) Nigdy nie wykona się akt e, jeśli prawdziwy jest schemat formuły φ, co oznacza, że jeśli akty e1 i e2 są wykonywane sekwencyjnie po e, to z tego wynika, że akt e2 może wykonać się tylko wtedy, gdy nieprawdziwa jest formuła φ. Has-never-held-since( e', φ ) = ( e1) ( e2) Done( e'; e1 ; e2 ) Done( e2, φ ) Zofia Kruczkiewicz 20 Systemy wieloagentowe, Wykład 10-11

21 KATALOG AKTÓW KOMUNIKACYJNYCH OPIS FORMALNY I NARRACYJNY Kategorie aktów komunikacyjnych Communicative act Information passing Requesting information Negotiation Action performing Error handling accept-proposal + agree + cancel + cfp + confirm + disconfirm + failure + inform + inform-if (macro + act) inform-ref (macro + act) not-understood + propose + query-if + query-ref + refuse + reject-proposal + request + request-when + request-whenever + subscribe + Zofia Kruczkiewicz 21 Systemy wieloagentowe, Wykład 10-11

22 accept-proposal Działanie: Zawartość wiadomości : Opis: Akcja akceptowania poprzednio odebranej propozycji wykonania akcji Krotka zawierająca akcje do wykonania i warunki akceptacji propozycji Accept-proposal jest całkowitą zgodą na poprzednio złożoną propozycję najczęściej w akcie propose. Agent wysyłając zgodę informuje odbiorcę o warunkach wykonania przez niego akcji. Model formalny Np. Odebrano propozycję hold a meeting anytime on Tuesday. Wysyłając akceptacje propozycji podaje się dodatkowy warunek: godzinę spotkania np Ten warunek nie był uwzględniony podczas składania propozycji, ale jest akceptowany przez składającego propozycję. <i, accept-proposal(j, <j, act>, φ))> <i, inform(j, Ii Done(<j, act>, φ))> FP : B i α B i (Bif j α Uif j α) RE : B j α gdzie α = I i Done(<j, act>, φ) i informuje j, że i ma intenecję, że j wykona akcję, jeśli podane warunki staną się prawdziwe (φ) Przykład Agent i informuje j, że akceptuje jego ofertę, która dotyczy skierowania podanego tytułu multimedialnego 1234 do kanału 19, kiedy klient 78 będzie gotowy. Agent i inform j o tym fakcie: (accept-proposal :sender i :receiver j :in-reply-to bid089 :content ( (action j (stream-content movie )) (B j (ready customer78)) ) :language sl) Zofia Kruczkiewicz 22 Systemy wieloagentowe, Wykład 10-11

23 agree Dzialanie: Zawartość wiadomości : Opis: Model formalny Przykład Akcja wyrażania zgody na akcje, które będą wykonywane w przyszłości Krotka zawierająca identyfikator agenta, wyrażenie reprezentujące akcję do wykonania i propozycję warunków akceptacji Agree jest zgodą na odebraną wcześniej wiadomosć typu request z poleceniem wykonania akcji. Agent wysyłajacy zgodę zapowiada wykonanie akcjji tylko wtedy, gdy podane warunki wstępne będą prawdziwe. <i, agree(j, <i, act>, φ))> <i, inform(j, Ii Done(<i, act>, φ))> FP : B i α B i (Bif j α Uif j α) RE : B j α gdzie α = I i Done(<i, act>, φ) Agent i informuje j, że ma intencję wyrażenia zgody na na wykonanie prze siebie akcji, pod warunkiem, że pewne warunki będą spełnione (φ) Agent i (kolejkowanie zadań) żąda od agenta j (robot), aby przestawił pudło w inne miejsce- j zgadza się, lecz zaznacza, że to zadanie ma niski priorytet. (request :sender i :receiver j :content (action j (deliver box017 (location 12 19))) :protocol fipa-request :reply-with order567 ) (agree :sender j :receiver i :content ((deliver j box017 (location 12 19)) (priority order567 low)) :in-reply-to order567 :protocol fipa-request ) Zofia Kruczkiewicz 23 Systemy wieloagentowe, Wykład 10-11

24 cancel Działanie: Zawartość wiadomości : Opis: Model formalny Kasowanie akcji, które mają charakter przejściowy Akcja określona w zawartości wiadomości jest kasowana Kasowanie umożliwia przerwanie wykonywanej akcji, której żądano wcześniej. Zakłada się, że akcja przerwana jeszcze się nie wykonała lub jeszcze nie zaczęła się. W odpowiedzi na kasowanie wysyła się wiadomość typu refuse do wysyłającego wcześniej żądanie wykonania akcji. <i, cancel(j, a)> <i, disconfirm(j, I i Done(a))> FP : I i Done(a) B i (B j I i Done(a) U j I i Done(a)) RE : B j I i Done(a) Kasowanie jest akcją kasowania dowolnej żądanej akcji. Oznacza to, że agent i żądał, aby agent j wykonał pewne akcje, jeśli określone warunki byłyby spełnione. Jest to efekt informowania przez i agenta j o swoich intencjach. Kiedy i odrzuca swoje intencje, informuje o tym j za pomocą aktu disconfirm. Przykład Agent j0 prosi i o skasowanie poprzedniej akcji request-whenever (cancel :sender j0 :receiver i :content (request-whenever :sender j ) ) Agent j1 prosi i o skasowanie akcji żądanej poprzednio w podanej konwersacji: (cancel :sender j1 :receiver i :conversation-id cnv0087 ) Zofia Kruczkiewicz 24 Systemy wieloagentowe, Wykład 10-11

25 cfp Działanie: Zawartość wiadomości : Opis: Model formalny Zapraszanie do podawania propozycji do wykonania podanej akcji Krotka zawiera wyrażenie określające akcję do wykonania oraz warunki wykonania akcji CFP jest akcją podejmowania negocjacji przez zapraszanie do składania propozycji. Protokół negocjacji jest określany za pomocą parametru wiadomości typu :protocol. Agent, który otrzyma cfp, odpowiada wiadomością typu propose, z podaną propozycją oraz warunkami jej wykonania propozycja musi być kompatybilna z warunkami podanymi w cfp. Np. cfp zawiera propozycję wyjazdu pociagiem, stąd propozycja nie może dotyczyć lotu samolotem, natomiast może określić typ pociągu (normalny, ekspres..) <i, cfp( j, <j, act>, φ(x) )> <i, query-ref(j,ιx (I i Done(<j, act>, φ(x)) (I j Done(<j, act>, φ(x))))> FP : Bref i (ιx α(x)) Uref i (ιx α(x)) B i I j Done(<j, Inform-ref(i,ιx α(x))>) RE : Done(<j, Inform(i,ιx α(x) = r 1 )> <j, Inform(i,ιx α(x) = r k ) >) gdzie α(x) = I i Done(<j, act>, φ(x)) I j Done(<j, act>, φ(x)) Agent i pyta agenta j: "Jakie jest x, dla którego wykonasz akt a, bo będzie prawdziwe φ (x)?" Przykład Agent j składa propozycję agentowi i sprzedania mu 50 skrzynek śliwek (cfp :sender j :receiver i :content ((action i (sell plum 50)) true) :ontology fruit-market ) Zofia Kruczkiewicz 25 Systemy wieloagentowe, Wykład 10-11

26 confirm Działanie: Zawartość wiadomośc i: Opis: Nadawca informuje odbiorcę, że podana propozycja jest prawdziwa, gdy odbiorca jest niezdecydowany, czy propozycja jest prawdziwa Propozycja Agent nadawca: wierzy w prawdziwość propozycji wyraża intencję, że odbiorca tak samo wierzy w prawdziwość propozycji wierzy, że odbiorca ma pewien poziom nieufności dotyczącej prawdziwości propozycji Dwie pierwsze własności oznaczają, że odbiorca zna propozycję, natomiast trzecia oznacza otrzymanie przez j wiadomości typu inform, która wyjaśnia wątpliwości agenta j. Z punktu widzenia odbiorcy, wiadomość typu confirm określa jego wiarę, że: nadawca wierzy w propozycje podane w zawartości wiadomości nadawca oczekuje, że odbiorca również wierzy w propozycje Model formalny Przykłady Prosty akt komunikacyjny <i, confirm( j, φ )> FP: B i φ B i U j φ RE: B j φ Agent i utwierdza agenta j, że prawdą jest, że dzisiaj pada śnieg. (confirm :sender i :receiver j :content "weather( today, snowing )" :language Prolog) Zofia Kruczkiewicz 26 Systemy wieloagentowe, Wykład 10-11

27 disconfirm Działanie: Zawartość wiadomośc i: Opis: Model formalny Nadawca informuje odbiorcę, że dana propozycja jest fałszywa, gdy odbiorca uważa, że ta propozycja jest prawdziwa Propozycja Ten akt komunikacyjny jest używany, wtedy gdy jeden agent chce zmienić mentalność drugiego agenta Nadawca: wierzy, że pewne propozycje są fałszywe ma intencję, że odbiorca także zacznie wierzyć, że propozycje są fałszywe wierzy, że odbiorca albo wierzy w propozycje albo nie jest pewny czy są prawdziwe. Dwie pierwsze właściwości oznaczają, że nadawca jest szczery i ma intencję, że odbiorca zna propozycje. Ostatnia właściwość oznacza, że agent powinien wysłać akt confirm, inform lub disconfirm, ale ten ostatni akt jest użyty najwłaściwiej, gdy odbiorca wierzy w propozycje lub jest niepewny co do propozycji Z punktu widzenia odbiorcy, wiadomość disconfirm upoważania go do wiary, że: nadawca wierzy, że propozycje są fałszywe nadawca życzy sobie, aby odbiorca także uwierzył, że propozycje są fałszywe Zmiana przekonań odbiorcy jest funkcją ufności obiorcy w opowiedzi na szczerość i pewność nadawcy. //Prosty akt komunikacyjny <i, disconfirm( j, φ )> FP: B i φ B i (U j φ B j φ) RE: B j φ Przykład Agent i, wierząc, że j myśli, że rekin jest ssakiem, próbuje zmienić jego przekonanie (disconfirm :sender i :receiver j :content (mammal shark)) Zofia Kruczkiewicz 27 Systemy wieloagentowe, Wykład 10-11

28 failure Działanie: Zawartość wiadomości : Opis: Model formalny Przykład Akt, w którym jeden agent przekazuje informację innemu agentowi, że podjęto próbę wykonania akcji, jednak próba nie powiodła się. Krotka, która zawiera odbiorcę, wyrażenie opisujące akcję i wyjaśnienie przyczyn niepowodzenia akcji Wiadomość ta jest skrótem informującym, że nadawca wie, że akcja jest wykonalna, ale nie została dokończona z podanych przyczyn. Odbiorca otrzymujący taką wiadomość jest zobowiązany do tego, aby wierzyć, że: akcja nie została wykonana akcja jest wykonalna (w czasie, gdy agent próbował ją wykonać). Przyczyna niepowodzenia jest wyrażona w postaci propozycji, jako trzeciego elementu krotki zawartości informacji. Przyczyna może być reprezentowana za pomocą stałej równej true. Nie ma gwarancji, że przyczynę niepowodzenia zrozumie odbiorca: to może być jedynie komunikat w postaci informacji o błędzie. <i, failure(j, a, φ)> <i, inform(j, ( e) Single(e) Done(e, Feasible(a) I i Done(a)) φ Done(a) I i Done(a))> FP : B i α B i (Bif j α Uif j α) RE : B j α gdzie α = ( e) Single(e) Done(e, Feasible(a) I i Done(a)) φ Done(a) I i Done(a) Agent i informuje j, że w przeszłości i miał intencję wykonania akcji a i akcja a jest wykonalna. Agent i próbował wykonać akcję a (zdarzenie/akcja e jest próbą wykonania akcji a), ale nie udało mu się, więc teraz nie ma dłużej intencji wykonania akcji a, a przyczyna niepowodzenia jest opisana formułą φ. Agent j informuje i, że otwarcie przez niego pliku zakończyło się błędem: (failure :sender j :receiver i :content ( (action j "open( \"foo.txt\ )") (error-message "No such file: foo.txt") ) :language sl) Zofia Kruczkiewicz 28 Systemy wieloagentowe, Wykład 10-11

29 inform Działania: Zawartość wiadomośc i: Opis: Model formalny Przykłady Nadawca informuje odbiorcę, że dana propozycja jest prawdziwa. Propozycja Nadający agent: utrzymuje, że dana propozycja jest prawdziwa ma intencję, że odbiorca zacznie wierzyć, że propozycja jest prawdziwa nie wierzy, że odbiorca ma wystarczajacą wiedzę na temat prawdziwości propozycji. Dwie pierwsze własności definiują prosto: nadawca jest szczery i uważa (ma intencję), że odbiorca pozna propozycję. Ostatnia własność koncentruje się na semantyce aktu. Jeżeli agent zna życie, wie że trudno zakładać (mieć intencję), że odbiorca uwierzy w formułę p wysłaną w wiadomości. Własność ta nie jest tak silna, jak można przypuszczać. Nadawca nie wymaga, aby odbiorca znał p. To jest tylko przypadek, w którym nadawca dostrzega, co wie odbiorca. Z punktu widzenia odbiorcy, odebrana wiadomość zoobowiązuje go do wiary, że: nadawca wierzy w propozycję zawartą w wiadomości nadawca życzy odbiorcy, aby ten również uwierzył w propozycję. Zmiana przekonań odbiorcy jest funkcją ufności obiorcy w opowiedzi na szczerość i pewność nadawcy. <i, inform( j, φ )> //prosty akt komunikacyjny FP: B i φ B i ( Bif j φ Uif j φ) RE: B j φ Agent i informuje agenta j, że pewne propozycje są prawdziwe (φ), jeśli agent i wierzy w nie (φ). Oznacza to, że i nie wierzy, że j już wierzy w φ lub jej negację lub j jest niepewny co do φ. Jeśli i jest pewien, że j już wierzy w φ, nie wysyła wiadomości. W przypadku, gdy i wierzy, że j nie wiery w φ, i czeka na wiadomość typu disconfirm, w przeciwnym wypadku czeka na confirm. Agent i informuje agenta j, że prawdą jest, że dzisiaj pada: (inform :sender i :receiver j :content "weather( today, raining )" :language Prolog) Zofia Kruczkiewicz 29 Systemy wieloagentowe, Wykład 10-11

30 inform-if (macro act) Działanie: Makro akcja dla agenta nadawcy informujacego odbiorcę czy propozycja jest prawdziwa czy też nie. Zawartość wiadomości : Description: Model formalny Propozycja Akt inform-if (macro act) jest skrótem informującym, czy dana propozycja jest godna wiary. Agent, który uczestniczy w akcie inform-if macro-act aktualnie wykonuje standardowy akt typu inform. Zawartość aktu zależy od wiary agenta nadawcy w moc informowania. Propozycja jest wyrażona za pomoca schematu formuły φ oraz: jeżeli agent nadawca wierzy w propozycję, informuje innego agenta o propozycji φ jeżeli agent nadawca wierzy w negację propozycji, informuje, że φ jest fałszywa (czyli φ) Bez takich własności agent nie mógłby zrealizować swoich planu. Np. jeżeli nie miałby wiedzy o φ, wysłałby wiadomość typu refuse. i, inform-if(j,φ)> <i, inform(j,φ)> <i, inform(j, φ)> FP : Bif i φ B i (Bif j φ Uif j φ) RE : Bif j φ Inform-if reprezentuje dwa możliwe tory akji: i informuje j, że φ lub i informuje j, że nie φ. Przykłady Agent i żąda od j informacji, czy Lannion jest w Normandii: (request :sender i :receiver j :content (inform-if :sender j :receiver i :content "in( lannion, normandy )" :language Prolog) :language sl) Agent j odpowiada, że nie jest: (inform :sender j :receiver i :content "\+ in( lannion, normandy )" :language Prolog) Zofia Kruczkiewicz 30 Systemy wieloagentowe, Wykład 10-11

31 inform-ref (macro act) Działanie: Nadawca informuje odbiorcę, że należy zdefinować deskryptor Zawartość Wykonanie deskryptora wiadomości Akt inform-ref (macro act) pozwala nadawcy poinformawać odbiorcę o Opis: obiektach, które mogą być przydatne do utworzenia deskryptora. Inform-ref jest aktem makro, gdy jest rozłączny z aktem inform, który informuje, o obiekcie o nazwie x. Np. agent może planować akt inform-ref dotyczący czasu bieżącego agenta j i wykonuje inform j, że jest godzina Agent wykonujący akcję powinien wierzyć, że obiekt odpowiadający definicji deskryptora jest przekazany i nie musi wierzyć, że odbiorca wie o tym. Agent odbiorca może wysłać wiadomość refuse, jeśli Model formalny Przykład warunki aktu są niewłaściwe. <i, inform-ref(j,ιx δ(x))> <i, Inform(j,ιx δ(x) = r 1 )>... (<i, Inform(j,ιx δ(x) = r k )> FP: Brefi ιx δ(x) Bi(Brefj ιx δ(x) Urefj ιx δ(x)) RE: Brefj ιx δ(x) Inform-ref reprezentuje niegraniczony, możliwie nieskończony zbiór akcji, w których i informuje j o powiązaniach x. Agent i żąda od j informacji o tym, kto jest premierem Wielkiej Brytanii: (request :sender i :receiver j :content (inform-ref :sender j :receiver i :content (iota?x (UKPrimeMinister?x)) :ontology world-politics :language sl ) :reply-with query0 :language sl) Agent j odpowiada: (inform :sender j :receiver i :content (= (iota?x (UKPrimeMinister?x)) "Tony Blair") :ontology world-politics :in-reply-to query0) Zauważ, że standardowy skrót dla aktu request z aktem inform-ref w przykładzie może być akt query-ref. Zofia Kruczkiewicz 31 Systemy wieloagentowe, Wykład 10-11

32 not-understood Działanie: Nadawca i informuje odbiorcę j, że przypuszczał, że j wykona akcje, ale nie rozumie, że j już to zrobił. Szczególny przypadek dotyczy sytuacji, że i powiadamia j, że nie rozumie wiadomości odebranej od niego. Zawartość Krotka zawierająca akcje lub zdarzenie (np. akt komunikacyjny) i wiadomośc: przyczynę Nadawaca otrzymał wiadomość, której nie rozumie. Jest kilka przyczyn: Opis: agent nie potrafi wykonać akcji lub spodziewał się innej wiadomości. Ten akt jest używany także w przypadkach, kiedy i informuje j, że nie rozumie akcji j. Drugi term z zawartości krotki reprezentuje przyczynę braku rozumienia. Reprezentacja przyczyny ma postać tekstową i nie gwarantuje, że prawidłowo wyraża powód niezrozumienia u nadawcy. <i, not-understood(j, a)> Model <i, Inform( j, ( x) B i ((ιe Done(e) Agent(e, j) B j (Done(e) formalny Agent(e, j) (a = e))) = x))> FP : B i φ B i (Bif j α Uif j α) RE : B j α gdzie α = ( x) B i ((ιe Done(e) Agent(e, j) B j (Done(e) Agent(e, j) (a = e))) = x) Agent 'i' nie zna ostatnio obserwowanego zdarzenia ( x) B i ((ιe Done(e) Agent(e, j)) = x) Agent 'i' wierzy, że agent 'j' zna 'a' jako ostatnie zdarzenie, które 'j' właśnie wykonał: B i (( e) B j (Done(e) Agent(e, j) (a = e)) Agent i nie rozumie wiadomości query-if, ponieważ nie ropoznaje Przykłady ontologii: (not-understood :sender (agent-identifier :name i) :receiver (set (agent-identifier :name j)) :content "((action (agent-identifier :name j) (query-if :sender (agent-identifier :name j) :receiver (set (agent-identifier :name i)) :content \"<fipa-ccl content expression>\" :ontology www :language fipa-ccl)) (unknown (ontology \"www\")))" :language fipa-sl) Zofia Kruczkiewicz 32 Systemy wieloagentowe, Wykład 10-11

33 propagate Działanie Zawartość wiadomości: Nadawca uważa, że odbiorca traktuje wbudowaną wiadomość jako wysłaną prosto do odbiorcy i chce, aby odbiorca zidentyfikował agentów za pomocą deskryptora i przesłał im odebraną wiadomość typu propagate razem z wiadomością wbudowaną Krotka deskryptora, zawierająca wyrażenie wyznaczające agenta lub agentów otrzymujacego/ch: propagowaną wiadomość przekazaną przez nadawcę do odbiorcy, wbudowaną wiadomość w wiadomośc propagowaną, warunki propagacji, oraz czas przeterminowania. Opis To jest akcja złożona z dwóch akcji. Pierwsza z nich dotyczy nadawcy, który żąda od odbiorcy traktowania wbudowanej wiadomości w wiadomości propagowanej jako wiadomości przeznaczonej prosto dla odbiorcy/ów. Druga z ich dotyczy nadawcy, który chce, aby odbiorca zidentyfikował odbiorcę lu odbiorców proppagownej widomości, czyli agenta lub agentów na postawie podanego deskryptora i wysłał jemu/im zmodyfikowaną wersję propagowanej wiadomości do tych agentów, a tym samym również domyślnie wbudowaną wiadomość. Przy przekazywaniu informacji parametr :receiver jest ustawiany na zidentyfikowanego odbiorcę i parametr :sender jest ustawiany na bieżącego odbiorcę. Ten akt komunikacyjny jest przeznaczony do przesyłania wiadomości wbudowanych do zrzeszonych agentów np. żądanie pośredniczenia lub stałe żądanie za pomocą aktów requestwhen/request-whenever wbudowanych w wiadomość typu proxy, która jest wiadomością propagowaną w wiadomości typu propagate Model formalny <i, propagate (j, Ref x δ(x), <i, cact>, φ)> <i, cact(j)>; <i, inform (j, Ii(( y) (Bj(Ref x δ(x) = y) Done (<j, propagate (y, Ref x δ(x), <j, cact>, φ)>, B j φ))))> FP: FP (cact) Bi α Bi (Bifj α Uifj α) RE: Done (cact) Bj α gdzie : α= Ii(( y) (Bj(Ref x δ(x) = y) Done (<j, propagate (y, Ref x δ(x), <j, cact>, φ)>, B j φ))) Agent i wysyła wbudowaną wiadomość do j <i, cact(j)> oraz i chce, aby j wysłał wiadomość typu propagate do wyznaczonych agentów za pomocą Ref x δ(x). Zauważ, że wbudowana wiadomość <i, cact> w wiadomości propagowanej propagate nie ma parametru :receiver, ponieważ jest nim odbiorca wiadomości propagowanej Ref x δ(x) jest jednym z wyrażeń zwiazanych: ιx δ(x), jakiś x δ(x) lub każdy x δ(x). Zofia Kruczkiewicz 33 Systemy wieloagentowe, Wykład 10-11

34 Przykład Agent i żąda od agenta j i jego stowarzyszonych pośredniczących agentów do pośredniczenia w usługach video na żądanie w zakresie osiągania programów "SF". (propagate :sender (agent-identifier :name i) :receiver (set (agent-identifier :name j)) :content ((any?x (registered (agent-description :name?x :services (set (service-description :name agent-brokerage)))) (action (agent-identifier :name i) (proxy :sender (agent-identifier :name i) :receiver (set (agent-identifier :name j)) :content "((all?y (registered (agent-description :name?y :services (set (service-description :name video-on-demand))))) (action (agent-identifier :name j) (request :sender (agent-identifier :name j) :content \"((action?z (send-program (category "SF"))))\" :ontology vod-server-ontology :protocol fipa-reqest )) true)" :ontology brokerage-agent-ontology :conversation-id vod-brokering-2 :protocol fipa-brokering )) (< (hop-count) 5)) :ontology brokerage-agent-ontology ) Zofia Kruczkiewicz 34 Systemy wieloagentowe, Wykład 10-11

35 propose Działanie: Zawartość wiadomości : Opis: Model formalny Akcja przedstawiania propozycji wykonania pewnej akcji przy podanych warunkach Krotka zwierająca opis akcji e, reprezentująca akcję, w ktorej nadawca proponuje wykonanie akcji w podanych warunkach Propose jest używana do składania propozycji lub odpowiedzi na propozycję akcji, która ma być wykonana w podanych warukach w wyniku prowadzonych negocjacji. Aktualny protokół negocjacji jest podany w parametrze wiadomości :protocol. Nadawca wiadomości informuje odbiorcę, że ma intencje wykonania akcji, jeśli będą spełnione warunki, a odbiorca powiadamia nadawcę o swojej intencji wykonania przez nadawcę akcji. Typowe zastosowanie to specyfikacja ceny przez pośrednika w aukcji lub w negocjacjach. <i, propose(j, <i, act>, φ)> <i, inform(j, I j Done(<i, act>, φ) I i Done(<i, act>, φ))> FP : B i α B i (Bif j α Uif j α) RE : B j α gdzie α = I j Done(<i, act>, φ) I i Done(<i, act>, φ) i informuje j, że raz j informuje i, że j ma intencje wobec i do wykonania akcji a, i waruki wykonania a są spełnione. i przyjmuje intencję wykonania a. Przykład Agent j informuje i, że sprzeda 50 skrzynek ze śliwkami w cenie $200: ( propose :sender (agent-identifier :name j) :receiver (set (agent-identifier :name i)) :content "((action j (sell plum 50)) (= (any?x (and (= (price plum)?x) (<?x 10))) 5)" :ontology fruit-market :in-reply-to proposal2 :language fipa-sl) Zofia Kruczkiewicz 35 Systemy wieloagentowe, Wykład 10-11

36 proxy Działanie Zawartość wiadomość: Opis Nadawca chce, aby odbiorca wybrał docelowych agentów oznaczonych zgodnie z otrzymanym opisem i wysłał im wbudowaną wiadomość Krotka deskryptora zawiera wyrażenie referencyjne, które wyznacza docelowych agentów odbiorców wiadomości wbudowanej, wiadomość wbudowaną, która ma być wysłana do agentów odbiorców oraz warunki ograniczające wykonanie wbudowanych aktów komunikacyjnych np. maksymalną liczbę agenów, do których rozsyła sie wbudowaną wiadomość Nadawca informuje odbiorcę o potrzebie zidentyfikowania agentów oznaczonych za pomocą deskryptora i wysłania im wbudowanej wiadomości. Podczas wysyłania wbudowanej wiadomości parametr : receiver zawiera zbiór zidentyfikowaych agentów, natomiast parametr :sender ma wartość agenta odbierającego wiadomość typu proxy. Jeśli wbudowany akt komunikacyjny zawiera parametr :reply-to, musi on być umieszczony w wykonywanej wbudowanej wiadomości. W przypadku żądania pośredniczącego (gdy parametr :protocol parameter jest oznaczony jako fipa-brokering), agent pośredniczący (odbiorca wiadomości typu proxy) musi sam ustawić pewne parametry wiadomości: :conversation-id, :reply-with, :sender itp. w otrzymanej wbudowanej wiadomosci w celu wysłania odpowiedzi od agentów docelowych do agenta żądającego (nadawcy wiadomości typu proxy). Zofia Kruczkiewicz 36 Systemy wieloagentowe, Wykład 10-11

37 Model formalny <i, proxy (j, Ref x δ(x), <j, cact>, φ)> <i, inform (j, Ii(( y)(bj (Ref x δ(x) = y) Done (<j, cact(y)>, Bjφ))))> FP: Bi α Bi (Bifj α Uifj α) RE: Bj α gdzie: α= Ii(( y) (Bj (Ref x δ(x) = y) Done (<j, cact(y)>, Bj φ))) Agent i chce, aby j wysłał wbudowaną wiadomość do agentów oznaczonych za pomoca Ref x δ(x). Zauważ, że <j,cact> w wiadomościach typu wiadomosć ACL jest bez parametru :receiver. Jej odbiorca jest oznaczony za pomocą Ref x δ (x). Zauważ: Ref xδ(x) jest jednym z referencjnych wyrażeń: ιx δ(x), dowolny x δ(x) lub wszystkie x δ(x). Można wyróżnić dwa typy wiadomości typu proxy. Jedna z nich określana jest jako silna, ponieważ warunki wykonalności wiadomości wbudowanej odpowiadają wykonalności wiadomości typu proxy. Czyli jeśli agent i chce nadać wiadomość typu inform z propozycją ψ do agenta y za pośrednictwem j, agent j musi wierzyć w ψ, zanim wyśle wiadomość wbudowaną do y. Drugi typ wiadomości typu proxy jest określany jako słaby, ponieważ nie wymaga sie, aby agent i wierzył w ψ. W tym przypadku agent j nie musi wprost informować y o ψ, ponieważ agent j nie jest usatysfakcjonowany warunkami wykonalności wiadomości wbudowanej. W tym przypadku j tylko informuje y o intencjach nadawcy i wiadomości typu proxy, wyrażonych za pomocą ψ. Słaby rodzaj może być wyrażony jako wystąpienie wiadomosci typu proxy, gdzie akcja <j,cact(y)> jest zastąpiona przez <j, inform(y, I i Done (<i, cact(y)>))>. Zofia Kruczkiewicz 37 Systemy wieloagentowe, Wykład 10-11

38 Przykład Agent i żąda od agenta j, aby agent j zwerbował serwera i żądał od niego usługi video na żądanie dotyczącej przesłania "SF" programów. (proxy :sender (agent-identifier :name i) :receiver (set (agent-identifier :name j)) :content ((all?x (registered(agent-description :name?x :services (set (service-description :name video-on-demand))))) (action (agent-identifier :name j) (request :sender (agent-identifier :name j) :content "((action?y (send-program (category "SF"))))" :ontology vod-server-ontology :language FIPA-SL :protocol fipa-request :reply-to (set (agent-identifier :name i)) :conversation-id request-vod-1) true) :language FIPA-SL :ontology brokerage-agent :protocol fipa-recruiting :conversation-id vod-brokering-1 ) Zofia Kruczkiewicz 38 Systemy wieloagentowe, Wykład 10-11

39 query-if Działanie: Zawartość wiadomości : Opis: Model Formal Akcja pytania innego agenta, czy dana propozycja jest prawdziwa czy fałszywa Propozycja. Query-if jest aktem pytania innego agenta, czy dana propozycja jest prawdziwa (odbiorca wierzy, że jest prawdziwa). Nadawca żąda od odbiorcy informacji, czy propozycja jest prawdziwa. Agent nadający akt query-if : nie ma wiedzy na temat prawdziwości propozycji wierzy, że inny agent zna prawdę o propozycji I wyjąsni ja pytającemu agentowi <i, query-if(j,φ) <i, request(j, <j, inform-if(i,φ)>)> FP: Bifiφ Uifiφ Bi I j Done(<j, inform-if(i, φ)>) RE: Done(<j, inform(i, φ)> <j, inform(i, φ)>) i żąda od j, aby j informował i, czy jest lub nie prawdziwy schemat formuły φ. Przykład Agent i pyta agenta j, czy zarejestrował się sewerze d1: (query-if :sender i :receiver j :content (registered (server d1) (agent j)) :reply-with r09 ) Agent j odpowiada agentowi i, że nie zarejestrował sie na serwerze d1 (inform :sender j :receiver i :content (not (registered (server d1) (agent j))) :in-reply-to r09 ) Zofia Kruczkiewicz 39 Systemy wieloagentowe, Wykład 10-11

40 query-ref Działanie: Akcja pytania innego agenta o obiekt opisany wyrażeniem referencyjnym Zawartość Definicja deskryptora wiadomośc: Query-ref jest aktem pytania innego agenta odbiorcę o informacje o Opis: obiekcie identyfikowanym przez definiowany deskryptor. Nadawca żąda od odbiorcy wykonania aktu typu inform, zawierającego informację o obiekcie odpowiadającym definiowanemu deskryptorowi. Agent nadajacy wiadomość typu query-ref: nie wie, który obiekt odpowiada deskryptorowi wierzy, że agent odbiorca wie, który obiekt odpowiada zdefiniowanemu deskryptorowi i udzieli informacji pytającemu Model formalny agentowi <i, query-ref(j,ιx δ(x)) <i, request(j, <j, inform-ref(i,ιx δ(x))>)> FP: Brefi(ιx δ(x)) Urefi(ιx δ(x)) Bi I j Done(<j, inform-ref(i, ιx δ(x))>) RE: Done(<i, Inform(j,ιx δ(x) = r 1 )>... <i, Inform(j,ιx δ(x) = r k )>) Agent i żąda od agenta j, aby ten informował agenta i o powiązaniach x Przykład Agent i pyta agenta j o usługi spełniane przez niego: (query-ref :sender i :receiver j :content (iota?x (available-services j?x)) ) j odpowiada, że może zarezerwować bilet na pociąg, samolot, autobus (inform :sender j :receiver i :content (= (iota?x (available-services j?x)) ((reserve-ticket train) (reserve-ticket plane) (reserve automobile)) ) ) Zofia Kruczkiewicz 40 Systemy wieloagentowe, Wykład 10-11

41 refuse Działanie: Akt odmówienia wykonania akcji i wyjaśnienie przyczyn odmowy Zawartość informacji: Opis: Model formalny Przykład Krotka zawierająca wyrażenie akcji oraz przyczyny Akt typu refuse jest skrótem zaprzeczania komuś (czyli disconfirming), że akcja jest możliwa do wykonania i wyjaśnienie przyczyn Akt ten jest wykonywany, gdy agent nie ma warunków, zarówno jawnych jak i ukrytych, do wykonania akcji. Agent otrzymujący akt odmowy jest zobowiązany do tego, aby wierzyć, że: akcja nie jest wykonana akcja nie jest wykonalna (z punktu widenia nadawcy) przyczyna odmowy jest reprezentowana za pomocą propozycji, która jest trzecim elementem krotki zawartości wiadomości (jeśli jest to stała, musi byc równa true). Nie ma gwarancji, że sposób wyrażenia przyczyny będzie zrozumiały dla odbiorcy. <i, refuse(j, <i, act>, φ)> <i, disconfirm(j, Feasible(<i, act>))>; <i, inform(j,φ Done(<i, act>) I i Done(<i, act>))> FP : B i Feasible(<i, act>) B i (B j Feasible(<i, act>) U j Feasible(<i, act>)) B i α B i (Bif j α Uif j α) RE : B j Feasible(<i, act>) B j α gdzie α = φ Done(<i, act>) I i Done(<i, act>) i informuje j, że akcja a nie jest wykonalna, z podanych przyczyn, oraz agent i nie ma intencji do wykonania akcji a. Agent j odmawia agentowi i rezerwacji biletu, od momentu gdy i nie ma wystarczającej kwoty na koncie: (refuse :sender (agent-identifier :name j) :receiver (set (agent-identifier :name i)) :content "((action (agent-identifier :name j) (reserve-ticket LHR MUC 27-sept-97)) (insufficient-funds ac12345))" :language fipa-sl) Zofia Kruczkiewicz 41 Systemy wieloagentowe, Wykład 10-11

42 reject-proposal Działanie: Zawartość wiadomości : Opis: Model formalny Akcja odmowy propozycji wykonania akcji podzcas negocjacji Krotka zawierająca opis akcji, propozycję, która zostaje odrzucona oraz przyczyny odmowy. Akt typu reject-proposal jest odmową poprzednio przyjętej propozycji. Agent wysyłający odmowę informuje odbiorcę, że nie ma intencji wykonania danej akcji z podanych przyczyn. Dodatkowa propozycja reprezentuje przyczyny odmowy wykonania proponowanej akcji. Trudno odnieść podane przyczyny do akcji, model formalny przyjmuje, że były one prawdziwe dla nadawcy w momencie odmowy. Syntaktycznie przyczyna jako poprzednik we wnioskowaniu jest traktowana jako przyczyna wyjaśniajacą odmowę, chociaż nie jest uwzględniania w formalnej semantyce. <i, reject-proposal(j, <j, act>, φ, ψ)> <i, inform(j, Ii Done(<j, act>, φ) ψ)> FP : B i α B i (Bif j α Uif j α) RE : B j α gdzie α = Ii Done(<j, act>, φ) ψ i informuje j, że z powodu ψ i nie ma intencji wykonania akcji przy prawdziwych warunkach opisanych φ. Przykład Agent i informuje j, że odrzuca ofertę kupna śliwek od j, ponieważ cena jest za wysoka (reject-proposal :sender (agent-identifier :name i) :receiver (set (agent-identifier :name j)) :content "((action (agent-identifier :name j) (sell plum 50)) (cost 200) (price-too-high 50))" :in-reply-to proposal13) Zofia Kruczkiewicz 42 Systemy wieloagentowe, Wykład 10-11

43 request Działanie: Zawartość wiadomości : Opis: Model formalny Przykłady Nadawca żąda od odbiorcy wykonania pewnej akcji, np. innego aktu komunikacyjnego. Opis akcji. Nadawca żąda od odbiorcy wykonania pewnych akcji. Zawartość widomości jest opisem akcji do wykonania, w języku zrozumiałyum dla odbiorcy. To może to być dowolna akcja: podniesienie skrzynki, zarezerwowanie biletu na samolot, zmiana hasła. Ważnym zastosowaniem tego aktu jest budowa złożonej konwersacji między agentami, gdzie wykonywane akcje są innymi aktami komunikacyjnymi np. typu inform. <i, request( j, a )> //prosty akt komunikacyjny FP: FP(a) [i\j] B i Agent( j, a ) B i I j Done(a) RE: Done(a) gdzie a jest zmienną, która zastępuje dowolne wyrażenie akcji FP(a) oznacza skutki wykonania dla a; FP(a) [i \j] oznacza, że część skutków wykonania akcji a jest wyrażona własnościami mentalnymi agenta i. Agent i żąda od agenta j otwarcia pliku: (request :sender i :receiver j :content "open \"db.txt\" for input" :language vb) Zofia Kruczkiewicz 43 Systemy wieloagentowe, Wykład 10-11

44 request-when Działanie: Zawartość wiadomości Opis: Model formalny Przykłady Nadawca chce, aby odbiorca wykonał pewne akcje, jeśli pewne warunki będą spełnione. Krotka opisu akcji i propozycji Akt request-when pozwala nadawcy informować innego agenta, że pewna akcja może być wykonana wtedy, gdy będą spełnione warunki wyrażone w postaci wyrażenia, które staje sie prawdziwe. Agent otrzymujący request-when powinien albo odmówić albo zapewnić, że akcja będzie wykonana, gdy warunki będą spełnione. To zobowiązanie trwa do czasu, gdy warunki stają się prawdziwe i żądający agent kasuje akt request-when lub agent odbiorca decyduje się dłużej nie honorować zobowiązań i wysyła wiadomoś typu refuse. Nie ma specjalnych specyfikacji dla zobowiązań nie ma wpływu na specyfikację częstość wykonywaych akcji oraz związek między akcją a zobowiązaniem liczy się tylko to, co wynegocjuje agent przyjmujący akt request-when. <i, request-when(j, <j, act>, φ)> <i, inform(j, ( e') Done(e') Unique(e') I i Done(<j, act>, ( e) Enables(e, B j φ) Has-never-held-since(e', B j φ)))> FP : B i α B i (Bif j α Uif j α) RE : B j α gdzie α = ( e') Done(e') (Unique(e') I i Done(<j, act>, ( e) Enables(e, B j φ) Has-never-held-since(e', B j φ)) i informuje j, że i ma intencję, aby j wykonał pewne akcje, jeśli j uwierzy w φ. Agent i mówi agentowi j, aby zawiadomił go wtedy, gdy wystąpi alarm (wysłanie wiadomości typu inform). (request-when :sender (agent-identifier :name i) :receiver (set (agent-identifier :name j)) :content "((action (agent-identifier :name j) (inform :sender (agent-identifier :name j) :receiver (set (agent-identifier :name i)) :content \"((alarm \"something alarming!\"))\")) (Done( alarm )))" ) Zofia Kruczkiewicz 44 Systemy wieloagentowe, Wykład 10-11

45 request-whenever Dzialanie: Zawartość wiadomości Opis: Model formalny Przykłady Nadawca chce, aby odbiorca wykonał pewne akcje tak szybko jak pewne propozycje (warunki) staną się prawdziwe i po pewnym czasie powtórzył je, kiedy propozycje (warunki) znowu staną się prawdziwe. Krotka z opisem akcji i propozycją Akt request-whenever pozwala agentowi informować innego agenta, że pewna akcja może byc wykonna tak szybko jak tylko warunki stana się prawdziwe. W przeciwnym wypadku, jeżeli warunki staną się fałszywe akcja może sie powtórzyć dopiero wtedy, gdy ponownie staną się prawdziwe. Akt request-whenever reprezentuje stałe zobowiązanie do ponownego wykonania akcji, jeśli warunki i akcja ulegną zmianie i będą właściwe. Bieżący agent może pozbyć się zobowiązań prze wykonanie akcji cancel. Nie ma specjalnych specyfikacji dla zobowiązań nie ma wpływu na specyfikację zobowiązań częstość wykonywanych akcji oraz związek między akcją a zobowiązaniem liczy się tylko to, co wynegocjuje agent przyjmujący akt request-whenever. <i, request-whenever(j, <j, act>, φ)> <i, inform(j, I i Done(<j, act>, ( e) Enables(e, B j φ)))> FP : B i α B i (Bif j α Uif j α) RE : B j α gdzie α = I i Done(<j, act>, ( e) Enables(e, B j φ)) i informuje j, że i ma intencję, aby j wykonał pewne akcje, jeśli kiedykolwiek pewne warunki staną się prawdziwe wyrażone wiarą agenta j w φ. Agent i mówi agentowi j, aby powiadomił go (wysłanie wiadomości typu inform-ref), jeśli kiedykolwiek cena urządzenia wzrośnie z poziomu poniżej 50 do poziomu powyżej 50 (request-whenever :sender (agent-identifier :name i) :receiver (set (agent-identifier :name j)) :content "((action (agent-identifier :name j) (inform-ref :sender (agent-identifier :name j) :receiver (set (agent-identifier :name i)) :content \"((iota?x (= (price widget)?x)))\")) (> (price widget) 50))" ) Zofia Kruczkiewicz 45 Systemy wieloagentowe, Wykład 10-11

46 subscribe Dzialanie: Zawartośc waidomości : Opis: Model formalny Stała intencja żądania od odbiorcy powiadamiania nadawcy o referencjach i powiadamiania o zmianach referencji. Definiowanie deskryptora Akt subscribe jest stałą wersją aktu typu query-ref, taką że agent odbierający bedzie informował nadawcę o wartościach referencji i bedzie kontynuował powiadamianie o zmianach referencji. Zbiór subskrypcji jest zakończony za pomocą aktu kasowania. <i, subscribe(j,ιx δ(x))> <i, request-whenever(j, <j, inform-ref(i,ιx δ(x))>, ( y) B j ((ιx δ(x) = y))> FP : B i α B i (Bif j α Uif j α) RE : B j α gdzie α= I i Done(<j, inform-ref(i,ιx δ(x))>, ( e) Enables(e, ( y) B j ((ιx δ(x) = y))) Przykłady Agent i żąda od agenta j zmiany raty z franków na dolary i wyraża zgodę na subskrypcję z agentem j (zmiana raty za serwer): (subscribe :sender i :receiver j: :content (iota?x (=?x (xch-rate FFr USD))) ) Zofia Kruczkiewicz 46 Systemy wieloagentowe, Wykład 10-11

47 PROTOKOŁY INTERAKCJI Używane wiadomości w różnych konwersacjach mogą tworzyć pewien szablon, co prowadzi do definicji nowego typu protokołu interakcji Wymaganie 8: Agent nie musi implementować standardowych protokołów, jednak jeśli przyjęto nazwę standardowego protokołu, musi ona odpowiadać podanej w specyfikacji FIPA. Agent może brać udział w kilku konwersacjach jednocześnie prowadząc dialog z wieloma agentami. Konwersacje te mogą należć do różnych protokołów. Należy zapewnić rozróżnialność poszczególnych wiadomości należących do różnych protokołów i konwersacji. Specyfikacja protokołu, jeśli jest operacją Przykład (request :sender i :receiver j :content some-act :protocol fipa-request ) Notacja standardowego opisu protokołu prostokaty z podwójnymi krawędziami reprezentują akt komunikacyjny Biały prostokąt reprezentuje akcje podejmowane przez nadawcę Szare prostokaty reprezentują akcje podejmowane przez pozostałych uczestników protokołu Tekst napisany italikiem reprezentuje komnetarz Przykład opisu protokołu Zofia Kruczkiewicz 47 Systemy wieloagentowe, Wykład 10-11

48 DEFINICJE PROTOKOŁÓW Failure to understand a response during a protocol Nie można odpowiedzieć na wiadomość not-understood za pomocą wiadomości not-understood. Protokół FIPA-request Protokół, ktory pozwala zażądać od innego agenta wykonanie pewnych akcji, a agentowi odbiorcy albo wyrazić zgodę (agree) albo odmówić (not-understood, refuse). W przypadku agree agent odbiorca potwierdza dodatkowo losy wykonanej akcji jako: failure lub inform. W przypadku wykonania akcji agent odbiorca w wiadomości typu inform powiadamia jedynie nadawcę o wykonaniu akcji (Done(action)) lub powiadamia również o jej rezultacie (iota x (result action) x). FIPA-query Protocol Od odbiorcy żąda się, aby wykonał kilka akcji typu informacyjnego. Jeśli jest to akcja typu query-if, agent odpowiada za pomocą aktu typu inform. Jeśli jest to akcja typu query-ref, wykonuje się akcje typu inform-ref. Zofia Kruczkiewicz 48 Systemy wieloagentowe, Wykład 10-11

49 Protokół FIPA-request-when Wyraża on w prosty sposób wiele intencji zawartych w żądaniach wykonania akcji. Agent nadawca żąda od drugiego agenta odbiorcy wykonania akcji w przyszłości, jeśli warunki przed staną się prawdziwe. Jesli agent odbiorca zrozumie żądanie (brak notunderstood) i nie odmówi (brak refuse), czeka on na spełnienie warunków w celu wykonania zleconego zadania (wybiera agree). Następnie (jeśli warunki zostały spełnione) odbiorca informuje o wykonaniu akcji (inform) lub o błędzie (failure), w przeciwnym wypadku, jeśli warunki nie zostały spełnione, odrzuca propozycję wykonania akcji (reject). Zofia Kruczkiewicz 49 Systemy wieloagentowe, Wykład 10-11

50 Protokół FIPA-contract-net Jest to szeroko używany protokół Contract Net, zdefiniowany na podstawie [Smith & Davis 80]. FIPA-Contract-Net jest niewielką modyfikacją oryginalnego protokołu przez dodanie aktów komunikacyjnych: rejection i confirmation. W protokole tym jeden agent pełni rolę menedżera. Menedżer rozsyła informację powiadamiającą o oczekiwaniu na propozycje wykonania pewnych zadań. Nadesłane propozycje wykonania zadań menedżer ocenia zgodnie z pewną funkcją, stąd przyjmuje część lub wszystkie nadesłane propozycje, jeśli wpłyną przed upływem zadanego czasu, a jeśli nie spełniają kryteriów odrzuca je. Ta ocena propozycji nadesłanych jest najczęściej wyrażana za pomocą ceny, czasu itp. Menedżer może skasować działania agentów wykonawczych przed wykonaniem zadania. Zofia Kruczkiewicz 50 Systemy wieloagentowe, Wykład 10-11

51 FIPA-Iterated-Contract-Net Protocol Protokół Iterated contract net jest rozszerzeniem podstawowego protokołu contract net. Różni się on od podstawowej wersji zastosowaniem pętli umożliwiającej wielokrotne uzgadnianie oferty. Menedżer wysyła wiadomość inicjującą typu cfp. Kontrahenci odpowiadają za pomocą wiadomości typu propose. Menedżer może zaakceptować jedna lub wiele ofert, odrzucić inne lub może on iteracyjnie inicjować ponownie proces uzgadaniania ofert. Intencją menedżera jest otrzymanie najlepszej oferty od kontrahentów za pomocą modyfikacji oferty inicjującej i żądania nowych ofert. Proces kończy się, kiedy menedżer odrzuci wszystkie propozycje i nie złoży nowej oferty inicjującej, akceptując jedną lub więcej ofert lub odrzucając wszystkie oferty. Zofia Kruczkiewicz 51 Systemy wieloagentowe, Wykład 10-11

52 FIPA-Auction-English Protocol W aukcji typu angielskiego aukcjoner poszukuje ceny rynkowej na towar, inicjując ją poniżej wartości rynkowej towaru. Następnie stopniowo ją podnosi. Za każdym razem cena jest ogłaszana i aukcjoner obserwuje, czy znajdzie się nabywca. Po każdej nowej propozycji ze strony kupujących aukcjoner czeka na nową wyższą ofertę i wybiera w danym momencie jedną najwyżsą ofertę ceny kupna towaru. Aukcja trwa do momentu, gdy są zakończy się zgłaszanie nowej oferty kupna towaru. Ostatnia oferta cenowa jest ostateczną ceną sprzedaży, jeśli nie jest mniejsza od pewnej ceny ustalonej przez aukcjonera. Jeśli jest ona mniejsza, towar nie zostanie sprzedany. W diagramie protokołu oferta aukcjonera jest wyrażona za pomocą wiadomości cfp, rozesłanej do wszystkich uczestników aukcji. Da ułatwienia tylko jedno wystąpienie wiadomości jest przedstawiane. W fizycznej aukcji obecność uczestników aukcji w jednym pomieszczeniu umożliwia rozgłaszane jednej najwyższej oferty kupna do wszystkich uczestników aukcji nie tylko do aukcjonera. To nie musi być prawda w przypadku systemu wieloagentowego, gdzie więcej niż jeden agent może oferować cenę w danym momencie. Nawet jeśli aukcja jest kontynuowana, dopóty, dopóki jest przynajmniej jeden pośrednik, agenty oczekują, czy ich oferta została zaakceptowana (reprezentowana za pomoca wiadomości propose). Stąd pojawiają się wiadomości typu accept-proposal i reject-proposal. Zofia Kruczkiewicz 52 Systemy wieloagentowe, Wykład 10-11

53 FIPA-Auction-Dutch Protocol W aukcji typu holenderskiego, prowadzacy aukcję próbuje znaleźć cenę rynkową dla towaru podając cenę dużo wyższą niż spodziewana cena rynkowa. Następnie, stopniowo redukuje jej wysokość, aż kupujący zaakceptują jej wysokość. Jednak aukcjoner nie może zejść poniżej pewnej granicznej ceny w momencie przekroczenia tej granicy, jeśli nie znajdzie sie kupujący, aukcjoner przerywa aukcję. Nazwa "Dutch Auction" wywodzi sie z aukcji kwiatów w Holandii. W modelowaniu aktualnej aukcji kwiatów dochodzą dodatkowe problemy. Po pierwsze, wyroby mogą być sprzedawane w różnych jednostkach: sztukach, skrzynkach, natomiast kupujący chciałby kupić towar, lecz mniejszej ilości (zamiast proponowanych 5 skrzynek tylko trzy). Sprzedaż (o ile to możliwe, również w zmiennych jednostkach) jest kontynuowana, aż towary zostana sprzedane, albo zostanie osiągnięta cena graniczna. Po drugie, mechanism targu kwiatów funkcjonuje przy założeniu, że nie ma zmowy po stronie kupujących, co osiąga się za pomocą jednej oferty cenowej na towar. Nie jest możliwe, aby istniał protokół akceptacji lub odrzucenia idei jednej oferty cenowej. Z punktu widzenia agentowego nie jest możliwe, aby założyć lub oczekiwać, że takie warunki można zastosować. Jest całkiem możliwe, że może pojawić kilka ofert cenowych na ten sam towar. Protokół każe odzucić te dodatkowe oferty, chociaż można przyjąć również wariant wielu ofert dla innej dziedziny niż sprzedaż towarów (kwiatów). Zofia Kruczkiewicz 53 Systemy wieloagentowe, Wykład 10-11