SBORNÍK PŘÍSPĚVKŮ Z LETNÍ ŠKOLY MEZIOBOROVÉ PŘÍSTUPY INFORMATIKY A KOGNITIVNÍ VĚDY

Transkript

1 SBORNÍK PŘÍSPĚVKŮ Z LETNÍ ŠKOLY MEZIOBOROVÉ PŘÍSTUPY INFORMATIKY A KOGNITIVNÍ VĚDY Fakulta informatiky a managementu Univerzity Hradec Králové Projekt Informační, kognitivní a interdisciplinární podpora výzkumu je spolufinancován Evropským sociálním fondem a státním rozpočtem České republiky.

2 Recenzent: prof. RNDr. Josef Zelenka, CSc. Recenzovaný sborník 2. ročníku letní školy Mezioborové přístupy informatiky a kognitivní vědy. Publikace neprošla jazykovou úpravou. Za obsahovou správnost odpovídají autoři příspěvků. ISBN

3 Recenzovaný sborník příspěvků z 2. ročníku letní školy Mezioborové přístupy informatiky a kognitivní vědy. Letní školu uspořádali členové vědeckých týmů působících na Fakultě informatiky a managementu Univerzity Hradec Králové spolu s projektovým týmem INKOV ve dnech 11. až 15. června Programový výbor: Ing. Agáta Bodnárová prof. RNDr. Martin Gavalec, CSc. Ing. Filip Malý, Ph.D. prof. RNDr. Peter Mikulecký, Ph.D. Mgr. Petr Tučník, Ph.D. Organizační výbor: Bc. Anna Hovorková Ing. Kateřina Mišičková Ing. Hana Šafránková prof. RNDr. Josef Zelenka, CSc.

4

5 OBSAH Josef Zelenka LETNÍ ŠKOLA MEZIOBOROVÉ PŘÍSTUPY INFORMATIKY A KOGNITIVNÍ VĚDY. 7 Martin Bacovský L-SYSTÉMY V 3D NETLOGU 8 Kristýna Báčová, Martina Husáková REPREZENTACE ZNALOSTÍ POMOCÍ JAZYKA OWL.. 12 Martin Hátaš, Jan Matyska CISCO IP KALKULAČKA PRO POČÍTAČOVÉ SÍTĚ Eva Kautzká, Richard Cimler SROVNÁNÍ METOD NASTUPOVÁNÍ DO LETADLA 30 Jiří Kysela MOŽNOSTI GEOLOKAČNÍCH WEBOVÝCH APLIKACÍ PRO LBS.. 36 Jan Loskot SYSTÉM PRO PODPORU VÝUKY PROGRAMOVÁNÍ MIKROKONTROLÉRŮ Kamila Olševičová, Richard Cimler AGENTOVÝ MODEL POPULAČNÍ DYNAMIKY KELTSKÉHO SÍDLIŠTĚ Alena Pozdílková PROBLÉM OBCHODNÍHO CESTUJÍCÍHO V EXTREMÁLNÍCH ALGEBRÁCH. 59 Jan Procházka TABULOVÁ ARCHITEKTURA JAKO METODA SPOLUPRÁCE V MULTIAGENTOVÝCH SYSTÉMECH 63 Karel Radocha, Lukáš Rejha OPEN EDU MOBILNÍ APLIKACE Peter Sinčák, Martin Paľa, Mária Virčíková AKO DÁVAŤ INTELIGENCIU REÁLNYM A VIRTUÁLNYM ROBOTOM.. 81 Vladimír Skoupý MOBILNÍ APLIKACE (ANDROID) OBCHODNÍ CESTUJÍCÍ 97 Jiří Štěpánek VYUŽITÍ MULTIAGENTOVÉHO SYSTÉMU V SIMULACI AKCIOVÉHO TRHU 108 5

6 Ján Vaščák HYBRIDNÉ PROSTRIEDKY VÝPOČTOVEJ INTELIGENCIE 112 Mária Virčíková, Peter Sinčák ÚLOHA EMÓCIÍ V INTELIGENTNÝCH SYSTÉMOCH 122 6

7 LETNÍ ŠKOLA MEZIOBOROVÉ PŘÍSTUPY INFORMATIKY A KOGNITIVNÍ VĚDY Podruhé v červnu 2012 Fakulta informatiky a managementu Univerzity Hradec Králové hostila účastníky letní školy Mezioborové přístupy informatiky a kognitivní vědy, kterou připravili členové vědeckých týmů působících na FIM spolu s projektovým týmem INKOV. Každý den letní školy byl věnován jednomu tématu a byl garantován jedním vědeckým týmem. V dopoledních blocích se naši i zahraniční odborníci věnovali např. těmto tématům: Kvalita služieb v IP sieťach Ign. Ivan Dolnák, Ph.D., Efektivní systém kritického varování a vyrozumění doc. Ing. Jan Skrbek, Dr., Systém OPEN-EDU na UHK Ing. Pavel Krbálek, Windows Phone 7 Filip Řehořík, Výpočtová inteligencia jako súčasť umelej inteligencie Dr. Ing. Ján Vaščák a Intervalový přístup k vlastnímu problému v max-min algebře prof. RNDr. Martin Gavalec, CSc. Odpoledne začala posterovými sekcemi studentů a pokračovala praktickými semináři pod vedením pozvaných hostů či členů vědeckých týmů. V rámci letní školy byla otevřena tato témata: Moderní přístupy v oblasti počítačových sítí, Inteligentní a znalostní přístupy k podpoře lidských aktivit, Autonomní systémy, Mobilní aplikace, platformy, vývoj, Nestandardní optimalizační metody. Přejeme Vám, aby i druhý ročník letní školy byl pro Vás zajímavou inspirací. za organizátory letní školy Josef Zelenka Poděkování Všechny příspěvky vznikly za podpory projektu Informační, kognitivní a interdisciplinární podpora výzkumu INKOV, registrační číslo CZ.1.07/2.3.00/ , který je spolufinancován Evropským sociálním fondem a státním rozpočtem České republiky. 7

8 L-SYSTÉMY V 3D NETLOGU L-SYSTEMS IN 3D NETLOGO Martin Bacovský Abstrakt V příspěvku zavedeme L-systémy a uvedeme dva modely, které pomocí L-systémů generují základní fraktální množiny i jednoduché rostliny a ukazují jejich možné využití. Originalita našich modelů spočívá především ve vývojovém prostředí, kterým je 3D NetLogo verze První model ukazuje základní lineární deterministické fraktály jako je např. Sierpinského trojúhelník, druhý pak využívá L-systému pro modelování primitivního růstu a šíření rostlin v uzavřeném prostředí. Klíčová slova Fraktál, L-systém, formální gramatika, želví grafika, Logo, NetLogo. Abstract In this report we define two basic L-systems together with two models, which generate basic fractal sets, plants and show their usefulness. The new is the developing of models in 3D NetLogo environment. The first model shows basic linear deterministic fractals such as Sierpinki s triangle, the second uses L-systems for modeling primitive plant growth and its expand in a closed environment. Keywords Fractal, L-system, formal grammatic, turtle graphics, Logo, NetLogo. 1. Úvod Fraktál je členitý objekt, jehož struktura je dána opakováním určitého tvaru v různých velikostech [1]. Konkrétněji si lze určitou podmnožinu fraktálů, tzv. lineární deterministické fraktály, představit jako posloupnost lineárních transformací nad jistou počáteční množinou. Pro vykreslování fraktálů lze využít například formální gramatiky. Formální gramatiku, kterou budeme dále nazývat L-systémem, definujeme jako uspořádanou trojici (V, P, S), kde V je konečná množina symbolů, P je konečná množina přepisovacích pravidel, která jednomu symbolu z V přiřadí konečný řetězec z V, a konečně S je počáteční řetězec z V zvaný axiom L-systému. V přepisovacích pravidlech vynecháváme ta pravidla, která symbol přepisují na ten samý symbol z důvodu stručnosti (např. + -> +). Jednotlivé symboly lze pak 8

9 interpretovat jako příkazy, které postupně vykonávají želvy v prostředí Logo, tzv. želví grafika. My používáme prostředí 3D NetLogo Celý proces vykreslení fraktálu pak probíhá iterativním způsobem. Začneme axiomem, na který paralelně aplikujeme přepisovací pravidla, tj. slovo přepíšeme najednou. Tím dostaneme slovo první iterace. Slovo druhé iterace pak získáme podobně paralelní aplikací přepisovacích pravidel na slovo z první iterace a takto můžeme pokračovat do té doby, než nám dojde paměť nebo prodlevy výpočetního stroje mezi jednotlivými iteracemi přesáhnou únosnou mez. Abychom se tomuto vyhnuli, používáme v našich modelech omezení na počet iterací v závislosti na právě vykreslovaném fraktálu. S předchozí jednoduchou gramatikou si v našich modelech nevystačíme. Pro většinu našich fraktálů budeme potřebovat tzv. závorkový L-systém, což je L- systém rozšířený o dva symboly [ a ], které mají přiřazeny operace ulož na zásobník a nahraj ze zásobníku, přičemž se ukládají a nahrávají aktuální pozice želv. Ukažme předchozí definice na praktické ukázce jednoduché fraktální květiny: L-systém fraktální květiny = ({0, 1, [, ]}; 0 -> 1[0]0, 1 -> 11; 0), kde symbolům 0 a 1 je přiřazena akce pohybu vpřed, které se mezi sebou liší délkou kroku. Symbol [ resp. ] navíc k práci se zásobníkem ještě představuje pootočení doprava resp. doleva o 45 stupňů. Slova prvních tří iterací vypadají takto: 0 -> 1[0]0 -> 11[1[0]0]1[0]0 -> 1111[11[1[0]0]1[0]0]11[1[0]0]1[0]0. Následující obrázek ukazuje tato tři slova vykreslena v NetLogu. Obr. 1: První tři iterace jednoduché fraktální rostliny 2. První model: Jednoduché fraktály První model vykresluje několik prvních iterací pro sedm fraktálů: Kochova vločka (maximálně 7 iterací), fraktální květina složitější (6), fraktální květina jednodušší (7), Sierpinského trojúhelník (9), jehličnatý strom (12), keř 1 (4), keř 2 (4). Na obrázku dva je ukázána devátá iterace Sierpinského trojúhelníka společně s detailem. Právě pro možnost natáčení a přibližovaní jsme dali přednost 3D NetLogu před NetLogem dvojrozměrným. 9

10 Obr. 2: Devátá iterace Sierpinského trojúhelníka jako celek a jako část V modelu je pro každý fraktál definován jeho L-systém, který ho generuje. Strukturu L-systému každého objektu poznáme z procedury "[zkratka objektu]- vytvor-seznam". Axiom (startovní slovo) pak najdeme v proceduře "inicializace". Operace příslušné jednotlivým symbolům jsou vyjádřené v proceduře "[zkratka objektu]-jdi-podle-seznamu". Aktuální slovo je uloženo v globální proměnné "seznam" a zásobník pozic želvy v globální proměnné "zasobnik". Procedury "[zkratka objektu]-nove-kolo" vytvoří želvu na startovním bodě, který může být pro každý objekt jiný, a vymaže objekt nakreslený v předchozím kroku. Pomocné procedury simulují práci se zásobníkem. Jsou to: "uloz-na-zasobnik", která uloží do zásobníku aktuální pozici želvy společně s jejím natočením v prostoru (kromě "roll", která pro nás nemá efekt), a její opak "nahraj-zezasobniku", která naopak nastaví pozici želvy a její orientaci podle hodnot v zásobníku. 3. Druhý model: Primitivní ekosystém pro dva druhy rostlin Druhý model má za úkol ukázat praktické využití L-systémů. Model simuluje nejjednodušší ekosystém, ve kterém je zdrojem energie voda a spotřebiteli energie květiny. Ty jsou zde dvou druhů: první druh se vyvíjí pět kol, než může rozšiřovat svá semena (žlutý květ), druhý druh se vyvíjí kol šest (fialový květ). Jejich vývoj je popsán právě L-systémem. Každé kolo může buď zapršet a tak doplnit části území vodu, kterou pak mohou květiny čerpat, anebo nezapršet a květiny si musí vystačit s vodou, kterou mají. Jestliže nemají dostatek energie, vrací se ve svém vývoji o jednu fázi zpět a v extrémním případě uhynou. V modelu je možné nastavit pravděpodobnost zapršení a celkový objem deště. Z pozorování vyplynulo, že první druh rychle obsadí většinu území, pak ale v době nedostatku dešťů vymírá a jeho pozici obsadí druhý druh, který se jednak rozmnožuje pomaleji a tím pádem pracuje se zdroji úsporněji, jednak z rozkvetlého 10

11 stavu (nejvyšší fáze vývoje) zahyne o jedno kolo déle než druh první. Pro malý počet srážek (malá pravděpodobnost deště nebo malý objem srážek) však oba druhy po určité době vyhynou. Obrázek tři ilustruje grafickou podobu druhého modelu. 4. Závěr Obr. 3: Grafický výstup primitivního modelu ekosystému V našem příspěvku jsme se zaměřili na vývoj jednoduchých L-systémů pro želví prostředí 3D NetLogo. Ukázali jsme, že lze v tomto prostředí vykreslovat i jednoduché fraktály jako například Sierpinského trojúhelník a jak je možné L- systémy využít pro modelování primitivních ekosystémů, kde jediným zdrojem energie je déšť a jejími spotřebiteli dva druhy rostlin bojující mezi sebou o místo. Poděkování Příspěvek vznikl v rámci řešení projektu GACR-402/09/0405 Rozvoj nestandardních optimalizačních metod a jejich aplikace v ekonomii a managementu. Literatura [1] Ebert, S. D., Musgrave, F. K., Peachey, D. R., Perlin, K., Worley, S. Texturing & Modeling A Procedural Approach, third edition. Morgan Kaufmann Publishers, Bc. Martin Bacovský Univerzita Hradec Králové, Fakulta informatiky a managementu Rokitanského 62, Hradec Králové, Česká republika martin.bacovsky@uhk.cz 11

12 REPREZENTACE ZNALOSTÍ POMOCÍ JAZYKA OWL KNOWLEDGE REPRESENTATION USING THE OWL LANGUAGE Kristýna Báčová, Martina Husáková Abstrakt Příspěvek je zaměřen na specifickou oblast informatiky - ontologie vyvíjené v ontologickém jazyce OWL (Ontology Web Language) prostřednictvím několika vybraných verzí editoru Protégé. Následně jsou konkrétní verze porovnány na základě zvolených kritérií a na závěr je doporučen nejvhodnější nástroj pro vymezenou cílovou skupinu studenty předmětu ZT1 (Znalostní technologie I) Fakulty informatiky a managementu při Univerzitě Hradec Králové. Klíčová slova Ontologie, jazyk OWL, Protégé Abstract The paper is focused on the specific area of computer science ontologies created in the OWL (Ontology Web Language) with the aid of several selected versions of Protégé editor. Particular versions are compared on the basis of selected criteria and the most suitable one is suggested for defined target group students of the subject K-bT1 (Knowledge-based Technologies 1) studying at the Faculty of Informatics and Management at the University of Hradec Králové. Keywords Ontologies, OWL, Protégé 1. Úvod V kontextu s informatikou navázal vývoj ontologií na předchozí pokusy o formální zachycení podstaty reálného světa. S rozvojem informačních systémů a masivním nástupem informací v podnicích vzešla potřeba terminologického slovníku znalostí, který by mohly sdílet určité instituce v konkrétních doménách. Objevil se tedy požadavek na tvorbu společného pojmového aparátu, jež by umožnil sdílení a využívání různých znalostí z odlišných zdrojů a v rozdílných jazycích [1]. První značný nárůst zájmu o ontologie nastal v souvislosti s rozšířením služby WWW (World Wide Web) v komerční sféře spolu se vznikem podnětů k využívání internetu jako prostředku výměny informací, které budou srozumitelné jak pro člověka, tak pro počítače [2]. 12

13 Aktuálně existuje obrovské množství webových dokumentů a v závislosti na tomto počtu vznikají problémy s vyhledávácími službami, protože informace obsažené na webu jsou mnohdy velmi rozsáhlé, často nestrukturované a vágní. V kontextu s těmito nedostatky vzešla potřeba nového webu, jenž by umožnil zpracování a vyhledávání informací na základě jejich významu (sémantiky). Ontologie slouží především k zabezpečení sémantiky webu, tedy využitelnosti webových informací pro strojové odvozování a zároveň představují jednu ze základních vrstev sémantického webu [3]. V současné době jsou ontologie spojovány zejména s oblastí ontologického inženýrství, jejímž cílem je na jedné straně vývoj obecných jazyků, metodik a softwarových nástrojů a na straně druhé konstrukce ontologií, které budou tyto nástroje, jazyky a metodiky využívat. Mezi hlavní oblasti využití ontologií patří: znalostní management, elektronické obchodování, zpracování přirozeného jazyka, vyhledávání informací, sémantické webové portály nebo inteligentní výukové systémy [2]. 2. Jazyk OWL Jedná se o značkovací jazyk, který byl vytvořen pro sdílení a tvorbu ontologií využitelných v prostředí sémantického webu. Jeho součástí je množina axiomů charakterizující třídy, vlastnosti a vztahy mezi nimi. Z hlediska syntaxe vychází z všeobecného syntaktického standardu XML (Extensible Markup Language) a představuje rozšíření jazyka RDF (Resource Description Framework). Jazyk OWL však umožňuje lepší strojovou interpretovatelnost webového obsahu než zmíněné standardy a zároveň poskytuje dodatečnou slovní zásobu s formální sémantikou. Představuje vrstvu jazyků implementujících sémantiku deskripční logiky a v souvislosti se specifickými požadavky na složitost ontologií je navrhován ve třech různých dialektech [4]. Dialekty jazyka OWL Dialekty jazyka (OWL Lite, OWL DL, OWL Full) jsou navzájem odlišné a jejich nasazení závisí na složitosti ontologie, budoucím využití ontologie, nástrojích, které jsou k dispozici, nárocích na implementaci, znalostech a potřebách uživatele [5]. Jazyky OWL Lite a OWL DL jsou založeny na deskripční logice, její sémantice a inferenčních mechanismech, zatímco jazyk OWL Full je založen na sémantice kompatibilní s RDF(S) [1]. OWL ontologie Strukturu OWL ontologie představuje tzv. OWL dokument, který reprezentuje ontologii příslušné domény a je organizován tak, aby byl strojově čitelný a použitelný pro odvozování [1]. Jeho součástí je hlavička (začátek dokumentu) a komponenty OWL ontologie, jež mohou být libovolně uspořádány [6]. Ontologii lze chápat jako hierarchicky strukturovanou množinu pojmů pro popis určité domény, která může být použita za základ znalostní báze [7]. Vytvářená ontologie se tedy týká konceptů světa, které tvoří třídy uspořádané do hierarchické struktury taxonomie (vztah nadtřída, podtřída). 13

14 3. Tvorba ontologie v praxi Pro porovnání vybraných verzí editoru Protégé byla vytvořena ontologie z oblasti aviatiky. Vlastnímu modelování konkrétní ontologie předcházela přípravná fáze, která spočívala ve vyřešení otázek dvojího typu: (1) Požadavky na ontologii směrem k zadavateli projektu (účel tvorby ontologie, doba splatnosti projektu, důvod tvorby ontologie), (2) Požadavky na realizaci dané ontologie (prostředí pro vývoj, problémová oblast - doména, rozsah ontologie, ontologický jazyk, jazyk tvorby ontologie). Přípravná fáze Problémová oblast (doména) Letectví (kategorizace letadel podle způsobu vzniku vztlaku) Jazyk tvorby ontologie Anglický jazyk (bez diakritiky) Jazyk pro vývoj ontologie OWL (1.0) Editor (nástroj) pro tvorbu Protégé (verze 3.3.1, 4.0.2, 4.1) ontologie Pravidla pro pojmenování konceptů Pojmenování vlastností bude začínat malým písmenem. Názvy tříd a jedinců budou začínat velkým písmenem. Víceslovné názvy nebudou odděleny mezerami. Tab. 1: Přehled nezbytných částí přípravné fáze Na začátku tvorby ontologie bylo nezbytné zúžit okruh rozsáhlého množství informací vztahujících se k modelované doméně. Pro vývoj ontologie byl zvolen jazyk OWL a editor Protégé, jenž je v současné době řazen mezi nejpoužívanější nástroje, které daný jazyk podporují. Editor Protégé neklade důraz na využití konkrétního jazyka (čeština, angličtina, ) při modelování konceptů ontologie ani na používání diakritiky v jejich názvech. Obvykle závisí volba jazyka na samotném tvůrci ontologie. V rámci modelování, však byla využita vizualizace pomocí pluginu OWL Viz, který v souvislosti s diakritikou v názvech konceptů, nemusí správně fungovat. V kontextu s těmito předpoklady byla tedy jazykem ontologie vybrána angličtina, jež neobsahuje diakritiku. V jazyce OWL nejsou stanoveny normy, které by určovaly striktní způsob pojmenování tříd, jedinců a vlastností. Pro jednodušší orientaci je však vhodné vymezení názvů jednotlivých konceptů na základě stejných pravidel, která jsou v přípravné fázi určena autorem ontologie (viz Tab. 1). Normalizovaná ontologie stručný popis vývoje vlastní ontologie Ontologie byla vytvářena dle pravidel normalizace, které strukturují ontologii do podoby stromu za účelem logického a snáze udržovatelného uspořádání tříd. Normalizovaná ontologie je tedy založena na předpokladu, že veškeré třídy jsou rozděleny do tří základních skupin: primitivní, definované a přídavné třídy. 14

15 První předpoklad tvorby vlastní ontologie představovala specifikace relevantních termínů a jejich následné rozdělení na komponenty OWL ontologie. Poté byl konkrétní model znovu přeformulován a obohacen o nové koncepty a vlastnosti. V situaci, kdy byl již výčet relevantních termínů dostatečný, následovala kategorizace tříd podle principu normalizace. Ukázka rozdělení na jednotlivé komponenty OWL ontologie je obsažena v Tab. 2. Komponenty OWL ontologie Třída Vlastnost Jedinec Letadlo Kluzák Má rychlost Grunau Baby Atmosféra Podvozek Pohybuje se v TL-3000 Sirius prostředí Civilní letadlo Dolet Má motor VSM-40 Démant PPL Pohon Má využití LF-109 Pionýr Tab. 2: Vymezení komponent OWL ontologie Druhá fáze vývoje ontologie spočívala v nastavení disjunktnosti mezi primitivními a modifikovanými třídami, včetně veškerých podtříd. Nastavení disjunktnosti bylo následně ověřeno pomocí nástroje Run Ontology Tests. Ve třetí fázi následovala specifikace definičního oboru a oboru hodnot u veškerých objektových vlastností. Vymezení definičního oboru D(f) a oboru hodnot H (f) určilo, mezi kterými jedinci z kterých tříd může objektová vlastnost působit. Nastavení globálního omezení bylo taktéž zkontrolováno pomocí nástroje Run Ontology Tests. V této fázi rovněž proběhlo ověření konzistentnosti ontologie pomocí klasifikátoru Pellet. V kontextu s další tvorbou vlastní normalizované ontologie bylo průběžné opakování kontroly konzistentnosti nezbytné. Čtvrtá fáze spočívala v definici kvantitativního omezení (existenční a univerzální) pro primitivní a definované třídy. Pro potřeby vlastní ontologie byly následně specifikovány návrhové vzory rozklad hodnot (axiomy pokrytí třídy) a axiomy uzávěru vlastnosti. V páté fázi tvorby normalizované ontologie byla provedena klasifikace ontologie pomocí nástroje Pellet. Prostřednictvím tohoto klasifikátoru došlo k odvození dalších vztahů (je-podtřídou) mezi třídami a při jeho spuštění rovněž proběhla kontrola konzistence ontologie. Šestá fáze spočívala ve vizualizaci (grafické reprezentaci) kompletního výsledku normalizované ontologie, která byla provedena pomocí nástroje OWLViz. 4. Editor Protégé Protégé je v současnosti podporováno rozsáhlou komunitou uživatelů, vývojářů a vědců, kteří poskytují značné množství pluginů. Představuje volně rozšiřitelný (open-source) editor, distribuovaný pod licencí Mozilla Public License a implementovaný pomocí jazyku Java. Editor je kompatibilní s různými operačními systémy, například s Windows, Unix, Mac OS X, Linux a Solaris. V Protégé existují dva různé způsoby modelování ontologií, tzv. Protégé-Frames a Protégé-OWL [5], [8]. 15

16 Editor se vyznačuje mnoha významnými vlastnostmi, například: rozšiřitelnou plugin architekturou, importem ontologie do různých formátů (do formátu RDF(S), OWL, XML), exportem ontologie do různých formátů (do formátu HTML, OWL, RDF, N-triple, Turtle), možností integrace s různými aplikacemi, podporou odvozování a klasifikací ontologie [8], [9], [10]. Srovnání nástrojů Pro tvorbu vlastní ontologie byly vybrány verze Protégé 3.3.1, a 4.1, které jsou porovnány na základě širokého spektra kritérií. Mezi významná kritéria pro srovnání jednotlivých verzí patří jazyk pro modelování ontologie, možnosti práce s projektem a ukládání ontologie, podpora exportu do různých formátů, pluginy, přívětivost z hlediska ovládání uživatelského rozhraní a instalace softwaru, ale především kritéria pro modelování ontologie (komponenty OWL ontologie, návrhové vzory a práce s ontologií). Samotné porovnání bylo provedeno prostřednictvím tvorby přehledných tabulek. Vzhledem k rozsáhlému počtu měřítek byla následně vyzdvihnuta pouze nejdůležitější kritéria, která mají sloužit pro srovnání vybraných verzí editoru Protégé a doporučení nejvhodnější verze pro zamýšlenou cílovou skupinu studenty předmětu ZT1. Vlastní porovnání jednotlivých verzí (subjektivní pohled) je realizováno tvorbou modelu pro podporu rozhodování pomocí jednoduché grafické aplikace CDP (Criterium Decision Plus). Porovnání pomocí CDP Cílem je tvorba modelu, který umožní rozhodování na základě více kritérií a to při výběru nejvhodnější alternativy ze tří možných (verze Protégé 3.3.1, 4.0.2, 4.1). Vytváření modelu obsahuje pět fází: I. Analýza problému (výběr alternativ a kritérií), II. Konstrukce hierarchie (hierarchie alternativ a příslušných kritérií), III. Ohodnocení hierarchie (ohodnocení kritérií a subkritérií, přiřazení vah), IV. Výběr nejlepší alternativy, V. Analýza výsledků. Pro přiřazení vah, včetně ohodnocení alternativ, kritérií a subkritérií byla zvolena slovní a numerická škála (viz Obr. 1). Vlastní hodnocení kritérií je obsaženo v Tab. 3, hodnocení subkritérií je zahrnuto v Tab. 4 a hodnocení alternativ je vystiženo v Tab. 5. Obr. 1: Škála ohodnocení 16

17 Ohodnocení Cíl Kritérium Slovní škála Numerická škála Výběr nejlepší Modelování Very Important 75 verze ontologie Instalace nástroje Critical 100 Práce s ontologií Very Important 75 Tab. 3: Hodnocení kritérií Ohodnocení Kritérium Subkritérium Slovní škála Numerická škála Modelování Práce se záložkou Critical 100 ontologie třídy Práce se záložkou Critical 100 vlastnosti Práce se záložkou Important 50 metadata Instalace Kompatibilita s OS Very Important 75 nástroje Jednoduchost Critical 100 instalace Práce s ontologií Export do obrázku Very Important 75 Testování úplnosti Important 50 Kontrola Critical 100 konzistence Podpora Critical 100 vizualizace Přednastavené Very Important 75 klasifikátory Debugger Important 50 Podpora v Critical 100 odvozování Generování OWL Important 50 dokumentace Tab. 4: Hodnocení subkritérií Alternativy Subkritérium A (verze 3.3.1) B (verze 4.0.2) C (verze 4.1) Práce se záložkou třídy Práce se záložkou vlastnosti Práce se záložkou metadata Kompatibilita s OS Jednoduchost instalace Export do obrázku Testování úplnosti ontologie

18 Kontrola konzistence Podpora vizualizace Přednastavené klasifikátory Debugger Podpora v odvozování Generování dokumentace Tab. 5: Hodnocení alternativ Obr. 2: Skóre rozhodování (A Protégé 3.3.1, B Protégé 4.0.2, C Protégé 4.1) Na obrázku 2 je zobrazeno skóre rozhodování (výsledek získaný z modelu CDP). Z uvedených výsledků vyplývá, že nejlepší (preferovanou) alternativu představuje verze B, tedy verze Protégé Rozdíl v preferenci verze Protégé oproti verzi Protégé 4.1 je však minimální. Verze Protégé byla vyhodnocena jako nejhorší a tudíž je pro modelování OWL ontologie nejméně vhodná (z hlediska doporučení nástroje pro studenty). Doporučení nejvhodnější verze V případě posuzování jednotlivých verzí editoru Protégé je zapotřebí uvažovat zejména přívětivost z hlediska instalace nástroje a jeho funkcionality. Instalace softwaru, včetně nastavení po dokončení instalace (uvedení nástroje do plného provozu), představují velmi důležitá měřítka, která jsou často opomíjena. Jestliže mají studenti vytvořit vlastní OWL ontologii, měl by pro ně být vybrán takový nástroj, který lze uvést do plného provozu snadno a rychle instalace včetně nastavení po jejím dokončení by neměla zabírat více než půl hodiny času. Pro efektivní práci s konkrétní ontologií je nezbytná přinejmenším podpora vizualizace, klasifikace a kontroly konzistence. Zmíněné funkce musí být pochopitelně určitým způsobem zpřístupněny, kdy uvedení do provozu je mnohdy podmíněno platnostmi jiných pluginů. 18

19 Verze Protégé a 4.1. obsahují přednastavený klasifikátor Fact++ (oproti verzi Protégé 3.3.1), přičemž verze Protégé 4.1. navíc poskytuje další klasifikátor HermiT. Významným aspektem je možnost instalace pluginů přímo v prostředí, kterou verze Protégé (ve srovnání se zbylými dvěma verzemi) nenabízí. Výrazné východisko představuje také otázka kompatibility nástroje s operačním systémem. V průběhu instalace a nastavení po jejím dokončení byly zjištěny značné nedostatky kompatibility verze Protégé s operačním systémem Windows 7, na rozdíl od verzí Protégé a 4.1, jež jsou se všemi uvedenými systémy plně kompatibilní. Další nevyhnutelný aspekt nepochybně reprezentuje uživatelské rozhraní jednotlivých verzí editoru Protégé. V případě porovnání prostředí určitého nástroje musí být zohledněn předpoklad, že hodnocení uživatelské přívětivosti (ovladatelnost GUI) bude do určité míry ovlivněno subjektivním názorem. Z hlediska orientace v prostředí nejvíce vyhovuje verze Protégé 3.3.1, která je nepatrně přehlednější oproti ostatním. Tento fakt lze ovšem přisoudit tomu, že daná verze je z hlediska nabídky funkcionality mnohem chudší než Protégé a 4.1. Při tvorbě ontologie však není na prvním místě preferována přehlednost, nýbrž manipulace s prostředím, respektive práce s jednotlivými záložkami vybrané verze editoru. Verze Protégé poskytuje pouze pět přednastavených záložek a práce s nimi je zde uživatelsky méně přívětivá, přičemž zbylé dvě verze disponují větším počtem záložek, jež jsou mnohem lépe uspořádány a nabízí rozsáhlejší možnosti pro práci s ontologií. V kontextu se zmíněnými aspekty lze tedy jednoznačně usuzovat, že verze Protégé je pro tvorbu ontologie nejméně vhodná. V současnosti představuje poněkud postarší verzi, která již plně nevyhovuje aktuálním požadavkům na funkčnost a přívětivost z hlediska instalace softwaru. V dnešní době jsou k dispozici novější verze editoru Protégé, které byly v průběhu času zdokonalovány a přizpůsobovány z hlediska dostupnosti pluginů a nejčastěji používaných funkcí. V souvislosti s uvedenými myšlenkami je tedy jistým doporučením upustit od výuky předmětu Znalostní technologie I ve starší verzi Protégé 3.3.1, protože v současnosti jsou k dispozici daleko komplexnější verze. V rámci výuky zmíněného předmětu je vhodným doporučením přechod na novější verzi editoru Protégé. Na základě vlastních zkušeností s modelováním OWL ontologie je doporučen výběr alternativy B (verze Protégé 4.0.2). Volba této alternativy nevychází pouze z výsledků získaných v rámci modelu CDP, ale rovněž z vlastní intuice, vypracovaných tabulek a především z praktických zkušeností nabytých při práci ve vybraných verzích editoru Protégé. 5. Závěr V příspěvku je nastíněna problematika ontologií, jejich využití a možná aplikace v praxi. Součástí je rovněž teoretický základ jazyka OWL, včetně naznačení principu tvorby normalizované ontologie, která byla modelována ve vybraných verzích editoru Protégé. Poslední část představuje porovnání daných nástrojů. Na základě provedeného srovnání nástrojů je doporučena verze editoru Protégé pro výuku předmětu ZT1. 19

20 Literatura [1] Lukasová, A., et al. Formální reprezentace znalostí Ostrava: Repronis s.r.o., s. ISBN [2] Svátek, Vojtěch. Ontologie a WWW [online] Databázová konference DATAKON 2002, Brno. Dostupné z WWW: < [3] Svátek, Vojtěch; Labský, Martin. Objektové modely a znalostní ontologie podobnosti a rozdíly [online] Dostupné z WWW: < [4] Allemang, Dean; Hendler, Jim. Semantic web for the working ontologist : Effective Modeling in RDFS and OWL. 1. Amsterdam: Morgan Kaufmann, s. ISBN [5] Hitzler, Pascal; Krotzsch, Markus; Rudolph, Sebastian. Foundations of Semantic Web Technologies. United States of America : Chapman &Hall/CRC, s. ISBN [6] Smith, Michael K.; Welty, Chris; McGuiness, Deborah L., editors. OWL Web Ontology Language Guide [online] Dostupné z www: < [7] Auxilio, María; Nieto, Medina. An Overview of Ontologies [online] Mexiko: 2003, March Technical report. Dostupné z WWW: < [8] Horridge; Matthew, Musen; Mark, et al. Protégé FAQ [online] Dostupné z WWW: < [9] Horridge; Matthew, Musen; Mark, et al. What is Protégé? [online] Dostupné z WWW: < [10] Hepp, Martin, et al. Ontology Management: Semantic Web, Semantic Web Services and Business Applications. 7. New York: Springer, s. ISBN Ing. Kristýna Báčová Univerzita Hradec Králové, Fakulta Informatiky a managementu Rokitanského 62, Hradec Králové, Česká republika kristyna.bacova@uhk.cz Ing. Martina Husáková Univerzita Hradec Králové, Fakulta Informatiky a managementu Rokitanského 62, Hradec Králové, Česká republika martina.husakova.2@uhk.cz 20

21 CISCO IP KALKULAČKA PRO POČÍTAČOVÉ SÍTĚ 1 4 CISCO IP CALCULATOR FOR COMPUTER NETWORKS 1 4 Martin Hátaš, Jan Matyska Abstrakt Vývoj aplikace pro zjednodušení výuky a zrychlení práce studentů v předmětech Počítačové sítě (PSIT1 PSIT4). Software po zadání požadovaných parametrů vygeneruje skript, potřebný pro konfiguraci cílového zařízení (PC, router, switch), který odešle buď na TFTP server běžící na studentském PC nebo pomocí jiné externí služby podporující předání textové informace (DropBox, , Facebook, generátor QR kódů, ). Aplikace bude k dispozici všem studentům PSIT1 4 a bude ji možné využít pro usnadnění práce při výuce, pokud lektor neurčí jinak. Klíčová slova android, počítačové sítě, skript, generátor Abstract Development of application for simplify and accelerate the work of teaching students in the courses Computer Networks (PSIT1 - PSIT4). Software by entering the required parameters generates a script needed to configure the target device (PC, router, switch), which will send either a TFTP server running on a student PC or by using another external services to support the transmission of text information (DropBox, , Facebook, QR code generator, ). Application will be available to all students PSIT1-4 and it will be used to facilitate the work in the classroom, where teacher tells you otherwise. Keywords android, computer networks, script, generator 1. Návrh aplikace Aplikace pomocí jednoduchého průvodce získá veškeré potřebné údaje pro generování konfiguračního skriptu. Průvodce se sestává ze 3 obrazovek. 21

22 Obr. 1: Use Case diagram použití aplikace První obrazovka je společná pro všechny typy konfigurací. Uživatel vybírá jedno z možných zařízení, pro které chce vygenerovat konfigurační skript. Následně student zadá IP adresu rozsahu sítě přiřazenou lektorem, doplní počet hostů v problémové části podsítě a vybere prefix celého rozsahu IP adres. Po vyplnění se přesune stiskem tlačítka Další k následujícímu kroku. Druhá obrazovka se liší podle zvoleného zařízení. Ty jsou zatím tři: PC, router, switch. Pro konfiguraci PC je zapotřebí doplnit název připojení v systému Windows ( Připojení k místní síti, Bezdrátové připojení, ), vybrat adresu podsítě z vygenerovaného seznamu všech přípustných podsítí pro zadaný prefix, adresu rozhraní síťové karty PC a výchozí bránu ( Gateway ). Při konfiguraci routeru musí uživatel vybrat typ síťového rozhraní ze seznamu dostupných (vychází ze specifikace CISCO Ethernet, FastEthernet, GigabitEthernet, Serial, Loopback) a doplnit jeho číslo (typicky číselné označení 0/1, ). Student dále vybere adresu podsítě a adresu vybraného síťového rozhraní. Poslední možné zařízení pro generování konfigurace je switch. Zde je po uživateli požadováno vyplnění čísla VLan a stejně jako v předchozích případech i adresa podsítě, síťového rozhraní zařízení a gateway. Ze všech tří obrazovek druhého kroku průvodce se uživatel dostane stiskem tlačítka Další na poslední obrazovku. Zde je zobrazen vygenerovaný konfigurační 22

23 skript v editačním poli, připravený pro případnou úpravu uživatelem. Pod editačním polem je k dispozici výběr způsobu odeslání skriptu na TFTP server nebo jinou službou. Pokud uživatel zvolí možnost TFTP, musí zadat IP adresu TFTP serveru na který se má textový soubor s konfigurací po stisku tlačítka Odeslat přenést. Druhou možností je volba Ostatní. V tomto případě je uživateli po stisku tlačítka Odeslat zobrazen seznam dostupných programů, které dokáží zpracovat předaný text, takovou aplikací může být ový klient, souborová služba DropBox, sdílení na Facebook a podobně. Vygenerovaný skript pak stačí pouze zkopírovat ze zvoleného zdroje do okna konzole (příkazový řádek Windows nebo SSH konzole). 2. Typický příklad použití Pro názornost uvedeme typický příklad, jak bude aplikace využívána. Celý proces se skládá z několika kroků, které doplníme o snímky obrazovek právě prováděných akcí. Lektor zadá studentům parametry sítě, kterou mají konfigurovat. Studenti tedy mají vytvořit konfiguraci pro síť /20, která má být dimenzována na 172 hostů v podsíti. Student vybavený mobilním zařízením s operačním systémem Android minimální verze 2.1 spustí aplikaci IPCalc, do které zadá předepsané údaje a vybere typ konfigurovaného zařízení router. Obr. 2: Úvodní obrazovka, vyplněné zadání 23

24 Po stisku tlačítka Další se zobrazí druhá obrazovka průvodce konfigurací. Zde student zvolí typ a číslo síťového portu, který má pro svou větev k dispozici FastEthernet 1/1. Následně vybere adresu podsítě /24, na které se domluvil s ostatními studenty, řešícími stejné cvičení v jeho skupině. Následuje volba IP adresy rozhraní přiděleného routeru. Aby si student zjednodušil práci s nastavením dalších zařízení dané větve, vybere poslední adresu rozsahu Obr. 3: Doplnění informací pro nastavení routeru Na poslední obrazovce průvodce student zkontroluje vygenerovaný skript a v případě potřeby jej upraví. Protože je student s vygenerovaným skriptem spokojen a má své zařízení připojené na Wi-Fi v laboratoři, vyplní IP adresu svého počítače , na kterém je předinstalovaný TFTP server. Stiskem tlačítka Odeslat se naváže spojení mezi mobilním zařízením a příslušným TFTP server a skript se odešle ve formě textového souboru. Obr. 4: Kontrola vygenerovaného skriptu a nastavení parametrů TFTP 24

25 3. Samotné řešení systému Systém pro práci s generovanými konfiguracemi pracuje na principu klient/server. Jako server zde vystupuje každá studentská PC stanice samostatně (pod vlastní IP adresou). Na všech PC v učebně je předinstalovaný TFTP server pro interní potřeby výuky PSIT. Toho je využito při návrhu předávání konfiguračního skriptu. Pokud není z nějakého důvodu možné dosáhnout TFTP server z mobilního zařízení (například když není dostupné Wi-Fi připojení, nebo pokud není Wi-Fi router ve stejné síti kvůli změnám v konfiguraci síťových zařízení) je implementována možnost odeslat skript některou ze služeb poskytovanou instalovanými aplikacemi v mobilním zařízení ( , Facebook, ). 4. Serverová část Jako serverová část obecně může být použita jakákoliv TFTP serverová aplikace. Software byl otestován s freeware TFTP serverem od společnosti SolarWind, který je nainstalován v laboratoři počítačových sítí a operačních systémů na každé studentské PC stanici. Technologie TFTP byla zvolena z důvodu podpory tohoto protokolu v Cisco zařízení a tak bude možné v budoucnu nabídnout možnost zasílat vygenerovanou konfiguraci přímo do zařízení. 5. Klientská část Tato kapitola se věnuje popisu klientské mobilní aplikace. Tu můžeme obecně rozdělit na aplikační a prezentační logiku. Tyto celky budou detailněji rozebrány a popsány v následujících podkapitolách Doménový model Pro potřeby aplikace musel být vyhotoven objektový model tříd, se kterým následně pracuje aplikační logika a který slouží jako vstupně výstupní parametry prezentační logice. Tento doménový model vychází ze základních pojmů, objektů a architektury paketových sítí popsaných v dokumentech RFC. Doménový model je zobrazen na následujícím class diagramu. 25

26 Obr. 5: Doménový model tříd Doménové třídy nebyly koncipovány jako hloupé POJO objekty, zapouzdřují tedy alespoň primitivní logiku, zejména validačního nebo konverzního charakteru Aplikační logika Aplikační logika řeší mimo jiné tři základní úkoly a to: Výpočet možných podsítí a masek, výpočet použitelných adres ze zadaných parametrů Vygenerování použitelných konfiguračních skriptů za použití šablon Vytvoření a nahrání souboru s konfigurací na server Výpočet podsítí a masek je prováděno podle metod, které používají samotné aktivní prvky sítě. Jedná se zejména o funkce binární AND a OR. Vzhledem k tomu, že za určitých kombinací zadaných parametrů může být výpočet časově náročný, je prováděn v samostatném vlákně za pomoci implementovaného potomka třídy AsyncTask. 26

27 Ke generování konfiguračních skriptů slouží předpřipravené šablony, do kterých aplikace dosazuje na místo unikátních vyznačených proměnných vypočítané a uživatelem vybrané údaje. K vytváření souboru s konfigurací jsou použity standardní knihovny Javy. Pro odeslání takto vytvořeného textového souboru na TFTP server je použita externí třída org.apache.commons.net.tftp. Model tříd aplikační logiky je zobrazen na následujícím diagramu: 6. Komunikační rozhraní Obr. 6: Model logiky Systém Android využívá pro komunikaci s uživatelem systém xml souborů definujících rozložení grafických prvku a tzv. aktivit svázaných s těmito xml soubory. Obsluha grafického rozhraní a provázání s modelem je prováděna právě v třídách aktivit. Pro každou obrazovku je třeba definovat vlastní aktivitu. V rámci této aplikace je vytvořeno celkem pět aktivit Úvodní obrazovka MainActivity V této aktivitě student zadává do textových polí zadání cvičení. Při stisku tlačítka Další se provede validace zadaných hodnot pomocí ošetření výjimek tříd IPv4Validator a Network. Uživatel je na základě zvoleného zařízení ze seznamu přesunut na jednu z následujících obrazovek Nastavení Routeru RouterActivity Po dokončení výpočtu dostupných síťových adres je studentovi umožněno vybrat jednu z nabízených možností nastavení podsítě v seznamu. Na základě provedené volby se naplní seznam IP adres rozhraní. Aby bylo možné nastavit i typ nastavovaného síťového rozhraní, je potřeba naplnit také seznam těchto rozhraní. Tento seznam je vytvářen ze staticky zadaných údajů v třídě EInterface, které 27

28 vychází ze specifikace Cisco zařízení. Stisknutím tlačítka Další je opět iniciována validace vstupních parametrů obdobně jako ve třídě MainActivity Nastavení Switche SwitchActivity Pokud student zvolil možnost pro generování konfigurace zařízení typu switch, zobrazí se obrazovka svázaná s aktivitou SwitchActivity. I zde se uživateli po vygenerování seznamu síťových adres zpřístupní seznamy pro výběr potřebných parametrů. V tomto případě je nutné zvolit nejen adresu podsítě a IP adresu rozhraní, ale také adresu výchozí brány, tzv. Gateway. Po výběru síťové adresy se automaticky zvolí první odpovídající IP adresa jako adresa rozhraní a poslední dostupná adresa jako výchozí brána. Zde je nutné vyplnit také identifikační číslo VLAN, které je nutné pro nastavení zařízení typu switch Nastavení PC PcActivity Uživateli je umožněno vygenerovat nastavení také pro PC. I zde jsou po vygenerování všech parametrů naplněny seznamy pro jejich uživatelskou volbu. Obdobně jako u zařízení typu switch, je nutné vybrat adresu podsítě, IP adresu rozhraní a adresu výchozí brány gateway. Jako poslední nutný parametr je zde potřeba vyplnit název síťového připojení v operačním systému. Pro operační systém Microsoft Windows, který je nainstalován na všech studentských počítačích, jde například o názvy typu Připojení k místní síti 1, nebo Bezdrátové připojení. Stejně jako u všech předchozích obrazovek se stiskem tlačítka Další provede validace vybraných parametrů Odeslání skriptu UploadActivity Poslední obrazovkou průvodce slouží k odeslání vygenerovaného skriptu některou z nabízených možností. K této obrazovce se uživatel dostane ze všech tří upřesňujících obrazovek (RouterActivity, SwitchActivity, PcActivity). Studentovi je zobrazen vygenerovaný konfigurační skript pro zvolené zařízení v editačním poli. Tento text je možné dále podle potřeby upravit podle dalších požadavků, které nemusí být v aktuální verzi programu dostupné. Následuje volba typu odeslání konfiguračního skriptu. Jako výchozí je označena možnost odeslání skriptu na TFTP server podle uživatelem vyplněné IP adresy. Pokud není mobilní zařízení v dosahu sítě, ve které se TFTP server nachází, je možné zvolit možnost Ostatní a skript odeslat některou z možností nabízených operačním systémem Android, případně některým z nainstalovaných programů. 7. Problémy implementace Při implementaci komunikace TFTP komunikace bylo nutné použít externí knihovnu, protože systém android nemá TFTP komunikaci dostupnou. Problém byl vyřešen implementací knihovny Apache TFTP (org.apache.commons.net.tftp), která umožní použít komunikační kanál TFTP v rámci systému Android. Dalším problémem byla dlouhá časová prodleva přechodu mezi jednotlivými aktivitami při počítání velkého množství podsítí. Tento problém byl vyřešen 28

29 implementací potomka třídy AsyncTask, který mimo výpočetní činnost ovládá ProgressBar na obrazovce a tím tak uživateli vizualizuje průběh výpočtu. 8. Možná rozšíření Jako možným rozšířením této aplikace je využít současnou aplikaci jako modul aplikace nové, která by měla sloužit obdobnému účel jako komplexní generátor konfigurace i pro jiné oblasti konfigurace. Příkladem může být potřeba uživatele nakonfigurovat VPN a přidat nového uživatele, který má do VPN přístup. Na úvodní obrazovce by pak vybral sekci VPN, dále by označil možnost vytvořit VPN a přidat uživatele a vybral by počet uživatelů. Aplikace by následně provedla uživatele jednoduchým průvodcem, ve kterém by uživatel zadal potřebné údaje, a aplikace by pak následně vygenerovala konfigurační skript. Další možné rozšíření spočívá v implementaci protokolu SNMP, který by umožňoval konfigurovat síťové prvky přímo z mobilního zařízení. Literatura [1] MUELLER, John. Příkazový řádek Windows pro Windows Vista, 2003, XP a Vyd. 1. Brno: Computer Press, 2008, 656 s. ISBN [2] EMPSON, Scott. CCNA kompletní přehled příkazů: autorizovaný výukový průvodce. Vyd. 1. Brno: Computer Press, 2009, 336 s. ISBN [3] GOOGLE INC. Android Developers [online] [cit ]. Dostupné z: < Ing. Martin Hátaš Univerzita Hradec Králové, Fakulta informatiky a managementu Rokitanského 62, Hradec Králové, Česká republika martin.hatas@uhk.cz Ing. Jan Matyska Univerzita Hradec Králové, Fakulta informatiky a managementu Rokitanského 62, Hradec Králové, Česká republika jan.matyska@uhk.cz 29

30 SROVNÁNÍ METOD NASTUPOVÁNÍ DO LETADLA Eva Kautzká, Richard Cimler Abstrakt Příspěvek se zabývá popisem a srovnáním různých metod nastupování do letadla, které mají zkrátit potřebný čas pro nástup. Je popsán experiment uskutečněný v maketě dopravního letadla, kde byly různé způsoby nástupu testovány. Tyto metody byly také testovány v námi navržené agentové simulaci a na základě již známých metod byla vytvořena a testována metoda nová. Klíčová slova Multiagentové systémy, modelování, simulace Abstract This contribution is focused on comparison of different aircraft boarding methods which should shorten the boarding time and save costs. The NeLogo agent-based model is introduced, experimental results are presented and innovated boarding methods are suggested. Keywords Multiagent systems, models, simulations 1. Dosavadní výzkum Proces nastupování na palubu letadla je středem zájmu hned několika odlišných skupin. Cestující si nastupování užívají nejen jako nevšední zážitek, ale i z pohledu zákazníka letecké společnosti, což může ovlivnit jak kladně, tak i záporně, jejich budoucí loajalitu. Letecké společnosti a její zaměstnanci mají na efektivitě procesu nastupování také zájem. Kratší čas, který letadlo stráví čekáním u brány, přinese společnosti finanční úspory, úsporu lidských zdrojů (obsluhující personál) a lepší vztahy a atmosféru mezi pasažéry na palubě. Studie z roku 2008 [Nyquist, McFadden, 2008] ukazuje, že každá minuta, kterou letadlo čeká na letišti, navyšuje aerolinkám průměrné náklady ve výši 30 USD. Jinými slovy každá ušetřená minuta přinese společnostem potencionální úspory ve výši přes 16 miliónů USD ročně (za předpokladu, že aerolinky vypraví letů denně). Byly navrženy různé metody nastupování do letadla, tak aby byl tento čas co nejvíce zkrácen. Jednu z těchto metod navrhl J.H.Steffen a popsal jí v článku Optimal boarding method for airline passengers [Steffen, 2008]. Výsledky experimentu s dobrovolníky byly popsány v 30

31 článku Experimental test of airplane boarding methods publikovaném v časopise Journal of Air Transport Management [Steffen, Hotchkiss, 2011] Parametry Steffenova experimentu V experimentu byla použita úzká maketu trupu letadla s 12 řadami po šesti sedadlech s jednou centrální uličkou. Organizátoři najali 72 pasažérů dobrovolníky a komparz z Hollywoodu. Věk cestujících byl v rozmezí od pětiletých dětí až po seniory, většina pasažérů byli dospělí (věk v experimentu nikde nerozhodoval). Pasažéři měli ve většině případů příruční zavazadlo, kufřík na kolečkách nebo obojí. Pouze malá skupinka cestujících neměla zavazadlo vůbec Metody nástupu do letadla Bylo testováno pět metod, nákres pořadí nástupu je znázorněn na obrázku 1. Back front nastupování od zadní do přední části letadla ve specifickém pořadí. Blocks nastupování ve skupinách (blocích) po čtyřech řadách sedadel. Wilma window-middle-aisle, nastupování od okna do uličky. Steffen metoda popsána v [Steffen, 2008]. Random náhodné pořadí pasažérů. Ob. 1: Testované metody 31

32 Pasažéři nastupují do letadla ve skupinách. Čísla na obrázcích znázorňují, jaké je pořadí skupiny, ve které pasažér nastupuje. V rámci skupiny nastupují pasažéři v náhodném pořadí. V metodě Back-front a Steffen je velikost každé skupiny jedna, takže každý pasažér nastupuje v přesně určeném pořadí Závěry Steffenova experimentu Autoři tohoto testu experimentálně ověřili, že mezi délkami trvání jednotlivých metod existují významné rozdíly. Výsledky pokusu podporují tvrzení Steffena [Steffen, 2008], že metoda, která využívá možnosti paralelního ukládání zavazadel (více pasažérů ukládá zavazadlo najednou), dosáhne lepších výsledků než metoda, která paralelní ukládání nevyužije. 2. Vlastní model nastupování na palubu letadla Na základě popisu experimentu [Steffen, Hotchkiss, 2011] byl v prostředí NetLogo 5.0 vytvořen model paluby letadla odpovídající modelu použitému ve Steffenově experimentu umožňující testovat různé metody nástupu za různých nastavení parametrů. Účelem modelu je umožnit simulace různých metod a situací při nastupování na palubu letadla. Chování modelu určuje množství nastavitelných parametrů. V modelu jsou použity reaktivní agenty, jejichž stavy a chování jsou ovlivňovány čistě jejich okolím a ostatními agenty. 3. Testování metod Každá z metod ze Steffenova experimentu má své silné a slabé stránky. Bylo proto zajímavé zjistit, jakých výsledků by dosáhla metoda vzniklá zkombinováním silných stránek jednotlivých metod. Byla proto navržena nová metoda Kautzka 3 viz obrázek 2. Při navrhování byl kladen důraz na to, aby u sebe sedící pasažéři (rodina) nastupovali co nejblíže u sebe. Obr. 2: Vlastní navržená metoda Metoda byla simulována v modelu, její výsledky byly porovnány s časy simulací ostatních metod. Výsledky jsou zobrazeny na grafu č

33 Úspěšnost navržených metod počet kroků Steffen Wilma Random Back front Blocks Kautzka 3 metoda Graf 1: Testování metod Velmi rychlého času dosáhla navržená metoda Kautzka 3. Kombinace metod Wilma, Back front a Steffen zajistila nízký výskyt střetů v uličce i u sedadel a zároveň možnost ukládat paralelně zavazadla. Cestující, kteří sedí vedle sebe (prostřední sedadlo a sedadlo u okna) navíc mohou nastupovat společně, takže není potřeba rozdělovat rodiny, případně řešit nastupování dvojic rodič dítě. 4. Vliv počtu pozdě příchozích pasažérů Metody Steffen, Back front a Kautzka 3 řadí pasažéry podle místa, kde budou v letadle sedět. Při nástupu jdou pasažéři za sebou ve správném přiděleném pořadí. To klade na cestující značné nároky na dochvilnost a disciplinovanost. Rozhodli jsme se proto otestovat, jak velký vliv bude mít narušení přesného pořadí nástupu na jednotlivé metody. Byly testovány časy potřebné pro nástup za předpokladu, že nikdo, 10 % nebo 20 % pasažérů nenastoupí na palubu ve správném (přiděleném) pořadí, ale půjdou náhodně jako poslední. Výsledky všech tří variant jsou zobrazeny v grafu č Vliv pozdě příchozích počet kroků Steffen Wilma Random Back front Blocks Kautzka 3 metoda 0 0,1 0,2 Graf 2: Vliv pozdě příchozích 33

34 Ze získaných výsledků vyplývá, že již v situaci, kdy pouhých 10 % pasažérů nenastoupí ve správném pořadí, dojde u metod, které řadí pasažéry ( Steffen, Kautzka 3 ), k výraznému zhoršení doby potřebné pro nástup. Je to dáno tím, že se v metodách najednou vyskytnou střety v uličce i u sedadel. U metody Random je vliv pozdě příchozích logicky nulový. Můžeme předpokládat, že v reálném provozu bude k narušení pořadí docházet kromě pozdě příchozích bude působit spíše nedisciplinovanost a pohodlnost lidí. Personál seřadí lidi podle místenek a ti pak musí v již přiřazeném pořadí čekat. Řešením by bylo řadit lidi v poslední chvíli před nástupem. To by ovšem v případě špatného časového odhadu mohlo ve výsledku způsobit zdržení nástupu na palubu. U metody Steffen způsobí již 10 % špatně nastupujících zhoršení času téměř na úroveň metody Random. Nabízí se proto otázka, zda má vůbec smysl řadit složitě pasažéry před nástupem na palubu, když již takto malé procento cestujících anuluje předpokládanou časovou úsporu. 5. Závěr V tomto příspěvku byly prezentovány a porovnány různé způsoby řazení pasažérů při nastupování do letadla. Byl vytvořen model v prostřední NetLogo, ve kterém lze tyto metody testovat. Navržený model je možné snadno upravit pro jiný typ letadla, dají se do něj lehce implementovat nově navržené metody. Díky tomu se jedná o univerzální a znovupoužitelný nástroj pro simulování nástupu cestujících na palubu letadla. Literatura [1] KAUTZKÁ, Eva. Agentové simulace hromadné obsluhy. Hradec Králové, Diplomová práce. Univerzita Hradec Králové. [2] NYQUIST, David C. a Kathleen L. MCFADDEN. A study of the airline boarding problem. Journal of Air Transport Management. 2008, roč. 14, č. 4, s ISSN DOI: /j.jairtraman Dostupné z: [3] STEFFEN, Jason H. Optimal boarding method for airline passengers. Journal of Air Transport Management. 2008, roč. 14, č. 3, s ISSN DOI: /j.jairtraman Dostupné z: [4] STEFFEN, Jason H. a Jon HOTCHKISS. Experimental test of airplane boarding methods. Journal of Air Transport Management. 2012, roč. 18, č. 1, s ISSN DOI: /j.jairtraman Dostupné z: Ing. Eva Kautzká Univerzita Hradec Králové, Fakulta informatiky a managementu Rokitanského 62, Hradec Králové, Česká republika kautzka.eva@gmail.com 34

35 Ing. Richard Cimler Univerzita Hradec Králové, Fakulta informatiky a managementu Rokitanského 62, Hradec Králové, Česká republika richard.cimler@uhk.cz 35

36 MOŽNOSTI GEOLOKAČNÍCH WEBOVÝCH APLIKACÍ PRO LBS POSSIBILITIES OF GEOLOCATION WEB APPLICATIONS FOR LBS Jiří Kysela Abstrakt Tento příspěvek se zabývá současnými možnostmi geolokace u webových aplikací na straně klienta, s cílem jejich využitelnosti u lokálně kontextových služeb (LBS). Je zde zkoumán systém geolokace implementovaný prostřednictvím webových technologií standardizovaných konsorciem W3C a v příspěvku jsou také popsány procesy webových klientů probíhající na pozadí, sloužící ke geolokaci za pomoci lokačních a bezdrátových datových technologií. Kromě toho příspěvek poskytuje přehled technologií používaných v LBS a zkoumá vzájemné vztahy jejich komponent (jež tvoří bezdrátové datové a mobilní technologie, lokační a identifikační technologie, mobilní zařízení a informační systémy). Klíčová slova LBS, geolokace, GPS, BTS, IPS, WiFi, WPAN, WLAN, WMAN, WWAN Abstract This contribution is focused on actual possibilities of geolocation in web applications on client side, with goal of using them in location based services (LBS). Main research is focused on geolocation system, implemented through web technologies, standardized by W3C consortium. In contribution are described processes of web clients, running on background, serving for geolocation by location technologies and wireless data technologies. More of this, contribution provides preview of technologies used in LBS and researches relations of their components (which are wireless data a mobile technologies, location technologies and identification technologies, mobile devices and information systems). Keywords LBS, geolocation, GPS, BTS, IPS, WiFi, WPAN, WLAN, WMAN, WWAN 1. Úvod Klíčový význam informací v dnešní době, označované jako informační věk, není třeba zdůrazňovat díky pokročilému vývoji informačních a komunikačních technologií (angl. Information and Communication Technologies, dále jen ICT) lze efektivně komunikačními kanály sdílet informace, s čím dál tím menším omezením 36

37 pak také bezdrátově. I díky tomu, v současnosti moderní prostředky ICT disponují stále vyšší schopností mobility, která tak umožňuje sdílet v globální síťové společnosti informace s rostoucí nezávislostí účastníka na poloze na povrchu Země. Mobilní komunikace se tedy stává požadovanou schopností při přenosu informací. Z tohoto důvodu vyplývá zájem o obohacení informací o novou složku, která by identifikovala uživatele v místě, a umožňovala přenášet data o jeho poloze na Zemi, které se označují jako geodata. Předpona geo-, vychází z řeckého slova Gaia či Gé (označující bohyni Země), vztahující se ve svém původu k naší planetě. Geodata mají tedy vztah k místu na Zemi a značí jeho prostorové souřadnice. Výše uvedené pokročilé schopnosti prostředků ICT tak dávají možnost využívání webových aplikací, které jsou schopny zohlednit lokální informace o uživateli. Tyto aplikace jsou součástí systému nazývaného jako lokální kontextové služby (angl. Location Based Services, dále jen LBS) a umožňují poskytovat informace a služby (informační, navigační, sociální, propagační, monitorovací, manažerské atd.) lokálního charakteru, vztahující se vždy k aktuální poloze jejich uživatele. Následující text příspěvku se tedy zabývá současnými možnostmi geolokace u webových aplikací na straně klienta, s cílem jejich využitelnosti u lokálně kontextových služeb (LBS). 2. LBS a jeho základní stavební kameny V dnešní době nalézají LBS uplatnění především v oblasti dopravy a cestovního ruchu, kde umožňují jejich uživatelům získat dopravní, turistické i komerční informace vztažené k místu kde se právě nachází. Pokročilé ideje LBS však sahají ještě dál, snažíc se zohlednit při poskytování informací také složku času či profilu uživatele. Zjednodušeně lze tedy říci, že LBS vystupují v roli prostředníka mezi informacemi (poskytovanými nejčastěji Internetem či vnější databází) a jejich uživatelem, přičemž hlavní myšlenkou je poskytnout informace k otázkám typu: Kde jsem? Co se děje v mém okolí? Kde jsou moji přátelé? Jak již bylo zmíněno v úvodu, všechny tyto aktivity se postupně vytvořily z původních esenciálních informačních potřeb společnosti, které vývojem daly vzniknout společné základně, kterou dnes tvoří: informace, komunikace, mobilita, identifikace. Tyto základní stavební prvky dnes tvoří skupiny informačních a komunikačních technologií a informačních systémů (angl. Information system, dále jen IS), které jsou kategorizovány v následujících odstavcích Informační systémy IS je pojítkem mezi LBS a ICT, které zastřešuje hardwarovou, softwarovou a datovou základnou. Informační systém umožňuje uchovávat, měnit a analyzovat data a zobrazit je v případě těchto služeb ve formách požadovaných pro 37

38 geografické aplikace. U LBS je využíván především geografický informační systém (z angl. Geographic Information Systém, dále jen GIS) a to nejčastěji v podobě mobilního GIS či webového GIS. Informační systémy jsou však v současnosti velmi nesourodým pilířem - jsou velmi různorodé a jejich použití není žádným způsobem v LBS standardizované Komunikační bezdrátové a mobilní datové technologie Pro LBS je klíčovým prvkem využití bezdrátových a mobilních datových komunikačních technologií, které zde slouží obvykle k přenosu dat z aplikace běžící na serveru k uživateli, jenž vystupuje v roli klienta. Realizace těchto služeb je tedy existenčně závislá na vybudované bezdrátové a mobilní datové komunikační infrastruktuře. Tyto technologie se nejčastěji dělí do skupin dle dosahu šířeného datového signálu, tvořící bezdrátovou datovou síť. Tato typologie definuje následující skupiny: WPAN (Wireless Personal Area Network) - dosah v rámci metrů až několika desítek metrů, WLAN (Wireless Local Area Network) - dosah až několik stovek metrů, WMAN (Wireless Metropolitan Area Network) - dosah několik kilometrů, WWAN (Wireless Wide Area Network) - dosah do několika desítek kilometrů. Jednotlivé bezdrátové a mobilní datové technologie (dostupné v ČR) využitelné v telematických službách a LBS s jejich bližšími parametry a řazením dle výše uvedené topologie zachycuje následující tabulka. Název technologie (verze) WPAN Bluetooth (2.0 class 2) Bluetooth (3.0 class 2) WLAN WiFi (IEEE a) WiFi (IEEE b) WiFi (IEEE g WiFi (IEEE n) WMAN WiMAX (IEEE d) Rok uvedení Přenosová frekvence Max. teoretická rychlost přenosu dat GHz 3 Mbps 10 m GHz 24 Mbps 10 m GHz 54 Mbps 100 m GHz 11 Mbps 110 m GHz 54 Mbps 110 m /5 GHz 150 Mbps 160 m GHz 75 Mbps 8 km Max. teoretická vzdálenost vysílače/přijímače 38

39 WWAN GPRS /síť GSM/ EDGE /síť GSM/ CDMA 1xEV- DO /síť CDMA2000/ UMTS /síť UMTS/ HSDPA /síť UMTS/ HSUPA /síť UMTS/ /1800 MHz /1800 MHz MHz MHz /1900 MHz /1900 MHz 86 kbps 35 km 237 kbps 30 km 2.4 Mbps 54 km 2 Mbps 2 km 14.4 Mbps 6 km 5.76 Mbps 5 km Tab. 1: Vlastnosti bezdrát. technologií dostupných v ČR. Zdroj: [3] - autor 2.3. Mobilní zařízení Mobilní zařízení tvoří jeden ze základních prvků LBS a jsou pro uživatele vstupní branou k těmto službám. Mobilním zařízením s nejvyšší konkurenceschopností pro účely těchto služeb je chytrý mobilní telefon (angl. smartphone), který je tzv. víceúčelovým mobilním zařízením. Opakem tohoto mobilního zařízení jsou tzv. jednoúčelová mobilní zařízení, jako je navigační zařízení GPS (angl. Global Positioning System) či modem pro bezdrátové a mobilní datové technologie. Pro uživatele LBS jsou jednoúčelová zařízení často integrována do víceúčelového mobilního zařízení jako je smartphone, notebook či PDA. V současnosti výrazně narůstá i počet uživatelů disponujících víceúčelovým mobilním zařízením s podporou bezdrátových a mobilních datových technologií, které je tak schopné využívat LBS a mobilní Internet který se u LBS často využívá Lokační a identifikační technologie Lokační technologie dokážou LBS poskytnout údaje o tom, kde se uživatel nachází a toto místo vyjádřit v určitém souřadném systému. Dnes je tímto systémem nejčastěji WGS84 (angl. World Geodetic System 1984) který udává souřadnice v rozsahu +90 až -90 pro zeměpisnou šířku, +180 až -180 pro zeměpisnou délku a také nadmořskou výšku (resp. výšku nad tzv. Geoidem). Lokační a identifikační technologie jsou pro využívání LBS jedním ze základních prvků umožňují realizovat akce jako je určení pozice, identifikace či navigace. Technologiemi, které bývají v současnosti pro účely lokace nejčastěji využívány je GPS, ve spojení s technologií agps (angl. Assisted GPS), která umožňuje rychlejší zaměření polohy a pomáhá zejména v případě, kdy není k dispozici přímá viditelnost tzv. LOS (angl. Line Of Sight, opakem je NLOS angl. Non LOS) mezi přijímačem a navigačními satelity GPS, tedy například uvnitř budov, v tunelech, v podzemí atd. V tomto případě je ovšem přesnost zaměření podstatně menší, stejně tak jako při použití dalších možných alternativ, kterými jsou metoda lokace pomocí 39

40 BTS (angl. Base Transceiver Station) v mobilních sítích GSM či UMTS, či metoda IPS (angl. Indoor Positioning System), která využívá pro lokaci technologie WiFi, Bluetooth a další. K identifikaci potom může být využita technologie NFC (angl. Near Field Communication), RFID (angl. Radio Frequency Identification) či pouze v LBS využívaná identifikační technologie QR-kódů (angl. Quick Response code), která u telematických služeb nenachází uplatnění. Obr. 1: Základní stavební prvky LBS Zdroj: autor 3. Možnosti geolokace pro mobilní aplikace Geolokace je metoda lokace která umožňuje získat geodata pro určení polohy uživatele na povrchu Země. Pro tento účel existuje v současné době metoda GPS lokace (konkurenční Galileo lokace EU se připravuje na spuštění v roce 2014). Tu ovšem nelze mnohdy uplatnit a proto se jako podpůrné metody využívají i jiné technologie, které nemají původní účel pro lokaci. Příkladem jsou vysílače BTS 40

41 u GSM či UMTS mobilních sítí či vysílače bezdrátové datové technologie WiFi, které s použitím matematické metody triangulace síly signálu lze využít pro relativně přesnou lokaci. Dalším možným způsobem je lokace dle IP adresy, tento způsob však patří k nejméně přesným a v případě geolokačních aplikací využívajících mobilního připojení kde je IP adresa přidělována dynamicky, je tato metoda nevhodná. Metoda lokace Průměr. přesnost [metry] Výhody Nevýhody BTS 250 Funkčnost při NLOS. Málo přesná lokace Výborné pokrytí (v ČR 95-99%) území a dostupnost. Krátká doba inicializace. Nízká spotřeba energie baterie. Nezatěžuje síťový přenos. GPS 5 20 Velmi přesná lokace. Nutnost LOS. Výborné pokrytí území a dostupnost. Delší doba inicializace. Nezatěžuje síťový přenos. agps Funkčnost při NLOS. Zatěžuje síťový Poměrně přesná lokace. Výborné pokrytí (v ČR 95-99%) území a dostupnost. přenos (GPRS). IPS (Bluetooth, WiFi, atd.) 1 10 (dle počtu access pointů) Krátká doba inicializace. Nízká spotřeba energie baterie (při GSM). Funkčnost při NLOS. Velmi přesná lokace. Krátká doba inicializace. Tab. 2: V současnosti používané metody lokace. Zdroj: [7], autor Nutná dodatečná bezdr. infrastruktura. Zatěžuje síťový přenos. Lokalizovaný uživatel má dva možné způsoby přístupu k LBS. První je na základě jeho aktivního požadavku - jako tzv. pull služba (např. vyžádají-li si stažení elektronického dokumentu přes Bluetooth), druhým je spouštění aplikace LBS nepřímo, na základě různých událostí jako tzv. push služba (např. trasování v mobilních technologiích). Elementární akce, na které LBS dokáže reagovat, jsou následující: určení pozice, vyhledávání, navigace, 41

42 identifikace, kontrola stavu událostí. Na základě výše uvedených akcí lze vytvořit geolokační webové aplikace pro LBS, které umožní v rámci lokální dopravy a cestovního ruchu zajišťovat široké spektrum služeb, mezi které patří zejména tyto služby: informační služby vyhledání lokálních objektů zájmu (restaurace, hotely) a událostí, elektronický průvodce, lokální předpověď počasí, sociální služby využívání geosociálních sítí (Foursquare, Gowalla, Google Latitude, Facebook places) s možností profilů uživatelů, navigační služby navigace turistická či automobilová, propagační služby dle pozice účastníka, monitorovací a manažerské služby správa vozového parku a mobilních zdrojů, trasování Webové technologie podporující geolokaci Současná mobilní zařízení fungují na různých platformách a zejména smartphony často využívají různé, navzájem nekompatibilní operační systémy (Android, Windows Phone, ios, Symbian, Bada a další). Pro vývoj mobilních aplikací tedy proto existují dva přístupy: Vývoj nativních aplikací - mobilní aplikace nejčastěji vytvořeny v programovacím jazyce C/C++, jehož zdrojové kódy jsou poté přeloženy do nativního kódu pro každou platformu zvlášť. Vývoj multiplatformních aplikací mobilní aplikace vytvořeny v systémech, které jsou nejčastěji spouštěné pomocí různých interpreterů (např. Adobe Flex, Adobe Flash, Microsoft Silverlight, Java, JavaScript, atd.), jež jsou obvykle volně k dispozici pro většinu platforem. Pro LBS které vyžadují aktuální údržbu zdrojových kódů mobilních aplikací je zcela na místě přistupovat k variantě multiplatformního vývoje. Omezení nenativních mobilních aplikací, které neměly přístup k funkcím systému a hardwaru (např. GPS) jsou v současné době již překonány. Na poli multiplatformních mobilních aplikací je to především díky konsorciu W3C (angl. World Wide Web Consortium), které v posledních dvou letech vydalo standardy pro velké množství API specifikací pro přístup webových aplikací k funkcím systému a hardwaru, které jsou již nyní v mobilních webových prohlížečích solidně podporovány. Mezi tyto specifikace patří zejména pro geolokační webové aplikace zcela klíčové Geolocation API Specification (rozhraní na straně webového klienta pro geolokaci), dále pak Battery Status API (rozhraní straně webového klienta pro údaje o stavu napájení mobilního zařízení), Screen Orientation API (rozhraní na straně webového klienta pro údaje o orientaci obrazovky mobilního zařízení), Vibration API (rozhraní na straně webového klienta pro vibraci mobilního zařízení) a mnohé další. Všechny tyto specifikace vyhovují HTML v5 a jako skriptovací jazyk je zde tedy podporován ECMAScript (který je kompatibilní s JavaScript). 42

43 Webové technologie na straně klienta Mobilní prohlížeč Internet Explorer Mobile (ver.9) Opera Mobile (ver.12) Firefox for mobile (ver.10) Google Android (ver.2) Geolocation API Ano Ano Ano Ano Battery Status API Ne Ne Ano Ne Screen Orientation API Ne Ne Ano Ne Tab. 3: Podpora web. technologií v mobilních web. prohlížečích Zdroj: autor 3.2. Geolokační metody, mapové podklady ve webových aplikacích Výše uvedená rozhraní API od konsorcia W3C implementuje každý webový prohlížeč vlastním způsobem - specifikace standardu mu totiž neudávají, jakou metodou mají být geodata získána. Pokud není dostupný GPS přijímač, tak webové prohlížeče využívají další metody lokace, v případě dostupnosti technologie WiFi pak nejčastěji nasbírají údaje o všech dostupných WiFi sítích v okolí (jejich názvy, MAC adresy, sílu signálů). Tyto údaje pošlou přes běžný Http protokol speciální lokalizační webové službě, která je porovná s údaji ve své databázi se známým umístěním (ty byly nashromážděny kupříkladu pomocí Google Car sběrem dat o WiFi sítích) a na základě toho vypočítá pravděpodobnou polohu mobilního zařízení, jejíž souřadnice pošle zpět webovému prohlížeči, který ji předá webové aplikaci. Webovými prohlížeči dvě aktuálně používané webové lokalizační služby jsou od firmy Google a od Microsoftu. Většina webových prohlížečů dnes využívá právě lokalizační službu Google, Internet Explorer pak službu od Microsoftu. Získaná geodata mohou být využita ve webových aplikacích LBS k účelům popsaným výše v kapitole 3. V případě informačních a navigačních služeb jsou často využity i mapové podklady pro zobrazení blízkých bodů zájmu mapy pro využití v geolokačních aplikacích jsou k dispozici od několika poskytovatelů, nejčastěji jsou pak využívány mapy společnosti Google, mapy Bing od společnosti Microsoft, mapy Ovi od společnosti Nokia anebo mapy projektu OpenStreetMap. Význam mobilních mapových podkladů v poslední době roste, což dokazuje i následující tabulka zachycující využití mobilních map v zemích EU. Země Uživatelů k únoru 2009 [tisíce] Uživatelů k únoru 2010 [tisíce] Uživatelů k únoru 2011 [tisíce] EU Velká Británie Německo Španělsko Itálie Tab. 5: Využívání mobilních map v zemích EU Zdroj: [8], úprava: autor 43

44 4. Závěr V tomto příspěvku autor identifikoval základní stavební prvky LBS, které dle něj tvoří informace, komunikace, lokace a identifikace, jejichž vzájemné vztahy zde byly zkoumány a pro každý z těchto prvků byly popsány i jeho technologické základny. Blíže pak byly zkoumány technologie a metody základny pro lokaci, u které byly popsány a porovnány aktuální možnosti geolokace u mobilních webových aplikací na straně klienta, s ohledem na jejich využitelnost u LBS. Příspěvek se dále zaměřoval na systém geolokace prostřednictvím webových technologií standardizovaných konsorciem W3C a byly také popsány procesy webových klientů probíhající na pozadí, sloužící ke geolokaci za pomoci lokačních a bezdrátových datových technologií. Porovnána byla také podpora rozhraní API pro geolokaci implementovaná v současných webových prohlížečích. Literatura [1] ZELENKA, J., BUREŠ, V., PECHANEC, V., ČECH, P., PONCE, D. E-tourism v oblasti cestovního ruchu. Praha: Ministerstvo pro místní rozvoj ČR, ISBN [2] KYSELA, J. Lokálně kontextové služby v praxi [online] [cit ]. Dostupné z: < [3] KYSELA, J. Bezdrátový Internet a technologie Wi-Fi v České republice [online] [cit ]. Dostupné z: < [4] PILGRIN, M. Dive into HTML5. [online] [cit ]. Dostupné z: < [5] PINKAVA, M. Vývoj multiplatformní geolokační aplikace. Bakalářská práce (vedoucí BP Ing. Aleš Pospíšil). Brno, Vysoké učení technické v Brně: [6] PULICAR, M. Hvězdná kartografie: Možnosti geoinformatiky. Bakalářská práce (vedoucí BP doc. RNDr. Milan Konečný, CSc.). Brno, Masarykova univerzita: [7] MEIJERS, S., BOONSTRA, B., KNIPPENBERGH, G. Location Based Services on Mobile Internet [online] [cit ]. Dostupný z: < [8] LANE, N., Mobile geo-location advertising will be a big number in 2015 [online] [cit ]. Dostupný z: < [9] DJUKNIC, G., RICHTON, R. Geolocation and Assisted GPS [online] [cit ]. Dostupný z: < 44

45 [10] BTS, Inc. Mobile Terminal Location Detection Services [online] [cit ]. Dostupný z: < PDFs/260.pdf >. [11] STEINIGER, S., NEUN, M. Foundations of Location Based Services [online] [cit ]. Dostupný z: < iger.pdf>. [12] WANG, Y., BURGENER, D., FLORES, M. KUZMANOVIC, A., HUANG, CH. Towards Street-Level Client-Indenpendent IP Geolocation [online] [cit ]. Dostupný z: < [13] REESE, W., BECKLAND, J. Lost in Geolocation [online] [cit ]. Dostupný z: < 20Geolocation%20Report(1).pdf>. [14] W3C. Geolocation API Specification [online] [cit ]. Dostupný z: < [15] W3C. Battery status API [online] [cit ]. Dostupný z: < [16] W3C. The Screen Orientation API [online] [cit ]. Dostupný z: < ing. Jiří Kysela Univerzita Hradec Králové, Fakulta informatiky a managementu Rokitanského 62, Hradec Králové, Česká republika jiri.kysela@uhk.cz 45

46 SYSTÉM PRO PODPORU VÝUKY PROGRAMOVÁNÍ MIKROKONTROLÉRŮ EDUCATION SUPPORT SYSTEM FOR MICROCONTROLLER PROGRAMMING Jan Loskot Abstrakt Příspěvek představuje systém, který má usnadnit praktickou část výuky programování mikrokontrolérů. Uvádí, proč je užitečné se při výuce zabývat tématem programování mikrokontrolérů a zmiňuje běžně používané nástroje pro podporu výuky. Dále popisuje hardwarovou i softwarovou část navrženého systému. Součástí popisu softwarové části je výčet hlavních oblastí, k jejichž výuce je systém určen. V textu jsou též nastíněny možnosti pro budoucí rozšiřování systému. Klíčová slova Mikrokontrolér, programování, výuka Abstract The article introduces a system that should simplify the practical part of teaching microcontroller programming. It explains why it is useful to be concerned with the topic of microcontroller programming in teaching and mentions tools commonly used for teaching support. It also describes both hardware and software parts of the designed system. The specification of the main issues that should by taught with the aid of the system is included in the software part description. In the text there are also adumbrated possibilities of expanding the system in the future. Keywords Microcontroller, programming, education 1. Úvod Výukový systém je založen na použití mikrokontroléru, což je zvláštní druh počítače, který se od jiných počítačů odlišuje tím, že všechny jeho obvody jsou sdruženy do jediného integrovaného obvodu. Lidé ve vyspělých zemích se v každodenním životě setkávají se značným množstvím mikrokontrolérů, i když si to většinou neuvědomují. Mikrokontroléry bývají vestavěné do běžných domácích spotřebičů, jako je mikrovlnná trouba, pračka, myčka nádobí apod. Nalézají uplatnění také v drobných přístrojích např. 46

47 mobilních telefonech, digitálních fotoaparátech atp. Jsou často využívány i v robotice, automobilovém průmyslu či měřicí technice [1]. Programování mikrokontrolérů je tedy perspektivní obor, který má široké uplatnění. Dalším důvodem, proč se zabývat právě prací s mikrokontroléry, je to, že mikrokontroléry vykazují mnoho společných znaků s jinými druhy počítačů a znalosti nabyté při programování mikrokontrolérů tak vedou k hlubšímu pochopení principů moderní informatiky. Mikrokontroléry jsou pro výuku vhodné díky své jednoduchosti a nízké ceně. Navržený systém má sloužit k praktické části výuky programování mikrokontrolérů. Důležitost praktického procvičování probírané látky zdůrazňuje mj. známý britský pedagog Geoffrey Petty v knize Moderní vyučování [4]: Lépe se věc naučíme, když ji sami děláme, než když jen posloucháme nebo se díváme. A dále: Většina žáků právem považuje praktické užívání dovedností za výbornou metodu učení. Obdobné názory se vyskytují i přímo v oblasti výuky programování mikrokontrolérů. Například v článku [6] odborníci z Aachen University uvádí, že pouhý teoretický výklad problematiky programování mikrokontrolérů nevedl u některých studentů k jejímu pochopení a teprve praktická cvičení zahrnující bezprostřední práci s hardwarem vedla k lepším výsledkům. Tento příspěvek vychází z bakalářské práce autora [2], jejímž cílem bylo navrhnout níže popsaný výukový systém a vytvořit jeho prototyp. Systém poskytuje hardwarové prostředky potřebné pro práci s mikrokontroléry a sadu výukových úloh vytvořených tak, aby umožňovaly systematickou výuku od jednodušších témat k tématům složitějším. Úlohy vedou studenty nejen ke zvládnutí programovacích technik, ale též k hlubšímu pochopení činnosti mikrokontroléru a příslušejícího hardwaru. 2. Obvyklé nástroje pro výuku programování mikrokontrolérů Při výuce programování mikrokontrolérů se běžně používají hardwarové prostředky nazývané vývojové kity. Většinou se jedná o desku plošného spoje osazenou mikrokontrolérem a různými periferními zařízeními jako jsou diody, tlačítka, displej apod., se kterými může mikrokontrolér pracovat. Program napsaný na osobním počítači je přenesen do mikrokontroléru ve vývojovém kitu, kde je možno jeho funkčnost ověřit na zmíněných periferních zařízeních, tedy na reálném hardwaru. Typickým příkladem vývojového kitu je PIC-DEM 2 PLUS [5]. Jinou alternativou jsou modulární vývojové kity a stavebnice. Na rozdíl od klasických vývojových kitů jsou tvořeny několika samostatnými moduly, z nichž typicky jeden je osazen mikrokontrolérem a ostatní obsahují jednotlivé periferie. Hardware systému, o kterém pojednává tento příspěvek, je rovněž navržen jako modulární, je inspirován vývojovým kitem COM644KIT popsaným v [3]. 3. Části výukového systému Výukový systém se skládá ze dvou částí: hardwarové a softwarové. 47

48 3.1. Hardwarová část výukového systému Hardware výukového systému je rozdělen do pěti modulů, které jsou uloženy v samostatných konstrukčních krabičkách. Jedná se o tyto moduly: 1) Modul BASE základní modul s mikrokontrolérem PIC16F876A, 2) modul BYTE se spínačem DIP a osmi LED diodami, 3) modul BUTTONS se čtyřmi tlačítky a osmi LED diodami, 4) modul DISPLAY s dvojmístným sedmisegmentovým displejem, 5) modul KEYBOARD s maticovou klávesnicí. K základnímu modulu lze pomocí desetižilových kabelů zakončených konektory PFL10 připojovat ostatní moduly. Ukázka možného propojení modulů je na obrázku 1. Hlavním důvodem rozdělení hardwaru na jednotlivé moduly je snaha o zpřehlednění systému a zjednodušení práce s ním. Navíc v případě poruchy některého z modulů zůstane zbytek hardwaru funkční. Systém je rozšiřitelný, tzn. je možné jej doplňovat o další moduly. Celý hardware je napájen síťovým adaptérem s výstupním napětím 6V, který se připojuje do modulu BASE. Ostatní moduly jsou napájeny z modulu BASE pomocí zmíněných propojovacích kabelů. Moduly jsou navrženy tak, aby vlivem jejich chybného propojení nebo nesprávného naprogramování mikrokontroléru nemohlo dojít k jejich poškození. Elektrické obvody obsahují množství ochranných rezistorů, které nedovolí překročit maximální povolené proudy jednotlivých součástek. Zapouzdření modulů do konstrukčních krabiček vede ke zvýšené mechanické odolnosti hardwaru. Obr. 1: Ukázka propojení modulů BASE, BUTTONS a BYTE 48

49 3.2. Softwarová část výukového systému Softwarová část systému je tvořena sadou sedmnácti výukových úloh. Úlohy jsou navrženy tak, aby se při jejich řešení studenti prakticky seznámili s architekturou mikrokontroléru a naučili se používat mikrokontroléry v reálných aplikacích. Jednodušší úlohy jsou řešeny v jazyce symbolických adres (tzv. assembleru ) a v jazyce ANSI C, složitější úlohy pouze v ANSI C. U některých úloh je uvedeno několik variant řešení. Každá úloha obsahuje základní zadání, rozbor problému, zdrojový kód (příp. zdrojové kódy) programu s podrobnými komentáři a shrnutí, jaké znalosti a dovednosti jsou při řešení této úlohy získány. Většina úloh navíc obsahuje návrh rozšiřujícího zadání pro hlubší zájemce a příklady konkrétních zařízení, ve kterých by bylo možné získané znalosti a dovednosti využít. Témata výukových úloh Hlavní témata probíraná ve výukových úlohách jsou: Práce se vstupy a výstupy, procvičování logických funkcí (AND, OR, NOT, ), ošetření stisku tlačítek, použití čekacích smyček a časovačů, práce s přerušením, nepřímé adresování, použití paměti EEPROM, práce se sedmisegmentovým LED displejem, obsluha maticové klávesnice, pulzně-šířková modulace. 4. Nástroje pro práci s výukovým systémem Při práci s výukovým systémem je nutné disponovat nástroji pro vývoj programů a nahrávání programů z osobního počítače do mikrokontroléru. Pro vývoj programů bylo použito vývojové prostředí MPLAB IDE 8.66 firmy Microchip. K nahrávání programů byl použit programátor PRESTO, který se připojuje mezi osobní počítač a modul BASE, viz obrázek 2. Obr. 2: Způsob zapojení programátoru PRESTO 49

50 5. Závěr V příspěvku byl představen systém, který má sloužit k výuce programování mikrokontrolérů. Skládá se z hardwarové části tvořené pěti moduly a softwarové části sestávající z výukových úloh. Systém je možno doplňovat dalšími moduly a k nim náležejícími úlohami. Nabízí se možnost rozšířit systém o LCD displej, servomotor, krokový motor, externí paměť, A/D převodník apod. Poněkud náročnější by bylo realizovat komunikaci více mikrokontrolérů mezi sebou nebo mikrokontroléru s osobním počítačem. Možnosti rozšiřování systému jsou skutečně rozsáhlé. Systém je určen především k použití na školách informatického a technického zaměření, kde má napomáhat k hlubšímu pochopení obecných principů počítačového hardwaru a k získání odborných znalostí uplatnitelných v praxi při programování mikrokontrolérů. Literatura [1] AXELSON, Jan. The microcontroller idea book: circuits, programs, & applications featuring the 8052-BASIC microcontroller. Madison(Wisconsin): Lakeview research llc, c s. ISBN [2] LOSKOT, Jan. Systém pro podporu výuky programování mikrokontrolérů. Hradec Králové, Bakalářská práce. Univerzita Hradec Králové, Fakulta informatiky a managementu, Katedra informačních technologií. [3] MATOUŠEK, David. Aplikace procesoru Atmega644 v jazyce C. In: Konstrukční elektronika A Radio: amatérské radio pro konstruktéry, 2011, roč. 16, č. 1, s ISSN [4] PETTY, Geoffrey: Moderní vyučování. Přel. Š. Kovářík. 1. vyd. Praha: Portál, s. Přel. z: Teaching Today. ISBN X. [5] PIC-DEM 2 PLUS [online]. GM Electronic. [cit ]. Dostupné z WWW: [6] STOLLENWERK, André DERKS, Andreas KOWALEWSKI, Stefan. A modular, robust and open source microcontroller platform for broad educational usage [online]. In: WESE 10 proceedings of the 2010 workshop on embedded systems education. [cit ]. Dostupné z doi: / Jan Loskot Univerzita Hradec Králové, Fakulta informatiky a managementu Rokitanského 62, Hradec Králové, Česká republika jan.loskot@uhk.cz 50

51 AGENTOVÝ MODEL POPULAČNÍ DYNAMIKY KELTSKÉHO SÍDLIŠTĚ AGENT-BASED MODEL OF CELTIC POPULATION DYNAMICS Kamila Olševičová a Richard Cimler Abstrakt Naším cílem je aplikovat agentové modelování a sociální simulace v archeologii, konkrétně při zkoumání složitosti a příčin zániku keltské společnosti ve střední Evropě na konci doby železné. Klíčovými aspekty, které je nutné modelovat, jsou formy osídlení, demografické charakteristiky společnosti, stupeň specializace řemeslné výroby atd. Prezentujeme prozatím dílčí výsledky výzkumu, a sice vysvětlující model fungování populační dynamiky keltského společenství, implementovaný v NetLogu. Model byl vytvořen na základě požadavků expertů, kteří současně poskytli doménové znalosti. Model bude sloužit archeologům ke generování časových řad hodnot dostupné pracovní síly a hodnot kalorické spotřeby celého společenství v lokalitě Staré Hradisko. Předpokládáme využití výstupů z modelu při studiu otázek týkajících se zemědělských praktik a využívání orné půdy. Klíčová slova agentový model, archeologie, NetLogo, populační dynamika, sociální simulace Abstract We intend to apply the agent-based modelling and social simulation to study the complexity of the Celtic society in Central Europe in the late Iron Age. Key aspects which form the complexity of the society are settlement forms, demography, the scale of work specialization etc. Our objective is to determine under what conditions the collapse of the Celtic society might have taken place. The paper presents particular results, especially the explanatory population dynamics model implemented in NetLogo. The model is based on specific domain knowledge and general demographic suppositions about birth rates, mortality and immigration. The model allows archaeologists to simulate the time series of available workforce and actual consumption of the population living in the settlement agglomeration Staré Hradisko. The population dynamics model is essential for further husbandry management model. The hypotheses related to extensive and/or intensive agricultural practices should be verified. Keywords agent-based model, archaeology, NetLogo, population dynamics, social simulation 51

52 1. Úvod Agentové modely a simulace se již dvě desítky let používají v mnoha oborech, mj. v archeologii. Archeologové mohou prostřednictvím modelů experimentálně ověřovat správnost svých hypotéz ohledně migrací a kolapsů dávných civilizací. Zatímco dříve se historikové klonili k názoru, že konec určité civilizace vždy souvisel s vyčerpáním některého přírodního zdroje či s jednotlivou epidemií, dnes převládá názor, že kolapsy byly vyvolány kombinacemi více příčin. Analyzovat takové situace je obtížné a agentová simulace se tak stává užitečným nástrojem. Prostřednictvím agentového modelu je možné formalizovat dílčí poznatky o struktuře a fungování vybraného společenství a následně simulovat vývoj společenství v čase. Agentové modelování spočívá v definování mikrostruktur (agenti a pravidla jejich chování, prostředí a procesy v něm probíhající), které jsou postačující k věrohodnému generování požadovaných makrostruktur. Proces tvorby tzv. sociální simulace se skládá ze šesti fází: konceptuální model procesů a objektů reálného světa v souladu s výzkumnými otázkami a hypotézami, implementace modelu ve vhodném vývojovém prostředí nebo jazyce, provedení experimentů a analýza získaných dat, verifikace a případná revize modelu, sdílení výsledků formou publikací a popisů modelů, reprodukování simulace. Realizace agentového modelování a tvorba sociálních simulací přináší s ohledem na relativní novost celého přístupu dva typy výzkumných výsledků: (a) interdisciplinární doménové modely, (b) simulační platformy, metodiky a soubory pracovních postupů. Například Altaweel prezentuje své realistické modely starověké mezopotamské civilizace spolu s implementační platformou ENKIMDU [1], simulace chování prvních hominidů [5] je popisována současně s výkladem používání protokolu ODD [6], výsledky výzkumu kolapsu civilizace Anasazi [2] jsou publikovány společně s replikací modelu v NetLogu [7] atd. Naším cílem je aplikovat agentové modelování a sociální simulace při analýze podmínek a okolností rozvoje a zániku keltského společenství ve střední Evropě v pozdní době železné. Klíčovými aspekty, které formovaly keltskou civilizaci, byly forma osídlení (tzv. oppida), demografické charakteristiky, zemědělské postupy při obhospodařování půdy a výrobě potravin, podíl výrobců a spotřebitelů potravin, míra specializace řemesel, lokální a vzdálené obchodní interakce, existence měny atd. [4]. V tomto příspěvku prezentujeme dílčí výsledky, související s tvorbou vysvětlujícího modelu populační dynamiky. Model je založen na doménových znalostech, poskytnutých experty (archeologické vykopávky různých sídlišť, regionální výzkumné studie v lokalitě Staré Hradisko, demografické studie, úmrtnostní tabulky atd. Model populační dynamiky je základem pro navazující modely tzv. úživnosti oppida. 52

53 Obsah článku je následující. V kapitole 2 vysvětlujeme východiska a poznatky o fungování populační dynamiky, v kapitole 3 prezentujeme implementaci a rozhraní modelu, v závěru zmiňujeme některé další směry výzkumu. 2. Popis modelu Model populační dynamiky objasňuje vývoj populace v závislosti na jejím výchozím stavu (počet jedinců, věkové složení) a na životních podmínkách, jimž je populace vystavena. Vývoj populace je určen čtyřmi faktory: porodností, úmrtností, imigrací a emigrací. Předpokládá se, že všechny populace, pokud je neovlivní jiné faktory či události, rostou (nebo klesají) exponenciálně (nebo logaritmicky) [8]. Byly formulovány následující předpoklady a požadavky na model: Zkoumané období trvalo 100 až 120 let. Počet obyvatel v lokalitě Staré Hradisko byl na počátku sledovaného období mezi 500 a 800, na konci přibližně 2000, nejvýše Alternativně se předpokládá, že výchozí populace byla velmi malá a postupně došlo k jejímu výraznějšímu růstu. Prozatím modelujeme jen první variantu. Pravděpodobně existovaly tři typy rodin: velké rodiny o cca 20 členech, střední rodiny o cca 10 členech a malé rodiny o 4-6 členech. Velká rodina se typicky skládala ze 7 menších dětí (1 kojenec, 3 batolata, 3 děti do 10 let), 3 větších dětí (mezi lety), 2 mladých dospělých (15-19 let), 5 dospělých a 3 starých lidí. Věkové složení jednotlivých rodin se přirozeně drobně lišilo. Sociální role (tj. rozlišení základních rodin, šlechty, otroků apod.) ani rodinné historie (sňatky, počty dětí, počty sourozenců) není třeba v modelu brát v úvahu, protože nemají přímou souvislost se zkoumanou úživností oppida. Plodný věk ženy trval od 15 do 49 let. Typicky měla žena 5,1 dítěte, z nichž se obvykle pouze dvě dožily dospělosti. Doba dožití jedince se určuje dle úmrtnostních tabulek. K dispozici jsou tabulky platné pro ženskou populaci ve starém Římě, zpracované pro pětiletá období [9]. K přepočtu původních tabulek na tabulky jednoroční je třeba aplikovat vhodnou matematickou metodu [3]. Průměrný roční přírůstek populace je s ohledem na vysokou míru dětské úmrtnosti odhadován na 0,2%. Velmi pravděpodobně docházelo k imigraci, přibližně takto přibyla jedna malá nebo středně velká rodina každých pět let. Emigrace nebude v modelu uvažována, neboť mohla být jednou z příčin kolapsu osídlení a jako taková bude později zkoumána samostatně. Dostupná pracovní síla je měřena počtem osob, schopných pracovat s pluhem, což zřejmě byli muži ve věku 15 až 49 let. 53

54 Denní kalorická spotřeba celé populace může být vypočtena na základě tabulkových hodnot, platných pro jednotlivé věkové skupiny (např pro batolata, 2000 pro malé děti a staré lidi, 2500 pro chlapce mezi 10 a 14 lety apod.). Vstupní hodnoty je třeba zadávat pomocí prvků v rozhraní modelu: posuvník pro nastavení délky simulovaného období ( let), posuvník pro nastavení výchozího počtu obyvatel (500 až 800), posuvník pro nastavení výchozího počtu velkých rodin (20 až 40), seznam dostupných úmrtnostních tabulek pro výpočet očekávané doby dožití, posuvník pro nastavení parametru, který figuruje ve výpočtu míry porodnosti, posuvník pro nastavení parametru, který figuruje ve výpočtu míry imigrace. Sledovány jsou dvě výstupní proměnné: časová řada kalorické spotřeby populace, časová řada dostupné pracovní síly. Kromě výstupních proměnných, jejichž hodnoty budou později využity v dalších modelech, je rovněž podstatné, aby se celá simulovaná populace jevila jako normální, tj. aby přirozeně přibývala a aby se významně neměnila její věková struktura. 3. Implementace Model byl implementován v NetLogu. Definovány jsou dva typy agentů: household-agent reprezentant domácnosti, inhabitant-agent reprezentant jedince, přiřazený právě jedné domácnosti. Sada globálních proměnných slouží k evidování charakteristik domácností a celé populace (num-of-sucklings, num-of-todlers, num-of-children, num-of-older-children, num-of-young-adults, num-of-adults, num-of-elder, souhrnné proměnné num-ofinhabitants, actual-workforce, actual-consumption). Při inicializaci modelu je vytvořen požadovaný počet velkých domácností. Počet malých a středních domácností je poté odvozen tak, aby byl dodržen nastavený celkový výchozí počet obyvatel. Pro každou domácnost je vygenerován adekvátní počet členů vyhovujícího věkového složení (viz. též graf 1), předpokládá se normální rozdělení s přesně nastavenou střední hodnotou a rozptylem. Parametry rozdělení byly nalezeny experimentálně. Procedura, zapsaná v syntaxi NetLoga, je tato: let local-random random 35 if local-random < 4 [report random 2] if local-random < 6 [report 2 + random 2] if local-random < 11 [report 4 + random 6] if local-random < 15 [report 10 + random 5] ; sucklings ; todlers ; children ; older-children 54

55 if local-random < 18 [report 15 + random 5] if local-random < 31 [report 20 + random 30] if local-random < 35 [report 49 + random 20] ; young-adults ;adults ; elder Graf 1: Věková struktura populace při inicializaci modelu Aktuální struktura populace je znázorněna pomocí diagramů (obr. 1), z nichž lze vyčíst počty členů každé domácnosti a jejich věk (s uspořádáním po směru hodinových ručiček). Vývoj populace v čase je znázorněn grafem (graf 2 vlevo). Hodnoty z grafu lze po skončení simulace exportovat a následně pomocí skriptu vykreslit mj. kumulativní spojnicový graf (graf 2 vpravo). Dynamika modelu je tvořena dvěma vnořenými cykly, v rámci nichž dochází k aktualizaci stavu household-agentů a inhabitant-agentů. V každém kroku chodu simulace, který odpovídá jednotlivému simulovanému roku, proběhnou tři procedury: Birth-rate procedura obsahuje pravděpodobnostní vzorec, který definuje okolnosti, za nichž je do modelu přidán další inhabitant-agent. Ve vzorci se pracuje s počtem plodných žen v domácnosti a s hodnotou parametru birthprobability. Mortality-rate procedura obsahuje pravděpodobnostní vzorec, který definuje okolnosti, za nichž je z modelu odstraněn inhabitant-agent. Ve vzorci se pracuje s úmrtnostními tabulkami. Používáme jednak původní pětileté tabulky, jednak tabulky interpolované metodami popsanými v [3]. Immigration-rate procedura obsahuje pravděpodobnostní vzorec, který definuje přidání nové malé nebo střední rodiny do modelu na základě hodnoty parametru immigration-probability. 55

56 Graf 2: Vývoj simulované populace Obr. 1: Vizualizace věkových struktur domácností Graf 3: Struktura populace v prvním a posledním kroku simulace 56

57 4. Závěr Model populační dynamiky keltského sídliště umožňuje experimentování s procedurami birth-rate, mortality-rate, immigration-rate. Použité vzorce mohou být dále modifikovány na základě požadavků zadavatelů (např. mohou být vloženy jiné kalorické tabulky, jinak interpolované úmrtnostní tabulky, nové parametry normálních rozdělení použitých při inicializaci modelu apod.). Model je možné rozšířit dodefinováním dalších vlastností agentů (sociální role, osobní historie), čímž se model stane realističtějším a současně složitějším. Výstupy modelu simulace populační dynamiky budou vstupem zemědělského modelu. Časové řady hodnot dostupné pracovní síly a hodnot kalorických spotřeb mohou být následně využity k odhadu tzv. úživnosti oppida (tj. ke stanovení maximálního počtu obyvatel, který se mohl v dané lokalitě uživit), což je jedna z vysvětlujících proměnných, důležitých k porozumění mechanismům, které vedly k zániku oppida. Je známo, že 80 procent denní kalorické spotřeby keltské společnosti bylo pokryto obilninami. To znamená, že způsob hospodaření a množství více či méně úrodné zemědělské půdy dostupné v pěší vzdálenosti okolo oppida úzce souvisí s možnostmi přežití a rozrůstání společenství. Archeologové přitom předpokládají, že keltští zemědělci v okolí lokality Staré Hradisko využívali určitou kombinaci intenzivního a extenzivního pěstování obilnin. Zemědělský model bude sloužit k ověření těchto domněnek. Použití jednotlivého agentového modelu je někdy kritizováno coby příliš zjednodušující a málo flexibilní. My předpokládáme, že naše kombinace několika relativně nezávislých modelů, konstruovaných tak, že výstupy z jednoho modelu se stanou vstupem modelu dalšího, dovolí tyto případné nedostatky eliminovat. Model populační dynamiky pracuje s jednotlivými obyvateli a domácnostmi coby agenty, zatímco v zemědělském modelu bude základní jednotkou obhospodařovaná ploška území. Věrohodnost modelu populační dynamiky lze posoudit prozkoumáním pomocného grafu 3, který jsme vytvořili v EXCELu a který odpovídá výchozí populaci o 500 obyvatelích (pro větší výchozí populace jsou grafy obdobné). V grafu je znázorněna věková struktura populace na počátku a konci chodu simulace. Je zřejmé, že věkové složení se výrazně neproměnilo. V rámci dalšího výzkumu se zaměříme na: upřesnění parametrů modelu populační dynamiky, vývoj zemědělského modelu, vývoj skriptů a dalších nástrojů pro přehlednější prezentaci a vizualizaci výstupů simulace. Poděkování Příspěvek vznikl v rámci řešení výzkumného projektu GAČR č. P405/12/0926 Social modelling as a tool for understanding Celtic society and cultural changes at the end of the Iron Age. 57

58 Literatura [1] ALTAWEEL, M. Investigating agricultural sustainability and strategies in northern Mesopotamia: results produced using socio-ecological modeling approach. In Journal of Archaeological Science, 35, s [2] AXTELL, R.L. et. al. Population Growth and Collapse in a Multi-Agent Model of the Kayenta Anasazi in Long House Valley. In Proceedings of the National Academy of Sciences, 99, S [3] BAILI, P. et al. Comparison of Four Methods for Estimating Complete Life Tables from Abridged Life Tables Using Mortality Data Supplied to EUROCARE-3. In Mathematical Population Studies, 12, s [4] DANIELISOVÁ, A. The oppidum of České Lhotice and its hinterland. Doktorská dizertační práce, nepublikováno, [5] GRIFFITH, C.S. et al. HOMINIDS: An agent-based spatial simulation model to evaluate behavioral patterns of early Pleistocene hominids. In Ecological Modelling, 221, S [6] GRIMM V. et. al. The ODD protocol: A review and first update. In Ecological Modelling, 221, [7] JANSSEN, M. Understanding Artificial Anasazi. In Journal of Artificial Societies and Social Simulation, 12, (4) 13. [8] DE ROOS, A.M. Modeling Population Dynamics. Studijní materiál, Universiteit van Amsterdam, [9] SALLER, R. Patriarchy, Property and Death in the Roman Family. Cambridge, doc. RNDr. Kamila Olševičová, Ph.D. Univerzita Hradec Králové, Fakulta informatiky a managementu Rokitanského 62, Hradec Králové, Česká republika kamila.olsevicova@uhk.cz Ing. Richard Cimler Univerzita Hradec Králové, Fakulta informatiky a managementu Rokitanského 62, Hradec Králové, Česká republika richard.cimler@uhk.cz 58

59 PROBLÉM OBCHODNÍHO CESTUJÍCÍHO V EXTREMÁLNÍCH ALGEBRÁCH TRAVELING SALESMAN PROBLEM IN EXTREMAL ALGEBRAS Alena Pozdílková Abstrakt Problém obchodního cestujícího patří mezi důležité optimalizační problémy s širokým praktickým využitím. Kromě standardních metod řešení, jako jsou metody s využitím teorie grafů, heuristické metody či evoluční techniky, jej lze úspěšně optimalizovat s využitím extremálních algeber, a to s využitím speciálního typu matic matic Mongeovských. V tomto článku bude tento problém interpretován ve třech základních extremálních algebrách, a to v max-plus algebře, v max-min algebře a v max- drast algebře. V každé z těchto algeber má jinou interpretaci, ovšem ve všech lze tento problém úspěšně řešit a redukovat jeho složitost. Klíčová slova Problém obchodního cestujícího, max-plus algebra, max-min algebra, max-drast algebra, Mongeovská matice Abstract Traveling Salesman Problem is one of the important optimization problems with a wide practical use. In addition to standard solution methods, such as methods using graph theory, heuristic methods or evolutionary techniques, it can be successfully optimized using extremal algebras, making use of a special type of matrices Monge matrices. In this paper, this problem will be interpreted in three basic extremal algebras, in max-plus algebra, the max-min algebra and the max-drast algebra. In each of these algebras has a different interpretation, but all can be successfully addressed this problem and reduce its complexity. Keywords Traveling salesman problem, max-plus algebra, max-min algebra, max-drast algebra, Monge matrix 1. Problém obchodního cestujícího S problémem obchodního cestujícího se v praxi lze setkat často. V případech, kdy je potřeba distribuovat určitý materiál od jednoho či několika málo dodavatelů 59

60 k většímu množství spotřebitelů, se okružním spojením ušetří mnoho nákladů v porovnání se situací, kdy by se každá cesta realizovala odděleně. V této kapitole bylo čerpáno z (APPLEGATE, 2006) a (LAWLER, 1985). Problém obchodního cestujícího představuje hledání nejkratší okružní cesty mezi M městy, která mají předem známé vzdálenosti. Tyto vzdálenosti vlastně představují náklady na jednotlivých cestách (předpokládají se náklady na cestu z města A do města B stejné jako na cestu z B do A). Cílem je tyto celkové náklady minimalizovat. Problém obchodního cestujícího má široké uplatnění v praxi. Může se jednat o distribuci materiálu, problémy z oblasti informačních technologií, například prohledávání webových stránek, optimalizace datových toků v sítích, optimalizace v přístupu k datům v distribuovaných databázích nebo o problémy managementu. Problém obchodního cestujícího patří mezi tzv. NP-těžké úlohy, což jsou úlohy velmi dobře formulovatelné, ale velmi těžko řešitelné (ne v polynomiálním čase). V praxi se řeší například heuristickými metodami, nebo také pomocí genetických algoritmů. Jedním z dalších způsobů, jak lze daný systém úspěšně optimalizovat, je využití Mongeovských matic v extremálních algebrách. 2. Mongeovské matice V následujících kapitolách, které se týkají extremálních algeber a Mongeovských matic, bylo čerpáno z (BURKARD, 1996), (BURKARD, 1991), (CUNINGHAM-GREEN, 1979) a (PARK, 1991). V rámci extremálních algeber jsou zkoumány i speciální typy matic. Je to hlavně z důvodu, že některé složité algoritmy či postupy lze pro matice splňující nějaké omezení či podmínku řešit mnohem jednodušeji. Mezi takovéto typy matic patří například matice cirkulantní, diagonální, dvoudiagonální nebo matice Mongeovské, kterými se budeme dále zabývat. Mongeovské matice v extremálních algebrách jsou speciální matice, splňující následující podmínku: kde i, k jsou řádkové indexy, kde a j, l jsou sloupcové indexy, kde. ( ) 3. Max-plus algebra V max-plus albegře jsou operace definovány následovně: ( ) 60

61 Problém obchodního cestujícího lze v max-plus algebře interpretovat jako hledání nejkratší okružní cesty mezi M městy, která mají předem známé vzdálenosti. Tyto vzdálenosti vlastně představují náklady na jednotlivých cestách. Cílem je tyto celkové náklady minimalizovat. Věta: Pokud je matice, vyjadřující náklady na jednotlivých cestách v problému obchodního cestujícího v max-plus algebře Mongeovská, potom existuje optimální cesta, která lze nalézt pomocí dynamického programování algoritmem o složitosti O(n2). 4. Max-min algebra V max-min algebře jsou operace definovány následovně: ( ) ( ) V max-min algebře lze graf interpretovat jako síť, kde ohodnocení jednotlivých hran představují dané minimální průtoky. Problém obchodního cestujícího je tak modifikován na hledání okružní cesty s maximální propustností touto sítí. Věta: Pokud je matice, vyjadřující průtoky sítí v problému obchodního cestujícího v max-min algebře Mongeovská, potom existuje optimální cesta, která lze nalézt pomocí dynamického programování algoritmem o složitosti O(n 2 ). 5. Max-drast algebra V max-drast algebře jsou operace definovány následovně: ( ) ( ) pokud nebo jinak V max-drast algebře lze problém obchodního cestujícího modifikovat na hledání cesty danou sítí s maximální spolehlivostí. Vzhledem k tomu, že v Booleovské algebře na množině { } se operace drast a min shodují, lze pro matice v max-drast algebře formulovat obdobné tvrzení jako pro matice v max-min algebře. Věta: Pokud je matice, vyjadřující spolehlivost cesty danou sítí v problému obchodního cestujícího v max-drast algebře Mongeovská, potom existuje optimální cesta, která lze nalézt pomocí dynamického programování algoritmem o složitosti O(n 2 ). 6. Závěr Článek popisuje problém obchodního cestujícího, a to jak v obecné rovině, tak i s využitím extremálních algeber. V těchto algebrách využívá speciálního typu matic matic Mongeovských. Praktická interpretace a optimalizace daného problému je popsána ve třech základních extremálních algebrách max-plus algebře, max-min algebře a max-drast algebře. V max-plus algebře se vlastně jedná o standardní hledání nejkratší cesty mezi určitým počtem měst s pevně danými náklady na 61

62 jednotlivých cestách, v ostatních algebrách je ovšem interpretace zcela odlišná. V max-min algebře se jedná o hledání cesty s největší propustností v dané síti, kde jsou na jednotlivých hranách dané minimální průtoky. V max-drast algebře je tento problém dále modifikován na hledání cesty danou sítí s maximální spolehlivostí. Ve všech těchto algebrách je tento problém s využitím Mongeovských matic optimalizován a jeho složitost oproti obecnému případu výrazně redukována, a to na kvadratickou složitost. Literatura [1] APPLEGATE, D. L., BIXBY, R. E., CHVÁTAL, V., COOK, W. J The Traveling Salesman Problem A Computational Study. Princeton University Press. [2] BURKARD, R., E., KLINZ, B., RUDOLF, R Perspectives of monge properties in optimization. In DiSC.APL.MATH, 70, pages [3] BURKARD, R., SANDHOLZER, W Efficiently solvable special casem of bottleneck traveling salesman problems. In DiSC.APL.MATH, 32, pages [4] CUNINGHAM-GREEN, R, A , Minimax algebra, Lecture notes in Economics and Mathemtaics systems, 166, Springer-Verlag, Berlin. [5] LAWLER, E. L., LENSTRA, J. K., RINNOY KAN, K. H. G., SHMOYS, D. B The Traveling Salesman Problem. John Wiley and Sons Ltd., England. [6] PARK, J., K A special case of the n-vertex travelling salesman problem that can be sloved in O(n) time. In INFORM.PROCESS.LETT, 40, pages Mgr. Alena Pozdílková Univerzita Hradec Králové, Fakulta informatiky a managementu Rokitanského 62, Hradec Králové, Česká republika alena.pozdilkova@uhk.cz 62

63 TABULOVÁ ARCHITEKTURA JAKO METODA SPOLUPRÁCE V MULTIAGENTOVÝCH SYSTÉMECH BLACKBOARD ARCHITECTURE AS A COOPERATION MECHANISM IN MULTI-AGENT SYSTEMS Jan Procházka Abstrakt Tento příspěvek se věnuje tabulové architektuře a jejímu použití v multiagentových systémech. Vychází ze stejnojmenné diplomové práce autora. V příspěvku jdou prezentovány principy tabulové architektury a tabulových systémů a možnosti použití tabulové architektury v multiagentových systémech jako způsobu řešení spolupráce agentů. Praktické použití tabulové architektury v multiagentových systémech je v příspěvku demonstrováno představením implementace řešení konkrétní logistické úlohy v modelovacím nástroji NetLogo. Klíčová slova Multiagentové systémy, NetLogo, spolupráce v multiagentových systémech, tabulová architektura, tabulové systémy. Abstract This contribution deals with the blackboard architecture and its use in multi-agent systems. It is based on the diploma thesis of the author. The blackboard architecture is explained, blackboard systems and multi-agent systems are described the cooperation between agents using the blackboard architecture is suggested. To demonstrate the blackboard architecture practically the implementation of a specific logistics problem solution in a form of the NetLogo model is provided. Keywords Blackboard architecture, blackboard systems, cooperation in multi-agent systems, multi-agent systems, NetLogo. 1. Úvod Systémy typu tabule se používají při řešení komplexních a špatně strukturovaných či distribuovaných problémů. Inteligentní agenti zdroje znalostí sdílejí společnou datovou strukturu tabuli a společný kontrolní mechanizmus řídící komponentu [1,2]. Systémy postavené na základě tabulové architektury používají oportunistické uvažování. To znamená, že znalosti, kterými systém agentů 63

64 disponuje, se používají ne v přesně stanoveném pořadí, ale v nejpříhodnější možnou dobu a nejlepším možným způsobem. Tato forma usuzování je vhodná tam, kde jsou znalosti o řešení problému dostupné ve formě autonomních, nezávislých modulů, které na řešení společného problému mohou spolupracovat [1,2,3]. Při návrhu multiagentových systémů může být jedním z požadavků zajistit efektivní centrální spolupráci ve skupině nezávislých agentů. Naplnění tohoto cíle může být realizováno právě použitím tabulové architektury, přičemž je třeba si ale uvědomit, že se tím značně mění tradiční přístup multiagentových systémů k autonomii jednotlivých agentů [2]. 2. Metafora tabulového systému Způsob fungování systémů s tabulovou architekturou ilustruje metafora problémtabule-skupina řešitelů, která je popsána např. v [1]: Skupina lidských expertů se nachází před tabulí, na které je specifikován problém, který mají společně vyřešit. Tabule je použita jako pracovní plocha pro vývoj řešení. Problém je popsán na tabuli spolu se všemi počátečními informacemi. Experti sledují tabuli a její obsah. Hledají příležitost, kdy můžou do vývoje řešení zasáhnout použitím svých znalostí. Pokud některý z expertů nalezne na tabuli dostatek informací k tomu, aby mohl přispět k vývoji řešení, zaznamená svůj příspěvek na tabuli. Tento příspěvek může umožnit ostatních expertů použít zase jejich specifickou znalost a dále přispět k řešení. Celý proces postupného přidávání příspěvků k řešení pokračuje, dokud není nalezeno řešení problému. Tato metafora demonstruje základní charakteristiky tabulových systémů [1]: a) Nezávislost specializací a znalostí jednotlivých expertů členové řešitelského týmu disponují rozdílnými druhy znalostí a jsou na sobě nezávislí. Tabulové systémy obsahují znalostní moduly nazývané zdroje znalostí. b) Rozdílný přístup a různé techniky řešení problému specialisté přemýšlejí o řešení problémů odlišně, což jim ale nebrání ve spolupráci. V tabulových systémech bývá způsob nakládání s informacemi značně variabilní. c) Flexibilita v reprezentaci informací zanesených na tabuli v tabulové architektuře nejsou diktována žádná explicitní omezení na druh a formát informací zaznamenaných na tabuli. d) Společný jazyk pro vzájemnou iteraci expertů spolupráce specialistů je podmíněna jednotným chápáním informací na tabuli. V tabulových systémech je třeba zajistit společný jazyk pro jednotnou interpretaci informací. e) Možnost vyhledávání specifických informací na tabuli řešení komplexních problémů znamená velký počet příspěvků k řešení. Je třeba rychle lokalizovat správné informace. Lze použít i více tabulí či rozdělení tabule na dílčí úrovně. f) Událostmi řízená aktivita jednotlivých expertů příležitosti k přispění k řešení jsou vázány na specifické události, jimiž jsou změny na tabuli a externí události. Aktivace zdrojů znalostí v tabulové architektuře může fungovat na základě jejich 64

65 objednávky specifikující, o jaké události se zajímají, namísto toho, aby každý zdroj znalostí samostatně sledoval celou tabuli a hledal objekty svého zájmu. g) Potřeba kontrolního mechanismu mezi experty na nějakou událost může reagovat více specialistů. Musí dojít k dohodě o pořadí. Možností je zavedení manažera řešení, který určuje pořadí na základě odhadu efektu potenciálních příspěvků k celkovému řešení. Tuto roli hraje řídící komponenta. h) Inkrementální vývoj řešení řešení je vytvářeno postupně přidáváním příspěvků od jednotlivých specialistů. Každý další příspěvek je zpřesněním nebo rozšířením některého z předchozích příspěvků od dalších řešitelů. 3. Model, komponenty a proces práce tabulového systému Základní model tabulové architektury pro řešení problémů se skládá ze tří komponent [1,2]: Zdroje znalostí (Knowledge sources) nezávislé výpočetní moduly, které obsahují potřebné znalosti pro řešení problému. Nepotřebují komunikovat navzájem mezi sebou či vědět o existenci ostatních zdrojů znalostí. Každý zdroj znalostí má své vlastní podmínky, za kterých může přispět ke společnému řešení (triggering conditions). Nezávislost zdrojů znalostí přináší funkční modularitu. Tabule (Blackboard) globální úložiště pro vstupní data, mezivýsledky a další informace. Zdroje znalostí vzájemně spolupracují skrze změny na tabuli. Řídící komponenta (Control Shell) provádí rozhodnutí o využití zdrojů znalostí. Určuje směr, kterým se bude řešení odvíjet. Řídící komponenta poskytuje možnost používat informace na tabuli oportunisticky (nejlepším možným způsobem). Proces práce komponent tabulového systému probíhá v opakujících se krocích, dokud není nalezeno řešení nebo dokud není systém zastaven z jiných důvodů (např. vyčerpání přidělených zdrojů či vypršení časového limitu na řešení): Krok 0 Inicializace systému. Zaznamenání problému na prázdnou tabuli. Inicializace zdrojů znalostí a řídící jednotky. Zdroje znalostí informují řídící jednotku o událostech, které je zajímají. Krok 1 Spuštění zdroje znalostí. Některý z aktivovaných zdrojů znalostí provede svůj příspěvek k řešení, který zaznamená na tabuli. Krok 2 Vyhodnocení změn. Řídící jednotka vyhodnocuje změny na tabuli a aktivuje zdroje znalostí, které mohou dále přispět k řešení na základě specifických událostí. Krok 3 Návrhy dalších možných příspěvků k řešení. Aktivované Zdroje znalostí na základě dohledaných detailnějších informací na tabuli navrhují své příspěvky. Krok 4 Výběr dalšího kroku řešení. Řídící jednotka vybere zdroj znalostí, který příspěvek k řešení skutečně provede. Krok 5 Systém se vrací ke kroku 1. 65

66 Tabule Spuštěný aktivovaný zdroj znalostí Zdroj znalostí Zdroj znalostí Zdroj znalostí Nejlepší ZZ ke spuštění Události Řídící komponenta Nově aktivované ZZ Čekající aktivované zdroje znalostí Obr. 1: Model tabulového systému 4. Výhody a omezení použití tabulové architektury Použití tabulové architektury při návrhu a implementaci systémů řešících komplexní problémy přináší řadu výhod, ale má i své limitující faktory [2]. Benefity a omezení použití tabulové architektury mohou být prezentovány v párech výhoda-omezení: a) Výhoda: Flexibilita systém zdroje znalostí nejsou pevně svázány a mohou být do systému přidávány za běhu řešení. Tato vlastnost poskytuje prostor pro škálovatelnost řešení. Omezení: Komunikace a jazyk je třeba najít vyvážení mezi specializovaným jazykem vyhovujícím konkrétní úloze, kterému by ale rozuměly jen některé zdroje znalostí, a obecným jazykem srozumitelným všem zdrojům znalostí. b) Výhoda: Široká škála možných problémů tabulová architektura není vázána na specifickou skupinu úloh či doménu. Lze ji použít pro širokou škálu aplikací od logistických úloh, přes rozpoznávání, až k diagnostickým systémům. Omezení: Náročnost zajištění spolupráce implementace funkcionality řídící jednotky může být náročná. Zjištění, který ze zdrojů znalostí může aktuálně nejvíc přispět, bývá výpočetně náročné. c) Výhoda: Možnost výběru zdrojů znalostí konkrétní aspekt problému dokáže řešit více než jeden zdroj znalostí. Řídící jednotka může vybírat z většího množství zdrojů znalostí ten, který je v dané chvíli pro řešení nejpřínosnější. Omezení: Zajištění znalostí určit jaké druhy zdrojů znalostí budou v systému potřeba pro řešení dané třídy problémů, bývá velmi komplikované. 66

67 d) Výhoda: Různé úrovně abstrakce tabulové systémy pracují s informacemi na různé úrovni abstrakce. Zdroje znalostí se mohou soustředit jen na odpovídající úroveň tabule. Omezení: Volba úrovně detailu informací je třeba vyřešit otázku úrovně detailů na výstupu jednotlivých příspěvků k řešení od zdrojů znalostí. Vysoká úroveň detailu vede k zahlcení, nesrozumitelnosti a snížení efektivity. e) Výhoda: Oportunistické uvažování znalosti se používají v nejpříhodnější možnou dobu a tím nejlepším možným způsobem nad globálně přístupnými daty (na tabuli). Omezení: Rizika použití globální databáze použití společné tabule jako globální databáze vyžaduje od zdrojů znalostí určitou zodpovědnost za změny, které na tabuli provádějí. Bez této zodpovědnosti může být ohrožena integrita dat uložených na tabuli a tím i možnost nalezení řešení. 5. Použití tabulové architektury v multiagentových systémech Při porovnání koncepcí multiagentových systémů a tabulových systémů jsou některé rysy společné, v některých existuje průnik a v některých aspektech se tyto dvě koncepce odlišují [2,4,5,6]: Úložiště dat tabulový systém používá tabuli jako globální úložiště dat spojených s řešením problému kdežto tradiční multiagentové systémy používají decentralizovaný přístup pro uchování informace. Autonomie v tabulových systémech jsou zdroje znalostí nezávislé. Stejně tak v multiagentových systémech mají jednotliví agenti autonomní schopnosti. Rozdíl může být v aktivizaci. V tabulových systémech musí být zdroj znalostí aktivován na základě událostí a potom musí dojít k jeho spuštění. Aktivovaný zdroj znalostí je připraven příspěvek k řešení vypracovat, ale skutečně ho vypracuje až na základě spuštění řídící komponentou. V multiagentových systémech jednotliví agenti rozhodují o svých dalších krocích většinou samostatně. Interakce a komunikace probíhá v tabulových systémech zprostředkovaně pomocí tabule. Zdroje znalostí o sobě navzájem nevědí a tak mohou být snadno za běhu systému přidány či vyměněny. Naproti tomu v multiagentových systémech agenti přicházejí do bezprostředního kontaktu. Pokud se jedná o komunikující agenty, potom si vyměňují informace přímo. Koordinace a organizace v tabulových systémech jsou zdroje znalostí organizovány pomocí centrální řídící komponenty, která se stará o správné směrování řešení. Naproti tomu v multiagentových systémech je koordinace založená na rozhodnutích jednotlivých agentů přijímaných na základě lokálních informací z dostupného okolí agentů a mnohdy pomocí velice jednoduchých pravidel (emergentní organizační prostředí). Možné konfigurace použití tabulové architektury v multiagentových systémech [2]: a) Jedna společná tabule pro všechny agenty v této konfiguraci existuje agent, který reprezentuje tabuli. Jednotliví agenti spolu mohou stále komunikovat přímo, ale mají k dispozici i nepřímou komunikaci přes tabuli. Zavedením tabule se eliminuje nutnost držet všechny potřebné informace v rámci lokálního úložiště agentů. 67

68 b) Jedna tabule s kontrolním mechanizmem v předchozí konfiguraci je stále na jednotlivých agentech, aby rozhodovali o svých aktivitách v každém okamžiku. Výhodné je přidat centrální kontrolní mechanizmus (řídící komponentu). Všechny informace, potřebné pro rozhodování o činnosti agentů, jsou totiž k dispozici právě na tabuli v rámci agenta-tabule. Agenti tak mohou delegovat rozhodnutí o jejich lokálním chování na agenta-tabuli. c) Jedna tabule pro každého agenta v této konfiguraci každý agent obsahuje implementaci celého tabulového systému. e) Kombinace předchozích konfigurací předchozí konfigurace lze kombinovat s ohledem na specializaci jednotlivých agentů a na konkrétní požadavky koordinace. 6. Demonstrace použití tabulové architektury v multiagentovém systému V této kapitole je představena konkrétní logistickou úloha a možnost jejího řešení v podobě multiagentového systému s tabulovou architekturou. Základní vymezení problému: Mějme prostředí, ve kterém se nachází určité množství volně loženého, náhodně rozprostřeného materiálu. Dále mějme v prostředí určitý počet skladů, do kterých se bude tento materiál shromažďovat. Lokalizaci materiálu zajišťují takzvaní pátrači. To jsou entity, které se mohou pohybovat po prostředí a dokáží zmíněný materiál objevit. Tito pátrači ale už nedokáží nalezený materiál sami sebrat a manipulovat s ním. Přemisťování materiálu zajišťují takzvaní sběrači. Sběrači dokáží materiál odnést z jeho původní lokace do skladů. Sběrači však nedokáží materiál sami lokalizovat a musejí se o jeho umístění nejprve dozvědět. Úkolem je lokalizovat veškerý materiál umístěný v prostředí a rovnoměrně ho rozmístit do existujících skladů. Zadání problému je dále rozšířeno, aby bylo možné demonstrovat možnosti systému reagovat na omezující podmínky a dynamicky se měnící prostředí. Další rozšíření zadání problému: Mějme na řešení úlohy pouze omezený čas a sledujme, jak dostupný počet zdrojů, tj. počet pátračů a počet sběračů, je schopen dokončit řešení v tomto požadovaném čase. Zabývejme se otázkou dynamického přidávání zdrojů do systému tak, aby řešení bylo dosaženo i za omezujících podmínek v podobě omezeného času. Vytvořme prostředí, ve kterém se průběžně mění množství materiálu, který má být rozdělen do skladů. Dokončení úlohy je potom dosaženo tehdy, pokud zdroje systému stačí zpracovat jak všechen na počátku přítomný materiál, tak i materiál průběžně přidávaný. Model pro řešení problému vychází z architektury multiagentového systému se zakomponováním několika tabulových systémů na úrovni specializovaných metaagentů [6], kteří poskytují funkcionalitu tabule pro ostatní agenty (viz obr. 2). Jednotlivými komponentami modelu jsou: Centrála hlavní tabule systému. V systému je pouze jedna. Shromažďuje informace o veškerém objeveném materiálu. Řídící jednotka centrály spravuje tabuli centrály a řídí aktivitu ostatních komponent v systému. Přiděluje konkrétní kousky materiálu do správy skladům. Také zabezpečuje vývoj řešení 68

69 podle nastavených parametrů. Provádí vyhodnocení stavu řešení a provádí vhodné reakce na tyto situace. Sklad tato komponenta je také tabule, která zastřešuje jeden sklad, do kterého se ukládá materiál. Shromažďuje informace o přiřazeném materiálu a informace o sběračích, kteří pro daný sklad aktuálně pracují. Skladů může být více kolik skladů, tolik tabulí. Sklad dostává od centrály do správy jednotlivé objevené kousky materiálu a dále zabezpečuje zajištění zdrojů pro přinesení tohoto materiálu. Pátrač tato komponenta je reprezentována nezávislým, samostatně jednajícím agentem, který prochází prostředím a hledá materiál. Pokud materiál nalezne, oznámí jeho polohu centrále.. Sběrač tato komponenta je také reprezentována agentem. Sběrači jsou na sobě navzájem nezávislí a jejich spolupráce probíhá pomocí tabulí. Prostředí prostředí není samostatnou komponentou, ale ohraničuje všechny zbývající komponenty systému. Obr. 2: Komponenty modelu 69

70 7. Implementace řešení Řešení úlohy je implementováno v modelovacím nástroji NetLogo. Implementace jednotlivých komponent proběhla takto: Implementace pátračů jde o čistě reaktivního agenta, který náhodně prochází prostředím s cílem lokalizovat v prostředí náhodně umístěné kousky materiálu (dále jen kostky ). Schopnost lokalizace kostek je dána parametry určujícími maximální zorný úhel pátrače a vzdálenost, na kterou pátrač v prostředí dohlédne. Kostky, které pátrač objeví, nahlásí centrále. Implementace sběračů implementace agenta sběrače je o něco komplikovanější. Sběrač v každém kroku může provádět některou z následujících aktivit: náhodné procházení, cesta pro kostku (sběrač dostal od skladu polohu kostky, pro kterou má dojít), cesta s kostkou zpět do skladu. Po odevzdání kostky ve skladu je třeba provést údržbu skladu, sestávající z odstranění záznamu o právě přinesené kostce z tabule skladu, dále se musí ve skladu určit místo, na které přijde další kostka. Implementace Centrály centrála je implementována jako agent s tabulovou architekturou a řeší následující úkoly: Rozdělení objevených kostek pod správu jednotlivým skladům - při tomto rozdělování centrála dodržuje nastavená pravidla ohledně kapacity skladů (pokud je to nastaveno, tak sklad může pojmout jenom omezené množství kostek do své správy). Vyřešení blokace kostek a agentů pokud je tato funkcionalita aktivována, centrála volá pokaždé za specifikovaný čas proceduru pro odblokování (při pohybu agentů v prostředí může totiž dojít k jejich zablokování). Měření a řízení výkonnosti pokud je tato funkcionalita zapnuta jako aktivní, je pravidelně měřena výkonnost systému (počet objevených a do skladů dopravených kostek za určité období). Na základě trendu z těchto měření je odhadován předpokládaný čas dokončení úlohy a podle potřeby jsou do systému přidávány další zdroje (pátrači či sběrači) aby systém byl schopný vyřešit úlohu i při limitovaném čase na dokončení úlohy a při dynamicky se měnícím prostředí (přidávání kostek do prostředí za běhu řešení úlohy). Změny prostředí za běhu modelu přidávání materiálu podle požadavků uživatele (uživatel specifikuje pravděpodobnost přidání a počet přidávaných kostek). Implementace Skladů sklady jsou implementovány jako agenti s tabulovou architekturou. Sklady jsou úkolovány centrálou, která jim předává k zaznamenání na jejich vlastní tabuli informace o umístění kostek, jejichž vyzvednutí má sklad zorganizovat. Předmětem pozornosti skladů se tak stávají volní sběrači, které lze poslat pro některou z kostek, které má sklad ve správě. 70

71 Obr. 3: Svět modelu a jeho komponenty 8. Možnosti zkoumání modelu pomocí nástroje BehaviourSpace Nástroj modelovacího systému NetLogo Behavior Space umožňuje zkoumat chování implementovaného modelu při mnoha různých zadáních úlohy. Zadání jsou nastavována automaticky na základě specifikace uživatele. Úlohy jsou automaticky spouštěny a mohou probíhat paralelně pro urychlení výpočtu. Výstupem jsou soubory dat vypovídajících o průběhu a výsledku řešení. Tímto nástroje lze pohodlně získávat mnoho informací o chování systému za různých podmínek. Tyto informace lze následně zkoumat a vyhodnocovat. Byl sledován například vliv hodnoty parametru úhlu náhodného otočení pátrače při jeho náhodném pohybu prostředím na schopnost systému vyřešit úlohu. Otázkou bylo, jaký vliv má hodnota tohoto parametru na čas potřebný k dokončení úlohy. Pomocí nástroje BehaviorSpace se hodnoty úhlu natočení měnily od hodnoty 2 stupně do hodnoty 45 stupňů v kroku po 2 stupních. Pro každé nastavení proběhla úloha 50 krát. Celkově tak bylo provedeno 1050 běhů úlohy. Výsledná data a jejich grafická reprezentace na obr. 4 ukazují, že úhel náhodného otočení pátrače pozorovatelný vliv na výkonnost systému nemá (horní křivka ukazuje maxima, spodní minima). Obr. 4: vliv parametru uhlu náhodného natočení na čas řešení úlohy 71

72 9. Závěr Tabulovou architekturu lze použít v multiagentových systémech tam, kde mají specializovaní agenti vykonávat koordinovaně nějakou činnost vedoucí ke společnému cíli, ke kterému by jako jednotliví agenti nedokázali dospět. Důležitým aspektem zavedení tabulové architektury do multiagentových systémů je fakt, že někteří agenti ztrácejí svoji autonomii. Tradiční multiagentové systémy totiž podporují nezávislé, distribuované agenty. Zavedením tabulové architektury jako metody spolupráce ale multiagentový systém na oplátku získává možnost centrální efektivní koordinace jednotlivých agentů. Je třeba si uvědomit, že takový multiagentový systém, obsahující funkcionalitu na bázi tabulové architektury pro spolupráci agentů, se nicméně vzdaluje původní myšlence autonomie jednotlivých agentů, která je jednou z hlavních charakteristik tradičních multiagentových systémů. Naopak použití tradičních multiagentových systémů nemusí být právě kvůli autonomii agentů úplně nejvhodnější pro návrh spolupracujících softwarů. Představené praktické řešení logistické úlohy demonstruje použití tabulové architektury a její možnosti při flexibilním řízení zdrojů systému. Implementovaný model může soužit jednak jako příklad použití tabulového přístupu v multiagentovém systému a také jako materiál pro studium a inspiraci dalších zájemců o práci s modelovacím systémem NetLogo. Řešení poskytuje mnoho možností nastavení a parametrizace zadání úlohy a je tak mimo jiné vhodným materiálem pro zkoumání nástrojem BehaviorSpace. Zdrojový kód v NetLogu je možné vyžádat na ové adrese autora. Literatura [1] CORKILL, D.D. Blackboard systems, AI Expert, 6(9):40 47, 1991, [2] CORKILL, D.D. Collaborating Software: Blackboard and Multi-Agent Systems & the Future, článek ve sborníku Proceedings of the International Lisp Conference, New York, [3] HUNT, J. Blackboard Architectures, JayDee Technology Ltd [4] Kolektiv autorů: Multiagent Systems: A Modern Approach to Distributed Artificial Intelligence. Edited by Gerhard Weiss, The MIT Press, Cambridge, Massachusetts, London, [5] MAŘÍK, V., ŠTĚPÁNKOVÁ, O., LAŽANSKÝ, J. a kol. Umělá inteligence II. Kapitola 4, Academia Praha, 1997, ISBN [6] MAŘÍK, V., ŠTĚPÁNKOVÁ, O., LAŽANSKÝ, J., a kol. Umělá inteligence III. Kapitola 5 Multiagentní systémy: Principy komunikace a základní formální architektury. Academia Praha, 2001, ISBN [7] VLASSIS, N. A. Concise Introduction to Multiagent Systems and Distributed Artificial Intelligence, Morgan & Claypool, Ing. Jan Procházka Univerzita Hradec Králové, Fakulta informatiky a managementu Rokitanského 62, Hradec Králové, Česká republika jan.prochazka.2@uhk.cz 72

73 OPEN EDU MOBILNÍ APLIKACE OPEN EDU MOBILE APPLICATION Karel Radocha, Lukáš Rejha Abstrakt Mobilní aplikace Open EDU umožňuje přístup k webovému projektu Open EDU. Jedná se o zjednodušenou verzi projektu poskytující základní služby pro již existující uživatele z mobilních zařízení s platformou Android. Sociální síť Open EDU je založena na vzoru tematických map a slouží převážně ke sdílení nápadů a projektů v akademické oblasti. Projekt je vyvíjen jako open source a je tedy přístupný každému. Mobilní aplikace je vystavěna na volání webových služeb pracujících na technologii JSON. Klíčová slova mobilní aplikace, android, open edu, tématická mapa, ontologie Abstract Mobile application Open EDU allows access to web project Open EDU. It acts as simplified version of the project providing basic services for existing users from mobile devices with running Android platform. Social network Open EDU is based on topic maps and mainly serves as a tool for sharing ideas and projects in academic field. Project is developed as an open source and is available to anyone. Mobile application is based on web service calls working with JSON technology. Keywords mobile application, android, open edu, topic map, ontology 1. Úvod Projekt Open EDU si klade za cíl navrhnout a zpřístupnit jednoduché prostředí sociální sítě zefektivňující spolupráci a mapování znalostí v univerzitním prostředí. Projekt bude přístupný různým zájmovým skupinám, zaměstnancům univerzity, doktorandům a v neposlední řadě umožní zapojení studentů magisterského a bakalářského studia. 73

74 Jedná se o projekt v rámci grantového projektu INKOV. Projekt je vyvíjen jako open source, umožňující budoucí rozšíření a napojení na široké spektrum existujících systémů. Projekt v budoucnu poběží na virtuální infrastruktuře FIM. Projekt bude umožňovat rozvoj jak v osobní oblasti například: tvůrčích záměrů, poslání, získání know-how, společenských událostí. Ale samozřejmě také v oblasti akademického prostředí například: výzkumných záměrů, diplomových prací, seminárních prací, nabídek spolupráce, nebo publikací na konferencích. 2. Standard TopicMaps Topicmaps (v češtině mapy témat) je standardem pro vytváření map znalostí (ISO ) a jejich formální zachycení (ontologie). Projekt OpenEDU využívá vlastnosti z Topicmaps k nabídnutí možnosti zachycení vzájemné provázanosti všech prvků a jejich následné vizualizace. Existuje zde možnost data přenést do jiných systémů, které Topicmaps standard podporují. Základním prvkem je téma - Topic. To může být ve vztahu s jiným tématem, nebo více tématy. Každé téma má definovaný svůj typ TopicType (např. Osoba, Publikace apod.), a stejně tak každá vazba je definovaná svým typem AssociationType (např. Spoluautor, apod.). Každé téma v mapě může mít odkaz na svůj výskyt Occurence (např. výtisk publikace). Dále má téma své jméno BaseName a různá alternativní jména VariantName (nebo také přidaná klíčová slova). 3. Mobilní aplikace Mobilní aplikace Open EDU vytvářená v rámci projektu na předmět MTE nabídne existujícím uživatelům webové aplikace přístup k datům ve zjednodušené verzi původní aplikace. Komunikuje s webovou verzí aplikace, která je založená na architektuře Model ViewController Použité technologie Aplikace je vytvářena v prostředí Eclipse v jazyce Java za použití technologií: Android SDK aplikace je vyvíjena pro verzi Java 1.6 JSON o komunikace mobilního zařízení se serverem probíhá pomocí zasílání POST request na speciálně přiřazenou URL, kterýdále zpracovává danýcontroller a vrací data ve formátu JSON Server ApacheTomcat o verze serveru 6 Databáze MySQL (spravovaná nástrojem HeidiSQL) o k práci s databází je použit frameworkhibernate

75 3.2. Architektura řešení Komunikace klient/server Mobilní aplikace získává potřebná data zasíláním HttpPostrequestů na vystavené URL (například: pro získání Tvůrčích záměrů ). request na straně webové aplikace přebírá controller (implementace z frameworkuspring 3.1.0). Zde je dotaz odeslán na servisní vrstvu, která pomocí DAO (hibernate 3.6.3) objektů vrací z MySQL databáze požadovaná data. Mobilní zařízení pak obdrží Http response, která obsahuje data ve formátu JSON, která jsou následně pomocí JSONObject a JSONArray upravena na specifické Java objekty, se kterými pak pracuje mobilní aplikace. Obr. 1: Struktura aplikace Ukázka kódu získání JSON : List<Objective>result = newarraylist<objective>(); HttpPostreq = newhttppost(url); HttpResponseresp = client.execute(req); if (resp.getstatusline().getstatuscode()!= 200) { // log returnnull; } StringBuildersb = newstringbuilder(); BufferedReader br = newbufferedreader(new InputStreamReader(resp.getEntity().getContent(), "UTF-8")); String line = ""; 75

76 while ((line = br.readline())!= null) { sb.append(line); } Stringjson = sb.tostring(); JSONObjectcontainer = newjsonobject(json); JSONArrayobjectives = container.getjsonarray("items"); for (int i = 0; i <objectives.length(); i++) { JSONObject o = objectives.getjsonobject(i); Objectiveobjective = newobjective(); // konverze z JSON na Javaclass (např. Objective) } result.add(objective); Ukázka publicviewgetview(intposition, ViewconvertView, ViewGroupparent) { Objective o = getitem(position); if (convertview == null) convertview = View.inflate(getContext(), R.layout.objective_item, null); TextViewtvObjective = (TextView) convertview.findviewbyid(r.id.objective_item_objective); // Přiřazení proměnné ke komponentě TextViewtvSomeText = (TextView)convertView.findViewById(R.id.objective_item_some_text); // Přiřazení proměnné ke komponentě if (o!= null) { // Naplnění proměnných tvobjective.settext(o.getauthor().getlastname() + " " + o.getauthor().getfirstname() ); tvsometext.settext(o.getname()); } returnconvertview; } 3.3. Stavba aplikace Po přihlášení do aplikace je uživateli zobrazena úvodní strana obsahující poslední novinky/změny které se udály v tématech s ním spojených. Aplikace však nabízí více pohledů zobrazující různá témata jako například zobrazení Tvůrčích záměrů, Dokumentů apod. K přecházení mezi těmito stránkami slouží třída zvaná Swiper. Tato třída využívá nativní animace z Android SDK ve spojení s listenerem, který 76

77 zachytává dotek na ploše obrazovky a dle vstupního a výstupního bodu rozhoduje o posunu na další/předchozí stránku. Listování mezi tématy tak napodobuje chování hlavního panelu mobilních zařízení běžících na prostředí Android. K zobrazení seznamů jednotlivých témat je použit Android ListView. V seznamu je vždy zobrazena jen základní informace a po kliknutí na jednotlivý prvek se otvírá v dialogovém okně, kde jsou zobrazeny detailnější informace. V tomto okně lze také (pokud je to možné) dělat některé další operace, jako například komentovat, hlasovat líbí/nelíbí apod. V hlavním okně je také možnost přepínat mezi pohledy na všechny záznamy a vlastní záznamy (neboli záznamy se kterými je uživatel nějakým způsobem spjat např. Spoluautor apod.) Uživatel bude moci dále taky tvořit svoje vlastní tvůrčí záměry, které bude možno přidávat přes nové okno v mobilní aplikaci. Tyto tvůrčí záměry budou pak nahrány zpět na server a uloženy do DBS Metody přístupné na serveru Přidání nového TOPIC Typ metody POST URL: BJECTIVE&description=popis&author=46&public=1 KGROUP&description=popis&author=46&p Parametry: name - jméno nového topicu topictype - typ nového topicu, možnosti: OBJECTIVE, WORKGROUP, DOCUMENT description - popis k topicu author - id existujícího uživatele public - veřejnost/neveřejnost topicu, 1=veřejný, 0=neveřejný Odpověď bude ID nově přidaného Topic např: 189 Vrať tvůrčí záměr (JSON) Typ metody GET URL: Paramentry: id - id existující tvůrčího záměru Jako odpověď se vrátí všechny detaily tvůrčího záměru. Vrať dokument (JSON) Typ metody GET URL: Paramentry: 77

78 id - id existující documentu Odpověď budou všechny informace o daném dokumentu Vrať všechny dokumenty (List JSON) Typ metody POST URL: Paramentry: page, size (ani jeden parametr není povinný, defaultní hodnota null nebo 0) Vrať všechny tvůrčí záměry (List JSON) Typ metody POST URL: Paramentry: page, size (ani jeden parametr není povinný, ) Detailní informace TOPICu URL: Paramentry: idtopic (povinný), idlevel (nepovinný) Popis: V reponse je vždy první nod ten, na který se ptáme. Přidat komentář k TOPICu Typ metody POST URL: entare} Paramentry: id, note (id topicu a text komentáře, oba parametry jsou povinné) Odpověď Id vytvořené poznámky např: 6 Vrať všechny poznámky k Topicu Typ metody GET URL: Paramentry: id, note (id topicu) Nejnovější poznámky od Topicu Typ metody GET Popis: Výpis max 10ti nejnovějších komentářů od konkrétního id komentáře URL: Paramentry: id (id komentáře, povinný) Nejstarší poznámky od Topicu Typ metody GET Popis: vrácí 10 topiců, které jsou starší než id zadaného komentáře URL: Paramentry: id (id komentáře, povinný) Možnost hlasování LÍBÍ / NELÍBÍ Typ metody POST URL: Parametry: id (id topicu, povinný), vote (možnost hlasování, povinný, - 2=POSITIVE - 1=DEFAULT 78

79 - 0=NEGATIVE Response example: (výsledek všech hlasů k topicu) 3.5. Případy použití (Use Case Model) 4. Závěr Obr. 2: Use Case model Práci velice ulehčilo, že její webová aplikace měla dostupné rozhraní pro dané metody. Tyto metody už stačilo jenom vystavit tak, aby byly dostupné mobilní aplikaci, která už pouze přijatá data zobrazila. Zřejmě největší problém při tvorbě mobilní aplikace byla komponenta swiper, u které nebylo možno snadno kontrolovat vizuální vzhled stránky. Jedinou možností bylo každou stránku upravovat zvlášť a poté až spojovat v jednu stránkovací komponentu. Pro implementaci jsme využili vývojové prostředí Eclipse. Bc. Karel Radocha Univerzita Hradec Králové, Fakulta informatiky a managementu Rokitanského 62, Hradec Králové, Česká republika karel.radocha.2@uhk.cz 79

80 Bc. Lukáš Rejha Univerzita Hradec Králové, Fakulta informatiky a managementu Rokitanského 62, Hradec Králové, Česká republika lukas.rejha@uhk.cz 80

81 AKO DÁVAŤ INTELIGENCIU REÁLNYM A VIRTUÁLNYM ROBOTOM HOW TO GIVE INTELLIGENCE TO REAL AND VIRTUAL ROBOTS Peter Sinčák, Martin Paľa, Mária Virčíková Abstrakt Tento príspevok si kladie ambíciu nadväzovať na príspevok v knihe prof. Kvasničku, nestora umelej inteligencie na Slovensku, z roku Vtedy som sa snažil naznačiť, že inteligentné technológie sú dôležitou súčasťou našej doby a je, a hlavne bude potrebné, aby vznikali odborníci z oblasti informačných technológií, ktorí by mali okrem klasickej znalosti z oblasti IT priniesť aj znalosti z oblasti aplikovanej umelej inteligencie. Je to veľmi dôležité pre samotný odbor Umelá inteligencia, ktorý je pod vplyvom novovznikajúcich integrálnych technológií. Technológie začínajú aj spätne generovať požiadavky pre základný výskum a následne základný výskum ovplyvňuje technológie. Inteligentné technológie smerujú k učiacim sa systémom a človek sa postupne dostáva do polohy pozorovateľa úloh a rutinnú iniciatívu preberajú stroje. Teraz má človek dve možnosti - buď pozorovať, alebo kreatívne vymýšľať veci v kontexte existujúcich a budúcich technológií pre prospech ľudstva. Kľúčové slová Autonomita, Inteligentné systémy, Machine Intelligent Quotient, Robotické platformy, Global Task Intelligence, Human Task Intelligence, Machine Task Intelligence, Tele operácia Abstract This paper has ambition to continue the research started and published in book of prof. V. Kvasnička one of the founders of Artificial Intelligence in Slovakia, from In that paper I wanted to underline that intelligent technologies are part of our current technologies and mainly how important is that experts for intelligent technologies as part of IT domain should be produced from educational system. Experts in Intelligent systems should be IT people with additional knowledge of Artificial Intelligence. It is very important for AI domain itself, which is under full press of novel technologies which mainly integrate existing technologies into new quality. Those technologies give number of feedbacks for basic research and back forth basic research influence technologies. Intelligent technologies directing towards learning systems and humans 81

82 are gradually becoming an observers of the process and routine work and initiative is done by machines. Nowadays the human has 2 options either only observe or creatively invent new challenged in context of existing and future technologies for benefit of mankind. Keywords Autonomy, Intelligent systems, Machine Intelligent Quotient, Robotic Platforms, Global Task Intelligence, Human Task Intelligence, Machine Task Intelligence, Tele operation. 1. Inteligentné technológie V práci [1] som sa snažil naznačiť, že súrne potrebujeme na Slovensku Inteligentné technológie - nakoľko IT svet sa rúti závratnou rýchlosťou a smeruje ku spoločnosti, kde Inteligentné technológie budú dominujúcim faktorom ekonomického rozvoja, a tým aj prosperity a životnej úrovne ľudí. Inteligentné systémy sú predmetom výskum už dlhé obdobie a umelá inteligencia zohráva vo vývoji Inteligentných systémov kľúčovú úlohu. História odboru umelá inteligencia sa datuje k roku 1956, keď sa na seminári v Dartmouthe (USA) vedci dohodli na názve a základnej terminológii tohto odboru. Obdobie v rokoch bolo poznačené rýchlym rozvojom výpočtovej techniky, ktorá má kľúčový význam pre rozvoj umelej inteligencia, a tým aj inteligentných systémov. Prelomový bol rok 1965 keď prof. Zadeh prišiel s koncepciou fuzzy množín na podporu mnohých predošlých aktivít, ďalej prof. Werbos obhájil svoji PhD prácu v roku 1973 na Harvarde, kde položil základy neurónových sietí a v neposlednej rade prof. Holland a profesori Koza a Goldberg (1975) prišli s evolučnými výpočtami ako prostriedkom pre výkonnú výpočtovú techniku. Začiatkom 90 rokov koalícia týchto troch prostriedkov neuro, fuzzy a evolučných (vrátane interaktívnych) systémov vytvorila oblasť, ktorá sa volá Výpočtová Inteligencia (známa aj ako subsymbolická umelá inteligencia) a je postavená na základoch tzv. spájania zdola hore a biologickej inšpirácii. Pre prípady, kde nevieme pre evolučný proces definovať funkciu vhodnosti, sa začínajú využívať evolučné interaktívne systémy zosumarizované prof. Takagim v roku Na rozdiel od výpočtovej, symbolická umelá inteligencia je založená na formálnej logike a spájania zhora dole. Základnou víziou umelej inteligencie je proces automatizácie rôznych procesov, ktoré robí človek. Takým procesom je aj programovanie a jeho automatizácia. Firma Microsoft v poslednom období výrazne pokročila v tejto oblasti a napomáha aplikácii automatizácie programovania. Produkty Visual Studio 10, Silverlight 4 majú prvky umelej inteligencie a smerujú k výraznej zmene programovacích techník. V neposlednej rade umelá inteligencia preniká aj do zábavného priemyslu, kde Microsoft prichádza s projektom XBOX Kinect 2009 a jeho komerčné spustenie je vyhlásené na rok Jeho postupné zdokonaľovanie prinesie 82

83 revolučné zmeny v interakcii človek stroj. Veľmi veľa očakávam od nových interface počítačov ako IPAD a Surface Computing. Súčasne sa začínajú objavovať tzv. Smart e- boardy napr. Samsung 650TS-2 E-Board HandsON. Takiež 3D monitory alebo TV, hlavne plazmové, sa stávajú cenovo dostupné. Zaujímavosťou Interaktívnych systémov je aj to, že budú prepájať reálne a virtuálne svety a hlavne ich štandardizácia. Príkladom takýchto štandardizovaných platforiem je napr. RTmiddleware pre rôzne robotické platformy vytvorené pod podporou systému CORBA pre možnosť využívania rôznych programovacích jazykov. RTmidleware vznikol v Japonsku v Tsukube, kde sa snažili štandardizovať a zefektívniť vývoj technologického výskumu v oblasti mobilnej robotiky. Definícia inteligentných systémov je nejednotná a vo vedeckom svete veľmi rôznorodá. Prof. Kasabov definoval 3 základné a podstatné vlastnosti inteligentných systémov, a to: učenie, archivácia ukladania znalostí, využívanie znalostí pri riešení problému. Opäť je tu treba potvrdiť, že názory na inteligentný systém má iný napr. expert na inteligentné domy ako expert na umelú inteligenciu. Určitej revízii dochádza v technologickom pohľade na definíciu umelej inteligencie, kde vo všeobecnosti a pri vysokej miere abstrakcie môžeme pod prostrediami umelej inteligencie považovať technológie, ktoré berú prácu ľudom a zamestnávajú stroje. Tento proces odovzdávania práce môže byť rôznorodý - a to buď kontinuálnym a inkrementálnym učením, ktoré sa produkuje znalostnou bázou, alebo jednorázovým transferom ľudských poznatkov stroju od experta. Táto forma môže byť rôznorodá - napr. vo forme fuzzy pravidiel alebo iných foriem znalostí. V princípe dnes už každý proces resp. úloha (tasks, missions) je realizovaný človekom a počítačom. Ak budeme uvažovať o abstraktnej pojme Inteligencia resp. Globálna Inteligencia pre úlohu GTI (Global Task Intelligence), tak je súčtom Inteligencie človeka HTI (Human Task Intelligence) a Inteligencie stroja MTI (Machine Task Intelligence). Teda: GTI = HTI + MTI (1) Ak budeme definovať GTI ako konštantu 1, tak HTI a MTI budú mať definičný obor definovaný ako uzavretý interval <0,1>. Ak je hodnota HTI resp. MTI blízka 0, buď človek nerobí nič - iba pozoruje resp. stroj je vypnutý, alebo, ak je blízka 1, tak buď človek plne realizuje úlohu alebo stroj plne a autonómne realizuje úlohu. Z týchto teoretických úvah môžeme definovať pre abstraktný stroj aj tzv. Machine Task Intelligence Autonomity (MTIA), ktorého definičný odbor je od <0, ). V prípade, ak je MTIA rovný 0, tak stroj je vypnutý a nie je v prevádzke. V prípade, ak MTI hodnota je napr a tým pádom HTI je veľmi malé, teda 0.01, tak teda stroj je vysoko autonómny a človek potrebuje málo Inteligencie na splnenie úlohy, tak hodnota MTIA je 99. MTIA = MTI / HTI (2) 83

84 Všetky tieto úvahy sú spojené tiež s pojmami MIQ (Machine Inteligent Quotient), ktorý bol definovaný ako koncept a je plne závislý od aplikácie. Učenie je imanentný a dôležitý prvok inteligentného systému. V princípe Inteligentný systém a jeho vývoj sa môže uberať tzv. Darwinovským alebo Lamarckovským prístupom. Kým vývoj biologických systémov sa uberá Darwinovským prístupom, naopak technologické systémy sa vyvíjajú Lamarckovským vývojom, kde ďalšia generácia replikuje znalosti priamo od predošlej generácie, čo nie je možné u Darwinovského prístupu. Veľmi dôležitým fenoménom je Internet a tzv. zasieťované systémy vedúce k určitej emergentnej forme distribuovaných multiagentových systémov. V dnešnej dobe nepotrebujeme vyvinúť stroj, ktorý bude vedieť všetko ale stroj, ktorý možno disponuje s určitým kvantom informácií, ale bude vedieť všetko nájsť aj na Internete. V princípe ide o simuláciu činnosti človeka. Dnes už je dôležité okrem určitého kvanta vedomostí hlavne vedieť, kde informáciu nájsť a hľadať súvislosti a vzájomnosti medzi znalosťami. Mení sa aj systém učenia. Obzvlášť sa mení názor na fakt, či chceme vyvinúť systém, ktorý má myslieť, alebo systém ktorý vie nájsť odpoveď na otázku (nájsť existujúcu informáciu). Nájdenie odpovede veľmi rýchlo a efektívne je veľká výzva hlavne vplyvom nových technológií ako gridové a klaudové počítanie. 2. Od teleoperácie k autonomite Teleoperáciu možno zjednodušene definovať ako ovládanie určitého systému. V princípe nemusíme apriori predpokladať, že ovládanie prebieha na diaľku, ale vzdialenosť medzi človekom, ktorý riadi a systémom, ktorý je riadený, začína byť nepodstatná. Pojem Teleoperácia systému nie je zďaleka jednoduchý technologický proces, ale stále nie sú jeho problémy vyriešené. V prvom rade je dôležité ujasniť si rozdiel medzi pojmami operátor a teleoperátor v oblasti teleoperácie. Operátor je väčšinou človek ovládajúci, respektíve riadiaci teleoperátor, pričom teleoperátor je definovaný ako diaľkovo ovládaný robot. V súčasnosti príkladom teleoperácie sú operačné systémy Da Vinci v zdravotníctve. Obr. 1: Robotický systém DaVinci reálne funguje v praxi 84

85 Vzdialenosť medzi operátorom a teleoperátorom sa môže líšiť od desiatok centimetrov (mikro manipulácia) až po niekoľko milión kilometrov (vesmírne aplikácie). Prioritným cieľom výskumu v oblasti teleoperácie bolo v minulosti vzdialené riadenie komplexných mechanických systémov za účelom manipulácie pre človeka nebezpečných materiálov. Splnenie tejto dnes možno triviálnej úlohy si vyžadovalo vyvinúť mechanické systémy dostatočne obratné pre plnohodnotné riešenie úloh manipulácie nebezpečných objektov. Na druhej strane ohrozenie človeka nebezpečnými materiálmi a vysokou pravdepodobnosťou intoxikácie prostredia viedlo k zvýšeniu vzdialeností medzi samotnými operátormi a strojmi nimi ovládanými. Tieto okolnosti si vyžadovali vývoj ďalších systémov podporujúcich prenos informácii a inštrukcií. Prvý takýto master-slave systém bol navrhnutý R. Goertzom v neskorých 40. rokoch 20. storočia pre prvý nukleárny reaktor. Bol to mechanický manipulátor ovládaný pomocou drôtov a remeňov, s priamym výhľadom operátora na manipulátor. Hlavnou nevýhodou takéhoto systému bolo to, že operátor musel prekonávať parazitné zotrvačnosti vznikajúce pri procese prenosu sily od operátora k manipulátoru, čo viedlo k dodatočnej produkcii námahy operátora. Riešením tohto nedostatku bol elektricko-mechanický manipulátor so servo riadením so spätnou väzbou, vyvinutý R. Goertzom a jeho tímom v roku Následne už nič nebránilo, aby sa teleoperačné systémy rozšírili aj do ostatných odvetví priemyslu alebo zábavy, všade tam, kde bolo možné naplno využiť vlastnosti teleoperatívnych systémov. Telepresence predstavuje veľmi dôležitý moment a na trhu sa začínajú objavovať dôležité produkty pre budúcnosť napr. od firmy DoubleRobotics ( 3. Aktuálny vývoj teleoperačných systémov Možnosti vzdialeného ovládania sa za posledných 40 rokov vyvíjali rôznymi smermi. Metódy teleoperácie je možné rozdeliť do štyroch základných skupín, podľa toho akou formou je robot alebo vzdialený mechanizmus riadený. Prvou možnosťou je mechanická manipulácia, kde sú riadiace príkazy šírené mechanicky alebo hydraulicky do teleoperátora. V prípade mechanickej teleoperácie je možná priama alebo nepriama vizuálna spätná väzba pomocou zobrazovacieho systému. Takáto forma vzdialenej manipulácie je typická pre manipuláciu nebezpečných materiálov, ale aj mikro manipulácie napríklad v chirurgii. Ďalšou formou je klasické diaľkové ovládanie, kde operátor má priamy vizuálny kontakt s teleoperátorom počas väčšiny času vykonávania činnosti. Riadiace signály sú vysielané elektricky káblom alebo ako rádiový signál. Treťou formou ovládania robota na diaľku je takzvaná normálna alebo štandardná teleoperácia. Pri štandardnej teleoperácii je riadenie zabezpečované človekom, bezdrôtovo s vizuálnou spätnou väzbou pomocou systému kamera-monitor. Štvrtú skupinu riadenia vzdialených systémov je možné nazvať spoločným názvom rozšírená teleoperácia (augmented teleoperation). Rozšírenie spočíva v pridaní ďalších prvkov, snímačov a iných komponentov podieľajúcich sa priamo alebo nepriamo na riadení teleoperátora. Ďalej je možné metódy teleoperácie rozdeliť podľa vzdialenosti 85

86 teleoperátora, respektíve podľa oneskorenia signálov ako vysielaných tak aj prijímaných a nezávislosti teleoperátora od operátora. Priama teleoperácia (Direct Teleoperation), riadenie v uzavretej slučke: Operátor riadi aktuátory teleoperátora priamymi signálmi a pracuje so spätnou väzbou v reálnom čase. Použitie tejto metódy je možné len v prípade, že oneskorenia v riadiacej slučke sú minimálne (do 100ms). Koordinovaná teleoperácia: Operátor znova riadi aktuátory teleoperátora, ale v procese riadenia sa nachádza určitá vnútorná riadiaca slučka. V tomto prípade ešte nie je možné hovoriť o akejkoľvek autonomite na strane teleoperátora, pretože vzdialené riadiace slučky slúžia iba na uzavretie tých riadiacich slučiek, ktoré sám operátor nie je schopný efektívne riadiť, kvôli oneskoreniam signálov. A nakoniec posledný stupeň nezávislosti riadenia teleoperátora od operátora pred samotnou autonomitou je dozorne, respektíve supervízne riadenie. Pri tomto type riadenia je podstatná časť riadiaceho cyklu vykonávaná na strane teleoperátora. Teleoperátor je teda schopný viac menej riešiť časti daných úloh autonómne, zatiaľ čo operátor je v úlohe pozorovateľa a prakticky zabezpečuje zadávanie len vysoko úrovňových príkazov. V tomto prípade sa často v literatúre uvádza termín teleoperácia založená na úlohe (task based teleoperation), avšak tá je výrazne viac limitovaná ako samotné supervízne riadenie. Nasledujúci obrázok presne vystihuje aktuálny vývoj a problémy v oblasti prechodu od teleoperatívnych systémov k semi-autonómnym a autonómnym systémom. Obr. 2: Základné problémy teleoperácie a parametre hodnotenia autonomity 86

87 úroveň schopnosť 10 Fully Autonomous Swarms 9 Group Strategic Goals 8 Distributed Controls 7 Group Tactical Goal 6 Group Tactical Replan 5 Group Coordination 4 Onboard Route Replan 3 Adapt to Failures & Flight Conditions 2 Real Time Health/Diagnosis 1 Remotely Guided Obr. 3: Označenie Machine Intelligence Quotient od 1-10 podľa úrovne autonomity Obr. 4: Základné etapy prechodu od teleoperačného systému k Mission-based Autonomite Obrázok č.4 bol prezentovaný z konferencie Robotics Summit Virtual Conference & Expo, ktorá sa konala v Júni 2011, prezentoval Tim Trainer, vice prezident vládnej a priemyselnej divízie spoločnosti irobot. Spoločnosť irobot sa okrem výroby domácich robotou špecializuje aj na vývoj polovojenských a vojenských robotov zameraných na výzvedné misie alebo likvidáciu mín a bômb. Aktuálne sú roboty spoločnosti irobot používané americkou armádou a nasadené do rôznych misií v Afganistane a Iraku. Problémom zostáva fakt, že tieto roboty nie sú schopné vykonávať rôzne zložité úlohy 87

88 autonómne a na ovládanie jedného robota je potrebný jeden alebo viac operátorov. Preto, podľa spoločnosti irobot, budúcnosť robotických systémov závisí na ich autonomite. Prechod z dnešného podielu 100% operátora na riadení k misijnej autonomite s 1% podielom operátora na riadení môže nastať už o 10 rokov, pri zachovaní aktuálnej výšky investícií. V takomto prípade by bol jeden operátor schopný riadiť 50 a viac robotov v reálnom čase. Autonómne robotické systémy budúcnosti budú schopné individuálne alebo tímovo riešiť zadané úlohy bez výraznej intervencie človeka do riadiaceho procesu. 4. Robotická platforma NAO Robot NAO je plne programovateľný humanoidný robot vyvinutý spoločnosťou Aldebaran Robotics so sídlom v Paríži. Dnes NAO predstavuje základnú výskumnú a edukačnú robotickú platformu na mnohých univerzitách a výskumných centrách po celom svete. S váhou nepresahujúcou 5kg, výškou 57cm a s 25 stupňami voľnosti je NAO schopný vykonávať širokú škálu rôznych pohybov od chôdze, obchádzania prekážok, tanca až po uchopenie predmetov a podobne. Precízne vykonávanie týchto akcií je umožnené vďaka bohatému senzorickému, motorickému a počítačovému vybaveniu robota NAO. Aj kvôli týmto vlastnostiam, bolo doposiaľ predaných viac ako 2000 robotov NAO viac ako 300 univerzitám a laboratóriám v 30 krajinách sveta. Medzi tieto laboratória patrí aj Laboratórium inteligentných technológií (CIT) na Technickej Univerzite v Košiciach. Práve interaktivita a plná programovateľnosť robota NAO je jeho kľúčovou vlastnosťou a dôvodom úspechu robotickej platformy v mnohých projektoch a aplikáciách vo vzdelávaní alebo výskume. NAO sa stal predstaviteľom vedúcej robotickej platformy používanej pri riešení rôznorodých problémov akými sú udržiavanie rovnováhy, uchopenie predmetov, robotické videnie, porozumenie ľudskej reči a interakcia medzi človekom a robotom. Neustále sa však objavujú nové oblasti využitia robotickej platformy NAO za hranicami klasickej robotiky, zahrňujúc podporu pri výuke na univerzitách alebo stredných školách, či starostlivosť a zvýšenie kvality života detí postihnutými rôznymi chorobami vyžadujúcimi dlhodobú hospitalizáciu Hardvérové vybavenie robota NAO Medzi základné stavebné komponenty robota NAO patrí telo robota s 25 stupňami voľnosti, pričom kľúčovými elementmi sú elektrické motory, ktorých sa v tele robota nachádza celkom 26. Každý z motorov je doplnený o snímače pozície a aktuálnej teploty motora. Dva motory slúžia na ovládanie pozície hlavy, 6 motorov zabezpečuje pohyb jednej ruky a takisto 6 motorov slúži na zabezpečenie pohybu jednej nohy robota. Ďalej je robot vybavený sieťou snímačov zahrňujúc 2 HD kamery s programovateľným mikročipom FPGA, ktorý umožňuje simultánny príjem obrazu z oboch kamier v reálnom čase, 4 mikrofóny umiestnené na hlave robota, 2 IR vysielače a prijímače, gyroskop zabezpečujúci meranie orientácie v dvoch osiach, akcelerometer merajúci zrýchlenie v troch osiach, 9 taktilných snímačov umiestnených na predlaktiach rúk a vrchnej časti hlavy, dva ultrazvukové snímače 88

89 umiestnené v torze robota a 8 tlakových snímačov rozmiestnených na spodných častiach chodidiel robota. Komunikácia robota s prostredím je zabezpečená viacerými komunikačnými zariadeniami ako sú hlasový syntetizátor, LED svetlá rozmiestnené vo viacerých častiach robota a dva vysoko kvalitné reproduktory umiestnené po oboch stranách hlavy robota. Najnovší operačný systém robota plne podporuje originálny middleware vyvinutý spoločnosťou Aldebaran Robotics (NaoQi), je postavený na Gentoo linux distribúcii a beží na konfigurácii s procesorom Intel Atom Z530 1,6GHz a 1GB RAM, ktorá je umiestnená v hlave robota. Robot NAO je vybavený aj sekundárnym procesorom, umiestneným v torze robota a zabezpečuje riadenie jednotlivých motorov. Pripojiteľnosť robota k počítačovým sieťam je možná využitím zabudovaného Ethernet alebo Wi-Fi adaptéra. Energetické zabezpečenie robota je dosiahnuté 24,9V/27,6Wh batériou typu Li-Ion, ktorá je schopná robota zásobovať energiou až 90 minút v autonómnom režime robota, závisiac od používania robota. Kľúčové prvky robota sú zobrazené na nasledujúcom obrázku. Kompletné špecifikácie hárdverových prvkov sú dostupné na internetovej stránke Aldebaran Robotics Programovanie robota NAO Obr. 5: Základná hardwarová štruktura robota NAO Robotická platforma NAO ponúka programovanie robota vo viacerých programovacích jazykoch. Vyplýva to zo softvérovej architektúry robota. Keďže operačným systémom robota NAO je Linux (x86) spoločnosť Aldebaran Robotics sa rozhodla pre natívnu podporu jazykov C++ a Python. Základný programový balíček robota NAO obsahuje: zabudovaný softvér bežiaci v robotovi podporujúci jeho autonómny režim, 89

90 príručný softvér spustiteľný na počítači umožňujúci tvorbu nových foriem správania, vzdialenú kontrolu a simulácie, nástroje pre programátorov umožňujúce vzdialenú kontrolu robota ako aj rozšírenie balíčkov zabudovaného softvéru. Zabudovaný softvér robota NAO pozostáva z dvoch častí. OpenNAO, GNU/Linux distribúcia založená na Gentoo, špeciálne vyvinutá pre potreby robota NAO. NaoQi, základný softvérový balíček, ktorý riadi robota a ovláda prakticky všetky jeho časti. Kópie NaoQi bežia takisto na klientských počítačoch a sú teda súčasťou rozšíreného programového vybavenia za účelom testovania programov vo virtuálnom prostredí. Príručný rozšírený softvér obsahuje tri balíčky. Choregraphe, vizuálny programovací jazyk, ktorý umožňuje tvorbu animácii foriem správania pre robota NAO, ako aj testovanie týchto programov v simulovanom robotickom prostredí, monitoring a vzdialené ovládanie robota. Intuitívne grafické rozhranie, rozšírené programovacie funkcie a knižnica ľahko modifikovateľných preddefinovaných foriem správania robota spĺňa požiadavky začínajúcich aj pokročilých programátorov. Obr. 6: Základný nástroj vizuálneho programovania robota NAO Monitor je softvérové vybavenie venované elementárnej spätnej väzbe z robota a jednoduchému prístupu k nastaveniam kamier robota. NAOsim, simulátor umožňujúci testovanie vytvorených programov vo virtuálnom svete. Podporuje vkladanie a modifikáciu objektov rôznych tvarov do virtuálneho sveta interagujúcich s robotom NAO. 90

91 Nástroje pre programátorov zahŕňajú už spomínaný softvér Choregraphe a jeden z dostupných SDK (C++, Python,.Net C#, Java). V závislosti na zvolenom programovacom jazyku je užívateľ schopný: vytvárať aplikácie pre vzdialené ovládanie robota (všetky SDK), vytvárať nové NaoQi moduly (C++, Python), obohacovať knižnicu programovacieho jazyka Choregraphe (Python). Obr. 7: Základná štruktúra tvorby programu pre robot NAO Na základe týchto vyššie popísaných vlastností je robotická platforma NAO ideálnym výskumným prostriedkom pre univerzity a iné výskumné laboratória. Uplatnenie však nachádza aj v iných oblastiach priamo v praxi a úzkou spoluprácou spoločnosti Aldebaran Robotics s univerzitami a výskumnými ústavmi sa robot NAO stáva prístupnejším širšej verejnosti. Robot NAO sa stal základnou platformou robotickej futbalovej ligy v roku 2007, keď nahradil robota Aibo vyvinutého spoločnosťou Sony. Do povedomia verejnosti sa NAO dostáva aj prostredníctvom rôznych projektov ako je projekt ALIZE, ktorý je zameraný na oblasť interakcie človeka so strojom. Iniciatívou spoločnosti Aldebaran Robotics je využitie robota NAO pre pomoc deťom s autizmom. Spolupracuje s rodičmi týchto detí, s terapeutmi a spolu hľadajú riešenia ako plne využiť možnosti robota NAO pre pomoc týmto deťom. S príchodom novej generácie robota NAO a jej uvedenia na trh v roku 2012 sa očakáva ešte rýchlejšie tempo rozšírenia humanoidnej robotiky a samotnej robotickej platformy NAO ako v priemyselnej tak aj sociálnej sfére. 5. Návrh učiaceho sa teleoperačného systému Jednou z možností ako dosiahnúť ciele popísane v predchádzajúcej kapitole je transfer znalostí od operátora k stroju. Priama teleoperácia zabezpečená počítačovým 91

92 systémom poskytuje všetky potrebné dáta pre odvodenie pravidiel, na základe ktorých sa operátor rozhoduje pri vykonávaní určitej úlohy, keďže vychádzame z predpokladu, že informácie, vstupné aj výstupné sú sprostredkované. Nasledujúci obrázok predstavuje schému navrhovaného učiaceho sa teleoperačného systému. Celkový učiaci sa systém pozostáva zo štyroch základných prvkov. Človek v úlohe operátora, určitý počet teleoperátorov, prostredie, v ktorom sa teleoperátory nachádzajú a samotný systém zabezpečujúci komunikáciu medzi operátorom a teleoperátormi, teda rozhranie človek-stroj, rozšírený o tri základné bloky naznačené na obrázku č. 8 (Virtual Asistent). Rozšírenie pozostáva z monitorovacieho agenta, zabezpečujúceho viacero funkcií pre podporu extrakcie pravidiel danej úlohy vykonávanej operátorom. Tento blok je na obrázku označený ako Learning Phase. Činnosť agenta pozostáva z vykonania viacerých krokov, ktoré sú interaktívne požadované od operátora. V prvom rade je potrebné definovať parciálnu úlohu, ktorú operátor teleoperačným riadením vykonáva. To je zabezpečené blokom Task Definition. Následne operátor vyznačí vstupy a výstupy, s ktorými pracuje a považuje za potrebné pri vlastnom rozhodovaní v procese riešenia úlohy. Systém je v tejto fáze pripravený sledovať používateľa pri danej činnosti. Obr. 8: Základný návrh tvorby teleoperačného systému 92

93 Následne sú odvádzané vzťahy medzi vstupmi a výstupmi od operátora v procese teleoperačného riadenia vo forme pravidiel. Po získaní dostatočného počtu trénovacích dát sú tieto pravidlá optimalizované a následne uložené do databázy v bloku Database Partial Task Database ako súbor pravidiel pre riešenie parciálnej úlohy. Tento cyklus odvodzovania pravidiel sa opakuje pre jednotlivé parciálne úlohy. V prípade, že proces učenia sa všetkých potrebných parciálnych úloh pre vytvorenie súvislej misie je ukončený, operátor môže pomocou bloku Mission Builder interaktívne pospájať jednotlivé parciálne úlohy do celistvej misie. Takýmto spôsobom je možné interaktívne vytvárať aj alternatívne úlohy spájaním akýchkoľvek parciálnych úloh, či už sekvenčne alebo paralelne. Finálna misia je následne uložená v databáze misií (Mission Database). V tomto štádiu je systém pripravený vykonávať jednotlivé úlohy alebo misie viac menej autonómne. Vo fáze života virtuálneho asistenta je požadované od operátora zadať teleoperátorom úlohy, respektíve misie. Tie sú zhromažďované v správcovi zásobníka úloh (Mission Stack Manager). Jednotlivé úlohy sú následne vyberané zo zásobníka na základe ich priorít a rozdeľované spätne na parciálne úlohy. Rozbitím na parciálne úlohy je umožnené jednotlivé parciálne úlohy distribuovať medzi viacero robotov, ak sú dostupné a tak efektívnejšie riešiť danú misiu. Po ukončení misie je zo zásobníka misií vybraná iná misia, alebo je riadenie odovzdané operátorovi pre ďalšie učenie alebo manuálne riadenie. 6. Záver Téma ako dávať inteligenciu reálnym alebo virtuálnym robotom môže mať niečo spoločné aj s tvorbou inteligentných rozhodovacích systémov. V princípe, ak máme ľubovoľný proces, tak najprv môže tento proces rozhodovania vykonávať človek a počítač to realizuje ale ak je v pozadí agent, ktorý sleduje správanie sa človeka a učí sa od neho tak následné môžeme aj rozhodovacích systémoch prejsť k tzv. asistovanému rozhodovaniu, kde človek má počas dozrievania systému už len dozornú funkciu. To všetko smeruje k tvorbe tzv. všadeprítomnej inteligencie Ambient Intelligence, ktoré jednotlivé stupne realizácie (stupne autonomity) je problém merať resp. identifikovať tzv. Machine Intelligence Quotient (MIQ) [24,25] pre jednotlivé procesy resp. stroje ako také. Ľudstvo smeruje k štandardizácii a predpokladáme, že nasadzovaním ďalších prostriedkov umelej inteligencie budeme svedkami autonómnych systémov rôznych stupňov pre zlepšenie životnej úrovne človeka resp. transormáciu jeho činností do kreatívneho priemyslu. Literatúra: [1] Sinčák P.: Myseľ, inteligencia a inteligentné technológie (Pohľad obyčajného učiteľa na inteligentné technologie), v zborníku Kvasnička V. a kol. : Myseľ, Inteligencia a život, STU, ISBN , Gratex 2007, pp

94 [2] Hee-Jun Park, Byung Kook Kim : Measuring the Machine Intelligence Quotient (MIQ) of Human Machine Cooperative Systems IEEE Transactions on SMC, Vol. 31, No. 2, March [3] S. Legg, M. Hutter : Universal Intelligence: A Definition of Machine Intelligence, 2007, [4] Sinčák P., Vaščák J. (Eds) Quo Vadis Computational Intelligence, pp. 498, ISBN Publish. In series Studies in Fuzziness and Softcomputing, Springer Verlag, Hardcover. [5] Sinčák P, Vaščák J., Kvasnička V., Mesiar R. (Eds): State of Art in Computational Intelligence, Proceedings of the EICI, pp. 404, ISSN , Published in series Advances in Softcomputing, Springer-Verlag, 2000, Softcover. [6] Sinčák P., Vaščák J., Kvasnička V., Pospíchal J.(eds): Intellignet Technologies Theory and Applications, New Trends in Intelligent Technologies, IOS Press, 2002, ISSN [7] Sinčák P. Vaščák J., Hirota K.(eds): Machine Intelligence: Quo Vadis, February 2004,WorldScientific Publishing House, ISBN X, pp [8] H. Takagi, "Interactive Evolutionary Computation: Fusion of the Capabilities of EC Optimization and Human Evaluation," Proceedings of the IEEE, Vol.89, No.9, pp (2001). [9] Camurri, S. Hashimoto, K. Suzuki, R. Trocca, "KANSEI analysis of dance performance," Proc. Intl Conf IEEE Systems Man and Cybernetics 1999, Tokyo (1999). [10] J. Eperješi, "Gait optimization of AIBO robot based on interactiv evolutionary computation," Applied Machine Intelligence and Informatics,2008. SAMI 2008, Herľany (2008). [11] E. Sasák, "Riadenie chôdze robota Aibo s využitím neurónových sietí, diplomová práca, Technická univerzita Košice (2007). [12] M. Lapko, "Riadenie 4-kolesového automobilového vozidla v šmyku,"diplomová práca, Technická univerzita Košice (2006). [13] M. Kuzma, R. Jakša, P. Sinčák, "Clustering of users inputs in multi-userinteractive evolutionary font design," Applied Computational Intelligence and Informatics, SACI'09, Timisoara (2009). [14] M. Balla, "Aplikácia interaktívnej evolúcie vo webdizajne," diplomová práca, Technická univerzita Košice (2009). [15] M. Užák, R. Jakša, "Framework for the Interactive Learning of ArtificialNeural Networks," 16th International Conference on Artificial Neural Networks, ICANN 2006, Atény, (2006). 94

95 [16] M. Užák, R. Jakša, "Reduction of Visual Information in Neural NetworkLearning Visualization," 18th International Conference on Artificial NeuralNetworks, ICANN 2008, Praha, (2008). [17] Zhi Liu, Yun Zhang, and Yaonan Wang: A Type-2 Fuzzy Switching Control System for Biped Robots, IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS PART C: APPLICATIONS AND REVIEWS, VOL. 37, NO. 6, 2007, pp [18] D. H. Grollman and O. C. Jenkins: Sparse incremental learning for interactive robot control policy estimation, In: Proceedings of the IEEE International Conference on Robotics and Automation (ICRA '08), 2008, pp [19] H. Wang, S. Kwong, Y. Jin, W. Wei and K. Man: A multi-objective hierarchical genetic algorithm for interpretable rule-based knowledge extraction, Int. Journal Fuzzy Sets and Systems, VOL. 149, NO. 1, 2005, pp [20] Riid, E. Rustern: Interpretability of Fuzzy Systems and Its Application to Process Control, IEEE International Fuzzy Systems Conference (FUZZ-IEEE), 2007, pp [21] Vaščák, Ján: Fuzzy Cognitive Maps in Path Planning; Acta Technica Jaurinensis, Series Intelligentia Computatorica, Széchenyi István University, Györ, Hungary, Vol. 1, No. 3, 2008, pp , ISSN [22] E.I. Papageorgiou, C.D. Stylios: Fuzzy Cognitive Maps, In: W. Pedrycz, A. Skowron, V. Kreinovich (Eds.) Handbook of Granular Computing, John Wiley & Sons Ltd., 2008, pp [23] Peter J Thomas, Russel J Stonier: Fuzzy control in robot-soccer, evolutionary learning in the first layer of control, Journal of SYSTEMICS, CYBERNETICS AND INFORMATICS, VOL. 1, NO 1, 2003, pp [24] Park H-P., Kim B-K: Measuring the Machine Intelligence Quotient (MIQ) of Human/Machine Cooperative Systems, IEEE Trans. On SMC / Part A,: Systems and Humans, Vol. 31, NO 2, March [25] Ozkul T., Gene H.I : development of Cost Adjusted MIQ Concept for Measuring Intelligence Value of Systems, Proceedings of the International Multiconference of Engineering and Computer Scientists 2011, Vol 1, IMECS 2011, March 16-18, 2011, Hong-Kong, China. Prof. Ing. Peter Sinčák, CSc. Technická univerzita v Košiciach, Fakulta elektrotechniky a informatiky, Katedra kybernetiky a umelej inteligencie, Centrum pre inteligentné technológie, Boženy Nemcovej 3, Košice, Slovenská republika peter.sincak@tuke.sk 95

96 Ing. Martin Paľa Katedra kybernetiky a umelej inteligencie, Centrum pre inteligentné technológie, Letna 9, Košice, Slovenská republika martin.pala@ymail.com Ing. Mária Virčíková Technická univerzita v Košiciach, Fakulta elektrotechniky a informatiky, Katedra kybernetiky a umelej inteligencie, Centrum pre inteligentné technológie, Boženy Nemcovej 3, Košice, Slovenská republika maria.vircikova@tuke.sk 96

97 MOBILNÍ APLIKACE (ANDORID) OBCHODNÍ CESTUJÍCÍ MOBILE APPLICATION (ANDROID) TRAVELING SALESMAN Vladimír Skoupý Abstrakt V dnešní době je trh s mobilními zařízeními na obrovském vzestupu a pro mobilní platformu Android to platí dvojnásob. Ta v současnosti pohání téměř polovinu všech mobilních zařízení. Rozšířenost Android platformy je možná především díky značné otevřenosti, která umožňuje vývojářům vytvářet velké množství různorodých aplikací pro koncové uživatele. Cílem práce je vytvoření aplikace pro potřeby obchodního cestujícího, který se stará o své zákazníky z obchodního hlediska a to především formou osobních návštěv. Zpravidla je při této obchodní činnosti potřeba komunikovat s centrálním informačním systémem a vhodným způsobem spravovat relevantní informace o zákaznících. Aplikace by měla umožnit obchodnímu cestujícímu efektivně pracovat přímo v terénu za pomoci mobilního zařízení s operačním systémem Andorid. Návrh aplikace, včetně návrhu uživatelského rozhraní, vyplývá z funkčních požadavků. Klíčová slova mobilní, aplikace, android, obchodní cestující Abstract Nowadays the mobile devices market is on the huge rise and form Android mobile platform it is doubly true. It currently runs on nearly half of all mobile devices. The dissemination of the Android platform is perhaps mainly due to the openness that allows developers to create large number of rich applications for end users. The aim is to create an application for the needs of the traveling salesman who cares about their customers from a business perspective, especially through personal visits. Usually, in this business, there is need to communicate with a central information system and appropriately manage the relevant information about customers. The application should allow the traveling salesman to work effectively in the field, using mobile devices running Andorid. Application design, including user interface design, results from functional requirements. Keywords mobile, application, android, traveling salesman 97

98 1. Úvod V dnešní době je trh s mobilními zařízeními na obrovském vzestupu a pro mobilní platformu Android to platí dvojnásob. Ta v současnosti pohání téměř polovinu všech mobilních zařízení. Rozšířenost Android platformy je možná především díky značné otevřenosti, která umožňuje vývojářům vytvářet velké množství různorodých aplikací pro koncové uživatele. Cílem práce je vytvoření aplikace pro potřeby obchodního cestujícího, který se stará o své zákazníky z obchodního hlediska a to především formou osobních návštěv. Zpravidla je při této obchodní činnosti potřeba komunikovat s centrálním informačním systémem a vhodným způsobem spravovat relevantní informace o zákaznících. Aplikace by měla umožnit obchodnímu cestujícímu efektivně pracovat přímo v terénu za pomoci mobilního zařízení s operačním systémem Andorid. Návrh aplikace, včetně návrhu uživatelského rozhraní, vyplývá z funkčních požadavků. 2. Návrh aplikace Tato kapitola se zabývá analýzou a návrhem implementace vybrané problematiky. Analýza zahrnuje definici základních požadavků na systém, vytvoření modelu případů užití, návrh struktury aplikace včetně její datové části a návrh uživatelského rozhraní. 3. Rozbor problému Cílem práce je vytvořit aplikaci pro potřeby obchodního cestujícího. Obchodní cestující je pracovník, zabývající se prodejem zboží, který má na starosti péči o nové a stávající zákazníky z obchodního hlediska a to z pravidla formou osobních návštěv v místě zákazníka Obchodní cestující tvoří obrat prodejem firemních produktů. Ke své práci zpravidla využívá automobil, mobilní telefon, diář, případně notebook. Obchodní cestující má většinou na starost určitý region, jako například Východní Čechy, nebo celou Českou republiku. Zpravidla má obchodní cestující nějakým způsobem zprostředkovaný přístup do centrálního informačního systému, kde jsou uloženy informace o zákaznících, produktech, objednávkách apod. Z tohoto systému čerpá obchodní cestující podklady pro svůj pracovní den, během kterého navštěvuje své zákazníky, například za účelem kontroly stavu zásob produktů, vytvoření nových objednávek, či za účelem získání nových zákazníků. S tím vším je spojeno několik problémů. Obchodní cestující musí vědět, kde se jeho zákazníci nacházejí a jak se k nim dostat. Dále musí efektivním způsobem pracovat s informacemi, které získá z centrálního systému, případně přímo v terénu. Informace získané musí opět promítnout zpět do centrálního systému. Našly by se určitě i některé další problémy, ale pro účely mé práce tento výčet vystačí. Maximální úspora času při řešení těchto problémů, je pro obchodního cestujícího zásadní, protože čím více času uspoří, tím více zákazníků může navštívit a tím větší obrat může uskutečnit. 98

99 4. Cíl Dle předchozího rozboru problému je tedy cílem této práce vytvořit jednoduchou aplikaci s využitím Android platformy, která umožní uživateli unikátní přístup k centrálnímu systému s informacemi o zákaznících. Informace by mělo být možné vhodným způsobem upravovat a opět synchronizovat s centrálním systémem. Dále by měla aplikace umožnit efektivnější práci s informacemi o zákaznících pomocí dostupných prostředků, jako jsou GPS navigace, čárové kódy, mapy, telefonní služby apod. 5. Základní požadavky S ohledem na rozbor problému a cíl, vyvstává několik základních požadavků na funkčnost aplikace, na jejichž základě bude vytvořen samotný návrh systému: Podpora uživatelských profilů, chráněných heslem. Stažení informací o relevantních zákaznících z centrálního systému. Editace informací o zákaznících. Odeslání dat do centrálního systému. Využití Google map. Využití navigace v Google mapách. Využití telefonního modulu. Využití čtečky čárových kódů. Zobrazení relevantních produktů. Zobrazení informací o stavu zásob produktů u zákazníka. Vytvoření nové objednávky pro zákazníka. Na základě požadavků lze vytvořit jednoduchý diagram případů užití, který zobrazuje jednotlivé požadavky na aplikaci a systém v hlubším kontextu. Tento diagram můžeme vidět na obrázku 1. 99

100 Obr. 1: Diagram případů užití Součástí práce je i jednoduchá implementace centrálního systému, ve formě webové aplikace, poskytující služby, pro vzdálený přístup ke zdrojům. Jedná se vlastně o centrální úložiště objektů, které byly identifikovány při návrhu doménového modelu. Základním doménovým objektem je Lokace, která zapouzdřuje informace o samotné lokaci, zákazníkovi, kontaktní osobě apod. Dalším základním objektem je Produkt, který představuje zboží, které si může zákazník koupit. Každá lokace, respektive zákazník, může mít nějaký stav zásob reprezentovaný stejnojmenným objektem. Dalším objektem doménového modelu je Objednávka, která je svázána s určitou lokací a sdružuje jednotlivé položky, které jsou reprezentované objednaným produktem. V neposlední řadě můžeme také identifikovat objekt představující uživatele, s uživatelským jménem a heslem. Obrázek 2 zobrazuje digram s doménovým modelem, který detailněji znázorňuje objekty, včetně atributů a vazby mezi nimi. 100

101 6. Návrh uživatelského rozhraní Obr. 2: Zjednodušený diagram tříd V následující kapitole je naznačeno, jak by měly vypadat jednotlivé obrazovky aplikace a jaká je mezi nimi návaznost. Při prvním spuštění se zobrazí jednoduchý přihlašovací formulář, umožňující vložit uživatelské jméno a heslo dle obrázku 15. Po přihlášení se zobrazí základní rozcestník aplikace, navržený dle používaných návrhových vzorů uživatelského rozhraní. Rozdělovník nabízí snadný přístup k základním funkcionalitám aplikace (viz. obrázek 4). V horní části každé obrazovky se nachází lišta s vybranými akcemi pro snadnější a intuitivnější ovládání (návrat na domovskou obrazovku, vytvoření lokace apod.). Výběrem lokací zobrazíme seznam relevantních lokací. Kliknutím na položku seznamu se zobrazí detail lokace dle obrázku 5. V rámci detailu je možné zobrazit mapu s polohou lokace, případně vyvolat telefonní číslo uvedené u kontaktní osoby. Součástí detailu je také fotografie lokace. Tlačítkem ve spodní části obrazovky se dostaneme ke kontrole stavu zásob a vytvoření nové objednávky (obrázek 6). 101

102 Obr. 3, 4, 5: Návrh uživatelského rozhraní (přihlášení, hlavní rozdělovník, detail lokace) Ze seznamu lokací je možné vyvolat formulář, pomocí kterého můžeme přidat novou lokaci, včetně její pozice na mapě a fotografie (obrázek 7). Výběr produktů nás přesune z hlavního rozdělovníku na seznam produktů, jejichž detail je možné zobrazit obdobným způsobem jako v případě lokací (viz obrázek 8). Zbylé položky na hlavní obrazovce slouží pro synchronizaci dat s centrálním systémem, odhlášení uživatele a spuštění čtečky čárových kódů. Obr. 6, 7, 8: Návrh uživatelského rozhraní (stav zásob, nová lokace, detail produktu) Uživatelské rozhrání je optimalizované pro různé rozměry obrazovek a to jak pro vodorovnou, tak pro svislou polohu mobilního zařízení. 102

103 7. Implementace aplikace V následujících kapitolách je popsána implementace aplikace s ohledem na předchozí návrh. Jsou zde zmíněny některé pokročilejší technologie, které byly v rámci aplikace použity, včetně jejich ukázek. 8. Implementace uživatelského rozhraní Většinou existuje pro každou aktivitu aplikace jeden XML soubor, popisující rozvržení komponent. Zpravidla je tento soubor uložen ve složce res/layout/. 9. Práce na pozadí Obr. 9, 10, 11: Implementace uživatelského rozhraní dle návrhu Kód aktivity běží zpravidla ve vlákně uživatelského rozhraní, a pokud nepoužijeme prostředky umožňující souběžnost, poběží veškerý kód právě v tomto vlákně. Při vykonávání dlouho trvajících operací, jako například stahování dat z internetu, je uživatelské rozhraní zablokováno, dokud není operace dokončena. Pokud aktivita nereaguje po dobu 5 sekund, je uživateli zobrazeno dialogové okno, informující o tom, že aktivita neodpovídá. Uživatel může prostřednictvím dialogu ukončit celou aplikaci. Chceme-li uživateli zajistit dobrou zkušenost s aplikací, pak by měla každá potenciálně dlouho trvající operace běžet asynchronně, ve svém vlastním vlákně. To můžeme zajistit prostředky, které nabízí samotný jazyk Java nebo aplikační framework Androidu. AsyncTask AsyncTask umožňuje asynchronní práci v rámci uživatelského rozhraní. Dlouho trvající operace je prováděna ve vlastním vlákně a může interagovat s 103

104 uživatelským rozhraním, aniž bychom museli nějakým způsobem řešit komunikaci mezi vlákny. 10. Komunikace prostřednictvím internetu Téměř každé mobilní zařízení využívající systém Android, má zabudované prostředky pro připojení k internetu. Jedná se především o Wi-Fi, mobilní datové služby v podobě EDGE, 3G apod. Android nabízí vývojářům rozsáhlé možnosti využití těchto služeb. Součástí systému je knihovna Apache HttpComponents, kterou využijeme k přístupu k webovým službám, založených na architektuře REST. REST REST (Representational State Transfer) je architektura rozhraní, navržená pro distribuované prostředí. Tato architektura je založena na webových standardech a protokolu HTTP. V REST architektuře je vše považováno za zdroj, ke kterému je možno přistupovat prostřednictvím základních HTTP metod. Zpravidla existuje REST server, poskytující zdroje a REST klient, který ke zdrojům přistupuje. Zdroje jsou obvykle identifikovány prostřednictvím url adres a mohou být reprezentovány různým způsobem, např. jako text, XML, JSON apod. REST Server Součástí práce je jednoduchý REST server, který funguje jako zdroj dat pro naší ukázkovou mobilní aplikaci. Server je implementován jako webová aplikace v jazyce Java. Java definuje podporu REST standardu prostřednictvím JAX-RS (The Java API for RESTful Web Services). JAX-RS využívá anotace k označení relevantních tříd v rámci REST architektury. V konfiguraci webové aplikace je potřeba zaregistrovat servlet, který je dodáván v rámci referenční implementace JAX-RS Jesrsey. Dále je potřeba definovat url, pod kterou bude naše REST webová aplikace dostupná. Servlet analyzuje příchozí HTTP požadavek a vybere konkrétní třídu a metodu, která jej obslouží. REST klient Součástí práce je samozřejmě i klientská část REST architektury, která komunikuje se serverem, zmíněným v předchozí kapitole. Klient je reprezentován samotnou mobilní aplikací, respektive komponentami, která využívají služeb, vystavených na serveru. Aby mohla aplikace komunikovat prostřednictvím internetu, je potřeba deklarovat v Android manifestu patřičné oprávnění: <uses-permission android:name="android.permission.internet" /> Klient je implementován pomocí knihovny Apache HttpClient, která je součástí Apache HttpComponents. 104

105 11. Zpracování odpovědi Android obsahuje tři základní nástroje pro zpracování XML (parsery). Jedná se o tradiční W3C DOM Parser (org.w3c.dom), SAX Parser (org.xml.sax) a XML Pull Parser. Z důvodu jednoduchosti byl v rámci ukázkové aplikace použit W3C DOM Parser, který si představíme v následující kapitole. W3C DOM Parser DOM (Document Object Model) je objektově orientovaná reprezentace XML dokumentu, která je realizována jako hierarchická stromová struktura. Každému elementu odpovídá jeden uzel stromu. Rozhraní parseru umožňuje číst nebo modifikovat obsah, strukturu nebo styl dokumentu či jeho části. Při zpracování XML dokumentu parserem je nahrán jeho celý obsah do paměti a prostřednictví DOM API k němu lze přistupovat. Jedná se o velmi přímočarý a jednoduchý přístup ve srovnání s ostatními. Jedinou slabinou parseru je vyšší paměťová náročnost, která se však neprojevuje při zpracování méně rozsáhlých dokumentů, které budeme v rámci naší aplikace používat. 12. Ukládání dat Nyní si vysvětlíme, jakým způsobem je možné data na mobilním zařízení uložit. Android nabízí několik přístupů k ukládání dat. Výběr je závislý především na našich preferencích. Musíme například zvážit, jestli chceme sdílet data s dalšími aplikacemi nebo kolik místa naše data vyžadují. Zde je výčet možností: Sdílené předvolby slouží k uložení hodnot primitivních datových typů ve formě klíč hodnota. Data jsou uložena v rámci uživatelského sezení aplikace, a to dokonce i v případě násilného ukončení aplikace. Interní paměť ukládání dat ve formě souborů do vnitřní paměti mobilního zařízení. Primárně jsou data viditelná pouze pro danou aplikaci a ostatní k nim tedy nemohou přistupovat. Pokud uživatel aplikaci odinstaluje, jsou tyto soubory smazány. Externí paměť každé zařízení s Androidem podporuje ukládání souborů do externí sdílené paměti, jako je SD karta apod. Takto uložené soubory mohou být nedostupné ve chvíli, kdy připojíme externí paměť například k počítači. Vždy by se mělo ověřit, zda je externí paměť k dispozici. Databáze ukládání strukturovaných dat do databáze. Android plně podporuje SQLite databáze. Pokud vytvoříme nějakou databázi v rámci aplikace, může k ní přistupovat jen tato aplikace. Připojení k síti ukládání dat na vlastním vzdáleném serveru. Pro účely naší aplikace byla zvolena databáze. Tento přístup nejlépe odpovídá našim požadavkům, protože naše data jsou strukturovaná a měla by být dostupná jen naší aplikaci. 105

106 SQLite Android poskytuje plnohodnotné možnosti relační databáze, bez výraznějších omezení ve formě knihovny SQLite. Pomocí SQLite lze vytvářet nezávislé relační databáze pro každou aplikaci, která tak může ukládat a spravovat komplexní strukturovaná data. Všechny Android databáze jsou uloženy na zařízení v adresáři /data/data/<nazev_balicku_aplikace>/databases. Primárně jsou všechny databáze přístupné jen těm aplikacím, které je vytvořily. SQLite je implementována jako kompaktní knihovna napsaná v jazyce C, která je součástí běhového prostředí Androidu. Díky tomu lze databáze jednoduše integrovat do aplikace, což snižuje externí závislosti, paměťovou náročnost, dobu odezvy a zjednodušuje synchronizaci. SQLite lze považovat za spolehlivý databázový systém, vhodný pro použití na mobilních zařízeních. Databáze používá rozhraní SQL a dialekt dotazovacího jazyka se liší od standardu SQL-92 jen v několika maličkostech, obdobně jako u většiny dalších SQL databází. 13. Lokalizační služby V dnešní době je s velkou oblibou využíván systém GPS, který umožňuje určit zeměpisnou polohu mobilního zařízení. Polohu lze kromě GPS určit pomocí dalších systémů nebo například Wi-Fi sítí, které mají známou zeměpisnou polohu. V Androidu existuje několik prostředků pro určení zeměpisné polohy, které se liší především přesností a množstvím poskytovaných informací. Soubor poskytovatelů zeměpisné polohy je reprezentován objektem LocationProvider. Pro každou lokalizační službu je k dispozici jeden poskytovatel, který je spravován objektem LocationManager. V rámci flexibility je možné použít objekt Criteria, ve kterém můžeme definovat, jakým způsobem vybrat poskytovatele. V závislosti na zvoleném poskytovateli je potřeba získat pro aplikaci patřičné oprávnění. Například pro využití systému GPS je nutno deklarovat v manifestu následující: <uses-permission android:name="android.permission.access_fine_location" /> Mapy Zjišťování aktuální zeměpisné polohy je často propojeno s využitím služby Google map, díky které můžeme získanou polohu zobrazit na mapě. Podmínkou integrace map v rámci aplikace je odsouhlasení řady právních podmínek a získání validního klíče, který nám umožní využívat API Google map. Samotné API Goole map je k dispozici jako rozšíření Android SDK a je tedy potřeba vytvořit projekt s vhodným cílem, aby byla přítomnost API zajištěna. Potřebné komponenty 106

107 Komponenty pro práci s Google mapami jsou k dispozici prostřednictvím balíčku com.google.android.maps. Základní komponentou je třída MapActivity, která rozšiřuje původní třídu Activity o služby pro zobrazování komponenty MapView. 14. Využití dalších aplikací V Androidu je kladen důraz na snadnou znovupoužitelnost již vytvořených funkčních komponent. Předávání řízení mezi jednotlivými komponentami probíhá pomocí záměrů. Záměry společně s jejich filtry vytvářejí mocný nástroj, který umožňuje propojovat spolu různé komponenty, které mohou být součástí různých aplikací. Tato skutečnost zvyšuje znovupoužitelnost hotových řešení, umožňuje vytvářet pestřejší aplikace a odkrývá uživateli fakt, že na dosažení určitého cíle se může podílet několik aplikací. V rámci naší ukázkové aplikace je pro větší efektivitu samotné aplikace využito několik komponent, dostupných prostřednictvím systému Android nebo za pomoci aplikací třetích stran. 15. Závěr Hlavním přínosem práce je vytvoření referenční aplikace pro potřeby obchodního cestujícího na základě stanovených požadavků. Při implementaci byly použity základní komponenty a některé pokročilejší technologie. Aplikace splňuje veškeré požadavky, které byly vytyčeny v části návrhu aplikace. Ačkoliv byly splněny všechny vytyčené požadavky, vždy existuje prostor pro další rozšiřování a vývoj aplikace. V budoucnu by bylo možné rozšířit aplikaci například o další lokační služby, které by upozorňovali na lokace, které se nachází v blízkosti uživatele. Dalším možným rozšířením by mohlo být zavedení kompletní architektury REST, která by pracovala se zdroji na vzdáleném serveru. Tím by odpadla potřeba vytvářet lokální databázi, kterou je vždy nutné synchronizovat s tou vzdálenou. Nicméně by musel být zajištěn neustálý přístup k internetu. Obdobných modifikací a rozšíření by se jistě našla celá řada a v rámci vlastní iniciativy se určitě pokusím některé z nich v budoucnu do aplikace implementovat. Literatura [1] GOOGLE INC. Android developers [online] [cit ]. Dostupné z: < [2] MURPHY, Mark L. Android 2: Průvodce programováním mobilních aplikací. Praha: COMPUTER PRESS, [3] MEIER, Reto. Professional Android application development: Průvodce programováním mobilních aplikací. Indianapolis, IN: Wiley, ISBN Ing. Vladimír Skoupý Univerzita Hradec Králové, Fakulta informatiky a managementu Rokitanského 62, Hradec Králové, Česká republika vladimir.skoupy@uhk.cz 107

108 VYUŽITÍ MULTIAGENTOVÉHO SYSTÉMU V SIMULACI AKCIOVÉHO TRHU USING MULTIAGENT SYSTEM IN STOCK MARKET SIMULATION Jiří Štěpánek Abstrakt Text popisuje model a implementovanou simulaci chování obchodníků na trhu s akciemi. Popsán je jak původní výchozí model, tak jeho rozšířená a upravená verze. Text popisuje proces vzniku softwarové simulace, která byla vytvořena pro účel zkoumání vlivu okolí na rozhodování agenta. Simulace je založena na multiagentovém systému. Text rozebírá možnosti a omezení jak původního, tak rozšířeného modelu trhu s akciemi. Dále jsou zde popsány možnosti vytvořené aplikace, její přínosy a úlohy, které aplikace dokáže simulovat. Klíčová slova Akciový trh, simullace, multiagentový systém Abstract The text describes the simulation model of stock market traders behaviour and its implementation. The original baseline model and its modified and extended versions are described. The text shows the process of creating simulation software, which was created for the purpose of examining the impact of environment to agent s decision. Simulation is based on multi-agent system. The text discusses the possibilities and limitations of both original and extended mode of stock market. It further describes the possibilities created by the application, the benefits and tasks that the application can simulate. Keywords Stock market, simulation, multi-agent system 1. Introduction Multi-agent systems are used in many types of simulations like biology, economics or tourism. Generally, these simulations are used in cases, when standard analytical methods are not useable or problem is too complex. One of these complex problems is stock market and its processes. We can imagine basic stock market as a set of people who buy or sell their shares. The main goal of participants is to generate profit arising from difference between past-value and 108

109 present value of shares. Principle of generating profit is simple when held shares have higher value than the original value, participant sells it. There is also mechanism forming price of shares. When demand for shares grows up, price of these shares also grows up. Stock market with these properties can be simplified and transformed into the model. Model can be programmed as a simulation that has its parameters and constants. The main advantage of this abstracting and modelling process is development of a simulation that can be launched many times with different parameters. Consequently, results can be compared and some hidden rules or patterns can be revealed. This paper describes the process of development of simple stock market simulation based on existing model extended of new features. 2. Stock market and behaviour of participants Generally, behaviour of stock market participant is very complex. There are few basic strategies, how participant can generate a profit. Each strategy is based on information. In real stock market, participants have incomplete information. They make their decision with information like original stock price, present stock price, probability of stock price growth etc. There is also psychological aspect participants perceive behaviour of other participants in environment and govern their behaviour. For example, if all other participants start to sell their shares, this fact creates a big tendency to influent one participant. This perception of neighbourhood gives additional information of other participant s strategy and provides predicting ability of future stock price changes. These basic rules can be used in model. 3. Simulation development Simulation based on aforementioned facts and inspired by original model created by Galimberti has been programmed in C# on Microsoft.net framework. The main reason, why C# and.net was chosen was bigger extensibility and better possibilities for adjusting and reporting. Original Model Original model is created in the NetLogo environment, which is the application for modelling multi-agent systems. There are few parameters of the model: Fundamental value, lambda, and k. Fundamental value is cost of one share in the beginning of simulation. Lambda is effect of difference between fundamental value of share and its current value. If lambda has higher value, participants are more inclinable to buy shares if their value is higher than its fundamental value. Parameter k shows tendency of participant to herd behaviour. If k is equal to 1, tendency to buy or sell share is equal to number of neighbours making this action. Participants with higher value of k are more influenced by their neighbourhood. 109

110 The probability, that selected agent will buy or sell his/her shares, is calculated in each iteration of simulation. Formula for counting probability of buying probability that agent buys share in time t, is ( ) ( ) ( ) ( ) ( ), where ( ) ( ) is probability of buying based on imitation and ( ) ( ) is probability of buying based on fundamentals. 4. Extended model Original model has been extended in a many ways: The most important improvement is possibility to study size of watched environment and its effect on participant s profits and losses. Application is able to save each participant fund value. Fund value is a positive or negative number which shows how successful participant was. Bankruptcy resulting in leaving participant from the market is not simulated in this version of the model. Another difference between original model and model created in C# is more elaborated individuality of each agent. In comparison to the original version is that each agent has its own value for parameters: Mi and observable neighbourhood (environment). That should make simulation more realistic because agents are more individual. There is also possibility to examine distribution of profits of all agents and test if this distribution is nearly normal or how big difference is between distribution of results and normal distribution. All results are stored in one table, which makes consequent work with results easier. Result table consists of number of agent, profit, characteristics parameters such is Mi and number of watched neighbours. Fig. 1: Class diagram of simulation application Figure 1 shows main class simulation connected with other application classes. The whole simulation is directed by Simulation class, which uses AgentGrid class to represent two-dimensional structure filled by agents. DecissionFunction class 110

111 represents mathematical formula used to make decision for each of agent. Standalone class gives possibility to extend model with new features. StockMarket class represents stock market, which changes price of stock dependently on buyers / sellers ratio. ProfitDistribution class is used to create simulation statistics, provide data for graphs and tables. This class can also perform test for normality of profit distribution. 5. Benefits of extended model and application Created simulation application gives a wide range of options and simulation adjustments. In the simulation it is possible to define number of agents, range of their parameters, or number of iterations. Reporting module that gives information about agents profit distribution in form of chart and table can be considered as another advantage. One of possible objectives is to simulate and observe, how agents observable neighbourhood affects his/her profit. Application is also ready for further development. 6. Conclusion Stock market trading is a complex human activity, where uncertainty plays a significant role. This paper describes the basic and extended model of stock market simulation. The application that was created for simulation based on extended model is also described. Simulations of this type give us the ability to understand certain patterns and these patterns can be used in real world. 7. Acknowledgement This paper is based on specific research project, whose aim is to examine the influence of environment on agent s decision in above-described model. Specific research is called Using multi-agent systems in economical simulations. References [1] FAMA, Eugene. The Journal of Business [online] [cit ]. The Behavior of Stock-Market Prices. Dostupné z WWW: < s.pdf>. [2] GALIMBERTI, Jaqueson. NetLogo [online] [cit ]. NetLogo User Community Models CASM Robot. Dostupné z WWW: < [3] SUHADOLNIK, Nicolas; GALIMBERTI, Jaqueson; DA SILVA, Sergio. Munich Personal RePEc Archive [online] [cit ]. Robot traders can prevent extreme events in complex stock markets. Dostupné z WWW: tockmarkets.pdf. Ing. Jiří Štěpánek Univerzita Hradec Králové, Fakulta informatiky a managementu Rokitanského 62, Hradec Králové, Česká republika 111

112 HYBRIDNÉ PROSTRIEDKY VÝPOČTOVEJ INTELIGENCIE HYBRID MEANS OF COMPUTATIONAL INTELLIGENCE Ján Vaščák Abstrakt Základné prostriedky výpočtovej inteligencie ako fuzzy systémy, neurónové siete a evolučné algoritmy už v celej rade svojich aplikácií preukázali svoju opodstatnenosť. Avšak v rámci umelej inteligencie voči týmto prostriedkom jestvujú isté výhrady. Tento príspevok sa preto zaoberá charakterizovaním samotnej výpočtovej inteligencie a jej postavenia voči symbolickým metódam. Nadväzujúc na to rozoberá vzťahy medzi týmito prostriedkami a definuje základné typy hybridných prostriedkov, ktoré sú v súčasnosti hlavným predmetom vedeckého výskumu v tejto oblasti. Príspevok sa zaoberá hlavne problematikou genetických fuzzy systémov a uvádza niektoré aplikácie pre návrh bázy znalostí fuzzy systémov ako aj spôsoby jej optimalizácie z hľadiska jej výkonnosti a čitateľnosti. Kľúčové slová výpočtová inteligencia, umelá inteligencia, fuzzy systémy, neurónové siete, evolučné algoritmy, hybridné prostriedky výpočtovej inteligencie, genetické fuzzy systémy Abstract Basic means of computational intelligence as fuzzy systems, neural networks and evolutionary algorithms have already proved their quality and justification. However, in the frame of artificial intelligence there are some negative approaches. Therefore, this paper deals with characterizing the notion of computational intelligence and its position n the face of symbolic methods. It continues with description of relations among these means and defines basic types of hybrid means, which are objectives of scientific research in this area. The paper deals mainly with problems of genetic fuzzy systems and introduces some applications for the knowledge base design of fuzzy systems as well as methods of its optimization from the point of view of its performance and readability. Keywords Computational intelligence, artificial intelligence, fuzzy systems, neural networks, evolutionary algorithms, hybrid means of computational intelligence, genetic fuzzy systems 112

113 1. Úvod Definícia umelej inteligencie (UI) ako vednej disciplíny je napriek celej rade pokusov nejednoznačná, keďže nejednoznačná je aj definícia samotného pojmu inteligencia a s ním úzko súvisiacich výrazov myslenie a tvorivosť. Častokrát nevieme ani posúdiť, či daná úloha skutočne vyžaduje vytvorenie novej znalosti, alebo je to len vhodná kombinatorická postupnosť operácií vedúcich z počiatočného do cieľového stavu. Ako vhodné príklady sa tu javia hra šachu a riešenie neurčitých integrálov. Preto väčšiu šancu pojať túto oblasť, jej predmet záujmu a charakteristické metódy máme, ak si zadefinujeme, čo od systému patriaceho do UI očakávame a aké by mal mať vlastnosti. Inteligencia je predovšetkým spojená so schopnosťami ako chápanie, myslenie a učenie sa, ktoré tvoria nerozlučnú trojicu. Niekedy sa myslenie ako súbor aktivít spája s mozgom ako nástrojom na ich vykonávanie. UI by sme teda mohli charakterizovať ako disciplínu, ktorá si kladie za cieľ konštruovať stroje (predovšetkým počítače) schopné vykonávať veci, ktoré by si vyžadovali inteligenciu, ak by ich robil človek [7]. Zdroje pre tvorbu prostriedkov, na základe ktorých by sme mohli vytvoriť skutočný inteligentný systém, alebo systém, ktorý sa aspoň javí ako inteligentný (viď dobre známy Turingov test), predstavujú dve základné skupiny. Jednak sú to formálne prostriedky matematickej logiky ako napr. predikátový počet a jednak prostriedky, ktoré kopírujú procesy a zákonitosti živej prírody, kam patria neurónové siete (NS) a evolučné výpočty, resp. algoritmy (EA). Aj keď od počiatku vývoja UI, ktorej formálne začiatky sú kladené do roku 1956, keď sa v rámci letného seminára o strojovej inteligencii, umelých NS a teórii automatov zišla desiatka priekopníkov a väčšina z nich potom udávala smer vývoja UI, sa využívali obidva typy zdrojov, bolo jasné, že sa jedná o veľmi heterogénne prístupy. Historickým vývojom UI bolo dané, že prevládla oblasť využívajúca formálnu logiku na riešenie úloh UI. Hlavnými prínosmi bolo rozpracovanie mechanizmu ľudského uvažovania, čiže inferencie, v podobe všeobecných metód na riešenie problémov (napr. General Problem Solver), ktoré neskôr smerovali k problémovo orientovaným aplikáciám známym ako expertné systémy a všeobecne k znalostným systémom. Tento prístup vedie k vnímaniu znalostí a údajov vo forme symbolov, dokonca tak, že aj postupnosť čísel v binárnom kóde počítača je chápaná viac ako postupnosť symbolov než čísel. Z tohto dôvodu sa neskôr pre túto oblasť UI zaviedol pojem symbolická UI. Avšak skúsenosť z reálneho života ukazuje, že človek musí neraz používať aj číselnú formu znalosti a spracovávať ju ako čísla. Aj závery medicínskeho výskumu ľudského mozgu vedú viac k jeho chápaniu ako istého zložitého analógového počítača pracujúceho na elektrochemickom princípe. Takže do oblasti UI sa začali od 70-tych rokov presadzovať okrem NS aj EA a fuzzy množiny (FM), resp. logika (FL), ktoré sú založené na číselnom vyhodnocovaní údajov. Pôvodne sa chápali ako skôr isté doplnkové a pomocné prostriedky pre potreby symbolickej UI a preto je možné sa niekedy ešte stále stretnúť s ich súhrnným označením ako subsymbolická UI. Avšak takáto forma pomoci komunitou symbolickej UI bola dlhé obdobie prijímaná s veľkou nevôľou, čo viedlo k rozštiepeniu komunity UI, ktoré čiastočne trvá až dodnes. 113

114 Úprimne povedané, v podstate toto odmietanie bolo počiatkom 90-tych rokov hlavným motívom k vzniku novej disciplíny, aj keď patriacej pod UI, ktorú poznáme buď ako soft computing [10] alebo ako výpočtová inteligencia (VI) [2]. Prvý pojem zaviedol Prof. L.A. Zadeh, tvorca teórie fuzzy množín a druhý pojem definoval Prof. J.C. Bezdek. Obidva pojmy zahŕňajú v sebe rovnaké prostriedky s tým rozdielom, že soft computing sa vzťahuje hlavne na FM a až následne na ich nadväznosť k ostatným prostriedkom a preto má užší záber než všeobecnejší pojem VI, ktorý budeme v ďalšom výhradne používať. V nasledujúcich statiach tohto príspevku sa budeme venovať definovaniu pojmu VI a hlavných prostriedkov doň patriacich. Keďže sa jedná už o známe prostriedky VI, tak po ich stručnej charakteristike na podrobnejšie detaily čitateľa odkážeme na vybranú literatúru. Viac priestoru budeme radšej venovať niektorým vybraným hybridným systémom, ktoré sú vybudované na základných prostriedkoch VI, predovšetkým genetické fuzzy systémy, keďže táto oblasť je stále veľmi dynamická. Uvedieme si niektoré konkrétne návrhy z najnovšieho výskumu a ozrejmíme na niektorých aplikáciách. 2. Výpočtová inteligencia vymedzenie pojmu a jej prostriedky VI je v [2] definovaná na základe výpočtovej inteligencie, kde nejaký systém je výpočtovo inteligentný, ak sa zaoberá iba s číselnými údajmi (tzv. údaje nízkej úrovne), má modul na rozpoznávanie vzorov a nepoužíva znalosť v zmysle UI (rozumej v symbolickej podobe) a navyše vykazuje: výpočtovú adaptivitu, výpočtovú toleranciu voči chybám, rýchlosť podobnú odozve človeka, chybovosť podobnú výkonnosti človeka. Takže prinajmenšom v dvoch bodoch sa VI odlišuje od symbolickej UI, a to: (a) vo forme reprezentácie znalosti a (b) v dôraze na schopnosť adaptácie, čiže učenia sa, kde symbolická UI vykazuje slabé výkony a spolieha sa hlavne na znalostného inžiniera. Takto vlastne môžeme testovať daný prostriedok, či patrí do oblasti VI. Avšak, ako v ďalšom uvidíme, nie všetky prostriedky VI priamo spĺňajú všetky uvedené podmienky, ale aspoň v interakcií s inými prostriedkami musia umožňovať ich splnenie. Napr. fuzzy logika nemá primárne schopnosť adaptácie, avšak túto môže získať v spojení s NS alebo EA. Uvedená definícia dáva spoločný základ pre zjednotenie použitých prostriedkov VI. Medzi základné stavebné kamene VI je možné predovšetkým radiť FL, NS a EA. Okrem toho je možné zaradiť aj iné prostriedky ako napr. teóriu pravdepodobnosti. V tomto ohľade sa už jednotliví odborníci mierne rozchádzajú, napr. [3]. Na obr. 1 je uvedená schéma prostriedkov VI a ich vzájomné prepojenie z hľadiska soft computing-u, kde FL hrá ústrednú úlohu. Avšak, ak si uvedomíme množstvo aplikácií využívajúcich FL v pomere k počtom aplikácií ostatných prostriedkov VI, tak táto schéme sa najviac uplatňuje, a to nielen v aplikáciách, ale aj v rozsahu výskumu jednotlivých oblastí VI. Zvláštnu pozornosť je pritom potrebné venovať tzv. hybridným štruktúram, založených na kombinácii FL, NS 114

115 a EA, ktoré predstavujú istú druhú generáciu VI. Práve posledne zmienenej kombinácii (FL a EA) budeme venovať zvyšok tohto príspevku. Obr. 1: Súhrn prostriedkov VI a ich možné interakcie, NFS neurónové fuzzy systémy, GFS genetické fuzzy systémy, NGFS neurónové genetické fuzzy systémy. 3. Genetické fuzzy systémy EA v spojení s FL sa väčšinou využívajú na nastavenie bázy znalostí fuzzy systému a označujeme ich ako genetické fuzzy systémy (GFS), ale sú aj aplikácie, keď FM sa používajú pre potreby EA a niekedy (avšak nie vždy) sa v takom prípade používa označenie fuzzy genetické systémy. Aj keď genetické algoritmy sú len súčasťou EA, predsa je to najznámejšia časť s najväčším počtom aplikácií EA. Taktiež v oblasti spojenia s FL boli to práve genetické algoritmy, ktoré sa na tento účel použili po prvý krát v 80-tych rokoch a počtom najviac. Preto z tohto dôvodu sa objavujú aj naďalej v názve tejto skupiny prostriedkov, hoci správne by sa malo hovoriť o evolučných fuzzy systémoch. V podstate existujú dva základné prístupy ako využiť EA pri návrhu bázy znalostí fuzzy systému. Buď každý jedinec v populácii bude predstavovať ucelenú bázu znalostí, alebo len jedno pravidlo a bázu znalostí bude vytvárať až populácia ako celok. Prvý prístup sa nazýva Pittsburghský [9] a druhý Michiganský [4]. Hneď na prvý pohľad je zrejmé, že Pittsburghský prístup je možné využiť len v jednoduchších aplikáciách, nakoľko je sprevádzaný vysokým nárastom výpočtovej zložitosti. Avšak Michiganský prístup vyžaduje vyššie nároky na množstvo úloh, ktoré musí riešiť ako napr. nerovnomerné pokrytie stavového priestoru pravidlami, ktoré súvisí s posudzovaním kvality jednotlivých pravidiel. Takže napokon štruktúra Michiganského prístupu a množstvo rôznych doplnkových modulov ho robia podstatne zložitejším, ako je to u Pittsburghského prístupu. V princípe sa v týchto dvoch prípadoch jedná skôr iba o hrubé načrtnutie, ktoré potom môže nadobúdať rôzne modifikácie. V ďalšom uvedieme niektoré dôležité aplikácie GFS. Napokon, by sme čitateľovi dali do pozornosti stránku projektu KEEL ( ktorá sa zaoberá extrakciou znalostí pomocou EA a zároveň poskytuje svoj vlastný softvér, 115

116 ktorý slúži na uvedené účely. V rámci rôznych extrakčných metód sú v tomto programe implementované aj obidva základné typy GFS Návrh TSK fuzzy regulátora pomocou EA Predpokladajme TSK fuzzy regulátor, že má pravidlá v tvare (1), kde jeho výstupná časť u * =f(x1 *,, xn * ) je v podobe lineárnej kombinácie, t.j. u * =w1.x1 * +wn.xn * a kde wi sú parametre výstupnej funkcie. V TSK fuzzy regulátore sa nachádzajú tri základné skupiny parametrov, a to parametre FP vstupov, ďalej parametre výstupných funkcií a napokon parametre bázy pravidiel. Pre potreby optimalizácie návrhu celej bázy znalosti je potrebné zaviesť ešte jeden špeciálny parameter, a to počet pravidiel. Obr. 2: Štruktúra chromozómu TSK fuzzy regulátora podľa [5]. Základný prístup k návrhu TSK fuzzy regulátora je založený na Pittsburghskom prístupe, kde jednotlivci (chromozómy) reprezentujú úplný návrh fuzzy regulátora [5]. Keďže sa jedná o rôzne skupiny parametrov, výsledný chromozóm nebude v podobe jednoduchej postupnosti parametrov, ale bude štruktúrovaný, ako je to znázornené na obr. 2. Ak sú vstupné FP popísané pomocou k parametrov (napr. Gaußovská funkcia má dva parametre stred a varianciu), výstupné funkcie pomocou l parametrov (v prípade lineárnej kombinácie l=n), tak takýto chromozóm bude mať p parametrov: n n i (4) i i1 i1 p k. X l. X, kde X i je počet slovných hodnôt premennej Xi. Index j z obr. 2 slúži pre označenie konkrétnej FP ( j1,, Xi ). Vzťah X i vyjadruje počet všetkých možných 116

117 neprotirečivých pravidiel, čo je ich hornou hranicou. Výsledkom evolúcie je jeden jediný víťazný chromozóm. V každom kroku evolúcie aplikujeme aj tzv. čistiaci algoritmus, ktorý odstraňuje nekvalitné pravidlá (napr. ak a vyskytujú s FP, ktoré majú malé hodnoty príslušnosti). Fitness funkcia závisí od konkrétnej aplikácie. Avšak, ak jej hodnotu delíme počtom pravidiel a hľadáme jej maximum, tak jedince s redukovaným počtom pravidiel budú zvýhodnené. Uvedená metóda má však aj svoje nedostatky. Jednak, nezaručuje, že tá istá slovná hodnota použitá vo viacerých pravidlách, bude mať tú istú FP. Inými slovami, dochádza k sémantickej nekonzistentnosti, čo nie je žiaduce. Ďalej, vyžaduje, aby sme vopred zadali počet slovných hodnôt pre dané vstupné premenné, t.j. X. Tento nedostatok rieši napr. metóda popísaná v [6], kde využíva zhlukovanie Multi-kriteriálne prístupy pri návrhu bázy znalostí V poslednom období požiadavky na tvorbu znalostí sa neustále zvyšujú. Okrem ich presnosti sa vyžaduje aj ich zrozumiteľnosť pre ľudí. Neraz takéto požiadavky sú protirečivé a je potrebné medzi nimi nájsť vhodný kompromis, čo je úlohou multikriteriálnych GFS, ktoré na tento účel využívajú vhodne zadefinované miery (metriky). V ďalšom si na dvoch aplikáciách ukážeme, ako je možné hľadanie rovnováhy medzi rôznymi kritériami riešiť. Z hľadiska zrozumiteľnosti (čitateľnosti) bázy znalostí pre človeka je možné konštatovať, že jej napomáha splnenie aspoň týchto podmienok: (a) FP pre všetky definované slovné hodnoty sú tzv. normálne, t.j. aspoň jedna hodnota má stupeň príslušnosti 1. (b) Je definovaný rozumný počet FP na danej premennej, tzv. granularita, čo je číslo 7-9. (c) FP by mali byť navzájom dobre rozlíšiteľné, t.j. nie príliš veľké vzájomné prekrytie. (d) Definičný obor premennej by mal byť plne pokrytý FP, t.j. každá hodnota patrí aspoň do rozsahu jednej slovnej hodnoty. Z uvedeného okrem bodu 1 vyplýva, že rozdelenie univerza, čiže definičného oboru danej premennej, priamo vplýva na čitateľnosť bázy znalostí a preto hľadanie vhodného rozdelenia má kľúčové postavenie v tejto úlohe. Za obzvlášť dobre čitateľnú bázu znalostí sa považuje tá, ktorá má rovnomerne rozdelené univerzum medzi jednotlivé FP, t.j. pre každú hodnotu x premennej X platí ( x) 1. Avšak takto navrhnuté FP nemusia zaručiť tvorbu pravidiel, ktoré by presne popisovali danú sústavu alebo stav. Spravidla presne navrhnutá báza znalostí má veľmi nerovnomerne rozložené FP a preto je zle čitateľná. Takže je potrebné navrhnúť vhodný kompromis medzi čitateľnosťou a presnosťou. V [1] bol pre tento účel navrhnutý transformačný reťazec, ktorý je zobrazený na obr. 3. Predpokladajme, že prostredníctvom nejakého učiaceho algoritmu sme pre premennú Xi získali FP Ai,1 až Ai,9, ktoré vytvárajú rozdelenie (partíciu) Pi a ktoré evidentne nie je rovnomerné. Jeho rovnomerná obdoba by vyzerala ako Pi, viď obr. i 117

118 3 (a). Aby sa tieto dve rozdelenia mohli dať do súladu, tak sa zavádza po častiach lineárna transformácia t, ktorej body zlomu zodpovedajú polohám vrcholov príslušných FP (šípkami naznačený postup tvorby bodov zlomu). Predpokladajme, že optimálny počet FP je 5, čomu zodpovedá rovnomerné rozdelenie Pi, ktoré je však iba virtuálne a je vhodné na zohľadnenie podmienky rovnomernosti. Preto sa transformačná funkcia t premietne aj do obr. 3 (b), kde šípkami je naznačený postup výpočtu vrcholov výsledného rozdelenia Pi. V tomto prípade sú FP v podobe trojuholníkov definovaných trojicou parametrov a, c, b prvé dva sú krajné body FP a posledný je jej vrchol, kde krajné body každej FP sú zároveň vrcholmi susedných FP. Ako vidno, rozdelenie Pi síce nie je úplne rovnomerné, ale lepšie čitateľné než pôvodné rozdelenie Pi. (a) Obr. 3: Postup transformácie medzi rozdeleniami univerza Pi Pi Pi Pi. Na obr. 3 (a) je vidno, že čím sa Pi a Pi od seba viac odlišujú, tým sú zlomy medzi jednotlivými úsečkami transformácie t výraznejšie. Ak by tieto rozdelenia boli identické, transformácia by predstavovala priamku. Je možné zadefinovať istú mieru podobnosti týchto dvoch rozdelení, napr. ako index integrity [1], ktorá bude predstavovať fitness funkciu. Zostáva už len definovať štruktúru chromozómu. V tomto prípade sa skladá z troch častí, a to: rozdelení Pi pre všetky premenné, optimálnych počtov FP a rozdelení Pi. Vykoná sa klasický optimalizačný postup na základe genetických algoritmov a jedinec s najvyšším indexom integrity bude mať najlepší pomer presnosti a čitateľnosti. (b) Ďalšia aplikácia sa zaoberá extrakciou pravidiel v prípade, že ich máme k dispozícii príliš veľa. Väčšinou totiž veľké množstvo pravidiel nie je len neprehľadné, ale vyskytujú sa v takejto sade aj mnohé pravidlá, ktoré majú nízku informačnú hodnotu a skôr robia výsledok menej presným, než by to bolo v prípade ponechania iba relevantných pravidiel. V prípade, že vykonávame klasifikáciu M 118

119 vzoriek x do tried C s indexom h, tak za týmto účelom sa definujú miery istoty mi a pokrytia mp [8]: mi mp xc M p1 xch ( x) k h, ( x) k ( x) M k h, kde k je sila k-teho pravidla a Mh je počet vzoriek patriacich do triedy h. Miera istoty vyjadruje hodnovernosť daného pravidla, t.j. jeho váhu. Ak toto do danej triedy klasifikuje všetky iba tam patriace vzorky a nijaké iné, tak nadobúda maximálnu hodnotu 1. Miera pokrytia je vhodná vtedy, ak máme nerovnomerne rozložené vzorky, t.j. niektoré triedy ich majú veľa a niektoré málo. Bolo dokázané, že tzv. Paretove pravidlá optimality veľmi dobre vyhovujú požiadavkám na extrakciu pravidiel. Na obr. 4 sa nachádza zobrazenie jednotlivých pravidiel, označených ako krúžky, fakticky podľa ich relevantnosti, čo sme dostali pomocou uvedených mier. Ak pravidlá majú príliš nízke hodnoty obidvoch mier, tak zo zoznamu sú vyškrtnuté ako sporné s malou informačnou hodnotou. Podobne sú vylúčené pravidlá s vysokou istotou, ale malým pokrytím, t.j. sú presné, ale príliš špecifické. Zo zvyšných pravidiel sa extrahujú pravidlá, ktoré sú buď Pareto-optimálne alebo Pareto-suboptimálne. Prvá skupina predstavuje samozrejme tie informačne najkvalitnejšie pravidlá, avšak v dôsledku príliš prísnej extrakcie ich môže zostať veľmi málo, viď pravidlá s čiernymi krúžkami v obr. 4 (a). V takomto prípade je potrebné zadefinovať pre obidve miery isté okrajové zmiernenia mi a mp, viď obr. 4 (b), kde získame aj Pareto-suboptimálne pravidlá zobrazené ako sivé krúžky. Takáto sada pravidiel s čiernymi a sivými krúžkami predstavuje kandidátske pravidlá, ktoré postupujú do ďalšieho výberu (extrakcie). Po výbere N kandidátskych pravidiel sa vytvorí populácia binárnych jedincov od dĺžke N a jednotlivé prvky daného jedinca budú predstavovať jednotlivé pravidlá. Ak daný prvok jedinca má hodnotu 0, tak sa v populácii dané pravidlo nenachádza, ak hodnota je 1, tak pravidlo je obsiahnuté. Takáto populácia je potom vstupom do klasického genetického algoritmu a po patričnom počte generácií sa vyberie jedinec, t.j. báza pravidiel, s najlepším ohodnotením. Fitness funkcia sa definuje v tomto prípade ako priamo úmerná priemernej kvalite klasifikácie pre každú triedu a nepriamo úmerná počtu vybraných pravidiel. 4. Záver V tomto príspevku bola uvedená definícia VI a jej miesto v kontexte UI. Z časového hľadiska vývoja je možné prostriedky VI kategorizovať do dvoch generácií. Prvá generácia je tvorená pôvodnými prostriedkami, t.j. NS, FL a EA. Okrem EA, kde sa ešte stále navrhujú rôzne nové prírodné a sociálne analógie, je výskum základov NS a FL v podstate uzatvorený. Avšak najmä v posledných dvadsiatich rokoch dochádza k procesu intenzívnej hybridizácie týchto prostriedkov, ktoré môžeme 119 (5) (6)

120 radiť do druhej generácie VI. Obzvlášť silne zastúpenými sú oblasti NFS a GFS. V budúcnosti sa môže očakávať, že bude snaha tieto hybridné prostriedky zabudovať do spoločného prostredia s ostatnými prostriedkami informačných technológií, napr. rozľahlými databázovými a komunikačnými systémami, alebo aj konvenčným riadením, a tak sa stať súčasťou integrovaných informačných systémov s vysokým stupňom inteligencie. (a) Obr. 4: Príklad (a) Pareto-optimálnych pravidiel (čierne krúžky) a (b) Pareto-suboptimálnych pravidiel (sivé krúžky) [8]. Ako hlavný historický prínos VI je možné považovať rozpracovanie prístupov strojového učenia a ich implementáciu do reálnych aplikácií, čím výrazne posunuli možnosť automatizácie ľudských činností do oblasti kognície. Literatúra [1] ANTONELLI, M., P. DUCANGE, B. LAZZERINI a F. MARCELLONI. Exploiting a Three-Objective Evolutionary Algorithm for Generating Mamdani Fuzzy Rule- Based Systems. In: Proc. of IEEE World Congress on Computational Intelligence (WCCI). Barcelona (Spain), 2010, Vol. FUZZ, s ISBN [2] BEZDEK, James C. What is computational intelligence?. ZURADA, Jacek M, Robert J MARKS a Charles J ROBINSON. Computational intelligence: imitating life. New York: Institute of Electrical and Electronics Engineers, 1994, s ISBN [3] ENGELBRECHT, Andries P. Computational intelligence: an introduction. Hoboken, N.J.: J. Wiley, 2002, ISBN [4] HOLLAND, J.H. a J. REITMAN Cognitive systems based on adaptive algorithms. WATERMAN, D. a F. HAYES-ROTH. Pattern-directed inference systems. London: Academic Press, 1978, s (b) 120

121 [5] LEE, M. a H. TAKAGI. Integrating design stages of fuzzy systems using genetic algorithms. In: 2nd International Conference on Fuzzy Systems (FUZZ-IEEE '93). San Francisco (USA), 1993, s [6] LIN, S.F., J.W. CHANG, Y.C. CHENG a Y.C. HSU. A novel self-constructing evolution algorithm for TSK-type fuzzy model design. In: Proc. of IEEE World Congress on Computational Intelligence (WCCI). Barcelona (Spain), 2010, Vol. CEC, s ISBN [7] NEGNEVITSKY, Michael. Artificial intelligence: a guide to intelligent systems. 2. vyd. Harlow (Veľká Británia): Pearson Education, ISBN [8] NOJIMA, Y., Y. KAISHO a H. ISHIBUCHI. Accuracy improvement of genetic fuzzy rule selection with candidate rule addition and membership tuning. In: Proc. of IEEE World Congress on Computational Intelligence (WCCI). Barcelona (Spain), 2010, Vol. FUZZ, s ISBN [9] SMITH, S. A learning system based on genetic adaptive algorithms. Pittsburgh (USA), Dizertačná práca. University of Pittsburgh. [10] ZADEH, Lotfi A. Fuzzy Logic, Neural networks, and soft computing. Communication of the ACM. 1994, Vol. 37, No. 3, s ISSN Dr. Ing. Ján Vaščák Technická univerzita v Košiciach, Fakulta elektrotechniky a informatiky Letná 9, Košice, Slovensko jan.vascak@tuke.sk 121

122 ÚLOHA EMÓCIÍ V INTELIGENTNÝCH SYSTÉMOCH THE ROLE OF EMOTIONS IN INTELLIGENT SYSTEMS Mária Virčíková a Peter Sinčák Abstrakt Ako sa roboty sťahujú z priemyslu do prostredí obývanými ľuďmi, nové trendy v robotike smerujú za kogníciu agentov a expandujú do oblasti spoločenských zážitkov s robotmi, ktorej súčasťou sú aj umelé emócie. Emocionálne technológie v dvoch formách, ako vyjadrovanie syntetických emócií, a rozpoznávanie emocionálnych stavov človeka strojom, prispievajú ku tvorbe personalizovaných systémov. Opierajúc sa o neurovedy, aj v robotickej komunite vzrastá potreba výpočtových modelov emócií pri návrhu inteligentných systémov. Príspevok sa snaží nadviazať na myšlienku M. Minskeho, ktorý uvádza, že otázkou nie je, či inteligentné stroje môžu mať emócie, ale či vôbec stroje môžu byť inteligentné bez akýchkoľvek emócií. Tento príspevok poskytuje prehľad dôvodov pre zahrnutie emócií do strojov a prehľad projektov, ktoré sa tým zaoberajú. Takisto sa snaží preukázať, že metódy výpočtovej inteligencie môžu byť vhodné nástroje pre systémy, ktoré zahŕňajú emócie. Klíčová slova Interakcia človek-stroj, personalizácia, spoločenská robotika, umelé emócie Abstract As robots are moving out from the industry to human-habitated environments, current trends in the field robotics are moving beyond cognition and expanding into the social experience which involves also artificial emotions. Emotional technology in its two forms as an expression of artificial emotions of the systems and as systems capable of recognizing human emotions contributes to the creation of personalised systems. Also, following neuroscience that says that emotions support human decision-making process, this paper continues in the statement of Minsky that says: the issue is not whether intelligent machines can have emotions, but whether machines can ever be intelligent without them. We try to move from the knowledge about human emotional processes to implement models of artificial emotions. This paper presents a survey of such emotional models and it tries to demonstrate that methods of computational intelligence can be appropriate tools for systems that involve emotions. Keywords Artificial emotions, human-robot interaction, personalization, social robotics 122

123 1. Úvod Americký spisovateľ Carnegie[6] výstižne poznamenal: Keď jednáte s ľuďmi, majte na pamäti, že nejednáte s bytosťami logiky, lež s bytosťami emócií. Ľudské emócie fungujú ako systém spätnej väzby poskytovaný telom a často im ľudia prisudzujú väčšiu váhu pri konaní ako racionálnym odôvodneniam, aj keď si to nie vždy uvedomujú. Tento článok sa snaží načrtnúť ich význam pre umelých agentov resp. stroje a poskytuje prehľad doposiaľ vyvinutých emocionálnych modelov s prvkami umelej inteligencie. Myslíme si, že umelé emócie by signifikantne prispeli k intuitívnejšej spolupráci ľudí so strojmi. Náš príspevok v druhej kapitole uvádza základné pojmy, následne v tretej kapitole vymenováva najvýraznejšie dôvody pre zahrnutie emócií do strojov, ktoré koexistujú s ľuďmi. Štvrtá kapitola načrtáva obrovské množstvo prístupov, ktoré sa snažia popísať emócie a piata kapitola pojednáva o technikách výpočtovej inteligencie ako o vhodných metódach na tento účel. Posledná, šiesta kapitola, uvádza príklady projektov, ktoré sa venovali emóciám pre umelých agentov. 2. Emocionálne stroje Pod emocionálnym strojom sa označuje softvér alebo hardvér ktorý je vybavený schopnosťou rozpoznávať alebo vyjadrovať emócie. Picard[32] tak dokonca hovorí strojom, ktoré majú emócie, avšak kvôli nejednoznačnosti tohto slovného spojenia a súčasného stavu aplikácií, ktoré zatiaľ majú ďaleko od vierohodného napodobnenia ľudskej emocionálnej inteligencie, to vyznieva ako súčasť slovníka sci-fi. Napriek tomu existuje spektrum projektov a aplikácií, ktorých cieľom je lepšie pochopiť človeka a ktorých správanie sa modeluje v závislosti na potrebách, očakávaniach a interakciách s ľudským používateľom, aby, stroje migrujúce do ľudskej spoločnosti, boli považované za prínosných a intuitívnych partnerov. Náhľad do budúcej kooperácie medzi strojmi a ľuďmi poskytuje obrazy počítačov, ktoré prispôsobujú svoje správanie človeku aby sa človek už viac nemusel prispôsobovať strojom. Na akademickej pôde v laboratóriách už asi dvadsať rokov vznikajú prvotné emocionálne stroje počítače, ktoré napríklad vycítia nervozitu ich ľudského spoločníka a následne aktívne poskytujú riešenia, ako jednoduchšie dokončiť danú úlohu, roboty, ktoré vediac, že človek je unavený, tak mu ponúknu šálku kávy, pretože tento zvyk od neho odpozorujú, alebo také, ktoré vyjadrovaním umelých pocitov zlepšujú náladu starším opusteným ľudom. Návrh takýchto modelov nie je založený len a jedine na výpočtových technológiách, ale je úzko prepojený s výsledkami výskumu mnohých disciplín, ktoré sa snažia pochopiť ľudské emocionálne procesy. Za poslednú dekádu nové poznatky z výskumu emócií z oblastí psychológie a neurovedy priťahujú pozornosť vedcov z kruhov okolo počítačovej vedy a umelej inteligencie (napr.[8], [31], [17]). Čoraz viac rastie skupina stúpencov, ktorí zastávajú názor, že emócie hrajú kľúčovú úlohu v ľudských kognitívnych procesoch a majú markantnú váhu pri riešení problémov a počas rozhodovacích procesoch. Umelá inteligencia, oblasť zaoberajúca sa modelovaním a simuláciou kognitívnych procesov, zaznamenáva záujem o emócie, dokonca podľa [15] sú emócie rozhodujúci element na 123

124 modelovanie vnímania, učenia, procesov rozhodovania, pamäte, správania a iných schopností. V oblasti počítačovej vedy sa vývoju emocionálnych strojov venujú dve, niekedy aplikačne sa prekrývajúce podoblasti: Interakcia človek-počítač (ang. Human- Computer Interaction ďalej HCI) a novšia oblasť Výpočtových modelov emócií, ktorá sa zaoberajú tvorbou biologicky inšpirovaných mechanizmov, ktoré simulujú aspekty ľudských emočných funkcií, ako napríklad ohodnotenie emocionálneho stimulu, aktiváciou určitých typov emócií alebo vytvorením emocionálnych reakcií. HCI je široká vedecká disciplína, ktorá sa orientuje na vzájomné interakcie medzi človekom a strojom, skúmajúc možnosti zlepšenia ich vzťahu. Jedným z cieľom HCI je práve vývoj inžinierskych nástrojov, ktoré by boli schopné merať, modelovať a reagovať na emócie, konštruujúc senzory, algoritmy a hardvérové prostriedky. 3. Dôvody pre implementáciu systémov emocionálnej inteligencie Na rozdiel od priemyselných robotov, ktoré sú stavané s cieľom plniť konkrétne úlohy v rôznych továrňach, spoločenská robotika sa zaoberá vývojom robotov, ktoré sú primárne určené na koexistenciu s ľuďmi v ich prirodzenom prostredí. Základná myšlienka, ako sme spomínali, je, aby interakcia medzi človekom a robotom bola čo najprirodzenejšia. Domnievame sa, že by to mal byť stroj, ktorý sa prispôsobí človeku. Preto základnou motiváciou na obohatenie robota o emócie je, aby sa človek v jeho prítomnosti, jednoducho povedané, dobre cítil. Komunikácia, ako referovanie vnútorného stavu agenta je najdôležitejšia schopnosť spoločenského robota. Okrem sprostredkovania informácie hlasom, je v ľudskej spoločnosti dôležitá aj neverbálna komunikácia. Humanoidné roboty môžu komunikovať vykazovaním umelých emócií, využívajúc tvár, pohyb, pózy a iné prvky, ktorými sú, závisiac na platforme, vybavené. Emócie na druhej strane ovplyvňujú rozhodovacie procesy u človeka. Neuroveda pokračuje v dokazovaní účinnosti emócií ovplyvniť kogníciu a správanie v ľudí najrôznejších situáciách[38]. Umelé emócie by mohli byť jedným z prostriedkov podporujúcich dynamické a flexibilné rozhodovanie aj u umelých agentov. V [20] prirovnávajú robotov bez emócií ku bytostiam, ktoré vykonávajú rozhodnutia bez vášne. Mnohé projekty sa snažia začleniť emócie ako podporu autonómneho správania, k čomu prispieva fakt, že emócie majú motivujúci efekt. Nielen Minsky[27], ale aj výsledky iných [10] [7] [12] [14] [18] [24] podporujú filozofické postoje označujúce kognitívne procesy nerozlučiteľné s emóciami a vyvracajú zmýšľanie chápajúce emócie a rozum ako opozitá. 4. Kategorizácia emocionálnych modelov Výskum v oblasti systémov s vnútornou architektúrou založenou na emóciách zaznamenal množstvo rozličných prístupov (napr. [24] [39] Chyba! Nenalezen zdroj odkazů.[1] [18] [12] [38]). Vo všeobecnosti sa tieto výskumy zameriavajú na výpočtové architektúry, ktorých modelom sú biologicky inšpirované emocionálnym procesom študovaným najmä neurovedou a spoločným zámerom je začleniť emócie do riadenia strojových procesov ([24] [39] [1] [18]) alebo evolúcia 124

125 umelej emócie [12] [38]. Hypotéza, ktorú očakávajú potvrdiť tvorcovia takýchto systémov je, že včlenenie emocionálneho modelu do výpočtového systému dokáže vylepšiť činnosť stroja (rozhodovanie, výber akcie, riadenie správania, Obr. 1: Niektoré teorie tvorby emócií: Zhore dole James-Langova, Canon-Bardova, Schachter-Singerova a Teória spínej väzby z tváre. Zdroj: vlastné spracovanie autonómnosť, atď.) Uvedené prístupy sa jeden od druhého líšia. Ak by sme hľadali jednotný koncept k modelovaniu emócií tvorbe akýchsi umelých, syntetických, simulovaných emócií, asi by sme stroskotali ihneď pri ozrejmení si základných termínov. S hľadaním jednotnej definície umelých emócií je to podobne ako s definíciou umelej inteligencie. Samotní psychológia sa doposiaľ nezhodli na jednotnom ucelenom vymedzení pojmu emócia u človeka. Literatúra často udáva množstvo definícií, často preukazujúc snahu o ich kategorizáciu, ako v [40]. Samozrejme, v niektorých aspektoch sa väčšina teórií zhoduje napríklad, že vo všeobecnosti je chápaná ako stav pocitov, ktorý zahŕňa myšlienky, fyziologické zmeny a následne vonkajšie prejavy vo forme výrazov a správania. Takmer všetci psychológovia sa zhodujú v tom, že existuje báza základných emócií, z ktorých vznikajú rôznorodé iné emócie, avšak nezhodujú sa v determinovaní množiny základných emócií. Prehľad niektorých je určený Tabuľkou 1, kde v poslednom stĺpci sú uvedené základné emócie určené daným psychológom. Predpokladá sa, že základné emócie sú inštiktívne a sú na evolučnej báze[40] a sekundárne, vytvorené z primárnych, sú naučené skúsenosťou. Takisto by sme mohli povedať, že emócie interpretujú pocity binárne do dvoch kategórií, na príjemné a nepríjemné. Nielenže existuje obrovské množstvo definícií, ale aj rôznych multidisciplinárnych pohľadov pojem emócia má svoje miesto nielen v spomínanej psychológii, ale napríklad aj v neurovedách, filozofii, kognitívnej informatike a v súčasnosti čoraz viac rezonuje v počítačovej vede. Vytvárajú sa mnohé nové formulácie teoretických, kognitívnych a výpočtových modelov. Existuje tiež niekoľko odlišných teórií o procese, akým sa dospeje do nejakého emocionálneho stavu 125