ˇ ´I TECHNICKE ´ V BRNEˇ VYSOKE´ UCEN BRNO UNIVERSITY OF TECHNOLOGY
ˇ ´ICH TECHNOLOGI´I FAKULTA INFORMACN ´ ´ U ˚ USTAV INTELIGENTN´ICH SYSTEM FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INTELLIGENT SYSTEMS
´ ´I UVAZUJ ˇ ´IC´ICH AGENTU ˚ MODELOVAN ˇ PETRIHO S´ITEMI
ˇ ´I PRACE ´ DISERTACN PHD THESIS
´ AUTOR PRACE AUTHOR
BRNO 2008
ˇ MAZAL Ing. ZDENEK
ˇ ´I TECHNICKE ´ V BRNE ˇ VYSOKE´ UCEN BRNO UNIVERSITY OF TECHNOLOGY
ˇ ´ICH TECHNOLOGI´I FAKULTA INFORMACN ´ ´ U ˚ USTAV INTELIGENTN´ICH SYSTEM FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INTELLIGENT SYSTEMS
´ ´I UVAZUJ ˇ ´IC´ICH AGENTU ˚ MODELOVAN ˇ PETRIHO S´ITEMI MODELLING DELIBERATIVE AGENTS BY PETRI NETS
ˇ ´I PRACE ´ DISERTACN PHD THESIS
´ AUTOR PRACE
ˇ MAZAL Ing. ZDENEK
AUTHOR
´ VEDOUC´I PRACE SUPERVISOR
BRNO 2008
ˇ ˇ doc. Ing. FRANTISEK V. ZBORIL, CSc.
Abstrakt Multiagentn´ım syst´emem naz´ yv´ame syst´em, ve kter´em se nach´ az´ı nˇekolik autonomn´ıch prvk˚ u, naz´ yvan´ ych agenti, kter´e spolu vz´ ajemnˇe interaguj´ı. Agentn´ı a multiagentn´ı syst´emy pˇredstavuj´ı relativnˇe nov´ y perspektivn´ı vˇedn´ı obor s ˇradou aplikac´ı v oblasti distribuovan´ ych softwarov´ ych syst´em˚ u, zejm´ena v prostˇred´ı Internetu. V r´ amci t´eto problematiky je ˇreˇsena cel´a ˇrada ot´azek. Jednou z nich je hled´ an´ı vhodn´e vnitˇrn´ı architektury agent˚ u a jej´ı modelov´an´ı. Dlouholet´e zkuˇsenosti prok´azaly, ˇze Petriho s´ıtˇe pˇredstavuj´ı vhodn´ y n´ astroj pro modelov´ an´ı paraleln´ıch a distribuovan´ ych syst´em˚ u. Jako takov´e by mˇely b´ yt vhodn´e pro modelov´ an´ı agentn´ıch a multiagentn´ıch syst´em˚ u, kter´e jsou inherentnˇe paraleln´ı. V souˇcasn´e dobˇe vˇsak existuje velmi m´alo syst´em˚ u, kter´e by umoˇzn ˇovaly modelovat cel´ y multiagentn´ı syst´em pomoc´ı Petriho s´ıt´ı – jejich pouˇzit´ı je obvykle omezeno pouze na nˇekter´e podprobl´emy, jako je verifikace interakˇcn´ıch protokol˚ u nebo synchronizace pl´ an˚ u. Tato disertaˇcn´ı pr´ace se zab´ yv´a moˇznostmi modelov´ an´ı multiagentn´ıch syst´em˚ u pomoc´ı formalismu objektovˇe orientovan´ ych Petriho s´ıt´ı (OOPN). Oproti standardn´ım vysokou ´rovˇ nov´ ym Petriho s´ıt´ım pˇredstavuj´ı OOPN mnohem dynamiˇctˇejˇs´ı n´ astroj, coˇz je pro modelov´ an´ı agentn´ıch syst´em˚ u velmi d˚ uleˇzit´e. Hlavn´ım pˇr´ınosem pr´ ace je n´ avrh architektury frameworku PNagent, kter´ y umoˇzn ˇuje v´ yvoj, testov´ an´ı a bˇeh softwarov´ ych agent˚ u v konzistentn´ım grafick´em prostˇred´ı PNtalk, zaloˇzen´em na formalismu OOPN. Framework je vhodn´ y pro prototypov´an´ı a experimenty jak s konkr´etn´ımi multiagentn´ımi aplikacemi, tak se samotnou architekturou agent˚ u. Z´ aroveˇ n, d´ıky form´ aln´ı povaze pouˇzit´ ych n´ astroj˚ u, poskytuje dobr´ y z´aklad pro vysoko´ urovˇ novou verifikaci vlastnost´ı multiagentn´ıho syst´emu. N´avrh architektury byl ovˇeˇren prototypovou implementac´ı frameworku, vˇcetnˇe uk´ azkov´e aplikace z oblasti ˇr´ızen´ı mobiln´ıch robot˚ u. Souˇc´ ast´ı pr´ ace je tak´e pˇr´ınos k obecn´e metodice modelov´an´ı pomoc´ı formalismu OOPN a n´ astroje PNtalk.
Kl´ıˇ cov´ a slova modelov´an´ı, uvaˇzuj´ıc´ı agent, BDI architektura, OOPN, PNagent
Abstract Multi-agent system is a system which consists of several autonomous elements, called agents, which interact with each other. Agent and multi-agent systems present a relatively new and prospective discipline with plenty of applications in distributed systems, especially on the Internet. As a part of it, many problems are being solved. One of them is that of suitable inner agent architecture and its modelling. Long time experiences have proven that Petri nets are a valuable tool for modelling concurrent and distributed systems. As such, they should be suitable for modelling agent and multi-agent systems, as these are inherently concurrent. Nevertheless, there are not many systems that allow modelling of the whole multi-agent system in Petri nets. The use of Petri nets is usually limited to sub-problems, such as verification of interaction protocols or plan synchronisation. This Ph.D. thesis deals with the possibilities of modelling multi-agent systems using the formalism of Object Oriented Petri Nets (OOPN). Compared to standard high-level Petri nets, OOPN present a much more dynamic tool, which is essential for modelling agent systems. The main outcome of this work is the design of PNagent framework, which allows for development, testing and running software agents in a consistent graphical environment PNtalk, based on the OOPN formalism. The framework is suitable for prototyping and experiments with both multi-agent applications and the particular agent architecture itself. At the same time, thanks to the formal nature of its underlying paradigm, it provides means for verification of multi-agent system’s properties. The design has been verified by a prototype implementation, including a demonstration application from mobile robot control field. An important part of the work is also a contribution to general methodology of modelling using the OOPN formalism and PNtalk tool.
Keywords Modelling, Deliberative Agent, BDI Architecture, OOPN, PNagent
Modelov´ an´ı uvaˇ zuj´ıc´ıch agent˚ u Petriho s´ıtˇ emi Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem tuto disertaˇcn´ı pr´ aci vypracoval samostatnˇe pod veden´ım doc. Ing. Frantiˇska V. Zboˇrila CSc. ....................... Zdenˇek Mazal 17. z´ aˇr´ı 2008
Podˇ ekov´ an´ı ˇ GD102/05/H050, V pr˚ ubˇehu sv´eho studia jsem byl podporov´ an n´ asleduj´ıc´ımi granty: GACR ˇ ˇ ˇ CEZ MSMT MSM0021630528 a FRVS MSMT FR2286/2007/G1. D´ ale bych chtˇel podˇekovat sv´emu ˇskoliteli doc. Ing. Frantiˇsku V. Zboˇrilovi, CSc. za jeho podporu pˇri studiu a sv´ ym ´ spolupracovn´ık˚ um z Ustavu inteligentn´ıch syst´em˚ u, zejm´ena Ing. Vladim´ıru Janouˇskovi, Ph.D., Ing. Radkovi Koˇc´ımu, Ph.D. a Ing. Frantiˇsku Zboˇrilovi, Ph.D. za konzultace a cenn´e ˇarce a vˇsem ostatn´ım, kteˇr´ı mˇe po dobu studia jakkoliv rady. M˚ uj d´ık patˇr´ı tak´e rodinˇe, S´ podporovali.
c Zdenˇek Mazal, 2008.
Tato pr´ ace vznikla jako ˇskoln´ı d´ılo na Vysok´em uˇcen´ı technick´em v Brnˇe, Fakultˇe informaˇcn´ıch technologi´ı. Pr´ ace je chr´ anˇena autorsk´ym z´ akonem a jej´ı uˇzit´ı bez udˇelen´ı opr´ avnˇen´ı autorem je nez´ akonn´e, s v´yjimkou z´ akonem definovan´ych pˇr´ıpad˚ u.
Obsah ´ 1 Uvod 1.1 Motivace, c´ıle disertaˇcn´ı pr´ ace . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Struktura pr´ace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 5 5
2 Objektovˇ e orientovan´ e Petriho s´ıtˇ e 2.1 Vysoko´ urovˇ nov´e Petriho s´ıtˇe . . . . . . . . . . . . . . . . . . . . . . . 2.2 Neform´aln´ı specifikace OOPN . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Z´akladn´ı prvky s´ıt´ı v OOPN . . . . . . . . . . . . . . . . . . 2.2.2 Struktura neprimitivn´ıch objekt˚ u . . . . . . . . . . . . . . . . 2.2.3 Dynamick´e chov´an´ı OOPN . . . . . . . . . . . . . . . . . . . 2.3 Jazyk a syst´em PNtalk . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Navrˇzen´e rozˇs´ıˇren´ı jazyka PNtalk . . . . . . . . . . . . . . . . . . . . ˇ sen´ı v barven´ 2.4.1 Reˇ ych Petriho s´ıt´ıch . . . . . . . . . . . . . . . . ˇ 2.4.2 Reˇsen´ı v jazyku PNtalk . . . . . . . . . . . . . . . . . . . . . 2.4.3 Pˇrevod negativn´ıch predik´ at˚ u na existuj´ıc´ı jazykov´e struktury 2.4.4 Negativn´ı predik´aty a logick´e programov´ an´ı . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
7 8 9 9 10 11 12 13 14 15 17 19
3 Agenti a multiagentn´ı syst´ emy 3.1 Z´akladn´ı pojmy . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Inteligentn´ı agent . . . . . . . . . . . . . . . . . 3.1.2 Multiagentn´ı syst´em . . . . . . . . . . . . . . . 3.2 Architektury agent˚ u . . . . . . . . . . . . . . . . . . . 3.2.1 Reaktivn´ı agent . . . . . . . . . . . . . . . . . . 3.2.2 Uvaˇzuj´ıc´ı agent . . . . . . . . . . . . . . . . . . 3.2.3 Hybridn´ı agent . . . . . . . . . . . . . . . . . . 3.3 Prostˇred´ı a interakce v multiagentn´ıch syst´emech . . . 3.4 Komunikace v multiagentn´ıch syst´emech . . . . . . . . 3.5 Standardizace agentn´ıch technologi´ı – organizace FIPA
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
21 22 22 22 22 23 25 27 28 29 30
4 Architektura BDI 4.1 Z´akladn´ı principy a komponenty architektury BDI 4.1.1 Pˇredstavy . . . . . . . . . . . . . . . . . . . 4.1.2 Touhy . . . . . . . . . . . . . . . . . . . . . 4.1.3 Z´amˇery . . . . . . . . . . . . . . . . . . . . 4.1.4 Pl´any . . . . . . . . . . . . . . . . . . . . . 4.2 Formalizace BDI . . . . . . . . . . . . . . . . . . . 4.2.1 Mod´aln´ı logiky . . . . . . . . . . . . . . . . 4.2.2 Tempor´aln´ı logiky . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
32 32 32 33 33 34 34 35 35
1
. . . . . . . .
. . . . . . . .
. . . . . . . . . . .
36 37 37 37 38 40 41 43 43 43 44
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
45 45 46 48 48 48 49 51 52 53 54 54 55 57 57 57 58 59 60 60 61 62 62 63 64 65 65 70 72
6 Z´ avˇ er 6.1 Zvolen´ y pˇr´ıstup k ˇreˇsen´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Dosaˇzen´e v´ ysledky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Moˇznosti dalˇs´ıho v´ yzkumu . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74 74 74 75
Literatura
75
4.3
4.4
4.2.3 BDI CTL logika . . . . . . . . . . . . . . . . Realizace architektury BDI . . . . . . . . . . . . . . 4.3.1 Abstraktn´ı interpret BDI agenta . . . . . . . 4.3.2 IRMA . . . . . . . . . . . . . . . . . . . . . . 4.3.3 PRS . . . . . . . . . . . . . . . . . . . . . . . 4.3.4 Syst´emy vych´azej´ıc´ı z PRS . . . . . . . . . . 4.3.5 JADEX . . . . . . . . . . . . . . . . . . . . . 4.3.6 Dalˇs´ı implementace BDI . . . . . . . . . . . . Formalizace syst´em˚ u zaloˇzen´ ych na architektuˇre BDI 4.4.1 AgentSpeak(L) . . . . . . . . . . . . . . . . . 4.4.2 Form´aln´ı specifikace dMars a 3APL . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
5 Modelov´ an´ı BDI agent˚ u objektovˇ e orientovan´ ymi Petriho s´ıtˇ emi 5.1 Poˇzadavky, c´ıle, v´ ychodiska . . . . . . . . . . . . . . . . . . . . . . . 5.2 Pˇrehled frameworku PNagent . . . . . . . . . . . . . . . . . . . . . . 5.3 Reprezentace b´aze pˇredstav . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Uk´azkov´ y syst´em – Cleaner world . . . . . . . . . . . . . . . 5.3.2 Tradiˇcn´ı zp˚ usob reprezentace b´ aze pˇredstav . . . . . . . . . . 5.3.3 Reprezentace b´aze pˇredstav pomoc´ı prostˇredk˚ u OOPN . . . . 5.4 Pl´any . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Pˇrid´av´an´ı specifick´e funkˇcnosti instance pl´ anu . . . . . . . . . ˇ 5.4.2 Zivotn´ı cyklus instance pl´ anu . . . . . . . . . . . . . . . . . . 5.4.3 Priority pl´an˚ u. . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Ud´alosti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.1 Unifikace ud´alost´ı, spouˇstˇen´ı pl´ an˚ u . . . . . . . . . . . . . . . 5.5.2 C´ıle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6 Z´amˇery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7 Interpret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.1 Zpracov´an´ı ud´alost´ı . . . . . . . . . . . . . . . . . . . . . . . 5.7.2 Interpretace z´amˇer˚ u . . . . . . . . . . . . . . . . . . . . . . . 5.8 Prostˇred´ı a meziagentn´ı komunikace . . . . . . . . . . . . . . . . . . 5.8.1 Platforma jako zdroj podnˇet˚ u agenta . . . . . . . . . . . . . . 5.8.2 Sluˇzby poskytovan´e platformou . . . . . . . . . . . . . . . . . 5.9 Pˇr´ıklad aplikace frameworku PNagent . . . . . . . . . . . . . . . . . 5.9.1 Neform´aln´ı zad´an´ı u ´lohy . . . . . . . . . . . . . . . . . . . . . 5.9.2 Mobiln´ı roboti . . . . . . . . . . . . . . . . . . . . . . . . . . 5.9.3 Struktura modelu . . . . . . . . . . . . . . . . . . . . . . . . 5.9.4 Pˇredzpracov´an´ı dat a ud´ alosti . . . . . . . . . . . . . . . . . . 5.9.5 B´aze pˇredstav a pl´ any . . . . . . . . . . . . . . . . . . . . . . 5.9.6 Zhodnocen´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.10 Jin´e pˇr´ıstupy k modelov´an´ı multiagentn´ıch syst´em˚ u Petriho s´ıtˇemi .
2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pˇ rehled publikac´ı autora
82
Pˇ r´ılohy
83
A Syntax jazyka PNtalk
84
B Model Cleaner world
86
C Model Blocks world
92
D N´ avod pro spuˇ stˇ en´ı model˚ u na pˇ riloˇ zen´ em CD
97
3
Kapitola 1
´ Uvod Multiagentn´ım syst´emem naz´ yv´ ame syst´em, ve kter´em se nach´ az´ı nˇekolik autonomn´ıch prvk˚ u – naz´ yvan´ ych agenti – kter´e spolu interaguj´ı. Autonomi´ı m´ ame na mysli schopnost dlouhodobˇe plnit c´ıle zadan´e uˇzivatelem bez jeho dohledu. Interakce pˇredstavuje komplexn´ı soci´aln´ı aktivity, jako kooperace, vyjedn´ av´ an´ı, apod. Multiagentn´ı syst´emy pˇredstavuj´ı relativnˇe nov´ y vˇedn´ı obor – prvn´ı pr´ ace v t´eto oblasti se datuj´ı do osmdes´at´ ych let minul´eho stolet´ı, do ˇsirok´eho povˇedom´ı se multiagentn´ı syst´emy dostaly v polovinˇe let devades´ at´ ych, zejm´ena v d˚ usledku prudk´eho rozvoje Internetu, kter´ y pro nˇe pˇredstavuje zˇrejmˇe nejd˚ uleˇzitˇejˇs´ı aplikaˇcn´ı dom´enu. Multiagentn´ı syst´emy jsou obor velmi interdisciplin´arn´ı – nejbl´ıˇze maj´ı k umˇel´e inteligenci, vych´ az´ı vˇsak i z dalˇs´ıch pˇr´ırodn´ıch i spoleˇcensk´ ych vˇed, jako jsou softwarov´e inˇzen´ yrstv´ı, robotika, logika, ekonomie, ekologie, sociologie, filozofie a dalˇs´ı. Abstrakce autonomn´ı entity – agenta – nach´ az´ı uplatnˇen´ı v mnoha aplikaˇcn´ıch oblastech. Jako pˇr´ıklad jmenujme komplexn´ı softwarov´e syst´emy, kde jednotliv´e komponenty jsou natolik nez´avisl´e a sloˇzit´e, ˇze z hlediska n´ avrhu je efektivn´ı povaˇzovat je za zcela samostatn´e jednotky, kter´e spolu komunikuj´ı ve velmi mal´e m´ıˇre pomoc´ı vysoko´ urovˇ nov´eho jazyka, + napˇr´ıklad jen v pˇr´ıpadˇe nestandardn´ıch situac´ı [SBD 00]. Dalˇs´ımi oblastmi jsou t´ ymov´ a spolupr´ace robot˚ u (napˇr. dobˇre zn´ am´ y robotick´ y fotbal [Kit98]), telekomunikaˇcn´ı aplikace (mobiln´ı agenti, kteˇr´ı migruj´ı po s´ıti za daty, coˇz vede k minimalizaci zat´ıˇzen´ı komunikaˇcn´ı infrastruktury) [AM04], software s vysokou m´ırou rekonfigurovatelnosti a pˇrizp˚ usobivosti (zak´azkov´a v´ yroba [Kou01], ˇr´ıd´ıc´ı syst´emy letiˇstˇe [GR96]), distribuovan´e aplikace na Internetu (napˇr. dolov´an´ı z dat) [KHS97], senzorov´e s´ıtˇe [LTO03], s´emantick´ y web (agenti vyhled´avaj´ıc´ı pro uˇzivatele komplexn´ı informace) [HM03], simulace socioekonomick´ ych proces˚ u [MP01] a mnoho dalˇs´ıch. V´ yzkum a v´ yvoj v oblasti multiagentn´ıch syst´em˚ u se v souˇcasn´e dobˇe soustˇred’uje do nˇekolika oblast´ı. Velk´a pozornost je vˇenov´ ana nasazov´ an´ı re´ aln´ ych multiagentn´ıch aplikac´ı v pr˚ umyslu, s ˇc´ımˇz u ´zce souvis´ı standardizace (o tu se star´a zejm´ena organizace FIPA1 ). Tato standardizace se zab´ yv´a zejm´ena moˇznostmi spolupr´ ace mezi heterogenn´ımi agenty – tedy jazyky pro komunikaci, sluˇzbami pro podporu bˇehu a migraci agent˚ u apod. Souˇcasnˇe vˇsak st´ale pokraˇcuje v´ yzkum vhodn´ ych vnitˇrn´ıch model˚ u agenta – a to jednak na rovinˇe teoretick´e, kde je kl´ıˇcovou ot´azkou jak´e architektury jsou vhodn´e pro modelov´ an´ı rozhodovac´ıch proces˚ u agenta a jejich form´ aln´ı popis, ale samozˇrejmˇe tak´e praktiˇctˇeji zamˇeˇren´ y v´ yzkum na realizaci tˇechto princip˚ u a jejich implementaci pomoc´ı vhodn´ ych prostˇredk˚ u. 1
http://www.fipa.org
4
1.1
Motivace, c´ıle disertaˇ cn´ı pr´ ace
Pˇredloˇzen´a disertaˇcn´ı pr´ace se zab´ yv´ a moˇznostmi modelov´ an´ı jedn´e z popul´ arn´ıch architektur agenta (architektury BDI) pomoc´ı formalismu objektovˇe orientovan´ych Petriho s´ıt´ı. Petriho s´ıtˇe jsou povaˇzov´any za dobr´ y n´ astroj pro modelov´ an´ı paralelismu. Mezi jejich v´ yhody patˇr´ı snadn´a pochopitelnost a vizu´ aln´ı reprezentace. Pˇritom jsou na rozd´ıl od vˇetˇsiny programovac´ıch jazyk˚ u zaloˇzeny na form´ aln´ım apar´ atu, kter´ y umoˇzn ˇuje s´ıtˇe automaticky analyzovat a ovˇeˇrovat jejich vlastnosti. Multiagentn´ı syst´emy jsou inherentnˇe paraleln´ı – tento paralelismus pramen´ı ze dvou hlavn´ıch zdroj˚ u. Prvn´ım je paralelismus v r´amci cel´eho syst´emu, tedy interakce mezi jednotliv´ ymi agenty, kdy tyto autonomn´ı jednotky nez´avisle na sobˇe pˇretv´aˇr´ı prostˇred´ı ve kter´em se nach´ az´ı. Druh´ y zdroj paralelismu nach´az´ıme uvnitˇr agenta, jelikoˇz vˇetˇsina netrivi´ aln´ıch agent˚ u obsahuje celou ˇradu senzor˚ u a aktu´ator˚ u, proto pro sv˚ uj efektivn´ı chod mus´ı vykon´ avat celou ˇradu ˇcinnost´ı z´ aroveˇ n. Zd´ a se tedy, ˇze Petriho s´ıtˇe by mˇely b´ yt vhodn´ ym prostˇredkem pro tvorbu a modelov´ an´ı agentn´ıch syst´em˚ u. Skuteˇcnˇe, byla publikov´ ana cel´ a ˇrada prac´ı na toto t´ema, napˇr´ıklad [MW97], [WH02] ˇci [YC06]. Tyto studie vˇsak byly vˇetˇsinou realizov´ any pomoc´ı barven´ych Petriho s´ıt´ı, pˇr´ıpadnˇe nˇekter´e jejich objektov´e nadstavby. Srovn´ an´ı s tˇemito pˇr´ıstupy bude provedeno pozdˇeji, hlavn´ı rozd´ıl vˇsak spoˇc´ıv´ a v sam´e povaze pouˇzit´eho formalismu. Zat´ımco barven´e Petriho s´ıtˇe z˚ ust´avaj´ı ve sv´e podstatˇe statick´e (v modelu mohou pouze vznikat ˇci zanikat znaˇcky), objektovˇe orientovan´e Petriho s´ıtˇe umoˇzn ˇuj´ı daleko vˇetˇs´ı dynamiku modelu. Tato dynamika je pro modelov´ an´ı a tvorbu multiagentn´ıch syst´em˚ u velmi d˚ uleˇzit´ a, domn´ıv´am se dokonce, ˇze kl´ıˇcov´a. To umoˇzn ˇuje pouˇz´ıvat pˇri modelov´ an´ı agent˚ u Petriho s´ıtˇemi zcela nov´e pˇr´ıstupy, kter´e se v´ıce bl´ıˇz´ı tradiˇcn´ımu programov´ an´ı, pˇri zachov´ an´ı v´ yhod Petriho s´ıt´ı – grafick´e reprezentace, form´ alnˇe definovan´e s´emantiky, moˇznost´ı vysoko´ urovˇ nov´e verifikace modelu atd. N´astroj PNtalk, kter´ y pˇredstavuje prostˇred´ı pro tvorbu model˚ u a jejich simulaci zaloˇzen´ y na formalismu objektovˇe orientovan´ ych Petriho s´ıt´ı se st´ ale nach´ az´ı ve f´ azi prototypu. Jedn´ım z c´ıl˚ u pˇredloˇzen´e pr´ace tak bylo zhodnocen´ı pouˇzitelnosti syst´emu PNtalk pro modelov´an´ı inteligentn´ıch syst´em˚ u obecnˇe, vˇcetnˇe spolupr´ ace s autory na v´ yvoji metodiky modelov´an´ı v tomto syst´emu. Hlavn´ı c´ıle pˇredloˇzen´e pr´ ace tak m˚ uˇzeme shrnout do dvou bod˚ u: • Navrhnout framework pro modelov´ an´ı BDI agent˚ u pomoc´ı objektovˇe orientovan´ ych Petriho s´ıt´ı, kter´ y umoˇzn´ı modelov´ an´ı a v´ yvoj multiagentn´ıch aplikac´ı, z´ aroveˇ n vˇsak bude otevˇren´ y tak, aby umoˇzn ˇoval experimenty se samotnou architekturou BDI. • Zhodnotit moˇznosti modelov´ an´ı inteligentn´ıch syst´em˚ u pomoc´ı n´ astroje PNtalk, doplnit metodiku modelov´an´ı v tomto syst´emu.
1.2
Struktura pr´ ace
´ Pr´ace se skl´ad´a z celkem ˇsesti kapitol. Ulohou prvn´ı kapitoly bylo struˇcnˇe uv´est ˇcten´ aˇre do problematiky, vysvˇetlit motivaci a vymezit c´ıle t´eto disertaˇcn´ı pr´ ace. Druh´a kapitola se vˇenuje objektovˇe orientovan´ ym Petriho s´ıt´ım. Nejprve jsou struˇcnˇe prezentov´any souvislosti, tedy klasick´e P/T Petriho s´ıtˇe a barven´e Petriho s´ıtˇe. N´ asleduje neform´aln´ı popis struktury i dynamiky objektovˇe orientovan´ ych Petriho s´ıt´ı a pˇredstaven´ı jazyka a n´astroje PNtalk. Zbytek kapitoly se vˇenuje rozˇs´ıˇren´ı jazyka PNtalk o koncept negativn´ıch predik´at˚ u, kter´ y pˇredstavuje pˇr´ıspˇevek k metodice modelov´ an´ı pomoc´ı tohoto
5
n´astroje a jeden z pˇr´ınos˚ u pˇredloˇzen´e pr´ ace. C´ılem druh´e kapitoly je tedy pˇredstavit n´ astroje a metody pouˇzit´e v t´eto pr´aci. Tˇret´ı kapitola se vˇenuje agent˚ um a multiagentn´ım syst´em˚ um obecnˇe. Nejprve jsou vymezeny z´akladn´ı pojmy, d´ale je provedeno rozdˇelen´ı agent˚ u podle jejich vnitˇrn´ı architektury. N´asleduje diskuze vybran´ ych ˇc´ ast´ı problematiky multiagentn´ıch syst´em˚ u, kter´e souvis´ı s pˇredloˇzenou prac´ı – zejm´ena ot´azky prostˇred´ı agenta, komunikace a standardizace multiagentn´ıch syst´em˚ u. C´ılem t´eto kapitoly je vymezit pouˇz´ıvan´e pojmy a uv´est prezentovanou pr´aci do kontextu. ˇ Ctvrt´ a kapitola se podrobnˇeji zab´ yv´ a architekturou BDI z r˚ uzn´ ych pohled˚ u – filozofick´eho, form´aln´ıho a implementaˇcn´ıho, spoleˇcnˇe s pˇrehledem nejzn´ amˇejˇs´ıch projekt˚ u v t´eto oblasti. C´ılem t´eto kapitoly je d´at teoretick´ a v´ ychodiska pro prezentovanou pr´ aci. P´at´a kapitola pˇredstavuje vlastn´ı framework a pˇredstavuje tak hlavn´ı pˇr´ınos pˇredloˇzen´e pr´ace. Nejprve jsou diskutov´any z´ akladn´ı principy fungov´ an´ı frameworku, d´ ale jsou podrobnˇe pˇredstaveny jeho jednotliv´e aspekty – pˇredstavy, ud´ alosti, pl´ any, z´ amˇery, atd. Pot´e je pˇredstavena uk´azka nasazen´ı frameworku v re´ aln´e aplikaci – ˇr´ızen´ı skupiny mobiln´ıch robot˚ u. Na z´avˇer je provedeno porovn´ an´ı frameworku s ostatn´ımi pˇr´ıstupy v dostupn´e literatuˇre. V z´avˇereˇcn´e ˇsest´e kapitole jsou shrnuty v´ ysledky disertaˇcn´ı pr´ ace, diskutov´ any moˇznosti dalˇs´ıho v´ yzkumu a provedeno zhodnocen´ı splnˇen´ı c´ıl˚ u.
6
Kapitola 2
Objektovˇ e orientovan´ e Petriho s´ıtˇ e Petriho s´ıtˇe pˇredstavuj´ı tˇr´ıdu matematick´ ych model˚ u pouˇz´ıvan´ ych zejm´ena pro modelov´ an´ı paralelismu, kauzality a nedeterminismu v diskr´etn´ıch distribuovan´ ych syst´emech. Naz´ yvaj´ı se podle nˇemeck´eho matematika C. A. Petriho, kter´ y ve sv´e doktorsk´e disertaˇcn´ı pr´ aci v roce 1962 zavedl nov´e koncepty popisu z´ avislosti mezi podm´ınkami a ud´ alostmi v modelovan´em syst´emu. Koncepˇcnˇe vych´azej´ı z paralelnˇe pracuj´ıc´ıch a komunikuj´ıc´ıch koneˇcn´ ych automat˚ u. Kromˇe form´aln´ıho popisu maj´ı takt´eˇz grafickou reprezentaci ve formˇe orientovan´eho bipartitn´ıho grafu, d´ıky kter´e je modelov´ an´ı syst´em˚ u jejich prostˇrednictv´ım intuitivn´ı. Tyto grafy se skl´adaj´ı z m´ıst a pˇrechod˚ u spojen´ ych orientovan´ymi hranami. M´ısta mohou obsahovat libovoln´ y poˇcet znaˇcek. Stav syst´emu je vyj´ adˇren rozloˇzen´ım znaˇcek v m´ıstech s´ıtˇe, toto rozloˇzen´ı se naz´ yv´a znaˇcen´ı. Klasick´e Petriho s´ıtˇe, naz´ yvan´e t´eˇz P/T Petriho s´ıtˇe (Place/Transition Petri nets), patˇr´ı k velmi rozˇs´ıˇren´ ym formalism˚ um a jsou pomˇernˇe dobˇre pops´ any v ˇradˇe publikac´ı, ˇ s94]. P/T Petriho s´ıtˇe je moˇzn´e celkem snadno doplnit o inhibiˇcn´ı hrany napˇr´ıklad v [Ceˇ (hrany, kter´e vyˇzaduj´ı, aby v m´ıstˇe bylo m´enˇe znaˇcek, neˇz je ohodnocen´ı t´eto hrany). Pˇr´ıklad grafick´eho zn´azornˇen´ı takov´e s´ıtˇe je na obr´ azku 2.1 (inhibiˇcn´ı hrana je zn´ azornˇena jako hrana, kter´a nen´ı ukonˇcena ˇsipkou, ale mal´ ym krouˇzkem). Takov´eto s´ıtˇe jiˇz dosahuj´ı v´ ypoˇcetn´ı s´ıly Turingova stroje [DA92], takˇze teoreticky jsou schopny modelovat libovoln´ y algoritmus. Z praktick´eho hlediska vˇsak maj´ı jedno z´ asadn´ı omezen´ı – neposkytuj´ı ˇz´ adn´e prostˇredky pro strukturov´an´ı modelu. Pˇri modelov´ an´ı rozs´ ahl´ ych syst´em˚ u se tak v´ ysledn´ y model st´av´a velmi nepˇrehledn´ ym, pˇr´ıpadnˇe zachycuje pouze vztahy mezi z´ akladn´ımi komponentami syst´emu. Pro pˇrekon´an´ı tohoto omezen´ı byla navrˇzena cel´ a ˇrada rozˇs´ıˇren´ı, kter´ a b´ yvaj´ı souhrnnˇe oznaˇcov´ana jako vysoko´ urovˇ nov´e Petriho s´ıtˇe, HLPN (High-Level Petri nets). Zˇrejmˇe nejv´ıce pouˇz´ıvanou variantou HLPN jsou Barven´e Petriho s´ıtˇe, CPN (Coloured Petri nets).
Obr´azek 2.1: Pˇr´ıklad P/T Petriho s´ıtˇe doplnˇen´e o inhibiˇcn´ı hranu (zn´ azornˇena ukonˇcen´ım hrany mal´ ym krouˇzkem m´ısto ˇsipky)
7
2.1
Vysoko´ urovˇ nov´ e Petriho s´ıtˇ e
Barven´e Petriho s´ıtˇe [Jen97] zaveden´e prof. Jensenem pˇredstavuj´ı velmi v´ yznamn´e rozˇs´ıˇren´ı p˚ uvodn´ıch P/T Petriho s´ıt´ı. Zat´ımco v P/T Petriho s´ıt´ıch jsou znaˇcky nerozliˇsiteln´e, v CPN m˚ uˇze kaˇzd´a znaˇcka n´est hodnotu. Barva znaˇcky pak ud´ av´ a jej´ı typ. Pˇrechody mohou m´ıt podm´ınky proveditelnosti, kontroluj´ıc´ı atributy tˇechto znaˇcek. Kromˇe grafick´eho vyj´ adˇren´ı s´ıtˇe je model doplnˇen o form´ aln´ı inskripci, kter´ a obsahuje: • definice typ˚ u znaˇcek v modelu; • poˇc´ateˇcn´ı znaˇcen´ı jednotliv´ ych m´ıst; • hranov´e v´ yrazy urˇcuj´ıc´ı jak´e znaˇcky jsou odeb´ır´ any ˇci pˇrid´ av´ any z m´ıst, kter´e jsou spojeny danou hranou s pˇrechodem; • str´aˇzn´ı podm´ınky pˇr´ısluˇsej´ıc´ı dan´ ym pˇrechod˚ um, jeˇz omezuj´ı jejich proveditelnost v z´avislosti na atributech znaˇcek; • procedury, opˇet spojen´e s jednotliv´ ymi pˇrechody, kter´e umoˇzn ˇuj´ı prov´ adˇet v´ ypoˇcty se znaˇckami, vˇcetnˇe vedlejˇs´ıch efekt˚ u. Pˇr´ıklad grafick´e reprezentace jednoduch´e barven´e Petriho s´ıtˇe ukazuje obr´ azek 2.2. V´ ysledn´ y modelovac´ı jazyk spojuje v´ yhody klasick´e Petriho s´ıtˇe a vysoko´ urovˇ nov´eho programovac´ıho jazyka. Pro pr´aci s CPN autoˇri jiˇz od poˇc´ atku vyv´ıjej´ı modelovac´ı n´ astroje, takˇze veˇsker´a teorie m˚ uˇze b´ yt ihned aplikov´ ana v praxi. P˚ uvodn´ı n´ astroj Design CPN dos´ahl pomˇernˇe velk´eho rozˇs´ıˇren´ı, v souˇcasn´e dobˇe je nahrazen novˇejˇs´ım softwarem CPN Tools. Tyto n´astroje se skl´adaj´ı z nˇekolika komponent – grafick´eho editoru s´ıt´ı, kter´ y umoˇzn ˇuje intuitivn´ı tvorbu model˚ u; interaktivn´ıho simul´ atoru bˇehu s´ıtˇe a koneˇcnˇe sady n´astroj˚ u pro ovˇeˇrov´an´ı vlastnost´ı model˚ u.
Obr´azek 2.2: Pˇr´ıklad barven´e Petriho s´ıtˇe Formalismus barven´ ych Petriho s´ıt´ı umoˇzn ˇuje modelovat v´ yraznˇe komplexnˇejˇs´ı syst´emy neˇz P/T Petriho s´ıtˇe. Je to d´ano zejm´ena moˇznost´ı nˇekter´e ˇc´ asti modelovan´eho syst´emu vyj´adˇrit pomoc´ı operac´ı se znaˇckami. Hierarchick´e barven´e Petriho s´ıtˇe (HCPN) d´ ale rozˇsiˇruj´ı CPN o podporou pro statick´e strukturov´ an´ı s´ıtˇe pomoc´ı mechanismu str´ anek. Jist´ ym omezen´ım vˇsak z˚ ust´av´a celkov´a statiˇcnost s´ıtˇe – v s´ıti mohou vznikat a zanikat znaˇcky, nen´ı vˇsak moˇzn´e mˇenit strukturu s´ıtˇe (pˇrid´ avat ˇci ub´ırat m´ısta a pˇrechody) bˇehem jej´ıho prov´adˇen´ı. Tuto nev´ yhodu se snaˇzili odstranit r˚ uzn´ı autoˇri spojen´ım koncept˚ u Petriho s´ıt´ı a technik objektovˇe orientovan´eho modelov´ an´ı. Jedn´ım z tˇechto pˇr´ıstup˚ u jsou objektovˇe orientovan´e Petriho s´ıtˇe, OOPN (Object oriented Petri nets), kter´e zavedl V. Janouˇsek ve sv´e doktorsk´e disertaˇcn´ı pr´aci [Jan98]. OOPN spojuj´ı v´ yhody obou pouˇzit´ ych paradigmat – Petriho s´ıtˇe umoˇzn ˇuj´ı form´alnˇe popsat vlastnosti modelovan´eho syst´emu, zat´ımco objektov´ a orientace pˇrin´ aˇs´ı pˇrirozen´e 8
moˇznosti strukturov´an´ı modelu a moˇznost dynamick´eho vytv´ aˇren´ı instanc´ı s´ıt´ı. Inspirac´ı pro objektov´ y model OOPN byl jazyk Smalltalk, coˇz ve struˇcnosti znamen´ a, ˇze: • Kaˇzd´ y objekt je instanc´ı nˇejak´e tˇr´ıdy. • Veˇsker´e v´ ypoˇcty v r´amci inskripˇcn´ıho jazyka se prov´ adˇej´ı zas´ıl´ an´ım zpr´ av mezi objekty. • Promˇenn´e obsahuj´ı reference na objekty. • Tˇr´ıda definuje chov´an´ı sv´ ych instanc´ı jako mnoˇzinu metod, kter´e specifikuj´ı reakci na zasl´an´ı zpr´avy. • Tˇr´ıdy jsou definov´any inkrement´ alnˇe, tedy kaˇzd´ a tˇr´ıda je podtˇr´ıdou nˇejak´e existuj´ıc´ı tˇr´ıdy (pouˇz´ıv´a se jednoduch´ a dˇediˇcnost). Tento z´akladn´ı model byl obohacen o prvek soubˇeˇznosti – objekty jsou ch´ ap´ any jako aktivn´ı servery, kter´e poskytuj´ı sluˇzby ostatn´ım objekt˚ um. Vlastn´ı chov´ an´ı objektu, stejnˇe jako poskytovan´e sluˇzby jsou pops´ any pomoc´ı Petriho s´ıt´ı.
2.2
Neform´ aln´ı specifikace OOPN
V t´eto ˇc´asti budou struˇcnˇe a neform´ alnˇe pops´ any z´ aklady formalismu objektovˇe orientovan´ ych Petriho s´ıt´ı. Nejprve se budu zab´ yvat strukturou OOPN, tedy jak´e prostˇredky OOPN poskytuj´ı pro popis model˚ u, a pot´e dynamikou OOPN, tedy jak jsou tyto modely interpretov´any. Smyslem t´eto ˇc´asti je sezn´ amit ˇcten´ aˇre s formalismem OOPN tak, aby rozumˇel popisu a model˚ um prezentovan´ ym v dalˇs´ıch ˇc´ astech pr´ ace. Form´ aln´ı definice vˇsech pojm˚ u diskutovan´ ych d´ale je moˇzn´e nal´ezt v [Jan98].
2.2.1
Z´ akladn´ı prvky s´ıt´ı v OOPN
S´ıtˇe se v OOPN skl´adaj´ı z m´ıst a pˇrechod˚ u, kter´e jsou spojeny orientovan´ ymi hranami. Pˇr´ıklad grafick´eho vyj´adˇren´ı jednoduch´e s´ıtˇe s popisem jednotliv´ ych prvk˚ u ukazuje obr´ azek 2.3. M´ısta maj´ı stejn´ y v´ yznam jako v bˇeˇzn´ ych Petriho s´ıt´ıch, zachycuj´ı tedy parci´ aln´ı stav modelovan´eho syst´emu. Kaˇzd´e m´ısto m˚ uˇze m´ıt poˇc´ ateˇcn´ı znaˇcen´ı (multimnoˇzinu znaˇcek).
Obr´azek 2.3: Z´ akladn´ı prvky s´ıtˇe OOPN
9
Pˇrechody vyjadˇruj´ı zmˇeny v syst´emu, kaˇzd´ y pˇrechod m´ a dvˇe ˇc´ asti – str´ aˇz a akci. Str´ aˇz omezuje proveditelnost pˇrechodu, skl´ ad´ a se z konjunkce booleovsk´ ych v´ yraz˚ u (booleovsk´ ym v´ yrazem se rozum´ı zasl´an´ı zpr´avy objektu jej´ımˇz v´ ysledkem je booleovsk´ y n´ avratov´ y typ). Akce umoˇzn ˇuje prov´adˇet v´ ypoˇcty se znaˇckami, tj. zas´ılat zpr´ avy objekt˚ um s moˇznost´ı pˇriˇradit v´ ysledek do promˇenn´e. Je moˇzn´e prov´est v´ıce akc´ı v jednom pˇrechodu, tento pˇrechod se pak ch´ape jako sekvence pˇrechod˚ u s vloˇzen´ ymi m´ısty tak, aby mezi tˇemito pˇrechody doˇslo k pˇrenosu pˇr´ısluˇsn´ ych znaˇcek a aby takto upraven´ a s´ıt’ odpov´ıdala definici Petriho s´ıtˇe. Hrany reprezentuj´ı vstupn´ı a v´ ystupn´ı podm´ınky pˇrechod˚ u. Vstupn´ı podm´ınka je graficky reprezentovan´a ˇsipkou smˇeˇruj´ıc´ı od m´ısta k pˇrechodu, v´ ystupn´ı podm´ınka ˇsipkou od pˇrechodu k m´ıstu. D´ale jsou zavedeny testovac´ı hrany, jeˇz jsou graficky reprezentovan´e oboustrann´ ymi ˇsipkami. Hrany jsou ohodnoceny hranov´ ymi v´ yrazy, coˇz jsou opˇet multimnoˇziny znaˇcek, pˇriˇcemˇz nˇekter´e znaˇcky mohou b´ yt nahrazeny voln´ ymi promˇenn´ ymi. Tyto promˇenn´e se pak navazuj´ı na konkr´etn´ı znaˇcky pˇri testov´ an´ı proveditelnosti pˇrechodu. Znaˇcky pˇredstavuj´ı reference na objekty nebo jejich n-tice, tyto objekty mohou b´ yt bud’ tzv. statick´e (primitivn´ı) nebo neprimitivn´ı. Statick´e objekty jsou ch´ ap´ any jako konstanty, jejichˇz jm´ena lze ztotoˇznit s obsahem (hodnotou) objektu. Jedn´ a se napˇr´ıklad o ˇc´ısla, znaky, ˇretˇezce, symboly, apod. Neprimitivn´ı objekty jsou pops´ any pomoc´ı Petriho s´ıt´ı a jejich strukturou se zab´ yv´a n´asleduj´ıc´ı podkapitola.
2.2.2
Struktura neprimitivn´ıch objekt˚ u
Neprimitivn´ı objekty jsou definov´ any svoj´ı tˇr´ıdou. Tˇr´ıda obsahuje: • pr´avˇe jednu objektovou s´ıt’ (kter´ a vˇsak m˚ uˇze b´ yt pr´ azdn´ a), • mnoˇzinu s´ıt´ı metod, • mnoˇzinu synchronn´ıch port˚ u. Objektov´a s´ıt’ popisuje autonomn´ı chov´ an´ı objektu. Tato s´ıt’ je instanciovan´ a v okamˇziku vytvoˇren´ı objektu a jej´ı doba ˇzivota je sv´ az´ ana s dobou ˇzivota objektu. S´ıtˇe metod popisuj´ı reakce na zpr´ avy, kter´e jsou objektu zas´ılan´e z akc´ı pˇrechod˚ u. Tyto s´ıtˇe jsou instanciov´any v okamˇziku vyvol´ an´ı metody a zruˇseny pˇri jej´ım ukonˇcen´ı. Pro kaˇzd´ y parametr metody obsahuje s´ıt’ speci´ aln´ı m´ısto se stejn´ ym n´ azvem, jak´ y m´ a form´aln´ı parametr, do kter´eho se v okamˇziku vyvol´ an´ı metody vloˇz´ı znaˇcky reprezentuj´ıc´ı skuteˇcn´e parametry metody. S´ıt’ d´ale obsahuje jedno speci´ aln´ı m´ısto s n´ azvem return, do kter´eho se uloˇz´ı n´avratov´a hodnota metody. Toto m´ısto nem˚ uˇze b´ yt souˇc´ ast´ı vstupn´ı podm´ınky ˇz´adn´eho pˇrechodu. Pˇrechody s´ıtˇe metody mohou b´ yt propojeny hranami s m´ısty v objektov´e s´ıti objektu, kter´e tak mohou slouˇzit jako ˇclensk´e promˇenn´e. Synchronn´ı porty definuj´ı reakce objektu na synchronn´ı zpr´ avy zas´ılan´e ze str´ aˇz´ı pˇrechod˚ u. Jsou to v podstatˇe speci´aln´ı pˇrechody, kter´e nemaj´ı ˇz´ adnou akci a slouˇz´ı k testov´ an´ı stavu objektu, pˇr´ıpadnˇe prov´adˇen´ı postrann´ıho efektu. D˚ uleˇzit´e je, ˇze tyto porty se mus´ı vyhodnotit atomicky, protoˇze se st´ avaj´ı souˇc´ ast´ı str´ aˇze pˇrechodu, kter´ y synchronn´ı zpr´avu zaslal. Pokud je tento pˇrechod proveden, provede se i postrann´ı efekt synchronn´ıho portu. Synchronn´ı porty, kter´e nemaj´ı ˇz´ adn´ y postrann´ı efekt a slouˇz´ı tedy ˇcistˇe k testov´ an´ı stavu objektu, naz´ yv´ame predik´ aty. Pˇr´ıklad tˇr´ıdy neprimitivn´ıho objektu ukazuje obr´ azek 2.4. Tˇr´ıdy se v OOPN definuj´ı inkrement´ alnˇe s vyuˇzit´ım dˇediˇcnosti. Koˇrenem stromu dˇediˇcnosti (pˇripomeˇ nme, ˇze OOPN podporuj´ı jednoduchou dˇediˇcnost) je tˇr´ıda PN, kter´ a m´ a pr´azdnou objektovou s´ıt’ i mnoˇziny s´ıt´ı metod a synchronn´ıch port˚ u. Tato tˇr´ıda definuje z´akladn´ı chov´an´ı vˇsech aktivn´ıch objekt˚ u v OOPN. 10
% %
$% ! " # $
# # %
Obr´azek 2.4: Pˇr´ıklad tˇr´ıdy neprimitivn´ıho objektu v OOPN
2.2.3
Dynamick´ e chov´ an´ı OOPN
Stav OOPN se naz´ yv´a znaˇcen´ı, m˚ uˇzeme jej ch´ apat jako syst´em OOPN objekt˚ u. Dynamick´e chov´an´ı OOPN pak odpov´ıd´ a evoluci tohoto syst´emu. Jedna tˇr´ıda je vˇzdy oznaˇcena jako hlavn´ı, pro tuto tˇr´ıdu se na poˇc´ atku simulace vytvoˇr´ı jedna jej´ı instance – objekt. Inicializovanou objektovou s´ıt’ tohoto objektu naz´ yv´ ame poˇca ´teˇcn´ı znaˇcen´ı. Evoluce s´ıt´ı v OOPN je zaloˇzena na ud´ alostech, coˇz je z´ asadn´ı rozd´ıl oproti evoluci k´odu klasick´ ych imperativn´ıch programovac´ıch jazyk˚ u, kter´ a je zaloˇzena na procesech. Ud´ alosti v OOPN odpov´ıdaj´ı proveditelnosti pˇrechodu. Podle typu proveditelnosti se rozliˇsuj´ı ˇctyˇri typy ud´alost´ı [Jan98]: • Ud´ alost typu A (atomic) – atomick´e proveden´ı pˇrechodu, v akci pˇrechodu se zas´ıl´ a zpr´ava statick´emu objektu. Odebr´ an´ı znaˇcek ze vstupn´ıch m´ıst, proveden´ı akce a uloˇzen´ı znaˇcek do v´ ystupn´ıch m´ıst pˇrechodu se provede souˇcasnˇe, jako nedˇeliteln´ a operace. • Ud´ alost typu N (new) – vytvoˇren´ı nov´eho neprimitivn´ıho objektu, pˇrechod je tak´e proveden atomicky, ale vznikne pˇritom nov´ y objekt. • Ud´ alost typu F (fork) – zasl´ an´ı zpr´ avy neprimitivn´ımu objektu. Pˇrechod ˇcek´ a na dokonˇcen´ı vyvolan´e metody, jedn´ a se tedy o ne´ upln´e proveden´ı pˇrechodu. Odeberou se znaˇcky ze vstupn´ıch m´ıst a vytvoˇr´ı se nov´ a instance s´ıtˇe odpov´ıdaj´ıc´ı metody (to vˇse jako atomick´a operace). • Ud´ alost typu J (join) – dokonˇcen´ı pˇrechodu po skonˇcen´ı vyvolan´e metody. Zruˇs´ı se instance s´ıtˇe odpov´ıdaj´ıc´ı metody a uloˇz´ı se znaˇcky do v´ ystupn´ıch m´ıst pˇrechodu. To vˇse jako atomick´a operace. 11
Po kaˇzd´e ud´alosti se provede garbage collecting, kter´ y zajist´ı skuteˇcn´e zruˇsen´ı instanc´ı s´ıt´ı na kter´e neexistuje reference.
2.3
Jazyk a syst´ em PNtalk
Na formalismu objektovˇe orientovan´ ych Petriho s´ıt´ı je zaloˇzen jazyk a syst´em PNtalk (Petri Nets & Smalltalk). Textovˇe grafick´ y jazyk PNtalk pˇredstavuje konkr´etn´ı implementaci OOPN. Vych´az´ı pˇr´ımo z jejich definice, m´ a vˇsak nˇekter´e drobn´e syntaktick´e odliˇsnosti a vylepˇsen´ı (konstruktory, sloˇzen´e zpr´ avy apod.), inspirovan´e jazykem Smalltalk. Konkretizuje tak´e ty ˇc´asti definice OOPN, kde p˚ uvodn´ı specifikace ponech´ av´ a urˇcitou volnost – pˇredevˇs´ım v oblasti statick´ ych objekt˚ u. Syntaxi textov´e formy jazyka ve formˇe Backus-Naurovy formy je moˇzno nal´ezt v [Koˇc04]. Syst´em PNtalk pak pˇredstavuje n´ astroj pro modelov´ an´ı, simulaci, verifikaci a prototypov´an´ı syst´em˚ u, postaven´ y na tomto jazyce, implementovan´ y v prostˇred´ı Smalltalk (viz obr´azek 2.5). Syst´em PNtalk je vyv´ıjen na VUT v Brnˇe od roku 1993, prvn´ı verze nesla oznaˇcen´ı PNtalk 96. Od poˇc´ atku umoˇzn ˇuje transparentn´ı spolupr´ aci objekt˚ u OOPN a Smalltalku. Souˇcasn´a verze tohoto n´ astroje nese oznaˇcen´ı PNtalk 2007. PNtalk 2007 byl navrˇzen jako otevˇren´ y simulaˇcn´ı syst´em na b´ azi meta´ urovˇ nov´e architektury [JK03]. Hlavn´ı v´ yhody tohoto pˇr´ıstupu spoˇc´ıvaj´ı v moˇznosti modifikovat s´emantiku modelu v pr˚ ubˇehu jeho prov´adˇen´ı a kombinovat r˚ uzn´e modelovac´ı formalismy (heterogenn´ı simulace). Nev´ yhodu pak pˇredstavuj´ı zv´ yˇsen´e n´aroky na v´ ypoˇcetn´ı v´ ykon.
Obr´azek 2.5: Syst´em PNtalk 2007 – uk´ azka grafick´e i textov´e podoby jazyka a kombinace s heterogenn´ım modelem na b´azi DEVS
12
Jedna z moˇznost´ı heterogenn´ı simulace byla vyuˇzita v modelu ˇr´ızen´ı robota prezentovan´em d´ale v t´eto pr´aci. Zde se jednalo o propojen´ı PNtalku s n´ astrojem SmallDEVS [JK06], takt´eˇz vyv´ıjen´em na VUT v Brnˇe, kter´ y je zaloˇzen na formalismu DEVS (Discrete Event System Specification) [ZKP00]. PNtalk je v tomto pˇr´ıpadˇe zapouzdˇren jako atomick´ a komponenta DEVSu, komunikace prob´ıh´ a pomoc´ı pˇred´ av´ an´ı znaˇcek do urˇcen´ ych m´ıst ze vstupn´ıch port˚ u komponenty a naopak pˇresunem znaˇcek z jin´ ych m´ıst do v´ ystupn´ıch port˚ u komponenty [JK07]. Pro popis ˇr´ıd´ıc´ı ˇc´ asti robota je tak pouˇzit vysoko´ urovˇ nov´ y formalismus OOPN, kter´ y umoˇzn ˇuje snadno vyjadˇrovat paralelismus a zpracov´ an´ı pl´ an˚ u, zat´ımco pro vlastn´ı komunikaci s robotem ˇci simul´ atorem pomoc´ı protokolu TCP/IP jsou vyuˇzity jin´e formalismy vhodnˇejˇs´ı pro tento u ´ˇcel v nez´ avisl´ ych komponent´ ach. DEVS pˇredstavuje r´ amec pro spolupr´aci tˇechto formalism˚ u. V souˇcasn´e dobˇe se cel´ y projekt PNtalk zamˇeˇruje zejm´ena na podporu pro v´ yvoj a prototypov´an´ı syst´em˚ u zaloˇzen´ y na modelech a simulaci (model based design – MBD). Hlavn´ı myˇslenka MBD spoˇc´ıv´a v tom, ˇze model je pouˇz´ıv´ an od poˇc´ ateˇcn´ıch f´ az´ı n´ avrhu aˇz po fin´ aln´ı prototyp v´ ysledn´e aplikace, pˇr´ıpadnˇe se m˚ uˇze st´ at pˇr´ımo jej´ı souˇc´ ast´ı. Pˇredpokl´ adanou oblast vyuˇzit´ı PNtalku pˇredstavuje pˇredevˇs´ım n´ avrh a v´ yvoj inteligentn´ıch syst´em˚ u – pˇr´ıkladem je framework pro tvorbu inteligentn´ıch agent˚ u prezentovan´ y v t´eto pr´ aci. Cel´ y syst´em PNtalk je st´ale ve f´azi prototypu, jedn´ım z pˇr´ınos˚ u pˇredloˇzen´e pr´ ace tak byla spolupr´ace s autory PNtalku na obecn´e metodice modelov´ an´ı v PNtalku. V n´ asleduj´ıc´ı ˇc´asti bude prezentov´ano navrˇzen´e rozˇs´ıˇren´ı jazyka PNtalk o koncept negativn´ıch predik´ at˚ u, kter´e umoˇzn ˇuje v´ yraznˇe zjednoduˇsit jist´e ˇc´ asti modelu. Toto rozˇs´ıˇren´ı bylo publikov´ ano v [MJK08] a je pouˇz´ıv´ano v modelech prezentovan´ ych d´ ale v t´eto pr´ aci.
2.4
Navrˇ zen´ e rozˇ s´ıˇ ren´ı jazyka PNtalk
Jak jiˇz bylo ˇreˇceno, formalismus OOPN, na kter´em je jazyk PNtalk postaven, patˇr´ı mezi vysoko´ urovˇ nov´e Petriho s´ıtˇe a velk´ a ˇc´ ast jeho princip˚ u je obdobn´ a jako u barven´ ych Petriho s´ıt´ı. Hlavn´ı rozd´ıl mezi P/T a vysoko´ urovˇ nov´ ymi Petriho s´ıtˇemi spoˇc´ıv´ a v tom, ˇze u vysoko´ urovˇ nov´ ych Petriho s´ıt´ı mohou znaˇcky n´est hodnotu, se kterou lze manipulovat v r´amci pˇrechodu pomoc´ı inskripˇcn´ıho jazyka. Pˇri vytv´ aˇren´ı modelu je tak potˇreba rozhodnout, kter´e ˇc´asti modelovan´eho syst´emu vyj´ adˇrit pomoc´ı s´ıtˇe a kter´e pomoc´ı manipulace se znaˇckami. Toto rozhodnut´ı nemus´ı b´ yt vˇzdy jednoduch´e. U p˚ uvodn´ıch P/T Petriho s´ıt´ı nen´ı moˇzn´e testovat nepˇr´ıtomnost znaˇcky v m´ıstˇe. To je ˇ s94]. V´ tak´e d˚ uvodem, proˇc P/T Petriho s´ıtˇe nejsou v´ ypoˇcetnˇe u ´pln´e [Ceˇ ypoˇcetn´ı u ´plnosti je moˇzn´e dos´ahnout pouze rozˇs´ıˇren´ım formalismu, napˇr´ıklad o inhibiˇcn´ı hrany. Vysokou ´rovˇ nov´e Petriho s´ıtˇe inhibiˇcn´ı hrany nepotˇrebuj´ı, jelikoˇz stejn´eho efektu m˚ uˇze b´ yt dosaˇzeno konstrukcemi inskripˇcn´ıho jazyka. Nezaveden´ı inhibiˇcn´ıch hran je d˚ uleˇzit´e z hlediska anal´ yzy s´ıtˇe pomoc´ı invariant˚ u, avˇsak m˚ uˇze zp˚ usobit jist´e komplikace pˇri modelov´ an´ı, coˇz demonstruje n´asleduj´ıc´ı pˇr´ıklad. Znaˇcky budou nab´ yvat hodnot cel´ ych ˇc´ısel. Str´ aˇz jist´eho pˇrechodu bude m´ıt tvar x > 5 – ˇ chceme tedy, aby pˇrechod byl provediteln´ y, pokud znaˇcka m´ a hodnotu vˇetˇs´ı neˇz pˇet. Casto vˇsak potˇrebujeme tak´e vykonat nˇejakou akci v pˇr´ıpadˇe, ˇze podm´ınka splnˇena nen´ı. To odpov´ıd´a konstrukci if (podm´ınka) then akce1 else akce2 v imperativn´ıch programovac´ıch jazyc´ıch. Ve vysoko´ urovˇ nov´ ych Petriho s´ıt´ıch se tento pˇr´ıpad modeluje dvˇema pˇrechody, jeden m´a ve str´aˇzi podm´ınku zm´ınˇenou v´ yˇse (x > 5) a ten druh´ y jej´ı negaci (x <= 5). Oba pˇrechody mus´ı b´ yt spojeny vstupn´ı hranou s nˇejak´ ym m´ıstem v s´ıti, ve kter´em budou znaˇcky uloˇzeny. Nyn´ı pˇredpokl´adejme, ˇze v m´ıstˇe jiˇz nˇekolik znaˇcek je, a my chceme, aby prvn´ı pˇrechod byl provediteln´ y v pˇr´ıpadˇe, ˇze se v m´ıstˇe nach´ az´ı alespoˇ n jedna znaˇcka s danou 13
vlastnost´ı (x > 5). To je samozˇrejmˇe velmi jednoduch´e, jak ukazuje obr´ azek 2.6.
Obr´azek 2.6: Pˇr´ıklad testu pˇr´ıtomnosti znaˇcky s danou vlastnosti v m´ıstˇe ve formalismu OOPN Probl´em nastane, pokud poˇzadujeme proveditelnost pˇrechodu v pˇr´ıpadˇe, ˇze ˇza ´dn´ a znaˇcka v tomto m´ıstˇe nesplˇ nuje danou podm´ınku – bez dodateˇcn´ ych m´ıst a pˇrechod˚ u, ˇci u ´pln´e zmˇeny stylu ukl´ad´an´ı znaˇcek toho nejsme schopni. Schopnost naj´ıt v m´ıstˇe jednu znaˇcku s danou vlastnost´ı nen´ı tedy v HLPN symetrick´ a schopnosti otestovat, ˇze ˇz´ adn´ a znaˇcka v dan´em m´ıstˇe vlastnost nesplˇ nuje. To je zp˚ usobeno pr´ avˇe absenc´ı inhibiˇcn´ıch hran. V praxi to znamen´a, ˇze pokud potˇrebujeme otestovat, zda ˇz´ adn´ a znaˇcka v dan´em m´ıstˇe nesplˇ nuje nˇejakou vlastnost, mus´ıme pro ukl´ ad´ an´ı znaˇcek v m´ıstˇe pouˇz´ıt komplexnˇejˇs´ı struktury inskripˇcn´ıho jazyka.
2.4.1
ˇ sen´ı v barven´ Reˇ ych Petriho s´ıt´ıch
Pro modelov´an´ı pomoc´ı barven´ ych Petriho s´ıt´ı existuje v´ yraznˇe propracovanˇejˇs´ı metodika, neˇz je tomu u OOPN. Dokonce byla vytvoˇrena cel´ a ˇrada n´ avrhov´ych vzor˚ u [MvdA05], kter´e maj´ı usnadnit ˇreˇsen´ı typick´ ych probl´em˚ u n´ avrhu, obdobnˇe jako je tomu u metodiky pro objektovˇe orientovan´ y n´avrh. Tyto vzory mimo jin´e nab´ız´ı moˇzn´ a ˇreˇsen´ı pro situaci prezentovanou v´ yˇse – konkr´etnˇe se jedn´ a o dva vzory: Prvn´ı vzor se naz´ yv´a Inhibiˇcn´ı hrana. Je zaloˇzen na myˇslence poˇc´ıt´ an´ı znaˇcek v dan´em m´ıstˇe pomoc´ı jin´eho m´ısta obsahuj´ıc´ı jednu znaˇcku typu cel´e ˇc´ıslo – poˇc´ıtadlo. Vˇzdy, kdyˇz nˇejak´ y pˇrechod pˇrid´a ˇci odebere z p˚ uvodn´ıho m´ısta znaˇcku, mus´ı tak´e zv´ yˇsit resp. sn´ıˇzit poˇc´ıtadlo. Znaˇcky v p˚ uvodn´ım m´ıstˇe tak mohou b´ yt na danou vlastnost ˇci jej´ı negaci otestov´any jedna po druh´e pˇrechodem, u kter´eho se pomoc´ı poˇc´ıtadla zajist´ı, ˇze se provede pˇresnˇe tolikr´at, kolik je v dan´em m´ıstˇe znaˇcek. Toto ˇreˇsen´ı je samozˇrejmˇe velmi neohraban´e a komplikuje model pˇrid´an´ım mnoha m´ıst a pˇrechod˚ u, ˇc´ımˇz se sniˇzuje pˇrehlednost a t´ım i v´ yznam pouˇzit´ı modelu. Druh´ y vzor se naz´ yv´a Barven´ a inhibiˇcn´ı hrana a je mnohem vhodnˇejˇs´ı, protoˇze umoˇzn ˇuje otestovat m´ısto pˇr´ımo na nepˇr´ıtomnost znaˇcky s danou hodnotou ˇci vlastnost´ı. Principem je agregov´an´ı znaˇcek do jedn´e, kter´ a je typu seznam. Tento seznam pak m˚ uˇze b´ yt otestov´an na nepˇr´ıtomnost znaˇcky pomoc´ı funkce inskripˇcn´ıho jazyka ve str´ aˇzi pˇrechodu. Aplikaci vzoru Barven´a inhibiˇcn´ı hrana na diskutovan´ y pˇr´ıklad ukazuje obr´ azek 2.7. Tento n´avrhov´ y vzor na prvn´ı pohled zcela uspokojivˇe ˇreˇs´ı zadan´ y probl´em. Nev´ yhodou vˇsak je, ˇze pokud chceme testovat nepˇr´ıtomnost znaˇcky s nˇejakou hodnotou v dan´em m´ıstˇe, mus´ı toto m´ısto obsahovat pr´ avˇe jednu znaˇcku typu seznam. To znamen´ a, ˇze pro kaˇzd´e z´ısk´an´ı jak´ekoliv znaˇcky mus´ıme pouˇz´ıvat funkci ve str´ aˇzi pˇrechodu, pˇriˇcemˇz z´ısk´ an´ı n´ahodn´e znaˇcky je v tomto pˇr´ıpadˇe paradoxnˇe obt´ıˇznˇejˇs´ı modelovat neˇz z´ısk´ an´ı nˇejak´e konkr´etn´ı znaˇcky. Pˇri n´avrhu inteligentn´ıch syst´em˚ u (a v´ yvoji zaloˇzen´em na modelov´ an´ı obecnˇe) se ˇcasto st´av´a, ˇze specifikace nejsou dopˇredu jasnˇe dan´e a vyv´ıjej´ı se bˇehem modelovac´ıho procesu, stejnˇe jako samotn´ y model. V tomto pˇr´ıpadˇe je tedy pomˇernˇe tˇeˇzk´e a omezuj´ıc´ı dopˇredu urˇcit, zda bude v dan´em m´ıstˇe potˇreba testovat nepˇr´ıtomnost znaˇcky s urˇcitou hodnotou.
14
Obr´azek 2.7: Aplikace vzoru Barven´ a inhibiˇcn´ı hrana
Jin´ ymi slovy, v extr´emn´ım pˇr´ıpadˇe by se mˇel tento vzor pouˇz´ıvat ve vˇsech pˇr´ıpadech, kdy nen´ı dopˇredu zcela zˇrejm´e, ˇze v m´ıstˇe bude vˇzdy obsaˇzena pr´ avˇe jedna znaˇcka.
2.4.2
ˇ sen´ı v jazyku PNtalk Reˇ
Vzhledem k tomu, ˇze c´ılem PNtalku je podpora pro prototypov´ an´ı a v´ yvoj zaloˇzen´ y na modelov´an´ı, nen´ı ˇreˇsen´ı ve stylu barven´ ych Petriho s´ıt´ı plnˇe uspokojiv´e. Proto jsem se snaˇzil naj´ıt moˇzn´a rozˇs´ıˇren´ı jazyka, kter´ a by umoˇzn ˇovala komfortn´ı ˇreˇsen´ı tˇechto situac´ı. D˚ uleˇzit´ ym poˇzadavkem na rozˇs´ıˇren´ı bylo, aby mˇelo co nejmenˇs´ı vliv na zbytek jazyka a bylo snadn´e pro implementaci. V optim´ aln´ım pˇr´ıpadˇe by mˇelo b´ yt moˇzn´e rozˇs´ıˇren´ı transformovat na existuj´ıc´ı jazykov´e struktury, takˇze formalismus OOPN by nebylo potˇreba v˚ ubec mˇenit. Uˇ zit´ı kolekc´ı pro ukl´ ad´ an´ı znaˇ cek Prvn´ı moˇzn´e ˇreˇsen´ı pˇredstavuje pˇr´ım´ a adaptace v´ yˇse zm´ınˇen´eho n´ avrhov´eho vzoru Barven´ a inhibiˇcn´ı hrana. Jako inskripˇcn´ı jazyk PNtalku je pouˇzit jazyk Smalltalk, pro agregaci znaˇcek v m´ıstech je tedy moˇzn´e vyuˇz´ıt koncept Smalltalkovsk´ ych kolekc´ı. Kolekce nab´ızej´ı pˇr´ıstup ke sv´ ym prvk˚ um na vyˇsˇs´ı u ´rovni neˇz seznamy inskripˇcn´ıho jazyka barven´ ych Petriho s´ıt´ı – poskytuj´ı celou ˇradu metod pro testov´ an´ı a zpˇr´ıstupnˇen´ı sv´eho obsahu. Pˇr´ıklad pouˇzit´ı kolekce Bag pro ˇreˇsen´ı diskutovan´eho pˇr´ıkladu demonstruje obr´ azek 2.8. Toto ˇreˇsen´ı n´as samozˇrejmˇe nezbavuje nutnosti pouˇzit´ı speci´ aln´ı agregaˇcn´ı znaˇcky pro test nepˇr´ıtomnosti znaˇcky s urˇcitou hodnotou v dan´em m´ıstˇe, ale je jiˇz v jazyku PNtalk dostupn´e. V optim´aln´ım pˇr´ıpadˇe by tedy mˇelo b´ yt moˇzn´e pˇrev´est navrˇzen´e rozˇs´ıˇren´ı na tento vzor. Zaveden´ı priorit pˇ rechod˚ u Dalˇs´ı moˇznost´ı, jak se s probl´emem testov´ an´ı nepˇr´ıtomnosti znaˇcky s urˇcitou vlastnost´ı v dan´em m´ıstˇe vyrovnat, je zav´est do jazyka PNtalk priority pˇrechod˚ u. U P/T Petriho s´ıt´ı m´a rozˇs´ıˇren´ı formalismu o koncept priorit pˇrechod˚ u stejn´ y efekt jako zaveden´ı inhibiˇcn´ıch hran – stanou se v´ ypoˇcetnˇe u ´pln´ ymi.
15
Obr´azek 2.8: Adaptace n´avrhov´eho vzoru Barven´ a inhibiˇcn´ı hrana do jazyka PNtalk
Priority pˇrechod˚ u tak´e ˇreˇs´ı probl´em testov´ an´ı nepˇr´ıtomnosti znaˇcky s danou vlastnost´ı v m´ıstˇe – umoˇzn ˇuj´ı totiˇz pˇr´ımoˇcarou implementaci konstrukce imperativn´ıch programovac´ıch jazyk˚ u if (podm´ınka) then akce1 else akce2. V pˇr´ıpadˇe, ˇze je podm´ınka splnˇena (alespoˇ n jedna znaˇcka s danou vlastnost´ı je v m´ıstˇe pˇr´ıtomna), provede se pˇrechod, jenˇz m´a ve str´aˇzi test t´eto vlastnosti a kter´emu je pˇriˇrazena vyˇsˇs´ı priorita. V opaˇcn´em pˇr´ıpadˇe se provede pˇrechod s pr´azdnou str´ aˇz´ı, jemuˇz je pˇriˇrazena priorita niˇzˇs´ı. Situaci zn´ azorˇ nuje obr´azek 2.9 (pˇrechod s vyˇsˇs´ı prioritou je oznaˇcen tuˇcn´ ym okrajem).
Obr´azek 2.9: PNtalk rozˇs´ıˇren´ y o priority pˇrechod˚ u (pˇrechod s vyˇsˇs´ı prioritou je oznaˇcen tuˇcn´ ym okrajem) Tento pˇr´ıstup m´a vˇsak nˇekolik nev´ yhod. Podle definice dynamiky OOPN zaveden´e v [Jan98] je v kaˇzd´em kroku simulace obecnˇe nˇekolik provediteln´ ych ud´ alost´ı (kter´e pˇredstavuj´ı podmnoˇzinu mnoˇziny vˇsech ud´ alost´ı), z nichˇz se jedna vybere nedeterministicky a ta je provedena. Hlavn´ı probl´em spoˇc´ıv´ a v tom, ˇze priority pˇrechod˚ u definuj´ı ˇc´ asteˇcn´e uspoˇr´ad´an´ı na cel´e t´eto mnoˇzinˇe, coˇz znamen´ a, ˇze se priority neaplikuj´ı pouze pro uspoˇr´ad´an´ı pˇrechod˚ u, kter´e jsme zam´ yˇsleli uspoˇr´ adat, ale na vˇsechny v dan´em okamˇziku provediteln´e pˇrechody v modelu. Nejjednoduˇsˇs´ı implementaci priorit pˇrechod˚ u pˇredstavuje lexikografick´e uspoˇr´ ad´ an´ı, ale to z´aroveˇ n pˇredstavuje nejhorˇs´ı variantu uspoˇr´ ad´ an´ı – vˇsechny pˇrechody se stejnou prioritou
16
by se musely jmenovat stejnˇe, jinak by doˇslo k jejich prov´ adˇen´ı v z´ avislosti na uspoˇr´ ad´ an´ı jejich jmen. T´ımto zp˚ usobem by tak doˇslo k pˇr´ım´emu rozporu s p˚ uvodn´ım urˇcen´ım Petriho s´ıt´ı – modelov´an´ı paraleln´ıch proces˚ u a nedeterministick´ ych voleb. Rozˇ s´ıˇ ren´ı jazyka o negativn´ı predik´ aty Jinou moˇznost´ı je rozˇs´ıˇrit jazyk o nˇejakou formu inhibiˇcn´ıch hran. Jak bylo uk´ az´ ano v ˇc´ asti popisuj´ıc´ı ˇreˇsen´ı u barven´ ych Petriho s´ıt´ı, obdoba klasick´ ych inhibiˇcn´ıch hran ve stylu P/T Petriho s´ıt´ı nevede k dobr´ ym v´ ysledk˚ um. Proto jsem navrhl koncept negativn´ıch predik´ at˚ u. Negativn´ı predik´at vych´az´ı z koncepce synchronn´ıho portu, z hlediska syntaktick´eho je s n´ım t´emˇeˇr shodn´ y. Hlavn´ı rozd´ıl spoˇc´ıv´ a v s´emantice – synchronn´ı port je provediteln´ y, pokud existuje nˇejak´e nav´az´an´ı voln´ ych promˇenn´ ych v hranov´ ych v´ yrazech vstupn´ıch hran tak, ˇze toto nav´az´an´ı splˇ nuje podm´ınky definovan´e str´ aˇz´ı portu. Negativn´ı predik´ aty funguj´ı obr´acenˇe – jsou provediteln´e v pˇr´ıpadˇe, ˇze ˇz´ adn´e takov´e nav´ az´ an´ı nem˚ uˇze b´ yt nalezeno. Negativn´ı predik´aty nemohou m´ıt postrann´ı efekty, protoˇze tato operace by ned´ avala smysl – aby byl negativn´ı predik´ at provediteln´ y, nˇekter´ a z promˇenn´ ych nemohla b´ yt nav´az´ana. To znamen´a, ˇze negativn´ı predik´ aty mohou b´ yt spojeny s m´ısty pouze testovac´ımi hranami. Pouˇzit´ı negativn´ıho predik´ atu pro ˇreˇsen´ı naˇseho pˇr´ıkladu ukazuje obr´ azek 2.10 (negativn´ı predik´at je oznaˇcen dvojitou ˇc´ arou pro odliˇsen´ı od synchronn´ıch port˚ u).
Obr´azek 2.10: Uk´azka pouˇzit´ı negativn´ıho predik´ atu v PNtalku (negativn´ı predik´ at je oznaˇcen dvojitou ˇc´arou) Je tedy zˇrejm´e, ˇze negativn´ı predik´ aty ˇreˇs´ı probl´em testov´ an´ı nepˇr´ıtomnosti znaˇcky s urˇcitou vlastnost´ı v dan´em m´ıstˇe. Z hlediska syntaxe jazyka PNtalk jsou totoˇzn´e se synchronn´ımi porty aˇz na dva rozd´ıly: V grafick´e podobˇe jazyka jsou zn´ azornˇeny obd´eln´ıkem s dvojit´ ym okrajem a s m´ısty mohou b´ yt spojeny pouze pomoc´ı testovac´ıch hran. Syntax upraven´e textov´e podoby jazyka je form´ alnˇe definov´ ana rozˇs´ıˇrenou Backus-Naurovou formou v pˇr´ıloze A. Pouˇzit´ı negativn´ıch predik´ at˚ u je moˇzn´e vˇzdy pˇrev´est na pˇr´ıpad uˇzit´ı agregace znaˇcek v m´ıstech do kolekc´ı prezentovan´ y v´ yˇse. Hlavn´ı myˇslenku tohoto pˇrevodu ukazuje n´asleduj´ıc´ı podkapitola.
2.4.3
Pˇ revod negativn´ıch predik´ at˚ u na existuj´ıc´ı jazykov´ e struktury
V t´eto ˇc´asti bude uk´az´an pˇrevod v´ yrazu str´ aˇze a hranov´ ych v´ yraz˚ u negativn´ıho predik´ atu na struktury jiˇz dostupn´e v jazyku PNtalk. Pˇrevod pˇredpokl´ ad´ a, ˇze zbytek s´ıtˇe jiˇz byl upraven tak, ˇze v m´ıstech, kter´a jsou s negativn´ım predik´ atem spojena, jsou znaˇcky agregov´any
17
do Smalltalkovsk´e kolekce Bag. Obdobnˇe jako negativn´ı predik´ aty je samozˇrejmˇe potˇreba upravit str´aˇze a hranov´e v´ yrazy pˇrechod˚ u a synchronn´ıch port˚ u, kter´e pracuj´ı s tˇemito m´ısty. Postup jejich pˇrevodu je vˇsak prakticky totoˇzn´ y jako negativn´ıch predik´ at˚ u, proto jej zde nebudu opakovat. Vlastn´ı pˇrevod se provede pomoc´ı n´ asleduj´ıc´ıho algoritmu: Pˇredpokl´adejme, ˇze ve vˇsech m´ıstech, kter´e jsou s dan´ ym negativn´ım predik´ atem spojeny hranou (negativn´ı predik´ aty mohou b´ yt s m´ısty spojeny pouze testovac´ımi hranami, proto je v tomto algoritmu nebudu rozliˇsovat), jsme nahradili bˇeˇzn´e vkl´ ad´ an´ı znaˇcek agregac´ı do Smalltalkovsk´e kolekce Bag. Nejprve provedeme pˇrejmenov´ an´ı promˇenn´ ych v hranov´ ych v´ yrazech: pokud se nˇekter´a voln´a promˇenn´a (napˇr. p) vyskytuje v hranov´em v´ yrazu dvou r˚ uzn´ ych vstupn´ıch hran dan´eho predik´atu, pˇrejmenuj´ı se vˇsechny jej´ı v´ yskyty v jednom z nich tak, aby tato nov´a promˇenn´a mˇela unik´ atn´ı n´ azev v r´ amci cel´eho predik´ atu (napˇr. p2). Do v´ yrazu str´aˇze predik´atu se pˇrid´ a podm´ınka rovnosti obou promˇenn´ ych (napˇr. p = p2). Pro kaˇzdou hranu z mnoˇziny vstupn´ıch hran predik´ atu provedeme n´ asleduj´ıc´ı u ´pravy: – Nahrad´ıme jej´ı hranov´ y v´ yraz jednou novou promˇennou s unik´ atn´ım n´ azvem v r´amci cel´eho predik´atu, do kter´e se nav´ aˇze kolekce, kter´ a v dan´em m´ıstˇe agreguje znaˇcky (napˇr. xBag). – Pro kaˇzd´ y term p˚ uvodn´ıho hranov´eho v´ yrazu, specifikuj´ıc´ı ˇcetnost znaˇcky vˇetˇs´ı neˇz jedna (napˇr. c’m), pˇrid´ ame do str´ aˇze predik´ atu v´ yraz tvaru ((xBag occurrencesOf: m) >= c). – V pˇr´ıpadˇe, ˇze m m´a tvar seznamu, vytvoˇr´ıme pro nˇej novou promˇennou (napˇr. lm) a pro kaˇzd´ y jeho prvek, kter´ y je konstantou (napˇr. 11) do str´ aˇze podm´ınku tvaru ( (lm at: pos) = 11), kde pos je ˇc´ıslo odpov´ıdaj´ıc´ı pozici, na kter´e se konstanta x v seznamu m nach´ az´ı. Pokud je prvkem seznamu promˇenn´ a, kter´ a je pouˇzita nˇekde ve v´ yrazu str´ aˇze, nahrad´ı se na vˇsech takov´ ychto m´ıstech v´ yrazem (lm at: pos), kde pos je ˇc´ıslo odpov´ıdaj´ıc´ı pozici, na kter´e se promˇenn´ a v seznamu m nach´az´ı. – Pro kaˇzd´ y term m vloˇz´ıme str´ aˇz predik´ atu do n´ asleduj´ıc´ı konstrukce: (xBag anySatisfy: [: m | <str´ aˇz predik´ atu> ]) Nakonec konjunkci ve str´aˇzi predik´ atu uprav´ıme tak, aby odpov´ıdala syntaxi v´ yrazu jazyka Smalltalk, tedy napˇr. str´ aˇz tvaru x > 5. y testWith: x. uprav´ıme na (x > 5) & (y testWith: x). V´ ysledn´ y v´ yraz ve str´aˇzi je konstrukc´ı inskripˇcn´ıho jazyka Smalltalk a vrac´ı hodnotu true pr´avˇe v tˇech pˇr´ıpadech, kdy byla str´ aˇz p˚ uvodn´ıho predik´ atu splnˇena. Pro splnˇen´ı s´emantiky negativn´ıho predik´ atu je tedy nutn´e tuto hodnotu znegovat zasl´an´ım zpr´avy not. Negativn´ı predik´at se tak stal synchronn´ım portem, kter´ y m´ a ve str´ aˇzi jeden v´ yraz inskripˇcn´ıho jazyka, a kter´ y je provediteln´ y pr´ avˇe v tˇech pˇr´ıpadech, kdy byl provediteln´ y p˚ uvodn´ı negativn´ı predik´at. Pˇr´ıklad pˇrevodu ukazuje obr´ azek 2.11.
18
Obr´azek 2.11: Pˇr´ıklad pˇrevodu negativn´ıho predik´ atu na synchronn´ı port pracuj´ıc´ı s kolekcemi
2.4.4
Negativn´ı predik´ aty a logick´ e programov´ an´ı
Koncept negativn´ıch predik´at˚ u byl inspirov´ an implementac´ı predik´ atu not(P) v logick´ ych programovac´ıch jazyc´ıch, napˇr. v jazyce Prolog. Tento pˇr´ıstup b´ yv´ a naz´ yv´ an negace jako selh´ an´ı (negation as failure) [Cla87]. Predik´ at not(P ) selˇze ve vˇsech pˇr´ıpadech, ve kter´ ych by predik´at P uspˇel. Hlavn´ı v´ yhodou tohoto pˇr´ıstupu je jednoduch´ a a pomˇernˇe efektivn´ı implementace. V logick´em programov´an´ı tento pˇr´ıstup vyvolal mnoho diskuz´ı, a to ze dvou hlavn´ıch d˚ uvod˚ u. Prvn´ım z nich je pˇredpoklad uzavˇrenosti svˇeta (closed world assumption), kter´ y je touto implementac´ı implikov´an. Jeho podstata spoˇc´ıv´ a v tom, ˇze cokoliv, o ˇcem nen´ı zn´amo, ˇze je pravdiv´e (resp. je moˇzn´e to odvodit ze zn´ am´ ych fakt˚ u), je povaˇzov´ ano za nepravdiv´e. Tento probl´em souvis´ı zejm´ena s pouˇzit´ım logick´ ych jazyk˚ u pro reprezentaci znalost´ı. V PNtalku negativn´ı predik´ aty jednoduˇse ˇr´ıkaj´ı, ˇze ˇz´ adn´ a znaˇcka v dan´em m´ıstˇe nesplˇ nuje podm´ınku definovanou str´ aˇz´ı tohoto predik´ atu. Druh´ y probl´em spoˇc´ıv´a v tom, ˇze predik´ at not(P ) implementovan´ y pomoc´ı negace jako selh´an´ı v Prologu neodpov´ıd´a predik´ atu ¬P v klasick´e predik´ atov´e logice. V nˇekter´ ych pˇr´ıpadech m˚ uˇze totiˇz d´avat neoˇcek´ avan´e v´ ysledky. Uk´ aˇzu klasick´ y pˇr´ıklad. Mˇejme datab´ azi v n´asleduj´ıc´ım tvaru: dobryStudent(X) :- chytry(X), not(liny(X)). liny(jirka). chytry(honza). Na dotaz dobryStudent(X) obdrˇz´ıme spr´ avnou odpovˇed’ X = honza. Nyn´ı uprav´ıme pravidlo dobryStudent na n´asleduj´ıc´ı tvar: dobryStudent(X) :- not(liny(X)), chytry(X). V pˇr´ıpadˇe, ˇze by not(P) fungovalo jako ¬P v predik´ atov´e logice, mˇeli bychom obdrˇzet ’ ’ stejnou odpovˇed jako pˇred u ´pravou. Odpovˇed vˇsak bude fail – predik´ at selˇze. To je d´ ano t´ım, ˇze v Prologu je predik´at not(P) implementov´ an pomoc´ı oper´ atoru ˇrezu, konkr´etnˇe: not(G) :- G, !, fail. not(G). 19
Po nav´az´an´ı promˇenn´e X na term jirka nen´ı moˇzn´e se kv˚ uli oper´ atoru ˇrezu vr´ atit a vyzkouˇset jin´e nav´az´an´ı (na term honza). Obdobnˇe je tomu v pˇr´ıpadˇe PNtalku, jak ilustruje obr´azek 2.12. Zat´ımco pˇrechod dobryStudent1 bude provediteln´ y, pˇrechod dobryStudent2 nikoliv. Je to d´ano t´ım, ˇze PNtalk se snaˇz´ı nav´ az´ an´ım promˇenn´ ych postupnˇe splnit jednotliv´e v´ yrazy ve str´aˇzi pˇrechodu. Zat´ımco v pˇr´ıpadˇe pˇrechodu dobryStudent1 je negativn´ı predik´at vol´an na jiˇz nav´azanou promˇennou a v d˚ usledku toho nenajde ˇz´ adnou moˇznou unifikaci a uspˇeje, v pˇr´ıpadˇe dobryStudent2 je vol´ an s volnou promˇennou, do kter´e je schopen nav´azat term jirka. Synchronn´ı port by tedy byl splnˇen, negativn´ı predik´ at proto splnˇen nen´ı. V d˚ usledku toho nen´ı splnˇena cel´ a str´ aˇz pˇrechodu. Pˇri pouˇz´ıv´ an´ı negativn´ıch predik´at˚ u je tedy potˇreba vˇenovat pozornost tomu, zda budou vol´ any na jiˇz nav´ azan´e nebo voln´e promˇenn´e.
Obr´azek 2.12: Demonstrace rozd´ıln´eho chov´ an´ı pˇrechod˚ u v z´ avislosti na poˇrad´ı v´ yraz˚ u ve str´aˇzi pˇri pouˇzit´ı negativn´ıch predik´ at˚ u. Zat´ımco pˇrechod dobryStudent1 bude provediteln´ y, pˇrechod dobryStudent2 nikoliv
20
Kapitola 3
Agenti a multiagentn´ı syst´ emy Problematiku ˇreˇsenou v komunitˇe zab´ yvaj´ıc´ı se oblast´ı multiagentn´ıch syst´em˚ u je moˇzn´e rozdˇelit do dvou hlavn´ıch kategori´ı: • Hled´an´ı vhodn´e vnitˇrn´ı struktury jednotliv´ych agent˚ u – tedy jak navrhnout ˇr´ıd´ıc´ı apar´at uvnitˇr agenta tak, aby navenek vykazoval poˇzadovan´e vlastnosti a chov´ an´ı. Tato oblast m´a bl´ızko k tradiˇcn´ı umˇel´e inteligenci, robotice a teorii ˇr´ızen´ı, ale ˇcerp´ a napˇr´ıklad tak´e z kognitivn´ı psychologie a filozofie akce. • V´ yzkum a n´avrh chov´ an´ı kolekce agent˚ u – zde se agenti povaˇzuj´ı v podstatˇe za ˇcern´e skˇr´ıˇ nky a zkoumaj´ı se jen jejich vnˇejˇs´ı projevy, zejm´ena to, jak ovlivˇ nuj´ı chov´ an´ı ostatn´ıch agent˚ u a cel´eho syst´emu. Pouˇz´ıvaj´ı se pˇr´ıstupy vˇed spoleˇcensk´ ych, matematick´e teorie her, ekonomie, lingvistiky apod. Obˇe oblasti spolu samozˇrejmˇe u ´zce souvis´ı a vz´ ajemnˇe se ovlivˇ nuj´ı. V´ yzkum prezentovan´ y v t´eto pr´aci spad´a do prvn´ı kategorie. Jednotliv´e ˇc´ asti t´eto kapitoly tak maj´ı za c´ıl nejprve uk´azat obecn´e principy n´ avrhu vnitˇrn´ı struktury agenta, zejm´ena pˇr´ıstupy alternativn´ı ke zvolen´e architektuˇre, d´ale pak poskytnout struˇcn´ y pˇrehled a souvislosti s druhou kategori´ı v´ yzkum˚ u, kter´e ovlivnily nˇekter´e aspekty navrˇzen´eho syst´emu. Pojem agenta, jakoˇzto autonomn´ı jednotky schopn´e interakce s ostatn´ımi agenty, prezentovan´ y v u ´vodn´ı kapitole, n´am poslouˇzil pro prvn´ı pˇribl´ıˇzen´ı. Oznaˇcen´ı agent je vˇsak pouˇz´ıv´ano v mnoha souvislostech a v´ yznamech, coˇz je d´ ano zejm´ena rozmanitost´ı vˇedn´ıch discipl´ın, v nichˇz se s t´ımto pojmem setk´ av´ ame. Nˇekter´e z tˇechto discipl´ın v˚ ubec nesouvis´ı s poˇc´ıtaˇcovou vˇedou. To je pˇr´ıˇcinou, proˇc dosud neexistuje ˇz´ adn´ a vˇseobecnˇe uzn´ avan´ a de’ finice. Jako pˇr´ıklad uved me mimoˇr´ adnˇe u ´spˇeˇsnou knihu [RN02], kterou mnoz´ı povaˇzuj´ı za z´akladn´ı d´ılo v oblasti umˇel´e inteligence. Zde je agent pouˇz´ıv´ an jako centr´ aln´ı pojem umˇel´e inteligence, resp. umˇel´a inteligence je ch´ ap´ ana jako vˇeda o vytv´ aˇren´ı inteligentn´ıch agent˚ u. Protoˇze pˇr´ıstupy pouˇz´ıvan´e v umˇel´e inteligenci jsou velmi r˚ uznorod´e, agent je ch´ apan jako cokoliv, co vn´ım´a sv´e prostˇred´ı pomoc´ı senzor˚ u a ovlivˇ nuje jej pomoc´ı efektor˚ u. Tato definice je vˇsak pro potˇreby t´eto pr´ ace pˇr´ıliˇs ˇsirok´ a. V n´ asleduj´ıc´ı ˇc´ asti se proto pokus´ım vymezit tento pojem spoleˇcnˇe s pojmem multiagentn´ıho syst´emu tak, jak jej budu v t´eto pr´aci nad´ale uˇz´ıvat.
21
3.1
Z´ akladn´ı pojmy
3.1.1
Inteligentn´ı agent
Pojmem agent se budu nad´ale odkazovat na syst´em (obvykle softwarov´ y nebo hardwarov´ y), kter´ y se nach´az´ı v nˇejak´em prostˇred´ı a vykazuje v nˇem tyto z´ akladn´ı vlastnosti: • autonomnost – agent m´a sv´e dlouhodob´e c´ıle, kter´e sleduje, a snaˇz´ı se dos´ ahnout tˇechto c´ıl˚ u bez trval´eho dozoru ˇclovˇeka nebo jin´eho agenta, • reaktivita – agent vn´ım´a zmˇeny prostˇred´ı, ve kter´em se pohybuje, a je schopen na nˇe adekv´atnˇe reagovat, • iniciativa – agent s´am iniciativnˇe vykon´ av´ a akce, kter´ ymi mˇen´ı sv´e okol´ı tak, aby se pˇribl´ıˇzil sv´ ym c´ıl˚ um, • soci´ alnost – agent um´ı komunikovat s ostatn´ımi agenty. Z tˇechto vlastnost´ı vypl´ yv´a, ˇze agent navenek vykazuje urˇcitou d´ avku inteligence, proto ˇ b´ yv´a tak´e oznaˇcov´an jako inteligentn´ı agent. Casto se tak´e setk´ av´ ame s pojmem racion´ aln´ı agent, racionalita v tomto pˇr´ıpadˇe znamen´ a, ˇze agent vykon´ av´ a pouze akce, kter´e v kontextu jeho prostˇred´ı a situace d´avaj´ı smysl, tedy mu mohou pomoci zajistit splnˇen´ı jeho c´ıl˚ u. Podrobnˇejˇs´ı u ´vahy na toto t´ema je moˇzno nal´ezt v ˇradˇe publikac´ı, napˇr´ıklad v [WJ95] nebo [Woo02].
3.1.2
Multiagentn´ı syst´ em
Obecn´y syst´em S je definov´an jako dvojice S = (U, R), kde U znaˇc´ı mnoˇzinu vˇsech prvk˚ u syst´emu a R mnoˇzinu vˇsech propojen´ı mezi prvky tohoto syst´emu. V souladu s touto definic´ı ch´ apeme multiagentn´ı syst´em jako syst´em, ve kter´em se vyskytuj´ı prvky aktivn´ı – agenti a pasivn´ı – neagentn´ı, kter´e spolu dohromady vytv´aˇrej´ı prostˇred´ı, ve kter´em se agenti nach´ azej´ı. Aby byl syst´em multiagentn´ı, mˇeli by se v nˇem nach´azet alespoˇ n dva agenti. Ti maj´ı sv´e c´ıle a protoˇze jsou obdaˇreni schopnost´ı iniciativy, aktivnˇe p˚ usob´ı na sv´e okol´ı tak, aby se stav syst´emu pˇribl´ıˇzil takov´emu, jak´ y po nich jejich uˇzivatel´e poˇzaduj´ı. Tyto akce mohou prob´ıhat souˇcasnˇe a kaˇzd´ a z nich vyˇzaduje jist´ y ˇcas. Je tedy moˇzn´e, ˇze akce agenta skonˇc´ı ne´ uspˇechem pˇresto, ˇze podm´ınky v dobˇe rozhodnut´ı o akci zaruˇcovaly u ´spˇech – podm´ınky se bˇehem vykon´ av´ an´ı zmˇenily.
3.2
Architektury agent˚ u
K n´avrhu vnitˇrn´ı struktury agenta lze pˇristoupit nˇekolika zp˚ usoby. Tradiˇcn´ım pˇr´ıstupem, vych´azej´ıc´ım z p˚ uvodn´ıch myˇslenek umˇel´e inteligence, je vybavit agenta symbolickou reprezentac´ı svˇeta, vˇcetnˇe ostatn´ıch agent˚ u a jeho sam´eho (napˇr´ıklad ve formˇe predik´ atov´e logiky prvn´ıho ˇr´adu) a apar´ atem pro odvozov´ an´ı nov´ ych poznatk˚ u. Takov´ y agent pak uvaˇzuje o sv´em prostˇred´ı, sv´ ych c´ılech a schopnostech. Na z´ akladˇe tˇechto u ´vah pak prov´ ad´ı akce, o kter´ ych vˇeˇr´ı, ˇze vedou ke splnˇen´ı jeho c´ıl˚ u, pokud jsou tyto c´ıle dosaˇziteln´e. Hlavn´ımi probl´emy tohoto pˇr´ıstupu jsou celkov´ a obt´ıˇznost tvorby takov´eho syst´emu a ˇcasov´ a sloˇzitost pr´ace se symbolickou reprezentac´ı. Agenti s touto vnitˇrn´ı architekturou b´ yvaj´ı naz´ yv´ ani uvaˇzuj´ıc´ı nebo tak´e rozv´ aˇzn´ı agenti (deliberative agents).
22
V 80. letech minul´eho stolet´ı vl´ adlo mezi vˇedci zab´ yvaj´ıc´ımi se umˇelou inteligenc´ı vˇseobecn´e zklam´an´ı z p˚ uvodn´ıch pˇr´ıliˇs optimistick´ ych viz´ı schopnost´ı syst´em˚ u se symbolickou reprezentac´ı. Jako odpovˇed’ vznikl proud robotiky, kter´ y prosazoval myˇslenku, ˇze inteligentn´ı chov´an´ı vznik´a jen v oˇc´ıch pozorovatele, pˇriˇcemˇz uvnitˇr syst´emu ˇz´ adn´ a symbolick´a reprezentace svˇeta b´ yt nemus´ı. V´ ysledn´e chov´ an´ı je pak pouze kombinac´ı pevnˇe dan´ ych bezprostˇredn´ıch reakc´ı na ud´ alosti, kter´e se v okol´ı vyskytly. Tento pˇr´ıstup se stal z´akladem pro takzvan´e reaktivn´ı agenty. Kombinac´ı obou tˇechto dvou moˇznost´ı dost´ av´ ame hybridn´ıho agenta. Obvykle se jedn´ a o vrstvenou architekturu, ve kter´e jednoduch´e akce vyˇzaduj´ıc´ı rychlou odezvu zpracov´ av´ a reaktivn´ı vrstva, zat´ımco komplexn´ı u ´lohy a pl´ anov´ an´ı obstar´ av´ a vrstva vyuˇz´ıvaj´ıc´ı symbolickou reprezentaci. N´asleduj´ıc´ı tˇri podkapitoly pˇredstavuj´ı jednotliv´e pˇr´ıstupy podrobnˇeji.
3.2.1
Reaktivn´ı agent
Jak jiˇz bylo ˇreˇceno, reaktivn´ı agent neobsahuje ˇz´ adnou symbolickou reprezentaci svˇeta. Nejjednoduˇsˇs´ım pˇr´ıkladem takov´eho agenta je ˇcistˇe reaktivn´ı agent. Ten neobsahuje naprosto ˇz´adnou reprezentaci sv´eho vnitˇrn´ıho stavu. Pˇr´ıkladem takov´eho agenta [Kel94] m˚ uˇze b´ yt mechanick´a beruˇska – dˇetsk´a hraˇcka, kter´ a m´ a za u ´kol jezdit po ploˇse stolu a nespadnout z nˇej. Beruˇska je v pˇredn´ı ˇc´asti vybavena dvˇema tykadly (senzory), kter´e jsou pˇr´ımo napojeny na pˇredn´ı koleˇcko (efektor). Pokud beruˇska naraz´ı na hranu stolu, jedno z jej´ıch tykadel se sn´ıˇz´ı, coˇz vede k otoˇcen´ı koleˇcka a t´ım zmˇenˇe smˇeru. Beruˇska tak vykazuje dostateˇcnˇe inteligentn´ı chov´an´ı, aby mohla slouˇzit ke sv´emu u ´ˇcelu. Charakteristickou vlastnost´ı reaktivn´ıch agent˚ u je tedy pomˇernˇe pˇr´ım´e mapov´ an´ı vjemu na akci (resp. sekvenci akc´ı), kter´e se d´ a u ˇcistˇe reaktivn´ıho agenta vyj´ adˇrit funkc´ı chov´an´ı: akce : P → A kde P je mnoˇzina vjem˚ u, kter´e agent rozezn´ av´ a a A je mnoˇzina akc´ı, kter´e je agent schopen vykonat. Vjemy, kter´e je agent schopen rozpoznat jsou urˇceny funkc´ı: vjem : E → P ˇ e reaktivn´ı agent kde E pˇredstavuje mnoˇzinu vˇsech moˇzn´ ych stav˚ u agentova prostˇred´ı. Cistˇ tedy m˚ uˇze b´ yt pops´an jako ˇctveˇrice P RA = (P, A, vjem, akce). Vliv agenta na prostˇred´ı popisuje funkce: vliv : A × E → E ˇ e reaktivn´ı agent je schopen vykon´ Cistˇ avat pouze velice omezen´e mnoˇzstv´ı u ´kol˚ u. Pˇr´ım´e mapov´an´ı vjemu na akci totiˇz umoˇzn ˇuje prov´ adˇet jen jednoduch´e pˇr´ımoˇcar´e akce. Tento probl´em lze ˇc´asteˇcnˇe odstranit zaveden´ım modelu chov´ an´ı. Agent st´ ale pouze automaticky prov´ad´ı akce, kter´e jsou reakc´ı na podnˇety pˇrijat´e z prostˇred´ı, a o kter´ ych nijak neuvaˇzuje, avˇsak tyto akce jsou nˇejak´ ym zp˚ usobem seˇrazeny do logick´eho sledu, napˇr´ıklad pomoc´ı koneˇcn´eho automatu. Form´alnˇe, kaˇzd´ y pˇrijat´ y vjem ovlivˇ nuje agent˚ uv vnitˇrn´ı stav, coˇz vyjadˇruje funkce: stav : P × I → I kde I je mnoˇzina vnitˇrn´ıch stav˚ u agenta. Na z´ akladˇe vnitˇrn´ıho stavu a pˇrijat´eho vjemu pak agent prov´ad´ı akce, coˇz vyjadˇruje upraven´ a funkce akce: akce2 : P × I → A
23
Reaktivn´ı agent je pak ˇsestice RA = (P, A, I, vjem, stav, akce2). Automaty ˇr´ıd´ıc´ı agenta se vˇsak pˇri zaveden´ı jiˇz nˇekolika m´ alo sloˇzitˇejˇs´ıch vzor˚ u chov´ an´ı st´avaj´ı velmi rychle rozs´ahl´ ymi a tedy nepˇrehledn´ ymi. Dalˇs´ı probl´em nast´ av´ a, pokud po takov´em agentovi poˇzadujeme, aby byl schopen prov´ adˇet v´ıce akc´ı najednou. Proto se obvykle u netrivi´aln´ıch agent˚ u zav´ad´ı takzvan´ a vrstven´ a architektura. Jednotliv´e vrstvy se staraj´ı o r˚ uzn´e vzory chov´an´ı a obvykle maj´ı moˇznost se nˇejak´ ym zp˚ usobem vz´ ajemnˇe ovlivˇ novat. ’ Tyto vrstvy b´ yvaj´ı doplnˇeny mechanismem v´ybˇeru akce, at uˇz pomoc´ı speci´ aln´ı jednotky v´ybˇeru akce nebo vestavˇen´ ych priorit vrstev. Reaktivn´ı architektury b´ yvaj´ı podle tohoto principu vrstev naz´ yv´ any jako pˇr´ıstup ke tvorbˇe agenta zdola nahoru“, protoˇze doch´ az´ı k dekompozici probl´emu n´ avrhu agenta podle ” jednotliv´ ych poˇzadovan´ ych schopnost´ı, nam´ısto klasick´e dekompozice na funkˇcn´ı jednotky. V´ yhodou tohoto pˇr´ıstupu je zejm´ena to, ˇze je moˇzn´e pomˇernˇe snadno implementovat nˇekter´e funkce agenta (napˇr´ıklad pouze pohyb), otestovat je a pozdˇeji v pˇr´ıpadˇe potˇreby doplˇ novat dalˇs´ı funkˇcnost pˇrid´av´an´ım dalˇs´ıch vrstev pro poˇzadovan´e vzory chov´ an´ı. Klasick´ y pˇr´ıklad takov´eto vrstven´e architektury pˇredstavuje subsumpˇcn´ı architektura [Bro86], navrˇzen´a v 80. letech minul´eho stolet´ı prof. Brooksem, p˚ usob´ıc´ım na MIT. Brooks patˇril k hlavn´ım kritik˚ um klasick´eho pˇr´ıstupu k umˇel´e inteligenci za pouˇzit´ı symbolick´e reprezentace. Inspirac´ı pˇri tvorbˇe tohoto modelu pro nˇej bylo chov´ an´ı niˇzˇs´ıch ˇzivoˇcich˚ u. Jeho architektura obsahuje vrstvy, pˇriˇcemˇz kaˇzd´ a vrstva se skl´ ad´ a z modul˚ u. Chov´ an´ı kaˇzd´eho z modul˚ u je ˇr´ızeno pomoc´ı koneˇcn´eho automatu. Nˇekter´e z modul˚ u jsou pˇripojeny pˇr´ımo na senzory, dalˇs´ı pak na aktu´atory. Jednotliv´e moduly maj´ı definovan´e vstupy a v´ ystupy, kter´e jsou vz´ajemnˇe propojeny. Princip pˇripojen´ı dalˇs´ıch vrstev spoˇc´ıv´ a v pˇripojen´ı vstup˚ u a v´ ystup˚ u nˇekter´ ych nov´ ych modul˚ u na existuj´ıc´ı propojen´ı a moˇznost zmˇenit vstup modul˚ u p˚ uvodn´ıch vrstev (potlaˇcen´ı), pˇr´ıpadnˇe blokovat v´ ystup jin´ ych (znehybnˇen´ı). Sch´ema subsumpˇcn´ı architektury pouˇzit´e pro ˇr´ızen´ı mobiln´ıho robota ukazuje obr´ azek 3.1. V tomto pˇr´ıpadˇe obsahuje architektura dvˇe vrstvy, spodn´ı vrstva m´ a za u ´kol vyh´ yb´ an´ı se pˇrek´aˇzk´am, vˇcetnˇe u ´niku od pohybliv´ ych pˇrek´ aˇzek, kter´e robota hon´ı“, zat´ımco horn´ı ” vrstva se star´a o n´ahodn´e proch´azen´ı prostoru.
Obr´azek 3.1: Subsumpˇcn´ı architektura pouˇzit´ a pro ˇr´ızen´ı mobiln´ıho robota Agenti zaloˇzen´ı na reaktivn´ı architektuˇre maj´ı celou ˇradu v´ yhod: jednoduchost, ekonomiˇcnost, robustnost proti poruˇse, atd. Maj´ı vˇsak tak´e celou ˇradu dosud nevyˇreˇsen´ ych probl´em˚ u: 24
• zat´ımco tvorba agent˚ u s nˇekolika m´ alo vrstvami je pomˇernˇe jednoduch´ a, n´ avrh agenta s vˇetˇs´ım poˇctem vrstev je v´yraznˇe obt´ıˇznˇejˇs´ı – interakce jednotliv´ ych vrstev se stanou pˇr´ıliˇs sloˇzit´e na to, aby se daly efektivnˇe zvl´ adnout. • V´ ysledn´e inteligentn´ı chov´an´ı agenta vznik´ a kombinac´ı chov´ an´ı jednotliv´ ych vrstev a prostˇred´ı. Proto je velmi tˇeˇzk´e pro takov´ y n´ avrh vytvoˇrit obecn´ y postup ˇci metodiku – pˇri v´ yvoji je tedy nutn´e pokaˇzd´e proj´ıt zdlouhav´ ym procesem experiment˚ u, pokus˚ u a chyb. • Limituj´ıc´ım faktorem reaktivn´ıch agent˚ u je neschopnost pl´ anov´ an´ı dalˇs´ıch akc´ı. Pˇri pokusech s relativnˇe jednoduch´ ymi agenty, jejichˇz c´ılem je napˇr´ıklad n´ ahodnˇe proch´azet m´ıstnosti a sb´ırat odpad [Con89] dosahuj´ı reaktivn´ı agenti obvykle minim´ alnˇe srovnateln´ ych v´ ysledk˚ u jako agenti se symbolickou reprezentac´ı svˇeta, velmi ˇcasto s v´ yraznˇe menˇs´ımi n´aroky na v´ ypoˇcetn´ı syst´em. Jsou vˇsak u ´koly, kter´e nelze reaktivn´ımu agentovi zadat [Kub04] – napˇr´ıklad aby se pˇresunul na nˇejak´e konkr´etn´ı m´ısto v laboratoˇri a tam vysb´ıral vˇsechny plechovky. Agent totiˇz nem´ a ˇz´ adnou pˇredstavu o okoln´ım svˇetˇe, kterou by pro proveden´ı takov´eho u ´kolu potˇreboval.
3.2.2
Uvaˇ zuj´ıc´ı agent
Jestliˇze pˇr´ıstup ke tvorbˇe reaktivn´ıho agenta se d´ a popsat jako zdola nahoru“ – n´ avrh´ aˇr ” prov´ad´ı dekompozici agenta podle u ´kol˚ u, kter´e m´ a agent plnit, u uvaˇzuj´ıc´ıho agenta je to vˇzdy shora dol˚ u“. Cel´ y syst´em se rozloˇz´ı na jednotliv´e funkˇcn´ı bloky (senzory, b´ aze znalost´ı, ” jednotka pro odvozov´an´ı, pl´anov´an´ı, efektory apod.), navrhnou se jejich vazby a teprve po implementaci vˇsech ˇc´ast´ı je syst´em provozuschopn´ y – nez´avisle na sloˇzitosti akc´ı, kter´e od agenta poˇzadujeme. Uvaˇzuj´ıc´ı agent obsahuje jako jednu z kl´ıˇcov´ ych komponent symbolickou reprezentaci svˇeta, poˇzadovan´eho chov´an´ı a sv´ ych akc´ı. Nad touto symbolickou reprezentac´ı pak agent prov´ad´ı syntaktick´e manipulace. Reprezentac´ı mohou b´ yt napˇr´ıklad formule predik´ atov´e logiky prvn´ıho ˇr´adu a syntaktick´ a manipulace pak odpov´ıd´ a logick´e dedukci, resp. dokazov´an´ı teor´em˚ u. Oznaˇcme L mnoˇzinu vˇsech vˇet predik´ atov´e logiky prvn´ıho ˇr´ adu a D = ℘(L) mnoˇzinu datab´az´ı (mnoˇzin) vˇet L. Prvky mnoˇziny D oznaˇc´ıme ∆, ∆1 , ... . Rozhodov´ an´ı agenta je modelov´ano pomoc´ı mnoˇziny ρ odvozovac´ıch pravidel, z´ apis ∆ ⊢ρ ϕ znaˇc´ı, ˇze ϕ m˚ uˇze b´ yt odvozeno z ∆ pouze pomoc´ı ρ. Uvaˇzuj´ıc´ıho agenta m˚ uˇzeme popsat obdobnˇe jako reaktivn´ıho pomoc´ı funkc´ı vjem, stav a akce. Funkce vjem je zcela shodn´ a jako u reaktivn´ıho agenta: vjem : E → P Funkce stav je obdobn´a jako u reaktivn´ıho agenta, vnitˇrn´ı stav je vˇsak d´ an agentovou reprezentac´ı svˇeta: stav : P × D → D Akce je pak zvolena na z´akladˇe stavu vnitˇrn´ı reprezentace: akce : D → A Uvaˇzuj´ıc´ı agent je pops´an opˇet jako ˇsestice DA = (P, A, D, vjem, stav, akce). Zjevnˇe kl´ıˇcov´ a je funkce akce, kter´a na z´akladˇe aktu´ aln´ıho stavu reprezentace rozhoduje, jakou akci z mnoˇziny A zvolit. Toho je moˇzn´e dos´ahnout tak [Woo02], ˇze pro kaˇzdou akci vytvoˇr´ıme odvozovac´ı pravidla tvaru ϕ(...) → ψ(...), kde ϕ a ψ jsou predik´ aty (kter´e mohou obsahovat 25
voln´e promˇenn´e, jeˇz jsou pˇri aplikaci pravidla nav´ az´ any). V nejjednoduˇsˇs´ım pˇr´ıpadˇe bude ϕ popisovat stav datab´aze a ψ akci, kter´ a se m´ a prov´est. Pˇr´ıkladem m˚ uˇze b´ yt pravidlo: P oziceRobota(x, y) ∧ P oziceOdpadu(x, y) → Do(zvedniOdpad) Tedy, nach´az´ı-li se robot na stejn´e pozici jako odpad, m´ a prov´est akci zvedniOdpad. Funkce akce se pak snaˇz´ı pro kaˇzdou akci α ∈ A odvodit Do(α). Pokud ∆ ⊢ρ Do(α), pak bude akce α vykon´ana. Jako pˇr´ıklady projekt˚ u, kter´e se daj´ı zaˇradit do t´eto kategorie, jmenujme syst´emy Concurent MetateM [Fis94] a AOP [Sho90, Sho93]. Pˇr´ıstup zaloˇzen´ y na logice je elegantn´ı a poskytuje jasnou s´emantiku, proto je pro mnoho vˇedc˚ u velmi l´ akav´ y. Tento pˇr´ıstup m´ a vˇsak tak´e celou ˇradu probl´em˚ u, kter´e daly vzniknout mnoha podobor˚ um klasick´e umˇel´e inteligence (rozpozn´av´an´ı obrazu, reprezentace znalost´ı, automatick´e odvozov´ an´ı apod.). Hlavn´ım probl´emem vˇsak z˚ ust´av´ a inherentn´ı ˇcasov´ a n´ aroˇcnost dokazov´ an´ı vˇet, kter´ a zp˚ usobuje u mnoh´ ych pochybnosti, zda se nˇekdy podaˇr´ı sestrojit agenta s touto architekturou pracuj´ıc´ıho v netrivi´aln´ım ˇcasovˇe omezen´em prostˇred´ı. Syst´ emy zaloˇ zen´ e na praktick´ em usuzov´ an´ı Na rozd´ıl od teoretick´eho usuzov´ an´ı (theoretical reasoning), kde je c´ılem odvozov´ an´ı rozhodnout, zda je ˇci nen´ı dan´a formule pravdiv´ a, praktick´e usuzov´ an´ı (practical reasoning) se zab´ yv´a t´ım, jak´a akce se m´a vykonat, aby se nˇejak´ a formule pravdivou stala. Praktick´e usuzov´an´ı se skl´ad´a ze dvou hlavn´ıch ˇc´ ast´ı – zvaˇzov´ an´ı (deliberation) a pl´ anov´ an´ı (means ends reasoning, planning). Ve f´ azi zvaˇzov´ an´ı se vol´ı c´ıl, kter´eho se m´ a dos´ ahnout. V´ ysledkem t´eto f´aze je z´ amˇer. Ve f´ azi pl´ anov´ an´ı se pak hled´ a vhodn´ a akce, ˇci sekvence akc´ı, kter´a dosaˇzen´ı z´amˇeru zajist´ı. Intuitivnˇe tento pˇr´ıstup odpov´ıd´ a zp˚ usobu, jak´ y pouˇz´ıv´ ame k ˇreˇsen´ı probl´em˚ u my, lid´e. V´ yvoj syst´em˚ u zaloˇzen´ ych na praktick´em usuzov´ an´ı skuteˇcnˇe ˇcerp´a z obor˚ u, jako je kognitivn´ı psychologie (cognitive psychology), filozofie akce (philosophy of action) a teorie racion´ aln´ıho v´ybˇeru (rational choice theory). Jedn´ım z pramen˚ u pro oblast zvaˇzov´ an´ı byla pr´ ace filozofa D. Dennetta [Den87], kter´ y tvrdil, ˇze ˇclovˇek je charakterizov´ an svou intencionalitou (intentional stance), schopnost´ı sebereflexe a pˇrisuzov´an´ı intencionality jin´ ym jedinc˚ um. Pˇri popisov´ an´ı chov´ an´ı jedinc˚ u pouˇz´ıv´ame ˇcasto vˇety jako: Karel tr´enoval, protoˇze chtˇel vyhr´ at a vˇeˇril ˇze to dok´ aˇze. Tento pˇr´ıstup stav´ı na naivn´ı psychologii (folk psychology), kter´ a umoˇzn ˇuje vysvˇetlovat a pˇredv´ıdat lidsk´e chov´an´ı t´ım, ˇze se ˇclovˇeku pˇriˇrad´ı atributy jako pˇredstavy o svˇetˇe, touhy, preference apod. Stejn´ y pˇr´ıstup se uk´ azal b´ yt uˇziteˇcn´ y pˇri popisu inteligentn´ıch agent˚ u. Kl´ıˇcov´ ym pojmem pro zvaˇzov´ an´ı je z´ amˇer. Problematikou z´ amˇer˚ u se zab´ yval zejm´ena filozof M. Bratman [Bra87]. Z´amˇer pˇredstavuje c´ıl, kter´eho agent hodl´ a dos´ ahnout. Z´ amˇer m´a pˇretrv´avaj´ıc´ı, perzistentn´ı charakter. Agent nem˚ uˇze od z´ amˇeru upustit, pokud k tomu nem´a dobr´ y d˚ uvod“. Situace, kter´e umoˇzn ˇuj´ı agentu odloˇzit z´ amˇer jsou v podstatˇe dvˇe: ” • Agent si je vˇedom, ˇze z´amˇer byl splnˇen, to znamen´ a, ˇze dos´ ahl c´ıle, kter´ y odpov´ıdal tomuto z´amˇeru. • Agent zjistil, ˇze z´amˇeru nikdy za ˇz´ adn´ ych okolnost´ı nem˚ uˇze b´ yt dosaˇzeno. Z´amˇery tvoˇr´ı jednu z kl´ıˇcov´ ych komponent architektury BDI a proto se jimi budu podrobnˇeji zab´ yvat v n´asleduj´ıc´ı kapitole vˇenovan´e t´eto architektuˇre. 26
Druh´ y krok – hled´an´ı sekvence akc´ı, kter´ a zajist´ı splnˇen´ı zvolen´eho z´ amˇeru, neboli pl´ anov´ an´ı – patˇr´ı mezi klasick´e discipl´ıny umˇel´e inteligence. Zˇrejmˇe prvn´ım a dodnes nejzn´amˇejˇs´ım pl´anovac´ım programem byl STRIPS [FN71]. Problematika pl´ anov´ an´ı je extenzivnˇe pokryta v [RN02]. Pˇres velk´ y pokrok, kter´ y se v t´eto oblasti podaˇrilo dos´ ahnout, z˚ ust´av´a hlavn´ım probl´emem pl´anov´ an´ı ˇcasov´ a sloˇzitost, zejm´ena v prostˇred´ıch, kter´a se rychle mˇen´ı a je tedy potˇreba pl´any v pr˚ ubˇehu jejich prov´ adˇen´ı revidovat. Z tohoto d˚ uvodu se syst´emy realizuj´ıc´ı praktick´e usuzov´ an´ı ˇcasto vybavuj´ı knihovnou pl´ an˚ u“, kter´ a obsa” huje parametrizovan´e ˇsablony pl´an˚ u, spoleˇcnˇe se situacemi, ve kter´ ych je vhodn´e tyto pl´any pouˇz´ıt. Stejnˇe tomu je u frameworku prezentovan´eho v t´eto pr´ aci, proto se zde klasick´ ym pl´anov´an´ım nebudu zab´ yvat. Zˇrejmˇe nejzn´amˇejˇs´ı architekturou zaloˇzenou na praktick´em usuzov´ an´ı je architektura BDI, kter´e je vˇenov´ana cel´a kapitola 4, pˇr´ıklady projekt˚ u a zhodnocen´ı proto ponech´ am do t´eto kapitoly.
3.2.3
Hybridn´ı agent
Agenti s reaktivn´ı architekturou jsou schopni rychl´e odezvy, avˇsak maj´ı probl´emy se zvl´ ad´an´ım komplexn´ıch u ´kol˚ u. Uvaˇzuj´ıc´ı agenti maj´ı probl´emy s rychlou odezvou na jednoduch´e podnˇety, protoˇze pouˇz´ıvaj´ı apar´at, kter´ y umoˇzn ˇuje zv´ aˇzit vˇsechny alternativy a vybrat optim´aln´ı akci, coˇz se hod´ı sp´ıˇse pro komplexn´ı u ´koly. Proto jsou vyv´ıjeny architektury, kter´e v sobˇe zahrnuj´ı obˇe paradigmata, pˇr´ıpadnˇe i nˇekter´ a dalˇs´ı. Obvykle se jedn´ a o vrstven´e architektury. Vrstvy mohou b´ yt propojeny bud’ horizont´ alnˇe nebo vertik´ alnˇe. U horizont´ aln´ıho vrstven´ı (viz obr´azek 3.2) dost´avaj´ı vˇsechny vrstvy stejn´ y senzorick´ y vstup a maj´ı k dispozici pˇr´ıstup k efektor˚ um. V tomto pˇr´ıpadˇe mus´ı existovat nˇejak´ y ˇr´ıd´ıc´ı mechanismus, kter´ y rozhodne, kter´a vrstva bude v dan´em okamˇziku kontrolovat agenta. Pˇr´ıkladem hybridn´ı architektury s horizont´aln´ım vrstven´ım je projekt TouringMachines [Fer92].
Obr´azek 3.2: Sch´ema horizont´ alnˇe vrstven´e architektury V pˇr´ıpadˇe vertik´aln´ıho vrstven´ı (viz obr´ azek 3.3) je se senzory a efektory obvykle spojena jen jedna vrstva. Podle toku dat a ˇr´ızen´ı rozliˇsujeme vrstven´ı s jednopr˚ uchodov´ym ˇr´ızen´ım (na obr´azku 3.3 vpravo, o akci rozhoduje horn´ı vrstva, zat´ımco spodn´ı vrstva dost´ av´ a senzorick´ y vstup) a dvoupr˚ uchodov´ym ˇr´ızen´ım (na obr´ azku 3.3 vlevo, vstup od senzor˚ u i pˇr´ıkazy efektor˚ um pos´ıl´a spodn´ı vrstva). Pˇr´ıkladem takov´eto architektury je InteRRaP (Integration of Reactive Behaviour and Rational Planning) [Mul97], kter´ a obsahuje tˇri vrstvy. Nejniˇzˇs´ı reaktivn´ı vrstva vykon´ av´ a reakce na ud´alosti, kter´e vyˇzaduj´ı rychlou odezvu, jako je vyh´ yb´ an´ı se pˇrek´ aˇzk´ am. Tyto ud´alosti jsou urˇceny takzvan´ ym popisem situac´ı. Ud´ alosti, kter´e nezapadaj´ı do ˇz´ adn´eho vzoru takov´eho popisu jsou pˇred´ any vyˇsˇs´ım vrstv´ am. Druh´ a vrstva se naz´ yv´ a vrstva lok´ aln´ıho pl´ anov´ an´ı, a je zodpovˇedn´ a za situace, kter´e vyˇzaduj´ı uvaˇzov´ an´ı, pˇr´ıpadnˇe tvorbu pl´anu. Nejvyˇsˇs´ı vrstva, vrstva kooperativn´ıho pl´ anov´ an´ı, odpov´ıd´ a za ˇreˇsen´ı konflikt˚ u s ostatn´ımi agenty a za koordinaci pl´an˚ u pˇri ˇreˇsen´ı spoleˇcn´eho u ´kolu. 27
Obr´azek 3.3: Sch´ema vertik´ alnˇe vrstven´e architektury
V´ yhodou hybridn´ıch agent˚ u je jejich schopnost reagovat t´emˇeˇr srovnatelnˇe rychle jako reaktivn´ı agenti a z´aroveˇ n vytv´aˇret pl´ any jako uvaˇzuj´ıc´ı agenti. Hlavn´ı nev´ yhodou je pak vˇetˇs´ı komplexnost cel´eho syst´emu a pˇr´ıdavn´ a reˇzie na synchronizaci jednotliv´ ych vrstev.
3.3
Prostˇ red´ı a interakce v multiagentn´ıch syst´ emech
Jiˇz pˇri vymezen´ı pojmu agent jsme uvedli, ˇze se jedn´ a o syst´em, kter´ y se nach´ az´ı v nˇejak´em prostˇred´ı. Prostˇred´ı je tedy pro agenta velmi d˚ uleˇzit´e, pˇredevˇs´ım proto, ˇze pˇredstavuje jeho sf´eru p˚ usobnosti a zdroj podnˇet˚ u, bez kter´ ych by jeho existence nemˇela smysl (sv´ azanost agenta s jeho prostˇred´ım ho mimo jin´e odliˇsuje od expertn´ıch syst´em˚ u [Woo02]). Toto prostˇred´ı vˇsak m˚ uˇze b´ yt agenty tak´e vyuˇz´ıv´ ano, napˇr´ıklad pro komunikaci. Spr´ avn´e vyuˇzit´ı prostˇred´ı m˚ uˇze u agent˚ u v´ yraznˇe sn´ıˇzit n´ aroˇcnost jejich v´ yvoje. V´ yzkumem na toto t´ema se zab´ yv´a v souˇcasn´e dobˇe cel´a ˇrada vˇedc˚ u, dokonce v r´ amci komunity zab´ yvaj´ıc´ı se multiagentn´ımi syst´emy vznikl pojem environmental engineering“. Dobr´ y pˇrehled o moˇznostech ” a souˇcasn´em stavu vyuˇz´ıv´an´ı prostˇred´ı pˇri tvorbˇe agentn´ıch syst´emu pod´ av´ a D. Weyns v ˇcl´anku [WOO07]. Do agentova prostˇred´ı vˇsak obvykle poˇc´ıt´ ame i v´ ypoˇcetn´ı syst´em, v r´ amci kter´eho agent bˇeˇz´ı“. U softwarov´eho agenta by mˇel tento v´ ypoˇcetn´ı syst´em agentovi poskytovat potˇrebn´e ” prostˇredky pro jeho chod, spr´avu ˇzivotn´ıho cyklu, vyhled´ av´ an´ı ostatn´ıch agent˚ u a zas´ıl´ an´ı zpr´av. Tato oblast je velmi d˚ uleˇzit´ a pro spolupr´ aci heterogenn´ıch agent˚ u, proto byla tak´e jednou z prvn´ıch oblast´ı, kter´e se dotkla standardizace. V dneˇsn´ı dobˇe tak jiˇz existuj´ı normy [FIP02a, FIP04] pro to, jak´e sluˇzby by mˇelo prostˇred´ı agent˚ um poskytovat, jak by tyto sluˇzby mˇely b´ yt pojmenov´any a jak´e rozhran´ı by mˇely m´ıt. Standardizaci v oblasti agentn´ıch technologi´ı je vˇenov´ana samostatn´ a podkapitola d´ ale v textu. Jak jiˇz bylo ˇreˇceno, v prostˇred´ı se typicky nach´ azej´ı dalˇs´ı agenti. Na rozd´ıl od problematiky ˇreˇsen´e v klasick´ ych distribuovan´ ych syst´emech m´ a kaˇzd´ y z tˇechto agent˚ u sv´e vlastn´ı u ´koly a c´ıle, kter´e mu zadal jeho uˇzivatel. Tyto c´ıle mohou b´ yt u dvou agent˚ u v jednom extr´emn´ım pˇr´ıpadˇe shodn´e, ve druh´em extr´emu zcela protich˚ udn´e. Pˇr´ıpady mezi tˇemito dvˇema extr´emy d´avaj´ı prostor k vyjedn´ av´ an´ı. Agent typicky nem´ a pˇr´ıstup k cel´emu prostˇred´ı – obvykle m˚ uˇze vn´ımat a ovlivˇ novat pouze jeho ˇca´st. V tomto pˇr´ıpadˇe m˚ uˇze b´ yt kooperace s dalˇs´ımi agenty nezbytn´ a. Velk´ a ˇc´ ast prac´ı o multiagentn´ıch syst´emech se tedy zab´ yv´a t´ım, jak ˇreˇsit konflikty mezi agenty a naopak jak maj´ı agenti vyjedn´ avat pro dosaˇzen´ı kooperace a jak tuto kooperaci posl´eze koordinovat. Jedn´ım z moˇzn´ ych pˇr´ıstup˚ u, jak k anal´ yze chov´ an´ı agent˚ u v r´ amci cel´eho syst´emu
28
pˇristoupit, je pouˇz´ıt matematickou teorii her. Akce, kter´e m˚ uˇze agent vykonat se v pojmech teorie her naz´ yvaj´ı strategie. Kaˇzd´ y agent m´ a sv´e preference o tom, v jak´em stavu by se prostˇred´ı mˇelo nach´azet. Tyto preference se vyj´ adˇr´ı funkc´ı, kter´ a kaˇzd´ y stav ohodnot´ı re´aln´ ym ˇc´ıslem. Na z´akladˇe toho se daj´ı strategie porovn´ avat a je moˇzn´e analyzovat, jak by se mˇel agent v dan´e situaci zachovat. Klasickou uk´ azkou toho pˇr´ıstupu je vˇezˇ novo dilema [RN02]. Pokud dva agenti nemaj´ı zcela protich˚ udn´e c´ıle, mohou dos´ ahnout oboustrannˇe v´yhodn´e dohody. Pro uzav´ır´an´ı takov´ ych dohod vˇsak mus´ı existovat mechanismy – protokoly, kter´e definuj´ı jak´ ym zp˚ usobem m´a vyjedn´ av´ an´ı prob´ıhat. V prostˇred´ı multiagentn´ıch syst´em˚ u si velkou oblibu z´ıskaly zejm´ena r˚ uzn´e druhy aukce [Woo02], kter´e se pouˇz´ıvaj´ı pˇredevˇs´ım pro pˇridˇelov´an´ı zdroj˚ u ˇci rozdˇelov´an´ı pr´ ace. Aby protokol mohl plnit svou funkci v prostˇred´ı heterogenn´ıch agent˚ u, mus´ı b´ yt vˇsem n´ avrh´ aˇr˚ um zn´ ama jeho pˇresn´ a specifikace. Proto byly tak´e pro tuto oblast vyvinuty mezin´ arodn´ı standardy (napˇr. [FIP02b]). Probl´emy spolupr´ace agent˚ u nast´ınˇen´e v t´eto ˇc´ asti se vlastn´ıho n´ avrhu architektury agenta, kter´a je hlavn´ım t´ematem pˇredloˇzen´e pr´ ace, dot´ ykaj´ı sp´ıˇse okrajovˇe. Proto zde nebyly rozeb´ır´any detailnˇe, d˚ uleˇzit´e vˇsak jsou dva poznatky: • agent mus´ı b´ yt vybaven schopnostmi komunikace na pomˇernˇe vysok´e u ´rovni, • mus´ı b´ yt schopen uvaˇzovat o akc´ıch zasl´ an´ı a pˇr´ıjmu zpr´ avy obdobnˇe jako o vˇsech sv´ ych ostatn´ıch (fyzick´ ych) akc´ıch.
3.4
Komunikace v multiagentn´ıch syst´ emech
Komunikace mezi agenty m˚ uˇze m´ıt celou ˇradu podob. Napˇr´ıklad mezi nejjednoduˇsˇs´ı patˇr´ı reaktivn´ı komunikace, kter´a b´ yv´a zaloˇzena na zanech´ av´ an´ı znaˇcek v prostˇred´ı, coˇz pˇredstavuje obdobu chov´an´ı hmyzu ˇzij´ıc´ıho ve spoleˇcenstv´ıch [BF89]. U agent˚ u se symbolickou reprezentac´ı svˇeta vˇsak tato komunikace prob´ıh´ a typicky na daleko vyˇsˇs´ı u ´rovni. Z´aklad pro tento zp˚ usob komunikace tvoˇr´ı teorie ˇreˇcov´eho aktu (speech act theory) [Aus75], ve kter´e se ke komunikaci pˇristupuje jako k prov´ adˇen´ı akc´ı. Kaˇzd´e zasl´an´ı zpr´avy tak m´a kromˇe informaˇcn´ıho obsahu zpr´ avy za c´ıl u adres´ ata vykonat nˇejakou zmˇenu v jeho kognitivn´ım stavu. Na z´ akladˇe toho se daj´ı z komunikace abstrahovat r˚ uzn´e druhy zpr´av (ozn´amen´ı, poˇzadavek, pˇr´ıkaz, apod.). Z t´eto teorie vych´ azej´ı vysoko´ urovˇ nov´e jazyky pro komunikaci mezi agenty. Jazyk KQML (Knowledge Query Manipulation Language) [FFMM94] byl vyvinut jako souˇc´ast projektu agentury DARPA za u ´ˇcelem v´ ymˇeny informac´ı a znalost´ı mezi autonomn´ımi informaˇcn´ımi syst´emy. Jeho syntaxe je velmi podobn´ a jazyku LISP. Je zaloˇzen na zpr´av´ach, kaˇzd´a zpr´ava odpov´ıd´ a jednomu ˇreˇcov´emu aktu. Skl´ ad´ a se z performativu, n´asledovan´eho voliteln´ ym poˇctem atribut˚ u. Performativ urˇcuje typ zpr´ avy, tedy ve vˇetˇsinˇe pˇr´ıpad˚ u jak´emu ˇreˇcov´eho aktu zpr´ ava odpov´ıd´ a. Kaˇzd´ y atribut m´ a tvar dvojice, pˇriˇcemˇz prvn´ı ˇclen pˇredstavuje n´azev atributu a druh´ y jeho hodnotu. Zpr´ ava tedy m˚ uˇze vypadat napˇr´ıklad takto: (inform :sender book-seller-agent :reciever client-agent :content "price(isaac-asimov-foundation, 25)" :language Prolog ) 29
Performativ t´eto zpr´avy je inform, tedy v´ yznam zpr´ avy je takov´ y, ˇze agent identifikovan´ y atributem :sender zas´ıl´a informaci agentovi specifikovan´eho atributem :receiver. Vlastn´ı obsah zpr´avy je zapouzdˇren v atributu :content. Tento obsah m˚ uˇze b´ yt zaps´ an v libovoln´em jazyce, v r´amci KQML oznaˇcovan´eho jako obsahov´y jazyk. Identifikace obsahov´eho jazyka je specifikov´ana atributem :language. Jazyk KQML si z´ıskal pomˇernˇe znaˇcnou oblibu, stal se vˇsak tak´e terˇcem cel´e ˇrady kritik. Probl´emy zp˚ usobuje zejm´ena to, ˇze s´emantika jazyka nebyla form´ alnˇe definov´ ana, coˇz vede k r˚ uzn´emu pochopen´ı u jednotliv´ ych implementac´ı a n´ asledn´e nekompatibilitˇe. Nav´ıc postupnˇe vznikla cel´a ˇrada verz´ı jazyka, kter´e obsahovaly r˚ uzn´e mnoˇziny performativ˚ u. Tato mnoˇzina se tak´e mnoh´ ym zd´ala pˇr´ıliˇs velk´ a (v p˚ uvodn´ı verzi pˇribliˇznˇe 40 performativ˚ u) a navrˇzen´a ad hoc. Tato kritika byla podnˇetem pro vznik jazyka FIPA ACL [FIP01], kter´ y je syntakticky prakticky shodn´ y s KQML, avˇsak m´ a form´ alnˇe definovanou s´emantiku (pomoc´ı jazyka FIPA SL, kter´ y vych´az´ı z pr´ace [BS97]) a pevnˇe danou mnoˇzinu dvaceti performativ˚ u, jejichˇz v´ ybˇer byl proveden na z´akladˇe peˇcliv´e anal´ yzy potˇreb, kter´e vyvstaly pˇri pouˇz´ıv´ an´ı KQML. Jazyk FIPA ACL pˇredstavuje v dneˇsn´ı dobˇe mezin´ arodn´ı standard [FIP01], proto se s n´ım v n´avrhu frameworku prezentovan´eho v t´eto pr´ aci poˇc´ıt´ a jako s jazykem pro komunikaci (v implementovan´em prototypu se pouˇz´ıv´ a jeho podmnoˇzina). Jazyky KQML i FIPA ACL pˇredpokl´ adaj´ı pouˇzit´ı dalˇs´ıho jazyka pro v´ ymˇenu vlastn´ıho obsahu zpr´av. Z hlediska n´avrhu frameworku nen´ı v´ ybˇer takov´eho jazyka pˇr´ıliˇs podstatn´ y, protoˇze tento jazyk se obvykle vol´ı v z´ avislosti na konkr´etn´ı aplikaci. Pro jednoduch´e pˇr´ıklady je napˇr´ıklad moˇzn´e pouˇz´ıvat pˇr´ım´e pˇred´ av´ an´ı hodnot v atributu zpr´ avy :content, nebo pouˇz´ıt predik´aty jazyka Prolog, jak tomu bylo u uk´ azky zpr´ avy KQML v´ yˇse. V prostˇred´ı, kde se pohybuje cel´a ˇrada heterogenn´ıch agent˚ u, kteˇr´ı byli vytvoˇreni r˚ uzn´ ymi institucemi, je vˇsak potˇreba shodnout se na interpretaci obsahu zpr´ avy stejnˇe d˚ uleˇzit´ a, jako na jazyku pro komunikaci. Tento probl´em se snaˇz´ı ˇreˇsit koncept ontologi´ı. Ontologie je form´aln´ı, explicitn´ı specifikace vyj´ adˇren´ı konceptu zpr´ avy. Ontologie tedy ud´ av´ a v´ yznam symbol˚ u ve zpr´avˇe [Gru93]. Aby mohly b´ yt ontologie plnˇe vyuˇz´ıv´ any pˇri komunikaci heˇ sen´ım terogenn´ıch agent˚ u, mus´ı b´ yt um´ıstˇeny na nˇejak´em veˇrejnˇe dostupn´em u ´loˇziˇsti. Reˇ jsou obecn´e ontologick´e slovn´ıky a ontologick´e servery, coˇz jsou m´ısta, kde jsou ontologie definov´any jako dom´eny. Komunikuj´ıc´ı agenti mohou tato m´ısta vyuˇz´ıvat a pˇri komunikaci uv´adˇet ontologie vztaˇzen´e k zas´ılan´ ym zpr´ av´ am.
3.5
Standardizace agentn´ıch technologi´ı – organizace FIPA
Organizace FIPA1 – Foundation for Intelligent Physical Agents je neziskov´ a organizace, jej´ım c´ılem je vytv´aˇret pr˚ umyslov´e standardy pro problematiku agent˚ u a multiagentn´ıch ˇ ysyst´em˚ u za u ´ˇcelem podpory znovupouˇzit´ı k´ odu a interoperatibility. Byla zaloˇzena ve Sv´ carsku v roce 1996, v roce 2005 se stala souˇc´ ast´ı IEEE Computer Society (jako jedna ze standardizaˇcn´ıch komis´ı). Vˇetˇsina jej´ıch norem byla pˇrijata v obdob´ı kolem roku 2002, po vstupu do asociace IEEE se zaˇcala zab´ yvat tak´e standardizac´ı napojen´ı agentn´ıch syst´em˚ u na neagentn´ı technologie. V souˇcasn´e dobˇe (rok 2008) m´ a FIPA 44 ˇclen˚ u, ˇclensk´ a z´ akladna je tvoˇrena pˇrev´aˇznˇe firmami zab´ yvaj´ıc´ımi se agentn´ımi technologiemi (mezi jin´ ymi Boeing, Siemens, Toshiba a dalˇs´ı) a univerzitami. Normalizace se zamˇeˇruje na n´ asleduj´ıc´ı oblasti: 1
http://www.fipa.org
30
• Abstraktn´ı architektura – normalizuje obecn´e poˇzadavky na komponenty agentn´ıho syst´emu, tyto normy tvoˇr´ı z´ aklad vˇsech ostatn´ıch norem. • Spr´ ava agent˚ u – tyto normy specifikuj´ı ˇzivotn´ı cyklus agenta, definuj´ı z´ akladn´ı principy identifikace agent˚ u a podp˚ urn´ ych sluˇzeb pro jejich bˇeh. • Meziagentn´ı komunikace – standardizuje strukturu zpr´ av, ontologie, interakˇcn´ı protokoly, obsahov´e jazyky apod. • Pˇrenos zpr´ av – tyto normy se zab´ yvaj´ı t´ım, jak m´ a prob´ıhat v´ ymˇena zpr´ av v r˚ uzn´ ych prostˇred´ıch, zejm´ena Internetu. • Aplikaˇcn´ı oblasti agent˚ u – normy v t´eto oblasti jsou vˇetˇsinou ve v´ yvoji, zamˇeˇruj´ı se na to, jak´e sluˇzby by mˇel agent poskytovat v dan´e aplikaˇcn´ı dom´enˇe (napˇr. osobn´ı asistent) a jak by mˇel s ostatn´ımi agenty komunikovat, tedy zejm´ena doporuˇcen´e ontologie. V dneˇsn´ı dobˇe by tak kaˇzd´a multiagentn´ı aplikace, u kter´e se poˇc´ıt´ a s jin´ ym neˇz ˇcistˇe akademick´ ym ˇci prototypov´ ym pouˇzit´ım mˇela splˇ novat alespoˇ n z´ akladn´ı koncepty definovan´e v tˇechto norm´ach. Zjevnˇe nejd˚ uleˇzitˇejˇs´ı je ot´ azka komunikace pomoc´ı zas´ıl´ an´ı zpr´av – v´ ymˇena zpr´av v s´ıt’ov´em prostˇred´ı je totiˇz nejtypiˇctˇejˇs´ım zp˚ usobem interakce heterogenn´ıch agent˚ u.
31
Kapitola 4
Architektura BDI Architektura BDI pˇredstavuje v dneˇsn´ı dobˇe zˇrejmˇe nejrozˇs´ıˇrenˇejˇs´ı pˇr´ıstup k tvorbˇe agent˚ u zaloˇzen´ ych na praktick´em usuzov´an´ı. Zkratka BDI poch´ az´ı z anglick´ ych slov Beliefs (pˇredstavy), Desires (touhy) a Intentions (z´ amˇery), kter´e spoleˇcnˇe s pl´ any tvoˇr´ı z´ akladn´ı prvky t´eto architektury. Na architekturu BDI lze nahl´ıˇzet ze tˇr´ı u ´hl˚ u pohledu: • Filozofick´eho: filozofick´ y z´aklad t´eto architektury poloˇzil M. Bratman v knize [Bra87], ve kter´e se snaˇzil modelovat lidsk´e praktick´e usuzov´ an´ı. Lid´e jsou naz´ır´ ani jako pl´anuj´ıc´ı agenti, kteˇr´ı pouˇz´ıvaj´ı pˇredstavy (to co v´ı o svˇetˇe), touhy (to co chtˇej´ı, touhy mohou b´ yt ve vz´ajemn´em rozporu) a z´ amˇery (to co se rozhodli dos´ ahnout, z´ amˇery mus´ı b´ yt na rozd´ıl od tuˇzeb konzistentn´ı). Jeho pr´ ace vych´ az´ı z naivn´ı psychologie (folk psychology), kter´a zav´ ad´ı potˇrebn´e koncepty jako jsou pˇredstavy, touhy apod. • Form´ aln´ıho (logick´eho): koncept˚ um pˇredstav, tuˇzeb a z´ amˇer˚ u je v tomto pˇr´ıstupu pˇriˇrazen pˇresn´ y logick´ y v´ yznam. Pouˇz´ıvan´e logiky vych´ azej´ı z mod´ aln´ıch logik se s´emantikou moˇzn´ ych svˇet˚ u. • Implementaˇcn´ıho: re´aln´e aplikace navazuj´ı na filozofick´ y a logick´ y pˇr´ıstup pomˇernˇe volnˇe. Pˇredstavy jsou obvykle omezeny na formu datab´ aze, c´ıle jsou modelov´ any jako ud´alosti v syst´emu a z´amˇery odpov´ıdaj´ı z´ asobn´ık˚ um pr´ avˇe prov´ adˇen´ ych pl´ an˚ u. Tato odtaˇzitost re´aln´ ych aplikac´ı od form´ aln´ı teorie vedla k mnoha pokus˚ um o alternativn´ı formalizaci realizovan´ ych aplikac´ı. V n´asleduj´ıc´ıch ˇc´astech se budu postupnˇe zab´ yvat jednotliv´ ymi pˇr´ıstupy podrobnˇeji – nejprve se zamˇeˇr´ım na z´akladn´ı komponenty architektury, n´ aslednˇe uk´ aˇzi v´ ychodiska pro formalizaci a nakonec nˇekolik implementovan´ ych syst´em˚ u spoleˇcnˇe s pokusy o jejich alternativn´ı form´aln´ı popis.
4.1 4.1.1
Z´ akladn´ı principy a komponenty architektury BDI Pˇ redstavy
Pˇredstavy reprezentuj´ı agentovy znalosti. Tyto znalosti se typicky t´ ykaj´ı prostˇred´ı, ve kter´em se agent nach´az´ı, jeho schopnost´ı, ostatn´ıch agent˚ u v syst´emu ˇci historie jeho akc´ı – tedy v z´asadˇe jsou to poznatky o stavu svˇeta. Znalosti o tom, jak tento stav mˇenit jsou reprezentov´any procedur´alnˇe ve formˇe pl´ an˚ u, kter´ ym je vˇenov´ ana samostatn´ a ˇc´ ast d´ ale v textu. Co bylo d˚ uvodem pro zaveden´ı pojmu pˇredstava, nam´ısto pojmu znalost, bˇeˇznˇe 32
pouˇz´ıvan´eho v klasick´e umˇel´e inteligenci? Informace, kter´e m´ a agent k dispozici, nemus´ı b´ yt nutnˇe pravdiv´e (zejm´ena v kontextu dynamick´eho prostˇred´ı, popˇr´ıpadˇe ˇspatnˇe funguj´ıc´ıch agentov´ ych senzor˚ u). M˚ uˇze se tedy st´ at, ˇze agent vytvoˇr´ı ˇspatn´ y pl´ an ˇci provede nesmyslnou akci kv˚ uli tomu, ˇze vych´ azel z chybn´ ych pˇredpoklad˚ u. C´ılem zaveden´ı pojmu pˇredstava je tedy zd˚ uraznit subjektivitu informac´ı, kter´e jsou agentovi dostupn´e. Z hlediska filozofick´eho m´a zcela jistˇe v´ yznam zab´ yvat se meta-pˇredstavami, tedy pˇredstavami o pˇredstav´ach. Prof. Dennett [Den87] dokonce dˇelil syst´emy podle jejich schopnost´ı m´ıt tyto pˇredstavy vyˇsˇs´ıch ˇr´ad˚ u“ – syst´em, kter´ y mˇel pˇredstavy, pˇr´ an´ı a dalˇs´ı ment´aln´ı ” stavy, naz´ yval intencion´ aln´ım syst´emem prvn´ıho ˇra ´du. Syst´em kter´ y mˇel pˇredstavy, pˇr´ an´ı a dalˇs´ı ment´aln´ı stavy o pˇredstav´ ach a pˇr´ an´ıch sv´ ych a ostatn´ıch agent˚ u naz´ yval intencion´ aln´ım syst´emem druh´eho ˇra ´du. Intencion´ aln´ı syst´emy tˇret´ıho ˇra ´du mohly m´ıt pˇredstavy o meta-pˇredstav´ach atd. Schopnost modelovat pˇredstavy a pˇr´ an´ı ostatn´ıch agent˚ u je zjevnˇe kl´ıˇcov´ a pro pˇredv´ıd´ an´ı jejich chov´an´ı. Aby vˇsak bylo moˇzn´e takov´e z´ avˇery korektnˇe odvozovat, mus´ı pro to b´ yt k dispozici form´aln´ı apar´at. Jist´ ych pokrok˚ u bylo v t´eto oblasti dosaˇzeno, avˇsak ˇcasov´ a n´aroˇcnost a sloˇzitost implementace takov´ ychto syst´emu ˇcin´ı tento pˇr´ıstup v souˇcasn´e dobˇe pro praktick´e pouˇzit´ı nere´aln´ ym. Souˇcasn´e implementace se tak obvykle omezuj´ı na intencion´aln´ı syst´emy prvn´ıho ˇr´adu. Pˇredstavy jsou pak obvykle skladov´ any v jist´em druhu datab´aze, kter´a je ˇcasto naz´ yv´ana b´ aze pˇredstav (belief base). Hlavn´ı probl´emy n´ avrhu b´ aze pˇredstav se t´ ykaj´ı toho, jak´ ym zp˚ usobem by mˇely b´ yt znalosti reprezentov´ any a jak by mˇely b´ yt aktualizov´any – napˇr´ıklad jak´ ym zp˚ usobem by mˇel agent ˇreˇsit konflikt mezi informacemi ze senzor˚ u a sv´e b´aze pˇredstav. Pˇr´ıstup˚ u k t´eto problematice je cel´ a ˇrada, kr´ atce se o nich zm´ın´ım u jednotliv´ ych konkr´etn´ıch implementac´ı.
4.1.2
Touhy
Touhy (v nˇekter´ ych syst´emech a u nˇekter´ ych autor˚ u naz´ yvan´e c´ıle) reprezentuj´ı motivaci agenta. Vyjadˇruj´ı objekty, informace nebo situace, kter´ ych se agent snaˇz´ı dos´ ahnout. Ne vˇsechny touhy mus´ı b´ yt v dan´em okamˇziku splniteln´e. Pouˇz´ıv´ an´ı pojmu c´ıl nam´ısto touha obvykle ponˇekud zuˇzuje v´ yznam tohoto konceptu v tom smyslu, ˇze c´ıle by mˇely b´ yt konzistentn´ı. Agent by napˇr´ıklad nemˇel m´ıt c´ıle j´ıt dnes veˇcer do kina a z˚ ustat dnes veˇcer doma, pˇrestoˇze by obˇe tyto moˇznosti pro nˇej byly l´ akav´e.
4.1.3
Z´ amˇ ery
Pojem z´amˇer vyjadˇruje odhodl´an´ı agenta dos´ ahnout zvolen´e touhy ˇci c´ıle. Pˇredstavuje u ´stˇredn´ı pojem v pr´aci prof. Bratmana [Bra87]. Bratman o z´ amˇerech formuloval celou ˇradu bod˚ u: • Z´amˇer pˇredstavuje zad´ an´ı probl´emu, agent se snaˇz´ı nal´ezt zp˚ usob, jak jej dos´ ahnout. • Z´amˇer pˇredstavuje pro agenta mez pˇr´ıpustnosti (screen of admisibility) pro pˇrij´ım´ an´ı dalˇs´ıch z´amˇer˚ u. • Agent si uchov´av´a z´aznam o tom, zda jeho pokusy o dosaˇzen´ı z´ amˇeru byly u ´spˇeˇsn´e. • Agent vˇeˇr´ı, ˇze je z´amˇer moˇzn´e splnit. • Agent nevˇeˇr´ı, ˇze se nikdy v budoucnosti nem˚ uˇze pˇribl´ıˇzit k dosaˇzen´ı z´ amˇeru. • Agent vˇeˇr´ı, ˇze se za urˇcit´ ych podm´ınek pˇribl´ıˇz´ı k dosaˇzen´ı z´ amˇeru. 33
• Agent nemus´ı m´ıt v u ´myslu vˇsechny vedlejˇs´ı u ´ˇcinky, kter´e nastanou pˇri dosahov´ an´ı z´amˇeru. Pokud agent z´amˇer jednou pˇrijme, nem˚ uˇze od nˇej upustit, pokud nenastane jedna ze dvou situac´ı: • Agent vˇeˇr´ı, ˇze dos´ahl z´amˇeru, tedy splnil c´ıl. • Agent zjist´ı, ˇze z´amˇer jiˇz nikdy v budoucnu nebude moˇzn´e splnit. Agent samozˇrejmˇe m˚ uˇze sledovat v´ıce z´ amˇer˚ u najednou, typicky jednotliv´ ym z´ amˇer˚ um pˇriˇrazuje r˚ uzn´e priority, pˇr´ıpadnˇe doˇcasnˇe odkl´ ad´ a z´ amˇery, pro jejichˇz dosaˇzen´ı nen´ı moment´alnˇe schopen sestavit pl´an.
4.1.4
Pl´ any
Pl´any pˇredstavuj´ı ˇctvrt´ y z´akladn´ı koncept architektury BDI, zkratka by tak mˇela zn´ıt sp´ıˇse BDIP“. Zat´ımco ve formalizaci architektury BDI jsou zmiˇ nov´ any sp´ıˇse okrajovˇe, ” v praktick´ ych realizac´ıch jsou povaˇzov´ any za u ´stˇredn´ı pojem – pˇredstavuj´ı procedur´aln´ı reprezentaci agentov´ ych znalost´ı o tom, jak mˇenit sv´e prostˇred´ı tak, aby dosahoval sv´ ych c´ıl˚ u. Pl´any mohou b´ yt hierarchick´e, tj. obsahovat dalˇs´ı pl´ any. Stejnˇe tak mohou b´ yt pouze ˇc´asteˇcnˇe konkretizovan´e (obsahovat podc´ıle nebo promˇenn´e). Unifikace se pak v tomto pˇr´ıpadˇe prov´adˇej´ı pˇri inicializaci, pˇr´ıpadnˇe v pr˚ ubˇehu vykon´ av´ an´ı pl´ anu. Konkr´etn´ı struktura pl´an˚ u se mezi jednotliv´ ymi implementovan´ ymi syst´emy liˇs´ı, nˇekter´e charakteristick´e rysy jsou vˇsak spoleˇcn´e. Pl´an typicky sest´ av´ a z hlaviˇcky a tˇela. Hlaviˇcka obsahuje c´ıl, kter´ y pl´an umoˇzn ˇuje dos´ahnout, a mnoˇzinu podm´ınek, kter´e mus´ı b´ yt splnˇeny, aby byl pl´an v dan´e situaci aplikovateln´ y. Tˇelo sest´ av´ a ze sekvence atomick´ ych akc´ı, kter´e je agent schopen vykonat. Kromˇe tˇechto akc´ı se obvykle povoluje vyvol´ an´ı podc´ıl˚ u a testov´ an´ı b´ aze znalost´ı. Tyto pl´any, resp. sp´ıˇse ˇsablony pl´ an˚ u, jsou pˇredem vytvoˇreny program´ atorem dan´e aplikace a b´ yvaj´ı uloˇzeny v knihovnˇe pl´ an˚ u. Pˇri v´ yskytu nˇejak´e ud´ alosti se pak v t´eto knihovnˇe hledaj´ı pl´any, kter´e pˇredstavuj´ı vhodnou reakci na danou ud´ alost. Agenti s architekturou BDI tak typicky neprov´adˇej´ı ˇz´adn´e pl´ anov´ an´ı v klasick´em slova smyslu (planning from first principles). D˚ uvodem pro to je zejm´ena ˇcasov´ a n´ aroˇcnost takov´eho pl´ anov´ an´ı, kter´ a by zp˚ usobovala pˇr´ıliˇs dlouh´e prodlevy v odezvˇe. Typick´ ym pouˇzit´ım BDI agent˚ u jsou totiˇz prostˇred´ı, kde jsou ˇcasov´a omezen´ı znaˇcn´ a a prostˇred´ı se rychle mˇen´ı. V takov´ ych prostˇred´ıch nen´ı kl´ıˇcov´a schopnost sestavit optim´ aln´ı pl´ an, ale sp´ıˇse schopnost rozpoznat, kdy dan´ y pl´an jiˇz nem´a smysl a zkusit jin´ y pˇr´ıstup, pˇr´ıpadnˇe cel´ y z´ amˇer odloˇzit. Uk´ azky jednotliv´ ych konkr´etn´ıch realizac´ı pl´an˚ u budou n´ asledovat u popisu pˇr´ısluˇsn´ ych syst´em˚ u.
4.2
Formalizace BDI
Pro architekturu BDI bylo vytvoˇreno nˇekolik form´ aln´ıch popis˚ u. Dnes jiˇz klasick´ y popis pˇredstavuje logika naz´ yvan´a BDI CTL, kter´ a kombinuje multimod´ aln´ı logiku s tempor´aln´ı logikou CTL*. Autory t´eto logiky jsou prof. Rao a prof. Georgeff [RG92]. Na tuto pr´aci nav´azal prof. Wooldridge se svoj´ı Logic of Rational Agents (LORA) [Woo01]. Logiku BDI CTL spoleˇcnˇe s potˇrebn´ ymi souvislostmi v n´ asleduj´ıc´ı podkapitole velice struˇcnˇe pˇredstav´ım. Alternativn´ı formalizace BDI vych´ az´ı ze situaˇcn´ıho kalkulu [Rei01].
34
4.2.1
Mod´ aln´ı logiky
Z´aklad pro vˇsechny logiky, kter´e budou zm´ınˇeny d´ ale, pˇredstavuj´ı mod´ aln´ı logiky. Mod´aln´ı logiky umoˇzn ˇuj´ı popisovat koncepty jako jsou moˇznost, nemoˇznost ˇci nutnost. Oproti logik´am klasick´ ym pˇrid´avaj´ı do jazyka dva nov´e oper´ atory 2 – oper´ ator nutnosti a 3 – oper´ator moˇznosti. Tyto oper´atory jsou vz´ ajemnˇe du´ aln´ı, tedy 2ϕ ⇔ ¬3(¬ϕ) a naopak. Mod´aln´ı logiky pouˇz´ıvaj´ı odliˇsnou s´emantickou interpretaci neˇz logiky klasick´e. Tato interpretace je zaloˇzena na teorii moˇzn´ych svˇet˚ u [Hin62]. Hlavn´ı myˇslenkou t´eto teorie je, ˇze na rozd´ıl od s´emantiky klasick´e logiky, kde bereme v u ´vahu jen jeden svˇet (ten re´aln´ y) a uvaˇzujeme co je a co nen´ı v tomto svˇetˇe pravda, zde pracujeme s mnoˇzinou virtu´aln´ıch“ svˇet˚ u, pˇriˇcemˇz dan´a formule m˚ uˇze b´ yt v nˇekter´ ych tˇechto svˇetech pravdiv´ a, ” v jin´ ych nikoliv. Tyto svˇety jsou spolu spojeny takzvanou relac´ı pˇr´ıstupnosti, kter´ a urˇcuje, jak spolu jednotliv´e svˇety souvis´ı“. Form´ aln´ı r´ amec pro tyto pojmy se naz´ yv´ a Kripkeho ” struktura, coˇz je ˇctveˇrice M = (S, S0 , R, L), kde S je spoˇcetn´ a mnoˇzina stav˚ u , S0 ⊆ S mnoˇzina poˇc´ateˇcn´ıch stav˚ u, R ⊆ S × S tot´ aln´ı relace, naz´ yvan´ a relace pˇr´ıstupnosti a L : S → 2AP pravdivostn´ı zobrazen´ı (AP je mnoˇzina atomick´ ych v´ yrok˚ u), jeˇz urˇcuje, kter´e atomick´e v´ yroky jsou v jednotliv´ ych stavech pravdiv´e. Pomoc´ı relace R je pak nadefinov´ana s´emantika oper´ator˚ u 2 a 3. Napˇr´ıklad 2ϕ ve stavu (svˇetˇe) S plat´ı, pr´ avˇe kdyˇz formule ϕ plat´ı ve vˇsech stavech, kter´e jsou ze svˇeta S pˇr´ıstupn´e. Mod´aln´ı logiky d´ale zav´ad´ı nov´e odvozovac´ı pravidlo, tzv. pravidlo nutnosti ϕ ⇒ 2ϕ a 5 axiom˚ u: K: 2(ϕ ⇒ ψ) ⇒ 2ϕ ⇒ 2ψ T: 2ϕ ⇒ ϕ D: 2ϕ ⇒ 3ϕ 4: 2ϕ ⇒ 22ϕ 5: 2ϕ ⇒ 23ϕ Tyto axiomy odpov´ıdaj´ı v s´emantick´e str´ ance r˚ uzn´ ym vlastnostem relace pˇr´ıstupnosti, napˇr´ıklad axiom 4 odpov´ıd´a tranzitivitˇe R. Podle toho, kter´e axiomy jsou pouˇzity, dost´ av´ame r˚ uzn´e varianty mod´aln´ıch logik. Za z´ akladn´ı b´ yv´ a povaˇzov´ ana mod´ aln´ı logika zaloˇzen´ a na axiomech K a T. V´ yborn´ yu ´vod do problematiky mod´ aln´ıch logik poskytuje kniha prof. Peregr´ına [Per04].
4.2.2
Tempor´ aln´ı logiky
Z logik mod´aln´ıch vych´azej´ı logiky tempor´ aln´ı. Tempor´ aln´ı logiky zav´ ad´ı sadu oper´ ator˚ u, kter´e vymezuj´ı platnost formul´ı s ohledem na ˇcas. Nejzn´ amˇejˇs´ı jsou zˇrejmˇe logiky LTL (Linear Temporal Logic) a CTL/CTL* (Computational Tree Logic). Zat´ımco LTL pracuje s line´ arn´ım ˇcasem, CTL a CTL* umoˇzn ˇuj´ı vˇetven´ı ˇcasu v budoucnosti. S´emantika tˇechto logik je opˇet d´ana Kripkeho strukturou – relace R je zde ch´ ap´ ana jako vyj´ adˇren´ı ˇcasov´e posloupnosti jednotliv´ ych stav˚ u, kter´e tak tvoˇr´ı takzvan´e cesty“. ” Logika CTL zav´ad´ı n´asleduj´ıc´ı oper´ atory (s neform´ aln´ım popisem s´emantiky): • Oper´atory cesty: – A ϕ – All: ϕ mus´ı platit na vˇsech cest´ ach, kter´e vych´ azej´ı ze souˇcasn´eho stavu. 35
– E ϕ – Exists: ϕ plat´ı alespoˇ n na jedn´e cestˇe vych´ azej´ıc´ı ze souˇcasn´eho stavu. • Oper´atory stavu: – N ϕ – Next: ϕ mus´ı platit v n´ asleduj´ıc´ım stavu. – G ϕ – Globally: ϕ mus´ı platit v cel´e cestˇe vych´ azej´ıc´ı ze souˇcasn´eho stavu. – F ϕ – Finally: ϕ mus´ı platit v nˇejak´em stavu nach´ azej´ıc´ım se na cestˇe vych´ azej´ıc´ı ze souˇcasn´eho stavu. – ϕ U ψ – Until: ϕ mus´ı platit, dokud v nˇejak´em stavu nebude platit ψ. – ϕ W ψ – Weak until ϕ mus´ı platit, dokud v nˇejak´em stavu nebude platit ψ, pˇriˇcemˇz toto na rozd´ıl od pˇredchoz´ıho pˇr´ıpadu nemus´ı nastat. Rozd´ıl mezi logikami CTL a CTL* spoˇc´ıv´ a v tom, ˇze v logice CTL se mus´ı dohromady nach´azet vˇzdy dvojice oper´ ator˚ u: jeden oper´ ator cesty n´ asledov´ an oper´ atorem stavu, zat´ımco v CTL* toto omezen´ı neplat´ı. Mezi CTL* a CTL i LTL plat´ı vztah CTL ⊂ CTL* a LTL ⊂ CTL*, LTL s CTL maj´ı spoleˇcn´ y pr˚ unik, avˇsak neplat´ı, ˇze by jedna byla podmnoˇzinou druh´e. Podrobnˇeji se o tempor´ aln´ıch logik´ ach zmiˇ nuje napˇr´ıklad [Zbo04].
4.2.3
BDI CTL logika
Logika BDI CTL vych´az´ı z logiky CTL* . K jej´ımu jazyku pˇrid´ av´ a tˇri mod´ aln´ı oper´ atory: Bel, Des a Int. S´emantika vych´az´ı opˇet z Kripkeho struktury, ale tentokr´ at se jedn´ a o sedmici M = (W, (Sw , w ∈ W ), (Rw , w ∈ W ), L, B, D, I), kde W je mnoˇzina svˇet˚ u, Sw stavy svˇeta w, Rw relace mezi stavy svˇeta w, L ohodnocen´ı atomick´ ych formul´ı v kaˇzd´em stavu kaˇzd´eho svˇeta a B, D, I jsou relace mezi svˇety z mnoˇziny W : B ⊆ W ×W , D ⊆ W ×W , I ⊆ W ×W . Oproti pˇredchoz´ım logik´am, kde byla pouze jedna mnoˇzina stav˚ u S a jedna relace R, zde je jich cel´a ˇrada pro kaˇzd´ y ze svˇet˚ u w ∈ W. S´emantika oper´ator˚ u Bel, Des a Int je pak pro formuli f, svˇety v, w ∈ W a jejich stavy sw , sv definov´ana takto: M, sw |= Belf ⇐⇒ ∀v, (v, w) ∈ B : M, sv |= f M, sw |= Desf ⇐⇒ ∀v, (v, w) ∈ D : M, sv |= f M, sw |= Intf ⇐⇒ ∀v, (v, w) ∈ I : M, sv |= f Tedy aby platila formule Belf , mus´ı platit formule f pro stavy sv vˇsech svˇet˚ u v, kter´e jsou se svˇetem w v relaci B (obdobnˇe pro zbyl´e dva oper´ atory). Axiomatika t´eto logiky je pomˇernˇe rozs´ahl´a, je moˇzn´e ji nal´ezt napˇr´ıklad v [Zbo04]. Na to, jak´ y by mˇel b´ yt vztah mezi jednotliv´ ymi modalitami, neexistuje jednotn´ y n´ azor. Jednotliv´e pˇr´ıstupy se naz´ yvaj´ı realismy. Tˇri nejˇcastˇeji uv´ adˇen´e realismy jsou: • siln´y realismus, kde plat´ı B ⊆ D ⊆ I, • realismus, kde I ⊆ D ⊆ B, a koneˇcnˇe • slab´y realismus, kde B ∩ D 6= ∅, B ∩ I 6= ∅, D ∩ I 6= ∅ a d´ ale plat´ı Intf → ¬Des¬f , Intf → ¬Bel¬f a Desf → ¬Bel¬f . Z tˇechto realism˚ u vypl´ yv´a, jak´e chov´ an´ı agent vykazuje. V siln´em realismu peˇclivˇe vych´az´ı jen z toho, co je v dan´em okamˇziku platn´e (pˇr´ an´ı jsou podmnoˇzinou pˇredstav), v realismu je tomu naopak. Slab´ y realismus definuje vztah tˇechto modalit volnˇeji, pouze pˇredpokl´ad´a jejich nepr´azdn´ y pr˚ unik a ud´ av´ a pravidla, kter´e by mˇela pro vztah mezi modalitami platit. 36
4.3
Realizace architektury BDI
Implementovat agenta pˇresnˇe podle v´ yˇse uveden´e teorie je pomˇernˇe obt´ıˇzn´e a ve skuteˇcnosti neexistuje ˇz´adn´a funkˇcn´ı aplikace, kter´ a by to takto dˇelala. Jedin´ ym n´ aznakem je st´ ale abstraktn´ı model interpretu BDI agenta, kterou prezentovali autoˇri BDI CTL logiky Rao a Georgeff v [RG92]. Ostatn´ı implementace BDI syst´em˚ u souvis´ı s touto teori´ı pomˇernˇe volnˇe, principy jejich pˇr´ıstupu si postupnˇe struˇcnˇe pˇredstav´ıme.
4.3.1
Abstraktn´ı interpret BDI agenta
Abstraktn´ı model interpretu BDI agenta mˇel pˇrispˇet k posunu od teorie k praktick´ ym aplikac´ım. R˚ uzn´ı autoˇri uv´adˇej´ı m´ırnˇe odliˇsn´e varianty p˚ uvodn´ıho algoritmu, ta kter´ a je zde prezentov´ana, byla pˇrevzata z publikace [Kub04]. Interpret po inicializaci pracuje v nekoneˇcn´e smyˇcce, kdy prov´ad´ı reakce na ud´ alosti, kter´e v jeho okol´ı nastaly. Cel´ y algoritmus vypad´a takto: Bel = Bel0 // inicializace pˇ redstav Int = Int0 // inicializace z´ amˇ er˚ u While (true) do Events = percept() // pˇ rijmi nov´ e ud´ alosti z prostˇ red´ ı Bel = updateBeliefs(Bel, Events) // aktualizuj pˇ redstavy Goal = options(Bel, Int) // vyber nesplnˇ en´ e dosaˇ ziteln´ e c´ ıle Int = filter(Bel, Goal, Int) // na z´ akladˇ e tˇ echto c´ ıl˚ u pˇ rijmi z´ amˇ er Plan = plan(Bel, Int) // sestav pl´ an pro dosaˇ zen´ ı tohoto z´ amˇ eru execute(Plan) // vykonej pl´ an Int = dropSuccessful() // odstraˇ n splnˇ en´ e z´ amˇ ery Int = dropImpossible() // odstraˇ n nesplniteln´ e z´ amˇ ery
4.3.2
IRMA
IRMA (Intelligent Resource-bounded Machine Architecture) [BIP91] pˇredstavuje jednu z prvn´ıch realizac´ı architektury BDI. Na jej´ım n´ avrhu se pˇr´ımo pod´ılel prof. Bratman, architektura tak vych´az´ı pomˇernˇe pˇresnˇe z jeho teoretick´ ych u ´vah. Konceptu´ aln´ı sch´ema j´adra syst´emu zn´azorˇ nuje obr´azek 4.1. Na obr´ azku jsou datov´e struktury vyznaˇceny elipsami, procesy obd´eln´ıky. Je tedy patrn´e, ˇze hlavn´ı koncepty teorie BDI, tedy pˇredevˇs´ım jednotliv´e modality, byly pˇrevedeny na datov´e struktury. Dalˇs´ı kl´ıˇcov´e komponenty jsou: • Modul pl´ anov´ an´ı (means ends reasoner), kter´ y nab´ız´ı moˇznosti, jak dos´ ahnout agentov´ ych c´ıl˚ u. Konkr´etnˇeji, vyb´ır´ a ˇsablony pl´ an˚ u z knihovny pl´ an˚ u a doplˇ nuje je o unifikace promˇenn´ ych a podc´ıl˚ u pro dosaˇzen´ı aktu´ aln´ıch c´ıl˚ u. Takto konkretizovan´e pl´any pˇred´av´a jako moˇznosti do filtrovac´ıho mechanismu • Analyz´ ator pˇr´ıleˇzitost´ı (oportunity analyser), jeˇz pˇrij´ım´ a podnˇety ze senzor˚ u a navrhuje moˇznosti, kter´e nastaly v d˚ usledku zmˇeny prostˇred´ı. • Filtrovac´ı mechanismus, kter´ y pˇrij´ım´ a moˇznosti z obou v´ yˇse zm´ınˇen´ ych modul˚ u a vyb´ır´a z nich ty, kter´e jsou kompatibiln´ı s agentov´ ymi z´ amˇery (z´ amˇery zde odpov´ıdaj´ı pl´an˚ um, jeˇz agent pr´avˇe prov´ ad´ı). Toto filtrov´ an´ı mus´ı b´ yt v´ ypoˇcetnˇe efektivn´ı, protoˇze jeho hlavn´ım c´ılem je zrychlit a zefektivnit pr´ aci modulu zvaˇzov´ an´ı. Souˇc´ ast´ı tohoto
37
mechanismu mohou b´ yt pravidla, kter´ a propust´ı i moˇznosti, kter´e by jinak pˇres filtry neproˇsly (anulace filtru) – tento pˇr´ıstup umoˇzn ˇuje ˇreˇsit r˚ uzn´e aplikaˇcnˇe specifick´e v´ yjimky. • Modul zvaˇzov´ an´ı (deliberation unit), kter´ y z moˇznost´ı, jeˇz proˇsly filtry, vyb´ır´ a nov´e z´amˇery, popˇr´ıpadˇe upravuje st´ avaj´ıc´ı pl´ any na z´ akladˇe nov´ ych skuteˇcnost´ı. • Odvozovac´ı stroj (reasoner), kter´ y m´ a na starosti odvozov´ an´ı nov´ ych poznatk˚ u z agentov´ ych pˇredstav.
Obr´azek 4.1: Sch´ema architektury IRMA Z popisu jednotliv´ ych komponent je snad zˇrejm´e, jak syst´em na glob´ aln´ı u ´rovni funguje. Probl´emem vˇsak je vyv´aˇzen´ı spolupr´ ace jednotliv´ ych komponent, tedy zejm´ena jak ˇcasto prov´adˇet zvaˇzov´an´ı a pˇrepl´anov´ an´ı. Existuj´ı dva krajn´ı pˇr´ıstupy – opatrn´y (cautious) agent bude pˇrehodnocovat sv´e z´amˇery jiˇz pˇri relativnˇe mal´ ych zmˇen´ ach prostˇred´ı, zat´ımco odhodlan´y (bold) agent setrv´a ve vykon´ av´ an´ı zvolen´eho pl´ anu, dokud to jen bude moˇzn´e. V prvn´ım pˇr´ıpadˇe agent ˇcasto zbyteˇcnˇe zvaˇzuje alternativy a v´ ahavost spojen´ a s ˇcast´ ym mˇenˇen´ım pl´anu m˚ uˇze m´ıt negativn´ı vliv na efektivitu jeho chov´ an´ı, stejnˇe jako ve druh´em pˇr´ıpadˇe trvan´ı na zvolen´em pl´anu i v situac´ıch, kdy je pl´ an odsouzen k ne´ uspˇechu. Optim´aln´ı strategie leˇz´ı zˇrejmˇe mezi tˇemito dvˇema krajn´ımi pˇr´ıpady, avˇsak vhodn´ a m´ıra opatrnosti“ ” se liˇs´ı podle prostˇred´ı a aplikace.
4.3.3
PRS
Architektura PRS (Procedural Reasoning System) [GL87], [GI89] je v dneˇsn´ı dobˇe st´ ale zˇrejmˇe nejzn´amˇejˇs´ı implementac´ı BDI princip˚ u a stala se z´ akladem pro celou ˇradu dalˇs´ıch syst´em˚ u. N´azev t´eto architektury se snaˇz´ı vyzdvihnout fakt, ˇze znalosti postup˚ u pro dosaˇzen´ı c´ıl˚ u jsou uloˇzeny v procedur´ aln´ı formˇe (tedy v pl´ anech). Tyto struktury vˇsak autoˇri nenaz´ yvaj´ı pl´any – v p˚ uvodn´ıch ˇcl´ anc´ıch je naz´ yvaj´ı oblasti znalost´ı (knowledge areas – KA), v pozdˇejˇs´ı literatuˇre pak akty (acts). 38
Sch´ema architektury PRS ukazuje obr´ azek 4.2. J´ adro syst´emu se skl´ ad´ a z pˇeti komponent – ˇctyˇri hlavn´ı datov´e struktury odpov´ıdaj´ı jednotliv´ ym mod´ aln´ım oper´ ator˚ um plus akty (pl´any); interpret ˇr´ıd´ı chov´an´ı cel´eho syst´emu. Z datov´ ych struktur jsou zˇrejmˇe nejzaj´ımavˇejˇs´ı akty. Skl´adaj´ı se z hlaviˇcky, kde jsou definov´ any podm´ınky, kter´e mus´ı platit pro jejich spuˇstˇen´ı; a tˇela, kter´e m´ a formu grafu. V tomto grafu se kromˇe jednotliv´ ych akc´ı mohou vyskytovat tak´e podc´ıle, alternativy, cykly, rekurze a nˇekolik koncov´ ych stav˚ u znamenaj´ıc´ıch u ´spˇech ˇci ne´ uspˇech.
Obr´azek 4.2: Sch´ema architektury PRS Pˇredstavy jsou vyj´adˇreny pomoc´ı formul´ı predik´ atov´e logiky prvn´ıho ˇr´ adu. PRS rozliˇsuje tˇri typy tuˇzeb (c´ıl˚ u) – k jejich znaˇcen´ı se pouˇz´ıv´ a oper´ ator˚ u ! ? a #. V´ yraz (! p), kde p je popis nˇejak´eho stavu, znaˇc´ı c´ıl dos´ ahni, aby p platilo“, (? p) znamen´ a otestuj, zda ” ” p plat´ı“ a koneˇcnˇe (# p) udrˇzuj stav syst´emu takov´ y, aby p platilo“. Z´ amˇery jsou repre” zentov´any jako struktury, kter´e obsahuj´ı p˚ uvodn´ı akt a d´ ale vˇsechny akty, kter´e vznikly pˇri vykon´av´an´ı tohoto aktu. Autoˇri uv´ adˇej´ı, ˇze tyto z´ amˇery odpov´ıdaj´ı proces˚ um v bˇeˇzn´em syst´emu. Vˇsechny z´amˇery, kter´e se agent rozhodl realizovat jsou uchov´ av´ any v tzv. struktuˇre z´amˇer˚ u, coˇz je mnoˇzina, nad kterou je definov´ ano ˇc´ asteˇcnˇe uspoˇr´ ad´ an´ı, kter´e urˇcuje priority a poˇrad´ı vykon´av´an´ı jednotliv´ ych z´ amˇer˚ u. Chov´an´ı syst´emu je urˇceno smyˇckou interpretu, kterou zn´ azorˇ nuje obr´ azek 4.3. Jak je vidˇet, interpret pracuje v nekoneˇcn´em cyklu, pˇriˇcemˇz kaˇzd´ a smyˇcka se skl´ ad´ a z osmi krok˚ u: 1. Do syst´emu doraz´ı nov´e pˇredstavy a c´ıle. 2. Tato zmˇena m˚ uˇze spustit nˇekter´e akty z knihovny akt˚ u. 3. Nˇekter´e z tˇechto akt˚ u mohou b´ yt vybr´ any a pˇrid´ any do grafu z´ amˇer˚ u. 4. Z grafu z´amˇer˚ u je vybr´an akt k interpretaci. 5. Ten je aktivov´an. 6. Z tohoto aktu je vykon´an jeden krok, kter´ y m˚ uˇze ovlivnit prostˇred´ı. 7. Tato zmˇena m˚ uˇze vyvolat nov´e pˇredstavy a c´ıle. 8. Tak´e m˚ uˇze doj´ıt k u ´pravˇe z´ amˇer˚ u. 39
Obr´azek 4.3: Sch´ema chov´ an´ı interpretu PRS
Krok 3 b´ yv´a naz´ yv´an meta-pl´ anov´ an´ı. Jeho c´ılem je pro danou ud´ alost vybrat z mnoˇziny aplikovateln´ ych akt˚ u ty, kter´e budou opravdu vykon´ av´ any. Meta-pl´ anov´ an´ı m˚ uˇze b´ yt v nejjednoduˇsˇs´ım pˇr´ıpadˇe implementov´ ano jako vybr´ an´ı prvn´ıho ˇci n´ ahodn´eho aplikovateln´eho aktu, pˇr´ıpadnˇe mohou b´ yt jednotliv´ ym akt˚ um pˇriˇrazeny fixn´ı priority. Nejkomplexnˇejˇs´ı variantu pˇredstavuje spuˇstˇen´ı meta-pl´ anu, kter´ y optim´ aln´ı akt vybere dynamicky podle okolnost´ı. P˚ uvodn´ı PRS byl implementov´ an v jazyku LISP, pozdˇeji byla na jeho z´ akladˇe vytvoˇrena cel´a ˇrada dalˇs´ıch verz´ı, o nichˇz se struˇcnˇe zm´ın´ıme v n´ asleduj´ıc´ı ˇc´ asti.
4.3.4
Syst´ emy vych´ azej´ıc´ı z PRS
UM PRS, JAM UM-PRS (University of Michigan PRS) [LHDK94] pˇredstavuje pˇr´ımoˇcarou reimplementaci origin´aln´ıho PRS v jazyce C++. Od origin´ aln´ıho PRS se liˇs´ı pˇredevˇs´ım jazykem pouˇzit´ ym pro reprezentaci oblast´ı znalost´ı a podporou pro integraci s existuj´ıc´ım neagentn´ım softwarem (UM-PRS pak pˇredstavuje v takov´em syst´emu ˇr´ıd´ıc´ı nadstavbu). Pouˇzit byl zejm´ena v oblasti ˇr´ızen´ı robot˚ u, konkr´etnˇe re´ aln´ ych autonomn´ıch ter´enn´ıch vozidel. Na UM-PRS nav´azal syst´em JAM [Hub99], kter´ y koncepˇcnˇe z UM-PRS vych´ az´ı a pˇrid´av´a celou ˇradu dalˇs´ıch vlastnost´ı – zejm´ena zabudovanou moˇznost komunikace s ostatn´ımi agenty a migrace agent˚ u po s´ıti. JAM byl implementov´ an v jazyce Java, coˇz umoˇzn ˇuje snadnou integraci s existuj´ıc´ım softwarem v tomto jazyce pomoc´ı jeho reflektivn´ıch vlastnost´ı. Oba syst´emy jsou pro nekomerˇcn´ı vyuˇzit´ı dostupn´e zdarma vˇcetnˇe zdrojov´ ych k´ od˚ u pod licenc´ı ve stylu GNU.
40
dMARS, JACK Syst´em dMARS (Distributed Multi-Agent Reasoning System) pˇredstavuje pˇr´ım´eho n´ asledovn´ıka architektury PRS. Vytvoˇren byl v Australsk´em institutu pro umˇelou inteligenci (AAII) pod veden´ım prof. Georgeffa, jednoho z hlavn´ıch tv˚ urc˚ u origin´ aln´ıho PRS (b´ yv´ a naz´ yv´an syst´emem druh´e generace PRS“). Byl implementov´ an v jazyku C++ a u ´spˇeˇsnˇe ” nasazen v ˇradˇe pr˚ umyslov´ ych aplikac´ı, z nichˇz asi nejzn´ amˇejˇs´ı je syst´em pro spr´ avu letiˇstˇe s n´azvem OASIS [GR96], kter´ y je ˇcasto uv´ adˇen jako jedna z nejpokroˇcilejˇs´ıch aplikac´ı agentn´ıch syst´em˚ u v˚ ubec. Poskytov´ an byl na komerˇcn´ı b´ azi. Se z´ anikem AAII skonˇcil i projekt dMARS, stal se vˇsak z´akladem pro syst´em JACK. Hlavn´ı vylepˇsen´ı syst´emu dMARS oproti PRS (kromˇe efektivnˇejˇs´ı implementace a cel´e ˇrady podp˚ urn´ ych n´astroj˚ u) se t´ ykalo pl´ an˚ u. Pl´ any (u tohoto syst´emu se jiˇz neoznaˇcovaly jako akty) byly oproti PRS ponˇekud komplexnˇejˇs´ı – skl´ adaly se ze spouˇstˇec´ıch podm´ınek; kontextu pl´anu (seznam pˇredstav, kter´ ym agent mus´ı vˇeˇrit, aby mˇelo proveden´ı pl´anu smysl); tˇela, kter´e mˇelo formu stromu; udrˇzuj´ıc´ıch podm´ınek, kter´e musely platit po celou dobu prov´adˇen´ı pl´anu a seznamu akc´ı, kter´e se maj´ı prov´est v pˇr´ıpadˇe u ´spˇechu, respektive ne´ uspˇechu pl´anu. Na syst´em dMARS nav´azal projekt JACK Agent Language [BRHL99]. Opˇet se jedn´ a o komerˇcn´ı software, vyv´ıj´ı jej firma Agent Oriented Software, do kter´e pˇreˇsla ˇrada v´ yvoj´ aˇr˚ u z AAII. Na rozd´ıl od dMARS pˇredstavuje rozˇs´ıˇren´ı jazyka Java o principy agentovˇe orientovan´eho programov´an´ı: poskytuje b´ azov´e tˇr´ıdy, rozhran´ı a metody, stejnˇe tak jako rozˇs´ıˇren´ı jazyka pro definice a s´emantick´a rozˇs´ıˇren´ı pro zpracov´ an´ı bˇehu agentn´ıho syst´emu. Tvorba agenta tak spoˇc´ıv´a ve zdˇedˇen´ı b´ azov´ ych tˇr´ıd a doplnˇen´ı aplikaˇcnˇe specifick´ ych agentov´ ych schopnost´ı, b´aze pˇredstav, pl´an˚ u a dalˇs´ıch podp˚ urn´ ych komponent. Syst´em poskytuje grafick´e rozhran´ı pro nˇekter´e ˇc´asti n´avrhu, jako je tvorba pl´ an˚ u. Hlavn´ı koncepty – tj. chov´ an´ı interpretu a z´akladn´ı datov´e struktury jsou obdobn´e jako tomu bylo u dMARS (a potaˇzmo PRS). S´emantika syst´emu JACK nen´ı form´ alnˇe definov´ ana (vzhledem k tomu, ˇze se jedn´ a o nadmnoˇzinu jazyka Java, bylo by nutno nejprve formalizovat Javu [Win05]). JACK se zamˇeˇruje pˇredevˇs´ım na ot´azky softwarov´eho inˇzen´ yrstv´ı a nasazen´ı cel´eho syst´emu v praktick´ ych aplikac´ıch. Syst´em v t´eto oblasti zav´ ad´ı oproti dMARS ˇradu rozˇs´ıˇren´ı, napˇr´ıklad zaveden´ı pojmu schopnost (capability), coˇz je prostˇredek pro strukturov´ an´ı agenta (obdoba modul˚ u u bˇeˇzn´eho programov´ an´ı) – kaˇzd´ a schopnost v sobˇe obsahuje c´ıle, pˇredstavy a z´amˇery, agent se pak skl´ad´a z nˇekolika takov´ ych schopnost´ı, pˇriˇcemˇz jednotliv´e schopnosti mohou b´ yt pouˇzity u v´ıce agent˚ u.
4.3.5
JADEX
Oproti pˇredchoz´ım projekt˚ um, kter´e by se daly nazvat klasikou“ v oblasti implemen” tac´ı BDI, JADEX [PBL03] je pomˇernˇe nov´ y a st´ ale velmi aktivn´ı projekt (v´ yvoj zaˇcal v roce 2002). Cel´ y syst´em je postaven na platformˇe JADE [BR01] – middlewaru pro tvorbu agentn´ıch aplikac´ı, kter´ y poskytuje prostˇredky a sluˇzby pro spr´ avu agent˚ u a jejich komunikaci. JADEX k tˇemto prostˇredk˚ um pˇrid´ av´ a BDI nadstavbu. Pˇrev´aˇzn´a ˇc´ast informac´ı o agentovi je v JADEXu uloˇzena v tzv. definiˇcn´ım souboru agenta (Agent Definition File), kter´ y m´ a form´ at XML. Zde se definuj´ı agentovy pˇredstavy, c´ıle, schopnosti a mnoho dalˇs´ıch vlastnost´ı. Jedin´ a ˇc´ ast, kter´ a se vytv´ aˇr´ı oddˇelenˇe jsou tˇela pl´an˚ u – ta jsou uloˇzena ve speci´aln´ıch souborech a jejich obsah se vytv´ aˇr´ı pomoc´ı bˇeˇzn´eho k´odu programovac´ıho jazyka Java.
41
Konceptu´aln´ı model agenta je zobrazen na obr´ azku 4.4 (ten byl vytvoˇren podle ilustrac´ı 1 v online manu´alu ). Jak je vidˇet, architektura nevych´ az´ı pˇr´ımo z PRS, napˇr´ıklad neobsahuje explicitnˇe odliˇsen´e touhy a z´ amˇery. Obˇe tyto kategorie jsou spojeny do c´ıl˚ u a jejich rozliˇsov´an´ı je ˇc´asteˇcnˇe nahrazeno zaveden´ım ˇzivotn´ıho cyklu c´ıl˚ u. JADEX totiˇz vych´ az´ı z myˇslenky, ˇze c´ıle jsou konkr´etn´ı, moment´ aln´ı pˇr´ an´ı agenta. Pro jak´ ykoliv c´ıl agent prov´ ad´ı v´ıce ˇci m´enˇe pˇr´ım´e akce k jeho dosaˇzen´ı aˇz do t´e doby, kdy povaˇzuje c´ıl za splnˇen´ y, nesplniteln´ y anebo nad´ale neˇz´adouc´ı. Na rozd´ıl od vˇetˇsiny BDI syst´em˚ u JADEX nepoˇzaduje, aby ˇ c´ıle byly konzistentn´ı. Zivotn´ ı cyklus c´ıl˚ u obsahuje tˇri hlavn´ı stavy – alternativa (option), aktivn´ı (active) a odloˇzen´ y (suspended). C´ıle mohou b´ yt ˇctyˇr druh˚ u – vykonej (perform), dos´ahni (achieve), otestuj (query) a udrˇzuj (maintain). Stejnˇe jako syst´em JACK obsahuje mechanismus schopnost´ı pro strukturov´ an´ı agenta do modul˚ u. Agent tak obsahuje jeden ˇr´ıd´ıc´ı mechanismus a nˇekolik schopnost´ı, mezi kter´e ˇr´ızen´ı rozdˇeluje pˇr´ıchoz´ı zpr´ avy.
Obr´azek 4.4: Konceptu´ aln´ı model agenta v syst´emu JADEX Reprezentace pˇredstav je velmi jednoduch´ a, v souˇcasn´e dobˇe nepodporuje ˇz´ adnou formu odvozov´an´ı (napˇr´ıklad zaloˇzen´e na logice). Pl´ any se stejnˇe jako u syst´em˚ u zaloˇzen´ ych na PRS skl´adaj´ı z hlaviˇcky a tˇela. Hlaviˇcka je specifikov´ ana v definiˇcn´ım souboru agenta a obsahuje podm´ınky pro spuˇstˇen´ı pl´ anu. Tˇelo je pak tvoˇreno bˇeˇzn´ ym k´ odem jazyka Java, kter´ y m´a za u ´kol dosaˇzen´ı nˇejak´eho c´ıle nebo reakci na nˇejakou ud´ alost. To m´ a jistou nev´ yhodu v tom, ˇze jak´ekoliv ˇr´ıd´ıc´ı elementy mus´ı b´ yt do pl´ anu explicitnˇe zakomponov´any program´atorem – napˇr´ıklad reakce na dosaˇzen´ı ˇci selh´ an´ı podc´ıle apod. Zamˇeˇren´ı syst´emu JADEX je obdobn´e jako u JACK – snahou autor˚ u bylo pˇribl´ıˇzit BDI architekturu co nejv´ıce 1
http://vsis-www.informatik.uni-hamburg.de/projects/jadex/jadex-0.96x/userguide/index.single.html
42
v´ yvoj´aˇr˚ um se zkuˇsenostmi s klasick´ ym softwarov´ ym inˇzen´ yrstv´ım.
4.3.6
Dalˇ s´ı implementace BDI
Tento v´ yˇcet implementac´ı architektury BDI samozˇrejmˇe nen´ı zdaleka u ´pln´ y. Existuje cel´ a ˇrada dalˇs´ıch reimplementac´ı PRS, stejnˇe jako syst´em˚ u, kter´e souvis´ı s BDI sp´ıˇse volnˇe. C´ılem bylo uk´azat principy implementace a klasick´e projekty v t´eto oblasti, kter´e byly zdrojem inspirace a srovn´an´ı s navrˇzen´ ym frameworkem. Dalˇs´ı zaj´ımav´e syst´emy zahrnuj´ı projekty 3APL a 2APL [Das08], Nuin [DW03], COSY [BS92] a GRATE* [Jen93].
4.4
Formalizace syst´ em˚ u zaloˇ zen´ ych na architektuˇ re BDI
Jak bylo uk´az´ano v pˇredchoz´ıch ˇc´ astech, jeden smˇer v´ yvoje realizac´ı BDI architektury se snaˇz´ı pˇribl´ıˇzit pˇr´ıstupy BDI ke klasick´emu softwarov´emu inˇzen´ yrstv´ı a od form´ aln´ı teorie se oproti sv´ ym pˇredch˚ udc˚ um sp´ıˇse vzdaluje. Tento pˇr´ıstup reprezentuj´ı v souˇcasn´e dobˇe pˇredevˇs´ım projekty JACK a JADEX. Existuj´ı vˇsak naopak tak´e projekty, kter´e se snaˇz´ı mezeru mezi teori´ı architektury BDI a jej´ımi praktick´ ymi realizacemi z´ uˇzit. Zˇrejmˇe nejzn´ amˇejˇs´ı prac´ı v t´eto oblasti je jazyk AgentSpeak(L) a form´ aln´ı specifikace nˇekolika syst´em˚ u ve specifikaˇcn´ım jazyce Z. Tˇemto pˇr´ıstup˚ um se budu nyn´ı kr´ atce vˇenovat.
4.4.1
AgentSpeak(L)
Vznik projektu AgentSpeak(L) [Rao96] byl motivov´ an velk´ ymi rozd´ıly mezi p˚ uvodn´ı form´aln´ı teori´ı BDI, ve kter´e jsou pˇredstavy, pˇr´ an´ı a z´ amˇery vyj´ adˇreny jako mod´ aln´ı oper´ atory a implementuj´ıc´ımi syst´emy vych´ azej´ıc´ımi z PRS, kde jsou tyto realizov´ any jako datov´e struktury. Syst´em AgentSpeak(L) m´a dvˇe hlavn´ı komponenty. Prvn´ı z nich pˇredstavuje interpretovan´ y jazyk, kter´ y je zaloˇzen na podmnoˇzinˇe predik´ atov´e logiky obohacen´e o ud´ alosti a akce. Tento jazyk m˚ uˇze b´ yt ch´ ap´ an jako alternativn´ı forma formalizace BDI agenta, pˇriˇcemˇz s´emantika jazyka zachycuje pr´ avˇe hlavn´ı rysy syst´em˚ u PRS a dMARS. Operaˇcn´ı s´emantika tohoto jazyka je formalizov´ ana pomoc´ı pˇrechodov´eho syst´emu. Pˇredstavy jsou stejnˇe jako u PRS a dMARS vyj´ adˇreny pomoc´ı formul´ı predik´ atov´e logiky. C´ıle mohou b´ yt podobnˇe jako u dMARS dvou druh˚ u – dosaˇzen´ı a testov´ an´ı platnosti formule. Na rozd´ıl od PRS vˇsak pl´any maj´ı line´arn´ı strukturu a nav´ıc oproti dMARS je znaˇcnˇe zjednoduˇsena jejich hlaviˇcka (ˇz´adn´e udrˇzovac´ı podm´ınky ˇci mnoˇziny akc´ı k proveden´ı po u ´spˇechu, resp. ne´ uspˇechu pl´anu apod.). Druhou komponentu pak tvoˇr´ı interpret tohoto jazyka (resp. pˇresn´ y popis algoritmu, jak m´ a b´ yt tento jazyk interpretov´ an). AgentSpeak(L) tak pˇredstavuje form´ aln´ı popis implementace BDI agenta. Tento popis je vˇsak na pomˇernˇe vysok´e u ´rovni abstrakce – AgentSpeak(L) zachycuje pouze z´akladn´ı rysy, proto byla pozdˇeji r˚ uzn´ ymi autory publikov´ana + ˇrada rozˇs´ıˇren´ı a vylepˇsen´ı, napˇr. [BdOJB 02, MVB03]. Interpret rozˇs´ıˇren´e verze jazyka AgentSpeak(L) byl pozdˇeji realizov´ an v jazyce Java projektem Jason [BH05]. Hlavn´ı rozˇs´ıˇren´ı se t´ yk´ a moˇznosti komunikace agent˚ u pomoc´ı jazyka zaloˇzen´em na ˇreˇcov´ ych aktech. Jason tedy umoˇzn ˇuje vyj´ adˇrit rozhodovac´ı proces agenta ve form´alnˇe definovan´em jazyce. Napojen´ı na okol´ı je provedeno pomoc´ı vol´ an´ı primitivn´ıch akc´ı, kter´e m˚ uˇze program´ator vytvoˇrit v jazyce Java.
43
4.4.2
Form´ aln´ı specifikace dMars a 3APL
Dalˇs´ım pˇr´ıstupem k formalizaci architektur BDI agent˚ u je pouˇzit´ı specifikaˇcn´ıho jazyka Z [Bow96]. T´ımto zp˚ usobem bylo pops´ ano vysoko´ urovˇ nov´e chov´ an´ı syst´emu 3APL [dHL00] a dMARS [dLG+ 04]. Tato formalizace umoˇzn ˇuje jasnˇe definovat chov´ an´ı jednotliv´ ych syst´em˚ u, pˇr´ıpadnˇe jednotliv´e syst´emy porovn´ avat, nicm´enˇe nen´ı pˇr´ımo provediteln´ a.
44
Kapitola 5
Modelov´ an´ı BDI agent˚ u objektovˇ e orientovan´ ymi Petriho s´ıtˇ emi C´ılem pˇredchoz´ıch kapitol bylo uk´ azat souˇcasn´ y stav v´ yzkumu v oblasti multiagentn´ıch syst´em˚ u, se zamˇeˇren´ım na vnitˇrn´ı architektury agent˚ u, zejm´ena architekturu BDI, ze kter´eho vypl´ yvaj´ı hlavn´ı teoretick´a v´ ychodiska pro v´ yzkum prezentovan´ y v t´eto pr´ aci. Tato kapitola popisuje hlavn´ı pˇr´ınos disertaˇcn´ı pr´ ace – framework PNagent, kter´ y umoˇzn ˇuje modelov´an´ı agent˚ u s architekturou BDI objektovˇe orientovan´ ymi Petriho s´ıtˇemi. PNagent byl navrˇzen a prototypovˇe implementov´ an v n´ astroji PNtalk. Koncepce, n´ avrh a aplikace frameworku byly publikov´any na uzn´ avan´ ych vˇedeck´ ych konferenc´ıch [KMZJ07], [MKJZ08b], k recenzi byla odesl´ana takt´eˇz publikace do t´ematicky zamˇeˇren´eho vˇedeck´eho ˇcasopisu [MKJZ08a]. Pˇredt´ım neˇz budou podrobnˇe rozebr´ any jednotliv´e aspekty n´ avrhu frameworku, pokus´ım se shrnout v´ ychodiska, kter´ a z pˇredchoz´ıch kapitol vypl´ yvaj´ı a tedy podrobnˇeji specifikovat c´ıle pr´ace v jejich kontextu.
5.1
Poˇ zadavky, c´ıle, v´ ychodiska
Jak bylo uk´az´ano ve tˇret´ı kapitole, zˇrejmˇe nejperspektivnˇejˇs´ım pˇr´ıstupem ke tvorbˇe vnitˇrn´ı architektury agent˚ u se zdaj´ı b´ yt syst´emy zaloˇzen´e na praktick´em usuzov´ an´ı, pˇr´ıpadnˇe hybridn´ı architektury, kter´e tento syst´em doplˇ nuj´ı o rychl´e reakce na bezprostˇredn´ı podnˇety. ˇ Ctvrt´ a kapitola se zab´ yvala nej´ uspˇeˇsnˇejˇs´ım pˇr´ıstupem k tvorbˇe syst´em˚ u zaloˇzen´ ych na praktick´em usuzov´an´ı – architekturou BDI. Zde jsme vidˇeli, ˇze architektura BDI nen´ı jasnˇe dan´ a specifikace, jak vytvoˇrit vnitˇrn´ı strukturu agenta, sp´ıˇse se jedn´ a o tˇr´ıdu syst´em˚ u, kter´e v´ıce ˇci m´enˇe vych´azej´ı ze z´akladn´ıch koncept˚ u formulovan´ ych filosofem Bratmanem. Nˇekter´e syst´emy se v souˇcasn´e dobˇe snaˇz´ı o pˇribl´ıˇzen´ı se ke klasick´emu softwarov´emu inˇzen´ yrstv´ı, jin´e se naopak pokouˇs´ı d´at implementac´ım form´ aln´ı r´ amec alternativn´ı k p˚ uvodn´ı pˇr´ıliˇs expresivn´ı logice. Jedn´ım z pomˇernˇe ˇcasto diskutovan´ ych t´emat v klasick´em softwarov´em inˇzen´ yrstv´ı je v dneˇsn´ı dobˇe v´ yvoj syst´em˚ u zaloˇzen´ y na modelech (Model Driven Engineering) – napˇr´ıklad ve formˇe xUML (Executable UML) [MB02]. Objektovˇe orientovan´e Petriho s´ıtˇe a n´ astroj PNtalk se snaˇz´ı b´ yt kompatibiln´ı alternativou k tˇemto pˇr´ıstup˚ um, pˇriˇcemˇz si zachov´ av´ a form´aln´ı z´aklad. Navrˇzen´ y framework tak m˚ uˇzeme ch´ apat jako reprezentanta obou dvou aktu´aln´ıch trend˚ u v oblasti v´ yzkumu BDI architektury – jak prakticky pouˇziteln´ y syst´em z pohledu softwarov´eho inˇzen´ yrstv´ı, tak form´ alnˇe definovan´ y syst´em s jasnou specifikac´ı umoˇzn ˇuj´ıc´ı aplikaci form´aln´ıch metod verifikace pˇr´ımo na vysoko´ urovˇ nov´ y popis. Pˇri n´ avrhu
45
frameworku jsem se ˇr´ıdil zejm´ena n´ asleduj´ıc´ımi poˇzadavky: • otevˇrenost – aplikaˇcn´ı program´ ator by mˇel tvoˇrit konkr´etn´ı modely multiagentn´ıch syst´em˚ u stejn´ ymi prostˇredky, jak´ ymi byl vytvoˇren vlastn´ı framework. Hranice mezi frameworkem a aplikacemi by tak nemˇela b´ yt ostr´ a jako napˇr´ıklad ve dˇr´ıve zm´ınˇen´em syst´emu Jason, n´avrh´aˇr by mˇel m´ıt moˇznost snadno pˇrizp˚ usobovat chov´ an´ı frameworku podle potˇreby konkr´etn´ıho modelu. Tento pˇr´ıstup z´ aroveˇ n umoˇzn´ı experimenty se samotnou architekturou BDI. • vizu´ aln´ı reprezentace – syst´em by mˇel poskytovat aplikaˇcn´ımu program´ atorovi pˇrehledn´e grafick´e rozhran´ı pro tvorbu cel´eho syst´emu, na rozd´ıl od vˇetˇsiny existuj´ıc´ıch syst´em˚ u pro tvorbu BDI agent˚ u, kde je tvorba jednotliv´ ych komponent pomˇern´e neintuitivn´ı (napˇr. tvorba akt˚ u pomoc´ı jazyka Lisp v PRS), coˇz vede k nutnosti doplˇ novat syst´em o speci´aln´ı grafick´e n´ astroje, kter´e ˇcin´ı syst´em sloˇzitˇejˇs´ı a omezuj´ı jeho otevˇrenost. • podpora pro v´yvoj syst´em˚ u zaloˇzen´y na modelech – aplikaˇcn´ı program´ ator by mˇel m´ıt moˇznost navrhnout a implementovat jednotliv´e ˇc´ asti struktury agenta na r˚ uzn´ ych u ´rovn´ıch abstrakce. V´ ysledn´ y model by mˇel b´ yt pˇr´ımo provediteln´ y alespoˇ n jako prototyp aplikace, v optim´aln´ım pˇr´ıpadˇe pˇr´ımo jako c´ılov´ a aplikace. • nav´ az´ an´ı na uzn´ avan´e standardy FIPA – vˇsechny ˇc´ asti frameworku, kter´e spadaj´ı do oblast´ı, kter´e byly standardizov´ any organizac´ı FIPA by mˇely b´ yt s tˇemito specifikacemi kompatibiln´ı a alespoˇ n ˇc´ asteˇcnˇe je implementovat. • zachov´ an´ı form´ aln´ıho z´ akladu – pˇresto, ˇze PNtalk poskytuje prostˇredky pro propojen´ı s dalˇs´ımi programovac´ımi paradigmaty, pˇri tvorbˇe frameworku by mˇel b´ yt zachov´ an form´aln´ı r´amec u vˇsech ˇc´ast´ı, kter´e by potenci´ alnˇe mohlo b´ yt potˇreba form´ alnˇe verifikovat.
5.2
Pˇ rehled frameworku PNagent
Framework PNagent poskytuje kolekci tˇr´ıd, kter´e usnadˇ nuj´ı tvorbu agent˚ u s architekturou BDI, schopn´ ych komunikovat pomoc´ı vysoko´ urovˇ nov´eho jazyka pro meziagentn´ı komunikaci (v souˇcasn´em prototypu je podporov´ ana podmnoˇzina jazyka FIPA ACL). Zjednoduˇsen´ y diagram tˇr´ıd cel´eho syst´emu na obr´ azku 5.1 ukazuje nejd˚ uleˇzitˇejˇs´ı tˇr´ıdy frameworku a jejich vztahy. B´azovou tˇr´ıdou pro vˇsechny konkr´etn´ı agenty je ve frameworku tˇr´ıda BDIAgent, kter´ a poskytuje z´akladn´ı abstrakci pro interpret, spolu s podp˚ urn´ ymi strukturami a metodami. Kaˇzd´ y agent obsahuje mnoˇzinu pl´ an˚ u, kter´e jsou rozdˇeleny na ˇsablony (objekty podtˇr´ıd b´azov´e tˇr´ıdy PlanTemplate) a instance (objekty podtˇr´ıd b´ azov´e tˇr´ıdy PlanInstance). Vztah ˇsablon a instanc´ı pl´an˚ u je takov´ y, ˇze ˇsablony poskytuj´ı prostˇredky pro vytv´ aˇren´ı instanc´ı. Instance pl´an˚ u jsou strukturov´any v z´ amˇerech (objekty tˇr´ıdy Intention), kter´e maj´ı podobu z´asobn´ıku. Veˇsker´e zmˇeny v syst´emu se prov´ adˇej´ı pomoc´ı ud´ alost´ı (objekty podtˇr´ıd b´azov´e tˇr´ıdy Event). Nˇekter´e z´akladn´ı ud´ alosti jsou pˇr´ımo souˇc´ ast´ı frameworku (napˇr´ıklad pˇrid´an´ı ˇci odebr´an´ı pˇredstavy, u ´spˇech ˇci selh´ an´ı instance pl´ anu, pˇr´ıjem zpr´ avy apod.). Dalˇs´ı, aplikaˇcnˇe specifick´e ud´alosti mus´ı doplnit aplikaˇcn´ı program´ ator. Speci´ aln´ım druhem ud´alost´ı jsou c´ıle (objekty podtˇr´ıd b´ azov´e tˇr´ıdy Goal ), kter´e se od bˇeˇzn´ ych ud´ alost´ı liˇs´ı t´ım, ˇze jsou perzistentn´ı. 46
Obr´azek 5.1: Zjednoduˇsen´ y diagram tˇr´ıd frameworku PNagent zachycuj´ıc´ı nejd˚ uleˇzitˇejˇs´ı tˇr´ıdy a jejich vztahy
Obr´azek 5.2 ukazuje z´akladn´ı funkˇcnost interpretu agenta – procesy jsou zobrazeny jako obd´eln´ıky, datov´e struktury jako kruhy. Interpret prov´ ad´ı dva hlavn´ı procesy. Prvn´ım je spr´ava ud´alost´ı, kter´a zahrnuje modifikaci b´ aze pˇredstav, tvorbu a spr´ avu ˇzivotn´ıho cyklu instanc´ı pl´an˚ u a tvorbu nov´ ych z´amˇer˚ u. Druh´ ym procesem je pak interpretace z´ amˇer˚ u, kter´ a m´a za n´asledek ovlivˇ nov´an´ı prostˇred´ı a tedy tvorbu dalˇs´ıch ud´ alost´ı. Oba procesy budou podrobnˇe pops´any v ˇc´asti zab´ yvaj´ıc´ı se interpretem.
Obr´azek 5.2: Sch´ema z´akladn´ı funkˇcnosti rozhodovac´ıho j´ adra agenta ve frameworku PNagent
47
Tˇr´ıda CommunicatingAgent pˇredstavuje nadstavbu nad rozhodovac´ım j´ adrem agenta, kter´a pˇrid´av´a zejm´ena prostˇredky pro meziagentn´ı komunikaci pomoc´ı vysoko´ urovˇ nov´eho jazyka, tedy zejm´ena schopnost pˇrij´ımat a odes´ılat zpr´ avy (realizovan´e objekty tˇr´ıdy ACLMessage). Vlastn´ı pˇrenos zpr´av je uskuteˇcn ˇov´ an pomoc´ı platforem (objekty tˇr´ıdy Platform), kter´e pˇredstavuj´ı prostˇred´ı, ve kter´em se agenti nach´ azej´ı. Objekt tˇr´ıdy MAS (Multi Agent System) pak pˇredstavuje cel´ y model, typicky se v nˇem prov´ ad´ı inicializace, pˇr´ıpadnˇe sbˇer statistik, vyhodnocov´an´ı experiment˚ u, apod. Aplikaˇcn´ı program´ator mus´ı pˇri tvorbˇe konkr´etn´ıho modelu ve frameworku PNagent pˇridat alespoˇ n tyto komponenty: b´ azi pˇredstav a metody pro agentovy schopnosti do tˇr´ıdy agenta, extern´ı ud´alosti pro modelovan´e prostˇred´ı a aplikaˇcnˇe specifick´e pl´ any (ˇsablony a instance). V n´asleduj´ıc´ıch sekc´ıch budou jednotliv´e komponenty diskutov´ any podrobnˇeji.
5.3
Reprezentace b´ aze pˇ redstav
Prvn´ı aspekt frameworku, na kter´ y se zamˇeˇr´ıme, je reprezentace agentov´ ych pˇredstav. Tato reprezentace m´a totiˇz, jak uvid´ıme d´ ale, vliv prakticky na vˇsechny dalˇs´ı komponenty syst´emu. Pro n´azornost bude zvolen´ y pˇr´ıstup demonstrov´ an na jednom z klasick´ ych testovac´ıch prostˇred´ı, zvan´em Cleaner world.
5.3.1
Uk´ azkov´ y syst´ em – Cleaner world
Prostˇred´ı Cleaner world je reprezentov´ ano diskr´etn´ı 2D mˇr´ıˇzkou. Na kaˇzd´em z pol´ı se m˚ uˇze nach´azet odpad nebo popelnice. Odpad se objevuje v pr˚ ubˇehu simulace n´ ahodnˇe. V prostˇred´ı se d´ale nach´az´ı autonomn´ı robot (agent), jehoˇz c´ılem je pˇresunout vˇsechen odpad do popelnic. Robot je schopen vykonat tˇri atomick´e extern´ı akce: zvednout odpad, upustit odpad a pˇresunout se na vedlejˇs´ı pol´ıˇcko. Pˇren´ aˇset m˚ uˇze vˇzdy odpad pouze z jednoho pole. Situace m˚ uˇze vypadat napˇr´ıklad jako na obr´ azku 5.3. Zde se na pozici (2,3) nach´az´ı popelnice a na pozic´ıch (4,4) a (5,6) odpadky. Robot se nach´ az´ı na pozici (4,5) a moment´alnˇe pˇren´aˇs´ı odpad.
Obr´azek 5.3: Uk´ azka prostˇred´ı Cleaner world
5.3.2
Tradiˇ cn´ı zp˚ usob reprezentace b´ aze pˇ redstav
Klasick´ y zp˚ usob reprezentace pˇredstav u agent˚ u s architekturou BDI je obdobn´ y pouˇzit´ı fakt˚ u v logick´em programovac´ım jazyce Prolog. Pˇredstavy jsou tedy vyj´ adˇreny jako liter´ aly predik´atov´e logiky prvn´ıho ˇr´adu neobsahuj´ıc´ı promˇenn´e. Za pouˇzit´ı syntaxe Prologu by reprezentace pˇr´ıkladu zm´ınˇen´eho v pˇredchoz´ı podkapitole mohla vypadat napˇr´ıklad takto: 48
wastePosition(5,6). wastePosition(4,4). binPosition(2,3). agentPosition(4,5). carryingWaste. M´ame-li takovouto reprezentaci, m˚ uˇzeme tvoˇrit odvozovac´ı pravidla, kter´ a se dotazuj´ı nad tˇemito fakty. Takov´a pravidla se pak pouˇz´ıvaj´ı pˇri ˇradˇe rozhodovac´ıch proces˚ u uvnitˇr agenta, napˇr´ıklad pˇri posuzov´an´ı relevance urˇcit´eho pl´ anu pˇri v´ yskytu ud´ alosti. Jako pˇr´ıklad takov´eho pravidla v Cleaner worldu uved’me test, zda je agent na stejn´em poli jako popelnice a pˇren´aˇs´ı odpad. V Prologu bychom takov´e pravidlo mohli vyj´ adˇrit napˇr´ıklad takto: canDropWaste :- binPosition(X,Y), agentPosition(X,Y), carryingWaste. Alternativn´ım pˇr´ıstupem k pouˇzit´ı logiky pro b´ azi pˇredstav m˚ uˇze b´ yt napˇr´ıklad ukl´ ad´ an´ı pˇredstav v relaˇcn´ı datab´azi. Pˇredstavy jsou pak vyj´ adˇreny jako relace, k dotazov´ an´ı se pouˇz´ıv´a jazyk SQL. Tento zp˚ usob je zˇrejmˇe m´enˇe flexibiln´ı, zato vˇsak m˚ uˇze dosahovat vˇetˇs´ı v´ ykonnosti d´ıky propracovan´ ym technik´ am optimalizace. Pˇri n´avrhu b´aze znalost´ı je tedy potˇreba zvolit jednak vlastn´ı reprezentaci, kter´a by mˇela poskytovat zejm´ena snadn´ y zp˚ usob ukl´ ad´ an´ı a odeb´ır´ an´ı fakt˚ u, a d´ ale mechanismus umoˇzn ˇuj´ıc´ı efektivn´ı dotazov´ an´ı nad tˇemito fakty. Ot´ azky automatick´eho odvozov´ an´ı nov´ ych znalost´ı z b´aze pˇredstav ˇci revize pˇredstav (napˇr. ˇreˇsen´ı nesouladu mezi obsahem b´aze znalost´ı a informac´ı ze senzor˚ u) jsou obvykle ponech´ any na pˇr´ıpadn´ ych rozˇs´ıˇren´ıch aplikaˇcn´ıch program´ator˚ u.
5.3.3
Reprezentace b´ aze pˇ redstav pomoc´ı prostˇ redk˚ u OOPN
Reprezentaci pˇredstav pomoc´ı logiky je samozˇrejmˇe moˇzn´e pouˇz´ıt i v prostˇred´ı OOPN. Znamenalo by to vˇsak bud’ implementovat odvozovac´ı apar´ at pomoc´ı prostˇredk˚ u Petriho s´ıtˇe ˇci inskripˇcn´ıho jazyka, anebo cel´ y syst´em pr´ ace s reprezentac´ı z OOPN vyjmout a zpracov´avat reprezentaci pˇredstav externˇe, napˇr´ıklad pomoc´ı objektu zapouzdˇruj´ıc´ıho nˇekter´ y existuj´ıc´ı interpret Prologu, dostupn´ y v prostˇred´ı syst´emu Smalltalk. Stejnˇe tak v pˇr´ıpadˇe pouˇzit´ı relaˇcn´ı datab´aze. OOPN vˇsak umoˇzn ˇuj´ı jin´ y pˇr´ıstup k reprezentaci znalost´ı, zaloˇzen´ y pˇr´ımo na dostupn´ ych struktur´ach OOPN. V´ yrazy odpov´ıdaj´ıc´ı fakt˚ um v Prologu se vyj´ adˇr´ı pomoc´ı m´ıst a znaˇcek. Odvozov´an´ı se pak prov´ad´ı pomoc´ı synchronn´ıch port˚ u. Pro kaˇzd´ y typ“ predik´ atu se vy” tvoˇr´ı jedno m´ısto, jak to ukazuje obr´ azek 5.4 pro pˇr´ıklad Cleaner worldu. Znaˇcky pak reprezentuj´ı hodnoty jednotliv´ ych formul´ı (pˇripomeˇ nme, ˇze v OOPN struktura tvaru (x,y) reprezentuje seznam a symbol #e znaˇcku bez specifick´e hodnoty – ˇcernou znaˇcku“). ” Odvozovac´ı pravidla se vyj´adˇr´ı synchronn´ımi porty. Jsou moˇzn´e dva pˇr´ıstupy: bud’ se vytvoˇr´ı jeden synchronn´ı port vyjadˇruj´ıc´ı cel´e pravidlo, jak to ukazuje obr´ azek 5.4, anebo se pro kaˇzd´e m´ısto vytvoˇr´ı synchronn´ı port se stejn´ ym jm´enem, kter´ y umoˇzn ˇuje pouze nav´azat libovolnou znaˇcku z tohoto m´ısta, a tyto porty se pak podle potˇreby spoj´ı s dalˇs´ımi omezuj´ıc´ımi podm´ınkami aˇz ve str´ aˇzi pˇrechodu, jako konjunkce v´ yraz˚ u (obr´ azek 5.5). D˚ uleˇzitou souˇc´ast´ı t´eto reprezentace je test nepˇr´ıtomnosti znaˇcky s urˇcitou hodnotou v m´ıstˇe (odpov´ıdaj´ıc´ı pouˇzit´ı predik´ atu not v jazyce Prolog). Jak jsme vidˇeli ve druh´e kapitole, tento test je obvykle ve vysoko´ urovˇ nov´ ych Petriho s´ıt´ıch probl´em. V jazyce PNtalk byl proto zaveden koncept negativn´ıch predik´ at˚ u, kter´e svou s´emantikou predik´ atu not odpov´ıdaj´ı. 49
Obr´azek 5.4: Reprezentace pˇredstav o prostˇred´ı Cleaner world pomoc´ı OOPN
Obr´azek 5.5: Odvozov´an´ı nad reprezentac´ı prostˇred´ı Cleaner world pomoc´ı skl´ ad´ an´ı synchronn´ıch port˚ u a negativn´ıch predik´ at˚ u ve str´ aˇzi pˇrechodu
Hlavn´ı v´ yhodou tohoto zp˚ usobu reprezentace v kontextu frameworku PNagent, kter´ a nakonec rozhodla o volbˇe tohoto pˇr´ıstupu, je zachov´ an´ı kompaktnosti cel´eho syst´emu – pˇredstavy jsou vyj´adˇreny pomoc´ı stejn´ ych v´ yrazov´ ych prostˇredk˚ u jako zbytek syst´emu. B´aze pˇredstav ve frameworku PNagent tedy vypad´ a tak, ˇze se pro kaˇzd´ y typ pˇredstavy, kter´ y se m´a v b´azi znalost´ı nach´azet, vytvoˇr´ı m´ısto a dvojice predik´ at / negativn´ı predik´ at, kter´e potom mohou b´ yt testov´any v r´ amci pˇrechod˚ u ve vˇsech ostatn´ıch komponent´ ach (pl´anech, ud´alostech, apod.). Pˇr´ıklad ukazuje obr´ azek 5.5. Manipulace se znaˇckami (tedy pˇrid´av´an´ı a odeb´ır´an´ı jednotliv´ ych konkr´etn´ıch predik´ at˚ u) se prov´ ad´ı pomoc´ı metod addBelief a removeBelief, do kter´ ych se pro kaˇzd´ y typ predik´ atu pˇrid´ a speci´ aln´ı pˇrechod, jak to ukazuje pro metodu addBelief obr´ azek 5.6. Tyto metody pak zajiˇst’uj´ı korektn´ı vyvol´ an´ı intern´ıch ud´alost´ı pˇri zmˇenˇe b´aze znalost´ı. B´aze pˇredstav je v souˇcasn´e prototypov´e implementaci um´ıstˇena pˇr´ımo v objektov´e s´ıtˇe tˇr´ıdy BDIAgent. V budoucnosti by u rozs´ ahlejˇs´ıch projekt˚ u mohla b´ yt oddˇelena do samostatn´eho objektu, kter´ y by zpˇr´ıstupˇ noval predik´ aty a negativn´ı predik´ aty pro testov´ an´ı b´aze pˇredstav a metody addBelief a deleteBelief pro jej´ı zmˇeny (vkl´ ad´ an´ı ˇci odstraˇ nov´ an´ı znaˇcek). Pro u ´ˇcely prototypu je vˇsak souˇcasn´ y pˇr´ıstup flexibilnˇejˇs´ı a plnˇe dostaˇcuj´ıc´ı.
50
Obr´azek 5.6: Metoda addBelief, kter´ a slouˇz´ı k pˇrid´ av´ an´ı pˇredstav do b´ aze. Pro kaˇzd´ y typ pˇredstavy ji aplikaˇcn´ı program´ator mus´ı rozˇs´ıˇrit podle sch´ematu uk´ azan´eho pro pˇredstavy wastePosition a binPosition
5.4
Pl´ any
Ve ˇctvrt´e kapitole jsme vidˇeli, ˇze pl´ any hraj´ı v realizac´ıch architektury BDI kl´ıˇcovou roli, protoˇze reprezentuj´ı agentovy procedur´ aln´ı znalosti o tom, jak dosahovat c´ıl˚ u. Typicky jsou vytv´aˇreny aplikaˇcn´ım program´ atorem v dobˇe n´ avrhu aplikace, agent tedy neprov´ ad´ı ˇz´adn´e pl´anov´an´ı v klasick´em smyslu. Pl´ any vˇsak nicm´enˇe mohou b´ yt ne´ uplnˇe specifikovan´e, pˇr´ıpadnˇe obsahovat podc´ıle. Framework PNagent podporuje koncept pl´ an˚ u dvˇema abstraktn´ımi tˇr´ıdami, kter´e poskytuj´ı prostˇredky pro vytv´aˇren´ı instanc´ı pl´ an˚ u, spr´ avu jejich ˇzivotn´ıho cyklu, synchronizaci s dalˇs´ımi pl´any, komunikaci s objektem tˇr´ıdy BDIAgent, atd. Rozdˇelen´ı konceptu pl´ an˚ u do dvou b´azov´ ych tˇr´ıd m´a pˇrev´aˇznˇe technick´e d˚ uvody – objektov´ y model OOPN neposkytuje ˇ ast funkˇcnosti pl´ koncept tˇr´ıdn´ıch metod. C´ anu, kter´ a m´ a na starosti tvorbu konkr´etn´ıch instanc´ı je soustˇredˇena ve tˇr´ıdˇe PlanTemplate, zbytek funkˇcnosti se pak nach´ az´ı ve tˇr´ıdˇe PlanInstance. Objekt tˇr´ıdy PlanTemplate tak vlastnˇe hraje roli tˇr´ıdn´ıch metod tˇr´ıdy PlanInstance. Aplikaˇcn´ı program´ator mus´ı vˇzdy vytvoˇrit dvojici konkr´etn´ıch tˇr´ıd zdˇedˇen´ım tˇechto dvou abstraktn´ıch tˇr´ıd a doplnit do nich konkr´etn´ı funkˇcnost. V pˇr´ıpadˇe tˇr´ıdy PlanTemplate jsou to podm´ınky, pˇri kter´ ych je pl´ an aplikovateln´ y a pˇr´ıpadn´ a aplikaˇcnˇe specifick´ a inicializace instance pl´anu. U tˇr´ıdy PlanInstance je to pak pˇredevˇs´ım vlastn´ı obsah pl´anu (tedy pods´ıt’ definuj´ıc´ı sled akc´ı, podc´ıl˚ u apod.) a pˇr´ıpadnˇe podm´ınky pro zmˇenu stavu pl´anu. Pˇri inicializaci agenta jsou um´ıstˇeny ˇsablony vˇsech pl´ an˚ u (tedy instance podtˇr´ıd tˇr´ıdy PlanTemplate) do speci´aln´ıho m´ısta v objektov´e s´ıti tˇr´ıdy BDIAgent, kter´e hraje roli knihovny pl´ an˚ u. Zde jsou pak ˇsablony pl´ an˚ u testov´ any pˇri interpretaci ud´ alost´ı v syst´emu, ’ kdy se zjiˇst uje, zda je pl´an relevantn´ı pro danou ud´ alost. Pokud se pl´ an vyhodnot´ı jako relevantn´ı a je zvolen z mnoˇziny vˇsech relevantn´ıch pl´ an˚ u, vytvoˇr´ı se jeho instance. Tento proces bude podrobnˇe rozebr´an pozdˇeji spoleˇcnˇe s konceptem ud´ alost´ı.
51
5.4.1
Pˇ rid´ av´ an´ı specifick´ e funkˇ cnosti instance pl´ anu
Objektov´a s´ıt’ tˇr´ıdy PlanInstance obsahuje mimo jin´e tˇri d˚ uleˇzit´ a m´ısta – start, success ´ a failure. Ukolem aplikaˇcn´ıho program´ atora je doplnit mezi tato tˇri m´ısta pˇrechody a m´ısta pro konkr´etn´ı funkˇcnost dan´eho pl´ anu. Kaˇzd´ y pˇrechod by mˇel odpov´ıdat proveden´ı agentovy atomick´e akce nebo vyvol´an´ı podc´ıle. M´ısta slouˇz´ı k uloˇzen´ı stavu instance pl´anu mezi jednotliv´ ymi kroky. Jeden krok pl´ anu by mˇel odpov´ıdat proveden´ı jednoho pˇrechodu, nicm´enˇe framework to nijak nevynucuje, je tedy moˇzn´e prov´est v´ıce pˇrechod˚ u (vˇcetnˇe paraleln´ıch vˇetv´ı, variant ˇci cykl˚ u) jako jeden krok. Framework zde ponech´ av´ a moˇznost pouˇz´ıvat vˇsechny prostˇredky dostupn´e v prostˇred´ı PNtalku. Pˇr´ıklad instance pl´ anu, kter´ a m´a na ’ starosti jednoduch´e odesl´an´ı zpr´avy a ˇcek´ an´ı na odpovˇed ukazuje obr´ azek 5.7. Obr´azek zachycuje pouze aplikaˇcnˇe specifickou ˇc´ ast objektov´e s´ıtˇe instance pl´ anu.
!
Obr´azek 5.7: Uk´azka aplikaˇcnˇe specifick´e ˇc´ asti objektov´e s´ıtˇe instance pl´ anu Typick´a struktura pˇrechodu v pods´ıti realizuj´ıc´ı funkˇcnost instance pl´ anu vypad´ a tak, ˇze ve str´aˇzi se vol´a jako prvn´ı podm´ınka proveditelnosti synchronn´ı port self step: myAgent. 52
Ten m´a dva u ´koly: postrann´ım efektem definuje konec kroku pl´ anu (zmˇenou stavu instance pl´anu, t´ımto mechanismem se podrobnˇe zab´ yv´ a dalˇs´ı podkapitola) a z´ aroveˇ n poskytuje referenci na objekt agenta, kter´a se pak pouˇz´ıv´ a u vˇetˇsiny dalˇs´ıch vol´ an´ı metod a synchronn´ıch port˚ u v r´amci pˇrechodu – jak pro testov´ an´ı b´ aze znalost´ı, tak pro vol´ an´ı agentov´ ych atomick´ ych akc´ı. Ve str´aˇzi pˇrechodu se typicky volaj´ı synchronn´ı porty pˇredstaven´e v podkapitole o reprezentaci b´aze znalost´ı, kter´e omezuj´ı proveditelnost pˇrechodu, pˇr´ıpadnˇe prov´adˇej´ı konkretizaci parametr˚ u pl´ anu. Vol´ an´ı agentov´ ych atomick´ ych akc´ı, pˇr´ıpadnˇe vyvol´av´an´ı podc´ıl˚ u pak prob´ıh´a v tˇele pˇrechodu. Podc´ıl se vyvol´ av´ a vytvoˇren´ım objektu reprezentuj´ıc´ıho pˇr´ısluˇsn´ y c´ıl a zavol´ an´ı metody self postSubgoal: aGoal, kter´ a zajist´ı vˇsechny technick´e detaily (nav´az´an´ı podc´ıle na z´ amˇer, usp´ an´ı instance pl´ anu, probuzen´ı pˇri dosaˇzen´ı tohoto podc´ıle, atd.).
5.4.2
ˇ Zivotn´ ı cyklus instance pl´ anu
Kaˇzd´a instance pl´anu po vytvoˇren´ı projde inicializac´ı a pˇrejde do stavu #ready (pl´ an je pˇripraven k vykon´av´an´ı). Aby mohl b´ yt proveden jeden krok pl´ anu, mus´ı b´ yt stav nastaven na #active. To prov´ad´ı interpret vol´ an´ım metody instance pl´ anu doStep. Konec kroku je urˇcen t´ım, ˇze se ve str´aˇzi pˇrechodu v pods´ıti realizuj´ıc´ı vlastn´ı funkˇcnost pl´ anu zavol´ a synchronn´ı port step: myAgent, kter´ y kromˇe z´ısk´ an´ı reference na agenta nastav´ı stav pl´anu zpˇet na #ready. Vol´an´ı tohoto synchronn´ıho portu tedy odpov´ıd´ a proveden´ı jednoho kroku pl´anu (vˇsechny pˇrechody, kter´e toto vol´ an´ı neobsahuj´ı se provedou v r´ amci jednoho kroku). Mechanismus proveden´ı kroku instance pl´ anu pomoc´ı vol´ an´ı doStep a step: myAgent ukazuje obr´azek 5.8.
Obr´azek 5.8: Mechanismus proveden´ı kroku instance pl´ anu
Kromˇe stav˚ u #ready a #active m˚ uˇze pl´ an ˇcekat na nˇejakou ud´ alost, typicky vykon´ an´ı podpl´ anu, splnˇen´ı podc´ıle nebo pˇr´ıjem zpr´ avy. V tom pˇr´ıpadˇe se nach´ az´ı ve stavu #suspended. K usp´an´ı a vzbuzen´ı pl´anu slouˇz´ı nˇekolik metod, kter´e nastavuj´ı ˇsablony ud´ alost´ı, kter´e mus´ı nastat, aby ke zmˇenˇe stavu doˇslo. Vlastn´ı mechanismus pr´ ace s ud´ alostmi je obdobn´ y 53
jako pˇri vytv´aˇren´ı pl´anu, podrobnˇe bude diskutov´ an v podkapitole zab´ yvaj´ıc´ı se ud´ alostmi. Posledn´ı dva stavy, ve kter´ ych se m˚ uˇze pl´ an nach´ azet, se naz´ yvaj´ı #succeeded a #failed a odpov´ıdaj´ı koncov´ ym stav˚ um pˇri u ´spˇechu, resp. selh´ an´ı pl´ anu. Pˇri pˇrechodu do tˇechto stav˚ u se automaticky volaj´ı metody succeed, resp. fail, kter´e zajiˇst’uj´ı vytvoˇren´ı odpov´ıdaj´ıc´ıch ud´alost´ı. Aplikaˇcn´ı program´ator je m˚ uˇze samozˇrejmˇe pˇredefinovat pro dosaˇzen´ı specifick´e funkˇcnosti. Cel´ y ˇzivotn´ı cyklus instance pl´ anu ukazuje obr´ azek 5.9.
ˇ Obr´azek 5.9: Zivotn´ ı cyklus instance pl´ anu
5.4.3
Priority pl´ an˚ u
Kaˇzd´a ˇsablona i instance pl´anu m´ a definov´ anu svoji prioritu. U ˇsablon m˚ uˇze priorita rozhodovat o tom, kter´ y pl´an bude zvolen pˇri dan´e ud´ alosti; u instanc´ı pak o poˇrad´ı vykon´ av´ an´ı jednotliv´ ych instanc´ı pl´an˚ u v r´amci prov´ adˇen´ı z´ amˇer˚ u. Instance prioritu implicitnˇe z´ısk´ av´ a od ˇsablony pl´anu, v pr˚ ubˇehu vykon´ av´ an´ı instance pl´ anu je moˇzn´e ji programovˇe mˇenit pomoc´ı dvojice metoda / synchronn´ı port priority: aPriority (synchronn´ı port slouˇz´ı k z´ısk´ an´ı hodnoty, metoda pro nastaven´ı). Priority jsou jen jeden ze zp˚ usob˚ u, kter´ y se v r´ amci interpretace agenta k ˇreˇsen´ı moˇznosti aplikace v´ıce pl´ an˚ u pouˇz´ıv´ a, podrobnˇeji se t´ımto t´ematem zab´ yv´a podkapitola Interpret.
5.5
Ud´ alosti
Ud´alosti reprezentuj´ı vˇsechny zmˇeny v syst´emu, kter´e je agent schopen rozpoznat, pˇr´ıpadnˇe zachytit sv´ ymi senzory. Podle m´ısta vzniku se ud´ alosti rozliˇsuj´ı na extern´ı (zmˇeny v agentovˇe prostˇred´ı) a intern´ı (zmˇeny uvnitˇr agenta). Ve frameworku PNagent jsou extern´ı ud´ alosti generov´any objekty tˇr´ıdy Platform, kter´ a modeluje agentovo prostˇred´ı – takov´e ud´ alosti jsou vˇzdy aplikaˇcnˇe specifick´e, a tedy musej´ı b´ yt vytvoˇreny aplikaˇcn´ım program´ atorem. Intern´ı ud´alosti jsou generov´any uvnitˇr agenta a pouˇz´ıvaj´ı se pˇredevˇs´ım pro informov´ an´ı pl´an˚ u o zmˇen´ach b´aze pˇredstav, stavu instanc´ı pl´ an˚ u, nov´ ych c´ılech, apod. Z´akladem pro koncept ud´alost´ı je abstraktn´ı tˇr´ıda Event, kter´ a definuje potˇrebn´ a rozhran´ı, zejm´ena poskytuje synchronn´ı porty pro testov´ an´ı typu ud´ alosti a unifikovatelnosti. Postupem pˇri unifikaci se podrobnˇe zab´ yv´ a n´ asleduj´ıc´ı podkapitola. D´ ale tak´e obsahuje referenci na z´amˇer, kter´a u intern´ıch ud´ alost´ı definuje, kter´ y z´ amˇer ud´ alost vyvolal. U extern´ıch 54
ud´alost´ı je tato vazba vytvoˇrena v pˇr´ıpadˇe, ˇze dojde k vytvoˇren´ı nov´eho z´ amˇeru. Odvozen´e tˇr´ıdy mohou obsahovat voliteln´ y poˇcet m´ıst, kter´e pak nesou informace specifick´e pro tuto ud´alost. Princip reprezentace tˇechto informac´ı je obdobn´ y jako u reprezentace pˇredstav, diskutovan´ y dˇr´ıve. Nejd˚ uleˇzitˇejˇs´ı metody, vztahy a intern´ı ud´ alosti definovan´e pˇr´ımo v r´ amci frameworku ukazuje diagram na obr´ azku 5.10. Jedn´ a se o drobnˇe modifikovan´ y diagram tˇr´ıd (rozˇs´ıˇren´ y o moˇznost vyj´adˇrit synchronn´ı porty). Obd´eln´ık oznaˇcuj´ıc´ı tˇr´ıdu je tedy rozdˇelen na ˇctyˇri ˇc´asti, v horn´ı ˇc´asti je uveden n´ azev tˇr´ıdy, v dalˇs´ı ˇc´ asti jsou atributy (jeˇz v OOPN odpov´ıdaj´ı m´ıst˚ um), tˇret´ı pole obsahuje synchronn´ı porty a koneˇcnˇe spodn´ı ˇc´ ast metody.
"
! ! ! ! ! !
"
Obr´azek 5.10: Modifikovan´ y diagram tˇr´ıd pro ud´ alosti ve frameworku PNagent
5.5.1
Unifikace ud´ alost´ı, spouˇ stˇ en´ı pl´ an˚ u
Dvˇe ud´alosti se ve frameworku PNagent povaˇzuj´ı implicitnˇe za unifikovateln´e, pokud maj´ı stejn´ y typ a obsah jejich aplikaˇcnˇe specifick´ ych m´ıst je unifikovateln´ y. Typ je urˇcen m´ıstem type, zaveden´ ym v b´azov´e tˇr´ıdˇe Event (typicky odpov´ıd´ a n´ azvu konkr´etn´ı tˇr´ıdy ud´ alosti, kterou je vˇsak v souˇcasn´e verzi PNtalku nesnadn´e z´ıskat). Aplikaˇcnˇe specifick´ ymi m´ısty se rozum´ı m´ısta, kter´a obsahuj´ı vlastn´ı popis ud´ alosti – napˇr´ıklad v pˇr´ıpadˇe ud´ alosti reprezentuj´ıc´ı objeven´ı nov´eho odpadu jeho pozici. Tato m´ısta se povaˇzuj´ı za unifikovateln´ a, pokud obsahuj´ı alespoˇ n jednu stejnou hodnotu, nebo je alespoˇ n jedno z tˇechto m´ıst pr´ azdn´e (tato podm´ınka se obvykle zjednoduˇs´ı, protoˇze takov´ ato m´ısta mohou typicky obsahovat pouze jednu znaˇcku). Koncept unifikace ud´alost´ı je pouˇz´ıv´ an pˇri vˇsech zmˇen´ ach stavu instanc´ı pl´ an˚ u. Princip bude uk´az´an na vytv´aˇren´ı instanc´ı; pro usp´ av´ an´ı, probouzen´ı, pˇredˇcasn´e dosaˇzen´ı u ´spˇechu a selh´av´an´ı instanc´ı se liˇs´ı jen n´azvy a um´ıstˇen´ı metod a synchronn´ıch port˚ u. Kaˇzd´a ˇsablona pl´anu obsahuje m´ısto triggeringEventTemplates, do kter´eho aplikaˇcn´ı program´ator vloˇz´ı ˇsablony ud´ alost´ı, jeˇz mohou vyvolat vytvoˇren´ı instance tohoto pl´anu. ˇ Sablona ud´alosti je vlastnˇe bˇeˇzn´ a ud´ alost (tedy objekt pˇr´ısluˇsn´e podtˇr´ıdy tˇr´ıdy Event),
55
kter´a nemus´ı m´ıt ˇz´adn´e znaˇcky v aplikaˇcnˇe specifick´ ych m´ıstech (coˇz odpov´ıd´ a voln´ ym promˇenn´ ym) anebo jich naopak m˚ uˇze m´ıt nˇekolik (coˇz vyjadˇruje alternativy, pro kter´e je pl´an relevantn´ı). Napˇr´ıklad v pˇr´ıpadˇe pl´ anu, kter´ y se m´ a spustit pˇri objeven´ı nov´eho odpadu, by ˇsablona ud´alosti nemˇela v m´ıstˇe reprezentuj´ıc´ım pozici odpadu ˇz´ adnou znaˇcku – byla by unifikovateln´a s jakoukoli konkr´etn´ı ud´ alost´ı objeven´ı odpadu. Testov´an´ı, zda je pl´an pro danou ud´ alost relevantn´ı, sest´ av´ a ze dvou krok˚ u. V prvn´ım kroku se testuje, zda je ud´alost unifikovateln´ a s nˇekterou ze ˇsablon. Pokud ano, vol´ a se synchronn´ı port ˇsablony pl´anu checkContextFor: anEvent, kter´ y m˚ uˇze dotazovat b´ azi znalost´ı a vyj´adˇrit tak dalˇs´ı omezen´ı pro relevanci pl´ anu. Synchronn´ı porty zapojen´e do unifikace ud´alost´ı pˇri spouˇstˇen´ı pl´anu ukazuje obr´ azek 5.11. Zde se jedn´ a o ud´ alost pˇrid´ an´ı pˇredstavy do b´aze znalost´ı, kter´a je implementovan´ a samotn´ ym frameworkem. U aplikaˇcnˇe specifick´ ych ud´alost´ı mus´ı synchronn´ı port unifiesWith: anEvent implementovat aplikaˇcn´ı program´ator, pˇritom m´a moˇznost koncept unifikace konkr´etn´ıch ud´ alost´ı upravit podle potˇreby. )
$ % &'(
!"!
$ % !" & '(!
!"
! #"# #
#"
! $ % # & '(#
#
" % $ %& $ %& $ %&
) " %
&&&&&&&&&&&&&&&
*%*+,!
Obr´azek 5.11: Uk´azka principu unifikace ud´ alost´ı pˇri vytv´ aˇren´ı instance pl´ anu (implementace unifikace zde pˇredpokl´ad´ a nejv´ yˇse jednu znaˇcku v aplikaˇcnˇe specifick´ ych m´ıstech ud´alosti)
56
5.5.2
C´ıle
C´ıle jsou ve frameworku povaˇzov´ any za speci´ aln´ı ud´ alosti, kter´e se odliˇsuj´ı od ostatn´ıch ud´alosti v tom, ˇze jsou perzistentn´ı. Jak bude uk´ az´ ano pozdˇeji v podkapitole o interpretaci, standardn´ı ud´alost je zpracov´ ana jedn´ım cyklem interpretu, pˇri kter´em m˚ uˇze, ale tak´e nemus´ı vyvolat vytvoˇren´ı instance pl´ anu (pˇr´ıpadnˇe zmˇenit stav nˇekter´ ych existuj´ıc´ıch instanc´ı), a pot´e ze syst´emu odch´ az´ı. C´ıle naproti tomu v syst´emu z˚ ust´ avaj´ı, dokud nejsou splnˇeny nebo odloˇzeny. Splnˇen´ı c´ıle je testov´ ano synchronn´ım portem satisfied. Framework nerozliˇsuje mezi typy c´ıl˚ u (napˇr´ıklad c´ıle dosaˇzen´ı, udrˇzen´ı, apod.), typ c´ıle je urˇcen implementac´ı portu satisfied, kde je ponech´ ana volnost aplikaˇcn´ımu program´ atorovi. Pˇri rozhodov´ an´ı o pouˇzit´ı c´ıle nebo bˇeˇzn´e ud´ alosti by se mˇel aplikaˇcn´ı program´ ator ˇr´ıdit t´ım, ˇze ud´alosti odpov´ıdaj´ı reaktivn´ımu chov´ an´ı (agent reaguje na zmˇeny v prostˇred´ı), zat´ımco c´ıle proaktivn´ımu (agent se snaˇz´ı nˇeˇceho dos´ ahnout ze sv´e iniciativy). C´ıle tedy b´ yvaj´ı obvykle intern´ı (vyvolan´e existuj´ıc´ımi instancemi pl´ an˚ u).
5.6
Z´ amˇ ery
Z´amˇery jsou ve frameworku PNagent realizov´ any jako z´ asobn´ıky instanc´ı pl´ an˚ u. Kaˇzd´ a extern´ı ud´alost nebo c´ıl, pro kterou byl nalezen nˇejak´ y aplikovateln´ y pl´ an, vede k vytvoˇren´ı nov´eho z´amˇeru z´aroveˇ n s instanc´ı tohoto pl´ anu. Vˇsechny dalˇs´ı pˇr´ıpadn´e podpl´ any tohoto pl´anu jsou pak vkl´ad´any do tohoto z´ amˇeru. Pokud je instance pl´ anu na vrcholu z´ asobn´ıku provediteln´a (je ve stavu #ready), z´ amˇer m˚ uˇze b´ yt vykon´ an jako celek. Po dokonˇcen´ı instance pl´anu na vrcholu z´asobn´ıku je tato instance odstranˇena a je vzbuzena instance bezprostˇrednˇe pod n´ı (kter´a ji vyvolala). Po dokonˇcen´ı vˇsech pl´ an˚ u v z´ asobn´ıku je cel´ y z´ amˇer odstranˇen. Ud´alosti mohou paralelnˇe k tomuto mechanismu mˇenit stav vˇsech pl´ an˚ u v z´ asobn´ıku, tedy je moˇzn´e, ˇze nˇekter´ y pl´an v z´ asobn´ıku se stane neadekv´ atn´ım (selˇze). Pak jsou vˇsechny jeho podpl´any ze z´asobn´ıku odstranˇeny a hled´ a se alternativn´ı ˇreˇsen´ı (vyvol´ an´ım ud´ alosti ˇci znovuzasl´an´ım c´ıle). Z´amˇery mohou m´ıt pˇriˇrazeny priority, kter´e pˇredstavuj´ı jeden z implementovan´ ych mechanism˚ u v´ ybˇeru z´amˇer˚ u pro prov´ adˇen´ı. Tuto prioritu pˇreb´ıraj´ı automaticky od instance pl´anu, kter´a vedla ke vzniku z´amˇeru. Priorita m˚ uˇze b´ yt stejnˇe jako u instanc´ı pl´ an˚ u pr˚ ubˇeˇznˇe programovˇe upravov´ana.
5.7
Interpret
Interpret je implementov´an objektovou s´ıt´ı tˇr´ıdy BDIAgent. Tato abstraktn´ı tˇr´ıda slouˇz´ı jako b´azov´a tˇr´ıda pro vˇsechny agenty vytv´ aˇren´e ve frameworku PNagent. Poskytuje vˇsechny spoleˇcn´e struktury a metody. Konkr´etn´ı tˇr´ıdy agent˚ u k n´ı pˇrid´ avaj´ı aplikaˇcnˇe specifick´e ˇc´asti, tedy zejm´ena m´ısta a synchronn´ı porty pro b´ azi pˇredstav a metody, kter´e reprezentuj´ı agentovy extern´ı akce. ˇ ast objektov´e s´ıtˇe tˇr´ıdy BDIagent realizuj´ıc´ı chov´ C´ an´ı interpretu je zn´ azornˇena na obr´azku 5.12. Zˇrejmˇe nejvˇetˇs´ım rozd´ılem oproti klasick´ ym implementac´ım BDI agent˚ u je to, ˇze tradiˇcn´ı cyklus interpretu – z´ıskej nov´e ud´ alosti, vytvoˇr odpov´ıdaj´ıc´ı pl´ any, uprav strukturu z´amˇer˚ u, vyber jeden z´amˇer a proved’ jeden krok jeho aktu´ aln´ıho pl´ anu – je rozdˇelen ˇ ast zobrazen´ do dvou nez´avisl´ ych ˇc´ast´ı. C´ a na obr´ azku vpravo je zodpovˇedn´ a za zpracov´ an´ı ud´alost´ı – ud´alosti jsou postupnˇe odeb´ır´ any z fronty ud´ alost´ı, maj´ı moˇznost upravit agentovu b´azi znalost´ı a pot´e jsou paralelnˇe pˇred´ any metod´ am, jeˇz maj´ı za u ´kol vytv´ aˇren´ı 57
ˇ ast objektov´e s´ıtˇe tˇr´ıdy BDIagent realizuj´ıc´ı chov´ Obr´azek 5.12: C´ an´ı interpretu
nov´ ych instanc´ı pl´an˚ u, resp. spr´ avu stavu existuj´ıc´ıch instanc´ı (tedy usp´ av´ an´ı, vzbouzen´ı atd.). Druh´a ˇc´ast, zachycen´a na obr´ azku vlevo, se star´ a o interpretaci struktury z´ amˇer˚ u. Z´amˇery jsou tedy interpretov´any nez´ avisle na zpracov´ an´ı ud´ alost´ı. Je samozˇrejmˇe moˇzn´e modelovat cyklus jako jeden celek, nicm´enˇe rozdˇelen´ı se zd´ a b´ yt v´ıce flexibiln´ı – v pˇr´ıpadˇe, ˇze je synchronizace potˇreba, m˚ uˇze b´ yt dod´ ana explicitnˇe. Voln´e prokl´ ad´ an´ı obou ˇc´ ast´ı cyklu m˚ uˇze b´ yt modelov´ano jednoduˇse d´ıky tomu, ˇze OOPN jsou zaloˇzeny na ud´ alostech m´ısto proces˚ u – v klasick´ ych programovac´ıch jazyc´ıch, jako je napˇr´ıklad Java by takov´e prokl´ ad´ an´ı muselo b´ yt modelov´ano pouˇzit´ım soubˇeˇznˇe bˇeˇz´ıc´ıch vl´ aken.
5.7.1
Zpracov´ an´ı ud´ alost´ı
Kaˇzd´a ud´alost m´a v prvn´ım kroku sv´eho zpracov´ an´ı moˇznost ovlivnit b´ azi znalost´ı agenta. To se dˇeje pˇredefinov´an´ım metody tˇr´ıdy Event updateBeliefs: anAgent, ve kter´e je moˇzn´e volat metody tˇr´ıdy BDIAgent addBelief a deleteBelief popsan´e dˇr´ıve. Tento krok v pˇr´ıpadˇe zmˇeny b´aze znalost´ı samozˇrejmˇe vede k vyvol´ an´ı dalˇs´ıch (intern´ıch) ud´ alost´ı. J´ adro zpracov´an´ı ud´alost´ı interpretem spoˇc´ıv´ a v paraleln´ım zavol´ an´ı pˇeti metod tˇr´ıdy BDIAgent, kter´e prov´adˇej´ı testov´an´ı, zda je tato ud´ alost unifikovateln´ a s nˇekterou ˇsablonou ud´ alosti pro jed58
'
(
# $% # $%
'
# $%
" !
!
&
Obr´azek 5.13: Metoda tˇr´ıdy BDIAgent slouˇz´ıc´ı k vytv´ aˇren´ı instanc´ı pl´ an˚ u a z´ amˇer˚ u pro danou ud´alost
notliv´e zmˇeny stavu instanc´ı pl´anu. Tyto metody jsou si znaˇcnˇe podobn´e, proto bude opˇet uk´az´ana pouze metoda createPlanInstances: anEvent, kter´ a se star´ a o vytv´ aˇren´ı nov´ ych instanc´ı pl´anu. Jej´ı s´ıt’ ukazuje obr´ azek 5.13. Framework poskytuje r˚ uzn´e varianty implementace t´eto metody, kter´e se liˇs´ı zp˚ usobem, jak´ ym se pˇristupuje ke knihovnˇe pl´ an˚ u (m´ısto planTemplates). Nejjednoduˇsˇs´ı varianta implementace, kter´a je uk´az´ana na obr´ azku 5.13, vybere z mnoˇziny relevantn´ıch pl´ an˚ u jeden n´ahodnˇe. V´ ybˇer pl´anu b´ yv´a naz´ yv´ an meta-pl´ anov´ an´ı a v souˇcasn´e dobˇe framework poskytuje moˇznost n´ahodn´eho v´ ybˇeru, v´ ybˇeru pl´ anu s nejvyˇsˇs´ı prioritou a koneˇcnˇe spuˇstˇen´ı speci´aln´ıho aplikaˇcn´ım program´atorem specifikovan´eho meta-pl´ anu, kter´ y vybere nejvhodnˇejˇs´ı pl´an. Pokud ud´alost nepatˇr´ı dosud k ˇz´ adn´emu z´ amˇeru (tj. jedn´ a se o extern´ı ud´ alost), je vytvoˇren z´amˇer nov´ y. Nen´ı-li v dan´em okamˇziku nalezen ˇz´ adn´ y relevantn´ı pl´ an, je metoda ukonˇcena. V pˇr´ıpadˇe, ˇze ud´alost byla c´ılem, je posl´ ana k opakovan´emu zpracov´ an´ı.
5.7.2
Interpretace z´ amˇ er˚ u
Interpret na obr´azku 5.12 vykon´ av´ a jeden z´ amˇer krok po kroku tak dlouho, dokud je tento z´amˇer provediteln´ y a pot´e vybere n´ ahodnˇe jin´ y provediteln´ y z´ amˇer. Dalˇs´ı varianta interpretace z´amˇer˚ u, kterou framework poskytuje, spoˇc´ıv´ a v tom, ˇze v kaˇzd´em kroku se vybere z provediteln´ ych z´amˇer˚ u ten s nejvyˇsˇs´ı prioritou a krok jeho instance pl´ anu na vrcholu z´asobn´ıku je pak vykon´an. Tento pˇr´ıstup ukazuje obr´ azek 5.14. Interpretace z´amˇer˚ u pˇredstavuje vlastn´ı funkˇcnost agenta – zde se v jednotliv´ ych kroc´ıch realizuj´ı agentovy pl´any, tedy prov´ adˇej´ı akce, kter´e ovlivˇ nuj´ı prostˇred´ı. Popis struktury a funkˇcnosti rozhodovac´ıho j´adra agenta tak byl dovrˇsen. N´ asleduj´ıc´ı podkapitola se bude 59
zab´ yvat podp˚ urn´ ymi strukturami, reprezentuj´ıc´ımi agentovo prostˇred´ı, zejm´ena ve vztahu ke komunikaci s ostatn´ımi agenty. Uk´ azky konkr´etn´ıch funkˇcn´ıch pˇr´ıklad˚ u model˚ u jsou uvedeny v pˇr´ıloze B – Cleaner world a pˇr´ıloze C – Block world, rozs´ ahlejˇs´ı aplikaci frameworku pak podkapitola 5.9.
Obr´azek 5.14: Interpretace z´ amˇer˚ u na z´ akladˇe priorit
5.8
Prostˇ red´ı a meziagentn´ı komunikace
Rozhodovac´ı j´adro BDI agenta popsan´e v pˇredchoz´ıch podkapitol´ ach se d´ a pouˇz´ıvat samostatnˇe k ˇreˇsen´ı u ´loh, kter´e maj´ı dopˇredu zn´ amy vˇsechny parametry (napˇr´ıklad u ´kol pˇreskl´ ad´av´an´ı kostek prezentovan´ y v pˇr´ıloze C). Takov´ y pˇr´ıstup je vˇsak velmi netypick´ y– jiˇz v definici agenta je zd˚ uraznˇena n´ avaznost na prostˇred´ı, se kter´ ym agent neust´ ale interaguje. Nav´ıc takov´ y pˇr´ıstup nen´ı efektivn´ı – v´ yhody reaktivn´ıho pl´ anov´ an´ı se projev´ı jen v dynamicky se mˇen´ıc´ım prostˇred´ı, ve kter´em je potˇreba upravovat agentovy c´ıle a pl´any bˇehem v´ ypoˇctu na z´akladˇe nov´ ych podm´ınek. Ve statick´ ych prostˇred´ıch je architektura BDI ve vˇetˇsinˇe pˇr´ıpad˚ u m´enˇe efektivn´ı neˇz klasick´e pl´ anovac´ımi algoritmy. Prostˇred´ı tedy pˇredstavuje d˚ uleˇzitou komponentu kaˇzd´eho agentn´ıho syst´emu, potaˇzmo frameworku PNagent. Na prostˇred´ı se d´ a nahl´ıˇzet ze dvou u ´hl˚ u – jednak pˇredstavuje zdroj podnˇet˚ u a pole p˚ usobnosti agenta (tento pohled je aplikaˇcnˇe specifick´ y), z´ aroveˇ n vˇsak agentovi tak´e poskytuje z´akladn´ı sluˇzby. Tyto sluˇzby, z nichˇz zˇrejmˇe nejd˚ uleˇzitˇejˇs´ı je zabezpeˇcen´ı prostˇredk˚ u pro vlastn´ı bˇeh agenta a komunikaci s dalˇs´ımi agenty, jsou obdobn´e pro vˇsechny agentn´ı syst´emy a jak bylo uk´az´ano ve tˇret´ı kapitole, standardizovan´e organizac´ı FIPA. Obˇe funkce prostˇred´ı zast´av´a ve frameworku PNagent tˇr´ıda Platform, tyto funkce budou nyn´ı struˇcnˇe diskutov´any.
5.8.1
Platforma jako zdroj podnˇ et˚ u agenta
Jiˇz jsem zm´ınil, ˇze funkce platformy jako zdroje podnˇet˚ u a pole p˚ usobnosti agenta je vˇzdy aplikaˇcnˇe specifick´a. Tuto funkˇcnost tedy mus´ı doplnit aplikaˇcn´ı program´ ator tak, ˇze zdˇed´ı ’ b´azovou tˇr´ıdu Platform a do jej´ı objektov´e s´ıtˇe dopln´ı pods´ıt , kter´ a pˇredstavuje fyzik´aln´ı ” z´akony“ dan´eho prostˇred´ı. Vlastn´ı pˇred´ av´ an´ı zmˇen prostˇred´ı agent˚ um se dˇeje zas´ıl´ an´ım zpr´av addEvent: anEvent objekt˚ um tˇr´ıdy BDIAgent. Ve frameworku m˚ uˇze objektu agenta tuto zpr´avu zas´ılat pouze objekt tˇr´ıdy Platform, protoˇze ten jedin´ y m´ a na objekt agenta referenci. V pˇr´ıpadˇe, ˇze je model napojen na re´ aln´e prostˇred´ı (z pohledu PNtalku, toto prostˇred´ı m˚ uˇze b´ yt i dalˇs´ım simul´ atorem, jak bude uk´ az´ ano d´ ale), pˇredstavuje tˇr´ıda Platform prostˇredn´ıka, kter´ y pˇrij´ım´a vstupy z tohoto prostˇred´ı a pˇrev´ ad´ı je na ud´ alosti pro 60
agenta. Stejnˇe tak agentovy akce typicky spoˇc´ıvaj´ı v zas´ıl´ an´ı zpr´ av objektu platformy, kter´ a pot´e modifikuje sv˚ uj model prostˇred´ı, pˇr´ıpadnˇe efekty agentov´ ych akc´ı pˇred´ av´ a do re´ aln´eho prostˇred´ı. Platforma tak pˇredstavuje vrstvu abstrakce prostˇred´ı pro vnitˇrn´ı model agenta. Tento pˇr´ıstup bude demonstrov´an v n´ asleduj´ıc´ı kapitole, vˇenuj´ıc´ı se uk´ azkov´e aplikaci frameworku PNagent.
5.8.2
Sluˇ zby poskytovan´ e platformou
Objekty tˇr´ıdy Platform poskytuj´ı v souˇcasn´e prototypov´e verzi agent˚ um tˇri z´ akladn´ı sluˇzby: • Spr´ avu ˇzivotn´ıho cyklu – zejm´ena prostˇredky pro vytv´ aˇren´ı a zab´ıjen´ı agent˚ u, pˇridˇelov´an´ı jednoznaˇcn´ ych identifik´ ator˚ u (AID), apod. • Sluˇzbu b´ıl´ych str´ anek (vyhled´ av´ an´ı agent˚ u podle jejich AID). • Pˇrenos zpr´ av mezi agenty. Jako komunikaˇcn´ı paradigma je pouˇzito zas´ıl´ an´ı zpr´ av, jazyk odpov´ıd´ a v prototypu podmnoˇzinˇe jazyka FIPA ACL. Zpr´ avy jsou implementov´ any objekty tˇr´ıdy ACLMessage, kter´a svou strukturou odpov´ıd´a zpr´ av´ am jazyka FIPA ACL. Obsahuje tedy m´ısta, synchronn´ı porty pro z´ısk´av´an´ı a metody pro nastavov´ an´ı jednotliv´ ych poloˇzek: AID pˇr´ıjemc˚ u, AID odes´ılatele, performativu, obsahu zpr´ avy atd. Na stranˇe agenta je komunikace postavena jako vyˇsˇs´ı vrstva nad z´ akladn´ım rozhodovac´ım j´adrem. Z´akladn´ı komponenty pro komunikaci jsou implementov´ any tˇr´ıdou CommunicatingAgent, kter´a dˇed´ı rozhodovac´ı j´ adro od tˇr´ıdy BDIAgent a pˇrid´ av´ a k nˇemu zejm´ena: • Prostˇredky pro jednoznaˇcnou identifikaci agenta (AID). • Metody pro zas´ıl´an´ı a pˇr´ıjem zpr´ av (ke kter´ ym BDI j´ adro m˚ uˇze pˇristupovat jako k agentov´ ym schopnostem). • Frontu pˇr´ıchoz´ıch zpr´av a tvorbu ud´ alost´ı spojen´ ych s pˇr´ıchoz´ımi zpr´ avami. Veˇsker´a komunikace prob´ıh´a pˇres agentovo prostˇred´ı, realizovan´e objektem tˇr´ıdy Platform, kter´ y se star´a o vlastn´ı pˇrenos zpr´ av mezi agenty, stejnˇe jako pˇridˇelov´ an´ı jedineˇcn´ ych AID. Metody, m´ısta a synchronn´ı porty realizuj´ıc´ı zasl´ an´ı zpr´ avy v r´ amci jedn´e platformy na stranˇe agenta i platformy ukazuje obr´ azek 5.15. Zpr´avu agent zaˇsle vol´an´ım sv´e metody sendMsg: aMessage, kter´ a vyvol´ a vlastn´ı pˇrenos zpr´avy pˇres platformu vol´an´ım jej´ı metody deliverMsg: aMessage, jeˇz pˇred´ a zpr´ avu pˇr´ıjemci vol´an´ım jeho metody addMsg: aMessage. Ta u pˇr´ıjemce vyvol´ a patˇriˇcnou ud´ alost a uloˇz´ı zpr´avu do jeho fronty zpr´av. Z t´eto fronty ji m˚ uˇze pˇrevz´ıt nˇekter´ a z jeho existuj´ıc´ıch instanc´ı pl´an˚ u, pˇr´ıpadnˇe m˚ uˇze b´ yt na z´akladˇe ud´ alosti pˇr´ıjmu zpr´ avy vytvoˇrena nov´ a instance pl´anu. Vlastn´ı pˇrevzet´ı zpr´avy se prov´ad´ı vol´ an´ım metody receiveMsg: aMsgTemplate. Parametr aMsgTemplate pˇredstavuje ˇsablonu zpr´ avy, kter´ a m´ a b´ yt pˇrijata. Koncept ˇsablon zpr´ av funguje obdobnˇe jako koncept ˇsablon ud´ alost´ı popsan´ y dˇr´ıve. Vzhledem k tomu, ˇze oblast komunikace a spr´ avy agent˚ u je v dneˇsn´ı dobˇe pomˇernˇe dobˇre standardizovan´a, byl pˇri n´avrhu kladen d˚ uraz na prinicipieln´ı soulad s tˇemito standardy. Tyto standardy vˇsak v prototypu nebyly implementov´ any do vˇsech detail˚ u. Ty by bylo potˇreba doplnit pˇri nasazen´ı frameworku v praxi, pro v´ yzkumn´e a prototypov´e u ´ˇcely souˇcasn´a implementace postaˇcuje. Proto byla pozornost zamˇeˇrena sp´ıˇse na aspekty rozhodovac´ıho j´adra. 61
!
"
"
Obr´azek 5.15: Metody, m´ısta a synchronn´ı porty objekt˚ u tˇr´ıdy CommunicatingAgent a Platform realizuj´ıc´ı zasl´an´ı zpr´avy v r´ amci jedn´e platformy
5.9
Pˇ r´ıklad aplikace frameworku PNagent
Kromˇe nˇekolika uk´azkov´ ych pˇr´ıklad˚ u zm´ınˇen´ ych v pˇredchoz´ıch ˇc´ astech t´eto kapitoly, jejichˇz c´ılem bylo otestovat a demonstrovat z´ akladn´ı vlastnosti frameworku PNagent, byla jeho funkˇcnost a pouˇzitelnost jako celku ovˇeˇrena na u ´loze tvorby formace mobiln´ıch robot˚ u. Souˇc´ast´ı tohoto projektu bylo ovˇeˇren´ı pouˇzitelnosti multiparadigmatick´eho modelov´an´ı v prostˇred´ı syst´em˚ u PNtalk a SmallDEVS. Samotn´ a u ´loha formace mobiln´ıch robot˚ u vych´az´ı z ˇcl´anku t´ ymu prof. Zieglera [HZ04], kter´ y na n´ı ukazuje moˇznosti pouˇzit´ı formalismu DEVS pro v´ yvoj syst´em˚ u zaloˇzen´ y na modelech.
5.9.1
Neform´ aln´ı zad´ an´ı u ´ lohy
V prostˇred´ı s pˇrek´aˇzkami se pohybuje skupina mobiln´ıch robot˚ u. Kaˇzd´ y robot se na poˇc´ atku pohybuje n´ahodnˇe po prostoru a vyh´ yb´ a se pˇrek´ aˇzk´ am. Pokud jeho senzory zachyt´ı pˇrek´aˇzku, tak si ovˇeˇr´ı, zda se jedn´ a o skuteˇcnou pˇrek´ aˇzku, nebo o jin´eho robota. Pro toto rozliˇsen´ı zaˇsle vˇsem ostatn´ım robot˚ um zpr´ avu obsahuj´ıc´ı data ze sv´ ych sonar˚ u. Pokud nˇekter´ y z ostatn´ıch robot˚ u naˇsel podobnost mezi tˇemito u ´daji a daty ze sv´ ych senzor˚ u, vˇsichni roboti zastav´ı a tento robot se pohne. Pokud se zmˇenou sonarov´eho vjemu potvrd´ı, ˇze tito dva roboti se zaznamenali navz´ ajem, vyˇsle robot, kter´ y protokol inicioval, pˇr´ıkaz n´asleduj mˇe“. Oba se pak natoˇc´ı do stejn´eho smˇeru a t´ım vytvoˇr´ı formaci. Od t´e chv´ıle ” se prvn´ı robot nad´ale pohybuje n´ ahodnˇe po prostoru, pˇriˇcemˇz pˇr´ıkazy sv´ ym aktu´ ator˚ um pˇrepos´ıl´a tak´e druh´emu robotu. Ten je beze zmˇeny vykon´ av´ a, ale na sv´e pozici. Formace 62
se tedy m˚ uˇze rozpadnout v pˇr´ıpadˇe, ˇze druh´ y robot nem˚ uˇze prov´est pˇr´ıkaz, protoˇze mu v tom br´an´ı pˇrek´aˇzka. V tom pˇr´ıpadˇe zaˇsle vedouc´ımu zpr´ avu konec formace“, vedouc´ı ” robot pˇrestane pos´ılat pˇr´ıkazy a nad´ ale se pohybuj´ı nez´ avisle na sobˇe, jak tomu bylo pˇred vznikem formace. Stejnˇe jako t´ ym prof. Zieglera jsme pro experimenty pouˇzili pouze dva roboty, rozˇs´ıˇren´ı na libovoln´ y poˇcet robot˚ u ve skupinˇe by vˇsak vyˇzadovalo jen drobn´e u ´pravy komunikaˇcn´ıho protokolu.
5.9.2
Mobiln´ı roboti
Jako syst´em pˇredstavuj´ıc´ı prostˇred´ı, ve kter´em se roboti nach´ azej´ı, stejnˇe jako abstrakci samotn´ ych robot˚ u, byl pouˇzit simul´ ator Player/Stage1 . Jedn´ a se o jeden z nejpouˇz´ıvanˇejˇs´ıch simulaˇcn´ıch syst´em˚ u v r´amci komunity zab´ yvaj´ıc´ı se robotikou. Skl´ ad´ a se ze dvou samostatn´ ych ˇc´ast´ı. Player je jazyk a platformˇe nez´ avisl´ y s´ıt’ov´ y server pro ovl´ ad´ an´ı robot˚ u, kter´ y poskytuje interface pro kontrolu cel´e ˇrady robotick´eho a senzorov´eho hardware pomoc´ı protokolu TCP/IP. Stage simuluje populaci mobiln´ıch robot˚ u, kteˇr´ı se pohybuj´ı a pˇrij´ımaj´ı podnˇety z 2D bitmapov´eho prostˇred´ı [GVH03]. V´ yhodou pouˇzit´ı kombinace Player/Stage je moˇznost obvykle zcela transparentn´ı z´ amˇeny simulovan´ ych robot˚ u v prostˇred´ı Stage za roboty re´aln´e. Obˇe ˇc´asti syst´emu jsou dostupn´e zdarma pod licenc´ı GNU GPL. Pˇri experimentech byl pouˇzit jeden ze z´ akladn´ıch model˚ u robota implementovan´ ych simul´atorem Stage, ActiveMedia Pioneer P3-DX2 , vybaven´ y osmi sonary o rozsahu 45◦ s dosahem 2,5 m, rozm´ıstˇen´ ymi radi´alnˇe kolem robota, osmi n´ arazn´ıky, kompasem a r´ adiem, umoˇzn ˇuj´ıc´ım zas´ıl´an´ı zpr´av ostatn´ım robot˚ um (v realizovan´em prototypu bylo zas´ıl´ an´ı zpr´ av implementov´ano lok´alnˇe v r´amci frameworku PNagent). Sch´ematick´ y obr´ azek robota s vyznaˇcen´ ymi z´onami pouˇz´ıvan´ ymi pro detekci pˇrek´ aˇzek ukazuje obr´ azek 5.16. Pˇr´ıkazy, kter´e je schopen robot vykonat (odpov´ıdaj´ı agentov´ ym schopnostem) jsou ˇctyˇri: robot se m˚ uˇze pohybovat vpˇred, zastavit, otoˇcit se o dan´ yu ´hel a zaslat zpr´ avu pomoc´ı r´ adia.
Obr´azek 5.16: Sch´ema pouˇzit´eho mobiln´ıho robota s vyznaˇcen´ım n´ arazn´ık˚ u a sonar˚ u. Z´ ona 1 (nebezpeˇcn´a z´ona) je pouˇz´ıv´ana pro zmˇenu smˇeru pˇri vyh´ yb´ an´ı pˇrek´ aˇzk´ am, z´ ona 2 (testovac´ı z´ona) pro testov´an´ı, zda se v bl´ızkosti nach´ az´ı jin´ y robot a z´ ona 3 pˇredstavuje dosah sonar˚ u.
1 2
http://playerstage.sourceforge.net/ http://www.activrobots.com/ROBOTS/p2dx.html
63
5.9.3
Struktura modelu
Jak jiˇz bylo zm´ınˇeno v u ´vodu, cel´ y model se skl´ ad´ a z nˇekolika heterogenn´ıch ˇc´ ast´ı, jejichˇz ˇ propojen´ı ukazuje obr´azek 5.17. C´ ast oznaˇcen´ a na obr´ azku jako server je kompletnˇe realizov´ana simul´atorem Player/Stage. Na stranˇe klienta je spuˇstˇeno prostˇred´ı Squeak Smalltalk, ve kter´em bˇeˇz´ı syst´em SmallDEVS. SmallDEVS [JK06] je syst´em vyv´ıjen´ y na VUT v Brnˇe, kter´ y je zaloˇzen na formalismu DEVS (Discrete Event System Specification) [ZKP00]. Jedn´ a se o pomˇernˇe n´ızko´ urovˇ nov´ y prostˇredek s pˇresnou form´aln´ı specifikac´ı, zaloˇzen´ y na syst´emu propojen´ ych komponent, kter´ y je d´ıky tomu vhodn´ y jako prostˇredek pro propojov´ an´ı r˚ uzn´ ych heterogenn´ıch syst´em˚ u. Realizovan´ y model obsahuje celou ˇradu komponent, z nichˇz vˇetˇsina se star´ a o komunikaci se simul´atorem Player/Stage, dalˇs´ı poskytuj´ı r˚ uzn´e transformace pˇr´ıkaz˚ u a vyrovn´ avac´ı pamˇeti pro komunikaci. Samotn´ y syst´em PNagent, kter´ y bˇeˇz´ı v prostˇred´ı PNtalk je zapouzdˇren jako atomick´a komponenta DEVSu [JK07], kter´ a pˇrij´ım´ a vstupy ze senzor˚ u vˇsech robot˚ u v syst´emu a n´aslednˇe vys´ıl´ a pˇr´ıkazy.
')*
!"
"-
"- $ # %
&+",
& "- !"
"-
"-
&' (
"-
Obr´azek 5.17: Sch´ema realizovan´eho modelu tvorby formace mobiln´ıch robot˚ u Z pohledu frameworku PNagent tato komunikace vypad´ a tak, ˇze v objektu tˇr´ıdy Platform jsou nˇekter´a m´ısta oznaˇcena jako vstupn´ı a jin´ a jako v´ ystupn´ı. Kdykoliv doraz´ı data ze senzor˚ u nˇekter´eho z robot˚ u, objev´ı se v pˇr´ısluˇsn´em vstupn´ım m´ıstˇe znaˇcka. Tento vstup je pak objektem tˇr´ıdy Platform analyzov´ an a v pˇr´ıpadˇe, ˇze je pro dan´eho agenta v´ yznamn´ y, je vygenerov´ana pˇr´ısluˇsn´a ud´alost ve smyslu architektury BDI a pˇred´ ana dan´emu agentovi. Naopak pokud se jeden z agent˚ u rozhodne vykonat akci, zavol´ a pˇr´ısluˇsnou metodu objektu tˇr´ıdy Platform, kter´a um´ıst´ı znaˇcku do v´ ystupn´ıho m´ısta, kde je pˇrevzata obaluj´ıc´ı komponentou DEVSu a odesl´ana. Aby mohla b´ yt jednoduˇse vyuˇzita komunikaˇcn´ı infrastruktura poskytovan´ a frameworkem PNagent, je cel´a populace agent˚ u (robot˚ u) um´ıstˇena uvnitˇr jedn´e komponenty. Ko64
munikace mezi jednotliv´ ymi agenty tak prob´ıh´ a pouze v r´ amci syst´emu PNagent pˇres objekt tˇr´ıdy Platform. V pˇr´ıpadˇe, ˇze by bylo nutn´e vytvoˇrit syst´em jako distribuovan´ y, nen´ı potˇreba v samotn´ ych agentech prov´ adˇet ˇz´ adn´e zmˇeny – komunikace bude pouze prob´ıhat vzd´alenˇe mezi jednotliv´ ymi platformami um´ıstˇen´ ych na r˚ uzn´ ych stroj´ıch. V modelu vˇsak tato moˇznost nebyla prozat´ım realizov´ ana.
5.9.4
Pˇ redzpracov´ an´ı dat a ud´ alosti
Simul´ator Player/Stage zas´ıl´a periodicky do pˇr´ısluˇsn´e DEVS komponenty data ze senzor˚ u. Tato data jsou n´aslednˇe pˇred´ana komponentˇe zapouzdˇruj´ıc´ı syst´em PNtalk, kde se objev´ı jako znaˇcky ve vstupn´ıch m´ıstech objektu tˇr´ıdy Platform. Tato data by mohla b´ yt pˇred´av´ana v nezmˇenˇen´e podobˇe objekt˚ um agent˚ u, jako ud´ alost nov´ a data ze senzoru“. ” Jako lepˇs´ı zp˚ usob se vˇsak jev´ı data jiˇz pˇri pˇr´ıjmu v platformˇe pˇredzpracovat a agent˚ um pak zas´ılat jiˇz pouze relevantn´ı ud´alosti – napˇr´ıklad ˇze byla zachycena pˇrek´ aˇzka v nebezpeˇcn´e vzd´alenosti pˇred robotem, robot zastavil apod. Na z´ akladˇe tˇechto ud´ alost´ı se pak pˇr´ımo vyvol´avaj´ı konkr´etn´ı pl´any pro ˇreˇsen´ı dan´e situace (nam´ısto speci´ aln´ıho pl´ anu, kter´ y by pokaˇzd´e analyzoval u ´daje ze senzor˚ u a na z´ akladˇe toho vytv´ aˇrel obdobn´e intern´ı ud´ alosti, coˇz by pro rozhodovac´ı proces byla zbyteˇcn´ a z´ atˇeˇz nav´ıc). Ud´ alosti pouˇzit´e v modelu a jejich vztah ukazuje obr´azek 5.18.
!
Obr´ azek 5.18: Hierarchie ud´alost´ı pouˇzit´ ych v modelu tvorby formace mobiln´ıch robot˚ u Ud´alosti tvoˇr´ı tˇri skupiny. Veˇsker´e ud´ alosti, kter´e nesou informaci z agentov´ ych senzor˚ u (robot zastavil, byla zpozorov´ana pˇrek´ aˇzka v testovac´ı z´ onˇe, nebezpeˇcn´ a pˇrek´ aˇzka pˇred robotem a koneˇcnˇe robot narazil) s sebou nesou kromˇe popisu ud´ alosti z´ aroveˇ n hrub´ a data ze senzor˚ u. Dalˇs´ı ud´alost je k dispozici pro pˇr´ıjem zpr´ av, ta je pouˇz´ıv´ ana pˇri r´ adiov´e komunikaci. C´ıle ved’ formaci“ a n´asleduj“ slouˇz´ı k vyvol´ av´ an´ı pˇr´ısluˇsn´ ych pl´ an˚ u po u ´spˇeˇsn´em ” ” ukonˇcen´ı protokolu tvorby formace.
5.9.5
B´ aze pˇ redstav a pl´ any
Pˇri souˇcasn´em zad´an´ı u ´lohy nen´ı b´ aze pˇredstav pˇr´ıliˇs rozs´ ahl´ a–u ´kolem robot˚ u je pohybovat se n´ahodnˇe a pouze pˇri kontaktu s pˇrek´ aˇzkou prov´est pˇredem danou aktivitu. B´ aze pˇredstav 65
tak obsahuje jen popis ostatn´ıch robot˚ u pro moˇznost nav´ az´ an´ı komunikace a d´ ale speci´ aln´ı meta-informace pro synchronizaci pl´ an˚ u. Extenzivnˇeji by byla vyuˇzita v pˇr´ıpadˇe, ˇze by roboti vytv´aˇreli mapu sv´eho prostˇred´ı, coˇz je jedn´ım z moˇzn´ ych budouc´ıch rozˇs´ıˇren´ı t´eto u ´lohy. Pl´ any naopak pˇredstavuj´ı kl´ıˇcovou souˇc´ ast t´eto u ´lohy. Na obr´ azc´ıch d´ ale v textu je zn´azornˇeno pˇet hlavn´ıch pl´an˚ u, kter´e zajiˇst’uj´ı z velk´e ˇc´ asti splnˇen´ı u ´kolu. Pro pˇrehlednost bylo z obr´azk˚ u vynech´ano oˇsetˇren´ı nˇekter´ ych chybov´ ych stav˚ u – napˇr´ıklad pˇri selh´ an´ı zasl´ an´ı zpr´avy, apod. N´ ahodn´ y pohyb agenta s vyh´ yb´ an´ım pˇrek´ aˇzk´ am je realizov´ an pl´ anem RCRandomMovePlan, kter´ y ukazuje obr´azek 5.19. Tento pl´ an je vytvoˇren pˇri v´ yskytu ud´ alosti RCRobotStoppedEvent a ihned po sv´em vytvoˇren´ı aktualizuje b´ azi znalost´ı tak, aby dalˇs´ı pl´ any pro n´ahodn´e proch´azen´ı nebyly vytv´aˇreny. Jeho funkˇcnost spoˇc´ıv´ a v tom, ˇze pokud se robot zastav´ı, vyˇsle pˇr´ıkaz jed’ vpˇred. Pokud se vyskytne pˇrek´ aˇzka v nebezpeˇcn´e z´ onˇe, zvol´ı se nov´ y smˇer tak, ˇze se vyberou sonary, kter´e vrac´ı nejvyˇsˇs´ı hodnotu (nejvzd´ alenˇejˇs´ı pˇrek´ aˇzku, nebo voln´ y prostor) a z nich se jeden zvol´ı n´ ahodnˇe. Robot se pak natoˇc´ı t´ımto smˇerem. Vlastn´ı v´ ypoˇcty natoˇcen´ı, stejnˇe jako ˇrada dalˇs´ıch v´ ypoˇct˚ u v modelu jsou z technick´ ych d˚ uvod˚ u realizov´any externˇe tˇr´ıdou jazyka Smalltalk pojmenovan´e RCMath (verze n´ astroje PNtalk pouˇzit´a pˇri experimentech zat´ım nepodporuje nˇekter´e potˇrebn´e konstrukce). V pˇr´ıpadˇe, ˇze byl zah´ajen protokol tvorby formace, je prov´ adˇen´ı n´ ahodn´eho proch´ azen´ı blokov´ ano negativn´ım predik´atem noFindFollowerPlan. Pˇri zah´ ajen´ı tohoto protokolu nen´ı pl´ an zruˇsen, pouze ˇcek´a na dokonˇcen´ı protokolu. Pl´ an pro n´ ahodn´e proch´ azen´ı tedy nem´ a definov´any podm´ınky ukonˇcen´ı, po sv´em vytvoˇren´ı existuje po celou dobu ˇzivota agenta.
! "# $
% !
&' !
Obr´azek 5.19: Pl´an RCRandomMovePlan realizuj´ıc´ı n´ ahodn´ y pohyb robota V pˇr´ıpadˇe, ˇze robot zpozoruje pˇrek´ aˇzku v testovac´ı z´ onˇe, spust´ı agent pl´ an pro zjiˇstˇen´ı, zda se jedn´a o pˇrek´aˇzku, ˇci jin´eho robota (samozˇrejmˇe za pˇredpokladu, ˇze tento protokol jiˇz nebyl zah´ajen jin´ ym agentem). Pl´ an RCFindFollowerPlan, jeˇz je uk´ az´ an na obr´ azku 5.20, 66
zast´av´a funkci role inici´atora protokolu, kter´ a je n´ asleduj´ıc´ı: • Robot se zastav´ı, zaˇsle data ze sv´ ych sonar˚ u ostatn´ım agent˚ um a ˇcek´ a na odpovˇed’. • Pokud je odpovˇed’ z´aporn´a, protokol konˇc´ı. • V opaˇcn´em pˇr´ıpadˇe se druh´ y robot pˇred odesl´ an´ım zpr´ avy pˇresunul, analyzuje se tedy aktu´aln´ı vstup ze sonar˚ u. • Pokud nebyla zaznamen´ana ˇz´ adn´ a zmˇena, zaˇsle se tomuto agentovi ozn´ amen´ı, ˇze se jednalo o n´ahodnou shodu vstup˚ u a protokol konˇc´ı. • V opaˇcn´em pˇr´ıpadˇe se mu zaˇsle pokyn k vytvoˇren´ı formace, dojde k natoˇcen´ı do pˇredem dan´eho smˇeru a oˇcek´ av´ a se jeho potvrzen´ı. • Po obdrˇzen´ı potvrzen´ı se spust´ı pl´ an pro veden´ı formace pomoc´ı vytvoˇren´ı pˇr´ısluˇsn´eho c´ıle. Druh´a role protokolu tvorby formace je implementov´ ana pl´ anem RCReplyFindFollowerPlan. Spouˇstˇec´ı podm´ınkou tohoto pl´ anu je, ˇze agent pˇrijme zpr´ avu od inici´ atora zahajuj´ıc´ı protokol. Sch´ema pl´anu ukazuje obr´ azek 5.21 a jeho u ´ˇcel je n´ asleduj´ıc´ı: • Robot se zastav´ı a analyzuje data, kter´ a obdrˇzel ve zpr´ avˇe. • Pokud nen´ı nalezena shoda, odeˇsle pˇr´ısluˇsnou zpr´ avu inici´ atorovi a protokol konˇc´ı. • V opaˇcn´em pˇr´ıpadˇe se robot natoˇc´ı smˇerem, kde by se mˇel nach´ azet inici´ ator a pˇrijede aˇz na hranici nebezpeˇcn´e oblasti. • Pot´e informuje inici´atora, ˇze byla nalezena shoda a ˇze se pˇresunul pro ovˇeˇren´ı. • Pokud inici´ator nezjist´ı zmˇenu ve sv´ ych senzorech, protokol konˇc´ı a formace nen´ı utvoˇrena. • V opaˇcn´em pˇr´ıpadˇe se robot natoˇc´ı do smluven´eho smˇeru, spust´ı pl´ an pro sledov´ an´ı a zaˇsle vedouc´ımu zpr´avu, ˇze je pˇripraven, ˇc´ımˇz je utvoˇrena formace. Pot´e co se ustanov´ı pomoc´ı tˇechto dvou pl´ an˚ u formace, je u inici´ atora na z´ akladˇe c´ıle zaslan´eho z pl´anu RCFindFollowerPlan vytvoˇrena instance pl´ anu RCLeadPlan. Obsah pl´anu ukazuje obr´azek 5.22. Pl´an vych´az´ı z pl´ anu pro n´ ahodn´e proch´ azen´ı, avˇsak kromˇe pˇr´ıkazu robotovi je vˇzdy vygenerov´ana tak´e zpr´ ava s t´ımto pˇr´ıkazem pro agenta, kter´ y jej n´ asleduje. D´ale je odchyt´av´ana ud´alost pˇrijet´ı zpr´ avy o tom, ˇze se formace ruˇs´ı. V pˇr´ıpadˇe pˇrijet´ı t´eto zpr´avy je pl´an ukonˇcen a agent pokraˇcuje v n´ ahodn´em proch´ azen´ı prostoru. Posledn´ı prezentovan´ y pl´an – RCFollowPlan je spuˇstˇen na z´ akladˇe c´ıle RCFollowGoal, kter´ y je vytvoˇren v pl´anu RCReplyFindFollowerPlan, pokud je u ´spˇeˇsnˇe vytvoˇrena formace. Spoˇc´ıv´a v pˇrij´ım´an´ı zpr´av s pˇr´ıkazy, jejich dek´ odov´ an´ı a prov´ adˇen´ı. V pˇr´ıpadˇe, ˇze se vyskytne ud´alost RCObstacleDeadAhead – tedy byla zpozorov´ ana pˇrek´ aˇzka tˇesnˇe pˇred agentem, je odesl´ana zpr´ava o zruˇsen´ı formace a pl´ an je ukonˇcen. Robot se pot´e d´ al pohybuje n´ ahodnˇe podle pl´anu RCRandomMovePlan, kter´ y byl po dobu pohybu ve formaci zastaven. Sch´ema pl´anu RCFollowPlan ukazuje obr´azek 5.23. Kromˇe tˇechto pˇeti z´akladn´ıch pl´ an˚ u, kter´e realizuj´ı vlastn´ı funkˇcnost modelu, m´ a k dispozici kaˇzd´ y agent tak´e nˇekolik pl´ an˚ u pro ˇreˇsen´ı r˚ uzn´ ych selh´ an´ı – napˇr´ıklad pro situaci, kdy robot narazil do pˇrek´aˇzky. 67
! " *+ , *+ , *+ , ! "#
$ ! " ! ! " "! *+ ,
*+ ,
*+ , " " % & "#
! "
' ( ) "
Obr´azek 5.20: Pl´an RCFindFollowerPlan pro roli inici´ atora protokolu tvorby formace
Pro v´ ybˇer pl´anu k prov´adˇen´ı je v modelu pouˇzita varianta interpretu ˇr´ızen´ a prioritami pl´an˚ u, kter´a je v nˇekter´ ych pˇr´ıpadech doplnˇena explicitn´ı synchronizac´ı (v nˇekter´ ych pˇr´ıpadech, jako napˇr´ıklad bˇehem ˇcek´ an´ı na pˇr´ıjem zpr´ avy pˇri protokolu tvorby formace, pˇri kter´em je dan´ y pl´an uspan´ y, nen´ı ˇz´ adouc´ı, aby agenta v tuto dobu ˇr´ıdily jin´e pl´ any s niˇzˇs´ı prioritou – konkr´etnˇe pl´an pro n´ahodn´e proch´ azen´ı). 68
, ! , ! , ! ' '(
! " # $%
& '
, ! , ! ' " # -$. & ' , ! , ! '
%" ' + , ! , ! , ! ' ' $ / '( " # $%
& ' ) ) ) & '* ' "
Obr´azek 5.21: Pl´an RCReplyFindFollowerPlan zodpovˇedn´ y za druhou roli protokolu tvorby formace
69
!" ! " " #
$ ! " " "
%& #
! " '
Obr´azek 5.22: Pl´an RCLeadPlan, kter´ y kromˇe n´ ahodn´eho proch´ azen´ı pˇrepos´ıl´ a veˇsker´e pˇr´ıkazy pomoc´ı zpr´av
5.9.6
Zhodnocen´ı
Hlavn´ım c´ılem modelu bylo otestovat funkˇcnost a aplikovatelnost frameworku PNagent jako celku, z´aroveˇ n s moˇznostmi propojen´ı s ostatn´ımi technologiemi vyv´ıjen´ ymi v r´ amci skupiny Modelov´an´ı a simulace na FIT VUT v Brnˇe. Tento c´ıl byl splnˇen (sn´ımek obrazovky pr˚ ubˇehu experimentu ukazuje obr´azek 5.24). Pˇri n´ avrhu modelu byla doladˇena cel´ a ˇrada technick´ ych detail˚ u v obou zm´ınˇen´ ych oblastech. Hlavn´ı probl´em, kter´ y se prozat´ım podaˇrilo vyˇreˇsit jen ˇc´asteˇcnˇe, je velmi vysok´a n´aroˇcnost syst´emu PNtalk, ve kter´em je framework PNagent implementov´an, na syst´emov´e zdroje. PNtalk se vˇsak st´ ale nach´ az´ı ve f´ azi prototypu a proto je moˇzn´e prov´est celou ˇradu optimalizac´ı (jiˇz v pr˚ ubˇehu tvorby modelu a experiment˚ u bylo autory PNtalku dosaˇzeno znaˇcn´eho zrychlen´ı). V porovn´an´ı s implementac´ı rozhodovac´ıho j´ adra agent˚ u pomoc´ı jednoduˇsˇs´ı reaktivn´ı architektury (jak v p˚ uvodn´ım ˇcl´anku skupiny prof. Zieglera, tak v r´ amci jin´eho t´ ymu ze skupiny Modelov´an´ı a simulace na FIT VUT v Brnˇe, ˇreˇs´ıc´ıho stejnou u ´lohu za pouˇzit´ı ˇcist´eho DEVSu, byla pouˇzita Subsumpˇcn´ı architektura) je zˇrejmˇe nejvˇetˇs´ım pˇr´ınosem snadn´ a rozˇsiˇritelnost funkˇcnosti pomoc´ı doplnˇen´ı dalˇs´ıch pl´ an˚ u a vyuˇzit´ı b´ aze znalost´ı a relativn´ı intuitivnost popisu ˇreˇsen´ı u ´lohy pomoc´ı pl´ an˚ u.
70
&( )
!"# $ %& '
Obr´azek 5.23: Pl´an RCLeadPlan, kter´ y pˇrij´ım´ a zpr´ avy od vedouc´ıho formace a prov´ ad´ı je
Obr´azek 5.24: Sn´ımek obrazovky s v´ ystupem simul´ atoru Player/Stage a modelu v prostˇred´ı SmallDEVS
71
´ eˇsnost tvorby formace samozˇrejmˇe nen´ı stoprocentn´ı, coˇz vypl´ Uspˇ yv´ a z pomˇernˇe dlouh´e reakˇcn´ı doby syst´emu a t´ım zp˚ usoben´e nepˇresnosti informac´ı, ze kter´ ych agent vych´ az´ı. Co se t´ yˇce moˇzn´ ych rozˇs´ıˇren´ı realizovan´eho modelu, tak zˇrejmˇe nejzaj´ımavˇejˇs´ı variantou je rozˇs´ıˇren´ı na v´ıce neˇz dva roboty – to vˇsak bude vyˇzadovat zrychlen´ı syst´emu PNtalk, pˇr´ıpadnˇe distribuci jednotliv´ ych agent˚ u na v´ıce poˇc´ıtaˇc˚ u (a s t´ım souvisej´ıc´ı nutnost doplnit moˇznost zas´ılat zpr´avy mezi platformami v s´ıt’ov´em prostˇred´ı). Dalˇs´ı drobn´ a rozˇs´ıˇren´ı by se mohla t´ ykat samotn´eho protokolu tvorby formace – zejm´ena vylepˇsen´ı tvaru formace po jej´ım vytvoˇren´ı (po skonˇcen´ı protokolu se roboti nach´ azej´ı pomˇernˇe bl´ızko sebe, takˇze formace se ˇcasto z´ahy rozpad´a) a peˇclivˇejˇs´ıho pˇredzpracov´ an´ı hrub´ ych dat ze senzor˚ u pˇri ovˇeˇrov´an´ı, zda se jedn´a o pˇrek´aˇzku ˇci robota (pot´e co bylo ovˇeˇreno, ˇze se o robota nejedn´ a, tuto pˇrek´aˇzku nad´ale pˇri vyhled´av´ an´ı robota ignorovat).
5.10
Jin´ e pˇ r´ıstupy k modelov´ an´ı multiagentn´ıch syst´ em˚ u Petriho s´ıtˇ emi
V n´asleduj´ıc´ım textu budou struˇcnˇe zm´ınˇeny jin´e pˇr´ıstupy k modelov´ an´ı multiagentn´ıch syst´em˚ u Petriho s´ıtˇemi. Tato ˇc´ast sice spad´ a sp´ıˇse do teoretick´e ˇc´ asti disertaˇcn´ı pr´ ace, avˇsak byla um´ıstˇena z´amˇernˇe aˇz za prezentaci frameworku PNagent, aby mohlo provedeno jeho srovn´an´ı s pˇr´ıstupy zde uveden´ ymi. Jednou z prvn´ıch publikac´ı, kter´ a se spojen´ım Petriho s´ıt´ı a agentn´ıch technologi´ı zab´ yvala, je ˇcl´anek [Hol95]. Vyuˇzit´ı Petriho s´ıt´ı (konkr´etnˇe barven´ ych Petriho s´ıt´ı) je zde vˇsak pops´ano pomˇernˇe v´agnˇe, stejnˇe tak jako architektura pouˇzit´ ych agent˚ u. Na tuto pr´ aci nav´azala stejn´a skupina ˇcl´ankem [WH02], kde je barven´ a Petriho s´ıt’ pouˇzita pro modelov´ an´ı konkr´etn´ıho multiagentn´ıho syst´emu, ˇreˇs´ıc´ıho u ´lohu, kterou autoˇri nazvali Packet-World. V modelu se autoˇri zamˇeˇruj´ı pˇredevˇs´ım na soci´ aln´ı interakce agent˚ u, konstatuj´ı vhodnost modelov´an´ı multiagentn´ıch syst´em˚ u pomoc´ı CPN. V´ ysledkem pr´ ace vˇsak nen´ı ˇz´ adn´ y znovupouˇziteln´ y syst´em, pouze samotn´ y model. Obecn´ y framework pro modelov´ an´ı multiagentn´ıho syst´emu pomoc´ı barven´ ych Petriho s´ıt´ı popisuje prof. Moldt ve ˇcl´ anku [MW97]. Formalismus barven´ ych Petriho s´ıt´ı je v nˇem rozˇs´ıˇren o koncepty objektov´e orientace, avˇsak pomˇernˇe konzervativn´ım zp˚ usobem, tak aby bylo moˇzn´e tyto s´ıtˇe simulovat pomoc´ı n´ astroj˚ u pro CPN. Architektura modelovan´eho multiagentn´ıho syst´emu vych´ az´ı z jiˇz dˇr´ıve zm´ınˇen´eho jazyka AOP [Sho93], tedy agentn´ıho syst´emu zaloˇzen´eho na teoretick´em usuzov´ an´ı. Pro reprezentaci pˇredstav a schopnost´ı agenta je pouˇzito prostˇredk˚ u logick´eho programov´ an´ı. Petriho s´ıtˇe tak pˇredstavuj´ı prostˇredek pro vyj´adˇren´ı infrastruktury frameworku (kter´ a je statick´ a), zat´ımco vlastn´ı programy jsou ps´any pomoc´ı jazyka obdobn´eho jazyku Prolog. Framework PNagent se s t´ımto pˇr´ıstupem tedy shoduje pouze v pouˇzit´ı Petriho s´ıt´ı rozˇs´ıˇren´ ych o objektovou orientaci; architektura agent˚ u i zp˚ usob vyj´ adˇren´ı agentn´ıch program˚ u jsou zcela odliˇsn´e. Dalˇs´ım pˇr´ıstupem, modeluj´ıc´ım tentokr´ at agenty zaloˇzen´e na architektuˇre BDI je jazyk nazvan´ y ADLMAS (Architecture Description Language for Multi-Agent Systems) [YC06]. Tento jazyk je zaloˇzen na formalismu nazvan´em OPN (Object-Oriented Petri nets). OPN pˇredstavuje variantu Petriho s´ıt´ı, kter´ a vych´ az´ı z CPN a m´ a s nimi mnoho podobnost´ı. Objektov´a rozˇs´ıˇren´ı jsou zavedeny prakticky jen pro potˇreby strukturov´ an´ı s´ıtˇe, v d˚ usledku toho je cel´ y syst´em opˇet zcela statick´ y – nen´ı moˇzn´e bˇehem simulace pˇrid´ avat ˇci ub´ırat agenty, agenti jsou pevnˇe propojeni hranami, po kter´ ych jsou zas´ıl´ any zpr´ avy (reprezentovan´e jako znaˇcky). Syst´em je v´ yraznˇe zamˇeˇren na statick´e ovˇeˇrov´ an´ı vlastnost´ı modelu, dynamick´e simulaci je vˇenov´ana mal´ a pozornost. V d˚ usledku toho je architektura i u ´ˇcel
72
tohoto syst´emu zcela odliˇsn´a od frameworku PNagent. Kromˇe tˇechto prac´ı vyuˇz´ıv´a ˇrada autor˚ u Petriho s´ıtˇe jako prostˇredek pro vyj´ adˇren´ı pouze nˇekter´ ych ˇc´ast´ı syst´emu, obvykle komunikace, pˇr´ıpadnˇe synchronizace pl´ an˚ u. Pˇr´ıklady takov´ ych pˇr´ıstup˚ u jsou pops´any napˇr´ıklad ve ˇcl´ anc´ıch [Fer99] a [CCF+ 99]. Lze tedy ˇr´ıci, ˇze to, co nejv´ıce odliˇsuje framework PNagent od vˇsech projekt˚ u zm´ınˇen´ ych v´ yˇse je jeho dynamiˇcnost, kterou se daleko v´ıce podob´ a syst´em˚ um vytvoˇren´ ych v bˇeˇzn´ ych programovac´ıch jazyc´ıch. To je d´ ano zejm´ena vlastnostmi pouˇzit´ ych objektovˇe orientovan´ ych Petriho s´ıt´ı. Framework PNagent tak pˇredstavuje praktickou uk´ azku hlavn´ı myˇslenky a p˚ uvodn´ıho c´ıle OOPN – pˇribl´ıˇzen´ı matematicky definovan´eho form´ aln´ıho apar´ atu bˇeˇzn´ ym programovac´ım jazyk˚ um.
73
Kapitola 6
Z´ avˇ er Pˇredloˇzen´a disertaˇcn´ı pr´ace se zab´ yv´ a problematikou modelov´ an´ı inteligentn´ıch agent˚ u pomoc´ı prostˇredk˚ u objektovˇe orientovan´ ych Petriho s´ıt´ı. Cel´ a pr´ ace bude nyn´ı shrnuta v nˇekolika kroc´ıch. Nejprve uvedu pouˇzit´ y pˇr´ıstup k ˇreˇsen´ı, d´ ale dosaˇzen´e v´ ysledky a koneˇcnˇe naznaˇc´ım moˇznosti dalˇs´ıho v´ yzkumu.
6.1
Zvolen´ y pˇ r´ıstup k ˇ reˇ sen´ı
V´ yzkum v oboru multiagentn´ıch syst´em˚ u se zamˇeˇruje na celou ˇradu oblast´ı, kter´e se daj´ı rozdˇelit do dvou hlavn´ıch skupin – hled´ an´ı vhodn´e vnitˇrn´ı architektury agent˚ u a v´ yzkum interakc´ı mezi kolekcemi agent˚ u. Ve sv´e pr´ aci jsem se rozhodl zamˇeˇrit na prvn´ı oblast – n´avrh vnitˇrn´ı architektury agent˚ u. K tomuto n´ avrhu existuje cel´ a ˇrada pˇr´ıstup˚ u, kter´e jsou diskutov´any ve tˇret´ı kapitole. Jako jeden z nejperspektivnˇejˇs´ıch pˇr´ıstup˚ u se jev´ı architektura BDI, kterou se pomˇernˇe podrobnˇe zab´ yv´ a kapitola ˇctvrt´ a. Souˇcasn´e syst´emy implementuj´ıc´ı architekturu BDI se obvykle snaˇz´ı bud’ o sbl´ıˇzen´ı s klasick´ ym softwarov´ ym inˇzen´ yrstv´ım, anebo se zamˇeˇruj´ı na hled´an´ı vhodn´eho form´ aln´ıho popisu. Pouˇzit´ı objektovˇe orientovan´ ych Petriho s´ıt´ı a n´ astroje PNtalk pro n´ avrh a v´ yvoj umoˇzn ˇuje vhodnˇe zkombinovat oba pˇr´ıstupy. M´ ym hlavn´ım c´ılem v t´eto pr´ aci bylo navrhnout experiment´aln´ı prototypov´ y syst´em, kter´ y by umoˇznil v´ yvoj agent˚ u s architekturou BDI podle metodiky v´ yvoje zaloˇzen´eho na modelech, a z´ aroveˇ n bude s´ am snadno modifikovateln´ y, coˇz by umoˇznilo experimenty se samotnou architekturou. Vzhledem k tomu, ˇze syst´em PNtalk je s´ am experiment´ aln´ı n´ astroj ve f´ azi v´ yvoje, ke kter´emu existuje zat´ım pomˇernˇe m´ alo materi´ al˚ u t´ ykaj´ıc´ıch se metodiky pouˇzit´ı, prom´ıtly se nˇekter´e myˇslenky a zkuˇsenosti z´ıskan´e pˇri t´eto pr´ aci zpˇetnˇe do obecn´e metodiky modelov´ an´ı pomoc´ı jazyka PNtalk.
6.2
Dosaˇ zen´ e v´ ysledky
Dosaˇzen´e v´ ysledky lze rozdˇelit do dvou oblast´ı. Hlavn´ım v´ ysledkem pr´ ace je n´ avrh architektury frameworku PNagent, prezentovan´ y v p´ at´e kapitole. Framework PNagent umoˇzn ˇuje modelov´an´ı inteligentn´ıch agent˚ u zaloˇzen´ ych na architektuˇre BDI pomoc´ı objektovˇe orientovan´ ych Petriho s´ıt´ı. Hlavn´ım rysem tohoto frameworku je otevˇrenost – tv˚ urce konkr´etn´ıho modelu m´a moˇznost snadno podle potˇreby modifikovat chov´ an´ı samotn´eho frameworku pomoc´ı stejn´ ych grafick´ ych prostˇredk˚ u, kter´ ymi vytv´ aˇr´ı samotn´ y model. To umoˇzn ˇuje vyuˇz´ıvat framework kromˇe tvorby model˚ u tak´e pro experimenty se samotnou architekturou BDI. 74
Oproti vˇetˇsinˇe existuj´ıc´ıch syst´em˚ u je PNagent zaloˇzen na form´ aln´ım z´ akladu, poskytovan´ ym Petriho s´ıtˇemi, coˇz umoˇzn ˇuje mimo jin´e vysoko´ urovˇ novou form´ aln´ı anal´ yzu. Dalˇs´ı v´ yhodou je intuitivnost grafick´eho vyj´ adˇren´ı modelu a pˇrirozen´ y popis paralelismu pˇri zachov´an´ı kompaktnosti cel´eho syst´emu. N´ avrh frameworku byl ovˇeˇren prototypovou implementac´ı pomoc´ı n´ astroje PNtalk, vˇcetnˇe nˇekolika uk´azkov´ ych model˚ u, kter´e slouˇz´ı pro demonstraci princip˚ u modelov´ an´ı pˇri pouˇzit´ı tohoto frameworku a tak´e porovn´ an´ı s existuj´ıc´ımi syst´emy. Kromˇe tˇechto uk´azkov´ ych model˚ u byla vytvoˇrena tak´e jedna rozs´ ahlejˇs´ı aplikace z oblasti ˇr´ızen´ı mobiln´ıch robot˚ u. Zde byl kromˇe funkˇcnosti a pouˇzitelnosti samotn´eho frameworku uk´ az´ an tak´e pˇr´ıstup k multiparadigmatick´emu modelov´ an´ı pomoc´ı n´ astroj˚ u vyv´ıjen´ ych v r´ amci skupiny Modelov´an´ı a simulace na FIT VUT v Brnˇe. Druhou oblast´ı pˇr´ınosu pr´ace je prok´ az´ an´ı a demonstrace vhodnosti pouˇzit´ı objektovˇe orientovan´ ych Petriho s´ıt´ı a syst´emu PNtalk pro modelov´ an´ı inteligentn´ıch syst´em˚ u a z´aroveˇ n pˇr´ıspˇevek k obecn´e metodice modelov´ an´ı pomoc´ı OOPN a n´ astroje PNtalk, zejm´ena zaveden´ı konceptu negativn´ıch predik´ at˚ u do jazyka PNtalk, diskutovan´ y ve druh´e kapitole. Negativn´ı predik´aty umoˇzn ˇuj´ı v ˇradˇe pˇr´ıpad˚ u pouˇz´ıt prostˇredk˚ u Petriho s´ıt´ı m´ısto inskripˇcn´ıho jazyka, ˇc´ımˇz mohou v´ yraznˇe usnadnit modelov´ an´ı. Vzhledem k tomu, ˇze pˇredstavuj´ı jist´ y druh inhibiˇcn´ıch hran, mohlo by jejich pouˇzit´ı v modelech zt´ıˇzit nˇekter´e druhy anal´ yzy zaloˇzen´e na invariantech. Proto byl vytvoˇren algoritmus, kter´ y umoˇzn ˇuje model vyuˇz´ıvaj´ıc´ı negativn´ı predik´aty pˇrev´est na ekvivalentn´ı model obsahuj´ıc´ı pouze v´ yrazy inskripˇcn´ıho jazyka.
6.3
Moˇ znosti dalˇ s´ıho v´ yzkumu
Na v´ yzkum prezentovan´ y v t´eto pr´ aci je moˇzn´e nav´ azat v nˇekolika oblastech. Prvn´ı z nich je vyuˇzit´ı frameworku PNagent pro experimenty se samotnou architekturou BDI, zejm´ena v oblasti meta-pl´anov´an´ı, tedy v´ ybˇeru relevantn´ıho pl´ anu pro danou ud´ alost a volby z´ amˇeru pro prov´adˇen´ı ze struktury z´amˇer˚ u. Jako zaj´ımav´ a moˇznost se jev´ı pro tento u ´ˇcel vyuˇzit´ı meta-´ urovˇ nov´e architektury n´astroje PNtalk. Dalˇs´ı experimenty se mohou t´ ykat porovn´ an´ı souˇcasn´e implementace interpretu s nez´ avisl´ ym zpracov´ an´ım ud´ alost´ı s klasick´ ym uzavˇren´ ym BDI-cyklem, podle nˇekolika proveden´ ych experiment˚ u se zd´ a verze implementovan´ a PNagentem v´ yhodnˇejˇs´ı. Rozˇs´ıˇren´ı se mohou t´ ykat tak´e pr´ ace s b´ az´ı pˇredstav, zejm´ena v oblasti jej´ı automatick´e revize. Dalˇs´ı oblast´ı sp´ıˇse implementaˇcn´ıho charakteru je propracov´ an´ı komunikaˇcn´ı infrastruktury, aˇz do dosaˇzen´ı pln´e kompatibility s normami FIPA a t´ım interoperatibility s ostatn´ımi agentn´ımi syst´emy, zejm´ena platformou JADE – implementovan´e modely byly doposud spouˇstˇeny pouze lok´alnˇe. Vzhledem k probl´em˚ um s efektivitou prototypov´e implementace n´ astroje PNtalk, na kter´e jsme narazili pˇri tvorbˇe modelu ˇr´ıd´ıc´ıho mobiln´ı roboty, se jev´ı jako zaj´ımav´ a ot´azka moˇznosti transformace model˚ u do jin´eho formalismu, napˇr´ıklad do ˇcist´eho DEVSu. PNagent by pak slouˇzil pro n´avrh a otestov´ an´ı rozhodovac´ıho j´ adra agenta, kter´e by pak pro samotn´ y bˇeh bylo pˇreloˇzeno do n´ızko´ urovˇ nov´eho, efektivnˇejˇs´ıho jazyka. Posledn´ım smˇerem je moˇznost vysoko´ urovˇ nov´e form´ aln´ı verifikace model˚ u, vytvoˇren´ ych pomoc´ı frameworku PNagent – t´eto problematice se vˇenuje jin´ a v´ yzkumn´ a skupina na FIT VUT v Brnˇe.
75
Literatura [AM04]
K. A. Amin and A. R. Mikler. Agent-based Distance Vector Routing: A Resource Efficient and Scalable approach to Routing in Large Communication Networks. Journal of Systems and Software, 71(3):215–227, 2004.
[Aus75]
J. Austin. How to Do Things With Words (William James Lectures). Harvard University Press, September 1975.
[BdOJB+ 02] R. H. Bordini, R. de O. Jannone, D. M. Basso, R. M. Vicari, and V. R. Lesser. AgentSpeak(XL): Efficient Intention Selection in BDI Agents via Decision-theoretic Task Scheduling. In Proceedings of the First International Joint Conference on Autonomous Agents and Multi-Agent Systems (AAMAS-2002), pages 1294–1302. ACM Press, 2002. [BF89]
R. A. Brooks and A. M. Flynn. Fast, Cheap and Out of Control: A Robot Invasion of the Solar System. Journal of the British Interplanetary Society, 42:478–485, 1989.
[BH05]
R. H. Bordini and J. F. H¨ ubner. BDI Agent Programming in AgentSpeak Using Jason (Tutorial Paper). In Proceedings of the Sixth International Workshop on Computational Logic in Multi-Agent Systems (CLIMA VI), pages 143–164, 2005.
[BIP91]
M. E. Bratman, D. Israel, and M. Pollack. Plans and Resource–Bounded Practical Reasoning. In R. Cummins and J. L. Pollock, editors, Philosophy and AI: Essays at the Interface, pages 1–22. The MIT Press, Cambridge, Massachusetts, 1991.
[Bow96]
J. P. Bowen. Formal Specification and Documentation using Z: A Case Study Approach. International Thomson Computer Press, 1996.
[BR01]
F. Bellifemine and G. Rimassa. Developing Multi-agent Systems with a FIPA-compliant Agent Framework. Software: Practice and Experience, 31(2):103–128, 2001.
[Bra87]
M. E. Bratman. Intention, Plans, and Practical Reason. Harvard University Press, Cambridge, MA, 1987.
[BRHL99]
P. Busetta, R. Ronnquist, A. Hodgson, and A. Lucas. JACK Intelligent Agents – Components for Intelligent Agents in Java, 1999. AgentLink News Letter. 76
[Bro86]
R. A. Brooks. A Robust Layered Control System for a Mobile Robot. IEEE Journal of Robotics and Automation, 2(1):14–23, March 1986.
[BS92]
B. Burmeister and K. Sundermeyer. Cooperative Problem-Solving Guided by Intentions and Perception. In E. Werner and Y. Demazeau, editors, Decentralized A.I. 3: Proceedings of the Third European Workshop on Modelling Autonomous Agents in a Multi-Agent World, pages 77–92. North-Holland, Amsterdam, 1992.
[BS97]
P. Bretier and M. D. Sadek. A Rational Agent as the Kernel of a Cooperative Spoken Dialogue System: Implementing a Logical Theory of Interaction. In ECAI ’96: Proceedings of the Workshop on Intelligent Agents III, Agent Theories, Architectures, and Languages, pages 189–203, London, UK, 1997. Springer-Verlag.
[CCF+ 99]
R. S. Cost, Y. Chen, T. Finin, Y. K. Labrou, and Y. Peng. Modeling Agent Conversations with Colored Petri Nets. In Working notes of the Autonomous Agents ’99 Workshop on Specifying and Implementing Conversation Policies, Seattle, Washington, May 1999.
[Cla87]
K. L. Clark. Negation as Failure. In Readings in nonmonotonic reasoning, pages 311–325. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 1987.
[Con89]
J. Connell. A Colony Architecture for an Artificial Creature. Technical report, Massachusetts Institute of Technology, Cambridge, MA, USA, 1989.
[DA92]
R. David and H. Alla. Petri Nets and Grafcet: Tools for Modelling Discrete Event Systems. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1992.
[Das08]
M. Dastani. 2APL: a Practical Agent Programming Language. Autonomous Agents and Multi-Agent Systems, 16(3):214–248, 2008.
[Den87]
D. C. Dennett. The Intentional Stance. The MIT Press, Cambridge, Massachusetts, 1987.
[dHL00]
M. d’Inverno, K. V. Hindriks, and M. Luck. A Formal Architecture for the 3APL Agent Programming Language. In ZB ’00: Proceedings of the First International Conference of B and Z Users on Formal Specification and Development in Z and B, pages 168–187, London, UK, 2000. Springer-Verlag.
[dLG+ 04]
M. d’Inverno, M. Luck, M. P. Georgeff, D. Kinny, and M. Wooldridge. The dMARS Architecture: A Specification of the Distributed Multi-Agent Reasoning System. Autonomous Agents and Multi-Agent Systems, 9(1-2):5–53, 2004.
[DW03]
I. Dickinson and M. Wooldridge. Towards Practical Reasoning Agents for the Semantic Web. In AAMAS ’03: Proceedings of the second international joint conference on Autonomous agents and multiagent systems, pages 827–834, New York, NY, USA, 2003. ACM.
77
ˇ s94] [Ceˇ
ˇ ska. Petriho s´ıtˇe. CERM, Brno, Cesk´ ˇ a republika, 1994. M. Ceˇ
[Fer92]
I. A. Ferguson. TouringMachines: Autonomous Agents with Attitudes. IEEE Computer, 25(5):51–55, 1992.
[Fer99]
J. Ferber. Multi-Agent Systems. Addision-Wesley, UK, 1999.
[FFMM94]
T. Finin, R. Fritzson, D. McKay, and R. McEntire. KQML as an Agent Communication Language. In N. Adam, B. Bhargava, and Y. Yesha, editors, Proceedings of the 3rd International Conference on Information and Knowledge Management (CIKM’94), pages 456–463, Gaithersburg, MD, USA, 1994. ACM Press.
[FIP01]
FIPA. FIPA ACL Message Structure Specification. FIPA, 2001.
[FIP02a]
FIPA. FIPA Abstract Architecture Specification. FIPA, 2002.
[FIP02b]
FIPA. FIPA Contract Net Interaction Protocol Specification. FIPA, 2002.
[FIP04]
FIPA. FIPA Agent Management Specification. FIPA, 2004.
[Fis94]
M. Fisher. A Survey of Concurrent METATEM – the Language and its Applications. In D. M. Gabbay and H. J. Ohlbach, editors, Temporal Logic Proceedings of the First Intemational Conference (LNAI Volume 827), pages 480–505. Springer-Verlag: Heidelberg, Germany, 1994.
[FN71]
R. E. Fikes and N. J. Nilsson. STRIPS: A New Approach in the Application of Theorem Proving to Problem Solving. Artificial Intelligence, 2:189–208, 1971. Reprint: Luger, Computation and Intelligence, 1995.
[GI89]
M. P. Georgeff and F. F. Ingrand. Decision-making in an Embedded Reasoning System. Technical Report 04, Australian Artificial Intelligence Institute, Melbourne, Australia, November 1989.
[GL87]
M. P. Georgeff and A. L. Lansky. Reactive Reasoning and Planning. In Proceedings of the Sixth National Conference on Artificial Intelligence (AAAI-87), pages 677–682, Seattle, WA, USA, July 1987. Morgan Kaufmann Publishers.
[GR96]
M. P. Georgeff and A. S. Rao. A profile of the Australian Artificial Intelligence Institute. IEEE Expert: Intelligent Systems and Their Applications, 11(6):89–92, 1996.
[Gru93]
T. R. Gruber. Towards Principles for the Design of Ontologies Used for Knowledge Sharing. In N. Guarino and R. Poli, editors, Formal Ontology in Conceptual Analysis and Knowledge Representation, Deventer, The Netherlands, 1993. Kluwer Academic Publishers.
[GVH03]
B. P. Gerkey, R. T. Vaughan, and A. Howard. The Player/Stage Project: Tools for Multi-Robot and Distributed Sensor Systems. In Proceedings of the 11th International Conference on Advanced Robotics, pages 317–323, 2003.
[Hin62]
J. Hintikka. Knowlegde and Belief. Cornell University Press, Ithaca, NY, 1962. 78
[HM03]
E. I. Hsu and D. L. Mcguinness. Wine Agent: Semantic Web Testbed Application. In Proceedings of 2003 Description Logics (DL2003), pages 5–7. CEUR-WS.org, 2003.
[Hol95]
T. Holvoet. Agents and Petri Nets. Petri Net Newsletter, 49, 1995.
[Hub99]
M. J. Huber. JAM: A BDI-theoretic Mobile Agent Architecture. In Proceedings of The Third International Conference on Autonomous Agents, pages 236–243, Seattle, WA, 1999.
[HZ04]
X. Hu and B. P. Zeigler. Model Continuity to Support Software Development for Distributed Robotic Systems: a Team Formation Example. In Journal of Intelligent & Robotic Systems, Theory & Application, Special Issue: Multiple and Distributed Cooperating Robots, pages 71–87, 2004.
[Jan98]
V. Janouˇsek. Modelov´ an´ı objekt˚ u Petriho s´ıtˇemi. PhD thesis, VUT v Brnˇe, Brno, CZ, 1998.
[Jen93]
N. R. Jennings. Specification and Implementation of a Belief-Desire-Joint-Intention Architecture for Collaborative Problem Solving. International Journal of Intelligent and Cooperative Information Systems, 2(3):289–318, 1993.
[Jen97]
K. Jensen. Coloured Petri Nets. Basic Concepts, Analysis Methods and Practical Use. Springer, 1997.
[JK03]
V. Janouˇsek and R. Koˇc´ı. PNtalk: Concurrent Language with MOP. In Proceedings of the CS&P’2003 Workshop, pages 271–282. Warsaw University, 2003.
[JK06]
V. Janouˇsek and E. Kironsk´ y. Exploratory Modeling with SmallDEVS. In Proc. of ESM 2006, pages 122–126. EUROSIS, 2006.
[JK07]
V. Janouˇsek and R. Koˇc´ı. Embedding Object-Oriented Petri Nets into a DEVS-based Simulation Framework. In Proceedings of the 16th International Conference on System Science, volume 1, pages 386–395. Wroclaw University of Technology, 2007.
[Kel94]
J. Kelemen. Strojovia a agenty. Archa, Bratislava, SK, 1994.
[KHS97]
H. Kargupta, I. Hamzaoglu, and B. Stafford. Scalable, Distributed Data Mining - An Agent Architecture. In Proceedings the Third International Conference on the Knowledge Discovery and Data Mining, pages 211–214, Menlo Park, California, 1997. AAAI Press.
[Kit98]
H. Kitano, editor. RoboCup-97: Robot Soccer World Cup I, volume 1395 of Lecture Notes in Computer Science. Springer, 1998.
[KMZJ07]
R. Koˇc´ı, Z. Mazal, F. Zboˇril, and V. Janouˇsek. Modeling Deliberative Agents using Object Oriented Petri Nets. In Proceedings of the 7th ISDA, pages 15–20. IEEE Computer Society, 2007.
79
[Koˇc04]
R. Koˇc´ı. Metody a n´ astroje pro implementaci otevˇren´ych simulaˇcn´ıch syst´em˚ u. PhD thesis, VUT v Brnˇe, Brno, CZ, 2004.
[Kou01]
A. Koumpis. The European IST ExPlanTech project. Ubiquity, 2(36):1, 2001.
[Kub04]
ˇ a republika, 2004. A. Kub´ık. Inteligentn´ı agenty. Computer Press, Brno, Cesk´
[LHDK94]
J. Lee, M. J. Huber, E. H. Durfee, and P. G. Kenny. UM-PRS: an Implementation of the Procedural Reasoning System for Multirobot Applications. In Proceedings of the Conference on Intelligent Robotics in Field, Factory, Service, and Space (CIRFFSS’94), pages 842–849, Houston, Texas, USA, 1994.
[LTO03]
V. Lesser, M. Tambe, and Ch. L. Ortiz, editors. Distributed Sensor Networks: A Multiagent Perspective. Kluwer Academic Publishers, Norwell, MA, USA, 2003.
[MB02]
S. J. Mellor and M. Balcer. Executable UML: A Foundation for Model-Driven Architectures. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2002.
[MJK08]
Z. Mazal, V. Janouˇsek, and R. Koˇc´ı. Enhancing the PNtalk Language with Negative Predicates. In Proceedings of MOSIS ’08, pages 28–34. MARQ, 2008.
[MKJZ08a]
Z. Mazal, R. Koˇc´ı, V. Janouˇsek, and F. Zboˇril. Modelling Intelligent Agents for Autonomic Computing in PNagent Framework, International Journal of Autonomic Computing (2008). Submitted for review.
[MKJZ08b]
Z. Mazal, R. Koˇc´ı, V. Janouˇsek, and F. Zboˇril. PNagent: a Framework for Modelling BDI Agents using Object Oriented Petri Nets. In Proceedings of the 8th ISDA. IEEE Computer Society, (to be published November 2008).
[MP01]
S. Moss and P.Davidsson, editors. Multi-Agent-Based Simulation, Second International Workshop, MABS 2000, Boston, MA, USA, July, 2000, Revised and Additional Papers, volume 1979 of Lecture Notes in Computer Science. Springer, 2001.
[Mul97]
J. P. Muller. The Design of Intelligent Agents: A Layered Approach. Springer-Verlag New York, Inc., Secaucus, NJ, USA, 1997.
[MVB03]
´ F. Moreira, R. Vieira, and R. H. Bordini. Extending the Operational A. Semantics of a BDI Agent-Oriented Programming Language for Introducing Speech-Act Based Communication. In DALT 2003 : Declarative Agent Languages and Technologies, pages 135–154. Springer, Berlin, Germany, 2003.
[MvdA05]
N. Mulyar and W.M.P. van der Aalst. Patterns in Colored Petri Nets. BETA Working Paper Series WP 139, Eindhoven University of Technology, Eindhoven, 2005.
80
[MW97]
D. Moldt and F. Wienberg. Multi-Agent-Systems Based on Coloured Petri Nets. In Lecture Notes in Computer Science: 18th International Conference on Application and Theory of Petri Nets, pages 82–101. Springer-Verlag, 1997.
[PBL03]
A. Pokahr, L. Braubach, and W. Lamersdorf. Jadex: Implementing a BDI-Infrastructure for JADE Agents. EXP – in Search of Innovation, 3(3):76–85, 2003.
[Per04]
ˇ a republika, 2004. J. Peregr´ın. Logika a logiky. Academia, Praha, Cesk´
[Rao96]
A. S. Rao. AgentSpeak(L): BDI Agents Speak Out in a Logical Computable Language. In Rudy van Hoe, editor, Seventh European Workshop on Modelling Autonomous Agents in a Multi-Agent World, Eindhoven, The Netherlands, 1996.
[Rei01]
R. Reiter. Knowledge in Action: Logical Foundations for Specifying and Implementing Dynamical Systems. MIT Press, Cambridge, MA, USA, 2001.
[RG92]
A. S. Rao and M. P. Georgeff. An Abstract Architecture for Rational Agents. In Proceedings of the 3rd International Conference on Principles of Knowledge Representation and Reasoning (KR’92), pages 439–449, Cambridge, MA, USA, 1992. Morgan Kaufmann.
[RN02]
S. J. Russell and P. Norvig. Artificial Intelligence: A Modern Approach (2nd Edition). Prentice Hall, December 2002.
[SBD+ 00]
V. S. Subrahmanian, P. Bonatti, J. Dix, T. Eiter, S. Kraus, F. Ozcan, and R. Ross. Heterogeneous Agent Systems. MIT Press/AAAI Press, Cambridge, MA, USA, 2000.
[Sho90]
Y. Shoham. Agent-oriented programming. Technical Report STAN-CS-1335-90, Computer Science Department, Stanford University, Stanford, CA, USA, 1990.
[Sho93]
Y. Shoham. Agent-oriented programming. Artif. Intell., 60(1):51–92, 1993.
[WH02]
D. Weyns and T. Holvoet. A Colored Petri Net for a Multi-Agent Application. In Components, Objects and Agents, MOCA’02. Computer Science Department, Aarhus University, 2002.
[Win05]
M. Winikoff. JACK Intelligent Agents: An Industrial Strength Platform. In R.H. Bordini, M. Dastani, J. Dix, and A. El Fallah Seghrouchni, editors, Multi-Agent Programming: Languages, Platforms and Applications, pages 175–193. Springer, 2005.
[WJ95]
M. J. Wooldridge and N. R. Jennings. Intelligent Agents: Theory and Practice. Knowledge Engineering Review, 10(2):115–152, 1995.
[Woo01]
M. J. Wooldridge. Reasoning about Rational Agents. MIT Press, Cambridge, MA, USA, 2001.
81
[Woo02]
M. J. Wooldridge. Introduction to MultiAgent Systems. John Wiley and Sons, 2002.
[WOO07]
D. Weyns, A. Omicini, and J. Odell. Environment as a First Class Abstraction in Multiagent Systems. Autonomous Agents and Multi-Agent Systems, 14(1):5–30, 2007.
[YC06]
Z. Yu and Y. Cai. Object-Oriented Petri nets Based Architecture Description Language for Multi-agent Systems. International Journal of Computer Science and Network Security, 6(1B):123–131, 2006.
[Zbo04]
F. Zboˇril. Pl´ anov´ an´ı a komunikace v multiagentn´ıch syst´emech. PhD thesis, VUT v Brnˇe, Brno, CZ, 2004.
[ZKP00]
B. P. Zeigler, T. Gon Kim, and H. Praehofer. Theory of Modeling and Simulation. Academic Press, Inc., Orlando, FL, USA, 2000.
82
Pˇ rehled publikac´ı autora [MZ06]
Z. Mazal, F. V. Zboˇril. Modelling Sensor Networks using Multiagent Systems. In: NETSS 2006, pages 15-18, Ostrava, CZ, MARQ, 2006.
[Maz06]
Z. Mazal. Multiagent System for Searching in FOAF Networks. In: Proceedings of the 12th Conference and Competition STUDENT EEICT 2006 Volume 4, pages 481-485, Brno, CZ, FIT VUT, 2006.
[MJZ07]
Z. Mazal, P. Jurka, F. V. Zboˇril. Framework for Intelligent Systems Education Support at FIT BUT. In: ASIS 2007, pages 173-176, Ostrava, CZ, MARQ, 2007.
[KMZJ07]
R. Koˇc´ı, Z. Mazal, F. Zboˇril, and V. Janouˇsek. Modeling Deliberative Agents using Object Oriented Petri Nets. In Proceedings of the 7th ISDA, pages 15–20. IEEE Computer Society, 2007.
[MJK08]
Z. Mazal, V. Janouˇsek, and R. Koˇc´ı. Enhancing the PNtalk Language with Negative Predicates. In Proceedings of MOSIS ’08, pages 28–34. MARQ, 2008.
[MKJZ08b]
Z. Mazal, R. Koˇc´ı, V. Janouˇsek, and F. Zboˇril. PNagent: a Framework for Modelling BDI Agents using Object Oriented Petri Nets. In Proceedings of the 8th ISDA. IEEE Computer Society, (to be published November 2008).
[MKJZ08a]
Z. Mazal, R. Koˇc´ı, V. Janouˇsek, and F. Zboˇril. Modelling Intelligent Agents for Autonomic Computing in PNagent Framework, International Journal of Autonomic Computing (2008). Submitted for review.
83
Pˇ r´ıloha A
Syntax jazyka PNtalk Textov´a verze jazyka PNtalk definuje kromˇe syntaxe inskripˇcn´ıho jazyka t´eˇz syntax popisu struktury Objektovˇe orientovan´e Petriho s´ıtˇe. Syntax popis˚ u s´ıt´ı, syntax struktury s´ıt´ı a cel´eho syst´emu tˇr´ıd form´alnˇe definujeme rozˇs´ıˇrenou Backus-Naurovou formou. Z´apis [. . .] znamen´a, ˇze ”...” se m˚ uˇze vyskytnout nepovinnˇe, [ ... ]* znamen´ a libovolnˇe n´ asobn´ y nepovinn´ y v´ yskyt ”...”, [ ... ]+ znamen´ a v´ yskyt ”...” jednou nebo v´ıckr´ at, ...—...[ —...]* ˇ ezce v uvozovk´ znamen´a v´ ybˇer jedn´e z variant. Retˇ ach odpov´ıdaj´ı lexik´ aln´ım symbol˚ um. V´ ychoz´ı symbol je classes. classes: [class]* "main" id [class]* class: "class" classhead [objectnet] [methodnet|constructor|sync|inhib]* classhead: id "is_a" id objectnet: "object" net methodnet: "method" message net constructor: "constructor" message net sync: "sync" message [cond] [precond] [guard] [postcond] inhib: "inhibitor" message [cond] [guard] message: id | binsel id | [keysel id]+ net: [place|transition]* place: "place" id"(" [initmarking] ")" [init] init: "init" "{" initaction "}" initmarking: multiset initaction: [temps] exprs transition: "trans" id [cond] [precond] [guard] [action] [postcond] cond: "cond" id"(" arcexpr ")" ["," id"(" arcexpr ")"]* precond: "precond" id"(" arcexpr ")" ["," id"(" arcexpr ")"]* postcond: "postcond" id"(" arcexpr ")" ["," id"(" arcexpr ")"]* guard: "guard" "{" expr3 "}" action: "action" "{" [temps] exprs "}" arcexpr: multiset multiset: [n "‘"] c ["," [n "‘"] c]*
84
n: [dig]+ | id c: literal | id | list list: "(" [c ["," c]* ["|" [id | list] ]] ")" temps: "|" [id]* "|" unit: id | literal | "(" expr ")" unaryexpr: unit [ id ]+ primary: unit | unaryexpr exprs: [expr "."]* [expr] expr: [id ":="]* expr2 expr2: primary | msgexpr [ ";" cascade ]* expr3: primary | msgexpr msgexpr: unaryexpr | binexpr | keyexpr cascade: id | binmsg | keymsg binexpr: primary binmsg [ binmsg ]* binmsg: binsel primary binsel: selchar[selchar] keyexpr: keyexpr2 keymsg keyexpr2: binexpr | primary keymsg: [keysel expr2]+ keysel: id":" literal: number | string | charconst | symconst | arrayconst arrayconst: "#" array array: "(" [number | string | symbol | array | charconst]* ")" number: [-][[dig]+ "r"] [hexDig]+ ["." [hexDig]+] ["e"["-"][dig]+]. string: "’"[char]*"’" charconst: "$"char symconst: "#"symbol symbol: id | binsel | keysel[keysel]* | string id: letter[letter|dig]* selchar: "+" | "-" | "*" | "/" | "~" | "|" | "," | "<" | ">" | selchar2 selchar2: "=" | "&" | "\" | "@" | "%" | "?" | "!" hexDig: "0".."9" | "A".."F" dig: "0".."9" letter: "A".."Z" | "a".."z" char: letter | dig | selchar | "[" | "]" | "{"|"}" | "(" | ")" | char2 char2:" "|"^"|";"|"$"|"#"|":"|"."| "-"|"‘"
85
Pˇ r´ıloha B
Model Cleaner world Tato pˇr´ıloha ukazuje kompletn´ı aplikaˇcnˇe specifickou ˇc´ ast modelu Cleaner world, pouˇzitou v p´at´e kapitole pr´ace pˇri popisu pr´ace s b´ az´ı pˇredstav a spouˇstˇen´ı pl´ an˚ u. V textu byly uk´ az´ any jen kl´ıˇcov´e ˇc´asti modelu, zde jsou doplnˇeny o dalˇs´ı souvislosti. V podobˇe prezentovan´e n´ıˇze nen´ı model napojen na re´aln´e prostˇred´ı – pˇredpokl´ ad´ a se, ˇze z vnˇejˇsku jsou objektu agenta zas´ıl´any ud´alosti pˇredstavuj´ıc´ı objeven´ı nov´eho odpadu. Veˇsker´e operace agent prov´ ad´ı jen nad svou b´az´ı pˇredstav. Model sest´ av´ a z konkretizovan´e tˇr´ıdy agenta, dvou pl´ an˚ u, jedn´e aplikaˇcnˇe specifick´e ud´alosti a jednoho c´ıle. Pro bˇeh modelu je pouˇz´ıv´ ana z´ akladn´ı verze interpretu bez pouˇzit´ı priorit a meta-pl´ an˚ u. C´ılem modelu je demonstrovat z´ akladn´ı principy fungov´an´ı agent˚ u ve frameworku PNagent – pr´ aci s b´ az´ı pˇredstav, unifikaci ud´ alost´ı, vytv´aˇren´ı pl´an˚ u, apod. Prvn´ım pl´anem je CWMoveToPositionPlan, jehoˇz instanci ukazuje obr´ azek B.1 a ˇsablonu obr´azek B.2. C´ılem tohoto pl´ anu je pˇresunout agenta na m´ısto, kter´e je specifikov´ano v c´ıli CWMoveToPositionGoal, kter´ y pˇredstavuje jeho spouˇstˇec´ı ud´ alost. Strukturu tˇr´ıdy CWMoveToPositionGoal ukazuje obr´ azek B.3.
Obr´azek B.1: Instance pl´ anu CWMoveToPositionPlan
86
ˇ Obr´azek B.2: Sablona pl´ anu CWMoveToPositionPlan
Obr´azek B.3: C´ıl CWMoveToPositionGoal
Druh´ ym pl´anem je CWCollectWastePlan, kter´ y je spuˇstˇen pˇri nalezen´ı nov´eho odpadu, a kter´ y m´a za u ´kol pˇrem´ıstit agenta na m´ısto odpadu (pomoc´ı spuˇstˇen´ı pomocn´eho pl´anu CWMoveToPositionPlan), zvednut´ı odpadu, pˇrenesen´ı do popelnice a jeho upuˇstˇen´ı. Instanci tohoto pl´anu ukazuje obr´azek B.4, ˇsablonu B.5, ud´ alost nalezen´ı nov´eho odpadu pak B.6. Vlastn´ı tˇr´ıda agenta je uk´az´ana na obr´ azc´ıch B.7, B.8 a B.9. Obr´ azky B.7 a B.8 ukazuj´ı metody addBelief, resp. removeBelief slouˇz´ıc´ı k pˇrid´ av´ an´ı a odeb´ır´ an´ı pˇredstav z agentovy b´aze znalost´ı, kter´e byly pˇr´ıliˇs rozs´ ahl´e, aby se veˇsly do jednoho vyobrazen´ı se zbytkem agenta. Ten je obsahem obr´azku B.9 a ukazuje implementaci b´ aze pˇredstav a agentov´ ych schopnost´ı.
87
#
" #
!
!
$
$
#
$
$ $ &
$ !
$ $
$
!
%
%
!
Obr´azek B.4: Instance pl´ anu CWCollectWastePlan
ˇ Obr´azek B.5: Sablona pl´ anu CWCollectWastePlan
88
! " #
! "
" ! " ! "
Obr´azek B.6: Ud´ alost CWNewWasteEvent
!
Obr´azek B.7: Metoda addBelief tˇr´ıdy CWAgent
89
!
#
!
!
! " !
$
Obr´azek B.8: Metoda removeBelief tˇr´ıdy CWAgent
90
" ) #
&&'( #
! $ ! " # ! # !
! !
&' ) % *+ %
! ! % ! "
"
! !
Obr´azek B.9: Tˇr´ıda CWAgent, implementuj´ıc´ı b´ azi pˇredstav a agentovy schopnosti
91
Pˇ r´ıloha C
Model Blocks world Blocks world pˇredstavuje jednu z klasick´ ych pl´ anovac´ıch u ´loh. Obsahuje tˇri kostky o stejn´e velikosti (block1, block2 a block3) a robotick´e rameno, kter´e m˚ uˇze zvednout jednu z kostek a pˇrem´ıstit ji na jinou kostku nebo na st˚ ul (table). C´ılem je pˇreskl´ adat kostky z poˇca´teˇcn´ıho do c´ılov´eho stavu. Pˇr´ıklad takov´eho poˇc´ ateˇcn´ıho a c´ılov´eho u ´lohy ukazuje obr´ azek C.1.
Obr´azek C.1: Poˇc´ ateˇcn´ı a c´ılov´ y stav u ´lohy Blocks world Pro syst´emy praktick´eho usuzov´ an´ı nen´ı takov´ ato u ´loha typick´ a – agentovo prostˇred´ı je statick´e, takˇze probl´em je efektivnˇeji vyˇreˇsen klasick´ ymi pl´ anovac´ımi algoritmy. Prezentovan´ y model vˇsak ukazuje jednu z moˇznost´ı, jak k dan´emu probl´emu pˇristoupit. Nav´ıc umoˇzn ˇuje porovn´an´ı s dalˇs´ımi BDI syst´emy, ve kter´ ych byl tento model implementov´ an, napˇr´ıklad JAM, prezentovan´ y v [Woo02]. Model prezentovan´ y d´ ale je spuˇstˇen speci´aln´ı ud´alost´ı pot´e vykon´av´a veˇsker´e pˇresuny pouze jako manipulaci se svoj´ı b´ az´ı pˇredstav – nen´ı tedy stejnˇe jako v modelu Cleaner world napojen na okoln´ı prostˇred´ı. Hlavn´ım pl´anem, kter´ y prov´ad´ı vlastn´ı pˇresuny kostek, je BWStackPlan. Jeho instanci ukazuje obr´azek C.2, ˇsablonu pak C.3. Pl´ an je spouˇstˇen c´ılem BWAchieveOnGoal (obr´ azek C.4), kter´ y specifikuje, kter´a kostka se m´ a pˇresunout kam. Druh´ ym pl´anem, kter´ y specifikuje jednotliv´e makro-kroky pˇresunu (tedy v postatˇe jak m´a vypadat v´ ysledek a kter´e kostky um´ıstit nejdˇr´ıve), je pl´ an BWTopLevelPlan (obr´azky C.5 a C.6). Tento pl´an je spouˇstˇen ud´ alost´ı BWStartEvent (obr´ azek C.7), kter´ a kromˇe spuˇstˇen´ı tohoto pl´anu provede inicializaci agentovy b´ aze pˇredstav. B´ aze pˇredstav a agentova
92
!%#$ #$ "
!
!%#$ #$ "&
"
#$
!%#$ #$ ' #$ "( ) *"+, ( !%
!%#$ #$
!%#$ #$
!%#$ #$ ' #$ "( ) *"+, ( !%
#$ #
Obr´azek C.2: Instance pl´ anu BWStackPlan
! " #
#
#
! "
ˇ Obr´azek C.3: Sablona pl´ anu BWStackPlan
93
Obr´azek C.4: C´ıl BWAchieveOnGoal
!" #$
!% !" #$ !& !% #$ $
Obr´azek C.5: Instance pl´ anu BWTopLevelPlan
jedin´a schopnost – pˇresunovat kostky, jsou implementov´ any tˇr´ıdou BWAgent. Tu ukazuje obr´azek C.4.
94
ˇ Obr´azek C.6: Sablona pl´ anu BWTopLevelPlan
" " "
"
" ' ( " " #"$" %&" ( " ' (
!
"
Obr´azek C.7: Ud´ alost BWStartEvent
95
%"
&
"" $
$
$ $
$
$
$
"""( $"$ ""(
&
%"
$
$
$ $
$
$
$
$
$ $
$ ' "( $"$ ""(
! ""
! "" !
# ! ""
! "" !
Obr´azek C.8: Aplikaˇcnˇe specifick´ a ˇc´ ast tˇr´ıdy BWAgent
96
Pˇ r´ıloha D
N´ avod pro spuˇ stˇ en´ı model˚ u na pˇ riloˇ zen´ em CD Framework PNagent byl prototypovˇe implementov´ an v syst´emu PNtalk 2007, kter´ y je zaloˇzen na prostˇred´ı Squeak Smalltalk. V´ yvojov´e prostˇred´ı a zp˚ usob distribuce se u Squeaku znaˇcnˇe liˇs´ı od tradiˇcn´ıch programovac´ıch jazyk˚ u. Distribuce se skl´ ad´ a z interpretu, kter´ y je urˇcen´ y pro konkr´etn´ı platformu, a image“, coˇz je zmrazen´ y stav syst´emu objekt˚ u, ” kter´ y je platformnˇe nez´avisl´ y. Na pˇriloˇzen´em CD se nach´ az´ı interpret funguj´ıc´ı na platformˇe Windows, interpret pro ostatn´ı platformy je moˇzn´e st´ ahnout na str´ ank´ ach Squeaku1 . Pro spuˇstˇen´ı je pˇripraven d´avkov´ y soubor run.bat. Obr´azek D.1 ukazuje sn´ımek obrazovky prostˇred´ı PNtalk. Vlevo se nach´ az´ı tzv. Re” pository“, coˇz je m´ısto, kde jsou uloˇzeny v pˇr´ısluˇsn´ ych sloˇzk´ ach vˇsechny dostupn´e tˇr´ıdy frameworku PNagent a vytvoˇren´e simulace. Kliknut´ım prav´ ym tlaˇc´ıtkem myˇsi na n´ azev tˇr´ıdy ˇci simulace se vyvol´a kontextov´e menu. To umoˇzn ˇuje u tˇr´ıd zobrazit jejich zdrojov´ y k´od v textov´e (poloˇzka open) i grafick´e (poloˇzka open editor ) podobˇe, pˇr´ıpadnˇe pˇrid´avat ˇci odeb´ırat metody, atd. U simulac´ı umoˇzn ˇuje menu jejich spuˇstˇen´ı, zastaven´ı, smaz´an´ı, apod. Kliknut´ım lev´ ym tlaˇc´ıtkem myˇsi na modr´ y troj´ uheln´ık vlevo od n´ azvu poloˇzky dojde k zobrazen´ı podˇrazen´ ych poloˇzek, tedy u tˇr´ıdy jej´ıch metod, u simulace objekt˚ u, kter´e se v n´ı nach´azej´ı. Jelikoˇz se projekt PNtalk se nach´ az´ı ve stavu alfa verze, obsahuje celou ˇradu nedodˇelk˚ u a velmi omezenou podporu pro grafick´e zobrazov´ an´ı model˚ u a simulac´ı – ve skuteˇcnosti je moˇzn´e pouze zobrazit objektovou s´ıt’ ˇci s´ıt’ metody, kter´ a byla pˇredt´ım zad´ ana textovˇe. PNtalk se tak´e nestar´a o spr´avn´e rozm´ıstˇen´ı grafick´ ych prvk˚ u na obrazovce – to je nutno prov´est ruˇcnˇe. Vzhledem k relativnˇe neintuitivn´ımu ovl´ ad´ an´ı syst´emu PNtalk jsem do uk´ azkov´eho image zahrnul jen z´akladn´ı tˇr´ıdy frameworku PNagent a dva jednoduch´e modely, popsan´e v pˇr´ıloh´ach B a C. Model ovl´ad´an´ı robot˚ u, kter´ y vyˇzaduje tak´e instalaci simul´ atoru Player/Stage pod Linuxem, jeho konfiguraci a celou ˇradu dalˇs´ıch nastaven´ı jsem vynechal. Modely odpov´ıdaj´ı tˇemto pˇr´ıloh´am pomˇernˇe pˇresnˇe, pouze obch´ azej´ı jist´e nedodˇelky syst´emu PNtalk v oblasti pˇrekladu (pˇrekladaˇc dosud nepodporuje konstruktory a nˇekter´e syntaktick´e obraty se seznamy). Pro oba modely jsou pˇredpˇripraveny simulace, kter´e lze spustit pomoc´ı poloˇzky Start ” Simulation“ z kontextov´eho menu. Po spuˇstˇen´ı simulace se vypisuj´ı agentovy akce do oblasti Transcriptu“, coˇz je v prostˇred´ı Squeaku obdoba konzole (na obr´ azku D.1 vpravo nahoˇre). ” 1
http://www.squeak.org/
97
Obr´azek D.1: Sn´ımek obrazovky prostˇred´ı PNtalk s pˇripraven´ ymi modely
Dalˇs´ı simulace je moˇzn´e vytv´aˇret oznaˇcen´ım bloku k´ odu v oblasti nazvan´e Workspace“ (na ” obr´azku D.1 vpravo dole), vyvol´an´ım kontextov´eho menu prav´ ym tlaˇc´ıtkem myˇsi a volbou Do It. U modelu Cleaner world je pˇri inicializaci agent um´ıstˇen na pozici (1,1) a popelnice na pozici (2,1). Po inicializaci je vytvoˇren pouze jeden odpad, a to na pozici (5,5). V modelu Block world odpov´ıd´a poˇc´ateˇcn´ı a c´ılov´ y stav situaci na obr´ azku C.1, prezentovan´eho v pˇr´ıloze C.
98
