zde - Univerzita Hradec Králové

Transkript

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.
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 978-80-7435-216-4
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 2012.
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.
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Ě 1 – 4 .................................................
21
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Ů ………………….....................................................
46
Kamila Olševičová, Richard Cimler
AGENTOVÝ MODEL POPULAČNÍ DYNAMIKY
KELTSKÉHO SÍDLIŠTĚ ……………………………………………………………............................
51
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 …………………………………………………………………...
73
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
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
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/20.0001, který je
spolufinancován Evropským sociálním fondem a státním rozpočtem České republiky.
7
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 4.1.3. 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
interpretovat jako příkazy, které postupně vykonávají želvy v prostředí Logo, tzv.
„želví grafika“. My používáme prostředí 3D NetLogo 4.1.3.
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 Lsysté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
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
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.
Obr. 3: Grafický výstup primitivního modelu ekosystému
4. Závěr
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é Lsysté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, 2003.
Bc. Martin Bacovský
Univerzita Hradec Králové, Fakulta informatiky a managementu
Rokitanského 62, 500 03 Hradec Králové, Česká republika
e-mail: [email protected]
11
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
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
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).
Problémová oblast (doména)
Přípravná fáze
Letectví (kategorizace letadel podle
způsobu vzniku vztlaku)
Anglický jazyk (bez diakritiky)
OWL (1.0)
Protégé (verze 3.3.1, 4.0.2, 4.1)
Jazyk tvorby ontologie
Jazyk pro vývoj ontologie
Editor (nástroj) pro tvorbu
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
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.
Třída
Letadlo
Atmosféra
Civilní letadlo
PPL
Komponenty OWL ontologie
Vlastnost
Jedinec
Kluzák
Má rychlost
Grunau Baby
Podvozek Pohybuje se v
TL-3000 Sirius
prostředí
Dolet
Má motor
VSM-40 Démant
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
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, 4.0.2 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
Cíl
Výběr nejlepší
verze
Kritérium
Modelování
ontologie
Instalace
nástroje
Ohodnocení
Slovní škála
Numerická škála
Very Important
75
Kritérium
Modelování
ontologie
Instalace nástroje Critical
Práce s ontologií
Very Important
Tab. 3: Hodnocení kritérií
Subkritérium
Práce se záložkou
třídy
vlastnosti
metadata
Kompatibilita s OS
100
75
Ohodnocení
Slovní škála
Numerická škála
Critical
100
Critical
100
Important
50
Very Important
75
Jednoduchost
Critical
instalace
Práce s ontologií Export do obrázku Very Important
Testování úplnosti Important
Kontrola
Critical
konzistence
Podpora
Critical
vizualizace
Přednastavené
Very Important
klasifikátory
Debugger
Important
Podpora v
Critical
odvozování
Generování OWL
Important
dokumentace
Tab. 4: Hodnocení subkritérií
100
75
50
100
100
75
50
100
50
Subkritérium
Alternativy
A (verze 3.3.1) B (verze 4.0.2)
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
75
75
75
50
25
100
100
100
100
100
100
100
75
75
17
C (verze
4.1)
100
100
50
100
100
75
75
Kontrola konzistence
100
75
Podpora vizualizace
50
100
Přednastavené klasifikátory
0
75
Debugger
100
50
Podpora v odvozování
50
100
Generování dokumentace
100
75
Tab. 5: Hodnocení alternativ
75
100
100
75
100
75
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é 4.0.2. Rozdíl v preferenci verze Protégé 4.0.2 oproti
verzi Protégé 4.1 je však minimální. Verze Protégé 3.3.1 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
Verze Protégé 4.0.2 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é 3.3.1 (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é 3.3.1 s operačním systémem
Windows 7, na rozdíl od verzí Protégé 4.0.2 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é 4.0.2
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é 3.3.1 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é
3.3.1 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é
4.0.2 pro výuku předmětu ZT1.
19
Literatura
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
Lukasová, A., et al. Formální reprezentace znalostí. 2010. Ostrava: Repronis
s.r.o., 2010. 343 s. ISBN 978-80-7368-900-1.
Svátek, Vojtěch. Ontologie a WWW [online]. 15. 9. 2003. Databázová
konference DATAKON 2002, Brno. Dostupné z WWW:
<http://nb.vse.cz/~svatek/onto-www.pdf.>
Svátek, Vojtěch; Labský, Martin. Objektové modely a znalostní ontologie –
podobnosti a rozdíly [online]. 11. 10. 2003. Dostupné z WWW:
<http://nb.vse.cz/~svatek/obj03fi.pdf>.
Allemang, Dean; Hendler , Jim. Semantic web for the working ontologist :
Effective Modeling in RDFS and OWL. 1. Amsterdam: Morgan Kaufmann, 2008.
330 s. ISBN 978-0-12-373556-0.
Hitzler, Pascal; Krotzsch, Markus; Rudolph, Sebastian. Foundations of
Semantic Web Technologies. United States of America : Chapman &Hall/CRC,
2010. 427 s. ISBN 978-1-4200-9050-5
Smith, Michael K.; Welty, Chris; McGuiness, Deborah L., editors. OWL Web
Ontology Language Guide [online]. 10. 2. 2004. Dostupné z www:
<http://www.w3.org/TR/owl-guide/>.
Auxilio, María; Nieto, Medina. An Overview of Ontologies [online]. 1.3. Mexiko:
2003, March 2000. Technical report. Dostupné z WWW:
<http://www.starlab.vub.ac.be/teaching/ontologies_overview.pdf>.
Horridge; Matthew, Musen; Mark, et al. Protégé FAQ [online]. 2012. Dostupné
z WWW: <http://protege.stanford.edu/doc/faq.html#01.01>.
Horridge; Matthew, Musen; Mark, et al. What is Protégé? [online]. 2012.
Dostupné z WWW: <http://protege.stanford.edu/overview/>.
Hepp, Martin, et al. Ontology Management: Semantic Web, Semantic Web
Services and Business Applications. 7. New York: Springer, 2008. 293 s. ISBN
978-0-387-6990-4.
Ing. Kristýna Báčová
Univerzita Hradec Králové, Fakulta Informatiky a managementu
Ing. Martina Husáková
Univerzita Hradec Králové, Fakulta Informatiky a managementu
20
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, Email, 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,
Email, 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
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
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 e-mailový 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íť 192.168.10.0 /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
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ě 192.168.11.0 /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 –
192.168.11.254.
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 – 192.168.100.123, 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
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í (email, 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.
5.1. 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
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.
5.2. 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
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:
Obr. 6: Model logiky
6. Komunikační rozhraní
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.
6.1. Ú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.
6.2. 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
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.
6.3. 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.
6.4. 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ů.
6.5. 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
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
2000. Vyd. 1. Brno: Computer Press, 2008, 656 s. ISBN 978-80-251-1961-7.
[2]
EMPSON, Scott. CCNA kompletní přehled příkazů: autorizovaný výukový
průvodce. Vyd. 1. Brno: Computer Press, 2009, 336 s.
ISBN 978-80-251-2286-0.
[3]
GOOGLE INC. Android Developers [online]. 2005 [cit. 2012-06-01]. Dostupné
z: <http://developer.android.com>.
Ing. Martin Hátaš
Ing. Jan Matyska
29
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í 1 500 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
článku Experimental test of airplane boarding methods publikovaném v časopise
Journal of Air Transport Management [Steffen, Hotchkiss, 2011].
1.1.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.
1.2.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
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í.
1.3.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 č. 1.
32
Úspěšnost navržených metod
270
počet kroků
250
230
210
190
170
150
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 č. 2.
Vliv pozdě příchozích
počet kroků
300
250
0
200
0,1
0,2
150
Steffen
Wilma
Random Back front
Blocks
metoda
Graf 2: Vliv pozdě příchozích
33
Kautzka 3
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]
[2]
KAUTZKÁ, Eva. Agentové simulace hromadné obsluhy. Hradec Králové, 2012.
Diplomová práce. Univerzita Hradec Králové.
NYQUIST, David C. a Kathleen L. MCFADDEN. A study of the airline boarding
problem. Journal of Air Transport Management. 2008, roč. 14, č. 4, s. 197-204.
ISSN 09696997. DOI: 10.1016/j.jairtraman.2008.04.004. Dostupné z:
http://linkinghub.elsevier.com/retrieve/pii/S0969699708000513.
[3]
STEFFEN, Jason H. Optimal boarding method for airline passengers. Journal of
Air Transport Management. 2008, roč. 14, č. 3, s. 146-150. ISSN 09696997.
DOI: 10.1016/j.jairtraman.2008.03.003. 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. 64-67.
ISSN 09696997. DOI: 10.1016/j.jairtraman.2011.10.003. Dostupné z:
Ing. Eva Kautzká
34
Ing. Richard Cimler
35
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
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.
2.1. 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
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é.
2.2. 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 802.11a)
WiFi
(IEEE 802.11b)
WiFi
(IEEE 802.11g
WiFi
(IEEE 802.11n)
WMAN
WiMAX
(IEEE
802.16d)
Rok
uvedení
Přenosová
frekvence
Max. teoretická Max.
teoretická
rychlost
vzdálenost
přenosu dat
vysílače/přijímače
2004
2.4 GHz
3 Mbps
10 m
2009
2.4 GHz
24 Mbps
10 m
1999
5 GHz
54 Mbps
100 m
1999
2.4 GHz
11 Mbps
110 m
2003
5 GHz
54 Mbps
110 m
2009
2.4/5 GHz
150 Mbps
160 m
2004
2-11 GHz
75 Mbps
8 km
38
WWAN
GPRS
/síť GSM/
EDGE
/síť GSM/
CDMA 1xEVDO
/síť
CDMA2000/
UMTS
/síť UMTS/
HSDPA
/síť UMTS/
HSUPA
/síť UMTS/
1997
2004
2004
2000
2004
2005
900/1800
MHz
900/1800
MHz
450-2100
MHz
86 kbps
35 km
237 kbps
30 km
2.4 Mbps
54 km
1920-2170
MHz
873/1900
MHz
873/1900
MHz
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á.
2.4. 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
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
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
BTS
Průměr.
přesnost
[metry]
250 –
5000
GPS
5 – 20
aGPS
10 – 50
Výhody
Nevýhody
Funkčnost při NLOS.
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.
Velmi přesná lokace.
Výborné pokrytí území a
dostupnost.
Nezatěžuje síťový přenos.
Poměrně přesná lokace.
Výborné pokrytí (v ČR 95-99%)
území a dostupnost.
Málo přesná lokace.
Nutnost LOS.
Delší doba
inicializace.
Zatěžuje síťový
přenos (GPRS).
Nízká spotřeba energie baterie
(při GSM).
IPS
1 – 10
(Bluetooth, (dle počtu
WiFi, atd.) access
Velmi přesná lokace.
pointů)
Nutná dodatečná
bezdr. infrastruktura.
Zatěžuje síťový
přenos.
Tab. 2: V současnosti používané metody lokace.
Zdroj: [7], autor
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

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í.
3.1. 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
Webové
Mobilní
technologie prohlížeč
na straně
klienta
Internet
Explorer
Mobile
Opera
Mobile
Firefox for
mobile
Google
Android
(ver.12)
(ver.10)
(ver.2)
Geolocation API
Ano
Ano
Ano
Ano
Battery Status API
Ne
Ne
Ano
Ne
Screen Orientation API
Ne
Ne
Ano
Ne
(ver.9)
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
12 530
21 099
35 446
Velká Británie
3 070
5 700
10 602
Německo
2 159
3 870
6 927
Španělsko
1 830
3 132
5 356
Itálie
3 198
4 879
7 465
Tab. 5: Využívání mobilních map v zemích EU
Zdroj: [8], úprava: autor
43
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, 2008.
ISBN 978-80-87147-07-8.
[2]
KYSELA, J. Lokálně kontextové služby v praxi [online]. 2011 [cit. 2012-06-08].
Dostupné z: <http://www.internetprovsechny.cz/lokalne-kontextovesluzby-v-praxi/>.
[3]
KYSELA, J. Bezdrátový Internet a technologie Wi-Fi v České republice [online].
2010 [cit. 2012-06-08]. Dostupné z: <
http://www.internetprovsechny.cz/bezdratovy-internet-a-technologie-wi-fiv-ceske-republice/>.
[4]
PILGRIN, M. Dive into HTML5. [online]. 2010 [cit. 2012-06-10]. Dostupné z: <
http://diveintohtml5.info/index.html>.
[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ě: 2012.
PULICAR, M. Hvězdná kartografie: Možnosti geoinformatiky. Bakalářská práce
(vedoucí BP doc. RNDr. Milan Konečný, CSc.). Brno, Masarykova univerzita:
2009.
[6]
[7]
MEIJERS, S., BOONSTRA, B., KNIPPENBERGH, G. Location Based Services on
Mobile Internet [online]. 2008 [cit. 2012-06-11]. Dostupný z:
<http://www.omi2.nl/wp-content/uploads/2008/11/final-lbs-whitepaperfinal-nov-2008.pdf>.
[8]
LANE, N., Mobile geo-location advertising will be a big number in 2015
[online]. 2008 [cit. 2012-06-12]. Dostupný z: <http://adfonic.com/wpcontent/uploads/2012/03/geo-location-white-paper.pdf>.
[9]
DJUKNIC, G., RICHTON, R. Geolocation and Assisted GPS [online]. 2001 [cit.
2012-06-12]. Dostupný z:
<http://www.cs.columbia.edu/~drexel/CandExam/Geolocation_assistedGPS.pdf>.
44
[10] BTS, Inc. Mobile Terminal Location Detection Services [online]. 2008 [cit.
2012-06-12]. Dostupný z: < http://www.btstraining.com/CoursePDFs/260.pdf >.
[11] STEINIGER, S., NEUN, M. Foundations of Location Based Services [online].
2006 [cit. 2012-06-12]. Dostupný z:
<http://www.spatial.cs.umn.edu/Courses/Spring10/8715/papers/IM7_stein
iger.pdf>.
[12] WANG, Y., BURGENER, D., FLORES, M. KUZMANOVIC, A., HUANG, CH. Towards
Street-Level Client-Indenpendent IP Geolocation [online]. 2011 [cit. 2012-0614]. Dostupný z:
<http://static.usenix.org/event/nsdi11/tech/full_papers/Wang_Yong.pdf>.
[13] REESE, W., BECKLAND, J. Lost in Geolocation [online]. 2011 [cit. 2012-06-14].
Dostupný z:
<http://www.whitehorse.com/uploadedFiles/World/Reports/Lost%20in%
20Geolocation%20Report(1).pdf>.
[14] W3C. Geolocation API Specification [online]. 2012 [cit. 2012-06-15]. Dostupný
z: <http://www.w3.org/TR/geolocation-API/>.
[15] W3C. Battery status API [online]. 2012 [cit. 2012-06-15]. Dostupný z:
<http://www.w3.org/TR/battery-status/>.
[16] W3C. The Screen Orientation API [online]. 2012 [cit. 2012-06-15]. Dostupný z:
<http://www.w3.org/TR/screen-orientation/>.
ing. Jiří Kysela
45
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
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
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
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
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, c1997. 273 s. ISBN 0-9650819-0-7.
[2]
LOSKOT, Jan. Systém pro podporu výuky programování mikrokontrolérů.
Hradec Králové, 2012. 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. 340. ISSN 1211-3557.
[4]
PETTY, Geoffrey: Moderní vyučování. Přel. Š. Kovářík. 1. vyd. Praha: Portál,
2004. 380 s. Přel. z: Teaching Today. ISBN 80-7178-978-X.
PIC-DEM 2 PLUS [online]. GM Electronic. [cit. 2011-06-04]. Dostupné
z WWW: http://www.gme.cz/dokumentace/752/752-662/czn.752662.1.pdf
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. 2011-11-22]. Dostupné z doi:
10.1145/1930277.1930285.
[5]
[6]
Jan Loskot
50
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
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
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 5000. 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 10-14 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

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ř. 1360 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í (100-120 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]
54
; sucklings
; todlers
; children
; older-children
; 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
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
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
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, 2008. s.821-835.
[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, 2002. S.7275-7279.
[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, 2005. s183-198.
[4]
[5]
[6]
[7]
DANIELISOVÁ, A. The oppidum of České Lhotice and its hinterland. Doktorská
dizertační práce, nepublikováno, 2008.
GRIFFITH, C.S. et al. HOMINIDS: An agent-based spatial simulation model to
evaluate behavioral patterns of early Pleistocene hominids. In Ecological
Modelling, 221, 2010. S.738-760.
GRIMM V. et. al. The ODD protocol: A review and first update. In Ecological
Modelling, 221, 2010. .2760-2768.
JANSSEN, M. Understanding Artificial Anasazi. In Journal of Artificial Societies
and Social Simulation, 12, 2009. (4) 13.
[8]
DE ROOS, A.M. Modeling Population Dynamics. Studijní materiál,
http://staff.science.uva.nl/~aroos/downloads/pdf_readers/syllabus.pdf.
Universiteit van Amsterdam, 2011.
[9]
SALLER, R. Patriarchy, Property and Death in the Roman Family. Cambridge,
1994.
doc. RNDr. Kamila Olševičová, Ph.D.
Ing. Richard Cimler
58
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
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
.
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(n2).
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(n2).
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
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. 2006. The Traveling
Salesman Problem – A Computational Study. Princeton University Press.
[2]
BURKARD, R., E., KLINZ, B., RUDOLF, R. 1996. Perspectives of monge
properties in optimization. In DiSC.APL.MATH, 70, pages 95-161.
[3]
BURKARD, R., SANDHOLZER, W. 1991. Efficiently solvable special casem of
bottleneck traveling salesman problems. In DiSC.APL.MATH, 32, pages 61-76.
CUNINGHAM-GREEN, R, A. 1979. , Minimax algebra, Lecture notes in
Economics and Mathemtaics systems, 166, Springer-Verlag, Berlin.
LAWLER, E. L., LENSTRA, J. K., RINNOY KAN, K. H. G., SHMOYS, D. B. 1985. The
Traveling Salesman Problem. John Wiley and Sons Ltd., England.
[4]
[5]
[6]
PARK, J., K. 1991. A special case of the n-vertex travelling salesman problem
that can be sloved in O(n) time. In INFORM.PROCESS.LETT, 40,
pages 247-254.
Mgr. Alena Pozdílková
62
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
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
„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
Spuštěný
aktivovaný zdroj
znalostí
Tabule
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
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
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




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
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
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
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 emailové 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, 2003.
[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, 1999.
[5] MAŘÍK, V., ŠTĚPÁNKOVÁ, O., LAŽANSKÝ, J. a kol. Umělá inteligence II. Kapitola
4, Academia Praha, 1997, ISBN 80-200-0504-8.
[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 80-200-0472-6.
[7] VLASSIS, N. A. Concise Introduction to Multiagent Systems and Distributed
Artificial Intelligence, Morgan & Claypool, 2007.
Ing. Jan Procházka
72
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
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
132 50) 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.
3.1. 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 2.3.3

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 frameworkHibernate3.6.3
74
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: http://<insert_server>/opensocial/ui/objectives/ajaxlist/ 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
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 Adaptéru
@Override
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
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.
3.4. Metody přístupné na serveru
Přidání nového TOPIC
Typ metody POST
URL:http://localhost:8080/opensocial/ui/topics/post?name=jmeno&topicType=O
BJECTIVE&description=popis&author=46&public=1
http://localhost:8080/opensocial/ui/topics/post?name=jmeno&topicType=WOR
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:http://localhost:8080/opensocial/ui/objectives/get/json/174
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:http://localhost:8080/opensocial/ui/documents/get/json/189
Paramentry:
77
id - id existující documentu
Odpověď budou všechny informace o daném dokumentu
Vrať všechny dokumenty (List JSON)
Typ metody POST
URL: http://localhost:8080/opensocial/ui/documentss/ajaxlist
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: http://localhost:8080/opensocial/ui/objectives/ajaxlist
Paramentry: page, size (ani jeden parametr není povinný, )
Detailní informace TOPICu
URL:
http://localhost:8080/opensocial/ui/map/get/details/{idTopic}?level={idLevel}
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:
http://localhost:8080/opensocial/ui/topics/notes/?id={id_topic}&note={text_kom
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: http://localhost:8080/opensocial/ui/topics/notes/?id={id_topic}
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: http://localhost:8080/opensocial/ui/topics/notes/new/?id={id_komentare}
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: http://localhost:8080/opensocial/ui/topics/notes/old/?id={id_komentare}
Paramentry: id (id komentáře, povinný)
Možnost hlasování LÍBÍ / NELÍBÍ
Typ metody POST
URL: http://localhost:8080/opensocial/ui/topics/vote?id=1&vote=2
Parametry: id (id topicu, povinný), vote (možnost hlasování, povinný,
- 2=POSITIVE
- 1=DEFAULT
78
- 0=NEGATIVE
Response example: (výsledek všech hlasů k topicu)
3.5. Případy použití (Use Case Model)
Obr. 2: Use Case model
4. Závěr
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
79
Bc. Lukáš Rejha
80
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 2007. 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 2007. 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
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 1956-1980 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 2001. 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 2010. Jeho postupné zdokonaľovanie prinesie
82
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 eboardy 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. 0.99 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
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
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 1954.
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 (www.doublerobotics.com)
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
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
ú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
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.
4.1. 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
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.
Obr. 5: Základná hardwarová štruktura robota NAO
4.2. Programovanie 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

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
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
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
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 978-80-227-2643-6, Gratex 2007, pp. 329-339.
93
[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 2001.
[3]
S. Legg, M. Hutter : Universal Intelligence: A Definition of Machine Intelligence,
2007, http://www.vetta.org/documents/UniversalIntelligence.pdf.
[4]
Sinčák P., Vaščák J. (Eds) Quo Vadis Computational Intelligence, pp. 498, ISBN 37908 13249 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 1615-3871, 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 0922-6389.
[7]
Sinčák P. Vaščák J., Hirota K.(eds): Machine Intelligence: Quo Vadis, February
2004,WorldScientific Publishing House, ISBN 981-238-751-X, pp. 450.
[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.1275-1296 (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,
2009. 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
[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. 1202 - 1213.
[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. 3315 – 3320.
[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. 149-186.
[20] Riid, E. Rustern: Interpretability of Fuzzy Systems and Its Application to Process
Control, IEEE International Fuzzy Systems Conference (FUZZ-IEEE), 2007, pp. 1 6.
[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. 467-479, ISSN 1789-6932.
[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. 755 - 774.
[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. 75 - 80.
[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 2001.
[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, 040 01 Košice, Slovenská republika
95
Ing. Martin Paľa
Letna 9, 040 01 Košice, Slovenská republika
Ing. Mária Virčíková
96
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
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
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
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
Obr. 2: Zjednodušený diagram tříd
6. Návrh uživatelského rozhraní
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
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
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/.
Obr. 9, 10, 11: Implementace uživatelského rozhraní dle návrhu
9. Práce na pozadí
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
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
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
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
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]
[2]
[3]
GOOGLE INC. Android developers [online]. 2012 [cit. 2012-05-29]. Dostupné
z: <http://developer.android.com/index.html>.
MURPHY, Mark L. Android 2: Průvodce programováním mobilních aplikací.
Praha: COMPUTER PRESS, 2011.
MEIER, Reto. Professional Android application development: Průvodce
programováním mobilních aplikací. Indianapolis, IN: Wiley, 2009.
ISBN 978-047-0344-712.
Ing. Vladimír Skoupý
107
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
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
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
probability of buying based on fundamentals.
( )
( )
is
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
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]. 1965 [cit. 2011-06-05]. The
Behavior of Stock-Market Prices. Dostupné z WWW:
<http://stevereads.com/papers_to_read/the_behavior_of_stock_market_price
s.pdf>.
[2] GALIMBERTI, Jaqueson. NetLogo [online]. 2010 [cit. 2011-06-05]. NetLogo
User Community Models CASM Robot. Dostupné z WWW:
<http://ccl.northwestern.edu/netlogo/models/community/CASM_Robot>.
[3] SUHADOLNIK, Nicolas; GALIMBERTI, Jaqueson; DA SILVA, Sergio. Munich
Personal RePEc Archive [online]. 2010 [cit. 2011-06-05]. Robot traders can
prevent extreme events in complex stock markets . Dostupné z WWW:
http://mpra.ub.unimuenchen.de/23923/1/RobotTradersCanPreventExtremeEventsInComplexS
tockMarkets.pdf.
Ing. Jiří Štěpánek
111
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
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
Ú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
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 (http://sci2s.ugr.es/keel/), ktorá sa
zaoberá extrakciou znalostí pomocou EA a zároveň poskytuje svoj vlastný softvér,
115
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.
3.1. 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 1
i 1
p  k . X i  l. X i ,
(4)
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 ( j  1,
,  X i ). Vzťah
X
116
i
vyjadruje počet všetkých možných
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 i .
Tento nedostatok rieši napr. metóda popísaná v [6], kde využíva zhlukovanie.
3.2. 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.
117
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)
(b)
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.
Ď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
vzoriek x do tried C s indexom h, tak za týmto účelom sa definujú miery istoty mi
a pokrytia mp [8]:
mi 

xCh
M

p 1
mp 
k
(5)
,
k

xCh
( x)
( x)
k
Mh
( x)
(6)
,
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
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)
(b)
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 RuleBased Systems. In: Proc. of IEEE World Congress on Computational Intelligence
(WCCI). Barcelona (Spain), 2010, Vol. FUZZ, s. 1373-1380.
ISBN 978-1-4244-6920-8.
[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. 1-12.
ISBN 0-78-031104-3.
[3]
[4]
ENGELBRECHT, Andries P. Computational intelligence: an introduction.
Hoboken, N.J.: J. Wiley, 2002, ISBN 04-708-4870-7.
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. 313-329.
120
[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. 613-617.
[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. 570-576. ISBN 978-1-4244-6910-9.
NEGNEVITSKY, Michael. Artificial intelligence: a guide to intelligent systems. 2.
vyd. Harlow (Veľká Británia): Pearson Education, 2005. ISBN 03-212-0466-2.
[7]
[8]
[9]
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. 527-534. ISBN 978-1-4244-6920-8.
SMITH, S. A learning system based on genetic adaptive algorithms. Pittsburgh
(USA), 1980. 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. 77-84. ISSN 0001-0782.
Dr. Ing. Ján Vaščák
Technická univerzita v Košiciach, Fakulta elektrotechniky a informatiky
Letná 9, 042 00 Košice, Slovensko
121
Ú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
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
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. HumanComputer 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
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
(Obr. 1). Napríklad, James-Langova teória emócií hovorí, že akcia (nejaká udalosť)
vyvolá fyziologické vzrušenie, ktoré sa interpretuje. Až po akomsi výklade tohto
vzruchu je bytosť schopná prežiť emóciu. Cannon-Bradova teória tvrdí, že
fyziologické vzrušenie a emócia sú prítomné zároveň. Táto teória nepopisuje úlohu
myšlienok ako Schachter-Singerova teória. Podľa nej udalosť spôsobí vzrušenie,
pre ktoré musí existovať nejaký dôvod (myšlienka). Existuje aj tzv. teória spätnej
väzby týkajúca sa tváre (ang. Facial-feedback theory), popisujúca zmeny tvárových
svalov (napr. úsmev odzrkadľuje prežívajúcu radosť). Napríklad Ekman sa
zaoberal korešpondovaním emócií s expresiou tváre – cestovaním po svete určil
základné emócie (pozri Tabuľka 1, riadok 2), ktorých hlavná devíza spočíva v tom,
že ich vyjadrenie tvárou nie je podmienené kultúrou, čiže univerzálne pre všetky
miesta na svete, náboženstvá, jazyk, pohlavie, atď.
Z pohľadu psychológie sú emocionálne procesy a stavy také zložité a zároveň môžu
byť analyzované z toľkých uhlov, že zostavenie kompletného obrazu je virtuálne
nemožné. Avšak je otázne do akej hĺbky je potrebné poznať tieto komplexné
procesy u človeka na tvorbu systémov umelej inteligencie, ako simulovanie
inteligentného riešenia problémov strojom. Minsky[27] poznamenal, že emócie
z pohľadu umelej inteligencie nie sú ničím zvláštne, že každý emocionálny stav je
len iný štýl myslenia – pričom emócie ako také majú odlišný spôsob organizácie
pre riadenie myslenia.
Ak sa aj nedajú emócie jednoznačne kategorizovať, často sa prirovnávajú k palete
farieb. Z troch základných farieb – červenej, zelenej a modrej – je možné generovať
mnoho rôznych odtieňov – intenzít rozličných emocionálnych stavov. Plutchik
vychádzal práve z teórie farieb pri navrhovaní jeho psychoevolučnej teórie. Názov
je odvodený z toho, že jeho primárne emócie vyvolávajú odlišné správanie
v kontexte prežitia. Ako je možné vyvodiť z Tabuľky 2., napríklad strach je emócia,
ktorá vyvolá u živých organizmov zvracanie a takto zabráni otrave. Z uvedených
základných emócií, ktoré by sme mohli prirovnať ku maliarovej palete - sa
miešaním – ako zo základných farieb sa dá namiešať celé farebné spektrum – sa
získajú rozličné emócie.
Stimulujúca
udalosť
hrozba
prekážka
získanie cenného
objektu
strata cenného
objektu
Kognícia
Pocitový
stav
Vykázané
správanie
nebezpečenstvo
nepriateľstvo
vlastnenie
strach
hnev
radosť
opustenie
smútok
útek
napadnutie
udržanie/opak
ovanie
plač
člen niekoho
priateľstvo
skupiny
neznesiteľný objekt otrava
nové teritórium
preskúmanie
akceptácia
znechutenie
očakávanie
staranie sa o
druhého
vracanie
mapovanie
neočakávaná
udalosť
prekvapenie
zastavenie
zvedavosť
126
Dôsledok
bezpečie
zničenie prekážky
získanie zdrojov
opakované
získanie
strateného
objektu
vzájomná
podpora
vypudenie otravy
získanie znalosti
o teritóriu
získanie času na
zorientovanie sa
Tab. 1: Od stimulu po dôsledok v správaní podľa Plutchika
Jedno z najvýraznejších obmedzení prístupov k modelovaniu emócií je
pravdepodobne neschopnosť adaptácie. Väčšina doposiaľ vytvorených
výpočtových modelov emócií bola navrhnutá tak, že odpovedá preddeterminovaným spôsobom na konkrétne situácie. Psychológia poukazuje na
dôležitosť pamäte a skúsenosti v emočnom procese. Práve metódy umelej
inteligencie by mohli predstavovať vhodné nástroje na modelovanie adaptívneho
emocionálneho správania.
5. Výpočtová inteligencia v modelovaní emócií
Táto kapitola sa bude snažiť preukázať vhodnosť použitia výpočtovej inteligencie
na vysporiadanie sa s otázkami, ktoré sa vyskytujú pri návrhu vnútorného modelu
emócií u umelých systémov.
Neurónové siete sú známe schopnosťou učenia, ktorá sa uplatňuje napríklad
o učení rozlučných aspektov o/z prostredia – asociácie objektov, sekvencií udalostí
alebo očakávaní užívateľov. To môže systému napomôcť dynamicky sa
prispôsobovať, čo zvyšuje jeho hodnovernosť a zlepšuje interakciu s človekom.
Emócie nanajvýš sa nanajvýš spájajú s charakteristickými vzormi správania
a s neurálnymi procesmi príznačnými pre špecifické regióny mozgu, preto ako
vyznal Levin [25], zodpovedajú modelovaniu neurónovými sieťami ako
ktorémukoľvek psychologickému procesu, ktorý bol nimi simulovaný. Obzvlášť
prínosné sú na pochopenie zložitých interakcií emócií a kognitívnych procesov,
ako je pozornosť, rozhodovanie a pamäť.
Fuzzy logika sa vyznačuje schopnosťou zachytiť neurčitosť a zložitý charakter
emócií. Bez hlbšieho uvažovania je zrejmé, že emócie sú vágne, je nemožné
zhotoviť vierohodný emocionálny model, kde by jednotlivé emocionálne stavy mali
priradené diskrétne hodnoty bez nejakého „spojitého prechodu“ medzi nimi –
človek môže byť smutný do nejakej miery, čiže má príslušný stupeň príslušnosti
smútku. Príklady využitia výhod fuzzy systémov na zhotovanie emocionálneho
modelu by mohli byť vypočítanie očakávanej reakcie ku terajšiemu vstupnému
stavu, alebo vypočítať pravdepodobnosť deviácie zo súčasného emocionálneho
stavu smerom ku nasledujúcemu emocionálnemu stavu.
Nasr[28] uviedol tri koncepty: Fuzzy ciele ako stupeň úspechu a neúspechu
vzhľadom na dosiahnutie cieľu, fuzzy príslušnosť udalosti k cieľu, vychádzajúc
z toho, že udalosť môže ovplyniť dva alebo viac cieľov s rôznymi stupňami a,
týkajúc sa emocionálneho modelovania, fuzzy mapovanie. Zmes emócií je
mapovaná na správanie použitím techniky fuzzy mapovania. V [28] fuzzy logika
preukázala, že dokáže dosiahnuť hladké prechody správanie s relatívne malou
množinou pravidiel, príklad je nasledovný:
AK emócia_1 je A1 A emócia_2 je A2 .... A emćoia_k je Ak
A udalosť je U A dôvod je (U, D)
POTOM SPRÁVANIE je S
127
Evolučné algoritmy sa tiež zdajú byť zaujímavou technikou na zostrojovanie
vierohodných emocionálnych modelov. Samotný Darwin a potom Plutchik
predpokladali, že ľudské emócie majú evolučný charakter. Umelý chromozóm
predstavuje v [23] hlavný komponent na definovanie osobnosti, ktorej prvky sa
dedia.
6. Projekty založené na emóciách
Prierezom histórie umelej inteligencie by sa dalo nájsť množstvo modelov
pokúšajúcich sa popísať ľudskú myseľ. Niektoré z nich si kládli za cieľ priblížiť sa
emocionálnym procesom. Pravdepodobne prvotný známy pokus o emócie v umelej
inteligencii sa považuje Simon, ktorý už okolo roku 1967 zostrojil model založený
na motivačných stavoch, ako hlad a smäd. Simulácia procesu vyzerala takto: ak
úroveň hladu dosiahla nejaký limit, proces rozmýšľania sa prerušil. Projekty, kde
emócie mali význam pre podporu rozhodovacích procesov alebo pre komunikácia
s robotom, sa dostali najviac do povedomia v 90.-tych rokoch (Sugano a Ogata
1996, Shibata et al. 1996, Breazeal, Brooks). Avšak podľa [15] nemôžeme tvrdiť, že
nejaký výskumný projekt doposiaľ zaznamenal prominentný úspech, alebo sa
priveľmi odlišoval od ostatných. Nejednoznačnosť dostupných informácií
o emocionálnom fenoméne a vzťah s ostatnými sub-systémami na vykázanie kvalít
je nedostatočný, avšak nadšenci z kruhov umelej inteligencie ako 40, argumentujú,
že vývoj výpočtových modelov emócií by mal tvoriť jadro záujmu umelej
inteligencie.
Nasledujúce riadky obsahujú niektoré systémy, ktoré majú v nejakej forme
zakomponovaný emocionálny model. Rozdeľujeme ich na formálny prístup
a modely agentov, ktoré sa delia na virtuálne a fyzické (robotické systémy).
Kismet simuloval sociálne interakcie medzi ľuďmi. Na základe tejto myšlienky mal
robot svojho ľudského učiteľa-asistenta, ktorý mu pomáhal získať lepšie
komunikačné schopnosti. Tento prístup učenia je inšpirovaný spôsobom akým sa
učia komunikovať dojčatá s dospelými. Emócie sú modelované z hľadiska ich
funkčnej perspektívy (7 základných emócií – zlosť, znechutenie, radosť, smútok,
pokoj a prekvapenie). Na základe jednoduchého odhadu možného úžitku
vyvolaného určitým stimulom, je aktivovaná kladná emotívna reakcia a robot sa
snaží dostať čo najbližšie k zdroju tohto stimulu, alebo je aktivovaná negatívna
emotívna reakcia a robot sa snaží "utiecť" pred týmto stimulom.
MADB Chyba! Nenalezen zdroj odkazů. model predstavuje formálne vysvetlenie
mechanizmu a vzťahov medzi motiváciou, prístupom a správaním. Snaží sa
o popísanie konceptu, akým spôsobom proces motivácie ovplyvňuje ľudské
správanie a jeho akcie a ako prístup a rozhodovanie napomáha regulovať
motiváciu.
128
Výstup projektu ALMA [26] by sme mohli zhrnúť do troch základných poznatkov
o implementácii emócií:

Emócie reflektujú krátkodobý vplyv. Zvyčajne sa rozpadajú a miznú, na základe
toho, na čo sa jednotlivec zameriava.

Nálady odrážajú vplyv, ktorý má trvanie strednej dĺžky – majú dlhšiu životnosť
a stabilné afektívne stavy, ktoré majú veľký vplyv na kognitívne funkcie
človeka.
Nálada je definovaná ako:
1
1



pozitívna
:
ak
I

I i 



i
nálada  

i  n
i  n
negatívna : inak




(1)
,kde I i vyjadruje intenzitu pozitívnych emócií v i a I i intenzitu
negatívnych emócií.
Osobnosť odráža individuálne rozdiely v duševných charakteristikách a má
dlhodobý vplyv, kde uvádzajú vlastnosti človeka ako otvorenosť, svedomitosť,
extrovertnosť, neuroticizmus a prívetivosť.
Obr. 2: Rozdelenie aplikačných oblastí výpočtových modelov emócií
Zdroj: Izard, 2006 Chyba! Nenalezen zdroj odkazů.
129
Obr. 3: Architektúra MOEGPP[23]
Podobné projekty sú napríklad FATIMA [13](Fearnot AffecTIve Mind Architecture),
CatHEXIS, MOEGPP [23] a EMA [26] (EMotion and Adaptationemotional situation).
V súčasnosti sa im venuje aj skupina okolo Feelix Growing [4].
Obr. .: Architektúra FATIMA [13]
130
Názov
projektu
EMA
Kismet
Flame
MAMID
Alma
MADB
FAtiMA
Cathexis
Procesy, ktoré zahŕňajú
Emócie, Nálada
Emócie, Nálada, Osobnosť, Základné potreby
Emócie, Nálada, Základné potreby
Emócie, Osobnosť
Emócie, Nálada, Osobnosť
Emócie, Nálada, Základné potreby, Prístupy
Emócie, Nálada, Osobnosť
Emócie, Nálada, Osobnosť, Základné potreby
Tab. 2: Porovnanie projektov kognitívnych modelov emócií vzhľadom na procesy,
ktoré zahŕňajú.
7. Záver
Aplikačný potenciál umelých emócií je široký. Okrem spoločenskej robotiky, ktorá
sa snaží najmä o vývoj robotov, ktoré by boli spoločníkmi v každodennom živote
ľudí, nájdu svoje uplatnenie v rôznych systémoch užívateľského rozhrania. Od
aplikácií v automobiloch, kde systém rozpozná emocionálny stav vodiča a upozorní
ho v prípade únavy varovným hlasom s cieľom znížiť nehodovosť, až po zložité
kognitívne roboty, kde by emócie slúžili ako podporný systém v rozhodovacích
procesoch.
Poďakovanie:
Táto práca bola vytvorená realizáciou projektu:
Rozvoj Centra informačných a komunikačných technológií pre znalostné systémy
(kód ITMS projektu: 26220120030) na základe podpory operačného programu
Výskum a vývoj financovaného z Európskeho fondu regionálneho rozvoja.
Literatúra
[1] Bailenson, J., N., Yee, N., Brave, S.: Virtual Interpersonal Touch: Expressing and
Recognizing Emotions Through Haptic Devices. HUMAN–COMPUTER
INTERACTION, 2007, Volume 22, pp. 325–353.
[2]
[3]
[4]
Bazzan, A. L. C., Bordini, R.: A framework for the simulation of agent with
emotions: report on experiments with the iterated prisoner`s dilemma. The 5th
Int. Conference on Autonomous Agents, Montreal, New York, 2001.
pp. 292-299.
Bhatti, W, M., Wang, Y., Guan, L.: A neural network approach for human
emotion recognition in speech. Proceedings of the 2004 international
symposium on circuits and systems, 2004.
Boucenna, S., Gaussier, P., Hafemeister, L, Bard, K.: Autonomous Development
Of Social Referencing Skills. From Animals to Animats, proceedings of the 11th
Conference on the Simulation of Adaptive Beahvior, 2010.
131
[5]
Bui, T. D., Heylen, D., Poel, M., Nijholt, A: Parlee: An adaptive plan based event
appraisal model of emotions. Heidelberg (ed.), KI 2002: Advances in Artiﬁcial
Intelligence, Vol. 2479 of Lecture Notes in Computer Science, Springer Berlin
/ Heidelberg, pp. 129–143.
[6]
Carnegie, D.: How to win friends and influence people. Pocket books, 1936.
[7]
[8]
Chakraborty, A.: Emotional Intelligence. Springer, 1998, pp. 261 – 270.
Custódio L., Ventura. R., Pinto-Ferreira C: Artificial emotions and emotionbased control systems. Proceedings of 7th IEEE International Conference on
Emerging Technologies and Factory Automation. 1999. V. 2. pp. 1415-1420.
[9] Daily, M, N. et. al.: EMPATH: A Neural Network that Categorizes Facial
Expressions, Journal of Cognitive Neuroscience, Vol14, 8, 2006,
pp. 1158-1173.
[10] Damasio, A., R.: Descartes' error: Emotion, reason, and the human
brainGrosset/Putnam, New York, 1994.
[11] Dang, T., H.,H.., Letellier-Zarshenas, S., Duhaut, D.: Grace generic robotic
architecture to create emotions. Advances in Mobile Robotics: Proceedings of
the Eleventh International Conference on Climbing and Walking Robots and
the Support Technologies for Mobile Machines, 2004, pp. 174–181.
[12] Davis, D. N.: Modelling emotion in computational agents, 2000. Available at
http://www2.dcs.hull.ac.uk/NEAT/dnd/papers/ecai2m.pdf. Revised:
15.4.2012.
[13] Dias, J., Mascarenhas, S., Paiva, A.: FAtiMA Modular: Towards an Agent
Architecture with a Generic Appraisal Framework, 2011.
[14] Fellous, J. M.: From Human Emotions to Robot Emotions. Architectures for
Modeling Emotions: Cross-Disciplinary Foundations.” AAAI Spring
Symposium, 2004. pp. 37-47.
[15] Freitas, J, S., Gudwin R., Queiroz, J.: Emotion in Artificial Intelligence and
Artificial Life Research: Facing Problems. Lecture Notes in Computer Science,
Springer-Verlag London, 2005.
[16] Frijda, N.H.: The emotions, Cambridge University Press, Cambridge, UK, 1986.
[17] Gadanho, S., Hallam, J.: Emotion-triggered learning in autonomous robot
control. Cybernetics and Systems: an international journal. V. 32, 2001,
pp.531-559.
[18] Gadanho, S., Hallam, J.: Emotion-triggered learning in autonomous robot
control. Cybernetics and Systems: an international journal. V. 32, July, 2001,
pp.531-55.
[19] Gebhard, P., Kipp, K.: Are Computer-generated Emotions and Mood plausible
to Humans? Proceedings of the 6th International Conference on Intelligent
Virtual Agents (IVA'06), pp. 343-356, Marina Del Rey, USA, 2006.
[20] Hollinger G., Georgiev Y., Manfredi A., Maxwell B., Pezzementi Z., Mitchell B.:
Design of a Social Mobile Robot Using Emotion-Based Decision Mechanisms.
132
International Conference on Intelligent RObots and Systems - IROS - IROS ,
pp. 3093-3098, 2006.
[21] Hudlicka, E.: A Computational Model of Emotion and Personality: Application
to Psychotherapy Research and Practice. Proceedings of the 10th Annual
CyberTherapy Conference: A Decade of Virtual Reality, Basel,
Switzerland, 2005.
[22] Izard C., E.: The Many Meanings/Aspects of Emotion: Definitions, Functions,
Activation, and Regulation. Emotion Review, 2010, vol. 2no. 4 363-370.
[23] Kim, J. K., Le, C.H.: Multi-objective Evolutionary Generation Process for Specific
Personalities of Artificial Creature, IEEE Computational Intelligence
Magazine, 2008.
[24] Ledoux, J.: The emotional brain: the mysterious underpinnings of emotional life.
New York, NY. Touchstone, 1996.
[25] Levine, D. S.: Neural network modeling of emotion. Physics of Life
Reviews, 2007.
[26] Marsella, S., Gratch, J.: Ema: A computational model of appraisal
dynamics.Agent Construction and Emotions, 2006.
[27] Minsky, M.: The Emotion Machine. Simon and Schuster, 2006.
[28] Nasr, E et al.: FLAME: Fuzzy Logic Adaptive Model of Emotions. Autonomous
Agents and Multi-Agent Systems, 3(3), 2000, pp. 219-257.
[29] Nehaniv, C.: The First, Second, and Third Person Emotions: Grounding
Adaptation in a Biological and Social World. 5th International Conference of
the Society for Adaptive Behavior (SAB'98). University of Zurich,
Switzerland,August, 1998.
[30] Perlovsky, L.I.: Toward physics of the mind: Concepts, emotions, consciousness,
and symbols. Physics of Life Reviews, 3, 2006, pp. 23–55.
[31] Petta, P., Trappl, R.: Emotions and agents. Multi-agents systems and
applications. Springer-Verlag: New York, NY, USA, 2001, pp. 301 - 316.
[32] Picard, R. W.: Affective computing. Cambridge, MA: MIT Press, 2007.
[33] Picard, R.W.: What does it mean for a computer to "have" emotions? Emotions
in Humans and Artifacts, pp 213-236. Cambridge, MA: MIT Pres.
[34] Plutchick, R.: The nature of emotions. American Scientist, 89, 344-350.
[35] Rolls, E.T.: The Brain and Emotion. Oxford University Press, 1998.
[36] Russel, J. A.: Core Affect and the Psychological Construction of Emotions.
Psychological Review, 110 (1), 145-172, 2003.
[37] Saint-Aim, S., Le-P, B., Duhaut, D.: iGrace – emotional computational model for
EmI companion robot. Valoria Laboratory - University of Bretagne Sud
France, Inria, 2010.
[38] Scheutz, M.: Useful roles of emotions in artificial agents: a case study from
artificial life. Proceedings of AAAI 2004. AAAI press, pp. 42-48.
133
[39] Velásquez, J.: Modeling emotion-based decision-making. Proceedings of the
1998 AAAI Fall Symposium. Emotional and Intelligent: the Tangled Knot of
Cognition, pp. 164–169.
[40] Wang, Y.: On the Cognitive Processes of Human Perception with Emotions,
Motivations and Attitudes. Int. Journal of Cognitive Informatics and Natural
Intelligence, 1(4), 1-13, 2007.
Ing. Mária Virčíková
Prof. Ing. Peter Sinčák, CSc.
134
POZNÁMKY:
135
Název: Sborník příspěvků z letní školy „Mezioborové přístupy informatiky
a kognitivní vědy“
Editor: prof. RNDr. Josef Zelenka, CSc.
Druh publikace: recenzovaný sborník 2. ročníku letní školy
Rok a místo vydání: 2012, Hradec Králové
Vydání: první
Náklad: 100 výtisků
Vydalo nakladatelství Gaudeamus, Univerzita Hradec Králové
jako svou 1157. publikaci.
ISBN 978-80-7435-216-4

zde - Univerzita Hradec Králové

Transkript

Podobné dokumenty

Use of Computers in Biology and Medicine

Ekonomické aspekty cestovního ruchu

zde - Univerzita Hradec Králové

Na tomto miste bude oficiální zadanizadani

Ontologický model pro portály

Slovníček NetLogo

Hlasové vyhledávání v jízdním řádu

Průvodce rozhraním

Metodika výpočtu ekologické stopy města

Myšlenkové mapy v teorii a praxi

České Vysoké Učení Technické v Praze Fakulta

Marik et al.: Umela inteligence (2).

Celulární automaty

PluScanner

Počítačové sítě (PSIT3)

Reaktivní multiagentní modely v ekonomii

IBM Connections a integrace aplikací

Počítačové sítě IV. (PSIT4)

5 - Oficiální stránky gymnázia Pardubice

Přesvědčování